Cloud Interconnection with F5 & Equinix

 Learn how the simplified Interconnection Oriented Architecture (IOA) from #F5 and #Equinix helps IT departments solve the need for mobile and dispersed user access to their cloud infrastructure(s) in a multi-cloud environment.

Learn more: https://www.f5.com/services/resources/use-cases/a-secure-equinix-gateway-to-the-cloud

This architecture allows for services to be deployed at the edge of, or next to the cloud resulting in Fewer hops, Dramatically lower latency, Fault-proof security & Lower Network transport costs - as much as 80% lower. This ‘edge’ architecture provides a natural point for traffic control by having centralized policy control and Security policy enforcement, access control and other services like DDoS protection, AAA and WAF.

F5 Cloud Services Early Access Program

F5's Cloud Services Team is excited to share an opportunity for customers test two new technologies! Essential App Protect is an instant, out-of-the-box protection from common web exploits, malicious IPs and coordinated attack types. Bot Protect is a bot management SaaS solution that identifies bots’ intent and prevents attacks, while maintaining access for the good bots that help your business.

Visit: https://www.f5.com/preview to help shape our roadmap and influence feature development!

Bot Management with F5'S Advanced WAF

Automated attacks are a huge threat to organizations. Half of internet traffic are bots and 30% of those are sending malicious payloads. Learn how F5's Adv. WAF helps protect your applications from automated attacks, optimizes your business intelligence and improves performance, availability, and infrastructure costs. Visit f5.com/bots to learn more.

DevCentral's Featured Member for March - Hannes Rapp

Hannes Rapp is an Independent F5 Engineering Consultant focusing on BIG-IP ASM and LTM. According to Hannes, 'if you combine these two modules, you have the best of F5 product portfolio. One without another is incomplete BIG-IP.' He's also interested in Python, building tools to automate routine administrative tasks on BIG-IP and he sends special thanks to REST API developers and F5-sdk project team who make this task easier.

Hannes is a 2018 DevCentral MVP and our Featured Member for March!

DevCentral: First, please explain to the DC community a little about yourself, what you do and why it’s important.

Hannes: A crook from Eastern Europe, as I like to introduce myself. A guy from Estonia with a track record in online gambling industry. Given the background, potential customers are sure to raise an eyebrow. What if he spies for Russia and drinks vodka with his lunch instead of Cola? 

Before my departure from online gambling, I worked as Network and Security Specialist for Playtech. This was the most impactful role for my career progression. There were days we had lots of work to do, and there were days we had insane amounts of work to do. These ever-growing work queues created a situation where some "safe" changes could sneak past Change Management procedures. But what safe is is debatable. So occasionally, some production iRules were modified on the fly without any prior notice. Sometimes customers reported their issues were "magically resolved", and sometimes they reported new issues. I don't know who did those changes. Trust me, I always ask for permissions and not move an inch before the green light. 

Anyone just getting started in IT should seek a busy place. If you want to become good at what you do, it's best to be buried under actual work but not under formalities. If you work at a conservative bank where every minor step must be measured and documented, you will not gain much experience. Banks are good when you're a bit older. They ask you to use a fork and a knife when eating. They help uncivil barbarians evolve into humans by giving lessons in ITIL.

DC: You are a very active contributor in the DevCentral community. What keeps you involved?

HR: My participation here is a learning experience. Most of my F5 knowledge comes from here. In particular, I like how official resources blend together with solutions and ideas from users not employed by F5 Networks. A closed echo chamber with one source of information would not be as interesting. Presence of bug complaints and negative remarks about the product drive the credibility of DevCentral and F5 as a vendor. With the addition of light board lessons, learning has been made even easier. It's always worth coming back here.

DC: Tell us a little about the areas of BIG-IP expertise you have.

HR: Anything but BIG-IP APM, SWG, GCNAT and WebSafe/MobileSafe. No matter what needs to be done, there's probably someone else that already had me do the exact same thing. I'm interested in adding WebSafe/MobileSafe to my portfolio but haven't had the opportunity.

DC: You are an Independent F5 Engineering Consultant focusing on BIG-IP LTM & ASM. Can you describe your typical workday and how you manage work/life balance?

HR: Something that is never missing from my typical workday is an argument with somebody. There's a famous quote that applies: "Arguing with an engineer is a lot like wrestling a pig in the mud. After a couple of hours, you realize the pig likes it." 

When I'm not arguing, I create optimized WAF policies for online banking frontends and mobile apps. Most BIG-IP ASM configurations I have looked at are needlessly cumbersome and feature bulk not relevant for the application. Among other projects, I work on major BIG-IP upgrades. Large corporations with a lot at stake often want BIG-IP upgrades done so that all existing functionality is retained without alterations. Only, and only when the upgrade is deemed successful should any modifications or new features come in effect. Any forceful configuration changes that are applied must either be denied or made redundant with trickery. For example, the event where default values in base profiles are updated to defaults of a new version must be segregated into a separate change. Segregation into bits and pieces helps with damage control. If an incident occurs, all troubleshooting efforts can be focused on a smaller area of surface. 

My last two customers have given me the opportunity to enjoy a better work-life balance. They let me work remotely. Since my area of expertise is so narrow, isolated to F5 BIG-IP, finding projects can be a challenge. Not that long ago I had to travel to another country to be accepted for a project. As far as I'm concerned, work should be about work. If a project is delivered as expected, the place of work is of secondary importance. I appreciate there are corporations who are on the same page in that regard. It's already in the best interest of engineers and consultants to do their job because every new client asks for a recent recommendation.

DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.

HR: The challenge was about converting nearly a hundred BIG-IP ASM policies from Case-Sensitive matching to Case-Insensitive. There's no supported way of changing this once your choice is locked in. After some testing, I found that it's possible to accomplish this by working with raw XML files. There's plenty of room for error but after a few days of scripting and testing, I got a solution I was happy with. From DevCentral, I found information about iControl API and instructions for use. This later proved very helpful for mass policy export and import functions. This was the old SOAP iControl API. Now I'm using iControlREST and would like to give a special mention to F5-sdk project team who work on a fabulous tool that eases automation with Python.

DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

HR: The only job that made sense to me as a kid was to be a basketball player in NBA! As we were walking around our neighborhood in a group of 3, someone always came up with a rhetorical statement: "We need 1 more to play 2v2". And someone always expanded the scope: "or maybe we can find 3 more so we can play 3v3". This was the end of 90s in Estonia. Basketball was immensely more popular than soccer aka football, a dumb ball game. Now it's the other way around.

Thanks Hannes! Check out all of Hannes' DevCentral contributions and connect with him on LinkedIn.
 

If there is a DevCentral member you think should be featured, let us know in the comments section!

DevCentral's Featured Member for March - Hannes Rapp

Hannes Rapp is an Independent F5 Engineering Consultant focusing on BIG-IP ASM and LTM. According to Hannes, 'if you combine these two modules, you have the best of F5 product portfolio. One without another is incomplete BIG-IP.' He's also interested in Python, building tools to automate routine administrative tasks on BIG-IP and he sends special thanks to REST API developers and F5-sdk project team who make this task easier.

Hannes is a 2018 DevCentral MVP and our Featured Member for March!

DevCentral: First, please explain to the DC community a little about yourself, what you do and why it’s important.

Hannes: A crook from Eastern Europe, as I like to introduce myself. A guy from Estonia with a track record in online gambling industry. Given the background, potential customers are sure to raise an eyebrow. What if he spies for Russia and drinks vodka with his lunch instead of Cola? 

Before my departure from online gambling, I worked as Network and Security Specialist for Playtech. This was the most impactful role for my career progression. There were days we had lots of work to do, and there were days we had insane amounts of work to do. These ever-growing work queues created a situation where some "safe" changes could sneak past Change Management procedures. But what safe is is debatable. So occasionally, some production iRules were modified on the fly without any prior notice. Sometimes customers reported their issues were "magically resolved", and sometimes they reported new issues. I don't know who did those changes. Trust me, I always ask for permissions and not move an inch before the green light. 

Anyone just getting started in IT should seek a busy place. If you want to become good at what you do, it's best to be buried under actual work but not under formalities. If you work at a conservative bank where every minor step must be measured and documented, you will not gain much experience. Banks are good when you're a bit older. They ask you to use a fork and a knife when eating. They help uncivil barbarians evolve into humans by giving lessons in ITIL.

DC: You are a very active contributor in the DevCentral community. What keeps you involved?

HR: My participation here is a learning experience. Most of my F5 knowledge comes from here. In particular, I like how official resources blend together with solutions and ideas from users not employed by F5 Networks. A closed echo chamber with one source of information would not be as interesting. Presence of bug complaints and negative remarks about the product drive the credibility of DevCentral and F5 as a vendor. With the addition of light board lessons, learning has been made even easier. It's always worth coming back here.

DC: Tell us a little about the areas of BIG-IP expertise you have.

HR: Anything but BIG-IP APM, SWG, GCNAT and WebSafe/MobileSafe. No matter what needs to be done, there's probably someone else that already had me do the exact same thing. I'm interested in adding WebSafe/MobileSafe to my portfolio but haven't had the opportunity.

DC: You are an Independent F5 Engineering Consultant focusing on BIG-IP LTM & ASM. Can you describe your typical workday and how you manage work/life balance?

HR: Something that is never missing from my typical workday is an argument with somebody. There's a famous quote that applies: "Arguing with an engineer is a lot like wrestling a pig in the mud. After a couple of hours, you realize the pig likes it."
When I'm not arguing, I create optimized WAF policies for online banking frontends and mobile apps. Most BIG-IP ASM configurations I have looked at are needlessly cumbersome and feature bulk not relevant for the application. 

Among other projects, I work on major BIG-IP upgrades. Large corporations with a lot at stake often want BIG-IP upgrades done so that all existing functionality is retained without alterations. Only, and only when the upgrade is deemed successful should any modifications or new features come in effect. Any forceful configuration changes that are applied must either be denied or made redundant with trickery. For example, the event where default values in base profiles are updated to defaults of a new version must be segregated into a separate change. Segregation into bits and pieces helps with damage control. If an incident occurs, all troubleshooting efforts can be focused on a smaller area of surface. 

My last two customers have given me the opportunity to enjoy a better work-life balance. They let me work remotely. Since my area of expertise is so narrow, isolated to F5 BIG-IP, finding projects can be a challenge. Not that long ago I had to travel to another country to be accepted for a project. As far as I'm concerned, work should be about work. 

If a project is delivered as expected, the place of work is of secondary importance. I appreciate there are corporations who are on the same page in that regard. It's already in the best interest of engineers and consultants to do their job because every new client asks for a recent recommendation.

DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.

HR: The challenge was about converting nearly a hundred BIG-IP ASM policies from Case-Sensitive matching to Case-Insensitive. There's no supported way of changing this once your choice is locked in. After some testing, I found that it's possible to accomplish this by working with raw XML files. There's plenty of room for error but after a few days of scripting and testing, I got a solution I was happy with. From DevCentral, I found information about iControl API and instructions for use. This later proved very helpful for mass policy export and import functions. This was the old SOAP iControl API. Now I'm using iControlREST and would like to give a special mention to F5-sdk project team who work on a fabulous tool that eases automation with Python.

DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

HR: The only job that made sense to me as a kid was to be a basketball player in NBA! As we were walking around our neighborhood in a group of 3, someone always came up with a rhetorical statement: "We need 1 more to play 2v2". And someone always expanded the scope: "or maybe we can find 3 more so we can play 3v3". This was the end of 90s in Estonia. Basketball was immensely more popular than soccer aka football, a dumb ball game. Now it's the other way around.

Thanks Hannes! Check out all of Hannes' DevCentral contributions and connect with him on LinkedIn.
 

If there is a DevCentral member you think should be featured, let us know in the comments section!

The OWASP Top 10 - 2017 vs. BIG-IP ASM

With the release of the new 2017 Edition of the OWASP Top 10, we wanted to give a quick rundown of how BIG-IP ASM can mitigate these vulnerabilities.

First, here's how the 2013 edition compares to 2017.

And how BIG-IP ASM mitigates the vulnerabilities.

	Vulnerability	BIG-IP ASM Controls
A1	Injection Flaws	Attack signatures Meta character restrictions Parameter value length restrictions
A2	Broken Authentication and Session Management	Brute Force protection Session tracking HTTP cookie protection
A3	Sensitive Data Exposure	Data Guard
A4	XML External Entities (XXE)	Attack signatures (see below)
A5	Broken Access Control	File types URL URL flows Session tracking URL flows Attack signatures (Directory traversal)
A6	Security Misconfiguration	Attack Signatures
A7	Cross-site Scripting (XSS)	Attack signatures Parameter meta characters Parameter value length restrictions Parameter type definitions (such as integer)
A8	Insecure Deserialization	Attack Signatures (see below)
A9	Using components with known vulnerabilities	Attack Signatures integration
A10	Insufficient Logging and Monitoring	BIG-IP ASM can help with the monitoring process to detect, alarm and deter attacks

Specifically, we have attack signatures for “A4:2017-XML External Entities (XXE)”:

• 200018018           External entity injection attempt

• 200018030           XML External Entity (XXE) injection attempt (Content)

Also, XXE attack could be mitigated by XML profile, by disabling DTDs (and of course enabling the “Malformed XML data” violation):

For “A8:2017-Insecure Deserialization” we have many signatures, which usually include the name “serialization” or “serialized object”, like:

• 200004188           PHP object serialization injection attempt (Parameter)
• 200003425           Java Base64 serialized object - java/lang/Runtime (Parameter)
• 200004282           Node.js Serialized Object Remote Code Execution (Parameter)

A quick run-down thanks to some of our security folks.

ps

Related:

• What’s New In The OWASP Top 10 And How TO Use It
• BIG-IP ASM Operations Guide

Mitigate L7 DDoS with BIG-IP ASM

Today, let’s look at a couple ways to mitigate an application DDoS attack with BIG-IP ASM.

We’ve logged into a BIG-IP ASM and navigated to Security>DDoS Protection>DDoS Profiles. In the General Settings of Application Security, we’ll activate an application DoS iRule event.

We’ll click TPS-based Detection to see the temporarily lowered TPS thresholds to easily simulate an attack. Often, there are multiple mitigation methods that are sequentially applied as you can see with the Source IP settings.

We can also record traffic packet captures during attacks for post analysis.

When the user requests a web application proxied by BIG-IP ASM, ASM will create a unique identifier or a Device ID. ASM will inject JavaScript to register each client device. You can see X-Device-ID: at the bottom.

And JavaScript incapable clients never make it through.

Now that the unit is ready, let’s enable some packet capture and take a go at that damn vulnerable web application.

Path for the log files is /var/log/ or /shared/log/…the PCAP folder is empty so let’s see the action.

Attack commence in 3-2-1. Some quick refreshes should do as our thresholds are low.

The first mitigation is Client Side Integrity Defense. The system issues a client-side integrity challenge that consumes client computation resources and slows down the attack. Next is Built-in Captcha. The third mitigation is Rate Limiting…

..then if they’re still not listening, you can instantly transform into a Honeypot.

The logs below show the IP address and the type of mitigation technique deployed. First Integrity, then Captcha, then Rate Limiting, then Honeypot if they don't stop. The traffic you recorded will be found in the, now populated, PCAP folders.

Thanks to F5 SE Artiom Lichtenstein for the demo video.

ps

Related:

• Lightboard Lessons: What is DDoS?

Deploy an Auto-Scaled BIG-IP VE WAF in AWS

Today let’s look at how to create and deploy an auto-scaled BIG-IP Virtual Edition Web Application Firewall by using a Cloud Formation Template (CFT) in AWS. CFTs are simply a quick way to spin up solutions that otherwise, you may have to create manually. The idea behind this CFT is it is going to create BIG-IP VE instances for you. These instances function as a firewall in front of your application. Depending on the limits you specify, when more traffic is going to your application, new instances will launch…and when there is less traffic, instances will terminate.

This solution has a few prerequisites:

• A Virtual Private Cloud (VPC) with at least two subnets, each in its own availability zone
• An AWS Elastic Load Balancer (ELB), which serves traffic to the BIG-IP VE instances
• An SSH key pair which you need to access the instances.

I have these already created, so we’ll proceed to deploying the template.

You have two choices on how you want to deploy. You can go to the AWS Marketplace and search ‘f5 waf’ or you can go to the F5 Networks GitHub site. GitHub usually has the latest and greatest, so we’ll use that.

Click on the f5-aws-cloudformation spot.

And then click Supported.

And then click solutions/autoscale.

Then waf.

We scroll down a little bit and click Launch Stack.

We click Next at the Select Template screen and fill out the template.

When you get to the template, the Deployment Name will be appended to all the instances so you can tell which ones are yours. Since we already set up a VPC with two subnets in two zones (not regions), we’ll select those in the VPC ID field. The Restricted Source Address is available if you only want to allow specific IP addresses to your BIG-IP VE instances.

Next is the AWS Elastic Load Balancer name, then choose your SSH key – which is needed to connect to the instances. And we’ll leave the defaults for the rest.

Then you’ll get to the Auto Scaling Configuration section which is where you’ll determine when to create the new WAF instances. You’ll want to configure the Scale Up & Scale Down Bytes Threshold which will, obviously, determine when one gets launched/added and when it is removed.

Under WAF Virtual Service Configuration, is where you’ll enter the application’s Service Port and DNS. In addition, if you wanted to automatically add application servers to the pool to have traffic will go to those without having to manually configure the BIG-IP, you can also add the Application Pool Tag Values which works great. Next choose your WAF Policy Level (low, medium, high) and click Next and Next.

Also, click the check box with indicates that you have the appropriate credentials to set some IAM roles and create a S3 Bucket. Click Create and the CFT will start creating resources.

This process can take about 15 minutes to complete and when it is done, you’ll get the CREATE_COMPLETE on your dashboard. The resources might be available now but it is recommended to wait at least 30 minutes before digging into things.

To see what the CFT created and confirm completion, go to: Services>EC2>Auto Scaling Groups. You can see that there is a BIG-IP VE instance created and added to the group. Also, be aware that the default for Scaling Policies is to wait 40 minutes to launch a new instance. You may want to adjust that to your preference. However, to be clear, AWS is always monitoring the traffic and want to know if you are exceeding the limits you’ve set. The Scaling Policies setting simply means that after one instance is launched – you hit the limit and one is up – AWS should wait 40 minutes (or whatever your value is) to launch another. It’ll keep going until you’ve hit the max number of instances specified. We put three.

While in Services>EC2, you can also inspect the ELB and see that the BIG-IP VE instance is there and in service. Traffic is going through the Load Balancer and then to the BIG-IP VE, then to the application server.

Lastly, let’s look at the list of instances in Services>EC2>Instances and the instances are there and ready to go!

And then when there is too much traffic, another is added. Since the limit was exceeded, AWS has launched new instances, up to three.

And when the traffic falls, the instance shuts down.

That’s it! Easily scale your BIG-IP application security on AWS. Thanks to our TechPubs group and watch the video demo here.
ps

Lightboard Lessons: BIG-IP ASM Layered Policies

In this Lightboard Lesson, I light up some use cases for BIG-IP ASM Layered Policies available in BIG-IP v13.

With Parent and Child policies, you can:

• Impose mandatory policy elements on multiple policies;
• Create multiple policies with baseline protection settings; and
• Rapidly push changes to multiple policies.

ps

Lightboard Lessons: Attack Mitigation with F5 Silverline

In this Lightboard Lesson, I describe how F5 Silverline Cloud-based Platform can help mitigate DDoS and other application attacks both on-prem and in the cloud with the Hybrid Signaling iApp. Learn how both on-premises and the cloud can work together to create a composite defense against attacks.



ps

Updating an Auto-Scaled BIG-IP VE WAF in AWS

Update servers while continuing to process application traffic.

Recently we've been showing how to deploy BIG-IP (and F5 WAF) in various clouds like Azure and AWS.

Today, we’ll take a look at how to update an AWS auto-scaled BIG-IP VEweb application firewall (WAF) that was initially created by using this F5 github template. This solution implements auto-scaling of BIG-IP Virtual Edition (VE) Web Application Firewall (WAF) systems in Amazon Web Services. The BIG-IP VEs have the Local Traffic Manager (LTM) and Application Security Manager (ASM) modules enabled to provide advanced traffic management and web application security functionality. As traffic increases or decreases, the number of BIG-IP VE WAF instances automatically increases or decreases accordingly.

Prerequisites:

• BIG-IP VE version 13.0.0
• You created your WAF using the F5 Cloud Formation Template or CFT from Github.

So, let’s assume you used the CFT to create a BIG-IP WAF in front of your application servers…and your business is so successful that you need to be able to process more traffic. You do not need to tear down your deployment and start over – you can make changes to your current deployment while the WAF is still running and protecting your environment.

For this article, a few examples of things you can change include increasing the throughput limit. For instance, When you first configured the WAF, you choose a specific throughput limit for BIG-IP. You can update that. You may also have selected a smaller AWS instance size and now want to choose a larger AWS instance type and add more CPU. Or, you may have set up your auto-scaling group to launch a maximum of two instances and now you want to be able to update the auto-scaling group attributes and add three.

This is all possible so let’s check it out.

The first thing we want to do is connect to one of the BIG-IP VE instances and save the latest configuration. We open putty, login and run the TMSH command (save /sys ucs /var/tmp/original.ucs) to save the UCS config file.

Then we use WinSCP to copy the UCS files to the desktop. You can use whatever application you like and copy the file wherever you like as this is just a temporary location.

Once that’s done, open the AWS Management Console and go to the S3 bucket. This bucket was created when you first deployed the CFT and locate yours.

When you find your file, click it and then click the Backup folder.

Once there, now upload the UCS file into that folder.

The USC is now in the folder.

The last step is to redeploy the CFT and change the selected options. From the main AWS Management Console, click CloudFormation, select your Stack and under Actions, click Update Stack.

Next, you can see the template we originally deployed and to update, click Next.

Scroll down the page to Instance Configuration to change the instance type size.

Right under that is Maximum Throughput to update the throughput limit.

And a little further down under Auto Scaling Configuration is where you can update the max number of instances. When done click Next at the bottom of the page.

It’ll ask you to review and confirm the changes. Click Update.

You can watch the progress and if your current BIG-IP VE instance is actively processing traffic, it will remain active until the new instance is ready.  Give it a little time to ensure the new instance is up and added to the auto scaling group before we terminate the other instance.

When it is done, we’ll confirm a few things.

Go to the EC2 Dashboard and check the running instances. We can see the old instance is terminated and the new instance is now available. You can also check the instance size and within the auto scaling group you can see the new maximum for number of instances.

And we’re deployed.

You can follow this same workflow to update other attributes of your F5 WAF. This allows you to update your servers while continuing to process traffic.

Thanks to our TechPubs group, you can also watch the video demo.

ps

Related:

• Deploy BIG-IP VE in AWS
• Deploy BIG-IP VE in Microsoft Azure Using an ARM Template
• Deploying F5’s Web Application Firewall in Microsoft Azure Security Center

Deploying F5’s Web Application Firewall in Microsoft Azure Security Center

Use F5’s Web Application Firewall (WAF) to protect web applications deployed in Microsoft Azure.

Applications living in the Cloud still need protection. Data breaches, compromised credentials, system vulnerabilities, DDoS attacks and shared resources can all pose a threat to your cloud infrastructure. The Verizon DBIR notes that web application attacks are the most likely vector for a data breach attack. While attacks on web applications account for only 8% of reported incidents, according to Verizon, they are responsible for over 40% of incidents that result in a data breach. A 2015 survey found that 15% of logins for business apps used by organizations had been breached by hackers.

One way to stay safe is using a Web Application Firewall (WAF) for your cloud deployments.

Let’s dig in on how to use F5’s WAF to protect web applications deployed in Microsoft Azure. This solution builds on BIG-IP Application Security Manager (ASM) and BIG-IP Local Traffic Manager (LTM) technologies as a preconfigured virtual service within the Azure Security Center.

Some requirements for this deployment are:

• You have an existing web application deployed in Azure that you want to protect with BIG-IP ASM
• You have an F5 license token for each instance of BIG-IP ASM you want to use

To get started, log into your Azure dashboard and on the left pane, toward the bottom, you’ll see Security Center and click it.

Next, you’ll want to click the Recommendations area within the Security Center Overview.

And from the list of recommendations, click Add a web application firewall.

A list of available web applications opens in a new pane. From the application list, select the application you want to secure.

And from there click Create New. You’ll get a list of available vendors’ WAFs and choose F5 Networks.

A new page with helpful links and information appears and at the bottom of the page, click Create.

First, select the number of machines you want to deploy – in this case we’re deploying two machines for redundancy and high availability. Review the host entry and then type a unique password for that field. When you click Pricing Tier, you can get info about sizing and pricing. When you are satisfied, at the bottom of that pane click OK.

Next, in the License token field, copy and paste your F5 license token. If you are only deploying one machine, you’ll only see one field. For the Security Blocking Level, you can choose Low, Medium or High. You can also click the icon for a brief description of each level. From the Application Type drop down, select the type of application you want to protect and click OK (at the bottom of that pane).

Once you see two check marks, click the Create button.

Azure then begins the process of the F5 WAF for your application. This process can take up to an hour. Click the little bell notification icon for the status of the deployment.

You’ll receive another notification when the deployment is complete.

After the WAF is successfully deployed, you’ll want to test the new F5 WAF and finalize the setup in Azure including changing the DNS records from the current server IP to the IP of the WAF.

When ready, click Security Center again and the Recommendations panel. This time we’ll click Finalize web application firewall setup.

And click your Web application.

Ensure your DNS settings are correct and check the I updated my DNS Settings box and when ready, click Restrict Traffic at the bottom of the pane.

Azure will give you a notification that it is finalizing the WAF configuration and settings, and you will get another notification when complete.

And when it is complete, your application will be secured with F5’s Web Application Firewall.

Check out the demo video and rest easy, my friend.

ps

Related:

• The dirty dozen: 12 cloud security threats
• Why Companies in the Cloud get Hacked
• 15 per cent of business cloud users have been hacked, research finds
• Azure and F5 WAF in the cloud
• Azure Security Center - How to protect your Web Applications in Azure