Tuesday, May 23, 2017

Device Discovery on BIG-IQ 5.1

The first step in using a BIG-IQ to manage BIG-IP devices

BIG-IQ enables administrators to centrally manage BIG-IP infrastructure across the IT landscape. BIG-IQ discovers, tracks, manages, and monitors physical and virtual BIG-IP devices - in the cloud, on premise, or co-located at your preferred datacenter.

Let’s look at how to get BIG-IQ 5.1 to gather the information needed to start managing a BIG-IP device. This gathering process is called Device Discovery.

To get started, the first thing is to logon to the BIG-IQ

Once in, the first thing you do is let the BIG-IQ know about the BIG-IP device that you want to manage. Here, in Device Management>Inventory>BIG-IP Devices, we’ll click Add Device.

Here we’ll need the IP address, user name and password of the device you want to manage. If the device you want to manage is part of a BIG-IP Device Service Cluster (DSC), you’ll probably want to manage that part of its configuration by adding it to a DSC group on the BIG-IQ. After selecting a DSC, tell the BIG-IQ how to handle synchronization when you deploy configuration changes so that when you deploy changes to one device, the other DSC members get the same changes. Best practice is to let BIG-IQ do the sync.

Next click Add at the bottom of the page to start the discovery process.

Once the device recognizes your credentials, it’ll prompt you to choose the services that you want to manage. You always select LTM, even if you only mange other services because the other services depend on LTM. To finish the device discovery task, click Discover.

The BIG-IQ gathers the information it needs for each of the services you requested. This first step takes only a few moments while the BIG-IQ discovers your devices. You are done with discovery once the status update reads, Complete import tasks.

Now, we need to import the service configurations that the BIG-IQ needs before we can start managing that BIG-IP device. Click the link that says, Complete import tasks.

Next, you’ll begin the process of importing the BIG-IP LTM services for this device. Just like the discovery task, you’ll import LTM first.

Click Import.

This could take a little time depending on how many LTM objects are defined on this BIG-IP device. When the import finishes, BIG-IQ will display the date and time of when the operation was completed.

Now, we repeat the process for the second service provisioned on this device.

Importing an access device like BIG-IP APM is slightly different. Part of the import task is to identify the Access Group that this device uses to share its configuration. Whether you’re adding to an existing or creating a new access group, when you’re done entering the name of the group, click Add to start the import process. Here again, the time to process depends on how many BIG-IP APM configuration objects are defined on the device.

When the BIG-IP APM services import finishes and the time completed displays, you can simply click Close to complete the task.

You can now see that the device has been added to BIG-IQ.

That’s it! Now you can start managing the BIG-IP LTM and APM object on this device. For this article, we only imported LTM and APM objects but the process is the same for all services you manage.

Thanks to our TechPubs group and watch the video demo here.

ps

Related:

Tuesday, May 16, 2017

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:


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:

Wednesday, May 10, 2017

Lightboard Lessons: What is BIG-IP?

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, I light up the various BIG-IP modules and what they do.



ps

Related:

Tuesday, May 9, 2017

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:

Tuesday, May 2, 2017

DevCentral’s Featured Member for May – NTT Security’s Leonardo Souza

Leonardo Souza lives in the United Kingdom, with his partner, 5-year-old daughter, and a (very) recently newborn son. He’s Brazilian and lived in Portugal for quite a while. He then moved to UK about 5 years ago ‘because of the amazing weather,’ he jokes.

Leonardo started to work with computers when he was 18 years old (he’s not 18 anymore), so he’s worked with many technologies. Fast forward a bit (he’s not that old) and while working as a network engineer, he was working on a project to migrate applications from Alteon load balancers to F5 BIG-IP LTMs. He completed his LTM Essentials and LTM Advanced training during that time (2011) and with the migration project, he was impressed with BIG-IP.

He even applied for a job at F5 in 2012 and joined as a Network Support Engineer. That moved him from Portugal to UK, and has been doing F5 products exclusively ever since.

With all that, Leonardo is DevCentral’s Featured Member for May and we got a chance to talk with Leonardo about his life, work and scripting prowess.

DevCentral: You were an F5er from 2012-15 and continue to be a very active contributor in the DevCentral community. What keeps you involved?
Leonardo: I often say that 1 year in F5 support is equal to 5 years as a F5 customer.
While in F5 support, I had multiple technical challenges every day, and I would typically go to DevCentral to check iRules documentation and get ideas for uncommon cases. After I left F5, I started using DevCentral to stay up to date about what is going on in the F5 world by reading the DevCentral articles. Then I started to go there daily and answer some questions myself. 
Short answer: to keep me updated, both about F5 news and my F5 knowledge.
DC: Tell us a little about the areas of BIG-IP expertise you have.
LS: Is difficult to know all F5 products, because some are for very specific networks/scenarios, but I know the common ones:
BIG-IP BIG-IP LTM, GTM/DNS, AFM, APM, ASM, EM, BIG-IQ, and iRules.
I had been a little bit lazy about the F5 certifications but recently I have done all level 300 exams. I have started study for the 401, so that should be done in the next couple months.
DC: As a Security Consultant at NTT Security, what’s your typical workday?
LS: First to clarify, the company recently changed names from NTT Com Security to NTT Security. 
I work in professional services, doing projects that use F5 products. My daily work includes doing some pre-sales activities advising pre-sales team about the F5 products, doing projects, and finding solutions or writing scripts to automate some F5 tasks.
DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.
LS: I have been using DevCentral for many years, and iRules, to a point where it is part of my daily job. Flexibility is a major advantage for F5 and people ask all the time “Can you do this with an iRule?” 
Recently, I was working in a project to upgrade many F5 devices. We had to perform an extensive inventory for each device which was taking about 3 days per device. I wrote a Python script using iControl SOAP to perform that task. (I still prefer bash script, but there is no iControl SOAP for bash) 
It would take around 240 days to do that manually, and we did in around 3 days using the script.
DC: Finally, if you weren’t in technology – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?
LS: I am doing the job I wanted since I was young and I can’t picture myself doing any other type of job.

Thanks Leonardo! Check out all Leonardo’s DevCentral contributions or connect with him on LinkedIn. And visit NTT Security on the web or follow on Twitter and LinkedIn.

Tuesday, April 25, 2017

Configure HA Groups on BIG-IP

Last week we talked about how HA Groups work on BIG-IP and this week we’ll look at how to configure HA Groups on BIG-IP.

To recap, an HA group is a configuration object you create and assign to a traffic group for devices in a device group. An HA group defines health criteria for a resource (such as an application server pool) that the traffic group uses. With an HA group, the BIG-IP system can decide whether to keep a traffic group active on its current device or fail over the traffic group to another device when resources such as pool members fall below a certain level.

First, some prerequisites:
  • Basic Setup: Each BIG-IP (v13) is licensed, provisioned and configured to run BIG-IP LTM
  • HA Configuration: All BIG-IP devices are members of a sync-failover device group and synced
  • Each BIG-IP has a unique virtual server with a unique server pool assigned to it
  • All virtual addresses are associated with traffic-group-1
To the BIG-IP GUI!

First you go to System>High Availability>HA Group List>and then click the Create button.
The first thing is to name the group. Give it a detailed name to indicate the object group type, the device it pertains to and the traffic group it pertains to. In this case, we’ll call it ‘ha_group_deviceA_tg1.’
Next, we’ll click Add in the Pools area under Health Conditions and add the pool for BIG-IP A to the HA Group which we’ve already created. We then move on to the minimum member count. The minimum member count is members that need to be up for traffic-group-1 to remain active on BIG-IP A. In this case, we want 3 out of 4 members to be up. If that number falls below 3, the BIG-IP will automatically fail the traffic group over to another device in the device group.
Next is HA Score and this is the sufficient threshold which is the number of up pool members you want to represent a full health score. In this case, we’ll choose 4. So if 4 pool members are up then it is considered to have a full health score. If fewer than 4 members are up, then this health score would be lower. We’ll give it a default weight of 10 since 10 represents the full HA score for BIG-IP A. We’re going to say that all 4 members need to be active in the group in order for BIG-IP to give BIG-IP A an HA score of 10. And we click Add.
We’ll then see a summary of the health conditions we just specified including the minimum member count and sufficient member count. Then click Create HA Group.
Next, we go to Device Management>Traffic Groups>and click on traffic-group-1.
Now, we’ll associate this new HA Group with traffic-group-1. Go to the HA Group setting and select the new HA Group from the drop-down list. And then select the Failover Method to Device with the Best HA Score. Click Save.
Now we do the same thing for BIG-IP B. So again, go to System>High Availability>HA Group List>and then click the Create button. Give it a special name, click Add in the Pools area and select the pool you’ve already created for BIG-IP B. Again, for our situation, we’ll specify a minimum of 3 members to be up if traffic-group-1 is active on BIG-IP B. This minimum number does not have to be the same as the other HA Group, but it is for this example. Again, a default weight of 10 in the HA Score for all pool members. Click Add and then Create HA Group for BIG-IP B.
And then, Device Management>Traffic Groups> and click traffic-group-1. Choose BIG-IP B’s HA Group and select the same Failover method as BIG-IP A – Based on HA Score. Click Save.
Lastly, you would create another HA Group on BIG-IP C as we’ve done on BIG-IP A and BIG-IP B. Once that happens, you’ll have the same set up as this:
As you can see, BIG-IP A has lost another pool member causing traffic-group-1 to failover and the BIG-IP software has chosen BIG-IP C as the next active device to host the traffic group because BIG-IP C has the highest HA Score based on the health of its pool.

Thanks to our TechPubs group for the basis of this article and check out a video demo here.

ps