Talk:Suricata-vs-snort

From aldeid
Jump to navigation Jump to search
16:10, 12 April 2011 (CEST)
Good Write-up!
17:19, 12 April 2011 (CEST)
Interesting write up.

I'd like to note and know a few things.

  1. Ipv6 is completely supported.
  2. What exploits were used for the client side attacks? We love to know so that we can be sure we cover them.
  3. What configuration file was used (snort.conf). We'd love to know so that we can replicate your results.

Feel free to contact me at any time at joel [at] snort.org

Joel
18:15, 12 April 2011 (CEST)
Hi Joel,

Thanks for your support.

  1. IPv6: Updated.
  2. Client side attacks are detailed on this page.
  3. Configuration files are available on this page
19:20, 12 April 2011 (CEST)
  1. Snort DAQ supports PF_RING, so you can use that if you want.
  2. Would be nice to know what the detection is with the SO rules on.
17:00, 14 April 2011 (CEST)
I also notice that you have this in your snort.conf:

"include emerging.conf" What is this file?

Noticed that you have "DELETED" rules in your results, but your snort.conf file doesn't have deleted in it.

In addition you state that Snort needs a threshold.conf to increment counters and you couldn't test this feature, while this is not only not true, as Snort does not need a threshold.conf to increment counters, but you also /do/ use the threshold.conf in the snort.conf that you provide.

Snort does not need to be compiled with Inline support for it to work in inline mode. It works by default by using the -Q command line tag. The DAQ is responsible for the input method and tries to compile inline mode into DAQ by default.

Basically, it appears that your results are not matching up with your tests, and your tests are incomplete (as you are not running Shared Object rules)

18:27, 14 April 2011 (CEST)
Sebastien, interesting article. A couple of minor points you might want to correct:

- The IPv6 story is more complex than Joel notes. While both Suri and Snort inspect IPv6 traffic and write Unified2 alerts, I don't believe any of the frontends you discussed will see those alerts because the standard database-schema doesn't support them. Barnyard2 has a more nuanced description of IPv6 support that applies equally to Snort and Suri since they both output unified2: http://www.securixlive.com/barnyard2/index.php

- Regarding Acceleration: Both snort and suri support a variety of accelerators including pfring, endace capture-cards, napatech capture-cards, Intel X10 capture-cards, and myricom capture-cards. I would call this a draw between the two products.

- Regarding Multithreading: While suri is natively multi-threaded, snort can be "multi-process". All of the acceleration frameworks noted above support running multiple instances of snort on the same computer, each using a separate CPU. It's much more work up-front to configure, but this is how many big shops scale snort and it is well-tested.

Regarding Performance: Again, I think there's a more nuanced story than "suri is faster". Multi-thread suri can beat single-thread snort given enough hardware. Multi-process snort, is still quite a lot faster on equivalent hardware, though: http://lists.emergingthreats.net/pipermail/emerging-sigs/2010-August/008613.html

Thanks for the article!!!

- Mike Lococo
20:34, 14 April 2011 (CEST)
@Joel: Many thanks for your feedback. Here are some answers and comments:
  • include file: Default snort.conf file only contains VRT rules. Emerging Threat rules have been included in snort.conf with "include emerging.conf". I have added the file in this page so you can download it.
  • DELETED rules: Tests have been performed by 3 different teams (and I suspect 3 different snort.conf files). I will ensure tests are done again with the SAME configuration files and will update the write-up.
  • Threshold: Honestly, this part hasn't been deeply analyzed and certainly needs further investigations. Actually, I didn't fully understand how to increment counters. I'll analyze Snort docs more in the details and I'll update this test.
  • Snort Inline capabilities: I've updated the table accordingly to your comment.
  • SO rules/incomplete tests: I have seen your previous comment regarding SO rules. Currently analyzing it... (to be continued)
Thanks again for this review, it will help formalizing more accurate results.
20:47, 14 April 2011 (CEST)
@Mike: Many thanks for this very positive feedback. Your comments are really precise and constructive; I'll include them in my write-up.
19:21, 15 April 2011 (CEST)
After going through the 257 Client side samples that you have md5sums for, we have pulled 203 of them. When running these files through Snort we've alerted much much more than the post says we do. However, in order to replicate your results, we'd like to see if we can get copies of the other 54 samples from you. Is there some way I can provide you the list of the md5sum's that we don't have so that we may verify coverage?
Peter Manev
08:49, 27 July 2011 (MDT)
Hi,

Thank you for all the efforts to put this article together. If I might add a few things:

  1. s/^# alert/alert/ - re-activates a lot of rules, HOWEVER it does not reactivate "#alert" only "# alert" (with a white space between "#" and "alert"), when you do , that adds a good few hundred rules more (for both Suricata and Snort).
  2. There were no decoder rules included as well in the rule set - it makes a difference for Suricata(decoder-events.rules).

When all those are added and re-tested - you get responses from Suricata on a good few more things from the tests done - i.e Xmas scan,Nestea Attack, FullSynScan, Malformed Traffic, Land Attack, Nikto Random URI encoding, Client Side Attacks etc. , than originally reported that log no alerts.

example: 

07/25/2011-14:29:34.228005  
[**] [1:2200011:1] SURICATA IPv4 wrong IP version 
[**] [Classification: (null)] [Priority: 3] 
[**] [Raw pkt: 00 50 56 00 00 FF 00 0C 29 5E 40 2A 08 00 32 00 00 1C 00 01 00 00
40 01 FA 47 C0 A8 89 24 C0 A8

07/25/2011-14:23:07.775713  
[**] [1:2000546:7] ET SCAN NMAP -f -sX 
[**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.137
.36:48018 -> 192.168.137.35:80
07/25/2011-14:23:07.775713  
[**] [1:1228:9] DELETED SCAN nmap XMAS 
[**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.137
.36:48018 -> 192.168.137.35:80

07/25/2011-14:32:12.577971  
[**] [1:2000537:8] ET SCAN NMAP -sS window 2048 
[**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.137
.36:41990 -> 192.168.137.35:80

07/25/2011-14:34:32.370835  
[**] [1:527:8] GPL SCAN same SRC/DST 
[**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.137.35
:135 -> 192.168.137.35:135
07/25/2011-14:34:32.370835  
[**] [1:527:10] DELETED BAD-TRAFFIC same SRC/DST 
[**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.137.35
:135 -> 192.168.137.35:135

07/25/2011-14:46:48.273792  
[**] [1:22000069:1] SURICATA FRAG IPv4 Fragmentation overlap 
[**] [Classification: (null)] [Priority: 3] {UDP} 192.168.137.36:0 -> 192.168.137
.35:0
07/25/2011-14:46:55.431430  
[**] [1:22000069:1] SURICATA FRAG IPv4 Fragmentation overlap 
[**] [Classification: (null)] [Priority: 3] {UDP} 192.168.137.36:0 -> 192.168.137
.35:0

Thanks

05:22, 17 November 2011 (MST)
You may have seen this already. If not, feel free to peruse the material. http://www.thinkmind.org/download.php?articleid=icds_2011_7_40_90007
Retrieved from "https://www.aldeid.com/w/index.php?title=Talk:Suricata-vs-snort&oldid=38243"