SSL Orchestrator Use Case: SWGaaS
Introduction BIG-IP 16.0 with SSL Orchestrator 9.0 has support for running Secure Web Gateway (SWG) “as a Service” inside the Service Chain.This allows you to take an existing F5 SWG solution and migrate or move it to the same BIG-IP as SSL Orchestrator. Typical SWG features include: User authentication (not covered here) Enforcement of an Acceptable Use Policy (AUP) Website category database (google.com = Search Engines) Logging and Reporting (not covered here) A typical SWG deployment will have a Per-Session Policy that handles authentication.Then a Per-Request Policy that enforces the AUP. User authentication (not covered here) Refer to this Dev/Central Article for more information on this topic. Enforcement of an Acceptable Use Policy (AUP) A Per-Request Policy is used to enforce the AUP.You can find this from the Configuration Utility under Access > Profiles / Policies > Per-Request Policies.Click Edit for the Per-Session Policy and a new window like this should open: This policy does a Protocol Lookup to determine if the content is HTTP, then performs a Category Lookup based on the host header in the URI.Response Analytics will check for malicious content and pass that information on to the URL Lookup Agent. The Category is compared to the URL Filter which maps URL categories to Allow/Deny Actions.As a final result the request is either Allowed or Denied (Reject). Note: In a per-request SWG policy you would typically have a Protocol Lookup for HTTP and HTTPS.But in this case the SSL Orchestrator will perform SSL decryption so the SWG Service will receive plain-text, HTTP content.Therefore, this SWG policy is ready to be used with SSL Orchestrator. Website category database (google.com = Search Engines) The URL Filter is configured from Access > Secure Web Gateway > URL Filters. Select CorporateURLFilter in this example. This opens the Category editor.Different Categories and sub-categories are available to make Allow or Deny decisions.In this example the Games and Shopping categories have been set to Deny. Logging and Reporting (not covered here)Refer to the AskF5 Knowledge Center for more information. Configuration Export / Import the SWG Per-Request Policy The SWG Per-Request Policy is easy to export from one BIG-IP to another.From the Configuration Utility select Access > Profiles / Policy > Per-Request Policies. Click Export then OK to save the policy. The policy file can be directly imported into another BIG-IP device.On the Per-Request Policies screen click Import. Give the Policy a name, click Browse to select the policy file then Import. This policy is ready for SSL Orchestrator to use with SWGaaS.You can click Edit to verify the policy is correct. Configure the F5 SWGaaS From the SSL Orchestrator Configuration page select Services then click Add. F5 Secure Web Gateway is available on the F5 tab.Double-click the icon to configure. Give it a name.Set the Access Profile Scope to Profile.Set the Per Request Policy to the policy imported previously.Click Save and Next. Add the newly created SWGaaS to an existing Service Chain or create a new one. Select the F5_SWG Service on the left and click the right arrow to move it to the Selected column.Click Save. Save & Next. Then Deploy. Test SWG Functionality Note: be sure that a Security Policy has the Service Chain applied.Go to a client computer and test access to various web sites.News sites are allowed but Shopping is set to Block so sites like amazon.com and walmart.com should be blocked. Details from espn.com.The padlock indicates the connection is encrypted.The Issued By field indicates that this was intercepted & signed by SSL Orchestrator. Any attempts to visit a site categorized as Shopping or Games will be blocked. The configuration is now complete.
HTTP Explicit Proxy Explained in Plain English
Introduction If you've ever used the old Linux Squid proxy or F5's Secure Gateway solution, you might be familiar with the existence of HTTP Explicit Proxy. If all you're looking for is to configure it ASAP, there's an iApp available to set things up in no time. This technology is also used by F5's Secure Web Gateway Services (SWG). This article will walk you through the mechanics behind the scenes, i.e. how to manually configure it and understand how it works through a lab test. 1. Lab Scenario Expected result is thatclient (.135) sends HTTP GET request to server2.rodrigo.example using 10.199.3.100/32 as http proxy andBIG-IP queries our DNS server (172.16.199.31) for server2.rodrigo.example's IP address, retrieves web page and passes on to client. 2. How Explicit Proxy works In HTTP Explicit proxy, we configure our client (application) to point to BIG-IP's virtual server which will act as an HTTP proxy for external websites. Once client issues a request, BIG-IP will then open a separate connection with external server the client is trying to connect to and issue the requests on behalf of client passing requests/responses back and forth between client and external server. In order to test HTTP Explicit proxy functionality, I configured my client's browser pointing to BIG-IP's HTTP Explicit proxy virtual server. BIG-IP is supposed to issue the requests on behalf of client and pass them back to client. The client is explicitly configured to use VIP's IP address as a proxy. Here's my config on Firefox (Preferences→ Advanced→ Network): When using any form of unencrypted traffic Firefox forwards request straight to BIG-IP without issuing an HTTP CONNECT request: We can see that BIG-IP just forwards request mostly as it is. The reason forGET /instead ofFQDNon server-side is because BIG-IP performed DNS resolution before that and I filtered it. If request is HTTPS instead of HTTP, things are slightly different. First, Firefox (my browser) tries to establish an HTTP tunnel (using CONNECT HTTP method) tohttps://server2.rodrigo.example, BIG-IP then immediately establishes TCP connection with remote-destination (after DNS lookup of course!). Lastly, once TCP connection is established with remote-destination, BIG-IP responds (to client) with 200 Connected signalling tunnel is successfully established and BIG-IP is ready to forward any requests through recently established tunnel: Now that tunnel is properly established, BIG-IP just forwards whatever Firefox sends. In this case, the SSL handshake Client Hello was the first packet which was captured: It is interesting to note that there is still an HTTP header in the messages between client and BIG-IPwith proxy information sent by firefox (frame 47) that encapsulates SSL message: Now that we understand how HTTP Explicit proxy works under the hood, we're ready to learn how to set up BIG-IP as Explicit proxy. 3. Setting Up Explicit proxy on BIG-IP 3.1 Create Virtual Server with no pool (you can leave http profile for later): 3.2 Create DNS resolver: In the GUI, it would be on Network → DNS Resolvers → Create. Then, we'd click on Forward Zones and add a dot '.' if we want all queries to be sent to this name server. For the purposes of this specific test, I could also have named this zone asrodrigo.example.instead. Note: In my lab test I worked out that forward zone's name is really important! When I named it 'testing' or 'google' BIG-IP did not forward DNS query to 172.16.199.31. However, when I named it either . or rodrigo.example. then DNS resolution worked. 3.3 Create tunnel interface BIG-IP already has a default http-tunnel interface. As long as encapsulation type istcp-forward, we can either stick to default or create a new one. I decided to create a new one for the purpose of this lab test: 3.4. Create http profile using http-explicit as parent and assign it to VIP created previously: Note: When configuring it from GUI just set proxy type to explicit and http-explicit will be set to parent profile. The equivalent in the GUI: 3.5. Testing Connection 3.6 Enabling encrypted requests Initially I did not understand why HTTP traffic worked whendefault-connect-handling was set to deny but HTTPS did not. Below is the summary of my tests: Looking at the packet capture, I noticed that BIG-IP was explicitly denying Firefox's request to establish a tunnel as shown below: Note: For this test I created another Virtual Server called using a different address 10.199.3.101 instead of the one I originally tested just to test default-connect-handling. After reading K40243113: Overview of the HTTP profile, I kind of understood the point: "indicates that outbound requests are delivered only if another virtual server is listening on the tunnel for the requested outbound connection. With this setting, virtual servers are required, and the system processes the outbound traffic before it leaves the device." I then created another VIP withsamedestination IP address and port as back-end server client was trying to connect to just to confirm if this time traffic would go through: And indeed it worked: I also tested with a wildcard virtual server listening on *:443 instead of 172.16.199.32/32 and it worked fine as well. What we have observed so far is that when default-connect-handling is set to deny,in order for encrypted client traffic to be accepted by BIG-IP and proxy tunnel established, the destination address that matches the one on client request has to have a listener on BIG-IP for return traffic. Therefore, we can conclude thatdefault-connect-handlingsetting governs what traffic is accepted by the tunnel interface, but unencrypted requests are not affected. The below picture sums up the explanation: default-connect-handling just adds the extra step to validate whether there is a listener on BIG-IP for destination address:port or not. If not, we deny request. If yes, request goes through.SSL Forward Proxy Explained using Wireshark
Related articles:SSL Legacy Renegotiation vs Secure Renegotiation Explained using Wireshark Summary The idea behind this feature is to allow BIG-IP to sniff into SSL connections to any Internet destination that goes through it whilst preserving client's trust of the destination. When this feature is enabled, BIG-IP uses a pre-installed CA set underproxy-ca-cert(CA Certificatein the GUI) that is also trusted by client's browser and BIG-IP pretends to be the Internet destination by re-signing SSL certificates on the fly with the aforementioned CA and using public key from CA configured undercerton BIG-IP. The client trusts the connection and is unaware of BIG-IP's presence. The most common use case isSecure Web Gateway(SWG), although neither APM nor SWG are needed to deploy SSL Forward Proxy functionality.LTM is enough. Lab Scenario Lab test results: Client opens connection with BIG-IP and sendsClient Hello. BIG-IP immediately opens connection with web server and completes SSL handshake. BIG-IP creates unique certificate with following information and sends it over viaServer Hello: Serial number: random Issuer: copied fromdefault.crt Validity: notBefore (copied fromserver1.crt), notAfter: 30 days counting from time it was generated (configurable viacert-lifespanorCertificate Lifespanin the GUI) Subject: copied fromserver1.crt Public Key: copied fromltm2.CA.crt All X.509extensionsallowed incert-extensions-includeare also copied fromserver1.crtto unique custom certificate Client-side handshake completes successfully using above dynamically generated custom certificate just created by BIG-IPand data exchange works as expected. How SSL Forward Proxy works on Wireshark Actual capture used for below explanation is attached to this article below (and heressl-forward-sample-3.pcap ) Upon Client Hello sent by Client BIG-IP rushes to open new connection and completes server-side SSL handshake: Server-side handshake completes on frames 17-18 and and BIG-IP immediately resumes and completes Client-side handshake.Note:The reason why BIG-IP waits for server-side handshake to complete first is because BIG-IP uses server-side certificate information to generate acustomcertificate that will be sent to Client on client-side. The most interesting bit here is BIG-IP'sCertificatemessage sent on frame 20 to Client as it contains the customCertificate generated by BIG-IP: We can see there are 2 Certificates: CA Certificate(proxy-ca-cert) is the Certificate Authority (CA) that signs the newly created custom certificate and is supposed to be trusted by Client to confirm BIG-IP's custom (dynamically generated) certificate can be trusted too. We can immediately work out that the 2nd certificate isdefault.crtjust by matching its serial number which is unique for each issuer: However, the first certificate looked a mystery to me until I found where all the pieces came from. The serial number looks randomly generated to me as it doesn't match (not even close to any of the certificates above): The Issuer field, which shows information about who signed the certificate, shows thatdefault.crtwas the one who signed BIG-IP's custom certificate: Certificate generation date (notBefore) is copied fromserver1.crtbut expiry date (notAfter) is calculated based oncert-lifespan(Certificate Lifespanin the GUI) which by default is 30 days added to time custom certificate was generated: Subject fields, which shows information about the current certificate, is copied and identical to information onserver1.crt: And finally, the public key is copied fromcertfield (ltm2CA.crt). Notice they are the same: That's enough information for now.
F5 SSL Orchestrator and Cisco WSA Solution for SSL Visibility and Management
Data transiting between clients (e.g., PCs, tablets, phones, etc.) and servers are predominantly encrypted with Secure Socket Layer (SSL) or the newer Transport Layer Security (TLS) (For reference, see the 2019 TLS Telemetry Report Summary from F5 Labs) Pervasive encryption results in threats being hidden and invisible to security inspection unless traffic is decrypted. The decryption and encryption of data by different devices that are performing security functions, such as Cisco Web Security Appliance (WSA), potentially increases overhead and latency. Added to the visibility difficulties and the fragmented nature of the security stack, enterprises are finding it challenging to design a comprehensive and lasting security strategy. F5® SSL Orchestrator™ and Cisco WSA integrate to deliver centralized visibility, orchestration, security, and control of web traffic, optimizing protection from web-based threats against any device. Bill of Materials F5 SSL Orchestrator Optional functional add-ons include URL filtering subscription, IP Intelligence subscription, network hardware security module (HSM), and F5 Access Manager (APM). Cisco Web Security Appliance Pre-requisites F5 SSL Orchestrator is licensed and set up with internal and external VLANs and self-IP addresses. An SSL certificate—preferably a subordinate certificate authority (CA)—and private key are imported into SSL Orchestrator. The CA certificate chain with the root certificate is imported into the client browser. SSL orchestration generally presents a new paradigm in the typical network architecture. Integrated with SSL Orchestrator, the traffic to the Cisco WSA is decrypted – including usernames, passwords, social security, and credit card numbers, etc. It is therefore highly recommended that security services be isolated within a private, protected enclave defined by the SSL Orchestrator. Solution Deployment In this example deployment setup, the SSL Orchestrator is configured to send decrypted traffic to an inline Cisco WSA. SSL Orchestrator handles both decryption and re-encryption of HTTPS traffic, with an inspection zone installed between the ingress and egress. Decrypted traffic is steered to a service pool of Cisco WSA devices. You can also deploy the F5 system as a device sync/failover device group (including an HA pair) with a floating IP address for high availability. How traffic flows in this deployment: Client traffic arrives at the ingress side of the SSL Orchestrator, where it is classified, and interesting HTTPS traffic is decrypted as part of the SSL handling process. SSL Orchestrator steers the decrypted traffic through the load balanced Cisco WSA service pool as part of a service chain that potentially includes multiple types of security services. The HTTP traffic is inspected by the Cisco WSA services for any hidden threats before sending that traffic back to the SSL Orchestrator. The SSL Orchestrator orchestrates the decrypted traffic through other services in the chain before it aggregates and re-encrypts the traffic, which is then routed to the next destination. Configure the Web Proxy Service Please refer to the appropriate Cisco WSA documentation for more detailed information on configuring WSA. The following are the minimal settings required for integration with SSL Orchestrator. Configuration of the web proxy will be performed from the WSA UI. The Cisco WSA can be configured as either a transparent or explicit web proxy. Deploy SSL Orchestrator using Guided Configuration The SSL Orchestrator guided configuration presents a completely new and streamlined user experience. This workflow-based architecture provides guided configuration steps tailored to a selected topology. Step 1: Topology Properties SSL Orchestrator creates discreet configurations based on the selected topology. Select L3 Outbound (transparent proxy) or L3 Explicit Proxy to support decrypted forward proxy traffic flows through the Cisco WSA. Step 2: SSL Configuration Select the previously imported subordinate CA certificate (see Prerequisites, above) for signing and issuing certificates to the end-host for client-requested HTTPS websites that are intercepted by SSL Orchestrator. Step 3: Create the Cisco WSA Service The services list section defines the security services that interact with SSL Orchestrator. The guided configuration includes a services catalog that contains common product integrations. In the service catalog, double click the 'Cisco WSA HTTP Proxy' service and configure the service settings: Cisco WSA IP address, port, and connected VLANs. Create these routes to route from the Cisco WSA appliance back to SSL Orchestrator. A gateway route to SSL Orchestrator 'from-service' self-IP ( 198.19.96.245 in the above example). A static return route to define the path back to the SSL Orchestrator 'to-service' self-IP (198.19.96.7 in the above example) on the inbound side of the Cisco WSA. Using the SSL Orchestrator service catalog, create additional security services as required before proceeding to the next step. Step 4: Service Chains Create a service chain, which is an ordered list of security devices. The service chain determines which services receive decrypted traffic. Step 5: Security Policy SSL Orchestrator’s guided configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface; the underlying per-request policy can be managed directly. Use this section to create custom rules as required. Step 6: Intercept Rule Interception rules are based on the selected topology and define the listeners (analogous to BIG-IP Local Traffic Manager virtual servers) that accept and process different types of traffic, such as TCP, UDP, or other. The resulting listeners will bind the SSL settings, VLANs, IPs, and security policies created in the topology workflow. Step 7: Egress Settings The egress settings section defines topology-specific egress characteristics like NAT and outbound route. Step 8: Summary Review the setting and click deploy SSL Orchestrator. Testing the Solution Use one of the following ways to observe the decrypted traffic Server certificate test To test an explicit forward proxy topology, configure a client’s browser proxy settings to point this listening IP and port. Ensure that the client trusts the local issuing CA certificate. Open a browser from the client and attempt to access an external HTTPS resource. Once the page is loaded, observe the server certificate of that site and take note of the certificate issuer, which should be the local issuing CA. If you have access to the client’s command-line shell and the cURL or wget utilities, you can simulate browser access using one of the following commands: curl -vk --proxy [proxy IP:port] https://www.example.com wget --no-check-certificate -e use_proxy=yes -e https_proxy=[proxy IP:port] -dO – https://www.example.com Both of these commands will display both the HTML server response and the issuer of the server’s certificate. Decrypted traffic analysis on the SSL Orchestrator Perform a tcpdump on the SSL Orchestrator to observe the decrypted clear text traffic. This confirms the SSL interception by the F5 system. tcpdump –lnni [interface or VLAN name] -Xs0 The security service VLANs and their corresponding application services are all visible from the SSL Orchestrator GUI: Network -> VLANs. Decrypted traffic analysis on the Cisco WSA From the web UI, navigate to Help and Support > Packet Capture. Edit the packet capture settings, such as the network interface on which the packet capture runs. Use one of the predefined filters, or create a custom filter and Click Start Capture to begin. Click Stop Capture to end the capture. Download the packet capture and analyze the tcpdump to observe the decrypted clear text traffic. Additional Resources Learn more about SSL Orchestrator on f5.com Recommended best practices guide: SSL Orchestrator and Cisco WSA SolutionF5 SSL Orchestrator and McAfee Web Gateway Solution for SSL Visibility and Management
Data transiting between clients (e.g. PCs, tablets, phones, etc.) and servers are predominantly encrypted with Secure Socket Layer (SSL) or the newer Transport Layer Security (TLS). Pervasive encryption results in threats being hidden and invisible to security inspection unless traffic is decrypted. This creates serious risks, leaving organizations vulnerable to costly data breaches and loss of intellectual property (For reference, see the TLS Telemetry Report Summary from F5 Labs). An integrated F5 SSL Orchestrator and McAfee Web Gateway (MWG) solution provide visibility and management of SSL/TLS traffic to expose the hidden malware, data exfiltration, and command and control threats. F5 SSL Orchestrator with its ability to address HTTP proxy devices inside its decrypted inspection zone allows the MWG to provide optimal security functionality while offloading SSL and complex orchestration to the F5 system. Bill of Materials F5 SSL Orchestrator Optional functional add-ons include URL filtering subscription, IP Intelligence subscription, network hardware security module (HSM), and F5 Access Manager (APM). McAfee Web Gateway Pre-requisites F5 SSL Orchestrator is licensed and set up with internal and external VLANs, and self-IP addresses. An SSL certificate—preferably a subordinate certificate authority (CA)—and private key are imported into SSL Orchestrator. The CA certificate chain with the root certificate is imported into the client browser. SSL orchestration generally presents a new paradigm in the typical network architecture. Integrated with SSL Orchestrator, the traffic to the MWG is decrypted – including usernames, passwords, social security, and credit card numbers, etc. It is therefore highly recommended that security services be isolated within a private, protected enclave defined by the SSL Orchestrator. Solution Deployment In this example deployment setup, the SSL Orchestrator is configured to send decrypted traffic to an inline MWG. SSL Orchestrator handles both decryption and re-encryption of HTTPS traffic, with an inspection zone installed between the ingress and egress. Decrypted traffic is steered to a service pool of MWG devices. You can also deploy the F5 system as a device sync/failover device group (including an HA pair) with a floating IP address for high availability. Configure the Web Proxy Service Before the MWG can receive traffic from the SSL Orchestrator, there are a few basic configurations that must be completed.Any and all licenses should be applied, and the basic system setup should be completed. Along with many other settings, the system setup will include the configuration of the hostname and Domain Name Servers (DNS).The system hostname should be configured as well as the IP address, subnet mask, and hostname for the management interface. The following settings will detail how to configure MWG as an explicit proxy. Please refer to the appropriate MWG documentation for more detailed information on configuring MWG. In the MWG UI under Appliances -> (this appliance) -> Proxies (HTTP(S), FTP, SOCKS, ICAP…): Deploy SSL Orchestrator using Guided Configuration The SSL Orchestrator guided configuration presents a completely new and streamlined user experience. This workflow-based architecture provides guided configuration steps tailored to a selected topology. Step 1: Topology Properties SSL Orchestrator creates discreet configurations based on the selected topology. Select L3 Outbound (transparent proxy) or L3 Explicit Proxy to support decrypted forward proxy traffic flows through the MWG. Step 2: SSL Configuration Select the previously imported subordinate CA certificate (see Prerequisites, above) for signing and issuing certificates to the end-host for client-requested HTTPS websites that are intercepted by SSL Orchestrator. Step 3: Create the McAfee Web Gateway Service The services list section defines the security services that interact with SSL Orchestrator. The guided configuration includes a services catalog that contains common product integrations. In the service catalog, double click the 'McAfee Secure Web Gateway HTTP Proxy' service and configure the service settings: McAfee Web Gateway IP address, port, and connected VLANs. In the MWG Web UI, create these routes to route from the MWG appliance back to SSL Orchestrator. A gateway route to SSL Orchestrator 'from-service' self-IP ( 198.19.96.245 in the above example). A static return route to define the path back to the SSL Orchestrator 'to-service' self-IP (198.19.96.7 in the above example) on the inbound side of the MWG. Using the SSL Orchestrator service catalog, create additional security services as required before proceeding to the next step. Step 4: Service Chains Create a service chain, which is an ordered list of security devices. The service chain determines which services receive decrypted traffic. Step 5: Security Policy SSL Orchestrator’s guided configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly. Use this section to create custom rules as required. Step 6: Intercept Rule Interception rules are based on the selected topology and define the listeners (analogous to BIG-IP Local Traffic Manager virtual servers) that accept and process different types of traffic, such as TCP, UDP, or other. The resulting listeners will bind the SSL settings, VLANs, IPs, and security policies created in the topology workflow. Step 7: Egress Settings The egress settings section defines topology-specific egress characteristics like NAT and outbound route. Step 8: Summary Review the setting and click deploy SSL Orchestrator. Testing the Solution Use one of the following ways to observe the decrypted traffic Server certificate test To test an explicit forward proxy topology, configure a client’s browser proxy settings to point this listening IP and port. Ensure that the client trusts the local issuing CA certificate. Open a browser from the client and attempt to access an external HTTPS resource. Once the page is loaded, observe the server certificate of that site and take note of the certificate issuer, which should be the local issuing CA. If you have access to the client’s command-line shell and the cURL or wget utilities, you can simulate browser access using one of the following commands: curl -vk --proxy [proxy IP:port] https://www.example.com wget --no-check-certificate -e use_proxy=yes -e https_proxy=[proxy IP:port] -dO – https://www.example.com Both of these commands will display both the HTML server response and the issuer of the server’s certificate. Decrypted traffic analysis on the SSL Orchestrator Perform a tcpdump on the SSL Orchestrator to observe the decrypted clear text traffic. This confirms the SSL interception by the F5 system. tcpdump –lnni [interface or VLAN name] -Xs0 The security service VLANs and their corresponding application services are all visible from the SSL Orchestrator GUI: Network -> VLANs. Decrypted traffic analysis on the McAfee Web Gateway From the MWG UI, use the Packet Tracing feature to capture traffic on all interfaces. Analyze the tcpdump to observe the decrypted clear text traffic. Additional Resources Learn more about SSL Orchestrator on f5.com Recommended best practices guide: F5 SSL Orchestrator and McAfee Web Gateway SolutionDNS Interception: Protecting the Client
Introduction Everything starts with a DNS request. So why not use it to protect the client? With the recent addition of Secure Web Gateway Services to the F5 line up of modules in TMOS 11.5, it provided the ability to access a URL Categorization database via iRules that contains 150 URL categories and identifies over 60 million URLs. Pair that with the IP Intelligence Services that was introduced in TMOS 11.2 and some DNS iRules, you now have a solution to filter all DNS Requests and Reponses originating from your network. This simple but powerful tool gives you the ability to protect clients which you may not have control over by sending back a Non-Existent Domain in the response to prevent the client from connecting to the malicious server or undesirable content. This iRule solution is applied to a DNS resolver or a catch all (0.0.0.0/0:53) DNS virtual server where the BIG-IP is a default gateway. It allows the BIG-IP to explicitly or transparently intercept all DNS Requests and Responses from the client and apply security filtering controls. This solution is suited to almost any outbound DNS scenario where you need to protect the client from accessing malicious threats or undesirable content intentionally or unintentionally. One example where you may find this solution handy, is on a Guest or BYOD network where you need a transparent method of adding security when you don’t have control of the client. How the solution works Scenario 1: The BIG-IP is configured as a DNS resolver and the client’s DNS settings have been configured via DHCP with the IP of the BIG-IP as the LDNS. Scenario 2: The BIG-IP is a default gateway on the network and a catch all (0.0.0.0/0:53) DNS virtual server transparently intercepts all DNS Requests an Responses. The client’s DNS settings have been configured via DHCP with the IP of a LDNS that has to traverse the BIG-IP. Scenario 3: The BIG-IP is a default gateway on the network and a catch all (0.0.0.0/0:53) DNS virtual server transparently intercepts all DNS Requests an Responses. The client’s DNS settings have been configured via DHCP or manually with a public DNS service (e.g Google, Open DNS, etc.) an the client has to traverse the BIG-IP. The “client” in the above scenarios doesn’t have to be an end user device such as a tablet, it could be a forward proxy server for example. The iRule is applied to the virtual server (VS) with a DNS profile and the events DNS_REQUEST and DNS_RESPONSE are triggered. When the DNS_REQUEST is triggered, the DNS Question Name is passed to the URL Categorization database using CATEGORY::lookup. When the DNS_RESPONSE is triggered, the IP address in the DNS Response can be passed to IP Intelligence database using IP::reputation. Solution Features DNS Request Filtering configurable items: DNS Request Filtering - Enable or Disable all DNS_REQUEST filtering. URL Categories e.g. Adult_Content, Hacking. If the DNS Question (FQDN - e.g. playboy.com) matches a category in the data group (default: dns_request_url_categories_dg), NXDOMAIN will be returned in the response. DNS Question Type e.g. A, AAAA, ANY etc. Only the Question Types configured in the data group (default: dns_request_question_type_dg) will be filtered. FQDN/TLD Whitelist e.g. f5.com or .gov. Any FQDN/TLD in the whitelist data group (default: dns_request_fqdn_whitelist_dg) will bypass DNS_REQUEST filtering regardless of the Question Type or URL Category. DNS Response Filtering configurable items: DNS Response Filtering - Enable or Disable all DNS_RESPONSE filtering. IP/Subnet Whitelist e.g 192.168.0.0/16 or 1.1.1.1. Any IP or IP Subnet in the whitelist data group will bypass DNS_RESPONSE filtering. IPI Threat Categories e.g. Spam Sources, Phishing. If the DNS RDATA (A & AAAA only) matches a category in the data group, NXDOMAIN will be returned in the response. Global Parameters Logging Control - Off, Level 1 (NXDOMAIN and Whitelist Matching) and Level 2 (All DNS Requests & Responses) Requirements - BIG-IP Version / Licensing BIG-IP 11.2+ for IPI Subscription (DNS Response filtering) BIG-IP 11.5+ for URL Categorization or SWG Subscription (DNS Request filtering) Licensing: GTM/DNS or DNS Services add-on to LTM URL Categorization Subscription or SWG Subscription for DNS Request filtering IPI Subscription for DNS Response filtering Configuration 1. Data Groups Multiple data groups are used throughout the solution to make it easy for the administrator to make changes on the fly without having to change the iRule. By default, the following data groups need to be created. The values can be modified to your liking. 1.1 Data Group Name: dns_request_url_categories_dg Purpose: URL Category Names If the DNS Question Name (e.g. playboy.com) matches a category (Adult_Content) in the data group, NXDOMAIN will be returned in the response. To obtain a list of possible URL Categories and their descriptions, run: tmsh list sys url-db url-category { description }. Example categories are included below. TMSH: create ltm data-group internal dns_request_url_categories_dg type string modify ltm data-group internal dns_request_url_categories_dg records add {"Adult_Content"} modify ltm data-group internal dns_request_url_categories_dg records add {"Advanced_Malware_Command_and_Control"} modify ltm data-group internal dns_request_url_categories_dg records add {"Advanced_Malware_Payloads"} modify ltm data-group internal dns_request_url_categories_dg records add {"Bot_Networks"} modify ltm data-group internal dns_request_url_categories_dg records add {"Compromised_Websites"} modify ltm data-group internal dns_request_url_categories_dg records add {"Elevated_Exposure"} modify ltm data-group internal dns_request_url_categories_dg records add {"Emerging_Exploits"} modify ltm data-group internal dns_request_url_categories_dg records add {"Hacking"} modify ltm data-group internal dns_request_url_categories_dg records add {"Keyloggers"} modify ltm data-group internal dns_request_url_categories_dg records add {"Malicious_Embedded_Link"} modify ltm data-group internal dns_request_url_categories_dg records add {"Malicious_Embedded_iFrame"} modify ltm data-group internal dns_request_url_categories_dg records add {"Malicious_Web_Sites"} modify ltm data-group internal dns_request_url_categories_dg records add {"Militancy_and_Extremist"} modify ltm data-group internal dns_request_url_categories_dg records add {"Mobile_Malware"} modify ltm data-group internal dns_request_url_categories_dg records add {"Newly_Registered_Websites"} modify ltm data-group internal dns_request_url_categories_dg records add {"Nudity"} modify ltm data-group internal dns_request_url_categories_dg records add {"Peer-to-Peer_File_Sharing"} modify ltm data-group internal dns_request_url_categories_dg records add {"Phishing_and_Other_Frauds"} modify ltm data-group internal dns_request_url_categories_dg records add {"Proxy_Avoidance"} modify ltm data-group internal dns_request_url_categories_dg records add {"Sex"} modify ltm data-group internal dns_request_url_categories_dg records add {"Spyware"} modify ltm data-group internal dns_request_url_categories_dg records add {"Tasteless"} modify ltm data-group internal dns_request_url_categories_dg records add {"Web_and_Email_Spam"} 1.2 Data Group Name: dns_request_question_type_dg Purpose: DNS Question Types Only the Question Types (e.g. A, AAAA) configured in the data group will be filtered. Example Question Types are included below. TMSH: create ltm data-group internal dns_request_question_type_dg type string modify ltm data-group internal dns_request_question_type_dg records add {"A"} modify ltm data-group internal dns_request_question_type_dg records add {"AAAA"} modify ltm data-group internal dns_request_question_type_dg records add {"ANY"} modify ltm data-group internal dns_request_question_type_dg records add {"CNAME"} modify ltm data-group internal dns_request_question_type_dg records add {"MX"} 1.3 Data Group Name: dns_request_fqdn_whitelist_dg Purpose: FQDN / TLD Whitelisting Any FQDN/TLD (e.g. f5.com or .gov) in the whitelist data group will bypass DNS_REQUEST filtering regardless of the Question Type or URL Category. Example Question Types are included below. TMSH: create ltm data-group internal dns_request_fqdn_whitelist_dg type string modify ltm data-group internal dns_request_fqdn_whitelist_dg records add {"f5.com"} 1.4 Data Group Name: dns_response_ip_whitelist_dg Purpose: IP / Subnet Whitelisting Any IP or IP Subnet in the whitelist data group will bypass DNS_RESPONSE filtering regardless of the IP Reputation. TMSH: create ltm data-group internal dns_response_ip_whitelist_dg type ip modify ltm data-group internal dns_response_ip_whitelist_dg records add {"10.0.0.0/8"} modify ltm data-group internal dns_response_ip_whitelist_dg records add {"172.16.0.0/12"} modify ltm data-group internal dns_response_ip_whitelist_dg records add {"192.168.0.0/16"} 1.5 Data Group Name: dns_response_ipi_categories_dg Purpose: IP Intelligence Category Names TMSH: create ltm data-group internal dns_response_ipi_categories_dg type string modify ltm data-group internal dns_response_ipi_categories_dg records add {"BotNets"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Networks"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Denial of Service"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Illegal"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Infected Sources"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Phishing"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Scanners"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Spam Sources"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Web Attacks"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Windows Exploits"} 2. iRule iRule Name: dns_request_response_filter_irule -> https://devcentral.f5.com/s/articles/dns-request-and-response-filtering-using-url-db-and-ipi-subscriptions The iRule is applied to the DNS resolver or a catch all (0.0.0.0/0:53) DNS virtual server. The logic is explained below and has been built to cater for most situations. Simply save the iRule to the BIG-IP using the Codeshare link above. DNS Request iRule logic: DNS Response iRule logic: 3. Virtual Servers, Pools, Nodes and DNS Profile 3.1 BIG-IP as a DNS Resolver (Scenario 1) When the BIG-IP is configured as a DNS Resolver, you need to configure a LDNS for the BIG-IP to resolve the requests. In my example I’m using Google’s public DNS servers. Make sure you change the Virtual Server IP and/or any other settings to suit your environment. TMSH: create ltm node google-public-dns-a { address 8.8.8.8 } create ltm node google-public-dns-b { address 8.8.4.4 } create ltm pool google_dns_pool { members replace-all-with { google-public-dns-a:domain google-public-dns-b:domain } } create ltm profile dns dns_interception { cache none defaults-from dns dns64 disabled dns-security none enable-cache no enable-dns-express no enable-dns-firewall no enable-dnssec no enable-gtm no enable-logging no process-rd yes process-xfr no unhandled-query-action allow use-local-bind no } create ltm virtual dns_resolver_udp_vs { destination 10.1.1.1:domain ip-protocol udp profiles replace-all-with { udp_gtm_dns dns_interception } source-address-translation { type automap } rules { dns_request_response_filter_irule } pool google_dns_pool } 3.2 BIG-IP is a default gateway (Scenario 2 and 3) When the BIG-IP is configured as a default GW, you only need to configure the catch all (0.0.0.0/0:53) DNS virtual server and the DNS Profile. Make sure you change the VLAN and/or any other settings to suit your environment. TMSH: create ltm profile dns dns_interception { cache none defaults-from dns dns64 disabled dns-security none enable-cache no enable-dns-express no enable-dns-firewall no enable-dnssec no enable-gtm no enable-logging no process-rd yes process-xfr no unhandled-query-action allow use-local-bind no } create ltm virtual catch_all_dns_udp_vs { destination 0.0.0.0:domain ip-protocol udp profiles replace-all-with { udp_gtm_dns dns_interception } vlans-enabled vlans replace-all-with { vlan1 } rules { dns_request_response_filter_irule } translate-address disabled } Conclusion By combining threat intelligence services with DNS, produces a simple and effective protection in a IoT world.
