Security for Linux on System z: Securing Your Network

Securing the network
The first step to set up your virtual environment in a secure fashion is to take care of the items in the following list. Your company most likely has specific requirements, in terms of information security, and these requirements must be considered when you build your own check list. This high-level list can be easily adapted and used for most environments.

• Protect your physical IT infrastructure.
• Secure the logical access to IBM z/VM®.
• Protect your data.
• Protect your virtual network.
• Secure the logical access to the Linux servers.
• Protect your environment from yourself by keeping consistent and auditable system logs.

This document specifically focuses on securing your network environment.

The IBM System z® platform provides a great security advantage when it comes to virtual networking capabilities. Using industry standards and providing various tools to control who can or cannot couple to the virtual devices, System z also provides auditing and troubleshooting functionality. Using Linux on System z, guests with correct connectivity can dramatically reduce physical intrusion points, making the physical infrastructure easier to maintain.

z/VM offers several possible network configurations, such as IBM® HiperSockets™ adapters, and guest LAN and virtual switches. The configuration of these resources is not detailed within this document; for specific configuration details and system requirements, see z/VM V5R4.0 Connectivity, SC24-6080-07. Although guest LANs might be considered as a viable alternative to provide connectivity among virtual servers, we choose to use virtual switches instead of any other z/VM networking options. The features that this technology offers are part of the best practices we discuss in this section. Information about how to use z/VM native functions to protect guest LANs are in “Protecting z/VM guest LANs” on page 28 of this IBM Redbooks publication (Security for Linux on System z, SG24-7728).

To illustrate how to create your virtual network infrastructure in a secure way, by using both the native security and an external security manager (ESM) such as IBM RACF®, see the scenario in Figure 1. It shows that four servers are configured to support an application: two act as web servers that face the Internet, and two act as application servers with tighter security requirements. Observe that for this first scenario, the only way to ensure that the data that is flowing from a server on an Internet-facing exposed network to a more secure network zone is by separating them on two separate subnets. We also assume that the VSWITCH is operating in the data layer.

Figure 1. VSWITCH infrastructure

Securing the virtual switches
The z/VM default configuration automatically prevents users from coupling to a VSWITCH if not explicitly allowed. To create a layer-2 virtual switch, you may use the command syntax that is shown in the following example.

DEFINE VSWITCH VSWITCH3 RDEV 3083 30A3 ETHERNET CONTROLLER *

This command produces the following output:

VSWITCH SYSTEM VSWITCH3 Type: VSWITCH Connected: 0 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Unaware MAC address: 02-00-00-00-00-0A State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF RDEV: 3083.P00 VDEV: 3083 Controller: DTCVSW1 RDEV: 30A3.P00 VDEV: 30A3 Controller: DTCVSW2 BACKUP

If, during creation, no VLAN ID is specified, a VLAN-unaware switch is created and all virtual guests that are coupled to it will be on the same segment, as shown in Figure 2.

Figure 2. VLAN-unaware VSWITCH infrastructure

Without any previous permission, if you try to couple to the VSWITCH from your Linux server, an error occurs, as shown in the following output. The error indicates that you do not have the necessary privileges to couple to the device.

lnxsu1:~ # vmcp couple 700 system VSWITCH3 HCPNDF6011E You are not authorized to COUPLE to SYSTEM VSWITCH3 Error: non-zero CP response for command 'COUPLE 700 SYSTEM VSWITCH3': #6011

If you are not using an external systems manager, such as RACF, you can use the following command to grant LNXSU1 privileges so the user can couple to the VSWITCH:

SET VSWITCH VSWITCH3 GRANT LNXSU1

Similarly, if you must revoke, from any user ID, a permission that was previously granted, use the following syntax:

SET VSWITCH VSWITCH3 REVOKE LNXSU1

If you have to assess the list of users with permission to couple to the VSWITCH, use the following command:

QUERY VSWITCH VSWITCH3 ACCESSLIST

This command produces the following output:

VSWITCH SYSTEM VSWITCH3 Type: VSWITCH Connected: 0 Maxconn: INFINITE PERSISTENT RESTRICTED ETHERNET Accounting: OFF VLAN Unaware MAC address: 02-00-00-00-00-0A State: Ready IPTimeout: 5 QueueStorage: 8 Isolation Status: OFF Authorized userids: LNXSU1 SYSTEM RDEV: 3083.P00 VDEV: 3083 Controller: DTCVSW1 RDEV: 30A3.P00 VDEV: 30A3 Controller: DTCVSW2 BACKUP

After the correct permission is granted to the user ID, LNXSU1 in this example, you can run the following command to dynamically couple the network interface card (NIC) that was previously defined to the virtual switch. The command and its output are as follows:

lnxsu1:~ # vmcp couple 700 system VSWITCH3
NIC 0700 is connected to VSWITCH SYSTEM VSWITCH3

RACF can improve the security requirements, managing policies to grant appropriate access to your systems resources, and can also reduce the risks of security breaches by reducing the number of interactions that are needed to maintain system integrity.

RACF can be used to protect guest LANs and virtual switches by using profiles in the VMLAN class. From an access control perspective, the two are treated the same way. This class contains two sets of profiles to secure access to the network devices:

• A base profile that controls the ability of a user ID to connect to a virtual switch
• An IEEE VLAN-aware virtual switch profile that can be used to assign a user to one or more VLANs

If the VMLAN class is not enabled on your system, you must enable it, for the sake of security and integrity of your network resources. This next example shows the command that is used to activate the class.

RAC SETROPTS CLASSACT(VMLAN)

The base profiles are named userid.name, where userid is the name of the owner of the resource, and name is the name of the LAN. The scenarios we are evaluating contain a virtual switch, not a guest LAN. Therefore, an important note is that, in the case of a VSWITCH, the userid will always be SYSTEM.

The profile for VSWITCH3 is shown here:

RAC SEARCH CLASS(VMLAN) MASK(SYSTEM.VSWITCH3) SYSTEM.VSWITCH3

If a RACF profile is not created for your VSWITCH, you may create it by using the following command:

RAC RDEFINE VMLAN SYSTEM.VSWITCH3 UACC(NONE)

When RACF controls the access to the system resources, having all the users you want to couple to the VSWITCH individually listed in the VSWITCH access list is unnecessary, because the ESM overrides the CP access list. Only SYSTEM remains in the VSWITCH access list; it is automatically added to the list upon the creation of the resource.

Using RACF, the list of users must exist on the ESM database, which for obvious reasons reduces the chances of a leakage of specific information about your network topology, because the information is not kept in a plain text file.

The following example shows the command for granting access, to the LNXSU1 user, to the VSWITCH3 VSWITCH, which is currently managed by RACF.

RAC PERMIT SYSTEM.VSWITCH3 ID(LNXSU1) CLASS(VMLAN) ACCESS(UPDATE)

Note: The UPDATE access is required so that the user can couple to a VSWITCH that is managed by RACF.

It is still necessary to update the device base profile for each server that we want to grant access to the resource. As a best practice for the profile maintenance, grant the desired privileges to the virtual guests based on RACF groups. The use of such groups can also help to run a security audit on your systems. Determining the privileges that a given user has is possible simply by determining the user’s privilege class and the groups that the user is a member of. Be sure that RACF group-list checking is active by issuing the following command:

RAC SETROPTS GRPLIST


Managing coupling to specific virtual switches
To manage who can or who cannot couple to a specific virtual switch, use the following steps:

1. Create a RACF group to hold the list of virtual guests that will be allowed to couple to your VSWITCH. Here, we created a RACF group and named it VSW3GRP:
   RAC ADDGROUP VSW3GRP
   
2. Update your VSWITCH base profile with the privileges that you want granted to this group, as shown here. In this example, we use the group VSW3GRP in the ID field.
   RAC PERMIT SYSTEM.VSWITCH3 ID(VSW3GRP) CLASS(VMLAN) ACCESS(UPDATE)
   
3. As a final step, connect the user, requiring access to this virtual switch, to the group, as shown here:
   RAC CONNECT LNXSU1 GROUP(VSW3GRP)

All new virtual guests, that are to be allowed to couple to the VSWITCH, must be connected only to this group. This step greatly reduces the maintenance efforts and makes the overall access lists audit-ready.