Mey Online

Cuando utilizamos control de contenido anteponiendo Dansguardian a nuestro proxy Squid nos vemos con el problema de que todas las conexiones que registra el proxy son provenientes del mismo servidor.

En el caso de tener implementadas políticas de filtrado mediante las ACL basándonos en la IP del cliente, estas ACL’s no tendrán efecto ya que todas las conexiones provienen de la interfaz de loopback (127.0.0.1) o de la IP del servidor que corra el filtro, en el caso de ser un equipo aparte.

Para que Squid pueda detectar la ip original de cliente es necesario utilizar la cabecera x-forwarded-for. Esta cabecera tiene un formato como el siguiente:

x-forwarded-for: ip_cliente, ip_proxy1, ip-proxy2

Sumado al hecho de que http se transmite en texto plano, la cabecera contiene información de nuestra red lo cual puede ser peligroso que se reenvíe esta cabecera a Internet. Para evitar este punto débil en nuestra red simplemente se habilitará Squid para leer la cabecera pero no incluirla en las conexiones salientes.

Habilitación

Los usuarios de Debian Lenny no deberán realizar ninguna tarea para habilitar el uso de las cabeceras x-forwarderd-for. Si no estas seguro si la versión instalada de Squid tiene habilitada la opción follow-x-forwarded-for puedes verificarlo con:

squid -v

En caso de no figurar habilitada puedes seguir estos pasos.

Configuración

Dentro de la configuración de Squid es necesario informar que vamos a leer las cabeceras y utilizar la IP original para las listas de acceso y, gracias a esto, no deberíamos cambiar nada de las reglas aplicadas mediante ACL’s.

Las opciones a utilizar son:

follow_x_forwarded_for

Se utiliza para habilitar o no la lectura de las cabeceras. Debemos pasarle como parámetro la ip del filtro. Para el caso de un unico filtro corriendo en el mismo servidor que Squid:

acl localhost src 127.0.0.1 #Esta linea deberia estar en algun lado
follow_x_forwarded_for allow localhost

acl_uses_indirect_client

Una vez habilitada la lectura de las cabeceras le indicamos que la IP que va a leer y utilizar para machear las ACL sea la primer IP (en teoría la IP verdadera del cliente o ‘indirecta’).

acl_uses_indirect_client on

log_uses_indirect_client

De la misma manera, indicamos que las IPs que se guardan en el log sean las indirectas. Con esto podemos analizar los logs sin que todo el tráfico figure de localhost.

log_uses_indirect_client on

delay_pool_uses_indirect_client

Lo mismo para las listas de retardo.

delay_pool_uses_indirect_client on

Como comentaba anteriormente, es recomendable que, en el caso de que el servidor Squid que estamos configurando sea el que se conecta a internet para servir las páginas a la red local, se deshabilite la inclusión de la IP del sistema dentro de la cabecera. Para esto utilizamos la opción:

forwarded_for

Indica si debe escribirse la IP del sistema dentro de la cabecera x-forwarded-for.

forwarded_for off

Logs de navegación

Si bien depende de que filtro estemos utilizando (sarg tiene soporte para generar los reportes a partir de Dansguardian, Squidguard o el mismo Squid) los cambios que hemos realizado posibilitan seguir utilizando el mismo analizador sin cambiar nada.

Yo utilizo Dansguardian y lo configuro para que los reportes sean en formato de Squid y asi levantarlos con Sarg.

This entry was posted on Wednesday, March 18th, 2009 at 11:34 am and is filed under Informática, Linux, MS Exchange, Seguridad. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.