| | |

Recopilar los registros del firewall de Mikrotik en la base de datos.

Buenas tardes 

Quiero decirle cómo puede configurar fácil y fácilmente el servidor de recopilación de metadatos de tráfico de red para los enrutadores Mikrotik. 

Propósito: El objetivo será almacenar los registros del servidor de seguridad «masticados» en la base de datos para su posterior análisis. 

Medios: Cualquier nueva distribución de Linux con rsyslogd v8 y superior será adecuada para la implementación; tal vez la sintaxis propuesta funcione en v7. También necesitamos un DBMS, elegí mariadb. El crecimiento de la base de datos variará en función del número de reglas de diario, ya que el tamaño de la unidad es a su criterio, en mi caso se registran 30-40 reglas, que son aproximadamente 1200 mil líneas por día. Para el mes de uso de la base de datos, incluidos los índices, ha crecido a 3.8 GB. 

Mecánica:El enrutador envía un registro al servidor remoto a través de UDP. El servidor rsyslog con la ayuda de expresiones regulares borra las líneas de información innecesaria, forma el inserto de SQL y lo envía al DBMS. El DBMS, con la ayuda de un activador antes de la inserción, realiza una limpieza y separación adicionales de los campos que no se pudieron analizar en rsyslog.

Personaliza el RSYSLOG

Edite el archivo /etc/rsyslog.conf 
Agregue las siguientes líneas allí:

module(load="ommysql")
module(load="imudp")
input(type="imudp" port="514")

De este modo cargamos los módulos necesarios y abrimos el puerto 514 UDP. 

La línea de registro de Mikrotik se ve así:

20180927155341  BLOCKSMKNETS forward: in:ether6 - LocalTORF out:VLAN55 - RT_INET, src-mac 00:15:17:31:b8:d7, proto TCP (SYN), 192.168.0.234:2457->192.168.6.14:65535, len 60

Como puede ver, hay una gran cantidad de almacenamiento en exceso en la base de datos y una selección coherente será difícil. 
En teoría, necesito agregar tales datos:

20180927155341 ether6 VLAN5 192.168.0.234 2457 192.168.6.14 65535 00:15:17:31:b8:d7 TCP forward BLOCKSMKNETS 60

No pude obtener esa línea usando solo un rsyslog. El uso regular de rsyslog POSIX ERE / BRE, por lo tanto, no hay posibilidad de aplicar características tales como lookahead o look beind. 

Hay una herramienta que le permite depurar a los usuarios habituales, intente tal vez pueda separar el puerto de la dirección, así como el nombre de la interfaz de entrada y salida:. Solo tenga en cuenta que faltan algunos protocolos de deportes y deportes. 

En general, mi salida fue:

20180927155341 in:ether6 out:VLAN5 192.168.0.234:2457 192.168.6.14:65535 00:15:17:31:b8:d7 TCP forward BLOCKSMKNETS 60

Hay documentación sobre cómo preparar rsyslog regulares. 

En la forma final, el archivo de configuración de recepción de registro de Mikrotik /etc/rsyslog.d/20-remote.conf se verá así:

$template tpl_traflog,"insert into traflog.traffic (datetime, inif, outif, src, dst, smac, proto, chain, logpref, len) values ('%timereported:::date-mysql%', '%msg:R,ERE,0,BLANK,0:in:[a-zA-Z]+[0-9]+|in:<[a-zA-Z]+-[a-zA-Z]+>--end%', '%msg:R,ERE,0,BLANK,0:out:[a-zA-Z]+[0-9]+|out:<[a-zA-Z]+-[a-zA-Z]+>--end%', '%msg:R,ERE,0,BLANK,0:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end%', '%msg:R,ERE,0,BLANK,1:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end%', '%msg:R,ERE,0,BLANK:([0-f]+:){5}[0-f]+--end%', '%msg:R,ERE,0,DFLT:\b[A-X]{3,4}\b--end%', '%msg:R,ERE,0,BLANK:[a-x]+--end%', '%msg:F,32:2%', '%msg:R,ERE,0,BLANK:[0-9]+$--end%' )",SQL
if ($fromhost-ip == '192.168.0.230') then {action(type="ommysql" server="localhost" serverport="3306" db="traflog" uid="rsyslogger" pwd="..." template="tpl_traflog") stop}

En la primera línea de la descripción de la plantilla (plantilla): una cadena de código SQL para transferirla a la base de datos. 
La segunda línea es la condición en que se llevará a cabo la acción, es decir, el registro en el DBMS. 
La condición se ve así: si la fuente del registro = 192.168.0.230 ( if ($fromhost-ip == '192.168.0.230')), luego use el módulo ommysql con los parámetros de conexión ( then {action(type="ommysql" server="localhost" serverport="3306" db="traflog" uid="rsyslogger" pwd="..." ), llame a la plantilla tpl_traflog ( template="tpl_traflog")), y luego deje de seguir procesando la línea ( stop}). 

Es posible que algo salga mal en su caso, puede estar relacionado con los nombres de las interfaces o los prefijos de los registros, tal vez algo más. Para depurar, hagamos lo siguiente, comente la segunda línea, agregue una nueva plantilla y dos nuevas condiciones:

$template tpl_traflog_test,"'%timereported:::date-mysql%', '%msg:R,ERE,0,BLANK,0:in:[a-zA-Z]+[0-9]+|in:<[a-zA-Z]+-[a-zA-Z]+>--end%', '%msg:R,ERE,0,BLANK,0:out:[a-zA-Z]+[0-9]+|out:<[a-zA-Z]+-[a-zA-Z]+>--end%', '%msg:R,ERE,0,BLANK,0:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end%', '%msg:R,ERE,0,BLANK,1:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end%', '%msg:R,ERE,0,BLANK:([0-f]+:){5}[0-f]+--end%', '%msg:R,ERE,0,BLANK:\b[A-X]{3,4}\b--end%', '%msg:R,ERE,0,BLANK:[a-x]+--end%', '%msg:F,32:2%', '%msg:R,ERE,0,BLANK:[0-9]+$--end%' "
if ($fromhost-ip == '192.168.0.230') then {action(type="omfile" file="/var/log/remote/192.168.0.230.log" )}
if ($fromhost-ip == '192.168.0.230') then {action(type="omfile" file="/var/log/remote/192.168.0.230.log" template="tpl_traflog_test" ) stop}

Reinicie el registrador. 

La plantilla tpl_traflog_test es similar a tpl_traflog pero sin SQL INSERT. 

La primera condición agrega la línea no procesada% msg% al archivo /var/log/remote/192.168.0.230.log. 

La segunda condición agrega la cadena procesada al mismo archivo. Así que será más conveniente comparar. 
A continuación, prepare la base de datos.

Preparando la base de datos

La configuración del DBMS se omite, todo es estándar aquí. 

Iniciamos la consola mysql y ejecutamos el siguiente código:


create database traflog character set utf8 collate utf8_bin;
use traflog;


create table traffic (id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
datetime DATETIME,
inif VARCHAR(20),
outif VARCHAR(20),
src VARCHAR(21),
sport INT(5),
dst VARCHAR(21),
dport INT(5),
smac VARCHAR(17),
proto VARCHAR(4),
chain VARCHAR(8),
logpref VARCHAR(24),
len INT(5)) ENGINE=MYISAM;


create user rsyslogger@localhost identified by '...';
grant all privileges on traflog.* to rsyslogger@localhost;

La mesa está lista, el usuario está. 

Ahora agregamos un disparador, hará lo que el registrador falló, separará la dirección del puerto y los nombres de las interfaces:


DELIMITER //
create TRIGGER delim_ip_port BEFORE insert ON traffic
FOR EACH ROW
begin
set NEW.inif = REGEXP_REPLACE ((NEW.inif), 'in:', '' );
set NEW.outif = REGEXP_REPLACE ((NEW.outif), 'out:', '' );
set NEW.sport = REGEXP_REPLACE ((NEW.src), '([0-9]+\.){3}[0-9]+:|([0-9]+\.){3}[0-9]+', '' );
set NEW.src = REGEXP_REPLACE ((NEW.src), ':[0-9]+', '' );
set NEW.dport = REGEXP_REPLACE ((NEW.dst), '([0-9]+\.){3}[0-9]+:|([0-9]+\.){3}[0-9]+', '' );
set NEW.dst = REGEXP_REPLACE ((NEW.dst), ':[0-9]+', '' );
end //
delimiter ;

REGEXP_REPLACE busca el segundo parámetro de coma posterior (regular) y lo reemplaza por el tercer parámetro, en nuestro caso no hay nada entre comillas, por lo que simplemente elimina lo que encontró. 

Hagamos una inserción de prueba, de la misma manera que lo haría un registrador:


insert into traffic (datetime, inif, outif, src, dst, smac, proto, chain, logpref)
values (20180730075437, 'in:ether6', 'out:VLAN55', '192.168.0.234:4997', '192.168.6.18:65535', '00:15:17:31:b8:d7', 'TCP', 'forward', 'BLOCKSMKNETS');

A ver que paso

select * from tarffic;

Si todo es correcto, entonces adelante. Si no, busca cuál es el error. 

Añade al menos un índice. No soy un asistente para crear índices, pero como entendí, en mysql para diferentes consultas es más correcto usar índices con diferentes campos de unión, ya que una consulta puede usar solo un índice (¿o me equivoco?). Si lo entiendes, hazlo a tu discreción. Por ejemplo, eso es suficiente:


create index traffic_index on traffic (src, dst, dport, datetime);

Esta hecho 

Ahora debe comenzar a enviar en el enrutador, agregar la configuración del servidor de registro remoto y la acción, agregar la opción de registro a una de las reglas del firewall, agregar el prefijo de no más de 24 caracteres. 

En la micro consola, se ve así:

/system logging action
set 3 remote=192.168.0.94 src-address=192.168.0.230
add name=remote2 remote=192.168.0.19 syslog-facility=local6 target=remote
/system logging
add action=remote topics=error,account,critical,event,info
add action=remote2 topics=firewall

/ip firewall filter
...
add action=drop chain=input comment="drop ssh brute forcers" dst-port=22,8291 log=yes log-prefix=DROP_SSH_BRUTE protocol=tcp src-address-list=ssh_blacklist
...

Donde 192.168.0.230 es la dirección del enrutador, 192.168.0.19 es la dirección del registro del servidor para los registros del firewall, y 192.168.0.94 es un servidor de registro diferente, mis registros del sistema micrótico caen allí, no lo necesitamos ahora. Nuestra configuración es remota2. 

Más mirada que cae en el archivo:

tail -f /var/log/remote/192.168.0.230.log

Las líneas del enrutador se deben esparcir en el archivo, a menos que, por supuesto, su regla funcione con la frecuencia suficiente. 

Si no hay suficientes campos, es decir, no se observa la fecha, inif, outif, src, dst, smac, proto, chain, logpref, len, puede intentar cambiar el parámetro en las plantillas de depuración del registrador, reemplazando BLANK con DLFT. Luego, en lugar del vacío de cualquier campo, aparecerán algunas letras, no recuerdo cuáles ya. Si esto sucede, entonces algo está mal con la temporada regular y debe corregirse. 

Si todo fue como debería, deshabilite las condiciones de prueba y la plantilla. 

Además, la configuración predeterminada en /etc/rsyslog.d/ debe reducirse a continuación, cambié su nombre a 50-default.conf, para que los registros remotos no se vuelquen en el registro del sistema / var / log / message 
Reiniciar el registrador.

Esperemos un poco hasta que nuestra base de datos esté llena. Entonces podemos empezar la muestra. 

Algunas consultas por ejemplo:

Para ver el tamaño de la base de datos y el número de filas:

MariaDB [traflog]> select table_schema as "database", round(sum(data_length + index_length)/1024/1024,2) as "size Mb", TABLE_ROWS as "count rows" from information_schema.tables group by table_schema;        +--------------------+---------+------------+
| database           | size Mb | count rows |
+--------------------+---------+------------+
| information_schema |    0.17 |       NULL |
| traflog            | 3793.39 |   21839553 |
+--------------------+---------+------------+
2 rows in set (0.48 sec)

A lo largo del mes, casi 4 GB han crecido, pero depende del número y las propiedades de las reglas de firewall registradas.

 

Número de prefijos registrados

El número de prefijos registrados no es igual al número de reglas, algunas reglas funcionan con un prefijo, pero ¿cuántos prefijos en total? ¿Y cuántas reglas se elaboran para ellos ?:

MariaDB [traflog]> select logpref,count(logpref) from traffic group by logpref order by count(logpref) desc;
+----------------------+----------------+
| logpref              | count(logpref) |
+----------------------+----------------+
| ACCEPT_TORF_INET     |       14582602 |
| ACCEPT_SMK_PPP       |        1085791 |
| DROP_FORWARD_INVALID |         982374 |
| REJECT_BNK01         |         961503 |
| ACCEPT_MMAX_TORF     |         802455 |
| ACCEPT_TORF_PPP      |         736803 |
| SMTP_DNAT            |         689533 |
| ACCEPT_SMK_INET      |         451411 |
| ACCEPT_INET_TORF     |         389857 |
| BLOCK_SMKNETS        |         335424 |
| DROP_SMTP_BRUTE      |         285850 |
| ACCEPT_ROZN_TORF     |         154811 |
| ACCEPT_TORF_MMAX     |         148393 |
| DROP_ETHALL_ETHALL   |          80679 |
| ACCEPT_SMTP          |          48921 |
| DROP_SMTP_DDOS       |          32190 |
| RDP_DNAT             |          28757 |
| ACCEPT_TORF_ROZN     |          18456 |
| SIP_DNAT             |          15494 |
| 1CWEB_DNAT           |           6406 |
| BLOCKSMKNETS         |           5789 |
| DROP_SSH_BRUTE       |           3162 |
| POP_DNAT             |           1997 |
| DROP_RDP_BRUTE       |            442 |
| DROP_BNK01           |            291 |
| DROPALL              |            138 |
| ACCEPT_RTP_FORWARD   |             90 |
| REJECT_SMTP_BRUTE    |             72 |
| L2TP_INPUT_ACCEPT    |             33 |
+----------------------+----------------+
29 rows in set (2 min 51.03 sec)

ACCEPT_TORF_INET está a la cabeza, con este prefijo puede encontrar a todas las personas que accedieron a Internet desde nuestra red local, los protocolos y los puertos están registrados, llegará el momento y el acceso estará cerrado para algunas personas. Hay datos de referencia para el trabajo futuro en los errores.

 

Líder smtp tyka

Veamos quién intentó acercarse al servidor smtp hoy:

MariaDB [traflog]> select src,count(dport) from traffic where logpref='SMTP_DNAT' and datetime > '2018101600000000' group by src order by count(dport) desc limit 10;
+----------------+--------------+
| src            | count(dport) |
+----------------+--------------+
| 191.96.249.92  |        12440 |
| 191.96.249.24  |         4556 |
| 191.96.249.61  |         4537 |
| 185.255.31.122 |         3119 |
| 178.57.79.250  |          226 |
| 185.36.81.174  |          216 |
| 185.234.219.32 |          211 |
| 89.248.162.145 |           40 |
| 45.125.66.157  |           32 |
| 188.165.124.31 |           21 |
+----------------+--------------+
10 rows in set, 1 warning (21.36 sec)

Claramente, el nudo 191.96.249.92 es el ganador de hoy. Echemos un vistazo a lo que las reglas registradas, todavía se calculó:

MariaDB [traflog]> select src,dport,count(dport),logpref from traffic where src='191.96.249.92' group by logpref order by count(dport) desc;
+---------------+-------+--------------+-----------------+
| src           | dport | count(dport) | logpref         |
+---------------+-------+--------------+-----------------+
| 191.96.249.92 |    25 |       226989 | SMTP_DNAT       |
| 191.96.249.92 |    25 |       170714 | DROP_SMTP_BRUTE |
| 191.96.249.92 |    25 |         2907 | DROP_SMTP_DDOS  |
| 191.96.249.92 |    25 |         2061 | ACCEPT_SMTP     |
+---------------+-------+--------------+-----------------+
4 rows in set (10 min 44.21 sec)

Esto se especializa solo en smtp, ~ 1% de los aciertos para intentar adivinar una contraseña o intentar enviar algo de basura, el resto fue a la casa de baños. 

La solicitud se formó 10 minutos es mucho, los índices actuales no son adecuados para él, o puede reformular la solicitud, pero ahora no hablaremos de ello.

En el futuro, está previsto vincular la interfaz web con formularios y solicitudes de muestra. 
El vector está establecido, espero que este artículo sea de utilidad. 

¡Gracias a todos! 

Referencias: documentación de 

rsyslog 
Documentación para mysql 
Documentación para el registro de Mikrotik

Publicaciones Similares

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *