Multi-Level-Encoding BLOCKING http://metal.fortiguard.com/

Reply
Highlighted
L1 Bithead

Multi-Level-Encoding BLOCKING http://metal.fortiguard.com/

Can anyone report successfully passing these tests?:

http://metal.fortiguard.com/

And what combination of settings did it?

Default Multi-Level-Encoding BLOCKING doesnt seem to catch what http://metal.fortiguard.com/ is doing.

 

Highlighted
L7 Applicator

I had a chance to look at this a little bit.  I disagree with their pass/fail criteria.  According to them, in order to pass their test, your firewall must accept the entire file, iteratively decompress, and block based on detecting the eicar file.  

 

When you block multi-level encoded files, PAN-OS stops the 5x-10x ZIP files from being transferred in the first place.  (Un)Fortunately, PAN-OS stops the transfer of these files before it gets to the eicar virus.  Fortinet calls this a "fail" because it wasn't blocked based on their "AntiVirus" detection criteria.  Personally, I'd call it a success.... why would I want to allow something that's been zipped more than 5 times into my network?  No thank you.  I think PAN-OS should get extra credit for stopping the malicious file earlier on in the download process.

 

Similar things can be said for the rest of the file types.  I'm trying to remember the last time I downloaded a tar, tar.gz, rar, 7z, passworded zip, or ARJ file on my desktop.  Well, I do remember ARJ at least... it was about 1998.  Each environment is different, but my file blocking profiles prevent the transfer of these riskier file types (along with quite a few others) unless they come through approved applications ie: CABs through ms-update only from microsoft.com, or tar.gz from an approved repository for my linux servers.  

 

TL;DR is that when I ran the test, the eicar virus file never entered my network.  Fortinet didn't like how it was done so they gave me a 5/18 score.  The eicar file never entered my network, so I gave myself 18/18 and patted myself on the back.

Highlighted
L1 Bithead

Half the archives I work with are tgz. I think your attempt to discredit the test based on your usage is pretty naive. I agree with your first comment though about blocking based on levels of containers. However, products like Sophos seem to be able to inspect arbitrary levels, it is frustrating that PA have chosen a specific limit.

Highlighted
L7 Applicator

sophos only has to focus on one thing, and speed is not a big issue. At the firewall level, speed while maintaining accuracy is paramount thus parallel processing is required. this also means a session can be rejected based on the first negative hit, rather than tallying hits for every single stage. (this means more effcient use of resources)

 

the deeper inside an archive a system needs to go, the more resources are consumed and for a system sitting at the perimeter, resources are precious: starting from PAN-OS 7.0, the 'depth' of decoding has been increased to 4 levels, which should be more than sufficient for any normal archive.

reaper - PANgurus.com
Find my book at amazon.com/dp/1789956374
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!