|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
CVX? Re: Scans of 21536 |  |
- To: [EMAIL PROTECTED]
- Subject: CVX? Re: Scans of 21536
- From: marc <[EMAIL PROTECTED]>
- Date: Fri, 12 Jan 2001 00:52:04 +0100
- In-reply-to: <[EMAIL PROTECTED]>
 |
| |
> 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:[EMAIL PROTECTED]
> Sent: Thursday, January 11, 2001 2:41 AM
> To: [EMAIL PROTECTED]
> 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.
>
> [EMAIL PROTECTED] 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
| |