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

[Peter Manev]

On Fri, Sep 9, 2016 at 11: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.

It could also be misconfiguration or a bug indeed.


>
> Maybe someone with better knowledge can provide ideas as to why a
> non-established flow triggered a signature with the established keyword.
>

You are welcome to post  a bug report here -
https://redmine.openinfosecfoundation.org/projects/suricata/issues. It
will also be easier to track and follow.

Before we can pinpoint the reason for this though we would need some
more info to investigate or give us some direction (especially for
fixing it).
If possible please include info that would be useful and can help for
that particular scenario :
- Suricata version
- OS type/version/kernel
- high level HW set up - cpu/ram/nic (is there any other high CPU/mem
utilization app on the server or is it just Suri? )
- average traffic speed
- Suricata run/start command
- relevant sections of the config ( some you posted but some are
missing -like home/ext nets/capture method - aka
afpacket/pfring/netmap.. sections)
- suricata.log (verbose output) - you would be able to see right away
if the flow engine is overloaded since you should have plenty of msgs
if emergency mode has kicked in.
- relevant stats.log section - when it occurred. You would be able to
see any memcaps reached/gaps present/emergency mode/packet/engine
stats and more
- how do you correlate the suricata alert (posted above) with the one
packet flow (posted above - #43)
- the Suricata alert event itself  - from eve.json (if you are using it)

it is indeed strange if the alert fires on one packet with S/E flags.


>
>
> Regards,
>
> Hovsep
>
>
>
>
> suricata.yaml
>
>
> flow:
> memcap: 24gb
> hash-size: 262144
> prealloc: 200000
> emergency-recovery: 30
>

This is a huge flow memcap setting - is there a specific reason for that?
Stats.log would be helpful as well to give you a better idea of what
is happening.

Also during normal(or peak traffic) you can use - top -H -p `pid of
suricata` - what you would want to look at is FM and FR threads and
how busy they are. I think you are using the defaults (or have not
updated your suri/config ) so that would be 1 and 1 (for 3.1.2
-https://redmine.openinfosecfoundation.org/projects/suricata/repository/entry/suricata.yaml.in?utf8=%E2%9C%93&rev=suricata-3.1.2#L1033
)


>
> 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
>
>

Thanks


-- 
Regards,
Peter Manev