{"id":107,"date":"2020-05-23T17:46:19","date_gmt":"2020-05-23T16:46:19","guid":{"rendered":"http:\/\/www.labtinker.net\/?p=107"},"modified":"2020-05-23T17:46:19","modified_gmt":"2020-05-23T16:46:19","slug":"palo-alto-and-non-std-ssh","status":"publish","type":"post","link":"http:\/\/18.135.13.153\/?p=107","title":{"rendered":"Palo Alto and non-std SSH"},"content":{"rendered":"\n

Initially, I wanted to explore the ways that different models of Next Generation firewalls defeat (or not) the simple tunnelling scenario of the previous labs (see ‘SSH forwarding’). <\/p>\n\n\n\n

In fact, I didn’t really get much further than looking at running applications on non-standard ports but it shows a little of the application awareness abilities of a next-gen firewall, in this case a Palo Alto.<\/p>\n\n\n\n

As I didn’t have a physical Palo to hand the one I used is the model available in the AWS marketplace<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

(At first, I tied myself in knots setting this lab up in AWS after forgetting how routing works there and will maybe put together a note on this later )<\/p>\n\n\n\n

For the firewall’s configuration, I tried to use as basic an out-of-the-box set-up as possible. The OS version in case you can’t see it above is 9.1.2<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Going into the full configuration options on each model or vendor is beyond the scope of the this post so I will only touch on them where they are relevant to the scope of the lab.<\/p>\n\n\n\n

The Lab setup is as follows…<\/strong><\/p>\n\n\n\n

\"\"
Figure 1: Topology<\/figcaption><\/figure>\n\n\n\n

The Windows host is on a DMZ with an address of 172.31.200.10, the Linux host on the Internet and our trusty Palo sits between them. It is in turn is configured thusly:<\/p>\n\n\n\n

We have a source NAT rule to hide our outbound traffic behind the firewall\u2019s external interface in common with almost every firewall that connects to the Internet. The actual configuration is shown here:<\/p>\n\n\n\n

\"\"
Figure 2: Palo NAT Tab 1<\/figcaption><\/figure>\n\n\n\n
\"\"
Figure 3 Palo NAT Tab 2<\/figcaption><\/figure>\n\n\n\n

We have the following access rule named ‘Windows Out’ (for those without a magnifying glass) which is allowing any traffic out from the Windows Host on the DMZ zone to the External zone which leads to the Internet. This being a stateful firewall it will allow traffic back in if it is return traffic from the outbound session.<\/p>\n\n\n\n

\"\"
Figure 4: Let it all out…<\/figcaption><\/figure>\n\n\n\n

Tunnelling Out<\/strong><\/p>\n\n\n\n

The linux host linux.labtinker.net<\/em> has an ssh listener listening on tcp port 80 which we will connect to from the Windows host as a precursor to tunnelling back in (spoiler alert – we’re not going to get as far as tunnelling back)<\/p>\n\n\n\n

I’ve realised it is difficult to show the log screens in any detail so will capture the relevant bits… when our Windows host tried to ssh out to linux.labtinker.net<\/em> on port 80 the traffic was denied.<\/p>\n\n\n\n

\"\"
Figure 5: Oh no you don’t.<\/figcaption><\/figure>\n\n\n\n

The log shows the traffic is hitting the \u2018default\u2019 deny rule and falling past our \u2018Windows Out\u2019 rule. It\u2019s not immediately clear why this is as the source and destination ip addresses are both allowed by the ‘Windows Out’ rule.<\/p>\n\n\n\n

However, in my rule I have selected any \u2018application\u2019 but not any \u2018service\u2019. The distinction is important. <\/p>\n\n\n\n

I stipulated that any application should be allowed out. However, on a Palo the service (port) associated with an application is defined separately, and the default option for this setting is \u2018application default\u2019.<\/p>\n\n\n\n

\"\"
Figure 6: Application Default<\/figcaption><\/figure>\n\n\n\n

This means is that application traffic will only match the service portion of the rule if is using the application’s default port which for ssh is tcp 22, for http is 80 etc.<\/p>\n\n\n\n

We were trying to use tcp port 80 for ssh which is not the default port for this application hence we fell foul of this part of the rule and our trafffic was blocked.<\/p>\n\n\n\n

Let\u2019s test this further in two ways: first by changing the ssh listener on linux.labtinker.net<\/em> back to the standard tcp port 22 and trying to connect and secondly by reverting the ssh listener to port 80 and changing the Palo’s rule to allow the application to be accessed on any service (port) not just the default one.<\/p>\n\n\n\n

Test One<\/strong><\/p>\n\n\n\n

OK, Scout’s Honour, nothing changed on the rule but running the traffic over the correct port allowed it to sail through…<\/p>\n\n\n\n

\"\"
Figure 7: SSH on its default port.

<\/figcaption><\/figure>\n\n\n\n

Test Two<\/strong><\/p>\n\n\n\n

And then changing the service in appropirate rule from ‘application default’ to ‘any’ and re-setting the ssh listener back to tcp port 80.<\/p>\n\n\n\n

\"\"
Figure 7: Set service to ‘any’<\/figcaption><\/figure>\n\n\n\n

We are able to connect to linux.labtinker.net<\/em> on ssh over tcp port 80<\/p>\n\n\n\n

\"\"
Figure 8: SSH on its non-default port<\/figcaption><\/figure>\n\n\n\n

Applications not Ports<\/strong><\/p>\n\n\n\n

Palo Alto typically espouse using applications in the firewall’s rules rather than services (ports) but as has been demonstrated even if you do use services the \u2018application-default\u2019 settting would give you some protection.  <\/p>\n\n\n\n

A best-practice Palo Alto rule to allow outbound browsing would use the application \u2018web-browsing\u2019 for clear text browsing in conjunction with application ‘ssl’ to allow https. (DNS would also be required but probably to specific destinations) – and of course the rule(s) would have ‘application-default’ specified for the service.<\/p>\n\n\n\n

\"\"
Figures 9: No ports please, we’re Next Generation!<\/figcaption><\/figure>\n\n\n\n

I didn’t get around to seeing if tunnelling back over ssh would work but then it seems a bit moot if you’re defeated getting out of the enterpise using a port that would be allowed (even the most slap-dash outfits wouldn’t allow port 22 out)<\/p>\n\n\n\n

In the next couple of posts I’m going to compare a couple more NG firewalls and see how they fare in a similar set up.<\/p>\n","protected":false},"excerpt":{"rendered":"

Initially, I wanted to explore the ways that different models of Next Generation firewalls defeat (or not) the simple tunnelling scenario of the previous labs (see ‘SSH forwarding’). In fact, I didn’t really get much further than looking at running applications on non-standard ports but it shows a little of the application awareness abilities of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-107","post","type-post","status-publish","format-standard","hentry","category-firewalls"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/107","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=107"}],"version-history":[{"count":0,"href":"http:\/\/18.135.13.153\/index.php?rest_route=\/wp\/v2\/posts\/107\/revisions"}],"wp:attachment":[{"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=107"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/18.135.13.153\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}