Firewalls
20 June 2020

Checkpoint and non-std SSH

By admin@labtinker.net

Herein is the last in the series of how firewalls can be configured to block applications running on non-standard ports, specifically ssh.

Today’s firewall vendor is the venerable Checkpoint and once more for the purposes of the lab I will reluctantly direct more moolah to Jeff Bezos’ bulging coffers by selecting the appropriate device from the AWS marketplace.

Initially, I chose this…

Figure 1: Checkpoint firewall- sounds good.

…and it took me a while to remember that Checkpoint use a manager and a gateway and you need the former to control the latter. These are usually two separate devices in the enterprise but for my purposes I’d like something that does the job of both… and ‘All-in-One’ something or other below fits the bill – why take two modules into the virtual datcentre?

Figure 2: Checkpoint manager and firewall.

Once more I used my standard topology:

Figure 3: Reduce, Reuse, Recycle

Using a browser, I connected to the gateway/manager and installed the software taking care to specify that I wanted the unit to be both a manager and a gateway (firewall)

Figure 3: Gateway and Manager

Checkpoint doesn’t use a Java client but instead a proprietary fat one which it was necessary to download from the firewall/manager. This is used to connect to the firewall on tcp/19009 to control policies. (The web-based GUI is for module/gateway specific stuff like routes and interfaces)

Figure 4: That client is fat.

So from Gaia (the web GUI), the interaces were set up thusly:

Figure 5: Interfaces

To ease routing concerns you may recall I generally manage the firewall on its external interface (otherwise mgmt and external interfaces both route to the Internet). This is not something I’d necessarily recommend in real life and I had issues connecting with my fat client which I couldn’t really pin down so I set up management on the internal interface from my AWS Windows box and it worked OK.

I set up the rule to allow the Windows client out to the Internet thusly:

Figure 6: Outbound rule

…and the NAT as follows…

Figure 7: Hide NAT

Now, I did a bit of messing around with this firewall (getting RDP set-up through it etc) and I don’t actually remember adding this particular NAT rule and the fact it comes under ‘Automatic Generated Rules’ is interesting… did it work it out from the access policy it needed this NAT rule (I don’t remember a talking paperclip saying – ‘it looks like you’re trying to get to the Internet shall I put in a hide NAT rule?’). I would go back and check my notes if I had some.

I wouldn’t dwell on this as it’s not the focus of the lab.

So I browsed to this excellent website: www.labtinker.net on (3.8.129.9) from my AWS Windows box through the firewall which confirmed everything was configured hunky-dory-ily.

FIgure 7: Resolving labtinker.net
Figure 8: Normal browsing.

Now, I stood up my linux server and assigned a dns name to its ip address of linux.labtinker.net and tried to ssh out to it on port 80 (as per the previous labs) and I was in like Flynn…(I’ve foregone pictorial proof save the logs below)

Figure 9: SSH-ing out on port 80 with no problem.

Whereas I’ve generally shown the process in arriving at how I blocked this behaviour, I think I’ll cut to the chase on this lab. I went down a couple of rabbit holes but essentially it came down to the following:

Checkpoint separate their ‘Access control’ policy which deals with standard source ip address, destination ip address and service type policies and their ‘Threat prevention’ policies .

Figure 10: Policy options

The Threat Prevention policy includes many types of Threat and what the security gateway’s response to said threat should be – the main ones being ‘detect’ or ‘prevent’

Figure 11: Threat prevention policy

Popping ‘ssh’ into the search bar I got these two ‘protections’:

Figure 12: SSH protections.

I changed the action of ‘SSH over Non-Standard Ports’ from ‘Detect’ to ‘Prevent’ and… it made no difference.

I had to enable ‘IPS’ on the ‘Threat Prevention’ tab of the firewall object itself.

Figure 13: Enabling IPS On Threat Prevention tab.

Below shows the policy accepting the ssh traffic over tcp/80 and then rejecting it when the stars are aligned or the above actions are taken:

Figure 14: Allow/Disallow logs
Figure 15: Linux.labtinker.net as seen in logs above.

As this concludes my tinkering with various firewall vendors’ approach to this issue, this is my league table based on ease of implementation:

1st Palo, 2nd Fortigate, 3rd Checkpoint, Cisco ASA dnf*

I appreciate this doesn’t cover a lot of vendors but I thought the different approach shown by them was interesting. In subsequent posts covering other topics I will try and take some other vendors for a spin.

*dnf – did not finish.