Configuring for Manageability, Part II
Last article we discussed route caching, the loopback interface, SNMP configuration, time and NTP, and using syslog to capture router console messages.
This month: converting names to addresses: host table and DNS. Then a couple of words about CDP and passwords. Central control of passwords across multiple routers or NAS’s brings us to XTACACS, with a brief nod to TACACS+. We’ll finish with some random related ideas on things you might want to configure into your Cisco routers.
Host Table
A host table may be configured into the router with the “ip host” command. I recommend doing this even if DNS is available, because Murphy’s Law says it won’t be available in a network outage.
1 2 | ip host new_york_router a.b.c.d e.f.g.h i.j.k.l ip host chicago_router a.b.c.g m.n.o.p |
Put at least your major routers and servers into each router, and keep this list updated as you add new devices. It’s well worth the effort the day your network goes down!
DNS
A router should be configured with the local domain name, even if DNS is not yet available:
1 | ip domain-name techsoftcenter.com |
If one or more DNS servers are available, configure the router with their addresses:
1 2 | ip name-server a.b.c.d ip name-server a.b.c.g |
If no DNS server is available, it is useful to turn off DNS name resolution with
1 | no ip domain-lookup |
This speeds response in case of router command typos.
CDP
The new Cisco Discovery Protocol is normally enabled. The information it collects (“show cdp neighbor details”) is available via SNMP. (CDP was the subject of a previous CiscoWorld article).
Leave CDP enabled, it may be very useful to future network management tools.
Passwords
Good passwords (hard to guess passwords) should be used where applicable. This includes SNMP read-write community string, enable password, console and AUX port password(s), and telnet vty passwords.
It is simpler to administer passwords, especially on access servers, using a central server mechanism, such as XTACACS or TACACS+, below. One-time passwords are valuable protection against password capture and re-use. Generally a mechanism such as the SecureID card is used for this, in conjuction with a form of TACACS.
The “service password-encryption” form of encryption is not secure, nor was it ever intended to be. I’ve heard there is a C program out on the Internet that breaks old-style encrypted passwords.
The new command to use is “enable secret”, which overrides any configured enable password. Thus minimal but reasonable password protection consists of:
1 2 3 4 5 6 7 8 9 10 11 | enable secret myEnableSecret enable password anotherSecret line console 0 login password xxxx line aux 0 login password xxxx line vty 0 4 login password yyyy |
XTACACS
I recommend you use XTACACS or TACACS+ for centralized control of access to routers and NAS’s (access servers). TACACS+ is the newer of these. The CiscoSecure product provides a GUI and supported TACACS+ daemon, but for a while XTACACS may be required for use with one-time password cards.
Start by turning on extended TACACS mode:
1 | tacacs-server extended |
Then tell the router the address(es) of the TACACS servers:
1 2 | tacacs-server host A.B.C.D tacacs-server host E.F.G.H |
Tell the router to use TACACS to authenticate enabled mode access, with the configured enable password as fallback if the TACACS server is inaccessible:
1 2 3 | enable use-tacacs tacacs-server authenticate enable enable last-resort password |
Similarly, if the TACACS server fails to respond, users may use a local password or the configured enable password to login to the router:
1 | tacacs-server last-resort password |
Options for authenticating users before they can use certain commands at the router EXEC prompt.
1 2 3 4 5 6 | tacacs-server authenticate connection tacacs-server authenticate enable ! if SLIP is to be authenticated: tacacs-server authenticate slip ! if CHAP is not used with PPP: ppp use-tacacs |
Options for logging what users do:
1 2 3 4 5 6 7 | tacacs-server notify connection tacacs-server notify enable ! if SLIP or PPP are to be used: tacacs-server notify slip ! if you care to log logouts (for connect time ! computation): tacacs-server notify logout |
And what EXEC connections do we want to use (X)TACACS to authenticate:
1 2 3 4 5 6 | line console 0 login tacacs line aux 0 no exec line vty 0 4 login tacacs |
If you don’t want Telnet (as on a firewall router), put “no exec” on the vty’s. If nothing is on the AUX port, “no exec” prevents people from connecting up and trying to log in.
PPP CHAP
Access servers should use CHAP or one-time passwords (SecureID, DES Gold) to control access to a network.
Telnet Access
It is a good idea to secure routers to only allow access from a list of acceptable network management stations. This makes it harder for a hacker to get into the routers. (It is also a minor nuisance in managing the routers, the usual security versus ease-of-use trade-off.)
Here’s an example:
1 2 3 4 5 6 7 | access-list 1 permit a.b.c.0 0.0.0.255 access-list 1 permit a.b.g.0 0.0.0.255 line vty 0 4 access-class 1 in login password xxx exec-timeout 5 0 |
The exec-timeout command specifies 5 minutes of idleness before you are automatically logged off. The default is 10. You can specify no automatic logout with “exec-timeout 0 0”. But then someone else may have enabled router access from a terminal you once logged onto. The cautious may wish to specify
1 | exec-timeout 1 0 |
Privilege Levels
The simplest approach if you have “operators” you don’t fully trust, is to realize that most show commands do not require enabled access to the router. If you want more control or granularity, look into the multiple privilege levels in the router. This can be used to make some commands unavailable to “users”, if you so choose, or to add to the commands available to non-enabled users. Or you can create intermediate levels of privilege, where some access to enabled mode commands is given, but not full access.
Miscellaneous
The following line disables IP source-routing, which is usually regarded as a security hole.
1 | no ip source-route |
If you feel the urge (need?) to configure “boot system” commands, always establish a fallback boot image from ROM. That way if flash is empty or some problem occurs, the router may be able to boot an older image from ROM.
1 2 | boot system flash slot0: boot system rom |
I generally prefer to NOT specify any boot system commands, and to set the configuration register to do the equivalent for me:
1 | config-register 0x2102 |
If you wish to slightly reduce LAN traffic, and are not in a DEC environment, turn off MOP:
1 2 | interface ethernet 0 no mop enabled |
It is generally unnecessary to alter the default buffers and buffer pools (buffers min-free, buffers max-free, etc.) Cisco would like to know about it if you do have to alter them, because they’re trying to make the right things happen automatically. If you do specify buffers commands, be aware that it can drastically affect the performance of your router.
Other Ideas
You might want to turn on access-list logging (to your syslog server).