CCIE Lab

ACL are usually configured for firewall configurations, for traffic filtering. When configuring ACLs, careful planing should be made so that in the moment when you are applying an ACL, things get filtered exactly the way you want it. In a lab environment tests can be made and if somethings doesn’t work right, you can start over. But in a live network router, filtering the wrong traffic could cause network outages.

If you are connected to the router via telnet or ssh (most likely in productions routers) it is very easy to lock yourself out of the router by denying the telnet or ssh traffic on an interface between you to that router. This is mostly because how IOS works. Any commands given in IOS are instantly commited to the live configuration. And, for example, if you make a configuration with an ACL and you forget about the implicit deny any (any) and you also forget to permit the telnet/ssh traffic, you might find yourself with the router not responding to any input after you apply the rules. It might take a while to figure out that you can’t access the router anymore and need to got physically to it’s location and either reload it or  use the console port to remove the ACL from the running-config.

One way of avoiding this is to schedule an automated reload in 10-15 minutes, while you are configuring, From enable mode issue the command:

#reload in MINUTES

This will reload the router after the specified number of minutes. It will ensure that if you lock yourself out, the router will revert back to the working startup-config. If the configuration was applied successfully, you can cancel the scheduled reload with the command

#reload cancel

Ok, this will be a short one . I just want to raise attention on how can one bypass an extended (or standard) ACL (or access-list).

So, for this example, i have one router with an IP address of 10.10.10.2, which can be accessed only by the admin, only from 20.20.20.20. That is done with an inbound ACL, put on the egress interface of the router. Looks like this:

Extended IP access list 111

20 permit ip host 20.20.20.20 host 10.10.10.2 log

There is a little problem with spoofing: the return traffic has to be routed back to the attacker. But everything will work just fine if you happen to be in the same network with the admin (you can achieve bidirectional communication). In case the attack is done over the Internet, there is still the possibility of a DOS (Denial Of Service), by sending tons of packets that will be accepted. I assumed another thing: your ISP does not check for the source of the packets (DOS attacks are less frequent if that simple measure is taken).

For the demonstration, i chose a well-known packet crafter named HPING3. It allows one to customize a packet at different layers and it`s well documented, but for now we will only use a fraction of it`s power:

$ sudo hping3 -S 10.10.10.2 -a 20.20.20.20

The result could be:

*Mar 1 05:52:01.702: %SEC-6-IPACCESSLOGP:

list 111 permitted tcp 20.20.20.20(0) -> 10.10.10.2(0), 360 packets

To check the amount of pings, you can issue the command “show ip traffic | section ICMP“. You can “clear ip traffic” before that.

Despite this, ACLs are still adding a serious amount of security to your network. But in front of a determined attacker, one should do more than that in order to have a healthy network.