Russell Fulton <r.fulton_at_AUCKLAND.AC.NZ> writes:
> hmmm... I've not seen SF scans from these addresses however I do see a
> whole lot of netbios scans (from trojans) with addresses in reserved
> ranges:
>
> [10.0.0.1] -- hosts 35, times 33, frags 0 udp-137
> [10.0.0.2] -- hosts 44, times 40, frags 0 udp-137
> [10.0.0.3] -- hosts 14, times 14, frags 0 udp-137
> [10.0.0.10] -- hosts 20, times 20, frags 0 udp-137
> [192.168.0.1] -- hosts 420, times 151, frags 0 udp-53,udp-137
> [192.168.0.2] -- hosts 81, times 64, frags 0 udp-137
> [192.168.0.3] -- hosts 38, times 39, frags 0 udp-53,udp-137
> [192.168.0.4] -- hosts 46, times 19, frags 0 udp-137
> [192.168.1.1] -- hosts 38, times 37, frags 0 udp-137
>
> I've always assumed that these came from networks with misconfigured
> border filters or NAT (maybe ones that don't filter or translate UDP).
Actually, what's more likely is that they come from windows boxes with
multiple interfaces, at least for the udp-137 packets. (Such as a
windows box with VPN support installed but not currently active, or a
box with both dialup and ethernet connections to the outside world).
The problem is that when some versions of windows (I'm not clear on
all the details) do a broadcast packet to discover what hosts exist on
the network, they will broadcast with the source IP of all their
interfaces, whether or not that interface is currently active. This
leads to the side effect of sending out packets with the wrong IP
address if they have any interfaces that have been assigned an address
but are currently not active. (As I said, I may be wrong on the
purpose of this behavior, but the effect is the same: packets get sent
with the source addresses of other interfaces)
If you look in your logs, these requests will almost certainly be
interleaved with requests from valid addresses; for example:
cush:~$ grep 'Jan 31 20:53:0[6-9].*REJECT' /var/log/kern.log | awk '{print $1,$2,$3,$10,$11,$12}'
Jan 31 20:53:06 eth1 PROTO=17 24.191.34.135:137
Jan 31 20:53:06 eth1 PROTO=17 192.168.0.1:137
Jan 31 20:53:07 eth1 PROTO=17 24.191.34.135:137
Jan 31 20:53:07 eth1 PROTO=17 192.168.0.1:137
Jan 31 20:53:09 eth1 PROTO=17 192.168.0.1:137
Jan 31 20:53:09 eth1 PROTO=17 24.191.34.135:137
I can't verify that the two addresses correspond to the same hardware
address, since my cablemodem makes everything appear to come from the
same hardware address, but I'm almost certain that that's the case.
You can occasionally view the same behavior with addresses in the
169.254.*.* range, as these addresses are used by interfaces that are
setup to receive their configuration via DHCP but cannot receive a
valid response from a DHCP server; for example:
cush:~$ grep 'Jan 22 19:40:1[2-5].*REJECT' /var/log/kern.log.0 | awk '{print $1,$2,$3,$10,$11,$12}'
Jan 22 19:40:12 eth1 PROTO=17 169.254.148.230:137
Jan 22 19:40:12 eth1 PROTO=17 24.240.191.191:137
Jan 22 19:40:13 eth1 PROTO=17 24.240.191.191:137
Jan 22 19:40:13 eth1 PROTO=17 169.254.148.230:137
Jan 22 19:40:15 eth1 PROTO=17 169.254.148.230:137
Jan 22 19:40:15 eth1 PROTO=17 24.240.191.191:137
Finally, it may be that the packets to udp port 53 are windows 2000 or
windows ME boxes trying to register themselves via dynamic DNS, and
exhibiting similarly silly behavior. However, I am not familiar with
the network behavior of those boxes to say.
DANIEL MARTIN
p.s. (to the list, mostly)
When looking at my logs I found this pattern a few times, and I don't
know what to make of it. Let "A" be the valid network address of
this host and let "B" be the invalid address (either in the
192.168/16 range or the 169.254/16 range). Time values are offsets
in seconds.
Time 0: UDP port 137 from address A
Time 2: UDP port 137 from address A
Time 3: UDP port 137 from address A
Time 5: UDP port 137 from address B
Time 5: UDP port 137 from address A
Time 6: UDP port 137 from address A
Time 6: UDP port 137 from address B
Time 8: UDP port 137 from address B
Time 8: UDP port 137 from address A
I can find this rhythm more than once in my logs, and am a bit curious
as to why windows boxes would exhibit this behavior. (Sometimes the
packets would be slightly re-ordered; for example, the two that arrive
at the same time could be in a different order). Specifically, why
would a burst of interleaved "broadcast any address out any interface"
packets be preceeded by a burst of packets containing the right
interface only? Is this Microsoft's idea of a fallback mechanism,
assuming that people will have assigned an address to the wrong
interface? If so, what response would a sending machine require to
prevent it from following a burst with the correct address by a burst
with all addresses?
Received on Feb 02 2001
Intro
