Reflexive Access Lists

December 10th, 2007 neteng

Starting with this post, I’m going to attempt a new format to my lab-type articles. I want to try and maintain some consistency between my presentations, in the hope that they will be cleaner and easier to comprehend. With that in mind, let’s get started!

Topic

Reflexive ACLs

Definition

Reflexive ACLs provide network engineers the tools to implement session filtering, albeit rather crudely. Their creation and application are almost identical to standard and extended access lists, but they are used to create dynamic entries for return traffic when an outgoing connection is attempted. Essentially, dynamic ACL entries are built on the return-traffic interface to allow the other side of the traffic pair to come in. This way, you can practically have an ip deny any any rule on your outside interface (untrusted network) and only allow traffic to come in that was initiated from your inside (trusted) network. Now, this can already be achieved somewhat through the established keyword when creating an access-list; but this only applies to TCP traffic. Reflexive ACLs will keep track of traffic pairs for UDP, ICMP, etc.

For TCP sessions, dynamic entries are removed 5 seconds after two FIN flags are detected (the five seconds allows a graceful shutdown window), or immediately after matching a TCP packet with a RST flag. Entries for all protocols will be removed if idle for the timeout period. One gotcha with reflexive ACLs is when using applications that switch port numbers during a session. A key example of this is FTP. Passive-mode FTP must be used so that a dynamic port is not requested for data transfer traffic.

Before deploying reflexive ACLs, you need to look at your network/traffic flows, and determine how to apply them to your interfaces. Logically, you have two types of interfaces: internal and external. The most typical scenario is to apply the ACLs to the untrusted external network interface (i.e. Internet) of your router. If you happen to have multiple interfaces on the router (i.e. internal, external and DMZ), then you will probably want to configure the reflexive ACLs on your trusted internal interface so as not to affect traffic initiated from the outside to your DMZ.

Reflexive ACLs can only be defined through named extended access lists, but they can be called from other types of access-lists (standard numbered, etc.).

Example

In our example, we’re going to use a simple inside/outside interface configuration. The first thing we need to look at is our traffic policy. The IT manager has decided that he wants to only allow people to surf the web (HTTP/HTTPS) and deny all other traffic. With that in mind, we need to construct an outbound access-list that will reflect our outgoing traffic to an inbound access-list. Basically, outgoing entries will be mirrored, with the incoming and outgoing hosts flipped in the ACL statement. Here’s our topology:

Our configuration will go onto R2. We will initiate traffic from R1 to R3.

With the policy in mind, let’s start our configuration off by creating our access-lists:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip access-list extended OUTBOUND
R2(config-ext-nacl)#permit tcp any any eq 80 reflect WEB
R2(config-ext-nacl)#permit tcp any any eq 443 reflect WEB
R2(config-ext-nacl)#deny ip any any

Of course, the deny ip any any statement at the end is implied, but I put it in for clarity. You can see that we are reflecting all outbound HTTP/HTTPS traffic to a dynamic ACL named WEB. What we will now do is reference WEB in the inbound ACL so that it will be evaluated before permitting or denying traffic:

R2(config)#ip access-list extended INBOUND
R2(config-ext-nacl)#evaluate WEB
R2(config-ext-nacl)#deny ip any any

Now let’s apply them to our outside interface (FastEthernet1/0):

R2(config)#int fa1/0
R2(config-if)#ip access-group OUTBOUND out
R2(config-if)#ip access-group INBOUND in

Let’s take a look at our ACLs:

R2#show access-list
Extended IP access list INBOUND
10 evaluate WEB
20 deny ip any any
Extended IP access list OUTBOUND
10 permit tcp any any eq www reflect WEB
20 permit tcp any any eq 443 reflect WEB
30 deny ip any any
Reflexive IP access list WEB

You can see that we our reflexive ACL WEB is listed, but currently is devoid of entries. For our test, lets enable HTTP services on R3:

R3(config)#ip http server

Now let’s initiate some HTTP traffic from R1 to R3 and then take a look at our reflexive ACL again:

R2#show access-lists
Extended IP access list INBOUND
10 evaluate WEB
20 deny ip any any
Extended IP access list OUTBOUND
10 permit tcp any any eq www reflect WEB (8 matches)
20 permit tcp any any eq 443 reflect WEB
30 deny ip any any
Reflexive IP access list WEB
permit tcp host 150.1.3.3 eq www host 192.168.12.1 eq 14867 (12 matches) (time left 294)

And there we have it! You can see that there is a timer associated with the dynamic entry. The default is 5 minutes, but this can be changed with the ip reflexive-list timeout command.

If we tried to send uninitiated traffic from R3 to R1, it would not pass the evaluate statement and therefore, be dropped due to the deny ip any any statement.

Well, that’s about all there is to it folks! Remember, if we ran into a situation where we needed to apply the ACLs to the internal interface, we would simply change the direction in which the reflect and evaluate statements are applied. The reflect statements would now be on the inbound ACL and the evaluate statements would applied to the outbound ACL.

I hope this has been helpful for you!

References

Configuring IP Session Filtering (Reflexive Access Lists) - Cisco.com

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in HOWTO, Networking, Security | 1 Comment »

TCP Intercept

December 4th, 2007 neteng

On the Internet, TCP is widely used by many applications, web servers being the most obvious. In the early days of the Internet, prior to the plethora of firewalls and security appliances now in place at most companies, it was relatively simple to instigate a Denial of Service (DoS) attack on a server listening on a TCP port. A malicious person could continuously open TCP connections to such a server and render it useless, as the CPU would be pegged trying to process and reply to the connections. Here’s a little reminder of TCP’s three-step handshake process:

Now there are smarter devices out there to mitigate these types of attacks, but in a pinch, IOS can prove to be useful until a more dedicated piece of equipment is in place. If you’re using vanilla-IOS, without the IOS Firewall feature (CBAC), TCP Intercept is your key to protection. It can be configured to run in two modes:

Intercept

Intercept mode is the default. The router will actually intercept incoming SYN packets and sends a SYN/ACK response on behalf of the server. If an ACK is then received by the router, it will forward the original SYN to the server and let the handshake process take it’s natural course.

Watch

In this mode, the router allows the SYN packets to come into the server, but watches the connection until it’s established. If the connection has failed to complete after the watch-timeout expires (default of 30 seconds), the routers sends a RST to the server to clear up the connection.

This is the basic operation of TCP Intercept. To enable it, we first need to define an access-list for the traffic that will be affected. It’s common practice to cover traffic from any source but towards specific destinations (i.e. web servers, terminal servers). Once the access-list is defined, we can enable TCP Intercept with a single command in global configuration mode:

ip tcp intercept list access-list-number

The mode can also be changed:

ip tcp intercept mode {intercept | watch}

As the connection attempts continue to mount and the router begins to sense an attack is in progress, it enters into what’s termed aggressive mode. This mode can be entered through two different ways: The total number of incomplete connections or the number of connection requests within a one-minute period. These values can be adjusted with the following commands:

Total number of incomplete connections

ip tcp intercept max-incomplete high number - Sets the threshold for triggering aggressive mode.
ip tcp intercept max-incomplete low number - Sets the threshold for stopping aggressive mode.

Number of connection requests within one-minute period

ip tcp intercept one-minute low number - Sets the threshold for stopping aggressive mode.
ip tcp intercept one-minute high number - Sets the threshold for triggering aggressive mode.

The three other adjustable timers for TCP Intercept include:

watch-timeout - Default of 30 seconds. This changes the time allowed for the TCP connection to become established.
finrst-timeout - Default of 5 seconds. This changes the time allowed for receipt of a RST or FIN before the connection is dropped.
connection-timeout - Default of 24 hours. This changes the amount of time the router will manage an idle connection.

The last bit of adjustment we can make is the way in which connections are dropped when operating in aggressive mode. The default is to have the oldest connections dropped, but we can change this to random:

ip tcp intercept drop-mode {oldest | random}

As always, let’s get our hands dirty and configure this in a live network:

R1 is acting as our host. We’re going to have him telnet to the telnet server (which is really a router with a loopback interface - 150.1.3.3) and turn on TCP Intercept mode at R2 in the middle.

R2 is configure with the following statements:

access-list 101 permit tcp any any
ip tcp intercept list 101

We’ll initiate a telnet connection from R1. Let’s take a quick peek at our connections and statistics in action:

R2#sh tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
192.168.12.1:53517 150.1.3.3:23 ESTAB 00:00:02 23:59:58 I

R2#sh tcp intercept statistics
Intercepting new connections using access-list 101
0 incomplete, 0 established connections (total 0)
0 connection requests per minute

Now to put TCP Intercept to work, I decided to block inbound SYN packets at R1 by configuring an ACL on the outgoing interface:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#access-list 150 deny tcp host 150.1.3.3 any syn
R1(config)#access-list 150 permit ip any any
R1(config)#int fa0/0
R1(config-if)#ip access-group 150 in

Let us once again initiate a telnet session from R1 to our telnet server. Aha! We see a different story on R2:

R2#sh tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode
192.168.12.1:59187 150.1.3.3:23 SYNRCVD 00:00:02 00:00:00 I

Established:
Client Server State Create Timeout Mode

R2#sh tcp intercept statistics
Intercepting new connections using access-list 101
1 incomplete, 0 established connections (total 1)
1 connection requests per minute

There you have it! The basics of TCP Intercept. Something to keep in mind is that this security service is named TCP Intercept for a reason. Any other kind of DoS attack (through UDP or ICMP) that is instigated towards the other side of that router will not be affected as those are connectionless protocols and therefore do not have a state that can be easily tracked.

I hope you enjoyed this article.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in HOWTO, Networking, Security | 1 Comment »