Forum Discussion
Jim_M_172559
Nimbostratus
NimbostratusHow "transparent" is transparent mode in ASM?
When setting up Application Security Manager, it's standard to set a security policy to "transparent" for a virtual server, watch what violations it catches, revise as needed and then change from transparent to blocking mode.
It turns out transparent mode is not completely transparent and can break an application, even with simple defaults from a rapid deployment security policy. The Data Guard feature will, by default, replace a string of digits with asterisks if it thinks it may be a credit card or social security number. That can break an application if, for instance, that string of digits was in a critical piece of javascript code. It can of course be turned off by unchecking the Mask Data option in Data Guard, or by exempting certain URLs.
Until this happened, I thought transparent mode was fairly safe to turn on, so I'd like to know what other features, especially those on by default, could interfere with a virtual server's traffic. ASM will add cookies by default, but I haven't seen that cause a problem yet. I don't know of any others on by default, but think that if the Web Scraping or Brute Force features are enabled, their client side integrity defense would be sending a javascript challenge to the client even in transparent mode.
Anything else I'm missing? Any other caveats to applying a transparent mode ASM security policy?
shaggy_121467Cumulonimbus
transparent mode essentially means that no requests are blocked altogether (dropped or generate a blocking response) by the policy, not that ASM does not interact with traffic. that being said, i also dislike that an rdp policy in transparent mode has data guard masking enabled, but by definition, it's not blocking entire requests.
from my experience cookie insertion, data-guard, and any feature that injects javascript (csrf protection, DDoS client side integrity defense, web-scraping protection) will interact with traffic when in transparent mode
Chris_GrantEmployee
Transparent mode can result in Javascript injection, even though it won't block based on the response. It will also result in TS cookies being added, and as you have already noted it turns data guard on. The only other caveats I can think of involve non RFC compliant traffic. ASM's parser is stricter than LTMs, and if you're sending traffic through that isn't either explicitly supported, or compliant HTTP we will fail to pass that on. It isn't blocking, per se, but has the same net effect (loss of functionality).
shaggytransparent mode essentially means that no requests are blocked altogether (dropped or generate a blocking response) by the policy, not that ASM does not interact with traffic. that being said, i also dislike that an rdp policy in transparent mode has data guard masking enabled, but by definition, it's not blocking entire requests.
from my experience cookie insertion, data-guard, and any feature that injects javascript (csrf protection, DDoS client side integrity defense, web-scraping protection) will interact with traffic when in transparent mode
- Chris_Grant
Transparent mode can result in Javascript injection, even though it won't block based on the response. It will also result in TS cookies being added, and as you have already noted it turns data guard on. The only other caveats I can think of involve non RFC compliant traffic. ASM's parser is stricter than LTMs, and if you're sending traffic through that isn't either explicitly supported, or compliant HTTP we will fail to pass that on. It isn't blocking, per se, but has the same net effect (loss of functionality).
Jim_M_172559Yeah, those are the only ones I could think of. Thanks for the response.
Perhaps a third, watch-only / true transparent, mode would be a good idea. Or at least make it clearer what non-transparent things happen in transparent mode. F5 should definitely take Data Guard out of the default Rapid Deployment policy.
- prt1969
Just ran into the same issue with data guard on a policy in transparent mode, which affected video content. Anything further from F5 on this? There really should be a true transparent mode where NOTHING is acted upon until you tell it to. Either that or give the current transparent mode a different name.
Transparent just mean non-blocking. ASM will do everything to learn and track the traffic without blocking it.
prt1969_120570Yes, but even in transparent mode, the F5 is still modifying traffic. See above. Cookie insertion and data guard masking are 2 examples. To me, that is not truly transparent. So really, we are looking at learning, tracking, and modifying without blocking. Modifying the traffic can affect traffic, as noted above.
You are right. It is not truly transparent and thus confusing. The "transparent mode" is only transparent in regards to performing blocking (i.e blocking pages) - however, in transparent mode other things are altered - javascripts can be injected, TS cookie added etc. You can open a support case to get this renamed. Product development will consider it as an enhancement request.
- Jim_M_172559
At the very least, transparent is a misleading term. It didn't block the response, but it did mangle it.
I agree with Jim. Transparent term is misleading. It should be "non-blocking" or something similar, in my opinion. Transparent gives the impression that data is not being transformed by ASM at all - which is not true. TS cookie is being inserted, sensitive data might get masked (if DG is enabled) and Javascript challenge might be added to the response (if fingerprinting options are in place).