Suricata blocks internal IP despite beeing on the passlist AND no alerts in logs
-
I have a very weird problem.
No logs or alerts but the internal IP gets blocked by suricata on a server despite beeing on the passlist.
How to troubleshoot that?
A clear blocks works for some time. Then it blocks again but the block doesnt show in the logs or alerts at all.
-
My first guess is a duplicate Suricata process is running on the interface. Such a process very well could lose access to the logs where information for the ALERTS tab is pulled from.
Check for duplicate Suricata processes on your interfaces using this command:
ps -ax | grep suricata
Kill the PID of any duplicate processes you might see.
That's really the only way I can imagine for an IP to get inserted into the snort2c table without getting logged. Unless perhaps your alert log files are getting rotated very quickly. The ALERTS tab is populated only from the currently active log. It does not pull from any rotated logs.
-
52316 - Ss 29:05.85 /usr/local/bin/suricata -i vmx2 -D -c /usr/local/etc/suricata/suricata_12544_vmx2/suricata.yaml --pidfile /var/run/suricata_vmx212544.pid
65841 - S 0:00.00 sh -c ps -ax | grep suricata 2>&1
65843 - S 0:00.00 grep suricataAs I see it there is no duplicate proces.
Solved it at first on reboot then it blocked again not showing the IP in logs.
Then I recreated the passlist and it hasnt blocked again as of now.
-
I had the same issue, trafic blocked without alert since I upgraded to Suricata 6.0.3
It's solved after a restart of suricata service. -
@le_bleu said in Suricata blocks internal IP despite beeing on the passlist AND no alerts in logs:
I had the same issue, trafic blocked without alert since I upgraded to Suricata 6.0.3
It's solved after a restart of suricata service.Do you have Suricata set to automatically clear blocked IPs after some time interval? That setting is on the GLOBAL SETTINGS tab, and I highly recommend that users configure that to clear blocks at a maximum of one hour. If the offending traffic returns, Suricata will block it again. There is no big benefit of persisting blocks forever. The blocked IP table is a RAM construct, so when you reboot it is cleared out. That's why rebooting removed your block.
One thing that can happen here is your alerts log file gets rotated when you have automated log management enabled on the LOGS MGMT tab. The data on the ALERTS tab is pulled from the "active" alert log. So if the file has been recently rotated, it can be empty, or else the alert that caused the block you currently have is now logged in one of the older rotated alert log files. So you won't see it on the ALERTS tab. This is exacerbated when you do not have blocked IPs automatically getting cleared. In that case, blocks persist until the firewall is rebooted, but the alert that caused them has long since likely been rotated out of view when the log management code rotated the alerts log.
-
@bmeeks The setting "Remove Blocked Hosts Interval" is set to "1hour" but suricata is configure in INLINE mode so the setting is not use if I understand well.
My suricata configuration runs well since at least 6month without issue. The ALERTS tab is not empty I can see some log of past 24Hours but when trafic is block nothing is listed about this block.
-
@le_bleu Its normal behaviour in INline mode that no blocks show...
Blocks only show in legacy mode.
-
@cool_corona Sorry I would say "Alert" tab and not "block" tab. I should see some entry in alert tab for trafic block
-
@le_bleu Indeed you should. :)
-
@le_bleu said in Suricata blocks internal IP despite beeing on the passlist AND no alerts in logs:
@bmeeks The setting "Remove Blocked Hosts Interval" is set to "1hour" but suricata is configure in INLINE mode so the setting is not use if I understand well.
My suricata configuration runs well since at least 6month without issue. The ALERTS tab is not empty I can see some log of past 24Hours but when trafic is block nothing is listed about this block.
Oh, well you used the word "block" so I assumed you were using Legacy Mode. You are correct the BLOCKS tab is irrelevant when using Inline IPS Mode. And so is the "Remove Blocked Hosts Interval" setting.
There is an issue, I believe, in the Suricata binary itself where it can drop traffic without logging an alert for it. Seems I remember seeing a bug report on the Suricata Redmine site about that. Hopefully that will be addressed in the upcoming 7.0 Suricata release set for later this year.