Say I've got a fresh install of Ubuntu, what steps should I take to secure it for use as a Rails application server?
Tell me more
×
Server Fault is a question and answer site for
professional system and network administrators. It's 100% free, no registration required.
|
closed as not a real question by Chris S♦ Jan 26 '12 at 4:26
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.
|
I can't think of any Ubuntu-specific tweaks, but here's a few that apply to all distributions:
Of course this list isn't complete, and you'll never be completely safe, but it covers all the exploits I have seen in real life. Also, the exploits I have seen were almost always related to unsecure user code, not unsecure configuration. The default configurations in minimal, server distributions tend to be pretty secure. |
|||||||||||||||
|
|
One quick thing that I do early on is install DenyHosts. It will regularly look through the /var/log/secure, looking for failed logins, and after a couple of failures, block the IP. I set it to block after the first no-such-user, on the second attempt at root, and after a couple of tries for real users (in case you mess up, but you should be using a SSH public key to login). |
|||||||||||||
|
|
Ubuntu is based off Debian and I've found the Securing Debian Manual to be very useful in Debian-based distributions in completely walking you through your system and checking every part. It's basically a really, really comprehensive answer to your question. |
|||||
|
|
Install logcheck, but tweak so that you never receive messages from regular events, otherwise you'll get in the habit of ignoring the emails. Check which processes are listening using netstat, and make sure nothing's running that doesn't need to run. Many daemons can be configured only to listen on the internal IP (or localhost) instead of all interfaces. |
|||
|
|
|
I usually install RKHunter, which scans for rootkits and does integrity checks of various important system binaries. It's in the standard repo, and will run daily from cron. It's not perfect, securitywise, but it's a low-effort item to add, and it provides a measure of protection. |
|||
|
|
|
Do what Can suggests... Nmap the host and disable all non-essential services. Use iptables if necessary. |
|||||
|
|
Use separate partitions for various directories like |
||||
|
|
|
If you're going anywhere near the Internet with the server, install an intrusion detection system like snort. |
|||
|
|
|
As well as other suggestions here I'll mention three that are obvious but perhaps worth mentioning for completeness:
|
||||
|
|
Some firewall suggestions.Learn to use a firewall and the concepts of properly locking a box down. Changing default ports is largely a useless thing; proper application and firewall configuration are much more important. Both are in the Ubuntu repos: FireHOLhas terrific documentation and very easy to learn syntax. I was able to set up a gateway/firewall in twenty minutes. The only reason I've moved away from this is that it doesn't seem to be maintained (last release 2 yrs ago). Doesn't mean it doesn't work, but... Fermis another one. More iptables-like syntax, but same concept. More community maintained than FireHOL, but takes longer to pick up. Shorewallis what I currently use. Its documentation is extensive, and its configuration format is tabular. It took me about an hour and a half to understand all the files needed (6) to get a working firewall/gateway configuration running. It's quite powerful. TIP: The man pages for the different config files are REALLY helpful! All of these load firewall configurations from a config file. Very effective, easier to use than iptables straight up, and (in my opinion) easier to use and manage than ufw. Other:
|
||||
|
|
