mod-security-users — General discussion about mod_security

Re: [mod-security-users] WAF file and folder locations

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

Hi Peter,

On Tue, Jan 22, 2019 at 02:07:28PM +0100, Peter Bittner wrote:
> I'm looking for documentation (or a source file) listing the configurable
> folders of the WAF and their meaning.

Good plan.

> When I look at a host we run, there are the following folders and files in
> `/modsecurity`:
> 
> - apache/
> - audit/
> - data/
> - tmp/
> - upload/
> - modsec_audit.log
> - virus-check.log

The ModSecurity Handbook is covering this in sufficient detail. 
Nicolas / Bigli is supposed to have a copy AFAICT. If not, let me know
and I'll send you one.

Please make sure
you get the partition restriction between /tmp and /upload right (need to be
on the same partition).

Other than that, I suggest to keep modsec_audit.log and audit/ together. They
former references files in the latter.

Best,

Christian


-- 
Besides, Emacs would be a far better OS if it shipped with a 
halfway-decent text editor - like vi for example.

[mod-security-users] WAF file and folder locations

[Peter B. <pet...@vs...>]

I'm looking for documentation (or a source file) listing the 
configurable folders of the WAF and their meaning.

When I look at a host we run, there are the following folders and files 
in `/modsecurity`:

- apache/
- audit/
- data/
- tmp/
- upload/
- modsec_audit.log
- virus-check.log

I need to know which folders (and files) are meant to contain data that 
is persisted (such as, probably, "audit" and "*.log") and which ones 
contain ephemeral data that we may mount somewhere where the OS throws 
the content away on, say, reboots (such as, probably, "tmp" and 
"upload").

Is there a specific documentation on this? Any hints that help me 
better understand are appreciated!

Peter

Re: [mod-security-users] Bls: Re: [Mod-security-developers] Question

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

Davy,

This is a very old recipe dating back to ModSecurity 1.0. You will have to
transpose it to ModSec 2.0 / 3.0 syntax with the SecRule directive and all
the mandatory actions that come with it.

Best,

Christian

On Fri, Jan 18, 2019 at 02:58:55PM +0000, Davy Gunarso via mod-security-users wrote:
> Hello,
> I already understand about the ModSecurity CRS.  I am trying to understand Ivan Ristic presentation - https://docs.huihoo.com/modsecurity/Web_Intruction_Detection_with_ModSecurity.pdf
> I wonder when I should write this:
> SecFilter "DELETE[[:space:]]+FROM"
> Thanks in advance.
> Davy
> 
> 
> Dikirim dari Yahoo Mail di Android 
>  
>   Pada Rab, 16 Jan 2019 pada 19:36, Manuel Spartan<spa...@gm...> menulis:   _______________________________________________
> 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] Bls: Re: [Mod-security-developers] Question

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

Hello,
I already understand about the ModSecurity CRS.  I am trying to understand Ivan Ristic presentation - https://docs.huihoo.com/modsecurity/Web_Intruction_Detection_with_ModSecurity.pdf
I wonder when I should write this:
SecFilter "DELETE[[:space:]]+FROM"
Thanks in advance.
Davy


Dikirim dari Yahoo Mail di Android 
 
  Pada Rab, 16 Jan 2019 pada 19:36, Manuel Spartan<spa...@gm...> menulis:   _______________________________________________
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: Re: [Mod-security-developers] Question

[Robert P. <rpa...@fe...>]

You may want to have a look at client9’s libinjection library. 

Sent from my iPhone

> On Jan 16, 2019, at 06:41, Davy Gunarso via mod-security-users <mod...@li...> wrote:
> 
> Yes, I have but it is not for specific sqlia type it is a general or perhaps for all type.  Since this is for my thesis I wonder if there is a specific sqlia type?
> 
> Davy
> 
> Dikirim dari Yahoo Mail di Android
> 
> Pada Rab, 16 Jan 2019 pada 19:36, Manuel Spartan
> <spa...@gm...> menulis:
> _______________________________________________
> 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>
> <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: Re: [Mod-security-developers] Question

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

Yes, I have but it is not for specific sqlia type it is a general or perhaps for all type.  Since this is for my thesis I wonder if there is a specific sqlia type?
Davy

Dikirim dari Yahoo Mail di Android 
 
  Pada Rab, 16 Jan 2019 pada 19:36, Manuel Spartan<spa...@gm...> menulis:   _______________________________________________
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] [Mod-security-developers] Question about ARGS Variable

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

Hi Davy,
Have you reviewed the owasp modsecurity core rule set project?
https://github.com/SpiderLabs/owasp-modsecurity-crs

Cheers!
Sent from my iPhone

> On 16 Jan 2019, at 02:51, Davy Gunarso via mod-security-users <mod...@li...> wrote:
> 
> 
> Hello,
> 
> Regarding Mod Security,  I wonder if it is possible to write custom rule in mod security special for SQLIA attacked?
> 
> For example: custom rule special for SQLIA Piggy backed tailed or custom rule special for SQLIA tautologies.
> 
> Is that possible?
> 
> Thanks in advance,
> Davy
> 
> On Thursday, January 3, 2019, 4:43:36 AM GMT+7, Manuel Spartan <spa...@gm...> wrote:
> 
> 
> The content of the request body is parsed f there is a body processor enabled, which only happens by default in two cases (https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#ctl) 
> ```
> The requestBodyProcessor option allows you to configure the request body processor. By default, ModSecurity will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body, respectively. Other two processors are also supported: JSON and XML, but they are never used implicitly. Instead, you must tell ModSecurity to use it by placing a few rules in the REQUEST_HEADERS processing phase.
> ```
> This means that if your content is XML you must have a rule in phase 1 that forces the engine to parse it, same applies to JSON and any other content-type https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#REQBODY_PROCESSOR
> 
> This also means that if the content-type is something else than `application/x-www-form-urlencoded` it will not populate the ARGS collection!  That is the default in most cases.
> 
> Now XML use its own collection while json will populate the same collection as urlencoded.
> You may also want to read https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRequestBodyAccess
> 
> Happy new year!
> 
> El mié., 2 ene. 2019 a las 13:50, Robert Paprocki (<rpa...@fe...>) escribió:
> Hey Jai,
> 
> I believe ARGS is only filled with the request body with the request is a urlencoded. Because ARGS and friends are treated as tabular variables, ModSecurity won't attempt to parse an XML body and at it into the ARGS or ARGS_POST variables, because there's no sane way to interpolate the document into key-value paired data.
> 
> On Wed, Jan 2, 2019 at 10:21 AM Jai Harpalani via mod-security-developers <mod...@li...> wrote:
> User-documentation states:
> 
> "ARGS is a collection and can be used on its own (means all arguments including the POST Payload)..."
> 
> Based on my testing, it does not appear that ARGS is including the POST payload. I am sending a POST request with the body shown below. I expect it to trigger Rule 930120, but it does not.
> 
> Request Body:
> 
> <?xml version='1.0' encoding='UTF-8'?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
>      <soapenv:Body>
>           <ns1:echo xmlns:ns1="http://example1.org/example1">
>                 <Text>hello .bashrc</Text>
>           </ns1:echo>
>      </soapenv:Body>
> </soapenv:Envelope>
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> _______________________________________________
> 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] [Mod-security-developers] Question about ARGS Variable

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

 
Hello,
Regarding Mod Security,  I wonder if it is possible to write custom rule in mod security special for SQLIA attacked?
For example: custom rule special for SQLIA Piggy backed tailed or custom rule special for SQLIA tautologies.
Is that possible?
Thanks in advance,Davy

    On Thursday, January 3, 2019, 4:43:36 AM GMT+7, Manuel Spartan <spa...@gm...> wrote:  
 
 The content of the request body is parsed f there is a body processor enabled, which only happens by default in two cases (https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#ctl) ```The requestBodyProcessor option allows you to configure the request body processor. By default, ModSecurity will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body, respectively. Other two processors are also supported: JSON and XML, but they are never used implicitly. Instead, you must tell ModSecurity to use it by placing a few rules in the REQUEST_HEADERS processing phase.```This means that if your content is XML you must have a rule in phase 1 that forces the engine to parse it, same applies to JSON and any other content-type https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#REQBODY_PROCESSOR
This also means that if the content-type is something else than `application/x-www-form-urlencoded` it will not populate the ARGS collection!  That is the default in most cases.
Now XML use its own collection while json will populate the same collection as urlencoded.You may also want to read https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRequestBodyAccess
Happy new year!

El mié., 2 ene. 2019 a las 13:50, Robert Paprocki (<rpa...@fe...>) escribió:

Hey Jai,
I believe ARGS is only filled with the request body with the request is a urlencoded. Because ARGS and friends are treated as tabular variables, ModSecurity won't attempt to parse an XML body and at it into the ARGS or ARGS_POST variables, because there's no sane way to interpolate the document into key-value paired data.
On Wed, Jan 2, 2019 at 10:21 AM Jai Harpalani via mod-security-developers <mod...@li...> wrote:

User-documentation states:

"ARGS is a collection and can be used on its own (means all arguments including the POST Payload)..."

Based on my testing, it does not appear that ARGS is including the POST payload. I am sending a POST request with the body shown below. I expect it to trigger Rule 930120, but it does not.
Request Body:
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">     <soapenv:Body>          <ns1:echo xmlns:ns1="http://example1.org/example1">                <Text>hello .bashrc</Text>          </ns1:echo>     </soapenv:Body></soapenv:Envelope>
_______________________________________________
mod-security-developers mailing list
mod...@li...
https://lists.sourceforge.net/lists/listinfo/mod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php
_______________________________________________
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] [Mod-security-developers] Question about ARGS Variable

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

The content of the request body is parsed f there is a body processor
enabled, which only happens by default in two cases (
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#ctl
)
```
The requestBodyProcessor option allows you to configure the request body
processor. By default, ModSecurity will use the URLENCODED and MULTIPART
processors to process an application/x-www-form-urlencoded and a
multipart/form-data body, respectively. Other two processors are also
supported: JSON and XML, but they are never used implicitly. Instead, *you
must* tell ModSecurity to use it by placing a few rules in the
REQUEST_HEADERS processing phase.
```
This means that if your content is XML you must have a rule in phase 1 that
forces the engine to parse it, same applies to JSON and any other
content-type
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#REQBODY_PROCESSOR

This also means that if the content-type is something else than `
application/x-www-form-urlencoded` it will not populate the ARGS
collection!  That is the default in most cases.

Now XML use its own collection while json will populate the same collection
as urlencoded.
You may also want to read
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecRequestBodyAccess

Happy new year!

El mié., 2 ene. 2019 a las 13:50, Robert Paprocki (<
rpa...@fe...>) escribió:

> Hey Jai,
>
> I believe ARGS is only filled with the request body with the request is a
> urlencoded. Because ARGS and friends are treated as tabular variables,
> ModSecurity won't attempt to parse an XML body and at it into the ARGS or
> ARGS_POST variables, because there's no sane way to interpolate the
> document into key-value paired data.
>
> On Wed, Jan 2, 2019 at 10:21 AM Jai Harpalani via mod-security-developers <
> mod...@li...> wrote:
>
>> User-documentation states:
>>
>> "ARGS is a collection and can be used on its own (means all arguments
>> including the POST Payload)..."
>>
>> Based on my testing, it does not appear that ARGS is including the POST
>> payload. I am sending a POST request with the body shown below. I expect it
>> to trigger Rule 930120, but it does not.
>>
>> Request Body:
>>
>> <?xml version='1.0' encoding='UTF-8'?>
>> <soapenv:Envelope xmlns:soapenv="
>> http://schemas.xmlsoap.org/soap/envelope/">
>>      <soapenv:Body>
>>           <ns1:echo xmlns:ns1="http://example1.org/example1">
>>                 <Text>hello .bashrc</Text>
>>           </ns1:echo>
>>      </soapenv:Body>
>> </soapenv:Envelope>
>>
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>
> _______________________________________________
> 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] Logging real ip behind proxy

[Luciano G. F. <luc...@gm...>]

I'm also using Cloudflare for all my sites, but I have this extension
enabled in Apache (on Linux): https://github.com/cloudflare/mod_cloudflare
So my apps and all mods (including modsec) see the real IP as it should be.

I don't know how the things work in Windows, but maybe you can fix it at
app level like they suggest here:
https://support.cloudflare.com/hc/en-us/articles/200170666-How-do-I-correct-visitor-IP-with-Microsoft-IIS-

El mié., 2 de ene. de 2019 a la(s) 15:32, Eero Volotinen (
eer...@ik...) escribió:

> Hi.
>
> Take look of REQUEST-901-INITIALIZATION.con
>
> I think this line takes care of ip address pickup:
>
> SecAction \
>
>   "id:901321, \
>
>   phase:1, \
>
>   t:none, \
>
>   initcol:global=global, \
>
>   initcol:ip=%{remote_addr}_%{tx.ua_hash}, \
>
>   setvar:tx.real_ip=%{remote_addr}, \
>
>   nolog, \
>
> You need to replace it with correct variable?
>
> Eero
>
> On Wed, Jan 2, 2019 at 7:30 PM Alexandros Kyrlis <ale...@me...>
> wrote:
>
>> I have already replaced the REMOTE_ADDR var with {HTTP_CF_Connecting_IP}
>> using IIS rewrite.
>> It works.
>>
>> using PHP:
>>
>> echo ($_SERVER['REMOTE_ADDR']);
>>
>> Returns the real client IP address.
>>
>> But mod_security still uses the ip of the proxy. I do not know why.
>>
>>
>> On 2 Ιαν 2019, at 19:03, Eero Volotinen <eer...@ik...> wrote:
>>
>> how about this:
>> http://www.loadbalancer.org/blog/iis-and-x-forwarded-for-header/
>>
>> Eero
>>
>> Alexandros Kyrlis via mod-security-users <
>> mod...@li...> kirjoitti ke 2. tammik. 2019
>> klo 19.00:
>>
>>> Hello,
>>> I'm using Mod Security with IIS 10.
>>> When a rule is triggered, mod security creates an event log on event
>>> viewer on Windows.
>>> This log contais the REMOTE_ADDR value, but since we are behind a proxy
>>> (Cloudflare) i would like it to log a custom header (CF_Connecting_IP) so
>>> we get the real client IP.
>>> Is it possible to do that?
>>> Thanks
>>> Alex
>>>
>>>
>>>
>>> _______________________________________________
>>> 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] Question about ARGS Variable

[Jai H. <jai...@mu...>]

Okay, here's a different question. This may not be the appropriate place to
ask, but I'll give it a shot.

There are many OWASP CRS rules which have XML in the list of operators, but
not REQUEST_BODY. An example of one is below.

SecRule
REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/*
"@pmf lfi-os-files.data" \
    "phase:request,\
    msg:'OS File Access Attempt',\
    rev:'4',\
    ver:'OWASP_CRS/3.0.0',\
    maturity:'9',\
    accuracy:'9',\
    capture,\
    t:none,t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,\
    block,\
    id:930120,\
. . .

This rule is searching for patterns specified in lfi-os-files.data. It is
not using Xpath expressions. The XML operator will be empty for non-xml
requests or when the xml parser is disabled. In these cases, wouldn't we
still want to search the request body for patterns specified in
lfi-os-files.data? Is there a reason that the patterns are only searched
for in the request body for XML requests?

On Wed, Jan 2, 2019 at 12:58 PM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 02.01.19 um 19:54 schrieb Jai Harpalani via mod-security-users:
> > Isn't the "POST Payload" equivalent to the body? If not, what exactly is
> > the "POST Payload"?
>
> hell how can any random XML stuff be a ARGUMENT and how do you imagine
> this to handeled performance wise?
>
> is it a post-param like <input type="text" anme"=arg" value"=whatever">
> no, it is not
>
> > On Wed, Jan 2, 2019 at 12:29 PM Reindl Harald <h.r...@th...
> > <mailto:h.r...@th...>> wrote:
> >
> >
> >
> >     Am 02.01.19 um 18:55 schrieb Jai Harpalani via mod-security-users:
> >     > User-documentation states:
> >     >
> >     > "ARGS is a collection and can be used on its own (means all
> arguments
> >     > including the POST Payload)..."
> >     >
> >     > Based on my testing, it does not appear that ARGS is including the
> >     POST
> >     > payload. I am sending a POST request with the body shown below. I
> >     expect
> >     > it to trigger Rule 930120, but it does not.
> >
> >     args and body are different worlds by definition
> >
> >
> >     > Request Body:
> >     >
> >     > <?xml version='1.0' encoding='UTF-8'?>
> >     > <soapenv:Envelope
> >     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
> >     >      <soapenv:Body>
> >     >           <ns1:echo xmlns:ns1="http://example1.org/example1">
> >     >                 <Text>hello .bashrc</Text>
> >     >           </ns1:echo>
> >     >      </soapenv:Body>
> >     > </soapenv:Envelope>
>
>
> _______________________________________________
> 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] Question about ARGS Variable

[Reindl H. <h.r...@th...>]

Am 02.01.19 um 19:54 schrieb Jai Harpalani via mod-security-users:
> Isn't the "POST Payload" equivalent to the body? If not, what exactly is
> the "POST Payload"?

hell how can any random XML stuff be a ARGUMENT and how do you imagine
this to handeled performance wise?

is it a post-param like <input type="text" anme"=arg" value"=whatever">
no, it is not

> On Wed, Jan 2, 2019 at 12:29 PM Reindl Harald <h.r...@th...
> <mailto:h.r...@th...>> wrote:
> 
> 
> 
>     Am 02.01.19 um 18:55 schrieb Jai Harpalani via mod-security-users:
>     > User-documentation states:
>     >
>     > "ARGS is a collection and can be used on its own (means all arguments
>     > including the POST Payload)..."
>     >
>     > Based on my testing, it does not appear that ARGS is including the
>     POST
>     > payload. I am sending a POST request with the body shown below. I
>     expect
>     > it to trigger Rule 930120, but it does not.
> 
>     args and body are different worlds by definition
> 
> 
>     > Request Body:
>     >
>     > <?xml version='1.0' encoding='UTF-8'?>
>     > <soapenv:Envelope
>     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
>     >      <soapenv:Body>
>     >           <ns1:echo xmlns:ns1="http://example1.org/example1">
>     >                 <Text>hello .bashrc</Text>
>     >           </ns1:echo>
>     >      </soapenv:Body>
>     > </soapenv:Envelope>

Re: [mod-security-users] Question about ARGS Variable

[Jai H. <jai...@mu...>]

Isn't the "POST Payload" equivalent to the body? If not, what exactly is
the "POST Payload"?

On Wed, Jan 2, 2019 at 12:29 PM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 02.01.19 um 18:55 schrieb Jai Harpalani via mod-security-users:
> > User-documentation states:
> >
> > "ARGS is a collection and can be used on its own (means all arguments
> > including the POST Payload)..."
> >
> > Based on my testing, it does not appear that ARGS is including the POST
> > payload. I am sending a POST request with the body shown below. I expect
> > it to trigger Rule 930120, but it does not.
>
> args and body are different worlds by definition
>
>
> > Request Body:
> >
> > <?xml version='1.0' encoding='UTF-8'?>
> > <soapenv:Envelope xmlns:soapenv="
> http://schemas.xmlsoap.org/soap/envelope/">
> >      <soapenv:Body>
> >           <ns1:echo xmlns:ns1="http://example1.org/example1">
> >                 <Text>hello .bashrc</Text>
> >           </ns1:echo>
> >      </soapenv:Body>
> > </soapenv:Envelope>
>
>
>
> _______________________________________________
> 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] [Mod-security-developers] Question about ARGS Variable

[Robert P. <rpa...@fe...>]

Hey Jai,

I believe ARGS is only filled with the request body with the request is a
urlencoded. Because ARGS and friends are treated as tabular variables,
ModSecurity won't attempt to parse an XML body and at it into the ARGS or
ARGS_POST variables, because there's no sane way to interpolate the
document into key-value paired data.

On Wed, Jan 2, 2019 at 10:21 AM Jai Harpalani via mod-security-developers <
mod...@li...> wrote:

> User-documentation states:
>
> "ARGS is a collection and can be used on its own (means all arguments
> including the POST Payload)..."
>
> Based on my testing, it does not appear that ARGS is including the POST
> payload. I am sending a POST request with the body shown below. I expect it
> to trigger Rule 930120, but it does not.
>
> Request Body:
>
> <?xml version='1.0' encoding='UTF-8'?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
> ">
>      <soapenv:Body>
>           <ns1:echo xmlns:ns1="http://example1.org/example1">
>                 <Text>hello .bashrc</Text>
>           </ns1:echo>
>      </soapenv:Body>
> </soapenv:Envelope>
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [mod-security-users] Logging real ip behind proxy

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

Hi.

Take look of REQUEST-901-INITIALIZATION.con

I think this line takes care of ip address pickup:

SecAction \

  "id:901321, \

  phase:1, \

  t:none, \

  initcol:global=global, \

  initcol:ip=%{remote_addr}_%{tx.ua_hash}, \

  setvar:tx.real_ip=%{remote_addr}, \

  nolog, \

You need to replace it with correct variable?

Eero

On Wed, Jan 2, 2019 at 7:30 PM Alexandros Kyrlis <ale...@me...> wrote:

> I have already replaced the REMOTE_ADDR var with {HTTP_CF_Connecting_IP}
> using IIS rewrite.
> It works.
>
> using PHP:
>
> echo ($_SERVER['REMOTE_ADDR']);
>
> Returns the real client IP address.
>
> But mod_security still uses the ip of the proxy. I do not know why.
>
>
> On 2 Ιαν 2019, at 19:03, Eero Volotinen <eer...@ik...> wrote:
>
> how about this:
> http://www.loadbalancer.org/blog/iis-and-x-forwarded-for-header/
>
> Eero
>
> Alexandros Kyrlis via mod-security-users <
> mod...@li...> kirjoitti ke 2. tammik. 2019
> klo 19.00:
>
>> Hello,
>> I'm using Mod Security with IIS 10.
>> When a rule is triggered, mod security creates an event log on event
>> viewer on Windows.
>> This log contais the REMOTE_ADDR value, but since we are behind a proxy
>> (Cloudflare) i would like it to log a custom header (CF_Connecting_IP) so
>> we get the real client IP.
>> Is it possible to do that?
>> Thanks
>> Alex
>>
>>
>>
>> _______________________________________________
>> 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] Question about ARGS Variable

[Reindl H. <h.r...@th...>]

Am 02.01.19 um 18:55 schrieb Jai Harpalani via mod-security-users:
> User-documentation states:
> 
> "ARGS is a collection and can be used on its own (means all arguments
> including the POST Payload)..."
> 
> Based on my testing, it does not appear that ARGS is including the POST
> payload. I am sending a POST request with the body shown below. I expect
> it to trigger Rule 930120, but it does not.

args and body are different worlds by definition


> Request Body:
> 
> <?xml version='1.0' encoding='UTF-8'?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
>      <soapenv:Body>
>           <ns1:echo xmlns:ns1="http://example1.org/example1">
>                 <Text>hello .bashrc</Text>
>           </ns1:echo>
>      </soapenv:Body>
> </soapenv:Envelope>

[mod-security-users] Question about ARGS Variable

[Jai H. <jai...@mu...>]

User-documentation states:

"ARGS is a collection and can be used on its own (means all arguments
including the POST Payload)..."

Based on my testing, it does not appear that ARGS is including the POST
payload. I am sending a POST request with the body shown below. I expect it
to trigger Rule 930120, but it does not.

Request Body:

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
     <soapenv:Body>
          <ns1:echo xmlns:ns1="http://example1.org/example1">
                <Text>hello .bashrc</Text>
          </ns1:echo>
     </soapenv:Body>
</soapenv:Envelope>

Re: [mod-security-users] Logging real ip behind proxy

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

how about this:
http://www.loadbalancer.org/blog/iis-and-x-forwarded-for-header/

Eero

Alexandros Kyrlis via mod-security-users <
mod...@li...> kirjoitti ke 2. tammik. 2019 klo
19.00:

> Hello,
> I'm using Mod Security with IIS 10.
> When a rule is triggered, mod security creates an event log on event
> viewer on Windows.
> This log contais the REMOTE_ADDR value, but since we are behind a proxy
> (Cloudflare) i would like it to log a custom header (CF_Connecting_IP) so
> we get the real client IP.
> Is it possible to do that?
> Thanks
> Alex
>
>
>
> _______________________________________________
> 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] Logging real ip behind proxy

[Reindl H. <h.r...@th...>]

Am 02.01.19 um 17:34 schrieb Alexandros Kyrlis via mod-security-users:
> I'm using Mod Security with IIS 10.
> When a rule is triggered, mod security creates an event log on event viewer on Windows.
> This log contais the REMOTE_ADDR value, but since we are behind a proxy (Cloudflare) i would like it to log a custom header (CF_Connecting_IP) so we get the real client IP.
> Is it possible to do that?

you need something like that for MS IIS or use a better webserver and be
it as proxy in front of the application itself

https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

[mod-security-users] Logging real ip behind proxy

[Alexandros K. <ale...@me...>]

Hello,
I'm using Mod Security with IIS 10.
When a rule is triggered, mod security creates an event log on event viewer on Windows.
This log contais the REMOTE_ADDR value, but since we are behind a proxy (Cloudflare) i would like it to log a custom header (CF_Connecting_IP) so we get the real client IP.
Is it possible to do that?
Thanks
Alex

[mod-security-users] CRS News for December 2018 published

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

Hello everybody,

I just published the news of the OWASP ModSecurity Core Rule Set project
for the month of November:

https://coreruleset.org/20181226/crs-project-news-december-2018/

It includes the CRS 3.1 release, updates to the docker container, an
interesting success story and the first CRS 3.2 pull requests.

Best,

Christian



-- 
History repeats itself, first as tragedy, second as XML.
--- Comment found on slashdot

[mod-security-users] (no subject)

[Don C. <don...@gm...>]

Re: [mod-security-users] Deployment Options

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

Well, there are instructions in this repo:

https://github.com/git001/haproxy-waf

You just need to rip off settings from docker file

Eero

Parrish, Kyle <Kyl...@th...> kirjoitti ma 17. jouluk.
2018 klo 15.19:

> I have seen references to that feature using SPOA but have yet to find
> instructions on how to configure it.
>
>
>
> Has anyone attempted setting this up?
>
>
>
> *B. Kyle Parrish*
>
> Cyber Security Engineer | The Villages® Technology Solutions Group
>
> Direct: 352.674.1508 | Support: 352.674.1530
>
>
>
> *From:* Eero Volotinen <eer...@ik...>
> *Sent:* Saturday, December 15, 2018 15:33
> *To:* mod...@li...
> *Subject:* Re: [mod-security-users] Deployment Options
>
>
>
> Anyway, looking at ha proxy git source there is support for modsecurity
> 2.9.x via spoa protocol? it is something like modsecurity standalone
> binary.
>
>
>
> Eero
>
>
>
> Christian Folini <chr...@ne...> kirjoitti la 15. jouluk.
> 2018 klo 11.17:
>
> Thanks Eero. Never came across this. Do you have contact?
>
> On Fri, Dec 14, 2018 at 05:50:30PM +0200, Eero Volotinen wrote:
> > or.. Haproxy enteprise that supports modsecurity waf internally. (this
> > costs something like 1700€/haproxy/year)
> >
> > Eero
> >
> > Christian Folini <chr...@ne...> kirjoitti pe 14. jouluk.
> > 2018 klo 17.41:
> >
> > > Oh, I see. Makes sense.
> > >
> > > Then your best option is
> > >
> > > Net -> HAProxy -> Apache(s) + ModSec 2.9.x -> Backend Application
> > >
> > > It's a proven and stable setup. Alternatively
> > >
> > > Net -> HAProxy -> NGINX(s) + ModSec 3.0.x -> Backend Application
> > >
> > > but I think it still has too many rough edges for my taste. And the
> > > performance is not yet on-par with the traditional Apache setup.
> > > (But that's a wild field and not everybody agrees with me.)
> > >
> > > Either way, you may find my tutorials for Apache + ModSec and NGINX +
> > > ModSec
> > > on netnea.com helpful.
> > >
> > > Ahoj,
> > >
> > > Christian
> > >
> > > On Fri, Dec 14, 2018 at 03:34:16PM +0000, Parrish, Kyle wrote:
> > > > Thank you for your prompt response.
> > > >
> > > > We currently have HAProxy serving our sites as a reverse proxy which
> > > doesn't nativily support modsecurity.
> > > >
> > > > What would you recommend in this scenario?
> > > >
> > > > -----Original Message-----
> > > > From: Christian Folini <chr...@ne...>
> > > > Sent: Friday, December 14, 2018 10:24
> > > > To: mod...@li...
> > > > Subject: Re: [mod-security-users] Deployment Options
> > > >
> > > > Good evening to you, Kyle,
> > > >
> > > > ModSecurity is usually sitting inline on the proxy. But it's
> perfectly
> > > OK to
> > > > have the proxy serve several if not hundreds of backends. The
> problem is
> > > much
> > > > more a problem of overall throughput (expect ModSec to eat 10% of
> > > throughput
> > > > for an average internet site, but your mileage may vary greatly) and
> in
> > > > some cases a RAM problem with rule set duplication in memory.
> > > >
> > > > Generally: ModSec should not have any problem serving your scenario
> (if
> > > you
> > > > change it to "the proxy is the WAF")
> > > >
> > > > Cheers,
> > > >
> > > > Christian
> > > >
> > > > On Fri, Dec 14, 2018 at 02:50:27PM +0000, Parrish, Kyle wrote:
> > > > > Good morning all,
> > > > >
> > > > > Seeking advice on deploying a Web Application Firewall.
> > > > >
> > > > > I'm pretty familiar with WAFs and what they will do but stuck on an
> > > ideal deployment structure.
> > > > >
> > > > > Lets say there are 20 websites sitting behind a reverse proxy.
> > > > > My idea would be to have:
> > > > >
> > > > >   1.  Request hits proxy
> > > > >   2.  Checks to see if it has been WAF'ed or not
> > > > >   3.  Sends to WAF
> > > > >   4.  If approved goes back to be proxied to correct backend
> > > > >
> > > > > Now, would it be okay to have 20 sites sent through a single WAF or
> > > should each site be configured for its own?
> > > > >
> > > > > I am looking to use OWASP ModSecurity for the WAF ruleset but not
> > > familiar with its scalability yet.
> > > > >
> > > > > Hoping someone else has already gone down this path and could shed
> > > some light on it.
> > > > >
> > > > > B. Kyle Parrish
> > > > >
> > > > >
> > > >
> > > >
> > > > > _______________________________________________
> > > > > mod-security-users mailing list
> > > > > mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > > > Commercial ModSecurity Rules and Support from Trustwave's
> SpiderLabs:
> > > > > http://www.modsecurity.org/projects/commercial/rules/
> > > > > http://www.modsecurity.org/projects/commercial/support/
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > mod-security-users mailing list
> > > > mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > > http://www.modsecurity.org/projects/commercial/rules/
> > > > http://www.modsecurity.org/projects/commercial/support/
> > > >
> > > >
> > > > _______________________________________________
> > > > mod-security-users mailing list
> > > > mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > > http://www.modsecurity.org/projects/commercial/rules/
> > > > http://www.modsecurity.org/projects/commercial/support/
> > >
> > >
> > > _______________________________________________
> > > mod-security-users mailing list
> > > mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > http://www.modsecurity.org/projects/commercial/rules/
> > > http://www.modsecurity.org/projects/commercial/support/
> > >
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

Re: [mod-security-users] Deployment Options

[Parrish, K. <Kyl...@Th...>]

I have seen references to that feature using SPOA but have yet to find instructions on how to configure it.

Has anyone attempted setting this up?

B. Kyle Parrish
Cyber Security Engineer | The Villages® Technology Solutions Group
Direct: 352.674.1508 | Support: 352.674.1530

From: Eero Volotinen <eer...@ik...>
Sent: Saturday, December 15, 2018 15:33
To: mod...@li...
Subject: Re: [mod-security-users] Deployment Options

Anyway, looking at ha proxy git source there is support for modsecurity 2.9.x via spoa protocol? it is something like modsecurity standalone binary.

Eero

Christian Folini <chr...@ne...<mailto:chr...@ne...>> kirjoitti la 15. jouluk. 2018 klo 11.17:
Thanks Eero. Never came across this. Do you have contact?

On Fri, Dec 14, 2018 at 05:50:30PM +0200, Eero Volotinen wrote:
> or.. Haproxy enteprise that supports modsecurity waf internally. (this
> costs something like 1700€/haproxy/year)
>
> Eero
>
> Christian Folini <chr...@ne...<mailto:chr...@ne...>> kirjoitti pe 14. jouluk.
> 2018 klo 17.41:
>
> > Oh, I see. Makes sense.
> >
> > Then your best option is
> >
> > Net -> HAProxy -> Apache(s) + ModSec 2.9.x -> Backend Application
> >
> > It's a proven and stable setup. Alternatively
> >
> > Net -> HAProxy -> NGINX(s) + ModSec 3.0.x -> Backend Application
> >
> > but I think it still has too many rough edges for my taste. And the
> > performance is not yet on-par with the traditional Apache setup.
> > (But that's a wild field and not everybody agrees with me.)
> >
> > Either way, you may find my tutorials for Apache + ModSec and NGINX +
> > ModSec
> > on netnea.com<http://netnea.com> helpful.
> >
> > Ahoj,
> >
> > Christian
> >
> > On Fri, Dec 14, 2018 at 03:34:16PM +0000, Parrish, Kyle wrote:
> > > Thank you for your prompt response.
> > >
> > > We currently have HAProxy serving our sites as a reverse proxy which
> > doesn't nativily support modsecurity.
> > >
> > > What would you recommend in this scenario?
> > >
> > > -----Original Message-----
> > > From: Christian Folini <chr...@ne...<mailto:chr...@ne...>>
> > > Sent: Friday, December 14, 2018 10:24
> > > To: mod...@li...<mailto:mod...@li...>
> > > Subject: Re: [mod-security-users] Deployment Options
> > >
> > > Good evening to you, Kyle,
> > >
> > > ModSecurity is usually sitting inline on the proxy. But it's perfectly
> > OK to
> > > have the proxy serve several if not hundreds of backends. The problem is
> > much
> > > more a problem of overall throughput (expect ModSec to eat 10% of
> > throughput
> > > for an average internet site, but your mileage may vary greatly) and in
> > > some cases a RAM problem with rule set duplication in memory.
> > >
> > > Generally: ModSec should not have any problem serving your scenario (if
> > you
> > > change it to "the proxy is the WAF")
> > >
> > > Cheers,
> > >
> > > Christian
> > >
> > > On Fri, Dec 14, 2018 at 02:50:27PM +0000, Parrish, Kyle wrote:
> > > > Good morning all,
> > > >
> > > > Seeking advice on deploying a Web Application Firewall.
> > > >
> > > > I'm pretty familiar with WAFs and what they will do but stuck on an
> > ideal deployment structure.
> > > >
> > > > Lets say there are 20 websites sitting behind a reverse proxy.
> > > > My idea would be to have:
> > > >
> > > >   1.  Request hits proxy
> > > >   2.  Checks to see if it has been WAF'ed or not
> > > >   3.  Sends to WAF
> > > >   4.  If approved goes back to be proxied to correct backend
> > > >
> > > > Now, would it be okay to have 20 sites sent through a single WAF or
> > should each site be configured for its own?
> > > >
> > > > I am looking to use OWASP ModSecurity for the WAF ruleset but not
> > familiar with its scalability yet.
> > > >
> > > > Hoping someone else has already gone down this path and could shed
> > some light on it.
> > > >
> > > > B. Kyle Parrish
> > > >
> > > >
> > >
> > >
> > > > _______________________________________________
> > > > mod-security-users mailing list
> > > > mod...@li...<mailto: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...<mailto: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...<mailto: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...<mailto: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...<mailto: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...<mailto: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] Deployment Options

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

Anyway, looking at ha proxy git source there is support for modsecurity
2.9.x via spoa protocol? it is something like modsecurity standalone
binary.

Eero

Christian Folini <chr...@ne...> kirjoitti la 15. jouluk.
2018 klo 11.17:

> Thanks Eero. Never came across this. Do you have contact?
>
> On Fri, Dec 14, 2018 at 05:50:30PM +0200, Eero Volotinen wrote:
> > or.. Haproxy enteprise that supports modsecurity waf internally. (this
> > costs something like 1700€/haproxy/year)
> >
> > Eero
> >
> > Christian Folini <chr...@ne...> kirjoitti pe 14. jouluk.
> > 2018 klo 17.41:
> >
> > > Oh, I see. Makes sense.
> > >
> > > Then your best option is
> > >
> > > Net -> HAProxy -> Apache(s) + ModSec 2.9.x -> Backend Application
> > >
> > > It's a proven and stable setup. Alternatively
> > >
> > > Net -> HAProxy -> NGINX(s) + ModSec 3.0.x -> Backend Application
> > >
> > > but I think it still has too many rough edges for my taste. And the
> > > performance is not yet on-par with the traditional Apache setup.
> > > (But that's a wild field and not everybody agrees with me.)
> > >
> > > Either way, you may find my tutorials for Apache + ModSec and NGINX +
> > > ModSec
> > > on netnea.com helpful.
> > >
> > > Ahoj,
> > >
> > > Christian
> > >
> > > On Fri, Dec 14, 2018 at 03:34:16PM +0000, Parrish, Kyle wrote:
> > > > Thank you for your prompt response.
> > > >
> > > > We currently have HAProxy serving our sites as a reverse proxy which
> > > doesn't nativily support modsecurity.
> > > >
> > > > What would you recommend in this scenario?
> > > >
> > > > -----Original Message-----
> > > > From: Christian Folini <chr...@ne...>
> > > > Sent: Friday, December 14, 2018 10:24
> > > > To: mod...@li...
> > > > Subject: Re: [mod-security-users] Deployment Options
> > > >
> > > > Good evening to you, Kyle,
> > > >
> > > > ModSecurity is usually sitting inline on the proxy. But it's
> perfectly
> > > OK to
> > > > have the proxy serve several if not hundreds of backends. The
> problem is
> > > much
> > > > more a problem of overall throughput (expect ModSec to eat 10% of
> > > throughput
> > > > for an average internet site, but your mileage may vary greatly) and
> in
> > > > some cases a RAM problem with rule set duplication in memory.
> > > >
> > > > Generally: ModSec should not have any problem serving your scenario
> (if
> > > you
> > > > change it to "the proxy is the WAF")
> > > >
> > > > Cheers,
> > > >
> > > > Christian
> > > >
> > > > On Fri, Dec 14, 2018 at 02:50:27PM +0000, Parrish, Kyle wrote:
> > > > > Good morning all,
> > > > >
> > > > > Seeking advice on deploying a Web Application Firewall.
> > > > >
> > > > > I'm pretty familiar with WAFs and what they will do but stuck on an
> > > ideal deployment structure.
> > > > >
> > > > > Lets say there are 20 websites sitting behind a reverse proxy.
> > > > > My idea would be to have:
> > > > >
> > > > >   1.  Request hits proxy
> > > > >   2.  Checks to see if it has been WAF'ed or not
> > > > >   3.  Sends to WAF
> > > > >   4.  If approved goes back to be proxied to correct backend
> > > > >
> > > > > Now, would it be okay to have 20 sites sent through a single WAF or
> > > should each site be configured for its own?
> > > > >
> > > > > I am looking to use OWASP ModSecurity for the WAF ruleset but not
> > > familiar with its scalability yet.
> > > > >
> > > > > Hoping someone else has already gone down this path and could shed
> > > some light on it.
> > > > >
> > > > > B. Kyle Parrish
> > > > >
> > > > >
> > > >
> > > >
> > > > > _______________________________________________
> > > > > mod-security-users mailing list
> > > > > mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > > > Commercial ModSecurity Rules and Support from Trustwave's
> SpiderLabs:
> > > > > http://www.modsecurity.org/projects/commercial/rules/
> > > > > http://www.modsecurity.org/projects/commercial/support/
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > mod-security-users mailing list
> > > > mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > > http://www.modsecurity.org/projects/commercial/rules/
> > > > http://www.modsecurity.org/projects/commercial/support/
> > > >
> > > >
> > > > _______________________________________________
> > > > mod-security-users mailing list
> > > > mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > > http://www.modsecurity.org/projects/commercial/rules/
> > > > http://www.modsecurity.org/projects/commercial/support/
> > >
> > >
> > > _______________________________________________
> > > mod-security-users mailing list
> > > mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > > http://www.modsecurity.org/projects/commercial/rules/
> > > http://www.modsecurity.org/projects/commercial/support/
> > >
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>