Suricata/Snort master SID disablesid.conf

[lobotiger]

I'm just getting into playing with snort and this was an interesting thread.  :)  I have a question and I don't know if it's dumb to ask or not but….when you suppress a rule does that mean that further triggers of that rule will no longer be visible?  I know most of the ones in the lists here are false positives but what about if it's a real intrusion?  I guess another question is, if all of these generate so many false positives, why are they including in the rule sets to begin with?  Shouldn't the owners of those updates just remove them since everyone else seems to be doing so?

LoboTiger

[bmeeks]

@lobotiger:

I'm just getting into playing with snort and this was an interesting thread.  :)  I have a question and I don't know if it's dumb to ask or not but….when you suppress a rule does that mean that further triggers of that rule will no longer be visible?  I know most of the ones in the lists here are false positives but what about if it's a real intrusion?  I guess another question is, if all of these generate so many false positives, why are they including in the rule sets to begin with?  Shouldn't the owners of those updates just remove them since everyone else seems to be doing so?

LoboTiger

The answer to your first question is "yes, when suppressed you no longer get alerts from the rule or preprocessor".  So be sure it really is a false positive before you routinely suppress an alert.

As for your second question, you have hit upon something that puzzles me as well.  The problem is caused, I believe, by the fact many software packages (servers and clients) do not follow all the various RFC standards to the letter.  Some deviations are due to mistakes or alternate interpretations of the RFC, and some may just be certain vendors trying to "one up or be one better" than their competition by "tweaking" how their software complies with an RFC.  No matter which is the true cause, the result is software than can generate false positives because Snort (and Suricata as well) inspect traffic according to the RFCs (well, most of the time).  There are also bugs from time to time in the detection code for Snort and Suricata.  For example, Snort today has a problem with parts of the SSL handshake (it loses track of the stream and sees client and server HELO messages out of order and then generates an alert).  The Snort VRT is working on fixing this bug.

Bill

[lobotiger]

Cool, thanks for the answers Bill.

LoboTiger

[rcampbell]

I share the same concern as lobotiger and I want to try and understand the logic of a master supress list and whether it is good idea to use such a list.

I'll take one example from the list as posted, this is the first one with a description so I'll use this:

#(http_inspect) DOUBLE DECODING ATTACK
suppress gen_id 119, sig_id 2

Lets assume a 'Double Decoding Attack' is bad and you would want to block that type of traffic.  Lets assume you go to a trusted website and it is blocked by this rule… i.e. a false positive.  Doesn't it make sense to only supress the rule for that specific IP address only?  Why supress the rule as it is listed with no specific IP?  Am I correct in thinking the rule is now supressed for all IP's?  Isn't that a bad thing in the sense that you would now never detect any Double Decoding Attack from any source?

Can anyone please clarify?

[BBcan177]

The general consensus is to Disable (false positive) rules before adding suppression for False Positives. However, as you said, if the Alert is only generated from a few IPs than its best to use suppression for those particular IPs only.

What you don't want to do is add a suppression without the "track_by src/dst" in the suppression. So in these cases, using suppression is wasting processing power and its best to disable the rule.

As Bill Meeks stated above, some alerts are false positive due to non-compliance to RFCs etc.

For Alerts like HTTP Inspect, you can look at the HTTP Pre-Processor to see if you can tune it to your setup to avoid these false positives.

Some Alerts can't be disabled by the Rules and the Pre-Processors might not be configurable via the GUI, so for a few alerts, you might need to use Suppression. I believe that with each version of Snort, more of the Pre-Processors are being added, so we have more buttons to play with to help tune it. For Suricata, it has a "Wan App Parser" which you could take a look at or for Stream Alerts, the "Wan Flow/Stream".

These are Threads in the forum for what people are using as a Baseline for Disabling Rules.

https://forum.pfsense.org/index.php?topic=78062.0
https://forum.pfsense.org/index.php?topic=64674.0

[panz]

I had this problem and tuning didn't solve anything; I had to disable the detection :(

https://forum.pfsense.org/index.php?topic=80068.msg436866#msg436866

[Thrae]

I suggest if you're getting too many false positives and at a loss for how to configure around them, try this:

event_filter gen_id 0, sig_id 0, type both, track by_src, count 10, seconds 600

This will filter events such that only offending IPs which create more than 10 events in 10 minutes will be blocked –- this seriously helps out when packets are fragmented oddly or a server just responds weirdly once in a while. You may change "count 10" and "seconds 600" to make it less restrictive or more restrictive.

[panz]

@Thrae:

I suggest if you're getting too many false positives and at a loss for how to configure around them, try this:

event_filter gen_id 0, sig_id 0, type both, track by_src, count 10, seconds 600

This will filter events such that only offending IPs which create more than 10 events in 10 minutes will be blocked –- this seriously helps out when packets are fragmented oddly or a server just responds weirdly once in a while. You may change "count 10" and "seconds 600" to make it less restrictive or more restrictive.

How do I apply this method?

[BBcan177]

This is added to the interface suppression list. So for a particular suppression you change the gid and sid accordingly.

You will need to restart the interface to allow it to be enabled.

http://manual.snort.org/node19.html

http://books.msspace.net/mirrorbooks/snortids/0596006616/snortids-CHP-9-SECT-5.html

[panz]

So, if I'm understanding right, I have to add this line to my Suppress List (both on LAN and WAN interfaces)

event_filter gen_id 123, sig_id 8, type both, track by_src, count 10, seconds 600

gen_id 123, sig_id 8 corresponds to #(spp_frag3) Fragmentation overlap

panz

[bmeeks]

@panz:

So, if I'm understanding right, I have to add this line to my Suppress List (both on LAN and WAN interfaces)

event_filter gen_id 123, sig_id 8, type both, track by_src, count 10, seconds 600

gen_id 123, sig_id 8 corresponds to #(spp_frag3) Fragmentation overlap

panz

Yes, that's correct.  Open the Suppress List in edit mode and paste in the line.  Save the list and then restart the affected Snort interface.  Make sure that the Suppress List you edit is the one currently used by the interface.  You can check this on the INTERFACE SETTINGS tab for the interface.

Bill

[Thrae]

Note that:

event_filter gen_id 0, sig_id 0, type both, track by_src, count 10, seconds 600

Will specifically filter ALL events to 10 per 10 minutes, a quick-and-dirty way to stop massive false-positives while still providing some protection. What I've been doing recently is slowly lowering the count –- now at 3 --- while making different event_filter rules for specific flowbits. Example:

event_filter gen_id 0, sig_id 0, type both, track by_src, count 3, seconds 600

## False Positives ##
; (spp_sdf) SDF Combination Alert
event_filter gen_id 139, sig_id 1, type both, track by_src, count 6, seconds 600
; (http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE
event_filter gen_id 120, sig_id 8, type both, track by_src, count 6, seconds 600
; (http_inspect) UNKNOWN METHOD
event_filter gen_id 119, sig_id 31, type both, track by_src, count 6, seconds 600

From my experience I'm not sure I actually agree with the idea of a master suppress list, since I've found false positives will be based on what sites you tend to visit, the quality of your connection with these sites (many false positives are simply malformed packets), etc. However, this filtering should provide at least a little more protection than simply suppressing the alert always.

Also note these event filters are tracking by the source, it shouldn't really matter how many users you have (IE, you don't necessarily need to up "count" because you have more users).

Next on my to-do is figure out how to do event filtering for certain IPs and IP ranges; I think it can be done using rate_filter set to at least "alert". I'm hoping to essentially disable the suppression for my servers.

[panz]

@bmeeks:

@panz:

So, if I'm understanding right, I have to add this line to my Suppress List (both on LAN and WAN interfaces)

event_filter gen_id 123, sig_id 8, type both, track by_src, count 10, seconds 600

gen_id 123, sig_id 8 corresponds to #(spp_frag3) Fragmentation overlap

panz

Yes, that's correct.  Open the Suppress List in edit mode and paste in the line.  Save the list and then restart the affected Snort interface.  Make sure that the Suppress List you edit is the one currently used by the interface.  You can check this on the INTERFACE SETTINGS tab for the interface.

Bill

Could I force this to work only for a certain IP address? Is it possible to add the IP address I want to filter after the comma past the "track by_src"?

[BBcan177]

Yes you can add an IP or CIDR and after that include additional other syntax as required.

9.5.3 Suppression Rules

Suppression rules are similar in syntax to standalone threshold rules. Suppression rules can suppress alerts by signature, by source or destination address, or by an entire CIDR network block. This flexibility has considerable power. Care must be taken to only suppress the correct alerts or addresses. An administrator could inadvertently suppress legitimate alerts.

Suppression rules are written with the following syntax:

suppress gen_id gen-id, sid_id sid-id, track [by_src|by_dst], ip IP/MASK-BITS

Suppress this event completely:

suppress gen_id 1, sig_id 114

Suppress this event from this source IP address:

suppress gen_id 1, sig_id 114, track by_src, ip 10.2.1.154

Suppress this event to this destination CIDR block:

suppress gen_id 1, sig_id 114, track by_dst, ip 10.2.1.0/24

[panz]

Thanks, this is for Suppress action. Am I able to use the track by_src with the event_filter?

Panz

[BBcan177]

Yes you can add other settings after the IP address.

[panz]

@BBcan177:

Yes you can add other settings after the IP address.

Sorry, I didn't explain my question well. Is this row ok? :

event_filter gen_id 123, sig_id 8, type both, track by_src, 106.188.165.67, count 10, seconds 600

I'm asking because – in the examples regarding the event_filter – I can't find the "track by_src" followed by an IP address, like in the examples regarding the suppress command.

I hope that my question is clear now.

[BBcan177]

@panz:

Sorry, I didn't explain my question well. Is this row ok? :

event_filter gen_id 123, sig_id 8, type both, track by_src, 106.188.165.67, count 10, seconds 600

After looking at the Docs, it looks like only the "Suppression" rules can use an IP where event_filter is only by src/dst…

If you wanted to have a suppression and a event_filter, you could do the following in order:

suppress gen_id 123, sig_id 8, track by_src, ip 106.188.165.67
event_filter gen_id 123, sig_id 8, type both, track by_src, count 10, seconds 600

This would suppress this sid/IP combination, and event_filter would limit any other IPs. Or you can just use the event_filter by itself.

[panz]

My intention was only to event_filter one address, my favorite AirVPN server.

[deanot]

The list is a good idea, BUT, we have no idea what is being suppressed.  At least I have no idea…..  Using this list literally stops everything from showing up and getting banned, is this a good idea?.  For all I know, you could have suppressed a bunch of things that should not be.

Listing what you suppressed would have been a better approach, I am going to avoid using this and attempt to build something that I have a clue about.

Not knocking your work, but as mentioned, I have no idea what you're suppressing.