anti-automation

gmadarm · 2014-06-17T16:55:00+00:00

This worked wonderfully! I achieved similar results on my x64 platform. Many thanks! On 6/16/2014 13:00, Yichun Zhang (agentzh) wrote: Hello! On Mon, Ju...

anti-automation

gmadarm

I want to add anti-automation capabilities to openresty which will prevent an attacker from running attack scripts like sqlmap against my app. Initially I thought of using lua to increase a counter in a redis hash with a short lived TTL to track the number of times a user requests a given URI within a defined period of time and then set a flag when too many requests are sent within X seconds. I think the major problem with this approach is the bottleneck it could create due to each request needing to update redis. Is that something I should be concerned with? As nginx does not support piped logging, can you suggest a better approach to prevent automated scripts from running against a web application?

thanks,
-G

brian

you could do the redis update in a "thread" - http://wiki.nginx.org/HttpLuaModule#ngx.thread.spawn - or you could just increment a counter in a table and have a timer that "dumps" this to redis every second.

lordnynex

Don't reinvent the wheel. Use nginx limit_req_module. I'd love to give you an example but I'm traveling currently. It is very well documented.

Sent from my iPhone

On Jun 17, 2014, at 3:54 AM, Gordon Madarm <gma...@gmail.com> wrote:

I want to add anti-automation capabilities to openresty which will prevent an attacker from running attack scripts like sqlmap against my app. Initially I thought of using lua to increase a counter in a redis hash with a short lived TTL to track the number of times a user requests a given URI within a defined period of time and then set a flag when too many requests are sent within X seconds. I think the major problem with this approach is the bottleneck it could create due to each request needing to update redis. Is that something I should be concerned with? As nginx does not support piped logging, can you suggest a better approach to prevent automated scripts from running against a web application?

thanks,
-G

.

mat999

Test the performance of doing this, we do something similar with redis ourselves. Choose your data structure very well.

We have noticed redis & lua become a bit of a bottleneck at close to 5-10k req/sec. I would recommend using the limit_req module for simple limiting in addition to a lua / redis module for complex hash signatures.

On Tuesday, June 17, 2014 6:54:59 PM UTC+10, Gordon Madarm wrote:

I want to add anti-automation capabilities to openresty which will prevent an attacker from running attack scripts like sqlmap against my app. Initially I thought of using lua to increase a counter in a redis hash with a short lived TTL to track the number of times a user requests a given URI within a defined period of time and then set a flag when too many requests are sent within X seconds. I think the major problem with this approach is the bottleneck it could create due to each request needing to update redis. Is that something I should be concerned with? As nginx does not support piped logging, can you suggest a better approach to prevent automated scripts from running against a web application?

thanks,
-G

agentzh

Hello!

On Tue, Jun 17, 2014 at 6:39 PM, Mathew Heard wrote:
> We have noticed redis & lua become a bit of a bottleneck at close to 5-10k
> req/sec. I would recommend using the limit_req module for simple limiting in
> addition to a lua / redis module for complex hash signatures.
>

Please ensure you have used the flame graph tools to analyze your
loaded nginx and redis processes to prevent common mistakes in your
coding or configurations:

    http://openresty.org/#Profiling

According to our experiences, knowing where the bottleneck truly is
can often lead to massive speedup via trivial changes ;)

Regards,
-agentzh

mat999

That requires a kernel patch for the userspace probes (on kernel 3.10)? I tried to get it to work ages ago without luck.

On 18 Jun 2014 12:51, "Yichun Zhang (agentzh)" <age...@gmail.com> wrote:

Hello!

On Tue, Jun 17, 2014 at 6:39 PM, Mathew Heard wrote:
> We have noticed redis & lua become a bit of a bottleneck at close to 5-10k
> req/sec. I would recommend using the limit_req module for simple limiting in
> addition to a lua / redis module for complex hash signatures.
>

Please ensure you have used the flame graph tools to analyze your
loaded nginx and redis processes to prevent common mistakes in your
coding or configurations:

http://openresty.org/#Profiling

According to our experiences, knowing where the bottleneck truly is
can often lead to massive speedup via trivial changes ;)

Regards,
-agentzh.

agentzh

Hello!

On Tue, Jun 17, 2014 at 7:57 PM, SplitIce wrote:
> That requires a kernel patch for the userspace probes (on kernel 3.10)? I
> tried to get it to work ages ago without luck.
>

Kernel 3.5+ has uprobes by default and kernel 3.10+ has uretprobes by
default. So you don't need to patch the kernel to get user-space
probing support at all.

Regarding the flame graph tools, it is recommended to apply the
following patch to add back the timer hook API to the kernel for the
best results (though without the patch, it should also work, more or
less):

    http://agentzh.org/misc/kernel/linux-3.10.16-timer_hook_api.patch

The timer hook API was removed in kernel 3.8 or 3.9 because the kernel
developers thought there was no out-of-tree users for this feature. So
using kernel 3.5 ~ 3.7 do not need this patch at all.

Regards,
-agentzh

mat999

I just re-read the toolkit README, and sure enough my problem was the systemtap version that is bundled with Debian Wheezy (1.7) is not new enough (and there's nothing backported).

When I have some time Ill have to look into this. I have a few suspected locations for performance but it would be good to confirm it :)

On Thu, Jun 19, 2014 at 9:47 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, Jun 17, 2014 at 7:57 PM, SplitIce wrote:
> That requires a kernel patch for the userspace probes (on kernel 3.10)? I
> tried to get it to work ages ago without luck.
>

Kernel 3.5+ has uprobes by default and kernel 3.10+ has uretprobes by
default. So you don't need to patch the kernel to get user-space
probing support at all.

Regarding the flame graph tools, it is recommended to apply the
following patch to add back the timer hook API to the kernel for the
best results (though without the patch, it should also work, more or
less):

http://agentzh.org/misc/kernel/linux-3.10.16-timer_hook_api.patch

The timer hook API was removed in kernel 3.8 or 3.9 because the kernel
developers thought there was no out-of-tree users for this feature. So
using kernel 3.5 ~ 3.7 do not need this patch at all.

Regards,
-agentzh.