[squid-users] ACL matches when it shouldn't
rentorbuy at yahoo.com
Tue Sep 29 22:03:33 UTC 2020
> None of the file entries are anchored regex. So any one of them could match.
>> Can anyone please let me know if there's a match, or how to enable debugging to see which record in this ACL is actually triggering the denial?
> To do that we will need to see the complete and exact URL which is being blocked incorrectly.
One of them is https://www.google.com/.
> NP: a large number of that files entries can be far more efficiently blocked using the dstdomain ACL type. For example:
> acl blacklist dstdomain .appspot.com
Agreed. However, this file is generated by an external process I don't control (SOC). It's like a "threat feed" I need to load in Squid.
The easiest way for me would be to tell Squid that it's just a list of exact URLs, not a list of regexps. I understand that's not possible.
This list comes with entries such as:
So, if I don't want Squid to complain I process it a little before serving it to it and the above line becomes:
You mention anchoring them... So now I adjusted the processing and the above becomes:
I'm still getting the same denial when a client tries to access https://www.google.com/.
This is what I can see in cache.log:
client_side_request.cc(751) clientAccessCheckDone: The request GET https://www.google.com/ is DENIED; last ACL checked: bad_dst_urls
I'm also seeing other denials such as:
client_side_request.cc(751) clientAccessCheckDone: The request GET http://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt is DENIED; last ACL checked: bad_dst_urls
If I grep http://www.microsoft.com/pki/certs in the ACL file I get no results at all.
That's why I'm puzzled.
So here's the new anchored regex file in case you have the chance to test it and reproduce the issue:
Squid doesn't complain about syntax errors so I'm assuming the ACL is as expected.
More information about the squid-users