[squid-users] Squid configuration sanity check

Mon May 7 16:56:57 UTC 2018

Hi Amos,

On Mon, May 7, 2018 at 7:30 PM, Amos Jeffries <squid3 at treenet.co.nz> 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
> > squid-users at lists.squid-cache.org
> > http://lists.squid-cache.org/listinfo/squid-users
> >
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180507/d85eade3/attachment-0001.html>