Configuring for Manageability, Part III

Peter J. Welcher

This month we complete our three-month theme of configuring a router for manageability.

Last month 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.

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:

ip domain-name foo.com

If one or more DNS servers are available, configure the router with their addresses:

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

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:

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:

tacacs-server extended

Then tell the router the address(es) of the TACACS servers:

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:

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:

tacacs-server last-resort password

Options for authenticating users before they can use certain commands at the router EXEC prompt.

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:

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:

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.

TACACS+

If you're interested in TACACS+, see my previous CiscoWorld articles, which can be found off of http://www.netcraftsmen.net/welcher .

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:

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

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.

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.

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:

config-register 0x2102

If you wish to slightly reduce LAN traffic, and are not in a DEC environment, turn off MOP:

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).

Summary

We've looked at a number of things you might want to configure into your router. Each in some way contributes to making your routers more manageable.

I hope this helps. If I've left your favorite configuration command out, I'm sure you'll let me know (please do)!

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .