[squid-users] Acl to deny all sites, and allow some sites

[hibandx]

So, i have an squid configured and ok with ad 2012, but the acl
Proxy_restrito is not working...

This acl is for 

any solution?

This is my conf is for deny all sites, and allow just some sites on file
proxy_restrito_whitelist...

follow:

#Porta padrão do proxy
http_port 3128
 
#Endereco de E-mail do administrador do proxy
cache_mgr suporte@dominio.local
 
#Nao faz cache de dados de formularios html,em de resultados de programas
cgi  
#hierarchy_stoplist cgi-bin ?
 
#Cria uma access control list, baseando-se na url e utilizando exp.
regulares nesta situacao   
#foi criado uma exp. regular para cgi e ?.
acl QUERY urlpath_regex cgi-bin \?
 
#Nao faz cache da acl QUERY
cache deny QUERY
 
#Define o tamonho maximo de um objeto para seu armazenamento no cache local 

maximum_object_size 4096 KB
 
#Define o tamanho minimo de um objeto para seu armazenamento no cache local 

minimum_object_size 0 KB
 
#Define o tamanho maximo de um objeto para seu armazenamento no cache de
memoria
maximum_object_size_in_memory 64 KB
 
#Definicao da quantidade de memoria ram a ser alocada para cache

cache_mem 60 MB
 
#Para nao bloquear downloads   
quick_abort_min -1 KB
 
# Resolve um problema com conexões persistentes que ocorre com certos
servidores,
# e que provoca delays em nosso cache.
detect_broken_pconn on
 
# Provoca um ganho de performance ao usar conexões Pipeline (requisições em
paralelo)
pipeline_prefetch on
 
 
#Para cache de fqdn
fqdncache_size 1024

# Add any of your own refresh_pattern entries above these.
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

#Definicao da porcentagem do uso do cache que fara o squid descartar os
arquivos mais antigos
cache_swap_low 90
cache_swap_high 95
 
#Logs   
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
 
#Define a localizacao do cache de disco, tamanho, qtd de diretorios pai, e
por fim a qtd de dir filhos   
cache_dir aufs /var/spool/squid 100 16 256
 
#Controle do arquivo de Log
logfile_rotate 10
 
#Arquivo que contem os nomes de maquinas   
hosts_file /etc/hosts
 
#Maquinas que nao precisaram de autenticacao   
acl liberados dstdomain "/etc/squid/regras/liberados"
http_access allow liberados
 
#liberar o acesso ao site da caixa que está com problemas 
#acl caixa dstdomain caixa.gov.br
#always_direct allow caixa
#cache deny caixa
 
#MACS que estão liberados.
acl macliberado   arp "/etc/squid/regras/mac_liberado"
http_access allow macliberado
 
 
### ACL Padroes
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
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 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
acl Safe_ports port 1080
acl Safe_ports port 1863
acl Safe_ports port 8443 # https
acl Safe_ports port 5222 # gTalk
acl Safe_ports port 5223 # gTalk
acl Safe_ports port 47057 # torrent

acl purge method PURGE
acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

#Limita conexeos HTTP
#acl connect_abertas maxconn 8

#sites que não serão feito cache geralmente bancos
acl NOCACHE dstdomain "/etc/squid/regras/direto" \?
no_cache deny NOCACHE

 
 Autenticao no Windows 2008/2012/Samba 4 via WINBIND
auth_param ntlm program /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
auth_param basic program /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy server
auth_param basic credentialsttl 2 hours
#Note que abaixo o meu sistema é 64 então as minhas libs estão em /usr/lib64
caso esteja utilizando sistema 32 troque para /usr/lib
external_acl_type ad_group ttl=1800 children=200 %LOGIN
/usr/lib64/squid/ext_wbinfo_group_acl

#---#
#   Nome ACLTIPONome Grupo AD   
   
#
#---#

aclproxy_livreexternal ad_group  proxy_livre
aclproxy_geral   external ad_group  proxy_geral
aclproxy_restrito  external ad_group 

[squid-users] Transparent Proxy on OSX Yosemite

[Shively, Gregory]

I'm attempting to get a squid working as a transparent proxy on OSX Yosemite. 
Every attempt ended with a "Forward loop detected". I initially started with 
the version from homebrew and moved to just compiling myself to see if I could 
figure out what was going on. Being new to both pf network and squid, it might 
be something that I have configured wrong. I configured pf similar to:

  nat on $ext_if proto {udp, tcp} from $int_if:network to any port 
domain -> ($ext_if)
  rdr pass on $int_if proto tcp from $int_if:network to any port 
{http, https} -> 127.0.0.1 port 3129

And my squid.conf for my testing is basically:

http_port 3128
http_port 3129 intercept
http_access allow all

I'm not sure if this is more appropriate on this mailing list or the developer 
mailing list (hoping it is just something I'm doing wrong). The squid that I'm 
using doesn't have -with-nat-devpf enabled; it fails to compile with that 
option. I'm wondering if the getsockname() as per comment for PFIntercept (of 
the !_USE_NAT_DEVPF) in src/ip/Intercept.cc, on OSX is not returning the 
pre-rdr address and causing the forward loop.

As mentioned, the -with-nat-devpf fails to compile on OSX due to a missing 
header file. And from looking it sounds like the header is for the ioctl() on 
/dev/pf, which doesn't seem to be public API on OSX. So I'm trying to determine 
if my issue is due to a misconfiguration - or is this portion of the code not 
working with OSX. I looked at the code for mitmproxy, and it seems like they 
require a sudoers entry to run "pfctl -s state" and parse the state. Would 
something like that need to be added to squid to support transparent proxy on 
OSX. I had started to put some code together like mitmproxy, but thought better 
check if I didn't get something configured correctly.

Greg
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit Bandwith for youtube....

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
I did not say it would be easy, right? :)

31.08.2016 2:51, Yuri Voinov пишет:
>
> And, to limit faceboot video,
>  you require to utilize akamaihd\.net\/v\/(.*\.mp4)\? regex in
conjunction with delay-pool + SSL bump. :)
>
> 31.08.2016 2:48, Yuri Voinov пишет:
>
>
>   > To cache streaming video, you require to utilize Store-ID
>   feature:
>
>
>
>   > http://wiki.squid-cache.org/Features/StoreID
>
>
>
>
>
>   > 31.08.2016 2:16, erdosain9 пишет:
>
>   > > By the way...
>
>   > > I have this on log
>
>
>
>
>
>
>
https://fbcdn-video-k-a.akamaihd.net/hvideo-ak-xat1/v/t42.1790-2/12094265_992502374146158_1776024195_n.mp4?
>
>   > > - HIER_DIRECT/204.2.178.146 -
>
>
>
>   > > i do not know how to use https://regex101.com/
>
>
>
>   > > it will be like
>
>
>
>   > > akamaihd\.net\/v\/(.*\.mp4)\?
>
>
>
>   > > Thanks.
>
>
>
>
>
>
>
>   > > --
>
>   > > View this message in context:
>
>
>
http://squid-web-proxy-cache.1019090.n4.nabble.com/Limit-Bandwith-for-youtube-tp4679182p4679269.html
>
>   > > Sent from the Squid - Users mailing list archive at
>   Nabble.com.
>
>   > > ___
>
>   > > squid-users mailing list
>
>   > > squid-users@lists.squid-cache.org
>
>   > > http://lists.squid-cache.org/listinfo/squid-users
>
>
>
>
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxfXJAAoJENNXIZxhPexGpLkIAL8qff5Ky6ZEYXgBnc3MVxIx
elo//UatXQHcELnPdSpFpC+5W+bSF5KMyBtzZy3zThsy7ipcT2iKwUP/9e00uCWY
fVQcbFUIiu9bR9M3LGhJuG7mUVtER2MBkX/wPUuRUpAabKRRZ05TlpIaYyUteU7A
GDuA74l/X3j26/XOeY0zPishz1V8enPLmgyO5ZvL3t16YjXKF2QWLkoe4gkSHLHr
+HWqXn1yYGa+XoJetZAgTbLp4eNhoBNC6ZOIs1ThRzkUFfuDjexCVinJX1E3JLYC
CBBQ+PBQIiirML0u3WwA02ad0pIeyeUEZ4eV6ZnHuXX8wZyuaD2H/DiSwW/90vI=
=bQ0e
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit Bandwith for youtube....

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
And, to limit faceboot video,
 you require to utilize akamaihd\.net\/v\/(.*\.mp4)\? regex in
conjunction with delay-pool + SSL bump. :)

31.08.2016 2:48, Yuri Voinov пишет:
>
> To cache streaming video, you require to utilize Store-ID feature:
>
> http://wiki.squid-cache.org/Features/StoreID
>
>
> 31.08.2016 2:16, erdosain9 пишет:
> > By the way...
> > I have this on log
>
>
>
https://fbcdn-video-k-a.akamaihd.net/hvideo-ak-xat1/v/t42.1790-2/12094265_992502374146158_1776024195_n.mp4?
> > - HIER_DIRECT/204.2.178.146 -
>
> > i do not know how to use https://regex101.com/
>
> > it will be like
>
> > akamaihd\.net\/v\/(.*\.mp4)\?
>
> > Thanks.
>
>
>
> > --
> > View this message in context:
>
http://squid-web-proxy-cache.1019090.n4.nabble.com/Limit-Bandwith-for-youtube-tp4679182p4679269.html
> > Sent from the Squid - Users mailing list archive at Nabble.com.
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > http://lists.squid-cache.org/listinfo/squid-users
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxfHrAAoJENNXIZxhPexGanwH+wXVGdAz0hdbK6Pof0vZlXHz
poxITiDr/hS3IUU5hiFNIsXS4fHRHZBkAH5m9jxnwgo2kOIu4KQ8MJh7eUmV3gAi
Qu+r0A/S3U3CWpbPpRMvbhyK9X+7434vWE6Qeuywc7WjtEnf+Pjwo5/yVwf+p2IN
ntdZwJaYc8loQcTgofYw+ARYBeRP6f9H9BUIrmTwm91HaPP1XYo4/XxL+wfmbjtI
CiAtW0bu4xi479cG7HaWkwSs3MnXz2lZGD/usBqpvZi+L3N4Kjh3cE5ZDDM8P2/h
lJqIZiIJAjkV6z6ychdZgp8KYZcvpbVPAodZZ4NTRe/NGRwx/MyHIFoaSO2TjZ4=
=TIqC
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit Bandwith for youtube....

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
To cache streaming video, you require to utilize Store-ID feature:

http://wiki.squid-cache.org/Features/StoreID


31.08.2016 2:16, erdosain9 пишет:
> By the way... 
> I have this on log
>
>
https://fbcdn-video-k-a.akamaihd.net/hvideo-ak-xat1/v/t42.1790-2/12094265_992502374146158_1776024195_n.mp4?
> - HIER_DIRECT/204.2.178.146 -
>
> i do not know how to use https://regex101.com/
>
> it will be like
>
> akamaihd\.net\/v\/(.*\.mp4)\?
>
> Thanks.
>
>
>
> --
> View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Limit-Bandwith-for-youtube-tp4679182p4679269.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxfEFAAoJENNXIZxhPexGPNAIAIuFAn/eijxhISMJity1Nu4i
TJOmsqM2RR9mCKwbbJSm+8M9fML7SNn/SH7V7nMgI01+WusgjBIgSpaIrT4ZNoP4
FinnYscibOC2oJPPmYBMp2dqdilIq+8MCMTjFzVwgJuYzxAeCtz5sgjlDpq8fNAp
nje6/q3TgfYYLuQwaQYseJO7ig3kvcDHa7vGrqdQzxPzk2epXnkx3EE5kmrU48hp
EWeAYh4yBa1wF5njtBJ57PhXtL0nTSXfm4ZJVsn87fBQQGqeqz+Smgw1HbX7qtLH
0zCXf3jZyud3wcA+nGM0xxDSEEKVw3j6KUKtFXC99iqredrVIsFyHnzhFODKEIc=
=933O
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] SQUID3 FreeRADIUS

[Craddock, Tommy]

Hello,

The name of the helper was changed some time ago:

2.5 Helper Name Changes

To improve the understanding of what each helper does and where it should be 
used the helper binaries which are bundled with Squid have undergone a naming 
change in this release.

Below is a list of the old helper names and what their names have changed to. 
For several helpers the directory name used in --enable-X-helpers configure 
option has also changed.

Basic Authentication protocol helpers:


  *   squid_radius_auth - basic_radius_auth - Authenticate with RADIUS.

Source:
ftp://ftp.fu-berlin.de/unix/www/squid/archive/3.2/squid-3.2.0.12-RELEASENOTES.html

On RH and its derivatives, it will be at:

[root@clwslprox01p ~]# locate basic_radius_auth
/usr/lib64/squid/basic_radius_auth

May be different on other flavors, do a locate on it to find it.

Tommy Craddock Jr.


From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Janis Heller
Sent: Tuesday, August 30, 2016 4:10 PM
To: squid-users@lists.squid-cache.org
Subject: [squid-users] SQUID3 FreeRADIUS

How to use freeradius in squid3?
The wiki information I found is very outdated:

http://wiki.squid-cache.org/ConfigExamples/Authenticate/Radius

The path: "/usr/local/squid/libexec/squid_radius_auth -f /etc/radius_config“ 
doesn’t exist anymore on SQUID3.

All the best;



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit Bandwith for youtube....

[erdosain9]

By the way... 
I have this on log

https://fbcdn-video-k-a.akamaihd.net/hvideo-ak-xat1/v/t42.1790-2/12094265_992502374146158_1776024195_n.mp4?
- HIER_DIRECT/204.2.178.146 -

i do not know how to use https://regex101.com/

it will be like 

akamaihd\.net\/v\/(.*\.mp4)\? 

Thanks.



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Limit-Bandwith-for-youtube-tp4679182p4679269.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit Bandwith for youtube....

[erdosain9]

Thanks.
But... 
I'm misunderstanding ?
Tx , is not the download?


I think it works this way in the mikrotik . That is, the transmission would
be the " download "



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Limit-Bandwith-for-youtube-tp4679182p4679268.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] SQUID3 FreeRADIUS

[Janis Heller]

How to use freeradius in squid3?
The wiki information I found is very outdated:

http://wiki.squid-cache.org/ConfigExamples/Authenticate/Radius

The path: "/usr/local/squid/libexec/squid_radius_auth -f /etc/radius_config“ 
doesn’t exist anymore on SQUID3.

All the best;
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] More host header forgery pain with peek/splice

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
And this one:

http://wiki.squid-cache.org/ConfigExamples/Intercept/CiscoIOSv15Wccp2

of course.


30.08.2016 23:25, Marcus Kool пишет:
> Do I understand it correctly that Squid in normal proxy mode
> allows malware to do a CONNECT to any destination, while in
> transparent proxy mode does extra security checks which causes
> some regular (non-malware) clients to fail?
>
> And philosophical questions: is Squid the right tool
> to stop malware?  If yes, is it acceptable that connections
> of regular (non-malware) clients are wrongly dropped?
>
> IMO Squid should do all it can to be a secure proxy.
> Doing security checks on connections in an attempt
> to stop malware sounds like a job for an antivirus / IDS tool.
>
> Marcus
>
>
> On 08/30/2016 01:01 PM, Amos Jeffries wrote:
>> On 26/08/2016 6:34 a.m., reinerotto wrote:
>>> Hack the code. Because it is even worse, as firefox for example does
not obey
>>> to the TTL.
>>>
>>
>> It is not that simple. The checks are there for very good reason(s)
>> related to security of the network using the proxy.
>>
>> The Host forgery issue being checked for allows network firewall rule
>> bypass, browser same-origin bypass, and browser sandbox bypass - in a
>> way which places the attacker in control of what logs you see [aha!
>> invisible access to the network]. With all the related nasty
>> side-effects those allow. There is both malware and services for sale
>> around the 'net that take advantage of the attack to do those bypasses.
>> => Simply disabling the check code is a *very* risky thing to do.
>>
>>
>> The cases where Squid still gets it wrong are where the popular CDN
>> service(s) in question are performing DNS actions indistinguishable to
>> those malware attacks. If Squid can't tell the difference between an
>> attack and normal DNS behaviour the only code change possible is to
>> disable the check (see above about the risk level).
>>
>>
>> FYI: I have a plan to reduce the false-positive rate from DNS rotation
>> effects. But that requires some deep redesign of the DNS code, which I'm
>> intending to do as part of the Squid-5 roadmap to avoid further
>> destabilizing 4.x while its in beta.
>>
>> For now the workarounds are:
>>
>> * obey the requirement that destination NAT (if any) is performed only
>> on the Squid machine.
>>
>> * to tune the lifetime for persistent client connections. That reduces
>> (but not fully) connections outliving DNS rotation times and thus
>> causing requests to have different ORIGINAL_DST from what DNS says.
>>
>> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
>> recursive resolver shared by Squid and client which points to that
>> service as its parent/forwarded resolver. That removes the issue with
>> every 8.8.8.8 response having different reply IP values (so client and
>> Squid doing near simultaneous lookups get different IPs).
>>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd4/AAoJENNXIZxhPexGwjwH+QHrd7xRMHLr1kTxd7cMoVtS
bMXLslGgtdno0T8hueLY68pCybfFSU/aO3HDg3V8SNvH8cx84ZSndqvUtbro3/Ze
Uzt+JQtvp8R7vyTgrfJFy02UJvxk6jtd88H/FSO0bp4vLNOxDg3H/OvxjyXuHU5C
fACXayHvZbf/IZzpEjyVWt2pKH9TBNK2eB2omqIQupFCGboIk70S2kpeA8L8+YKx
1hWq0QWY9esyi7b8OZwX2QnEU2M+eBYCn+KZHp6BorLfxOTcctpxM37Up3ieOON5
asyOC4MMmOAvqs4NSHgqfGB2Pybd6I0+wZ0yz576rZqscE/zfRxkbaZ3MqKT53s=
=ernf
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] More host header forgery pain with peek/splice

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


31.08.2016 1:24, Yuri Voinov пишет:
>
>
>
> 30.08.2016 23:25, Marcus Kool пишет:
> > Do I understand it correctly that Squid in normal proxy mode
> > allows malware to do a CONNECT to any destination, while in
> > transparent proxy mode does extra security checks which causes
> > some regular (non-malware) clients to fail?
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
>
> > And philosophical questions: is Squid the right tool
> > to stop malware?  If yes, is it acceptable that connections
> > of regular (non-malware) clients are wrongly dropped?
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
Not stop all. But reduce.
>
>
> > IMO Squid should do all it can to be a secure proxy.
> > Doing security checks on connections in an attempt
> > to stop malware sounds like a job for an antivirus / IDS tool.
> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
> http://wiki.squid-cache.org/Features/SslPeekAndSplice
>
>
>
> > Marcus
>
>
> > On 08/30/2016 01:01 PM, Amos Jeffries wrote:
> >> On 26/08/2016 6:34 a.m., reinerotto wrote:
> >>> Hack the code. Because it is even worse, as firefox for example does
> not obey
> >>> to the TTL.
> >>>
> >>
> >> It is not that simple. The checks are there for very good reason(s)
> >> related to security of the network using the proxy.
> >>
> >> The Host forgery issue being checked for allows network firewall rule
> >> bypass, browser same-origin bypass, and browser sandbox bypass - in a
> >> way which places the attacker in control of what logs you see [aha!
> >> invisible access to the network]. With all the related nasty
> >> side-effects those allow. There is both malware and services for sale
> >> around the 'net that take advantage of the attack to do those bypasses.
> >> => Simply disabling the check code is a *very* risky thing to do.
> >>
> >>
> >> The cases where Squid still gets it wrong are where the popular CDN
> >> service(s) in question are performing DNS actions indistinguishable to
> >> those malware attacks. If Squid can't tell the difference between an
> >> attack and normal DNS behaviour the only code change possible is to
> >> disable the check (see above about the risk level).
> >>
> >>
> >> FYI: I have a plan to reduce the false-positive rate from DNS rotation
> >> effects. But that requires some deep redesign of the DNS code,
which I'm
> >> intending to do as part of the Squid-5 roadmap to avoid further
> >> destabilizing 4.x while its in beta.
> >>
> >> For now the workarounds are:
> >>
> >> * obey the requirement that destination NAT (if any) is performed only
> >> on the Squid machine.
> >>
> >> * to tune the lifetime for persistent client connections. That reduces
> >> (but not fully) connections outliving DNS rotation times and thus
> >> causing requests to have different ORIGINAL_DST from what DNS says.
> >>
> >> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
> >> recursive resolver shared by Squid and client which points to that
> >> service as its parent/forwarded resolver. That removes the issue with
> >> every 8.8.8.8 response having different reply IP values (so client and
> >> Squid doing near simultaneous lookups get different IPs).
> >>
> >> Amos
> >>
> >> ___
> >> squid-users mailing list
> >> squid-users@lists.squid-cache.org
> >> http://lists.squid-cache.org/listinfo/squid-users
> >>
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > http://lists.squid-cache.org/listinfo/squid-users
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd3bAAoJENNXIZxhPexGUbgH/j4qcbQW7u/zktJpJLlqhed3
+J7Qsr6eXyeC3ryG8q8w5CGAdP/ESoeJO/aA02uW/DEf517oH5kHxMtKdtyl9VNw
suqNAcFsk6F8fYG+9h2+0Zip2IN3IC8u2ArtZcVcd5QO/rruEEFLK6HX3K9cvOBn
guRq9LNa5DvX83cYhxdQIdDJ8eeGGOxcwteyajkeMfwskfx4dLeoDO2B4F56VKLA
ugVA7NBskVe2TiuhgfpZ4fOWslWaiZATma1beM4sa0KOvRUqxKuf0BJlnX+Llyzp
YsD1cPRXs4YftF6t4d/iV4BT+oUYKq4UugHNHgy3PqgKu9VFWoeX/dBmHRMYHQY=
=Siw+
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] More host header forgery pain with peek/splice

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


30.08.2016 23:25, Marcus Kool пишет:
> Do I understand it correctly that Squid in normal proxy mode
> allows malware to do a CONNECT to any destination, while in
> transparent proxy mode does extra security checks which causes
> some regular (non-malware) clients to fail?
http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
>
> And philosophical questions: is Squid the right tool
> to stop malware?  If yes, is it acceptable that connections
> of regular (non-malware) clients are wrongly dropped?
http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP

>
> IMO Squid should do all it can to be a secure proxy.
> Doing security checks on connections in an attempt
> to stop malware sounds like a job for an antivirus / IDS tool.
http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP
http://wiki.squid-cache.org/Features/SslPeekAndSplice


>
> Marcus
>
>
> On 08/30/2016 01:01 PM, Amos Jeffries wrote:
>> On 26/08/2016 6:34 a.m., reinerotto wrote:
>>> Hack the code. Because it is even worse, as firefox for example does
not obey
>>> to the TTL.
>>>
>>
>> It is not that simple. The checks are there for very good reason(s)
>> related to security of the network using the proxy.
>>
>> The Host forgery issue being checked for allows network firewall rule
>> bypass, browser same-origin bypass, and browser sandbox bypass - in a
>> way which places the attacker in control of what logs you see [aha!
>> invisible access to the network]. With all the related nasty
>> side-effects those allow. There is both malware and services for sale
>> around the 'net that take advantage of the attack to do those bypasses.
>> => Simply disabling the check code is a *very* risky thing to do.
>>
>>
>> The cases where Squid still gets it wrong are where the popular CDN
>> service(s) in question are performing DNS actions indistinguishable to
>> those malware attacks. If Squid can't tell the difference between an
>> attack and normal DNS behaviour the only code change possible is to
>> disable the check (see above about the risk level).
>>
>>
>> FYI: I have a plan to reduce the false-positive rate from DNS rotation
>> effects. But that requires some deep redesign of the DNS code, which I'm
>> intending to do as part of the Squid-5 roadmap to avoid further
>> destabilizing 4.x while its in beta.
>>
>> For now the workarounds are:
>>
>> * obey the requirement that destination NAT (if any) is performed only
>> on the Squid machine.
>>
>> * to tune the lifetime for persistent client connections. That reduces
>> (but not fully) connections outliving DNS rotation times and thus
>> causing requests to have different ORIGINAL_DST from what DNS says.
>>
>> * if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
>> recursive resolver shared by Squid and client which points to that
>> service as its parent/forwarded resolver. That removes the issue with
>> every 8.8.8.8 response having different reply IP values (so client and
>> Squid doing near simultaneous lookups get different IPs).
>>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJXxd12AAoJENNXIZxhPexGatAIAMvXwPnEHw5PR+fg+8KdxCQ3
h0fYEFKZHOI2P0b+kk7DRd/RG1mBdM23Hlr6EflqXGSigkuYF8fLGfx4iyo6BaXt
gOO4Z/CEoUCtjF8PPG8WWNaRz5kz4eZcMJM10gGJ0wke8ojDUJ11Z0TXorj7n9Ou
JRG2XuyP4RF2fHxOPsCvQRD1I7yiynMVXa8vsc6PHvlOru56rs/VTd86NX2jBFJf
TpM6UWrJzmZbUAIlrzhgllEPpgfUPzTdJX8eIFKQeVnOyq0i6o5pjc8wdg4CZUkw
naaYNTp/xsx/zfhW75xjKV4UuxCGiZy9zroiKpyu/EjnSUvtnQHVFrWyhvxCJrM=
=mPgV
-END PGP SIGNATURE-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] More host header forgery pain with peek/splice

[Marcus Kool]

Do I understand it correctly that Squid in normal proxy mode
allows malware to do a CONNECT to any destination, while in
transparent proxy mode does extra security checks which causes
some regular (non-malware) clients to fail?

And philosophical questions: is Squid the right tool
to stop malware?  If yes, is it acceptable that connections
of regular (non-malware) clients are wrongly dropped?

IMO Squid should do all it can to be a secure proxy.
Doing security checks on connections in an attempt
to stop malware sounds like a job for an antivirus / IDS tool.

Marcus


On 08/30/2016 01:01 PM, Amos Jeffries wrote:

On 26/08/2016 6:34 a.m., reinerotto wrote:

Hack the code. Because it is even worse, as firefox for example does not obey
to the TTL.



It is not that simple. The checks are there for very good reason(s)
related to security of the network using the proxy.

The Host forgery issue being checked for allows network firewall rule
bypass, browser same-origin bypass, and browser sandbox bypass - in a
way which places the attacker in control of what logs you see [aha!
invisible access to the network]. With all the related nasty
side-effects those allow. There is both malware and services for sale
around the 'net that take advantage of the attack to do those bypasses.
=> Simply disabling the check code is a *very* risky thing to do.


The cases where Squid still gets it wrong are where the popular CDN
service(s) in question are performing DNS actions indistinguishable to
those malware attacks. If Squid can't tell the difference between an
attack and normal DNS behaviour the only code change possible is to
disable the check (see above about the risk level).


FYI: I have a plan to reduce the false-positive rate from DNS rotation
effects. But that requires some deep redesign of the DNS code, which I'm
intending to do as part of the Squid-5 roadmap to avoid further
destabilizing 4.x while its in beta.

For now the workarounds are:

* obey the requirement that destination NAT (if any) is performed only
on the Squid machine.

* to tune the lifetime for persistent client connections. That reduces
(but not fully) connections outliving DNS rotation times and thus
causing requests to have different ORIGINAL_DST from what DNS says.

* if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
recursive resolver shared by Squid and client which points to that
service as its parent/forwarded resolver. That removes the issue with
every 8.8.8.8 response having different reply IP values (so client and
Squid doing near simultaneous lookups get different IPs).

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Too many AD group and squid kerberos auth problem

[Jok Thuau]

On Tue, Aug 30, 2016 at 4:05 AM, alberto  wrote:

> Hi all,
> I have a squid3 installation with kerberos ldap groups authentication.
> Everything works like a charm except for one of my user that belongs to
> too many groups (more than 50): this user can not browse any site because
> of authentication problem.
> I always see TCP_DENIED/407 in the squid log file for that user.
>
> Is there a parameter that I can change in the squid.conf file to increase
> the number of groups allowed during authentication?
> FYI I'm on Debian Jessie and using this kerberos configuration
>
>
if you are using group membership authorization purely to allow/deny access
globally (rather than for specific sites), you can tweak your filter to
accomplish that...


> squid.conf snippet===
>

 [snip]


> # Basic Auth 
> auth_param basic program /usr/lib/squid3/basic_ldap_auth -D
> srvc_sq...@example.lcl -W /etc/squid3/ldappwd.txt -h "example.lcl" -b
> "OU=root,DC=EXAMPLE,DC=LCL" -s sub -f (&(objectClass=Person)(
> sAMAccountName=%s))
>

this filter (after "-f") could be tweaked like this:
(&(objectClass=Person)(sAMAccountName=%s)(|(memberOf=CN=group1,OU=somewhere,dc=EXAMPLE,dc=LCL)(memberOf=CN=group2,OU=somewhere,dc=EXAMPLE,dc=LCL))

That would allow the user to login if they are member of either group.
(that syntax/schema is for AD, feel free to adjust as needed)
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] More host header forgery pain with peek/splice

[Amos Jeffries]

On 26/08/2016 4:17 a.m., Steve Hill wrote:
> 
> This one just seems to keep coming up and I'm wondering how other people
> are dealing with it:
> 
> When you peek and splice a transparently proxied connection, the SNI
> goes through the host validation phase.  Squid does a DNS lookup for the
> SNI, and if it doesn't resolve to the IP address that the client is
> connecting to, Squid drops the connection.
> 
> When accessing one of the increasingly common websites that use DNS load
> balancing, since the DNS results change on each lookup, Squid and the
> client may not get the same DNS results, so Squid drops perfectly good
> connections.
> 
> Most of this problem goes away if you ensure all the clients use the
> same DNS server as squid, but not quite.  Because the TTL on DNS records
> only has a resolution of 1 second, there is a period of up to 1 second
> when the DNS records Squid knows about doesn't match the ones that the
> client knows about.  The client and squid may expire the records up to 1
> second apart.

FYI: Services sending TTL of just 1 or even a few seconds are abusing
the DNS system. Rotating the order of IPs in the RR record is a
standardized feature and works just fine with how Squid does its checks.

NP: using "8.8.8.8" in both Squid and client does not count as using the
same resolver. Because that service is an entire farm of resolvers that
can and do respond differently to any two requests - even if they are
made simultaneously. Not a single machine using a single cache of DNS data.

> 
> So what's the solution?  (Notably the validation check can't be disabled
> without hacking the code).
> 

Well, hacking the code. But not necessarily in the obvious way of
disabling checks. Redesign in Squid DNS component is needed. If you want
to sponsor and/or test that work mail me privately. Though its unlikely
to be available for use in the short term .

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] More host header forgery pain with peek/splice

[Amos Jeffries]

On 26/08/2016 6:34 a.m., reinerotto wrote:
> Hack the code. Because it is even worse, as firefox for example does not obey
> to the TTL. 
> 

It is not that simple. The checks are there for very good reason(s)
related to security of the network using the proxy.

The Host forgery issue being checked for allows network firewall rule
bypass, browser same-origin bypass, and browser sandbox bypass - in a
way which places the attacker in control of what logs you see [aha!
invisible access to the network]. With all the related nasty
side-effects those allow. There is both malware and services for sale
around the 'net that take advantage of the attack to do those bypasses.
=> Simply disabling the check code is a *very* risky thing to do.


The cases where Squid still gets it wrong are where the popular CDN
service(s) in question are performing DNS actions indistinguishable to
those malware attacks. If Squid can't tell the difference between an
attack and normal DNS behaviour the only code change possible is to
disable the check (see above about the risk level).


FYI: I have a plan to reduce the false-positive rate from DNS rotation
effects. But that requires some deep redesign of the DNS code, which I'm
intending to do as part of the Squid-5 roadmap to avoid further
destabilizing 4.x while its in beta.

For now the workarounds are:

* obey the requirement that destination NAT (if any) is performed only
on the Squid machine.

* to tune the lifetime for persistent client connections. That reduces
(but not fully) connections outliving DNS rotation times and thus
causing requests to have different ORIGINAL_DST from what DNS says.

* if wanting Google 8.8.8.8 service as your resolver. Use a local DNS
recursive resolver shared by Squid and client which points to that
service as its parent/forwarded resolver. That removes the issue with
every 8.8.8.8 response having different reply IP values (so client and
Squid doing near simultaneous lookups get different IPs).

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Shared Caching with Authorization

[Amos Jeffries]

On 27/08/2016 12:10 a.m., LIJO C J wrote:
> Hi, I have a resource representation in a REST service.  The response
> content  is same for allusers. But the response should be accessed
> only by authorizedInventoryAuditors.
> 
> 
> 
> 1.  How should be the response headers set to leveragecaching in
> Squid (as a forward proxy)?
> 

Squid obeys (modulo bugs) the rules set forth in:
 

Responses are cached by Squid unless prohibited, or the caching
freshness is impossible to calculate.

If you want to guarantee cacheability of your responses send
Last-Modified plus either Expires or Cache-Control:max-age=N.

If those are not possible to send, then dont bother - just let Squid
sort out what is possible to cache with the data you can provide about
the response object.



> 2.  How Squid will validate that the requested useris an
> authorized InventoryAuditor, while serving the response from cache?
> 

Authorization and Authentication are orthoganal concepts to Caching.

Squid uses HTTP authentication as specified in
 *if* you configure Squid to
perform authentication *and* make use of it for authorization checks (ACL).

To provide a cached response the client must be authorized to send HTTP
requests to the proxy. The squid.conf http_access directive does HTTP
request authorization checks.


PS. I'm not sure what that code you finished up your questions with was
supposed to mean. HTTP is a protool, Squid is a proxy - neither is a
coding language.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Too many AD group and squid kerberos auth problem

[Amos Jeffries]

On 30/08/2016 11:05 p.m., alberto wrote:
> Hi all,
> I have a squid3 installation with kerberos ldap groups authentication.
> Everything works like a charm except for one of my user that belongs to too
> many groups (more than 50): this user can not browse any site because of
> authentication problem.
> I always see TCP_DENIED/407 in the squid log file for that user.

The Squid<->helper protocol in Squid-3 is not able to handle very long
lists of groups being returned by the helper. We have a fix in Squid-4,
but it is too large and destabilizing to backport.

You may want to try the latest 4.0 daily snapshot, or 4.0.14 release
which will be coming out as soon as I can find the time to package it.

If Squid-4 does not resolve the issue then the problem is likely to be
the large size of the Negotiate token in HTTP headers. There is no
guarantee that any HTTP header longer than 8000 bytes will be able to be
transmitted. Squid also has a 64KB header length limit at present which
may be applicable.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Limit Bandwith for youtube....

[Amos Jeffries]

On 30/08/2016 8:13 a.m., erdosain9 wrote:
> Ok,thanks!
> But something is wrong with my config
> I dont have almost no users... (because is proxy testing) and i have too
> many download avg.
> 
> Look , this is Torch to the ip of proxy, to see whats going on...
> 
> 
> 
>  
> 

Image does not exist.

> 
>  

This appears to be showing several clients who are using only several
KB/sec *download* which approximately match some of the delay pools
download rates configured (~10-30 KBps). Also they are *uploading* very
fast to the server.

Delay pools controls download rates, not uploads. So that is as
expected. Although not much upload data is expected when streaming
_downloads_, so even if it did the 'burst' rates could account for most
of the higher upload speeds.


> 
> This is my config 
> 
> #Pools para ancho de Banda
> delay_pools 5 
> 
> ###VELOCIDAD PARA REDES SOCIALES
> delay_class 1 1
> delay_parameters 1 1/10
> delay_access 1 allow redes_sociales limitado
> delay_access 1 allow redes_sociales full
> delay_access 1 allow redes_sociales adminis
> 
> #Limitar YOUTUBE
> delay_class 2 1
> delay_parameters 2 1/10
> delay_access 2 allow youtube adminis
> delay_access 2 allow youtube full
> delay_access 2 allow youtube limitado
> 
> #Ancho de Banda Administracion
> delay_class 3 2
> delay_parameters 3 512000/512000 6/256000
> delay_access 3 allow adminis
> 
> #Ancho de Banda Sistemas
> delay_class 4 2
> delay_parameters 4 512000/512000 64000/256000
> delay_access 4 allow sistemas
> 
> #Ancho de Banda Logistica
> delay_class 5 2
> delay_parameters 5 256000/256000 3/125000
> delay_access 5 allow limitado
> 
> 
> if I have delay pools with low bandwidth . How can it be that "long period
> of time " the squid has a bandwidth so high ??

1) see above about download vs upload differences.

2) there are non-HTTP things involves with connections that use up
bandwidth and being non-HTTP are not accounted by Squid - which can only
account the HTTP message bytes.

3) you have both small and large bandwidth pools. Delay pools do not
operate on connection or port basis. They operate on HTTP message bytes
basis. So any given TCP connection may be rate limited one second (for
one message) and then rate limited differently the next second (for its
next message).

Delay pools are a very old design from the days before QoS was properly
standardized. It has many flaws. If you can do rate limiting with TOS /
QoS controls it is recommended to use that instead. I hope to remove
Delay Pools functionality from Squid as soon as the alternatives are
able to meet all use-cases.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Too many AD group and squid kerberos auth problem

[alberto]

Hi all,
I have a squid3 installation with kerberos ldap groups authentication.
Everything works like a charm except for one of my user that belongs to too
many groups (more than 50): this user can not browse any site because of
authentication problem.
I always see TCP_DENIED/407 in the squid log file for that user.

Is there a parameter that I can change in the squid.conf file to increase
the number of groups allowed during authentication?
FYI I'm on Debian Jessie and using this kerberos configuration

squid.conf snippet===

## Kerberos Auth ###
auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth  -s
GSS_C_NO_NAME -i
auth_param negotiate children 10
auth_param negotiate keep_alive off

# External_acl_type 
#internet ALL
external_acl_type kgrp_all ttl=60 negative_ttl=60 %LOGIN
 /usr/lib/squid3/ext_kerberos_ldap_group_acl -i -g "DL Internet
a...@example.lcl" -D EXAMPLE.LCL -S example@example.lcl -m 10 -b
"OU=InternetAccess,OU=Groups,OU=Users &
Groups,OU=Inet,OU=Root,DC=EXAMPLE,DC=LCL"  -D EXAMPLE.LCL -N
exam...@example.lcl

# Basic Auth 
auth_param basic program /usr/lib/squid3/basic_ldap_auth -D
srvc_sq...@example.lcl -W /etc/squid3/ldappwd.txt -h "example.lcl" -b
"OU=root,DC=EXAMPLE,DC=LCL" -s sub -f
(&(objectClass=Person)(sAMAccountName=%s))
auth_param basic children 10
auth_param basic realm Internet Proxy
auth_param basic credentialsttl 1 minute


Thank you for your help,
Alberto
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users