Re: Code Red Doesn't care about TCP sessions?

[Mark Wiater <mwiater () bayserve net>]

Thanks for confirming this Vern, I thought I was going nuts. (And lot's of 
folks have told me privately, in response to this note, that I have).

I've too spent a fair amount of time trying to find a legitimate reason for 
this behaviour but can't. There is no NAT in play here. 

I also neglected to state that I've correlated this activity to firewall 
logs, deny firewall logs that is. Another note is that the destination IP's 
are not in use. I've also ruled out that the Arrowpoints are somehow proxying 
the handshake, there's nothing going back to the code red attacking machine 
from my network.

Worm attempts to real web servers get through the firewalls and look like 
(via tcpdump) normal http sessions.

One of the reasons that I wanted to bring this up is to see if anyone thought 
that this behaviour would be impact Intrusion Detection Systems, IDS's that 
reassemble the TCP streams.  (I should have said that I used Snort 1.7, which 
doesn't do TCP reassembly...)

Mark

On Friday 10 August 2001 12:36 am, Vern Paxson wrote:
> > 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?
>
> I've seen this too - very bizarre!  I've tried to concoct scenarios in
> which it's somehow a NAT that's run amuck, but haven't managed to put
> together any that are convincing.
>
>               Vern

----------------------------------------------------------------------------
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