AppSensor Guide Application-Specific Real-Time Attack Detection & Response Version 48 (Draft)
Chapter 26 : Leveraging a Web Application Firewall
Download 11.95 Mb.
|
- Navigate this page:
- Description
- AppSensor scope
- Source code
- Implementation
- Related implementations
Chapter 26 : Leveraging a Web Application FirewallIntroductionOWASP ModSecurity Core Rule Set is a free set of generic application protection rules for the open source ModSecurity35 web application firewall (WAF). A number of rules implement AppSensor behavior, albeit separate from the application’s source code. Where there is no permission or ability to modify an application, the use of a WAF can accommodate some AppSensor-like behavior, and may in fact be the only available way to apply the concept to some legacy or commercial applications where the source code cannot be altered. WAFs have other valuable uses too, and may already exist in the application’s environment. This demonstration implementation does not form part of the core development efforts within the OWASP AppSensor Project. Instead, please refer to the actively maintained and supported OWASP ModSecurity Core Rule Set Project36,124 which has its own mailing list125. DescriptionModSecurity can be deployed embedded within the existing web server infrastructure or as a reverse proxy server on the network. The latter has been used in this example so that it can protect multiple back-end web servers. In this pure WAF implementation, all AppSensor-like functionality in undertaken within the WAF, and none in the application itself. Schematic Arrangement of Example Leveraging a Web Application Firewall 
AuditViewer126 is used to browse the event data, which are stored as logs on the file system (indicated in the above diagram as accessible to both the event manager and the reporting client). In this implementation, only the AppSensor-relevant rules (see below) were enabled, with all other rules disabled or removed. This was so the effect of AppSensor-like functionality alone can be assessed without having to consider the effect of other WAF capabilities. AppSensor scopeThe following detection points have existing rules (some multiple especially for IE1) in the Core Rule Set (CRS) at the time of writing: List of Detection Point Categories Implemented in ModSecurity Core Rule Set
The rules are spread across the “base” rules and also the “experimental” ones included in the CRS. Application-specific custom ModSecurity rules can be written to extend these detection points much further, and this is strongly recommended. However, some other AppSensor detection points may be difficult to implement since the WAF will not have the same access to user information and context the application has. Many more ModSecurity ideas can be found in the recent book “Web Application Defender's Cookbook: Battling Hackers and Protecting Users”127. All AppSensor example response actions are potentially possible using ModSecurity: List of Response Categories Implemented in ModSecurity Core Rule Set
Configuration of ModSecurity is required to execute the responses based on individual events or aggregated scoring. Source codeModSecurity, the OWASP ModSecurity CRS and AuditViewer respectively can be downloaded at: http://www.modsecurity.org/download/ https://github.com/SpiderLabs/owasp-modsecurity-crs http://www.jwall.org/projects/org.jwall.web.audit/source-repository.html ImplementationFollow the instructions included within the downloads, but also review the information available at: http://www.modsecurity.org/documentation/ http://blog.spiderlabs.com/modsecurity/ https://secure.jwall.org/web/audit/viewer.jsp ConsiderationsModSecurity is available for Apache, IIS and Nginx - see the download page listed above. As mentioned above, to assess this method of implementation, it is best to disable or remove other rules in the CRS, so the AppSensor-relevant aspects can be isolated. The included rules should be modified and extended to be more specific to the application(s) being protected. Related implementationsOther WAFs may not be as configurable as the example here – AppSensor cannot be implemented satisfactorily with only a generic negative security model. A small number of more advanced load balancers that understand the HTTP protocol could support some similar functionality. But note the comments in Chapter 2 : Protection Measures - Comparison with . A web application firewall can also be used as a: Reputational detection point, for example to send possible attack information to the defended application (detection point type RP2) using HTTP request headers or other signaling Response action on behalf of the defended application, for example to perform increased logging (ASR-A), to proxy user requests to another system (ASR-N), to disable functions (ASR-I), to disable the application (ASR-L) and to collect data from a user (ASR-M). Similarly other application firewalls (e.g. database) could be used for some detection points and response actions. Directory: images -> archive images -> World-renowned vocal ensemble sweet honey in the rock images -> Peoples Voice Café History archive -> J. Welles Henderson Archives and Library archive -> The Heartbeat Beacon Abstract archive -> E9-1-1 Heartbeat Abstract archive -> HL7 Mobile Health Application Functional Framework; Consumer mhaFF, Release 1 (pi id: 1182) archive -> Opensfs benchmarking Working Group I/o survey Report archive -> Opensfs benchmarking Working Group I/o survey Report archive -> Need a computer and can't afford one? Download 11.95 Mb. Share with your friends:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||