Re: fwd: Re: Slow FTP scan

From: Joe Smith (shadowm4nat_private)
Date: Thu Oct 25 2001 - 14:22:45 PDT

  • Next message: Mike Shaw: "Re: code red request, but cant be resolved?"

    I appreciate your comments.  I've answered you 
    
    > * 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]
    
    No target on my network responded to any of the SYN
    attempts.  There are no tcp-port 21 servers accessible
    from the Internet.  Thus, no response would ever be
    generated as the firewall is dropping all attempts.
    
    > 
    > * If RSTs 'are' being seen, do their TTLs correspond
    > to the TTLs of the SYN
    > packets: are TTLs actually being randomized?
    
    No RST's being seen, none being generated (see above).
    
    > 
    > * 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?
    > 
    
    We would not necessarily see RST's from the source
    host (even it if wasn't spoofed) because there are
    some scanning techniques that will not respond to
    SYN-ACK packets, but will simply leave the session
    half open.
    
    > 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.
    > 
    An associate of mine suggested this could be a
    worm-in-testing?
    
    > - 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.
    > 
    I agree with the above here.
    
    > - 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.
    > 
    As you now know, there are no devices on my network
    listening on port 21 accessible from the Internet.
    
    > - 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.
    > 
    Just curious, is there a good source out there that
    has lists of OS's versus known window sizes (and other
    properties of the TCP header, for that matter)?
    
    > 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 (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
    > 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
    > 
    
    
    __________________________________________________
    Do You Yahoo!?
    Make a great connection at Yahoo! Personals.
    http://personals.yahoo.com
    
    ----------------------------------------------------------------------------
    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 - 14:28:48 PDT