[j-nsp] Changing SSH port on EX switches, M routers

[Kevin Oberman]

> From: "Stefan Fouant" <sfouant at shortestpathfirst.net>
> Date: Sun, 3 Apr 2011 21:27:06 -0400
> 
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> > bounces at puck.nether.net] On Behalf Of Kevin Oberman
> > Sent: Sunday, April 03, 2011 7:50 PM
> > 
> > 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.
> 
> While I completely agree with all of the points, there is such a thing as
> taking things too far... to the point where security actually becomes an
> encumbrance and hinders normal operations...
> 
> I once worked for an employer that had the most bizarre and overly complex
> process for accessing devices - they required everyone to log into a VPN
> Concentrator (regardless of being remote or at the corporate location).
> From there they required SSHing into jumphosts, and then finally from the
> jumphost you could SSH into your given device.  The VPN, jumphosts, and the
> end-devices were all using two-factor authentication (SecureID).  While this
> represented probably one of the most secure environments I've ever worked
> in, logging into multiple devices during firedrills was a real PITA to say
> the least... 

As with any security system, you need to trade off the benefits versus
the costs. Aside from procurement and training costs, theer are
on-going maintenance costs and loss of productivity due to the
implementation.

FWIW, the system we use is quite straight-forward. It does require a
login to a bastion host with the SmartCard token followed by access to
the routing asset, also via SSH. IT really means:
$ ssh bastion1.es.net (not a real node name)
$ ssh chicago-router-1

You better have more than one bastion host and they need to be as
diversely located as possible in your network footprint.

The most common key-based attacks depend on stealing a private key,
usually with the pass-phrase. With the tokens, this simply odes not
work, making public key access pretty strong.

We have been using this system for over two years with minimal
operational impact and no cases where access was unavailable except when
tokens were physically damaged or forgotten.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751