Re: [squid-users] can't explain 403 denied for authenticated
On 7/06/24 07:08, Kevin wrote: > >> acl trellix_phone_cloud dstdomain amcore-ens.rest.gti.trellix.com >> http_access deny trellix_phone_cloud >> external_acl_type host_based_filter children-max=15 ttl=0 0X0P+0CL >> acl HostBasedRules external host_based_filter >> http_access allow HostBasedRules >> auth_param digest program /usr/lib/squid/digest_file_auth -c /etc/squid/passwd >> auth_param digest realm squid >> auth_param digest children 2 >> auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/basic_passwd >> auth_param basic children 2 >> auth_param basic realm squidb >> auth_param basic credentialsttl 2 hours > >> acl auth_users proxy_auth REQUIRED >> external_acl_type custom_acl_db children-max=15 ttl=0 0X0P+0CL >> acl CustomAclDB external custom_acl_db >> http_access allow CustomAclDB > > >Hmm, this use of combined authentication+authorization is a bit tricky >with two layers of asynchronous helper lookups going on. That alone >might be what is going on with the weird 403's. > > >A better sequence would be: > ># ensure login is performed >http_access deny !auth_users > ># check the access permissions for whichever user logged in >http_access allow CustomAclDB The first call the the external_acl is to process unauthenticated requests. Is the suggestion to replace acl auth_users proxy_auth REQUIRED with http_access deny !auth_users before the second external_acl (for authenticated requests)? No. It is to ensure that "missing credentials" are treated differently than "bad credentials". Specifically that any auth challenge response is never able to be given "allow" permission. HTH Amos ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] can't explain 403 denied for authenticated
You can also add this to lock down the proxy after hours so nothing is used much like locking a door, whatever is inside is going to keep working ie connections already established however all new connections will be blocked. I love this one acl block_hours time 00:30-05:00 ssl_bump terminate all block_hours http_access deny all block_hours however this is for use with ssl intercept and root certificates installed however it also works for spliced connections as it comes before everything else the terminate everything line you can also if you want to lock down to specific mac addresses ie small office home network use eui_lookup on Example of use with mac addresses acl splice_only src 192.168.1.8 #Tasha iPhone acl splice_only src 192.168.1.10 #Jon iPhone acl splice_only src 192.168.1.11 #Amazon Fire acl splice_only src 192.168.1.15 #Tasha HP acl splice_only src 192.168.1.16 #iPad acl splice_only_mac arp (unique 48bit hardware address here) acl splice_only_mac arp (unique 48bit hardware address here) acl splice_only_mac arp (unique 48bit hardware address here) acl splice_only_mac arp (unique 48bit hardware address here) acl splice_only_mac arp (unique 48bit hardware address here) acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/pkg/reg.url.nobump" acl NoBumpDNS dstdomain "/usr/local/pkg/dns.nobump" acl markBumped annotate_client bumped=true acl active_use annotate_client active=true acl bump_only src 192.168.1.3 #webtv acl bump_only src 192.168.1.4 #toshiba acl bump_only src 192.168.1.5 #imac acl bump_only src 192.168.1.9 #macbook acl bump_only src 192.168.1.13 #dell acl bump_only_mac arp (unique 48bit hardware address here) acl bump_only_mac arp (unique 48bit hardware address here) acl bump_only_mac arp (unique 48bit hardware address here) acl bump_only_mac arp (unique 48bit hardware address here) acl bump_only_mac arp (unique 48bit hardware address here) ssl_bump peek step1 miss_access deny no_miss active_use ssl_bump splice https_login active_use ssl_bump splice splice_only_mac splice_only active_use (this works as “and logic” except my annotate active use) ssl_bump splice NoBumpDNS active_use ssl_bump splice NoSSLIntercept active_use ssl_bump bump bump_only_mac bump_only active_use acl activated note active_use true ssl_bump terminate !activated acl markedBumped note bumped true url_rewrite_access deny markedBumped > On Jun 6, 2024, at 12:08, Kevin wrote: > > >> uri_whitespace encode > > > >Hmm. Accepting whitespace in URLs is a risky choice. One can never be > >completely sure how third-party agents in the network are handling it > >before the request arrived. > > > >If (big IF) you are able to use "uri_whitespace deny" this proxy would > >be a bit more secure. This is just a suggestion, you know best here. > > I think that was a workaround for a vulnerability. If it was, it may no > longer be needed. > > > > > >> acl trellix_phone_cloud dstdomain amcore-ens.rest.gti.trellix.com > >> http_access deny trellix_phone_cloud > >> external_acl_type host_based_filter children-max=15 ttl=0 0X0P+0CL >> acl > >> HostBasedRules external host_based_filter > >> http_access allow HostBasedRules > >> auth_param digest program /usr/lib/squid/digest_file_auth -c > >> /etc/squid/passwd > >> auth_param digest realm squid > >> auth_param digest children 2 > >> auth_param basic program /usr/lib/squid/basic_ncsa_auth > >> /etc/squid/basic_passwd > >> auth_param basic children 2 > >> auth_param basic realm squidb > >> auth_param basic credentialsttl 2 hours > > > >> acl auth_users proxy_auth REQUIRED > >> external_acl_type custom_acl_db children-max=15 ttl=0 0X0P+0CL >> acl > >> CustomAclDB external custom_acl_db > >> http_access allow CustomAclDB > > > > > >Hmm, this use of combined authentication+authorization is a bit tricky > >with two layers of asynchronous helper lookups going on. That alone > >might be what is going on with the weird 403's. > > > > > >A better sequence would be: > > > ># ensure login is performed > >http_access deny !auth_users > > > ># check the access permissions for whichever user logged in > >http_access allow CustomAclDB > > > The first call the the external_acl is to process unauthenticated requests. > Is the suggestion to replace > > acl auth_users proxy_auth REQUIRED > > with > > http_access deny !auth_users > > before the second external_acl (for authenticated requests)? > > > > > Thanks again, very much > > > Kevin > > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > https://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] can't explain 403 denied for authenticated
>> uri_whitespace encode > >Hmm. Accepting whitespace in URLs is a risky choice. One can never be >completely sure how third-party agents in the network are handling it >before the request arrived. > >If (big IF) you are able to use "uri_whitespace deny" this proxy would >be a bit more secure. This is just a suggestion, you know best here. I think that was a workaround for a vulnerability. If it was, it may no longer be needed. > >> acl trellix_phone_cloud dstdomain amcore-ens.rest.gti.trellix.com >> http_access deny trellix_phone_cloud >> external_acl_type host_based_filter children-max=15 ttl=0 0X0P+0CL >> acl >> HostBasedRules external host_based_filter >> http_access allow HostBasedRules >> auth_param digest program /usr/lib/squid/digest_file_auth -c >> /etc/squid/passwd >> auth_param digest realm squid >> auth_param digest children 2 >> auth_param basic program /usr/lib/squid/basic_ncsa_auth >> /etc/squid/basic_passwd >> auth_param basic children 2 >> auth_param basic realm squidb >> auth_param basic credentialsttl 2 hours > >> acl auth_users proxy_auth REQUIRED >> external_acl_type custom_acl_db children-max=15 ttl=0 0X0P+0CL >> acl >> CustomAclDB external custom_acl_db >> http_access allow CustomAclDB > > >Hmm, this use of combined authentication+authorization is a bit tricky >with two layers of asynchronous helper lookups going on. That alone >might be what is going on with the weird 403's. > > >A better sequence would be: > ># ensure login is performed >http_access deny !auth_users > ># check the access permissions for whichever user logged in >http_access allow CustomAclDB The first call the the external_acl is to process unauthenticated requests. Is the suggestion to replace acl auth_users proxy_auth REQUIRED with http_access deny !auth_users before the second external_acl (for authenticated requests)? Thanks again, very much Kevin ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] can't explain 403 denied for authenticated
Free config audit inline ... On 6/06/24 05:24, Kevin wrote: Understood. Here it is: acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl windows_net src 172.18.114.0/24 acl sample_host src 172.18.115.1/32 acl rsync port 873 You can remove the above line. This "rsync" ACL is unused and the port is added directly to the SSL_Ports and Safe_ports. acl SSL_ports port 443 acl SSL_ports port 873 #873 is rsync acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl Safe_ports port 873 acl CONNECT method CONNECT You can remove the above line. "CONNECT" is a built-in ACL. acl PURGE method PURGE Your proxy is configured with "cache deny all" preventing anything being stored. As such you can improve performance somewhat by removing the "acl PURGE" and all config below that uses it. acl localhost src 127.0.0.1 You can remove the above line. "localhost" is a built-in ACL. http_access allow PURGE localhost http_access deny PURGE acl URN proto URN http_access deny URN http_access deny manager acl API_FIREFOX dstdomain api.profiler.firefox.com http_access deny API_FIREFOX acl ff_browser browser ^Mozilla/5\.0 acl rma_ua browser ^RMA/1\.0.*compatible;.RealMedia uri_whitespace encode Hmm. Accepting whitespace in URLs is a risky choice. One can never be completely sure how third-party agents in the network are handling it before the request arrived. If (big IF) you are able to use "uri_whitespace deny" this proxy would be a bit more secure. This is just a suggestion, you know best here. acl trellix_phone_cloud dstdomain amcore-ens.rest.gti.trellix.com http_access deny trellix_phone_cloud external_acl_type host_based_filter children-max=15 ttl=0 %ACL %DATA %SRC %>rd %>rP /PATH/TO/FILTER/SCRIPT.py acl HostBasedRules external host_based_filter http_access allow HostBasedRules auth_param digest program /usr/lib/squid/digest_file_auth -c /etc/squid/passwd auth_param digest realm squid auth_param digest children 2 auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/basic_passwd auth_param basic children 2 auth_param basic realm squidb auth_param basic credentialsttl 2 hours acl auth_users proxy_auth REQUIRED external_acl_type custom_acl_db children-max=15 ttl=0 %ACL %DATA %ul %SRC %>rd %>rP %credentials /PATH/TO/FILTER/SCRIPT.py acl CustomAclDB external custom_acl_db http_access allow CustomAclDB Hmm, this use of combined authentication+authorization is a bit tricky with two layers of asynchronous helper lookups going on. That alone might be what is going on with the weird 403's. A better sequence would be: # ensure login is performed http_access deny !auth_users # check the access permissions for whichever user logged in http_access allow CustomAclDB acl CRLs url_regex "/etc/squid/conf.d/CRL_urls.txt" http_access allow CRLs deny_info 303:https://abc.def.com/ FYI; deny_info is a way to customize what happens when the "deny" action is performed an a specific ACL match. The above deny_info line does nothing unless you name which ACL(s) it is to become the action for and also those ACLs are used in a "deny" rule. For example: acl redirect_HTTPS url_regex ^http://example\.com deny_info 303:https://example.com%rp redirect_HTTPS http_access deny redirect_HTTPS http_access deny all So ... none of the http_access lines below here are doing anything. acl apache rep_header Server ^Apache icp_access allow localnet icp_access deny all These lines... http_access deny !Safe_ports http_access deny CONNECT !SSL_ports .. to here are supposed to protect your proxy against some nasty DDoS type attacks. They need to be first out of all your http_access lines in order to do that efficiently. The http_access below are optional from our default squid.conf setup. Since your install does not appear to need them they can just be removed. http_access allow localhost manager http_access deny manager http_access allow localhost http_port 3128 coredump_dir /var/cache/squid refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 logformat squid %ts.%03tu %6tr %>a %Ss/%>Hs %a %Ss/%>Hs %h] [%a %ui %un
Re: [squid-users] can't explain 403 denied for authenticated
I appreciate very much your looking at my question. >Date: Thu, 30 May 2024 22:15:27 +1200 >From: Amos Jeffries >To: squid-users@lists.squid-cache.org >Subject: Re: [squid-users] can't explain 403 denied for authenticated > user >Message-ID: <96746157-da51-47db-8d52-d65239f27...@treenet.co.nz> >Content-Type: text/plain; charset=UTF-8; format=flowed > >On 25/05/24 07:28, Kevin wrote: >> Hi, >> >> We have 2 external ACLs that take a request's data (IP, authenticated >> username, URL, user-agent, etc) and uses that information to determine >> whether a user or host should be permitted to access that URL.?? It >> almost always works well, but we have a recurring occasional issue that >> I can't figure out. >> >> When it occurs, it's always around 4AM.?? This particular request occurs >> often - averages about once a second throughout the day. >> >> What we see is a "403 forbidden" for a (should be) permitted site from >> an authenticated user from the same IP/user and to the same site that >> gets a "202 connection established" every other time. > >Is maybe 4am the time when your auth system refreshes all nonce? > - thus making any currently in-use by the clients invalid until they >re-auth. You might see a mix of 403/401/407 in a bunch at such times. My auth system is just squid with one flat file each for basic and digest authentication (we allow basic only if an application doesn't support digest). >Or maybe in a similar style one/some of the clients is broken and fails >to update its nonce before it expires at 4am? The client is a Java-based application. I can find out more from the team that wrote it. > - looking at which client agent and IP were getting the 403 and/or the >nonce which received 403 will give you hints about this possibility. Oh: it's only this one application from this one particular host. > >Or your network router(s) do garbage collection and terminate >long-running connections to free up TCP resources? > - thus forcing a lot of client re-connects at 4am, which may: > a) overload the auth system/helper, or > b) break a transaction that included nonce update for clients - >resulting in their next request being invalid nonce. I'm not aware of a 4AM connection-terminating task but will confirm. As mentioned (in answer to a), the auth system is just squid. Re: b - I hadn't thought of that. > > >Or maybe you have log processing software that does "squid -k restart" >instead of the proper "squid -k rotate" to get access to the log files? I hadn't checked that! But logrotate runs at 00:00 and the rotate script does use "squid -k rotate". >Or maybe your auth system has a limit on how large nonce-count can become? > - I notice that the working request has 0x2F uses and the forbidden >has 0x35 (suspiciously close to 50 in decimal) I don't know what that is. I didn't find a lot of helpful detail on squid's digest auth implementation. > >> >> The difference I see in the logs:? though all the digest auth info looks >> okay, the %un field in the log for the usual (successful) request is the >> authenticated username, while in the failed request, it's "-".?? So >> though there hasn't been an authentication error or "authentication >> required" in the log - and the username is in the authentication details >> in the log entry -? it seems like squid isn't recognizing that username >> as %un. > > >Be aware that a properly behaving client will *not* send credentials >until they are requested, after which it should *always* send >credentials on that same connection (even if they are not requested >explicitly). >That means some requests on a multiplex/pipeline/keep-alive connection >MAY arrive with credentials and be accepted(2xx)/denied(403) without >authentication having occured. Entirely due to your *_access directives >sequence. In these cases the log will show auth headers but no value for >%un and/or %ul. > > >> >> My squid.conf first tests a request to see if an unauthenticated request >> from a particular host is permitted.? That external ACL doesn't take a >> username as an argument.?? If that external ACL passes, the request is >> allowed. >> > >Please *show* the config lines rather than describing what you *think* >they do. Their exact ordering matters *a lot*. > Obfuscation of sensitive details is okay/expected so long as you makes >it easy for us to tell that value A and value B are different. > >FWIW; if your config file is *actually* containing only what you >described it is mis
Re: [squid-users] can't explain 403 denied for authenticated user
On 25/05/24 07:28, Kevin wrote: Hi, We have 2 external ACLs that take a request's data (IP, authenticated username, URL, user-agent, etc) and uses that information to determine whether a user or host should be permitted to access that URL. It almost always works well, but we have a recurring occasional issue that I can't figure out. When it occurs, it's always around 4AM. This particular request occurs often - averages about once a second throughout the day. What we see is a "403 forbidden" for a (should be) permitted site from an authenticated user from the same IP/user and to the same site that gets a "202 connection established" every other time. Is maybe 4am the time when your auth system refreshes all nonce? - thus making any currently in-use by the clients invalid until they re-auth. You might see a mix of 403/401/407 in a bunch at such times. Or maybe in a similar style one/some of the clients is broken and fails to update its nonce before it expires at 4am? - looking at which client agent and IP were getting the 403 and/or the nonce which received 403 will give you hints about this possibility. Or your network router(s) do garbage collection and terminate long-running connections to free up TCP resources? - thus forcing a lot of client re-connects at 4am, which may: a) overload the auth system/helper, or b) break a transaction that included nonce update for clients - resulting in their next request being invalid nonce. Or maybe you have log processing software that does "squid -k restart" instead of the proper "squid -k rotate" to get access to the log files? Or maybe your auth system has a limit on how large nonce-count can become? - I notice that the working request has 0x2F uses and the forbidden has 0x35 (suspiciously close to 50 in decimal) The difference I see in the logs: though all the digest auth info looks okay, the %un field in the log for the usual (successful) request is the authenticated username, while in the failed request, it's "-". So though there hasn't been an authentication error or "authentication required" in the log - and the username is in the authentication details in the log entry - it seems like squid isn't recognizing that username as %un. Be aware that a properly behaving client will *not* send credentials until they are requested, after which it should *always* send credentials on that same connection (even if they are not requested explicitly). That means some requests on a multiplex/pipeline/keep-alive connection MAY arrive with credentials and be accepted(2xx)/denied(403) without authentication having occured. Entirely due to your *_access directives sequence. In these cases the log will show auth headers but no value for %un and/or %ul. My squid.conf first tests a request to see if an unauthenticated request from a particular host is permitted. That external ACL doesn't take a username as an argument. If that external ACL passes, the request is allowed. Please *show* the config lines rather than describing what you *think* they do. Their exact ordering matters *a lot*. Obfuscation of sensitive details is okay/expected so long as you makes it easy for us to tell that value A and value B are different. FWIW; if your config file is *actually* containing only what you described it is missing a number of things necessary to have a safe and secure proxy. A look at your full config (without comments or empty lines) will help us point out any unnoticed issues for you to consider fixing. The next line in squid.conf is acl auth_users proxy_auth REQUIRED FYI the above just means that Squid is using authentication. It says nothing about when the authentication will be (or not be) performed. ... and after that, the external ACL that takes the username as well as the other info. HTH Amos ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
[squid-users] can't explain 403 denied for authenticated user
Hi, We have 2 external ACLs that take a request's data (IP, authenticated username, URL, user-agent, etc) and uses that information to determine whether a user or host should be permitted to access that URL. It almost always works well, but we have a recurring occasional issue that I can't figure out. When it occurs, it's always around 4AM. This particular request occurs often - averages about once a second throughout the day. What we see is a "403 forbidden" for a (should be) permitted site from an authenticated user from the same IP/user and to the same site that gets a "202 connection established" every other time. The difference I see in the logs: though all the digest auth info looks okay, the %un field in the log for the usual (successful) request is the authenticated username, while in the failed request, it's "-". So though there hasn't been an authentication error or "authentication required" in the log - and the username is in the authentication details in the log entry - it seems like squid isn't recognizing that username as %un. My squid.conf first tests a request to see if an unauthenticated request from a particular host is permitted. That external ACL doesn't take a username as an argument. If that external ACL passes, the request is allowed. The next line in squid.conf is acl auth_users proxy_auth REQUIRED ... and after that, the external ACL that takes the username as well as the other info. The filter has its own log. For most authenticated requests, we see four entries in that log for each of this particular request: HostBasedRequest HostBasedResponse UserBasedRequest UserBasedResponse When the issue occurs, we see a blip in the pattern when looking at only this particular request, like: HostBasedRequest HostBasedRespons HostBasedRequest HostBasedResponse UserBasedRequest UserBasedResponse so it looks like the requests that experience the issue don't get past that "acl auth_users proxy_auth REQUIRED" directive. One more clue: The last morning the issue occurred, we saw 8 instances of "403 forbidden" responses (out of roughly 5800 that hour). When I looked at the log entry for one of them (included below) and looked for other instances of the cnonce in the digest auth info, I saw that cnonce in five of the eight log entries showing the issue. Any ideas or suggestions? Here are two logs: one illustrating the issue and the other showing how a typical successful request is logged. thanks! 12.34.56.78 - - [20/May/2024:04:00:00 -0400] "CONNECT abc.defg.net:443 HTTP/1.1" 403 4276 "-" "Java/21.0.1" TCP_DENIED:HIER_NONE [User-Agent: Java/21.0.1\r\nAccept: */*\r\nProxy-Connection: keep-alive\r\nProxy-Authorization: Digest username="service_uname", realm="squid", nonce="eca7c1c8831a2fc2b0afb3ee95862950", nc=0035, uri="abc.defg.net:443", response="88f2110f926ba56c3b1a84a1321a051c", algorithm=MD5, cnonce="BHGEEDNBMEPIIMIDLABNJHJNAIEHLKPGGEDFCLHG", qop=auth\r\nHost: abc.defg.net:443\r\n] [HTTP/1.1 403 Forbidden\r\nServer: squid/5.7\r\nMime-Version: 1.0\r\nDate: Mon, 20 May 2024 08:00:00 GMT\r\nContent-Type: text/html;charset=utf-8\r\nContent-Length: 3884\r\nX-Squid-Error: ERR_ACCESS_DENIED 0\r\nVary: Accept-Language\r\nContent-Language: en\r\nX-Cache: MISS from proxy.acme.com\r\nX-Cache-Lookup: NONE from proxy.acme.com:3128\r\nVia: 1.1 proxy.acme.com (squid/5.7)\r\nConnection: keep-alive\r\n\r\n] 12.34.56.78 - service_uname [20/May/2024:10:50:10 -0400] "CONNECT abc.defg.net:443 HTTP/1.1" 200 2939 "-" "Java/21.0.1" TCP_TUNNEL:HIER_DIRECT [User-Agent: Java/21.0.1\r\nAccept: */*\r\nProxy-Connection: keep-alive\r\nProxy-Authorization: Digest username="service_uname", realm="squid", nonce="3e30376ba9c74cb016b3d8cfe1bf8a81", nc=002f, uri="abc.defg.net:443", response="f8f720d4e2bb9324e1a90bcfafecd1c5", algorithm=MD5, cnonce="KDJPEGFBCHFLMCJMAPEBMEGJNKOHOBEDOAEINPKL", qop=auth\r\nHost: abc.defg.net:443\r\n] [HTTP/1.1 200 Connection established\r\n\r\n] ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
