pfBlockerNG crontab-based restart causes SyslogNG restart: SyslogNG sends the same entire log file each time to my SIEM
-
Hello @stephenw10 ,
thank you for your reply.
Unfortunately, I don't think the problem is due to log-rotate (anyway, changing the file size, would postpone the problem, but would not solve it)
The event occurs every day at the exact same time. And it coincides with the one shown in the following screenshot.
To update the blacklists and to apply the daily updates of pfBlockerNG, I am forced to leave that setting on.
I might consider turning it off, but I would lose all the important updates.
I noticed that there are other users on the forum who have the same problem, but don't know how to solve it.Do you have any ideas?
Thank you very much,
Mauro -
You are using syslog-ng locally on pfSense to export to your external syslog server?
It's the sysog-ng service that's restarting?
-
Hello @stephenw10 ,
yes I'm using syslog-ng locally on pfSense to export logs to the SIEM.
I don't know why, but it seems that when pfBlockerNG restarts automatically at 00:00 also syslog-ng is restarted.And this is the cause of duplicate logs sending.
Is there a way to fix this behavior?Thank you,
Mauro -
Why are you using syslog-ng rather than exporting directly?
What shown in the logs when pfBlocker updates and syslog-ng restarts?
-
I don't know how to export logs from pfblockerng "directly" without using syslog-ng.
I followed the instructions contained in this conversation:https://forum.netgate.com/topic/180605/how-to-send-pfblockerng-logs-to-remote-log-server-wazuh-siem
This is what I see in the pfBlockerng logs during the update:
CRON PROCESS START [ v3.2.0_4 ] [ 07/5/23 00:00:00 ]
[ compromised_v4 ]
Remote timestamp: Tue, 4 Jul 2023 21:13:10 GMT
Local timestamp: Mon, 3 Jul 2023 18:46:18 GMT Update found
UPDATE PROCESS START [ v3.2.0_4 ] [ 07/5/23 00:00:04 ]===[ DNSBL Process ]================================================
===[ GeoIP Process ]============================================
[ pfB_Top_v4 ] exists. [ 07/5/23 00:00:05 ]
===[ IPv4 Process ]=================================================
[ ip_cred_theft_custom_v4 ] exists.
[ compromised_v4 ] Downloading update .. 200 OK. completed ..Aggregation Stats:
Original Final
403 402
===[ Aliastables / Rules ]==========================================
No changes to Firewall rules, skipping Filter Reload
Updating: pfB_compromised_v4
18 addresses added.19 addresses deleted.UPDATE PROCESS ENDED [ 07/5/23 00:00:09 ]
And this is the SYSLOG-NG log file content:
Jul 5 00:00:00 pfSense_LAN syslog-ng[22079]: Configuration reload finished;
Jul 5 00:00:00 pfSense_LAN syslog-ng[22079]: Configuration reload request received, reloading configuration;
Jul 5 00:00:14 pfSense_LAN syslog-ng[22079]: The current log file has a mismatching size/inode information, restarting from the beginning; state='affile_sd_curpos(/var/log/pfblockerng/ip_block.log)', stored_inode='944', cur_file_inode='1286', stored_size='3361864', cur_file_size='3202961', raw_stream_pos='3361716' -
Ah for the pfBlocker logs, I see.
If syslog-ng is watching the pfBlocker log file and that is rotated then I would expect that. It appears syslog-ng is seeing the file has changed and restarts and then presumably resends everything from that file?
-
Yes, that's exactly what happens.
To avoid this behaviour, I should disable pfBlockerNG daily update (and restart), but I think it is not good practice.Do you think there is a workaround to solve this issue?
-
I'm not aware of anything to workaround that.
Are you running 2.6? Have you tested this in 2.7?
-
Yes, Steve. I'm running pfSense v.2.6
I can try to test the 2.7.
I will take a look at 2.7 changelog file as well. -
Hello @stephenw10 ,
this is to inform you that I solved the issue adding this line in the "cron" case statement in "/usr/local/www/pfblockerng/pfblockerng.php" file:
exec("cat /dev/null > /var/log/pfblockerng/ip_block.log");
exec("cat /dev/null > /var/log/pfblockerng/unified.log");I hope there is no side effect :)
Have a great day,
Mauro -
Cool, if that works for you I would expect any issues. Since you're exporting all the logs you don't need them locally.
