Syslog

De CiberWiki
Revisión del 11:25 6 ago 2023 de Jcorletti (discusión | contribs.) (Página creada con «En esta entrada vamos a hablar un poco de cómo funciona el tema del login. No nos vamos a basar en el sistema y Glock de Yonic's, sino que vamos a trabajar con capturas de tráfico a través de Wireshark. Después vamos a trabajar con dos máquinas diferentes; una es la Raspberry que vimos <strong> la entrada sobre INSERTAR ENTRADA</strong>, que están viendo en la interfaz de comandos con IP 192.198.1.220 y la otra es una máquina virtual donde hemos instala…»)
(difs.) ← Revisión anterior | Revisión actual (difs.) | Revisión siguiente → (difs.)

En esta entrada vamos a hablar un poco de cómo funciona el tema del login. No nos vamos a basar en el sistema y Glock de Yonic's, sino que vamos a trabajar con capturas de tráfico a través de Wireshark. Después vamos a trabajar con dos máquinas diferentes; una es la Raspberry que vimos la entrada sobre INSERTAR ENTRADA, que están viendo en la interfaz de comandos con IP 192.198.1.220 y la otra es una máquina virtual donde hemos instalado previamente OSSIM. Esta se visualiza desde una conexión SSH, por lo que nos quedarán dos máquinas: esta OSSIM y la Raspberry conectada a través de Kali. Vamos a generar un sistema de logs en local en la Raspberry. Vamos a ver cómo se hace para poder exportar los logs de la Raspberry al servidor centralizador.


Importancia de exportar logs y evitar la eliminación por intrusos.


En este caso, desde el proyecto de OSSIM, vamos a ver cómo se visualizan los logs que son exportados desde nuestra Raspberry; ¿por qué es muy importante esto? Ya lo hablamos en el webinar anterior, cuando hablamos del comando NTP de Network Time Protocol. Recordar que cuando un intruso toma posesión de una máquina, por ejemplo, de esta Raspberry, si logra escalar privilegios, lo primero que va a hacer es borrar todas sus huellas para que no quede rastro de lo que hizo, y no podamos estudiar lo que ha hecho. Entonces, cuando uno genera los logs en una máquina y solo los deja local, se expone a que un intruso los borre y perdamos toda la huella de lo que ha sucedido. Por eso, siempre en una arquitectura de red de TI, es muy importante que los dispositivos críticos de mi infraestructura exporten los logs a un servidor central. De esta manera, si un intruso toma posesión de esa Raspberry que tengo acá, por más que borre los logs en local, yo voy a tener todos esos registros en mi servidor central.

Vamos a aguantar un poco de base teórica. La base teórica la vamos a sustentar en este libro, que es el libro Seguridad en Redes. Recordar que en la página web www.darfe.es, tienen los cuatro libros gratuitos que pueden descargar en formato electrónico pinchando directamente los enlaces de la página web. Entonces, hoy el tema de Syslog está desarrollado sobre este libro "Seguridad en Redes", que es el segundo libro libro publicado por Alejandro Corletti. Acá vamos a ver un poco la base teórica y después los vídeos. Recordar que están en nuestro canal de YouTube, y si se suscriben al canal, los mantendré informados de todas las publicaciones, libros y vídeos que van saliendo.

Dentro de "dar fe" en la parte de redes y TI, aquí tienen toda la secuencia de vídeos que son muchos sobre temas de seguridad. Y acá está todo el seminario de 5G, y este último que está subido aquí porque justamente es el del protocolo Network Time Protocol,que es el que os invito a que veáis antes de meternos ahora con Syslog.

Facilidades y prioridades en el sistema Syslog

Empecemos con la teoría en el libro que acabáis de ver sobre seguridad en redes. Es el punto 96, nos describe de qué trata este sistema de syslog. Acordaros de que los eventos de Windows, no quiero ser tan tendencioso, pero es reconocido que todo el sistema de registros de eventos de Windows ha sido tomado como base. Lo que estamos viendo aquí es el sistema de syslog, que es anterior a todos los despliegues de Windows.

El sistema de syslog en realidad se basan en dos grandes cosas: las facilidades, que es la aplicación de la cual proviene ese registro, y la gravedad, que es la criticidad. Entonces, siempre vamos a hablar de facilidades y prioridades. La facilidad de sonar auth, cron, daemon, ftp, kernel, mail, etcétera (lo tenéis en el libro) y las prioridades de mayor a menor. Empezamos con lo que son emergencias, alertas, críticas, errores, etcétera.

Tenemos siete prioridades y un montón de facilidades. Inclusive estas locales 0 a 7 que las puedo configurar yo como quiera en el sistema Syslog. Entonces, tiene una sintaxis que pueden dar una miradita acá, como dice en el libro, con un asterisco, etcétera. Cada... En general, por default, los directorios de Syslog se guardan en el directorio /var/log. Dentro de ellos, los típicos son messages, kern.log, auth.log, etcétera. Bueno, en el libro entonces, la base teórica la tienen acá. Por default, los sistemas Linux y Unix ya vienen con este gran daily. Si miran, lo pueden ver acá en el directorio /etc y el fichero syslog.conf. Acá es como se decide toda la lógica para que semanalmente, mensualmente, se vayan comprimiendo y rotando el sistema de logs, por cuánto tiempo se almacenan, etcétera.


Visualización y análisis de logs en la máquina virtual y Raspberry


Lo que me interesa es cómo vamos a trabajar de forma práctica con nuestro fichero syslog. Acá nos habla de syslog-ng, no sólo vamos a jugar con el rsyslog. Entonces, ¿qué es lo que yo tengo definido? Vamos a empezar desde nuestra máquina virtual en Entornos, desde nuestra máquina física Raspberry, que es esta que están viendo en la pantalla.

Si yo me voy al directorio /etc, a partir de acá puedo ver el syslog.conf, El fichero, como todo fichero Linux, lo que está comentado son comentarios. Las cuestiones en almohadillas son comentarios. Y siempre, por defecto, suele ser muy detallado. La explicación de cada una de las formas, darle una mirada y una estudiada. ¿Qué es lo que más me interesa que vean? Ahí tenemos toda la estructura de los logs. Acá está la prioridad de mente. El valor cero es el más alto, para emergencia. El 7 es el más bajo.

Lo que me interesa es cómo vamos a trabajar de forma práctica con nuestro fichero syslog. Acá nos habla de Syslog, nosotros vamos a jugar con el fichero rsyslog, el remote syslog. Entonces, ¿qué es lo que yo tengo definido? Bueno, vamos a empezar desde nuestra máquina física Raspberry. entornos, desde nuestra máquina física rápida que es esta que están viendo en LA IMAGEN. Si yo me vengo acá al directorio cd/etc/ a partir de acá puedo ver el "rsyslog.com". El fichero, como todo fichero Linux, lo que está comentado son comentarios, las cuestiones en almohadillas son comentarios y siempre, por defecto, suele ser muy detallada la explicación de cada una de las formas, dadle una mirada y una estudiada. ¿Qué es lo que más me interesa que vean? Ahí tenemos toda la estructura de los logs. Acá está la prioridad de mente. El valor cero es el más alto, para emergencia. El 7 es el más bajo...

Ejecución del comando ntpdate y exportación de logs

...Vamos a ejecutar nuevamente el comando ntpdate. Fíjense que está sincronizado ahora. 27 de octubre, 17:27 horas. Y nuestra máquina virtual OSSIM está sincronizada. El 27 de octubre, 19:27 horas. Ya sabemos que tenemos el sincronismo de tiempos hecho. Ya sabemos que hemos configurado en el archivo ntpdate.conf junto con el ntp.conf. Y estamos exportando los logs a la dirección IP 192.168.1.200, sólo los authentication. Ping, es decir, voy a generar algo de autenticación. Voy a salir del usuario root que tenía acá, y ven que en estos momentos soy el usuario "acorletti" en mi Kali en mi Raspberry...

...Entonces, vamos a ver qué es lo que me está mostrando. Esto es el filtro de visualización. Antes, ejecutamos filtros de captura para que sólo me capturen la IP 192.168.12.20. Y ahora, de los miles de capturas de tramas que capturó, le estoy diciendo: "Sólo muéstrame aquellas que tengan el puerto igual a 514." Acordaros que Wireshark, acá está el resumen. Y acá me despliega toda la trama. Vamos a ver cada una de ellas. El protocolo, acordaros, Ethernet nivel 2, Internet nivel 3, y usando esta gran foto, nivel 4. Este es el protocolo que me está diciendo. La IP 220, es decir, mi Raspberry, tiene un puerto origen por arriba de 1024, que es un puerto cliente. Un puerto número el, por un puerto no conocido...

...Y ahora las 1928, donde otra vez estaríamos registrando. Así como aquí nos aparece la 220, en la medida que nosotros exportamos los logs hacia nuestro servidor central o nuestra plataforma 100, como en este caso, sí podríamos ir activando todos los dispositivos críticos de nuestra red para que nos envíen los logs. De la misma forma que lo estamos haciendo con nuestra Raspberry. Y no sólo los authentication, puedo sacar los de carne, los de 16, desde determinados parámetros del sistema. O sea, diferentes tipos de facilidades que yo considere importantes para ser exportadas de esos sistemas.

Bueno, esto es un poco lo que quería que vean. Porque es muy importante manejar bien este tema de syslog. Saber qué cosas almacenar localmente y saber qué cosas y cómo debo exportar las acciones centralizadoras del login. Y, de ser posible, una plataforma como OSSIM, que a su vez nos permite sacar reportes y estadísticas, meter la inteligencia a esos logs que estamos recibiendo.