Reflexive Access Lists

Introduction

In this month's article we'll take a look at a nifty new feature in IOS 12.0, reflexive access lists (RACL's, for those who like acronyms). These look like something you should really look into if you're using packet filtering routers as part of your security architecture.

Congratulations to Rick Burts, Mentor Technologies' newest CCIE!

What Are Reflexive Access Lists

They go on the filtering router connecting your network to the outside world. (I'm avoiding "firewall router", since we usually think of a firewall as a dedicated security box now).

Reflexive access lists allow you to dynamically open up your filtering router to allow reply packets back through, in response to an outbound TCP connection or UDP session initiated from within your network. This mechanism reduces exposure to spoofing and denial-of-service, since desirable inbound flows are mostly in response to outbound traffic.

You're perhaps wondering, "well, gee, I just use the established keyword in my extended access list, to allow replies through". You already know that established matches ACK and RST bits in the TCP header, in effect specifying packets which are part of an already-established session. Well, that doesn't work with UDP or ICMP, and it doesn't work with programs that dynamically vary the internal (source) port. Established also just checks ACK and RST bits, not necessarily source and destination address. Reflexive access lists do work with UDP or ICMP, and with different internal port numbers. And they force the reply to come from the destination of a known recent outbound packet, and to go to the source of that outbound packet, tightly controlling what traffic is allowed in. Furthermore, reflexive access lists just increase the capabilities of extended access lists, so that while they're powerful they're not too radical a change in what you're already doing.

The idea of reflexive access lists is that you create a temporary named access list. The special new access list commands for named access lists then allow the router to dynamically add and remove entries from the temporary access list. The router in effect snoops on your outbound traffic, and when it sees the initiation of a new connection, it adds an entry to the temporary access list, to allow replies back in.

More specifically, an access list is used to filter traffic leaving your network. One or more statements in the access lists with the reflect keyword cause the addition of a permit entry to the temporary named access list(s), whenever new outbound traffic is seen. A corresponding access list is used to filter traffic coming into your network. Every time a line is reached containing the keyword evaluate (and the name of a temporary access list), the inbound packet is checked against the permit statements in the temporary access list. (That is, is it the response to something that came out of your network). If the inbound packet matches a permit statement, it is allowed into the network. Eventually, the permit entry in the temporary access list expires, if no session packets pass for a configurable length of time, or if the session is terminated.

The temporary permit entries match the protocol (TCP or UDP) with source and destination addresses swapped, and source and destination ports swapped. That is, take what goes out, flip the source and destination info, and allow that back in. Other IP protocols like ICMP and IGMP behave appropriately (no port numbers).

Temporary access list entries are removed at the end of the session. For TCP, the entry is removed 5 seconds after two set FIN bits are detected, or immediately after a TCP packet with the RST bit set. The idea is that two set FIN bits means that the session is about to end, and the 5-second window allows the session to close gracefully. A set RST bit indicates an abrupt session closure. The temporary entry is also removed after no packets of the session have been detected for the configurable timeout period. This is necessary to support connectionless protocols like UDP, and (presumably) also as a safety measure in case the FIN or RST is somehow missed.
 

fig904a

There's one detail we've skipped here. The actual type or direction of access list used depends on where it is applied, on which interface. Consider interfaces A and B in the diagram.

If you're going to monitor traffic on interface B in the drawing, the Internet link, then an outbound access list on B filters outbound network traffic, and an inbound access list on B filters (sees) replies inbound to the network. So in this case you need an outbound access list with reflect , and an inbound access list with evaluate . That's because the outbound ACL "sees and records" the outbound traffic, which is reflected to the temporary ACL, which is in turn used to evaluate inbound traffic, "seen by" the inbound ACL.

If you're monitoring traffic on interface A in the drawing, the inside link, then an inbound access list (inbound to A) sees (filters) the outbound traffic, the traffic leaving the network. And an outbound access list (outbound as far as interface A is concerned) sees (filters) the inbound packet replies. So in this case, the inbound ACL gets the reflect commands, and the outbound ACL gets the evaluate commands.

If you find this confusing, just remember that traffic leaving the secure network might be going in or out an interface, depending on what interface you're talking about. It goes into A, and out of B. So the relevant access list for recording that traffic is inbound on A or outbound on B.

You can work through the reply scenarios similarly.

Configuring Reflexive Access Lists

If you're still with me, you're over the hard part! Once you've got the directions down on this, configuring it isn't so bad. It has the following major steps:
  • Think about what interface you're going to apply the access lists on. The simplest use of RACL's is to put both ACL's on the same interface, applied in opposite directions.
  • Set up an extended named access list that filters the traffic leaving the "secure" network. It should contain at least one reflect command referencing a temporary named access list.
  • Apply this named access list to the chosen interface in the proper direction.
  • Set up an extended named access list that filters the reply traffic entering the "secure" network. It should contain at least one evaluate command referencing the temporary named access list.
  • Apply this named access list to the chosen interface in the proper direction, generally the same interface as above but applied in the opposite direction..
Tip: use meaningful names for all the named access lists involved. It'll make troubleshooting it a whole lot simpler.

Tip: you don't have to actually create the temporary named access list, just put its name in the right places.

For example, suppose we decide to set up reflexive access lists on interface B in the picture, the exterior interface. Say the router's name for B is interface serial 1/0 (it's a 2600 model, say). Then we'd configure something like:

! create the named extended access list that "sees" the outbound packets
ip access-list extended outbound-packet-watch
  permit tcp any any reflect tcp-reflexive-temporary-list
  permit udp any any reflect udp-reflexive-temporary-list

! create the named extended access list that evaluates the inbound packets
ip access-list extended inbound-packet-catcher
  evaluate tcp-reflexive-temporary-list
  evaluate udp-reflexive-temporary-list

interface serial 1/0
  ! apply the named access list to watch packets leaving the secure network
  ! as they go out serial 1/0
  ip access-group outbound-packet-watch out
  ip access-group inbound-packet-catcher in

By the way, you don't need to use two separate temporary lists here, I just chose to do so to show how it might be done.

With some other access list statements mixed in, this might evolve to look like:

! create the named extended access list that "sees" the outbound packets
ip access-list extended outbound-packet-watch
  permit tcp any any reflect reflexive-temporary-list
  permit udp any any reflect reflexive-temporary-list

! create the named extended access list that evaluates the inbound packets
ip access-list extended inbound-packet-catcher
  ! allow BGP routing but deny ICMP from outside
  permit bgp any any
  deny icmp any any
  evaluate reflexive-temporary-list

interface serial 1/0
  ! apply the named access list to watch packets leaving the secure network
  ! as they go out serial 1/0
  ip access-group outbound-packet-watch out
  ip access-group inbound-packet-catcher in

If you want to change the global timeout, this can be configured by entering:

ip reflexive-list timeout seconds

where seconds is the number of seconds in the timeout. The default is

ip reflexive-list timeout 300

You can also add the words timeout seconds at the end of the access list reflect line, to specify a  non-global timeout for just the one named (temporary) ACL mentioned in the reflect command.

To observe this in action, use show access-list. Before traffic is sent, you'll just see the inbound and outbound named extended ACL's. After firing off some traffic, you'll see the temporary access-list and its entries, along with number of matches and time left before expiration.

Caveats with Reflexive Access Lists

Some applications change port numbers within a session. They may initially transmit to a well-known port and then shift ports. This will not work with RACL's. Active FTP is an example of such an application. You'll need passive FTP if you plan on using reflexive access lists.

References

CCO -- http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/screflex.htm

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This email address is being protected from spambots. You need JavaScript enabled to view it. .

5/5/99
Copyright (C)  1999,  Peter J. Welcher