From jyri@sac.sfbay.sun.com Thu Feb 7 20:39:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m184dsRS026416 for ; Thu, 7 Feb 2008 20:39:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m184dna7023475; Fri, 8 Feb 2008 04:39:53 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVW00F03KYGHA00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 20:39:52 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW006L2KYGSW90@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 20:39:52 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m184do5c019508; Thu, 07 Feb 2008 20:39:50 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m184Ooqg026312; Thu, 07 Feb 2008 20:24:50 -0800 (PST) Received: (from jyri@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m184Oo56026308; Thu, 07 Feb 2008 20:24:50 -0800 (PST) Date: Thu, 07 Feb 2008 20:24:50 -0800 (PST) From: Jyri Virkki Subject: Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] To: PSARC-ext@sun.com Cc: Rahul.G.Nair@sun.com, webstack-discuss@opensolaris.org Message-id: <200802080424.m184Oo56026308@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5926 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Additional Apache2 Modules 1.2. Name of Document Author/Supplier: Author: Rahul Nair 1.3 Date of This Document: 07 February, 2008 4. Technical Description Additional Apache2 Modules 7 February 2008 1. Summary and motivation 1.1. Introduction This project delivers Apache modules mod_jk, mod_fcgid, mod_security and mod_dtrace to the Apache2 (PSARC/2007/586) in OpenSolaris. Modules allow Apache to integrate and provide functionality during runtime that were not available during compile time. This project integrates the most recent stable releases of mod_jk[1] tomcat-connectors-1.2.25, mod_fcgid[2] 2.2, mod_security[3] 2.1.3 and mod_dtrace[4] 0.3a This case seeks Minor Release Binding. 2. Technical issues 2.1. Key objects /usr/apache2/2.2/libexec/mod_jk.so /usr/apache2/2.2/libexec/mod_fcgid.so /usr/apache2/2.2/libexec/mod_security2.so /usr/apache2/2.2/libexec/mod_dtrace.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_jk.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_fcgid.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_security2.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_dtrace.so 2.2 Versioning mod_jk, mod_fcgid, mod_security and mod_dtrace have a single active release. (There was a module named mod_jk2 which was deprecated. It was not the successor to mod_jk.) It is not possible to query the modules to find out their versions. The only way to do that is to look at the package description for the package including it. 2.2 Directory Naming and Structure This project delivers the shared libraries of 32 bit and 64 bit into /usr/apache2/2.2/libexec and /usr/apache2/2.2/libexec/${ISAINFO}/ directories of apache. This is in keeping with the approach taken by the Apache2 integration project for OpenSolaris (PSARC/2007/586). 3. Documentation The modules mod_jk, mod_fcgid, mod_security and mod_dtrace do not install documentation into apache though they come with some documentation in their source. The recommended way to access their documentation is to look at their websites (mod_fcgid[5] ,mod_jk[6], mod_security[7] and mod_dtrace[8] ). A list of external apache modules that has been added and their corresponding sites will be part of the release document. 4. Packaging and Delivery The modules will be delivered under the cluster SUNWCapch22m. This cluster consists of SUNWapch22m-fcgid, SUNWapch22m-jk, SUNWapch22m-security and SUNWapch22m-dtrace respectively. 5. Interfaces 5.1. Interface Stability The interface stability of most of these modules is Volatile as these are controlled by external organisations over which Sun has no control. The specific researches regarding stability of each module are captured below. 5.1.1 mod_jk The mod_jk developers will try to keep the releases of 1.2.X line compatible with each other. But this is not guaranteed in case of new features that may need to be retracted due to some bugs or vulnerabilities. 5.1.2 mod_security The mod_security developers will keep the compatibility between releases of the same major number. (ie 2.y.z with 2 being the major number.) But there is no guarantee that meaning of a rule set (configuration directive) would be exactly the same across any two releases. 5.1.3 mod_fcgid There were no commitments from mod_fcgid developers in this regard. (The mod_fcgid does not seem to have broken the configuration compatibility with any of its earlier releases yet [9] but is in very active development) 5.1.4 mod_dtrace The mod_dtrace has had just two releases (0.2a and 0.3a) and is possibly very unstable. 5.2. Imported Interfaces These Apache modules imports interfaces from NAME STABILITY NOTES ------------------------------------------------------------ Apache2 Uncommitted PSARC/2007/586/ LDAP Evolving PSARC/2000/362/ PCRE Uncommitted PSARC/2007/164/ SUNWlxml Committed PSARC/2001/175/ Dtrace Uncommitted PSARC/2001/466/ 5.3. Exported Interfaces NAME STABILITY --------------------------------------------------------------- /usr/apache2/2.2/libexec/mod_jk.so Volatile /usr/apache2/2.2/libexec/mod_fcgid.so Volatile /usr/apache2/2.2/libexec/mod_security.so Uncommitted /usr/apache2/2.2/libexec/mod_dtrace.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_jk.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_fcgid.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_security.so Uncommitted /usr/apache2/2.2/libexec/${ISAINFO}/mod_dtrace.so Volatile 6. References 1. http://fastcgi.coremail.cn/ 2. http://tomcat.apache.org/connectors-doc/ 3. http://www.modsecurity.org/projects/modsecurity/apache/index.html 4. http://prefetch.net/projects/apache_modtrace/index.html 5. http://fastcgi.coremail.cn/doc.htm 6. http://tomcat.apache.org/connectors-doc/generic_howto/quick.html 7. http://www.modsecurity.org/documentation/index.html 8. http://prefetch.net/projects/apache_modtrace/mod_dtrace.c 9. http://fastcgi.coremail.cn/download.htm 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From John.Plocher@sun.com Thu Feb 7 20:58:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m184wCpq026719 for ; Thu, 7 Feb 2008 20:58:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m184w72n029245 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 04:58:12 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVW0080FLSZJA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 21:58:11 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW00FN2LSZFT70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 21:58:11 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m184wBHR012578 for ; Thu, 07 Feb 2008 20:58:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVW00401LODU800@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 20:58:11 -0800 (PST) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVW002XELSYYTC0@fe-sfbay-10.sun.com>; Thu, 07 Feb 2008 20:58:11 -0800 (PST) Date: Thu, 07 Feb 2008 20:58:10 -0800 From: John Plocher Subject: Re: Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <200802080424.m184Oo56026308@sac.sfbay.sun.com> Sender: John.Plocher@sun.com To: Jyri Virkki Cc: PSARC-ext@sun.com, Rahul.G.Nair@sun.com, webstack-discuss@opensolaris.org Message-id: <47ABE162.1070906@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 633 Jyri Virkki wrote: > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Additional Apache2 Modules Other than missing descriptions of what these modules are used for ("mod_jk is used to connect apache2 to the tomcat web container/servlet environment..."), this is a very nice example of the type and level of ARC documentation we need for projects that bring FOSS stuff into the system. I particulary like the characterizations of the upstream community's own stability expectations. Thanks, Jyri! -John From jyri@buye.red.iplanet.com Thu Feb 7 21:35:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m185ZdMk026896 for ; Thu, 7 Feb 2008 21:35:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m185ZZW5014193; Fri, 8 Feb 2008 05:35:37 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVW00I03NJBAZ00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 21:35:35 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW0060UNJBSWD0@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 21:35:35 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m185S5PF007765; Thu, 07 Feb 2008 21:28:05 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m185S5J1007764; Thu, 07 Feb 2008 21:28:05 -0800 (PST) Date: Thu, 07 Feb 2008 21:28:05 -0800 From: Jyri Virkki Subject: Re: Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <47ABE162.1070906@Sun.Com> To: John Plocher Cc: PSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <20080208052805.GW6789@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <47ABE162.1070906@Sun.Com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 764 John Plocher wrote: > > Other than missing descriptions of what these modules are > used for ("mod_jk is used to connect apache2 to the tomcat > web container/servlet environment..."), this is a very nice > example of the type and level of ARC documentation we need > for projects that bring FOSS stuff into the system. > > I particulary like the characterizations of the upstream > community's own stability expectations. > > Thanks, Jyri! I'm sponsoring the case for Rahul (timeout set to 2/15/2008). This case had a fair amount of pre-review on the webstack community list: http://www.opensolaris.org/jive/thread.jspa?threadID=47744 http://www.opensolaris.org/jive/thread.jspa?threadID=41624 -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From danek.duvall@sun.com Fri Feb 8 09:12:10 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m18HC97F012932 for ; Fri, 8 Feb 2008 09:12:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m18HBauD014445 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Feb 2008 01:12:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVX00257JS8YE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:12:08 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVX001AAJS5Y1D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:12:05 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m18HC3aG018641; Fri, 08 Feb 2008 09:12:03 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m18HC3GY005555; Fri, 08 Feb 2008 09:12:03 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m18HC3qt005554; Fri, 08 Feb 2008 09:12:03 -0800 (PST) Date: Fri, 08 Feb 2008 09:12:03 -0800 From: Danek Duvall Subject: Re: Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <200802080424.m184Oo56026308@sac.sfbay.sun.com> To: Jyri Virkki Cc: PSARC-ext@sun.com, Rahul.G.Nair@sun.com, webstack-discuss@opensolaris.org Message-id: <20080208171203.GQ22027@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 1253 On Thu, Feb 07, 2008 at 08:24:50PM -0800, Jyri Virkki wrote: > 5.3. Exported Interfaces > > NAME STABILITY > --------------------------------------------------------------- > /usr/apache2/2.2/libexec/mod_jk.so Volatile > /usr/apache2/2.2/libexec/mod_fcgid.so Volatile > /usr/apache2/2.2/libexec/mod_security.so Uncommitted > /usr/apache2/2.2/libexec/mod_dtrace.so Volatile So what are the interfaces this project is actually exporting? That is, for instance, what is Volatile about "/usr/apache2/2.2/libexec/mod_jk.so"? Is it the pathname? The pathname seems unlikely to change -- either it stays the same pretty much forever or we decide to yank it. Doesn't seem particularly Volatile. Is it behavior? Is it the set of configuration directives it supports? Something else? A description of what each actually does would also be nice. The fact that it was discussed at length somewhere else is nice, but most of us aren't on those other lists, so a summary in the proposal of, y'know, what the project actually *does* would be useful to the majority of ARC members reviewing the proposal. :) Thanks, Danek From brectanu@gmail.com Fri Feb 8 09:26:46 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m18HQkHl013202 for ; Fri, 8 Feb 2008 09:26:46 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m18HQkxJ003206 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 09:26:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVX00E03KGMBO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:26:46 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVX00DERKGLZO10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:26:46 -0800 (PST) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m18HMZd0026044 for ; Fri, 08 Feb 2008 17:26:45 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay42i.sun.com with ESMTP id BT-MMP-1044767 for PSARC-ext@sun.com; Fri, 08 Feb 2008 17:26:45 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-1181443 for PSARC-ext@sun.com; Fri, 08 Feb 2008 17:26:45 +0000 (Z) Received: from fg-out-1718.google.com ([72.14.220.155] [72.14.220.155]) by relay4i.sun.com with ESMTP id BT-MMP-19439642 for PSARC-ext@sun.com; Fri, 08 Feb 2008 17:26:44 +0000 (Z) Received: by fg-out-1718.google.com with SMTP id e12so2812003fga.6 for ; Fri, 08 Feb 2008 09:26:44 -0800 (PST) Received: by 10.82.118.2 with SMTP id q2mr23472201buc.23.1202491603668; Fri, 08 Feb 2008 09:26:43 -0800 (PST) Received: by 10.82.185.8 with HTTP; Fri, 08 Feb 2008 09:26:43 -0800 (PST) Date: Fri, 08 Feb 2008 09:26:43 -0800 From: Brian Rectanus Subject: Re: [webstack-discuss] Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <20080208171203.GQ22027@zruty.sfbay.sun.com> To: Jyri Virkki Cc: Danek Duvall , PSARC-ext@sun.com, webstack-discuss@opensolaris.org, Rahul.G.Nair@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=P8WQvP/UMbBklBFpnuhTjMPASFJ0+N68dAxzQaIa5ZU=; b=W8MJD6o6XhO85rq5Rzft6cJdGqxa56IuJ5Xiplp15FOqzGl7Ws2d4gskgkj9zM+bnoq/5SXOnQa9ns+V75MhK9SPRIraC2HpaQ6u3dJbnGKKggwdCPaJ51H9nLvpZEyzzqvWVS3GB+hAAIeqho060hDlLQHvgZoi/pFUSCLGsr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hnorpQQyVkyCKUPkeV38iv831ApojlOrx4WognfT8K+N1dwVjPb+Uuy5HWcAcgHHXGK34w75H300KncC/d9cZ2Cm4UaNwXrvhH6axqBKNHYNqtzjtyNyCyrhg1931zeeEkzCTdL1L8/uWPES8cL13kmn3YWj67oc7Pj/29gW0DM= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.265sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <20080208171203.GQ22027@zruty.sfbay.sun.com> Status: RO Content-Length: 2681 On Feb 8, 2008 9:12 AM, Danek Duvall wrote: > On Thu, Feb 07, 2008 at 08:24:50PM -0800, Jyri Virkki wrote: > > > 5.3. Exported Interfaces > > > > NAME STABILITY > > --------------------------------------------------------------- > > /usr/apache2/2.2/libexec/mod_jk.so Volatile > > /usr/apache2/2.2/libexec/mod_fcgid.so Volatile > > /usr/apache2/2.2/libexec/mod_security.so Uncommitted > > /usr/apache2/2.2/libexec/mod_dtrace.so Volatile > > So what are the interfaces this project is actually exporting? That is, > for instance, what is Volatile about "/usr/apache2/2.2/libexec/mod_jk.so"? > Is it the pathname? The pathname seems unlikely to change -- either it > stays the same pretty much forever or we decide to yank it. Doesn't seem > particularly Volatile. > > Is it behavior? > > Is it the set of configuration directives it supports? > > Something else? > > A description of what each actually does would also be nice. The fact that > it was discussed at length somewhere else is nice, but most of us aren't on > those other lists, so a summary in the proposal of, y'know, what the > project actually *does* would be useful to the majority of ARC members > reviewing the proposal. :) > > Thanks, > Danek I was curious on this as well. What does the Uncommited mean for mod_security? Also the filename is normally compiled as mod_security2.so (mod_security.so being the 1.x.y version). Additionally, "the most recent stable releases of" for mod_security is no longer 2.1.3. It is 2.1.5, which fixes a number of issues that you may want included... 10 Jan 2008 - 2.1.5 ------------------- * Updated included Core Ruleset to version 1.5.1. * Phase 5 rules can now be removed via SecRuleRemoveBy* directives. * Fixed issue where only the first phase 5 rule would run when the request was intercepted in an earlier phase. * Fixed configuration parsing so that disruptive actions, meta actions and phases are not allowed in a chained rule (as originally intended). * Fixed t:escapeSeqDecode to better follow ANSI C escapes. 27 Nov 2007 - 2.1.4 ------------------- * Updated included Core Ruleset to version 1.5 and noted in the docs that XML support is required to use the rules without modification. * Fixed an evasion FP, mistaking a multipart non-boundary for a boundary. * Fixed multiple warnings on Solaris and/or 64bit builds. * Do not process subrequests in phase 2-4, but do hand off the request data. * Fixed a blocking FP in the multipart parser, which affected Safari. thanks, -B From Rahul.G.Nair@sun.com Mon Feb 11 07:09:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BF9sp5021023 for ; Mon, 11 Feb 2008 07:09:54 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BF9e7p001101 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Feb 2008 23:09:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW200405Y4A6X00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Feb 2008 08:09:46 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW200LC0Y45UZF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Feb 2008 08:09:44 -0700 (MST) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1BF9lVY009897 for ; Mon, 11 Feb 2008 15:09:47 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JW200M01Y3XFO00@mail-apac.sun.com> (original mail from Rahul.G.Nair@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Feb 2008 23:09:40 +0800 (SGT) Received: from localhost ([129.158.224.78]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JW200IP5Y3YP400@mail-apac.sun.com>; Mon, 11 Feb 2008 23:09:40 +0800 (SGT) Date: Mon, 11 Feb 2008 20:29:32 +0530 From: rahul Subject: Re: [webstack-discuss] Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: Sender: Rahul.G.Nair@sun.com To: Brian Rectanus Cc: Jyri Virkki , PSARC-ext@sun.com, webstack-discuss@opensolaris.org, Danek Duvall Message-id: <20080211145931.GY4494@vayavyam.India.Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ)" X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <20080208171203.GQ22027@zruty.sfbay.sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 273099 --Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline I would like to update the arc case with the following updates. 1) Include a blurb for each of the modules explaining what they do 2) Add an addendum explaining briefly the interfaces (In this case the configuration directives they support) 3) Provide a complete reference for these configuration directives for each of the modules as supplied by the respective upstream communities. 4) Update mod_security to 2.1.5 rahul --Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ) Content-type: text/plain; NAME=arc.modules; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=arc.modules Additional Apache Modules 13 December 2007 1. Summary and motivation 1.1. Introduction This FastTrack delivers Apache modules mod_jk, mod_fcgid, mod_security and mod_dtrace to the Apache2 in OpenSolaris. Modules allow Apache to integrate and provide functionality during runtime that were not available during compile time. 1.1.1 mod_security From modsecurity.org[3] "ModSecurity is a web application firewall (WAF). With over 70% of all attacks now carried out over the web application level, organisations need every help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure." 1.1.2 mod_jk From tomcat.apache.org "mod_jk is a replacement to the elderly mod_jserv. It is a completely new Tomcat-Apache plug-in that handles the communication between Tomcat and Apache." 1.1.3 mod_fcgid From fastcgi.coremail.cn "It is a binary compatibility alternative to Apache module mod_fastcgi." mod_fcgid is an apache module that allows CGIs to be deployed on apache that make use of the FastCGI mechanism. From www.fastcgi.com "FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs." 1.1.4 mod_dtrace From prefetch.net "The Apache DTrace module (mod_dtrace) utilizes the hook framework to add DTrace probes to the Apache web server. These probes can be used to observe and correlate web server and system behavior, and allow easy access to numerous pieces of realtime Apache data. This project integrates the most recent stable releases of mod_jk[1] tomcat-connectors-1.2.25, mod_fcgid[2] 2.2, mod_security[3] 2.1.5 and mod_dtrace[4] 0.3a This case seeks Minor Release Binding. 2. Technical issues 2.1. Key objects /usr/apache2/2.2/libexec/mod_jk.so /usr/apache2/2.2/libexec/mod_fcgid.so /usr/apache2/2.2/libexec/mod_security2.so /usr/apache2/2.2/libexec/mod_dtrace.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_jk.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_fcgid.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_security2.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_dtrace.so 2.2 Versioning mod_jk, mod_fcgid, mod_security and mod_dtrace have a single active release. (There was a module named mod_jk2 which was deprecated. It was not the successor to mod_jk.) It is not possible to query the modules to find out their versions. The only way to do that is to look at the package description for the package including it. 2.2 Directory Naming and Structure This project delivers the shared libraries of 32 bit and 64 bit into /usr/apache2/2.2/libexec and /usr/apache2/2.2/libexec/${ISAINFO}/ directories of apache. This is in keeping with the approach taken by the Apache2 integration project for OpenSolaris (PSARC/2007/586). 3. Documentation The modules mod_jk, mod_fcgid, mod_security and mod_dtrace do not install documentation into apache though they come with some documentation in their source. The recommended way to access their documentation is to look at their websites (mod_fcgid[5] ,mod_jk[6], mod_security[7] and mod_dtrace[8] ). A list of external apache modules that has been added and their corresponding sites will be part of the release document. 4. Packaging and Delivery The modules will be delivered under the cluster SUNWCapch22m. This cluster consists of SUNWapch22m-fcgid, SUNWapch22m-jk, SUNWapch22m-security and SUNWapch22m-dtrace respectively. 5. Interfaces 5.1. Interface Stability The interface stability of each component is described as Volatile as these are controled by external organizations over which Sun has no control. The specific researches regarding stability of each module are captured below. 5.1.1 mod_jk The mod_jk developers will try to keep the releases of 1.2.X line compatible with each other. But this is not guaranteed in case of new features that may need to be retracted due to some bugs or vulnerabilities. The interface of mod_jk (it configuration) is presented as Addendum 2. The complete list of directives and their explanation as supplied by tomcat.apache.org is available as mod_jk_interface.html. 5.1.2 mod_security The mod_security developers will keep the compatibility between releases of the same major number. (ie 2.y.z with 2 being the major number.) But there is no guarantee that meaning of a rule set (configuration directive) would be exactly the same across any two releases. The interface of mod_security (its configuration) is presented in Addendum 1. The complete list of dirctives and their explanation (as provided by modsecurity.org) is available as mod_security_interface.html. 5.1.3 mod_fcgid There were no commitments from mod_fcgid developers in this regard. (The mod_fcgid does not seem to have broken the configuration compatibility with any of its earlier releases yet [9] but is in very active developement). The interface of mod_fcgid (its configuration options) is presented as Addendum 3. The complete list of directives and their explanation as provided by fastcgi.coremail.cn is available as mod_fcgid_interface.html 5.1.4 mod_dtrace The mod_dtrace has had just two releases (0.2a and 0.3a) and is possibly very unstable. The interface of dtrace module consists of the apache functions it is hooking into. This is provided as Addendum 4. 5.2. Imported Interfaces These Apache modules imports interfaces from NAME STABILITY NOTES Apache2 Uncommitted PSARC/2007/586/ LDAP Evolving PSARC/2000/362/ PCRE Uncommitted PSARC/2007/164/ SUNWlxml Committed PSARC/2001/175/ Dtrace Uncommitted PSARC/2001/466/ 5.3. Exported Interfaces NAME STABILITY /usr/apache2/2.2/libexec/mod_jk.so Volatile /usr/apache2/2.2/libexec/mod_fcgid.so Volatile /usr/apache2/2.2/libexec/mod_security.so Uncommitted /usr/apache2/2.2/libexec/mod_dtrace.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_jk.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_fcgid.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_security.so Uncommitted /usr/apache2/2.2/libexec/${ISAINFO}/mod_dtrace.so Volatile 6. References 1. http://fastcgi.coremail.cn/ 2. http://tomcat.apache.org/connectors-doc/ 3. http://www.modsecurity.org/projects/modsecurity/apache/index.html 4. http://prefetch.net/projects/apache_modtrace/index.html 5. http://fastcgi.coremail.cn/doc.htm 6. http://tomcat.apache.org/connectors-doc/generic_howto/quick.html 7. http://www.modsecurity.org/documentation/index.html 8. http://prefetch.net/projects/apache_modtrace/mod_dtrace.c 9. http://fastcgi.coremail.cn/download.htm Addendum 1 mod_security interfaces: It includes the configuration directives, exposed variables, library functions (transformation functions), operators and actions to be taken on the URI Configuration Directives SecAction SecArgumentSeparator SecAuditEngine SecAuditLog SecAuditLog2 SecAuditLogParts SecAuditLogRelevantStatus SecAuditLogStorageDir SecAuditLogType SecChrootDir SecCookieFormat SecDataDir SecDebugLog SecDebugLogLevel SecDefaultAction SecGuardianLog SecRequestBodyAccess SecRequestBodyLimit SecRequestBodyInMemoryLimit SecResponseBodyLimit SecResponseBodyMimeType SecResponseBodyMimeTypesClear SecResponseBodyAccess SecRule SecRuleInheritance SecRuleEngine SecRuleRemoveById SecRuleRemoveByMsg SecServerSignature SecTmpDir SecUploadDir SecUploadKeepFiles SecWebAppId Variables ARGS ARGS_COMBINED_SIZE ARGS_NAMES AUTH_TYPE ENV FILES FILES_COMBINED_SIZE FILES_NAMES FILES_SIZES FILES_TMPNAMES HTTP_ MULTIPART_CRLF_LF_LINES MULTIPART_STRICT_ERROR MULTIPART_UNMATCHED_BOUNDARY PATH_INFO QUERY_STRING REMOTE_ADDR REMOTE_HOST REMOTE_PORT REMOTE_USER REQBODY_PROCESSOR REQBODY_PROCESSOR_ERROR REQBODY_PROCESSOR_ERROR_MSG REQUEST_BASENAME REQUEST_BODY REQUEST_COOKIES REQUEST_COOKIES_NAMES REQUEST_FILENAME REQUEST_HEADERS REQUEST_HEADERS_NAMES REQUEST_LINE REQUEST_METHOD REQUEST_PROTOCOL REQUEST_URI REQUEST_URI_RAW RESPONSE_BODY RESPONSE_HEADERS RESPONSE_HEADERS_NAMES RESPONSE_PROTOCOL RESPONSE_STATUS RULE SCRIPT_BASENAME SCRIPT_FILENAME SCRIPT_GID SCRIPT_GROUPNAME SCRIPT_MODE SCRIPT_UID SCRIPT_USERNAME SERVER_ADDR SERVER_NAME SERVER_PORT SESSION SESSIONID TIME TIME_DAY TIME_EPOCH TIME_HOUR TIME_MIN TIME_MON TIME_SEC TIME_WDAY TIME_YEAR TX USERID WEBAPPID WEBSERVER_ERROR_LOG XML Transformation functions base64Decode base64Encode compressWhitespace escapeSeqDecode hexDecode hexEncode htmlEntityDecode lowercase md5 none normalisePath normalisePathWin removeNulls removeWhitespace replaceComments replaceNulls urlDecode urlDecodeUni urlEncode sha1 Actions allow auditlog capture chain ctl deny deprecatevar drop exec expirevar id initcol log msg multiMatch noauditlog nolog pass pause phase proxy redirect rev sanitiseArg sanitiseMatched sanitiseRequestHeader sanitiseResponseHeader severity setuid setsid setenv setvar skip status t xmlns Operators eq ge gt inspectFile le lt rbl rx validateByteRange validateDTD validateSchema validateUrlEncoding validateUtf8Encoding Addendum 2: Apache directives exposed by mod_jk JkWorkersFile JkWorkerProperty JkShmFile JkShmSize JkMountFile JkMountFileReload JkMount JkUnMount JkAutoAlias JkMountCopy JkWorkerIndicator JkLogFile JkLogLevel JkLogStampFormat JkRequestLogFormat JkExtractSSL JkHTTPSIndicator JkCERTSIndicator JkCIPHERIndicator JkCERTCHAINPrefix JkSESSIONIndicator JkKEYSIZEIndicator JkOptions JkEnvVar JkStripSession Addendum 3: Apache directives exposed by mod_fcgid IdleTimeout IdleScanInterval BusyTimeout BusyScanInterval ErrorScanInterval ZombieScanInterval ProcessLifeTime SocketPath SpawnScoreUpLimit SpawnScore TerminationScore MaxProcessCount DefaultMaxClassProcessCount DefaultMinClassProcessCount DefaultInitEnv IPCConnectTimeout IPCCommTimeout OutputBufferSize PHP_Fix_Pathinfo_Enable Addendum 4: Apache methods hooked into by mod_dtrace: apache_receive_request apache_log_request apache_create_child apache_accept_connection apache_check_user apache_check_access apache_check_authorization dtrace_register_hooks --Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ) Content-type: text/html; NAME=mod_fcgid_interface.html; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=mod_fcgid_interface.html

IdleTimeout n (300 seconds)

An idle fastcgi application will be terminated after IdleTimeout seconds.

IdleScanInterval n (120 seconds)

The scan interval for idle fastcgi applications.

BusyTimeout n (300 seconds)

a fastcgi application will be terminated if handing a single request longer than busy timeout.

BusyScanInterval n (120 seconds)

The scan interval for busy timeout fastcgi applications.

ErrorScanInterval n (3 seconds)

The scan interval for exit pending fastcgi applications. fastcgi applications will be terminated within this scanning.

ZombieScanInterval n (3 seconds)

The scan interval for zombie process. 

ProcessLifeTime n (3600 seconds)

A fastcgi application will be terminated if lifetime expired, even no error is detected.

SocketPath path (logs/fcgidsock)

The directory to put the UNIX domain socket. (UNIX only)

SpawnScoreUpLimit n (10)

The spawn-speed control score up water limit. Score increases while a process is spawned or terminated, and decreases as time progresses; while the score is higher than SpawnScoreUpLimit, the spawning will be held for a while. The higher this number is, the higher speed of the spawning can be.

SpawnScore n (1)

The weight of spawning.  This weight will be plused to the spawn-control score on every spawn. The higher this number is, the lower speed of spawning can be.

TerminationScore n (2)

The weight of termination. This weight will be plused to the score while fastcgi process terminates. The higher this number is, the lower speed of spawning can be.

MaxProcessCount n (1000)

The max count of total fastcgi process count.

DefaultMaxClassProcessCount n (100)

The maximum number of fastcgi application instances allowed to run for any one fastcgi application. 

DefaultMinClassProcessCount n (3)

The minimum number of fastcgi application instances for any one fastcgi application. 

DefaultInitEnv  env_name env_value

The default environment variables before a fastcgi application is spawned. You can set this configuration more than once.

IPCConnectTimeout n (3 seconds)

The connect timeout to a fastcgi application. 

IPCCommTimeout n (20 seconds)

The communication timeout to a fastcgi application. Please increase this value if your CGI have a slow initialization or slow respond.

OutputBufferSize n (64k bytes)

CGI output cache buffer size.

PHP_Fix_Pathinfo_Enable n(n=0/1, default 0)

If you are using PHP and set cgi.fix_pathinfo=1 in php.ini, set PHP_Fix_Pathinfo_Enable 1. --Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ) Content-type: text/html; NAME=mod_jk_interface.html; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: attachment; filename=mod_jk_interface.html The Apache Tomcat Connector - Reference G= uide - Configuring Apache
3D"Apache

The Apache Tomcat C= onnector - Reference Guide

Configuring Apache

=3D"Printer
print-friendly
version
Configuration Directiv= es

Most of the directives are allowed once in the global part of the Apa= che httpd configuration and once in every <VirtualHost> elements. Excepti= ons from this rule are explicitely listed in the table below.

Values are inherited from the main server to the virtual hosts.=20 Since version 1.2.20 they can be overwritten in the virtual hosts. Exceptions from this rule are again explicitely listed in the table below.

Waring: If Apache httpd and Tomcat are configured to serve cont= ent from the same filing system location then care must be taken to ensure tha= t httpd is not able to serve inappropriate content such as the contents of the W= EB-INF directory or JSP source code. This could occur if the httpd Docum= entRoot overlaps with a Tomcat Host's appBase or the docBase of any Context. = It could also occur when using the httpd Alias directive with a Tomcat Host's = appBase or the docBase of any Context.

Here are the all directives supported by Apache:

DirectiveDescription
JkWorkersF= ile

The name of a worker file for the Tomcat servlet containers.
This directive is only allowed once. It must be put into the global part of the configuration.
If you don't use the JkWorkerProperty directives, then you must define your workers with a valid JkWorkersFile. There is no default value.

JkWorker= Property

Enables setting worker properties inside Apache configuration file. The syntax is the same as in the JkWorkersFile (usually workers.prope= rties). Simply prefix each line with "JkWorkerProperty" to put it directly in= to the Apache httpd config files.
This directive is allowed multiple times. It must be put into the global part of the configuration.
If you don't use the JkWorkerProperty directives, then you must define your workers with a valid JkWorkersFile. There is no default value.
This directive is available in jk1.2.7 version and later.

JkShmFil= e

Shared memory file name. Used only on unix platforms. The shm file is used by balancer and status workers.
This directive is only allowed once. It must be put into the global part of the configuration.
The default value is logs/jk-runtime-status. It is highly recommended that the shm file be placed on a local drive and not an NFS share.

The shared memory contains configuration and runtime information for = load balancer workers and their members. It is need in order that all apache childr= en

  • share the same status information for load balancing members (OK,= ERROR, ...),
  • share the information about load taken by the individual workers,=
  • share the information for the parts of the configuration, which a= re changeable during runtime by status workers.

JkShmSize

Size of the shared memory file name.
This directive is only allowed once. It must be put into the global part of the configuration.
The default value depends on the platform. It is usually less than 64= KB.

JkMountF= ile

File containing multiple mappings from a context to a Tomcat worker. It is usually called uriworkermap.properties.
For inheritance rules, see: JkMountCopy.
There is no default value.

JkMountF= ileReload

This directive configures the reload check interval in seconds. The JkMountFile is checked periodically for changes. A changed file gets reloaded automatically. If you set this directive to "0", reload checking is turned off.
The default value is 60 seconds.
This directive has been added in version 1.2.20 of mod_jk.

JkMount<= /code>

A mount point from a context to a Tomcat worker.
This directive is allowed multiple times. It is allowed in the global configuration and in VirtualHost. You can also use it inside Location with a different syntax. Inside Location, one omits the first argument (path), which gets inherited from the Location. For inheritance rules, see: JkMountCopy.

JkUnMoun= t

An exclusion mount point from a context to a Tomcat worker. All exclusion mounts are checked after mapping a request to a tomcat worker. If the request maps also to an exclusion, it will not be forwarded to tomcat, and instead be served locally.
This directive is allowed multiple times. It is allowed in the global configuration and in VirtualHost. You can also use it inside Location with a different syntax. Inside Location, one omits the first argument (path), which gets inherited from the Location. For inheritance rules, see: JkMountCopy.
This directive is available in jk1.2.7 version and later.

JkAutoAl= ias

Automatically Alias webapp context directories into the Apache document space.
Care should be taken to ensure that only static content is served via= httpd as a result of using this directive. Any static content served by httpd wi= ll bypass any security constraints defined in the application's web.xml.
For inheritance rules, see: JkMountCopy.
There is no default value.

JkMountC= opy

If this directive is set to "On" in some virtual server, the mounts from the global server will be copied to the virtual server, more precisely all mounts defined by JkMount or JkUnMount. The Mounts defined by JkMountFile and JkAutoAlias will only be inherited, if the VirtualHost does not define it's own JkMountFile or JkAutoAlias.
If you want all vhost to inherit mounts from the main server, you can set JkMountCopy to 'All' in the main server.
This directive is only allowed inside VirtualHost (with value "On") and in the global server (with value "All").
The default is Off.
Starting with version 1.2.26 you can also set it to "All" in the global virtual server. This will switch the default to On.

JkWorker= Indicator

Name of the Apache environment variable that can be used to set worke= r names in combination with SetHandler jakarta-servlet.
This directive is only allowed once per virtual server. It is allowed in the global configuration and in VirtualHost.
The default value is JK_WORKER_NAME.

JkLogFil= e

Full or server relative path to the Tomcat Connector module log file. It will also work with pipe, by using a value of the form "| ...".
The default value is logs/mod_jk.log.
Pipes are supported for Apache 1.3 only since version 1.2.16. The default value exists only since version 1.2.20.

JkLogLev= el

The Tomcat Connector module log level, can be debug, info, warn error or trace.
The default value is info.

JkLogSta= mpFormat

The Tomcat Connector module date log format, using an extended strftime syntax. This format will be used for the time stamps in the JkLogFile. The maximum length of the format is 63 characters.
Starting with version 1.2.24 of mod_jk you can also use %Q for adding milliseconds to the log and %q for microseconds.=20 These conversion specifiers are an extension to strftime. They will only work on platforms with a gettimeofday() function. You can use %Q and %q only once in the pattern and also not both together in the same pattern.
The default value is "[%a %b %d %H:%M:%S %Y] " and beginning with version 1.2.24 on platforms with a gettimeofday() function it is "[%a %b %d %H:%M:%S.%Q %Y] ".

JkReques= tLogFormat

Request log format string. See detailed description below.
There is no default value. Without defining a value, the request logg= ing is turned off.

JkExtrac= tSSL

Turns on SSL processing and information gathering by mod_jk
The default value is On.

JkHTTPSI= ndicator

Name of the Apache environment variable that contains SSL indication.
The default value is "HTTPS".

JkCERTSI= ndicator

Name of the Apache environment variable that contains SSL client cert= ificates.
The default value is "SSL_CLIENT_CERT".

JkCIPHER= Indicator

Name of the Apache environment variable that contains SSL client ciph= er.
The default value is "SSL_CIPHER".

JkCERTCH= AINPrefix

Name of the Apache environment (prefix) that contains SSL client chai= n certificates.
The default value is "SSL_CLIENT_CERT_CHAIN_".

JkSESSIO= NIndicator

Name of the Apache environment variable that contains SSL session.
The default value is "SSL_SESSION_ID".

JkKEYSIZ= EIndicator

Name of the Apache environment variable that contains SSL key size in= use.
The default value is "SSL_CIPHER_USEKEYSIZE".

JkOption= s

Set one of more options to configure the mod_jk module. See below for details about this directive.
This directive can be used multiple times per virtual server.
The default value is "ForwardURIProxy" since version 1.2.24. It was "ForwardURICompatUnparsed" in version 1.2.23 and "ForwardURICompat" until version 1.2.22.

JkEnvVar=

Adds a name and an optional default value of environment variable that should be sent to servlet-engine as a request attribute. If the default value is not given explicitely, the variable will only be send, if it is set during runtime.
This directive can be used multiple times per virtual server.
The default is empty, so no additional variables will be sent.
Empty default values are supported since version 1.2.20. Not sending variables with empty defaults and empty runtime value has been introduced in version 1.2.21.

JkStripS= ession

If this directive is set to On in some virtual server, the session IDs ;jsessionid=3D... will be removed for non matched URLs.
This directive is only allowed inside VirtualHost.
The default is Off.
This directive has been introduced in version 1.2.21.

=
Configuration Directives Types

We'll discuss here the mod_jk directive types.

Define workers<= /strong>

JkWorkersFile specify the location where mod_jk will find the = workers definitions. Take a look at Workers documentation for= detailed description. 

 =20
  JkWorkersFile     /etc/httpd/conf/workers.properties


Logging

JkLogFile specify the location where mod_jk is going to place = its log file. 

  JkLogFile     /var/log/httpd/mod_jk.log

Since JK 1.2.3 for Apache 2.0 and JK 1.2.16 for Apache 1.3 this can a= lso be used for piped logging: 

  JkLogFile     "|/usr/bin/rotatelogs /var/log/httpd/mod_jk.log 86400=
"

JkLogLevel set the log level between :

  • info log will contain standard mod_jk activity (default).
  • warn log will contain non fatal error reports.
  • error log will contain also error reports.
  • debug log will contain all information on mod_jk activity
  • trace log will contain all tracing information on mod_jk activ= ity 
 =20
  JkLogLevel    info

info should be your default selection for norma= l operations.

JkLogStampFormat will configure the date/time format found on = mod_jk log file.=20 Using the strftime() format string it's set by
default to "[%a %b %d %H:%M:%S %Y]" 

  JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "



JkRequestLogFormat will configure the format of mod_jk individ= ual request logging.=20 Request logging is configured and enabled on a per virtual host basis= .=20 To enable request logging for a virtual host just add a JkRequestLogF= ormat config.=20 The syntax of the format string is similar to the Apache LogFormat co= mmand,=20 here is a list of the available request log format options:

=20

=
OptionsDescription
%b<= /td>Bytes sent, excluding HTTP h= eaders (CLF format)
%BBytes sent,= excluding HTTP headers
%HThe req= uest protocol
%mThe request metho= d
%pThe canonical Port of the ser= ver serving the request
%qThe que= ry string (prepended with a ? if a query string exists, otherwise an = empty string)
%rFirst line of req= uest
%sRequest HTTP status code
%TRequest duration, elapsed time t= o handle request in seconds '.' micro seconds
%UThe URL path requested, not including any query strin= g.
%v<= /td>The canonical ServerName of = the server serving the request
%V= The server name according to the UseCanonicalName setting
%wTomcat worker name
%RReal worker name

  JkRequestLogFormat     "%w %V %T"


You can also log mod_jk information using the Apache standard module = mod_log_config. The module sets several notes in the Apache httpd notes table. Most of them are are only useful in combination with a load balancer = worker.

=20

= Actual worker name selected by the = URI mapping (usually a member of the load balancer).
Before versi= on 1.2.26 only available if JkRequestLogFormat is set.<= td align=3D"left" valign=3D"center">JK_REQUEST_DURATION<= /td><= td align=3D"left" valign=3D"center">JK_LB_FIRST_NAMELoad-Balancer: Access count for the= first worker tried= <= td align=3D"left" valign=3D"center">Load-Balancer: Activation state f= or the first worker tried= = 
  LogFormat     "%h %l %u %t \"%r\" %>s %b %{JK_WORKER_NAME}n %{JK=
_LB_FIRST_NAME}n \
                 %{JK_LB_FIRST_BUSY}n %{JK_LB_LAST_NAME}n %{JK_LB_LAS=
T_BUSY}n" mod_jk_log
  CustomLog     logs/access_log     mod_jk_log


NoteDescription
JK_WORKER_NAMEName of the worker sele= cted by the URI mapping
JK_WORKER_TYPEType of the worker selected by the URI mapping
JK_WORKER_ROUTE
Request duration in seconds = and microseconds.
Before versi= on 1.2.26 only available if JkRequestLogFormat is set.
Load-Balancer: Name of the firs= t worker tried
JK_LB_FIRST_TYPELo= ad-Balancer: Type of the first worker tried
JK_LB_FIRST_ACCESSED
JK_LB_FIRST_READLoad-Balancer: Bytes read for the first worker tried
JK_LB_FIRST_TRANSFERREDLoad-Balancer: Bytes tr= ansferred for the first worker tried
JK_LB_FIRST_ERRORSLoad-Balancer: Error count for the first worker= tried
JK_LB_= FIRST_BUSYLoad-Balan= cer: Busy count for the first worker tried
JK_LB_FIRST_ACTIVATION
JK_LB_FIRST_STATELoad-Balancer: Error state for the first worker tried
JK_LB_LAST_NAME<= /code>Load-Balancer: Name o= f the last worker tried
JK_LB_LAST_TYPELoad-Balancer: Type of the last worker tried
JK_LB_LAST_ACCESSEDLoad-Balancer: Access count for = the last worker tried
JK_LB_LAST_READLoad-Balancer: Bytes read for the last worker tried
JK_LB_LAST_TRANSFERREDLoad-Balancer: Bytes tra= nsferred for the last worker tried
JK_LB_LAST_ERRORSLoad-Balancer: Error count for the last worker tri= ed
JK_LB_LAST= _BUSYLoad-Balancer: = Busy count for the last worker tried
JK_LB_LAST_ACTIVATIONLoad-Balancer: Activation state for the l= ast worker tried
JK_LB_LAST_STATE= Load-Balancer: Error state for the last worker tried
Forwarding=

The directive JkOptions allow you to set many forwarding options whic= h will enable (+) or disable (-) following option. Without any leading signs, options w= ill be enabled.

The four following options +ForwardURIxxx are mutually exclusi= ve. Exactly one of them is required, a negative sign prefix is not allowe= d with them. The default value is "ForwardURIProxy" since version 1.2.24. It was "ForwardURICompatUnparsed" in version 1.2.23 and "ForwardURICompat" until version 1.2.22. You can turn the default off by switching on one of the other two opt= ions. You should leave this at it's default value, unless you have a very g= ood reason to change it.

All options are inherited from the global server to virtual hosts. Options that support enabling (plus options) and disabling (minus opt= ions), are inherited in the following way:

options(vhost) =3D plus_options(global) - minus_options(global) + plu= s_options(vhost) - minus_options(vhost)

Using JkOptions ForwardURIProxy, the forwarded URI will be partially reencoded after processing inside Apache httpd and before forwarding to Tomcat. This will be compatible with local URL manipulation by mod_rewrite and with URL encoded session ids. 

  JkOptions     +ForwardURIProxy


Using JkOptions ForwardURICompatUnparsed, the forwarded URI will be unparsed. It's spec compliant and secure. It will always forward the original request URI, so rewriting URIs with mod_rewrite and then forwarding the rewritten URI will not work. 

  JkOptions     +ForwardURICompatUnparsed


Using JkOptions ForwardURICompat, the forwarded URI will be decoded by Apache httpd. Encoded characters will be decoded and explicit path components like ".." will already be resolved. This is less spec compliant and is not safe if you are using prefix JkMount. This option will allow to rewrite URIs with mod_rewrite before forwarding. 

  JkOptions     +ForwardURICompat


Using JkOptions ForwardURIEscaped, the forwarded URI will be the encoded form of the URI used by ForwardURICompat. Explicit path components like ".." will already be resolved. This will not work in combination with URL encoded session IDs, but it will allow to rewrite URIs with mod_rewrite before forwarding. 

  JkOptions     +ForwardURIEscaped


JkOptions RejectUnsafeURI will block all URLs, which contain percent signs '%' or backslashes '\' after decoding.

Most web apps do not use such URLs. Using the option RejectUnsafeURI,= you can block several well known URL encoding attacks. By default, this o= ption is not set.

You can also realize such a check with mod_rewrite, which is more pow= erful but also slightly more complicated. 

 =20
  JkOptions     +RejectUnsafeURI


JkOptions ForwardDirectories is used in conjunction with Di= rectoryIndex directive of Apache web server. As such mod_dir should be available t= o Apache, statically or dynamically (DSO)

When DirectoryIndex is configured, Apache will create sub-requests fo= r each of the local-url's specified in the directive, to determine if t= here is a local file that matches (this is done by stat-ing the file).

If ForwardDirectories is set to false (default) and Apache doesn't fi= nd any files that match, Apache will serve the content of the directory (if = directive Options specifies Indexes for that directory) or a = 403 Forbidden response (if directive Options doesn't specify Indexes for that directory).

If ForwardDirectories is set to true and Apache doesn't find any file= s that match, the request will be forwarded to Tomcat for resolution. This i= s used in cases when Apache cannot see the index files on the file system for v= arious reasons: Tomcat is running on a different machine, the JSP file has b= een precompiled etc.=20

Note that locally visible files will take precedence over the ones visible only to Tomcat (i.e. if Apache can see the file, that's = the one that's going to get served). This is important if there is more then = one type of file that Tomcat normally serves - for instance Velocity pages and JS= P pages. 

 =20
  JkOptions     +ForwardDirectories


JkOptions ForwardLocalAddress, you ask mod_jk to send the loca= l address, of the Apache web server instead remote client address. This can be u= sed by Tomcat remote address valve for allowing connections only from regist= ered Apache web servers. 

 =20
  JkOptions     +ForwardLocalAddress


JkOptions FlushPackets, you ask mod_jk to flush Apache's conne= ction buffer after each AJP packet chunk received from Tomcat. This option = can have a strong performance penalty for Apache and Tomcat as writes are perf= ormed more often than would normally be required (ie: at the end of each response). 

 =20
  JkOptions     +FlushPackets


JkOptions FlushHeader, you ask mod_jk to flush Apache's connec= tion buffer after the response headers have been received from Tomcat. 

 =20
  JkOptions     +FlushHeader


JkOptions DisableReuse, you ask mod_jk to close connections im= mediately after their use. Normally mod_jk uses persistent connections and pool= s idle connections to reuse them, when new requests have to be sent to Tomca= t.

Using this option will have a strong performance penalty for Apache a= nd Tomcat. Use this only as a last resort in case of unfixable network problems. If a firewall between Apache and Tomcat silently kills idle connectio= ns, try to use the worker attribute socket_keepalive in combination with = an appropriate TCP keepalive value in your OS. 

 =20
  JkOptions     +DisableReuse


JkOptions ForwardKeySize, you ask mod_jk, when using ajp13, t= o forward also the SSL Key Size as=20 required by Servlet API 2.3. This flag shouldn't be set when servlet engine is Tomcat 3.2.x (on by= default). 

 =20
  JkOptions     +ForwardKeySize


JkOptions ForwardSSLCertChain, you ask mod_jk, when using ajp= 13, to forward SSL certificate chain (off by default). Mod_jk only passes the SSL_CLIENT_CERT to the A= JP connector. This is not a problem with self-signed certificates or certificates directly signed= by the root CA certificate. However, there's a large number of certificates = signed by an intermediate CA certificate, where this is a significant problem: = A servlet will not have the possibility to validate the client certificate on i= ts own. The bug would be fixed by passing on the SSL_CLIENT_CER= T_CHAIN to Tomcat via the AJP connector.
This directive exists only since version 1.2.22. 

 =20
  JkOptions     +ForwardSSLCertChain


The directive JkEnvVar allows you to forward environment varia= bles from Apache server to Tomcat engine. The variables can be retrieved on the Tomcat side as request attribut= es. You can add a default value as a second parameter to the directive. If the default value is not given explicitely, the variable will only be send, if it is set during runtime.

The variables are inherited from the global server to virtual hosts. 

 =20
  JkEnvVar     SSL_CLIENT_V_START     undefined


Assig= ning URLs to Tomcat

If you have created a custom or local version of mod_jk.conf-local as= noted above,=20 you can change settings such as the workers or URL prefix.

JkMount directive assign specific URLs to Tomcat.=20 In general the structure of a JkMount directive is: 

 =20
  JkMount [URL prefix] [Worker name]

  # send all requests ending in .jsp to worker1
  JkMount /*.jsp worker1
  # send all requests ending /servlet to worker1
  JkMount /*/servlet/ worker1
  # send all requests jsp requests to files located in /otherworker w=
ill go worker2
  JkMount /otherworker/*.jsp worker2

You can use the JkMount directive at the top level or inside <Virt= ualHost> sections of your httpd.conf file.

JkUnMount directive acts as an opposite to JkMount and bloc= ks access to a particular URL. The purpose is to be able to filter out the part= icular content types from mounted context. The following example mounts /servlet/* context, but all .gif files that belongs to that context are not serv= ed. 

  # send all requests ending with /servlet to worker1
  JkMount /servlet/* worker1
  # do not send requests ending with .gif to worker1
  JkUnMount /servlet/*.gif worker1

JkUnMount takes precedence over JkMount directives, meaning that the = JK will first try to mount and then checks, if there is an exclusiond de= fined by a JkUnMount. A JkUnMount overrides a JkMount only, if the worker names = in the JkMount and in the JkUnMount are the same.

The following example will block all .gif files although there is a J= kMount for them: 

  # do not send requests ending with .gif to worker1
  JkUnMount /*.gif worker1
  # The .gif files will not be mounted cause JkUnMount takes
  # precedence over JkMount directive
  JkMount /servlet/*.gif worker1

Starting with version 1.2.26 of JK you can apply a JkUnMount to any w= orker, by using the star character '*' as the worker name in the JkUnMount. More complex patterns in JkUnMount worker names are not allowed. 

  # Mapping the webapps myapp1 and myapp2:
  /myapp1/*=3Dworker1
  /myapp2/*=3Dworker2
  # Exclude the all subdirectories static for all workers:
  !/*/static/*=3D*
  # Exclude some suffixes for all workers:
  !*.html=3D*

JkAutoAlias directive automatically Alias webapp contex= t directories into the Apache document space. It enables Apache to serve a static contex= t while Tomcat serving dynamic context. This directive is used for convenience so th= at you don't have to put an apache Alias directive for each application directory = inside Tomcat's webapp directory. For security reasons is is strongly recommended tha= t JkMount is used to pass all requests to Tomcat by default and JkUnMount is us= ed to explicitly exclude static content to be served by httpd. It should al= so be noted that content served by httpd will bypass any security constraints def= ined in the application's web.xml. 

  # enter the full path to the tomcat webapps directory
  JkAutoAlias /opt/tomtact/webapps

The following example shows how to serve a dynamic context by Tomcat and static using Apache. The webapps directory has to be accessible by apache.

  # enter the full path to the tomcat webapps directory
  JkAutoAlias /opt/tomtact/webapps

  # Mount 'servlets-examples' directory. It's physical location
  # is assumed to be in the /opt/tomtact/webapps/servlets-examples
  # ajp13w is a worker defined in the workers.properties
  JkMount /servlets-examples/* ajp13w

  # Unmount desired static content from servlets-examples webapp.
  # This content will be served by the httpd directly.
  JkUnMount /servlets-examples/*.gif ajp13w
  JkUnMount /servlets-examples/*.jpg ajp13w

Note that you can have a single JkAutoAlias directive per virtual host inside your httpd.conf

JkWorkerProperty is a new directive available from JK 1.2.7 version. It is a convenient method for setting directives that are usually set inside workers.propeties file. The parameter for that directive is raw line from workers.properties file. 

  # Just like workers.properties but exact line is prefixed
  # with JkWorkerProperty

  # Minimal jk configuration
  JkWorkerProperty worker.list=3Dajp13w
  JkWorkerProperty worker.ajp13w.type=3Dajp13
  JkWorkerProperty worker.ajp13w.host=3Dlocalhost
  JkWorkerProperty worker.ajp13w.port=3D8009  =20

JkMountFile is a new directive available from JK 1.2.9 version. It is used for dynamic updates of mount points at runtime. When the mount file is changed, JK will reload it's content. 

  # Load mount points

  JkMountFile conf/uriworkermap.properties

If the mount point uri starts with an exclamation mark '!' it defines an exclusion in the same way JkUnMount does. If the mount point uri starts with minus sign '-' the mount point will only be disabled. A disabled mount can be reenab= led by deleting the minus sign and waiting for the JkMountFile to reload. An exclusion can be disabled by prefixing it with a mninus sign. 

  # Sample uriworkermap.properties file

  /servlets-examples/*=3Dajp13w
  # Do not map .jpeg files
  !/servlets-examples/*.jpeg=3Dajp13w
  # Make jsp examples initially disabled =20
  -/jsp-examples/*=3Dajp13w

At run time you can change the content of this file. For example removing minus signs will enable the previously disabled uri mappings= . You can add any number of new entries at runtime that reflects the ne= wly deployed applications. Apache will reload the file and update the mount points within 60 second interval.

There is no way to delete entries by dynamic reloading, but you can d= isable or exclude mappings.

Using SetHandler and Environment Variables<= /font>

Alternatively to the mod_jk specific directives, you can also use SetHandler and environment variables to control, which requests are being forwarded via which worker. This gives you more flexibility= , but the results might be more difficult to understand. If you mix bot= h ways of defining the forwards, in general to mod_jk directives will w= in.

SetHandler jakarta-servlet forces requests to be handled by mo= d_jk. If you neither specify any workers via JkMount and the related direct= ives, not via the environment variable described below, the first worker in the list of all worker will be chosen. You can us= e SetHandler for example in Location blocks or with Apache 2.2 also in RewriteRule= .

In order to control the worker using SetEnvIf or RewriteRul= e for more complex rules, you can set the environment variable JK_WO= RKER_NAME to the name of your chosen target worker. This enables you to decide = on the chosen worker in a more flexible way, including dependencies on c= ookie values. This feature has been added in version 1.2.19 of mod_jk.

In order to use another variable than JK_WORKER_NAME, you can = set the name of this variable via the JkWorkerIndicator directive.

Finally you can define exclusions from mod_jk forwards by setting the= environment variable no-jk. 

  # Automatically map all encoded urls
  <Location *;jsessionid=3D>
    SetHandler jakarta-servlet
    SetEnv JK_WORKER_NAME my_worker
  </Location>

  # Map all subdirs to workers via naming rule
  # and exclude static content.
  <Location /apps/>
    SetHandler jakarta-servlet
    SetEnvIf REQUEST_URI ^/apps/([^/]*)/ JK_WORKER_NAME=3D$1
    SetEnvIf REQUEST_URI ^/apps/([^/]*)/static no-jk
  </Location>

Copyright © 1999-2005, Apache Software Foundation
--Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ) Content-type: text/html; NAME=mod_security2_interface.html; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: attachment; filename=mod_security2_interface.html ModSecurity Reference Manual
3D"ModSecuri=
<= h2 class=3D"title">ModSecurity Reference Manua= l

Version 2.1.5 / (Jan 10, 20= 08)

Copyright © 2004-2008 B= reach Security, Inc. (http://www.breach.com)

Table of Contents

Introduction
HTTP= Traffic Logging
Real-Time Monitoring and Attack Detection
Attack Prevention an= d Just-in-time Patching
Flexible Rule Engine
Embedded-mode Deployment<= /dt>
Network-based Dep= loyment
Licensing
ModSecurity Core Rules
<= dt>Overview
Core Rules Structur= e
Core= Rules Content
<= a href=3D"#02-installation">Installation
Configuration= Directives
SecAction
SecArgumentSeparator
SecAuditEngine
SecAuditLog
SecAuditLog= 2
SecAuditLogParts
= SecAuditLogRelevantStatus
SecAuditLogStorage= Dir
SecAuditLogType
SecChrootDir
SecCookieFormat
SecDataDir
SecDebugLog
SecDebugLogLevel
SecDefault= Action
SecGuardianLog
=
SecRequestBodyAccess
SecRequestBodyLimit<= /code>
SecRequestBodyInMemoryLimit
SecResponseBodyLimit
SecRespons= eBodyMimeType
SecResponseBodyMimeTypesClear<= /code>
SecResponseBodyAccess
=
SecRule
SecRuleInheritance
SecRuleEngine
SecRuleRemoveById=
SecRuleRemoveByMsg
SecServerSignature
SecTmpDir
SecUploadDir
SecUploadKeepFiles=
SecWebAppId
Proces= sing Phases
Phase Request Headers
Phase Request Body
Phase Response Headers<= /a>
Phase = Response Body
Phase Logging
Variables
= A= RGS
ARGS_COMBINED_SIZE
ARGS_NAMES
AUTH_TYPE
ENV
FILES
= F= ILES_COMBINED_SIZE
= FILES_NAMES
FILES_SIZES
FILES_TMPNAMES
HTTP_
MULTIPART_CRLF_LF= _LINES
MULTIPART_STRICT_ERROR
MULTIPART_UNMATCHED_BOUNDARY
<= span class=3D"section">PA= TH_INFO
QUERY_STRING
REMOTE_ADDR
<= a href=3D"#N10A78">REMOTE_HOST
REMOTE_PORT
REMOTE_USER<= /a>
REQBODY_PROCESSOR
REQBODY_= PROCESSOR_ERROR
REQBODY_PROCESSOR_ERROR_MSG<= /code>
REQUEST_BASENAME
<= span class=3D"section">RE= QUEST_BODY
REQUEST_COOKIES
REQUEST_COOKIES_NAMES
REQUEST_F= ILENAME
REQUEST_HEADERS
REQUEST_HEADERS_NAMES
REQUEST_L= INE
REQUEST_METHOD
= REQUEST_PROTOCOL
REQUEST_URI
REQUEST_URI_RAW
RESPONSE_BOD= Y
RESPONSE_HEADERS
= RESPONSE_HEADERS_NAMES
RESPONSE_PROTOCOL
RESPONSE_STATUS
RULE
= SCRIPT_BASENAME
SCRI= PT_FILENAME
SCRIPT_GID
SCRIPT_GROUPNAME
SCRIPT_MODE<= /span>
SCRIPT_UID
SCRIPT_USERNAME
SERVER_ADDR
SERVER_NAM= E
SERVER_PORT
SESSI= ON
SESSIONID
TIME
= TIME_DAY
TIME_EPOCH<= /code>
TIME_HOUR
TIME_MIN<= /code>
TIME_MON
TIME_SEC
= TIME_WDAY
TIME_YEAR<= /code>
TX
USERID
WEBAPPID
WEBSERVER_ER= ROR_LOG
XML
<= /dd>
Transformation functions
base64Decode=
base64Encode
compr= essWhitespace
escapeSeqDecode
hexDecode
hexEncode<= /span>
htmlEntityDecode
lowercase
<= code class=3D"literal">md5
none
= normalisePath<= /span>
normalisePathWin
removeNulls<= /code>
removeWhitespace
<= span class=3D"section">re= placeComments
replaceNulls=
urlDecode
<= a href=3D"#N10F1F">urlDecodeUni
urlEncode
sha1
A= ctions
allow
= a= uditlog
capture
chain
ctl
deny
deprecatevar
drop
exec
expirevar
id
initcol
log
msg
<= dt>multiMatch
noauditlog
nolog
pass
<= span class=3D"section">pa= use
phase
proxy
redirect
rev
sanitiseArg
sanitiseMatc= hed
sanitiseRequestHeader<= /dt>
sanitiseResponseHeader
severity
setuid
setsid
setenv
setvar=
skip
status=
t
xmlns
Operators=
eq
ge
gt
= inspectFile
le
lt
= rbl
rx
validateByte= Range
validateDTD
= v= alidateSchema
validateUrlEncoding=
validateUtf8Encoding
<= dt>Miscellaneous Topics
Impedance Mismatch

Intr= oduction

ModSecurity™ is a web application firewall (WAF). With over 70% of all attacks now carr= ied out over the web application level, organisations need every help the= y can get in making their systems secure. WAFs are deployed to establish an= external security layer that increases security, detects, and prevents att= acks before they reach web applications. It provides protection from a= range of attacks against web applications and allows for HTTP traffic moni= toring and real-time analysis with little or no changes to existing infrastructure.

H= TTP Traffic Logging

Web servers a= re typically well-equipped to log traffic in a form useful for marketing analyses, but fall short when it comes to = logging of traffic to web applications. In particular, most are not cap= able of logging the request bodies. Your adversaries know this, and tha= t is why most attacks are now carried out via POST requests, rendering y= our systems blind. ModSecurity makes full HTTP transaction logging = possible, allowing complete requests and responses to be logged. Its logg= ing facilities also allow fine-grained decisions to be made about e= xactly what is logged and when, ensure only the relevant data is recorded.

= Real-Time Monitoring and Attack Detection

=

In addition to providing logging facilities, ModSecurity can monitor the HTTP traffic in real time in order to detect attack= s. In this case ModSecurity operates as a web intrusion detection too= l, allowing you to react to suspicious events that take place at y= our web systems.

A= ttack Prevention and Just-in-time Patching

ModSecurity can also act immediately to prevent attacks fro= m reaching your web applications. There are three commonly used approaches:

  1. Negative security model. Negative security model monitors requests for anomalies, unusual behaviour, and common web application attacks. It keeps anomaly scores for each reque= st, IP addresses, application sessions, and user accounts. Request= s with high anomaly scores are either logged or rejected altogethe= r.

  2. Positive security model. When positive security mod= el is deployed, only requests that are known to be valid are acce= pted, with everything else rejected. This approach works best wit= h applications that are heavily used but rarely updated.

    <= /li>

  3. Known weaknesses and vulnerabilities. Its rule language ma= kes ModSecurity an ideal external patching tool. External patch= ing is all about reducing the window of opportunity. Time needed t= o patch application vulnerabilities often runs to weeks in many organisations. With ModSecurity, applications can be patche= d from the outside, without touching the application source code (= and even without any access to it), making your systems secure until= a proper patch is produced.

Flexible Rule Engine

A flexible rule engine sits in the heart of ModSecur= ity. It implements the ModSecurity Rule Language, which is a specialise= d programming language designed to work with HTTP transaction dat= a. The ModSecurity Rule Language was designed to be easy to use, yet f= lexible: common operations are simple while complex operations are possi= ble. Certified ModSecurity Rules, included with subscription to ModS= ecurity, contain a comprehensive set of rules that implement general-pur= pose hardening, common web application security issues. Heavily comm= ented, these rules can be used as a learning tool.

Embedded-mode Deployment

=

ModSecurity is an embeddable web applicatio= n firewall, which means it can be deployed as part of your existing web server infrastr= ucture provided your web servers are Apache-based. This deployment met= hod has certain advantages:

  1. No changes to existing network. It only takes a few minutes = to add ModSecurity to your existing web servers. And because i= t was designed to be completely passive by default, you are free = to deploy it incrementally and only use the features you need. It is = equally easy to remove or deactivate it should decide you don't wan= t it any more.

  2. No single point of failure. Unlike wit= h network-based deployments, you will not be introducing a new point of fai= lure to your system.

  3. Implicit load balancing and sca= ling. Because it works embedded in web servers, ModSecurity will automatically take advanta= ge of the additional load balancing and scalability features. You wil= l not need to think of load balancing and scaling unless your exi= sting system needs them.

  4. Minimal overhead. Because= it works from inside the web server process there is no overhead for network communication and = minimal overhead in parsing and data exchange.

  5. No pr= oblem with encrypted or compressed content. Many IDS systems have difficulties analysing SSL traffic. This is no= t a problem for ModSecurity because it is positioned to work wh= en the traffic is decrypted and decompressed.

<= p>ModSecurity is known to work well on a wide range of operating systems. Our customers are successfully running it on Linux, Wi= ndows, Solaris, FreeBSD, OpenBSD, NetBSD, AIX, Mac OS X, and HP-UX.

Network-based Deployment

<= div>

ModSecurity works equally well when deployed as pa= rt of an Apache-based reverse proxy server, and many of our customers ch= oose to do so. In this scenario, one installation of ModSecurity can pr= otect any number of web servers (even the non-Apache ones).

Licensing

ModSecurity is available under two licenses. U= sers can choose to use the software under the terms of the GNU General Public Lice= nse version 2 (licence text is included with the distribution), as = an Open Source / Free Software product. A range of commercial licenses = is also available, together with a range of commercial support contract= s. For more information on commercial licensing please contact Breach Security.

Note

ModSecurity, mod= _security, and ModSecurity Pro are trademarks or registered trademarks of Breach Security, Inc.

= ModSecurity Core Rules

Overview

ModSecurity is a web application firewall engine that prov= ides very little protection on its own. In order to become useful, ModSecurity must be configured with rules. In order to enable u= sers to take full advantage of ModSecurity out of the box, Breach Secur= ity Inc. is providing a free certified rule set for ModSecurity 2.0. Unl= ike intrusion detection and prevention systems, which rely on signa= ture specific to known vulnerabilities, the Core Rules provide gener= ic protection from unknown vulnerabilities often found in web appl= ications, which are in most cases custom coded. The Core Rules are heavil= y commented to allow it to be used as a step-by-step deployment g= uide for ModSecurity. The latest Core Rules can be found at the ModSecur= ity website - http://www.modsecurity.org/projects/rules/.

=

Core Rules Structur= e

If you expect a single pack of = Apache configuration files, you are right, and wrong. A ModSecurity rule set includes information a= bout different areas:

  • The logic required to detect attacks.

  • A poli= cy setting the actions to perform if an attack is detected.

  • Information regarding attacks.

    =

In order to allow separate management of the diffe= rent parts, the Core Rules are based on templates that are generated into a run= -time rule set by inserting policy, patterns and event information. T= he Core Rules package includes these templates, the generation script (= written in Perl) and data files required to generate a useful rule set.= It also includes a bunch of pre-generated rule sets for different polic= ies. The generation script also allows two optimizations:

  • Optimal use of regular exp= ressions. Since regular expressions are much more efficient if assembled into a single expressi= on and optimized, the generation script takes the list of patterns= that are required for a rule and optimize them into a most efficient= regular expression.

  • Removal of rules that are not ut= ilized by a specific policy.

Core Rules Content

In order to provide generic web applications protection, the Core Rules use the following techniques:

  • HTTP protection - detecting violations o= f the HTTP protocol and a locally defined usage policy.

  • Common W= eb Attacks Protection - detecting common web application security attack.

  • Automation dete= ction - Detecting bots, crawlers, scanners and other surface malicious activity.

  • Trojan Pro= tection - Detecting access to Trojans horses.

  • Error Hi= ding - Disguising error messages sent by the server.

Installation

ModSecurity installation consists = of the following steps:

    =

  1. ModSecurity 2.x works with Apache 2.0.x or better.

    2. Make sure you have mod_unique_id i= nstalled.

  2. Install the latest version of libxml2, if it= isn't already installed on the server.

  3. Unpack the ModSecurit= y archive

  4. Edit Makefile to configure the path to the A= pache ServerRoot directory. You can check this by identifying the ServerRoot d= irective setting in your httpd.conf file. This is the path that was sp= ecified with the "--install-path=3D" configuration flag during compil= ation (for example, in Fedora Core4: top_dir = =3D /etc/httpd).

  5. Edit Makefile to configure= the correct include path for libxml (for example: INCLUDES=3D-I/usr/inclu= de/libxml2)

  6. Compile with make

  7. Stop Apache

  8. Install with<= code class=3D"literal"> make install

  9. Add one line to your configurat= ion to load libxml2:

    LoadFile /usr/lib/libxml2.so

  10. Add one line to you= r configuration to load ModSecurity:

    Lo= adModule security2_module modules/mod_security2.so

  11. Configure ModS= ecurity

  12. Start Apache

  13. You now have ModSe= curity 2.x up and running.

N= ote

If you have compiled Apache yourself or are compiling for = a distribution, please read the following notes.

The ModSec= urity Core rules may assume XML support is available (compiled with -DWITH_LIBXML2). You may have to manu= ally remove any XML references in the Core rules if you choose not t= o include XML support. In future versions of ModSecurity XML sup= port will be required. For these reasons, please consider XML suppo= rt required.

You might experience problems compiling ModSecurity against PCRE. This is because Apache bund= les PCRE but this library is also typically provided by the operating sy= stem. I would expect most (all) vendor-packaged Apache distributions to= be configured to use an external PCRE library (so this should not = be a problem).

You want to avoid Apache using the bundled PCRE= library and ModSecurity linking against the one provided by the operating s= ystem. The easiest way to do this is to compile Apache against the PCR= E library provided by the operating system (or you can compile it against= the latest PCRE version you downloaded from the main PCRE distribut= ion site). You can do this at configure time using the --with-pcre switch. If you are not in a position to recompile Apache then, to compile ModSecurity succe= ssfully, you'd still need to have access to the bundled PCRE headers (th= ey are available only in the Apache source code) and change the includ= e path for ModSecurity (as you did in step 7 above) to point to them.<= /p>

If your Apache is using an external PCRE library you can compile ModSecurity with WITH_PCRE_= STUDY defined,which would possibly give you a slight performance edge in regular expression processing.

<= div class=3D"titlepage">

Configuration Dire= ctives

The following section outl= ines all of the ModSecurity directives. Most of the ModSecurity directives can be used inside the various= Apache Scope Directives such as VirtualHost, Location, = LocationMatch, Directory, etc... There are others= , however, that can only be used once in the main configuration file. This informatio= n is specified in the Scope sections below.

These rules, along w= ith the Core rules files, should be contained is files outside of the httpd.conf file and called up with Apache "I= nclude" directives. This allows for easier updating/migration of the rule= s. If you create your own custom rules that you would like to use with the = Core rules, you should create a file called - modsecurity_crs_15_customrules.conf and place it in the same directory as the Core rules files. By using this file na= me, your custom rules will be called up after the standard ModSecurity Cor= e rules configuration file but before the other Core rules. This allows y= our rules to be evaluate first which can be useful if you need to implement= specific "allow" rules or to correct any false positives in the Core rules= as they are applied to your site.

Note=

It is highly encouraged that you do not edit t= he Core rules files themselves but rather place all changes (such as SecRuleRemoveByID, etc...) in your= custom rules file. This will allow for easier upgrading as newer Core rules are rele= ased by Breach Security on the ModSecurity website.

SecAction

Descri= ption: Unconditionally processes the action list it receives as the first and only par= ameter. It accepts one parameter, the syntax of which is identical to t= he third parameter of SecRule.

Syntax: SecAction action1,action2,action2

Example Usage: Sec= Action nolog,redirect:http://www.hostname.com

ProcessingPhase: Any

Scope: Any

Dependencies/Notes: None

SecA= ction is best used when you uncondiationally execute an action. This is explicit triggering whereas the normal Actions = are conditional based on data inspection of the request/response. T= his is a useful directive when you want to run certian actions such as i= nitcol to initialize collections.

SecArgumentSeparator<= /h3>

Desc= ription: Specifies which character to use as separator for application/x-www-form-urlencoded content. Defaults to &. Applications are sometime= s (very rarely) written to use a semicolon (;).

Syntax: SecArgumentSeparator character

=

Example Usage: SecArgumentSeparator ;

Processing Phase: Any

Scope: Main

Depend= encies/Notes: None

This directive is needed if = a backend web appliaction is using a non-standard argument separator. If this directive is not set p= roperly for each web app, then ModSecurity will not be able to parse th= e arguements appropriately and the effectiveness of the rule matc= hing will be significantly decreased.

SecAuditEngine

<= /div>

Descripti= on: Configures the audit logging engine.

Syntax: SecAuditEngine On|Off|RelevantOnl= y

Example Usage: SecAuditEngine On

Processing Phase: N/A

Scope: Any

Dependencies/Notes: Can be set/changed with the "ctl" action for the current transaction.<= /p>

Example: The following example shows the various audit directiv= es used together.

SecAuditEngine RelevantOnly=20
SecAuditLog logs/audit/audit.log
SecAuditLogParts ABCFHZ
SecAuditLogType concurrent
SecAuditLogStorageDir logs/audit
SecAuditLogRelevantStatus ^[45]=

Possible values are:

<= ul type=3D"disc">

  • On - log all t= ransactions by default.

  • Off - do not log transactions by default.

  • RelevantOnly - by default only log transactions that have triggered a warning or an e= rror, or have a status code that is considered to be relevant (see SecAuditLogRelevantStatus).

    • SecAuditLog

    <= span class=3D"bold">Description: Defines the = path to the main audit log file.

    Syn= tax: SecAuditLog /path/to/aud= itlog

    Example Usage: SecAuditLog /usr/local/apache/logs/audit.log

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: This file is open on startup when the server typically still runs as root. You should not allow non-root users to have w= rite privileges for this file or for the directory it is stored in..=

    This file will be used to store the audit log entries if seria= l audit logging format is used. If concurrent audit logging forma= t is used this file will be used as an index, and contain a record of all= audit log files created. If you are planning to use Concurrent audit = logging and sending your audit log data off to a remote Console host, t= hen you will need to use the modsec-auditlog-collector.pl script and us= e the following format:

    SecAuditL=
og \
  "|/path/modsec-auditlog-collector.pl /path/SecAuditLogDataDir /path=
/SecAuditLog"

    = SecAuditLog2

    =

    Description: Defines the path to the secondary audit log index file when concurrent logging is e= nabled. See SecAuditLog2 for more details.

    Syntax: SecAuditLog2 /path/to/auditlog2

    Example Usage: SecAuditLog2 /usr/local/apache/logs/audit2.log

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: A main audit log must be defined via SecAuditLog before this directive may be used. Additionally, this log is on= ly used for replicating the main audit log index file when concurrent a= udit logging is used. It will not be used for non-concurrent audit logging.

    SecAuditLogParts

    D= escription: Defines the path to the main audit log file.

    Syn= tax: SecAuditLogParts PARTS

    Example Usage: SecAuditLogParts ABCFHZ

    Processing Phase: N/A

    <= span class=3D"bold"> Scope: Any

    Depende= ncies/Notes: At this time ModSecurity does not log response bodies of stock Apache respon= ses (e.g. 404), or the Server and Date response h= eaders.

    Default: ABCFHZ.

    A= vailable audit log parts:

    • A - audit log header (mandatory)

    • B= - request headers

    • C - = request body (present only if the request body exists and ModSecurity is configur= ed to intercept it)

    • D - RESERVED for intermediary response headers, not implemented yet.

    • E - intermediary response body (present only if ModSecurity is configured to intercep= t response bodies, and if the audit log engine is configured = to record it). Intermediary response body is the same as the actual r= esponse body unless ModSecurity intercepts the intermediary respons= e body, in which case the actual response body will contain the err= or message (either the Apache default error message, or the ErrorDocument page).

    • F - final response headers (excluding the Date and Server headers, which are always ad= ded by Apache in the late stage of content delivery).

    • =

      G - RESERVED for the actual response body, not implemented yet.

    • H - audit log trailer

    • I - T= his part is a replacement for part C. It will log the same data as C in a= ll cases except when multipart/form-data encoding in used. In this case it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not abou= t the files. This is handy if you don't want to have (often large= ) files stored in your audit logs.

    • J - RESERVED. This part, when implemented, will contain information about the files = uploaded using multipart/form-data en= coding.

    • Z - final bound= ary, signifies the end of the entry (mandatory)

    =

    SecAuditLogRelevantStatus

    <= /div>

    Description: Con= figures which response status code is to be considered relevant for the purpo= se of audit logging.

    Syntax: SecAuditLogRelevantStatus REGEX

    Example Usage: SecAuditLogRelevantStatus ^[45]

    <= p>Processing Phase: N/A<= /p>

    Scope: Any

    <= span class=3D"bold">Dependencies/Notes: Must = have the SecAuditEngine set to RelevantOnly. The parameter is a regular expression.

    The main purpose of this directive is to allo= w you to configure audit logging for only transactions that generate the specified= HTTP Response Status Code. This directive is often used to the decre= ase the total size of the audit log file. Keep in mind that if this par= ameter is used, then successful attacks that result in a 200 OK status co= de will not be logged.

    SecAuditLogStorageDir

    <= /div>

    Description: Configures the storage directory where concurrent audit log entries are to be stored.

    Syntax: SecAuditLogStorageDir /path/to/storage/dir

    = Example Usage: SecAuditLogSto= rageDir /usr/local/apache/logs/audit

    = Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: SecAuditLogType must be set to Concurrent. The directory must a= lready be created before starting Apache and it must be writable by the w= eb server user as new files are generated at runtime.

    As with all l= ogging mechanisms, ensure that you specify a file system location that has adequate disk space and is not on the = root partition.

    Description: Configures the type of audit logging mechanism to be used.

    Syntax: SecAuditLo= gType Serial|Concurrent

    Exa= mple Usage: SecAuditLogType S= erial

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: Must specify SecAuditLogStorageDir if you use concurrent logging.

    Poss= ible values are:

    1. = Serial - all audit log entries will be stored in the main audit logging file. This= is more convenient for casual use but it is slower as only one audi= t log entry can be written to the file at any one file.

      2. <= li>

      Concurrent - audit log entries will be stored in separate files, one for each tran= saction. Concurrent logging is the mode to use if you are going to s= end the audit log data off to a remote ModSecurity Console host.

    <= code class=3D"literal">SecChrootDir

    Description: C= onfigures the directory path that will be used to jail the web server process= .

    Syntax: SecChrootDir /path/to/chroot/dir

    Example Usage: SecChrootDir /chroot

    Processing Phase: N/A

    Scope: Main

    = Dependencies/Notes: The internal chroot functionality provided by ModSecurity works great for si= mple setups. One example of a simple setup is Apache serving static = files only, or running scripts using modules. For more complex setups= you should consider building a jail the old-fashioned way. The inte= rnal chroot feature should be treated as somewhat experimental. Due = to the large number of default and third-party modules available for t= he Apache web server, it is not possible to verify the internal chroot wo= rks reliably with all of them. You are advised to think about your = option and make your own decision. In particular, if you are using any= of the modules that fork in the module initialisation phase (e.g. mod_= fastcgi, mod_fcgid, mod_cgid), you are advised to examine each Apache pr= ocess and observe its current working directory, process root, and the li= st of open files.

    Description: Selects the cookie format that will be used in the current configuration context.<= /p>

    Syntax: SecCookieFormat 0|1

    <= strong>Example Usage: SecCook= ieFormat 0

    Processing Phase= : N/A

    Scope: Any

    Dependencies/Notes:= None

    Possible values are:

    SecDataDir

    Description:= Path where persistent data (e.g. IP address data, session data, etc) is to= be stored.

    Syntax: SecDataDir /path/to/dir

    Example Usage: SecDataDir /usr/local/apache/logs/data

    Processing Phase: N/A

    = Scope: Main

    Depend= encies/Notes: This directive is needed when initcol, setsid an setuid are used. Mu= st be writable by the web server user.

    = SecDebugLog

    Descrip= tion: Path to the ModSecurity debug log file.

    = Syntax: SecDebugLog /path/to/= modsec-debug.log

    Example Us= age: SecDebugLog /usr/local/apache/logs/modsec-debug.log

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: None

    <= div class=3D"section" lang=3D"en">
    =

    Se= cDebugLogLevel

    Description: Configures the verboseness of the debug log data.

    <= strong>Syntax: SecDebugLogLev= el 0|1|2|3|4|5|6|7|8|9

    Exam= ple Usage: SecDebugLogLevel 4=

    Processing Phase:= N/A

    Scope:= Any

    Dependencies/Notes:<= /span> Levels 1 - 3 are always sent to the Apa= che error log. Therefore you can always use level 0 as the default logging level in production. Level 5 is useful when debugging= . It is not advisable to use higher logging levels in production as = excessive logging can slow down server significantly.

    Possible valu= es are:

    • 0 - no logging.

    • 1 - errors (intercepted requests) only.

    • 2 - warnings.

    • 3 - no= tices.

    • 4 - details of h= ow transactions are handled.

    • 5 - as above, but including information about each piece of information handled.

    • 9 - log everything, including very detailed debugging information.

    SecDefaultAction

    Description: Defines= the default action to take on a rule match.

    Syntax: SecDefaultAction action1,action2,action3

    Example Usage: SecDefaultA= ction log,auditlog,deny,status:403,phase:2,t:lowercase

    <= span class=3D"bold">Processing Phase: Any

    =

    Scope: Any

    Dependencies/Notes: Rules following a SecDefaultAction directive will inherit this settin= g unless a specific action is specified for an indivdual rule or until a= nother SecDefaultAction is specified.

    The default value is:

    <= pre class=3D"programlisting">SecDefaultAction log,auditlog,deny,statu= s:403,phase:2,t:lowercase,t:replaceNulls,t:compressWhitespaceNote

    SecDefaultAc= tion must specify a disruptive action and a processing phase.

    <= code class=3D"literal">SecGuardianLog

    Description:= Configuration directive to use the httpd-guardian script to monitor for Denia= l of Service (DoS) attacks.

    Synta= x: SecGuardianLog |/path/to/h= ttpd-guardian

    Example Usage= : SecGuardianLog |/usr/local/apache/bin/httpd-guardian

    Processing Phase: N/A

    Scope: Main

    Dependencies/Notes: By default httpd-guardian will defend against clients that send more 120 r= equests in a minute, or more than 360 requests in five minutes.

    S= ince 1.9, ModSecurity supports a new directive, SecGuardianLog, that is designed to send all access data to another program usi= ng the piped logging feature. Since Apache is typically deployed in a multi-process fashion, making information sharing difficult, th= e idea is to deploy a single external process to observe all requests in = a stateful manner, providing additional protection.

    Develop= ment of a state of the art external protection tool will be a focus of subsequent ModSecurity releases. However, a fully fu= nctional tool is already available as part of the Apache httpd tools project. The tool is called httpd-guardian and can be used = to defend against Denial of Service attacks. It uses the blacklist= tool (from the same project) to interact with an iptables-based (Lin= ux) or pf-based (*BSD) firewall, dynamically blacklisting the offendin= g IP addresses. It can also interact with SnortSam (http://www.snort= sam.net). Assuming httpd-guardian is already configured (look into the so= urce code for the detailed instructions) you only need to add one line to= your Apache configuration to deploy it:

    SecGuardianLog |/path/to/httpd-guardian

    SecRequestB= odyAccess

    Description: Configures whether request bodies will be buffered and processed by ModSecurity by default.

    Syntax: SecRequestBodyAccess On|Off

    Example Usage: SecRequestBodyAccess On

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: This directive is required if you plan to inspect POST_PAYLOADS of r= equests. This directive must be used along with the "phase:2" processing= phase action and REQUEST_BODY variable/location. If any of these 3 pa= rts are not configured, you will not be able to inspect the request bodies.

    Possible values are:

    • On - acces= s request bodies.

    • Off -= do not attempt to access request bodies.

    SecRequestB= odyLimit

    Description: Configures the maximum request body size ModSecurity will accept for buffering= .

    Syntax: SecRequestBodyLimit NUMBER_IN_BYTES

    Example Usage: SecRequestBodyLimit 134217728

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: 131072 KB (134217728 bytes) is the default setting. Anything over this li= mit will be rejected with status code 413 Request Entity Too Large. Ther= e is a hard limit of 1 GB.

    SecRequestBodyInMemoryLimit<= /h3>

    Desc= ription: Configures the maximum request body size ModSecurity will store in memory.

    =

    Syntax: SecRequestBodyInMemoryLimit NUMBER_IN_BYTES

    Examp= le Usage: SecRequestBodyInMem= oryLimit 131072

    Processing = Phase: N/A

    Scope:<= /strong> Any

    Dependencies/N= otes: None

    By default the limit is 128 KB:

    <= pre class=3D"programlisting"># Store up to 128 KB in memory SecRequestBodyInMemoryLimit 131072

    SecResponseBodyLimit

    = Description: Configures the maximum response body size that will be accepted for buffering.=

    Syntax: SecResponseBodyLimit NUMBER_IN_BYTES

    Example Usage: SecResponseBodyLimit 524228

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: Anything over this limit will be rejected with status code 500 Internal Serve= r Error. This setting will not affect the responses with MIME types that= are not marked for buffering. There is a hard limit of 1 GB.

    By d= efault this limit is configured to 512 KB:

    # Buffer response bodies of up to 512 KB in length=20
SecResponseBodyLimit 524288

    SecResponseBodyMimeType

    D= escription: Configures which MIME types are to be consi= dered for response body buffering.

    Syntax: SecResponseBodyMimeT= ype mime/type

    Example Usage= : SecResponseBodyMimeType tex= t/plain text/html

    Processing = Phase: N/A

    Scope:<= /strong> Any

    Dependencies/N= otes: Multiple SecResponseBodyMimeType directives can be used to add MIME types.

    The default value is text/= plaintext/html:

    SecResponseBo=
dyMimeType text/plain text/html

    SecResponseBodyMimeTypesCle= ar

    Description: Clears the list of MIME types considered for respon= se body buffering, allowing you to start populating the list from scratch.

    Syntax: SecResponseBodyMimeTypesClear

    =

    Example Usage: SecResponseBodyMimeTypesClear

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: None

    <= div class=3D"section" lang=3D"en">
    =

    Se= cResponseBodyAccess

    Description: Configures whethe= r response bodies are to be buffer and analysed or not.

    Syntax: SecResponseBodyAccess On|Off

    <= strong>Example Usage: SecResp= onseBodyAccess On

    Processin= g Phase: N/A

    Scope= : Any

    Dependencies= /Notes: This directive is required if you plan to inspect html responses. Th= is directive must be used along with the "phase:4" processing phas= e action and RESPONSE_BODY variable/location. If any of these 3 parts ar= e not configured, you will not be able to inspect the response bodies= .

    Possible values are:

    • On - access response = bodies (but only if the MIME type matches, see above).

      • Off - do not attempt to access response bodies.

    SecRule

    = Description: SecRule i= s the main ModSecurity directive. It is used to analyse data and perform actions based on the result= s.

    Syntax: SecRule VARIABLES OPERATOR [ACTIONS]

    Example Usage: SecRule REQUEST_URI "attack"

    Processing Phase: Any

    Scope: Any

    Dependencies/Notes: None

    In g= eneral, the format of this rule is as follows:

    SecRule VARIABLES OPERATOR [ACTIONS]

    The second pa= rt, OPERATOR, specifies how they are going to be checked. The third (optional= ) part, ACTIONS, specifies what to do whenever the operator used performs a successful match against = a variable.

    Variab= les in rules

    The first part, VARIABLES, specifies which variables are to be checked. For example, the following rule will reject a transaction that has the word dirty in the URI:

    SecRule REQUEST_URI dirty

    Each rule can specify one or more= variables:

    SecRule REQUEST_URI|QUER=
Y_STRING dirty

    There is a third format supported by the selec= tion operator - XPath expression. XPath expressions can only used against the= special variable XML, which is available only of the request body was processed as XML.

    SecRule XM=
L:/xPath/Expression dirty

    Note

    As y= ou have just seen, not all collections support all selection operator format types. You should refer to the documentation of each collection to determine what is and i= sn't supported.

    Operators in rules

    In = the simplest possible case you will use a regular expression pattern as the second rule parameter. This is what we've done= in the examples above. If you do this ModSecurity assumes you want t= o use the rx operator. You can explicitl= y specify the operator you want to use by using @ as the first character in the second rule parameter:

    SecRule REQUEST_U=
RI "@rx dirty"

    Note how we had to use double quotes to delimi= t the second rule parameter. This is because the second parameter now has a whi= tespace in it. Any number of whitespace characters can follow the nam= e of the operator. If there are any non-whitespace characters there, t= hey will all be treated as a special parameter to the operator. In the= case of the regular expression operator the special parameter is the = pattern that will be used for comparison.

    The @ can be the seco= nd character if you are using negation to negate the result returned by the operator:

    SecRule &ARGS "!@rx ^0$"

    Actions in rules

    <= div>

    The third parameter, ACTIO= NS, can be omitted only because there is a helper feature that sp= ecifies the default action list. If the parameter isn't omitted the a= ctions specified in the parameter will be merged with the default ac= tion list to create the actual list of actions that will be processed o= n a rule match.

    SecRuleInheritance

    Description: Configures whether the current context will inherit rules from the parent context (configuration options are inherited in most cases - you should= look up the documentation for every directive to determine if it is inh= erited or not).

    Syntax: SecRuleInheritance On|Off

    Example Usage: SecRuleInheritance Off

    Processing Phase: Any

    Scope: Any

    Dependencies/Notes: Resource-specific contexts (e.g. Location, Directory, etc) cannot override phase1= rules configured in the main server or in the virtual server. This is because phase 1 is run= early in the request processing process, before Apache maps request to r= esource. Virtual host context can override phase 1 rules configured in t= he main server.

    Example: The following example shows where ModSec= urity may be enabled in the main Apache configuration scope, however you mig= ht want to configure your VirtualHosts differently. In the first exampl= e, the first virtualhost is not inheriting the ModSecurity main config directives and in the second one it is.

    SecRuleEnine On
SecDefaultAction log,pass,phase:2
=2E.. =20

<VirtualHost *:80>
ServerName app1.com=20
ServerAlias www.app1.com
SecRuleInheritance Off
SecDefaultAction log,deny,phase:1,redirect:http://www.site2.com=20
=2E..=20
</VirtualHost> =20

<VirtualHost *:80>=20
ServerName app2.com=20
ServerAlias www.app2.com
SecRuleInheritance On Se=
cRule ARGS "attack"=20
=2E..=20
</VirtualHost>

    Possible values are:

    • On - inherit rules from the parent context.

    • Off<= /code> - do not inherit rules from the parent context.

    SecRuleEng= ine

    <= strong>Description: Configures the rules engine.

    Syntax: SecRuleEngine On|Off|DetectionOnly=

    Example Usage: SecRuleEngine On

    Processing Phase: Any

    Scope: Any

    Dependencies/Notes: Thisdirective can also be controled by the ctl action (ctl:ruleEngine=3Doff) = for per rule processing.

    Possible values are:

    • On - process rules.

    • Off = - do not process rules.

    • DetectionOnly= - process rules but never intercept transactions, even when rules are configured to do so.

    SecRuleRemo= veById

    Description: Removes matching rules from the parent contexts.

    Syntax: SecRuleRemoveById= RULEID

    Example Usage: SecRuleRemoveByID 1 2 "9000-9010"=

    Processing Phase:= Any

    Scope:= Any

    Dependencies/Notes:<= /span> This directive supports multiple parameters, where each parameter ca= n either be a rule ID, or a range. Parameters that contain spaces must b= e delimited using double quotes.

    SecRuleRemoveById 1 2 5 10-20 "400-556" 673

    SecRuleRemo= veByMsg

    Description: Removes matching rules from the parent contexts.

    Syntax: SecRuleRemoveByMs= g REGEX

    Example Usage: SecRuleRemoveByMsg "FAIL"<= /p>

    Processing Phase: = Any

    Scope: Any

    =

    Dependencies/Notes: T= his directive supports multiple parameters. Each parameter is a reg= ular expression that will be applied to the message (specified using= the msg action).

    SecServerSi= gnature

    Description: Instructs ModSecurity to change the data presented in the "Server:" respo= nse header token.

    Syntax: SecServerSignature "WEB SERVER SOFTWARE"

    Example Usa= ge: SecServerSignature "Netscape-Enterprise/6.0"

    Processing Phase: N/A

    Scope: Main

    Dependencies/Notes: In order for this directive to work, you must set the Apache ServerTokens di= rective to Full. ModSecurity will overwrite the server signature data h= eld in this memory space with the data set in this directive. If Serve= rTokens is not set to Full, then the memory space is most likely not la= rge enough to hold the new data we are looking to insert.

    =

    S= ecTmpDir

    Description: Configures the directory where temporary files will be created.

    Syntax: = SecTmpDir /path/to/dir

    Exam= ple Usage: SecTmpDir /tmp

    Processing Phase: N/A

    Scope: Any=

    Dependencies/Notes: Needs to be writable by the Apache user process. This is the directory loca= tion where Apache will swap data to disk if it runs out of memory (m= ore data than what was specified in the SecRequestBodyInMemoryLimit dire= ctive) during inspection.

    =

    SecUploadDir

    =

    Description: Configures the directory where intercepted files will be stored.

    Syntax: SecUploadDir /path/to/dir

    = Example Usage: SecUploadDir /= tmp

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes: This directory must be on the same filesystem as the temporary direc= tory defined with SecTmpDir. This directive is used with SecUploadKeepFil= es.

    <= code class=3D"literal">SecUploadKeepFiles

    Description: Configures whether or not the intercepted files will be kept after transaction is processed.

    Syntax:<= /span> SecUploadKeepFiles On|Off|RelevantOnly=

    Example Usage: SecUploadKeepFiles On

    Processing Phase: N/A

    <= span class=3D"bold">Scope: Any

    Dependencies/Notes: This directive requires the storage directory to be defined (using <= code class=3D"literal">SecUploadDir).

    Possible values ar= e:

    • On - Keep uploaded files.

    • Off - = Do not keep uploaded files.

    • RelevantOnly<= /code> - This will keep only those files that belong to requests that are deem= ed relevant.

    SecWebAppId

    Descriptio= n: Creates a partition on the server that belongs to one web application.

    Syntax: SecWebAppId "NAME"

    Exampl= e Usage: SecWebAppId "WebApp1= "

    Processing Phase: N/A

    Scope: Any

    Dependencies/Notes:= Partitions are used to avoid collisions between session IDs and user IDs. = This directive must be used if there are multiple applications deplo= yed on the same server. If it isn't used, a collision between session = IDs might occur. The default value is default. Example:

    <VirtualHost *:80&=
gt;=20
ServerName app1.com=20
ServerAlias www.app1.com
SecWebAppId "App1"
SecRule REQUEST_COOKIES:PHPSESSID !^$ chain,nolog,pass=20
SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}=20
=2E..=20
</VirtualHost> =20

<VirtualHost *:80>=20
ServerName app2.com=20
ServerAlias www.app2.com
SecWebAppId "App2"
SecRule REQUEST_COOKIES:PHPSESSID !^$ chain,nolog,pass=20
SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}=20
=2E..=20
</VirtualHost>

    In the two examples configurations shown= , SecWebAppId is being used in conjuction with the Apache VirtualHost directives. What= this achieves is to create more unique collection names when being h= osted on one server. Normally, when setsid is used, ModSecurity will cre= ate a collection with the name "SESSION" and it will hold the value s= pecified. With using SecWebAppId as shown in the examples, however, the n= ame of the collection would become "App1_SESSION" and "App2_SESSION".<= /p>

    SecWebAppId is relevant in two cases:

    1. You are logging transactions/alerts to the= ModSecurity Console and you want to use the web application ID to search only t= he transactions belonging to that application.

    2. = You are using the data persistence facility (collections SESSION and USER) and you need to avoid collisions between = sessions and users belonging to different applications.

    Processing Phases

    =

    ModSecurity 2.x allows rules to be placed in one of th= e following five phases:

    1. = Request headers

    2. Request body

    3. Response h= eaders

    4. Response body

    5. Logging

    ModSecurity Processing Phase= s Diagram

    Below is a diagram of the standard Apache Request Cycle. In the diagram, the 5 ModSecurity processing phase= s are shown.

    In order to se= lect the phase a rule executes during, use the phase action either directly in the rule or in using the SecDefaultAction directive:

    SecDefaultAction "log,pass,phase:2" SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1"

    Note o= n Rule and Phases

    Keep in mind that rules are e= xecuted according to phases, so even if two rules are adjacent in a configuration file, but are set to ex= ecute in different phases, they would not happen one after the other. The = order of rules in the configuration file is important only within the rule= s of each phase. This is especially important when using the skip action.

    Phase Requ= est Headers

    Rules in this phase a= re processed immediately after Apache completes reading the request headers (post-read-request phase)= . At this point the request body has not been read yet, meaning not all r= equest arguments are available. Rules should be placed in this phase i= f you need to have them run early (before Apache does something with = the request), to do something before the request body has been read= , determine whether or not the request body should be buffered, o= r decide how you want the request body to be processed (e.g. whether to = parse it as XML or not).

    Note

    Rules in this phase can not leverage Apache scope dire= ctives (Directory, Location, LocationMatch, etc...) as the post-read-r= equest hook does not have this information yet. The exception here is = the VirtualHost directive. If you want to use ModSecurity rules ins= ide Apache locations, then they should run in Phase 2. Refer to the= Apache Request Cycle/ModSecurity Processing Phases diagram.

    <= div class=3D"section" lang=3D"en">
    =

    Phase Request Body

    This is the general-purpose input analys= is phase. Most of the application-oriented rules should go here. In this phase you ar= e guaranteed to have received the request argument (provided the = request body has been read). ModSecurity supports three encoding types = for the request body phase:

    • application/x-www-form-urlen= coded - used to transfer form data

    • m= ultipart/form-data - used for file transfers

    • text/xml - used for passing XML data

    Other encodin= gs are not used by most web applications.

    Phase Response Headers

    This phase takes place just before response headers a= re sent back to the client. Run here if you want to observe the response bef= ore that happens, and if you want to use the response headers to determi= ne if you want to buffer the response body. Note that some response statu= s codes (such as 404) are handled earlier in the request cycle by Apach= e and my not be able to be triggered as expected. Additionally, there ar= e some response headers that are added by Apache at a later hook (such= as Date, Server and Connection) that we would not be able to trigger on = or sanitize. This should work appropirately in a proxy setup or wi= thin phase:5 (logging).

    =

    Phase Response Body

    This= is the general-purpose output analysis phase. At this point you can run rules against the response body (provided it was bu= ffered, of course). This is the phase where you would want to inspect t= he outbound html for information discloure, error messages or fail= ed authentication text.

    Phase Logging

    This pha= se is run just before logging takes place. The rules placed into this phase can only affect how the logging is perfo= rmed. This phase can be used to inspect the error messages logged by = Apache. You can not deny/block connections in this phase as it is too l= ate. This phase also allows for inspection of other response headers that= weren't available during phase:3 or phase:4.

    Variabl= es

    The following variables are su= pported in ModSecurity 2.x:

    ARGS

    =

    ARGS is a collection and can = be used on its own (means all arguments including the POST Payload), with a static parameter (matches arguments with that name), or with a regular expression (matches all arguments with name that matches the re= gular expression). Note: ARGS:p will n= ot result in any invocations against the operator if argument p does not exist. = Some variables are actually collections, which are expanded into mor= e variables at runtime. The following example will examine all re= quest arguments:

    SecRule ARGS dirty
      Sometimes, however, you will want to look only at parts of a co=
llection.
      This can be achieved with the help of the selection
      operator(colon). The following example will only lo=
ok at the
      arguments named p (do note that,=
 in
      general, requests can contain multiple arguments with the same =
name):
      
    SecRule ARGS:p dirty
    
      It is also possible to specify exclusions. The following will e=
xamine
      all request arguments for the word=
 dirty, except
      the ones named z (again, there c=
an be
      zero or more arguments named z):
      
    SecRule ARGS|!ARGS:z dirty
    
      There is a special operator that allows you to count how many v=
ariables
      there are in a collection. The following rule will trigger if t=
here is
      more than zero arguments in the request (ignore the second para=
meter for
      the time being): 
    SecRule &ARG=
S !^0$
    
      And sometimes you need to look at an array of parameters, each =
with a
      slightly different name. In this case you can specify a regular
      expression in the selection operator itself. The following rule=
 will
      look into all arguments whose names begin with id_: 
    SecRule ARGS:/^id_/=
 dirty
    Note
    In ModSecurity 1.X,=
 the ARGS variable stood
        for QUERY_STRING + POST_PAYLOAD,
        whereas now it expands to to individual variables.
    <=
/div>
    ARGS_COMBINED_SIZE
    Thi=
s variable allows you to set more targeted evaluations on the
      total size of the Arguments as compared with normal Apache Limi=
tRequest
      directives. For example, you could create a rule to ensure that=
 the
      total size of the argument data is below a certain threshold (t=
o help
      prevent buffer overflow issues). Example: Block request if the =
size of
      the arguments is above 25 characters.
    SecRule REQUEST_FILENAME "^/cgi-bin/login\.php$" "chain,log,d=
eny,phase:2"
SecRule ARGS_COMBINED_SIZE "@gt 25"

    <= code class=3D"literal">ARGS_NAMES

    <= /div>

    Is a collection of the argument names. You can search for spe= cific argument names that you want to block. In a positive policy sce= nario, you can also whitelist (using an inverted rule with the ! chara= cter) only authorized argument names. Example: This example rule will= only allow 2 argument names - p and a. If any other argument names a= re injected, it will be blocked.

    =
SecRule REQUEST_FILENAME "/index.php" "chain,log,deny,status:403,phas=
e:2"
SecRule ARGS_NAMES "!^(p=
|a)$"

    AUTH_TYPE

    = This variable holds the authentication method used to validate a user. Example:

    SecRule AUTH_TYPE "basic" log,deny,stat=
us:403,phase:1,t:lowercase

    Note<= /strong>

    This data will not be available in a proxy-mode= deployment as the authentication is not local. In a proxy-mode deployment, you wo= uld need to inpect the REQUEST_HEADERS:Authoriza= tion header.

    <= code class=3D"literal">ENV

    Collection, requires a single parameter (after a colon character). The ENV variable is set with setenv and does not give access to= the CGI environment variables. Example:

    SecRule REQUEST_FILENAME "printenv" pass,setenv:tag=3Dsuspicious
SecRule ENV:tag "suspici=
ous"

    FILES

    Colle= ction. Contains a collection of original file names (as they were called on the remote user's file system). Note: only avail= able if files were extracted from the request body. Example:

    SecRule FILES "\.conf$" log,deny,status:403,phase:2

    FILES_CO= MBINED_SIZE

    Single value. = Total size of the uploaded files. Note: only available if files were extracted from the request body. Exampl= e:

    SecRule FILES_COMBINED_SIZE "@gt 1000" log,deny,status:40=
3,phase:2

    <= code class=3D"literal">FILES_NAMES

    =

    Collection w/o parameter. Contains a list of form fields tha= t were used for file upload. Note: only available if files were extrac= ted from the request body. Example:

    Sec=
Rule FILES_NAMES "^upfil=
e$" log,deny,status:403,phase:2

    FILES_SIZES

    Collection. Contains a list of file sizes= . Useful for implementing a size limitation on individual uploaded files. Note: only avai= lable if files were extracted from the request body. Example:

    SecRule FILES_SIZ=
ES "@gt 100" log,deny,status:403,phase:2
    <= div class=3D"section" lang=3D"en">
    =

    FI= LES_TMPNAMES

    Collection. C= ontains a collection of temporary files' names on the disk. Useful when used together with @i= nspectFile. Note: only available if files were extracted from the request body. Example:

    SecRule FILES_TMPNAM=
ES "@inspectFile /path/to/inspect_script.pl"
    <= div>

    HTTP_

    This variable is a= special prefix that is followed by a header name and can be used to access any request header. Example:

    = 
    SecRule HT=
TP_REFERER "www\.badsite\.com"

    Note

    This variable is for bac= kward-compatibilty with ModSecurity 1.X rules. It has been superceded by the REQUEST_HEADERS variable (REQUEST_HEADERS:Headername)

    MULTIPART_CRLF_LF_LINES

    This flag variable will be set to 1 whenever a multipart request uses mixed line terminators. The multipart/form-data RFC requires CRLF sequence to be used to term= inate lines. Since some client implementations use only LF= to terminate lines you might want to allow them to proceed under certain circumstances (if you want to do this you will need to stop usi= ng MULTIPART_STRICT_ERROR and check= each multipart flag variable individually, avoding MULTIPAR= T_LF_LINE). However, mixing CRLF and LF line terminators is dangerous as it can allow for evasion. Therefore= , in such cases, you will have to add a check for MULTIPART_CRLF_LF_LINES.

    MULTIPART_STRICT_ERROR

    MULTIPART_STRICT_ERROR will be set to 1 when any of the following vari= ables is also set to 1: REQBO= DY_PROCESSOR_ERROR, MULTIPART_BOUNDARY_QUOTED, MULTIPART_BOUNDARY_WHITESPACE, MULTIPART_DATA_BEFORE, MULTIPART_DATA_AFTER, MULTIPART_HEADER_FOLDING, MULTIPART_LF_LINE, MULTIPART_SEMICOLON_MISSING. Eac= h of these variables covers one unusual (although sometimes legal) aspect of the req= uest body in multipart/form-data format. Y= our policies should always contain a rule = to check either this variable (easier) or one or more individual variables (if you know exact= ly what you want to accomplish). Depending on the rate of false positiv= es and your default policy you should decide whether to block or just = warn when the rule is triggered.

    The best way to use this variable = is as in the example below:

    SecRule MULTIPART_STRIC=
T_ERROR "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_SEMICOLON_MISSING}'"

    The multipart/form-data parser has been upgraded in ModSecurity v2.1.3 to actively look for signs of ev= asion. Many variables (as listed above) were added to expose various f= acts discovered during the parsing process. The MULTIPART_STRICT_ERROR variable = is handy to check on all abnormalities at once. The individual variables allow detec= tion to be fine-tuned according to your circumstances in order to reduc= e the number of false positives. Detailed analysis of various evasion techniques covered will be released as a separated document at = a later date.

    <= code class=3D"literal">MULTIPART_UNMATCHED_BOUNDARY

    =

    Set to 1 whe= n, during the parsing phase of a multipart/request-body, ModSecur= ity encounters what feels like a boundary but it is not. Such an event may occur wh= en evasion of ModSecurity is attempted.

    The best wasy to use= this variable is as in the example below:

    SecRule MULTIPART_UNMAT=
CHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible un=
matched boundary.'"

    Change the rule from blocking to logging-= only if many false positives are encountered.

    PATH_INFO

    <= /div>

    Besides passing query information to a scrip= t/handler, you can also pass additional data, known as extra path information, as = part of the URL. Example:

    SecRule PATH_INFO "^/(bin|etc|sbin|o=
pt|usr)"

    <= code class=3D"literal">QUERY_STRING

    This variable holds form data passed to the script/handler = by appending data after a question mark. Warning: Not URL-decoded. Example:

    SecRule QUERY_STRING "attack"
    <= h3 class=3D"title">REM= OTE_ADDR

    This variable hol= ds the IP address of the remote client. Example:

    SecRule REMOTE_ADDR "^192\.168\.1\.101$"
    =

    REMOTE_HOST

    If Hos= tnameLookUps are set to On, then this variable will hold the DNS resolved remote host name. If it is set to Off, then it wil= l hold the remote IP address. Possible uses for this variable would be= to deny known bad client hosts or network blocks, or conversely, to all= ow in authorized hosts. Example:

    Sec=
Rule REMOTE_HOST "\.evil=
\.network\org$"

    REMOTE_USER

    This variable holds the username o= f the authenticated user. If there are no password (basic|digest) access controls in place, = then this variable will be empty. Example:

    SecRule REMOTE_USER "=
admin"

    Note

    <= p>This data will not be available in a proxy-mode deployment as the authentication is not local.

    REQBODY_PROCESSOR

    Built-in processors are URLENCODED, MULTIPART, and XML. Example:

    SecRule REQBODY_PROCESSOR "^XML$ chain
SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd"
    <= div>

    REQBODY_PROCESSOR_ERROR

    = Possible values are 0 (no error) or 1 (error). This variable will be set by request body processors (typically the multipart/request-data parser = or the XML parser) when they fail to properly parse a request payload.

    Examp= le:

    SecRule REQBODY_PROCESSOR_ERROR "@eq 1" deny,phase:2
    Note
    Your policies must have a rule to check
        REQBODY_PROCESSOR_ERROR at the beginning of phase 2. Failure =
to do so
        will leave the door open for impedance mismatch attacks. It i=
s
        possible, for example, that a payload that cannot be parsed b=
y
        ModSecurity can be successfully parsed by more tolerant parse=
r
        operating in the application. If your policy dictates blockin=
g then
        you should reject the request if error is detected. When oper=
ating in
        detection-only mode your rule should alert with high severity=
 when
        request body processing fails.

    REQBODY_PROCESSO= R_ERROR_MSG

    Empty, or cont= ains the error message from the processor. Example:

    SecRule REQBODY_PROCESSOR_ERROR_MSG "faile=
d to parse" t:lowercase

    REQUEST_BASENAME

    <= /div>

    This variable holds just the filename part o= f REQUEST_FILENAME (e.g. index.php= ). Warning: not urlDecoded. Example:

    SecRule <=
span class=3D"bold">REQUEST_BASENAME "^login\=
.php$"

    REQUEST_BODY

    This variable holds the data in the request body (including POST_PAYLOAD data). REQUEST_BODY should be used if the original= order of the arguements is important (ARGS should be used in all other c= ases). Example:

    SecRule REQUEST_BODY "^username=3D\w{25,}\&=
amp;password=3D\w{25,}\&Submit\=3Dlogin$"

    Note

    This variable is only av= ailable if the content type is application/x-www-form-urlencoded.

    REQUEST_COOKIES

    This variable is a collection = of all of the cookie data. Example: the following example is using the Ampersand special operator t= o count how many variables are in the collection. In this rule, it woul= d trigger if the request does not include any Cookie headers.

    SecRule &REQUE=
ST_COOKIES "@eq 0"

    REQUEST_COOKIES_NAMES

    This variable is a collectio= n of the cookie names in the request headers. Example: the following rule will trigger if the JSESSI= ONID cookie is not present.

    SecRule=
 &REQUEST_COOKIES_NAMES:JSESSIONID "@eq 0"
    =

    REQUEST_FILENAME

    This variable holds the relative REQUEST_URI = minus the QUERY_STRING part (e.g. /index.php). Example:

    SecRule REQUEST_FILE=
NAME "^/cgi-bin/login\.php$"

    REQUEST_HEA= DERS

    This variable can be = used as either a collection of all of the Request Headers or can be used to specify indivudual headers (b= y using REQUEST_HEADERS:Header-Name). Example: the first example uses REQUEST_HEADERS as a collection and is applying th= e validateUrlEncoding operator against all headers.

    SecRule REQUEST_HEAD=
ERS "@validateUrlEncoding"

    Example: the secon= d example is targeting only the Host header.

    SecRule REQUEST_HEADERS:Host "^[\d\.]+$" \
    "deny,log,status:400,msg:'Host header is a numeric IP address'"

    REQUEST_HEADERS_NAMES

    =

    This variable is a collection of the names of all of the Req= uest Headers. Example:

    SecRule REQUEST_HEADERS_NAMES "^x-fo=
rwarded-for" \
    "log,deny,status:403,t:lowercase,msg:'Proxy Server Used'"
    =

    REQUEST_LINE

    This varia= ble holds the complete request line sent to the server (including the REQUEST_METHOD and HTTP version data). Example: = this example rule will trigger if the request method is something ot= her than GET, HEAD, POST or if the HTTP is something other than HTTP/0.9= , 1.0 or 1.1.

    SecRule REQUEST_LINE "!(^((?:(?:pos|ge)t|head))|h=
ttp/(0\.9|1\.0|1\.1)$)"

    Note

    Due to the default action transformation function = lowercase, the regex strings should be in lowercase as well unless the t:none transformation function is specified for this particular rule.<= /p>

    =

    REQUEST_METHOD

    Thi= s variable holds the Request Method used by the client. Example: the following example will trigger if the Request Meth= od is either CONNECT or TRACE.

    SecRu=
le REQUEST_METHOD "^((?:=
connect|trace))$"

    Note<= /span>

    Due to the default action transformation function lowerc= ase, the regex strings should be in lowercase as well unless the t:none transformation function is specified for this particular rule.<= /p>

    =

    REQUEST_PROTOCOL

    T= his variable holds the Request Protocol Version information. Example:

    SecRule REQUEST_PROTOCOL "!^http/(0\.9|1\.0=
|1\.1)$"

    Note

    Due to the default action transformation function lowercase, the regex strings should be in lowercase as well unless the t:none transformation function is specified for this particular rule.<= /p>

    =

    REQUEST_URI

    This v= ariable holds the full URL including the QUERY_STRING data (e.g. /index.php?p=3DX), however it will never contain a domain= name, even if it was provided on the request line. Warning: not urlDecoded= . It also does not include either the REQUEST_METHOD or the HTTP version = info. Example:

    SecRule REQUEST_URI "attack"
    REQU= EST_URI_RAW

    Same as REQUES= T_URI but will contain the domain name if it was provided on the request line (e.g. http://www.example.com/index.php?p=3DX). Warning: not urlDecode= d. Example:

    SecRule REQUEST_URI_RAW "http:/"

    RESPONSE_BODY

    This variab= le holds the data for the response payload. Example:

    SecRule RESPONSE_BODY "ODBC Error Code"
    =

    RESPONSE_HEADERS

    T= his variable is similar to the REQUEST_HEADERS variable and can be used in the same manner. Example:

    SecRule RESPONSE_HEADERS=
:X-Cache "MISS"
    Note
    This v=
ariable may not have access to some headers when running in
      embedded-mode. Headers such as Server, Date, Connection and Con=
tent-Type
      are added during a later Apache hook just prior to sending the =
data to
      the client. This data should be available, however, either duri=
ng
      ModSecurity phase:5 (logging) or when running in proxy-mode.

    RESPONSE_HEADERS_NAMES

    =

    This variable is a collection of the response header names. Example:

    SecRule RESPONSE_HEADERS_NAMES "Set-Cookie"=

    Note

    Same= limitations as RESPONSE_HEADERS with regards to access to some headers in embedded-mode.

    RESPONSE_PROTOCOL=

    This variable holds the HTTP Res= ponse Protocol information. Example:

    SecRule RESPONSE_PROTOCOL "^HTTP\/0\.9"
    <= div>

    RESPONSE_STATUS

    Thi= s variable holds the HTTP Response Status Code generated by Apache. Example:

    SecRule RESPONSE_STATUS "^[45]"
    =

    Note

    This direc= tive may not work as expected in embedded-mode as Apache handles many of the stock response codes (404, 401, etc...) ear= lier in Phase 2. This variable should work as expected in a proxy-mode deployment.

    SCRIPT_BASENAME

    <= /div>

    This variable holds just the local filename = part of SCRIPT_FILENAME. Example:

    SecR=
ule SCRIPT_BASENAME "^lo=
gin\.php$"

    Note<= /p>

    This variable is not available in proxy mode.

    SCRIPT_FI= LENAME

    This variable holds= the full path on the server to the requested script. (e.g. SCRIPT_NAME plus the server path). Example:

    SecRule SCRI= PT_FILENAME "^/usr/local/apache/cgi-bin/login\.php$"<= /pre>

    Note

    This = variable is not available in proxy mode.

    SCRIPT_GID

    This variable holds the groupid (nu= merical value) of the group owner of the script. Example:

    =
SecRule SCRIPT_GID "!^46=
$"

    Note

    Th= is variable is not available in proxy mode.

    SCRIPT_GROUPNAME<= /code>

    This variable holds the gr= oup name of the group owner of the script. Example:

    SecRule SCRIPT_GROUPNAME "!^apache$"<=
/pre>
    Note
    This =
variable is not available in proxy mode.

    SCRIPT_MODE

    This variable holds the script's p= ermissions mode data (numerical - 1=3Dexecute, 2=3Dwrite, 4=3Dread and 7=3Dread/write/execute).= Example: will trigger if the script has the WRITE permissions set.

    SecRule SCRIPT_MO=
DE "^(2|3|6|7)$"

    Note

    This variable is not available in proxy m= ode.

    SCRIPT_UID

    Th= is variable holds the userid (numerical value) of the owner of the script. Example: the example rule below will trigger if the= UID is not 46 (the Apache user).

    SecR=
ule SCRIPT_UID "!^46$"
    Note
    This v=
ariable is not available in proxy mode.

    SCRIPT_USERNAME

    This variable holds the usernam= e of the owner of the script. Example:

    SecRule SCRIPT_USERNAME "!^apache$"
    Note

    This variabl= e is not available in proxy mode.

    SERVER_ADDR

    This variable contains the IP address of = the server. Example:

    SecRule SERVER_ADDR "^192\.168\.1\.100$"

    SERVER_NAME

    T= his variable contains the server's hostname or IP address. Example:

    SecRule SERVER_NAME "hostname\.com$"
    <= p>Note

    This data i= s taken from the Host header submitted in the client request.

    <= code class=3D"literal">SERVER_PORT

    =

    This variable contains the local port that the web server is listening on. Example:

    SecRule=
 SERVER_PORT "^80$"

    SESSION

    This variabl= e is a collection, available only after setsi= d is executed. Example: the following example shows how to initialize a SESSION collection with setsi= d, how to use setvar to increase the session.score values, how to set the session.blocked variable and finally how to deny the connection= based on the session:blocked value.

    Sec=
Rule REQUEST_COOKIES:PHPSESSID !^$ chain,nolog,pass
SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}
SecRule REQUEST_URI "^/cgi-bin/finger$" "pass,log,setvar:session.score=3D+10"
SecRule SESSION:SCORE "@=
gt 50" "pass,log,setvar:session.blocked<=
/strong>=3D1"
SecRule SESSION:BLOCKED =
"@eq 1" "log,deny,status:403"

    SESSIONID

    <= /div>

    This variable is the value set with setsid. Example:

    SecRule SESSIONID !^=
$ chain,nolog,pass
SecRule REQUEST_COOKIES:PHPSESSID !^$
SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}

    TIME=

    This variable holds a formatted = string representing the time (hour:minute:second). Example:

    SecRule TIME "^(([1](8|=
9))|([2](0|1|2|3))):\d{2}:\d{2}$"

    TIME_DAY

    This variable holds the current date (1-31= ). Example: this rule would trigger anytime between the 10th and 20th days of the month.

    SecRule TIME_DAY "^(([1](0|1|2|3|4|5|6|7|8|=
9))|20)$"

    <= code class=3D"literal">TIME_EPOCH

    <= /div>

    This variable holds the time in seconds since 1970. Example:

    SecRule TIME_EPOCH "@gt 1000"
    <= h3 class=3D"title">TIM= E_HOUR

    This variable holds= the current hour (0-23). Example: this rule would trigger during "off hours".

    SecRule TIME_HOUR "^=
(0|1|2|3|4|5|6|[1](8|9)|[2](0|1|2|3))$"

    TIME_MIN

    This variable holds the current minu= te (0-59). Example: this rule would trigger during the last half hour of every hour.

    SecRule TIME_MI=
N "^(3|4|5)"

    TIME_MON

    This variable holds the current month (0-11).= Example: this rule would match if the month was either November (10) or December (11).

    SecRule TIME_MON "^1"

    TIME_SEC<= /h3>

    This variable holds the current s= econd count (0-59). Example:

    SecRule TIME_SEC "@gt 30"

    TIME_WD= AY

    This variable holds the= current weekday (0-6). Example: this rule would trigger only on week-ends (Saturday and Sunday).

    SecRule TIME_WD=
AY "^(0|6)$"

    TIME_YEAR

    <= /div>

    This variable holds the current four-digit y= ear data. Example:

    SecRule TIME_YEAR "^2006$"

    TX

    Transaction Collection. This = is used to store pieces of data, create a transaction anomaly score, and so on. Transaction vari= ables are set for 1 request/response cycle. The scoring and evaluation wi= ll not last past the current request/response process. Example: In thi= s example, we are using setvar to increase the tx.score value by = 5 points. We then have a follow-up run that will evaluate the transaction= al score this this request and then it will decided whether or not to al= low/deny the request through.

    SecRule W=
EBSERVER_ERROR_LOG "does not exist" "phase:5,pass,setvar:tx.score=3D+5"
SecRule TX:SCORE "@gt 20=
" deny,log

    <= code class=3D"literal">USERID

    This variable is the value set with setui= d. Example:

    SecAction setuid:=
%{REMOTE_USER},nolog
SecRule USERID "Admin"

    WEBAPPID

    This= variable is the value set with SecWebAppId. Example:

    SecWebAppId "WebApp1=
"
SecRule WEBAPPID "WebApp=
1" "chain,log,deny,status:403"
SecRule REQUEST_HEADERS:Transfer-Encoding "!^$"

    WEBSERVER_E= RROR_LOG

    Contains zero or = more error messages produced by the web server. Access to this variable is in phase:5 (logging). Example:

    SecRule WEBS= ERVER_ERROR_LOG "File does not exist" "phase:5,setvar= :tx.score=3D+5"

    Can be used standalone (as a target for validateDTD and validateSchema) or with an XPath expression parameter (which ma= kes it a valid target for any function that accepts plain text). Example= using XPath:

    SecDefaultAction log,de=
ny,status:403,phase:2
SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \
    phase:1,t:lowercase,nolog,pass,ctl:requestBodyProcessor=3DXML
SecRule REQBODY_PROCESSOR "!^XML$" skip:2
SecRule XML:/employees/employee/name/tex=
t() Fred
SecRule XML:/xq:employees/employee/name/=
text() Fred \
    xmlns:xq=3Dhttp://www.example.com/employees

    The first XPa= th expression does not use namespaces. It would match against payload such as this one:

    <employees>
    <employee>
        <name>Fred Jones</name>
        <address location=3D"home">
            <street>900 Aurora Ave.</street>
            <city>Seattle</city>
            <state>WA</state>
            <zip>98115</zip>
        </address>
        <address location=3D"work">
            <street>2011 152nd Avenue NE</street>
            <city>Redmond</city>
            <state>WA</state>
            <zip>98052</zip>
        </address>
        <phone location=3D"work">(425)555-5665</phone>
        <phone location=3D"home">(206)555-5555</phone>
        <phone location=3D"mobile">(206)555-4321</phone>
    </employee>
</employees>

    The second XPath expression does use names= paces. It would match the following payload:

    <xq:=
employees xmlns:xq=3D"http://www.example.com/employees">
    <employee>
        <name>Fred Jones</name>
        <address location=3D"home">
            <street>900 Aurora Ave.</street>
            <city>Seattle</city>
            <state>WA</state>
            <zip>98115</zip>
        </address>
        <address location=3D"work">
            <street>2011 152nd Avenue NE</street>
            <city>Redmond</city>
            <state>WA</state>
            <zip>98052</zip>
        </address>
        <phone location=3D"work">(425)555-5665</phone>
        <phone location=3D"home">(206)555-5555</phone>
        <phone location=3D"mobile">(206)555-4321</phone>
    </employee>
</xq:employees>

    Note the different namespace used in th= e second example.

    To learn more about XPath we suggest the foll= owing resources:

    1. = XPath Standard

    2. XPath Tutorial

    When = ModSecurity receives request or response information, it makes a copy of this data and places it into memory. It is on this data= in memory that transformation functions are applied. The raw request= /response data is never altered. Transformation functions are used to trans= form a variable before testing it in a rule.

    = Note

    The default transformation functio= n setting is - lowercase, replaceNulls and compressWhitespace (in this order).

    The fo= llowing rule will ensure that an attacker does not use mixed case in order to evade the ModSecurity rule:

    SecRule ARG:p "xp_cmdshell" =
"t:lowercase"
    multiple tranformation actions can be used in the same rule, for example t= he following rule also ensures that an attacker does not use URL enc= oding (%xx encoding) for evasion. Note the order of the transformation functions, which ensures that a URL encoded letter is first decod= ed and than translated to lower case.

    SecRule ARG:p "xp_cmdshell" "t:urlDeco=
de,t:lowercase"

    One can use the SetDefaul= tAction command to ensure the translation occurs for every rule until the next. Note that translation actio= ns are additive, so if a rule explicitly list actions, the translation a= ctions set by SetDefaultAction are still performed.

    SecDefaultAction t:u=
rlDecode,t:lowercase

    The following transf= ormation functions are supported:

    base64Decode

    This function decoes a base64-encoded stri= ng.

    base64Encode

    = This function encodes input string using base64 encoding.

    <= h3 class=3D"title">com= pressWhitespace

    This funct= ion is enabled by default. It converts whitespace characters (32, \f, \t, \n, \r, \v, 160) to spaces (ASCII 32) a= nd then compresses multiple space characters into only one.

    <= h3 class=3D"title">esc= apeSeqDecode

    This function= decode ANSI C escape sequences: \a, \b, \f, \n, \r, \t, \v, \\, \?, \', \", \xHH (hexadecimal), \0OOO (octal). Invalid encodings are left in the output.

    hexEnco= de

    This function encodes i= nput as hex-encoded string.

    htmlEntityDecode

    <= /div>

    This function decodes HTML entities pr= esent in input. The following variants are supported:

    • &#xHH a= nd &#xHH; (where H is any hexadeci= mal number)

    • &#DDD and &#DDD; (where D is any de= cimal number)

    • &quot and &quot;

    • &nbsp and &am= p;nbsp;

    • &lt = and &lt;

    • &gt and &gt;

    = lowercase

    This function is enabled by default. It converts all char= actes to lowercase using the current C locale.

    md5

    This function calculates an MD5 hash fr= om input.

    none

    This not an actual transformation functio= n but an instruction to ModSecurity to remove all transformation functions associated w= ith the current rule and start from scratch.

    normalisePath

    This function will remove mult= iple slashes, self-references and directory back-references (except when they are at the beginnin= g of the path).

    <= code class=3D"literal">normalisePathWin

    <= /div>

    Same as normalisePath, but will first convert backslash= characters to forward slashes.

    removeNulls

    =

    This function removes NULL bytes from input.

    <= /div>

    removeWhitespace

    This = function removes all whitespace characters.

    replaceComments

    This function replaces each= occurence of a C-style comments (/* ... */) with a single space (multiple consecutive occurences of a space will not be compres= sed). Unterminated comments will too be replaced with a space (ASCII = 32). However, a standalone termination of a comment (*/) will not be acted upon.

    replaceNull= s

    This function is enabled= by default. It replaces NULL bytes in input with spaces (ASCII 32).

    urlDecode

    This function decodes an URL-encoded inpu= t string. Invalid encodings (i.e. the ones that use non-hexadecimal characters, o= r the ones that are at the end of string and have one or two characte= rs missing) will not be converted. If you want to detect invalid e= ncodings use the @validateUrlEncoding operator. The transformational function should not be used agai= nst variables that have already been URL-decoded unless it is your = intention to perform URL decoding twice!

    urlDecodeUni

    =

    In addition to decoding %xx like urlDecode, urlDecodeUni also decodes %uXXXX encoding. If the code is in the rang= e of FF01-FF5E (the full width ASCII codes), then the higher byte= is used to detect and adjust the lower byte. Otherwise, only the lower = byte will be used and the higher byte zeroed.

    urlEncode

    This function encodes input using U= RL encoding.

    <= code class=3D"literal">sha1

    <= p>This function calculates a SHA1 hash from input.

    Ac= tions

    Each action belongs to one = of five groups:

    1. <= span class=3D"emphasis">Disruptive actions - are thos= e actions where ModSecurity will intercept the data. They can only appe= ar in the first rule in a chain.

    2. Non-disruptive actions - can appear anywhere.

    3. Flow ac= tions - can appear only in the first rule in a chain.

    4. = Meta-data actions(id, rev, severity, msg) - can only appear in the first rule in a chain.

    5. Data act= ions - can appear anywhere; these actions are completely passive and only serve to carry data u= sed by other actions.

    allow

    Description: Stops processing on a successful match and allows transaction to proceed.

    Action Group: Disruptive

    Example:

    SecRule REMOTE_ADDR "^1=
92\.168\.1\.100$" nolog,phase:1,allow

    Note

    The allow action only applies to the current processing phas= e. If your intent is to explicitly allow a request, then you should u= se the "ctl" action to turn the ruleEngine off - ctl:ruleEngine=3DOff.

    auditlog

    =

    Description: Marks the transaction for logging in the audit log.

    Action Group: Non-Disruptive

    Example:

    =
SecRule REMOTE_ADDR "^192\.168\.1\.100$" auditlog,phase:1,allow

    = Note

    The auditlog action is now explici= t if log is already specified.

    = chain

    Description:<= /strong> Chains the rule where the action is placed with the rule that immediately follo= ws it. The result is called a rule chain<= /em>. Chained rules allow for more complex rule matches where you want to use a num= ber of different VARIABLES to create a better rule and to help prevent= false positives.

    Action Group: Flow

    Example:

    # R=
efuse to accept POST requests that do
# not specify request body length=20
SecRule REQUEST_METHOD ^POST$ chain
SecRule REQUEST_HEADER:Content-Length ^$

    Note

    In programming language concepts,= think of chained rules somewhat similar to AND conditional statements. The actions specified in= the first portion of the chained rule will only be triggered if all= of the variable checks return positive hits. If one aspect of the chai= ned rule is negative, then the entire rule chain is negative. Also note = that disruptive actions, execution phases, metadata actions (id, rev= , msg) and skip actions can only be specified on by the chain starter rule.

    <= code class=3D"literal">ctl

    Description: The ctl ac= tion allows configuration options to be updated for the transaction.=

    Action Group: Non-Disruptive

    Example:

    =
# Parse requests with Content-Type "text/xml" as XML=20
SecRule REQUEST_CONTENT_TYPE ^text/xml nolog,pass,ctl:requestBodyProcessor=3DXML

    Note

    The following con= figuration options are supported:

    1. auditEngine

      2. <= li>

      auditLogParts

    2. debugLogLevel

    3. requestBodyAccess

    4. requestBodyLimit

    5. requestBodyProcessor

    6. = responseBodyAccess

    7. resp= onseBodyLimit

    8. ruleEngin= e

    With the exception of requestBodyProcessor, each configuration option correspo= nds to one configuration directive and the usage is identical.

    T= he requestBodyProcessor option allows you to configure the request body processor. By default ModSecurity will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body, respectively. A third processor, XML, is also supported, but it= is never used implicitly. Instead you must tell ModSecurity to use it by= placing a few rules in the REQUEST_HEADERS processing phase. After the request body was processed as XML y= ou will be able to use the XML-related features to inspect it.

    Re= quest body processors will not interrupt a transaction if an error occurs during parsing. Instead they will set variables REQBODY_PROCESSOR_ERROR and REQBODY_PROCESSOR_ERROR_MSG. These variables should be inspected in the REQUEST_BODY= phase and an appropriate action taken.

    <= code class=3D"literal">deny

    <= p>Description: Stops rul= e processing and intercepts transaction.

    Action Group: Disruptive

    Example:

    SecRule REQUEST_HEADERS:User-Agent "ni=
kto" "log,deny,msg:'Nikt=
o Scanners Identified'"

    deprecatevar

    Description: Decrement counter based on its age.

    Action Gro= up: Non-Disruptive

    Example: The following example will decrem= ent the counter by 60 every 300 seconds.

    SecAction d=
eprecatevar:session.score=3D60/300

    Note

    Counter values are always positive, mea= ning the value will never go below zero.

    drop

    <= /div>

    Description: Imm= ediately initiate a "connection close" action to tear down the TCP connection by = sending a FIN packet.

    Action Group: Disruptive

    Example: The following example initiat= es an IP collection for tracking Basic Authentication attempts. If the client goes over= the threshold of more than 25 attempts in 2 minutes, it will DROP s= ubsequent connections.

    SecAction initcol=
:ip=3D%{REMOTE_ADDR},nolog
SecRule ARGS:login "!^$" \
    nolog,phase:1,setvar:ip.auth_attempt=3D+1,deprecatevar:ip.auth_at=
tempt=3D20/120
SecRule IP:AUTH_ATTEMPT "@gt 25" \
    log,drop,phase:1,msg=
:'Possible Brute Force Attack"

    N= ote

    This action is extremely useful when respon= ding to both Brute Force and Denial of Service attacks in that, in both cases, you= want to minimize both the network bandwidth and the data returned to th= e client. This action causes error message to appear in the log "(9)Bad f= ile descriptor: core_output_filter: writing data to the network"

    exec

    Description: Executes an external script/binary supplied as parameter.

    Action Group: Non-Disruptive

    Example:

    =
SecRule REQUEST_URI "^/cgi-bin/script\.pl" \
    "log,exec:/usr/local/apache/bin/test=
.sh,phase:1"

    Not= e

    This directive does not effect a primary acti= on if it exists. This action will always call script with no parameters, but providin= g all information in the environment. All the usual CGI environment v= ariables will be there. You can have one binary executed per filter matc= h. Execution will add the header mod_security-executed to the list= of request headers. You should be aware that forking a threaded pr= ocess results in all threads being replicated in the new process. For= king can therefore incur larger overhead in multithreaded operation. The= script you execute must write something (anything) to stdout. If it do= esn't ModSecurity will assume execution didn't work.

    expireva= r

    Description: Configurescollection variable to expire after the given time in seconds.

    Action Group: Non-Disruptive

    Example:

    =
SecRule REQUEST_COOKIES:JSESSIONID "!^$" nolog,phase:1,pass,chain
SecAction setsid:%{REQUEST_COOKIES:JSESSIONID}
SecRule REQUEST_URI "^/cgi-bin/script\.pl" \
    "log,allow,setvar:session.suspicious=3D1,expirevar:session.suspicious=3D3600,phase:1"
    Note
    You shou=
ld use expirevar actions at the same time that you use
      setvar actions in order to keep the indended expiration time. I=
f they
      are used on their own (perhaps in a SecAction directive) the ex=
pire time
      could get re-set. When variables are removed from collections, =
and there
      are no other changes, collections are not written to disk at th=
e end of
      request. This is because the variables can always be expired ag=
ain when
      the collection is read again on a subsequent request.
    =

    i= d

    Description: Assigns a unique ID to the rule or chain.

    Action= Group: Metadata

    Example:

    SecRule &REQUEST_HEADERS:Host "@eq 0" \
    "log,id:60008,severi=
ty:2,msg:'Request Missing a Host Header'"

    Note

    These are the reserved ranges:

    • 1-99,999; rese= rved for local (internal) use. Use as you see fit but do not use this range for rules that are distribute= d to others.

    • 100,000-199,999; reserved for intern= al use of the engine, to assign to rules that do not have explicit IDs.

    • =

      200,000-299,999; reserved for rules published at modsecurity.org.

    • 300,000-399,999; reserved f= or rules published at gotroot.com.

    • 400,000-419,999; unused (availa= ble for reservation).

    • 420,000-429,999; reserved for ScallyWhack.

    • 430,000-899,999; unused (available f= or reservation).

    • 900,000-999,999; reserved for the C= ore Rules project.

    • 1,000,000 and above; unused (availa= ble for reservation).

    initcol

    Descriptio= n: Initialises a named persistent collection, either by loading data from storage or b= y creating a new collection in memory.

    Action Group: Non-Disruptive

    Example: The following example initiates I= P address tracking.

    SecAction initcol:ip=3D%{REMOTE_ADDR},nolog<=
/pre>
    Note
    Every=
 collection contains several built-in variables that are
      read-only:
    1. =
CREATE_TIME - date/time of
          the creation of the collection.
    2. KEY - the value of the
          initcol variable (the client's IP address in the example).<=
/p>
    3. LAST_UPDATE_TIME -
          date/time of the last update to the collection.
      4. TIMEOUT - date/time in
          seconds when the collection will be updated on disk from me=
mory (if
          no other updates occur).
    4. UPDATE_COUNTER - how many
          times the collection has been updated since creation.
    5. UPDATE_RATE - is the
          average rate updates per minute since creation.
    Collections are loaded into memory when the initcol action=
 is
      encountered. The collection in storage will be updated (and the
      appropriate counters increased) on=
ly if it was
      changed during transaction processing.
    Note
    To create a collection to hold session variables (SESSION) use action =
setsid. To create a collection to hold user
        variables (USER) use action
        setuid.
    Note
    At this time it is only possible to have thre=
e
        collections: IP, SESSION, and USER=
.

    log

    Description: Indicates that a successful match of the rule needs to be logged.

    Action Group: Non-Disruptive

    Example:

    =
SecAction initcol:ip=3D%{REMOTE_ADDR},lo=
g

    Note<= /span>

    This action will log matches to the Apache error log fil= e and the ModSecurity audit log.

    msg

    <= div>

    Description:= Assigns a custom message to the rule or chain.

    Action Group: Metadata

    Example:

    SecRule &REQUEST_HEADERS:Host "@eq 0" \
    "log,id:60008,severi=
ty:2,msg:'Request Missing a Host Header'=
"

    Note<= /span>

    The msg information appears in the error and/or audit lo= g files and is not sent back to the client in response headers.

    multiMatch

    Description: If enabled ModSecurity will perform multiple operator invocations for ever= y target, before and after every anti-evasion transformation is performed= .

    Action Group: Non-Disruptive

    Example:

    =
SecDefaultAction log,deny,phase:1,t:removeNulls,t:lowercase
SecRule ARGS "attack" multiMatch

    Note

    Normally, variables are evaluated once, only after all transformation functions have completed. With multiMatch, varia= bles are checked against the operator before and after every transformat= ion function that changes the input.

    = noauditlog

    =

    Descript= ion: Indicates that a successful match of the rule should not be used as criteria whe= ther the transaction should be logged to the audit log.

    Action Group: Non-Disruptive

    Example:

    =
SecRule REQUEST_HEADERS:User-Agent "Test" allow,=
noauditlog

    Note

    If the SecAuditEngine is set to On, all= of the transactions will be logged. If it is set to RelevantOnly, then you can control i= t with the noauditlog action. Even if the noauditlog action is applied= to a specific rule and a rule either before or after triggered an au= dit event, then the tranaction will be logged to the audit log. The= correct way to disable audit logging for the entire transaction is to u= se "ctl:auditEngine=3DOff"

    = nolog

    Description: Prevents rule matches from appearing in both the error and audit logs.

    = Action Group: Non-Disruptive

    Example:

    =
SecRule REQUEST_HEADERS:User-Agent "Test" allow,=
nolog

    No= te

    The nolog action also implies noauditlog.

    pass

    Description: Continues processing with the next rule in spite of a successful match.

    Action Group: Disruptive

    Example:

    SecRule REQUEST_HEADERS:Us=
er-Agent "Test" log,pass=

    Note

    Tran= saction will not be interrupted but it will be logged (unless logging has been suppressed).

    pause

    Description: Pauses transaction processing for the specified number of milliseconds.

    Action Group: Disruptive

    =

    Example:

    SecRule REQUEST_HEADERS:=
User-Agent "Test" log,deny,status:403,pa=
use:5000

    Note

    This feature can be of limited benefit for slowin= g down Brute Force Scanners, however use with care. If you are under a Denia= l of Service type of attack, the pause feature may make matters wors= e as this feature will cause child processes to sit idle until the pause = is completed.

    <= code class=3D"literal">proxy

    =

    Description: Intercep= ts transaction by forwarding request to another web server using t= he proxy backend.

    Action Group: Disruptive

    Example:

    SecRule REQUEST_HEADERS:User-Agent "Test" log,<=
strong>proxy:http://www.honeypothost.com/

    Note

    For this action = to work, mod_proxy must also be installed. This action is useful if you would like to proxy matching requests o= nto a honeypot webserver.

    redirect

    Description: Intercepts transaction by issuing a redirect to the given location.

    = Action Group: Disruptive=

    Example:

    SecRule REQUEST_HEAD=
ERS:User-Agent "Test" \
    log,redirect:http://www.hostname.com=
/failed.html

    Not= e

    If the status = action is present and its value is acceptable (301, 302, 303, or 307) it will be = used for the redirection. Otherwise status code 302 will be used.

    <= div>

    rev

    Description: Specifies rule revision.

    Action Group: Metadata

    Example:

    =
SecRule REQUEST_METHOD "^PUT$" "id:340002,rev:1,severity:2,msg:'Restricted HTTP function'"
    Note
    This ac=
tion is used in combination with the id action to allow the same rule ID to be used
      after changes take place but to still provide some indication t=
he rule
      changed.

    <= code class=3D"literal">sanitiseArg

    =

    Description: Sa= nitises (replaces each byte with an asterisk) a named request argument prior to a= udit logging.

    Action Group: Non-Disruptive

    Example:

    =
SecAction nolog,phase:2,sanitiseArg:pass=
word

    Note

    The sanitize actions do not sanitize any data within = the actual raw requests but only on the copy of data within memory that is= set to log to the audit log. It will not sanitize the data in the modsec_debug.log file (if the log level is set high enough to c= apture this data).

    Description: Sanitises the variable (request argument, request header, or response header)= that caused a rule match.

    Action = Group: Non-Disruptive

    Example: This action can be used to saniti= se arbitrary transaction elements when they match a condition. For example, the example = below will sanitise any argument that contains the word password in the name.

    SecRule ARGS_NAMES password nolog,pass,sanitiseMatched

    Note

    Same note as sanitiseArg.

    sanit= iseRequestHeader

    Description: Sanitises a named request header.

    Action Group= : Non-Disruptive

    Example: This will sanitise the data in th= e Authorization header.

    SecAction log,phase:1,=
sanitiseRequestHeader:Authorization

    Note=

    Same note as sanitiseArg.

    sanitiseResponseHeader

    De= scription: Sanitises a named response header.

    Action Grou= p: Non-Disruptive

    Example: This will sanitise the Set-Cookie= data sent to the client.

    SecAction log,phase:3,=
sanitiseResponseHeader:Set-Cookie

    Note

    Same note as sanitiseArg.

    severity

    Description: Assigns severity to the rule it is placed with.

    = Action Group: Metadata

    Example:

    SecRule REQUEST_METHOD "^PUT$" "id:340002,rev:1,<=
span class=3D"bold">severity:2,msg:'Restricte=
d HTTP function'"

    Note<= /span>

    The severity numbers follow the Syslog convention:

    • 0 =3D EMERGENCY

    • 1 =3D ALERT

    • 2 =3D CRITICAL

    • 3 =3D ERROR

    • 4 =3D WARNING

    • 5 =3D NOTICE=

    • 6 =3D INFO

    • 7 =3D DEBUG

    setuid

    Description: Special-purpose action that initialises the USER collection.

    Action Group: Non-Disruptive

    Example:

    =
SecAction setuid:%{REMOTE_USER}=
,nolog

    Note

    After initialisation takes place the variable USERID will be available for use in the subsequent rules.

    <= div class=3D"titlepage">

    setsid

    Description: Special-purposeaction that initialises the SESSION collection.

    Act= ion Group: Non-Disruptive

    Example:

    # Initialise session variables using the session =
cookie value=20
SecRule REQUEST_COOKIES:PHPSESSID !^$ chain,nolog,pass
SecAction setsid:%{REQUEST_COOKIES.PHPSE=
SSID}

    Note

    On first invocation of this action the collection wi= ll be empty (not taking the pre-defined variables into account - see initcol for more information). On subsequent invocations the contents of the collection (session, in this ca= se) will be retrieved from storage. After initialisation takes place the variable SESSIONID will be avail= able for use in the subsequent rules.This action understands each ap= plication maintains its own set of sessions. It will utilise the current = web application ID to create a session namespace.

    setenv

    Description: Creates, removes, or updates an environment variable.

    Action Group: Non-Disruptive

    Examples:

    To create a new variable (= if you omit the value 1 will be used):= 

    setenv:name=3Dvalue

    To remo= ve a variable:

    setenv:!name

    = Note

    This action c= an be used to establish communication with other Apache modules.

    setvar

    Description: = Creates, removes, or updates a variable in the specified collection.

    Action Group: Non-Disruptive

    Examples:

    To create a new variable:<= /p>

    setvar:tx.score=3D10

    To remo= ve a variable prefix the name with exclamation mark:

    setvar:!tx.score

    To increase or decrease = variable value use + and - characters in front of a numerical value:

    setvar:tx.score=3D+5

    skip

    Description: Skips one or more rules (or chains) on successful match.

    Action Group: Non-Disruptive

    Example:

    SecRule REQUEST_URI "^/$" "chain,skip=
:2"
SecRule REMOTE_ADDR "^127\.0\.0\.1$" "chain"
SecRule REQUEST_HEADERS:User-Agent "^Apache \(internal dummy connecti=
on\)$" "t:none" =20
SecRule &REQUEST_HEADERS:Host "@eq 0" \
    "deny,log,status:400,id:960008,severity:4,msg:'Request Missing a =
Host Header'"
SecRule &REQUEST_HEADERS:Accept "@eq 0" \
    "log,deny,log,status:400,id:960015,msg:'Request Missing an Accept=
 Header'"

    Note

    Skip only applies to the current processing phase and not necessarily the order in which the rules appear in the configur= ation file. If you group rules by processing phases, then skip should= work as expected. This action can not be used to skip rules within one = chain. Accepts a single paramater denoting the number of rules (or cha= ins) to skip.

    <= code class=3D"literal">status

    Description: Specifi= es the response status code to use with actions deny and redirect.

    = Action Group: Disruptive=

    Example:

    SecDefaultAction log=
,deny,status:403,phase:1=

    Note

    Stau= s actions defined in Apache scope locations (such as Directory, Location, etc...) may be superceded by phase:1 actio= n settings. The Apache ErrorDocument directive will be triggered = if present in the configuration. Therefore if you have previously = defined a custom error page for a given status then it will be executed a= nd its output presented to the user.

    t

    =

    Description: This action can be used which transformation function should be used against the s= pecified variables before they (or the results, rather) are run against = the operator specified in the rule.

    Action Group: Non-Disruptive

    Example:

    =
SecDefaultAction log,deny,phase:1,t:removeNulls,t:lowercase=20
SecRule REQUEST_COOKIES:SESSIONID "47414e81cbbef3cf8366e84eeacba091" =
\
    log,deny,status:403,t:md5

    Note

    Any transformation functions that you specify in a SecRule will be in addtion to previous ones specified in SecDefaultAction. Use = of "t:none" will remove all transformation functions for the speci= fied rule.

    <= code class=3D"literal">xmlns

    =

    Description: This act= ion should be used together with an XPath expression to register a namespace.

    Action Group: Non-Disruptive

    Example:

    =
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
    phase:1,pass,ctl:requestBodyProcessor=3DXML,ctl:requestBodyAccess=
=3DOn,xmlns:xsd=3D"http://www.w3.org/200=
1/XMLSchema"
SecRule XML:/soap:Envelope/soap:Body/q1:getInput/id() "123" phase:2,d=
eny

    Operators

    A number of operators can be used in rules, as documented below. = The operator syntax used the "@" symbol followed by the specific oper= ator name.

    eq

    Description: This operator is a numerical comparison and stands for "equal to."

    Example:<= /p>

    SecRule &REQUEST_HEADERS_NAMES "=
@eq 15"

    ge

    = Description: This operator is a numerical comparison and stands for "greater than or equal to."=

    Example:

    SecRule &REQUEST=
_HEADERS_NAMES "@ge 15"<=
/pre>

    gt

    Description: This operator is a numerical comparison and stands for "greater than."

    Examp= le:

    SecRule &REQUEST_HEADERS_NAM=
ES "@gt 15"
    <= div class=3D"section" lang=3D"en">
    =

    in= spectFile

    Description: Executes the external script/binary given as parameter to the operator again= st every file extracted from the request.

    Example:

    SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl"

    le

    Description: This operator is a numerical comparison and stands for "less than or equal to."

    Example:

    SecRule &REQUEST_HE=
ADERS_NAMES "@le 15"
    <= div>

    lt

    Description: This operator is a numerical comparison and stands for "less than."

    Example:= 

    SecRule &REQUEST_HEADERS_NAMES =
"@lt 15"
    rbl

    Description: Look up the parameter in the RBL given as parameter. Parameter can be an IP= v4 address, or a hostname.

    Example:

    SecRule REMOTE_ADDR "@rbl sc.surbl.org"

    rx

    Description:= Regular expression operator. This is the default operator, so if the "@" operator = is not defined, it is assumed to be rx.

    Example:

    SecRule REQUEST_HEADERS:User-Agent "@rx nikto"

    Note

    Regular expressions are handl= ed by the PCRE library (http://www.pcre.org). ModSecurity compiles its regular expressions with the following settings:

    1. The entire input i= s treated as a single line, even when there are newline characters present.

    2. All matches = are case-sensitive. If you do not care about case sensitivity you either need to implement the lowercase transformational function, or use the per-pattern(?i)modif= icator, as allowed by PCRE.

    3. The PCRE_DOTAL= L and PCRE_DOLLAR_ENDONLY flags ar= e set during compilation, meaning a single dot will match any cha= racter, including the newlines and a $ end anchor will not match a trailing newline charater.

      <= /li>

    <= code class=3D"literal">validateByteRange

    =

    Description: Validates the byte range used in the variable falls into the specified range.

    <= p>Example:

    SecRule ARG:text "@validateByteRange 10, 13, 32-1=
26"

    Note

    Y= ou can force requests to consist only of bytes from a certain byte range. This can be useful to avoid stack overflow attacks = (since they usually contain "random" binary content). Default range va= lues are 0 and 255, i.e. all byte values are allowed. This directive doe= s not check byte range in a POST payload when multipart/form-data encoding (fi= le upload) is used. Doing so would prevent binary files from being uploaded. Howeve= r, after the parameters are extracted from such request they are checked= for a valid range.

    validateByteRange is similar to the ModSecur= ity 1.X SecFilterForceByteRange Directive however since it works in a r= ule context, it has the following differences:

    • You can specify a different range= for different variables.

    • It has an "event" context (id, ms= g....)

    • It is executed in the flow of rules rather than= being a built in pre-check.

    validateDTD

    Descri= ption: This operator requires the request body to be processed as XML.

    Example= :

    SecDefaultAction log,deny,status:4=
03,phase:2
SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \
    phase:1,t:lowercase,nolog,pass,ctl:requestBodyProcessor=3DXML
SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skip:1
SecRule XML "@validateDTD /path/to/apach=
e2/conf/xml.dtd"

    validateSchema

    =

    Descript= ion: This operator requires the request body to be processed as XML.

    Example= :

    SecDefaultAction log,deny,status:4=
03,phase:2
SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \
    phase:1,t:lowercase,nolog,pass,ctl:requestBodyProcessor=3DXML
SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skip:1
SecRule XML "@validateSchema /path/to/ap=
ache2/conf/xml.xsd"

    This operator requires re= quest body to be processed as XML.

    validateUrlEncoding=

    Des= cription: Verifies the encodings used in the variable (if any) are valid.

    Exampl= e:

    SecRule ARGS "@validateUrlEncoding"

    Note

    URL encoding is an HTTP = standard for encoding byte values within a URL. The byte is escaped with a % followed by two hexadecimal v= alues (0-F). This directive does not check encoding in a POST payload= when the multipart/form-data encoding (fi= le upload) is used. It is not necessary to do so because URL encoding is not used f= or this encoding.

    = validateUtf8Encoding

    <= div>

    Description:= Verifies the variable is a valid UTF-8 encoded string.

    Example:

    SecRule ARGS "@validateUtf8Encoding"

    = Note

    UTF-8 encoding is valid on most we= b servers. Integer values between 0-65535 are encoded in a UTF-8 byte sequence that is es= caped by percents. The short form is two bytes in length.

    check fo= r three types of errors:

    • Not enough bytes. UTF-8 supports two, three, four, five, = and six byte encodings. ModSecurity will locate cases when a by= te or more is missing.

    • Invalid encoding. The two m= ost significant bits in most characters are supposed to be fixed to 0x80. Attackers can = use this to subvert Unicode decoders.

    • Overlong charac= ters. ASCII characters are mapped directly into the Unicode space and are thus represented with a single by= te. However, most ASCII characters can also be encoded with two= , three, four, five, and six characters thus tricking the decoder in= to thinking that the character is something else (and, presuma= bly, avoiding the security check).

    M= iscellaneous Topics

    Impedance Mismatch

    Web application firewalls have a difficult job t= rying to make sense of data that passes by, without any knowledge of the appl= ication and its business logic. The protection they provide comes from = having an independent layer of security on the outside. Because data vali= dation is done twice, security can be increased without having to touch t= he application. In some cases, however, the fact that everything i= s done twice brings problems. Problems can arise in the areas where th= e communication protocols are not well specified, or where either= the device or the application do things that are not in the specifi= cation. In such cases it may be possible to design payload that will be interpreted in one way by one device and in another by the othe= r device. This problem is better known as Impedance Mismatch. It can be e= xploited to evade the security devices.

    While we will continue to = enhance ModSecurity to deal with various evasion techniques the problem can only be minimized, but never= solved. With so many different application backends chances are some wi= ll always do something completely unexpected. The only solution is to be = aware of the technologies in the backend when writing rules, adapting th= e rules to remove the mismatch. See the next section for some examples.=

    =

    PHP Peculiarities for= ModSecurity Users

    When writing r= ules to protect PHP applications you need to pay attention to the following facts:

    1. When "register_globals" is set to "On" reque= st parameters are automatically converted to script variables. In some = PHP versions it is even possible to override the $GLOBALS array.

    2. Whitespace at the beginning of para= meter names is ignored. (This is very dangerous if you are writing rules to targe= t specific named variables.)

    3. The remaining w= hitespace (in parameter names) is converted to underscores. The same applies to dots and to a "[" if = the variable name does not contain a matching closing bracket= . (Meaning that if you want to exploit a script through a v= ariable that contains an underscore in the name you can send a pa= rameter with a whitespace or a dot instead.)

    4. Cooki= es can be treated as request parameters.

    5. The discussio= n about variable names applies equally to the cookie names.

    6. The order in which parameter= s are taken from the request and the environment is EGPCS (environment, GET, POST, Cookies= , built-in variables). This means that a POST parameter wil= l overwrite the parameters transported on the request line = (in QUERY_STRING).

    7. When "magic_quotes_gpc" is = set to "On" PHP will use backslash to escape the following characters: single quot= e, double quote, backslash, and the nul byte.

    8. If "ma= gic_quotes_sybase" is set to "On" only the single quote will be escaped using another single quote. In this= case the "magic_quotes_gpc" setting becomes irrelevant. The "magic_quotes_sybase" setting completely overrides the "magic_quotes_gpc" behaviour but "magic_quotes_gpc" still= must be set to "On" for the Sybase-specific quoting to be work.

    9. PHP will also automatically create nested arrays for yo= u. For example "p[x][y]=3D1" results in a total of three variables.

    Copyright (C) 2004-2008 Breach Security
    --Boundary_(ID_QUUFOcR+f9AyrsyWvio1YQ)-- From jyri@buye.red.iplanet.com Mon Feb 11 14:31:25 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BMVO1h008838 for ; Mon, 11 Feb 2008 14:31:25 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1BMVKAW000881; Mon, 11 Feb 2008 22:31:21 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300G0DIK7JV00@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 14:31:19 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW300BLYIK6O470@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 14:31:18 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1BMNmlB010998; Mon, 11 Feb 2008 14:23:48 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1BMNmKk010997; Mon, 11 Feb 2008 14:23:48 -0800 (PST) Date: Mon, 11 Feb 2008 14:23:48 -0800 From: Jyri Virkki Subject: Re: [webstack-discuss] Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <20080211145931.GY4494@vayavyam.India.Sun.COM> To: rahul Cc: PSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <20080211222348.GB10961@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <20080208171203.GQ22027@zruty.sfbay.sun.com> <20080211145931.GY4494@vayavyam.India.Sun.COM> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 304 rahul wrote: > > I would like to update the arc case with the following updates. I've updated the docs in the case materials accordingly. http://opensolaris.org/os/community/arc/caselog/2008/090/ (updates take a bit to show up on the site) -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From jyri@buye.red.iplanet.com Tue Feb 12 23:16:19 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1D7GIAb016675 for ; Tue, 12 Feb 2008 23:16:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1D7G5Jh003267; Wed, 13 Feb 2008 07:16:14 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW600E011J01R00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Feb 2008 23:16:12 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW600CQG1J0DO00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Feb 2008 23:16:12 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1D6rhUE013563; Tue, 12 Feb 2008 22:53:43 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1D6rho4013562; Tue, 12 Feb 2008 22:53:43 -0800 (PST) Date: Tue, 12 Feb 2008 22:53:43 -0800 From: Jyri Virkki Subject: Re: [webstack-discuss] Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <20080211145931.GY4494@vayavyam.India.Sun.COM> To: rahul Cc: Brian Rectanus , PSARC-ext@sun.com, webstack-discuss@opensolaris.org, Danek Duvall Message-id: <20080213065343.GO12197@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <20080208171203.GQ22027@zruty.sfbay.sun.com> <20080211145931.GY4494@vayavyam.India.Sun.COM> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 913 rahul wrote: > > > 5.1.4 mod_dtrace > The mod_dtrace has had just two releases (0.2a and 0.3a) and > is possibly very unstable. The interface of dtrace module consists > of the apache functions it is hooking into. This is provided as > Addendum 4. > > Addendum 4: > Apache methods hooked into by mod_dtrace: > > apache_receive_request > apache_log_request > apache_create_child > apache_accept_connection > apache_check_user > apache_check_access > apache_check_authorization > dtrace_register_hooks The above seems a bit confusing.. Isn't the public interface the provider and probe names being exported? Looking at http://prefetch.net/projects/apache_modtrace/apache.d the probe names seem to be receive-request log-request create-child accept-connection check-user-credentials check-access check-authorization -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Rahul.G.Nair@sun.com Wed Feb 13 01:50:12 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1D9oCTd020217 for ; Wed, 13 Feb 2008 01:50:12 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1D9oAZ5004144 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Feb 2008 01:50:11 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW60020R8NNDF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Feb 2008 02:50:11 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW600BXD8NJPRE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Feb 2008 02:50:10 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1D9oANm026094 for ; Wed, 13 Feb 2008 09:50:10 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JW600E018MFNE00@mail-apac.sun.com> (original mail from Rahul.G.Nair@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Feb 2008 17:50:06 +0800 (SGT) Received: from localhost ([129.158.224.78]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JW60032O8NCMWTY@mail-apac.sun.com>; Wed, 13 Feb 2008 17:50:01 +0800 (SGT) Date: Wed, 13 Feb 2008 15:09:56 +0530 From: rahul Subject: Re: [webstack-discuss] Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <20080213065343.GO12197@sun.com> Sender: Rahul.G.Nair@sun.com To: Jyri Virkki Cc: PSARC-ext@sun.com, webstack-discuss@opensolaris.org, Danek Duvall Message-id: <20080213093955.GF4494@vayavyam.India.Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_W/F6ABLY1olOe5NEZWS5GA)" X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <20080208171203.GQ22027@zruty.sfbay.sun.com> <20080211145931.GY4494@vayavyam.India.Sun.COM> <20080213065343.GO12197@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 13055 --Boundary_(ID_W/F6ABLY1olOe5NEZWS5GA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi, Updated arc draft attached, the changes are: change these | > apache_receive_request | > apache_log_request | > apache_create_child | > apache_accept_connection | > apache_check_user | > apache_check_access | > apache_check_authorization | > dtrace_register_hooks to the provider names as suggested by jyri. | receive-request | log-request | create-child | accept-connection | check-user-credentials | check-access | check-authorization rahul -- 1. e4 _ --Boundary_(ID_W/F6ABLY1olOe5NEZWS5GA) Content-type: text/plain; NAME=arc.modules; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=arc.modules Additional Apache2 Modules 11 February 2008 1. Summary and motivation 1.1. Introduction This project delivers Apache modules mod_jk, mod_fcgid, mod_security and mod_dtrace to the Apache2 (PSARC/2007/586) in OpenSolaris. Modules allow Apache to integrate and provide functionality during runtime that were not available during compile time. 1.1.1 mod_security From modsecurity.org[3] "ModSecurity is a web application firewall (WAF). With over 70% of all attacks now carried out over the web application level, organisations need every help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure." 1.1.2 mod_jk From tomcat.apache.org "mod_jk is a replacement to the elderly mod_jserv. It is a completely new Tomcat-Apache plug-in that handles the communication between Tomcat and Apache." 1.1.3 mod_fcgid From fastcgi.coremail.cn "It is a binary compatibility alternative to Apache module mod_fastcgi." mod_fcgid is an apache module that allows CGIs to be deployed on apache that make use of the FastCGI mechanism. From www.fastcgi.com "FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs." 1.1.4 mod_dtrace From prefetch.net "The Apache DTrace module (mod_dtrace) utilizes the hook framework to add DTrace probes to the Apache web server. These probes can be used to observe and correlate web server and system behavior, and allow easy access to numerous pieces of realtime Apache data. This project integrates the most recent stable releases of mod_jk[1] tomcat-connectors-1.2.25, mod_fcgid[2] 2.2, mod_security[3] 2.1.5 and mod_dtrace[4] 0.3a This case seeks Minor Release Binding. 2. Technical issues 2.1. Key objects /usr/apache2/2.2/libexec/mod_jk.so /usr/apache2/2.2/libexec/mod_fcgid.so /usr/apache2/2.2/libexec/mod_security2.so /usr/apache2/2.2/libexec/mod_dtrace.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_jk.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_fcgid.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_security2.so /usr/apache2/2.2/libexec/${ISAINFO}/mod_dtrace.so 2.2 Versioning mod_jk, mod_fcgid, mod_security and mod_dtrace have a single active release. (There was a module named mod_jk2 which was deprecated. It was not the successor to mod_jk.) It is not possible to query the modules to find out their versions. The only way to do that is to look at the package description for the package including it. 2.2 Directory Naming and Structure This project delivers the shared libraries of 32 bit and 64 bit into /usr/apache2/2.2/libexec and /usr/apache2/2.2/libexec/${ISAINFO}/ directories of apache. This is in keeping with the approach taken by the Apache2 integration project for OpenSolaris (PSARC/2007/586). 3. Documentation The modules mod_jk, mod_fcgid, mod_security and mod_dtrace do not install documentation into apache though they come with some documentation in their source. The recommended way to access their documentation is to look at their websites (mod_fcgid[5] ,mod_jk[6], mod_security[7] and mod_dtrace[8] ). A list of external apache modules that has been added and their corresponding sites will be part of the release document. 4. Packaging and Delivery The modules will be delivered under the cluster SUNWCapch22m. This cluster consists of SUNWapch22m-fcgid, SUNWapch22m-jk, SUNWapch22m-security and SUNWapch22m-dtrace respectively. 5. Interfaces 5.1. Interface Stability The interface stability of most of these modules is Volatile as these are controlled by external organisations over which Sun has no control. The specific researches regarding stability of each module are captured below. 5.1.1 mod_jk The mod_jk developers will try to keep the releases of 1.2.X line compatible with each other. But this is not guaranteed in case of new features that may need to be retracted due to some bugs or vulnerabilities. The interface of mod_jk (its configuration) is presented as Addendum 2. The complete list of directives and their explanation as supplied by tomcat.apache.org is available as mod_jk_interface.html. 5.1.2 mod_security The mod_security developers will keep the compatibility between releases of the same major number. (ie 2.y.z with 2 being the major number.) But there is no guarantee that meaning of a rule set (configuration directive) would be exactly the same across any two releases. The interface of mod_security (its configuration) is presented in Addendum 1. The complete list of directives and their explanation (as provided by modsecurity.org) is available as mod_security_interface.html. 5.1.3 mod_fcgid There were no commitments from mod_fcgid developers in this regard. (The mod_fcgid does not seem to have broken the configuration compatibility with any of its earlier releases yet [9] but is in very active development). The interface of mod_fcgid (its configuration options) is presented as Addendum 3. The complete list of directives and their explanation as provided by fastcgi.coremail.cn is available as mod_fcgid_interface.html 5.1.4 mod_dtrace The mod_dtrace has had just two releases (0.2a and 0.3a) and is possibly very unstable. The interface of dtrace module consists of the apache functions it is hooking into. This is provided as Addendum 4. 5.2. Imported Interfaces These Apache modules imports interfaces from NAME STABILITY NOTES ------------------------------------------------------------ Apache2 Uncommitted PSARC/2007/586/ LDAP Evolving PSARC/2000/362/ PCRE Uncommitted PSARC/2007/164/ SUNWlxml Committed PSARC/2001/175/ Dtrace Uncommitted PSARC/2001/466/ 5.3. Exported Interfaces NAME STABILITY --------------------------------------------------------------- /usr/apache2/2.2/libexec/mod_jk.so Volatile /usr/apache2/2.2/libexec/mod_fcgid.so Volatile /usr/apache2/2.2/libexec/mod_security.so Uncommitted /usr/apache2/2.2/libexec/mod_dtrace.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_jk.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_fcgid.so Volatile /usr/apache2/2.2/libexec/${ISAINFO}/mod_security.so Uncommitted /usr/apache2/2.2/libexec/${ISAINFO}/mod_dtrace.so Volatile 6. References 1. http://fastcgi.coremail.cn/ 2. http://tomcat.apache.org/connectors-doc/ 3. http://www.modsecurity.org/projects/modsecurity/apache/index.html 4. http://prefetch.net/projects/apache_modtrace/index.html 5. http://fastcgi.coremail.cn/doc.htm 6. http://tomcat.apache.org/connectors-doc/generic_howto/quick.html 7. http://www.modsecurity.org/documentation/index.html 8. http://prefetch.net/projects/apache_modtrace/mod_dtrace.c 9. http://fastcgi.coremail.cn/download.htm ============================================================================== Addendum 1 ---------- mod_security interfaces: It includes the configuration directives, exposed variables, library functions (transformation functions), operators and actions to be taken on the URI Configuration Directives SecAction SecArgumentSeparator SecAuditEngine SecAuditLog SecAuditLog2 SecAuditLogParts SecAuditLogRelevantStatus SecAuditLogStorageDir SecAuditLogType SecChrootDir SecCookieFormat SecDataDir SecDebugLog SecDebugLogLevel SecDefaultAction SecGuardianLog SecRequestBodyAccess SecRequestBodyLimit SecRequestBodyInMemoryLimit SecResponseBodyLimit SecResponseBodyMimeType SecResponseBodyMimeTypesClear SecResponseBodyAccess SecRule SecRuleInheritance SecRuleEngine SecRuleRemoveById SecRuleRemoveByMsg SecServerSignature SecTmpDir SecUploadDir SecUploadKeepFiles SecWebAppId Variables ARGS ARGS_COMBINED_SIZE ARGS_NAMES AUTH_TYPE ENV FILES FILES_COMBINED_SIZE FILES_NAMES FILES_SIZES FILES_TMPNAMES HTTP_ MULTIPART_CRLF_LF_LINES MULTIPART_STRICT_ERROR MULTIPART_UNMATCHED_BOUNDARY PATH_INFO QUERY_STRING REMOTE_ADDR REMOTE_HOST REMOTE_PORT REMOTE_USER REQBODY_PROCESSOR REQBODY_PROCESSOR_ERROR REQBODY_PROCESSOR_ERROR_MSG REQUEST_BASENAME REQUEST_BODY REQUEST_COOKIES REQUEST_COOKIES_NAMES REQUEST_FILENAME REQUEST_HEADERS REQUEST_HEADERS_NAMES REQUEST_LINE REQUEST_METHOD REQUEST_PROTOCOL REQUEST_URI REQUEST_URI_RAW RESPONSE_BODY RESPONSE_HEADERS RESPONSE_HEADERS_NAMES RESPONSE_PROTOCOL RESPONSE_STATUS RULE SCRIPT_BASENAME SCRIPT_FILENAME SCRIPT_GID SCRIPT_GROUPNAME SCRIPT_MODE SCRIPT_UID SCRIPT_USERNAME SERVER_ADDR SERVER_NAME SERVER_PORT SESSION SESSIONID TIME TIME_DAY TIME_EPOCH TIME_HOUR TIME_MIN TIME_MON TIME_SEC TIME_WDAY TIME_YEAR TX USERID WEBAPPID WEBSERVER_ERROR_LOG XML Transformation functions base64Decode base64Encode compressWhitespace escapeSeqDecode hexDecode hexEncode htmlEntityDecode lowercase md5 none normalisePath normalisePathWin removeNulls removeWhitespace replaceComments replaceNulls urlDecode urlDecodeUni urlEncode sha1 Actions allow auditlog capture chain ctl deny deprecatevar drop exec expirevar id initcol log msg multiMatch noauditlog nolog pass pause phase proxy redirect rev sanitiseArg sanitiseMatched sanitiseRequestHeader sanitiseResponseHeader severity setuid setsid setenv setvar skip status t xmlns Operators eq ge gt inspectFile le lt rbl rx validateByteRange validateDTD validateSchema validateUrlEncoding validateUtf8Encoding ============================================================================== Addendum 2: ----------- Apache directives exposed by mod_jk JkWorkersFile JkWorkerProperty JkShmFile JkShmSize JkMountFile JkMountFileReload JkMount JkUnMount JkAutoAlias JkMountCopy JkWorkerIndicator JkLogFile JkLogLevel JkLogStampFormat JkRequestLogFormat JkExtractSSL JkHTTPSIndicator JkCERTSIndicator JkCIPHERIndicator JkCERTCHAINPrefix JkSESSIONIndicator JkKEYSIZEIndicator JkOptions JkEnvVar JkStripSession ============================================================================== Addendum 3: ----------- Apache directives exposed by mod_fcgid IdleTimeout IdleScanInterval BusyTimeout BusyScanInterval ErrorScanInterval ZombieScanInterval ProcessLifeTime SocketPath SpawnScoreUpLimit SpawnScore TerminationScore MaxProcessCount DefaultMaxClassProcessCount DefaultMinClassProcessCount DefaultInitEnv IPCConnectTimeout IPCCommTimeout OutputBufferSize PHP_Fix_Pathinfo_Enable ============================================================================== Addendum 4: ----------- Probe names exported by mod_dtrace receive-request log-request create-child accept-connection check-user-credentials check-access check-authorization --Boundary_(ID_W/F6ABLY1olOe5NEZWS5GA)-- From jyri@buye.red.iplanet.com Fri Feb 15 16:10:18 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1G0AIUv026574 for ; Fri, 15 Feb 2008 16:10:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1G0ADsD004846; Fri, 15 Feb 2008 17:10:16 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWB00M671T2UL00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Feb 2008 16:10:14 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWB004GR1O3YJ80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Feb 2008 16:07:16 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1FNxkks025336; Fri, 15 Feb 2008 15:59:46 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1FNxkGd025335; Fri, 15 Feb 2008 15:59:46 -0800 (PST) Date: Fri, 15 Feb 2008 15:59:45 -0800 From: Jyri Virkki Subject: Re: [webstack-discuss] Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <20080213093955.GF4494@vayavyam.India.Sun.COM> To: rahul Cc: PSARC-ext@sun.com, webstack-discuss@opensolaris.org Message-id: <20080215235945.GO13839@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> <20080208171203.GQ22027@zruty.sfbay.sun.com> <20080211145931.GY4494@vayavyam.India.Sun.COM> <20080213065343.GO12197@sun.com> <20080213093955.GF4494@vayavyam.India.Sun.COM> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 620 rahul wrote: > > Hi, > Updated arc draft attached, the changes are: > change these > | > apache_receive_request > | > apache_log_request > | > apache_create_child > | > apache_accept_connection > | > apache_check_user > | > apache_check_access > | > apache_check_authorization > | > dtrace_register_hooks > > to the provider names as suggested by jyri. > > | receive-request > | log-request > | create-child > | accept-connection > | check-user-credentials > | check-access > | check-authorization I've updated the copy in the case materials. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From jyri@buye.red.iplanet.com Tue Feb 19 13:59:45 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1JLxj9w002165 for ; Tue, 19 Feb 2008 13:59:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1JLxbw2018641; Tue, 19 Feb 2008 13:59:42 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWI0070FAFGKX00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 19 Feb 2008 13:59:40 -0800 (PST) Received: from buye.red.iplanet.com ([192.18.65.224]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWI00JEVAFG2NA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 19 Feb 2008 13:59:40 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1JLqAwC011640; Tue, 19 Feb 2008 13:52:10 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1JLqAWd011639; Tue, 19 Feb 2008 13:52:10 -0800 (PST) Date: Tue, 19 Feb 2008 13:52:10 -0800 From: Jyri Virkki Subject: Re: Additional Apache2 Modules [PSARC/2008/090 FastTrack timeout 2/15/2008] In-reply-to: <200802080424.m184Oo56026308@sac.sfbay.sun.com> To: PSARC-ext@sun.com Cc: Rahul.G.Nair@sun.com, webstack-discuss@opensolaris.org Message-id: <20080219215210.GA11633@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802080424.m184Oo56026308@sac.sfbay.sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 230 Discussion has died down and the materials have been updated with the changes in this thread; I've now marked this case closed approved after it timed out last Friday. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems