[squid-users] block user agent

[Alex Rousskov]

On 11/17/2017 08:27 AM, Vieri wrote:
> From: Alex Rousskov <rousskov at measurement-factory.com>
>> 1. Your "works" and "does not work" setups currently differ in at least
>> three variables: user agent name, slash after the user agent name, and
>> acl negation in http_access. Find out which single variable is
>> responsible for the breakage by eliminating all other differences.
>>
>> 2. Post two ALL,2 cache.logs, each containing a single transaction, one
>> for the "works" case and one for the "does not work" case polished as
>> discussed in #1.

> I can't really do anything about #1 except maybe leave out the forward slash.
> That's because my 2 examples are trying to achieve the opposite.

You may be conflating two very different goals:

  A) Understanding why Squid does X.
  B) Configuring Squid to do what you want.

My response was focused on the former. Once you understand, you can
probably accomplish the latter on your own.

To understand why two similar setups act differently, I would reduce the
number of different variables until you find the variable that explains
the difference. Yes, none of the tested reduced setups may do what you
want your production Squid to do, but that should not matter for now.
You are after understanding.

The usual alternative to the above approach is trying random
configurations until you think Squid works the way you want it to work.
Usually, Squid still does not do what you think it does, but your test
cases do not expose the difference.


> My goal is to deny all client traffic from browsers that DO NOT have
> a specific user-agent string. So this is a negated statement.

There is no need to use negation for that. If the goodAgents ACL matches
requests with "specific user-agent string", then you can do this:

  http_access allow goodAgents
  http_access deny all

As you can see, there is no ACL negation or negative ACLs.


> Common to both:
> 
> acl allowed_useragent browser MyAllowedUAstring
> acl denied_useragent browser MyDeniedUAstring
> 
> # example 1:
> http_access deny denied_useragent
> http_reply_access deny denied_useragent

If you want to block access to the origin server, do not use
http_reply_access. Use http_access.


> # example 2:
> http_access deny !allowed_useragent
> http_reply_access deny !allowed_useragent
> 
> Then I run this from the client:
> 
> # curl --insecure --user-agent MyAllowedUAstring https://www.gentoo.org
> -> I was expecting to be allowed access since Squid denies "everything that's not" MyAllowedUAstring. Well, at least I should have passed the "deny" line in example 2.
> However, I'm being blocked right there.

> ---------
> CONNECT 89.16.167.134:443 HTTP/1.1
> Host: 89.16.167.134:443
> ----------
> clientAccessCheckDone: The request CONNECT 89.16.167.134:443 is DENIED; last ACL checked: allowed_useragent


As you can see, your CONNECT request was denied (because it lacks the
User-Agent header). The rest does not matter much (for now), but Squid
bumps the connection to serve the error page in response to the first
bumped HTTP request (regardless of what that first bumped HTTP request
looks like).

Alex.