Turn on logging for select built-in rules only

darcey

With logging of default block rules turned off in the pfSense UI, how best to enable logging for, say, just the snort2c rules and so that logging persists after pfsense/firewall restarts?

NogBadTheBad

@darcey You need to send your logs to a syslog server.

Do you have a NAS with a syslog server, I send mine to a Synology NAS.

Screenshot 2021-12-24 at 10.18.17.png

darcey

@nogbadthebad I have a remote syslog set up and working. I turned off logging the default blocks. However I'd like to turn on pflog just for the two snort2c rules. So I can see the suricata (legacy mode) related blocks in action without the rest of the default blocks getting logged.

I believe I can manually modify the snort2c rules via pfctl (though haven't tried as yet). But I wondered if there is a better way and, having determined the best way, have it applied on filter reloads.

NogBadTheBad

@darcey Not sure why you just want to log just two rules rather than everything, seems a little odd.

The snort2c table is actually everything that snort has blocked, you'd be better logging every Snort block.

Screenshot 2021-12-24 at 10.35.16.png

Are you running Snort & Suricata or does Suricata use the snort2c table as well ?

darcey

@nogbadthebad Sorry, I have tried several times to reply but my post keeps getting flagged as spam. I tweaked and removed some stuff, but no joy. I'll have to try again later.

darcey

Akismet must have not liked the tags around the pf table names.

In reply:
No Snort, just Suricata. In legacy mode, Suricata adds blocked hosts to the snort2c table. In my log analysis I aim to correlate suricata blocks with reported pflog blocks.

ATM I'm not logging the default firewall block rules. Only selectively logging some of my user defined rules.

I'd like to log blocks generated from the snort2c table. I'd prefer not to turn on all the default blocks to achieve this if possible.

I believe I need to modify these two built-in rules to log:

#pfctl -s rules | grep snort2c
block drop quick from snort2c to any label "Block snort2c hosts"
block drop quick from any to snort2c label "Block snort2c hosts"

i.e.

#
block drop log quick from snort2c to any label "Block snort2c hosts"
block drop log quick from any to snort2c label "Block snort2c hosts"

then have those changes re-applied after pf filter restarts.

If that is indeed the best approach, I'd also like to know how to make it persist over restarts.

I had a helluva time posting this. It kept being flagged as spam!

NogBadTheBad

@darcey Ah sorry I didn't realise snort2c was used in Suricata as well.

bmeeks

@NogBadTheBad:
Both IDS/IPS packages use the snort2c pf table for Legacy Mode Blocking operation. That's because pfSense creates that table specifically for them. The table is created each time the firewall rules are rebuilt. This sharing of the snort2c table is why I don't recommend running both Snort and Suricata at the same time.

bmeeks

@darcey said in Turn on logging for select built-in rules only:

@nogbadthebad I have a remote syslog set up and working. I turned off logging the default blocks. However I'd like to turn on pflog just for the two snort2c rules. So I can see the suricata (legacy mode) related blocks in action without the rest of the default blocks getting logged.

I believe I can manually modify the snort2c rules via pfctl (though haven't tried as yet). But I wondered if there is a better way and, having determined the best way, have it applied on filter reloads.

I think you are misunderstanding a key fact here. There is really no point in manually reloading the snort2c table. That table is a RAM construct in the firewall, and it is cleared each time the firewall rules are reloaded/rebuilt. But that's not a problem because if Suricata detected an issue and blocked traffic the first time (when it put an IP in the table in the first place), then it will certainly see the same traffic and block it again the next time that traffic hits. So reloading the table is really pointless.

In fact, you really need to be sure the automatic clearing of the table is enabled on the GLOBAL SETTINGS tab. I suggest an interval of 30 minutes or an hour as the max value for the "Remove Blocked Hosts" setting.

If you want to see what blocks Suricata has inserted, then simply look at the BLOCKS tab. That's what it is for. It populates by reading the contents of the snort2c table and displaying them. You said you had remote syslog enabled, so you should be getting all of the Suricata alerts and blocks sent over via syslog.

Legacy Mode Blocking is really not the best option anyway. It is a large hammer because it blocks and IP entirely instead of just selectively dropping traffic that matches a rule. If your NIC supports it, I highly recommend using Inline IPS Mode. It allows you to tailor the rules so some only alert while others alert and drop traffic. You can configure different rules to have ALERT or DROP actions using Legacy Mode with Suricata, but if your hardware supports it, Inline IPS Mode is the best.

darcey

@bmeeks
I wasn't very clear in my post and follow up.
If I enable Log packets matched from the default block rules in the ruleset under Status/System Logs/Settings, then I get the logs I desire in my syslog and log analysis tool. I don't however want all the default firewall block rules logged. Just those based on the snort2c table.

I'm interested in when, in legacy mode, those rules actually fire. I understand that suricata, running in legacy mode, inserts IP's in that table and it is then down to the firewall to drop traffic. I want to see those events. It's a convenience thing. Having suricata related blocks in the firewall log without all the other default blocking logged.

I don't think I can run in inline mode with virtualised pfsense (vtnet interface driver).

bmeeks

@darcey said in Turn on logging for select built-in rules only:

@bmeeks
I wasn't very clear in my post and follow up.
If I enable Log packets matched from the default block rules in the ruleset under Status/System Logs/Settings, then I get the logs I desire in my syslog and log analysis tool. I don't however want all the default firewall block rules logged. Just those based on the snort2c table.

I'm interested in when, in legacy mode, those rules actually fire. I understand that suricata, running in legacy mode, inserts IP's in that table and it is then down to the firewall to drop traffic. I want to see those events. It's a convenience thing. Having suricata related blocks in the firewall log without all the other default blocking logged.

I don't think I can run in inline mode with virtualised pfsense (vtnet interface driver).

You won't be able to log just those rules unless you actually modify the PHP source code in pfSense itself. And the next time you update pfSense, those changes would disappear. You can make a temp change, sure, but the way pfSense works is that many critical configuration files are recreated each time certain events occur (reloading the firewall rules, for example). That recreation will remove any of your customizations unless you actually go modify the PHP source code running on the firewall that recreates the config files.

The vtnet virtual driver is supported for Inline IPS operation. You could give it a try to see how it works.

I still don't really understand why you are hung up on seeing the blocks added to the snort2c table directly. You can get the same info from the ALERTS tab in Suricata and by exporting the Suricata logs to your remote analysis system. That's what the EVE JSON option is all about if your remote analysis tool supports JSON logs. If not, you can export the Suricata alert logs to a remote syslog system. All of those options are on the INTERFACE SETTINGS tab.

darcey

@bmeeks said in Turn on logging for select built-in rules only:

You won't be able to log just those rules unless you actually modify the PHP source code in pfSense itself. And the next time you update pfSense, those changes would disappear. You can make a temp change, sure, but the way pfSense works is that many critical configuration files are recreated each time certain events occur (reloading the firewall rules, for example). That recreation will remove any of your customizations unless you actually go modify the PHP source code running on the firewall that recreates the config files.

I thought that may be the case. I will just have to turn on logging built-in drops for a while.

The vtnet virtual driver is supported for Inline IPS operation. You could give it a try to see how it works.

Thanks. I did not know that and I am going to give it a try!

I still don't really understand why you are hung up on seeing the blocks added to the snort2c table directly. You can get the same info from the ALERTS tab in Suricata and by exporting the Suricata logs to your remote analysis system. That's what the EVE JSON option is all about if your remote analysis tool supports JSON logs. If not, you can export the Suricata alert logs to a remote syslog system. All of those options are on the INTERFACE SETTINGS tab.

I do also ship the suricata eve logs.

The reason I am looking at this is regarding the recent log4j exploit.
On my DMZ interface, I saw suricata alerts for log4j. Then I also see jdni URIs in my nginx log. I'm wondering if the latter are the initial packet(s) that slip through before suricata appends the offending IP to the snort2c table OR they are undetected variations of the exploit OR some other (mis)configuration on my part.
I am a hobbyist not doing this professionally. The webserver is not vulnerable. Once I satisfy myself I understand what's going on, I'm going to try inline mode. Thanks for your work on the suricata integration. It's a joy to use.

bmeeks

@darcey said in Turn on logging for select built-in rules only:

The reason I am looking at this is regarding the recent log4j exploit.
On my DMZ interface, I saw suricata alerts for log4j. Then I also see jdni URIs in my nginx log. I'm wondering if the latter are the initial packet(s) that slip through before suricata appends the offending IP to the snort2c table OR they are undetected variations of the exploit OR some other (mis)configuration on my part.

The Legacy Blocking Mode will leak packets. That's why I say the Inline IPS Mode is better as it won't leak packets. It is important to always have the "Kill States" option on the INTERFACE SETTINGS tab set to "yes" when using Legacy Blocking Mode. "Yes" is the default value for that setting.

An IDS/IPS actually looks at a stream of data to make a decision. It is not always done with just one single packet. It may take the IDS seeing several packets from a flow before it makes the "alert" decision.

darcey

@bmeeks I've taken your advice and switched to inline mode. Thank you for the help.
log4j is still hitting suricata but I no longer see any log4j traffic in the nginx log. So it would seem to have been leakage under legacy mode.
Under inline mode, I'm targetting rules in my dropsid.conf largely by classtype attributes. This seems to be a good compromise between granularity and not having too much config.
What is the significance of the caret in interface names (eve logs and suricata.log)?

26/12/2021 -- 15:10:00 - <Info> -- Using 2 live device(s).
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2/R from vtnet2: 0x81c606000
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2^ from vtnet2^: 0x81c606300
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2^ from vtnet2^: 0x8345fd000
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2/T from vtnet2: 0x8345fd300

bmeeks

@darcey said in Turn on logging for select built-in rules only:

@bmeeks I've taken your advice and switched to inline mode. Thank you for the help.
log4j is still hitting suricata but I no longer see any log4j traffic in the nginx log. So it would seem to have been leakage under legacy mode.
Under inline mode, I'm targetting rules in my dropsid.conf largely by classtype attributes. This seems to be a good compromise between granularity and not having too much config.
What is the significance of the caret in interface names (eve logs and suricata.log)?
26/12/2021 -- 15:10:00 - <Info> -- Using 2 live device(s).
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2/R from vtnet2: 0x81c606000
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2^ from vtnet2^: 0x81c606300
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2^ from vtnet2^: 0x8345fd000
26/12/2021 -- 15:10:00 - <Notice> -- opened netmap:vtnet2/T from vtnet2: 0x8345fd300

The caret interface suffix denotes the OS endpoint of a netmap pipe. In order for Inline IPS Mode to function, two netmap pipes are created- one to send traffic, and one to receive traffic. Each pipe has an OS endpoint (called the host stack endpoint) and a NIC endpoint. Additionally, if your NIC supports multiple queues, you will see more netmap connections created for each supported queue.

So those lines in your log snippet show one netmap connection from host stack to NIC, and another from NIC to host stack. The "R" and "T" values indicate "receive" and "transmit", respectively.