To secure your webserver from any potential harms we can inspect/decrypt inbound traffic before being handed over to our webserver. It’s different than SSL Forward Proxy, which is mostly for outbound traffic e.g. a client visiting a website and NOT for inbound traffic destined for an endpoint like a webserver. Both methods require the firewall to be put inbetween both endpoints in order for the firewall to step in and play a fundamental role in stopping the attack.
- Active Threat Prevention license
- Updated Anti-Virus/threats contents
- Running Apache2/nginx webserver (Apache2 on Ubuntu 18.04 in my case)
- Valid domainname resolvable over the Internet
- Let’s Encrypt SSL Certificate
Enable firewall to forward decrypted SSL traffic to WildFire
Device > Setup > Content-ID > Content-ID Settings
In order for Palo Alto’s cloud-based WildFire engine to learn any new threats and to prevent them, it’s always a good idea to deliver them the necessary information.
Adding a passphrase to LE-SSL Private Key
Head over to /etc/letsencrypt/live/<domainname>. In my case “faatech.be”
- cert.pem = domain’s public key certificate
- privkey.pem = domain’s private key certificate
- chain.pem = Let’s Encrypt Intermediate CA Certificate
- fullchain.pem = cert.pem + chain.pem
You’ll need the following certificates “cert.pem” and “privkey.pem”. By default Let’s Encrypt doesn’t add any passphrases to the private key, so we have to add one. First we backup our current privkey.pem in case anything goes wrong;
$ cp privkey.pem privkey.pem.bak
$ openssl rsa -aes192 -in privkey.pem -out newprivkey.pem
It’ll prompt for a passphrase. And it should be secure, right? Next, replace the current privkey.pem with the newprivkey.pem.
$ rm privkey.pem
$ cp newprivkey.pem privkey.pem
$ rm newprivkey.pem
Download certificate and private key from the webserver
In order to upload those to the Palo Alto Firewall – I’ve copied the “cert.pem” and “privkey.pem” to a regular sudo user’s home directory. So I can get them through Filezilla over SSH. Temporarily allow SSH on the Webserver and add a security policy to allow SSH. Restrict SSH Access to a specific local IP of your PC.
$ cp privkey.pem /home/someuser/
$ cp cert.pem /home/someuser/
$ chown someuser:someuser /home/someuser/privkey.pem
Move the files somewhere you can easily get access to. (ignore the file private_key.ppk, totally not relevant)
To remove the passphrase from the private key:
$ openssl rsa -in privkey.pem -out privkeywithoutpassphrase.pem
Import the certificate/private key to the Firewall
Device > Certificates > Import
Select “cert.pem” as the Certificate File. Select the option “Import private key” and load privkey.pem as the key file and enter your passphrase.
Adding Decryption Policy
Policies > Decryption > Add
Give the policy a clear name
Choose the zone that’s your external side. Source address should be left to any.
Choose the zone where your webserver resides in. If you’re using a static 1:1 NAT Policy for your webserver, enter the public IP of your webserver and NOT the internal IP address of the webserver.
Select service-https (443/tcp) as the service.
Select Decrypt as your action. Type should be “SSL Inbound Inspection”. Select the Certificate you just uploaded. I’ve used the default Decryption profile. You can make your own under Objects > Decryption > Decryption profile by cloning the default and make your changes as you please.
Enabling antivirus security profile in the security policy
Policies > Security > edit your policy that allows traffic to flow through your webserver. Under Actions, select the default Anti-Virus profile or your own custom profile.
Disable passphrase prompt on apache2 restart
Every time you restart Apache2, it’ll ask for your privkey.pem’s passphrase because you added one. To automate this, we’ll edit the following file
$ vim /etc/apache2/mods-enabled/ssl.conf
Creating the passphrase file:
$ vim /usr/share/apache2/name-of-your-passphrase-file
Add the following:
Make it executable:
$ chmod +x /usr/share/apache2/name-of-your-passphrase-file
The certificate on the firewall has to be renewed every 90 days because Let’s Encrypt doesn’t issue certificates for a period longer than 90 days. So any steps related to certificates in this guide have to be redone. Scripting this is possible, but it’s rather complex.
To verify the firewall is decrypting the traffic, under Policies > Decryption and check the Hit Counter to see how often the firewall decrypted.
Under Monitor > Threat – it’ll show any threats it has stopped (if there were any in the first place). The threat page will only monitor vulnerabilities, viruses and spyware.
993 total views