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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS 7.5.6 SSL/TLS Implementations Although some Web servers come packaged with SSL capabilities already integrated, many do not. This section discusses various commercial and open-source SSL/TLS implementations. Some of these packages contain the functionality to generate SSL certificates without the need of a CA. The following list includes some of the SSL toolkits available: OpenSSL is an open-source implementation of SSL/TLS for Unix and Linux platforms (http://www.openssl.org/). Network Security Services (NSS) is an open-source implementation of SSL/TLS developed by the Mozilla foundation. 61 NSS is derived from the original Netscape SSL implementation. GnuTLS is an open-source implementation of SSL/TLS developed by the Free Software Foundation. 62 Java Secure Socket Extension (JSSE) is an implementation of SSL/TLS developed by Sun for distribution as part of the Java Runtime Environment (JRE). 63 Security Support Provider Interface (SSPI) is an implementation of SSL/TLS available on Microsoft Windows Server 2003. IBM Java Secure Sockets Extension (IBMJSSE) is an implementation of SSL/TLS for the WebSphere Application Server. Federal government organizations are required to use Federal Information Processing Standards (FIPS)- validated SSL/TLS implementations when protecting data using SSL/TLS. The Cryptographic Module Validation Program (CMVP) performs validation testing of cryptographic modules, including SSL/TLS implementations. 64 <strong>NIST</strong> provides a list of FIPS 140-2 65 -compliant vendors and implementations. 66 Regardless of what SSL/TLS implementation is used, it is important to ensure that security patches are regularly applied. Security flaws in SSL/TLS implementations can potentially allow attackers to spoof PKI certificates, forge digital signatures, perform DoS attacks, or execute arbitrary code in the Web server. 7.6 Brute Force Attacks Many Web sites authenticate users via username and password combinations—whether through HTTP Basic, HTTP Digest, or a Web form over SSL. Regardless of implementation, username and password combinations are susceptible to brute force attacks. Brute force attacks can occur in multiple forms: Username Harvesting—Applications that differentiate between an invalid password and an invalid username can allow attackers to construct a list of valid user accounts. 61 62 63 64 65 66 http://www.mozilla.org/projects/security/pki/nss/ http://www.gnu.org/software/gnutls/ http://java.sun.com/products/jsse/index.jsp http://csrc.nist.gov/cryptval/ http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf http://csrc.nist.gov/cryptval/140-1/1401vend.htm 7-12
GUIDELINES ON SECURING PUBLIC WEB SERVERS Dictionary Attacks—Attackers use common dictionary words and their variants to attempt to gain access to a user’s account. Brute Force Attacks—Attackers try every possible password to attempt to gain access to a user’s account. There are a number of methods for reducing a Web server’s vulnerability to brute force attack: Use Strong Authentication—Strong authentication techniques, such as hardware tokens, one-time passwords, biometric authentication, and SSL/TLS client certificates, are much more resistant to brute force attacks than passwords. Stronger authentication can be achieved by combining multiple authentication mechanisms to form a multi-factor authentication scheme. However, strong authentication may be prohibitively expensive or difficult to incorporate into a system. Use Timeouts—Incurring a delay of several seconds after a failed login attempt can slow an attacker down. However, attackers can attempt multiple logins at the same time from different clients. Use Lockouts—Locking out a user account after a number of failed login attempts prevents the attacker from successfully logging into an account. The primary disadvantage of this technique is that it can leave the system open to a DoS attack. Also, an attacker may try several common passwords against random usernames, which may grant the attacker access to the system while bypassing the lockout [Whit06]. Enforce a Password Policy—By requiring passwords to be of a certain length and to contain lowercase letters, uppercase letters, numerals, and/or symbols, a simple dictionary attack will not work on the system. Enforce a Password Change Policy—By requiring passwords to be changed on a regular basis, an attacker might not have enough time to brute-force a potential password. However, strict password change policies can frustrate users and weaken passwords by causing users to follow patterns, such as using password1, password2, etc. [Bell06] Use Blacklists—Blocking IP addresses or domains known to attempt brute force attacks from accessing the system may stop some attackers, but it is possible that some attacks may come from compromised systems that would otherwise be considered legitimate. Use Log Monitoring Software—Vigilantly monitoring logs of invalid password attempts may help an organization detect brute force attacks, potentially giving the organization time to respond before the attack has been successful. Aside from strong authentication, none of these mechanisms completely prevent brute force attacks; however, using one or more of these techniques makes it more difficult for an attacker to gain access to the system. Nevertheless, when considering which technologies to adopt, it is important to consider passwords as part of the system as a whole. For example, a Web site that uses usernames and passwords to retrieve user customizations may not need to concern itself with preventing brute force attacks [Bell06]. In systems where sensitive information is being protected, some of these techniques may be necessary. Regardless, an organization may already have policies regarding brute force attacks. If so, those policies should be followed and enhanced if necessary. 7-13
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:
Page 33 and 34: GUIDELINES ON SECURING PUBLIC WEB S
Page 83: GUIDELINES ON SECURING PUBLIC WEB S
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?