Channels ▼
RSS

Security

Secure Data Exchange with Mainframes Under z/OS


FTPS Clients

Unfortunately it is hard to find suitable clients to connect to z/OS from other platforms: (1) Not all FTP clients support FTP over SSL/TLS. (2) FTP clients have often problems in accessing files which are not on Unix or Windows filesystems. The shareware program WS_FTP did encounter neither problem (1) nor (2) in connecting an z/OS mainframe in our tests. Another good choice is the open-source program lftp. It supports TLS/SSL and it deals well with MVS data sets. The only problem was that it cannot change the current working directory because lftp doesn't understand that a path like 'SYS1' is absolute. Multiple tries of cd 'SYS1' result in a long chain of 'SYS1.SYS1.SYS1...'. This is only a little problem because full path addressing in ls, put and get works fine in lftp but needs "special" quoting. For example a command:

ls \'SYS1.\'

in lftp is equivalent to a

LISTCAT LEVEL('SYS1')

in TSO. Apart from this little limitations lftp is a good choice for scripting FTPS transfers in Unix shell.

Most scripting languages also support FTPES. Python support FTPES by M2Crypto. For Perl exists a FTPES implementation in Net:FTPSSL. Listing 3 shows for example a little Perl script which uses Net::FTPSSL to connect to a z/OS mainframe. It executes several LIST commands and puts itself onto the host while talking care of parameters for MVS data set allocation. To switch from FTP to FTPES in scripting languages is not very complicated. Of course it is effort to change the scripts but that's the price for an up to date security level.


#!/usr/bin/perl

use strict;
use Net::FTPSSL;
use Term::ReadKey;

if ($#ARGV != 1) {
    print "Usage: $0 host user\n";
    exit (1);
}

# Get target and credentials for connect
#
my $host = $ARGV[0];
my $user = $ARGV[1];
print "Enter password of $user:";
ReadMode('noecho');
my $password = ReadLine(0);
print "\n";
ReadMode(0);

# Connect host with FTPES
#
my $ftps = Net::FTPSSL->new($host,
                            Port => 21,
                            Encryption => 'E')
    or die "Can't connect to $host";

# Login
#
$ftps->login($user, $password)
    or die "Login failed";

# Subroutine to list files
# in current working directory
#
sub list_files
{
    print "Listing: " . $ftps->pwd() . "\n";
    my @listing = $ftps->list();
    my $n;
    foreach $n (0..$#listing) {
        print "$listing[$n]\n";
    }
}

# List files
#
list_files;

# Put a new file (this script) onto the host
# with parameters for MVS data set allocation
#
print "Putting $0\n";
$ftps->site("recfm=fb lrecl=80 blksize=27920");
$ftps->put("$0");

# List files again
# FTPES.PL should appear in listing
#
list_files;

# List another level ('SYS2')
#
$ftps->cwd("'SYS2.'");
print $ftps->pwd() . "\n";
list_files;

# Disconnect
#
$ftps->quit();

Listing 3: ftpes.pl

For Java EE developers it is good news that even FTP resource adapters has already started supporting FTPS. Since version 6.1 IBM WebSphere Adapter for FTP allows integration of FTPS client operations into Java EE applications. It makes it possible to feed old z/OS scheduled batch jobs with data for processing from Java EE by FTPS.

Effort to Switch from FTP to FTPS

By switching from FTP to FTPS the server side under z/OS needs only minor modification. The old batch jobs which receives data for processing by FTP can run without modification with FTPS. By using FTPS the FTP server's product won't change so features like JES mode are still available. With JES mode it is possible to start a job automatically when a new data set arrives by FTP. The modifications at z/OS' server side needs only reconfiguration of the FTP server. Applications and batch jobs don't need to be touched. This is a big plus in an legacy environment where nobody has the heart to touch old programs.

At client side and the systems providing data for processing respectively modifications are definitely needed. If the used FTP client doesn't support TLS/SSL a migration to another tool is necessary. If scripting languages are used the scripts need to be modified.

SFTP and SCP

In the world of Unix, as well as other VT100 terminal dominated environments (such as OpenVMS Secure Shell (SSH) and its subsystems), SSH File Transfer Protocol (SFTP) and SSH Copy (SCP) replaced insecure TELNET, rsh, rlogin and rcp. SFTP and SCP have become the cross-platform de facto standard for secure file transfers. With its UNIX System Services (USS) z/OS offers a POSIX and UNIX compliant environment. IBM delivers under USS an OpenSSH port so that z/OS can participate in the world of SFTP and SCP, too. Configuration of OpenSSH for z/OS is absolutely the same as on Unix/Linux systems.

It is temping to replace old FTP-based transfers by SFTP. Unfortunately SFTP and SCP of OpenSSH are restricted to Unix files on HFS and ZFS. It is not possible to access MVS data sets through SFTP or SCP. The good news are: Some Unix commands like cat, mv and cp of USS are extended to access MVS data sets. Also the TSO commands OPUT, OGET and OCOPY allow the file exchange between MVS and USS. Out of the box a two-phase transfer is technically feasible. To transfer a file for processing onto z/OS the following two phases apply.

  1. The first phase transfers the files via SFTP into a HFS/ZFS file.
  2. The second phase copies the Unix file into a MVS data set by the commands mentioned before. Batch processing can run unmodified upon this MVS data set.

If the batch job gets its data sets by DD statements in JCL decks it will be much easier. Instead of specifying a MVS data set name by the parameter DSN in DD statements you can simply specify a Unix file by using the PATH parameter. The job accesses then directly the Unix file as it were a MVS data set. Unfortunately this solutions needs modifications to JCL decks. In most cases solution where is no need for modification of JCLs is more effective.

But there are also alternatives to OpenSSH! Tectia offers with "SSH Tectia Server for IBM z/OS" -- an SSH implementation which supports Unix files as well as MVS data sets. Dovetails Technologies also offers with Co:Z SFTP an SSH server which bases upon OpenSSH. It is an open-source solution which enables your SSH server on z/OS easily to access MVS data sets directly.

There is a broad support in scripting and programming environments for SFTP and SCP. Just to name a few: Perl offers SFTP integration by the module Net::SFTP. Paramiko is a LGPL licensed solution for Python. A few JCA resource adapters for Java EE application servers exist which provide SFTP access out of Java EE applications.

The Price to Switch from FTP to SFTP

The compatibility to the widely supported world of SFTP/SCP brings one disadvantage, too. The useful JES mode as it exists in z/OS' FTP server is not available in SSH servers. Here it is necessary to switch from automatically start of processing by JES mode to a scheduled execution. It is necessary to involve a job scheduler which brings in a new dependency to batch processing. Before there was only a dependency to FTP server and its JES mode.

The migration from FTP to SFTP has a deeper impact to your infrastructure and your batch jobs. Both sides -- server on z/OS and clients--must be modified. There are advantages by integrating to the standardized world of SFTP/SCP but there are also disadvantage of a higher migration effort. There is no simple answer in general for all application scenarios.

FTPS is the easier way to bring your dinosaur on the secure side of life. Often there are several FTP products by different vendors involved on the system platforms of infrastructures. The risk of incompatibility increases.

SFTP/SCP are the common standard on dominating system platforms. Often you can use one product, e. g. OpenSSH or Tectia, on different operating systems. This reduced risks of incompatibility. On the other hand the effort for migration is much higher than that for migration to FTPS.

Nevertheless these two alternatives to insecure traditional FTP show that there is really no more excuse to support insecure protocols on the mainframe. So think twice before you start nodding in conference rooms.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video