Resources Archived Articles Reflexive Access Lists
| Reflexive Access Lists |
| Wednesday, 05 May 1999 21:09 |
IntroductionIn 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 ListsThey 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.
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 ListsIf 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:
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 ! create the named extended access list that evaluates the inbound packets interface serial 1/0 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 ! create the named extended access list that evaluates the inbound packets interface serial 1/0 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 ListsSome 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.ReferencesCCO -- http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/screflex.htmDr. 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. Pete's links start at http://www.netcraftsmen.net/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it . 5/5/99 |
