Bug #2847
closed
Confusing warning “Rule is inspecting both directions” when inspecting engine analysis output
Added by Samu Voutilainen about 5 years ago.
Updated almost 5 years ago.
Description
Hi,
I’ve been investigating engine analysis output for my rules, and it seems that most of the the warnings are coming from ”Warning: Rule is inspecting both directions”. For example following:
== Sid: 2013845 ==
alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"ET INFO DYNAMIC_DNS Query to a Suspicious *.ez-dns.com Domain"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|06|ez-dns|03|com"; fast_pattern; nocase; distance:0; classtype:bad-unknown; sid:2013845; rev:2; metadata:created_at 2011_11_04, updated_at 2011_11_04;)
Rule contains 2 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern "\x06ez-dns\x03com" on "payload" buffer.
Warning: Rule is inspecting both directions.
I haven’t found anything from Google nor reading source easily said what it’s for. My assumption is that it’s something like that the engine is analysing the rule for both incoming and outcoming traffic. Is that correct? If so, does that mean that every rule should specify the direction where traffic should be inspected at?
A bit related, is there a place (other than source) to read what these warnings are actually trying to say?
- Assignee set to OISF Dev
- Target version set to Support
This should just occure if the flags to_server and to_client are both set. Can you give us more details about your configuration? how are HOME_NET and EXTERNAL_NET configured?
Andreas Herz wrote:
how are HOME_NET and EXTERNAL_NET configured?
EXTERNAL_NET is just negation of HOME_NET:
vars.address-groups.EXTERNAL_NET = !$HOME_NET
HOME_NET is constructed from multiple variables, but because it also contains public IPs, I rather not paste it publicly here. It’s something like...
vars.address-groups.LOCALHOST = [127.0.0.1,::1,2.2.2.2]
vars.address-groups.IPV4_HOME = [1.1.1.1]
vars.address-groups.IPV6_HOME = [2001::/64,2002::1]
vars.address-groups.HOME_NET = [10.0.0.0/8,$LOCALHOST,$IPV4_HOME,$IPV6_HOME]
This config output looks a bit off, how did you get it running?
I tried this and I don't get the warning with that rule:
vars:
# more specific is better for alert accuracy and performance
address-groups:
LOCALHOST: "[127.0.0.1,::1,2.2.2.2]"
IPV4-HOME: "[1.1.1.1]"
IPV6-HOME: "[2001::/64,2002::1]"
HOME_NET: "[10.0.0.0/8,$LOCALHOST,$IPV4-HOME,$IPV6-HOME]"
My output was from suricata --dump-config. Config has similar to what you tested.
Is there anything I could do to debug this or is there some extra information that would be helpful to debug this issue?
Andreas Herz wrote:
This should just occur if the flags to_server and to_client are both set. [...]
This, but also when the flow direction is not set. Based on the rest of this signature, it would appear this is looking for a dns query, so flow:to_server should be added. Without it, Suricata will also look for the pattern in to_client traffic.
The address vars don't affect this.
Oka, thanks for the information. I guess that warning makes sense, though I assume there will be some false positives since some things makes sense to analyze to both directions. Actually, even in this case, in case you don’t trust your ”home network”, it may make sense to inspect that traffic too.
Just an idea, but maybe it would make sense to make this specific warning configurable, as it may well be that it’s false positive in a lot of cases?
I guess this ticket can be closed.
I think the risk of FP is very small especially when addresses and ports are used in the rule. In the example you gave
udp $HOME_NET any -> $EXTERNAL_NET 53
It would match on traffic to_server using dest port 53 but also to_client using dest port 53. Normally you would expect the src port to be 53 for to_client dns packets.
Oh, I see. And even if <-> is used, the rule only should specify where it should do the inspection, regardless of who is initiating the connection (i.e. look only from data from source or answer)?
I tried to think some way to improve that warning, maybe something like ”The rule is inspecting both request and response.” would make it a bit more clear?
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Jeff Lucovsky
- Target version changed from Support to 70
Hi Jeff, can you make this warning more clear (see comment 8)?
- Tracker changed from Support to Bug
- Status changed from Assigned to Closed
- Target version changed from 70 to 5.0rc1
Also available in: Atom
PDF