Where are F5's archived deployment guides?
Archived F5 Deployment Guides This article contains an index of F5’s archived deployment guides, previously hosted onF5 | Multi-Cloud Security and Application Delivery.They are all now hosted on cdn.f5.com. Archived guides... are no longer supported and no longer being updated -provided for reference only. may refer to products or versions, by F5 or 3rd parties that are end-of-life (EOL) or end-of-support (EOS). may refer to iApp templates that are deprecated. For current/updated iApps and FAST templates see myF5 K13422: F5-supported and F5-contributed iApp templates Current F5 Deployment Guides Deployment Guides (https://www.f5.com/resources/deployment-guides) IMPORTANT:The guidance found in archived guides is no longer supported by F5, Inc. and is supplied for reference only.For assistance configuring F5 devices with 3 rd party applications we recommend contacting F5 Professional Services here:Request Professional Services | F5 Archived Deployment Guide Index Deployment Guide Name (links to off-platform) Written for… CA Bundle Iapp BIG-IP V11.5+, V12.X, V13 Microsoft Internet Information Services 7.0, 7.5, 8.0, 10 BIG-IP V11.4 - V13: LTM, AAM, AFM Microsoft Exchange Server 2016 BIG-IP V11 - V13: LTM, APM, AFM Microsoft Sharepoint 2016 BIG-IP V11.4 - V13: LTM, APM, ASM, AFM, AAM Microsoft Active Directory Federation Services BIG-IP V11 - V13: LTM, APM SAP Netweaver: Erp Central Component BIG-IP V11.4: LTM, AAM, AFM, ASM SAP Netweaver: Enterprise Portal BIG-IP V11.4: LTM, AAM, AFM, ASM Microsoft Dynamics CRM 2013 And 2011 BIG-IP V11 - V13: LTM, APM, AFM IBM Qradar BIG-IP V11.3: LTM Microsoft Dynamics CRM 2016 and 2015 BIG-IP V11 - V13: LTM, APM, AFM SSL Intercept V1.5 BIG-IP V12.0+: LTM IBM Websphere 7 BIG-IP LTM, WEBACCELERATOR, FIREPASS Microsoft Dynamics CRM 4.0 BIG-IP V9.X: LTM SSL Intercept V1.0 BIG-IP V11.4+, V12.0: LTM, AFM SMTP Servers BIG-IP V11.4, V12.X, V13: LTM, AFM Oracle E-Business Suite 12 BIG-IP V11.4 - V13: LTM, AFM, AAM HTTP Applications BIG-IP V11.4 - V13: LTM, AFM, AAM Amazon Web Services Availability Zones BIG-IP LTM VE: V12.1.0 HF2+, V13 Oracle PeopleSoft Enterprise Applications BIG-IP V11.4+: LTM, AAM, AFM, ASM HTTP Applications: Downloadable IApp: BIG-IP V11.4 - V13: LTM, APM, AFM, ASM Oracle Weblogic 12.1, 10.3 BIG-IP V11.4: LTM, AFM, AAM IBM Lotus Sametime BIG-IP V10: LTM Analytics BIG-IP V11.4 - V14.1: LTM, APM, AAM, ASM, AFM Cacti Open Source Network Monitoring System BIG-IP V10: LTM NIST SP-800-53R4 Compliance BIG-IP: V12 Apache HTTP Server BIG-IP V11, V12: LTM, APM, AFM, AAM Diameter Traffic Management BIG-IP V10: LTM Nagios Open Source Network Monitoring System BIG-IP V10: LTM F5 BIG-IP Apm With IBM, Oracle and Microsoft BIG-IP V10: APM Apache Web Server BIG-IP V9.4.X, V10: LTM, WA DNS Traffic Management BIG-IP V10: LTM Diameter Traffic Management BIG-IP V11.4+, V12: LTM Citrix XenDesktop BIG-IP V10: LTM F5 As A SAML 2.0 Identity Provider For Common SaaS Applications BIG-IP V11.3+, V12.0 Apache Tomcat BIG-IP V10: LTM Citrix Presentation Server BIG-IP V9.X: LTM Npath Routing - Direct Server Return BIG-IP V11.4 - V13: LTM Data Center Firewall BIG-IP V11.6+, V12: AFM, LTM Citrix XenApp Or XenDesktop Iapp V2.3.0 BIG-IP V11, V12: LTM, APM, AFM Citrix XenApp Or XenDesktop BIG-IP V10.2.1: APMDevCentral Resources
DevCentral offers resources that let you get a closer look at F5 products and the code behind them. API Documentation -Here's where you'll find documentation on iRules, iControl, and iApps; advanced design and configuration techniques, and more. Downloads -Get a comprehensive, fully sortable, list of downloads of interest to devs. Developer License -Buy a low-cost Developer License so you can try F5 products in your own development and test environments. Support Self-solve issues with Knowledge Base articles, the iHealth Diagnostic Tool, technical product documentation, and more - all on F5 Support. Knowledge Center Articles Product Documentation iHealth Diagnostic Tool Resources on F5.com F5's corporate site offers everything from the latest deployment guides to training opportunities. Deployment Guides Training and Certification F5 Labs
Making WAF Simple: Introducing the OWASP Compliance Dashboard
Whether you are a beginner or an expert, there is a truth that I want to let you in on; building and maintaining Web Application Firewall (WAF) security policies can be challenging. How much security do you really need? Is your configuration too much or too little? Have you created an operational nightmare? Many well-intentioned administrators will initially enable every available feature, thinking that it is providing additional security to the application, when in truth, it is hindering it. How, you may ask? False positives and noise. The more noise and false positives, the harder it becomes to find the real attacks and the increased likelihood that you begin disabling features that ARE providing essential security for your applications. So… less is better then? That isn't the answer either, what good are our security solutions if they aren't protecting against anything? The key to success and what we will look at further in this article, is implementing best practice controls that are both measurable and manageable for your organization. The OWASP Application Security Top 10 is a well-respected list of the ten most prevalent and dangerous application layer attacks that you almost certainly should protect your applications from. By first focusing your security controls on the items in the OWASP Top 10, you are improving the manageability of your security solution and getting the most "bang for your buck". Now, the challenge is, how do you take such a list and build real security protections for your applications? Introducing the OWASP Compliance Dashboard Protecting your applications against the OWASP Top 10 is not a new thing, in fact, many organizations have been taking this approach for quite some time. The challenge is that most implementations that claim to "protect" against the OWASP Top 10 rely solely on signature-based protections for only a small subset of the list and provide zero insight into your compliance status. The OWASP Compliance Dashboard introduced in version 15.0 on BIG-IP Advanced WAF reinvents this idea by providing a holistic and interactive dashboard that clearly measures your compliancy against the OWASP Application Security Top 10. The Top 10 is then broken down into specific security protections including both positive and negative security controls that can be enabled, disabled, or ignored directly on the dashboard. We realize that a WAF policy alone may not provide complete protection across the OWASP Top 10, this is why the dashboard also includes the ability to review and track the compliancy of best practices outside the scope of a WAF alone, such as whether the application is subject to routine patching or vulnerability scanning. To illustrate this, let’s assume I have created a brand new WAF policy using the Rapid Deployment policy template and accepted all default settings, what compliance score do you think this policy might have? Let's take a look. Interesting. The policy is 0/10 compliant and only A2 Broken Authentication and A3 Sensitive Data Exposure have partial compliance. Why is that? The Rapid Deployment template should include some protections by default, shouldn't it? Expanding A1 Injection, we see a list of protections required in order to be marked as compliant. Hovering over the list of attack signatures, we see that each category of signature is in 'Staging' mode, aha! Signatures in staging mode are not enforced and therefore cannot block traffic. Until the signature set is in enforced, we do not mark that protection as compliant. For those of you who have mistakenly left entities such as Signatures in staging for longer than desired, this is also a GREAT way to quickly find them. I also told you we could also interact with the dashboard to influence the compliancy score, lets demonstrate that. Each item can be enforced DIRECTLY on the dashboard by selecting the "Enforce" checkmark on the right. No need to go into multiple menus, you can enforce all these security settings on a single page and preview the compliance status immediately. If you are happy with your selection, click on "Review & Update" to perform a final review of what the dashboard will be configuring on your behalf before you can click on "Save & Apply Policy". Note: Enforcing signatures before a period of staging may not be a good idea depending on your environment. Staging provides a period to assess signature matches in order to eliminate false positives. Enforcing these signatures too quickly could result in the denying of legitimate traffic. Let's review the compliancy of our policy now with these changes applied. As you can see, A1 Injection is now 100% compliant and other categories have also had their score updated as a result of enforcing these signatures. The reason for this is because there is overlap in the security controls applied acrossthese other categories. Not all security controls can be fully implemented directly via the dashboard, and as mentioned previously, not all security controls are signature-based. A6 Cross-Site Scripting was recalculated as 50% complaint with the signatures we enforced previously so let's take a look at what else it required for full compliancy. The options available to us are to IGNORE the requirement, meaning we will be granted full compliancy for that item without implementing any protection, or we can manually configure the protection referenced. We may want to ignore a protection if it is not applicable to the application or if it is not in scope for your deployment. Be mindful that ignoring an item means you are potentially misrepresenting the score of your policy, be very certain that the protection you are ignoring is in fact not applicable before doing so. I've selected to ignore the requirement for "Disallowed Meta Characters in Parameters" and my policy is now 100% compliance for A7 Cross-Site Scripting (XSS). Lastly, we will look at items within the dashboard that fall outside the scope of WAF protections. Under A9 Using Components with Known Vulnerabilities, we are presented with a series of best practices such as “Application and system hardening”, “Application and system patching” and “Vulnerability scanner integration”. Using the dashboard, you can click on the checkmark to the right for "Requirement fulfilled" to indicate that your organization implements these best practices. By doing so, the OWASP Compliance score updates, providing you with real-time visibility into the compliancy for your application. Conclusion The OWASP Compliance Dashboard on BIG-IP Advanced WAF is a perfect fit for the security administrator looking to fine-tune and measure either existing or new WAF policies against the OWASP App Security Top 10. The OWASP Compliance Dashboard not only tracks WAF-specific security protections but also includes general best practices, allowing you to use the dashboard as your one-stop-shop to measure the compliancy for ALL your applications. For many applications, protection against the OWASP Top 10 may be enough, as it provides you with best practices to follow without having to worry about which features to implement and where. Note: Keep in mind that some applications may require additional controls beyond the protections included in the OWASP Top 10 list. For teams heavily embracing automation and CI/CD pipelines, logging into a GUI to perform changes likely does not sound appealing. In that case, I suggest reading more about our Declarative Advanced WAF policy framework which can be used to represent the WAF policies in any CI/CD pipeline. Combine this with the OWASP Compliance Dashboard for an at-a-glance assessment of your policy and you have the best of both worlds. If you're not already using the OWASP Compliance Dashboard, what are you waiting for? Look out for Bill Brazill, Victor Granic and myself (Kyle McKay) on June 10th at F5 Agility 2020 where we will be presenting and facilitating a class called "Protecting against the OWASP Top 10". In this class, we will be showcasing the OWASP Compliance Dashboard on BIG-IP Advanced WAF further and providing ample hands-on time fine-tuning and measuring WAF policies for OWASP Compliance. Hope to see you there! To learn more, visit the links below. Links OWASP Compliance Dashboard: https://support.f5.com/csp/article/K52596282 OWASP Application Security Top 10: https://owasp.org/www-project-top-ten/ Agility 2020: https://www.f5.com/agility/attendWhat is BIG-IP Next?
BIG-IP Next LTM and BIG-IP Next WAF hit general availability back in October, and we hit the road for a tour around North America for its arrival party! Those who attended one of our F5 Academy sessions got a deep-dive presentation into BIG-IP Next conceptually, and then a lab session to work through migrating workloads and deploying them. I got to attend four of the events and discuss with so many fantastic community members what's old, what's new, what's borrowed, what's blue...no wait--this is no wedding! But for those of us who've been around the block with BIG-IP for a while, if not married to the tech, we definitely have a relationship with it, for better and worse, right? And that's earned. So any time something new, or in our case "Next" comes around, there's risk and fear involved personally. But don't fret. Seriously. It's going to be different in a lot of ways, but it's going to be great. And there are a crap-ton (thank you Mark Rober!) of improvements that once we all make it through the early stages, we'll embrace and wonder why we were even scared in the first place. So with all that said, will you come on the journey with me? In this first of many articles to come from me this year, I'll cover the high-level basics of what is so next about BIG-IP Next, and in future entries we'll be digging into the tech and learning together. BIG-IP and BIG-IP Next Conceptually - A Comparison BIG-IP has been around since before the turn of the century (which is almost old enough to rent a car here in the United States) and this year marks the 20 year anniversary of TMOS. That the traffic management microkernel (TMM) is still grokking like a boss all these years later is a testament to that early innovation! So whereas TMOS as a system is winding down, it's heart, TMM, will go on (cue sappy Celine Dion ditty in 3, 2, 1...) Let's take a look at what was and what is. With TMOS, the data plane and control plane compete for resources as it's one big system. With BIG-IP, the separation of duties is more explicit and intentionally designed to scale on the control plane. Also, the product modules are no longer either completely integrated in TMM or plugins to TMM, but rather, isolated to their own container structures. The image above might convey the idea that LTM or WAF or any of the other modules are single containers, but that's just shown that way for brevity. Each module is an array of containers. But don't let that scare you. The underlying kubernetes architecture is an abstraction that you may--but certainly are not required to--care about. TMM continues to be its awesome TMM self. The significant change operationally is how you interact with BIG-IP. With TMOS, historically you engage directly with each device, even if you have some other tools like BIG-IQ or third-party administration/automation platforms. With BIG-IP Next, everything is centralized on Central Manager, and the BIG-IP Next instances, whether they are running on rSeries, VELOS, or Virtual Edition, are just destinations for your workloads. In fact, outside of sidecar proxies for troubleshooting, instance logins won't even be supported! Yes, this is a paradigm shift. With BIG-IP Next, you will no longer be configuration-object focused. You will be application-focused. You'll still have the nerd-knobs to tweak and turn, but they'll be done within the context of an application declaration. If you haven't started your automation journey yet, you might not be familiar with AS3. It's been out now for years and works with BIG-IP to deploy applications declaratively. Instead of following a long pre-flight checklist with 87 steps to go from nothing to a working application, you simply define the parameters of your application in a blob of JSON data and click the easy button. For BIG-IP Next, this is the way. Now, in the Central Manager GUI, you might interact with FAST templates that deliver a more traditional view into configuring applications, but the underlying configuration engine is all AS3. For more, I hosted aseries of streams in December to introduce AS3 Foundations, I highly recommend you take the time to digest the basics. Benefits I'm Excited About There are many and you can read about them on the product page on F5.com. But here's my short list: API-first. Period. BIG-IP had APIs with iControl from the era before APIs were even cool, but they were not first-class citizens. The resulting performance at scale requires effort to manage effectively. Not only performance, but feature parity among iControl REST, iControl SOAP, tmsh, and the GUI has been a challenge because of the way development occurred over time. Not so with BIG-IP Next. Everything is API-first, so all tooling is able to consume everything. This is huge! Migration assistance. Central Manager has the JOURNEYS tool on sterroids built-in to the experience. Upload your UCS, evaluate your applications to see what can be migrated without updates, and deploy! It really is that easy. Sure, there's work to be done for applications that aren't fully compatible yet, but it's a great start. You can do this piece (and I recommend that you do) before you even think about deploying a single instance just to learn what work you have ahead of you and what solutions you might need to adapt to be ready. Simplified patch/upgrade process. If you know, you know...patches are upgrades with BIG-IP, and not in place at that. This is drastically improved with BIG-IP Next! Because of the containerized nature of the system, individual containers can be targeted for patching, and depending on the container, may not even require a downtime consideration. Release cycle. A more frequent release cadence might terrify the customers among us that like to space out their upgrades to once every three years or so, but for the rest of us, feature delivery to the tune of weeks instead of twice per year is an exciting development (pun intended!) Features I'm Excited About Versioning for iRules and policies. For those of us who write/manage these things, this is huge! Typically I'd version by including it in the title, and I know some who set release tags in repos. With Central Manager, it's built-in and you can deploy iRules and polices by version and do diffs in place. I'm super excited about this! Did I mention the API? On the API front...it's one API, for all functionality. No digging and scraping through the GUI, tmsh, iControl REST, iControl SOAP, building out a node.js app to deploy a custom API endpoint with iControl LX, if even possible with some of the modules like APM or ASM. Nope, it's all there in one API. Glorious. Centralized dashboards. This one is for the Ops teams! Who among us has spent many a day building custom dashboards to consume stats from BIG-IPs across your org to have a single pane of glass to manage? I for one, and I'm thrilled to see system, application, and security data centralized for analysis and alerting. Log/metric streaming. And finally, logs and metrics! Telemetry Streaming from the F5 Automation Toolchain doesn't come forward in BIG-IP Next, but the ideas behind it do. If you need your data elsewhere from Central Manager, you can set up remote logging with OpenTelemetry (see the link in the resources listed below for a first published example of this.) There are some great features coming with DNS, Access, and all the other modules when they are released as well. I'll cover those when they hit general availability. Let's Go! In the coming weeks, I'll be releasing articles on installation and licensing walk-throughs for Central Manager and the instances, andcontent from our awesome group of authors is already starting to flow as well. Here are a few entries you can feast your eyes on, including an instance Proxmox installation: For the kubernetes crowd, BIG-IP Next CNF Solutions for RedHat Openshift Installing BIG-IP Next Instance on Proxmox Remote Logging with BIG-IP Next and OpenTelemetry Are you ready? Grab a trial licensefrom your MyF5 dashboard and get going! And make sure to join us in the BIG-IP Next Academy group here on DevCentral. The launch team is actively engaged there for next-related questions/issues, so that's the place to be in your early journey! Also...if you want the ultimate jump-start for all things BIG-IP Next, join usatAppWorld 2024 in SanJose next month!Cloud Docs - Use Case Guide to Service Proxy (SPK) for Kubernetes
Introduction Guides for Engineers by Engineers As F5 internal engineers, we work with the technologies and complexities created by the interconnected requirements and configurations of our customers deployments. In doing so, we gain knowledge and insight into the eco systems that F5 products live in and learn from the people that support them. Using GIT and Markdown As F5 has advanced we’ve realized that the previousF5 Network Operations guides were no longer capable of keeping up with the changes to modern network infrastructure and complex configurations deployed by its users. In response, the F5 engineering teams have begun to utilize GIT and Markdown to enable the F5 community of subject matter experts in all roles to contribute and collaborate. Because of this shift, we able to grow the F5 Cloud Docs portal with engineer focused content like the new SPK Use Cases below. SPKUse Cases TheService Proxy for Kubernetes (SPK) Use Case guidegoes into detail how the OpenShift Cluster networks are connected and explains how to validate the environment to prepare for the SPK Installation while walking you through common use cases utilizing the following 5 Pods: Controller Service Proxy dSSM CWC Telemetry For further information about SPK and the use cases documented check the links below: Service Proxy for Kubernetes (SPK) Install Creating TCP Ingress for an application Routing diameter traffic to pods using SPK Enabling BGP for SPK with fault tolerance using BFD Enabling Egress Traffic Using SNAT Managing Egress Traffic Using Static Route SPK Egress Between Single Stack IPv4 and Single Stack IPv6 Services Configuring Multiple Watch Namespace SPK Licensing Macvlan Network Configuration Manage HTTP/2 Traffic for 5G Applications Conclusion: We’re driven to keep up to date information at everyone fingertips. The new GIT and Markdown powered documentation will be one of the many tools utilized to keep you informed and operational.Revolutionize F5 BIG-IP Deployment Automation with HashiCorp’s No-Code Ready Terraform Modules
Introduction In organizations today, application infrastructure deployment involves teams such as platform teams, Ops teams, and dev teams all working together to ensure consistency and compliance. This is no easy task as because of siloed teams and expertise and deploying application infrastructure is time-consuming. Platform teams typically address this challenge with automation and by enabling their ops team and developers with self-service infrastructure – which abstracts most steps of deployment. HashiCorp Terraform No-Code Provisioning enables self-service of BIG-IP infrastructure as it allows the platform teams tocreate and maintain a library of pre-built Terraform modules that can be used by ops teams and developers to deploy multi-cloud BIG-IP infrastructure and services for their applications. This help to ensure consistency and reduce the amount of time organizations need to set up and configure infrastructure. Taking this one step further, the Terraform no-code modules enable infrastructure teams to streamline automation by combining CI/CD pipelines, any custom scripts, and other automation tools in the deployment chain allowing developers and operations teams to deploy F5 application services and infrastructure anywhere with a few clicks from the Terraform Cloud GUI – all while maintaining compliance. What is No-Code? No-code provisioning in Terraform Cloud lets users deploy infrastructure resources without writing Terraform configuration. This lets organizations provide a self-service model to developers with limited infrastructure knowledge and a way to deploy the resources they need. It allows individuals with limited Terraform coding experience or knowledge to provision infrastructure with Terraform. It can accelerate the development process by eliminating the need for coding and testing. It can reduce the reliance on scarce technical resources or expertise. It can improve the flexibility and agility of BIG-IP deployment. How to set up Terraform Cloud for BIG-IP No-Code Module? You need the following: Terraform Cloud account AWS account Terraform Cloud variables set configured with your AWS credentials Fork the example GitHub repository https://github.com/f5businessdevelopment/terraform-aws-bigip-nocode Then, clone your forked repository. Replacing USER with your username. Git clone https://github.com/USER/terraform-aws-bigip-nocode-1 Navigate to the repository directory. Navigate to terraform-aws-bigip-nocode1 directory Make sure you have variables defined as shown below variable "prefix" { description = "provide some prefix for deployment" } variable "region" { description = "AWS region you can define example is us-west-2 " } variable "allow_from" { description = "IP Address/Network to allow traffic from your machine (i.e. 192.0.2.11/32)" } These variable definitions facilitate the exposure of parameters while deploying the BIG-IP instance, you can add/delete any new parameters you need to expose. How to Publish No-code ready module? First, create a tag for your module. Tags are required to create a release on the GitHub repository, Terraform Cloud will use this tag to register the module. git tag 1.0.0 git push –tags Once your release is ready on the Github repository Navigate to Terraform Cloud at https://app.terraform.iohttps://terraform.io Click Registry 🡪 Publish 🡪 Module On the Add Module option select GitHub in Connect to VCS option Browse through your repository and select the repository as shown below. Confirm the selection as shown below Click on Add Module to no-code provision allow list and then hit Publish as shown below. Confirm the selection as shown below Click on Add Module to no-code provision allow list and then hit Publish as shown below. It will take a couple of seconds to Publish the module, once done you will see the screen below as shown. Now you are ready to use the module, to deploy the BIG-IP instance you click on the Provision workspace tab. How to use the BIG-IP No-Code Terraform Module? Once we have the No-Code module published on Terraform Cloud we are ready to use it. Login to Terraform Cloud at https://app.terraform.io and choose an organization Click on Registry🡪 Module (bigip-1nic-nocode) as shown Click on the Provision workspace button as shown below. Workspaces in Terraform Cloud separate infrastructure configurations to help provide a multi-tenant environment. Provide the 3 parameters below as shown, you can give any name as a prefix, this helps in further providing more multi-tenancy if multiple people are provisioning. Provide workspace name, you can give any name. And finally hit the “Create Workspace” button to deploy the BIG-IP instance. BIG-IP instance will be ready with the Management IP address and password for you. Conclusion: Finally, the Infrastructure team can help to ensure the security and compliance of the infrastructure deployed using the Terraform No-Code Provisioning by implementing security best practices controls and monitoring. Reference Video
Agility 2020 - you're invited!
In-person event for Agility 2020 has been cancelled. Please see the Agility Event Page for more details. (Update 2/28/2020) In an abundance of caution for our customers, partners and employees, we have made the tough decision to cancel our in-person event for Agility 2020 due to the escalating travel and safety concerns related to the global COVID-19 (Coronavirus) outbreak. While we are disappointed to miss sharing ideas and solving problems with customers and partners from around the globe in person, we believe this is the best decision for everyone's welfare. We are rapidly developing an alternative to Agility as a virtual experience in the near term to deliver valuable Lab, Break-out Session, Certification and Keynote content to our customers and partners. Check back regularly for more details on the virtual event or email F5Agility@F5.com for additional information. <Professor Farnsworth imitation>Good news, everybody!</Professor Farnsworth imitation> As you know, there was no Agility 2019. This was in part so that we could reset the time of year for the conference from August to March. Agility 2020will be held from March 16-19, 2020 at theSwan & Dolphinin Orlando, Florida. Orlando, and Disney, and putt-putt golfing... That's right, *puts on ears* we're going to Disneyworld - and you are all cordially invited to participate in labs and breakouts, meet fellow F5 users, talk with F5 and partner subject-matter experts, learn to develop and deploy applications in days instead of months, secure your apps at scale in a multi-cloud environment, and hear about our vision for the future of F5 and NGINX. Registration is now open! The DevCentral team will be busy as usual that week. We areallflying over, and will be: hosting our usual booth and giving out swag in the expo hall, hosting a walk-in Nerdery zone next to our booth, where folks can drop in to speak with one of our subject-matter experts, presenting breakout sessions, hanging out at Geekfest, connecting community, enjoying the exclusive community area at the final night party, and of course, spoiling the dev/central MVPs during the joint 2019-20 MVP Summit at Agility with special sessions and activities. If you'd like to do more than pick up all the knowledge being dropped, if you have some cool technical stories or lessons-learned to share, please stay tuned for the open call for proposals which should go live in early December - so please start getting those great breakout, lightening round, and open talk ideas ready. Hope to see you there!Action Items in OMB Memorandum M-22-09 “Moving the U.S. Government Toward Zero Trust...”
Purpose On January 26, 2022, OMB issued Memorandum M-22-09 for “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” listing a series of action items. This blog is to provide an overview of F5 capabilities and where they fit within those action items. Milestone Dates January 26, 2022 Issuance of M-22-09 “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” February 25, 2022 Agencies to designate and identify a zero trust strategy implementation lead for their organization March 27, 2022 Submit to OMB and CISA an implementation plan for FY22-FY24 May 27, 2022 Chief Data Officers to develop a set of initial categorizations for sensitive electronic documents within their enterprise January 26, 2023 Public-facing agency systems that support MFA must give users the option of using phishing-resistant authentication January 26, 2023 Each agency must select at least one FISMA Moderate system that requires authentication and make it Internet accessible August 27, 2022 Agencies must reach the first event logging maturity level (EL-1) as described in Memorandum M-21-31 End of FY2024 Agencies to achieve specific zero trust security goals Requirements to F5 Capability Mapping Page Requirements F5 Capabilities F5 Products 6 Section A.1 “Enterprise identity management must be compatible with common applications and platforms. As a general matter, users should be able to sign in once and then directly access other applications and platforms within their agency’s IT infrastructure. Beyond compatibility with common applications, an agency identity management program should facilitate integration among agencies and with externally operated cloud services; the use of modern, open standards often promotes such integration.” Proxies and transforms client side authentication method to adapt to application’s native authentication method. Modern authentication can now be applied to legacy web application without any changes. BIG-IP APM NGINX 7 Section A.2 Agencies must integrate and enforce MFA across applications involving authenticated access to Federal systems by agency staff, contractors, and partners. MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 7 Section A.2 MFA should be integrated at the application layer MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 7 Section A.2 guessing weak passwords or reusing passwords obtained from a data breach Finds compromised credentials in real-time, identifies botnets, and blocks simulation software. F5 Distributed Cloud Services 7 Section A.2 many approaches to multi-factor authentication will not protect against sophisticated phishing attacks, which can convincingly spoof official applications and involve dynamic interaction with users. Users can be fooled into providing a one-time code or responding to a security prompt that grants the attacker account access. These attacks can be fully automated and operate cheaply at significant scale. Finds compromised credentials in real-time, identifies botnets, and blocks simulation software. F5 Distributed Cloud Services 9 Section A.3 every request for access should be evaluated to determine whether it is appropriate, which requires the ability to continuously evaluate any active session After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. A per-request policy must provide the logic for determining how to process web-bound traffic. It must determine whether to allow or reject a URL request and control whether or not to bypass SSL traffic. BIG-IP APM NGINX 10 Section A.3 Agency authorization systems should work to incorporate at least one device-level signal alongside identity information about the authenticated user when regulating access to enterprise resources High-efficacy digital fingerprinting identifies returning web client patterns from new edge devices. F5 Distributed Cloud Services 12 Section C.1 Agencies should make heavy internal use of recent versions of standard encryption protocols, such as TLS 1.3 Regardless of your TLS version, you need to have visibility into encrypted threats to protect your business. SSL/TLS based-decryption devices that allow for packet inspection can intercept encrypted traffic, decrypt, inspect, and re-encrypt untrusted TLS traffic entering or leaving the network. BIG-IP LTM BIG-IP SSLO NGINX 13 Section C.1 agencies should plan for cryptographic agility in their network architectures, in anticipation of continuing to adopt newer versions of TLS Organizations don’t want to reconfigure hundreds of servers just to offer these new protocols. This is where transformational services become cipher agility. Cipher agility is the ability of an SSL device to offer multiple cryptographic protocols such as ECC, RSA2048, and DSA at the same time—even on the same virtual server. BIG-IP SSLO 13 Section C.2 agency DNS resolvers must support standard encrypted DNS protocols (DNS-over-HTTPS or DNS-over-TLS) NOTE: DNSSEC does not encrypt DNS data in transit. DNSSEC can be used to verify the integrity of a resolved DNS query, but does not provide confidentiality. DoH proxy—A passthrough proxy that proxies the client’s DoH request to a backend DoH server and the backend DoH server’s response back to the DoH client. DoH server—The server translates the client’s DoH request into a standard DNS request and forwards the DNS request using TCP or User Datagram Protocol (UDP) to the configured DNS server, such as the BIG-IP named process and the BIG-IP DNS cache feature. When the BIG-IP system receives a response from the configured DNS server, it translates the DNS response into a DoH response before sending it to the DoH client. BIG-IP DNS 14 Section C.3 Zero trust architectures—and this strategy— require agencies to encrypt all HTTP traffic, including within their environments. Handle SSL traffic in load balancing scenario and meet most of the security requirements effectively. The 3 common SSL configurations that can be set up on LTM device are: -SSL Offloading -SSL Passthrough -Full SSL Proxy / SSL Re-Encryption / SSL Bridging / SSL Terminations BIG-IP LTM BIG-IP SSLO NGINX 18 Section D.4 Making applications internet-accessible in a safe manner, without relying on a virtual private network (VPN) or other network tunnel Proxy-based access controls deliver a zero-trust platform for internal and external application access. That means applications are protected while extending trusted access to users, devices, and APIs. BIG-IP LTM BIG-IP APM 18 Section D.4 require agencies to put in place minimum viable monitoring infrastructure, denial of service protections, and an enforced access-control policy Integrate with SIEM for agency wide monitoring or use F5 management platform for greater visibility. On-prem DDOS works in conjunction with cloud service to protect from various attack strategies. BIG-IQ BIG-IP AFM BIG-IP ASM F5 Distributed Cloud DDOS 19 Section D.6 Automated, immutable deployments support agency zero trust goals Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds. BIG-IP NGINX 20 Section D.6 Agencies should work toward employing immutable workloads when deploying services, Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds. BIG-IP NGINX 24 Section F.1 Agencies are undergoing a transition to IPv6, as described in OMB Memorandum M-21- 07, while at the same time migrating to a zero trust architecture The BIG-IP device is situated between the clients and the servers to provide the applications the clients use. In this position—the strategic point of control—the BIG-IP device provides virtualization and high availability for all application services, making several physical servers look like a single entity behind the BIG-IP device. This virtualization capability provides an opportunity to start migrating either clients or servers—or both simultaneously—to IPv6 networks without having to change clients, application services, and both sides of the network all at once. BIG-IP LTM NGINX 24 Section F.2 OMB Memorandum M-19-1735 requires agencies to use PIV credentials as the “primary” means of authentication used for Federal information systems PIV authentication can be applied to any applications, whether legacy or modern, without changes. BIG-IP APM 25 Section F.3 Current OMB policies neither require nor prohibit inline decryption of enterprise network traffic SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments. BIG-IP SSLO 25 Section F.4 This memorandum expands the scope of M-15-13 to encompass these internal connections. NOTE: M-15-13 specifically exempts internal connections, stating, “[T]he use of HTTPS is encouraged on intranets, but not explicitly required.” SSL Orchestrator delivers dynamic service chaining and policy-based traffic steering, applying context-based intelligence to encrypted traffic handling to allow you to intelligently manage the flow of encrypted traffic across your entire security stack, ensuring optimal availability. BIG-IP LTM BIG-IP SSLO NGINX Your F5 Account Team Can Help Every US Federal agency has a dedicated F5 account team to support the mission. They are ready to discuss F5 capabilities and help provide further information for your Zero Trust implementation plan. Please contact your F5 account team directly or use this contact form.Shape Security and Volterra moving to F5 Distributed Cloud Services
Overview Product Name Changes So what does this mean for you? Overview In the last few years, F5 acquired Shape Security, Volterra,NGINX and Threat Stack--broadening the F5 portfolio of products. To simply our growing portfolio, products from Shape Security and Volterra will now converge under a new F5 Distributed Cloud Services brand. From now on there will be three primary F5 product brands: BIG-IP, NGINX, and Distributed Cloud Services. For more information on these changes, please see theF5 Brand Updates page. Product Name Changes The chart below outlines each product's historical name and its corresponding F5 Distributed Cloud Services name: Historical Product Name New Product Name VoltMesh F5 Distributed Cloud Mesh VoltStack F5 Distributed Cloud App Stack VoltConsole F5 Distributed Cloud Console Shape Recognize F5 Distributed Cloud Authentication Intelligence Shape AI Fraud Engine (SAFE) F5 Distributed Cloud Account Protection Shape Client-Side Defense F5 Distributed Cloud Client-Side Defense Shape Aggregator Defense F5 Distributed Cloud Aggregator Management Shape Integrated Bot Defense F5 Distributed Cloud Bot Defense Shape Enterprise Defense So what does this mean for you? Your experiences with these F5 products should remain largely unchanged. That being said, here's a few minor changes that may affect you: In-product experiences, DevCentral posts, and other F5 materials will reflect the new names. Specific website domains will no longer exist.Volterra.io will redirect to cloud.f5.com, where users can login on the Distrubuted Cloud Services page. Interactions with the respective products, assigned tenant name spaces/URLs, and who you work with for support and customer service will not be impacted. Product documentation for F5 Distributed Cloud Protection Manager and Distributed Cloud Console will also move. You can see the new locations here: Historical Product Name New Product Name Product Documentation Location Shape Protection Manager F5® Distributed Cloud Protection Manager The F5® Distributed Cloud Protection Manager user interface contains a “Documentation” link to relevant product documentation. VoltConsole F5® Distributed Cloud Console The F5® Distributed Cloud Console user interface will include links to relevant product documentation. In addition, product documentation can be found at https://docs.cloud.f5.com Questions about this rebranding should be directed to F5 via the respective email addresses for your region (which can be found atContact F5.)
