Re: fwd: Re: Slow FTP scan

[Joe Smith <shadowm4n () yahoo com>]

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 (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


__________________________________________________
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