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.
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 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 ipv4 representation was only accepting slash notation with masks
represented in 2 digits. In the ipv6 implementation several fixies were made:
The maximum value to a bitmask was 64 which is not the reality, as ipv6 can
handle 128 bits. The second change was also to enable mask representation with
more and less than 2 digits. A more general fix was added to allow the unit
tests to work even if a invalid ip/range was informed during the creation of
the "tree", now it is checking if the tree is NULL while performing the
execution of the operator. Initial problem was reported at the issue: #706.
Used by the operator @ipMatch and variants, this structure storage all the IPs
addresses for later comparison. Last version was using RadixTree only if the
set of IPs was specified from files. IPs specified as parameters, was using
a chained list. Chained lists may affect the performance, since lookups in
worst case will be O(n). RadixTrees could provide better results depending
on the amount of elements and its contents.
The operators @ipMatch, @ipMatchF and @ipMatchFromFile were
added to the functions: SecReadStateLimit and SecReadStateLimit,
by using them it is possible to declare a suspicious list. When
a suspicious list is given, the {Read|Write}StateLimit will be
applied just to the IPs that belongs to that restricted list.
Note that the negative of those operators (e.g. !@ipMatch) can be
used to place a whitelist. The {Read|Write}StateLimit
restrictions will not be applied to those in the whitelist.
This current version the Sec{Read|Write}StateLimit can be used
varios times to add elements to both lists, however, the
last informed limit will be applied for the entire group. This
feature is experimental, and suggestions on how to improve it
are very welcome. For further discussion use the issue: #353.
Testing inet_pton with the help of Steffen. Acording to Steffen we can use
!(NTDDI_VERSION >= NTDDI_VISTA) to identify that the specific Windows version
has this function defined or not, if so we can use the Windows version.
Reverting this commit to avoid to overwrite the Windows' function. And
see the original error that happened before this commit.
There is a function named inet_pton on windows API, with different
signature. This patch just override the windows function and point
the inet_pton to our implementation.
