5 June 2020

Fortigate and non-std SSH

By admin@labtinker.net

In the previous post we saw how a Palo Alto fared in blocking applications running on non-standard ports and in this one we’re going to try the same exercise with a Fortigate firewall.

Once again, I don’t have a physical Fortigate firewall to hand so used one in the AWS Marketplace:

Figure 1: AWS Marketplace’s Fortigate firewall

On the following firmware version:

I used the same topology as I did with the Palo Alto; namely:

I also followed the same apporoach as with the Palo Alto in that I did the minimum to set up the firewall to allow the Windows host to browse out to the Internet.

The interfaces were set up like this:

I set up a rule to allow the source, Windows_DMZ on 172.31.200.10, access to any (or all) destinations for http, https and dns only. I configured ‘hide’ NAT behind the outgoing interface. On a Fortigate this is all done on the same rule which looks like this:

Figure 4: Fortigate Rule to allow the Windows host to browse out to the Internet.

And having done this I was able to browse out happily to the Internet as these firewall logs show:

Figure 5: The Windows host browses the Internet

And so once again using the elementary yet fiendish plan of setting up a linux host (linux.labtinker.net) to run ssh on port 80 and then trying to connect to through the above rule which is set up to only allow http,https and dns.

Figure 6: Running up putty on the Windows box to linux.labtinker.net on port 80

And… it allowed me through the firewall. Below shows the Windows host (confusingly called fwext.labtinker.net because I’m RDP-ing through the external firewall interface on a static nat) ssh-ing successfully to our linux.labtinker.net.

And the log confirms this….

Figure 8: Log showing ssh through Fortigate on port 80

OK, so we don’t get applications running on non-standard ports blocked by default as we more or less did on the Palo. So let’s delve a little deeper. Each rule on the Forti gives us many more options such as: AntiVirus, Web Filter and Application Control…. and that last one sounds promising for what we’re trying to achieve…

So let’s turn on application control:

Now some firealls can be set to enforce rule changes for new sessions rather than run existing sessions through the rule base again so for good measure I am doing the following from the firewall’s CLI after each policy change to ensure my session starts afresh with the new rulebase:

diagnose sys session clear

As this killed my RDP session to the Windows box ,also going through the firewall as previously stated, I had some confidence the above command cleared existing sessions. (I think this is probably overkill but it’s easy enough to do in a lab environment)

With the application control turned on I was still able to ssh out to my Linux box on port 80 but the firewall at least now recognised I’m running SSH as seen by the application column in the logs:

Figure 11: That looks like ssh on port 80 – come right through.

The application profile is designed to let you allow (or more probably block) traffic based on its application category as we can see if we delve into the default Application Control profile under the Security Profiles menu:

The default settting for all profiles is monitor (the eye!) but you could block any applications as well as by altering the drop down box setting:

Figure 13: Applicaton profile page

OK, interesting but not probably not we want at the moment. But lo, just below this, look at this button…

So, like all good engineers let’s turn it on and see what happens.

And, dear reader, still I sailed through the firewall with ssh on port 80. I have actually missed the allow/deny column from the next log insert so you’re going to have to take this one on trust:

Is it time to RTFM? (here if you’re interested…)

https://docs.fortinet.com/document/fortigate/6.4.0/administration-guide/410638/protocol-enforcement

Of course not, we just have to go a little further down the applicaton control page and…

Our troubles are over, I thought as I enabled this. However, they weren’t . This didn’t work. Eventually, I admitted defeat and RTFM’d.

OK, how does this look? Defining a port, what protocol to allow on it and what to do if there’s a violation.

Yes, this did the trick and the log in Figure 18 shows this traffic being blocked. Interestingly, the logs stopped identifying the traffic as SSH – I guess all the Forti needed to know was that it wasn’t http and thus not coming through.

Figure 18: Not http on port 80 – not so fast, sunshine.

So to summarise, we had to enable application control, and on the application control profile we enabled ‘Block applicatons on non-standard ports’ and then told the Forti what the standard apps on those ports were.

In my opinion the Fortigate is a very capable Next Gen firewall with lots of great features but for the very specific use case of blocking applications running on non-standard ports it’s easier to do on the Palo Alto where it’s almost harder not to do than to do.