
Ask YC: Securing your servers? - thorax
What techniques do you use to secure your servers? I've had a lot of good luck with things like SuSE and AppArmor for my servers, but I'm curious if there are other Linux flavors (or other OSs) that have some solid security tools for surviving wild on the internet.<p>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?<p>Thanks!
======
gcv
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.

~~~
edu
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).

------
bbb
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.

~~~
dgr
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...](http://www.google.com./search?hl=en&q=ssh+authorized_keys)).

------
pius
[http://articles.slicehost.com/2007/11/6/ubuntu-gutsy-
setup-p...](http://articles.slicehost.com/2007/11/6/ubuntu-gutsy-setup-page-1)

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.

------
bluelu
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.

------
inklesspen
Read
[http://www.ranum.com/security/computer_security/editorials/d...](http://www.ranum.com/security/computer_security/editorials/dumb/)
Read it now.

------
tlrobinson
I'm no expert, but I'd start with iptables, snort, denyhosts, bastille,
nessus, nmap, etc

------
rcoder
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.

------
staunch
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.

~~~
xirium
> 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.

------
nweiner
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.

------
xirium
Ingress and egress packet filtering (
<http://en.wikipedia.org/wiki/Egress_filtering> ). Remove default route on all
internal servers.

------
patrickg-zill
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.

------
brk
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

------
thorax
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.

------
hs
OpenBSD

~~~
dazzawazza
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.

------
berryg
Just installed Denyhosts. It immediately blocked 6 ip addresses. Seems to be
working just fine. Nice tool.

------
dustineichler
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...

------
comatose_kid
Read Hardening Linux.

~~~
wyclif
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.

------
extantproject
deny by default and trust only people that need to know

