Pages

Monday, July 19, 2010

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

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Summary

The requirements presented in this chapter are much more allied to the CIS than those from the previous chapter. The corresponding items of the CIS RHEL are the chapters 3 and 4, paragraphs 2.3, 8.2, 9.4, 11.2, and SN.8. However, it will be necessary to apply external tools, such as port scanners and password crackers, in addition to OS settings.

2.1 Always change vendor-supplied defaults before installing a system on the network

The question is about passwords of network devices and Wi-Fi points of presence, SNMP access strings, etc. The requirement implies manual check (which is absolutely necessary in most cases), but there is an opportunity to avoid the most part of routine works by applying a special network or offline password cracking tool.

XSpider, MaxPatrol and THC Hydra can be used as a network password cracking tool; you can supplement their dictionaries if necessary. A disadvantage of Hydra is that addresses and ports are specified manually; this tool can be tied to Nmap, which identifies services running on scanned hosts, via special scripts.


Furthermore, there are offline password-cracking tools, which have higher performance than the network ones. For Linux, such tool will need to load the local hash base (/etc/shadow), determine the used algorithm (authconfig --list, usually it is md5 or sha512) and attack the hashes on the local host the scanner is running on. For example, this functionality is implemented in the MaxPatrol scanner (by Positive Technologies). The most popular free password cracking tool is John the Ripper; recently, RainbowCrack, which can use GPU for search, became rather popular, too.


Obviously, it is necessary to exclude empty passwords; for this purpose, verify that there are no such passwords in /etc/shadow and deny authorization with empty passwords in ssh by adding the following string to /etc/ssh/sshd_config:


PermitEmptyPasswords no

This parameter is set into “no” by default; therefore, it is enough to verify that this value is not “yes” in the settings file.

Empty passwords are denied in item 9.2 of the CIS standard. Moreover, the item 11.4 implies that pam_cracklib is enabled to analyze passwords when they are created or changed.

IT IS IMPORTANT. It is necessary to mention that the PCI ASV scanning procedures deny intensive password search (so that there were no excessive traffic and the users were not blocked). It concerns only verifying the default settings. In RHEL systems, there are no accounts with preset logins and passwords (except the anonymous FTP in cases, when such access should be denied); therefore, there is no formal need in application of password cracking tools. Nevertheless, if it is possible to crack passwords safely using search methods, one should do it.

2.2.а Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards (SANS, NIST, CIS)

It is necessary to configure target hosts in compliance with the requirements of industry-accepted standards (e.g. the CIS) and enterprise standards (which are usually based on industry-accepted ones). To estimate compliance of the target host settings with the specified requirements, you can apply a wide variety of commercial scanners (MaxPatrol, Symantec SCCS, Nessus, Acunetix, etc.), which can considerably simplify the check routine.

However, you should not pin your faith upon standards and automated tools. Errors are always possible and manual analysis should not be neglected.

For example, the item SN.8 of the CIS RHEL v.1.1.2 implies that users should be locked after a number of consecutive unsuccessful logon attempts. The recommended settings are valid only for RHEL4 with the pam_tally module; for version 5, these settings are pointless, because in spite of the same module name, it has other parameters. Additionally, the new module version, pam_tally2, is available along with the legacy one. At that, the standard officially supports version 5. In new systems (particularly, Fedora 12), the settings are different even from RHEL 5 (the pam_tally2 configuration is the same, but FC12 cannot use pam_tally).




MaxPatrol correctly supports all RHEL systems.

2.2.1 For a sample of system components, verify that only one primary function is implemented per server. For example, web servers, database servers, and DNS should be implemented on separate servers

To fulfill this requirement, you can apply any existing virtualization technique. For RHEL 5, Xen is officially supported, but it was replaced with KVM for RHEL 6. The both solutions offer similar functionality and differ in implementation only. Among the reasons to reject Xen in new distribution versions, they named the complexity of its implementation in the OS kernel and vague prospects of inclusion of the Xen source code into the official version of Linux kernel.

It also should be mentioned that Xen doesn’t support the “overload” mode, when the number of processor cores granted to virtual machines exceeds their physical amount on the virtualization server. This mode is often applied for the purposes of testing, development, and hosting, when there is a low load of virtual servers. In this case, KVM should be used instead of Xen.

Besides Xen and KVM, we’d like to mention the OpenVZ project, which is not included into the Linux distribution kits, but is widely used for VPS hosting and serves as the base for the Virtuozzo commercial product. OpenVZ allows for more fine-grained granting of resources to virtual machines. Among disadvantages, we can mention the number of supported guest OSs: currently, it is only Linux.

There is a wide variety of commercial (closed) virtualization tools, e.g. VMWare ESX, Virtuozzo, and Microsoft Hyper-V.


2.2.2 For a sample of system components, inspect enabled system services, daemons, and protocols. Verify that unnecessary or insecure services or protocols are not enabled, or are justified and documented as to appropriate use of the service

These requirements are absolutely clear; moreover, they are fulfilled if all CIS requirements that concern daemon launching on target hosts (chapters 3 and 4) are fulfilled. Most of these requirements imply that the following command should be executed:


chkconfig daemon_name on|off


For every chosen service, this command enables or disables its loading at the OS start for the predefined launch levels (for independent services and components, the syntax is the same).

When considering the items 2.2.2 and 2.2.4, you can additionally disable unnecessary kernel modules, e.g. support for uncommon network protocols such as SCTP (by analogy with the 1.2.1.a example), as well as the modules corresponding to devices that are not used on the given server / workstation / laptop.

2.2.3 Configure system security parameters to prevent misuse

The requirement statement is not correct enough, but we can conjecture that is implies configuration of kernel protective mechanisms. Moreover, setting of secure kernel parameters is important for protection of the entire system, but it is the only item where this mechanism can be applied.

The first kernel protecting mechanism is prevention of buffer overflows, which is mostly implemented using random addresses of application stacks and random addresses of library and application loading (the generally accepted term is Address Space Layout Randomization, ASLR [1]). These mechanisms were first included into the official Linux kernel version 2.6.12; the functionality was completely implemented in the version 2.6.25 [2].

However, before the described kernel versions were released, the RHEL and Fedora Core had already had a built-in mechanism ExecShield ([3], [4]), which implemented similar functions. You can verify whether it is available using the following command:


[root@support ~]# sysctl -a | grep -E 'randomize|shield'
kernel.randomize_va_space = 1
kernel.exec-shield = 1

The specified kernel variables must be assigned with non-zero values. You can disable this function only in special cases, for example, for the purposes of software testing or security features development. In these situations, it is necessary to add the following strings to the file /etc/sysctl.conf:
kernel.randomize_va_space = 0
kernel.exec-shield = 0

After that, either reboot the OS or apply the modifications without rebooting:


sysctl -p

An additional measure to prevent buffer overflows is to prohibit execution of code in stack at the level of library or application body. In Linux, these functions are implemented by the execstack utility, which can allow or deny code execution in stack for separate programs and libraries, as well as request confirmation of necessity to execute code in stack from applications and libraries [5].

Applications and libraries containing potentially executable stack can be identified as described below:


[root@support ~]# echo BINARIES:; for dir in /usr/libexec `echo $PATH | sed -e 's/:/ /g'`; do execstack -q ${dir}/* 2>/dev/null; done | grep -Ev ^\\-; echo LIBS:; find /lib /usr/lib -type f -name '*.so' -exec execstack -q {} \; 2>/dev/null | grep -v ^\\-
BINARIES:
? /sbin/mount.vmhgfs
? /usr/sbin/vmware-checkvm
? /usr/sbin/vmware-guestd
? /usr/sbin/vmware-tools-upgrader
? /usr/sbin/vmware-vmdesched
? /usr/bin/vmware-hgfsclient? /usr/bin/vmware-xferlogs
LIBS:
X /usr/lib/vmware-tools/lib32/libvmGuestLibJava.so
X /usr/lib/vmware-tools/lib32/libvmGuestLib.so



Furthermore, it is necessary to set network kernel parameters described in the CIS (items 5.1, 5.2, and SN.3 in version 1.1.2) and related to routing, ICMP and protection against DoS attacks. In the named standard, detailed kernel settings are given; there is no need to repeat them in this article.

It is possible that this requirement item also implies using SELinux; detailed consideration of this system is beyond the scope of this work. Features of this system’s settings are described in [6] and [7].

2.2.4 For a sample of system components, verify that all unnecessary functionality is removed. Verify enabled functions are documented and support secure configuration

Configuring the system in compliance with this requirement is much analogous to the item 2.2.2, but it can be supplemented with disabling support for external user devices (USB drives and Fireware devices). For this purpose, it is necessary to create and fill in the following files:
/etc/modprobe.d/disable-usb:


install usb-storage /bin/true


/etc/modprobe.d/disable-fireware:


install fireware_ohci /bin/true

If you will need to use an external USB or Fireware device for backup later, then the administrator will be able to load the corresponding kernel module using the insmod command, which is unavailable for non-privileged users.
Furthermore, if the protected host supports WiFi and/or WiMAX, but they are not necessary to carry out work tasks in the organization, then one can disable them in BIOS and delete the corresponding kernel modules:


rm -f /lib/modules/`uname -r`/kernel/drivers/net/wi{max,reless}/*


Note. The kernel modules should be deleted after every kernel update [8].

2.3 For a sample of system components, verify that nonconsole administrative access is encrypted

To fulfill this requirement, it is necessary to perform the following actions:

1. Disable launching of the telnet daemon (which is disabled by default) and support for “r” commands and daemons (rlogin, rsh, rcp), which are not included into the modern distribution kits;

2. Disable unsafe SSHD options by setting the parameters in the file
/etc/ssh/sshd_config as described below:


Protocol 2
RhostsRSAAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no

However, all these options (may be, except the first one) are already disabled by default; therefore in most cases, it will be necessary not to change the parameters, but to verify that they are not set into other (unsafe) values.

3. If LDAP authentication is used, then it is necessary to protect traffic between server and client from interception. If the communication session is not encrypted, then an attacker will be able to intercept password hashes or even plain-text passwords that are transferred from the server to a client; furthermore, when a password is changed, the new user password is sent to the LDAP server as a plain text. To avoid these situations and fulfill the standard requirements, one can perform the actions described in [9] (as an example, a CentOS5 client and a FC12 server were considered) with the following changes:
3.1 The server encryption mode is specified with the following string in /etc/openldap/slapd.conf:
TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3
3.2 When a key pair for the LDAP server is generated, one should not specify the password phrase (challenge). This requirement is given in the official documentation (man slapd.conf).
3.3 On the client side, one can specify the direct path to the certificate file instead of the directory (in the configuration file of LDAP authentication /etc/ldap.conf):
TLS_CACERT /etc/openldap/cacerts/rf12.crt
3.4 Furthermore, you can set lower connection timeouts or another connection type for the client (bind_policy in /etc/ldap.conf):


timelimit 10
bind_timelimit 4
bind_policy soft

4. If there are FTP daemons, verify that the root cannot login using FTP.
vsftpd, which is installed by default, has two files in the directory /etc/vsftpd/ that define users who are not allowed to gain such access — ftpusers and user_list. It is necessary to add an entry “root” into ftpusers and then check the value of the parameter userlist_deny in the directory /etc/vsftpd/vsftpd.conf. If this parameter is set into YES (by default), then the file user_list should contain an entry “root”; if it is set into NO, then the file should contain no such entries.

5. Consider and prevent other (usually uncommon) situations, for example, checking the root’s mailbox via SquirrelMail without using HTTPS.

References:


No comments:

Post a Comment