Jim Black

Layered Security with Enterprise Threat Protector

Blog Post created by Jim Black Employee on Jan 11, 2018

Adopting a defense in depth approach to security is now considered a best practice given the vast and ever evolving range of threats.

 

 

In the event of a threat evading one security layer, having multiple layers of protection ensures that there are other layers of protection that may still detect and block the threat. It’s also the recognition that there is no single security product that delivers 100% protection.

In this blog post, I will give you a quick overview of some of the most common approaches we see customers take to deploy Enterprise Threat Protector as part of a layered security architecture.

 

Deploying Enterprise Threat Protector with a Secure Web Gateway and an Enterprise Firewall

This configuration is most typically used on a large site, for example at a Head Office. The figure below shows a typical deployment.

 

In this setup, all of the traffic from the HQ is sent through a Secure Web Gateway and an Enterprise Firewall. Recursive DNS (rDNS) uses Microsoft Server Active Directory.

 

Let's looks at the the flow when a user makes a request to access an external resource.

 

  1. The device makes a request for example.com. The request hits the Secure Web Gateway (SWG).
  2. The SWG checks the requested URL against the filtering policy assigned to the user of the device. If the URL is not allowed, then the request is dropped and the user receives a block page. If it is allowed, then the SWG sends the DNS request to Active Directory.
  3. Active Directory sends the DNS request to the external Recursive DNS server. Note that If the request is for an internal resource, then Active Directory responds back with the IP address of the internal resource.
  4. The rDNS servers responds with the IP address of the server where example.com is hosted and the IP address is sent back to the device.
  5. The device browser now makes the request to the IP address of the resource.
  6. The response payload is received by the SWG and the content is inspected by inline anti-virus and any other inline security engines.
  7. The requested web page is sent back to the device.

 

 

Now let's take a look at the same configuration with Enterprise Threat Protector deployed as shown in the diagram below.

 

 

It's worth highlighting that the overall architecture is still the same and that the only change is that Active Directory has been configured to send DNS for external resources to Enterprise Threat Protector. Making that change is very simple and consists of changing two IP addresses in your Active Directory setup.

 

This is the request flow with Enterprise Threat Protector deployed.

 

  1. The user makes a request for example.com. The request hits the Secure Web Gateway (SWG).

 

  1. The SWG checks the requested URL against the filtering policy assigned to the user of the device. If the URL is not allowed, then the request is dropped and the user receives a block page. If it is allowed, then the SWG sends the DNS request to Active Directory.

 

  1. Active Directory sends the DNS request to the Enterprise Threat Protector DNS resolver where the domain is checked against the policy configured for the HQ. (Note that If the request is for an internal resource, then Active Directory responds back with the IP address of the internal resource).

  2. If the domain is allowed under the Enterprise Threat Protector policy, the request is sent to  the the rDNS servers.
  3. The rDNS servers respond with the IP address of the server where example.com is hosted and the IP address is sent back to the device

 

  1. The device browser now makes the request to the IP address of the resource.

  2. The response payload is received by the SWG and the content is inspected by inline anti-virus.

  3. The requested web page is sent back to the device.

 

Now let's take a look at the flow when a user tries to access a malicious domain as shown in the diagram below.

 

  1. The user makes a request for example.com. The request hits the Secure Web Gateway (SWG).

 

  1. The SWG checks the requested URL against the filtering policy assigned to the user of the device. If the URL is not allowed then the request is dropped and the user receives a block page. If it is allowed, then the SWG sends the DNS request to Active Directory.

  2. Active Directory sends the DNS request to Enterprise Threat Protector.

 

  1. Enterprise Threat Protector checks the requested domain against the policy that has been created for the HQ. In this example the policy blocks malicious domains.

  2. Enterprise Threat Protector refuses the DNS request and sends back a block page to the device.

 

As can be seen from this example, Enterprise Threat Protector has blocked a request to a malicious domain that was not blocked by the SWG. Of course the SWG may or may not have blocked the response payload, but in security, stopping a threat early and further away from the enterprise is a good approach. It's also worth noting that the request was dropped at the DNS stage and before the IP connection was made. That’s a useful benefit as it reduces the load on on your on-premises devices.

 

Deploying Enterprise Threat Protector with a UTM

 

This configuration is most typically used on a smaller site, for example a Branch Office. The figure below shows a typical deployment where an MPLS connection is used to backhaul traffic to the HQ. Note that all DNS requests are sent to to Active Directory as the branch has no DNS infrastructure.

 

 

Here’s the request flow for this setup.

 

  1. The user in the branch makes a request for example.com. The UTM sends the DNS request to the HQ.

 

  1. The Firewall sends the DNS request to Active Directory which makes a request to the external Recursive DNS servers.

  2. The rDNS server responds with the IP address of the server where example.com is hosted and the IP address is sent back to the device.

  3. The device’s browser now makes an HTTP request to the IP address over the MPLS connection. The firewall sends the request to the Secure Web Gateway (configured in Transparent Proxy mode). The SWG checks the requested URL against the user’s policy.

 

  1. The SWG makes the request to the example.com web server.

  2. The response payload is received by the SWG and the content is inspected by inline anti-virus.

  3. The requested web page is sent back to the device in the branch over the MPLS network.

 

As can be seen from this flow, there’s a lot of complexity in this setup and backhauling all of the DNS traffic and the HTTP/S traffic over the MPLS network can introduce performance problems.

 

One approach is to deploy Enterprise Threat Protector and then route requests for external resources directly to to the Internet. This setup is shown in the diagram below.


Here’s the request flow for this setup.

 

  1. The device in the branch makes a request for example.com. The UTM is configured to forward DNS request for non-corporate domains to ETP. (Note that if the request is for a corporate domain then this is sent as normal over the MPLS network).

  2. ETP receives the request and checks it against the policy configured for the branch.

  3. ETP sends on the request to the rDNS servers.

 

  1. The rDNS servers respond with the IP address of the server where example.com is hosted and the IP address is sent back to the device in the branch.

  2. The device’s browser now makes an HTTP request to the IP address directly over the Internet.

  3. The web server returns the requested resources directly over the Internet.

This direct-to-Internet approach for non-domain resources is a more efficient setup as it eliminates the need to backhaul traffic. Enterprise Threat Protector provides protection for that traffic.

 

Summary

In this blog post I’ve covered some of the more common ways you can deploy Enterprise Threat Protector as part of a layered security architecture.  There are numerous other configurations that I’ve not covered and if you are interested in finding out how ETP might enhance your security posture then please contact your Akamai representative or account manager.

Outcomes