#Palo ssh proxy update#
#Palo ssh proxy windows#

…so I adjusted my SSH Proxy profile as detailed above and pressed on whereupon I was able to connect successfully to the server, (good) and transfer my eicar profile (bad).

#Palo ssh proxy windows#

Initially, when connecting from the Windows DMZ server to my SFTP server I saw this in Filezilla… Figure 17: Filezilla error.Īnd this in the logs… Figure 18: Unsupported ssh

#Palo ssh proxy update#

…restored an AWS Elastic IP address to my Palo’s managment interface (where the update traffic originates from) and then downloaded and installed the AV sigs. So, note to self, the AWS Palo doesn’t come pre-loaded with AV signatures and why would it? Initially I got this when I tried to commit this policy… Figure 14: Ooops I set up the default AV profile on my outbound Access rule. So having created my decryption profile I added in a decryption rule as follows: Figure 8: Decrypt rule source Figure 9: Decrypt rule destination Figure 10: Decrypt rule port Fig 11: Decrypt Options In the Palo, you set up decryption rules to match the traffic you want decrypting (more usually for SSL). In the end I unticked all the extra options: Figure 7: SSH Proxy in Decryption Profile. OK, in the decryption profile for ‘SSH Proxy’ I initially ticked all the boxes, as you do, but this caused issues (see later) possibly because I was using SFTP – I don’t know. The default AV profile doesn’t actually mention ssh in its decoders but anyway… Figure 6a – Palo’s default Anti-Virus profile. Now there was bit of faffing around with this which I will reproduce here as if I need to do this again I can remind myself of the loops I had to jump through. OK, time to break out our Anti-Virus on the Palo. Figure 6: Copying a normal and dummy virus file to SFTP server. I connected to my SFTP server and copied up a copy of a normal text file (so good, it was suffixed twice) and my dummy virus file (eicar.txt) with no problem. I downloaded my eicar file again and using the Filezilla SFTP client on the Windows machine. So, after nobbling this… Figure 5: Down, boy! I got evidence that this worked fromthe Windows Servers’ pre-installed version of Windows Defender which quarantined the file. Working from the DMZ windows machine shown, I downloaded my dummy virus file from eicar ( ). To pad out the blog (and save you scrolling down) reproduced here: Figure 3: Today’s lab I used the lab topology that I have favoured recently. In the AWS marketplace I found a pre-baked one:Īnd as we’re going to take a Palo for a spin, we also need: Figure 2: Firewall du jour My goal in this lab was to see if I could intercept a dummy virus in an sftp file transfer.įirstly, I needed an SFTP server. I googled a bit and found out that Palo Alto did SSH-proxying which sounded promising.Īnd with this lead I headed to my virtual lab (Well, AWS: I know, I know, but, damn, these cloud platforms are handy) (FTPS is different again, this is FTP over SSL but I’m not going there) My confusion on this matter was cleared up by the book ‘SSH – The Secure Shell’ by Barrett, Silverman and Byrnes published by O’Reilly): a refreshingly dead-tree reference for you that goes into much more detail. SFTP (and SCP for that matter) run their file transfer service using SSH. SFTP is not related to FTP – save by the name which is misleading. Both of these methods deny the proxy any visibility of the traffic. You can also proxy SFTP (and other things) but need to use the HTTP Connect method or a SOCKS proxy to do this. My previous posts have been concerned with stopping SSH tunnels on non-standard ports but some may have viewed this as an academic exercise as most enterprises insist outbound connections are made through a proxy server.Ī proxy understands HTTP (including HTTPS as most proxies implement SSL interception) and FTP and can inspect these traffic streams for threats.

I recently came upon a situation where there was a request to allow an SFTP connection out to the Internet for secure file transfer.