OSSEC has quickly become a primary weapon in my security toolkit. Â It’s flexible, fast, and very easy to use. Â I’d like to share a few rules I’ve found useful as of late.
I primarily use OSSEC in a server/client setup. Â One side effect of this is that when I make changes to the agent’s configuration, it takes some time for it to push out to all of the clients. Â Additionally, clients don’t restart automatically when a new agent config is received. Â However, it’s fairly easy to remedy this.
First, make sure you have syscheck enabled and that you’re monitoring the OSSEC directory for changes. Â I recommend monitoring all of /var/ossec and ignoring a few specific directories where files change regularly. You’ll need to add this to both the ossec.conf as well as the agent.conf.
<directories check_all="yes">/var</directories> <ignore type="sregex">^/var/ossec/queue/</ignore> <ignore type="sregex">^/var/ossec/logs/</ignore> <ignore type="sregex">^/var/ossec/stats/</ignore>
The first time you set this up, you’ll have to manually restart the clients after the new config is pushed to them. All new clients should work fine, however.
Next, add the following rules to your local_rules.xml file (or whatever scheme you’re using).
<rule level="12" id="100005"> <if_matched_group>syscheck</if_matched_group> <description>agent.conf changed, restarting OSSEC</description> <match>/var/ossec/etc/shared/agent.conf</match> </rule>
This rule looks for changes to the agent.conf file and triggers a level 12 alert. Now we just need to capture that alert and act on it. To do that, you need to add the following to your ossec.conf file on the server.
<command> Â Â Â <name>restart-ossec</name> Â Â Â <executable>restart-ossec.sh</executable> Â Â Â <expect>srcip</expect> Â Â Â <timeout_allowed>no</timeout_allowed> </command>
<active-response> Â Â Â <command>restart-ossec</command> Â Â Â <location>local</location> Â Â Â <rules_id>100005</rules_id> </active-response>
You need to add this to the top of your active response section, above any other rules. OSSEC matches the first active-response block and ignores any subsequent ones. The restart-ossec.sh script referenced in the command section should exist already in your active-response/bin directory as it’s part of the distribution.
And that’s all there is to it. Whenever the agent.conf file changes on a client, it’ll restart the OSSEC agent, reading in the new configuration.
Next up, a simple DoS prevention rule for apache web traffic. I’ve had a few instances where a single IP would hammer away at a site I’m responsible for, eating up resources in the process. Generally speaking, there’s no real reason for this. So, one solution is to temporarily block IPs that are abusive.
Daniel Cid, the author of OSSEC, helped me out a little on this one. It turned out to be a little less intuitive than I expected.
First, you need to group together all of the “normal” error response codes. The actual error responses (400/500 errors) are handled with other, more aggressive rules, so you can ignore most of them. For our purposes, we want to trigger on 200/300/400 error codes.
<rule id="131105" level="1"> Â Â Â Â <if_sid>31101, 31108, 31100</if_sid> Â Â Â Â <description>Group of all "normal" 200/300/400 error codes.</description> </rule>
Next, we want to create a composite rule that will fire after a set frequency and time limit. In short, we want this rule to fire if X matches are made in Y seconds.
<rule id="131106" level="10" frequency="500" timeframe="60"> Â Â Â Â <if_matched_sid>131105</if_matched_sid> Â Â Â Â <same_source_ip /> Â Â Â Â <description>Excessive access, Temporary block</description> </rule>
That should be all you need provided you have active response already enabled. You can also add a specific active response for this rule that blocks for a shorter, or longer, period of time. That’s the beauty of OSSEC, the choice is in your hands.
I hope you find these rules helpful. If you have any questions or comments, feel free to post them below.