The BIG-IP Application Security Manager Part 10: Event Logging

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

1. What is the BIG-IP ASM?
2. Policy Building
3. The Importance of File Types, Parameters, and URLs
4. Attack Signatures
5. XML Security
6. IP Address Intelligence and Whitelisting
7. Geolocation
8. Data Guard
9. Username and Session Awareness Tracking

In this, the final article in the BIG-IP ASM series, we will dive into the excitement and necessity of event logging. Throughout this ASM series, we've looked at log files from a distance but we never really talked about how to configure logging. I know...event logging might not be the most fascinating part of the ASM, but it's really important stuff! Before joining F5, I worked as a cyber threat analyst for a government organization. I saw lots of cyber attacks against various systems. After an attack would take place, my team and I would come in and study the attack vector, target points, etc and it seemingly never failed that the system logs showed at least some (but many times all) of the malicious activity. If someone had just been reviewing the logs...
 

Logging Profiles

Logging profiles specify how and where the ASM stores requests for application data. In versions prior to 11.3.0, a logging profile is associated with a security policy, but beginning in 11.3.0 the logging profile is associated with a virtual server. I'm using version 11.3.0 in these examples, so this article will associate a logging profile with a virtual server.

When choosing a logging profile, you have the option of creating your own or using one of the system-supplied profiles. In addition, you can log data locally, remotely, or both using the same logging profile. Keep in mind that the system-supplied profiles are configured to only log data locally. The logging profile specifies two things: where the log data is stored (locally, remotely, both) and what data gets stored (all requests, illegal requests only, etc).

Creating a Profile

To create a new logging profile, navigate to Security >> Event Logs >> Logging Profiles and click the "Create" button. You will see the following screen:

I named this one "Test_Log_Profile" and enabled logging for Application Security. Notice that you can enable logging for Application Security, Protocol Security, and/or Denial of Service Protection. I enabled local storage and filtered for "Illegal Requests Only". Now that I have my logging profile created, I can associate it with the virtual server.
 

Configuring the Virtual Server

Navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the virtual server with which you want to associate the logging profile. Notice the tabs across the top part of the page...click on Security >> Policies and you will see the following screen:

Now you can move the logging profile from "Available" to "Selected" in order to enable the profile for the virtual server. Also, notice that "Application Security Policy" is enabled and the name of the security policy is listed in the drop down menu.

If you enable more than one profile, the ASM will apply the settings of the top profile first and then work down the list.
 

Viewing Log Files

Log data is stored in the /var/log/asm folder on the BIG-IP. You can view the details of the log data using the command line or the GUI.
 

Command Line

To view the log data via the command line, use a command like "cat" or "tail". You can also use other standard commands like "grep" to filter results or "more" to view one page at a time.

GUI

To view the Application Security logs in the GUI, navigate to Security >> Event Logs >> Application >> Requests and you will see the following screen:

You can click on any of the application requests, and the details will load in the bottom portion of the screen. You can view the Request Details, the actual HTTP Request, or the actual HTTP Response (if response logging is enabled in your logging profile). Many times response logging is not enabled due to the large amount of data this would consume.

Remote Storage

The ASM provides the option of storing log data on a remote server. When configuring a logging profile, you can view the Advanced Configuration to enable remote storage and select one of three types. The first is "Remote" and this option specifies that the ASM will store all traffic on a remote logging server like syslog. The second is "Reporting Server" and this option specifies that the ASM will store all log data on a server using a preconfigured storage format. The third option is "ArcSight" and this option specifies that the ASM will store all log data on a remote server using predefined ArcSight settings for the logs (the log messages are in the Common Event Format).

Speaking of remote storage...a popular remote log management tool is Splunk. In fact, Splunk offers a specific F5 app that does a fantastic job of organizing and displaying log data in a way that is easy to understand and consume. If you need more information on the Splunk app for F5 log data, check out this article written by the one and the only Jason Rahm...you'll be glad you did!

Well, that wraps things up for this article. It's been a fun ride through the internal workings of the BIG-IP ASM. I hope you have enjoyed this series as much as I have. Stay tuned for my next set of articles on the awesomeness that is DNS...see you soon!!

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.

1. What is the BIG-IP ASM?
2. Policy Building
3. The Importance of File Types, Parameters, and URLs
4. Attack Signatures
5. XML Security
6. IP Address Intelligence and Whitelisting
7. Geolocation
8. Data Guard
9. Username and Session Awareness Tracking
10. Event Logging