Project

General

Profile

Actions

Bug #1193

closed

Rule-Thresholding not working at high packet rates

Added by Tim Taylor almost 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

I don't know if this is a bug, if not maybe someone can point me in the right direction. :)

The problem is:

Seems that Rule-Thresholding is not working at high packet rates.

Test-Setup:

Host1 (192.168.100.10) --- IDS-Host (bridged, suricata 2.0 with pf_ring) --- Host2 (192.168.100.20)

Suricata Buildinfo:
@
This is Suricata version 2.0 RELEASE
Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 PF_RING AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG HAVE_HTP_URI_NORMALIZE_HOOK
SIMD support: SSE_4_2 SSE_4_1 SSE_3
Atomic intrisics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 4.4.7 20120313 (Red Hat 4.4.7-4), C version 199901
L1 cache line size (CLS)=64
compiled with LibHTP v0.5.10, linked against LibHTP v0.5.10
Suricata Configuration:
AF_PACKET support: yes
PF_RING support: yes
NFQueue support: no
IPFW support: no
DAG enabled: no
Napatech enabled: no
Unix socket enabled: no
Detection enabled: yes

libnss support:                          no
libnspr support: no
libjansson support: no
Prelude support: no
PCRE jit: no
libluajit: no
libgeoip: yes
Non-bundled htp: no
Old barnyard2 support: no
CUDA enabled: no
Suricatasc install:                      yes
Unit tests enabled:                      no
Debug output enabled: no
Debug validation enabled: no
Profiling enabled: no
Profiling locks enabled: no
Coccinelle / spatch: no

Generic build parameters:
Installation prefix (--prefix): /usr/local
Configuration directory (--sysconfdir): /usr/local/etc/suricata/
Log directory (--localstatedir) : /usr/local/var/log/suricata/

Host:                                    x86_64-unknown-linux-gnu
GCC binary: gcc
GCC Protect enabled: no
GCC march native enabled: yes
GCC Profile enabled: no

@

My test rule looks like this:


alert udp any any -> any any (msg:"UDP-test 2"; threshold: type both, track by_dst, count 1000, seconds 10; sid:100006;rev:1;)

When i run the following command:


hping3 -V -w 64 -p 80 -s 445 --rand-source 192.168.100.10 -2 -i u1000

Everything works as expected:


05/16/2014-13:30:54.631028 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 84.117.0.233:1442 -> 192.168.100.10:80
05/16/2014-13:31:04.003001 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 53.227.238.67:10374 -> 192.168.100.10:80
05/16/2014-13:31:14.007863 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 205.227.181.56:19908 -> 192.168.100.10:80
05/16/2014-13:31:24.028645 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 183.84.70.175:29458 -> 192.168.100.10:80
05/16/2014-13:31:34.008999 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 1.24.12.252:38971 -> 192.168.100.10:80

When i reduce the time between the packets via "-i u1" with hping the udp-packetrate goes up to ~100kpps everyhting works fine as before but i get flooded with
alerts:


05/16/2014-13:44:44.483682 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 29.93.248.204:16708 -> 192.168.100.10:80
05/16/2014-13:44:45.850753 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 156.213.70.21:11837 -> 192.168.100.10:80
05/16/2014-13:44:46.909633 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 19.98.151.248:13138 -> 192.168.100.10:80
05/16/2014-13:44:48.337742 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 234.83.133.38:10070 -> 192.168.100.10:80
05/16/2014-13:44:49.815976 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 181.14.83.0:24158 -> 192.168.100.10:80
05/16/2014-13:44:51.155775 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 51.153.193.247:19103 -> 192.168.100.10:80
05/16/2014-13:44:51.973204 [**] [1:100006:1] UDP-test 2 [**] [Classification: (null)] [Priority: 3] {UDP} 131.58.124.188:39649 -> 192.168.100.10:80

I tried with different protocols and ip-only rules but what i get is always the same: Many many alerts.

Thanks!

Actions #1

Updated by Andreas Herz over 9 years ago

Since the "threshold" option is deprecated, you could try to convert it to a detection_filter rule and test it with that.
I also had some issues with that, see: https://redmine.openinfosecfoundation.org/issues/1243

Actions #2

Updated by Andreas Herz about 8 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #3

Updated by Andreas Herz almost 7 years ago

  • Status changed from New to Closed

Closed (no response after 1y)

Actions #4

Updated by Victor Julien over 6 years ago

  • Target version deleted (TBD)
Actions

Also available in: Atom PDF