mod-security-users Mailing List for ModSecurity (Page 2)
Brought to you by:
victorhora,
zimmerletw
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(17) |
Aug
(7) |
Sep
(8) |
Oct
(11) |
Nov
(14) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(46) |
Feb
(14) |
Mar
(20) |
Apr
(48) |
May
(15) |
Jun
(20) |
Jul
(36) |
Aug
(24) |
Sep
(31) |
Oct
(28) |
Nov
(23) |
Dec
(12) |
2005 |
Jan
(69) |
Feb
(61) |
Mar
(82) |
Apr
(53) |
May
(26) |
Jun
(71) |
Jul
(27) |
Aug
(52) |
Sep
(28) |
Oct
(49) |
Nov
(104) |
Dec
(74) |
2006 |
Jan
(61) |
Feb
(148) |
Mar
(82) |
Apr
(139) |
May
(65) |
Jun
(116) |
Jul
(92) |
Aug
(101) |
Sep
(84) |
Oct
(103) |
Nov
(174) |
Dec
(102) |
2007 |
Jan
(166) |
Feb
(161) |
Mar
(181) |
Apr
(152) |
May
(192) |
Jun
(250) |
Jul
(127) |
Aug
(165) |
Sep
(97) |
Oct
(135) |
Nov
(206) |
Dec
(56) |
2008 |
Jan
(160) |
Feb
(135) |
Mar
(98) |
Apr
(89) |
May
(115) |
Jun
(95) |
Jul
(188) |
Aug
(167) |
Sep
(153) |
Oct
(84) |
Nov
(82) |
Dec
(85) |
2009 |
Jan
(139) |
Feb
(133) |
Mar
(128) |
Apr
(105) |
May
(135) |
Jun
(79) |
Jul
(92) |
Aug
(134) |
Sep
(73) |
Oct
(112) |
Nov
(159) |
Dec
(80) |
2010 |
Jan
(100) |
Feb
(116) |
Mar
(130) |
Apr
(59) |
May
(88) |
Jun
(59) |
Jul
(69) |
Aug
(67) |
Sep
(82) |
Oct
(76) |
Nov
(59) |
Dec
(34) |
2011 |
Jan
(84) |
Feb
(74) |
Mar
(81) |
Apr
(94) |
May
(188) |
Jun
(72) |
Jul
(118) |
Aug
(109) |
Sep
(111) |
Oct
(80) |
Nov
(51) |
Dec
(44) |
2012 |
Jan
(80) |
Feb
(123) |
Mar
(46) |
Apr
(12) |
May
(40) |
Jun
(62) |
Jul
(95) |
Aug
(66) |
Sep
(65) |
Oct
(53) |
Nov
(42) |
Dec
(60) |
2013 |
Jan
(96) |
Feb
(96) |
Mar
(108) |
Apr
(72) |
May
(115) |
Jun
(111) |
Jul
(114) |
Aug
(87) |
Sep
(93) |
Oct
(97) |
Nov
(104) |
Dec
(82) |
2014 |
Jan
(96) |
Feb
(77) |
Mar
(71) |
Apr
(40) |
May
(48) |
Jun
(78) |
Jul
(54) |
Aug
(44) |
Sep
(58) |
Oct
(79) |
Nov
(51) |
Dec
(52) |
2015 |
Jan
(55) |
Feb
(59) |
Mar
(48) |
Apr
(40) |
May
(45) |
Jun
(63) |
Jul
(36) |
Aug
(49) |
Sep
(35) |
Oct
(58) |
Nov
(21) |
Dec
(47) |
2016 |
Jan
(35) |
Feb
(81) |
Mar
(43) |
Apr
(41) |
May
(77) |
Jun
(52) |
Jul
(39) |
Aug
(34) |
Sep
(107) |
Oct
(67) |
Nov
(54) |
Dec
(20) |
2017 |
Jan
(99) |
Feb
(37) |
Mar
(86) |
Apr
(47) |
May
(57) |
Jun
(55) |
Jul
(34) |
Aug
(31) |
Sep
(16) |
Oct
(49) |
Nov
(53) |
Dec
(33) |
2018 |
Jan
(25) |
Feb
(11) |
Mar
(79) |
Apr
(77) |
May
(5) |
Jun
(19) |
Jul
(17) |
Aug
(7) |
Sep
(13) |
Oct
(22) |
Nov
(13) |
Dec
(68) |
2019 |
Jan
(44) |
Feb
(17) |
Mar
(40) |
Apr
(39) |
May
(18) |
Jun
(14) |
Jul
(20) |
Aug
(31) |
Sep
(11) |
Oct
(35) |
Nov
(3) |
Dec
(10) |
2020 |
Jan
(32) |
Feb
(16) |
Mar
(10) |
Apr
(22) |
May
(2) |
Jun
(34) |
Jul
(1) |
Aug
(8) |
Sep
(36) |
Oct
(16) |
Nov
(13) |
Dec
(10) |
2021 |
Jan
(16) |
Feb
(23) |
Mar
(45) |
Apr
(28) |
May
(6) |
Jun
(17) |
Jul
(8) |
Aug
(1) |
Sep
(2) |
Oct
(35) |
Nov
|
Dec
(5) |
2022 |
Jan
|
Feb
(17) |
Mar
(23) |
Apr
(23) |
May
(9) |
Jun
(8) |
Jul
|
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(16) |
Dec
(4) |
2023 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2024 |
Jan
(7) |
Feb
(13) |
Mar
(17) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Hans M. <mo...@ma...> - 2024-02-07 22:15:46
|
Dear All, Over years I am using modsec and Apache with mlogc sending the alerts to waf-fle. With the last upgrade to Debian bookworm and PHP 8.2 waf-fle by klaubert doesn't work any more. Actually I am wondering how long it was running as the last update is 10 years ago. Now I am looking for an alternative to view the alert logs. I liked waf-fle as it didn't use a lot of resources. Is there something similar available ? // Hans -- |
From: <az...@po...> - 2024-02-05 11:35:18
|
Hi, for others: this was answered on github, see: https://github.com/coreruleset/coreruleset/issues/3527 azurit Citát Beckert via mod-security-users <mod...@li...>: > Hello, > > we are running nginx with ModSecurity 3.0.9 and rule set 3.2.0. > > Our user are sending POST requests with content-type > application/fhir+json > application/fhir+json; charset=utf-8 > application/fhir+json; charset=iso8859-1 > > To enable the Json request body parser we added this rule > # Enable JSON request body parser for application/fhir+json. > SecRule REQUEST_HEADERS:Content-Type "^application/.+[+]json.*$" \ > > "id:'100',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON" > > But somehow the charset is not considered by the Json parser. > If a POST is done with > content-type: application/fhir+json; charset=iso8859-1 > and with some iso8859-1 characters in the json body, ModSecurity > can't parse the requests and returns an error > > [14] tcp.0: [[1706742332.054460688, {}], {"date"=>1706742329.475638, > "log"=>"2024/01/31 23:05:29 [error] > 3588367#3588367: *26426370 [client 128.65.209.32] ModSecurity: > Access denied with code 400 (phase 2). Matched "Operator > `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' > ) [file "/etc/nginx/modsec/modsecurity.conf"] [line > "54"] [id "200002"] [rev ""] [msg "Failed to parse request body."] > [data "JSON parsing error: lexical error: invalid > bytes in UTF8 string.\x0a"] [severity "2"] [ver ""] [maturity "0"] > [accuracy "0"] > > ModSecurity considers the body as UTF8. > > How to convince the Json parser to parse it as ido8859-1 as stated > in the content-type? > > Uwe > > > _______________________________________________ > 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...> - 2024-02-03 06:39:14
|
Thanks for letting us know. And glad you sorted this out. Best, Christian On Sat, Feb 03, 2024 at 10:15:59AM +0530, homesh joshi wrote: > Dear All, > > This is resolved. found issue with the Backend web server not responding > intermittently. > No issues with apache or modsec. > > Thanks for all the help. > > Thanks, > Homesh > > On Mon, Jan 29, 2024 at 1:18 PM Christian Folini < > chr...@ne...> wrote: > > > Hey Homesh, > > > > This is very much an Apache question. Please address it to the Apache > > user's mailinglist or some other Apache forum. > > > > With that being said, it's a very odd behavior, I have never see. > > > > Best, > > > > Christian > > > > On Mon, Jan 29, 2024 at 12:31:13PM +0530, homesh joshi wrote: > > > Hi All, > > > > > > I am not sure if this is a modsec issue as I have tested it by disabling > > > the modsec still I face this issue. > > > I have apache setup in reverse proxy configuration with proxy timeout set > > > as 20 sec. > > > for one website request for /favicon.ico takes 20 sec. if I reduce the > > > proxy timeout to 2 sec then request for favicon.ico takes 2 sec. I put > > the > > > proxy module log level to trace 8 and apache log level to debug. but > > still > > > i am not able to find why apache waits for timeout. Attached are the logs > > > for your reference. > > > > > > Thanks in advance. > > > Homesh > > > > > [Thu Jan 25 15:47:22.967833 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(508): AH00831: socache_shmcb_store > > (0x61 -> subcache 1) > > > [Thu Jan 25 15:47:22.967900 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(862): AH00847: insert happened at > > idx=29, data=(6525:6557) > > > [Thu Jan 25 15:47:22.967923 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(865): AH00848: finished insert, > > subcache: idx_pos/idx_used=25/5, > > > data_pos/data_used=5638/1084 > > > [Thu Jan 25 15:47:22.967927 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(530): AH00834: leaving > > socache_shmcb_store successfully > > > [Thu Jan 25 15:47:22.968048 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(508): AH00831: socache_shmcb_store > > (0xab -> subcache 11) > > > [Thu Jan 25 15:47:22.968062 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(862): AH00847: insert happened at > > idx=26, data=(5857:5889) > > > [Thu Jan 25 15:47:22.968067 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(865): AH00848: finished insert, > > subcache: idx_pos/idx_used=22/5, > > > data_pos/data_used=4954/1099 > > > [Thu Jan 25 15:47:22.968071 2024] [socache_shmcb:debug] [pid 5731:tid > > 140199434626624] mod_socache_shmcb.c(530): AH00834: leaving > > socache_shmcb_store successfully > > > [Thu Jan 25 15:47:22.969591 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_kernel.c(415): [remote 1.2.3.4:58139] > > AH02034: Subsequent (No.2) HTTPS request > > > received for child 5394 (server play.lvu:443) > > > [Thu Jan 25 15:47:22.971124 2024] [proxy:trace2] [pid 5731:tid > > 140200633919040] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > > attempting to match URI path '/favic > > > on.ico' against prefix '/error/' for proxying > > > [Thu Jan 25 15:47:22.971161 2024] [proxy:trace2] [pid 5731:tid > > 140200633919040] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > > attempting to match URI path '/favic > > > on.ico' against prefix '/' for proxying > > > [Thu Jan 25 15:47:22.971167 2024] [proxy:trace1] [pid 5731:tid > > 140200633919040] mod_proxy.c(998): [remote 1.2.3.4:58139] AH03464: URI > > path '/favicon.ico' matches prox > > > y handler 'proxy: > > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com:443/favicon.ico' > > > [Thu Jan 25 15:47:22.971190 2024] [authz_core:debug] [pid 5731:tid > > 140200633919040] mod_authz_core.c(843): [remote 1.2.3.4:58139] AH01628: > > authorization result: grant > > > ed (no directives) > > > [Thu Jan 25 15:47:22.975603 2024] [proxy:trace2] [pid 5731:tid > > 140200633919040] proxy_util.c(2335): [remote 1.2.3.4:58139] https: found > > worker https://play-lvu-20510 > > > 2675.ap-south-1.elb.amazonaws.com/ for > > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico > > > [Thu Jan 25 15:47:22.975651 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] mod_proxy.c(1503): [remote 1.2.3.4:58139] AH01143: > > Running scheme https handler (attemp > > > t 0) > > > [Thu Jan 25 15:47:22.975660 2024] [proxy_fcgi:debug] [pid 5731:tid > > 140200633919040] mod_proxy_fcgi.c(1054): [remote 1.2.3.4:58139] AH01076: > > url: https://play-lvu-205 > > > 102675.ap-south-1.elb.amazonaws.com/favicon.ico proxyname: (null) > > proxyport: 0 > > > [Thu Jan 25 15:47:22.975666 2024] [proxy_fcgi:debug] [pid 5731:tid > > 140200633919040] mod_proxy_fcgi.c(1059): [remote 1.2.3.4:58139] AH01077: > > declining URL https://play > > > -lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico > > > [Thu Jan 25 15:47:22.975682 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(2531): AH00942: https: has acquired > > connection for (play-lvu-205133111.ap-south > > > -1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:22.975694 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(2587): [remote 1.2.3.4:58139] AH00944: > > connecting https://play-lvu-205102 > > > 675.ap-south-1.elb.amazonaws.com/favicon.ico to > > play-lvu-205133111.ap-south-1.elb.amazonaws.com:443 > > > [Thu Jan 25 15:47:23.019184 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(2810): [remote 1.2.3.4:58139] AH00947: > > connected /favicon.ico to play-lvu > > > -205133111.ap-south-1.elb.amazonaws.com:443 > > > [Thu Jan 25 15:47:23.019277 2024] [proxy:trace2] [pid 5731:tid > > 140200633919040] proxy_util.c(3244): https: fam 2 socket created to connect > > to play-lvu-205133111.ap-south-1 > > > .elb.amazonaws.com > > > [Thu Jan 25 15:47:43.039441 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(3267): (70007)The timeout specified has > > expired: AH00957: https: attempt to conn > > > ect to 3.111.227.162:443 ( > > play-lvu-205133111.ap-south-1.elb.amazonaws.com) failed > > > [Thu Jan 25 15:47:43.039558 2024] [proxy:trace2] [pid 5731:tid > > 140200633919040] proxy_util.c(3244): https: fam 2 socket created to connect > > to play-lvu-205133111.ap-south-1 > > > .elb.amazonaws.com > > > [Thu Jan 25 15:47:43.057570 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(3276): AH02824: https: connection established > > with 3.109.6.57:443 (play-lvu-205 > > > 102675.ap-south-1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.057649 2024] [proxy:trace1] [pid 5731:tid > > 140200633919040] proxy_util.c(3450): [remote 3.109.6.57:443] https: set > > SNI to play.lvu for (play-lvu-20510 > > > 2675.ap-south-1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.057655 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(3462): AH00962: https: connection complete to > > 3.111.227.162:443 (play-lvu-20510 > > > 2675.ap-south-1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.057663 2024] [qos:debug] [pid 5731:tid > > 140200633919040] apache2/mod_qos.c(8587): mod_qos(): skip processing of > > outgoing connection 3.109.6.57<->165.232 > > > .187.180 > > > [Thu Jan 25 15:47:43.057669 2024] [ssl:info] [pid 5731:tid > > 140200633919040] [remote 3.109.6.57:443] AH01964: Connection to child 0 > > established (server play.lvu:443) > > > [Thu Jan 25 15:47:43.078549 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > > AH02275: Certificate Verification, depth 3, > > > CRL checking mode: none (0) [subject: CN=Starfield Services Root > > Certificate Authority - G2,O=Starfield Technologies\\, > > Inc.,L=Scottsdale,ST=Arizona,C=US / issuer: OU=Starf > > > ield Class 2 Certification Authority,O=Starfield Technologies\\, > > Inc.,C=US / serial: A70E4A4C3482B77F / notbefore: Sep 2 00:00:00 2009 GMT > > / notafter: Jun 28 17:39:16 2034 > > > GMT] > > > [Thu Jan 25 15:47:43.078695 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > > AH02275: Certificate Verification, depth 2, > > > CRL checking mode: none (0) [subject: CN=Amazon Root CA 1,O=Amazon,C=US > > / issuer: CN=Starfield Services Root Certificate Authority - G2,O=Starfield > > Technologies\\, Inc.,L=S > > > cottsdale,ST=Arizona,C=US / serial: > > 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6 / notbefore: May 25 12:00:00 2015 > > GMT / notafter: Dec 31 01:00:00 2037 GMT] > > > [Thu Jan 25 15:47:43.078779 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > > AH02275: Certificate Verification, depth 1, > > > CRL checking mode: none (0) [subject: CN=Amazon RSA 2048 > > M01,O=Amazon,C=US / issuer: CN=Amazon Root CA 1,O=Amazon,C=US / serial: > > 077312380B9D6688A33B1ED9BF9CCDA68E0E0F / no > > > tbefore: Aug 23 22:21:28 2022 GMT / notafter: Aug 23 22:21:28 2030 GMT] > > > [Thu Jan 25 15:47:43.078863 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > > AH02275: Certificate Verification, depth 0, > > > CRL checking mode: none (0) [subject: CN=play.lvu / issuer: CN=Amazon > > RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / > > notbefore: Oct 11 00:00:00 20 > > > 23 GMT / notafter: Nov 8 23:59:59 2024 GMT] > > > [Thu Jan 25 15:47:43.079137 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_kernel.c(2254): [remote 3.109.6.57:443] > > AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_ > > > 128_GCM_SHA256 (128/128 bits) > > > [Thu Jan 25 15:47:43.079199 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_util_ssl.c(451): AH02412: [play.lvu:443] Cert matches > > for name 'play.lvu' [subject: CN=kl > > > ay.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: > > 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 2023 GMT / > > notafter: Nov 8 23:59:59 2024 GMT > > > ] > > > [Thu Jan 25 15:47:43.100903 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(2546): AH00943: https: has released > > connection for (play-lvu-205133111.ap-south > > > -1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.100989 2024] [ssl:debug] [pid 5731:tid > > 140200633919040] ssl_engine_io.c(1147): [remote 3.109.6.57:443] AH02001: > > Connection closed to child 0 with stand > > > ard shutdown (server play.lvu:443) > > > [Thu Jan 25 15:47:43.101088 2024] [proxy:debug] [pid 5731:tid > > 140200633919040] proxy_util.c(3386): [remote 3.109.6.57:443] AH02642: > > proxy: connection shutdown > > > [Thu Jan 25 15:47:43.863505 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_kernel.c(415): [remote 1.2.3.4:58139] > > AH02034: Subsequent (No.2) HTTPS request > > > received for child 1808 (server play.lvu:443), referer: > > https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.865077 2024] [proxy:trace2] [pid 5731:tid > > 140200650737216] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > > attempting to match URI path '/favic > > > on.ico' against prefix '/error/' for proxying, referer: > > https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.865165 2024] [proxy:trace2] [pid 5731:tid > > 140200650737216] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > > attempting to match URI path '/favic > > > on.ico' against prefix '/' for proxying, referer: > > https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.865192 2024] [proxy:trace1] [pid 5731:tid > > 140200650737216] mod_proxy.c(998): [remote 1.2.3.4:58139] AH03464: URI > > path '/favicon.ico' matches prox > > > y handler 'proxy: > > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com:443/favicon.ico', > > referer: https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.865231 2024] [authz_core:debug] [pid 5731:tid > > 140200650737216] mod_authz_core.c(843): [remote 1.2.3.4:58139] AH01628: > > authorization result: grant > > > ed (no directives), referer: https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868082 2024] [proxy:trace2] [pid 5731:tid > > 140200650737216] proxy_util.c(2335): [remote 1.2.3.4:58139] https: found > > worker https://play-lvu-20510 > > > 2675.ap-south-1.elb.amazonaws.com/ for > > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico, > > referer: https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868164 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] mod_proxy.c(1503): [remote 1.2.3.4:58139] AH01143: > > Running scheme https handler (attemp > > > t 0), referer: https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868198 2024] [proxy_fcgi:debug] [pid 5731:tid > > 140200650737216] mod_proxy_fcgi.c(1054): [remote 1.2.3.4:58139] AH01076: > > url: https://play-lvu-205 > > > 102675.ap-south-1.elb.amazonaws.com/favicon.ico proxyname: (null) > > proxyport: 0, referer: https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868223 2024] [proxy_fcgi:debug] [pid 5731:tid > > 140200650737216] mod_proxy_fcgi.c(1059): [remote 1.2.3.4:58139] AH01077: > > declining URL https://play > > > -lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico, referer: > > https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868248 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(2531): AH00942: https: has acquired > > connection for (play-lvu-205133111.ap-south > > > -1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.868273 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(2587): [remote 1.2.3.4:58139] AH00944: > > connecting https://play-lvu-205102 > > > 675.ap-south-1.elb.amazonaws.com/favicon.ico to > > play-lvu-205133111.ap-south-1.elb.amazonaws.com:443, referer: > > https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868630 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(2810): [remote 1.2.3.4:58139] AH00947: > > connected /favicon.ico to play-lvu > > > -205133111.ap-south-1.elb.amazonaws.com:443, referer: > > https://play.lvu/favicon.ico > > > [Thu Jan 25 15:47:43.868704 2024] [proxy:trace2] [pid 5731:tid > > 140200650737216] proxy_util.c(3244): https: fam 2 socket created to connect > > to play-lvu-205133111.ap-south-1 > > > .elb.amazonaws.com > > > [Thu Jan 25 15:47:43.894557 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(3276): AH02824: https: connection established > > with 3.109.172.68:443 (play-lvu-2 > > > 05102675.ap-south-1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.894681 2024] [proxy:trace1] [pid 5731:tid > > 140200650737216] proxy_util.c(3450): [remote 3.109.172.68:443] https: set > > SNI to play.lvu for (play-lvu-205 > > > 102675.ap-south-1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.894708 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(3462): AH00962: https: connection complete to > > 3.109.172.68:443 (play-lvu-205102 > > > 675.ap-south-1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.894748 2024] [qos:debug] [pid 5731:tid > > 140200650737216] apache2/mod_qos.c(8587): mod_qos(): skip processing of > > outgoing connection 3.109.172.68<->165.2 > > > 32.187.180 > > > [Thu Jan 25 15:47:43.894770 2024] [ssl:info] [pid 5731:tid > > 140200650737216] [remote 3.109.172.68:443] AH01964: Connection to child 0 > > established (server play.lvu:443) > > > [Thu Jan 25 15:47:43.923819 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > > AH02275: Certificate Verification, depth 3 > > > , CRL checking mode: none (0) [subject: CN=Starfield Services Root > > Certificate Authority - G2,O=Starfield Technologies\\, > > Inc.,L=Scottsdale,ST=Arizona,C=US / issuer: OU=Sta > > > rfield Class 2 Certification Authority,O=Starfield Technologies\\, > > Inc.,C=US / serial: A70E4A4C3482B77F / notbefore: Sep 2 00:00:00 2009 GMT > > / notafter: Jun 28 17:39:16 20 > > > 34 GMT] > > > [Thu Jan 25 15:47:43.924033 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > > AH02275: Certificate Verification, depth 2 > > > , CRL checking mode: none (0) [subject: CN=Amazon Root CA > > 1,O=Amazon,C=US / issuer: CN=Starfield Services Root Certificate Authority > > - G2,O=Starfield Technologies\\, Inc.,L > > > =Scottsdale,ST=Arizona,C=US / serial: > > 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6 / notbefore: May 25 12:00:00 2015 > > GMT / notafter: Dec 31 01:00:00 2037 GMT] > > > [Thu Jan 25 15:47:43.924124 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > > AH02275: Certificate Verification, depth 1 > > > , CRL checking mode: none (0) [subject: CN=Amazon RSA 2048 > > M01,O=Amazon,C=US / issuer: CN=Amazon Root CA 1,O=Amazon,C=US / serial: > > 077312380B9D6688A33B1ED9BF9CCDA68E0E0F / > > > notbefore: Aug 23 22:21:28 2022 GMT / notafter: Aug 23 22:21:28 2030 GMT] > > > [Thu Jan 25 15:47:43.924208 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > > AH02275: Certificate Verification, depth 0 > > > , CRL checking mode: none (0) [subject: CN=play.lvu / issuer: CN=Amazon > > RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / > > notbefore: Oct 11 00:00:00 > > > 2023 GMT / notafter: Nov 8 23:59:59 2024 GMT] > > > [Thu Jan 25 15:47:43.924468 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_kernel.c(2254): [remote 3.109.172.68:443] > > AH02041: Protocol: TLSv1.3, Cipher: TLS_AE > > > S_128_GCM_SHA256 (128/128 bits) > > > [Thu Jan 25 15:47:43.924535 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_util_ssl.c(451): AH02412: [play.lvu:443] Cert matches > > for name 'play.lvu' [subject: CN=kl > > > ay.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: > > 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 2023 GMT / > > notafter: Nov 8 23:59:59 2024 GMT > > > ] > > > [Thu Jan 25 15:47:43.959108 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(2546): AH00943: https: has released > > connection for (play-lvu-205133111.ap-south > > > -1.elb.amazonaws.com) > > > [Thu Jan 25 15:47:43.959261 2024] [ssl:debug] [pid 5731:tid > > 140200650737216] ssl_engine_io.c(1147): [remote 3.109.172.68:443] > > AH02001: Connection closed to child 0 with sta > > > ndard shutdown (server play.lvu:443) > > > [Thu Jan 25 15:47:43.959361 2024] [proxy:debug] [pid 5731:tid > > 140200650737216] proxy_util.c(3386): [remote 3.109.172.68:443] AH02642: > > proxy: connection shutdown > > > [Thu Jan 25 15:47:48.965114 2024] [ssl:debug] [pid 5731:tid > > 140199476590144] ssl_engine_io.c(1147): [client 1.2.3.4:58139] AH02001: > > Connection closed to child 16 with > > > standard shutdown (server play.lvu:443) > > > > > > > > > > > > ▸ > > > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ |
From: homesh j. <ho...@gm...> - 2024-02-03 04:46:21
|
Dear All, This is resolved. found issue with the Backend web server not responding intermittently. No issues with apache or modsec. Thanks for all the help. Thanks, Homesh On Mon, Jan 29, 2024 at 1:18 PM Christian Folini < chr...@ne...> wrote: > Hey Homesh, > > This is very much an Apache question. Please address it to the Apache > user's mailinglist or some other Apache forum. > > With that being said, it's a very odd behavior, I have never see. > > Best, > > Christian > > On Mon, Jan 29, 2024 at 12:31:13PM +0530, homesh joshi wrote: > > Hi All, > > > > I am not sure if this is a modsec issue as I have tested it by disabling > > the modsec still I face this issue. > > I have apache setup in reverse proxy configuration with proxy timeout set > > as 20 sec. > > for one website request for /favicon.ico takes 20 sec. if I reduce the > > proxy timeout to 2 sec then request for favicon.ico takes 2 sec. I put > the > > proxy module log level to trace 8 and apache log level to debug. but > still > > i am not able to find why apache waits for timeout. Attached are the logs > > for your reference. > > > > Thanks in advance. > > Homesh > > > [Thu Jan 25 15:47:22.967833 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(508): AH00831: socache_shmcb_store > (0x61 -> subcache 1) > > [Thu Jan 25 15:47:22.967900 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(862): AH00847: insert happened at > idx=29, data=(6525:6557) > > [Thu Jan 25 15:47:22.967923 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(865): AH00848: finished insert, > subcache: idx_pos/idx_used=25/5, > > data_pos/data_used=5638/1084 > > [Thu Jan 25 15:47:22.967927 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(530): AH00834: leaving > socache_shmcb_store successfully > > [Thu Jan 25 15:47:22.968048 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(508): AH00831: socache_shmcb_store > (0xab -> subcache 11) > > [Thu Jan 25 15:47:22.968062 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(862): AH00847: insert happened at > idx=26, data=(5857:5889) > > [Thu Jan 25 15:47:22.968067 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(865): AH00848: finished insert, > subcache: idx_pos/idx_used=22/5, > > data_pos/data_used=4954/1099 > > [Thu Jan 25 15:47:22.968071 2024] [socache_shmcb:debug] [pid 5731:tid > 140199434626624] mod_socache_shmcb.c(530): AH00834: leaving > socache_shmcb_store successfully > > [Thu Jan 25 15:47:22.969591 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_kernel.c(415): [remote 1.2.3.4:58139] > AH02034: Subsequent (No.2) HTTPS request > > received for child 5394 (server play.lvu:443) > > [Thu Jan 25 15:47:22.971124 2024] [proxy:trace2] [pid 5731:tid > 140200633919040] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > attempting to match URI path '/favic > > on.ico' against prefix '/error/' for proxying > > [Thu Jan 25 15:47:22.971161 2024] [proxy:trace2] [pid 5731:tid > 140200633919040] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > attempting to match URI path '/favic > > on.ico' against prefix '/' for proxying > > [Thu Jan 25 15:47:22.971167 2024] [proxy:trace1] [pid 5731:tid > 140200633919040] mod_proxy.c(998): [remote 1.2.3.4:58139] AH03464: URI > path '/favicon.ico' matches prox > > y handler 'proxy: > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com:443/favicon.ico' > > [Thu Jan 25 15:47:22.971190 2024] [authz_core:debug] [pid 5731:tid > 140200633919040] mod_authz_core.c(843): [remote 1.2.3.4:58139] AH01628: > authorization result: grant > > ed (no directives) > > [Thu Jan 25 15:47:22.975603 2024] [proxy:trace2] [pid 5731:tid > 140200633919040] proxy_util.c(2335): [remote 1.2.3.4:58139] https: found > worker https://play-lvu-20510 > > 2675.ap-south-1.elb.amazonaws.com/ for > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico > > [Thu Jan 25 15:47:22.975651 2024] [proxy:debug] [pid 5731:tid > 140200633919040] mod_proxy.c(1503): [remote 1.2.3.4:58139] AH01143: > Running scheme https handler (attemp > > t 0) > > [Thu Jan 25 15:47:22.975660 2024] [proxy_fcgi:debug] [pid 5731:tid > 140200633919040] mod_proxy_fcgi.c(1054): [remote 1.2.3.4:58139] AH01076: > url: https://play-lvu-205 > > 102675.ap-south-1.elb.amazonaws.com/favicon.ico proxyname: (null) > proxyport: 0 > > [Thu Jan 25 15:47:22.975666 2024] [proxy_fcgi:debug] [pid 5731:tid > 140200633919040] mod_proxy_fcgi.c(1059): [remote 1.2.3.4:58139] AH01077: > declining URL https://play > > -lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico > > [Thu Jan 25 15:47:22.975682 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(2531): AH00942: https: has acquired > connection for (play-lvu-205133111.ap-south > > -1.elb.amazonaws.com) > > [Thu Jan 25 15:47:22.975694 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(2587): [remote 1.2.3.4:58139] AH00944: > connecting https://play-lvu-205102 > > 675.ap-south-1.elb.amazonaws.com/favicon.ico to > play-lvu-205133111.ap-south-1.elb.amazonaws.com:443 > > [Thu Jan 25 15:47:23.019184 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(2810): [remote 1.2.3.4:58139] AH00947: > connected /favicon.ico to play-lvu > > -205133111.ap-south-1.elb.amazonaws.com:443 > > [Thu Jan 25 15:47:23.019277 2024] [proxy:trace2] [pid 5731:tid > 140200633919040] proxy_util.c(3244): https: fam 2 socket created to connect > to play-lvu-205133111.ap-south-1 > > .elb.amazonaws.com > > [Thu Jan 25 15:47:43.039441 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(3267): (70007)The timeout specified has > expired: AH00957: https: attempt to conn > > ect to 3.111.227.162:443 ( > play-lvu-205133111.ap-south-1.elb.amazonaws.com) failed > > [Thu Jan 25 15:47:43.039558 2024] [proxy:trace2] [pid 5731:tid > 140200633919040] proxy_util.c(3244): https: fam 2 socket created to connect > to play-lvu-205133111.ap-south-1 > > .elb.amazonaws.com > > [Thu Jan 25 15:47:43.057570 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(3276): AH02824: https: connection established > with 3.109.6.57:443 (play-lvu-205 > > 102675.ap-south-1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.057649 2024] [proxy:trace1] [pid 5731:tid > 140200633919040] proxy_util.c(3450): [remote 3.109.6.57:443] https: set > SNI to play.lvu for (play-lvu-20510 > > 2675.ap-south-1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.057655 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(3462): AH00962: https: connection complete to > 3.111.227.162:443 (play-lvu-20510 > > 2675.ap-south-1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.057663 2024] [qos:debug] [pid 5731:tid > 140200633919040] apache2/mod_qos.c(8587): mod_qos(): skip processing of > outgoing connection 3.109.6.57<->165.232 > > .187.180 > > [Thu Jan 25 15:47:43.057669 2024] [ssl:info] [pid 5731:tid > 140200633919040] [remote 3.109.6.57:443] AH01964: Connection to child 0 > established (server play.lvu:443) > > [Thu Jan 25 15:47:43.078549 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > AH02275: Certificate Verification, depth 3, > > CRL checking mode: none (0) [subject: CN=Starfield Services Root > Certificate Authority - G2,O=Starfield Technologies\\, > Inc.,L=Scottsdale,ST=Arizona,C=US / issuer: OU=Starf > > ield Class 2 Certification Authority,O=Starfield Technologies\\, > Inc.,C=US / serial: A70E4A4C3482B77F / notbefore: Sep 2 00:00:00 2009 GMT > / notafter: Jun 28 17:39:16 2034 > > GMT] > > [Thu Jan 25 15:47:43.078695 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > AH02275: Certificate Verification, depth 2, > > CRL checking mode: none (0) [subject: CN=Amazon Root CA 1,O=Amazon,C=US > / issuer: CN=Starfield Services Root Certificate Authority - G2,O=Starfield > Technologies\\, Inc.,L=S > > cottsdale,ST=Arizona,C=US / serial: > 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6 / notbefore: May 25 12:00:00 2015 > GMT / notafter: Dec 31 01:00:00 2037 GMT] > > [Thu Jan 25 15:47:43.078779 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > AH02275: Certificate Verification, depth 1, > > CRL checking mode: none (0) [subject: CN=Amazon RSA 2048 > M01,O=Amazon,C=US / issuer: CN=Amazon Root CA 1,O=Amazon,C=US / serial: > 077312380B9D6688A33B1ED9BF9CCDA68E0E0F / no > > tbefore: Aug 23 22:21:28 2022 GMT / notafter: Aug 23 22:21:28 2030 GMT] > > [Thu Jan 25 15:47:43.078863 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] > AH02275: Certificate Verification, depth 0, > > CRL checking mode: none (0) [subject: CN=play.lvu / issuer: CN=Amazon > RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / > notbefore: Oct 11 00:00:00 20 > > 23 GMT / notafter: Nov 8 23:59:59 2024 GMT] > > [Thu Jan 25 15:47:43.079137 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_kernel.c(2254): [remote 3.109.6.57:443] > AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_ > > 128_GCM_SHA256 (128/128 bits) > > [Thu Jan 25 15:47:43.079199 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_util_ssl.c(451): AH02412: [play.lvu:443] Cert matches > for name 'play.lvu' [subject: CN=kl > > ay.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: > 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 2023 GMT / > notafter: Nov 8 23:59:59 2024 GMT > > ] > > [Thu Jan 25 15:47:43.100903 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(2546): AH00943: https: has released > connection for (play-lvu-205133111.ap-south > > -1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.100989 2024] [ssl:debug] [pid 5731:tid > 140200633919040] ssl_engine_io.c(1147): [remote 3.109.6.57:443] AH02001: > Connection closed to child 0 with stand > > ard shutdown (server play.lvu:443) > > [Thu Jan 25 15:47:43.101088 2024] [proxy:debug] [pid 5731:tid > 140200633919040] proxy_util.c(3386): [remote 3.109.6.57:443] AH02642: > proxy: connection shutdown > > [Thu Jan 25 15:47:43.863505 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_kernel.c(415): [remote 1.2.3.4:58139] > AH02034: Subsequent (No.2) HTTPS request > > received for child 1808 (server play.lvu:443), referer: > https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.865077 2024] [proxy:trace2] [pid 5731:tid > 140200650737216] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > attempting to match URI path '/favic > > on.ico' against prefix '/error/' for proxying, referer: > https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.865165 2024] [proxy:trace2] [pid 5731:tid > 140200650737216] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: > attempting to match URI path '/favic > > on.ico' against prefix '/' for proxying, referer: > https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.865192 2024] [proxy:trace1] [pid 5731:tid > 140200650737216] mod_proxy.c(998): [remote 1.2.3.4:58139] AH03464: URI > path '/favicon.ico' matches prox > > y handler 'proxy: > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com:443/favicon.ico', > referer: https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.865231 2024] [authz_core:debug] [pid 5731:tid > 140200650737216] mod_authz_core.c(843): [remote 1.2.3.4:58139] AH01628: > authorization result: grant > > ed (no directives), referer: https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868082 2024] [proxy:trace2] [pid 5731:tid > 140200650737216] proxy_util.c(2335): [remote 1.2.3.4:58139] https: found > worker https://play-lvu-20510 > > 2675.ap-south-1.elb.amazonaws.com/ for > https://play-lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico, > referer: https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868164 2024] [proxy:debug] [pid 5731:tid > 140200650737216] mod_proxy.c(1503): [remote 1.2.3.4:58139] AH01143: > Running scheme https handler (attemp > > t 0), referer: https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868198 2024] [proxy_fcgi:debug] [pid 5731:tid > 140200650737216] mod_proxy_fcgi.c(1054): [remote 1.2.3.4:58139] AH01076: > url: https://play-lvu-205 > > 102675.ap-south-1.elb.amazonaws.com/favicon.ico proxyname: (null) > proxyport: 0, referer: https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868223 2024] [proxy_fcgi:debug] [pid 5731:tid > 140200650737216] mod_proxy_fcgi.c(1059): [remote 1.2.3.4:58139] AH01077: > declining URL https://play > > -lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico, referer: > https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868248 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(2531): AH00942: https: has acquired > connection for (play-lvu-205133111.ap-south > > -1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.868273 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(2587): [remote 1.2.3.4:58139] AH00944: > connecting https://play-lvu-205102 > > 675.ap-south-1.elb.amazonaws.com/favicon.ico to > play-lvu-205133111.ap-south-1.elb.amazonaws.com:443, referer: > https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868630 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(2810): [remote 1.2.3.4:58139] AH00947: > connected /favicon.ico to play-lvu > > -205133111.ap-south-1.elb.amazonaws.com:443, referer: > https://play.lvu/favicon.ico > > [Thu Jan 25 15:47:43.868704 2024] [proxy:trace2] [pid 5731:tid > 140200650737216] proxy_util.c(3244): https: fam 2 socket created to connect > to play-lvu-205133111.ap-south-1 > > .elb.amazonaws.com > > [Thu Jan 25 15:47:43.894557 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(3276): AH02824: https: connection established > with 3.109.172.68:443 (play-lvu-2 > > 05102675.ap-south-1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.894681 2024] [proxy:trace1] [pid 5731:tid > 140200650737216] proxy_util.c(3450): [remote 3.109.172.68:443] https: set > SNI to play.lvu for (play-lvu-205 > > 102675.ap-south-1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.894708 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(3462): AH00962: https: connection complete to > 3.109.172.68:443 (play-lvu-205102 > > 675.ap-south-1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.894748 2024] [qos:debug] [pid 5731:tid > 140200650737216] apache2/mod_qos.c(8587): mod_qos(): skip processing of > outgoing connection 3.109.172.68<->165.2 > > 32.187.180 > > [Thu Jan 25 15:47:43.894770 2024] [ssl:info] [pid 5731:tid > 140200650737216] [remote 3.109.172.68:443] AH01964: Connection to child 0 > established (server play.lvu:443) > > [Thu Jan 25 15:47:43.923819 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > AH02275: Certificate Verification, depth 3 > > , CRL checking mode: none (0) [subject: CN=Starfield Services Root > Certificate Authority - G2,O=Starfield Technologies\\, > Inc.,L=Scottsdale,ST=Arizona,C=US / issuer: OU=Sta > > rfield Class 2 Certification Authority,O=Starfield Technologies\\, > Inc.,C=US / serial: A70E4A4C3482B77F / notbefore: Sep 2 00:00:00 2009 GMT > / notafter: Jun 28 17:39:16 20 > > 34 GMT] > > [Thu Jan 25 15:47:43.924033 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > AH02275: Certificate Verification, depth 2 > > , CRL checking mode: none (0) [subject: CN=Amazon Root CA > 1,O=Amazon,C=US / issuer: CN=Starfield Services Root Certificate Authority > - G2,O=Starfield Technologies\\, Inc.,L > > =Scottsdale,ST=Arizona,C=US / serial: > 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6 / notbefore: May 25 12:00:00 2015 > GMT / notafter: Dec 31 01:00:00 2037 GMT] > > [Thu Jan 25 15:47:43.924124 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > AH02275: Certificate Verification, depth 1 > > , CRL checking mode: none (0) [subject: CN=Amazon RSA 2048 > M01,O=Amazon,C=US / issuer: CN=Amazon Root CA 1,O=Amazon,C=US / serial: > 077312380B9D6688A33B1ED9BF9CCDA68E0E0F / > > notbefore: Aug 23 22:21:28 2022 GMT / notafter: Aug 23 22:21:28 2030 GMT] > > [Thu Jan 25 15:47:43.924208 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] > AH02275: Certificate Verification, depth 0 > > , CRL checking mode: none (0) [subject: CN=play.lvu / issuer: CN=Amazon > RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / > notbefore: Oct 11 00:00:00 > > 2023 GMT / notafter: Nov 8 23:59:59 2024 GMT] > > [Thu Jan 25 15:47:43.924468 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_kernel.c(2254): [remote 3.109.172.68:443] > AH02041: Protocol: TLSv1.3, Cipher: TLS_AE > > S_128_GCM_SHA256 (128/128 bits) > > [Thu Jan 25 15:47:43.924535 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_util_ssl.c(451): AH02412: [play.lvu:443] Cert matches > for name 'play.lvu' [subject: CN=kl > > ay.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: > 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 2023 GMT / > notafter: Nov 8 23:59:59 2024 GMT > > ] > > [Thu Jan 25 15:47:43.959108 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(2546): AH00943: https: has released > connection for (play-lvu-205133111.ap-south > > -1.elb.amazonaws.com) > > [Thu Jan 25 15:47:43.959261 2024] [ssl:debug] [pid 5731:tid > 140200650737216] ssl_engine_io.c(1147): [remote 3.109.172.68:443] > AH02001: Connection closed to child 0 with sta > > ndard shutdown (server play.lvu:443) > > [Thu Jan 25 15:47:43.959361 2024] [proxy:debug] [pid 5731:tid > 140200650737216] proxy_util.c(3386): [remote 3.109.172.68:443] AH02642: > proxy: connection shutdown > > [Thu Jan 25 15:47:48.965114 2024] [ssl:debug] [pid 5731:tid > 140199476590144] ssl_engine_io.c(1147): [client 1.2.3.4:58139] AH02001: > Connection closed to child 16 with > > standard shutdown (server play.lvu:443) > > > > > > > > ▸ > > > > _______________________________________________ > > 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: Beckert <be...@gm...> - 2024-02-02 18:19:35
|
Hello, we are running nginx with ModSecurity 3.0.9 and rule set 3.2.0. Our user are sending POST requests with content-type application/fhir+json application/fhir+json; charset=utf-8 application/fhir+json; charset=iso8859-1 To enable the Json request body parser we added this rule # Enable JSON request body parser for application/fhir+json. SecRule REQUEST_HEADERS:Content-Type "^application/.+[+]json.*$" \ "id:'100',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON" But somehow the charset is not considered by the Json parser. If a POST is done with content-type: application/fhir+json; charset=iso8859-1 and with some iso8859-1 characters in the json body, ModSecurity can't parse the requests and returns an error [14] tcp.0: [[1706742332.054460688, {}], {"date"=>1706742329.475638, "log"=>"2024/01/31 23:05:29 [error] 3588367#3588367: *26426370 [client 128.65.209.32] ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsec/modsecurity.conf"] [line "54"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "JSON parsing error: lexical error: invalid bytes in UTF8 string.\x0a"] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] ModSecurity considers the body as UTF8. How to convince the Json parser to parse it as ido8859-1 as stated in the content-type? Uwe |
From: Ervin H. <ai...@gm...> - 2024-01-31 12:31:48
|
Hi, On Wed, Jan 31, 2024 at 03:17:38PM +0330, mahh m wrote: > Hi, > when I want to install modsecurity 3.0.12, by running build.sh these > warnings are displayed: warning: The macro `AC_TRY_LINK' is obsolete. > warning: The macro `AC_HEADER_STDC' is obsolete > warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete > warning: The macro `AC_TRY_COMPILE' is obsolete > > the warnings remain after running "autoupdate". > the version of "autoconf" is 2.71-2 (on ubuntu 22.04). unfortunately there are few obsolote macros in m4 files. As the most software, autotools is also constantly evolving, and this brings that few macros will be obsolote. Here is the full list for your version: https://www.gnu.org/software/autoconf/manual/autoconf-2.71/html_node/Obsolete-Macros.html > how can I resolve it? If *YOU* want to resolve it, you should replace the old macro by a new one. For eg. if you check the page above, there is a new suggested version: AC_LINK_IFELSE. So for eg. this patch solves the issue for AC_TRY_LINK: diff --git a/build/pcre.m4 b/build/pcre.m4 index f338aa50..edac7c7e 100644 --- a/build/pcre.m4 +++ b/build/pcre.m4 @@ -77,10 +77,11 @@ else CFLAGS="${PCRE_CFLAGS} ${CFLAGS}" LDFLAGS="${PCRE_LDADD} ${LDFLAGS}" LIBS="${PCRE_LDADD} ${LIBS}" - AC_TRY_LINK([ #include <pcre.h> ], - [ pcre_jit_exec(NULL, NULL, NULL, 0, 0, 0, NULL, 0, NULL); ], - [ pcre_jit_available=yes ], [:] - ) + AC_LINK_IFELSE( + [AC_LANG_PROGRAM([[ #include <pcre.h> ]], + [[ pcre_jit_exec(NULL, NULL, NULL, 0, 0, 0, NULL, 0, NULL); ]])], + [ pcre_jit_available=yes ], + [:]) if test "x$pcre_jit_available" = "xyes"; then AC_MSG_RESULT(yes) If you want to fix all of them, please send a PR here: https://github.com/owasp-modsecurity/ModSecurity/pulls If you don't want/can't cover this issue, please open an issue here: https://github.com/owasp-modsecurity/ModSecurity/issues/new?assignees=&labels=&projects=&template=bug-report-for-version-3-x.md&title= and we try to solve that soon. Thank you, a. |
From: mahh m <muh...@gm...> - 2024-01-31 11:43:47
|
Hi, when I want to install modsecurity 3.0.12, by running build.sh these warnings are displayed: warning: The macro `AC_TRY_LINK' is obsolete. warning: The macro `AC_HEADER_STDC' is obsolete warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete warning: The macro `AC_TRY_COMPILE' is obsolete the warnings remain after running "autoupdate". the version of "autoconf" is 2.71-2 (on ubuntu 22.04). how can I resolve it? |
From: Ervin H. <ai...@gm...> - 2024-01-30 16:35:16
|
Dear all, As you can see in my previous e-mail, the new OWASP ModSecurity team is happy to announce the release of ModSecurity / libModSecurity v3.0.12, the first release under the new organization. Version 3.0.12 fixes CVE 2024-1019, a security bug with HIGH severity on the ModSec 3 release line. Please find the complete advisory and and detailed information at https://owasp.org/www-project-modsecurity/tab_cves#cve-2024-1019-2024-01-30 The code of the release can be found at https://github.com/owasp-modsecurity/ModSecurity/releases/tag/v3.0.12 DigitalWave will publish pre-compiled binaries later tonight or tomorrow throughout the day at https://modsecurity.digitalwave.hu. I also try to upload the patched versions for Debian and Ubuntu systems. We advise all ModSecurity 3 users to upgrade to 3.0.12. A workaround for those stuck on lower versions is covered in the link shared above. Best, Christian Folini, Marc Stern and Ervin Hegedüs |
From: Ervin H. <ai...@gm...> - 2024-01-30 16:27:01
|
Dear ModSecurity users, ModSecurity is announcing the release of version 3.0.12. This version includes a bug fixes, see the release notes: ==%== Security impacting issue Change REQUEST_FILENAME and REQUEST_BASENAME behavior [Issue #3048 - @martinhsv, @theMiddleBlue, @theseion, @M4tteoP, @airween] WAF bypass of the ModSecurity v3 release line for path-based payloads by submitting a specially crafted request URL. For details, see CVE 2024-1019. Enhancements and bug fixes Set the minimum security protocol version (TLSv1.2) for SecRemoteRules [Issue security/code-scanning/2 - @airween] ==%== Additional information on the release, including the source (and hashes/signatures), is available at: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.12 Thanks to everybody who helped in this process: reporting issues, making comments and suggestions, sending patches, etc. Regards: Christian Folini, Marc Stern and Ervin Hegedüs |
From: Christian F. <chr...@ne...> - 2024-01-29 07:44:41
|
Hey Homesh, This is very much an Apache question. Please address it to the Apache user's mailinglist or some other Apache forum. With that being said, it's a very odd behavior, I have never see. Best, Christian On Mon, Jan 29, 2024 at 12:31:13PM +0530, homesh joshi wrote: > Hi All, > > I am not sure if this is a modsec issue as I have tested it by disabling > the modsec still I face this issue. > I have apache setup in reverse proxy configuration with proxy timeout set > as 20 sec. > for one website request for /favicon.ico takes 20 sec. if I reduce the > proxy timeout to 2 sec then request for favicon.ico takes 2 sec. I put the > proxy module log level to trace 8 and apache log level to debug. but still > i am not able to find why apache waits for timeout. Attached are the logs > for your reference. > > Thanks in advance. > Homesh > [Thu Jan 25 15:47:22.967833 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(508): AH00831: socache_shmcb_store (0x61 -> subcache 1) > [Thu Jan 25 15:47:22.967900 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(862): AH00847: insert happened at idx=29, data=(6525:6557) > [Thu Jan 25 15:47:22.967923 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(865): AH00848: finished insert, subcache: idx_pos/idx_used=25/5, > data_pos/data_used=5638/1084 > [Thu Jan 25 15:47:22.967927 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(530): AH00834: leaving socache_shmcb_store successfully > [Thu Jan 25 15:47:22.968048 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(508): AH00831: socache_shmcb_store (0xab -> subcache 11) > [Thu Jan 25 15:47:22.968062 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(862): AH00847: insert happened at idx=26, data=(5857:5889) > [Thu Jan 25 15:47:22.968067 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(865): AH00848: finished insert, subcache: idx_pos/idx_used=22/5, > data_pos/data_used=4954/1099 > [Thu Jan 25 15:47:22.968071 2024] [socache_shmcb:debug] [pid 5731:tid 140199434626624] mod_socache_shmcb.c(530): AH00834: leaving socache_shmcb_store successfully > [Thu Jan 25 15:47:22.969591 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_kernel.c(415): [remote 1.2.3.4:58139] AH02034: Subsequent (No.2) HTTPS request > received for child 5394 (server play.lvu:443) > [Thu Jan 25 15:47:22.971124 2024] [proxy:trace2] [pid 5731:tid 140200633919040] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: attempting to match URI path '/favic > on.ico' against prefix '/error/' for proxying > [Thu Jan 25 15:47:22.971161 2024] [proxy:trace2] [pid 5731:tid 140200633919040] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: attempting to match URI path '/favic > on.ico' against prefix '/' for proxying > [Thu Jan 25 15:47:22.971167 2024] [proxy:trace1] [pid 5731:tid 140200633919040] mod_proxy.c(998): [remote 1.2.3.4:58139] AH03464: URI path '/favicon.ico' matches prox > y handler 'proxy:https://play-lvu-205133111.ap-south-1.elb.amazonaws.com:443/favicon.ico' > [Thu Jan 25 15:47:22.971190 2024] [authz_core:debug] [pid 5731:tid 140200633919040] mod_authz_core.c(843): [remote 1.2.3.4:58139] AH01628: authorization result: grant > ed (no directives) > [Thu Jan 25 15:47:22.975603 2024] [proxy:trace2] [pid 5731:tid 140200633919040] proxy_util.c(2335): [remote 1.2.3.4:58139] https: found worker https://play-lvu-20510 > 2675.ap-south-1.elb.amazonaws.com/ for https://play-lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico > [Thu Jan 25 15:47:22.975651 2024] [proxy:debug] [pid 5731:tid 140200633919040] mod_proxy.c(1503): [remote 1.2.3.4:58139] AH01143: Running scheme https handler (attemp > t 0) > [Thu Jan 25 15:47:22.975660 2024] [proxy_fcgi:debug] [pid 5731:tid 140200633919040] mod_proxy_fcgi.c(1054): [remote 1.2.3.4:58139] AH01076: url: https://play-lvu-205 > 102675.ap-south-1.elb.amazonaws.com/favicon.ico proxyname: (null) proxyport: 0 > [Thu Jan 25 15:47:22.975666 2024] [proxy_fcgi:debug] [pid 5731:tid 140200633919040] mod_proxy_fcgi.c(1059): [remote 1.2.3.4:58139] AH01077: declining URL https://play > -lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico > [Thu Jan 25 15:47:22.975682 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(2531): AH00942: https: has acquired connection for (play-lvu-205133111.ap-south > -1.elb.amazonaws.com) > [Thu Jan 25 15:47:22.975694 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(2587): [remote 1.2.3.4:58139] AH00944: connecting https://play-lvu-205102 > 675.ap-south-1.elb.amazonaws.com/favicon.ico to play-lvu-205133111.ap-south-1.elb.amazonaws.com:443 > [Thu Jan 25 15:47:23.019184 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(2810): [remote 1.2.3.4:58139] AH00947: connected /favicon.ico to play-lvu > -205133111.ap-south-1.elb.amazonaws.com:443 > [Thu Jan 25 15:47:23.019277 2024] [proxy:trace2] [pid 5731:tid 140200633919040] proxy_util.c(3244): https: fam 2 socket created to connect to play-lvu-205133111.ap-south-1 > .elb.amazonaws.com > [Thu Jan 25 15:47:43.039441 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(3267): (70007)The timeout specified has expired: AH00957: https: attempt to conn > ect to 3.111.227.162:443 (play-lvu-205133111.ap-south-1.elb.amazonaws.com) failed > [Thu Jan 25 15:47:43.039558 2024] [proxy:trace2] [pid 5731:tid 140200633919040] proxy_util.c(3244): https: fam 2 socket created to connect to play-lvu-205133111.ap-south-1 > .elb.amazonaws.com > [Thu Jan 25 15:47:43.057570 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(3276): AH02824: https: connection established with 3.109.6.57:443 (play-lvu-205 > 102675.ap-south-1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.057649 2024] [proxy:trace1] [pid 5731:tid 140200633919040] proxy_util.c(3450): [remote 3.109.6.57:443] https: set SNI to play.lvu for (play-lvu-20510 > 2675.ap-south-1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.057655 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(3462): AH00962: https: connection complete to 3.111.227.162:443 (play-lvu-20510 > 2675.ap-south-1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.057663 2024] [qos:debug] [pid 5731:tid 140200633919040] apache2/mod_qos.c(8587): mod_qos(): skip processing of outgoing connection 3.109.6.57<->165.232 > .187.180 > [Thu Jan 25 15:47:43.057669 2024] [ssl:info] [pid 5731:tid 140200633919040] [remote 3.109.6.57:443] AH01964: Connection to child 0 established (server play.lvu:443) > [Thu Jan 25 15:47:43.078549 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] AH02275: Certificate Verification, depth 3, > CRL checking mode: none (0) [subject: CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\\, Inc.,L=Scottsdale,ST=Arizona,C=US / issuer: OU=Starf > ield Class 2 Certification Authority,O=Starfield Technologies\\, Inc.,C=US / serial: A70E4A4C3482B77F / notbefore: Sep 2 00:00:00 2009 GMT / notafter: Jun 28 17:39:16 2034 > GMT] > [Thu Jan 25 15:47:43.078695 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] AH02275: Certificate Verification, depth 2, > CRL checking mode: none (0) [subject: CN=Amazon Root CA 1,O=Amazon,C=US / issuer: CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\\, Inc.,L=S > cottsdale,ST=Arizona,C=US / serial: 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6 / notbefore: May 25 12:00:00 2015 GMT / notafter: Dec 31 01:00:00 2037 GMT] > [Thu Jan 25 15:47:43.078779 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] AH02275: Certificate Verification, depth 1, > CRL checking mode: none (0) [subject: CN=Amazon RSA 2048 M01,O=Amazon,C=US / issuer: CN=Amazon Root CA 1,O=Amazon,C=US / serial: 077312380B9D6688A33B1ED9BF9CCDA68E0E0F / no > tbefore: Aug 23 22:21:28 2022 GMT / notafter: Aug 23 22:21:28 2030 GMT] > [Thu Jan 25 15:47:43.078863 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_kernel.c(1764): [remote 3.109.6.57:443] AH02275: Certificate Verification, depth 0, > CRL checking mode: none (0) [subject: CN=play.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 20 > 23 GMT / notafter: Nov 8 23:59:59 2024 GMT] > [Thu Jan 25 15:47:43.079137 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_kernel.c(2254): [remote 3.109.6.57:443] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_ > 128_GCM_SHA256 (128/128 bits) > [Thu Jan 25 15:47:43.079199 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_util_ssl.c(451): AH02412: [play.lvu:443] Cert matches for name 'play.lvu' [subject: CN=kl > ay.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 2023 GMT / notafter: Nov 8 23:59:59 2024 GMT > ] > [Thu Jan 25 15:47:43.100903 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(2546): AH00943: https: has released connection for (play-lvu-205133111.ap-south > -1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.100989 2024] [ssl:debug] [pid 5731:tid 140200633919040] ssl_engine_io.c(1147): [remote 3.109.6.57:443] AH02001: Connection closed to child 0 with stand > ard shutdown (server play.lvu:443) > [Thu Jan 25 15:47:43.101088 2024] [proxy:debug] [pid 5731:tid 140200633919040] proxy_util.c(3386): [remote 3.109.6.57:443] AH02642: proxy: connection shutdown > [Thu Jan 25 15:47:43.863505 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_kernel.c(415): [remote 1.2.3.4:58139] AH02034: Subsequent (No.2) HTTPS request > received for child 1808 (server play.lvu:443), referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.865077 2024] [proxy:trace2] [pid 5731:tid 140200650737216] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: attempting to match URI path '/favic > on.ico' against prefix '/error/' for proxying, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.865165 2024] [proxy:trace2] [pid 5731:tid 140200650737216] mod_proxy.c(881): [remote 1.2.3.4:58139] AH03461: attempting to match URI path '/favic > on.ico' against prefix '/' for proxying, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.865192 2024] [proxy:trace1] [pid 5731:tid 140200650737216] mod_proxy.c(998): [remote 1.2.3.4:58139] AH03464: URI path '/favicon.ico' matches prox > y handler 'proxy:https://play-lvu-205133111.ap-south-1.elb.amazonaws.com:443/favicon.ico', referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.865231 2024] [authz_core:debug] [pid 5731:tid 140200650737216] mod_authz_core.c(843): [remote 1.2.3.4:58139] AH01628: authorization result: grant > ed (no directives), referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868082 2024] [proxy:trace2] [pid 5731:tid 140200650737216] proxy_util.c(2335): [remote 1.2.3.4:58139] https: found worker https://play-lvu-20510 > 2675.ap-south-1.elb.amazonaws.com/ for https://play-lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868164 2024] [proxy:debug] [pid 5731:tid 140200650737216] mod_proxy.c(1503): [remote 1.2.3.4:58139] AH01143: Running scheme https handler (attemp > t 0), referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868198 2024] [proxy_fcgi:debug] [pid 5731:tid 140200650737216] mod_proxy_fcgi.c(1054): [remote 1.2.3.4:58139] AH01076: url: https://play-lvu-205 > 102675.ap-south-1.elb.amazonaws.com/favicon.ico proxyname: (null) proxyport: 0, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868223 2024] [proxy_fcgi:debug] [pid 5731:tid 140200650737216] mod_proxy_fcgi.c(1059): [remote 1.2.3.4:58139] AH01077: declining URL https://play > -lvu-205133111.ap-south-1.elb.amazonaws.com/favicon.ico, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868248 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(2531): AH00942: https: has acquired connection for (play-lvu-205133111.ap-south > -1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.868273 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(2587): [remote 1.2.3.4:58139] AH00944: connecting https://play-lvu-205102 > 675.ap-south-1.elb.amazonaws.com/favicon.ico to play-lvu-205133111.ap-south-1.elb.amazonaws.com:443, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868630 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(2810): [remote 1.2.3.4:58139] AH00947: connected /favicon.ico to play-lvu > -205133111.ap-south-1.elb.amazonaws.com:443, referer: https://play.lvu/favicon.ico > [Thu Jan 25 15:47:43.868704 2024] [proxy:trace2] [pid 5731:tid 140200650737216] proxy_util.c(3244): https: fam 2 socket created to connect to play-lvu-205133111.ap-south-1 > .elb.amazonaws.com > [Thu Jan 25 15:47:43.894557 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(3276): AH02824: https: connection established with 3.109.172.68:443 (play-lvu-2 > 05102675.ap-south-1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.894681 2024] [proxy:trace1] [pid 5731:tid 140200650737216] proxy_util.c(3450): [remote 3.109.172.68:443] https: set SNI to play.lvu for (play-lvu-205 > 102675.ap-south-1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.894708 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(3462): AH00962: https: connection complete to 3.109.172.68:443 (play-lvu-205102 > 675.ap-south-1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.894748 2024] [qos:debug] [pid 5731:tid 140200650737216] apache2/mod_qos.c(8587): mod_qos(): skip processing of outgoing connection 3.109.172.68<->165.2 > 32.187.180 > [Thu Jan 25 15:47:43.894770 2024] [ssl:info] [pid 5731:tid 140200650737216] [remote 3.109.172.68:443] AH01964: Connection to child 0 established (server play.lvu:443) > [Thu Jan 25 15:47:43.923819 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] AH02275: Certificate Verification, depth 3 > , CRL checking mode: none (0) [subject: CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\\, Inc.,L=Scottsdale,ST=Arizona,C=US / issuer: OU=Sta > rfield Class 2 Certification Authority,O=Starfield Technologies\\, Inc.,C=US / serial: A70E4A4C3482B77F / notbefore: Sep 2 00:00:00 2009 GMT / notafter: Jun 28 17:39:16 20 > 34 GMT] > [Thu Jan 25 15:47:43.924033 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] AH02275: Certificate Verification, depth 2 > , CRL checking mode: none (0) [subject: CN=Amazon Root CA 1,O=Amazon,C=US / issuer: CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\\, Inc.,L > =Scottsdale,ST=Arizona,C=US / serial: 067F944A2A27CDF3FAC2AE2B01F908EEB9C4C6 / notbefore: May 25 12:00:00 2015 GMT / notafter: Dec 31 01:00:00 2037 GMT] > [Thu Jan 25 15:47:43.924124 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] AH02275: Certificate Verification, depth 1 > , CRL checking mode: none (0) [subject: CN=Amazon RSA 2048 M01,O=Amazon,C=US / issuer: CN=Amazon Root CA 1,O=Amazon,C=US / serial: 077312380B9D6688A33B1ED9BF9CCDA68E0E0F / > notbefore: Aug 23 22:21:28 2022 GMT / notafter: Aug 23 22:21:28 2030 GMT] > [Thu Jan 25 15:47:43.924208 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_kernel.c(1764): [remote 3.109.172.68:443] AH02275: Certificate Verification, depth 0 > , CRL checking mode: none (0) [subject: CN=play.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 > 2023 GMT / notafter: Nov 8 23:59:59 2024 GMT] > [Thu Jan 25 15:47:43.924468 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_kernel.c(2254): [remote 3.109.172.68:443] AH02041: Protocol: TLSv1.3, Cipher: TLS_AE > S_128_GCM_SHA256 (128/128 bits) > [Thu Jan 25 15:47:43.924535 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_util_ssl.c(451): AH02412: [play.lvu:443] Cert matches for name 'play.lvu' [subject: CN=kl > ay.lvu / issuer: CN=Amazon RSA 2048 M01,O=Amazon,C=US / serial: 088DB8B2694138D3A4624BF0EEFF3856 / notbefore: Oct 11 00:00:00 2023 GMT / notafter: Nov 8 23:59:59 2024 GMT > ] > [Thu Jan 25 15:47:43.959108 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(2546): AH00943: https: has released connection for (play-lvu-205133111.ap-south > -1.elb.amazonaws.com) > [Thu Jan 25 15:47:43.959261 2024] [ssl:debug] [pid 5731:tid 140200650737216] ssl_engine_io.c(1147): [remote 3.109.172.68:443] AH02001: Connection closed to child 0 with sta > ndard shutdown (server play.lvu:443) > [Thu Jan 25 15:47:43.959361 2024] [proxy:debug] [pid 5731:tid 140200650737216] proxy_util.c(3386): [remote 3.109.172.68:443] AH02642: proxy: connection shutdown > [Thu Jan 25 15:47:48.965114 2024] [ssl:debug] [pid 5731:tid 140199476590144] ssl_engine_io.c(1147): [client 1.2.3.4:58139] AH02001: Connection closed to child 16 with > standard shutdown (server play.lvu:443) > > > > ▸ > _______________________________________________ > 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: homesh j. <ho...@gm...> - 2024-01-29 07:01:33
|
Hi All, I am not sure if this is a modsec issue as I have tested it by disabling the modsec still I face this issue. I have apache setup in reverse proxy configuration with proxy timeout set as 20 sec. for one website request for /favicon.ico takes 20 sec. if I reduce the proxy timeout to 2 sec then request for favicon.ico takes 2 sec. I put the proxy module log level to trace 8 and apache log level to debug. but still i am not able to find why apache waits for timeout. Attached are the logs for your reference. Thanks in advance. Homesh |
From: Ervin H. <ai...@gm...> - 2024-01-11 13:48:10
|
Hi all, (sorry for the crosspost). Perhaps most users read the news: Trustwave transfers ModSecurity custodianship to the OWASP (Open Worldwide Application Security Project). This means the development of ModSecurity (mod_security2 Apache module, libmodsecurit3 library and libnginx-mod-http-modsecurity Nginx module) will continue under the umbrella of OWASP. Here are the announcements: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/trustwave-transfers-modsecurity-custodianship-to-the-open-worldwide-application-security-project/ https://owasp.org/blog/2024/01/09/ModSecurity.html There is a public channel on OWASP's Slack workspace, called #project-modsecurity. You can join the workspace here: https://owasp.org/slack/invite. Feel free to join that channel if you have any questions/ideas, or want to participate in the development of any component. Regards, a. |
From: Andrew H. <and...@ow...> - 2023-10-26 21:34:37
|
The OWASP ModSecurity Core Rule Set (CRS) team is proud to announce the availability of release candidate 2 (RC2) of the upcoming CRS v4.0.0 release. The release candidate is available for download as a 'release' from our GitHub repository: * https://github.com/coreruleset/coreruleset/releases/tag/v4.0.0-rc2 This new release candidate includes over 230 changes. Some of the important changes include: * Add new rule 920620 to explicitly detect multiple Content-Type abuse (CVE-2023-38199) (Andrea Menin) * Extend definition of restricted headers to include Content-Encoding and Accept-Charset by default (Walter Hop) * Migrate application exclusions and less-used functionality to plugins (Christian Folini, Max Leske, Jozef Sudolský, Andrew Howe) * Add support for HTTP/3 (Jozef Sudolský) * Add enable_default_collections flag to not initialize collections by default (Matteo Pace) * Switch to using wordnet instead of spell for finding English words in spell.sh utility (Max Leske) Refer to the CHANGES.md file in the release for the full list of changes. It is important to note that this new release candidate is *significantly different to the first release candidate* which was announced and made available[1] back in April 2022. Two days after the v4.0.0 RC1 release, the CRS project participated in a bug bounty program[2] in April-May 2022 which resulted in 175 security findings being reported. The decision was made to fix the findings in full for the v4.0.0 release, rather than release a half-baked version 4.0 with many newly discovered holes. The fixes required a *significant* amount of work over many months. It was sometimes the case that adding the required new detection would cause unforeseen problems, such as introducing new false positives which then needed to be addressed. Fixing all of the security findings in full required the development of new tooling, new rules, new tests, and new approaches. This all took a lot of time to complete to the high standard expected from the CRS project, resulting in an unfortunate delay to v4.0.0. As a result of fixing the security findings, the RC2 release features *a lot of new detection capability*. It is highly likely that *new false positives will continue to appear* as a result, so it is very important for this new release candidate to be tested as widely as possible. *Please test this new release candidate* and report any false positives encountered via GitHub (https://github.com/coreruleset/coreruleset/). All feedback and reports are gratefully received and will help to make the final v4.0.0 release the best and most comprehensive CRS release ever! Sincerely, Andrew Howe on behalf of the Core Rule Set development team --- [1]: https://coreruleset.org/20220428/coreruleset-v4-rc1-available [2]: https://coreruleset.org/20230509/what-we-learnt-from-our-bug-bounty-program-its-not-for-the-faint-of-heart |
From: <az...@po...> - 2023-09-26 11:00:33
|
Hi, try CRS but you will need few exclusion rules to make it work properly. Citát 현 <co...@gm...>: > I'm looking for a RuleSet that can defend Magento. |
From: 현 <co...@gm...> - 2023-09-26 07:01:44
|
I'm looking for a RuleSet that can defend Magento. |
From: Andrew H. <rub...@gm...> - 2023-07-24 19:12:59
|
The OWASP ModSecurity Core Rule Set (CRS) team is pleased to announce the release of CRS v3.3.5. For downloads and installation instructions, please refer to the Installation page (https://coreruleset.org/installation/). This is a security release which fixes the recently announced CVE-2023-38199, whereby it is possible to cause an impedance mismatch on some platforms running CRS v3.3.4 and earlier by submitting a request with multiple Content-Type headers. See: https://coreruleset.org/20230717/cve-2023-38199-multiple-content-type-headers/ Aside from the security fix, a few other minor, non-breaking changes and improvements are also included in this release. The full changes are as follows: * Backport fix for CVE-2023-38199 from CRS v4 via new rule 920620 (Andrea Menin, Felipe Zipitría) * Fix paranoia level-related scoring issue in rule 921422 (Walter Hop) * Move auditLogParts actions to the end of chained rules where used (Ervin Hegedus) * Clean up redundant paranoia level tags (Ervin Hegedus) * Clean up YAML test files to support go-ftw testing framework (Felipe Zipitría) * Move testing framework from ftw to go-ftw (Felipe Zipitría) * Update sponsors list and copyright notices (Felipe Zipitría) As noted above, the fix for CVE-2023-38199 has already been merged[1] into the CRS v4 branch[2]: our upcoming milestone release which we hope to publish in the near future. Please feel free to contact us with any questions or concerns about this release via the usual channels: directly via the CRS GitHub repository, in our Slack channel (#coreruleset on owasp.slack.com), or via the mailing list. Sincerely, Andrew Howe on behalf of the Core Rule Set development team --- [1]: https://github.com/coreruleset/coreruleset/pull/3237 [2]: https://github.com/coreruleset/coreruleset/tree/v4.0/dev |
From: Christian F. <chr...@ne...> - 2023-06-21 12:29:10
|
Hey Homesh, Yes, it's the same it's just that the deny does not happen, so rule execution continues. Good luck! Christian On Wed, Jun 21, 2023 at 05:45:42PM +0530, homesh joshi wrote: > Hi Christian, > > Thanks for the quick reply. OK so in detectonly mode also modsecurity rule > evaluation works the same. > Debug is a good idea. I have UAT so I can test. Will let you know. > > Thanks, > Homesh > > On Wed, Jun 21, 2023 at 3:03 PM Christian Folini < > chr...@ne...> wrote: > > > Hey Homesh, > > > > Evaluation does indeed stop after a drop and there is a chance > > your rules only set the variables in question in a later phase. > > Really depends on your configuration. > > > > You can follow rule execution with the ModSecurity debug log, but beware > > it is very verbose. > > > > Generally, it is best to set variables for display in the access log only > > in phase 5, which is also executed for requests that have been denied > > in an earlier phase. > > > > Best regards, > > > > Christian > > > > > > > > > > On Wed, Jun 21, 2023 at 01:14:04PM +0530, homesh joshi wrote: > > > Hi All, > > > > > > With regards to my approach for logging the modsec variables in apache > > log > > > has worked for me for almost a year now. > > > However, today when I enabled "SecRuleEngine DetectionOnly" for one of my > > > websites. What I notice is that the apache logs are missing the right > > > variable data. > > > e.g I tested SQL injection and i was not able to see the relevant > > > information in apache log which I typically get when "SecRuleEngine On" > > > sample log for "SecRuleEngine DetectionOnly" > > > 49.36.106.185 - - [21/Jun/2023:06:39:53 +0000] 200 23125 GET "-" > > > "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 > > > Firefox/114.0" 3154 443 example.com ZJKbOUfg7dWT82qCkvNySAAAAEU TLSv1.3 > > > TLS_AES_128_GCM_SHA256 0 4 L; "/" 15.24.15.205 39735 "" "" "" "/" 333762 > > > "/?k=1%20or%201=1" > > > > > > here rule id log is 333762 which is not the signature for SQL injection > > > > > > So my conclusion is, in "SecRuleEngine On" rule evaluation stops when the > > > first rule matches with the final action drop/block. Hence I am able to > > get > > > the right rule ID and other variable data. But when "SecRuleEngine > > > DetectionOnly" rule evaluation continues till the last rule and due to > > > which my variable data gets changed as per the rules getting evaluated. > > Can > > > I change this behaviour of modsecurity in Detectonly mode ? that it > > should > > > stop the evaluation when it matches the first rule with final action of > > > drop/block ( and not block/drop the transaction) ? > > > > > > Please suggest. > > > > > > Thanks, > > > Homesh > > > > > > > > > On Fri, Mar 25, 2022 at 4:08 PM Christian Folini < > > > chr...@ne...> wrote: > > > > > > > Thanks for the updates. I do not immediately see why it's not working > > > > completely. But glad you have a working solution. > > > > > > > > Best, > > > > > > > > Christian > > > > > > > > On Fri, Mar 25, 2022 at 01:59:38PM +0530, homesh joshi wrote: > > > > > Dear Christian, > > > > > > > > > > I added setvar:tx.rule=1 in each rule and then added the following > > rule, > > > > > post which I am able to get 1 written in access logs ( via the > > %{waf} ) > > > > for > > > > > the transactions which got blocked by Modsec. for other transactions > > it > > > > is > > > > > missing and hence getting - in the logs. I was not able to directly > > set > > > > the > > > > > WAF=1 in the rules via setenv:waf=1 > > > > > > > > > > SecRule TX:rule "@eq 1" "phase:5,pass,setenv:waf=1,id:'9001'" > > > > > > > > > > Will test this any update incase I face any challenge. > > > > > > > > > > Thanks, > > > > > Homesh > > > > > > > > > > > > > > > On Thu, Mar 24, 2022 at 6:35 PM Christian Folini < > > > > > chr...@ne...> wrote: > > > > > > > > > > > I suggest you add this to every rule that detects / blocks > > something. > > > > > > Thus not a SecAction, but attach the setenv to your existing > > SecRules > > > > > > where you want to see the flag. > > > > > > > > > > > > Alternatively, you can do a SecRule in phase 5 where you test the > > > > > > HTTP status and if it's 403, then you set the env. > > > > > > > > > > > > Good luck! > > > > > > > > > > > > Christian > > > > > > > > > > > > On Thu, Mar 24, 2022 at 05:02:20PM +0530, homesh joshi wrote: > > > > > > > Dear Christian, > > > > > > > > > > > > > > Thanks. I think this will work for me. However, can you please > > > > explain > > > > > > it a > > > > > > > bit more on how this works. > > > > > > > from your tutorial if i set up following rule > > > > > > > > > > > > > > # === ModSec performance calculations and variable export (ids: > > > > 90100 - > > > > > > 90199) > > > > > > > > > > > > > > SecAction "id:90100,phase:5,pass,nolog,setenv:modsec=1" > > > > > > > > > > > > > > then for every access I see "1" in the access log. > > > > > > > > > > > > > > I think I will need to understand it more in order to use it. > > > > > > > > > > > > > > Kindly explain > > > > > > > 1) the configuration required for setenv by modifying each rule > > > > > > > > > > > > > > 2) the configuration required for more complicated scheme which > > you > > > > > > > are referring to > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 24, 2022 at 11:52 AM Christian Folini < > > > > > > > chr...@ne...> wrote: > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > On Thu, Mar 24, 2022 at 08:37:51AM +0530, homesh joshi wrote: > > > > > > > > > Thanks for the clarification. > > > > > > > > > I have already gone through excellent netnea.com tutorials. > > I > > > > have > > > > > > > > already > > > > > > > > > used some of the configuration from tutorial.I do not use > > crs. > > > > > > > > > > > > > > > > Thank you very much. > > > > > > > > > > > > > > > > > My objective here is that I want to get a flag in access log > > > > line if > > > > > > > > modsec > > > > > > > > > has taken any action on the transaction say simply it can be > > a > > > > field > > > > > > like > > > > > > > > > modsec=1 or modsec=0. This wi help me in separating > > transactions > > > > > > which > > > > > > > > are > > > > > > > > > allowed.(modsec=0) So then it is easy to show these > > transactions > > > > in > > > > > > the > > > > > > > > > reporting system. > > > > > > > > > > > > > > > > I'd do a setenv then in the rules. > > > > > > > > > > > > > > > > ... "setenv:modsec=1" > > > > > > > > > > > > > > > > Similar to the way I set th various env variables in phase 5. > > You > > > > can > > > > > > > > simply > > > > > > > > add this to every rule you have. Or you set up a more > > complicated > > > > > > scheme > > > > > > > > and do it in the end in phase 5. > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > On Thu, 24 Mar, 2022, 12:04 am Christian Folini, < > > > > > > > > > chr...@ne...> wrote: > > > > > > > > > > > > > > > > > > > HelloHomesh, > > > > > > > > > > > > > > > > > > > > Unfortunately, this is not how this works. > > > > > > > > > > > > > > > > > > > > A ModSecuriy variable is not automatically an environment > > > > variable. > > > > > > > > > > And on top, the ModSec variable "rule" is only available > > > > during the > > > > > > > > > > execution of the very rule (and there might be many, many > > > > rules). > > > > > > > > > > > > > > > > > > > > I suggest you read up on my free tutorials published at > > > > netnea.com > > > > > > . > > > > > > > > > > The one on logging and the ones on the Core Rule Set are > > > > proposing > > > > > > > > > > ways to achieve something along these lines. > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 23, 2022 at 11:12:58PM +0530, homesh joshi > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > Hope you all are well. > > > > > > > > > > > > > > > > > > > > > > I want to add the modsecurity variable e.g "rule.id"in > > the > > > > > > apache > > > > > > > > access > > > > > > > > > > > log via the extended format. > > > > > > > > > > > I set the following line in /etc/apache2/apache.conf > > > > > > > > > > > > > > > > > > > > > > LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" > > > > > > > > \"%{User-Agent}i\" > > > > > > > > > > > %{ms}T %p %{Host}i %{UNIQUE_ID}e %{rule.id}e" extended > > > > > > > > > > > > > > > > > > > > > > However I am not getting the rule.id value in the > > access log > > > > > > line. > > > > > > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > mod-security-users mailing list > > > > > > > > > > > mod...@li... > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > > > SpiderLabs: > > > > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > mod-security-users mailing list > > > > > > > > > > mod...@li... > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > > > SpiderLabs: > > > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > mod-security-users mailing list > > > > > > > > > mod...@li... > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > SpiderLabs: > > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > mod-security-users mailing list > > > > > > > > mod...@li... > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > SpiderLabs: > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mod-security-users mailing list > > > > > > > mod...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > SpiderLabs: > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mod-security-users mailing list > > > > > > mod...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > SpiderLabs: > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mod-security-users mailing list > > > > > mod...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > mod-security-users mailing list > > > > mod...@li... > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > _______________________________________________ > 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: homesh j. <ho...@gm...> - 2023-06-21 12:16:03
|
Hi Christian, Thanks for the quick reply. OK so in detectonly mode also modsecurity rule evaluation works the same. Debug is a good idea. I have UAT so I can test. Will let you know. Thanks, Homesh On Wed, Jun 21, 2023 at 3:03 PM Christian Folini < chr...@ne...> wrote: > Hey Homesh, > > Evaluation does indeed stop after a drop and there is a chance > your rules only set the variables in question in a later phase. > Really depends on your configuration. > > You can follow rule execution with the ModSecurity debug log, but beware > it is very verbose. > > Generally, it is best to set variables for display in the access log only > in phase 5, which is also executed for requests that have been denied > in an earlier phase. > > Best regards, > > Christian > > > > > On Wed, Jun 21, 2023 at 01:14:04PM +0530, homesh joshi wrote: > > Hi All, > > > > With regards to my approach for logging the modsec variables in apache > log > > has worked for me for almost a year now. > > However, today when I enabled "SecRuleEngine DetectionOnly" for one of my > > websites. What I notice is that the apache logs are missing the right > > variable data. > > e.g I tested SQL injection and i was not able to see the relevant > > information in apache log which I typically get when "SecRuleEngine On" > > sample log for "SecRuleEngine DetectionOnly" > > 49.36.106.185 - - [21/Jun/2023:06:39:53 +0000] 200 23125 GET "-" > > "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 > > Firefox/114.0" 3154 443 example.com ZJKbOUfg7dWT82qCkvNySAAAAEU TLSv1.3 > > TLS_AES_128_GCM_SHA256 0 4 L; "/" 15.24.15.205 39735 "" "" "" "/" 333762 > > "/?k=1%20or%201=1" > > > > here rule id log is 333762 which is not the signature for SQL injection > > > > So my conclusion is, in "SecRuleEngine On" rule evaluation stops when the > > first rule matches with the final action drop/block. Hence I am able to > get > > the right rule ID and other variable data. But when "SecRuleEngine > > DetectionOnly" rule evaluation continues till the last rule and due to > > which my variable data gets changed as per the rules getting evaluated. > Can > > I change this behaviour of modsecurity in Detectonly mode ? that it > should > > stop the evaluation when it matches the first rule with final action of > > drop/block ( and not block/drop the transaction) ? > > > > Please suggest. > > > > Thanks, > > Homesh > > > > > > On Fri, Mar 25, 2022 at 4:08 PM Christian Folini < > > chr...@ne...> wrote: > > > > > Thanks for the updates. I do not immediately see why it's not working > > > completely. But glad you have a working solution. > > > > > > Best, > > > > > > Christian > > > > > > On Fri, Mar 25, 2022 at 01:59:38PM +0530, homesh joshi wrote: > > > > Dear Christian, > > > > > > > > I added setvar:tx.rule=1 in each rule and then added the following > rule, > > > > post which I am able to get 1 written in access logs ( via the > %{waf} ) > > > for > > > > the transactions which got blocked by Modsec. for other transactions > it > > > is > > > > missing and hence getting - in the logs. I was not able to directly > set > > > the > > > > WAF=1 in the rules via setenv:waf=1 > > > > > > > > SecRule TX:rule "@eq 1" "phase:5,pass,setenv:waf=1,id:'9001'" > > > > > > > > Will test this any update incase I face any challenge. > > > > > > > > Thanks, > > > > Homesh > > > > > > > > > > > > On Thu, Mar 24, 2022 at 6:35 PM Christian Folini < > > > > chr...@ne...> wrote: > > > > > > > > > I suggest you add this to every rule that detects / blocks > something. > > > > > Thus not a SecAction, but attach the setenv to your existing > SecRules > > > > > where you want to see the flag. > > > > > > > > > > Alternatively, you can do a SecRule in phase 5 where you test the > > > > > HTTP status and if it's 403, then you set the env. > > > > > > > > > > Good luck! > > > > > > > > > > Christian > > > > > > > > > > On Thu, Mar 24, 2022 at 05:02:20PM +0530, homesh joshi wrote: > > > > > > Dear Christian, > > > > > > > > > > > > Thanks. I think this will work for me. However, can you please > > > explain > > > > > it a > > > > > > bit more on how this works. > > > > > > from your tutorial if i set up following rule > > > > > > > > > > > > # === ModSec performance calculations and variable export (ids: > > > 90100 - > > > > > 90199) > > > > > > > > > > > > SecAction "id:90100,phase:5,pass,nolog,setenv:modsec=1" > > > > > > > > > > > > then for every access I see "1" in the access log. > > > > > > > > > > > > I think I will need to understand it more in order to use it. > > > > > > > > > > > > Kindly explain > > > > > > 1) the configuration required for setenv by modifying each rule > > > > > > > > > > > > 2) the configuration required for more complicated scheme which > you > > > > > > are referring to > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > On Thu, Mar 24, 2022 at 11:52 AM Christian Folini < > > > > > > chr...@ne...> wrote: > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > On Thu, Mar 24, 2022 at 08:37:51AM +0530, homesh joshi wrote: > > > > > > > > Thanks for the clarification. > > > > > > > > I have already gone through excellent netnea.com tutorials. > I > > > have > > > > > > > already > > > > > > > > used some of the configuration from tutorial.I do not use > crs. > > > > > > > > > > > > > > Thank you very much. > > > > > > > > > > > > > > > My objective here is that I want to get a flag in access log > > > line if > > > > > > > modsec > > > > > > > > has taken any action on the transaction say simply it can be > a > > > field > > > > > like > > > > > > > > modsec=1 or modsec=0. This wi help me in separating > transactions > > > > > which > > > > > > > are > > > > > > > > allowed.(modsec=0) So then it is easy to show these > transactions > > > in > > > > > the > > > > > > > > reporting system. > > > > > > > > > > > > > > I'd do a setenv then in the rules. > > > > > > > > > > > > > > ... "setenv:modsec=1" > > > > > > > > > > > > > > Similar to the way I set th various env variables in phase 5. > You > > > can > > > > > > > simply > > > > > > > add this to every rule you have. Or you set up a more > complicated > > > > > scheme > > > > > > > and do it in the end in phase 5. > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Homesh > > > > > > > > > > > > > > > > On Thu, 24 Mar, 2022, 12:04 am Christian Folini, < > > > > > > > > chr...@ne...> wrote: > > > > > > > > > > > > > > > > > HelloHomesh, > > > > > > > > > > > > > > > > > > Unfortunately, this is not how this works. > > > > > > > > > > > > > > > > > > A ModSecuriy variable is not automatically an environment > > > variable. > > > > > > > > > And on top, the ModSec variable "rule" is only available > > > during the > > > > > > > > > execution of the very rule (and there might be many, many > > > rules). > > > > > > > > > > > > > > > > > > I suggest you read up on my free tutorials published at > > > netnea.com > > > > > . > > > > > > > > > The one on logging and the ones on the Core Rule Set are > > > proposing > > > > > > > > > ways to achieve something along these lines. > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 23, 2022 at 11:12:58PM +0530, homesh joshi > wrote: > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > Hope you all are well. > > > > > > > > > > > > > > > > > > > > I want to add the modsecurity variable e.g "rule.id"in > the > > > > > apache > > > > > > > access > > > > > > > > > > log via the extended format. > > > > > > > > > > I set the following line in /etc/apache2/apache.conf > > > > > > > > > > > > > > > > > > > > LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" > > > > > > > \"%{User-Agent}i\" > > > > > > > > > > %{ms}T %p %{Host}i %{UNIQUE_ID}e %{rule.id}e" extended > > > > > > > > > > > > > > > > > > > > However I am not getting the rule.id value in the > access log > > > > > line. > > > > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > mod-security-users mailing list > > > > > > > > > > mod...@li... > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > > SpiderLabs: > > > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > mod-security-users mailing list > > > > > > > > > mod...@li... > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > > SpiderLabs: > > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > mod-security-users mailing list > > > > > > > > mod...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > SpiderLabs: > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mod-security-users mailing list > > > > > > > mod...@li... > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > SpiderLabs: > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mod-security-users mailing list > > > > > > mod...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > SpiderLabs: > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mod-security-users mailing list > > > > > mod...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > Commercial ModSecurity Rules and Support from Trustwave's > SpiderLabs: > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > _______________________________________________ > > > > mod-security-users mailing list > > > > mod...@li... > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
From: Christian F. <chr...@ne...> - 2023-06-21 09:29:41
|
Hey Homesh, Evaluation does indeed stop after a drop and there is a chance your rules only set the variables in question in a later phase. Really depends on your configuration. You can follow rule execution with the ModSecurity debug log, but beware it is very verbose. Generally, it is best to set variables for display in the access log only in phase 5, which is also executed for requests that have been denied in an earlier phase. Best regards, Christian On Wed, Jun 21, 2023 at 01:14:04PM +0530, homesh joshi wrote: > Hi All, > > With regards to my approach for logging the modsec variables in apache log > has worked for me for almost a year now. > However, today when I enabled "SecRuleEngine DetectionOnly" for one of my > websites. What I notice is that the apache logs are missing the right > variable data. > e.g I tested SQL injection and i was not able to see the relevant > information in apache log which I typically get when "SecRuleEngine On" > sample log for "SecRuleEngine DetectionOnly" > 49.36.106.185 - - [21/Jun/2023:06:39:53 +0000] 200 23125 GET "-" > "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 > Firefox/114.0" 3154 443 example.com ZJKbOUfg7dWT82qCkvNySAAAAEU TLSv1.3 > TLS_AES_128_GCM_SHA256 0 4 L; "/" 15.24.15.205 39735 "" "" "" "/" 333762 > "/?k=1%20or%201=1" > > here rule id log is 333762 which is not the signature for SQL injection > > So my conclusion is, in "SecRuleEngine On" rule evaluation stops when the > first rule matches with the final action drop/block. Hence I am able to get > the right rule ID and other variable data. But when "SecRuleEngine > DetectionOnly" rule evaluation continues till the last rule and due to > which my variable data gets changed as per the rules getting evaluated. Can > I change this behaviour of modsecurity in Detectonly mode ? that it should > stop the evaluation when it matches the first rule with final action of > drop/block ( and not block/drop the transaction) ? > > Please suggest. > > Thanks, > Homesh > > > On Fri, Mar 25, 2022 at 4:08 PM Christian Folini < > chr...@ne...> wrote: > > > Thanks for the updates. I do not immediately see why it's not working > > completely. But glad you have a working solution. > > > > Best, > > > > Christian > > > > On Fri, Mar 25, 2022 at 01:59:38PM +0530, homesh joshi wrote: > > > Dear Christian, > > > > > > I added setvar:tx.rule=1 in each rule and then added the following rule, > > > post which I am able to get 1 written in access logs ( via the %{waf} ) > > for > > > the transactions which got blocked by Modsec. for other transactions it > > is > > > missing and hence getting - in the logs. I was not able to directly set > > the > > > WAF=1 in the rules via setenv:waf=1 > > > > > > SecRule TX:rule "@eq 1" "phase:5,pass,setenv:waf=1,id:'9001'" > > > > > > Will test this any update incase I face any challenge. > > > > > > Thanks, > > > Homesh > > > > > > > > > On Thu, Mar 24, 2022 at 6:35 PM Christian Folini < > > > chr...@ne...> wrote: > > > > > > > I suggest you add this to every rule that detects / blocks something. > > > > Thus not a SecAction, but attach the setenv to your existing SecRules > > > > where you want to see the flag. > > > > > > > > Alternatively, you can do a SecRule in phase 5 where you test the > > > > HTTP status and if it's 403, then you set the env. > > > > > > > > Good luck! > > > > > > > > Christian > > > > > > > > On Thu, Mar 24, 2022 at 05:02:20PM +0530, homesh joshi wrote: > > > > > Dear Christian, > > > > > > > > > > Thanks. I think this will work for me. However, can you please > > explain > > > > it a > > > > > bit more on how this works. > > > > > from your tutorial if i set up following rule > > > > > > > > > > # === ModSec performance calculations and variable export (ids: > > 90100 - > > > > 90199) > > > > > > > > > > SecAction "id:90100,phase:5,pass,nolog,setenv:modsec=1" > > > > > > > > > > then for every access I see "1" in the access log. > > > > > > > > > > I think I will need to understand it more in order to use it. > > > > > > > > > > Kindly explain > > > > > 1) the configuration required for setenv by modifying each rule > > > > > > > > > > 2) the configuration required for more complicated scheme which you > > > > > are referring to > > > > > > > > > > Thanks, > > > > > > > > > > Homesh > > > > > > > > > > > > > > > On Thu, Mar 24, 2022 at 11:52 AM Christian Folini < > > > > > chr...@ne...> wrote: > > > > > > > > > > > Hi there, > > > > > > > > > > > > On Thu, Mar 24, 2022 at 08:37:51AM +0530, homesh joshi wrote: > > > > > > > Thanks for the clarification. > > > > > > > I have already gone through excellent netnea.com tutorials. I > > have > > > > > > already > > > > > > > used some of the configuration from tutorial.I do not use crs. > > > > > > > > > > > > Thank you very much. > > > > > > > > > > > > > My objective here is that I want to get a flag in access log > > line if > > > > > > modsec > > > > > > > has taken any action on the transaction say simply it can be a > > field > > > > like > > > > > > > modsec=1 or modsec=0. This wi help me in separating transactions > > > > which > > > > > > are > > > > > > > allowed.(modsec=0) So then it is easy to show these transactions > > in > > > > the > > > > > > > reporting system. > > > > > > > > > > > > I'd do a setenv then in the rules. > > > > > > > > > > > > ... "setenv:modsec=1" > > > > > > > > > > > > Similar to the way I set th various env variables in phase 5. You > > can > > > > > > simply > > > > > > add this to every rule you have. Or you set up a more complicated > > > > scheme > > > > > > and do it in the end in phase 5. > > > > > > > > > > > > Best, > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > Thanks, > > > > > > > Homesh > > > > > > > > > > > > > > On Thu, 24 Mar, 2022, 12:04 am Christian Folini, < > > > > > > > chr...@ne...> wrote: > > > > > > > > > > > > > > > HelloHomesh, > > > > > > > > > > > > > > > > Unfortunately, this is not how this works. > > > > > > > > > > > > > > > > A ModSecuriy variable is not automatically an environment > > variable. > > > > > > > > And on top, the ModSec variable "rule" is only available > > during the > > > > > > > > execution of the very rule (and there might be many, many > > rules). > > > > > > > > > > > > > > > > I suggest you read up on my free tutorials published at > > netnea.com > > > > . > > > > > > > > The one on logging and the ones on the Core Rule Set are > > proposing > > > > > > > > ways to achieve something along these lines. > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 23, 2022 at 11:12:58PM +0530, homesh joshi wrote: > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > Hope you all are well. > > > > > > > > > > > > > > > > > > I want to add the modsecurity variable e.g "rule.id"in the > > > > apache > > > > > > access > > > > > > > > > log via the extended format. > > > > > > > > > I set the following line in /etc/apache2/apache.conf > > > > > > > > > > > > > > > > > > LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" > > > > > > \"%{User-Agent}i\" > > > > > > > > > %{ms}T %p %{Host}i %{UNIQUE_ID}e %{rule.id}e" extended > > > > > > > > > > > > > > > > > > However I am not getting the rule.id value in the access log > > > > line. > > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > mod-security-users mailing list > > > > > > > > > mod...@li... > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > SpiderLabs: > > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > mod-security-users mailing list > > > > > > > > mod...@li... > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > > SpiderLabs: > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mod-security-users mailing list > > > > > > > mod...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > SpiderLabs: > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mod-security-users mailing list > > > > > > mod...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > SpiderLabs: > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mod-security-users mailing list > > > > > mod...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > mod-security-users mailing list > > > > mod...@li... > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ |
From: homesh j. <ho...@gm...> - 2023-06-21 07:44:24
|
Hi All, With regards to my approach for logging the modsec variables in apache log has worked for me for almost a year now. However, today when I enabled "SecRuleEngine DetectionOnly" for one of my websites. What I notice is that the apache logs are missing the right variable data. e.g I tested SQL injection and i was not able to see the relevant information in apache log which I typically get when "SecRuleEngine On" sample log for "SecRuleEngine DetectionOnly" 49.36.106.185 - - [21/Jun/2023:06:39:53 +0000] 200 23125 GET "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/114.0" 3154 443 example.com ZJKbOUfg7dWT82qCkvNySAAAAEU TLSv1.3 TLS_AES_128_GCM_SHA256 0 4 L; "/" 15.24.15.205 39735 "" "" "" "/" 333762 "/?k=1%20or%201=1" here rule id log is 333762 which is not the signature for SQL injection So my conclusion is, in "SecRuleEngine On" rule evaluation stops when the first rule matches with the final action drop/block. Hence I am able to get the right rule ID and other variable data. But when "SecRuleEngine DetectionOnly" rule evaluation continues till the last rule and due to which my variable data gets changed as per the rules getting evaluated. Can I change this behaviour of modsecurity in Detectonly mode ? that it should stop the evaluation when it matches the first rule with final action of drop/block ( and not block/drop the transaction) ? Please suggest. Thanks, Homesh On Fri, Mar 25, 2022 at 4:08 PM Christian Folini < chr...@ne...> wrote: > Thanks for the updates. I do not immediately see why it's not working > completely. But glad you have a working solution. > > Best, > > Christian > > On Fri, Mar 25, 2022 at 01:59:38PM +0530, homesh joshi wrote: > > Dear Christian, > > > > I added setvar:tx.rule=1 in each rule and then added the following rule, > > post which I am able to get 1 written in access logs ( via the %{waf} ) > for > > the transactions which got blocked by Modsec. for other transactions it > is > > missing and hence getting - in the logs. I was not able to directly set > the > > WAF=1 in the rules via setenv:waf=1 > > > > SecRule TX:rule "@eq 1" "phase:5,pass,setenv:waf=1,id:'9001'" > > > > Will test this any update incase I face any challenge. > > > > Thanks, > > Homesh > > > > > > On Thu, Mar 24, 2022 at 6:35 PM Christian Folini < > > chr...@ne...> wrote: > > > > > I suggest you add this to every rule that detects / blocks something. > > > Thus not a SecAction, but attach the setenv to your existing SecRules > > > where you want to see the flag. > > > > > > Alternatively, you can do a SecRule in phase 5 where you test the > > > HTTP status and if it's 403, then you set the env. > > > > > > Good luck! > > > > > > Christian > > > > > > On Thu, Mar 24, 2022 at 05:02:20PM +0530, homesh joshi wrote: > > > > Dear Christian, > > > > > > > > Thanks. I think this will work for me. However, can you please > explain > > > it a > > > > bit more on how this works. > > > > from your tutorial if i set up following rule > > > > > > > > # === ModSec performance calculations and variable export (ids: > 90100 - > > > 90199) > > > > > > > > SecAction "id:90100,phase:5,pass,nolog,setenv:modsec=1" > > > > > > > > then for every access I see "1" in the access log. > > > > > > > > I think I will need to understand it more in order to use it. > > > > > > > > Kindly explain > > > > 1) the configuration required for setenv by modifying each rule > > > > > > > > 2) the configuration required for more complicated scheme which you > > > > are referring to > > > > > > > > Thanks, > > > > > > > > Homesh > > > > > > > > > > > > On Thu, Mar 24, 2022 at 11:52 AM Christian Folini < > > > > chr...@ne...> wrote: > > > > > > > > > Hi there, > > > > > > > > > > On Thu, Mar 24, 2022 at 08:37:51AM +0530, homesh joshi wrote: > > > > > > Thanks for the clarification. > > > > > > I have already gone through excellent netnea.com tutorials. I > have > > > > > already > > > > > > used some of the configuration from tutorial.I do not use crs. > > > > > > > > > > Thank you very much. > > > > > > > > > > > My objective here is that I want to get a flag in access log > line if > > > > > modsec > > > > > > has taken any action on the transaction say simply it can be a > field > > > like > > > > > > modsec=1 or modsec=0. This wi help me in separating transactions > > > which > > > > > are > > > > > > allowed.(modsec=0) So then it is easy to show these transactions > in > > > the > > > > > > reporting system. > > > > > > > > > > I'd do a setenv then in the rules. > > > > > > > > > > ... "setenv:modsec=1" > > > > > > > > > > Similar to the way I set th various env variables in phase 5. You > can > > > > > simply > > > > > add this to every rule you have. Or you set up a more complicated > > > scheme > > > > > and do it in the end in phase 5. > > > > > > > > > > Best, > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > Thanks, > > > > > > Homesh > > > > > > > > > > > > On Thu, 24 Mar, 2022, 12:04 am Christian Folini, < > > > > > > chr...@ne...> wrote: > > > > > > > > > > > > > HelloHomesh, > > > > > > > > > > > > > > Unfortunately, this is not how this works. > > > > > > > > > > > > > > A ModSecuriy variable is not automatically an environment > variable. > > > > > > > And on top, the ModSec variable "rule" is only available > during the > > > > > > > execution of the very rule (and there might be many, many > rules). > > > > > > > > > > > > > > I suggest you read up on my free tutorials published at > netnea.com > > > . > > > > > > > The one on logging and the ones on the Core Rule Set are > proposing > > > > > > > ways to achieve something along these lines. > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 23, 2022 at 11:12:58PM +0530, homesh joshi wrote: > > > > > > > > Hi All, > > > > > > > > > > > > > > > > Hope you all are well. > > > > > > > > > > > > > > > > I want to add the modsecurity variable e.g "rule.id"in the > > > apache > > > > > access > > > > > > > > log via the extended format. > > > > > > > > I set the following line in /etc/apache2/apache.conf > > > > > > > > > > > > > > > > LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" > > > > > \"%{User-Agent}i\" > > > > > > > > %{ms}T %p %{Host}i %{UNIQUE_ID}e %{rule.id}e" extended > > > > > > > > > > > > > > > > However I am not getting the rule.id value in the access log > > > line. > > > > > > > > > > > > > > > > Kindly suggest. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Homesh > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > mod-security-users mailing list > > > > > > > > mod...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > SpiderLabs: > > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mod-security-users mailing list > > > > > > > mod...@li... > > > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > > > SpiderLabs: > > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mod-security-users mailing list > > > > > > mod...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > > Commercial ModSecurity Rules and Support from Trustwave's > SpiderLabs: > > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mod-security-users mailing list > > > > > mod...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > > Commercial ModSecurity Rules and Support from Trustwave's > SpiderLabs: > > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > > > > _______________________________________________ > > > > mod-security-users mailing list > > > > mod...@li... > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > > http://www.modsecurity.org/projects/commercial/rules/ > > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > > > > > > _______________________________________________ > > > mod-security-users mailing list > > > mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > > http://www.modsecurity.org/projects/commercial/rules/ > > > http://www.modsecurity.org/projects/commercial/support/ > > > > > > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > > http://www.modsecurity.org/projects/commercial/rules/ > > http://www.modsecurity.org/projects/commercial/support/ > > > > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs: > http://www.modsecurity.org/projects/commercial/rules/ > http://www.modsecurity.org/projects/commercial/support/ > |
From: Luke B. <lba...@gm...> - 2023-05-18 15:50:58
|
Javascript / Challenge page Good morning, I introduce myself, I'm new to the list. i'm a university student who has to take care of the security inside the campus. I have to set up a series of mod_security instances which, in addition to a series of basic rules, must be able to run a challenge page, in the event of a major DDoS attack, in order to filter all automatic traffic. Has anyone done something like this before or can point me to online resources to do it? Thanks Luke |
From: Monah B. <mon...@gm...> - 2023-03-27 14:40:57
|
Morning all, I am trying to compile modsecurity on freebsd 12.4-release-p1 ========================== ModSecurity - v3.0.8-51-g1feaa7d2 for FreeBSD Mandatory dependencies + libInjection ....v3.9.2-46-gbfba51f + SecLang tests ....a3d4405 Optional dependencies + GeoIP/MaxMind ....found * (MaxMind) v1.6.0 -lmaxminddb , -DWITH_MAXMIND -I/usr/local/include + LibCURL ....found v7.87.0 -L/usr/local/lib -lcurl, -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL + YAJL ....found v2.1.0 -lyajl , -DWITH_YAJL -I/usr/local/include + LMDB ....disabled + LibXML2 ....found v2.10.3 -lxml2 , -I/usr/local/include/libxml2 -DWITH_LIBXML2 + SSDEEP ....found -lfuzzy -L/usr/local/lib/, -DWITH_SSDEEP -I/usr/local/include + LUA ....found -llua-5.4 -lm -L/usr/local/lib , -DWITH_LUA -DWITH_LUA_5_4 -I/usr/local/include/lua54 + PCRE2 ....disabled Other Options + Test Utilities ....enabled + SecDebugLog ....enabled + afl fuzzer ....disabled + library examples ....enabled + Building parser ....disabled + Treating pm operations as critical section ....disabled ================== However gmake returns the following error: libtool: compile: g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL -DWITH_YAJL -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPCRE_HAVE_JIT -I/usr/local/include -DWITH_SSDEEP -I/usr/local/include -DWITH_MAXMIND -I/usr/local/include -DWITH_LUA -DWITH_LUA_5_4 -I/usr/local/include/lua54 -I/usr/local/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT actions/disruptive/libmodsecurity_la-deny.lo -MD -MP -MF actions/disruptive/.deps/libmodsecurity_la-deny.Tpo -c actions/disruptive/deny.cc -fPIC -DPIC -o actions/disruptive/.libs/libmodsecurity_la-deny.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL -DWITH_YAJL -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPCRE_HAVE_JIT -I/usr/local/include -DWITH_SSDEEP -I/usr/local/include -DWITH_MAXMIND -I/usr/local/include -DWITH_LUA -DWITH_LUA_5_4 -I/usr/local/include/lua54 -I/usr/local/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT actions/disruptive/libmodsecurity_la-deny.lo -MD -MP -MF actions/disruptive/.deps/libmodsecurity_la-deny.Tpo -c actions/disruptive/deny.cc -o actions/disruptive/libmodsecurity_la-deny.o >/dev/null 2>&1 mv -f actions/disruptive/.deps/libmodsecurity_la-deny.Tpo actions/disruptive/.deps/libmodsecurity_la-deny.Plo /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL -DWITH_YAJL -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPCRE_HAVE_JIT -I/usr/local/include -DWITH_SSDEEP -I/usr/local/include -DWITH_MAXMIND -I/usr/local/include -DWITH_LUA -DWITH_LUA_5_4 -I/usr/local/include/lua54 -I/usr/local/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT actions/disruptive/libmodsecurity_la-drop.lo -MD -MP -MF actions/disruptive/.deps/libmodsecurity_la-drop.Tpo -c -o actions/disruptive/libmodsecurity_la-drop.lo `test -f 'actions/disruptive/drop.cc' || echo './'`actions/disruptive/drop.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL -DWITH_YAJL -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPCRE_HAVE_JIT -I/usr/local/include -DWITH_SSDEEP -I/usr/local/include -DWITH_MAXMIND -I/usr/local/include -DWITH_LUA -DWITH_LUA_5_4 -I/usr/local/include/lua54 -I/usr/local/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT actions/disruptive/libmodsecurity_la-drop.lo -MD -MP -MF actions/disruptive/.deps/libmodsecurity_la-drop.Tpo -c actions/disruptive/drop.cc -fPIC -DPIC -o actions/disruptive/.libs/libmodsecurity_la-drop.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -I/usr/local/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL -DWITH_YAJL -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPCRE_HAVE_JIT -I/usr/local/include -DWITH_SSDEEP -I/usr/local/include -DWITH_MAXMIND -I/usr/local/include -DWITH_LUA -DWITH_LUA_5_4 -I/usr/local/include/lua54 -I/usr/local/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT actions/disruptive/libmodsecurity_la-drop.lo -MD -MP -MF actions/disruptive/.deps/libmodsecurity_la-drop.Tpo -c actions/disruptive/drop.cc -o actions/disruptive/libmodsecurity_la-drop.o >/dev/null 2>&1 gmake[3]: *** [Makefile:2427: actions/disruptive/libmodsecurity_la-drop.lo] Error 1 gmake[3]: Leaving directory '/usr/home/mbaki/ModSecurity/src' gmake[2]: *** [Makefile:3505: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/home/mbaki/ModSecurity/src' gmake[1]: *** [Makefile:1239: all] Error 2 gmake[1]: Leaving directory '/usr/home/mbaki/ModSecurity/src' gmake: *** [Makefile:1049: all-recursive] Error 1 Thanks Monah |
From: Christian F. <chr...@ne...> - 2023-03-27 07:52:13
|
Hey Stephen, I am not familiar with HAProxy and this integration. But speaking from a general position, there is always a chance for a timeout, but the exact message (and the TON of them) is troubling. https://www.mail-archive.com/search?l=ha...@fo...&q=subject:%22Re%5C%3A+doubt+how+to+compile+modsecurity+module+for+HAproxy%22&o=newest&f=1 discusses this, but I am none the wiser now. I am not sure wether HAProxy closes the connection now or there was a timeout and HAProxy concludes the client closed the connection. Or whatever. I would try and do two things: - Raise the timeout and monitor for a general reduction of the number of messages. - Try to reproduce the error message on separate machine. That way you will learn what really is the problem - and if it is one from an operating standpoint (users not getting what they want) - or just noise (everybody gets their responses OK, but HAProxy is unhappy about connection termination and regularly complains. Good luck, Christian On Fri, Mar 24, 2023 at 04:37:03PM -0400, Stephen Schor wrote: > Hi All > > I've inherited a project that uses modsecurity (wrapped in > jcmoraisjr/modsecurity-spoa <https://github.com/jcmoraisjr/modsecurity-spoa> > ). > Looking at the modsecurity logs...I see plenty of legitimate log messages > when a SecRule is matched, but also > a TON of lines like this: > > 1679689652.575012 [01] <223243> Peer closed connection: a timeout occurred > > There isn't any additional info around these log lines, I'd appreciate if > folks can help a newcomer out and > help give some context about what causes these messages. Does this indicate > a slow client attack? > The need to adjust some config? Is this normal / expected? > > Thanks for your time, > Stephen > _______________________________________________ > 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: Stephen S. <beh...@gm...> - 2023-03-24 20:37:20
|
Hi All I've inherited a project that uses modsecurity (wrapped in jcmoraisjr/modsecurity-spoa <https://github.com/jcmoraisjr/modsecurity-spoa> ). Looking at the modsecurity logs...I see plenty of legitimate log messages when a SecRule is matched, but also a TON of lines like this: 1679689652.575012 [01] <223243> Peer closed connection: a timeout occurred There isn't any additional info around these log lines, I'd appreciate if folks can help a newcomer out and help give some context about what causes these messages. Does this indicate a slow client attack? The need to adjust some config? Is this normal / expected? Thanks for your time, Stephen |
From: homesh j. <ho...@gm...> - 2022-12-14 03:02:38
|
Thank you Christian. On Wed, 14 Dec, 2022, 3:46 am Christian Folini, <chr...@ne...> wrote: > Hi there, > > We looked at it from a CRS perspective. > > Detection is spotty at paranoia level 1, but CRS detects all the payloads > at PL2. There is pull request that aims to detect everything at PL1. > > https://github.com/coreruleset/coreruleset/pull/3055 > > Best, > > Christian > > On Tue, Dec 13, 2022 at 09:30:21PM +0530, homesh joshi wrote: > > Hi All, > > > > Has any one tested the new method mentioned here > > > https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf > > > > > > any successfully block the same with modsec ? > > > > Thanks, > > Homesh > > > > _______________________________________________ > > 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/ > |