North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

TCP session disconnection caused by Code Red?

  • From: Blaz Zupan
  • Date: Mon Aug 06 14:03:51 2001

I'm seeking the collective wisdom of this list to try to prove that I'm
not halucinating.

For the last few days, our network seems to be basically unreachable from the
outside. Most incoming TCP sessions (web requests, incoming mail, telnet
sessions, etc.) often fail with a simple "Connection refused" like nobody is
listening on that port (but of course there is a server running on the port).
It does not matter which service I'm trying to connect to, it also does not
matter which server I'm connecting to. It happens randomly, i.e. three
successive connections fail, then 5 connections succeed, then 2 connections
fail, etc. Outgoing connections (i.e. our customers surfing the web) work just
fine - except active FTP, which of course contains an implicit "incoming" TCP

I've been fighting with this since friday and have done some packet traces. By
comparing successful and unsuccesful packet traces I came to the conclusion
that my problems are being caused by incoming TCP packets with the RST bit
set. So I applied the following access list on the link to our upstream:

access-list 170 deny tcp any any rst
access-list 170 permit ip any any

After doing this, our incoming TCP sessions magically started working. Looking
at the packet counters, I see about 20% of our incoming packets are TCP RST
packets. Putting the same filter on an internal link, I see about 1% of TCP
RST packets.

Turning on access list logging, I see that most of the packets are destined
for port 80 on unused IP addresses (which are nullrouted) - which I guess is
Code Red searching for victims.

So now tell me, am I dreaming or has Code Red found a bug in Cisco IOS? :)
Or is this some kind of new (or old?) denial of service attack disguising as
Code Red? I've reported this to [email protected] and I'm waiting to see what
they come up with.

Anyone seen anything like this? I see the same thing with 12.0(14)S2,
12.0(17)S, 12.0(18)S and 12.2(1). Machine is a 7206 VXR, NPE-400, PA-2E3, 2FE
I/O controller.

Blaz Zupan,  Medinet d.o.o, Trzaska 85, SI-2000 Maribor, Slovenia
E-mail: [email protected], Tel: +386-2-320-6320, Fax: +386-2-320-6325