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

michmoor

@keyser Do you know where the syslog-ng configuration is stored. Im running into an issue where if i include another Source/Destination/Log config syslog-ng wont start. Weird.

EDIT: Found the file. Can you spot a problem??

# This file is automatically generated by pfSense
# Do not edit manually !
@version:4.1
destination d_pfB_permit { network("192.168.50.198" transport(udp) port(1524)); };
destination d_squid { network("192.168.50.198" transport(udp) port(1523)); };
destination pf_block { network("192.168.50.198" transport(udp) port(1522)); };
destination _DEFAULT { file("/var/syslog-ng/default.log"); };
log { source(s_squid); destination(d_squid); };
log { source(s_pfB_permit); destination(d_pfB_permit); };
log { source(source_pfblocker); destination(pf_block); };
log { source(_DEFAULT); destination(_DEFAULT); };
source s_pfB_permit {
file("/var/log/pfblockerng/ip_permit.log");
};
source s_squid {
file("/var/squid/logs/access.log");
};
source source_pfblocker {
file("/var/log/pfblockerng/dnsbl.log");
};
source _DEFAULT { internal(); syslog(transport(udp) port(5140) ip(192.168.50.254)); };

michmoor

Found the issue. Syslog-NG does not like sending to the same destination port. I had 1522 listed twice. Not sure why it even cares about something like that but it does. Changed to 1523 and starts normally.

stephenw10

It may use it as the source port also (and is already using it). Though there's no good reason for that AFAIK, syslog is old!

mauro.tridici

Hi @keyser ,

thanks to your help, I had been able to solve the issue :)
Now, I can see the ip_block.log file (and other files) and a lot of additional interesting features provided by pfBlockerNG.
I really appreciated your patience and support, thanks again.

Now, I have to solve the last problem :P

It seems that the ip_block.log file content is not sent to the SIEM.
In the SIEM syslog target file, I can only see the logs coming from pfsense filter.log file.

Could you please help me to check the syslog-ng configuration?

name: SRC_PFBLOCKERNG
type: SOURCE

{ file("/var/log/pfblockerng/ip_block.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)); };

If the syslog-ng client configuration is ok, I think that the problem is related to the target syslog server installed on the SIEM.
In fact, in the syslog server configuration file I recently added the following line:

if $HOSTNAME == 'pfsense' then /var/log/pfsense/pfsense.log
& stop

It works with the filter.log content because it contains the hostname "pfsense", but the ip_block.log file doesn't contain the hostname (so the server doesn't accept the logs).
How did you collected pfblockerng logs in your configuration? can I send the pfblocker logs to a different file on the syslog server?

EDIT:

this source log line type is correctly processed by syslog server:
Jun 7 14:11:13 pfSense_LAN filterlog[40553]: 4,,,1000000103,lagg0.35,match,block,in,4,0x0,,1,15015,0,DF,17,udp,601,IP1,IP2,5060,5060,581

this source log line type is not correctly processed by syslog server:
Jun 7 13:57:35,1770008703,em0,DMZ,block,4,6,TCP-S,IPSRC,IPDEST,56382,44215,in,RU,pfB_Top_v4,83.97.73.0/24,RU_v4,Unknown,wan,null,+

Thank you in advance,
Mauro

mauro.tridici

@mauro-tridici

UPDATE:

I just noticed that also the pfblocker logs from pfsense are saved in the target syslog server.
they are not saved in the pfsense.log destination file, but in /var/log/messages.

example:

Jun 7 14:19:47 pfSense_LAN - Jun 7 14:19:45,1770023929,em0,DMZ,block,4,17,UDP,IP1,IP2,47529,53,out,RU,pfB_Top_v4,194.85.252.0/22,RU_v4,b.dns.ripn.net,wan,null,-

I think I have to find the right syslog filter to send this kind of logs to a different file on syslog server.

Thanks,
Mauro

mauro.tridici

@mauro-tridici

CASE closed: adding a new filter rule in /etc/rsyslog.conf I had been able to have a new file with only the information related to pfBlockerNG logs.

Many thanks to all of you for the help.
Mauro