Enterprise Knights of IBM Z - Group home

Thwarted by IBM Z! - Episode 10

  


Good Networking - six z/OS network security technologies you should know about


I've had multiple conversations with z/OS administrators and system programmers who figured that, between using TLS on z/OS and their company's firewalls, their z/OS systems had plenty of protection from a network security perspective.  Each time, I've explained that while firewalls and TLS are extremely important, they alone do not constitute iron-clad network security for z/OS.  So what other measures can be taken?   Glad you asked!

Here are six z/OS TCP/IP network security technologies that you should know about and explore.  And make sure to check out the link at the bottom to a new digital badge that digs into each of these in more detail...

1. IP packet filtering

Think of this feature as a "personal firewall" of sorts for your z/OS TCP/IP stack that can control whether or not specific IP traffic is allowed to flow into and out of the stack.

IP packet filter rules describe IP traffic based on packet attributes such as source and destination IP address, transport protocol (TCP, UDP, etc.) source and destination ports (if applicable), packet direction and so forth.  The rules also indicate whether an IP packet that matches the rule should be permitted to proceed to its destination.  You can also configure rules to control TCP connections based on the connection direction. Packet filtering is part of the IP Security function of the TCP/IP stack.

IP packet filtering rules are configured through the z/OSMF Network Configuration Assistant (NCA) and are installed into the TCP/IP stack by the Policy Agent.
For more information on IP packet filtering, check out this blog entry that Joyce Anne Porter and I published back in March of 2021.


2. Defensive filters

These are a special form of IP packet filter that are created and managed dynamically through the z/OS Unix ipsec -f command instead of through configuration. If you think you're under attack from a certain IP address, you can quickly install a defensive filter to block traffic from the suspect IP address without having to go through your usual configuration workflow (which in some shops could mean days or weeks if tied to change windows). 

Defensive filters require IP packet filtering to be enabled on the TCP/IP stack.  Since they are created with the ipsec -f command, defensive filters can be created manually on a command line or they can created automatically as by an SIEM over an SSH session.

See the z/OS Communications Server IP Configuration Guide topic on defensive filtering for more information.

3. TCP/IP Intrusion Detection Services

The z/OS TCP/IP stack supports a variety of intrusion detection services which are configured through the NCA and installed into the TCP/IP stack by the Policy Agent.

While z/OS IDS does not replace network-based IDS or IPS devices, it does serve as a nice complement to such devices.  These built-in IDS functions fall into three main categories:
    • Scan detection, which can alert you through console and/or syslogd messages when a remote IP address is scanning the various TCP, UDP or ICMP resources on z/OS
    • Attack detection, which looks for a wide variety of different attacks at the networking (IP, ICMP) and transport (TCP, UDP) layers of the TCP/IP stack. The z/OS IDS never inspects or analyzes application layer payloads like SQL injection, cross-site scripting, and so forth – that type of detection is left to network-based IDS/IP devices. While some defensive actions can be configured, the primary purpose of z/OS IDS attack detection is to generate notifications in the form of console or syslogd messages when unusual or potentially harmful situations occur. These messages can be logged or can be used to trigger automation in a network monitor or SIEM.
    • Traffic regulation, which comes in two forms:
      • TCP traffic regulation, which limits the number of TCP connections allocated to any single IP address based on the current number of available connections to the target port.
      • UDP traffic regulation, which limits the length of the various internal queues that the stack's UDP layer maintains, effectively limiting the amount of memory that can be consumed at that layer.
 Lots of great capability here.  See the z/OS Communications Server IP Configuration Guide topic on intrusion detection services for more information.

4. Of course, cryptographic network security protocols are a very important part of the z/OS network security story. z/OS supports three such protocols:
  • Transport Layer Security (TLS, which evolved from SSL)

    TLS/SSL protects TCP traffic only, but most of your TCP/IP-based z/OS workloads use TCP.  IBM provides a couple different mechanisms for protecting your TCP-based programs with TLS/SSL on z/OS:
    • You can modify your z/OS application programs to call a z/OS TLS library like System SSL or the Java Secure Sockets Extension (JSSE) directly.
    • You can use z/OS Communications Server’s Application Transparent TLS (AT-TLS) feature, which typically does not require any application changes. AT-TLS is configured through policies built using the NCA.  The Policy Agent installs those policies into the TCP/IP stack, where they are enforced as new TCP connections are established.
          Any of these approaches support TLS versions up to TLSv1.3 and a wide variety of strong cipher suites that include RSA, Elliptic Curve, AES and SHA-2 algorithms

  • IPsec

    z/OS Communications Server provides a full IPsec implementation that can be used to protect TCP, UDP (including Enterprise Extender) or any other IP-based traffic.    Since IPsec is implemented at the network (IP) layer, it is completely transparent to applications and middleware by design.  Like AT-TLS, IPsec on z/OS is configured through the NCA and the generated policies are installed by the policy agent into the TCP/IP stack (which protects application and middleware traffic with IPsec tunnels), and into the z/OS Internet Key Exchange daemon (IKED, which is responsible for negotiating the IPsec tunnels with other nodes).  z/OS IPsec supports peer authentication using X.509 digital certificates or pre-shared keys, a variety of strong AES-based encryption algorithms and a variety of strong SHA-2 and AES-based message authentication/integrity algorithms. 

  • Secure Shell (SSH)

    z/OS ships with an OpenSSH server and client as part of the base operating system.  SSH is popular for its built-in functions, such as terminal emulation, secure file transfer (sftp), and secure copy (scp).  It can also be used to protect general TCP traffic through its port forwarding capabilities.
For more information on z/OS TLS, IPsec and SSH support, see two TechChannel.com articles I wrote a few years ago.  The first one provides a bit more detail on how z/OS support of these three network security protocols, and the second one discusses how to choose between them for different z/OS workloads.


5. z/OS Encryption Readiness Technology (zERT)

With the number of workloads you run on your z/OS systems and the variety of cryptographic network security protocols available on the platform, it is very important to clearly understand which of your z/OS traffic is cryptographically protected, as well as how that traffic is protected. For example, with so many security researchers out there looking for (and finding!) weaknesses in older versions of the security protocols and the different cryptographic algorithms they use, you need a way to quickly determine which of your z/OS TCP/IP connections are using a weak or vulnerable protocol or algorithm.   This is what zERT does.

zERT monitors and records (via SMF records) the connection endpoint information and cryptographic protection details for every TCP and Enterprise Extender (EE) connection that terminates on the local z/OS TCP/IP stack.  For connections that use recognized security protocols (TLS, SSL, IPsec and SSH), zERT can record the protocol version, individual cryptographic algorithms and key lengths that were chosen and used to protect the connection.   For connections that don't use any of the recognized protocols, just the endpoint information is recorded.  

z/OS Communications Server includes a z/OSMF plugin called the zERT Network Analyzer that ingests zERT SMF records into a Db2 for z/OS database, allowing users to formulate their own customized queries over the ingested data. There are also numerous other products from both IBM and other software vendors that consume zERT SMF data. 

And new with z/OS V2R5 comes zERT policy-based enforcement. With this feature, the z/OS TCP/IP stack uses the zERT data it collects in real-time to enforce your local network encryption standards through sets of rules you configure through the NCA and install into the stack with the Policy Agent.

zERT is a must if you use cryptographic network protocols on z/OS.  For more information, a good place to start the zERT "all-on-one" page.


6. SAF resources in the SERVAUTH class

Of course, when you think about security on z/OS, SAF-compliant security managers like RACF, ACF2 and Top Secret, come to mind, right? Well rest assured, there are plenty of networking-specific SAF resources you can leverage in the SERVAUTH class. 

z/OS Communications Server offers almost fifty different SAF resources to control a wide variety of networking-related functions.  There are far too many to cover here, but just as an example, let's look at two very powerful ones you should know about:

  • PORTACCESS resources control which z/OS user IDs are allowed to establish themselves as listeners on a given TCP or UDP port or port range. This can be very effective in preventing unauthorized or even malicious servers from being established on your z/OS system
  • NETACCESS resources, which you configure in the TCP/IP profile data set, represent different zones of your TCP/IP network and control which z/OS user IDs are allowed to communicate with those network zones. NETACCESS resources can also be used by z/OS applications to control ports of entry based on the remote communication partner's IP address.   These controls can be used to ensure that only authorized user IDs are communicating with specific subnets or even specific IP addresses, and that client user IDs for specific z/OS services (like Db2 and FTP, for example) are accessing those services from authorized IP addresses.
Again, there are lots more resources at your disposal.  For more information on SERVAUTH class resources, see the z/OS IP Configuration Guide topic on TCP/IP resource protection. 


I hope this quick tour of primary z/OS network security capabilities is helpful and inspires you to explore new ways of locking down your z/OS systems from a network perspective.   A great way to get started is to earn the z/OS Network Security - Foundations digital badge!    Remember, it's not just about TLS and firewalls!