Re: Scans From 192.168.0.134

[Daniel Martin <dtmartin24 () HOME COM>]

"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.