In this first part, I will list just 5 steps. The second part will list the next 5 steps.
I usually like to outline the levels of quick security as
- Remote access
- Application access
The reason for this priority is this, the first access is usually physical if an attack is local, if physical attack fails, the next is usually a network attack, then remote attack, the access to files with loose permissions and security then applications. Application attacks usually comes with Network level attacks. You can however create your own order depending on what service you are offering. Lets get to the quick steps.
1) remove unwanted users-gopher,games,operator,uucp: You do not want exploitation of these accounts. They are not so useful when running a server, therefore delete them and confirm they have been safely deleted.
2)rename halt,poweroff,reboot in /etc/security/console.apps/ directory: You do not want some guy to pop into your server room and power off your server. Restrict what users can do when they login remotely unless there is power failure. Im assuming every server has a UPS. Connect the UPS to the server to monitor UPS activities. Restrict access to the UPS configs and logs.
3)/etc/inittab comment out ctrl+Alt+del and set runlevel to 3: This is pretty straight forward. You dont want anyone restarting your server. So you say you are a pro linux user, what do you need X,Gnome,KDE for if you will login over ssh?? Run the server in runlevel 3. This gives you several advantages including system performance. This way you save memory for other services that require them.
4) set login times /etc/login.defs:Whiles you are off during the weekend you do not want a compromised user account to get into the system and escalate privileges and end up setting up backdoors. I have a script that checks possible backdoors as well as possible logins at odd hours. This way Im informed over SMS and email if any stranger logs into my servers or tries to brute my servers.
5) Enable SELinux: I have heard lots of people complaining about SELinux denials,so they disable it after setting up a Fedora server. SELinux is the next step to defence after iptables,never disable it. Learn its internals and it will guard your path. In another article I will do a mini how to for SELinux. I think this will help most people appreciate the strength and essence of SELinux in a server setup. It is pretty straight forward when using SELinux. SELinux policies can be used to protect backup files so that unprivileged users do not have access.Its a preference over AppArmor for me. Start at Enforcing the SELinux rules. Its an addon to making you a pro administrator.
Get started now. In the second part of this article, I will wrap up with the last 5 quick steps. i will also post my script here to share with you. Im sure this will help most people as a quick measure to monitoring/securing their servers. I will later on write on what quick steps will help you detect if your server has been hacked and what damage control measures to put in place immediately. For those of you running web services I will put up a checklist too.
Till then.. happy tuxing...
feel the power of Fedora.... Infinity, Freedom and Friends...