Resultados 1 al 5 de 5

Tema: Cómo montar un firewall por software

  1. #1
    Senior Member Avatar de Carlitoxx
    Fecha de ingreso
    12 oct, 05
    Ubicación
    Con l@s Wambin@s!
    Edad
    41
    Mensajes
    4,384

    Cómo montar un firewall por software

    Buenas,

    Ayer me dio la vena y he decidido cambiar la organización de los pcs en casa, de tal manera que utilizaré el pc más viejo para montar sobre él un firewall por software, y un servidor proxy.

    Para ello le pondré dos tarjetas de red, una directa al router y la otra hacia el switch de mi LAN.

    Sé que algunos (uno de seguro :P) ya habéis implementado algo parecido, por lo que agradecería toda la ayuda que me ofrezcáis.

    El firewall y el servidor proxy lo montaré sobre un PIII a 500, instalando un Ubuntu Server, junto con Squid y Shorewall.

    Buscando manuales acerca de Shorewall me he encontrado con lo siguiente, lo cual creo que está muy completo.

    Autor: Joel Barrios Dueñas
    Correo electrónico: jbarrios arroba linuxparatodos punto net
    Sitio de Red: http://www.linuxparatodos.net/


    Introducción.
    Acerca de Shorewall.

    Shorewall (Shoreline Firewall) es una robusta y extensible herramienta de alto nivel para la configuración de muros cortafuego. Shorewall solo necesita se le proporcionen algunos datos en algunos ficheros de texto simple y éste creará las reglas de cortafuegos correspondientes a través de iptables. Shorewall puede permitir utilizar un sistema como muro cortafuegos dedicado, sistema de múltiples funciones como puerta de enlace, dispositivo de encaminamiento y servidor.

    URL: http://www.shorewall.net/
    Acerca de Iptables y Netfilter.

    Netfilter es un conjunto de ganchos (Hooks, es decir, técnicas de programación que se emplean para crear cadenas de procedimientos como manejador) dentro del núcleo de GNU/Linux y que son utilizados para interceptar y manipular paquetes de red. El componente mejor conocido es el cortafuegos, el cual realiza procesos de filtración de paquetes. Los ganchos son también utilizados por un componente que se encarga del NAT (acrónimo de Network Address Translation o Traducción de dirección de red). Estos componentes son cargados como módulos del núcleo.

    Iptables es el nombre de la herramienta de espacio de usuario (User Space, es decir, área de memoria donde todas las aplicaciones, en modo de usuario, pueden ser intercambiadas hacia memoria virtual cuando sea necesario) a través de la cual los administradores crean reglas para cada filtrado de paquetes y módulos de NAT. Iptables es la herramienta estándar de todas las distribuciones modernas de GNU/Linux.

    URL: http://www.netfilter.org/
    Acerca de Iproute.


    Iproute es una colección de herramientas (ifcfg, ip, rtmon y tc) para GNU/Linux que se utilizan para controlar el establecimiento de la red TCP/IP, así como también el control de tráfico. Aunque ifconfig sigue siendo la herramienta de configuración de red estándar en las distribuciones de GNU/Linux, iproute tiende a sustituirlo al proveer soporte para la mayoría de las tecnologías modernas de red (incluyendo IP versiones 4 y 6), permitiendo a los administradores configurar los parámetros de red y el control de tráfico.

    URL: http://linux-net.osdl.org/index.php/Iproute2

    Requisitos.

    • Un sistema GNU/Linux con todos los parches de seguridad correspondientes instalados.
    • Shorewall 3.0.8 o versiones posteriores.
    • Tres interfaces de red:
    • Interfaz para acceso hacia Internet.
    • Interfaz para acceso hacia una DMZ, tras la cual se podrán colocar servidores.
    • Interfaz para acceso hacia la LAN (acrónimo de Local Area Network o Área de Red Local).


    Conceptos requeridos.

    ¿Qué es una zona desmilitarizada?


    Una zona desmilitarizada (DMZ), es parte de una red que no está dentro de la red interna (LAN) pero tampoco está directamente conectada hacia Internet. Podría resumirse como una red que se localiza entre dos redes. En términos más técnicos se refiere a un área dentro del cortafuegos donde los sistemas que la componen tienen acceso hacia las redes interna y externa, sin embargo no tienen acceso completo hacia la red interna y tampoco acceso completamente abierto hacia la red externa. Los cortafuegos y dispositivos de encaminamiento (routers) protegen esta zona con funcionalidades de filtrado de tráfico de red.



    Diagrama de una Zona Desmilitarizada.
    Imagen de dominio público tomada de Wikipedia y modificada con el Gimp.


    ¿Que es una Red Privada?

    Una Red Privada
    es aquella que utiliza direcciones IP establecidas en el RFC 1918. Es decir, direcciones IP reservadas para Redes Privadas dentro de los rangos 10.0.0.0/8 (desde 10.0.0.0 hasta 10.255.255.255), 172.16.0.0/12 (desde 172.16.0.0 hasta 172.31.255.255) y 192.168.0.0/16 (desde 192.168.0.0 hasta 192.168.255.255).

    ¿Qué es un NAT?

    NAT
    (acrónimo de Network Address Translation o Traducción de dirección de red), también conocido como enmascaramiento de IP, es una técnica mediante la cual las direcciones de origen y/o destino de paquetes IP son reescritas mientras pasan a través de un dispositivo de encaminamiento (router) o muro cortafuegos. Se utiliza para permitir a múltiples anfitriones en una Red Privada con direcciones IP para Red Privada para acceder hacia una Internet utilizando una sola dirección IP pública.

    ¿Qué es un DNAT?

    DNAT
    , (acrónimo de Destination Network Address Translation o traducción de dirección de red de destino) es una técnica mediante la cual se hace público un servicio desde una Red Privada. Es decir permite redirigir puertos hacia direcciones IP de Red Privada. El uso de esta técnica puede permitir a un usuario en Internet alcanzar un puerto en una Red Privada (dentro de una LAN) desde el exterior a través de un encaminados (router) o muro cortafuegos donde ha sido habilitado un NAT.

    Procedimientos.
    Sustento lógico necesario.

    • iptables: Controla el código del núcleo de GNU/Linux para filtración de paquetes de red.
    • iproute: Conjunto de utilidades diseñadas para utilizar las capacidades avanzadas de gestión de redes del núcleo de GNU/Linux.
    • shorewall: Shoreline Firewall.


    Shorewall puede descargarse en formato RPM desde http://www.shorewall.net/.

    Fichero de configuración /etc/shorewall/shorewall.conf

    En éste se definen, principalmente, dos parámetros. STARTUP_ENABLED y CLAMPMSS.

    STARTUP_ENABLED se utiliza para activar Shorewall. De modo predefinido está desactivado, solo basta cambiar No por Yes.STARTUP_ENABLED=Yes


    CLAMPMSS se utiliza en conexiones tipo PPP (PPTP o PPPoE) y sirve para limitar el MSS (acrónimo de Maximum Segment Size que significa Máximo Tamaño de Segmento). Cambiando el valor No por Yes, Shorewall calculará el MSS más apropiado para la conexión. Si se es osado, puede también especificarse un número en paquetes SYN. La recomendación es establecer Yes si se cuenta con un enlace tipo PPP.CLAMPMSS=Yes

    Fichero de configuración /etc/shorewall/zones

    Este fichero se utiliza para definir las zonas que se administrarán con Shorewall y el tipo de zona (firewall, ipv4 o ipsec). La zona fw está presente en el fichero /etc/shorewall.conf como configuración predefinida. En el siguiente ejemplo se registrarán las zonas de Internet (net), Red Local (loc) y Zona Desmilitarizada (dmz):
    #ZONE DISPLAY OPTIONS
    fw firewall
    net ipv4
    loc ipv4
    dmz ipv4
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Fichero de configuración /etc/shorewall/interfaces

    En éste se establecen cuales serán las interfaces para las tres diferentes zonas. Se establecen las interfaces que corresponden a la Internet, Zona Desmilitarizada DMZ y Red Local. En el siguiente ejemplo, se cuenta con una interfaz ppp0 para acceder hacia Internet, una interfaz eth0 para acceder hacia la LAN y una interfaz eth1 para acceder hacia la DMZ, y en todas se solicita se calcule automáticamente la dirección de transmisión (Broadcast):
    #ZONE INTERFACE BROADCAST OPTIONS GATEWAY
    net ppp0 detect
    loc eth0 detect
    dmz eth1 detect
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo, se cuenta con una interfaz eth0 para acceder hacia Internet, una interfaz eth1 para acceder hacia la LAN y una interfaz eth2 para acceder hacia la DMZ, y en todas se solicita se calcule automáticamente la dirección de transmisión (Broadcast):
    #ZONE INTERFACE BROADCAST OPTIONS GATEWAY
    net eth0 detect
    loc eth1 detect
    dmz eth2 detect
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Hay una cuarta zona implícita que corresponde al cortafuegos mismo y que se denomina fw.

    Si acaso hubiera un servicio de DHCP, sea como cliente, como servidor o como intermediario, en alguna de las interfaces, se debe añadir la opción dhcp para permitir la comunicación requerida para este servicio. En el siguiente ejemplo el anfitrión donde opera el muro cortafuegos obtiene su dirección IP, para la interfaz ppp0, a través del servicio DHCP del ISP; en este mismo anfitrión opera simultáneamente un servidor DHCP, el cual es utilizado en la red de área local para asignar direcciones IP; por todo lo anterior se debe activar la opción DHCP para las interfaces ppp0 y eth1, que correspondientemente son utilizadas por la zona de Internet y la red de área local, pero no es necesario hacerlo para la interfaz eth2 que es utilizada para la zona de la DMZ:
    #ZONE INTERFACE BROADCAST OPTIONS GATEWAY
    net ppp0 detect dhcp
    loc eth1 detect dhcp
    dmz eth2 detect
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Fichero de configuración /etc/shorewall/policy

    En este fichero se establece como se accederá desde una zona hacia otra y hacia la zona de Internet.
    #SOURCE DEST POLICY LOG LIMIT:BURST
    loc net ACCEPT
    dmz net ACCEPT
    fw net ACCEPT
    net all DROP info
    all all REJECT info
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Lo anterior hace lo siguiente:
    1. La zona de la red local puede acceder hacia la zona de Internet.
    2. La zona de la DMZ puede acceder hacia la zona de Internet.
    3. El cortafuegos mismo puede acceder hacia la zona de Internet.
    4. Se impiden conexiones desde Internet hacia el resto de las zonas.
    5. Se establece una política de rechazar conexiones para todo lo que se haya omitido.


    Todo lo anterior permite el paso entre las diversas zonas hacia Internet, lo cual no es deseable si se quiere mantener una política estricta de seguridad. La recomendación es cerrar todo hacia todo e ir abriendo el tráfico de acuerdo a como se vaya requiriendo. Es decir, utilizar algo como lo siguiente:
    #SOURCE DEST POLICY LOG LIMIT:BURST
    net all DROP info
    all all REJECT info
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Lo anterior bloquea todo el tráfico desde donde sea a donde sea. Si es necesario realizar pruebas de diagnóstico desde el cortafuegos hacia Internet para probar conectividad y acceso hacia diversos protocolos, se puede utilizar lo siguiente:
    #SOURCE DEST POLICY LOG LIMIT:BURST
    fw net ACCEPT
    net all DROP info
    all all REJECT info
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Lo anterior permite al propio cortafuegos acceder hacia la zona de Internet. Esta sería la política más relajada que se pudiera recomendar para mantener un nivel de seguridad aceptable.


    Fichero de configuración /etc/shorewall/masq

    Se utiliza para definir que a través de que interfaz o interfaces se habilitará enmascaramiento, o NAT, y para que interfaz o interfaces o redes se aplicará dicho enmascaramiento. En el siguiente ejemplo, se realizará enmascaramiento a través de la interfaz ppp0 para las redes que acceden desde las interfaces eth0 y eth1:
    #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
    ppp0 eth0
    ppp0 eth1
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo, se realizará enmascaramiento a través de la interfaz eth0 para las redes 192.168.0.0/24 y 192.168.1.0/24:
    #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
    eth0 192.168.0.0/24
    eth0 192.168.1.0/24
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    También es posible hacer NAT solamente hacia una IP en particular y para un solo protocolo en particular. En el siguiente ejemplo se hace NAT a través de la interfaz ppp0 para la dirección 192.168.3.25 que accede desde la interfaz eth1 y solo se le permitirá hacer NAT de los protocolos smtp y pop3. Los nombres de los servicios se asignan de acuerdo a como estén listados en el fichero /etc/services.
    #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
    ppp0 eth1 192.168.3.25 tcp 25,110
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Fichero de configuración /etc/shorewall/rules

    Todos los puertos están cerrados de modo predefinido, y es en este fichero donde se habilitan los puertos necesarios. Hay diversas funciones que pueden realizarse.
    ACCEPT

    La acción ACCEPT se hace para especificar si se permiten conexiones desde o hacia una(s) zona (s) un protocolo(s) y puerto(s) en particular. En el siguiente ejemplo se permiten conexiones desde Internet hacia el puerto 80 (www), 25 (smtp) y 110 (pop3). Los nombres de los servicios se asignan de acuerdo a como estén listados en el fichero /etc/services.
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    ACCEPT net fw tcp 80,25,110
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    REDIRECT

    La acción REDIRECT permite redirigir peticiones hacia un puerto en particular. Muy útil cuando se quieren redirigir peticiones para HTTP (puerto 80) y se quiere que estas pasen a través de un Servidor Intermediario (Proxy) como Squid. En el siguiente ejemplo las peticiones hechas desde la red local y desde la DMZ serán redirigidas hacia el puerto 8080 del cortafuegos, en donde hay un Servidor Intermediario (Proxy) configurado de modo transparente.
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    REDIRECT loc 8080 tcp 80
    REDIRECT dmz 8080 tcp 80
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    DNAT

    La acción DNAT se utiliza para reenviar peticiones desde un puerto del cortafuegos hacia una IP y puerto en particular tanto en la red local como en la DMZ. Cabe destacar que para que el DNAT funcioné se necesita que:
    • Esté habilitado el reenvío de paquetes en /etc/sysconfig/sysctl.cfg y /etc/shorewall/shorewall.conf
    • Los equipos hacia los que se esté haciendo DNAT utilicen como puerta de enlace al cortafuegos desde sus correspondientes zonas.


    En el siguiente ejemplo, se hace DNAT desde la zona de Internet para HTTP (puerto 80), SMTP (puerto 25) y POP3 (puerto 110) por TCP y DNS (puerto 53) por TCP y UDP hacia la IP 10.10.10.28 localizada en la zona de la Red Local.
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    DNAT net dmz:10.10.10.28 tcp 80,25,110,53
    DNAT net dmz:10.10.10.28 udp 53
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Ejemplos diversos de reglas.

    En el siguiente ejemplo se permite a la zona de Red Local el acceso hacia el puerto 22 (SSH) de cualquier equipo dentro de la DMZ:
    #ACTION SOURCE DEST PROTO DEST PORT
    ACCEPT loc dmz tcp 22
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo se permite solo a la dirección 192.168.2.34 de zona de Red Local el acceso hacia el puerto 22 (SSH) de cualquier equipo dentro de la DMZ:
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    ACCEPT loc:192.168.2.34 dmz tcp 22
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo se permite solo a la dirección 192.168.2.34 de zona de Red Local el acceso hacia el puerto 22 (ssh) de la dirección 10.10.10.5 que está dentro de la DMZ:
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    ACCEPT loc:192.168.2.34 dmz:10.10.10.5 tcp 22
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo se hace DNAT desde la zona de Internet para los servicios de HTTP (puerto 80), SMTP (puerto 25) y POP3 (puerto 110) por TCP y DNS (puerto 53) por TCP y UDP hacia diversos servidores localizados DMZ:
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    DNAT net dmz:10.10.10.1 tcp 80
    DNAT net dmz:10.10.10.2 tcp 25,110
    DNAT net dmz:10.10.10.3 tcp 53
    DNAT net dmz:10.10.10.3 udp 53
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo se hace DNAT desde la zona de la Red Local para los servicios de HTTP (puerto 80), SMTP (puerto 25), POP3 (puerto 110) y DNS (puerto 53) hacia diversos servidores localizados DMZ:
    #ACTION SOURCE DEST PROTO DEST
    # PORT
    DNAT loc dmz:10.10.10.1 tcp 80
    DNAT loc dmz:10.10.10.2 tcp 25,110
    DNAT loc dmz:10.10.10.3 tcp 53
    DNAT loc dmz:10.10.10.3 udp 53
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo se hace DNAT desde la zona de Internet para los servicios de HTTP (puerto 80), SMTP (puerto 25), POP3 (puerto 110) y DNS (puerto 53) hacia diversos servidores localizados DMZ y limitar la taza de conexiones a diez por segundo con ráfagas de hasta cinco conexiones para cada servicio:
    #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
    # PORT PORT(S) DEST LIMIT
    DNAT net dmz:10.10.10.1 tcp 80 - - 10/sec:5
    DNAT net dmz:10.10.10.2 tcp 25,110 - - 10/sec:5
    DNAT net dmz:10.10.10.3 tcp 53 - - 10/sec:5
    DNAT net dmz:10.10.10.3 udp 53 - - 10/sec:5
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    En el siguiente ejemplo las peticiones hechas desde la red local (LAN) serán redirigidas hacia el puerto 8080 del cortafuegos, en donde hay un Servidor Intermediario (Proxy) configurado de modo transparente, limitando la taza de conexiones a diez por segundo con ráfagas de hasta cinco conexiones. Esto es muy útil para evitar ataques de DoS (acrónimo de Denial of Service que se traduce como Denegación de Servicio) desde la red local (LAN).
    #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
    # PORT PORT(S) DEST LIMIT
    REDIRET loc 8080 tcp 80 - - 20/sec:5
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Iniciar el cortafuegos y añadirlo a los servicios de arranque del sistema

    Para ejecutar por primera vez el servicio, utilice:service shorewall start


    Para hacer que los cambios hechos a la configuración surtan efecto, utilice:service shorewall restart


    Para detener el cortafuegos, utilice:service shorewall stop


    Cabe señalar que detener el cortafuegos también detiene todo tráfico de red, incluyendo el tráfico proveniente desde la LAN. Si se desea restaurar el tráfico de red, sin la protección de un cortafuegos, será necesario también utilizar el guión de iptables.service iptables stop


    Lo más conveniente, en caso de ser necesario detener el cortafuegos, es definir que direcciones IP o redes podrán continuar accediendo cuando el cortafuegos es detenido, o cuando éste se encuentra en proceso de reinicio. Esto se define en el fichero /etc/shorewall/routestopped, definiendo la interfaz, a través de la cual se permitirá la comunicación, y la dirección IP o red, en un formato de lista separada por comas, de los anfitriones que podrán acceder al cortafuegos. Ejemplo:
    #INTERFACE HOST(S) OPTIONS
    eth0 192.168.1.0/24
    eth0 192.168.2.30,192.168.2.31
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE


    Para añadir Shorewall al arranque del sistema, utilice:chkconfig shorewall on


  2. #2
    Senior Member Avatar de Rotty
    Fecha de ingreso
    23 sep, 05
    Ubicación
    Around the World!
    Edad
    43
    Mensajes
    4,768

    Re: Cómo montar un firewall por software

    Como me he sentido aludido...DD, respondo:
    Yo he implementado dicha software en la empresa en la cual trabajo.El soft que he utilizado es el siguiente:
    - Ubuntu Server i386 6.10.
    - Bind (DNS Server)
    - Squid (Proxy Server)
    - Dansguardian (Proxy Safe Server & Filter)
    - Shorewall (Firewall).
    La implementación ha sido sobre el siguiente equipo:
    - PIII-450
    - SDRAM 512Mb 133Mhz
    - HD 20Gb
    - 3x Tarjetas Red (3Com)

    Los resultados han sido más q optimos, consiguiendo las siguientes cosas:
    - Salida ha internet filtrada.
    - Separar zonas de red.
    - Securizar la red.

    Los archivos de configuración más importantes en la configuración de shorewall son:
    - zones
    - policy
    - rules
    - interfaces

    De todas formas, el manual q has puesto explica bastante bien el proceso para implementar dicho soft.
    Aún así, yo tengo una maquina virtual con vmware con todo ya cargado y configurado.
    Si alguno lo quiere q lo diga y le paso la maquina virutual.
    Un saludo.

  3. #3
    Senior Member Avatar de Carlitoxx
    Fecha de ingreso
    12 oct, 05
    Ubicación
    Con l@s Wambin@s!
    Edad
    41
    Mensajes
    4,384

    Re: Cómo montar un firewall por software

    Hombre, ya sabes que lo bonito de todo esto es montarlo tú mismo y pelearte con las líneas de configuración, hasta que empiezas a ver que las cosas funcionan .

    Por cierto, en la misma página he encontrado el manual para el Squid. Cuando lo termine de leer lo posteo también. Buscaré también algo referente al Dansguardian, ya que me parece interesante e imprescindible.

    Saludos!


  4. #4
    Senior Member Avatar de Carlitoxx
    Fecha de ingreso
    12 oct, 05
    Ubicación
    Con l@s Wambin@s!
    Edad
    41
    Mensajes
    4,384

    Re: Cómo montar un firewall por software

    Manual del Squid:


    Autor: Joel Barrios Dueñas
    Correo electrónico: jbarrios arroba linuxparatodos punto net
    Sitio de Red: http://www.linuxparatodos.net/


    Introducción.
    ¿Qué es Servidor Intermediario (Proxy)?


    El término en ingles «Proxy» tiene un significado muy general y al mismo tiempo ambiguo, aunque invariablemente se considera un sinónimo del concepto de «Intermediario». Se suele traducir, en el sentido estricto, como delegado o apoderado (el que tiene el que poder sobre otro).

    Un Servidor Intermediario (Proxy) se define como una computadora o dispositivo que ofrece un servicio de red que consiste en permitir a los clientes realizar conexiones de red indirectas hacia otros servicios de red. Durante el proceso ocurre lo siguiente:
    • Cliente se conecta hacia un Servidor Intermediario (Proxy).
    • Cliente solicita una conexión, fichero u otro recurso disponible en un servidor distinto.
    • Servidor Intermediario (Proxy) proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.
    • En algunos casos el Servidor Intermediario (Proxy) puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.


    Los Servidores Intermediarios (Proxies) generalmente se hacen trabajar simultáneamente como muro cortafuegos operando en el Nivel de Red, actuando como filtro de paquetes, como en el caso de iptables, o bien operando en el Nivel de Aplicación, controlando diversos servicios, como es el caso de TCP Wrapper. Dependiendo del contexto, el muro cortafuegos también se conoce como BPD o Border Protection Device o simplemente filtro de paquetes.

    Una aplicación común de los Servidores Intermediarios (Proxies) es funcionar como caché de contenido de Red (principalmente HTTP), proporcionando en la proximidad de los clientes un caché de páginas y ficheros disponibles a través de la Red en servidores HTTP remotos, permitiendo a los clientes de la red local acceder hacia éstos de forma más rápida y confiable.

    Cuando se recibe una petición para un recurso de Red especificado en un URL (Uniform Resource Locator) el Servidor Intermediario busca el resultado del URL dentro del caché. Si éste es encontrado, el Servidor Intermediario responde al cliente proporcionado inmediatamente el contenido solicitado. Si el contenido solicitado no estuviera disponible en el caché, el Servidor Intermediario lo traerá desde servidor remoto, entregándolo al cliente que lo solicitó y guardando una copia en el caché. El contenido en el caché es eliminado luego a través de un algoritmo de expiración de acuerdo a la antigüedad, tamaño e historial de respuestas a solicitudes (hits) (ejemplos: LRU, LFUDA y GDSF).

    Los Servidores Intermediarios para contenido de Red (Web Proxies) también pueden actuar como filtros del contenido servido, aplicando políticas de censura de acuerdo a criterios arbitrarios.
    Acerca de Squid.

    Squid es un Servidor Intermediario (Proxy) de alto desempeño que se ha venido desarrollando desde hace varios años y es hoy en día un muy popular y ampliamente utilizado entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública General GNU (GNU/GPL). Siendo sustento lógico libre, está disponible el código fuente para quien así lo requiera.

    Entre otras cosas, Squid puede funcionar como Servidor Intermediario (Proxy) y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario.

    Squid consiste de un programa principal como servidor, un programa para búsqueda en servidores DNS, programas opcionales para reescribir solicitudes y realizar autenticación y algunas herramientas para administración y y herramientas para clientes. Al iniciar Squid da origen a un número configurable (5, de modo predefinido a través del parámetro dns_children) de procesos de búsqueda en servidores DNS, cada uno de los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de tiempo de espera para las búsquedas en servidores DNS.
    NOTA ESPECIAL: Squid no debe ser utilizado como Servidor Intermediario (Proxy) para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT (Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante (http://www.inet.no/dante/).


    URL: http://www.squid-cache.org/
    Algoritmos de caché utilizados por Squid.


    A través de un parámetro (cache_replacement_policy) Squid incluye soporte para los siguientes algoritmos para el caché:
    LRU Acrónimo de Least Recently Used, que traduce como Menos Recientemente Utilizado. En este algoritmo los objetos que no han sido accedidos en mucho tiempo son eliminados primero, manteniendo siempre en el caché a los objetos más recientemente solicitados. Ésta política es la utilizada por Squid de modo predefinido.

    LFUDA Acrónimo de Least Frequently Used with Dynamic Aging, que se traduce como Menos Frecuentemente Utilizado con Envejecimiento Dinámico. En este algoritmo los objetos más solicitados permanecen en el caché sin importar su tamaño optimizando la eficiencia (hit rate) por octetos (Bytes) a expensas de la eficiencia misma, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia.

    GDSF Acrónimo de GreedyDual Size Frequency, que se traduce como Frecuencia de tamaño GreedyDual (codicioso dual), que es el algoritmo sobre el cual se basa GDSF. Optimiza la eficiencia (hit rate) por objeto manteniendo en el caché los objetos pequeños más frecuentemente solicitados de modo que hay mejores posibilidades de lograr respuesta a una solicitud (hit). Tiene una eficiencia por octetos (Bytes) menor que el algoritmo LFUDA debido a que descarta del caché objetos grandes que sean solicitado con frecuencia.

    Sustento lógico necesario.

    Para poder llevar al cabo los procedimientos descritos en este manual y documentos relacionados, usted necesitará tener instalado al menos lo siguiente:
    • Al menos squid-2.5.STABLE6
    httpd-2.0.x (Apache), como auxiliar de caché con aceleración.
    • Todos los parches de seguridad disponibles para la versión del sistema operativo que esté utilizando. No es conveniente utilizar un sistema con posibles vulnerabilidades como Servidor Intermediario.


    Debe tomarse en consideración que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo sustento lógico que vaya a ser instalado para realizar los procedimientos descritos en este manual, a fin de contar con los parches de seguridad necesarios. Ninguna versión de Squid anterior a la 2.5.STABLE6 se considera como apropiada debido a fallas de seguridad de gran importancia.

    Squid no se instala de manera predeterminada a menos que especifique lo contrario durante la instalación del sistema operativo, sin embargo viene incluido en casi todas las distribuciones actuales.


    Otros componentes necesarios.

    El mandato iptables se utilizará para generar las reglas necesarias para el guión de Enmascaramiento de IP. Se instala de modo predefinido en todas las distribuciones actuales que utilicen núcleo (kernel) versiones 2.4 y 2.6.

    Es importante tener actualizado el núcleo del sistema operativo por diversas cuestiones de seguridad. No es recomendable utilizar versiones del kernel anteriores a la 2.4.21. Actualice el núcleo a la versión más reciente disponible para su distribución.


    Antes de continuar.

    Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en todos los casos y si algo no funciona solo significa que usted no lo leyó a detalle y no siguió correctamente las indicaciones.

    Evite dejar espacios vacíos en lugares indebidos.


    Configuración básica.

    Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes:
    • http_port
    • cache_dir
    • Al menos una Lista de Control de Acceso
    • Al menos una Regla de Control de Acceso
    • httpd_accel_host
    • httpd_accel_port
    • httpd_accel_with_proxy

    Parámetro http_port: ¿Que puerto utilizar para Squid?

    De acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el 21 de marzo de 2001, los Puertos Registrados (rango desde 1024 hasta 49151) recomendados para Servidores Intermediarios (Proxies) pueden ser el 3128 y 8080 a través de TCP.

    De modo predefinido Squid utilizará el puerto 3128 para atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro puerto disponible o bien que lo haga en varios puertos disponibles a la vez.

    En el caso de un Servidor Intermediario (Proxy) Transparente, regularmente se utilizará el puerto 80 o el 8000 y se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los clientes HTTP para utilizar el Servidor Intermediario (Proxy). Bastará con utilizar como puerta de enlace al servidor. Es importante recordar que los Servidores HTTP, como Apache, también utilizan dicho puerto, por lo que será necesario volver a configurar el servidor HTTP para utilizar otro puerto disponible, o bien desinstalar o desactivar el servidor HTTP.

    Hoy en día puede no ser del todo práctico el utilizar un Servidor Intermediario (Proxy) Transparente, a menos que se trate de un servicio de Café Internet u oficina pequeña, siendo que uno de los principales problemas con los que lidian los administradores es el mal uso y/o abuso del acceso a Internet por parte del personal. Es por esto que puede resultar más conveniente configurar un Servidor Intermediario (Proxy) con restricciones por clave de acceso, lo cual no puede hacerse con un Servidor Intermediario (Proxy) Transparente, debido a que se requiere un diálogo de nombre de usuario y clave de acceso.

    Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer de modo predefinido el puerto 8080 (servicio de cacheo WWW) para utilizarse al configurar que Servidor Intermediario (Proxy) utilizar. Si queremos aprovechar esto en nuestro favor y ahorrarnos el tener que dar explicaciones innecesarias al usuario, podemos especificar que Squid escuche peticiones en dicho puerto también. Siendo así localice la sección de definición de http_port, y especifique:
    #
    # You may specify multiple socket addresses on multiple lines.
    #
    # Default: http_port 3128
    http_port 3128
    http_port 8080


    Si desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP 192.168.1.254, puede hacerse lo siguiente:
    #
    # You may specify multiple socket addresses on multiple lines.
    #
    # Default: http_port 3128
    http_port 192.168.1.254:3128
    http_port 192.168.1.254:8080

    Parámetro cache_mem.

    El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente:
    • Objetos en tránsito.
    • Objetos frecuentemente utilizados (Hot).
    • Objetos negativamente almacenados en el caché.


    Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem especifica un límite máximo en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad. Sin embargo los objetos Hot y aquellos negativamente almacenados en el caché podrán utilizar la memoria no utilizada hasta que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad de memoria especificada, Squid excederá lo que sea necesario para satisfacer la petición.

    De modo predefinido se establecen 8 MB. Puede especificarse una cantidad mayor si así se considera necesario, dependiendo esto de los hábitos de los usuarios o necesidades establecidas por el administrador.

    Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor para este parámetro:
    cache_mem 16 MB


    Parámetro cache_dir: ¿Cuanto desea almacenar de Internet en el disco duro?

    Este parámetro se utiliza para establecer que tamaño se desea que tenga el caché en el disco duro para Squid. Para entender esto un poco mejor, responda a esta pregunta: ¿Cuanto desea almacenar de Internet en el disco duro? De modo predefinido Squid utilizará un caché de 100 MB, de modo tal que encontrará la siguiente línea:
    cache_dir ufs /var/spool/squid 100 16 256


    Se puede incrementar el tamaño del caché hasta donde lo desee el administrador. Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un caché de 700 MB:
    cache_dir ufs /var/spool/squid 700 16 256


    Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios subordinados con 256 niveles cada uno. No modifique esto números, no hay necesidad de hacerlo.

    Es muy importante considerar que si se especifica un determinado tamaño de caché y éste excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de caché especificado.


    Parámetro ftp_user.

    Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará como clave de acceso Squid@. Si se desea que el acceso anónimo a los servidores FTP sea más informativo, o bien si se desea acceder a servidores FTP que validan la autenticidad de la dirección de correo especificada como clave de acceso, puede especificarse la dirección de correo electrónico que uno considere pertinente.
    ftp_user proxy@su-dominio.net


    Controles de acceso.

    Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y otras.


    Listas de control de acceso.

    Regularmente una lista de control de acceso se establece con la siguiente sintaxis:
    acl [nombre de la lista] src [lo que compone a la lista]


    Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde las máquinas tienen direcciones IP 192.168.1.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente:
    acl miredlocal src 192.168.1.0/255.255.255.0


    También puede definirse una Lista de Control de Acceso especificando un fichero localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP. Ejemplo:
    acl permitidos src "/etc/squid/permitidos"


    El fichero /etc/squid/permitidos contendría algo como siguiente:
    192.168.1.1
    192.168.1.2
    192.168.1.3
    192.168.1.15
    192.168.1.16
    192.168.1.20
    192.168.1.40


    Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/permitidos.


    Reglas de Control de Acceso.

    Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:
    #
    # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
    #


    La sintaxis básica es la siguiente:
    http_access [deny o allow] [lista de control de acceso]


    En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:
    http_access allow permitidos


    También pueden definirse reglas valiéndose de la expresión !, la cual significa no. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2:
    http_access allow lista1 !lista2


    Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.


    Aplicando Listas y Reglas de control de acceso.

    Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, procederemos a determinar cuales utilizar para nuestra configuración.


    Caso 1.

    Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:
    acl todalared src 192.168.1.0/255.255.255.0


    Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:

    Listas de Control de Acceso: definición de una red local completa
    #
    # Recommended minimum configuration:
    acl all src 0.0.0.0/0.0.0.0
    acl manager proto cache_object
    acl localhost src 127.0.0.1/255.255.255.255
    acl todalared src 192.168.1.0/255.255.255.0


    A continuación procedemos a aplicar la regla de control de acceso:
    http_access allow todalared


    Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

    Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
    #
    # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
    #
    http_access allow localhost
    http_access allow todalared
    http_access deny all


    La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.


    Caso 2.

    Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/listas/redlocal, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:
    192.168.1.1
    192.168.1.2
    192.168.1.3
    192.168.1.15
    192.168.1.16
    192.168.1.20
    192.168.1.40


    Denominaremos a esta lista de control de acceso como redlocal:
    acl redlocal src "/etc/squid/listas/redlocal"


    Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:

    Listas de Control de Acceso: definición de una red local completa#
    # Recommended minimum configuration:
    acl all src 0.0.0.0/0.0.0.0
    acl manager proto cache_object
    acl localhost src 127.0.0.1/255.255.255.255
    acl redlocal src "/etc/squid/listas/redlocal"


    A continuación procedemos a aplicar la regla de control de acceso:
    http_access allow redlocal


    Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

    Reglas de control de acceso: Acceso a una Lista de Control de Acceso.
    #
    # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
    #
    http_access allow localhost
    http_access allow redlocal
    http_access deny all


    La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/listas/redlocal. Esto significa que cualquier máquina no incluida en /etc/squid/listas/redlocal no tendrá acceso a Squid.


    Parámetro chache_mgr.

    De modo predefinido, si algo ocurre con el caché, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.
    cache_mgr joseperez@midominio.net


    Parámetro cache_peer: caches padres y hermanos.

    El parámetro cache_peer se utiliza para especificar otros Servidores Intermediarios (Proxies) con caché en una jerarquía como padres o como hermanos. Es decir, definir si hay un Servidor Intermediario (Proxy) adelante o en paralelo. La sintaxis básica es la siguiente:
    cache_peer servidor tipo http_port icp_port opciones


    Ejemplo: Si su caché va a estar trabajando detrás de otro servidor cache, es decir un caché padre, y considerando que el caché padre tiene una IP 192.168.1.1, escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130 (puerto utilizado de modo predefinido por Squid), especificando que no se almacenen en caché los objetos que ya están presentes en el caché del Servidor Intermediario (Proxy) padre, utilice la siguiente línea:
    cache_peer 192.168.1.1 parent 8080 3130 proxy-only


    Cuando se trabaja en redes muy grandes donde existen varios Servidores Intermediarios (Proxy) haciendo caché de contenido de Internet, es una buena idea hacer trabajar todos los caché entre si. Configurar caches vecinos como sibling (hermanos) tiene como beneficio el que se consultarán estos caches localizados en la red local antes de acceder hacia Internet y consumir ancho de banda para acceder hacia un objeto que ya podría estar presente en otro caché vecino.

    Ejemplo: Si su caché va a estar trabajando en paralelo junto con otros caches, es decir caches hermanos, y considerando los caches tienen IP 10.1.0.1, 10.2.0.1 y 10.3.0.1, todos escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130, especificando que no se almacenen en caché los objetos que ya están presentes en los caches hermanos, utilice las siguientes líneas:
    cache_peer 10.1.0.1 sibling 8080 3130 proxy-only
    cache_peer 10.2.0.1 sibling 8080 3130 proxy-only
    cache_peer 10.3.0.1 sibling 8080 3130 proxy-only



    Pueden hacerse combinaciones que de manera tal que se podrían tener caches padres y hermanos trabajando en conjunto en una red local. Ejemplo:
    cache_peer 10.0.0.1 parent 8080 3130 proxy-only
    cache_peer 10.1.0.1 sibling 8080 3130 proxy-only
    cache_peer 10.2.0.1 sibling 8080 3130 proxy-only
    cache_peer 10.3.0.1 sibling 8080 3130 proxy-only



    Caché con aceleración.

    Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el caché de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el caché en lugar de volver a descargarlo desde Internet.

    Esta función permite navegar rápidamente cuando los objetos ya están en el caché de Squid y además optimiza enormemente la utilización del ancho de banda.

    La configuración de Squid como Servidor Intermediario (Proxy) Transparente solo requiere complementarse utilizando una regla de iptables que se encargará de re-direccionar peticiones haciéndolas pasar por el puerto 8080. La regla de iptables necesaria se describe más adelante en este documento.


    Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) en modo convencional.

    En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros:
    httpd_accel_host virtual
    httpd_accel_port 0
    httpd_accel_with_proxy on



    Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) Transparente.

    Si se trata de un Servidor Intermediario (Proxy) transparente, deben utilizarse las siguientes opciones, considerando que se hará uso del caché de un servidor HTTP (Apache) como auxiliar:
    # Debe especificarse la IP de cualquier servidor HTTP en la
    # red local o bien el valor virtual
    httpd_accel_host 192.168.1.254
    httpd_accel_port 80
    httpd_accel_with_proxy on
    httpd_accel_uses_host_header on



    Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) Transparente para redes con Internet Exlorer 5.5 y versiones anteriores.

    Si va a utilizar Internet Explorer 5.5 y versiones anteriores con un Servidor Intermediario (Proxy) transparente, es importante recuerde que dichas versiones tiene un pésimo soporte con los Servidores Intermediarios (Proxies) transparentes imposibilitando por completo la capacidad de refrescar contenido. Si se utiliza el parámetro ie_refresh con valor on puede hacer que se verifique en los servidores de origen para nuevo contenido para todas las peticiones IMS-REFRESH provenientes de Internet Explorer 5.5 y versiones anteriores.
    # Debe especificarse la IP de cualquier servidor HTTP en la
    # red local
    httpd_accel_host 192.168.1.254
    httpd_accel_port 80
    httpd_accel_with_proxy on
    httpd_accel_uses_host_header on
    ie_refresh on


    Lo más conveniente es actualizar hacia Internet Explorer 6.x o definitivamente optar por otras alternativas. Mozilla es en un conjunto de aplicaciones para Internet, o bien Firefox, que es probablemente el mejor navegador que existe en el mercado. Firefox es un navegador muy ligero y que cumple con los estándares, y está disponible para Windows, Linux, Mac OS X y otros sistemas operativos.


    Estableciendo el idioma de los mensajes mostrados por de Squid hacia el usuario.

    Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado durante su operación. Dichas traducciones se pueden encontrar en /usr/share/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/share/squid/errors/Spanish en lugar de hacerlo hacia /usr/share/squid/errors/English.

    Elimine primero el enlace simbólico actual:
    rm -f /etc/squid/errors


    Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español.
    ln -s /usr/share/squid/errors/Spanish /etc/squid/errors


    Nota: Este enlace simbólico debe verificarse, y regenerarse de ser necesario, cada vez que se actualizado Squid.


    Iniciando, reiniciando y añadiendo el servicio al arranque del sistema.

    Una vez terminada la configuración, ejecute el siguiente mandato para iniciar por primera vez Squid:
    service squid start


    Si necesita reiniciar para probar cambios hechos en la configuración, utilice lo siguiente:
    service squid restart


    Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, utilice lo siguiente:
    chkconfig squid on


    Lo anterior habilitará a Squid en todos los niveles de corrida.


    Depuración de errores

    Cualquier error al inicio de Squid solo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los ficheros de las Listas de Control de Acceso.

    Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devolverá los errores que existan en el fichero /etc/squid/squid.conf.
    service squid reload


    Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse el contenido del fichero /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:
    less /var/log/squid/squid.out


    Ajustes para el muro corta-fuegos.

    Si se tiene poca experiencia con guiones de cortafuegos a través de iptables, sugerimos utilizar Firestarter. éste permite configurar fácilmente tanto el enmascaramiento de IP como el muro corta-fuegos. Si se tiene un poco más de experiencia, recomendamos utilizar Shorewall para el mismo fin puesto que se trata de una herramienta más robusta y completa.
    • Firestarter: http://www.fs-security.com/
    • Shorewall: http://www.shorewall.net/


    Re-direccionamiento de peticiones a través de iptables y Firestarter.

    En un momento dado se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio HTTP para pasar a través del el puerto donde escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguna hacia servidores HTTP en el exterior sin que ésta pase antes por Squid. No se puede hacer Servidor Intermediario (Proxy) Transparente para los protocolos HTTPS, FTP, GOPHER ni WAIS, por lo que dichos protocolos tendrán que ser filtrados a través del NAT.

    El re-direccionamiento lo hacemos a través de iptables. Considerando para este ejemplo que la red local se accede a través de una interfaz eth0, el siguiente esquema ejemplifica un re-direccionamiento:
    /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080


    Lo anterior, que requiere un guión de cortafuegos funcional en un sistema con dos interfaces de red, hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-direccionará hacia el puerto 8080 del servidor.

    Utilizando Firestarter, la regla anteriormente descrita se añade en el fichero /etc/firestarter/user-post.


    Re-direccionamiento de peticiones a través de la opción REDIRECT en Shorewall.

    La acción REDIRECT en Shorewall permite redirigir peticiones hacia protocolo HTTP para hacerlas pasar a través de Squid. En el siguiente ejemplo las peticiones hechas desde la zona que corresponde a la red local serán redirigidas hacia el puerto 8080 del cortafuegos, en donde está configurado Squid configurado como Servidores Intermediario (Proxy) transparente.
    #ACTION SOURCE DEST PROTO DEST
    REDIRECT loc 8080 tcp 80

    Ale, a empollar!!


  5. #5
    Just Urban! Avatar de RugaL
    Fecha de ingreso
    21 sep, 05
    Ubicación
    Arroyo de la Encomienda, Valladolid
    Edad
    41
    Mensajes
    9,231

    Re: Cómo montar un firewall por software

    Interesante. Algún dia de estos estaría bien pelearse con ello.


Temas similares

  1. Aventuras y desventuras de una profe en apuros. Cap. 2
    Por Nuri en el foro Todo lo demas
    Respuestas: 6
    Último mensaje: 04/05/2009, 18:47
  2. ¿Alguien quiere un perrito?
    Por Nuri en el foro Todo lo demas
    Respuestas: 9
    Último mensaje: 19/04/2009, 12:00
  3. Ofertas de móviles Vodafone
    Por Nilaya en el foro Electronica e informatica
    Respuestas: 3
    Último mensaje: 18/12/2007, 12:52
  4. Respuestas: 0
    Último mensaje: 18/07/2006, 13:23

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •