Project

General

Profile

Actions

Bug #2847

closed

Confusing warning “Rule is inspecting both directions” when inspecting engine analysis output

Added by Samu Voutilainen over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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?

Actions #1

Updated by Andreas Herz over 5 years ago

  • 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?

Actions #2

Updated by Samu Voutilainen over 5 years ago

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]
Actions #3

Updated by Andreas Herz over 5 years ago

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]" 

Actions #4

Updated by Samu Voutilainen about 5 years ago

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?

Actions #5

Updated by Victor Julien about 5 years ago

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.

Actions #6

Updated by Samu Voutilainen about 5 years ago

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.

Actions #7

Updated by Victor Julien about 5 years ago

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.

Actions #8

Updated by Samu Voutilainen about 5 years ago

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?

Actions #9

Updated by Victor Julien about 5 years ago

  • 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)?

Actions #10

Updated by Victor Julien about 5 years ago

  • Tracker changed from Support to Bug
  • Status changed from Assigned to Closed
  • Target version changed from 70 to 5.0rc1
Actions

Also available in: Atom PDF