Dynamic Packet Filtering and the Reflexive Access List

Many of the problems that face static packet filtering, the Cisco standard, and extended access lists can be alleviated by dynamic packet-filtering technology. The concept is that filters are built on-the-fly as needed and torn down after connections are broken.

Reflexive access lists are examples of dynamic packet-filtering technology. A criterion is set up on the outbound interface that watches defined connection types to the outside world. When the traffic returns, it is compared to an access list that was dynamically created as the outgoing traffic left the network.

For example, perhaps you have a client that has an IP address of 192.168.100.2 and have set up a reflexive access list to check for TCP traffic using the Telnet port. The reflexive access list would see the client sending the Telnet packet out the greater than 1023 port (let's say 1072 was randomly picked) to port 23 on some IP address (let's say 100.100.100.1) of a Telnet server. The reflexive access list would then generate an incoming access list based on this outgoing connection. It would take the outgoing connection

Client 192.168.100.2.1072 > telnet server 100.100.100.1.23

and reverse it into an incoming access list that permits traffic from 100.100.100.1 on port 23, to client 192.168.100.2 on port 1072, like this:

permit tcp host 100.100.100.1 eq 23 192.168.100.2 eq 1072

This dynamically generated list would be deleted after the connection was ended (a graceful FIN exchange or RST packet was sent). Because this access list type doesn't rely on the TCP flag bits set, it works with UDP and ICMP traffic as well. For non-TCP traffic, the connection is torn down after a timeout value expires . The timeout can be set per access list, or it can default to the global timeout of 300 seconds. This feature allows maximum security for return traffic because lists are created and removed for individual communication sessions. This capability to keep track of connections makes the reflexive access list the safest of the three access list types, but also the slowest.

Syntactically, reflexive access lists are basically a subset of extended access lists specifically , "named" extended access lists. Named lists were created in Cisco IOS version 11.2 for two main reasons. First, large enterprises could run out of numbers for access lists using the old method. Second, its name could explain for what purpose the list was being used.

Sequence and the Named Access List

One of the best features of the named access list is that individual entries can be added or deleted without the list having to be completely re-created. You simply enter the access list configuration mode by typing

ip access-list extended name

where name is the name of the access list you want to edit. The prompt will change to look like this:

router(config-ext-nacl)#

At this point, you can delete entries by typing an existing entry preceded by no , or you can enter additional entries that will automatically be added to the end of the list. The fact that entries are added to the end of the list can be an issue, due to the problems with rule order. In previous versions of IOS, the only way this could be corrected was by re-creating the entire list or by deleting all the commands at the end of the list that you want the new entry to be placed before and then re-adding them back in after adding the new entry. Anyone who has done this knows it is a major hassle.

Now in versions 12.2(15)T and 12.3(2)T and later, the sequence feature has been introduced. Before entering the permit or deny keyword, you can add a sequence number, enabling the placement of a new access list entry anywhere in an access list. To demonstrate this feature, let's look at the following access list:

ip access-list extended test
    10 permit tcp any any
    20 permit ip any any log

In the past, a new entry would be placed after the last listed entry. However, with the sequence feature, we can choose a value below 10 to place the entry at the beginning of this list, between 10 and 20 to put the entry between the two listed entries, or greater than 20 to add it to the end of the list. If an initial sequence number is not specified when you create an entry, numbers will automatically be assigned (starting with the number 10). The auto-numbering then increments by 10 for each additional entry added.

We start by defining the list with ip access-list extended name , where name is the descriptive name used to define the access list. We follow this line with permit and deny lines, as shown next . They follow similar logic to numbered extended access lists. To move to a reflexive access list, all we have to do is add the reflect keyword to the end, followed by a name for the reflexive access list:

router(config)#ip access-list extended outfilter
router(config-ext-nacl)#permit tcp any any eq 80 reflect mypackets
router(config-if)#ip access-group outfilter out

Notice the way that the prompt changes after entering the initial command, which shows that we are now entering specific information into the named access list. In the permit line, we have the reflect keyword and the name of the reflexive access list with which we will be keeping track of our packet's connection information. Of course, the last line applies the list to the network interface, just like all previous examples, but now we do it by name. You might remember from the explanation of reflexive access lists that every connection has a dynamically created access list. These dynamic lists are created based on an access list like the one in the previous example. However, we need a component in the reverse direction to examine the packets when they come back in. Take a look at a sample inbound filter:

router(config)#ip access-list extended infilter
router(config-ext-nacl)#evaluate mypackets
router(config-if)#ip access-group infilter in

This access list should look familiar, except for the second line. The evaluate line checks the incoming packet flow versus the reflexive access list information (in this case, mypackets ) to see if it will pass the test of one of its dynamically created lists. We now have a complete reflexive access list with all its components !

FTP Problems Revisited with the Reflexive Access List

Following is an example of a reflexive mode FTP filter that blocks incoming FTP traffic but allows outgoing passive FTP, along with any valid TCP traffic. This is a popular use of the reflexive access listto allow anything outbound and to allow return (or response) traffic inbound.

router(config)#ip access-list extended filterout
router(config-ext-nacl)#permit tcp any any reflect packets
router(config-ext-nacl)#permit udp any any reflect packets
router(config-ext-nacl)#permit icmp any any reflect packets

router(config)#ip access-list extended filterin
router(config-ext-nacl)#evaluate packets

router(config-if)#ip access-group filterin in
router(config-if)#ip access-group filterout out

The filterout on this list permits all types of traffic out. Only TCP is necessary for FTP, but the others are added to demonstrate a popular configuration selection used with reflexive access lists, as mentioned previously. The filterin evaluates the return traffic of the previous outbound filter, and by the implied "deny all," it drops non-return FTP traffic (and any other non-return traffic). The last group shows the application of the filterin inbound and filterout outbound on the appropriate internal and external ports. Filter order isn't an issue, as the example appears here. It is possible to add other permit and deny access lists into this filter, being careful to ensure that nothing permitting TCP port 21 traffic comes before the rule in filterin and that the evaluate line terminates the list. The evaluate line must always terminate the list.

You can test the effectiveness of this filter using a properly implemented PASV FTP client. This filter, though the most secure of the FTP options you have seen so far, still only works with PASV FTP. The only way to securely allow standard FTP outbound through a Cisco router is by using a part of the Cisco Secure Integrated Software (formerly the Firewall Feature Set) called context-based access control (CBAC) , which inspects traffic and watches for inbound connections based on common behaviors of known protocols. Therefore, if you have to do secured outbound standard FTP on a Cisco router, consider the Cisco Secure Integrated Software.

Reflexive ACLs with UDP and ICMP Traffic: Clearing Up DNS Issues

One of the greatest advantages of reflexive ACLs over extended ACLs with the established keyword is that reflexive access lists can handle UDP and ICMP traffic. One place that this is helpful is with DNS traffic.

As previously mentioned, incoming UDP DNS return traffic is an issue because it can't be tracked by the established command; therefore, a specific access list must be made to allow DNS return traffic. With the reflexive access list, this is no longer necessary. Using the same access list used in the "FTP Problems Revisited with the Reflexive Access List" section, DNS return traffic is handled dynamically. Because the outgoing connection is aware of the ephemeral port that the DNS request is using, the dynamically created ACL can reflect (pardon the pun) that information, making a much more secure access control list.

Trouble in Paradise: Problems with Reflexive Access Lists

Yes, just when you thought you had found the panacea of packet filtering, the disclaimer comes about. Even reflexive access lists aren't perfect. However, due to the dynamic nature by which they are created and deleted, they are much more difficult to pass than other packet filters. One reset packet is all that is required to entirely remove a reflexively generated ACL.

Another issue with reflexive access lists is that they keep no record of TCP flags, so initial traffic could flow in without an alarm being sounded. How feasible is this? Look at the following example:

permit tcp host 100.100.100.1 eq 23 192.168.100.2 eq 1072

This is a dynamically generated reflexive access list example from a previous section. For someone to be able to use this access list as a conduit through to your internal network, the following would have to transpire:

Someone would have to know that this access list exists.
This access list would have to be created by an internal host contacting an outside entity.
Only a host at 100.100.100.1 using port 23 could start a viable communications channel through this access list.
The only host that could be contacted would be at address 192.168.100.2.
The contacted host would have to be listening on the ephemeral port 1072.
The sending host would have to know exactly what stage of communication the contacted host would be expecting to keep it from tearing down the dynamic access list.
This would all have to transpire before the generated access list was torn down.

If someone is this in-tune with your network and security structure and you don't have the reconnaissance capabilities to recognize that this person is watching you, you might be vulnerable on more levels than this one.

One thing can walk right through reflexive access lists: outbound traffic. If a virus or Trojan is on the internal network and wants to contact a malicious outside entity, the reflexive access list would let the traffic out and the return traffic from the conversation back in. The only way to defend against this with packet filtering is by limiting outbound access with an access list like the following (for an even stronger security stance, replace the second any with your internal network number):

router(config)#ip access-list extended filterout
router(config-ext-nacl)#permit tcp any any eq 21 reflect packets
router(config-ext-nacl)#permit tcp any any eq 22 reflect packets
router(config-ext-nacl)#permit tcp any any eq 23 reflect packets
router(config-ext-nacl)#permit tcp any any eq 25 reflect packets
router(config-ext-nacl)#permit tcp any any eq 53 reflect packets
router(config-ext-nacl)#permit tcp any any eq 80 reflect packets
router(config-ext-nacl)#permit tcp any any eq 110 reflect packets
router(config-ext-nacl)#permit tcp any any eq 119 reflect packets
router(config-ext-nacl)#permit tcp any any eq 143 reflect packets
router(config-ext-nacl)#permit tcp any any eq 443 reflect packets
router(config-ext-nacl)#permit udp any any eq 53 reflect packets
router(config-ext-nacl)#permit icmp any any packet-too-big
router(config-ext-nacl)#deny ip any any log-input


router(config)#ip access-list extended filterin
router(config-ext-nacl)#evaluate packets

router(config-if)#ip access-group filterin in
router(config-if)#ip access-group filterout out

This way, controls exist for the types of traffic leaving the network. However, if the virus or Trojan happens to use one of these popular traffic types, you are just as vulnerable. This is why it is important to deploy extra layers of defense, such as virus checkers and host firewall defenses. Despite the fact that reflexive ACLs can be a more effective means to defend your network using dynamically generated host and port access lists, they still have the inherent limitations of packet-filtering technology that need to be considered before choosing them as your protection method of choice. They also put more of a burden on your router than static ACLs, so implement them with caution.

For two complete examples of reflexive access lists, refer to Appendix A, "Cisco Access List Sample Configurations."

Cisco IPv6 Access Lists

With the advent of IP version 6, Cisco access lists have changed. IPv6 extended access list support started to be accommodated for in IOS versions 12.0(23)S and 12.2(13)T or later. Previously there were limited IOS versions that supported features similar to standard access list functionality for IPv6, only allowing filtering based on source addressing. The IPv6 extended access lists, though similar to their IPv4 predecessors, require slightly different commands. Because IPv6 is not backward compatible with IPv4, new commands needed to be created for IPv6- related functions.

Access lists are still created in config mode, but the process of creating an IPv6 access list is instead started with the following command:

Router(config)#ipv6 access-list

name

Here, name is some descriptive name for the IPv6 access list. This will place you into IPv6 access-list configuration mode. The prompt will change to look like this:

Router(config-ipv6-acl)#

Now permit or deny access list statements can be added. Here is an example of a permit statement for this access list:

Router(config-ipv6-acl)#permit ipv6 any A2b2:A:132::1234/64 log

It follows the same format as IPv4 extended access lists permit or deny , followed by protocol identifier. Supported keywords include ipv6 for layer 3 access lists using IPv6 addressing, along with protocol identifiers ahp , esp , tcp , udp , pcp , stcp , and icmp . This is followed by the source and destination address in IPv6 format, and the any and host keywords can still also be used. This version of access list can accommodate the double- colon abbreviation, as shown in the example. One minor difference in the source and destination address notation is the new way the subnet mask is entered. Instead of listing out the value of the subnet mask, as was commonly done with IPv4, it is now shown as /xxx where xxx is some number between 0 and 128. This number represents the number of bits in the subnet mask. The entry can be ended with a trailing keyword. It can be any of the trailing keywords used in IPv4, with the exception of keywords that only refer to IPv4 features ( tos and precedence ). Also, there are several new keywords to accommodate IPv6 features. IPv6 extension header information can be filtered with the flow-label and routing keywords. Also, the sequence keyword allows similar functionality to the IPv4 named access list feature of the same name. However, in IPv6 lists, the sequence keyword is added after the list instead of at the beginning:

permit tcp any any sequence 5

IPv6 extended access lists also have support for reflexive access list capability with the use of the reflect keyword. This functionality is identical to IPv4 reflexive access lists.

IPv6 access lists are displayed using the following command:

Router# sh ipv6 access-list

name

The name option can be left off to display all IPv6 access lists.

As IPv6 continues to be more and more supported throughout the Internet, understanding IPv6 access list features will become a crucial part of securing your network environment.

Buy on amazon.com >>

Northcutt S., Zeltser L., Winters S

<< Previous page

Table of contents

Next page >>