Trying to block new .zip and .mov domains, following KB, but still not working?
We have decided (and it seems like we're not the only ones) to block access to the new .zip and .mov domain names in their entirety.
Following this KB article:
Totally makes sense, I've triple-checked all the items listed and we appear to match, but we're still able to load .zip and .mov websites without issue. (I'm using http://www.img.zip as a test, which still continues to load fine.)
I'm sure I'm missing something silly like "did you remember to enable App Rules?!" (Yes!), but what?! Is there a better method to accomplish the same thing?
thanks for any suggestions
MustafaA SonicWall Employee
With the App Rule/Match Object combination I was also not able to block img.zip URI. This needs further investigation.
As an alternative you can create an FQDN Address Object for *.zip and create a Deny Access Rule using that as destination. I've tested this and it works as expected.1
Ajishlal Community Legend ✭✭✭✭✭
since we are blind on .zip .mov websites, recommended to create FQDN entry (*.mov / *.zip) and block through the ACL.
Create the rule LAN --> WAN based rule as same as below and call the FQDN address object group in the destination and choose the action Deny.1
preston Enthusiast ✭✭
@techuser just use the CFS URI as below, using *.mov and *.Zip works for me added to the Forbidden URI List in the CFS Profile, this works also without DPI-SSL enabled just make sure you enabled HTTPS on the CFS Profile (you don't get the block page as below for HTTPS but it does drop the connection)1
Best approach (IMHO, because it does not need much performance) would be to block on DNS level, sadly built-in DNS Security cannot block whole TLDs.
Maybe this is something worth considering for SonicOS 7.1 which will enhance that topic.
@techuser , to block TLDs as described in the following KB article with App Rule/Match Object, DPI-SSL is required for HTTPS domains.
Thanks for bring this up.
To add clarity, the KB article will be updated, highlighting that DPI-SSL is required for HTTPS domains.
Thank you, all, for your help on this!
I did ultimately take the route of creating two FQDN address objects (*.zip and *.mov), a new Address Group including these two objects, and a DENY LAN -> WAN rule.
This is now working in our environment to prevent access to various test .zip and .mov websites.
I also appreciate the heads up that DPI-SSL is required in order to use the App Rule/Match Object workflow (which makes sense).