Changes of Revision 2
| [-] | Changed | mod_security-ix.spec |
|
x 1 2 rm -rf %{buildroot}3 mkdir -p %{buildroot}/%{_sysconfdir}/httpd/modsecurity.d/4 mkdir -p %{buildroot}/%{_sysconfdir}/httpd/conf.d/5 +mkdir -p %{buildroot}/var/asl/data/suspicious6 +mkdir -p %{buildroot}/var/asl/data/msa7 +mkdir -p %{buildroot}/var/asl/data/audit8 install -D -m755 apache2/.libs/mod_security2.so %{buildroot}/%{_libdir}/httpd/modules/mod_security2.so9 install -D -m644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/httpd/conf.d/00_mod_security.conf10 -%if 0%{asl}11 install -D -m644 %{SOURCE2} %{buildroot}/%{_sysconfdir}/httpd/modsecurity.d/modsecurity_crs_10_config.conf12 -%else13 -cp rules/modsecurity_crs_10_config.conf %{buildroot}/%{_sysconfdir}/httpd/modsecurity.d/14 -%endif15 -16 -17 -18 -19 20 %clean21 rm -rf %{buildroot}22 23 %config %{_sysconfdir}/httpd/conf.d/00_mod_security.conf24 %dir %{_sysconfdir}/httpd/modsecurity.d25 %config(noreplace) %{_sysconfdir}/httpd/modsecurity.d/modsecurity_crs_10_config.conf26 -27 -28 -29 +%defattr(-,apache,apache)30 +%dir /var/asl31 +%dir /var/asl/data32 +%dir /var/asl/data/suspicious33 +%dir /var/asl/data/msa34 +%dir /var/asl/data/audit35 36 %changelog37 * Wed Nov 24 2010 Carsten Schoene <cs@linux-administrator.com> - 2.5.12-1538 |
||
| [+] | Deleted | modsecurity_crs_10_config--default.conf ^ |
| @@ -1,302 +0,0 @@ -# --------------------------------------------------------------- -# Core ModSecurity Rule Set ver.1.6.1 -# Copyright (C) 2006-2007 Breach Security Inc. All rights reserved. -# -# The ModSecuirty Core Rule Set is distributed under GPL version 2 -# Please see the enclosed LICENCE file for full details. -# --------------------------------------------------------------- - - -# Configuration contained in this file should be customized -# for your specific requirements before deployment. -# -# Next to each rule there is a description of what it does. Each -# location where customization is needed is marked with "TODO". It -# is recommended that you: -# -# 1) Keep a copy of the original file. This will allow you to use -# the "diff" command to quickly see the changes. It will also -# make upgrades to future rule sets easier. -# -# 2) Document your changes thoroughly. -# -# You are advised to start with ModSecurity in detection mode only. -# Switch to protection when you are comfortable with your rule set. -# For maximum protection monitor your logs on daily basis (or -# better). -# - -# TODO You may want to provide an error friendly message to your -# users when you start rejecting requests. You can do this using -# the Apache ErrorDocument directive. You should also add -# mod_unique_id to your configuration and display the unique -# request ID on the error page. This would allow your users to -# report the request ID back to you so that you can investigate -# the false positive (if that's what it is). A nice error page -# usually reduces the impact of false positives on the users. -# -# The drawback of this user friendly approach is that it is -# easier for the attackers to figure out there is an web -# application firewall protecting the application. -# -# ErrorDocument 403 /path/to/error_document.php -# -# For more information see -# http://httpd.apache.org/docs-2.0/custom-error.html - - -## -- Configuration ---------------------------------------------------------- - -# Turn ModSecurity on ("On"), set to monitoring only -# ("DetectionOnly") or turn off ("Off"). -# -SecRuleEngine On - -# Define which part of the HTTP transaction to inspect. -# -# Inspecting request body (SecRequestBodyAccess) should probably be always set -# to "on". Only very high volume sites that never use POST requests might want -# to set it to "off" to optimize performance. -# -# Inspecting response body is useful for monitoring for information leaks, -# or for signs of intrusion. However, it does require all responses to be -# buffered in memory. For most sites this should not be a problem, but special -# care must be taken to avoid buffering file downloads (through -# MIME type selection, as shown below). -# -# TODO If you decide to enable output filtering make sure to -# review the list of scanned MIME types. If pages of the types specified -# for outbound inspection are smaller than 512K in you application -# (which is usually the case) you may reduce the SecResponseBodyLimit -# to protect from potential denial of service attacks. -# -SecRequestBodyAccess On -SecResponseBodyAccess On -SecResponseBodyMimeType (null) text/html text/plain text/xml -SecResponseBodyLimit 2621440 - - -# Initiate XML Processor in case of xml content-type -# -# TODO Uncomment this rule if you wish to parse -# text/xml requests using the XML parser. Note -# that this may cause considerable overhead in processing -# text/xml requests. -#SecRule REQUEST_HEADERS:Content-Type "text/xml" \ -#"phase:1,pass,nolog,ctl:requestBodyProcessor=XML" - - -# What to do when an error is encountered. -# -# The default is to log the error and let the request go through. -# This is a reasonable setting to start with because you do not -# want to reject legitimate requests with an untuned rule set. -# -# If, after monitoring the performance of the rule set after a -# sufficient period, you determine the rules never (or rarely -# trigger on legitimate requests) you can change to something -# else, such as "log,deny,status:403". You can also leave the -# default setting here as is, but use per rule action configuration -# to only configure some rules to reject requests, leaving most -# of them to work in detection mode. -# -#SecDefaultAction "phase:2,log,deny,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace" - -# Set web server identification string -# -# TODO In case you use Apache, you may want specify a simple server signature -# instead of the detailed Apache default signature that list most modules -# used on the specific Apache deployment: -# "Apache/2.2.0 (Fedora)" -# For this directive to work, you need to set Apache ServerTokens -# to Full (this is the default option) -SecServerSignature Apache - -# Add ruleset identity to the logs -# -SecComponentSignature 201001071602 - -## -- File uploads configuration ----------------------------------------------- -# Temporary file storage path. -# -# TODO Change the temporary folder setting to a path where only -# the web server has access. -# -SecUploadDir /var/asl/data/suspicious - -# Whether or not to keep the stored files. -# -# In most cases you don't want to keep the uploaded files (especially -# when there is a lot of them). It may be useful to change the setting -# to "RelevantOnly", in which case the files uploaded in suspicious -# requests will be stored. -# -SecUploadKeepFiles Off - -# Inspect uploaded files. -# -# TODO If there is a danger of attack through uploaded files then it -# is possible to configure an external script to inspect each file -# before it is seen by the application. An example script is -# included with ModSecurity (/util/modsec-clamscan.pl). -# -# Inspecting uploaded files is especially important in a hosting, -# community or blogging environments where uploading files is permitted. -# -# NOTE the t:none action is required in order not to process the files names -# passed to the script based on previously defined actions in a -# SecDefaultAction directive. -# -# SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl" \ -# "t:none" - -## -- Logging ---------------------------------------------------------------- - -# Whether to log requests to the ModSecurity audit log. -# -# By default, only requests that trigger a ModSecurity events (as detected -# by) or a serer error are logged ("RelevantOnly"). This is a reasonable -# setting. Full logging can be set by using # "on". If the system is used -# for protection only and no logging is desired (not reccomended) logging can -# be turned of using "off" -# -# NOTE It is also possible to configure forensic logging on the -# per request basis using the "auditlog" and "noauditlog" rule -# actions. -# -# TODO The default rule set logs requests that generate a 404 "file not found" -# response. These events are interesting, but may log a lot of information. -# you may consider removing it by setting SecAuditLogRelevantStatus -# to "^(?:5|4\d[^4])". -# -SecAuditEngine RelevantOnly -SecAuditLogRelevantStatus "^(?:5|4(?!04))" - -# Log files structure -# -# You can select to log all events to a single log file (set SecAuditLogType to -# "Serial") or to log each request to a separate file (set it to "Concurrent"). -# The former is usually easier to use, but if full logging is required or if -# the protected system supports a large transaction volume the later may -# be a better option. -# -# TODO Set the SecAuditLog (for "Serial" logging) or SecAuditLogStorageDir (for -# "Concurrent" logging). -# -# TODO If you change from "Serial" to "Concurrent" uncomment the -# SecAuditLogStorageDir directive and make sure the direcory specified -# exists and has write permissions for the Apache user. - -SecAuditLogType Concurrent -SecAuditLog logs/audit_log -# SecAuditLogStorageDir logs/modsec_audit - -# Select what portions of the request to log -# -# Modify the string by adding any of the letter below to it: -# A - audit log header (mandatory) -# B - request headers -# C - request body (present only if the request body exists and ModSecurity is | ||
| [+] | Added | modsecurity_crs_10_config-default.conf ^ |
| @@ -0,0 +1,302 @@ +# --------------------------------------------------------------- +# Core ModSecurity Rule Set ver.1.6.1 +# Copyright (C) 2006-2007 Breach Security Inc. All rights reserved. +# +# The ModSecuirty Core Rule Set is distributed under GPL version 2 +# Please see the enclosed LICENCE file for full details. +# --------------------------------------------------------------- + + +# Configuration contained in this file should be customized +# for your specific requirements before deployment. +# +# Next to each rule there is a description of what it does. Each +# location where customization is needed is marked with "TODO". It +# is recommended that you: +# +# 1) Keep a copy of the original file. This will allow you to use +# the "diff" command to quickly see the changes. It will also +# make upgrades to future rule sets easier. +# +# 2) Document your changes thoroughly. +# +# You are advised to start with ModSecurity in detection mode only. +# Switch to protection when you are comfortable with your rule set. +# For maximum protection monitor your logs on daily basis (or +# better). +# + +# TODO You may want to provide an error friendly message to your +# users when you start rejecting requests. You can do this using +# the Apache ErrorDocument directive. You should also add +# mod_unique_id to your configuration and display the unique +# request ID on the error page. This would allow your users to +# report the request ID back to you so that you can investigate +# the false positive (if that's what it is). A nice error page +# usually reduces the impact of false positives on the users. +# +# The drawback of this user friendly approach is that it is +# easier for the attackers to figure out there is an web +# application firewall protecting the application. +# +# ErrorDocument 403 /path/to/error_document.php +# +# For more information see +# http://httpd.apache.org/docs-2.0/custom-error.html + + +## -- Configuration ---------------------------------------------------------- + +# Turn ModSecurity on ("On"), set to monitoring only +# ("DetectionOnly") or turn off ("Off"). +# +SecRuleEngine On + +# Define which part of the HTTP transaction to inspect. +# +# Inspecting request body (SecRequestBodyAccess) should probably be always set +# to "on". Only very high volume sites that never use POST requests might want +# to set it to "off" to optimize performance. +# +# Inspecting response body is useful for monitoring for information leaks, +# or for signs of intrusion. However, it does require all responses to be +# buffered in memory. For most sites this should not be a problem, but special +# care must be taken to avoid buffering file downloads (through +# MIME type selection, as shown below). +# +# TODO If you decide to enable output filtering make sure to +# review the list of scanned MIME types. If pages of the types specified +# for outbound inspection are smaller than 512K in you application +# (which is usually the case) you may reduce the SecResponseBodyLimit +# to protect from potential denial of service attacks. +# +SecRequestBodyAccess On +SecResponseBodyAccess On +SecResponseBodyMimeType (null) text/html text/plain text/xml +SecResponseBodyLimit 2621440 + + +# Initiate XML Processor in case of xml content-type +# +# TODO Uncomment this rule if you wish to parse +# text/xml requests using the XML parser. Note +# that this may cause considerable overhead in processing +# text/xml requests. +#SecRule REQUEST_HEADERS:Content-Type "text/xml" \ +#"phase:1,pass,nolog,ctl:requestBodyProcessor=XML" + + +# What to do when an error is encountered. +# +# The default is to log the error and let the request go through. +# This is a reasonable setting to start with because you do not +# want to reject legitimate requests with an untuned rule set. +# +# If, after monitoring the performance of the rule set after a +# sufficient period, you determine the rules never (or rarely +# trigger on legitimate requests) you can change to something +# else, such as "log,deny,status:403". You can also leave the +# default setting here as is, but use per rule action configuration +# to only configure some rules to reject requests, leaving most +# of them to work in detection mode. +# +#SecDefaultAction "phase:2,log,deny,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace" + +# Set web server identification string +# +# TODO In case you use Apache, you may want specify a simple server signature +# instead of the detailed Apache default signature that list most modules +# used on the specific Apache deployment: +# "Apache/2.2.0 (Fedora)" +# For this directive to work, you need to set Apache ServerTokens +# to Full (this is the default option) +SecServerSignature Apache + +# Add ruleset identity to the logs +# +SecComponentSignature 201001071602 + +## -- File uploads configuration ----------------------------------------------- +# Temporary file storage path. +# +# TODO Change the temporary folder setting to a path where only +# the web server has access. +# +SecUploadDir /var/asl/data/suspicious + +# Whether or not to keep the stored files. +# +# In most cases you don't want to keep the uploaded files (especially +# when there is a lot of them). It may be useful to change the setting +# to "RelevantOnly", in which case the files uploaded in suspicious +# requests will be stored. +# +SecUploadKeepFiles Off + +# Inspect uploaded files. +# +# TODO If there is a danger of attack through uploaded files then it +# is possible to configure an external script to inspect each file +# before it is seen by the application. An example script is +# included with ModSecurity (/util/modsec-clamscan.pl). +# +# Inspecting uploaded files is especially important in a hosting, +# community or blogging environments where uploading files is permitted. +# +# NOTE the t:none action is required in order not to process the files names +# passed to the script based on previously defined actions in a +# SecDefaultAction directive. +# +# SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl" \ +# "t:none" + +## -- Logging ---------------------------------------------------------------- + +# Whether to log requests to the ModSecurity audit log. +# +# By default, only requests that trigger a ModSecurity events (as detected +# by) or a serer error are logged ("RelevantOnly"). This is a reasonable +# setting. Full logging can be set by using # "on". If the system is used +# for protection only and no logging is desired (not reccomended) logging can +# be turned of using "off" +# +# NOTE It is also possible to configure forensic logging on the +# per request basis using the "auditlog" and "noauditlog" rule +# actions. +# +# TODO The default rule set logs requests that generate a 404 "file not found" +# response. These events are interesting, but may log a lot of information. +# you may consider removing it by setting SecAuditLogRelevantStatus +# to "^(?:5|4\d[^4])". +# +SecAuditEngine RelevantOnly +SecAuditLogRelevantStatus "^(?:5|4(?!04))" + +# Log files structure +# +# You can select to log all events to a single log file (set SecAuditLogType to +# "Serial") or to log each request to a separate file (set it to "Concurrent"). +# The former is usually easier to use, but if full logging is required or if +# the protected system supports a large transaction volume the later may +# be a better option. +# +# TODO Set the SecAuditLog (for "Serial" logging) or SecAuditLogStorageDir (for +# "Concurrent" logging). +# +# TODO If you change from "Serial" to "Concurrent" uncomment the +# SecAuditLogStorageDir directive and make sure the direcory specified +# exists and has write permissions for the Apache user. + +SecAuditLogType Concurrent +SecAuditLog logs/audit_log +# SecAuditLogStorageDir logs/modsec_audit + +# Select what portions of the request to log +# +# Modify the string by adding any of the letter below to it: +# A - audit log header (mandatory) +# B - request headers +# C - request body (present only if the request body exists and ModSecurity is | ||