Date: Sat, 26 Feb 2000 01:51:24 +0000 (GMT)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> It's rude, but no less then the WinNT Term server boxes on my network that
> snmp sweep the subnet.
SNMP sweeping the subnet is reasonable if told to do so. The trace is far
worse, its DNS bombing the entire class C which is also other customers,
and its doing it without sensible delays between frames
Given my past experience with certain broken HP Printer drivers (for
Windows) that would SNMP sweep an entire class A network at high speed,
I'm less convinced that this kind of scanning is *ever* appropriate.
Especially since given the use of CIDR, there's absolutely no guarantee
that a class C subnet is going to be local. More often than not, people
routinely get fractions of a class C these days, and the rest will go
out over a potentially slow link.
(Consider what happens if you have a 802.11 ethernet anywhere in the
scan range; it's usually enough to completely take out the network ---
and *finding* the rogue box on a wireless network is devilishly
difficult. Fortunately, the one time this happened, we simply sent the
Windows box a ping-of-death, and it went away. You never knew
ping-of-death could be used as a network management tool, did you? :-)
If you're going to do this kind of thing, for goodness sake, arrange to
have the TTL field set to down to 1 in the IP packet, so it won't escape
the local subnet. It still won't save you in the case where the rogue
machine is on a radio network, but at least you won't make other
innocent networks suffer.
Something else that's probably worth having Lizard do is to check to see
whether it can reach the DNS root nameservers, and simply do a IN-ADDR
loookup for the domain's NS records. If this succeeds, this will give
you the local domain's nameservers without having to do a network sweep.
This trick won't work in a firewalled environment with split DNS, in
which case you may have to fall back to spamming the local network, but
at least this way you've limited the damage you can inflict to the local
company's network. Also, a company that has this kind of firewall is
also likely to have a DHCP or BOOT infrastructure, which is something
else that *really* should be tried first. In fact, the order that
should be used is probably:
* DHCP/BOOT
* IN-ADDR lookup of NS records
* DNS capetbombing of local subnet with ttl set to 1
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:15 EST