More and more companies are moving from traditional in-house systems of various hardware and software components to a model that promotes outsourcing key processes to offsite data centers. These data centers are designed and managed to serve internal computing needs as well as external, customer facing needs, such as facilitated communication, product demonstrations, order processing, and product fulfillment.
A requirement of this migration is that key internal company information and privileged customer data remain accessible only to those users authorized to access and manage that data.
This article describes the basics for upgrading, choosing, and implementing a highly effective, secure SSH connectivity solution to the IBM Cloud. It starts by examining some recent trends in migration to the cloud, then looks at key areas to consider when making the shift from in-house handling of key processes to a cloud-based solution. Finally, it concludes with a demonstration of an existing end-to-end, server and client SSH security solution.
Challenges to secure cloud access
One of the concerns of potential cloud users is that data is exposed when it is moved from a secure in-house location to what might be considered a less secure external location. Even though the cloud instance itself can be secured using the Windows Active Directory, NTFS file system, and firewalls, the transfer of data can be troubling.
Issues that can create real and costly security breaches when left unaddressed include:
- Clear text transmission: All communications done in clear text, including usernames and passwords.
- Weak client authentication: Commonly deployed and unsecure access methods authenticate users through usernames and passwords that, time and time again, have proven to be unreliable and offer no support for advanced methods such as public/private key, Kerberos, or digital certificates.
- No server authentication: Users have no way to confirm that they are communicating with their intended server instead of an attacker impersonating the server.
- Absence of data integrity: Anyone can alter and corrupt data being transmitted between server and the client without detection.
In these cases, the explosion of mobile access to cloud data must also be taken into account. It's not uncommon these days to see employees:
- Use smart phones and tablets to check inventory at a warehouse
- Gather information while in the field
- Track products across multiple checkpoints
- Transmit data to a home office from a car or an airport lounge
One estimate predicts that in 2014, mobile Internet usage will overtake desktop Internet usage. Already, more than 50 percent of all "local" searches are done from a mobile device.
Given the large number of federal privacy and data protection regulations, not to mention the increasing technical acumen now exhibited by hackers, allowing employees remote access to the network from mobile devices is becoming untenable in an enterprise setting.
Everyone is aware of change resistant users and companies who are reluctant to make the shift. But as companies and their employees redefine the geographic sweep of the workplace, focusing on how to best securely manage this migration of multiple access points to stored data in the cloud will be paramount.
As for those privacy regulations, most of us are also aware of the federal regulations put in place over the last decade to protect consumer and corporate privacy, such as:
- PCI-DSS (2004, updated January 2009): This payment card, industry data security standard regulates how credit card information is processed, stored, and transmitted. The lack of encryption, weak authentication, and the absence of data integrity render Telnet completely unsuitable for supporting the standard's requirements on a wireless network.
- GLBA (1999): The Gramm-Leach-Bliley Act requires the financial industry to adequately protect customer data information—again, an unrealistic expectation with Telnet or FTP.
- Sarbox (2002): Sarbanes-Oxley requires the implementation of solid internal controls to guarantee that financial reports properly reflect the economic reality of any publicly traded company. Most auditors reviewing IT systems tend to require Telnet or FTP remote computing activities to be shut down.
- HIPAA (1996): Among other things, this healthcare industry regulation requires doctors to encrypt and protect their patients' information—again, not possible with Telnet or FTP.
- FIPS Compliance: Under the Information Technology Management Reform Act (Public Law
104-106), the Secretary of Commerce approves standards and guidelines that are
developed by the National Institute of Standards and Technology (NIST) for Federal
computer systems. These standards and guidelines are issued by NIST as Federal
Information Processing Standards for use government wide. NIST develops FIPS when
there are compelling Federal government requirements but no acceptable industry
solution or standards, such as for security and interoperability.
As part of this program, the Cryptographic Module Validation Program (CMVP) is the accreditation program that validates cryptographic modules to this standard. The CMVP is a joint effort between the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE) of the Government of Canada. Cryptographic Modules validated through the program are subjected to rigorous testing by independent, accredited Cryptographic Module Testing (CMT) laboratories.
Moving beyond the promulgation of straightforward regulation, the federal government also recently kicked off a six month study of its data centers, the findings of which will lay the groundwork for a sweeping, public data center consolidation effort. In the wake of the federal announcement, the city of New York also began a similar initiative.
As government agencies work to streamline data center and storage capabilities and place more and more functions within the cloud, many industry watchers expect these broad scale initiatives will usher in still further data and privacy protection regulation aimed at ensuring remote computing security.
SSH as a cloud access security approach
The components of SSH discussed here make it a prime candidate for a cloud access security approach.
A network protocol that allows data to be exchanged using a secure channel between any two networked devices, SSH was designed from the ground up in 1995 specifically to serve as a replacement for Telnet, FTP, and other insecure remote shells.
SSH uses encryption to ensure the confidentiality and integrity of data transmitted over insecure networks. With the right SSH solution, a company is able to protect itself against:
- Eavesdropping of data transmitted over any network
- Data manipulation at intermediate elements in the network like at the routers
- IP address spoofing
- DNS spoofing of trusted host names/IP addresses
- IP source routing
Over time, the role of SSH has expanded to become the de facto industry standard for secure remote access, secure file transfer, and secure tunnel connection. Perhaps more importantly, SSH has become the secure delivery transport of choice for delivering applications from servers to desktop and mobile clients.
The following list of RFCs details the role of SSH, which is a RFC standard, in helping to secure remote data communications:
- RFC 4250: SSH Protocol Assigned Numbers
- RFC 4251: The Secure Shell (SSH) Protocol Architecture
- RFC 4252: The Secure Shell (SSH) Authentication Protocol
- RFC 4253: The Secure Shell (SSH) Transport Layer Protocol
- RFC 4254: The Secure Shell (SSH) Connection Protocol
- RFC 4256: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
- RFC 4335: The Secure Shell (SSH) Session Channel Break Extension
- RFC 4344: The Secure Shell (SSH) Transport Layer Encryption Modes
From Cisco routers to corporate production servers, SSH can be used across platforms, including Microsoft® Windows, UNIX®, Apple Mac, and Linux®, for such tasks as:
- Logging in to a shell on a remote host (replacing Telnet and rlogin).
Use any standard SSH client to get shell access.
- Executing a single command on a remote host (replacing rsh).
Pass a command to the SSH connection to automatically run the command:
ssh user@server c:\temp\batch_file_to_launch
- Copying files from a local server to a remote host, using Secure FTP (SFTP) and Secure
Copy Protocol (SCP), providing
options for file copies.
scp source_file user@sshServer:drive:\dest_directory\dest_file
- Transferring files in combination with SFTP, as a secure alternative to FTP. A common misunderstanding is that this is secure FTP and an FTP client can be used to connect; an SFTP client is required to connect to an SFTP server.
- In combination with rsync to backup, copying and mirroring files efficiently and securely.
- Automating file copies with scripting. This code is an example of scripting with
Pragma Systems command SFTP client:
sftp user@sftp_server -b batchfile -L logfile
The batch file can contain file transfers:
cd userlogs mput *.log cd \serverlogs mget *.logs
- Forwarding or tunneling a port. One common mistake with port forwarding is connecting to the remote host instead of the local port. Port forwarding allows local connections to tunnel through the ssh connection, encrypting the full session. Also, a nice way to automatically forward ports is to use a batch file that sets up port forwarding that is run as a user's logon script.
- Web traffic tunneling can be done by port forwarding. Open an SSH client and connect
with port forwarding:
ssh user@ssh_server -L 8080:internal_webserver:80
Then connect locally to tunnel traffic through the port http://localhost:8080.
- You can use email traffic. Open an SSH client and connect with port
ssh user@ssh_server -L
- Web traffic tunneling can be done by port forwarding. Open an SSH client and connect with port forwarding:
- Forwarding from a remote host (possible through multiple intermediate hosts).
- Browsing the web through an encrypted proxy connection with SSH clients that support the SOCKS protocol.
- Securely mounting a directory on a remote server as a file system on a local computer using SSHFS.
- Automated remote monitoring and management of servers through one or more of these mechanisms.
- Collaborating securely with multiple SSH shell channel users where session transfer, swap, sharing, and recovery of disconnected sessions is possible.
For these tasks and needs, SSH seems like the right approach for secure anytime, anywhere access to the cloud. But you should still consider if SSH alone is enough to support everything you need and want to do from the field.
SSH is all you need if:
- You only need command line access.
- You want to execute single commands, either scripted or interactively.
- You can do all of your administration on a command line.
- You want all traffic through secured through a single port.
- You only want to open a single port in a firewall.
- You want quick access to your server.
You might need VPN or Terminal Services access if:
- You need to run graphical programs.
- You want full access to multiple programs with user context.
So what are some best practices to implement SSH in the cloud? Remember these:
- A GUI connection is processor intensive. For servers, this may be prohibitive. Command line access is less intensive with a quick connection.
- SSH is ideal for server administration and running console applications remotely. Almost all administration that is done through a GUI can be performed from the command line. Windows provides PowerShell and other command line tools for command line administration.
- Since it is a standard, cross-platform connection is allowed. Linux, Windows, and even handheld devices such as RF guns or mobile phones can connect to transfer files or run applications.
- SSH on a cloud Windows instance gives Windows some of the basic functionality that Linux cloud instances currently provide, but with the flexibility and ease of use associated with common Windows-based systems.
Let's talk a little about an existing system that can meet the requirements of providing SSH access to the cloud. Then we'll look at how that system handles real world requirements like the PCI regulations.
Real world solutions for SSH
Pragma Systems' Fortress SSH Server is easy to install and intuitive to use. You can configure the software using a dialog window or command line program. It is also easy to customize, allowing user-defined login scripts and customizable login shells. Fortress SSH Server is also designed for seamless and easy deployment across large corporate environments.
The following implementation use case will show how Fortress SSH can be used to satisfy the Payment Card Industry (PCI) security requirements.
As part of Payment Card Industry's key listing of requirements for secure data transfer for the transfer of critical payment information, one of the keys to PCI is Requirement 4.1-4.1.1: Encrypt transmission of cardholder data across open, public networks. In other words, sensitive information must be encrypted during transmission over networks that are easy and common for a hacker to intercept, modify, and divert data while in transit. These requirements are:
- 4.1: Use strong cryptography and security protocols such as secure sockets layer (SSL)/ transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive card holder data during transmission over open, public networks.
- 4.1.1: For wireless networks transmitting cardholder data, encrypt the transmissions by using WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN.
If you use WEP:
- Use with a minimum 104-bit encryption key and 24 bit initialization value.
- Use only in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS.
- Rotate shared WEP keys quarterly (or automatically if the technology permits).
- Rotate shared WEP keys whenever there are changes in personnel with access to keys.
- Restrict access based on media access code (MAC) address.
When reviewing Sections 4.1 and 4.1.1, it is important to note that SSH (including Pragma's Fortress SSH) uses the same encryption mechanisms as SSL/TLS and IPSEC—and then goes one step further, actually providing additional security features.
SSL is an older version of TLS: TLS 1.0 is the equivalent of SSL 3.0. SSH was invented to provide secure remote access and secure file transfer (through SFTP), just as SSL/TLS was designed to secure web e-commerce and IPSEC was designed to provide VPN access. SSH and SFTP have become RFC standards and are widely deployed and adopted in the industry.
Additionally, the Request for Comments (RFC) Overview Notes for the Internet lists two basic properties of the TLS Record protocol:
- The connection is private. Symmetric cryptography is used for data encryption (such as DES [DES] or RC4 [RC4].) The keys for this symmetric encryption are generated uniquely for each connection, and are based on a secret negotiated by another protocol such as the TLS Handshake Protocol. The Record Protocol can also be used without encryption.
- The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (such as SHA or MD5) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.
In brief, TLS provides a mechanism to keep people from seeing data being transferred (connection is private) and a mechanism to verify that the data being received was the data being sent (connection is reliable). This second feature may seem like a basic error-checking capability, but is actually intended to prevent a hacker from modifying the data in route.
Moreover, IPSEC is defined in RFC 4301-4309. In Section 2.1: Goals/Objectives/Requirements/ Problem Description, it states that:
IPSEC is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (through encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself). In fact, IPSEC provides a superset of SSL/ TLS functionality.
From this, it seems clear that encryption and message integrity are paramount to effecting compliance with PCI-DSS.
Pragma Systems' Fortress SSH security features closely resemble IPSEC, utilizing the same algorithms for encryption: message authentication code (MAC) processing and key exchanges. Moving beyond the encryption function, however, SSH affords companies the perfect balance of security and ease-of-use. Fortress SSH provides more flexibility in authentication than either SSL/TLS or IPSEC and it's as secure as SSL/TLS or IPSEC. Pragma's Fortress SSH technology directly addresses the tenets of PCI DDS 10.2.4-10.2.5 expressed in Requirement 10.2.4-10.2.5: Track and monitor all access to network resources and cardholder data. It provides robust authentication including password, public key, and Kerberos authentication mechanisms. Fortress SSH also readily facilitates tracking and logging invalid logging attempts and valid connections.
Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis if something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
In this article I've described the challenges to achieving secure cloud access, described how SSH can be used to implement a secure cloud-access system (including the components necessary to do this), outlined some best practices to implementing an effective SSH-access system for a cloud environment, and provided a real world example in Pragma System's Fortress SSH product.
developerWorks provides an extensive library of SSH-usage resources that may be of interest in connection with this article:
- Tunneling with SSH is a classic that demonstrates Windows-to-UNIX connectivity in a secure world.
- Three locks for your SSH door explains how to specify who can use SSH, application of port-knocking techniques, and how to hide the fact that SSH access even exists.
- More locks for your SSH door extends the previous resource by demonstrating how to enhance SSH access by eliminating passwords and using public/private key pairs instead; it also explores how to recognize and block possible attacks, including brute-force and dictionary attacks, by denying server access to origins that are identified as unsafe.
- Secure multi-user access to IBM Cloud instances with VNC and SSH shows you how to configure cloud instances and clients for secure remote graphical access.
- Secure access for Android devices demonstrates how to set up an Android mobile device to securely access an IBM Cloud instance.
For more on how to perform tasks in the IBM Cloud, visit these resources:
- Knowledge path: Build an effective cloud policy
- Up and download files from a Windows instance
- Install IIS web server on Windows 2008 R2
- Create an IBM Cloud instance with the Linux command line
- Create an IBM Cloud instance with the Windows command line
- Extend your corporate network with the IBM Cloud
- High availability apps in the IBM Cloud
- Parameterize cloud images for custom instances on the fly
- Windows-targeted approaches to IBM Cloud provisioning
- Deploy products using rapid deployment service
- Integrate your authentication policy using a proxy
- Configure the Linux Logical Volume Manager
- Deploy a complex topology using a deployment utility tool
- Provision and configure an instance that spans a public and private VLAN
- Secure IBM Cloud access for Android devices
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- See a list of product images available for IBM SmartCloud Enterprise.
- Find out how to access IBM SmartCloud Enterprise.
Get products and technologies
- Visit the IBM Cloud site for current cloud offers.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.