En el pasado episodio introdujimos al lector en el mundo Sentinel. Instalamos la opción y usamos un conector sencillo para empezar a ingestar datos.
Seguimos con esta segunda entrega, esta vez vamos a profundizar un poco más en los eventos, en los logs. Se que hemos creado mucha expectación con la serie, pero no me llaméis a casa a las 3 de la mañana como alguno ha hecho, tener paciencia.
Podemos decir que tenemos 3 tipos de Data Connector según el origen de los mismos, los de sistemas Microsoft, como puedan ser eventos de seguridad de Windows, Defender para Office, Cloud App Security etc. Por otro lado tenemos los conectores de los vendors, de los fabricantes, como puedan ser la consola centralizada de Eset, Cisco o servicios en Amazon…
Es muy importante entender el ámbito de actuación de Azure Sentinel, más allá de servicios de seguridad relacionados con “el mundo Microsoft”. En conversaciones con colegas del ramo entiende o asocian que Azure es la nube de Microsoft… para productos Microsoft… y para servicios puro de la nube. Más allá de estos planteamientos, afirmo que es todo lo contrario. Azure Sentinel se aloja en la nube de Microsoft, pero podemos tener visibilidad de eventos de cualquier tipo y ubicación, por ejemplo, nuestros firewalls perimetrales on-premise… o nuestra base de datos Sql Server en un servidor desactualizado en el fondo del CPD… La apuesta de Microsoft en esto es totalmente multicloud.
El tercer tipo de conectores que tenemos los denominaría “a medida”. Cualquier evento que podamos transmitir, que acepte el formato CEF ( Common Event Format) o en formato syslog. Syslog puede ser el mecanismo de transporte y a su vez el formato de los datos, o “por encima” llevar una capa de formateo de datos denominada CEF.
Podemos tener datos en formato syslog grabados en un fichero, sin red… o podemos tener.
De esta manera, tenemos cubierto el 99,99% de los casos de ingesta de logs. Microsoft indica esta referencia de manera sencilla
Este documento nos viene de lujo para los ecosistemas Linux, indicar que el tráfico SYSLOG por defecto va en claro, y es una buena práctica fortificar la comunicación con TLS. Para Rsyslog y SYSLOG.NG es muy sencillo habilitarlo. Recuerda, Security by default
La ingesta de los eventos que se transmiten por Syslog se recepcionan en Sentinel mediante el Log Analytics Agent.
El Log Analytics Agent o también denominado Microsoft Monitoring Agent (MMA) o OMS Linux agent. Puede desplegarse como una extensión de máquina virtual si nuestro equipo está en la nube Azure, o podemos instalarlo de manera convencional en nuestra infraestructura ON Premise. Una buena práctica sería tener un servidor centralizado interno y desde ahí, “saltar” hacía Sentinel mediante un agente.
Me gusta la aproximación de Microsoft de usar este único agente para la telemetría no solo de seguridad, sino de operaciones, y el mismo agente nos dará información para Sentinel, para Operationes Manager y otros servicios de diagnóstico y monitorización.
Si usamos el cliente Windows del agente podremos configurar uno o varios Workspace como destino, por ejemplo un repositorio de seguridad, otro de rendimiento, uno para IIS, otro para seguridad… whatever you need. Si usas el agente Linux solo podrás configurar un espacio de trabajo…
Para configurar un agente en Linux vamos a seguir un pequeño proceso. Tenemos que entrar en Áreas de trabajo de Log Analytics, buscar nuestro repositorio si tenemos uno o varios. En el cuadro general tenemos el id del Workspace. Si seleccionamos Gestión de agentes, tenemos la clave primaria de seguridad, y la descarga de los agentes Microsoft. Seguimos con Linux.
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w -s
Después de una serie de invocaciones al demonio, lenguas extintas y varias delicadezas, tenemos nuestro agente desplegado en Linux.
En un acto de temeridad, vamos a intentar desplegar el agente en un servidor Windows On-Premise siguiendo nuestra intuición… vamos a descargar el binario para 32 o 64 bits y probar a instalarlo… llámame loco.
Desde el mismo menú en Azure donde recuperamos los id, podemos ver la cantidad de equipos conectados al workspace, Linux y Windows.
Si hacemos un repaso por donde vamos, tenemos eventos originados en Linux, que serán guardados en Azure, en nuestro Workspace, que Sentinel usará. ¿Pero estos eventos de Linux como son? ¿Valen cualquier tipo de eventos? Los eventos recopilados de esta manera estarán en formato Syslog. Por ejemplo, eventos del sistema, de Apache, si tuviéramos un Mysql, etc. Imagina que tienes una aplicación desarrollada internamente con un formato de logs “propios”… por mucho que el protocolo sea syslog habrá que gestionarlos? ¿Parsearlos?
Ahora tenemos que configurar como gestionamos estos eventos una vez llegan. Desde la configuración avanzada del Workspace seleccionamos la fuente SYSLOG y agregamos un recurso. Seguro que si estás familiarizado con el formato syslog entiendes el proceso.
En mi caso voy a añadir Syslog, Auth y Autpriv para monitorizar algunas cositas.
Vamos a configurar qué registros vamos a trasportar en el agente Microsoft ya que estamos.
Como puedes ver, aquí podemos configurar que ramas del visor de eventos queremos consumir. Si queremos tener los eventos de la rama Seguridad clásicos de toda la vida, no tenemos que hacerlo por el agente syslog. Debemos irnos a los Data Connectors y seleccionar un conector que hay denominado Eventos de Seguridad. Al final, por debajo, se nutrirá del agente instalado en el Windows para recopilar los eventos, pero como comentamos en el primer episodio una cosa son los datos en bruto, y otra cosa son las libros y conectores que aportan otra serie de ventajas, como cuadros de mando, consultas, etc.
Siguiente este ejemplo, habilitamos la ingesta para los logs clásicos de seguridad, y añadimos los eventos del servidor DNS… que nunca está mal.
No vamos a continuar por este sendero de gloria, eventos y pantallas negras, pero si queremos avanzar un poquito en los eventos, en verlos.
Desde Sentinel tenemos una pestaña que se denomina registros. Podemos acceder a los registros desde distintas ubicaciones, pero siempre vamos a parar la misma información. Una vez que entramos en registros nos aborda un panel con recomendaciones sobre consultas que podemos hacer. Esto es la parte importante de Sentinel, la creación de alertas y consultas para detectar los incidentes, pero esto será objeto de otros episodios. De momento vamos a ver datos de nuestros Linux y Windows que hemos añadido. Cerramos las consultas propuestas y se me ocurre decirle que busque cualquier evento de autenticación en Linux.
Syslog
| where Facility in (“authpriv”,”auth”)
Interesante, ya tenemos eventos. Y si le añadimos un count a la consulta, y nos vamos por SSH y fallamos alguna vez … el count es solo un guiño para que veas como se genera eventos, pero al final, podemos ver el evento.
Para abrir un poco las ganas, vamos a hacer una cosa, nos vamos a ir a análisis, vamos a ver las reglas que tenemos habilitadas, y vamos a habilitar un par de reglas que nos proporciona Sentinel respecto al SSH.
No voy a entrar en detalle, pero si creamos la regla, al final será una consulta que se realiza cada cierto tiempo, vamos a crearla.
Voy a copiar la consulta, y voy a cambiar el valor para que busque 3 intentos fallidos de login en un día, en vez de 15.
let timeframe = 1d;
let threshold = 3;
Syslog
| where TimeGenerated >= ago(timeframe)
| where SyslogMessage contains “Failed password for invalid user”
| where ProcessName =~ “sshd”
| parse kind=relaxed SyslogMessage with * “invalid user” user ” from ” ip ” port” port ” ssh2″
| project user, ip, port, SyslogMessage, EventTime
| summarize EventTimes = make_list(EventTime), PerHourCount = count() by ip, bin(EventTime, 4h), user
| where PerHourCount > threshold
| mvexpand EventTimes
| extend EventTimes = tostring(EventTimes)
| summarize StartTimeUtc = min(EventTimes), EndTimeUtc = max(EventTimes), UserList = makeset(user), sum(PerHourCount) by IPAddress = ip
| extend UserList = tostring(UserList)
| extend timestamp = StartTimeUtc, IPCustomEntity = IPAddress, AccountCustomEntity = UserList
Conclusión
Como hemos comentado, esto es solo para que vayas comprendiendo un poco más Sentinel. De momento sabemos configurarlo, sabemos leer logs de Azure, muy sencillos, y logs de máquinas On-Premise, como un Windows Server y un Linux. Hemos visto por encima las reglas… pero de momento es suficiente.
Quizás en el próximo artículo aprendamos a usar otro tipo de conector, por ejemplo… un Logtash que ya tienes recopilando eventos con tu ELK, te imaginas?
Desde Verne somos conscientes de la complejidad de un proyecto así, en el que no solo interviene la parte del SIEM, sino de cómo aglutinar eventos, estrategias de envío, retención, fortificación, etc.
Como siempre, gracias por leernos y sigue atento a la serie de artículos y si tienes alguna necesidad, ya sabes
#WeAreVerne
