Actions
Bug #3179
closedhttp_header_names not generating alerts
Affected Versions:
Effort:
Difficulty:
Label:
Description
Original reported from Brandon Murphy - http_header_names seems to not generate an alert.
I did further investigation and it seems that in certain condition it can stop other rule from generating an alert.
Pcap can be privately shared.
sudo rm logs/* ; \ sudo /opt/suritest/bin/suricata -k none -S c66781e1f4b67de9/dalton-custom.rules -r c66781e1f4b67de9/765c2531b535858a57c824e7725c6918-0.pcap -l logs/ --runmode=single ; \ jq 'select (.event_type == "alert" ) | .alert.signature' logs/eve.json \ cat c66781e1f4b67de9/dalton-custom.rules [13507] 20/9/2019 -- 08:46:14 - (suricata.c:1075) <Notice> (LogVersion) -- This is Suricata version 5.0.0-dev (d4bc46038 2019-09-17) running in USER mode [13507] 20/9/2019 -- 08:46:14 - (tm-threads.c:2144) <Notice> (TmThreadWaitOnThreadInit) -- all 1 packet processing threads, 4 management threads initialized, engine started. [13507] 20/9/2019 -- 08:46:14 - (suricata.c:2881) <Notice> (SuricataMainLoop) -- Signal Received. Stopping engine. [13508] 20/9/2019 -- 08:46:14 - (source-pcap-file.c:373) <Notice> (ReceivePcapFileThreadExitStats) -- Pcap-file module read 1 files, 149 packets, 16887 bytes alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Test -1"; flow:established,to_server; content:"CONNECT"; http_method; content:"AutoIt"; http_user_agent; fast_pattern; content:"CONNECT api.telegram.org"; depth:24; content:"|20|HTTP/1.0|0d 0a|User-Agent"; distance:0; http_header_names; content:!"Referer"; classtype:trojan-activity; sid:1; rev:2;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Test -8"; flow:established,to_server; content:"CONNECT"; http_method; http_header_names; content:"|0d 0a|Host|0d 0a|"; classtype:trojan-activity; sid:8; rev:2;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Test -9"; flow:established,to_server; http_header_names; content:"|0d 0a|Host|0d 0a|"; classtype:trojan-activity; sid:9; rev:2;) # second run with the first rule disabled sudo rm logs/* ; \ sudo /opt/suritest/bin/suricata -k none -S c66781e1f4b67de9/dalton-custom.rules -r c66781e1f4b67de9/765c2531b535858a57c824e7725c6918-0.pcap -l logs/ --runmode=single ; \ jq 'select (.event_type == "alert" ) | .alert.signature' logs/eve.json \ cat c66781e1f4b67de9/dalton-custom.rules [13534] 20/9/2019 -- 08:46:21 - (suricata.c:1075) <Notice> (LogVersion) -- This is Suricata version 5.0.0-dev (d4bc46038 2019-09-17) running in USER mode [13534] 20/9/2019 -- 08:46:21 - (tm-threads.c:2144) <Notice> (TmThreadWaitOnThreadInit) -- all 1 packet processing threads, 4 management threads initialized, engine started. [13534] 20/9/2019 -- 08:46:21 - (suricata.c:2881) <Notice> (SuricataMainLoop) -- Signal Received. Stopping engine. [13535] 20/9/2019 -- 08:46:21 - (source-pcap-file.c:373) <Notice> (ReceivePcapFileThreadExitStats) -- Pcap-file module read 1 files, 149 packets, 16887 bytes # we get 20 alerts 10 Test -9 10 Test -8 #alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Test -1 "; flow:established,to_server; content:"CONNECT"; http_method; content:"AutoIt"; http_user_agent; fast_pattern; content:"CONNECT api.telegram.org"; depth:24; content:"|20|HTTP/1.0|0d 0a|User-Agent"; distance:0; http_header_names; content:!"Referer"; classtype:trojan-activity; sid:1; rev:2;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Test -8 "; flow:established,to_server; content:"CONNECT"; http_method; http_header_names; content:"|0d 0a|Host|0d 0a|"; classtype:trojan-activity; sid:8; rev:2;) alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Test -9"; flow:established,to_server; http_header_names; content:"|0d 0a|Host|0d 0a|"; classtype:trojan-activity; sid:9; rev:2;)
Updated by Victor Julien about 5 years ago
- Subject changed from http_header_names not genratting alerts to http_header_names not generating alerts
Updated by Andreas Herz about 5 years ago
- Assignee set to Peter Manev
- Target version set to TBD
Updated by Philippe Antoine 12 months ago
@Peter Manev is this still a problem with suricata 7 ?
Updated by Brandon Murphy 12 months ago
Based on my testing, it looks like this was solved in 6.0.0.
Running the rules against the pcap mentioned in the log with all 3 rules enabled results in 10 alerts in each rule.
5.0.0 results in 0 alerts produced when all rules are enabled.
It is my opinion this can be closed.
Actions