Just deployed an ASM in line with a bunch of virtual servers, but I am seeing a bunch of traffic flows that look like XML, but don't really conform to the open and closing tag format.
I need to figure out a way to get the ASM to target those HTML fields so I can mark them as sensitive so they will be obfuscated in the event logs.
So as an example:
POST /ofxserver/ofxsrvr.dll HTTP/1.1
User-Agent: MFM-Android/4.4.46 Nexus 5X OS 7.1.2
The USERPASS item shows in cleartext during the HTTPS stream, and as a consequence shows in the event logs. We want to hide the content of the USERPASS section, but I have yet to find a decent way to mark that field as a sensitive parameter or the like.
I have attempted to import the XSD files for OFX, to see if the templates can teach the ASM how to parse the XML (but again it doesn't look like any XML I have ever seen).
If anyone could provide some insight into how I can target these fields so I can make sure they are obfuscated in the event logs would be very helpful!
This data format isn't XML but rather OFX (Open Financial Exchange), a financial data exchange standard originally based on SGML.
Further, ASM brute force protection is restricted to specific content types (text/html, text/xml, application/sgml, application/xml, application/html, application/xhtml, application/x-asp, or application/x-aspx) but OFX data has a content type of "application/x-ofx" and therefor wouldn't be included.
Protection for OFX services is probably better provided by a combination of IP Intelligence (to exclude known bad-actor sources) and custom iRules to examine OFX requests for specific strings used for brute-force OFX attacks or to collect data to identify bad-actors for blocking.
You should probably make contact with your F5 Account team to see about resources that can help you develop a suitable solution.
I definitely get what you are saying in regards to it not being able to protect the traffic. However my goal is really to tell the ASM not to log or to obscure specific string patterns so it doesn't show in the event logs.
In the worst case scenario, exclude logging for those patterns outright.
Looks like this becomes a moot point for our topic. My server team decommissioned the systems hosting that service today. Thanks for your help!