Squid ACL for bypassing ssl-bump

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

Squid ACL for bypassing ssl-bump

agent_js03
Hi all,

I have thus far used dstdomain acl for bypassing ssl bump on sites that we don't want to decrypt, like banking sites. It seems to work for some sites, but not for others.

I see the following post on this from some years back:
http://www.squid-cache.org/mail-archive/squid-users/201303/0046.html

It seems like people there are recommending use of an IP based approach to doing this. In this case you would need a static list of IP addresses to the sites in question.

I was thinking about this, and it seems to me that if we are using the squid proxy with a dns server, we should be able to check the dns cache for that IP, and find the associated hostname, and then match against that.

Does squid support this kind of a thing? If not, I was going to write an external acl helper that does a query on a DNS cache to see if it matches a particular domain. However, I don't want to reinvent the wheel.

Thanks,
-Justin

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

Re: Squid ACL for bypassing ssl-bump

Alex Rousskov
On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote:

> I have thus far used dstdomain acl for bypassing ssl bump on sites that
> we don't want to decrypt, like banking sites. It seems to work for some
> sites, but not for others.

Yes, many HTTPS transactions do not expose destination domain until it
is too late to decide whether to bump them, and reverse DNS lookups are
often unreliable.


> I was thinking about this, and it seems to me that if we are using the
> squid proxy with a dns server, we should be able to check the dns cache
> for that IP, and find the associated hostname, and then match against that.

When you use dstdomain, Squid will do a (reverse) DNS query for you as
necessary (including DNS cache lookups) unless you specify a -n option
that is documented to disable all such operations.


In many cases, you should be using ssl::server_name instead of dstdomain
or dst ACL, but you may have to use a combination of various ACLs to
cover all the cases you care about.


HTH,

Alex.

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

squid cache

Majed Zouhairy

Health be Upon you,

i want to cache certain files, let's say exe, msi... above 20MB and
below 300MB, limit the cache directory to 3GB
i have no ssl bump not configured
version 4.14
how to do that?
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid ACL for bypassing ssl-bump

Alex Rousskov
In reply to this post by Alex Rousskov
On 2/26/21 7:35 AM, Justin Michael Schwartzbeck wrote:
>> Yes, many HTTPS transactions do not expose destination domain until it
>> is too late to decide whether to bump them, and reverse DNS lookups are
>> often unreliable.

> I wonder why this would be.

I suspect you assume that a forward DNS lookup (A or AAAA query) answer
is always the "opposite" of a reverse DSN lookup (PTR query) answer.
AFAIK, that is not how DNS is defined. From DNS point of view, each of
those answers is totally independent -- there is no 1:1 or even 1:N
mapping between them; the answers even come from different DNS zones!  A
caching DNS resolver would probably violate the DNS protocol if it uses
a cached A or AAAA record to answer a PTR query. Disclaimer: I am not a
DNS expert.


> From my understanding, when you open a
> browser and browse to www.google.com, the very
> first thing that happens is you do a DNS resolution so that you know
> what IP to send the CONNECT request and subsequent HTTPS records in the
> first place.

What happens depends on the browser and the proxy port:

1. For forward proxies: Some browsers will not do DNS lookups. They will
send a CONNECT request to example.com, allowing Squid to do the DNS
lookup. In this case, Squid dstdomain configured with a host name will
work well.

2. For forward proxies: Some browsers do DNS lookups. They will send a
CONNECT request to one of the returned IP addresses.

3. For interception proxies: All browsers do DNS lookups. They open a
TCP connection to one of the returned IP addresses.

In cases 2 and 3, Squid dstdomain will have to do a reverse DNS lookup
(PTR query). In many cases, that lookup either fails or returns a
different domain name than the domain the browser started with.


HTH,

Alex.


> So we would have the IP already, and the hostname that was
> looked up already in the DNS cache, right? Why wouldn't squid just be
> able to reach in there, match the IP that DNS returned, and then pull
> that hostname out to compare against the ACLs?
>
> On Thu, Feb 25, 2021 at 2:57 PM Alex Rousskov
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote:
>
>     > I have thus far used dstdomain acl for bypassing ssl bump on sites
>     that
>     > we don't want to decrypt, like banking sites. It seems to work for
>     some
>     > sites, but not for others.
>
>     Yes, many HTTPS transactions do not expose destination domain until it
>     is too late to decide whether to bump them, and reverse DNS lookups are
>     often unreliable.
>
>
>     > I was thinking about this, and it seems to me that if we are using the
>     > squid proxy with a dns server, we should be able to check the dns
>     cache
>     > for that IP, and find the associated hostname, and then match
>     against that.
>
>     When you use dstdomain, Squid will do a (reverse) DNS query for you as
>     necessary (including DNS cache lookups) unless you specify a -n option
>     that is documented to disable all such operations.
>
>
>     In many cases, you should be using ssl::server_name instead of dstdomain
>     or dst ACL, but you may have to use a combination of various ACLs to
>     cover all the cases you care about.
>
>
>     HTH,
>
>     Alex.
>

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

Re: Squid ACL for bypassing ssl-bump

agent_js03
Thanks for your answers Alex.

For case 1, I understand that should not be a problem, since squid is the one asking for DNS resolution.
For case 2 and 3, what you are saying is that the browser is requesting the DNS lookup first, correct? Hence the need for a reverse DNS from squid, since squid does not know at that point what domain the IP belongs to. But they still had to query the DNS server, so that entry is in that DNS cache, and it should have the same domain as the lookup that the user entered.

So if I have a local dns (maybe dnsmasq) that both squid and the user use, from what I understand I should be able to use squid's dns_nameservers directive to point to that DNS, and it should return fine since it is stored right there in the cache.

If the user is trying to use a different DNS server other than the local one, then fine, I will just decrypt their traffic as punishment. ūüėĀ

On Fri, Feb 26, 2021 at 9:44 AM Alex Rousskov <[hidden email]> wrote:
On 2/26/21 7:35 AM, Justin Michael Schwartzbeck wrote:
>> Yes, many HTTPS transactions do not expose destination domain until it
>> is too late to decide whether to bump them, and reverse DNS lookups are
>> often unreliable.

> I wonder why this would be.

I suspect you assume that a forward DNS lookup (A or AAAA query) answer
is always the "opposite" of a reverse DSN lookup (PTR query) answer.
AFAIK, that is not how DNS is defined. From DNS point of view, each of
those answers is totally independent -- there is no 1:1 or even 1:N
mapping between them; the answers even come from different DNS zones!  A
caching DNS resolver would probably violate the DNS protocol if it uses
a cached A or AAAA record to answer a PTR query. Disclaimer: I am not a
DNS expert.


> From my understanding, when you open a
> browser and browse to www.google.com, the very
> first thing that happens is you do a DNS resolution so that you know
> what IP to send the CONNECT request and subsequent HTTPS records in the
> first place.

What happens depends on the browser and the proxy port:

1. For forward proxies: Some browsers will not do DNS lookups. They will
send a CONNECT request to example.com, allowing Squid to do the DNS
lookup. In this case, Squid dstdomain configured with a host name will
work well.

2. For forward proxies: Some browsers do DNS lookups. They will send a
CONNECT request to one of the returned IP addresses.

3. For interception proxies: All browsers do DNS lookups. They open a
TCP connection to one of the returned IP addresses.

In cases 2 and 3, Squid dstdomain will have to do a reverse DNS lookup
(PTR query). In many cases, that lookup either fails or returns a
different domain name than the domain the browser started with.


HTH,

Alex.


> So we would have the IP already, and the hostname that was
> looked up already in the DNS cache, right? Why wouldn't squid just be
> able to reach in there, match the IP that DNS returned, and then pull
> that hostname out to compare against the ACLs?
>
> On Thu, Feb 25, 2021 at 2:57 PM Alex Rousskov
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote:
>
>     > I have thus far used dstdomain acl for bypassing ssl bump on sites
>     that
>     > we don't want to decrypt, like banking sites. It seems to work for
>     some
>     > sites, but not for others.
>
>     Yes, many HTTPS transactions do not expose destination domain until it
>     is too late to decide whether to bump them, and reverse DNS lookups are
>     often unreliable.
>
>
>     > I was thinking about this, and it seems to me that if we are using the
>     > squid proxy with a dns server, we should be able to check the dns
>     cache
>     > for that IP, and find the associated hostname, and then match
>     against that.
>
>     When you use dstdomain, Squid will do a (reverse) DNS query for you as
>     necessary (including DNS cache lookups) unless you specify a -n option
>     that is documented to disable all such operations.
>
>
>     In many cases, you should be using ssl::server_name instead of dstdomain
>     or dst ACL, but you may have to use a combination of various ACLs to
>     cover all the cases you care about.
>
>
>     HTH,
>
>     Alex.
>


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

Re: Squid ACL for bypassing ssl-bump

Alex Rousskov
On 2/26/21 12:45 PM, Justin Michael Schwartzbeck wrote:

> For case 2 and 3, what you are saying is that the browser is requesting
> the DNS lookup first, correct?

Correct, but that does not really matter.


> Hence the need for a reverse DNS from
> squid, since squid does not know at that point what domain the IP
> belongs to.

Squid "does not know" because all Squid gets is an IP address (in those
two cases).


> But they still had to query the DNS server, so that entry is
> in that DNS cache, and it should have the same domain as the lookup that
> the user entered.

DNS does not support what feels natural to you. You are thinking of a
name:IP cache entry that can be looked up by IP. That is a natural
model, but it does not match reality. DNS simply does not have an
interface that says "find me a name that maps to IP Y". DNS essentially
has only one interface: "find me what maps to name X". That is it! There
is just no way to ask a DNS server what name in its cache maps to an IP
address.

For reverse DNS lookups, the DNS client constructs an IP-based _name_ in
a special in-addr.arpa DNS zone and uses that name to query the DNS
server. For example, a "reverse" lookup for 127.0.0.1 is really a lookup
for the "1.0.0.127.in-addr.arpa" name. And that lookup follows all the
DNS rules about contacting authoritative servers for the zone, etc.; the
DNS server does not really "know" that what you really want is a cached
domain name for that 127.0.0.1 IP address.


> So if I have a local dns (maybe dnsmasq) that both squid and the user
> use, from what I understand I should be able to use squid's
> dns_nameservers directive to point to that DNS, and it should return
> fine since it is stored right there in the cache.

The IP may be stored, but it cannot be looked up using DNS.

Alex.


> On Fri, Feb 26, 2021 at 9:44 AM Alex Rousskov wrote:
>
>     On 2/26/21 7:35 AM, Justin Michael Schwartzbeck wrote:
>     >> Yes, many HTTPS transactions do not expose destination domain
>     until it
>     >> is too late to decide whether to bump them, and reverse DNS
>     lookups are
>     >> often unreliable.
>
>     > I wonder why this would be.
>
>     I suspect you assume that a forward DNS lookup (A or AAAA query) answer
>     is always the "opposite" of a reverse DSN lookup (PTR query) answer.
>     AFAIK, that is not how DNS is defined. From DNS point of view, each of
>     those answers is totally independent -- there is no 1:1 or even 1:N
>     mapping between them; the answers even come from different DNS zones!¬† A
>     caching DNS resolver would probably violate the DNS protocol if it uses
>     a cached A or AAAA record to answer a PTR query. Disclaimer: I am not a
>     DNS expert.
>
>
>     > From my understanding, when you open a
>     > browser and browse to www.google.com <http://www.google.com>, the very
>     > first thing that happens is you do a DNS resolution so that you know
>     > what IP to send the CONNECT request and subsequent HTTPS records
>     in the
>     > first place.
>
>     What happens depends on the browser and the proxy port:
>
>     1. For forward proxies: Some browsers will not do DNS lookups. They will
>     send a CONNECT request to example.com <http://example.com>, allowing
>     Squid to do the DNS
>     lookup. In this case, Squid dstdomain configured with a host name will
>     work well.
>
>     2. For forward proxies: Some browsers do DNS lookups. They will send a
>     CONNECT request to one of the returned IP addresses.
>
>     3. For interception proxies: All browsers do DNS lookups. They open a
>     TCP connection to one of the returned IP addresses.
>
>     In cases 2 and 3, Squid dstdomain will have to do a reverse DNS lookup
>     (PTR query). In many cases, that lookup either fails or returns a
>     different domain name than the domain the browser started with.
>
>
>     HTH,
>
>     Alex.
>
>
>     > So we would have the IP already, and the hostname that was
>     > looked up already in the DNS cache, right? Why wouldn't squid just be
>     > able to reach in there, match the IP that DNS returned, and then pull
>     > that hostname out to compare against the ACLs?
>     >
>     > On Thu, Feb 25, 2021 at 2:57 PM Alex Rousskov
>     > <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>> wrote:
>     >
>     >¬† ¬† ¬†On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote:
>     >
>     >¬† ¬† ¬†> I have thus far used dstdomain acl for bypassing ssl bump on
>     sites
>     >¬† ¬† ¬†that
>     >¬† ¬† ¬†> we don't want to decrypt, like banking sites. It seems to
>     work for
>     >¬† ¬† ¬†some
>     >¬† ¬† ¬†> sites, but not for others.
>     >
>     >¬† ¬† ¬†Yes, many HTTPS transactions do not expose destination domain
>     until it
>     >¬† ¬† ¬†is too late to decide whether to bump them, and reverse DNS
>     lookups are
>     >¬† ¬† ¬†often unreliable.
>     >
>     >
>     >¬† ¬† ¬†> I was thinking about this, and it seems to me that if we are
>     using the
>     >¬† ¬† ¬†> squid proxy with a dns server, we should be able to check
>     the dns
>     >¬† ¬† ¬†cache
>     >¬† ¬† ¬†> for that IP, and find the associated hostname, and then match
>     >¬† ¬† ¬†against that.
>     >
>     >¬† ¬† ¬†When you use dstdomain, Squid will do a (reverse) DNS query
>     for you as
>     >¬† ¬† ¬†necessary (including DNS cache lookups) unless you specify a
>     -n option
>     >¬† ¬† ¬†that is documented to disable all such operations.
>     >
>     >
>     >¬† ¬† ¬†In many cases, you should be using ssl::server_name instead of
>     dstdomain
>     >¬† ¬† ¬†or dst ACL, but you may have to use a combination of various
>     ACLs to
>     >¬† ¬† ¬†cover all the cases you care about.
>     >
>     >
>     >¬† ¬† ¬†HTH,
>     >
>     >¬† ¬† ¬†Alex.
>     >
>

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

Re: squid cache

Majed Zouhairy
In reply to this post by Majed Zouhairy
i tried this, but neither the https download bandwidth restriction nor
caching seems to be working as expected

acl slower src 10.46.10.78
acl localnet src 10.46.10.0/24

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 8080 # 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 CONNECT method CONNECT
acl blockfiles urlpath_regex -i "/etc/squid/blocks.files.acl"

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
visible_hostname proxy.lk.sk


delay_pools 1
delay_class 1 3
delay_access 1 allow slower
delay_access 1 deny all
delay_parameters 1 51200/51200 -1/-1 51200/25600

http_access allow localnet
http_access allow localhost



# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 8080

# Uncomment and adjust the following to add a disk cache directory.
# Updates: chrome and acrobat
refresh_pattern -i gvt1.com/.*\.(exe|ms[i|u|f|p]|dat|zip|psf) 43200 80%
129600 reload-into-ims
refresh_pattern -i adobe.com/.*\.(exe|ms[i|u|f|p]|dat|zip|psf) 43200 80%
129600 reload-into-ims



range_offset_limit 200 MB
maximum_object_size 200 MB
quick_abort_min -1

# DONT MODIFY THESE LINES
refresh_pattern \^ftp:           1440    20%     10080
refresh_pattern \^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0      0%      0
refresh_pattern .  0      20%     43200

cache_dir ufs /var/cache/squid 3000 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/cache/squid

cache_mem 1024 MB

netdb_filename none

#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

url_rewrite_program /usr/local/ufdbguard/bin/ufdbgclient -m 4 -l
/var/log/squid/
url_rewrite_children 16 startup=8 idle=2 concurrency=4
#debug_options ALL,1 33,2 28,9


any help?


On 2/26/21 10:22 AM, Majed Zouhairy wrote:

>
> Health be Upon you,
>
> i want to cache certain files, let's say exe, msi... above 20MB and
> below 300MB, limit the cache directory to 3GB
> i have no ssl bump not configured
> version 4.14
> how to do that?
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid cache

Alex Rousskov
On 3/1/21 2:07 AM, Majed Zouhairy wrote:
> i tried this, but neither the https download bandwidth restriction nor
> caching seems to be working as expected

Squid cannot cache HTTP responses without bumping HTTPS traffic. This is
a protocol-level limitation, not a bug.

There are known delay pools bugs for not-bumped (i.e. tunneled or
CONNECT) traffic. IIRC, the pools may work for some tunnels, but the
imposed limits may vary significantly from the configured values.


HTH,

Alex.


> acl slower src 10.46.10.78
> acl localnet src 10.46.10.0/24
>
> acl SSL_ports port 443
> acl Safe_ports port 80        # http
> acl Safe_ports port 8080    # 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 CONNECT method CONNECT
> acl blockfiles urlpath_regex -i "/etc/squid/blocks.files.acl"
>
> #
> # Recommended minimum Access Permission configuration:
> #
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
>
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
>
> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager
>
> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> #http_access deny to_localhost
> visible_hostname proxy.lk.sk
>
>
> delay_pools 1
> delay_class 1 3
> delay_access 1 allow slower
> delay_access 1 deny all
> delay_parameters 1 51200/51200 -1/-1 51200/25600
>
> http_access allow localnet
> http_access allow localhost
>
>
>
> # And finally deny all other access to this proxy
> http_access deny all
>
> # Squid normally listens to port 3128
> http_port 8080
>
> # Uncomment and adjust the following to add a disk cache directory.
> # Updates: chrome and acrobat
> refresh_pattern -i gvt1.com/.*\.(exe|ms[i|u|f|p]|dat|zip|psf) 43200 80%
> 129600 reload-into-ims
> refresh_pattern -i adobe.com/.*\.(exe|ms[i|u|f|p]|dat|zip|psf) 43200 80%
> 129600 reload-into-ims
>
>
>
> range_offset_limit 200 MB
> maximum_object_size 200 MB
> quick_abort_min -1
>
> # DONT MODIFY THESE LINES
> refresh_pattern \^ftp:           1440    20%     10080
> refresh_pattern \^gopher:        1440    0%      1440
> refresh_pattern -i (/cgi-bin/|\?) 0      0%      0
> refresh_pattern .           0      20%     43200
>
> cache_dir ufs /var/cache/squid 3000 16 256
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/cache/squid
>
> cache_mem 1024 MB
>
> netdb_filename none
>
> #
> # Add any of your own refresh_pattern entries above these.
> #
> refresh_pattern ^ftp:        1440    20%    10080
> refresh_pattern ^gopher:    1440    0%    1440
> refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
> refresh_pattern .        0    20%    4320
>
> url_rewrite_program /usr/local/ufdbguard/bin/ufdbgclient -m 4 -l
> /var/log/squid/
> url_rewrite_children 16 startup=8 idle=2 concurrency=4
> #debug_options ALL,1 33,2 28,9
>
>
> any help?
>
>
> On 2/26/21 10:22 AM, Majed Zouhairy wrote:
>>
>> Health be Upon you,
>>
>> i want to cache certain files, let's say exe, msi... above 20MB and
>> below 300MB, limit the cache directory to 3GB
>> i have no ssl bump not configured
>> version 4.14
>> how to do that?
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

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

Re: squid cache

Majed Zouhairy
Thanks for, at least, the explanation

On 3/1/21 6:12 PM, Alex Rousskov wrote:

> On 3/1/21 2:07 AM, Majed Zouhairy wrote:
>> i tried this, but neither the https download bandwidth restriction nor
>> caching seems to be working as expected
>
> Squid cannot cache HTTP responses without bumping HTTPS traffic. This is
> a protocol-level limitation, not a bug.
>
> There are known delay pools bugs for not-bumped (i.e. tunneled or
> CONNECT) traffic. IIRC, the pools may work for some tunnels, but the
> imposed limits may vary significantly from the configured values.
>
>
> HTH,
>
> Alex.
>
>
>> acl slower src 10.46.10.78
>> acl localnet src 10.46.10.0/24
>>
>> acl SSL_ports port 443
>> acl Safe_ports port 80        # http
>> acl Safe_ports port 8080    # 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 CONNECT method CONNECT
>> acl blockfiles urlpath_regex -i "/etc/squid/blocks.files.acl"
>>
>> #
>> # Recommended minimum Access Permission configuration:
>> #
>> # Deny requests to certain unsafe ports
>> http_access deny !Safe_ports
>>
>> # Deny CONNECT to other than secure SSL ports
>> http_access deny CONNECT !SSL_ports
>>
>> # Only allow cachemgr access from localhost
>> http_access allow localhost manager
>> http_access deny manager
>>
>> # We strongly recommend the following be uncommented to protect innocent
>> # web applications running on the proxy server who think the only
>> # one who can access services on "localhost" is a local user
>> #http_access deny to_localhost
>> visible_hostname proxy.lk.sk
>>
>>
>> delay_pools 1
>> delay_class 1 3
>> delay_access 1 allow slower
>> delay_access 1 deny all
>> delay_parameters 1 51200/51200 -1/-1 51200/25600
>>
>> http_access allow localnet
>> http_access allow localhost
>>
>>
>>
>> # And finally deny all other access to this proxy
>> http_access deny all
>>
>> # Squid normally listens to port 3128
>> http_port 8080
>>
>> # Uncomment and adjust the following to add a disk cache directory.
>> # Updates: chrome and acrobat
>> refresh_pattern -i gvt1.com/.*\.(exe|ms[i|u|f|p]|dat|zip|psf) 43200 80%
>> 129600 reload-into-ims
>> refresh_pattern -i adobe.com/.*\.(exe|ms[i|u|f|p]|dat|zip|psf) 43200 80%
>> 129600 reload-into-ims
>>
>>
>>
>> range_offset_limit 200 MB
>> maximum_object_size 200 MB
>> quick_abort_min -1
>>
>> # DONT MODIFY THESE LINES
>> refresh_pattern \^ftp:           1440    20%     10080
>> refresh_pattern \^gopher:        1440    0%      1440
>> refresh_pattern -i (/cgi-bin/|\?) 0      0%      0
>> refresh_pattern .           0      20%     43200
>>
>> cache_dir ufs /var/cache/squid 3000 16 256
>>
>> # Leave coredumps in the first cache dir
>> coredump_dir /var/cache/squid
>>
>> cache_mem 1024 MB
>>
>> netdb_filename none
>>
>> #
>> # Add any of your own refresh_pattern entries above these.
>> #
>> refresh_pattern ^ftp:        1440    20%    10080
>> refresh_pattern ^gopher:    1440    0%    1440
>> refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
>> refresh_pattern .        0    20%    4320
>>
>> url_rewrite_program /usr/local/ufdbguard/bin/ufdbgclient -m 4 -l
>> /var/log/squid/
>> url_rewrite_children 16 startup=8 idle=2 concurrency=4
>> #debug_options ALL,1 33,2 28,9
>>
>>
>> any help?
>>
>>
>> On 2/26/21 10:22 AM, Majed Zouhairy wrote:
>>>
>>> Health be Upon you,
>>>
>>> i want to cache certain files, let's say exe, msi... above 20MB and
>>> below 300MB, limit the cache directory to 3GB
>>> i have no ssl bump not configured
>>> version 4.14
>>> how to do that?
>>> _______________________________________________
>>> squid-users mailing list
>>> [hidden email]
>>> http://lists.squid-cache.org/listinfo/squid-users
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users