[Oisf-users] meta-data crashes

Jeremy A. Grove jgrove at quadrantsec.com
Fri Nov 30 15:30:31 UTC 2018



Jeremy Grove, SSCP 
Security Engineer 
Quadrant Information Security 
o: [ callto:(904)296-9100 | (904)296-9100 ] x100 
t: [ callto:(800) 538-9357 | (800) 538-9357 ] x100 
e: [ mailto:soc at quadrantsec.com | soc at quadrantsec.com ] 

Learn more= about our managed SIEM [ https://a.quadrantsec.com/3D%22https://quadrantsec.com/SaganMSSP%22 | people + product ]

----- Original Message -----
From: "Peter Manev" <petermanev at gmail.com>
To: "Jeremy A. Grove" <jgrove at quadrantsec.com>
Cc: "oisf-users" <oisf-users at lists.openinfosecfoundation.org>
Sent: Thursday, November 29, 2018 4:49:36 PM
Subject: Re: [Oisf-users] meta-data crashes

> This is Suricata version 4.1.0 RELEASE
> Features: PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LIBJANSSON TLS MAGIC RUST
> 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 6.3.0 20170516, C version 199901
> compiled with _FORTIFY_SOURCE=0
> L1 cache line size (CLS)=64
> thread local storage method: __thread
> compiled with LibHTP v0.5.28, linked against LibHTP v0.5.25
>

This above seems a bit odd - "compiled with LibHTP v0.5.28, linked
against LibHTP v0.5.25"
4.1.0 should go with LibHTP 0.5.28 all the way , not linked against 0.5.25
Could you please update and redeploy and see if it makes a difference ?

The install process was linking to existing version of Libhtp so I removed all versions and let the install process reinstall. I will let this run and monitor for the issue.

This is Suricata version 4.1.0 RELEASE
Features: PCAP_SET_BUFF AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LIBJANSSON TLS MAGIC RUST 
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 6.3.0 20170516, C version 199901
compiled with _FORTIFY_SOURCE=0
L1 cache line size (CLS)=64
thread local storage method: __thread
compiled with LibHTP v0.5.28, linked against LibHTP v0.5.28



Is there anything specific to your set up in terms of how you have
Suricata running  - on a VM/docker/HW ? What speeds are you looking at
?

We have this issue in a variety of environments with different speeds. I am focusing on the 2 below.

Speeds and equipment per location:

Location A:
HP ProLiant DL160 Gen9
Dual -- Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz
32 GB Ram

5 1Gb Ethernet monitored port with high utilization on average. 

Location B:
HP ProLiant DL380 Gen9
Dual -- Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz  
32 GB Ram

2 10GB fiber and 1 1GB ethernet - one of the 10GB interfaces averages around 6GB per second. 

> Suricata Configuration:
>   AF_PACKET support:                       yes
>   eBPF support:                            no
>   XDP support:                             no
>   PF_RING support:                         no
>   NFQueue support:                         no
>   NFLOG support:                           no
>   IPFW support:                            no
>   Netmap support:                          no
>   DAG enabled:                             no
>   Napatech enabled:                        no
>   WinDivert enabled:                       no
>
>   Unix socket enabled:                     yes
>   Detection enabled:                       yes
>
>   Libmagic support:                        yes
>   libnss support:                          yes
>   libnspr support:                         yes
>   libjansson support:                      yes
>   liblzma support:                         no
>   hiredis support:                         no
>   hiredis async with libevent:             no
>   Prelude support:                         no
>   PCRE jit:                                yes
>   LUA support:                             no
>   libluajit:                               no
>   libgeoip:                                no
>   Non-bundled htp:                         no
>   Old barnyard2 support:                   no
>   Hyperscan support:                       yes
>   Libnet support:                          yes
>   liblz4 support:                          yes
>
>   Rust support:                            yes (default)
>   Rust strict mode:                        no
>   Rust debug mode:                         no
>   Rust compiler:                           rustc 1.30.0 (da5f414c2 2018-10-24)
>   Rust cargo:                              cargo 1.30.0 (36d96825d 2018-10-24)
>
>   Suricatasc install:                      yes
>
>   Profiling enabled:                       no
>   Profiling locks enabled:                 no
>
> Development settings:
>   Coccinelle / spatch:                     no
>   Unit tests enabled:                      no
>   Debug output enabled:                    no
>   Debug validation enabled:                no
>
> Generic build parameters:
>   Installation prefix:                     /usr
>   Configuration directory:                 /etc/suricata/
>   Log directory:                           /var/log/suricata/
>
>   --prefix                                 /usr
>   --sysconfdir                             /etc
>   --localstatedir                          /var
>
>   Host:                                    x86_64-pc-linux-gnu
>   Compiler:                                gcc (exec name) / gcc (real)
>   GCC Protect enabled:                     no
>   GCC march native enabled:                yes
>   GCC Profile enabled:                     no
>   Position Independent Executable enabled: no
>   CFLAGS                                   -g -O2 -march=native -I${srcdir}/../rust/gen/c-headers
>   PCAP_CFLAGS                               -I/usr/include
>   SECCFLAGS



-- 
Regards,
Peter Manev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2131 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181130/66cc28bd/attachment.bin>


More information about the Oisf-users mailing list