Description
The article explains an issue where a flow-based file filter security profile fails to prevent downloading after a second attempt and offers a solution.
Scope
FortiGate.
Solution
This problem may occur when using a 'flow-based' file filter:
Example log:
date=2022-09-20 time=20:46:27 eventtime=1663699587411289097 tz="+0200" logid="1900064000" type="utm" subtype="file-filter" eventtype="file-filter" level="warning" vd="root" policyid=1 sessionid=114743 srcip=192.168.15.2 srcport=59621 srcintf="port3" srcintfrole="undefined" dstip=143.186.120.171 dstport=443 dstintf="port2" dstintfrole="undefined" proto=6 service="HTTPS" profile="ff-executables-fb" direction="incoming" action="blocked" url="https://demo.borland.com/testsite/downloads/downloadfile.php?file=dotNetFx40_Full_x86_x64.exe&cd=att..." hostname="demo.borland.com" agent="Chrome/86.0.4240.75" filtername="executables" filename="dotNetFx40_Full_x86_x64.exe" filetype="exe" msg="File was blocked by file filter."
Despite how the FortiGate has blocked the file, the user is able to bypass the filter by downloading the file again a second time.
This may occur for at least two reasons:
1) Modern web browsers can store partially downloaded files. This is done to continue file downloads seamlessly after a network disruption occurs.
2) A flow-based filter scans the file at the same time as it is transferred to the requester. When the FortiGate has identified that it should be blocked, it sends a reset request to the user downloading the file to disconnect the session.
To prevent this from happening, switch the file filter scan mode from flow-based to proxy-based. Additionally, adjust the inspection mode from flow-based to proxy-based in the firewall policy.
Related documentation:
- Technical Tip: Configuring file filter (standalone... - Fortinet Community.
- Technical Tip: Use file filter rules in sniffer - Fortinet Community.
- Technical Tip: How to use file filtering - Fortinet Community.
