Writing

Feed Software, technology, sysadmin war stories, and more.

Saturday, April 28, 2012

Web vulnerability scans have slowed down

Just like the raptors in the original Jurassic Park, there are automated scanners which are "testing the fences for weaknesses". Check this out:

[26/Apr/2012:10:51:42 -0700] /translators.html

[26/Apr/2012:21:56:08 -0700] /phpmyadmin/translators.html

[27/Apr/2012:09:42:01 -0700] /phpMyAdmin/translators.html

[27/Apr/2012:21:20:36 -0700] /pma/translators.html

[28/Apr/2012:08:45:31 -0700] /mysql/translators.html

Those are all hits from the same machine to the same vhost. In the past, these sorts of scans would come packed together, as if trying to get it all done as quickly as possible. Now, they just slowly dribble out the checks by waiting minutes, hours, or even days between polls.

This has a number of interesting ramifications. First, if your badness detection strategy depends on the amount of stupidity coming from a host in a given span of time, then chances are it won't pick up on this. These probes are just way too slow compared to past volleys.

Second, if you have something which blocks bad hosts for some span of time, odds are it will expire before they try again. I wrote one of these back around the days of Code Red and NIMDA, and the sorts of timeouts it used by default were relatively short. Polls which were spread out over the span of hours would have definitely gotten through.

Third, if your "IDS" is just you happening to notice weird stuff scrolling by, you'll probably miss these. They look like random wayward GET requests until you finally twig on to the pattern. Then you'll say "okay, show me everything from this same host", and then it will start making sense.

In other words, for every one of those obviously-wrong URLs shown above, I can find several hosts attempting it in any given week, and all of those hosts have also tried other sketchy probes.

Oh well. More wasted resources going to a pointless exercise.