Ask YC: Securing your servers?
18 comments
I'm not the best person at this, but I do the following on any machine I deal with which does not sit behind a firewall:
1. Disable root logins via ssh (as noted above by bbb).
2. Move ssh port from port 22 to something nonstandard. According to my logs, the number of idiots who try brute-force attacks on my machines dropped from 4/day to 0.
3. Put an iptables script into /etc/init.d and make sure it runs on startup at the normal multiuser run levels (on Debian, the command is something like /sbin/update-rc.d, but I don't remember exactly). I looked into more sophisticated firewall packages which generate iptables rules, but found them rather complicated, and probably overkill (YMMV). I essentially blocked all incoming traffic except on the nonstandard ssh port and ports 80 and 443.
Services which use ports other than 80, 443, and ssh should run on a privately routed network, or, at minimum, on a separate network interface with draconian access rules. iptables is pretty easy to use once for this stuff you get the hang of it.
1. Disable root logins via ssh (as noted above by bbb).
2. Move ssh port from port 22 to something nonstandard. According to my logs, the number of idiots who try brute-force attacks on my machines dropped from 4/day to 0.
3. Put an iptables script into /etc/init.d and make sure it runs on startup at the normal multiuser run levels (on Debian, the command is something like /sbin/update-rc.d, but I don't remember exactly). I looked into more sophisticated firewall packages which generate iptables rules, but found them rather complicated, and probably overkill (YMMV). I essentially blocked all incoming traffic except on the nonstandard ssh port and ports 80 and 443.
Services which use ports other than 80, 443, and ssh should run on a privately routed network, or, at minimum, on a separate network interface with draconian access rules. iptables is pretty easy to use once for this stuff you get the hang of it.
This is great advice. I will simply add one more thing (and two bonuses):
4. Disable password authentication for SSH and use a public/private key. Of course, use a good password on the private key.
5. (bonus) keep the installed software to the bare minimum. Less software, less bugs.
6. (extra bonus) look apache's mod_security, it's an application level firewall (filters requests to the application, so, for example, you can filter SQL injections or invalid characters before they reach your app).
4. Disable password authentication for SSH and use a public/private key. Of course, use a good password on the private key.
5. (bonus) keep the installed software to the bare minimum. Less software, less bugs.
6. (extra bonus) look apache's mod_security, it's an application level firewall (filters requests to the application, so, for example, you can filter SQL injections or invalid characters before they reach your app).
One absolute rule for any *nix-based server:
In /etc/ssh/sshd_config, disable root logins:
PermitRootLogin no
Even if you think your password ist strong. This will stop a majority of the brute-force password-guessing attacks. For extra credit, install denyhosts as well. It has stopped a _lot_ of bad guys trying to brute-force my servers.
In /etc/ssh/sshd_config, disable root logins:
PermitRootLogin no
Even if you think your password ist strong. This will stop a majority of the brute-force password-guessing attacks. For extra credit, install denyhosts as well. It has stopped a _lot_ of bad guys trying to brute-force my servers.
You might also want to use:
AllowUsers user1 user2...
And it's probably best to disable password logins and use keys instead (http://www.google.com./search?hl=en&q=ssh+authorized_key...).
AllowUsers user1 user2...
And it's probably best to disable password logins and use keys instead (http://www.google.com./search?hl=en&q=ssh+authorized_key...).
More important is to routinely rotate strong root passwords. What most people neglect to mention, when denying root access to an SSH server, is that people then login with a second account, (you still need ssh), and then su - to root. So, all you've really done is moved the difficultly in logging onto the server from the root account, to the secondary account+root account. Your security is now based on the strength of that bi-pair of passwords. As others have mentioned, moving logins to RSA keys (very easy) is probably a better approach.
http://articles.slicehost.com/2007/11/6/ubuntu-gutsy-setup-p...
I like the Slicehost guides to getting a server up and running relatively safely. The link has some good basic server hardening tips to start you off.
I like the Slicehost guides to getting a server up and running relatively safely. The link has some good basic server hardening tips to start you off.
1) Only allow login by private key pair and not by password (you don't have to disable root login then)
2) Only run the minimum amount of services.
3) Don't give anyone else access to the system. (root exploits) Also be cautious if you are running some freely available software (such as phpbb). When a security hole is found, an attacker could deploy code on your machine resulting in a denial of service attack against other internet users, or in worst case, compromising your machine with a root exploit.
4) If a security exploit is found , update! If your server got compromised, make a fresh install.
2) Only run the minimum amount of services.
3) Don't give anyone else access to the system. (root exploits) Also be cautious if you are running some freely available software (such as phpbb). When a security hole is found, an attacker could deploy code on your machine resulting in a denial of service attack against other internet users, or in worst case, compromising your machine with a root exploit.
4) If a security exploit is found , update! If your server got compromised, make a fresh install.
I'm no expert, but I'd start with iptables, snort, denyhosts, bastille, nessus, nmap, etc
There have been a number of good app-specific recommendations below, but I think there are some more general things to keep in mind, too:
#1: Keep your system up-to-date. Your most likely entry vector is a perfectly legitimate service like Apache or OpenSSH (or even worse, some PHP application) being cracked 'cause you never installed a critical security patch.
#2: Run different services as different users. There's no reason for your Mongrel listeners, cron jobs, reverse proxy, and god knows what else to run as the same user. Basic uid/gid partitioning is at the core of good POSIX security.
#3: Never, ever trust a public web application or server with total access to your data. Use your database server's access controls to limit admin-level access, and consider running your load balancer, public applications, and admin tools on separate hosts.
#4: Find ways to prevent password storage, entry, and checking on your application servers. Read up on and understand Kerberos, even if you aren't going to use it: it's the industry standard for an authentication system that doesn't require clients to expose their password to servers.
#1: Keep your system up-to-date. Your most likely entry vector is a perfectly legitimate service like Apache or OpenSSH (or even worse, some PHP application) being cracked 'cause you never installed a critical security patch.
#2: Run different services as different users. There's no reason for your Mongrel listeners, cron jobs, reverse proxy, and god knows what else to run as the same user. Basic uid/gid partitioning is at the core of good POSIX security.
#3: Never, ever trust a public web application or server with total access to your data. Use your database server's access controls to limit admin-level access, and consider running your load balancer, public applications, and admin tools on separate hosts.
#4: Find ways to prevent password storage, entry, and checking on your application servers. Read up on and understand Kerberos, even if you aren't going to use it: it's the industry standard for an authentication system that doesn't require clients to expose their password to servers.
1. Expose the absolute minimum number of services (and even then only software with a good security reputation).
2. Lock them down as much as possible in configuration and access (for example: use iptables to restrict acces to only your home/office where possible).
3. Apply vendor security updates as quickly as possible (subscribe to mailing lists).
4. Remotely backup your data.
5. Hope for the best.
2. Lock them down as much as possible in configuration and access (for example: use iptables to restrict acces to only your home/office where possible).
3. Apply vendor security updates as quickly as possible (subscribe to mailing lists).
4. Remotely backup your data.
5. Hope for the best.
> 1. Expose the absolute minimum number of services (and even then only software with a good security reputation).
Perform a minimal install of your operating system then source compilation of latest services, with minimal features enabled. It is possible to compromise this configuration but it harder because there are less dormant features to exploit and it doesn't utilise widely used binaries.
Perform a minimal install of your operating system then source compilation of latest services, with minimal features enabled. It is possible to compromise this configuration but it harder because there are less dormant features to exploit and it doesn't utilise widely used binaries.
Keep your software all up to date. For an example, I've seen an old version of a open source calendar be used to send 30,000 spam emails from a server.
Software like Fanstasico can keep your software automatically updated across user accounts.
Software like Fanstasico can keep your software automatically updated across user accounts.
Ingress and egress packet filtering ( http://en.wikipedia.org/wiki/Egress_filtering ). Remove default route on all internal servers.
I have found Solaris, being "weird" and different from Linux, results in less attacks from bots. You can run "netservices limited" and it will turn off almost everything except ssh.
1)Limit SSH logins to specific users
2)Get a proper /etc/sudoers
3)Use IP tables to limit SSH connections to trusted IP's/networks. Setup a port knock if you roam around a lot.
4)Read your daily logwatch
5)Turn off ports/services that are not in use (this is somewhat less necessary with a halfway decent iptables setup)
6)Use SSH keys instead of passwords!
7)Log to a syslog server that is highly secured as well
8)Run a nessus scan on your box regularly
9)Minimize how much specific information about your underlying OS various services display
2)Get a proper /etc/sudoers
3)Use IP tables to limit SSH connections to trusted IP's/networks. Setup a port knock if you roam around a lot.
4)Read your daily logwatch
5)Turn off ports/services that are not in use (this is somewhat less necessary with a halfway decent iptables setup)
6)Use SSH keys instead of passwords!
7)Log to a syslog server that is highly secured as well
8)Run a nessus scan on your box regularly
9)Minimize how much specific information about your underlying OS various services display
Anyone use things like AppArmor? I see it routinely preventing attacks on some of the older software we run. I almost wouldn't think of running a server without something like it.
OpenBSD
It may seem flippant to just say OpenBSD but it's an awesome piece of software. I tend to deploy FreeBSD for historical reasons but I totally respect OpenBSD for it's complete and utter no nonsense approach to everything.
FreeBSD comes pretty locked down but OpenBSD is locked down as tight as a gnats arse. It's pretty safe to say that if your OpenBSD server is compromised it's something _you_ have done rather then something _you_ have NOT done. It's a good starting point.
FreeBSD comes pretty locked down but OpenBSD is locked down as tight as a gnats arse. It's pretty safe to say that if your OpenBSD server is compromised it's something _you_ have done rather then something _you_ have NOT done. It's a good starting point.
Just installed Denyhosts. It immediately blocked 6 ip addresses. Seems to be working just fine. Nice tool.
this isn't an app realted but equally important...i think. i put everything behind a deployed firewall and layer3 manged switch. cisco plus 'ios' is good hardware solutions. run nagios for upkeep etc...
Read Hardening Linux.
Yes. And after you do, realise that the process of hardening a base Linux server install takes more than 15 minutes. Linux is not a "silver bullet" for security right out of the box.
deny by default and trust only people that need to know
What do you use? What wouldn't you ever use again? Any absolute rules that you force yourself to follow before even bringing your server online?
Thanks!