Can I suppress snort alerts for ports that I don't have open on my firewall?
-
Hi there
Hope you're all well and hope someone can give me a direct answer to the question:
"Can I suppress snort alerts for ports that I don't have open on my firewall?"
I'm getting a lot of what I think are false positives, an example been the following that keeps showing up on my WAN Alert Logs:
1:2010935 - ET POLICY Suspicious inbound to MSSQL port 1433
I don't have port 1433 open on my firewall so would it be safe to assume that I can suppress this Snort SID Rule?
Thanks again
Andy
-
Not really. Snort sees traffic before your firewall rules act upon it, so it will alert on things that your firewall will block. You can suppress any Snort alert you wish, but just be aware that is somewhat global and you might suppress events you really would want to see. If you are sure you want to see nothing about MSSQL, then you could disable all of those rules. The SID MGMT tab is the easiest way to accomplish this.
Bill
-
Many thanks Bill
-
Bill, can you expand on this?
AFAICT, the only advantage to keeping this rule enabled, if 1433 is blocked at the firewall, is so you are notified of an attempt to access your database server. If rule-breakers are automatically blocked, this would prevent further attempts but if the port is already blocked, what is the return on enabling this rule?
I am new to Snort but the rules do not look complicated. I am setting up an IPS for our company network. All of our Internet traffic is routed through this gateway and outbound NAT traffic is unrestricted. Our public services include website apps, FTP servers, and VPNs. I don't see the need to be notified about intrusion attempts against IPs/Ports that are blocked (or in this case, not passed because the default deny rule blocks everything not passed).
Question: Am I missing something regarding the value of being notified about attempts to access ports that are not open?
I am a minimalist and prefer to be very specific regarding the processes and configuration of my network hardware and servers. Most of the suggested configs I see on the Internet seem to say enable everything and disable what you don't need. This is contrary to my thinking but I am willing to concede if it really is the best way.
Question: Is it best to simply enable all the default rule sets (GPLv2 and ET) and then add them to a disable list in SID Mgmt as it is determined we don't need them or is there a more limited list of rulesets that will provide the protection I want given the list of public services my network provides?
Steve
-
Bill, can you expand on this?
AFAICT, the only advantage to keeping this rule enabled, if 1433 is blocked at the firewall, is so you are notified of an attempt to access your database server. If rule-breakers are automatically blocked, this would prevent further attempts but if the port is already blocked, what is the return on enabling this rule?
I am new to Snort but the rules do not look complicated. I am setting up an IPS for our company network. All of our Internet traffic is routed through this gateway and outbound NAT traffic is unrestricted. Our public services include website apps, FTP servers, and VPNs. I don't see the need to be notified about intrusion attempts against IPs/Ports that are blocked (or in this case, not passed because the default deny rule blocks everything not passed).
Question: Am I missing something regarding the value of being notified about attempts to access ports that are not open?
I am a minimalist and prefer to be very specific regarding the processes and configuration of my network hardware and servers. Most of the suggested configs I see on the Internet seem to say enable everything and disable what you don't need. This is contrary to my thinking but I am willing to concede if it really is the best way.
Question: Is it best to simply enable all the default rule sets (GPLv2 and ET) and then add them to a disable list in SID Mgmt as it is determined we don't need them or is there a more limited list of rulesets that will provide the protection I want given the list of public services my network provides?
Steve
Certainly nothing wrong with doing it the way you mention. I just usually err on the side of caution when doling out advice on the net about disabling broad swaths of Snort rules. You are totally correct that if the firewall is going to block all the traffic for those ports anyway, then you gain nothing security-wise by seeing those alerts unless you just want to know somebody is knocking at the door. Of course simply looking at the firewall logs and seeing tons of dropped port 1433 traffic would be an easy indicator as well.
Just an FYI from my old job (I'm retired now … ;)) ... one of the best places for an IDS in a corporate network is sniffing outbound traffic. In my old job we found a few malware infections that would otherwise have gone unnoticed by having a Snort sensor watching outbound traffic from the corporate network. Snort triggered on the malware signatures as the malware "phoned home". In your case where you said outbound traffic is not restricted, watching it with Snort might be a good idea. Just use IDS mode (no blocking) and monitor your alert logs closely.
Bill
-
Thanks, Bill.
I intend to do exactly that. In fact, I went ahead and installed snort in IDS mode with everything enabled. I am evaluating the alerts and disabling the ones that are benign.
We'll see how it works.
Steve -
Bill, regarding SID Mgmt, I seem to have to run a Force Update and restart Snort for changes to take effect.
Does that seem correct? -
Bill, regarding SID Mgmt, I seem to have to run a Force Update and restart Snort for changes to take effect.
Does that seem correct?What exactly do you mean by "Force Update"? Are you referring to the checkbox on the SID MGMT tab? If so, that should (when checked) send Snort a SIGHUP to force a reload of the rules. Snort has an internal mechanism for loading a new copy of updated rules into memory and then instantly switching the signature context from the last loaded rules to this most recent one. Then the old rules are removed from memory.
So you should not have to actually restart Snort itself when making changes on the SID MGMT tab. You will have to save the change and make sure the "reload rules" checkbox is checked on the appropriate interfaces.
Bill
-
That's what I thought but it does not appear to be accurate. Following an update to SID Mgmt as you describe, I was still getting false positive alerts from rules I had disabled.
What I have noticed is that after a rule update, which I've configured for each night, the rules are disabled and I receive no further alerts. This is fine. I'm happy to continue in this vane. It just seemed it was supposed to work the way you describe.Questions:
-
When I turn on the option to block (IPS), will Snort block IPs in the $HOME_NET?
-
What does pfSense do when I tell it to block offenders? Does it modify the firewall? The rules?
-
Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?
-
-
That's what I thought but it does not appear to be accurate. Following an update to SID Mgmt as you describe, I was still getting false positive alerts from rules I had disabled.
What I have noticed is that after a rule update, which I've configured for each night, the rules are disabled and I receive no further alerts. This is fine. I'm happy to continue in this vane. It just seemed it was supposed to work the way you describe.Questions:
-
When I turn on the option to block (IPS), will Snort block IPs in the $HOME_NET?
-
What does pfSense do when I tell it to block offenders? Does it modify the firewall? The rules?
-
Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?
- When I turn on the option to block (IPS), will Snort block IPs in the $HOME_NET?
Yes, unless the IP addresses are in a PASS LIST. The default PASS LIST will contain all locally-attached networks, the WAN IP, the WAN gateway IP and configured DNS server IP addresses. The default Pass List will be active unless you create your own custom one and assign it to an interface.
What does pfSense do when I tell it to block offenders? Does it modify the firewall? The rules?
pfSense itself essentially does nothing beyond creating a specific pf table. Snort will make a FreeBSD system call to insert the offending IP address into a pf (packet filter) table called snort2c. This table is created by the pfSense code each time the firewall is initialized. IP addresses inserted into that table get blocked (as if you put them in a block rule, but without requiring any action on your part in terms of modifying the firewall rules).
- Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?
No. This is not possible in Snort. The custom plugin within the Snort binary that inserts the IP address to be blocked into that snort2c table mentioned above triggers on every alert. It does not care what the rule action is. It does not even look at the rule action.
Bill
-
-
- Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?
No. This is not possible in Snort. The custom plugin within the Snort binary that inserts the IP address to be blocked into that snort2c table mentioned above triggers on every alert. It does not care what the rule action is. It does not even look at the rule action.
What I would like to happen is for these intrusions, like trying to access port 1433, to not generate an alert but block all access from the IP, not just 1433. In essence, block anyone trying to access my network in a way they should not. Now, this would be redundant if the blocks that snort creates are port specific and I don't know if they are, yet.
Given so many intrusion attempts, the list of alerts is very large and it would be much easier if, after identifying an intrusion, I could not generate an alert, log the attempt, and block the IP. The only option, right now, appears to be to disable the alert. If I suppress the alert, I assume it will not be blocked.
Bill, please let me know if it I appear to be overthinking this.
Steve
-
- Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?
No. This is not possible in Snort. The custom plugin within the Snort binary that inserts the IP address to be blocked into that snort2c table mentioned above triggers on every alert. It does not care what the rule action is. It does not even look at the rule action.
What I would like to happen is for these intrusions, like trying to access port 1433, to not generate an alert but block all access from the IP, not just 1433. In essence, block anyone trying to access my network in a way they should not. Now, this would be redundant if the blocks that snort creates are port specific and I don't know if they are, yet.
Given so many intrusion attempts, the list of alerts is very large and it would be much easier if, after identifying an intrusion, I could not generate an alert, log the attempt, and block the IP. The only option, right now, appears to be to disable the alert. If I suppress the alert, I assume it will not be blocked.
Bill, please let me know if it I appear to be overthinking this.
Steve
I believe that once the IDS alerts and blocks an IP, the IP is blocked completely and not just for the port. It still continues the alerts to show it is still happening, but the IP is completely blocked.
-
- Is it possible to log and block a rule without alerting? If so, would this be done by modifying the rule in SID Mgmt so "alert" becomes "log"?
No. This is not possible in Snort. The custom plugin within the Snort binary that inserts the IP address to be blocked into that snort2c table mentioned above triggers on every alert. It does not care what the rule action is. It does not even look at the rule action.
What I would like to happen is for these intrusions, like trying to access port 1433, to not generate an alert but block all access from the IP, not just 1433. In essence, block anyone trying to access my network in a way they should not. Now, this would be redundant if the blocks that snort creates are port specific and I don't know if they are, yet.
Given so many intrusion attempts, the list of alerts is very large and it would be much easier if, after identifying an intrusion, I could not generate an alert, log the attempt, and block the IP. The only option, right now, appears to be to disable the alert. If I suppress the alert, I assume it will not be blocked.
Bill, please let me know if it I appear to be overthinking this.
Steve
I believe that once the IDS alerts and blocks an IP, the IP is blocked completely and not just for the port. It still continues the alerts to show it is still happening, but the IP is completely blocked.
This is correct. Blocking is done by IP address and not by IP address and port. So all ports for the blocked IP are also blocked. It's the equivalent of using any/any for the port numbers in a firewall block rule.
Bill
