Pertenece a Topic 208: Web Services

• Weight: 2
• Description: Candidates should be able to install and configure a proxy server, including access policies, authentication and resource usage.
• Key Knowledge Areas:
  • Squid 3.x configuration files, terms and utilities
  • Access restriction methods
  • Client user authentication methods
  • Layout and content of ACL in the Squid configuration files
• Terms and Utilities:
  • squid.conf
  • acl
  • http_access

Un servidor proxy se encarga de realizar una petición en nombre de un cliente a otro servidor mediante un protocolo determinado.

La mayoría de los proxys trabajan con el protocolo HTTP.

Si se habla de proxy sin concretar el protocolo aplicado, se trata de un proxy web (HTTP).

Ventajas:

• Protección a clientes: Los servidores proxy son el único camino válido para ir a Internet (en principio, cualquier cliente tiene que pasar por el proxy para obtener contenido proveniente de Internet). Están en la primera línea en caso de que se produzca un ataque desde el exterior.
• Servidores de caché: conserva en su disco una copia de los datos para responder al resto de clientes mas rápido.
• Filtrado: ofrecen la posibilidad de rechazar parte o la totalidad de sus peticiones.

Inconvenientes:

• Requiere una configuración especifica de los clientes.
• Se limitan a la capa de aplicación. Es decir, para utilizarlo, debemos especificar el proxy. Por ejemplo, si lo queremos usar en nuestro navegador web, le tendremos que indicar dónde se encuentra el proxy para que lo use.

Es el proxy más conocido en Linux.

El fichero de configuración se ubica en /etc/squid/squid.conf

Por defecto, un servidor proxy squid actúa de servidor caché.

Toda la configuración se basa en reglas de varios tipos que debemos ir declarando.

Configuración básica de un proxy squid:

http_port <numero_de_puerto>
cache_dir ufs <directorio> <tamaño> <dir_nivel_1>, <dir_nivel_2>
visible_hostname <nombre_servidor>

La recomendación es crear una configuración de cero. Podemos cambiar de nombre la original de squid.conf a squid.conf.old.

Ejemplo de configuración básica:

http_port 3128
cache_dir ufs /var/squid 300M 16, 256
visible_hostname miproxy

El fichero se configura en dos partes: primero las ACLs y luego las directivas de configuración.

Una de las cosas más interesantes que tiene squid es poder definir qué máquinas pueden acceder a ciertos recursos o salir a Internet.

Definición de los hosts o conjuntos de hosts (grupos, redes) al que se aplicará la autorización. Estos grupos se crean con el nombre de ACL (Access Control List).

acl nombre_lista tipo_acl A.B.C.D/M

• nombre_lista: nombre de la lista creada. Valor alfanumérico cualquiera.
• tipo_acl:
  • src: definición de direcciones origen (las máquinas de la red local)
  • dst: definición de direcciones destino
• A.B.C.D/M:
  • Dirección de red y máscara de subred (número de bits de la máscara)
  • Dirección de host y máscara de subred (número de bits de la máscara)
  • Intervalo de direcciones: A.B.C.D-E.F.G.H/M (número de bits a 1 de la máscara)

Ejemplo de definición de ACLs:

acl all src all
acl red_local src 192.168.1.0/24
acl servidores_prohibidos dst 172.11.5.2-172.11.5.5./24

Una vez definidos esos ACL, hay decirle a squid qué tiene que hacer con estas acls:

http_access <autorizacion> <nombre_acl>

• autorizacion: autorización o denegación de la acl. Los dos valores posibles son allow y deny
• nombre_acl: el nombre de la lista que se autoriza o se deniega.

Ejemplo de autorización de ACLs:

acl all src all
acl red_local src 192.168.1.0/24
acl servidores_prohibidos dst 172.11.5.2-172.11.5.5/24
http_access deny servidores_prohibidos
http_access allow red_local
http_access deny all

Estaríamos diciendo que nadie podrá conectarse a servidores_prohibidos, todos los equipos de red_local podrán conectarse a Internet. Todos los demás no se podrán conectar a Internet.

acl nombre_acl "archivo_acl"

La configuración se aplicará reiniciando squid:

service squid restart

En squid podemos plantear la necesidad de autenticación para acceder a determinados recursos. Para eso utilizamos las reglas authenticate_program (para especificar el programa) y proxy_auth (activar autenticación)

Dichas reglas nos permiten acudir a un motor de autenticación externo a squid, que valorará si se trata de un usuario válido.

Podemos usar sistemas como LDAP, Samba, SASL, PAM y muchos más.

authenticate_program /sbin/my_auth -f /etc/my_auth.db
acl red_local proxy_auth REQUIRED
http_access allow red_local

• authenticate_program indica el programa que se utiliza para la autenticación y le podemos pasar el fichero que contiene la información de los usuarios
• acl red_local proxy_auth REQUIRED: indica que los usuarios del grupo name necesitan autenticarse.
• http_access allow red_local: cuando los usuarios del grupo name se hayan autenticado correctamente, podrán acceder a Internet.

Todo lo que suceda referente a squid se almacena en /var/log/squid/:

• access.log: registro de todo lo que suceda con squid.
• cache.log
• squid.out: errores

Para usar el proxy, hay que configurar los equipos cliente para que utilicen ese proxy indicando la IP y puerto en el que trabaja.

Hay que tener en cuenta que existen los proxies transparentes donde es un router el que redirige el tráfico http y https hacia otra máquina que hace de proxy. En este caso, no hay que configurar nada en los equipos cliente.

sarg genera informes HTML en base a los registros de squid permitiendo ver de forma cómoda por dónde han navegado los usuarios.

Para generar el informe:

sarg -x