Snort - alerts tab - reference to sid (link) possible?
-
Hi,
I am playing with snort since mandy days. It is interesting which alerts could arise in a home network. I find it a little bit uncomfortable to find out what rule is behind the different SIDs.
I often go to "LAN rules" and then hopefully finding the correct category ans search for the SID.I would like to make a suggestion to link to the specific rule on the alerts tab or if this isn't that easy to code perhaps another option in the "LAN rules" –> "Categroy pulldown" like "any" so I can search using the webbrowser or adding a search field which allows me to search for a specific SID.
Or how do you analyze your alerts?
PS:
By the way a small question: Where is the advantage/disadvantage if I suppress an alert or if I disable a signature?
Is a disable signature disabled for every interface or just for the specific one? Suppressing can be defined for specific interfaces as far as I know using the suppress_List.Thank you for your help and suggestions! I really like the pfsense snort package but I need more experience with it and need to learn more about it ...
-
Hi,
I am playing with snort since mandy days. It is interesting which alerts could arise in a home network. I find it a little bit uncomfortable to find out what rule is behind the different SIDs.
I often go to "LAN rules" and then hopefully finding the correct category ans search for the SID.I would like to make a suggestion to link to the specific rule on the alerts tab or if this isn't that easy to code perhaps another option in the "LAN rules" –> "Categroy pulldown" like "any" so I can search using the webbrowser or adding a search field which allows me to search for a specific SID.
Or how do you analyze your alerts?
PS:
By the way a small question: Where is the advantage/disadvantage if I suppress an alert or if I disable a signature?
Is a disable signature disabled for every interface or just for the specific one? Suppressing can be defined for specific interfaces as far as I know using the suppress_List.Thank you for your help and suggestions! I really like the pfsense snort package but I need more experience with it and need to learn more about it ...
Linking as you suggest within the GUI would be difficult (not impossible, but difficult and potentially computationally intensive while searching for the rule). Snort does not remember the "category" once it loads a rule. They are all just one big in-memory list of rules.
Most folks who want to do in-depth analysis of Snort alerts will send them to another system such as Snorby, ELSA or similar tools. That's what the Barnyard2 feature of the Snort package is used for. It transfers the alerts over to another analysis tool on a separate box.
The difference between suppressing a rule and disabling a rule is the former does not remove the rule from that in-memory list I mentioned above. Snort will still load the rule and test all incoming traffic against the rule. It just will not alert if the traffic matches on the rule. So it can be said you wasted CPU time checking traffic on a rule you did not alert on.
However, if you have CPU cycles to spare and still want to see the alerts but not have them "block", then suppression is the way to go.When you disable a rule, that rule is never even loaded into the in-memory list by Snort. Therefore it essentially does not exist so far as Snort is concerned. No CPU cycles ever get used evaluating that rule.Finally, everything in the pfSense Snort package is "interface dependent". That means rule disables/enables, suppress lists and pass lists are assigned and managed on a "per interface" basis.
Bill
EDIT: strikethrough text was added to remove incorrect info posted earlier.
-
Thank you for your feedback.
I have an additional question:
I am downloading the snort updates once a day. Will there be only new rules or is it possible that an existing rule will be modified compared to a previous rule?
I am interested in this question because sometime I add alerts/rules to the suppress list because they fire to often and perhaps some weeks later this rule gets an update and then it would make sense to active it again.So this is not a question directly to the snort package but to the snort experts how the updates are working.
And if new updates can modify existing rules - how do you behave with the rules you have on the suppress list? Do you delete all rules from the suppress list to test if a rule now behaves "better" in your environment?Thanks!
-
The difference between suppressing and rule and disabling a rule is the former does not remove the rule from that in-memory list I mentioned above. Snort will still load the rule and test all incoming traffic against the rule. It just will not alert if the traffic matches on the rule. So it can be said you wasted CPU time checking traffic on a rule you did not alert on. However, if you have CPU cycles to spare and still want to see the alerts but not have them "block", then suppression is the way to go.
Bill, can you clarify please - you are saying that suppressed rule will not alert, but then go on saying that if alerts are needed without block, rule needs to be suppressed?
From what I understand, you block based on alerts and there is no way to have some rules to block and some to only alert in the same Snort instance? Am I reading this wrong? -
Interesting question. I didn't recognize that when I read it the first time.
Perhaps it will belogged somewhere else. On the interfaces tab there is a special "Log" tab. -
The difference between suppressing and rule and disabling a rule is the former does not remove the rule from that in-memory list I mentioned above. Snort will still load the rule and test all incoming traffic against the rule. It just will not alert if the traffic matches on the rule. So it can be said you wasted CPU time checking traffic on a rule you did not alert on. However, if you have CPU cycles to spare and still want to see the alerts but not have them "block", then suppression is the way to go.
Bill, can you clarify please - you are saying that suppressed rule will not alert, but then go on saying that if alerts are needed without block, rule needs to be suppressed?
From what I understand, you block based on alerts and there is no way to have some rules to block and some to only alert in the same Snort instance? Am I reading this wrong?Sorry. You are correct that I misspoke a bit. Within the context of the Snort package and the way it handles alerts, when you Suppress a rule it is still checked, but just never alerts and blocks. When you disable a rule, it is never even checked, therefore it can't alert or block.
I was not clearly putting into words what I was thinking in my head… :-[. I have edited my previous post to "strikethrough" the errant statement. Thanks for setting me straight... :D
Bill
-
Thank you for your feedback.
I have an additional question:
I am downloading the snort updates once a day. Will there be only new rules or is it possible that an existing rule will be modified compared to a previous rule?
I am interested in this question because sometime I add alerts/rules to the suppress list because they fire to often and perhaps some weeks later this rule gets an update and then it would make sense to active it again.So this is not a question directly to the snort package but to the snort experts how the updates are working.
And if new updates can modify existing rules - how do you behave with the rules you have on the suppress list? Do you delete all rules from the suppress list to test if a rule now behaves "better" in your environment?Thanks!
The updates can modify existing rules as well as provide completely new rules. For both rule packages the vendors post the equivalent of release notes for their rule updates. These notes show which SIDs were modified, added or deleted (usually rules are just disabled by commenting them out in the rule package instead of outright deleting them). If you scroll down to the RULES section of this page- https://www.snort.org/downloads - you will see a link to the most recent release notes for the Snort VRT rules.
-
Sorry. You are correct that I misspoke a bit. Within the context of the Snort package and the way it handles alerts, when you Suppress a rule it is still checked, but just never alerts and blocks. When you disable a rule, it is never even checked, therefore it can't alert or block.
I was not clearly putting into words what I was thinking in my head… :-[. I have edited my previous post to "strikethrough" the errant statement. Thanks for setting me straight… :D
[/quote]Ok, great thanks for clarification, but I wrote this not only to clarify, but also ask if you can add this functionality - log alert without blocking on some rules even if blocking is enabled on the interface. This may be helpful when I have majority rules enabled for blocking, but still want to test how specific rules react without affecting connections… or just for some special logging purposes.
It might not be easy with the current architecture of the Snort package, but maybe some time in the future... :) -
This may be helpful when I have majority rules enabled for blocking, but still want to test how specific rules react without affecting connections… or just for some special logging purposes.
Yes we need the log rule action ;)
F.
-
This may be helpful when I have majority rules enabled for blocking, but still want to test how specific rules react without affecting connections… or just for some special logging purposes.
Yes we need the log rule action ;)
F.
I have considered adding that feature. Still trying to figure out the best way to expose it while at the same time not totally upsetting things for all the users that are accustomed to the legacy method of the package (where any alert is the same as a block). I have tossed a few possibilities around in my head. Whatever I do for Snort would likely also get rolled into Suricata.
Bill
