mod-security-users Mailing List for ModSecurity (Page 15)
Brought to you by:
victorhora,
zimmerletw
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(17) |
Aug
(7) |
Sep
(8) |
Oct
(11) |
Nov
(14) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(46) |
Feb
(14) |
Mar
(20) |
Apr
(48) |
May
(15) |
Jun
(20) |
Jul
(36) |
Aug
(24) |
Sep
(31) |
Oct
(28) |
Nov
(23) |
Dec
(12) |
| 2005 |
Jan
(69) |
Feb
(61) |
Mar
(82) |
Apr
(53) |
May
(26) |
Jun
(71) |
Jul
(27) |
Aug
(52) |
Sep
(28) |
Oct
(49) |
Nov
(104) |
Dec
(74) |
| 2006 |
Jan
(61) |
Feb
(148) |
Mar
(82) |
Apr
(139) |
May
(65) |
Jun
(116) |
Jul
(92) |
Aug
(101) |
Sep
(84) |
Oct
(103) |
Nov
(174) |
Dec
(102) |
| 2007 |
Jan
(166) |
Feb
(161) |
Mar
(181) |
Apr
(152) |
May
(192) |
Jun
(250) |
Jul
(127) |
Aug
(165) |
Sep
(97) |
Oct
(135) |
Nov
(206) |
Dec
(56) |
| 2008 |
Jan
(160) |
Feb
(135) |
Mar
(98) |
Apr
(89) |
May
(115) |
Jun
(95) |
Jul
(188) |
Aug
(167) |
Sep
(153) |
Oct
(84) |
Nov
(82) |
Dec
(85) |
| 2009 |
Jan
(139) |
Feb
(133) |
Mar
(128) |
Apr
(105) |
May
(135) |
Jun
(79) |
Jul
(92) |
Aug
(134) |
Sep
(73) |
Oct
(112) |
Nov
(159) |
Dec
(80) |
| 2010 |
Jan
(100) |
Feb
(116) |
Mar
(130) |
Apr
(59) |
May
(88) |
Jun
(59) |
Jul
(69) |
Aug
(67) |
Sep
(82) |
Oct
(76) |
Nov
(59) |
Dec
(34) |
| 2011 |
Jan
(84) |
Feb
(74) |
Mar
(81) |
Apr
(94) |
May
(188) |
Jun
(72) |
Jul
(118) |
Aug
(109) |
Sep
(111) |
Oct
(80) |
Nov
(51) |
Dec
(44) |
| 2012 |
Jan
(80) |
Feb
(123) |
Mar
(46) |
Apr
(12) |
May
(40) |
Jun
(62) |
Jul
(95) |
Aug
(66) |
Sep
(65) |
Oct
(53) |
Nov
(42) |
Dec
(60) |
| 2013 |
Jan
(96) |
Feb
(96) |
Mar
(108) |
Apr
(72) |
May
(115) |
Jun
(111) |
Jul
(114) |
Aug
(87) |
Sep
(93) |
Oct
(97) |
Nov
(104) |
Dec
(82) |
| 2014 |
Jan
(96) |
Feb
(77) |
Mar
(71) |
Apr
(40) |
May
(48) |
Jun
(78) |
Jul
(54) |
Aug
(44) |
Sep
(58) |
Oct
(79) |
Nov
(51) |
Dec
(52) |
| 2015 |
Jan
(55) |
Feb
(59) |
Mar
(48) |
Apr
(40) |
May
(45) |
Jun
(63) |
Jul
(36) |
Aug
(49) |
Sep
(35) |
Oct
(58) |
Nov
(21) |
Dec
(47) |
| 2016 |
Jan
(35) |
Feb
(81) |
Mar
(43) |
Apr
(41) |
May
(77) |
Jun
(52) |
Jul
(39) |
Aug
(34) |
Sep
(107) |
Oct
(67) |
Nov
(54) |
Dec
(20) |
| 2017 |
Jan
(99) |
Feb
(37) |
Mar
(86) |
Apr
(47) |
May
(57) |
Jun
(55) |
Jul
(34) |
Aug
(31) |
Sep
(16) |
Oct
(49) |
Nov
(53) |
Dec
(33) |
| 2018 |
Jan
(25) |
Feb
(11) |
Mar
(79) |
Apr
(77) |
May
(5) |
Jun
(19) |
Jul
(17) |
Aug
(7) |
Sep
(13) |
Oct
(22) |
Nov
(13) |
Dec
(68) |
| 2019 |
Jan
(44) |
Feb
(17) |
Mar
(40) |
Apr
(39) |
May
(18) |
Jun
(14) |
Jul
(20) |
Aug
(31) |
Sep
(11) |
Oct
(35) |
Nov
(3) |
Dec
(10) |
| 2020 |
Jan
(32) |
Feb
(16) |
Mar
(10) |
Apr
(22) |
May
(2) |
Jun
(34) |
Jul
(1) |
Aug
(8) |
Sep
(36) |
Oct
(16) |
Nov
(13) |
Dec
(10) |
| 2021 |
Jan
(16) |
Feb
(23) |
Mar
(45) |
Apr
(28) |
May
(6) |
Jun
(17) |
Jul
(8) |
Aug
(1) |
Sep
(2) |
Oct
(35) |
Nov
|
Dec
(5) |
| 2022 |
Jan
|
Feb
(17) |
Mar
(23) |
Apr
(23) |
May
(9) |
Jun
(8) |
Jul
|
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(16) |
Dec
(4) |
| 2023 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(7) |
Feb
(13) |
Mar
(18) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(12) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Reindl H. <h.r...@th...> - 2021-02-26 18:05:03
|
Am 26.02.21 um 18:28 schrieb Jason Long via mod-security-users: > Hello, > Any report about conflicting ModSecurity with other security tools like > IDS/IPS? I have Suricata-IDS on my server, can it make any conflict with > the ModSecurity? why should it? * modsec blocks a request by it's rules or not * something later don't get anything in case of block * modsec don't get anything when the request got blocked before IDS works on a complete different layer anyways |
|
From: Jason L. <hac...@ya...> - 2021-02-26 17:30:14
|
Hello,Any report about conflicting ModSecurity with other security tools like IDS/IPS? I have Suricata-IDS on my server, can it make any conflict with the ModSecurity? Thank you. |
|
From: Kyle R. O. <ky...@st...> - 2021-02-24 13:39:54
|
Hi, Is anyone aware of any attempts to integrate ModSecurity with either a SAST or DAST? I figured it would be more common, but I've only seen DAST integration mentioned in a couple of Ryan Barnett's articles from 2012: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-advanced-topic-of-the-week-automated-virtual-patching-using-owasp-zed-attack-proxy/ https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/dynamic-dastwaf-integration-realtime-virtual-patching/ They mention a couple of Perl scripts, which I was able to find here: https://github.com/coreruleset/coreruleset/tree/v3.4/dev/util/virtual-patching I'm also a quite curious about how these scripts came about and how effective they are (I'm currently testing out the ZAP one). Thanks, Kyle |
|
From: Brent C. <bre...@gm...> - 2021-02-24 11:26:06
|
The host itself, is fine. HTH Regards Brent On 2021/02/24 12:58, Jason Long via mod-security-users wrote: > Hello, > Where is the best place for the ModSecurity to protect a WordPress > website? Is it true that a WAF like ModSecurity must be installed > between the web server and the Internet and not on the host itself? > > Tnx. > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ |
|
From: Reindl H. <h.r...@th...> - 2021-02-24 11:13:16
|
Am 24.02.21 um 11:58 schrieb Jason Long via mod-security-users: > Hello, > Where is the best place for the ModSecurity to protect a WordPress > website? Is it true that a WAF like ModSecurity must be installed > between the web server and the Internet and not on the host itself? no it is not and given that you can adjust rules based on <Directory> in your httpd configuration it makes a lot of sense have it on the host itself and "must" don't exist at all - nobody can force you to setup a proxy nor pretend an additional proxy makes things more secure by it's existence the opposite is true: in doubt you are now vulerable for bugs of the proxy as well as the backend server - having more layers and complexity in the mix can make sense but it's not more secure out of the blue |
|
From: Jason L. <hac...@ya...> - 2021-02-24 10:59:01
|
Hello,Where is the best place for the ModSecurity to protect a WordPress website? Is it true that a WAF like ModSecurity must be installed between the web server and the Internet and not on the host itself? Tnx. |
|
From: Reindl H. <h.r...@th...> - 2021-02-22 18:38:06
|
first can you use a proper mail client not converting everything to HTML? Am 22.02.21 um 18:49 schrieb Jason Long via mod-security-users: > I thought nobody here answered because that version 2.9.2 is old! you got answers you problem is that you touch 1000 things at once while not understand modsec and the corerules and your distribution at all > Uninstall version 3? most likely yes i get tired from your "But I can't see any "mod_security.conf" file in "httpd" directory!" *what* is the "httpd" directory - /etc/httpd or /etc/httpd/conf.d - maybe you even don't understand .d-directories please do your homework just learn some basics like "rpm -q --filesbypkg", make sure you have *both* the corerules and modsec installed and don't insist in edit things you don't understand at the moment just get a basic install without nonsense like compile stuff at your own and fankly don't mix random fedira packages into your centos setup - you won't be able to maintain the mess you are creating "yum install mod_security mod_security_crs" should give you everything you need and then *look* what files it provide and where - forget random howtos at least for details, i can package every file whereever i want when building a package > On Monday, February 22, 2021, 03:37:55 PM GMT+3:30, Reindl Harald > <h.r...@th...> wrote: > > > > > Am 21.02.21 um 20:28 schrieb Jason Long via mod-security-users: > > Thank you so much for your answer. > > I installed ModSecurity as below: > > > > # yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl > > GeoIP-devel doxygen zlib-devel pcre-devel > > # cd /opt/ > > # git clone https://github.com/SpiderLabs/ModSecurity > <https://github.com/SpiderLabs/ModSecurity> > > # cd ModSecurity > > # git checkout -b v3/master origin/v3/master > > # sh build.sh > > # git submodule init > > # git submodule update > > # ./configure > > # yum install > > > https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/23/x86_64/b/bison-3.0.4-3.fc23.x86_64.rpm > <https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/23/x86_64/b/bison-3.0.4-3.fc23.x86_64.rpm> > > # make > > # make install > > what he hell are you doing? > > compiling stuff? > mixing Fedora and CentOS packaging? > > > But I can't see any "mod_security.conf" file in "httpd" directory! > > Why? > > what about install modsec and the core ruleset from *packages* (EPEL if > needed) and look tighter with "ls -lhaR /etc/httpd/"? > > yum install mod_security mod_security_crs > > it's in /etc/httpd/conf.d > > > [harry@srv-rhsoft <mailto:harry@srv-rhsoft>:/downloads]$ rpm -q > --filesbypkg > mod_security-2.9.3-9.eln109.x86_64.rpm > mod_security /etc/httpd/conf.d/mod_security.conf > mod_security /etc/httpd/conf.modules.d/10-mod_security.conf > mod_security /etc/httpd/modsecurity.d > mod_security /etc/httpd/modsecurity.d/activated_rules > mod_security /etc/httpd/modsecurity.d/local_rules > mod_security > /etc/httpd/modsecurity.d/local_rules/modsecurity_localrules.conf > mod_security /usr/lib/.build-id > mod_security /usr/lib/.build-id/c0 > > mod_security > > /usr/lib/.build-id/c0/9fe3397f1beb60cd30f4fa5a3ac1a24f2c93df > mod_security /usr/lib64/httpd/modules/mod_security2.so > mod_security /usr/share/doc/mod_security > mod_security /usr/share/doc/mod_security/CHANGES > mod_security /usr/share/doc/mod_security/LICENSE > mod_security /usr/share/doc/mod_security/NOTICE > mod_security /usr/share/doc/mod_security/README.md > mod_security /var/lib/mod_security > > > [harry@srv-rhsoft <mailto:harry@srv-rhsoft>:/downloads]$ rpm -q > --filesbypkg > mod_security_crs-3.0.0-12.eln109.noarch.rpm > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-901-INITIALIZATION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-905-COMMON-EXCEPTIONS.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-910-IP-REPUTATION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-911-METHOD-ENFORCEMENT.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-912-DOS-PROTECTION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-913-SCANNER-DETECTION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-921-PROTOCOL-ATTACK.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/REQUEST-949-BLOCKING-EVALUATION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-950-DATA-LEAKAGES.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-959-BLOCKING-EVALUATION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-980-CORRELATION.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/crawlers-user-agents.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/iis-errors.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/java-code-leakages.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/java-errors.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/lfi-os-files.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/php-config-directives.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/php-errors.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/php-function-names-933150.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/php-function-names-933151.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/php-variables.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/restricted-files.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/scanners-headers.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/scanners-urls.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/scanners-user-agents.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/scripting-user-agents.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/sql-errors.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/sql-function-names.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/unix-shell.data > mod_security_crs > /etc/httpd/modsecurity.d/activated_rules/windows-powershell-commands.data > mod_security_crs /etc/httpd/modsecurity.d/crs-setup.conf > mod_security_crs /usr/share/doc/mod_security_crs > mod_security_crs /usr/share/doc/mod_security_crs/CHANGES > mod_security_crs /usr/share/doc/mod_security_crs/README.md > mod_security_crs /usr/share/licenses/mod_security_crs > mod_security_crs /usr/share/licenses/mod_security_crs/LICENSE > mod_security_crs /usr/share/mod_modsecurity_crs > mod_security_crs /usr/share/mod_modsecurity_crs/rules > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-901-INITIALIZATION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-910-IP-REPUTATION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-912-DOS-PROTECTION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-913-SCANNER-DETECTION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-950-DATA-LEAKAGES.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/RESPONSE-980-CORRELATION.conf > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/crawlers-user-agents.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/iis-errors.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/java-code-leakages.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/java-errors.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/lfi-os-files.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/php-config-directives.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/php-errors.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/php-function-names-933150.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/php-function-names-933151.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/php-variables.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/restricted-files.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/scanners-headers.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/scanners-urls.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/scanners-user-agents.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/scripting-user-agents.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/sql-errors.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/sql-function-names.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/unix-shell.data > mod_security_crs > /usr/share/mod_modsecurity_crs/rules/windows-powershell-commands.data |
|
From: Jason L. <hac...@ya...> - 2021-02-22 17:49:23
|
I thought nobody here answered because that version 2.9.2 is old! Uninstall version 3? On Monday, February 22, 2021, 03:37:55 PM GMT+3:30, Reindl Harald <h.r...@th...> wrote: Am 21.02.21 um 20:28 schrieb Jason Long via mod-security-users: > Thank you so much for your answer. > I installed ModSecurity as below: > > # yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl > GeoIP-devel doxygen zlib-devel pcre-devel > # cd /opt/ > # git clone https://github.com/SpiderLabs/ModSecurity > # cd ModSecurity > # git checkout -b v3/master origin/v3/master > # sh build.sh > # git submodule init > # git submodule update > # ./configure > # yum install > https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/23/x86_64/b/bison-3.0.4-3.fc23.x86_64.rpm > # make > # make install what he hell are you doing? compiling stuff? mixing Fedora and CentOS packaging? > But I can't see any "mod_security.conf" file in "httpd" directory! > Why? what about install modsec and the core ruleset from *packages* (EPEL if needed) and look tighter with "ls -lhaR /etc/httpd/"? yum install mod_security mod_security_crs it's in /etc/httpd/conf.d [harry@srv-rhsoft:/downloads]$ rpm -q --filesbypkg mod_security-2.9.3-9.eln109.x86_64.rpm mod_security /etc/httpd/conf.d/mod_security.conf mod_security /etc/httpd/conf.modules.d/10-mod_security.conf mod_security /etc/httpd/modsecurity.d mod_security /etc/httpd/modsecurity.d/activated_rules mod_security /etc/httpd/modsecurity.d/local_rules mod_security /etc/httpd/modsecurity.d/local_rules/modsecurity_localrules.conf mod_security /usr/lib/.build-id mod_security /usr/lib/.build-id/c0 mod_security /usr/lib/.build-id/c0/9fe3397f1beb60cd30f4fa5a3ac1a24f2c93df mod_security /usr/lib64/httpd/modules/mod_security2.so mod_security /usr/share/doc/mod_security mod_security /usr/share/doc/mod_security/CHANGES mod_security /usr/share/doc/mod_security/LICENSE mod_security /usr/share/doc/mod_security/NOTICE mod_security /usr/share/doc/mod_security/README.md mod_security /var/lib/mod_security [harry@srv-rhsoft:/downloads]$ rpm -q --filesbypkg mod_security_crs-3.0.0-12.eln109.noarch.rpm mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-901-INITIALIZATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-905-COMMON-EXCEPTIONS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-910-IP-REPUTATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-911-METHOD-ENFORCEMENT.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-912-DOS-PROTECTION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-913-SCANNER-DETECTION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-921-PROTOCOL-ATTACK.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-949-BLOCKING-EVALUATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-950-DATA-LEAKAGES.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-959-BLOCKING-EVALUATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-980-CORRELATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/crawlers-user-agents.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/iis-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/java-code-leakages.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/java-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/lfi-os-files.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-config-directives.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-function-names-933150.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-function-names-933151.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-variables.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/restricted-files.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scanners-headers.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scanners-urls.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scanners-user-agents.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scripting-user-agents.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/sql-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/sql-function-names.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/unix-shell.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/windows-powershell-commands.data mod_security_crs /etc/httpd/modsecurity.d/crs-setup.conf mod_security_crs /usr/share/doc/mod_security_crs mod_security_crs /usr/share/doc/mod_security_crs/CHANGES mod_security_crs /usr/share/doc/mod_security_crs/README.md mod_security_crs /usr/share/licenses/mod_security_crs mod_security_crs /usr/share/licenses/mod_security_crs/LICENSE mod_security_crs /usr/share/mod_modsecurity_crs mod_security_crs /usr/share/mod_modsecurity_crs/rules mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-901-INITIALIZATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-910-IP-REPUTATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-912-DOS-PROTECTION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-913-SCANNER-DETECTION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-950-DATA-LEAKAGES.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-980-CORRELATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/crawlers-user-agents.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/iis-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/java-code-leakages.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/java-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/lfi-os-files.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-config-directives.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-function-names-933150.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-function-names-933151.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-variables.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/restricted-files.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scanners-headers.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scanners-urls.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scanners-user-agents.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scripting-user-agents.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/sql-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/sql-function-names.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/unix-shell.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/windows-powershell-commands.data _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: http://www.modsecurity.org/projects/commercial/rules/ http://www.modsecurity.org/projects/commercial/support/ |
|
From: Reindl H. <h.r...@th...> - 2021-02-22 12:04:06
|
Am 21.02.21 um 20:28 schrieb Jason Long via mod-security-users: > Thank you so much for your answer. > I installed ModSecurity as below: > > # yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl > GeoIP-devel doxygen zlib-devel pcre-devel > # cd /opt/ > # git clone https://github.com/SpiderLabs/ModSecurity > # cd ModSecurity > # git checkout -b v3/master origin/v3/master > # sh build.sh > # git submodule init > # git submodule update > # ./configure > # yum install > https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/23/x86_64/b/bison-3.0.4-3.fc23.x86_64.rpm > # make > # make install what he hell are you doing? compiling stuff? mixing Fedora and CentOS packaging? > But I can't see any "mod_security.conf" file in "httpd" directory! > Why? what about install modsec and the core ruleset from *packages* (EPEL if needed) and look tighter with "ls -lhaR /etc/httpd/"? yum install mod_security mod_security_crs it's in /etc/httpd/conf.d [harry@srv-rhsoft:/downloads]$ rpm -q --filesbypkg mod_security-2.9.3-9.eln109.x86_64.rpm mod_security /etc/httpd/conf.d/mod_security.conf mod_security /etc/httpd/conf.modules.d/10-mod_security.conf mod_security /etc/httpd/modsecurity.d mod_security /etc/httpd/modsecurity.d/activated_rules mod_security /etc/httpd/modsecurity.d/local_rules mod_security /etc/httpd/modsecurity.d/local_rules/modsecurity_localrules.conf mod_security /usr/lib/.build-id mod_security /usr/lib/.build-id/c0 mod_security /usr/lib/.build-id/c0/9fe3397f1beb60cd30f4fa5a3ac1a24f2c93df mod_security /usr/lib64/httpd/modules/mod_security2.so mod_security /usr/share/doc/mod_security mod_security /usr/share/doc/mod_security/CHANGES mod_security /usr/share/doc/mod_security/LICENSE mod_security /usr/share/doc/mod_security/NOTICE mod_security /usr/share/doc/mod_security/README.md mod_security /var/lib/mod_security [harry@srv-rhsoft:/downloads]$ rpm -q --filesbypkg mod_security_crs-3.0.0-12.eln109.noarch.rpm mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-901-INITIALIZATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-905-COMMON-EXCEPTIONS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-910-IP-REPUTATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-911-METHOD-ENFORCEMENT.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-912-DOS-PROTECTION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-913-SCANNER-DETECTION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-921-PROTOCOL-ATTACK.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/REQUEST-949-BLOCKING-EVALUATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-950-DATA-LEAKAGES.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-959-BLOCKING-EVALUATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-980-CORRELATION.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf mod_security_crs /etc/httpd/modsecurity.d/activated_rules/crawlers-user-agents.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/iis-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/java-code-leakages.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/java-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/lfi-os-files.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-config-directives.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-function-names-933150.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-function-names-933151.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/php-variables.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/restricted-files.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scanners-headers.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scanners-urls.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scanners-user-agents.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/scripting-user-agents.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/sql-errors.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/sql-function-names.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/unix-shell.data mod_security_crs /etc/httpd/modsecurity.d/activated_rules/windows-powershell-commands.data mod_security_crs /etc/httpd/modsecurity.d/crs-setup.conf mod_security_crs /usr/share/doc/mod_security_crs mod_security_crs /usr/share/doc/mod_security_crs/CHANGES mod_security_crs /usr/share/doc/mod_security_crs/README.md mod_security_crs /usr/share/licenses/mod_security_crs mod_security_crs /usr/share/licenses/mod_security_crs/LICENSE mod_security_crs /usr/share/mod_modsecurity_crs mod_security_crs /usr/share/mod_modsecurity_crs/rules mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-901-INITIALIZATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-910-IP-REPUTATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-912-DOS-PROTECTION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-913-SCANNER-DETECTION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-950-DATA-LEAKAGES.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/RESPONSE-980-CORRELATION.conf mod_security_crs /usr/share/mod_modsecurity_crs/rules/crawlers-user-agents.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/iis-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/java-code-leakages.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/java-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/lfi-os-files.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-config-directives.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-function-names-933150.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-function-names-933151.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/php-variables.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/restricted-files.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scanners-headers.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scanners-urls.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scanners-user-agents.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/scripting-user-agents.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/sql-errors.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/sql-function-names.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/unix-shell.data mod_security_crs /usr/share/mod_modsecurity_crs/rules/windows-powershell-commands.data |
|
From: Ervin H. <ai...@gm...> - 2021-02-22 07:41:52
|
Hi Jason, On Sun, Feb 21, 2021 at 07:28:21PM +0000, Jason Long wrote: > Thank you so much for your answer.I installed ModSecurity as below: > # yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl GeoIP-devel doxygen zlib-devel pcre-devel# cd /opt/# git clone https://github.com/SpiderLabs/ModSecurity# cd ModSecurity# git checkout -b v3/master origin/v3/master# sh build.sh# git submodule init# git submodule update# ./configure# yum install https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/23/x86_64/b/bison-3.0.4-3.fc23.x86_64.rpm# make# make install in your first mail you wrote: > I'm using CentOS 8 x86_64 and I want to configure ModSecurity > for Apache. I looked at > "https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache" > tutorial and that tutorial suggests install "mod_security" package: `sudo yum install mod_security` Therefore I don't see the reason why did you installed these development tools and why did you installed ModSecurity v3... > But I can't see any "mod_security.conf" file in "httpd" directory! Why? I don't have any CentOS (ANY) system, just downloaded the package from here: http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/mod_security-2.9.2-8.el8.x86_64.rpm and found mod_security.conf with name '/etc/httpd/conf.d/mod_security.conf'. a. |
|
From: Jason L. <hac...@ya...> - 2021-02-21 19:28:40
|
Thank you so much for your answer.I installed ModSecurity as below: # yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl GeoIP-devel doxygen zlib-devel pcre-devel# cd /opt/# git clone https://github.com/SpiderLabs/ModSecurity# cd ModSecurity# git checkout -b v3/master origin/v3/master# sh build.sh# git submodule init# git submodule update# ./configure# yum install https://archives.fedoraproject.org/pub/archive/fedora/linux/updates/23/x86_64/b/bison-3.0.4-3.fc23.x86_64.rpm# make# make install But I can't see any "mod_security.conf" file in "httpd" directory! Why? On Sunday, February 21, 2021, 07:16:54 PM GMT+3:30, Ervin Hegedüs <ai...@gm...> wrote: On Sun, Feb 21, 2021 at 03:11:17PM +0000, Jason Long via mod-security-users wrote: > Hello,Any tutorial about configuring it? https://coreruleset.org/installation/ https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Not a CentOS 8 specific, but hope this helps. a. |
|
From: Ervin H. <ai...@gm...> - 2021-02-21 15:47:09
|
On Sun, Feb 21, 2021 at 03:11:17PM +0000, Jason Long via mod-security-users wrote: > Hello,Any tutorial about configuring it? https://coreruleset.org/installation/ https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Not a CentOS 8 specific, but hope this helps. a. |
|
From: Jason L. <hac...@ya...> - 2021-02-21 15:11:34
|
Hello,Any tutorial about configuring it?
On Friday, February 19, 2021, 03:28:00 PM GMT+3:30, Jason Long via mod-security-users <mod...@li...> wrote:
Thank you.I did:# yum install mod_securityLast metadata expiration check: 1:10:47 ago on Thu 18 Feb 2021 05:21:45 PM +0330.Package mod_security-2.9.2-8.el8.x86_64 is already installed.Dependencies resolved.Nothing to do.Complete!
As you see, it installed mod_security-2.9.2. My main problem is how to configure it!The URL that I sent is a little old tutorial.
On Friday, February 19, 2021, 10:41:44 AM GMT+3:30, Reindl Harald <h.r...@th...> wrote:
Am 19.02.21 um 07:10 schrieb Jason Long via mod-security-users:
> Hello,
> I'm using CentOS 8 x86_64 and I want to configure ModSecurity for
> Apache. I looked at
> "https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache"
> tutorial, but I can't find any "/etc/modsecurity" directory!!!
> I used below find command to find that directory:
>
> # find / -name modsecurity -print
>
> But no result.
>
> Is "/etc/modsecurity" directory replaced by
> "/etc/httpd/conf.d/mod_security.conf" and
> "/etc/httpd/conf.modules.d/10-mod_security.conf" ?
besides that's that higly packaging dependent you don't even say which
version of modsec you are using and from where the package comes
my private packages of modsec2 as example expecting their rules in
/etc/httpd/modsecurity.d/
BTW: CentOS8 is dying!
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/
|
|
From: Jason L. <hac...@ya...> - 2021-02-19 11:54:14
|
Thank you.I did:# yum install mod_securityLast metadata expiration check: 1:10:47 ago on Thu 18 Feb 2021 05:21:45 PM +0330.Package mod_security-2.9.2-8.el8.x86_64 is already installed.Dependencies resolved.Nothing to do.Complete!
As you see, it installed mod_security-2.9.2. My main problem is how to configure it!The URL that I sent is a little old tutorial.
On Friday, February 19, 2021, 10:41:44 AM GMT+3:30, Reindl Harald <h.r...@th...> wrote:
Am 19.02.21 um 07:10 schrieb Jason Long via mod-security-users:
> Hello,
> I'm using CentOS 8 x86_64 and I want to configure ModSecurity for
> Apache. I looked at
> "https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache"
> tutorial, but I can't find any "/etc/modsecurity" directory!!!
> I used below find command to find that directory:
>
> # find / -name modsecurity -print
>
> But no result.
>
> Is "/etc/modsecurity" directory replaced by
> "/etc/httpd/conf.d/mod_security.conf" and
> "/etc/httpd/conf.modules.d/10-mod_security.conf" ?
besides that's that higly packaging dependent you don't even say which
version of modsec you are using and from where the package comes
my private packages of modsec2 as example expecting their rules in
/etc/httpd/modsecurity.d/
BTW: CentOS8 is dying!
_______________________________________________
mod-security-users mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/
|
|
From: Ervin H. <ai...@gm...> - 2021-02-19 07:11:51
|
Hi Jason, On Fri, Feb 19, 2021 at 06:10:16AM +0000, Jason Long via mod-security-users wrote: > Hello,I'm using CentOS 8 x86_64 and I want to configure ModSecurity for Apache. I looked at "https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache" tutorial, but I can't find any "/etc/modsecurity" directory!!!I used below find command to find that directory: > # find / -name modsecurity -print > But no result. > Is "/etc/modsecurity" directory replaced by "/etc/httpd/conf.d/mod_security.conf" and "/etc/httpd/conf.modules.d/10-mod_security.conf" ? I think you should install modsecurity-crs package: https://git.centos.org/rpms/mod_security_crs/tree/c8 or donwload the latest stable version: https://github.com/coreruleset/coreruleset/releases/tag/v3.3.0 Note, in this case the "/etc/modsecurity" directory not needed, you can make your structure as you want. Hope this helps, a. |
|
From: Reindl H. <h.r...@th...> - 2021-02-19 07:08:07
|
Am 19.02.21 um 07:10 schrieb Jason Long via mod-security-users: > Hello, > I'm using CentOS 8 x86_64 and I want to configure ModSecurity for > Apache. I looked at > "https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache" > tutorial, but I can't find any "/etc/modsecurity" directory!!! > I used below find command to find that directory: > > # find / -name modsecurity -print > > But no result. > > Is "/etc/modsecurity" directory replaced by > "/etc/httpd/conf.d/mod_security.conf" and > "/etc/httpd/conf.modules.d/10-mod_security.conf" ? besides that's that higly packaging dependent you don't even say which version of modsec you are using and from where the package comes my private packages of modsec2 as example expecting their rules in /etc/httpd/modsecurity.d/ BTW: CentOS8 is dying! |
|
From: Jason L. <hac...@ya...> - 2021-02-19 06:10:30
|
Hello,I'm using CentOS 8 x86_64 and I want to configure ModSecurity for Apache. I looked at "https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache" tutorial, but I can't find any "/etc/modsecurity" directory!!!I used below find command to find that directory: # find / -name modsecurity -print But no result. Is "/etc/modsecurity" directory replaced by "/etc/httpd/conf.d/mod_security.conf" and "/etc/httpd/conf.modules.d/10-mod_security.conf" ? Thank you. |
|
From: Davy G. <da...@ya...> - 2021-02-18 06:16:13
|
Please unsubscribe me from the group. I no longer need the mailing list. Dikirim dari Yahoo Mail di Android Pada Kam, 18 Feb 2021 pada 5:14, Christian Folini<chr...@ne...> menulis: Andrew, This is excellent. I never really thought this through to the end and now it clicked. The point is this: Every installation I have seen hitherto includes the recommended rules before the actual rule set. Given most rules run in phase 2, rule 200005 will run before the PCRE error hits. This means the moment rule 200005 checks for PCRE limit errors, said errors have not occurred yet and when they pop up, there is no rule taking care of the situation anymore and PCRE limit errors will be ignored. Probably one of the reasons you rarely see 200005 trigger. It might be worthwhile to shift rule 200005 to phase 3 or move it after the other rules towards the end of phase 2. Best, Christian On Wed, Feb 17, 2021 at 02:34:53PM +0000, Andrew Howe wrote: > Hi Ed, > > > This is not a rule violation, so where would I find a specification for the error it gets. > > I believe that if a PCRE match limit is hit then the flag > MSC_PCRE_LIMITS_EXCEEDED is set. > > A rule would be required to look for the presence of that flag and > take appropriate action if it is set. > > The ModSecurity default configuration (modsecurity.conf-recommended, > https://github.com/SpiderLabs/ModSecurity/blob/v3/master/modsecurity.conf-recommended) > contains the following rule: > > > # Some internal errors will set flags in TX and we will need to > look for these. > # All of these are prefixed with "MSC_". The following flags > currently exist: > # > # MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded. > # > SecRule TX:/^MSC_/ "!@streq 0" \ > "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal > error flagged: %{MATCHED_VAR_NAME}'" > > > On a ModSecurity deployment using that default rule, a request that > hits a PCRE match limit would be denied. I suppose a "status:" action > could be added to specify which response status code to use, as you > mentioned. > > I hope this helps aanswer your question. > > Thanks, > Andrew > > -- > > Andrew Howe > Loadbalancer.org Ltd. > www.loadbalancer.org > +1 888 867 9504 / +44 (0)330 380 1064 > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurinty.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: http://www.modsecurity.org/projects/commercial/rules/ http://www.modsecurity.org/projects/commercial/support/ |
|
From: Christian F. <chr...@ne...> - 2021-02-17 22:11:01
|
Andrew, This is excellent. I never really thought this through to the end and now it clicked. The point is this: Every installation I have seen hitherto includes the recommended rules before the actual rule set. Given most rules run in phase 2, rule 200005 will run before the PCRE error hits. This means the moment rule 200005 checks for PCRE limit errors, said errors have not occurred yet and when they pop up, there is no rule taking care of the situation anymore and PCRE limit errors will be ignored. Probably one of the reasons you rarely see 200005 trigger. It might be worthwhile to shift rule 200005 to phase 3 or move it after the other rules towards the end of phase 2. Best, Christian On Wed, Feb 17, 2021 at 02:34:53PM +0000, Andrew Howe wrote: > Hi Ed, > > > This is not a rule violation, so where would I find a specification for the error it gets. > > I believe that if a PCRE match limit is hit then the flag > MSC_PCRE_LIMITS_EXCEEDED is set. > > A rule would be required to look for the presence of that flag and > take appropriate action if it is set. > > The ModSecurity default configuration (modsecurity.conf-recommended, > https://github.com/SpiderLabs/ModSecurity/blob/v3/master/modsecurity.conf-recommended) > contains the following rule: > > > # Some internal errors will set flags in TX and we will need to > look for these. > # All of these are prefixed with "MSC_". The following flags > currently exist: > # > # MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded. > # > SecRule TX:/^MSC_/ "!@streq 0" \ > "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal > error flagged: %{MATCHED_VAR_NAME}'" > > > On a ModSecurity deployment using that default rule, a request that > hits a PCRE match limit would be denied. I suppose a "status:" action > could be added to specify which response status code to use, as you > mentioned. > > I hope this helps aanswer your question. > > Thanks, > Andrew > > -- > > Andrew Howe > Loadbalancer.org Ltd. > www.loadbalancer.org > +1 888 867 9504 / +44 (0)330 380 1064 > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurinty.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ |
|
From: Ed G. <Ed....@mr...> - 2021-02-17 16:38:32
|
Thanks for the answer. The web is full of explanations of how to cure the error, but I could not find the info you just provided. The submission that is failing is a json upload with two large base64 encoded text strings, so I'm not surprised it's hitting the limit. Ed -----Original Message----- From: Andrew Howe <and...@lo...> Sent: Wednesday, February 17, 2021 9:35 AM To: mod...@li... Subject: Re: [mod-security-users] question about PCRE limits exceeded Hi Ed, > This is not a rule violation, so where would I find a specification for the error it gets. I believe that if a PCRE match limit is hit then the flag MSC_PCRE_LIMITS_EXCEEDED is set. A rule would be required to look for the presence of that flag and take appropriate action if it is set. The ModSecurity default configuration (modsecurity.conf-recommended, https://github.com/SpiderLabs/ModSecurity/blob/v3/master/modsecurity.conf-recommended) contains the following rule: # Some internal errors will set flags in TX and we will need to look for these. # All of these are prefixed with "MSC_". The following flags currently exist: # # MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded. # SecRule TX:/^MSC_/ "!@streq 0" \ "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'" On a ModSecurity deployment using that default rule, a request that hits a PCRE match limit would be denied. I suppose a "status:" action could be added to specify which response status code to use, as you mentioned. I hope this helps answer your question. Thanks, Andrew -- Andrew Howe Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: http://www.modsecurity.org/projects/commercial/rules/ http://www.modsecurity.org/projects/commercial/support/ This electronic message transmission contains information from MRI Software LLC which is (i) confidential; or (ii) otherwise the exclusive property of the intended recipient or MRI Software LLC (neither of which is waived nor lost by mistaken delivery). This information is intended for the use of the individual or entity that is the intended recipient. If you are not the designated recipient, please be aware that any dissemination, distribution or copying of this communication is strictly prohibited. Please notify us if you have received this message in error, and remove both emails from your system. Any unauthorized use is expressly prohibited. Thank you for your assistance. |
|
From: Andrew H. <and...@lo...> - 2021-02-17 14:59:15
|
Hi Ed, > This is not a rule violation, so where would I find a specification for the error it gets. I believe that if a PCRE match limit is hit then the flag MSC_PCRE_LIMITS_EXCEEDED is set. A rule would be required to look for the presence of that flag and take appropriate action if it is set. The ModSecurity default configuration (modsecurity.conf-recommended, https://github.com/SpiderLabs/ModSecurity/blob/v3/master/modsecurity.conf-recommended) contains the following rule: # Some internal errors will set flags in TX and we will need to look for these. # All of these are prefixed with "MSC_". The following flags currently exist: # # MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded. # SecRule TX:/^MSC_/ "!@streq 0" \ "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'" On a ModSecurity deployment using that default rule, a request that hits a PCRE match limit would be denied. I suppose a "status:" action could be added to specify which response status code to use, as you mentioned. I hope this helps answer your question. Thanks, Andrew -- Andrew Howe Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 |
|
From: Ed G. <Ed....@mr...> - 2021-02-17 13:32:11
|
So I've read about PCRE limits exceeded and understand what causes it, but my question is a followon... If my system is not in Detection Only mode, what sort of result should I get for one of these? IN rule violations, each rule has it's own status: specification. This is not a rule violation, so where would I find a specification for the error it gets. I have a few sample violations that show a 200 return. (See Below) So I'm not sure if modsec is actually interrupting the submission or if they are succeeding with less (or no) inspection. In the sample below, it also references a rule 218601 which ruby on rails related, but that's something I should ask about the ruleset, I guess. (this is not a ruby site.) Thanks, Ed --bec61605-F-- HTTP/1.1 200 OK Cache-Control: no-cache, private ... X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Strict-Transport-Security: max-age=63072000; includeSubDomains; preload X-Frame-Options: SAMEORIGIN WebNode: ip-172-31-75-176 Keep-Alive: timeout=4, max=50 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json --bec61605-H-- Message: Rule 55af32f5a1d0 [id "218601"][file "/etc/httpd/cwafrules/25_ROR_RORGen.conf"][line "17"] - Execution error - PCRE limits exceeded (-8): (null). Message: Rule 55af32f63be0 [id "218602"][file "/etc/httpd/cwafrules/25_ROR_RORGen.conf"][line "20"] - Execution error - PCRE limits exceeded (-8): (null). Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client xx.xx.xx.xx] ModSecurity: Rule 55af32f5a1d0 [id "218601"][file "/etc/httpd/cwafrules/25_ROR_RORGen.conf"][line "17"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "xxxxx.xxxxx.com"] [uri "/application-collection"] [unique_id "YCQ6RSCbkGR@Nn7yBu3EpQAAAA0"] Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client xx.xx.xx.xx] ModSecurity: Rule 55af32f63be0 [id "218602"][file "/etc/httpd/cwafrules/25_ROR_RORGen.conf"][line "20"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "xxxxx.xxxxx.com"] [uri "/application-collection"] [unique_id "YCQ6RSCbkGR@Nn7yBu3EpQAAAA0"] Apache-Handler: proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost Stopwatch: 1612986949727839 337602 (- - -) Stopwatch2: 1612986949727839 337602; combined=10395, p1=502, p2=9645, p3=0, p4=0, p5=188, sr=82, sw=60, l=0, gc=0 Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/); CWAF_Apache. Server: Apache Engine-Mode: "ENABLED" This electronic message transmission contains information from MRI Software LLC which is (i) confidential; or (ii) otherwise the exclusive property of the intended recipient or MRI Software LLC (neither of which is waived nor lost by mistaken delivery). This information is intended for the use of the individual or entity that is the intended recipient. If you are not the designated recipient, please be aware that any dissemination, distribution or copying of this communication is strictly prohibited. Please notify us if you have received this message in error, and remove both emails from your system. Any unauthorized use is expressly prohibited. Thank you for your assistance. |
|
From: <az...@po...> - 2021-01-14 08:29:04
|
Hi friends,
i'm having problems with getting access to rule tags within Lua script
in modsecurity 2, off course i tried (wasn't working):
m.getvars("RULE.TAG", "none")
m.getvars("RULE.TAGS", "none")
I also checked the source code and it seems that tags are not
accessible using 'RULE' variable. Is there any other way? Thanks!
azurIt
|
|
From: Christian F. <chr...@ne...> - 2021-01-13 16:15:13
|
No worries. Nothing wrong with speaking up - and thank you for your patience. Best, Christian On Wed, Jan 13, 2021 at 11:16:52AM -0000, Jamie Burchell wrote: > Thanks Christian and I apologise for my original message being a bit > blunt. > > -----Original Message----- > From: Christian Folini <chr...@ne...> > Sent: 11 January 2021 14:03 > To: mod...@li... > Subject: Re: [mod-security-users] CRS Issues being automatically closed? > > Hello Jamie, > > On Mon, Jan 11, 2021 at 12:10:03PM -0000, Jamie Burchell wrote: > > Thanks for the response and apologise for posting in the incorrect list. > > No worries. > > > Great to see there is things in development to address this. > > > > I just wanted to re-iterate that the issue I raise is not one of > > expectation for anyone to look at the issues reported (in their spare > > time or otherwise) - I fully understand your points here. Rather, I > > would just prefer to see current issues not automatically closed and > buried. > > Ah. Thanks. We're full of guilt already, so my reaction tends to be a bit > on the defensive side when it comes to this topic. > > The issues are not gone, they are just a bit hidden. But I have now added > a link to a query that lets you filter for them on github. The link is in > our README and also on the coreruleset.org website. I think we should have > added this before and also documented the process much earlier. Thanks for > pointing it out. > > Cheers, > > Christian > > > > > > Best Regards, > > Jamie > > > > -----Original Message----- > > From: Christian Folini <chr...@ne...> > > Sent: 11 January 2021 07:21 > > To: mod...@li... > > Subject: Re: [mod-security-users] CRS Issues being automatically closed? > > > > Hey Jamie, > > > > This is the mailing list for the ModSecurity engine. The CRS project > > has a separate mailinglist over at > > > > https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-proj > > ect > > > > But let me answer your question nevertheless: > > > > You are correct and this configuration to close stale issues after 120 > > days is offensive. And we did not take it lightly. We have been > > struggling with not being able to address all the issues for years. We > > tried different methods, scheduling, assigning, highlighting, inviting > > the wider community to help, tagging as "#goodfirstissue" etc. But it > > did not bring a real solution: The issues pile up and new issues (also > > vital ones!) can end up buried under a pile that is too big to plough > through. > > > > As most open source projects, CRS is a volunteer driven project. > > People work on CRS because they want to work on CRS. Some steal time > > from their companies to do so, some put their children to bed to hack > > away. But it is always time that our developers give to the project > > freely. I as a co-leader of the project can not force issues into > > their hands. All I can do is making CRS a fun project to work with and > > prepare the environment in a way that makes it easy and cool to work on > CRS. > > > > And the huge pile of issues started to have a chilling effect on > > developers or new developers. There is a moment where the pile is so > > big, you are not even addressing what you can address because of all the > rest. > > Looking at the > > 36 issues open right now feels managable and most issues are being > > addressed. > > (You can tell easily, since most open issues do have a conversation > > history.) > > > > So we talked about the step a big deal and we took the decision about > > a year ago. Ultimately it was a decision to pick between the goodwill > > and health of the developers and the goodwill of individual users. I > > am really not happy with the way it is and I have a new plan to help > > us address all the issues before they get stale. But it is not quite > ready to share. > > > > What can you do: If you care about an issue, then comment on it. We > > read every comment on every issue. If get the notice that the issue > > has been tagged for removal (the tag "Stale issue" is being applied 2 > > weeks or so before it gets closed), then comment on the issue and tell > > us you still care. Also multiple users chiming in give an issue priority > in our eyes. > > We currently do an issue chat once a month (3rd Monday every month), > > where we look into 5-10 open issues. One way to make sure an issue > > makes it into that meeting is the tag "Meeting agenda". Ask us to add > > this tag and we will take it on the list. > > > > All in all, using the services of the stale issue bot is not a sign > > that we do not care. Quite the opposite. We care a lot and we feel bad > > about using the stale issue bot. But it was the only solution we saw. > > > > Hope this explains our reasoning a bit. > > > > Best regards and thanks for speaking up, > > > > Christian Folini, CRS Co-Lead > > > > > > > > > > > > > > On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote: > > > Hi CRS Team > > > > > > I'm disappointed to see that issues I'm reporting (FPs) (e.g. > > > https://github.com/coreruleset/coreruleset/issues/1864) are being > > > automatically closed by stalebot. I fully understand that there may > > > not be the time nor the resources to address issues reported, and I > > > know why stalebot exists, but I don't think rule issues that people > > > have spent time looking at and reporting should be closed before > > > they are actually addressed. It certainly doesn't encourage me to > > > continue reporting them moving forward. > > > > > > Cheers, Jamie > > > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ |
|
From: Jamie B. <ja...@ib...> - 2021-01-13 11:24:47
|
Thanks Christian and I apologise for my original message being a bit blunt. -----Original Message----- From: Christian Folini <chr...@ne...> Sent: 11 January 2021 14:03 To: mod...@li... Subject: Re: [mod-security-users] CRS Issues being automatically closed? Hello Jamie, On Mon, Jan 11, 2021 at 12:10:03PM -0000, Jamie Burchell wrote: > Thanks for the response and apologise for posting in the incorrect list. No worries. > Great to see there is things in development to address this. > > I just wanted to re-iterate that the issue I raise is not one of > expectation for anyone to look at the issues reported (in their spare > time or otherwise) - I fully understand your points here. Rather, I > would just prefer to see current issues not automatically closed and buried. Ah. Thanks. We're full of guilt already, so my reaction tends to be a bit on the defensive side when it comes to this topic. The issues are not gone, they are just a bit hidden. But I have now added a link to a query that lets you filter for them on github. The link is in our README and also on the coreruleset.org website. I think we should have added this before and also documented the process much earlier. Thanks for pointing it out. Cheers, Christian > > Best Regards, > Jamie > > -----Original Message----- > From: Christian Folini <chr...@ne...> > Sent: 11 January 2021 07:21 > To: mod...@li... > Subject: Re: [mod-security-users] CRS Issues being automatically closed? > > Hey Jamie, > > This is the mailing list for the ModSecurity engine. The CRS project > has a separate mailinglist over at > > https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-proj > ect > > But let me answer your question nevertheless: > > You are correct and this configuration to close stale issues after 120 > days is offensive. And we did not take it lightly. We have been > struggling with not being able to address all the issues for years. We > tried different methods, scheduling, assigning, highlighting, inviting > the wider community to help, tagging as "#goodfirstissue" etc. But it > did not bring a real solution: The issues pile up and new issues (also > vital ones!) can end up buried under a pile that is too big to plough through. > > As most open source projects, CRS is a volunteer driven project. > People work on CRS because they want to work on CRS. Some steal time > from their companies to do so, some put their children to bed to hack > away. But it is always time that our developers give to the project > freely. I as a co-leader of the project can not force issues into > their hands. All I can do is making CRS a fun project to work with and > prepare the environment in a way that makes it easy and cool to work on CRS. > > And the huge pile of issues started to have a chilling effect on > developers or new developers. There is a moment where the pile is so > big, you are not even addressing what you can address because of all the rest. > Looking at the > 36 issues open right now feels managable and most issues are being > addressed. > (You can tell easily, since most open issues do have a conversation > history.) > > So we talked about the step a big deal and we took the decision about > a year ago. Ultimately it was a decision to pick between the goodwill > and health of the developers and the goodwill of individual users. I > am really not happy with the way it is and I have a new plan to help > us address all the issues before they get stale. But it is not quite ready to share. > > What can you do: If you care about an issue, then comment on it. We > read every comment on every issue. If get the notice that the issue > has been tagged for removal (the tag "Stale issue" is being applied 2 > weeks or so before it gets closed), then comment on the issue and tell > us you still care. Also multiple users chiming in give an issue priority in our eyes. > We currently do an issue chat once a month (3rd Monday every month), > where we look into 5-10 open issues. One way to make sure an issue > makes it into that meeting is the tag "Meeting agenda". Ask us to add > this tag and we will take it on the list. > > All in all, using the services of the stale issue bot is not a sign > that we do not care. Quite the opposite. We care a lot and we feel bad > about using the stale issue bot. But it was the only solution we saw. > > Hope this explains our reasoning a bit. > > Best regards and thanks for speaking up, > > Christian Folini, CRS Co-Lead > > > > > > > On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote: > > Hi CRS Team > > > > I'm disappointed to see that issues I'm reporting (FPs) (e.g. > > https://github.com/coreruleset/coreruleset/issues/1864) are being > > automatically closed by stalebot. I fully understand that there may > > not be the time nor the resources to address issues reported, and I > > know why stalebot exists, but I don't think rule issues that people > > have spent time looking at and reporting should be closed before > > they are actually addressed. It certainly doesn't encourage me to > > continue reporting them moving forward. > > > > Cheers, Jamie > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: http://www.modsecurity.org/projects/commercial/rules/ http://www.modsecurity.org/projects/commercial/support/ |