Securing FTP and File Sharing

Hello and welcome to SolarWinds THWACKCamp. This session is about securing FTP and file sharing with your host, Jonathan Lampe, PMM for the Serv-U Managed File Transfer product. Today we're going to look at exactly three things. First of all, how to make FTP safer and easier to use. Second, how to secure ad hoc file sharing. And third, talk about some of the deployment best practices you can use to keep your deployment safe.

First of all, let's talk about why people use FTP in the first place. The short answer is that it really solves a very common business need at an affordable price. It's often used to batch work up. Whether that's timesheets. Whether that's, let's say, batches of scans. In the old days, that would be banks with things like teller registers. Whatever that bundle of work at the end of the day, at the end of the period is, very often ends up in a Zip file or other bulk data collection that people just put up on a server and let the next person in the business process pick up and use. The nice thing about that is that it rarely requires any type of programming. These aren't detailed transactions that require programmers and implementation teams and everybody to get involved at each end. It's just a bunch of files that everybody knows how to deal with--or at least the applications that you depend on, know how to import and export.

FTP is universal these days. There are hundreds of FTP clients you can get, including SolarWinds' own FTP Voyager for free, and most major web browsers also support the protocol. It's also built in as a command line utility to billions of deployed computers, whether that's Windows, Linux, Mac, whatever. FTP is also capable of handling files of any size. Those of you, especially dealing with media, dealing with large videos, VMware images, database backups, anything that generates a huge file, may have already encountered browser upload limits, either the 2GB or 4GB limits coded into the browsers--or just basic operational limits in terms of trying to upload, let's say, a 500MB file, and having that file consistently bomb out at 100MB or so.

So FTP over the years has grown functions to allow orderly resuming, to check the integrity of a file, to make sure that those 500MB, or those 2GB, whatever it was that you sent are exactly the same thing on both sides. But there are some ongoing concerns about FTP, and we have to address those. First of all, end users, of course, have the whole ease of use problem. Not everybody has an FTP client, or knows how to use one. And certainly many end users are not going to be comfortable dealing with a command line utility. Furthermore, system administrators are very concerned about things like security with plain old FTP that happens in clear text, and just the administrative workload of having to setup and de-provision all of these users.

But there have been many improvements on plain old FTP over the years, starting with security improvements. We have, now, FTPS, which secures in transit using SSL and TLS. We also have SFTP, which is part of the SSH protocol. Both of those secure both credentials and data, which is something that FTP by itself of course, cannot do. And this is something that, really, the demand started over in the banking industry, healthcare certainly with the HIPAA, energy, in terms of trying to keep their assets protected. And basically, it's migrated to be a concern of every industry, every corporation that wants to keep its data secure. You absolutely have to move your stuff across encrypted these days.

The other issue that people have encountered, especially if they're working with firewalls, is that FTP uses multiple ports for data transfer. There's that 21 port that's used to establish that control connection. But then there's also these higher ports that get involved, somehow someway. The good news is, as FTP has matured, it's basically battened things down so you can have a fixed range of high passive ports in terms that basically limits what you have to open up for FTP and FTPS. And of course, SSH really only has one open port. Take a quick look at, for example, the Serv-U Firewall guide here, and you can see those ports listed: clear, FTP, FTPS, FTPS data, and SFTP, as well as some other ports we'll talk about in just a minute.

The next issue I wanted to address is that FTP requires a lot of user account administration. Creating those users, taking down those users. To eliminate a lot of that hassle, FTP servers, again especially SolarWinds Serv-U, they can use existing Active Directory credentials instead. So any user that's in on the system, or subsets of users, can use the server right out-of-the-box without having to do that extra user provisioning on the FTP server itself. And furthermore, for those external users, or the users that have to be defined on that box--the server, the software, the interfaces--they can all support basic things such as user password resets, user reminders via email, and some of those basic tools that keep you out of the daily administration of user provisioning and de-provisioning.

And the last thing to talk about here is that FTP servers no longer require an FTP client. For example, on the Serv-U system, it has a built-in web interface. And this web interface allows you to quickly click onto the server, be able to take a look at exactly the same folder structure that you would if you were looking at an FTP client, with much the same feel including right-click menus and the ability to take a look at images online as thumbnails.

The next thing I would like to talk about is ad hoc file sharing, which is a little bit different that FTP. In fact, it's a lot bit different, because you have people at either end of the exchange here. And in many cases, these people are your end users. And in this case, you may have people, let's say they want to send somebody else a huge spreadsheet they've been working on, but it's too big for the email server. Or you may want somebody to request that they scan in a document and send it back knowing that that's too sensitive to be lying around an email server. In both cases, we have a common need that's grown up, and a number of third-party file sharing sites have grown up with it. All of these sites essentially use the same process here. If you're sending a file, that person goes to the site, uploads the file. That site automatically sends an email with the link. The recipient clicks that link and downloads the file. You're done. You've sent that file; you've got that big spreadsheet all the way through.

Requesting files, similar operation. The requester goes to the site, requests from a recipient, “Please send me some files.” The site will generate an email, the person at the other end will open up their invitation, upload files to the file sharing site and that, of course, just like the first operation, sends that original requester an email with the link. They click the link; they download the file. This type of process is used across the industry. It's not specific to SolarWinds. What we did, in Serv-U file sharing, is we brought it into the product. And we'll see that in just a second.

So again, going through the reasons why people look at this. Large attachments on email servers are often banned, or people may know that email servers do have some insecurities, either through some of the data storage, or because they're unsure exactly which server may have it in transit. Second reason is, of course, some of the administrative hassle for the FTP servers. It may be too much work, either perception by the end user or actually felt by IT administrators. Maybe too much administrative hassle to set up a different FTP share for every group or every type of transaction that has to take place. So with file sharing, you have end users in control of who gets the files, and also in control of who they request files with. They can do all of that. They're essentially doing provisioning without having any administrator involved.

Of course, this interface is also web-based which lets everybody use it. Everybody knows how to do web browser by this point, everybody knows how to get onto these sites, and everybody knows how to send files, especially if they know how to send email using most of the web clients. The biggest problem with this technology, of course, is that there are real concerns about loss of control. Whether that's because there are sensitive business documents, let's say an entire list of your sales contacts, whether that's personally identifiable health information flying around, whether that's other information that's protected by specific regulations or compliance mechanisms, let's say PCIDSS, may have some credit card data in it, and whatnot. In many cases, you just don't know if that data is being sent through third-party websites. And because users have no alternative, they use those sites. What the Serv-U Manage File Transfer System does is essentially gives your end users the same functionality that they experience on third party sites, but you get to deploy it in your data center. Which is huge because you get to apply your security policy. You get to use all of the procedures you normally use. You certainly get to use all of the great SolarWinds software you already use to monitor, regulate, control, all of the data, all of the systems, all of the networks that this passes through. It brings a very common piece of functionality, the file sharing, into the data center.

Now I know you are itching to see what this looks like in person, so I am going to bring up a demo. What we're looking at is the Serv-U file-sharing interface. We have here a list of requests that have gone out. For example, I need some website images for my homepage. So I sent that to two people, they haven't sent it back to me yet. Here's another request. I'm looking for marketing materials. I sent that to Jane Doe, she was kind enough to receive my invitation, and she has sent me back three files totaling 54 kilobytes.

Similarly, on the sent files, I've sent a number of files. Let's go here to product logos for marketing. Here. This one's expired. That's another good benefit of all the file sharing metaphors; they only live for a certain amount of time. So let's say that this was sensitive content. Seven days, ten days, whatever we can figure, it's gone. It's not sitting on the server where some other interested party, nefarious party, would be able to get on the server and go get it. It's gone.

Product badges, images for review. We're going to take a quick look at this one. There's five files in there. Drill down, and then what you see here is this is the actual link that gets sent to your recipient. They get this link in an email; they put it into their browser. Just by clicking on the link, they put it in their browser. And then they may have to enter a password if the original sender has put one on. Or, they may be able to come in directly to an unprotected share. And so a couple of configuration options we'll take a look at in just a second here. This particular case, just going to send a quick file to myself. I could put some more comments in here, in the interest of time I won't. I only want this thing to live two days. I want to be notified when the files have been downloaded. I definitely want to send the download link to the person who's going to receive these files. And I could also specify that I want to put in a password. Once I have told the system who I'm sending it to, I have the ability to upload files. I hit upload, the link is sent, the other person gets that email, and they immediately can download the file as much as they want.

Similarly, I could post a request files, and this looks amazingly similar to the send-files operation. The one thing that's going to change here is that when I get down to the bottom, I don't have an upload button here; I have a send request. So again I could specify, please send me... This goes out to the other person. They have to respond. Let's say, in this case it's urgent--in four hours. And again, I could require them to put in a password before they are allowed to upload anything so I have some idea that they are who they should be. Again, if you know how to send email through a web interface, you probably know how to send a request files through the Serv-U interface.

Now when you're configuring file sharing in Serv-U MFT server, you turn it on. It's literally one check box in a tab called file sharing, and that immediately puts up the end user interface that you see there. Two other things that you'll have to encounter, and this will be no surprise to anybody who's worked with web applications at all, is that you'll need an SSL certificate, hopefully some sort of a CA-signed certificate if you're working in a commercial environment, and then also an SMTP server. You have to put in some access codes, tell it where that server is of course. So those email notifications, which are a critical part of file sharing, get where they need to go.

The last major section I wanted to cover here was some defensive deployment. Best practices, essentially, about how you should be deploying Serv-U MFT server, or really any FTP server, to get the most security you can out of your deployment. The first thing I wanted to look at is considering separate systems for your secure FTP functions and your file-sharing functions. Yes, Serv-U Managed File Transfer Server can do it all. It's an all-in-one server; you could put it all on one server and just fire away. The reason I see many people in the field split this up into two functions, is that they really have separate business purposes. Your secure FTPs are very often tied to automation, they're very often tied to a business process with an SLA that says if I get this file at four o'clock, I'm expecting a file back at seven o'clock. It's very often tied to time-sensitive items, and it also has different firewall rules. Remember the high ports for FTP. Remember the SFTP requirement, as well as the basic FTP requirement. There are often a lot more ports open to your secure FTP server than there would be to your HTTPS-only file sharing server.

The second system, now that we're talking about file sharing, that's basically there to help end users send files to other people. Not a whole lot of SLA activity associated with it. In fact, from a technical point of view, there's really just one large folder with files in it, sub-folders of course within that, but basically there's just one large file share that can be anywhere on your system. And those files are going to be there for a short, defined period of time, and then blown away. But it's basically there just to help your end users send files. There's not going to be some automation components involved in this thing, there's probably not going to be SLA-dependency turnaround.

But basically, if you find yourself in a situation where you do have those functional differences about how those systems are used, especially who's getting in there and using it, you may want to look at having the separate systems, one for secure FTP and one for file sharing. The second consideration I want to talk about is high-availability deployment. And I'm aware that these days, you're very often looking at a situation where you have high availability that's covered by your virtualization technology, or the underlying technologies below the operating system. But Serv-U Managed File Transfer Server can also--especially in the case where it's being used for secure FTP--can rely on some common authentication like Active Directory, like an external database, like an LDAP server, can ride on some common authentication sources and some common storage. Again, these are things that are going to be defined by Windows shares, CIFS shares, and you can use those two technologies, the share authentication and the shared storage, and build a web farm cluster of Serv-U MFT for secure FTP on top of that.

Now the last thing I wanted to talk about under defensive deployment is the case where you need to keep data at rest, out of a DMZ, or terminate connections on your DMZ. In those cases, you typically are going to know that you have these requirements. First of all, you have had to build DMZ, either because your security policy required it, because your subject is something like PCIDSS that leans toward it. But if you have an existing DMZ, and you use things like web proxies in it, you use things like email forwarders in it. If you have that type of arrangement in it, you're probably going to be looking at a technology that's the Serv-U Gateway or something very much like it. So that your incoming connections get safely terminated in the DMZ, and then the Serv-U server, which would then be physically deployed on your internal network, never actually has to have connections coming into it from the Internet.

Two things happen with that. First of all, the connections that come into the Serv-U Gateway, it's not as if they're dropping files, they're picking files up off of the Serv-U Gateway itself. Those connections are actually streamed, and streamed safely, between the Serv-U Gateway and the Serv-U system. And how that happens is essentially, Serv-U signs onto the Serv-U Gateway. So outgoing connection from your internal network to the DMZ--it opens a connection that way, and some helper connections in the same direction. And basically, you have a pool of existing connections, incoming connections to Serv-U Gateway; ride those connections in through Serv-U, and basically providing you the protection so that you never have to have any connections from your DMZ segment to the internal network.

So again, we just talked about using Serv-U and a secure solution for FTP and file sharing, and we saw a little of its ease-of-use in the demos. And since it's from SolarWinds, you know it will be affordable. With that, I want to thank you for attending another THWACKcamp presentation, and invite you to continue your exploration of secure file transfer in the Serv-U section of SolarWinds.com and THWACK.com.