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
Received on Mon Nov 11 2013 - 22:24:55 MST
This archive was generated by hypermail 2.2.0 : Tue Nov 12 2013 - 12:00:06 MST