Firewall RouterOS

Firewall - Cortafuegos

Bibliografía: Learn RouterOS by Dennis Burgess
https://wiki.mikrotik.com/wiki/Main_Page

Por definición, los firewalls deberían pasar buen tráfico y bloquear el mal tráfico. Este tráfico bueno y malo pasa a nuestro firewall, desde nuestro firewall o a través de nuestro firewall. En casi todas las circunstancias, un firewall también actúa como un enrutador que realmente no agrega ninguna complejidad, pero vale la pena contrastar con lo que generalmente se denomina un firewall "pasivo" o firewall de puente. En un firewall pasivo o puente, el dispositivo se inserta en la red como un dispositivo de Capa 2, lo que significa que no está enrutando paquetes. Por lo general, tiene una dirección IP, pero solo para fines de administración. A diferencia de un enrutador, todos los paquetes que ingresan al firewall pasivo salen del firewall a menos que existan reglas que eliminen específicamente esos paquetes.Cubriremos los firewalls de enrutamiento, aunque los firewalls pasivos se crean de manera similar.

Los cortafuegos necesitan reglas para restringir el flujo de tráfico y, afortunadamente, estas reglas están organizadas en cadenas. El propósito de las cadenas es determinar en qué punto de la progresión de un paquete dentro o a través del firewall se aplica un conjunto de reglas. Las tres cadenas predeterminadas son entrada (input), reenvío (forward) y salida (output). 

Input 

Comencemos con la cadena de entrada. La cadena de entrada está diseñada para proteger el enrutador. Considere el siguiente diagrama:

Como puede ver, esta es una ubicación muy típica de un enrutador de firewall en la puerta de enlace a Internet público para una red de área local. La red de área local o LAN utiliza direcciones IP privadas, ocultas de la Internet pública o WAN, detrás de la dirección pública en la dirección IP externa o pública del firewall/enrutador. Los paquetes que provienen de la LAN o de la WAN destinados al enrutador pasarán a la cadena de entrada, por lo que esa es la ubicación lógica de las reglas para proteger el enrutador. 

Esto trae un detalle importante sobre el funcionamiento de las redes IP en lo que se refiere a la formación de paquetes.

Los paquetes son los mensajeros de Internet, muy similar a una carta que envía por correo en la oficina de correos. Cada carta tiene una dirección "a" y una dirección "desde" o de retorno. La dirección "a" le dice a la oficina de correos dónde se debe enrutar la carta y la dirección "desde" les dice dónde devolver la carta si no se puede entregar. Del mismo modo, los paquetes tienen una dirección de "origen" y una dirección de "destino".

A menudo se abrevian como dst para el destino y src para la fuente. Cuando su computadora envía un paquete, forma los paquetes con una dirección dst igual a la IP resuelta para www.freebsd.org y usa la dirección IP de la PC como dirección src. Cuando Freebsd recibe los paquetes y quiere devolverlos con la información solicitada; invierte el src y el dst y obtiene lo que solicitó. Si algo sale mal en el camino, los enrutadores ascendentes saben a qué host enviar el paquete de regreso como "no entregables" o "inalcanzables".

Por lo general, los únicos paquetes que deberían ir a nuestro enrutador son los paquetes de comunicaciones, las conexiones que nuestro enrutador ha iniciado (que asumimos que son legítimos y seguros) o los paquetes que nos representan administrando o configurando nuestros enrutadores. Esto reduce en gran medida la lista de direcciones IP de host seguras y hace que la creación de reglas de firewall sea mucho más simple. El esquema más fácil de usar al crear reglas de firewall es permitir lo que determina que es un tráfico bueno o seguro y luego usar comodines para descartar el resto del tráfico. 

Entonces, ¿qué es el tráfico "bueno" a su enrutador de firewall? Eso es realmente fácil y se puede encontrar pensando en dos cosas:

- ¿Qué protocolos y puertos usará para administrar el enrutador?

- ¿Qué servicios proporcionará su enrutador a la red LAN o WAN?

Estas dos preguntas definirán todas las reglas que colocará en la cadena "a" y todo lo demás deberá ser eliminado.

Antes de continuar, es necesario examinar la forma en que las reglas de firewall en cualquier cadena funcionan. Las reglas son simplemente buscadores de paquetes. Definen ciertos criterios para identificar paquetes y luego realizan alguna acción en esos paquetes. Las reglas de firewall funcionan en un director "si-entonces". "Si" un paquete coincide con sus criterios, "entonces" realice la siguiente acción en ellos.

El siguiente es un ejemplo de una nueva regla de filtro de firewall creada en la cadena de entrada.

 

Como puede ver, todavía no se ha seleccionado nada más que la cadena. Esta regla luego coincide con todos los paquetes que van al enrutador. En la siguiente ilustración, hemos comenzado el proceso de reducir los criterios de coincidencia de paquetes:

Esta regla ahora coincide con todos los tipos de paquetes, pero solo si provienen de (dirección src) de nuestra LAN privada. Agregar criterios adicionales reducirá aún más el alcance de esta regla. Esta es la parte "si" de la regla. 

A continuación, debemos especificar alguna acción que se tomará cuando un paquete coincida con la regla. Esto se hace en la pestaña Acción. Hemos seleccionado la acción predeterminada de "aceptar".

La acción de "aceptar" permite que el paquete ingrese al firewall. Esta regla, aunque de naturaleza muy simplista, permitirá que cualquier host en nuestra red LAN de 192.168.100.0/24 tenga acceso a todos los servicios en el enrutador. Lo único que se requiere para completar este firewall de entrada muy simple es una regla para eliminar el resto del tráfico que no proviene de nuestra LAN. La suposición aquí es que todo el tráfico de nuestra LAN es seguro y todo lo demás es malo, lo que no es una buena seguridad, pero es suficiente de momento. Para crear la regla de caída (drop), simplemente creamos una segunda regla de firewall que coincida con todo el tráfico, seleccionando solo la cadena input (de entrada) y nada más en la pestaña General y luego seleccionando la Accón drop.

Es importante saber que las reglas de firewall como casi todas las reglas en RouterOS se procesan en orden, de arriba abajo. Por lo tanto, si su regla de aceptación es anterior a su regla de descarte, todo funciona como se esperaba. Si pone su regla de caída primero, perderá el acceso a su enrutador.

En el ejemplo anterior, si colocamos una dirección de nuestra red LAN en nuestra computadora portátil, podremos administrar el enrutador mediante SSH, WinBox, FTP o HTTP. El enrutador no responderá a los pings de Internet público y no podremos acceder al enrutador desde fuera de nuestra LAN. 

Este es el primer bloque de construcción de un firewall. Una mejor "aceptación" reduciría aún más el rango de direcciones IP a las que se les permitirá administrar el enrutador solo a nuestra computadora portátil o solo a las IP utilizadas por el grupo de TI, etc. Además, es aconsejable permitir solo los protocolos y puertos que en realidad usará. Este es el tipo más seguro de firewall de entrada.

Si sigue el ejemplo anterior, puede notar que todo parece funcionar normalmente en lo que se refiere al acceso al enrutador, sin embargo, este firewall interrumpirá otros servicios que el enrutador proporciona a la LAN, como DNS, si está utilizando las instalaciones de almacenamiento en caché de DNS de RouterOS. Esto es normal.

Los firewalls de aprendizaje pueden ser muy frustrantes y complejos a menos que los divida en los bloques de construcción que componen un firewall y les enseñe estos bloques de manera progresiva. 

Conexiones

Ahora traeremos la siguiente pieza al rompecabezas del firewall, las conexiones, pero primero analicemos algunos conceptos básicos. La comunicación en redes se realiza mediante puertos; el dispositivo que envía el paquete envía el paquete desde un puerto (el puerto de origen) y el dispositivo receptor recibe el paquete en un puerto (puerto de destino). También se usan protocolos como TCP o UDP, pero por ahora limitemos nuestra discusión a los puertos. Estas combinaciones de puerto de origen y destino se mantienen constantes para cada conexión entre hosts. Nuestros datos se transmitirán a través de estas conexiones. Hay cuatro tipos de conexiones: nuevas, establecidas, relacionadas e inválidas. Comencemos con lo nuevo.

Generalmente, cada vez que un enrutador envía un paquete a un host por primera vez, abre una nueva conexión. En este escenario, estoy definiendo una nueva conexión como una combinación de origen/destino/puerto que nunca ha sido vista por ninguno de los hosts que participan en la comunicación. Origen será abreviado  como src y destino como dst. Una conexión solo es nueva cuando se inicia, y luego se considera como establecida a menos que se "perturbe" o se detenga y luego se vuelva a establecer como nueva. Entonces, ¿qué puede causar esta "perturbación"? Eso sería un paquete inválido. Un paquete no válido es uno que no pertenece a ninguna conexión conocida pero que no crea una nueva conexión. En resumen, los paquetes no válidos nunca son útiles y, por lo tanto, deben descartarse. Pueden ser creados por software malformado o con mal comportamiento o un posible intento de piratería.

Además de nuevas conexiones y conexiones establecidas, también hay conexiones relacionadas. La forma más fácil de comprender las conexiones relacionadas es pensar en ellas como lo que no son. No son nuevos porque están creados por una conexión que ya se ha visto como nueva, no son inválidos y no son parte de la conexión establecida, simplemente están relacionados con una conexión ya establecida.

Las reglas para entender aquí son:

Una conexión es nueva cuando cualquiera de los hosts que participan en la comunicación ve por primera vez su combinación src/dst/puerto.

Se establece una conexión en los paquetes que siguen al paquete que crea la nueva conexión. Sin permitir que se abra una nueva conexión, nunca se puede establecer o relacionar.

Esto es importante: las nuevas conexiones se convierten en los guardianes de las conexiones establecidas y relacionadas. Controla las nuevas conexiones y tú controlas todas las demás conexiones.

Una conexión no puede ser una conexión relacionada a menos que primero sea una conexión nueva. Las conexiones relacionadas no son nuevas ni están establecidas, pero son parte de una conexión establecida.

Las conexiones no válidas no son útiles y deberían descartarse.

En el diagrama anterior, puede ver varios estados de conexiones y las combinaciones posibles.

Comenzando con la primera línea, el primer paquete comienza la nueva conexión. Todos los siguientes paquetes son parte de una conexión establecida.

La segunda línea comienza con una conexión no válida, no es parte de ninguna conexión conocida y no es una conexión nueva. A continuación hay una nueva conexión, luego una conexión establecida. La conexión no válida "interrumpe" la conexión establecida y, por lo tanto, el siguiente paquete debe comenzar una nueva conexión.

La tercera línea comienza como la primera línea con una nueva conexión, y luego una conexión establecida, y luego genera una conexión relacionada. Ahora tenemos dos conexiones paralelas relacionadas entre sí.

La cuarta línea comienza como la primera pero termina con dos conexiones no válidas, el siguiente estado de conexión sería nuevo, ahora comprende los estados de conexión.

Dos formas de controlar el acceso

Hasta ahora, hemos discutido dos formas de controlar el acceso en la cadena de entrada. El primer método es simplemente filtrar cada paquete que ingresa al enrutador. Si pasa a través de nuestro filtro, está permitido, si no pasa, se descarta.

El segundo método es filtrar según el estado de la conexión. Si la conexión se encuentra en un cierto estado, acéptala, de lo contrario la desconectamos. Además, si una conexión está en estado no válido, simplemente la descartamos.

Para comprender cómo estos dos métodos funcionan juntos y son utilizados por un firewall RouterOS, considere el primer ejemplo con dos reglas de entrada. La primera regla permitía todo el tráfico de la red LAN. La segunda regla dejó caer todo lo demás. Si un host en la LAN intenta hacer ping al enrutador, recibirá una respuesta. Si el enrutador intenta hacer ping a un host en la LAN, nuevamente, recibirá una respuesta. 

Pero, ¿qué pasa si el enrutador intenta hacer ping a un host en la WAN? Si intenta esto, lo que encontrará es que el ping se agota. Puede preguntar por qué, ya que no estamos restringiendo que el enrutador haga nada, pero la respuesta es que aunque el enrutador crea y envía el paquete ping, no puede obtener una respuesta porque estamos bloqueando la cadena de entrada. Efectivamente, el enrutador no conoce el host que envía el paquete de respuesta, por lo que lo descarta.

Dado que el host que está haciendo ping en la WAN no está en la red LAN y, por lo tanto, no está permitido por la primera regla, la segunda regla lo descarta. 

Aquí es donde las conexiones de estado coinciden pueden salvar el día. Con los comparadores de estado de conexión, podemos suponer que si el enrutador mismo abre una conexión, es seguro permitir comunicaciones de retorno desde ese host para ese protocolo y para esa conexión. Ahora puede pensar en las conexiones como una calle de dos vías o una tubería. El tráfico fluye en ambas direcciones una vez que su enrutador abre esa tubería. Esto permite que el ping regrese del host al que fue enviado.

Asumimos aquí que no se pueden crear conexiones desde el enrutador a menos que las iniciemos, o permitimos que se inicien mediante el uso de protocolos que abren conexiones como el almacenamiento en caché de DNS. Esta es una suposición segura. El enrutador abre la nueva conexión y la devolución se maneja utilizando una regla de conexión establecida. Por lo tanto, solo se necesita una regla de conexión establecida en la cadena de entrada para que las conexiones desde cualquier lugar regresen al enrutador.

Entonces, volviendo al ejemplo con dos reglas de firewall, una para permitir paquetes desde la red LAN y otra para descartar todo lo demás. Al agregar una tercera regla, podemos permitir que nuestro enrutador haga ping o que realice búsquedas de DNS al permitir esa ruta de retorno a través de una regla de estado de conexión. Esta regla debe agregarse por encima de la regla drop y permitirá un estado de conexión establecido. Agregue una regla más como esta para los paquetes relacionados y esto resuelve el problema.

Pero ahora pregunta, ¿qué pasa con las nuevas conexiones? ¿No necesitamos una regla para permitirlas también? En este escenario, las nuevas conexiones solo se crean cuando hacemos algo como un ping desde el enrutador, de modo que se convierte en el control. La conexión de retorno cuando llega la respuesta del paquete de ping ahora está en el estado establecido (recuerde, las conexiones establecidas son aquellas que siguen una nueva conexión en virtud de sus combinaciones src/dst/puerto), por lo que nuestra regla de estado de conexión establecida permite la ruta de retorno. Obviamente, una regla de estado de conexión relacionada funciona de la misma manera y también es necesaria. El resultado final serán cuatro reglas en la cadena de entrada:

- Una regla acepta todo de la red LAN.

- Una regla acepta conexiones establecidas.

- Una regla para permitir todas las conexiones relacionadas. 

- Una regla para descartar todos los demás paquetes.

Puede agregar una regla para eliminar conexiones no válidas, pero eso sería redundante porque la regla 4 anterior elimina todo lo demás y eso incluye conexiones no válidas. El firewall de entrada ahora está completo y, por lo tanto, ha asegurado su enrutador.

Cadena forward

Como la cadena de entrada protege al enrutador, la cadena forward protege a los clientes. En esta declaración, me refiero a todos los hosts detrás del firewall como los clientes. El tráfico hacia y desde los hosts detrás del cortafuegos pasa a través de la cadena forward, y ahí es donde colocaremos nuestras reglas.

Los comparadores de estado de conexión son ideales para este trabajo. Considere . Desea crear reglas de filtro para permitir que los protocolos pasen a través de su firewall y descarten los intentos de piratería. 

Si la única herramienta en su caja de herramientas son las reglas de firewall que coinciden con el tráfico basado en la IP de origen y/o la IP de destino, en realidad tendría que escribir una regla para cada host en Internet al que desea permitir que sus clientes accedan y, una regla para cada camino de regreso! Obviamente, esto no es factible y los comparadores de puertos ayudan un poco. Por ejemplo, podría permitir todo el puerto 80 a través del firewall y eso ayuda mucho. Agregue el puerto 110, 443, etc., y seguramente estará en camino, pero ¿qué pasa con los protocolos y puertos que no anticipó? ¿Qué pasa con el escenario cuando su cliente quiere usar SSH en el puerto 22 o alguna otra aplicación nueva? Ahí es donde los emparejadores de conexiones pueden salvar el día una vez más y es por eso que enseño la cadena forward utilizando emparejadores de conexiones.

Aquí hay varios supuestos: Primero, que si un host en su red de área local abre una conexión a un host en el exterior del firewall, esa fue una operación prevista y usted, de manera predeterminada, les está permitiendo hacer eso. Segundo, recuerde que una vez que se abre la conexión, es una tubería de dos vías. El host ahora puede enviar datos al host externo y también se permitirá el flujo inverso. 

Al comprender los estados de conexión, podemos proteger a nuestros clientes detrás del firewall con solo unas pocas reglas simples. Estas reglas utilizarán coincidencias en función de los estados de conexión y permitirán que las conexiones se inicien solo desde la LAN, permitan la comunicación bidireccional a través del firewall para cada conexión abierta por los clientes de LAN y eliminen el resto del tráfico a través del firewall. Además, le permitirá agregar reglas adicionales para bloquear ciertos puertos y protocolos incluso si sus clientes LAN los inician.

La primera regla en nuestra cadena de forward (reenvío) permitirá a los clientes en la LAN crear nuevas conexiones a través del firewall. Dado que todos los estados de conexión comienzan como nuevas conexiones, al controlar la creación de nuevas conexiones, controlamos efectivamente todos los accesos a través del firewall. Para este propósito, podemos usar el emparejador de paquetes de dirección de origen en una regla de firewall para restringir la primera regla para que solo coincida con los paquetes que provienen de la LAN. Esto se puede hacer simplemente ingresando la dirección de red de la LAN en el "Src. Address ". 

Por ejemplo, si su red LAN es 192.168.100.0/24, ingrese esa dirección en el espacio en blanco en la pestaña General. A continuación, podemos usar el emparejador de estado de conexión para hacer coincidir las conexiones nuevas. Finalmente, la acción de aceptar permitirá que se acepten conexiones nuevas (New), provenientes de nuestra LAN.

Tenga en cuenta que solo si la dirección de origen está en la LAN se permitirá la conexión, por lo que los hosts en el lado WAN del enrutador no podrán abrir nuevas conexiones a través de nuestro firewall.

La siguiente regla permitirá conexiones relacionadas. Esta regla es menos restrictiva porque ya controlamos nuevas conexiones y restringimos secundariamente todas las demás conexiones a través de este control único. La segunda regla hace coincidir las conexiones "relacionadas" en la cadena hacia adelante con una acción de "aceptar".

La tercera regla es similar a la segunda y permite conexiones establecidas. Finalmente, dejamos caer las conexiones no válidas en la cadena forward y la arrastramos hacia la parte superior de la lista de reglas para que se procese primero.

Listas de direcciones

Mikrotik es genial!.