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 HostBa
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
>> 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 secur
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
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: <9674615
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 recurrin
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 fig
