Search squid archive

Re: block user agent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux