2.3: Suddenly blocks TCP:S connection and sites
-
Since 2.3 I have the weird issue that "suddenly" some sites stop working. They stay connecting in the browser, without any reason. A good example is facebook. All is well, until I see that the messenger section suddenly says that there is no connection. Also a Dutch site Tweakers.net becomes totally unreachable when a minute before it worked flawlessly.
In the firewall log I see this:
X Apr 21 10:00:06 LAN 192.168.7.7:55212 213.239.154.20:443 tweakers.net TCP:S
I have no idea why this behaviour sometimes happens. After a while it will start working again. It happens on all clients including the OpenVPN connection.
Does anyone have a clue where to start looking?
-
Click on the X. What rule is blocking it?
-
Ah, nice! That's a good start. Seems that Snort rules are acting up:
The rule that triggered this action is:
@51(1000000118) block drop log quick from any to snort2c:1label "Block snort2c hosts"
The rulesets I use for snort are:
Snort VRT Rules
Snort GPLv2 Community Rules
Emerging Threats Open RulesError from SNORT:
(spp_ssl) Invalid Client HELLO after Server HELLO Detected
Does force disabling this rule have any effect? I searched for this and many report this als a false positive? Is it better to start running Snort on the LAN interface?
Edit: I Surpessed gen_id 137, sig_id 1. Is this sufficient?</snort2c:1>
-
Ah, nice! That's a good start. Seems that Snort rules are acting up:
The rule that triggered this action is:
@51(1000000118) block drop log quick from any to snort2c:1label "Block snort2c hosts"
The rulesets I use for snort are:
Snort VRT Rules
Snort GPLv2 Community Rules
Emerging Threats Open RulesError from SNORT:
(spp_ssl) Invalid Client HELLO after Server HELLO Detected
Does force disabling this rule have any effect? I searched for this and many report this als a false positive? Is it better to start running Snort on the LAN interface?
Edit: I Surpessed gen_id 137, sig_id 1. Is this sufficient?</snort2c:1>
You can either disable or suppress that rule. The difference is a suppressed rule is still evaluated, but it just does not generate an alert. A disabled rule is never evaluated (meaning incoming traffic is not tested against that rule). A disabled rule saves resources.
One thing you can do for a suppressed rule is to choose the option to "suppress by IP", and that IP can be either the source or destination IP. Using this method lets you in effect turn off the rule for a specific host (or you can manually edit the suppress statement and suppress by network) while leaving it enabled for all other hosts.
Bill
-
You can either disable or suppress that rule. The difference is a suppressed rule is still evaluated, but it just does not generate an alert. A disabled rule is never evaluated (meaning incoming traffic is not tested against that rule). A disabled rule saves resources.
One thing you can do for a suppressed rule is to choose the option to "suppress by IP", and that IP can be either the source or destination IP. Using this method lets you in effect turn off the rule for a specific host (or you can manually edit the suppress statement and suppress by network) while leaving it enabled for all other hosts.
Bill
Thanks Bill, but just a question beyond this is why is it doing this so random? Why does it happen 3 times an hour and then for about 6 hours all is well. Any idea?
-
You can either disable or suppress that rule. The difference is a suppressed rule is still evaluated, but it just does not generate an alert. A disabled rule is never evaluated (meaning incoming traffic is not tested against that rule). A disabled rule saves resources.
One thing you can do for a suppressed rule is to choose the option to "suppress by IP", and that IP can be either the source or destination IP. Using this method lets you in effect turn off the rule for a specific host (or you can manually edit the suppress statement and suppress by network) while leaving it enabled for all other hosts.
Bill
Thanks Bill, but just a question beyond this is why is it doing this so random? Why does it happen 3 times an hour and then for about 6 hours all is well. Any idea?
It could be caused by a retransmitted packet arriving out-of-order for that particular stream so far as Snort is concerned. One thing to remember with Snort is that it operates in promiscuous mode directly on the WAN interface, so it sees all traffic and sees it before the firewall does.
Bill
-
Ah, that makes sense. Thanks for the response.
-
I had the same issue in 2.3.1_p5, until I unchecked the "Block Offenders" checkbox in the "Alert Settings" area on the "Services/Snort/Edit Interfaces/LAN" tab.
Entries are no longer added on the snort2c Table on the "Diagnostics/Tables" tab.
Intermittent failures of random pages resolved.
-
I had the same issue in 2.3.1_p5, until I unchecked the "Block Offenders" checkbox in the "Alert Settings" area on the "Services/Snort/Edit Interfaces/LAN" tab.
Entries are no longer added on the snort2c Table on the "Diagnostics/Tables" tab.
Intermittent failures of random pages resolved.
True, but now you have an Intrusion Detection System and not an Intrusion Prevention System. Malicious traffic can flow between your hosts and the bad guys unimpeded until you manually block it. So having "block offenders" enabled is usually a better system, but an IPS takes a lot of care, feeding and attention in the initial stages to tune the enabled rule set. Many folks think Snort is a "turn it on and forget it package".
For rules that false positive in your environment, it is better to just disable those specific rules rather than turning off blocking completely.
Bill
-
Thanks Bill.
I was wondering about that. I'll fix by doing what you suggest.
Thanks.
