ET Rule 2003927 not matchin in suricata
I have the following rule (from ET) included in my suricata.yaml:
drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Suspicious User-Agent (HTTPTEST) - Seen used by downloaders"; flow:to_server,established; content:"User-Agent|3a| HTTPTEST"; nocase; http_header; threshold: type limit, count 2, track by_src, seconds 300;reference:url,doc.emergingthreats.net/bin/view/Main/2003927; classtype:trojan-activity; sid:2003927; rev:9;)
This rule is detected by snort but not by suricata 2.0.3 when i use the following command:
exec 80<>/dev/tcp/10.0.13.134/80 && ( echo -e 'GET / HTTP/1.0\r\nUser-Agent: Autotest httpRequest\r\nUser-Agent: HTTPTEST\r\n\r\n' >&80; while read -t 10 <&80; do echo $REPLY; done; exec 80<&- 80>&- )
It's working as soon as i remove the first User-Agent. But IMHO the rule should even match with the additional User-Agent in front of the HTTPTEST.
Victor said it could be that it's rejected in an earlier stage, but that means such traffic could go through although i wanted to drop it.
Updated by Victor Julien about 5 years ago
Looks like libhtp does this unconditionally: https://github.com/ironbee/libhtp/blob/0.5.15/htp/htp_request_generic.c#L66
Updated by Philippe Antoine 19 days ago
Well, I see this as about Suricata rule keywords
The rule triggers when we use
http_raw_header instead of
The rule does not trigger with
http_header keyword because there is a normalization step first
That normalization includes concatenating together the different values for a single header (This is done by libhtp).
That is transforming
User-Agent: Autotest httpRequest
User-Agent: Autotest httpRequest, HTTPTEST
Maybe the best solution would be to have some keywords
value that we could use with
Updated by Victor Julien 7 days ago
I think the normalization is not working in our advantage. I think we should disable the normalization and instead consider this buffer to have 1-N values, instead of just a single one.
This will be quite involved, as it would first require libhtp changes to store this correctly somehow, then in suri we would need to iterate over the 1-N values in detection and logging. The logging (in eve) means we need to change it from scalar to array probably.