These two user agents make up pretty much all the brute force attempts to access the admin pages here for one day.
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 GTB5"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0"
The full list from just one sample — yesterday — looks like this:
"Mozilla/5.0 (Windows NT 6.1; AMD64; en:16.0) Gecko/20100101 Firefox/16.0"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0"
"Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.15 (KHTML, like Gecko) Chrome/24.0.1295.0 Chrome/24.0.1295.0 Safari/537.15"
"Mozilla/5.0 (Windows; U; MSIE 9.0; WIndows NT 9.0; en-US))"
"Mozilla/5.0 (Windows; U; MSIE 9.0; Windows NT 9.0; en-US)"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Firefox/3.5.3 GTB5"
"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)"
"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)"
"Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 7.1; Trident/5.0)"
"Mozilla/6.0 (Windows NT 6.2; WOW64; rv:16.0.1) Gecko/20121011 Firefox/16.0.1"
So I can’t really block by user agent, as I had hoped.
Notice anything in common between all of them?
None of them claim to be anything but Windows. For all I know these are actual browsers on someone’s PC running a background process, not a script with a bogus presentation. The UAs seem legit from a cursory Google search.
So I come back once more to the question: how does shutting down arbitrary ports on residential customer networks do anything to defeat this? This may seem like background noise but it’s a constant, relentless attack on the network that adds volume and congestion, which should be of concern to network providers, and puts customers at risk, which should be an issue for those customers and their network providers. It’s network abuse, at the most basic definition.
I’m sure there is enough information from various research projects, honeypots, and ad hoc stuff like this to put together a defensive strategy.
- Find the weak links, be they network providers who don’t care like the image below reveals, browsers and operating systems that are unsecured on delivery (see above: the GTB5 variant is a toolbar, I assume, and those have been linked to this kind of nonsense for years), and isolate them.
- Work with publishers and hosting companies to identify and report patterns of abuse.
- Establish a buyer’s guide to network service that monitors and publicizes poor security practices, advising both business and personal users that they may find themselves cut off from the internet if they sign on with one of these suspect providers.
For the moment, I am simply taking all the IP addresses that get caught by the login trap and adding them to a ban list. When I have a few more, perhaps I’ll sift through them to find out what netblocks/ISPs claim them and see what that reveals.
Well, apparently this is a new thing.
Right now there’s a botnet going around all of the WordPresses it can find trying to login with the “admin” username and a bunch of common passwords, and it has turned into a news story […] Most other advice isn’t great — supposedly this botnet has over 90,000 IP addresses, so an IP limiting or login throttling plugin isn’t going to be great (they could try from a different IP a second for 24 hours).
Also noticed this post earlier today via Reddit: http://www.melbourne.co.uk/blog/2013/04/12/brute-force-attack-on-wordpress-and-joomla-powered-sites/
Might be related? (or you might already know about this and I’m behind on things)
Good to hear from you.
I suspected this has been going on for awhile, based on the diligence I have shown around here. No one is more behind than I am…