Web Application Firewall: ModSecurity
Summary
ModSecurity is an Open Source Web Application Firewall.
Set it up for +Layer of the Secuiry not only the Fortinet Firewall.
How-to
For CentOS 7
For CentOS 6
/etc/httpd/modsecurity.d/
Edit /etc/httpd/conf.d/mod_security.conf
id that is the tripped rule within ModSec
Test
Log
/etc/logrotate.d/httpd
Appendix: CRS (Core Rule Set) 3.0 vs CRS 2.x
https://coreruleset.org/installation/
References
https://github.com/SpiderLabs/ModSecurity/wiki
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#OWASP_ModSecurity_Core_Rule_Set_CRS_Project
Atomic ModSecurity Rules by Atomicorp
https://wiki.atomicorp.com/wiki/index.php/WAF_rule_families
OWASP ModSecurity
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-advanced-topic-of-the-week-updated-exception-handling/
Update
ModSecurity is an Open Source Web Application Firewall.
Set it up for +Layer of the Secuiry not only the Fortinet Firewall.
How-to
For CentOS 7
yum -y install epel-release
For CentOS 6
rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum install mod_security mod_security_crs
/etc/httpd/modsecurity.d/
activated_rules modsecurity_crs_10_config.conf
Edit /etc/httpd/conf.d/mod_security.conf
On – Rules are activated
Off – Rules are Deactivated
DetectionOnly – Only Intercepts and logs Transactions
Off – Rules are Deactivated
DetectionOnly – Only Intercepts and logs Transactions
SecRuleEngine on
SecDebugLog /var/log/httpd/modsec_debug.log
SecAuditLog /var/log/httpd/modsec_audit.log
SecRule REMOTE_ADDR "@ipMatch 192.168.0.254,192.168.1.0/24" phase:1,nolog,allow,ctl:ruleEngine=Off,id:55666
SecDebugLog /var/log/httpd/modsec_debug.log
SecAuditLog /var/log/httpd/modsec_audit.log
SecRule REMOTE_ADDR "@ipMatch 192.168.0.254,192.168.1.0/24" phase:1,nolog,allow,ctl:ruleEngine=Off,id:55666
id that is the tripped rule within ModSec
Each rule added to a ModSecurity instance must have a unique ID (in recent versions of modsec). As a result of this it is important that IDs be generated in a preplanned way such that they don’t overlap with other rules.
Pattern match "^192\\.168\\.0\\.254$" at REMOTE_ADDR. [file "/etc/httpd/conf.d/mod_security.conf"] [line "20"] [id "55666"]
service httpd restart
/etc/httpd/modsecurity.d/activated_rules
/usr/lib/modsecurity.d/base_rules
/usr/lib/modsecurity.d/base_rules
apachectl -M | grep security
Test
curl localhost/index.html?testparam=test
tail -n 40 /var/log/httpd/modsec_audit.log
Log
/etc/logrotate.d/httpd
/var/log/httpd/*log {
rotate 4
weekly
missingok
notifempty
sharedscripts
delaycompress
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
rotate 4
weekly
missingok
notifempty
sharedscripts
delaycompress
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
Appendix: CRS (Core Rule Set) 3.0 vs CRS 2.x
However, CRS 3.0 is a major rewrite, incompatible with CRS 2.x. Key setup variables have changed their name, and new features have been introduced. Your former modsecurity_crs_10_setup.conf file is thus no longer usable. We recommend you to start with a fresh crs-setup.conf file from scratch.
https://coreruleset.org/installation/
Apache web server with ModSecurity 2.9.x
IIS/Nginx web server with ModSecurity 3.0.3 or higher
IIS/Nginx web server with ModSecurity 3.0.3 or higher
References
https://github.com/SpiderLabs/ModSecurity/wiki
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#OWASP_ModSecurity_Core_Rule_Set_CRS_Project
Atomic ModSecurity Rules by Atomicorp
https://wiki.atomicorp.com/wiki/index.php/WAF_rule_families
OWASP ModSecurity
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-advanced-topic-of-the-week-updated-exception-handling/
Update