mod-security-users Mailing List for ModSecurity (Page 48)
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users — General discussion about mod_security
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: Cristiano G. <cri...@ga...> - 2018-03-14 21:42:33
|
Yep! My application use JSON payloads.
Christian, please try it:
$> curl -H "Content-Type: application/json" -X POST -d '{"cvv”:"123"}' http://localhost/?id=/bin/bash
Cristiano Galdino
(61) 9860 1 9860
cri...@ga...
On 14 Mar 2018 18:38 -0300, Robert Paprocki <rpa...@fe...>, wrote:
> Christian, you tested with a application/x-www-form-urlencoded request; Christiano's use case involves JSON-encoded bodies.
>
> I do not believe JSON request bodies can be translated into data collections that can have sanitize actions applied on them at this point.
>
> > On Wed, Mar 14, 2018 at 2:34 PM, Christian Folini <chr...@ne...> wrote:
> > > Hello Cristiano,
> > >
> > > I did the following request:
> > >
> > > $> curl localhost -d "CVV=0000-0000-0000-0000" -d "exec=/bin/bash"
> > >
> > > and got the following audit-log when using CRS3 (parameter exec triggering
> > > the writing of the audit log):
> > >
> > > --a7997f3d-A--
> > > [14/Mar/2018:22:29:03 +0100] WqmUH6r6pkVX9OUmJm3aggAAAAM 127.0.0.1 50058 127.0.0.1 40080
> > > --a7997f3d-B--
> > > POST / HTTP/1.1
> > > Host: localhost
> > > User-Agent: curl/7.50.1
> > > Accept: */*
> > > Content-Length: 38
> > > Content-Type: application/x-www-form-urlencoded
> > >
> > > --a7997f3d-C--
> > > CVV=*******************&exec=/bin/bash
> > > --a7997f3d-F--
> > > HTTP/1.1 200 OK
> > > Last-Modified: Sun, 17 Dec 2017 11:08:45 GMT
> > > ETag: "2d-5608741dac6fd"
> > > Accept-Ranges: bytes
> > > Content-Length: 45
> > > Content-Type: text/html
> > > ...
> > >
> > >
> > >
> > > I'm running ModSec 2.9.2 on Apache 2.4.29, both self compiled according to
> > > the tutorials on netnea.com.
> > >
> > > My ModSec Configuration:
> > >
> > > ------------------------------------------------------------------------------
> > >
> > > SecRuleEngine On
> > >
> > > SecRequestBodyAccess On
> > > SecRequestBodyLimit 10000000
> > > SecRequestBodyNoFilesLimit 64000
> > >
> > > SecResponseBodyAccess On
> > > SecResponseBodyLimit 10000000
> > >
> > > SecTmpDir /tmp/
> > > SecDataDir /tmp/
> > > SecUploadDir /tmp/
> > >
> > > SecDebugLog /apache/logs/modsec_debug.log
> > > SecDebugLogLevel 3
> > >
> > > SecAuditEngine RelevantOnly
> > > SecAuditLogRelevantStatus "^(?:5|4(?!04))"
> > > SecAuditLogParts ABEFHIJZ
> > >
> > > SecAuditLogType Concurrent
> > > SecAuditLog /apache/logs/modsec_audit.log
> > > SecAuditLogStorageDir /apache/logs/audit/
> > >
> > > SecPcreMatchLimit 500000
> > > SecPcreMatchLimitRecursion 500000
> > >
> > > SecDefaultAction "phase:2,pass,log"
> > >
> > >
> > >
> > > # == ModSec Rule ID Namespace Definition
> > > # Service-specific before Core-Rules: 10000 - 49999
> > > # Service-specific after Core-Rules: 50000 - 79999
> > > # Locally shared rules: 80000 - 99999
> > > # - Performance: 90000 - 90199
> > > # Recommended ModSec Rules (few): 200000 - 200010
> > > # OWASP Core-Rules: 900000 - 999999
> > >
> > >
> > > # === ModSec timestamps at the start of each phase (ids: 90000 - 90009)
> > >
> > > SecAction "id:'90000',phase:1,nolog,pass,setvar:TX.ModSecTimestamp1start=%{DURATION}"
> > > SecAction "id:'90001',phase:2,nolog,pass,setvar:TX.ModSecTimestamp2start=%{DURATION}"
> > > SecAction "id:'90002',phase:3,nolog,pass,setvar:TX.ModSecTimestamp3start=%{DURATION}"
> > > SecAction "id:'90003',phase:4,nolog,pass,setvar:TX.ModSecTimestamp4start=%{DURATION}"
> > > SecAction "id:'90004',phase:5,nolog,pass,setvar:TX.ModSecTimestamp5start=%{DURATION}"
> > >
> > > # SecRule REQUEST_FILENAME "@beginsWith /" "id:'90005',phase:5,t:none,nolog,noauditlog,pass,setenv:write_perflog"
> > >
> > >
> > >
> > > # === ModSec Recommended Rules (in modsec src package) (ids: 200000-200010)
> > >
> > > SecRule REQUEST_HEADERS:Content-Type "text/xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
> > >
> > > SecRule REQBODY_ERROR "!@eq 0" "id:'200001',phase:2,t:none,deny,status:400,log,msg:'Failed to parse request body.',\
> > > logdata:'%{reqbody_error_msg}',severity:2"
> > >
> > > SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
> > > "id:'200002',phase:2,t:none,log,deny,status:403, \
> > > msg:'Multipart request body failed strict validation: \
> > > PE %{REQBODY_PROCESSOR_ERROR}, \
> > > BQ %{MULTIPART_BOUNDARY_QUOTED}, \
> > > BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
> > > DB %{MULTIPART_DATA_BEFORE}, \
> > > DA %{MULTIPART_DATA_AFTER}, \
> > > HF %{MULTIPART_HEADER_FOLDING}, \
> > > LF %{MULTIPART_LF_LINE}, \
> > > SM %{MULTIPART_MISSING_SEMICOLON}, \
> > > IQ %{MULTIPART_INVALID_QUOTING}, \
> > > IP %{MULTIPART_INVALID_PART}, \
> > > IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
> > > FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
> > >
> > > SecRule TX:/^MSC_/ "!@streq 0" "id:'200004',phase:2,t:none,deny,status:500,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
> > >
> > >
> > > # === ModSecurity Rules (ids: 900000-999999)
> > >
> > > # === ModSec Core Rules Base Configuration (ids: 900001-900021)
> > >
> > > Include /home/dune73/data/git/crs-official/crs-setup.conf.example
> > >
> > > SecAction "id:900111,phase:1,nolog,pass,t:none,setvar:tx.inbound_anomaly_score_threshold=500,setvar:tx.outbound_anomaly_score_threshold=500"
> > > SecAction "id:'900000',phase:1,nolog,pass,t:none,setvar:tx.paranoia_level=4"
> > >
> > > # === ModSecurity Ignore Rules Before Core Rules Inclusion; order by id of ignored rule (ids: 10000-49999)
> > >
> > > # SecRule ARGS:a "." "id:1001,phase:2,pass,log,msg:'XXX1: %{MATCHED_VAR}'"
> > >
> > > # SecRule ARGS_GET:a "." "id:1002,phase:2,pass,log,msg:'XXX2: %{MATCHED_VAR}'"
> > >
> > > # SecRule ARGS_POST:a "." "id:1003,phase:2,pass,log,msg:'XXX3: %{MATCHED_VAR}'"
> > >
> > > # SecRule REQUEST_URI "." "id:1004,phase:2,pass,log,msg:'XXX4: %{MATCHED_VAR}'"
> > >
> > > # SecRule REQUEST_HEADERS:User-Agent "." "id:1005,phase:2,pass,log,msg:'XXX5: %{MATCHED_VAR}'"
> > >
> > > SecRule ARGS:b "." "id:1006,phase:2,pass,log,auditlog,msg:'XXX6: %{MATCHED_VAR}'"
> > >
> > >
> > > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV"
> > > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse"
> > >
> > >
> > >
> > >
> > >
> > > # === ModSecurity Core Rules Inclusion
> > >
> > > Include /home/dune73/data/git/crs-official/rules/*.conf
> > >
> > > # === ModSec Core Rules: Startup Time Rules Exclusions
> > >
> > >
> > >
> > >
> > >
> > >
> > > # === ModSec timestamps at the end of each phase (ids: 90010 - 90019)
> > >
> > > SecAction "id:'90010',phase:1,pass,nolog,setvar:TX.ModSecTimestamp1end=%{DURATION}"
> > > SecAction "id:'90011',phase:2,pass,nolog,setvar:TX.ModSecTimestamp2end=%{DURATION}"
> > > SecAction "id:'90012',phase:3,pass,nolog,setvar:TX.ModSecTimestamp3end=%{DURATION}"
> > > SecAction "id:'90013',phase:4,pass,nolog,setvar:TX.ModSecTimestamp4end=%{DURATION}"
> > > SecAction "id:'90014',phase:5,pass,nolog,setvar:TX.ModSecTimestamp5end=%{DURATION}"
> > >
> > >
> > > # === ModSec performance calculations and variable export (ids: 90100 - 90199)
> > >
> > > SecAction "id:'90100',phase:5,pass,nolog,setvar:TX.perf_modsecinbound=%{PERF_PHASE1}"
> > > SecAction "id:'90101',phase:5,pass,nolog,setvar:TX.perf_modsecinbound=+%{PERF_PHASE2}"
> > > SecAction "id:'90102',phase:5,pass,nolog,setvar:TX.perf_application=%{TX.ModSecTimestamp3start}"
> > > SecAction "id:'90103',phase:5,pass,nolog,setvar:TX.perf_application=-%{TX.ModSecTimestamp2end}"
> > > SecAction "id:'90104',phase:5,pass,nolog,setvar:TX.perf_modsecoutbound=%{PERF_PHASE3}"
> > > SecAction "id:'90105',phase:5,pass,nolog,setvar:TX.perf_modsecoutbound=+%{PERF_PHASE4}"
> > > SecAction "id:'90106',phase:5,pass,nolog,setenv:ModSecTimeIn=%{TX.perf_modsecinbound}"
> > > SecAction "id:'90107',phase:5,pass,nolog,setenv:ApplicationTime=%{TX.perf_application}"
> > > SecAction "id:'90108',phase:5,pass,nolog,setenv:ModSecTimeOut=%{TX.perf_modsecoutbound}"
> > > SecAction "id:'90109',phase:5,pass,nolog,setenv:ModSecAnomalyScoreIn=%{TX.anomaly_score}"
> > > SecAction "id:'90110',phase:5,pass,nolog,setenv:ModSecAnomalyScoreOut=%{TX.outbound_anomaly_score}"
> > >
> > >
> > > # === End ModSec Configuration
> > >
> > > ------------------------------------------------------------------------------
> > >
> > >
> > > So I think this generally works. If it does not for you, then please try and
> > > reproduce the behaviour on the latest ModSec version of the 2.9 series and
> > > open a bug report in case.
> > >
> > > Ahoj,
> > >
> > > Christian
> > >
> > >
> > >
> > > On Wed, Mar 14, 2018 at 06:13:04PM -0300, Cristiano Galdino wrote:
> > > > Hi Christian!
> > > > Modsecurity: 2.9.0-1 (from Ubuntu repository)
> > > > Apache 2.4.18-2ubuntu3.5
> > > > Tks!
> > > >
> > > > Cristiano Galdino
> > > > cri...@ga...
> > > >
> > > > On 14 Mar 2018 17:55 -0300, Christian Folini
> > > > <chr...@ne...>, wrote:
> > > >
> > > > Hello Christiano,
> > > > What platform are you using? (-> ModSec version, Apache / NGINX /
> > > > IIS?)
> > > > Ahoj,
> > > > Christian
> > > > On Wed, Mar 14, 2018 at 05:06:28PM -0300, Cristiano Galdino wrote:
> > > >
> > > > Hello!
> > > > I created a rule in ModSecurity to sanitize param CVV (credit card)
> > > > but
> > > > it is not working.
> > > > Samples:
> > > > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV”
> > > > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse"
> > > > This prevents me from using modsecurity because PCI does not allow
> > > > CVV
> > > > to be stored.
> > > > I found this issue without response.
> > > > [1]https://github.com/SpiderLabs/ModSecurity/issues/715
> > > > What can I do?
> > > > Cristiano Galdino
> > > > cri...@ga...
> > > > References
> > > > 1. https://github.com/SpiderLabs/ModSecurity/issues/715
> > > >
> > > > --------------------------------------------------------------------
> > > > ----------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > >
> > > > _______________________________________________
> > > > 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/
> > > >
> > > > --
> > > > https://www.feistyduck.com/training/modsecurity-training-course
> > > > https://www.feistyduck.com/books/modsecurity-handbook/
> > > > mailto:chr...@ne...
> > > > twitter: @ChrFolini
> > > > --------------------------------------------------------------------
> > > > ----------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > _______________________________________________
> > > > 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/
> > >
> > > > ------------------------------------------------------------------------------
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >
> > > > _______________________________________________
> > > > 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/
> > >
> > >
> > > --
> > > https://www.feistyduck.com/training/modsecurity-training-course
> > > https://www.feistyduck.com/books/modsecurity-handbook/
> > > mailto:chr...@ne...
> > > twitter: @ChrFolini
> > >
> > > ------------------------------------------------------------------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > _______________________________________________
> > > 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/
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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: Robert P. <rpa...@fe...> - 2018-03-14 21:38:16
|
Christian, you tested with a application/x-www-form-urlencoded request; Christiano's use case involves JSON-encoded bodies. I do not believe JSON request bodies can be translated into data collections that can have sanitize actions applied on them at this point. On Wed, Mar 14, 2018 at 2:34 PM, Christian Folini < chr...@ne...> wrote: > Hello Cristiano, > > I did the following request: > > $> curl localhost -d "CVV=0000-0000-0000-0000" -d "exec=/bin/bash" > > and got the following audit-log when using CRS3 (parameter exec triggering > the writing of the audit log): > > --a7997f3d-A-- > [14/Mar/2018:22:29:03 +0100] WqmUH6r6pkVX9OUmJm3aggAAAAM 127.0.0.1 50058 > 127.0.0.1 40080 > --a7997f3d-B-- > POST / HTTP/1.1 > Host: localhost > User-Agent: curl/7.50.1 > Accept: */* > Content-Length: 38 > Content-Type: application/x-www-form-urlencoded > > --a7997f3d-C-- > CVV=*******************&exec=/bin/bash > --a7997f3d-F-- > HTTP/1.1 200 OK > Last-Modified: Sun, 17 Dec 2017 11:08:45 GMT > ETag: "2d-5608741dac6fd" > Accept-Ranges: bytes > Content-Length: 45 > Content-Type: text/html > ... > > > > I'm running ModSec 2.9.2 on Apache 2.4.29, both self compiled according to > the tutorials on netnea.com. > > My ModSec Configuration: > > ------------------------------------------------------------ > ------------------ > > SecRuleEngine On > > SecRequestBodyAccess On > SecRequestBodyLimit 10000000 > SecRequestBodyNoFilesLimit 64000 > > SecResponseBodyAccess On > SecResponseBodyLimit 10000000 > > SecTmpDir /tmp/ > SecDataDir /tmp/ > SecUploadDir /tmp/ > > SecDebugLog /apache/logs/modsec_debug.log > SecDebugLogLevel 3 > > SecAuditEngine RelevantOnly > SecAuditLogRelevantStatus "^(?:5|4(?!04))" > SecAuditLogParts ABEFHIJZ > > SecAuditLogType Concurrent > SecAuditLog /apache/logs/modsec_audit.log > SecAuditLogStorageDir /apache/logs/audit/ > > SecPcreMatchLimit 500000 > SecPcreMatchLimitRecursion 500000 > > SecDefaultAction "phase:2,pass,log" > > > > # == ModSec Rule ID Namespace Definition > # Service-specific before Core-Rules: 10000 - 49999 > # Service-specific after Core-Rules: 50000 - 79999 > # Locally shared rules: 80000 - 99999 > # - Performance: 90000 - 90199 > # Recommended ModSec Rules (few): 200000 - 200010 > # OWASP Core-Rules: 900000 - 999999 > > > # === ModSec timestamps at the start of each phase (ids: 90000 - 90009) > > SecAction "id:'90000',phase:1,nolog,pass,setvar:TX. > ModSecTimestamp1start=%{DURATION}" > SecAction "id:'90001',phase:2,nolog,pass,setvar:TX. > ModSecTimestamp2start=%{DURATION}" > SecAction "id:'90002',phase:3,nolog,pass,setvar:TX. > ModSecTimestamp3start=%{DURATION}" > SecAction "id:'90003',phase:4,nolog,pass,setvar:TX. > ModSecTimestamp4start=%{DURATION}" > SecAction "id:'90004',phase:5,nolog,pass,setvar:TX. > ModSecTimestamp5start=%{DURATION}" > > # SecRule REQUEST_FILENAME "@beginsWith /" "id:'90005',phase:5,t:none, > nolog,noauditlog,pass,setenv:write_perflog" > > > > # === ModSec Recommended Rules (in modsec src package) (ids: 200000-200010) > > SecRule REQUEST_HEADERS:Content-Type "text/xml" > "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl: > requestBodyProcessor=XML" > > SecRule REQBODY_ERROR "!@eq 0" "id:'200001',phase:2,t:none, > deny,status:400,log,msg:'Failed to parse request body.',\ > logdata:'%{reqbody_error_msg}',severity:2" > > SecRule MULTIPART_STRICT_ERROR "!@eq 0" \ > "id:'200002',phase:2,t:none,log,deny,status:403, \ > msg:'Multipart request body failed strict validation: \ > PE %{REQBODY_PROCESSOR_ERROR}, \ > BQ %{MULTIPART_BOUNDARY_QUOTED}, \ > BW %{MULTIPART_BOUNDARY_WHITESPACE}, \ > DB %{MULTIPART_DATA_BEFORE}, \ > DA %{MULTIPART_DATA_AFTER}, \ > HF %{MULTIPART_HEADER_FOLDING}, \ > LF %{MULTIPART_LF_LINE}, \ > SM %{MULTIPART_MISSING_SEMICOLON}, \ > IQ %{MULTIPART_INVALID_QUOTING}, \ > IP %{MULTIPART_INVALID_PART}, \ > IH %{MULTIPART_INVALID_HEADER_FOLDING}, \ > FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'" > > SecRule TX:/^MSC_/ "!@streq 0" "id:'200004',phase:2,t:none, > deny,status:500,msg:'ModSecurity internal error flagged: > %{MATCHED_VAR_NAME}'" > > > # === ModSecurity Rules (ids: 900000-999999) > > # === ModSec Core Rules Base Configuration (ids: 900001-900021) > > Include /home/dune73/data/git/crs-official/crs-setup.conf.example > > SecAction "id:900111,phase:1,nolog,pass,t:none,setvar:tx.inbound_ > anomaly_score_threshold=500,setvar:tx.outbound_anomaly_ > score_threshold=500" > SecAction "id:'900000',phase:1,nolog,pass,t:none,setvar:tx. > paranoia_level=4" > > # === ModSecurity Ignore Rules Before Core Rules Inclusion; order by id of > ignored rule (ids: 10000-49999) > > # SecRule ARGS:a "." > "id:1001,phase:2,pass,log,msg:'XXX1: %{MATCHED_VAR}'" > > # SecRule ARGS_GET:a "." > "id:1002,phase:2,pass,log,msg:'XXX2: %{MATCHED_VAR}'" > > # SecRule ARGS_POST:a "." > "id:1003,phase:2,pass,log,msg:'XXX3: %{MATCHED_VAR}'" > > # SecRule REQUEST_URI "." > "id:1004,phase:2,pass,log,msg:'XXX4: %{MATCHED_VAR}'" > > # SecRule REQUEST_HEADERS:User-Agent "." > "id:1005,phase:2,pass,log,msg:'XXX5: %{MATCHED_VAR}'" > > SecRule ARGS:b "." "id:1006,phase:2,pass,log,auditlog,msg:'XXX6: > %{MATCHED_VAR}'" > > > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV" > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" > > > > > > # === ModSecurity Core Rules Inclusion > > Include /home/dune73/data/git/crs-official/rules/*.conf > > # === ModSec Core Rules: Startup Time Rules Exclusions > > > > > > > # === ModSec timestamps at the end of each phase (ids: 90010 - 90019) > > SecAction "id:'90010',phase:1,pass,nolog,setvar:TX.ModSecTimestamp1end=%{ > DURATION}" > SecAction "id:'90011',phase:2,pass,nolog,setvar:TX.ModSecTimestamp2end=%{ > DURATION}" > SecAction "id:'90012',phase:3,pass,nolog,setvar:TX.ModSecTimestamp3end=%{ > DURATION}" > SecAction "id:'90013',phase:4,pass,nolog,setvar:TX.ModSecTimestamp4end=%{ > DURATION}" > SecAction "id:'90014',phase:5,pass,nolog,setvar:TX.ModSecTimestamp5end=%{ > DURATION}" > > > # === ModSec performance calculations and variable export (ids: 90100 - > 90199) > > SecAction "id:'90100',phase:5,pass,nolog,setvar:TX.perf_ > modsecinbound=%{PERF_PHASE1}" > SecAction "id:'90101',phase:5,pass,nolog,setvar:TX.perf_ > modsecinbound=+%{PERF_PHASE2}" > SecAction "id:'90102',phase:5,pass,nolog,setvar:TX.perf_application=%{TX. > ModSecTimestamp3start}" > SecAction "id:'90103',phase:5,pass,nolog,setvar:TX.perf_application=-%{TX. > ModSecTimestamp2end}" > SecAction "id:'90104',phase:5,pass,nolog,setvar:TX.perf_ > modsecoutbound=%{PERF_PHASE3}" > SecAction "id:'90105',phase:5,pass,nolog,setvar:TX.perf_ > modsecoutbound=+%{PERF_PHASE4}" > SecAction "id:'90106',phase:5,pass,nolog,setenv:ModSecTimeIn=%{ > TX.perf_modsecinbound}" > SecAction "id:'90107',phase:5,pass,nolog,setenv:ApplicationTime=% > {TX.perf_application}" > SecAction "id:'90108',phase:5,pass,nolog,setenv:ModSecTimeOut=%{ > TX.perf_modsecoutbound}" > SecAction "id:'90109',phase:5,pass,nolog,setenv:ModSecAnomalyScoreIn=%{TX. > anomaly_score}" > SecAction "id:'90110',phase:5,pass,nolog,setenv: > ModSecAnomalyScoreOut=%{TX.outbound_anomaly_score}" > > > # === End ModSec Configuration > > ------------------------------------------------------------ > ------------------ > > > So I think this generally works. If it does not for you, then please try > and > reproduce the behaviour on the latest ModSec version of the 2.9 series and > open a bug report in case. > > Ahoj, > > Christian > > > > On Wed, Mar 14, 2018 at 06:13:04PM -0300, Cristiano Galdino wrote: > > Hi Christian! > > Modsecurity: 2.9.0-1 (from Ubuntu repository) > > Apache 2.4.18-2ubuntu3.5 > > Tks! > > > > Cristiano Galdino > > cri...@ga... > > > > On 14 Mar 2018 17:55 -0300, Christian Folini > > <chr...@ne...>, wrote: > > > > Hello Christiano, > > What platform are you using? (-> ModSec version, Apache / NGINX / > > IIS?) > > Ahoj, > > Christian > > On Wed, Mar 14, 2018 at 05:06:28PM -0300, Cristiano Galdino wrote: > > > > Hello! > > I created a rule in ModSecurity to sanitize param CVV (credit card) > > but > > it is not working. > > Samples: > > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV” > > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" > > This prevents me from using modsecurity because PCI does not allow > > CVV > > to be stored. > > I found this issue without response. > > [1]https://github.com/SpiderLabs/ModSecurity/issues/715 > > What can I do? > > Cristiano Galdino > > cri...@ga... > > References > > 1. https://github.com/SpiderLabs/ModSecurity/issues/715 > > > > ------------------------------------------------------------ > -------- > > ---------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > 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/ > > > > -- > > https://www.feistyduck.com/training/modsecurity-training-course > > https://www.feistyduck.com/books/modsecurity-handbook/ > > mailto:chr...@ne... > > twitter: @ChrFolini > > ------------------------------------------------------------ > -------- > > ---------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > 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/ > > > ------------------------------------------------------------ > ------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > 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/ > > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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...> - 2018-03-14 21:34:33
|
Hello Cristiano, I did the following request: $> curl localhost -d "CVV=0000-0000-0000-0000" -d "exec=/bin/bash" and got the following audit-log when using CRS3 (parameter exec triggering the writing of the audit log): --a7997f3d-A-- [14/Mar/2018:22:29:03 +0100] WqmUH6r6pkVX9OUmJm3aggAAAAM 127.0.0.1 50058 127.0.0.1 40080 --a7997f3d-B-- POST / HTTP/1.1 Host: localhost User-Agent: curl/7.50.1 Accept: */* Content-Length: 38 Content-Type: application/x-www-form-urlencoded --a7997f3d-C-- CVV=*******************&exec=/bin/bash --a7997f3d-F-- HTTP/1.1 200 OK Last-Modified: Sun, 17 Dec 2017 11:08:45 GMT ETag: "2d-5608741dac6fd" Accept-Ranges: bytes Content-Length: 45 Content-Type: text/html ... I'm running ModSec 2.9.2 on Apache 2.4.29, both self compiled according to the tutorials on netnea.com. My ModSec Configuration: ------------------------------------------------------------------------------ SecRuleEngine On SecRequestBodyAccess On SecRequestBodyLimit 10000000 SecRequestBodyNoFilesLimit 64000 SecResponseBodyAccess On SecResponseBodyLimit 10000000 SecTmpDir /tmp/ SecDataDir /tmp/ SecUploadDir /tmp/ SecDebugLog /apache/logs/modsec_debug.log SecDebugLogLevel 3 SecAuditEngine RelevantOnly SecAuditLogRelevantStatus "^(?:5|4(?!04))" SecAuditLogParts ABEFHIJZ SecAuditLogType Concurrent SecAuditLog /apache/logs/modsec_audit.log SecAuditLogStorageDir /apache/logs/audit/ SecPcreMatchLimit 500000 SecPcreMatchLimitRecursion 500000 SecDefaultAction "phase:2,pass,log" # == ModSec Rule ID Namespace Definition # Service-specific before Core-Rules: 10000 - 49999 # Service-specific after Core-Rules: 50000 - 79999 # Locally shared rules: 80000 - 99999 # - Performance: 90000 - 90199 # Recommended ModSec Rules (few): 200000 - 200010 # OWASP Core-Rules: 900000 - 999999 # === ModSec timestamps at the start of each phase (ids: 90000 - 90009) SecAction "id:'90000',phase:1,nolog,pass,setvar:TX.ModSecTimestamp1start=%{DURATION}" SecAction "id:'90001',phase:2,nolog,pass,setvar:TX.ModSecTimestamp2start=%{DURATION}" SecAction "id:'90002',phase:3,nolog,pass,setvar:TX.ModSecTimestamp3start=%{DURATION}" SecAction "id:'90003',phase:4,nolog,pass,setvar:TX.ModSecTimestamp4start=%{DURATION}" SecAction "id:'90004',phase:5,nolog,pass,setvar:TX.ModSecTimestamp5start=%{DURATION}" # SecRule REQUEST_FILENAME "@beginsWith /" "id:'90005',phase:5,t:none,nolog,noauditlog,pass,setenv:write_perflog" # === ModSec Recommended Rules (in modsec src package) (ids: 200000-200010) SecRule REQUEST_HEADERS:Content-Type "text/xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" SecRule REQBODY_ERROR "!@eq 0" "id:'200001',phase:2,t:none,deny,status:400,log,msg:'Failed to parse request body.',\ logdata:'%{reqbody_error_msg}',severity:2" SecRule MULTIPART_STRICT_ERROR "!@eq 0" \ "id:'200002',phase:2,t:none,log,deny,status:403, \ msg:'Multipart request body failed strict validation: \ PE %{REQBODY_PROCESSOR_ERROR}, \ BQ %{MULTIPART_BOUNDARY_QUOTED}, \ BW %{MULTIPART_BOUNDARY_WHITESPACE}, \ DB %{MULTIPART_DATA_BEFORE}, \ DA %{MULTIPART_DATA_AFTER}, \ HF %{MULTIPART_HEADER_FOLDING}, \ LF %{MULTIPART_LF_LINE}, \ SM %{MULTIPART_MISSING_SEMICOLON}, \ IQ %{MULTIPART_INVALID_QUOTING}, \ IP %{MULTIPART_INVALID_PART}, \ IH %{MULTIPART_INVALID_HEADER_FOLDING}, \ FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'" SecRule TX:/^MSC_/ "!@streq 0" "id:'200004',phase:2,t:none,deny,status:500,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'" # === ModSecurity Rules (ids: 900000-999999) # === ModSec Core Rules Base Configuration (ids: 900001-900021) Include /home/dune73/data/git/crs-official/crs-setup.conf.example SecAction "id:900111,phase:1,nolog,pass,t:none,setvar:tx.inbound_anomaly_score_threshold=500,setvar:tx.outbound_anomaly_score_threshold=500" SecAction "id:'900000',phase:1,nolog,pass,t:none,setvar:tx.paranoia_level=4" # === ModSecurity Ignore Rules Before Core Rules Inclusion; order by id of ignored rule (ids: 10000-49999) # SecRule ARGS:a "." "id:1001,phase:2,pass,log,msg:'XXX1: %{MATCHED_VAR}'" # SecRule ARGS_GET:a "." "id:1002,phase:2,pass,log,msg:'XXX2: %{MATCHED_VAR}'" # SecRule ARGS_POST:a "." "id:1003,phase:2,pass,log,msg:'XXX3: %{MATCHED_VAR}'" # SecRule REQUEST_URI "." "id:1004,phase:2,pass,log,msg:'XXX4: %{MATCHED_VAR}'" # SecRule REQUEST_HEADERS:User-Agent "." "id:1005,phase:2,pass,log,msg:'XXX5: %{MATCHED_VAR}'" SecRule ARGS:b "." "id:1006,phase:2,pass,log,auditlog,msg:'XXX6: %{MATCHED_VAR}'" SecAction "nolog,phase:2,id:101,sanitiseArg:CVV" SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" # === ModSecurity Core Rules Inclusion Include /home/dune73/data/git/crs-official/rules/*.conf # === ModSec Core Rules: Startup Time Rules Exclusions # === ModSec timestamps at the end of each phase (ids: 90010 - 90019) SecAction "id:'90010',phase:1,pass,nolog,setvar:TX.ModSecTimestamp1end=%{DURATION}" SecAction "id:'90011',phase:2,pass,nolog,setvar:TX.ModSecTimestamp2end=%{DURATION}" SecAction "id:'90012',phase:3,pass,nolog,setvar:TX.ModSecTimestamp3end=%{DURATION}" SecAction "id:'90013',phase:4,pass,nolog,setvar:TX.ModSecTimestamp4end=%{DURATION}" SecAction "id:'90014',phase:5,pass,nolog,setvar:TX.ModSecTimestamp5end=%{DURATION}" # === ModSec performance calculations and variable export (ids: 90100 - 90199) SecAction "id:'90100',phase:5,pass,nolog,setvar:TX.perf_modsecinbound=%{PERF_PHASE1}" SecAction "id:'90101',phase:5,pass,nolog,setvar:TX.perf_modsecinbound=+%{PERF_PHASE2}" SecAction "id:'90102',phase:5,pass,nolog,setvar:TX.perf_application=%{TX.ModSecTimestamp3start}" SecAction "id:'90103',phase:5,pass,nolog,setvar:TX.perf_application=-%{TX.ModSecTimestamp2end}" SecAction "id:'90104',phase:5,pass,nolog,setvar:TX.perf_modsecoutbound=%{PERF_PHASE3}" SecAction "id:'90105',phase:5,pass,nolog,setvar:TX.perf_modsecoutbound=+%{PERF_PHASE4}" SecAction "id:'90106',phase:5,pass,nolog,setenv:ModSecTimeIn=%{TX.perf_modsecinbound}" SecAction "id:'90107',phase:5,pass,nolog,setenv:ApplicationTime=%{TX.perf_application}" SecAction "id:'90108',phase:5,pass,nolog,setenv:ModSecTimeOut=%{TX.perf_modsecoutbound}" SecAction "id:'90109',phase:5,pass,nolog,setenv:ModSecAnomalyScoreIn=%{TX.anomaly_score}" SecAction "id:'90110',phase:5,pass,nolog,setenv:ModSecAnomalyScoreOut=%{TX.outbound_anomaly_score}" # === End ModSec Configuration ------------------------------------------------------------------------------ So I think this generally works. If it does not for you, then please try and reproduce the behaviour on the latest ModSec version of the 2.9 series and open a bug report in case. Ahoj, Christian On Wed, Mar 14, 2018 at 06:13:04PM -0300, Cristiano Galdino wrote: > Hi Christian! > Modsecurity: 2.9.0-1 (from Ubuntu repository) > Apache 2.4.18-2ubuntu3.5 > Tks! > > Cristiano Galdino > cri...@ga... > > On 14 Mar 2018 17:55 -0300, Christian Folini > <chr...@ne...>, wrote: > > Hello Christiano, > What platform are you using? (-> ModSec version, Apache / NGINX / > IIS?) > Ahoj, > Christian > On Wed, Mar 14, 2018 at 05:06:28PM -0300, Cristiano Galdino wrote: > > Hello! > I created a rule in ModSecurity to sanitize param CVV (credit card) > but > it is not working. > Samples: > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV” > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" > This prevents me from using modsecurity because PCI does not allow > CVV > to be stored. > I found this issue without response. > [1]https://github.com/SpiderLabs/ModSecurity/issues/715 > What can I do? > Cristiano Galdino > cri...@ga... > References > 1. https://github.com/SpiderLabs/ModSecurity/issues/715 > > -------------------------------------------------------------------- > ---------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > 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/ > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > -------------------------------------------------------------------- > ---------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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/ > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Cristiano G. <cri...@ga...> - 2018-03-14 21:14:00
|
Hi Christian! Modsecurity: 2.9.0-1 (from Ubuntu repository) Apache 2.4.18-2ubuntu3.5 Tks! Cristiano Galdino cri...@ga... On 14 Mar 2018 17:55 -0300, Christian Folini <chr...@ne...>, wrote: > Hello Christiano, > > What platform are you using? (-> ModSec version, Apache / NGINX / IIS?) > > Ahoj, > > Christian > > On Wed, Mar 14, 2018 at 05:06:28PM -0300, Cristiano Galdino wrote: > > Hello! > > I created a rule in ModSecurity to sanitize param CVV (credit card) but > > it is not working. > > Samples: > > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV” > > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" > > This prevents me from using modsecurity because PCI does not allow CVV > > to be stored. > > I found this issue without response. > > [1]https://github.com/SpiderLabs/ModSecurity/issues/715 > > What can I do? > > > > Cristiano Galdino > > cri...@ga... > > > > References > > > > 1. https://github.com/SpiderLabs/ModSecurity/issues/715 > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > 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/ > > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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...> - 2018-03-14 20:55:48
|
Hello Christiano, What platform are you using? (-> ModSec version, Apache / NGINX / IIS?) Ahoj, Christian On Wed, Mar 14, 2018 at 05:06:28PM -0300, Cristiano Galdino wrote: > Hello! > I created a rule in ModSecurity to sanitize param CVV (credit card) but > it is not working. > Samples: > SecAction "nolog,phase:2,id:101,sanitiseArg:CVV” > SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" > This prevents me from using modsecurity because PCI does not allow CVV > to be stored. > I found this issue without response. > [1]https://github.com/SpiderLabs/ModSecurity/issues/715 > What can I do? > > Cristiano Galdino > cri...@ga... > > References > > 1. https://github.com/SpiderLabs/ModSecurity/issues/715 > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Cristiano G. <cri...@ga...> - 2018-03-14 20:11:37
|
Hello! I created a rule in ModSecurity to sanitize param CVV (credit card) but it is not working. Samples: SecAction "nolog,phase:2,id:101,sanitiseArg:CVV” SecAction "nolog,phase:4,id:102,sanitiseArg:CVV_Reponse" This prevents me from using modsecurity because PCI does not allow CVV to be stored. I found this issue without response. https://github.com/SpiderLabs/ModSecurity/issues/715 What can I do? Cristiano Galdino cri...@ga... |
|
From: Cristiano G. <cri...@ga...> - 2018-03-09 20:02:01
|
Hi! I have a 3.0 modsecurity in NGINX with the SecAuditLogType set to Concurrent and SecAuditLogParts set to ABIJDEFGHZ. The events are being recorded like this: > ---l4LQjRLv---A-- > [09/Mar/2018:18:00:01 +0000] 15206184011.536311 189.x.x.x 59421 189.x.x.x 8080 > ---l4LQjRLv---B-- > GET /?id=1%27%20or%20%271=1 HTTP/1.1 > Host: my_host.compute.amazonaws.com > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Firefox/58.0 > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3 > Accept-Encoding: gzip, deflate > Connection: keep-alive > Upgrade-Insecure-Requests: 1 > > ---l4LQjRLv---D-- > > ---l4LQjRLv---E-- > \xb3Qt\xf1w\x0e\x89\x0cpU\xc8(\xc9\xcd\xb1\xe3\xb2\x01Q\x0a9\x89y\xe9\xb6J\xa9yJ \x81\xd4\xc4\x14 \x95\x9bZ\x92\xa8\x90\x9c\x91XT\x9cZb\xabTZ\x92\xa6k\x01\x92-\xc9,\xc9I\xb5s-*\xca/\xb2\xd1\x87p\xb8l\xf4\xa1z\x92\xf2S*\x81TAQ\xaa\x9dsb^^~\x89\x82\xbbk\x88\x82\xbe\x8d>H\x04\xa8\x0c*\xaf\x0f\xb1\x1a\x00\xe6O#T\x8b\x00\x00\x00\x00\x00PX9\x02\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00@Q9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:msg\xb0\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00pX9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00hQ9\x02\x00\x00\x00\x008Q9\x02\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x81\x00\x00\x00\x00\x00\x00\x00\xb0K9\x02\x00\x00\x00\x00`S9\x02\x00\x00\x00\x00PM9\x02\x00\x00\x00\x00G\x01\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xf0S9\x02\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x002\x00verity\ x00ata: \x00\x00!\x00\x00\x00\x00\x00\x00\x00\x10\xed7\x02\x00\x00\x00\x000Y9\x02\x00\x00\x00\x00@\x06\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\xc0R9\x02\x00\x00\x00\x00(S9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\xb8R9\x02\x00\x00\x00\x00\xa0R9\x02\x00\x00\x00\x00pS9\x02\x00\x00\x00\x00pS9\x02\x00\x00\x00\x00\x91\x00\x00\x00\x00\x00\x00\x00P\x1e3\x02\x00\x00\x00\x00\x90Y9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00logdata\x00 E9\x02\x00\x00\x00\x001\x00\x00\x00\x00\x00\x00\x00`J9\x02\x00\x00\x00\x00\xb8\x17\x82\xb0\xf1\x7f\x00\x00\x00R9\x02\x00\x00\x00\x00\xdc\x02\x00\x00\x00\x00\x00\x00`\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xf0Y9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xb8R9\x02\x00\x00\x00\x00\xe8R9\x02\x00\x00\x00\x00\x10\x07\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00PY9\x02\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:logdata\x00 accept\x00\x00\x00\x00\x00d\x00\x00\x00\x00\x00\ x00`\x00\x00\x00\x00\x00\x00\x00`Z9\x02\x00\x00\x00\x008\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00Matched Data: accept found within : \x00\x00\x00\x00PT9\x02\x00\x00\x00\x001\x01\x00\x00\x00\x00\x00\x00`X9\x02\x00\x00\x00\x00\x01\x07\x00\x00\x00\x00\x00\x00 \xb07\x02\x00\x00\x00\x00\xd0a9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xd0S9\x02\x00\x00\x00\x000[9\x02\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00severity\x00T9\x02\x00\x00\x00\x00!\x00\x00\x00\x00\x00\x00\x00\x80>2\x02\x00\x00\x00\x000[9\x02\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00Y9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x18T9\x02\x00\x00\x00\x00HT9\x02\x00\x00\x00\x00\xc0\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\xc0[9\x02\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xff\xf f\xff\x00\x00\x00\x00RULE:severity\x00\x00\x00HS9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x91\x00\x00\x00\x00\x00\x00\x00\xb0K9\x02\x00\x00\x00\x00\xb8\x17\x82\xb0\xf1\x7f\x00\x008.c\xaf\xf1\x7f\x00\x00\x18T9\x02\x00\x00\x00\x00\x00T9\x02\x00\x00\x00\x00\xe0S9\x02\x00\x00\x00\x00\xe0S9\x02\x00\x00\x00\x00Q\x00\x00\x00\x00\x00\x00\x00\x10\xb97\x02\x00\x00\x00\x00\x00\9\x02\x00\x00\x00\x00pT9\x02\x00\x00\x00\x00{\x03\x00\x00\x00\x00\x00\x00\xd0>2\x02\x00\x00\x00\x00!\x00\x00\x00\x00\x00\x00\x00pV9\x02\x00\x00\x00\x00\xe0_9\x02\x00\x00\x00\x00\x90\x01\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\xa0U9\x02\x00\x00\x00\x00\xc8U9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\xc8X9\x02\x00\x00\x00\x00\xb0X9\x02\x00\x00\x00\x00`X9\x02\x00\x00\x00\x00`X9\x02\x00\x00\x00\x001\x00\x00\x00\x00\x00\x00\x00`F9\x02\x00\x00\x00\x00 u9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00id\x00260\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x10\x0e8\x02\x00\x00 \x00\x00\xf8\x87\x11\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\xe8W9\x02\x00\x00\x00\x00\xd0W9\x02\x00\x00\x00\x00\xc0V9\x02\x00\x00\x00\x00\xc0V9\x02\x00\x00\x00\x00\xb1\x03\x00\x00\x00\x00\x00\x00 \xfc7\x02\x00\x00\x00\x00\xc0Z9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00Sybase SQL Information Leakage\x00\x00q\x03\x00\x00\x00\x00\x00\x00\x00\xef8\x02\x00\x00\x00\x00@]9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00(W9\x02\x00\x00\x00\x00\x10W9\x02\x00\x00\x00\x00\x80V9\x02\x00\x00\x00\x00\x80V9\x02\x00\x00\x00\x001\x03\x00\x00\x00\x00\x00\x00\xe019\x02\x00\x00\x00\x00 h9\x02\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00`^9\x02\x00\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00951014\x00951014\x00\x00\x00!\x01\x00\x00\x00\x00\x00\x00pN9\x02\x00\x00\x00\x00\xd0]9\x02\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00`_9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\xd0T9\x02\x00\x00\x00\x00\x98U9\x02\x00\x00\x00\x00`\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x90N9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:id\x00\x90\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x000^9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00(W9\x02\x00\x00\x00\x00\xf8V9\x02\x00\x00\x00\x00ainst TXa\x00\x00\x00\x00\x00\x00\x00\xf0W9\x02\x00\x00\x00\x00\xe0d9\x02\x00\x00\x00\x00\xf0U9\x02\x00\x00\x00\x00\xcd\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xe0d9\x02\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00rev\x00\x00\x00\x00\x00p\x01\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xc0W9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:rev\xa0\x01\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00`d9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xe8 W9\x02\x00\x00\x00\x00\xb8W9\x02\x00\x00\x00\x00rmation a\x01\x00\x00\x00\x00\x00\x00\xf0\x0a8\x02\x00\x00\x00\x00\xe0d9\x02\x00\x00\x00\x00pU9\x02\x00\x00\x00\x00M\x01\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00Q\x00\x00\x00\x00\x00\x00\x00\xd0X9\x02\x00\x00\x00\x00\xa0e9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00msg\x00\x00\x00\x00\x00DATA-LEA!\x00\x00\x00\x00\x00\x00\x00\xe0\xb77\x02\x00\x00\x00\x00`_9\x02\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xa0X9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:msg\xb0\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00@e9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xc8X9\x02\x00\x00\x00\x00\x98X9\x02\x00\x00\x00\x00\x10W9\x02\x00\x00\x00\x00\x81\x00\x00\x00\x00\x00\x00\x00`S9\x02\x00\x00\x00\x00\xc0Z9\x02\x00\x00\x00\x00\x00U9\x02\x00\x00\x00\x00G\x01\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00P[ 9\x02\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x002\x00verity\x00ata: \x00\x00!\x00\x00\x00\x00\x00\x00\x00\x10\xed7\x02\x00\x00\x00\x00\x90d9\x02\x00\x00\x00\x00\xf0\x05\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00 Z9\x02\x00\x00\x00\x00\x88Z9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\x18Z9\x02\x00\x00\x00\x00\x00Z9\x02\x00\x00\x00\x00\xd0Z9\x02\x00\x00\x00\x00\xd0Z9\x02\x00\x00\x00\x00\x91\x00\x00\x00\x00\x00\x00\x00P\x1e3\x02\x00\x00\x00\x000l9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00logdata\x00\xff\xff\xff\xff\x00\x00\x00\x001\x00\x00\x00\x00\x00\x00\x000R9\x02\x00\x00\x00\x00\xb8\x17\x82\xb0\xf1\x7f\x00\x00`Y9\x02\x00\x00\x00\x00\xdc\x02\x00\x00\x00\x00\x00\x00`\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00`f9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x18Z9\x02\x00\x00\x00\x00HZ9\x02\x00\x00\x00\x00\xc0\x06\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00pb9\x02\x00\x00\x00\x00\x10\x00\x00\x00\x00\x0 0\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:logdata\x00 accept\x00\x00\x00\x00`k\x00\x00\x00\x00\x00\x00`\x00\x00\x00\x00\x00\x00\x00pc9\x02\x00\x00\x00\x008\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00Matched Data: accept found within : \x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00logdata\x00\xff\xff\xff\xff\x00\x00\x00\x00\xb1\x06\x00\x00\x00\x00\x00\x00\xd0a9\x02\x00\x00\x00\x00@t9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x000[9\x02\x00\x00\x00\x00\xc0f9\x02\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00Pg9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00severity\x00O9\x02\x00\x00\x00\x00!\x00\x00\x00\x00\x00\x00\x00\x80>2\x02\x00\x00\x00\x00\xc0f9\x02\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xd0e9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00x[9\x02\x00\x00\x00\x00\xa8[9\x02\x00\x00\x00\x00\xc0\x00\x00\x00\x00\x00\x00\x 00@\x00\x00\x00\x00\x00\x00\x00\x10g9\x02\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:severity\x00\x00\x00\x88Z9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\x91\x00\x00\x00\x00\x00\x00\x00`S9\x02\x00\x00\x00\x00\xb8\x17\x82\xb0\xf1\x7f\x00\x008.c\xaf\xf1\x7f\x00\x00x[9\x02\x00\x00\x00\x00`[9\x02\x00\x00\x00\x00@[9\x02\x00\x00\x00\x00@[9\x02\x00\x00\x00\x00Q\x00\x00\x00\x00\x00\x00\x00\x10\xb97\x02\x00\x00\x00\x00\x10\xbd:\x02\x00\x00\x00\x00\xd0[9\x02\x00\x00\x00\x00{\x03\x00\x00\x00\x00\x00\x00P\x00\x00\x00\x00\x00\x00\x00!\x00\x00\x00\x00\x00\x00\x00\x90d9\x02\x00\x00\x00\x00\x00m9\x02\x00\x00\x00\x00\x90\x01\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\x00n9\x02\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:severity\x00leaned.\x00\x00\x00\x88\9\x02\x00\x00\x00\x001\x00\x00\x00\x00\x00\x00\x000U9\x02\x00\x00\x00\x00 u9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00id\x00014\x00\x00\x00\x02\x00 \x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x000k9\x02\x00\x00\x00\x00\x18\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00Java Source Code Leakage\x00\9\x02\x00\x00\x00\x00\xa1\x02\x00\x00\x00\x00\x00\x00\xa0U9\x02\x00\x00\x00\x00\xb8\x17\x82\xb0\xf1\x7f\x00\x008.c\xaf\xf1\x7f\x00\x00\x98e9\x02\x00\x00\x00\x00\x80e9\x02\x00\x00\x00\x00p_9\x02\x00\x00\x00\x00p_9\x02\x00\x00\x00\x00a\x02\x00\x00\x00\x00\x00\x00\x00\xef8\x02\x00\x00\x00\x00\xb0b9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\x88^9\x02\x00\x00\x00\x00p^9\x02\x00\x00\x00\x00\xe0]9\x02\x00\x00\x00\x00\xe0]9\x02\x00\x00\x00\x00q\x01\x00\x00\x00\x00\x00\x00\x80\xee7\x02\x00\x00\x00\x00\xd0a9\x02\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xd0c9\x02\x00\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00952012\x00952012\x00_s!\x01\x00\x00\x00\x00\x00\x00 V9\x02\x00\x00\x00\x00\x00\xf77\x02\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00 \x10^9\x02\x00\x00\x00\x00(_9\x02\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00 b9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00`\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00@V9\x02\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00RULE:id\x00\x90\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\x00\xf77\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x88^9\x02\x00\x00\x00\x00X^9\x02\x00\x00\x00\x00ainst TXa\x00\x00\x00\x00\x00\x00\x00\x00d9\x02\x00\x00\x00\x00\xd0a9\x02\x00\x00\x00\x00P]9\x02\x00\x00\x00\x00\xcd\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x000\x00\x00\x00\x00\x00\x00\x00\xd0a9\x02\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00id\x00012\x000\xb0\x01\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\xe0b9\x02\x00\x00\x00\x00\xc8]9\x02\x00\x00\x00\x008.c\xaf\xf1\x7f\x00\x00\xf8c9\x02\x00\x00\x00\x00\xe0c9\x02\x00\x00\x00\x00\x00^9\x02\x00\ x00\x00\x00\x00^9\x02\x00\x00\x00\x00q\x00\x00\x00\x00\x00\x00\x00\xc0-7\x02\x00\x00\x00\x00`q9\x02\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00rev\x00\x00\x00\x00\x00ch\x00\x00\x00\x00\x00\x00A\x00\x00\x00\x00\x00\x00\x00\xe0\xb77\x02\x00\x00\x00\x00\xb0q9\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00!\x00\x00\x00\x00\x00\x00\x00 b9\x02\x00\x00\x00\x00\xb0h9\x02\x00\x00\x00\x00\xe0\x04\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00\x00\xf0k9\x02\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xf1\x7f\x00\x00RULE:logdata\x00 accept\x00\x00\x00\x00`a9\x02\x00\x00\x00\x00\x91\x01\x00\x00\x00\x00\x00\x00\x10\xa92\x02\x00\x00\x00\x00`\xbb5\x02\x00\x00\x00\x00\xff\xff\xff\xff\xf1\x7f\x00\x00/var/log/mlog2waffle/data/20180309/20180309-1417/20180309-141734-152060505454.421689\x00INBOUND_ANOMALY_SCORE' (Value: `8' )\x00asscan)\x00\x82\xb0\xf1\x7f\x00\x00 > > ---l4LQjRLv---F-- > HTTP/1.1 404 > Server: nginx/1.12.1 > Date: Fri, 09 Mar 2018 18:00:01 GMT > Content-Type: text/html; charset=utf-8 > X-Content-Type-Options: nosniff > Connection: keep-alive > Content-Security-Policy: default-src 'self' > Content-Encoding: gzip > > ---l4LQjRLv---G-- > > ---l4LQjRLv---H-- > ModSecurity: Warning. detected SQLi using libinjection. [file "/opt/crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "17"] [id "942100"] [rev "1"] [msg "SQL Injection Attack Detected via libinjection"] [data "Matched Data: upgrade-insecure-requests found within ARGS:id: 1' or '1=1"] [severity "2"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] [hostname "189.59.73.186"] [uri "/"] [unique_id "15206184011.536311"] [ref "v9,10t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:removeComments"] > ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/opt/crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "36"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "189.59.73.186"] [uri "/"] [unique_id "15206184011.536311"] [ref ""] > ModSecurity: Warning. Matched "Operator `Ge' with parameter `5' against variable `TX:INBOUND_ANOMALY_SCORE' (Value: `5' ) [file "/opt/crs/rules/RESPONSE-980-CORRELATION.conf"] [line "61"] [id "980130"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): SQL Injection Attack Detected via libinjection'"] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [tag "event-correlation"] [hostname "189.59.73.186"] [uri "/"] [unique_id "15206184011.536311"] [ref ""] > > ---l4LQjRLv---I-- > > ---l4LQjRLv---J-- > > ---l4LQjRLv---Z-- Why is my stage E broken? Cristiano Galdino (61) 9860 1 9860 cri...@ga... |
|
From: Felipe C. <FC...@tr...> - 2018-03-07 20:23:30
|
Hi Cristiano, The semantic of both files are the same. My suggestion ls to double check the regex that try to match the index content. Br., Felipe “Zimmerle” Costa Security Researcher, Lead Developer ModSecurity. Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> From: Cristiano Galdino <cri...@ga...> Reply-To: "mod...@li..." <mod...@li...> Date: Wednesday, March 7, 2018 at 11:40 AM To: "mod...@li..." <mod...@li...> Subject: [mod-security-users] SecAuditLog format different 2.9.x and 3.0 Hi! I am using modsecurity 2.9 in apache and modsecurity 3.0 in nginx, both are in the same configuration but the log is in a different format. My modsecurity.conf: SecAuditLogParts ABIJDEFGHZ SecAuditLogType Concurrent SecAuditLog /var/log/mlog2waffle/mlog2waffle-index SecAuditLogStorageDir /var/log/mlog2waffle/data Events in mlog2waffle-index in modsecurity 2.9 (apache): http://localhost 10.10.10.10 - - [05/Mar/2018:12:33:22 --0300] "POST / HTTP/1.1" 404 926 "-" "-" Wp1jQX8AAQEAAGReP8MAAAAH "-" /20180305/20180305-1233/20180305-123322-Wp1jQX8AAQEAAGReP8MAAAAH 0 2770 md5:608e97823d44086abc1719a930fb90bb Events in mlog2waffle-index in modsecurity 3.0 (nginx): 127.0.0.1 10.10.10.10 - "GET / HTTP/1.1" 404 0 - "Java/1.8.0_161" 152026763220.574250 - /var/log/mlog2waffle/data/20180305/20180305-1633/20180305-163352-152026763220.574250 0 1303.000000 md5:1a354780659b4213afc79e5185c507a7 So I can not use mlog2waffle because the format log index in 3.0 is not supported. How can I make modsecurity 3.0 generate the logs in the 2.9.x format? Regards, Cristiano Galdino cri...@ga... |
|
From: Reindl H. <h.r...@th...> - 2018-03-07 19:15:05
|
Am 07.03.2018 um 19:32 schrieb Matt Holdsworth: > Hi! > > I’m having trouble with false positives in my new nginx+libModSecurity setup, in front of a Ghost blog and running OWASP CRS v3 ruleset. > > I have the brotli module installed as well as the ModSecurity-nginx connector, and sometimes it seems that libModSecurity gets/analyses brotli-encoded responses. > > When this happens, I sometimes see false positives in the audit log, e.g. caused by “<?” characters turning up and being detected as PHP code leakage. Or “<%” being detected as another form of code leakage, etc. you have similar issues with every random file because "<?" also exists in image-files and so on - i gave up check file-uploads for PHP code because of that > It seems pointless to perform such analysis on compressed responses (at least, without uncompressing them first), so is there a way I can turn off response body analysis in just these cases? Perhaps I could set a condition of a response header for “Content-Encoding: br” or “Content-Encoding: gzip” being present, as the trigger for the rule? it seems to be pointless check repsonse bodies at all when you skip a large amount of them anyways > I went to try to create such a rule using the “ctl:responseBodyAccess=Off” action, but the docs say that this action is still TBI (to be implemented) for libModSecurity… > > Please note: these compressed responses are from the same nginx instance as libModSecurity is installed on, so it’s unfortunately not as easy as “configure your origin server not to compress, and set up your nginx reverse proxy (where libModSecurity is running) to compress instead”. I know for certain that the origin server (Ghost/node.js, in this case) is *not* doing the compression the put mod_security on the backendserver where it deals with uncompressed responses and leave the reverse proxy alone with compression and content serving |
|
From: Matt H. <ma...@ma...> - 2018-03-07 18:32:54
|
Hi! I’m having trouble with false positives in my new nginx+libModSecurity setup, in front of a Ghost blog and running OWASP CRS v3 ruleset. I have the brotli module installed as well as the ModSecurity-nginx connector, and sometimes it seems that libModSecurity gets/analyses brotli-encoded responses. When this happens, I sometimes see false positives in the audit log, e.g. caused by “<?” characters turning up and being detected as PHP code leakage. Or “<%” being detected as another form of code leakage, etc. It seems pointless to perform such analysis on compressed responses (at least, without uncompressing them first), so is there a way I can turn off response body analysis in just these cases? Perhaps I could set a condition of a response header for “Content-Encoding: br” or “Content-Encoding: gzip” being present, as the trigger for the rule? I went to try to create such a rule using the “ctl:responseBodyAccess=Off” action, but the docs say that this action is still TBI (to be implemented) for libModSecurity… Please note: these compressed responses are from the same nginx instance as libModSecurity is installed on, so it’s unfortunately not as easy as “configure your origin server not to compress, and set up your nginx reverse proxy (where libModSecurity is running) to compress instead”. I know for certain that the origin server (Ghost/node.js, in this case) is *not* doing the compression. Any help would be much appreciated! Cheers, Matt |
|
From: Cristiano G. <cri...@ga...> - 2018-03-07 14:38:54
|
Hi! I am using modsecurity 2.9 in apache and modsecurity 3.0 in nginx, both are in the same configuration but the log is in a different format. My modsecurity.conf: > SecAuditLogParts ABIJDEFGHZ > SecAuditLogType Concurrent > SecAuditLog /var/log/mlog2waffle/mlog2waffle-index > SecAuditLogStorageDir /var/log/mlog2waffle/data Events in mlog2waffle-index in modsecurity 2.9 (apache): > http://localhost 10.10.10.10 - - [05/Mar/2018:12:33:22 --0300] "POST / HTTP/1.1" 404 926 "-" "-" Wp1jQX8AAQEAAGReP8MAAAAH "-" /20180305/20180305-1233/20180305-123322-Wp1jQX8AAQEAAGReP8MAAAAH 0 2770 md5:608e97823d44086abc1719a930fb90bb Events in mlog2waffle-index in modsecurity 3.0 (nginx): > 127.0.0.1 10.10.10.10 - "GET / HTTP/1.1" 404 0 - "Java/1.8.0_161" 152026763220.574250 - /var/log/mlog2waffle/data/20180305/20180305-1633/20180305-163352-152026763220.574250 0 1303.000000 md5:1a354780659b4213afc79e5185c507a7 So I can not use mlog2waffle because the format log index in 3.0 is not supported. How can I make modsecurity 3.0 generate the logs in the 2.9.x format? Regards, Cristiano Galdino cri...@ga... |
|
From: Franziska B. <fra...@gm...> - 2018-03-06 17:22:48
|
Hi, Just a note about the linked blog post: https://www.oreilly.com/ideas/how-to-tune-your-waf-installation-to-reduce-false-positives It was Christian Folini who has written this blog post about how to reduce false positives. Chaim linked it on https://coreruleset.org. Best regards, Franziska |
|
From: Deanna S. <dst...@gm...> - 2018-03-04 04:14:15
|
Hi Kirk, I am running CRS/3.0.0, which I believe is the version that reduced large number of false positives, and modsec ver is 2.9. The rule is getting lot of hits and the traffic is malicious 99.9% of the time, so I'd rather not disable the rule. That article is great and have actually gone through it before, but don't think it addresses the problem/questions I am talking about. Thanks for your input. On Thu, Mar 1, 2018 at 5:46 PM, Kirk Jackson <ki...@pa...> wrote: > Hi Deanna, > > First thing I'd check is whether you're running the latest Core Rule Set - > that has been tuned to have less false positives (see > https://coreruleset.org/) > > Then if you decide that this particular rule is more trouble than it's > worth, I'd disable the rule by ID using SecRuleRemoveById. > > Chaim has a good article on tuning linked from the Core Rule Set blog: > https://www.oreilly.com/ideas/how-to-tune-your-waf- > installation-to-reduce-false-positives > > Even if you remove that rule, you've still got the libinjection rules that > will help detect "real" SQLi (again: assuming you're on a modern > modsecurity). > > Kirk > > On Fri, Mar 2, 2018 at 1:15 PM, Deanna Stevenson <dst...@gm...> > wrote: > >> Hello All, >> >> I have a problem where SQL injection rules like "Detects concatenated >> basic SQL injection and SQLLFI" attempts are firing, when the strings in >> the input fields are similar to SQL commands. Here is an example. >> >> 8d85025e-H-- Message: Warning. Pattern match >> "(?i:(?:[\\d\\W]\\s+as\\s*?[\"'`\\w]+\\s*?from)|(?:^[\\W\\d] >> +\\s*?(?:union|select|create|rename|truncate|load|alter|dele >> te|update|insert|desc)\\b)|(?:(?:select|create|rename|trunca >> te|load|alter|delete|update|insert|desc)\\s+(?:(?:group_)concat|char|load >> ..." at ARGS:address1. [file "/etc/modsec/sitebuyprod/rules >> /REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "451"] [id "942360"] >> [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI >> attempts"] *[data "Matched Data: 1922 ALTER found within ARGS:address1: >> 1922 ALTER St PHILADELPHIA, PA 19146"*] [severity "CRITICAL"] [ver >> "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "application-multi"] >> [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag >> "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag >> "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] >> >> How do I whitelist this behavior in a way, where >> 1. I am not whitelisting actual SQL injection commands. Like in above >> case, I can whitelist not to fire on string "alter" for args adress1, but >> doesn't that eliminate detection/blocking of any alter based SQL injection? >> 2. Is there a way to whitelist such false positives globally for all >> fields. The string could be present in address 2 next time or comments >> etc., and there are multiple sites. Do I have to collect all possible >> fields for all sites, or can I whitelist this false positive globally in >> some way? >> >> Appreciate your help! >> >> Sincerely, >> Deanna >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> 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/ >> >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: Kirk J. <ki...@pa...> - 2018-03-02 00:46:47
|
Hi Deanna, First thing I'd check is whether you're running the latest Core Rule Set - that has been tuned to have less false positives (see https://coreruleset.org/) Then if you decide that this particular rule is more trouble than it's worth, I'd disable the rule by ID using SecRuleRemoveById. Chaim has a good article on tuning linked from the Core Rule Set blog: https://www.oreilly.com/ideas/how-to-tune-your-waf-installation-to-reduce-false-positives Even if you remove that rule, you've still got the libinjection rules that will help detect "real" SQLi (again: assuming you're on a modern modsecurity). Kirk On Fri, Mar 2, 2018 at 1:15 PM, Deanna Stevenson <dst...@gm...> wrote: > Hello All, > > I have a problem where SQL injection rules like "Detects concatenated > basic SQL injection and SQLLFI" attempts are firing, when the strings in > the input fields are similar to SQL commands. Here is an example. > > 8d85025e-H-- Message: Warning. Pattern match > "(?i:(?:[\\d\\W]\\s+as\\s*?[\"'`\\w]+\\s*?from)|(?:^[\\W\\d] > +\\s*?(?:union|select|create|rename|truncate|load|alter| > delete|update|insert|desc)\\b)|(?:(?:select|create|rename| > truncate|load|alter|delete|update|insert|desc)\\s+(?:(?:group_)concat|char|load > ..." at ARGS:address1. [file "/etc/modsec/sitebuyprod/ > rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "451"] [id > "942360"] [rev "2"] [msg "Detects concatenated basic SQL injection and > SQLLFI attempts"] *[data "Matched Data: 1922 ALTER found within > ARGS:address1: 1922 ALTER St PHILADELPHIA, PA 19146"*] [severity > "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag > "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag > "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag > "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag > "PCI/6.5.2"] > > How do I whitelist this behavior in a way, where > 1. I am not whitelisting actual SQL injection commands. Like in above > case, I can whitelist not to fire on string "alter" for args adress1, but > doesn't that eliminate detection/blocking of any alter based SQL injection? > 2. Is there a way to whitelist such false positives globally for all > fields. The string could be present in address 2 next time or comments > etc., and there are multiple sites. Do I have to collect all possible > fields for all sites, or can I whitelist this false positive globally in > some way? > > Appreciate your help! > > Sincerely, > Deanna > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: Deanna S. <dst...@gm...> - 2018-03-02 00:17:59
|
Hello All, I have a problem where SQL injection rules like "Detects concatenated basic SQL injection and SQLLFI" attempts are firing, when the strings in the input fields are similar to SQL commands. Here is an example. 8d85025e-H-- Message: Warning. Pattern match "(?i:(?:[\\d\\W]\\s+as\\s*?[\"'`\\w]+\\s*?from)|(?:^[\\W\\d]+\\s*?(?:union|select|create|rename|truncate|load|alter|delete|update|insert|desc)\\b)|(?:(?:select|create|rename|truncate|load|alter|delete|update|insert|desc)\\s+(?:(?:group_)concat|char|load ..." at ARGS:address1. [file "/etc/modsec/sitebuyprod/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [line "451"] [id "942360"] [rev "2"] [msg "Detects concatenated basic SQL injection and SQLLFI attempts"] *[data "Matched Data: 1922 ALTER found within ARGS:address1: 1922 ALTER St PHILADELPHIA, PA 19146"*] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] How do I whitelist this behavior in a way, where 1. I am not whitelisting actual SQL injection commands. Like in above case, I can whitelist not to fire on string "alter" for args adress1, but doesn't that eliminate detection/blocking of any alter based SQL injection? 2. Is there a way to whitelist such false positives globally for all fields. The string could be present in address 2 next time or comments etc., and there are multiple sites. Do I have to collect all possible fields for all sites, or can I whitelist this false positive globally in some way? Appreciate your help! Sincerely, Deanna |
|
From: Christian V. <cv...@it...> - 2018-02-28 17:54:16
|
Hello, I'm using nginx 1.9.x with modsecurity refactoring version but having troubles with the modsecurity audit log, where should be the origin IP I'm getting my hostname (waf). There anybody know how to get the source IP for the blocked request ? Audit Log: [27/Feb/2018:16:26:45 --0300] [waf/sid#7f34b85370a0][rid#7f34b01fb0a0][/botellas.php][1] Access denied with code 403 (phase 2). Pattern match "(^[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+|[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98;]+$)" at ARGS:id. [file "/opt/waf/nginx/etc/modsec_rules/www.vinicas.cl/enabled_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "64"] [id "981318"] [rev "2"] [msg "SQL Injection Attack: Common Injection Testing Detected"] [data "Matched Data: '' found within ARGS:id: ''"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] Cheers! -- -- Chris |
|
From: <jm+...@ro...> - 2018-02-27 17:31:40
|
Hi, On 2/27/2018 5:43 AM, Christian Folini wrote: > On Mon, Feb 26, 2018 at 11:14:11PM +0100, jm+...@ro... wrote: >> How would I modify tx:allowed_methods without actually touching the system >> file /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf as >> it might be replaced during an upgrade? > SLES 11 seems to leave you with a CRS 2.2.x setup. I suggest you move to > CRS3 where this question is answered / solved in the crs-setup.conf file. > > My tutorial 7 at https://www.netnea.com/cms/apache-tutorials/ also brings > an example in this regard. > Well, crs v3 would require modsec > 2.8.0 and even SLES12-SP3 comes with modsec 2.7 only. What you probably mean is that the setup file included with crs v3 states: # The order of file inclusion in your webserver configuration should always be: # 1. modsecurity.conf # 2. crs-setup.conf (this file) # 3. rules/*.conf (the CRS rule files) I have now done something similar with "/etc/apache2/conf.d/mod_security2.conf" in SLES12. By default, that file says at the bottom: Include /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf # as set up with symlinks for files that are placed here: Include /etc/apache2/mod_security2.d/*.conf I have added a statement in-between, which seems to also do the trick Include /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf SecAction \ "id:'999989', \ phase:1, \ t:none, \ setvar:'tx.allowed_request_content_type=%{tx.allowed_request_content_type}|text/calendar', \ nolog, \ pass" Include /etc/apache2/mod_security2.d/*.conf For some reason using SecRuleRemoveById on the actual rule 900012 that I wanted to override did not work. When I put up a new rule 900012 after removing the old one I still got the error that the ID would already exist... So that is why I did the above. marki |
|
From: Christian F. <chr...@ne...> - 2018-02-27 04:43:27
|
Hello, On Mon, Feb 26, 2018 at 11:14:11PM +0100, jm+...@ro... wrote: > Quick question on customization : > > How would I modify tx:allowed_methods without actually touching the system > file /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf as > it might be replaced during an upgrade? SLES 11 seems to leave you with a CRS 2.2.x setup. I suggest you move to CRS3 where this question is answered / solved in the crs-setup.conf file. My tutorial 7 at https://www.netnea.com/cms/apache-tutorials/ also brings an example in this regard. Good luck! Christian -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Christian F. <chr...@ne...> - 2018-02-27 04:40:19
|
Hey Marki, On Mon, Feb 26, 2018 at 11:09:38PM +0100, jm+...@ro... wrote: > Can anyone elaborate on that? > > If you specify say > > 1) SecRule some_variable some_operator "some_action,phase:1,id:4" > 2) SecRule some_variable some_operator "some_action,phase:2,id:5" > 3) SecRule some_variable some_operator "some_action,phase:1,id:5" > 4) SecRule some_variable some_operator "some_action,phase:2,id:4" You have a rule id collision here. > The order of execution is pretty clear, is it not? 1 -> 3 -> 4 -> 2 No, if you remove the id collision to make it syntactically correct you get 1 -> 3 -> 2 -> 4 It's the order of the phases and then top down. The rule id is irrelevant. If you spread rules over Server context, virtual host and containers, then inheritance starts to play a role and I suggest you try things out to be really sure about the order. Ahoj, Christian -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: <jm+...@ro...> - 2018-02-26 22:14:23
|
Hi, Quick question on customization : How would I modify tx:allowed_methods without actually touching the system file /usr/share/apache2-mod_security2/rules/modsecurity_crs_10_setup.conf as it might be replaced during an upgrade? Just remove and replace the rule later in the configuration, i.e. in /etc/something ? How is this usually, correctly and officially done? (SLES 11 here) Thanks, marki |
|
From: <jm+...@ro...> - 2018-02-26 22:09:52
|
Hey Concerning https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Processing_Phases "The order of rules in the configuration file is important only within the rules of each phase." Can anyone elaborate on that? If you specify say 1) SecRule some_variable some_operator "some_action,phase:1,id:4" 2) SecRule some_variable some_operator "some_action,phase:2,id:5" 3) SecRule some_variable some_operator "some_action,phase:1,id:5" 4) SecRule some_variable some_operator "some_action,phase:2,id:4" The order of execution is pretty clear, is it not? 1 -> 3 -> 4 -> 2 How would the order of statements in the configuration file play a role? Thanks. Marki |
|
From: Robert P. <rpa...@fe...> - 2018-02-23 17:30:52
|
There's also the fact that logs can be written as JSON (both for v2 and v3), so you can easily ship audit log data to the next part of your stack without a need for a custom parser. Sent from my iPhone > On Feb 23, 2018, at 08:18, Christian Folini <chr...@ne...> wrote: > > Hey Darvin, > > Could you be a bit more specific? > > Which LogFiles are you interested in? Audit Logs? > > I have not tried out AuditConsole with v3, but the log formats did not > really change a lot. > > Christian > > > >> On Thu, Feb 22, 2018 at 05:31:50PM -0500, Darvin Rivera Aguilar wrote: >> There is any tool to parse modsecurity 3? Something like AuditConsole. >> Thanks >> ----------------------------------------------------------------- >> ---- Universidad de Camagüey "Ignacio Agramonte Loynaz", Cuba --- >> ----------------------------------------------------------------- >> ---- https://intranet.reduc.edu.cu/ ----------------------------- >> ---- https://www.reduc.edu.cu/ ---------------------------------- >> ----------------------------------------------------------------- >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> 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/ > > -- > https://www.feistyduck.com/training/modsecurity-training-course > https://www.feistyduck.com/books/modsecurity-handbook/ > mailto:chr...@ne... > twitter: @ChrFolini > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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...> - 2018-02-23 16:18:36
|
Hey Darvin, Could you be a bit more specific? Which LogFiles are you interested in? Audit Logs? I have not tried out AuditConsole with v3, but the log formats did not really change a lot. Christian On Thu, Feb 22, 2018 at 05:31:50PM -0500, Darvin Rivera Aguilar wrote: > There is any tool to parse modsecurity 3? Something like AuditConsole. > Thanks > ----------------------------------------------------------------- > ---- Universidad de Camagüey "Ignacio Agramonte Loynaz", Cuba --- > ----------------------------------------------------------------- > ---- https://intranet.reduc.edu.cu/ ----------------------------- > ---- https://www.reduc.edu.cu/ ---------------------------------- > ----------------------------------------------------------------- > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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/ -- https://www.feistyduck.com/training/modsecurity-training-course https://www.feistyduck.com/books/modsecurity-handbook/ mailto:chr...@ne... twitter: @ChrFolini |
|
From: Darvin R. A. <da...@re...> - 2018-02-22 22:29:44
|
There is any tool to parse modsecurity 3? Something like AuditConsole. Thanks ----------------------------------------------------------------- ---- Universidad de Camagüey "Ignacio Agramonte Loynaz", Cuba --- ----------------------------------------------------------------- ---- https://intranet.reduc.edu.cu/ ----------------------------- ---- https://www.reduc.edu.cu/ ---------------------------------- ----------------------------------------------------------------- |
|
From: Felipe C. <FC...@tr...> - 2018-02-19 21:02:33
|
Hi Andrew, We don’t have an ETA on it. Br., Felipe “Zimmerle” Costa Security Researcher, Lead Developer ModSecurity. Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> From: Andrew Joshwa <4an...@gm...> Reply-To: "mod...@li..." <mod...@li...> Date: Monday, January 29, 2018 at 11:40 AM To: "mod...@li..." <mod...@li...> Subject: [mod-security-users] ModSecurity-apache connector in ModSecurity-3.0 Hello, What will be the release schedule for Stable version of ModSecurity-apache connector ? Thanks in Advance Regards, Andrew Joshwa |
139 messages has been excluded from this view by a project administrator.
