Archive for application security

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:

 




Lightboard Lessons: SSO to Legacy Web Applications

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.

In this Lightboard Lesson, I draw out how VMware and F5 helps remove these complexities and enable productive, any-device app access. By enabling secure SSO to Kerberos constrained delegation (KCD) and header-based authentication apps, VMware Workspace ONE and F5 BIG-IP APM help workers securely access all the apps they need—mobile, cloud and legacy—on any device anywhere.

 

 

Watch Now:




« Older episodes ·