On 2023-10-26 08:37, magri@xxxxxx wrote:
TL;DR: is there a way to get/log the resolved ip of a denied request?
TLDR: Bugs notwithstanding, use %<a.
We have a rather large ip based malware blacklist (dst acl) and
sometimes a destination is blocked inadvertantly because of a false
positive entry in this list.
This happens most often with CDNs where the ips of a destination change
often and even move between different sites.
Because of this rapid change it's difficult to determine the blocked ip
in hindsight when analyzing access problems and makes it impossible to
correct the blacklist.
For normal requests the resolved and accessed ip is be logged with %<a,
but that doesn't happen when the request is denied.
If a request was denied by a dst ACL based on its successfully resolved
destination IP address but %<a was logged as "-", then it is a Squid bug
that should be fixed IMO. Meanwhile, you can annotate every dst match
and log that annotation. Here is an untested sketch:
acl matchDst1 dst 127.0.0.1
acl markDst1 note matched=127.0.0.1
acl all-of dst1 matchDst1 markDst1
http_access deny dst1
acl matchDst2 dst 127.0.0.2
acl markDst2 note matched=127.0.0.2
acl all-of dst2 matchDst2 markDst2
http_access deny dst2
logformat myFormat ... matched_dst=%note{matched}
access_log ...
The same thing with fewer lines (but with fewer ways to group dst1 and
dst2 with other ACLs):
acl matchDst1 dst 127.0.0.1
acl markDst1 note matched=127.0.0.1
http_access deny matchDst1 markDst1
acl matchDst2 dst 127.0.0.2
acl markDst2 note matched=127.0.0.2
http_access deny matchDst2 markDst2
logformat myFormat ... matched_dst=%note{matched}
access_log ...
For long dst lists, the above approach will require scripting the
generation of the corresponding squid.conf portions or include files, of
course.
If a request was denied by a dst ACL because its destination IP address
could not be resolved, then %<a should be logged as "-". I cannot think
of a way to distinguish this case from other cases where %<a is "-". It
feels like address resolution failures should be available via
%err_detail, but I doubt Squid code populates that information in these
cases. Another problem to fix!
HTH,
Alex.
Is there any way to get the ip logged that was used in the dst-acl aside
from debug logging? Maybe through some annotation mechanism?
Squid version is 6.2, as 6.4 crashes with assertion errors here, too.
thanks,
Martin
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users