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.
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.
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.
The SecRuleEngine has the capability to Enable, Disable or even to place the
ModSecurity in DetectionOnly mode. The SecReadStateLimit and SecWriteStateLimit
were not honoring such state, due the fact that our configuration belongs to
requests not to connections, the only struct that exists while those filters
are placed. By adding a global variable "conn_limits_filter_state" we are now
able to identify the current state of the ModSecurity, once the configuration
is loaded this variable is set and used by the connections filters.
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.
Now searching for yajl using find_yajl.m4 macro file instead
of using pkg-config directly. If YAJL was not found or if it
was disabled in the configure phase, the code will be compiled
without JSON support.
