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

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

Í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

Juan Díez- Yanguas Barber! Práctica 9______________________________________________________________________________________

______________________________________________________________________________________© 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.

! 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.

PREROUTING FORDWARDEntrega local

INPUT

POSTROUTING

OUTPUT

Procesado local

NO

SI

Sistema de Filtrado

DNATManipulación

(Mangle)

SNATManipulación

(Mangle)

DNATManipulación

(Mangle)

Filtrado

Manipulación (Mangle)

Filtrado

Manipulación (Mangle)

Filtrado


______________________________________________________________________________________© 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.

Privada172.16.183.0/24

Pública172.16.212.0/24

Routereth0: 172.16.183.100eth1: 172.16.212.129

VM Red Privadaeth0: 172.16.183.200

VM Red Públicaeth0: 172.16.212.131


______________________________________________________________________________________© 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!

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!

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!

http://soi57.net/blog/iptables-para-limitar-el-numero-de-conexiones-entrantes/




http://www.linuxtotal.com.mx/index.php?cont=info_seyre_004




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!

http://www.funtoo.org/Traffic_Control

http://www.funtoo.org/Traffic_Control

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

Documents

Transcript of Software de Comunicaciones Práctica 9 - Filtrado de...