Snort generating alert but not blocking
-
Hello,
I have the latest production firewall pfSense 2.0.3-RELEASE (amd64) with Snort 2.9.4.6 pkg v. 2.5.9 installed. It was working fine back then but I recently noticed that it's not blocking any offenders. It is generating Snort Alerts but when I click the Block tab, none was blocked.
My settings are:
Services > Snort > Interface (LAN) Edit
1. Block offenders = Checked
2. Kill states = Checked
3. Whick IP to block = srcServices > Snort > LAN Preprocessors > General Preprocessors
All is checked except Enable GTP Detection and Enable Sensitive Data.
Please help.
-
Hello,
I have the latest production firewall pfSense 2.0.3-RELEASE (amd64) with Snort 2.9.4.6 pkg v. 2.5.9 installed. It was working fine back then but I recently noticed that it's not blocking any offenders. It is generating Snort Alerts but when I click the Block tab, none was blocked.
My settings are:
Services > Snort > Interface (LAN) Edit
1. Block offenders = Checked
2. Kill states = Checked
3. Whick IP to block = srcServices > Snort > LAN Preprocessors > General Preprocessors
All is checked except Enable GTP Detection and Enable Sensitive Data.
Please help.
I know next to nothing about it, but if it is LAN, shouldn't it be 'destination' then, instead of 'src'?
By the way, I have 'both', but I just noticed mine isn't blocking on LAN either.
-
I think, some internal interfaces of your pfsense box are added to exceptions automatically.
-
Hello,
I have the latest production firewall pfSense 2.0.3-RELEASE (amd64) with Snort 2.9.4.6 pkg v. 2.5.9 installed. It was working fine back then but I recently noticed that it's not blocking any offenders. It is generating Snort Alerts but when I click the Block tab, none was blocked.
My settings are:
Services > Snort > Interface (LAN) Edit
1. Block offenders = Checked
2. Kill states = Checked
3. Whick IP to block = srcServices > Snort > LAN Preprocessors > General Preprocessors
All is checked except Enable GTP Detection and Enable Sensitive Data.
Please help.
My personal preference is "BOTH" for the block offenders setting. Also, look at the IP addresses shown on the ALERTS tab. Compare them to your HOME_NET and any Whitelist ranges. Any IP address (or IP net block) listed in the Whitelist will not get blocked.
Bill
-
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?
-
Restarted Snort, it now works. :o
-
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>
-
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.
