1 February 2022

Cisco ASA and non-std SSH – the reprise

By admin@labtinker.net

Any readers of this blog will possibly remember that I compared a few different vendors’ firewalls to see how easy it was to configure them to block ssh access when it was running on the non-standard port of tcp 80 which is typically used by http. (This is a little contrived because anyone trying to get out like this would probably use tcp 443 giving us the complication of encryption but it gives a feel for how easy it is to configure application inspection)

During this process I had problems with the Cisco ASA and disqualified it from my trial. However, would you believe I have had countless emails asking me when I would give it a second chance? No, neither would I. Nonetheless I decided to revist the ASA.

This is the topology:

The stages of the test will follow the trials conducted earlier. We will set up the firewall with a rule allowing port 80 or http traffic out from the DMZ and stand up a server running ssh on port 80 (ssh.labtinker.net). We will then see if we can ssh out through the firewall on port 80 from the linux server running on the DMZ.

I can report that with a rule allowing http (amongst other things but not ssh!)…

I was able to connect straight away to my ssh server.

I knew the ASA already did some from of application inspection out of the box using its default global service policy but checking this out I saw that it didn’t cover http

I added ‘http’ to this policy

I then tried my ssh connection out on port 80 and it was still allowed…. I won’t bother with the visual evidence this time but obvioulsy the default http application inspection didn’t stop ssh.

I realised I was going to have to delve into modular policy framework which is what Cisco uses to do application inspection (amongst other things). I never found it hugely intuitive so I determined that I would satisfy myself that I could get it working before trying to use it to block ssh. I chose as a way of doing this allowing access to www.labtinker.net but blocking access to www.labtinker.co.uk; mainly because someone had already given an example of how to do something similar.

To avoid confusion, I deleted the default service policy (the joy of a lab – I would advise against this generally!!) then created a policy which would check the http host header for the presence of the text labtinker.net and only allow a connection if this was present…

I achieved this as follows…

….a global rule service policy rule matching all http traffic…

Which in class maps is defined as follows..

The CLI config for this being…

class-map type inspect http match-all class-http1

 match not request header host regex urlallow1

class-map dmz-class

 match port tcp eq www

class-map match-all

!

policy-map type inspect http policy-http1

 parameters

 class class-http1

  drop-connection log

  regex urlallow1 “labtinker\.net”

Which in action, is demonstrated by trying two curl commands from DMZ linux…

This is a curl connection to www.labtinker.net which shows the start of the successful HTTP GET

…as logged going through the ASA…

And now trying www.labtinker.co.uk

The connection is dropped by the inspection engine.

So I know that the ASA is inspecting my http connnection. However, it still allows my ssh connection through on port 80.

Then, in here…

I found this…

…which had this….

So I ticked it… and ASDM generated these CLI commands…

That had to be it, didn’t it? Ladies and Gentlemen, it was!!

And in the logs…

So the ASA can be configured to drop non-http traffic on port 80. I then decided to remove the http inspection checking the header text so I could allow all http traffic out but block ssh.. (and presumably anything else not http)

…and I could make curl connections to www.labtinker.net and www.labtinker.co.uk and any website but I still could not ssh out on this port 80… result!

I apologise for taking such a circuitous route to find out how to do what I set out to but I genuinely couldn’t find much in the way of guidance so I offer this up… as an untidy but successful example.#

I guess the ASA is creaking as it’s not an NG firewall and that this kind of thing would be done in Cisco’s FMC / FTD offfering. I’ve been out of the Cisco space for a while and it doesn’t seem that easy to get hold of an eval VM outside of a contract to play around with this… but I’ll hopefully be getting up to speed on this area fairly shortly as my new role calls for it!