WAF generic detection signatures
Hi All, I found something strange with the signature setGeneric Detection Signatures (High/Medium Accuracy) assigned to the ASM policies. This signature sets claims to include the following systems. Systems:General Database,Various systems,System Independent,JavaScript However when I compare the total of signatures of each system in the attack signature list available on the system it does not match the total of the signatures assigned to the ASM policy. For example 2556 System Independent 1932 on ASM policy 24 Various systems same on ASM policy 708 general database 391 on ASM policy Strange thing that for example signature200022004 was assigned to the ASM policy but after live update of the signatures not anymore. Could someone clarify the content of the generic signature set and why arent all the signatures of sytem independent, various systems and general database included?
ASM Signatures Learning
Dears, I have a question regarding the ASM Signatures learning. On a box, the signatures are not enforced. They are in staging only. The enforcement period is set to 7 days, and learning mode to manual. Upon performing a security audit, it was found that the application is exposed to number of attacks due to this. Can someone explain how to resolve this, and ensure that the signatures are enforced with minimal admin intervention?
REST - List enforcement readiness
Hi, is it possible to use REST to retrieve the status of enforcement readiness? I mean, a list of signatures in stage (not enforced), a list of signatures with suggestions and a list of signatures ready to be enforced? I tried to search this information on the icontrol-rest-api-user-guide-12-1-0.pdf, but I haven't found anything like this.
Identifying ASM signatures affecting responses?
Env: LTM 11.5.2 with ASM We have a security profile which appears to be affecting responses for a small set of requests, without reporting any error or block in the ASM event log. This is a REST call that accespts JSON input data, retreieves data from a database, and returns the data results as JSON. When we run the query for a userid that returns a small result, there is no issue. But when we use a different userid that has more data, the client never receives the response (not a single byte gets returned, at the network level). Nevertheless, the response appears in the ASM event log (though at the top of the response content display it says "Response was truncated"), and I see content displayed, as if it had been sent back. The size of the response that has an issue isn't huge (about 15K). We have only one entry in our Parameter List for this policy, "*" of type User-input value. We turned off both Value and Name meta-characters checks, just in case, with no effect. However, when we turn off signature checks for the parameter, the problem goes away. So, our assumption is that some signature is processing the response, and freezing, or some other way affecting the stream going back to the client, such that bytes never get sent. But it's happening with no indication in the ASM event log. How can we identify what signature is the culprit? Is there a way to search just the signatures that parse responses, vs. request data? (the Advanced filter lumps Request/Response together). Is there any advanced ASM signature processing logging that we can turn on, anything like that? And any other thoughts on what the cause might be would be appreciated. I don't think it's size related, as the max_html setting in advanced. I thought maybe chunking, but Transfer-Encoding: chunked is appearing in both working and non-working responses. Hmm ....
Exporting a full list of Attack Sigantures
Hi. I am looking to export a full list of the current signatures I have in blocking mode. If possible, I would like to separate these lists in to their signature sets. If I navigate to "Security ›› Options : Application Security : Attack Signatures : Attack Signature Sets" then I can view the different signature set types. Let's take the High Accuracy Signatures for instance. If I click on those, I get a list of signatures that are a part of that set, but I cannot copy and paste them. I have people asking me for a list of these signatures so I am hoping there is an easy way to extract these. They want to be able to share it within their team to show what the WAF is doing for them, and what it is blocking so they can test it out for themselves. Is it a possibility that a file exists in the console that I can pull down through WinSCP that has a list of these? Similarly if I go to "Security ›› Application Security : Attack Signatures" I would like to be able to export the full list of 2857 signatures I have for this policy. Thanks.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: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs 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. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
