Evasión de cortafuegos - CPH hacking and security

Hola, comunidad.

He publicado un manual sobre evasión de cortafuegos que está en mi página web. Está incompleto aún, por mi parte; y espero que vosotros contribuyáis también.

Lo pongo también aquí.

Para ver este enlace Registrate o Inicia Sesion

Bien, hay algo que a todos nos han metido a fuego en la cabeza: cualquier administrados de seguridad debe tener un cortafuegos. La cuestión es la siguiente: ¿cómo debemos configurar ese cortafuegos?.

En este manual vamos a tratar de explicar algunsa técnicas que los atacantes pueden poner en práctica para evitar el cortafuegos. Las técnicas basadas en troyanos y similares las dejaré aparte por dos razones: las desdeño, pues no enseñan absolutamente nada; y la solución pasa por tener un antivirus actualizado.

Vamos a centrarnos en técnicas que empleen los que ya saben algo de ese mundillo, para poder mostrar a los administradore s cómo protegerse.

Lo esencial es conocer que herramientas tiene un atacante. En este caso, nos centramos en Nmap. Nmap es una potente herramienta implementada en consola de comandos, lo que seguramente les parecerá mal a algunos, mal acostumbrados a programas poco potentes y muy bonitos gráficamente. Está disponible para Linux, Windows y Mac.

Antes de nada, daremos un pequeño manual para configurar un cortafuegos.

Lo saqué de una web, pero no recuerdo ahora cual. Pido al autor/es disculpas por no poner escribir su/s nombre/s.

INTRODUCCIÓN A LOS CORTAFUEGOS (FIREWALLS)

¿Qué es un firewall?

Un firewall en términos de sistemas computacionale s es un sistema informático, simple o compuesto que actúa como punto de conexión segura entre otros dos o más ordenadores o redes.

Figura 1 Sistema complejo con diversos Cortafuegos

Profundizando un poquito más, un cortafuegos se sitúa entre dos o más redes con la intención de cumplir unas determinadas directivas de seguridad en la comunicación entre ellas. Por ello, un cortafuegos, puede ser desde un simple router, a un PC o una subred de servidores.

Como vemos el término cortafuegos, puede concretarse de manera muy distinta según los mecanismos utilizados para su construcción, la familia de protocolos que reconoce (desde el estándar universal TCP/IP, hasta aproximaciones de corte comercial como NETBEUI de Microsoft, o IPX/SPX de Novell Netware), el nivel de la pila sobre el que actúa para un mismo protocolo (ver figura), y la arquitectura de red que posee.

7.2. CORTAFUEGOS DE FILTRADO DE PAQUETES, IPFW

Este módulo de introducción, no pretende ser un estudio sobre la infinidad de familias y variedades de firewalls, seremos más concret@s, y nos centraremos en el estudio de un modelo de cortafuegos, la familia de los firewalls de filtrado de paquetes sobre la pila de protocolos TCP/IP, los llamados IPFW.

Los IPFW funcionan como indican las dos primeras letras de IPFW, sobre paquetes IP, es decir, en el nivel de transporte y red de TCP/IP.

Figura 2 Niveles ISO/OSI vs TCP/IP

Los cortafuegos de filtrado de paquetes IP, suelen implementarse dentro del sistema operativo y funcionan en las capas de transporte y red, trabajando sobre la información de las cabeceras de los paquetes IP, es decir, que no analizarán el área de datos3, sino que únicamente utilizan la información que puede obtenerse de una cabecera IP. Como ya habíamos dicho, habitualmente, un cortafuego se sitúa entre dos o más redes, lo que implica que tiene al menos dos interfaces de red.

A pesar de que un cortafuegos separa dos redes cualquiera entre si, lo habitual, es que separe redes propietarias distintas. Es decir, aunque pueden utilizarse cortafuegos dentro de una misma red, filtrando las comunicaciones entres las distintas subredes internas, lo habitual, es que forme parte de una red propia y sea él quien vigile las comunicaciones con otra red o redes ajenas en las que no se confía, por ejemplo, y sobre, todo Internet.

Un cortafuegos de filtrado de paquetes, no puede evitar que un/una usuari@ mande desde su equipo un mensaje de correo con las cuentas de la empresa a la competencia, lo más que podría evitar sería que esa estación acceda al servidor de correo, con lo que no podría enviar correo a nadie.

De hecho, un único ordenador con un MODEM y un firewall configurado, ya representa dicha separación, aunque la red interna la forma sólo él y por ello no dispondrá de dos interfaces de red, sino de una.

Los firewalls, son principalmente, una herramienta de seguridad y prevención ante ataques externos. Es decir, un IPFW funciona filtrando las comunicaciones en ambos sentidos entre su interfaz interna (la que lo conecta a su red) y la externa. El mecanismo de funcionamiento para realizar este filtrado es a través de una lista de reglas.

Las reglas, pueden ser de dos tipos; de aceptación y de rechazo, aunque en realidad, éste última se descompone en dos “subtipos”, es decir, en términos de aceptación, rechazo y denegación. En iptables, un IPFW se corresponde con los argumentos ACCEPT, REJECT y DROP, respectivament e.

La lista de reglas de entrada (del exterior hacia la red) es totalmente independiente de la lista de reglas de filtrado de salida (de la red hacia el exterior). Las distintas listas de reglas se llaman cadenas (chains).

Figura 3 Flujo de un paquete en un FW

Hemos hablado de aceptación, rechazo y denegación. Las dos últimas son bastante similares, la diferencia radica en lo siguiente, cuando un IPFW rechaza una petición externa, envía una respuesta negativa diciendo que no acepta la comunicación, por el contrario, si descarta una petición, no envía ningún tipo de respuesta, es decir, que el agente externo que intentó establecer contacto, no sabrá siquiera si la máquina existe o está apagada.

Una vez definido un IPFW, podemos comenzar a estudiar las técnicas y políticas de creación de las cadenas. Hemos comentado que las cadenas eran listas de reglas por las que pasaban los paquetes IP, pero ¿debemos definir las reglas para todos los posibles paquetes IP? Obviamente, eso es inabordable, no podemos definir una regla de aceptación o rechazo para cada característica de cada paquete proveniente de cada una de las IP. La solución, pasa por hacer uso de “comodines” o “máscaras” y conseguir reglas generales. Esta manera de actuar, implica la primera decisión: La regla por defecto. Podemos establecer dos criterios:

1. Aceptar TODO por defecto y especificar aquello que no deseemos.
2. Rechazar TODO por defecto y especificar aquello que deseemos.

Hoy por hoy, si se quiere llevar una política de seguridad seria, la primera propuesta es inviable, de hecho, muchos sistemas de IPFW no la permiten, y sólo trabajan con la segunda. Así que, esa será la política que elijamos nosotr@s.

Para poder asegurar nuestra red mediante cortafuegos, deberemos estudiar previamente las reglas de entrada y de salida para las interfaz(es) interna( Roll Eyes

y externa( Roll Eyes

. Sin embargo, la parte más importante y donde se realiza el mayor esfuerzo en la elaboración de las reglas, es en la cadena de entrada de la interfaz externa.

7.3. FILTRADO DE PAQUETES ENTRANTES EN UN IPFW.

Un IPFW basa su filtrado en unas reglas que atienden a distintas condiciones sobre la información que aparece en una cabecera IP, en realidad, además de la cabecera IP, también se utiliza información de las cabeceras de los protocolos inmediatamente superiores, es decir TCP y UDP.

Esto implica que podemos filtrar basándonos en la dirección de origen, la dirección destino, el puerto origen, el puerto destino, el BIT de estado de TCP, etc…

Intentaremos esbozar en líneas generales las reglas que interesa que se cumplan para no crear agujeros de seguridad en el IPFW.

FILTRADO DE DIRECCIÓN REMOTA: La dirección remota es lo único que identifica al remitente del paquete. Deberemos impedir la entrada de paquetes cuya dirección remota pertenezca a redes o hosts “problemáticos”. Mediante este filtrado, disminuimos la posibilidad de ataques de ip spoofing. En este tipo de agresiones, el/la atacante suplanta su dirección IP por otra. Para dificultar las posibilidades de que esto ocurra, en la interfaz externa denegaremos siempre:

o La dirección IP propia de la interfaz de red externa.
o Direcciones IP privadas, de clase A (10.0.0.0 hasta 10.255.255.255),
de clase B (172.16.0.0 hasta 172.31.255.255) y de clase C (192.168.0.0 hasta 192.168.255.25 5).
o Direcciones IP de multidifusión de clase D (224.0.0.0 239.255.255.25 5).
o Direcciones reservadas de clase E (240.0.0.0 hasta 247.255.255.25 5).
o Direcciones de loopback (127.0.0.0 hasta 127.255.255.25 5).

FILTRADO DE DIRECCIÓN DESTINO LOCAL: Por defecto la interfaz de red ignora los paquetes de red que no se dirigen a ella, a excepción de las difusiones. Si no se va a hacer uso de ellas, conviene denegarlas.

FILTRADO DE PUERTO DE ORIGEN REMOTO Y DESTINO LOCAL: Se configurarán en función de los servicios de la red, tanto los locales que se exporten al exterior (por ejemplo un servidor web) como los externos que utilice (por ejemplo, un cliente de correo conectándose a un servidor POP3 ajeno a nuestra red).

FILTRADO DEL ESTADO DE LA CONEXIÓN TCP: Para los paquetes entrantes procedentes de servidores remotos, se exigirá que el BIT de AWK está activo (normalmente, siempre ocurre así puesto que responden a peticiones de un cliente local). Respecto a los paquetes IP entrantes desde clientes remotos hacia servicios locales que se exportan, dependerá de las necesidades de dichos servicios. Un ejemplo; generalmente se desea que un servidor WEB puede ser accesible por todo el mundo. Sin embargo, puede que deseemos que otros servicios como el de FTP o el servicio seguro SSH estén sólo disponibles para hosts concretos.

SONDEOS Y EXPLORACIÓN DE PUERTOS: Son relativamente habituales en nuestros días. No conviene ser extremista, es decir, no ser excesivamente paranoico ni pasar absolutamente del tema.

En realidad la mayoría de ataques y/o escaneos no los realizan hackers o crackers, suelen llevarlos a cabo los que en esta terminología se denominan lamers, es decir, gente con pocos o nulos conocimientos, que utiliza herramientas de otro para intentar acceder o averiguar datos de un sistema. Si el firewall lo permite, la mejor opción es auditarlos (registrar cuando y desde donde ocurren en un fichero histórico) para poder estudiar sus características (frecuencia, origen, puertos afectados, etc...). Con todos esos datos en la mano es más sencillo determinar si se trata de alguien inexpert@, o si realmente se avecina un ataque serio.

.ATAQUE DOS (denial of service): Este tipo de ataques tal y como su nombre indica, intenta inutilizar uno o varios servicios de los ofrecidos por nuestra red. Para conseguirlo, puede explotar bugs que afecten a la red o las máquinas (por ejemplo, el conocido WinNuke, aprovechaba un fallo del protocolo NETBEUI y los servicios SMB de recursos compartidos, de Microsoft y forzaba un reinicio en máquinas con el SO Windows 95), o intentar saturar un servicio por sobrecarga, bien sea aprovechando un mayor ancho de banda o capacidad de proceso por parte del/de la atacante, o bien porque vari@s atacantes se ponen de acuerdo y aúnan sus recursos.

Por ejemplo, se puede saturar un servidor SMTP cuando varios de sus usuari@s hacen spam de correo con mensajes tamaño considerable. No es posible defenderse totalmente de ellos. La mejor manera de evitarlos es estar informado sobre los últimos agujeros de seguridad.

Ejemplo de estos ataques son la inundación SYN TCP, inundación ping, bombas de redirección ICMP, etc… Si quieres obtener más información sobre el tema puedes consultar bibliografía especializada, aunque la mejor manera de estar al día sobre los últimos exploits o bugs de seguridad que se descubren y sus soluciones, es suscribirse a alguna lista de seguridad.

Este módulo, tiene como principal objetivo el diseño de un cortafuegos, describir la familia de IPFW y estudiar la configuración en un caso concreto (IPTables).

El cortafuegos, debe evitar accesos externos a servicios que se ofrecen al ámbito local o interno, y/o asegurar el correcto funcionamiento e integridad de servicios que se ofrecen al exterior protegiéndolos debidamente. Independientem ente de la configuración del cortafuegos, es muy importante vigilar que los servicios son seguros (por ejemplo, manteniendo siempre parcheados lo posibles bugs que surjan), que están correctamente configurados, y que se utilizan. ¿Para qué tener en marcha un servicio que no se utiliza y que puede poner en riesgo la seguridad de toda la red?

7.4. INTRODUCCIÓN A IPTABLES.

El objetivo de este módulo, es centrarse en el estudio de una herramienta específica de todas cuantas existen. Concretamente, el sistema que estudiaremos, será la herramienta de cortafuegos iptables sobre la distribución de Linux RedHat 9.

La versión 9, es la última de la distribución Red Hat, su kernel tiene una variante de la versión 2.4., que soporta IPTables. En lo que a la configuración de IPTables respecta, las diferencias son prácticamente inexistentes entre los distintas distribuciones, lo único necesario es que la elegida cuente con una versión de Kernel superior a la 2.4.

Iptables es como se conoce al módulo Netfilter, la herramienta estándar actual de cortafuegos bajo Linux.

NOVEDADES DE IPTABLES. (NAT)

Además de realizar un mejor aprovechamient o de los recursos del sistema, la principal novedad del módulo netfilter-iptables, es la integración de las herramientas de filtrado (el cortafuegos propiamente dicho), de NAT y de manipulación (MANGLING).

Aunque lo trataremos con más profundidad luego, es necesario detenernos un momento para conocer lo que es NAT, el acrónimo de Network Address Translation.

NAT básicamente altera las cabeceras de los paquetes IP, (principalmente las direcciones) y mantiene un “registro de entrada y salida” de los paquetes modificados, para poder alterar los paquetes respuesta de igual forma. Las aplicaciones de NAT son muchas y variadas, aunque actualmente, la aplicación más conocida es lo que se conoce como enmascaramient o o masquerading. El enmascaramient o, se utiliza principalmente para dos cosas:

LA CONEXIÓN DE VARIOS EQUIPOS A TRAVÉS DE UNA SOLA DIRECCIÓN IP. Como ejemplos, las pequeñas LAN domésticas, un CyberCafé, y en general cualquier red con más equipos que IP´s.

NAT no es un proxy, los proxies trabajan en un nivel superior de la pila de protocolos, bien en el nivel de TCP/UDP o incluso en el nivel de aplicación, lo que implica que los clientes deben configurarse para hacer uso del servicio. Por el contrario, NAT, al igual que el filtrado, trabaja en un nivel más bajo, a nivel IP, por lo que es “transparente”.

¿Por qué se confunden muchas veces NAT y proxy? La respuesta puede deberse a que tanto el uso de proxy como el uso de NAT se emplean actualmente para “compartir una conexión a Internet”.

Figura 4 Ejemplo de NAT

EL BALANCEO DE CARGA. Para verlo, lo mejor es un ejemplo. Imaginemos que tenemos una máquina en la que corre un servidor HTTP, una de las páginas que ofrece el servidor, tiene un número de visitas diarias muy elevado, (por ejemplo
Para ver este enlace Registrate o Inicia Sesion). El servidor, está conectado a Internet con un ancho de banda suficientement e bueno y está disponible para todo el mundo. El problema, es que dada la afluencia tan alta de peticiones a las que se ve sometida, la máquina se sobrecarga y las páginas se sirven con mucha lentitud. ¿Cómo resolverlo?

O compramos un servidor más potente, o utilizamos NAT.

La IP que tenía la máquina servidor y que estaba asociada a la URL
Para ver este enlace Registrate o Inicia Sesion, se le asigna a una máquina que actúa como radware (balanceador), ésta reparte la carga entre varios servidores de páginas web (que forman parte de una LAN Ethernet) que están configurados de forma similar (todos ellos sirven las mismas páginas). La carga de los servidores queda entonces repartida y se facilita la redundancia del sitio.

Los servidores HTTP que alojan sitios web importantes, o con gran número de visitas, utilizan este sistema de balanceo para que el tiempo de respuesta de las peticiones sea bajo y se pueda mantener el servicio si alguno se avería o se apaga.

Figura 5 Ejemplo de un sistema de balanceo de carga HTTP .

El filtrado de paquetes y NAT están muy ligados entre sí. Como hemos visto, ambos servicios constituyen el módulo Netfilter y se configuran haciendo uso de la herramienta iptables. En el pasado, Linux utilizaba ipmasqadm.

7.5. INSTALACIÓN DE IPTABLES.

Podemos descargar iptables desde el sitio web de Netfilter
Para ver este enlace Registrate o Inicia Sesion, o buscarlo en el CD de rpms de RedHat 9, pero en cualquier distribución actual se instala por defecto y el kernel “precompilado” soporta la configuración, no obstante, describiré, brevemente, el proceso de instalación.

Parámetros del kernel.

Para utilizar iptables, necesitamos un kernel superior a la versión 2.3.15. y para su configuración correcta será necesario recompilarlo (make config) e incluir las distintas opciones, o bien habilitar la posibilidad de que puedan cargarse posteriormente como módulos.

A continuación, están descritas brevemente las opciones más importantes:

CONFIG_PACKET: Permite a ciertos programas trabajar directamente con la interfaz de red.
CONFIG_NETFILT ER: Opción necesaria para utilizar la máquina como cortafuegos y/o router.
CONFIG_IP_NF_F ILTER: Habilita el uso de la tabla FILTER.
CONFIG_IP_NF_N AT: Habilita el uso de la tabla de NAT.
CONFIG_IP_NF_I PTABLES: Opción necesaria para utilizar iptables.
CONFIG_IP_NF_C ONNTRACK: Opción necesaria para usar NAT y enmascaramient o (seguimiento de conexiones).
CONFIG_IP_NF_T ARGET_MASQUERA DE: opción necesaria para trabajar con NAT cuando la IP de conexión a Internet es dinámica.
CONFIG_IP_NF_F TP: Opción necesaria para poder hacer seguimiento de conexiones a servidores ftp a través del cortafuegos.
CONFIG_IP_NF_M ATCH_LIMIT: Esta opción permite limitar en el tiempo el número de paquetes que casan con una cierta regla. Se utiliza para limitar ataques DOS por sobrecarga.
CONFIG_IP_NF_M ATCH_MAC: Permite el uso de direcciones MAC (Ethernet) en las reglas de filtrado.
CONFIG_IP_NF_M ATCH_STATE: Es una de las principales novedades respecto a ipchains, pues permite hacer filtrado a partir del estado de una conexión TCP (por ejemplo ESTABLISHED…).
CONFIG_IP_NF_M ATCH_OWNER: Es un módulo recientemente incorporado a iptables, con el podemos filtrar paquetes en función del usuario que es dueño (UID).
CONFIG_IP_NF_T ARGET_LOG: Permite registrar en ficheros .log el disparo de las reglas. Se utiliza para observar situaciones extrañas en la configuración o posibles ataques.

Figura 6 Distintas opciones del kernel.

Tanto iptables como el kernel, están preparados para soportar la definición de nuevos criterios de evaluación en las condiciones de las reglas o nuevas acciones a efectuar con los paquetes.

Estas extensiones, pueden ser implementadas por nosotr@s, o bien podemos descargar alguna extensión pública y utilizarla.

7.6. EL PROCESO DE NSTALACIÓN DE IPTABLES.

En las distribuciones RedHat superiores a la 7.1, el Kernel que se instala por defecto está ya configurado con iptables. El único problema que podemos encontrar, es que ipchains este habilitado también. Para deshabilitarlo en el arranque del sistema y no cause conflictos con iptables basta ejecutar:

[root@casiopea /root]# chkconfig --level 0123456 ipchains off; service ipchains stop

Finalmente, para arrancar el servicio iptables en el arranque del sistema ejecutaremos el comando siguiente:

[root@casiopea /root]# chkconfig --level 235 iptables on; service iptables start

Naturalmente, no hay ninguna regla activa. Las reglas creadas con el comando iptables se almacenan, por defecto, sólo en memoria, es decir, que si reiniciamos el sistema tras haber configurado varias reglas de iptables, éstas se perderán y tendremos que volver a escribirlas. Para incluir las reglas al inicio del sistema, podemos hacer varias cosas.

La primera, editar el archivo script /etc/rc.d/init.d/iptables, este script se ejecuta cada vez que se inicia el servicio iptables. Otra opción, es introducir las reglas mediante el comando iptables y cuando el cortafuegos funcione bien, guardarlas en el fichero /etc/sysconfig/iptables. El método que utilizaremos para guardar las reglas es el siguiente; ejecutamos:

[root@casiopea /root]# /sbin/service iptables save

Esto hace que el script de inicio de iptables (rc.d) ejecute el programa /sbin/iptables-save y escriba la configuración actual en el fichero /etc/sysconfig/iptables. Este fichero será exclusivamente visible por el/la usuari@ root, para evitar que las reglas de filtrado sean accesibles por el resto de l@s usuari@s.

La próxima vez que se inicie el sistema, el script de inicio de iptables volverá a aplicar las reglas guardadas en /etc/sysconfig/iptables usando el comando /sbin/iptables-restore.

Finalmente, podemos desinstalar el paquete de ipchains con el comando:

[root@casiopea /root]# rpm -e ipchains

7.7. ESTRUCTURA Y FUNCIONAMIENTO DE IPTABLES.

Comentamos al principio del módulo, que el módulo netfilter, integraba tres posibilidades en el manejo de los paquetes, cada una de ellas, se corresponde con una tabla donde se aplican las reglas.

Con la opción iptables –t tabla, especificamos la tabla sobre la que queremos trabajar. Estas tablas son filter, nat y mangling. Veamos que podemos hacer sobre ellas:

NAT: La tabla nat se utiliza para configurar el protocolo Network Addess Translation. Cuando un flujo de paquetes (una conexión TCP) atraviesa la tabla, el primer paquete es admitido, el resto, son automáticamente identificados como parte del flujo de ese primer paquete y de manera automática se llevan a cabo sobre ellos las operaciones NAT o de enmascaramient o. Esta es la razón por la cual, no se lleva a cabo ningún tipo de filtrado en esta tabla. La tabla de nat tiene tres cadenas sobre las que podemos añadir reglas. La cadena PREROUTING se utiliza para alterar los paquetes tan pronto llegan al cortafuegos (DNAT o NAT del destino). La cadena OUTPUT, se utiliza para alterar los paquetes generados localmente dentro del cortafuegos, antes de tomar ninguna decisión de enrutado. Finalmente tenemos la cadena POSTROUTING para alterar los paquetes que abandonan el cortafuegos (SNAT o NAT en el origen).

MANGLE: La tabla de mangling o “manipulación”, permite manipular otros elementos de los paquetes, como el TTL, el TOS, etc…, a excepción del NAT, que se realiza en la otra tabla. La funcionalidad de esta tabla está en expansión y aunque potencialmente puede ser muy valiosa, no tiene demasiada utilidad (salvo para hackers). Consta de dos cadenas, PREROUTING y OUTPUT.

FILTER: En la tabla filter, se llevan a cabo las principal tarea de iptables, el filtrado de paquetes. Como las anteriores, consta de varias cadenas predefinidas, (INPUT, FORWARD y OUTPUT). La primera hace referencia a los paquetes entrantes cuyo destino es el propio cortafuegos. La segunda se emplea para decidir que hacer con los paquetes que llegan al cortafuegos y tienen como destino otro host, así podemos decidir si encaminarlos o no, y por último, la cadena OUTPUT se utiliza para filtrar paquetes generados en el propio host con destinos externos.

Cuando un paquete entra en el cortafuegos, lo hace a través de alguna interfaz (tarjeta de red, MODEM…). El paquete se dirige al Kernel, entrando en las distintas cadenas de las tablas sólo si procede. En la siguiente figura, puede observarse el esquema general del procesado de paquetes en iptables. En la tabla siguiente podemos ver también ejemplos del tráfico de los paquetes en su tránsito por el módulo netfilter del kernel.

Podemos comentar algunas curiosidades del esquema anterior. Supongamos que disponemos de una conexión compartida a Internet. RED1 es una red local con IPs privadas, y la RED2 es Internet.

Para acceder a servicios externos de Internet desde la RED1 (por ejemplo WWW), utilizaremos NAT, ¿Cómo funciona? Un paquete con origen en 192.168.0.2 (IP de un PC de la LAN), tiene como destino el puerto 80 de la IP 157.88.94.240 (
Para ver este enlace Registrate o Inicia Sesion

www.palencia.u va.es

).

El paquete llega a la interfaz interna del cortafuegos, pasa por la tabla de mangling sin recibir ninguna modificación, atraviesa la tabla de NAT prerouting sin modificarse, se observa que el destino es externo, por lo que se encamina a través de la tabla filter y de la cadena FORWARD.

Ssuponiendo que atraviesa todas sus reglas (es decir, que no se impide que l@s usuari@s de la LAN accedan a servidores HTTP externos), se llega de nuevo a la decisión de encaminamiento y tras ella, el paquete atraviesa la tabla NAT y la cadena POSTROUTING, es aquí donde se modifica la dirección origen del paquete para que coincida con la IP pública del cortafuegos.

A partir de este instante, el flujo de paquetes de esa conexión, van marcados por la tabla NAT que lo gestiona de forma autónoma.

7.8. EL COMANDO IPTABLES.

En este apartado, veremos el uso del comando iptables, que es la herramienta para crear las reglas de nuestro cortafuegos.

iptables -[ADC] chain rule-specification [options]
iptables -[RI] chain rulenum rule-specification [options]
iptables -D chain rulenum [options]
iptables -[LFZ] [chain] [options]
iptables -[NX] chain
iptables -P chain target [options]
iptables -E old-chain-name new-chain-name

Figura 8 Opciones de iptables a través del comando man.

Como ya habíamos visto antes, iptables, funciona mediante tres tablas, a su vez, cada una de estas tablas, tiene definidas unas cadenas. Cada una de ellas se compone de una lista de reglas de filtrado. Cada regla no es más que un par condición/acción sobre atributos del paquete IP.

El paquete, irá pasando secuencialment e por cada una de las reglas de la Cadena hasta encajar en el patrón de alguna de ellas. Cuando esto ocurra, se tratará según indique la acción de la regla con cuya condición ha encajado. El recorrido por la lista de reglas es secuencial, por lo que es muy importante el orden en el cual coloquemos las reglas. Haremos hincapié en ello más adelante.

Si tras recorrer toda la lista, el paquete no encaja con ninguna de las reglas, se ejecutará la acción por defecto asociada a esa cadena.

Ahora, podemos adentrarnos en las opciones de la herramienta iptables. Primero, veremos como manipular las cadenas. La utilización del comando, presenta siempre el siguiente patrón:

iptables [-t tabla] comando [match] [objetivos/saltos]

Las tablas son siempre una de las tres siguientes filter, nat, o forward. Si no se indica tabla alguna, por defecto, nos referimos a la tabla filter. Para añadir y manipular cadenas utilizaremos siempre los comandos siguientes:

iptables –N: Crear una nueva cadena o cadena vacía (sin reglas).
iptables –X: Elimina una cadena que esté vacía (a excepción de las tres internas)
iptables –F: Vacía una cadena. Es decir, elimina todas las reglas de una cadena.
iptables –P: Cambia la política por defecto de una cadena.
iptables –L: Lista las reglas de una cadena.
iptables –Z: Pone a cero las variables de auditoría de una chain (número de paquetes, de bytes, etc…)

Con los comandos siguientes conseguimos manejar las reglas de esas cadenas:

iptables –A: Inserta al final de una cadena una nueva regla.
iptables –I: Inserta al comienzo de una cadena una nueva regla.
iptables –R: Reemplaza una regla de una cadena.
iptables –D: Elimina una regla de una cadena (podemos indicar el orden o su condición).

Por último, sólo queda mostrar como podemos establecer las condiciones y acciones sobre cada regla, es decir como establecer las condiciones de match entre paquetes y reglas:

iptables –s: Indica un dominio o IP (rango de IPs) de origen sobre el que se evalúa la condición de la regla.
iptables –d: Indica un dominio o IP (rango de IPs) de destino el que se evalúa la condición de la regla.
iptables –i (--in-interface): Indica la interfaz de entrada sobre la cual se evalúa la condición de la regla.
iptables –o (--out-interface): Indica la interfaz de salida sobre la cual se evalúa la condición de la regla.
iptables –p: Especifica el protocolo del datagrama que concordará con esta regla.

Los nombres válidos de protocolos son tcp, udp, icmp, o un número, si se conoce el número del protocolo de IP. Cada protocolo lleva asociados sus propios modificadores a través de las extensiones correspondient es:

EXTENSIONES DE TCP:

–-sport: Especifica el puerto que debe utilizar el origen del datagrama para encajar con esta regla. Se pueden especificar los puertos en la forma de un rango, especificando los límites inferior y superior con los dos puntos “:” como delimitador. Por ejemplo, 20:25 describe todos los puertos que van desde el 20 hasta el 25 incluyendo ambos. De nuevo, el signo “!” puede utilizarse para negar los valores.

--dport: Igual que la opción anterior pero para el puerto destino.
--tcp-flags: Especifica mediante una máscara si los bits indicadores de TCP del datagrama concuerdan con ella. La máscara es una lista separada por comas de los indicadores que deben examinarse en la comprobación. (SYN, ACK, FIN, RST, URG, PSH, ALL o NONE).
-–syn: La regla encaja con los datagramas cuyo bit SYN valga 1 y cuyos bits ACK y FIN valgan ambos 0. Esta opción es una abreviatura de: --tcp-flags SYN,RST,ACK SYN.

EXTENSIONES UDP:

–-sport: Como en TCP, especifica el puerto que debe utilizar el origen del datagrama para encajar con esta regla.
--dport: Igual que la opción anterior pero para el puerto destino.

EXTENSIONES ICMP:

–-icmp-type: Puede especificarse el tipo de mensaje ICMP tanto por su número como por los siguientes identificadore s: echo-request, echoreply, source-quench, time-exceeded, destination-unreachable, network-unreachable, host-unreachable, protocol-unreachable, y port-unreachable.

EXTENSIONES MAC:

–-mac-source: Se especifica la dirección MAC (ethernet). Sólo se utiliza en las cadenas INPUT y FORWARD.
- iptables –f: Cuando se fracciona un datagrama debido a que se supera el MTU de la red, podemos utilizar esta opción para especificar acciones sobre el segundo y restantes fragmentos del datagrama.
- iptables ¡: Invierte el valor lógico de la condición de la regla.

Existen más posibilidades de filtrado, y como ya hemos dicho, podemos diseñar las propias por la facilidad de extensión de iptables. Estas extensiones, son librerías compartidas que normalmente están en /usr/local/lib/iptables/, aunque, según distribuciones, pueden aparecer en /lib/iptables/ ó en /usr/lib/iptables/. Sirviéndonos de ellas podemos incluir filtrado sobre multitud de nuevas opciones o realizar acciones muy curiosas con los paquetes filtrados.

Como siempre, a medida que las extensiones demuestran su utilidad, se añaden a la distribución estándar de iptables, y si no hay ninguna que nos ofrezca lo que buscamos, podemos crearla nosotr@s mismos J.

7.9. UN CASO REAL: UNA HOME-LAN.

El manejo de iptables es sencillo, aunque explicarlo mediante la simple narración puede que parezca más complicado de lo que en realidad es. La mejor manera de entenderlo es a través de su aplicación a un caso real. Para ello, supongamos que vamos a configurar un cortafuegos de filtrado de paquetes para la red de la figura siguiente:

Figura 9 Home-LAN de ejemplo.

En principio, las tres maquinas de la red son simples estaciones de trabajo, que tal vez exportan algún directorio por SMB dentro de la propia red local. Por lo que debemos preocuparnos principalmente de que tengan salida a Internet los principales servicios, clientes HTTP, FTP, etc.

Por contra, casiopea además de actuar de cortafuegos, queremos que corran servicios exportados tanto a la LAN como a Internet, por ejemplo un servidor HTTP, un servidor FTP y un servidor SSH para poder conectarnos remotamente a la máquina.

Además, deberemos resolver el problema del servicio DNS para la red local. La opción más sencilla, es configurar las máquinas de la red para que utilicen el mismo servidor DNS que la máquina cortafuegos (casiopea), es decir, los DNS del ISP (en este caso RETECAL).

La otra alternativa, es ejecutar un servidor DNS en el cortafuegos y configurar las máquinas de la red local para que lo utilicen. Naturalmente, el servicio DNS que correrá en casiopea, será sólo un servicio de caché. Esta segunda configuración, es mas compleja, aunque ofrece ventajas respecto a la primera porque reduce el tráfico de peticiones DNS hacia Internet, ya que se resuelven localmente salvo cuando no están en caché, por este motivo, el tiempo medio de servicio en la resolución de un nombre de maquina descenderá ligeramente.

Supondremos que la red interna es confiable, es decir, que de existir alguna amenaza, ésta vendrá desde Internet, no desde dentro. Tenemos que tener en cuenta que la IP proporcionada por RETECAL es dinámica, esto puede traernos pequeños quebraderos de cabeza en el caso que deseemos (como es nuestro caso) filtrar utilizando nuestra dirección IP pública. Hay diversas soluciones, pero dado que mi ISP ofrece cierta “estabilidad” en la duración de las IP (algunas han durado meses). Si el ISP cambia nuestra IP de forma muy frecuente, tal vez interese utilizar alguna utilidad como pump, DHCPCD o dhclient, programas que permiten ejecutar un script cada vez que se produce un cambio de IP.

La solución más sencilla, es obtener la IP mediante la ejecución de:

EXT_IP=`ifconfig $EXT_IF | grep inet | cut -d : -f 2 | cut -d \ -f 1`

O de algún método equivalente como:

EXT_IP="`ifconfig $EXT_IF | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"

Resueltos estos problemas, sólo queda estructurar el script en función de nuestras necesidades.

Por ejemplo, para permitir accesos al servidor HTTP, FTP o SSH de casiopea desde cualquier lugar, bastaría con:

#Servicio FTP
iptables -t filter -A INPUT -p TCP -s 0/0 --dport 21 -j allowed
#Servicio SSH
iptables -t filter -A INPUT -p TCP -s 0/0 --dport 22 -j allowed
#Servicio HTTP
iptables -t filter -A INPUT -p TCP -s 0/0 --dport 80 -j allowed

Si el servidor HTTP se ejecutase en aldebaran en lugar de en casiopea, deberíamos emplear DNAT.

#Servicio HTTP dentro de la LAN. Se exporta al exterior
iptables -t nat -A PREROUTING –i $EXT_IF -p tcp --dport 80 -j \ DNAT --to-destination 192.168.0.2

Tras ver la sintaxis de iptables y comprender como es su funcionamiento, configurar el cortafuegos a medida es una cuestión de paciencia. A media que nos volvemos “paranoicos” o necesitamos una mayor seguridad, las cosas se van complicando.

El script de configuración del cortafuegos para la red local de la figura anterior, puede verse un poco más tarde. El cortafuegos presentado, es relativamente seguro y bastante sencillo aunque contiene casi 300 líneas de código.

Si no se desea una seguridad o filtrado extremo, actualmente existen herramientas gráficas que permiten generar scripts generales de configuración, a pesar de que puede que no excesivamente eficientes, pueden servir de base para “retocarlo” después a mano y evitar teclear demasiado.

SCRIPT DE IPTABLES PARA UNA HOME-LAN

#!/bin/bash
# Script de configuración del Firewall $IPTABLES para Kernels 2.4.x
#---------------------------------------------------------------------------
#---------------------------------------------------------------------------
#Colores para la información que ofreceremos por pantalla.
rojo="${esc}[31m"
verde="${esc}[32m"
azul="${esc}[34m"
echo "${rojo}"
echo "---------------------------------------------"
echo "${azul}
echo "---- Script de configuración de iptables ----"
echo "${rojo}"
echo "---------------------------------------------"
#---------------------------------------------------------------------------
#---------------------------------------------------------------------------
# Configuración de algunas variables.
echo "${azul}"
echo -n " ---- Configurando Variables ---- "
KERNEL=`uname -a|cut -f3 -d " "`
LAN_IP_RANGE="192.168.0.0/24" #IP's permitidas en la LAN 192.168.0.[0...255]
LAN_IP="192.168.0.1" #IP de la interfaz de la LAN.
ANYIP="0/0" #Cualquier IP.
LAN_BCAST_ADRE SS="192.168.0.255" # Dirección bradcast.
LO_IF="lo" #Interfaz de loopback
LO_IP="127.0.0.1" # LocalHost IP 127.0.0.1
EXT_IF="eth0" # Interfaz de red Externa (Conexión a Internet)
INT_IF="eth1" # Interfaz de red Interna (Conexión a la LAN)
IPTABLES="/usr/sbin/iptables" #"whereis iptables" si se desconoce el PATH.
IPPRIVADACLASE _A="10.0.0.0/8"
IPPRIVADACLASE _B="172.16.0.0/12"
IPPRIVADACLASE _C="192.168.0.0/16"
CLASE_D_MULTIC AST="224.0.0.0/4"
CLASE_E_RESERV ADAS="240.0.0.0/5"
EXT_IP="`ifconfig $EXT_IF|grep 'inet addr'|awk '{print $2}'|sed -e's/.*://'`"
echo "${verde}"
echo " [.] Versión del Kernel : $KERNEL"
echo " [.] Localización iptables : $IPTABLES"
echo " [.] Interfaz externa : $EXT_IF"
echo " [.] Dirección IP externa : $EXT_IP"
echo " [.] Interfaz LAN : $INT_IF"
echo " [.] Dirección IP LAN : $LAN_IP"
echo "¡Hecho!"
#---------------------------------------------------------------------------
#---------------------------------------------------------------------------
# Cargamos los módulos de iptables que necesitamos
echo "${azul}"
echo -n " ---- Cargando módulos requeridos de NetFiler ----"
/sbin/depmod -a
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state
/sbin/modprobe ipt_MASQUERADE
#/sbin/modprobe ipt_owner
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ip_conntrack_f tp
#/sbin/modprobe ip_conntrack_i rc
echo "${verde}"
#echo "lsmod"
echo "¡Hecho!"
#---------------------------------------------------------------------------
#---------------------------------------------------------------------------
echo "{azul}
echo -n "---- Estableciendo parametros del Kernel en /proc/sys/net/ipv4 ----"
# Activamos la opción de FORWARDING. La opción es CRÍTICA si el firewall
# tiene más de una interfaz de red y queremos que encamine tráfico entre
ellas.
echo "1" > /proc/sys/net/ipv4/ip_forward
# Habilitamos el la opción de verificación de dirección
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo "1" > $f
done
# Activamos la opción de sync cookies. Con ello, nos protejemos ante el
# ataque DOS de bomba SYNC
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
# Activamos la opción de protección de mansajes ICMP, con ello evitamos
# ataques DOS de bomba ICMP
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# IMPORTANTE: SÓLO PARA USUARIOS CON IP DINÁMICA. (La mayoría)
# Si tu ISP proporciona IP's dinámicas en tu conexión SLIP, PPP, o DHCP,
# debes ejecutar la línea siguientes.
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# DESHABILITAMOS la aceptación de paquetes cuyas ruta haya sido
# prefijada en el origen (source routed packets).
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo "0" > $f
done
# DESHABILITAMOS la aceptación de paquetes ICMP del tipo
# Redirect Acceptance
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo "0" > $f
done
# DESHABILITAMOS la posibilidad de enviar paquetes ICMP del tipo
# Redirect Acceptance.
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo "0" > $f
done
#DESHABILITAMOS la posibilidad de enviar mensajes de redirección
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo "0" > $f
done
echo "${verde}"
echo -n " [.] Parámetros del Kernel establecidos. "
echo "¡Hecho!"
#---------------------------------------------------------------------------
#------------------------------ INICIALIZACIÓN -----------------------------
# Inicializamos el módulo Netfilter
echo "${azul}"
echo -n "... Inicializando NetFilter ... "
# Eliminamos las reglas de TODAS las cadenas de cada tabla
$IPTABLES -t filter --flush
$IPTABLES -t nat --flush
$IPTABLES -t mangle --flush
# Con las TODAS las cadenas vacías, dejamos sólo las cadenas por defecto
$IPTABLES -t filter --delete-chain
$IPTABLES -t nat --delete-chain
$IPTABLES -t mangle --delete-chain
# Fijamos las políticas por defecto para el filtrado.
$IPTABLES -t filter --policy INPUT DROP
$IPTABLES -t filter --policy OUTPUT DROP
$IPTABLES -t filter --policy FORWARD DROP
echo "${verde}"
echo -n " [.] Tablas y cadenas vaciadas. Establecidas políticas por defecto"
echo "¡Hecho!"
#---------------------------------------------------------------------------
#------------------ Construcción de las reglas de filtrado -----------------
echo "${azul}"
echo -n ".... Comienza la inserción de reglas de cortafuefos .... "
# Comenzamos la inserción de reglas en la tabla filter.
# Creamos cadenas para los paquetes no validos
$IPTABLES -N bad_tcp_packet s
$IPTABLES -N bad_tcp_input_ packets
# Creamos cadenas separados para los protocolos ICMP, TCP y UDP
$IPTABLES -t filter -N allowed
$IPTABLES -t filter -N icmp_packets
$IPTABLES -t filter -N tcp_packets
$IPTABLES -t filter -N udpincoming_pa ckets
# --- Cadenas bad_tcp_packet s y bad_tcp_input_ packets
# Los paquetes TCP entrantes no presentarán situaciones extrañas
# en sus BITS (evitaremos ataques DOS)
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
ALL NONE -j DROP
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
SYN,FIN SYN,FIN -j DROP
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
SYN,RST SYN,RST -j DROP
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
FIN,RST FIN,RST -j DROP
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
ACK,FIN FIN -j DROP
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
ACK,PSH PSH -j DROP
$IPTABLES -t filter -A bad_tcp_input_ packets -p tcp --tcp-flags \
ACK,URG URG -j DROP
$IPTABLES -t filter -A bad_tcp_packet s -p tcp ! --syn -m state --state \
NEW -j LOG --log-prefix "filter bad_tcp_packet s Posible ataque SYN:"
$IPTABLES -t filter -A bad_tcp_packet s -p tcp ! --syn -m state --state \
NEW -j DROP
# --- Cadena allowed
$IPTABLES -t filter -A allowed -p tcp --syn -j ACCEPT
$IPTABLES -t filter -A allowed -p tcp -m state --state ESTABLISHED, \
RELATED -j ACCEPT
$IPTABLES -t filter -A allowed -p tcp -j DROP
# --- Cadena icmp_packets
#Permitimos la salida y entrada de PINGs
$IPTABLES -t filter -A icmp_packets -p icmp -s $ANYIP --icmp-type 8 \
-j ACCEPT
$IPTABLES -t filter -A icmp_packets -p icmp -s $ANYIP --icmp-type 11 \
-j ACCEPT
# --- Cadena tcp_packets
#Servicio FTP
$IPTABLES -t filter -A tcp_packets -p tcp -s $ANYIP --dport 21 -j allowed
#Servicio SSH
$IPTABLES -t filter -A tcp_packets -p tcp -s $ANYIP --dport 22 -j allowed
#Servicio HTTP
$IPTABLES -t filter -A tcp_packets -p tcp -s $ANYIP --dport 80 -j allowed
#Servicio IDENTD
$IPTABLES -t filter -A tcp_packets -p tcp -s $ANYIP --dport 113 -j allowed
# --- Cadena udpincoming_pa ckets
#Servicio DNS caché para la red local.
$IPTABLES -t filter -A udpincoming_pa ckets -p udp -s $LAN_IP_RANGE \
--source-port 53 -j ACCEPT
# --- Cadena INPUT.
# Todo paquete entrante, deberá ser bueno.
$IPTABLES -t filter -A INPUT -p tcp -j bad_tcp_packet s
# Rechazamos paquetes entrantes por la interfaz de red Externa con IPs de
# origen extrañas (anti spoofing)
$IPTABLES -t filter -A INPUT -i $EXT_IF -s $EXT_IP -j DROP
$IPTABLES -t filter -A INPUT -i $EXT_IF -s $IPPRIVADACLASE_A -j DROP
$IPTABLES -t filter -A INPUT -i $EXT_IF -s $IPPRIVADACLASE_B -j DROP
$IPTABLES -t filter -A INPUT -i $EXT_IF -s $IPPRIVADACLASE_C -j DROP
$IPTABLES -t filter -A INPUT -i $EXT_IF -s $CLASE_D_MULTICAST -j DROP
$IPTABLES -t filter -A INPUT -i $EXT_IF -s $CLASE_E_RESERVADAS -j DROP
# Los paquetes que provienen de Internet deben ser alguno de los definidos
$IPTABLES -t filter -A INPUT -p icmp -i $EXT_IF -j icmp_packets
$IPTABLES -t filter -A INPUT -p tcp -i $EXT_IF -j tcp_packets
$IPTABLES -t filter -A INPUT -p udp -i $EXT_IF -j udpincoming_pa ckets
# Reglas especiales
#Mensajes a la dirección de broadcast desde la LAN hacia la LAN
$IPTABLES -t filter -A INPUT -p ALL -i $INT_IF -d $LAN_BCAST_ADRESS -j ACCEPT
#Permitimos conexión de Loopback.
$IPTABLES -t filter -A INPUT -p ALL -i $LO_IF -s $LO_IP -j ACCEPT
$IPTABLES -t filter -A INPUT -p ALL -i $LO_IF -s $INT_IP -j ACCEPT
$IPTABLES -t filter -A INPUT -p ALL -i $LO_IF -s $EXT_IP -j ACCEPT
#Peticiones de la red local
$IPTABLES -t filter -A INPUT -p ALL -i $INT_IF -s $LAN_IP_RANGE -j ACCEPT
$IPTABLES -t filter -A INPUT -p ALL -d $EXT_IP -m state --state ESTABLISHED, \
RELATED -j ACCEPT
#Registramos un máximo de 3 paquetes por minuto que no casen con las
#reglas anteriores
$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j \
LOG --log-level DEBUG --log-prefix "filter INPUT paquete perdido: "
# --- Cadena FORWARD.
# Solo encaminamos paquetes válidos
$IPTABLES -t filter -A FORWARD -p tcp -j bad_tcp_packet s
# Aceptamos ecaminar los paquetes porcedentes de la LAN
$IPTABLES -t filter -A FORWARD -i $INT_IF -j ACCEPT
$IPTABLES -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
#Registramos un máximo de 3 paquetes por minuto que no casen con las
#reglas anteriores
$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j \
LOG --log-level DEBUG --log-prefix "filter FORWARD paquete perdido: "
# --- Cadena OUTPUT.
# Solo permitimos paquetes válidos
$IPTABLES -t filter -A OUTPUT -p tcp -j bad_tcp_packet s
# Permitimos paquetes salientes con origen en el host
$IPTABLES -t filter -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -t filter -A OUTPUT -p ALL -s $INT_IP -j ACCEPT
$IPTABLES -t filter -A OUTPUT -p ALL -s $EXT_IP -j ACCEPT
#Registramos un máximo de 3 paquetes por minuto que no caden con las
#reglas anteriores
$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j \
LOG --log-level DEBUG --log-prefix "filter OUTPUT paquete perdido: "
echo "${verde}"
echo -n " [.] Política de filtrado establecida"
echo "¡Hecho!"
#---------------------------------------------------------------------------
#------------------- Construcción de las reglas de NAT ---------------------
# Habilitamos NAT, TODO el tráfico interno es enmascarado cuando sale al
# exterior
echo "${azul}"
echo -n ".... Configuración de NAT .... "
#REM: Utilizamos MASQUERADE porque la IP es dinámica
$IPTABLES -t nat -A POSTROUTING -s $LAN_IP_RANGE -o $EXT_IF -j MASQUERADE
echo "${verde}"
echo -n " [.] Política de enmascaramient o establecida"
echo "¡Hecho!

Después del ladrillo (perdón), sigamos.

Nmap provee al atacante de muchas opciones para escanear. La estándar de Nmap, no proporciona información si el objetivo tiene cortafuegos. ¿Pero cómo funciona un cortafuegos?.

Cómo se ha visto arriba, un cortafuegos trabaja filtrando paquetes. Imaginemos que somos un atacante. Hacemos un escaneo normal con Nmap, y no nos sale absolutamente nada (todos los puertos bloqueados).

Continuemos con la parte 2.

-f (fragmentar los paquetes); --mtu (utilizar el MTU especificado)

Imaginemos que somos un atacante remoto que utilizamos Nmap.

Tenemos entonces la opción -f. esta opción hace lo siguiente:
provoca que todos los escáneres que vayamos a realizar utilicen paquetes fragmentados. ¿Por qué esta división?. Pues muy sencillo: simplemente, al dividir la cabecera del paquete TCP, es mas difícil que los filtros de paquetes o los sistemas de detección de intrusos detecten que un ataque está llevándose a cabo. Desgraciadamen te para los administradore s que usen cortafuegos comerciales (por ejemplo, zone alarm) no podrán configurar a su gusto los detectores de paquetes. Que yo sepa, sólo en Linux puedes implementar algo serio como para evitar ataques de paquetes fragmentados. ¿Cómo se logra?. Pues así: te vas al núcleo y le dices: CONFIG_IP_ALWA YS_DEFRAG. O sea:
Encólame todos los fragmentos de IP que encuentres. Sin embargo, algunas redes no pueden tolerar la pérdida de rendimiento que eso provoca, y deshabilitan esa opción.

Seguimos explicando.
Utilizamos Nmap, así que nos hemos leído antes el fantástico manual que se encuentra en el FTP de dueloshack. Por ello, sabemos que además de la opción -f, tenemos la opción --mtu.

Para saber que es el mtu, busca en google, pues estás aún un poco verde para entender lo que estoy tratando de explicar aquí.

Usamos el Nmap con la opción -f para fragmentar los paquetes una vez, si vuelves a poner -f, lo harás dos veces, y así sucesivamente.

Si usas --mtu, has de especificar un valor múltiplo de 8 (cuestiones de protocolo) para que funcione. La idea es la misma que la de fragmentar los paquetes que se envían con la opción -f.