Re: Interesting scan

[Daniel Martin <dtmartin24 () HOME COM>]

Bruce Parkinson <bruce.parkinson () PAVTECH CO NZ> writes:

> Hi folks,
>
> I received this scan on my home PC.  I've never seen one like this before -
> anyone seen a tool to do this?  Logs are from an OpenBSD/ipfilter combo -
> xx.xx.xx.xx is his IP address, yy.yy.yy.yy is my IP address, time is local.
> Scan came from a dialup port at another ISP.  Our servers here at work
> didn't receive the same scan, suggesting either a targetted scan or a random
> class C.

Well, here's a summary of my guess at the scan:

First off, two seconds before any of the tcp scanning begins we have a
ping.  Second, once the tcp scanning begins we have near-simultaneous
connection attempts to a variety of well-known and lesser-known ports
that seem to be looking for a web server/proxy (ports 80, 8080, 3128,
10080, 81, etc.), and then telnet, FTP, and socks servers.  These
almost seem to be an afterthought given the large number of ports
scanned for web proxies.  Furthermore, each syn packet is followed by
an identical one exactly three seconds later.  Almost ten seconds
after the initial burst of scan packets, the socks port is retried.

The three second delay is consistent with standard TCP behavior - that
is, if I try to do
  telnet blackholed.host.nowhere  # a host which discards all packets
then my machine will send an initial SYN packet, wait three seconds,
send another SYN packet, wait six seconds, send another packet,
etc. (doubling the delay between packets each time) until it times
out.  (Note that the third packet to port 23 comes after a six second
delay from the previous port 23 packet)

My guess then is that this scanning program does all its network
access through standard socket calls, and were it not for the initial
ping I would say that this kind of scan could be launched through an
open https or socks proxy.  Hazarding a wild guess, I would say that
this is someone's first attempt to write a program which scans
addresses, and that it does the scanning either by a whole load of
forking right after the ping or by a bunch of no-wait connect() calls
and a select loop.

I have seen scans before for open web proxies, but not one this noisy.

Could you provide information on what the scanner might have received
back from your machine?  That is, would they have gotten back RST
packets or would they have seen nothing?  (I'm a bit puzzled by why
the socks port is retried, as well as the third packet to port 23)