Except trusted IP

I wrote a pass rule as follows in order not to generate an alert related to a trusted IP, but the alert continues without being passed.
Could I have written the rule incorrectly?

pass ip xx.xx.0.0/16 any → yy.yy.yy.yy any (msg:“any”; sid:1900342; gid:1100001;)

Are you really only interested in not alerting from xx.xx.0.0/16 to yy.yy.yy.yy but alerting on traffic from yy.yy.yy.yy to xx.xx.0.0/16?

Would pass ip xx.xx.0.0/16 any <> yy.yy.yy.yy any ([...] work better for you?
If not, then sharing the rule that triggeres and specifying which direction triggers on would help trace the problem further.

I am testing using 2 passing rules

pass tcp xx.xx.0.0/16 10000 → yy.yy.yy.yy any (msg:“tcp-any”; sid:1900342; gid:1100001;)
pass ip xx.xx.0.0/16 any <> yy.yy.yy.yy any (msg:“any”; sid:1900358; gid:1100001;)

However, the alert still occurs as shown below

{“event_type”:“alert”,“direction”:“egress”,“alert”:{“category”:“user”,“signature”:“test_signature”,“action”:“allowed”,“gid”:1000001,“rev”:1,“severity”:2,“signature_id”:1100355},"@proto":“TCP”,"@src_port":10000,“timestamp”:“2021-02-05T05:02:48.317Z”,“timestamp”:“2021-02-05T14:02:47.989724+0900”,“version”:“1”,“payload_printable”:“xxxxxxxxxxx”,“dest_port”:1077,“flow_id”:923119891547874,“host”:“abc”,“flow”:{“pkts_toserver”:36581402,“bytes_toclient”:385304584,“start”:“2021-02-02T09:13:44.886498+0900”,“pkts_toclient”:5480938,“bytes_toserver”:51082104518},“packet_info”:{“linktype”:1},"@src_ip":“xx.xx.246.190”,“stream”:0,"@dest_ip":“yy.yy.yy.yy”}

The action-order is as follows:

action-order:
-pass
-drop
-reject
-alert

Could the order of the rule file list also affect?

rule-files:
-alert.rules
-pass.rules

Can you post more details about your setup and configuration?

The two pass rules I have posted are written in the pass.rules file, and the detected test_signature rules are written in alert.rules. There are many rules in alert.rules, and there are many other alerts in addition to test_signature.

The action-order in suricata.yaml is the same as above, and I inquired about the only reason I’m guessing is related to the order of rule-files in the suricata.yaml

I seem to have sufficiently posted the settings related to the pass rule, but could you tell me what settings or explanations you need, so I can post them?

Do you have some setup that can reproduce this issue?
For example pcap + config + rulefile.

suricata_config.yaml (10.5 KB)
test_signature_pcap.zip (818 Bytes)
pass.rules (159 Bytes)
alert.rules (137 Bytes)

Please note that only the rule file and the IP part of the packet have been changed.

Thanks! I’m having some trouble replaying the pcap.

[root@2c39d228331d suri] suricata -c suricata.yaml -l logs/ -r test_signature.pcap 
23/2/2021 -- 20:12:36 - <Notice> - This is Suricata version 6.0.0 RELEASE running in USER mode
23/2/2021 -- 20:12:36 - <Error> - [ERRCODE: SC_ERR_FOPEN(44)] - unsupported pcap savefile version 1026.0
23/2/2021 -- 20:12:36 - <Warning> - [ERRCODE: SC_ERR_PCAP_DISPATCH(20)] - Failed to init pcap file test_signature.pcap, skipping
23/2/2021 -- 20:12:36 - <Notice> - all 9 packet processing threads, 6 management threads initialized, engine started.
23/2/2021 -- 20:12:36 - <Error> - [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - pcap file reader thread failed to initialize
23/2/2021 -- 20:12:36 - <Notice> - Signal Received.  Stopping engine. 
[root@2c39d228331d suri] tcpdump -n -r test_signature.pcap 
tcpdump: unsupported pcap savefile version 1026.0

In my case there was no problem. How about checking the version?

# tcpdump -n -r test_signature.acp
    reading from file test_signature.acp, link-type EN10MB (Ethernet)
    09:00:00.000000 IP 1.1.1.1.37175 > 2.2.2.2.5180: Flags [.], seq 1644606715:1644608063, ack 1314311174, win 221, options [nop,nop,TS val 803496242 ecr 2933921374], length 1348

I’m using :

libpcap-1.5.3-8.el7.x86_64
tcpdump-4.5.1-3.el7.x86_64

Localhost

tcpdump --version
tcpdump version 4.9.3
libpcap version 1.9.1 (with TPACKET_V3)
OpenSSL 1.1.1f  31 Mar 2020

ldd /usr/sbin/tcpdump 
	linux-vdso.so.1 (0x00007ffd30db7000)
	libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f0ef7a55000)
	libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f0ef7a0a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0ef7818000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0ef7812000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0ef77ef000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f0ef7fa9000)

md5sum test_signature.acp 
e1b0ebd79f0f4120f9f60f0371eacb6c  test_signature.acp

Docker container

[root@2c39d228331d suri] tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
OpenSSL 1.1.1c FIPS  28 May 2019

[root@2c39d228331d suri] ldd /usr/sbin/tcpdump 
	linux-vdso.so.1 (0x00007ffef95be000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f9195d41000)
	libpcap.so.1 => /lib64/libpcap.so.1 (0x00007f9195afb000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f9195739000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f9195522000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f919531e000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f91950fe000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f919669d000)

I tried editing the pcap header to be version 2.4 (seems standard) but then tcpdump throws some other error. Not really sure what’s going on if you have the same md5 on your file.

[root@2c39d228331d suri]# file test_signature.pcap  
test_signature.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
[root@2c39d228331d suri]# tcpdump -n -r test_signature.pcap 
reading from file test_signature.pcap, link-type EN10MB (Ethernet)
00:00:00.000000 IP 1.1.1.1.37175 > 2.2.2.2.5180: Flags [.], seq 1644606715:1644608063, ack 1314311174, win 221, options [nop,nop,TS val 803496242 ecr 2933921374], length 1348
tcpdump: pcap_loop: truncated dump file; tried to read 16 header bytes, only got 1

In my case the error did not occur as follows.
Also, when I installed and tested tcpdump 4.9.2, I didn’t get any errors too.

   # md5sum test_signature.acp
    e1b0ebd79f0f4120f9f60f0371eacb6c  test_signature.acp

    # file test_signature.acp
    test_signature.acp: tcpdump capture file (little-endian) - version 1026.0 (Ethernet, capture length 65535)

    # tcpdump -n -r test_signature.acp
    reading from file test_signature.acp, link-type EN10MB (Ethernet)
    09:00:00.000000 IP 1.1.1.1.37175 > 2.2.2.2.5180: Flags [.], seq 1644606715:1644608063, ack 1314311174, win 221, options [nop,nop,TS val 803496242 ecr 2933921374], length 1348