Squid configuration sanity check

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

Squid configuration sanity check

Alex K
Hi all,

I wanted to check with your accumulated wisdom the following squid configuration.

The config is working both for splice or bump (by commenting/uncommenting the respective line) using TPROXY. It is a config ported form an old installation of squid 3.1 for the new 3.5 and although I did some cleanup I am wondering if I am misusing any directive or missing any crucial one for better performance or just for sake of cleanliness.

At the moment for filtering I am using squidGuard and considering to go with ufdbGuard instead as pointed from Amos (thanx for that).
 
To avoid issues with some sites I am considering to use only splicing, although this has some caveats as bumping also does. I could go with a hybrid approach (splice some and bump all) but this sounds that this will cause periodically more administrative overhead to sort out the sites that need splicing.

The config has also some ACLs as an attempt to block media streaming by those seem to not work.

The hardware running the squid is somehow small with 4 GB of RAM, 4 CPU cores and 100 GB SSD in case one wonders.


http_port 192.168.200.1:3128 tproxy
https_port 192.168.200.1:3129 tproxy ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myCA.pem

sslcrtd_program /usr/lib/squid/ssl_crtd -s /usr/local/squid/var/lib/ssl_db -M 4MB
sslcrtd_children 5

shutdown_lifetime 5 seconds

# ACL
#acl ncsa_users proxy_auth REQUIRED
#acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 192.168.200.1/32

acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 21
acl Safe_ports port 443
acl Safe_ports port 10080
acl Safe_ports port 10443
acl SSL method CONNECT
acl CONNECT method CONNECT # multiling http
#acl block_url dstdomain "/etc/squid/block_url.squid"
#acl allow_url dstdomain "/etc/squid/allow_url.squid"
acl ELAN src 192.168.200.0/24

acl QUERY urlpath_regex cgi-bin \?

# SSL
always_direct allow all

# Video Streaming ACLs
acl media rep_mime_type ^.*mms.*
acl media rep_mime_type ^.*ms-hdr.*
acl media rep_mime_type ^.*x-fcs.*
acl media rep_mime_type ^.*x-ms-asf.*
acl media2 urlpath_regex dvrplayer mediastream mms://
acl media2 urlpath_regex \.asf$ \.afx$ \.flv$ \.swf$
acl flashvideo rep_mime_type -i video/flv
acl flashvideo rep_mime_type -i video/x-flv
acl shockwave rep_mime_type -i ^application/x-shockwave-flash$
acl x-type req_mime_type -i ^application/octet-stream$
acl x-type req_mime_type -i application/octet-stream
acl x-type req_mime_type -i ^application/x-mplayer2$
acl x-type req_mime_type -i application/x-mplayer2
acl x-type req_mime_type -i ^application/x-oleobject$
acl x-type req_mime_type -i application/x-oleobject
acl x-type req_mime_type -i application/x-pncmd
acl x-type req_mime_type -i ^video/x-ms-asf$
acl x-type2 rep_mime_type -i ^application/octet-stream$
acl x-type2 rep_mime_type -i application/octet-stream
acl x-type2 rep_mime_type -i ^application/x-mplayer2$
acl x-type2 rep_mime_type -i application/x-mplayer2
acl x-type2 rep_mime_type -i ^application/x-oleobject$
acl x-type2 rep_mime_type -i application/x-oleobject
acl x-type2 rep_mime_type -i application/x-pncmd
acl x-type2 rep_mime_type -i ^video/x-ms-asf$

# Block Media Streaming
http_reply_access deny flashvideo
http_reply_access deny shockwave
http_reply_access deny media
http_reply_access deny media2
http_reply_access deny x-type
http_reply_access deny x-type2

#
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
#http_access deny block_url
#http_access allow allow_url
http_access allow LAN
http_access allow ELAN

http_access allow localhost
#http_access allow ncsa_users
http_reply_access allow all

deny_info ERR_CUSTOM LAN ELAN media media2 flashvideo shockwave x-type x-type2
error_directory /usr/share/squid-langpack/en

#icp_access allow all

# Logging
logfile_daemon /usr/lib/squid/log_db_daemon
access_log daemon:/127.0.0.1/squid_log/access_log/squid/squid squid
icap_log stdio:/var/log/squid/icap.log squid
cache_store_log stdio:/var/log/squid/store.log

# DNS
dns_nameservers 127.0.0.1
positive_dns_ttl 8 hours
negative_dns_ttl 30 seconds
ipcache_size 2048
ipcache_low 95
ipcache_high 97
fqdncache_size 2048

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid
cache_dir ufs /var/spool/squid 10240 16 256
minimum_object_size 0 KB
maximum_object_size 30 MB
maximum_object_size_in_memory 1024 KB

# HTTPS filtering
acl step1 at_step SslBump1

ssl_bump peek step1
ssl_bump splice all
#ssl_bump bump all

# SquidGuard
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 5



Your input is highly appreciated.

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 configuration sanity check

Amos Jeffries
Administrator
On 08/05/18 00:24, Alex K wrote:

> Hi all,
>
> I wanted to check with your accumulated wisdom the following squid
> configuration.
>
> The config is working both for splice or bump (by
> commenting/uncommenting the respective line) using TPROXY. It is a
> config ported form an old installation of squid 3.1 for the new 3.5 and
> although I did some cleanup I am wondering if I am misusing any
> directive or missing any crucial one for better performance or just for
> sake of cleanliness.
>
> At the moment for filtering I am using squidGuard and considering to go
> with ufdbGuard instead as pointed from Amos (thanx for that).
>  
> To avoid issues with some sites I am considering to use only splicing,
> although this has some caveats as bumping also does. I could go with a
> hybrid approach (splice some and bump all) but this sounds that this
> will cause periodically more administrative overhead to sort out the
> sites that need splicing.
>
> The config has also some ACLs as an attempt to block media streaming by
> those seem to not work.

The ACL checking for mms:// URL will not work because MMS protocol is
not HTTP. Any client using that protocol will not be going through
Squid. So quite likely none of the other checks will work for its
non-proxied traffic either.

"working" can also depend on what you are looking at. Your rules are
only blocking *reply* access. Which means only that the client does not
get the response delivered. It still gets fetched from the server -
maybe in full. So checking your logs etc can still show things arriving
and lots of bandwidth usage.

The urlpath and req_mime_type can be checked in http_access instead to
block those requests from ever happening. That MAY work better, but no
guarantees.



>
> The hardware running the squid is somehow small with 4 GB of RAM, 4 CPU
> cores and 100 GB SSD in case one wonders.
>
>
> http_port 192.168.200.1:3128 tproxy
> https_port 192.168.200.1:3129 tproxy \
>   ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB \
>   cert=/etc/squid/ssl_cert/myCA.pem
>
> sslcrtd_program /usr/lib/squid/ssl_crtd -s
> /usr/local/squid/var/lib/ssl_db -M 4MB
> sslcrtd_children 5
>
> shutdown_lifetime 5 seconds
>
> # ACL
> #acl ncsa_users proxy_auth REQUIRED
> #acl all src 0.0.0.0/0.0.0.0
> acl manager proto cache_object

'manager' ACL is now built-in, and has a different type signature. The
above needs to be removed. Same with 'all'. It is not a good idea to
leave them even commented out because the old definitions are no longer
true.


> acl localhost src 192.168.200.1/32

192.168.200.1 is assigned to your lo interface?

>
> acl SSL_ports port 443
> acl Safe_ports port 80
> acl Safe_ports port 21
> acl Safe_ports port 443
> acl Safe_ports port 10080
> acl Safe_ports port 10443
> acl SSL method CONNECT

The above can be quite deceptive,

> acl CONNECT method CONNECT # multiling http
> #acl block_url dstdomain "/etc/squid/block_url.squid"
> #acl allow_url dstdomain "/etc/squid/allow_url.squid"
> acl ELAN src 192.168.200.0/24
>
> acl QUERY urlpath_regex cgi-bin \?

The QUERY is not being used. It is also no longer necessary so can be
removed.

>
> # SSL
> always_direct allow all

That should not be. You do not have any cache_peer configured.

>
> # Video Streaming ACLs
> acl media rep_mime_type ^.*mms.*
> acl media rep_mime_type ^.*ms-hdr.*
> acl media rep_mime_type ^.*x-fcs.*
> acl media rep_mime_type ^.*x-ms-asf.*
> acl media2 urlpath_regex dvrplayer mediastream mms://
> acl media2 urlpath_regex \.asf$ \.afx$ \.flv$ \.swf$
> acl flashvideo rep_mime_type -i video/flv
> acl flashvideo rep_mime_type -i video/x-flv
> acl shockwave rep_mime_type -i ^application/x-shockwave-flash$

> acl x-type req_mime_type -i ^application/octet-stream$
> acl x-type req_mime_type -i application/octet-stream

All the lines like the two above are duplicates.
The "^foo$" pattern is a sub-set of "foo" pattern.


> acl x-type req_mime_type -i ^application/x-mplayer2$
> acl x-type req_mime_type -i application/x-mplayer2
> acl x-type req_mime_type -i ^application/x-oleobject$
> acl x-type req_mime_type -i application/x-oleobject
> acl x-type req_mime_type -i application/x-pncmd
> acl x-type req_mime_type -i ^video/x-ms-asf$
> acl x-type2 rep_mime_type -i ^application/octet-stream$
> acl x-type2 rep_mime_type -i application/octet-stream
> acl x-type2 rep_mime_type -i ^application/x-mplayer2$
> acl x-type2 rep_mime_type -i application/x-mplayer2
> acl x-type2 rep_mime_type -i ^application/x-oleobject$
> acl x-type2 rep_mime_type -i application/x-oleobject
> acl x-type2 rep_mime_type -i application/x-pncmd
> acl x-type2 rep_mime_type -i ^video/x-ms-asf$
>
> # Block Media Streaming
> http_reply_access deny flashvideo
> http_reply_access deny shockwave
> http_reply_access deny media
> http_reply_access deny media2
> http_reply_access deny x-type
> http_reply_access deny x-type2
>
> #
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports

FYI: current best-practice recommendation is to place the manager access
line down here after the faster port checks.

> #http_access deny block_url
> #http_access allow allow_url
> http_access allow LAN
> http_access allow ELAN
>
> http_access allow localhost
> #http_access allow ncsa_users
> http_reply_access allow all

This http_reply_access line should be up with the others so it does not
fool anyone into thinking its placement here with the http_access lines
has any meaning.

>
> deny_info ERR_CUSTOM LAN ELAN media media2 flashvideo shockwave x-type
> x-type2
> error_directory /usr/share/squid-langpack/en
>
> #icp_access allow all
>
> # Logging
> logfile_daemon /usr/lib/squid/log_db_daemon
> access_log daemon:/127.0.0.1/squid_log/access_log/squid/squid squid
> icap_log stdio:/var/log/squid/icap.log squid
> cache_store_log stdio:/var/log/squid/store.log
>
> # DNS
> dns_nameservers 127.0.0.1
> positive_dns_ttl 8 hours
> negative_dns_ttl 30 seconds
> ipcache_size 2048
> ipcache_low 95
> ipcache_high 97
> fqdncache_size 2048
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
> cache_dir ufs /var/spool/squid 10240 16 256
> minimum_object_size 0 KB
> maximum_object_size 30 MB
> maximum_object_size_in_memory 1024 KB
>
> # HTTPS filtering
> acl step1 at_step SslBump1
>
> ssl_bump peek step1
> ssl_bump splice all
> #ssl_bump bump all
>
> # SquidGuard
> url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
> url_rewrite_children 5
>
>
> Your input is highly appreciated.
>
> Alex
>
>
> _______________________________________________
> 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 configuration sanity check

Alex K
Hi Amos,

On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries <[hidden email]> wrote:
On 08/05/18 00:24, Alex K wrote:
> Hi all,
>
> I wanted to check with your accumulated wisdom the following squid
> configuration.
>
> The config is working both for splice or bump (by
> commenting/uncommenting the respective line) using TPROXY. It is a
> config ported form an old installation of squid 3.1 for the new 3.5 and
> although I did some cleanup I am wondering if I am misusing any
> directive or missing any crucial one for better performance or just for
> sake of cleanliness.
>
> At the moment for filtering I am using squidGuard and considering to go
> with ufdbGuard instead as pointed from Amos (thanx for that).
>  
> To avoid issues with some sites I am considering to use only splicing,
> although this has some caveats as bumping also does. I could go with a
> hybrid approach (splice some and bump all) but this sounds that this
> will cause periodically more administrative overhead to sort out the
> sites that need splicing.
>
> The config has also some ACLs as an attempt to block media streaming by
> those seem to not work.

The ACL checking for mms:// URL will not work because MMS protocol is
not HTTP. Any client using that protocol will not be going through
Squid. So quite likely none of the other checks will work for its
non-proxied traffic either.

"working" can also depend on what you are looking at. Your rules are
only blocking *reply* access. Which means only that the client does not
get the response delivered. It still gets fetched from the server -
maybe in full. So checking your logs etc can still show things arriving
and lots of bandwidth usage.

The urlpath and req_mime_type can be checked in http_access instead to
block those requests from ever happening. That MAY work better, but no
guarantees.



>
> The hardware running the squid is somehow small with 4 GB of RAM, 4 CPU
> cores and 100 GB SSD in case one wonders.
>
>
> http_port 192.168.200.1:3128 tproxy
> https_port 192.168.200.1:3129 tproxy \
>   ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB \
>   cert=/etc/squid/ssl_cert/myCA.pem
>
> sslcrtd_program /usr/lib/squid/ssl_crtd -s
> /usr/local/squid/var/lib/ssl_db -M 4MB
> sslcrtd_children 5
>
> shutdown_lifetime 5 seconds
>
> # ACL
> #acl ncsa_users proxy_auth REQUIRED
> #acl all src 0.0.0.0/0.0.0.0
> acl manager proto cache_object

'manager' ACL is now built-in, and has a different type signature. The
above needs to be removed. Same with 'all'. It is not a good idea to
leave them even commented out because the old definitions are no longer
true.

ok, removed these entries (ncsa_users, all, manager)
 
> acl localhost src 192.168.200.1/32

192.168.200.1 is assigned to your lo interface?
Yes, this is the IP of one of the interfaces of the device at the network where the users use squid to reach Internet. 

>
> acl SSL_ports port 443
> acl Safe_ports port 80
> acl Safe_ports port 21
> acl Safe_ports port 443
> acl Safe_ports port 10080
> acl Safe_ports port 10443
> acl SSL method CONNECT

The above can be quite deceptive,
I removed port 21 as I don't think I am using FTP.
 

> acl CONNECT method CONNECT # multiling http
> #acl block_url dstdomain "/etc/squid/block_url.squid"
> #acl allow_url dstdomain "/etc/squid/allow_url.squid"
> acl ELAN src 192.168.200.0/24
>
> acl QUERY urlpath_regex cgi-bin \?

The QUERY is not being used. It is also no longer necessary so can be
removed.
Removed.

>
> # SSL
> always_direct allow all

That should not be. You do not have any cache_peer configured.

Removed
 
>
> # Video Streaming ACLs
> acl media rep_mime_type ^.*mms.*
> acl media rep_mime_type ^.*ms-hdr.*
> acl media rep_mime_type ^.*x-fcs.*
> acl media rep_mime_type ^.*x-ms-asf.*
> acl media2 urlpath_regex dvrplayer mediastream mms://
> acl media2 urlpath_regex \.asf$ \.afx$ \.flv$ \.swf$
> acl flashvideo rep_mime_type -i video/flv
> acl flashvideo rep_mime_type -i video/x-flv
> acl shockwave rep_mime_type -i ^application/x-shockwave-flash$

> acl x-type req_mime_type -i ^application/octet-stream$
> acl x-type req_mime_type -i application/octet-stream

All the lines like the two above are duplicates.
The "^foo$" pattern is a sub-set of "foo" pattern.

Removed duplicates

> acl x-type req_mime_type -i ^application/x-mplayer2$
> acl x-type req_mime_type -i application/x-mplayer2
> acl x-type req_mime_type -i ^application/x-oleobject$
> acl x-type req_mime_type -i application/x-oleobject
> acl x-type req_mime_type -i application/x-pncmd
> acl x-type req_mime_type -i ^video/x-ms-asf$
> acl x-type2 rep_mime_type -i ^application/octet-stream$
> acl x-type2 rep_mime_type -i application/octet-stream
> acl x-type2 rep_mime_type -i ^application/x-mplayer2$
> acl x-type2 rep_mime_type -i application/x-mplayer2
> acl x-type2 rep_mime_type -i ^application/x-oleobject$
> acl x-type2 rep_mime_type -i application/x-oleobject
> acl x-type2 rep_mime_type -i application/x-pncmd
> acl x-type2 rep_mime_type -i ^video/x-ms-asf$
>
> # Block Media Streaming
> http_reply_access deny flashvideo
> http_reply_access deny shockwave
> http_reply_access deny media
> http_reply_access deny media2
> http_reply_access deny x-type
> http_reply_access deny x-type2
>
> #
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports

FYI: current best-practice recommendation is to place the manager access
line down here after the faster port checks.

Placed the manager line after the  "http_access deny CONNECT !SSL_ports".

> #http_access deny block_url
> #http_access allow allow_url
> http_access allow LAN
> http_access allow ELAN
>
> http_access allow localhost
> #http_access allow ncsa_users
> http_reply_access allow all

This http_reply_access line should be up with the others so it does not
fool anyone into thinking its placement here with the http_access lines
has any meaning.
Moved it at http_reply block

>
> deny_info ERR_CUSTOM LAN ELAN media media2 flashvideo shockwave x-type
> x-type2
> error_directory /usr/share/squid-langpack/en
>
> #icp_access allow all
>
> # Logging
> logfile_daemon /usr/lib/squid/log_db_daemon
> access_log daemon:/127.0.0.1/squid_log/access_log/squid/squid squid
> icap_log stdio:/var/log/squid/icap.log squid
> cache_store_log stdio:/var/log/squid/store.log
>
> # DNS
> dns_nameservers 127.0.0.1
> positive_dns_ttl 8 hours
> negative_dns_ttl 30 seconds
> ipcache_size 2048
> ipcache_low 95
> ipcache_high 97
> fqdncache_size 2048
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
> cache_dir ufs /var/spool/squid 10240 16 256
> minimum_object_size 0 KB
> maximum_object_size 30 MB
> maximum_object_size_in_memory 1024 KB

> # HTTPS filtering
> acl step1 at_step SslBump1
>
> ssl_bump peek step1
> ssl_bump splice all
> #ssl_bump bump all
>
> # SquidGuard
> url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
> url_rewrite_children 5
>
>
> Your input is highly appreciated.
>
> Alex
>
>
> _______________________________________________
> 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 configuration sanity check

Amos Jeffries
Administrator
On 08/05/18 04:56, Alex K wrote:
> Hi Amos,
>
> On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries wrote:
>
>     On 08/05/18 00:24, Alex K wrote:
>     > Hi all,
>     >
...
>     > acl localhost src 192.168.200.1/32 <http://192.168.200.1/32>
>
>     192.168.200.1 is assigned to your lo interface?
>
> Yes, this is the IP of one of the interfaces of the device at the
> network where the users use squid to reach Internet. 
>

No, I mean specifically the interface named "lo" which has ::1 and
127.0.0.0/8 assigned by the system. It has some special security
properties like hardware restriction preventing globally routable IPs
being used as dst-IP of packets even routed through it result in rejections.



>
>     >
>     > acl SSL_ports port 443
>     > acl Safe_ports port 80
>     > acl Safe_ports port 21
>     > acl Safe_ports port 443
>     > acl Safe_ports port 10080
>     > acl Safe_ports port 10443
>     > acl SSL method CONNECT
>
>     The above can be quite deceptive,
>
> I removed port 21 as I don't think I am using FTP.
>  

Sorry, I missed out the last half of that text. I was meaning the "SSL"
ACL definition specifically. CONNECT method is not restricted to SSL
protocol even when all you are doing is intercepting port 443 (think
HTTP/2, WebSockets, QUIC, etc). It would be better to use the provided
CONNECT ACL in place of "SSL" - they are identical in definition and
CONNECT is clearer to see if/when some access control is not as tightly
restricted as "SSL" would make it seem.


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

Re: Squid configuration sanity check

Alex K
Hi Amos,

On Tue, May 8, 2018 at 8:55 AM, Amos Jeffries <[hidden email]> wrote:
On 08/05/18 04:56, Alex K wrote:
> Hi Amos,
>
> On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries wrote:
>
>     On 08/05/18 00:24, Alex K wrote:
>     > Hi all,
>     >
...
>     > acl localhost src 192.168.200.1/32 <http://192.168.200.1/32>
>
>     192.168.200.1 is assigned to your lo interface?
>
> Yes, this is the IP of one of the interfaces of the device at the
> network where the users use squid to reach Internet. 
>

No, I mean specifically the interface named "lo" which has ::1 and
127.0.0.0/8 assigned by the system. It has some special security
properties like hardware restriction preventing globally routable IPs
being used as dst-IP of packets even routed through it result in rejections.
I have not assigned 192.168.200.1 at lo. It is assigned to an interface (eth3 for example). localhost is here misleading. it could say "proxy"




>
>     >
>     > acl SSL_ports port 443
>     > acl Safe_ports port 80
>     > acl Safe_ports port 21
>     > acl Safe_ports port 443
>     > acl Safe_ports port 10080
>     > acl Safe_ports port 10443
>     > acl SSL method CONNECT
>
>     The above can be quite deceptive,
>
> I removed port 21 as I don't think I am using FTP.
>  

Sorry, I missed out the last half of that text. I was meaning the "SSL"
ACL definition specifically. CONNECT method is not restricted to SSL
protocol even when all you are doing is intercepting port 443 (think
HTTP/2, WebSockets, QUIC, etc). It would be better to use the provided
CONNECT ACL in place of "SSL" - they are identical in definition and
CONNECT is clearer to see if/when some access control is not as tightly
restricted as "SSL" would make it seem. 
You mean remove  "acl CONNECT method CONNECT" and leave only "acl CONNECT method CONNECT" ?


Cheers
Amos


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

Re: Squid configuration sanity check

Alex K
Correction:

On Tue, May 8, 2018 at 1:35 PM, Alex K <[hidden email]> wrote:
Hi Amos,

On Tue, May 8, 2018 at 8:55 AM, Amos Jeffries <[hidden email]> wrote:
On 08/05/18 04:56, Alex K wrote:
> Hi Amos,
>
> On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries wrote:
>
>     On 08/05/18 00:24, Alex K wrote:
>     > Hi all,
>     >
...
>     > acl localhost src 192.168.200.1/32 <http://192.168.200.1/32>
>
>     192.168.200.1 is assigned to your lo interface?
>
> Yes, this is the IP of one of the interfaces of the device at the
> network where the users use squid to reach Internet. 
>

No, I mean specifically the interface named "lo" which has ::1 and
127.0.0.0/8 assigned by the system. It has some special security
properties like hardware restriction preventing globally routable IPs
being used as dst-IP of packets even routed through it result in rejections.
I have not assigned 192.168.200.1 at lo. It is assigned to an interface (eth3 for example). localhost is here misleading. it could say "proxy"




>
>     >
>     > acl SSL_ports port 443
>     > acl Safe_ports port 80
>     > acl Safe_ports port 21
>     > acl Safe_ports port 443
>     > acl Safe_ports port 10080
>     > acl Safe_ports port 10443
>     > acl SSL method CONNECT
>
>     The above can be quite deceptive,
>
> I removed port 21 as I don't think I am using FTP.
>  

Sorry, I missed out the last half of that text. I was meaning the "SSL"
ACL definition specifically. CONNECT method is not restricted to SSL
protocol even when all you are doing is intercepting port 443 (think
HTTP/2, WebSockets, QUIC, etc). It would be better to use the provided
CONNECT ACL in place of "SSL" - they are identical in definition and
CONNECT is clearer to see if/when some access control is not as tightly
restricted as "SSL" would make it seem. 
You mean remove  "acl SSL method CONNECT" and leave only "acl CONNECT method CONNECT" ?


Cheers
Amos



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

Re: Squid configuration sanity check

Amos Jeffries
Administrator
On 08/05/18 22:36, Alex K wrote:

> Correction:
>
> On Tue, May 8, 2018 at 1:35 PM, Alex K wrote:
>
>     Hi Amos,
>
>     On Tue, May 8, 2018 at 8:55 AM, Amos Jeffries wrote:
>
>         On 08/05/18 04:56, Alex K wrote:
>         > Hi Amos,
>         >
>         > On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries wrote:
>         >
>         >     On 08/05/18 00:24, Alex K wrote:
>         >     > Hi all,
>         >     >
>         ...
>         >     > acl localhost src 192.168.200.1/32
>         >
>         >     192.168.200.1 is assigned to your lo interface?
>         >
>         > Yes, this is the IP of one of the interfaces of the device at the
>         > network where the users use squid to reach Internet. 
>         >
>
>         No, I mean specifically the interface named "lo" which has ::1 and
>         127.0.0.0/8 assigned by the system. It has
>         some special security
>         properties like hardware restriction preventing globally
>         routable IPs
>         being used as dst-IP of packets even routed through it result in
>         rejections.
>
>     I have not assigned 192.168.200.1 at lo. It is assigned to an
>     interface (eth3 for example). localhost is here misleading. it could
>     say "proxy"

Yes, it should be different. "localhost" ACL is used for some defaults.
What you are doing here is adding 192.168.200.1 to the ::! etc
definition of the predefined localhost ACL.


>
>         >
>         >     >
>         >     > acl SSL_ports port 443
>         >     > acl Safe_ports port 80
>         >     > acl Safe_ports port 21
>         >     > acl Safe_ports port 443
>         >     > acl Safe_ports port 10080
>         >     > acl Safe_ports port 10443
>         >     > acl SSL method CONNECT
>         >
>         >     The above can be quite deceptive,
>         >
>         > I removed port 21 as I don't think I am using FTP.
>         >  
>
>         Sorry, I missed out the last half of that text. I was meaning
>         the "SSL"
>         ACL definition specifically. CONNECT method is not restricted to SSL
>         protocol even when all you are doing is intercepting port 443 (think
>         HTTP/2, WebSockets, QUIC, etc). It would be better to use the
>         provided
>         CONNECT ACL in place of "SSL" - they are identical in definition and
>         CONNECT is clearer to see if/when some access control is not as
>         tightly
>         restricted as "SSL" would make it seem. 
>
>     You mean remove  "acl SSL method CONNECT" and leave only "acl
>     CONNECT method CONNECT" ?
>

Yes. Exactly so.

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

Re: Squid configuration sanity check

Alex K
Hi again,

With this config I get:

ERROR: No forward-proxy ports configured.

I am wondering if I could just add a dummy entry:

http_port 3130

to suppress this error.

But not sure how this is useful when reading:

https://wiki.squid-cache.org/KnowledgeBase/NoForwardProxyPorts

Alex

On Tue, May 8, 2018 at 7:49 PM, Amos Jeffries <[hidden email]> wrote:
On 08/05/18 22:36, Alex K wrote:
> Correction:
>
> On Tue, May 8, 2018 at 1:35 PM, Alex K wrote:
>
>     Hi Amos,
>
>     On Tue, May 8, 2018 at 8:55 AM, Amos Jeffries wrote:
>
>         On 08/05/18 04:56, Alex K wrote:
>         > Hi Amos,
>         >
>         > On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries wrote:
>         >
>         >     On 08/05/18 00:24, Alex K wrote:
>         >     > Hi all,
>         >     >
>         ...
>         >     > acl localhost src 192.168.200.1/32
>         >
>         >     192.168.200.1 is assigned to your lo interface?
>         >
>         > Yes, this is the IP of one of the interfaces of the device at the
>         > network where the users use squid to reach Internet. 
>         >
>
>         No, I mean specifically the interface named "lo" which has ::1 and
>         127.0.0.0/8 assigned by the system. It has
>         some special security
>         properties like hardware restriction preventing globally
>         routable IPs
>         being used as dst-IP of packets even routed through it result in
>         rejections.
>
>     I have not assigned 192.168.200.1 at lo. It is assigned to an
>     interface (eth3 for example). localhost is here misleading. it could
>     say "proxy"

Yes, it should be different. "localhost" ACL is used for some defaults.
What you are doing here is adding 192.168.200.1 to the ::! etc
definition of the predefined localhost ACL.


>
>         >
>         >     >
>         >     > acl SSL_ports port 443
>         >     > acl Safe_ports port 80
>         >     > acl Safe_ports port 21
>         >     > acl Safe_ports port 443
>         >     > acl Safe_ports port 10080
>         >     > acl Safe_ports port 10443
>         >     > acl SSL method CONNECT
>         >
>         >     The above can be quite deceptive,
>         >
>         > I removed port 21 as I don't think I am using FTP.
>         >  
>
>         Sorry, I missed out the last half of that text. I was meaning
>         the "SSL"
>         ACL definition specifically. CONNECT method is not restricted to SSL
>         protocol even when all you are doing is intercepting port 443 (think
>         HTTP/2, WebSockets, QUIC, etc). It would be better to use the
>         provided
>         CONNECT ACL in place of "SSL" - they are identical in definition and
>         CONNECT is clearer to see if/when some access control is not as
>         tightly
>         restricted as "SSL" would make it seem. 
>
>     You mean remove  "acl SSL method CONNECT" and leave only "acl
>     CONNECT method CONNECT" ?
>

Yes. Exactly so.

Amos


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

Re: Squid configuration sanity check

Amos Jeffries
Administrator
On 16/05/18 18:17, Alex K wrote:

> Hi again,
>
> With this config I get:
>
> ERROR: No forward-proxy ports configured.
>
> I am wondering if I could just add a dummy entry:
>
> http_port 3130
>
> to suppress this error.
>
> But not sure how this is useful when reading:
>
> https://wiki.squid-cache.org/KnowledgeBase/NoForwardProxyPorts
>

As the wiki page says Squid generates URLs sometimes which require the
client to contact the proxy directly for something(s). That cannot be
done through a port used for TPROXY or NAT interception traffic.

The port 3130 (if you choose that over the well-known 3128 port) should
not be a "dummy" that does nothing. Squid *will* open and listen for
traffic there. Clients will at times be told to fetch URLs from the
Squid machines public hostname at that port.

You can firewall the port off from all access if you really want to.
Just be aware that will add error messages about the proxy port not
being accessible to whatever problem the client is having that required
direct contact with Squid in the first place (usually trying to display
an error page).

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

Re: Squid configuration sanity check

Alex K
Ok, clear.
Thank you Amos.

Alex

On Wed, May 16, 2018 at 3:33 PM, Amos Jeffries <[hidden email]> wrote:
On 16/05/18 18:17, Alex K wrote:
> Hi again,
>
> With this config I get:
>
> ERROR: No forward-proxy ports configured.
>
> I am wondering if I could just add a dummy entry:
>
> http_port 3130
>
> to suppress this error.
>
> But not sure how this is useful when reading:
>
> https://wiki.squid-cache.org/KnowledgeBase/NoForwardProxyPorts
>

As the wiki page says Squid generates URLs sometimes which require the
client to contact the proxy directly for something(s). That cannot be
done through a port used for TPROXY or NAT interception traffic.

The port 3130 (if you choose that over the well-known 3128 port) should
not be a "dummy" that does nothing. Squid *will* open and listen for
traffic there. Clients will at times be told to fetch URLs from the
Squid machines public hostname at that port.

You can firewall the port off from all access if you really want to.
Just be aware that will add error messages about the proxy port not
being accessible to whatever problem the client is having that required
direct contact with Squid in the first place (usually trying to display
an error page).

Amos


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

Re: Squid configuration sanity check

Eliezer Croitoru

And..

If there are objects you don’t want to be served from the proxy directly you can try to edit the templates.

 

Eliezer

 

----

Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]

 

From: squid-users <[hidden email]> On Behalf Of Alex K
Sent: Wednesday, May 16, 2018 21:08
To: Amos Jeffries <[hidden email]>
Cc: [hidden email]
Subject: Re: [squid-users] Squid configuration sanity check

 

Ok, clear.

Thank you Amos.

Alex

 

On Wed, May 16, 2018 at 3:33 PM, Amos Jeffries <[hidden email]> wrote:

On 16/05/18 18:17, Alex K wrote:


> Hi again,
>
> With this config I get:
>
> ERROR: No forward-proxy ports configured.
>
> I am wondering if I could just add a dummy entry:
>
> http_port 3130
>
> to suppress this error.
>
> But not sure how this is useful when reading:
>
> https://wiki.squid-cache.org/KnowledgeBase/NoForwardProxyPorts
>

As the wiki page says Squid generates URLs sometimes which require the
client to contact the proxy directly for something(s). That cannot be
done through a port used for TPROXY or NAT interception traffic.

The port 3130 (if you choose that over the well-known 3128 port) should
not be a "dummy" that does nothing. Squid *will* open and listen for
traffic there. Clients will at times be told to fetch URLs from the
Squid machines public hostname at that port.

You can firewall the port off from all access if you really want to.
Just be aware that will add error messages about the proxy port not
being accessible to whatever problem the client is having that required
direct contact with Squid in the first place (usually trying to display
an error page).

Amos

 


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