Re: IOS Vulnerability, Loose connectivity applying the recommend

guibor_p · ‎07-22-2003

Hello All!

When I apply the following ACL...

access-list 105 deny 53 any any

access-list 105 deny 55 any any

access-list 105 deny 77 any any

access-list 105 deny 103 any any

access-list 105 deny ip 10.0.0.0 0.255.255.255 any

access-list 105 deny ip 127.0.0.0 0.255.255.255 any

access-list 105 deny ip 172.16.0.0 0.15.255.255 any

access-list 105 deny ip 192.168.0.0 0.0.255.255 any

access-list 105 deny ip host 255.255.255.255 any

access-list 105 deny ip 209.69.xx.xx 0.0.0.31 any

access-list 105 deny ip 209.69.xx.xx 0.0.0.15 any

access-list 105 permit ip any any

the first couple of (new) lines get processed and then all of a sudden the router slows WAY down and traffic can no longer can transit the router and it needs to be reloaded. Below is the output of the "sh ver" command...

Cisco Internetwork Operating System Software

IOS (tm) C2600 Software (C2600-I-M), Version 12.2(5a), RELEASE SOFTWARE (fc1)

Compiled Thu 04-Oct-01 19:37 by pwade

Image text-base: 0x80008088, data-base: 0x80989210

ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)

McKinleyAssociates-gw uptime is 28 minutes

System returned to ROM by power-on

System image file is "flash:c2600-i-mz_122-5a.bin"

cisco 2611 (MPC860) processor (revision 0x203) with 20480K/4096K bytes of memory.

Processor board ID JAB033900Y9 (2502324674)

M860 processor: part number 0, mask 49

Bridging software.

X.25 software, Version 3.0.0.

2 Ethernet/IEEE 802.3 interface(s)

2 Serial network interface(s)

32K bytes of non-volatile configuration memory.

8192K bytes of processor board System flash (Read/Write)

Configuration register is 0x2102

The above access list (105) is applied inbound on the serial interfaces. This router is an Internet border router.

Any help regarding this matter would greatly be appreciated.

Paul

thisisshanky · ‎07-22-2003

What does a show buffer reveal ? Does it give any clue that the interfaces are blocked?

Does the 10.0.0.0, 172.16.0.0, 192.168.0.0 and 209.x.x.x network, belong to you? Then the source and destination network fields in the access-list 105, starting from line 5 through 11 needs to be swapped, for those lines to function properly

Sankar Nair
UC Solutions Architect
Pacific Northwest | CDW
CCIE Collaboration #17135 Emeritus

guibor_p · ‎07-22-2003

The interfaces are not being blocked at THIS time. The 10., 172.16., 192.168., 209.x.x.x are nothing more than anti spoofing entries and were in place and working prior to the addition of the IOS vulnerability work-around. Cisco states...

http://cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml#workarounds

"ACLs can have performance impact on certain platforms, so care should be taken when applying the recommended workarounds."

Do we know what platforms they are referring to?

Paul

thisisshanky · ‎07-22-2003

I think, that statement, was only talking about Access lists in general. When you configure access-list on an interface, processing of packets on that interfaces switches to Process switching. This can impact operation of certain low end platforms, if the number of packets being processed are high in number.

Sankar Nair
UC Solutions Architect
Pacific Northwest | CDW
CCIE Collaboration #17135 Emeritus

ryan_moffett · ‎07-22-2003

When you enter the new ACL, are you temporarily removing from the interface prior to entering the new ACL? If not, then you are going to run into problems because if the ACL is still applied to the interface and you enter this new ACL, there are no permit statements until the very end. As the ACL is applied line-by-line, no traffic is technically permitted. For example, the very first line of your ACL, "access-list 105 deny 53 any any" doesn't permit any traffic, and at that time, the only other component of the ACL is the implicit deny all at the end. So effectively, right there, you built a deny all ACL on that interface. When this occurs, it takes a few seconds for it to fully take effect and then gradually, you drop your telnet session (if you are using out-of-band) management and you see traffic gradually grind to a halt of the course of several seconds. I have seen this happen dozens of times and it can always be avoided by removing the ACL from the interface, then removing the old ACL, entering the new ACL and re-applying the ACL to the interface.

guibor_p · ‎07-22-2003

Sounds logical, I'll first remove the access list from the interface, then remove it globally, then rebuild the list globally with the new lines and finally re-apply it at each interface and life should be good right?

Thanks for your help! I'll try this after hours this time.

Paul

hbaerten · ‎07-22-2003

This method leaves you unprotected for a few seconds, so if you're paranoid (or when you are under attack at the time of modification), a slightly better method is:

- define the new acl with a different name/number

- apply the new acl on the interface, replacing the old one immediately

- delete the old acl

regards

Herbert

guibor_p · ‎07-23-2003

That worked great, thanks for all who replied!!!

IOS Vulnerability, Loose connectivity applying the recommended ACL