We are currently running suricata 4.1.10 and have loaded 3 rule sets.
ruleset 1 → tls-events.rules
ruleset 2 → app-layer-events.rules
ruleset 3 → customer_exceptions.rules
in the custom exception rules, we have the following rule: pass tcp $PROXY_SERVERS [1024:] <> any 443 (msg:"pass all traffic from proxy to https endpoints"; sid:9000018;)
in our suricata.yaml we have this address-group: PROXY_SERVERS: "[10.9.48.0/22, 10.10.48.0/22, 10.11.48.0/22]"
but we are still getting alerts for:
src_ip 52.95.120.61
src_port 443
dest_ip 10.10.48.127
dest_port 43854
proto TCP
metadata
flowints :
Unknown macro: {‘applayer’}
alert
action : allowed
gid : 1
signature_id : 2260001
rev : 1
signature : SURICATA Applayer Wrong direction first Data
category : Generic Protocol Command Decode
severity : 3
app_proto failed
app_proto_ts tls
Is there any way to debug why our pass rule is not being used?
first of all I would suggest to update to a supported version 5 or 6. In addition to that, try a dedicated pass rule for each direction, to see if those would work instead of the <> one.
pass tcp $PROXY_SERVERS [1024:] -> any 443 (msg:"pass all traffic from proxy to https endpoints"; sid:9000027; rev:1;)
pass tcp any 443 -> $PROXY_SERVERS [1024:] (msg:"pass return traffic from https endpoints t proxy"; sid:9000028; rev:1;)
pass tls $PROXY_SERVERS [1024:] -> any 443 (msg:"pass all traffic fro proxy to https endpoints"; sid:9000029; rev:1;)
pass tls any 443 -> $PROXY_SERVERS [1024:] (msg:"pass return traffic from https endpoints to proxy"; sid:9000030; rev:1;)
But still, this alert triggers: {"timestamp":"2021-04-22T06:20:02.424616+0000","flow_id":704250444397769,"in_iface":"ens5","event_type":"alert","src_ip":"10.10.48.238","src_port":50586,"dest_ip":"176.32.109.195","dest_port":443,"proto":"TCP","metadata":{"flowints":{"applayer.anomaly.count":1}},"alert":{"action":"allowed","gid":1,"signature_id":2260001,"rev":1,"signature":"SURICATA Applayer Wrong direction first Data","category":"Generic Protocol Command Decode","severity":3},"app_proto":"failed","app_proto_tc":"tls","flow":{"pkts_toserver":3,"pkts_toclient":4,"bytes_toserver":174,"bytes_toclient":324,"start":"2021-04-22T06:20:02.408777+0000"}}
which is:
alert ip any any -> any any (msg:"SURICATA Applayer Wrong direction first Data"; flow:established; app-layer-event:applayer_wrong_direction_first_data; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260001; rev:1;)
There are some things you can try to narrow it down:
change the pass to alert rules and see if they trigger at all
If they do, change those back and add another alert that is not using app-layer-event but that should still trigger. For example the same rule as alert instead of pass with a different sid.
Can you provide a pcap that reproduces that issue? that would make it easier to test and match your scenario
I’m very new to Suricata 6.0.4 with a fresh install on Ubuntu 20.04.
I’m trying to implement my first *pass**rule and I still get anomaly events in eve.json.
pass tcp any any <> 172.17.2.206 80 (msg:"SCCM Client to server traffic"; sid:900001; rev:1; )
It looks like the anomaly detection rule generates the first event and then my custom alert rule the second event.
How does the rule processing work?
Shouldn’t the more specific rule (with a specified target IP for example) be the only match?
Sorry for my noob.questions
Anomaly events are not alerts. They’re generated when something unexpected occurs. The Suricata configuration file suricata.yaml contains a description of what they are and when they’re generated.
