Re: Hardening CentOS

On Thu, Jul 3, 2008 at 8:53 AM, Florin Iliescu <[email protected]> wrote:
> Helo,
>
> Can anybody help me with some procedures to secure a CentOS server? I am going to use it for receiving files over Internet with SFTP.
>
> Thank you,
>
> Florin
>
>
>
>
My personal pre-production check list includes as a default:

1. Don't connect the server to the net until all other steps are done.
2. Apply all vendor supplied patches/updates and devise a plan for
getting new updates in a timely manner.
3. Get yourself connected to a security email alert portal where you
can find out about new vulnerabilities that might affect you.  I
suggest bugtraq.
4. Stop/disable all unnecessary services
5. Do some research into SELinux and bastille to see if they can be of
some benefit in your specific situation.
6. Scan your system with a network security tool such as Nessus.  If
you're doing this prior to launching into production you'll have the
luxury of safely doing a penetrating test as opposed to a safer
non-penetrating test.  I'd suggest you let nessus down your server if
it can.  Better to know now than later.  If your summary report
doesn't come back all green, make sure you know why.

SSH/SFTP specific:
1. Ensure sshv1 is turned off (protocol 2 in your sshd_config)
2. Ensure that PermitRootLogin is set to 'no' in your sshd_config
3. Ensure that your SSH daemon chroot's (jail/sandbox) incoming
connections.  You don't want your users being able to traverse your /
filesystem.
4. If at all possible, run your service on a non-standard port.  This
suggestion is inevitably followed by outcry that this is security by
obscurity.  To which I would reply that no, this is security though
all and every means possible including, but not limited to, obscurity.
 In a nut shell, you can count on your SFTP server being pounded daily
by automated brute force attacks.  Moving the service off of port 22
will eliminate 90% of this traffic.  Given that these attacks are
largely based on the statistical probability that they will guess a
password on one of your account, side stepping the majority of such
attacks is only going to help you.  And then there's the fact that
this will hop the size of your auth logs to a fraction of what they
would otherwise be.
5. Use a restrictive shell for connections.
6. Turn off PubkeyAuthentication
7. Most importantly, manage your user accounts.  Don't be afraid to
implement a policy that locks accounts after N days of inactivity.