Block Wetransfer Upload

[ce1028]

I was doing a test on allowing wetransfer download, but not allowing upload. Ran into some issues. I have TLS decryption enabled. I have removed the *.wetransfer.com decryption exclusion.

My security policy is looking for applications "wetransfer" and "amazon-cloud-drive-uploading". I have a file blocking policy that is set to block upload of any application - any files.

If I go to wetransfer.com, I can upload any file that I wish

anyone successfully doing this?

[Remo]

@ce1028

Do you block connections that cannot be decrypted?

[ce1028]

@Remo no, in this lab, I do not have a decryption profile assigned. It's set to none

[ce1028]

Issue turned out to be related to another issue I had.  However, now I see a bigger problem.

I can configure a wetransfer download rule without an issue.  However, creating a rule that ONLY allows upload to wetransfer is proving to be an issue.

The only way to get it to work is to create a rule that looks like this:

source zone: trust

source user: mydomain\wetransferuploadusers

destination zone: untrust

applications: web-browsing/ssl

Service: TCP/80, TCP/443

This is an issue, because this will allow uploads to any site that's allowed, that runs over 80/443, and any internet traffic these specific users do will match this rule.

There has to be a better way, just haven't found one yet

[BPry]

@ce1028,

So maybe I missed something here, but you aren't actually doing decryption of this traffic at all? You won't be able to block uploads as you can't identify the traffic. Therefore you can't distinguish what is actually happening behind that SSL tunnel and you won't be able to identify amazon-cloud-drive-uploading to properly block this. You could use QoS to drastically slow down any uploads to make it unlikely anyone will actually use it, but you can't block it outright. 

+

[ce1028]

@BPry So, originally, I was decrypting the traffic because I disabled the "*.wetransfer.com" decrypted exception that Palo adds under SSL Decryption Exclusion.

With decryption disabled, I'm still able to block wetransfer uploads using a file blocking policy (although small files, like 100k upload even with file blocking on, but that's another issue).

What I'm attempting to do now is the opposite. I've already successfully blocked uploads, but now I want to allow uploads for specific users.  The issue is, with decryption on or off, palo only identifies this traffic as web-browsing and ssl.  It does not categorize the upload as amazon-cloud-drive-upload, although it should.

There does not seem to be a good way to allow uploads to only wetransfer

Update: Just to be clear, I always had TLS Decryption enabled. When I mentioned disabled decryption, I was referring the "SSL Decryption Exclusion"

[MikeC]

@ce1028

I have the same issue. Assuming you are in the US.  You can do this as a workaround. Keep your download security policy rule and create an upload security policy rule that looks like this

Destination Zone: untrust

Destination Address: wetransfer-us-prod-outgoing.s3.amazonaws.com    (need an address object)

Application: web-browsing, ssl

Service:  TCP_80, TCP_443

For EU, use wetransfer-eu-prod-outgoing.s3.amazonaws.com

[MikeC · Accepted solution]

My apologies, I typed this too fast. You don't need an address object.  Create a custom URL category containing the below

wetransfer-us-prod-outgoing.s3.amazonaws.com

wetransfer-us-prod-outgoing.s3.amazonaws.com/*

Then in the policy rule

Destination Zone: untrust

Destination Address: any

Application: web-browsing, ssl

Service: tcp-443

URL Category:  <name of custom URL category>

[ce1028]

This worked, thank you.

The only problem now is I don't see this traffic in the URL Filtering log. If you specify the custom url category in the security policy rule, does that mean its no longer logged?

[Remo]

@ce1028

URL logs are only generated by the URL filtering security profiles. When you add URL categories directly to the security policy, you are able to filter on URLs directly there but without also adding an URL filtering security profile, no URL log is generated. 

So in this case because you already restrict the rule to a custom URL category you could add a Log-All profile and you should see the URL logs.

[ce1028]

@Remobut I added a url filtering profile and set some of the categories to "alert". I see my custom url category there too and set that to alert, but no dice

What do you mean by 'log-all' profile? How is that setup?

[Remo]

@ce1028

What I meant with this log all profile is an URL filteting profile like the following:

• Set all categories to action "alert" (The custom ones I would set to "none" but this is up to you)
• Disable the checkbox at "Log container page only" (helpful in your case, but depending on the art of connection it could generate quite a few logs

Is my assumption correct that the profile that you applied has the log container page only checkbox activated? 

[ce1028]

@Remoyou were correct, the Log container page only option was enabled. I disabled and now it's logged.  Question though, did I have to uncheck the log container page only because I used the custom url category in the security policy rule, or is it unrelated?

[Remo]

@ce1028

With that option enabled the firewall only logs specific MIME types. This option should enable URL logging without generating potentially extremely high logrates (modern websites - spcially highly dynamic websites - where javascript loads content in the background, keepalives are sent and javascripts, images, css that are fetched from everywhere in the internet will generate high amounts of logs that are not very useful in most cases).

In your case the requests to the domains in your custom URL category are not matching the default MIME types so they were not logged. You have now the option to keep this config with the log container page only disabled or you add the MIME type used for this website to the Container pages config.

[ce1028]

@Remo thank you for clarifying. For this purpose, I shall create a seperate URL profile and turn the option off