There is a growing trend when it comes to websites. Many years ago, if you visited a site, you were most likely accessing it over HTTP (port 80). This is considered basic web traffic, and can be monitored easily by firewalls. As more and more of our day-to-day activities start to rely on Internet access, that trend has been changing to more sites using HTTPS (443). This is because HTTPS encrypts the data, so sites like Amazon, Facebook, and your bank website can protect your personal or payment information. The estimation is that, by the end of 2019, over 90% of all web traffic will be HTTPS.
While HTTPS sites in general are more secure, there’s another side of the issue. Because these sites are encrypted, it is nearly impossible for a firewall, in its base configuration, to be able to review the data. This wouldn’t be such a big issue, except for the fact that attackers know this. The increase in ransomware, things like Cryptowall, Locky and BadRabbit, have been made worse because they are being distributed through HTTPS sites. These attackers know that most firewalls can’t review all the data on an HTTPS site, so they use them to infect our networks. We, assuming that HTTPS sites are safe, visit these sites without realizing the potential dangers lurking there.
The good news is that not all hope is lost when it comes to protecting ourselves from the potential dangers of unscanned HTTPS sites. Your WatchGuard firewall is capable of scanning this HTTPS content completely, and at no extra licensing fee. This feature, called Deep Packet Inspection (DPI), just has to be configured to ensure your HTTPS traffic is safe. All that this feature relies on outside of your firewall is a trusted certificate that needs to be installed on your devices. In the past, the setup Deep Packet Inspection has been daunting, leading many organizations to take the risk of not scanning their HTTPS traffic. However, by following the steps below, you can enable the service easily, and rest easier knowing your network is fully protected.
STEP 1: DEPLOY THE CERTIFICATE
In order for your firewall to be able to properly review HTTPS traffic, it needs to be a trusted source, which requires an SSL certificate. The good news is that this certificate already resides on the firewall, so you don’t have to purchase anything extra. The only thing you need to do is to deploy this certificate to the computers on your network so that they are also trusted sources.
In order to get the certificate, log into your firewall and open Firebox System Manager. Then go to View > Certificates. Look for the Proxy Authority certificate, and export it.
This certificate is what will need to be installed on the computers in your network. You can install it manually, or can easily roll it out through Group Policy.
NOTE: If you are going to roll it out through Group Policy, make sure to change the file extension to .cer
STEP 2: USE A TEST GROUP
When rolling out DPI, it is best to first test on a select group of users. To do this, you will want to create a new HTTPS policy and define the test group by IP addresses or authentication.
To create the new policy in Policy Manager, select Edit > Add Policy and select the HTTPS-proxy.
Define the From field to identify the test group.
Clone the default HTTPS proxy action.
Rename the proxy action. At the bottom, change the Action from Allow to Inspect. Select the box to Log the action. Then, select your HTTP-proxy action from the drop-down. This is where the services are configured, so it must be used to properly filter the traffic.
STEP 3: DPI WITH WEBBLOCKER
If you have WebBlocker enabled, next go to the WebBlocker tab in your Proxy Action. Select the WebBlocker profile you want to use. At the bottom, again select your HTTP proxy action.
STEP 4: LET DPI RUN
Now that you have all of your DPI settings in place, save your policy. You will want to let these test settings run for at least a week so that you have ample time to test how they work.
Please know that some sites that you visit will possibly get blocked. If this happens, you will need to make a decision on if it is a site you trust. If it is a site you decide you need to allow an exception for, go back into your Proxy Action window for your HTTPS DPI policy. Click Add on the right to create a new exception. Then you will need to name the rule, and put in the domain
Note: DPI exceptions work best when you use the base domain. For example, let’s say the site we are having trouble with is https://meetings.webex.com. If you are trying to write an exception, write it as *.webex.com as shown above.
STEP 5: COMPLETE THE ROLLOUT
Once you have tested Deep Packet Inspection for at least a few days, you can roll it out to everyone in your organization. This can be done by taking your normal HTTPS policy and applying the new DPI proxy action to it. Then you can remove your DPI test policy, bringing everyone’s traffic back to normal but with the added protection of Deep Packet Inspection.
With the increase of HTTPS sites that our users are accessing, we need to ensure we are fully monitoring ALL of our web traffic. If you are not currently utilizing Deep Packet Inspection, the vast majority of your organization’s web traffic is not being filtered. Furthermore, several of your services, such as Gateway Antivirus, APT Blocker and Data Loss Prevention, won’t work on HTTPS traffic without DPI. It’s only a matter of time before that leads to an infection on your network. The good news is that it can be easily remedied. As an added bonus, Deep Packet Inspection works with Windows, Android, and Apple!
If Deep Packet Inspection is something you are interested in deploying but would like assistance, please Contact Us and our WatchGuard experts will be happy to assist you in getting this configured.
Related Posts:
Deploying a WatchGuard DPI Certificate Through Active Directory Group Policy
Deploying a WatchGuard DPI Certificate on a Mac