@bmeeks said in Snort Behavior:
@defenderllc said in Snort Behavior:
@steveits said in Snort Behavior:
@bmeeks said in Snort Behavior:
the next packet through will simply trigger another block
He's saying it was triggering alerts while the service/interface was showing stopped in the GUI. Hence my comment about a zombie process.
It was still still blocking with the interfaces completely deleted from Snort. I had to reboot to get this to stop.
You should look for Snort alerts under the ALERTS tab of the Snort GUI. You can see blocks under the BLOCKS tab.
Here is what was happening. An excessive amount of SIP traffic triggered a bunch of blocks that pushed memory utilization to nearly 100% and the firewall was inaccessible for about 10 minutes.
I was finally able to get in via console cable and then eventually the GUI. The Snort LAN interface was stopped which was fine with me so I could make some adjustments. The memory remained at nearly 70% and I was super busy with work, so I tried to stop the bleeding by simply stopping the service. That did not work because it would just restart within seconds even without it being configured in Service Watchdog.
The next step was just to delete all of the interfaces in Snort, clear all alerts and blocks... I did this over and over and it did not matter because they just kept coming back despite a lack of any interfaces configured. Memory utilization was still high.
A reboot was what it took to clear everything - include the memory utilization. #LessonLearned