On Mon, Sep 26, 2016 at 4:28 AM, Anoop Alias <anoopalias01 at gmail.com> wrote:
> Ok .. reiterating my original question.
>> Is the usage of if / map in nginx config more efficient than say naxsi (
> or libmodsecurity ) for something like blocking SQL injection ?
>
Strictly speaking, and barring performance costs of the regexes themselves
using only if/map directives in place of a full-featured WAF would likely
be more less expensive, because any decent WAF will do more than just a
single regular expression. That doesn't make this a better solution, though.
> For example, https://github.com/nbs-system/naxsi/blob/master/nax> si_config/naxsi_core.rules
> rules 1000-1099 - blockes sql injection attempt
>> So ..do (to a limited extent )
>> ## Block SQL injections
> set $block_sql_injections 0;
> if ($query_string ~ "union.*select.*\(") {
> set $block_sql_injections 1;
> ............
>
Using multiple .* patterns like this is pretty bad form. It doesn't lead to
_catastrophic_ backtracking, but there are certainly much smarter and
cheaper ways to accomplish this, particularly with larger input sets.
Beyond this, checking like this doesn't allow you to examine request body
data or arbitrary headers, which seems like a very poor approach.
.....................
> if ($block_file_injections = 1) {
> return 403;
> }
>>Using a simple return 403 here, without any logging or debug/audit
information, could make it very very difficult to track down false
positives and issues with your user base.
> From the point of application performance which one is better .. ?
> Performance for a shared hosting server with around 500 vhosts.
>
This smells very much like premature optimization. If you are truly
concerned with securing this many sites, adopting a more feature solution
should be the goal. If you are this truly focused on squeezing out every
bit of performance as possible, using such a large hammer with generic
regexes and hundreds of if/map blocks seems like the wrong road to take.
There is a reason that there is no good community solution for a WAF
replacement in vanilla Nginx config syntax. It's simply not a good idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160926/0da17182/attachment.html>