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.


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 '' 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.

Wednesday, 3 February 2016

"Connection Failed: Enforce Firewall Policy failed" - on OSX Yosemite

According to SK106293 - this problem can be fixed via a hotfix from Check Point TAC.
I've tried the hotfix and it doesn't appear to perform any different. You still get the same error pop up and in the logs.
There is a workaround though - you need to manually disable the firewall on the client (if your policy allows for it).

First, shutdown the CP client from your menu bar.

Stop the CP services

 sudo launchctl unload /Library/LaunchDaemons/com.checkpoint.epc.service.plist  

Edit your Trac.defaults file at /Library/Application Support/Checkpoint/Endpoint Connect/Trac.defaults

The top line should read something similar to


(the formatting of this file is horrible - I've removed loads of spaces / tabs to make it more readable).

Change the value of '1' to '0'.

Restart the CP services then stop them again

 sudo launchctl load -w /Library/LaunchDaemons/com.checkpoint.epc.service.plist
 sudo launchctl unload /Library/LaunchDaemons/com.checkpoint.epc.service.plist  

This will start the services and decode your Trac.config file so you can edit it (make sure you stop the services again to be able to edit the decoded file!).

Find the line like <PARAM enable_firewall="true"></PARAM>  and edit the value 'true' to 'false'. You might have another like showing the name of your policy - I'm not sure it's required with the policy disabled but I edited mine from "desktop_policy" to "".

Save and close the file then finally start the services again.

 sudo launchctl load -w /Library/LaunchDaemons/com.checkpoint.epc.service.plist  

Start the Endpoint VPN application again from Launchpad and try to connect. If it works for you too - awesome! If it doesn't - sorry, best speak to TAC to get a proper solution.

Tuesday, 26 January 2016

How to recover X-Raid (Netgear) drives after a chassis failure.

A while back I used to have a Netgear ReadyNAS Duo. For the time, it was pretty good value for money and proved to be a reliable little NAS for streaming and backing up files.
What I never really considered was what I would do should the chassis fail and I'm left with numerous drives running a 'proprietary' RAID type (X-RAID) and potentially no source for a replacement chassis other than eBay or CEX.
I assumed it would be a matter of plug drives in through a number of SATA > USB adapters and just dragging the files off once the OS magically picked up and decoded whatever X-RAID was.
Luckily, I never had to find out but a friend's house recently caught a lightning strike which took out his router and the ethernet port on his NV+ (the NAS took the lightning, not the friend). The drives looked to be safe in the NAS but with no way to access them - the only solution was to put them in something else and see what we could do.

The thought was to add all the drives to machine with plenty of SATA ports available (four for the drives from the NAS plus one for the OS and restoration drive) and see what happens, X-RAID seems to be pretty close to RAID-5 so I doubt Netgear / Infrant messed around with it so much as to make it unreadable by anything else.
Ubuntu 14.04 is my go to OS here - so I installed that on a spare drive (at this point the NAS drives were absolutely nowhere near this machine for fear of overwriting them accidentally).
When your'e happy it's installed and running, power down and add the old X-RAID drives in. Once connected, boot up again.

WARNING: Don't run DF once you've mounted your drives with Fuse. There appears to be a bug that causes the fuseext process to crash and consume 100% CPU time. The 'du' command is slow (like, really slow) but won't crash your system.

Next, we'll need to make sure we've got the FUSE module installed for Ext2 filesystems. First we'll cheat a little and go into a root shell.

 sudo bash  

(Warning: this will put you in to a root shell. Be very careful what you type outside of this list as you can cause serious damage to things).
Next install the Fuse Ext2 package.

 apt-get install fuseext2  

Then, load the fuse module.

 modprobe fuse

Next, we'll scan our connected drives for LVM volumes with


Now we'll activate the volume we need

 vgchange -ay c 

(vgchange will search for all LVMs, '-ay c' will activate any volume named 'c' which is the name for the main volume on a ReadyNAS).

Make sure you have a mount point created to mount the reassembled volume in

 mkdir -p /mnt/readynas 

(just an example, call your directory whatever you like under /mnt/)

Then finally (fingers crossed here)

 fuseext2 -o ro -o sync_read /dev/c/c /mnt/readynas

All being well, you're data will all be available under /mnt/readynas (or whatever you called it). You're free to copy it off to a non RAID drive, thumb drive or whatever you have to hand.

Thursday, 14 August 2014

APM1 (Arduino 1280 based) Arducopter software

I've just acquired an older Arducopter quad and not had much luck with putting the newer versions of Arducopter onto the board because of its limited memory capacity. With a lot of digging and searching for the right Arduino IDEs and software versions - I've managed to build a couple of versions; one as per the source and one with some modules removed to make it fit onto the board. The hex files are attached below to hopefully save someone the pain of searching, compiling and failing. I'll also attach the IDE if you want to verify the code and compile yourselves.

Arducopter 2.3 and Arducopter 2.5.5 with NO CLI

The 2.5.5 firmware also has a few other modules removed as per this thread on DIY Drones.
Please be aware I've not tested the 2.5.5 version (yet) but the 2.3 release seems to fly perfectly well but again I've not tested the flight modes.

 # define CONFIG_RELAY      DISABLED  
 # define CAMERA         DISABLED  
 # define MOUNT         DISABLED  
 # define CLI_ENABLED      DISABLED  

The other files I've used to compile with and from are here:

Arduino 0022 (Relax Patch)
Arducopter firmware sources

Thursday, 29 May 2014

Fiddler SSL interception not working

Fiddler has been my go-to web application debugging tool for as long as I've needed one. Yesterday - it simply decided it didn't want to decrypt any more SSL traffic for me. No settings changed (no, really) or anything and I started seeing this error for every site I tried connecting to:> HTTPS handshake to failed. System.Security.Cryptography.CrytpographicException Cannot find the requested object.

Not a particularly helpful error message (at least not to someone who isn't the developer) so off to Google I went. A few hours of searching through various Google Group discussions mentioned some recent changes to the .NET framework which has changed certain cryptographic behaviours and broken things. The solution is to go to C:\Users\[your username]\Documents\fiddler2 and rename the file ClientCertificate.cer to something else. I'm not 100% certain on why this certificate would cause the problem in the first place but it fixed my SSL interception so I'm happy again. Full discussion from here.