Archive for application security

DevCentral’s Featured Member for March - Hannes Rapp

Posted in f5, big-ip, application security, application delivery, devcentral by psilva on March 6th, 2018

hannes.pngHannes 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!

 




Post of the Week: SSL on a Virtual Server

Posted in security, f5, big-ip, application security, silva, video, lightboard, http, ssl, devcentral, certificate by psilva on December 22nd, 2017

In this Lightboard Post of the Week, I answer a few questions about SSL/https on Virtual Servers. BIG-IP being a default deny, full proxy device, it's important to configure specific ports, like 443, to accept https traffic along with client and server side profiles and include your SSL certificates. We cover things like SAN/SNI certificates but I failed to mention that self-signed certificates are bad anywhere except for testing or on the server side of the connection.

 

 

 

Watch Now:



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

Posted in security, f5, big-ip, application security, asm, compliance, malware, 0day, owasp by psilva on November 29th, 2017

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.

13to17.png

  

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):

asmclip.jpg

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:




Mitigate L7 DDoS with BIG-IP ASM

Posted in security, f5, big-ip, application security, silva, DoS attack, devcentral, infrastructure, waf, ddos by psilva on November 28th, 2017

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.

l7d2.png

 

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.

l7d34.png

 

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

l7d5.png

 

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.

l7d6.png

 

And JavaScript incapable clients never make it through.

l7d7.png

 

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

l7d8a.png

 

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

l7d8b.png

 

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

l7d8c.png

 

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…

l78de.png

 

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

pot.png

 

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.

dvwa_logs_full.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 




Lightboard Lessons: What is DDoS?

Posted in security, f5, application security, lightboard, DoS attack, basics, scams, devcentral, 0day, botnet, ddos by psilva on November 1st, 2017

Over the last quarter, there were approximately 500 DDoS attacks daily around the world with some lasting as long as 300 hours. In this Lightboard Lesson I light up some #basics about DoS and DDoS attacks. 

ps

Related:

 

Watch Now:



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

Posted in security, f5, big-ip, application security, http, compliance, scams, devcentral, infrastructure by psilva on October 24th, 2017

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

xf1.jpg

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.

xf2.jpg

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.

xf3.jpg

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.

xf4.jpg

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.

xf5.jpg

Also, save the draft.

xf6.jpg

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

xf7.jpg

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.

xf8.jpg

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

xf9.jpg

Move PreventSpoofOfXFF to the Enabled list and click Finished.

xf9a.jpg

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




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: 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:



Security Trends in 2016: Securing the Internet of Things

Posted in security, big-ip, application security, devcentral, iot, sensors by psilva on February 7th, 2017

mirai-trojan.png

Whenever you connect anything to the internet, there is risk involved. Just ask the millions of IoT zombies infected with Mirai. Sure, there have been various stories over the years about hacking thermostats, refrigerators, cameras, pacemakers, insulin pumps and other medical devices along with cars, homes and hotel rooms…but Mirai took it to a new level.

And it’s not the only IoT botnet out there nor are these nasty botnets going away anytime soon. There’s a gold mine of unprotected devices out there waiting to either have their/your info stolen or be used to flood another website with traffic.

This is bound to compound in the years to come.

A recent Ponemon Institute report noted that an incredible 80% of IoT applications are not tested for vulnerabilities. Let’s try that again – only 20% of the IoT applications that we use daily are tested for vulnerabilities. There’s probably no indication or guarantee that the one you are using now has been tested.

R025_Fig1_1.jpg

Clearly a trend we saw in 2016, and seems to continue into 2017, is that people are focusing too much on the ‘things’ themselves and the coolness factor rather than the fact that anytime you connect something to the internet, you are potentially exposing yourself to thieves. There has been such a rush to get products to market and make some money off a new trend yet these same companies ignore or simply do not understand the potential security threats. This somewhat mimics the early days of internet connectivity when insecure PCs dialed up and were instantly inundated with worms, viruses and email spam. AV/FW software soon came along and intended to reduce those threats.

Today it’s a bit different but the cycle continues.

Back then you’d probably notice that your computer was acting funky, slowing down or malfunctioning since we interacted with it daily. Today, we typically do not spend every waking hour working with our IoT devices. They’re meant to function independently to grab data, make adjustments and alert us on a mobile app with limited human interaction. That’s the ‘smart’ part everyone talks about. But these botnets are smart themselves. With that, you may never know that your DVR is infected and allowing someone across the globe (or waiting at the nearest street corner) watch your every move.

Typical precautions we usually hear are actions like changing default passwords, not connecting it directly to the internet and updating the firmware to reduce the exposure. Software developers, too, need to plan and build in security from the onset rather than an afterthought. The security vs. usability conundrum that plagues many web applications extends to IoT applications also. But you wouldn’t, or I should say, shouldn’t deploy a financial application without properly testing it for vulnerabilities. There the risk is financial loss but with IoT and particularly medical/health devices the result can be deadly.

Mirai was just the beginning of the next wave of vulnerability exploitation. More chaos to come.

ps

Related:

 





« Older episodes ·