OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: marc (marcZOUNDS.NET)
Date: Thu Jan 11 2001 - 16:42:51 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    > I'm not sure exactly what causes the corrupted packets, but I have seen them
    > as well, here in the US. My network logs show a client connecting to our web
    > site, sending a corrupt packet with the TCP header "missing", with "GET "
    > 18245 > 21536. The next packet they send is a proper request "GET " directed
    > at tcp port 80 of our web server.
    ...
    > to be legitimate home-ISP users connecting to our web site(s). I have not
    > seen scans that follow these patterns.
    > I would guess that your theory that someone is scanning behind a device (or
    > with a device) that creates broken packets is correct. A simple scan for web

            I exchanged email with someone that claimed the problem had been
    traced back to a Nortel CVX. Can anyone confirm or deny this as an issue?

    marc

    > servers with the occasional garbage packet thrown at you.
    >
    > I do still wonder what is causing this, it could also be a Windows bug...
    > maybe a flaw in Windows Me ??
    >
    > -----Original Message-----
    > From: Fulton L. Preston Jr. [mailto:fultonPRESTONS.ORG]
    > Sent: Thursday, January 11, 2001 2:41 AM
    > To: INCIDENTSSECURITYFOCUS.COM
    > Subject: Scans of 21536
    >
    >
    > For the last few months I have seen scans for port 21536 from port 18245
    > to my various web servers. I have searched the mail archives on
    > SecurityFocus and have found several people on several lists ask about
    > them and I found only one response, which seems ok, but I want to
    > confirm it.
    >
    > smarkaczanathema.eu.org wrote to the lists:
    >
    > "We have seen it for several months[2] in Poland, these packets are
    > generated by some brain damaged device (I don't know what this is); they
    > would be correct TCP packets if something did not strip TCP header
    > placing HTTP request right after the IP header. Look at the numbers and
    > you'll see that such damaged packet will be resolved to `port 21536
    > probe' - "GET " resolves to ports 18245 -> 21536."
    >
    > He even claims to be able to reproduce it if he dials into some public
    > ISP in Poland and connect to his machines on any port such as telnet or
    > ssh.
    >
    > I might accept this but the sources of the scans I see are from the US
    > (I'm in the US too). The scans so far have come from the west coast.
    > Now if it is a misconfigured device I could believe the traffic to be
    > innocent but what I get are actual slow scans across my various IP
    > spaces in sequential order. This would indicate a "scan" in my book and
    > not just some odd device causing this from casual browsing (though it
    > could be scans from behind a broken device, that makes it easy to "tag"
    > as a signature for IDS)
    >
    > To make it even more complicated, not all scans look at port 80. Some
    > don't even look at anything at all except port 21536. Most do look for
    > port 80 though after a connection is attempted to 21536.
    >
    > [Sample Snort Log]
    > Jan 10 14:26:28 209.252.32.186:1264 -> x.x.x.x:80 SYN ******S*
    > Jan 10 14:26:24 209.252.32.186:18245 -> x.x.x.x:21536 INVALIDACK
    > *2UA*R** RESERVEDBITS
    > Jan 10 14:26:28 209.252.32.186:18245 -> x.x.x.x:21536 NOACK *2U*PR*F
    > RESERVEDBITS
    > Jan 10 14:26:31 209.252.32.186:1265 -> x.x.x.x:80 SYN ******S*
    > Jan 10 14:26:36 209.252.32.186:18245 -> x.x.x.x:21536 NOACK *2U*P*S*
    > RESERVEDBITS
    > Jan 10 14:26:39 209.252.32.186:1266 -> x.x.x.x:80 SYN ******S*
    > Jan 10 14:26:40 209.252.32.186:18245 -> x.x.x.x:21536 UNKNOWN *2*A*R**
    > RESERVEDBITS
    > Jan 10 14:26:47 209.252.32.186:1270 -> x.x.x.x:80 SYN ******S*
    > Jan 10 14:26:57 209.252.32.186:1271 -> x.x.x.x:443 SYN ******S*
    > Jan 10 17:51:47 63.255.26.26:1120 -> x.x.x.x:80 SYN ******S*
    > Jan 10 17:51:47 63.255.26.26:18245 -> x.x.x.x:21536 NOACK *2U**RS*
    > RESERVEDBITS
    > Jan 10 17:51:51 63.255.26.26:18245 -> x.x.x.x:21536 NOACK *2U**RS*
    > RESERVEDBITS
    > [/Sample Snort Log]
    >
    > The above may be a poor example as both IP ranges belong to the same ISP
    > in this case. In others they have no know relation and traceroutes show
    > that they take totally different paths and do not cross the same
    > routers.
    >
    > I know a few people have seen this. Anyone else lurking on the list
    > seen this activity? Anyone else have anything to offer on this? I am
    > really interested in knowing if it is a router causing this. If it
    > isn't a router, what the heck are they looking for?
    >
    > Regards,
    > Fulton Preston
    >
    > [This is supposed to be an annoying signature. Are you annoyed yet?]
    >

    marc

    import sigfile