Bug #5255
openReported pcap_filename in alerts are not correct
Description
Bug has more discussion here: https://forum.suricata.io/t/pcap-filename-in-eve-json-is-not-accurate-when-using-pcap-file-continuous/558/
Reported pcap_filename in alerts are not correct.
pcap_filename is from a different event.
It is not possible to use suricata without --pcap-file-recursive because it takes too many time to scan each file separately. Suricata bootstrap goes too long (2 minutes per each file). There are hundreds of files each 10 minutes.
I have attached config file as you asked.
Please help me to resolve this issues.
Suricata version 7.0.0-dev (3a490fb16 2022-03-04) Linux version 5.11.0-49-generic (buildd@lcy02-amd64-054) (gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #55-Ubuntu SMP Wed Jan 12 17:36:34 UTC 2022 /usr/bin/suricata -v -c /etc/suricata/suricata.yaml -r /opt/nids/test/ --pcap-file-recursive -l /var/log/suricata/ 2>/dev/null
{
“timestamp”: “2022-03-22T08:59:08.174415+0000”,
“flow_id”: 1155331436357967,
“pcap_cnt”: 54854,
“event_type”: “alert”,
“src_ip”: “10.0.0.104”,
“src_port”: 57621,
“dest_ip”: “10.0.0.255”,
“dest_port”: 57621,
“proto”: “UDP”,
“ether”: {
“src_mac”: “XX:XX:XX:4d:b2:4d”,
“dest_mac”: “ff:ff:ff:ff:ff:ff”
},
“community_id”: “1:4nybWSscJYddpIgTcsmSA0dz7v4=”,
“alert”: {
“action”: “allowed”,
“gid”: 1,
“signature_id”: 2027397,
“rev”: 1,
“signature”: “ET POLICY Spotify P2P Client”,
“category”: “Not Suspicious Traffic”,
“severity”: 3,
“metadata”: {
“affected_product”: [
“Windows_Client_Apps”
],
“attack_target”: [
“Client_Endpoint”
],
“created_at”: [
“2019_05_30”
],
“deployment”: [
“Internal”
],
“performance_impact”: [
“Low”
],
“signature_severity”: [
“Minor”
],
“updated_at”: [
“2019_05_30”
]
}
},
“app_proto”: “failed”,
“flow”: {
“pkts_toserver”: 1,
“pkts_toclient”: 0,
“bytes_toserver”: 86,
“bytes_toclient”: 0,
“start”: “2022-03-22T08:59:08.174415+0000”
},
“payload”: “hidden”,
“payload_printable”: “hidden”,
“stream”: 0,
“packet”: “hidden”,
“packet_info”: {
“linktype”: 1
},
“pcap_filename”: “/test//20220322090615350400-XX:XX:XX:XX:83:12-0e8816425288d9684f038bc55c3c03XX.pcap”
}
{
“timestamp”: “2022-03-22T09:04:08.198805+0000”,
“flow_id”: 1155331436357967,
“pcap_cnt”: 118976,
“event_type”: “alert”,
“src_ip”: “10.0.0.104”,
“src_port”: 57621,
“dest_ip”: “10.0.0.255”,
“dest_port”: 57621,
“proto”: “UDP”,
“ether”: {
“src_mac”: “XX:XX:XX:4d:b2:4d”,
“dest_mac”: “ff:ff:ff:ff:ff:ff”
},
“community_id”: “1:4nybWSscJYddpIgTcsmSA0dz7v4=”,
“alert”: {
“action”: “allowed”,
“gid”: 1,
“signature_id”: 2027397,
“rev”: 1,
“signature”: “ET POLICY Spotify P2P Client”,
“category”: “Not Suspicious Traffic”,
“severity”: 3,
“metadata”: {
“affected_product”: [
“Windows_Client_Apps”
],
“attack_target”: [
“Client_Endpoint”
],
“created_at”: [
“2019_05_30”
],
“deployment”: [
“Internal”
],
“performance_impact”: [
“Low”
],
“signature_severity”: [
“Minor”
],
“updated_at”: [
“2019_05_30”
]
}
},
“app_proto”: “failed”,
“flow”: {
“pkts_toserver”: 11,
“pkts_toclient”: 0,
“bytes_toserver”: 946,
“bytes_toclient”: 0,
“start”: “2022-03-22T08:59:08.174415+0000”
},
“payload”: “hidden”,
“payload_printable”: “hidden”,
“stream”: 0,
“packet”: “hidden”,
“packet_info”: {
“linktype”: 1
},
“pcap_filename”: “/test//20220322090914541400-XX:XX:XX:XX:2b:92-40b8c45e48e3fee6df38d2482ac16dXX.pcap”
}
{
“timestamp”: “2022-03-22T09:09:08.224668+0000”,
“flow_id”: 1155331457946243,
“pcap_cnt”: 120400,
“event_type”: “alert”,
“src_ip”: “10.0.0.104”,
“src_port”: 57621,
“dest_ip”: “10.0.0.255”,
“dest_port”: 57621,
“proto”: “UDP”,
“ether”: {
“src_mac”: “XX:XX:XX:4d:b2:4d”,
“dest_mac”: “ff:ff:ff:ff:ff:ff”
},
“community_id”: “1:4nybWSscJYddpIgTcsmSA0dz7v4=”,
“alert”: {
“action”: “allowed”,
“gid”: 1,
“signature_id”: 2027397,
“rev”: 1,
“signature”: “ET POLICY Spotify P2P Client”,
“category”: “Not Suspicious Traffic”,
“severity”: 3,
“metadata”: {
“affected_product”: [
“Windows_Client_Apps”
],
“attack_target”: [
“Client_Endpoint”
],
“created_at”: [
“2019_05_30”
],
“deployment”: [
“Internal”
],
“performance_impact”: [
“Low”
],
“signature_severity”: [
“Minor”
],
“updated_at”: [
“2019_05_30”
]
}
},
“app_proto”: “failed”,
“flow”: {
“pkts_toserver”: 10,
“pkts_toclient”: 0,
“bytes_toserver”: 860,
“bytes_toclient”: 0,
“start”: “2022-03-22T09:04:38.201347+0000”
},
“payload”: “hidden”,
“payload_printable”: “hidden”,
“stream”: 0,
“packet”: “hidden”,
“packet_info”: {
“linktype”: 1
},
“pcap_filename”: “/test//20220322090950822200-XX:XX:XX:XX:c1:c2-c550d07ceda9c9adfe0473975ab638XX.pcap”
}
Files
Updated by Victor Julien over 2 years ago
- Priority changed from High to Normal
Whats the way to reproduce this?
Updated by Ivan Kachkivskyi over 2 years ago
Please check Suricata forum links with configuration and files attached for steps to reproduce.
Link is on a top of message
Updated by Ivan Kachkivskyi over 2 years ago
This is constantly reproducing. Try to take 10-20 pcap files from several computers and scan them several times with --pcap-file-recursive, you will see not correct behavior.
Updated by Ivan Kachkivskyi about 2 years ago
Is there any update on this issue ?