Linux server hardening: SSH, PAM, sysctl
You harden a freshly installed Linux server step by step, securing SSH, password and session policy, kernel network settings and mount options.
Level 201 · 20 lessons · 18 practice labs
Lessons
Locking down SSH
- Reading sshd_config: seeing effective settings with sshd -T
- Key-only login: disabling passwords and root login
- Limiting who connects with AllowGroups and Match
- Narrowing SSH ciphers and key exchange algorithms
- Blocking brute-force attempts with fail2ban
- Short task: leave SSH open only to the admin group and only with keys
Passwords, sessions and PAM
- The PAM stack: auth, account, password, session
- Password quality rules with pwquality
- Account lockout with faillock
- Closing idle sessions: TMOUT and logind
- Login warning banners: /etc/issue and motd
- Short task: set a policy that locks an account for 15 minutes after five failed attempts
Kernel and file system
- Network settings with sysctl: forwarding, ICMP redirects, SYN cookies
- Kernel protection settings: ASLR, dmesg and ptrace limits
- Mount options: nodev, nosuid, noexec for /tmp
- Disabling core dumps
- Inventorying SUID and SGID files
- Short task: write the sysctl settings to a persistent file and verify them
Capstone
- Hardening checklist and change record
- Capstone: get a new web server ready for production
Practice labs
- Find and close the weak SSH settings on this server: Find weak settings such as root and password login in sshd -T output, fix them and show the effective values again.
- Install your own key before switching to key-only login: Add your key to the admin account, test key login and only then disable password login.
- Find the drop-in file that overrides your SSH setting: Find a file under sshd_config.d that overrides the main setting, fix the order and prove the result with sshd -T.
- Allow the backup account SFTP from one address only: Use a Match block to limit the backup user to one source address and SFTP only, and show it cannot open a shell.
- Remove weak SSH algorithms without breaking the old clients: Disable weak ciphers and key exchange algorithms, then test that the three listed clients can still connect.
- Turn on fail2ban for SSH and ban the guesser: Enable the sshd jail, let the incoming password guessing get banned and show the banned address with fail2ban-client.
- Configure fail2ban so it never bans the office address: Add the office address to ignoreip, set the ban time and retry limit to the policy and test with two addresses.
- Write a fail2ban filter for a custom login log: Write a regex filter for an internal admin panel’s log, test it with fail2ban-regex and put the new jail into service.
- Bring password quality rules in line with company policy: Set the minimum length and character classes in pwquality to the policy and show a weak password is rejected.
- Set up account lockout with faillock and unlock an account: Set a ten-minute lock after five failed attempts, get an account locked and reopen it with faillock.
- Find the line in the PAM stack that lets everyone in: Find a stray pam_permit or wrong control flag in a PAM file, fix it and prove a wrong password is now refused.
- Turn off IP forwarding on a server that should not route: Check the running value and the persistent file, disable forwarding and verify the value after reloading.
- Disable ICMP redirects and source routing: Write the relevant sysctl keys for all interfaces to a persistent file and show the values after sysctl --system.
- Catch the sysctl setting that another file overrides: Find which file brings back a ptrace setting after reboot, fix the precedence and prove the value persists.
- Mount /tmp with noexec and nosuid: Add mount options for /tmp to fstab, remount it and show a script there no longer runs.
- Find the extra SUID file on this system: List SUID and SGID files, find the suspicious one that no package owns and remove its bit.
- Stop core dumps from leaking passwords: Show a password inside a crashed service’s dump, disable core dumps through limits, sysctl and systemd, and try again.
- Restrict SSH access through the jump host by group: Use Match blocks in sshd_config so the admin group can log in only from the jump host and everyone else gets SFTP only, then prove it with three accounts.
About this course
You harden a freshly installed Linux server step by step, securing SSH, password and session policy, kernel network settings and mount options.
What you will learn
- Locking down SSH
- Passwords, sessions and PAM
- Kernel and file system
- Capstone
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.