Daniel,
An active-response firewall drop failed to actually happen; though it was
logged. That in itself doesn't necessarily present a problem with ossec,
but I figure you'd probably like to know about it anyway, so I attempt to
include a detailed report herein.
Running linux 2.6 with iptables in a VPS environment.
It's a local rule pair which has been working beautifully for the last
week or so, so I don't expect to be able to reproduce this event.
The local rules (pasted at bottom of this post) are used to identify DNS
queries for root NS (current spoofing activity) with rule 100201; and
apply the firewall drop response (triggered by level 10) on rule 100211
frequency check.
The active-response log shows, for a different rule and ip, a "delete"
action (first below) at the same second as the "add" action which didn't
actually happen; and that near concurrency is the only "clue to follow"
which I can spot anywhere. And the effect seems to have been a
discontinuation of active-response actions, though the rules for them
continue to be logged in the alert log (below).
Mon Feb 2 03:10:57 GMT 2009
/var/ossec/active-response/bin/firewall-drop.sh delete - 216.65.19.138
1233529808.128418 30114
Mon Feb 2 03:10:57 GMT 2009
/var/ossec/active-response/bin/firewall-drop.sh add - 69.64.87.156
1233544257.4357 100211
Mon Feb 2 13:46:00 GMT 2009
/var/ossec/active-response/bin/firewall-drop.sh delete - 69.64.87.156
123354
4257.4357 100211
Thie third rule, at 13:46 showing the blocked IP to be deleted, was
triggered by my manual stopping of ossec.
The alert log at the time shows this, starting with the entry for the rule
which triggered an active response which did not happen, and continues
with logs showing that the drop did not take place, and ends with the next
instance of the same active-response rule which does not appear in the
active-response log.
2009 Feb 02 03:10:57 yager->/var/log/named/query.log
Rule: 100211 (level 10) -> 'Multiple DNS query offenses'
Src IP: 69.64.87.156
User: (none)
02-Feb-2009 03:10:55.938 client 69.64.87.156#7860: view external: query: .
IN NS +
02-Feb-2009 03:09:59.896 client 69.64.87.156#1558: view external: query: .
IN NS +
02-Feb-2009 03:09:47.442 client 69.64.87.156#29715: view external: query:
. IN NS +
02-Feb-2009 03:08:51.400 client 69.64.87.156#31239: view external: query:
. IN NS +
** Alert 1233544263.4357: - local_bind,
2009 Feb 02 03:11:03 yager->/var/log/named/query.log
Rule: 100201 (level 5) -> 'recursive root query'
Src IP: 69.64.87.156
User: (none)
02-Feb-2009 03:11:02.164 client 69.64.87.156#32711: view external: query:
. IN NS +
** Alert 1233544275.4618: - local_bind,
2009 Feb 02 03:11:15 yager->/var/log/named/query.log
Rule: 100201 (level 5) -> 'recursive root query'
Src IP: 69.64.87.156
User: (none)
02-Feb-2009 03:11:14.618 client 69.64.87.156#24026: view external: query:
. IN NS +
** Alert 1233544337.4879: - local_bind,
2009 Feb 02 03:12:17 yager->/var/log/named/query.log
Rule: 100201 (level 5) -> 'recursive root query'
Src IP: 69.64.87.156
User: (none)
02-Feb-2009 03:12:16.888 client 69.64.87.156#54858: view external: query:
. IN NS +
** Alert 1233544351.5140: - local_bind,
2009 Feb 02 03:12:31 yager->/var/log/named/query.log
Rule: 100201 (level 5) -> 'recursive root query'
Src IP: 69.64.87.156
User: (none)
02-Feb-2009 03:12:29.341 client 69.64.87.156#39114: view external: query:
. IN NS +
** Alert 1233544357.5401: mail - local_bind,
2009 Feb 02 03:12:37 yager->/var/log/named/query.log
Rule: 100211 (level 10) -> 'Multiple DNS query offenses'
Src IP: 69.64.87.156
User: (none)
02-Feb-2009 03:12:35.567 client 69.64.87.156#24257: view external: query:
. IN NS +
02-Feb-2009 03:12:29.341 client 69.64.87.156#39114: view external: query:
. IN NS +
02-Feb-2009 03:12:16.888 client 69.64.87.156#54858: view external: query:
. IN NS +
02-Feb-2009 03:11:14.618 client 69.64.87.156#24026: view external: query:
. IN NS +
In summary, what I'm seeing above is the active-response rule not having
created the firewall entry, and also disabling active-responses all
together.
If it does happen again, I'll look for a missing process.
As you'll no doubt observe, these are the rules of a novice still learning
and exploring.
Rule 100210 doesn't seem to be working yet.
Rule 100211 triggers on count without waiting for the entire tiemframe, so
I'm happy, and impressed, and still learning :)
<group name="local_bind,">
<!-- Bind9 rules using new Bind9 decoder[s] bind9-query-ip
adapted from named rules
-->
<rule id="100201" level="5">
<decoded_as>named_client</decoded_as>
<regex>view external: query: \. IN NS +$</regex>
<description>recursive root query</description>
</rule>
<rule id="100202" level="5">
<decoded_as>named_client</decoded_as>
<match>view external: query: . IN NS </match>
<description>root query</description>
</rule>
<rule id="100203" level="5">
<decoded_as>named_client</decoded_as>
<regex>view external:\.++$</regex>
<description>recursive query</description>
</rule>
<!-- for active-response: -->
<rule id="100210" level="10" frequency="5" timeframe="60">
<if_matched_group>local_bind</if_matched_group>
<same_source_ip />
<description>Multiple DNS query offenses</description>
</rule>
<rule id="100211" level="10" frequency="3" timeframe="300">
<if_matched_sid>100201</if_matched_sid>
<same_source_ip />
<description>Multiple DNS query offenses</description>
</rule>
</group> <!-- local_bind -->
