Here we consider TCP/IP under z/OS, a path into the system we need to control for effective security. Using tools provided with z/OS, this can be the most secure TCP/IP you’ll find anywhere. We’ll summarize how TCP/IP works under z/OS, discuss its security risks, and examine how you can manage those risks. References to security software here mean RACF, ACF2, or TopSecret.
Each TCP/IP message contains an IP address used for routing. The IP address is like a phone number and often corresponds to one computer and often one Domain Name Server (DNS) name; for example, www.ibm.com.
Each TCP/IP message also contains a port number that corresponds to one application, such as email or File Transfer Protocol (FTP). When a message is routed to your mainframe based on its IP address, the TCP program on the computer uses the port number of the message to decide which program to hand the message to. So, if the port number is for the FTP program, then TCP/IP hands the message to the FTP application program. (The User Datagram Protocol [UDP] also uses IP addresses and port numbers, and can be secured with many of the tools used for TCP.)
Each such application program is called a daemon. Under z/OS, each daemon is a started task, with its own JCL, userid, program load module, and often its own control file where the administrator specifies the options.
Here are some security risks associated with TCP/IP. Someone could:
- Read unencrypted data on the Internet
- Write a program that opens an unused port and then listens for requests for the program to take some unauthorized action
- Modify the control files, JCL, or actual program for TCP/IP or one of its daemon programs to do improper things under the identity of that program
- Attempt a Denial of Service (DoS) attack either by flooding the server with messages or buffer overflow
- Access the system by spoofing (falsely assuming someone else’s identity)
- Hijack a session; that is, seize control of a conversation between your mainframe and, for example, a client using Internet Explorer to send his credit card number to your company. Take advantage of flaws or improper configuration of daemon programs.
These steps will help you provide effective security for your mainframe TCP/IP network. See if you can match them with the aforementioned risks:
- Know what TCP/IP programs are executing. The TSO command NETSTAT will tell you the to- and from- IP addresses, the to- and from- port numbers, and the name of the program for each connection. Review the TCP/IP control file to see what ports and daemons are defined.
- Control who can use which IP addresses, both inbound and outbound. These addresses are defined in the control file for TCP/IP and can be named so you can control them in your security software using the SERVAUTH resource class.
- Control who can use which ports. In the control file for TCP/IP, you can restrict all the commonly used ports (with the RESTRICTLOWPORTS operand); reserve ports so they can’t be used (with the RESERVED operand) until your standards group authorizes their use; or define them to the security software so you can protect them (with the SAF operand in the port definition and the SERVAUTH resource class in the security software).
- Determine what encryption is in place for each link. The z/OS system supports all the standard encryption methods and makes it easy for applications to invoke them.
- Determine for each connection how “who is that user?” is answered. This could be done using an encrypted password, Secure Sockets Layer (SSL), Transport Layer Security (TLS) client authentication, Kerberos, or other means, including settings in the control files for the daemons. In the security software, use the BPX.DAEMON, BPX.SERVER, and BPX.SUPERUSER rules to control the ability of some programs to assume other people’s identities.
- Determine access controls, quality assurance, and change control over the programs, their JCL, and their control files.
- Consider using external firewalls or the Policy Agent software you get with TCP/IP to provide firewall-like functions such as intrusion detection, Virtual Private Network (VPN), and packet filtering.
- Use digital certificates stored in your security software to prevent session hijacking.
- Discover particular security issues for each daemon. For example, FTP on the mainframe can upload and download both MVS and USS files as well as submit batch jobs, browse printouts, and access DB2, depending on your security settings. DB2, when called by a program connected to the Internet, may be subject to SQL injection attacks, if the application isn’t well-designed.
The next column will examine how to secure another path into your z/OS system.