- TCP/IP Primer: How Packet Filtering Works
- TCP and UDP Ports
- TCP's Three-way Handshake
- The Cisco Router as a Packet Filter
- An Alternative Packet Filter: IPChains
- The Cisco ACL
- Effective Uses of Packet-Filtering Devices
- Egress Filtering
- Tracking Rejected Traffic
- Problems with Packet Filters
- Dynamic Packet Filtering and the Reflexive Access List
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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 list—to 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.