Bug #2017
closedEVE Log Missing Fields
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
Updated by Ryan Cote almost 8 years ago
Issue is repeatable using afpacket as well.
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 ?
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
- File suricata.yaml suricata.yaml added
- File alert.json alert.json added
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
Updated by Ryan Cote almost 8 years ago
- File suri_timestamp.PNG suri_timestamp.PNG added
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.
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.
Updated by Victor Julien almost 8 years ago
Are you able to reproduce with a pcap recording of your traffic?
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
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?
Updated by Ryan Cote almost 8 years ago
Andreas Herz wrote:
Can you share the .pcap with us?
Forwarded via email.
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.
Updated by Victor Julien almost 8 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.2.1