(This article describes the SERVAUTH resource class, used with IBM mainframe computers as a feature of the RACF computer security software to secure TCP/IP access. This article was updated in August, 2004 to provide minor corrections, to add background information, to describe new functions, to clarify situations where SERVAUTH might be used, and to add comments for auditors. Special thanks to Rob Weemhoff of IBM in the Netherlands for gently pointing out needed corrections.)
The SERVAUTH resource class supports TCP/IP (Transmission Control Protocol / Internet Protocol) security by controlling these functions:
You will probably not want to use all of these functions. However, if your shop is using TCP/IP on MVS, then you will certainly want to discuss at least the first four functions with your network staff and your security staff.
You may want to start by defining SERVAUTH rules in WARNING mode to collect information without disrupting operations.
Please note that the SERVAUTH resource class will also be taking over some of the responsibilities of the TERMINAL class as we shift to the new, extended set of IP addresses. (IPv6 provides many more possible addresses than IPv4.)
As you can see, the SERVAUTH class fills in some important, previously-missing controls for TCP/IP.
Remember that with TCP/IP, each message has an IP address which is used for routing the message,to deliver it to a specific computer or site on the Internet. Each TCP/IP message also specifies a TCP port, that is a number which specifies the application (or server) which is to process the message.
SERVAUTH is easier to understand if you keep in mind the distinction between in-bound access and out-bound access. Think of your MVS mainframe as a platform which supports several servers, such as Websphere. Think of a user named George at his desk running Windows XP with Internet Explorer as a client trying to access the servers on your mainframe over the Internet, or over your internal intranet. When George tries to access your servers, the request is in-bound.
On the other hand, when a program on your mainframe wants to be a server (to talk to clients like George), the request is out-bound. For example, when Websphere or CICS on the mainframe requests a connection to TCP/IP, it is trying to access the Internet (or internet) from within your computer, out-bound.
This may not seem like a request that needs to controlled, until you imagine a system programmer who is about to resign, and who wants to leave a backdoor into your system. If he can install a USS (UNIX System Services) program that makes an out-bound request using some unused port, then he will succeed.
In short, you want to be sure that only authorized ports have been opened in TCP/IP, the same way you want to be sure that only authorized user SVCs have been added to your system. Auditors will start paying attention to this, especially after the first publicized break-in to a mainframe system over the Internet.
Please note that while the examples below use RACF, the other two security software packages (ACF2 and TopSecret) handle SERVAUTH just as well. Computer Associates provides two cookbooks on their website (www.cai.com) for securing mainframes over the Internet. (One cookbook is for ACF2, the other for TopSecret.)
The SERVAUTH class must be RACLISTed, so you might set it up with this command:
and after changing any SERVAUTH rules, you might want to refresh it like this:
Rules in this class all have names beginning: EZB.xxx. where xxx indicates which of the functions is being controlled. (Note that EZB is IBM's abbreviation for TCP/IP.)
The TCP/IP started task uses a control file, often named PROFILE.TCPIP, where the system programmer specifies what options are to be used. Several keywords in this file are used as parts of names of RACF rules, as you will see in the examples below.
This call to RACF is not made for socket() calls issued in the TCP/IP address space, the USS address space, or the VTAM address space. When RACF is called for this check, if there is no matching rule, then all access requests are permitted. At least READ access is sufficient. The userids permitted to this rule should be the userids of servers like FTPD and the HTTPD.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task
This prevents a user from accessing a given network, subnetwork, or host. RACF is called for this check when a TCP/IP packet is sent. You could use this to restrict which users are permitted to access the Internet or your intranet. READ access is sufficient. This use of SERVAUTH is for both inbound and outbound messages, but it is the userids of the servers (not the clients) that should be permitted to it.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task and
netname is the name of the network, subnetwork,
or host as identified in the NETACCESS statement
in PROFILE.TCPIP.
You would use this to prevent a programmer from writing his own programs which use a given port, then executing those programs to "hijack" the port. (For example, such a program might otherwise take over the e- mail port, browse all e-mail, and then pass it on to the real e-mail server.) READ access is sufficient. The userids of servers (not clients) should be permitted for this outbound use of SERVAUTH.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task and
portname is the RACF name for the port, as
specified in the SAF operand of the PORT or
PORTRANGE statement in PROFILE.TCPIP.
This is used to restrict users from using a secure port (where the previous function restricted access to any port). When a port is secured with SSL (Secure Sockets Layer), this use of SERVAUTH prevents unauthorized users from accessing the port. This extra control is used in conjunction with the CLIENTAUTH statement in PROFILE.TCPIP. RACF is called only if the CLIENTAUTH statement specifies SAFCERT. READ access is sufficient.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task and
nnnnn is the port number (zero-filled on the left if
necessary)
This is used to control who can issue the NETSTAT command to collect information about TCP/IP in your installation. READ access is sufficient. If there is no matching rule, then access is allowed. The userids of whoever is authorized to issue the NETSTAT command should be permitted to these rules.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task and
netstatoption is the netstat command option to be controlled
This is used to restrict users from using the Fast Response Cache Accelerator, a performance feature used to speed up servers such as the http server in Websphere. READ access is sufficient. If there is no matching rule, then access is allowed. The userid of the authorized web server, for example the http server, should be permitted to this rule.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task
This is used to restrict users from issuing the MODDVIPA utility program. The MODDVIPA program is used to activate or de-activate a dynamic VIPA (Virtual IP Address, a feature of TCP/IP on MVS that reduces single points of failure). READ access is sufficient. If there is no matching rule, then access is allowed only to superusers. The userid of whoever is authorized to execute MODDVIPA should be permitted to this rule.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task
This is used to restrict users from setting a TCP option called SO_BROADCAST which would allow them to broadcast messages to everyone on the network or subnetwork. READ access is sufficient. If there is no matching rule, then access is allowed. The authorized userid of whatever program is doing the broadcasting should be permitted to this rule.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task
This is used to restrict users from accessing network management information from: packet traces, connection activity, and SMF data, respectively. READ access is sufficient. If there is no matching rule, then access is allowed only to superusers and to users who are permitted to become superusers. The authorized userid of whoever is accessing this data should be permitted to the appropriate rule.
SERVAUTH rules for this function have names like:
where sysname is the name of the MVS system
(&SYSNAME as specified by the MVS system
programmer) and
tcpname is the name of the TCP/IP started task
To audit TCP/IP on an MVS system, you will want to get a copy of the TCP/IP control file (often named PROFILE.TCPIP) for your work papers. You should also get a list of what TCP/IP ports have been authorized and what software uses each port. Use the NETSTAT command in TSO to learn what ports are active.
You should also get a list of all the SERVAUTH security software rules. (In RACF, you would issue the command RL SERVAUTH * ALL.)
Get the name of the TCP/IP started task and a list of the system symbols (such as &SYSNAME) since they will be part of the rule names in the SERVAUTH class. You can use the operator command DISPLAY SYMBOLS to do this.
Of course you would not want to produce a finding for a mainframe TCP/IP audit without assessing the relevant risk, as well as compensating controls. Assessing the risk is best done by considering risks for out-bound requests separately from in-bound requests. Such assessment should also consider what data and applications exist on the mainframe.
Compensating controls for such risk would include: firewalls; intrusion detection software (now included for free with mainframe TCP/IP); controls specified in the file PROFILE.TCPIP; physical access controls; encryption by means of Secure Sockets Layer, Transport Layer Secrurity, or Virtual Private Networks; and controls specified in the control files for server software such as Websphere.
About the Author
Stuart Henderson is a consultant and trainer who specializes in effective IT (Information Technology) audits and computer security. He has helped hundreds of organizations make better use of security software such as RACF, ACF2, and TopSecret. He has also helped these organizations address the technical and organizational issues surrounding cross-platform security. As President of the Henderson Group, he directs a variety of activities in support of the information security and IT audit communities. These include: seminars, consulting services, articles, and speeches. He is an experienced system programmer who has earned the Certified Internal Auditor, Certified Management Accountant, and Certified Data Processor designations. His seminars on computer security and audit of: MVS, DB2, RACF, networks, UNIX, WIndows, and other subjects are taught nationwide. He teaches Certified Information Systems Auditor review courses for the National Capital Area Chapter of the ISACA.
He speaks to groups such as SHARE, the Vanguard conferences, the Computer Security Institute, the DPMA, the ISSA, and the ISACA. Some of his topics have been: "How to Break Into z/OS Systems", "How to Break Into z/OS Systems Through the Internet", "What System Programmers Know that DSOs and EDP Auditors Should (or How I Would Break into Your System and What You Should be Doing to Stop Me)", What Non-Data Processing Executives Should Know and Do About Computer Security", "Combining VAX/VMS Security with IBM Mainframe Security", and "Tools for Maintaining Single Point of Control for Security". He is founder of the New York RACF Users Group and Editor of its newsletter. He also edits the email newsletter "the Mainframe Audit News". His website is at http://stuhenderson.com. He can be reached at (301) 229-7187 or stu@stuhenderson.com. Return to HG Home Page (www.stuhenderson.com)