Lesson 12 -- Access Control Lists

A few days after setting up the LAG groups between the two 2924 switches, you start to receive a number of phone calls from users in the main office, who are again complaining of poor network performance. You telnet to the switches, and sure enough, they seem to be responding more sluggishly than normal. You begin checking network interfaces, and see that utilization is abnormally high on a number of ports. On a lark, you start sniffing network traffic on the Ethernet port of your laptop using tcpdump, and see a large number of connection attempts on ports 80, 135-139, and 3128:

me@myllt:~$ sudo tcpdump -envi eth0 -s0 port 80 or port 135 or port 136 or port 137 or port 138 or port 139 or port 3128
[sudo] password for me:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:14:23.538876 00:05:9b:be:cf:60 > 00:15:c5:08:5d:92, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 44, id 14733, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.114.63816 > 192.168.1.66.80: Flags [.], cksum 0x2827 (correct), ack 2159576407, win 1024, length 0 14:14:23.538907 00:15:c5:08:5d:92 > 00:05:9b:be:cf:60, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.66.80 > 192.168.1.114.63816: Flags [R], cksum 0x2c33 (correct), seq 2159576407, win 0, length 0 14:14:23.562432 00:05:9b:be:cf:60 > 00:15:c5:08:5d:92, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 58, id 53140, offset 0, flags [none], proto TCP (6), length 40)
<...snip...>
me@myllt:~$


You know that port 80 is the well-known port for HTTP and that ports 135-139 are well-known ports for Microsoft Windows file sharing (SMB/CIFS). However, it is port 3128 that really gets your attention. A number of worms and trojans have attempted to use port 3128 as a back door to compromised machines. You suspect someone may have a desktop or laptop with a virus, as a result of the tcpdump output, so you create an access control list on your router to block all traffic from the source IP address while you start investigating the problem:

lab2651rtr# conf t
lab2651rtr(config)# access-list 1 deny 192.168.1.114 0.0.0.0
lab2651rtr(config)# access-list 1 permit any


That created an appropriate filter, but it did not tell the router to actually start filtering any traffic. Before the access list can take effect, we have to apply the filter to the network interfaces. Unfortunately, here is where we have made things a little difficult. Because we are using 802.1Q VLAN trunking, we have to apply the ACL ("Access Control List") to each sub-interface -- we can't just apply it to FA0/0 on the router (I tried...):

lab2651rtr(config-if)#int fa0/0.1
lab2651rtr(config-subif)#ip access-group 1 in
lab2651rtr(config-subif)#int fa0/0.2
lab2651rtr(config-subif)#ip access-group 1 in
lab2651rtr(config-subif)#int fa0/0.3
lab2651rtr(config-subif)#ip access-group 1 in
lab2651rtr(config-subif)#int fa0/0.4
lab2651rtr(config-subif)#ip access-group 1 in
lab2651rtr(config-subif)#int fa0/0.5
lab2651rtr(config-subif)#ip access-group 1 in
lab2651rtr(config-subif)#int fa0/0.6
lab2651rtr(config-subif)#ip access-group 1 in
lab2651rtr(config-subif)#int fa0/0.7
lab2651rtr(config-subif)#ip access-group 1 in


Running tcpdump again, you see that you have now blocked all incoming traffic from this host (sort of -- you have blocked all traffic coming through the router, but this host will still be scanning and potentially infecting the rest of the hosts on that same subnet on the switch, since the router is only blocking traffic trying to hit other subnets). As you turn your attention to the switch to try to find the source of the problem so you can disable the switch port, however, you start to see traffic flooding your network again, this time, just hitting port 3128 but coming from a myriad of IP addresses:

<...snip...>     192.168.1.119.55092 > 192.168.1.66.3128: Flags [FPU], cksum 0x8dab (correct), seq 532322015, win 1024, urg 0, length 0
14:35:51.969318 00:15:c5:08:5d:92 > 00:05:9b:be:cf:60, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.66.3128 > 192.168.1.119.55092: Flags [R.], cksum 0x91bf (correct), seq 0, ack 532322016, win 0, length 0
14:35:52.775074 00:05:9b:be:cf:60 > 00:15:c5:08:5d:92, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 50, id 46336, offset 0, flags [none], proto TCP (6), length 40)
    192.168.1.120.40785 > 192.168.1.66.3128: Flags [FPU], cksum 0xc243 (correct), seq 2778797122, win 1024, urg 0, length 0
14:35:52.775146 00:15:c5:08:5d:92 > 00:05:9b:be:cf:60, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
<...snip...>

You could just turn off the port on the router, but that would deny service to everyone in the same subnet as the affected machine. You could also create another standard access list that blocks all of the IP addresses that the traffic is now coming from, but again, it looks like that would be every host in the source subnet. You would like to create an access list that is as minimally invasive as possible, while still achieving the desired goals, so you decide to create an extended access list, which will allow you to filter by port (protocol) rather than simply source address (it would also allow you to filter by destination, but that's not a factor in this case):

lab2651rtr# conf t
lab2651rtr(config)# access-list 101 deny tcp any any eq 3128
lab2651rtr(config)# access-list 101 deny udp any any eq 3128
lab2651rtr(config)# access-list 101 permit tcp any any
lab2651rtr(config)# access-list 101 permit udp any any
lab2651rtr(config)# int fa0/0.1
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# int fa0/0.2
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# int fa0/0.3
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# int fa0/0.4
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# int fa0/0.5
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# int fa0/0.6
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# int fa0/0.7
lab2651rtr(config-subif)# no ip access-group 1 in
lab2651rtr(config-subif)# ip access-group 101 out
lab2651rtr(config-subif)# exit
lab2651rtr(config)# exit


Now, to make sure the ACL is working:

lab2651rtr# sho ip access-lists
Extended IP access list 101
    deny tcp any any eq 3128 (27 matches)
    deny udp any any eq 3128
    permit tcp any any
    permit udp any any (15 matches)
lab2651rtr#


You verify with tcpdump that the problem has been temporarily minimized, and then spend a while analyzing the data from tcpdump to try to identify the source of the network traffic. You notice that all of the source IP addresses are from a single subnet, 192.168.1.112/28, which is in use by Sales (VLAN 6), so you look at MAC addresses on the first switch to see who is on-line:

lab2924a# sho mac vlan 6
<...snip...>
Destination Address Address Type VLAN Destination Port
------------------- ------------ ---- --------------------
0005.9bbe.cf60      Dynamic         6 FastEthernet0/3
0024.e8cb.f9e9      Dynamic         6 FastEthernet0/1
lab2924a#


From this, you know that the compromised host is on the second switch, since Fa0/3 is the port to the file server, and Fa0/1 is one of the ports in LAG group to the second switch. You telnet to the second switch and repeat the same command:
< lab2924b#sho mac vlan 6
<...snip...>
Destination Address Address Type VLAN Destination Port
------------------- ------------ ---- --------------------
0003.e3e4.f881      Dynamic         6 FastEthernet0/2
0005.9bbe.cf60      Dynamic         6 FastEthernet0/2
0024.e8cb.f9e9      Dynamic         6 FastEthernet0/14
lab2924b#


Fa0/2 is the second port in the LAG group from the first switch, but the third line contains the information you needed. Fa0/14 is an access port to the Sales group, and therefore, that's almost certainly where the offending traffic is coming from. You shut down the port on the switch, then remove the ACL from VLAN 3 (IT) on the router to see if you are still seeing the port scans:

lab2924b(config)# int fa0/14
lab2924b(config-if)# shut


...and on the router:

lab2651rtr# conf t
lab2651rtr(config)#int fa0/0.3
lab2651rtr(config-subif)#no ip access-group 101 out
lab2651rtr(config-subif)#


Satisfied that you have stopped the flood of malicious traffic, you head to the Sales department to try to find out whose computer was compromised.

Note: Be aware that, while you can create a crude firewall with the ACL features on Cisco routers, you should try to filter as little as possible. Cisco routers, or for that matter, most comparable vendors' routers (with the exception of ImageStream routers which are actually full-fledged PC's with multiple Ethernet interfaces, running a Linux kernel and using iptables for firewalling) simply don't have enough horsepower to do complex firewalling. As an extreme example, I once tried to use a Cisco 806 SOHO router (admittedly, a very low-end box with minimal processing power) as a DSL router/firewall. It worked well as a router, but once I started applying ACL's to the 806, I noticed a definite slow-down on throughput. A cheap, $35 Linksys DSL router/firewall had more than enough CPU to route, NAT and firewall, but the 806 simply couldn't keep up with the ACLs required to NAT and firewall the DSL connection.