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
Reflexive access lists are examples of dynamic packet-filtering technology. A criterion is set up on the outbound interface that
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
Client 192.168.100.2.1072 > telnet server 100.100.100.1.23
and reverse it into an incoming access list that
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
Syntactically, reflexive access lists are basically a subset of extended access lists
We start by defining the list with
ip access-list extended
is the descriptive name used to define the access list. We follow this line with
lines, as shown
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
line checks the incoming packet flow versus the reflexive access list information (in this case,
) 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
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
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
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
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
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:
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
For two complete examples of reflexive access lists, refer to Appendix A, "Cisco Access List Sample Configurations."
Cisco IPv6 Access Lists
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:
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
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.