Wednesday, July 20, 2011

Cisco Access List Using Established Parameter


The above diagram is a rough drawing of my situation. I have two Cisco routers at my headquarters. Each router is on a separate ISP. The store router will create a DMVPN tunnel to each router and use it for failover. That way if we have a problem with a provider at our headquarters the stores can keep doing business as usual.

The store only needs access to a few things at headquarters. I need to keep the traffic from the store network into my headquarters as limited as possible.

I could apply an access list to the store router, but if the store router's physical security is compromised an attacker could perform a password reset and remove my access list. That means I need to apply my access list to the routers at headquarters. I can control their physical security and they would be much more difficult to gain access to.

I asked myself, how can I keep my store access very limited, but still allow any traffic originating from headquarters to get to the stores?

That is when I found out about the "established" parameter for an access list. Here's how it works:

This access list is applied to the outbound direction of the inside interfaces on the headquarters routers.


access-list 110 remark APPLIED TO INSIDE INTERFACE OUTBOUND
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.197
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.161
access-list 110 permit icmp 192.168.10.0 0.0.0.255 host 172.16.1.183
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq snmp host 172.16.1.183
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq 1645 host 172.16.1.203
access-list 110 permit tcp any 172.16.1.0 0.0.0.255 established

Let's break it down:


****Use remarks so you can easily see the purpose of the ACL****
access-list 110 remark APPLIED TO INSIDE INTERFACE OUTBOUND

****Allow traffic from my store to get to the reporting servers****
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.197
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.161

This is the most important to keep up. This section is what keeps my stores doing business.


****Allow SNMP traffic between my server and the store****
access-list 110 permit icmp 192.168.10.0 0.0.0.255 host 172.16.1.183
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq snmp host 172.16.1.183

The SNMP server only needs ICMP traffic and SNMP traffic. This will allow me to know if the router goes down. Now you may say, why do you need these lines in the ACL if the SNMP server is polling the router and the ping is initiated from the server. I thought the same thing and I will explain it in just a minute.


****Allow RADIUS traffic from the store router to my server****
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq 1645 host 172.16.1.203

This line allows my router to send authentication requests to my RADIUS server.


****Allow return traffic for any traffic sourced from headquarters.
access-list 110 permit tcp any 172.16.1.0 0.0.0.255 established

This line checks to see that the traffic headed to the headquarters was previously established from the headquarters.


Now that we have the ACL broken down let's look at the mechanics. Remember this ACL is applied on the OUTBOUND side of the headquarter inside interfaces. On the INBOUND side I am allowing any traffic from headquarters to go to the store. Since this is not a stateful firewall I must account for the return traffic.

The last line in the ACL uses the parameter "established". Basically, this will look at the TCP packet and see if there is an ACK or RST bit set. If the traffic coming is trying to create a new connection it will be denied, but if it is responding to a connection that was initiated from the headquarters network it will be allowed.

Now, back to the lines used for SNMP. While it is true, that the connection for SNMP originates on my headquarters network, this traffic will not be allowed back through without explicitly allowing it. This is because ICMP and UDP are connection-less (SNMP uses UDP ports). In other words, it does not use TCP and it does not have an ACK or RST bit to set.

This is sort of like a stateless firewall. It allows traffic that has already been connected. The difference is we don't know what the traffic is and we are assuming that the traffic is a legitimate response. This is not a replacement for a firewall by any means, but it is a nice enhancement for your access lists.

No comments:

Post a Comment