What does this log mean? Can it mean my IPS working properly?
------------------------------------------------------------------------------------
Counter | TM Name | Value
------------------------------------------------------------------------------------
decoder.pkts | Total | 15309
decoder.bytes | Total | 16231733
decoder.ipv4 | Total | 15309
decoder.tcp | Total | 14767
decoder.udp | Total | 520
decoder.icmpv4 | Total | 22
decoder.avg_pkt_size | Total | 1060
decoder.max_pkt_size | Total | 1400
flow.tcp | Total | 26
flow.udp | Total | 318
tcp.sessions | Total | 25
tcp.syn | Total | 26
tcp.synack | Total | 1
tcp.rst | Total | 4
app_layer.flow.http | Total | 1
app_layer.tx.http | Total | 1
app_layer.flow.failed_udp | Total | 318
ips.accepted | Total | 15308
flow_mgr.new_pruned | Total | 79
flow.spare | Total | 10010
flow_mgr.flows_checked | Total | 22
flow_mgr.flows_notimeout | Total | 15
flow_mgr.flows_timeout | Total | 7
flow_mgr.flows_removed | Total | 7
flow_mgr.rows_checked | Total | 65536
flow_mgr.rows_skipped | Total | 65502
flow_mgr.rows_empty | Total | 13
flow_mgr.rows_maxlen | Total | 2
tcp.memuse | Total | 2293760
tcp.reassembly_memuse | Total | 397312
http.memuse | Total | 96
flow.memuse | Total | 7553024
These rules are generated from datasets outside of ET those, for example, the ET DROP Dshield block list has this description:
Dshield Top Attackers This ruleset takes a daily list of the top attackers reported to Dshield and converts them into Snort signatures…
So you should look into the DShield project to learn more. I’ve seen l legitimate traffic trigger these, such as NTP, and other stuff. So they are indicators, but how actionable they are depends on you and your risk profile.
It did detect, not block, those events (doesn’t have to be an attack). This is only possible if you run it in IPS mode and have converted the alert rules to drop.
Thank you.
Consider “app-layer-events.rules” file. Its content is:
# App layer event rules
#
# SID's fall in the 2260000+ range. See http://doc.emergingthreats.net/bin/view/Main/SidAllocation
#
# These sigs fire at most once per connection.
#
# A flowint applayer.anomaly.count is incremented for each match. By default it will be 0.
#
alert ip any any -> any any (msg:"SURICATA Applayer Mismatch protocol both directions"; flow:established; app-layer-event:applayer_mismatch_protocol_both_directions; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260000; rev:1;)
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;)
alert ip any any -> any any (msg:"SURICATA Applayer Detect protocol only one direction"; flow:established; app-layer-event:applayer_detect_protocol_only_one_direction; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260002; rev:1;)
alert ip any any -> any any (msg:"SURICATA Applayer Protocol detection skipped"; flow:established; app-layer-event:applayer_proto_detection_skipped; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260003; rev:1;)
# alert if STARTTLS was not followed by actual SSL/TLS
alert tcp any any -> any any (msg:"SURICATA Applayer No TLS after STARTTLS"; flow:established; app-layer-event:applayer_no_tls_after_starttls; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260004; rev:2;)
# unexpected protocol in protocol upgrade
alert tcp any any -> any any (msg:"SURICATA Applayer Unexpected protocol"; flow:established; app-layer-event:applayer_unexpected_protocol; flowint:applayer.anomaly.count,+,1; classtype:protocol-command-decode; sid:2260005; rev:1;)
#next sid is 2260006
If I change all “alert” to “drop” then it will be OK?
Can I use “Find and Replace” feature in an Editor for doing it? Some rules are long and
has been messed up.
Make sure there are no unintended changes to the rules – note that Suricata will not load rules with syntax or structural issues – suricata.log (and the console, if available) will contain information about rules that couldn’t be loaded.
If you want to test specific attacks you should pick those rules that would match on those. If you want to test just running it overall you should include the default set provided by ET or start with a run for each file.