As the this new Curl version supports well the Windows certificate storage,
removing the dependency on the OpenSSL. Also changing the build scripts to work
accordingly. As the cmake build of Curl is said to broken abandoning it in
favor of the nmake files. Thanks to Gregg Smith and Steffen.
Resources load mechanism as the SecRemoteRuels were not showing information
about the loaded rules while Apache was reloaded. This patch add such
information to reload in the same way that it was showing on restart.
As reported by Walter Hop, the status call functionality was printing a message
in the console without the expected 'ModSecurity:' prefix. SecServerSignature
was also printing messages without the expected prefix. Both are fixed by this
commit.
As reported by Walter Hop on our dev- mailing list, remote resource download
was not validating the HTTP code, parsing errors pages as resources. This
commit fix this issue, from now one HTTP error codes will be verified and
treated as errors. Operators are now dealing well with empty values that may
be produced in consequence of a download error.
As reported by Christian Folin and Walter Hop on our dev mailing list, Apache
mod_ssl was failing if a remote resource was utilized. That was happening
because Curl clean up was also cleaning up the OpenSSL data used by mod_ssl.
This patch moves Curl initialization to happens while ModSecurity is
initialized.
As reported by Rainer Jung, Curl may not be mandatory to build
ModSecurity core. This patch make it optional by:
- Concentrate all downloads using curl on msc_remote_rules.c
- Split Curl build definitions checks into: WITH_CURL, WITH_REMOTE_RULES
and WITH_CRYPTO.
- WITH_CURL: Contains Culr headers and binaries during the build time.
- WITH_REMOTE_RULES: Currently enabled if Curl is present.
- WITH_CRYPTO: Set if apr tool was compiled with crypto support.
- Renames msc_remote_grab_content to msc_remote_download_content
On IIS CA validation was not working as libcurl on windows does not look for a
certificate store, unless it is specified. The resource downloads are now
respecting the SecRemoteRulesFailAction.
This commit makes ModSecurity to refuse to download or install rules
(SecRemoteRules) from sites that are not running HTTPS with a valid and
trusted certificate.
Originally the SecRemoteRules fetch the rules from an remote server in an
specific format, using cryptography. This patch adds the possibility to
load rules in plain/text format.
SecRemoteRules adds a new dependency to libcurl. Before only mlogc was
depending on libcurl. SecRemoteRules also depends on the apr-tools with
crypto support, which (as reported by our buildbots) is not default in
some environments such as: MacOS X. This commit disable SecRemoteRules
support if apr-tools was not compiled with crypto support.
This directive allows the user to set a default action whenever the
SecRemoteRules failed to download a set of rules. Current the supported
values are: Warn and Abort. By default `Abort' is selected.
Initially those directives were only able to load content from a
local file. This commit extends this functionality allowing the user to
provide an HTTP URI that can be downloaded and loaded by ModSecurity.
Initially the download is associated with a server restart. For next
versions we expect to load such resources as it become outdated (Without
need to resetart the server).
The script was looking for the wrong header file. Instead of look for
yajl_parse.h it was looking for yajl.h. Originally reported by
@rpfilomeno at #804.
On Apache platform the server signature can be replaced using the
SecServerSignature directive. Status call was using the signature informed by
this directive instead of using the original one. As reported at #702.
As reported at #714 status calls with long `apache version' name was broken.
DNS queries cannot be so long. This field is now limited to 25 characters
which is a valid size when encoded into base32
Seems like curl versions older than 7.34.0 does not have support for
`CURL_SSLVERSION_TLSv1_2'. In this cases, using CURL_SSLVERSION_TLSv1
which was added at version 7.9.2. ModSecurity demands a curl version
newer than 7.15.1.
Using apr-util installed by Macports results in build failure because apr-util uses BerkeleyDB that MacPorts installs into a subdir of $prefix/lib and $prefix/include (so that multiple versions of BerkeleyDB can be installed simultaneously). apu-1-config's --ldflags output includes the -L/path/to/bdb that's needed.
As of Automake 1.4, it starts to warning about the lack of utilization
of `subdir-objects' option, which will be default in the further
releases. Avoiding break stuff we are patching ModSecurity to support
such option when it still an option (Issue #760).
FuzzyHash operator is optional and only installed if the headers for libfuzzy
was found in the system. Otherwise, the FuzzyHash operator is disable during
the compilation. After this commit, if some rules tries to use it, ModSecurity
will produce an runtime error not a config time error, allowing the web server
to procede normal with its operations.
The fuzzyHash operator can be used to match files. In conjuntcion
with FILES_TMP_CONTENT collection it can scan uploaded files and
try to match it with a pre caculated list of know malicious content,
more details on how it works can be found on ssdeep website:
http://ssdeep.sourceforge.net/
The collection is filled with a key-value set where value is the content of
the file which was uploaded. This collection can be used with all supported
operators, however SecUploadKeepFiles should be set to 'On' in order
to have this collection filled.
