Red Card: Specificity of PCI DSS in respect to Red Hat Enterprise Linux (Part 1)

Author: Feodor Kulishov

In the present article, we will discuss configuration of a standard Linux system (as well as the standard software supplied with the distribution kit) in accordance with the PCI DSS by examples of RHEL 5 and Fedora Core 12. For each requirement of the standard, recommended system settings will be given based on the existing technical standards (CIS, NIST, SANS) and the experience in configuring such systems.
RedHat Enterprise Linux was chosen to serve as the target Linux distribution kit, because it receives (along with Novell SUSE Enterprise Linux Server/Desktop) the most widespread support of hardware and software vendors and offers a wide variety of commercial support options. This is why the considered system is widely used in the business society, including the payment card industry. FC12 serves as the base for the future RHEL6.
Note. The present publication represents only one point of view on the problem of auditing the compliance with the PCI DSS requirements. Auditors who examine certain data processing systems can have their own vision of secure settings, which may differ from the recommendations given in this article, because some items of the standard may have various explanations. Nevertheless, this work can serve as the starting point to obtain RH systems that are not only compliant with the standard’s requirement, but also have safe configurations.

What is PCI DSS and why is it necessary

The main developers of the PCI DSS (Payment Card Industry Digital Security Standard) are Visa and Master Card payment systems.

As stated in the «Requirements and Security Assessment Procedures», «…The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. This document, PCI Data Security Standard Requirements and Security Assessment Procedures, uses as its foundation the 12 PCI DSS requirements, and combines them with corresponding testing procedures into a security assessment tool. It is designed for use by assessors conducting onsite reviews for merchants and service providers who must validate compliance with the PCI DSS» ([1]).

The purpose of the article
The considered standard includes a great number of technical and organizational requirements, for example:

  • 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 (1.2.1.b, technical)
  • Obtain and examine documentation to verify that the rule sets are reviewed at least every six months (1.1.6.b, organizational)

The requirements are imposed on the entire infrastructure (related to processing of plastic card data) of the examined object. At the same time, there are universally recognized standards (such as CIS, SANS, and NIST families) and various corporate standards in information security, which give clear recommendations about technical settings of certain target systems. Meanwhile, the problem of matching the PCI DSS requirements with the CIS requirements (for example) for a certain OS presents an involved task.

The situation is complicated by the fact that the PCI DSS requirements often are fuzzy, i.e. it isn’t obvious at first sight what subsystems should be configured to meet them, will the obtained system settings cover all the requirements, and is it technically possible to fulfill a certain requirement at all. On the other hand, CIS and other technical security standards operate with concrete system settings (e.g., CIS even gives scripts performing the recommended actions for UNIX systems).

However, in-depth study of the PCI DSS shows that many requirements that seemed to be unspecific can be fulfilled. The purpose of the given article is to bring the abstract auditing language of the PCI DSS and clear terminology of system administrators and information security specialists together. The RHEL5 and Fedora 12 distribution kits served as the target systems, the latter one was considered to be the basis for RHEL6, which will be released soon and is available in beta version since April 2010. The article structure repeats the PCI DSS one; corresponding technical recommendations are given for every item of the standard.

Publications on topic
There have been many attempts to specify the PCI DSS requirements with regard to certain operating systems, for example, [2], [3], and [4]. However, there was given no complete and detailed description of OS settings in any of these works. The analysis of the requirements didn’t cover the entire technical part and considered only several PCI DSS chapters; in other cases, it was too general and didn’t touch upon the concrete OS settings (commands, configuration files, lists of applicable software, etc.).

General propositions
Hereinafter, we will suppose that only software from standard distribution is installed on the target RHEL system; all exceptions will be specially provided. It is also supposed that hosts controlled by RHEL represent either servers or workstations of data processing network; RHEL servers can also implement certain functions in the DMZ. Configuration of firewalls between the DMZ and the data processing network, as well as between the DMZ and the Internet is not considered in details, because in large organizations, Linux hosts (with general-purpose distribution kits installed) usually don’t serve as routers and security gateways.

Many requirements are purely organizational or their application is illogical for a certain operating system (e.g. many items in the chapter 3 describe the storage procedures for payment card data, while it is normally stored in the database, i.e. on the layer of application, not system software). If a requirement is not mentioned in the text, it means that this requirement is an organizational one or is not applicable to the defined platform. For brevity sake, most PCI DSS requirements are given in the short form.

IMPORTANT: In spite of the fact that OS and application software configuration is obviously important for secure data processing, a considerable part of the PCI DSS is devoted to documentation and deployment requirements. Moreover, many technical requirements imply that certain mechanisms must be not only configured, but also implemented. It means that one should pay proper attention to documentation, at least to pass auditing of compliance with the PCI DSS successfully.

What chapters are wholly inapplicable to the OS
The standard contains chapter 9 (physical access to payment card data), chapter 11 (penetration testing), and chapter 12 (security policy), which do not describe secure OS settings. Thus, these chapters are ignored in the part of OS configuration.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

The chapter begins with purely organizational requirements; the first technical one is 1.1.5.b. As follows from the description, most technical requirements imply configuration of Netfilter and tcp_wrappers (the latter one if necessary). However, the CIS standard for RHEL describes only tcp_wrappers settings (item 3.2) and Netfilter is mentioned just once (in the part devoted to service launching at the system start); the settings of traffic filter rules are not specified there.

Further, there arises a question, what type of traffic do VPN-tunnels to adjacent data processing centers belong to (local traffic, DMZ traffic, or Internet traffic). Moreover, the subsequent standard chapters don’t pay proper attention to VPN-channels. It is also not quite clear, does the standard allow one to transfer the Internet traffic from the hosts in the data processing network through the DMZ proxy servers.

Analysis of the requirements gives us the following recommended network architecture:

  1. The DMZ contains application servers (not DBMS servers!) that are available to third-party clients who access database servers located in a separate protected network through DNAT/VPN.
  2. Boundary routers (located between the DMZ and the Internet and between the protected network and the DMZ) have strict policies of traffic filtering.
  3. Strict rules of traffic filtering are also defined for all hosts in the protected network.
  4. Access to the Internet is allowed only from the DMZ hosts.

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service. An example of an insecure service, protocol, or port is FTP, which passes user credentials in clear-text.

The basic meaning of this requirement is to disable application protocols that transfer clear-text traffic (data and mandates), when possible. The following services may prevent you from fulfilling this requirement:

  1. telnet – however, it is no longer installed from the package for Linux;
  2. ftp – it is necessary to use sftp instead of it unless there is a serious reason to save FTP;
  3. «The big mail three» pop3/imap/smtp – in most cases, they are replaced with the ‘s’ analogs;
  4. Various web-based mechanisms of access (e.g. mail access) that do not encrypt traffic (e.g. SquirrelMail; its client traffic can be transferred through the port 443 if corresponding settings will be enabled);
  5. Services that are usually launched from xinetd (echo, discard, tftp etc.) – they are not necessary for 90% of systems.

At this stage, the settings of firewalls (Netfilter and tcp_wrappers in the standard package) are not considered; corresponding requirements will be given below.
Approximate analogs of this requirement in the CIS standard are the chapters “Minimize Boot Services” and “Minimize Xinetd Network Services” (items 3 and 4).

1.2.1.а Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented

Actually, this requirement refers to the settings of system and application firewalls. At that, it is not specified what network hosts should implement traffic filtering. Let us suppose that this requirement applies to routers/security gateways, servers, workstations, and portable computers of users who can access the network of payment data processing.
To fulfill this requirement, it is necessary to create clear ACCEPT rules in iptables; the best choice is to follow the principle “one service – one rule” (in fact, there will be created two rules for every service because of Netfilter features – one rule in each of the INPUT and OUTPUT chains or two rules in the FORWARD chain if the target host serves as a router). Supplement these rules with settings of tcp_wrappers in /etc/hosts.allow if necessary.

It is obvious that a firewall must be operating at the system start. This problem is commonly solved by enabling the iptables service at the system start:
chkconfig iptables on

However, a system administrator may decide to include the list of filtering rules into a script that is executed at the system start. This script can be called, for example, from /etc/rc.d/rc.local. This approach is useful, because the script is always available and it is possible to change and apply new rules quickly when necessary. A disadvantage of this method is described in the requirement 1.2.2.

An indirect consequence of this requirement is disabling the IPv6 protocol in case if it is not used to transfer data. In the RHEL-based systems, it is necessary to deny loading of the ipv6.ko module by adding the following entry to the file in the /etc/modprobe.d directory (e.g. /etc/modprobe.d/blacklist.conf):
install ipv6 /bin/true

As a result, the module of IPv6 support will not be loaded even if some application or OS part (e.g. ip6tables) requires it. The command
modprobe ipv6
will also reject loading the module; the only way to load it will be applying insmod.
You can perform similar actions for other network protocols that are not used in the system (SCTP etc.).

1.2.1.b Verify that all other inbound and outbound traffic is specifically denied

This requirement can be fulfilled by installing standard firewall via iptables in DROP:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

or by denying all traffic in tcp_wrappers by adding the following entry to /etc/hosts.deny:

1.2.2 Verify that router configuration files are synchronized – for example, running configuration files and start-up configuration files (used when machines are re-booted) have the same secure configurations

The statement of this requirement is quite clear. However, it should be mentioned that this rule is also applicable to Netfilter settings on servers and workstations.

You can verify whether the output of the iptables-save command coincides with the contents of the rules file /etc/sysconfig/iptables. This procedure can be easily optimized using text filters and md5sum.

It is necessary to remember that if the rules of traffic filtering are not described in the standard script launched at the system start (see 1.2.1.a), then it will be much more difficult to automate this procedure.
For tcp_wrappers, it isn’t necessary to verify that the settings are synchronized.

1.3.2 Verify that inbound Internet traffic is limited to IP addresses within the DMZ

It is necessary to configure servers (see 1.2.1.а) and routers/security gateways located between the data processing network and the DMZ. Thus, the traffic will be filtered by the gateway and the hosts in the data processing network.

This requirement has a non-obvious consequence: if the corresponding settings will be applied to the boundary network devices (routers/security gateways), then they will allow DNAT transfer of traffic from DMZ hosts to the data processing network, which should have no real IP addressing as will be shown below.

1.3.3 Verify there is no direct route inbound or outbound for traffic between the Internet and the cardholder data environment.

Formally, this requirement is a part of the item 1.2.1.а, but it has wider consequences.

From this, it follows that:

  1. It is necessary to configure DMZ update servers for all software of the data processing network: on one hand, the hosts should be regularly updated and on the other hand, it is not advisable to load updates directly from the Internet.
  2. Such network should have no real IP addressing (because it isn’t necessary); moreover, the real addressing is directly prohibited in the item 1.3.8.

It is not clear from the requirement statement whether it is allowed to use proxy servers for the hosts in the protected network to access the Internet. If it is a business necessity, then there is no direct prohibition to use it.

1.3.5 Verify that outbound traffic from the cardholder data environment can only access IP addresses within the DMZ
Formally, this requirement is a part of the items 1.2.1.а and 1.3.3; however, it doesn’t explain how to regard VPN traffic between data processing networks that are located in different sites and connect to each other via a VPN tunnel through the Internet.

1.3.7 Verify that the database is on an internal network zone, segregated from the DMZ.

This setting is trivial, but if a DMZ is large, then it will be difficult to audit it.

As the first step, nmap can be launched from a DMZ host:
nmap -sS -sV -T5 dmz-net/dmz-mask
nmap -sU -sV -T5 dmz-net/dmz-mask

Furthermore, it is possible (and necessary!) to initiate scanning of DMZ hosts from outside (such scan will conform to the item 11.2 of PCI DSS, but it must be performed by an organization with the ASV status).

It may turn out that the DBMS is allowed to listen to the loopback interface or the UNIX socket only; additionally, access to the port may be denied by the firewall. In such case, it will be necessary to perform manual analysis or apply a special scanner (that can be authorized on the target hosts; for example, MaxPatrol by Positive Technologies) to detect the launched databases.
This item can be matched with the CIS requirement 4.18 (with certain improvements) for other databases (Oracle, IBM DB2, etc.).

1.3.8 For the sample of firewall and router components, verify that a mechanism of address translation is used to prevent disclosure of internal network addresses

From this requirement, it follows that the data processing network should have no real IP addresses, because NAT will be applied in any case.

1.4.а Verify that mobile and/or employee-owned computers with direct connectivity to the Internet that are used to access the organization’s network, have personal firewall software installed and active

Netfilter is supplied with the standard distribution kit; it is necessary only to verify the configured rules of traffic filtering as for the requirements stated in the item 1.2.1.а.

In this item and the nest one, we assume that RHEL/Fedora systems are installed on work laptops of users. If so, it will be useful to take organizational protective measures that will prevent  this devices and external information-carrying media from being taken out of the controlled perimeter; these measures are considered in the items 9.6—9.9 of the PCI DSS.

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by mobile computer users

Application of filtering rules is not a complicated task. On the contrary, definition of user privileges requires a considered, tailored approach; this problem is described in the chapter 7.
To fulfill the last two requirements (1.4.а and 1.4.b), it is also advisable to configure boundary firewalls so that the traffic from such hosts was confined severely regardless of resourcefulness of users (who always tend to get rid of any restrictions).


  1. Payment Card Industry (PCI) Data Security Standard. Requirements and Security Assessment Procedures (Version 1.2.1, July 2009).

8 thoughts on “Red Card: Specificity of PCI DSS in respect to Red Hat Enterprise Linux (Part 1)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.