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.