On 2013-11-12 02:22, emerson.carpes wrote:
Gentlemen
When I set my browser proxy does not display the images "CAPTCHA",
even releasing my ip by proxy remains the same.
When put P2P firewall on my machine works in the same browser, so I
believe it is a problem in squid.
Below the contents of acess.log:
1384173759.292 833 10.21.100.195 TCP_MISS/302 647 GET
http://www.bj2.me/ - DIRECT/190.93.254.184 text/html
1384173759.570 269 10.21.100.195 TCP_MISS/200 1609 GET
http://www.bj2.me/login.php - DIRECT/190.93.254.184 text/html
1384173760.014 382 10.21.100.195 TCP_MISS/200 12633 GET
http://www.bj2.me/functions/simple-php-captcha.php? -
DIRECT/190.93.254.184 image/png
As Elizer said this is a successful transfer.
* a 12.6KB ONG image delivered to the browser.
* caching was not involved.
* authentication was not involved.
FWIW, going in to investigate if that log line is correct I find the
website is using a completely different captcha system. see
http://redbot.org/?descend=True&uri=http://www.bj2.me/login.php for
details on that and a few very major HTTP bugs. The extremely broken
Vary support which could be the problem if the captcha is served as a
negotiable image type.
Now, for your free config audit ...
Your Squid version 3.1.10 is quite old now. Can you try an upgrade? Some
of the suggestions below will work okay with 3.1 but even better with
the current stables.
Contents squid.conf file:
#------------------------------------------------------------------------------
# Authentication
#
-----------------------------------------------------------------------------
OK.
#------------------------------------------------------------------------------
# Groups
#
-----------------------------------------------------------------------------
OK.
#-------------------------------------------------------------------------------
# Lock and release groups
#-------------------------------------------------------------------------------
acl msn_http url_regex -i "/etc/squid/msn.txt"
##--http_access deny WebRestricted msn_http
http_access deny WebSNRestricted msn_http
acl tlmk dstdomain -i "/etc/squid/liberados_tlmk.txt"
http_access allow WebLimited tlmk
acl snblocked url_regex -i "/etc/squid/bloqueio_social_networks.txt"
http_access deny WebSNRestricted snblocked
http_access deny WebLimited snblocked
#--acl snblocked_PosProducao url_regex -i
"/etc/squid/redes_sociais.txt"
#--http_access deny WebPosProducao snblocked_PosProducao
acl proibidos dstdomain -i "/etc/squid/proibidos.txt"
http_access allow WebRestricted proibidos
http_access deny WebSNRestricted proibidos
http_access deny WebPosProducao proibidos
acl liberados dstdomain -i "/etc/squid/liberados.txt"
http_access allow WebRestricted liberados
http_access allow WebSNRestricted liberados
#http_access allow WebPosProducao liberados
acl urls url_regex -i "/etc/squid/urls.txt"
http_access allow WebRestricted urls
http_access deny WebSNRestricted urls
http_access deny WebPosProducao urls
acl extensoes urlpath_regex -i "/etc/squid/extensoes.txt"
#--http_access allow WebRestricted extensoes
http_access deny WebSNRestricted extensoes
http_access deny WebPosProducao extensoes
http_access allow WebRestricted
http_access allow WebSNRestricted
http_access allow WebFull
http_access allow WebPosProducao
http_access deny WebBlockAll
Performance hint:
Take a close look at the load on your authentication and group lookup
helpers.
While regex is regarded a very slow ACL type, it is still faster than
external ACL lookups in a lot of cases. You may find your proxy runs
faster if you change the above group ACL lines to the format:
http_acces allow/deny <regex-check> <group-check> all
This works if the group helper is being used often or the regex ACL list
is relatively short.
Hint #2: current Squid have faster regex handling which improves the
gain even further.
#-------------------------------------------------------------------------------
# Minimal Configuration
#-------------------------------------------------------------------------------
acl all src all
Remove the above line.
#acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
Replace:
acl localhost src 127.0.0.1 ::1
acl to_localhost dst 127.0.0.0/8
Replace:
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl SSL_ports port 443
acl Radio_ports port 7000
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 Safe_ports port 2095 # Webmail Madrugada com Deus
acl CONNECT method CONNECT
#####--http_access deny CONNECT !SSL_ports !Radio_ports
http_access deny CONNECT !SSL_ports
http_access allow Safe_ports
Security warning:
The above two http_access lines are basic security to prevent clients
from accessing yoru proxy and performing a wide range of malicious
activity. That activity can happen even on trusted clients if they are
infected, hijacked, or simply viewing a maliciously crafted website.
You should have these two above all the other http_access rules. Adjust
SSL_Ports if you really have to for HTTPS services, but only after a
careful check that it is actually needed.
http_access allow localhost
http_access deny all
icp_access allow all
cache_store_log none
Remove the above line. "none" is the default in Squid-3.
cache_access_log /logs/access.log
The "cache_" part of the above line is no longer needed. These are just
"access_log ..." now.
visible_hostname 2111-px01
The above should be a FQDN resolvabel in DNS by clients. It is used in
error pages etc. to generate URLs for followup client requests.
Your Squid should also be able to auto-detect the machine hostname
automatically, most of the bugs in 2.x and 3.0 series around this have
been fixed. If not then an upgrade to current will fix the remaining
issues.
http_port 3128
hierarchy_stoplist cgi-bin ?
The above directive is not necessary in Squid-3. It is particularly
useless if you do not have any cache_peer entries. You can remove it.
cache_mem 1276 MB
#-------------------------------------------------------------------------------
# Opcoes de tamanho do cache
#-------------------------------------------------------------------------------
cache_dir diskd /cache 61440 16 256 Q1=64 Q2=72
logfile_rotate 1
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
The above lines are deprecated since Squid-2.7. You should remove them
and add a new refresh_pattern as mentienod below.
#Suggested default:
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
OK.
refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200
override-expire ignore-no-cache ignore-no-store ignore-private
refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200
90% 432000 override-expire ignore-no-cache ignore-no-store
ignore-private
refresh_pattern -i
\.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200
override-expire ignore-no-cache ignore-no-store ignore-private
There is very little reason to so ignore explicit caching instructions.
In particular explicit "private", "no-store" and "Expires:" controls are
quite bad to ignore/override in such a global way. They are used by
systems like captcha to prevent the wrong images being displayed.
You should only use those particular control overrides in a highly
targeted way for URLs or domains which are clearly using them wrong. AND
that reason foruse should be re-evaluated periodically to ensure the
service provider did not fix anything.
Case study for this is Facebook; years ago they were terrible for
forcing non-caching on all of their content and the website rendered
horribly slowly unless one override the Expires and Cache-Control
headers on the mostly static parts of the site. In the last few years
they have improved their controls such that they work really well and
the situation is reversed. Admin still overriding the FB cache expiry
controls (like you do) are now the ones who get slow and buggy user
experience.
Ignoring no-cache is less serious, but can cause a significant amount of
web content (like FB, Youtube, Google) to be delivered inaccurately and
at times corrupt the users visible display of pages and sites.
Hint: Upgrading to current Squid the control is obsoleted and the
no-cache objects are stored without being forced.
refresh_pattern -i \.index.(html|htm)$ 0 40% 10080
refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320
Add this (replaces the QUERY controls above):
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 40% 40320
#-------------------------------------------------------------------------------
# Opcoes do HTTP
#-------------------------------------------------------------------------------
acl apache rep_header Server ^Apache
#broken_vary_encoding allow apache
This is all useless now. You can erase this section completely from your
Squid-3 config files.
#-------------------------------------------------------------------------------
# Idioma
#-------------------------------------------------------------------------------
error_directory /usr/share/squid/errors/pt-br/
#-------------------------------------------------------------------------------
# Diretorios do cache
#-------------------------------------------------------------------------------
cachemgr_passwd secret shutdown
cachemgr_passwd acqwp info stats/objects
cachemgr_passwd disable all
coredump_dir /var/spool/squid
coredump_dir /usr/local/squid/var/cache
NOTE: you should now change those manager passwords.
In any event, this appears to be a cut-n-paste from an example out of
the administration manual. You may want to consider what it does and
whether it meets your actual needs.
Amos
