GNU/Linux >> Tutoriales Linux >  >> Linux

Wazuh Bloqueo de ataques con Active Response

La respuesta activa permite que Wazuh ejecute comandos en un agente en respuesta a ciertos desencadenantes. En este caso de uso, simulamos un ataque SSH Brute Force y configuramos una respuesta activa para bloquear la IP del atacante. Entonces, en esta publicación aprenderá cómo bloquear ataques con respuesta activa.

Detectar el ataque

En primer lugar, necesitamos saber cuándo ejecutar la respuesta. Podemos utilizar una de las siguientes opciones:

  • Id. de regla:la respuesta se ejecutará en cualquier evento con el Id. definido.
  • Grupo de reglas:la respuesta se ejecutará en cualquier evento del grupo definido.
  • Nivel:la respuesta se ejecutará en cualquier evento con este nivel o superior.

En este caso de uso, queremos evitar SSH brute force attacks entonces cuando la regla 5712 - SSHD brute force trying to get access to the system se activa, ejecutará la respuesta activa adecuada para bloquear la IP del atacante.

Definiendo el comando

Sabemos cuándo se ejecutará la respuesta activa, ahora tenemos que definir qué hará. Puede crear su propio script para bloquear una IP o cualquier otra acción, pero Wazuh viene con un conjunto de scripts comunes que se usan en la respuesta activa. Estos scripts están en /var/ossec/active-response/bin/ . Vamos a usar el firewall-drop script que funciona con los sistemas operativos comunes Linux/Unix y permite bloquear una IP maliciosa usando el firewall local.

Defina el comando en el ossec.conf de tu administrador de Wazuh:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

Definir la respuesta activa para bloquear ataques

Defina la respuesta activa en el ossec.conf de tu administrador de Wazuh:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>
  <timeout>1800</timeout>
</active-response>

Reinicie el administrador de Wazuh para aplicar los cambios.

Prueba de concepto

Vamos a simular un ataque SSH, el ataque se ejecutará desde 10.0.0.6 a nuestro agente ejecutándose en 10.0.0.5. Primero, comprobamos si hay conectividad entre el atacante y el agente:

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=0.602 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=0.774 ms

Ahora, intentamos conectarnos al agente por SSH varias veces utilizando un usuario no válido:

$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).
$ ssh 10.0.0.5
Permission denied (publickey).

Después de 8 intentos, podemos ver en el administrador cómo se dispara la regla:

Si intentamos hacer ping al agente del atacante, vemos que no es posible:

[ec2-user@ip-10-0-0-6 ~]$ ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
^C
--- 10.0.0.5 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11000ms

Generar una alerta cuando se activa una respuesta activa

Cada agente tiene un archivo de registro en /var/ossec/logs/active-responses.log donde se registran las actividades de respuesta activa. De manera predeterminada, este archivo está siendo monitoreado.

<ossec_config>
  <localfile>
      <log_format>syslog</log_format>
      <location>/var/ossec/logs/active-responses.log</location>
  </localfile>
</ossec_config>

Cuando se dispara la respuesta activa podemos ver la alerta correspondiente:

Esto es posible porque la regla 651 está definida en ossec_rules.xml . Si crea su propio script, debe agregar la regla adecuada.

Lista blanca

También podemos establecer una lista de direcciones IP que nunca deben ser bloqueadas por la respuesta activa. En la sección global de ossec.conf en el Administrador, use el campo white_list . Permite dirección IP o netblock

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <email_notification>no</email_notification>
    <logall>yes</logall>
    <white_list>10.0.0.6</white_list>
  </global>

Aumento del tiempo de bloqueo para infractores reincidentes

Configuramos un tiempo de bloqueo de 30 minutos para nuestra respuesta activa, pero en caso de que necesite aumentar este tiempo de bloqueo para reincidentes, puede agregar la siguiente configuración en el ossec.conf de cada agente:

<active-response>
  <repeated_offenders>60,120,180</repeated_offenders>
</active-response>

La primera vez que se activa la respuesta activa, bloqueará la IP durante 30 minutos, la segunda vez durante 60 minutos, la tercera vez durante 120 minutos y finalmente la cuarta vez durante 180 minutos.

Gracias a la respuesta activa puedes realizar acciones respondiendo a varios escenarios y restringiendo actividades maliciosas y bloqueando ataques. Tenga en cuenta que cualquier respuesta automática tiene un riesgo implícito, así que defina sus respuestas con cuidado.


Linux
  1. Seguimiento del kernel con trace-cmd

  2. Bloqueo de botnets de spam internacionales con un complemento de Postfix

  3. Aprenda cómo detener los ataques XML-RPC con .htaccess

  4. Configurar Active Directory con DNS integrado

  5. ¿La forma más segura de realizar mysqldump en un sistema en vivo con lecturas y escrituras activas?

Reemplace du con polvo en Linux

Integre Samba con Active Directory en CentOS

Instalación del agente WAZUH

Detectando Log4Shell con Wazuh

Cómo conectarse con Samba a Linux Active Directory

Elimine la ventana actualmente activa con un atajo de teclado