TLS
Today we have the answer to the question – Without SSL decryption how many threats/attempted vulnerability exploits/other bad stuff will I miss that are coming from the internet at my internally hosted (externally published) web sites and services?
To run some simple tests (which will be detected as malicious attacks) I’m going to be running the Nessus scanner against a website behind a Palo Alto Networks Next Generation Firewall, while we won’t get the same results that might be seen from a ‘determined attacker’ we will get an idea of how things look from the standpoint of a ‘casual attacker’.
In short the answer is you’ll miss a lot – without decryption of traffic coming at your own web servers it’s pretty much impossible to detect attacks (with some minor exceptions) that are hiding inside HTTPS, either way let’s see how it’s done…
Kit list for this testing:
- An ‘internal’ web service, in this case the web console for PRTG Network Monitor (running on Windows Server)
- A Palo Alto Networks Next Generation Firewall – a PA-850 running PAN-OS 8.1 with a full suite of licences
- The Nessus vulnerability scanner
Both the firewall and the web service have been configured to run TLS1.2 with the private key for the certificate on both (which allows the firewall to decrypt the traffic without breaking connections) and the latest firmware/security updates have been applied across the board. Continue reading
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.
Has this page helped you? Was it worth the cost of a Coffee? If so click here to donate £4.00 to the myworldofit.net coffee fund via PayPal.