Verbose ACL logging

By stretch | Thursday, January 8, 2009 at 12:00 a.m. UTC

Cisco IOS provides the capability to log matches against access list expressions by appending the log or log-input keyword to a statement. By enabling ACL logging we can harness a great deal more detail than simple packet counters provide. For example, consider the following topology:

topology.png

An ACL has been created to block SSH traffic on R1, and applied inbound on the FastEthernet0/0 and FastEthernet0/1 interfaces:

Extended IP access list Block_SSH
    10 deny tcp any any eq 22
    20 permit ip any any

When an administrator attempts to SSH to R1 from one of the other routers, the TCP connection is rejected by R1 and its ACL counter increased appropriately:

R2# ssh 1.1.1.1
% Destination unreachable; gateway or host down
R1# show ip access-lists
Extended IP access list Block_SSH
    10 deny tcp any any eq 22 (3 matches)
    20 permit ip any any (24 matches)

The stock ACL counters give us a good idea of how much traffic is being allowed or rejected, but not where that traffic is coming from (or going to). We can alter the first entry in our Block_SSH ACL and append the log keyword to log matches.

R1(config)# ip access-list extended Block_SSH
R1(config-ext-nacl)# no 10
R1(config-ext-nacl)# 10 deny tcp any any eq 22 log
R1(config)# ^Z
R1# show ip access-lists
Extended IP access list Block_SSH
    10 deny tcp any any eq 22 log
    20 permit ip any any (444 matches)

Now SSH traffic will continue to be blocked and the ACL counters to increase, but the router will also generate a log message indicating when the match occurred, where the packet came from, and where the packet was headed:

%SEC-6-IPACCESSLOGP: list Block_SSH denied tcp 10.0.12.2(28467) -> 1.1.1.1(22), 1 packet

This is certainly handy, but what if we expand our topology to include a LAN (192.168.0.0/24) attached to both R1 and R2?

topology2.png

Imagine R2 and R3 are also supposed to be blocking SSH traffic, but one of them has had its ACL mistakenly erased. If a user from the LAN attempts to SSH to R1 via the unsecured router, the traffic will still be blocked at R1, but the log message won't help us determine where the leak is:

%SEC-6-IPACCESSLOGP: list Block_SSH denied tcp 192.168.0.42(30316) -> 1.1.1.1(22), 1 packet

To provide even more detail in our ACL log entries, we can replace the log keyword with log-input. log-input includes all the detail provided by log plus some handy layer two information.

R1(config)# ip access-list extended Block_SSH
R1(config-ext-nacl)# no 10
R1(config-ext-nacl)# 10 deny tcp any any eq 22 log-input
R1(config-ext-nacl)# ^Z
R1# show ip access-lists
Extended IP access list Block_SSH
    10 deny tcp any any eq 22 log-input
    20 permit ip any any (1683 matches)

Here's what the log records when the same SSH attempt from the LAN is repeated:

%SEC-6-IPACCESSLOGP: list Block_SSH denied tcp 192.168.0.42(15111) (FastEthernet0/1
 c203.73ae.0001) -> 1.1.1.1(22), 1 packet

Now we can easily determine both the incoming interface (FastEthernet0/1) and the source MAC address from the prior hop (c203.73ae.0001). Note that this MAC belongs to R3, not the origin host. These attributes clearly point to R3 as the unsecured router, and we can now move to secure it.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Security

Comments


Peter (guest)
January 8, 2009 at 12:30 a.m. UTC

Hi,
Great work !!!

offtopic
Did you know why in OSPF appears DR 0.0.0.0 and BDR 0.0.0.0.


Roland Dobbins (guest)
January 8, 2009 at 4:46 a.m. UTC

Logging ACL hits can easily become a self-DoS in high-traffic situations due to the CPU consumed to generate the syslog output. Rate-limiting is available, but then one loses granularity.

NetFlow telemetry export/collection/analysis is generally a much better way to gain visibility into network behaviors, classify attack traffic, et. al.


Smail (guest)
January 8, 2009 at 7:34 a.m. UTC

Nice. I always use the log command. Have not used the log-input command though.

Once I had a problem with NAT on a 800 series router where I used the log command and NAT would not work. When I wrote the ACL without log again, it worked.


MattG (guest)
January 8, 2009 at 8:59 a.m. UTC

Very useful.


Marcus (guest)
January 8, 2009 at 7:20 p.m. UTC

Thanks for that post.
Very useful


m__ (guest)
February 4, 2009 at 10:56 a.m. UTC

I have the same problem with NAT when "log" in ACL was used - router 2811, full IOS image. But I have not found explanation for this behavior yet. Does anyone have experience with this problem?

Once I had a problem with NAT on a 800 series router where I used the log command and NAT would not work. When I wrote the ACL without log again, it worked.


Ravi (guest)
January 30, 2013 at 9:13 p.m. UTC

Useful information. I learnt something new today and I thank you for that.


Josh Blaylock (guest)
September 25, 2013 at 6:01 p.m. UTC

The "log" command did not work when you applied it to an access list used with NAT, because IOS at the time of this posted article did not support the "log" command for use with NAT.

From Cisco documentation:

Q. Does Cisco IOS NAT support ACLs with a "log" keyword?

A. When you configure Cisco IOS NAT for dynamic NAT translation, an ACL is used to identify packets that can be translated. The current NAT architecture does not support ACLs with a "log" keyword.

reference: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml

Comments have closed for this article due to its age.