Thread: [mod-security-users] Custom Headers
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users
|
From: Matt W. <mat...@ho...> - 2020-11-17 14:36:59
|
I am hoping this is a relatively straight forward question, but I have been struggling with it for some time and cannot find any examples online. We are using ModSecurity 3.04 with NGINX and trying to get a custom header written to the audit log with every transaction. Essentially, we want to write the $ssl_client_s_dn_cn variable to the audit log which is populated by the users PKI certificate when they login through a reverse proxy. This info is set in a header to available to applications so if you had something similar to: proxy_set_header ClientUsername $ssl_client_s_dn_cn. How would you craft a modsec rule to write client username to the audit log? Thanks in advance, Matt |
|
From: Christian F. <chr...@ne...> - 2020-11-18 08:22:05
|
Hey Matt,
I am not very well versed in things NGINX. But it is not as obvious as it
seems.
Conceptually, there are at least two ways here:
(1) Have ModSec access the SSL variable and write it into the msg / logdata
of a rule
(2) Have ModSec access the HTTP request variable and write it into the
msg / logdata of a rule
(3) Dirty hack
Now (2) is blocked as new headers added by the webserver itself are not
accessible from ModSec. At least this is what the situation is on
Apache/ModSec2. It might be different on NGINX, but you ought to try it.
(1) on the other hand is tricky as ModSec needs a way to access the mod_ssl
variables. But as far as I know, this is not implemented.
(3) There is a dirty hack that I sometimes use on Apache: I add stuff via
mod_headers, then I proxy onto the same Apache (different port) and there,
the new header becomes available, then I'm ready to proxy to the backend.
Cheers,
Christian
On Tue, Nov 17, 2020 at 02:04:10PM +0000, Matt Ward wrote:
> I am hoping this is a relatively straight forward question, but I have been struggling with it for some time and cannot find any examples online.
>
> We are using ModSecurity 3.04 with NGINX and trying to get a custom header written to the audit log with every transaction. Essentially, we want to write the $ssl_client_s_dn_cn variable to the audit log which is populated by the users PKI certificate when they login through a reverse proxy. This info is set in a header to available to applications so if you had something similar to:
>
> proxy_set_header ClientUsername $ssl_client_s_dn_cn.
>
> How would you craft a modsec rule to write client username to the audit log?
>
> Thanks in advance,
>
> Matt
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
|
|
From: Alexandre S. <ale...@gm...> - 2020-11-18 17:20:34
|
Bonjour,
( Same, no nginx good knowledge, no modsecv3 usage. )
There is a less dirty trick for apache/modsecv2.
Playing with apache hook mechanisms.
Consider testing around that sample:
# set header in early hook: before modsec phase:2
RequestHeader set "X-CLIENT-I-DN-CN" "%{SSL_CLIENT_I_DN_CN}s" early
# remove if null
RequestHeader edit "X-CLIENT-I-DN-CN" "\(null\)" "" early
# use in modsec phase:2 hook. If ok, maybe do some ctl combo, skipafter,
setvar, deny if not the one desired...
# debug on : SecAction
"id:1234,phase:2,nolog,noauditlog,ctl:debuglogLevel=9,pass"
SecRule REQUEST_HEADERS:X-CLIENT-I-DN-CN "@rx .*" \
"id:666,\
phase:2,\
pass,\
log,noauditlog,\
msg:'found X-CLIENT-I-DN-CN is %{MATCHED_VAR}',\
setenv:DNCN=%{MATCHED_VAR}"
# debug off: SecAction "id:4321,phase:2,ctl:debuglogLevel=0,pass"
# header is no more needed
RequestHeader unset "X-CLIENT-I-DN-CN"
LogFormat "[whatever your logformat is] [%{DNCN}e]" vhost_common
br,
Alexandre.
On Wed, Nov 18, 2020 at 9:25 AM Christian Folini <
chr...@ne...> wrote:
> Hey Matt,
>
> I am not very well versed in things NGINX. But it is not as obvious as it
> seems.
>
> Conceptually, there are at least two ways here:
> (1) Have ModSec access the SSL variable and write it into the msg / logdata
> of a rule
> (2) Have ModSec access the HTTP request variable and write it into the
> msg / logdata of a rule
> (3) Dirty hack
>
> Now (2) is blocked as new headers added by the webserver itself are not
> accessible from ModSec. At least this is what the situation is on
> Apache/ModSec2. It might be different on NGINX, but you ought to try it.
>
> (1) on the other hand is tricky as ModSec needs a way to access the mod_ssl
> variables. But as far as I know, this is not implemented.
>
> (3) There is a dirty hack that I sometimes use on Apache: I add stuff via
> mod_headers, then I proxy onto the same Apache (different port) and there,
> the new header becomes available, then I'm ready to proxy to the backend.
>
> Cheers,
>
> Christian
>
>
> On Tue, Nov 17, 2020 at 02:04:10PM +0000, Matt Ward wrote:
> > I am hoping this is a relatively straight forward question, but I have
> been struggling with it for some time and cannot find any examples online.
> >
> > We are using ModSecurity 3.04 with NGINX and trying to get a custom
> header written to the audit log with every transaction. Essentially, we
> want to write the $ssl_client_s_dn_cn variable to the audit log which is
> populated by the users PKI certificate when they login through a reverse
> proxy. This info is set in a header to available to applications so if you
> had something similar to:
> >
> > proxy_set_header ClientUsername $ssl_client_s_dn_cn.
> >
> > How would you craft a modsec rule to write client username to the audit
> log?
> >
> > Thanks in advance,
> >
> > Matt
> >
> >
>
>
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
|
|
From: Robert P. <rpa...@fe...> - 2020-11-18 18:29:02
|
With Nginx, there is no way to have modsec expose any environment variable
into the process, so the Apache hack won't work.
Is there any reason you couldn't write a no-op modsec rule that matches on
that header values and writes the match value as part of the log msg?
On Wed, Nov 18, 2020 at 9:21 AM Alexandre Schaff <ale...@gm...>
wrote:
> Bonjour,
> ( Same, no nginx good knowledge, no modsecv3 usage. )
> There is a less dirty trick for apache/modsecv2.
> Playing with apache hook mechanisms.
> Consider testing around that sample:
> # set header in early hook: before modsec phase:2
> RequestHeader set "X-CLIENT-I-DN-CN" "%{SSL_CLIENT_I_DN_CN}s" early
> # remove if null
> RequestHeader edit "X-CLIENT-I-DN-CN" "\(null\)" "" early
> # use in modsec phase:2 hook. If ok, maybe do some ctl combo, skipafter,
> setvar, deny if not the one desired...
> # debug on : SecAction
> "id:1234,phase:2,nolog,noauditlog,ctl:debuglogLevel=9,pass"
> SecRule REQUEST_HEADERS:X-CLIENT-I-DN-CN "@rx .*" \
> "id:666,\
> phase:2,\
> pass,\
> log,noauditlog,\
> msg:'found X-CLIENT-I-DN-CN is %{MATCHED_VAR}',\
> setenv:DNCN=%{MATCHED_VAR}"
> # debug off: SecAction "id:4321,phase:2,ctl:debuglogLevel=0,pass"
> # header is no more needed
> RequestHeader unset "X-CLIENT-I-DN-CN"
> LogFormat "[whatever your logformat is] [%{DNCN}e]" vhost_common
>
> br,
> Alexandre.
>
>
>
>
>
> On Wed, Nov 18, 2020 at 9:25 AM Christian Folini <
> chr...@ne...> wrote:
>
>> Hey Matt,
>>
>> I am not very well versed in things NGINX. But it is not as obvious as it
>> seems.
>>
>> Conceptually, there are at least two ways here:
>> (1) Have ModSec access the SSL variable and write it into the msg /
>> logdata
>> of a rule
>> (2) Have ModSec access the HTTP request variable and write it into the
>> msg / logdata of a rule
>> (3) Dirty hack
>>
>> Now (2) is blocked as new headers added by the webserver itself are not
>> accessible from ModSec. At least this is what the situation is on
>> Apache/ModSec2. It might be different on NGINX, but you ought to try it.
>>
>> (1) on the other hand is tricky as ModSec needs a way to access the
>> mod_ssl
>> variables. But as far as I know, this is not implemented.
>>
>> (3) There is a dirty hack that I sometimes use on Apache: I add stuff via
>> mod_headers, then I proxy onto the same Apache (different port) and there,
>> the new header becomes available, then I'm ready to proxy to the backend.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> On Tue, Nov 17, 2020 at 02:04:10PM +0000, Matt Ward wrote:
>> > I am hoping this is a relatively straight forward question, but I have
>> been struggling with it for some time and cannot find any examples online.
>> >
>> > We are using ModSecurity 3.04 with NGINX and trying to get a custom
>> header written to the audit log with every transaction. Essentially, we
>> want to write the $ssl_client_s_dn_cn variable to the audit log which is
>> populated by the users PKI certificate when they login through a reverse
>> proxy. This info is set in a header to available to applications so if you
>> had something similar to:
>> >
>> > proxy_set_header ClientUsername $ssl_client_s_dn_cn.
>> >
>> > How would you craft a modsec rule to write client username to the audit
>> log?
>> >
>> > Thanks in advance,
>> >
>> > Matt
>> >
>> >
>>
>>
>> > _______________________________________________
>> > 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/
>
|
Thanks for helping keep SourceForge clean.
X