Cisco Firepower and non-std SSH

At my new place of work I have encountered Cisco’s NGFW offering: Firepower. The firewall policies are administered on an FMC (Firewall Management Center) and pushed or deployed to enforcement modules called FTDs (Firepower Threat Defense) . Instead of FTD’s you can do this on ASAs with an SFR module but I digress . Posts passim will testify that I like to test NGFWs by seeing how easy it is to get them to block SSH running on a non-standard ports.

The setup is the same as I have used elsewhere so I won’t go into great detail: I have a linux host running ssh on port 80 on linux.labtinker.net and I have a host on a DMZ which routes to the Internet through an FTD which will try and access said Linux server on said port using said protocol.

And I’ve got to say It was pretty straight foward. I had the following Access Policy defined on the FMC:

…with these rules…

The FMC/FTD has the concept of a ‘Trust’ action which means the traffic isn’t inspected and the first rule is trusting DNS and NTP (please note – this is not intended as best practice guide – you may not want to trust anything – this is just a guy messing around in a lab) but the next rule is where the action is happening.

So drilling down into the relevant parts of the other rule…

…and where the magic happens…

I have kept things simple in this rule by not using any other available features such as decyrption or an IPS policy.

So from my DMZ host trying to login to the ssh server through the FTD I’m not getting any joy…

… and checking in the FMC’s logs…(Analysis/Connection Events):

so full marks. Out of interest I went back to the above rule and changed the application part as follows:

and then re-tested and I was able to login straight away

And we can see this connection allowed in the logs together with the previously blocked traffic:

The protocol is no longer recognised – presumably because we are no longer doing application inspection.

On first blush, I’ve found a few things about Firepower a bit clunky compared to other NGFWs but in terms of ease use defining rules to allow/disallow applications I’d think it’s second only to the Palo’s which gives us a current league table (assembled from previous labs) of:

1/ Palo Alto 2/ Cisco Firepower 3/ Fortigate 4/ Checkpoint 5/ Cisco ASA