Using IBM’s built-in FTP and Open SSH servers to transfer files to and from your IBM i systems can be time-consuming, if not simply riddled with fine details. From scripting knowledge to running specific (and sometimes obscure) commands, there’s a lot to consider—and the safety and integrity of your files is probably at the top of the list.
While the IBM i is generally considered impenetrable to attacks, your systems are still susceptible to vulnerabilities and user oversight. Here are five practices for the IBM i that we recommend you follow when transferring files inside and outside your network.
The standard FTP protocol has been around since the 1970s. When it first debuted, it was considered a safe way to transfer files. Data breaches and cyberattacks were virtually non-existent. However, FTP hasn’t kept up with today’s fast-paced technology and strict compliance requirements. It worked for transferring files within private networks, but now using unsecure FTP to move files is risky at best … and a wide open door for a data breach at worst.
“Everything that flows over a standard FTP connection is 'in the clear,' meaning that a would-be attacker can simply sit on the network or router and watch all of the user IDs, passwords, and data that are transmitted over the FTP connection,” writes Bob Luebbe, Chief Architect at GoAnywhere. “The attacker can not only capture this information easily with readily available 'packet sniffing' tools, but also manipulate this data since FTP does nothing to protect its integrity.”
SSH keys for the IBM i are created using OpenSSH commands on the command line. They are then placed in a directory and connected to a user through the IBM i’s management GUI.
Proper key management and placement is important for keeping your data safe. Using a Managed File Transfer (MFT) solution with an integrated key manager can help take the stress out of generating and storing public SSH keys. Instead of a needing a command line, keys are created and managed from a central database. Key pairs can be imported, exported, and viewed from one interface, and all keys use asymmetric and symmetric cryptology for strong encryption and optimal performance.
Integrated File Systems (IFS) are sets of file systems that can be transferred across IBM i systems. The root directory for each IFS generally contains product files, third-party applications, and other data. Unfortunately, the root isn’t very secure (by default, root has *PUBLIC access), which leaves objects stored in the IFS vulnerable to viruses.
The easiest way to deal with this threat is to scan your IFS before transferring your files. In fact, IBM i experts recommend that scanning for viruses becomes part of your cybersecurity routine and policies.
Not convinced that your IFS is at risk? A guide to security issues for IFS (linked below) explains that “the IFS has proven, on numerous occasions, to be a very effective ‘carrier.’ That is, it very efficiently stores and propagates viruses around a network. Another way to put it is that IBM i is the perfect host. It may not get infected itself, but it is very good at infecting everything that touches it.”
Are you sure the data in your IFS hasn’t been infected? To learn more about scanning and other ways your IFS might be at risk, check out Top Security Issues for the Integrated File System (IFS).
The DMZ is the public-facing portion of an organization’s network. Many companies decide to store their data in the DMZ to avoid opening inbound ports into their private network, making it easy to keep sensitive information safe while sending data to and receiving data from external sources.
Unfortunately, the DMZ is not an ideal place to store information, even temporarily. This portion of the network is much easier to hack into; it’s closer to the internet than the private network, it’s less secure, and the firewall between the internet and the DMZ may not be set up correctly. Moving files between the DMZ and the private network also requires programming and scripting knowledge, which can eat into your team’s time and resources.
A better, alternative option to the DMZ is to keep your file server in the private network. But if opening inbound ports is a concern, especially if you’re PCI DSS or HIPAA compliant, you may feel neither the DMZ nor the private network are good options. In that case, a DMZ gateway can serve as an enhanced reverse and forward proxy that allows you to store (and send) files in your private network—all while keeping your inbound ports firmly closed.
Whether you’re sending a dozen or a thousand file transfers a day, it’s a good idea to set up email alerts so you’re informed whenever a file transfer fails, an error occurs, or an event happens. Alerts keep you on top of important file transfers, helping you make sure the data gets where it’s supposed to go.
Depending on how the triggers are set up, you can also design them to process files. For example, if a file is downloaded, a trigger could automatically move that file to a designated folder, reducing the amount of manual work you have to do after each transfer.
Are you looking for ways to improve your efficiency on the IBM i? GoAnywhere MFT can simplify your IBM i file transfers through easy deployment, automated transfers, an integrated user management system, comprehensive security controls, and more.
Our 60 minute on-demand webinar, “IBM i Webinar: Simplify and Protect Your File Transfers,” explores how GoAnywhere MFT works with the IBM i to streamline your file transfer and encryption practices. The recording is packed with information. Don’t miss out; view the webinar here.