Messages in this thread | | | Date | Sat, 26 Feb 2000 09:14:41 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: How to survive in a Micro$oft environment?? |
| |
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/
| |