[thepuppet33r]

It's an interesting idea, but I'm not sure it actually accomplishes much.

I do some purple team work for my company occasionally, and if I scanned a network and got back a bunch of delayed traffic and an active host at every IP, I wouldn't think that I had 255 hosts to check, I'd think the scan failed. I'd tweak the parameters and try again. Unless you're setting your actual servers to respond differently, it wouldn't take much trial and error to filter out the noise. And once it's out that this tool exists, and the parameters are hard set by default (3 ARP calls to non-existent IPs), it'll just be another saved scan setting I can flip to if I get all the noise back.

You might be able to make this harder in the short term by varying the parameters (e.g., 2 ARP scans, only return a host for every third empty address, etc.), but then your solution is not as effective as it takes me less time to check each host for life.

Also, do your fake hosts respond to Telnet on their fake ports? Do they respond to ping? Do they show up on DNS lookups? If you're not altering the traffic at some deeper level or employing something like a custom honeypot that dynamically reacts, these fake hosts are just going to be another static artifact to filter out in the long run. The more straightforward you make the response to a scan, the easier it'll be to dismiss it as noise rather than something to investigate further.

[altairprime]

Simply reacting with “>5% of honeypot IPs have issued an ARP response” would be a valuable alert about a network scan in progress, no matter how long the delay between addresses pinged. The point isn’t to make the network inscrutable, it’s to make it much more risky to scan at all. That the ARP is delayed to the third attempt is interesting but presumably tunable based on whatever the reactivity thresholds for the customer are.