Re: server security

[Tracy Reed <treed () ultraviolet org>]

On Wed, Jun 20, 2012 at 04:44:57PM PDT, Alex Dolan spake thusly:
> One tip I have is to set SSH to a port other than 22, I don't need to

I tried this once upon a time and very quickly found that operationally it was
just a real pain in the neck. Most everyone who has more than a few machines or
a few users seems to go through this stage. Everything has to be configured to
use the non-standard port and especially when you have lots of people and lots
of servers involved it adds a whole lot more work and troubleshooting. It just
isn't worth it.

For my external-facing ssh servers I implement several controls to mitigate the
fact that everyone can hit the ssh port:

1. Require key auth. Do not accept passwords. "PasswordAuthentication no" in
   sshd_config.

2. Disallow root login with "PermitRootLogin no" in sshd_config.

3. Run fail2ban to cut down on scanner traffic. Since they couldn't possibly
   brute force a password since passwords are not accepted anyway this mostly
   just cuts down on log traffic.

4. Where applicable, restrict what IPs can connect to ssh using iptables. I
   don't do this for my external facing bastion hosts since I never know for
   certain from where I may need to connect but I do this for my internal
   network bastion hosts which I know I will always be connecting to from
   certain IPs.

5. Have written into the security policy (which every employee receives a copy
   of and signs a form saying they have received, read, and understood the
   policy, this is required by PCI-DSS among other things) that all ssh private
   keys will be encrypted with a  passphrase and that the passphrase will be
   chosen properly per the strong passphrase rules also in the security policy.

I find this to be the far better way to go.

-- 
Tracy Reed

Attachment: _bin
Description: