Apparently Nortel corrected something and the ISP representative I talk
with told me they update their firmware but we still detect this TCP/21536
cnx attempts.

JF

At 16:42 11/01/01 -0600, marc wrote:
> > 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

Jean-Francois Zwobada
Cellule Securite - Fluxus
Phone : +33.1.70.95.10.10 - Fax : +33.1.70.95.10.00
37, rue du Colonel Pierre Avia - 75015 PARIS

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