[ISN] When is secure FTP not secure? When it reaches your network

[InfoSec News]

http://www.computerworld.com/securitytopics/security/story/0,,96265,00.html

Advice by James King
ID Analytics Inc.
OCTOBER 01, 2004 
COMPUTERWORLD

It's widely accepted that file transfer protocol (FTP) is the simplest
way for organizations to send data across the Internet. To enhance
security, many companies now use sFTP or FTP/S, the "secure" forms of
FTP, believing that data traveling across this protocol is safe.

But is it?

It's true that secure forms of FTP have additional encryption while
commands and data are in transit across the Web. But it's commonly
overlooked that while files are indeed secure during transit, they are
nonetheless extremely vulnerable for the period of time they reside at
the Internet-facing, final point of handoff at the edge of the
receiving network. Due to limited Internet bandwidth and large file
sizes, it will always take some amount of time for this final transfer
because a software program or script at the receiving end must wait
for the download to be complete before securing the entire file inside
the interior firewall.

Imagine a pipe carrying water to a bucket. Though the pipe holds the
water securely, the bucket can't be secured until it's filled with the
water it's waiting for. The larger the file, the longer the transfer
takes. The longer the transfer takes, the greater the vulnerability.  
The exposure is due to new vulnerabilities discovered, seemingly
daily, within operating systems. If a hacker can gain access to the
operating system, any files on the computer's disk are available to
him. If the files on the disk aren't encrypted, you have made the
hacker's day.

In an environment where security breaches have become so commonplace
that legislation such as California's Senate Bill 1386 makes companies
even more liable for data security violations, greater measures of
protection are needed. Hackers only need one part of the file to do
their dirty work. All it takes is one stolen Social Security number
from a customer for your company to be at risk.

Here are some measures that IT managers and network architects can
take to better ensure data security:

1.) Install a dedicated transfer server in a true DMZ with equipment
from different manufacturers, Perhaps the most common method for
supporting automatic data transfer is to add this duty to an existing
internal server and present the server to partners through the
external firewall via network address translation.  Unfortunately,
this is also the most insecure method. If the single firewall is
compromised through a known vulnerability or if the server is
compromised through the protocol used for data transfer, the entire
network segment where the servers are located is exposed. Isolating
the data-transfer duty to a server that isn't multipurposed, being
sure to disable any unnecessary services, reduces the number of
potential vulnerabilities, but the internal network is still
vulnerable.

The best method to minimize risk is to create a true DMZ by using two
firewalls, each with two interfaces to keep the Internet-facing
firewall completely separate from the firewall facing the private
network.

Also, most organizations source their firewall equipment from a single
manufacturer. However, newly discovered vulnerabilities often affect
entire ranges of a manufacturer's products. Ideally, the two firewalls
in this scenario will be sourced from different manufacturers because
it's rare for new vulnerabilities to be effective across platforms.


2.) Establish strict rules at the firewall. A good beginning rule set
for the exterior firewall would be explicit denial of access to all,
but with implicit access to well-known clients and partners. The
interior firewall rule set should explicitly deny all access,
including access from the FTP server in the DMZ. Any processes waiting
for files from the outside must reach out through the interior
firewall and pull files in from the sFTP server.


3.) Require a key exchange for connectivity. Secure FTP provides
functionality allowing access only to outside contacts with a valid
cryptologic key. This eliminates the need for a user ID and password
log-on. The key may also be capable of differentiating individual
computers accessing the sFTP server from within a client organization,
where there otherwise may be only a single log-in ID or IP presented.  
If key exchange isn't possible, require the use of strong passwords,
meaning those with an eight-character minimum length, required mixing
of upper and lower case, and inclusion of punctuation marks. Don't
reuse passwords, and change them frequently.


4.) Encrypt, encrypt, encrypt. One of the most important measures is
to require exchange of public encryption keys and encrypt the data
files that will be transferred. Many programs are available for this
level of data encryption in both the commercial and public domains,
including Pretty Good Privacy and the GNU version, GPG. An additional
bonus of encryption is that almost all of today's encryption programs
also include file compression.


5.) Exercise additional caution when using FTP/S. FTP/S uses a Secure
Sockets Layer (SSL) wrapper around an FTP server or client to encrypt
the log-in and data exchanged between them. But differences in the
various SSL implementations and versions used can result in
incompatibilities and failures between server and client software. If
the initial SSL authentication between two SSL implementations fails,
they will often fall back to sending the user log-in and password as
clear text rather than fail the log-in. This allows the FTP user
log-in data to be clearly read by anyone monitoring the traffic. Oddly
enough, once the clear-text log-in is authenticated, the data transfer
itself will be encrypted.

So the rule is: Check the log files, since this is the only place
where this particular failure will show up, especially because your
outside contacts can change implementations of FTP/S without your
knowledge. If possible, configure the chosen FTP/S server or client to
deny or fail the log-in if the initial SSL authentication fails.


6.) Stay current with the latest operating system patches. FTP
programs are implemented on a number of platforms, including Windows,
Linux, Solaris and many flavors of Unix, so attentive daily updates
are essential.


7.) Look for security holes, especially by frequently checking logs.  
Even with all the latest technology in place to protect data,
vulnerabilities can exist. It takes smart people vigilantly applying
investigative skills to keep a network truly secure.


In a world where new vulnerabilities appear daily and where the rate
of litigation increases as rapidly as computing power, it's imperative
to secure your data transfers with clients and business partners.  
Fortunately, a straightforward architectural approach to systems and
process design can mitigate most of the risks.

Employing the strategies outlined here will make it much easier for IT
and security professionals (and their executive management) to sleep
at night, knowing that their data is as secure as possible.


James King is vice president, engineering and operations, at ID
Analytics Inc., a San Diego-based vendor of identity management
products and services.