-----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 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 (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
This archive was generated by hypermail 2b30 : Thu Oct 25 2001 - 08:41:48 PDT