Dynamic Packet Filtering and the Reflexive Access List

 In dynamic packet-filtering 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.

Dynamic Packet Filtering and the Reflexive Access List  For example, perhaps you have a client that has an IP address of 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 ) 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 > telnet server

Dynamic Packet Filtering and the Reflexive Access List  and reverse it into an incoming access list that permits traffic from on port 23, to client on port 1072, like this: permit tcp host eq 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.

Dynamic Packet Filtering and the Reflexive Access List  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.

Dynamic Packet Filtering and the Reflexive Access List  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.  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 ahead. They follow similar logic to numbered extended access lists.

Dynamic Packet Filtering and the Reflexive Access List  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

Dynamic Packet Filtering and the Reflexive Access List  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.

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 list to allow anything outbound and to allow return (or response) traffic inbound.

FTP Problems Revisited with the Reflexive Access List 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

FTP Problems Revisited with the Reflexive Access List  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.

FTP Problems Revisited with the Reflexive Access List  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.

FTP Problems Revisited with the Reflexive Access List  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).  CBAC inspects traffic and watches for inbound connections based on common behaviors of known protocols.  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.  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.

Reflexive ACLs with UDP and ICMP Traffic: Clearing Up DNS Issues  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.

Trouble in Paradise: Problems with Reflexive Access Lists  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 eq 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 ahead would have to transpire:

Trouble in Paradise: Problems with Reflexive Access Lists 1.Someone would have to know that this access list exists. 2.This access list would have to be created by an internal host contacting an outside entity. 3.Only a host at using port 23 could start a viable communications channel through this access list. 4.The only host that could be contacted would be at address The contacted host would have to be listening on the ephemeral port 1072.

Trouble in Paradise: Problems with Reflexive Access Lists 6.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. 7.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.

Trouble in Paradise: Problems with Reflexive Access Lists 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

Trouble in Paradise: Problems with Reflexive Access Lists (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

Trouble in Paradise: Problems with Reflexive Access Lists 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.

Trouble in Paradise: Problems with Reflexive Access Lists  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.

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.

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: 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