How to send pfBlockerNG logs to remote log server (wazuh siem)

[mauro.tridici]

Dear Users,

I would like to send PGSense logs to a remote log-server (wazuh, in my case) but I noticed that eventhough I have set PFSense to send "Everything" it is not sending pfBlockerNG logs.
Is there any way of do this?

Saving pfBlockerNG logs in a SIEM is very useful in order to check them and trigger some alert notification when needed.

Thank you in advance,
Mauro

[keyser]

@mauro-tridici Hi Mauro. Not from pfBlockerNG or pfSense on their own. But you can use the package “Syslog-ng” which in my opinion is one of the best packages around for pfSense.
Not only can you have it monitor local files and forward new entries to remote syslog/siem/greylog/grafana and what not, but you can also set it up as a syslog proxy on a local site.
I use that, and have switches and accesspoints syslog to “Syslog-ng” with UDP, and it then enriches the data as I se fit (with rules), and forwards it with Syslog over TCP/SSL to my central LOKI/Grafana log analytics engine. I also pick up all the pfBlockerNG log files and forward those. In fact, I have i picking pfSense’s own logfiles up instead of having pfSense syslog remotely. That way it goes over TCP/SSL :-)

[mauro.tridici]

@keyser many thanks for your reply and help.
I just installed syslog-ng as on pfsense as you suggested.

In my previous configuration, (standard/default) pfsense logs have been sent, using default syslog, to the SIEM.
Could you please share with me how you configured syslog-ng in order to send also pfblockerng logs to an external log collector?

If I'm not wrong, syslog-ng collect different type of logs that can be sent to external SIEM using standard syslog already installed on pfsense. Is it correct?

Thanks in advance,
Mauro

[keyser]

@mauro-tridici That a pretty long explanation, so I’ll give you the helicopter perspective here, and then you will have to figure out the rest.

The idea is it install a DEFAULT Syslog Server that it by default sets up to listen on port 5140 on the localhost IP. If you are not planning to let other devices log to Syslog-ng (and then forward to your SIEM), the installed DEFAULT syslog server is irrelevant.

What you are looking to achive is have syslog-ng pick up pfBlockerNG files and forward them to your SIEM (Via Syslog).
For this you need to go to the ADVANCED settings tab, and create your own custom SOURCE (Definition of the logfiles it should monitor), a custom destination (Your SIEM syslog), and a custom LOG statement which forwards changes from SOURCE to DESTINATION.

Here are all my custom definitions:

A example SOURCE is defined as follows (For just the pfBlocker DNSBL log)

My LOKI Syslog Distination:

And the LOG that binds them together:

I use a REWRITE in the process to transform the content of a line from the logfile to mhy liking (something usable in LOKI). You can leave that out if you just want the raw lines.

[michmoor]

@keyser I have something similar to send my Squid Proxy and pfblocker dnsbl log files to Graylog. On top of the great explainer you gave I encourage reading the docs for syslogng. Lots of cool things can be done!

[mauro.tridici]

@keyser good morning :)
Many thanks again for your help and for the detailed description of the syslog-ng configuration.
I just created the three objects as you suggested:

name: SRC_PFBLOCKERNG
type: SOURCE

{ file("/var/log/pfblockerng/pfblockerng.log" flags(no-parse)); };

---

name: LOG_PFBLOCKERNG
type: LOG

{ source(SRC_PFBLOCKERNG); destination(DST_WAZUH); };

---

name: DST_WAZUH
type: DESTINATION
{ syslog("x.x.x.x" transport("udp") port(514)); };

As you can see, I don't need to send dnbsl logs to SIEM since DNBSL is not enabled in my case. I only need to trace the IP addresses that are blocked by PFBLOCKERNG lists.
I just checked the content of the file pfblockerng.log saved in pfsense (please take a look at the text below):

*[...] omissis [...]

IPv6 South America [ 06/05/23 12:01:10 ]
IPv4 Proxy and Satellite [ 06/05/23 12:01:11 ]
IPv6 Proxy and Satellite
IPv4 TOP 20
IPv6 TOP 20
pfBlockerNG Reputation Tab
Country Code Update Ended

[ pfB_Top_v4 ] exists. [ 06/05/23 12:01:11 ]

===[ IPv4 Process ]=================================================

[ ip_cred_theft_custom ] exists.

===[ Aliastables / Rules ]==========================================

No changes to Firewall rules, skipping Filter Reload
No Changes to Aliases, Skipping pfctl Update

UPDATE PROCESS ENDED*

It seems that no interesting logs about "banned IP addresses" are listed in the file.
Maybe that no banned IP addresses attacked our pfsense instance, I know that.
But my question is: is pfblockerng.log the right file to be checked (and sent to the SIEM) in order to trace "bad events"? do you know if the logs of a future blocked IP will be saved in this file?

Sorry for my stupid questions, but I'm still a newbie.
Many thanks in advance,
Mauro

[keyser]

@mauro-tridici Ahh, yeah, pfBlockerNG is a little corny on this one.

This trick is as follows:
If you do IP blocking or permit from pfBlockerNG based on feeds or other lists you import, you need to make sure that either the autocreated block/permit rules or your own defined block/permit rules based on DENY/PERMIT lists in pfBlockerNG are set to log hits. This will put a log entry in pfSense's own firewall log among all the other rules that log hits.
pfBlockerNG then has a filterservice that goes through the pfSense Firewall log (near realtime) and scrapes events caused by block/permit rules originating from pfBlockerNG.

Any IP blocks based on lists pfBlockerNG created are then stored in /var/log/pfblockerng/ip_block.log
Any IP allows baased on lists pfBlockerNG created are stored in /var/log/pfblockerng/ip_permit.log

[mauro.tridici]

@keyser what a fantastic explanation :) thank you!

Last question, I promise.

I set the custom block rules to log hits, I added the current public IP of my mobile phone to the custom pfblockerng black-list and I started scanning the pfsense public IP ports using the mobile phone itself.

During the scanning, I checked the content of /var/log/pfblockerng directory in order to verify that the ip_block.log file has been created.
Unfortunately the file is not in the list.

/var/log/pfblockerng: ls -l
total 59
-rw-r--r-- 1 root wheel 22478 Jun 5 15:01 dnsbl.log
-rw-r--r-- 1 root wheel 527 Jun 5 00:00 dnsbl_error.log
-rw-r--r-- 1 root wheel 510 Jun 5 15:01 error.log
-rw-r--r-- 1 root wheel 54803 Jun 5 15:20 extras.log
-rw-r--r-- 1 root wheel 163 Jun 5 15:20 maxmind_ver
-rw-r--r-- 1 root wheel 165133 Jun 5 15:20 pfblockerng.log

So, I checked STATUS -> SYSTEM LOGS -> FIREWALL and, surprise, I see a lot of block entries similar to the following ones:

Jun 5 15:21:13 WAN Default deny rule IPv4 (1000000103) (mobile phone public ip):28480 (pfsense public IP):5357 TCP:S

It seems that standard/default firewall rules intercept this kind of traffic before "Snort" and before "pfBlocker-NG".
Is it correct?

Please, note that:

• I use Snort to automatically block P2P traffic, malicious traffic and so on;
• I use pfBlockerNG to block IP addresses contained in custom blacklists;
• I use standard firewall rules to set up initial and basic rules.

When pfBlockerNG starts analysing and blocking blacklisted IPs? In which order?

Thank you very much for you patience.
Mauro

[keyser]

@mauro-tridici Hi Mauro

Your log entry from pfsense itself shows that it’s the “default deny rule IPv4” that blocked the request. That’s the very last (and hidden) rule in all of the WAN interface rules. It will only hit that rule if nothing else blocked it (including pfBlockerNG). Let’s leave Snort out for now as that works quite differently and does not act “as a rule”.

So your issue is, pfBlockerNG is not configured correctly to block your mobilephone IP. If you look at your WAN rules theres needs to be a BLOCK rule somewhere that blocks the pfBlockerNG custom block-list. If you have auto rule creation enabled it should be there, and likely you forgot that you need to run a “reload - all” in pfBlockerNG before any changes becomes active. If you only have pfBlockerNG create block lists, you have to create the block rule to the custom IP Block-list yourself on WAN. And you still need to “reload - all” in pfblockerng for your added IP to actually be added to the block list.

[keyser]

@mauro-tridici A common misconception is that pfBlockerNG is doing firewall’ing (blocking and allowing) on its own.
It does not - not even close.

The only thing is does is create lists of IP addresses - either from GEOIP, Feeds, Txtfiles, or manually entered lists.
It then has two modes of operation:

1: With autorule creation it automatically attempts to create the Block rules on the Interfaces where you asked it to block. But this can cause issues with rule ordering. This is the reason many use the secondd mode.

2: Autorule creation disabled, and configured to just created combined BLOCK or PERMIT ALIASes out of your feed setups (visible in FIREWALL -> ALIASES). You then have to use these ALIASES and create the proper block or permit rules yourselv - with logging enabled if you want pfBlockerNG to create a separate logfile for hits.

I MUCH prefer the 2nd method as it gives me much more control, and I have created a lot of lists to use for all og my general rules - Fx. A custom list of only my own countrys GEOIP and PLEX’s AWS IPs to allow access to my plex server :-)

[michmoor]

@keyser Why do you always have to be so fancy :)

EDIT:
I use autorule creeation but with Floating Rules enabled. That way it doesnt interfere with the rules on the interfaces themselves. I want the IPv4 blcoks (or permits) to be hit first before the rules on the interface.

[keyser]

@michmoor said in How to send pfBlockerNG logs to remote log server (wazuh siem):

@keyser Why do you always have to be so fancy :)

EDIT:
I use autorule creeation but with Floating Rules enabled. That way it doesnt interfere with the rules on the interfaces themselves. I want the IPv4 blcoks (or permits) to be hit first before the rules on the interface.

That’s a pretty good way to do it if blocking is your primary use of pfBlockerNG. For me blocking is a fairly small part - so I just created a few floating rules for that my self (general bad countries and actors). But my main use is for limited publishing instead of ANY for the various services i run.

[michmoor]

@keyser said in How to send pfBlockerNG logs to remote log server (wazuh siem):

But my main use is for limited publishing instead of ANY for the various services i run.

Thats interesting. Can you eloborate a bit on that? Might help me change my approach when using pfblocker.

[mauro.tridici]

@keyser your support is really professional, thank you :)

Now, with your help and reloading pfBlockerNG, I can see that the public IP of my mobile phone is blocked by pfBlockerNG (I'm still using the first method you mentioned, in the next step I will try to use manual rules).

So, in STATUS - SYSTEM LOGS - FIREWALL, I can see a lot of lines similar to the following ones:

X Jun 5 20:09:32 WAN pfB_ip_cred_theft auto rule (1770009099) (MOBILE IP):2928 (WAN IP):3351 TCP:S

and my phone public IP is actually blocked.
Anyway, no ip_block.log file has been created in /var/log/pfblockerng directory in pfsense.
I can only see the relevant entries in /var/log/filter.log file:

/var/log: grep -R (MOBILE IP) *
filter.log:Jun 5 20:10:36 pfSense_WAN filterlog[40217]: 145,,,1770009099,em0,match,block,in,4,0x0,,49,29056,0,DF,6,tcp,60,(MOBILE IP),(WAN IP),2687,1,0,S,2732915126,,65535,,mss;sackOK;TS;nop;wscale

And I can see also these lines in my SIEM since /var/log/filter.log is correctly sent to my SIEM using "standard/default" syslog service.

Could you please help to understand where is my fault?

Many thanks again,
Mauro

[keyser]

@michmoor said in How to send pfBlockerNG logs to remote log server (wazuh siem):

Thats interesting. Can you eloborate a bit on that? Might help me change my approach when using pfblocker.

Sure, fx. I use my boxes for mobileuser VPN, but it only from a few countries in EU that I actually have workers living/traveling while working.
So I disabled the built-in netgate VPN rules (ANY -> 500UDP, ANY -> 4500UDP, ANY -> ESP), and created a list of my own containing only those 3 countries and set pfBlockerNG to ALIAS PERMIT for that list. I then created the VPN rules myself, but the source is now the pfb_allowedVPN_countries ALIAS instead of ANY.
A similar example is my PLEX server. I created a ALIAS PERMIT list with just my own country and PLEX’es published list of AWS IP addresses in use for their proxies. My own firewall rule the publishes the PLEX to only that Source ALIAS list.
I have numerous other examples of publishing rules where I only publish to a few countries, or a published list of Azure service addresses.

The idea here is that the same could be achived by creating a BLOCK list containing the whole world apart from those 3 countries (in the VPN case), but that would become an ENORMOUS list and consume way to much memory and cpu to use generally.

[keyser]

@mauro-tridici Did you enable logging for the LIST or globally in pfBlocker? If you do not set the list for LOGGING in pfBlocker, the filterservice will not scrape the firewall log for entries created by that rule. Again reload - all is needed when you change the logging settings.

But remember, your SIEM will then get the block twice. Both from the firewall log, and from the pfBlockerNG log. The block will be both places. The pfBlockerNG log is mostly used for its own builtin analysis and visualization feature. But you can use it specifically for getting a list of blocks specifically caused by pfBlocker.

[mauro.tridici]

hello @keyser ,

yes I enabled logging for each LIST defined in pfBlockerNG. PfBlockerNG has been reloaded.
Anyway, I can see the block entries only in /var/log/filter.log file and they are correctly sent to the SIEM.

I would like to send both block logs (firewall + pfblocker logs) to the SIEM in order to get a list of blocks specifically caused by pfblocker (as you said), but, for the time being, it's okay to receive it once if we can't solve the problem.

This is the current configuration of the test LIST of pfblocker:

Thank you in advance,
Mauro

[keyser]

@mauro-tridici That’s a good question, I would expect it to work if that is your list that does the mobileip blocking (under custom).

I can’t really think of what might cause it not to be scraped… does that also mean you have no hits to look at/analyse under Firewall -> pfBlockerNG - Reports?
What about the pfBlocker Widget on the dashboard? Does that show your IP block list as registering any hits?

[mauro.tridici]

Hi @keyser ,

thanks for your reply and patience.
Yes, the screenshot above is related to the list that does the mobileip blocking (under custom).

Below you can find some the answers to your questions and some additional info that can help.

• under Firewall - pfBlockerNG there is no "Reports" choice (please take a look at the picture below)

• the pfBlockerNG Widget show the IP block lists but it doesn't show any hits

In addition, I noticed that:

• pfBlockerNG is quite out-of-date and I think it should be updated (if you are agree);

• the pfBlockerNG "rules" have been (correctly) auto-added to the pfsense floating rules;

• no pfBlockerNG related rules have been auto-added to the WAN interface firewall rules;

• this is the configuration of pFBlockerNG

PfBlockerNG rules should be executed before all other rules, but it seems that blocked IPs are logged in the /var/log/filter.log file (and they are sent to the SIEM without any differentiator tag/label to distinguish the IPs blocked by pfsense firewall or by pfBlockerNG)

Thank you in advance,
Mauro

[keyser]

@mauro-tridici Oh, that’s a VERY VERY old version of pfBlockerNG. The v. 3.x current series is almost a completely different product - im not even sure your version has the reporting and log scraping features.
What version of pfSense are you using?

I would remove the “keep settings” selection, uninstall your pfBlockerNG, and then install the new v3.1.x from scratch. I would not bet on a succesfull upgrade - even if it is supported (I don’t know if it is).

The try again with the current pfBlockerNG. I’m sure that will work like intended (and described by me)