ACL matches when it shouldn't

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ACL matches when it shouldn't

Vieri
> 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:

https://domain.org/?something={whatever}&other=(this)

So, if I don't want Squid to complain I process it a little before serving it to it and the above line becomes:

https://domain.org/\?something=\{whatever}&other=\(this)

You mention anchoring them... So now I adjusted the processing and the above becomes:

^https://domain.org/\?something=\{whatever}&other=\(this)$

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:

https://drive.google.com/file/d/1ZUP9eRAqLzMG162xHfYRV9vx_47kWuXs/view?usp=sharing

Squid doesn't complain about syntax errors so I'm assuming the ACL is as expected.

Thanks,

Vieri
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ACL matches when it shouldn't

Amos Jeffries
Administrator
Ah. Think I found it.

Line 9600 in the earlier file contains a URL with un-escaped "||"
sequence. Pipe is a reserved character in regex so needs \-escaping like
'?' '*' '.', '$', '^, '[', ']', '(', ')', '$' and '\' in the original URL.


See the note below though for long-term fix ...


On 30/09/20 11:03 am, Vieri wrote:

>> 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.
>

Not with the built-in ACLs, but an external ACL helper can do any checks
you want it to. I think that would probably be best to use here.



Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users