How to allow Wetransfer?
There's an article about blocking Wetransfer: How to block WeTransfer file upload/transfer? | SonicWall
I would like to know how to allow Wetransfer? It's a service we use to send large files. Thing is, all up/downloads are intercepted by Capture ATP. It turns out Wetransfer uses AmazonAWS. When an upload starts, the counter moves up - then it moves down a bit, moves up, moves a bit down etc. The file is sent in chunks and whet every chunk, it connects to a different IP-address at Amazon. And our TZ470 then happily sends the same file to the Capture ATP cloud service. Depending on how big the file is and in the amount of chunks it's uploaded, it could mean it's using numerous different IP's on the Amazon-side and hence, the TZ470 the same number of times to the Capture ATP cloud service.
It gets uploaded in the end, but it takes quite some effort on the TZ470's side. So I wonder how to exclude uploading of files with Wetransfer from Capture ATP? The above mentioned article uses a piece of the URL used to upload files ( /api/v4/transfers/) but it's pretty generic - I don't want malware sites using the same piece in their URL's to bypass scanning. The URL I see in the firewalls System Log starts whit this: wt-prod-s3asaservice-storm.s3.eu-west-1.amazonaws.com/prod-euwest1/blocks/
Question is, is this part solely tied to Wetransfer? Or is there another way to exclude a site from scannen?
HI @Simon_Weel, are you using DPI-SSL ?
Hi Simon, in the Capture ATP Host exclusions ( HTTP Hostnames to exclude from Capture ATP ) , have you tried adding
wetransfer.com/api/v4/transfers/ or try wetransfer.com/api/v4/transfers/*
Gave it a try, but you cannot enter wetransfer.com/api/v4/transfers/* as a host name. I tried *.wetransfer.com on it's own, but that doesn't work when uploading files - they are redirected to wt-prod-s3asaservice-storm.s3.eu-west-1.amazonaws.com.
Posted a question for the people of Wetransfer, and this is what they say:
If you're having issues with your firewall and WeTransfer, please permit the domains we use: *.amazonaws.com, *.wetransfer.com, *.wetransfer.net, *.we.tl
We only use the normal ports 80 and 443. That would usually solve the issue, but if you want to dive in a bit deeper, here's some more! The following can be permitted for facilitating uploads:
For the platform:
cdn.wetransfer.net, api.wetransfer.com, we.tl assets.wetransfer.net, backgrounds.wetransfer.net, cdn.wetransfer.net and www.wetransfer.com (for the service, assets, and backgrounds)
To clarify my configuration; I've defined exclusions as Address Object (Group). Adding the two upload-domains to the exclusion-group doesn't work. As described in the initial post, the hostname seems to be wt-prod-s3asaservice-storm.s3.eu-west-1.amazonaws.com So I entered that as host to be excluded, but it still doesn't work.
Didn't use option 'HTTP Hostnames to exclude from Capture ATP' before, so tried that. Now when uploading, it's no longer logged, but the Wetransfer progress meter still runs up and down. Not sure why, but anyway, files do get uploaded, albeit a bit weird...
Hi @Simon_Weel, it lets me add it to the exclusions, not sure why it isn't working for you,
in this case though why don't you create an address object group with the FQDN's mentioned and then create a outbound firewall access rule rule using the Object group as the Destination and disable the DPI / DPI-SSL in the Security Profiles tab on the rule and see if it works then.
I gave it a try and this seems to work so far?
Stupid person here falling into trap of WeTransfer files not uploading (and it is imperative they get to a SOC).
How, exactly, in a Gen 7 device, do you add a new Access Rule? I do not see any form of "add" on this page:
What am I missing?
@Larry where did your Action Bar go to? Is this new? Sometimes I'am struggle myself to find the proper Button, because it's either at the Top or the Bottom or pops up dynamically either directly at the mouse pointer or to the right of a column.
Every table/list page in the product has the actions on the top. And yet...
Heading: Rules and Policies
Category: Access Rules - actions on bottom
Category: NAT Rules - actions on bottom
Category: Routing Rules - actions on bottom
Category: Content Filter Rules - actions on top
Category: App Rules - actions on top
Category: Endpoint Rules - actions on top
I can't understand why there is NO standard AT ALL for consistent UI/UX development with this product.
Time to reach out to my partner rep to submit an RFE; however, I doubt that it'll ever see the light of day...
This seems to turn out easier then I thought - using App Rules. There's already a predefined app for WeTransfer under Match Object. So I created a Match Object for WeTransfer and added it to the App Rules policy, setting to bypass GAV.
Not ideal, since you would like to have all downloads scanned, so if there's a better way....?
Well, that hope was short-lived. App Rules don't seem to work. So I decided to disable Capture ATP all-together and then upload a file to WeTransfer (should have tried that in the first place....). And the result is, the upload still rolls back frequently until WeTransfer gives up? So I think we can rule out Capture ATP as the problem.
And to make things even more difficult - the upload attempts are no longer logged in the firewall's System Log?
Any updates on this issue? ... we are also facing the same problems with a Sonicwall NSA2700.
When I exclude the clients IP adress to exclude DPI-SSL the problem is solved, so it looks like DPI-SSL is causing the problem. I now added wt-prod-s3asaservice-storm.s3.eu-west-1.amazonaws.com as Common Name exclusion under DPI-SSL and looks like it it working for now.