Data filter with SSH proxy decryption

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Data filter with SSH proxy decryption

L1 Bithead

So, I would like to be able to enforce file blocking between our external FTP,sftp,scp server that is published in our DMZ. Users coming into the DMZ are NAT'ed from a public IP space to 172.16.0.0/16 space. I have enabled SSH proxy decryption between the outside and the DMZ interfaces and traffic is being decrypted as shown by the traffic logs. I am not however, seeing any file identification occurring between the outside and the DMZ over SSH. I only see ftp file transfers.

  • Is the SSH proxy decryption only used in application identification to identify SSH tunneling? and cant be used in file blocking rules?
  • Do I have my proxy in the wrong place? Should it be between the NAT and the host in the DMZ or between the NAT and the outside?

Anyone have any insight?

1 accepted solution

Accepted Solutions

L4 Transporter

Currently it is possible to tunnel other applications through SSH by enabling port forwarding on SSH. This can be considered a security risk because a user could potentially circumvent the application based security policies on the Paloalto device.
The Paloalto device is able to address this risk with the ssh proxy feature. Via a decryption policy,    you can configure the PA to decrypt a ssh session and if the users does any ssh port forwarding, remote forwarding or X11, the session will be determined to be ssh tunnel. In turn action can be taken on the ssh tunnel application according to the security policies.

It is important to note the following:

1. The same "man in the middle" method for SSL decryption is used for SSH proxy.
2. Also, currently the PA only supports SSH version 2.....(if the client only supports SSH version 1, when it receives the version string from the Paloalto device, it should exit).
3. Content and threat inspection is not done on the SSH Tunnel session.

View solution in original post

2 REPLIES 2

L4 Transporter

Currently it is possible to tunnel other applications through SSH by enabling port forwarding on SSH. This can be considered a security risk because a user could potentially circumvent the application based security policies on the Paloalto device.
The Paloalto device is able to address this risk with the ssh proxy feature. Via a decryption policy,    you can configure the PA to decrypt a ssh session and if the users does any ssh port forwarding, remote forwarding or X11, the session will be determined to be ssh tunnel. In turn action can be taken on the ssh tunnel application according to the security policies.

It is important to note the following:

1. The same "man in the middle" method for SSL decryption is used for SSH proxy.
2. Also, currently the PA only supports SSH version 2.....(if the client only supports SSH version 1, when it receives the version string from the Paloalto device, it should exit).
3. Content and threat inspection is not done on the SSH Tunnel session.

L3 Networker

I am use to Bitvise SSH Server.(Personal version)

and I don't know;;

SSH Server is being normally

SSH2 is right;;

maybe It seems that Supported ciphers

Supported ciphers

AES128 CTR, AES196 CTR, AES256 CTR, AES128 CBC, AES192 CBC, AES256 CBC

Supported message authentication functions

HMAC-MD5, HMAC-SHA1, HMAC-MD5-96, HMAC-SHA1-96, HMAC-RIPEMD128, HMAC-RIPEMD160

I red document SSH tunneling

Do ciphers relative ciphers?

  • 1 accepted solution
  • 3819 Views
  • 2 replies
  • 1 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!