Securitizando tu red: Sysmon y AuditD (Parte 3)

Escrito por Daniel Olivares

Introducción

Continuando con nuestra serie de artículos para mejorar la seguridad en nuestras PyMES u hogares. Hoy queremos presentarles una forma de mejorar los registros (logs) que dejan nuestros equipos ya sea en ambiente Windows o Linux.

Para esto utilizaremos dos herramientas libres que mejoraría enormemente la visibilidad sobre los procesos que ejecutan los equipos: para el ambiente Windows utilizaremos SYSMON, y para el ambiente Linux utilizaremos AUDITD.

Es importante destacar que estos software deberán ser instalados en cada equipo que deseemos monitorizar. Esto también nos servirá para poder contar con evidencia útil al momento de realizar una investigación forense o de caza de amenazas.

Prerrequisitos

Para poder realizar la instalación y uso de las herramientas propuestas necesitaremos dos equipos, uno con Windows y otro con Linux, teniendo en consideración:

SYSMON (Windows)

• Para OS de escritorio SYSMON es compatible con Win7+.
• Para OS de servidores SYSMON es compatible con WinServer 2008+.
• Contar con permisos de administrador para instalar software en tu sistema

AUDITD (Linux)

• Contar con permisos root para instalar software en tu sistema

Nosotros utilizaremos Windows 10 y Ubuntu 22 para los ejemplos.

SYSMON

System Monitor (SYSMON) es un software de Microsoft y servicio de Windows que debe ser instalado manualmente, registrando en el  “visor de eventos” con detalle los diferentes eventos ocurridos en el equipo.

El registro de estos eventos se realizará en la siguiente ruta del visor de eventos “Applications and Services Logs/Microsoft/Windows/Sysmon/Operational” y la rotación del log queda sujeta a la política de retención configurada en Windows.

Al momento de escribir este artículo SYSMON puede registrar 28 tipos de eventos:

• Event ID 1: Process creation
• Event ID 2: A process changed a file creation time
• Event ID 3: Network connection
• Event ID 4: Sysmon service state changed
• Event ID 5: Process terminated
• Event ID 6: Driver loaded
• Event ID 7: Image loaded
• Event ID 8: CreateRemoteThread
• Event ID 9: RawAccessRead
• Event ID 10: ProcessAccess
• Event ID 11: FileCreate
• Event ID 12: RegistryEvent (Object create and delete)
• Event ID 14: RegistryEvent (Key and Value Rename)
• Event ID 15: FileCreateStreamHash
• Event ID 16: ServiceConfigurationChange
• Event ID 17: PipeEvent (Pipe Created)
• Event ID 18: PipeEvent (Pipe Connected)
• Event ID 19: WmiEvent (WmiEventFilter activity detected)
• Event ID 20: WmiEvent (WmiEventConsumer activity detected)
• Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected)
• Event ID 22: DNSEvent (DNS query)
• Event ID 23: FileDelete (File Delete archived)
• Event ID 24: ClipboardChange (New content in the clipboard)
• Event ID 25: ProcessTampering (Process image change)
• Event ID 26: FileDeleteDetected (File Delete logged)
• Event ID 27: FileBlockExecutable
• Event ID 28: FileBlockShredding
• Event ID 29: FileExecutableDetected

Para ver la descripción completa de cada evento te invito a visitar el siguiente link, con la documentación oficial de Microsoft SYSMON – Events

Instalando SYSMON

Para realizar la instalación de SYSMON debemos contar con dos archivos, uno de estos debe ser el instalador, el cual podemos obtener desde la página oficial en el siguiente link: SYSMON – Download y el segundo es el archivo de configuración. Para este caso utilizaremos como base el que tiene Florian Roth disponible en el siguiente Github SYSMON – Config.

Una vez descarguemos el instalador, tendremos que descomprimirlo y copiar los archivos en la ruta “C:\Program Files” junto con el archivo de configuración.

El siguiente paso será abrir un terminal con permisos de administrador y dirigirnos a la ruta donde se encuentran los archivos de SYSMON utilizando:

cd C:\Program Files\Sysmon

Luego procederemos a la instalación, utilizando el comando:

Sysmon64.exe -accepteula -i sysmonconfig-export.xml

Inmediatamente se instalará el servicio SYSMON con la configuración definida en el archivo XML.

Con esto ya tendremos SYSMON instalado y podremos ir a revisar los logs al visor de eventos de Windows, para esto debemos dirigirnos a la ruta:

Applications and Services Logs/Microsoft/Windows/Sysmon/Operational

Editando el archivo de configuración

A continuación, explicaré cómo podemos editar el archivo de configuración para que podamos incluir reglas personalizadas y debido a que SYSMON es bastante granular, evaluaremos varios ejemplos para explicar la creación de reglas con mayor detalle.

Comenzaremos entendiendo la estructura básica del archivo de configuración, para lo cual usaremos como ejemplo algunas partes del archivo disponible en Github: SYSMON – Config.

El inicio del archivo de configuración no varía mucho en el tiempo, pero si hay que tener dos consideraciones:

1. La versión del esquema debe ser la misma que la versión de SYSMON instalado. Para este ejemplo utilizaremos la versión de esquema 4.83
2. Habilitar el registro del HASH en los eventos. El más utilizado en la industria actualmente es SHA256. Es importante definirlo ya que por defecto el valor de está etiqueta es “none”.

Con esto el inicio de nuestro archivo de configuración debería verse así:

<Sysmon schemaversion="4.83">
	<!--SYSMON META CONFIG-->
	<HashAlgorithms>sha256,IMPHASH</HashAlgorithms>
	<EventFiltering>
	</EventFiltering>
</Sysmon>

Ahora nos enfocaremos en el nodo “EventFiltering” donde podremos definir las reglas para el registro de eventos en Windows, para lo cual debemos tener algunas consideraciones previas.

Filtros de Eventos

A través de TAG únicos, basado en los EventID, se puede filtrar el tipo de evento que será evaluado. En la siguiente tabla se describen algunos de los TAG que se pueden utilizar para este propósito..

TAG	Descripción
ProcessCreate	Creación de proceso
FileCreateTime	Tiempo de creación de archivo
NetworkConnect	Conexiones de red
ProcessTerminate	Proceso terminado
DriverLoad	Carga de Driver
ImageLoad	Carga de Imagen
CreateRemoteThread	Creación de Thread remoto
RawAccessRead	Acceso de lectura RAW
ProcessAccess	Acceso a procesos
FileCreate	Creación de archivos
RegistryEvent	Objeto de registro añadido o eliminado
RegistryEvent	Configuración de parámetro de registro
RegistryEvent	Modificación de nombre de registro
FileCreateStreamHash	Flujo de creación de archivos
PipeEvent	PIPE nombrada creada
PipeEvent	PIPE nombrada conectada
WmiEvent	Filtro WMI
WmiEvent	WMI consumer
WmiEvent	WMI consumer filter
DNSQuery	Consulta DNS
FileDelete	Eliminación de archivos (ARCHIVADA)
ClipboardChange	Nuevo contenido en portapapeles
ProcessTampering	Cambio en imagen de proceso
FileDeleteDetected	Eliminación de archivos (REGISTRADA)
FileBlockExecutable	File Block Executable
FileBlockShredding	File Block Shredding
FileExecutableDetected	File Executable Detected

Junto al filtro de evento elegido deberemos indicarle cómo realizará match (calce) sobre los eventos y para esto deberemos indicar el atributo “include” o “exclude”. Esto lo realizaremos agregando después del filtro ‘onmatch=”include”’ o ‘onmatch=”exclude”’ según corresponda

Cuando definimos el valor “include” el filtro solo realizará match cuando se cumpla la condición definida y todo evento fuera de la condición, será ignorado y no documentado.

Cuando definimos el valor como “exclude” el filtro realizará match para todos los eventos a excepción de los casos que definamos.

Finalmente es importante destacar que al configurar un filtro puedo usar ambos atributos en la configuración, pero los eventos definidos con el atributo “exclude” tendrán preferencia.

Datos del evento

Cada LOG que SYSMON registre, incluirá diferentes tipos de datos dependiendo del EventID que se esté registrando. Esta información es importante debido a que será la base para definir sobre qué información se realizará match. A continuación, detallo algunos de los datos disponibles por EventID.

EventID	EventName	Data
1	Process Creation	UtcTime, ProcessGuid, ProcessID, Image, FileVersion, Description, Product, Company, CommandLine, CurrentDirectory, User, LogonGuid, LogonId, TerminalSessionId, IntegrityLevel, Hashes, ParentProcessGuid, ParentProcessId, ParentImage, ParentCommandLine, RuleName
2	File Creation Time Retroactively Changed In The Filesystem	UtcTime, ProcessGuid, ProcessId, Image, TargetFilename, CreationUtcTime, PreviousCreationUtcTime
3	Network Connection Initiated	UtcTime, ProcessGuid, ProcessId, Image, User, Protocol, Initiated, SourceIsIpv6, SourceIp, SourceHostname, SourcePort, SourcePortName, DestinationIsIpV6, DestinationIp, DestinationHostname, DestinationPort, DestinationPortName
5	Process Ended	UtcTime, ProcessGuid, ProcessId, Image
6	Driver Loaded Into Kernel	UtcTime, ImageLoaded, Hashes, Signed, Signature, SignatureStatus
7	Dll (Image) Loaded By Process	UtcTime, ProcessGuid, ProcessId, Image, ImageLoaded, Hashes, Signed, Signature, SignatureStatus
8	Remote Thread Created	UtcTime, SourceProcessGuid, SourceProcessId, SourceImage, TargetProcessId, TargetImage, NewThreadId, StartAddress, StartModule, StartFunction
9	Raw Disk Access	UtcTime, ProcessGuid, ProcessId, Image, Device
10	Inter-Process Access	UtcTime, SourceProcessGuid, SourceProcessId, SourceThreadId, SourceImage, TargetProcessGuid, TargetProcessId, TargetImage, GrantedAccess, CallTrace
11	File Created	UtcTime, ProcessGuid, ProcessId, Image, TargetFilename, CreationUtcTime
17-18	Pipe Created / Pipe Connected	UtcTime, ProcessGuid, ProcessId, PipeName, Image
19-20-21	Wmi Event Monitoring	EventType, UtcTime, Operation, User, Name, Type, Destination, Consumer, Filter
22	Dns Query	RuleName, UtcTime, ProcessGuid, ProcessId, QueryName, QueryType, QueryStatus, QueryResults
23	File Delete	RuleName, UtcTime, ProcessGuid, ProcessId, User, Image, TargetFilename, Hashes, IsExecutable, Archived
24	Clipboard Event Monitoring	EventType, UtcTime, ProcessGuid, ProcessId, Image, Session, ClientInfo, Hashes, Archived
25	Process Tampering	EventType, RuleName, UtcTime, ProcessGuid, ProcessId, Image, Type
26	File Delete Logged	RuleName, UtcTime, ProcessGuid, ProcessId, User, Image, TargetFilename, Hashes, IsExecutable
27	File Block Executable	RuleName, UtcTime, ProcessGuid, ProcessId, User, Image, TargetFilename, Hashes
28	File Block Shredding	RuleName, UtcTime, ProcessGuid, ProcessId, User, Image, TargetFilename, Hashes
29	File Executable Detected	RuleName, UtcTime, ProcessGuid, ProcessId, User, Image, TargetFilename, Hashes

Condicionales

Para poder hacer match con los datos que se están registrando se deben utilizar condicionales que definirán cómo se evaluará la información. Es importante destacar que la información evaluada es “case sensitive”.

A continuación detallo algunas de estás condiciones disponibles:

Condición	Descripción
is	Por defecto, los valores son iguales
is any	El campo es “uno de”. Se pueden delimitar valores con ;
is not	Los valores son diferentes
contains	El campo contiene
contains any	El campo contiene cualquiera “de”. Se pueden delimitar valores con ;
contains all	El campo contiene todo “de”. Se pueden delimitar valores con ;
excludes	El campo no contiene el valor
excludes any	El campo no contiene uno o más “de”. Se pueden delimitar valores con ;
excludes all	El campo no contiene ninguno de los valores. Se pueden delimitar valores con ;
begin with	El campo comienza “con”
end with	El campo termina “con”
not begin with	El campo NO comienza “con”
not end with	El campo NO termina “con”
less than	La comparación es menor “que”
more than	La comparación es mayor “que”
image	Hace match con la ruta absoluta

Teniendo toda está información en consideración, es que podremos realizar múltiples combinaciones que nos permitan monitorear de la forma y manera que necesitamos los equipos.

A continuación veremos varios escenarios de configuración para explicar de mejor manera cómo formular las reglas utilizando los filtros, datos y condiciones ya descritas.

Cuando comenzamos a monitorear el funcionamiento de los equipos es bastante probable que no exista documentación sobre qué procesos, comandos o directorios deberían ser utilizados. Y debido a esto no sepamos qué monitorear.

En este caso lo recomendable sería realizar un monitoreo de amplio espectro, donde buscaríamos monitorear todo para luego realizar tuning sobre la regla. Como ejemplo utilizaremos el filtro “ProcessCreate” que nos permitirá monitorear la creación de procesos y lo definiremos con el atributo “exclude”, dejando en blanco los elementos debajo del filtro. La regla debería verse de la siguiente manera.

<EventFiltering>
	<ProcessCreate onmatch="exclude">
	</ProcessCreate>
</EventFiltering>

Con esta regla estamos indicando que se debe registrar toda creación de procesos del equipo, sin excepción. Esto nos permitirá generar una línea base de los procesos creados sobre la cual podremos comenzar a modificar la regla para disminuir la cantidad de registros.

Y luego de revisar los eventos del equipo identificamos que el proceso de “Indexado de Windows” y el proceso “Windows Session Manager” son utilizados constantemente y generan una gran cantidad de log que no están siendo de interés debido a que son dos procesos del funcionamiento normal y constante del sistema operativo y por ende decidimos no monitorearlos.

Esto lo lograremos modificando el ejemplo anterior, pero esta vez si agregaremos elementos debajo del filtro utilizando el campo “CommandLine” de la Data del evento y la condicional “is”. Lo cual se vería de la siguiente forma.

<EventFiltering>
	<ProcessCreate onmatch="exclude">
		<CommandLine condition="is">C:\Windows\system32\SearchIndexer.exe /Embedding</CommandLine>
		<CommandLine condition="is">\SystemRoot\System32\smss.exe</CommandLine>
	</ProcessCreate>
</EventFiltering>

En la regla con condicional “is” estamos indicado que se deje registro de toda creación de proceso a excepción de cuando el campo “CommandLine” haga match exacto con la ruta indicada.

Ahora si solo nos interesa monitorear procesos especificamos podemos crear una regla con el filtro “ProcessCreate” y lo definiremos con el atributo “include” defiendo sobre qué se debe hacer match. Para este ejemplo monitoreamos solo la creación de los procesos de TeamViewer. La regla se debería ver de la siguiente forma:

<EventFiltering>
	<ProcessCreate onmatch="include">
		<CommandLine condition="is">C:\Program Files\TeamViewer\TeamViewer.exe</CommandLine>
	</ProcessCreate>
</EventFiltering>

Con está regla indicamos que se deje registro solo cuando el valor “CommandLine” haga match en el el texto definido. Es importante mencionar que el uso de está combinación solo se debe utilizar cuando tengamos pleno conocimiento de lo que realizará el match, esto debido a que podemos dejar eventos sin monitorear y un atacante puede aprovechar esta situación para pasar desapercibido. 

En otro caso donde necesitemos monitorear la creación de archivos por ejemplo en la carpeta temporales podremos realizarlo creando una regla con el filtro “FileCreate” con el atributo “include”. En este caso evaluaremos la data del campo “TargetFilename” utilizando la condición “contains any”. La regla se debería ver de la siguiente manera:

<EventFiltering>
	<ProcessCreate onmatch="include">
		<TargetFilename condition="contains any">Temp;TMP,tmp</CommandLine>
	</ProcessCreate>
</EventFiltering>

En esta regla indicamos que se deje registro de cualquier creación de archivo cuando el campo “TargetFilename” contenga el texto definido, en este caso nombres comunes para carpetas de temporales.

En caso de necesitar monitorear la creación de archivos con extensión asociados a algún ransomware podremos realizarlo creando una regla que utilice el filtro “FileCreate” con el atributo “include”. En este caso evaluaremos la data del campo “TargetFilename” utilizando la condición “contains any”. La regla se debería ver de la siguiente manera:

<EventFiltering>
	<ProcessCreate onmatch="include">
		<TargetFilename condition="contains any">.locky;.wcry;.potato;.cry</CommandLine>
	</ProcessCreate>
</EventFiltering>

También podremos generar reglas que nos ayuden a detectar ejecuciones desde MALDOC (documento malicioso), para esto tendremos que crear un grupo de regla donde nos permita definir dos condiciones utilizando el filtro “ProcessCreate” y el atributo “include”:

1. La primera definición evaluará el campo  “ParentImage” y la condicional será “contains any”.
2. La segunda definición evaluará el campo “Image” y la condición será “contains any”.

<RuleGroup name="MALDOC" groupRelation="and">
	<EventFiltering>
		<ProcessCreate onmatch="include">
			<ParentImage condition="contains any">WINWORD.EXE;EXCEL.EXE;POWERPNT.EXE;OUTLOOK.EXE</ParentImage>
			<Image condition="contains any">cmd.exe;powershell.exe;wscript.exe;cscript.exe;wmic.exe</Image>                        
		</ProcessCreate>
	</EventFiltering>
</RuleGroup>

En esta regla estamos indicado que las definiciones del grupo “MALDOC” serán evaluadas con un “Y” entre sí, y ésta hará match cuando en el evento se detecte en el campo “ParentImage” cualquiera de los textos definidos (Word, Excel, PowerPoint y Outlook) y en el campo “Image” se detecte cualquiera de los textos definidos.

En resumen, SYSMON dejará registro cada vez que algún programa de la suite Office sea el proceso padre para la ejecución de una consola cmd o Powershell, por ejemplo. Este comportamiento NO es normal y está asociado a las ejecuciones que se realizan desde un MALDOC y es altamente recomendable investigar este tipo de eventos.

Finalmente si quisiéramos dejar registro de las consultas DNS realizadas por el equipo podríamos crear una regla que utilice el filtro “DnsQuery” con atributo “exclude”, donde evaluamos el campo “QueryName” utilizando la condicional “end with”. El ejemplo a continuación es un extracto de la configuración propuesta inicialmente:

<EventFiltering>
	<DnsQuery onmatch="exclude">
…
		<QueryName condition="end with">.microsoft.com</QueryName>
		<QueryName condition="end with">.office.com</QueryName>
		<QueryName condition="end with">.microsoftstore.com</QueryName>
		<QueryName condition="end with">.skype.com</QueryName>
		<QueryName condition="end with">.windowsupdate.com</QueryName>
…
	</DnsQuery>
</EventFiltering>

En esta regla estamos indicando que se deje registro de toda consulta DNS realizada, con excepción cuando los dominios terminan con los textos definidos. Estos son los dominios de uso constante pero que no presentan ningún riesgo para la organización, en el ejemplo excluimos el registro de dominios asociados a Microsoft, pero pueden ver que en el archivo de configuración se excluyen mucho más.

Es importante mencionar que está regla generará muchos registros en el visor de eventos, pero el valor de este evento es que indica cual es el programa que realizó la consulta.

Por suerte el archivo de configuración propuesto, cuenta con una buena base para comenzar esta tarea.

AUDITD

Instalando AUDITD

Antes de continuar nos aseguramos que el sistema operativo se encuentre actualizado, para esto ejecutamos el siguiente comando.

Ubuntu sudo apt update && sudo apt upgrade

CentOS sudo yum update && sudo yum upgrade

Una vez el sistema esté actualizado, procedemos a instalar AUDITD con el siguiente comando.

Ubuntu sudo apt install auditd

CentOS sudo yum install audit

Con esto tendremos instalado el servicio de auditoría y el siguiente paso sería configurarlo.

Para esta parte utilizaremos como base el archivo disponible en el Github de Florian Roth en el siguiente link AUDITD – Config

Lo primero que haremos será respaldar el archivo de configuración audit.rules y luego vaciarlo utilizando los siguientes comandos:

Ubuntu cp -a /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.bkpcat /dev/null > /etc/audit/rules.d/audit.rule

CentOS cp -a /etc/audit/audit.rules /etc/audit/audit.rules.bkpcat /dev/null > /etc/audit/audit.rules

Luego lo editamos con nuestro editor favorito, donde pegaremos la configuración base del Github. Se debería ver así:

Guardamos el archivo y salimos. Luego de esto tendremos que configurar AUDITD para que se inicie con el sistema operativo y finalizamos reiniciando el servicio con los siguientes comandos:

Ubuntu systemctl enable auditdsystemctl start auditd

CentOS systemctl enable auditdsystemctl start auditd

Editando el archivo de configuracón

A continuación, explicaré cómo podemos editar este archivo para incluir reglas personalizadas, teniendo como ejemplo el monitoreo de las ejecuciones del servicio web con el fin de buscar el uso de webshell.

Con AUDITD podremos monitorear las llamadas de sistema y realizar auditoria de archivos.

Auditando llamadas de sistema (syscall)

Para auditar syscall tendremos la siguiente estructura:

-a acción,filtro –S system_call –F campo=valor –k “tag”

Donde las directivas significan:

Directiva	Detalle
Acción	Esta directiva tiene dos valores “always” o “never” y estos significan que siempre audita o nunca audita.
Filtro	Esta directiva es específica de las reglas de Kernel
S	Nombre de syscall. En el siguiente link SYSCALL List podrás encontrar un listado completo de la syscall en linux para 32 y 64 bit.
F	Opciones adicionales del filtro (arquitectura, PID,GID, etc)
K	Especifica un TAG para el registro

Como ejemplo podemos utilizar la siguiente regla:

-a always,exit -F arch=b64 -F euid=0 -S execve -k rootcmd

La cual podremos interpretar como “Siempre monitorea la salida de las ejecuciones del usuario con ID 0 (root) y utiliza el tag rootcmd”.

Auditando archivos y carpetas

Para auditar archivos y carpetas tendremos la siguiente estructura:

-w /ruta/al/archivo/o/directorio –p “permiso” –k “tag”

Donde las directivas significan:

Directiva	Detalle
W	Especifica la ruta hacia el archivo o directorio que se quiere monitorear.
P	Especifica los permisos a registrar: r: acceso de lectura w: acceso de escritura x: acceso de ejecución a: cambio de atributo
K	Especifica un TAG para el registro

Como ejemplo podemos utilizar la siguiente regla:

-w /var/www/ -p w –k write_webdirectory

La cual podremos interpretar como “Monitorea la escritura de archivos en el directorio /var/www”.

Monitoreando la ejecución de WEBSHELL

Entendiendo mejor la estructura de cómo se escriben las reglas de AUDITD será más fácil entender la regla para la detección de webshell en un servidor WEB.

Para esto editaremos nuevamente el archivo audit.rules y buscamos la sección “# Web Server Actvity” donde veremos lo siguiente:

# Web Server Actvity
## Change the number "33" to the ID of your WebServer user. Default: www-data:x:33:33
-a always,exit -F arch=b32 -S execve -F euid=33 -k detect_execve_www
-a always,exit -F arch=b64 -S execve -F euid=33 -k detect_execve_www

Esta sección monitorea siempre las ejecuciones del usuario 33 (Apache/NGINX) en arquitecturas de 32 y 64 bit agregándoles el TAG “detect_execve_www”. Lo cual nos permitirá detectar cuando se esté utilizando una webshell ya que se identificaran ejecuciones utilizando el usuario de sistema del servicio WEB.

Si deseamos monitorear la escritura sobre los directorios WEB agregamos la línea del ejemplo de estructura, quedando de la siguiente manera:

# Web Server Actvity
## Change the number "33" to the ID of your WebServer user. Default: www-data:x:33:33
-a always,exit -F arch=b32 -S execve -F euid=33 -k detect_execve_www
-a always,exit -F arch=b64 -S execve -F euid=33 -k detect_execve_www
-w /var/www/ -p w –k write_webdirectory

La nueva línea dejará registro de cuando se realice alguna escritura en los directorios que estén en /var/www (directorio tipico del servicio WEB), lo que nos permitirá identificar cuando algún atacante realice alguna carga de archivos en algún directorio web.

Solo nos quedaría reiniciar el servicio AUDITD utilizando el siguiente comando

Ubuntu systemctl restart auditd

CentOS systemctl restart auditd

Revisando las auditorías

Los logs registrados por AUDIT se almacenan en la ruta “/var/log/audit/audit.log” y para su revisión tenemos algunas opciones.

• Una opción para poder revisar los logs, es utilizar el comando “aureport” el cual nos entregará la estadística de los log registrados a la fecha.

• Otra opción es utilizar el comando “ausearch” lo que nos entregará una vista optimizada de los eventos, con la opción de algunos filtros:

Comando	Descripción
ausearch -ui	Entrega los eventos de un usuario específico
ausearch -x <ruta>	Entrega los eventos en una ruta específica
ausearch -l <tag>	Entrega los eventos con un TAG específico

En la siguiente foto podemos ver el reporte que entrega cuando se buscan los eventos para el usuario 0 (root).

• Y como última opción para revisar logs se utilizar el comando tail -f <ruta_archivo> lo que nos permitirá ver los log en tiempo real. Si deseamos filtrar por alguna palabra podemos utilizar “grep”, quedando el comando “tail -f <ruta_archivo> | grep <palabra_filtro>”.

Conclusión

La incorporación de estás dos herramientas en tu ambiente mejorará enormemente la visibilidad sobre los procesos que ejecutan los equipos y dará mayores capacidades de detección de cualquier comportamiento anómalos que pudiera existir en ambientes Windows o en Linux.

Esto fortalecerá la defensa de nuestro entorno TI y se podrá obtener una comprensión más profunda del funcionamiento de los diferentes sistemas, permitiendo tener una respuesta más rápida ante cualquier amenaza ya que contaremos con eventos de auditoría que nos darán información útil.

Ahora bien, es importante destacar que con la configuración propuesta el registro de LOGS quedará de forma local en el equipo y no centralizadamente, lo cual en caso de tener un evento de seguridad donde el equipo se vea comprometido con cifrado de datos o eliminación de estos existe una alta probabilidad de que los LOG se pierdan y no tengamos como poder realizar una investigación adecuadamente. Este punto será abordado en nuestro próximo artículo donde explicaremos cómo levantar y configurar un repositorio externo de eventos.