However, the claim that using the “–top-ports” switch to scan only the top 3,674 TCP ports is 100% effective opens the door for yet another false sense of security. I wholeheartedly believe that it was NOT Fyodor’s intention for organizations to rely solely on port scans using this configuration to determine which ports are open. However, it does not require a leap of faith to believe that some less “offensive minded” security professionals will now use this configuration to get a “complete picture” of their networks.

Why is this a problem? If you are reading this blog, you probably already know where I am going with this. It doesn’t require another leap of faith to believe that an attacker or offensive minded individual would examine the “Top Ports” list and code their malware or configure their tools to operate on ports that are not included in the list. The result? Those who subscribe to this complete picture mentality will not discover the open ports.

So how do we effectively leverage the hard work of the Top Ports Project? I’m not entirely sure yet. Perhaps we use the “–top-ports” switch to perform differential scans and continue to use “-p-” to perform baseline scans? Or maybe we use the “–top-ports” switch to perform discovery scans and “-p-” to perform enumeration?

I do know that the information that has been provided as a result of the Top Ports Project is valuable. How do you think we can effectively use this information?

• SSLv2 Enabled
• Weak SSL Encryption Ciphers Enabled

With these vulnerabilities being so common amongst those bound to the PCI DSS, I would have hoped that better remediation information existed beyond Microsoft’s overcomplicated Knowledgebase Article,

• How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll

In response to this lack of quality remediation information, I created the following Windows Registry file that aims to simplify the remediation of both vulnerabilities. This file has been tested on IIS 6.0 (Windows 2003) and disables the following weak ciphers, hashing functions, and protocols associated with SSL:

• Weak Ciphers – DES 56, NULL, RC2 40/128, and RC4 40/56/128
• Weak Hash Functions – MD5
• Weak Protocols – PCT 1.0, and SSL 2.0

You can download the registry file from our website, here.

The standard “Backup your registry first” and “Test on non-production systems first” rules apply. Happy remediating! (and more importantly…SECURING!!!)