A Achieving PCI DSS Compliance #

This task is embedded into the requirement to identify, document and justify all services and protocols running on a system. A special interest are services and protocols that could lead to a security risk. If an insecure service or protocol is used, it must be evaluated to understood its potential security impact. Services or protocols that are not necessary for the business to function should be disabled or removed.

Inbound traffic filtering rules can be defined from the YaST firewall module. Systems with multiple interfaces can be configured to make the SSH daemon only reachable on the administration interface and not on the general network card. Furthermore, it is possible to define the source addresses that a service allows traffic from.

Usually all outbound system traffic is allowed by the SuSEFirewall2 script. Therefore outbound rules need to be defined manually inside the SuSEFirewall2 custom script. Activate the custom script inside the general SuSEFirewall2 configuration file /etc/sysconfig/SuSEfirewall2 by uncommenting the FW_CUSTOMRULES line.

To add an outbound rule, add an appropriate iptables command line inside the fw_custom_after_chain_creation() function. This function hook is executed during the firewall setup and allows any customized iptables rule.

For example, to allow only outbound DNS requests over the interface eth0 to server 10.0.0.4, use:

tux > sudo iptables -A OUTPUT -d 10.0.0.4/32 -o eth0 -p udp -m udp --dport 53 -j ACCEPT

Also see the deny all OUTPUT rule described in 1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit “deny after allow” statement. .

The “deny all” rules of other inbound and outbound traffic can easily be achieved with iptables. The INPUT and FORWARD table policies are directly set by the SuSEFirewall2 script, so all unwanted traffic is dropped. Forwarding is usually completely disabled by a kernel parameter and should not be enabled for endpoint servers.

The OUTPUT policy needs to be defined manually inside the custom SuSEFirewall2 script because in general, all outgoing traffic is allowed. The following two rules need to be added to the fw_custom_after_chain_creation() function so that only outbound traffic that is related to an established inbound connection is allowed.

tux > sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

tux > sudo iptables -P OUTPUT DROP

In addition, inbound traffic can also be configured for certain services via the tcp wrapper configuration file /etc/hosts.deny.

Most of the following tasks are about examine and verifying that the defined inbound and outbound rules are really limiting the traffic between and within all network segments, like the DMZ and the Internet, to a needed minimum for full system operation.

There are two ways to implement anti-spoofing measurements in SUSE Linux Enterprise Server:

The SuSEFirewall2 enables connection tracking via iptables. Connections to an interface that has been marked as external are dropped by default. Only connections that associated with an established connection are allowed.

It is possible to define certain services that are allowed to connect to the external interface. However, this must be in compliance with the general security policy.

Keep in mind that the first line of defense against malicious connections from the Internet should be a dedicated firewall system that handles all traffic and acts as a gate keeper. Unwanted connections should never reach the DMZ network. However, simple firewall rules on SUSE Linux Enterprise Server systems can help avoid misconfigurations and act as another line of defense.

A SUSE Linux Enterprise Server system can also act as a router to forward traffic from one interface to another network on a second interface. It is possible to use Network Address Translation (NAT) on the external interface so that no internal IP address is actually exposed to outside. This is done to mitigate the information an external attacker can gather by simply analyzing the network traffic. NAT can also be used on virtualization hosts or container-based environments that connect to the outside via a specific interface.

The configuration of any system service must be evaluated to meet the needed security standards. This goes from limiting the used protocols to only allow currently secure versions and to disable legacy implementations, to the definition of access controls and authentication. The default settings of SUSE Linux Enterprise Server already provide good overall security, but they can be tweaked further.

For example, the following security settings might be relevant:

Default settings can be customized by automating system installation with an AutoYaST profile. This allows rolling out new instances of SUSE Linux Enterprise Server and automatically enabling an evaluated configuration. This setup procedure can also be automated with the SUSE Manager. For more information, see the SUSE Manager documentation at https://www.suse.com/documentation/suse-manager.

By default, SUSE Linux Enterprise Server does not create additional accounts apart from the root administrative user. There are system accounts defined in /etc/passwd, but they are not activated and therefore not directly reachable. This can be validated by checking the lines inside the /etc/shadow file.

In that file, the second column represents the defined password:

As mentioned inside the PCI DSS document, possible sources for industry-accepted hardening standards are:

As the PCI DSS requirements are not specified precisely, there is no direct relationship between hardening standards and specific requirements. However, other hardening resources can also help in complying with these specifications, including Security Guide and Security and Hardening Guide.

To help separate services, use the variety of virtualization and containerization methods included with SUSE Linux Enterprise Server: KVM, Xen, LXC, and Docker.

You can also run SUSE Linux Enterprise Server on third-party virtualization servers like VMware ESX or Microsoft Hyper-V to achieve service separation.

When using the options built in to SUSE Linux Enterprise Server, see:

This is directly related to an item of requirement 1: To allow only services that are really needed and are using secure protocols and settings ( 1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service. ). All parties involved must be aware of the dangers of using insecure communication. Research, clearly document and communicate the risk of using insecure protocols and services.

Enable and disable system services using the following systemctl commands:

To list all available services that are installed on the system and see their status, use the following command:

tux > systemctl list-unit-files --type=service

To add an additional layer of security to insecure services, use VPN tunnels (for example, IPsec). With a VPN tunnel, network traffic of such services can be isolated and all data is protected against eavesdropping, both internally and externally. However, note that the communication is still insecure at the endpoints of the VPN tunnel and that this is only a workaround.

For additional security within SUSE Linux Enterprise Server, use SELinux or AppArmor. However, the setup of these frameworks is beyond the scope of this document:

The Linux kernel is the main system component. It consists of a core image that is extended by kernel modules which are loaded depending on the hardware and system design. For example: Network card drivers are automatically loaded depending on the system’s network card. File system modules can be enabled to extend the Linux kernel’s file system support.

The list of loaded kernel modules is usually quite long and includes modules that are only used occasionally. The kernel module framework allows blacklisting modules and limiting which functionality is loaded.

To block modules from being loaded, configure them via the directory /etc/modprobe.d. For example, the kernel module floppy is only necessary for systems that have a floppy drive. On systems that do not have a floppy drive, prevent the module from loading: Create a configuration file /etc/modprobe.d/00-disable-modules.conf with the following content:

install floppy /bin/true

The floppy module is usually loaded during the execution of the initial RAM disk. Therefore, propagate this configuration change to the initrd file using the mkinitrd script.

tux > sudo mkinitrd

It is harder to remove or restrict application functionality, as functionality is in most cases compiled into the application or library itself. Even cases where deleting a file cleanly removes a functionality are problematic: If the file was installed from an RPM package, it will be reinstalled when the package is updated.

Encrypt all administrative network access: SSH with appropriate configuration settings that fit into the security concept should be the tool of choice.

Administrative access can also be granted via a Web site. In this case, the complete connection chain between the browser and the server system must be encrypted. This is done via TLS and X.509 certificates.

The guidance description of the PCI DSS document says the following about this requirement: “Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”

From an administrator’s point of view, a block device encryption with the Linux Unified Key Setup (LUKS)/dm-crypt offers an abstraction layer that allows the usage of encrypted disks in the same way as unencrypted disks.

Therefore, access control can only be limited with the general ACL permissions that the file system offers. To comply with this requirement, the decryption key used must not be associated with any general login credentials or authentication methods.

When using LUKS, this is usually fulfilled: The password needs to be entered separately when booting, inserting portable devices or manually mounting disks.

LUKS in fully integrated into SUSE Linux Enterprise Server and can be used via YaST to create new partitions.

As described in 3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials). , LUKS/dm-crypt provides full-disk encryption that fulfills this requirement. Access to the stored data is only possible via a decryption password that must be entered when the disk is mounted.

Any connection that transmits sensitive information must be protected against eavesdropping and tampering.

For incoming client requests, use the HTTPS protocol with a secure TLS connection. The authentication is done with a public X.509 certificate that proves to a certain level that the server is the right endpoint the customer is looking for.

SUSE Linux Enterprise Server comes with a set of services and tools that allow protected HTTPS connections. For example, this can be directly done with the Apache HTTP Server or via stunnel that functions as a proxy to offer TLS encryption functionality.

IPsec or other VPN technologies can be used for securing the connection between network segments that are connected via a public network. Such connections can also be secured with a public X.509 certificate. For internal usage, it is possible to use a private Certificate Authority (CA) to sign X.509 certificates and to keep track of trusted keys.

In SUSE Linux Enterprise Server, this can be directly established with strongSwan that is a IPsec-based VPN solution or with OpenVPN that is using a custom security protocol.

To administrate the OS, use SSH. For information about configuring SSH to provide better security, see Section A.3.1, “Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data” and Section A.3.2, “Requirement 2: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters”.

To identify patches that need to be installed to secure your system, do the following:

First, refresh all software repositories, so you have up-to-date information:

tux > sudo zypper refresh

Then use the patch-related commands of Zypper:

To perform updates automatically, the parameter --non-interactive, that is supported by all Zypper subcommands, is helpful.

For more information about Zypper, see Section 6.1, “Using Zypper”.

The standard Unix permissions allow setting Read, Write, and Execution flags to user and group IDs. A general group called others or world defines the access for users that do not fit into the first two groups. This provides a straightforward way to grant or deny access to file system resources.

ACLs provide an extra level of restrictions. It is possible to set read-write access for one user ID and only read access to a second one. The same goes for group IDs.

The commands getfacl and setfacl (on SUSE Linux Enterprise Server shipped with the package acl) allow direct modification of file system resources. For example, to check and set ACL restrictions of the file /tmp/test.txt for the user wilber:

tux > getfacl /tmp/test.txt
# file: /tmp/test.txt
# owner: tux
# group: users
user::r--
group::r--
other::r--

tux > setfacl -m "u:wilber:rw" /tmp/test.txt

tux > getfacl /tmp/test.txt
# file: /tmp/test.txt
# owner: tux
# group: users
user::rw-
user:wilber:r--
group::r--
mask::r--
other::r--

Standard Unix permissions include the so-called Sticky Bit. This allows the execution of certain programs with higher privileges then the user who is executing those programs. The best example of this is the passwd tool that needs to modify the /etc/shadow to change the user password.

For a more gradual approach to explicitly allowing certain operations or behaviors to binaries, use extended capabilities. As an example for a command that uses extended capabilities by default, consider ping (from the package iputils).

ping sends ICMP IP packets over the network card. For this, it needs the CAP_NET_RAW capability to be Effective and Permitted (+ep):

root # sudo getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep

Login access control to the system can be managed using Pluggable Authentication Modules (PAM). There are several modules available in SUSE Linux Enterprise Server that allow setups such as logging the login time, multiple authentication mechanisms and central databases like NIS, LDAP or Active Directory.

For more information about managing permissions, see Chapter 10, Access Control Lists in Linux.

In this context, there are many advantages to using a centralized infrastructure for user accounts like NIS, LDAP, or Active Directory:

However, if you are using local accounts, these can be checked for inactivity when a user is logging in. This module checks the last login time recorded in /var/log/lastlog and calculates the number of days since. By default, access is denied when the inactivity reaches 90 days.

To list the local accounts last login time use the command lastlog.

As stated in 8.1.4 Remove/disable inactive user accounts within 90 days. , a centralized account infrastructure will have this capability. On SUSE Linux Enterprise Server systems, access attempts can be checked and limited with the pam_tally2 PAM module. The module is executed during login time and checks the recorded failed attempts since the last successful login. To check and reset the account status, use the tool pam_tally2.

The PAM module pam_tally2 described in 8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. can be used to lock an account for a given time after a failed login attempt. The parameter unlock_time=1800 must be specified in the PAM configuration. By default, only the administrator can reactivate a locked account.

To authenticate users for administrative access with multiple factors, use the following methods:

For details, see 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. .