how to interpret the ossec active response log

[hostingguy]

Hi,

I had a client call in today and say they couldn't access the server and the first thing I thought of was that they got shunned by ossec. Looking through the logs I do see that they got blocked, but I was wondering what the lines in the log file mean and how to use this to trace down to the reason why they were blocked with out having to grep through every access_log or security audit file. Eventually I did find it by doing a grep through the audit logs but I was wondering if there is an easier way to find this out using the data in this log file.

Code: Select all

Mon Jun 17 07:30:36 PDT 2013 /var/ossec/active-response/bin/asl-shun.pl add - xx.xx.xx.xx 1371479436.3327886 60118
Mon Jun 17 07:30:36 PDT 2013 /var/ossec/active-response/bin/host-deny.sh add - xx.xx.xx.xx 1371479436.3327886 60118
Mon Jun 17 08:19:16 PDT 2013 /var/ossec/active-response/bin/asl-shun.pl delete - xx.xx.xx.xx 1371479436.3327886 60118
Mon Jun 17 08:19:16 PDT 2013 /var/ossec/active-response/bin/host-deny.sh delete - xx.xx.xx.xx 1371479436.3327886 60118
Mon Jun 17 08:34:05 PDT 2013 /var/ossec/active-response/bin/asl-shun.pl add - xx.xx.xx.xx 1371483245.3777287 60118
Mon Jun 17 08:34:05 PDT 2013 /var/ossec/active-response/bin/host-deny.sh add - xx.xx.xx.xx 1371483245.3777287 60118

[mikeshinn]

Please see this FAQ:

https://www.atomicorp.com/wiki/index.ph ... l_shuns.3F

[hostingguy]

Thanks Mike, One thing I noticed is that in that logging it mentioned the rule 60118

grep 60118 /var/ossec/etc/rules.d/*
/var/ossec/etc/rules.d/50_asl_general_rules.xml: <rule id="60118" level="7">

Which doesn't really tell me much other than ModSec blocked it.

Code: Select all

# grep -B1 -A7 60118 /var/ossec/etc/rules.d/50_asl_general_rules.xml

  <rule id="60118" level="7">
    <if_sid>60101</if_sid>
    <match>Access denied</match>
    <description>Access attempt blocked by Mod Security.</description>
    <group>access_denied,</group>
  </rule>

  <rule id="60119" level="12" frequency="6" timeframe="120">
    <if_matched_sid>60118</if_matched_sid>
    <same_source_ip />
    <description>Multiple attempts blocked by Mod Security.</description>
    <group>access_denied,</group>
  </rule>

[prupert]

It is a general rule that is used to do a shun after a modsec event. Check your asl event list for more specifics, such as the modsec rule id.

[hostingguy]

I dont know what that means, if that is not available in the CLI then our support wont be able to access it. The ASL GUI is pretty much worthless since it never loads and as such we have never really used it more than 2 or 3 times in the last few years (combined over dozens of servers).

[prupert]

60118 is not a modsec rule, it is a catch-all for modsec rules so ASL can loop in OSSEC to do the shunning.

[hostingguy]

Alright, I apologize if I am not being clear.

My original request was to understand what rule in mod sec this triggered, possibly even what vhost, or audit file, etc - something that makes it easy to find a log entry like this

Mon Jun 17 07:30:36 PDT 2013 /var/ossec/active-response/bin/asl-shun.pl add - xx.xx.xx.xx 1371479436.3327886 60118

and turn around and tell the client why they were blocked.

So far everything everyone has told me says to look at the rule in the log - the last entry, which in this case is 60118. Well for diagnostics, that rule isnt helping because it doesn't tell you anything useful. So I still have the same query - how can I use the log entries in here to quickly find the reason the user was blocked with out having to grep the entire audit log directories?

[mikeshinn]

how can I use the log entries in here to quickly find the reason the user was blocked with out having to grep the entire audit log directories?

You need to use the web console for that. The logs do not provide that level of detail.

[faris]

If you can't get into the GUI then something is seriously wrong.

There was a short timeframe when it was difficult to login -- it took ages -- but that's long gone now. If you still can't login then something needs to be looked at regarding this.

The logs are all available in plain text in /var/asl/data/audit/[date]/[date-time]/[date-time-unique]

So if you: grep -ri 'ip-address' /var/asl/data/audit/[date]
You'll find the logs that contain the IP, and you can then investigate in more detail.

At least that's how things are on our systems. There may be a configuration option that enables/prevents this, or there may not.

*** In addition, or instead, you can have all events over a certain level emailed to you. This is how it is set by default, in fact. If you set your email client to put all those emails in one folder, you can then search by IP and find the events that triggered things.

But you may have to set asl to send an email alert at level 5 or maybe even lower in order to catch everything this way. If you do, make sure you also set asl to only send on email (digest) per hour, so you don't get overwhelemed. Maybe even set up a special gmail address specifically for this purpose to avoid clogging your own mailbox?



I

[hostingguy]

Unfortunately like I mentioned the web console doesnt work - it never loads and virtually anything we open in there doesnt work either except for the ASL config page, thats the only item that seems to come up right away. On some servers it takes about half hour to load the opening page and the items on it, some takes upwards of 2 hours, and the vast majority of them never load.

This pretty much makes the console not usable.
We really need a way to accomplish the tasks done via the console and am a little surprised we cant despite the length of time since the roll out of the GUI. Something simple like turning off logging or emailing of certain rules. This is fine for one box, but we have dozens - we cant login to each one and do it manually, that is way too much work.

[craigedmonds]

Unfortunately like I mentioned the web console doesnt work - it never loads and virtually anything we open in there doesnt work either except for the ASL config page, thats the only item that seems to come up right away. On some servers it takes about half hour to load the opening page and the items on it, some takes upwards of 2 hours, and the vast majority of them never load.

This pretty much makes the console not usable.
We really need a way to accomplish the tasks done via the console and am a little surprised we cant despite the length of time since the roll out of the GUI. Something simple like turning off logging or emailing of certain rules. This is fine for one box, but we have dozens - we cant login to each one and do it manually, that is way too much work.

I have the same issue on 3 different servers. The GUI takes around30-60 seconds to load and when I am typing an ip into the search box it always says "no results" even though someone is appearing on the blocklist (which means its recent).