|
Configuring Cisco Reflexive Access Lists |
|
IntroductionIf you have responsibility for protecting your organization's perimeter, you may have used Cisco's standard and extended access lists as well as some enhanced capability such as time-based and dynamic access lists. While these access lists are an enhancement to traditional access lists, they still have limitations, including the opening of access from the untrusted side to the trusted side without control and the inability to provide different clients with different kinds of access. Reflexive access lists, introduced in IOS Version 11.3, allow filtering of IP packets based on upper-layer session information. You can use reflexive access lists to permit IP traffic for sessions originating from within your network, but to deny IP traffic for sessions originating from outside your network. You do this with reflexive filtering, a kind of session filtering. 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 feature reduces an organization's exposure to spoofing and denial-of-service, since desirable inbound flows are mostly in response to outbound traffic. You need to determine where to apply your list. You ordinarily use reflexive access lists in one of two basic ways. In the first way, you want to prevent IP traffic from entering the router and the internal network, unless the traffic is part of a session already established from within the internal network. So, you configure reflexive access lists for the external interface. In the second way, you want to allow external traffic to access the services in your organization's Demilitarized Zone (DMZ) or screened subnet, such as DNS or WWW, but you want to prevent IP traffic from entering your internal network unless you can associate that traffic with an established session from within your internal network. So, you configure reflexive access lists for the internal interface. Keep these thoughts about interfaces in mind when applying a list to an interface. But this is getting ahead of the subject. Let's start by reflecting on reflexive access lists. To use this feature, you first 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 spies 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, the IOS uses an access list 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, whenever it sees new outbound traffic. The IOS uses a corresponding access list to filter traffic coming into your network. Every time the IOS processes a line containing the keyword evaluate, and the name of a temporary access list, it checks the inbound packet against the permit statements in the temporary access list. That is, it answers the question: is it in response to something that originated with your network? When the inbound packet matches a permit statement, the router allows the traffic into the network. The temporary permit entries match the TCP or UDP protocol with source and destination addresses swapped, and source and destination ports swapped. That is, take what goes out, flip the source and destination information, and allow that back in. Other IP protocols like ICMP and IGMP behave appropriately (no port numbers). The software removes temporary access list entries at the end of the session. For TCP, the IOS removes the entry 5 seconds after it detects two set FIN bits, or immediately after a TCP packet with the RST bit set. Two set FIN bits means that the session is terminating, and the 5-second window allows the session to shutdown gracefully. A set RST bit indicates an abrupt session closure. The IOS also removes the temporary entry at the point when the IOS has not seen any packets for the session for a configurable timeout period. This is necessary to support connectionless protocols like UDP, and presumably also as a failsafe measure in the event the software somehow misses the FIN or RST. For UDP and other protocols, the IOS determines the end of the session differently than for TCP. Since UDP services and other protocols are connectionless (or sessionless), there is no session tracking information embedded in packets. Therefore, the IOS considers the end of a session as a predetermined, configurable length of time (known as the timeout period) when it has not detected packets for the session. You define reflexive access lists with extended named IP access lists only. You cannot define reflexive access lists with numbered or standard named IP access lists or with other protocol access lists, such as IPX. Use reflexive access lists with other standard access lists and static extended access lists. Reflexive access lists are similar in many ways to other access lists. Reflexive access lists contain condition statements or entries that define criteria for permitting IP packets. The IOS evaluates these entries in order, and when a match occurs, examines no more entries. However, reflexive access lists have significant differences from other types of access lists. Reflexive access lists contain only temporary entries; which the IOS automatically creates when a new IP session begins, for example, with an outbound packet, and removes the entries when the session ends. The IOS does not apply the reflexive access lists directly to an interface, but instead nests them within an extended named IP access list that the IOS applies to the interface. Also, reflexive access lists do not have the usual implicit "deny all traffic" statement at the end of the list, because of the nesting. Configure reflexive access lists on border routers—routers that pass traffic between an internal and external network. Often, these are firewall routers. Session Filtering You're perhaps muttering can't you use the established keyword in an extended access list to allow replies back through the router. Well, yes, using basic standard and static extended access lists, you can approximate session filtering by using the established keyword with the permit command. The established keyword filters TCP packets based on whether the ACK or RST bits are set. Set ACK or RST bits indicate that the packet is not the first in the session so the packet belongs to an established session. You could permanently apply an access list with this filter criterion to any interface. You also can filter by allowing only ports greater than 1023 into your network. Again, this filter criterion is part of an access list that you could apply permanently to an interface. Reflexive access lists, however, provide a truer form of session filtering, which is much harder to spoof because the IOS must match more filter criteria before permitting a packet through. For example, the IOS will check the source and destination addresses and the source and destination port numbers, not just ACK and RST bits. Also, session filtering uses temporary filters that the IOS will remove when the session ends. This presents a smaller window of opportunity to an attacker. Moreover, the previous method of using the established keyword was available only for the TCP upper-layer protocol. Reflexive access lists do work with UDP or ICMP, and with different internal port numbers. So, for the other upper-layer protocols, such as UDP, ICMP, and so forth, you would have to either permit all incoming traffic or define all possible permissible source and destination address and port pairs for each protocol. Besides being an unmanageable task, you would exhaust NVRAM space. 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. How Reflexive Access Lists Work When someone initiates a new IP upper-layer session, such as TCP or UDP, from inside your network with a packet traveling to the external network, it triggers a reflexive access list. When triggered, the reflexive access list generates a new, temporary entry. This entry will permit traffic to enter your network when the traffic is part of the session, but will not permit traffic to enter your network when the traffic is not part of the session. For example, should a host forward a TCP packet outside your network, and this packet is the first packet of a TCP session, then the IOS will create a new, temporary reflexive access list entry for this connection. It adds this entry to the reflexive access list, which it applies to inbound traffic. The temporary entry has the following characteristics:
Restrictions on Using Reflexive Access Lists Reflexive access lists do not work with some applications that use port numbers that change during a session. For example, when the port numbers for a return packet are different from the originating packet, the IOS will deny the return packet, even though the packet is actually part of the same session. FTP is a good example of an application with changing port numbers. You initiate the session on port 21, while the daemon sends data on port 20. With reflexive access lists, should you start an FTP request from within your network, the request will not complete. Instead, you must use Passive or PAS-V FTP when originating requests from within your network. This form of FTP allows you to set up both connections, rather than having the server set up the data channel. Configuring Reflexive Access Lists You should ensure that you have a basic understanding of the IP protocol and access lists; specifically, you should know how to configure extended named IP access lists. To learn about configuring IP extended and named access lists, refer to any good book on traffic filtering. Configuring the Interface Before you configure reflexive access lists, you must decide whether to configure reflexive access lists on an internal or external interface. Think back to the discussion at the beginning of the article and decide whether you will apply it on the internal or external interface. The simplest use of reflexive access lists is to put both access control lists on the same interface, applied in opposite directions. To configure reflexive access lists for an outbound interface, perform these tasks:
______________________________________________________________________________ Note. The defined outbound reflexive access list evaluates traffic traveling out of your network: when the IOS matches the defined reflexive access list, it creates temporary entries in the nested inbound reflexive access list. The IOS will then apply these temporary entries to traffic traveling into your network. ______________________________________________________________________________ You do the opposite to configure an internal interface. ______________________________________________________________________________ Note. The IOS uses the defined inbound reflexive access list to evaluate traffic traveling out of your network: when the IOS matches the defined reflexive access list, it creates temporary entries in the nested outbound reflexive access list. The IOS applies these temporary entries to traffic traveling into your network. ______________________________________________________________________________ Defining the Reflexive Access List To define a reflexive access list, you use an entry in an extended named IP access list. This entry must use the reflect keyword. The rules for the entry are:
To define reflexive access lists, perform the following tasks, starting in global configuration mode: gandalf(config)#ip access-list extended {access-list-number | name} To create a reflexive access list that enables the IOS to generate automatically its temporary entries, use the permit (reflexive) access-list configuration command. For the external interface, specify the outbound access list. For the internal interface, specify the inbound access list. gandalf(config-ext-nacl)#permit protocol any any reflect name [timeout seconds] This command defines the reflexive access list using the reflexive permit entry. The protocol keyword is either the name or number of an IP protocol. You can use one of the keywords gre, icmp, ip, ipinip, nos, tcp, or udp, or an integer in the range 0 to 255 representing the IP protocol number. To match any Internet protocol (including ICMP, TCP, and UDP), use the keyword ip. The name keyword specifies the name of the reflexive access list. Names cannot contain a space or quotation mark, and must begin with an alphabetic character to prevent ambiguity with numbered access lists. You can use up to 64 characters for the name. Optionally, you can specify the timeout and the number of seconds to wait (when the IOS doesn't detect session traffic) before entries expire in this reflexive access list. Use a positive integer from 0 to 232 - 1 (that is, 4,294,967,296 - 1 or approximately 136 years). If you do not specify this option, the number of seconds defaults to the global timeout value. Repeat this step for every IP upper-layer protocol; for example, you can define reflexive filtering for TCP sessions and also for UDP sessions. You can use the same name for multiple protocols. Use the no form of this command to delete the reflexive access list, where you only defined one protocol, or to delete protocol entries from the reflexive access list, where you defined multiple protocols). gandalf(config-ext-nacl)#no permit protocol any any reflect name If you never applied the extended named IP access list you just specified to an interface, you must also do this. For the external interface, apply the extended access list to the interface's outbound traffic. gandalf(config-if)#ip access-group name out For the internal interface, apply the extended access list to the interface's inbound traffic. gandalf(config-if)#ip access-group name in These commands apply the extended named IP access list to the interface, in interface configuration mode. Mixing Reflexive Access List Statements with Other Permit and Deny Entries The extended IP access list that contains the reflexive access list permit statement can also contain other normal permit and deny statements. However, as you have seen with other access lists, the order of entries is important. If you configure reflexive access lists for an external interface, when an outbound IP packet reaches the interface, the IOS will evaluate sequentially the packet against each entry in the outbound access list until a match occurs. If the packet matches an entry prior to the reflexive permit entry, the IOS will not evaluate the packet against the reflexive permit entry, and it will not create a temporary entry for the reflexive access list, that is, the IOS will not trigger reflexive filtering. The IOS will evaluate the outbound packet by the reflexive permit entry only when no other match occurs first. Then, should the packet match the protocol specified in the reflexive permit entry, the router will forward the packet out the interface and create a corresponding temporary entry in the inbound reflexive access list, unless the corresponding entry already exists, indicating the outbound packet belongs to a session in progress. The temporary entry specifies criteria that permits inbound traffic only for the same session. Nesting the Reflexive Access List After you define a reflexive access list in one IP extended access list, you must nest the reflexive access list within a different extended named IP access list. Nest the entries according to these rules:
After you nest a reflexive access list, the IOS will evaluate any packets heading into your internal network against any reflexive access list temporary entries, along with the other entries in the extended named IP access list. To nest reflexive access lists, perform the following tasks, starting in global configuration mode. gandalf(config)#ip access-list extended name You now need to add an entry for each reflexive access list name that points to the previously defined access list. To nest a reflexive access list within an access list, use the evaluate access-list configuration command. gandalf(config-ext-nacl)#evaluate name You specify the name of the reflexive access list that you want evaluated for IP traffic entering your internal network. This is the name defined in the permit reflexive command. The evaluate command terminates an extended IP named access list that included one or more reflexive entries. Use the no form of this command to remove a nested reflexive access list from the access list. Again, the order of entries is important. Normally, when the IOS evaluates a packet against entries in an access list, it evaluates the entries in sequential order, and when a match occurs, it does not evaluate any more entries. With a reflexive access list nested in an extended access list, the IOS evaluates the extended access list entries sequentially up to the nested entry, then it evaluates the reflexive access list entries sequentially, and then it evaluates the remaining entries in the extended access list sequentially. As usual, after a packet matches any of these entries, the software will not evaluate any more entries. If you have never applied the extended named IP access list you just specified to an interface, you must also complete this task. Apply the extended named IP access list to an interface, in interface configuration mode. For an external interface, apply the extended access list to the interface's inbound traffic. gandalf(config-if)#ip access-group name in For an internal interface, apply the extended access list to the interface's outbound traffic. gandalf(config-if)#ip access-group name out Setting a Global Timeout Value (Optional) Reflexive access list entries expire when the IOS doesn't detect packets for the session for a certain length of time (the timeout period). You can specify the timeout for a particular reflexive access list when you define the reflexive access list. But should you not specify the timeout for a given reflexive access list, the list will use the global timeout value instead. To specify the length of time that reflexive access list entries will continue to exist when no packets in the session are detected, use the ip reflexive-list timeout global configuration command. This command applies only to reflexive access lists that do not already have a specified timeout. To change the global timeout value, perform the following task in global configuration mode: gandalf(config)#ip reflexive-list timeout seconds The global timeout value is 300 seconds by default. But, you can change the global timeout to a different value at any time. Use any positive integer from 0 to 232-1. (Again, that's a lot of time: an eternity in the computer world.) Again, use this command to specify the number of seconds to wait (when no session traffic is being detected) before temporary access list entries expire. To observe this in action, use show access-list. Before someone sends traffic, you'll just see the inbound and outbound named extended access control list. 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. Use the no form to reset the timeout period to the default timeout of 300 seconds. gandalf(config)#no ip reflexive-list timeout Example Reflexive Access Lists Configuration Now that you have seen all the commands, let's look at an external interface configuration example. In this example, the policy permits both inbound and outbound TCP traffic at interface Serial 1, but only when the first packet in any given session originates from inside the network. The interface Serial 1 connects to the Internet. The first thing is to define the interface where you wish to apply the session-filtering configuration: gandalf(config)#interface serial 1 Then, you apply access lists to the interface, for inbound traffic and for outbound traffic: gandalf(config-if)#ip access-group infilter in gandalf(config-if)#ip access-group outfilter out Next, define the outbound access list that evaluates all outbound traffic on interface Serial 1. gandalf(config-if)#ip access-list extended outfilter ______________________________________________________________________________ Tip. Use meaningful names for all the named access lists involved. Later, it'll make troubleshooting a whole lot simpler. ______________________________________________________________________________ You must define a reflexive access list, say tcpapps, that permits all outbound TCP traffic and creates a new access list named tcpapps. Also, when an outbound TCP packet is the first in a new session, the IOS will automatically create a corresponding temporary entry in the reflexive access list tcpapps. gandalf(config-if)#permit tcp any any reflect tcpapps Define the inbound access list to evaluate all inbound traffic on interface Serial 1. gandalf(config-if)#ip access-list extended infilter Define inbound access list entries. This example permits BGP and Enhanced IGRP traffic and restricts ICMP packets. You must create an entry that points to the reflexive access list. If a packet does not match the first three entries, the IOS will evaluate the packet against all the entries in the reflexive access list tcpapps. gandalf(config-if)#permit bgp any any gandalf(config-if)#permit eigrp any any gandalf(config-if)#deny icmp any any gandalf(config-if)#evaluate tcpapps Your last step is to define the global idle timeout value for all reflexive access lists. In this example, when you defined the reflexive access list tcpapps, you did not specify a timeout value, so tcpapps uses the global timeout. Accordingly, let's create an entry that will remove the corresponding reflexive access list entry when there is no TCP traffic for an established session for 120 seconds or 2 minutes. gandalf(config-if)#ip reflexive-list timeout 120 Enter the show interface serial 1 command and you should see the following: interface Serial 1 ip access-group infilter in ip access-group outfilter out ! ip reflexive-list timeout 120 ! ip access-list extended outfilter permit tcp any any reflect tcpapps ! ip access-list extended infilter permit bgp any any permit eigrp any any deny icmp any any evaluate tcpapps Conclusion In this article, you learnt about reflexive access lists. Reflexive access lists are an important part of securing your network against network hackers, as part of your firewall defense. Set up an extended named access list that filters the traffic leaving the trusted network. It should contain at least one reflect command referencing a temporary named access list. Reflexive access lists provide a level of security against spoofing and certain denial-of-service attacks. Reflexive access lists are simple to use, and, compared to basic access lists, provide greater control over packets entering your network. They are not that difficult to understand and they provide enhanced functionality over standard and extended access lists. Abridged version of a document originally published by Auerbach Publications 2002. This subject also is covered in Securing and Controlling Cisco Routers from Auerbach Publications/CRC Press. |
