Project

General

Profile

Actions

Bug #2017

closed

EVE Log Missing Fields

Added by Ryan Cote almost 8 years ago. Updated almost 8 years ago.

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

Description

A sanitized testing version has the signature below:

alert ip [192.168.1.1,192.168.1.2] any -> ![192.168.1.0/24,192.168.2.0/24] any (msg:"Testing missing field alert"; sid:999999; rev:1;)

Which constantly repeats this output output:

{"timestamp":"2017-02-03T20:56:28.449174+0000","alert": {"action":"allowed","gid":1,"signature_id":999999,"rev":1,"signature":"Testing missing field alert","category":"","severity":3}}

The capture method is PFRING and the EVE Output configuration is below:

- eve-log:
enabled: yes
filetype: regular
filename: eve.json
types:
- alert:
payload-printable: yes
payload: yes
http: yes
tls: yes
ssh: yes
smtp: yes

I can run a more thorough sanitized test as more information is required


Files

suricata.yaml (62.4 KB) suricata.yaml Ryan Cote, 02/03/2017 09:29 PM
alert.json (3.39 KB) alert.json Ryan Cote, 02/03/2017 09:29 PM
suri_timestamp.PNG (92.6 KB) suri_timestamp.PNG Ryan Cote, 02/03/2017 10:33 PM
Actions #1

Updated by Ryan Cote almost 8 years ago

Issue is repeatable using afpacket as well.

Actions #2

Updated by Eric Leblond almost 8 years ago

Ryan Cote wrote:

Issue is repeatable using afpacket as well.

I'm not sure I understand the problem I've updated one of the IP to match my setup and I've got the following alerts after a ping:

{"timestamp":"2017-02-04T00:32:05.852737+0100","in_iface":"wlan0","event_type":"alert","src_ip":"192.168.0.110","dest_ip":"1.2.3.4","proto":"ICMP","icmp_type":8,"icmp_code":0,"alert":{"action":"allowed","gid":1,"signature_id":999999,"rev":1,"signature":"Testing missing field alert","category":"","severity":3}}

What suricata version are you using by the way ?

Actions #3

Updated by Ryan Cote almost 8 years ago

Version 3.2, and no matching IPs in the left side of the signature are seen in the traffic flow, but I get a constant flow of alerts with no source or dest

Updated by Ryan Cote almost 8 years ago

A different environment, one I can share more details about, Ubuntu 16.04 running on an odroid XU4. suricata.yaml and eve alerts output attached. I can share flow logs and pcap through different channels.

Command Line Options: suricata -c suricata.yaml --af-packet -S testing.rules

Build options:

This is Suricata version 3.2 RELEASE
Features: NFQ PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LUA HAVE_LUAJIT HAVE_LIBJANSSON TLS
SIMD support: none
Atomic intrisics: 1 2 4 8 byte(s)
32-bits, Little-endian architecture
GCC version 5.4.0 20160609, C version 199901
compiled with _FORTIFY_SOURCE=2
L1 cache line size (CLS)=64
thread local storage method: __thread
compiled with LibHTP v0.5.23, linked against LibHTP v0.5.23

Suricata Configuration:
AF_PACKET support: yes
PF_RING support: no
NFQueue support: yes
NFLOG support: no
IPFW support: no
Netmap support: no
DAG enabled: no
Napatech enabled: no

Unix socket enabled:                     yes
Detection enabled: yes
libnss support:                          yes
libnspr support: yes
libjansson support: yes
hiredis support: no
Prelude support: no
PCRE jit: yes
LUA support: yes, through luajit
libluajit: yes
libgeoip: no
Non-bundled htp: no
Old barnyard2 support: no
CUDA enabled: no
Hyperscan support: no
Libnet support: yes
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:                                    armv7l-unknown-linux-gnueabihf
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
PCAP_CFLAGS -I/usr/include
SECCFLAGS
Actions #5

Updated by Ryan Cote almost 8 years ago

Something odd is going on with the timestamp within the output generated as well. I ran it again to see if it was a system problem, but it doesn't appear to be.

Actions #6

Updated by Ryan Cote almost 8 years ago

Ryan Cote wrote:

Version 3.2, and no matching IPs in the left side of the signature are seen in the traffic flow, but I get a constant flow of alerts with no source or dest

To clarify on the problem, this rule should not fire based on the traffic flow, but I have a constant stream of alerts with no source or destination information when it is enabled.

Actions #7

Updated by Victor Julien almost 8 years ago

Are you able to reproduce with a pcap recording of your traffic?

Actions #8

Updated by Ryan Cote almost 8 years ago

Yes, the missing field problems is present reading through PCAP. I have 10 events without src/dest fields and one properly formatted event.

root@odroid:~# capinfos /opt/pcap/1486226413.pcap
File name: /opt/pcap/1486226413.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Number of packets: 168
File size: 24 kB
Data size: 21 kB
Capture duration: 57.486052 seconds
First packet time: 2017-02-04 16:40:14.383176
Last packet time: 2017-02-04 16:41:11.869228
Data byte rate: 371 bytes/s
Data bit rate: 2970 bits/s
Average packet size: 127.07 bytes
Average packet rate: 2 packets/s
SHA1: 76901959a3659f157b37708d14fea28b65655d89
RIPEMD160: 86b04f185c75c6c98429ecac923b2e8c363f66c7
MD5: b048987ad9376227d3456e2db9f599ae
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Name = UNKNOWN
Description = NONE
Encapsulation = Ethernet (1/1 - ether)
Speed = 0
Capture length = 65535
FCS length = -1
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Filter string = NONE
Operating system = UNKNOWN
Comment = NONE
BPF filter length = 0
Number of stat entries = 0
Number of packets = 168

Actions #9

Updated by Andreas Herz almost 8 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD

Can you share the .pcap with us?

Actions #10

Updated by Ryan Cote almost 8 years ago

Andreas Herz wrote:

Can you share the .pcap with us?

Forwarded via email.

Actions #11

Updated by Victor Julien almost 8 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Victor Julien
  • Target version changed from TBD to 70

I can reproduce the issue with your pcap, having a look.

Actions #12

Updated by Victor Julien almost 8 years ago

  • Status changed from Assigned to Closed
  • Target version changed from 70 to 3.2.1
Actions

Also available in: Atom PDF