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 over 5 years ago
- Subject changed from http_header_names not genratting alerts to http_header_names not generating alerts
Updated by Andreas Herz over 5 years ago
- Assignee set to Peter Manev
- Target version set to TBD
Updated by Philippe Antoine about 1 year ago
@Peter Manev is this still a problem with suricata 7 ?
Updated by Brandon Murphy about 1 year 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