Re: Hardening CentOS



On Thu, Jul 3, 2008 at 8:53 AM, Florin Iliescu <iliescufm@xxxxxxxxx> 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.



Relevant Pages

  • Re: Integrated security - why not?
    ... Let me explain why we seldom use Integrated Security for Internet asp.net ... how could we setup accounts for them? ... !server to the public network with services such as SQL Server (remember SQL ... The DC at the ISP is not for our own use. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Integrated security - why not?
    ... The DC at the ISP is not for our own use. ... very much wanted to go down the fully integrated security route. ... > FSMO roles on disjoined server), but I would advise against that. ... > and create local accounts and then recreate all security. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Integrated security - why not?
    ... FSMO roles on disjoined server), but I would advise against that. ... and create local accounts and then recreate all security. ... server behind a firewall at your ISP and just publish HTTPS service. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • security-basics Digest of: get.123_145
    ... VPN to ASP a security risk? ... Re: Multiple IPSec tunnels? ... Subject: Security NT Server ... VPN to ASP a security risk? ...
    (Security-Basics)
  • << SBS News of the week - Sept 26 >>
    ... And he points to the info you need to put the file on the server in the ... at the network perimeter. ... The Symantec Firewall/VPN and the Gateway Security ... by the firewall at risk. ...
    (microsoft.public.backoffice.smallbiz2000)