[beatboxing intro]
>>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 view 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 deprovision 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,
health care 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 deprovisioning.
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 date 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 totalling 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 gonna 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 gonna 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 FTP's 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 gonna be some automation components
involved in this thing,
there's probably not gonna 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 wanna look at having the separate systems,
one for secure FTP and one for file sharing.
The second consideration I wanna 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.