Intelligent Proxy Steering - Office365
Introduction This solution started back in May 2015 when I was helping a customer bypass their forward proxy servers due to the significant increase in the number of client connections after moving to Office365. Luckily they had a BIG-IP in front of their forward proxy servers load balancing the traffic and F5 had introduced a new “Proxy Mode” feature in the HTTP profile in TMOS 11.5. This allowed the BIG-IP to terminate Explicit Proxy connections, instead of passing them through to the pool members. The original solution was a simple iRule that referenced a data-group to determine if the connection should bypass the forward proxy pool or reverse proxy and load balance the connection as normal. Original iRule: when HTTP_PROXY_REQUEST { # Strip of the port number set hostname [lindex [split [HTTP::host] ":"] 0] # If the hostname matches a MS 0ffice365 domain, enable the Forward Proxy on BIG-IP. # BIG-IP will then perform a DNS lookup and act as a Forward Proxy bypassing the Forward Proxy # Server Pool (BlueCoat/Squid/IronPort etc..) if { [class match $hostname ends_with o365_datagroup] } { # Use a SNAT pool - recommended snatpool o365_snatpool HTTP::proxy } else { # Load balance/reverse proxy to the Forward Proxy Server Pool (BlueCoat/Squid/IronPort etc..) HTTP::proxy disable pool proxy_pool } } As more organisations move to Office365, they have been facing similar problems with firewalls and other security devices unable to handle the volume of outbound connections as they move the SaaS world. The easiest solution may have been just to create proxy PAC file and send the traffic direct, but this would have involved allowing clients to directly route via the firewall to those IP address ranges. How secure is that? I decided to revisit my original solution and look at a way to dynamically update the Office365 URL list. Before I started, I did a quick search on DevCentral and found that DevCentral MVP Niels van Sluis had already written an iRule to download the Microsoft Office365 IP and URL database. Perfect starting point. I’ve since made some modifications to his iRulesLX and a new TCL iRule to support the forward proxy use case. How the solution works The iRuleLX is configured to pull the O365IPAddresses.xml every hour. Reformat into JSON and store in a LokiJS DB. The BIG-IP is configured as an Explicit Proxy in the Clients network or browser settings. The Virtual Server has a HTTP profile attached with the Proxy Mode set to Explicit along we a few other settings. I will go in the detail later. An iRule is attached that executes on the HTTP_PROXY_REQUEST event to check if the FQDN should bypass the Explicit Proxy Pool. If the result is not in the Cache, then a lookup is performed in the iRuleLX LokiJS DB for a result. The result is retuned to the iRule to make a decision to bypass or not. The bypass result is Cached in a table with a specified timeout. A different SNAT pool can be enabled or disabled when bypassing the Explicit Proxy Pool Configuration My BIG-IP is running TMOS 13.1 and the iRules Language eXtension has been licensed and provisioned. Make sure your BIG-IP has internet access to download the required Node.JS packages. This guide also assumes you have a basic level of understanding and troubleshooting at a Local Traffic Manager (LTM) level and your BIG-IP Self IP, VLANs, Routes, etc.. are all configured and working as expected. Before we get started The iRule/iRuleLX for this solution can be found on DevCentral Code Share. Download and install my Explicit Proxy iApp Copy the Intelligent Proxy Steering - Office365 iRule Copy the Microsoft Office 365 IP Intelligence - V0.2 iRuleLX Step 1 – Create the Explicit Proxy 1.1 Run the iApp iApps >> Application Services >> Applications >> “Create” Supply the following: Name: o365proxy Template: f5.explicit_proxy Explicit Proxy Configuration IP Address: 10.1.20.100 FQDN of this Proxy: o365proxy.f5.demo VLAN Configuration - Selected: bigip_int_vlan SNAT Mode: Automap DNS Configuration External DNS Resolvers: 1.1.1.1 Do you need to resolve any Internal DNS zones: Yes or No Select “Finished" to save. 1.2 Test the forward proxy $ curl -I https://www.f5.com --proxy http://10.1.20.100:3128 HTTP/1.1 200 Connected HTTP/1.0 301 Moved Permanently location: https://f5.com Server: BigIP Connection: Keep-Alive Content-Length: 0 Yep, it works! 1.3 Disable Strict Updates iApps >> Application Services >> Applications >> o365proxy Select the Properties tab, change the Application Service to Advanced. Uncheck Strict Updates Select “Update" to save. 1.4 Add an Explicit Proxy server pool In my test environment I have a Squid Proxy installed on a Linux host listening on port 3128. Local Traffic >> Pools >> Pool List >> “Create” Supply the following: Name: squid_proxy_3128_pool Node Name: squid_node Address: 10.1.30.105 Service Port: 3128 Select “Add" and “Finished” to Save. Step 2 – iRule and iRuleLX Configuration 2.1 Create a new iRulesLX workspace Local Traffic >> iRules >> LX Workspaces >> “Create” Supply the following: Name: office365_ipi_workspace Select “Finished" to save. You will now have any empty workspace, ready to cut/paste the TCL iRule and Node.JS code. 2.2 Add the iRule Select “Add iRule” and supply the following: Name: office365_proxy_bypass_irule Select OK Cut / Paste the following Intelligent Proxy Steering - Office365 iRule into the workspace editor on the right hand side. Select “Save File” when done. 2.3 Add an Extension Select “Add extension” and supply the following: Name: office365_ipi_extension Select OK Cut / Paste the following Microsoft Office 365 IP Intelligence - V0.2 iRuleLX and replace the default index.js. Select “Save File” when done. 2.4 Install the NPM packages SSH to the BIG-IP as root cd /var/ilx/workspaces/Common/office365_ipi_workspace/extensions/office365_ipi_extension/ npm install xml2js https repeat lokijs ip-range-check --save 2.5 Create a new iRulesLX plugin Local Traffic >> iRules >> LX Plugin >> “Create” Supply the following: Name: office365_ipi_plugin From Workspace: office365_ipi_workspace Select “Finished" to save. 2.6 Verify the Office365 XML downloaded SSH to the BIG-IP and tail -f /var/log/ltm The Office365 XML has been downloaded, parsed and stored in the LokiJS: big-ip1 info sdmd[5782]: 018e0017:6: pid[9603] plugin[/Common/office365_ipi_plugin.office365_ipi_extension] Info: update finished; 20 product records in database. 2.7 Add the iRule and the Explicit Proxy pool to the Explicit Proxy virtual server Local Traffic >> Virtual Servers >> Virtual Server List >> o365proxy_3128_vs >> Resources Edit the following: Default Pool: squid_proxy_3128_pool Select “Update" to save. Select “Manage…” and move office365_proxy_bypass_irule to the Enabled section. Select “Finished" to save. Step 3 – Test the solution SSH to the BIG-IP and tail -f /var/log/ltm 3.1 Test a non-Office365 URL first $ curl -I https://www.f5.com --proxy http://10.1.20.100:3128 HTTP/1.1 200 Connected HTTP/1.0 301 Moved Permanently location: https://f5.com Server: BigIP Connection: Keep-Alive Content-Length: 0 Output from /var/log/ltm: big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : 10.10.99.31:58190 --> 10.1.20.100:3128 big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : ## HTTP Proxy Request ## big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : CONNECT www.f5.com:443 HTTP/1.1 big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : Host: www.f5.com:443 big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : User-Agent: curl/7.54.0 big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : Proxy-Connection: Keep-Alive big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : www.f5.com not in cache - perform DB lookup big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : www.f5.com - bypass: 0 big-ip1 info tmm2[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : 10.10.99.31:58190 (10.1.30.245:24363) --> 10.1.30.105:3128 3.2 Test the same non-Office365 URL again to confirm the cache works Output from /var/log/ltm: big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : 10.10.99.31:58487 --> 10.1.20.100:3128 big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : ## HTTP Proxy Request ## big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : CONNECT www.f5.com:443 HTTP/1.1 big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : Host: www.f5.com:443 big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : User-Agent: curl/7.54.0 big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : Proxy-Connection: Keep-Alive big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : www.f5.com found in cache big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : www.f5.com - bypass: 0 big-ip1 info tmm1[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : 10.10.99.31:58487 (10.1.30.245:25112) --> 10.1.30.105:3128 3.3 Test a Office365 URL and check it bypasses the Explicit Proxy pool $ curl -I https://www.outlook.com --proxy http://10.1.20.100:3128 HTTP/1.1 200 Connected HTTP/1.1 301 Moved Permanently Cache-Control: no-cache Pragma: no-cache Content-Length: 0 Location: https://outlook.live.com/ Server: Microsoft-IIS/10.0 Connection: close Output from /var/log/ltm: big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : 10.10.99.31:58692 --> 10.1.20.100:3128 big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : ## HTTP Proxy Request ## big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : CONNECT www.outlook.com:443 HTTP/1.1 big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : Host: www.outlook.com:443 big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : User-Agent: curl/7.54.0 big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : Proxy-Connection: Keep-Alive big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : www.outlook.com not in cache - perform DB lookup big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : www.outlook.com - bypass: 1 big-ip1 info tmm3[12384]: Rule /Common/office365_ipi_plugin/office365_proxy_bypass_irule : 10.10.99.31:58692 (10.1.10.245:21666) --> 40.100.144.226:443 It works! Conclusion By combining Microsoft Office365 IP and URL intelligence with LTM, produces a simple and effective method to steer around overloaded Forward Proxy servers without the hassle of messy proxy PAC files.Get Smart with IP Intelligence
There are always threats out there on the big bad internet. The majority of breaches happen at the application layer and many OWASP Top 10s like SQL injection are still malicious favorites to gain entry. Add to that the availability of DDoS tools, anonymous proxies and the rise of hacktivism means networks and systems are bigger targets than ever. Threat detection today relies on a couple elements: Identifying suspicious activity among the billions of data points and refining a large set of suspicious incidents down to those that matter. Today’s cyber-criminals use various techniques to hide their identities and activity. Keeping them out of your systems requires constant vigilance. Every packet that transverses the internet has a source IP address so disabling inbound communications from known malicious IPs can be highly effective. You may not know but F5 offers IP Intelligence Services which provides the functionality to block known malicious IP addresses. It is a layer of IP threat protection and an additional way to allow BIG-IP customers to defend against malicious activity and infrastructure attacks. The IP Intelligence service is offered on several BIG-IP platforms. With IP Intelligence, BIG-IP AFM can be configured to block or allow traffic entering the system based on the reputation of the source IP address. BIG-IP AFM determines reputation using two methods. One is a continuous feed of known or suspected malicious IP addresses provided by a third-party service Webroot BrightCloud. You can also create custom feed lists that specifies IP addresses that have been blacklisted or whitelisted by the organization. The BrightCloud feed is updated every 5 minutes by default and custom feed lists are unique to the AFM and are polled at intervals of your choosing. These two methods are jointly referred to as IP Intelligence and can be used independently or in tandem to filer traffic on the BIG-IP systems. The BrightCloud option is licensed separately through F5 and requires internet connectivity and DNS resolution from your BIG-IP system. Custom feed lists do not need connectivity since it is local to the BIG-IP. IP Intelligence can be applied via AFM firewall policy to the Route Domain or Virtual Server. Once enabled, it will affect all traffic that arrives on your BIG-IP system no matter the access point. The IP Intelligence data is organized into categories that help you differentiate between types of listed IP addresses. There are 11 pre-defined categories including botnets, scanners, infected sources, illegal websites and more. These correspond to the categories in the BrightCloud feed. You can also create up to 51 custom categories to meet your own specific needs. Networks, infrastructures, systems and applications are all under attack these days. While you can do your best at securing your data, sometimes a little call blocking can go a long way in ensuring these known rascals cannot get through. Peace of mind is always a secure feeling. psDNS 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.
