Secure your OOB!

As anyone who has had to work with remote datacenters or remote offices will tell you, you can never have too much OOB (Out-Of-Band) access.  Whether it be because you’ve fudged an ACL on a firewall or fat-fingered your route filtering, some form of remote access to your network devices comes under the heading of “bacon saver”.

A terminal server doesn’t necessarily have to be a dedicated device: as many network engineers know, a Cisco router equipped with some manner of async card makes a fairly basic but serviceable terminal server.  I’ve used both 2800 and 2900 series routers equipped with HWIC-8A and HWIC-16A modules at work, while my home lab uses a 2600XM (which does double duty as one of the “BB” routers in the IPexpert topology) with an NM-16A.  I’ve then equipped these devices with some kind of alternative network access – sometimes an old-school analog dialup or ISDN connection, other times a cheap ADSL connection – so that you can still get access to the site to troubleshoot when all other routes to the site are down.

One of the problems with this kind of setup (apart from the monstrosity of the green “octopus” cables that Cisco insists on still using) is making sure that such a setup is secure.  A device that gives console access to all your network devices needs to be treated the same way as the physical door to your datacenter – lock it, and lock it good!

There’s a number of good steps that can be taken to improve console security.  Firstly on the devices you are accessing via the terminal server:

• Make sure that you apply the same AAA policies that you would use for VTY (i.e. network) access on the console.  If you’re using RADIUS/TACACS+, use that on the console too.  If you have limits on logon attempts, apply that to the console too.
• In a similar vein, make sure that you have an exec-timeout configured on your console.  If you get disconnected from the terminal server while logged in to a serial line, your session will still be active; anyone else who connects to that line on the terminal server will be able to pick up your logged-in session and anything they do will be performed (and potentially logged) as if you were in front of the keyboard.  An exec-timeout will ensure that if you do get disconnected, or if you forget to log out of the device, that your session will not hang around long enough to be a liability to you.
• Remember, just because you have a terminal server there is no excuse for not securing the devices themselves.  A terminal server is very easily bypassed if physical access is gained to the datacenter.

Now for the terminal servers:

• Configure SSH on the line (“transport input ssh”).  With SSH you can still access individual lines directly – just use “<username>:<line>” as the username when you log in (for example: ssh -l jon:18 10.1.1.1 is equivalent to telnet 10.1.1.1 2018). There’s not many (if any) good reasons for keeping telnet enabled these days.
• Apply an access-class to the terminal server vty and async lines.  This will reference an ACL that specifies which hosts can SSH to the terminal server – limit this to your management subnet or jump boxes.
• If you make your terminal server accessible over the Internet (I’ve sometimes used a cheap DSL connection to provide OOB access), make sure to secure it appropriately. Configure CBAC or ZBFW on the router and consider using a IPSec VPN for access.
• Likewise if you’re still using analog dial or ISDN to access your OOB devices, make sure you secure this method of access too. Configure callback as well – it’s one more layer of security between you and the bad guys.

So in conclusion – Out-of-Band access is a great tool to have at your disposal – just make sure that access is only provided to those who need it.