> > > 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.
There are a number of script kiddy tools that only check port 22 for ssh. Moving to a different port is an effective tool aginst that threat. The tools are basicly drive by hacking. Send a port with user id "bob" with password "egale1" to port 22, wait a bit and try something else. Not being on port 22 helps with the odds a great deal and since any password guessing is based on random odds, anything you do to increase those odds helps a great deal. If something is listening on port 22, then a high port is less liekly to get hit so its the odds game and if you have something listening on 22 that will log attempts, you have an early warning system that something is playing games that should not have happened. As far as keys vs passwords, keys have resulted in far more high value compromised systems than passwords from what I've seen. I figure this is mostly a result of openSSH not having the option to require both keys and a password (which is not the same as a password protected key). Every tool that guesses ssh passwords and does anything once it logs in also has a payload to hunt for other hosts via keys too and many of them can try passphrases on protected keys which they can do much faster than trying remote systems. If your using keys, make sure they are password protected but keep in mind that if someone is far enough into a bastions host that has keys to your router, there is a good chance they can install a keylogger to grab passwords too. -tim _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
