views:

463

answers:

7

What security best-practices would you strongly recommend in maintaining a Linux server? (i.e. bring up a firewall, disable unnecessary services, beware of suid executables, and so on.)

Also: is there a definitive reference on Selinux?

EDIT: Yes, I'm planning to put the machine on the Internet, with at least openvpn, ssh and apache (at the moment, without dynamic content), and to provide shell access to some people.

+1  A: 

1.) Enabling only necessary and relevant ports.

2.) Regular scan of the network data in - out

3.) Regular Scan of ip addresses accessing the server and verify if any unusual data activity associated with those ip address as found from logs/traces

4.) If some some critical and confidential data and code, needs to be present on the server , may be it can be encrypted

-AD

goldenmean
+3  A: 

The short answer is, it depends. It depends on what you're using it for, which in turn influences how much effort you should put into securing the thing.

There are some handy hints in the answers to this question: http://stackoverflow.com/questions/5078/personal-linux-web-server

If you're not throwing the box up onto the internet, some of those answers won't be relevant. if you're throwing it up onto the internet and hosting something even vaguely interesting on it, those answers are far too laissez-faire for you.

+4  A: 

For SELinux I've found SELinux By Example to be really useful. It goes quite in-depth into keeping a sever as secure as possible and is pretty well written for such a wide topic.

In general though:

  • Disable anything you don't need. The wider the attack domain, the more likely you'll have a breach.
  • Use an intrusion detection system (IDS) layer in front of any meaningful servers.
  • Keep servers in a different security zone from your internal network.
  • Deploy updates as fast as possible.
  • Keep up to date on 0-day attacks for your remotely-accessible apps.
Oli
+3  A: 

There's an NSA document "NSA Security Guide for RHEL5" available at:

http://www.nsa.gov/snac/os/redhat/rhel5-guide-i731.pdf

which is pretty helpful and at least systematic.

tonys
+1  A: 
  • Limit the software to the only ones you really use
  • Limit the rights of the users, through sudo, ACLs, kernel capabilities and SELinux/AppArmor/PaX policies
  • Enforce use of hard passwords (no human understandable words, no birthday dates, etc.)
  • Make chroot or vserver jails for the "dangerous" applications
  • Install some IDS, e.g. Snort for the network traffic and OSSEC for the log analysis
  • Monitor the server
  • Encrypt your sensible datas (truecrypt is a gift of the gods)
  • Patch your kernel with GRSecurity : this add a really nice level of paranoïa

That's more or less what I would do.

Edit : I added some ideas that I previously forgot to name ...

edomaur
A: 

Don't use a DNS Server unless you have to . BIND has been a hotspot of security issues and exploits.

Brian G
And, if you need a DNS server for a local subnet but do not need to provide external DNS, then both configure BIND to not listen to external ports and firewall block external DNS incoming access.
Eddie
A: 

Goals: The hardest part is always defining your security goals. Everything else is relatively easy at that point.

Probing/research: Consider the same approach that attackers would take, ie network reconnaissance (namp is pretty helpful for that).

More information: SELinux by example is a helpful book, finding a good centralized source for SELinux information is still hard. I have a small list of helpful links that I find useful time to time http://delicious.com/reverand_13/selinux

Helpful solution/tools: As with what most people will say less is more. For an out of the box stripped down box with SELinux I would suggest clip (http://oss.tresys.com/projects/clip). A friend of mine used it in an academic simulation in which the box was under direct attack from other participants. I recall the story concluded very favorably for said box.

You will want to become familiar with writing SELinux policy. Modular policy can also become helpful. such tools as SLIDE and seedit (have not tried) may help you.

rev