http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-... Does seem to have potential, because at least one large webhost says they got bit hard by this (when they asked me to unblock one of their /24s) - and I've been seeing the same type of spam for quite some time [pizzabox cpanel servers running exim, but emitting porn spam with completely different hostnames and qmail headers] <quote> So this brings us today to a new technique reported by Stephen Satchell of satchell.net last Thursday. It reads almost like a mystery novel, involving cloaking, promiscuous interfaces, stolen IP addresses, and tunneling. It gets a little tricky, so follow the bouncing ball: * The spammer obtains a dedicated server at the victim service provider. The server shares a subnet with other customers. * A spamware daemon is installed on the dedicated server, to keep the network interface in promiscuous mode * The daemon determines which IP addresses on the local subnet are not in use. It also determines the addresses of the network routers. One or more unused IP addresses are commandeered for use by the spammer. * The perp server sends unrequested ARP responses to only the gateway routers, so that the routers never have to ask for a layer-3 to layer-2 association -- it's alway in the ARP cache of the routers. Nobody else sees this traffic in an EtherSwitch fabric, so ARPWATCH and its kin are defeated. Pings and traceroutes also fail with "host unreachable.". The daemon then only has to watch on the NIC, in promiscuous mode, for TCP packets to the hijacked address on port 80, and pass them down the tunnel to the remote Web server. * Finally, GRE and IPIP tunneling is used to connect the stolen IP addresses to the spammer's real servers hosted elsewhere. The end result is that the spammer has created a server at an IP address which not even the owners of the network are aware of. There are a number of ways you can protect your own network from from this exploit: * Give each customer their own subnet. * Null-route unused IP addresses in your network space, or otherwise make sure that there's a legitimate server somewhere that will claim them. * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. </quote> -- Suresh Ramasubramanian (ops.lists@gmail.com)