2/28/2002 -- It's tough enough to stay current with everything you need to do to keep your network running well -- never mind keeping up with security information for every single piece of hardware and software in the enterprise. What's an internetwork administrator to do? In this article, I've pulled together five ways you can prevent "vulnerability creep" through your Cisco devices.

Tip #1: SSH Whenever Possible
A quick and easy way of accessing a Cisco device for administration is to Telnet. Unfortunately, Telnet sends everything in clear text. Username? Clear text. Password? Clear text. This sounds like we're using G.711. Fortunately, some Cisco devices aren't limited to just Telnet.

SSH is the Secure Shell. It started life in the Unix world and still spends most of it there, although there is support for Windows and Macintosh devices. It started as a free utility, but it seems that the developer started getting the idea that he could make money off it so with each release the licenses got more restrictive. Finally, members of the open source movement started modifying some of the earlier versions. The result is that the "official" SSH is a commercial product, but there are various open source versions available as well.

Cisco has implemented SSH as an alternative to using Telnet. Telnet is an inherently insecure method of transferring information yet highly secure administration tasks are being done with it. Cisco has stated that it has no plans on implementing SSH v2. It implemented SSH v1 because IPSec had yet to be finalized and needed to offer a secure method of administration.

Enabling SSH involves setup similar to that required to allow the router to use digital certificates in IPSec. Before starting, make sure that you can authenticate to the router. There's nothing worse than spending 30 minutes troubleshooting the wrong part of the configuration. Once that is done, a public/private key pair needs to be generated. Before this can be done, the domain the router resides in must be established.

(config)# ip domain-name abccompany.com
(config)# crypto key generate rsa

The first line tells the router it is a member of the domain abccompany.com while the second line tells the router to start generating two pairs of keys. When doing this, you will need to say how big the keys should be. Make sure they are the same size on the client and the router. The bigger the key, the longer it will take to create. On a 2500 series router, a 512 bit key should take about 45 seconds to create.

The following commands are SSH administration commands:

(config)# ip ssh time-out 30
(config)# ip ssh authentication-retries 2
(config-line)# transport input ssh

The first line gives a time limit for an idle timeout in minutes. Make it as short as you can. There's no point to encrypting a session then leaving it running while you go to lunch. The second command limits how many retries someone has to authenticate. The third line, done in VTY configuration mode, limits the type of connection that the VTY port is able to receive. In this instance, it says that the VTY port can only accept SSH sessions.

A requirement for using SSH is that there be an encryption-capable IOS image on the router. The router must be capable of encrypting traffic using DES or 3DES. Many SSH clients have the ability to encrypt using other algorithms. The Cisco router can only encrypt SSH sessions using DES and 3DES. The SSH configuration guide for IOS version 12.2 can be found here.

Other Cisco devices can also run SSH, including the PIX firewall and some Catalyst switches. IOS code from v12.0 and v12.1 has been found to have some significant flaws in the SSH code. If you intend on enabling this in a secure environment, then the devices involved should be using IOS version 12.2

SSH clients are easy to find for the various flavors of Unix, especially BSD. Versions for Windows have been a bit harder to find though. One of the more popular free clients is FiSSH available at http://pgpdist.mit.edu/FiSSH/index.html. It does seem to move around a bit so if this link stops working, search the Internet for "windows ssh".

Tip #2: Look at G.729 for VoIP
When people think about sniffers, they normally think about traffic that can be read. If you sniff a binary file that's going across the wire, what do you see? I see stuff that I can't make heads nor tails of. We haven't had to worry about this too much in the past because it was usually too difficult to figure out the encoding scheme used by the binary file in order to put it back together. Voice traffic isn't like that though.

Spying on other people is a human failing. From politics at work to gossiping over the back fence to reading sleazy tabloids, everyone is a little nosy at some point in their lives -- and there are lots of people who are more than a little. Listening in on a conversation can be a very strong urge. Unfortunately, there's at least one tool available on the Internet that can capture an IP telephone call and save it to a WAV file. Fortunately, it's not a wizard-driven Windows utility that just anyone can operate.

Still, voice traffic should be encoded. There are several ways to encode voice traffic. Called codecs, each method provides for a different amount of compression. Compression is good for reducing overhead but it can reduce voice quality.

The clearest conversation uses the G.711 codec -- which is, functionally, no compression. The rule of thumb is that if you have the bandwidth and want the sharpest conversation possible, use G.711. This is often the rule in LANs.

Because there isn't any compression, the data that flows across the wire is the conversation. If someone could capture the packets, a trivial exercise, they could be strung together, run through a G.711 process and popped out as sound file. Does the CEO really need someone listening in on the phone call regarding outsourcing? How about the phone call between you and the recruiter?

Rather than using G.711, examine a codec called G.729. It compresses pretty tightly but leaves the conversation almost as clear as G.711 does. Another option is to provide for encryption between the end points. Each of these methods does provide for more latency than pure G.711, but they are also more secure.

Tip #3: Use Time-Based Access Lists
Once you have the lines of communication to the devices secured, you may want to start thinking about what can be accessed and when. A time-based access list will only be applied during certain times of the day, days of the week or times of the year. It can be applied hour by hour or day by day. Needless to say, accurate timekeeping becomes important when using this feature.

This configuration begins with the global command, time-range [name]. Once in the time range configuration mode, you need to start configuring the time ranges you wish the filter to apply to. This mode only configures the times involved -- you do not configure the actual traffic filter here.

There are only two types of time ranges that can be used. A periodic range is one that reoccurs. You can configure a filter to reoccur every weekend by using the Periodic statement. The other type is Absolute. When using this option, the filter applies between these two times and does not repeat unless a different line says it should. An example would be to filter all traffic from 10 a.m. on June 6th, 2002 through 1 a.m. June 8th, 2002. It is possible to use both types together in a time range configuration. An example would be a school allowing certain types of traffic from June 15 through Aug. 15 and from 4 p.m. until 7 a.m. weekdays and all day on weekends.

Once the time range has been configured, it needs to be referenced in the access list statement lines. A line is configured and will only be applied during the times that the time range dictates. The way this is done is access-list [ACL number] {deny | permit} protocol any any [log] [time-range time-range-name].

A sample access list allowing Web access with appropriate time range follows:

Time-range Allow-HTTP
Periodic weekdays 18:00 to 08:00
Periodic weekdays 11:30 to 13:00
Periodic Friday 18:00 to Monday 08:00

Access-list 101 permit tcp any any eq www time-range allow-http

This feature first came out in version 12.0(T) and that is still where you can get the most complete documentation. Find it here.

Tip #4: VLANs Work on More than Physical Ports
The basic access switch provides access to the network for user PCs. Because these devices don't need to provide a lot of utility, they often aren't as flexible as the enterprise-level switches. Of course, they aren't as expensive either. The most popular access switches used in Cisco-centric networks are the 1900s, 2900s and the 3500s. What's used depends on the hardware requirements, but they are all workhorse switches without much in the way of layer 3 functionality.

Each switch supports IP addressing for management purposes as well as VLANs to control broadcast domains. A typical access switch has most of its ports set on one VLAN simply because most of the users accessing those ports will be doing similar jobs. Those users will be on the same VLAN; so when that department does the quarterly "musical cubes," the switch doesn't need to be touched. The error here is thinking of VLANs as something that only work on physical ports.

Each switch also has a management interface that can have a VLAN associated with it; by default, it uses VLAN1, the same VLAN as every other interface. In a small environment, it is not unusual for every user to be on the same VLAN. Here, a switch is used to contain collisions. There aren't enough broadcasts to cause a problem.

Whenever someone has access to a network device, there is always the potential for the device to be broken into. The simplest way to stop someone from Telnetting into a switch is to filter requests from IP addresses that have no business accessing that device. Placing all of the switch management interfaces on one VLAN allows for easy filtering at the router. By giving all of the switches an IP address on the 192.168.3.x network, we can filter out inappropriate attempts with just a few access list lines. The best thing is that since only management interfaces reside on this network, we won't be slowing down other types of traffic with unnecessary lookups.

• If the switch IP address is 192.168.3.56 and all of the computers in the IT department reside on the 192.168.7.x network, we should do something like:
• Make sure the management VLAN is not shared by data traffic. In this case, set the VLAN to 99.
• Go over to the router and create a sub-interface for VLAN 99. I prefer interface fastethernet 1.99. Do a "no shut" on the interface.
• Build an access list for the interface. The one shown here will allow all traffic from anywhere but will stop telnet traffic from anywhere but an IT machine.

1. access-list 101 permit tcp 192.168.7.0 0.0.0.255 192.168.3.0 0.0.0.255 eq 23
2. access-list 101 deny tcp any any eq 23
3. access-list 101 permit ip any any

• Apply the access list to the interface. Because normal data traffic does not cross sub-interface 99, access list checking won't slow the traffic.

Tip #5: Permit Lists for Layer 3 Switches
A layer 3 switch is one that can use layer three information in its switching tables. Layer 3 and layer 4 switches allow for more flexibility as well as designs that require content switching and load balancing. Typical layer 3 switches in the Cisco world include the 4000 series, the 2948G and the 2980G.

Just because the switch is able to understand some layer 3 information doesn't make it a router. A router will exchange information with other routers in an effort to learn about remote networks. A switch does not do any of that. Instead, it is able to learn about higher layers by the traffic that passes through it.

A layer 3 switch is able to recognize that there are differences in the types of traffic. This allows the administrator to configure something called a Permit List. This list will permit certain types of traffic from certain IP addresses to access the switch management functions. This is not an access list but the function is similar -- just more limited.

The switch recognizes that there are several ways it can be configured, including Telnet and SNMP. Chances are, you don't want just anyone to be able to access the switch and configure it. While setting up access lists will work, the cleaner method is to let each switch do its own filtering on an as-needed basis.

The base command for the permit list is: Set ip permit ip_address [mask] [all | snmp | telnet | ssh]. Determine what device or devices are permitted to access this device and permit them to do so. All others will be implicitly denied. There are three separate tables being configured with this command. The Telnet table is kept separate from the SNMP table. This allows you to configure a permit list that only permits authorized management stations to use SNMP and a different permit list for Telnet allowing different devices.

In order to turn this process on, use the command set ip permit enable [ssh | snmp | telnet]. You must specify which table is being activated. Just because the SNMP table is activated does not mean the Telnet table is turned on.

Other commands exist that can be used in conjunction with the permit list. SNMP can log unauthorized attempts and syslog can capture information as well. Cisco has a page describing the process and other options here.

Just the Beginning
These tips will go a long way to securing your organization. However, there's more out there -- and you may know about them. What are your favorite Cisco security tips? Post them below.

More articles by Eric Quinn:

• Data Protection 102: IPsec Implementation
• Data Protection 101: Understanding Encryption & IPsec Tunnels
• So, You Wanna Teach...
  
• CCIE Fundamentals: Network Design and Case Studies, Second Edition