Code Red Doesn't care about TCP sessions?

[Mark Wiater <mwiater () bayserve net>]

Good day all,

I've searched the archives looking for someone else to have reported this and 
haven't found mention of it yet. But it is entirely possible with the volume 
of information out there that I missed it. If so, please accept my apologies 
for the waste of bandwidth.
 
Some coworkers and I were implementing some ACL's in an Arrowpoint (Cisco) 
Content Smart Switch last night. This load balancer is physically located 
above a set of firewalls. The ACL's were to detect default.ida in the url and 
deny the packet. (Works pretty well too.)

I was REAL disturbed when I found that the rate of Code Red incidents 
increased by 1000% percent, as reported by the Arrowpoint, from the number of 
code red incidents reported as a result of IIS logs on my internal machines.

I got curious and setup a Snort machine out by the Arrowpoints. Low and 
behold the numbers of Code Red (any versions) incidents tracked closely with 
what the arrowpoint was reporting.

A closer look at the data showed that many of the Code Red attacks were 
directed at machines that I KNEW were not able to receive port 80 through the 
firewalls. So how did Code Red get so far as to send the GET request when 
there was no SYN, SYN/ACK, ACK???

A tcpdump showed that all of the code red communications were unidirectional. 
It didn't bother to wait (more than 350ms) for a response from the Web server 
before it sent it's ACK and then GET request.  This behaviour was consistent 
for all ip addresses that could not respond via port 80 because of the 
firewall.

Am I the only one to see this behaviour?

Thanks


Mark 

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com