Access Lists

An access list provides the ability to block or permit traffic based on address, port number, and/or the concept of established communications. There is no awareness of upper-layer protocols, and thus protection against application-layer attacks is not available. A significant number of companies continue to use router access lists as the sole means of securing their networks. Yet, while such lists certainly belong in most security deployments, the access list itself is fairly limited.

One of the misunderstood components in an access list is the established keyword—there is no bona fide established bit or validation of sequence numbers. Rather, the established keyword requires packets to have the ACK (acknowledgment) bit set. The acknowledgment bit is set on the second packet in the TCP three-way handshake that starts all sessions, as well as on all subsequent packets. The router presumes that any inbound packet with an ACK bit is in response to a datagram sent by the trusted station. One denial-of-service (DOS) attack made use of this characteristic—the SYNACK flood operated by sending a large number of packets to the target with both the SYN and ACK bits set. Most systems would overflow their buffers in servicing the traffic.

	The established keyword is used in a different context on the PIX firewall and should not be confused with the description in this section.

	The FIN (finished) bit will also pass the established filter.

Thwarting address spoofing is another common use of access lists. This technique prevents IP addresses outside the network from entering and possibly taking advantage of permissions granted to internal resources. To configure this solution, the administrator blocks all internal addresses from being the source address on the external interface.

Time-Based and Reflexive Access Lists

Two new kinds of access lists have been added to the most recent versions of the IOS. Time-based access lists provide designers with the ability to activate security policies based on the time of day or the day of the week. This is an interesting conflict in traditional security policies—normally anything that is not permitted is never permitted. Time-based lists alter this situation by allowing specific functions to traverse the router at certain times. These lists might be used to allow backups to run in the middle of the night from servers in the DMZ, for example. Unfortunately, this would also permit hackers to exploit the increased permissions in order to launch an attack.

There is little doubt that administrators will use time-based access lists. However, to do so without fully incorporating the feature with a security policy would be irresponsible.

Reflexive access lists go beyond the traditional “permit all established” access lists by incorporating reflexive technology. A reflexive list permits traffic only in response to a prior event—an originating packet from the internal network, for example.

Perhaps the best way to understand the operation of a reflexive access list is to consider the configuration used, which is shown in the following output:

In this example, the serial 0 interface is configured with inbound- and outbound-named access lists. The outbound filter denies ICMP and UDP traffic and then references the reflexive tcp traffic filter—a filter that permits the return of any TCP traffic that originates inside the network. This is similar to the established bit, but the advantage is that this permission exists only for 120 seconds or for the duration of the TCP session—a significant reduction in the amount of time a hacker might have to exploit the permission. Note that the default timeout value is 300 seconds, which applies to lost TCP sessions and connectionless UDP sessions. Reflexive access lists work with UDP traffic; however, the termination of the reflexive access list permission is based only on the timer.

Encryption

The concept of encryption is best exemplified by the childhood code games that most pre-teens play. These games send secret messages composed of offsets—for example, each letter may be three characters removed from the actual letter. Thus, the letter D might represent the letter A, and the letter Z would be represented with the letter C.

Obviously, such a simple code would be fairly easy to crack. In wartime, such codes incorporated garbage characters, floating offsets, and other techniques to provide additional protection. By World War II, these ciphers had become quite advanced and made use of simple computers that added additional randomness to the sequence. A famous Allied victory incorporated the cracking of a German code—a victory made possible only because a German officer transmitted the same message twice. By dissecting the pattern, the Americans and the British were able to build their own computer for decoding the secret messages.

With today’s computational power, the ability to encode and decode data streams is fairly simple, and a wide variety of methods may be employed. The majority of these methods incorporate the concept of a key, or password, and the number of bits used for the key directly relates to the potential security afforded by the encryption. A key is the base code used to calculate the encryption code. For example, the formula for my encryption code might be to add two and subtract one, but if I allow the user to define the initial number, the result should be different from those of other users (clearly this is a very simple example).

Recently, the United States government took steps to authorize the export of higher-security encryption keys to 128 bits. Prior to this time, export keys were restricted to 56 bits, and munitions laws governed the use of higher encryption key values.

	This text does not address specific technologies for encryption given the everchanging landscape of the encryption marketplace. However, it is clear that a standard will emerge and that at least 128-bit keys will be required to provide the required level of protection.