Reflexive Access Lists
Reflexive access lists are a type of extended access list that allow two access lists to work together dynamically. When the outbound access list senses a connection to a remote site, the inbound access list is opened up to allow two-way communications to occur. Once this two-way session is completed, the inbound access list is again closed to the remote site. The characteristics of reflexive access lists are as follows:
There are no implied deny any statements at the end of the reflexive access control list.
A reflexive access list entry is always a permit entry.
Named access lists are used in pairs and relate to each other while using reflexive access lists.
The inbound interface access list is dynamically changed in relation to sessions initiated from the inside of the network.
These dynamic changes are created and removed as sessions are initiated and closed from hosts on the internal network or after a specified time of inactivity. In the case of TCP, the FIN or RST bit is used. In UDP connections, or when a TCP session is not properly ended, the timeout is used.
Reflexive access lists support TCP and UDP sessions.
Reflexive access lists are built within extended access lists and are not applied directly to an interface.
Reflexive access lists provide security greater than that experienced with extended access lists, especially in the area of spoofed addresses and certain DoS attacks.
Reflexive access lists are a type of named access list that allows two access lists to work together dynamically, creating Layer 4 session-based filtering.
Reflexive access lists are similar to dynamic access lists, as both dynamically open pathways through the router based on the needs of a user at a given time. These pathways are closed once the initiating application has terminated. The advantage of reflexive access lists is that the user does not need to be authenticated on the router by initiating a Telnet session. This allows a transparent operation, where the user is not even aware that an access list is controlling availability. Additionally, reflexive access lists are much easier to use with mass-produced and system-based software because no additional steps are required to allow additional access.
When setting up reflexive access lists, two access lists must be created: one for the inbound packets, and one for the outbound packets. The following is an example of two access lists without any reflexive properties. After the example, you will see these access lists with changes to incorporate reflexive properties.
interface Serial 0
ip access-group inbound in
ip access-group outbound out
ip access list extended inbound
permit ip 10.1.1.0 0.0.0.255 172.30.1.0 0.0.0.255
deny ip any any
ip access list extended outbound
deny ip 172.30.1.18 0.0.0.0 10.1.1.0 0.0.0.255
permit ip any any
In the preceding configuration, any IP packet destined for the 172.30.1.0/24 network with a source address on the 10.1.1.0/24 network is allowed into the router. All packets from inside the network are allowed out except for those originating from 172.30.1.18 and destined to the 10.1.1.0/24 network.
The problem with this list becomes apparent when someone inside the corporate network wants to establish a connection to another network that is not on the access list. For example, if a user wants to establish a connection to the 10.10.10.0/24 network, the inbound access list will prevent the receipt of responses. Reflexive access lists were designed with this particular situation in mind. You can easily change the access lists to allow a connection initiated on the inside of the network to be available as needed. The following is an example of how the access lists changes to allow this:
interface Serial 0
ip access-group inbound in
ip access-group outbound out
ip access list extended inbound
permit ip 10.1.1.0 0.0.0.255 172.30.1.0 0.0.0.255
evaluate packetssent
deny ip any any
ip access list extended outbound
deny ip 172.30.1.18 0.0.0.0 10.1.1.0 0.0.0.255
permit tcp any any reflect packetssent timeout 90
permit udp any any reflect packetssent timeout 60
permit icmp any any reflect packetssent timeout 30
permit ip any any
A total of four lines have been added to the configuration. The first line, evaluate packetssent, is applied on the inbound filter. The next three lines are applied to the outbound filter. When an outbound packet is seen on the interface, the outbound access list is checked. If the packet meets any of the criteria, it is allowed through. The following paragraph contains a specific example to help you understand exactly what happens to the access lists. If no activity is present on the connection for the period in seconds specified by the timeout parameter, the reflexive access list will automatically be discontinued.
Assume that a user on host 172.30.1.18 initiates a Telnet connection to 10.10.10.10. The outbound access list sees the Telnet packets and mirrors them on the inbound filter to allow responses. In fact, the inbound filter dynamically changes to allow responses to travel through the interface in response to the connection initiated from 172.30.1.18. Using the show access-list command proves this. Three examples of the show access-list command follow, one before the connection is initiated, one while the connection session is running, and one after the connection has terminated. Notice that while the session is running, the “packetssent” reflexive access list is visible and contains a permit statement allowing Telnet traffic from the remote host with the appropriate port number. The inbound filter evaluates the inbound traffic against this temporary access list and permits the packets that match the criteria.
Before the connection is initiated:
routera#show access-list
Extended ip access list inbound
permit ip 10.1.1.0 0.0.0.255 172.30.1.0 0.0.0.255
evaluate packetssent
deny ip any any
extended ip access list outbound
deny ip host 172.30.1.18 10.1.1.0 0.0.0.255
permit tcp any any reflect packetssent timeout 90
permit udp any any reflect packetssent timeout 60
permit icmp any any reflect packetssent timeout 30
permit ip any any
During the connection session:
routera#show access-list
Extended ip access list inbound
permit ip 10.1.1.0 0.0.0.255 172.30.1.0 0.0.0.255
evaluate packetssent
deny ip any any
extended ip access list outbound
deny ip host 172.30.1.18 10.1.1.0 0.0.0.255
permit tcp any any reflect packetssent timeout 90
permit udp any any reflect packetssent timeout 60
permit icmp any any reflect packetssent timeout 30
permit ip any any
reflexive access list packetssent
permit tcp host 10.10.10.10 eq telnet host 172.30.1.18 eq 1045
(15 matches) (time left 23 seconds)
After the connection has terminated:
routera#show access-list
Extended ip access list inbound
permit ip 10.1.1.0 0.0.0.255 172.30.1.0 0.0.0.255
evaluate packetssent
deny ip any any
extended ip access list outbound
deny ip host 172.30.1.18 10.1.1.0 0.0.0.255
permit tcp any any reflect packetssent timeout 90
permit udp any any reflect packetssent timeout 60
permit icmp any any reflect packetssent timeout 30
permit ip any any
Figure 5-3 shows the sequence of the reflexive access list example.
Figure 5-3. Reflective Access Lists Open the Router in Response to Connections Initiated from Inside the Network
As with all access lists, placements of permit and deny statements are crucial to proper functioning. If the user chose to Telnet to a host on the 10.1.1.0/24 network, the request would still have been denied, because the deny statement for that network would have been evaluated before reaching the reflexive access list statements.
Although a reflexive access list is a very powerful and useful tool, there are still some limitations. Reflexive access lists do not have the ability to handle multiple channel applications. Context-based Access Control (CBAC), which will be discussed later in this chapter in the section “How Context-Based Access Control (CBAC) Works,” was designed to provide security support for multiple channel applications.
Null Route
An alternative to access lists is the null route command. This is actually a static route that directs packets to the null interface. The null interface, also known as the bit bucket, simply drops packets instead of forwarding them to the next hop.
Using this command has a number of advantages. The first is that very few CPU cycles are required to implement this method. Unlike an access list, which can consume an unacceptable number of CPU cycles, using the null route command consumes no more cycles than any other static route. The next advantage is that a single entry can be used to control access to both inbound and outbound packets. The third advantage is that a null route can be redistributed, and therefore, a single entry can drop data destined for any given network as soon as that data attempts to traverse a router.
A drawback to using the null route command for security purposes is that using it does not prevent packets originating at the designated network from entering your company's network. However, responses destined to the designated network are dropped.
A null route is entered as a static route with the next-hop router entered as null. For example, if you wish to deny access to the 184.15.10.0/24 network, use the following:
ip route 184.15.10.0 255.255.255.0 null 0
This forwards all packets destined for the 184.15.10.0/24 network to the null bit bucket. In other words, the router throws away all packets destined for this network. Redistributing this static route allows all routers on the network to drop these packets.
Look at Figure 5-4 to see an example of how a null route operates. After the null route is added to a single router and redistributed, all routers know to throw away packets destined for the 184.15.10.0/24 network. This method prevents wasting bandwidth within the network for packages that are ultimately destined to be dropped.
Figure 5-4. Null Route with Redistribution
In the Figure 5-4 example, if Host A tries to send information to the 182.15.10.0/24 network, the first router drops this packet. Likewise, if Host B tries to send data to the 182.15.10.0/24 network, the first router drops the packet.