Since a few months I realized I need more than just a secure connection. What are “they” attempting on the outside of my Internet connection and do I take sufficient measures to counteract?
So instead of just checking the logfiles using elsa, I started suricata on the webserver. Suricata is similar to snort, but more suited for my like. Just to see what’s going on.
Suricata is simple to install, although the default install on Ubuntu 12.04 is version 1.1.1, which is ancient. Using PPA and great help from the suricata community, I installed 1.4.1, a more recent version.
Suricata works best with the emerging threats rules, so I decided to only use those. You can add the snort rules, if you like. Only doing the same double or triple – there is an overlap in rules, seems to be off track.
And then? You have the tools listen to the traffic, so you need some tools to identify the severity of the matched rules. The need for such a tool is even bigger if you have more than one instance of suricata running. And that is the plan.
Checking the odds against the available options, I picked snorby. Why snorby? It runs Ruby, which is one of my favorite languages. Why? Don’t know. I like the language since it is different from the usual. It is object oriented, provides readable source. New. Stylish.
So snorby it was. And then when you add barnyard2 to spool the output of suricata to snorby, it all comes to life.
By running barnyard, snorby sees a sensor. And starts reporting.
As if I knew, it started really reporting. Lots of ET POLICY Cleartext WordPress Login severity 1. In red. So, whats that message implying?
Looking at the rule, it says:
alert http any any -> any any (msg:"ET POLICY Cleartext WordPress Login"; flow:established,to_server; content:"log="; http_client_body; content:"&pwd="; http_client_body; content:"&wp-submit="; http_client_body; classtype:policy-violation; sid:2012843; rev:3;)
Or, in plain text, if an established session contains the words “log=” and “&pwd” and “&wp-submit” alert referring sid 2012843
Easy job, using snorby. A few clicks and the payload is displayed too. They were – and still are – attempting to brute-force the password of these wordpress sites. Bruteforce not really as they were – and are – coming in from the whole world.
Although I have a locationmatch in place to prevent access to the internals of the website from the outside world, this is not sufficient. They want to access this link, server reponds with a 403, the access this link (with a different password) and so on. Crap, as this consumes resources while they are not spent as they should be spent – serving real users.
What next? It would be good to glue these requests for a certain amount of time, just to slow them down. Yes, resources on the webserver are still spent, but now to make life more difficult to those eating my resources, while still serving the real users.
Using mod_security2, I therefore created the following for every vhost:
SecRuleEngine On
SecDefaultAction log,deny,status:406,phase:2
SecRule REMOTE_ADDR ^192\.168\.220\.(?:[0-9][0-9][0-9])$ "nolog,phase:1,allow"
SecRule REQUEST_URI wp-admin|wp-login t:lowercase,pause:55000,log,noauditlog,status:402,deny
SecDebugLog /var/log/apache2/modsec_tarpit.log
SecDebugLogLevel 1
As the rules are processed top down, until a match, this does the following:
- If REMOTE_ADDR contains the internal network (changed, for obvious purpose), traffic is allowed
- If the REQUEST_URI contains wp-admin or wp-login, pause for 55 seconds and return a 402 (payment required) and deny access
- Log this traffic, with a verbosity of 1
So now my tarpit log is filling with single entries, for everyone trying to access this url. And for starters, this open up to a whole new set of rules to protect the websites even further.