Project

General

Profile

Actions
Copy link

Bug #8165

open

FTP data is not blocked with drop rule and filemd5 match

Added by Thomas Winter about 2 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
TBD
Affected Versions:
7.0.3, 7.0.6, 7.0.8, 8.0.1
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

Download all 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
Copy link
 #1

Updated by Thomas Winter about 1 month ago

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

Actions
Copy link
 #2

Updated by Thomas Winter about 1 month ago

A potential problem is FTPDataStateGetTxFiles and FTPDataGetAlstateProgress do

if (direction == ftpdata_state->direction)

I believe this should be
if (direction & ftpdata_state->direction)

as DetectFileInspectGeneric gives direction as (STREAM_TOSERVER|STREAM_TOCLIENT).

Making this change hasn't helped the test case.

Actions
Copy link

Also available in: Atom PDF