mod-security-users Mailing List for ModSecurity (Page 39)
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: Christian F. <chr...@ne...> - 2018-11-01 09:48:57
|
Hello Adrian, You are facing a complicated problem on a very old system. Ubuntu 14.04 is still supported by Ubuntu of course, but I have not touched Apache 2.4.7 and ModSec 2.7.7 for years. Please try and reproduce the error on a newer system with ModSec 2.9.2 and a recent Apache > 2.4.30. If it persists, somebody may want to take a closer look. This way it's likely to take a large amount of time - and time is scarce, so your question is mostly ignored. Ahoj, Christian On Mon, Oct 29, 2018 at 02:01:55PM -0400, Adrian Daminato wrote: > I'm running a stock Ubuntu 14.04 setup with Apache 2.4.7 and ModSecurity > 2.7.7, on a PHP based API that uses rewrites. With my searches of the > mailing list archives and git issues, I believe I'm having problem similar > to the ones described in > https://github.com/SpiderLabs/ModSecurity/issues/1658 > > I'm fairly certain the rewrite is causing this, however other searches have > led me in circles, or dead-ends, suggesting this problem was resolved (e.g. > https://github.com/SpiderLabs/ModSecurity/issues/185) > > Even if I'm doing no rules, and having SecAuditEngine set to On, I get > responses on every request that comes through, except for calls that go via > /api/ and the rewrite rules, so I'm fairly certain this isn't from a > ModSecurity misconfiguration that I've done. > > My ModSecurity configuration is as follows: > > SecRuleEngine On > SecAuditEngine RelevantOnly > SecAuditLogType Concurrent > SecAuditLogDirMode 755 > SecAuditLogFileMode 644 > SecAuditLog /var/log/apache2/post_audit.log > SecAuditLogStorageDir /var/log/apache2/modsecurity > SecRequestBodyAccess on > SecResponseBodyAccess On > SecAuditLogParts ABIEFGHZ > > SecResponseBodyMimeType text/plain text/html text/xml application/json > application/x-httpd-php > SecRequestBodyLimitAction ProcessPartial > SecResponseBodyLimitAction ProcessPartial > > SecDefaultAction "nolog,noauditlog,allow,phase:2" > > SecRule REQUEST_METHOD "POST" "id:1234,allow,phase:2,chain" > SecRule ARGS:object recording "ctl:auditEngine=On,nolog" > > With debug logging enabled, I can see that requests to the API are hit, and > the rewrite followed but the response is never hit > > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Initialising transaction (txid W9cU9n8AAQEAAB30p0sAAAAB). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Transaction context created (dcfg 7f5560154be8). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Starting phase REQUEST_HEADERS. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] This > phase consists of 0 rule(s). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Second phase starting (dcfg 7f5560154be8). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Input filter: Reading request body. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] > Input filter: Bucket type TRANSIENT contains 53 bytes. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] > Input filter: Bucket type EOS contains 0 bytes. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] > Adding request argument (BODY): name "object", value "recording" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] > Adding request argument (BODY): name "id", value "20181026131815011691" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] > Adding request argument (BODY): name "action", value "read" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Input filter: Completed receiving request body (length 53). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Starting phase REQUEST_BODY. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] This > phase consists of 2 rule(s). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Recipe: Invoking rule 7f55600d9148; [file > "/etc/modsecurity/post_audit.conf"] [line "16"] [id "1234"]. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Rule > 7f55600d9148: SecRule "REQUEST_METHOD" "@rx POST" > "nolog,noauditlog,phase:2,id:1234,allow:phase,chain" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Transformation completed in 1 usec. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Executing operator "rx" with param "POST" against REQUEST_METHOD. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] > Target value: "POST" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Operator completed in 3 usec. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Rule > returned 1. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] > Match -> mode NEXT_RULE. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Recipe: Invoking rule 7f55600d9b58; [file > "/etc/modsecurity/post_audit.conf"] [line "17"]. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Rule > 7f55600d9b58: SecRule "ARGS:object" "@rx recording" "ctl:auditEngine=On" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Transformation completed in 0 usec. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Executing operator "rx" with param "recording" against ARGS:object. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] > Target value: "recording" > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Operator completed in 1 usec. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Ctl: > Set auditEngine to 1. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Rule > returned 1. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] > Match, intercepted -> returning. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Access to phase allowed (phase 2). Pattern match "recording" at > ARGS:object. [file "/etc/modsecurity/post_audit.conf"] [line "16"] [id > "1234"] > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Hook > insert_filter: Adding input forwarding filter (r 7f5546c1a0a0). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Hook > insert_filter: Adding output filter (r 7f5546c1a0a0). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c0ebf8][/api/webroot/recordings][4] > Hook insert_filter: Adding input forwarding filter for subrequest (r > 7f5546c0ebf8). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Hook insert_filter: Adding input forwarding filter for subrequest (r > 7f5546c02220). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Input filter: Forwarding input: mode=0, block=0, nbytes=16384 (f > 7f5546c00b48, r 7f5546c02220). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Input filter: Forwarded 53 bytes. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Input filter: Sent EOS. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Input filter: Input forwarding complete. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c0ebf8][/api/webroot/recordings][4] > Input filter: Input forwarding already complete, skipping (f 7f5546c020c8, > r 7f5546c0ebf8). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Input filter: Input forwarding already complete, skipping (f 7f5546c0ea68, > r 7f5546c1a0a0). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] > Initialising logging. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Starting phase LOGGING. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][9] > This phase consists of 0 rule(s). > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Recording persistent data took 0 microseconds. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] > Audit log: Logging this transaction. > [29/Oct/2018:10:11:02 --0400] > [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][9] > Audit Log: Writing 272 bytes to primary concurrent index > > For another endpoint, that's not hitting a rewrite, it processes as expected > > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Initialising > transaction (txid W9cU9n8AAQEAAB31DioAAAAC). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][5] Adding request > argument (QUERY_STRING): name "status", value "" > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Transaction > context created (dcfg 7f5560154be8). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase > REQUEST_HEADERS. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase > consists of 0 rule(s). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Second phase > starting (dcfg 7f5560154be8). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Input filter: > This request does not have a body. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase > REQUEST_BODY. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase > consists of 2 rule(s). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Recipe: > Invoking rule 7f55600d9148; [file "/etc/modsecurity/post_audit.conf"] [line > "16"] [id "1234"]. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][5] Rule > 7f55600d9148: SecRule "REQUEST_METHOD" "@rx POST" > "nolog,noauditlog,phase:2,id:1234,allow:phase,chain" > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Transformation > completed in 1 usec. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Executing > operator "rx" with param "POST" against REQUEST_METHOD. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Target value: > "GET" > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Operator > completed in 3 usec. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Rule returned 0. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] No match, > chained -> mode NEXT_CHAIN. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Hook > insert_filter: Adding output filter (r 7f5546c1a0a0). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Hook > insert_error_filter: Adding output filter (r 7f5546c1a0a0). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Output filter: > Receiving output (f 7f5546c16140, r 7f5546c1a0a0). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase > RESPONSE_HEADERS. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase > consists of 0 rule(s). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Content > Injection: Not enabled. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Output filter: > Bucket type HEAP contains 374 bytes. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Output filter: > Bucket type EOS contains 0 bytes. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Output filter: > Completed receiving response body (buffered full - 374 bytes). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase > RESPONSE_BODY. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase > consists of 0 rule(s). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Output filter: > Output forwarding complete. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Initialising > logging. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase > LOGGING. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase > consists of 0 rule(s). > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Recording > persistent data took 0 microseconds. > [29/Oct/2018:10:11:02 --0400] > [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Audit log: > Ignoring a non-relevant request. > > The audit log file generated by the API call: > > --a479b55a-B-- > POST /api/ HTTP/1.1 > Authorization: Basic YnVzOmJ1cw== > Host: apihost.local > Accept: */* > Connection: keep-alive > Content-Type: application/x-www-form-urlencoded > Content-Length: 53 > > --a479b55a-C-- > object=recording&id=20181026131815011691&action=read > --a479b55a-F-- > HTTP/1.1 200 OK > Cache-Control: no-store > Pragma: no-cache > Vary: Accept-Encoding > Content-Length: 650 > Keep-Alive: timeout=5, max=100 > Connection: Keep-Alive > Content-Type: text/xml; charset="utf-8" > > --a479b55a-H-- > Apache-Handler: application/x-httpd-php > Stopwatch: 1540822262272919 70600 (- - -) > Stopwatch2: 1540822262272919 70600; combined=112, p1=4, p2=83, p3=0, p4=0, > p5=24, sr=0, sw=1, l=0, gc=0 > Producer: ModSecurity for Apache/2.7.7 (http://www.modsecurity.org/). > Server: Apache/2.4.7 (Ubuntu) > Engine-Mode: "ENABLED" > > --a479b55a-Z-- > > And the rewrite rule setup is from an .htaccess in the directory root for > /api/ > > <IfModule mod_rewrite.c> > RewriteEngine on > RewriteRule ^$ webroot/ [L] > RewriteRule (.*) webroot/$1 [L] > </IfModule> > > Is the rewrite handling still a known issue in 2.7.7, or am I missing a > simple configuration option to get this working? > > -- > Adrian Daminato > Manager, Core Services, Versature > 1-877-498-3772 x111 > ada...@ve... > > *The Latest News from Versature:* > Versature to Scale Operations Through Acquisition by net2phone > <https://www.versature.com/conversation-blog/net2phone-acquires-versature/> > Versature Named to Growth 500 Ranking > <https://www.versature.com/conversation-blog/versature-growth500-2018/> > Best Questions to Start Your Data Analysis > <https://www.versature.com/conversation-blog/best-questions-to-start-your-call-data-analysis/> > > [image: Website] > <https://www.versature.com?utm_source=Signature&utm_medium=Email&utm_campaign=Outreach> > [image: > LinkedIn] <https://www.linkedin.com/company/Versature> [image: Twitter] > <https://www.twitter.com/Versature> [image: Facebook] > <https://www.facebook.com/Versature> [image: Instagram] > <https://www.instagram.com/versature_hpbx> > _______________________________________________ > 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: Adrian D. <ada...@ve...> - 2018-10-29 18:25:25
|
I'm running a stock Ubuntu 14.04 setup with Apache 2.4.7 and ModSecurity 2.7.7, on a PHP based API that uses rewrites. With my searches of the mailing list archives and git issues, I believe I'm having problem similar to the ones described in https://github.com/SpiderLabs/ModSecurity/issues/1658 I'm fairly certain the rewrite is causing this, however other searches have led me in circles, or dead-ends, suggesting this problem was resolved (e.g. https://github.com/SpiderLabs/ModSecurity/issues/185) Even if I'm doing no rules, and having SecAuditEngine set to On, I get responses on every request that comes through, except for calls that go via /api/ and the rewrite rules, so I'm fairly certain this isn't from a ModSecurity misconfiguration that I've done. My ModSecurity configuration is as follows: SecRuleEngine On SecAuditEngine RelevantOnly SecAuditLogType Concurrent SecAuditLogDirMode 755 SecAuditLogFileMode 644 SecAuditLog /var/log/apache2/post_audit.log SecAuditLogStorageDir /var/log/apache2/modsecurity SecRequestBodyAccess on SecResponseBodyAccess On SecAuditLogParts ABIEFGHZ SecResponseBodyMimeType text/plain text/html text/xml application/json application/x-httpd-php SecRequestBodyLimitAction ProcessPartial SecResponseBodyLimitAction ProcessPartial SecDefaultAction "nolog,noauditlog,allow,phase:2" SecRule REQUEST_METHOD "POST" "id:1234,allow,phase:2,chain" SecRule ARGS:object recording "ctl:auditEngine=On,nolog" With debug logging enabled, I can see that requests to the API are hit, and the rewrite followed but the response is never hit [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Initialising transaction (txid W9cU9n8AAQEAAB30p0sAAAAB). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Transaction context created (dcfg 7f5560154be8). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Starting phase REQUEST_HEADERS. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] This phase consists of 0 rule(s). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Second phase starting (dcfg 7f5560154be8). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Input filter: Reading request body. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] Input filter: Bucket type TRANSIENT contains 53 bytes. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] Input filter: Bucket type EOS contains 0 bytes. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Adding request argument (BODY): name "object", value "recording" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Adding request argument (BODY): name "id", value "20181026131815011691" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Adding request argument (BODY): name "action", value "read" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Input filter: Completed receiving request body (length 53). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Starting phase REQUEST_BODY. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] This phase consists of 2 rule(s). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Recipe: Invoking rule 7f55600d9148; [file "/etc/modsecurity/post_audit.conf"] [line "16"] [id "1234"]. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Rule 7f55600d9148: SecRule "REQUEST_METHOD" "@rx POST" "nolog,noauditlog,phase:2,id:1234,allow:phase,chain" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Transformation completed in 1 usec. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Executing operator "rx" with param "POST" against REQUEST_METHOD. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] Target value: "POST" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Operator completed in 3 usec. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Rule returned 1. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] Match -> mode NEXT_RULE. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Recipe: Invoking rule 7f55600d9b58; [file "/etc/modsecurity/post_audit.conf"] [line "17"]. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][5] Rule 7f55600d9b58: SecRule "ARGS:object" "@rx recording" "ctl:auditEngine=On" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Transformation completed in 0 usec. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Executing operator "rx" with param "recording" against ARGS:object. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] Target value: "recording" [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Operator completed in 1 usec. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Ctl: Set auditEngine to 1. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Rule returned 1. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][9] Match, intercepted -> returning. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Access to phase allowed (phase 2). Pattern match "recording" at ARGS:object. [file "/etc/modsecurity/post_audit.conf"] [line "16"] [id "1234"] [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Hook insert_filter: Adding input forwarding filter (r 7f5546c1a0a0). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Hook insert_filter: Adding output filter (r 7f5546c1a0a0). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c0ebf8][/api/webroot/recordings][4] Hook insert_filter: Adding input forwarding filter for subrequest (r 7f5546c0ebf8). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Hook insert_filter: Adding input forwarding filter for subrequest (r 7f5546c02220). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Input filter: Forwarding input: mode=0, block=0, nbytes=16384 (f 7f5546c00b48, r 7f5546c02220). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Input filter: Forwarded 53 bytes. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Input filter: Sent EOS. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Input filter: Input forwarding complete. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c0ebf8][/api/webroot/recordings][4] Input filter: Input forwarding already complete, skipping (f 7f5546c020c8, r 7f5546c0ebf8). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Input filter: Input forwarding already complete, skipping (f 7f5546c0ea68, r 7f5546c1a0a0). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c1a0a0][/api/recordings][4] Initialising logging. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Starting phase LOGGING. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][9] This phase consists of 0 rule(s). [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Recording persistent data took 0 microseconds. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][4] Audit log: Logging this transaction. [29/Oct/2018:10:11:02 --0400] [apihost.local/sid#7f55600c6d20][rid#7f5546c02220][/api/webroot/index.php][9] Audit Log: Writing 272 bytes to primary concurrent index For another endpoint, that's not hitting a rewrite, it processes as expected [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Initialising transaction (txid W9cU9n8AAQEAAB31DioAAAAC). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][5] Adding request argument (QUERY_STRING): name "status", value "" [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Transaction context created (dcfg 7f5560154be8). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase REQUEST_HEADERS. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase consists of 0 rule(s). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Second phase starting (dcfg 7f5560154be8). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Input filter: This request does not have a body. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase REQUEST_BODY. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase consists of 2 rule(s). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Recipe: Invoking rule 7f55600d9148; [file "/etc/modsecurity/post_audit.conf"] [line "16"] [id "1234"]. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][5] Rule 7f55600d9148: SecRule "REQUEST_METHOD" "@rx POST" "nolog,noauditlog,phase:2,id:1234,allow:phase,chain" [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Transformation completed in 1 usec. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Executing operator "rx" with param "POST" against REQUEST_METHOD. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Target value: "GET" [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Operator completed in 3 usec. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Rule returned 0. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] No match, chained -> mode NEXT_CHAIN. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Hook insert_filter: Adding output filter (r 7f5546c1a0a0). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Hook insert_error_filter: Adding output filter (r 7f5546c1a0a0). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Output filter: Receiving output (f 7f5546c16140, r 7f5546c1a0a0). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase RESPONSE_HEADERS. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase consists of 0 rule(s). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Content Injection: Not enabled. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Output filter: Bucket type HEAP contains 374 bytes. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] Output filter: Bucket type EOS contains 0 bytes. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Output filter: Completed receiving response body (buffered full - 374 bytes). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase RESPONSE_BODY. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase consists of 0 rule(s). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Output filter: Output forwarding complete. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Initialising logging. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Starting phase LOGGING. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][9] This phase consists of 0 rule(s). [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Recording persistent data took 0 microseconds. [29/Oct/2018:10:11:02 --0400] [localhost/sid#7f55600c6d20][rid#7f5546c1a0a0][/rproxy/][4] Audit log: Ignoring a non-relevant request. The audit log file generated by the API call: --a479b55a-B-- POST /api/ HTTP/1.1 Authorization: Basic YnVzOmJ1cw== Host: apihost.local Accept: */* Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 53 --a479b55a-C-- object=recording&id=20181026131815011691&action=read --a479b55a-F-- HTTP/1.1 200 OK Cache-Control: no-store Pragma: no-cache Vary: Accept-Encoding Content-Length: 650 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/xml; charset="utf-8" --a479b55a-H-- Apache-Handler: application/x-httpd-php Stopwatch: 1540822262272919 70600 (- - -) Stopwatch2: 1540822262272919 70600; combined=112, p1=4, p2=83, p3=0, p4=0, p5=24, sr=0, sw=1, l=0, gc=0 Producer: ModSecurity for Apache/2.7.7 (http://www.modsecurity.org/). Server: Apache/2.4.7 (Ubuntu) Engine-Mode: "ENABLED" --a479b55a-Z-- And the rewrite rule setup is from an .htaccess in the directory root for /api/ <IfModule mod_rewrite.c> RewriteEngine on RewriteRule ^$ webroot/ [L] RewriteRule (.*) webroot/$1 [L] </IfModule> Is the rewrite handling still a known issue in 2.7.7, or am I missing a simple configuration option to get this working? -- Adrian Daminato Manager, Core Services, Versature 1-877-498-3772 x111 ada...@ve... *The Latest News from Versature:* Versature to Scale Operations Through Acquisition by net2phone <https://www.versature.com/conversation-blog/net2phone-acquires-versature/> Versature Named to Growth 500 Ranking <https://www.versature.com/conversation-blog/versature-growth500-2018/> Best Questions to Start Your Data Analysis <https://www.versature.com/conversation-blog/best-questions-to-start-your-call-data-analysis/> [image: Website] <https://www.versature.com?utm_source=Signature&utm_medium=Email&utm_campaign=Outreach> [image: LinkedIn] <https://www.linkedin.com/company/Versature> [image: Twitter] <https://www.twitter.com/Versature> [image: Facebook] <https://www.facebook.com/Versature> [image: Instagram] <https://www.instagram.com/versature_hpbx> |
|
From: Christian F. <chr...@ne...> - 2018-10-27 04:02:26
|
Nice one. Congratulations.
On Fri, Oct 26, 2018 at 10:29:54PM +0000, Scheblein, Adam wrote:
> Figured it out. Had to use a period instead of a colon.
>
> Below is the code that I've come up with to block brute force attacks from IP and for Username. Suggestions and comments are welcome:
>
> # Retrieve the IP address
> SecAction id:'2000000',phase:1,nolog,pass,initcol:IP=%{REMOTE_ADDR}
>
> # Enforce an existing IP address block
> SecRule IP:bf_block "@eq 1" \
> "id:'2000001',phase:1,deny,\
> msg:'IP address blocked because of suspected brute-force attack'"
>
> # Retrieve the username
> SecRule REQUEST_HEADERS:Authorization "Basic (.*)" "chain,capture,phase:1,pass,id:'2000002'"
> SecRule TX:1 "^([-a-zA-Z0-9_]+):" "t:base64Decode,chain,capture"
> SecAction initcol:USER=%{TX.1}
>
> # Enforce an existing username block
> SecRule USER:bf_block "@eq 1" \
> "id:'2000003',phase:1,deny,\
> msg:'Username \"%{REMOTE_USER}\" blocked because of suspected brute-force attack'"
>
> # Check that this is a POST
> SecRule REQUEST_METHOD "@streq GET" "id:'2000004',phase:5,chain,t:none,nolog,pass"
> # AND Check for authentication failure and increment counters
> # NOTE this is for a Rails application, you probably need to customize this
> SecRule RESPONSE_STATUS "!200" \
> "setvar:IP.bf_counter=+1,setvar:USER.bf_counter=+1"
>
>
> # Check for too many failures for a single username
> SecRule USER:bf_counter "@ge 3" \
> "id:'2000005',phase:5,t:none,pass,\
> setvar:USER.bf_block,\
> setvar:!USER.bf_counter,\
> expirevar:USER.bf_block=600"
>
> # Check for too many failures from a single IP address. Block for 10 minutes.
> SecRule IP:bf_counter "@ge 3" \
> "id:'2000006',phase:5,pass,t:none, \
> setvar:IP.bf_block,\
> setvar:!IP.bf_counter,\
> expirevar:IP.bf_block=600"
>
> On 10/26/18, 5:07 PM, "Scheblein, Adam" <ada...@ma...> wrote:
>
> I was able to narrow down using decode and TX, however, the issue I'm having now is that:
> Rule 559a7f24c920: SecAction "initcol:USER=%{TX:1}"
> Failed to resolve macro %{tx:1}: Unknown variable: tx:1
>
>
> How do I take what I captured previously and put it in as a key in a collection?
>
> thanks
>
> On 10/26/18, 4:34 PM, "Christian Folini" <chr...@ne...> wrote:
>
> Hey Adam,
>
> Yes, that is possible. It's a nice exercise actually. You need to strip the
> "Basic " prefix, fill the rest into a variable and then t:base64 that variable
> and then extract the 2nd part after the colon. I've built sort of a
> dumb authentication cache based on this. It's been in production for close
> to ten years now, running like a charm.
>
> Cheers,
>
> Christian
>
>
> On Fri, Oct 26, 2018 at 09:20:41PM +0000, Scheblein, Adam wrote:
> > Good thing it was a throw away password __. Is there any way to have mod_security grab the authorization string? I see that there is a base64 transform, so I was hoping to grab the string, decode it, parse/block based on that info.
> >
> > On 10/26/18, 1:38 PM, "Christian Folini" <chr...@ne...> wrote:
> >
> > Hello Adam,
> >
> > I have not tried this example in a while. I wonder if it works for basic auth,
> > because basic auth is likely to shortcut some of the ModSec processing phases
> > in case of a 401.
> >
> > I suggest you raise the ModSec debug log level and then follow the execution
> > of the request to see which rules are actually executed.
> >
> > Also: You should not send Basic Auth Headers to mailing lists. You just
> > shared a password with the world.
> >
> > Good luck,
> >
> > Christian Folini
> >
> > On Fri, Oct 26, 2018 at 04:01:06PM +0000, Scheblein, Adam wrote:
> > > I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
> > >
> > > Here is what I have for my rules and from my audit log:
> > >
> > > Rules:
> > >
> > > <Location />
> > > # Enforce an existing IP address block
> > > SecRule IP:bf_block "@eq 1" \
> > > "phase:2,id:40000000,deny,\
> > > msg:'IP address blocked because of suspected brute-force attack'"
> > > # Retrieve the per-username record
> > > SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
> > > # Enforce an existing username block
> > > SecRule USER:bf_block "@eq 1" \
> > > "phase:2,id:40000001,deny,\
> > > msg:'Username blocked because of suspected brute-force attack'"
> > > # Check for authentication failure and increment counters
> > > SecRule RESPONSE_HEADERS:Location ^/ \
> > > "phase:5,id:40000002,t:none,nolog,pass,\
> > > setvar:IP.bf_counter=+1,\
> > > setvar:USER.bf_counter=+1"
> > > # Check for too many failures from a single IP address
> > > SecRule IP:bf_counter "@gt 2" \
> > > "phase:5,id:40000003,pass,t:none,\
> > > setvar:IP.bf_block,\
> > > setvar:!IP.bf_counter,\
> > > expirevar:IP.block=1800"
> > > # Check for too many failures for a single username
> > > SecRule USER:bf_counter "@gt 2" \
> > > "phase:5,id:40000004,t:none,pass,\
> > > setvar:USER.bf_block,\
> > > setvar:!USER.bf_counter,\
> > > expirevar:USER.block=1800"
> > > </Location>
> > >
> > > Audit log entry:
> > >
> > > --6ba2c30c-B--
> > > GET / HTTP/1.1
> > > Host: something.example.com
> > > Connection: keep-alive
> > > Cache-Control: max-age=0
> > > Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
> > > Upgrade-Insecure-Requests: 1
> > > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
> > > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> > > DNT: 1
> > > Accept-Encoding: gzip, deflate, sdch, br
> > > Accept-Language: en-US,en;q=0.8
> > >
> > > --6ba2c30c-F--
> > > HTTP/1.1 401 Unauthorized
> > > Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> > > X-Frame-Options: DENY
> > > X-Content-Type-Options: nosniff
> > > WWW-Authenticate: Basic realm="Protected"
> > > Content-Length: 503
> > > Keep-Alive: timeout=5, max=98
> > > Connection: Keep-Alive
> > > Content-Type: text/html; charset=iso-8859-1
> > >
> > > --6ba2c30c-E--
> > >
> > > --6ba2c30c-H--
> > > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
> > > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
> > > Stopwatch: 1540568079334381 38724 (- - -)
> > > Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
> > > Response-Body-Transformed: Dechunked
> > > Producer: ModSecurity for Apache/2.9.2 (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=qhl30HpH8LJWoF9f_fT90bk7SdkYVhzO3u8IO6snE-c&e=); OWASP_CRS/3.1.0.
> > > Server: Apache
> > > Engine-Mode: "ENABLED"
> > >
> > > --6ba2c30c-Z--
> >
> >
> > > _______________________________________________
> > > mod-security-users mailing list
> > > mod...@li...
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
> >
> >
> >
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
> >
> >
> >
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=dXjd2nye3iUVNEm093j19LY0GpfxCR95RPj3jE4vl3s&e=
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=gmSmsBQJ3FMfzkzK_EEk8M3OXYq1SjWIz2azKOF7abk&e=
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=WRhDqItV3_pjB8mCAldvdFIKwtWlXs_LpeHrelYeKnQ&e=
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=dXjd2nye3iUVNEm093j19LY0GpfxCR95RPj3jE4vl3s&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=gmSmsBQJ3FMfzkzK_EEk8M3OXYq1SjWIz2azKOF7abk&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=WRhDqItV3_pjB8mCAldvdFIKwtWlXs_LpeHrelYeKnQ&e=
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=dq0RD2ZevA2MC-ce-EVcEtpDx9phI2cKyyyB3u2oSek&s=cb8BEByzikCxnqIkV9FDXQ1no7guc1yfru9xKFwiidk&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=dq0RD2ZevA2MC-ce-EVcEtpDx9phI2cKyyyB3u2oSek&s=e8IKCzOTlGHiYGvAGv69Ompqmjh21sVyrRDTJAb72f0&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=dq0RD2ZevA2MC-ce-EVcEtpDx9phI2cKyyyB3u2oSek&s=u5kx7kDDZo2dvJGGzNUiqC7V8gAN3I52mz8xzzkKJnc&e=
>
>
>
> _______________________________________________
> 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: Scheblein, A. <ada...@ma...> - 2018-10-26 22:30:07
|
Figured it out. Had to use a period instead of a colon.
Below is the code that I've come up with to block brute force attacks from IP and for Username. Suggestions and comments are welcome:
# Retrieve the IP address
SecAction id:'2000000',phase:1,nolog,pass,initcol:IP=%{REMOTE_ADDR}
# Enforce an existing IP address block
SecRule IP:bf_block "@eq 1" \
"id:'2000001',phase:1,deny,\
msg:'IP address blocked because of suspected brute-force attack'"
# Retrieve the username
SecRule REQUEST_HEADERS:Authorization "Basic (.*)" "chain,capture,phase:1,pass,id:'2000002'"
SecRule TX:1 "^([-a-zA-Z0-9_]+):" "t:base64Decode,chain,capture"
SecAction initcol:USER=%{TX.1}
# Enforce an existing username block
SecRule USER:bf_block "@eq 1" \
"id:'2000003',phase:1,deny,\
msg:'Username \"%{REMOTE_USER}\" blocked because of suspected brute-force attack'"
# Check that this is a POST
SecRule REQUEST_METHOD "@streq GET" "id:'2000004',phase:5,chain,t:none,nolog,pass"
# AND Check for authentication failure and increment counters
# NOTE this is for a Rails application, you probably need to customize this
SecRule RESPONSE_STATUS "!200" \
"setvar:IP.bf_counter=+1,setvar:USER.bf_counter=+1"
# Check for too many failures for a single username
SecRule USER:bf_counter "@ge 3" \
"id:'2000005',phase:5,t:none,pass,\
setvar:USER.bf_block,\
setvar:!USER.bf_counter,\
expirevar:USER.bf_block=600"
# Check for too many failures from a single IP address. Block for 10 minutes.
SecRule IP:bf_counter "@ge 3" \
"id:'2000006',phase:5,pass,t:none, \
setvar:IP.bf_block,\
setvar:!IP.bf_counter,\
expirevar:IP.bf_block=600"
On 10/26/18, 5:07 PM, "Scheblein, Adam" <ada...@ma...> wrote:
I was able to narrow down using decode and TX, however, the issue I'm having now is that:
Rule 559a7f24c920: SecAction "initcol:USER=%{TX:1}"
Failed to resolve macro %{tx:1}: Unknown variable: tx:1
How do I take what I captured previously and put it in as a key in a collection?
thanks
On 10/26/18, 4:34 PM, "Christian Folini" <chr...@ne...> wrote:
Hey Adam,
Yes, that is possible. It's a nice exercise actually. You need to strip the
"Basic " prefix, fill the rest into a variable and then t:base64 that variable
and then extract the 2nd part after the colon. I've built sort of a
dumb authentication cache based on this. It's been in production for close
to ten years now, running like a charm.
Cheers,
Christian
On Fri, Oct 26, 2018 at 09:20:41PM +0000, Scheblein, Adam wrote:
> Good thing it was a throw away password __. Is there any way to have mod_security grab the authorization string? I see that there is a base64 transform, so I was hoping to grab the string, decode it, parse/block based on that info.
>
> On 10/26/18, 1:38 PM, "Christian Folini" <chr...@ne...> wrote:
>
> Hello Adam,
>
> I have not tried this example in a while. I wonder if it works for basic auth,
> because basic auth is likely to shortcut some of the ModSec processing phases
> in case of a 401.
>
> I suggest you raise the ModSec debug log level and then follow the execution
> of the request to see which rules are actually executed.
>
> Also: You should not send Basic Auth Headers to mailing lists. You just
> shared a password with the world.
>
> Good luck,
>
> Christian Folini
>
> On Fri, Oct 26, 2018 at 04:01:06PM +0000, Scheblein, Adam wrote:
> > I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
> >
> > Here is what I have for my rules and from my audit log:
> >
> > Rules:
> >
> > <Location />
> > # Enforce an existing IP address block
> > SecRule IP:bf_block "@eq 1" \
> > "phase:2,id:40000000,deny,\
> > msg:'IP address blocked because of suspected brute-force attack'"
> > # Retrieve the per-username record
> > SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
> > # Enforce an existing username block
> > SecRule USER:bf_block "@eq 1" \
> > "phase:2,id:40000001,deny,\
> > msg:'Username blocked because of suspected brute-force attack'"
> > # Check for authentication failure and increment counters
> > SecRule RESPONSE_HEADERS:Location ^/ \
> > "phase:5,id:40000002,t:none,nolog,pass,\
> > setvar:IP.bf_counter=+1,\
> > setvar:USER.bf_counter=+1"
> > # Check for too many failures from a single IP address
> > SecRule IP:bf_counter "@gt 2" \
> > "phase:5,id:40000003,pass,t:none,\
> > setvar:IP.bf_block,\
> > setvar:!IP.bf_counter,\
> > expirevar:IP.block=1800"
> > # Check for too many failures for a single username
> > SecRule USER:bf_counter "@gt 2" \
> > "phase:5,id:40000004,t:none,pass,\
> > setvar:USER.bf_block,\
> > setvar:!USER.bf_counter,\
> > expirevar:USER.block=1800"
> > </Location>
> >
> > Audit log entry:
> >
> > --6ba2c30c-B--
> > GET / HTTP/1.1
> > Host: something.example.com
> > Connection: keep-alive
> > Cache-Control: max-age=0
> > Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
> > Upgrade-Insecure-Requests: 1
> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> > DNT: 1
> > Accept-Encoding: gzip, deflate, sdch, br
> > Accept-Language: en-US,en;q=0.8
> >
> > --6ba2c30c-F--
> > HTTP/1.1 401 Unauthorized
> > Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> > X-Frame-Options: DENY
> > X-Content-Type-Options: nosniff
> > WWW-Authenticate: Basic realm="Protected"
> > Content-Length: 503
> > Keep-Alive: timeout=5, max=98
> > Connection: Keep-Alive
> > Content-Type: text/html; charset=iso-8859-1
> >
> > --6ba2c30c-E--
> >
> > --6ba2c30c-H--
> > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
> > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
> > Stopwatch: 1540568079334381 38724 (- - -)
> > Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
> > Response-Body-Transformed: Dechunked
> > Producer: ModSecurity for Apache/2.9.2 (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=qhl30HpH8LJWoF9f_fT90bk7SdkYVhzO3u8IO6snE-c&e=); OWASP_CRS/3.1.0.
> > Server: Apache
> > Engine-Mode: "ENABLED"
> >
> > --6ba2c30c-Z--
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=dXjd2nye3iUVNEm093j19LY0GpfxCR95RPj3jE4vl3s&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=gmSmsBQJ3FMfzkzK_EEk8M3OXYq1SjWIz2azKOF7abk&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=WRhDqItV3_pjB8mCAldvdFIKwtWlXs_LpeHrelYeKnQ&e=
_______________________________________________
mod-security-users mailing list
mod...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=dXjd2nye3iUVNEm093j19LY0GpfxCR95RPj3jE4vl3s&e=
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=gmSmsBQJ3FMfzkzK_EEk8M3OXYq1SjWIz2azKOF7abk&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=WRhDqItV3_pjB8mCAldvdFIKwtWlXs_LpeHrelYeKnQ&e=
_______________________________________________
mod-security-users mailing list
mod...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=dq0RD2ZevA2MC-ce-EVcEtpDx9phI2cKyyyB3u2oSek&s=cb8BEByzikCxnqIkV9FDXQ1no7guc1yfru9xKFwiidk&e=
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=dq0RD2ZevA2MC-ce-EVcEtpDx9phI2cKyyyB3u2oSek&s=e8IKCzOTlGHiYGvAGv69Ompqmjh21sVyrRDTJAb72f0&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=dq0RD2ZevA2MC-ce-EVcEtpDx9phI2cKyyyB3u2oSek&s=u5kx7kDDZo2dvJGGzNUiqC7V8gAN3I52mz8xzzkKJnc&e=
|
|
From: Scheblein, A. <ada...@ma...> - 2018-10-26 22:07:33
|
I was able to narrow down using decode and TX, however, the issue I'm having now is that:
Rule 559a7f24c920: SecAction "initcol:USER=%{TX:1}"
Failed to resolve macro %{tx:1}: Unknown variable: tx:1
How do I take what I captured previously and put it in as a key in a collection?
thanks
On 10/26/18, 4:34 PM, "Christian Folini" <chr...@ne...> wrote:
Hey Adam,
Yes, that is possible. It's a nice exercise actually. You need to strip the
"Basic " prefix, fill the rest into a variable and then t:base64 that variable
and then extract the 2nd part after the colon. I've built sort of a
dumb authentication cache based on this. It's been in production for close
to ten years now, running like a charm.
Cheers,
Christian
On Fri, Oct 26, 2018 at 09:20:41PM +0000, Scheblein, Adam wrote:
> Good thing it was a throw away password __. Is there any way to have mod_security grab the authorization string? I see that there is a base64 transform, so I was hoping to grab the string, decode it, parse/block based on that info.
>
> On 10/26/18, 1:38 PM, "Christian Folini" <chr...@ne...> wrote:
>
> Hello Adam,
>
> I have not tried this example in a while. I wonder if it works for basic auth,
> because basic auth is likely to shortcut some of the ModSec processing phases
> in case of a 401.
>
> I suggest you raise the ModSec debug log level and then follow the execution
> of the request to see which rules are actually executed.
>
> Also: You should not send Basic Auth Headers to mailing lists. You just
> shared a password with the world.
>
> Good luck,
>
> Christian Folini
>
> On Fri, Oct 26, 2018 at 04:01:06PM +0000, Scheblein, Adam wrote:
> > I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
> >
> > Here is what I have for my rules and from my audit log:
> >
> > Rules:
> >
> > <Location />
> > # Enforce an existing IP address block
> > SecRule IP:bf_block "@eq 1" \
> > "phase:2,id:40000000,deny,\
> > msg:'IP address blocked because of suspected brute-force attack'"
> > # Retrieve the per-username record
> > SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
> > # Enforce an existing username block
> > SecRule USER:bf_block "@eq 1" \
> > "phase:2,id:40000001,deny,\
> > msg:'Username blocked because of suspected brute-force attack'"
> > # Check for authentication failure and increment counters
> > SecRule RESPONSE_HEADERS:Location ^/ \
> > "phase:5,id:40000002,t:none,nolog,pass,\
> > setvar:IP.bf_counter=+1,\
> > setvar:USER.bf_counter=+1"
> > # Check for too many failures from a single IP address
> > SecRule IP:bf_counter "@gt 2" \
> > "phase:5,id:40000003,pass,t:none,\
> > setvar:IP.bf_block,\
> > setvar:!IP.bf_counter,\
> > expirevar:IP.block=1800"
> > # Check for too many failures for a single username
> > SecRule USER:bf_counter "@gt 2" \
> > "phase:5,id:40000004,t:none,pass,\
> > setvar:USER.bf_block,\
> > setvar:!USER.bf_counter,\
> > expirevar:USER.block=1800"
> > </Location>
> >
> > Audit log entry:
> >
> > --6ba2c30c-B--
> > GET / HTTP/1.1
> > Host: something.example.com
> > Connection: keep-alive
> > Cache-Control: max-age=0
> > Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
> > Upgrade-Insecure-Requests: 1
> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> > DNT: 1
> > Accept-Encoding: gzip, deflate, sdch, br
> > Accept-Language: en-US,en;q=0.8
> >
> > --6ba2c30c-F--
> > HTTP/1.1 401 Unauthorized
> > Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> > X-Frame-Options: DENY
> > X-Content-Type-Options: nosniff
> > WWW-Authenticate: Basic realm="Protected"
> > Content-Length: 503
> > Keep-Alive: timeout=5, max=98
> > Connection: Keep-Alive
> > Content-Type: text/html; charset=iso-8859-1
> >
> > --6ba2c30c-E--
> >
> > --6ba2c30c-H--
> > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
> > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
> > Stopwatch: 1540568079334381 38724 (- - -)
> > Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
> > Response-Body-Transformed: Dechunked
> > Producer: ModSecurity for Apache/2.9.2 (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=qhl30HpH8LJWoF9f_fT90bk7SdkYVhzO3u8IO6snE-c&e=); OWASP_CRS/3.1.0.
> > Server: Apache
> > Engine-Mode: "ENABLED"
> >
> > --6ba2c30c-Z--
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=dXjd2nye3iUVNEm093j19LY0GpfxCR95RPj3jE4vl3s&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=gmSmsBQJ3FMfzkzK_EEk8M3OXYq1SjWIz2azKOF7abk&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=WRhDqItV3_pjB8mCAldvdFIKwtWlXs_LpeHrelYeKnQ&e=
_______________________________________________
mod-security-users mailing list
mod...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=dXjd2nye3iUVNEm093j19LY0GpfxCR95RPj3jE4vl3s&e=
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=gmSmsBQJ3FMfzkzK_EEk8M3OXYq1SjWIz2azKOF7abk&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=QxsBsil2ErNwOo7Gy3ZZLEMghErRFXb_I7zp9Ofqe4c&s=WRhDqItV3_pjB8mCAldvdFIKwtWlXs_LpeHrelYeKnQ&e=
|
|
From: Christian F. <chr...@ne...> - 2018-10-26 21:33:48
|
Hey Adam,
Yes, that is possible. It's a nice exercise actually. You need to strip the
"Basic " prefix, fill the rest into a variable and then t:base64 that variable
and then extract the 2nd part after the colon. I've built sort of a
dumb authentication cache based on this. It's been in production for close
to ten years now, running like a charm.
Cheers,
Christian
On Fri, Oct 26, 2018 at 09:20:41PM +0000, Scheblein, Adam wrote:
> Good thing it was a throw away password __. Is there any way to have mod_security grab the authorization string? I see that there is a base64 transform, so I was hoping to grab the string, decode it, parse/block based on that info.
>
> On 10/26/18, 1:38 PM, "Christian Folini" <chr...@ne...> wrote:
>
> Hello Adam,
>
> I have not tried this example in a while. I wonder if it works for basic auth,
> because basic auth is likely to shortcut some of the ModSec processing phases
> in case of a 401.
>
> I suggest you raise the ModSec debug log level and then follow the execution
> of the request to see which rules are actually executed.
>
> Also: You should not send Basic Auth Headers to mailing lists. You just
> shared a password with the world.
>
> Good luck,
>
> Christian Folini
>
> On Fri, Oct 26, 2018 at 04:01:06PM +0000, Scheblein, Adam wrote:
> > I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
> >
> > Here is what I have for my rules and from my audit log:
> >
> > Rules:
> >
> > <Location />
> > # Enforce an existing IP address block
> > SecRule IP:bf_block "@eq 1" \
> > "phase:2,id:40000000,deny,\
> > msg:'IP address blocked because of suspected brute-force attack'"
> > # Retrieve the per-username record
> > SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
> > # Enforce an existing username block
> > SecRule USER:bf_block "@eq 1" \
> > "phase:2,id:40000001,deny,\
> > msg:'Username blocked because of suspected brute-force attack'"
> > # Check for authentication failure and increment counters
> > SecRule RESPONSE_HEADERS:Location ^/ \
> > "phase:5,id:40000002,t:none,nolog,pass,\
> > setvar:IP.bf_counter=+1,\
> > setvar:USER.bf_counter=+1"
> > # Check for too many failures from a single IP address
> > SecRule IP:bf_counter "@gt 2" \
> > "phase:5,id:40000003,pass,t:none,\
> > setvar:IP.bf_block,\
> > setvar:!IP.bf_counter,\
> > expirevar:IP.block=1800"
> > # Check for too many failures for a single username
> > SecRule USER:bf_counter "@gt 2" \
> > "phase:5,id:40000004,t:none,pass,\
> > setvar:USER.bf_block,\
> > setvar:!USER.bf_counter,\
> > expirevar:USER.block=1800"
> > </Location>
> >
> > Audit log entry:
> >
> > --6ba2c30c-B--
> > GET / HTTP/1.1
> > Host: something.example.com
> > Connection: keep-alive
> > Cache-Control: max-age=0
> > Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
> > Upgrade-Insecure-Requests: 1
> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> > DNT: 1
> > Accept-Encoding: gzip, deflate, sdch, br
> > Accept-Language: en-US,en;q=0.8
> >
> > --6ba2c30c-F--
> > HTTP/1.1 401 Unauthorized
> > Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> > X-Frame-Options: DENY
> > X-Content-Type-Options: nosniff
> > WWW-Authenticate: Basic realm="Protected"
> > Content-Length: 503
> > Keep-Alive: timeout=5, max=98
> > Connection: Keep-Alive
> > Content-Type: text/html; charset=iso-8859-1
> >
> > --6ba2c30c-E--
> >
> > --6ba2c30c-H--
> > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
> > Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
> > Stopwatch: 1540568079334381 38724 (- - -)
> > Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
> > Response-Body-Transformed: Dechunked
> > Producer: ModSecurity for Apache/2.9.2 (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=qhl30HpH8LJWoF9f_fT90bk7SdkYVhzO3u8IO6snE-c&e=); OWASP_CRS/3.1.0.
> > Server: Apache
> > Engine-Mode: "ENABLED"
> >
> > --6ba2c30c-Z--
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
>
>
>
> _______________________________________________
> 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: Scheblein, A. <ada...@ma...> - 2018-10-26 21:20:59
|
Good thing it was a throw away password __. Is there any way to have mod_security grab the authorization string? I see that there is a base64 transform, so I was hoping to grab the string, decode it, parse/block based on that info.
On 10/26/18, 1:38 PM, "Christian Folini" <chr...@ne...> wrote:
Hello Adam,
I have not tried this example in a while. I wonder if it works for basic auth,
because basic auth is likely to shortcut some of the ModSec processing phases
in case of a 401.
I suggest you raise the ModSec debug log level and then follow the execution
of the request to see which rules are actually executed.
Also: You should not send Basic Auth Headers to mailing lists. You just
shared a password with the world.
Good luck,
Christian Folini
On Fri, Oct 26, 2018 at 04:01:06PM +0000, Scheblein, Adam wrote:
> I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
>
> Here is what I have for my rules and from my audit log:
>
> Rules:
>
> <Location />
> # Enforce an existing IP address block
> SecRule IP:bf_block "@eq 1" \
> "phase:2,id:40000000,deny,\
> msg:'IP address blocked because of suspected brute-force attack'"
> # Retrieve the per-username record
> SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
> # Enforce an existing username block
> SecRule USER:bf_block "@eq 1" \
> "phase:2,id:40000001,deny,\
> msg:'Username blocked because of suspected brute-force attack'"
> # Check for authentication failure and increment counters
> SecRule RESPONSE_HEADERS:Location ^/ \
> "phase:5,id:40000002,t:none,nolog,pass,\
> setvar:IP.bf_counter=+1,\
> setvar:USER.bf_counter=+1"
> # Check for too many failures from a single IP address
> SecRule IP:bf_counter "@gt 2" \
> "phase:5,id:40000003,pass,t:none,\
> setvar:IP.bf_block,\
> setvar:!IP.bf_counter,\
> expirevar:IP.block=1800"
> # Check for too many failures for a single username
> SecRule USER:bf_counter "@gt 2" \
> "phase:5,id:40000004,t:none,pass,\
> setvar:USER.bf_block,\
> setvar:!USER.bf_counter,\
> expirevar:USER.block=1800"
> </Location>
>
> Audit log entry:
>
> --6ba2c30c-B--
> GET / HTTP/1.1
> Host: something.example.com
> Connection: keep-alive
> Cache-Control: max-age=0
> Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> DNT: 1
> Accept-Encoding: gzip, deflate, sdch, br
> Accept-Language: en-US,en;q=0.8
>
> --6ba2c30c-F--
> HTTP/1.1 401 Unauthorized
> Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> X-Frame-Options: DENY
> X-Content-Type-Options: nosniff
> WWW-Authenticate: Basic realm="Protected"
> Content-Length: 503
> Keep-Alive: timeout=5, max=98
> Connection: Keep-Alive
> Content-Type: text/html; charset=iso-8859-1
>
> --6ba2c30c-E--
>
> --6ba2c30c-H--
> Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
> Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
> Stopwatch: 1540568079334381 38724 (- - -)
> Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
> Response-Body-Transformed: Dechunked
> Producer: ModSecurity for Apache/2.9.2 (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=qhl30HpH8LJWoF9f_fT90bk7SdkYVhzO3u8IO6snE-c&e=); OWASP_CRS/3.1.0.
> Server: Apache
> Engine-Mode: "ENABLED"
>
> --6ba2c30c-Z--
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
_______________________________________________
mod-security-users mailing list
mod...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_mod-2Dsecurity-2Dusers&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=u0jxmP0rhtu23yq0M7-p60br38HreMChRHJCZzer0K4&e=
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_rules_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=cgYc-s-PpwppJr8fIXLtgK1mSJQAmqnzkZsq75TRROc&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.modsecurity.org_projects_commercial_support_&d=DwIGaQ&c=S1d2Gs1Y1NQV8Lx35_Qi5FnTH2uYWyh_OhOS94IqYCo&r=E28NzkfUnnOxyipWbMmVvps8QnGe_19SJDNMcPTyffU&m=GrUG5eW733hjZXRRayDFZ-lKai5L1jGVaa1B8_csXeY&s=Ny1EXwvYROVsswWxOxuWAOakyrwvh8fVr_cvjsPcHXA&e=
|
|
From: Christian F. <chr...@ne...> - 2018-10-26 18:38:02
|
Hello Adam,
I have not tried this example in a while. I wonder if it works for basic auth,
because basic auth is likely to shortcut some of the ModSec processing phases
in case of a 401.
I suggest you raise the ModSec debug log level and then follow the execution
of the request to see which rules are actually executed.
Also: You should not send Basic Auth Headers to mailing lists. You just
shared a password with the world.
Good luck,
Christian Folini
On Fri, Oct 26, 2018 at 04:01:06PM +0000, Scheblein, Adam wrote:
> I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
>
> Here is what I have for my rules and from my audit log:
>
> Rules:
>
> <Location />
> # Enforce an existing IP address block
> SecRule IP:bf_block "@eq 1" \
> "phase:2,id:40000000,deny,\
> msg:'IP address blocked because of suspected brute-force attack'"
> # Retrieve the per-username record
> SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
> # Enforce an existing username block
> SecRule USER:bf_block "@eq 1" \
> "phase:2,id:40000001,deny,\
> msg:'Username blocked because of suspected brute-force attack'"
> # Check for authentication failure and increment counters
> SecRule RESPONSE_HEADERS:Location ^/ \
> "phase:5,id:40000002,t:none,nolog,pass,\
> setvar:IP.bf_counter=+1,\
> setvar:USER.bf_counter=+1"
> # Check for too many failures from a single IP address
> SecRule IP:bf_counter "@gt 2" \
> "phase:5,id:40000003,pass,t:none,\
> setvar:IP.bf_block,\
> setvar:!IP.bf_counter,\
> expirevar:IP.block=1800"
> # Check for too many failures for a single username
> SecRule USER:bf_counter "@gt 2" \
> "phase:5,id:40000004,t:none,pass,\
> setvar:USER.bf_block,\
> setvar:!USER.bf_counter,\
> expirevar:USER.block=1800"
> </Location>
>
> Audit log entry:
>
> --6ba2c30c-B--
> GET / HTTP/1.1
> Host: something.example.com
> Connection: keep-alive
> Cache-Control: max-age=0
> Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> DNT: 1
> Accept-Encoding: gzip, deflate, sdch, br
> Accept-Language: en-US,en;q=0.8
>
> --6ba2c30c-F--
> HTTP/1.1 401 Unauthorized
> Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
> X-Frame-Options: DENY
> X-Content-Type-Options: nosniff
> WWW-Authenticate: Basic realm="Protected"
> Content-Length: 503
> Keep-Alive: timeout=5, max=98
> Connection: Keep-Alive
> Content-Type: text/html; charset=iso-8859-1
>
> --6ba2c30c-E--
>
> --6ba2c30c-H--
> Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
> Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
> Stopwatch: 1540568079334381 38724 (- - -)
> Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
> Response-Body-Transformed: Dechunked
> Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/); OWASP_CRS/3.1.0.
> Server: Apache
> Engine-Mode: "ENABLED"
>
> --6ba2c30c-Z--
> _______________________________________________
> 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: Scheblein, A. <ada...@ma...> - 2018-10-26 18:19:00
|
I’m trying to implement basic auth protection based on the example given in the modsecurity handbook, however, the rules never seem to engage. Any help would be appreciated.
Here is what I have for my rules and from my audit log:
Rules:
<Location />
# Enforce an existing IP address block
SecRule IP:bf_block "@eq 1" \
"phase:2,id:40000000,deny,\
msg:'IP address blocked because of suspected brute-force attack'"
# Retrieve the per-username record
SecAction phase:2,id:40000005,nolog,pass,initcol:USER=%{ARGS.username}
# Enforce an existing username block
SecRule USER:bf_block "@eq 1" \
"phase:2,id:40000001,deny,\
msg:'Username blocked because of suspected brute-force attack'"
# Check for authentication failure and increment counters
SecRule RESPONSE_HEADERS:Location ^/ \
"phase:5,id:40000002,t:none,nolog,pass,\
setvar:IP.bf_counter=+1,\
setvar:USER.bf_counter=+1"
# Check for too many failures from a single IP address
SecRule IP:bf_counter "@gt 2" \
"phase:5,id:40000003,pass,t:none,\
setvar:IP.bf_block,\
setvar:!IP.bf_counter,\
expirevar:IP.block=1800"
# Check for too many failures for a single username
SecRule USER:bf_counter "@gt 2" \
"phase:5,id:40000004,t:none,pass,\
setvar:USER.bf_block,\
setvar:!USER.bf_counter,\
expirevar:USER.block=1800"
</Location>
Audit log entry:
--6ba2c30c-B--
GET / HTTP/1.1
Host: something.example.com
Connection: keep-alive
Cache-Control: max-age=0
Authorization: Basic MjhjM3NjaGVibGVpOmFzZGY=
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8
--6ba2c30c-F--
HTTP/1.1 401 Unauthorized
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
WWW-Authenticate: Basic realm="Protected"
Content-Length: 503
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--6ba2c30c-E--
--6ba2c30c-H--
Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/": Password Mismatch
Apache-Error: [file "mod_auth_basic.c"] [line 406] [level 3] AH01617: user username: authentication failure for "/tools/unauthorized.shtml": Password Mismatch
Stopwatch: 1540568079334381 38724 (- - -)
Stopwatch2: 1540568079334381 38724; combined=494, p1=280, p2=0, p3=61, p4=92, p5=61, sr=12, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/); OWASP_CRS/3.1.0.
Server: Apache
Engine-Mode: "ENABLED"
--6ba2c30c-Z--
|
|
From: Christian F. <chr...@ne...> - 2018-10-20 18:38:40
|
Hey Todor, Hmm, my initial thought was wrong. Your Rewrite Rule should not be any problem. What does your DebugLog say? Can you do a rule in phase 4 that displays RESPONSE_BODY in an alert message? Do you see it? Best, Christian On Fri, Oct 19, 2018 at 10:39:21AM +0300, Todor Petkov wrote: > On Thu, Oct 18, 2018 at 9:00 PM Christian Folini > <chr...@ne...> wrote: > > > > Todor, > > > > Your pastebin is now gone, but it feels as if your RewriteRule would ahve > > apache stop all further execution of the request. This bypasses ModSec > > and immediately sends out the response. This is also the case when you > > encounter a local 404 as an example. > > > Hello, > > this is the new pastebin https://pastebin.com/PxAPdH4b > > I came upon this issue on github > https://github.com/SpiderLabs/ModSecurity/issues/185 but I could not > find anything useful there. Also, the response is "200". > > htaccess is: > RewriteEngine on > RewriteRule (.*) index.php [L] > > > Thanks in advance > > > _______________________________________________ > 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: Todor P. <pet...@gm...> - 2018-10-19 07:39:40
|
On Thu, Oct 18, 2018 at 9:00 PM Christian Folini <chr...@ne...> wrote: > > Todor, > > Your pastebin is now gone, but it feels as if your RewriteRule would ahve > apache stop all further execution of the request. This bypasses ModSec > and immediately sends out the response. This is also the case when you > encounter a local 404 as an example. Hello, this is the new pastebin https://pastebin.com/PxAPdH4b I came upon this issue on github https://github.com/SpiderLabs/ModSecurity/issues/185 but I could not find anything useful there. Also, the response is "200". htaccess is: RewriteEngine on RewriteRule (.*) index.php [L] Thanks in advance |
|
From: Christian F. <chr...@ne...> - 2018-10-18 17:58:36
|
Todor, Your pastebin is now gone, but it feels as if your RewriteRule would ahve apache stop all further execution of the request. This bypasses ModSec and immediately sends out the response. This is also the case when you encounter a local 404 as an example. Best, Christian On Thu, Oct 18, 2018 at 05:40:25PM +0300, Todor Petkov wrote: > Hello, > > I am trying to set up modsecurity 2.9.2 to log requests/response on > Apache 2.4.6. My config is https://pastebin.com/wAZJwecy. When there > is mod_rewrite rule to forward to index.php, it does not log the > response, even if I open directly http://server/index.php instead of > http://server. If I remove the > mod_rewrite lines from .htaccess, the logging is fine. Has anyone run > into such scenario? > > > Regards > > > _______________________________________________ > 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: Todor P. <pet...@gm...> - 2018-10-18 14:40:44
|
Hello, I am trying to set up modsecurity 2.9.2 to log requests/response on Apache 2.4.6. My config is https://pastebin.com/wAZJwecy. When there is mod_rewrite rule to forward to index.php, it does not log the response, even if I open directly http://server/index.php instead of http://server. If I remove the mod_rewrite lines from .htaccess, the logging is fine. Has anyone run into such scenario? Regards |
|
From: Aditya M. <man...@gm...> - 2018-10-15 13:02:15
|
Dear All, Why i cant drop db from phpmyadmin, it said error 403. modsecurity block it. Anyone know what i need to adjust so i can drop db from phpmyadmin? Regards, Aditya Manumayasa |
|
From: Osama E. <oel...@gm...> - 2018-10-09 09:21:19
|
One approach you might consider is: - have a regex rule that checks if the document is likely "good" (has the string(s) that you expect). Drop / log anything else So you would drop records that don’t have the word setup for example. - have a rule that validates the document against an XML schema or DTD. ModSecurity has support for this (refer to this for an example: https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Mitigations-for-Ruby-on-Rails-XML-Exploits/ ) ModSecurity also has XPath support, so you can use XPath. Here is an example of what you can do: SecRule XML:/employees/employee/name/text() "!@rx ^[a-zA-Z ]{3,33}$" \ "id:2000,phase:2,deny,msg:'Invalid employee name'" So you can use XPath to validate that a given value is of a specific type or in a specific range You can also have a look at Chapter 14 in the ModSecurity Handbook 2nd Edition which covers XML Finally, if the above does not cover your use case, you could look at using Lua and one of the Lua XML parser libraries -- Osama Elnaggar On October 9, 2018 at 2:42:59 PM, Christian Folini ( chr...@ne...) wrote: Hello Ivan, That sounds like a call for a whitelisting rule set. You can take my basic recipe in tutorial 6, step 8 as a base and adopt as needed: https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Working with XML is a bit tricky and I have not really done whitelist extensively. So I am not sure you can really address each parameter accordingly for whitelisting through ModSec. But it's a start. Good luck! Christian On Tue, Oct 09, 2018 at 09:28:14AM +1100, Ivan Rodriguez wrote: > Hi there, > > So it happens we have a 3rd party API provider that we need to expose, the > API is quite extensive, we would like to basically block every single call > to the API except for a very specific call with some specific parameters, > for example > > block something like this > curl -s -d "<config classId='c' cookie='xx' />" > and allow only something like this > curl -s -d "<setup classId='x' cookie='xx' />" > > we have the full API reference so we could have one rule per api call that > we want to block, what would be the best way to achieve this ? on modsec 2 > ? > > Thanks in advance > _______________________________________________ > 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: Christian F. <chr...@ne...> - 2018-10-09 03:40:31
|
Hello Ivan, That sounds like a call for a whitelisting rule set. You can take my basic recipe in tutorial 6, step 8 as a base and adopt as needed: https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Working with XML is a bit tricky and I have not really done whitelist extensively. So I am not sure you can really address each parameter accordingly for whitelisting through ModSec. But it's a start. Good luck! Christian On Tue, Oct 09, 2018 at 09:28:14AM +1100, Ivan Rodriguez wrote: > Hi there, > > So it happens we have a 3rd party API provider that we need to expose, the > API is quite extensive, we would like to basically block every single call > to the API except for a very specific call with some specific parameters, > for example > > block something like this > curl -s -d "<config classId='c' cookie='xx' />" > and allow only something like this > curl -s -d "<setup classId='x' cookie='xx' />" > > we have the full API reference so we could have one rule per api call that > we want to block, what would be the best way to achieve this ? on modsec 2 > ? > > Thanks in advance > _______________________________________________ > 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: Ivan R. <iv...@gm...> - 2018-10-08 22:28:33
|
Hi there, So it happens we have a 3rd party API provider that we need to expose, the API is quite extensive, we would like to basically block every single call to the API except for a very specific call with some specific parameters, for example block something like this curl -s -d "<config classId='c' cookie='xx' />" and allow only something like this curl -s -d "<setup classId='x' cookie='xx' />" we have the full API reference so we could have one rule per api call that we want to block, what would be the best way to achieve this ? on modsec 2 ? Thanks in advance |
|
From: 黃 世名 <ct...@ho...> - 2018-10-05 08:17:55
|
Hi, I am curious about how to boost audit log performance. Regardless of mode Serial or Concurrent, I find that there is a huge bottleneck in audit log engine. After enabling audit log engine, Modsecurity's requests per second can decrease from 1000 to 270 with command wrk. In addition to this, when using command "wrk -t1 -c10 -d60s http:/uri", nginx processes would not response any more and become unavailable to normal request. I use v3 master(libmodsecuriy: 738e328, nginx-module-modsecurity: 4b50399, nginx: 1.14.0) as my test bed. Like Nginx, instead of writing a log entry for every request to disk immediately, it can buffer entries in memory and write them to disk as a group. Is it possible to apply this mechanism to audit log engine or there having another approach to solve this challenge? Regards, Daniel |
|
From: Reindl H. <h.r...@th...> - 2018-10-04 16:55:08
|
Am 04.10.18 um 18:45 schrieb Thorsten Kampe: > * Christian Folini (Tue, 2 Oct 2018 20:26:53 +0200) >> I can't confirm. I'm getting the tmp file as expected. >> >> Do you have permissions restricting the www-data user from writing to /tmp? > > It was actually a permissions issue (kind of). Apache was obviosly > able to write to /tmp because that's were the scanned files were > temporarily stored. > > I switched the log directory for my shell script from /tmp to > /var/log/apache2. This is where Apache writes its log files so I > could not expect any permission issues. Despite of that Apache's > error.log now showed permission errors. There were no error log > entries when I used /tmp. > > I created a new directory and made www-data the owner. Now everything > works fine the native httpd logs are opened at start as root anything else runs by the user after drop privileges from the workers |
|
From: Thorsten K. <tho...@th...> - 2018-10-04 16:45:47
|
* Christian Folini (Tue, 2 Oct 2018 20:26:53 +0200) > I can't confirm. I'm getting the tmp file as expected. > > Do you have permissions restricting the www-data user from writing to /tmp? It was actually a permissions issue (kind of). Apache was obviosly able to write to /tmp because that's were the scanned files were temporarily stored. I switched the log directory for my shell script from /tmp to /var/log/apache2. This is where Apache writes its log files so I could not expect any permission issues. Despite of that Apache's error.log now showed permission errors. There were no error log entries when I used /tmp. I created a new directory and made www-data the owner. Now everything works fine. Thanks, guys Thorsten |
|
From: Osama E. <oel...@gm...> - 2018-10-02 19:43:14
|
To add to Christian’s suggestion, as you are on Ubuntu 18.04, you might have an AppArmor profile loaded for Apache2 (a profile doesn't come by default in 18.04 but is included in either apparmor-profiles or apparmor-profiles-extra - don't remember which one). This could be the reason the command isn’t executed. Run the following to see if it is the culprit. If so, update it to allow execution of your bash script: grep -i "apparmor=\"DENIED\"" /var/log/audit/audit.log | grep -i "<path_to_binary>" -- Osama Elnaggar On October 3, 2018 at 4:28:49 AM, Christian Folini ( chr...@ne...) wrote: Hey Thorsten, I can't confirm. I'm getting the tmp file as expected. Do you have permissions restricting the www-data user from writing to /tmp? The next thing I would do is calling apache via $> strace httpd -X and then look for the write operation. (Did not do this myself, but I reckon is should be visible). Ahoj, Christian On Tue, Oct 02, 2018 at 08:05:29PM +0200, Thorsten Kampe wrote: > Hi, > > I have a script that inspects files for viruses (like in "Inspecting > Files" from https://www.feistyduck.com/library/modsecurity% > 2dhandbook%2dfree/online/ch04-logging.html). > > This script works fine - although any file that I want to write to or > create from this script is neither created nor modified. > > See this simple example script: > > ### > #! /usr/bin/env bash > > touch /tmp/MODSECURITY-WAS-HERE.txt > > printf '0 THREAD DETECTED\n' > ### > > This scripts denies all Uploads via Apache but no file "MODSECURITY- > WAS-HERE.txt" is created. > > This are the relevant lines from modsecurity.conf > ### (line break in line 2) > SecRuleEngine On > > SecTmpSaveUploadedFiles On > > SecRule FILES_TMPNAMES "@inspectFile /opt/sophos-av/runav.sh" > "id:'1',log,auditlog,deny,severity:2,phase:2,t:none" > ### > > This is mod-security 2.9.2 on Ubuntu 18.04. > > > Thorsten > > > > _______________________________________________ > 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: Christian F. <chr...@ne...> - 2018-10-02 18:27:06
|
Hey Thorsten, I can't confirm. I'm getting the tmp file as expected. Do you have permissions restricting the www-data user from writing to /tmp? The next thing I would do is calling apache via $> strace httpd -X and then look for the write operation. (Did not do this myself, but I reckon is should be visible). Ahoj, Christian On Tue, Oct 02, 2018 at 08:05:29PM +0200, Thorsten Kampe wrote: > Hi, > > I have a script that inspects files for viruses (like in "Inspecting > Files" from https://www.feistyduck.com/library/modsecurity% > 2dhandbook%2dfree/online/ch04-logging.html). > > This script works fine - although any file that I want to write to or > create from this script is neither created nor modified. > > See this simple example script: > > ### > #! /usr/bin/env bash > > touch /tmp/MODSECURITY-WAS-HERE.txt > > printf '0 THREAD DETECTED\n' > ### > > This scripts denies all Uploads via Apache but no file "MODSECURITY- > WAS-HERE.txt" is created. > > This are the relevant lines from modsecurity.conf > ### (line break in line 2) > SecRuleEngine On > > SecTmpSaveUploadedFiles On > > SecRule FILES_TMPNAMES "@inspectFile /opt/sophos-av/runav.sh" > "id:'1',log,auditlog,deny,severity:2,phase:2,t:none" > ### > > This is mod-security 2.9.2 on Ubuntu 18.04. > > > Thorsten > > > > _______________________________________________ > 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: Thorsten K. <tho...@th...> - 2018-10-02 18:07:31
|
Hi, I have a script that inspects files for viruses (like in "Inspecting Files" from https://www.feistyduck.com/library/modsecurity% 2dhandbook%2dfree/online/ch04-logging.html). This script works fine - although any file that I want to write to or create from this script is neither created nor modified. See this simple example script: ### #! /usr/bin/env bash touch /tmp/MODSECURITY-WAS-HERE.txt printf '0 THREAD DETECTED\n' ### This scripts denies all Uploads via Apache but no file "MODSECURITY- WAS-HERE.txt" is created. This are the relevant lines from modsecurity.conf ### (line break in line 2) SecRuleEngine On SecTmpSaveUploadedFiles On SecRule FILES_TMPNAMES "@inspectFile /opt/sophos-av/runav.sh" "id:'1',log,auditlog,deny,severity:2,phase:2,t:none" ### This is mod-security 2.9.2 on Ubuntu 18.04. Thorsten |
|
From: Christian F. <chr...@ne...> - 2018-09-27 05:14:04
|
Hello everybody, I just published the news of the OWASP ModSecurity Core Rule Set project for the month of September: https://coreruleset.org/20180927/crs-project-news-september-2018/ It includes the CRS 3.1-RC1 release obviously and hope for GeoIP on ModSec 2.9. Best, Christian -- A man must be big enough to admit to his mistakes, smart enough to profit from them and strong enough to correct them. -- Probably by John C. Maxwell |
|
From: highclass99 <hig...@gm...> - 2018-09-25 02:28:22
|
Thanks for the comment. Of note, I am doing over 600 million pageviews(reference data google analytics, so probably more considering bots and ad blockers blocking analytics) using the "nginx <-> static files nginx <-> apache modsecurity proxy <-> nginx <-> dynamic files(fastcgi)" setup. Regarding your comment "There are a lot of nginxes that could be removed from your setup", Actually it is a single nginx instance. What I figured works well is receive the initial traffic to nginx, then nginxs sends only the dynamic traffic to apache modsecurity proxy(which is prefork at this time), and then the apache connects to the same nginx again to get the dynamic files. It's a weird setup, but never has caused problems yet. I got the idea for the setup, while reading that Cloudflare in the past also used modsecurity with apache for there WAF before they patched nginx with a modsecurity compatible lua based nginx. The reason I selected prefork is because I think modsecurity is CPU bound in my setup, not IO bound like common static or proxing requests. Therefore my theory was that is would actually be harmful if I used event models. On Mon, Sep 24, 2018 at 5:26 PM Christian Folini < chr...@ne...> wrote: > Hello highclass99, > > There are a lot of nginxes that could be removed from your setup but that's > not the question you are asking. > > I do not know anybody who runs ModSec on prefork Apache, the event MPM is > clearly the standard these days. With that being said, I do not have the > perf numbers. If you do compare them, please be sure to share. > > As for ModSec3 on NGINX: I think it's a lot less buggy than it used to be. > Performance and a few isolated missing features are an issue though. > > You may want to keep an eye on this meta issue: > https://github.com/SpiderLabs/ModSecurity/issues/1734 > > Good luck, > > Christian > > > On Mon, Sep 24, 2018 at 04:35:35PM +0900, highclass99 wrote: > > Hello, > > > > I run a > > nginx <-> static files > > nginx <-> apache modsecurity proxy <-> nginx <-> dynamic files(fastcgi) > > > > configuration. > > > > So, apache is only 100% for WAF. > > In this case my theory was that since apache modsecurity is probably not > io > > bound but cpu bound, I set the apache MPM as prefork. > > This apache instance handles thousands of requests/sec. > > > > I could not find any good information on whether this is optimal > > performance wise. > > > > Performance wise is this a better choice than worker or event MPM, when > > considering the apache is 100% only modsecurity requests? > > > > Also, I used the above model because nginx modsecurity was too buggy in > the > > past, I am considering using modsecurity 3 with nginx. In that case > would > > it be optimal to increase nginx worker instances since modsecurity would > > probably be cpu bound? > > > > _______________________________________________ > > 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/ > |
139 messages has been excluded from this view by a project administrator.
