Overview of Reflexive ACLs

As discussed in Chapter 7, "Basic Access Lists," you can use standard and, especially, extended ACLs to provide excellent packet-filtering capabilities, protecting you from all different kinds of attacks. Every perimeter router that I have configured or seen takes advantage of extended ACLs in filtering traffic. However, as I also pointed out in Chapter 7, these ACLs have certain limitations. The biggest limitation is that they are good for filtering unidirectional but not bidirectional, connections. As you recall, standard and extended ACLs do not keep track of the state of a connection; therefore, if someone inside sends traffic to the Internet, it is very hard to safely allow the returning traffic back into your network without opening a large hole on your perimeter router. In other words, a standard or extended ACL has static entries that always filter on the information that you have configured?with no exceptions.

RACLs were developed to deal with this issue. RACLs enable you to filter on session layer information. With this type of filtering, the Cisco IOS keeps track of the connections leaving your network and allows the returning traffic of these connections back in. By default, RACLs deny traffic that originates outside of your network and attempts to connect to internal resources. RACLs basically create temporary entries in your inbound filter whenever an internal device opens a session to the outside world. This temporary entry allows the returning traffic for this session back through the perimeter firewall router.

For example, assume that an internal user generates a Telnet connection to a remote device on the Internet, and this traffic passes through your perimeter router with RACLs configured on it. The Cisco IOS would permit the outgoing connection and add a temporary, dynamic entry to allow the returning Telnet traffic back to the internal user. However, the RACLs would not allow Internet users to Telnet to the internal user's device unless you explicitly allowed this connection with an extended ACL entry.

Extended Versus Reflexive ACLs

To help you understand the advantages that RACLs provide over extended ACLs, this section compares the two different types of ACLs. As you recall from Chapter 7, extended IP ACLs can filter only on Layers 3 and 4 information, such as the IP protocol (IP, ICMP, TCP, UDP, and so on), source and destination IP addresses, IP protocol information (ICMP message types, TCP and UDP port numbers, TCP control flags, and so on), and other information related to the Layers 3 and 4 header fields.

How Extended ACLs Handle Returning ICMP Traffic

This section looks how you can deal with returning traffic for sessions from internal users when using extended IP ACLs. Refer to Figure 8-1 as an illustration of how ICMP traffic can be handled. In this example, the internal user pings an external server (200.1.1.1) using ICMP echo messages. Assume that this traffic is allowed out by the perimeter router. After the pings have been sent out of the network, and assuming that 200.1.1.1 replies to the echo requests, the echo replies make it back to the filtering router. To allow the ICMP replies back into the network, you would have to configure something like Example 8-1.

Example 8-1. Sample Extended ACL with ICMP

Router(config)# ip access-list extended perimeter-filter

Router(config-ext-nacl)# permit icmp any host 192.1.1.1 echo-reply

Router(config-ext-nacl)# deny ip any any

Router(config-ext-nacl)# exit

Router(config)# interface ethernet1

Router(config-if)# ip access-group perimeter-filter in

Figure 8-1. ICMP Traffic and Extended ACLs

[View full size image]

This example allows ICMP echo replies back to 192.1.1.1. A few problems arise with this solution, though:

• Because you do not know who 192.1.1.1 is pinging, you must allow all echo replies to return to this device (other devices besides 200.1.1.1).

• This filter statement is always active, so a hacker could implement a denial of service (DoS) spoofing attack against 192.1.1.1.

• This filter works only with one device: 192.1.1.1. If you want other internal devices to ping outside devices, you also must include them in the extended ACL.

As you can see from this example, using an extended IP ACL does not provide a very good solution. Probably the main problem of these three is the DoS attack that you open yourself to. If a hacker knows that ICMP echo replies are allowed to 192.1.1.1, he easily could orchestrate a Smurf attack through reflectors and overload your internal user's PC. The Smurf attack is discussed in Chapter 7.

How Extended ACLs Handle Returning UDP Traffic

Now that you know the issues that extended ACLs have when dealing with ICMP and stateful processes, you can see how an extended ACL handles UDP connections. Consider the network shown in Figure 8-2 as an illustration of how to allow returning UDP traffic into this network. In this example, a user (192.1.1.1) performs a DNS query to an external DNS server (200.2.2.2).

Figure 8-2. UDP Traffic and Extended ACLs

[View full size image]

In this example, an internal user performs a DNS query and expects a response back from 200.2.2.2. Because DNS queries use UDP, the user's PC chooses a source port number greater than 1023 and a destination port number of 53. In the example, the random port number chosen was 10,000. To allow this traffic back into the network, you would have to configure the ACL as shown in Example 8-2.

Example 8-2. Sample Extended ACL with UDP DNS Connections

Router(config)# ip access-list extended perimeter-filter

Router(config-ext-nacl)# permit udp any eq 53 host 192.1.1.1 gt 1023

Router(config-ext-nacl)# deny ip any any

Router(config-ext-nacl)# exit

Router(config)# interface ethernet1

Router(config-if)# ip access-group perimeter-filter in

Here are some of the issues with the ACL configuration in Example 8-2:

• You probably do not know which DNS server or servers the internal user is using, so you must allow all DNS server replies back into your network.

• All port numbers greater than 1023 must be allowed because this is what the source device randomly chooses.

In this example, you have opened an even bigger hole in your firewall by allowing all UDP ports greater than 1023 to 192.1.1.1. Another problem with this ACL is that it solves (and not very well, at that) only DNS replies to 192.1.1.1. What about DNS replies (and other types of UDP traffic) to other internal devices? As you can see from this example, you would have to open ports greater than 1023 to all internal devices for the specific UDP applications that they will be accessing externally. Again, a hacker can take advantage of this with a tool such as Fraggle, creating a DoS attack (Fraggle was discussed in Chapter 7). Even if you lock down the source IP addresses that are allowed this access, a hacker easily can get around this with address spoofing.

How Extended ACLs Handle Returning TCP Traffic

When using an extended ACL to permit returning TCP traffic, you have more control on what returning traffic actually is allowed with the established keyword. As you recall from Chapter 7, the established keyword checks whether the ACK, FIN, PSH, RST, SYN, or URG TCP control flags are set. This typically indicates the return of traffic from an established session. Look at Figure 8-3 to see how returning TCP traffic is treated with an extended ACL.

Figure 8-3. TCP Traffic and Extended ACLs

[View full size image]

In this example, I have configured the commands in Example 8-3 on the perimeter router.

Example 8-3. Sample Extended ACL Allowing TCP Connections

Router(config)# ip access-list extended perimeter-filter

Router(config-ext-nacl)# permit tcp any host 192.1.1.1 established

Router(config-ext-nacl)# deny ip any any

Router(config-ext-nacl)# exit

Router(config)# interface ethernet1

Router(config-if)# ip access-group perimeter-filter in

In this example, when the user establishes a Telnet connection to 200.3.3.3 and goes through the three-way handshake, the SYN/ACK from 200.3.3.3 is allowed back through the router because of the established ACL statement. Likewise, any traffic sent from 200.3.3.3 in response to the Telnet connection, such as sending or acknowledging the receipt of data, is also allowed through. Even the messages for the teardown of the TCP connection are allowed through.

However, even though this is more restrictive than the filters I previously showed you with ICMP and UDP in the last two sections, the established keyword does not look at session information for connections. In other words, it does not look to see if this traffic is part of an existing connection that originated from inside the network. Instead, any TCP segment that has the right TCP control flag or flags set is allowed through to 192.1.1.1. Again, a hacker can take advantage of this with a modified form of the TCP SYN flood attack. In this instance, the hacker might flood 192.1.1.1 with SYN/ACK messages, which the packet-filtering firewall would allow through.

How RACLs Handle Returning Traffic

As you saw in the previous three sections, you can use methods with extended IP ACLs to restrict traffic as it returns to your network. However, the solutions described in these sections open big security holes in your perimeter router firewall. Therefore, network administrators typically do not use extended IP ACLs to handle returning traffic (responses to requests that originated inside a network).

Cisco addressed this issue with the development of the RACL feature. Unlike extended IP ACLs, RACLs are aware of state information concerning a connection?at least, to a certain degree. In other words, a reflexive ACL can detect when a user initiates a connection to the outside world and can allow only returning traffic for that user's connection. Unlike extended IP ACLs that can do this somewhat for TCP connections (with the established parameter), RACLs can do this with all IP protocols. Basically, RACLs are a stripped-down version of Cisco's CBAC stateful firewall feature, which is part of the Cisco IOS Firewall feature set (discussed in Chapter 9).

RACLs perform a function similar to that of a true stateful firewall, like CBAC: Only when a session is initiated on the inside of your network is returning traffic allowed back in. RACLs accomplish this feat by using temporary ACL statements that are inserted into your extended ACL filter, which is applied on your router's external interface. When the session ends or the temporary entry times out, it is removed from the external interface's ACL configuration. This reduces your exposure to DoS attacks by a hacker. As you will see in the later section "Limitations of Reflexive ACLs," RACLs do have limitations; however, they at least provide a solution that is much better than one that uses only extended ACLs.

Now take a look at a basic example of how RACLs works. Figure 8-4 illustrates how the perimeter router treats a Telnet connection.

Figure 8-4. Telnet Connection and RACLs

[View full size image]

In this example, assume that RACLs already have been configured for the router and that the default behavior of the router is to drop any traffic that originates outside the router and that is trying to access internal resources. As you can see from Figure 8-4, the internal user (192.1.1.1) establishes an outbound Telnet connection to 200.4.4.4. When the router receives the packet, the Cisco IOS checks to see if a RACL has been configured, to determine whether returning traffic for this user's connection should be allowed. If this is true, the Cisco IOS creates a temporary ACL entry on the inbound external interface (E1). This ACL entry allows only Telnet traffic from the server to the client (and only returning traffic, at that). When the user terminates this connection, or if it exceeds the idle timeout for the connection, the Cisco IOS removes the temporary RACL entry from the extended IP ACL. As you can see from this example, the temporary entry allows returning traffic for a specific period of time, which limits your exposure to DoS attacks.

As you saw in the previous three sections, extended IP ACLs have problems with allowing the return of replies. With TCP, you at least can have the Cisco IOS examine the TCP control flags, such as SYN, ACK, and others, to determine whether the traffic is part of an existing connection. However, extended ACLs do not have this option for ICMP or UDP traffic (or for other types of IP traffic, for that matter). Unlike TCP, these protocols do not indicate the state of the connection, so it is difficult, if not impossible, to determine whether the connection has just started, is in the middle of transmitting data, or is ending. Plus, even with the established keyword in a TCP extended ACL statement, the Cisco IOS does not look at whether this traffic is part of a connection that was initiated from inside your network; it looks at just whether fields in the segment header are marked appropriately.

Reflexive ACLs, however, do look at the source (origin) of the traffic. Only when a valid source originates traffic is a temporary ACL entry created, allowing the returning traffic only for this connection. In other words, the Cisco IOS looks at who establishes a session and uses this information to allow returning traffic for that specific connection. This gives you much tighter control over the type of traffic allowed back into your network, presenting a much smaller window in your filter that a hacker can take advantage of. Plus, RACLs actually build on the ACL technology of the Cisco IOS. In other words, they are an extension of extended ACLs: You can mix and match the two features to provide a more secure perimeter defense. By combining these two filtering features, you are much less susceptible to network attacks such as IP spoofing, DoS, and access attacks.

Reflexive ACLs in Action

As you saw in the previous section, RACLs create temporary holes in your router's inbound ACL to allow returning traffic back into your network. This section discusses how RACLs perform in more detail.

Steps in Processing Traffic

RACLs require the use of two ACLs to function correctly. The first ACL is used to capture session information for outbound traffic. This information is placed in a special RACL and inserted into the inbound ACL you have applied to your router's external interface. Figure 8-5 illustrates the use of the different ACLs.

Figure 8-5. ACLs and RACLs

[View full size image]

The steps for RACL processing in Figure 8-5 are as follows:

In this example, three ACLs are used.

When the session has been completed or timed out, the session entry in the RACL automatically is removed by the Cisco IOS.

Traffic Leaving the Network

You can break this down further. As traffic leaves your network, you have a named extended ACL that examines this traffic. This ACL can be applied inbound on an internal interface or outbound on the external interface. The latter method is more common because you need to apply it on only one interface. If you used the former method, you might have to create more than one ACL and apply them inbound on your internal interfaces.

In this "internal" ACL, you place statements that examine traffic for new sessions (with the reflect parameter). With these statements, you can control which connections you will build RACL entries for, where these entries will allow returning traffic back into your network. If you do not configure these statements, returning traffic is dropped, by default. This gives you much greater control over which internal users you want to access the external network and what type of connections they should be permitted. For example, you could set up your ACL statements to examine only HTTP connections, thus allowing only temporary RACL entries to be created for HTTP traffic.

Building the RACL

As traffic is leaving the network, if it matches a permit statement with a reflect parameter, a temporary entry is added to the RACL specified in the statement. For each permit/reflect statement you have, your router builds a separate RACL. A RACL entry is an inverted entry. Remember that these entries need to allow returning traffic back into the network; therefore, the source and destination information is flipped in the RACL statement.

For example, if a user (192.1.1.1) Telnets to 200.5.5.5, where the source port number is 11000, this RACL entry is created:

permit host 200.5.5.5 eq 23 host 192.1.1.1 eq 11000

As you can see in this example, this RACL entry has the source and destination information reversed, which includes both the address information and, because this is a TCP connection, the port information. Also note that any temporary RACL entries created contain the permit action, which makes sense because you want to allow the returning traffic for this session.

These are some of the characteristics of RACL entries:

• The action is always permit.

• The protocol of the packet, such as TCP, UDP, and ICMP, is placed in the RACL entry.

• The source and destination IP addresses are reversed in the RACL entry, to allow the return of this traffic.

• For TCP and UDP, the source and destination port numbers are switched, to allow the traffic to return from the destination device.

• For other protocols, such as ICMP and IGMP, the Cisco IOS can specify other protocol criteria, such as message types for ICMP.

Traffic Returning to the Network

To use RACLs to filter returning traffic, you must build an extended named ACL that filters traffic coming from the external network. This ACL is applied inbound on your external interface and commonly is called an external ACL.

In the external ACL, you put a placeholder (or reference) where your RACL or RACLs should be processed. Basically, you are nesting your RACL within an ACL. Whatever statement or statements exist in the RACL or RACLs logically are inserted into the specified place of your external ACL. When the Cisco IOS processes the external ACL and finds a RACL reference, it processes the statements in the RACL until it finds a match. If no match is found in the RACL, the Cisco IOS returns to the next external ACL statement after the RACL reference and continues to look for a match.

The insertion of your RACL references is done with the evaluate statement. Placement of these statements is important. For example, you might have the configuration in Example 8-4 for an external ACL.

Example 8-4. Example Extended ACL and RACL Placement

Router(config)# ip access-list extended inbound

Router(config-ext-nacl)# permit tcp any host 192.1.1.10 eq www

Router(config-ext-nacl)# deny ip any any

Router(config-ext-nacl)# exit

Router(config)# interface ethernet1

Router(config-if)# ip access-group inbound in

In Example 8-4, only web traffic is allowed to the internal web server (192.1.1.10); all other traffic is dropped.

To allow returning traffic into your network for sessions listed in your temporary RACLs, you need to put a placeholder in your external inbound ACL that specifies the use of the RACL statements. The location of the reference/placeholder is important.

Assume that you have a RACL with the following temporary statements:

permit host 200.5.5.5 eq 23 host 192.1.1.2 eq 10000

permit host 200.5.5.5 eq 23 host 192.1.1.1 eq 11000

In this example, two internal devices (192.1.1.2 and 192.1.1.1) have Telnetted to 200.5.5.5. If you put the RACL reference at the bottom of the external ACL, you actually would prevent the returning of their traffic because the deny ip any any statement would be processed first and would drop the returning traffic. Your RACL entries never would be processed because the packet would match this deny statement. In the previous example, you would need to put your RACL reference before any deny statement that might block it (this is accomplished with the evaluate statement). Example 8-5 shows a simple example for the code in Example 8-4.

Example 8-5. Example Showing RACL Placement

Router(config)# ip access-list extended inbound

Router(config-ext-nacl)# remark -> insert RACL reference or references here

Router(config-ext-nacl)# permit tcp any host 192.1.1.10 eq www

Router(config-ext-nacl)# deny ip any any

Router(config-ext-nacl)# exit

Router(config)# interface ethernet1

Router(config-if)# ip access-group inbound in

In this example, the RACL reference (indicated by a remark comment line and shaded) is placed at the beginning of the external ACL, guaranteeing that returning traffic will be allowed back through the router. This is a common placement for RACL references.

Removing RACL Entries

Entries in a RACL are temporary. They are removed from the RACL under two conditions:

• The session terminates.

• The entry in the RACL times out (is idle for a period of time).

When a session terminates, the Cisco IOS removes the temporary entry from the RACL. However, only TCP uses a well-defined mechanism by which the Cisco IOS can detect the end of a session. UDP, ICMP, and other protocols do not have this mechanism (they are connectionless). With TCP, the Cisco IOS looks for two FIN messages, and the temporary RACL entry is removed after 5 seconds. The 5-second waiting period is used to ensure that the TCP session is allowed enough time to close gracefully. If the Cisco IOS sees an RST message instead, this indicates an abrupt session closure, causing the Cisco IOS to immediately remove the session entry from the RACL.

Otherwise, for all other conditions for TCP and all other protocols, such as UDP and ICMP, the Cisco IOS monitors each session to see if the session is idle for a period of time. If the session is idle longer than the configured timeout value, the Cisco IOS automatically removes the session entry from the RACL.

Limitations of Reflexive ACLs

RACLs have two main limitations:

• RACLs do not provide a complete stateful solution (the ending of a session for protocols such as UDP and ICMP is approximated by an idle timer).

• Not all applications work with RACLs.

Stateful Issues

You already know one of the limitations of RACLs: They are stateful only for TCP. With other TCP/IP protocols, RACLs use timeouts to remove idle sessions. Even with TCP traffic, there is a minor issue with returning traffic. For example, as you recall from Chapter 7, the extended ACL established keyword allows only TCP segments with certain control flags set, such as the ACK flag. The assumption here is that certain control flags indicate the return of traffic into the network. However, it does not restrict a RACL entry that the Cisco IOS creates for TCP sessions. This is a minor issue and probably will not cause a problem.

Even though this is a very minor issue, it does open you up to possible problems. For example, imagine that an internal host somehow was compromised. Your perimeter routers are using RACLs to prevent incoming traffic. A hacker knows about the use of RACLs and wants to gain access to the device he has hacked into, probably through a virus or worm spread through an e-mail attachment. To get around the RACLs, the hacker has the internal machine periodically open a TCP connection to his own PC. The hacker's software then disconnects the session but does not go through the hand-shake process of tearing down the connection. The hacker's software then starts up a Telnet process on the port just closed. In this situation, the RACL entry is still there until it times out. The hacker can take advantage of this by setting up a Telnet connection with the three-way TCP handshake to the internal device on the previously used port. From the Cisco IOS perspective, it looks like this is a continuation of the previous TCP connection; in reality, it is a new TCP connection, but with the same source and destination addresses and port numbers. The problem with the RACL implementation is that, for TCP, it does not examine the inbound TCP control flags to determine the direction of the flow of traffic.

This same issue can be applied to the other protocols. As long as the hacker can compromise an internal device, have that internal device initiate an outbound connection, and prematurely terminate the connection, the hacker can use the temporary RACL entry to gain access to the internal device. Therefore, even by using RACLs, you are exposing yourself, even in a limited way, to specific kinds of attacks.

Application Issues

The second problem with RACLs is that they do not work with all session layer applications. Examples of some of these applications include FTP and multimedia, such as RTSP, H.323, VoIP, and many others. With these applications more than one connection is involved in sharing information between the devices. Typically, the first connection is a control connection, and the second and subsequent connections are data, error, and synchronization connections. How these extra connections are set up is random: Sometimes the client sets them up, and other times the server sets them up. In some instances, the ports that the connections use are standardized; sometimes they fall within a range, and sometimes they are completely random.

Standard FTP Example

Unfortunately, RACLs have problems with these types of additional connections. This section looks at how FTP uses connections to illustrate this problem. Figure 8-6 displays the two types of modes that FTP supports: standard (active) and passive. With a standard connection, the FTP client chooses a random TCP port number greater than 1023 for the source and connects to port 21 on the server. This is called the control connection, and FTP commands are passed across this connection. As soon as the user wants to get data from the server or load data to the server, the client tells the server of the data exchange, as well as the port number to use to connect to on the client (higher than 1023). The server opens the data connection by connecting back to the client's specified data port from its local data port (the source port is 20).

Figure 8-6. FTP Connections

[View full size image]

Next you will look at how this affects a router with RACLs, from two perspectives with standard FTP: with the client inside the network and the server outside, and then vice versa.

Client on the Inside

The first standard FTP example assumes that the FTP client is inside the network and that the server is outside. In this example, RACLs have been configured and the external extended ACL denies all inbound traffic by default. When the client initiates the port 21 connection to the server, a RACL entry is created to allow the returning traffic from the server for this connection. However, as soon as the client retrieves data from the server, and the server tries to open a connection back to the client, it fails. Unfortunately, the RACL entry and the extended external ACL do not allow this second connection. You could get around this problem by allowing any TCP source port 20 connection going to a destination port greater than 1023 into your network with an extended ACL entry, but this presents a security risk.

Client on the Outside

The second standard FTP example assumes that the FTP client is outside the network and that the server is inside. In this example, RACLs have been configured and the external extended ACL denies all inbound traffic, by default, with the exception of the external users trying to access the internal FTP server (TCP port 21). When the client initiates the port 21 connection to the server, the extended ACL permits the connection. When the client tries to upload or download data, the server sets up a connection back to the client; the Cisco IOS adds the RACL entry for this second connection (allowing the client to send traffic to the server on this connection). In this example, the client has no problems with bidirectionally communicating with the FTP server on a standard connection.

Passive FTP Example

With a passive connection, the FTP client chooses a random TCP port number greater than 1023 for the source port and connects to port 21 on the server. This is called the control connection, and commands are passed across this connection. As soon as the user wants to get data from the server or load data to the server, the client opens a new connection to the server from an unused random port greater than 1023. The server tells the client what destination port number to use (across the control connection), which is typically a random port number greater than 1023 that is not being used currently on the server.

Now you will look at how this affects a router with RACLs. I examine this from two perspectives with passive FTP, just as I did with standard FTP: with the client inside the network and the server outside, and then vice versa.

Client on the Inside

The first passive FTP example assumes that the FTP client is inside the network and that the server is outside. In this example, RACLs have been configured and the external extended ACL denies all inbound traffic, by default. When the client initiates the port 21 connection to the server, a RACL entry is created to allow the returning traffic from the server. When the client attempts to retrieve data from the server, the client opens up a second connection to the FTP server, which is successful (unlike with standard FTP). With passive FTP, the client initiates the second connection. When the Cisco IOS sees that the internal client is initiating a session, it adds the session information as a temporary ACL entry in the RACL, allowing the returning traffic from the server back into the network. In this example, there is no issue with passive FTP and RACLs.

Client on the Outside

The second passive FTP example assumes that the FTP client is outside the network and that the server is inside. In this example, RACLs have been configured and the external extended ACL denies all inbound traffic, by default, with the exception of the external users trying to access the internal FTP server (TCP port 21). When the client initiates the port 21 connection to the server, the extended ACL permits the connection. Then when the client tries to upload or download data, the client tries to establish the data connection to the server on the prenegotiated port numbers greater than 1023. Unfortunately, because RACLs build temporary entries for outbound traffic, and this is inbound traffic, the connection is not allowed.

Copyright eTutorials.org 2008-2023. All rights reserved.