Google
Web dns.bdat.net

Concepto de ACL en Squid

Un ACL es una definición de control de acceso, que en Squid se especifica mediante el parámetro acl según la siguiente sintaxis:

acl nombre_acl tipo_acl descripción ...

acl nombre_acl tipo_acl "fichero_de_descripciones" ...

Cuando usamos un "fichero_de_descripciones", cada descripción se corresponde con una línea del fichero.

Tipos de ACL

src

Especifica una dirección origen de una conexión en formatio IP/máscara.

Por ejemplo, utilizaremos una acl de tipo src para especificar la red local:

acl red_local src 192.168.1.0/24

También podemos especificar rangos de direcciones mediante una acl de tipo src:

acl jefes src 192.168.1.10-192.168.1.25/32

dst

Especifica una dirección destino de una conexión en formatio IP/máscara.

acl google_es dst 216.239.0.0/24

También podemos especificar hosts concretos mediante una acl de tipo dst:

acl google_es2 dst 216.239.59.104/32 216.239.39.104/32 216.239.57.104/32

Las definiciones son idénticas a las acl de tipo src salvo que se aplican al destino de las conexiones, no al origen.

srcdomain y dstdomain

Estos tipos de acl especifican un nombre de dominio.

En el caso de srcdomain es el dominio origen y se determina por resolución DNS inversa de la IP de la máquina, es decir, tendremos que tener bien configurado el DNS de la red local.

En el caso de dstdomain el nombre del dominio se comprueba con el dominio que se haya especificado en la petición de página web.

Por ejemplo:

acl google_com dstdomain google.com

srcdom_regex y dstdom_regex

Especifican una expresión regular que verifican los dominio origen o destino. La expresión regular hace distinción entre mayúsculas y minúsculas salvo que incluyamos la oción "-i" que evita dicha distinción.

Por ejemplo

acl google_todos dstdom_regex -i google\..*

Observamos como al incluir "-i" estamos indicando que no haga distinción entre mayúsculas y minúsculas.

time

Este tipo de acl perimite especificar una franja horaria concreta dentro de una semana. La sintaxis es la siguientes

acl nombre_acl_horaria time [dias-abrev] [h1:m1-h2:m2]

Donde la abreviatura del día es:

S - Sunday (domingo)

M - Monday (lunes)

T - Tuesday (martes)

W - Wednesday (miércoles)

H - Thursday (jueves)

F - Friday (viernes)

A - Saturday (sábado)

además la primera hora especificada debe ser menor que la segunda, es decir h1:m1 tiene que ser menor que h2:m2

Por ejemplo

acl horario_laboral time M T W H F 8:00-15:00

Estarímos especificando un horario de 8 a 15 y de lunes a viernes.

url_regex

Permite especificar expresiones regulares para comprobar una url completa, desde el https:// inicial.

Por ejemplo, vamos a establecer una acl que se verifique con todos los servidores cuyo nombre sea adserver:

url_regex serv_publicidad ^https://adserver.*

En otro ejemplo podemos ver una acl que verifique las peticiones de ficheros mp3:

url_regex ficheros_mp3 -i mp3$

Nota: ver expresiones regulares

referer_regex

Define una acl que se comprueba con el enlace que se ha pulsado para acceder a una determinada página. Cada petición de una página web incluye la dirección donde se ha pulsado para acceder. Si escribimos la dirección en el navegador entonces estaremos haciendo una petición directa.

Por ejemplo vamos a establecer uan acl para todas las páginas a las que hayamos accedido pulsando en una ventana de búsqueda de google:

acl pincha_google referer_regex https://wwww.google.*

req_mime

Las acl de tipo req_mime se utilizan para comprobar el tipo de petición mime que realiza un cliente, y se puede utilzar para detectar ciertas descargas de ficheros o ciertas peticiones en túneles HTTP.

Esta acl sólo comprueba las peticiones que realiza el cliente, no comprueba la respuesta del servidor. Esto es importante para tener claro qué estamos haciendo y qué no.

Por ejemplo

acl subida req_mime_type -i ^multipart/form-data$

acl javascript req_mime_type -i ^application/x-javascript$

acl estilos req_mime_type -i ^text/css$

acl audiompeg req_mime_type -i ^audio/mpeg$

rep_mime_type

Este tipo de acl se utiliza para verificar el tipo de respuesta recibida por el proxy. Este tipo de acl, analiza una respuesta del servidor por lo que sólo le afectas las reglas de respuesta como http_reply_access y no las reglas http_access que se aplican a las peticiones.

Por ejemplo

acl javascript rep_mime_type -i ^application/x-javascript$

acl ejecutables rep_mime_type -i ^application/octet-stream$

acl audiompeg rep_mime_type -i ^audio/mpeg$

Ejemplos de ACL

acl todos

Una acl que verifica todos los equipos de la red. Puede parecer un poco tonta, pero se va a utilizar posteriormente para establecer una politica preestablecida para denegarlo o aceptarlo todo.

acl todos src 0.0.0.0/0.0.0.0

acl localhost

Nuestra propia maquina como origen de conexiones

acl localhost src 127.0.0.1/255.255.255.255

Nuestra propia máquina como destino de las conexiones

acl localhost_destino dst 127.0.0.0/8

http_access

Este es el parámetro que permite o deniega accesos a una o más acl.

La sintaxis de uso es:

http_access allow|deny [!]acl ...

Observamos como cada acl puede ir precedida por un signo "!" que indicaría que la acl no se verifica.

Por ejemplo, para permitir acceso fuera del horario laboral, según una acl que definimos anteriormente:

http_access allow ! horario_laboral

Para denegar el acceso en horario laboral

http_access deny horario_laboral

Para dar acceso completo a la red local

http_access allow red_local

Características de http_access

Si no hay ninguna línea de acceso la acción predeterminada es denegar la petición.

Si una petición no ha verificado ninguna línea de acceso, la ación que se realiza es la opuesta a la última línea de la lista. Si la última línea deniega entonces el valor predeterminado es permitir. Por este motivo es conveniente incluir una línea "deny all" o "allow all" al final de las listas de accesos para tener las cosas claras.

Es importante la forma en la cual añadimos los distinto parámetros http_access para determinar la forma en la que se comprueba. En primer lugar, todas las acl incluidas en en una cláusula http_access se comprueban y todas ellas tendrán que verificarse conjuntamente, es decir, como si estuvieran unidas por un operador AND. Después, los sucesivos parámetros http_access se evalúan individualmente, es decir, como si estuvieran unidos mediante un operador OR.

Por ejemplo

acl red1 src 192.168.0.0/24

acl red2 src 192.168.1.0/24

http_access allow red1 red2

permitiría el acceso a todas aquellas conexiones que procedieran a la vez de red1 y de red2, que probablemente no es lo que pretendemos. Para permitir acceso a las dos redes podríamos:

acl red1 src 192.168.0.0/24

acl red2 src 192.168.1.0/24

http_access allow red1

http_access allow red2

o también, de forma más simple:

acl redes src 192.168.0.0/24 192.168.1.0/24

http_access allow redes

Ejemplos de Acl y http_access

Denegar las peticiones de ficheros de tipo exe, pif, bat y cmd

acl tipoexe url_regex -i exe$ pif$ bat$ cmd$

http_access deny tipoexe

Denegar el acceso a todos los servidores cuyo nombre comience por "popup", "banner" o "ads"

acl incordios url_regex https://popup.* https://ads.* https://ads.*

http_access deny incordios

Denegar todos los ficheros de tipo exe que provengan de virus_fijo.com

acl anti_exe url_regex -i exe$

acl vfijo dstdomain virus_fijo.com

http_access deny anti_exe vfijo

Denegar las conexiones a las url completas o incompletas que hay en el fichero "/etc/squid/lista_negra_1.txt"

acl ln1 url_regex "/etc/squid/lista_negra_1.txt"

http_access deny ln1