Linux Security Recipes: New Server, Website, Check-up

New server: the first hour

Do these in order on any server you're responsible for, before anything goes on it. Keep your first SSH session open the whole time, so one mistake can't lock you out.

Step	Rocky / RHEL	Ubuntu / Debian
1. Update everything, then reboot if the kernel changedLesson: Updates done right	`sudo dnf upgrade -y` `sudo reboot`	`sudo apt update` `sudo apt full-upgrade -y` `sudo reboot`
2. Make your own admin account, and stop working as rootLesson: Managing users & groups	`sudo useradd -m -G wheel NAME` `sudo passwd NAME`	`sudo adduser NAME` `sudo usermod -aG sudo NAME`
3. On YOUR computer: make a key with a passphrase and copy it overLesson: Lock down SSH	`ssh-keygen -t ed25519` `ssh-copy-id NAME@SERVER` same on both
4. Turn off password and root logins, then test in a NEW window before closing the old oneLesson: Lock down SSH	`printf 'PasswordAuthentication no\nPermitRootLogin no\n' \| sudo tee /etc/ssh/sshd_config.d/00-hardening.conf` `sudo sshd -t` `sudo systemctl reload sshd`	`printf 'PasswordAuthentication no\nPermitRootLogin no\n' \| sudo tee /etc/ssh/sshd_config.d/00-hardening.conf` `sudo sshd -t` `sudo systemctl reload ssh`
5. Firewall: refuse everything except SSH (and what the server is for)Lesson: Firewalls in depth	`sudo firewall-cmd --list-all` `sudo firewall-cmd --permanent --remove-service=cockpit` `sudo firewall-cmd --reload`	`sudo ufw allow OpenSSH` `sudo ufw enable` `sudo ufw status verbose`
6. Security updates install themselves every nightLesson: Updates done right	`sudo dnf install dnf-automatic` `sudoedit /etc/dnf/automatic.conf` `sudo systemctl enable --now dnf-automatic.timer` In the file, set `upgrade_type = security` and `apply_updates = yes`.	`cat /etc/apt/apt.conf.d/20auto-upgrades` `systemctl list-timers 'apt-daily*'` unattended-upgrades is installed and on by default; just check it.
7. Switch off everything the server doesn't needLesson: Think like an attacker	`sudo ss -tlnp` `systemctl list-units --type=service --state=running` `sudo systemctl disable --now NAME` same on both
8. From another machine you own, check what the network seesLesson: Scan your own lab with nmap	`nmap SERVER` `nmap -p- SERVER` same on both
9. Save a fingerprint of the clean serverLesson: Did anyone change anything?	`sudo dnf install aide` `sudo aide --init` `sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz`	`sudo apt install aide` `sudo aideinit`
10. Set up backups that leave the server, and test a restore onceLesson: Backups: tar, rsync & cron	`sudo tar czf /root/etc-$(date +%F).tar.gz /etc` `rsync -a /root/*.tar.gz BACKUPHOST:backups/` same on both

Put a website online safely

From an empty server to a site that's tight-lipped, encrypted and checked. Do "New server: the first hour" first.

Step	Rocky / RHEL	Ubuntu / Debian
1. Install the web server and start it at bootLesson: Services & your first website	`sudo dnf install httpd` `sudo systemctl enable --now httpd` Rocky waits for you to start it.	`sudo apt install apache2` `systemctl status apache2` Ubuntu starts Apache as soon as it's installed.
2. Let web traffic through the firewallLesson: Firewalls in depth	`sudo firewall-cmd --permanent --add-service=http --add-service=https` `sudo firewall-cmd --reload`	`sudo ufw allow 'Apache Full'`
3. Hide the version: ServerTokens Prod and ServerSignature OffLesson: Web server hardening & HTTPS	`sudoedit /etc/httpd/conf.d/security.conf`	`sudoedit /etc/apache2/conf-available/security.conf`
4. No folder listings: take Indexes out of the Options lineLesson: Web server hardening & HTTPS	`sudoedit /etc/httpd/conf/httpd.conf`	`sudoedit /etc/apache2/apache2.conf`
5. Add security headersLesson: Web server hardening & HTTPS	`Header always set X-Content-Type-Options "nosniff"` `Header always set X-Frame-Options "SAMEORIGIN"`	`sudo a2enmod headers` `Header always set X-Content-Type-Options "nosniff"` `Header always set X-Frame-Options "SAMEORIGIN"`
6. Check the config, then reloadLesson: Web server hardening & HTTPS	`sudo apachectl configtest` `sudo systemctl reload httpd`	`sudo apache2ctl configtest` `sudo systemctl reload apache2`
7. Get a real HTTPS certificate (your domain must already point at the server)Lesson: Web server hardening & HTTPS	`sudo dnf install epel-release` `sudo dnf install certbot python3-certbot-apache` `sudo certbot --apache -d YOUR.DOMAIN` certbot offers to redirect HTTP to HTTPS: say yes.	`sudo apt install certbot python3-certbot-apache` `sudo certbot --apache -d YOUR.DOMAIN` certbot offers to redirect HTTP to HTTPS: say yes.
8. Make sure renewals will workLesson: Web server hardening & HTTPS	`sudo certbot renew --dry-run` same on both
9. Look at it from outsideLesson: Scan your own lab with nmap, Web server hardening & HTTPS	`curl -I https://YOUR.DOMAIN` `curl -I http://YOUR.DOMAIN` `nmap -sV -p 80,443 YOUR.DOMAIN` same on both

Someone got in: what to do

Stay calm and go in order. Close the door before you chase anyone out, and keep the evidence.

Step	Rocky / RHEL	Ubuntu / Debian
1. Look first, and write down what you seeLesson: Spot trouble in the logs	`last \| head -20` `w` `sudo ss -tnp` `ps auxf` same on both
2. Copy the logs somewhere safe before changing anythingLesson: Spot trouble in the logs	`mkdir ~/evidence` `sudo cp -a /var/log/secure* ~/evidence/` Then copy them off the server too (scp or rsync to a machine you trust).	`mkdir ~/evidence` `sudo cp -a /var/log/auth.log* ~/evidence/` Then copy them off the server too (scp or rsync to a machine you trust).
3. Find the way in: the login that workedLesson: Spot trouble in the logs	`sudo grep Accepted /var/log/secure` `sudo lastb \| head`	`sudo grep Accepted /var/log/auth.log` `sudo lastb \| head`
4. Lock the accountLesson: Spot trouble in the logs	`sudo usermod -L NAME` `sudo usermod -s /sbin/nologin NAME` same on both
5. Then end their sessionsLesson: Spot trouble in the logs	`sudo pkill -KILL -u NAME` same on both
6. Take back what they left: keys and scheduled jobsLesson: Spot trouble in the logs	`sudo cat /home/NAME/.ssh/authorized_keys` `sudo crontab -l -u NAME` same on both
7. Did they get root? Look for refused or used sudo, extra UID 0 accounts and changed programsLesson: Did anyone change anything?	`sudo grep sudo /var/log/secure` `awk -F: '$3 == 0' /etc/passwd` `sudo rpm -Va`	`sudo grep sudo /var/log/auth.log` `awk -F: '$3 == 0' /etc/passwd` `sudo dpkg --verify`
8. If they got root: rebuildLesson: Backups: tar, rsync & cron, Did anyone change anything?	Take the server off the network, install fresh, restore data from a backup made before the break-in, and change every password and key that was on it. You can't trust anything on a server someone controlled.
9. Close the hole they usedLesson: Lock down SSH	`printf 'PasswordAuthentication no\n' \| sudo tee /etc/ssh/sshd_config.d/00-hardening.conf` `sudo sshd -t` `sudo systemctl reload sshd`	`printf 'PasswordAuthentication no\n' \| sudo tee /etc/ssh/sshd_config.d/00-hardening.conf` `sudo sshd -t` `sudo systemctl reload ssh`

Monthly security check-up

Twenty minutes once a month. Put it in your calendar.

Step	Rocky / RHEL	Ubuntu / Debian
1. Any updates waiting?Lesson: Updates done right	`sudo dnf check-update` `sudo dnf updateinfo list --security`	`sudo apt update` `apt list --upgradable`
2. Who logged in, and who failed?Lesson: Spot trouble in the logs	`last \| head -20` `sudo lastb \| head` same on both
3. Is anything new listening?Lesson: Think like an attacker	`sudo ss -tlnp` same on both
4. What does the network see? (from another machine you own)Lesson: Scan your own lab with nmap	`nmap SERVER` same on both
5. Who are the admins, and what may the others run?Lesson: Find the weak spots	`getent group wheel` `sudo ls /etc/sudoers.d/` `sudo -l -U NAME`	`getent group sudo` `sudo ls /etc/sudoers.d/` `sudo -l -U NAME`
6. Any new SUID programs or files anyone can change?Lesson: Find the weak spots	`sudo find / -xdev -perm -4000 -type f 2>/dev/null` `sudo find / -xdev -type f -perm -0002 2>/dev/null` same on both
7. Did anything change that shouldn't have?Lesson: Did anyone change anything?	`sudo aide --check` `sudo rpm -Va`	`sudo aide --config /etc/aide/aide.conf --check` `sudo dpkg --verify`
8. When do the HTTPS certificates run out?Lesson: Web server hardening & HTTPS	`sudo certbot certificates` same on both
9. Restore one file from last night's backupLesson: Backups: tar, rsync & cron	`tar -tzf BACKUP.tar.gz \| head` `tar -xzf BACKUP.tar.gz -C /tmp/restore-test etc/hostname` same on both

Recipes

🛡 New server: the first hour

🔐 Put a website online safely

🚨 Someone got in: what to do

📅 Monthly security check-up

New server: the first hour

Put a website online safely

Someone got in: what to do

Monthly security check-up