Hi,
yes it does if you activated "Active Response" capabilities during
installation, I think the default setting for that is "yes".
Your ossec.conf should contain an active response section that looks like
this (excerpt):
<command>
<name>host-deny</name>
<executable>host-deny.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<!-- Active Response Config -->
<active-response>
<!-- This response is going to execute the host-deny
- command for every event that fires a rule with
- level (severity) >= 6.
- The IP is going to be blocked for 600 seconds.
-->
<command>host-deny</command>
<location>local</location>
<level>6</level>
<timeout>600</timeout>
</active-response>
This means that the active response "host-deny" is associated with the
application $OSSECDIR/active-response/bin/host-deny.sh
This application (or in this case shell script) is run everytime an alert of
level 6 or higher occurs that decodes a source IP adress (c.f.
<expect>srcip</expect>). host-deny.sh puts this IP adress on the host.deny
list of the system that triggered the rule. After 10 minutes or 600 seconds
(c.f. timeout) the IP adress will be removed from the host.deny. Of course
if you exit the ossec agent with /etc/init.d/ossec stop the IP will be
removed then.
The alert you attached is of level 13, therefore triggering the active
response.
If you are using OSSEC with active response here is some friendly advice:
Read the manual at http://www.ossec.net/main/manual/manual-active-responses/
Active response is pretty powerful and has lots of benefits when it is
configured right but might cause trouble if it isn't.
In this case a user was blocked from a webserver (probably because of active
response) and you didn't know why.
If this rule fires very often as a result of false positives you could
generate a local rule for the webserver hosting that site with the long URL
in $OSSECDIR/rules/local_rules.xml:
<rule id="100200" level="0">
<if_sid>31115</if_sid>
<hostname>NAME_OF_WEBSERVER_AS_REGISTERED_IN_OSSEC</hostname>
<description>Ignore rule 31115 for server xy because long URLs are
normal</description>
</rule>
Or you could only do it for the affected URL if it is always the same:
<rule id="100200" level="0">
<if_sid>31115</if_sid>
<hostname>NAME_OF_WEBSERVER_AS_REGISTERED_IN_OSSEC</hostname>
<match>URL_AS_STRING</match>
<description>Ignore rule 31115 for server xy and this URL because its length
is fine in this case</description>
</rule>
Or you could exclude hosts from your local network if only these are allowed
to access that URL and if their IP adress shows up in the log that triggers
the rule. E.g. if your internal network has an IP adress range of
192.168.100.0/24
<rule id="100200" level="0">
<if_sid>31115</if_sid>
<srcip>192.168.100.0/24</srcip>
<description>Ignore rule 31115 for http requests from internal
network.</description>
</rule>
Instead of tagging these as level="0" you could also declare them as
level="1" which would mean these alerts are logged for a default ossec.conf,
but wont cause an e-mail notification or active response.
As you can see OSSEC gives you a lot of options here, however reading the
manual is essential for understanding rule writing and active responses.
Kind regards,
Oscar
On Mon, Feb 8, 2010 at 6:32 PM, john lee <[email protected]> wrote:
> Hi,
> Does ossec trigger any actions from log files? I am using the default
> settings in ossec.conf. But we had an instance where rule: 31115 fired and
> put that IP address on apache block list. We disable ossec agent and the
> user are fine.
>
> Received From: (server) x.x.x.x->/var/log/apache2/access.log
>
> Rule: 31115 fired (level 13) -> "URL too long. Higher than allowed on most
> browsers. Possible attack."
>
> Portion of the log(s):
>
>
> thanks
>
