2

This is my rule:

alert udp 192.168.1.1 4000 -> 192.168.1.1 7000 (msg:"This rule doesn't work"; sid:1234567;)

I am running snort against a precaptured packet file where there are UDP packets that match the rule given above. However, they are ignored by snort and do not actually make it into the results file. Why does snort ignore those packets and how can I force snort to recognize those packets? Since they match the rule (above) in my rules file, I would think they'd show up.

Improve this question
  • 3
    It is important for us to know how you are running Snort, on which interface is it listening, have you properly added the local rule to your local.rules, sid-msg.map and other files, etc. I hope you are not making Snort listen on eth0 while running your pcap file. Plus this question is much better suited for snort-users mailing list. They have a pretty active mailing list. I suggest checking it out on www.snort.org – pnp Mar 25 '13 at 4:45
  • Are other snort alerts firing? How are you 'running snort against' a file? – schroeder♦ Mar 25 '13 at 19:16
  • @pnp I'm running it like I described, with the "replay" option. Like snort -r file.previouscapture.out -c myRulesFile.rules -X -l log. I also tried it with various other command line options, always keeping the essential options (the rules file, the file containing the capture, and the log location). No matter how I run it the alerts that have same src/dst IP are ignored; in fact, snort prints out a warning saying that they're being ignored. The rule works if it's a different src/dst IP. – KyleM Mar 26 '13 at 18:16
  • @pnp Also, like I said everything is pretty "normal" I think. I'm using the normal options that make snort run against a pre-captured pcap file. I'm specifying my local.rules file on the command line. I didn't mess with a sid-msg.map file or any other files, why should I? All of my other rules worked just fine without touching any other files... – KyleM Mar 26 '13 at 18:19
  • I once again suggest the snort-users mailing list. Don't forget to share the answers you get from there... – pnp Mar 28 '13 at 8:11
1

Preamble: I wanted to just add a comment first, as it's still rather unclear what might be causing your problem from the information you provide, but I ran out of space reserved for comments, so here goes my suggestion (no guarantees it's actually the case):

On what kind of a capture file you're trying to run Snort rules through is rather unclear both from your question, as well as your later comments. It's however possible that you're running your replay in a single packet capture mode, but from a file with many pcaps. That's what flag -r implies (is the same as using -pcap-single=<file>) and your comment that it works on some rule and not the other suggests this might be the case also (if in one instance the first packet capture would match your rules, while in another the pcap that would match your rules might not be the first one in the list of many). To make Snort replay process multiple pcaps from a single capture file, use -pcap-file=<file> instead.

To be sure this is the case, you could test that with a -pcap-no-filter flag and see if it iterates through all of them in the output. Other command line arguments relevant to your use-case are listed here.

Alternatively, you could change your rule to match all packets, and see how many results it returns:

alert udp any any -> any any (msg:"This should match all UDP packets in an input file";)

Other than this, I don't see any problems with your snort rule you gave in the example, and it follows Snort rules form properly.

Improve this answer
  • Thanks for the info. It wasn't the case though. My pcap file is of a single capture. I ran tons of other tests, all of which worked. All tests were run one at a time (e.g. edit the rules file, take out the ones I'm not currently testing, then repeat). Packets were always matched properly except for this one rule, and it only ignored the packets with matching src and dst. – KyleM Apr 9 '13 at 14:28
  • @KyleM - Yeah it was a stab in the dark rather, but failing to see any other possible problems with your example, I thought it's worth a shot. Could you please edit your answer to include the exact problematic rule and also one that works? – TildalWave Apr 9 '13 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.