SERVAUTH Class Security Features: Protecting Your Mainframe
Tony Amies, software technical director at Vertali, explains how the ESM (RACF|ACF|TSS) SERVAUTH class can be an invaluable—but often overlooked—tool for organizations pursuing a zero trust strategy
Data exfiltration, ransomware, denial of service or any other form of malicious attacks on the mainframe infrastructure typically rely on network connectivity. Gone are the days when it was commonplace to be able to access mainframe systems from external networks. The threat can come from within and in any mainframe estate, especially those with a zero trust policy, the SERVAUTH class can provide the first line of defense.
First Line of Defense
The SERVAUTH class profiles protect a wide range of network-related activities and resources, including who can use the network connections, who can interrogate network components and who can use lower-level programming interfaces, some of which are very powerful, but equally very dangerous when accidentally or maliciously exploited.
There are many profile types that can be defined in SERVAUTH class, some of which require detailed understanding of network technologies and/or co-operative definitions in the TCP/IP configuration. Although this may be common knowledge in some sites, a lesser-known fact is some SERVAUTH profiles default to “PERMIT” when not defined, perhaps unintentionally allowing network activities that should really be blocked. This can lead to incorrect, missing or even dangerous security exposures.
During network security assessments and pen tests performed at large mainframe sites, we have found instances where a generic EZB.** profile has been defined with universal access of READ. This definition may be thought to be safe as more specific profiles were defined to protect the key networking technologies. This catch-all profile inadvertently permitted the use of new communications server technologies as they were released, a good example being able to programmatically trace TCP/IP packet data.
It is this level of complexity that can prohibit the use of SERVAUTH, perhaps due to lack of knowledge, time or of course the fear that adding new definitions could impact production services.
However, a Zero Trust strategy can be largely achieved with just two relatively straightforward profile types in SERVAUTH class: STACKACCESS and PORTACCESS. These two definitions alone can add a considerable layer of security to mainframe systems, but we rarely see them fully defined, thus creating vulnerabilities that can easily be exploited by users without any elevated authorization.
STACKACCESS
The STACKACCESS profile protects who can use TCP/IP services. This does not mean who can log in to an application, but who can use TCP/IP programming interfaces to either initiate or accept a network connection.
In a production environment, the applications that can either create or accept network connections should be well understood, these are typically started tasks or scheduled batch jobs. The default for SERVAUTH class when not defined is “PERMIT”, so without this profile, any user can initiate/accept connections, not just from low/medium level programming languages, but also REXX and more recently python. Many sites either restrict or even block file transfers on production systems. Without STACKACESS protection, any user can use a simple REXX script to send/receive files to another system. This is not difficult; sample REXX procedures to do this are supplied in the IBM samples library.
The solution is simple. Define the STACKACESS profile in SERVAUTH class with universal access of NONE and just give READ access to the users of the started tasks and batch jobs who legitimately require network services. If these are not well known (perhaps they should be) then create the STACKACCESS profile with AUDIT on and monitor the successful accesses. The results may be interesting.
PORTACCESS
The PORTACCESS profiles are equally important. These profiles cooperate with TCP/IP profile definitions to control access to TCP/IP Ports—in other words, which user is authorized to BIND and typically listen on a TCP/IP port to accept incoming connections or to send and receive UDP datagrams on specific ports.
Historically, TCP and UDP ports were protected by JOBNAME, which is far from secure. In many security assessments and pen tests, we see ports protected by jobname only, and a simple batch job can be submitted with that jobname to allocate and use the port. It could be argued that if a port has already been opened by the authorized job or started task, another job with the same name could not be submitted and “steal” the port, but this is security by chance and timing, not zero trust.
Of greater risk are ports defined in the TCP/IP configuration profile with the SHAREPORT option. This allows multiple address spaces to open and accept incoming connections on the same port, typically used for load balancing or failover. In recent pen tests where PORTACCESS profiles have not been implemented, we’ve been able to intercept incoming connections to a production service in a simple batch job running REXX. With AT-TLS providing the encryption/decryption of connections, the REXX was able to see the production data in clear, even though the connection was end-to-end encrypted. Admittedly, it would require considerable work in REXX to fully spoof a production application and intercept data, but this is again security by chance, not Zero Trust.
The simple solution is to define the SAF keyword on the PORT definitions in the TCP/IP configuration and define the accompanying PORTACCESS profiles in the SERVAUTH class. By permitting only the userid associated with the server’s started task, no other user can attempt to steal the port or intercept connections when SHAREPORT is in use.
In addition to protecting the limited number of server ports in use on production systems, a Zero Trust strategy should also protect the ports that are not in use. In TCP/IP there are up to 65,535 ports that can be used per server IP address, so it is clearly not practical to add ESM definitions for what is likely to be tens or even hundreds of thousands of ports. The solution is again simple. The TCP/IP configuration definitions allow a generic keyword to represent “unreserved ports” which can be associated with an SAF profile using the SAF keyword. Only users permitted access to this profile will be allowed to open ports not previously defined. In a production, zero trust environment, it could be argued that no users should be permitted to open an unreserved port, as all ports should be reserved and protected by PORTACCESS.
Wide-Ranging Protection
In summary, the SERVAUTH class in RACF|ACF2|TSS provides protection for a wide number of network-related services and commands. Although the majority default to a “deny” decision if the profiles are not defined, a few default to “allow”, which presents a potential exposure. It is therefore advisable to always define “catch all” profile of EZB.** in SERVAUTH class with a UACC of NONE.
STACKACCESS and PORTACCESS do not require specialist networking knowledge to implement but are perhaps two of the most important tools to support a zero trust strategy. To overcome the risk of inadvertently disabling network access, AUDIT can be enabled on the SERVAUTH profile(s) and monitored to determine who is using the resources being protected by the SERVAUTH profiles.