PROXYUn servidor proxy es un software que realiza tareas de servidor intermediario. El caso más común es utilizarlo para compartir internet en ámbitos donde se posee una única conexión a internet y varias computadoras. El servidor proxy se conecta directamente a internet y por otra interfaz a la red interna, de modo que todos los pedidos a internet de las computadoras pertenecientes a la LAN pasan a través del proxy y es éste en realidad el que hace las conexiones hacia la web y luego entrega las respuestas a los hosts correspondientes.Un proxy, en una red informática, es un programa o dispositivo que realiza una acción en representación de otro, esto es, si una hipotética máquina A solicita un recurso a una C, lo hará mediante una petición a B; C entonces no sabrá que la petición procedió originalmente de A. Esta situación estratégica de punto intermedio suele ser aprovechada para soportar una serie de funcionalidades: proporcionar caché, control de acceso, registro del tráfico, prohibir cierto tipo de tráfico etc.

CARACTERISTICAS:Permite definir los permisos que tienen los usuarios de la red interna sobre los servicios, dominios, IP externas. Todos los usuarios de la red interna comparten una única dirección IP de forma que desde el exterior no se puede diferenciar a unos de otros. Puesto que todo el tráfico que circula de la red interna hacia internet y viceversa pasa por el proxy, se puede auditar el uso que se hace de internet. Permite almacenar las páginas recientemente consultadas en una cache para aumentar el rendimiento de la red. Por ejemplo, la página que se

almacena en la caché de un proxy para que al recibir la petición cargue más rápido.

CONEXIONES SIN PROXY:

CONEXIONES CON PROXY:

SQUIDDentro de los servidores más importantes que existen en GNU/Linux existe el servidor proxy, el cual se encarga de administrar el acceso a internet de tu red local y también es conocido como servidor intermedio, el servidor proxy que se ocupa en GNU/Linux en sus diferentes distribuciones es squid. Squid es un programa que hace cache de datos obtenidos de internet para poder optimizar recursos de banda ancha de internet, entre sus características más importantes son:

Proxy/cache: Proporciona servicio proxy a peticiones del tipo http, https y ftp a equipos que se encuentran en nuestra red local para que puedan acceder hacia internet y a su vez provee la funcionalidad de cache en el cual se almacenan localmente

las paginas consultadas por los usuarios de forma que incrementa la rapidez de acceso a la información web y ftp.

Proxy SSL: Es un servicio de squid compatible con SSL (Secure Sockets Layer), con el cual se aceleran las peticiones y las peticiones hacia internet estarían cifradas.

Jerarquías de Cache: Nuestro squid puede pertenecer a una jerarquía de cache que trabajan conjuntamente sirviendo peticiones. En este caso tendremos varios servidores squid resolviendo peticiones de una página web, si no la tiene registrada le pregunta a otro hasta que es encontrada la información.

Compendio de ICP, HTCP, CARP, Cache: Squid sigue los compendios de protocolos ICP, HTCP, CARP y caché que tienen como objetivo permitir a un proxy "preguntarle" a otros proxys caché si poseen almacenado un recurso determinado.

Proxy Transparente: Puede ser configurado para ser usado como proxy transparente de manera que las solicitudes son enrutadas por medio de reglas de firewall y sean enviadas al squid sin tener que configurar los clientes dentro de una red.

WCCP: Permite interceptar y redirigir el tráfico que recibe un router hacia uno o más proxys caché, haciendo control de la conectividad de los mismos.

Control de Accesos: En este parte establecemos reglas de control de acceso, esto permite establecer políticas de denegación o aceptación.

Aceleración de servidores HTTP: Cuando hacemos peticiones hacia internet la información es almacenada en el cache del squid y si hay otra solicitud hacia el mismo recurso el squid le devolverá la información que tiene el squid en cache. Si hay algún cambio entonces la información deberá ser actualizada.

SNMP: Permite activar el protocolo SNMP, esto permite la administración de red, que permite supervisar, analizar y comunicar información de estado entre una gran variedad de máquinas, pudiendo detectar problemas y proporcionar mensajes de estados.

Caché de resolución DNS: Squid está compuesto también por el programa DNS server, que se encarga de la búsqueda de nombres de dominio. Cuando Squid se ejecuta, produce un número configurable de procesos DNS server, y cada uno de ellos realiza su propia búsqueda en DNS. De este modo, se reduce la cantidad de tiempo que la caché debe esperar a estas búsquedas DNS.

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 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.

Los servidores proxy son en su mayoría desplegados para llevar a cabo lo siguiente:

Reducir el consumo de ancho de banda.

Mejorar la experiencia de navegación del usuario al reducir el tiempo de carga de página.

Se logra mediante el almacenamiento en caché de documentos web.Hacer cumplir las políticas de acceso a la red.

Control de tráfico de los usuarios o informar el uso de Internet para usuarios individuales o grupos.

Mejorar la privacidad de los usuarios al no exponer la máquina del usuario directamente a Internet.

Distribuirla carga entre los servidores web diferentes para reducir la carga en un único servidor.

PROXY INVERSOUn proxy inverso (o reverse proxy) es una técnica de almacenar las respuestas o recursos de un servidor web local para que las solicitudes posteriores al mismo recurso puede ser satisfechas con la copia local en el servidor proxy, a veces sin ni siquiera estar realmente en contacto con el servidor web. El servidor proxy chequea si la copia almacenada localmente del documento web sigue siendo válida antes de servir la copia almacenada en caché.La vida del documento Web localmente almacenada se calcula a partir de los encabezados HTTP adicionales recibidos desde el servidor web. Usar cabeceras HTTP, servidores web pueden controlar si un determinado documento / respuesta debe ser almacenado en caché por un servidor proxy o no.El almacenamiento en caché Web se utiliza sobre todo:

Para reducir el consumo de ancho de banda. Un gran número de documentos web estáticas como los archivos CSS y JavaScript, imágenes, videos, y así sucesivamente pueden

almacenar en caché, ya que no cambian con frecuencia y constituye la mayor parte de la respuesta de un servidor web.

Por los ISP para reducir el tiempo promedio de carga de la página para mejorar la experiencia de navegación para sus clientes en el acceso telefónico o banda ancha.

Para tomar una carga de un servidor web muy ocupado sirviendo páginas estáticas y documentos de un servidor proxy caché.

PROXY TRANSPARENTETal como hemos visto es posible usar un proxy para aplicar políticas de control de acceso a Internet. Normalmente esa configuración no es transparente: es necesario modificar el cliente para que use el proxy al acceder a Internet, de forma que es posible que un usuario modifique esa configuración.Una configuración de proxy transparente hace que no sea necesaria modificación alguna en las máquinas clientes, eliminando el riesgo de que un usuario modifique dicha configuración a su antojo. El uso de un proxy transparente combina un servidor proxy con NAT, de forma que todas las conexiones son encaminadas a través del proxy sin la intervención de la máquina cliente.

OBTENCIÓN DE SQUIDSquid está disponible en varias formas (archivos comprimidos de origen, código fuente de un sistema de control de versiones, paquetes de binarios, tales como RPM, DEB, etc) desde el sitio oficial de Squid, Squid varios espejos en todo el mundo, y los repositorios de software de casi todo el operativo popular sistemas. Squid también se suministra con muchas distribuciones de Linux / Unix.Hay varias versiones y liberaciones de squid disponibles para su descarga desde el sitio oficial de Squid. Para obtener el máximo rendimiento de una instalación de Squid todo lo posible para ver el último código fuente de un sistema de control de versiones (VCS) para que podamos obtener las últimas mejoras y correcciones. Pero cuidado, el último código fuente de un VCS es generalmente de punta y no puede ser estable o tal vez ni siquiera funcione correctamente. Aunque el código de un VCS es bueno para el aprendizaje o evaluación de las nuevas características de Squid, se aconsejan o usar el código de un VCS para los despliegues de producción.

Si queremos ir a lo seguro, probablemente debe descargar la última versión estable de las versiones más antiguas. Las versiones estables se prueban generalmente antes de que sean puestos en libertad y se supone que funcionan fuera de la caja. Versiones estables se puede utilizar directamente en despliegues de producción.

VERSIONES ESTABLES

VERSIONES BETA

VERSIONES DE DESARROLLO

VERSIONES ANTERIORES

FUNCIONAMIENTO:

Una aplicación común de los Squid 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 Squid busca el resultado del URL dentro del caché. Si éste es encontrado, el Squid responde al cliente proporcionado inmediatamente el contenido solicitado. Si el

contenido solicitado no estuviera disponible en el caché, el Squid 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).

LRU (política por defecto): Se eliminan de la cache los objetos que no han sido accedidos en mucho tiempo, manteniendo en la cache los que han sido utilizado más recientemente.

LFUDA: Los objetos más solicitados permanecen en el cache sin importar su tamaño, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer cache de objetos pequeños que se soliciten con menor frecuencia.

GDSF: Optimiza la eficiencia por objeto, manteniendo en el cache los objetos pequeños más frecuentemente solicitados; descarta del cache objetos grandes que sean solicitado con frecuencia.

VENTAJAS: Soporta HTTP y FTP. Tiene un avanzado mecanismo de autentificación y control

de acceso (o sea, a quien y cuando permitimos utilizar el proxy).

Permite actuar como 'cache' de Internet, copiando contenido en forma local para que se lo pueda accesar rápidamente.

Es Software Libre. Ahorro de tráfico. Velocidad en tiempo de respuesta. Filtrado de contenidos.

DESVENTAJAS: La máquina donde funcionara el Proxy debe tener capacidad

de almacenamiento acorde a la cache que necesitemos o queramos.

Debe tener un buen poder de procesamiento, ya que no es solo un 'reenvio' de paquetes tcp/ip. Recuerden que estamos trabajando en la Capa de Aplicación.

En modo transparente existen algunos problemas de compatibilidad (mínimos, pero existen).

Hay que configurar la utilización del Proxy en cada cliente (hay 2 formas de salvar este inconveniente, que veremos más adelante).

JERARQUIA DE SERVIDORES

SQUID permite especificar otros servidores intermediarios, utilizando la cache en una jerarquía como padres o como hermanos, dependiendo de la topología de la red estos pueden operar en cascada (padres) o en paralelo (hermanos).

CACHÉS MULTINIVEL

Es posible configurar varios proxys para que cooperen intercambiando objetos entre ellos. De esta forma se reduce la carga total del sistema y se aumenta la probabilidad de que el objeto se encuentre ya en la red local. Es posible configurar incluso jerarquías de cachés, de forma que se pueda pedir páginas a cachés del mismo nivel o enviar peticiones a otros proxys de jerarquía más alta para que pidan las páginas a otros cachés existentes en la red o las obtengan directamente de la fuente.

Elegir una buena topología para los cachés es muy importante para no acabar creando más tráfico del que ya había en la red antes de instalar los cachés. Por ejemplo, en el caso de una red local muy extensa conviene configurar un servidor proxy para cada subred y conectar estos a un proxy de jerarquía superior conectado a su vez al caché proxy del ISP.

Toda esta comunicación se lleva a cabo mediante el protocolo ICP (Internet Cache Protocol) basado en UDP. Las transferencias de datos entre la mayoría de cachés se realizan mediante HTTP, protocolo basado en TCP.

Para encontrar el servidor más apropiado desde el que obtener un objeto, un caché envía una petición ICP a sus proxys vecinos. Estos le enviarán respuestas ICP con código “HIT”, si el objeto se encuentra efectivamente allí, o bien “MISS” en caso contrario. En caso que haya varios HIT, el proxy se decidirá por un servidor en especial en función de factores como la velocidad de respuesta o la proximidad, entre

otros. Si las respuestas de los proxys vecinos no son satisfactorias, la petición se realizará al caché principal.

OBJETOS CACHEADOS EN INTERNET

No todos los objetos disponibles en la red son estáticos. Existen páginas generadas dinámicamente por CGIs, contadores de visitantes o bien documentos que incluyen SSL para codificar el contenido y hacerlo más seguro. Por esos motivos se considera este tipo de objetos como no cacheables, ya que cada vez que se accede a ellos ya han cambiado.

Pero para todos los demás objetos que se guardan en el caché existe el problema de cuánto tiempo deben quedarse allí. Para determinarlo se asignan diferentes estados a los objetos del caché.

Los servidores web y los cachés proxy controlan el estado de un objeto añadiendo cabeceras como Lastmodified (última modificación) o Expires (expira) y la fecha correspondiente. También se utilizan otras cabeceras para especificar los objetos que no deben cachearse.

Normalmente, los objetos desaparecerán antes del caché por la falta de espacio en el disco. Se utiliza algoritmos para sustituir objetos en el caché, como el LRU (Last Recently Used) que consiste en sustituir los objetos menos utilizados por nuevos.

Tamaño del caché de disco

Depende de varios factores. En un caché pequeño la probabilidad de un HIT (el objeto ya se encuentre en el caché) será pequeña, ya que el caché se llenará con facilidad y se deberá sustituir los objetos antiguos por nuevos. En cambio, en el caso de disponer de por ejemplo 1GB de disco para cachear, y de que los usuarios sólo necesiten 10MB al día para navegar, se tardará al menos 100 días en llenar el caché.

El método más fácil para determinar el tamaño del caché es en función del tráfico máximo que pase por el mismo. Si se dispone de una conexión de 1Mb/s, como mucho se transferirán 125KB por segundo. Si todo este tráfico va a parar al caché, en una hora será 450MB, y suponiendo que este tráfico se genera durante las 8 horas de trabajo, tendremos en total 3,6GB diarios. Como la línea no suele trabajar al máximo, la cantidad total de datos procesada por el caché es de unos 2GB. Así pues, para guardar todos los datos navegados por la web en un día, necesitamos en este ejemplo 2GB de memoria RAM para Squid.

ACTUALIZAR LOS PATRONES DE LOS OBJETOS ALMACENADOS EN CACHÉ

Squid ofrece la Directiva refresh_pattern, con el que podemos controlar el estado de un objeto en caché.

Actualizar los patrones se pueden utilizar para lograr mayores tasas de HIT, manteniendo los objetos recientemente expiró fresca durante un período corto de tiempo, o por razones imperiosas de algunos de los encabezados HTTP enviados por los servidores web. Mientras que la directiva de caché puede hacer uso de ACL, refresh_pattern utiliza expresiones regulares. La ventaja de utilizarla directiva refresh_patternes que se puede alterar el curso de la vida de los objetos almacenados en caché, mientras que con la directiva de caché sólo se puede controlar si una solicitud debe ser almacenado en caché o no.

Vamos a echar un vistazo a la sintaxis de refresh_pattern:

refresh_pattern [-i] regex min percent max [OPTIONS]

La expresión regex parámetro debe ser una expresión regular que describe la petición de URL. Una línea de patrón de actualización se aplica a cualquier URL que coincide con la expresión regular correspondiente. No puede haber varias líneas de los patrones de refresco. La primera línea, cuya expresión regular coincide con la dirección actual, se utiliza. De forma predeterminada, la expresión regular es entre mayúsculas y minúsculas, pero podemos utilizar-i para que sea entre mayúsculas y minúsculas.

El método utilizado para la determinación de la actualización o el estancamiento de un objeto almacenado en caché. Un objeto en caché se considera:

Expiración. si el tiempo de caducidad que se menciona en el encabezado de respuesta HTTP es en el pasado.

Refresca, si el tiempo de expiración mencionada en las cabeceras de respuesta HTTP es en el futuro.

Expiración, si la edad de respuesta es más que el valor máximo. Refresca, si LM-factor es menor que el valor por ciento. Refresca, si la edad de respuesta es menor que el valor min.

Expiración, de lo contrario.Tiempo para la acción del cálculo de la actualización de los objetos almacenados en caché:

Digamos que un cliente pidió a la imagen en http://example.com/text.jpg~~ hace una hora, y la imagen fue modificada por última vez (creado) en el servidor web hace seis horas. Supongamos que el servidor web no especificó el tiempo de caducidad. Por lo tanto, tenemos los siguientes valores para las diferentes variables:

En el momento de la solicitud, la edad del objeto era (6 -1)= 5 horas.

Actualmente, la edad de respuesta es de 1 hora. En la actualidad, el LM-factor es 1 ÷5 = 20 por ciento.

Vamos a comprobar si el objeto se ha refrescado: La edad de respuesta es de 60 minutos, que no es más de 1440

(valor máximo), así que esto no puede ser el factor decisivo. LM-factor es 20 por ciento, que es inferior al 60 por ciento, por

lo que el objeto se refresca.Ahora, vamos a calcular el momento en que el objeto expirará. La edad es objeto de 5 horas y el valor es 60 por ciento. Por lo tanto, el objeto expirará en (5x 60) ÷ 100= 3 horas de la última solicitud, es decir, 2 horas a partir de ahora.

OPCIONES PARA EL PATRÓN DE ACTUALIZACIÓNLa mayoría de las veces, el tiempo de expiración especificada por los servidores web para todas las solicitudes. Sin embargo, algunos documentos de la tela, como las hojas de estilo (CSS) o archivos JavaScript (JS) incluidos en la página web, cambiar muy rara vez y se puede subir su tiempo de caducidad a un valor más alto para aprovechar al máximo el almacenamiento en caché. A medida que los servidores web y a especificar el tiempo de expiración, el caché de CSS /JS, caducará automáticamente. Para ignorarla fuerza de la caduca y un montón de otras cabeceras relacionadas con el almacenamiento en caché, podemos pasar las opciones de la directiva refresh_pattern.

Opciones para el patrón de actualización: override-expire: La opción de override-expire, anula o hace

caso omiso de la cabecera Expires, que es el actor principal para determinar el tiempo de caducidad de una respuesta almacenada en caché. Como el encabezado Caduca se tiene en cuenta, los valores del mínimo, máximo, y los parámetros por ciento jugará un papel esencial en la determinación de la actualización de una respuesta.

override-lastmod: La opción de override-lastmod obligará a Squid para ignorar la cabecera Last-Modified, que finalmente se imponga el uso del valor mínimo para determinar la actualización de un objeto. Esta opción no sirve de nada, si nos hemos fijado el valor de minutos a cero.

reload-into-ims: Usando la opción de reload-into-ims obligará a Squid para convertir las directivas de caché no-en las cabeceras HTTP de las cabeceras If-Modified-Since. El uso de esta opción es útil sólo cuando la cabecera Last-Modified está presente.

ignore-reload: Usando la opción de ignore-reload simplemente ignorar la no-cacheo directivas de recarga presentes en las cabeceras HTTP.

ignore-no-cache: Cuando la opción ignore-no-cache utiliza la caché, Squid simplemente ignora la directiva no-cache en las cabeceras HTTP.

ignore-no-store: El encabezado HTTP ignore-no-store se utiliza par ainformar a los clientes que no se les permite

almacenar los datos que se transmiten. Si la opción de ignore-no-store se establece, Squid simplemente ignorara esta cabecera HTTP y almacena en caché la respuesta si se trata de almacenar en caché.

ignore-must-revalidate: El encabezado HTTP ignore-must-revalidate significa que la respuesta debe ser revalidado con el servidor Web de origen antes de que sea utilizado de nuevo. Establecer la opción de ignore-must-revalidate hará cumplir Squid hacer caso omiso de esta cabecera.

ignore-private: La información privada o datos sensibles por lo general lleva una cabecera HTTP conocido comoCache-Control: prívate para que los servidores intermedios no hacen caché de las respuestas. Sin embargo, la opción de ignorar-privada se puede utilizar para ignorar esta cabecera.

ignore-auth: Si la opción de ignore-auth está definida, entonces Squid será capaz de almacenar en caché las solicitudes de autorización. Con esta opción puede ser muy arriesgado.

refresh-ims: Esta opción puede ser bastante útil. La opción de refresh-IMS fuerzas de Squidpara validar el objeto en caché con el servidor original cada vez que un If-Modified-Since encabezado solicitud es recibidade un cliente. El uso de este puede aumentar la latencia, pero los clientes siempre obtendrán los datos más recientes.

ANULACIÓN DE LAS RECUPERACIONES PARCIALESCuando un cliente inicia una petición de ir a buscar algunos datos y aborta prematuramente, Squidpuede continuar para tratar de recuperar los datos. Esto puede causar ancho de banda y otros recursostales como el poder de procesamiento y memoria que se pierde, sin embargo, si tenemos las solicitudes posteriores para el mismo objeto, que va a resultar en una proporción de aciertos mejor. Para actuar contra este problema, Squid ofrece tres directivas quick_abort_min(KB), quick_abort_max(KB), y quick_abort_pct(por ciento).Para todas las solicitudes abortadas, Squid comprueba los valores de estas directivas y toma la acción apropiada de acuerdo a las siguientes reglas:

Si los datos restantes que debe ser recuperado es menor que el valor de quick_abort_min, Squid continuará a buscarla.

Si los datos restantes a ser transferidos es mayor que el valor dequick_abort_max, Squid abortar inmediatamente la solicitud.

Si los datos que ya se ha transferido más de ciento quick_abort_pct de los datos totales, a continuación, Squid se mantendrá la recuperación de los datos.

ALMACENAMIENTO EN CACHÉ LAS PETICIONES FALLIDASLas solicitudes de recursos que no existe (HTTP Error 404) o un cliente no tiene permiso para acceder al recurso solicitado (HTTP Error 403) son comunes y las peticiones a esos recursos representan un porcentaje significativo de las solicitudes totales. Estas respuestas son almacenables por Squid. Sin embargo, a veces los servidores web no envía el Expira cabeceras HTTP en las respuestas, lo que impide el almacenamiento en caché de Squid estas respuestas. Para resolver este problema, Squid ofrece la negative_ttl directiva que obliga a este tipo de respuestas en la memoria caché durante el tiempo especificado. La sintaxis de negative_ttl es como sigue:negative_ttl TIME_UNITS.Anteriormente,este valor fue de cinco minutos por defecto, pero en las nuevas versiones de Squid, se establece en cero segundos por defecto.

MEMORIA RAM

La cantidad de memoria requerida por Squid está relacionada directamente con la cantidad de objetos que se encuentran en el caché. Squid también almacena referencias a los objetos en el caché y objetos utilizados frecuentemente en la memoria RAM para optimizar la obtención de los mismos. La memoria RAM es muchísimo más rápida que el disco duro.

Squid también guarda muchos otros datos en la memoria, como por ejemplo una tabla con todas las direcciones IP utilizadas, un caché para los nombres de dominio totalmente cualificados, objetos “calientes” (los que más se solicitan), buffers, listas de control de acceso, etc.

Es muy importante tener memoria más que suficiente para el proceso de Squid, ya que en el caso de tener que pasar el proceso al disco duro, las prestaciones del sistema se reducirán drásticamente. Para facilitar la administración de la memoria utilizada por el caché, podemos utilizar la herramienta cachemgr.cgi

EJECUCIÓN DE SQUIDLas opciones de línea de comandos: Normalmente, todas las opciones de configuración de Squid residen con en el archivo squid.conf (el archivo de configuración de Squid principal). Para modificar la funcionalidad de Squid, el método preferido consiste en cambiar las opciones en el archivo squid.conf. Sin embargo, hay algunas opciones que también pueden ser controlados usando las opciones adicionales de línea de comandos durante la ejecución de Squid.

Estas opciones no son muy populares y se usan rara vez, pero estas son muy útiles para la depuración de los problemas sin el servidor proxy Squid. Antes de explorarlas opciones de línea de comandos, vamos a ver cómo Squid se ejecuta desde la línea de comandos.

La ubicación del archivo binario de Squid depende de la opción – prefix pasa al comando configure antes de compilar. Así, dependiendo del valor de la opción - prefix, la ubicación del ejecutable de Squid puede ser uno de

/usr/local/sbin/squido ${PREFIX}/sbin/squid

Donde ${PREFIX} es el valor de la opción- prefix pasa al comando de configuración. Por lo tanto, para ejecutar Squid, que necesitamos para ejecutar uno de los siguientes comandos en el terminal:

Cuando la opción – prefix no se utiliza con el comando de configuración, la ubicación predeterminada del archivo ejecutable de Squid será /usr/local/sbin/squid.

Cuando la opción – prefix se utilizó y se estableció en un directorio, entonces la ubicación del ejecutable de Squid será de ${PREFIX}/sbin/squid.

$ Squid: Este comando se ejecutará Squid es después de cargarlas opciones de configuraciónde la squid.conf.

REGLAS DE ACCESO DE SQUIDUna vez que tenemos un servidor proxy Squid en marcha y funcionando, podemos definir reglas para permitir o denegar el acceso a diferentes personas o para controlar el uso de los recursos. También es posiblepara definir los límites superior e inferior sobre el uso de diferentes recursos. Conocer las normas de la lista, que son básicamente una combinación de permitir o denegar la palabra clave y los elementos de ACL, desempeñan un papel vital en la consecución de este tipo de control.

LAS LISTAS DE CONTROL (ACL)Listas de control de acceso son los elementos de base en el archivo de configuración de Squid, que ayudan en la identificación de transacciones en la Web, por diversos atributos de la transacción.

TIPOS DE ACLSquid soporta la identificación de los clientes que utilizan el protocolo ident proporcionando el tipo de ACL. Squid intenta conectarse al servidor ident en la máquina cliente y recibe el nombre de usuario correspondiente a la solicitud actual, cuando el tipo de ident ACL se utiliza. El nombre de usuario que Squid recibirá no puede ser el nombre de usuario del usuario

conectado. Por ejemplo, cuando Squid intenta obtener el nombre de usuario de un servidor proxy aguas abajo, se puede obtener el Squid nombre de usuario, proxy,o nadie, en función del valor de la directiva cache_effective_user.Normalmente, no es posible especificar todos los usuarios sobre todo si se tiene una red grande. Para estos casos, Squid ofreceuna palabra clave especial, REQUIRED, que se puede utilizar para hacer cumplir un nombre de usuario para todas las solicitudes. Si se produce una búsqueda de identidad en cualquier nombre de usuario, la ACL es igual, de lo contrario la ACL no será igualada.

PROXY DE AUTENTICACIÓNLa mejor manera de mantener a los chicos malos de un servidor proxy es el uso de la autenticación del proxy. En este caso, el cliente tendrá que introducir un nombre de usuario y contraseña para poder utilizar nuestro servidor proxy. Si la autenticación del proxy está habilitada, el cliente deberá enviar un encabezado adicional con credenciales de autenticación, que Squid evaluar y comprobar si el cliente se debe permitir utilizar nuestro servidor proxy. La parte interesante es que Squid no puede validar las credenciales enviadas por el cliente por su cuenta. Squid pasa las credenciales que recibe de un cliente a un proceso de ayuda, y la validez de las credenciales se determina por el proceso externo.Por lo tanto, tenemos el tipo proxy_auth ACL en el que podemos especificar una lista de nombres de usuario para la autenticación. Sin embargo, como hemos visto anteriormente, Squid no puede validar las credenciales de sí mismo, hay que especificar al menos un esquema de autenticación para validar el nombre de usuario y la contraseña enviada por el cliente. Esquemas de autenticación se configuran con las directivas auth_paramen nuestro archivo de configuración de Squid.

INSTALACION Y CONFIGURACION DE SQUID

Para poder instalar instalar el servicio de squid tendremos que ejecutar lo siguiente como usuario root.Yum –y install squid*

La configuración del servidor proxy SQUID se realiza en un único archivo de texto plano generalmente ubicado en /etc/squid/squid.conf. La sintaxis en este archivo debe comenzar en la primera columna, sin dejar espacios.gedit squid.conf

Parámetro http_port

En este parámetro configuramos el puerto de escucha de nuestro servidor squid, por default es el puerto 3128, pero también puede ser utilizado el 8080; y utiliza el 3130 para comunicarse mediante ICP (Internet Cache Protocol) con otras caches.http_port 3128icp_port 3130

Parámetro cache_mem

Establece la cantidad de memoria RAM dedicada para almacenar los datos más solicitados. Esta opción viene comentada por los cual la des comentaremos para darle un valor reservado en memoria RAM.

# cache_mem 8 MBpor cache_mem 50 MB

El valor ya depende del administrador y de la carga que tenga el squid.

Parámetros cache_swap

Dentro del cache_swap, existen dos parámetros: cache_swap_low y cache_swap-high. Con estos le indicamos a squid que mantenga los

niveles del espacio del area de intercambio o también conocido como swap. Estos parámetros viene siempre desactivados por cual los buscaremos para activarlos.

#cache_swap_low 90

#cache_swap_high 95

por

cache_swap_low 90 cache_swap_high 95

Con esto decimos al squid que mantenga los niveles del espacio del área de intercambio entre 90% y 95%.

Parámetros maximum_object_size

Utilizamos esta directiva para indicar el tamaño máximo para los objetos a almacenar en la cache.

#maximum_object_size 4096 KB

pormaximum_object_size 1024 MB

Parámetro hierarchy_stoplist

Este parámetro es útil para indicar a squid que paginas que contengan ciertos caracteres no deben almacenarse en cache. También se pueden incluir como sitios de webmail y paginas locales en su red ya que no sería necesario almacenarlas en el cache, esta opción ya viene habilitada solamente tendremos que modificarle algunos datos de la misma.

hierarchy_stoplistcgi-bin ? por hierarchy_stoplistcgi-bin ? Hotmail gmail yahoo

Parámetro visible_hostname

Es el nombre del equipo, el nombre debe ser igual a los siguientes ficheros /etc/hosts y en /etc/sysconfig/network. Este parametro no viene configurado en el archivo de configuracion, tendremos que agregar y que en ocasiones pueda ser que nuestro servicio de squid no quiera iniciar.

visible_hostname nombrehost

Parámetro cache_dir

Con este parámetro establecemos el tamaño que deseamos que tenga la cache en el disco, lo cual tendremos que habilitar y modificar el siguiente dato.

#cache_dir ufs /var/spool/squid 100 16 256por

cache_dir ufs /var/spool/squid 700 16 256

Con esto establecemos el tamaño que deseamos que tenga la cache en el disco, se puede incrementar hasta el tamaño que desee el administrador, nosotros establecemos 700MB de cache con 16 directorios subordinados y 256 niveles cada uno.

Parámetro access_log

Especifica en que directorio se realizara el registro de accesos al squid, este parámetro es importante para definir un análisis de estadísticas con webalizer.

access_log /var/log/squid/access.log squid

Parámetro cache_log

Define en donde se almacenaran los mensajes del comportamiento de la cache de squid. Por default viene desactivado.

cache_log /var/log/squid/cache.log

Reglas acl

Una ACL es una definición de control de acceso, que utiliza squid para especificar mediante el tipo de acceso; la entrada hacia la red o Internet, existen varios tipos de reglas ACL que comentaremos en la tabla.

Src(Origen) Time(Tiempo)

Dst(Destino) url_regex

Srcdomain(Dominio de urlpath_regex

Origen)

Dstdomain(Dominio de Destino)

req_mime

srcdom_regexMacaddress(Direccion MAC)

dstdom_regex password

Regla Tipo src

Esta regla especifica una o varias dirección IP de origen o un segmento de red con su máscara de red. Nomenclatura:

acl [Nombre] src [Contenido]

Ejemplos:

1) El nombre de la regla es llamada redlocal la cual tendría asignada un segmento de red 192.168.1.0 a 24 bits.

acl redlocal src 192.168.1.0/24

2) Esta regla es llamada jefes de los cuales solamente se le proporcionan algunas IP de nuestro segmento de red.

acl jefes src 192.168.1.10 192.168.1.20

3) Esta regla que se llama sistemas en la cual manda a llamar al archivo permitidos el cual se encuentra en /etc/squid, contiene las IP de la gente que trabaja en el área de sistemas.

acl sistemas src “/etc/squid/permitidos”

Regla Tipo dst

Especifica una dirección de destino en formato IP y mascara o el nombre del sitio a visitar. Nomenclatura:

acl [Nombre] dst [Contenido]

Ejemplos:

1) En esta regla es llamada webmail la cual contendrá como destino final las direcciones de webmail mas conocidos de internet.

acl webmail dst www.gmail.com www.hotmail.com www.yahoo.com

2) En esta regla es llamada iplocales la cual contendrá algunas de la IP de nuestro segmento de red.

acl iplocales dst 192.168.1.109 192.168.1.103

Regla Tipo srcdomain.

La regla de tipo srcdomain se establecen permisos sobre dominios web de origen y se determina por la resolución de DNS inversa. Para poder ocupar esta regla es necesario contar un DNS local. Nomenclatura:

acl [Nombre] srcdomain [Contenido]

Ejemplo:

La regla repos indica que máquinas de nuestra red local están agregadas a la misma.

acl repos srcdomain repoubu.dyndns.net repodeb.dyndns.net repocen.dyndns.net

Regla Tipo dstdomain

La regla de tipo dstdomain se establecen permisos sobre dominios web de destino. Nomenclatura:

acl [Nombre] dstdomain [Contenido]

Ejemplo:

La regla permitidos indicamos que dominios pueden estar hacia la salida a internet

acl pemitidos dstdomain .linuxparatodos.net .factor.com.mx .eluniversal.com .reforma.com

Regla Tipo srcdom_regex

Esta regla se encarga de evaluar palabras de entrada a nuestra red, ocupándose expresiones regulares. Nomenclatura:

acl [Nombre] srcdom_regex [Contenido]

Ejemplo:

La regla intranet analiza todas las posibles palabras de factor en mayúsculas y minúsculas de nuestra red local.

acl intranet srcdom_regex -i factor\..*

Regla Tipo dstdom_regex

Esta regla se encarga de evaluar palabras de salida, ocupándose expresiones regulares. Nomenclatura:

acl [Nombre] dstdom_regex [Contenido]

Ejemplo:

La regla google_todos analiza todas las posibles palabras de google en mayúsculas y minúsculas.

acl google_todos dstdom_regex -i google\..*

Regla Tipo time

Esta regla establece un tiempo límite de conexión dentro de una semana. Parámetros por días de la semana:

Parámetro DíaS LunesM MartesT MiércolesH JuevesW ViernesF SábadoA Domingo

D Todos los Días

En el manejo de las horas se establece un horario de 24:00 hrs Nomenclatura:

acl [Nombre] time [días] [horainicio]-[horafin]

Ejemplo:

La regla horario establece que está habilitada los días Lunes a Viernes de 09:00 a 18:00 hrs.

acl horario time MTWHF 09:00-18:00

Regla Tipo url_regex

Permite especificar expresiones regulares para comprobar dicha url, a este tipo de regla se recomienda tener un archivo en cual agregamos todas la palabras que nosotros creamos que importantes. Nomenclatura:

acl [Nombre] url_regex “Path”

Ejemplo de archivo porno.txt:

Sexxxx adultpornotube chicas porn playboy lolitas

Ejemplo:

Esta regla se llama porno el cual manda a llamar a un archivo que contiene palabras relacionadas a pornografía.

acl porno url-regex “/etc/squid/porno”

Regla Tipo urlpath_regex

Esta regla nos permite la administración de descargas por medio de la extensión de los archivos, se recomienda tener Nomenclatura:

acl [Nombre] urlpath_regex “Path”

Ejemplo de archivo extensiones.txt:

\.avi$\.mpg$ \.mpeg$ \.avi$ \.flv$ \.exe$ \.bat$ \.zip$ \.mp3$

Ejemplo:

Esta regla se llama extensiones la cual administrará las descargas por medio de la extensiones de los archivos.

acl extensiones urlpath_regex “/etc/squid/extensiones”

Otra forma:acl videos urlpath_regex -i \.(avi|mp4|mov|m4v|mkv|flv)(\?.*)?$

Regla Tipo req_mime

Esta regla nos permite comprobar el tipo de petición mime que realiza un cliente. Nomenclatura:

acl [Nombre] req_mime “mime”

Ejemplo:

Esta regla se llame MSN la cual contiene el mime del mensajero MSN.

acl MSN req_mime type application/x-msn-messenger

Regla Tipo macaddress

Este tipo de regla nos permite administrar squid por medio de Mac Address. Nomenclatura:

acl [Nombre] arp “Mac Address”

Ejemplo: Esta regla se llama adminmac en la cual nosotros proporcionamos el Mac Address de las máquinas clientes.

acl adminmac arp 09:00:2b:23:45:67 00:1f:3c:5f:fd:b1 00:1e:ec:70:7e:24

Regla Tipo password

Este tipo de regla, se controla el acceso a internet por medio de un usuario y password, para poder habilitar este método tendremos que hacer lo siguientes pasos de configuración.

1) Creamos el archivo que contendrá las claves. touch claves

2) Le asignamos permisos de Lectura/Escritura y el usuario encargado del archivo. chmod 600 claveschown squid:squid claves

3) Creación de usuario y password para el acceso a internet. htpasswd claves clientes

4) Habilitaremos las siguientes opciones dentro del fichero de configuración del servidor squid, busquemos el primer parámetro llamado auth_param basic.

#auth_param basic program <uncomment and complete this line>

Este parámetro lo modificaremos de la siguiente manera.

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

Estamos enlazando la aplicación que nos permitiría autenticarnos y en donde se encuentra el archivo donde se encuentran las cuentas de los usuarios.

5) Por ultimo tendremos que habilitar la regla acl encargada de la autenticación de password.

#acl password proxy_auth REQUIRED por

acl password proxy_auth REQUIRED Con esto ya tendremos habilitada la regla para la autenticación de los usuarios.

Control de Acceso

El control de acceso define si se permite o deniega el acceso a las reglas para que empecemos a crear el filtrado. Nomenclatura:

http_access allow/Deny Regla

Ejemplo:

Como sabemos la regla jefes contendrá la IP de las personas encargadas de cada área de la empresa y tendrán acceso a todo el internet.

http_access allow jefesTodos los demás clientes de la red no tendrán acceso a internet. http_access deny redlocal

Dentro de la configuración http_access, existe una expresión “!” que significa no, esto permite que una regla se permitida o denegada. Es lo contrario a la primera definición del control de acceso.

Ejemplo: Esta regla permite navegar a todo la red en un horario de 09:00 a 18:00 Hrs y solamente a la paginas permitidas por el administrador. Pero no pueden entrar hacia los otros recursos de internet. http_access deny redlocal !horario !permitidos

Configuración básica squid

Como vemos en el siguiente diagrama de red, especificaremos las siguientes reglas que tendrá nuestra red.

Todas las computadoras de la empresa se encuentran dentro del segmento de red 192.168.1.0/24.

Los jefes de cada departamento tienen salida a sin ninguna restricción a internet y sus IP son 92.168.1.10, 192.168.1.20.

El resto de la red solamente tiene acceso a la página de la empresa Factor y de interés social, con un horario de 08:00 a 19:00 hrs, sin poder descargar archivos de música y vídeos.

Crearemos las reglas del squid.

acl redlocal src 192.168.1.0/24 acl jefes src 192.168.1.10 192.168.1.20

acl permitidas dstdomain “/etc/squid/permitidas”

acl horario time MTWHF 08:00-19:00

acl extensiones urlpath_regex “/etc/squid/extensiones”

Comenzaremos a configurar el control de accesos.

http_access allow jefeshttp_access deny redlocal !permitidas !horario extensiones

Con esto tendremos ya configurado nuestro squid, para poder exportar en proxy desde consola tendremos que hacer lo siguiente:

export http_proxy=http://192.168.1.254:3128

A continuación debemos iniciar el servicio y luego dejarlo estático para que se inicie cada vez que el sistema se reinicie.Service squid startService squid restartChkconfig --level 235 squid on

Configuración de Navegadores Web.

Solo nos falta que en las máquinas clientes configuremos la salida a internet por proxy.

Ejemplos:

Firefox

Menú Herramientas ---> Opciones ---> Avanzadas ---> Red ---> Configuración---> Configuración manual de proxy ---> Poner la dirección IP del servidor proxy en conjunto con su puerto correspondiente ---> Usar el mismo proxy para todo.

Internet Explorer.

Menú Herramientas ---> Opciones de Internet --->Conexiones ---> Configuración de LAN

IptablesEl comportamiento de las tablas IP se basa en pares de reglas y acciones. Las reglas definen en el que los paquetes de paquetes (ej. de una determinada red) una determinada acción (por ejemplo, dejar caer los paquetes) se ejecutará. Netfilter procesa todas las reglas de forma secuencial para cada paquete. Cuando encuentra uno que coincida con una regla determinada, se pronunciará por llamar a la acción definida para esa regla. Las medidas adoptadas pueden ser terminativo o no. Por ejemplo, una acción que pide a netfilter para ignorar un paquete de seguro será llamado y no hay otras normas se aplicarán. Esta es una acción terminativa. Sin embargo, si la acción específica que se debe registrar sólo la existencia del paquete, que hará su trabajo y dejar que netfilter procesar las siguientes reglas. Esta es una acción que no terminativo.

Diagrama de flujo de datosEl flujo de datos dentro de cada tabla / de la cadena en el interior del núcleo de Linux se describe en el gráfico a continuación. En cada cuadro, se etiqueta la cadena que actúa y los nombres de las tablas válidas para cada cadena. El tráfico fluye a través de cada una de las tablas de serie para cada cadena. Por ejemplo, en PREROUTING cadena, están las tablas raw, mangle e nat . Tráfico que fluye a través de esta cadena se pasa por cada una de las tres tablas de forma secuencial.

ReglasDada una determinada cadena / tabla es necesario el uso de reglas para seleccionar en la que los paquetes de una determinada acción tendrá lugar. No todas las reglas se aplican a todas las cadenas. Por ejemplo, una regla que especifica la interfaz de salida de un paquete no se aplica a la cadena PREROUTING, ya que la decisión de enrutamiento no se ha tomado en ese momento.

Hay reglas generales (referido como PARAMETERS en los manuales iptables(8) ) y extensiones (ver MATCH EXTENSIONS en el mismo manual). Las reglas generales son generalmente los mismos a través de diferentes versiones del núcleo. Coincidir las extensiones depende del núcleo en ejecución y la versión Tablas IP (recuerde que las tablas de propiedad intelectual es sólo una herramienta de entorno de usuario para interactuar con netfilter). Es posible tener el caso en que una determinada regla existe en los cuadros de propiedad intelectual, pero es de aplicación correspondiente, no se encuentra en el núcleo en ejecución. En este caso, tratando de utilizar dicha norma se producirá un error.

Las reglas generales son las siguientes:

Regla Descripción

-p PROTOCOL Especificar un protocolo IP (por ejemplo, TCP ,UDP).

-s ADDRESS Especifique una dirección de origen.

-d ADDRESS Especifique una dirección de destino.

-i INTERFACE Especifique una interfaz local de tráfico entrante.

-o INTERFACE Especifique una interfaz local de tráfico de salida.

Las extensiones de los partidos serán tratados a seguir.

Tablas Hay cuatro tablas definidas en iptables, que se encargan de diferentes tipos de procesos

Tabla Sentido

raw Bajo nivel de alteración de paquetes.

nat Los cambios en los encabezados de los paquetes (en NAT se lleva a cabo).

mangle

Se utiliza para realizar modificaciones de paquetes especializados.

filter El filtrado de paquetes.

ObjetivoUn objetivo de especificar la acción a tomar cuando un paquete cumple una regla cierta. Este objetivo puede ser uno de los por defecto (debe estar disponible en todos los granos) o una extensión de destino.

Los objetivos predeterminados son:

Objetivo

Sentido

ACCEPT Deje pasar el paquete.

DROP Instruya a netfilter para ignorar el paquete.

QUEUE Pasar al paquete al espacio de usuario.

RETURN

Desde el manual: "detener el paso en la cadena y continuar con la siguiente regla de la anterior (llamada) de la cadena Si al final de una cadena del sistema se alcanza o una regla de una cadena integrada con el objetivo RETURN coincide, el destino especificado por la política de la cadena determina el destino del paquete. "

En la práctica, la mayoría de las veces que se va a utilizar ya sea ACCEPT o DROP.

Reglas de escrituraDe acuerdo con iptables, hay muchas maneras de agregar / quitar las reglas. Todas las acciones de reglas de complementos, son la operación discreta. Esto sugiere la creación de un script que contiene todos los iptables las llamadas que componen el servidor de seguridad conjunto. Recuerde limpiar todas las reglas pre-existentes al inicio de la secuencia de comandos.

Para añadir una sola regla (al final de los existentes), siga esta forma general:

# Iptables -t [CUADRO]-A [CADENA] [REGLAS]-j [objetivo]

Donde:

Variable Sentido

TABLE Especifique la tabla.

CHAIN Especifique la cadena.

RULES Las reglas para paquetes de selección.

TARGET Acción a tomar su lugar.

aquí sólo trataremos de la tabla nat, por lo que cada vez que escribamos una instrucción comenzaremos con iptables

-t nat.

La tabla nat está formada por tres cadenas:

● PREROUTING: Permite modificar paquetes entrantes antes de que se tome una decisión de enrutamiento.

● OUTPUT: Permite modificar paquetes generados por el propio equipo después de enrutarlos

● POSTROUTING: Permite modificar paquetes justo antes de que salgan del equipo.

Para cadena se especifican reglas, para las que es fundamental el orden, ya que cuando un paquete encuentra una regla que lo define, aplica esa regla y no lee las siguientes.

Parámetros generales

Listar reglasUtilizamos el parámetro -L (normalmente se acompaña de -n para que los resultados se muestran de forma numérica y evitar consultas DNS)

# iptables -t nat -L -n

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Que nos muestra las tres cadenas de la tabla nat y que en este momento no hay ninguna regla aplicada.

VerbosePara una salida más completa de iptables utilizamos el parámetro -v:

# iptables -t nat -L PREROUTING -n -v

Chain PREROUTING (policy ACCEPT 21 packets, 4133 bytes)

pkts bytes target prot opt in out source destination

que nos informa de los paquetes y bytes que “atraviesan” una cadena y en caso de que hubiese reglas, se contarían los paquetes y bytes a los que se ha aplicado cada una.

Borrar contadoresSi queremos poner a cero los contadores de paquete que se aplican en las cadenas de una tabla:

iptables -t nat -Z

Borrar todas las reglas de una cadenaPara borrar todas las reglas de una cadena se escribe:

iptables -t nat -F OUTPUT

Se puede no especificar ninguna cadena, con lo que se borran todas las reglas de todas las cadenas de una tabla:

iptables -t nat -F

iptables -t nat -X

iptables -t nat -Z

Que borra todas las reglas anteriores y pone los contadores a cero.

EjemploSupongamos que tenemos una situación como la de la imagen:

Vamos a ver los pasos que habría que dar para que todos los equipos de la red local tuviesen acceso a Internet y se pudieran alojar servicios en cualquiera de ellos.

Activación del bit de forwardEn principio un equipo con GNU/Linux no permite que pasen paquetes de una interfaz de red a otra, para que se permita esto y por tanto pueda funcionar el equipo como router, o más concretamente en este caso como dispositivo de NAT, hay que activar (dar valor 1) lo que se denomina bit de forward:

echo 1 > /proc/sys/net/ipv4/ip_forward

Esta activación se borra cuando se apaga el equipo, ya que el directorio /proc está en memoria. Para que dicha activación permanezca lo habitual es definirla en el fichero /etc/sysctl.conf, asegurándose de que exista una línea como:

net.ipv4.ip_forward=1

POSTROUTINGTodos los equipos de la red 192.168.3.0/24 están interconectados entre sí, pero en principio no tienen acceso a Internet puesto que sus direcciones IP son privadas y por tanto no son accesibles desde Internet (ningún equipo contestaría a sus peticiones). El equipo que tiene dos interfeces de red sí tiene acceso a Internet ya que la interfaz de red eth0 tiene una dirección IP pública, además pertenece a la red 192.168.3.0/24 ya que está conectado a través de la interfaz de red eth1 con dirección IP 192.168.3.254.

El equipo con dos interfaces de red puede funcionar como dispositivo de NAT (source NAT), aceptando paquetes provenientes del resto de equipos de la red 192.168.3.0/24 que entren por eth1 con destino a cualquier equipo de Internet. Tal como se describe en el ejemplo inicial de SNAT, el dispositivo de NAT debe cambiar la dirección IP origen, pero esto se hace justo antes de enviar el paquete a Internet y por tanto habrá que definirlo en la cadena POSTROUTING.

Source NAT (estático) con iptablesLa regla que hay que poner para que se haga SNAT de todos los equipos de la red 192.168.3.0/24 es tan simple como:

iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -o eth0 -j SNAT --to 80.58.1.14

Explicación de los parámetros:

● -A POSTROUTING: Añade (Add) una regla a la cadena POSTROUTING● -s 192.168.3.0/24: Se aplica a los paquetes que tengan como

dirección origen (source) la 192.168.3.0/24● -o eth0: Se aplica a los paquetes que salgan (out-interface) por eth0● -j SNAT --to 80.58.1.14 (--to aquí es equivalente a --to-source):

Cambia la dirección de origen por la 80.58.1.14

Source NAT (dinámico) con iptablesPodríamos tener un caso similar al anterior, pero en el que la dirección IP pública del equipo que se conecta a Internet fuese dinámica, por lo que no la sabíamos a priori y no sería posible definirla en una regla como la anterior. En ese caso la regla de iptables a utilizar sería:

iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -o eth0 -j MASQUERADE

Donde el único cambio se refiere a la acción (parámetro -j), en este caso es MASQUERADE, que cambia la dirección origen por la que tenga la interfaz de salida (eth0).

MASQUERADE podría funcionar también si la dirección IP de eth0 fuese estática, pero en ese caso se recomienda utilizar SNAT.

PREROUTING(Todo lo que se explica en este punto no se hace con la seguridad en mente, sino simplemente para explicar algunas cosas que se pueden hacer con PREROUTING. En una implementación real, esto tendría que ir combinado con un cortafuegos y un esquema de red diferente).

Para realizar una conexión cliente-servidor entre dos equipos de Internet hay que especificar completamente lo que se denomina socket de Internet, que queda definido con lo siguiente:

● Protocolo (normalmente TCP o UDP)● Dirección IP equipo cliente● Puerto equipo cliente● Dirección IP equipo servidor● Puerto equipo servidor

Si volvemos a nuestro problema, el único equipo de la red local que es accesible desde Internet es el dispositivo de NAT a través de su dirección IP pública 80.58.1.14, ya que sería el único con el que un equipo de Internet podría establecer un socket y por tanto sería el único equipo de la red que podría alojar servicios. Todo esto cambia si utilizamos NAT, ya que en el equipo que tiene las dos interfaces de red podemos cambiar la dirección IP destino (DNAT) de una petición que llegue de Internet y mandarla a un equipo de la red local.

Supongamos que instalamos un servidor web en un equipo de la red local con dirección IP 192.168.3.2 y queremos que sea accesible desde Internet, tendremos que modificar las peticiones que lleguen al puerto 80/tcp des equipo que tiene la dirección IP pública y que cambie la dirección IP destino 80.58.1.14 por 192.168.3.2, esto se hace con la siguiente regla:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to 192.168.3.2

Explicación de los parámetros:

● -A PREROUTING: Añade (Add) una regla a la cadena PREROUTING● -p tcp: Especifica el (p)rotocolo de transporte (tcp en este caso)

● --dport 80 (equivalente a --destination-port 80): Puerto destino 80 (ligada al parámentro anterior)

● -i eth0: Específica eth0 como interfaz de entrada (in-interface)● -j DNAT --to 192.168.3.2 (--to aquí es equivalente a --to-destination):

Cambia la dirección IP destino (inicialmente 80.58.1.14) a 192.168.3.2

Es lógico que haya que hacerlo en la cadena PREROUTING, porque las reglas de esta cadena se aplican antes de tomar la decisión de enrutamiento, así se tomará la decisión de encaminamiento con la nueva dirección IP destino.

Para otros servicios bastaría con poner el protocolo y puerto adecuados, aunque el caso del servicio ftp es más complicado y necesitaría una discusión mas detallada. La principal limitación de utilizar DNAT con una sola dirección pública es que no es posible poner más de un servicio en el mismo puerto, ya que sólo se puede hacer DNAT a un equipo de la red local (el socket debe estar totalmente determinado).

Hay algunos servicios que permiten utilizar puertos diferentes a los estándar, como por ejemplo http, ya que podemos acceder a un servidor web que esté en un puerto diferente al 80/tcp, simplemente especificando en el navegador. Como iptables nos permite no sólo modificar la dirección IP destino sino también el puerto destino, podríamos poner un segundo servidor web en el equipo 192.168.3.3 y añadir la siguiente regla:

iptables -A PREROUTING -p tcp --dport -880 -i eth0 -j DNAT --to 192.168.3.3:80

Donde hemos especificado el puerto destino 880 (que no es un puerto estándar para ningún servicio) y cambiamos tanto la IP destino como el puerto destino con --to 192.168.3.3:80.

Para acceder a ese servicio desde Internet tendremos que escribir en el navegador:

http://80.58.1.14:880

Ejemplo:

1. Creamos y editamos un archivo de extensión sh dentro del directorio /etc

2. En la parte inicial del archivo debemos poner #!/bin/sh. Esta línea es importante ya que ejecutará nuestro archivo de configuración.

3. Eliminamos las reglas anteriores mediante las siguientes líneaso iptables −Fo iptables −Xo iptables −Zo iptables −t nat –F

4. Establecemos políticas por defectoo iptables −P INPUT DROPo iptables −P OUTPUT DROPo iptables −P FORWARD DROPo iptables −t nat −P PREROUTING DROPo iptables −t nat −P POSTROUTING DROP

5. Al local host le dejamos que pase todoo iptables −A INPUT −i lo −j ACCEPT

6. A nuestra direccion IP le dejamos acceso total

o iptables −A INPUT −s 192.20.40.249 −j ACCEPT7. El Puerto 80 de navegacion web debe estar abierto por lo tanto

o iptables −A INPUT −p tcp −−dport 80 −j ACCEPT8. Y el resto de puertos potencialmente riegosos se cierran

o iptables −A INPUT −p tcp −−dport 20:21 −j DROPo iptables −A INPUT −p tcp −−dport 3306 −j DROPo iptables −A INPUT −p tcp −−dport 22 −j DROPo iptables −A INPUT −p tcp −−dport 10000 −j DROP

9. Grabamos el archivo y luego le establecimos permisos de lectura y ejecución al archivo generado

10.Y ahora el paso final, debemos decirle al sistema que ejecute ese script cuando inicie, para eso modificamos el archivo /etc/rc.local y colocamos la dirección del archivo ahí.

11.Verificamos que nuestras reglas se encuentren ejecutando mediante iptables –L -n