AV error message - file reached uncompressed limit

[SteveGrant]

Hi there, I' m running FortiOS 5.2 on a FG60D. For the most part it' s been working well since upgrading to 5.2 from 5.0.7. I have, though, been getting odd error messages from the AV engine. The culprit appears to be application updates for Android devices from Google Play. Generally the update completes successfully, but it' s an odd one and I' m wondering weather other people have had the same problem. I never got this message when running 5.0.7. The message is below: Message meets Alert condition File Block Detected: Protocol: HTTP Source IP: 192.168.0.45 Destination IP: 213.253.9.140 Email Address From: Email Address To: date=2014-08-01 time=08:26:06 devname=CIR-FG60D devid=FGT60D4613026425 logid=0262008961 type=utm subtype=virus eventtype=scanerror level=notice vd=" root" msg=" File reached uncompressed size limit." action=passthrough service=HTTP sessionid=4635915 srcip=192.168.0.45 dstip=213.253.9.140 srcport=44417 dstport=80 proto=6 direction=incoming quarskip=No-skip url=" http://r1---sn-ja5g5-ajte.c.android.clients.google.com/market/GetBinary/GetBinary/com.a0soft.gphone.app2sd/90003369:90003359:2?mm=31&m" profile=" default" agent=" AndroidDownloadManager/4.4.4" analyticscksum=" c7beb43ac2b6ac3cd84cec404a95447607f918c989120ff6c2a5f304b454f1e6" analyticssubmit=false Thanks, Steve

[AtiT]

Hi, It seems that the file what was downloded was some archived file so the AVengine has to decompress it and scan for viruses. As during the uncompressing the AV engine reached the memory limit for uncompressing the file - maybe the default value is something like 12MB - the AV will passthrough the file - the default settings. If I am wrong someone can correct me.

[ede_pfau]

We got used to this particular message which clearly is a BUG because it states " File Block Detected" . Which it never did. You should have received that file despite it' s size, right? Seems they fixed it in 5.0.x and reintroduced it in 5.2. There is another " false positive" AV message stating that an archive is encrypted (which is true) and therefor blocked (which is not!). Wonder if they caught that one in the mean time...

[Sean_Toomey_FTNT]

By default the file size limit of proxy AV is 12MB because much more than that and you are really taking a toll on the firewall, especially a smaller unit like the 60D. It is possible to change these values under " config antivirus service xxxx" where xxxx is a particular service like https (see below). config antivirus service " http" set uncompsizelimit 10 set uncompnestlimit 12 set scan-bzip2 disable end That said, in FortiOS 5.2 there were immense enhancements made to the flow protections and they are now considered as effective (or very nearly so) to the proxy protections. Therefore, I would heavily encourage you to switch AV, Web Filtering and AntiSpam (if you' re using it) to flow mode. This helps conserve resources on the box, it no longer has to proxy the connection (less moving parts = less potential problems) and you no longer have a size limitation. It' s a win/win for most every environment. There are still some high security environments where they require the very highest chance that viruses will be detected by this engine and for those cases proxy is still appropriate.. but with 5.2 I would say in my estimation 85% or better of installations will do just fine with flow and benefit from higher throughput as well. To your point about the log saying " File Block Detected" , one of the options of the AV protection is the ability to block any file or archive that the firewall cannot scan, and for proxy users this means any file above 12MB. The reason that exists is that (again) some high security environments require it. I do think the message could be written a little better than it is, so that its purpose is more clear, but I do know we had the logging requirement to say whenever we could not scan the file due to its size. If you do not feel this log is useful to you, you could have your syslog or FAZ ignore that message so that it gets rid of potential noise. Hope this helps. Cheers!

[SteveGrant]

Now that' s interesting that you mention using flow based scanning as that was one of first things I changed when upgrading! The AV profile is definitely set to flow. I read somewhere that if the AV engine switches back to proxy mode under certain conditions but I can' t find the reference now. Could this be what' s happening here - or is it simply a 5.2 bug? Thanks everyone.

[Sean_Toomey_FTNT]

From FortiOS Handbook: " Flow-based scanning does not use a buffer and therefore has no file-size limit. File data is scanned as it passes through the FortiGate unit. The uncompsizelimit setting has no effect for flow-based scanning." If you have AV set to Flow that is what it should use for any instance that it is capable of scanning. HOWEVER - if you have any other protection using proxy mode (DLP, WebFilter, AppCtrl, Email Filter) this invokes the proxy which may then cause the situation to reoccur. If you are sure all your UTM profiles are set to Flow mode and you still see this message happening, please open a case with TAC so we can take a look at that for you. Make sure to include a backup of the config as well as a diag debug report / exe tac report. Cheers!

[ede_pfau]

@Sean Sorry, I think your comment might be misleading. One quite frequent reason why archive scanning fails is not size but encryption. That is the reason most of the time when I see a log message from AV with " File Block Detected" . The reason why I call these messages buggy is that although the archive cannot be scanned it is nonetheless permitted through (" action=passthrough" ) and not blocked as stated. There is an option to block files which the AV engine cannot scan and if this happens it should be logged. But this message is triggered regardless of the action taken, blocked or permitted. BTW, having files scanned up to 12 MB is IMHO a sure waste of ressources. If you mention the size parameter then you should as well point to the fact that the probability of having malware inside a file is falling exponentially with file size. There are virtually no observed malware infected files in the wild bigger than 2-3 MB. Scanning all the rest of the file is useless and a waste of time and memory. This has been discussed previously on this forum IIRC. Lastly, the biggest drawback of flow mode is it' s unability to scan archives. So overall security in any scenario is compromised to the extent in which archives (ZIP, .XLSX,...) are part of the files in the data scanned. Any network should be concerned with this. I am not argueing that flow mode has seen improvements over time, it' s only that disadvantages in principle should not be disregarded, esp. with novice users.

[Sean_Toomey_FTNT]

Hi Ede, Not trying to be misleading. The information you have is accurate for FortiOS 5.0 and below. 1. In FortiOS 5.2 the flow mode can buffer the file and indeed it can scan archived files. Flow is now the default AV mode in FortiOS 5.2 specifically because of these improvements. I would cite more than the below but the AV document for 5.2 is still being written. http://docs.fortinet.com/uploaded/files/1912/fortigate-whats-new-52.pdf page 61 http://investor.fortinet.com/releasedetail.cfm?ReleaseID=843431 " A new deep flow advanced malware engine that goes beyond traditional signatures and heuristics; combining the speed of flow-based analysis with the breadth of proactive detection technologies including unpacking and emulation" 2. The default size limits for proxy mode are geared to be a bit above what the average installation needs. I personally agree with you, that 3MB is plenty for any installation I am running. But for out of the box default configuration, 10-12MB is a balance between use of system resources and the ability to scan malicious files, with a heavy handed weight towards the latter. Another good reason to just use flow, as the size limitation goes away. 3. The actual Android app that the OP was trying to download (which appears to be AppMgr III) is around 3MB. I am going to do some testing to see what I get when I encrypt a zip file with flow and AV proxy under 5.2 I do know it is a logging requirement for many companies that we log whenever we cannot scan a file, and I' ll be the first to say some of our syslog messages could be worded a bit better. Nonetheless, there is a different syslog message entirely for archives that are encrypted and cannot be read, that I would expect to see used instead of this one.. so that needs to be looked into.

[ede_pfau]

Thanks for the clarification. When 5.2 has stabilized (...5.2.3+) this will then definitely be the preferred way to do AV and IPS. Until then, and with 5.0 just gaining ' stable' reputation, users should be aware that flow mode cannot scan archives/Office files. I was talking about multiple log messages stating " File Block Detected" - there is one for oversized files and one for non-scanable files. My point is that both are misleading and should read " Possible File Block Detected" or the like. They only indicate that some files scanned were special but not blocked. Any information about the compressed file size limit you mentioned? Where did you see that (" 12MB" )? Edit: just read your answer in the other thread https://forum.fortinet.com/FindPost/107435 (funny that the same topic pops up several times in days but only once in a year before). Thanks.

[Sean_Toomey_FTNT]

Yep I agree on the preferred way. One thing I should note is that IPS isn' t proxied. In fact, " flow" protections utilize the IPS engine. It is the enhancements to the IPS engine that allowed the improvements to flow AV. Regarding stabilization, I think 5.2.0 has done well for an initial release - we do have a decent adoption rate in the field of it, and 5.2.1 is right around the corner (but can' t speak to specific date of release). One thing that is different from 5.0 days is that when we release patches to 5.2.x it is only for bugfixes and stabilization. There will be separate " feature" releases containing new functionality that will likely be 5.3 or 5.4 depending on how the enumeration is decided. The idea is for each patch to be more and more stable. That being the case, any non-critical deployments should be reasonably good to try 5.2.1, and by 5.2.3 or so I would say it is a candidate for production environments - this is a personal recommendation based on what I' m seeing internally and my own lab testing, and is in no way endorsed by Fortinet :) Just so that we are very clear on that. Cheers!