GNU/Linux >> Linux Esercitazione >  >> Linux

Wazuh Blocco degli attacchi con Active Response

La risposta attiva consente a Wazuh di eseguire comandi su un agente in risposta a determinati trigger. In questo caso d'uso, simuliamo un attacco SSH Brute Force e configuriamo una risposta attiva per bloccare l'IP dell'attaccante. Quindi, in questo post imparerai come bloccare gli attacchi con una risposta attiva.

Rilevamento dell'attacco

Prima di tutto, dobbiamo sapere quando eseguire la risposta. Possiamo utilizzare una delle seguenti opzioni:

  • ID regola:la risposta verrà eseguita su qualsiasi evento con l'ID definito.
  • Gruppo di regole:la risposta verrà eseguita su qualsiasi evento nel gruppo definito.
  • Livello:la risposta verrà eseguita su qualsiasi evento con questo livello o superiore.

In questo caso d'uso, vogliamo prevenire SSH brute force attacks quindi quando la regola 5712 - SSHD brute force trying to get access to the system viene attivato, eseguirà la corretta risposta attiva per bloccare l'IP dell'attaccante.

Definizione del comando

Sappiamo quando verrà eseguita la risposta attiva, ora dobbiamo definire cosa farà. Puoi creare il tuo script per bloccare un IP o qualsiasi altra azione, ma Wazuh viene fornito con una serie di script comuni utilizzati in risposta attiva. Questi script sono in /var/ossec/active-response/bin/ . Utilizzeremo il firewall-drop script che funziona con i comuni sistemi operativi Linux/Unix e consente di bloccare un IP dannoso utilizzando il firewall locale.

Definisci il comando in ossec.conf del tuo manager Wazuh:

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

Definizione della risposta attiva per bloccare gli attacchi

Definisci la risposta attiva in ossec.conf del tuo manager Wazuh:

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

Riavvia il gestore Wazuh per applicare le modifiche.

Prova del concetto

Simuleremo un attacco SSH, l'attacco verrà eseguito da 10.0.0.6 al nostro agente in esecuzione su 10.0.0.5. Per prima cosa, controlliamo se c'è connettività tra l'attaccante e l'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

Ora, tentiamo di connetterci all'agente tramite SSH più volte utilizzando un utente non valido:

$ 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).

Dopo 8 tentativi, possiamo vedere nel manager come viene attivata la regola:

Se proviamo a eseguire il ping dell'agente dall'attaccante, vediamo che non è possibile:

[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

Generazione di un avviso quando viene attivata una risposta attiva

Ogni agente ha un file di registro in /var/ossec/logs/active-responses.log dove sono registrate le attività di risposta attiva. Per impostazione predefinita, questo file viene monitorato.

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

Quando viene attivata la risposta attiva, possiamo vedere l'avviso corrispondente:

Questo è possibile perché la regola 651 è definita in ossec_rules.xml . Se crei il tuo script, devi aggiungere la regola corretta.

Lista bianca

Possiamo anche impostare un elenco di indirizzi IP che non dovrebbero mai essere bloccati dalla risposta attiva. Nella sezione globale di ossec.conf nel Gestore, utilizza il campo white_list . Consente l'indirizzo IP o il 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 tempo di blocco per i trasgressori recidivi

Abbiamo impostato un tempo di blocco di 30 minuti per la nostra risposta attiva, ma nel caso in cui sia necessario aumentare questo tempo di blocco per i trasgressori recidivi è possibile aggiungere la seguente configurazione in ossec.conf di ciascun agente:

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

La prima volta che viene attivata la risposta attiva, bloccherà l'IP per 30 minuti, la seconda volta per 60 minuti, la terza volta per 120 minuti e infine la quarta volta per 180 minuti.

Grazie alla risposta attiva puoi eseguire azioni rispondendo a diversi scenari e limitando le attività dannose e bloccando gli attacchi. Tieni presente che qualsiasi risposta automatizzata ha un rischio implicito, quindi definisci attentamente le tue risposte.


Linux
  1. Traccia del kernel con trace-cmd

  2. Blocco delle botnet di spam internazionali con un plug-in Postfix

  3. Autenticazione Git con l'utente di Active Directory?

  4. Scopri come fermare gli attacchi XML-RPC con .htaccess

  5. Configura Active Directory con DNS integrato

Sostituisci du con polvere su Linux

Integra Samba con Active Directory su CentOS

Installazione dell'agente WAZUH

Rilevamento di Log4Shell con Wazuh

Come connettersi con Samba a Linux Active Directory

Uccidi la finestra attualmente attiva con una scorciatoia da tastiera