Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES Arquitectura de Sistemas y Aplicaciones Distribuidas U.L.P.G.C.

Transcripción

1 Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES David Jesús Horat Flotats

2 Índice Introducción a los cortafuegos o firewall... 2 Introducción a iptables... 8 Parámetros de iptables SINOPSIS OBJETIVOS...11 TABLAS PARÁMETROS...11 EXTENSIONES...12 icmp state...12 tcp...13 Ejemplo de una política concreta Objetivos...14 Configuración...14 Ejemplos de acceso...22 Ip-Spoofing ICMP...22 Telnet FTP POP HTTP SMTP...33 DNS

3 Introducción a los cortafuegos o firewall 1 Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico o un software sobre un sistema operativo. En general debemos verlo como una caja con DOS o mas interfaces de red en la que se establecen una reglas de filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso puede ir más allá y realizar modificaciones sobre las comunicaciones, como el NAT. Esa sería la definición genérica, hoy en dia un firewall es un hardware especifico con un sistema operativo o una IOS que filtra el tráfico TCP/UDP/ICMP/../IP y decide si un paquete pasa, se modifica, se convierte o se descarta. Para que un firewall entre redes funcione como tal debe tener al menos dos tarjetas de red. Esta sería la tipología clásica de un firewall: Ilustración 1: Esquema de firewall típico entre red local e internet Esquema típico de firewall para proteger una red local conectada a internet a través de un router. El firewall debe colocarse entre el router (con un único cable) y la red local (conectado al switch o al hub de la LAN) Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a internet (como es el caso de un servidor web, un servidor de correo, etc..), y en esos casos obviamente en principio se debe aceptar cualquier conexión a 1 Extraído de 2

4 ellos. Lo que se recomienda en esa situación es situar ese servidor en lugar aparte de la red, el que denominamos DMZ o zona desmilitarizada. El firewall tiene entonces tres entradas: Ilustración 2: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el servidor sea accesible desde internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el firewall. Esta estructura de DMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un único dispositivo con al menos tres interfaces de red). Sería un esquema como este: 3

5 Ilustración 3: Esquema de firewall entre red local e internet con zona DMZ para servidores expuestos creado con doble firewall(perímetro) Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de internet en las empresas, aunque ahí también suelen tener una doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior; esto último se hace con el firewall o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel). También, en empresas de hosting con muchos servidores alojados lo normal es encontrarnos uno o más firewalls ya sea filtrando toda la instalación o parte de ella: 4

6 Ilustración 4: Esquema de firewall entre redes, en la que solo se filtra y no se hace NAT Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino de los paquetes del protocolo tcp/ip. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no solo los tcp, también los udp, los icmp, los gre y otros protocolos vinculados a vpns. Este podría ser (en pseudo-lenguaje) un el conjunto de reglas de un firewall del primer gráfico: Politica por defecto ACEPTAR. Todo lo que venga de la red local al firewall ACEPTAR Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR Todo lo que venga de la red local y vaya al exterior ENMASCARAR 5

7 Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR Todo lo que venga del exterior al puerto tcp 3389 DENEGAR Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR En definitiva lo que se hace es: - Habilita el acceso a puertos de administración a determinadas IPs privilegiadas - Enmascara el trafico de la red local hacia el exterior (NAT, una petición de un pc de la LAN sale al exterior con la ip pública), para poder salir a internet - Deniega el acceso desde el exterior a puertos de administración y a todo lo que este entre 1 y Hay dos maneras de implementar un firewall: 1) Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y solo se denegará lo que se diga explícitamente. 2) Política por defecto DENEGAR: todo esta denegado, y solo se permitirá pasar por el firewall aquellos que se permita explícitamente. Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que preocupar de proteger aquellos puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar. Por ejemplo, si queremos proteger una máquina linux, podemos hacer un netstat -ln (o netstat -an, o netstat -puta grep LISTEN), saber que puertos están abiertos, poner reglas para proteger esos puertos y ya está. Para qué vamos a proteger un puerto que realmente nunca se va a abrir? El único problema que podemos tener es que no controlemos que es lo que esta abierto, o que en un momento dado se instale un software nuevo que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política por defecto es ACEPTAR y no se protege explícitamente, nos la estamos jugando un poco. En cambio, si la política por defecto es DENEGAR, a no ser que lo 6

8 permitamos explícitamente, el firewall se convierte en un auténtico MURO infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro como funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a meter reglas super-permisivas. Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema. Uno de los objetos principales de este documento es mostrar la forma de crear este tipo de firewalls. IMPORTANTE El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace con un paquete se va comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se hace lo que dicte esta regla (aceptar o denegar); después de eso NO SE MIRARÁN MÁS REGLAS para ese paquete. Cuál es el peligro? Si ponemos reglas muy permisivas entre las primeras del firewall, puede que las siguientes no se apliquen y no sirvan de nada. 7

9 Introducción a iptables 2 IPtables es un sistema de firewall vinculado al kernel de linux que se ha extendido enormemente a partir del kernel 2.4 de este sistema operativo. Al igual que el anterior sistema ipchains, un firewall de iptables no es como un servidor que lo iniciamos o detenemos o que se pueda caer por un error de programación(esto es una pequeña mentira, ha tenido alguna vulnerabilidad que permite DoS, pero nunca tendrá tanto peligro como las aplicaciones que escuchan en determinado puerto TCP): iptables esta integrado con el kernel, es parte del sistema operativo. Cómo se pone en marcha? Realmente lo que se hace es aplicar reglas. Para ellos se ejecuta el comando iptables, con el que añadimos, borramos, o creamos reglas. Por ello un firewall de iptables no es sino un simple script de shell en el que se van ejecutando las reglas de firewall. El kernel lo que hace es, dependiendo si el paquete es para la propia maquina o para otra maquina, consultar las reglas de firewall y decidir que hacer con el paquete según mande el firewall. Este es el camino que seguiría un paquete en el kernel: Ilustración 5: Cuando un paquete u otra comunicación llega al kernel con iptables se sigue este camino Como se ve en el gráfico, básicamente se mira si el paquete esta 2 Extraído de 8

10 destinado a la propia maquina o si va a otra. Para los paquetes (o datagramas, según el protocolo) que van a la propia maquina se aplican las reglas INPUT y OUTPUT, y para filtrar paquetes que van a otras redes o maquinas se aplican simplemente reglas FORWARD. INPUT,OUTPUT y FORWARD son los tres tipos de reglas de filtrado. Pero antes de aplicar esas reglas es posible aplicar reglas de NAT: estas se usan para hacer redirecciones de puertos o cambios en las IPs de origen y destino. Veremos ejemplos. E incluso antes de las reglas de NAT se pueden meter reglas de tipo MANGLE, destinadas a modificar los paquetes; son reglas poco conocidas y es probable que no las usen. Por tanto tenemos tres tipos de reglas en iptables: - MANGLE - NAT: reglas PREROUTING, POSTROUTING - FILTER: reglas INPUT, OUTPUT, FORWARD. 9

11 Parámetros de iptables Iptables admite muchos parámetros, de los cuales a continuación se comentarán los principales y, más en concreto, los usados para la configuración realizado del firewall de nuestra máquina. SINOPSIS iptables [-t table] -[AD] chain especificación-regla [opciones] --> con A se añade una regla a la cadena de reglas; con D se borra una regla de la cadena de reglas. iptables [-t table] -I chain [numeroregla] especificación-regla [opciones] --> Insertar una regla en concreto. iptables [-t table] -R chain numeroregla especificación-regla [opciones] --> Reemplazar una regla en concreto. iptables [-t table] -D chain numeroregla [opciones] --> Eliminar una regla en concreto. iptables [-t table] -[LFZ] [chain] [opciones] --> L lista todas las reglas de una cadena de reglas; F hace un flush, es decir, actualiza los cambios en la cadena de reglas; Z pone a cero los paquetes y contadores de las cadenas de reglas. iptables [-t table] -N chain --> Crea una nueva cadena de reglas (chain). iptables [-t table] -X [chain] --> Elimina toda una cadena de reglas (chain). iptables [-t table] -P chain objetivo [opciones] --> Establece la política para una cadena de reglas, es decir, el objetivo para la misma. Sirve como política por defecto. 10

12 iptables [-t table] -E old-chain-name new-chain-name --> Renombre una cadena de reglas (chain). OBJETIVOS Las reglas de un firewall especifican un criterio para los paquetes y el objetivo, es decir, que hacer con ellos. Si una regla se valida se le aplica el objetivo. Los posibles objetivos son: ACCEPT indica que se deje pasar el paquete. DROP indica que se desecha el paquete. Otros: QUEUE y RETURN TABLAS Hay tres tipos de tabla: -t, --table tabla Indica sobre que tabla actuará la opción o comando. Las tablas son: filter: Tabla por defecto. Contiene las cadenas de reglas: INPUT (paquetes entrantes), FORWARD (paquetes enrutados), y OUTPUT (paquetes salientes). nat: Tabla para paquetes encontrados en conexiones nuevas. Admite las siguientes cadenas de reglas: PREROUTING, OUTPUT y POSTROUTING. mangle: Tabla para alteraciones especiales de los paquetes. PARÁMETROS Parámetros para especificar reglas. Se usan al añadir, eliminar, insertar, reemplazar y concatenar comandos. -p, --protocol [!] protocolo Protocolo del paquete a chequear. Se admite: tcp, udp, icmp, or all (por defecto), o un valor numérico. Con "!" se niega. 11

13 -s, --source [!] dirección[/máscara] Origen o fuente. La dirección puede ser un nombre de dominio, hostname, una IP de red o IP de máquina. La máscara puede ser de una red o una máquina, e indica el número de 1s. Se suele usar el alias --src. -d, --destination [!] dirección[/máscara] Destino. Se suele usar el alias dst. -j, --jump objetivo Indica el objetivo de la regla, es decir, que hacer con ella, que se indica en el apartado de OBJETIVOS. -i, --in-interface [!] name Interfaz por la que se reciben los paquetes. Admite las cadenas de reglas INPUT, FORWARD y PREROUTING. -o, --out-interface [!] name Interfaz por la que se envían los paquetes. Admite las cadenas de reglas FORWARD, OUTPUT y POSTROUTING. EXTENSIONES iptables puede extenderse, es decir, extender los módulos de matching de paquetes. Se puede hacer implícitamente (ej. con -p o protocol, que indican el protocolo y automáticamente se carga el módulo del protocolo) o explícitamente, con las opciones -m o --match, seguidas del nombre del módulo de matching; después de esto se dispone de varios comandos extra, según el módulo. icmp opción: Esta extensión se carga al indicar -p icmp. Proporciona la siguiente --icmp-type [!] typename Especifica el tipo de ICMP, que puede ser un valor numérico o nombres de tipos ICMP. En nuestro caso destacan dos: echo-request (interrogación o petición) y echo-reply (repuesta o contestación). state Este módulo, cuando se comibina con el seguimiento de conexiones, permite el acceso al seguimiento del estado de los paquetes. --state estado 12

14 El estado es una lista separado por espacios para comprobar los estados de la conexión. Los posibles estados son: INVALID indica que el paquete no puede identificarse. ESTABLISHED indica que el paquete está asociado con una conexión en la que se han visto paquetes en ambas direcciones. NEW indica que el paquete ha iniciado una nueva conexión o bien está asociado a una conexión en la que no se han visto paquetes en ambas direcciones. RELATED indica que el paquete está iniciando una nueva conexión, pero está asociado a una conexión existente. Es el caso de las transferencias de datos FTP o los errores ICMP. tcp Esta extensión se carga con -p tcp. Proporciona las siguientes opciones: --source-port [!] puerto[:puerto] Puerto o rango de puertos de origen. Puede indicar el nombre de un servicio (ej. ftp) o un número de puerto. Puede indicarse un rango inclusivo. Si se omite el primer puerto (:puerto) se toma 0. Si se omite el segundo valor (puerto:) se toma el valor máximo: Se suele usar el alias --sport. --destination-port [!] puerto[:puerto] Puerto o rango de puertos de destino. Se suele usar el alias --dport. 13

15 Ejemplo de una política concreta Objetivos Llevar a cabo la política de Denegación por defecto tal que todos los servicios estén prohibidos por defecto y haya que ir añadiendo servicios bajo petición. Activar los siguientes servicios IP-SPOOFING: Evitar spoofing the nuestras direcciones de red ICMP: Denegar Echo Request a máquinas internas Telnet: Solo hacia afuera FTP: Solo hacia afuera POP3: Solo hacia afuera por enlaces ethernet y ambos sentidos por enlaces ppp. HTTP: Solo hacia afuera y a través del servidor proxy proxy.ulpgc.es ( ) SMTP: Solo hacia afuera con la máquina que actúa como relaying de correo DNS: Ambos sentidos pero solo con la máquina que actuará de forwarder Configuración Para la configuración de iptables usaremos un script the bash creado para esta ocasión y comentado, con el mismo orden que la lista de servicios a activar indicada en los Objetivos. Además, consta de una declaración de variables previa, para que sirve para cualquier jerarquía de direcciones Ips. En el propio script se comenta lo que hace cada línea, que se han realizado (escrito) según el orden de las configuraciones a aplicar, tal y como el guión de la práctica lo indicaba. #!/bin/bash 14

16 # Variables INTERNET=eth0 LOCAL=eth1 REDLOCAL= /24 YO= echo "Aplicando Reglas de Firewall..." # Borrado de reglas iptables -F iptables -X iptables -Z iptables -t nat -F # Establecemos politica de denegaciã³n por defecto iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # [1] IP-SPOOFING - Evitar SPOOFING de nuestras direcciones de red... # [1.1] a la propia mã quina iptables -A INPUT -i $INTERNET -s $REDLOCAL -j DROP && echo "Impedimos IP-Spoofing" # [1.2] a las mã quinas de la red interna iptables -A FORWARD -i $INTERNET -s $REDLOCAL -j DROP && echo "Impedimos IP- Spoofing" # [2] ICMP - Denegar Echo Request a mã quinas internas y aceptar el resto # [2.1] Permitir ping hacia fuera, desde la red interna iptables -A FORWARD -i $LOCAL -p icmp --icmp-type echo-request -j ACCEPT && echo "Aceptamos ICMP request a travã s" 15

17 iptables -A FORWARD -i $INTERNET -p icmp --icmp-type echo-reply -j ACCEPT && echo "Aceptamos ICMP reply a travã s" # [2.2] Permitir ping hacia fuera, desde la propia mã quina iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT && echo "Aceptamos ICMP request hacia fuera" iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT && echo "Aceptamos ICMP reply hacia dentro" # [2.3] Permitir ping a la propia mã quina, desde la red local iptables -A INPUT -p icmp --icmp-type echo-request -s $REDLOCAL -j ACCEPT && echo "Aceptamos ICMP request de mi red" iptables -A OUTPUT -p icmp --icmp-type echo-reply -d $REDLOCAL -j ACCEPT && echo "Aceptamos ICMP reply a mi red" # [2.4] Admitir ping a mi mismo a travã s de la interfaz externa (en realidad, ya se cubre con las reglas [2.5]) #iptables -A INPUT -p icmp --icmp-type echo-request -s $YO -j ACCEPT && echo "Aceptamos ICMP request de mi mismo" #iptables -A OUTPUT -p icmp --icmp-type echo-reply -d $YO -j ACCEPT && echo "Aceptamos ICMP reply a mi mismo" # [2.5] Permite que: # 1. Me pueda hacer ping a mismo a travã s de la interfaz externa # 2. Me vean desde Internet a travã s de la interfaz externa (pero no de la interna) iptables -A INPUT -p icmp --icmp-type echo-request -d $YO -j ACCEPT && echo "Aceptamos ICMP request a mi mismo" iptables -A OUTPUT -p icmp --icmp-type echo-reply -s $YO -j ACCEPT && echo "Aceptamos ICMP reply de mi mismo" # [3] Telnet solo hacia fuera # [3.1] Dejar salir hacia fuera, desde red interna y la propia mã quina 16

18 iptables -A FORWARD -i $LOCAL -p tcp --dport 23 -s $REDLOCAL -j ACCEPT && echo "Aceptamos FTP a traves" iptables -A OUTPUT -p tcp --dport 23 -j ACCEPT && echo "Aceptamos FTP hacia fuera" # [3.2] Dejar entrar paquetes de las conexiones establecidas, hacia la red interna y la propia mã quina iptables -A FORWARD -i $INTERNET -p tcp -m tcp --sport 23 -m state --state 'RELATED' -- state 'ESTABLISHED' -j ACCEPT && echo "" iptables -A INPUT -p tcp -m tcp --sport 23 -m state --state 'RELATED' --state 'ESTABLISHED' -j ACCEPT && echo "" # [4] FTP solo hacia fuera # [4.1] Dejar salir hacia fuera, desde red interna y la propia mã quina iptables -A FORWARD -i $LOCAL -p tcp --dport ftp -s $REDLOCAL -j ACCEPT && echo "Aceptamos FTP a traves" iptables -A OUTPUT -p tcp --dport ftp -j ACCEPT && echo "Aceptamos FTP hacia fuera" # [4.2] Dejar entrar paquetes de las conexiones establecidas, hacia la red interna y la propia mã quina iptables -A FORWARD -i $INTERNET -p tcp -m tcp --sport ftp -m state --state 'RELATED' -- state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos FTP a traves hacia dentro de conexiones establecidas" iptables -A INPUT -p tcp -m tcp --sport ftp -m state --state 'RELATED' --state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos FTP hacia dentro siempre que venga de una conexiã³n establecida" # [5] DNS en ambos sentidos pero solo con la mã quina que actuarã de forwarder # [5.1] Dejar salir hacia , desde red interna y la propia mã quina iptables -A FORWARD -i $LOCAL -d p udp --dport 53 -j ACCEPT && echo "Aceptamos DNS hacia afuera" iptables -A OUTPUT -d p udp --dport 53 -j ACCEPT && echo "Aceptamos DNS 17

19 hacia " # [5.2] Dejar entrar paquetes desde , hacia la red interna y la propia mã quina iptables -A FORWARD -i $INTERNET -s p udp --sport 53 -j ACCEPT && echo "Aceptamos DNS de vuelta" iptables -A INPUT -s p udp --sport 53 -j ACCEPT && echo "Aceptamos DNS de vuelta" # [6] POP3 solo hacia fuera por enlace ethernet # [6.1] Dejar salir hacia fuera, desde red interna y la propia mã quina iptables -A FORWARD -i $LOCAL -p tcp --dport 110 -j ACCEPT && echo "Aceptamos POP3 hacia afuera" iptables -A OUTPUT -p tcp --dport 110 -j ACCEPT && echo "Aceptamos POP3 de vuelta" # [6.2] Dejar entrar paquetes de las conexiones establecidas, hacia la red interna y la propia mã quina iptables -A FORWARD -i $INTERNET -p tcp -m tcp --sport 110 -m state --state 'RELATED' -- state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos POP3 a traves hacia las mã quinas internas" iptables -A INPUT -p tcp -m tcp --sport 110 -m state --state 'RELATED' --state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos POP3 hacia la mã quina firewall" # [6.3] Dejar salir hacia fuera por ppp, desde red interna y la propia mã quina iptables -A FORWARD -i ppp+ -p tcp --sport 110 -j ACCEPT && echo "Aceptamos POP3 a traves hacia dentro" iptables -A OUTPUT -o ppp+ -p tcp --sport 110 -j ACCEPT && echo "Aceptamos POP3 a traves hacia fuera" # [6.4] Dejar entrar paquetes de las conexiones ppp establecidas, hacia la red interna y la propia mã quina iptables -A FORWARD -o ppp+ -p tcp --dport 110 -j ACCEPT && echo "Aceptamos POP3 a 18

20 traves hacia fuera" iptables -A INPUT -i ppp+ -p tcp --dport 110 -j ACCEPT && echo "Aceptamos POP3 a traves hacia dentro" # [7] HTTP solo hacia afuera y a travã s del servidor Proxy "proxy.rcanaria.es" ( ) # [7.1] Dejar salir hacia el proxy , desde red interna y la propia mã quina iptables -A FORWARD -i $LOCAL -d p tcp --dport j ACCEPT && echo "Aceptamos HTTP hacia afuera a proxy.ulpgc.es ( )" iptables -A OUTPUT -d p tcp --dport j ACCEPT && echo "Aceptamos HTTP de vuelta de proxy.ulpgc.es ( )" # [7.2] Dejar entrar paquetes de las conexiones establecidas, hacia la red interna y la propia mã quina iptables -A FORWARD -i $INTERNET -s p tcp -m tcp --sport m state -- state 'RELATED' --state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos POP3 a traves hacia las mã quinas internas" iptables -A INPUT -s p tcp -m tcp --sport m state --state 'RELATED' -- state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos POP3 hacia la mã quina firewall" # [8] SMTP solo hacia afuera con la mã quina (neptuno.redes.dis.ulpgc.es) que actãºa como relaying de correo # [8.1] Dejar salir hacia , desde red interna y la propia mã quina iptables -A FORWARD -i $LOCAL -d p tcp --dport 25 -j ACCEPT && echo "Aceptamos SMTP hacia afuera a " iptables -A OUTPUT -d p tcp --dport 25 -j ACCEPT && echo "Aceptamos SMTP hacia afuera a " # [8.2] Dejar entrar paquetes de las conexiones establecidas con , hacia la red interna y la propia mã quina iptables -A FORWARD -i $INTERNET -s p tcp -m tcp --sport 25 -m state --state 19

21 'ESTABLISHED' --state 'RELATED' -j ACCEPT && echo "Aceptamos SMTP de vuelta de " iptables -A INPUT -s p tcp -m tcp --sport 25 -m state --state 'ESTABLISHED' -- state 'RELATED' -j ACCEPT && echo "Aceptamos SMTP de vuelta de " read echo "Para comprobar que se aplica: iptables -L -n" read iptables -L -n Las tres últimas líneas se destinan a poder visualizar el estado resultante de las tablas del iptables, lo que sirve de comprobación de la activación de los servicios apropiados. Adicionalmente se dispone de otro script cuya finalidad es configurar iptables de forma que no filtre nada, es decir, que acepte todo. Dicho fichero de script se muestra a continuación: #!/bin/bash echo "Aplicando Reglas de Firewall..." echo "Aceptando todas las conexiones..." # Borrado de reglas iptables -F iptables -X iptables -Z iptables -t nat -F # Establecemos politica de aceptaciã³n por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT 20

22 iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT 21

23 Ejemplos de acceso En esta sección se listarán las pruebas realizadas, con la finalidad de demostrar el correcto funcionamiento de la configuración del cortafuegos iptables, que se ha realizado con el script visto en la sección anterior. Las pruebas realizadas se enumeran a continuación según el orden establecido en el guión de la práctica; determinadas configuraciones no será posible probarlas, ya que no se dispone de las herramientas apropiadas para ello, o bien su manejo es complejo. Ip-Spoofing Para realizar una prueba de Ip-Spoofing no basta tomar una máquina externa a la red y cambiar su configuración de red. De hecho, si se hace eso no tendría conectividad porque la máscara de red no sería la apropiada o bien la Ip o Pasarela estaría mal configurada. Para poder hacer Ip-Spoofing habría que modificar los paquetes enviados intentando modificar el campo que indica la IP de origen o fuente. Para ello se requeriría una herramienta que lo permitiera, de la cual no se dispone. Por este motivo, no es posible realizar una prueba para observar como el cortafuegos evita el Ip-Spoofing. ICMP Para probar la intervención del cortafuego frente a los paquetes del protocolo ICMP, se hará uso de la herramienta ping, que usa este protocolo para las interrogaciones (echo-request) a otras máquinas y las respuestas (echo-reply) de dichas máquinas. En primer lugar comprobamos que desde la máquina , que es donde se dispone del firewall instalado, se puede hacer ping a cualquier máquina. Los tres posibles casos son: 22

24 1. Máquinas de la red interna ( ) Hacemos la prueba con el equipo PC, de nuestra red interna (también podría hacer con la interfaz de la red interna de la propia máquina), y vermos que se permite. [root@pasarela12 Desktop]# ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=0 ttl=64 time=0.887 ms 64 bytes from : icmp_seq=1 ttl=64 time=0.116 ms ping statistics packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.116/0.501/0.887/0.386 ms, pipe 2 2. Máquinas de la red externa ( ) Del mismo modo, se permite perfectamente. La prueba se ha realizado sobre la máquina [root@pasarela12 Desktop]# ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=0 ttl=64 time=0.180 ms 64 bytes from : icmp_seq=1 ttl=64 time=0.144 ms ping statistics packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.144/0.162/0.180/0.018 ms, pipe 2 3. Máquinas externas (Internet) Con redes externas, en Internet, tampoco hay problema (siempre que no haya otro firewall que lo impida para sus máquinas). En este caso la prueba se hace con [root@pasarela12 Desktop]# ping 23

25 PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=0 ttl=237 time=83.6 ms 64 bytes from : icmp_seq=1 ttl=237 time=84.0 ms ping statistics packets transmitted, 2 received, 33% packet loss, time 2001ms rtt min/avg/max/mdev = /83.866/84.054/0.188 ms, pipe 2 Este comportamiento es normal, pues la máquina del firewall no restringe la posibilidad de hacer ping hacia cualquier destino, sino que las restricciones son en sentido de entrada. A continuación se prueba como los pings que se hacen a la propia máquina (la que tiene el firewall configurado) desde equipos de su red ( ), que se admitirán. Además, también se admite la realización de ping desde la interfaz externa de la propia máquina, que está en la red El ping desde la red interna se hace desde la interfaz de la red interna de la propia máquina ( ). [root@pasarela12 ~]# ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=0 ttl=64 time=0.143 ms 64 bytes from : icmp_seq=1 ttl=64 time=0.130 ms ping statistics packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.130/0.136/0.143/0.013 ms, pipe 2 El ping desde el interfaz de la red externa ( ) también funciona: [root@pasarela12 ~]# ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=0 ttl=64 time=0.153 ms 24

26 64 bytes from : icmp_seq=1 ttl=64 time=0.143 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.149 ms ping statistics packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.143/0.148/0.153/0.010 ms, pipe 2 Finalmente, si probamos la realización de un ping desde una máquina externa (en realidad una máquina del Laboratorio, dentro de la red ), veremos como puede hacer el ping a la interfaz externa ( ) de la máquina con el firewall, pero no así como Ips de la red interna ( ), ni siquiera de la máquina con el firewall ( ). En la siguiente captura de pantalla puede observarse el funcionamiento del ping al realizarlo sobre la interfaz y como se rechaza si se hace sobre las interfaces de la red interna (como la , en este caso), respectivamente. 25

27 Esto es indicativo de un correcto funcionamiento del firewall. Telnet Para probar la conexiones con telnet, cuyo puerto según el estándar es el 23, se requiere de una aplicación que escuche por dicho puerto para que se establezcan las conexiones. Como no se dispone de ninguna aplicación para ello, la forma en que se hará la prueba consistirá en ver la diferencia en el proceso en función de si el firewall está o no activado. Sin firewall se tiene lo siguiente: [root@pasarela12 Desktop]# telnet Trying telnet: connect to address : Connection refused telnet: Unable to connect to remote host: Connection refused 26