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

From: Mark Wiater (mwiater@bayserve.net)
Date: 08/10/01 

From: Mark Wiater <mwiater@bayserve.net>
To: Vern Paxson <vern@ee.lbl.gov>
Subject: Re: Code Red Doesn't care about TCP sessions?
Date: Fri, 10 Aug 2001 09:52:55 -0400
Message-Id: <01081009525503.01193@snuffleupagus.localdomain>

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

Relevant Pages

  • Re: F**kin hackers!
    ... > ideas to get around any stealthing capabilities of firewalls but that is ... # FIN without ACK ... NMAP OS fingerprint, TCP ACK ping ... ... > The hacker probably found out my OS and maybe my firewall program. ...
    (comp.security.firewalls)
  • Re: [Full-disclosure] 0trace - traceroute on established connections
    ... variety of different probes using both UDP and TCP layer-4 protocols. ... elicit ICMP "TTL exceeded" from hosts in the path, LFT can send TCP ... a tool to probe firewall ACLs; ...
    (Full-Disclosure)
  • Re: [Full-disclosure] 0trace - traceroute on established connections
    ... For example, rather than only launching UDP probes in an attempt to elicit ICMP "TTL exceeded" from hosts in the path, LFT can send TCP SYN or FIN probes to target arbitrary services. ... a tool to probe firewall ACLs; ...
    (Bugtraq)
  • Re: R2 DFS Replication failing
    ... Disabled the firewall and everything started magically working.. ... BTW: Found out the RPC patch is this one: ... System service name: DfsApplication protocol Protocol Ports ... NetBIOS Session Service TCP 139 ...
    (microsoft.public.windows.server.general)
  • Re: Monitor port Access(File Transfer Activity)
    ... Probably, just capture the activity on the control channel [TCP 21], since ... If your firewall does not permit this capability [and your firewall ...
    (microsoft.public.windowsxp.security_admin)