Hey, wassup Y’all?
I cant do the second rule in the Snort IDS.
The question is: “IDS: On the Ubuntu system, create a local Snort rule to alert on traffic to and from TCP port 1337. The alert message should read “LEET Detected”.
(Hint: You will need two rules.)”
I did the following rules in the /etc/snort/rules/local.rules:
alert tcp any any → any 1337 (msg:“LEET Detected”; ) - Worked
alert tcp any 1337 → any any (msg:“LEET Detected”; ) - Not Worked
alert tcp any 1337 → any 1337 (msg:“LEET Detected”; ) - Not Worked
alert tcp any any ← any 1337 (msg:“LEET Detected”; ) - Not Worked
alert tcp any 1337 ← any any (msg:“LEET Detected”; ) - Not Worked
When i run the script called checksnortrule.sh at Ubuntu Desktop, it gives the message: “alert tcp any any → any 1337 (msg:“LEET Detected”; )
First rule is correct.”
Thanks
The second rule will be bidirectional (<>)
2 Likes
Thanks so much mr @JosephWhite!
Hello @JosephWhite, may I ask you why the bidirectional rule is not enough ? To get the flags, we always have to precede the bidirectional rule with the unidirectional rule “any any → any {destination-port}”. It’s repetitive, isn’t it ?
Excellent question!!
I tested:
alert tcp any any - > any 80 […]
alert tcp any 80 <> any any […]
vs…
alert tcp any 80 <> any any […]
vs…
alert tcp any any <> any 80 […]
They all seem to work the same. I’m using <> as a proxy for < - (as there is no < - in Snort) BUT as you rightly point out, bidirectional (<>) means that each side is both source and destination making two rules to detect basic “web traffic” as we do in the lab a bit redundant.
That being said, you really want to stick to unidirectional rules as much as possible to improve performance and reduce false positives. The bidirectional rules should be used when necessary, ideally for two-way communication scenarios (like C2 traffic). Thus my basic example is not a good use case for a bidirectional rule.
I wish I had a schwag button I could push to send you a thank you for this great question.