ExamenRedes – Examen, preguntas y respuestas Redes De Computadores Examenes de Redes
Última actualización: octubre 17, 2022
12.2.1.5 Práctica de laboratorio: Convertir los datos a un formato universal (versión para el instructor)
Nota para el instructor: Los elementos con color de fuente rojo o resaltados en gris indican texto que aparece solo en la copia del instructor.
Objetivos
Parte 1: Normalizar marcas de hora en un archivo de registro
Parte 2: Normalizar marcas de hora en un archivo de registro Apache
Parte 3: Preparación de archivos de registro en Security Onion
Antecedentes / Escenario
Esta práctica de laboratorio preparará a los alumnos para aprender dónde se encuentran los archivos de registro. También aprenderán cómo manipularlos y verlos. Las entradas de registro son generadas por dispositivos de red, sistemas operativos, aplicaciones y diversos tipos de dispositivos programables. A un archivo que contiene una secuencia temporizada de entradas de registro se le llama archivo de registro.
Por naturaleza, los archivos de registro registran eventos que son relevantes a la fuente. La sintaxis y el formato de los datos que se encuentran dentro de los mensajes de registro a menudo son definidos por el desarrollador de la aplicación.
Por lo tanto, la terminología utilizada en las entradas de registro a menudo varía según la fuente. Por ejemplo: dependiendo de la fuente, los términos «iniciar sesión», «conectarse», «evento de autenticación» y «conexión del usuario» pueden aparecer en entradas de registro para describir la autenticación exitosa de un usuario en un servidor.
A menudo es aconsejable tener terminología consistente y uniforme en los archivos de registro generados por diferentes fuentes. Esto es especialmente cierto cuando todos los archivos de registro son recopilados por un punto centralizado.
El término normalización se refiere al proceso de convertir partes de un mensaje, en este caso una entrada de registro, a un formato común.
En esta práctica de laboratorio utilizarán herramientas de la línea de comando para normalizar las entradas de registro manualmente. En la Parte 2, se normalizará el campo de la marca de hora. En la Parte 3, se normalizará el campo de IPv6.
Nota: Si bien hay numerosos complementos para realizar la normalización de archivos de registro, es importante comprender los fundamentos básicos que subyacen al proceso de normalización.
Recursos necesarios
- VM CyberOps Workstation
- VM Security Onion
Parte 1: Normalizar marcas de hora en un archivo de registro
Las marcas de hora se utilizan en entradas de registro para especificar cuándo tuvo lugar el evento registrado. Si bien la práctica recomendada es registrar marcas de hora en UTC, el formato de las marcas de hora varía según la fuente del archivo de registro. Hay dos formatos de marca de hora comunes; se conocen como Unix Epoch y Human Readable (Legible por seres humanos).
Las marcas de hora Unix Epoch registran la hora midiendo la cantidad de segundos transcurridos desde el 1 de enero de 1970.
Las marcas de hora legibles registran la hora representando valores aparte para el año, el mes, el día, las horas, los minutos y los segundos.
La marca de hora legible Wed, 28 Jun 2017 13:27:18 GMT equivale a 1498656439 en Unix Epoch.
Desde un punto de vista de programabilidad, es mucho más fácil trabajar con Epoch, ya que permite facilitar operaciones de suma y resta. Desde una perspectiva de análisis; sin embargo, las marcas de hora legibles son mucho más fáciles de interpretar.
Convertir marcas de hora Epoch a marcas de hora legibles con AWK
AWK es un lenguaje de programación diseñado para manipular archivos de texto. Es muy potente y especialmente útil para manejar archivos de texto en los que las líneas contienen varios campos, separados por un carácter delimitador. Los archivos de registro contienen una entrada por línea y tienen el formato de campos separados por delimitadores, por lo que AWK es una excelente herramienta para la normalización.
Analicen el archivo applicationX_in_epoch.log que se muestra a continuación. La fuente del archivo de registro no es relevante.
2|Z|1219071600|AF|0 3|N|1219158000|AF|89 4|N|1220799600|AS|12 1|Z|1220886000|AS|67 5|N|1220972400|EU|23 6|R|1221058800|OC|89
El archivo de registro anterior fue generado por la aplicación X. Los aspectos relevantes del archivo son los siguientes:
- Las columnas están separadas, o delimitadas, por el carácter |. Por lo tanto, el archivo tiene cinco columnas.
- La tercera columna contiene las marcas de hora en Unix Epoch.
- El archivo tiene una línea adicional al final. Esto será importante más adelante en la práctica de laboratorio.
Supongan que un analista de archivos de registro necesita convertir las marcas de hora al formato legible. Sigan los pasos que se detallan a continuación y utilicen AWK para realizar la conversión manual fácilmente:
a. Abran la VM CyberOps Workstation y, luego, abran una ventana del terminal.
b. Utilicen el comando cd para pasar al directorio /home/analyst/lab.support.files/. Allí se almacena una copia del archivo que se muestra arriba.
[analyst@secOps ~]$ cd ./lab.support.files/ [analyst@secOps lab.support.files]$ ls -l total 580 -rw-r--r-- 1 analyst analyst 649 Jun 28 18:34 apache_in_epoch.log -rw-r--r-- 1 analyst analyst 126 Jun 28 11:13 applicationX_in_epoch.log drwxr-xr-x 4 analyst analyst 4096 Aug 7 15:29 attack_scripts -rw-r--r-- 1 analyst analyst 102 Jul 20 09:37 confidential.txt <output omitted> [analyst@secOps lab.support.files]$
c. Emitan el siguiente comando de AWK para convertir e imprimir el resultado en el terminal:
Nota: Es común cometer un error de mecanografiado en el siguiente script. Consideren la posibilidad de copiar el script en un editor de texto para quitar los saltos de línea adicionales. Luego, copie el script del editor de texto a la ventana del terminal de la VM CyberOps Workstation. Sin embargo, recuerden estudiar la explicación del script que se incluye a continuación para enterarse de qué manera modifica el campo de la marca de hora.
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS="|"}{$3=strftime("%c",$3)} {print}' applicationX_in_epoch.log
2|Z|Mon 18 Aug 2008 11:00:00 AM EDT|AF|0
3|N|Tue 19 Aug 2008 11:00:00 AM EDT|AF|89
4|N|Sun 07 Sep 2008 11:00:00 AM EDT|AS|12
1|Z|Mon 08 Sep 2008 11:00:00 AM EDT|AS|67
5|N|Tue 09 Sep 2008 11:00:00 AM EDT|EU|23
6|R|Wed 10 Sep 2008 11:00:00 AM EDT|OC|89
||Wed 31 Dec 1969 07:00:00 PM EST
[analyst@secOps lab.support.files]$
El comando anterior es un script de AWK. Puede parecer complicado. La estructura principal del script de AWK es la siguiente:
- awk: invoca al intérprete de AWK.
- ‘BEGIN: define el comienzo del script.
- {}: define las acciones que se deben realizar en cada línea del archivo de texto de entrada. Un script de AWK puede tener varias acciones.
- FS = OFS = “|”: esto define el separador de campos (es decir, el delimitador) como el símbolo (|) de la barra. En distintos archivos de texto se pueden utilizar diferentes caracteres delimitadores para separar campos. Este operador permite que el usuario defina qué carácter se utiliza como el separador de campos en el archivo de texto actual.
- $3: esto hace referencia al valor presente en la tercera columna de la línea actual. En el archivo log, la tercera columna contiene la marca de hora en Epoch que se tiene que convertir.
- strftime: esta es la función interna de AWK diseñada para trabajar con la hora. Los valores %c y $3 entre paréntesis son los parámetros que se pasan a strftime.
- log: este es el archivo de texto de entrada que se tiene que cargar y utilizar. Como ya está en el directorio lab.support.files, no es necesario que agregue la información de la ruta: /home/analyst/lab.support.files/applicationX_in_epoch.log.
La primera acción del script, definida en el primer conjunto de llaves es definir el carácter separador de campos como la barra vertical («|»). Luego, en el segundo conjunto de llaves, se reescribe la tercera columna de cada línea con el resultado de la función strftime() que se ejecutó. strftime() es una función interna de AWK creada para manejar la conversión de la hora. Observen que el script le ordena a la función que utilice el contenido de la tercera columna de cada línea antes del cambio ($3) y que dé formato a la salida (%c).
¿Se convirtieron las marcas de hora Unix Epoch al formato legible? ¿Se modificaron los otros campos? Explique.
Sí, el script se convirtió de Epoch a Legible. El script cambió solamente el campo de marca de hora, conservando el resto del archivo.
Comparen el contenido del archivo con la salida impresa. ¿Por qué está la siguiente línea: ||Wed 31 Dec 1969 07:00:00 PM EST?
El motivo de la línea adicional es que el archivo tiene una línea vacía al final, lo que llevó al script a interpretarlo erróneamente como 0 y a convertirlo en una marca de hora legible.
Al interpretar la línea vacía como 0, el script convirtió 0 Unix Epoch a Legible. 0 Unix Epoch se traduce en 0 segundos después de la medianoche del 1 de enero de 1970. El script muestra “miércoles 31 de diciembre de 1969, 07:00:00 p. m. (hora del este)” ya que se ajusta automáticamente para la zona horaria. Debido a que CyberOps Workstation está configurada para la hora del este (UTC -5), el script muestra la medianoche del 1 de enero de 1970, menos 5 horas.
d. Utilicen nano (o el editor de texto que prefieran) para quitar la línea vacía adicional del final del archivo y vuelvan a ejecutar el script AWK.
[analyst@secOps lab.support.files]$ nano applicationX_in_epoch.log
¿Ahora la salida es correcta? Explique.
Sí. Ya que se eliminó la línea vacía, el script no creó datos adicionales y los agregó al archivo de registro.
e. Si bien imprimir el resultado en la pantalla es útil para solucionar problemas en el script, los analistas probablemente necesitarán guardar la salida en un archivo de texto. Redirijan la salida del script anterior a un archivo de nombre log para guardarlo en un archivo:
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS="|"}{$3=strftime("%c",$3)} {print}' applicationX_in_epoch.log > applicationX_in_human.log
[analyst@secOps lab.support.files]$
¿Qué imprimió el comando anterior? ¿Es esperable?
No se imprimió nada en la pantalla. Sí, se prevé, ya que la salida del comando se redirigió a un archivo de texto llamado applicationX_in_human.log.
f. Utilicen cat para ver el archivo log. Observen que ahora se quitó la línea adicional y que las marcas de hora correspondientes a las entradas de registro se han convertido al formato legible.
[analyst@secOps lab.support.files]$ cat applicationX_in_human.log 2|Z|Mon 18 Aug 2008 11:00:00 AM EDT|AF|0 3|N|Tue 19 Aug 2008 11:00:00 AM EDT|AF|89 4|N|Sun 07 Sep 2008 11:00:00 AM EDT|AS|12 1|Z|Mon 08 Sep 2008 11:00:00 AM EDT|AS|67 5|N|Tue 09 Sep 2008 11:00:00 AM EDT|EU|23 6|R|Wed 10 Sep 2008 11:00:00 AM EDT|OC|89 [analyst@secOps lab.support.files]$
Parte 2: Normalizar marcas de hora en un archivo de registro Apache
En forma similar a lo que se hizo con el archivo applicationX_in_epoch.log, los archivos de registro Apache también se pueden normalizar. Sigan los pasos que se detallan a continuación para convertir marcas de hora Unix Epoch al formato legible. Analicen el siguiente archivo de registro Apache, apache_in_epoch.log:
[analyst@secOps lab.support.files]$ cat apache_in_epoch.log 198.51.100.213 - - [1219071600] "GET /twiki/bin/edit/Main/Double_bounce_sender?topicparent=Main.ConfigurationVariables HTTP/1.1" 401 12846 198.51.100.213 - - [1219158000] "GET /twiki/bin/rdiff/TWiki/NewUserTemplate?rev1=1.3&rev2=1.2 HTTP/1.1" 200 4523 198.51.100.213 - - [1220799600] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 198.51.100.213 - - [1220886000] "GET /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 200 7352 198.51.100.213 - - [1220972400] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 198.51.100.213 - - [1221058800] "GET /twiki/bin/oops/TWiki/AppendixFileSystem?template=oopsmore&m1=1.12&m2=1.12 HTTP/1.1" 200 11382
El archivo de registro Apache anterior contiene seis entradas que registran eventos relacionados con el servidor web Apache. Cada entrada tiene siete campos. Los campos están delimitados por un espacio:
- La primera columna contiene la dirección IPv4 (51.100.213) del cliente web que está elevando la solicitud.
- La segunda y tercera columna no se utilizan, y se emplea un carácter de “–“ para representar que no hay ningún valor.
- La cuarta columna contiene la marca de hora en Unix Epoch, por ejemplo: [1219071600].
- La quinta columna contiene texto con detalles sobre el evento; eso incluye direcciones URL y los parámetros de la petición web. Las seis entradas son mensajes HTTP GET. Como estos mensajes incluyen espacios, todo el campo está encerrado entre comillas.
- La sexta columna contiene el código de estado HTTP, por ejemplo: 401.
- La séptima columna contiene el tamaño de la respuesta al cliente (en bytes), por ejemplo: 12846.
En forma similar a lo se hizo en la Parte uno, se creará un script para convertir la marca de hora del formato Epoch al legible.
a. En primer lugar, respondan las siguientes preguntas. Son cruciales para la construcción del script.
En el contexto de la conversión de marcas de hora, ¿qué carácter funcionará bien como carácter delimitador para el archivo de registro Apache anterior?
El carácter de espacio.
¿Cuántas columnas contiene el archivo de registro Apache anterior?
7
¿En el archivo de registro Apache anterior, qué columna contiene la marca de hora en Unix Epoch?
Columna 4
b. En el terminal de la VM CyberOps Workstation se almacena una copia del archivo de registro Apache (apache_in_epoch.log), en /home/analyst/lab.support.files.
c. Utilicen un script de awk para convertir el campo de la marca de hora al formato legible. Observen que el comando contiene el mismo script que ya se utilizó, pero con algunos ajustes en el campo de la marca de hora y en el nombre de archivo.
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}{$4=strftime("%c",$4)} {print}' /home/analyst/lab.support.files/apache_in_epoch.log
¿El script pudo convertir las marcas de hora correctamente? Describan la salida.
No. Todas las marcas de hora son ahora, miércoles 31 de diciembre de 1969, 07:00:00 p. m., hora del este.
d. Antes de seguir adelante, piensen en la salida del script. ¿Pueden decir qué hizo que la salida fuese incorrecta? ¿El script es incorrecto? ¿Cuáles son las diferencias relevantes entre log y apache_in_epoch.log?
El problema son los corchetes en el archivo del curso. El script prevé que la marca de hora esté en el formato de Unix Epoch, que no incluye los corchetes. Debido a que el script no sabe qué número representa el carácter “[”, asume que es 0, y devuelve el comienzo de hora de Unix en UTC -5.
e. Para corregir el problema se deben quitar los corchetes del campo de la marca de hora antes de realizar la conversión. Corrijan el script; para ello, agreguen dos acciones antes de la conversión, de la siguiente manera:
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}
{gsub(/\[|\]/,"",$4)}{print}{$4=strftime("%c",$4)}{print}' apache_in_epoch.log
Observen que, después de especificar el espacio como delimitador con {FS=OFS=” “}, hay una acción de expresión regular para hacer coincidir y reemplazar los corchetes por una cadena vacía; eso quita efectivamente los corchetes que aparecen en el campo de la marca de hora. La segunda acción imprime la línea actualizada para que se pueda realizar la acción de la conversión.
- gsub(): esta es una función interna de AWK que se utiliza para ubicar y sustituir cadenas. En el script anterior, gsub() recibió tres parámetros separados por comas, que se describen a continuación.
- /\[|\]/: esta es una expresión regular que se pasa a gsub() como primer parámetro. La expresión regular debe leerse como ‘find “[“ OR “]”’. A continuación se muestra el desglose de la expresión:
- El primer y último carácter “/” marcan el comienzo y el final del bloque de búsqueda. Cualquier elemento que se incluya entre la primera y la segunda “/” estará relacionado con la búsqueda. El carácter “\” se utiliza para dar escape al siguiente “[“. El escape es necesario porque “[“ también puede ser utilizado por un operador en expresiones regulares. Al escapar el “[“ con una barra “\” precedente, le estamos diciendo al intérprete que el “]” forma parte del contenido y no de un operador. El carácter “|” es el operador OR. Tengan en cuenta que la barra «|» no tiene escape y, por lo tanto puede verse como un operador. Por último, la expresión regular da escape al corchete de cierre con “\]”, como se hizo antes.
- «»: esto representa la ausencia de caracteres, o una cadena vacía. Este parámetro le dice a gsub() con qué debe reemplazar “[“ y “]”, cuando los encuentre. Al reemplazar “[“ y “]” por “”, gsub() quita efectivamente los caracteres “[“ y “]”.
- $4: esto le dice a gsub() que trabaje solamente en la cuarta columna de la línea actual, la columna de la marca de hora.
Nota: La interpretación de expresiones regulares es un tema del examen de SECOPS. Las expresiones regulares se analizan más detalladamente en otra práctica de laboratorio de este capítulo. Sin embargo, pueden buscar tutoriales en Internet.
f. En un terminal de la VM CyberOps Workstation, ejecuten el script modificado, de la siguiente manera:
[analyst@secOps lab.support.files]$ awk 'BEGIN {FS=OFS=" "}{gsub(/\[|\]/,"",$4)}{print}{$4=strftime("%c",$4)}{print}' apache_in_epoch.log
¿El script pudo convertir las marcas de hora correctamente esta vez? Describan la salida.
Sí. La salida ahora muestra dos líneas para cada entrada de registro. La primera línea muestra la fecha y hora en formato Unix Epoch, y la segunda línea es la misma entrada de registro con la marca de hora que se muestra con formato legible.
Parte 3: Preparación de archivos de registro en Security Onion
Como la normalización de los archivos de registro es importante, las herramientas para el análisis de registros a menudo incluyen características de normalización de registros. Las herramientas que no incluyen tales características a menudo dependen de complementos para la normalización y preparación de registros. La meta de estos complementos es permitir que las herramientas para el análisis de registros normalicen y preparen los archivos de registro recibidos para que las herramientas puedan utilizarlos.
El dispositivo Security Onion depende de diversas herramientas para proporcionar servicios de análisis de registros. ELSA, Bro, Snort y SGUIL sin duda son las más utilizadas.
ELSA (Enterprise Log Search and Archive [Búsqueda y archivo empresarial de registros]) es una solución que permite hacer lo siguiente:
- Normalizar, almacenar e indexar registros en volúmenes y velocidades sin límite.
- Proporcionar una interfaz de búsqueda y API simple y transparente.
- Proporcionar una infraestructura para alertar, informar y compartir registros.
- Controlar las acciones de los usuarios con permisos locales o basados en LDAP/AD.
- Contar con un sistema complementario para realizar acciones con los registros.
- Funcionar como un proyecto totalmente gratuito y de código abierto.
Bro es un marco diseñado para analizar el tráfico de red y generar registros de eventos en función de dicho tráfico. Al analizar el tráfico de red, Bro crea registros que describen eventos como los siguientes:
- Conexiones de red TCP/UDP/ICMP
- Actividad del DNS
- Actividad de FTP
- Peticiones y respuestas HTTPS
- Protocolos de enlace SSL/TLS
Snort y SGUIL
Snort es un IDS que depende de reglas predefinidas para señalar tráfico potencialmente dañino. Snort analiza todas las porciones de los paquetes de red (encabezados y cargas útiles) en busca de los patrones definidos en sus reglas. Cuando los encuentra, Snort toma la medida definida en la misma regla.
SGUIL proporciona una interfaz gráfica para los registros y las alertas de Snort, lo que permite que el analista de seguridad pase de SGUIL a otras herramientas para obtener más información. Por ejemplo: si se envía un paquete potencialmente malicioso al servidor web de la organización y Snort elevó una alerta al respecto, SGUIL incluirá esa alerta en una lista. Entonces, el analista puede hacer clic derecho sobre esa alerta para buscar en las bases de datos de ELSA o Bro y así comprender mejor el evento.
Nota: El listado de directorios puede diferir del resultado de muestra que se incluye a continuación.
Paso 1: Pasen a Security Onion.
Inicie la VM de Security Onion desde el panel de control de VirtualBox (nombre de usuario: analyst/contraseña: cyberops). Se puede cerrar la VM CyberOps Workstation para liberar memoria en el servidor para esta parte de la práctica de laboratorio.
Paso 2: Registros de ELSA
a. Abran una ventana de terminal en la VM Security Onion. Pueden acceder al menú de aplicaciones que se muestra en la siguiente captura de pantalla:
b. También pueden hacer clic derecho en el Escritorio > Open Terminal Here (Abrir terminal aquí), tal como se muestra en la siguiente captura de pantalla:
c. Los registros de ELSA se pueden encontrar en el directorio /nsm/elsa/data/elsa/log/. Cambien de directorio con el siguiente comando:
analyst@SecOnion:~/Desktop$ cd /nsm/elsa/data/elsa/log analyst@SecOnion:/nsm/elsa/data/elsa/log$
d. Utilicen el comando ls –l para incluir los archivos en una lista:
analyst@SecOnion:/nsm/elsa/data/elsa/log$ ls -l total 99112 total 169528 -rw-rw---- 1 www-data sphinxsearch 56629174 Aug 18 14:15 node.log -rw-rw---- 1 www-data sphinxsearch 6547557 Aug 3 07:34 node.log.1.gz -rw-rw---- 1 www-data sphinxsearch 7014600 Jul 17 07:34 node.log.2.gz -rw-rw---- 1 www-data sphinxsearch 6102122 Jul 13 07:34 node.log.3.gz -rw-rw---- 1 www-data sphinxsearch 4655874 Jul 8 07:35 node.log.4.gz -rw-rw---- 1 www-data sphinxsearch 6523029 Aug 18 14:15 query.log -rw-rw---- 1 www-data sphinxsearch 53479942 Aug 18 14:15 searchd.log -rw-rw---- 1 www-data sphinxsearch 32613665 Aug 18 14:15 web.log analyst@SecOnion:/nsm/elsa/data/elsa/log$
Paso 3: Registros de Bro en Security Onion
a. Los registros de Bro se almacenan en /nsm/bro/logs/. Como es habitual en sistemas Linux, los archivos de registro se rotan en función de la fecha, se les cambia el nombre y se almacenan en el disco. Los archivos de registro actuales se pueden encontrar en el directorio current. Desde la ventana del terminal, cambien de directorio con el siguiente comando:
analyst@SecOnion:/nsm/elsa/data/elsa/log$ cd /nsm/bro/logs/current analyst@SecOnion:/nsm/logs/current$
b. Utilicen el comando ls -l para ver todos los archivos de registro que generó Bro:
analyst@SecOnion:/nsm/bro/logs/current$ ls -l total 100 -rw-rw-r-- 1 sguil sguil 368 Aug 18 14:02 capture_loss.log -rw-rw-r-- 1 sguil sguil 46031 Aug 18 14:16 communication.log -rw-rw-r-- 1 sguil sguil 2133 Aug 18 14:03 conn.log -rw-rw-r-- 1 sguil sguil 2028 Aug 18 14:16 stats.log -rw-rw-r-- 1 sguil sguil 40 Aug 18 14:00 stderr.log -rw-rw-r-- 1 sguil sguil 188 Aug 18 13:46 stdout.log analyst@SecOnion:/nsm/bro/logs/current$
Paso 4: Archivos de registro de Snort
a. Los archivos de registro de Snort se pueden encontrar en /nsm/sensor_data/. Cambien de directorio de la siguiente manera:
analyst@SecOnion:/nsm/bro/logs/current$ cd /nsm/sensor_data analyst@SecOnion:/nsm/sensor_data$
b. Utilicen el comando ls -l para ver todos los archivos de registro que generó Snort:
analyst@SecOnion:/nsm/sensor_data$ ls -l total 16 drwxrwxr-x 7 sguil sguil 4096 Jun 19 23:16 seconion-eth0 drwxrwxr-x 7 sguil sguil 4096 Jun 19 23:16 seconion-eth1 drwxrwxr-x 7 sguil sguil 4096 Jun 19 23:16 seconion-eth2 drwxrwxr-x 5 sguil sguil 4096 Jun 19 23:08 seconion-eth3 analyst@SecOnion:/nsm/sensor_data$
c. Observen que Security Onion separa los archivos en función de la interfaz. Como la imagen de la VM Security Onion tiene cuatro interfaces, se conservan cuatro directorios. Utilicen el comando ls –l seconion-eth0 para ver los archivos que generó la interfaz ethernet 0.
analyst@SecOnion:/nsm/sensor_data$ ls -l seconion-eth0/ total 52 drwxrwxr-x 2 sguil sguil 4096 Jun 19 23:09 argus drwxrwxr-x 10 sguil sguil 4096 Jul 7 12:09 dailylogs drwxrwxr-x 2 sguil sguil 4096 Jun 19 23:08 portscans drwxrwxr-x 2 sguil sguil 4096 Jun 19 23:08 sancp drwxr-xr-x 2 sguil sguil 4096 Jul 7 12:12 snort-1 -rw-r--r-- 1 sguil sguil 27566 Jul 7 12:12 snort-1.stats -rw-r--r-- 1 root root 0 Jun 19 23:08 snort.stats analyst@SecOnion:/nsm/sensor_data$
Paso 5: Registros varios
a. Si bien en el directorio /nsm/ se almacenan algunos archivos de registro, se pueden encontrar otros más específicos en /var/log/nsm/. Cambien de directorio y utilicen el comando ls -l para ver todos los archivos de registro presentes en el directorio.
analyst@SecOnion:/nsm/sensor_data$ cd /var/log/nsm/ analyst@SecOnion:/var/log/nsm$ ls -l total 8364 -rw-r--r-- 1 sguil sguil 4 Aug 18 14:56 eth0-packets.log -rw-r--r-- 1 sguil sguil 4 Aug 18 14:56 eth1-packets.log -rw-r--r-- 1 sguil sguil 4 Aug 18 14:56 eth2-packets.log -rw-r--r-- 1 sguil sguil 182 Aug 18 13:46 ossec_agent.log -rw-r--r-- 1 sguil sguil 202 Jul 11 12:02 ossec_agent.log.20170711120202 -rw-r--r-- 1 sguil sguil 202 Jul 13 12:02 ossec_agent.log.20170713120201 -rw-r--r-- 1 sguil sguil 202 Jul 14 12:02 ossec_agent.log.20170714120201 -rw-r--r-- 1 sguil sguil 202 Jul 15 12:02 ossec_agent.log.20170715120202 -rw-r--r-- 1 sguil sguil 249 Jul 16 12:02 ossec_agent.log.20170716120201 -rw-r--r-- 1 sguil sguil 202 Jul 17 12:02 ossec_agent.log.20170717120202 -rw-r--r-- 1 sguil sguil 202 Jul 28 12:02 ossec_agent.log.20170728120202 -rw-r--r-- 1 sguil sguil 202 Aug 2 12:02 ossec_agent.log.20170802120201 -rw-r--r-- 1 sguil sguil 202 Aug 3 12:02 ossec_agent.log.20170803120202 -rw-r--r-- 1 sguil sguil 202 Aug 4 12:02 ossec_agent.log.20170804120201 -rw-r--r-- 1 sguil sguil 42002 Aug 4 07:33 pulledpork.log drwxr-xr-x 2 sguil sguil 4096 Aug 18 13:46 seconion-eth0 drwxr-xr-x 2 sguil sguil 4096 Aug 18 13:47 seconion-eth1 drwxr-xr-x 2 sguil sguil 4096 Aug 18 13:47 seconion-eth2 drwxr-xr-x 2 sguil sguil 4096 Jun 19 23:08 securityonion -rw-r--r-- 1 sguil sguil 1647 Jun 19 23:09 securityonion-elsa-config.log -rw-r--r-- 1 sguil sguil 7708106 Aug 18 14:56 sensor-clean.log -rw-r--r-- 1 sguil sguil 1603 Aug 4 00:00 sensor-newday-argus.log -rw-r--r-- 1 sguil sguil 1603 Aug 4 00:00 sensor-newday-http-agent.log -rw-r--r-- 1 sguil sguil 8875 Aug 4 00:00 sensor-newday-pcap.log -rw-r--r-- 1 sguil sguil 53163 Aug 4 05:01 sguil-db-purge.log -rw-r--r-- 1 sguil sguil 369738 Aug 4 07:33 sid_changes.log -rw-r--r-- 1 sguil sguil 22598 Aug 8 01:35 so-bro-cron.log drwxrwxr-x 2 sguil securityonion 4096 Jun 19 23:09 so-elsa -rw------- 1 sguil sguil 7535 Jun 19 23:09 sosetup.log -rw-r--r-- 1 sguil sguil 14046 Jun 19 23:09 sosetup_salt_call.log -rw-r--r-- 1 sguil sguil 63208 Jun 19 23:09 sphinx_initialization.log -rw-r--r-- 1 sguil sguil 81 Aug 18 14:55 squert-ip2c-5min.log -rw-r--r-- 1 sguil sguil 1079 Jul 16 06:26 squert-ip2c.log -rw-r--r-- 1 sguil sguil 125964 Aug 18 14:54 watchdog.log analyst@SecOnion:/var/log/nsm$
Observen que el directorio que se muestra arriba también contiene registros utilizados por herramientas secundarias como OSSEC, Pulledpork, Sphinx y Squert.
b. Tómense un momento para investigar estas herramientas en Google y respondan las siguientes preguntas:
En cada una de las herramientas antes enumeradas, describan su función, importancia y ubicación en el flujo de trabajo del analista de seguridad.
Sphinx es un motor de búsqueda de código abierto y es utilizado por ELSA para proporcionar capacidades de búsqueda.
Pulledpork es un sistema de administración de reglas de Snort. Facilita la actualización de las reglas de Snort. Las reglas de Snort desactualizadas hacen que todo el sistema deje de ser útil.
OSSEC es un sistema utilizado para normalizar y concentrar registros del sistema local. Cuando se implementa en toda la organización, OSSEC permite que un analista tenga una imagen clara de lo que está sucediendo en los sistemas.
Squert es una herramienta visual que intenta proporcionar un contexto adicional a los eventos a través del uso de metadatos, representaciones de series de tiempo y conjuntos de resultados ponderados y agrupados lógicamente.
Parte 4: Reflexión
La normalización de registros es importante y depende del entorno implementado.
Las herramientas populares incluyen sus propias características de normalización, pero los registros también se pueden normalizar manualmente.
Cuando estén normalizando y preparando archivos de registro manualmente, revisen bien los scripts para garantizar que se llegue al resultado deseado. Un script de normalización mal escrito puede modificar los datos, y eso afectaría directamente el trabajo del analista.
