Encryption offers data confidentiality but it doesn’t mean the encrypted data is harmless. It also means that it bypasses IPS/IDS systems due to the inability to inspect the data. To migate this we can grant the firewall the ability to decrypt traffic for deeper packet inspection – SSL Forward Proxy & SSL Inbound Decryption are excellent methods.
In a previous post we’ve configured SSL Inbound Inspection to protect an endpoint like a webserver from being infected external sources. That doesn’t prevent end-users from infecting their own devices with malicious software. Implementing SSL Forward Proxy (Outbound traffic only) on the firewall with MITM (man in the middle) behavior can prevent users from harming their device or even other devices within the network.
Under normal circumstances whenever the client browses to a website, then the client will use the certificate of that particular website. To be more specific, the server sends out her public key destined to the client who’s the only one able to decrypt the traffic and thus only the client can decrypt it because she’s the owner of the private key. The firewall can’t intercept this and decrypt it because it lacks the private key of the client.
SSL Forward Proxy works by replacing the public key of that server (eg google.com) with its own certificate and signs it with its own public key. Then the firewall will initiate a new SSL session by generating a new certificate before handing it over the client. As a result the traffic was inspected & decrypted by the firewall for any potential malware before it could harm any endpoint. It has to be a self-signed certificate generated on the firewall or a subordinate CA issued by the Active Directory PKI. These can’t be publicly trusted, but they should within the enterprise.
Generating trust certificate
Self-signed CA for Trust Forwarding
Device > Certificates
If Active Directory Domain Certificates isn’t an option, opt for a self-signed certificate instead. I’ve named the Certificate & Common Name the same for simplicity. Make sure to check the box “Certificate Authority”.
After the CA certificate has been generated, make sure to check the following boxes:
Optional: Active Directory CA (best-practice)
It totally makes sense to take advantage of this because every Active Directory Member already trusts the Domain’s Root CA . Manually installing the certificate or spreading it with a GPO is unnecessary. First off, install Active Directory Certificate Services. Server Manager > Manage > Add roles & Features > Active Directory Certificate Services > and make sure to select “Certificate Authority Web Enrollment” twice.
After the installation configure the Active Directory Certificate Services role. Select the highlighted down below. Leave everything else at default for the rest of the installation.
Device > Certificates
Request a CSR (certificate signing request).
Export the certificate, open the certificate in notepad and browse to http://<ip-address>/certsrv
Click on “Advanced Certificate Request”
Copypaste the CSR input in here and make sure to select “Subordinate Certification Authority” which simply just means Intermediate CA.
Click “Download Certificate” and rename the file to https-trust-inspection.cer
Next download the Root CA.
Select Base 64 and rename the file to root.crt
Import the root-ca.crt
Import HTTPS-Trust-Inspection.cer file
You’ll notice that the certificate is no longer highlighted in the color orange and that issued by the root CA of your Active Directory infrastructure.
Finally, open the https-trust-inspection and check “Forward Trust Certificate”
Self-signed CA for Untrusted Forwarding
This will be the certificate that the firewall will use for websites with expired or invalid certificates. Like when users receive the message: “Your connection is not private” when browsing to a website with an invalid/expired certificate. https://self-signed.badssl.com is a great way to test invalid or expired certificates.
It really does have to a certificate that isn’t trusted by any of your clients or servers because the “not secure” prompt has to occur. Do not use a certificate from the Active Directory Infrastructure because by default they’re trusted by any domain user.
Generate a self-signed CA.
And select Forward Untrust
Select the kind of content you want to decrypt. It’s best to NOT decrypt or use SSL Forward Proxy for financial services or anything that relies on it such as shopping or gambling because of legal requirements.
Attaching anti-virus profile to a security policy
Edit your security policy that allows your clients to reach out on the Internet.
Enabling OCSP/CRL for certificate validation
In order for the firewall to determine the validity of a certificate either the OCSP or CRL protocol is used with the former taking priority. This is an important step so that users get the error “not secure…” message when visiting a website with an expired certificate.
Under Device > Setup > Session > Certificate Revocation Checking
And enable OCSP. CRL can be enabled as well but OCSP takes priority unless the OCSP servers are down then CRL will be used.
To verify viruses are effectively being stopped by the firewall, wicar.org is a great method to test it. The viruses aren’t harmful because they’re made for testing purposes to validate whether the endpoint is protected or not.
With SSL Forward Proxy (Monitor > Threat):
Or Decryption (Monitor > Decryption)
1,103 total views