fwd: Re: Slow FTP scan

From: vishal pranjale (vishal.pranjaleat_private)
Date: Wed Oct 24 2001 - 23:34:35 PDT

  • Next message: Hoyt Plunkett: "RE: Security Question"

    -----Original Message-----
    From: Roshen Chandran [mailto:roshen.chandranat_private]
    Sent: Thursday, October 25, 2001 10:57 AM
    To: vishal.pranjaleat_private
    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 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,, and '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
    - The unusual window sizes of 512 and 7300 come from the same address: 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.
    From: Joe Smith (shadowm4nat_private)
    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
    Thanks in advance,
    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

    This archive was generated by hypermail 2b30 : Thu Oct 25 2001 - 08:41:48 PDT