Prevent a Spoof of an X-Forwarded-For Request with BIG-IP

Last week, we looked at how to do Selective Compression on BIG-IP with a local traffic policy so this week let’s try something security related using the same procedures.

You can associate a BIG-IP local traffic policy to prevent a spoof of an x-forwarded-for request. This is where bad actors might attempt to thwart security by falsifying the IP address in a header, and pass it through the BIG-IP system.

Pre-reqs:

• We’re using BIG-IP v12 and,
• We already have a Virtual Server configured to manage HTTP traffic with an HTTP profile assigned to it.

Let’s log into a BIG-IP

The first thing we’ll need to do is create a draft policy. On the main menu select Local Traffic>Policies>Policy List and then the Create or + button.

This takes us to the create policy config screen. Type a unique Policy Name like PreventSpoofOfXFF and optionally, add a description. Leave the Strategy at the default of Execute First matching rule. Click Create Policy.

We’re then directed to the draft policy’s General Properties page and here we can create the rules for the policy. In the Rules area, click Create.

We’ll give the rule a unique name like, StopSpoof and the first condition we need to configure is to match all HTTP traffic with the matching strategy. This means we can use the default setting of All Traffic. Then we’ll tell the policy what to do when the All Traffic condition matches. The new action is to Replace the http header named X-forwarded-for with the value of tcl:[IP::client_addr] (to return the client IP address of the connection) at the request time. Click Save.

Also, save the draft.

And then select the box next to the draft policy and click Publish.

We can now associate the published policy with a virtual server that we’re using to manage http traffic. On the main menu click Local Traffic>Virtual Servers>Virtual Server List and click the name of the virtual server you’d like to associate for the policy.

On the menu bar click Resources and next to Policies click Manage.

Move PreventSpoofOfXFF to the Enabled list and click Finished.

Now, the virtual server with the PreventSpoofOfXFF local traffic policy will prevent any HTTP traffic that attempts to spoof an x-forwarded-for request.

Congrats! You’ve easily added additional security to your local traffic policy! You can also watch the full video demo thanks to our TechPubs team.

ps

Lightboard Lessons: What are Bots?

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.



ps

Related:

• The Facts about Botnets
• The state of botnets in late 2015 and early 2016
• What are bots?

Selective Compression on BIG-IP

BIG-IP provides Local Traffic Policies that simplify the way in which you can manage traffic associated with a virtual server.

You can associate a BIG-IP local traffic policy to support selective compression for types of content that can benefit from compression, like HTML, XML, and CSS stylesheets. These file types can realize performance improvements, especially across slow connections, by compressing them. You can easily configure your BIG-IP system to use a simple Local Traffic Policy that selectively compresses these file types. In order to use a policy, you will want to create and configure a draft policy, publish that policy, and then associate the policy with a virtual server in BIG-IP v12.

Alright, let’s log into a BIG-IP

The first thing you’ll need to do is create a draft policy. On the main menu select Local Traffic>Policies>Policy List and then the Create or + button.

This takes us to the create policy config screen. We’ll name the policy SelectiveCompression, add a description like ‘This policy compresses file types,’ and we’ll leave the Strategy as the default of Execute First matching rule. This is so the policy uses the first rule that matches the request. Click Create Policy which saves the policy to the policies list.

When saved, the Rules search field appears but has no rules. Click Create under Rules.

This brings us to the Rules General Properties area of the policy. We’ll give this rule a name (CompressFiles) and then the first settings we need to configure are the conditions that need to match the request. Click the + button to associate file types.

We know that the files for compression are comprised of specific file types associated with a content type HTTP Header. We choose HTTP Header and select Content-Type in the Named field. Select ‘begins with’ next and type ‘text/’ for the condition and compress at the ‘response’ time. We’ll add another condition to manage CPU usage effectively. So we click CPU Usage from the list with a duration of 1 minute with a conditional operator of ‘less than or equal to’ 5 as the usage level at response time.

Next under Do the following, click the create + button to create a new action when those conditions are met. Here, we’ll enable compression at the response time. Click Save.

Now the draft policy screen appears with the General Properties and a list of rules. Here we want to click Save Draft.

Now we need to publish the draft policy and associate it with a virtual server. Select the policy and click Publish.

Next, on the main menu click Local Traffic>Virtual Servers>Virtual Server List and click the name of the virtual server you’d like to associate for the policy.

On the menu bar click Resources and for Policies click Manage.

Move SelectiveCompression to the Enabled list and click Finished.

The SelectiveCompression policy is now listed in the policies list which is now associated with the chosen virtual server. The virtual server with the SelectiveCompression Local Traffic Policy will compress the file types you specified.

Congrats! You’ve now added a local traffic policy for selective compression! You can also watch the full video demo thanks to our TechPubs team.

ps

Legacy Application SSO with BIG-IP and Okta

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.

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.

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

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.

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.

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.

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.

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\tuser 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.

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.

ps

Lightboard Lessons: Connecting Cars with BIG-IP

I light up how BIG-IP and Solace work together in a MQTT connected car infrastructure.



ps

Related:

• Using F5 BIG-IP and Solace Open Data Movement technology for MQTT message routing and delivery
• Lightboard Lessons: What is MQTT?

DevCentral’s Featured Member for October – Jad Tabbara

Jad Tabbara has been a Security Engineer with e-Xpert Solutions in Switzerland since 2014.

He graduated from INSA de Lyon FRANCE with a master degree in telecommunications and nowadays, work takes the most part of my time, but happy to succeed in his endeavors.
As hobbies, he enjoys playing sports (soccer, tennis), traveling, sharing time with family and is DevCentral’s Featured Member for October. Our second Featured Member from e-Xpert Solutions!

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

Jad: First, I would like to thank you for giving me this opportunity. 

I have never contributed to a forum other than DevCentral. Compared to other editors, I must admit that DevCentral is well designed such as all other F5 websites, articles and documentations. DevCentral is a great place to learn and a simple access to information regarding iRules, iControl, etc. 

As a part of my personality, I like to share my experience and help others to achieve what they are doing, this is what I found at the community and keeps me involved.

DC: You are an Engineer at e-Xpert Solutions SA. Can you describe your typical workday?

JT: There is no typical workday at e-Xpert Solutions since we always have new challenges, projects and customers. As part of my work, I implement security solutions mainly based on BIG-IP LTM, APM and ASM modules. I participate to all phases of a project (design, install & configure, maintain and troubleshoot).

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

JT: As good news, I’ve just added the 304 APM to my certification list. My objective is to get all remaining certifications before next year (BIG-IP ASM, DNS and 401). These certifications help me to learn more about BIG IP features and prove my technical skills. I believe that it’s a differentiator for me and e-Xpert Solutions. Finally, for customers, it guarantees a high level of expertise.

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

JT: There are many situations where DevCentral and iRules helped me a lot! Let me share with you one of the hardest issue I had to deal with. A customer was load balancing SFB solution through F5. 

An intermittent voice call interruption was occurring after 5 seconds only when tethering connection using a smartphone with a specific ISP. Thanks to DevCentral that helped me to make advanced tcpdump captures from end to end. After analysis, the problem was found. The client connected to the specific ISP used same source port for two connections (F5 and SFB). The F5 was replying using the wrong socket. Finally, to work around this weird client behavior, we changed the “Source Port Translation” option on the VS from “Preserve” to “Change”.

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?

JT: When I was a kid, my dream was to be a soccer player. Later with the use of trendy applications such as MSN and Skype I became curious to understand how Internet world works. So, I decided to make studies in this field. During this period, I realized risks of Internet (introduced by malicious users) so I came up to specialize and work in security.

Thanks Jad! Check out all of Jad's DevCentral contributions, connect with him on LinkedIn and visit e-Xpert Solutions SA, follow on Twitter or visit LinkedIn.