MANUAL: Mikrotik, tips & tricks


/ip firewall filter
add action=accept chain=input comment=letsencrypt-challenge-TO-DELETE \
dst-port=443 in-interface=NEXO protocol=tcp
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat in-interface-list=WAN protocol=tcp \
to-addresses=192.168.1.100 to-ports=5555
add action=dst-nat chain=dstnat in-interface-list=WAN protocol=tcp \
to-addresses=192.168.1.100 to-ports=46252
 
Si cambias el puerto en IP > Services para www-ssl, igualmente has de hacerlo en la regla de input que acepta dicho tráfico. Sino, manda export y lo vemos.

Saludos!
 
Si cambias el puerto en IP > Services para www-ssl, igualmente has de hacerlo en la regla de input que acepta dicho tráfico. Sino, manda export y lo vemos.

Saludos!
No me deja enviarte el export, lo identifica como spam, da igual que lo pegue como código que como texto normal. He intentado enviártelo por MP, pero ocurre lo mismo. Se puede adjuntar el .rsc descargado del Mikrotik?
 
Sí, renómbralo a .txt o hazle un zip.

Saludos!
 
Buenas de nuevo, pues sigo con el mismo problema, da igual los puertos que configure en "dst-nat" que ni se abren ni responden los equipos en la LAN. He estado revisando el export, pero no encuentro el fallo en las reglas del firewall, puede que sea un fallo del modelo? Este en concreto es un HAP AC3 LTE, suelo montar la versión sin LTE, pero ambos corriendo siempre la 7.1.5 long term. A ver si 2 cerebros ven mas que dos ojos xD Gracias de antemano! Export
 
Si tu conexión WAN es LTE, probablemente no puedas abrir puertos, porque tengas un CG-NAT encima y la IP que te entreguen sea privada, no pública. Ahí, por mucho que tu abras puertos en el NAT, de poco va a valer.

Saludos!
 
Si tu conexión WAN es LTE, probablemente no puedas abrir puertos, porque tengas un CG-NAT encima y la IP que te entreguen sea privada, no pública. Ahí, por mucho que tu abras puertos en el NAT, de poco va a valer.

Saludos!
Buenas @pokoyo , correcto! la sim es de Orange y no tiene ip pública. A veces uso Movistar, que sí tiene. Pero justamente la conexión LTE(default router distance = 2) la deshabilité para forzar la conexión por FTTH(default router distance = 1). He abierto incidencia al operador, aunque lego mediante ping a la IP pública que me entrega Masmóvil tras sacar la conexión de CGNAT.
 
Truco: Certificado SSL de let's encrypt para nuestro dominio DDNS cloud o cualquier otro dominio propio (sólo v7)
Se trata de que podamos sacar un certificado de let's encrypt para poder acceder al router de manera segura, usando https. Sigo sin recomendar abrir esto a internet, pero si no tenéis más remedio o queréis usar vuestro propio dominio y queréis que sea el router quien lo mantenga actualizado automáticamente, ahí va:
¡Qué maravilla de truco! Intenté varias veces aplicarlo hasta que salió el mensaje satisfactorio: succes. Casi morí en el intento :)

Gracias mil por ello.

Saludos
 
Os dejo por aquí un pequeño tip para los que lo necesitéis y que a mí me ha salvado en alguna ocasión: hacer los logs persistentes en memoria.

Por defecto, el log del Mikrotik es volátil y se borra tras un reinicio o un apagón. Si estamos cacharreando y tenemos que reiniciar y más adelante necesitamos consultar algún evento no podremos.

Vamos a hacer que se guarde un log en la memoria persistente y además los separaremos por Info, Error, Warning y Critical para que sea más fácil localizar lo que sea que estemos buscando.

Primero creamos una nueva Action que servirá como “plantilla” para crear luego la regla dentro de Rules.

001 - Template.png


El parámetro File Count indica que cuando el log se llene con las 10000 líneas que le establecimos, genere un nuevo archivo. Así, dará lugar a Warning0, Warning1, Warning2… Aquí cada uno que ponga los parámetros que le interese pero al menos pondría un File Count de 2 ya que si se pone 1 y se llena con el número de líneas establecido en Lines Per File, éste se borrará y volverá a empezar de nuevo. Con lo cual habría algunos momentos en los que tendríamos un log prácticamente vacío y no nos serviría para este propósito.

Repetimos lo mismo para Critical, Error e Info.


002 - logging.png


Ahora, en la pestaña Rules hacemos doble clic sobre cada línea y le indicamos que guarde cada Topic en su correspondiente archivo:

003 - Action.png



Y quedará así:

004 - Logging 2.png


Ahora tendremos en Files los ficheros correspondientes a cada uno. Así, en caso de necesitar revisar el log se puede exportar en txt y usar la herramienta "Buscar" del editor de texto para localizar lo que nos interese más rápido.

005 - File List.png


De todas formas, en el apartado LOG seguirán apareciendo todos los eventos como hasta ahora:

006 - Logs.png
 
Última edición:
Otro tip (o manual, lo que sea).

Si tenemos puertos abiertos en nuestro router siempre va a haber alguien escaneando cuáles son e intentando acceder por ellos mediante fuerza bruta.

Lo reconoceremos fácilmente en el log porque aparecerán marcados en rojo como Error. Me he tomado la molestia de tapar mi ip pública pero he dejado la del otro extremo que se intenta conectar. En este pantallazo provienen todas de EEUU pero me suelen aparecer de Cuba, de Brasil, etc.

001 - error log.png

Si no tenemos pensado salir al extranjero, lo más fácil y rápido es bloquear todas las peticiones entrantes (cadena INPUT) que no provengan de nuestro país (en nuestro caso, España). No eliminaremos el peligro de exponer puertos pero limitaremos el alcance del riesgo.

Accedemos a la web de IP2Location y descargamos una lista para Mikrotik que guardaremos con el nombre "firewall.txt" (sin comillas).


002 - ip2ltn.png

Abrimos el txt y cambiamos el encabezado por el comando

Código:
/ip/firewall/address-list

De manera que quede tal que así:

003 - Header.png


Guardamos y subimos el fichero al Mikrotik.

004 - Files.png


Abrimos un Terminal y ejecutamos

Código:
import file-name:firewall.txt

Tras unos segundos tendremos una lista dentro del apartado Firewall con todas las direcciones que acabamos de añadir.

005 - Address List.png


Ahora vamos a crear una regla para que todas las peticiones entrantes (para acceder al equipo, para conectar la vpn, etc) que provengan de fuera de España sean automáticamente rechazadas.

Código:
/ip firewall filter
add chain=input action=drop in-interface-list=WAN src-address-list=!IP2Location place-before=0 comment="Bloquea peticiones entrantes fuera de la lista de IP2Location"

En breve veremos cómo empieza el contador a subir.


En caso de que queramos actualizar la lista (recomendable hacerlo una vez al mes), lo más fácil es seleccionar la lista completa, borrarla e importar un nuevo fichero. No hará falta volver a meter la regla de firewall.

006 - Delete.png
 
Última edición:
El primer tip te lo compro @dremi, pero el segundo… diría que es mejor aclararlo.

Para el primero, comentar que hay que tener cuidado a la hora de escribir en disco, por dos razones: a menos que sea un equipo de los que lleva ranura para tarjeta de memoria SD o un pincho USB, la memoria de almacenamiento del resto de equipos es muy limitada, y escribir en disco la puede condenar en cero coma dos. Además no te vas a enterar hasta que el equipo de problemas de almacenamiento, normalmente durante una actualización. Además de lo anterior, la escritura en disco (en estos chismes o en cualquiera), es una operación lenta per sé, la cual quiere de CPU.

Para una ocasión donde necesitéis capturar unos logs y descargarlos, el tip es estupendo. Para tenerlo de continuo funcionando, merece la pena que miréis cómo volcar los logs a un servidor de logs. Cualquier NAS tiene esa opción (centro de registros se llama en synology) y la configuración es realmente sencilla:

Creáis una entrada para recibir logs del chisme que queráis
1661756379650.png


Y lo dais de alta en Mikrotik, tal que así:
1661756468169.png
1661756514861.png


En mi caso tengo duplicada la entrada de error, y los mensajes de ese topic van a parar al NAS también, pudiendo consultarse en la misma herramienta donde el propio NAS vuelca sus logs. Esto lo podéis hacer para múltiples cacharros, y así tener los logs centralizados.

Para el segundo tip, yo revisaría concienzudamente tu chain de input. Es probable que te puedas ahorrar disgustos simplemente restringiendo un poco más quién puede llegar a él. Y, si tienes que hacer un filtro como el que has descrito, el sitio correcto para hacerlo es la tabla raw, y su chain asociado: raw prerouting. Ahí puedes aplicar un filtro similar, y descartar los paquetes incluso antes de que lleguen siquiera al router, tan pronto entren por la interfaz WAN, descargando al equipo de la parte del connection tracking. Eso sí, mucho ojo con el raw prerouting, que no pregunta, y te quedas por menos de nada sin acceso al router, así que yo metería en lugar de una lista de permitidas, una lista de IPs prohibidas, y la regla le daría la vuelta: Las IPs chungas, ni las pasas al siguiente chain.


Si quieres que le echemos un vistazo a tu firewall en input, abre un post con el export, que lo miramos, a ver qué se puede hacer. Y, si no lo has hecho ya, te recomiendo pruebes Wireguard, en favor de cualquier tipo de IPSec. Son puertos UDP aleatorios, y ahí no hay dios que se lie a husmear.

Saludos!
 
El primer tip te lo compro @dremi, pero el segundo… diría que es mejor aclararlo.

Para el primero, comentar que hay que tener cuidado a la hora de escribir en disco, por dos razones: a menos que sea un equipo de los que lleva ranura para tarjeta de memoria SD o un pincho USB, la memoria de almacenamiento del resto de equipos es muy limitada, y escribir en disco la puede condenar en cero coma dos. Además no te vas a enterar hasta que el equipo de problemas de almacenamiento, normalmente durante una actualización. Además de lo anterior, la escritura en disco (en estos chismes o en cualquiera), es una operación lenta per sé, la cual quiere de CPU.

Para una ocasión donde necesitéis capturar unos logs y descargarlos, el tip es estupendo. Para tenerlo de continuo funcionando, merece la pena que miréis cómo volcar los logs a un servidor de logs. Cualquier NAS tiene esa opción (centro de registros se llama en synology) y la configuración es realmente sencilla:

Creáis una entrada para recibir logs del chisme que queráis
Ver el adjunto 98613

Y lo dais de alta en Mikrotik, tal que así:
Ver el adjunto 98616Ver el adjunto 98619

En mi caso tengo duplicada la entrada de error, y los mensajes de ese topic van a parar al NAS también, pudiendo consultarse en la misma herramienta donde el propio NAS vuelca sus logs. Esto lo podéis hacer para múltiples cacharros, y así tener los logs centralizados.

Para el segundo tip, yo revisaría concienzudamente tu chain de input. Es probable que te puedas ahorrar disgustos simplemente restringiendo un poco más quién puede llegar a él. Y, si tienes que hacer un filtro como el que has descrito, el sitio correcto para hacerlo es la tabla raw, y su chain asociado: raw prerouting. Ahí puedes aplicar un filtro similar, y descartar los paquetes incluso antes de que lleguen siquiera al router, tan pronto entren por la interfaz WAN, descargando al equipo de la parte del connection tracking. Eso sí, mucho ojo con el raw prerouting, que no pregunta, y te quedas por menos de nada sin acceso al router, así que yo metería en lugar de una lista de permitidas, una lista de IPs prohibidas, y la regla le daría la vuelta: Las IPs chungas, ni las pasas al siguiente chain.


Si quieres que le echemos un vistazo a tu firewall en input, abre un post con el export, que lo miramos, a ver qué se puede hacer. Y, si no lo has hecho ya, te recomiendo pruebes Wireguard, en favor de cualquier tipo de IPSec. Son puertos UDP aleatorios, y ahí no hay dios que se lie a husmear.

Saludos!

Jajajaja Me has desmontado todos mis argumentos.

Con el de los logs, nunca me había planteado que con estos ficheros de texto pudiese llegar a tener problemas porque se comiesen el espacio de almacenamiento o de rendimiento porque sea lenta la escritura. Pero siempre se aprende algo

Y la de las listas de ip2location la verdad que fue la manera rápida de solucionar un problema en su día. Actualmente no lo tengo activado por la integración de NordVPN en el router. Pero si veis que no es seguro ni recomendado, borramos el mensaje (o lo metemos en un hide) para que nadie se meta en líos por usarlo. Sin problema!

De todas formas, me apunto el tip de volcar el log al Synology jejeje. Wireguard lo tengo en mi lista de tareas pendientes (de momento sigo con mi l2tp IPsec hasta que encuentre un rato libre para trastear).

Y ya para abusar, cuando encuentre otro rato, acepto el ofrecimiento de revisar el firewall jeje (Pero mira a qué horas suelen ser mis mensajes y verás los pocos huecos que tengo jajajaja)

Eres un fenómeno, @pokoyo
 
Jajajaja Me has desmontado todos mis argumentos.

Con el de los logs, nunca me había planteado que con estos ficheros de texto pudiese llegar a tener problemas porque se comiesen el espacio de almacenamiento o de rendimiento porque sea lenta la escritura. Pero siempre se aprende algo

Y la de las listas de ip2location la verdad que fue la manera rápida de solucionar un problema en su día. Actualmente no lo tengo activado por la integración de NordVPN en el router. Pero si veis que no es seguro ni recomendado, borramos el mensaje (o lo metemos en un hide) para que nadie se meta en líos por usarlo. Sin problema!

De todas formas, me apunto el tip de volcar el log al Synology jejeje. Wireguard lo tengo en mi lista de tareas pendientes (de momento sigo con mi l2tp IPsec hasta que encuentre un rato libre para trastear).

Y ya para abusar, cuando encuentre otro rato, acepto el ofrecimiento de revisar el firewall jeje (Pero mira a qué horas suelen ser mis mensajes y verás los pocos huecos que tengo jajajaja)

Eres un fenómeno, @pokoyo
Si usas L2TP, hay una manera más eficiente de hacer eso: sólo aceptar tráfico L2TP que venga ya encriptado (policy=in-ipsec). Vas a seguir teniendo los timbrazos al puerto 500 UDP del IPSec, pero nadie llegará al L2TP, al no pasar de fase. Pruébalo y me dices.

Saludos!
 
En mi cabeza pensaba que estaba bloqueando IP maliciosas usando un script del post de scripts... pero la verdad es que no lo veo en la configruacion...


Veo las listas, pero no veo ninguna regla o confifg de bloqueo... no veo nada en la tabla raw o incluso alguna regla tirando de la address lists...
 
En mi cabeza pensaba que estaba bloqueando IP maliciosas usando un script del post de scripts... pero la verdad es que no lo veo en la configruacion...


Veo las listas, pero no veo ninguna regla o confifg de bloqueo... no veo nada en la tabla raw o incluso alguna regla tirando de la address lists...
Simplemente haz un drop de esa lista. La miga del script es el rellenar las listas, no la regla de bloqueo como tal, que no difiere de cualquier otra.

Saludos!
 
En mi cabeza pensaba que estaba bloqueando IP maliciosas usando un script del post de scripts... pero la verdad es que no lo veo en la configruacion...


Veo las listas, pero no veo ninguna regla o confifg de bloqueo... no veo nada en la tabla raw o incluso alguna regla tirando de la address lists...

Si tu lista de direcciones IP se llama por ejemplo "blacklist", puedes crear esta regla en RAW.

Código:
/ip firewall raw
add action=drop chain=prerouting src-address-list=blacklist

S@lu2.
 
Una pregunta, referente al script para detectar nuevos clientes conectado.

Sabéis si en ROS 7.X (7.5 específicamente) ha cambiado algo en la sintaxis, referente a la siguiente consulta?

Código:
/ip dhcp-server lease
:if (($leaseBound=1) && ([/ip dhcp-server lease find where dynamic mac-address=$leaseActMAC]!="")) do= {
:do {
<...>
}

Consultando en el siguiente enlace, las variables globales son correctas:
 
Última edición:
Arriba