Following on from more work with OpenVAS and after resolving issues around PHP/MySQL the next largest priority was flagged as issues with the Remote Desktop Server (this applies if the server is being used as a Session Host or is just running Windows Server/Client). Here are two pointers in the right direction to get these port 3389 issues resolved!
SSL/TLS: Report Weak Cipher Suites and SSL/TLS: Diffie-Hellman Key Exchange Insufficient DH Group Strength Vulnerability
To resolve this issue I would suggest you look at the free IISCrypto tool (https://www.nartac.com/Products/IISCrypto) which (after a reboot) disables weak cipher suites and ensures that the correct key exchange mechanisms are used on your servers and clients. Note this software doesn’t just apply to IIS (Internet Information Services) but also Remote Desktop and any other Microsoft technology that makes use of schannel.
Although it takes a little while longer you can also examine the registry (see https://www.nartac.com/Support/IISCrypto/FAQ) and deploy a Group Policy to apply the same settings to your machines.
If you can I would suggest you opt for the PCI 3.1 template (which also culls TLS1.0 support) however as I found out you may have to resort to the ‘Best Practices’ which keeps TLS1.0 enabled and in turn allows things like 802.1x EAPOL and older versions of Microsoft SQL Server to work. Really is worth doing extensive testing with all of your applications (network services included!) before you go and roll this tool out to your full environment!
SSL/TLS: Certificate Signed Using A Weak Signature Algorithm
In this case we are looking at the self signed Remote Desktop Protocol certificate which just so happens to be SHA1. To resolve this issue have a look at this blog post – https://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo which covers in great detail how to use an Active Directory Certificate Services Server to issue SHA256 certificates to your machines to use with Remote Desktop.
A interesting quirk of an issue with this one; when generating a CSR to secure the iDRAC (version 8) interface on a Dell T430 server it appears that you can’t use an apostrophe in any of the fields else you are presented with a empty/blank csr.txt file (see right).
The work around is simple if a little annoying (especially when CSRs generated with other tools allow apostrophes) in that you remove the apostrophe from all of fields in the request. I’d imagine this is the same for other special characters as well.