TCP/IP security
In this chapter we provide a security concepts and architecture overview for TCP/IP on System z. Some concepts of the applications and components listed here will be provided as well. Then we describe some guiding principles for configuring TCP/IP security.
This chapter includes the following sections:
 
Important: A more general overview of TCP/IP related topics is addressed in Chapter 1, “Mainframe network concepts and functions” on page 1. Make sure that you are familiar with these concepts.
3.1 Introduction
The IT backbone of every organization is a strong IP network infrastructure. Securing your z/OS IP network resources is key to ensure smooth business operations. In this chapter, we describe the particular controls that you will be able to use as systems programmer to protect the IT crown jewel of your organization.
3.1.1 IP network design
When discussing IP security, the first step is to address the overall network design. Because System z usually contains multiple components of an enterprise service flow, there are particular challenges on how to design this part of the network.
The most common type of network design is a three-tiered network design. This design consists of a presentation layer, an application layer, and a database layer. The presentation layer usually resides within a DMZ and can be considered the front end to your applications. The other two layers provide an interesting challenge to System z network engineers, because both of these layers usually reside within System z.
It is important that you review your corporate policies to see whether this configuration is allowed, or if an exception needs to be made. There are methods available, such as designating some System z LPARs as application LPARs and others as database LPARs, to segregate the network traffic to meet this common IT architectural standard. Unfortunately there is no silver bullet that can be offered without truly understanding the applications in your environment. However, there are other security controls that we describe in this chapter, such as SAF controls, which can be used to mitigate security issues. We also describe other design choices that deal with network architecture.
3.1.2 System z in a DMZ
Normally, it is not a preferred practice to deploy a System z resource within the network DMZ. It is better to create a bastion host, even if it just acts as a proxy. This approach can front-end the network traffic to ensure that you are not wasting any processor resources needlessly in deflecting attacks. This approach can also limit the exposure of other services if your System z is placed within an enterprise network zone. If it is deemed necessary to place an LPAR inside the DMZ it should be segmented from other System z resources, and every network packet should have to traverse a third-party firewall and intrusion prevention device.
3.1.3 Mixing environments
In many deployments different stages of systems, such as production, test, and development, are placed together within the same network hierarchy. This is generally considered a bad practice because test systems have much lower levels of security placed on them compared to systems in development or production.
This could potentially allow an attacker to access the test system and gain a stronghold behind the network defenses that you have put in place to protect access to your production and development systems. Breaking these areas apart allows for stronger security controls to be placed on your different environments, which in turn allows you to better adhere to your organization’s security policies.
We also advise that you do not place distributed servers within the same local network segment where the Systems z LPARs reside. Because distributed servers have been known in the past to become susceptible to malicious attacks more easily, it is not wise to have them deployed on the same local network segments that your System z.
3.1.4 HiperSockets
IBM HiperSockets technology is an internal memory buffer within the System z that is used as internal Queued Input/Output (iQDIO). This concept can potentially produce network throughput at memory speeds to pass traffic between virtual servers on the same hardware platform. This is not just limited to z/OS, but is also available for Linux on System z and z/VM. HiperSockets is an elegant solution for transferring data securely between virtual servers without the need for encryption because this memory buffer cannot be sniffed or compromised.
 
Preferred practice: We advise that communication between LPARs on the same physical System z footprint should rely on HiperSockets communications.
3.2 Sockets and APIs
In a TCP/IP based network applications rely on two major concepts to communicate with each other, Sockets and APIs.
•Sockets
A socket is an endpoint for communication able to be named and addressed in a network. From the perspective of the application program, it is a resource allocated by the address space; it is represented by an integer called the socket descriptor.
The socket interface was designed to provide applications a network interface that hides the details of the physical network. The interface is differentiated by the different services provided:
 – Stream
 – Datagram
 – Raw sockets
Each interface defines a separate service available to applications. A socket uniquely identifies the endpoint of a communication link between two application ports.
A port represents an application process on a TCP/IP host, but the port number itself does not indicate the protocol being used: TCP, UDP, or IP. The application process might use the same port number for TCP or UDP protocols.
To uniquely identify the destination of an IP packet arriving over the network, you must extend the port principle with information about the protocol used and the IP address of the network interface; this information is called a socket. A socket has three parts, protocol, local-address, local-port.
Figure 3-1 illustrates the concept of a socket.
Figure 3-1 Socket concept
The term association is used to specify completely the two processes that comprise a connection as this example shows:
(protocol,local-address,local-port,foreign-address,foreign-port)
The terms socket and port are sometimes used as synonyms, but the terms port number and socket address are not like one another. A port number is one of the three parts of a socket address, and it can be represented by a single number, such as 1028, but a socket address can be represented by tcp,myhostname,1028.
A socket descriptor (sometimes referred to as a socket number) is a binary integer that acts as an index to a table of sockets; the sockets are currently allocated to a given process. A socket descriptor represents the socket, but is not the socket itself.
•APIs
z/OS Communications Server provides several application programming interfaces (APIs) to access TCP/IP sockets. These APIs can be used in either or both integrated and common INET PFS configurations. In a common INET PFS configuration, however, they function differently from z/OS UNIX APIs. In this type of configuration, the z/OS Communications Server APIs always bind to a single PFS transport provider, and the transport provider must be the TCP/IP stack provided by z/OS Communications Server.
The following TCP/IP socket APIs are included in z/OS Communications Server:
 – Pascal API
The Pascal APIs enable you to develop TCP/IP applications in Pascal language. Supported environments are normal MVS address spaces. The Pascal programming interface is based on Pascal procedures and functions that implement conceptually the same functions as the C socket interface. The Pascal routines, however, have different names than the C socket calls. Unlike the other APIs, the Pascal API does not interface directly with the Logical File System (LFS). It uses an internal interface to communicate with the TCP/IP protocol stack. The Pascal API only supports AF_INET.
 – CICS sockets
The CICS socket interface enables you to write CICS applications that act as clients or servers in a TCP/IP-based network. Applications can be written in the C language, using the C sockets programming, or they can be written in COBOL, PL/I or assembler, using the Sockets Extended programming interface. CICS sockets only support AF_INET.
 – C sockets
The C socket interface supports socket function calls that can be invoked from C programs. However, note that for C application development, IBM recommends the use of the UNIX C socket interface. These programs can be ported between MVS and most UNIX environments relatively easily if the program does not use any other MVS specific services. C sockets only support AF_INET.
 – IMS sockets
The Information Management System (IMS) IPv4 socket interface supports client/server applications in which one part of the application executes on a TCP/IP-connected host and the other part executes as an IMS application program. The IMS sockets API supports AF_INET.
 – Sockets Extended macro API
The Sockets Extended macro API is a generalized assembler macro-based interface to sockets programming. It includes extensions to the socket programming interface, such as support for asynchronous processing on most sockets function calls. The Sockets Extended macro API supports AF_INET and AF_INET6.
 – Sockets Extended Call Instruction API
The Sockets Extended Call Instruction API is a generalized call-based, high-level language interface to sockets programming. The functions implemented in this call interface resemble the C-sockets implementation, with some extensions similar to the sockets extended macro interface. The Sockets Extended Call Instruction API supports AF_INET and AF_INET6.
 – REXX sockets
The REXX sockets programming interface implements facilities for socket communication directly from REXX programs by using an address rxsocket function. REXX socket programs can execute in TSO, online, or batch. The REXX sockets programming interface supports AF_INET and AF_INET6
3.3 Telnet Server
Telnet is a terminal emulation protocol that enables you to log on to a remote system as though you were directly connected to it. Telnet enables users to have access to applications running on that system. The TN3270 Telnet Server provides access to IBM VTAM SNA applications on the z/OS host using 3270 or Linemode protocol.
Traditionally, non-mainframe ASCII-based platforms have used the Telnet emulation protocol for achieving this connectivity. However, because the mainframe is an EBCDIC-based platform with special 3270 terminal-type data stream requirements for its connected terminals, the TN3270 function was developed to support mainframe data streams.
Telnet is provided on z/OS by Telnet 3270 (TN3270), which is a terminal emulation technology that supports access to SNA applications on mainframe computers using TCP/IP (Telnet) protocols.
A z/OS Communications Server TN3270E Telnet Server can be implemented in your mainframe environment to allow TN3270 clients to access SNA applications using TCP/IP (Telnet) protocols.
As illustrated in Figure 3-2, TN3270E Telnet Server is one of the standard applications provided with the z/OS Communications Server. It uses z/OS UNIX socket application programming interfaces (APIs), a logical file system (LFS) and a physical file system (PFS) to transfer data from application layers to transport layers, and to manage incoming client requests.
Figure 3-2 z/OS TN3270E Telnet Server application services
3.3.1 Security concepts and architecture
Telnet is a protocol used worldwide for client access in the TCP/IP environment. To reduce the liability of your environment you must secure your Telnet applications. The traditional Telnet TN3270E differ in two main areas:
•3270 terminal emulation uses block mode rather than line mode.
•3270 terminal emulation uses the EBCDIC character set rather than the ASCII set.
Traditionally, non-mainframe ASCII-based platforms have used the Telnet emulation protocol for achieving this connectivity. However, because the mainframe is an EBCDIC-based platform with special 3270 terminal type data stream requirements for its connected terminals, the TN3270 function was developed to support mainframe data streams. The TN3270E Telnet Server has implemented these special terminal data stream requirements for clients using the 3270 emulation protocol.
 
What’s the “E” about? The meaning of the E as used in TN3270E and in IBM terminal devices, such as the IBM-3279-2-E can be confusing. In both cases, the E represents extended capabilities. However, there is no correlation between the extended capabilities of TN3270E and those of an IBM-3279-2-E display station.
327x device types that end in E are terminals that support extended field attributes, such as color and highlighting. TN3270E server support includes several important enhanced capabilities over TN3270E.
Also, the z/OS TN3270E Server supports RFC 1647 TN3270 Enhancements (July 1994) and RFC 2355 TN3270 Enhancements (June 1998), but not the RFC 1646 TN3270 Extension for LU-name and Printer Selection (July 1994). If you want to migrate from a channel-attached router or Communications Server for IBM AIX, Linux, and Windows to z/OS TN3270E server, the older version of the TN3270 emulator software might need to be replaced.
The TN3270 server is enabled for both SSL and AT-TLS, and the data path in the IP network to Telnet is protected using the SSL protocol. Figure 3-3 provides a TN3270E Telnet Server security overview.
Figure 3-3 TN3270E Telnet Server security overview
The TN3270E Telnet Server support provides several extensions for RACF-based access control to Telnet. These extensions can prevent a client from seeing the USSMSG (log on screen) unless the client is authorized.
 
Preferred practice: To configure the TN3270E Telnet Server extension to prevent a client from seeing the USSMSG (log on screen) define the client certificate to RACF using RACF digital certificate services. The first level of authorization checking verifies that the RACF user ID presented by the client certificate is defined to RACF. The next level of authorization requires that this RACF user ID be permitted to access the Telnet port. The Telnet port is represented as a RACF resource using the SERVAUTH class.
The TN3270E Telnet Server security can be enhanced using both multiple ports support and single port support:
•Multiple port support
TN3270E Telnet Server provides multiple port support. It can be used to enable the combination of secure and non-secure traffic. To use multiple port support, you define separate ports; one port is dedicated to non-secure traffic and another port is dedicated to secure traffic. Ports with the designation SECUREPORT or TTLSPORT can be secure. intranet clients are not required to be secure. Intranet clients connect to the BASIC port (port 23, as shown in Figure 3-4). All clients connecting from the Internet are required to be secure. These clients use the SECUREPORT (port 1023, as shown in Figure 3-4). Packet filtering is used at the firewall that separates the intranet and Internet to control access to the Telnet ports.
To prevent Internet access to the BASIC port, port 23 is blocked at the firewall. The SECUREPORT, port 1023, is permitted at the firewall. In this scenario, the best security is achieved when SSL client authentication with the Telnet RACF extensions is used. This support ensures that the client has the authority to attempt to log on to SNA applications through Telnet. Regardless of the method of authentication used, the SNA application should identify and authenticate the user using the RACF before any application access is granted. If you are using SSL encryption services, the used ID and password are encrypted.
Figure 3-4 Using multiple Telnet ports to separate secure and non-secure traffic
You can enhance security even more on remote access from the Internet to SNA applications combining IPSec and Telnet security. This scenario is shown on Figure 3-5. IPSec AH protocol is used for authentication between the user’s PC and the firewall. The firewall is open for port 1023 for traffic that is authenticated with only IPSec and discards the traffic that cannot be authenticated by IPSec. The additional security provided by IPSec protects the System z server from unauthorized access attempts and denial of service attacks by hosts outside the VPN.
Figure 3-5 Combining Telnet security with IPSec client-to-firewall authentication
•Single port support
A single port can be used to support a mix of secure and non-secure traffic. The port has the designation SECUREPORT or TTLSPORT. To support the configuration of various security policies for a single port, the SECUREPORT or TTLSPORT designation indicates that the port can use TLS/SSL, but the port does not have to use TLS/SSL.
Telnet supports both negotiated and non-negotiated TLS/SSL. Negotiated TLS/SSL is an IETF-defined extension to the TN3270 protocol. With negotiated TLS/SSL, the decision to use TLS/SSL for a connection is based on the outcome of a negotiation between the Telnet client and server using TN3270 protocols. This negotiation is performed after the Telnet connection is established, and if TLS/SSL is negotiated, the TLS/SSL handshake is performed. With non-negotiated TLS/SSL, a TLS/SSL handshake is required immediately after the connection is established. A single port can concurrently use both negotiated and non-negotiated TLS/SSL connections.
Figure 3-6 on page 98 shows a single Telnet port that allows a mix of secure and non-secure traffic. Intranet clients are not required to be secure. All clients connecting from the Internet are required to use SSL. Both intranet and Internet clients connect to the port designated as SECUREPORT (port 23 in this example).
In this scenario, IPSec AH protocol is used for authentication between the user's PC and the firewall. The firewall is open for port 23 for traffic that is authenticated with only IPSec. The firewall discards traffic for port 23 that IPSec cannot authenticate. In this scenario, packet filtering without IPSec cannot be used at the firewall that separates the intranet and the Internet to control access on the basis of port, because only one port is used. Without IPSec AH, all access control checks are deferred to Telnet. The additional security provided by IPSec at the firewall protects the System z server from unauthorized access attempts and denial of service attacks by hosts outside the VPN.
Figure 3-6 Secure and non-secure traffic using a single Telnet port
3.4 FTP
File Transfer Protocol (FTP) allows you to transfer files between any computers (mainframe, midrange systems, PC servers, and desktop systems) that support the TCP/IP-standard FTP protocols. FTP is the name of both the application and the protocol that allows you to transfer files over in a TCP/IP network. The FTP protocol uses a client/server model and the z/OS Communications Server ships with both FTP server (FTPD) and an FTP client.
FTP provides a fast and reliable method to transfer files in a TCP/IP network. FTP also allows for communication between platforms that have different character encoding and file structures by hiding such details from the user. With a few simple FTP commands, you can easily transfer a file from one platform to another regardless of whether the two platforms are similar. FTP is one of the standard applications provided with the z/OS Communications Server, which are depicted in Figure 3-7.
Figure 3-7 z/OS FTP client/server application services
3.4.1 Security concepts and architecture
System administrators can implement security precautions to protect data being transferred from one client to another. Rules can be applied to client devices, server devices, application platforms, and network firewalls to administer the security policies in the organization. This section focuses on the security measures that can be applied to the z/OS FTP client and server applications.
Security exposures can exist in an FTP environment, so it is imperative to analyze and correct them using available tools. The FTP application relies on the use of an external security manager, such as RACF, for certain levels of security. The client and server environments provide built-in security functions for additional security. We identify a few of the common security exposures and tools that can be used to address the issues. The major emphasis is on Secure Sockets Layer/Transport Layer Security (SSL/TLS) and Application Transparent Transport Layer Security (AT-TLS) features supported by the z/OS FTP application.
Throughout this section, we define the term secure FTP with the following statements:
•FTP data transmissions can be secured by requiring the client to connect to the server indirectly by passing through an FTP SOCKS proxy server that can control the connections and provide an extra level of security itself on the path toward the final destination server.
•FTP clients can allow or require server authentication whereby the server identifies itself to the client by passing a digital certificate to the client, which verifies the certificate against pre-established criteria. Any data exchanged between the client and server can then be encrypted using encryption keys established at connection time.
•FTP servers can allow or require the same server authentication process. Data encryption is usually the intent of this process, although not always required.
•FTP servers can require client authentication whereby the client identifies itself to the server by passing a digital certificate to the server who verifies the certificate against pre-established criteria. The certificate information can be used by the server to provide secure application logons on behalf of the client, thus avoiding the exchanges of user ID and password in clear text.
To get a better view of the FTP security architecture, it helps to understand how FTP security works.
SOCKS proxy protocols enable an FTP client to access a remote FTP server, protected by a blocking mechanism, that is otherwise unreachable. The client does not have direct network access to the final destination server, but the intermediate (proxy) server does have the necessary access. Therefore the client, having access to the proxy server, can connect to the proxy by using a special SOCKS protocol, pass through the proxy, and thereby gain access to the intended final destination.
 
Preferred practice: Although it can be a little complicated, consider configuring your FTP server to use a SOCKS proxy to enhance the security of your overall FTP environment.
Clients and servers can identify (authenticate) each other by using digital certificates, and can encrypt data exchanges by using encryption keys obtained from these certificates.
In addition to native TLS support, the FTP server and client can use AT-TLS to manage TLS security. TLS managed by AT-TLS (TLSMECHANISM ATTLS) supports more security functions than TLS managed natively by the FTP (TLSMECHANISM FTP). Be aware of these AT-TLS capabilities and requirements when planning the preferred AT-TLS support for FTP:
•Specify the label of the certificate to use for authentication rather than using the default.
•Support SSL session key refresh.
•Support SSL sysplex session ID caching.
•Trace decrypted SSL data for FTP in a data trace.
•Receive more detailed diagnostic messages in syslogd.
•There are no restrictions for the FTP ATTLS function.
•Policy agent must be active for FTP ATTLS to work.
•TLS security defined natively to FTP will continue to be available in addition to AT-TLS.
FTP security can be applied by implementing restricted access to FTP servers with firewalls, and then requiring the use of a SOCKS proxy server to control client access to the intended destination server.
Digital certificates can be used for client and server authentication and to enable the use of data encryption.
If you already have TLS implemented for an existing instance of the FTP server, it is easy to migrate from TLS to AT-TLS support. AT-TLS support is implemented by moving most of the TLS definitions from the FTP server’s FTP.DATA file into the policy agent’s AT-TLS configuration profile section. The FTP server is defined as an AT-TLS controlling application to the policy agent, and can retain its control of the secure relationship with the client. The AT-TLS implementation provides more flexibility and functions than basic TLS, and is therefore the preferred method of implementing digital certificate support for the FTP server. The IBM Configuration Assistant GUI is used to create the appropriate policy agent statements for AT-TLS.
If the FTP client must pass through a SOCKS proxy, the client must use the SOCKS protocol to successfully navigate through the proxy server. The client must be able to determine which servers it must contact using the SOCKS protocol. These servers are specified in a SOCKS configuration file that the client reads to make this determination. The SOCKSCONFIGFILE statement in the client’s FTP.DATA file is used to point the client to the configuration file where these servers are identified.
Dome dependencies must be covered to use FTP with a SOCKS proxy:
•The SOCKS protocol is supported for IPv4 only, not IPv6.
•The SOCKSCONFIGFILE is applicable to the client only: the server ignores the statement.
•If the SOCKSCONFIGFILE is not present in the client’s FTP.DATA file, the client does not use SOCKS to contact any servers.
•The configuration file can be an HFS file or an MVS data set.
Using the FTP client with SOCKS allows users to contact FTP servers that are protected by a SOCKS firewall that are otherwise unreachable. For more information and guidance on how to configure FTP with SOCKS proxy, check IBM z/OS V2R1 Communications Server TCP/IP Implementation Volume 4: Security and Policy-Based Networking, SG24-8099.
In addition to these methods you can also configure the basic z/OS FTP server to support native TLS-based security by enabling various RACF profiles and then authenticate and encrypt the FTP sessions. Both the FTP server and client in the z/OS Communications Server support TLS and Kerberos security. FTP can also be made secure with z/OS Communications Server AT-TLS or IP Security (IPSec).
 
Secure FTP versus sftp: The SSL/TLS implementation of FTP is known as secure FTP and invokes security in z/OS Communications Server using z/OS System SSL. It is based upon extensions to the base FTP RFC 959:
•RFC 2246, “The TLS Protocol Version 1”
•Internet draft RFC, “On Securing FTP with TLS (draft 05)”
•RFC 2228, “FTP Security Extensions”
•RFC 4217, “Securing FTP with TLS“
You need to understand the difference between secure FTP and the OpenShell procedure known as sftp. The sftp procedure operates over an encrypted Secure Shell (SSH) transport and does not use FTP protocols as described in RFC959 and its related RFCs.
By default, any valid z/OS user ID can log in to the FTP application.
 
Preferred practice: For security purposes, you might want to allow only certain user IDs to log in to FTP on a certain host. z/OS FTP currently provides the following methods to allow users to log in to FTP:
•Set up the FTP server for TLS level 3 authentication when sessions are secured with TLS.
•Code and install an FTCHKPWD exit routine that screens the user IDs that are allowed to log in to FTP.
•Code VERIFYUSER TRUE in the server’s FTP.DATA and use RACF profile to protect the FTP server port.
IBM z/OS V1R13 Communications Server TCP/IP Implementation: Volume 1 Base Functions, Connectivity, and Routing, SG24-7996 explains how to set these configurations.
3.5 InetD, the Internet daemon
The Internet daemon (InetD), also know as the Internet super daemon, is an application that listens for connection requests on behalf of other applications. By handling the initial connection process, InetD passes the connection to the application associated with the targeted port.
InetD is one of the standard applications provided with the z/OS Communications Server. It is a generic listener that can be used by any server that does not have its own listener.
Figure 3-8 shows the relationship between InetD and its supported applications.
Figure 3-8 InetD and its supported applications
The InetD servers provide access to the z/OS UNIX shell using otelnetd, rexecd, or rshd, allowing you to then run other UNIX commands and applications from there. The z/OS Communications Server includes three applications and several internal services that require InetD, as listed on Table 3-1 on page 103.
Table 3-1 Applications that use InetD
Application
Description
z/OS UNIX Telnet server
z/OS UNIX REXEC Server
Remote Execution Protocol
z/OS UNIX RSH server
Remote Shell Protocol
sendmail and popper mail servers
Mail servers available on z/OS Communication Server
echo
Repeats any data received back to the sender
discard
Throws away any received data
chargen
Sends predefined or random data and discards any received data
daytime
Sends the current date and time in user readable form
time
Sends the current date and time in machine-readable form
popper
Post Office Protocol 3 (POP3) mail delivery agent
3.5.1 Security concepts and architecture
InetD calls fork() to run in the background and disassociates itself from the controlling terminal. z/OS UNIX appends a 1 to the job name, provided the job name is fewer than eight characters. For example, if InetD is started with job name InetD, after the application forks the job name is INETD1. The correct job name of InetD is important to note because the TCPIP.PROFILE data set should reserve ports for InetD using the job name after InetD forks.
InetD can accept two command line parameters:
•-d
•A file name
Both parameters are optional. If -d is specified, InetD does not fork() at start and all error messages are written to STDERR. If a file name is specified, then InetD uses the specified file as the configuration file rather than the default /etc/inetd.conf.
 
Restriction: Only one Inet daemon can be run in one MVS image. The process file that the InetD uses is /etc/inetd.pid. You cannot change this file to another file name using either shell commands or environment variables, and it can be used only by one InetD at the same time.
InetD reduces system load by invoking other daemons only when they are needed and by providing several simple Internet services internally without invoking other daemons. Some applications depend on InetD to provide a listener, and those applications cannot be started without InetD.
InetD uses a configuration file in the z/OS UNIX file system to determine for which services InetD will listen. A sample configuration file can be found in the /samples/inetd.conf file. The format of the file is:
<service> <socket type> <protocol> <wait/nowait> <user> <application> <arguments>
All parameters except the last one (arguments) are required on each line. Table 3-2 shows a brief description of each parameter.
Table 3-2 Configuration file parameters
Parameter
Description
service
Name of the Internet service. This name must match an entry in /etc/services. By default, InetD assumes you want to listen on all IP addresses. However, you can optionally specify the service parameter in the format of IP_address:service_name to force a particular service to listen on a particular IP address.
socket type
Options are stream or dgram. Applications that use the TCP protocol are stream applications. Applications using UDP are dgram.
protocol
The IP protocol used by the application. The options are TCP, UDP, TCP4, TCP6, UDP4, or UDP6. If TCP6 or UDP6 is specified then the socket will support IPv6. You can also optionally specify the maximum receive buffer in the format of protocol,sndbuf=n, where n is the number of users.
wait/nowait
Wait indicates the server is single threaded and the application will issue an accept() API call itself and process connections one at a time. Nowait indicates the application is multi-threaded. In nowait mode, InetD issues the accept() API call and passes a connected socket to the application. The application in nowait mode can process multiple connections at a time. You can also optionally specify the maximum number of simultaneous users allowed by the application by using the format nowait.n or wait.n, where n is the number of users.
user
The user ID the application should run under.
application
The full path to the executable file for the application InetD should start.
arguments
Up to 20 optional arguments that can be passed to the application.
 
Preferred practice: The INET daemon configuration file contains all the information regarding the applications running on its behalf. Make sure not to grant write permission to this file to any person. Keep the access to this file at minimum whenever possible. You can control access to it using ACL rules, like shown in this example.
1. Permit user Joe and group Admins to the file named /etc/inetd.conf with read and write authority:
setfacl -m user:joe:rw-,group:admins:rw- /etc/inetd.conf
The -m option modifies ACL entries, or adds them if they do not exist
2. Set the base permission bits to prevent access by anyone other than the file owner:
setfacl -s user::rw-,group::---,other::---,user
user:joe:rw-,group:admin:rw:rw- /etc/inetd.conf
We recommend starting the InetD by using a shell script in /etc/rc, which causes InetD to be started automatically when z/OS UNIX is started.
The best method to verify that InetD is running correctly is to issue a netstat command to see the listener connections for InetD.
This section does not intend to explain how you can configure and start the InetD on z/OS Communication Server. You can check the IBM Redbooks publication titled IBM z/OS V1R13 Communications Server TCP/IP Implementation: Volume 2 Standard Applications, SG24-7997 for this.
3.6 Virtual IP addressing
In TCP/IP networking, Internet Protocol (IP) addresses are typically assigned to physical network interfaces. If a server has two physical interfaces, a separate IP address is assigned to each of them.
IBM introduced the concept of virtual IP addressing (VIPA) for its z/OS environment to support the use of IP addresses, representing TCP/IP stacks, applications, or clusters of applications, that are not tied to any specific physical interface. The association between VIPA and an actual physical interface is subsequently accomplished using either the Address Resolution Protocol (ARP) or dynamic routing protocols (such as OSPF).
3.6.1 Security concepts and architecture
VIPA provides a foundation technology solution for enhancing the availability and scalability of a z/OS system by providing the following capabilities:
•Automatic and transparent recovery from device and adapter failures
When a device (for example, a channel-attached router) or an adapter (for example, an OSA-Express adapter) fails, then another device or link can automatically provide alternate paths to the destination.
•Recovery from a z/OS TCP/IP stack failure
Assuming that an alternate stack is installed to serve as a backup, the use of VIPAs enables the backup stack to activate the VIPA address of the failed stack. Connections on the failed primary stack will be disrupted, but they can be reestablished on the backup using the same IP address as the destination. In addition, the temporarily reassigned VIPA address can be restored to the primary stack after the cause of failure has been removed. When Dynamic VIPA (DVIPA) is used, the VIPA takeover can be automatic, while the static VIPA must be taken over with an operation (using the OBEYFILE command).
•Limited scope of a stack or application failure
If DVIPA is distributed among several stacks, the failure of only one stack affects only the subset of clients connected to that stack. If the distributing stack experiences the failure, a backup assumes control of the distribution and maintains all existing connections.
•Enhanced workload management through distribution of connection requests
With a single DVIPA being serviced by multiple stacks, connection requests and associated workloads can be spread across multiple z/OS images according to Workload Manager (WLM) and Service Level Agreement policies (for example, quality of service, or QOS).
With the use of a DVIPA, nondisruptive movement of an application server to another stack is allowed so that workload can be drained from a system in preparation for a planned outage.
 
Preferred practice: When implementing VIPA follow these practices:
•Always define a VIPA and a VIPA backup to guarantee your environment availability.
•After the VIPA is implemented, exercise a takeover and takeback function in both automatic and manual operation to make sure that it will work in case it is needed.
•In a scenario where you are using an event-stacked DVIPA, an alternative for unique application-instance applications that do not contain the logic to bind to a unique IP address is to use the BIND parameter on the PORT reservation statement. It is usually a good practice to reserve a port for the listening socket of a server application.
•When using DVIPA, if possible, try to distribute it among several stacks. This can guarantee you that if one stack fails it will affect only the subset of clients connected to that stack. If the distributing stack experiences the failure, a backup assumes control of the distribution and maintains all existing connections.
The IBM z/OS Communications Server supports two types of virtual IP addressing (VIPA).
Static VIPA
A static VIPA is an IP address that is associated with a particular TCP/IP stack. Using either ARP takeover or dynamic routing protocol (such as OSPF), static VIPAs can enable mainframe applications communications to continue unaffected by network interface failures. As long as a single network interface is operational on a host, communication with applications on the host persist.
Static VIPAs have the following characteristics:
•They can be activated during TCP/IP initialization or VARY TCPIP, OBEYFILE command processing, and are configured using an appropriate set of DEVICE/LINK/HOME or INTERFACE statements and, optionally, OMPROUTE configuration statements or BSDROUTINGPARMS statements for IPv4 and IPv6 Static VIPAs.
•Using the SOURCEVIPA configuration option, or SOURCEVIPA parameter on the INTERFACE configuration statement, static VIPAs can be used as the source IP address for outbound datagrams for TCP, RAW, UDP (except routing protocols), and ICMP requests.
•They can be specified as the source IP address for outbound TCP connection requests for all applications using this stack with TCPSTACKSOURCEVIPA, or just a specific job and a specific destination through the use of the SRCIP profile statement block.
•The number of static VIPAs on a stack is limited only by the range of host IP addresses that are available for that host.
•They can be moved to a backup stack after the original owning stack has left the XCF group (such as resulting from some sort of failure), by using VARY TCPIP,,OBEYFILE command processing to configure the VIPA on the backup stack.
 
Note: Static VIPA does not require a sysplex (XCF communications) because it does not require coordination between TCP/IP stacks.
Dynamic
A dynamic VIPA (DVIPA) can be defined on multiple stacks and moved from one TCP/IP stack in the sysplex to another automatically. One stack is defined as the primary or owning stack, and the others are defined as backup stacks. Only the primary stack is revealed to the IP network.
TCP/IP stacks in a sysplex exchange information about DVIPAs, their existence, and their current location, and the stacks are continuously aware of whether the partner stacks are still functioning. If the owning stack leaves the XCF group (such as resulting from some sort of failure), then one of the backup stacks automatically takes its place and assumes ownership of the DVIPA. The network simply sees a change in the routing tables (or in the adapter that responds to ARP requests).
In this case, applications associated with these DVIPAs are active on the backup systems, thereby providing a hot standby and high availability for the services. DVIPA addresses identify applications independently of which images in the sysplex the server applications execute on and allow an application to retain its identity when moved between images in a sysplex.
Figure 3-9 shows a simple example of DVIPA that illustrates a failed TCP/IP stack and associated applications.
Figure 3-9 DVIPA address moviment
Dynamic VIPAs are divided in three types:
•Stack-managed DVIPA
•Event-activated DVIPA
•Distributed DVIPA (Sysplex Distributor)
For a more detailed definition of Virtual IP addressing (VIPA), check the IBM Redbooks publication titled IBM z/OS V1R13 Communications Server TCP/IP Implementation: Volume 3 High Availability, Scalability, and Performance, SG24-7998.
3.7 z/OS IP filtering
IP filtering provides a means of permitting or denying IP messages (packets) into and out of the z/OS Communications Server environment at an early stage in message handling (and, therefore, efficiently). By early we mean at a point when the packet is just about to enter the protocol stack and before any applications are executed or any work is performed.
Depending on your security policies, IP filtering capabilities can provide either the primary means of protecting your z/OS environment from network-based attacks or a powerful additional line of defense (when used in conjunction with layers of external firewalls and access control lists). IP filtering is required to identify the IPSec behavior to apply to all traffic.
z/OS Communications Server IP filtering support is packaged with IP Security (IPSec) and is referred to as integrated IP Security because there is a close affinity between IPSec and IP filtering in the z/OS Communications Server. Although you can implement IP filtering without IPSec, you cannot implement IPSec without IP filtering.
IP filtering enables a z/OS system to classify any IP packet that comes across a network interface and take specific action according to a predefined set of rules. An administrator can configure IP filtering to deny or allow any given network packet into or out of a z/OS system with an IP filtering policy. IP filtering provides two functions:
•Packet filtering and logging
•Filtering rules that determine whether IPSec encryption and authentication are required
When a packet arrives over a network interface into the z/OS environment, the IP filtering function running under the TCP/IP stack searches the Security Policy Database (SPD), which is a table that maintains the set of filter rules, for a matching rule against the TCP/IP header. Filter rules have conditions and actions.
Filter rules contain the conditions to apply the rules based on any combination of the following attributes:
•Packet information
 – IP source or destination address (or masked address)
 – Protocol
 – Source or destination port address
•Direction of flow (inbound/outbound)
•Time of day
Filter rules also contain the actions to specify whether the packets that match the filter rule conditions are denied or permitted. The following possible actions can be taken:
•Permit (with or without manual or dynamic IPSec)
•Deny
•Log (in combination with Permit or Deny)
 
What to do when traffic is blocked: When an IP packet is blocked, the source of the packet is usually not informed. However, a possibility is to configure a packet discard action to send an ICMP error when certain traffic is blocked.
To create the IP filtering policy, you must know the resources available in the network, the resources available in a z/OS image, and how they relate to others hosts. Figure 3-10 on page 109 illustrates the basic concept of IP filtering.
Figure 3-10 IP filtering at the z/OS data endpoint
 
Preferred practice: The IP filtering function available on the z/OS Communications Server should only be used to control and protect the resources owned by the z/OS image. In other words, it is not the best use of a z/OS image to have it function as a firewall router (also called a secure gateway). You should rather use specialized network devices that are more suitable and cost-effective as routing firewalls.
The following resources are available in the z/OS image:
•TCP/IP address space and stack (can be more than one stack).
•The network interfaces and their respective IP addresses.
•The servers or clients, which are the address spaces running programs that will either access or be accessed by others hosts (such as TN3270 server, FTP server and client, and IBM DB2) and what interfaces they will be using.
•The direction of the information flow and if routing might be needed.
•Authentication and encryption requirements.
The following network resources should be mapped outside the z/OS image:
•Clients and servers that need to connect to the z/OS image, their IP addresses, and the services required.
•Networks and subnets.
The relationship between the TCP/IP components in a z/OS image and the network resources is translated in the IP filtering implementation. We can call this relationship an IP filtering policy. This policy contains all the rules that permit or deny the access to a z/OS image.
 
Watch out: The implicit deny rules are always created using either the default or the filter policy. Using the IPSECURITY option in the IPCONFIG statement creates the implicit rules that deny all the inbound and outbound TCP/IP traffic in that z/OS image. Therefore, if you code IPSECURITY without either IPSEC statements or filter policies, the stack will be completely inaccessible.
Firewalls are so common that a definition is hardly needed; however, in a large organization the term should be formally defined. A firewall is an implementation (or extension) of an organization’s security policies. A firewall controls and limits access between networks of different security classifications, and sometimes even within a network that is already protected by a firewall. Firewalls can filter based upon port numbers and IP addresses (or networks).
3.7.1 Security concepts and architecture
z/OS IP filtering defines the security parameters based on filter rules. This set of filter rules is called Security Policy Database. The security policy database provides two types of filters policies: the default IP filter policy and the IP security filter policy.
•The default IP filter policy
This policy provides only a basic filtering function (only permit rules and no VPN support). The default IP filter policy is defined in the TCP/IP profile; it contains an implicit rule to deny all traffic. It is intended to filter packets when the IP security filter policy is not available, in such situations that IP security filter policy is configured but the policy agent has not been started or completely initialized.
•IP security filter policy
The policy is intended to be the primary source of filter rules, and it also contains an implicit rule to deny all traffic. It is defined in a policy agent IPSec configuration file and can be generated by the z/OSMF Configuration Assistant.
You can use the ipsec command to switch between the default IP filter policy and IP security filter policy. Figure 3-11 shows a functional view of IP filter policy on z/OS.
Figure 3-11 IP filter policy on z/OS
 
Preferred practice: Consider defining a default policy that has an IPSECRULE to allow one administrative IP address to connect to the TCP/IP stack. In this way, if PAGENT fails to start, you will still have a way to access the stack using TN3270.
3.8 IPSec
IP Security (IPSec) is a suite of protocols and standards defined by the Internet Engineering Task Force (IETF) to provide an open architecture for security at the IP network layer of TCP/IP. IPSec provides the framework to define and implement network security based on policies defined by your organization.
This protocol is mostly used for implementing a virtual private network (VPN). This is due to the fact that IPSec works at the IP networking layer and it can be used to provide security for any TCP/IP application without modification. If necessary, applications can have their own additional security features on top of the underlying IPSec security. Also, unlike TCP-layer-based security implementations (such as SSL/TLS), IPSec can be used to protect both TCP and UDP applications.
 
Preferred practice: IPSec provides flexible building blocks that can support a variety of configurations. There are several protocols and encryption algorithms provided by IPSec to suit the security requirements of your installation. The IPSec security policies can be either defined manually or by using the z/OS MF Configuration Assistant, which creates the IP security configuration file for you. We recommend avoiding a manual configuration to provide a more reliable configuration.
The IPSec standards have also been structured so that they can accommodate newer, more powerful cryptographic algorithms as they become available in the future.
IPSec technology is used to build what is referred to as a virtual private network, because the technology enables an enterprise to extend its network across an untrusted network (such as the Internet) without compromising security. Using IPSec protocols, each host can encrypt and authenticate individual IP packets between itself and other communicating hosts. Organizations can securely and cost effectively extend the reach of their applications and data across the world by replacing leased lines to remote sites with VPN connections. Because Internet access is increasingly available worldwide, companies can now use VPN technologies to reach places where other connectivity alternatives, such as leased lines, are expensive or unavailable.
 
Background information: IBM z/OS Communications Server IP filtering support is packaged with IP Security (IPSec) and is referred to as integrated IP Security because there is a close affinity between IPSec and IP filtering in the z/OS Communications Server. Although you can implement IP filtering without IPSec, you cannot implement IPSec without IP filtering. To configure IP filtering, you must indicate that you are configuring IPSec in the z/OSMF Configuration Assistant. For more information, see 3.7, “z/OS IP filtering” on page 107.
3.8.1 Security concepts and architecture
The IPSec architecture provides a framework for security at the IP layer of IPv4 and IPv6. IPSec defines a unidirectional logical connection between two endpoints. Such secure logical connections between pairs of endpoints are often called tunnels. z/OS Communications Server IPSec implementation refers to two types of tunnels:
•Manual IPSec tunnels
The security parameters and encryption keys are configured statically and are managed by a security administrator manually. Manual tunnels are not commonly implemented. Although simple to establish, manual tunnels are not considered entirely secure because manually configured keys can be compromised easily. Also, with manual tunnels, IPSec keys cannot be changed without deactivating and reactivating the secure tunnels, thus opening up a window of vulnerability during the data transfer.
•Dynamic IPSec tunnels
The security parameters are negotiated, and the encryption keys are generated dynamically. Inadvertent or intentional breach of the security keys with dynamic tunnels is nearly impossible. Thus, dynamic IPSec tunnels are preferred for robust security implementations. The Security Associations (SA) and the encryption keys are negotiated using the IKE protocol, which is discussed in more detail in the RFC5996 bullet on page 114.
 
Preferred practice: Consider using dynamic tunnels rather than manual tunnels. Manual tunnels are not considered a secure form of IPSec.
The concept of a Security Association is fundamental to IPSec, defining the security characteristics of the traffic that is carried across the tunnel. The span of protection of an SA can vary. For example, the SA can protect traffic for multiple connections (all traffic between networks), or the SA can protect traffic for a single connection.
IPSec can provide a secured connection and an encrypted payload with its implementation. The authentication proves data origin authentication, data integrity, and replay protection, which are explained as follows:
•Data origin authentication confirms that the data origin was from a device that knows the correct cryptographic key.
•Data integrity proves that the contents of a datagram have not been changed because the authentication data was created.
•Replay protection prevents an attacker from sending bogus IPSec packets resulting in unnecessary cryptographic operations. For example, if an attacker kept retransmitting the Encapsulating Security Payload (ESP) last packet sent, replay protection will prevent that packet from being decrypted and authenticated each time. The sequence number in the IP header is always in clear text.
The Authentication Header (AH) protocol is the IPSec-related protocol that provides authentication. The Encapsulating Security Payload (ESP) protocol provides data encryption, which conceals the content of the payload. ESP also offers authentication. The Internet Key Exchange (IKE) protocol exchanges the secret number that is used for encryption or decryption in the encryption protocol.
As shown in Figure 3-12 on page 113, AH and ESP support two modes types:
•Transport mode
This mode tells IP how to construct the IPSec packet. Transport mode is used in host-to-host scenarios in which the two endpoints of the tunnel (the security endpoints) are the same as the host endpoints (the data endpoints). With transport mode, the IP header of the original transmitted packet remains unchanged.
•Tunnel mode
Tunnel mode is most frequently used when either the endpoint of the tunnel is a router or a firewall. With tunnel mode the security endpoints are separate from the data endpoints. With tunnel mode, a new IP header is constructed and placed in front of the original packet.
Figure 3-12 Transport and tunnel mode
Key components
Below we provide a brief description of the three most important IPSec components implemented by z/OS Communications Server:
•RFC 4302
The first component is the IP Authentication Header (AH) protocol. It provides data authentication, IP header authentication, and data origin authentication. IPSec AH authenticates IP packets, ensuring that they came from a legitimate origin host and that they have not been changed. IPSec AH also provides the following features:
 – Data integrity by authenticating the entire IP packet using a message digest that is generated by algorithms such as HMAC-MD5 and HMAC-SHA.
 – Data origin authentication by using a shared secret key to create the message digest.
 – Replay protection by using a sequence number field within the AH header.
•RFC 4303
The next component is the IP Encapsulating Security Payload (ESP). It provides for data authentication, data origin authentication, and data privacy (encryption). The ESP provides additional protection beyond (or in addition to) AH, as follows:
 – Encapsulating and encrypting the IP packet.
 – Authenticating the IP datagram portion of the IP packet, including most of what is listed under AH — data integrity for all but the IP header, data origin authentication, and replay production. For most users, the authentication protection provided by ESP is already being used for encryption
In the ESP, before leaving a host, outbound packets are rebuilt with additional IPSec headers using a cryptographic key that is known to both communicating hosts. This is called encapsulation.
On the receiving side, the inbound packets are stripped of their IPSec headers (decapsulated) using the same cryptographic key, thereby recovering the original packet. Any packet that is intercepted on the IP network is unreadable to anyone without the encryption key. Any modifications to the IP packet while in transit are detected by authentication processing at the receiving host and is discarded.
•RFC 5996
The third component is the Internet Key Exchange (IKE), which provides protocols for automated encryption key management. The IKE protocol, which is implemented in z/OS Communications Server by the IKE daemon, manages the transfer and periodic changing of security keys between senders and receivers and is required when implementing IPSec dynamic tunnels.
 
Preferred practice: When the IKE daemon has obtained the IPSec policy, the policy agent can be stopped without impacting the IKE daemon. However, any changes to the IPSec policy are not detected until the policy agent is restarted. The IKE daemon reconnects to the policy agent when it is restarted. Avoid doing that to keep the policies always set and running.
Key exchange, defined in IKE, is normally a multi-step process, as described here and as shown in Figure 3-13 on page 115:
a. First, the partners establish a secure logical connection, an SA, and decide on security parameters such as encryption, hashing algorithms, and authentication methods (IKE SA). This connection is sometimes referred to as the phase 1 tunnel or IKE tunnel.
b. After the appropriate security parameters are negotiated, the partners set up a second SA for the actual data transfer (IPSec or child SA). This connection is sometimes referred as phase 2 or IPSec tunnel.
c. Thereafter, the SAs and the session keys are renegotiated periodically. The IKE daemon uses the IP security policies that you define in the policy agent (PAGENT) and manages the keys dynamically that are associated with dynamic IPSec VPNs.
Figure 3-13 IKE concepts
There are two methods of authenticating the IPSec when using dynamic tunnels:
 – Authenticate the IPSec partner with a pre-shared key
 – Authenticate the partner using digital signature mode
The term pre-shared key can be considered a misnomer, because the so-called “keys” are more akin to secret “passwords” that are shared between the IPSec peers to authenticate the partner during the Phase 1 IKE exchange and to provide a value to the Diffie-Hellman exchange that produces a cryptographic key to protect and authenticate the Phase 1 IKE negotiations.
Digital signature mode authentication relies on x.509 certificate exchanges to provide verification of the trusted partner. z/OS supports two digital algorithms: RSA and ECDSA. The certificates are stored in the IKE key rings of the peers, as shown in Figure 3-13. The local identity of an IPSec peer must be configured in the IPSec policy, and it must represent an identity established in x.509 certificate on the local IKE key ring. The remote identity of an IPSec peer must also be configured in the IPSec policy, and it must represent an identity established in the x.509 certificate presented by the remote IKE peer during Phase 1 negotiations.
When implementing digital signature mode on z/OS, certificate management services can be provided at the local z/OS IKE daemon (IKED) or by a Network Security Services daemon (NSSD) running locally or in another, more secure network zone on z/OS. IKED supports local digital signature mode for IKE version 1 (IKEv1) negotiations only, but NSSD supports both IKEv1 and IKE version 2 (IKEv2).
 
Preferred practices:
The z/OS Communications Server supports IKEv2 in addition to IKE version 1(IKEv1). IKEv2 has better performance and operational characteristics than IKEv1. Many government agencies expect the vendors who do business with them to use IKEv2 to establish secure communications with them. Consider using IKEv2 to increase security over IPSec use.
If you are setting up a production environment, consider setting the IkeSyslogLevel and PagentSyslogLevel to low to avoid a performance impact from excessive logging.
You can find more detailed explanations of how to configure and implement IPSec in the IBM Redbooks publication titled IBM z/OS V1R13 Communications Server TCP/IP Implementation: Volume 4 Security and Policy-Based Networking, SG24-7999.
3.9 z/OS Intrusion Detection Services
In this section we cover the z/OS Intrusion Detection Services (IDS). Intrusion is a term used to describe undesirable activities in an IT environment. The objective of an intrusion might be to acquire information that a person is not authorized to have. It might be to gain unauthorized use of a system as a stepping stone for further intrusions elsewhere. It might also be used to cause an organization harm by rendering a network, host system, or application unusable. Most intrusions follow a pattern of information gathering, attempted access, and then destructive attacks. Intrusion detection services (IDS) guard against these intrusions, providing protection against potential attackers.
Intrusion Detection Services (IDS) is a z/OS Communications Server security protection mechanism that inspects inbound and outbound network activity, and identifies suspicious patterns that might indicate a network or system attack from someone attempting to break into or compromise a system. IDS is integrated into the TCP/IP stack’s processing and can detect malicious packets that are designed to be overlooked by a firewall simplistic filtering rules. IDS provides a reactive system whereby it responds to the suspicious activity by taking policy-based actions that include the ability to drop attack packets. It can also limit TCP and UDP traffic by dropping packets that exceed the configured connection limit or receive queue length.
3.9.1 Security concepts and architecture
Figure 3-14 shows an overview of the IDS architecture with all the components involved.
Figure 3-14 Intrusion Detection Services architecture
IDS functions can be divided into the following three areas:
•Scan detection
•Attack detection
•Traffic regulation
A well configured IDS can add another layer to the security structure of your environment. On the other hand, it might cause you a lot of problems and false-positive findings if not configured properly and not well adapted to your business goals.
IDS is managed through policies. The policies are determined by the network administrator and are based on preconceived events. The policies must include factors such as who, what, where, when and how:
•Who is allowed to connect to the host?
•What applications or ports are clients allowed to use?
•Where is the attack, intruder, or traffic emanating from?
•When should I consider something to be an attack or scan?
•How is my system affected by the attack, scan, or traffic?
IDS policies can be defined and stored in a policy agent configuration file and an LDAP server. This solution provides an IDS policy solution that is consistent with other policy types for installations that do not have an LDAP infrastructure in place or that favor using configuration files rather than an LDAP configuration.
The policy agent configuration file can be created with the stand-alone version of the z/OSMF Configuration Assistant or the one running under z/OSMF. In this section, we cover only the policy agent configuration file that is created with the z/OSMF Configuration Assistant running under z/OSMF.
The policy information is loaded into the policy agent application during PAGENT startup. All IDS policies allow the logging of events to a specified message level in syslogd or the system console. Most IDS policies support discarding packets when a specified limit is reached, and they support writing statistics records to the INFO message level of syslogd on a specified time interval, or if exception events have occurred.
 
Preferred practice: Check your LDAP server log or command output for errors encountered when your policies are loaded into LDAP. Some LDAP servers treat consecutive blank lines in an LDIF file as end-of-file; ensure that all of the policy objects in your LDIF files are acknowledged by LDAP.
In addition, check your policy agent log file for errors while processing your policy.
And finally, use the pasearch command to verify that the intended policies are active and have the expected attributes for the target stack.
Most IDS policies also support tracing all or part of the triggering packet to an IDS-specific CTRACE facility, SYSTCPIS. IDS assigns a correlator value to each event. Messages written to the system console and syslogd, and records written to the IDS CTRACE facility, all use this correlator. A single detected event can involve multiple packets. The correlator value helps to identify which messages and packets are related to each other.
 
Preferred practice for creating policies: The GUI can potentially reduce the amount of time that is required to create IDS policy files, contributing to ease configuration and maintenance. Because of the inherently complex nature of z/OS security, using the GUI can help you ensure that you have a consistent and easily manageable interface for implementing your IDS.
The IDS implementation provides you with policy samples, which you can use rather than configuring your own from scratch. We recommend starting by using the samples and to adapt them whenever possible. This can help you build less error-prone policies because you will have to deal with a very large variety of attributes.
 
Preferred practice for acting on intrusions: The IDS and its scan policies do not provide the ability to reject a connection. The actual rejection of the connection based on the source IP address must be configured in the traffic regulation policy or firewall.
If possible, try to use Tivoli NetView to manage your IDS. Tivoli NetView for z/OS provides local management functions for IDS and the ability to trap IDS messages from the system console or syslogd and take predefined actions based on IDS type events such as:
•Route IDS messages to designated NetView consoles
•Email notifications to security administrators
•Run trmdstat and attach output to email
•Issue pre-defined commands
See “Configuring NetView for z/OS” for more information:
Next, we examine the three types of policies:
Scan policy
Scans are used to gather information about a system. Scans are usually not harmful and can be part of normal operations, but many serious attacks are preceded by information-gathering scans. For example, a port scan can determine which ports are open on a system and, therefore, are potentially vulnerable to attacks.
z/OS Communications Server detects a scan when multiple unique information gathering events from a single source IP address occur within a defined period of time. Because most scans use consistent source IP addresses, they can be monitored and the data processed to help prevent an attack or determine the origins of a previous attack.
The scanner is defined as a source host that accesses multiple unique resources (ports or interfaces) over a specified period of time. The number of unique resources (threshold) and the time period (interval) can be specified in the policy. Two categories of scans are supported:
•Fast scans
During a fast scan, many resources are rapidly accessed over a short time period. They are usually program-driven and take less than 5 minutes.
•Slow scans
During a slow scan, resources are accessed intermittently over a longer period of time (sometimes over many hours). A slow scan can occur when a scanner is trying to avoid detection.
A fast scan scenario might be one in which an attack is based on the information provided through a program that loops through ports 1 - 1025 (normally the ports used by the server for listening ports), determining which ports have active listeners. This information can be the basis for a future attack.
A slow attack is more deliberate. Occasional packets can be sent out to different ports over a long period of time with the same fundamental purpose: obtaining host information.
The same port being accessed will not generate multiple event records, for example, if a client with the same source IP address generates 20 connections to port 23 (TN3270 telnet server) it will not be considered a scan due to the fact that one unique resource has been accessed.
Scan policy parameters
A scan policy provides the ability to control the following parameters that define a scan:
•Fast scan time interval
•Slow scan time interval
•Fast scan threshold
•Slow scan threshold
•Exclude well-known legitimate scanners using an exclusion list
•Specify a sensitivity level by port or port range (to reduce performance impacts)
•Notify the installation of a detected scan through a console message or syslogd message
•Trace potential scan packets
The policy allows the administrator to set a sensitivity level, which is known as policy-specified sensitivity. This sensitivity level is used in parallel with the categorization of the individual packets to determine whether a packet should be counted as a scan event. The event classification defines a possibly suspicious or very suspicious event. This logic is used to control the performance impact and analysis load of scan monitoring by only counting those individual packets where the chart indicates a count value. This value is then added with the current count total of scan events and compared with the threshold value to determine if the threshold has been met or exceeded in a specified time interval.
Scan events
Scan events are classified into Internet Control Message Protocol (ICMP), UDP port, and TCP port scan categories. The scan events are described here:
•ICMP scan
ICMP requests (echo, information, time stamp and subnet mask) are used to obtain or map network information. The type of ICMP request determines the event classification.
•ICMPv6 scan
ICMPv6 echo requests are used to obtain or map network information.
•TCP port scans
TCP is a stateful protocol. Most events can be classified as normal, possibly suspicious, or highly suspicious.
•UDP port scans
UDP is stateless. The stack is unable to differentiate between a client port and a server port. A scanner sending messages to many ephemeral ports looks similar to a DNS server sending replies to many clients on ephemeral ports. TCP/IP configuration allows UDP ports to be RESERVED, therefore restricting a port so that it cannot be used.
False positive scans
The IDS attempts to reduce the recording of false scan events. This can be manually coded in the policy by excluding a source IP address, port, or subnet. This can be useful if you have a particular client that probes the TCP/IP stack for general statistical information. Also, only unique events from a source IP address are counted as a scan event. An event is considered unique if the four-tuple values (client IP address, client port, server IP address, and server port) and the IP protocol are unique for this scan interval. In the case of ICMP, a packet is unique if the type has not been seen before within this scan interval.
Attack policy
An attack is defined as an assault on system security. An attack is usually an intelligent act that includes a deliberate attempt to evade security services and violate the security policy of a system. In practice, however, an attack can be inadvertent. For example, a malfunctioning host or application could generate a flood of SYN packets to a host. The security policies will not differentiate between a malicious intent and an accident. And, they should not differentiate because attack policies exist to protect the z/OS host.
In fact, one of the difficulties of attack policies is how to differentiate between a valid user application repeatedly attempting to make a connection and a malicious program trying to inflict damage and penetrate the IT defenses. An attack can be in the form of a single packet or multiple packets. There are two types of attacks, active and passive1:
•An active attack is designed to alter or steal system resources or affect their operation.
•A passive attack is designed to learn or make use of system information, but not affect the system performance and integrity.
The attack policies designed for IDS are based on active attacks. Scanning can be considered a passive attack.
The IDS attack policy allows the network administrator to provide network detection for one or more categories of attacks independently of each other. In general, the types of actions that can be specified for an attack policy are notifications (that is, event logging, statistics gathering, packet tracing), and discarding the attack packets.
The IDS attack types that can be enabled on the z/OS Communications Server are described in Table 3-3 on page 121.
For each enabled attack type, you configure the types of notification that are provided if an attack is detected. Also, you configure whether the packet should be discarded or not.
Table 3-3 Attack categories
Category
Attack description
Actions
Malformed packets
There are numerous attacks designed to crash a system’s protocol stack by providing incorrect partial header information. The source IP address is rarely reliable for this type of attack.
•TCP/IP stack: Always discards malformed packets.
•IDS policy: Can provide notification.
Inbound IPv4 fragment restrictions
Many attacks are the result of fragment overlays in the IP or transport header. This support allows you to protect your system against future attacks by detecting fragmentation in the first 88  bytes of a packet.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause the packet to be discarded.
IP protocol restrictions
There are 256 valid IP protocols. Only a few are in common use today. This support allows you to protect your system against future attacks by you defining those protocols as restricted.
IP protocol restrictions are configured independently for IPv4 and IPv6 because the headers differ. For IPv4, there is an IP protocol restrictions attack type. For IPv6, there is a next header restrictions attack type.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause the packet to be discarded.
IP option restriction
There are 256 valid IP options, with only a small number currently in use. This support allows you to prevent misuse of options that you are not intentionally using. Checking for restricted IPv4 and IPv6 options is performed on all inbound packets, even those forwarded to another system.
IP option restrictions are configured independently for IPv4 and IPv6 because IP options are implemented differently. For IPv4, there is a single IP option restrictions attack type. For IPv6, there is a hop-by-hop option restrictions attack type and a destination option restrictions attack type.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause the packet to be discarded.
UDP perpetual echo
Certain UDP applications unconditionally respond to every datagram received. In certain cases, such as Echo, CharGen, or TimeOfDay, this is a useful network management or network diagnosis tool. In other cases, it might be polite application behavior to send error messages in response to incorrectly formed requests. If a datagram is inserted into the network with one of these applications as the destination and another of these applications spoofed as the source, the two applications will respond to each other continually. Each inserted datagram will result in another perpetual echo conversation between them. This support allows you to identify the application ports that exhibit this behavior.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause packet to be discarded.
ICMP redirect restrictions
ICMP redirect packets can be used to modify your routing tables.
•TCP/IP stack: Will discard ICMP redirects if IGNOREREDIRECT is coded in the tcpip.profile.
•IDS policy: Can provide notification and disable redirects (this can optionally be coded as a parameter in the tcpip.profile).
Outbound raw restrictions
Most network attacks require the ability to craft packets that would not normally be built by a proper protocol stack implementation. This support allows you to detect and prevent many of these crafting attempts so that your system is not used as the source of attacks. As part of this checking, you can restrict the IP protocols allowed in an outbound RAW packet. Generally, you should restrict the TCP protocol on the outbound raw rule. Outbound raw restrictions are configured independently for IPv4 and IPv6.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause the packet to be discarded.
TCP SYN flood
One common denial of service attack is to flood a server with connection requests from invalid or nonexistent source IP addresses. The intent is to use up the available slots for connection requests and thereby deny legitimate access from completing.
•TCP/IP stack: Provides internal protection against SYN attack.
•IDS policy: Can provide notification.
Interface flood
An interface flood is detected when a large number of the incoming packets over an interface is being discarded. Enabling the flood attack allows you to receive notification about the attack.
•TCP/IP stack: Discards the packets.
•IDS policy: Can provide notification.
Data hiding
Detects inbound IP packets that might contain hidden data. Checking is done for both IPv4 and IPv6 packets.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause the packet to be discarded.
TCP queue size
Detects attacks targeting TCP/IP send, receive, or out-of-order queues. Constraint triggered when data on queue for at least 60 seconds or a “fixed” limit of data on queue for at least 30 seconds.
•TCP/IP stack: Storage marked page eligible.
•IDS policy: Can provide notification and cause the connection to be reset.
Global TCP stall
A global TCP stall condition is detected when at least 50% of the active TCP connections are stalled and at least 1000 TCP connections are active.
•TCP/IP stack: No default action.
•IDS policy: Can provide notification and cause all stalled connections to be reset.
EE malformed packet
Malformed EE packets are attempts to crash the EE protocol stack.
•TCP/IP stack: No default action
•IDS policy: Can provide notification and cause the packet to be discarded
EE LDLC check
EE LDLC control packets must flow over the EE signaling port. Control packets received on another port might represent an attacker’s attempt to probe or crash a system.
•TCP/IP stack: No default action
•IDS policy: Can provide notification and cause the packet to be discarded
EE port check
EE packets are expected to use the same source and destination port numbers. Packets received with differing port numbers might represent an attacker’s attempt to probe a system.
•TCP/IP stack: No default action
•IDS policy: Can provide notification and cause the packet to be discarded
EE XID flood
An attacker might attempt to consume system resources, or block or delay legitimate EE connections, by generating a flood of EE XIDs. This attack type monitors for EE XID timeouts that can result from an attacker's spurious XIDs.
•TCP/IP stack: No default action
•IDS policy: Can provide notification
Traffic regulation policy
The two types of traffic regulations policies are as follows:
•TCP traffic regulation policies
The IDS traffic regulation policies for TCP ports limit the total number of connections an application has active at one time. This can be used to limit the number of address spaces created by forking applications.
•UDP traffic regulation policies
Traffic regulation (TR) policies for UDP are used to limit memory use and queue delay time.
Traffic regulation for UDP connections can be done in two ways: Through the UDPQUEUELIMIT parameter in the TCPIP.PROFILE or by coding a TR UDP policy. If both are in effect, the TR UDP policy takes priority.
 
Preferred practice for reporting, analytics, statistics, and enterprise integration: Intrusion Detection Services for z/OS have a lot of reporting options available that you can use to report about every captured event. It gives you the ability to log the events on the system console, to syslogd, or even both. Try to determine what is the best way for you to keep track of these events.
IDS for z/OS also provides a packet trace feature. Make sure to have all packets traced, so that you can analyze each and every packet destined to your network with malicious intentions.
You can keep statistics for various IDS events that occur. Those statistics can come in handy whenever you need to review your policies or run any forensic activity.
Last but not least you need to understand that the IDS capability on your z/OS mainframe has to be regarded as an additional intrusion defying barrier for malicious attacks. You must also deploy sophisticated network intrusion detection and intrusion prevention services (IPS) for your general network infrastructure, beginning in your DMZ and following all the way through to your subnetworks.
Those IDS and IPS services typically collect overwhelming amounts of data that can best be used in a centralized fashion for enterprise-wide security intelligence. A typical solution for this centralized capability is called a Security Information and Event Management system (SIEM), like IBM Security QRadar® SIEM (shown previously in Figure 3-14 on page 117).
3.10 IP resource security
The next stage to securing your enterprise IP network is to protect the resources on your
IBM system. This can be done through several controls, which range from RACF to IP configuration options. In this section, we explain different controls to give you a better understanding on how to use them within your ecosystem.
3.10.1 SAF controls
The base of all security on z/OS comes from the Security Access Facility (SAF). The IP stack and the facilities it provides are considered to be a protected resource in the same sense as data sets or other authorized functions of the system. The z/OS IP stack uses SAF to protect itself, through resource profiles defined in the SERVAUTH resource class. This is controlled by a security manager such as IBM RACF. The SERVAUTH resource class can control a wide variety of IP functions, from displays of network information to the ability to connect to other resources within your enterprise.
This is the general profile format of the SERVAUTH class for TCP/IP:
EZB.resource_category.system_name.job_name.resource_name
Where:
•EZB designates that this is a TCP/IP profile.
•resource_category is the capability area to be controlled.
•system_name is the name of the operating system, and can be used as a wild card.
•job_name is the job name associated with the resource access request (stack name) and can be wild carded.
•resource_name is optional and can further refine the resource to be protected.
For example, access to stack TCPIP1 on MVS1 can be protected by defining the resource EZB.STACKACCESS.MVS1.TCPIP1 and granting individual users access to the resource in the SAF-based product in use.
These are the main categories of resource protection (resource_category):
STACKACCESS The STACKACCESS control category regulates access to the stack.
PORTACCESS The PORTACCESS control category is used with a resource name specified on the PORT or PORTRANGE statement after the SAF keyword.
NETACCESS The network access control category is used with the NETACCESS block of statements to divide the external network into security zones and limit access by zone (resource_name).
NETSTAT The NETSTAT access control category is where access to particular netstat options may be limited by defining profiles with the options as the resource_name.
PAGENT The PAGENT access control category limits access to the pasearch command. Access may be limited by policy type (IDS, QoS) by specifying the profile with the policy type as the resource_name.
SNMPAGENT The SNMPAGENT access control category allows the ability to control use of SNMP subagents that connect to the TCP/IP SNMP agent.
MODDVIPA The utility program control limits the ability to create new dynamic VIPAs within a VIPARANGE by using the MODDVIPA utility.
FTP The FTP SITE command access control category limits the ability to use STE DUMP and DEBUG commands, because these can write significant amounts of output. The resource_name is specified as SITE.DUMP and SITE.DEBUG, respectively.
FRCAACCESS The Fast Response Cache Accelerator (FRCA) access control category limits the ability to create an FRCA cache.
SAF security packages and resource definitions
TCP/IP will always make the resource authorization check when one of those categories of access is encountered. The SAF interface provides for notification of three different conditions as a result of the check:
•0, the access is permitted
•4, the resource is not defined
•8, the access is not permitted
z/OS TCP/IP treats the 4, resource not defined, condition as meaning that the access is permitted. In other words, defining the resource means that access control is wanted, but in the absence of such a definition, resource access control is not wanted. Unfortunately, not all security products return all three conditions. ACF2, for example, treats a resource being undefined as an access check failure, and returns condition 8, access not permitted.
The way to deal with this is to define enough resource profiles to satisfy the security needs, and then to permit unrestricted access to those categories where access control is not an issue. If the entire stack is to have unrestricted access initially, the profile EZB.*.*.* could be defined, with unrestricted access, and the security checks would always result in access being permitted.
3.10.2 Multi-level security
Multilevel security is the strictest method of implementing platform hardening for an operating system. It involves labeling all of the resources and users within a system and basing their security access on the labels that were assigned.
Unlike single-level security systems (such as workstations), where there is no ability to properly label information and user sessions, multi-level security (MLS) systems allow you to tag data and user sessions to ensure that the information is controlled and information write-down is prevented. Information write-down is the accidental or intentional declassification of information by allowing it to be written to a resource with an incorrect security label.
There are a group of attributes that must be configured for MLS to determine the type of data and if an application or user should have access and the ability to write that information to another place.
•Security level
This is the familiar term dealing with the sensitivity of information and a person's clearance to process it.
•Category or compartment
There might be a category for accounting, another for logistics and another for cryptographic methodology. Categories are used to enforce need to know policies.
•Security label
A security label (seclabel) is an eight character name. It represents a particular security level and a set of categories that are defined in the security server.
•Equality, equivalence and dominance
These are special checks that are done using a seclabel to ensure that information is handled appropriately.
•Profile name
Authorized programs that manage access to data, network and other resources are assigned resource classes by the security server. Those programs then document how to form a profile name that represents the resources it wants to protect.
Some of the applications that have this capability are:
•OMPROUTE
•Ping
•UNIX FTP Server
•UNIX Telnet Server
•TN3270
Although this security technique provides a lot of security, it also incurs a large cost in administrative overhead. It is not recommended that you use this technique unless your requirements dictate that you implement this level security.
3.10.3 OSA-Express connection isolation
In a typical data center environment, OSA-Express interfaces are shared among multiple TCP/IP stacks due to their large available bandwidth (1 GbE or 10 GbE) and as a means to minimize infrastructure costs. In some instances, the sharing of resources also presents a security risk because the OSA-Express adapter can internally route IP packets directly to a TCP/IP stack that shares the same port.
OSA-Express connection isolation is a way to prevent IP communication between two TCP/IP stacks that share the same OSA-Express port. It also provides extra assurance against a misconfiguration that might otherwise allow such traffic to flow. When OSA-Express connection isolation is in effect, the OSA-Express feature discards any unicast packets when the next-hop address is registered by a TCP/PI stack sharing the same port and prevents any multicast or broadcast packets from being internally routed between the TCP/IP stacks sharing the port.
OSA-Express connection isolation can also be useful if you want to ensure that traffic flowing through the OSA adapter does not bypass any security features implemented on the external LAN.
 
Note: Dynamic routing protocols such as OSPF are not aware of OSA-Express connection isolation, which can be an issue if static routes are not used and traffic needs to flow between the TCP/IP stacks that share the OSA adapter using connection isolation.
3.10.4 IP Profile Controls
Within the TCP/IP profile, there are mechanisms that the system programmer can enable to reduce the security risk exposure. In this section, we describe some of the more useful parameters available to the system programmer to secure the mainframe environment.
FinWait2 timer
TCP is a connection-oriented protocol. Thus, before a new connection is established there is a three-phase handshake that must occur. The handshake consists of the following phases:
•Hello Phase
•Ready to Start
•Begin Connection
The Hello Phase is sent from the client to the server. The Ready to Start phase is sent back to the client from the server. Finally, the client sends the Begin Connection message back to the server.
Malicious attackers have used this innocent process to attack systems using what is called a SYN flood attack. A SYN-flood is when you have one or more clients initiating a TCP connection to a server but never sending the final phase. A stack can quickly be overwhelmed by keeping requests open while attempting to serve new connections. On the TCPCONFIG statement there is an option called FINWait2time that can be used to tune the time that a system will allow a TCP handshake to be between the second and third phase before closing the connection.
 
Preferred practice: The recommendation is to not keep the default, which is five minutes, but change the value to be 75 seconds. This provides ample time to complete the TCP handshake protocol, and it frees resources quickly enough to avoid a successful SYN-flood, in most cases.
RestrictLowPorts
The two most common transport layer protocols, TCP and UDP, both use port numbers to separate which application is talking to which client. There are a defined group of well known ports that are a set of services defined by the IETF — ports 1-1023. These ports are used for applications such as TN3270, FTP, ISAKMP, and many other basic services. It is a common practice for an attacker to start a new service masquerading as a well-known application bound to one of these well known ports. Instead of connecting to a legitimate application, a user would get the malicious application giving up information like user IDs and passwords unknowingly. We can configure the IBM Communication Server for z/OS to protect these well known ports from any random user accessing them.
 
Preferred practice: Enable the RestrictLowPorts keyword in the TCPCONFIG and UDPCONFIG statements to prevent any service from binding to one of the well-known ports unless they are defined in the PORT list in the IP profile.
Port definition
Port numbers are the doorway into your system for the TCP and UDP protocol. It is important to control port access, so that only specified applications can access specific ports. You can reserve ports using the PORT or PORTRANGE profile statements. These statements allow you to reserve ports for well known or configured ports for the applications that need to bind to them. For example, let’s say you have a TN3270 server, an FTP daemon, and a local server. You could code the following ports:
23 TCP TN3270S Only an application called TN3270S will be able to bind to this port.
21 TCP FTPD* Any FTP daemon that starts with FTPD can use this port.
5000 TCP * Any server can bind to this port.
5001 TCP RESERVED The port is not available for use by any user.
If you wanted to further secure these ports, you can add an optional SAF parameter to provide additional access control. If you specify the SAF keyword in the PORT or PORTRANGE statement, it can provide additional access control by verifying that the user ID associated with an application at the time of a bind to the port is authorized to access the port.
You need to define an SAF SERVAUTH profile, such as this example:
EZB.PORTACCESS.sysname.stackname.port_safname
Where port_safname is the same value that you specify on the SAF keyword of the PORT or PORTRANGE statement. The user ID that is associated with the application at the time of the bind request must have READ access to this resource for the application to be able to bind to the port.
Now, to modify the previous example: If we have a group called STCGRP that all of the started task user IDs were part of, we could define the following:
•Define RACF PORTACCESS profiles:
RDEFINE SERVAUTH EZB.PORTACCESS.LPAR.TCPIP.STARTED UACC(NONE)
PE EZB.PORTACCESS.LPAR.TCPIP.STARTED CLASS(SERVAUTH) USER(STCGRP) ACCESS(READ)
•Modify the port statement:
23 TCP TN3270S     STARTED
21 TCP FTPD*       STARTED
5000 TCP *
5001 TCP RESERVED
Only the started tasks that match both the name and the started task user ID will be allowed to bind to ports 21 and 23.
UNRSV
Because there are over 65,000 ports to a stack, it would be time-consuming to reserve all of the ports. So you can use the UNRSV keyword to lock down all of the other ports on your stack. Note, you only want to do this for server ports because clients will need to grab a random port to connect to another server. It is recommended that at the end of your port statements you add the following instruction:
UNRSV TCP DENY WHENLISTEN
1 These definitions are excerpts from the Internet Security Glossary, Version 2, RFC 4949: https://tools.ietf.org/html/rfc4949
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset