Rule priority (pass with packet inspection)

Rules
1

We want to allow traffic from trusted sources to the internet, but still inspect the traffic. We want to disallow all other traffic

I tried this

drop tcp any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; sid:100003; rev:7; priority:1; metadata:created_at 2010_09_23, updated_at 2010_09_23;)
pass ip 198.18.0.10/32 any -> ![10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,198.18.0.0/15] any (msg:"Allow traffic from 198.18.0.10/32 to all except private ranges"; sid:2000006; rev:1; priority: 2;)

But it will always let the traffic pass because of the pass rule, whatever the priority is. I even set the action order to drop first but the pass just gets priority.

Any idea how we can solve this?

2

What version do you run?
How do you run it?
How does the suricata.yaml look like?

3

Seeing your answer I would think this is not intended behavior?

We have built Suricata from source, our suricata yaml

%YAML 1.1
---
action-order:
  - reject
  - drop
  - alert
  - pass
logging:
  outputs:
    - console:
        enabled: yes
    - file:
        enabled: yes
        filename: /var/log/company/suricata.log
        append: yes

  default-log-level: debug
  default-output-filter:

rule-files:
  - /etc/company/rules/firewall.rules

nfqueue:
  mode: accept
  repeat-mark: no
  buffer-size: 0
  defrag: yes
  queue:
    - id: 1
      threads: 4

vars:
  address-groups:
    HOME_NET: "[192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, 198.18.0.0/15]"

default-rule-path: /etc/company/
max-pending-packets: 1024

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/company/eve.json
      types:
        - alert:
            metadata: yes
            payload: yes
            payload-printable: yes
            packet: yes
  - file:
      enabled: yes
      filename: /var/log/company/suricata.log

rule-reload:
  enabled: yes
  interval: 10

flow-timeouts:
  tcp:
    new: 30
    established: 300
    closed: 120
  udp:
    new: 30
    established: 180
  icmp:
    new: 0
    established: 0

stream:
  reassembly:
    depth: 0
    toserver-chunk-size: 2560
    toclient-chunk-size: 2560

Should the behavior be different? Should we try an official version?

4

The additional information requested is to help us understand the full picture. We have a template of sorts requesting contextual information. This often provides details that are needed to proceed.

5

Thanks. I just thought if this is perfect expected behavior I would guess the additional information is kinda obsolete :wink: