AyGR 2024 - TP Firewalls/netfilter

Fecha de Entrega: Chivilcoy 03/11/2024. Luján 04/11/2024.

Objetivo: Desarrollar una experiencia práctica en seguridad de redes utilizando un firewall de uso extendido profesionalmente. Conocer las reglas básicas que permiten restringir o permitir el acceso a un servicio determinado en la red. Poner a prueba la aplicación de políticas de seguridad. Conocer buenas prácticas para “suavizar” el efecto de: ataques de denegación de servicio, de envío de spam y finalmente de intentos, por fuerza bruta, de login remoto. Categorías ISO: FCAPS.

Bibliografía

Experiencia de Laboratorio

  1. Teniendo en cuenta las actividades que ha realizado en las prácticas de esta asignatura y de la asignatura Teleinformática y Redes. De las cuatro políticas básicas vistas en la teoría (las “4 P”), ¿cuál considera que es la política de firewall (filtrado de paquetes) aplicada en los equipos Linux? ¿cómo llegó a esa conclusión?
  2. Valide su suposición ejecutando nft list ruleset asegurándose previamente que el servicio nftables se encuentre activo. Busque las líneas chain input, chain forward y chain output y tome nota de la política vigente.
  3. Para el resto de esta experiencia de laboratorio, y para evitar modificar su configuración personal, utilizaremos el laboratorio kathara-lab_webserver.tar.gz.

  Este es un escenario muy sencillo que tiene un host que funciona como webserver llamado “server” con ip 10.0.0.1 y un host “client” con ip 10.0.0.2 que puede realizarle peticiones.

  1. Haga un ping desde “client” hacia “server” y verifique la conectividad. Luego realice un escaneo al servidor mediante nmap. Finalmente, verifique las reglas existentes hasta el momento en el firewall de cada equipo con nft list ruleset.
  2. Vamos a proceder ahora a configurar el firewall en el equipo “server”. Una buena práctica, cuando se quiere configurar una política de seguridad prudente, es denegar primero todo aquello que no esta expresamente permitido. Para lograrlo definiremos una tabla que se utilizará como filtro, luego las cadenas INPUT, OUTPUT y FORWARD, estableciendo una política por defecto para cada una de ellas. La acción recomendada para ello es “DROP”. Con esto lo que lograremos es descartar cualquier paquete recibido y tampoco podremos enviar ni reenviar nada.
nft flush ruleset
nft add table inet firewall
nft add chain inet firewall incoming   "{ type filter hook input priority 0 ; policy drop; }"
nft add chain inet firewall outgoing   "{ type filter hook output priority 0 ; policy drop; }"
nft add chain inet firewall forwarding "{ type filter hook forward priority 0 ; policy drop; }"

  Nosotros pusimos de nombre a la tabla firewall y a las cadenas incoming, outgoing y forwarding por conveniencia, pero tanto la tabla como las cadenas pueden tener cualquier nombre que ud desee; por ej cortafuegos, entrante, saliente, etc).

  ¿Ha llegado usted a la configuración más segura para un servidor web? ¿Que servicio de seguridad no se estaría cumpliendo?

  1. Si en algún momento quiere deshacer todos los cambios efectuados en las reglas ejecute nft flush ruleset. De todas formas, al reiniciar el equipo o parar el servicio de nftables las reglas se limpiarán.
  2. Realice una captura desde su terminal en su equipo real. Para ello y mientras esta situado en el directorio del laboratorio, escriba el comando tshark -i $(ip l | grep ": kt-" | cut -d ":" -f 2) -w captura.pcap. Verifique la configuración realizando un ping desde “client” hacia “server”. ¿Llegan?. Finalice en su terminal la captura con CTRL + C y abra la misma con wireshark captura.pcap. ¿Que puede observar?
  3. El “server” es después de todo un webserver ¿No?. Vamos a permitir que entonces pueda recibir peticiones HTTP de puerto 80 de cualquier IP.
nft add rule inet firewall incoming iif eth0 tcp dport 80 accept

Con esta línea le decimos al firewall que vamos a agregar una regla (add) para permitir (accept) el ingreso (cadena incoming) de los paquetes que lleguen a la interfaz “eth0” (iif eth0), con protocolo tcp y al puerto destino 80 (dport 80).

  1. Con el comando “wget” desde el host “client” solicite al “server” la página index. Para ello ejecute wget http://10.0.0.1/ ¿Funcionó?

Realice nuevamente una captura con tshark -i $(ip l | grep ": kt-" | cut -d ":" -f 2) -w captura.pcap y verifique que sucede con wireshark.

  1. ¡Claramente olvidamos permitir que el servidor pueda enviar paquetes! Para ello agregue la siguiente linea.
nft add rule inet firewall outgoing tcp sport 80 accept

Vuelva a verificar con wget. ¿La página llegó? ¿Si probamos hacer ping desde el cliente al servidor? ¿Llegan? ¿Deberían hacerlo?

  1. Vamos a ser piadosos con el host “client” y vamos a permitir todos los mensajes del protocolo ICMP con este. Para ello en el “server” escribiremos:
nft add rule inet firewall incoming ip protocol icmp ip saddr 10.0.0.2 accept
nft add rule inet firewall outgoing ip protocol icmp ip daddr 10.0.0.2 accept

Con esta linea lo que logramos es agregar una regla en la cadena incoming para que se acepte todo paquete icmp desde la IP del cliente (saddr 10.0.0.2) y que también pueda enviarle (outgoing) a esa IP (daddr 10.0.0.2) paquetes de protocolo icmp. Verifique haciendo ping desde el cliente y desde el servidor.

  1. Suponga que instalamos un nuevo servicio en el host “server” que escuchará en el puerto TCP 8000, pero no queremos que el host “client” se conecte a él. Así como tenemos configurado hasta ahora el firewall del servidor ¿Podría conectarse el host client al puerto 8000 del server? Vamos a verificar. Realice una captura con tshark -i $(ip l | grep ": kt-" | cut -d ":" -f 2) -w obvioQueNoLlega.pcap. Luego desde el host “client” ejecute nc 10.0.0.1 8000 para intentar conectarse al server al puerto 8000. Termine la captura. Observerla con wireshark.
  2. Ahora vamos a cambiar las reglas para avisarle al host cliente que rechazamos sus intentos de conexión. Para ello haremos uso de la acción reject.
nft add rule inet firewall incoming ip saddr 10.0.0.2 tcp dport 8000 reject

Realice una captura nuevamente con el comando tshark -i $(ip l | grep ": kt-" | cut -d ":" -f 2) -w reject.pcap y realice nuevamente desde el host client el intento de conexión nc 10.0.0.1 8000. ¿Qué observa en esta nueva captura a diferencia de la captura anterior?

  1. Nos arrepentimos, ya no queremos avisarle al host “client” que rechazamos sus peticiones. Para ello agregamos la regla:
nft add rule inet firewall incoming ip saddr 10.0.0.2 tcp dport 8000 log
nft add rule inet firewall incoming ip saddr 10.0.0.2 tcp dport 8000 drop
  1. Verifique nuevamente haciendo desde el host client el intento de nc 10.0.0.1 8000. ¿Funcionó? ¿Nos dejó de avisar que nos rechaza la conexión? Claro que no, pero ¿por qué sigue avisando el server que rechaza la conexión si claramente ahora lo debería dropear directamente? Verifique las reglas existentes con nft list ruleset.

  Como puede verse, la regla está efectivamente definida. Sin embargo lo que sucede es que netfilter respeta el orden en que se definen las reglas. Es decir, una vez que una regla hace “match” con el paquete entrante se aplica esa regla y se deja de verificar la tabla. En este caso la primera acción es “REJECT”. La solución en este caso será eliminar las últimas dos reglas, ya que la política por defecto ya era dropear. Para ello listaremos las reglas y luego usaremos el comando delete rule y el número de handle de cada una para borrarlas, de la siguiente manera:

nft -a list ruleset
nft delete rule inet firewall incoming handle XX    # borrar regla reject
nft delete rule inet firewall incoming handle YY    # borrar regla drop
  1. Utilizando el comando nft -a list ruleset nuevamente, liste las reglas existentes para ver como ha quedado todo. Esta configuración ¿es stateful o stateless?
  2. Las reglas definidas para aceptar y responder peticiones http al puerto 80, si bien funcionan, podrían ser aún más “seguras”. Esto es por ejemplo por que la regla nft add rule inet firewall outgoing tcp sport 80 accept permitiría que nuestro servidor envíe respuestas a cualquier IP destino sin importar si alguien hizo con nosotros o no una conexión previamente. Nuestro servidor, tal como descubrimos en el punto anterior, tiene un firewall sin estado por lo que ignora las conexiones previas y su relación con cada paquete que está examinando. Vamos a cambiar esto y para ello vamos a borrar las reglas que habíamos definido en el firewall del servidor de la siguiente manera:
nft delete rule inet firewall incoming handle 4   # borrar regla iif eth0 tcp dport 80 accept
nft delete rule inet firewall outgoing handle 5   # borrar regla tcp sport 80 accept

  Verificamos con wget desde el host “client” y comprobamos que nuevamente no podemos hacer peticiones. Ahora agregaremos la reglas:

nft add rule inet firewall incoming iif eth0 tcp dport 80 ct state new,established accept
nft add rule inet firewall outgoing oif eth0 tcp sport 80 ct state established accept

  Mediante el módulo de connection-tracking ct, estas reglas permiten que solo se acepten conexiones nuevas y establecidas (state new,established) y que envíen paquetes sólo a aquellas conexiones que ya fueron establecidas (ct state established). De esta manera ahora el firewall mantendrá información de las conexiones establecidas por lo que acabamos de convertirlo en un firewall “stateful”.

  1. Hasta ahora todas las reglas se han aplicado para filtrar los paquetes que se envían o reciben en un mismo host. ¿Qué cambios habría que efectuar en las reglas definidas para que funcionen en un router que opera como firewall?

Trabajo Práctico

  1. Analice el siguiente escenario:

Se han dado las siguientes directivas acerca de cómo debe funcionar la red:

  1. Los teléfonos deben poder comunicarse con el servidor de VOIP que utiliza SIP como protocolo de señalización. Nos informan además que uno de los teléfonos es de otra marca y que no soporta los mismos CODEC que los demás.

  2. Los teléfonos VOIP toman su IP del servidor DHCP.

  3. Los teléfonos VOIP toman su configuración del servidor TFTP.

  4. Todos los equipos deben ser capaces de hacer consultas al servidor DNS.

  5. Las computadoras deben poder comunicarse con el Servidor Administrativo que funciona en el puerto TCP 9896.

  6. La computadora con ip 10.2.0.3 debe poder comunicarse con el servidor VOIP a la interfaz administrativa web que funciona con HTTPS.

  7. El router tiene una interfaz de configuración ssh a la que debe poder acceder la PC 10.2.0.3. Todos los demás equipos deberían recibir un REJECT si intentan hacerlo.

  8. El router debe poder contestar enviar y recibir mensajes ICMP.

Su tarea consiste en configurar, a conciencia, el firewall que se encuentra en el router. Para hacerlo debe completar la siguiente tabla de ACL. Considere que el firewall tiene por defecto la acción drop para todas sus cadenas.

Cadena IP Origen IP Destino Protocolo Port Orig Port Destino Acción Comentario
Forward * 10.99.0.2 UDP * 53 ACCEPT dns ida
Forward 10.99.0.2 * UDP 53 * ACCEPT dns vuelta
               
  …   …     …  
               

Donde el valor de Cadena puede ser INPUT (Entrada), OUTPUT (Salida), FORWARD (Reenvío), entre otras, y el valor de la columna Acción puede ser ACCEPT (Permitir), REJECT (Rechazar) o DROP (Descartar), entre otras. Como ejemplo, brindamos las primeras dos líneas completas para permitir el intercambio de mensajes DNS entre las redes con el servidor DNS.

  1. Dada la ACL que usted ha confeccionado, cree un script que configure mediante nft el firewall de ese router. Para ello puede usar de guía el script que se encuentra en el Anexo I, así como también puede consultar el Anexo II que contiene más información acerca del funcionamiento de la herramienta y los snippets presentes en Quick reference-nftables in 10 minutes.

Anexo I

#!/bin/sh
################################################################################
# Script para  implementación de reglas de filtrado en firewall utilizando netfilter
# Interfaces:
# eth0: 172.210.97.200 - Red Interna de la Organización
# eth1: 172.210.96.200 - Red de Acceso público de la Organización
# eth2: 172.210.0.200 - Red de Interconexión a Proveedor de acceso a Internet
################################################################################

################################################################################
# Eliminar todas las reglas existentes
################################################################################
nft flush ruleset

################################################################################
# Políticas por defecto
# Denegar todo el tráfico que no se habilite de manera específica
################################################################################

nft add table ip filter
nft add chain ip filter input { type filter hook input priority 0; policy drop; }
nft add chain ip filter output { type filter hook output priority 0; policy drop; }
nft add chain ip filter forward { type filter hook forward priority 0; policy drop; }

################################################################################
#   Permitir al firewall enviar/recibir tráfico de servicios básicos
################################################################################
## DNS 
nft add rule ip filter output ip daddr 172.210.96.1 udp dport 53 accept
nft add rule ip filter output ip daddr 172.210.96.1 udp dport 53 ct state new accept
nft add rule ip filter input ip saddr 172.210.96.1 udp sport 53 accept

## NTP
nft add rule ip filter output ip daddr 172.210.96.1 udp dport 123 accept
nft add rule ip filter input ip saddr 172.210.96.1 udp sport 123 accept

## SMTP - Correo electrónico saliente
nft add rule ip filter output ip daddr 172.210.96.3 tcp dport 25 ct state new accept

## Aceptar paquetes de conexiones ya establecidas
nft add rule ip filter input ct state related,established accept

## Aceptar conexiones locales
nft add rule ip filter input iif "lo" accept

#########################################################################
#  Paquetes en tránsito (tráfico que se rutea)
#########################################################################

## Permitir paquetes pertenecientes a conexiones ya establecidas
nft add rule ip filter forward ct state related,established accept

################################################################
#  a) Accedo desde red privada a servicios en servidores corporativos
################################################################
## Acceso a servidor de correo electrónico
nft add rule ip filter forward iif "eth0" ip saddr 172.210.97.0/24 ip daddr 172.210.96.3 tcp dport {25,110,143} ct state new accept

## Acceso a servidor dns y ntp
nft add rule ip filter forward iif "eth0" ip saddr 172.210.97.0/24 ip daddr 172.210.96.1 udp dport 53 accept
nft add rule ip filter forward iif "eth0" ip saddr 172.210.97.0/24 ip daddr 172.210.96.1 tcp dport 53 ct state new accept
nft add rule ip filter forward iif "eth0" ip saddr 172.210.97.0/24 ip daddr 172.210.96.1 udp dport 123 accept

## Acceso a servidor web
nft add rule ip filter forward iif "eth0" ip saddr 172.210.97.0/24 ip daddr 172.210.96.2 tcp dport {80,443} ct state new accept

################################################################
#  b) Desde Internet es posible acceder al servidor web de la empresa.
################################################################
nft add rule ip filter forward iif "eth2" ip daddr 172.210.96.2 tcp dport {80,443} ct state new accept        

################################################################
# c) Desde Internet es posible enviar correo electrónico al servidor de correo
#    corporativo.
################################################################
nft add rule ip filter forward iif "eth2" ip daddr 172.210.96.3 tcp dport 25 ct state new accept

################################################################
# d) Desde Internet es posible realizar consultas DNS al servidor de nombres
#    de dominio de la organización.
################################################################
nft add rule ip filter forward iif "eth2" ip daddr 172.210.96.1 udp dport 53 accept
nft add rule ip filter forward iif "eth2" ip daddr 172.210.96.1 tcp dport 53 ct state new accept

################################################################
# e) El servidor de nombres de dominio debe sincronizarse con otros servidores
#    NTP accesibles a través de Internet.
################################################################
nft add rule ip filter forward iif "eth1" ip saddr 172.210.96.1 udp dport 123 accept

Anexo II - Algo más de teoría

Flujo de paquetes en Linux – Hooks de netfilter

Flujo de paquetes en Linux – Hooks de netfilter

nftables es una herramienta de filtrado de paquetes y gestión de firewall en Linux, diseñada para reemplazar a iptables, ip6tables, arptables y ebtables. Incorporado en el kernel de Linux 3.13, nftables ofrece una interfaz unificada y simplificada para la configuración de reglas de red, lo que mejora la eficiencia y la legibilidad.

Características Principales

  1. Sintaxis Unificada: Combina las funcionalidades de las herramientas anteriores en una única sintaxis, facilitando la gestión y reducción de la complejidad.

  2. Soporte para IPv4 e IPv6: Permite gestionar tanto tráfico IPv4 como IPv6 desde una misma herramienta.

  3. Mejoras en el Rendimiento: Utiliza un motor de evaluación de reglas optimizado que mejora el rendimiento en comparación con sus predecesores.

  4. Soporte para Conjuntos: Permite definir conjuntos de direcciones IP, puertos y otros elementos, lo que simplifica la creación de reglas complejas.

  5. Hooks y Prioridades: Ofrece un sistema de hooks (enganches) para integrar reglas en diferentes puntos del procesamiento de paquetes, permitiendo mayor flexibilidad.

  6. Persistencia: Las reglas pueden ser guardadas y restauradas fácilmente, lo que facilita la gestión a largo plazo.

Conceptos Clave en nftables

  1. Tablas: Las tablas son contenedores que agrupan cadenas y reglas. En nftables, cada tabla se asocia con un tipo de tráfico (por ejemplo, IPv4 o IPv6) y puede contener múltiples cadenas. Esto permite organizar y estructurar las reglas de manera lógica.

  2. Cadenas: Las cadenas son secuencias de reglas que se aplican a los paquetes en un punto específico del procesamiento de red. Cada cadena tiene un tipo (por ejemplo, filter, nat, etc.) y un hook que define en qué momento se evaluarán las reglas (por ejemplo, al recibir un paquete o al enviarlo).

  3. Reglas: Las reglas son condiciones específicas que se evalúan para determinar cómo manejar un paquete. Una regla puede especificar criterios como la dirección IP de origen, el puerto de destino, el protocolo, etc. Si un paquete coincide con una regla, se aplica la acción asociada.

  4. Hooks: Los hooks son puntos en el flujo de procesamiento de paquetes donde se pueden aplicar las cadenas. Por ejemplo, hay hooks para el tráfico de entrada (input), salida (output), y reenvío (forward). Esto permite a los administradores definir cómo se deben tratar los paquetes en diferentes etapas del ciclo de vida del tráfico de red.

Acciones de las Reglas

Las reglas en nftables pueden tener varias acciones que determinan cómo se debe manejar un paquete que coincide con los criterios establecidos. Algunas de las acciones más comunes son:

  • accept: Permite que el paquete continúe su camino a través de la red.
  • drop: Descarta el paquete sin enviar ninguna notificación al remitente.
  • reject: Similar a drop, pero envía un mensaje de error al remitente indicando que el paquete fue rechazado.
  • log: Registra información sobre el paquete en los logs del sistema, lo que es útil para auditorías y depuración.
  • masquerade: Se utiliza en configuraciones NAT para ocultar la dirección IP interna al salir a Internet, permitiendo que múltiples dispositivos compartan una única dirección IP pública.
  • mark: Marca un paquete con un valor específico, que puede ser utilizado por otras reglas o aplicaciones para tomar decisiones adicionales.
  • queue: Envía el paquete a un espacio de usuario para su procesamiento adicional, lo que es útil para aplicaciones como sistemas de detección de intrusiones.

Uso Básico

  • Listar Reglas: nft list ruleset
  • Agregar una Tabla: nft add table ip filter
  • Agregar una Cadena:
    nft add chain ip filter input { type filter hook input priority 0; }
  • Agregar una Regla: nft add rule ip filter input ip saddr 192.168.1.0/24 accept

Las “condiciones” que se definen en una regla pueden ser múltiples. Las más habituales son:

ip protocol YYY     coincide con el campo de protocolo “de transporte”,
                    los valores más comunes son tcp, udp, icmp e icmpv6.
ip saddr IP_ADDR        coincide con la dirección de host origen (o red si indica máscara)
ip daddr IP_ADDR        coincide con la dirección de host destino (o red si indica máscara)
iif INTERFAZ        coincide con la interfaz de red donde arribó un paquete
tcp sport NN        coincide con el número de puerto TCP o UDP origen
tcp dport NN        coincide con el número de puerto TCP o UDP destino
ct state new        coincide con paquetes TCP de apertura de conexión
ct state ...            coincide con un estado de conexión particular (para stateful)
                    * Es posible negar cualquier condición con el signo !

Con estos conceptos y acciones, nftables proporciona una estructura flexible y potente para gestionar el tráfico de red. La capacidad de organizar reglas en tablas y cadenas, junto con la variedad de acciones disponibles, permite a los administradores personalizar el comportamiento del firewall según las necesidades específicas de su entorno.