The BIG-IP Application Security Manager Part 4: Attack Signatures

This is the fourth article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first three articles in this series are:

This fourth article in the series will discuss attack signatures...what they are, why they are necessary, and how you can use them to protect your environment.

What Is An Attack Signature?

Attack signatures are rules and patterns that identify attacks against your web application. When the ASM receives a client request (or a server response), the system compares the request/response to the attack signature associated with your security policy. If a matching pattern is detected, the ASM will trigger an "attack signature detected" violation and will either alarm or block based on the enforcement mode of your security policy. For example, a SQL injection attack signature will look for certain expressions like ' or 1=1 and if a user enters that string into a field (i.e. the username field) on your web application, the ASM will block the request based on the SQL injection attempt.

An ideal security policy would include only the attack signatures needed to defend your application. If too many are included, you waste resources on keeping up with signatures that you don't need. Likewise, if you don't include enough, you might let an attack compromise your application without every knowing it.

BIG-IP Attack Signatures

The BIG-IP ASM comes loaded with over 4,500 attack signatures, so it's certainly capable of protecting just about any attack your application might encounter. The following screenshot shows a sample of the ASM attack signatures. You can view this entire list by navigating to Security >> Options >> Application Security >> Attack Signatures >> Attack Signature List. You can also create your own unique signatures and use them to protect your application as well.

It can be overwhelming to figure out which signatures to employ for your application...especially when you have over 4,500 to choose from! That's where the Attack Signature Sets can help out. I know everyone read my ASM article on Policy Building, so you'll remember the part about choosing the attack signatures for your application. This is the part where you need to know what systems your application is built on (Windows, SQL, IIS, etc) so that you can choose the appropriate settings for the attack signatures. Once you do this, the ASM automatically configures an Attack Signature Set for your security policy. You can view this by navigating to Security >> Options >> Application Security >> Attack Signatures >> Attack Signature Sets. The following screenshot shows the specific attack signature set for the security policy that protects the online auction site that I've been using recently. Notice that, when I was building the security policy for this application, I chose Unix/Linux, Apache, Apache Tomcat, PHP, and MySQL as the assigned systems for the application. Based on those choices, the ASM automatically assigned the correct attack signatures to my security policy. That way, I didn't have to pick and choose from the long list of 4,500+ attack signatures...the ASM did it for me!

One more thing before we show some of this stuff in action. If you notice that a specific attack signature is causing some problems for you (false positives, etc), then you can disable that individual attack signature in your policy. Navigate to Security >> Application Security >> Attack Signatures >> Attack Signature List. Then, you can click on "Show Filter Details" and search for the specific attack signature that you want to disable. When you find it, simply click on it and then uncheck the "Enabled" box. After you do this, that specific attack signature will be disabled for that specific security policy, but it won't be affected in other security policies. This is a good thing because you may need that same attack signature in other security policies on your BIG-IP ASM!

The Attack

In this quick example, I tested to see if the online auction site would let me conduct a Cross Site Scripting (XSS) attack. I navigated to the "Sell an item" page and then, instead of describing the item, I inserted a small script in the description block of the page. The script simply pops up an alert screen with a message. If this worked, I knew that I could do some other nasty XSS attacks against this application. So, let's check it out...

Here's what happened when I finished filling out everything on the page...

So, the attack worked. As a hacker, I would be thrilled to know that I have a way to attack this site, but as a security guy, I would be very nervous about the vulnerability of my application.

BIG-IP Interface

Let's take a quick look at the ASM interface and see where we can dive into the details of this attack. You can navigate to Security >> Event Logs >> Application >> Requests and review all the application requests. The following screenshot shows the details of the attack listed above. I clicked on the request at the top of the list and it loaded up all the details of the request. Notice that this request was marked "Legal" and "Informational" because I don't have the attack signatures configured to block yet.

If you look toward the bottom of the page, you'll notice a Violation entry that says "Attack signature detected". I clicked on this link and it pulled up the smaller window shown in the screenshot below...this outlines the exact attack signatures that triggered the violation. You'll notice that each attack signature has a unique Signature ID, so you can search, filter, etc if you ever need to look up that attack signature again. Also, notice that the "Alarm" column states that these three attack signatures are in staging...that's the reason the ASM didn't block the XSS attack. More on that in just a minute. The last thing to note is that you can click on the "View details" link in the right-most column of each attack signature. This will pop up another window that gives you all the details on why that specific attack signature triggered a violation.

So, I clicked on the first attack signature in the list above (XSS script tag (Parameter) with Signature ID 200000098) and it pulled up the following window. This shows the exact detail of what caused the violation. In this case, check out the "Detected Keywords" block at the bottom of the page. You should notice that the keyword (highlighted in red with a box around it) is part of the actual XSS script that I used in the attack on the application. That keyword is what triggered the attack signature. You can use this information (as well as other information found in these windows) to make security decisions about your policy and application. It's a good idea to review your security logs on a regular basis to make sure you see these types of requests coming in!

Since the ASM allowed the XSS attack to access the application, let's go back and make sure the attack signatures are configured correctly to block this behavior in the future. Navigate to Security >> Application Security >> Attack Signatures >> Attack Signatures Configuration and uncheck the Signature Staging Enabled box. This will take all the attack signatures out of staging and will allow them to start taking the actions listed in the boxes to the right of each listed signature set. In the screenshot below, I have the Generic Detection Signatures (which are listed in every security policy by default) as well as my system specific signature set that was created when I built the security policy. For each of these signature sets, I have "Learn, Alarm, and Block" enabled. This means that the ASM will continue to generate learning suggestions for the policy, it will alarm (log) each attack violation, and finally it will actually block the attack.

By the way, after I took the attack signatures out of staging, I tried the XSS attack again...guess what happened?

Signature Updates

The last thing to discuss in this article is Signature Updates. As you can imagine, network attacks are very dynamic and require constant attention. In order to keep up with the ever-changing attack world, the signatures you employ in your security policy need to stay up to date as well. The BIG-IP ASM has a Signature Update feature that will add/delete attack signatures as needed. You can set the ASM to update signatures on a schedule (daily, weekly, or monthly) or you can update them manually. You can check out all the options when you go to Security >> Options >> Application Security >> Attack Signatures >> Attack Signatures Update. The last thing I'll mention is that all new attack signatures are automatically placed in staging. This happens because you won't know how a new attack signature is going to affect your application until you've had some time to test it first. After you test the new signature(s), then you can take them out of staging and turn them loose to protect your application!

Well, that's it for the attack signature article. Make sure you come back next time for some fun with XML security!

By the way, here's a link to the chapter on Attack Signatures from the BIG-IP ASM Configuration Guide: http://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/config_guide_asm_10_2_0/asm_attack_sigs.html. If you have more detailed questions, you might find some good info there as well.

Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list.