The purpose of this post is to detail what type reviews will be performed on a linux computer to determine if it meets the security requirements of the PCI DSS standard. To do this, whenever possible, I will detail the commands to use in each case.
However, although the main purpose is to audit compliance with PCI DSS, the proposed revisions can be used as a starting point for any security audit of a linux computer you want to perform.
All the commands in this post have been tested on Ubuntu 12.04 computer, so it is possible that some of them need to be modified to work properly on other Linux distributions. We can use the lsb_release-a command for the exact version of the system we are reviewing, or obtain it from the /etc/os-release.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
The command
iptables -L -v
will show the firewall rules used in the system. In case of a laptop, you should review compliance with PCI DSS 1.4 that required to install and maintain a personal firewall. In any case, you should review the rules defined in the fw because in certain circumstances can serve as a compensating control in the absence of compliance with other requirements of the standard.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
To verify some aspects of compliance with this requirement, we can use the following commands:
dpkg -l
This command allows us to list all installed packages in order to detect unnecessary packets that should have been uninstalled.
route -n
This command allows us to list all the routes defined in the system.
Additionally, analyzing the following files we could determine if it has changed the name resolution of the system:
/etc/resolv.conf
/etc/hosts
/etc/nsswitch.conf
Also, you must check the next file to detect if exist unnecessary or predefined user accounts that should have been deleted or disabled:
/etc/passwd
Likewise, you should check out the company’s hardening guide and identify any additional evidence that should be acquired to ensure it is being properly applied.
It is also important to identify which is the primary function of this server, and use the review to identify any package or service that does not make sense for that primary function. For example, if the primary server role is to act as a web server, it makes sense that we locate apache packages installed, but would not have it we found packages of Oracle or Nessus. The existence of these packages could make us suspect that the server is being used for more than one primary function and therefore the requirement 2.2.1 is not in place.
We can use the following command to list all running processes and services listening on the UDP and TCP ports to verify that there are no processes or unnecessary services running and all that are running are adequately documented and justified:
ps -edf
lsof -i UDP -n -P
lsof -i TCP -n -P
We should aldo review this folder to detect scheduled tasks:
/var/spool/cron/crontabs
Additionally, we review this list of processes and services to identify insecure protocols (such FTP, Telnet, etc.) and check that they have been documented and implemented additional security measures for these protocols.
Finally, to complete the review of this requirement, we will review the following file to check the existing SSH configuration on the server:
cat /etc/ssh/sshd_config
In this file we can verify which port SSH is running, what versions are allowed (should only be permitted v2 because v1 is vulnerable) and what encryption protocol is being used to ensure that is a sufficiently robust protocol. Additionally, you should check that the value of AllowTcpForwarding is “no”, unless is justify the need to use this server as jumping server to manage other systems.
Requirement 6: Develop and maintain secure systems and applications
To check this requirement, we have to validate that there are no unsafe versions of software on the system. With this purpose in mind, we can use the following commands:
uname -a
This command allows us to know which kernel version is used and verify that there are not know vulnerabilities for that version, or in other words, that the kernel is correctly patched.
In the other hand, with the next command we can list all the packages installed in the system and their versions, so we can also check if there are any package vulnerable in the system. Remember that to meet this requirement you must to install security patches for all the software included in the PCI DSS scope:
dpkg -l
Last, but not least, we should review the next file to verify that there are not developers or testing user accounts. This kind of accounts must be deleted before the system or the apps are deployed in production environment:
/etc/passwd
Requirement 7: Restrict access to cardholder data by business need to know
In order to verify compliance with the PCI DSS requirement 7, you can perform the following checks:
/etc/sudoers
/etc/pam.d/sudo
/etc/pam.d/su
In these files we can check which users have permission to increase their privileges to root and under what conditions they can. All cases should be properly documented and justified.
We should also review the perms of the next file and any backup that it could have to be sure it can not be open or edited for any user:
/etc/shadow
On the other side, we should check that the setuide files can not be edited by don’t authorized users to increase their system privileges. We could use next command for this purpose:
find / -perm -4000 -ls 2> /dev/null
Next commands allow us to list all files that can be open or edited by any user and are not located on /proc folder:
find / -type f -perm -006 2>/dev/null | grep -v /proc
find / -type f -perm -002 2>/dev/null | grep -v /proc
We should analyze these files to check if exists a justification for the privileges that are defined in each case.
In addition, we should review the next file to verify what shell have assigned each account:
/etc/passwd
Also, we should review next file to check if are defined any restriction to the users login:
/etc/security/access.conf
This file allows to limit the kind of access that some accounts can have. In example, you can configure it to prohibit the remote access to the root account or the console access to some user or app accounts.
Finally, you should review the next file to verify that the line “none *” exists and is not commented, as well as there are no users with extra capabilities without a justified reason for it:
/etc/security/capability.conf
Requirement 8: Identify and authenticate access to system components
To check the major part of PCI DSS requirement 8 we should review the next file:
/etc/pam.d/common-password
In this file we can find what algorithm is used to hash the passwords stored in /etc/shadow and verify if it is used pam_cracklib.so to configure a password policy that meets requirement 8.2.1 of PCI DSS.
Requirement 10: Track and monitor all access to network resources and cardholder data
To analyze compliance with this requirement of PCI DSS must be reviewed two aspects; time configuration and syslog settings.
Reviewing next file we know the UTC time zone being used by the system:
/etc/timezone
This other command allows us to verify the NTP Servers configuration for the time synchronization of the system:
ntpdate
On the other side, next command allows us to know if syslog process is running:
ps -edf | grep syslog
Reviewing the next file we can know if syslog is configured to receive events from other systems or devices and what permits will have the generated log files:
/etc/rsyslog.conf
Finally, reviewing this file (or its equivalent defined in first lines of the file /etc/rsyslog.conf) we can know what events are generated and where they are saved or sent. On this way, we can verify if all the security events included on the PCI DSS scope are stored centralized as the standard requires:
/etc/rsyslog.d/50-default.conf
Requirement 11: Regularly test security systems and processes
Check what type of file integrity monitoring solution is installed. Depending on the type of solution being used, we must do appropriate revisions to ensure that the requirement 11.5 of PCI DSS. ie, at least weekly, the solution should check the changes made to files considered critical as system executables, application executables, parameter files, etc.
I hope you enjoy and find useful this post. If you have found any error or you wish propose any improvement, please, don’t hesitate to propose it in a comment.
Kudelski Security Research 