0

I would like to blacklist IPs that are spamming a particular URL, but only for a determined amount of time. let's say 10 minutes.

I'm thinking of creating a stick-table, and store the src IP and increment a counter. Once the counter exceed X retries, I deny it.

stick-table has an expire parameter, but I noticed that as long as there's new data that are written in it, the expire counter is resetted. So the expire parameter is table-wide. Thus, entries will never expire until nothing is added for 10 minutes.

Is there any way to achieve this sort of temporary blocking ?

Bastien974
  • 1,824
  • 12
  • 43
  • 61

1 Answers1

2

Stick tables do in fact have an expiry, but it's counted/calculated per entry, not per table.

Per the docs:

expire
Defines the maximum duration of an entry in the table since it was last created, refreshed or matched. The expiration delay is defined using the standard time format, similarly as the various timeouts. The maximum duration is slightly above 24 days. See section 2.2 for more information. If this delay is not specified, the session won't automatically expire, but older entries will be removed once full. Be sure not to use the "nopurge" parameter if not expiration delay is specified.

So you can use them for what you want to do.

In fact, this has already more or less been answered in a blog post by the fine people that run this site, as well as one by the people who maintain HAProxy.

Basically, you'd just need a few of lines to make it work

stick-table type ip size 100k expire 10m store conn_rate(3s)
tcp-request connection reject if { src_conn_rate ge 10 }
tcp-request connection track-sc1 src

Where conn_rate(3s) should be modified to reflect the connection rate that should trigger a temporary blacklisting.

GregL
  • 9,030
  • 2
  • 24
  • 35
  • Odd, I did try this solution already, with a very short expire (5sec), none of my entries were expiring because only one entry were being updated constantly. I'll retry, probably an error on my part... – Bastien974 Jul 21 '15 at 13:25
  • @GregL You're second link is to the same SF blog post, so a miss paste there you may want to update. – Kyle Brandt Jul 27 '15 at 01:47