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