Re: AW: [squid-users] AW: any chance to optimize squid3?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 25 Nov 2012 01:45:01 +1300

On 24/11/2012 8:52 p.m., Fuhrmann, Marcel wrote:
> Hello Amos,
>
> I've installed a test squid server. I'm using CentOS 6.3 (2GB Ram, 2 CPU, RAID10 for caching folder). I followed this guides:
> http://serverfault.com/questions/66556/getting-squid-to-authenticate-with-kerberos-and-windows-2008-2003-7-xp
> http://klaubert.wordpress.com/2008/01/09/squid-kerberos-authentication-and-ldap-authorization-in-active-directory/
>
> And now i'm also using kerberos to authenticate to Windows 2008. And the best: It's working :-)
>
> Here my config:
>
> cache_mem 64 MB
> cache_dir aufs /var/spool/squid 8000 256 256
> cache_effective_user squid
> cache_mgr lux.support_at_lux.ag
> cache_replacement_policy heap LFUDA
> maximum_object_size 1000 KB
> maximum_object_size_in_memory 128 KB
> memory_replacement_policy heap GDSF
> error_directory /usr/share/squid/errors/de-de
> dns_nameservers 10.4.1.20
>
> auth_param negotiate program /usr/lib64/squid/squid_kerb_auth
> auth_param negotiate children 10
> auth_param negotiate keep_alive on
>
> acl snmplux snmp_community kj3v45hv345j23
> #acl LAN src 10.4.1.0/24 10.2.1.0/24
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
> acl SSL_ports port 443
> 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 CONNECT method CONNECT
> acl AUTH proxy_auth REQUIRED
>
> snmp_access allow snmplux localhost
> http_access allow AUTH

The above line means authenticated users (any group or username - just
need to be accepted as valid by AD) are allowed unlimited access.

> #http_access allow LAN
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost
> http_access deny all

So localhost is the only source which is protected from making CONNECT
tunnels or requests to your manager interface.

I would move the allow AUTH line down next to the allow localhost line.

> icp_access deny all
> htcp_access deny all
>
> hierarchy_stoplist cgi-bin ?
> access_log /var/log/squid/access.log squid
> cache_log /var/log/squid/cache.log squid
> 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
> icp_port 0
> http_port 3128
> snmp_port 3401
>
> Two questions about it:
>
> How can I grant internet access to a ADS group called "INTERNET". The example in the guide doesn't work for me. If this is working, I will switch all my users to this server and discard my old one. Then I'm able to test, if this config is more efficient.

You need to check for auth, then to check group membership.

Your current form only grants access immeidately for all authenticated
users ("allow AUTH").

To ensure users are authenticated, but not to grant access immediately
use this form of auth test:
   http_access deny !AUTH

Which means reject anyone not authenticated (Squid will use an auth
challenge in that rejection).
You then follow it with another access line sto tell Squid what to do
with the users who *are* authenticated. Such as yoru group check"

   external_acl_type groups ...
   acl groupCheck group INTERNET
   http_access allow groupCheck

>
> Is there any regulation how to arrange a squid config? OK, the rules need a special order to work correct, but what about the rest?

Multi-line options order of those multiple lines is very important in
how they act together. For the single line directives often placement is
less important, it only matters for the directives which depend on
something or something depends on them being set first (eg the
delay_pools count directive needs to be set before configuraing what
those pools are. 'acl' lines need to be set before any access control
which uses them, cache_peer label being defined before cache_peer_access
setup for it, etc, etc)

Amos
Received on Sat Nov 24 2012 - 12:45:17 MST

This archive was generated by hypermail 2.2.0 : Sat Nov 24 2012 - 12:00:04 MST