Approved Scanning Vendors are companies that make software that performs vulnerability scans and helps organizations validate adherence to PCI DSS. For a list of all companies and scanning software approved by PCI DSS, see https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors.
In our example, we used Rapid7 to test SL1 for compliance with PCI DSS before we performed the configuration steps in this document. If you use a scanning tool before performing the steps in this document, you might see some vulnerabilities like the following:
|
Vulnerability ID |
Vulnerability Description |
Vulnerability Solution |
|---|---|---|
| ssh-openssh-x11-forwarding-info-disclosure | OpenSSH 4.3p2, and probably other versions, allows local users to hijack forwarded X connections by causing ssh to set DISPLAY to :10, even when another process is listening on the associated port, as demonstrated by opening TCP port 6010 (IPv4) and sniffing a cookie sent by Emacs. | False positive. SL1 does not use X or OpenBSD. |
| ssh-openssh-cbc-mode-info-disclosure | Error handling in the SSH protocol in (1) SSH Tectia Client and Server and Connector 4.0 through 4.4.11, 5.0 through 5.2.4, and 5.3 through 5.3.8; Client and Server and ConnectSecure 6.0 through 6.0.4; Server for Linux on IBM System z 6.0.4; Server for IBM z/OS 5.5.1 and earlier, 6.0.0, and 6.0.1; and Client 4.0-J through 4.3.3-J and 4.0-K through 4.3.10-K; and (2) OpenSSH 4.7p1 and possibly other versions, when using a block cipher algorithm in Cipher Block Chaining (CBC) mode, makes it easier for remote attackers to recover certain plaintext data from an arbitrary block of ciphertext in an SSH session via unknown vectors. | False positive. SL1 does not use X or OpenBSD. |
| openssh-x11-cookie-auth-bypass | ssh in OpenSSH before 4.7 does not properly handle when an untrusted cookie cannot be created and uses a trusted X11 cookie instead, which allows attackers to violate intended policy and gain privileges by causing an X client to be treated as trusted. | False positive. SL1 does not use X or OpenBSD. |
| http-generic-sensitive-form-data-unencrypted | A web form contains fields with data that is probably sensitive in nature. This form data is submitted over an unencrypted connection, which could allow hackers to sniff the network and view the data in plaintext. | Fixed by forcing HTTPS. |
| http-cookie-secure-flag | The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text. | Fixed by forcing HTTPS. |
| http-generic-webdav-enabled | WebDAV is a set of extensions to the HTTP protocol that allows users to collaboratively edit and manage files on remote web servers. Many web servers enable WebDAV extensions by default, even when they are not needed. Because of its added complexity, it is considered good practice to disable WebDAV if it is not currently in use. | False positive. SL1 does not enable webdav. |
| http-basic-auth-cleartext | The HTTP Basic Authentication scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as TLS/SSL), as the username and password are passed over the network as cleartext. | Fixed by forcing HTTPS. |
| http-cookie-http-only-flag | HttpOnly is an additional flag included in a Set-Cookie HTTP response header. If supported by the browser, using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website. | Fixed by forcing HTTPS. |
| ssl-self-signed-certificate | The server's TLS/SSL certificate is self-signed. Self-signed certificates cannot be trusted by default, especially because TLS/SSL man-in-the-middle attacks typically use self-signed certificates to eavesdrop on TLS/SSL connections. | Fixed by installing a commercial SSL certificate. |