> Date: Sun, 03 Apr 2011 13:12:54 -0700 > From: Joel Jaeggli <joe...@bogus.com> > Sender: juniper-nsp-boun...@puck.nether.net > > the normal approach is to have the control plane policing policy limit > where you can ssh from rather than obfiscating the port number. From my > vantage point the ability to forward traffic up to the control plane is > the problem not which port it happens to be pointed. while you could > rate limit it with a policer that seems like it's missing the point.
+1 1. Limit access to the ssh port to trusted hosts, preferably tightly controlled hosts that are dedicated to acting a bastions. No extra services running that might open vulnerabilities! 2. No passwords! Even if rules for 'good' passwords are followed, passwords are not nearly as strong as good cyrpto keys. (yes, I know about the Debian issue! That was so incredibly stupid that it still boggles my mind! I doubt that any Unix distro will ever do anything so incomprehensibly stupid again, but it's unwise to assume stupidity is growing less common. If in doubt, run openssh directly from openssh.org. they KNOW what they are doing! 3. Require two factor systems to further control access. We use SmartCard tokens to create and store the private keys. When working properly, it is not possible to get the private key off of the token and modern openssh contains support for PKCS11 which will work with SmartCards, though finding tokens that work with Unix in the US is a problem. This sort of control is vastly superior to playing games with the ssh port by which smart hackers will only be mildly disturbed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp