shotgun scanning

UDP scanning has always been slow. Slower than slow, slower than molasses, really fucking slow.

So when I started being interested in scanning for IPMI out in the wild, which runs on UDP 623, I first fired up trusty ol’ nmap… but bless it’s heart, it’s a cautious, robust scanner that is outrun by crippled snails on UDP scanning.

So I thought… well, most scans don’t really need a request-response-follow-up… so… well, I can just forge the requesting address… spread out collectors… then receive it in one location.  Then I thought… why am I writing a receiver?  I’ll just run tcpdump on the receiving end, and process that… and that also gives all the packets and data, not just what I think of parsing out at the time.

I wrote my “scanner” (not sure what to call it, more like a shotgun, it doesn’t really receive any data ;)) in perl, of course (below.)  I was playing with the speeds and delays – scanning a /8 or A CIDR block in 5-10 mins for a single UDP port A is pretty simple, but I never really know if I’m missing traffic – so many systems, so little time, are all the packets really working?

This might be an old technique or discredited or something… nothing is new under the sun, after all. But it worked for me. And it’s really, really simple, because it’s all the connection details and grabbing and parsing responses, and queuing up all the scans… that takes a fair bit of code – this is just a few for loops and bam.

And it sure beat the alternatives I knew about, at least, which is scanning for a year or so to do the same you can do in a day.  It’d be interesting to do a few nets simultaneously to see if any methods or speeds were better than others.  But for now….