Hi,
As the title says, I am not getting accurate “pcap_filename” results in my eve.json when using --pcap-file-continuous. The pcap_filename value in the alerts and events do not correspond to the right files.
Also, every time I run it with the same set of pcaps, I get different results in the pcap_filename. I suspect it may be related to a threading issue? Not sure. Any insight would be helpful.
(I am setting pcap-file: true)
Thanks
Hi,
can you give us more details about your setup?
Which version, on which system and how do you run suricata?
Also feel free to attach the configuration and logfiles.
I have the same issue when scan directory of files. Pcap file name goes for incorrect files
Hi, could you add the necessary details requested above?
Suricata 5.0.8, 6.0.3, 6.0.4, 7.0.0-dev
Ubuntu 18.04
There is nothing special in configuration files, and log files does not have any errors.
Suricata is executed with --pcap-file-recursive . The problem with data in alerts. They are raised for wrong files. It is in pcap_filename field
Do you have some examples for that issue?
Yes, please share you email address, I will send there samples
Can this issue be because suricata does not handle correctly flows ? There are same FLOW ID for different PCAP files.
Is there any option to tell suricata to consider as different flows packets from different PCAP files ?
Andreas do you have any update?
Also having the same issue, please advice.
Please provide:
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”
}
Reported pcap_filename in alerts are not correct
Andreas do you have any update?
@Andreas_Herz any help would be really appreciated
Not correct in what way?
Is the pcap in pcap_filename from a different event or are parts not correct?
Does it also occur without the --pcap-file-recursive flag?
Also the config is missing!
Please try to avoid thread bumping.
suricata.yaml (74.8 KB)
Yes 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.
Hi @Andreas_Herz, do you have any update?
I can reproduce it as well, also with the -r run and without the --pcap-file-recursive flag. Would you mind filling a bug report on our redmine?