mod-security-users — General discussion about mod_security

Re: [mod-security-users] GEO:COUNTRY_CODE returns an empty string

[Dan E. <da...@eh...>]

1. Can you trying running the command “lsof” to see if your GeoIP database file ever gets opened?

2. Also what’s the chmod on that maxminddb file?

3. Also also, have you tried putting it in “usr/local/share/GeoIP/GeoIP2-***.mmdb”. Maybe the ModSec 3 documentation says to do something different (not looking at it right now) but when using PHP/Go/Apache Web Server you’re always supposed to put it there.

4. Finally, you could try putting a small PHP program/file on your web server that prints out the country code (see the examples in the official PHP api by MaxMind: https://github.com/maxmind/GeoIP2-php/blob/master/README.md) to see if that works. This makes it much easier to troubleshoot.





Sent from my iPhone

> On Mar 11, 2019, at 8:30 AM, Felipe Costa <FC...@tr...> wrote:
> 
> Hi Juan,
> 
> Please, make sure that the IP is on the database with a country code record. The code is ready to fulfill the variable name and it is being tested here:
> 
> https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L627
> 
> https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L161
> 
> There are utilities like geoiplookup that allow you to query the IP address from the command line.
> 
> Br.,
> Felipe "Zimmerle" Costa
> Security Researcher, Lead Developer ModSecurity
> m: +55 81.98706.5547
>  
> 
> www.trustwave.com
>  
> Recognized by industry analysts as a leader in managed security services.
> 
> From: Juan Pablo Tosso <jt...@co...>
> Sent: Monday, March 4, 2019 10:36 PM
> To: mod...@li...
> Subject: [mod-security-users] GEO:COUNTRY_CODE returns an empty string
>  
> Hello, I have been trying to use geoip without success, I've tried with legacy format and new format, and updated databases.
> 
> This is the current code:
> SecGeoLookupDb /mnt/nginx/defaults/geoip/geoip.mmdb
> SecRule GEO:COUNTRY_CODE "CL" "id:111,deny,log,logdata:'test',phase:1"
> 
> I'm using modsecurity 3 in it's master branch with the nginx connector (master) and Nginx 1.15.9
> 
> I have also tried to print the value with tx but I receive a null value.
> 
> Thank you
> _______________________________________________
> 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] GEO:COUNTRY_CODE returns an empty string

[Felipe C. <FC...@tr...>]

Oh, Thank you for the report, Juan. I saw that it has a workaround. I will have a solid fix for it as soon as possible.

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Juan Pablo Tosso <jt...@co...>
Sent: Monday, March 11, 2019 10:34 AM
To: Felipe Costa
Cc: mod...@li...
Subject: Re: [mod-security-users] GEO:COUNTRY_CODE returns an empty string

Hello Felipe and thank you for your answer, it was actually related to issue #2033, the database was not working after reload.

You can "fix" it by removing geoip v1 from the configuration recipe.


On Mon, Mar 11, 2019, 10:30 AM Felipe Costa <FC...@tr...<mailto:FC...@tr...>> wrote:
Hi Juan,

Please, make sure that the IP is on the database with a country code record. The code is ready to fulfill the variable name and it is being tested here:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L627<https://scanmail.trustwave.com/?c=4062&d=keSG3CFIBPXWKTDyOxn2sw4H-9wVvywY4VDnk2bRcQ&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fv3%2fmaster%2ftest%2ftest-cases%2fregression%2fvariable-GEO%2ejson%23L627>

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L161<https://scanmail.trustwave.com/?c=4062&d=keSG3CFIBPXWKTDyOxn2sw4H-9wVvywY4QC4kjyLJA&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fv3%2fmaster%2ftest%2ftest-cases%2fregression%2fvariable-GEO%2ejson%23L161>

There are utilities like geoiplookup that allow you to query the IP address from the command line.

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Juan Pablo Tosso <jt...@co...>
Sent: Monday, March 4, 2019 10:36 PM
To: mod...@li...<mailto:mod...@li...>
Subject: [mod-security-users] GEO:COUNTRY_CODE returns an empty string

Hello, I have been trying to use geoip without success, I've tried with legacy format and new format, and updated databases.

This is the current code:
SecGeoLookupDb /mnt/nginx/defaults/geoip/geoip.mmdb
SecRule GEO:COUNTRY_CODE "CL" "id:111,deny,log,logdata:'test',phase:1"

I'm using modsecurity 3 in it's master branch with the nginx connector (master) and Nginx 1.15.9

I have also tried to print the value with tx but I receive a null value.

Thank you

Re: [mod-security-users] GEO:COUNTRY_CODE returns an empty string

[Juan P. T. <jt...@co...>]

Hello Felipe and thank you for your answer, it was actually related to
issue #2033, the database was not working after reload.

You can "fix" it by removing geoip v1 from the configuration recipe.


On Mon, Mar 11, 2019, 10:30 AM Felipe Costa <FC...@tr...> wrote:

> Hi Juan,
>
> Please, make sure that the IP is on the database with a country code
> record. The code is ready to fulfill the variable name and it is being
> tested here:
>
>
> https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L627
>
>
> https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L161
>
> There are utilities like geoiplookup that allow you to query the IP
> address from the command line.
>
> Br.,
>
> *Felipe "Zimmerle" Costa*
>
> Security Researcher, Lead Developer ModSecurity
>
> m: +55 81.98706.5547
>
>
>
> [image: signature_480191669]
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *Recognized by industry analysts as a leader in managed security services.
> <https://www.trustwave.com/company/about-us/accolades/>*
>
> ------------------------------
> *From:* Juan Pablo Tosso <jt...@co...>
> *Sent:* Monday, March 4, 2019 10:36 PM
> *To:* mod...@li...
> *Subject:* [mod-security-users] GEO:COUNTRY_CODE returns an empty string
>
> Hello, I have been trying to use geoip without success, I've tried with
> legacy format and new format, and updated databases.
>
> This is the current code:
> SecGeoLookupDb /mnt/nginx/defaults/geoip/geoip.mmdb
> SecRule GEO:COUNTRY_CODE "CL" "id:111,deny,log,logdata:'test',phase:1"
>
> I'm using modsecurity 3 in it's master branch with the nginx connector
> (master) and Nginx 1.15.9
>
> I have also tried to print the value with tx but I receive a null value.
>
> Thank you
>

Re: [mod-security-users] GEO:COUNTRY_CODE returns an empty string

[Felipe C. <FC...@tr...>]

Hi Juan,

Please, make sure that the IP is on the database with a country code record. The code is ready to fulfill the variable name and it is being tested here:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L627

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-GEO.json#L161

There are utilities like geoiplookup that allow you to query the IP address from the command line.

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Juan Pablo Tosso <jt...@co...>
Sent: Monday, March 4, 2019 10:36 PM
To: mod...@li...
Subject: [mod-security-users] GEO:COUNTRY_CODE returns an empty string

Hello, I have been trying to use geoip without success, I've tried with legacy format and new format, and updated databases.

This is the current code:
SecGeoLookupDb /mnt/nginx/defaults/geoip/geoip.mmdb
SecRule GEO:COUNTRY_CODE "CL" "id:111,deny,log,logdata:'test',phase:1"

I'm using modsecurity 3 in it's master branch with the nginx connector (master) and Nginx 1.15.9

I have also tried to print the value with tx but I receive a null value.

Thank you

[mod-security-users] GEO:COUNTRY_CODE returns an empty string

[Juan P. T. <jt...@co...>]

Hello, I have been trying to use geoip without success, I've tried with
legacy format and new format, and updated databases.

This is the current code:
SecGeoLookupDb /mnt/nginx/defaults/geoip/geoip.mmdb
SecRule GEO:COUNTRY_CODE "CL" "id:111,deny,log,logdata:'test',phase:1"

I'm using modsecurity 3 in it's master branch with the nginx connector
(master) and Nginx 1.15.9

I have also tried to print the value with tx but I receive a null value.

Thank you

[mod-security-users] ModSecurity with ClamAV on Windows

[Benjamin D. <bdi...@gm...>]

Hi,

I want to configure Apache with ModSecurity and ClamAV on Windows. I was
able to install all the software but now run into issues with the
integration between ModSecurity and ClamAV, it seems like ModSecurity is
not passing the file name to the perl script or perl can't read it:

I tested the perl script by itself and it working as expected:
perl runav.pl
C:\tmp\upload\20190304-153319-XH2Lj7J7UIOIOO4ofagtSwAAABo-file-a04592
I can specify a file name and it returns either 0 / 1 with the detailed
message

When I use ModSecurity no file name is passed in, the $#ARGV variable
returns -1 and the ModSecurity log shows the following message:
[...] by the approver script
"C:/Apps/Apache24/conf/modsecurity/owasp-modsecurity-crs/util/av-scanning/
runav.pl": Usage: runav.pl <filename>\ [...]

Does anyone have any suggestions? Any help would be appreciated!

My configuration is as follows:

modsecurity.conf:
...
SecTmpDir c:\tmp
SecDataDir c:\tmp\persistent
SecUploadDir c:\tmp\upload
...

The rule modsecurity_crs_46_av_scanning.conf

SecRule FILES_TMPNAMES "@inspectFile
C:/Apps/Apache24/conf/modsecurity/owasp-modsecurity-crs/util/av-scanning/
runav.pl" "id:2222, deny"

the runav.pl
# runav.pl
# Copyright (c) 2004-2011 Trustwave
#
# This script is an interface between ModSecurity and its
# ability to intercept files being uploaded through the
# web server, and ClamAV

use warnings;

#specify a log file
my $filename = 'clamAV.log';
open(my $fh, '>', $filename) or die "Could not open file '$filename' $!";

print $fh "Started Virus scan\n";


$CLAMSCAN = "C:/Progra~1/ClamAV/clamdscan.exe";
    print $fh "$#ARGV\n";

if ($#ARGV != 0) {
print "Usage: runav.pl <filename>\n";
print $fh "no file specified\n";
close $fh;
    exit;
}

my ($FILE) = shift @ARGV;

#Required for windows to convert slash/backslash properly
$FILE =~ tr{/}{\\};

$cmd = "$CLAMSCAN --stdout $FILE";
$input = `$cmd`;
$input =~ m/^(.+)/;
$error_message = $1;

$output = "0 Unable to parse clamscan output [$1]";

print "$error_message\n";

if ($error_message =~ m/: Empty file\.?$/) {
    $output = "1 empty file";
}
elsif ($error_message =~ m/: (.+) ERROR$/) {
    $output = "0 clamscan: $1";
}
elsif ($error_message =~ m/: (.+) FOUND$/) {
    $output = "0 clamscan: $1";
}
elsif ($error_message =~ m/: OK$/) {
    $output = "1 clamscan: OK";
}

close $fh;

print "$output\n";

[mod-security-users] Bls: CRS News for February 2019 published

[Davy G. <da...@ya...>]

I have a question recording creating custom rule in modsecurity -Do I have to create the following folder and file for custom rule - /modsecurity-crs/base_rules/custom_rule.conf

Since I only have the following folder /etc/httpd/modsecurity-crs/rules
Thanks in advance,Davy


Dikirim dari Yahoo Mail di Android 
 
  Pada Jum, 1 Mar 2019 pada 4:12, Christian Folini<chr...@ne...> menulis:   Hello,

The OWASP ModSecurity Core Rule Set project news for February 2019 are out

https://coreruleset.org/20190228/crs-project-news-february-2019/

Retweets are welcome:

https://twitter.com/CoreRuleSet/status/1101226355155496960

This month, we announce the CRS community summit at AppSecGlobal in Tel Aviv
in late May and news of a ModSecurity fork by Microsoft's Azure team.

Best,

Christian

-- 
One sign that you’ve approached actual mastery of a subject is that
you get less arrogant; because you’ve spent so much time being wrong.
-- Matthew D. Green



_______________________________________________
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] Bls: CRS News for February 2019 published

[Manuel S. <spa...@gm...>]

Hi tharr,
ARGS is a collection containing all parameters sent either in the url or the body depending on the method arg1=val&arg2=val2.
In json it will be the keys.

I recommend you read the reference manual and C.Folini’s book to get familiar with modsec.

Regards,
Manuel
Sent from my iPhone

> On 2 Mar 2019, at 02:19, Davy Gunarso via mod-security-users <mod...@li...> wrote:
> 
> Does any one knows what ARGS mean in modsecurity rule?
> 
> 
> Dikirim dari Yahoo Mail di Android
> 
> Pada Jum, 1 Mar 2019 pada 4:12, Christian Folini
> <chr...@ne...> menulis:
> Hello,
> 
> The OWASP ModSecurity Core Rule Set project news for February 2019 are out
> 
> https://coreruleset.org/20190228/crs-project-news-february-2019/
> 
> Retweets are welcome:
> 
> https://twitter.com/CoreRuleSet/status/1101226355155496960
> 
> This month, we announce the CRS community summit at AppSecGlobal in Tel Aviv
> in late May and news of a ModSecurity fork by Microsoft's Azure team.
> 
> Best,
> 
> Christian
> 
> -- 
> One sign that you’ve approached actual mastery of a subject is that
> you get less arrogant; because you’ve spent so much time being wrong.
> -- Matthew D. Green
> 
> 
> 
> _______________________________________________
> 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/
> <Untitled>
> _______________________________________________
> 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] Bls: CRS News for February 2019 published

[Davy G. <da...@ya...>]

Does any one knows what ARGS mean in modsecurity rule?

Dikirim dari Yahoo Mail di Android 
 
  Pada Jum, 1 Mar 2019 pada 4:12, Christian Folini<chr...@ne...> menulis:   Hello,

The OWASP ModSecurity Core Rule Set project news for February 2019 are out

https://coreruleset.org/20190228/crs-project-news-february-2019/

Retweets are welcome:

https://twitter.com/CoreRuleSet/status/1101226355155496960

This month, we announce the CRS community summit at AppSecGlobal in Tel Aviv
in late May and news of a ModSecurity fork by Microsoft's Azure team.

Best,

Christian

-- 
One sign that you’ve approached actual mastery of a subject is that
you get less arrogant; because you’ve spent so much time being wrong.
-- Matthew D. Green



_______________________________________________
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] CRS News for February 2019 published

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

Hello,

The OWASP ModSecurity Core Rule Set project news for February 2019 are out

https://coreruleset.org/20190228/crs-project-news-february-2019/

Retweets are welcome:

https://twitter.com/CoreRuleSet/status/1101226355155496960

This month, we announce the CRS community summit at AppSecGlobal in Tel Aviv
in late May and news of a ModSecurity fork by Microsoft's Azure team.

Best,

Christian

-- 
One sign that you’ve approached actual mastery of a subject is that
you get less arrogant; because you’ve spent so much time being wrong.
-- Matthew D. Green

Re: [mod-security-users] ctl:ruleRemoveById not working?

[<ltn...@an...>]

Hi,

holy c...! I completely missed the fact that the phase in the rule I want to disable (1) is before my whitelist ("request")..

Thanks a lot. Went quiet like in a grave in my Graylog now. Exactly the way I like it :)

/Eirik

> On 24 Feb 2019, at 18:56, Manuel Spartan <spa...@gm...> wrote:
> 
> Hi Eirik,
> 
> You could try setting the debug level to 4 and follow the order of execution and precedence of the rules, some cases requires the rule to be defined before you hit the rule they are modifying while others have to be processed before the rule you need to change.Let me try to explain it because it is a bit confusing.
> 
> Supposing you want to disable rule 1 you have many options that work and some that will not work like:
> 
> Inclusion order:
>  SecRule id:1
>  SecRuleRemoveById 1
> 
> Results in rule 1 disabled but if they are reversed it will not work as the rule 1 would be created after it was removed
> 
> Inclusion order (same phase):
>  SecRule id:1
>  SecRule id:2,ctl:RuleRemoveById=1
> 
> Results in rule 1 being processed before 2 is executed, unless rule 2 is included before 1
> 
> Inclusion order (different phases):
>  SecRule id:1,phase:2
>  SecRule id:2,phase:1ctl:RuleRemoveById=1
> 
> Results in rule 2 being processed before 1 is executed as the orders are evaluated by phase then by inclusion order
> 
> Cheers!
> 
> El dom., 24 feb. 2019 a las 11:20, <ltn...@an...> escribió:
> Hi again,
> 
> as always when I raise a question, it manage to butcher the test case. Due to a confusion about which CRS version was being used, the below is only partially true. My findings so far indicate that the initial SecRule fails to trigger, so the ctl: part (no matter if I use ruleRemoveById, ruleRemoveByTag or ruleRemoveTargetByTag) never takes effect.
> 
> I've tried variants of
> SecRule REQUEST_HEADERS:Content-Type "@unconditionalMatch"
> SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)"
> SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*"
> 
> to make it stick, to no avail. I'm not terribly experienced here and might be beating about the bush in all the wrong ways, but any help would be welcome. Sorry about the noise.
> 
> /Eirik
> 
> > On 24 Feb 2019, at 16:19, ltn...@an... wrote:
> > 
> > Hi all,
> > 
> > I feel like I'm going blind here, I'm sure the problem is obvious and (to me) embarrassing. But - I'm trying to write a whitelist rule that selectively disabled a specific rule:
> > 
> > # acs: Some clients stick charsets in content-type request headers
> > SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)" \
> >    "phase:request,id:1103,t:none,pass,nolog,tag:'md-debug',chain,\
> >        ctl:ruleRemoveById=920480"
> >            SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*" "t:none"
> > 
> > I know the matcher works, because when I use
> >        ctl:ruleRemoveTargetByTag='OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE_CHARSET';REQUEST_HEADERS:Content-Type"
> > 
> > the whitelist works as expected. I just think disabling the explicit rule would be the more correct/cheap thing to do.
> > 
> > What am I doing wrong?
> > libmodsecurity 3.0.3 and nginx on FreeBSD, CRS 3.1.0.
> > Note that it works with CRS 3.0.0 but I think rule 920480 is new in 3.1, so that would explain that part.
> > 
> > /Eirik
> > 
> > _______________________________________________
> > 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] ctl:ruleRemoveById not working?

[Manuel S. <spa...@gm...>]

Hi Eirik,

You could try setting the debug level to 4 and follow the order of
execution and precedence of the rules, some cases requires the rule to be
defined before you hit the rule they are modifying while others have to be
processed before the rule you need to change.Let me try to explain it
because it is a bit confusing.

Supposing you want to disable rule 1 you have many options that work and
some that will not work like:

Inclusion order:
 SecRule id:1
 SecRuleRemoveById 1

Results in rule 1 disabled but if they are reversed it will not work as the
rule 1 would be created after it was removed

Inclusion order (same phase):
 SecRule id:1
 SecRule id:2,ctl:RuleRemoveById=1

Results in rule 1 being processed before 2 is executed, unless rule 2 is
included before 1

Inclusion order (different phases):
 SecRule id:1,phase:2
 SecRule id:2,phase:1ctl:RuleRemoveById=1

Results in rule 2 being processed before 1 is executed as the orders are
evaluated by phase then by inclusion order

Cheers!

El dom., 24 feb. 2019 a las 11:20, <ltn...@an...> escribió:

> Hi again,
>
> as always when I raise a question, it manage to butcher the test case. Due
> to a confusion about which CRS version was being used, the below is only
> partially true. My findings so far indicate that the initial SecRule fails
> to trigger, so the ctl: part (no matter if I use ruleRemoveById,
> ruleRemoveByTag or ruleRemoveTargetByTag) never takes effect.
>
> I've tried variants of
> SecRule REQUEST_HEADERS:Content-Type "@unconditionalMatch"
> SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)"
> SecRule REQUEST_URI "@rx
> ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*"
>
> to make it stick, to no avail. I'm not terribly experienced here and might
> be beating about the bush in all the wrong ways, but any help would be
> welcome. Sorry about the noise.
>
> /Eirik
>
> > On 24 Feb 2019, at 16:19, ltn...@an... wrote:
> >
> > Hi all,
> >
> > I feel like I'm going blind here, I'm sure the problem is obvious and
> (to me) embarrassing. But - I'm trying to write a whitelist rule that
> selectively disabled a specific rule:
> >
> > # acs: Some clients stick charsets in content-type request headers
> > SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)" \
> >    "phase:request,id:1103,t:none,pass,nolog,tag:'md-debug',chain,\
> >        ctl:ruleRemoveById=920480"
> >            SecRule REQUEST_URI "@rx
> ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*" "t:none"
> >
> > I know the matcher works, because when I use
> >
> ctl:ruleRemoveTargetByTag='OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE_CHARSET';REQUEST_HEADERS:Content-Type"
> >
> > the whitelist works as expected. I just think disabling the explicit
> rule would be the more correct/cheap thing to do.
> >
> > What am I doing wrong?
> > libmodsecurity 3.0.3 and nginx on FreeBSD, CRS 3.1.0.
> > Note that it works with CRS 3.0.0 but I think rule 920480 is new in 3.1,
> so that would explain that part.
> >
> > /Eirik
> >
> > _______________________________________________
> > 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] ctl:ruleRemoveById not working?

[<ltn...@an...>]

Hi again,

as always when I raise a question, it manage to butcher the test case. Due to a confusion about which CRS version was being used, the below is only partially true. My findings so far indicate that the initial SecRule fails to trigger, so the ctl: part (no matter if I use ruleRemoveById, ruleRemoveByTag or ruleRemoveTargetByTag) never takes effect.

I've tried variants of
SecRule REQUEST_HEADERS:Content-Type "@unconditionalMatch"
SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)"
SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*"

to make it stick, to no avail. I'm not terribly experienced here and might be beating about the bush in all the wrong ways, but any help would be welcome. Sorry about the noise.

/Eirik

> On 24 Feb 2019, at 16:19, ltn...@an... wrote:
> 
> Hi all,
> 
> I feel like I'm going blind here, I'm sure the problem is obvious and (to me) embarrassing. But - I'm trying to write a whitelist rule that selectively disabled a specific rule:
> 
> # acs: Some clients stick charsets in content-type request headers
> SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)" \
>    "phase:request,id:1103,t:none,pass,nolog,tag:'md-debug',chain,\
>        ctl:ruleRemoveById=920480"
>            SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*" "t:none"
> 
> I know the matcher works, because when I use
>        ctl:ruleRemoveTargetByTag='OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE_CHARSET';REQUEST_HEADERS:Content-Type"
> 
> the whitelist works as expected. I just think disabling the explicit rule would be the more correct/cheap thing to do.
> 
> What am I doing wrong?
> libmodsecurity 3.0.3 and nginx on FreeBSD, CRS 3.1.0.
> Note that it works with CRS 3.0.0 but I think rule 920480 is new in 3.1, so that would explain that part.
> 
> /Eirik
> 
> _______________________________________________
> 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] ctl:ruleRemoveById not working?

[<ltn...@an...>]

Hi all,

I feel like I'm going blind here, I'm sure the problem is obvious and (to me) embarrassing. But - I'm trying to write a whitelist rule that selectively disabled a specific rule:

# acs: Some clients stick charsets in content-type request headers
SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)" \
    "phase:request,id:1103,t:none,pass,nolog,tag:'md-debug',chain,\
        ctl:ruleRemoveById=920480"
            SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*" "t:none"

I know the matcher works, because when I use
        ctl:ruleRemoveTargetByTag='OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE_CHARSET';REQUEST_HEADERS:Content-Type"

the whitelist works as expected. I just think disabling the explicit rule would be the more correct/cheap thing to do.

What am I doing wrong?
libmodsecurity 3.0.3 and nginx on FreeBSD, CRS 3.1.0.
Note that it works with CRS 3.0.0 but I think rule 920480 is new in 3.1, so that would explain that part.

/Eirik

Re: [mod-security-users] HTTP/1.1 405 Method Not Allowed

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

:)

On Thu, Feb 21, 2019 at 10:52:46AM -0300, Felipe Rocha wrote:
> xmlrpc.php only accepts POST. it's within wordpress code. no worries
> 
> 
> On Thu, Feb 21, 2019 at 2:56 AM Eero Volotinen <eer...@ik...>
> wrote:
> 
> > Check allowed methods from config file..
> >
> > On Thu, Feb 21, 2019, 07:52 Brent Clark <bre...@gm...> wrote:
> >
> >> Good day Guys
> >>
> >> I am seeing the following.
> >>
> >> https://pastebin.com/raw/j6TfasPd
> >>
> >> Could anyone share some light on what the problem could be, and how I
> >> can resolve the above.
> >>
> >> I am rolling out a very small subset of rules to get started, which you
> >> can see here.
> >>
> >> https://pastebin.com/raw/6ZywmqqQ
> >>
> >> Thanks
> >>
> >> Regards
> >> Brent
> >>
> >>
> >> _______________________________________________
> >> 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/
> >
> 
> 
> -- 
> *Nenhum Sonho é grande demais.*


> _______________________________________________
> 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] HTTP/1.1 405 Method Not Allowed

[Felipe R. <fel...@gm...>]

xmlrpc.php only accepts POST. it's within wordpress code. no worries


On Thu, Feb 21, 2019 at 2:56 AM Eero Volotinen <eer...@ik...>
wrote:

> Check allowed methods from config file..
>
> On Thu, Feb 21, 2019, 07:52 Brent Clark <bre...@gm...> wrote:
>
>> Good day Guys
>>
>> I am seeing the following.
>>
>> https://pastebin.com/raw/j6TfasPd
>>
>> Could anyone share some light on what the problem could be, and how I
>> can resolve the above.
>>
>> I am rolling out a very small subset of rules to get started, which you
>> can see here.
>>
>> https://pastebin.com/raw/6ZywmqqQ
>>
>> Thanks
>>
>> Regards
>> Brent
>>
>>
>> _______________________________________________
>> 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/
>


-- 
*Nenhum Sonho é grande demais.*

Re: [mod-security-users] HTTP/1.1 405 Method Not Allowed

[Eero V. <eer...@ik...>]

Check allowed methods from config file..

On Thu, Feb 21, 2019, 07:52 Brent Clark <bre...@gm...> wrote:

> Good day Guys
>
> I am seeing the following.
>
> https://pastebin.com/raw/j6TfasPd
>
> Could anyone share some light on what the problem could be, and how I
> can resolve the above.
>
> I am rolling out a very small subset of rules to get started, which you
> can see here.
>
> https://pastebin.com/raw/6ZywmqqQ
>
> Thanks
>
> Regards
> Brent
>
>
> _______________________________________________
> 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] HTTP/1.1 405 Method Not Allowed

[Brent C. <bre...@gm...>]

Good day Guys

I am seeing the following.

https://pastebin.com/raw/j6TfasPd

Could anyone share some light on what the problem could be, and how I 
can resolve the above.

I am rolling out a very small subset of rules to get started, which you 
can see here.

https://pastebin.com/raw/6ZywmqqQ

Thanks

Regards
Brent

Re: [mod-security-users] Management Console for ModSecurity

[Germán C. <gch...@gm...>]

I'll check it out. Thank you

On Fri, Feb 8, 2019 at 2:10 PM Christian Varas <cv...@it...> wrote:

> There is one
>
> https://github.com/ITSec-Chile/Waf2Py
> http://www.waf2py.org
>
> Cheers.
>
> El vie., 8 feb. 2019 13:35, Germán Chialli <gch...@gm...> escribió:
>
>> Hello all,
>>
>> Need your help with a question... Is there any Web Based Management
>> Console for ModSecurity out there? Anything that you can recommend?
>>
>> Thank you
>> _______________________________________________
>> 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] Management Console for ModSecurity

[Christian V. <cv...@it...>]

There is one

https://github.com/ITSec-Chile/Waf2Py
http://www.waf2py.org

Cheers.

El vie., 8 feb. 2019 13:35, Germán Chialli <gch...@gm...> escribió:

> Hello all,
>
> Need your help with a question... Is there any Web Based Management
> Console for ModSecurity out there? Anything that you can recommend?
>
> Thank you
> _______________________________________________
> 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] Management Console for ModSecurity

[Germán C. <gch...@gm...>]

Hello all,

Need your help with a question... Is there any Web Based Management Console
for ModSecurity out there? Anything that you can recommend?

Thank you

Re: [mod-security-users] Compiling modsecurity with yajl

[Felipe C. <FC...@tr...>]

Great news :)

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Germán Chialli <gch...@gm...>
Sent: Tuesday, February 5, 2019 4:25 PM
To: mod...@li...
Subject: Re: [mod-security-users] Compiling modsecurity with yajl

Hello,
I managed to get it to work downloading ModSecurity's source again and compiling it from scratch.
Thanks for your help!

On Tue, Feb 5, 2019 at 2:25 PM Felipe Costa <FC...@tr...<mailto:FC...@tr...>> wrote:

Hi German,


Are you sure that the mod_security2.so<http://scanmail.trustwave.com/?c=4062&d=pdXZ3EmthTkR1bC_wN2yEbaaguAG4kLME3eVSbSJVg&s=5&u=http%3a%2f%2fmod%5fsecurity2%2eso> is the most recent compiled one? Did you manage to start this compilation process in a clean environment?


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Germán Chialli <gch...@gm...<mailto:gch...@gm...>>
Sent: Thursday, January 31, 2019 2:42:48 PM
To: mod...@li...<mailto:mod...@li...>
Subject: [mod-security-users] Compiling modsecurity with yajl

Hi all,

I'm trying to get the JSON parser to work with modsecurity 2.9.2 with Apache HTTPD. I have followed instructions from this link:
https://gist.github.com/rpfilomeno/1140359f4bd360137a98#file-modsecurity-installation-owasp-crs-for-centos-6-5-L22<https://scanmail.trustwave.com/?c=4062&d=pdXZ3EmthTkR1bC_wN2yEbaaguAG4kLMEyKSFeGPUg&s=5&u=https%3a%2f%2fgist%2egithub%2ecom%2frpfilomeno%2f1140359f4bd360137a98%23file-modsecurity-installation-owasp-crs-for-centos-6-5-L22>

I can see that yajl is found when I run the configure script. I see the following in the config.log:
$ cat config.log | grep yajl
  $ ./configure --with-yajl=/usr/local/lib /usr/local
configure:15950: checking for libyajl config script
configure:16071: using yajl v2.1.1
YAJL_CFLAGS='-DWITH_YAJL -I/usr/local/include/yajl  '
YAJL_LDADD='-lyajl  '
YAJL_LIBS='-lyajl  '

However after restarting apache, I still see the JSON support nor enabled error. Also, ldd mod_security2.so<http://scanmail.trustwave.com/?c=4062&d=pdXZ3EmthTkR1bC_wN2yEbaaguAG4kLME3eVSbSJVg&s=5&u=http%3a%2f%2fmod%5fsecurity2%2eso> doesn't show yajl.

What am I missing?

Thanks in advance,
Germán

_______________________________________________
mod-security-users mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-users<https://scanmail.trustwave.com/?c=4062&d=pdXZ3EmthTkR1bC_wN2yEbaaguAG4kLME3DARebcAw&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-users>
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/<http://scanmail.trustwave.com/?c=4062&d=pdXZ3EmthTkR1bC_wN2yEbaaguAG4kLMEyKSEb-IBw&s=5&u=http%3a%2f%2fwww%2emodsecurity%2eorg%2fprojects%2fcommercial%2frules%2f>
http://www.modsecurity.org/projects/commercial/support/<http://scanmail.trustwave.com/?c=4062&d=pdXZ3EmthTkR1bC_wN2yEbaaguAG4kLMEyOWQ7PcUg&s=5&u=http%3a%2f%2fwww%2emodsecurity%2eorg%2fprojects%2fcommercial%2fsupport%2f>

Re: [mod-security-users] Compiling modsecurity with yajl

[Germán C. <gch...@gm...>]

Hello,
I managed to get it to work downloading ModSecurity's source again and
compiling it from scratch.
Thanks for your help!

On Tue, Feb 5, 2019 at 2:25 PM Felipe Costa <FC...@tr...> wrote:

> Hi German,
>
>
> Are you sure that the mod_security2.so is the most recent compiled one?
> Did you manage to start this compilation process in a clean environment?
>
>
> Br.,
>
> *Felipe "Zimmerle" Costa*
>
> Security Researcher, Lead Developer ModSecurity
>
> m: +55 81.98706.5547
>
>
>
> [image: signature_480191669]
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
> *Recognized by industry analysts as a leader in managed security services.
> <https://www.trustwave.com/company/about-us/accolades/>*
>
> ------------------------------
> *From:* Germán Chialli <gch...@gm...>
> *Sent:* Thursday, January 31, 2019 2:42:48 PM
> *To:* mod...@li...
> *Subject:* [mod-security-users] Compiling modsecurity with yajl
>
> Hi all,
>
> I'm trying to get the JSON parser to work with modsecurity 2.9.2 with
> Apache HTTPD. I have followed instructions from this link:
>
> https://gist.github.com/rpfilomeno/1140359f4bd360137a98#file-modsecurity-installation-owasp-crs-for-centos-6-5-L22
> <https://scanmail.trustwave.com/?c=4062&d=mqbT3OoFvcK9m4kp3T8f4ZtXViQ38OQ-NzM6ieGW4A&s=5&u=https%3a%2f%2fgist%2egithub%2ecom%2frpfilomeno%2f1140359f4bd360137a98%23file-modsecurity-installation-owasp-crs-for-centos-6-5-L22>
>
> I can see that yajl is found when I run the configure script. I see the
> following in the config.log:
> $ cat config.log | grep yajl
>   $ ./configure --with-yajl=/usr/local/lib /usr/local
> configure:15950: checking for libyajl config script
> configure:16071: using yajl v2.1.1
> YAJL_CFLAGS='-DWITH_YAJL -I/usr/local/include/yajl  '
> YAJL_LDADD='-lyajl  '
> YAJL_LIBS='-lyajl  '
>
> However after restarting apache, I still see the JSON support nor enabled
> error. Also, ldd mod_security2.so
> <http://scanmail.trustwave.com/?c=4062&d=mqbT3OoFvcK9m4kp3T8f4ZtXViQ38OQ-N2Y91bSQ5A&s=5&u=http%3a%2f%2fmod%5fsecurity2%2eso>
> doesn't show yajl.
>
> What am I missing?
>
> Thanks in advance,
> Germán
>
> _______________________________________________
> 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] Compiling modsecurity with yajl

[Felipe C. <FC...@tr...>]

Hi German,


Are you sure that the mod_security2.so is the most recent compiled one? Did you manage to start this compilation process in a clean environment?


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Germán Chialli <gch...@gm...>
Sent: Thursday, January 31, 2019 2:42:48 PM
To: mod...@li...
Subject: [mod-security-users] Compiling modsecurity with yajl

Hi all,

I'm trying to get the JSON parser to work with modsecurity 2.9.2 with Apache HTTPD. I have followed instructions from this link:
https://gist.github.com/rpfilomeno/1140359f4bd360137a98#file-modsecurity-installation-owasp-crs-for-centos-6-5-L22<https://scanmail.trustwave.com/?c=4062&d=mqbT3OoFvcK9m4kp3T8f4ZtXViQ38OQ-NzM6ieGW4A&s=5&u=https%3a%2f%2fgist%2egithub%2ecom%2frpfilomeno%2f1140359f4bd360137a98%23file-modsecurity-installation-owasp-crs-for-centos-6-5-L22>

I can see that yajl is found when I run the configure script. I see the following in the config.log:
$ cat config.log | grep yajl
  $ ./configure --with-yajl=/usr/local/lib /usr/local
configure:15950: checking for libyajl config script
configure:16071: using yajl v2.1.1
YAJL_CFLAGS='-DWITH_YAJL -I/usr/local/include/yajl  '
YAJL_LDADD='-lyajl  '
YAJL_LIBS='-lyajl  '

However after restarting apache, I still see the JSON support nor enabled error. Also, ldd mod_security2.so<http://scanmail.trustwave.com/?c=4062&d=mqbT3OoFvcK9m4kp3T8f4ZtXViQ38OQ-N2Y91bSQ5A&s=5&u=http%3a%2f%2fmod%5fsecurity2%2eso> doesn't show yajl.

What am I missing?

Thanks in advance,
Germán

Re: [mod-security-users] Issue with ModSecurity and my proxy

[Felipe C. <FC...@tr...>]

Hi,


ModSecurity uses libCurl to download the rules. If it works with the command line `curl', it is likely to work with the library as well.


Make sure that the proxy variable is also set for your httpd user. During the startup process, Apache may change users losing the environment variables that you have set in your console.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: service maintenanceinfotel <ser...@ms...>
Sent: Monday, February 4, 2019 3:10:47 PM
To: mod...@li...
Cc: FONTVIELLE Thibault; Ben...@co...; Mic...@co...
Subject: [mod-security-users] Issue with ModSecurity and my proxy


Hello Community,



Here’s my problem :



The server where I have to install ModSecurity must pass by a proxy server to join internet



Therefore, I configure this on my debian :



export http_proxy=http://myproxy.com:8080

export https_proxy=http://myproxy.com:8080



Then, ModSecurity has to download the https://dashboard.modsecurity.org/rules/download/plain<https://scanmail.trustwave.com/?c=4062&d=gPnY3CFFaGiyHevQZVijsBqHuTG8GzOh4-c8x8Yz9Q&s=5&u=https%3a%2f%2fdashboard%2emodsecurity%2eorg%2frules%2fdownload%2fplain>



Here’s what happen on my WAF server when I reload apache2 :



[cid:image001.jpg@01D4BC9F.381D4010]



We have a TCP RETRANSMISSION



But when I try to wget on this link, it works :



[cid:image002.jpg@01D4BC9F.381D4010]



It takes into account my export http_proxy from before



And If I try this wget on my proxy server, of course it works :



[cid:image003.jpg@01D4BC9F.381D4010]



My proxy doesn’t block the link



When I reload apache and tshark the 443 on my proxy, I don’t see anything : no accept, no reject etc…



There’s nothing between my proxy and my WAF



My theory is that ModSecurity does not take into account the proxy rules I’ve set on my debian OS



So, If you don’t see any other source about my problem, my main question is :



How to force ModSecurity to pass by my proxy to download and synchronize the rules ?



Thank you for your help



Regards,



BC



Ce message est confidentiel. Son contenu ne represente en aucun cas un
engagement de la part de la Mutuelle Saint-Christophe assurances sous reserve de
tout accord conclu par ecrit entre vous et la Mutuelle Saint-Christophe assurances.
Toute publication, utilisation ou diffusion, meme partielle, doit etre
autorisee prealablement. Si vous n'etes pas destinataire de ce message,
merci d'en avertir immediatement l'expediteur.

This message is confidential. Its contents do not constitute a
commitment by Mutuelle Saint-Christophe assurances except where provided for in
a written agreement between you and Mutuelle Saint-Christophe assurances. Any
unauthorised disclosure, use or dissemination, either whole or partial, is
prohibited. If you are not the intended recipient of the message, please
notify the sender immediately.