Antecedentes: Como líder mundial en importación y exportación, Vandalay Industries ha sido el objetivo de muchos adversarios que intentan alterar su negocio en línea. Recientemente, Vandaly ha estado experimentando ataques DDOS contra sus servidores web.
Un ataque DDOS no solo dejó fuera de línea los servidores web, sino que la velocidad de carga y descarga también se vio significativamente afectada después de la interrupción. Su equipo de redes proporcionó resultados de una velocidad de red analizada en el momento del último ataque DDOS.
Archivo de prueba de velocidad
Captura de pantalla del archivo 'server_speedtest.csv' cargado en Splunk:
eval , cree un campo llamado ratio que muestre la relación entre las velocidades de carga y descarga. Sugerencia: El formato para crear una proporción es: | eval new_field_name = 'fieldA' / 'fieldB'
Consulta utilizada en Splunk para generar una relación entre las velocidades de carga y descarga - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
Podemos ver la proporción de descargas y cargas de esta consulta.
_timeIP_ADDRESSDOWNLOAD_MEGABITSUPLOAD_MEGABITSratioSugerencia: utilice el siguiente formato para el comando de tabla: | tabla campoA campoB campoC
Consulta utilizada en Splunk para generar una relación entre las velocidades de carga y descarga - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
En la captura de pantalla anterior, podemos ver el cronograma total del evento de cuándo tuvieron lugar las descargas y cargas.
En la captura de pantalla anterior, podemos ver la hora en que se realizaron las descargas y cargas, así como la dirección IP de origen que estaba realizando esta acción.
En la captura de pantalla anterior, podemos ver una representación visual de estos eventos de descarga y carga en un formato de gráfico de columnas. La hora se muestra en la parte inferior y esto hace que nuestros datos sean mucho más legibles.
Según nuestros hallazgos en las consultas anteriores, podemos ver que la velocidad de descarga y carga se redujo drásticamente aproximadamente a las 2:30 p.m. del 23 de febrero. Podemos ver esto en la siguiente captura de pantalla:
Podemos ver que las descargas cayeron a 7,87 a las 2:30 p.m. Esta es una caída drástica de los 109,16 megabits que era el evento anterior. Es justo suponer entonces que esto fue cuando comenzó el ataque.
Podemos ver en la captura de pantalla anterior que los megabits descargados aumentaron de 17,56 a 65,34, lo cual es un aumento drástico. Por lo tanto, es seguro asumir que esto ocurre cuando el sistema comenzó a recuperarse y a volver al flujo de tráfico de red normal.
Podemos ver en la captura de pantalla anterior que los megabits descargados saltaron a 123,91 desde 78,34 aproximadamente a las 11:30 p. m. del 23 de febrero. Es seguro asumir que este es el momento en que el flujo de tráfico de la red se ha estabilizado y ha vuelto a la normalidad.
Envíe una captura de pantalla de su informe y la respuesta a las preguntas anteriores.
Antecedentes: debido a la frecuencia de los ataques, su gerente debe asegurarse de que los datos confidenciales de los clientes en sus servidores no sean vulnerables. Dado que Vandalay utiliza los escáneres de vulnerabilidades de Nessus, ha realizado los análisis de las últimas 24 horas para ver si hay vulnerabilidades críticas.
Para obtener más información sobre Nessus, lea el siguiente enlace: https://www.tenable.com/products/nessus
Resultados del escaneo Nessus
Captura de pantalla de los resultados del escaneo Nesus cargados en Splunk:
10.11.36.23 . Utilice dest_ip="10.11.36.23" en la consulta
Vale la pena señalar que existen cinco tipos de niveles de gravedad que buscan estos registros, como se muestra a continuación:
Queremos filtrar cualquier vulnerabilidad cuyo nivel de gravedad sea un valor "crítico". Podemos usar severity="crtiical" en nuestra consulta.
La consulta completa es source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"
Vea la captura de pantalla a continuación para ver la consulta completa que muestra el recuento de vulnerabilidades críticas del servidor de base de datos del cliente desde este archivo de registro:
Se encontraron un total de 49 vulnerabilidades críticas cuando la IP de destino era 10.11.36.23 (que es el servidor de la base de datos).
[email protected] .Cree la alerta haciendo clic en "guardar como" y luego en "alerta" después de haber generado los resultados de la consulta anterior:
Ingrese detalles para generar alertas cada vez que Nessus detecte una vulnerabilidad en el servidor de la base de datos. Ingrese nombre, descripción y cualquier otra información relativa:
Ingrese los detalles del correo electrónico para enviar la alerta generada a - [email protected] e ingrese los detalles del mensaje que se enviará con el correo electrónico:
Continúe ingresando los detalles de la alerta y luego haga clic en "guardar":
Una vez guardado deberíamos poder ver la alerta y editarla si lo deseamos:
Envíe una captura de pantalla de su informe y una captura de pantalla de la prueba de que se ha creado la alerta.
Antecedentes: un servidor Vandalay también está experimentando ataques de fuerza bruta en su cuenta de administrador. A la gerencia le gustaría que usted configure el monitoreo para notificar al equipo SOC si vuelve a ocurrir un ataque de fuerza bruta.
Inicios de sesión de administrador
Captura de pantalla del archivo 'Administrator_logs.csv' cargado en Splunk:
Consejos:
Busque el campo de nombre para encontrar inicios de sesión fallidos.
Tenga en cuenta que el ataque duró varias horas.
Como queremos buscar indicadores de un ataque de fuerza bruta, queremos profundizar en los registros en los que las cuentas no pudieron iniciar sesión. Si navegamos al campo 'nombre' podemos ver los valores que contiene en los registros. En este caso, podemos ver un recuento de 1004 "Una cuenta no pudo iniciar sesión". Este es un buen indicador de que se ha producido un ataque de fuerza bruta. Ver captura de pantalla:
Ahora, si agregamos esto a nuestra búsqueda, podemos ver el total de eventos cuando esto ocurrió. Luego podemos ver cuándo ocurrieron la mayoría de estos eventos, lo cual es un buen indicador de cuándo ocurrió. Ver captura de pantalla:
Como podemos ver, hay un aumento bastante grande en los eventos por los cuales "Una cuenta no pudo iniciar sesión" alrededor de las 9 am del 21 de febrero. Podemos ver del total de 1004 eventos ocurridos, a las 9 am hubo 124 de estos eventos con números similares apareciendo en las horas posteriores. Por lo tanto, creo que el ataque comenzó alrededor de esta hora: las 9:00 a. m. del 21 de febrero de 2020.
Podemos ver en la línea de tiempo de estos eventos que 124 es un gran pico. En las horas previas a este evento, la mayor cantidad de inicios de sesión incorrectos fue alrededor de 23. Podemos considerar este comportamiento normal. Ver captura de pantalla:
Con esto en mente y teniendo en cuenta que hubo entre 124 y 135 intentos de inicio de sesión cuando ocurrió el ataque de fuerza bruta, consideraría una base de aproximadamente 40 inicios de sesión incorrectos por hora. Tendría los rangos de inicios de sesión incorrectos por hora de la siguiente manera:
[email protected] si se activa.Para crear una alerta para este tipo de evento, seguí los siguientes pasos:
Haga clic en "guardar como" y luego en "alertar":
Complete los detalles de la alerta, incluido cuándo activarla (cualquier cosa que supere los 25 intentos por hora):
Introduzca los detalles de una acción. En este caso estaremos enviando un correo electrónico a [email protected] :
Guarda la alerta y luego podremos verla:
Ahora hemos creado con éxito una alerta que se activará cuando haya más de 25 eventos de una cuenta que no pueda iniciar sesión.
Envíe las respuestas a las preguntas sobre el momento, la línea de base y el umbral de la fuerza bruta. Además, proporcione una captura de pantalla como prueba de que se ha creado la alerta.
