[squid-users] Doesnt authorize with Squid

[Amos Jeffries]

On 14/12/17 06:03, Edwin Quijada wrote:
> Hi!
> I have installed a debian server with Squid3 to authorize surf for 
> internet. My problem is when I get the screen for credentials I put my 
> rigth credentials and always I get denied.
> 

Is this "screen" a popup box or an actual visual page displayed?
HTTP auth popups should be relatively small and grey outlined, asking 
only for username and password with the proxy Realm string as the title 
or initial text.


> I have used a different helpers for authentication and I did my own using C
> 
> but the authorization is continue
> 

Whether to show the popup is a Browser decision. Properly working you 
should only ever see 0 or 1 of them.

> 
> There is a way to see or debug the autorization process?
> 

The available helpers should all provide a -d command line option for 
testing and troubleshooting. You can configure that in their 'auth_param 
... program' squid.conf line. Squid logs the debug info from helpers to 
cache.log.

Your custom helper is up to you how it gets debugged. Anything it sends 
to stderr is sent to cache.log so you can use that instead of having to 
worry about custom log files yourself.


> 
> It is the squid.conf. The helper just takes the values but always 
> autorize, Always print OK
> 
> 
> #Recommended minimum configuration:
> http_port 3128
> cache_dir ufs /var/spool/squid3 2048 16 256
> maximum_object_size 100 MB
> cache_swap_low 90
> cache_swap_high 95
> 
> #--------------- Reglas de Autorizacion -------------
> auth_param basic program   /root/squid_helper3
> auth_param basic children 20
> auth_param basic casesensitive off
> auth_param basic realm Proxy Test --> Usuario Y Clave
> auth_param basic credentialsttl 5 hours

That credentialsttl setting is how long Squid remembers helper responses 
about credentials. Once credentials are given an OK/ERR result no 
further changes to the auth system for that credential pair (eg, user 
account addition, removal or password changes) are noticed by Squid 
until that TTL expires and a fresh lookup performed.

This is a value you should tune to be short, but long enough not to 
overload the helpers and slow your clients traffic down at peak times.

For initial testing of auth leave it *very* short until you are sure the 
auth is working okay. Then test longer timings until you are happy with 
the performance vs security tradeoff.


> #----------------------------------------------------
> #
> acl AuthenticatedUsers proxy_auth REQUIRED
> http_access allow AuthenticatedUsers

The best way to perform auth is to deny non-authenticated users. That 
includes the ones with *invalid* credentials (attackers or forgotten 
passwords etc.).

Then further access controls can rely on credentials being both present 
and valid and do allows for various reasons. For example; client being 
on the LAN / localnet.


> #-------------------- ACL Puertos --------------------
> 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
> 
> #---------------------- HTTP ACCES DEFAULT-------------
> #http_access allow manager localhost
> #http_access deny manager
> http_access deny !Safe_ports
> 
> Any help ?
> 

Your custom rules should all be down below the !Safe_Ports and "CONNECT 
!SSL_Ports" protections. So attacks using those DoS methods cannot 
overload your auth system and more complicated ACL things.


While the http_access rules are not great they should still have 
"worked" for the request(s) after you entered the credentials.

What I'd do along with enabling debug in the auth helper is to also 
configure "debug_options 11,2" in squid.conf to get a trace of whet the 
HTTP messages contain. That may show some clues about where the problem 
is starting.

Amos