Pesquisar neste blog

Mostrando postagens com marcador SQUID. Mostrar todas as postagens
Mostrando postagens com marcador SQUID. Mostrar todas as postagens

quarta-feira, 21 de maio de 2014

How To Setup Squid Authenticate with Radius on CentOS 6

In this how to, I assume you already have a setup running FreeRADIUS server. I am going to share how to install and setup Squid 3.1.10 on CentOS 6.4 version. This how to has been tested on Windows 7 and Chrome as a client.
First, we must ensure everything are up to date by running the following commands: -
yum check-update
yum -y update
Next, start installing Squid by running the following command: -
yum -y install squid
Now, add the following auth_param and http_access config below in /etc/squid/squid.conf file after line 6: -
# Radius Authentication
auth_param basic program /usr/lib64/squid/squid_radius_auth -f /etc/squid/squid_radius_auth.conf
auth_param basic children 5
auth_param basic realm My-Squid-Server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
acl radius-auth proxy_auth REQUIRED
# Allow Radius Authorized Users
http_access allow radius-auth
Next, include the following config below in /etc/squid/squid_radius_auth.conf file: -
# Radius server and secret
server 1.2.3.4
secret my-secret-here
Now, start Squid service and create a system startup links for Squid so it starts automatically whenever the system boots up: -
service squid start
chkconfig squid on
Now you can test the helper, execute and then type your radius username/password on the same line separated with space, on successful authentication it will give “OK” otherwise “ERR login failure”
[leo@srv01 leo]# /usr/lib64/squid/squid_radius_auth -f /etc/squid/squid_radius_auth.conf
mylogin mypassword
OK
Next, setup your favourite web browser to use port 3128. You will be prompted to enter username and password to start web browsing.
Finally, with all the configuration above I hope you are able to use and enjoy your Squid proxy server. Thank you.

Source: wingloon

quinta-feira, 20 de março de 2014

Configurando Squid Proxy com ClamAV Antivirus usando HAVP (HTTP Anti Virus Proxy)

HAVP (HTTP Anti Virus Proxy) is a non caching proxy which scans for viruses with ClamAV anti-virus scanner at the same time. The main aims are continuous, non-blocking downloads and smooth scanning of dynamic and password protected HTTP traffic. It can be used with squid or standalone, and it also supports transparent proxy mode.

HAVP (HTTP Anti Virus Proxy) features:
  * HTTP Antivirus proxy
  * Multiple scanner support at the same time
  * Scans complete incomming traffic
  * Nonblocking downloads
  * Smooth scanning of dynamic and password protected traffic
  * Can used with squid or other proxy
  * Parent proxy support
  * Transparent proxy support
  * Use Clamav (GPL antivirus)

Install HAVP
Open up the terminal and type following command to install HAVP:
sudo apt-get install havp
You can look at the detail configuration of HAVP under /etc/havp/havp.config file, most of the settings are fine with the default, finally start HAVP if it didn't start after the installation using following command:
/etc/init.d/havp start
It's ready, by default HAVP listens on port 8080. You can configure your web browser to use the server as a proxy.

Configure Squid to Use HAVP:
Once clamav and HAVP have been setup we need to setup squid to run with HAVP. edit the squid.conf file (/etc/squid/squid.conf) and add the following line
cache_peer 127.0.0.1 parent 8000 0 no-query no-digest no-netdb-exchange default
Finally, we need to start/restart all the services, from command line ..
/etc/init.d/havp start
/etc/init.d/clamd start
/etc/init.d/squid restart
Check here for quick start squid configuration under Ubuntu system


Read more: http://linuxpoison.blogspot.com.br/2010/12/configure-squid-proxy-with-clamav.html#more#ixzz2wVt9Q3pM

Bloqueando extensões mp3, mpg, mpeg, exe files usando Squid proxy server

First open squid.conf file /etc/squid/squid.conf:
# vi /etc/squid/squid.conf
Now add following lines to your squid ACL section:
acl blockfiles urlpath_regex “/etc/squid/multimedia.files.acl”
Now create the the file
# vi /etc/squid/multimedia.files.acl
\.[Ee][Xx][Ee]$
\.[Aa][Vv][Ii]$
\.[Mm][Pp][Gg]$
\.[Mm][Pp][Ee][Gg]$
\.[Mm][Pp]3$
Save and close the file and Restart Squid:
# /etc/init.d/squid restart


Read more: http://linuxpoison.blogspot.com.br/search?q=squid#ixzz2wVsLPzFf

Configurando o Squid para usar diferentes links de internet

SQUID is a powerful and fast object cache server. It proxies FTP and WWW sessions making it relatively safe. Squid would be very hard to use to actually compromise the system and runs as a non root user (typically 'nobody'), so generally it's not much to worry about. Your main worry with Squid should be improper configuration. For example, if Squid is hooked up to your internal network (as is usually the case), and the internet (again, very common), it could actually be used to reach internal hosts (even if they are using non-routed IP addresses). Hence proper configuration of Squid is very important.

The simplest way to make sure this doesn't happen is to use Squid's internal configuration and only bind it to the internal interface(s), not letting the outside world attempt to use it as a proxy to get at your internal LAN. In addition to this, firewalling it is a good idea. Fortunately Squid has very good ACL's (Access Control Lists) built into the squid.conf file, allowing you to lock down access by names, IP’s, networks, time of day, actual day. Remember however that the more complicated an ACL is, the slower Squid will be to respond to requests.

Example where requests from 10.0.0.0/24 will be forwarded with source address 10.1.0.1,

10.0.2.0/24 forwarded with source address 10.1.0.2 and the rest will be forwarded with source address 10.1.0.3.

acl abc src 10.0.0.0/24
acl xyz 10.0.2.0/24


tcp_outgoing_address 10.1.0.1 abc
tcp_outgoing_address 10.1.0.2 xyz
tcp_outgoing_address 10.1.0.3

This will prevent anyone from using Squid to probe your internal network.

Read more: http://linuxpoison.blogspot.com.br/search?q=squid#ixzz2wVs2zVKD

Usando autenticação NCSA no Squid

You can configure Squid to prompt users for a username and password. Squid comes with a program called ncsa_auth that reads any NCSA-compliant encrypted password file.

1) Create the password file. The name of the password file should be /etc/squid/squid_passwd, and you need to make sure that it’s universally readable.

# touch /etc/squid/squid_passwd
# chmod o+r /etc/squid/squid_passwd

2) Use the htpasswd program to add users to the password file. You can add users at anytime without having to restart Squid. In this case, you add a username called nikesh:

# htpasswd /etc/squid/squid_passwd nikeshNew
password:Re-type new password:
Adding password for user nikesh

3) Find your ncsa_auth file using the locate/find command. (different distro stores this file at different locations)

# locate ncsa_auth/usr/lib/squid/ncsa_auth

4) Edit squid.conf; specifically, you need to define the authentication program in squid.conf, which is in this case ncsa_auth. Next, create an ACL named ncsa_users with the REQUIRED keyword that forces Squid to use the NCSA auth_param method you defined previously. Finally, create an http_access entry that allows traffic that matches the ncsa_users ACL entry. Here’s a simple user authentication example; the order of the statements is important:

## Add this to the auth_param section of squid.conf

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd

# Add this to the bottom of the ACL section of squid.conf
acl ncsa_users proxy_auth REQUIRED

# Add this at the top of the http_access section of squid.conf
http_access allow ncsa_users

Remember to restart Squid for the changes to take effect.


Read more: http://linuxpoison.blogspot.com.br/search?q=squid#ixzz2wVrOOZ4q

sexta-feira, 20 de dezembro de 2013

Como fazer cache de vídeos no Squid

Como fazer cache de vídeos do youtube no Squid

Do ano passado pra cá, o crescimento de vídeos explodiu no mundo. Um problema notado, porém, foi que os vídeos não eram cacheados no squid.
Foram criadas várias ferramentas para de redirecionamento, com menor ou maior grau de sucesso.
Aqui no trabalho, testamos uma alternativa, adicionando as linhas
acl googlevideo dstdomain .googlevideo.com
cache allow googlevideo
acl youtube dstdomain .youtube.com
cache allow youtube

no arquivo /etc/squid/squid.conf e o problema foi resolvido.
Importante. Essas linhas devem estar acima dessas duas:
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY

A explicação é simples.
RFC 2616, que define o HTTP 1.1, diz que não deve entrar no cache todo recurso que tiver na resposta os cabeçalhos:
  • Cache-Control: no-cache;
  • Pragma: no-cache;
  • Cache-Control: no-store;
Porém, o squid, por padrão, também proíbe o armazenamento a todo conteúdo cujas URLs contenham as strings "cgi-bin" ou o sinal que delimita parâmetros, o "?" (sinal de interrogação). Nos dois casos, o squid considera que certamente o conteúdo é dinâmico, e sequer verifica os cabeçalhos HTTP.
Conforme testes, verificamos que os vídeos continham um cabeçalho de expiração de algumas horas, além de não conter instruções nos cabeçalhos para não guardá-los. O que fizemos foi inserir uma regra dizendo que não é pra descartar de cara o conteúdo de googlevideo.com e youtube.com. A regra foi colocada antes por questão de prioridade.
Pudemos, assim, cachear tranquilamente os vídeos, atentos a um pequeno detalhe. O recurso é definido pela URL de requisição, o cabeçalho Vary da resposta (quando existir) e a ETag. Assim, essas duas URL abaixo são entidades diferentes, pois não atendem ao primeiro quesito:
  • http://dominio.com.br/?a=1&b=2
  • http://dominio.com.br/?b=2&a=1
Se você for corajoso, pode aumentar o tempo de vida do recurso com orefresh_pattern. Se for mais corajoso ainda, retire as linhas referentes à ACL QUERY e passe a confiar nas instruções de cache de todos os servidores HTTP que entrar (o que não é tão má ideia assim).
Como última dica, deixo a de aumentar o parâmetro maximum_object_size, pois o padrão é de apenas 4 MB.



O resultado no log do squid foi o seguinte (substituí os IPs por falsos):
# tail -n 5000 /var/log/squid/access.log|grep googlevideo
1244065234.402 1478259 10.10.5.7 TCP_MISS/200 9944050 GET http://v2.lscache6.googlevideo.com/videoplayback? - ROUNDROBIN_PARENT/200.200.200.29 video/x-flv
1244065379.699 129413 10.10.5.8 TCP_MISS/200 1042113 GET http://v22.lscache1.googlevideo.com/videoplayback? - ROUNDROBIN_PARENT/200.200.200.28 video/x-flv
1244065640.822    167 10.10.5.7 TCP_HIT/200 1042121 GET http://v22.lscache1.googlevideo.com/videoplayback? - NONE/- video/x-flv
1244065709.024   1590 10.10.5.8 TCP_HIT/200 9944059 GET http://v2.lscache6.googlevideo.com/videoplayback? - NONE/- video/x-flv
UPDATE: Veja meu outro post sobre como resolver o problema da efetividade e fazer 100% de acerto nas requisições: Cache efetivo de vídeos do Youtube com Squid

Fonte: http://lucianopinheiro.net/

segunda-feira, 30 de setembro de 2013

SARG on CentOS 6

Usually, it's pretty hard to analyze information from the squid log file. For example, I don't know how to analyze date or number of hits from /var/log/squid/access.log. If someone needs to analyze which websites are being accessed from the network, SARG may be a very good tool. SARG, or Squid Analysis Report Generator (http://sarg.sourceforge.net) analyzes the log, and generates a web based table where one can easily analyze proxy traffic.

Although SARG can be installed using YUM, I have faced problems with CentOS 6. So, I went for tarball installation instead. And believe, it's really easy unlike many tarball installtions.

So, let's start:
[root@busy-bee2 ~]# yum install gcc make wget httpd
[root@busy-bee2 ~]# wget http://sourceforge.net/projects/sarg/files/sarg/sarg-2.3.1/sarg-2.3.1.tar.gz/download

[root@busy-bee2 ~]# tar zxvf sarg-2.3.1.tar.gz
[root@busy-bee2 ~]# cd sarg-2.3.1
[root@busy-bee2 ~]# ./configure
[root@busy-bee2 ~]# make
[root@busy-bee2 ~]# make install



Time to modify the conf file 
[root@busy-bee2 ~]# vim /usr/local/etc/sarg.conf



There are a lot of options, and it is always recommended to go through them. However, we'll be editing only the ones that we need.

#### sarg.conf####
access_log /var/log/squid/access.log
date_format e     ## since here we use date format DD-MM-YYYY
overwrite_report yes     ## because I don't want multiple sarg reports for the same day
output_dir /var/www/html/squid-reports


Time for a test run
[root@busy-bee2 ~]# sarg -x



We have used to the "-x" parameter for to view detail information on the run (used for debugging). If all goes well, there should be a report generated at/var/www/html/squid-reports directory which can be accessed from the web browser using the address http://IP/squid-reports


Sarg in Browser


Now, we'd be adding a scheduled task to run SARG at 02:30 everyday.

[root@busy-bee2 ~]# crontab -e

30 2 * * * sarg

[root@busy-bee2 ~]# service crond restart
[root@busy-bee2 ~]# chkconfig crond on




Troubleshooting
If there is problem viewing the SARG page, here are a few tips:
  1. Check whether the Firewall is blocking (iptables)
  2. Check if there is a file /etc/httpd/conf.d/sarg.conf. There is a line "allow from". Modify it to suit your needs.
  3. Verify  that there is directory "/var/www/html/squid-reports"

segunda-feira, 23 de abril de 2012

Não Fazer cache de determinados sites no SQUID


acl SITE dstdomain www.site.com.br
no_cache deny SITE
Ele não criará cache para os acesso feitos para o dominio www.site.com.br
Observe que no arquivo /var/log/squid/access.log, ele apresentará a seguinte mensagem “TCP_MISS” nas visitas consecutivas.

quinta-feira, 13 de outubro de 2011

Entendendo os Logs do Squid

TCP_HIT = Uma cópia válida do objeto pedido estava no cache.

TCP_MISS = O objeto pedido não estava no cache.
TCP_REFRESH_HIT = O objeto estava no cache, mas era antigo. Foi verificado e ele não foi alterado.
TCP_REF_FAIL_HIT = O objeto estava no cache, mas era antigo. O pedido para validar o objeto falhou, o objeto antigo foi retornado.
TCP_REFRESH_MISS = O objeto estava no cache, mas era antigo. Foi descarregado a cópia nova do objeto.
TCP_CLIENT_REFRESH = Foi uma requisisão com a meta tag “no-cache”.
TCP_CLIENT_REFRESH_MISS = O browser forçou o proxy a verificar para ver se há uma versão nova do objeto.
TCP_IMS_HIT = O browser ja tinha uma cópia válida do objeto.
TCP_IMS_MISS = Foi feita um requisisão para verificar se um objeto antigo tinha uma nova cópia.
TCP_SWAPFAIL = Era para o objeto estar no cache, mas não estava.
TCP_DENIED = A requisição foi negada.