IPTables-Shorewall MemoriaSDC PDF

Software de Comunicaciones
Práctica 9 - Filtrado de Paquetes.

IPTables y Shorewall
Juan Díez-Yanguas Barber
Software de Comunicaciones
Ingeniería Informática - 5º Curso
______________________________________________________________________________________
© Jdyb - Mayo 2013
Juan Díez- Yanguas Barber! Práctica 9
______________________________________________________________________________________
Índice
1. Introducción! 4
2. Cortafuegos personal! 5
2.1. Estado inicial de IPTables! 5
2.2. Establecimiento de reglas de filtrado sin estado! 7
2.2.1. Establecimiento de la política por defecto! 7
2.2.2. Establecimiento de reglas! 8
2.2.3. Comprobación de la importancia del orden de las reglas! 13
2.3. Redirección de tráfico! 15
2.4. Usar IPTables para protegerse de una enumeración con NMap! 17
2.5. Filtros con estado para ICMP! 19
3. Router con función de cortafuegos y NAT! 22

3.1. Construcción del escenario! 22
3.2. Configuración del escenario! 30
3.3. Instalación de Shorewall! 32
3.4. Configuración de Shorewall! 33
3.4.1. Configuración de zonas! 34
3.4.2. Configuración de políticas! 34
3.4.3. Configuración de reglas! 34
3.4.4. Configuración de las interfaces! 35
3.4.5. Configuración de enmascaramiento! 35
3.5. Configuración de políticas básicas! 36
3.5.1. Configuración previa del escenario! 36
3.5.2. Configuración de las políticas en Shorewall! 37
3.5.3. Enmascaramiento de direcciones! 39

______________________________________________________________________________________
© Jdyb - Mayo 2013! 2
!
______________________________________________________________________________________
3.5.4. Configuración de reglas para las conexiones salientes! 42
4. Apartados opcionales! 53
4.1. Securizar servidor SSH contra ataques de fuerza bruta! 53
4.2. Control y limitación del ancho de banda! 56
______________________________________________________________________________________
© Jdyb - Mayo 2013! 3
!
______________________________________________________________________________________
1. Introducción
! En esta práctica se va a tratar el manejo de net filter, llamado ahora IPTables. Es
un módulo incluido dentro de núcleo del sistema operativo. Esto implica que no vamos a
tener que instalarlo ni activarlo.
! No se tiene que activar porque ya viene activo por defecto pero hace el efecto de
no estar activo porque sus tablas de filtrado están todas ellas vacías por defecto y política
que llevan por defecto es ACCEPT.
! El sistema de filtrado se compone de una serie de tablas en diferentes etapas, y en

cada una de ellas es posible aplicar reglas de diferente tipo, a saber entre reglas de
filtrado, reglas de NAT o reglas de manipulación de paquetes.
! A continuación indicamos mediante un esquema las diferentes reglas que son

aplicables en cada una de las etapas.
Sistema de Filtrado Manipulación

(Mangle)
Filtrado
Entrega
PREROUTING NO FORDWARD
local
SI SNAT
DNAT Manipulación
(Mangle)
Manipulación
POSTROUTING
(Mangle)
INPUT DNAT
Manipulación
(Mangle)
Manipulación
(Mangle) Filtrado
Filtrado OUTPUT
Procesado local
! Durante el desarrollo de la práctica se hará referencia a cada una de las etapas y

tablas que se han visto representadas en la figura. Se tratarán dos escenarios, el primero
de ellos será la configuración de un cortafuegos personal y el segundo de ellos tratará de
poner en marcha una máquina con la función de reenvío habilitada de manera que actué
como un router dentro de la red con función de NAT y cortafuegos.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 4
!
______________________________________________________________________________________
2. Cortafuegos personal
! En este apartado trataremos el primer escenario comentado anteriormente en el
cual usaremos IPTables como filtro de control para lo que entre o salga de nuestro equipo
local.
2.1. Estado inicial de IPTables

! Lo primero que vamos a hacer es comprobar el estado de las interfaces de nuestro
equipo que veremos que cuenta con una interfaz virtual, la interfaz física y la interfaz de
loopback. Es la misma configuración que hemos usado en anteriores ocasiones.
! Ahora comprobaremos el estado de IPTables, que veremos que tiene todas las
tablas de las cadenas de reglas vacías y con política por defecto ACCEPT que es como
se encuentra por defecto. Para visualizar el contenido de las tablas lo haremos con el
siguiente comando.
Si no se especifica tabla la que se muestra por defecto es la de filtrado y si no se

especifica la cadena mostrará todas aquellas en las que este presente la tabla. Por
ejemplo, si es la tabla de filtrado mostrará OUTPUT, INPUT y FORWARD.
iptables -‐L(opción listar) -‐n(mostrar números de puerto e IPs en

vez de dominios o protocolos)
______________________________________________________________________________________
© Jdyb - Mayo 2013! 5
!
______________________________________________________________________________________
! Mostraremos ahora las reglas de las tablas de NAT para todas las cadenas en las
que este presente y veremos que de nuevo no hay regla alguna. Fijándonos en el
diagrama de la introducción vemos que las tablas de NAT se encuentran en la cadena de
PREROUTING, POSTROUTING y OUTPUT.
! Finalmente mostramos las reglas de las tablas de manipulación o mangle, esta vez
la tabla estará presente en todas las cadenas de reglas. De nuevo no habrá reglas por
defecto y la política por defecto será ACCEPT.
! Tal como se indicó no ha sido necesaria instalación ni activación de nada al ser un

módulo del propio núcleo del sistema, solo que al no tener reglas y tener la política
ACCEPT por defecto no afecta al funcionamiento del sistema en lo que a conexiones se
refiere.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 6
!
______________________________________________________________________________________
2.2. Establecimiento de reglas de filtrado sin estado

! En el enunciado se nos indica que vamos a proceder al establecimiento de reglas
sin estado en las cadenas de INPUT y OUTPUT. Lo primero que se hará es fijar la política
y posteriormente se fijarán las reglas que se nos indican.
2.2.1. Establecimiento de la política por defecto

! Estableceremos en este apartado las políticas por defecto de DROP para las
cadenas OUTPUT y INPUT. Esto lo debemos de hacer sobre las tablas de filtrado que son
sobre las que estamos trabajando, ya que son las tablas por defecto podremos indicar la
tabla en el comando o no hacerlo ya que como se indicó se toma por defecto la tabla de
filtrado.
iptables -‐P (política) OUTPUT (cadena) DROP
! Hay que tener cuidado en la aplicación de las reglas en un entorno de producción,

por ejemplo, al haber aplicado esta política sin tener ninguna regla de exclusión
estábamos conectados por ssh a la máquina y lógicamente la conexión se perdió en el
momento de aplicar la regla.
! Mostramos ahora el resultado de las reglas con los comandos de listado que vimos
anteriormente. Sigue sin haber reglas pero ahora la política por defecto en la tabla de
filtrado para las cadenas de OUTPUT e INPUT son de DROP.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 7
!
______________________________________________________________________________________
! La situación actual se diría que es una situación de bloqueo total en lo que se

refiere a conexiones de la máquina. Por ejemplo levantamos el servidor http y el servidor
DNS e intentamos conectarnos desde la máquina anfitriona.
2.2.2. Establecimiento de reglas

! En el enunciado se nos indica que habilitemos el intercambio de tráfico ICMP para
los equipos de la red local. Esto requerirá la habilitación en dirección entrante y saliente,
ya que se requerirá que nuestra máquina responda a las peticiones y que también le
puedan llegar o enviar ella misma. Y solo se debe habilitar para dentro de la propia
subred.
iptables -‐t filter -‐A (añadir) OUTPUT -‐p (protocolo) icmp -‐d
(destino) 172.16.183.0/24 -‐j ACCEPT
! Antes de aplicar las reglas veremos el efecto que se produce, la máquina no puede
hacer ping ni recibir ping de otra máquina.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 8
!
______________________________________________________________________________________
! Aplicamos a continuación las reglas siguiendo la sintaxis indicada anteriormente.

La sintaxis debe ser estricta tal como se ha indicado en mayúsculas y minúsculas.
! Si se intenta ahora el ping se quedará parado porque podrá enviar pero no recibir
las respuestas.
! Aplicaremos ahora la regla pero en sentido entrante.
! A continuación comprobamos que ahora si se puede enviar pings a otra máquina

de la misma subred y que responde a los ping enviados desde una máquina de la misma
subred.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 9
!
______________________________________________________________________________________
! Sin embargo comprobamos que no se pueden enviar pings a otra máquina que no
esté en la subred.
! A continuación el enunciado también nos indica que habilitemos el tráfico saliente

hacia el puerto 80 TCP. Hay que tener en cuenta que aunque apliquemos la regla el
tráfico web no funcionará porque no está habilitado el tráfico del DNS ni tampoco está
habilitado el tráfico entrante en otros puertos, de manera que podrá enviar la petición pero
la respuesta normalmente se recibe en otros puertos no privilegiados que no son el 80.
! Si se quiere que el tráfico web funcione habrá que habilitar una regla análoga en
sentido entrante que permita el tráfico TCP originado en el puerto 80.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 10
!
______________________________________________________________________________________
! Probamos a continuación a lanzar una petición a google pero por la dirección IP y

no por el dominio.
! Si lo hacemos por el nombre de dominio no podrá resolverlo porque no se ha

habilitado el tráfico saliente DNS ni tampoco entrante.
! Vamos a habilitar ahora el tráfico DNS para comprobar que funcione

correctamente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 11
!
______________________________________________________________________________________
! Si queremos que desde la máquina local se pueda acceder al servidor web de la

máquina virtual con esta configuración no debería ser posible ya que no se ha habilitado
el tráfico entrante que tenga como destino el puerto 80 TCP ni el puerto 53 UDP para el
DNS.
! Finalmente en el enunciado se nos pide que se permitan conexiones entrantes

hacia el puerto 22 que es el puerto de SSH.
! Con esta regla pasará lo mismo que en anteriores ocasiones, no se deja salir el
tráfico con origen en el puerto 22 por lo que no podrá establecerse una conexión ssh
hacia la máquina.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 12
!
______________________________________________________________________________________
! Para que funcione ejecutaremos la siguiente regla.
! Y comprobamos que la conexión desde el cliente se establece correctamente.
! Se muestra finalmente el resultado de todas las reglas aplicadas en este apartado.
2.2.3. Comprobación de la importancia del orden de las reglas

! Se nos pide que partamos de una configuración sin filtrado, para ello borraremos la
tabla de filtrado y fijaremos las políticas por defecto en ACCEPT.
! La opción -F se indica para borrar por completo la cadena de reglas, no se ha

indicado en los comandos la tabla porque la tabla de filtrado es la que se toma por defecto
como se ha indicando en ocasiones anteriores.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 13
!
______________________________________________________________________________________
! No hemos hablado anteriormente del orden de las reglas porque no era necesario,
eran todas las reglas de diferentes protocolos. Las reglas son evaluadas en orden, por lo
que si se ponen primero las más restrictivas no se conseguirá el efecto deseado.
! Veamos un ejemplo. Queremos bloquear todo el tráfico saliente TCP salvo el

dirigido a una dirección concreta de nuestra subred. Nos quedamos como era lógico de
nuevo sin la conexión ssh.
! Con esta última regla se habilita el tráfico saliente TCP hacia la máquina anfitriona.
Pero veremos que la realidad es otra, no vamos a poder establecer una conexión SSH
desde la máquina anfitriona. Y eso es porque primero está la regla más restrictiva,
establecer una conexión SSH coincide con la primera regla y no se sigue evaluando. Por
tanto si se quiere que funcione se deben de aplicar primero las reglas más específicas.
! Ahora la conexión SSH si debería de funcionar desde la máquina anfitriona.
! Probamos a establecer una conexión SSH desde otra máquina de la misma subred
y observaremos que no funciona, podrá aceptar la conexión porque tiene política
ACCEPT y la petición llegará pero no se podrá establecer porque la respuesta nunca
podrá salir.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 14
!
______________________________________________________________________________________
2.3. Redirección de tráfico

! En este apartado se nos pide que se redirija todo el tráfico web que se realice con
destino www.ceu.es, hacia otro servidor web externo como por ejemplo www.google.es.
! Lo más adecuado para esto será aplicar reglas de NAT en la cadena de reglas
OUTPUT, que si nos fijamos en el diagrama será la que está en la salida del equipo local.
Y en ese momento cambiaremos la dirección de destino por la que nosotros deseemos.
Esta vez en las reglas si que tendremos que especificar la tabla de la regla puesto que no
va a ser la de filtrado sino la tabla de NAT.
iptables -‐t nat -‐A OUTPUT -‐p tcp -‐-‐dport 80 -‐d www.ceu.es -‐j DNAT
-‐-‐to-‐destination 173.194.34.216:80
! Hacemos la prueba a continuación.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 15
!
______________________________________________________________________________________
! Se podría haber aplicado la regla también por la dirección ip de destino en vez de

por el dominio que sería mejor si por cualquier motivo se bloqueara al servicio DNS.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 16
!
______________________________________________________________________________________
2.4. Usar IPTables para protegerse de una enumeración con

NMap
! En este apartado se nos indica que probemos a identificar el sistema operativo de
la máquina virtual usando NMAP desde otra máquina. Para posteriormente aplicar una
regla con estado que prohiba las conexiones TCP inválidas y ver posteriormente el efecto
de la regla en la ejecución de NMap.
! NMap analiza las respuestas del objetivo ante patrones de ataque que envía, lo
que hace es enviar muchas peticiones de varios tipos, ya sean normales o mal formadas
(no empezando como una petición TCP normal que ha de empezar con SYN). Y ante el
patrón de respuesta a dichas peticiones puede saber el sistema operativo y otros datos en
base a una base de datos de patrones de respuesta.
! El comando a ejecutar para que se obtenga el sistema operativo es el siguiente.
nmap -‐O 172.16.183.100
! No obstante parece que no se ha detectado el sistema operativo como se

esperaba, posiblemente la versión de CentOS que estamos usando no están en los
listados de patrones de respuesta de NMap. Hay que tener en cuenta que hemos lanzado
la detección sobre una máquina que no tiene levantados servicios salvo el SSH, lo cual
dificultará más la detección lógicamente.
! Con este ejercicio se pretendía que se mostrase como después de introducir una
regla con estado en IPTables se dejase de detectar el sistema operativo ya que se
rechazarían las peticiones TCP mal formadas, de manera que al no detectarse ni siquiera
sin filtro alguno, se puede decir que no se va a ver el resultado completo que se pretendía
______________________________________________________________________________________
© Jdyb - Mayo 2013! 17
!
______________________________________________________________________________________
con el ejercicio. No obstante a continuación vamos a mostrar el comando que se debería

de introducir para el filtro con estado.
! IPTables clasifica los paquetes en varios estados posibles, para ello se basa en
analizar las conexiones TCP y también las conexiones producidas a la vez, por ejemplo
FTP tiene una conexión de control y otra de datos.
• NEW: Intentando abrir una nueva conexión.
• ESTABLISHED: Parte de una conexión ya existente.
• RELATED: Relacionada aunque no realmente parte de una conexión existente

(ejemplo de FTP).
• INVALID: No es parte de una conexión existente e incapaz de crear una conexión

nueva.
! Si lo que queremos es evitar que se abran conexiones TCP inválidas contra

nuestro servidor lo que haremos será establecer un filtro con estado que obligue a que las
conexiones se inicien siempre con un segmento SYN. El comando indicado a
continuación indica que se ha de tirar cualquier conexión en el estado NEW que no sea
un segmento SYN.
iptables -‐A INPUT -‐p tcp ! -‐-‐syn -‐m state -‐-‐state NEW -‐j DROP
! Volvemos a lanzar el comando Nmap pero como ya antes no se detectó el sistema

operativo poca diferencia observaremos ahora.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 18
!
______________________________________________________________________________________
! Aunque el caso de prueba no ha funcionado de la manera que se esperaba con lo

que hay que quedarse es con el concepto de filtros con estado y el comando que se ha
introducido para rechazar las conexiones TCP inválidas.
2.5. Filtros con estado para ICMP

! En este ejercicio se nos pide que se parta de una configuración sin filtros y con
política por defecto de DROP. Posteriormente una vez que esté todo el tráfico bloqueado
se pide definir reglas con estado que permitan el tráfico ICMP siempre que sea iniciado
por nosotros o relacionado con nuestras conexiones.
! Lo primero borramos la tabla del ejercicio anterior y aplicamos la política DROP por
defecto en las cadenas de reglas INPUT y OUTPUT.
! Con el primer comando mostrado a continuación permitiremos todas las

conexiones ICP salientes, por tanto podremos establecer nuevas conexiones, abrir otras
relacionadas o que formen parte de la conexión activa. Con la segunda regla permitimos
que nos lleguen conexiones ICMP pero solo las respuestas a las nuestras, no se permite
que se establezca una nueva conexión contra nosotros (no incluido en la regla pero la
política es DROP)
iptables -‐A OUTPUT -‐p icmp -‐m state -‐-‐state NEW,ESTABLISHED,RELATED

-‐j ACCEPT
iptables -‐A INPUT -‐p icmp -‐m state -‐-‐state ESTABLISHED,RELATED -‐j
ACCEPT
______________________________________________________________________________________
© Jdyb - Mayo 2013! 19
!
______________________________________________________________________________________
! Si establecemos una nueva conexión desde la máquina anfitriona a la máquina

virtual no debe ser permitido ya que no se permiten conexiones nuevas en sentido
entrante.
! Sin embargo si abrimos la conexión desde la máquina virtual si se recibirán las

conexiones entrantes que son respuesta.
! Finalmente visto que funciona vamos a borrar las reglas y poner política por
defecto ACCEPT de una manera distinta a como lo hemos estado haciendo. En CentOS
se dispone de un script para realizar acciones con iptables como por ejemplo borrar las
reglas, exportarlas o restaurarlas.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 20
!
______________________________________________________________________________________
! Ahora si que podemos abrir una conexión SSH y veremos como las reglas se han
borrado y las políticas son ACCEPT.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 21
!
______________________________________________________________________________________
3. Router con función de cortafuegos y NAT

! Esta será la segunda parte de la práctica en la que vamos a tener una máquina con
función de reenvío de tráfico e iptables habilitado en ella aplicando reglas en el reenvío de
paquetes. Esta máquina tendrá dos interfaces de red en dos sub-redes diferentes, en
cada una de las sub-redes tendremos otra máquina virtual. Por tanto vamos a trabajar con
tres máquinas virtuales en este apartado.
! Para la realización de este apartado se usará shorewall que es una herramienta

que traduce reglas a más alto nivel en un fichero de configuración a reglas de IPTables,
esto se hacer porque en el entorno en que vamos a trabajar es bastante más complejo
que en el caso anterior y si ya vimos que se complicaba anteriormente teniendo que estar
atento no solo a la apertura de conexiones sino a las respuestas y los puertos en que son
originadas. Este escenario será mucho más complejo al pasar conexiones entre distintas
subredes y otros aspectos.
3.1. Construcción del escenario

! En este apartado vamos a construir el escenario descrito anteriormente. Lo
considero lo suficientemente complejo como para explicar la construcción del mismo y
hacer las pruebas pertinentes de su funcionamiento.
! Lo primero que se va a hacer es disponer de varias máquinas virtuales como ya se

ha comentado, han de ser tres.
! La primera de ellas que será la que normalmente hemos estado usando será la que
va a actuar como router. Lo primero que tendremos que hacer es añadir una segunda
interfaz física mediante las opciones de VMWare, la segunda interfaz que añadamos debe
de estar en modo Host-Only para que este una subred diferente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 22
!
______________________________________________________________________________________
! Reiniciamos ahora el servicio de red de la máquina virtual y se deben de ver las

dos interfaces físicas cada una en una subred diferente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 23
!
______________________________________________________________________________________
! El siguiente paso será arrancar una segunda máquina virtual que se situe dentro de
la subred 172.16.183.0/24 que será nuestra red privada. Para ello esa máquina debe de
tener la configuración de red en modo NAT.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 24
!
______________________________________________________________________________________
! Si observamos la dirección IP veremos que está dentro de la subred indicada.
! Pasaremos ahora a la configuración de la tercera y última máquina virtual, ésta

deberá estar en la subred que vamos a llamar pública que será la 172.16.212.0/24, para
ello deberá estar dentro de la subred que crea VMWare para las máquinas con la interfaz
de red en modo HostOnly.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 25
!
______________________________________________________________________________________
! En este momento el escenario estará configurado correctamente. Tenemos una

máquina virtual que se usará como router con interfaces en la red pública y en la red
privada y en cada una de esas redes tenemos una máquina virtual con una interfaz que
tienen asignada una dirección IP de la subred correspondiente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 26
!
______________________________________________________________________________________
! Ahora mismo debería poderse hacer un ping desde y hacia cada una de las
máquinas de la misma subred pero no podrá hacerse desde una máquina de una subred
hacia otra máquina de diferente subred ya que la máquina que actuará como router no
tiene habilitada la función de reenvío. Esta función deberá ser habilitada.
! Comprobamos ahora que podemos hacer ping con éxito en la red privada entre las
dos máquinas que hay en la misma que son la máquina virtual y la interfaz de la máquina
virtual que actuará como router.
! Realizaremos el mismo proceso dentro de la red pública comprobando que las dos
máquinas se puede hacer ping entre sí.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 27
!
______________________________________________________________________________________
! Finalmente otro aspecto a comprobar es que si no se añade ninguna ruta en la

tabla de de rutas de la máquina que hará la función de router en este momento de la
configuración no se debería poder alcanzar la subred privada desde la red pública. A la
inversa si que podrá ser porque al estar en NAT la red privada, las interfaces de la misma
tienen una puerta de acceso que será el router de VMWare el cual les permitirá llegar.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 28
!
______________________________________________________________________________________
! En este momento se tiene ya configurado el escenario que se nos pide a falta de

hacer algunas configuraciones en las máquinas para habilitar el encaminamiento entre las
dos redes. Dado que hasta ahora lo hemos explicado todo mediante texto vamos a
proponer un gráfico donde se explica la configuración actual de la que disponemos.
Privada Pública
172.16.183.0/24 172.16.212.0/24
Router
VM Red Privada VM Red Pública
eth0: 172.16.183.100
eth0: 172.16.183.200 eth0: 172.16.212.131
eth1: 172.16.212.129
______________________________________________________________________________________
© Jdyb - Mayo 2013! 29
!
______________________________________________________________________________________
3.2. Configuración del escenario

! Ahora lo que falta será completar la configuración del escenario construido. Para
ello lo que haremos es configurar en la Máquina virtual de la red privada la dirección IP de
eth0 en la máquina que actuará de router como puerta de enlace.
! El siguiente paso será habilitar el reenvío de paquetes en la máquina virtual que

actuará como router. Para ello nos podemos encontrar con varias formas, por ejemplo en
Mandriva se puede hacer modificando el fichero de configuración /etc/sysconfig/network, y
añadiendo una nueva variable FORWARD_IPV4.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 30
!
______________________________________________________________________________________
! En nuestra distribución que es CentOS este mismo fichero existe, pero al reiniciar
el servicio de red no se habilita la variable de sistema correspondiente al reenvío de
paquetes /proc/sys/net/ipv4/ip_forward. Se puede visualizar el contenido de la variable
con un comando cat.
! En nuestra distribución habrá que hacerlo en la configuración del sistema situada

en el fichero /etc/sysctl.conf. En la línea net.ipv4.ip_forward, se debe asignar a esta
variable el valor binario 1, tal como se puede apreciar en la captura de pantalla.
! Si visualizamos ahora la variable que hemos mencionado anteriormente después

de reiniciar el servicio de red podemos observar como ahora si está habilitada.
! La máquina de la red pública seguirá sin tener conexión con la red privada debido a
que no tiene puerta de enlace. De momento no la pondremos puesto que la manera
correcta de alcanzar este puesto será haciendo NAT, que como veremos se nos pedirá
próximamente en el enunciado.
! Por otra parte, aunque no configuremos este parámetro, cuando pasemos a los
siguientes apartado en los que se usa Shorewall veremos que funciona igualmente, pero
será porque en la configuración de shorewall hay un parámetro para ajustar esto, de
manera que cuando shorewall se active se activará el forwarding de paquetes. Aunque
después explicaremos los ficheros de configuración de shorewall, este parámetro lo
podemos encontrar en el fichero /etc/shorewall/shorewall.conf.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 31
!
______________________________________________________________________________________
3.3. Instalación de Shorewall

! Para la instalación de Shorewall nos hemos de dirigir al directorio donde nuestra
máquina virtual tiene los paquetes instalables que será /usr/local/src/shorewall.
! Vemos que tenemos varios paquetes de instalación rpm, el principal de shorewall y

también disponemos de las dependencias del mismo. Instalaremos todos los paquetes.
Lo haremos de la misma manera que hemos instalado paquetes otras veces, con el
comando rpm.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 32
!
______________________________________________________________________________________
3.4. Configuración de Shorewall

! En este apartado describiremos la configuración de shorewall para posteriormente
empezar a configurarlo definiendo las reglas que se nos vayan pidiendo en el enunciado.
Los archivos de configuración estarán situados en el directorio /etc/shorewall.
! Como vemos el directorio tiene numerosos ficheros, pero nosotros nos

centraremos en seis de ellos que serán los ficheros de configuración.
• zones: Archivo de configuración para definir las zonas
• policy: Archivo para definir las políticas por defecto
• rules: Fichero de definición de reglas
• masq: Para la configuración del enmascaramiento
• interfaces: Para la identificación de las interfaces
• shorewall.conf: Configuración general
______________________________________________________________________________________
© Jdyb - Mayo 2013! 33
!
______________________________________________________________________________________
3.4.1. Configuración de zonas

! Lo primero que haremos será configurar las zonas en el archivo correspondiente.
Cuando lo abramos nos encontraremos que ya tiene una zona dentro del mismo llamada
fw, esta zona hace referencia al mismo equipo. Nosotros tendremos que añadir dos zonas
más, la zona local o zona de la red privada y la zona pública.
3.4.2. Configuración de políticas

! En este paso explicaremos el archivo de políticas. Este archivo es usado para
establecer políticas por defecto en el paso de los paquetes de una zona a otra. Es decir,
habrá una política a aplicar por ejemplo en el paso de la zona privada a la zona pública,
otra política en el sentido inverso, etc... También es posible establecer en este fichero de
configuración el nivel de registro de la actividad (logs), la tasa de conexiones permitidas,
tamaño máximo de las ráfagas y número máximo de conexiones permitidas
simultáneamente.
3.4.3. Configuración de reglas

! En este fichero se establecen reglas que actuarán como excepciones a las políticas
establecidas en el fichero de políticas, cumplen la misma función que las reglas de
IPTables. Basándose en un origen y destino de las conexiones y otros parámetros como
el protocolo, el puerto, o las direcciones IP establecer reglas más específicas.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 34
!
______________________________________________________________________________________
3.4.4. Configuración de las interfaces

! En este archivo se configuran las interfaces del equipo asociándolos a las zonas en
que están presentes.
! También se indican en este archivo otros parámetros como sus direcciones de

difusión y configuraciones como dhcp si se usa en la subred que gestiona. A continuación
mostramos una configuración válida para nuestro escenario.
3.4.5. Configuración de enmascaramiento

! En el archivo masq se establece en enmascaramiento de direcciones IP en el
tráfico que atraviesa algunos de los interfaces del cortafuegos.
! Las configuraciones se pueden establecer el enmascaramiento por direcciones IP o

especificando la interfaz en la que va a ser enmascarado. Veremos ejemplos en el
apartado correspondiente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 35
!
______________________________________________________________________________________
3.5. Configuración de políticas básicas

! En este apartado se llevará a cabo la configuración de algunas políticas básicas
que se nos describen en el enunciado.
• Es aceptado el tráfico local hacia el exterior.
• Está prohibido el tráfico entrante desde el exterior.
• Se acepta el tráfico saliente desde el cortafuegos hacia cualquier zona.
• Se acepta tráfico entrante al cortafuegos desde la red local.
3.5.1. Configuración previa del escenario

! Lo primero que vamos a hacer es poner como puerta de enlace por defecto al
router en la máquina de la subred pública porque sino no vamos a ser capaces de probar
la correcta configuración ya que la máquina del exterior no va a poder llegar a la red
privada no porque esté impedido sino por problemas de conectividad. Esto no será en una
situación normal lo más adecuado, lo más adecuado sería usar NAT.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 36
!
______________________________________________________________________________________
3.5.2. Configuración de las políticas en Shorewall

! Con el objetivo de cumplir las especificaciones enunciadas anteriormente vamos a
configurar el fichero policy en situado en /etc/shorewall/policy para establecer las políticas.
! Ahora pasamos a aplicar las reglas con el script de shorewall. Observamos que ha
fallado y vamos al log del sistema para observar que es lo que ha ocurrido.
! Nos indica que el inicio de shorewall está deshabilitado y tenemos que habilitarlo
en el fichero de configuración general. Esta variable que se nos pide activar está puesta
como seguridad para evitar que shorewall sea activado accidentalmente antes de ser
configurado. Hay que tener en cuenta que un inicio accidental de shorewall en un sistema
administrado remotamente si las reglas no están configuradas correctamente te puede
dejar sin la conexión remota.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 37
!
______________________________________________________________________________________
! Se puede comprobar que la configuración que permite tráfico local hacia el servidor
del firewall se ha establecido correctamente porque no se ha perdido la conexión SSH
mediante la cual estamos administrando la máquina.
! Comprobamos ahora que no hay comunicación desde el exterior a la red local ni al

cortafuegos.
! Si que hay comunicación desde el interior de la red local hacia el exterior, haciendo
ping a la red pública.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 38
!
______________________________________________________________________________________
! También hay comunicación desde el cortafuegos hacia cualquier zona.
3.5.3. Enmascaramiento de direcciones

! En este apartado se pretende enmascarar direcciones desde la red interior hacia la
red exterior. De manera que si por ejemplo la máquina de la red privada quieres salir al
exterior la dirección origen de esos paquetes será la de la interfaz pública del cortafuegos.
! Para la realización de esta configuración editaremos el archivo /etc/shorewall/

masq. Como ya comentamos se puede hacer basado en las direcciones o en las
interfaces, de manera que lo podremos configurar de dos formas posibles.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 39
!
______________________________________________________________________________________
! Se reinicia shorewall para activar las nuevas reglas de enmascaramiento.
! Para comprobar la correcta configuración vamos a dejar la máquina de la red

privada enviando pings hacia el exterior en concreto a la dirección 172.16.212.131.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 40
!
______________________________________________________________________________________
tráfico de la interfaz eth0 con tcpdump. Con el comando vamos a filtrar los que provengan
de la misma máquina para ver más clara la salida del comando.
tcpdump -‐i eth0 src host 172.16.183.200
! Observamos una petición Echo desde la dirección local a la dirección pública, tal
como habíamos hecho el ping.
! Ahora pondremos en marcha de la misma manera el tcpdump en la interfaz eth0 en

la máquina de destino pública, en ella se tienen que ver peticiones Echo con destino ella
misma pero con dirección origen 172.16.212.129.
tcpdump -‐i eth0
______________________________________________________________________________________
© Jdyb - Mayo 2013! 41
!
______________________________________________________________________________________
! Con esto se comprueba que el enmascaramiento de direcciones está funcionando

correctamente.
3.5.4. Configuración de reglas para las conexiones salientes

! En este apartado se nos pide implantar una serie de reglas para las conexiones
salientes de la red privada de manera que la salida esté más restringida.
Configuración de la política por defecto
! Lo primero que se nos indica es que por defecto las salidas van a estar rechazadas
exceptuando una serie de servicios, por tanto lo primero que haremos será cambiar la
política por defecto a REJECT (más adecuado su uso en el interior ya que devuelve un
rechazo).
! También se pide en el enunciado que se impida el tráfico entrante desde el exterior,

que se acepte el tráfico saliente del cortafuegos hacia cualquier zona y finalmente que el
cortafuegos acepte tráfico entrante hacia si mismo desde la red local.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 42
!
______________________________________________________________________________________
! Aunque hayamos aplicado políticas aquí por petición expresa en el enunciado lo

normal sería restringir todo como se indica en el regla final que en este caso se ha puesto
para que no se dejara de contemplar nada y que lo que se haya quedado sin contemplar
sea denegado.
! Como digo, no este el uso normal del fichero de políticas, sino que se suele
denegar todo como indico a continuación y todas las comunicaciones que se quieran
permitir se indican mediante reglas en el fichero correspondiente. Al estilo de como se
hacía con las políticas de las tablas de iptables.
! Las peticiones que vengan de Internet al resto de las zonas de desprecian sin más,
mientras que las comunicaciones en el resto de las zonas de indica la denegación dando
información y evitando los timeout. De manera que es más elegante al comportarse de
manera diferente para tus usuarios que para el resto de Internet
! Observemos que ahora no es posible hacer un ping desde la red privada hacia el
exterior (después de haber reiniciado Shorewall). Se nos da un mensaje de error
proveniente del cortafuegos, y ello es debido a haber puesto como política por defecto
REJECT en vez de DROP, su hubiéramos puesto DROP no devolvería respuesta alguna,
simplemente tiraría los paquetes sin responder a ellos.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 43
!
______________________________________________________________________________________
Configuración de las reglas
! Una vez que la política ha sido cambiada nos dirigiremos al fichero de reglas en el
que especificaremos reglas específicas para los requisitos que el enunciado nos indicará.
El fichero que editaremos estará situado en el directorio /etc/shorewall/rules.
! Se nos pide que habilitemos la sida de una serie de servicios como por ejemplo
http, https, SMTP, etc... En el fichero de configuración vemos que se establece el origen y
destino y vemos que en el caso de los puerto podemos poner tanto el puerto específico
como el nombre del servicio.
! Añadimos también la posibilidad de usar ICMP hacia el exterior ya que es más fácil
hacer así las pruebas.
! Reiniciamos Shorewall para aplicar las reglas y pasamos a realizar las pruebas
pertinentes.
! Probamos en primer lugar a realizar el ping que probamos anteriormente desde la

red privada hacia el exterior y vemos que funciona correctamente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 44
!
______________________________________________________________________________________
! Levantamos un servidor web en la máquina de la red pública para comprobar que

funciona también la salida de la red privada para hacer consultas a páginas web.
! Nos situamos en la máquina de la red privada e intentamos visitar una web en la

dirección 172.16.212.131 que es la máquina de la red pública.
! Observamos que la configuración ha sido correcta ya que se ha mostrado la página

que se esperaba, que ha sido un index.html que hemos situado en el servidor web recién
levantado en la máquina pública.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 45
!
______________________________________________________________________________________
Configuración de Port Forwarding
! En el enunciado también se nos indica que hagamos público algún servicio de la

red privada hacia el exterior. Por ejemplo un servidor web que se levante dentro la
máquina de la red privada al que se pueda entrar desde una máquina de la red pública.
! Para que esto sea posible las peticiones enviadas a la dirección pública de la red
privada (172.16.212.129) y al puerto 80 serán redirigidas a la dirección IP del servidor web
en el puerto 80. Esto recibe el nombre de port-forwarding.
! Con la regla indicada lo que hacemos es especificar un cambio en la dirección de

destino mediante el uso de Destination-NAT (DNAT) para las peticiones que vayan
dirigidas al puerto 80 de la dirección pública de la red privada y su destino pasará a ser el
de la máquina 172.16.183.200 (manteniendo el mismo puerto).
! Lo primero que vamos a hacer para probar la configuración será eliminar la puerta
de enlace por defecto de la máquina pública ya que al haber implementado DNAT ya
puede alcanzar la red privada sin problemas (en las conexiones para las que haya DNAT).
______________________________________________________________________________________
© Jdyb - Mayo 2013! 46
!
______________________________________________________________________________________
! Ahora en la configuración del router reiniciamos shorewall para aplicar la regla

configurada, y en la máquina privada 172.16.183.200 hemos de levantar un servidor web.
! Ahora en la máquina pública intentamos acceder a la dirección pública de la red

privada desde un navegador.
! Se nos debe de mostrar una página web creada en un index.html sobre el servidor
web que se ha levantado en la máquina privada.
! Con esta prueba queda comprobado que la regla de DNAT está funcionando
correctamente.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 47
!
______________________________________________________________________________________
Configuración de acceso vía SSH al cortafuegos desde el exterior
! En este apartado se pretende configurar un acceso SSH al servidor en el cual está

implementado el cortafuegos, pero desde el exterior, recordemos que la política para
estos casos era DROP.
! También se especifica que el acceso solo se permita desde una dirección de la red
pública concreta. Para realizar esta configuración acudiremos de nuevo al fichero de
reglas.
! Reiniciamos shorewall para aplicar la nueva regla.
! Comprobamos su correcto funcionamiento y vemos que el funcionamiento es

correcto.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 48
!
______________________________________________________________________________________
! Si queremos probar que de verdad solo se admite la conexión SSH desde la

máquina que hemos especificado podemos levantar una cuarta máquina en la red
pública, que deberá estar con la interfaz en modo Host Only.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 49
!
______________________________________________________________________________________
______________________________________________________________________________________
© Jdyb - Mayo 2013! 50
!
______________________________________________________________________________________
Redirección del tráfico DNS
! En este caso se nos indica que todo el tráfico DNS saliente se debe redirigir a un
servidor DNS externo concreto. Por ejemplo, todas las peticiones DNS que se hagan
desde la red local van a ser redirigidas al DNS 8.8.8.8 que es el DNS de google.
! Esto lo haremos mediante DNAT, las peticiones que vengan desde la red privada al
puerto 53 UDP serán redirigidas a la IP 8.8.8.8 en el mismo puerto. No se incluye el
puerto 53 TCP porque las peticiones DNS no lo usan, solo se usa para sincronización
entre servidores DNS.
! El ejemplo que hemos puesto no va a funcionar porque en nuestro esquema

consideramos como net una red del entorno virtual de VMWare que no tiene salida al
exterior. Pero si que vemos la configuración que se ha de aplicar.
! Por no levantar un servidor DNS y configurar zonas en el equipo de la red pública

vamos a hacer el mismo ejemplo con un servidor HTTP que es más fácil de arrancar. En
el fichero de configuración de reglas podremos una línea de configuración parecida tal
como se muestra en la siguiente captura, la única diferencia es que ahora se dirigirán las
peticiones a la dirección IP de la máquina virtual en la red pública, en cuanto el protocolo
será el protocolo TCP por el puerto 80 que es por donde se realiza el tráfico HTTP.
! Ahora con la nueva regla introducida después de reiniciar shorewall para aplicar las
reglas lo que veremos es que cualquier tráfico web originado en la subred privada nos
llevará a la dirección IP indicada.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 51
!
______________________________________________________________________________________
______________________________________________________________________________________
© Jdyb - Mayo 2013! 52
!
______________________________________________________________________________________
4. Apartados opcionales
4.1. Securizar servidor SSH contra ataques de fuerza bruta
! El enunciado nos pone bajo el supuesto de que tenemos un servidor ssh que está
siendo atacado con intento de obtener las contraseñas mediante fuerza bruta, para lo cual
se están registrando peticiones de acceso continuas al mismo.
! Para evitar esto se puede tratar de reducir el número de accesos por dirección IP.
Con el siguiente comando estaríamos reduciendo el número máximo de conexiones
paralelas al servidor por la dirección del cliente.
iptables -‐A INPUT -‐p tcp -‐-‐syn -‐-‐dport 22 -‐m connlimit -‐-‐connlimit-‐
above 3 -‐j REJECT
iptables -‐A INPUT -‐p tcp -‐-‐syn -‐-‐dport 80 -‐m connlimit -‐-‐connlimit-‐
above 20 -‐-‐connlimit-‐mask 24 -‐j DROP
! connlimit-above: Si el número de conexiones existentes es mayor que lo indicado.
! connlimit-mask: Para aplicar la regla por un grupo de hosts, el número indica la

longitud de la máscara.
! Si lo que queremos es poder limitar las conexiones en el tiempo podemos usar el

módulo recent el cual permite monitorizar conexiones recientes con lo cual podríamos
limitar el número de intentos por minuto por ejemplo.
! Necesitaremos dos comandos.
iptables -‐A INPUT -‐p tcp -‐-‐syn -‐-‐dport 22 -‐m state -‐-‐state NEW -‐m
recent -‐-‐set
iptables -‐A INPUT -‐p tcp -‐-‐syn -‐-‐dport 22 -‐m state -‐-‐state NEW -‐m
recent -‐-‐update -‐-‐seconds 60 -‐-‐hitcount 4 -‐j DROP
! El primer comando tomará las peticiones de inicio de sesión a SSH y al haber

puesto el flag SET nos asegura que tomará las direcciones IP de los clientes y las añadirá
a la lista de direcciones recientes que necesita el módulo recent para poder comprobar las
conexiones recientes.
! La segunda regla es donde ocurrirá el filtrado. El flag UPDATE comprobará si las

direcciones IP de las nuevas conexiones al puerto 22 ya existen en la lista de conexiones
recientes. El flag SECONDS establece el intervalo de tiempo en segundos. Finalmente la
opción HITCOUNT establece el número de ocurrencias que debe haber de este tipo de
paquetes para aplicar la acción de la regla.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 53
!
______________________________________________________________________________________
! Resumiendo, la segunda regla hará un DROP de una conexión si la dirección IP

que inicia la conexión ya está en la lista de recientes, ha mandado algún paquete en los
últimos 60 segundos y esos paquetes enviados han sido más de 4 en total.
! Respecto a limitar el número máximo de intentos de login por cada sesión ya no es

algo que se pueda hacer con iptables, es más bien algo propio de SSH por tanto este
ajuste lo realizaremos mediante las configuraciones de OpenSSH, lo haremos con la
opción MaxAuthTries. Es interesante aplicar esto porque si por ejemplo limitamos a dos
los intentos ya no se puede intentar más veces en la misma conexión por lo que se tendrá
que abrir otra y en pocas más que lo intente ya será restringido por las propias reglas de
iptables que hemos especificado anteriormente.
! Hemos configurado los comandos de iptables que hemos indicado como se puede
mostrar en la siguiente captura.
! También hemos realizado la configuración de máximo dos intentos de login en el

fichero de configuración de SSH y hemos reiniciado el servicio.
! Ahora realizamos varios intentos de login continuos y comprobamos el efecto que

han tenido las reglas configuradas. Veremos que no nos deja más que dos intentos por
conexión y no nos dejará intentarlo más de tres veces.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 54
!
______________________________________________________________________________________
! También disponemos de la opción MaxStartups que limita el número máximo de

pantallas de login o conexiones simultáneas de login. Si bien es cierto que una vez que la
sesión haya sido iniciada se pueden tener más terminales de ssh, el número se refiere
solo a pantallas de login. Por tanto como vemos se puede proteger el acceso a servidor
ssh contra ataques de fuerza bruta con unos pocos ajustes.
! La información referente a los comando de IPTables para este apartado ha sido

obtenida de la siguiente página web: http://soi57.net/blog/iptables-para-limitar-el-numero-
de-conexiones-entrantes/. Por otra parte se ha encontrado en esta otra página web las
opciones para securizar SSH mediante la configuración del mismo servidor: http://
www.linuxtotal.com.mx/index.php?cont=info_seyre_004.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 55
!
______________________________________________________________________________________
4.2. Control y limitación del ancho de banda

! Gracias a la función de modificación de iptables es posible usarlo para marcar la
cabecera de determinados paquetes atendiendo a condiciones como las que se han visto
durante el desarrollo de la práctica. Posteriormente, una vez han sido marcados los
paquetes es posibles usar Traffic Control (TC) para aplicar restricciones de ancho de
banda a las clases identificadas.
Configuración de Traffic Control
! Supongamos una interfaz eth4 de un router en el ejemplo que trataremos. Vamos a

crear dos clases de tráfico 1:10 y la 1:12, por defecto todo el tráfico se dirige a la de
menor prioridad que es la última mencionada. La primera mencionada que es la clase
1:10 tiene una mayor prioridad, si hay algo pendiente de enviar en esta clase será
enviado por encima de la clase 1:12.
! Por otra parte la clase de tráfico 1:10 tiene un ratio de 100kbit, aunque puede usar
todo el ancho de banda de 1500kbit compartiéndolo con la clase 1:12.
! El tráfico UDP (protocolo 0x11 0xff de la cabecera IP) será puesto en la clase de
prioridad máxima 1:10, lo que será bueno para juegos en primera persona para asegurar
una latencia baja y que no se vea perjudicado por el tráfico de menor prioridad.
! Llegados a este punto se puede ver que se han creado dos canales de salida de
diferentes prioridades, sabiendo que el de mayor prioridad puede llegar a perjudicar al de
menor prioridad tal y como se desea. El problema es que tanto el tráfico de baja prioridad
como el de alta prioridad pueden ser perjudicados por flujos de gran ancho de banda,
causando que otros flujos de la misma prioridad se vean perjudicados por estos.
! Para poner solución al problema planteado se añaden dos colas SFQ (Stochastic
Fairness Queueing) a las clases de baja prioridad y alta prioridad para asegurar que los
flujos individuales de tráfico son identificados y cada uno de ellos cuenta con la misma
oportunidad de enviar sus datos de las respectivas clases. Esto debería evitar el problema
de inanición dentro de las mismas clases.
! SFQ es un algoritmo de la familia de Fair Queing, menos preciso que otros pero
por otra parte con menor necesidad de cálculo. Estas colas dividen por conversaciones o
flujos TCP, lo que hace que se cree un gran conjunto de colas FIFO, una por cada
conversación, dando la misma oportunidad a las conversaciones, lo que evita como se ha
comentado que se provoque inanición entre distintas conversaciones de la misma
prioridad.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 56
!
______________________________________________________________________________________
modemif=eth4
tc qdisc add dev $modemif root handle 1: htb default 12
tc class add dev $modemif parent 1: classid 1:1 htb rate 1500kbit ceil
1500kbit burst 10k
tc class add dev $modemif parent 1:1 classid 1:10 htb rate 700kbit ceil
1500kbit prio 1 burst 10k
tc class add dev $modemif parent 1:1 classid 1:12 htb rate 800kbit ceil
800kbit prio 2
tc filter add dev $modemif protocol ip parent 1:0 prio 1 u32 match ip
protocol 0x11 0xff flowid 1:10
tc qdisc add dev $modemif parent 1:10 handle 20: sfq perturb 10
tc qdisc add dev $modemif parent 1:12 handle 30: sfq perturb 10
Configuración de IPTables
! En lo referido a la configuración de iptables hemos añadido las reglas en la etapa

de POSTROUTING. Esto permite modificar los paquetes antes de que sean encolados
para su envío por una determinada interfaz de salida, y esto es justo lo que nos interesa.
! En ese punto los paquetes pueden haber sido generados en la propia máquina
localmente o provenir de otra máquina y estar ahí para ser reenviados,
independientemente de que estén preparados para salir por la misma interfaz (eth4 en
este caso). Pasarán todos ellos por la cadena de mangle de esta etapa y será ahí donde
se clasifique el tráfico y se realicen otros ajustes.
! En las reglas de iptables que vamos a ver a continuación se puede ver que todo el
tráfico es ajustado con el flag de mínimo retardo "minimize-delay” (tráfico ssh interactivo
por ejemplo) en las clases de alta prioridad. También todo el tráfico HTTP, HTTPS, y DNS
TCP será clasificado como de alta prioridad. Recordando también que todo el tráfico UDP
será de alta prioridad, lo que incluirá todo el tráfico DNS UDP.
modemif=eth4
iptables -‐t mangle -‐A POSTROUTING -‐o $modemif -‐p tcp -‐m tos -‐-‐tos
Minimize-‐Delay -‐j CLASSIFY -‐-‐set-‐class 1:10
iptables -‐t mangle -‐A POSTROUTING -‐o $modemif -‐p tcp -‐-‐dport 53 -‐j
CLASSIFY -‐-‐set-‐class 1:10
______________________________________________________________________________________
© Jdyb - Mayo 2013! 57
!
______________________________________________________________________________________
! Por la información que se ha podido obtener a estas reglas las deberían

acompañar otras bajo las mismas condiciones en la tabla de filtrado porque estas reglas
aplican las modificaciones sobre los paquetes pero no hace que los mismos abandonen la
cadena de reglas, por tanto habría que añadir las reglas ACCEPT correspondientes en la
tabla de filtrado.
! Como se explicó al principio se usa IPTables para clasificar el tráfico y Traffic

Control actuará según las reglas especificadas sobre las clases de tráfico que vendrán
indicadas en los paquetes al haber sido marcadas con las opciones de mangle.
! Se ha obtenido este ejemplo y las órdenes de Traffic Control e IPTables de la

siguiente página web: http://www.funtoo.org/Traffic_Control.
______________________________________________________________________________________
© Jdyb - Mayo 2013! 58
!

IPTables-Shorewall MemoriaSDC PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IPTables-Shorewall MemoriaSDC PDF

Cargado por

Copyright:

Formatos disponibles

Software de Comunicaciones

Práctica 9 - Filtrado de Paquetes.

Juan Díez-Yanguas Barber

Ingeniería Informática - 5º Curso

2.2. Establecimiento de reglas de filtrado sin estado! 7

2.2.1. Establecimiento de la política por defecto! 7

2.2.2. Establecimiento de reglas! 8

2.2.3. Comprobación de la importancia del orden de las reglas! 13

2.3. Redirección de tráfico! 15

2.4. Usar IPTables para protegerse de una enumeración con NMap! 17

2.5. Filtros con estado para ICMP! 19

3. Router con función de cortafuegos y NAT! 22

3.2. Configuración del escenario! 30

3.3. Instalación de Shorewall! 32

3.4. Configuración de Shorewall! 33

3.4.1. Configuración de zonas! 34

3.4.2. Configuración de políticas! 34

3.4.3. Configuración de reglas! 34

3.4.4. Configuración de las interfaces! 35

3.4.5. Configuración de enmascaramiento! 35

3.5. Configuración de políticas básicas! 36

3.5.1. Configuración previa del escenario! 36

3.5.2. Configuración de las políticas en Shorewall! 37

3.5.3. Enmascaramiento de direcciones! 39

3.5.4. Configuración de reglas para las conexiones salientes! 42

4.2. Control y limitación del ancho de banda! 56

! El sistema de filtrado se compone de una serie de tablas en diferentes etapas, y en

! A continuación indicamos mediante un esquema las diferentes reglas que son

Sistema de Filtrado Manipulación

! Durante el desarrollo de la práctica se hará referencia a cada una de las etapas y

2.1. Estado inicial de IPTables

Si no se especifica tabla la que se muestra por defecto es la de filtrado y si no se

iptables -­‐L(opción listar) -­‐n(mostrar números de puerto e IPs en

! Tal como se indicó no ha sido necesaria instalación ni activación de nada al ser un

2.2. Establecimiento de reglas de filtrado sin estado

2.2.1. Establecimiento de la política por defecto

iptables -­‐P (política) OUTPUT (cadena) DROP

! Hay que tener cuidado en la aplicación de las reglas en un entorno de producción,

! La situación actual se diría que es una situación de bloqueo total en lo que se

2.2.2. Establecimiento de reglas

! Aplicamos a continuación las reglas siguiendo la sintaxis indicada anteriormente.

! Aplicaremos ahora la regla pero en sentido entrante.

! A continuación comprobamos que ahora si se puede enviar pings a otra máquina

! A continuación el enunciado también nos indica que habilitemos el tráfico saliente

! Probamos a continuación a lanzar una petición a google pero por la dirección IP y

! Si lo hacemos por el nombre de dominio no podrá resolverlo porque no se ha

! Vamos a habilitar ahora el tráfico DNS para comprobar que funcione

! Si queremos que desde la máquina local se pueda acceder al servidor web de la

! Finalmente en el enunciado se nos pide que se permitan conexiones entrantes

! Para que funcione ejecutaremos la siguiente regla.

! Y comprobamos que la conexión desde el cliente se establece correctamente.

! Se muestra finalmente el resultado de todas las reglas aplicadas en este apartado.

2.2.3. Comprobación de la importancia del orden de las reglas

! La opción -F se indica para borrar por completo la cadena de reglas, no se ha

! Veamos un ejemplo. Queremos bloquear todo el tráfico saliente TCP salvo el

! Ahora la conexión SSH si debería de funcionar desde la máquina anfitriona.

2.3. Redirección de tráfico

! Hacemos la prueba a continuación.

! Se podría haber aplicado la regla también por la dirección ip de destino en vez de

2.4. Usar IPTables para protegerse de una enumeración con

! El comando a ejecutar para que se obtenga el sistema operativo es el siguiente.

nmap -­‐O 172.16.183.100

! No obstante parece que no se ha detectado el sistema operativo como se

iptables -‐L(opción listar) -‐n(mostrar números de puerto e IPs en

iptables -‐P (política) OUTPUT (cadena) DROP

nmap -‐O 172.16.183.100

iptables -‐A OUTPUT -‐p icmp -‐m state -‐-‐state NEW,ESTABLISHED,RELATED

tcpdump -‐i eth0 src host 172.16.183.200