Attack Signature Staging Audit / History
Hi Team, I have just started my attack signature journey being automatically pushed out via Big-IQ and loving the fact that I no longer have to deal with change windows etc! Currently my production system is just setup for auto updates and still require manually activation out of staging to be enabled. In my Nonprod environment, I have the same autoupdate of attack signatures for the last few months and have setup autostaging ( I think I have! ) by setting my staged time to 14 days. The question is, is there a log/history/event that I can view that shows when attack signatures move out of staging and where the heck do I find it ?ASM same URL variants
Hi, I wonder why (13.1.0.7, Comprehensive, Automatic Learning, Always for URLs) for some URLs two entries (Explicit) are created, for example: / /. I never saw request containing URL /. so why those are added by policy building process? Above examples are not alone, there are other URLs added like that but not all - can't see logic here. After policy is stabilized all URLs with . at the end remains in staging and counterparts without . are no longer in staging. PiotrASM 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? Piotr
ASM 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? PiotrASM same URL variants
Hi, I wonder why (13.1.0.7, Comprehensive, Automatic Learning, Always for URLs) for some URLs two entries (Explicit) are created, for example: / /. I never saw request containing URL /. so why those are added by policy building process? Above examples are not alone, there are other URLs added like that but not all - can't see logic here. After policy is stabilized all URLs with . at the end remains in staging and counterparts without . are no longer in staging. Piotr
ASM: About the effects of "Real Traffic Policy Builder" to "Perform Staging"
Hi All My ASM's configuration as follow: Security ›› Application Security : Policy Building : Real Traffic Policy Builder® Settings is DISABLED Security ›› Application Security : Parameters : Parameters List ›› Parameter Properties :Perform Staging is ENABLED I think close "Real Traffic Policy Builder" then "Perform Staging" as invalid ,But why I needs to DISABLED Parameter's "Perform Staging" to be Block the Parameter's viloations? Thanks D.LuoAbout the effects of Real Traffic Policy Builder to Staging
Hi All My ASM's configuration as follow: Security -- Application Security : Policy Building : Real Traffic Policy Builder? Settings is DISABLED Security -- Application Security : Parameters : Parameters List -- Parameter Properties :Perform Staging is ENABLED I think close "Real Traffic Policy Builder" then "Perform Staging" as invalid ,But why I needs to DISABLED Parameter's "Perform Staging" to be Block the Parameter's viloations? Thanks D.Luo
attack signature updates
I am looking to settle a conversation I am currently having with a customer. he states that with the signature updates that the "enable staging" box must be checked for the policy and only the new updates will be in staging at that time not the entire policy( I'm referring to the actual policy page not the signature update page, I am sure that one goes into staging regardless) My understanding is that the signatures that were updated as well as any new sigs go directly into staging for seven days and that if you click "enable staging" on the policy, it puts the entire policy into staging and will not block anything? is this the case? is being in staging mode just nearly the same as transparent? any and all advice is appreciated, a step by step guide to safely implementing signature updates would be extremely helpful if someone had guidance on thissignature updates
I am curious as to how long newly input signatures as well as updates stay in staging after they have been downloaded. is this generally a formality and has minimal impact or are they heavy sig updates that must be monitored to ensure valid traffic is not blocked. F5 states that the updates go immediately to staging, but what is the period for this and how can I validate?