SSH decryption policy

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

SSH decryption policy

L4 Transporter

Hi All,

We have recently deployed PA devices in our network as IPS. We have configured SSH proxy and provide an exception with negate policy for the hosts. I have a basic question regarding decryption rule. I am assuming all rules work like firewalls with src zone + hosts (if any) + dst zone + dst hosts (if any) and services. Is it true for decryption policies as well? We have configured policy to bypass SSH proxy and add src OR dst with "negate" checked. The policies were configured by someone else but I am somehow confused as I am believing that the policy works as src and dst and not src or dst. Please help me understand.

1 accepted solution

Accepted Solutions

L6 Presenter

Stuff in the same decryption policy works as AND, while compared to a different policy it works as OR.

So it should be the same execution path as security policies have regarding top-down first-match.

A tricky part when it comes to decryption policies might be the "allow encrypted traffic" which a rule can have in case it cannot decrypt the matching traffic.

If a session (or packet) matches your particular decryption rule and "allow encrypted traffic" is not set then the flow will be blocked.

View solution in original post

8 REPLIES 8

L6 Presenter

Stuff in the same decryption policy works as AND, while compared to a different policy it works as OR.

So it should be the same execution path as security policies have regarding top-down first-match.

A tricky part when it comes to decryption policies might be the "allow encrypted traffic" which a rule can have in case it cannot decrypt the matching traffic.

If a session (or packet) matches your particular decryption rule and "allow encrypted traffic" is not set then the flow will be blocked.

L4 Transporter

For my own sanity, I've never used the negate box.

In the scenario, I would create a policy with the exception list as a "no-decypt" and place it above the decryption rule.

Thanks. The policy had been configured by different admin and hence I am tying to understand. Yes it makes sense and easy to have two policies with one for SSH proxy and another for bypass. Do you seen any issue with negate? I guess the same policy is acting like SSH proxy all except the negates hosts.

I am new to Palo Alto firewalls but from firewall experience even I think the policy works with src and dst. I have also opened up case with support and waiting to get confirmation.

It really just comes down to preference. It should work either way, but if someone comes in behind to troubleshoot an problem, it's easier to understand the no-decrypt versus the negate visually.

L4 Transporter

Coming to my original question.... How do you read policy below?

Zone Trust -> Src A + B (negate) -> to Zone Untrust Dst X, Y , Z (negate) -> Decrypt -> Type SSH proxy

I find it harder to read...

But my intepretation is:

srczone: trust

dstzone: untrust

srcaddress: any but A or B

dstaddress: any but X, Y or Z

unless you meant that you negated B and Z only and not all the selected ip/ranges :smileysilly:

Basically the host are added (negate) to bypass the SSH proxy. Everything is working fine. But I was only confused on how it is interpreted. Is it src "and" dst negate pair OR src "or" dst negate individual hosts. Since it is working I am assuming that for negate it is not considering src and dst pair like standard policy.

T

  • 1 accepted solution
  • 3134 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!