Since a long time I’m running Suricata on a few Internet facing boxes, just to see what’s attempted to access these boxes unauthorized. It brings a great deal of new information, however there are limits what people should be allowed to do. Politely asking them to stop does not work, nor emailing the abuse address of their provider. It takes just too much time and work.
Filtering with a firewall can work, only if you have a newer model with application security embedded. And these things cost money.
Being not new in OpenSource, I’m using mod_security to enable basic security features. This will stop most of the naughty traffic. But what about the remaining 5%?
I found a nice addition to mod_security which allows ip addresses to be blacklisted. Blacklisted ip addresses can be redirected to a page which indicates the blacklisting. Serving such a page does not cost that much resources – at least less compared to serving normal pages and the naughty requests.
So far, so good. But the naughty people do not come from the same source address all the time. They change these source addresses or use proxies. Instead of having to add these addresses manually, I found a way to automate.
In steps:
Webserver sits on the Internet and is equipped with mod_security and the toolset to blacklist ip addresses. The webservers external interface is spanned to a second server, which runs suricata with a limited ruleset. Data from suricata is send to a central snorby console.
Snorby creates a daily report with the top-10 ip addresses which caused an alert. This list of ip addresses is fed into a script, which will add all these ip addresses to the blacklist, using ansible to all affected servers.
So, although the amount of alerts sometimes is > 200, the automation ensures I’m not having to spend much time adding these ip addresses to the blacklist. And, more important, the amount of alerts does not rise beyond the 200 anymore. Record sits at 43000….