Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm able to take a basic linux distro (stable Ubuntu Server) and install everything I need to get my web apps up and running. (Django, Rails, PHP etc...) But after all of that I would appreciate some advice on security.

Here is my current checklist: 1. Change the root password assigned to me 2. Add admin user so I don't have to log in as root 3. Change ssh port to something random I make up and require SSH Key 4. Set up IPTables to block nearly everything except (80, my ssh port, and maybe a couple of others depending

on requirements)

What now? How do I keep the server up to date? I really don't want to have to read the ubuntu-security-announce mailing list daily I just want to build web apps.

share|improve this question

Make sure you configure IPTables to also constrain ssh and anything else you have that shouldn't be public to the local subnet or specific workstations. You may want to constrain outgoing traffic as well if you are working with more than one server to limit damages in the event of a compromise. apt-get update for doing basic updates, installs from source you need to do yourself. For installs from source the README file will usually tell you what you need to know, and often there are migration matrices or upgrade guides. If anything else the procedure is almost always simply reinstalling from source (./configure [options], make, make install)

You can also do rate limiting with iptables to alleviate brute forcing and basic DOS (Denial of Service). You probably want to make sure you are DROP(ing) packets instead of REJECT(ing) them in your iptables. Reject sends a response back to the sender that they were....well Rejected. Drop just acts like the it never got the packet.

An example of rate limiting can be found here:

I would highly recommend reading some of the other articles on the site above.Vivek Gite is quite artful at getting the basic points across, and he covers alot on security.

Adding an admin user so you don't have to log in at all as root is a minimal security gain - doing things as root is fine as long as you accept the risk of allowing your ownmistakes to be bigger i.e. accidentaly deleting /boot. More important is turning root login via SSH off (in /etc/ssh/sshd_config), so you can only get root by su or allowing only physical access\certain users the ability to switch to root.

I do want to stress the admin user is still good as a stepping stone to root (i.e. ssh in as admin then switch to root), just that making an admin user so you don't have to login to root is a little in vain in the context of security.

You might also look into an application firewall. Application Firewalls protect against various higher level attacks than something else like say IPTables which works with packets. If your using Apache as your web server Mod_Security2 (by Ivan Ristic) is a solid choice.

If you want even more security traps\defenses you can look into Intrusion Detection Systems, a popular one is Snort.

Make sure you have antivirus. A good free one is Clam AV.

If the above is more than you think you need for your environment at the minimal:

  1. Install Antivirus
  2. Turn SSH for Root off.
  3. Constrain SSH and other services on open ports to only accept connections from your subnet in iptables.

Past this it gets into vague hairy details that you need to look at like making sure file and folder permissions are not too loose, badly written programs aren't running as root, etc.

share|improve this answer
Good suggestions, also change the "SSH Port" from 22 to something else. I normally set them to 34020 or some not so very usual number. – rihatum Jan 10 '11 at 12:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.