Forum Discussion
Nik_67256
Nimbostratus
NimbostratusGenerating Traffic Learnings through Explore scans
Hello All / Aaron,
To generate useful learning traffic (becasue say the site is not really used) , Is it a good idea to run a web app scan in the "Explore Mode". This will access every url of the site and generate traffic for the ASM to capture e.g. Illegal URL count will go up on the traffic learning screen.
Now, Although the count of such occurance will be 1 (host IP of the scanner running)
, we can now accept these urls in the security policy.
Does this make sense ? pls advise.
regards
Nik
3 Replies
hoolioCirrostratus
Hi Nik,
I generally don't define every URL for a web app in a policy. I define the filetypes and lock down the metacharacters for URLs and the rest of the charsets. I then define explicit URLs if there are is a character set violation for a URL. If there are odd metacharacters in the URLs, then a crawl of the site might help. Or if you have a lot of filetypes it would help to run the crawler.
Are you able to put the policy in transparent mode on a production virtual server that does receive traffic?
Aaron
Nik_67256
Aaron,
Just to understand you clearly, Does this mean
1) We generally do not create a wildcard parameter "*" for allowed URLs and try to learn the URLs accessed on the learning screen. (since crawlers would do just the same)
Based on your suggested approach , is it ok then not to learn from the metacharacters on parameters (policy-->blocking-->settings) , as it may not be very useful:
2) Illegal meta characters in parameter name
3) Illegal meta characters in parameter value
Specific Yes/No answers to 1),2) & 3) will save me a lot of time & effort.
Yes, the policy is in transparent mode on production. Regards,
regards,
Nik- hoolioHi Nik,
I personally like defining a * URL and only define specific URLs if they trigger meta-character or attack signature violations. So for 1) I would say no, do not define every URL for a web application in the security policy.
I highly suggest enforcing meta-characters for each of the four character sets (header, URL, parameter name, parameter value). For 2) and 3) I suggest you do use learning or other tools to keep a tight list of globally allowed meta-characters for parameter names and values and make only make specific exceptions. For parameter names and values, I try to make exceptions by defining a specific global parameter and relax the character set there.
For example, on the * global parameter, only allow "A-Z a-z 0-9 Space ! " ( ) + , - . @ [ ] _ { } $ ? = :" for parameter names. For parameter values, only allow "A-Z a-z 0-9 Space CR LF ! " ( ) + , - . @ [ ] _ { } $ ? = : ". Then if for example the web app requires use of meta-characters in this list for the password parameter "' % < > &; `", create a global parameter named password and allow the meta-characters only on that parameter value.
I added some of this info on what I use for character sets to a recent post with you:
https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/52/aft/2161357/showtab/groupforums/Default.aspx2238613
Aaron
