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

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.

Continue reading here: Null Route

Was this article helpful?

0 0