How "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?1.8KViews0likes11CommentsASM from blocking to transparent mode
Hello everyone, I apologize if this has already been asked here on this forum, but from the search I did I only found the opposite question, which is normal. Can anyone tell me what precautions or possible impacts there might be when changing the ASM from blocking to transparent? And will it just stop blocking all violations or will it keep the blocks it has cached from the previous (blocking) configuration? thank you all in advance for your time600Views0likes1CommentASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr528Views0likes1CommentASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr331Views0likes0CommentsGTM Generic Host, Mutliple Data Centers with Transparency
Hello All, I have a scenrio that I cannot get to work because of the GTM forcing a Generic host address to be part of only one Data Center. I have a single Server (ServerA) that is on a our OTV VLAN between both DC1 and DC2. We using GTM transparency to return external NATs to the outside for this Server (1.1.1.1 and 2.2.2.2). The issue I am having is if the egress Link monitor is down in DC1 I want the GTM to return the DC2 transparent addr (2.2.2.2). However because I can't make two Generic Host objects with the same IP, the GTM will start round robining as a best effort, which will fail. For example: ServerA = 10.10.10.5 TransparentAddrA = 1.1.1.1 TransparentAddrB = 2.2.2.2 A = DC1, B = DC2 Any ideas on how to get this to work?Solved315Views0likes1Comment