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
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.
A bit of an interesting one today; while provisioning a pair of shiny new Dell T430s I had obtained and uploaded a valid 3rd party signed SSL certificate to the iDRAC interface with a view to ensuring that whenever an administrator accessed the interface they didn’t get a invalid certificate warning.
However after uploading the certificate and restarting iDRAC I was presented with an error message in Internet Explorer starting that ‘The security certificate provided by this website is not secure’. In researching this it appeared that the site was either running a very old version of SSL or that the certificate had become ‘mangled’ in the server somehow. Either way Internet Explorer, Google Chrome and Firefox did not allow me to bypass this error message.
On way to resolve this issue was by accessing the server via SSH and running some commands (see screen shot sequence below for the details)…
One such problem is how to deploy remotely accessible services (VPNs/Terminal Server/Citrix VDI/or the famous Home Access Plus+) in a secure but low cost manner. Obviously a key part of these services is security and for modern web security you need a SSL Security Certificate.
Most hosting companies will charge £40+ a year for even the most basic of SSL certificates (and personally I would put that into more RAM for a server!) but luckily JANET (the Joint Academic NETwork) offers any school, college or university completely free security certificates.
Schools have the extra hoop to jump through in the sense that they have to apply through their LEA/RBC; but, I know for one thing Oxfordshire County Council are doing well with this and we already have two certificates protecting both our web portal and VPN.
For more information visit the JANET Certificate Service web page.