Wazuh – Regole

Published by Lello on

In questo post familizzieremo con le regole di Wazuh; le regole sono mantenute da Wazuh Inc. e, essendo Wazuh un progetto open-source, ad esse contribuisce la community di Wazuh.

Le regole vengono utilizzate per rilevare attacchi, intrusioni, uso improprio del software, problemi di configurazione, errori di applicazioni, malware, rootkit, anomalie di sistema o violazioni delle security policy.

Le regole possono essere aggiornate periodicamente tramite script fornito nell’installazione di default; se ad esempio volessimo aggiornare le regole settimanalmente, possiamo aggiungere al nostro crontab la seguente riga:

0 3 * * * /var/ossec/bin/update_ruleset -r
5 3 * * * systemctl restart wazuh-manager

Ricordarsi che il comando precedente sovrascrive le regole fornite, per cui qualunque modifica effettuata direttamente su tali regole verrà persa.

Esistono due path in cui possiamo trovare le regole:

  • /var/ossec/ruleset/rules: qui troviamo le regole fornite da Wazuh; come ricordato precedentemente, queste verranno sovrascritte nel momento in cui effettuiamo l’aggiornamento;
  • /var/ossec/etc/rules: qui troviamo le “custom rules”, ossia le regole che possiamo costruirci (anche modificando eventualmente le originali). Se volessimo modificare una regola di default, possiamo copiarla dentro il file /var/ossec/etc/rules/local_rules.xml inserendo la direttiva “overwrite=yes”.

Per familiarizzare con le regole, vogliamo creare una nuova regola che ci avvisi se un utente cerca di aprire una sessione SSH verso una nostra macchina utilizzando l’account di root.

SCONSIGLIO vivamente di lasciare abilitato l’accesso con utente root tramite SSH nelle macchine *nix; nel vostro file di configurazione ( /etc/ssh/sshd_config ) disabilitate tale accesso modificando la seguente riga:

PermitRootLogin no

Se fosse necessario avere accesso come utente root, l’utente generico può utilizzare il comando “su”; in questo modo ho due vantaggi:

  1. viene loggato l’accesso dell’utente generico nella mia macchina
  2. viene loggata l’apertura di una sessione con credenziali amministrative nel file di log:
    • Jul 12 12:36:30 machine su[33598]: pam_unix(su-l:session): session opened for user root by mioutente (uid=1000)

Quando l’utente root cerca di effettuare un accesso (non autorizzato) alla nostra macchina, nel file di log di SSH ( /var/log/secure ) troveremo la seguente riga:

Jul 12 12:21:03 machine sshd[33426]: User root from xxx.xxx.xxx.xxx not allowed because not listed in AllowUsers

Per creare la regola che intercetti questo evento, prendo spunto dalle regole relative all’SSH (il file è /var/ossec/ruleset/rules/0095-sshd_rules.xml ).

La regola che voglio creare:

  • avrà ID=5780 e un alert level=10 (un tentativo di accesso tramite root user non potrebbe essere altrimenti);
  • dovrà essere attivata se il decoder SSH è stato richiamato (e quindi la regola con ID 5700 è stata attivata); in particolare, voglio che questa regola venga attivata se anche se la regola 5718 è stata attivata ( “Attempt to login using a denied user” );
  • dovrà essere attivata se verrà trovata la stringa “User root from xxx.xxx.xxx.xxx not allowed because not listed in AllowUsers”

Creeremo dunque la seguente regola:

<group name="syslog,sshd,">
  <rule id="5780" level="10">
     <if_sid>5718</if_sid>
     <regex>User root from \d+.\d+.\d+.\d+ not allowed because not listed in AllowUsers</regex>
     <description>!!! Root attempt login !!!</description>
  </rule>
</group>
  • <rule id=”5780″ level=”10″>: alla regola abbiamo assegnato l’ID 5780 e un livello 10;
  • <if_sid>5718</if_sid>: la regola verrà attivata se la regola “padre” 5718 è stata attivata;
  • <regex> … </regex>: cerco la stringa indicata tramite espressione regolare.

La nostra regola dovrà essere inserita all’interno del file:

/var/ossec/etc/rules/local_rules.xml

Facciamo un test per vedere se la nostra regola viene attivata:

# /var/ossec/bin/ossec-logtest
2020/07/12 15:48:37 ossec-testrule: INFO: Started (pid: 33044).
ossec-testrule: Type one log per line.

Jul 12 15:31:19 machine sshd[36459]: User root from xxx.xxx.xxx.xxx not allowed because not listed in AllowUsers <== input

**Phase 1: Completed pre-decoding.
       full event: 'Jul 12 15:31:19 machine sshd[36459]: User root from xxx.xxx.xxx.xxx not allowed because not listed in AllowUsers'
       timestamp: 'Jul 12 15:31:19'
       hostname: 'machine'
       program_name: 'sshd'
       log: 'User root from xxx.xxx.xxx.xxx not allowed because not listed in AllowUsers'

**Phase 2: Completed decoding.
       decoder: 'sshd'
       dstuser: 'root'
       srcip: 'xxx.xxx.xxx.xxx'

**Phase 3: Completed filtering (rules).
       Rule id: '5780'
       Level: '10'
       Description: '!!! Root attempt login !!!'
**Alert to be generated.

Se interroghiamo l’app di Wazuh in Kibana, possiamo vedere come l’evento è stato correttamente intercettato:

Nel prossimo post vedremo come Wazuh possa attivare una serie di comandi al verificarsi di un certo evento (pro-active response); ad esempio, in questo caso, Wazuh potrebbe “ordinare” alla macchina che ha subito il tentativo di intromissione, di bloccare tramite iptables (o altro) l’indirizzo IP da cui l’evento è generato.

 

← Wazuh – FIM (File Alteration Monitor)

Wazuh – Pro-active response →