[squid-users] block user agent

[Amos Jeffries]

On 21/11/17 23:06, Vieri wrote:
> 
> ________________________________
> From: Amos Jeffries
>>
>>    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.
> 
> 
>  From this I deduce that in my case I cannot use "http_access allow goodAgents", but I need to go for "http_access deny !goodAgents" so I can continue on evaluating the rest of my http_access rules.
>> 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.
> 
> 
> You lost me there. Here's what I did today.
> 
> I took your advice (and Alex's), and renamed my ACL labels. Unfortunately, I'm still a little confused :-(.
> 

[ snipping the log traces to keep the mail relatively small ]
> 
> It seems that Squid decides to ALLOW, right?

Look at the "markFinished" lines for the outcome of each set of access 
controls outcomes. The lines leading up to those details which ACL tests 
are performed and which *_access lines they were on.


Ignoring the first few quoted lines which are for some earlier 
ssl-bumped transaction I see:

* http_access line #9 DENIED an HTTP request.

* access_log is ALLOWED to record something. Probably unrelated traffic.

* http_reply_access line #9 ALLOWED a reply to be delivered, then

* access_log is ALLOWED to log something.


> 
> Isn't the message "The request CONNECT 89.16.167.134:443 is DENIED" what I should be concentrating on?
> Isn't that the root cause?

Yes, that line is the outcome. The cause of the denial is what ACL 
check(s) led to it.

Specifically in these log lines:

   matches: checked: interceptedssl = 1
   match: aclIpMatchIp: '10.215.144.48' found
   matches: checked: localnet = 1
   matches: checked: !localnet = 0
   matches: checked: http_access#8 = 0

   matches: checked: good_useragents = 0
   matches: checked: !good_useragents = 1
   match: aclIpMatchIp: '10.215.144.48' NOT found
   matches: checked: src_ips_with_any_useragent = 0
   matches: checked: !src_ips_with_any_useragent = 1
   matches: checked: http_access#9 = 1
   matches: checked: http_access = 1

Which strangely do not seem to match your squid.conf details. These are 
the 8th and 9th http_access lines in the squid.conf which is used by the 
running proxy.
But in your quoted squid.conf they are lines #4 and #5.


  http_access deny interceptedssl !localnet
   - it was interceptedssl from localnet
   - so not a match due to !localnet

  http_access deny !good_useragents !src_ips_with_any_useragent
   - it has no UA, and
   - it is not listed n that IP whitelist.
   - the NOT condition (!) on both of those make the whole line a match.


> In another message, you mentioned that I should notice that Squid reports another ACL name (in this case, after the name change, it's "bad_replied_mimetypes").
> In any case, the message "The reply for GET https://www.gentoo.org/ is ALLOWED" means that Squid should ALLOW, right?

No, it means that *reply* is allowed.

A reply *might* be from a server, or from cache, or a 403 denial error 
page generated by Squid, or one of the deny_info redirects you have 
configured to happen - like that one in the "HTTP Client REPLY" in the 
second log trace.



> However, why do I get a 307 redirect to a deny_info page (where incidentally the URL refers to bad_useragents, not bad_replied_mimetypes)?

Because the CONNECT _request_ was denied and that redirect _reply_ is 
what a deny_info with a URL generates when its associated ACL causes a 
denial.

bad_useragents was the ACL checking the *request* which triggered that 
redirect to happen.

bad_replied_mimetypes was just the last ACL tested to see if that 
redirect was allowed to be delivered to the client.


If we assume that the two log traces actually line up then 
bad_replied_mimetypes is actually irrelevant because the 
http_reply_access result is actually "NO match found, last action DENIED 
so returning ALLOWED"


> 
> I can't seem to clear this out and make it work without adding "http_access allow CONNECT SSL_ports" right before checking for the useragent.


If you place that after the default "deny CONNECT !SSL_ports", and 
before your UA checks, AND if you are using ssl_bump on the allowed 
tunnels then you can relatively safely use "allow CONNECT".

Just be careful that the CONNECT allowed by that are always handled 
safely by the ssl_bump rules you have.
  Meaning that you either bump or terminate traffic you are not sure is 
okay, splice if you are reasonably sure, etc. it is a balancing effort 
between "splice as much as possible" and "terminate if unsure of the 
traffic" advice.


Just FYI you would be a huge amount better off dropping the UA 
fingerprinting. It's a _really_ simplistic idea about the HTTP world, 
and it is partly because of that overly-simplistic nature and depending 
on unreliable values that you are having so much more trouble than 
normal admin face.

Amos