We all know that the BIG-IP ASM does a bunch of great things to protect web applications from malicious attackers.  We also know that it’s extremely important to review logs to ensure visibility and awareness about application traffic.  In fact, the OWASP organization published the “OWASP Top 10 Proactive Controls” as recommended steps to help mitigate each of their published Top 10 security vulnerabilities.  Some of these proactive controls help mitigate more than one of the Top 10 vulnerabilities, but they list “Logging” as a control that helps mitigate all ten

They say it like this, “Logging and tracking security events and metrics helps to enable "attack-driven defense" making sure that your security testing and controls are aligned with real-world attacks against your system.” Needless to say, event logging is critical to the overall security of your web applications.

 

BIG-IP ASM Logging Profiles

The BIG-IP ASM dedicates significant resources to event logging.  After all, when the ASM blocks a malicious request, you’ll likely want to know all the details associated with that request.  Fortunately, you can create a “logging profile” and configure it to capture all kinds of great information.  To create a logging profile, navigate to Security >> Event Logs >> Logging Profiles and then click the “Create” button on the upper right part of the page to begin creating a new logging profile.  Check out the screenshot below to see the details:

 

Logging Profile - Remote Storage

 

You can name your profile whatever you want, but in this case, we are going to set up a profile to send logs to Splunk, so I named mine “Splunk”.  Because I’m sending these logs to a remote server, I enabled the “Remote Storage” checkbox and it gave me all the different options for choosing format, protocol, server address/port, and storage format.  I chose the UDP protocol because that’s what Splunk uses, I typed in the IP address for the Splunk server I’m using (be sure to click the “Add” button after you input IP address and port), and I moved all the Storage Format items from “Available” to “Selected”.  Finally, click the “Finished” button at the bottom of the screen to complete the profile creation.  The screenshot below shows all the completed configurations for my profile:

Splunk Logging Profile

 

Now we have a complete profile that will send all the “Selected” items to the Splunk server using UDP port 514.  There’s still one thing to do, though.  We need to associate this profile with a virtual server on the BIG-IP.  After all, the logging profile won’t know which server to be capturing log information for unless we tell it. 

To do this, navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the virtual server you want to associate with this Logging Profile.  When you select the virtual server, you’ll notice a series of menu choices across the top of the screen…click on the “Security” link and select the “Policies” option.  When you do that, you’ll see the screen shown below:

Logging Profile Selected

 

Notice that I have a security policy (auction_security_policy) and it is enabled on this virtual server.  Additionally, I changed the “Log Profile” option from Disabled to Enabled.  When it changes to Enabled, you’ll see a menu that allows you to move logging profiles from “Available” to “Selected”.  I moved my Splunk logging profile to the Selected column and finally clicked the “Update” button. 

Now, I have a fully functional logging profile that has been enabled on my virtual server.  It’s time to generate some logs by visiting (or, in my case, attacking) the web application that is being protected by my Application Security Policy.

I’ll save you all the screenshots of my web application, but I will show you the log report captured on the BIG-IP when I attempted an injection attack against my web application.  Navigate to Security >> Event Logs >> Application >> Requests and you’ll see the list of illegal requests that were blocked by the ASM security policy. 

Illegal Request List

 

Remember how the logging profile listed the “Remote Storage” as an option?  Well, if you looked closely, you noticed that it also included “Local Storage” as well.  That means the BIG-IP will keep a record of all these illegal requests in addition to sending them over to the Remote Storage server.  You can obviously configure these settings differently depending on your needs.  Anyway, back to the illegal request list.  Notice that two of the ASM attack signatures detected a violation in the request.  And, rightfully so…after all, I was attempting an injection attack!

After I attempted the injection attack, I wanted to slightly change the configuration of the logging profile, so I changed the logging profile to only capture attack-type for each illegal request.  I navigated back to my Splunk logging profile and moved everything but “attack_type” back from Selected to Available and then clicked Update.  See the screenshot below:

Logging Profile - Attack Type Only

 

The nice thing about making this change in the logging profile is that I don’t have to change it anywhere else on the BIG-IP.  Any virtual server that has this logging profile enabled will now only capture the attack_type field when logging an illegal request.

So, enough with the BIG-IP…what about the remote Splunk server?  Well, I logged into Splunk and set up a custom search on UDP port 514 since that is the port I configured to send logs to Splunk from the BIG-IP.  Check out the screenshot below to see the details that Splunk captured:

Splunk Search

 

Notice the first request in Splunk lists all the details of the illegal request.  If you look closely, you’ll notice that all these details match up to the list of “Selected” items chosen in the logging profile.  Then, notice that the most current request (the one at the top of the list) only lists the attack_type…in this case it’s “SQL-Injection”.  Pretty cool stuff, huh?

The BIG-IP is capable of sending log information to much more than just Splunk, so get out there and configure those logging profiles to suite your specific needs.  Remember, log review is one of the most critical things you can do to protect all your web applications!