Bug #7199
Updated by Antonin Bas 4 months ago
After upgrading from Suricata 6 to 7, alerts in the eve JSON output no longer seem to include app-layer metadata.
This is what we use to have:
<pre>
{
"timestamp": "2023-03-09T20:00:28.210821+0000",
"flow_id": 627175734391745,
"in_iface": "antrea-l7-tap0",
"event_type": "alert",
"vlan": [
1
],
"src_ip": "10.10.1.5",
"src_port": 43352,
"dest_ip": "10.10.1.4",
"dest_port": 80,
"proto": "TCP",
"alert": {
"action": "blocked",
"gid": 1,
"signature_id": 1,
"rev": 0,
"signature": "Reject by AntreaClusterNetworkPolicy:test-l7-ingress",
"category": "",
"severity": 3,
"tenant_id": 1
},
"http": {
"hostname": "10.10.1.4",
"url": "/admin",
"http_user_agent": "curl/7.74.0",
"http_method": "GET",
"protocol": "HTTP/1.1",
"length": 0
},
"app_proto": "http",
"flow": {
"pkts_toserver": 3,
"pkts_toclient": 1,
"bytes_toserver": 284,
"bytes_toclient": 74,
"start": "2023-03-09T20:00:28.209857+0000"
}
}
</pre>
This is what we have now with Suricata 7.0.6:
<pre>
{
"timestamp": "2024-08-26T22:19:16.005590+0000", "2024-08-06T01:56:22.005829+0000",
"flow_id": 1147586615954996, 1540521509719125,
"in_iface": "antrea-l7-tap0",
"event_type": "alert",
"vlan": [
1
],
"src_ip": "10.10.1.9", "10.10.1.5",
"src_port": 54728, 37938,
"dest_ip": "10.10.1.10", "10.10.1.4",
"dest_port": 80,
"proto": "TCP",
"pkt_src": "wire/pcap", "stream (flow timeout)",
"tenant_id": 1,
"alert": {
"action": "blocked",
"gid": 1,
"signature_id": 1,
"rev": 0,
"signature": "Reject by AntreaNetworkPolicy:default/ingress-allow-http-request-to-api-v2",
"category": "",
"severity": 3,
"tenant_id": 1
},
"app_proto": "http",
"direction": "to_server",
"flow": {
"pkts_toserver": 3,
"pkts_toclient": 1, 2,
"bytes_toserver": 302, 291,
"bytes_toclient": 78, 136,
"start": "2024-08-26T22:19:16.005049+0000", "2024-08-06T01:55:17.227608+0000",
"src_ip": "10.10.1.9", "10.10.1.5",
"dest_ip": "10.10.1.10", "10.10.1.4",
"src_port": 54728, 37938,
"dest_port": 80
}
}
</pre>
The first output was captured with Suricata 6 a while back, but the rules were essentially the same. These are the rules I am using now:
<pre>
reject ip any any -> any any (msg: "Reject by AntreaNetworkPolicy:default/ingress-allow-http-request-to-api-v2"; flow: to_server, established; sid: 1;)
pass http any any -> any any (msg: "Allow http by AntreaNetworkPolicy:default/ingress-allow-http-request-to-api-v2"; http.uri; content:"/api/v2/"; startswith; http.method; content:"GET"; http.host; content:"foo.bar.com"; startswith; endswith; sid: 2;)
</pre>
And this is the relevant part of the config:
<pre><code class="yaml">
%YAML 1.1
---
outputs:
- eve-log:
enabled: yes
filetype: regular
filename: eve-%Y-%m-%d.json
rotate-interval: day
pcap-file: false
community-id: false
community-id-seed: 0
xff:
enabled: no
types:
- alert:
tagged-packets: yes
- http:
extended: yes
tagged-packets: yes
- tls:
extended: yes
</code></pre>
It seems to me that this change, which was not backported to 6, is responsible: https://github.com/OISF/suricata/pull/10876/files, as it added an extra condition for logging app-layer data.
I am assuming that even though the action is "blocked", the expectation is that http data can still be logged here (with the default `metadata` configuration for alerts).