Bloquear DNS abierto desde Mikrotik

Tenemos un miembro que utiliza microtik (MT) y tenía varios reportes de dns openresolver. Un DNS abierto.

Sugerimos en la pantalla de configuración de DNS (DNS Settings) desactivar el checkbox referente a permitir peticiones remotas (Allow Remote Requests):

Con este cambio estamos impidiendo que el servidor de DNS acepte peticiones provenientes desde Internet hacia la WAN del Mikrotik.

Con esto es suficiente para bloquear las peticiones desde internet al equipo.


Otras instituciones lo solucionaron de la siguiente forma:

El administrador tomó una medida muy sabia, que es el bloquear el puerto 53/UDP entrante como indicamos en este mismo sitio. Lo hizo así:

/ip firewall filter add action=drop chain=input comment=»Bloqueo DNS cache externo» disabled=no dst-port=53 in-interface=ether1 protocol=udp

¡Sin embargo el problema persistía! Nos ponemos a conversar, validando todo. Efectivamente la anterior regla está bien sintácticamente. Esta regla lo que hace es bloquear el puerto 53/UDP para paquetes que entran al equipo MT. Es decir, si el MT corre un servidor de DNS, le bloquea perfectamente el acceso.

Sin embargo seguía siendo un opendns (la IP ha sido cambiada para mantener la privacidad):

[eperez@eperez-cedia ~]$ host www.google.com 1.2.3.4
Using domain server:
Name: 1.2.3.4
Address: 1.2.3.4#53
Aliases:

www.google.com has address 181.198.80.174
www.google.com has address 181.198.80.56
www.google.com has address 181.198.80.135
www.google.com has address 181.198.80.213
www.google.com has address 181.198.80.251
www.google.com has address 181.198.80.96
www.google.com has address 181.198.80.57
www.google.com has address 181.198.80.173
www.google.com has address 181.198.80.95
www.google.com has address 181.198.80.212
www.google.com has address 181.198.80.18
www.google.com has address 181.198.80.134
www.google.com has IPv6 address 2800:3f0:4005:403::2004

Le pregunto si por casualidad está reenviando (forward) el puerto 53/udp hacia otra IP. ¡Y eso era! El servidor de DNS no estaba en el MT sino en un equipo dentro de la red al que se reenviaban las peticiones al puerto 53/UDP

Así que cambió la regla por la siguiente:

/ip firewall filter add action=drop chain=forward comment=»Bloqueo DNS cache externo» disabled=no dst-port=53 in-interface=ether1 protocol=udp

Si te fijas, cambia el input (que es lo que entra al MT) por forward que es lo que atraviesa al MT y pasa de una interfaz a otra.

Problema arreglado:

[eperez@eperez-cedia ~]$ host www.google.com 1.2.3.4
;; connection timed out; no servers could be reached

Como comentarios finales, este mismo procedimiento puede ser utilizado para cualquier otro puerto (ntp, snmp, tftp, etc) que se necesite cerrar. Si es un servicio que corre en el mismo MT, se utiliza input, si es un puerto que se reenvía a otro lugar, se usa forward.

Efectivamente: otra variante sería dejar de reenviar el puerto, pero por alguna razón interna no podían hacerlo, por eso adoptaron esta medida.