|
Information Security and IS Audit Articles
from the Henderson Group |
This page is: ARTICLES: SERVAUTH |
|
Quick Links: HOME PAGE CONTACT US INFOSEC TRAINING IT AUDIT TRAINING NEWSLETTERS AND USER GROUPS ARTICLES
ABOUT US OTHER INFO SOURCES |
(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
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
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
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
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
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
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
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
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
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.
| ||