Trabajo - DavidHorat.com

Práctica 5:
Puesta en marcha de un
cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David Jesús Horat Flotats
Enrique Fernández Perdomo
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
Índice
Introducción a los cortafuegos o firewall........................................................... 2
Introducción a iptables....................................................................................... 8
Parámetros de iptables..................................................................................... 10
SINOPSIS...................................................................................................... 10
OBJETIVOS....................................................................................................11
TABLAS......................................................................................................... 11
PARÁMETROS...............................................................................................11
EXTENSIONES..............................................................................................12
icmp........................................................................................................... 12
state...........................................................................................................12
tcp..............................................................................................................13
Ejemplo de una política concreta..................................................................... 14
Objetivos........................................................................................................14
Configuración................................................................................................14
Ejemplos de acceso...........................................................................................22
Ip-Spoofing.................................................................................................... 22
ICMP..............................................................................................................22
Telnet............................................................................................................ 26
FTP................................................................................................................ 27
POP3..............................................................................................................28
HTTP............................................................................................................. 30
SMTP.............................................................................................................33
DNS............................................................................................................... 36
1
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
Introducción a los cortafuegos o firewall1
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 http://www.pello.info/filez/firewall/iptables.html
2
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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 1024.
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
Introducción a iptables2
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 http://www.pello.info/filez/firewall/iptables.html
8
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
-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
Esta extensión se carga al indicar -p icmp. Proporciona la siguiente
opción:
--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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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: 65535. Se suele usar
el alias --sport.
--destination-port [!] puerto[:puerto]
Puerto o rango de puertos de destino. Se suele usar el alias --dport.
13
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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” (193.145.133.12)
–
SMTP: Solo hacia afuera con la máquina 172.16.1.1 que actúa como
relaying de correo
–
DNS: Ambos sentidos pero solo con la máquina 172.16.1.1 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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
# Variables
INTERNET=eth0
LOCAL=eth1
REDLOCAL=172.16.6.0/24
YO=172.16.1.6
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 IPSpoofing"
# [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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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 172.16.1.1 que
actuará de forwarder
# [5.1] Dejar salir hacia 172.16.1.1, desde red interna y la propia máquina
iptables -A FORWARD -i $LOCAL -d 172.16.1.1 -p udp --dport 53 -j ACCEPT && echo
"Aceptamos DNS hacia afuera"
iptables -A OUTPUT -d 172.16.1.1 -p udp --dport 53 -j ACCEPT && echo "Aceptamos DNS
17
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
hacia "
# [5.2] Dejar entrar paquetes desde 172.16.1.1, hacia la red interna y la
propia máquina
iptables -A FORWARD -i $INTERNET -s 172.16.1.1 -p udp --sport 53 -j ACCEPT && echo
"Aceptamos DNS de vuelta"
iptables -A INPUT -s 172.16.1.1 -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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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" (193.146.95.50)
# [7.1] Dejar salir hacia el proxy 193.146.95.50, desde red interna y la propia
máquina
iptables -A FORWARD -i $LOCAL -d 193.146.95.50 -p tcp --dport 3128 -j ACCEPT && echo
"Aceptamos HTTP hacia afuera a proxy.ulpgc.es (193.145.133.12)"
iptables -A OUTPUT -d 193.146.95.50 -p tcp --dport 3128 -j ACCEPT && echo "Aceptamos
HTTP de vuelta de proxy.ulpgc.es (193.145.133.12)"
# [7.2] Dejar entrar paquetes de las conexiones establecidas, hacia la red
interna y la propia máquina
iptables -A FORWARD -i $INTERNET -s 193.146.95.50 -p tcp -m tcp --sport 3128 -m state -state 'RELATED' --state 'ESTABLISHED' -j ACCEPT && echo "Aceptamos POP3 a traves
hacia las máquinas internas"
iptables -A INPUT -s 193.146.95.50 -p tcp -m tcp --sport 3128 -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 172.16.1.24
(neptuno.redes.dis.ulpgc.es) que actúa como relaying de correo
# [8.1] Dejar salir hacia 172.16.1.24, desde red interna y la propia máquina
iptables -A FORWARD -i $LOCAL -d 172.16.1.24 -p tcp --dport 25 -j ACCEPT && echo
"Aceptamos SMTP hacia afuera a 172.16.1.24"
iptables -A OUTPUT -d 172.16.1.24 -p tcp --dport 25 -j ACCEPT && echo "Aceptamos SMTP
hacia afuera a 172.16.1.24"
# [8.2] Dejar entrar paquetes de las conexiones establecidas con 172.16.1.24,
hacia la red interna y la propia máquina
iptables -A FORWARD -i $INTERNET -s 172.16.1.24 -p tcp -m tcp --sport 25 -m state --state
19
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
'ESTABLISHED' --state 'RELATED' -j ACCEPT && echo "Aceptamos SMTP de vuelta de
172.16.1.24"
iptables -A INPUT -s 172.16.1.24 -p tcp -m tcp --sport 25 -m state --state 'ESTABLISHED' -state 'RELATED' -j ACCEPT && echo "Aceptamos SMTP de vuelta de 172.16.1.24"
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
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
21
David J. Horat Flotats
Enrique Fernández Perdomo
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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 172.16.6.1, que es
donde se dispone del firewall instalado, se puede hacer ping a cualquier
máquina. Los tres posibles casos son:
22
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
1. Máquinas de la red interna (172.16.6.0)
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 172.16.6.2
PING 172.16.6.2 (172.16.6.2) 56(84) bytes of data.
64 bytes from 172.16.6.2: icmp_seq=0 ttl=64 time=0.887 ms
64 bytes from 172.16.6.2: icmp_seq=1 ttl=64 time=0.116 ms
--- 172.16.6.2 ping statistics --2 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 (172.16.1.0)
Del mismo modo, se permite perfectamente. La prueba se ha realizado
sobre la máquina 172.16.1.1.
[root@pasarela12 Desktop]# ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=0.180 ms
64 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=0.144 ms
--- 172.16.1.1 ping statistics --2 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 www.google.com.
[root@pasarela12 Desktop]# ping www.google.com
23
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
PING www.l.google.com (66.102.9.147) 56(84) bytes of data.
64 bytes from 66.102.9.147: icmp_seq=0 ttl=237 time=83.6 ms
64 bytes from 66.102.9.147: icmp_seq=1 ttl=237 time=84.0 ms
--- www.l.google.com ping statistics --3 packets transmitted, 2 received, 33% packet loss, time 2001ms
rtt min/avg/max/mdev = 83.678/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
(172.16.6.0), 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
172.16.1.0.
El ping desde la red interna se hace desde la interfaz de la red interna de
la propia máquina (172.16.6.1).
[root@pasarela12 ~]# ping 172.16.6.1
PING 172.16.6.1 (172.16.6.1) 56(84) bytes of data.
64 bytes from 172.16.6.1: icmp_seq=0 ttl=64 time=0.143 ms
64 bytes from 172.16.6.1: icmp_seq=1 ttl=64 time=0.130 ms
--- 172.16.6.1 ping statistics --2 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 (172.16.1.6) también funciona:
[root@pasarela12 ~]# ping 172.16.1.6
PING 172.16.1.6 (172.16.1.6) 56(84) bytes of data.
64 bytes from 172.16.1.6: icmp_seq=0 ttl=64 time=0.153 ms
24
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
64 bytes from 172.16.1.6: icmp_seq=1 ttl=64 time=0.143 ms
64 bytes from 172.16.1.6: icmp_seq=2 ttl=64 time=0.149 ms
--- 172.16.1.6 ping statistics --3 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
172.16.1.0), veremos como puede hacer el ping a la interfaz externa
(172.16.1.6) de la máquina con el firewall, pero no así como Ips de la red
interna (172.16.6.0), ni siquiera de la máquina con el firewall (172.16.6.1). En
la siguiente captura de pantalla puede observarse el funcionamiento del ping
al realizarlo sobre la interfaz 172.16.1.6 y como se rechaza si se hace sobre
las interfaces de la red interna 172.16.6.0 (como la 172.16.61, en este caso),
respectivamente.
25
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
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 172.16.6.1 23
Trying 172.16.6.1...
telnet: connect to address 172.16.6.1: Connection refused
telnet: Unable to connect to remote host: Connection refused
26
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
El error en la conexión se debe a que no se establece la conexión porque
no hay ninguna aplicación a la escucha por el puerto 23, para telnet.
Con firewall, por contra, se tiene lo siguiente:
[root@pasarela12 Desktop]# telnet 172.16.6.1 23
Trying 172.16.6.1...
Esto es indicativo de que cuando el firewall actúa, la conexión no se
permite con el puerto 23, que es el de telnet. Por este motivo el cliente telnet
se queda bloqueado como si aparentemente no hiciera nada. Esto demuestra
que el firewall está funcionando.
FTP
Las conexiones FTP sólo se harán hacia fuera, es decir, la máquina con el
firewall no funcionará de servidor FTP. Si se hace conexión FTP con ella se
rechazará (en realidad el cliente FTP se suele quedar bloqueado
aparentemente sin hacer nada). Si se hace una conexión FTP desde la propia
máquina o desde un equipo de la red interna a la propia máquina (en concreto
la IP 172.16.6.1), no se acepta la conexión.
[root@pasarela12 ~]# ftp 172.16.6.1
[root@pasarela12 ~]#
Sin embargo, si nos conectamos al FTP de la máquina 172.16.1.1 la
conexión sí se hará efectiva. Tanto desde la propia máquina:
[root@pasarela12 Desktop]# ftp 172.16.1.1
Connected to 172.16.1.1.
220---------- Bienvenido a Pure-FTPd ---------220-Eres el usuario numero 2 de 50 permitidos
220-La hora local es ahora 18:55. Puerto del servidor: 21.
220-Las conexiones IPv6 tambien son bienvenidas en este servidor
220 Seras desconectado despues de 15 minutos de inactividad.
500 Extensiones de seguridad no implementadas
27
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
500 Extensiones de seguridad no implementadas
KERBEROS_V4 rejected as an authentication type
...
Como desde una máquina de la red interna:
[root@pasarela12 ~]# ftp 172.16.1.1
Connected to 172.16.1.1.
220---------- Bienvenido a Pure-FTPd ---------220-Eres el usuario numero 1 de 50 permitidos
220-La hora local es ahora 18:55. Puerto del servidor: 21.
220-Las conexiones IPv6 tambien son bienvenidas en este servidor
220 Seras desconectado despues de 15 minutos de inactividad.
500 Extensiones de seguridad no implementadas
500 Extensiones de seguridad no implementadas
KERBEROS_V4 rejected as an authentication type
Name (172.16.1.1:root): anonymous
230-Bienvenido al FTP anonimo del Grupo Docente de Redes.
230230-Toda la actividad que aqui se realiza queda grabada.
230-Si no le gusta dicha politica por favor abandone el
230-sitio.
230230-Gracias.
230 Usuario Anonimo dentro del sistema
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quit
221-Adios. Has transmitido 0 y descargado 0 kbytes.
221 Fin de sesion.
POP3
Para probar la conexiones a servidores POP3 se requiere de una
28
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
aplicación que será el servidor POP3, en la propia máquina, que tiene el
firewall. En realidad no se dispone de ningún servidor POP3. Como sólo debe
permitirse las conexiones POP3 hacia fuera, la forma de probarlo será ver que
ocurre sin firewall y con firewall al intentar conexiones POP3 con la propia
máquina.
Sin firewall se tiene lo siguiente:
[root@pasarela12 Desktop]# telnet 172.16.6.1 110
Trying 172.16.6.1...
telnet: connect to address 172.16.6.1: Connection refused
telnet: Unable to connect to remote host: Connection refused
El error en la conexión se debe a que no se establece la conexión porque
no hay ninguna aplicación a la escucha por el puerto 110, para POP3.
Con firewall, por contra, se tiene lo siguiente:
[root@pasarela12 Desktop]# telnet 172.16.6.1 110
Trying 172.16.6.1...
Esto es indicativo de que cuando el firewall actúa, la conexión no se
permite con el puerto 110, que es el de POP3. Por este motivo el cliente telnet
se queda bloqueado como si aparentemente no hiciera nada. Esto demuestra
que el firewall está funcionando.
Si la conexión POP3 se hace hacia fuera, es decir, con un servidor POP3
externo, como pop.correo.yahoo.es, la conexión se realizará con éxito, como
en el siguiente caso.
[root@pasarela12 Desktop]# telnet pop.correo.yahoo.es 110
Trying 216.136.173.10...
Connected to pop.correo.yahoo.es (216.136.173.10).
Escape character is '^]'.
+OK hello from popgate(2.31.0)
user enrique
29
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
+OK password required.
pass ******
+OK maildrop ready, 50 messages (10987352 octets) (13400180 207341824)
Adicionalmente, para conexión de acceso telefónico a redes (PPP) sí se
permitirán las conexions POP3 en ambos sentidos. La conexión con servidores
POP3 externos como pop.correo.yahoo.es seguirá funcionando.
[root@pasarela12 Desktop]# telnet pop.correo.yahoo.es 110 Trying
216.136.173.10...
Connected to pop.correo.yahoo.es (216.136.173.10).
Escape character is '^]'.
quit
+OK hello from popgate(2.31.0)
Connection closed by foreign host.
Sin embargo, para comprobar el funcionamiento con un servidor interno
se requerirá de un servidor POP3, del cual no se dispone en la máquina en que
está el firewall. Por este motivo no es posible la realización de una prueba
representativa para este caso.
HTTP
Para las conexiones HTTP sólo se permitirán hacia fuera a través del
proxy proxy.rcanaria.es, ya que el proxy proxy.ulpgc.es no existe. La Ip de
proxy.rcanaria.es es la 193.146.95.50.
Para la realización de las pruebas se usará el navegador Firefox en el
cual se obligará al uso del proxy, indicándolo en las configuraciones de
conexión, accesibles desde las Preferencias. La configuración para que se use
el proxy será la de la Ilustración 1, en la que se indica la Ip del proxy
proxy.rcanaria.es (193.146.95.50) y su puerto, que es el 3128.
30
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
Illustración 1: Configuración del proxy: proxy.rcanaria.es
(193.146.95.50:3128)
Para las capturas se usará tcpdump para ver el tráfico de la red, según
la prueba que se realice.
En primer lugar se usa el navegador sin usar el proxy, de forma que el
firewall no le permitirá el acceso, pues no usa el proxy, como se observa en la
siguiente captura del tcpdump.
[root@pasarela12 Desktop]# tcpdump -i eth1 src 172.16.1.6 or dst 172.16.1.6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:28:09.785848 IP pasarela6.redes.dis.ulpgc.es.32790 >
pasarela1.redes.dis.ulpgc.es.53: 8001+ AAAA? www.google.com. (33)
31
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
15:28:09.786526 IP pasarela6.redes.dis.ulpgc.es.32791 >
pasarela1.redes.dis.ulpgc.es.53: 5478+ PTR? 6.1.16.172.in-addr.arpa. (41)
15:28:14.784367 arp who-has pasarela1.redes.dis.ulpgc.es tell
pasarela6.redes.dis.ulpgc.es
15:28:14.799454 IP pasarela6.redes.dis.ulpgc.es.32790 >
pasarela1.redes.dis.ulpgc.es.53: 8001+ AAAA? www.google.com. (33)
15:28:19.140179 IP pasarela6.redes.dis.ulpgc.es.32791 >
pasarela1.redes.dis.ulpgc.es.53: 27503+ A? www.google.com. (33)
Se ha intentado acceder a www.google.es y se observa que sólo se
realizan proceso de resolución de nombres con el DNS de la máquina
172.16.1.1 (que tiene el nombre pasarela1.redes.dis.ulpgc.es en nuestra
máquina). El proceso de obtención de la página por conexión y uso del
protocolo HTTP no se lleva a cabo porque el firewall sólo lo permite a través
del proxy antes indicado.
Si ahora activamos el uso del firewall como se indicó en la Ilustración 1,
al realizar el acceso a www.google.es sí funcionará.
[root@pasarela12 Desktop]# tcpdump -i eth1 src 172.16.1.6 or dst 172.16.1.6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:35:21.181762 IP pasarela6.redes.dis.ulpgc.es.32899 >
193.146.95.50.3128: S 3121570739:3121570739(0) win 5840 <mss
1460,sackOK,timestamp 6936619 0,nop,wscale 2>
15:35:21.187245 IP pasarela6.redes.dis.ulpgc.es.32791 >
pasarela1.redes.dis.ulpgc.es.53: 13318+ PTR? 50.95.146.193.in-addr.arpa.
(44)
15:35:21.187507 IP pasarela1.redes.dis.ulpgc.es.53 >
pasarela6.redes.dis.ulpgc.es.32791: 13318 NXDomain 0/1/0 (131)
15:35:21.191814 IP pasarela6.redes.dis.ulpgc.es.32791 >
pasarela1.redes.dis.ulpgc.es.53: 64099+ PTR? 2.1.16.172.in-addr.arpa. (41)
15:35:21.192002 IP pasarela1.redes.dis.ulpgc.es.53 >
32
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
pasarela6.redes.dis.ulpgc.es.32791: 64099* 1/1/0 PTR[|domain]
15:35:21.248494 IP 193.146.95.50.3128 >
pasarela6.redes.dis.ulpgc.es.32899: S 683207663:683207663(0) ack
3121570740 win 5792 <mss 1460,sackOK,timestamp 96157260
6936619,nop,wscale 0>
15:35:21.248553 IP pasarela6.redes.dis.ulpgc.es.32899 >
193.146.95.50.3128: . ack 1 win 1460 <nop,nop,timestamp 6936686
96157260>
15:35:21.250414 IP pasarela6.redes.dis.ulpgc.es.32899 >
193.146.95.50.3128: P 1:412(411) ack 1 win 1460 <nop,nop,timestamp
6936687 96157260>
15:35:21.318387 IP 193.146.95.50.3128 >
pasarela6.redes.dis.ulpgc.es.32899: . ack 412 win 6432 <nop,nop,timestamp
96157268 6936687>
15:35:21.406243 IP 193.146.95.50.3128 >
pasarela6.redes.dis.ulpgc.es.32899: . 1449:2897(1448) ack 412 win 6432
<nop,nop,timestamp 96157276 6936687>
Se observa como se realiza el intercambio de datos entre la propia
máquina (pasarela6.redes.dis.ulpgc.es) y el proxy proxy.rcanaria.es que
se ve como la IP 193.146.95.50, y más concretamente junto con su puerto, que
es el de proxy: 3128, teniendo 193.146.95.50.3128.
SMTP
Se trata de que sólo puedan hacerse conexiones SMTP hacia fuera a
través de la máquina 172.16.1.24 (neptuno.redes.dis.ulpgc.es), que difiere
de la indicada en el guión de la práctica (172.16.1.1), porque dicha máquina
no actúa como relay de correo.
Si realizamos una conexión SMTP a la máquina 172.16.1.24 sin haber
realizado la activación del firewall, la conexión se consigue y además se recibe
el correo en nuestra máquina, lo cual podemos ver con mail -u enrique,
como se ve a continuación.
33
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
[root@pasarela12 sysconfig]# telnet 172.16.1.24 25
Trying 172.16.1.24...
Connected to 172.16.1.24 (172.16.1.24).
Escape character is '^]'.
220 neptuno.redes.dis.ulpgc.es ESMTP Postfix
ehlo david
250-neptuno.redes.dis.ulpgc.es
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250 8BITMIME
mail from: davidj
250 Ok
rcpt to:webmaster@pasarela6.red6.redes.dis.ulpgc.es
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
hola
.
250 Ok: queued as 679F0178976
quit
221 Bye
Connection closed by foreign host.
[root@pasarela12 sysconfig]# mail -u enrique
Mail version 8.1 6/6/93. Type ? for help.
"/var/mail/enrique": 1 message 1 new
>N 1 davidj@redes.dis.ul Fri May 20 14:55 17/843
Además, si en lugar de usar el servidor SMTP de la máquina 172.16.1.24,
usamos nuestro servidor SMTP (de la máquina 172.16.6.1 ó 172.16.1.6),
también funcionará correctamente.
34
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
Si tenemos el firewall activado, ya no podremos conectarnos al servidor
SMTP de nuestra máquina, pues el firewall sólo deja hacerlo con la máquina
172.16.1.24. El resultado será el siguiente, similar al caso anterior.
[root@pasarela12 sysconfig]# telnet 172.16.1.24 25
Trying 172.16.1.24...
Connected to 172.16.1.24 (172.16.1.24).
Escape character is '^]'.
220 neptuno.redes.dis.ulpgc.es ESMTP Postfix
ehlo david
250-neptuno.redes.dis.ulpgc.es
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250 8BITMIME
mail from: davidj
250 Ok
rcpt to:webmaster@pasarela6.red6.redes.dis.ulpgc.es
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
hola
.
250 Ok: queued as 2C637178976
quit
221 Bye
Connection closed by foreign host.
[root@pasarela12 sysconfig]# mail -u enrique
No mail for enrique
La única diferencia radica en que en este caso el correo no es recibido en
nuestra máquina. Esto se debe a que el firewall no permite la entrada.
35
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
DNS
Sólo se permitirá que se use el servidor DNS 172.16.1.1, de modo que si
el servidor DNS de la propia máquina (172.16.6.1) está en marcha, no deberá
permitirse el uso del mismo.
Para probar esto, en primer lugar se hace que el servidor DNS que se
esté usando sea el 172.16.6.1:
[root@pasarela12 etc]# nslookup
> server
Default server: 172.16.6.1
Address: 172.16.6.1#53
A continuación probamos la resolución de nombres haciendo simplemente
un ping a un nombre de dominio, como www.google.es, en nuestro caso. En
primer lugar probamos la resolución sin haber activado las reglas del firewall,
es decir, sin tener el firewall activo, de modo que se hará la resolución.
[root@pasarela12 Desktop]# ping www.google.es
PING www.l.google.com (66.102.9.99) 56(84) bytes of data.
64 bytes from 66.102.9.99: icmp_seq=0 ttl=237 time=84.5 ms
--- www.l.google.com ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 84.593/84.593/84.593/0.000 ms, pipe 2
A continuación, se activa el firewall. Ahora la resolución no es posible,
pues la regla impide que se use el servidor DNS 172.16.6.1, pues sólo se
permite el 172.16.1.1.
[root@pasarela12 Desktop]# ping www.google.es
ping: unknown host www.google.es
Además, podemos comprobar que es un simple problema de resolución,
porque se hacemos ping a la IP de www.google.es, conocida de antes
(66.102.9.99), se verá que tenemos conectividad.
36
Práctica 5: Puesta en marcha de un cortafuegos con IPTABLES
Arquitectura de Sistemas y Aplicaciones Distribuidas – U.L.P.G.C.
David J. Horat Flotats
Enrique Fernández Perdomo
[root@pasarela12 Desktop]# ping 66.102.9.99
PING 66.102.9.99 (66.102.9.99) 56(84) bytes of data.
64 bytes from 66.102.9.99: icmp_seq=0 ttl=237 time=83.8 ms
--- 66.102.9.99 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 83.864/83.864/83.864/0.000 ms, pipe 2
Dejando el firewall activado, cambiamos el servidor DNS que se usará
para las resoluciones, poniendo el 172.16.1.1, que es el único que admitirá el
firewall.
[root@pasarela12 etc]# nslookup
> server
Default server: 172.16.1.1
Address: 172.16.1.1#53
Ahora la resolución de nombres sí funciona:
[root@pasarela12 etc]# ping www.google.com
PING www.l.google.com (66.102.9.147) 56(84) bytes of data.
64 bytes from 66.102.9.147: icmp_seq=0 ttl=237 time=84.8 ms
64 bytes from 66.102.9.147: icmp_seq=1 ttl=237 time=83.7 ms
64 bytes from 66.102.9.147: icmp_seq=2 ttl=237 time=83.2 ms
--- www.l.google.com ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 83.237/83.960/84.866/0.677 ms, pipe 2
37