Please cater for UFW in Auditd searches/reports

[Intermediate]

Hi Doug,

We use your excellent Auditd app and various TAs. It's geared for RHEL, which is understandable, but where applicable we use it with Ubuntu also.

For better or worse we are using "UFW" on Ubuntu. It appears practically impossible to permanently change the log prefix for built-in rules (we've spent considerable time investigating).

In the Linux Netfilter (iptables) Add-On documentation you say that we should add "ACTION=" with values ACCEPT, DROP or REJECT.

Could you please consider modifying your queries to also find "[UFW BLOCK]", "[UFW DROP]" or "[UFW REJECT]" so that it will just work with UFW? (I understand that UFW is the default on Ubuntu)

Thank you!

[Intermediate · Accepted solution]

@doksu quickly provided version 1.0.0 pre-release update of TA_netfilter which works. See other comments below.

[doksu]

Thanks very much for letting me know @Intermediate. Could you please try this pre-release v1.0.0 branch: https://github.com/doksu/TA_netfilter/tree/v1.0.0 and let me know if it works for both RHEL iptables and Ubuntu UFW? If it works well, then I'll publish the new version of Splunkbase.

[Intermediate]

Thanks for your help Doug, the updates you've made work.

Splunk Answers is being difficult and won't let me accept your answer!

Anyway, we ended up adding monitor stanzas for /var/log/ufw.log (ubuntu) and /var/log/firewalld (RHEL) to input.conf for *nix systems. We then added an explicit source stanza setting both log paths to sourcetype=syslog in props.conf and it's working reliably.

Thank you!

[gjanders]

Doug will need to convert his comment to an answer so you can accept it, as you cannot accept a comment as an answer...

[doksu]

Ah, I was going to release the new version on Splunkbase then answer with a link to it but Intermediate got there first 🙂

[Intermediate]

Well, feel free to post an answer here and I'll accept yours instead.
You did all the hard work after all!

[Intermediate]

Thanks @gjanders

[Intermediate]

Thanks @gjanders

[Intermediate]

@doksu Thanks for the fast response!

(I've removed some old responses I'd made here here which are irrelevant/confusing)

I'm sure that I've deployed 1.0.0 to an indexer cluster but I am not seeing events assigned the correct sourcetype. Could you please help me troubleshoot the problem?

Here's a sample:
Nov 14 09:59:01 examplesvr kernel: [  573.578259] [UFW BLOCK] IN=ens160 OUT= MAC=00:50:56:80:e1:23:01:51:55:88:04:aa:08:01 SRC=10.10.19.23 DST=10.10.19.13 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=50776 DF PROTO=TCP SPT=51176 DPT=8080 WINDOW=29200 RES=0x00 SYN URGP=0

Thanks!

[doksu]

The app by default only applies the sourcetype transformation to events with the original sourcetype of 'syslog'. Could you please check the UFW events' original sourcetype is 'syslog'? If not and it can't be changed, you may opt to add a local prop.conf like so:

[yoursourcetype]
TRANSFORMS-yoursourcetype_netfilter = netfilter_sourcetyping

The field extractions occur at search time, so the new version of the app will need to be installed on the search heads once the sourcetying issue is resolved.

[Intermediate]

Thanks, we'd been logging to /var/log/firewalld OR /var/log/ufw.log and it seems those logs weren't being ingested with the 'syslog' sourcetype.

I think the addon is working, but it will take me a little while to confirm.

I've got an issue on Ubuntu where we're getting duplicate UFW logs. The same event appears in /var/log/syslog,/var/log/kern.log AND /var/log/ufw.log but I'll sort that out. Possibly syslog config.

[Intermediate]

For the record, for reasons I don't understand, Ubuntu has default rsyslog configuration which logs UFW events to /var/log/ufw.log AND allows these events to also be reported in /var/log/syslog and /var/log/kern.log

Fixing this is as simple as uncommenting '& stop' at the end of the block included in /etc/rsyslog.d/20-ufw.conf and reloading rsyslog.

[doksu]

If the UFW logs are being put in a dedicated log file, then you could specify the sourcetype 'linux:netfilter' directly in the inputs.conf monitor stanza for that file.

[Intermediate]

Applying the TA to the indexer cluster didn't require a restart, but given this isn't working I've done a rolling restart anyway. No change.