Categories
it could be called work

forensics

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.

stay classy, there.

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).

Categories
it could be called work

The first 24 hours

So here’s how the first day or so went of logging and blocking repeated attempts to access the login screen by brute force.

20130411-193234.jpg

What protection against this does Comcast offer with their smtp lockdowns and block on https?

Added the Stealth Login Page Plugin as well, with the added benefit that future script kiddies will get an eyeful of sex.com on each attempt. What would be better is some site that jams a ton of bits down the pipe upon accessing a page.

Categories
it could be called work

and moar cleanup

One of the side-effects of owncloud is the client chatter, all those PROPFIND attempts.

grep -c PROPF /var/log/httpd/httpd-access.log
2740
which is about 1/4 of the log file:
9438 /var/log/httpd/httpd-access.log

I have yet to decipher the right Sacred Rune that will tell me how to prevent this cruft from being logged. I’m able to ignore/not log traffic from 127.0.0.1 but cannot ignore requests for specific URI contents (like PROPFIND requests) or by other IP addresses.

Aha. It turns out the issue was either some old stuff that was messing up the evaluation process of each request or that the IfSetEnvIF requests have to come in order. Or it just doesn’t work, as I have tested those already. Requests from 192.168.0.x networks are logged, but requests from the outside are ignored. Requests for some specified directories are not logged but others are, despite near identical config options.


SetEnvIfNoCase Request_URI "^/metrics" dontlog
SetEnvIfNoCase Request_URI "^PROPFIND" dontlog

Seems legit.

192.168.0.4 - paul [10/Apr/2013:15:38:30 -0700] "GET /cloud/status.php HTTP/1.1" 200 74

I wonder if it’s because I am authenticated?

Nope, it seems to be the menubar client (on OS X) that does that. In a browser, none of the requests are logged, even authenticated. But the little menubar gadget? Everything is logged…

What’s also interesting is that IP addresses can be used unescaped. I didn’t know that.

SetEnvIf Remote_Addr "192.168.0.4" dontlog

Categories
it could be called work

To my 44 subscribers

So Google is closing down Google Reader July 1. How do you read this site, in Reader or something else? What works?