FTP Security
FTP Security Strategies, and Where VitalSigns for FTP Fits In
If you are migrating from standard FTP to a secure FTP environment, VitalSigns for FTP can be a valuable part of your migration strategy. The VitalSigns for FTP 2.0 - SSH Tectia™ bundle provides automatic, transparent encryption of FTP through SSH tunnels and/or dynamic translation of FTP to SFTP.
Also, VitalSigns for FTP's all-seeing eye, coupled with its powerful query engine and its intuitive graphic user interface, allows you to quickly and easily monitor compliance with your organization's security standards.
The common FTP security strategies have very similar names.
This chart explains the distinctions.
VitalSigns for FTP can manage and monitor any file transfer passing through an
IBM z/OS FTP client or server.
SM can monitor any file transfer passing through an
SSH Tectia client, server, or SOCKS proxy.
| Transfer Protocol, Security Strategy |
IBM FTP Supports |
VitalSigns for FTP Manages and Monitors |
Notes |
| Standard FTP | Yes | Yes | See RFC 959 and its predecessors. Data may be encrypted by some other process prior to transfer. |
| FTPS (FTP & SSL/TLS) |
Yes | Yes | Uses standard FTP to authenticate users and send encrypted data by SSL/TLS. SSL is secure socket layer and the "parent" of TLS, transport layer security. See RFC 4217. |
| Secure FTP (send encrypted data through an SSH "tunnel") |
Yes | Yes |
Uses standard FTP to authenticate users and send encrypted data through an SSH "tunnel." SSH is the Secure Shell protocol. See RFCs 4250-4254. VitalSigns for FTP controls z/OS FTP client, redirects transfers through SSH Tectia™ SOCKS proxy and SSH tunnel. VitalSigns for FTP monitors all such traffic. VitalSigns for FTP v2.0, in the SSH Tectia™ bundle, provides easy, browser-based controls for transparently converting FTP transfers to Secure FTP transfers--with no need for revising the JCL in batch jobs. |
| SFTP (SSH file transfer protocol) |
--- | Yes |
SFTP is descended from SCP (secure copy protocol). It uses SSH (Secure Shell) servers and clients rather than standard FTP. See RFCs 4250-4254. VitalSigns for FTP controls z/OS FTP client, redirects transfers through SSH Tectia™ SOCKS proxy. The proxy translates FTP to SFTP. VitalSigns for FTP v2.0, in the SSH Tectia™ bundle, fully monitors SFTP and SCP traffic via SSH Tectia clients and servers. VitalSigns for FTP v2.0, in the SSH Tectia™ bundle, provides easy, browser-based controls for dynamically translating FTP transfers to SFTP transfers--with no need for revising the JCL in batch jobs. |
| Others | --- | --- | Proprietary transfer protocols |
For more information about FTP security, see http://en.wikipedia.org/wiki/File_Transfer_Protocol
For more information about SFTP, see http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/
Securing FTP with z/OS Security Profiles ( RACF, ACF2, or Top Secret )
By themselves, RACF, ACF2, and Top Secret cannot adequately protect against dangerous FTP functions.
Most notably, "read access" means an FTP user can download, duplicate, re-distribute a dataset at will.
VitalSigns for FTP allows z/OS security administrators to add rules to RACF to protect individual FTP server resources and commands. Access can be as global or as granular as the administrator deems appropriate.
Standard RACF rules for dataset access determine whether a user can read a dataset. The original intention was to allow access to information related to the transaction at hand, typically while the user is under the control of a mainframe application. But with FTP, if users can read a file, they can copy it to their PCs and email it anywhere in the world with ease. Standard RACF rules for datasets do not consider that read access allows FTP sessions to offload whole files. Though there is some protection, it falls short of what is needed when FTP is added to the mix.
And FTP can do other risky things besides data transfer.
With a standard FTP session, a client can snoop around the system for private information.
A hacker might, for example, log onto FTP, cd (change directory) to
/u (the directory that often houses user's workspaces), and list the
contents--including several userIDs (directory names associated with the user).
The SITE command also allows for many dangerous operations.
For example, with the FILETYPE=JES, an FTP client can submit jobs
to, and pull reports from, the JES queue.
SITE can also be used to change permission bits for a file,
or to list detailed information about your storage devices.
For these reasons FTP functions need to be treated as a protectable resources, just as datasets are. Although there are some basic protection mechanisms in place, they don't stand up to what is needed for a true enterprise-class secure protocol.
VitalSigns for FTP provides a link between z/OS FTP servers and z/OS security that will deny any specified users access to any specified FTP command.