Security Incidents mailing list archives
Re: Scans From 192.168.0.134
From: Daniel Martin <dtmartin24 () HOME COM>
Date: Thu, 1 Feb 2001 13:40:36 -0500
"Douglas P. Brown" <Doug () UNC EDU> writes:
We are somewhat preplexed - Our IDS reported 8000+ SYN FIN scans from a non-routable address (192.168.0.134) to thousands of ours hosts yesterday. Our IDS setup is only seeing traffic that traverses our main router. Has anyone seen this before? Am I missing something? Any advice or direction you can offer would be greatly appreciated.
Yes, I have seen something similar - when testing the synscan tool that comes as part of the ramen worm (what ports were these scans addressed to?). (Although in that case it was a load of packets from my routable address - in the 24.12.*.* block - out my internal interface, which has IP 192.168.0.1) In short, someone didn't use their scanning tool correctly. Many of these scanning tools need to construct raw IP packets to then send on to the destination. Because of the way this is done, these tools need to be told two things: 1) which interface to send scanning packets out on, and 2) what IP address to use when sending those packets Often, a tool will try to guess the answer to one or both of these questions if the user forgets to tell it; for example, queso never needs to be told the interface since it lets the kernel make routing decisions. Synscan (as it comes with the ramen worm) needs to be told both. Now, the standard way of guessing the answer to question (2) is to say "what's my hostname?" (via gethostname() or similar) followed by "what IP address corresponds to that name?". This is all fine and good if the hostname that the machine uses corresponds to its external interface. I would wager that for people who have their own private network at home, this method would produce the internal IP address. I know that's the case with my machine. (Every time I run queso I usually have to run it again because I forgot to give it my source IP address, and it tried to use 192.168.0.1) So my guess is that someone was using a mass scanning tool and failed to give it a host address; this could result in what you see. Were there any other unusual characteristics of the scan that would tell you the tool (source port, dest port, tcp window size, IP ID number, etc.)? A side note: the ramen worm uses a script that determines the main IP address in a more intelligent manner, by looking for the default route - however, the worm fails to use this information to answer question (1), and just always uses "eth0" for the interface on non-ppp boxes. My external interface is eth1, hence the strange packets I saw to my internal network. Also, the current (1.6) synscan (the version used in ramen is older) appears to use a method that reads the IP address right off the interface through ioctl calls. While that should give it the correct source IP address every time, I won't rule out that certain odd mis-configurations on the scanning machine could result in the wrong source IP address. It would also be appropriate for those who wish to rant a bit to at this point bash ISPs who route packets coming from the wrong networks; if people would stop doing that it would make everyone's lives easier.
Current thread:
- Scans From 192.168.0.134 Douglas P. Brown (Feb 01)
- Re: Scans From 192.168.0.134 Alan Hannan (Feb 01)
- Re: Scans From 192.168.0.134 Jon O. (Feb 01)
- Re: Scans From 192.168.0.134 Daniel Martin (Feb 01)
- Update: Scans From 192.168.0.134 Douglas P. Brown (Feb 01)
- Re: Scans From 192.168.0.134 Russell Fulton (Feb 01)
- Re: Scans From 192.168.0.134 Daniel Martin (Feb 02)
- <Possible follow-ups>
- Re: Scans From 192.168.0.134 James Crooks (Feb 01)
- Re: Scans From 192.168.0.134 Alan Hannan (Feb 01)