QUIC is the Quick UDP Internet Connections protocol, developed by Google and currently in IETF workgroups for further development. It is being considered for replacing TCP as a transport protocol for HTTP/3. Join Jason in this Lightboard Lesson as he gives an overview of the protocol in light of a transition from TCP. Resources Next generation multiplexed transport over UDP Google’s QUIC Protocol: Moving the Web from TCP to UDP QUIC Datatracker at IETF

Stop! You must be this smart to read this article! Seriously, dude, put down the wireless trackball and back away from the computer. RIGHT NOW. Because this article is too hardcore for you. Yeah, yeah, you’ve read the previous Top Ten Hardcore Security Feature lists (12, 12.1, 13), and you think you’re clever, but just stahp. You’re not ready for this one. You are strongly advised to stand down and read the standard version 14.0 release notes instead, like normal people, because this Top Ten Hardcore list for version 14.0 makes all the previous Top Ten lists look like corporate marketing fluff written by a tribble!  What?!? You’re going to continue reading? Well, don’t say I didn’t warn you. I bet you won’t even get past the first two features before you scroll to the end looking for a bad joke. Number 10 [ ASM ] – Name Your Own WAF Cookies In days of yore, just after Al Gore invented the Internet, F5 bought a little application security product called “TrafficShield.” That’s a super cool name for a web application firewall, but eventually the F5 marketing drones standardized on “ASM.” The spirit of TrafficShield lived on in the ASM cookies, which were always named TSCookie. So one could, in theory, fingerprint an F5 web application firewall by looking for the TSCookie. Not that anyone ever did that.  Version 14 lets you create your own cookie naming patterns for the ASM cookie and the Device ID cookie. If you’re worried about fingerprinting, make up your own names (I’m going with NOTanF5Cookie). This feature can also help you conform to in-house cookie conventions. The maximum cookie size is also increased from 8 KB to 16 KB to accommodate user applications which block 8 KB cookies. I know, you’re thinking, who on God’s green earth uses 9K cookies? It’s called cookie bloat and it’s a thing because people are jamming entire web objects into cookies these days. Who designed this internet anyway? Certainly not Spock. Number 9 [FPS] – Single Page Application Support Guys, I have seen the future. The future is the Single Page Application (SPA). Many of the most popular  webpages are SPA now, like Twitter, Facebook, and Gmail. In theory, SPA allows the application developers to focus on UX and not on URL management. But SPA relies heavily on duplex technologies like isomorphic React, Websockets and AJAX. That’s the future. Or the present or whatever. In a Single Page Application, a URL can have multiple views (layouts/content sets), where views change without a full page reload. As you can imagine, the normal tricks that our Fraud Protection Service (FPS) code uses to protect the application need to change. Starting with version 14.0, you can direct the FPS to treat an application as SPA. The DataSafe component of ASM now also supports SPA. SPA views in FPS can be configured in version with Malware Detection, Automatic Transactions Detection, and Application Level Encryption; and an SPA view can be configured as a login page. You can apply application layer integrity to the whole payload between the client and server with minimal performance loss. With application layer encryption, FPS will have to encrypt the whole payload (instead of just fields), but it stills manages to extract the username for enriching the alerts! Obviously you can’t enable Integrity and Encryption at the same time, because encryption already includes integrity, duh! Even McCoy knows that! Did those first two features seem hardcore to you? Well, you’re only half wrong! Those were the teasers. This list is just starting to get hardcore! We showed the next three features to Commander Spock, and his brain exploded.  Speaking of… Here’s a hilarious musical tribute to Spock’s Brain on Spockify. I’ve listened to it like five

In the previous article, The Three HTTP Routing Patterns, Lori MacVittie covers 3 methods of routing. Today we will look at Server Name Indication (SNI) routing as an additional method of routing HTTPS or any protocol that uses TLS and SNI. Using SNI we can route traffic to a destination without having to terminate the SSL connection. This enables several benefits including: Reduced number of Public IPs Simplified configuration More intelligent routing of TLS traffic Terminating SSL Connections When you have a SSL certificate and key you can perform the cryptographic actions required to encrypt traffic using TLS.  This is what I refer to as “terminating the SSL connection” throughout this article.  When you want to route traffic this is a chicken and an egg problem, because for TLS traffic you want to be able to route the traffic by being able to inspect the contents, but this normally requires being able to “terminate the SSL connection”.  The goal of this article is to layer in traffic routing for TLS traffic without having to require having/knowing the original SSL certificate and key. Server Name Indication (SNI) SNI is a TLS extension that makes it possible to "share" certificates on a single IP address. This is possible due to a client using a TLS extension that requests a specific name before the server responds with a SSL certificate. Prior to SNI, the other options would be a wildcard certificate or Subject Alternative Name (SAN) that allows you to specify multiple names with a single certificate. SNI with Virtual Servers It has been possible to use SNI on F5 BIG-IP since TMOS 11.3.0. The following KB13452 outlines how it can be configured. In this scenario (from the KB article) the BIG-IP is terminating the SSL connection.  Not all clients support SNI and you will always need to specify a “fallback” profile that will be used if a SNI name is not used or matched. The next example will look at how to use SNI without terminating the SSL connection. SNI Routing Occasionally you may have the need to have a hybrid configuration of terminating  SSL connections on the BIG-IP and sending connections without terminating SSL.   One method is to create two separate virtual servers, one for SSL connections that the BIG-IP will handle (using clientssl profile) and one that it will not handle SSL (just TCP). This works OK for a small number of backends, but does not scale well if you have many backends (run out of Public IP addresses). Using SNI Routing we can handle everything on a single virtual server / Public IP address. There are 3 methods for performing SNI Routing with BIG-IP iRule with binary scan a. Article by Colin Walker code attribute to Joel Moses b. Code Share by Stanislas Piron iRule with X509::extensions Local Traffic Policy Option #1 is for folks that prefer complete control of the TLS protocol. It only requires the use of a TCP profile. Options #2 and #3 only require the use of a SSL persistence profile and TCP profile. SNI Routing with Local Traffic Policy We will skip option #1 and #2 in this article and look at using a Local Traffic Policy for SNI Routing. For a review of Local Traffic Policies check out the following DevCentral articles: LTM Policy Jan 2015 Simplifying Local Traffic Policies in BIG-IP 12.1 June 2016 In previous articles about Local Traffic Policies the focus was on routing HTTP traffic, but today we will use it to route SSL connections using SNI. In the following example, using a Local Traffic Policy named “sni_routing”, we are setting a condition on the SSL Extension “servername” and sending the traffic to a pool without terminating the SSL connection. The pool member could be another server or another BIG-IP device. The next example will forward the traffic to another virtual server that is configured with a clientssl profile.  This uses VIP targeting to send tra

The "Spectre" and "Meltdown" vulnerabilities affect almost every computer in the world.  One of the very interesting things about each of these vulnerabilities is that they target the hardware (processor) of the computer rather than the software.  Intel is the leading computer processor manufacturer in the world, and most Intel processors are vulnerable to both Spectre and Meltdown.  Other manufacturers' computer processors are vulnerable as well.  These vulnerabilities can allow an attacker to view the entire contents of the memory on a victim's computer.  Because so much sensitive data is stored in memory (passwords, personal information, etc), these attacks can be devestating.  Watch the video below to learn more about Spectre and Meltdown and how they work.   March 21, 2018 UPDATE F5 has released BIG-IP v12.1.3.3 and v13.1.0.4. These versions include fixes for the SPECTRE variant 1 (CVE-2017-5753) and MELTDOWN (CVE-2017-5754) vulnerabilities.  The official documentation of these vulnerabilities and details on fixed versions is available from https://support.f5.com/csp/article/K91229003. Related Resources: An in-depth explanation of Meltdown and Spectre Meltdown Attack Whitepaper Spectre Attack Whitepaper Daniel Miessler Blog on Spectre and Meltdown

In previous articles, we have discussed the use of F5 BIG-IP as a SSL VPN and other use cases for external or inbound access. I now wanted to take some time to discuss an outbound access use case using F5 BIG-IP as an explicit forward web proxy. In laymen terms, this use case allows you to control end user web access with malware prevention, URL and content filtering. This is made possible with a great partnership between F5 and Forcepoint, previously known as Websense. The BIG-IP can also be used as a transparent forward proxy though this will be outside the scope of this article. Below is a diagram and description of each. OK, so now that we've discussed the intent of the article, let's go over the requirements before getting started. The customer requirement is to identify a forward web proxy solution that provides URL filtering, content filtering as well as the ability to export logs and statistics on end user browsing. They also require single sign on using Kerberos authentication. As the integrator, you're wondering how much it would cost to bring in a new vendor and appliances to meet this requirement. Then you remember hearing that F5 is somewhat of a Swiss Army Knife, can they do this? So as many of us do, we go back to our handy dandy search engine and type in web proxy site:f5.com. What do you know, you see BIG-IP APM Secure Web Gateway Overview. After reading the overview you will now identify the requirements to successfully deploy this solution. They include: BIG-IP LTM Licensed APM Licensed SWG Licensed Note: SWG is a subscription based licenses which includes Forcepoint (Websense DB updates) Obtain a signing cert and private key Keytab generated using KTPass Latest SWG iApp from https://downloads.f5.com DNS Configured on BIG-IP to resolve external web addresses Downloading the IP Intelligence database Configure browser with explicit web proxy Now looking at this it seems like it must include much much more than F5 but let's go deeper. Running on the F5 BIG-IP is LTM, APM and SWG. From SWG you will download the IP intelligence database which will be stored on the local BIG-IP and if connected to the internet can download updates on a reoccurring basis. With all of that now covered and you have provided a project timeline and requirements to your local PM, let's get started! We will begin by validating the required modules have been provisioned on the BIG-IP. Navigate to System > Resource Provisioning Validate LTM, APM and Secure Web Gateway are provisioned as you see in the screenshot below. If each of these modules is not provisioned, select the appropriate resources and click Submit. Note: Additional details regarding resource provisioning can be found here https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-essentials-12-1-1/7.html Now that you have provisioned the necessary F5 modules, you must obtain a signing cert and key which you will import into the BIG-IP for use later in the article. For this use case, I used a Windows 2012 box to submit a custom certificate request to my CA. For the sake of time, I am not going to walk through the certificate request process though I will provide one very important detail when performing the certificate request. When submitting the custom request, you must enable basic constraints allowing the subject to issue certificates behalf of the BIG-IP. Import the cert and key into the BIG-IP. Navigate to System > Certificate Management > Traffic Certificate Management > Click SSL Certificate List. Click Import Specify PKCS 12 as the import type. Specify Demo_SWG_CA as the certificate name. Browse to the location that the PFX file was exported to and Import. Provide the password created when exporting cert and key. Click Import Before deploying the SWG iApp, we are going to configure our Active Directory AAA server, create a Keytab file, configure a Kerberos AAA server, create an explicit access policy, custom URL

In this episode of Lightboard Lessons, Jason compares the OSI and TCP/IP Models at a high level. Note that TCP/IP’s bottom two layers are called a lot of different things (ie, Network = Internet, Physical = Network Interface, Network Access, Link, Physical) but I’ve carried network and physical over from OSI to TCP/IP to provide clarity here. Resources Application Delivery Fundamentals (101 Study Guide) OSI Model (Wikipedia) TCP/IP Protocols (The TCP/IP Guide)

Many users and organizations want the flexibility and convenience of identity federation and Single Sign-On (SSO) from the corporate network to intranet, extranet, and cloud applications.  Users want to use their corporate login information to access applications outside of the organization...for example, login from the Microsoft/Windows environment and have seamless access to Office 365 and external applications like Salesforce and Concur.  Microsoft utlilizes a Web Application Proxy (WAP) that acts as a gateway product to allow external users to access internal applications (behind the firewall), like Active Directory Federation Services (AD FS) for example. The F5 BIG-IP can be used to provide high availability, performance, and scalability for both AD FS and AD FS Proxy servers using the Local Traffic Manager (LTM) module.  The same BIG-IP can also be used to secure AD FS traffic without the need for AD FS Proxy servers by using the Access Policy Manager (APM) module.  Check out the video below to learn more! Related Resources: Deploying F5 with Microsoft Active Directory Federation Services Active Directory Federation Services Content Map

Hey All, here is the next document in the series for Integration/Deployment guides for F5 with VMware Products.  This guide had a lot of requests.  I am happy to announce that the next document “Load Balancing VMware Unified Access Gateway” is now available to the public! What is VMware Unified Access Gateway? VMware Unified Access Gateway (UAG), formerly known as VMware Access Point is an appliance that is typically installed in the demilitarized zone (DMZ).  UAG is designed to provide safe and secure access to desktop and application resources for remote access.  UAG simplifies gateway access and provides tunneled and proxied resources for the following VMware product suites. What does this Integration Guide Detail? This documentation focuses on deploying F5 BIG-IP LTM with VMware Unified Access Gateway (UAG) for a production deployment.  When Unified Access Gateway is deployed in a production scenario (n+1) it requires a load balancer sitting in front (for UAG Servers scalability) and behind it (for Connection Server load balancing).  The below picture is an example of the implementation detailed in this guide, we will specifically focus on the load balancer sitting in front (for UAG Server scalability).  In typical deployment scenarios the Load balancer for the connection server would have already been deployed prior to the deployment of the UAG Servers, this path is recommended so that UAG can leverage the Load balancer in front of the connection servers for the UAG's Configuration/Setup. Here is an example from the document that shows how to setup the advanced monitor we use to identify if a single node within the cluster is online or not.  This monitor is an example of how F5 does more than just a simple load balancing monitor.  Most simple load balancers just check for the HTTPS header or ICMP (Ping) responses to identify if a node is online.  F5 worked together with VMware to identify the best way to identify if a node within a cluster is in maintenance mode (Quiesce Mode) or offline due to other issues.  As you can also see we have more than 1 monitor to identify the node is online, if one of either of the monitors fails then the system is taken offline.  Both have to be online for the node to be considered "OK". HTTPS – Second Monitor This monitor is used to identify when the UAG Node is in Quiesce Mode (Maintenance) Create a simple HTTPS monitor using the following guidance. On the Main tab, click Local Traffic > Monitors > Create. In the Name field, type a unique name (different from the first). From the Type list, select HTTPS. Ensure the Parent Monitor is https. In the Interval field, type 30. In the Timeout field, type 91. In the Send String field, type (or copy and paste) GET /favicon.ico HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n In the Receive String field, type 200 in the Receive Disable String field, type 503 Leave all other settings at the default and then click Finished.   You can now download the updated step-by-step guide for Load Balancing VMware Unified Access Gateway at https://www.f5.com/pdf/solution-center/load-balancing-vmware-unified-access-gateway-servers-deployment-guide.pdf Special Thanks to Mark Benson, and the VMware Unified Access Gateway Server development team for all of their assistance putting this together!

F5 has created a specialized ASM template to simplify the configuration process of OWA 2016 with the new version of BIG-IP 13.x Click here to access the .zip file that contains the template:  OWA 2016 ASM Template for BIG-IP v13.x Goal: The template is set to "blocking" from Day One and is tuned to the OWA 2016 environment. Readiness Period: The template is set to "staging" for positive technology elements such file types/urls/parameters and headers, before switching to "blocking". The ASM will advise you to switch to "blocking" from "staging" when the readiness period is over. Note: DataGuard and WebScraping modules are set to "alarm" in order to make sure no false positives are received before switching to "blocking". Important: If the policy is not working properly, please ensure you are using the latest version.  If you have any issues or questions, please send any feedback to my email: [email protected]  

In this episode of Lightboard Lessons, I break out my “router guy” hat from days gone by to deliver an overview of BGP, the border gateway protocol. This exterior gateway routing protocol is “THE” standard for exchanging routing information between autonomous systems. What does this have to do with F5 and BIG-IP? Well, even though the BIG-IP is primarily a platform for application services in the upper layers, it speaks layer three quite well via the ZebOS license. In future episodes I’ll highlight some F5 specific use cases for BGP. Resources Routing Administration (v12.1.1.) Overview of BGP on the BIG-IP system Configuring the BIG-IP system for basic BGP connectivity