[Snort-users] To check for current SNORT limitations in 2.9

Joel Esler (jesler) jesler at cisco.com
Mon Oct 30 15:06:34 EDT 2017


Also:

https://snort.org/faq/can-i-have-help-with-my-homework


--
Joel Esler | Talos: Manager | jesler at cisco.com<mailto:jesler at cisco.com>






On Oct 30, 2017, at 2:13 PM, DFIRob via Snort-users <snort-users at lists.snort.org<mailto:snort-users at lists.snort.org>> wrote:

IMO:
rule for a specific attack/policy,
more efficient detection,
lower false positives,
Have nothing to do with Snort, and more to do with the ruleset (unless you're planning to write a preprocessor). Although some false positives could be reduced on the IDS side, false negative reduction (aka more efficient detection, in a way) could be an improvement to the snort engine.
granular detection,
What do you mean by that?
use of less resources,
Yeah, sure, that's a possible improvement to Snort.
better administration.
Maybe? Depends on what you define by administration...

My 2 cents as a Snort user..

Rob'

On Mon, Oct 30, 2017 at 4:47 PM, Robert Muscat via Snort-users <snort-users at lists.snort.org<mailto:snort-users at lists.snort.org>> wrote:

I gathered it from some papers, the majority is from a particular paper. Can someone advise if any of these are relevant. Are there any more know issues? I need to find a niche area in SNORT where I can provide at least a minor enhancement for an undergraduate thesis, with an office environment as a scenario. Problem is I haven't yet decided on which area I shall focus ex. rule for a specific attack/policy, more efficient detection, use of less resources, lower false positives, granular detection, better administration. Unfortunately I have yet to use SNORT, but I also have to focus on an area where I can provide an improvement of some sort. I am aware that it is an open ended idea.

Your feedback is highly appreciated.
________________________________
From: Joel Esler (jesler) <jesler at cisco.com<mailto:jesler at cisco.com>>
Sent: Monday, October 30, 2017 3:29 PM
To: Robert Muscat
Cc: snort-users at lists.snort.org<mailto:snort-users at lists.snort.org>
Subject: Re: [Snort-users] To check for current SNORT limitations in 2.9

Where did this come from?


--
Joel Esler | Talos: Manager | jesler at cisco.com<mailto:jesler at cisco.com>






On Oct 29, 2017, at 10:50 AM, Robert Muscat via Snort-users <snort-users at lists.snort.org<mailto:snort-users at lists.snort.org>> wrote:


Hi,

Can someone confirm which of the below problems are still persistent in the stable version (not 3.0)


  *
Performance drops during heavy network traffic
  *
Adding additional snort instances and modifying snort configurations can lead to mistake magnification. So experienced users only can use it.


  *
Snort cannot detect UDP and TCP flooding attacks; it can only detect ICMP flooding attacks.
  *
When snort is in its active detection mode it will utilize 100% CPU and will slow down the performance of the system to a greater extent.


  *
In snort, graphical interface is not there by default and can be achieved only by adding extra plug-ins.


  *
By default snort will not provide any anomaly detection and is purely a misuse based system. Extra plug-in is required.


  *
While handling the normal traffic snort will process the packets at a slow phase. During a DoS and DDoS attack snort throughput increases drastically, but will drop large number of packet.


  *
When the number of rules increases, memory utilization also increases and hence will take longer to initialize all the rules.


  *
Snort checks each and every field specified in the rule and creates RTN, OTN for all the fields in the rule. Therefore it will decrease the processing throughput by performing several unnecessary comparisons with all the fields in the rule.


  *
Snort is capable of detecting flooding attacks by default. If snort needs to be configured to detect other modes of attacks then the configuration file have to be changed which indeed is a tedious task.


  *
Snort is purely an intrusion detection system and is not an intrusion prevention system.


  *
Snort will start to drop the packets at a massive rate when the incoming packet rate is more.Therefore possibilities of detecting possible attack patterns are more since it fails to analyze those dropped packets.

If there are more known issues, I appreciate you can forward them to me.

Thanks in advance!


_______________________________________________
Snort-users mailing list
Snort-users at lists.snort.org<mailto:Snort-users at lists.snort.org>
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

Please visit http://blog.snort.org<http://blog.snort.org/> to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette


_______________________________________________
Snort-users mailing list
Snort-users at lists.snort.org<mailto:Snort-users at lists.snort.org>
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

Please visit http://blog.snort.org<http://blog.snort.org/> to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette


_______________________________________________
Snort-users mailing list
Snort-users at lists.snort.org<mailto:Snort-users at lists.snort.org>
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20171030/66cac135/attachment.html>


More information about the Snort-users mailing list