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