Re: [squid-users] squid and unauthorized clients rate-blocking

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 15 Mar 2013 16:46:04 -0600

On 03/13/2013 04:27 AM, Eugene M. Zheganin wrote:

> I use squid mostly for internet access authorization in corporate
> network. I have a problem. Let's suppose some foobar company has
> developed a proxy-unaware update mechanism using HTTP to update their
> software. Or some internet company wrote a javascript that does execute
> outside proxy context in a browser. Such things can produce a massive
> amount of GET requests which squid answers with HTTP/407. Massive like
> thousands per seconds from just one machine.

Ouch.

> In the same time, being
> explicitly blocked with HTTP/403 answers, this madness stops. So, is
> there a mechanism that I could use for, like, send 403 after exceeding
> some rate to a client ? Or rate-block some acls ? Or something similar ?

That Javascript wonder probably uses a specific upgrade URL or two. Can
you block just those with a URL-specific ACL? If you place "http_access
deny" with that ACL before authentication ACLs, Squid should respond
with 403 Forbidden. I understand that this is not fully automated
because you need to maintain the black list of update URLs, but it gives
you an immediate and simple solution:

    http_access deny badScriptUrl
    http_access allow !needsAuthentication
    http_access allow authenticated

If you really want to rate-limit, you can probably do that using an
external ACL that will compute the request rate of unauthenticated
requests and deny access based on that. AFAICT, you do not really need
to measure authentication failure rate (although that would be possible
in a custom authenticator too) -- measuring the rate of
not-yet-authenticated-but-must-be-authenticated requests would be
sufficient in practice (and might be even overall better as it will
protect your authentication code).

    http_access allow !needsAuthentication
    http_access allow lowRate authenticated

HTH,

Alex.
Received on Fri Mar 15 2013 - 22:46:07 MDT

This archive was generated by hypermail 2.2.0 : Sat Mar 16 2013 - 12:00:05 MDT