OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Benninghoff, John (JaBenninghoffDAINRAUSCHER.COM)
Date: Thu Jan 11 2001 - 13:54:09 CST

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

    Fulton,

    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.

    I have also seen this behavior with SSL as well, with arbitrary, but
    predictable ports, which follow the same pattern: an obviously corrupt
    packet missing the TCP header(often they have bad options set, etc.)
    followed by a proper packet, with the same data payload. The clients appear
    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
    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?]