Cuando se administra una red ISP o WISP mediante MikroTik, FreeRADIUS y MariaDB permiten controlar qué usuario PPPoE se conecta, qué dirección IP recibe y durante cuánto tiempo permanece conectado. Sin embargo, esta información por sí sola no permite conocer todas las conexiones que posteriormente realiza ese abonado hacia Internet.
Para disponer de una trazabilidad mucho más completa podemos incorporar Graylog a la infraestructura y enviarle información de tráfico procedente del router MikroTik.
El objetivo de esta configuración será poder responder preguntas como:
¿Qué usuario PPPoE tenía la IP 10.50.0.25
el 11/08/2026 a las 10:32?
¿A qué dirección IP de Internet se conectó?
¿Qué puerto de destino utilizó?
¿Qué protocolo utilizó?
¿Qué traducción NAT realizó el MikroTik?
Graylog no sustituirá a FreeRADIUS ni a MariaDB, cada sistema tendrá una función diferente.
- FreeRADIUS realizará la autenticación y accounting de los usuarios PPPoE.
- MariaDB almacenará la relación entre usuario, sesión, dirección IP PPPoE, hora de inicio y hora de finalización.
- MikroTik conocerá las conexiones que atraviesan el router y realizará el NAT.
- Graylog centralizará, indexará y permitirá buscar las conexiones enviadas por MikroTik.
Esta separación es importante porque RADIUS Accounting está diseñado precisamente para registrar información de las sesiones suministrada por el NAS. La propia documentación de FreeRADIUS contempla eventos Accounting-Start y Accounting-Stop con atributos como usuario, identificador de sesión y NAS.
Activar RADIUS Accounting en MikroTik
Nuestro servidor PPPoE debe estar utilizando RADIUS.
Desde terminal podemos comprobarlo con:
/ppp aaa print
La configuración deberá tener habilitado:
use-radius: yes
accounting: yes
Si fuese necesario:
/ppp aaa
set use-radius=yes accounting=yes interim-update=5m
El parámetro:
interim-update=5m
hace que MikroTik envíe actualizaciones periódicas mientras la conexión permanece activa.
Esto resulta especialmente útil porque si un router se reinicia, existe un fallo eléctrico o se pierde un paquete Accounting-Stop, tendremos información reciente sobre la sesión.
En una infraestructura donde la trazabilidad sea importante no conviene depender exclusivamente de Start y Stop.
Opción principal: enviar IPFIX desde MikroTik a Graylog
Para este tipo de proyecto, IPFIX es normalmente la opción más interesante.
MikroTik incorpora Traffic Flow y permite exportar NetFlow versiones 1, 5 y 9, además de IPFIX. IPFIX puede incluir direcciones y puertos de origen y destino, protocolo, interfaces y, especialmente importante en nuestro escenario, información de NAT como nat-src-address y nat-src-port.
Graylog dispone actualmente de un input específico para IPFIX, por lo que puede recibir directamente este tipo de información. El input espera inicialmente las plantillas IPFIX transmitidas por el exportador antes de poder interpretar los registros.
Crear el Input IPFIX en Graylog
Entramos en Graylog y nos dirigimos a:
System>InputsCreamos un nuevo:
IPFIX UDP
Podemos utilizar, por ejemplo:
Title:
MikroTik IPFIX
Bind address:
0.0.0.0
Port:
4739
El puerto puede ser diferente siempre que coincida en ambos extremos.
Entramos en el Set-up Input para terminar la configuración
En este caso tiene sentido separar todo el tráfico IPFIX de MikroTik en un stream propio, por ejemplo:
Una vez terminado iniciamos el Input
Lanzamos el diagnostico para ver que este todo bien.
Volvemos a la pagina de input y vemos que ya esta corriendo:
La documentación actual de Graylog dispone tanto de inputs NetFlow como de un input específico IPFIX. El puerto 2055 es además uno de los puertos habitualmente utilizados para este tipo de exportación.
Debemos permitir UDP/4739 en el firewall del servidor Graylog únicamente desde las direcciones de nuestros routers.
Configurar Traffic Flow en MikroTik
Activamos Traffic Flow:
/ip traffic-flow
set enabled=yes interfaces=all
Ahora añadimos Graylog como destino.
/ip traffic-flow target
add dst-address=10.0.1.4 port=4739 version=IPFIX
MikroTik enviará entonces los flujos hacia Graylog. La documentación oficial especifica que los targets de Traffic Flow utilizan UDP y permiten seleccionar IPFIX como formato.
Qué campos IPFIX nos interesan
Para nuestro escenario conviene disponer, como mínimo, de:
src-address
dst-address
src-port
dst-port
protocol
first-forwarded
last-forwarded
nat-src-address
nat-src-port
in-interface
out-interface
packets
bytes
MikroTik permite incluir, entre otros, dirección IP origen y destino, puertos origen y destino, protocolo, interfaces y datos de traducción NAT.
Esto permite reconstruir una conexión aproximadamente como:
src-address:
10.50.0.25
src-port:
52341
nat-src-address:
80.30.40.50
nat-src-port:
41236
dst-address:
142.250.184.142
dst-port:
443
protocol:
TCP
porque si varios clientes comparten una misma dirección pública mediante NAT/PAT, el puerto traducido puede ser necesario para diferenciar las conexiones simultáneas.
Comprobar que Graylog está recibiendo IPFIX
Una vez arrancado el input, generamos tráfico desde uno de los clientes PPPoE.
Una limitación importante de Traffic Flow
Traffic Flow no registra necesariamente absolutamente todo el tráfico existente dentro del router.
MikroTik especifica que Traffic Flow solamente puede procesar tráfico que haya pasado por la CPU del router. Por tanto, determinados tráficos con hardware offloading pueden no aparecer.
En un escenario PPPoE y NAT donde el tráfico pasa por routing/conntrack, esto normalmente no representa el mismo problema que en tráfico puramente bridged con hardware offloading, pero debe tenerse en cuenta durante el diseño y las pruebas.
Nunca deberíamos asumir que existe trazabilidad completa sin comprobarlo previamente con tráfico real.
Segunda opción: registrar conexiones mediante firewall logging
La segunda posibilidad consiste en hacer que determinadas reglas del firewall de MikroTik generen logs, después enviamos esos logs mediante Syslog hacia Graylog.
RouterOS permite enviar los eventos del sistema a servidores Syslog remotos. Su documentación especifica soporte para Syslog RFC 3164; las versiones modernas de RouterOS también han incorporado CEF, aunque esta última opción requiere RouterOS 7.18 o superior y por tanto no podemos utilizarla como requisito base de un tutorial compatible desde RouterOS 7.10, por compatibilidad utilizaremos Syslog tradicional.
Crear un Input Syslog UDP en Graylog
En Graylog crearemos el input.
Graylog admite Syslog mediante UDP y TCP y puede interpretar mensajes compatibles con RFC 3164 y RFC 5424.
Configurar el destino remoto en MikroTik
Creamos una acción:
Ahora necesitamos decidir qué eventos enviaremos.
Crear una regla de firewall para registrar conexiones
Crearemos un log para todas las conexiones PPPoE tanto en TCP como en UDP.
Enviar los eventos firewall a Graylog
Añadimos la regla para mandar el trafico a Graylog.
A partir de ese momento los mensajes con topic firewall serán enviados al servidor.
Podemos comprobar primero:
/log print where topics~"firewall"
Y en el servidor Graylog:
sudo tcpdump -ni any udp port 1514
Si funciona veremos datagramas desde MikroTik.
Después buscamos en Graylog:
CLIENTESPPPOE
Qué podemos obtener mediante firewall logging
Un registro típico puede contener información similar a:
CLIENTESPPPOE forward:
in:pppoe-cliente001
out:ether1-WAN
src-mac ...
proto TCP
10.50.0.25:52341->142.250.184.142:443Graylog dispone precisamente de extractors para convertir partes de mensajes de texto recibidos en campos independientes que después pueden utilizarse en búsquedas.
Por ese motivo no utilizaría firewall logging masivo como mecanismo principal de registro de todas las conexiones de una red grande.
¿IPFIX o firewall logging?
Para este proyecto las diferencias principales serían:
| Característica | IPFIX | Firewall logging |
|---|---|---|
| IP origen | Sí | Sí |
| IP destino | Sí | Sí |
| Puerto origen | Sí | Sí |
| Puerto destino | Sí | Sí |
| Protocolo | Sí | Sí |
| Información NAT | Sí | Depende de dónde se registre |
| Bytes transmitidos | Sí | No de forma práctica |
| Paquetes | Sí | No de forma práctica |
| Inicio/final del flujo | Sí | Limitado |
| Formato estructurado | Sí | No siempre |
| Escalabilidad | Mejor | Peor |
| Facilidad inicial | Media | Alta |
| Carga del router | Normalmente menor | Puede ser elevada |
| Análisis de tráfico | Excelente | Limitado |
| Eventos específicos | Limitado | Excelente |
Para una red ISP/WISP, utilizaría:
IPFIX
=
registro principal de conexiones
y:
Syslog
=
eventos de firewall, administración y seguridad
Es decir, las dos tecnologías son complementarias y no excluyentes.
Configuración de retención de logs durante 1 año en Graylog
Esta configuración se realizó en Graylog 7.0.12 con el objetivo de conservar durante aproximadamente un año los registros almacenados en el Default index set. En este servidor se utiliza Data Tiering, que es el sistema actual de gestión de rotación y retención de índices de Graylog. Se decidió mantener este sistema en lugar de utilizar Legacy (Deprecated).
En System → Indices → Default index set → Edit → Rotation & Retention
se mantuvo seleccionada Data Tiering y se configuraron los siguientes valores:
Min. days in storage: 365
Max. days in storage: 366
El resultado mostrado por Graylog es:
Rotation strategy: Data Tiering
Min. in storage: 365 days
Max. in storage: 366 days
Eliminar trafico irrelevante
Podemos eliminar el trafico que no queremos que llegue a Geylog, como por ejemplo, el trafico DNS, IP locales que nos nos aporta nada, y algunas web que no queramos registrar.
Primero creamos las listas con las IP que no queremos registrar.
Después modificamos la regla de los log indicando que no queremos que se mande ni la lista que hemos creado ni el puerto 53, tenemos que hacerlo tanto en UDP como en TCP.
Con esto filtraremos bastante le trafico que no queramos registrar.
Cambiar hora Greylog
La hora con el usuario administrador es UTC, por lo que tendremos que crear un usuario con nuestra zona horaria.
