Manual Iptables (Firewalls, access rules on LInux)

FIREWALL Y NAT

en Linux

Versión 0.1

Este documento da una introducción a FIREWALL y NAT, y describe cómo activar el iptables en un servidor Linux para utilizarlo con estos servicios.

Roberto Carvajal Salamanca

mailto:[email protected]

Docente Facultad de Ingeniería de Sistemas

Director Grupo Linux UNAB

Jorge Andrés Sáyago P.

[email protected]

Estudiante de Ingeniería de Sistemas

Coordinador Grupo Linux UNAB

Universidad Autónoma de Bucaramanga

Bucaramanga, Colombia, 14 de junio de 2002

TABLA DE CONTENIDO

1 Prólogo y retrospectiva

2. FIREWALLS Y SEGURIDAD EN INTERNET

Introducción

2.1 Firewalls

2.1.1 Beneficios de un firewall en Internet

2.1.2 Limitaciones de un firewall

2.2 Bases para el diseño decisivo del firewall

2.2.1 Políticas del firewall

2.2.2 Política interna de seguridad

2.2.3. Costo del firewall

2.2.4 Componentes del sistema firewall

2.3 Software filtra-paquetes

2.3.1 Servicio dependiente del filtrado

2.3.2 Servicio independiente del filtrado

2.3.3 Beneficios del software filtra-paquetes

2.3.4 Limitaciones del filtra-paquetes

3. NAT (Network Address Translator) 3.1 NAT

3.1.1 ¿Quién puede beneficiarse de NAT?

3.1.2 ¿Quién no necesita NAT?

3.2 ¿Cómo funciona NAT?

4. IPTABLES 4.1 ¿Qué es iptables?

4.2 Uso básico de iptables

4.2.1 Crear una nueva regla al final de las ya existentes en una chain determinada

4.2.2 Insertar una regla en una posición determinada de la lista de reglas de una chain determinada

4.2.3 Borrar una regla en una posición determinada de la lista de reglas de una chain determinada

4.2.4 Borrar todas las reglas de una chain determinada

4.2.5 Listar las reglas de una chain determinada

4.2.6 Explicación de parámetros

4.3 iptables como FIREWALL

4.3.1 Creación de un firewall doméstico (ejemplo 1)

4.3.2 Creación de un firewall avanzado (ejemplo 2)

4.4 iptables como NAT

4.4.1 Creación de un NAT básico (ejemplo único)

# Compartir de archivos

# Mensajería instantánea

# Otros

4.5 Herramientas de iptables

4.5.1 iptables-save

4.5.2 iptables-restore

5. Anexos 5.1 FireStarter (GUI para configurar iptables)

5.2 Hogwash (mezcla de Firewall y NIDS)

6. Bibliografía y créditos

1 Prólogo y retrospectiva

Encontramos muy sencillo, como nuevo usuario, configurar iptables en los núcleos nuevos, esto es, 2.4.x. Existen diversos documentos y páginas web que explican en detalle este procedimiento. Consideramos que los problemas que se pueden presentar para aprender iptables tienen como origen la falta de conocimientos relacionados con la forma en que se comunican entre sí máquinas en red, más que a la estructura de creación de reglas de filtrado del iptables.

Decidimos escribir esta guía como punto de partida para nuevos usuarios. Esta guía está basada en otros documentos encontrados en la red, en libros y en experiencias propias. Los autores de los documentos desde los que se extrajeron apartes son mencionados al final de ésta guía. Nuestra labor fue complementar, recopilar y corregir detalles de dichos textos, así como darle el orden que tiene, para que su entendimiento fuese rápido.

Por favor siéntase libre de enviarme cualquier crítica o comentario a [email protected] ó [email protected]. Si algo de lo aquí explicado le parece erróneo, o si echa algo de menos, sus comentarios serán bienvenidos y de seguro podrán influenciar el futuro de esta guía.

La primera parte de esta guía contiene información teórica de la aplicación de firewalls para aumentar la seguridad de los servidores, pretendiendo dar conocimientos básicos generales que permitan entender la importancia y el significado de este mecanismo de seguridad. La segunda parte está pensada

para ser rápida a fin conseguir que el iptables funcione en el plazo de tiempo más corto posible.

Podrá encontrar las últimas novedades de esta guía, a partir de agosto de 2002, en la dirección: http://www.ColombiaLinux.org, el cual será un Portal de Noticias Linux para la población colombiana, principalmente (cuña publicitaria).

Si tiene alguna pregunta técnica sobre iptables por favor entre a una lista de correo de Linux o en la documentación que acompaña al iptables.

Este documento puede redistribuirlo bajo los términos de la GNU General Public License.

Los autores no se responsabilizan de ningún daño sufrido debido a las acciones realizadas basadas en este documento.

2. FIREWALLS Y SEGURIDAD EN INTERNET

Introducción

La seguridad ha sido el tema principal a tratar cuando una organización desea conectar su red privada a Internet. Sin tomar en cuenta el tipo de negocios, se ha incrementado el numero de usuarios de redes privadas por la demanda del acceso a los servicios de Internet. Tal es el caso de la World Wide Web (WWW), Internet Mail (e-mail), Telnet, y File Transfer Protocol (FTP). Adicionalmente las organizaciones buscan las ventajas que ofrecen las paginas en el WWW y los servidores FTP de acceso público en el Internet.

Los administradores de red tienen que incrementar todo lo relacionado con la seguridad de sus sistemas, debido a que se expone la organización privada de sus datos así como la infraestructura de su red a los Expertos de Internet (Internet Crakers). Para superar estos temores y proveer el nivel de protección requerida, la organización necesita seguir una política de seguridad para prevenir el acceso no-autorizado de usuarios a los recursos propios de la red privada, y protegerse contra la exportación privada de información. Todavía, aun si una organización no está conectada a Internet, ésta debería establecer una política de seguridad interna para administrar el acceso de usuarios a porciones de red y proteger sensitivamente la información secreta.

2.1 Firewalls

Un firewall (muro de fuego) en Internet es un sistema o grupo de sistemas que impone una política de seguridad entre la organización de red privada y el Internet. El firewall determina cuáles de los servicios de red pueden ser accesados dentro de ésta por los que están fuera, es decir, quién puede entrar a utilizar los recursos de red pertenecientes a la organización.

Para que un firewall sea efectivo, todo trafico de información a través de Internet deberá pasar a través del mismo, donde podrá ser inspeccionada la información. El firewall podrá únicamente autorizar el paso del trafico, y él mismo podrá ser inmune a la penetración. Desafortunadamente, este sistema no puede ofrecer protección alguna una vez que el agresor lo traspasa o permanece en torno a éste.

Esto es importante, ya que debemos notar que un firewall de Internet no es justamente un ruteador, un servidor de defensa, o una combinación de elementos que proveen seguridad para la red. El firewall es parte de una política de seguridad completa que crea un perímetro de defensa diseñada para proteger las fuentes de información. Esta política de seguridad podrá incluir publicaciones con las guías de ayuda donde se informe a los usuarios de sus responsabilidades, normas de acceso a la red, política de servicios en la red, política de autenticidad en acceso remoto o local a usuarios propios de la red, normas de dial-in y dial-out, reglas de encriptación de datos y discos, normas de protección de virus, y entrenamiento. Todos los puntos potenciales de ataque en la red podrán ser protegidos con el mismo nivel de seguridad. Un firewall de Internet sin una política de seguridad comprensiva es como poner una puerta de acero en una tienda.

2.1.1 Beneficios de un firewall en Internet

Los firewalls en Internet administran los accesos posibles del Internet a la red privada. Sin un firewall, cada uno de los servidores propios del sistema se expone al ataque de otros servidores en Internet.

El firewall permite al administrador de la red definir un "choke point" (embudo), manteniendo al margen los usuarios no-autorizados (tal como hackers, crakers, vándalos, y espías) fuera de la red, prohibiendo potencialmente la entrada o salida al vulnerar los servicios de la red, y proporcionar la protección para varios tipos de ataques posibles. Uno de los beneficios clave de un firewall en Internet es que ayuda a simplificar los trabajos de administración, una vez que se consolida la seguridad en el sistema firewall, es mejor que distribuirla en cada uno de los servidores que integran nuestra red privada.

El firewall ofrece un punto donde la seguridad puede ser monitoreada. Si aparece alguna actividad sospechosa, éste generara una alarma ante la posibilidad de que ocurra un ataque, o suceda algún problema en el tránsito de los datos.

Un firewall de Internet es el punto perfecto para auditar o registrar el uso del Internet. Esto permite al administrador de red justificar el gasto que implica la conexión a Internet, localizando con precisión los cuellos de botella potenciales del ancho de banda, y promueve el método de cargo a los departamentos dentro del modelo de finanzas de la organización.

Un firewall de Internet ofrece un punto de reunión para la organización. Si una de sus metas es proporcionar y entregar servicios información a consumidores, el firewall de Internet es ideal para desplegar servidores WWW y FTP.

Finalmente, el firewall puede presentar los problemas que genera un punto de falla simple. Enfatizando, si este punto de falla se presenta en la conexión a Internet, aun así la red interna de la organización puede seguir operando -únicamente el acceso a Internet está perdido-.

La preocupación principal de un administrador de red son los múltiples accesos a Internet, que se pueden registrar con un monitor y un firewall en cada punto de acceso que posee la organización hacia el Internet. Estos dos puntos de acceso significa dos puntos potenciales de ataque a la red interna que tendrán que ser monitoreados regularmente.

2.1.2 Limitaciones de un firewall

Un firewall no puede proteger contra aquellos ataques que se efectúen fuera de su punto de operación.

Por ejemplo, si existe una conexión dial-out sin restricciones que permita entrar a nuestra red protegida, el usuario puede hacer una conexión SLIP o PPP a Internet. Los usuarios con sentido común suelen "irritarse" cuando se requiere una autenticación adicional requerida por un Firewall Proxy server (FPS) lo cual se puede ser provocado por un sistema de seguridad circunvecino que está incluido en una conexión directa SLIP o PPP del ISP.

Este tipo de conexiones deriva la seguridad provista por firewall construido cuidadosamente, creando una puerta de ataque. Los usuarios pueden estar conscientes de que este tipo de conexiones no son permitidas como parte integral de la arquitectura de la seguridad en la organización.

El firewall no puede proteger de las amenazas a que está sometido por traidores o usuarios inconscientes. El firewall no puede prohibir que los

traidores o espías corporativos copien datos sensitivos en disquetes o tarjetas PCMCIA y substraigan éstas del edificio.

El firewall no puede proteger contra los ataques de la "Ingeniería Social", por ejemplo un Hacker que pretende ser un supervisor o un nuevo empleado despistado, persuade al menos sofisticado de los usuarios a que le permita usar su contraseña al servidor del corporativo o que le permita el acceso "temporal" a la red.

Para controlar estas situaciones, los empleados deberían ser educados acerca de los varios tipos de ataque social que pueden suceder, y a cambiar sus contraseñas si es necesario periódicamente. El firewall no puede proteger contra los ataques posibles a la red interna por virus informativos a través de archivos y software. Obtenidos del Internet por sistemas operativos al momento de comprimir o descomprimir archivos binarios, el firewall de Internet no puede contar con un sistema preciso de SCAN 4 para cada tipo de virus que se puedan presentar en los archivos que pasan a través de él.

La solución real está en que la organización debe ser consciente en instalar software anti-viral en cada despacho para protegerse de los virus que llegan por medio de disquetes o cualquier otra fuente.

Finalmente, el firewall de Internet no puede proteger contra los ataques posibles en la transferencia de datos, estos ocurren cuando aparentemente datos inocuos son enviados o copiados a un servidor interno y son ejecutados despachando un ataque.

Por ejemplo, una transferencia de datos podría causar que un servidor modificara los archivos relacionados a la seguridad haciendo más fácil el acceso de un intruso al sistema.

Como nosotros podemos ver, el desempeño de los servidores Proxy en un servidor de defensa es un excelente medio de prohibición a las conexiones directas por agentes externos y reduce las amenazas posibles por los ataques con transferencia de datos.

2.2 Bases para el diseño decisivo del firewall

Cuando se diseña un firewall de Internet, se tiene que tomar algunas decisiones que pueden ser asignadas por el administrador de red:

• Posturas sobre la política del Firewall. • La política interna propia de la organización para la seguridad total. • El costo financiero del Proyecto "Firewall". • Los componentes o la construcción de secciones del Firewall.

2.2.1 Políticas del firewall

Las posturas del sistema firewall describen la filosofía fundamental de la seguridad en la organización. Estas son dos posturas diametralmente opuestas que la política de un firewall de Internet puede tomar:

• "No todo lo específicamente permitido está prohibido" • "Ni todo lo específicamente prohibido está permitido"

La primera postura asume que un firewall puede obstruir todo el tráfico y cada uno de los servicios o aplicaciones deseadas necesariamente para ser implementadas básicamente caso por caso.

Esta propuesta es recomendada únicamente a un limitado número de servicios soportados cuidadosamente seleccionados en un servidor. La desventaja es que el punto de vista de "seguridad" es más importante que - facilitar el uso - de los servicios y éstas limitantes numeran las opciones disponibles para los usuarios de la comunidad. Esta propuesta se basa en una filosofía conservadora donde se desconocen las causas acerca de los que tienen la habilidad para conocerlas.

La segunda postura asume que el firewall puede desplazar todo el trafico y que cada servicio potencialmente peligroso necesitará ser aislado básicamente caso por caso. Esta propuesta crea ambientes más flexibles al disponer mas servicios para los usuarios de la comunidad. La desventaja de esta postura se basa en la importancia de "facilitar el uso" que la propia - seguridad – del sistema. También además, el administrador de la red está en su lugar de incrementar la seguridad en el sistema conforme crece la red. Desigual a la primer propuesta, esta postura está basada en la generalidad de conocer las causas acerca de los que no tienen la habilidad para conocerlas.

2.2.2 Política interna de seguridad

Tan discutidamente escuchada, un firewall de Internet no está solo - es parte de la política de seguridad total en una organización -, la cual define todos los aspectos en lo competente al perímetro de defensa. Para que ésta sea exitosa, la organización debe conocer qué es lo se está protegiendo. La política de seguridad se basará en una conducción cuidadosa analizando la seguridad, la asesoría en caso de riesgo, y la situación del negocio. Si no se posee la información detallada de la política a seguir, aunque sea un firewall cuidadosamente desarrollado y armado, estará exponiendo la red privada a un posible atentado.

2.2.3. Costo del firewall

¿Cuánto puede ofrecer una organización por su seguridad?. Un simple paquete de filtrado firewall puede tener un costo mínimo ya que la organización necesita un ruteador conectado al Internet, y dicho paquete ya está incluido como estándar del equipo. Un sistema comercial de firewall provee un incremento más a la seguridad pero su costo aumenta dependiendo de la complejidad y el número de sistemas protegidos. Si la organización posee al experto en casa, un firewall casero puede ser construido con software de dominio público, pero este ahorro de recursos repercute en términos del tiempo de desarrollo y el despliegue del sistema firewall.

Finalmente requiere de soporte continuo para la administración, mantenimiento general, actualización de software, reparación de seguridad, e incidentes de manejo.

2.2.4 Componentes del sistema firewall

Después de las decisiones acerca de los ejemplos previos, la organización puede determinar específicamente los componentes del sistema. Un firewall típico se compone de uno, o una combinación, de los siguientes obstáculos.

• Filtra-paquetes. • Gateway a Nivel-aplicación. • Gateway a Nivel-circuito.

En esta guía se discutirá lo referente a las opciones para la edificación de obstáculos basados en el sistema filtra-paquetes nativo de Linux. Se describirá cómo se puede trabajar con él para construir un efectivo sistema firewall de Internet.

2.3 Software filtra-paquetes

Toma las decisiones de rehusar / permitir el paso de cada uno de los paquetes que son recibidos. El programa examina cada data grama para determinar si este corresponde a uno de sus paquetes filtrados y que a su vez haya sido aprobado por sus reglas. Las reglas de filtrado se basan en revisar la información que poseen los paquetes en su encabezado, lo que hace posible su desplazamiento en un proceso de IP. Esta información consiste en la dirección IP fuente, la dirección IP destino, el protocolo de encapsulado (TCP, UDP,ICMP, o IP tunnel), el puerto fuente TCP/UDP, el puerto destino TCP/UDP, el tipo de mensaje ICMP, la interfaz de entrada del paquete, y la interfaz de salida del paquete. Si se encuentra la correspondencia y las reglas permiten el paso del paquete, éste será desplazado de acuerdo a la información de la tabla de filtrado, si se encuentra la correspondencia y las reglas niegan el paso, el paquete es descartado. Si éstos no corresponden a las reglas, un parámetro

configurable por incumplimiento determina descartar o desplazar el paquete.

2.3.1 Servicio dependiente del filtrado

Las reglas acerca del filtrado de paquetes a través de un programa para rehusar / permitir el tráfico está basado en un servicio especifico, desde entonces muchos servicios vierten su información en numerosos puertos TCP/UDP conocidos.

Por ejemplo, un servidor Telnet está a la espera para conexiones remotas en el puerto 23 TCP y un servidor SMTP espera las conexiones de entrada en el puerto 25 TCP. Para bloquear todas las entradas de conexión Telnet, el filtro simplemente descarta todos los paquetes que contengan el valor del puerto destino TCP igual a 23. Para restringir las conexiones Telnet a un limitado numero de servidores internos, el filtro podrá rehusar el paso a todos aquellos paquetes que contengan el puerto destino TCP igual a 23 y que no contengan la dirección destino IP de uno de los servidores permitidos.

Algunas características típicas de filtrado que un administrador de redes podría solicitar en un filtra-paquetes para perfeccionar su funcionamiento serian:

• Permite la entrada de sesiones Telnet únicamente a una lista especifica de servidores internos

• Permite la entrada de sesiones FTP únicamente a los servidores internos especificados

• Permite todas las salidas para sesiones Telnet • Permite todas las salidas para sesiones FTP • Rehusar todo el trafico UDP

2.3.2 Servicio independiente del filtrado

Este tipo de ataques ciertamente es difícil de identificar usando la información básica de los encabezados debido a que éstos son independientes al tipo de servicio. Los filtros pueden ser configurados para protegerse de este tipo de ataques pero son más difíciles de especificar, por lo tanto, las reglas para el filtrado requieren de información adicional que pueda ser estudiada y examinada por la tabla de filtrado, inspeccionando las opciones especificas IP, revisando fragmentos especiales de edición, etc. Algunos ejemplos de este tipo de ataques incluye:

Agresiones originadas por el direccionamiento IP

Para este tipo de ataque, el intruso trasmite paquetes desde afuera pretendiendo pasar como servidor interno - los paquetes poseen una dirección fuente IP falsa de un servidor interno del sistema -. El agresor espera que usando este impostor se pueda penetrar al sistema para emplearlo

seguramente como dirección fuente donde los paquetes que trasmita sean autentificados y los del otro servidor sean descartados dentro del sistema. Los ataques por seudo-fuentes pueden ser frustrados si descartamos la dirección fuente de cada paquete con una dirección fuente "interna" si el paquete llega a una de las interfaces del filtro "externo".

Agresiones originadas en el filtro

En un ataque de filtro, la estación de origen especifica la ruta que un paquete deberá tomar cuando cruce a través del Internet. Este tipo de ataques es diseñado para cuantificar las derivaciones de seguridad y encauzan al paquete por un inesperado camino a su destino. Los ataques originados en el filtro pueden ser frustrados simplemente descartando todos los paquetes que contengan fuentes de filtrado opcionales.

Agresiones por fragmentación

Por este tipo de ataques, los intrusos utilizan las características de fragmentación para crear fragmentos extremadamente pequeños y obligan a la información del encabezado TCP a separarse en paquetes. Estos pequeños fragmentos son diseñados para evitar las reglas definidas por el filtrado, examinando los primeros fragmentos y el resto pasa sin ser visto. Aunque si bien únicamente es explotado por sencillos decodificadores, una agresión pequeñísima puede ser frustrada si se descartan todos los paquetes donde el tipo de protocolo es TCP y la fragmentación de compensación IP es igual a 1.

2.3.3 Beneficios del software filtra-paquetes

La mayoría de sistemas firewall son desplegados usando únicamente filtra-paquetes. Otros, planean los filtros y configuran el ruteador, sea este pequeño o no. El costo para implementar la filtración de paquetes no es cara, desde que los componentes básicos de los ruteadores incluyen revisiones estándar de software para dicho efecto. Desde entonces el acceso a Internet es generalmente provisto a través de interfaces WAN, optimizando la operación del filtro, moderando el tráfico y definiendo menos filtros. Finalmente, el filtra-paquetes es por lo general transparente a los usuarios finales y a las aplicaciones por lo que no se requiere de entrenamiento especializado o software específico que tenga que ser instalado en cada uno de los servidores.

2.3.4 Limitaciones del filtra-paquetes

Definir el filtrado de paquetes puede ser una tarea compleja porque el administrador de redes necesita tener un estudio detallado de varios servicios de Internet, como los formatos del encabezado de los paquetes, y los valores

específicos esperados a encontrarse en cada campo. Si las necesidades de filtrado son muy complejas, se necesitará soporte adicional, con lo cual el conjunto de reglas de filtrado puede empezar a complicarse y alargar el sistema, haciendo más difícil su administración y comprensión. Finalmente, éstas serán menos fáciles de verificar para las correcciones de las reglas de filtrado después de ser configuradas. Potencialmente se puede dejar una localidad abierta sin probar su vulnerabilidad.

Cualquier paquete que pasa directamente a través de un filtra-paquetes puede ser posiblemente usado como parte inicial de un ataque dirigido de datos. Haciendo memoria, este tipo de ataques ocurren cuando los datos aparentemente inocuos se desplazan por el filtro a un servidor interno. Los datos contienen instrucciones ocultas que pueden causar que el servidor modifique su control de acceso y seguridad relacionando sus archivos y facilitando al intruso el acceso al sistema.

Generalmente, los paquetes en torno al filtro disminuyen conforme el número de filtros utilizados se incrementa. Los filtra-paquetes son optimizados para extraer la dirección destino IP de cada paquete, haciendo relativamente simple la consulta a la tabla de reglas de filtrado, y el desplazamiento de paquetes para la interfaz apropiada de la transmisión. Esto puede consumir ciclos de CPU e impactar el perfecto funcionamiento del sistema. El filtrado de paquetes IP no puede ser capaz de proveer el suficiente control sobre el tráfico. Un filtra-paquetes puede permitir o negar un servicio en particular, pero no es capaz de comprender el contexto / dato del servicio.

Por ejemplo, un administrador de red necesita filtrar el trafico de la capa de aplicación - limitando el acceso a un subconjunto de comandos disponibles por FTP o Telnet-, bloquear la importación de Mail o Newsgroups concerniente a tópicos específicos. Este tipo de control es muy perfeccionado a las capas altas por los servicios de un servidor Proxy y en Gateways a Nivel-aplicación.

3. NAT (Network Address Translator)

Con el paso de algunos años, Internet ha experimentado una crisis en las direcciones, logrando que el direccionamiento IP sea menos generoso en los recursos que proporciona. Por este medio se organizan las compañías conectadas a Internet, debido a esto hoy no es posible obtener suficientes registros de direcciones IP para responder a la población de usuarios en demanda de los servicios. Un firewall, además de servir como filtro de paquetes, es un lugar apropiado para desplegar un Traductor de Direcciones de Red (NAT). Esto puede ayudar aliviando el espacio de direccionamiento,

acortando y eliminando lo necesario para re-enumerar cuando la organización cambie del Proveedor de Servicios de Internet (ISP) .

Es posible conectar sus máquinas clientes (corriendo con cualquier sistema operativo) al servidor, tanto con Ethernet como con otro tipo de conexiones, como es el caso de enlaces ppp.

3.1 NAT

Si un servidor está conectado a Internet con el servicio de NAT habilitado, las computadoras conectadas a él (bien en la misma red local, bien por módem) también pueden conectarse a Internet, incluso aunque no tengan una dirección IP oficial asignada.

Esto permite a un conjunto de máquinas acceder transparentemente a Internet ocultas tras la máquina pasarela, la cual aparece como el único sistema que está usando Internet.

3.1.1 ¿Quién puede beneficiarse de NAT?

Si tiene un servidor conectado a Internet, y

• si tiene algunas computadoras con TCP/IP conectadas con esa máquina en una subred local (LAN) , y/o

• si su servidor tiene más de un módem y actúa como un servidor PPP o SLIP conectando a otros, los cuales no tienen asignada una dirección IP oficial. (Estas máquinas son representadas por otras máquinas presentes).

• y por supuesto, si quiere que esas otras máquinas estén en Internet sin gastar dinero extra

3.1.2 ¿Quién no necesita NAT?

Si su máquina es un servidor aislado conectado a Internet, es inútil usar NAT, o

• si ya tiene direcciones asignadas a sus otras máquinas, entonces no necesita NAT,

• y por supuesto, si no le gusta la idea de una salida gratuita a Internet.

3.2 ¿Cómo funciona NAT?

Representación de la configuración más simple, suponiendo una red privada clase C:

+--------------+ | Cliente | Ethernet | A |---->: | 192.168.1.11 | : +--------------+ : : +----------+ +--------------+ : 192.168.1.1 | Servidor | enlace | Cliente | :------------>| NAT | --------> Internet | B |---->: Ethernet | | IP: 111.222.333.444 | 192.168.1.12 | : +----------+ +--------------+ : : +--------------+ : | Cliente | : | C |---->: | 192.168.1.13 | +--------------+

<--- Red Privada --->

En este ejemplo hay cuatro computadoras, un servidor NAT (IP 192.168.1.1) y tres clientes (IP’s: 192.168.1.11, 192.168.1.12 y 192.168.1.13).

El sistema NAT es la pasarela enmascarada para la red interna de los clientes A, B y C que permite el acceso a Internet. La red interna usa una de las direcciones de red privadas, en este caso la red de clase C 192.168.1.x, donde la interfaz ethernet del servidor NAT tiene la dirección 192.168.1.1 y los clientes tienen direcciones de esa misma red.

Los tres clientes A, B y C (que pueden estar usando cualquier sistema operativo que pueda "hablar IP") pueden conectarse a otras máquinas de Internet, ya que el servidor NAT enmascara todas sus conexiones de tal forma que parezcan originadas en el enlace, y se encarga de que los datos que le devuelven en una conexión enmascarada sean retransmitidos al sistema original. Así los sistemas de la red interna ven una ruta directa a Internet y son incapaces de darse cuenta que sus datos están siendo enmascarados

4. IPTABLES

4.1 ¿Qué es iptables?

iptables – IP packet filter administration (administración de filtro de paquete IP), es la herramienta que nos permite configurar, mantener e inspeccionar las tablas de reglas de filtrado de paquetes IP en el kernel de Linux, desde su

versión 2.4 (en 2.2 era ipchains). Con esta herramienta, podremos crearnos un firewall adaptado a nuestras necesidades.

Del manual de iptables:

Se pueden definir diferentes tablas. Cada tabla contiene un número de cadenas propias y también puede contener cadenas definidas por el usuario. Cada cadena es una lista de reglas las cuales pueden encajar con un conjunto de paquetes. Cada regla especifica qué hacer con un paquete que encaja. Esto es llamado un `objetivo', el cual puede ser un salto a una cadena definida por el usuario en la misma tabla.

Su funcionamiento es simple: a iptables se le proporcionan unas reglas, especificando cada una de ellas unas determinadas características que debe cumplir un paquete. Además, se especifica para esa regla una acción o target (objetivo). Las reglas tienen un orden, y cuando se recibe o se envía un paquete, las reglas se recorren en orden hasta que las condiciones que pide una de ellas se cumplen en el paquete, y la regla se activa realizando sobre el paquete la acción que le haya sido especificada.

Estas acciones se plasman en lo que se denominan targets (objetivos), que indican lo que se debe hacer con el paquete. Los más usados son bastante explícitos: ACCEPT, DROP y REJECT, pero también hay otros que nos permiten funcionalidades añadidas y algunas veces interesantes: LOG, MIRROR, QUEUE, RETURN, MARK, entre otros.

En cuanto a los paquetes, el total del sistema de filtrado de paquetes del kernel se divide en tres tablas, cada una con varias chains (cadenas) a las que puede pertenecer un paquete, de la siguiente manera.

• filter: Tabla por defecto, para los paquetes que se refieran a nuestra máquina

o INPUT: Paquetes recibidos para nuestro sistema o FORWARD: Paquetes enrutados a través de nuestro sistema o OUTPUT : Paquetes generados en nuestro sistema y que son

enviados

• nat: Tabla referida a los paquetes enrutados en un sistema con Masquerading

o PREROUTING: Para alterar los paquetes según entren o OUTPUT : Para alterar paquetes generados localmente antes de

enrutar o POSTROUTING: Para alterar los paquetes cuando están a punto

para salir

• mangle: Alteraciones más especiales de paquetes o PREROUTING: Para alterar los paquetes entrantes antes de

enrutar o OUTPUT : Para alterar los paquetes generados localmente antes

de enrutar

Dado que el soporte para el firewall está integrado en el kernel de Linux (Netfilter), para poder usar iptables tendremos que asegurarnos de que nuestro núcleo admite el uso de iptables y que añadimos a la configuración del núcleo todos aquellos targets que vayamos a necesitar (aunque siempre es bueno tener los más posibles).

4.2 Uso básico de iptables

El ejecutable de iptables generalmente reside en /sbin/iptables. A continuación se presentan los comandos básicos de iptables.

4.2.1 Crear una nueva regla al final de las ya existentes en una chain determinada

$ /sbin/iptables -A [chain] [especif_de_la_regla] [opciones]

4.2.2 Insertar una regla en una posición determinada de la lista de reglas de una chain determinada

$ /sbin/iptables -I [chain] [posición] [especif_de_la_regla] [opciones]

4.2.3 Borrar una regla en una posición determinada de la lista de reglas de una chain determinada

$ /sbin/iptables -D [chain] [posición]

4.2.4 Borrar todas las reglas de una chain determinada

$ /sbin/iptables -F [chain]

4.2.5 Listar las reglas de una chain determinada

$ /sbin/iptables -L [chain]

4.2.6 Explicación de parámetros

La especificación de la regla: "especif_de_la_regla" se hace con los siguientes parámetros:

• -p, --protocol [!] protocolo

Protocolo al que pertenece el paquete. El protocolo especificado puede ser tcp, udp, icmp o all, o puede ser un número, representando uno de esos protocolos u otro diferente. Un nombre de protocolo de /etc/protocolos también está permitido. Un "!" antes del protocolo invierte el resultado. El número cero es equivalente a todos.

• -s, --source [!] dirección[/máscara]

Dirección de origen del paquete. Puede ser un nombre de host, una dirección IP normal, o una dirección de red (con máscara, de forma dirección / máscara). La bandera --src es un alias conveniente para esta opción. Un "!" invierte el resultado.

• -d, --destination [!] dirección[/máscara]

Al igual que el anterior, puede ser un nombre de host, dirección de red o dirección IP singular. La bandera --dst es una alias conveniente para esta opción.

• -i, --in-interfaz [!] [nombre]

Especificación de la interfaz por la que se recibe el paquete. Si el nombre de la interfaz termina en un "+", entonces cualquier interfaz que comience con este nombre será tenida en cuenta. Si esta opción es omitida, la cadena "+" es asumida, por lo que se

tendrán en cuenta todas las interfaces.

• -o, --out-interfaz [!] [nombre]

Especificación de la interfaz por la que se va a enviar el paquete. Funciona exactamente igual que la anterior opción.

• [!] –f, --fragment

Especifica que la regla se refiere al segundo y siguientes fragmentos de un paquete fragmentado. Si se antepone !, se refiere sólo al primer paquete, o a los paquetes no fragmentados.

Y además, uno que nos permitirá elegir qué haremos con el paquete:

• -j, --jump [target]

Nos permite elegir el target al que se debe enviar ese paquete, esto es, la acción a llevar a cabo con él. Si esta opción es omitida en una regla, entonces la regla no tendrá efecto sobre el paquete, pero sí se incrementará el contador de la regla.

Algunas de las opciones que se permiten en los comandos de arriba son:

• -v, --verbose

Modo comunicativo, útil sobre todo con iptables -L. Muestra información detallada sobre el comando ejecutado.

• -n, --numeric

Las direcciones IP y números de puertos se mostrarán numéricamente (sin resolver nombres). Por defecto el programa intentará desplegarlos como nombres de host, nombres de red o de servicios.

• --line-numbers

Muestra los número de regla de cada chain, de manera que sea más fácil identificarlas para realizar operaciones de inserción, borrado, etc.

4.3 iptables como FIREWALL

Para utilizar iptables como firewall lo que único que se debe tener en cuenta, aparte de usar la estructura adecuada para crear las reglas, son las tablas INPUT y OUTPUT, las cuales se encargan de controlar, respectivamente, los paquetes que entran y salen de la máquina.

4.3.1 Creación de un firewall doméstico (ejemplo 1)

Para crear nuestro sencillo firewall doméstico, tendremos primero que preguntarnos qué es lo que deseamos que haga. Lo más usual que se requiere en un firewall , para un equipo que se usa para conexiones a Internet de manera normal (no es servidor de nada) es lo siguiente:

• Que nos permita realizar conexiones TCP hacia afuera de nuestra máquina (si no, no podríamos hacer casi nada).

• Que no permita realizar conexiones TCP desde afuera hacia nuestra máquina, para evitar que alguien intente conectarse a nuestros servidores web, ftp, telnet, X...

• Que permita el tráfico de paquetes TCP (paquetes que no establezcan conexiones) en ambas direcciones, pues necesitamos tráfico bidireccional de paquetes al usar casi cualquier cosa en Internet.

• Que prohíba el tráfico UDP desde afuera de nuestra máquina, a excepción del necesario para las respuestas por parte de nuestros servidores DNS, que provendrán de su puerto UDP 53.

• En caso de tener una intranet, que no aplique estas restricciones al tráfico proveniente de y enviado hacia la intranet, ya que en esta red interna probablemente sí nos interese poder acceder remotamente a nuestra máquina.

Iremos introduciendo una a una las reglas que necesitamos.

Primera regla: permitamos cualquier tráfico que provenga de nuestra interfaz loopback (lo), para ello insertamos en el chain INPUT (se encarga de los paquetes que lleguen a nuestra máquina) de la tabla filter la siguiente regla:

$ /sbin/iptables -A INPUT -i lo -j ACCEPT

Explicación: -A indica que dicha regla se adicionará a la lista de reglas ya definidas (en este ejemplo esta es la primera regla que de define). INPUT significa que la regla se aplica a los paquetes que se reciban. –i lo indica que la regla será aplicada a los paquetes que se reciban con destino a la interfaz loopback (local). –j ACCEPT significa que los paquetes que cumplan las condiciones anteriores serán aceptados.

NOTA: Atención: es importante aquí respetar las mayúsculas, pues los nombres del chain y del target son INPUT y ACCEPT, no input o accept.

Segunda regla: si disponemos de intranet, permitiremos todo el tráfico que provenga de nuestra interfaz de red interna. Por ejemplo, imaginando que tuviésemos una ethernet en la interfaz eth0, haríamos:

$ /sbin/iptables -A INPUT -i eth0 -j ACCEPT

Explicación: -i eth0 indica que la regla se aplicará a los paquetes que lleguen a nuestra máquina con destino a la interfaz del sistema cuyo alias es eth0. El ACCEPT, como vimos antes, permite dichos paquetes atraviesen el firewall.

NOTA: El hecho de que omitamos la dirección de origen, de destino implica que nos referimos a todas, tal como se explicó en 4.2.6 Explicación de parámetros.

Tercera regla: impediremos el paso de cualquier paquete TCP proveniente del exterior que intente establecer una conexión con nuestro equipo. Estos paquetes se reconocen por tener la bandera SYN acertada y las banderas ACK y FIN desacertados. Para decirle a la regla que reconozca específicamente estos paquetes, usaremos una opción que se puede usar cuando el protocolo del paquete es declarado como tcp, la opción --syn. De la siguiente manera:

$ /sbin/iptables -A INPUT -p tcp --syn -j REJECT --reject-with icmp-port-unreachable

Explicación: -p tcp indica que los paquetes del protocolo tcp que intenten iniciar conexión (--syn) con nuestra máquina (sin importar de dónde provengan), serán devueltos (REJECT) con un error dentro del mismo. En este caso los paquetes serán regresados con (--reject-with) el mensaje de error icmp-port-unreachable. Se puede elegir el tipo de mensaje de error de rechazo entre: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-port-unreachable, icmp-net-prohibited e icmp-host-prohibited.

Cuarta regla: Antes de declarar que deseamos prohibir cualquier tráfico UDP hacia nuestra máquina, y dado que las reglas se recorren en orden hasta que una de ellas se activa con el paquete, tendremos que añadir ahora una regla que nos permita recibir las respuestas de nuestro(s) servidor(es) DNS cuando nuestro sistema les realice alguna consulta. Estas respuestas, vía UDP, saldrán

del puerto 53 del servidor DNS. La regla, pues, será:

$ /sbin/iptables -A INPUT -p udp --source-port 53 -j ACCEPT

Explicación: -p udp indica que la regla se aplicará a los paquetes con protocolo udp que entren a nuestra máquina. --source-port es una opción presente cuando el protocolo es udp (también cuando es tcp) y nos permite en este caso especificar que la consulta provenga del puerto destinado al DNS. Dichos paquetes serán aceptados (ACCEPT ).

Quinta regla: Prohibimos ahora el resto del tráfico UDP. La regla de por sí implica a todo el tráfico UDP, pero como un paquete sólo activará esta regla si no ha activado la anterior, los paquetes UDP referentes a una transacción con un servidor de nombres no se verán afectados.

$ /sbin/iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

Explicación: --reject-with icmp-port-unreachable, como en la tercera regla, indica que los paquetes serán devueltos con el mensaje de error que se ha especificado.

NOTA: Dado que los targets por defecto (denominados policy o política) en la tabla filter son ACCEPT , si un paquete no activa ninguna de las reglas, será aceptado, de manera que no tendremos que preocuparnos de, por ejemplo, los paquetes de tráfico normal de TCP, ya que estos serán aceptados al no activar regla alguna.

Si ahora escribimos:

$ /sbin/iptables -L -v

Deberíamos obtener algo como:

Chain INPUT (policy ACCEPT 3444 packets, 1549K bytes) pkts bytes target prot opt in out source destination 11312 3413K ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT all -- eth0 any anywhere anywhere 0 0 REJECT tcp -- any any anywhere anywhere tcp flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable 0 0 ACCEPT udp -- any any anywhere anywhere udp spt:domain 0 0 REJECT udp -- any any anywhere anywhere reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 15046 packets, 4218K bytes) pkts bytes target prot opt in out source destination

De modo que nuestro pequeño y básico firewall doméstico ya está configurado. Nuestro equipo es ahora muchísimo más seguro, puesto que los ataques a nuestro sistema requerirían ahora mucha más elaboración, tiempo y esfuerzo por parte del atacante, de manera que nuestra condición de insignificantes ya empezará a ser importante como garante de seguridad.

4.3.2 Creación de un firewall avanzado (ejemplo 2)

Para este ejemplo vamos a anexar el script completo para configurar un firewall de un nivel superior al anterior. No se puede clasificar como un firewall completo, pues la creación de uno de estos requiere conocimientos mayores en cuanto a sitios de Internet y aplicaciones existentes, así como los puertos que estos usan.

En este ejemplo se usarán solo los targets ACCEPT y DROP. En el anterior se usó el target REJECT, que permite regresar un paquete con un mensaje de error específico. Se propone este método para estructurar un script de firewall.

Dentro del script se encuentran seis bloques distintos:

• Bloque 1. Variables: En ésta sección, se tiene que especificar la IP de la computadora donde se va a instalar el firewall, mascara de subred, etc.

DPRIV=192.168.1.1 Dirección IP del equipo en la red privada DPUBL=209.205.69.127 Dirección IP pública del equipo

REDLOCAL= 192.168.0.0/24 Toda la red local (privada)

MASCARA=255.255.255.0 Máscara de red

IPT=/sbin/iptables Ubicación del iptables en disco

• Bloque 2. Iniciación básica. Elimina completamente las restricciones del firewall sobre la interfaz localhost. De ésta manera las aplicaciones

como las X que necesitan ésta interfase para funcionar no tendrán ningún problema.

• Bloque 3. Ataques específicos: Son reglas que bloquean ataques específicos:

Spoofing: Usurpación de IP: Para evitar que un atacante nos presente una IP incorrecta, introducimos en el firewall las IP's falsas que se suelen usar en estos ataques para evitar problemas.

icmp: En principio aceptamos todos los paquetes icmp, pero documentando las líneas correspondientes en el script, se puede activar solo los paquetes icmp necesarios para la comunicación. También, comentando las líneas de ping, se puede evitar que le hagan ping's.

smurf: Es un ataque DoS que envía ping's a las direcciones de broadcast de la red, de forma que se van propagando por todos las computadora.

• Bloque 4. Servicios disponibles: son servicios disponibles en nuestro servidor, por ejemplo web, ftp, etc. Aunque aquí las reglas tengan la misma forma, no tiene que ser así para todos los protocolos; según el caso puede ser necesario añadir más reglas o cambiarlas. Si quiere añadir sus propias reglas, averigue que protocolo usa el servicio que quiere instalar para saber como generar una regla válida. Fíjese que hay servicios disponibles únicamente para la red local y otros disponibles para toda la red.

NOTA: Fíjese que en el caso del modo ftp pasivo (el que se suele usar por defecto en los navegadores, etc.) se tienen que abrir todos los puertos por encima del 1024, esto no es muy seguro así que está comentado.

• Bloque 5. Conexiones cliente: Con éstas reglas permitimos al servidor conectarse solo a determinados servicios específicos. Si es un servidor normalmente no lo usaremos para navegar en la red. De todas formas están las reglas básicas que permiten recoger correo, conectarse a la web, traerse ficheros ftp y algunas más.

• Bloque 6. Reglas por defecto: Bloquea todo lo que no se haya especificado de antemano.

4.3.1.1 Script para la creación de un firewall avanzado

#!/bin/bash

### Israel E. Bethencourt/CORE <[email protected]>

### Modificado por Andrés Sáyago <[email protected]>

#########################################################################

### Bloque 1. Variables

DPRIV=192.168.1.1

DPUBL=209.205.69.127

REDLOCAL=192.168.0.0/24

MASCARA=255.255.255.0

IPT=/sbin/iptables

#########################################################################

### Bloque 2. Inicialización básica

# Limpia la lista de reglas

$IPT -F

# Tráfico sin restricciones sobre la interfaz loopback (lo)

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

##########################################################################

### Bloque 3. Ataques específicos

##########

# Spoofing

# Rechaza paquetes que afirmen ser o venir de una red privada Clase A

$IPT -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP

$IPT -A INPUT -i eth0 -d 10.0.0.0/8 -j DROP

$IPT -A OUTPUT -o eth0 -s 10.0.0.0/8 -j DROP

$IPT -A OUTPUT -o eth0 -d 10.0.0.0/8 -j DROP

# Rechaza paquetes que afirmen ser o venir de una red privada Clase B

$IPT -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP

$IPT -A INPUT -i eth0 -d 172.16.0.0/12 -j DROP

$IPT -A OUTPUT -o eth0 -s 172.16.0.0/12 -j DROP

$IPT -A OUTPUT -o eth0 -d 172.16.0.0/12 -j DROP

# Rechaza paquetes que afirmen ser o venir de una red multicast Clase D

# $IPT -A INPUT -i eth0 -s 224.0.0.0/4 -j DROP

# $IPT -A OUTPUT -o eth0 -s 224.0.0.0/4 -j DROP

# Rechaza paquetes que afirmen ser o venir de una red reservada Clase E

# $IPT -A INPUT -i eth0 -s 240.0.0.0/5 -j DROP

# Rechaza paquetes que afirmen ser o venir de loopback

$IPT -A INPUT -i eth0 -s localhost -j DROP

$IPT -A OUTPUT -o eth0 -s localhost -j DROP

# Rechaza paqetes broadcast mal formados

$IPT -A INPUT -i eth0 -s 255.255.255.255 -j DROP

$IPT -A INPUT -i eth0 -d 0.0.0.0 -j DROP

######

# icmp

# Acepta todos los paquetes icmp

$IPT -A INPUT -p icmp -j ACCEPT

$IPT -A OUTPUT -p icmp -j ACCEPT

# Solo confiar en paquetes icmp

# Mensaje icmp de control de origen apagado

# $IPT -A INPUT -p icmp --icmp-type 4 -j ACCEPT

# $IPT -A OUTPUT -p icmp --icmp-type 4 -j ACCEPT

# Mensaje de estado icmp por problemas de parámetro



# Mensaje icmp de error de destino inalcanzable



# Mensaje de estado icmp de tiempo excedido



# Permitir ping's salientes a cualquier parte

# $IPT -A INPUT -d $DPRIV -p icmp --icmp-type 8 -j ACCEPT

# $IPT -A OUTPUT -s $DPRIV -p icmp --icmp-type 8 -j ACCEPT

# Permitir ping's entrantes de cualquier parte

# $IPT -A INPUT -d $DPRIV -p icmp --icmp-type 8 -j ACCEPT

# $IPT -A OUTPUT -s $DPRIV -p icmp --icmp-type 8 -j ACCEPT

#######

# smurf

# Ataque de tipo DoS (denegación de servicios)

# $IPT -A INPUT -d 255.255.255.255 -p icmp -j DROP

# $IPT -A OUTPUT -d 255.255.255.255 -p icmp -j DROP

# Ataque DoS de direcciones de red

# $IPT -A INPUT -d $MASCARA -p icmp -j DROP

# $IPT -A OUTPUT -d $MASCARA -p icmp -j DROP

##########################################################################

### Bloque 4. Servicios disponibles

# Recibiendo correo como un servidor SMTP

$IPT -A INPUT -d $DPRIV -p tcp --dport 25 --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --sport 25 --dport 1024:65535 -j ACCEPT

# Solicitud entrante de pop3



# Solicitud entrante de telnet



# Solicitud entrante de FTP



# Los datos encauzan respuestas FTP en modo puerto normal

$IPT -A OUTPUT -s $DPRIV -p tcp --dport 1024:65525 --sport 20 -j ACCEPT

$IPT -A INPUT -d $DPRIV -p tcp ! --syn --dport 20 --sport 1024:65535 -j ACCEPT

# Canal de datos FTP modo pasivo

#$IPT -A INPUT -d $DPRIV -p tcp --sport 1024:65535 --dport 1024:65535 -j ACCEPT

#$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --sport 1024:65535 --dport 1024:65535 -j ACCEPT

# Solicitudes http de entrada



# Solicitudes auth de entrada

$IPT -A INPUT -d $DPRIV -p tcp --dport auth --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --sport auth --dport 1024:65535 -j ACCEPT

# Solicitudes shttp (ssl) de entrada

# $IPT -A INPUT -d $DPRIV -p tcp --dport 443 --sport 1024:65535 -j ACCEPT

# $IPT -A OUTPUT -s $DPRIV -p ! --syn --sport 443 --dport 1024:65535 -j ACCEPT

# Solicitudes binkp de entrada

$IPT -A INPUT -d $DPRIV -p tcp --dport binkp --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --sport binkp --dport 1024:65535 -j ACCEPT

# Solicitudes tfido de entrada

$IPT -A INPUT -d $DPRIV -p tcp --dport tfido --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --sport tfido --dport 1024:65535 -j ACCEPT

# Solicitudes fido de entrada

$IPT -A INPUT -d $DPRIV -p tcp --dport fido --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --sport fido --dport 1024:65535 -j ACCEPT

# Solicitudes interbase de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport gds_db --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport gds_db --dport 1024:65535 -j ACCEPT

$IPT -A INPUT -s $REDLOCAL -d $DPRIV -p tcp --sport 1024:65535 --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport 1024:65535 --dport 1024:65535 -j ACCEPT

# Solicitudes mysql de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport mysql --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport mysql --dport 1024:65535 -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --dport mysql --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport mysql --dport 1024:65535 -j ACCEPT

# Solicitudes mysql de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport netbios-ns:netbios-ssn --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport netbios-ns:netbios-ssn --dport 1024:65535 -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --dport netbios-ns:netbios-ssn --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport netbios-ns:netbios-ssn --dport 1024:65535 -j ACCEPT

# Solicitudes portmap de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport sunrpc --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport sunrpc --dport 1024:65535 -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --dport sunrpc --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport sunrpc --dport 1024:65535 -j ACCEPT

# Solicitudes nfs de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport nfs --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport nfs --dport 1024:65535 -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --dport nfs --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport nfs --dport 1024:65535 -j ACCEPT

# Solicitudes rexec de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport exec --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport exec --dport 1024:65535 -j ACCEPT

# Solicitudes X11 de entrada

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp --dport x11 --sport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp ! --syn --sport x11 --dport 1024:65535 -j ACCEPT

##########################################################################

### Bloque 5. Conexiones cliente

# Permitiendo DNS Lookups como un cliente

$IPT -A OUTPUT -s $DPRIV -p udp --dport 53 --sport 1024:65525 -j ACCEPT

$IPT -A INPUT -d $DPRIV -p udp --sport 53 --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --dport 53 --sport 1024:65535 -j ACCEPT

$IPT -A INPUT -d $DPRIV -p tcp --sport 53 --dport 1024:65525 -j ACCEPT

# Enviando correo a cualquier servidor de correo externo

$IPT -A OUTPUT -s $DPRIV -p tcp --sport 1024:65535 --dport 25 -j ACCEPT

$IPT -A INPUT -d $DPRIV -p tcp ! --syn --sport 25 --dport 1024:65535 -j ACCEPT

# Recuperando correo POP como cliente



# Acceso http estándar



# Acceso shttp estándar



# Acceso telnet estándar



# Acceso auth estándar

$IPT -A OUTPUT -s $DPRIV -p tcp --sport 1024:65535 --dport auth -j ACCEPT

$IPT -A INPUT -d $DPRIV -p tcp ! --syn --sport auth --dport 1024:65535 -j ACCEPT

# Acceso ftp estándar



# Canal de datos FTP modo pasivo

# $IPT -A OUTPUT -s $DPRIV -p tcp --sport 1024:65535 --dport 1024:65535 -j ACCEPT

# $IPT -A INPUT -d $DPRIV -p tcp ! --syn --sport 1024:65535 --dport 1024:65535 -j ACCEPT

# Respuestas del canal de datos FTP modo puerto normal

$IPT -A INPUT -d $DPRIV -p tcp --sport 20 --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -p tcp ! --syn --dport 20 --sport 1024:65525 -j ACCEPT

# Acceso whois estándar



# Acceso binkp estándar

$IPT -A OUTPUT -s $DPRIV -p tcp --sport 1024:65535 --dport binkp -j ACCEPT

$IPT -A INPUT -d $DPRIV -p tcp ! --syn --sport binkp --dport 1024:65535 -j ACCEPT

# Acceso interbase estándar

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp --sport 1024:65535 --dport gds_db -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp ! --syn --sport gds_db --dport 1024:65535 -j ACCEPT

# Acceso mysql estándar

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp --sport 1024:65535 --dport mysql -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp ! --syn --sport mysql --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport 1024:65535 --dport mysql -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --sport mysql --dport 1024:65535 -j ACCEPT

# Acceso Netbios estándar

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp --sport 1024:65535 --dport netbios-ns:netbios-ssn -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp ! --syn --sport netbios-ns:netbios-ssn --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport 1024:65535 --dport netbios-ns:netbios-ssn -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --sport netbios-ns:netbios-ssn --dport 1024:65535 -j ACCEPT

# Acceso portmap estándar

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp --sport 1024:65535 --dport sunrpc -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp ! --syn --sport sunrpc --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport 1024:65535 --dport sunrpc -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --sport sunrpc --dport 1024:65535 -j ACCEPT

# Acceso nfs estándar

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp --sport 1024:65535 --dport nfs -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp ! --syn --sport nfs --dport 1024:65535 -j ACCEPT

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p udp --sport 1024:65535 --dport nfs -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p udp --sport nfs --dport 1024:65535 -j ACCEPT

# Acceso X11 estándar

$IPT -A OUTPUT -s $DPRIV -d $REDLOCAL -p tcp --sport 1024:65535 --dport x11 -j ACCEPT

$IPT -A INPUT -d $DPRIV -s $REDLOCAL -p tcp ! --syn --sport x11 --dport 1024:65535 -j ACCEPT

##########################################################################

### Bloque 6. Reglas por defecto

# Bloquea cualquier otro tipo de conexión que se intente hacer fuera de las que están aquí

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

4.4 iptables como NAT

Básicamente, iptables traduce direcciones IP internas en direcciones IP externas. Este proceso se llama Traducción de Direcciones de Red (NAT) y Linux hace esto mediante los llamados números de puerto. Desde el exterior, todas las conexiones parecen haberse originado desde su máquina Linux.

Bloquear servicios indeseables en una LAN es vital, especialmente cuando, como en la mayoría de los casos, el abuso en el consumo del valioso ancho de banda consecuente en el detrimento de los servicios que son verdaderamente importantes.

Al llegar a este punto ya tenemos la habilidad de manejar el iptables en cuanto a firewall se refiere. Pues bien, le sorprenderá saber que lo que falta por aprender para manejar el iptables como NAT es supremamente..... poco.

Para utilizar iptables como NAT lo que único que se debe tener en cuenta, aparte de usar la estructura adecuada para crear las reglas, es la tabla FORWARD, la cuales se encarga de controlar el reenvío (enmascaramiento) de los paquetes que entran y salen de la máquina.

4.4.1 Creación de un NAT básico (ejemplo único)

Servicios como los utilizados para compartir archivos, principalmente música, además de fomentar la piratería, y comprometer indirectamente a la empresa en dicha actividad, son los que representan el mayor consumo de ancho de banda.

Otros servicios, como los utilizados para mensajería instantánea, contribuyen, aunque en menor grado, a este detrimento. Representan también un riesgo de seguridad para los mismos usuarios debido a la proliferación de gusanos, troyanos y virus, hecho que puede llegar a comprometer datos e información confidencial y estratégica de la empresa.

Las siguientes constituyen las reglas necesarias, para añadir en el guión del muro contrafuegos, a fin de bloquear los servicios indeseables:

# Compartir de archivos

# Red de Audio Galaxy

/sbin/iptables -A FORWARD -d 64.245.58.0/23 -j REJECT

# GNUtella, Bearshare y ToadNode

/sbin/iptables -A FORWARD -p TCP --dport 6346 -j REJECT

# Puertos y redes de Kazaa y Morpheus

/sbin/iptables -A FORWARD --dport 1214 -j REJECT



# Red de Napigator


# Red de Napster


# Redes de WinMX


/sbin/iptables -A FORWARD -d 64.49.201.0/24 -j REJ ECT

# Red de IMesh


# Mensajería instantánea

# AIM e ICQ

/sbin/iptables -A FORWARD --dport 9898 -j REJECT

/sbin/iptables -A FORWARD --dport 5190:5193 -j REJECT

/sbin/iptables -A FORWARD -d login.oscar.aol.com -j REJECT

/sbin/iptables -A FORWARD -d login.icq.com -j REJECT

# Jabber

/sbin/iptables -A FORWARD --dport 5222:5223 -j REJECT

# MSN Messenger

/sbin/iptables -A FORWARD -p TCP --dport 1863 -j REJECT


# Yahoo! Messenger

/sbin/iptables -A FORWARD -p TCP --dport 5000:5010 -j REJECT

/sbin/iptables -A FORWARD -d cs.yahoo.com -j REJECT

/sbin/iptables -A FORWARD -b scsa.yahoo.com -j REJECT

# Otros

# eDonkey

/sbin/iptables -A FORWARD -p tcp --dport 4661:4662 -j REJECT

/sbin/iptables -A FORWARD -p udp --dport 4665 -j REJECT

4.5 Herramientas de iptables

Si una vez realzadas las configuraciones de iptables apagáramos nuestro equipo, éstas se perderían y tendríamos que volver a realizar una a una las sentencias de configuración, o podríamos llamar al script, en caso de que hayamos creado uno.

Aquí se explican dos herramientas útiles que acompañan al programa iptables, las cuales nos permiten sacar por salida estándar el contenido de nuestras tablas IP, y el segundo nos permite, a partir de la salida generada por el primero, recuperar la configuración de las tablas.

4.5.1 iptables-save

Para guardar la configuración de las tablas en un archivo, lo hacemos de la siguiente forma:

$ /sbin/iptables-save -c > miarchivo

Donde –c es una opción que nos permite guardar los contadores del número de paquetes que activaron cada regla.

4.5.2 iptables-restore

Para recuperar la configuración de las tablas de un archivo, lo hacemos de la siguiente forma:

$ /sbin/iptables-restore -c < miarchivo

En cuyo caso –c tiene el mismo significado que con iptables-save

NOTA: Estas llamadas a iptables-save e iptables-restore podrán ser incluidas en los script's adecuados para que se lleven a cabo de manera automática en el arranque y el cierre del sistema.

En caso de ser usuarios de Red Hat Linux, a partir de su versión 7.1, una vez configurado el firewall con iptables tal y como se ha descrito en este artículo, y una vez salvada la configuración con iptables-save en el archivo /etc/sysconfig/iptables, se pueden activar los script’s que arrancarán y cerrarán el firewall automáticamente al arrancar y apagar el equipo, mediante la Text Mode Setup Utility (/usr/sbin/setup), en la sección System Services.

5. Anexos

5.1 FireStarter (GUI para configurar iptables)

Para los que no quieran interactuar con el shell y en la línea de difundir el uso de GNU/Linux en los negocios o entre nuevos usuarios que vienen de Microsoft, hay interfaces gráficas simplificadas al máximo que te permiten correr un NAT firewall inmediatamente después de la primera instalación de nuestro sistema.

Es decir, si no tienes mucho conocimientos sobre Linux y no tiene suficiente tiempo para dedicarte a él, y lo único que necesitas es:

• Montar una puerta de enlace (una salida compartida a Internet por una red de PC’s) para salir a Internet con una única conexión

• Le gusta la idea de que solo esté a la vista desde Internet, el PC dedicado a la salida

• Le vendría bien permitir algunos servicios (como web, ftp, telnet, ssh, X, etc.)

• Registrar accesos • Y sobretodo no está tratando con información codiciable, es decir, no

espera ser atacado

Entonces una GUI como FireStarter <http://firestarter.sourceforge.net/> o cualquier otra que encuentre en sourceforge <http://sourceforge.net/> le pueden ayudar a solucionar su problema de tiempo.

Se debe recalcar que

• Con esto no puede conseguir tanta seguridad como si elabora una completa tabla de reglas a su medida con iptables, pero nuestra opinión es que un novato podría dejar el sistema al descubierto muy fácilmente con iptables.

5.2 Hogwash (mezcla de Firewall y NIDS)

Hogwash, es una especie de híbrido entre un firewall y un NIDS (Network Intrusion Detection System), de forma que correctamente configurado nos permitirá protegernos de ataques externos que podrían pasar inadvertidos para un firewall.

Los firewall clásicos lo que hacen es modificar sus reglas, para denegar cualquier petición que se suponga ilegal, esto que en un principio es lo correcto y lo que queremos, también implica que el atacante pueda realizar un ataque DoS (Denegación de Servicio) muy fácilmente.

Imagine que el atacante al detectar nuestra defensa, empieza a mandarnos peticiones falsas de accesos desde Freshmeat o nuestro propio servidor DNS. ¿Qué pasaría entonces? Que nos estaríamos denegando nosotros mismo el acceso a estos sitios, y si no podemos acceder a nuestro servidor DNS, perdemos el acceso a prácticamente todo.

La solución es utilizar hogwash, que en lugar de cerrar puertos y denegar acceso, lo que hace es rechazar y modificar determinados paquetes en función de la identificación de signaturas / patrones, para lo cual se apoya en el potente Snort y su amplia y completa colección de reglas.

Hogwash está diseñado para evitar el 95% de las acciones de ataque que todos los kiddies lanzan a su red. Hogwash vive en línea como un cortafuego, pero funciona de forma diferente. En lugar de cerrar puertos como un cortafuego tradicional, deja caer o modifica paquetes específicos basados en un fósforo de la firma. Hogwash vive directamente encima del controlador de la red, así que no requiere una pila de IP para trabajar. Detiene ataques que no pueden ser bloqueados por un cortafuego tradicional y puede usarse para proteger sistemas a los que no se les puede aplicar parches por una razón u otra. El motor está basado en Snort.

6. Bibliografía y créditos

Firewall y Seguridad en Internet

www.monografías.com

Autor: Daniel Ramón Elorreaga Madrigal

Ing. Electrónico

Universidad Nacional Autónoma de México

e-mail: [email protected]

Configuración de un firewall en Linux con iptables

http://www.elrincondelprogramador.com/autores.asp?id=10

Daniel Fernández Garito

Configurar firewall

http://www.informaticos.biz/

Israel E. Bethencourt/CORE

[email protected]

iptables – IP Packet filter administration

Rusty Rusell

Iptables: Bloqueando servicios indeseables

Darkshram

http://www.linuxparatodos.com/linux/productos_servicios.php

Hogwash: mezcla de Firewall y NIDS

Carlos Cortes (aka carcoco)

http://carcoco.eresmas.com/

Linux Recursos Para el Usuario

James Mohr

Editorial Prentice Hall

1999

Manual Iptables (Firewalls, access rules on LInux)

Documents

Transcript of Manual Iptables (Firewalls, access rules on LInux)