[Oisf-users] Possible bug with flow tracking engine via config or design

[Hovsep Levi]

Based on the lack of posting to the mailing list I assume this is a decent
bug.  I thought so too.

On Fri, Sep 9, 2016 at 9:20 PM, Hovsep Levi <hovsep.sanjay.levi at gmail.com>
wrote:

> Hello,
>
>
> We recently experienced a DoS attack leaving our network that erroneously
> triggered the 2020381 signature for a number of spoofed IPs, 238 in total.
> In review it seems the signature should not have fired and suggests a
> possible bug in the flow tracking engine by config limits or design.
>
>
> The DoS attack was a TCP SYN flood attack with packet size varying between
> 1010 and 1042 and either the SYN flag, SYN+ECE. or SYN+CWR flags set.
> There was no three-way handshake with the target at any time.  Source ports
> were randomized.
>
>
> Signature, notice the "established" keyword:
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN DDoS.XOR
> Checkin"; flow:to_server,established; content:"BB2FA36AAA9541F0";
> depth:500; reference:url,blog.malwaremustdie.org/2014/09/
> mmd-0028-2014-fuzzy-reversing-new-china.html; classtype:trojan-activity;
> sid:2020381; rev:3;)
>
>
>
> Here are the netflows for a specific TCP flow (randomized IPs).  The
> flows are #13 and #43 of 287 sent to the target.
>
> TCP 212.212.141.142:14717 -> 10.229.52.48:8300
>
> sIP| dIP|sPort|dPort|pro| packets| bytes| flags| sTime|
> 212.212.141.142| 10.229.52.48|14717| 8300| 6| 1| 1034| S E
> |2016/09/08T09:09:19.994|
> 212.212.141.142| 10.229.52.48|14717| 8300| 6| 1| 1034| S E
> |2016/09/08T09:09:45.993|
>
>
>
> Here is the Suricata event which fired on flow #43:
>
> "rulesid": "2020381",
> "rulerev": "3",
> "classification": "A Network Trojan was Detected",
> "suri_priority": "1",
> "proto": "TCP",
> "orig_h": "212.212.141.142",
> "orig_p": "14717",
> "resp_h": "10.229.52.48",
> "resp_p": "8300",
> "event_timestamp": "2016-09-08T09:09:45.991Z",
> "rule": "1:2020381:3 -- ET TROJAN DDoS.XOR Checkin ",
>
>
> Unfortunately file logging was not enabled so there's no suricata.log file
> to check for emergency mode conditions.  These sensors have plenty of
> memory available so I think it's caused by config limits and/or something
> with the flow engine.
>
> Maybe someone with better knowledge can provide ideas as to why a
> non-established flow triggered a signature with the established keyword.
>
>
>
> Regards,
>
> Hovsep
>
>
>
>
> suricata.yaml
>
>
> flow:
> memcap: 24gb
> hash-size: 262144
> prealloc: 200000
> emergency-recovery: 30
>
>
> flow-timeouts:
>
> default:
> new: 30
> established: 120
> closed: 0
> emergency-new: 10
> emergency-established: 60
> emergency-closed: 0
> tcp:
> new: 60
> established: 120
> closed: 120
> emergency-new: 10
> emergency-established: 60
> emergency-closed: 20
> udp:
> new: 30
> established: 120
> emergency-new: 10
> emergency-established: 60
> icmp:
> new: 30
> established: 120
> emergency-new: 10
> emergency-established: 60
>
>
> stream:
> memcap: 32gb
> checksum-validation: yes # reject wrong csums
> inline: no # auto will use inline mode in IPS mode, yes or no set it
> statically
> reassembly:
> memcap: 16gb
>   depth: 6mb # reassemble 6mb into a stream
> toserver-chunk-size: 2560
> toclient-chunk-size: 2560
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160912/b0842626/attachment-0002.html>