14

What is the easiest way to test Snort IDS after installing? Would using and writing a rule that captures all of the traffic work? 

alert ip any any -> any any ( msg: "ICMP packet detected!"; sid: 1; )

That is, using its own rules.

One way that I know of for testing Snort is by using some programs such as Nmap, Metasploit, and something else, but how can it be done?

techraf
  • 9,141
  • 11
  • 44
  • 62
Mohsen Gh.
  • 309
  • 2
  • 5
  • 14
  • ping the snort machine. snort thinks pings are DoS. then check the alert directory. on linux this is, /var/log/squid/ if you are on windows then i dont know... – J'e Jan 15 '13 at 13:00

5 Answers5

10

There are two subtly different things you might want to test.

  1. Is Snort working in the sense that it's running, able to sniff trafic, testing it against the rules, and alerting you when one is triggered?
  2. Is Snort working in the sense that it's current rule set detects a specific intrusion of type X?

To test case 1, you make a rule that's easy to fire, like your example, and fire it. To test case 2, you have to attempt an intrusion of type X and confirm that it is detected.

You seem to be wanting to test case 1 (that the install has been done correctly) using the method in case 2, but you don't need to. Using a "fake" rule is a perfectly valid test that Snort is working in the first sense. And it's easier. Easy tests are good. You don't want to faff around with Metasploit when you're just checking that the alert emails go to the right person. Especially if you're not skilled in running intrusions - what if you do the intrusion wrong, and get a false test result? What if the intrusion attempt crashes the target (which is very likely on many types of intrusion.)

You really only need to test case 2, that a specific rule works against a real intrusion attempt, if you don't trust your rule set (in which case - why are you using it?) or if you're developing new rules.

Graham Hill
  • 15,394
  • 37
  • 62
  • I say "like your example" but your actual example is not a good test rule to set up. Something like "alert me if you see port 80 web traffic coming into this host" will be much easier to control. You want to be able to make the rule fire on command, so you can test, adjust settings, and test again. Something that's firing all the time will be too noisy. – Graham Hill May 22 '12 at 08:30
  • 1
    May i ask you give a detailed example?!! – Mohsen Gh. May 23 '12 at 09:51
  • 1
    If you have a host at 192.168.1.1 then this rule will detect any attempt to ping it: *alert icmp any any -> 192.168.1.1 any (msg: "Someone Pinged DotOne";)* – Graham Hill May 23 '12 at 17:30
  • 1
    Yes i know this. I do that!! But my question is how to use those programs to test Snort's rules(default rules i mean)? – Mohsen Gh. May 24 '12 at 06:28
  • To test a specific existing rule, you have to attempt the intrusion it protects against: but as I mention, you should not normally need to do that. – Graham Hill May 25 '12 at 11:02
9

It also might be worth taking a look at IDSWakeUp [Apr 2019: link is dead].

IDSwakeup is a collection of tools that allows to test network intrusion detection systems.

The main goal of IDSwakeup is to generate false attack that mimic well known ones, in order to see if NIDS detects them and generates false positives.

Like nidsbench, IDSwakeup is being published in the hopes that a more precise testing methodology might be applied to network intrusion detection, which is still a black art at best.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Petey B
  • 607
  • 1
  • 6
  • 8
6

To test that your default rules are working, assuming you've pulled them down with pulledpork, oinkmaster or something-else, you can simply browse to http://testmyids.com/ from a client whose traffic will be seen by the IDS, through your IDS device being inline or as a port span.

The http response contains the following text:

uid=0(root) gid=0(root) groups=0(root)

which will match one of the default snort rules that looks for "content" containing root. This is an old rule to check for successful privilege escalation when an attacker runs the id or whoami type commands to check that he/she has root access.

Here's an (old) blog also discussing how to test snort: How do I know if my Snort implementation is working?.

techraf
  • 9,141
  • 11
  • 44
  • 62
Mark Hillick
  • 2,124
  • 11
  • 14
  • testmyids.com is canonical. You can also play packet captures of known events into your system to see if snort alerts. There are many such captures included in the SecurityOnion distribution or available from various online resources. – adric Aug 01 '13 at 17:04
2

I know this is old but I will throw this out there anyhow...

Check out snort -T

This switch is designed for exactly the question that was asked. It's built-in, you don't need to monkey with rules, you don't need to send malicious traffic (even though it's "controlled"), you don't need to send any traffic. Will even tell you where your problems are.

user1801810
  • 379
  • 1
  • 9
0

As of 2019 the most robust Suricata/Snort test I found is:

dig a 3wzn5p2yiumh7akj.onion

Which triggers the following rule from emerging-trojan.rules:

alert dns $HOME_NET any -> any any (msg:"ET TROJAN Cryptowall .onion Proxy Domain"; 
dns_query; content:"3wzn5p2yiumh7akj"; depth:16; nocase; 
reference:url,www.bleepingcomputer.com/news/security/cryptowall-4-0-released-with-new-features-such-as-encrypted-file-names; 
classtype:trojan-activity; sid:2022048; rev:2; metadata:created_at 2015_11_09, 
updated_at 2015_11_09;)

Background: the signatures mentioned above are out of date and most of them do not contain proper flow specification which will make Snort or Suricata blind to them. Also to reach testmyids.com you need a working proxy and this adds to the complexity. The .onion DNS resolution alert however does not require a working Internet connection as it is triggered by a mere attempt to resolve the name by the client.

kravietz
  • 412
  • 2
  • 7