ossec-logtest behavior different than alert.log

[jrossi]

I found a situation where ossec-logtest reports that the rules are correct, but when testing with actual logs, the alert is not trigger. Steps to reproduce:

1. Added this to the PIX decoder: pix firewall ^5-106100|^6-106100|^3-106100| ^4-106100 ^(\S+): access-list \S+ (\w+) (\w+) \w+/(\d+.\d+.\d+.\d+)((\d+)) -\p \w+/(\d+.\d+.\d+.\d+)((\d+)) .\+ [\w+, \w+]$ id, action, protocol, srcip, srcport, dstip, dstport

This makes the log I was working on properly decoded.

1. Create a local rule for a firewall permitted event: 4100 permitted Firewall permitted event. firewall,firewall_permitted,
2. Test in ossec-logtest with the following log: Jun 25 12:13:26 192.168.1.4 %ASA-6-106100: access-list INOUT permitted tcp inside/10.0.6.55(43798) -> outside/1.2.3.4(80) hit-cnt 1 first hit [0x98ac69d7, 0x3980c908]

ossec-logtest reports that the rule matches: **Phase 1: Completed pre-decoding. full event: 'scrubbed: Jun 25 12:13:26 192.168.1.4 %ASA-6-106100: access-list INOUT permitted tcp inside/10.0.6.55(43798) -> outside/1.2.3.4(80) hit-cnt 1 first hit [0x98ac69d7, 0x3980c908]' hostname: 'wso-sec-01' program_name: '(null)' log: 'scrubbed: Jun 25 12:13:26 192.168.1.4 %ASA-6-106100: access-list INOUT permitted tcp inside/10.0.6.55(43798) -> outside/1.2.3.4(80) hit-cnt 1 first hit [0x98ac69d7, 0x3980c908]'

**Phase 2: Completed decoding. No decoder matched. Jun 25 12:13:26 192.168.1.4 %ASA-6-106100: access-list INOUT permitted tcp inside/10.0.6.55(43798) -> outside/1.2.3.4(80) hit-cnt 1 first hit [0x98ac69d7, 0x3980c908]

**Phase 1: Completed pre-decoding. full event: 'Jun 25 12:13:26 192.168.1.4 %ASA-6-106100: access-list INOUT permitted tcp inside/10.0.6.55(43798) -> outside/1.2.3.4(80) hit-cnt 1 first hit [0x98ac69d7, 0x3980c908]' hostname: '192.168.1.4' program_name: '(null)' log: '%ASA-6-106100: access-list INOUT permitted tcp inside/10.0.6.55(43798) -> outside/1.2.3.4(80) hit-cnt 1 first hit [0x98ac69d7, 0x3980c908]'

**Phase 2: Completed decoding. decoder: 'pix' id: '6-106100' action: 'permitted' proto: 'tcp' srcip: '10.0.6.55' srcport: '43798' dstip: '1.2.3.4' dstport: '80'

**Phase 3: Completed filtering (rules). Rule id: '100043' Level: '5' Description: 'Firewall permitted event.'

1. Now wait for a permitted firewall log event or replay the sample log into a monitored log file. Nothing appears in alerts.log.

Curiously, if the element is used, rather than , the behavior is correct. Also, if the firewall element if removed from the decoder, such that it is decoded as pix, and a child rule is created on the pix warning rule (perhaps rule 4313,4314), using only and not , it is correct.

Note: This issue has been automatically migrated from Bitbucket Created by mstarks01 on 2013-06-27 00:25:13+00:00, last updated: 2013-07-02 23:33:37+00:00

[jrossi]

Looks like bitbucket mudged this decoder. Try here: http://pastebin.com/hdCcR1Se

Note: This comment has been automatically migrated from Bitbucket Created by mstarks01 on 2013-07-02 21:24:17+00:00

[jrossi]

In analysisd/alerts/log.c function FW_Log(Eventinfo *lf), firewall actions such as 'accept', 'pass', and 'permitted' are all converted to "ALLOW".
Maybe this has something to do with the observed behavior.

Note: This comment has been automatically migrated from Bitbucket Created by jbcheng on 2013-07-02 23:33:37+00:00, last updated: 2013-07-30 21:48:23+00:00