Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Securing SSH Services - Go Blue Team!! - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Securing SSH Services - Go Blue Team!!

As the world of the attacker evolves and new attacks are developed (Red Team), people in the world of defense sees a matching evolution in recommendations for securing various platforms and services (Blue Team).  It struck me as odd that we don’t see a lot of “high profile” changes in advice for SSH, so I did some digging.

The go-to document that many of us use for SSH security is NISTIR 7966 (http://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf).  That has lots of great recommendations, and is dated October 2015, so it’s 2 years old as of this post.

There are some great OPENSSH recommendations published here at mozilla.org: https://wiki.mozilla.org/Security/Guidelines/OpenSSH.  The latest commit on that project was Oct 19, so just 11 days ago – that’s about as current as it gets.

However, lots of the devices we work with don’t give us access to the OpenSSH config, so there’s a lot of translation to match up guidance to the command interface of this or that device.  Bettercrypto.org hosts a paper that does just this.  https://bettercrypto.org/static/applied-crypto-hardening.pdf

For instance, let’s look at Cisco IOS routers – mostly because the configuration is so simple, and I see so many of them that have silly configuration “misses” on the security side.  Most guidance for Cisco IOS routers suggests that you force SSHv2, add an access-list to limit access, and then stop there.  That config sequence would look like:

crypto key gen rsa gen mod 2048        ! generate the SSH key

login on-failure log                   ! log failed login attempts
login on-success log                   ! log successful login attempts

 

ip ssh version 2                       ! force SSHv2 (SSHv1.x is easily decrypted)

ip access-list standard ACL-MGT        ! Create an ACL to limit access

  permit ip x.x.x.0 0.0.0.255          ! permit access from management VLAN

  permit ip host x.x.x.y               ! or permit access from specific management hosts

deny ip any log                        ! log all other accesses  (you can log the successful ones too of course)

 

line vty 0 15                          ! note that some newer platforms have more than 15 VTY lines !!

transport input ssh                    ! restrict to SSH only (no telnet)

access-class ACL-MGT                   !  apply the ACL

However, combining advice from the various documents above, naming the key, increasing the key size and setting a client minimum all make good sense – this changes our config commads to:

crypto key generate rsa modulus 4096 label SSH-KEYS     ! name the keys.  This makes it easier to rotate keys without a "gap" in protection

ip ssh rsa keypair-name SSH-KEYS

ip ssh version 2

ip ssh dh min size 2048                                                                              ! set a minimum standard for a client to connect with (helps prevent downgrade attacks)

ip access-list standard ACL-MGT

 permit ip x.x.x.0 0.0.0.255                 ! permit access from management VLAN

 permit ip host x.x.x.y                      ! or permit access from specific management hosts

deny ip any log                              ! log all other accesses  (you can log the successful ones too of course)

 

line vty 0 15                                ! note that some newer platforms have more than 15 VTY lines !!

transport input ssh                          ! restrict to SSH only (no telnet)

access-class ACL-MGT                                                           ! apply the ACL

A Cisco ASA gives us a bit more control, where we can set the key exchange group.

crypto key generate rsa modulus 4096

ssh version 2

ssh key-exchange group dh-group14-sha1

 

ssh x.x.x.y m.m.m.0 inside            ! limits SSH access to specific hosts or subnets. (note the ACL is a subnet instead of a wildcard approach)

(I’d recommend NOT to enable ssh to any public interfaces – use a VPN connection, preferably with 2FA, then connect to the inside interface).

Rather than disable telnet on an ASA, you simply don’t grant access to it – be sure that there are no lines similar to:

telnet x.x.x.y m.m.m.m <interface name>

in your configuration.

Note that both the Cisco IOS platform and Cisco ASA support key based authentication in addition to standard userid/password authentication.  The advantage to this is that you can’t easily brute-force a key-based authentication interface – so that’s a very (very) good thing.  The disadvantage is that if an admin workstation is then compromised, the attacker is in the “all your keys are belong to us” situation – all they need is the keys, and the keys are usually helpfully named with the IP address or hostnames of the targets.  Or if you happen to be a vendor who’s put keys into a firmware image, that would mean all instances of your product everywhere are easy to pop.

This covers off some basic SSH configuration, but what about auditing this config?  (Stay tuned)

===============
Rob VandenBrink
Compugen

Rob VandenBrink

458 Posts
ISC Handler
Also, off-topic but related:

And to not forget, TLS guidance is here:
https://tools.ietf.org/html/rfc7525#page-5

this was mostly due to absolute retirement of SSL as well as deprecation of various crypto elements.
Brett

15 Posts Posts
Ab-so-lutely!
That's an issue to keep track of and audit where you must have HTTPS (ASA and Palo Alto firewalls, wireless controllers and so on for instance)
On a router, I normally disable https and http, there's not usually a lot of advantage to a web interface to those:
no ip http server
no ip http secure-server

The API's for these are usually over SSH as well (which steer us back towards using keys for SSH in many cases)

With us all gearing up towards SDN, we're starting to see web based RESTful API's against what would traditionally be a router or a switch, so as this marches out, so will the TLS/SSL downgrade risks.
Rob VandenBrink

458 Posts Posts
ISC Handler
Thanks for the post, very usefull
camp0

4 Posts Posts
I am concerned about the access list in the sample configuration:

> ip access-list standard ACL-MGT ! Create an ACL to limit access
> permit ip x.x.x.0 255.255.255.0 ! permit access from management

Cisco IOS uses "don't care bits" in the acl. So if your intention was to only permit from a /24 then you'd want something like this:

permit ip x.x.x.0 0.0.0.255

Depending on platform, the original ACL listed might grant access to every IPv4 address on the internet ending in .0.

Too add to the confusion, ASA uses normal netmask format.

Fortunately this confusing syntax did not get passed on to Cisco's IPv6 configuration.
Anonymous

Posts
Thanks very much! I updated the ACLs in the story, and made that note in the ASA config snip.
Good catch!
Rob VandenBrink

458 Posts Posts
ISC Handler
Nice post, thanks!

I also add archiving so that I can see what changes have been made:

archive
log config
logging enable
logging size 1000
exit
exit

show archive log config all
idx sess user@line Logged command
1 1 mikehubbard@vty0 |interface range GigabitEthernet1/0/1 - 23
2 1 mikehubbard@vty0 | no switchport trunk allowed vlan
3 1 mikehubbard@vty0 | interface GigabitEthernet1/0/1
4 1 mikehubbard@vty0 | switchport trunk allowed vlan 20,30,40
Anonymous

Posts

Sign Up for Free or Log In to start participating in the conversation!