[squid-users] block user agent

Amos Jeffries squid3 at treenet.co.nz
Mon Nov 20 13:51:44 UTC 2017


On 20/11/17 21:45, Vieri wrote:
> ________________________________
> From: Alex Rousskov
>>
>> 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.
> 
> 
> You are absolutely right. I'd like to uderstand how Squid *access rules work.
> 
> 
> To put it bluntly, http_access and http_reply_access rules are processed one after another as they appear in squid.conf. It "exits" the sequence (ie. stops going through each http_*access rule) as soon as it hits a match.
> 

Not quite. The lines which start with the same directive name are 
executed that way. Each directive has a different timing within the 
transaction lifetime.


  http_access allow foo
  http_reply_access deny foo
  http_access allow bar

Is the same as

  http_access allow foo
  http_access allow bar

  http_reply_access deny foo


http_access lines are checked on a client HTTP request arriving. 
http_reply_access on a server HTTP reply arriving.


> 
> The http_*access rules take on ACLs which can be AND'ed if the conditions are in one line, or OR'ed if they are on seperate lines.

That is binary, access control lines are trinary logic with short-cuts.

> eg.
> http_access allow goodAgents !baddomains (AND)
> #--
> http_access allow goodAgents
> http_access deny baddomains (OR)

You also have to take action into account.

For this:

   http_access allow goodAgents !baddomains (AND)

  If the first line matches the allow happens.
  otherwise deny happens

ie. goodAgents are only allowed to non-baddomains. All non-goodAgents 
are denied to everything.


For this:

   http_access allow goodAgents
   http_access deny baddomains (OR)

  If the first line matches the allow happens,
  If the second matches deny happens,
  otherwise allow happens.

ie. goodAgents are allowed to do anything. All non-goodAgents are denied 
only to baddomains.


> 
>>> 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.
> 
> 
> I understand your example, but unfortunately, I was looking for something else. It's my mistake because I started this thread with basic, stripped-down examples without giving details on what I need to achieve. I wasn't doing ACL negation just for kicks. It's because I need to integrate it into a broader setup.
> 
> Your example "works", but Squid will match "goodAgent" in your first line, and exit without going on. I require to apply other rules afterwards. In other words, my intention was to first filter based on the UA string, and block all except eg. MyAllowedUAstring. From then on, I need to apply the rest of my rules.
> 
>>> 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).
> 
> So... What is the security implication of allowing all CONNECT messages to port 443?
> 

Allowing them all the way through Squid is bad. But that is not what is 
needed here. ssl_bump rules get applied after the CONNECT is accepted 
*in* for proxy processing and they decide what happens to the tunneled 
data based on what is found there.
  If bumping is decided the TLS gets removed and the messages inside 
individually go through the http_access process.


...
> I'd greatly appreciate your input on this.
> 
> Hoping to understand Squid logic someday.

To speed that up enable debug_options 28,3.

I second Alex's recommendation about removing the "denied_" and 
"allowed_" bits of your ACL names. It will make what is going on a LOT 
clearer to see and understand.


Amos


More information about the squid-users mailing list