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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
