[Snort-users] help with flow:established

Al Lewis (allewi) allewi at ...589...
Mon Jan 9 10:15:47 EST 2017


That sounds like correct behavior. If one of the packets needed to establish the session has a bad checksum it is ignored (if you don’t have the -k none added when running snort).


Albert Lewis
ENGINEER.SOFTWARE ENGINEERING
SOURCEfire, Inc. now part of Cisco
Email: allewi at ...589... 







On 1/9/17, 9:55 AM, "Felix Erlacher" <felix.erlacher at ...17726...> wrote:

>Hi all,
>
>I encountered a strange behavior in snort 2.9.9.0
>I wanted to trigger rule with sid:2010054 from the current
>emerging-threat ruleset (emerging-all.rules)[1].
>I created a very simple traffic dump with an ARP request/response, TCP 3
>way handshake and a HTTP GET request containing the content the rule is
>looking for, and a 404 answer from my http server.
>If I run snort with only this rule no alarm is triggered.
>Now, if I remove the option "established" from the "flow:" keyword,
>leaving only "flow:to_server" left in the rule than snort triggers an
>alarm for this rule.
>There is only one thing that imho could be blamed for this behavior: the
>second segment in the tcp 3whs coming from the server has a wrong tcp
>checksum.
>Is it possible that the preprocessor (and thus snort) does not consider
>a TCP connection "established" if there is checksum error in the 3whs?
>
>[1] alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN
>Likely TDSS Download (codec.exe)"; flow:established,to_server;
>content:"GET"; nocase; http_method; content:"/codec.exe"; nocase;
>http_uri; reference:url,doc.emergingthreats.net/2010054;
>classtype:trojan-activity; sid:2010054; rev:6;)
>
>-- 
>Felix Erlacher
>
>Key-ID:4EAC0959
>


More information about the Snort-users mailing list