Securing SFTP?
I recently came upon a situation where there was a request to allow an SFTP connection out to the Internet for secure file transfer. 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.
A proxy understands HTTP (including HTTPS as most proxies implement SSL interception) and FTP and can inspect these traffic streams for threats. You can also proxy SFTP (and other things) but need to use the HTTP Connect method or a SOCKS proxy to do this. Both of these methods deny the proxy any visibility of the traffic. First a word on SFTP:
SFTP is not related to FTP – save by the name which is misleading. SFTP (and SCP for that matter) run their file transfer service using SSH. 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.
(FTPS is different again, this is FTP over SSL but I’m not going there)
I googled a bit and found out that Palo Alto did SSH-proxying which sounded promising.
and with this lead I headed to my virtual lab (Well, AWS: I know, I know, but, damn, these cloud platforms are handy)
The Goal
My goal in this lab was to see if I could intercept a dummy virus in an sftp file transfer.
The Lab
Firstly, I needed an SFTP server. In the AWS marketplace I found a pre-baked one:
And as we’re going to take a Palo for a spin, we also need:
I used the lab topology that I have favoured recently. To pad out the blog (and save you scrolling down) reproduced here:
Working from the DMZ windows machine shown, I downloaded my dummy virus file from eicar ( https://www.eicar.org/). I got evidence that this worked fromthe Windows Servers’ pre-installed version of Windows Defender which quarantined the file.
So, after nobbling this…
I downloaded my eicar file again and using the Filezilla SFTP client on the Windows machine. (https://filezilla-project.org/). 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.
OK, time to break out our Anti-Virus on the Palo. 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.
The default AV profile doesn’t actually mention ssh in its decoders but anyway…
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. In the end I unticked all the extra options:
In the Palo, you set up decryption rules to match the traffic you want decrypting (more usually for SSL). So having created my decryption profile I added in a decryption rule as follows:
I set up the default AV profile on my outbound Access rule..
Initially I got this when I tried to commit this policy…
So, note to self, the AWS Palo doesn’t come pre-loaded with AV signatures and why would it?
I went over to the dynamic updates….
…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..
Initially, when connecting from the Windows DMZ server to my SFTP server I saw this in Filezilla…
And this in the logs…
…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). The following log excerpt doesn’t really show that but does show we aren’t decrypting..
This is when my faith in the wisdom of my enterprise began to falter and I fully read the Palo link I’d shared above. (I like to demonstrate to the wisdom of RTFM by generally failing to do so until forced.)
This is the relevant excerpt
When the client sends an SSH request to the server to initiate a session, the firewall intercepts the request and forwards it to the server. The firewall then intercepts the server response and forwards it to the client. This establishes two separate SSH tunnels, one between the firewall and the client and one between the firewall and the server, with firewall functioning as a proxy. As traffic flows between the client and the server, the firewall checks whether the SSH traffic is being routed normally or if it is using SSH tunneling (port forwarding). The firewall doesn’t perform content and threat inspection on SSH tunnels; however, if the firewall identifies SSH tunnels, it blocks the SSH tunneled traffic and restricts the traffic according to configured security policies.
This confused me a little bit. Initially I interpreted it as saying that the firewall can’t inspect SSH but I believe it means you it can’t intercept another protocol tunnled over SSH which is fair enough. Doesn’t that mean SSH and SFTP traffic should be inspected for threats?
I decided to try the decrypt rule with plain old SSH and so spun up an AWS Linux server and tried to connect to this from my Windows DMZ machine. I found I couldn’t connect through the firewall when the ‘ssh-proxy’ decrypt rule was enabled; though could when I disabled this rule. I guess this was because AWS SSH authentication uses the public/private key method rather than a password and the firewall is a MITM. I didn’t dwell on this but it proved the ssh-proxy rule was intercepting SSH (and thus SFTP) and so should have decrypted SFTP.
My conclusions based on the limited time and effort I was able to put in, was that ssh interception didn’t work with SFTP nor with SSH when using public/private key. I was mainly interested in the former use-case. It could be that I’m doing something wrong but there doesn’t seem as if there should be that much to it, following Palo’s how-to.
For some reason, I didn’t find this blog on the same subject written by Phoneboy five years ago when I first searched. Here is his eloquent take on the matter:
http://phoneboy.org/2015/07/29/lies-damn-lies-and-inspecting-ssh-traffic-securely/