mod-security-users — General discussion about mod_security

Re: [mod-security-users] execute a script for all rules

[Franziska B. <fra...@gm...>]

Hi Hans!

To me, it's not clear what you're trying to achieve.
You would probably have to write a new rule that checks whether rules have
matched and therefore the blocking variables inbound or outbound (e.g.
tx.blocking_inbound_anomaly_score) are set. And then you "exec:" and call
your script in this new rule.
You can't test for individual rules, or at least I don't see how that could
work right now.

Best,
Franziska
# CRS dev-on-duty

Am Mi., 20. März 2024 um 21:03 Uhr schrieb Hans Mayer via
mod-security-users <mod...@li...>:

>
> Dear All,
>
> I am using Apache/2.4.57 on Debian with the modsecurity-crs package
> which is Producer ModSecurity for Apache/2.9.3 and Rule Set
> OWASP_CRS/3.3.0
>
> With self written rules I have the possibility to execute a script with
> the "exec:" statement.
>
> Is there a way to execute a script for all these predefined rules if
> they are triggered ?
>
>
> Kind regards
>
> Hans
>
> --
>
>
>
>
>
>
>
> _______________________________________________
> 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] execute a script for all rules

[Hans M. <mo...@ma...>]

Dear All,

I am using Apache/2.4.57 on Debian with the modsecurity-crs package 
which is Producer ModSecurity for Apache/2.9.3 and Rule Set  OWASP_CRS/3.3.0

With self written rules I have the possibility to execute a script with 
the "exec:" statement.

Is there a way to execute a script for all these predefined rules if 
they are triggered ?


Kind regards

Hans

-- 

Re: [mod-security-users] alternatives for waf-fle

[Hans M. <mo...@ma...>]

Dear All,

not sure if everyone realised that there is a new fork of waf-fle

https://github.com/LucaRastrelli/waf-fle

It supports PHP 8.2 and MySQL 8

Sorry for this slightly off-topic message, but there is no dedicated 
waf-fle mailing list and mod-sec without any useful possibility to view 
the logs makes no sense.

// Hans

-- 


On 07.02.24 23:15, Hans Mayer via mod-security-users wrote:
>
> 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
>

[mod-security-users] Contact Comodo ModSecurity Rules team

[Christian F. <chr...@ne...>]

Hi there,

I've tried to get in touch with the Comodo ModSecurity / rules team.

This is about OWASP taking over ModSecurity and talking to them as rules
vendor.

However, I can't find any useful email address and the enterprise sales
I tried did not get back to me.

Unless my memory fails me, I've never had any contact with Comodo.

So if you know anybody at Comodo or you have a contact for me, then please
share via DM. Alternatively, please tell them to get in touch with me.

Best,

Christian Folini, OWASP ModSecurity Co-Lead


-- 
You work to make a dream come true, you do not whine it into existence.
-- Arnold Schwarzenegger

[mod-security-users] Contact to Atomicorp

[Christian F. <chr...@ne...>]

Hi there,

Ever since OWASP took over the ModSecurity project, I tried to talk to
Atomicorp. But no response.

I had contact with Mike Shinn before, but no response anymore.

I also tried Scott and Charity in the meantime, but dead silence.

It's kind of important we talk with the various rule vendors and if Atomicorp
does not response they will be left out when we develop the ModSecurity 
roadmap.

If you are one of their customers, if you have contact with them, then please
tell them to response. If you have infos for me, then please DM.

Best,

Christian Folini, OWASP ModSecurity Co-Lead

-- 
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
--- Douglas Adams

[mod-security-users] X-Post: CRS version 4.0.0 is out

[Christian F. <chr...@ne...>]

Dear ModSecurity users,

Let CRS 4 be your valentine!

The OWASP CRS team is proud to announce the release of CRS 4.0.

* https://github.com/coreruleset/coreruleset/releases/tag/v4.0.0

The release brings some 500 changes including the new plugin architecture.

More important updates:

* Early-Blocking option
* Over 500 individual rule bypasses closed following a big Bug Bounty project
* New web shell detection
* Full RE2/Hyperscan compatibility for better performance
* Support for HTTP/3
* More granular reporting options

Please read the detailed blog post coming with this release at

* https://coreruleset.org/20240214/let-crs-4-be-your-valentine/

or the full CHANGES file at 

* https://github.com/coreruleset/coreruleset/blob/v4.0/dev/CHANGES.md

With the best regards,

Christian Folini on behalf of the OWASP CRS team

-- 
The purpose of computing is insight not numbers.
-- Richard W. Hamming

Re: [mod-security-users] alternatives for waf-fle

[Steve M. <sm...@so...>]

Hans,

> Is there also a dashboard and visual libraries available in kibana for "mod-sec" logs ?

Not that I know of.  (Since there isn't a single definitive mapping of mod_security's log fields onto Elastic Common Schema, each user is probably going to create different field mappings, so one user's dashboards/visualizations wouldn't be usable on another user's system.)

Steve

Re: [mod-security-users] alternatives for waf-fle

[Hans M. <mo...@ma...>]

Hi Steve,

many thanks for your hint.

I stumbled already over ELK as log viewer for "mod-sec" a while ago.

I am using the ELK stack on a different server for different services 
over many years and I am a fan of this great application. But as you 
wrote, it needs a lot of resources. This was the benefit of "waf-fle" as 
it used really less memory and CPU resources. And it was the reason for 
me not to switch from "waf-fle" away to ELK some time ago.

But now I will give it a try maybe.

I don't know "draff" but it seems that "draff" isn't really needed.

Is there also a dashboard and visual libraries available in kibana for 
"mod-sec" logs ? If not then it's not an challenge. I developed already 
some.


Kind regards

Hans


-- 




On 08.02.24 21:32, Steve Mokris wrote:
> Hans,
>
>> Now I am looking for an alternative to view the alert logs.
>
> FWIW, here's a summary of the setup that my team has been using for realtime mod_security log aggregation/browsing/monitoring:
>
> On each web host:
>
>     - configure mod_security to log to a newline-delimited JSON file (`SecAuditLogFormat JSON`)
>     - use Filebeat <https://github.com/elastic/beats> to send the log data to a central log server
>
> On the central log server:
>
>     - use Logstash <https://github.com/elastic/logstash> to receive the log data from all hosts, extract relevant information from the individual fields, and send it to Elasticsearch
>     - use Elasticsearch <https://github.com/elastic/elasticsearch> as the backend to store/index/search the log data
>     - use Kibana <https://github.com/elastic/kibana> as the web interface to perform search queries, browse individual log events, and view aggregated data as charts
>     - use Draff <https://github.com/kosada/draff> to provide daily email summaries of interesting/unusual events
>
> This setup is more flexible than WAF-FLE — you can use it to process and browse many kinds of log data, not just mod_security.  In our case, we have it ingest system logs + Apache httpd access/error logs + web application logs into the same database as mod_security logs, since it's often helpful to browse related events — e.g. the series of HTTP requests leading up to a mod_security audit event.  But the drawback is that it requires more system resources than WAF-FLE (the combination of Logstash + Elasticsearch + Kibana is fairly heavyweight), and more effort to configure it initially (while Logstash supports parsing JSON, it doesn't have any specific built-in knowledge of mod_security's JSON schema).
>
> Steve

Re: [mod-security-users] alternatives for waf-fle

[Hans M. <mo...@ma...>]

Hi Ervin,

I am not sure if I want to go with an old PHP version.  I am not the one 
who uses always the latest version but during my 40 years working 
experience with UNIX I realized that there is a point where old versions 
are hard to maintain and brings more incompatibility than advantages.

In the meantime it seems that's not only the PHP version is the issue. 
It is also the Apache mode which is now FPM/FastCGI and was obviously 
not the case before. I will investigate a little bit how to switch this 
Apache mode but in general it's time for an other solution than "waf-fle".

"mod-sec" is a great tool and I don't want to loose it, just because 
there is no easy tool to view the logs.


Kind regards

Hans


-- 



On 08.02.24 21:27, Ervin Hegedüs wrote:
> Hi Hans,
>
> On Thu, Feb 08, 2024 at 05:57:11PM +0100, Hans Mayer wrote:
>>> (actually I don't understand what does it mean "by klaubert")
>> Sorry, if I didn't explain understandable what's the issue. The maintainer
>> for "waf-fle" is klaubert. Here the link at GitHub:
>> https://github.com/klaubert/waf-fle
> oh, sorry for my dump question :), I should have looked up.
>   
>> Apache with mod-sec is working fine. But waf-fle is not working any more.
>> "waf-fle" was the tool to display the alerts coming from mod-sec.
>> "waf-fle" is written in PHP and obviously using calls, which are not supported any more, like "apache_setenv()"
>>
>> So I am looking for an alternative to view the log entries generated by "mod-sec"
>>
>> I hope this explains a little bit more my issue.
> yes, definitely. Especially you mentioned that the waf-fle does
> not work with the new 8.2 PHP version.
>
> First your might try to add an older version of PHP:
>
> https://packages.sury.org/php/
>
> Sury (he is the official maintainer of PHP packages in Debian)
> supports older versions of PHP - perhaps those do not have any
> security updates, but at least work.
>
>
>
> Regards,
>
>
> a.

Re: [mod-security-users] alternatives for waf-fle

[Steve M. <sm...@so...>]

Hans,

> Now I am looking for an alternative to view the alert logs.


FWIW, here's a summary of the setup that my team has been using for realtime mod_security log aggregation/browsing/monitoring:

On each web host:

   - configure mod_security to log to a newline-delimited JSON file (`SecAuditLogFormat JSON`)
   - use Filebeat <https://github.com/elastic/beats> to send the log data to a central log server

On the central log server:

   - use Logstash <https://github.com/elastic/logstash> to receive the log data from all hosts, extract relevant information from the individual fields, and send it to Elasticsearch
   - use Elasticsearch <https://github.com/elastic/elasticsearch> as the backend to store/index/search the log data
   - use Kibana <https://github.com/elastic/kibana> as the web interface to perform search queries, browse individual log events, and view aggregated data as charts
   - use Draff <https://github.com/kosada/draff> to provide daily email summaries of interesting/unusual events

This setup is more flexible than WAF-FLE — you can use it to process and browse many kinds of log data, not just mod_security.  In our case, we have it ingest system logs + Apache httpd access/error logs + web application logs into the same database as mod_security logs, since it's often helpful to browse related events — e.g. the series of HTTP requests leading up to a mod_security audit event.  But the drawback is that it requires more system resources than WAF-FLE (the combination of Logstash + Elasticsearch + Kibana is fairly heavyweight), and more effort to configure it initially (while Logstash supports parsing JSON, it doesn't have any specific built-in knowledge of mod_security's JSON schema).

Steve

Re: [mod-security-users] alternatives for waf-fle

[Ervin H. <ai...@gm...>]

Hi Hans,

On Thu, Feb 08, 2024 at 05:57:11PM +0100, Hans Mayer wrote:
> > (actually I don't understand what does it mean "by klaubert")
> 
> Sorry, if I didn't explain understandable what's the issue. The maintainer
> for "waf-fle" is klaubert. Here the link at GitHub:
> https://github.com/klaubert/waf-fle

oh, sorry for my dump question :), I should have looked up.
 
> Apache with mod-sec is working fine. But waf-fle is not working any more.
> "waf-fle" was the tool to display the alerts coming from mod-sec.
> "waf-fle" is written in PHP and obviously using calls, which are not supported any more, like "apache_setenv()"
> 
> So I am looking for an alternative to view the log entries generated by "mod-sec"
> 
> I hope this explains a little bit more my issue.

yes, definitely. Especially you mentioned that the waf-fle does
not work with the new 8.2 PHP version.

First your might try to add an older version of PHP:

https://packages.sury.org/php/

Sury (he is the official maintainer of PHP packages in Debian)
supports older versions of PHP - perhaps those do not have any
security updates, but at least work.



Regards,


a.

Re: [mod-security-users] alternatives for waf-fle

[Hans M. <mo...@ma...>]

Hi Ervin,

many thanks for your swift reply.

 > (actually I don't understand what does it mean "by klaubert")

Sorry, if I didn't explain understandable what's the issue. The 
maintainer for "waf-fle" is klaubert. Here the link at GitHub: 
https://github.com/klaubert/waf-fle

> could you explain what's wrong with your setup? I mean what does
it mean "doesn't work".

Apache with mod-sec is working fine. But waf-fle is not working any more.
"waf-fle" was the tool to display the alerts coming from mod-sec.
"waf-fle" is written in PHP and obviously using calls, which are not supported any more, like "apache_setenv()"

So I am looking for an alternative to view the log entries generated by "mod-sec"

I hope this explains a little bit more my issue.

Kind regards
Hans

-- 


On 07.02.24 23:33, Ervin Hegedüs wrote:
> Hi Hans,
>
> On Wed, Feb 07, 2024 at 11:15:27PM +0100, Hans Mayer via mod-security-users wrote:
>> 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 don't understand what does it mean "by klaubert")
>
> could you explain what's wrong with your setup? I mean what does
> it mean "doesn't work".
>
> (Note that I'm the maintainer of libapache2-mod-security2 package
> in Debian, so it's important to know me what's the issue.)
>
>> 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 ?
> If your package does not work (for some reason) could you try
> this repository?
>
> https://modsecurity.digitalwave.hu
>
> Thanks,
>
>
> a.
>   

Re: [mod-security-users] alternatives for waf-fle

[Ervin H. <ai...@gm...>]

Hi Hans,

On Wed, Feb 07, 2024 at 11:15:27PM +0100, Hans Mayer via mod-security-users wrote:
> 
> 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 don't understand what does it mean "by klaubert")

could you explain what's wrong with your setup? I mean what does
it mean "doesn't work".

(Note that I'm the maintainer of libapache2-mod-security2 package
in Debian, so it's important to know me what's the issue.)

> 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 ?

If your package does not work (for some reason) could you try
this repository?

https://modsecurity.digitalwave.hu

Thanks,


a.
 

[mod-security-users] alternatives for waf-fle

[Hans M. <mo...@ma...>]

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

-- 

Re: [mod-security-users] Json Request Body Parser doesn't respect charset=iso8859-1

[<az...@po...>]

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/

Re: [mod-security-users] Apache reverse proxy timeout value

[Christian F. <chr...@ne...>]

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/

Re: [mod-security-users] Apache reverse proxy timeout value

[homesh j. <ho...@gm...>]

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] Json Request Body Parser doesn't respect charset=iso8859-1

[Beckert <be...@gm...>]

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

Re: [mod-security-users] obsolete macros in running build.sh

[Ervin H. <ai...@gm...>]

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.

[mod-security-users] obsolete macros in running build.sh

[mahh m <muh...@gm...>]

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?

[mod-security-users] More information about security issue - CVE 2024-1019

[Ervin H. <ai...@gm...>]

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

[mod-security-users] Announcing ModSecurity release 3.0.12

[Ervin H. <ai...@gm...>]

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

Re: [mod-security-users] Apache reverse proxy timeout value

[Christian F. <chr...@ne...>]

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] Apache reverse proxy timeout value

[homesh j. <ho...@gm...>]

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

[mod-security-users] Future of ModSecurity

[Ervin H. <ai...@gm...>]

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.