Trouble with configuring OSSEC/UFW for Port Scan detection

[Jason Aleksi]

I am attempting to get OSSEC to read my ufw.log for port scan attempts.  The ufw.log is reading and logging potential port scans.  I've created a decoder to identify the log entries.  I've also created a rule in the local_rules.xml.  I'm OK with it using a firewall drop or host-deny.  

I have two problems:

1. When I go to add the frequency and timeframe in the local_rules.xml, ossec does not like the configs and will not start.  I remove those settings and it starts like a champ.
   
2. Although the ossec-logtest is reading and decoding the logs correctly, the block is not occurring.

I know I'm missing something, but I just can't pinpoint where I need to be looking.  Can anyone offer any suggestions? Below are the configs and results.

sudo vi /var/ossec/etc/ossec.conf

  <localfile>

    <log_format>syslog</log_format>

    <location>/var/log/ufw.log</location>

  </localfile>

sudo vi /var/ossec/etc/decoder.xml

<decoder name="ufw-log">

  <parent>iptables</parent>

  <prematch>^\.+ SRC=</prematch>

  <regex>^\.+ SRC=(\S+) DST=(\S+) \.+ </regex>

  <regex>\.+ PROTO=(\w+) </regex>

  <regex>\.+ DPT=(\w+) </regex>

  <order>srcip,dstip,protocol,dstport</order>

</decoder>

sudo vi /var/ossec/rules/local_rules.xml

<group name="syslog,">

  <rule id="4100" level="0" overwrite="yes">

    <category>firewall</category>

    <description>Firewall rules grouped.</description>

  </rule>

  <rule id="100101" level="10" frequency="3" timeframe="60">

    <if_sid>4100</if_sid>

    <action>DROP</action>

    <options>alert_by_email</options>

    <description>Firewall drop event.</description>

    <group>firewall_drop,</group>

  </rule>

</group>

root@node-01:/var/ossec# bin/ossec-logtest

2017/05/03 11:47:16 ossec-testrule: INFO: Reading local decoder file.

2017/05/03 11:47:16 ossec-testrule: INFO: Started (pid: 10779).

ossec-testrule: Type one log per line.

Apr 25 16:48:26 nodel-01 kernel: [89761.953207] [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:37:7b:ce:00:50:56:c0:00:08:08:00 SRC=10.0.1.1 DST=10.0.1.25 LEN=44 TOS=0x00 PREC=0x00 TTL=44 ID=47998 PROTO=TCP SPT=47528 DPT=443 WINDOW=1024 RES=0x00 SYN URGP=0

**Phase 1: Completed pre-decoding.

       full event: 'Apr 25 16:48:26 node-01 kernel: [89761.953207] [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:37:7b:ce:00:50:56:c0:00:08:08:00 SRC=10.0.1.1 DST=10.0.1.25 LEN=44 TOS=0x00 PREC=0x00 TTL=44 ID=47998 PROTO=TCP SPT=47528 DPT=443 WINDOW=1024 RES=0x00 SYN URGP=0'

       hostname: 'node-01'

       program_name: 'kernel'

       log: '[89761.953207] [UFW BLOCK] IN=ens33 OUT= MAC=00:0c:29:37:7b:ce:00:50:56:c0:00:08:08:00 SRC=10.0.1.1 DST=10.0.1.25 LEN=44 TOS=0x00 PREC=0x00 TTL=44 ID=47998 PROTO=TCP SPT=47528 DPT=443 WINDOW=1024 RES=0x00 SYN URGP=0'

**Phase 2: Completed decoding.

       decoder: 'iptables'

       srcip: '10.0.1.1'

       dstip: '10.0.1.25'

       proto: 'TCP'

       dstport: '443'

Suggestions on where to look?

FWIW:  I have been using PSAD for portscan detection, but I would like to just use OSSEC and eliminate an additional service running; keeping all my security logs and security troubleshooting in one place.

[dan (ddp)]

Your decoder does not decode "action."
So this should never match.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[dan (ddp)]

Here is a decoder with action filled out:

<decoder name="ufw-log">
<parent>iptables</parent>
<prematch>^\.+ SRC=</prematch>

<regex>^\.+ [UFW (\S+)] \.+ SRC=(\S+) DST=(\S+) \.+ </regex>

<regex>\.+ PROTO=(\w+) </regex>
<regex>\.+ DPT=(\w+) </regex>

<order>action,srcip,dstip,protocol,dstport</order>
</decoder>

And the rules when running ossec-logtest:
# cat /tmp/xxx | /var/ossec/bin/ossec-logtest -q
2017/05/03 17:30:43 ossec-testrule: INFO: Reading the lists file:
'rules/lists/ossec.block'
2017/05/03 17:30:43 ossec-analysisd: Invalid use of frequency/context
options. Missing if_matched on rule '100101'.
2017/05/03 17:30:43 ossec-testrule(1220): ERROR: Error loading the
rules: 'rules/rules.d//99-local_rules.xml'.

I'm not sure what you've changed in 4100, so I'm removing it from my tests.
It also doesn't look like the log message is matching 4100, so I'll
modify the decoder again:

<decoder name="ufw-log">
<parent>iptables</parent>
<prematch>^\.+ SRC=</prematch>

<regex>^\.+ [UFW (\S+)] \.+ SRC=(\S+) DST=(\S+) \.+ </regex>

<regex>\.+ PROTO=(\w+) </regex>
<regex>\.+ DPT=(\w+) </regex>

<order>action,srcip,dstip,protocol,dstport</order>
<type>firewall</type>
</decoder>

Now it matches:
**Phase 1: Completed pre-decoding.
full event: 'May 1 05:04:07 buzzell kernel: [2133233.578654]
[UFW BLOCK] IN=enp5s0 OUT=
MAC=b8:97:5a:b1:0b:c6:04:18:d6:f0:7d:51:08:00 SRC=192.168.18.53
DST=192.168.17.8 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46997 DF
PROTO=TCP SPT=47144 DPT=8880 WINDOW=29200 RES=0x00 SYN URGP=0'
hostname: 'buzzell'
program_name: 'kernel'
log: '[2133233.578654] [UFW BLOCK] IN=enp5s0 OUT=
MAC=b8:97:5a:b1:0b:c6:04:18:d6:f0:7d:51:08:00 SRC=192.168.18.53
DST=192.168.17.8 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46997 DF
PROTO=TCP SPT=47144 DPT=8880 WINDOW=29200 RES=0x00 SYN URGP=0'

**Phase 2: Completed decoding.
decoder: 'iptables'

action: 'BLOCK'
srcip: '192.168.18.53'
dstip: '192.168.17.8'
proto: 'TCP'
dstport: '8880'

**Phase 3: Completed filtering (rules).
Rule id: '4100'
Level: '0'
Description: 'Firewall rules grouped.'

The sample logs I've used have BLOCK instead of DROP, so I'd modify
the rule like this:

<rule id="100101" level="10" frequency="3" timeframe="60">

<if_matched_sid>4100</if_matched_sid>
<action>BLOCK</action>

<options>alert_by_email</options>
<description>Firewall drop event.</description>
<group>firewall_drop,</group>
</rule>

Notice I also changed the if_sid to if_matched_sid, as indicated in the error.

[Jason Aleksi]

Dan,

     Thanks for the followup.  I made the changes you suggested and it's detecting the rules as expected.  Now, last step is to actually get it to issue the active-response with a firewall drop.  Thank you!

-JA-