Forum Discussion
F5 ASM remote logging format (Splunk KV pairs)
The basic answers can be found in
Event Messages and Attack Types
and
K9435: Overview of the Storage Format option for a remote logging profile
date_time - Yes, this should be the timestamp of when ASM processed the request.
- violation_rating - K000137152: Violation Rating Based Enforcement
- route_domain - This is a BIG-IP LTM route domain.
- syslog_priority - This part of the syslog protocol. RFC 5424 Section 6.2.1 "The number contained within these angle brackets is known as the Priority value (PRIVAL) and represents both the Facility and Severity.
- sig_ids, sig_names, staged_sig_ids, staged_sig_names, sig_cves, staged_sig_cves - Event Messages and Attack Types
- ip_address_intelligence - Enabling IP Address Intelligence
websocket_direction, websocket_message_type - Yes they are details for the websocket protocol.
threat_campaign_names, staged_threat_campaign_names - Managing Threat Campaigns
- blocking_exception_reason - It's a reason why an illegal request was not blocked.
- microservice - ASM attempting to match the request to the micro service configured on the ASM policy.
- tap_event_id, tap_vid - TAP is short for threat analysis platform,
- fragment - It's the query string is the URL when the # separator is used.
Hi, thanks for providing the info and sources, really helpful and appreciate it. I wonder how the ASM would be able to capture the fragment identifier after the "#" in a request uri, since the fragment is not meant to be sent to the server, but is more like to be used by browser (client-side)?
I tried to test by randomly added "#something" in the request uri, but it still show us "N/A" instead of the query string containing the # separator.
Asking this because wondering whether it could help us in case there would be a scenario, where an attacker would exploit a vulnerable web application, probably with a malicious phishing link crafted to redirect the user to malicious website, e.g., "https://abc.com/abc.php#https://malicious-site.com". If this would be the case, perhaps we probably able to find suspicious URL in the "fragment" field found in the logs.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com