[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).
SOURCEfire, Inc. now part of Cisco
Email: allewi at ...589...
On 1/9/17, 9:55 AM, "Felix Erlacher" <felix.erlacher at ...17726...> wrote:
>I encountered a strange behavior in snort 126.96.36.199
>I wanted to trigger rule with sid:2010054 from the current
>emerging-threat ruleset (emerging-all.rules).
>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
>Is it possible that the preprocessor (and thus snort) does not consider
>a TCP connection "established" if there is checksum error in the 3whs?
> 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;
>classtype:trojan-activity; sid:2010054; rev:6;)
More information about the Snort-users