Project

General

Profile

Actions

Bug #8165

open

FTP data is not blocked with drop rule and filemd5 match

Added by Thomas Winter 3 days ago. Updated about 3 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Running suricata in IPS mode with a ftp-data drop rule to match on MD5. The event is alerted and with a drop rule, logging claims it is dropped but the FTP data packet gets through and the ftp client gets the file. The next TCP acks are blocked.

The EICAR file is a small file so it is only 1 ftp data packet. I don't know if more packets to trigger the md5 match would affect the behaviour.

See suricata-verify/tests/smtp-attachment-md5/ for same md5 and similar rule used but with ftp-data or ip protocol instead. I haven't tried other hash methods.

Tested on 8.0.1, 7.0.8, 7.0.6, 7.0.3. Also 4.0.6 but that was a heavily modified version.

Attached packet captures are of the client side.


Files

ftp_eicar_allowed.pcapng (4.4 KB) ftp_eicar_allowed.pcapng Thomas Winter, 12/12/2025 03:55 AM
ftp_eicar_not_fully_dropped.pcapng (4.89 KB) ftp_eicar_not_fully_dropped.pcapng Thomas Winter, 12/12/2025 03:56 AM
Actions #1

Updated by Thomas Winter about 3 hours ago

Forgot to say, the same file over http and smtp is properly blocked where the data packet is dropped.

Actions

Also available in: Atom PDF