A. Use the least amount of permissions to accomplish the required task.
B. Use the minimum of software tools and packages to implement the required services.
C. Securing your server is a continuous process, not a one-time activity.
1. Always start with a minimal server installation and add packages as they're needed. Reasoning: every piece of software can be a potential vulnerability. There's no need to insert a vulnerability with something you'll not use in the first place.
2. Set up a user account and install sudo. Add user to the sudoers file and configure system to allow root login only on tty1-tty8.
3. Install ssh and reconfigure it to listen on non-standard efemeral port (> 1024). If possible, install port knocking to unlock the new ssh port - do not use default knocking sequence!
4. Configure ssh to disable password authentication and permit only pubkey authentication. Install your public key in authorized_keys of a user account. Always use strong passphrase for your keys and keep private keys as best as you can!
5. If server requires ordinary users to log in onto it, configure PAM to harden password policy, if possible. If a users that logs in do not require full access to command, give him a restricted shell.
6. Install only necessary services for your server. If you can choose, choose services that implement some kind of encryption when accessing server. For example, if your users need some sort of remote file services and they can use both FTP and SCP/SFTP, choose SCP/SFTP. Avoid telnet service if at all possible (but have telnet client as you'll probably need it when troubleshooting tcp connections).
7. Use SELinux or AppArmor if you can. Learn to create custom SELinux policies if needed (some software just won't work with SELinux in enforcing mode).
8. Set up iptables in the most restrictive way. On INPUT chain block all ports except those that your services use on that server. Limit open ports by IP addresses that are permitted to access them, if at all possible.
9. Set rules to the OUTPUT chain as well. Lots of exploits work by establishing connection from compromised server back to the attacker's machine which usually bypass external firewalls. Limiting outgoing traffic can mitigate attacks and render them useless.
10. Implement remote central log server and install some sort of log analyzing software. Check logs frequently and search for unusual patterns.
11. Check your /etc/fstab and add 'nodev,noexec,nosuid' options on filesystems that will not have executables and devices. This is far from bullet-proof protection and it can be thwarted by competent attacker, but can still stop some script kiddies and automated attacks.
12. Use chroot when possible. I know this is also almost trivial to evade, but still, why would I ease the attacker's job?
13. Implement tripwire or similar software if you can keep your file-signature database on some non-volatile media (like CD-ROM).
14. Upgrade and apply patches if at all possible.
15. Run some audit tool, both local (Lynis) and remote (OpenVAS, Nessus) to check if you managed to cover all the bases. Analyze reports made by those apps and apply necessary changes to your system.
B. Use the minimum of software tools and packages to implement the required services.
C. Securing your server is a continuous process, not a one-time activity.
1. Always start with a minimal server installation and add packages as they're needed. Reasoning: every piece of software can be a potential vulnerability. There's no need to insert a vulnerability with something you'll not use in the first place.
2. Set up a user account and install sudo. Add user to the sudoers file and configure system to allow root login only on tty1-tty8.
3. Install ssh and reconfigure it to listen on non-standard efemeral port (> 1024). If possible, install port knocking to unlock the new ssh port - do not use default knocking sequence!
4. Configure ssh to disable password authentication and permit only pubkey authentication. Install your public key in authorized_keys of a user account. Always use strong passphrase for your keys and keep private keys as best as you can!
5. If server requires ordinary users to log in onto it, configure PAM to harden password policy, if possible. If a users that logs in do not require full access to command, give him a restricted shell.
6. Install only necessary services for your server. If you can choose, choose services that implement some kind of encryption when accessing server. For example, if your users need some sort of remote file services and they can use both FTP and SCP/SFTP, choose SCP/SFTP. Avoid telnet service if at all possible (but have telnet client as you'll probably need it when troubleshooting tcp connections).
7. Use SELinux or AppArmor if you can. Learn to create custom SELinux policies if needed (some software just won't work with SELinux in enforcing mode).
8. Set up iptables in the most restrictive way. On INPUT chain block all ports except those that your services use on that server. Limit open ports by IP addresses that are permitted to access them, if at all possible.
9. Set rules to the OUTPUT chain as well. Lots of exploits work by establishing connection from compromised server back to the attacker's machine which usually bypass external firewalls. Limiting outgoing traffic can mitigate attacks and render them useless.
10. Implement remote central log server and install some sort of log analyzing software. Check logs frequently and search for unusual patterns.
11. Check your /etc/fstab and add 'nodev,noexec,nosuid' options on filesystems that will not have executables and devices. This is far from bullet-proof protection and it can be thwarted by competent attacker, but can still stop some script kiddies and automated attacks.
12. Use chroot when possible. I know this is also almost trivial to evade, but still, why would I ease the attacker's job?
13. Implement tripwire or similar software if you can keep your file-signature database on some non-volatile media (like CD-ROM).
14. Upgrade and apply patches if at all possible.
15. Run some audit tool, both local (Lynis) and remote (OpenVAS, Nessus) to check if you managed to cover all the bases. Analyze reports made by those apps and apply necessary changes to your system.
No comments:
Post a Comment