HIDS that can detect attacks, take immediate action locally, and then report to a central service for re-broadcasting to other systems?

Question

I've been researching this for a bit now and cannot find what I want. So I'm to the point where I'm weighing my options as to how I can proceed.

Background

I'd like to setup a HIDS that has the ability to use rules to monitor web server logs for known patterns of attacks. I'm thinking something along the lines of how fail2ban works here. Regex is OK but it would be even better if the "rules engine/scanning tool" had some context of how the logs were structured for servers such as Nginx and/or Apache so that the rules could be matched against the log entry contextually, vs. just being a regex.

Sample Apache log entry

192.168.1.6 - - [25/Sep/2014:15:54:01 -0400] "GET /blog/wp-content/themes/atahualpa/images/icons/trackback.gif HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible;)"

Regex example (I don't necessarily want this):

^%(_apache_error_client)s (AH01618: )?user .*? not found(: )?\S*(, referer: \S+)?\s*$

Contextual rule (I'd like this instead):

sourcetype=http
requestpath=/w00tw00t

Evasive maneuvers

I'd like this capability to be deployed with the web server nodes so that they can take immediate actions when a threat is perceived via iptables & ipset. In addition to taking immediate actions, I'd like to report the mis-behaving IP address back to a central server, which will have the ability to re-broadcast this IP out to my other nodes, so that they too can add it to their firewalls too.

Central control

I'd like the central management to keep track of what IPs are currently being blacklisted, and to relay these to the other nodes so that they can incorporate the blacklisted IPs into their firewalls too.

After a time the offending IPs would expire out of the central node, and it would report to the nodes that this IP is no longer being blacklisted.

UPDATE #1 - regarding the potential use of OSSEC

A comment was left as follows:

Just want a little clarification. The thing you can't find a solution for is the centralized part, right? As far as I can tell from your question, other than the centralized IP blocking, OSSEC can perform all of these functions

To which I replied:

You're correct, I didn't realize that OSSEC had active responses that could take actions locally on the agents end. It's described here: New to ossec - what does active response do out of the box So the collecting of the banned IPs and re-broadcast would seem to be the only thing that's not available within OSSEC.

But it's still unclear to me whether the agents can act autonomously and take an active response when a particular log message is seen or not. This comment in the FAQ makes me think that they cannot, Do the rules get pushed to the agents automatically?. So what happens when the OSSEC central server is down? The agents will queue up logs, but will they be able to take any active response on their own to a perceived attack?

References

• ossec.conf: Active Response Options
• Welcome to OSSEC’s documentation!
• OSSEC FAQ's

Answer 1

To put this a little more officially as an answer, I believe OSSEC has the options you're looking for. You can create custom rules, configure it to watch specific log files (such as your web server logs), and trigger alarms if certain regex matches or strings are detected. Active response can actually run more or less any command, you just have to place it in the active-response bin directory which is /var/ossec/active-response/bin by default.

With Active Response you could trigger a script that pushed the IP somewhere centrally and that could be used to derive a list of bad IPs. Active Response has a timeout mechanism to "reverse" the response as well using add or delete. You can view sample scripts in the Active Response bin directory. I will caution you that iptables is not very scalable with a large number of rules, so you will want to test this pretty thoroughly no matter which direction you go with this. Odds are the number of IPs you will block are pretty low, but you never know. Here are a couple of links that may be helpful to you.

http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.active-response.html http://sgros.blogspot.com/2012/08/about-active-responses-in-ossec.html