On 2/18/11 9:52 AM, "Lucas Ferreira" <[email protected]> wrote:
>Hello Ryan, > >after reading your blog post, I still have some doubts: > >How does the profiling work with regard to restarting the web server? >Are the collections saved to disk? Yes - the data is saved to persistent storage files on disk. This would keep the data across Apache restarts. > >How can the administrator restart the profiling process? Is it >possible to selectively restart profiling based on host, URL or other >application identifier? Great question. We actually were talking a bit about some options for profile management. One option that we are thinking of would be to use dynamic updates based on access requests from "trusted" clients. Take a look at the previous blog post on GeoIP data where we talk about dynamic updates - http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geoloc ation-data.html The idea would be that if you wanted to remove/relearn a profile for a URL, you could have an authorized client send a specific request to that URL. Based on the source IP, UA + Parameter (maybe ?relearn_profile=true), then the saved resource collection data for that URL would be removed and the relearning would commence. There are some other ideas that we we need to test which could possibly include tracking an increase in alerts across multiple clients as this might indicate an application change and could initiate an auto-relearn. This is something that we are planning to add in future versions. Please keep the comments coming! We want people to test so that we can improve the capabilities. Cheers, Ryan > >Thanks, > >Lucas > >On Thu, Feb 17, 2011 at 16:27, Ryan Barnett <[email protected]> >wrote: >> Hello everyone, >> This email will most likely come as very welcomed news to most of you. >>We have just released a ruleset to the OWASP CRS that implements a basic >>framework for real-time application profiling - >> >>http://blog.spiderlabs.com/2011/02/modsecurity-advanced-topic-of-the-week >>-real-time-application-profiling.html >> >> This initial version of the rules has the ability to profile and >>enforce the following on a per-resource basis: >> >> * Request Method(s) >> * Number of Parameters >> * Parameter Names >> * Parameter Length Ranges >> * Parameter Types - numeric or alpha >> >> Please test out this ruleset and provide feedback on the OWASP CRS >>mail-list. >> >> Cheers, >> Ryan >> >> >> ________________________________ >> This transmission may contain information that is privileged, >>confidential, and/or exempt from disclosure under applicable law. If you >>are not the intended recipient, you are hereby notified that any >>disclosure, copying, distribution, or use of the information contained >>herein (including any reliance thereon) is STRICTLY PROHIBITED. If you >>received this transmission in error, please immediately contact the >>sender and destroy the material in its entirety, whether in electronic >>or hard copy format. >> >> _______________________________________________ >> Owasp-modsecurity-core-rule-set mailing list >> [email protected] >> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >> > > > >-- >Homo sapiens non urinat in ventum. > _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
