Townsend Security Data Privacy Blog

The adoption of the Secure Shell (SSH) file transfer protocol has gained a lot of momentum over the last few months. Major financial institutions are migrating from proprietary transfer systems, and from the Secure Sockets Layer FTP protocol (SSL FTP) to Secure Shell implementations. We’ve had support for Secure Shell file transfer automation in our Managed File Transfer solution, Alliance FTP Manager, for many years and our customers are making the switch with no difficulties.

But what about running the Secure Shell server on the IBM i platform? What do you need to know about securing the SSH server when it runs on the IBM i?

One of the most important things you can do is create a CHROOT jail for the SSH server.

I can see you raising your collective eyebrows right now! Let’s talk about what a CHROOT jail is, why you would want to do this, and how you can make it happen.

Without creating some additional controls, your implementation of the SSH server will leave your system very exposed to abuse. For example, if you SSH to a server and log in, you will be presented with a command line. For any of you Linux geeks, you know what a command line means. It’s free reign to wander all over the system. On any SSH server without good controls, you can change directory (CD) to any library or IFS file on the system. And then you can do a lot of damage!

CHROOT to the rescue!

The Linux CHROOT facility is designed to keep users in a tightly controlled area, or “jail”. It’s been a part of UNIX and Linux for decades, and is very well implemented in those systems. But we also have it on the IBM i platform. If set up correctly, your IBM i SSH server with CHROOT implemented will keep those users from wandering around your system. They will only be able to see the directories you give them, and they won’t be able to change to other directories. They are in the little jail that you created.

Fortunately, the IBM i OpenSSH licensed software provides full support for implementing CHROOT jails. You can enable CHROOT support in the SSH server configuration file, and IBM provides a Shell script to create all of the directories and objects you need for each user. And there are good instructions on how to set this up.

But there is one little piece of CHROOT that can be a challenge. For CHROOT to work properly, the SSH server has to be running as “root” when it starts. On an IBM platform, that means it has to be running under the QSECOFR user profile. But you can’t submit the job and specify the QSECOFR profile, so how does this bit of logic get automated?

In Alliance FTP Manager we’ve solved that problem for you. When you specify that you want to run in a CHROOT environment, we submit the job and perform a profile swap to QSECOFR. Voila! You have everything you need to use the SSH server with CHROOT enabled.

If you want to run the SSH server on your IBM i you can contact our technical support group to receive the added software for the Alliance FTP Manager product. You can be up and running with CHROOT’ed SSH in no time at all.

Patrick

---

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.

One clear direction I’ve observed over the last few months is the focus of QSA auditors and other security professionals on the protection of sensitive data AFTER it traverses the Internet and then lands in a database on a hard disk drive. We have really good ways of protecting data in transit using 128-bit SSL encryption. For example, the web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands on a hard drive somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors are putting a lot of emphasis now on making sure that data is encrypted when it hits a hard drive.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a power incentive to use this platform for business integration.
 
But care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives.

Of course, the right thing to do is encrypt sensitive data before it lands on the hard drive. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process about four years ago. Alliance XML/400 customers can protect sensitive data by just enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

For non-IBM System i environments we now provide an easy way to retrieve encryption keys and perform encryption in a variety of development languages such as Microsoft .NET, Java, and C/C++.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting in Orlando this year, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? Certainly not. I like to think of it this way:  Wearing a parachute on a skydiving expedition is no guarantee that you won’t be hurt when you land.  But that doesn’t mean you wouldn’t wear one, right? I think of encryption in the same way.

To view a replay of a recent webinar we presented on XML & Web Services, click here.

Patrick