Quest has been named as an ASP "Ten Best Web Support Sites" award winner. Learn more.
A security vulnerability scan has detected concerns with Rapid Recovery and you want to know what can be done to resolve them. For example, after running a Nessus security scan, the following results are displayed:
Windows Registry Disclaimer:
Quest does not provide support for problems that arise from improper modification of the registry. The Windows registry contains information critical to your computer and applications. Make sure you back up the registry before modifying it. For more information on the Windows Registry Editor and how to back up and restore it, refer to Microsoft Article ID 256986 “Description of the Microsoft Windows registry” at Microsoft Support.
Medium Cipher Strength Cipher Suite Supported
SSL Version 3 Protocol Detection and Vulnerability of POODLE Attack.
There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol. However, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available.
The POODLE vulnerability is a weakness in version 3 of the SSL protocol that allows an attacker in a 'man in the middle' context to decipher the plain text content of an SSLv3 encrypted message. Servers and clients should take steps to disable SSL 3.0 support completely. Take care to evaluate your servers to protect any additional services that may rely on SSL/TCP encryption.
To manually edit the Windows registry to disable SSL 3.0, do the following:
Although the TLS protocols are enabled by default, they do not appear in the registry. After disabling SSL 2.0 and SSL 3.0, it is a good idea to ensure that at least one of the TLS protocols are enabled. To verify that the TLS protocol is enabled, do the following:
SSL RC4 Cipher Suites Supported
In light of recent research into practical attacks on biases in the RC4 stream cipher, Microsoft is recommending that customers enable TLS 1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS 1.2 with AESGCM as a more secure alternative which will provide similar performance. Microsoft recommends that customers upgrade to TLS 1.2 and utilize AESGCM. On modern hardware AESGCM has similar performance characteristics and is a much more secure alternative to RC4.
Clients and servers that do not want to use RC4 regardless of the other party’s supported ciphers can disable RC4 cipher suites completely by setting the following registry keys. In this manner, any server or client that is talking to a client or server that must use RC4 can prevent a connection from occurring. Clients that deploy this setting will be unable to connect to sites that require RC4, and servers that deploy this setting will be unable to service clients that must use RC4.
You can avoid the problem by running the following commands from an elevated command prompt:
Each command will add the "Enabled" dword registry value and set it to disabled (value data set to 1 is 'On'). If you currently do not have the registry keys for RC4 128, RC4, or RC4 56, the above commands will automatically add these registry keys and corresponding dwords automatically.
SSL/TLS DiffieHellman Modulus <= 1024 Bits (Logjam)
An information disclosure vulnerability exists in Secure Channel (Schannel) when it allows the use of a weak DiffieHellman ephemeral (DHE) key length <= 1024 Bits in an encrypted TLS session. Allowing <= 1024 Bits DHE keys makes DHE key exchanges weak and vulnerable to various attacks. You can avoid the problem by running: