Suricata

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?