Project

General

Profile

Actions
Copy link

Bug #2017

closed

EVE Log Missing Fields

Added by Ryan Cote over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Victor Julien
Target version:
3.2.1
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

Download all 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
Copy link
 #1

Updated by Ryan Cote over 7 years ago

Issue is repeatable using afpacket as well.

Actions
Copy link
 #2

Updated by Eric Leblond over 7 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
Copy link
 #3

Updated by Ryan Cote over 7 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

Actions
Copy link Download all files
 #4

Updated by Ryan Cote over 7 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
Copy link
 #5

Updated by Ryan Cote over 7 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
Copy link
 #6

Updated by Ryan Cote over 7 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
Copy link
 #7

Updated by Victor Julien over 7 years ago

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

Actions
Copy link
 #8

Updated by Ryan Cote over 7 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
Copy link
 #9

Updated by Andreas Herz over 7 years ago

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

Can you share the .pcap with us?

Actions
Copy link
 #10

Updated by Ryan Cote over 7 years ago

Andreas Herz wrote:

Can you share the .pcap with us?

Forwarded via email.

Actions
Copy link
 #11

Updated by Victor Julien over 7 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
Copy link
 #12

Updated by Victor Julien over 7 years ago

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

Also available in: Atom PDF