Re: Rate Limiting Blog Link

Hi Bradford,

To send to violators to a different backend, based of the example I used in that post you want something like:

In Frontend:
use_backend go-away if source_is_abuser

Then a backend like:
backend go-away

        mode http
        errorfile 503 /etc/haproxy/errors/503rate.http

Not sure off hand how to make it work with a reserved word however, hope this helps.
-Kyle

On Tue, Apr 12, 2011 at 9:37 AM, bradford <fingermark#gmail.com> wrote:

> Excellent point, Jonathan. So, would having HAProxy support/implement
> HTTPS be the only way to allow HTTPS rate limiting (in HTTPS only and HTTP
> and HTTPS mixed environments)?
>
> As for my other point. Have you looked at the sample configuration on http://blog.serverfault.com/post/101649187use_backend
> go-away if source_is_abuser3/<http://blog.serverfault.com/post/1016491873/>
>
> It's a lot of configuration. And in that post it even describes part of
> the configuration as "more cryptic but is not too complicated." I don't
> know many people who could configure their server to do rate limiting
> without that blog post (and just the documentation). Moreover, if you took
> over a project and saw this configuration, it'd take you a bit to figure out
> what's going on. There are also statements in that post such as "the expire
> argument is how long to keep an entry in the table (In this case it just
> needs to be twice the length of the longest rate argument for a smoothed
> average). The time arguments for connection rate and bytes out rate are how
> long to calculate the average over."
>
> I just want a rate-limit reserved word that allows me to control connection
> rate / second (and bytes out rate), where i can send to some additional
> backend if violated.
>
>
> On Mon, Apr 11, 2011 at 5:47 AM, Jonathan Matthews <
> contact#jpluscplusm.com> wrote:
>
>> On 6 April 2011 16:42, bradford <fingermark#gmail.com> wrote:
>> > Also, in a previous email I mentioned something about
>> > X-Forwarded-For IP addresses being comma delimited. This table would
>> have
>> > to take that into consideration, I guess.
>>
>> No it shouldn't.
>> If you rate-limit based on information that you find in the XFF header
>> you allow malicious users to
>>
>> a) bypass the rate-limit by faking up different XFF headers each time or
>> b) DoS legitimate users by faking up the same, matching, XFF header
>> each time and letting haproxy do the DoS for them
>>
>> Also, above and beyond "I haven't understood it yet", the rest of your
>> email was rather light on *detail*. If other people are comprehending
>> and happily using the functionality based on the existing config
>> requirements and documentation, then perhaps the flaw doesn't lie with
>> the config and/or documentation.
>>
>> My 2-pence,
>> Jonathan
>> --
>> Jonathan Matthews
>> London, UK
>> http://www.jpluscplusm.com/contact.html
>>
>>
>
Received on 2011/04/19 17:38