Bug #1536
closedeve log alert
Description
In eve log sometimes (random?) it lacks the object http or voice payload_printable while showing it as alert.
Tested version 2.1beta4 and git master.
Actual result:
{ "timestamp": "2015-09-02T16:52:21.795878+0200", "flow_id": 29637168, "in_iface": "eth0", "event_type": "alert", "src_ip": "xxx.xxx.xxx.xxx", "src_port": 43512, "dest_ip": "xxx.xxx.xxx.xxx", "dest_port": 80, "proto": "TCP", "alert": { "action": "allowed", "gid": 1, "signature_id": 940000006, "rev": 5, "signature": "xxx", "category": "xxx", "severity": 1, "tx_id": 0 }, "payload_printable": "GET /......", "stream": 1 }
or
{ "timestamp": "2015-09-02T16:52:21.795878+0200", "flow_id": 29637168, "in_iface": "eth0", "event_type": "alert", "src_ip": "xxx.xxx.xxx.xxx", "src_port": 43512, "dest_ip": "xxx.xxx.xxx.xxx", "dest_port": 80, "proto": "TCP", "alert": { "action": "allowed", "gid": 1, "signature_id": 940000006, "rev": 5, "signature": "xxx", "category": "xxx", "severity": 1, "tx_id": 0 }, "stream": 1 }
Expected result:
{ "timestamp": "2015-09-02T16:52:21.795878+0200", "flow_id": 29637168, "in_iface": "eth0", "event_type": "alert", "src_ip": "xxx.xxx.xxx.xxx", "src_port": 43512, "dest_ip": "xxx.xxx.xxx.xxx", "dest_port": 80, "proto": "TCP", "alert": { "action": "allowed", "gid": 1, "signature_id": 940000006, "rev": 5, "signature": "xxx", "category": "xxx", "severity": 1, "tx_id": 0 }, "http": { "hostname": "www.xxx.xxx", "url": "/.....", "http_user_agent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36\tChrome 35.0", "http_content_type": "image/gif", "http_refer": "http://xxx.yyy/", "http_method": "GET", "protocol": "HTTP/1.1", "status": 200, "length": 35 }, "payload_printable": "GET /......", "stream": 1 }
eve log configuration:
- eve-log: enabled: yes filetype: regular #regular|syslog|unix_dgram|unix_stream filename: eve.json types: - alert: # payload: yes # enable dumping payload in Base64 payload-printable: yes # enable dumping payload in printable (lossy) format # packet: yes # enable dumping of packet (without stream segments) http: yes # enable dumping of http fields # tls: yes # enable dumping of tls fields # ssh: yes # enable dumping of ssh fields xff: enabled: no mode: extra-data deployment: reverse
Updated by Victor Julien over 8 years ago
Is there a difference between the rules? E.g. does it work when the rule matches only on http keywords but not (always) if using just plain 'content'?
Updated by Marco Rondini over 8 years ago
I tried to remove all of the rules and to enter one like this:
alert http any any -> $EXTERNAL_NET $HTTP_PORTS (msg:"xxx"; flow:to_server,established; pcre:"/.*/Pi"; classtype:web-application-attack; sid:910000003; rev:5;)
The result is the same: the invalid output varies from 30 to 50% of the total.
Updated by Jakob Andersen over 8 years ago
Marco, could it be that your traffic is single sided? By default, the http parser doesn't seems to run if the underlying TCP session is not complete. If this could be the case, try playing with the settings "async-oneside" and "midstream" in suricata.yaml?
Updated by Marco Rondini over 8 years ago
I just played with these settings but the result remains the same
Updated by Jakob Andersen over 8 years ago
:-( Are you able to share the pcap file you have used for testing?
Updated by Andreas Herz over 7 years ago
- Status changed from New to Closed
- Assignee set to Anonymous
- Target version set to TBD