Introducción
Usar un firewall tiene tanto que ver con tomar decisiones de políticas inteligentes como con aprender la sintaxis. Los firewalls como iptables están diseñados para hacer cumplir políticas mediante la interpretación de reglas establecidas por el administrador. Sin embargo, como administrador, necesitas saber qué tipos de reglas tienen sentido para tu infraestructura.
Mientras que otros guías se centran en los comandos necesarios para comenzar, en esta guía discutiremos algunas de las decisiones que tendrás que tomar al implementar un firewall. Estas decisiones afectarán cómo se comporta tu firewall, cuán asegurado está tu servidor y cómo responderá a diversas condiciones que ocurran. Utilizaremos iptables como ejemplo específico, pero la mayoría de los conceptos serán ampliamente aplicables.
Decidir sobre una Política Predeterminada
Al construir un firewall, una de las decisiones más importantes a tomar es la política por defecto. Esto determina qué sucede cuando el tráfico no coincide con ninguna otra regla. Por defecto, un firewall puede ACEPTAR cualquier tráfico que no coincida con reglas anteriores, o DROPEAR ese tráfico.
Default Drop vs Default Accept
A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.
La alternativa es una política por defecto de DROPEAR. Esto significa que cualquier tráfico que no coincida con una regla explícita no será permitido. Cada servicio debe ser explícitamente permitido, lo que podría parecer una cantidad significativa de configuración inicial. Sin embargo, esto significa que su política tiende hacia la seguridad y que sabe exactamente qué está permitido recibir tráfico en su servidor. Además, casi todas las políticas preconfiguradas seguirán este enfoque, lo que significa que puede basarse en los valores por defecto existentes.
Default Drop Policy vs Final Drop Rule
La elección de una política de drop por defecto conduce a otra decisión sutil. Con iptables y otros firewalls similares, la política por defecto se puede establecer utilizando la funcionalidad de política integrada del firewall, o implementándola agregando una regla de drop general al final de la lista de reglas.
La distinción entre estos dos métodos se reduce a lo que sucede si se borran las reglas del firewall.
Si la función de política incorporada de su firewall está configurada como DROP y las reglas del firewall se borran alguna vez (se restablecen), o si se eliminan ciertas reglas de coincidencia, sus servicios se volverán inaccesibles de inmediato de forma remota. Esto suele ser una buena idea al establecer políticas para servicios no críticos, de manera que su servidor no quede expuesto a tráfico malicioso si las reglas se eliminan.
La desventaja de este enfoque es que sus servicios estarán completamente no disponibles para sus clientes hasta que restablezca reglas permisivas. Incluso podría bloquearse fuera del servidor si no tiene acceso remoto local o basado en la web como alternativa.
La alternativa para establecer una política de bloqueo mediante la funcionalidad de política incorporada es establecer la política predeterminada del firewall como ACCEPT y luego implementar una política de DROP con reglas regulares. Puede agregar una regla de firewall normal al final de su cadena que coincida y deniegue todo el tráfico restante no coincidente.
En este caso, si se borran las reglas del firewall, sus servicios serán accesibles pero no protegidos. Dependiendo de sus opciones de acceso local o alternativo, esto podría ser un mal necesario para asegurarse de poder volver a ingresar a su servidor si las reglas se borran. Si decide utilizar esta opción, asegúrese de que la regla de captura siempre permanezca como la última regla en su conjunto de reglas.
Dejar vs Rechazar Tráfico
Hay varias formas de evitar que un paquete llegue a su destino previsto. La elección entre estas opciones tiene un impacto en cómo percibe el cliente su intento de conexión y qué tan rápido puede determinar que su solicitud no será atendida.
La primera forma en que los paquetes pueden ser denegados es con DROP. DROP puede ser utilizado como política predeterminada o como objetivo para reglas de coincidencia. Cuando un paquete es dejado caer, iptables simplemente lo descarta. No envía ninguna respuesta de vuelta al cliente que intenta conectarse y no da ninguna indicación de que alguna vez haya recibido los paquetes en cuestión. Esto significa que los clientes (legítimos o no) no recibirán ninguna confirmación de la recepción de sus paquetes.
Para intentos de conexión TCP (como las conexiones realizadas por un navegador web), la conexión se detendrá hasta que se alcance el límite de tiempo de espera. La falta de respuesta para los clientes UDP es aún más ambigua. De hecho, no recibir un paquete UDP de vuelta a menudo es una indicación de que el paquete fue aceptado. Si al cliente UDP le importa la recepción de sus paquetes, tendrá que volver a enviarlos para intentar determinar si fueron aceptados, se perdieron en tránsito o fueron dejados caer. Esto puede aumentar la cantidad de tiempo que un actor malintencionado tendrá que pasar para obtener información sobre el estado de los puertos de su servidor, pero también podría causar problemas con el tráfico legítimo.
Una alternativa para evitar el tráfico es rechazar explícitamente los paquetes que no se permiten. ICMP, o Protocolo de Mensajes de Control de Internet, es un metaprotocolo utilizado en todo Internet para enviar mensajes de estado, diagnóstico y error entre hosts como un canal fuera de banda que no depende de protocolos de comunicación convencionales como TCP o UDP. Cuando se utiliza el objetivo REJECT en lugar del objetivo DROP, se niega el tráfico y se devuelve un paquete ICMP al remitente para informarles que su tráfico fue recibido pero no será aceptado. También se puede incluir un mensaje de estado para proporcionar una razón.
Esto tiene varias consecuencias. Suponiendo que el tráfico ICMP tiene permitido llegar al cliente, este será informado inmediatamente de que su tráfico está bloqueado. Para clientes legítimos, esto significa que pueden contactar al administrador o verificar sus opciones de conexión para asegurarse de que están llegando al puerto correcto. Para usuarios malintencionados, esto significa que pueden completar sus exploraciones y mapear los puertos abiertos, cerrados y filtrados en un período de tiempo más corto.
Hay mucho que considerar al decidir si se debe descartar o rechazar el tráfico. Una consideración importante es que la mayor parte del tráfico malintencionado será perpetrado en realidad por scripts automatizados. Dado que estos scripts típicamente no están supervisados, descartar el tráfico ilegítimo no los desalentará de manera significativa y tendrá efectos negativos para los usuarios legítimos. Más sobre este tema se puede encontrar en el sitio web de Peter Benie.
Tabla de Respuestas Drop vs Reject
La tabla a continuación muestra cómo reaccionará un servidor protegido por un firewall ante diferentes solicitudes, según la política aplicada al puerto de destino.
| Client Packet Type | NMap Command | Port Policy | Response | Inferred Port State |
|---|---|---|---|---|
| TCP | nmap [-sT | -sS] -Pn <server> | Accept | TCP SYN/ACK | Open |
| TCP | nmap [-sT | -sS] -Pn <server> | Drop | (none) | Filtered |
| TCP | nmap [-sT | -sS] -Pn <server> | Reject | TCP RESET | Closed |
| UDP | nmap -sU -Pn <server> | Accept | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Drop | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Reject | ICMP Port Unreachable | Closed |
La primera columna indica el tipo de paquete enviado por el cliente. La segunda columna contiene los comandos nmap que se pueden utilizar para probar cada escenario. La tercera columna indica la política de puerto aplicada al puerto. La cuarta columna es la respuesta que enviará el servidor y la quinta columna es lo que el cliente puede inferir sobre el puerto según la respuesta recibida.
Políticas ICMP
Al igual que al decidir si deseas descartar o rechazar el tráfico denegado, tienes la opción de aceptar o rechazar paquetes ICMP destinados a tu servidor.
ICMP es un protocolo utilizado para muchas cosas. Como se mencionó, a menudo se envía para dar información de estado sobre solicitudes que utilizan otros protocolos. Una de sus funciones más populares es enviar y responder a pings de red para verificar la conectividad con hosts remotos. Hay muchos otros usos para ICMP que no son tan conocidos, pero aún así son útiles.
Los paquetes ICMP están organizados por “tipo” y luego por “código”. Un tipo especifica el significado general del mensaje. Por ejemplo, el Tipo 3 significa que el destino no era accesible. A menudo, un código se utiliza para proporcionar información adicional sobre un tipo. Por ejemplo, el Código 3 del Tipo 3 de ICMP significa que el puerto de destino no estaba disponible, mientras que el Código 0 del Tipo 3 de ICMP significa que la red de destino no se pudo alcanzar.
Algunos tipos ICMP están obsoletos, por lo que pueden bloquearse incondicionalmente. Entre ellos se encuentran el supresor de origen ICMP (tipo 4 código 0) y el host alternativo (tipo 6). Los Tipos 1, 2, 7 y el Tipo 15 en adelante están obsoletos, reservados para uso futuro o experimental. Muchas plantillas de firewall aguas arriba manejarán esto de forma predeterminada.
Tipos para bloquear según la configuración de red
Algunos tipos ICMP son útiles en ciertas configuraciones de red, pero deben bloquearse en otras.
Por ejemplo, los mensajes de redirección ICMP (tipo 5) pueden ser útiles para iluminar un diseño de red deficiente. Se envía una redirección ICMP cuando hay una ruta mejor disponible directamente para el cliente. Entonces, si un enrutador recibe un paquete que deberá enrutarse a otro host en la misma red, envía un mensaje de redirección ICMP para indicar al cliente que envíe los paquetes a través del otro host en el futuro.
Esto es útil si confías en tu red local y deseas detectar ineficiencias en tus tablas de enrutamiento durante la configuración inicial. En una red no confiable, un usuario malicioso podría potencialmente enviar redirecciones ICMP para manipular las tablas de enrutamiento en los hosts.
Otros tipos de ICMP que son útiles en algunas redes y potencialmente perjudiciales en otras son los paquetes de anuncio de enrutador ICMP (tipo 9) y la solicitud de enrutador (tipo 10). Los paquetes de anuncio y solicitud de enrutador se utilizan como parte del protocolo de descubrimiento de enrutador de Internet (IRDP, por sus siglas en inglés), un sistema que permite a los hosts, al iniciar o unirse a una red, descubrir dinámicamente los enrutadores disponibles.
En la mayoría de los casos, es mejor que un host tenga rutas estáticas configuradas para las pasarelas que utilizará. Estos paquetes deben ser aceptados en las mismas situaciones que los paquetes de redirección ICMP. De hecho, dado que el host no conocerá la ruta preferida para el tráfico de cualquier ruta descubierta, a menudo se necesitan mensajes de redirección justo después del descubrimiento. Si no estás ejecutando un servicio que envía paquetes de solicitud de enrutador o modifica tus rutas según los paquetes de anuncio (como rdisc), puedes bloquear de forma segura estos paquetes.
Tipos que a menudo son seguros de permitir
Los tipos de ICMP que generalmente son seguros de permitir se enumeran a continuación, pero puedes desactivarlos si deseas ser especialmente cauteloso.
- Tipo 8 — Solicitud de eco: Estas son solicitudes de ping dirigidas a tu servidor. Por lo general, es seguro permitirlas (negar estos paquetes no oculta tu servidor, ya que hay muchas otras formas para que los usuarios descubran si tu host está activo), pero puedes bloquearlas o limitar las direcciones de origen a las que respondes si así lo deseas.
- Tipo 13 — Solicitud de marca de tiempo: Estos paquetes pueden ser utilizados por clientes para recopilar información de latencia. Pueden ser utilizados en algunas técnicas de huella digital de sistemas operativos, por lo que puedes bloquearlos o limitar el rango de direcciones a las que respondes.
Los tipos a continuación generalmente pueden permitirse sin reglas explícitas configurando tu firewall para permitir respuestas a solicitudes que ha realizado (utilizando el módulo conntrack para permitir tráfico ESTABLISHED y RELATED).
- Tipo 0 — Respuestas de eco: Estas son respuestas a solicitudes de eco (pings).
- Tipo 3 — Destino inaccesible: Los paquetes legítimos de destino inaccesible son respuestas a solicitudes creadas por tu servidor que indican que el paquete no pudo ser entregado.
- Tipo 11 — Tiempo excedido: Este es un error de diagnóstico devuelto si un paquete generado por tu servidor murió antes de llegar al destino debido a que excedió su valor TTL.
- Tipo 12 — Problema de parámetro: Esto significa que un paquete saliente de tu servidor estaba malformado.
- Tipo 14 — Respuestas de marca de tiempo: Estas son las respuestas a las consultas de marca de tiempo generadas por tu servidor.
Aún se recomienda bloquear todo el tráfico ICMP entrante por algunos expertos en seguridad, sin embargo, muchas personas ahora fomentan políticas inteligentes de aceptación de ICMP. Estas dos discusiones de Stackexchange tienen más información.
Límite de Conexiones y Límite de Velocidad
Para algunos servicios y patrones de tráfico, puede que quieras permitir el acceso solo mientras el cliente no esté abusando de ese acceso. Dos formas de limitar el uso de recursos son el límite de conexiones y el límite de velocidad.
Límite de Conexiones
El límite de conexiones se puede implementar utilizando extensiones como connlimit para verificar cuántas conexiones activas tiene abiertas un cliente. Esto se puede utilizar para restringir el número de conexiones permitidas a la vez. Si decides imponer límites de conexión, tendrás que tomar algunas decisiones:
- ¿Limitas por dirección, por red, o en todo el ámbito global?
- ¿Coincides y restringes el tráfico para un servicio específico o para todo el servidor?
Las conexiones pueden ser limitadas caso por caso en un host, o se puede establecer un límite para un segmento de red proporcionando un prefijo de red (como un rango de direcciones IP para toda una organización). También puedes establecer un número máximo global de conexiones para un servicio o para toda la máquina. Ten en cuenta que es posible combinar estas opciones para crear políticas más complejas y controlar el número de conexiones.
Limitación de velocidad
La limitación de velocidad te permite crear reglas que controlan la velocidad o frecuencia con la que el tráfico será aceptado por tu servidor. Hay varias extensiones de firewall que se pueden usar para limitar la velocidad, incluyendo limit, hashlimit y recent. La elección de la extensión dependerá en gran medida de cómo desees limitar el tráfico.
La extensión limit hará que la regla en cuestión coincida hasta alcanzar el límite, después de lo cual se descartarán más paquetes. Un límite como 5/seg permitirá que coincidan 5 paquetes por segundo, después de lo cual la regla ya no coincidirá. Esto es útil para establecer un límite global de velocidad para un servicio. También puedes implementar un servicio adicional como Fail2ban para bloquear intentos repetidos de conexión.
La extensión hashlimit es más flexible, lo que te permite especificar algunos de los valores que iptables utilizará para hacer hash y evaluar una coincidencia. Por ejemplo, puede observar la dirección de origen, el puerto de origen, la dirección de destino, el puerto de destino o una combinación de esos cuatro valores para evaluar cada entrada. Puede limitar por paquetes o por bytes recibidos. Esto proporciona una limitación flexible de la tasa por cliente o por servicio.
La extensión recent añade dinámicamente direcciones IP de cliente a una lista o comprueba contra una lista existente cuando la regla coincide. Esto te permite distribuir tu lógica de limitación en varias reglas diferentes para patrones complejos. Tiene la capacidad de especificar un recuento de aciertos y un rango de tiempo como los otros limitadores, pero también puede reiniciar el rango de tiempo si se detecta tráfico adicional, obligando a un cliente a detener todo el tráfico si está siendo limitado.
Gestión Monolítica vs Basada en Cadenas
Toda la política de firewall de iptables y nftables se basa esencialmente en la extensión de las cadenas integradas. Para empezar, esto suele implicar cambiar la política predeterminada de las cadenas existentes y añadir reglas. Para firewalls más complejos, a menudo es una buena idea ampliar el marco de gestión mediante la creación de cadenas adicionales.
Las cadenas creadas por el usuario se llaman secundariamente y están inherentemente vinculadas a su “cadena de llamadas” de origen. Las cadenas creadas por el usuario no tienen una política predeterminada, así que si un paquete atraviesa una cadena creada por el usuario, volverá a la cadena de llamadas y continuará la evaluación. Con eso en mente, las cadenas creadas por el usuario son principalmente útiles con fines organizativos, para hacer que las condiciones de coincidencia de reglas sean más mantenibles y mejorar la legibilidad al dividir las condiciones de coincidencia.
Si te encuentras repitiendo ciertos criterios de coincidencia para un número significativo de reglas, podría valer la pena crear una regla de salto con los criterios de coincidencia compartidos a una nueva cadena. Dentro de la nueva cadena, puedes agregar ese conjunto de reglas con los criterios de coincidencia redundantes omitidos.
La decisión de agrupar todas tus reglas en una de las cadenas incorporadas o de crear y utilizar cadenas adicionales dependerá de la complejidad de tu conjunto de reglas.
Conclusión
Ahora deberías tener una mejor comprensión de las decisiones que tendrás que tomar al diseñar políticas de firewall para tus servidores. Por lo general, la inversión de tiempo involucrada en los firewalls tiende a inclinarse fuertemente hacia la configuración inicial. Aunque puede llevar algo de tiempo y experimentación crear una política que sirva mejor a tus necesidades, hacerlo te dará más control sobre la seguridad de tu servidor.
Si deseas obtener más información sobre firewalls y iptables específicamente, consulta los siguientes artículos:
Las siguientes guías pueden ayudarte a implementar tus políticas. Elige la guía que corresponda a tu firewall para comenzar: