Thursday, December 1, 2011

SSH Proxy - huh?

Burning Firewall
    tl;dr - I was asked to change some file transfers to use the SFTP protocol by our IT department. The IT department actively blocks SSH/SFTP connections and gave me no way to fulfill their request.  

    When I started working at my current company, I was assigned the task of changing some of our file transfers from regular FTP to use the secure SFTP. It's an obvious security enhancement since SFTP encrypts the data as well as the usernames and passwords during transfer.
    I thought this would be a simple task, but it turned out to be a continuing nightmare. You see, our IT department had requested the change, but they gave us no way to actually do it. I found that the company firewall blocks the TCP port that SFTP uses. That was my first clue that something wasn't right. I've never worked at a company that blocks outgoing SSH/SFTP.
    I think it makes some sense to block the port because one can tunnel almost any traffic through SSH. Since it's encrypted, the company can't monitor the traffic through the tunnel. But it makes no sense when you consider that the IT department was the one asking us to change to SFTP when they gave us no way to actually use it.
    Moving on, I found that the company provides an "SSH Proxy" to allow you to SSH anywhere. According to the documentation, they also provided temporary storage on the proxy so that you could transfer files using one of the secure SCP or SFTP protocols. After talking with many IT folks, this proxy was the only supported method I found for accomplishing my task. So I decided to give it a go.
   The proxy was implemented horribly. It would periodically delete all of your files, including any keys. It didn't have a lot of temporary storage space, and it didn't let you run any of your own programs.
    This meant that I had to connect to the proxy, upload all of my keys, upload my temporary file, and then issue the commands to connect to my final destination and then upload the file from the proxy to the final destination. Remember, it wouldn't let me run my own programs, so I couldn't copy a script to this proxy to do this.
    After figuring out how to get this all working, I was told we were going to be transferring a ton of files and that the temporary storage wasn't going to be enough. So I submitted a request to IT to extend the storage space. The request was denied and I was told that the server was not meant to be used for file transfers, even though the documentation explicitly stated it could be used for that purpose.
   There are two interesting things that I see here. One is the prevention of information services by our own IT department. They asked us to change to the SFTP protocol, but gave us no way to do that. Not only that, but they said their own servers weren't to be used for their documented purposes. Isn't the purpose of the IT department to enable other departments to conduct business? They failed miserably.
    The second thing is the use of the term "proxy." A proxy server is one that will perform an action on your behalf. For example, you ask a web proxy to retrieve a web page for you. It will look at its rules and decide if it should and then retrieve the page for you if you're allowed. This "proxy" was not a proxy. I couldn't tell it to transfer a file to a certain server for me. It wouldn't retrieve a file for me either. It is not a proxy, it's much more like a gateway. IT people should know the difference, but obviously our department isn't the brightest bunch.