[j-nsp] Changing SSH port on EX switches, M routers
Tim Hogard
thogard at abnormal.com
Sun Apr 3 21:11:21 EDT 2011
>
> > Date: Sun, 03 Apr 2011 13:12:54 -0700
> > From: Joel Jaeggli <joelja at bogus.com>
> > Sender: juniper-nsp-bounces at 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
More information about the juniper-nsp
mailing list