fwd: Re: Slow FTP scan

["vishal pranjale" <vishal.pranjale () paladion net>]

-----Original Message-----
From: Roshen Chandran [mailto:roshen.chandran () paladion net]
Sent: Thursday, October 25, 2001 10:57 AM
To: vishal.pranjale () paladion net
Subject: Re: Slow FTP scan


This does not seem like a set of random, unrelated ftp scans. Nor does it
look like the results of a slow decoy scan, though initially it was tempting
to classify it as yet another decoy. The number of ftp scans in recent times
has increased quite a bit on our networks too.

> From the logs that have been posted, this looks more like a loosely
co-ordinated, distributed ftp scan. There're several missing pieces, but it
seems intriguing anyway.

Some queries that might help us understand the nature of these scans better:

* If this were a spoofed decoy scan, wouldn't we expect to see RSTs from the
spoofed sources, whenever the target SYN-ACK-ed the probe? [assuming there's
at least one open ftp in the network]

* If RSTs 'are' being seen, do their TTLs correspond to the TTLs of the SYN
packets: are TTLs actually being randomized?

* If TTLs are being randomized signifying packet-crafting at Layer 3, wouldn
't we expect RST from the source, (even if the sources were not spoofed)?
The kernel should normally have responded with RSTs as it was not
responsible for the SYN?

A few observations on some of the patterns in these logs:

- The 39 (decoy?) hosts that scan Joe's Class C subnet over the period of 9
days, rarely probe the same IP address again that have been probed by
another one of the scanners during this period. ( <10% ) While someone here
could work out the exact mathematical probability of such a pattern, it
seems to suggest some level of loose co-ordination between the scanners.

- The source IPs reappears in the logs across days, probing the same target
in ~ 60% of the cases. There seems to be a tendency for each scanner to
converge to the same set of target IPs over time.

- The fast ftp scan from 217.85.115.254 on Oct 16th looked unrelated to the
rest of the scans at first, though there seems to be a visible pattern
emerging between the fast and slow scans.

- Both the fast ftp scan, and the slower scans contain a SYN retry after 3
seconds. [Probably, several tools have this 'feature'?]

- The IP addresses that did not receive a SYN retry during the fast scan
(like x.x.x.27) were then excluded from probing altogether- from the slow
scans also. [The absence of SYN retries could be the result of a SYN-ACK
response from the target. Joe could help us: do the absence of SYN retries
correlate with an open ftp port on the Class C subnet?] If this is the case,
then I'd guess we're probably not seeing spoofed source decoy scans at all.

- The two IPs that engaged in the [RST, ACK] responses after 8 minutes,
64.66.223.131, and 193.95.161.209 'always' played out the same sequence with
the same 4 targets, x.x.x.44, .57, .84, .108 across the week. Oddly enough,
these targets did not play the sequence with any other scanner that happened
to probe them at this time. Are these two scanners unrelated to the rest, or
probably variants of the original scanner as they also have the 3 second
retry?

- The unusual window sizes of 512 and 7300 come from the same address:
195.141.175.2. The others have 8K and 16K window sizes, the defaults of NT
and 2K respectively. The window size of 512 doesn't fit into the default
range for 'any' OS.

We could probably get a better picture of what's going on in the days ahead
when we see more detailed logs from across the Net.

Roshen




From: Joe Smith (shadowm4n () yahoo com)
Date: Mon Oct 22 2001 - 11:19:07 CDT

I'm showing that somewhere, someone is very interested
in scanning for ftp servers on my network, but they're
doing this in a very slow fashion, and it appears to
be coming from random hosts (they'll hit one host
every couple hours, this has been going on for weeks).

I'm not at all sure how to identify which one is the
badguy, or even if there is a badguy. Assuming that
most of these hosts are spoofed, and that their ttl's,
tcp sequences, ip id's, and such are all randomized
within normal parameters, is there any way to
determine whats going on?

I've included output of the dump file, but if you can
think of anything to look for, don't hesitate to let
me know. The xxx.xxx.xxx refers to the first three
octets of our class-c block. They're hitting host
IP's that most of the time don't even correlate to a
machine.

Thanks in advance,
Joe.












----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com