vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/28/89)
Consider what happens when an standard 4.xBSD systems receives an ARP packet announcing its IP address and a strange etheraddress. The system prints one message and otherwise ignores the theft of its name. Third parties on the ethernet notice the new (IP,ether) pair, and redirect all traffic for the victim to the thief. This means that when you bring up a machine with a duplicate IP address, you often get no messages, and things appear to work, on the naughty machine. Meanwhile, the victim burps and behaves as if the rest of the world disappeared. Eventually, as arp caches are refilled both machines will print messages, on the order of 0.1 msg/minute. This makes it hard for the knowledgeable to discover which machine is the thief and hard for the uninitiated to figure out what happened. We are thinking of changing this in a future release of IRIX (UNIX for the IRIS--love those AT&T lawyers who hog the real name). The new behaviour uses a neat hack figured out by someone here. He has modified the arp code to save the bogus entry in the victim's cache, and then do an ordinary arpwhohas after a short wait. The result is a steady stream of messages on both consoles. The desired end of making the damage equal for victim and thief is achieved. He also found that if the wait is short enough, TCP connections tend to stay up for the victim, making it a lot easier to poke around on BIND/YP servers for typos, or to sendmail to third parties to ask for help. There are two obvious questions. Is this a No-No? What is a reasonable "short wait"? For the first, I admit that it does generate a little traffic, but know of no laws it breaks. For the second, we have found 1 second too short, generating too many console messages. This change is also a trivial security improvement, making it a little harder to spoof a host, since the victim's complaints are now rather shrill. Does anyone have any comments or suggestions? Vernon Schryver Silicon Graphics vjs@sgi.com
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/28/89)
Consider what happens when an standard 4.xBSD systems receives an ARP packet announcing its IP address and a strange etheraddress. The system prints one message and otherwise ignores the theft of its name. Third parties on the ethernet notice the new (IP,ether) pair, and redirect all traffic for the victim to the thief. This means that when you bring up a machine with a duplicate IP address, you often get no messages, and things appear to work, on the naughty machine. Meanwhile, the victim burps and behaves as if the rest of the world disappeared. Eventually, as arp caches are refilled both machines will print messages, on the order of 0.1 msg/minute. This makes it hard for the knowledgeable to discover which machine is the thief and hard for the uninitiated to figure out what happened. We are thinking of changing this in a future release of IRIX (UNIX for the IRIS--love those AT&T lawyers who hog the real name). The new behaviour uses a neat hack figured out by someone here. He has modified the arp code to save the bogus entry in the victim's cache, and then do an ordinary arpwhohas after a short wait. The result is a steady stream of messages on both consoles. The desired end of making the damage equal for victim and thief is achieved. In addition, he was surprised to find that if the wait is short enough, TCP connections tend to stay up for the victim, making it a lot easier to poke around on BIND/YP servers for typos, or to sendmail to third parties to ask for help. There are two obvious questions. Is this a No-No? What is a reasonable "short wait"? For the first, I admit that it does generate a little traffic, but know of no laws it breaks. For the second, we have found 1 second too short, generating too many console messages. This change is also a trivial security improvement, making it a little harder to spoof a host, since the victim's complaints are now rather shrill. Does anyone have any comments or suggestions? Vernon Schryver Silicon Graphics vjs@sgi.com