JSON support was not enabled (Make it required?)

[davewichers]

I believe JSON support in ModSecurity is optional, i.e., it has to be compiled in and is not by default. With the prevalence of JSON support in apps today, can you change this to be a required, not optional, component? This way, users don't have to beg the people that compile and distribute their ModSecurity version (e.g., Debian, CentOS, etc.) to include JSON support in what they compile and release?

I'm using the official CentOS 7 v2.9.2 ModSecurity release and it apparently doesn't include JSON support. Unless you know a way of adding it, without recompiling it, which I'm not doing.

[victorhora]

@davewichers

I believe that JSON support is enabled by default during compilation if the YAJL library is available (see find_yajl.m4)

In your case it was the a choice of the packagers of your distro either not providing YAJL on the distro (maybe try searching if your distro provides such package in the first place) or simply choosing to disable it. A way to find out is getting the source RPM or spec file and looking into how it was configured/compiled (see #1779 (comment))

Please go over this issue and you may find out that you could be facing the same issue: #1779. Even though this issue talks about RHEL, your version of CentOS might not be providing YAJL for some reason.

FYI, Debian, Ubuntu, ArchLinux, Gentoo, SUSE, Mint and many others provide YAJL packages without hassle.

There's no way to add JSON support without recompiling it.

[davewichers]

The point of my request is to make it REQUIRED. Meaning that if the library is not present, fail the compilation. I think this is similar to: #1913, in that you say it has to be compiled in. My suggestion is to make all these optional features required to be compiled in, but then they can be enabled/disabled via configuration. And the default configuration can have them on or off as you think is overall best for the user community. But then if someone needs it (or not), they simply enable/disable it and don't have to wonder/figure out if it is supported or not in the version compiled for them.

Having to compile things to change behavior/enable options is very strange to me and I think not very nice to users.

[victorhora]

@davewichers

As mentioned on #1913, ModSecurity is a performance focused, general purpose WAF (not a "WAF product"). It's core concept is being a highly customizable WAF engine.

ModSecurity is meant to run in many platforms, including resource constrained environments (e.g. an ARM micro PC) where a the user might not have a readily available port of a given component (e.g. YAJL/libXML) or simply because the user doesn't want or need that feature and choose not to use to save resources, hence why they are called optional ;)

make all these optional features required to be compiled in, but then they can be enabled/disabled via configuration

All the optional features will be enabled by default if the libraries/dependencies are available and they can also be turned on or off regardless. If you do try to make an optional component mandatory by adding--with-yajl=yes to the configure script but the library is not present, the compilation will not proceed.

If you do try to use the JSON parser (YAJL) but you don't have it enabled you should get a warning on your logs (see msc_reqbody.c#L139)

Also, as soon as you start ModSecurity, you should get the below on your Apache log which will inform you of which features and versions you have compiled/running:

[Mon Sep 24 16:19:53.000614 2018] [:notice] [pid 0:tid 0] ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/) configured.
[Mon Sep 24 16:19:53.000802 2018] [:notice] [pid 0:tid 0]] ModSecurity: APR compiled version="1.5.1"; loaded version="1.5.1"
[Mon Sep 24 16:19:53.000821 2018] [:notice] [pid 0:tid 0]] ModSecurity: PCRE compiled version="8.35 "; loaded version="8.35 2014-04-04"
[Mon Sep 24 16:19:53.000851 2018] [:notice] [pid 0:tid 0] ModSecurity: YAJL compiled version="2.1.0"
[Mon Sep 24 16:19:53.000864 2018] [:notice] [pid 0:tid 0] ModSecurity: LIBXML compiled version="2.9.1"
[Mon Sep 24 16:19:53.000919 2018] [:notice] [pid 0:tid 0] ModSecurity: StatusEngine call: "2.9.2,Apache/2.4.10 (Debian),1.5.1/1.5.1,8.35/8.35 2014-04-04,(null),2.9.1,

As mentioned, If you are still struggling with features being disabled on a specific packaged version of ModSecurity by a third party (e.g. CentOS) I would suggest taking these concerns to the packagers or simply rebuilding ModSecurity or even rebuilding the RPM yourself.

[davewichers]

Thanks for this explanation and these details. They are helpful.

…

On Sep 26, 2018, at 5:34 PM, Victor Hora ***@***.***> wrote: @davewichers As mentioned on #1913, ModSecurity is a performance focused, general purpose WAF (not a "WAF product"). It's core concept is being a highly customizable WAF engine. ModSecurity is meant to run in many platforms, including resource constrained environments (e.g. an ARM micro PC) where a the user might not have a readily available port of a given component (e.g. YAJL/libXML) or simply because the user doesn't want or need that feature and choose not to use to save resources, hence why they are called optional ;) make all these optional features required to be compiled in, but then they can be enabled/disabled via configuration All the optional features will be enabled by default if the libraries/dependencies are available and they can also be turned on or off regardless. If you do try to make an optional component mandatory by adding--with-yajl=yes to the configure script but the library is not present, the compilation will not proceed. If you do try to use the JSON parser (YAJL) but you don't have it enabled you should get a warning on your logs (see msc_reqbody.c#L139) Also, as soon as you start ModSecurity, you should get the below on your Apache log which will inform you of which features and versions you have compiled/running: [Mon Sep 24 16:19:53.000614 2018] [:notice] [pid 0:tid 0] ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/) configured. [Mon Sep 24 16:19:53.000802 2018] [:notice] [pid 0:tid 0]] ModSecurity: APR compiled version="1.5.1"; loaded version="1.5.1" [Mon Sep 24 16:19:53.000821 2018] [:notice] [pid 0:tid 0]] ModSecurity: PCRE compiled version="8.35 "; loaded version="8.35 2014-04-04" [Mon Sep 24 16:19:53.000851 2018] [:notice] [pid 0:tid 0] ModSecurity: YAJL compiled version="2.1.0" [Mon Sep 24 16:19:53.000864 2018] [:notice] [pid 0:tid 0] ModSecurity: LIBXML compiled version="2.9.1" [Mon Sep 24 16:19:53.000919 2018] [:notice] [pid 0:tid 0] ModSecurity: StatusEngine call: "2.9.2,Apache/2.4.10 (Debian),1.5.1/1.5.1,8.35/8.35 2014-04-04,(null),2.9.1, As mentioned, If you are still struggling with features being disabled on a specific packaged version of ModSecurity by a third party (e.g. CentOS) I would suggest taking these concerns to the packagers or simply rebuilding ModSecurity or even rebuilding the RPM yourself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[acidumirae]

This is for poor CentOS people who end up here while googling the problem:
Solution is to use the Atomic packages with the YAJL support compiled in.

yum install wget yajl-devel.x86_64

wget http://www6.atomicorp.com/channels/atomic/centos/7/x86_64/RPMS/mod_security-2.9.2-2748.el7.art.x86_64.rpm

wget http://www6.atomicorp.com/channels/atomic/centos/7/x86_64/RPMS/atomic-curl-libcurl-7.38.0-5.1.el7.art.x86_64.rpm

wget http://www6.atomicorp.com/channels/atomic/centos/7/x86_64/RPMS/atomic-curl-curl-runtime-7.38.0-5.1.el7.art.x86_64.rpm

yum localinstall atomic-curl-libcurl-7.38.0-5.1.el7.art.x86_64.rpm mod_security-2.9.2-2748.el7.art.x86_64.rpm atomic-curl-curl-runtime-7.38.0-5.1.el7.art.x86_64.rpm

[khurshid-alam]

@victorhora How can we check this on windows ? I am using 2.9.3, but SecAuditLogFormat JSON in C:\Program Files\ModSecurity IIS\modsecurity.conf doesn't write the log in json format ? Windows server 2019.

What am I missing ?

[martinhsv]

Hello @khurshid-alam ,

Note that that setting only affects the ModSecurity audit log, not the format written to the server's error log file.

If the official installer published in github was used, then yajl should be included. This means JSON processing -- both for parsing of input and writing of audit log entries -- should be available.

There are a few ways you could confirm it. One option: If json support is available and if you enter an invalid value like SecAuditLogFormat: Abc, then you should get an error message.