Logging profiles determine where events are logged, and which items (such as which parts of requests, or which type of errors) are logged. Events can be logged either locally on the system and viewed in the Event Logs, or remotely by the client’s server. The system forwards the log messages to the client’s server using the Syslog service. Each logging profile can specify local or remote logging, but not both.
You can use one logging profile for Application Security, Protocol Security, Advanced Firewall, and DoS Protection. The system includes two logging profiles that log data locally for Application Security: one to log all requests and another to log illegal requests. Other logging profiles are included for global-network and local-dos. You can use the system-supplied logging profiles, or you can create a custom logging profile. The system-supplied logging profiles cannot be edited.
The logging profile records requests to the virtual server. By default, when you create a security policy using the Deployment wizard, the system associates the log illegal requests profile to the virtual server associated with the policy. You can change which logging profile is associated with the security policy by editing the virtual server.
A logging profile has two parts: the storage configuration and the storage filter. The storage configuration specifies where to store the logs, either locally or remotely. The storage filter determines what information is stored. For remote logging, you can send logging files for storage on a remote system (in CSV format), on a reporting server (as key/value pairs), or on an ArcSight server (in CEF format). Note that configuring external logging servers is not handled by F5 Networks.
You can assign multiple logging profiles to one virtual server. Here are some examples of how to use multiple logging profiles:
You can log all requests locally using just one logging profile. But you can save resources by logging illegal requests locally and logging all requests remotely. You would create two logging profiles:
If your company uses multiple security information and event management (SIEM) systems to collect logs and other security related information (for example, Splunk and ArcSight), you could set up three logging profiles.
|Off||Do not log responses.|
|For Illegal Requests Only||Log responses for illegal requests.|
|For All Requests||Log responses for all requests. Used when the Storage Filter Request Type is set to All Requests. (Otherwise, logs only illegal requests.)|
When you store the logs locally, the logging utility may compete for system resources. Using the Guarantee Local Logging setting ensures that the system logs the requests in this situation but may result in a performance reduction in high-volume traffic applications.
Information related to traffic controlled by the security policy is logged using the logging profile or profiles specified in the virtual server.
If you enable response logging in the logging profile, the system can log only responses that include the following content headers:
The system cannot log other responses.
If your network uses ArcSight logs, you can create a logging profile so that the log information is saved using the appropriate format. Application Security Manager stores all logs on a remote logging server using the predefined ArcSight settings for the logs. The log messages are in Common Event Format (CEF).
The basic format is:
CEF:Version|Device Vendor|Device Product|Device Version |Device Event Class ID|Name|Severity|Extension
Application Security Manager™ can log security events to the /var/log/asm file on the system if you need to. Logging to this file is off by default. You can turn the logging on using the send_content_events system variable from the command line, or on the System Variables screen: .
Here is the format of the syslog request followed by descriptions of the fields:
<Rejection Description> <Request Violation> <Support ID> <Source IP> <XFF IP> <Source Port> <Destination IP> <Destination Port> <Route Domain> <HTTP Classifier> <Scheme> <Geographic Location> <Request> <Username> <Session ID> <Violation Rating>
|Field||What it contains|
|Rejection Description||Empty unless the request is blocked by the security policy.|
|Request Violations||A comma separated list of the violations that occurred during enforcement of the request or response.|
|Support ID||An ID number assigned to the request by the system to allow the system administrator to track it.|
|Source IP||The IP address from which the request originated.|
|XFF IP||The X-Forwarded-For (XFF) IP address located in the XFF header and which represents the end client's IP address.|
|Source Port||The port from which the request originated.|
|Destination IP||The IP address to which the request is sent, generally, the virtual server IP address.|
|Destination Port||The port to which the request is sent.|
|Route Domain||The route domain (network traffic segment) where the request originated.|
|HTTP Classifier||The name of the ASM security policy.|
|Scheme||Whether the request was made using HTTP or HTTPS.|
|Geographic Location||The two-letter country code of origin based on the source IP address.|
|Request||The actual request made including headers (up to 128 bytes).|
|Username||Name of the user associated with the request.|
|Session ID||ID number assigned to the request to allow the system administrator to track requests by session.|
|Violation Rating||Rating between 1 and 5 that ranks the severity of any violations associated with the request. 1 is most likely a false positive and 5 is most likely an attack.|
|OR||Select this operator to log the data that meets one or more of the criteria.|
|AND||Select this operator to log the data that meets all of the criteria.|
The system logs application security data that meets the criteria specified in the storage filter.
The system displays application security data that meets the criteria specified in the logging profile.