S170 not blocking all windows executables?

[acercco]

Hi all,

We have a couple of S170s on AsyncOS 7.7.0 and have found that some windows executables can be downloaded even when the "windows executable" object is blocked by an Access Policy.

An example of this is https://download.articulate.com/storyline/2/storyline-2.exe

This seems to be because the MIME type is "application/octet-stream", which falls outside the MIME type block list.

We don't really want to add that MIME type to the the custom block list: it is also used for possibly-allowed things e.g. compressed files.

I read in the User Guide that AsyncOS sometimes scans files "If warranted" to see if they are in fact other types e.g. executables, but this doesn't seem to kick in in this case.

I have tried to create a custom URL category with a regular expression "\.exe", but unfortunately, this does not work unless we specify URLs. Fair enough.

How can we ensure that all files with an ".exe" extension get blocked, or is this something that cannot be done?

[Raed Boshmaf]

Hi, Give the following a try:

1. Create a custom URL category to block files with file extension .exe

Keep the sites option empty and just include the following in the Regular expression option (\.exe$) "without the parenthesis".

2. Associate the newly created custom URL category with an Access policy and set it to "Block".

(just go the URL Filtering option of that Access policy and from the Custom URL Category Filtering option set the action for the Custom URL that you created and associated to this policy to Block  )

I did a test in our local labs and it is working "the test was to go to cnet and download avast".

Access_logs:

1464697225.302 2 10.63.77.155 TCP_DENIED/403 0 GET http://files.downloadnow.com/s/software/14/53/28/63/avast_free_antivirus_setup_online.exe?token=1464714798_887c4db13f76bc0b022935d22a55acff&fileName=avast_free_antivirus_setup_online.exe - NONE/- - BLOCK_CUSTOMCAT_12-testaccess-test-NONE-NONE-NONE-NONE <C_test,0.0,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,IW_busi,-,"-","-","Unknown","Unknown","-","-",0.00,0,-,"-","-",-,"-",-,-,"-","-"> -

Regards

Raed

[acercco]

Thanks for the help Raed,

I have pretty much already done exact what you said, before you said it, as mentioned in my question. I, too, can block Avast from cnet.

Strangely, I still cannot block the file from download.articulate.com. Could you please try to see if you can block that one as well?

[acercco]

Okay, it turns out the problem is HTTPS. We do not have decryption/HTTPS proxy in place, so the custom URL categories are not triggering for HTTPS sites, since the WSA cannot see the URI.

The custom URL category itself (with \.exe) was otherwise correct.

So, downloads from nvidia and cnet (HTTP) work, but downloads from intel and articulate (HTTPS) do not, for our set up.

[Handy Putra]

That is correct for HTTPS traffic, and in order for the WSA to see the object type, the encrypted traffic will need to be decrypted (if its encrypted WSA only see the parent domain request or destination IP address in WCCP redirection mode).

Once the encrypted traffic being decrypted, it will become normal HTTP traffic and Access Policy(if HTTPS proxy enabled, Decryption Policy is the one policing all the HTTPS traffic) will kick in to apply the scanning needed.