Archive for security

Lightboard Lessons: What are Bots?

Posted in security, f5, big-ip, silva, basics, devcentral, botnet, risk by psilva on October 18th, 2017

In this Lightboard Lesson, I light up some #basics about internet bots and botnets. Humans account for less than 50% of internet traffic and the rest is spread between the good bots and bad ones.

 

Watch Now:



Legacy Application SSO with BIG-IP and Okta

Posted in security, f5, big-ip, silva, authentication, kerberos, devcentral, saml, access by psilva on October 10th, 2017

IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way.

Today we’ll take you through BIG-IP APM’s integration with Okta, a cloud-based identity-as-a-service provider.

The primary use case for this scenario is providing the user authentication through Okta and then Okta providing BIG-IP APM a SAML assertion so that BIG-IP can perform legacy SSO using either Kerberos Constrained Delegation (KCD) or Header Authentication. BIG-IP is the Service Provider (SP) in this SAML transaction.

As we log on to a BIG-IP, you’ll see that we have two policies/application examples.

ok1.jpg

Let’s click on the Edit button under Access Policy for app1-saml-sp-okta. This takes us to the Visual Policy Editor (VPE) for the first application. As the chart flows, BIG-IP is consuming the SAML authentication, then storing the SSO credentials and doing a Variable Assign so we know who the user is.

ok2.jpg

The next entry, app3-saml-sp-okta, looks very similar.

ok3.jpg

One of the things that is different however is for Header Authentication, we’re using a Per Request Policy. You can view/configure this by going to Access Policy>Per Request Policy.

ok45.jpg

We click Edit (under Access Policy) and here via the flow, the user enters and on every request, we’re going to remove the Okta header name, which is arbitrary and doesn’t need to be that value – could be any value you choose. But we want to make sure that no one is able to pad that header into a request. So, we’ll remove it and insert the variables BIG-IP receives from Okta. This way the application can consume it and we know who that user is.

ok67.jpg

So, what does it look like.

First, we’ll log into Okta and in the portal, we see two applications – the Header Auth and Kerberos Auth.

ok89.jpg

We’ll test the Header authentication first and see that we’re logged into App1 using Header authentication. Tuser@f5demo.com was the account we logged into with Okta and we see the application has been single-signed into using that credential.

ok9a.jpg

Now let’s hit that Kerberos auth application. Here again, we’ve been SSO’d into the application. You may notice that the user looks a bit different here as F5DEMO user since this time we used Kerberos Constrained Delegation. So, we’ve obtained a Kerberos ticket from the domain controller for F5DEMO as the user to use. So the username can look a little different but it’s mainly about formatting.

ok9b.jpg

BIG-IP is able to consume that SAML assertion from Okta and then use SSO capabilities via Header or Kerberos for legacy applications. Watch Cody Green’s excellent demo of this integration.




DevCentral’s Featured Member for October – Jad Tabbara

Posted in security, f5, big-ip, devcentral, featured member by psilva on October 3rd, 2017

Technical Articles | F5 DevCentral

 




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

Posted in security, f5, big-ip, application security, cloud, privacy, waf, aws by psilva on August 29th, 2017

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.

awaf1.jpg

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.

awaf2.jpg

And then click Supported.

awaf3.jpg

And then click solutions/autoscale.

awaf4.jpg

Then waf.

awaf5.jpg

We scroll down a little bit and click Launch Stack.

awaf6.jpg

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

awaf7.jpg

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.

awaf8.jpg

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.

awaf9.jpg

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.

awaf9a.jpg

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.

awaf9b.jpg

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.

awaf9c.jpg

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 right away but it is recommended to wait at least 30 minutes before digging into things.

awaf9d.jpg

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.

awaf9e.jpg

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.

awaf9f.jpg

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

awaf9g.jpg

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

awaf9h.jpg

And when the traffic falls, the instance shuts down.

awaf9i.jpg

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

Posted in security, f5, big-ip, application security, asm, lightboard, devcentral, waf, policy by psilva on August 23rd, 2017

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

Watch Now:



Lightboard Lessons: What is BIG-IP APM?

Posted in security, f5, big-ip, silva, video, lightboard, access, policy by psilva on July 26th, 2017

In this Lightboard, I light up some lessons on BIG-IP Access Policy Manager. BIG-IP APM provides granular access controls to discreet applications and networks supporting 2FA and federated identity management. You can also check out Chase's written article What is BIG-IP APM?

ps

 

Watch Now:



Lightboard Lessons: Attack Mitigation with F5 Silverline

Posted in security, f5, big-ip, application security, cloud, silva, video, lightboard, devcentral by psilva on July 19th, 2017

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

 

 

Watch Now:



DevCentral’s Featured Member for July – Vosko Networking’s Niels van Sluis

Posted in security, f5, big-ip, interview, devcentral by psilva on July 10th, 2017

Niels.jpgFor almost two years Niels van Sluis has worked as a Security Engineer for Vosko Networking. Vosko's security team focuses on supporting security solutions from various vendors like F5, Check Point, Cisco and RSA. Niels focuses is on F5 BIG-IP and Check Point. He started his professional career about 20 years ago in the ISP industry as an Unix Administrator, and switched to the public healthcare sector around 2001. In more recent years, he’s moved more towards working on network security and design. Apparently, having a Unix background helps a lot when working with modern security devices, since most of them are running on some flavor of Unix. When not working or spending time on DevCentral, he likes to travel, visit historic places and enjoy nature. And Niels is DevCentral’s Featured Member for July!

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

Niles: My first encounter with BIG-IP was during my previous job. A colleague had been working with BIG-IP before and introduced it as a replacement for the KEMP load balancer that was currently in use. So, I had to attend the ‘Administering and Configure BIG-IP’ course. It was then – when I learned about iRules – I saw the full potential of this nifty device. But during my days there I didn’t do much with the BIG-IP as in terms to administration. I would only touch the box, if my colleague was on leave. This however changed when I started working for Vosko Networking. Within about a year’s time I’ve gone through the BIG-IP certification program, spend a lot of time on DevCentral and got my hands dirty in the field. The BIG-IP areas I’m most experienced in are LTM and APM. The most fun part for me are iRules (LX).

DC: You are a Security System Engineer at Vosko Networking BV. Can you describe your typical workday?

NS: My typical workday depends whether I’m working on a project or not. When working on projects I often visit customers throughout the country to help them deploy new equipment or configure new services. Recently I’ve migrated quite a few Cisco ACE and Microsoft Forefront TMG deployments to the F5 BIG-IP platform. Other times I help customers upgrading their BIG-IPs or setting up more advanced APM configurations including SAML and SSO. When I’m not working on projects I work on support cases or trying out new stuff in our lab.

DC: You have a number of F5 Certifications including most of the Technology Specialist (LTM, GTM, APM, ASM) certifications. Why are these important to you and how have they helped with your career?

vosko1

NS: First of all, they are required for Vosko Networking to participate in the F5 Support Partner program. But more important to myself is that the F5 certification program helps to get deeper knowledge in to how the various BIG-IP modules work, how they relate (interact) to each other and what part the BIG-IP plays in modern network infrastructures. The certification program is also very practical; you can directly apply what you have been learning. It helped me to get more comfortable and confident in my day to day job.

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

NS: In my experience, there are BIG-IP challenges every day. I think this is the result of the BIG-IP being some kind of network-magic-box, that can do about everything. With most other security devices, one is limited to the functionality and settings the box is shipped with. But with BIG-IP, you can really be creative and think outside the box. If the required functionality is missing, you can build it yourself with iRules. And customers know this. I often go out to customers with a specific need, but when starting out it isn’t always clear if this is something the BIG-IP can do by default. In these situations, access to the DevCentral community is crucial. Even though BIG-IP isn’t an open source project, it’s amazing to see how members share their time, code and knowledge to help each other. For example, some code that really helped me out are Yann Desmarest’s APM Full Step Up Authentication and Stanislas Piron’s APM SharePoint authentication. Besides code, I think the Lightboard Lessons are awesome; very helpful!

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?

I think I wanted to be an electrician when I was young, but I’m pretty sure that isn’t my dream job. As long as I’m able to learn new things and have new challenges, I’m happy how things are. I think I’m useless for any other job that doesn’t require a keyboard. Thanks for the privilege for being a featured member and thanks for the Lightboard Lessons as well. I really enjoy them.

Thanks Niels! Check out all of Niels' DevCentral contributions, connect with him on LinkedIn and follow Vosko@vosko.




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

Posted in security, f5, big-ip, cloud computing, infrastructure, waf, aws by psilva on May 23rd, 2017

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 VEBIG-IP VE web 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:

asw1.jpg

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.

asw2.jpg

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.

asw3.jpg

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.

asw456.jpg

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

asw7.jpg

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

asw89.jpg

The USC is now in the folder.

asw91.jpg

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.

asw9293.jpg

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

asw94.jpg

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

asw95.jpg

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

asw96.jpg

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.

asw97.jpg

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

asw9899.jpg

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.

asw991.jpg

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.

asw99234.jpg

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:

 




Lightboard Lessons: What is BIG-IP?

Posted in security, f5, big-ip, silva, video, application delivery, lightboard, devcentral by psilva on May 10th, 2017

In the early days of F5, BIG/IP was our original load balancer. Today, BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions.

In this Lightboard Lesson, Peter Silva lights up the various BIG-IP modules and what they do.

 

 

Watch Now:




« Older episodes ·