Dedicated Server Security Audit: 10 Checks You Should Run Monthly

Running a dedicated server gives you full control over performance and configuration—but it also means you’re responsible for keeping it secure. A structured monthly security audit helps you catch misconfigurations, outdated software, and weak access controls before an attacker does.

Below is a complete, step-by-step checklist you can run on a Linux-based dedicated server (Ubuntu/CentOS–style). Each section includes concrete commands you can copy and adapt.

1. Check for OS and Package Updates

Unpatched operating systems are one of the most common entry points for attackers. Always keep your kernel and core packages up to date.

On Ubuntu/Debian

bash 
sudo apt update
sudo apt list --upgradable
sudo apt upgrade -y
sudo apt autoremove -y

Check if a reboot is required:

bash
cat /var/run/reboot-required

If the file exists, reboot using sudo reboot.

On RHEL/CentOS (or AlmaLinux/Rocky)

bash
sudo dnf check-update      # or `yum check-update`
sudo dnf update -y         # or `yum update -y`
sudo reboot
Tip: Use unattended-upgrades (Ubuntu) or dnf-automatic (RHEL) to automatically apply critical security patches while still maintaining control.

2. Review User Accounts and Sudo Privileges

Unused or overly privileged accounts are a major risk. Every month, confirm who has access and what they can do.

List all users:

bash
cut -d: -f1 /etc/passwd
  • Look for default accounts (e.g., test, demo, old developers).
  • Look for any unexpected interactive users.

Check sudoers:

bash
sudo grep -v '^#' /etc/sudoers | grep -v '^$'
sudo ls -l /etc/sudoers.d/

Review any custom files in /etc/sudoers.d/ and remove overly broad or unused grants.

Remove unused accounts:

bash
sudo userdel -r username

Also rotate passwords for active admin accounts using sudo passwd username.

3. Audit SSH Configuration and Keys

SSH is the main way you manage your server; hardening it is essential.

Edit SSH config: Open the configuration file:

bash
sudo nano /etc/ssh/sshd_config

Recommended settings:

text
Port 2222                      # avoid default 22
PermitRootLogin no             # disallow root login
PasswordAuthentication no      # use SSH keys only
AllowUsers alice bob           # explicitly allow users
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Save, then restart SSH using sudo systemctl restart sshd. Before closing your current session, make sure you can reconnect. If you get locked out, use your provider’s KVM/IPMI console to regain access.

Rotate SSH keys: Remove old or unused entries from ~/.ssh/authorized_keys. Encourage team members to generate new keys and remove old ones.

bash
ssh-keygen -t ed25519 -C "user@server"
ssh-copy-id user@your-server-ip

4. Review Firewall Rules and Open Ports

Too many open ports mean more attack surface. Use a firewall to lock down only what you need.

If using UFW (Ubuntu)

bash
sudo ufw status verbose
sudo ufw show added

Common secure setup:

bash
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw enable

If using firewalld (RHEL/CentOS)

bash
sudo firewall-cmd --list-all

Allow only essential services:

bash
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Use ss -tuln to see what’s listening and close or block any ports that shouldn’t be public.

5. Scan for Running Services and Unnecessary Software

Unneeded services increase your risk if they’re exposed or misconfigured.

List listening services:

bash
ss -tuln

Check for services listening on 0.0.0.0 that should be internal or disabled.

List installed packages:

On Ubuntu: dpkg -l | grep -E '^ii' | awk '{print $2}'

On RHEL: rpm -qa

Remove unused software:

bash
sudo apt remove --purge package-name
# or
sudo dnf remove package-name

Common candidates to remove include Telnet, FTP servers, old web servers, and development tools (gcc, compilers) if you don’t compile on the live server.

6. Check File Permissions and World-Writable Files

Loose permissions can expose configs, keys, or databases.

Find world-writable files:

bash
sudo find / -xdev -type f -perm -002 -ls 2>/dev/null
sudo find / -xdev -type d -perm -002 -ls 2>/dev/null

Look especially for web-root directories with world-write enabled, or config/script files that don’t need write access. Secure typical web directories:

bash
sudo chmod 755 /var/www/html
sudo chmod 644 /var/www/html/*.php

Protect sensitive directories:

bash
sudo chmod 700 /root
sudo chmod 750 /etc/ssh
sudo chmod 600 ~/.ssh/id_rsa

7. Review Logs for Suspicious Activity

Logs are your first sign of brute-force attacks or odd logins.

Check failed SSH logins (Ubuntu):

bash
sudo grep "Failed password" /var/log/auth.log | tail -20
sudo grep "Invalid user" /var/log/auth.log | tail -20

On RHEL/CentOS:

bash
sudo grep "Failed password" /var/log/secure | tail -20
sudo grep "Invalid user" /var/log/secure | tail -20

Install and configure fail2ban (recommended):

bash
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Enable [sshd] and set bantime = 3600 and maxretry = 3. Then enable and check status:

bash
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

8. Audit Cron Jobs and Background Tasks

Unpatched or forgotten cron jobs can be exploited. List all cron jobs:

bash
# For root:
sudo crontab -l

# For each user:
sudo crontab -u username -l

# System-wide cron:
ls /etc/cron.d/
cat /etc/crontab
  • Check for scripts in world-writable directories.
  • Look for jobs calling curl or wget to unknown URLs.
  • Find old backup scripts that still store credentials in plain text.

Restrict execution to proper paths using commands like sudo chmod 700 /root/scripts/.

9. Check Backups and Recovery Readiness

A security issue is only half-fixed if your data isn’t recoverable.

Confirm backup status: If you use your provider’s image-based backups or snapshots, verify they are scheduled and recent. For custom scripts, check the latest backup file:

bash
ls -la /backup/ | head -10

Ideally, backups should be encrypted (e.g., gpg or restic) and stored off-server.

Test a recovery: Once a month, pick a small service and restore it from backup:

bash
tar -xzf /backup/site-2026-03-01.tar.gz -C /tmp/test-restore

Verify files and database consistency, and document the steps so anyone on your team can repeat them in an emergency.

10. Run a Light-Weight Vulnerability Scan with Lynis

Lynis is a powerful but lightweight security auditing tool for Linux servers.

Install Lynis (Ubuntu/Debian):

bash
sudo apt install lynis -y

Run an audit:

bash
sudo lynis audit system

Lynis will highlight Warnings (high-priority fixes) and Suggestions (best-practice improvements). Review the report and fix weak password policies, missing logging, or SSH misconfigurations.

You can also schedule a monthly scan by adding this to your crontab:

text
0 2 1 * * /usr/bin/lynis audit system --quiet

Ready to deploy this on a globally optimized server?

Once you’ve hardened your server following these 10 monthly checks, the next step is choosing a hosting platform that matches your security and performance needs worldwide.

Fit Servers offers a robust dedicated server platform with 250+ global locations, giving you the flexibility to host your audited server close to your target audience. This helps reduce latency, improve page-load times, and strengthen your GEO-performance without compromising on security.

If you’re looking for a secure, well-connected environment for your hardened Linux box, Fit Servers’ worldwide network makes it easy to deploy your server in the right region and keep your monthly security audit running smoothly.

Discover fitservers Dedicated Server Locations

Fit Servers are available around the world, providing diverse options for hosting websites. Each region offers unique advantages, making it easier to choose a location that best suits your specific hosting needs.