NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS -----BEGIN CERTIFICATE----- MIIDjjCCAvegAwIBAgIBAzANBgkqhkiG9w0BAQQFADCBzzELMAkGA1UEBhMCQ0ExED AOBgNVBAgTB09udGFyaW8xETAPBgNVBAcTCFdhdGVybG9vMR8wHQYDVQQKExZVb ml2ZXJzaXR5IG9mIFdhdGVybG9vMSswKQYDVQQLEyJJbmZvcm1hdGlvbiBTeXN0ZW1zI GFuZCBUZWNobm9sb2d5MSUwIwYDVQQDExxVVy9JU1QgQ2VydGlmaWNhdGUgQXV0a G9yaXR5MSYwJAYJKoZIhvcNAQkBFhdpc3QtY2FAaXN0LnV3YXRlcmxvby5jYTAeFw05O DA4MjcxNjE0NDZaFw05OTEwMjExNjE0NDZaMIHGMQswCQYDVQQGEwJDQTEQMA4G A1UECBMHT250YXJpbzERMA8GA1UEBxMIV2F0ZXJsb28xHzAdBgNVBAoTFlVuaXZlcn NpdHkgb2YgV2F0ZXJsb28xKzApBgNVBAsTIkluZm9ybWF0aW9uIFN5c3RlbXMgYW5kIFRl Y2hub2xvZ3kxGTAXBgNVBAMTEGlzdC51d2F0ZXJsb28uY2ExKTAnBgkqhkiG9w0BCQEW GndlYm1hc3RlckBpc3QudXdhdGVybG9vLmNhMIGfMA0GCSqGSIb3DQEBAQUAA4GNAD CBiQKBgQCw8Sc7X4EeAxBxTPgmTd4Utau0BIqYTdnIRXXg/ryAn2A7G5MtkMHj0triXoineu RxW9MQSQW8jMAv+xznMaL6OxnG+txyBjYx1zh02D+npBp4Fy81kgbypp5Usf18BonsqSe9Sl 2P0opCCyclGr+i4agSP5RM5KrycTSVoKHERQIDAQABo4GAMH4wOgYJYIZIAYb4QgEEB C0WK2h0dHA6Ly9pc3QudXdhdGVybG9vLmNhL3NlY3VyaXR5L2NhLWNybC5wZW0wLQ YJYIZIAYb4QgENBCAWHklzc3VpbmcgQ0EgYXNzdW1lcyBubyBsaWFibGl0eTARBglghkgB hvhCAQEEBAMCAEAwDQYJKoZIhvcNAQEEBQADgYEADZOtbpvbnBaWOPIMOSbqTQK 1LUjn4uHN3BLmqxznIzdiMu4RXyxne5Uq9EA7LbttutH7fIoOW+ID9Zrn1aH1FoU1dtEvovXm A6m5G+SN8A9tIAvRGjNmphB82xGkwEXuLN0afYz5XaFo3Z73INw6WxVoxDhPTgNIyYEii Sp6Qfc= -----END CERTIFICATE----- Figure 7-3. Sample Encoded SSL/TLS Certificate When a Web browser contacts a Web site that is using SSL/TLS, the browser examines the certificate and attempts to verify its validity. Each browser has a store of certificates, and these typically include root certificates for many third-party CAs. If the browser has a root certificate for the third-party CA that issued the Web server’s certificate, it can use the CA’s root certificate to validate the Web server’s certificate, which is based partially on that root certificate. If the browser does not have the needed root certificate, then it typically displays a warning to the user that says the Web server’s certificate could not be verified and asks the user how it should proceed. Some organizations decide to create and sign their own Web server certificates instead of having certificates issued by third-party CAs. The main advantage of self-signed certificates is that it avoids the cost of purchasing and renewing certificates; however, by default, Web browsers will not be able to validate self-signed certificates, so they provide no assurance of the legitimacy of the certificate or the Web server. Given the increasing use of phishing and other techniques to trick users into visiting rogue Web sites, failing to authenticate the server’s identity before using SSL/TLS with it is unacceptable. If a particular Web server is only going to be accessed from the organization’s own systems (e.g., telecommuters using laptops issued and managed by the organization), then those systems’ browsers could be provisioned with the root certificates needed to validate the Web server’s self-signed certificate and authenticate the server’s identity. Otherwise, the use of self-signed certificates for public Web servers is generally not recommended because of the logistics involved in securely distributing the root certificates to users’ Web browsers and having the certificates installed correctly by the users so that the browsers can authenticate the organization’s Web servers. For all SSL/TLS certificates for Web servers, regardless of issuer or format, administrators should take extreme caution in securing their certificate and encryption keys. The following are recommendations: Create and store a backup copy of the certificate on read-only media in case the original certificate is deleted accidentally. If the certificate is lost and cannot be recovered from backup media, a new certificate must be created. 7-10
GUIDELINES ON SECURING PUBLIC WEB SERVERS Create and store a backup copy of the encryption keys on read-only media in case the keys are deleted accidentally. If the keys are lost and cannot be recovered from backup media, a new key pair and certificate must be created. Note that the backup copy of the keys must be physically secured and should be encrypted as well. Store the original certificate in a folder or partition accessible by only Web or system administrators and secured by appropriate authentication mechanisms. Consider running a file integrity checker in the Web server (see Section 8.2.2) and ensure that it is monitoring for any changes to the certificate. Examine system logs regularly to validate and ensure prevention of unauthorized system access. If a malicious user gains unauthorized access to a Web server, the integrity of the entire server is lost immediately once the encryption key pair is modified. Once a key in an SSL/TLS certificate is compromised, it can remain compromised; for example, some CAs do not issue revocation information, and many client implementations do not obtain or process revocation information. Once a certificate is ready, it needs to be installed, and SSL needs to be enabled and configured. Some steps are common to all Web servers: Disable SSL 1.0 and SSL 2.0. Configure SSL/TLS to restrict cryptographic algorithms to the selected cipher suite(s) (see Section 7.5.4). Indicate the location of the SSL/TLS certificate and instruct the server to start using SSL/TLS. In certain cases, the Web server must be instructed to begin using SSL/TLS, and even given the location of the SSL/TLS certificate and private keys if they were stored as files on the hard drive. Instruct server to listen on TCP port <strong>44</strong>3. This is the default TCP port from which SSL/TLS resources are accessed by clients (other ports can be used). In most cases, if the server was not previously using SSL/TLS, this port would be disabled for security reasons. It will probably be necessary to configure the network infrastructure supporting the Web server to allow SSL/TLS traffic (see Section 8.2). All ports other than TCP <strong>44</strong>3 should be closed and the network infrastructure (e.g., firewalls) should be updated to block attempts to connect to all other ports. However, if the Web server is to host both HTTP and HTTPS content, TCP 80 should be open as well. Configure the server to protect the necessary resources (directories and/or files) using SSL/TLS. Configure the Web server application so that the appropriate resources are protected with SSL/TLS. These resources are then accessible only from a URL that starts with “https://”. Newer versions of the HTML standard have been amended to include a response to inform clients when a file they have requested is available only via SSL/TLS. The HTTP status code 403.4 indicates that a HTTP GET request must be prefixed with an https:// because the resource requested is protected with SSL/TLS. For more information, consult RFCs 2246, 2626, and 2817. 60 Most current Web browsers also provide users with some user-friendly visual indication of a server’s SSL/TLS certificate status, such as changing the color of a status bar. 60 http://www.ietf.org/rfc/rfc2246.txt, http://www.ietf.org/rfc/rfc2626.txt and http://www.ietf.org/rfc/rfc2817.txt 7-11
Page 1 and 2:
Special Publication 800</st
Page 3 and 4:
GUIDELINES ON SECURING PUBLIC WEB S
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32: GUIDELINES ON SECURING PUBLIC WEB S
Page 81: GUIDELINES ON SECURING PUBLIC WEB S
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
show all

NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?