@bmeeks:
@NPDF:
So, pardon my ignorance here as I am new to Snort, but I am having the same issue. I recently enabled blocking.. And an event popped up as ET DROP Dshield Block, under Alerts but was not blocked. You recommended to scan any IP in the alert in the block list, but the destination is the WAN IP, so it is listed - Does that mean it'll never get blocked?
On the INTERFACE SETTINGS tab where you configure blocking, there is a combo-select box for choosing which offending IP address will be blocked. Those choices are SRC, DST, or BOTH. SRC means block the source IP in the alert packet. DST means block the destination IP. BOTH means block both the source and destination IP addresses. The next thing that comes into play is the PASS LIST. By default, your WAN IP, Default Gateway, DNS servers and a few other IPs are never blocked.
So now, to see how the alert you mentioned would be treated, look at the SRC and DST IP addresses. Next, look at that combo-box setting I mentioned. Determine if it is set to SRC, DST or BOTH. Comparing all that information should show you how Snort would have made a block decision. For example, if you had DST selected in the combo-box control, and the DST of the alert was your WAN IP, then Snort would not block because your WAN IP is in the default "never block" PASS LIST. However, if you had the combo set to BOTH, then Snort would insert a block for the SRC IP of the alert (assuming that IP was not also in the default PASS LIST).
Finally, remember that there is a cron job that periodically clears blocked IP addresses. So if enough time has elapsed, it is possible that job cleared the block. Any time the packet filter is reloaded by pfSense, that will also clear all blocks Snort may have inserted. A number of system events can cause the filter (firewall) to reload. Examples are a change in your WAN IP due to DHCP renewal, temporary latency or issues with apinger, etc. Snort does not have its own block list. It simply stuffs any offending IP into the <snort2c>alias table in the pfSense packet filter firewall. Other things outside of Snort's control may clear that alias table. One of those is a filter reload event. As mentioned previously, there are many things that can trigger a filter reload.
Bill</snort2c>
Thanks for the great response! It was at the end of the day, a restart fixing my issue; But this information will help in the future if need be.
