Vediamo come creare delle liste personalizzate (CDB) utilizzando elenchi OSINT (Open Source Intelligence). L’idea è quella di creare liste che contengano utenti/IP legittimi dai quali non vogliamo avere avvisi (whitelist) o, viceversa, liste che contengano utenti/IP che vogliamo bloccare (blacklist).

Quello che dobbiamo fare è creare regole personalizzate che controllino se l’IP, l’utente o qualsiasi altro campo estratto dai decoders, siano inclusi in liste personalizzate: a seconda del risultato, potremo decidere se generare un avviso o meno, procedendo con il bloccare eventualmente l’IP.

Per creare le nostre blacklist personalizzate utilizzeremo FIREHOLE, un servizio fornito da OSINT.

Vi invito a leggere attentamente il contenuto della home page di FIREHOLE e di analizzare le immagini/report in essa contenute; riescono a presentare in maniera alquanto intuitiva la situazione reale degli indirizzi IP che potrebbero danneggiare in qualche modo i nostri sistemi.

Esiste una lista globale, formata come aggregazione di sottoliste che include (ad oggi) circa 620 milioni di indirizzi IP. E’ possibile utilizzare tale lista, ma per la mole di indirizzi IP in essa contenuti, risulta molto pesante da gestire; per questo motivo vi consiglio di utilizzare solo le sottoliste che servono al vostro scopo, e che sono raggruppate per categoria (abuse, anonymizers, attack, malware, organizations, reputation, spam, unroutable).

Di seguito l’immagine relativa alla georeferenziazione degli indirizzi IP contenuti nella blacklist globale (firehol_level1):

Nel nostro esempio, utilizzeremo solo 2 delle blacklist incluse in FIREHOLE:

• firehol_level3: un ipset composto da blocklist che tengono traccia di attacchi, spyware, virus. Include gli IP che sono stati segnalati o rilevati negli ultimi 30 giorni. Include: bruteforceblocker ciarmy dshield_30d dshield_top_1000 malc0de maxmind_proxy_fraud myip shunlist snort_ipfilter sslbl_aggressive talosintel_ipfilter vxvault
• et_block: include circa 19 milioni di indirizzi ed incorpora IP provenienti da spamhaus DROP, dshield and abuse.ch. Spamhaus DROP (una delle liste più importanti) rappresenta netblock “dirottati” o affittati da operazioni professionali di spam o cyber-crimine, utilizzati cioè per la diffusione di malware, downloader di trojan, controller di botnet. Tale lista rappresenta un sottoinsieme di SBL, progettato per essere utilizzato da firewall e apparecchiature di routing per filtrare il traffico dannoso da questi netblock).

Utilizzeremo anche lo script free-to-use iplist-to-cdblist.py per convertire le liste precedenti in formato “leggibile” da ossec.

# wget https://iplists.firehol.org/files/firehol_level3.netset -O /var/ossec/etc/lists/firehol_level3.netset
# wget https://iplists.firehol.org/files/et_block.netset -O /var/ossec/etc/lists/et_block.netset
# wget https://wazuh.com/resources/iplist-to-cdblist.py -O /var/ossec/etc/lists/iplist-to-cdblist.py

# dnf -y install dos2unix python2
# dos2unix iplist-to-cdblist.py
# chmod +x /var/ossec/etc/lists/iplist-to-cdblist.py

Sostituiamo nello script iplist-to-cdblist.py la prima riga:

#!/usr/bin/env python 
#!/usr/bin/python2

Procediamo con la compilazione delle liste:

# /var/ossec/etc/lists/iplist-to-cdblist.py /var/ossec/etc/lists/firehol_level3.netset /var/ossec/etc/lists/bl_firehol_level3
# /var/ossec/etc/lists/iplist-to-cdblist.py /var/ossec/etc/lists/et_block.netset /var/ossec/etc/lists/bl_et_block
# rm -f /var/ossec/etc/lists/firehol_level3.netset /var/ossec/etc/lists/et_block.netset

Modifichiamo la configurazione di Wazuh (/var/ossec/etc/ossec.conf) per includere le blacklist precedenti:

...
<ruleset>
  <!-- User-defined ruleset -->
  <rule_dir>etc/rules</rule_dir>
  <list>etc/lists/bl_firehol_level3</list>
  <list>etc/lists/bl_et_block</list>

Creiamo il file CDB:

# /var/ossec/bin/ossec-makelists
...
 * CDB list etc/lists/bl_et_block.cdb has been updated successfully
 * CDB list etc/lists/bl_firehol_level3.cdb has been updated successfully

Ora che abbiamo creato le nostre liste, possiamo utilizzarle nelle nostre regole; creeremo due regole personalizzate (ma potrebbe essere anche una sola) che utilizzerà lo script opnsense_ban.sh per bloccare l’IP da cui proviene la richiesta. La regola si attiverà se il “gruppo” è web, attack o attacks e l’IP è nella nostra lista nera.

Modifichiamo il file /var/ossec/etc/rules/local_rules.xml:

....
<group name="attack,">
    <rule id="100601" level="10">
      <if_group>web|attack|attacks</if_group>
      <list field="srcip" lookup="address_match_key">etc/lists/bl_firehol_level3</list>
      <description>IP in FireHol Level 3 - $(srcip) blocked (opnsense-ban).</description>
    </rule>
</group>

<group name="attack,">
    <rule id="100602" level="10">
      <if_group>web|attack|attacks</if_group>
      <list field="srcip" lookup="address_match_key">etc/lists/bl_et_block</list>
      <description>IP in et_block - $(srcip) blocked (opnsense-ban).</description>
    </rule>
</group>

Modifichiamo infine il file di configurazione di Wazuh per eseguire opnsense-ban.sh come active-response quando la regola viene attivata:

...
  <active-response>
    <command>opnsense-ban</command>
    <location>server</location>
    <rules_id>100601,100602</rules_id>
  </active-response>

Riavviamo il servizio:

# systemctl restart wazuh-manager

Con un log fittizio, con IP appartenente ad una delle liste, verifichiamo che le nostre regole vengano attivate;

# /var/ossec/bin/wazuh-logtest

1.15.48.154 – – [09/Jun/2017:11:17:03 +0000] “POST /command.php HTTP/1.0” 404 464 “-” “Wget(linux)”
**Phase 1: Completed pre-decoding.
full event: ‘27.203.77.170 – – [09/Jun/2017:11:17:03 +0000] “POST /command.php HTTP/1.0” 404 464 “-” “Wget(linux)”‘

**Phase 2: Completed decoding.
name: ‘web-accesslog’
id: ‘404’
protocol: ‘POST’
srcip: ‘27.203.77.170’
url: ‘/command.php’

**Phase 3: Completed filtering (rules).
id: ‘100601’
level: ’10’
description: ‘IP in FireHol Level 3- 27.203.77.170 blocked (opnsense-ban).’
groups: ‘[‘attack’]’
firedtimes: ‘1’
mail: ‘False’
**Alert to be generated.

46.209.140.220 – – [09/Jun/2017:11:17:03 +0000] “POST /command.php HTTP/1.0” 404 464 “-” “Wget(linux)”
**Phase 1: Completed pre-decoding.
full event: ‘46.209.140.220 – – [09/Jun/2017:11:17:03 +0000] “POST /command.php HTTP/1.0” 404 464 “-” “Wget(linux)”‘

**Phase 2: Completed decoding.
name: ‘web-accesslog’
id: ‘404’
protocol: ‘POST’
srcip: ‘46.209.140.220’
url: ‘/command.php’

**Phase 3: Completed filtering (rules).
id: ‘100602’
level: ’10’
description: ‘IP in et_block – 46.209.140.220 blocked (opnsense-ban).’
groups: ‘[‘attack’]’
firedtimes: ‘1’
mail: ‘False’
**Alert to be generated.

Quando una delle regole che contiene gli IP delle blacklist viene attivata, nel nostro frontend (Kibana/Elastic) potremo vedere:

Come fatto per le blacklist, è anche possibile creare delle whitelist con utenti, IP, URL o processi (qualunque campo estraibile dai decoders).

Un’ultima cosa: ricordatevi di automatizzare il download delle liste almeno 2/3 volte a settimana (crontab …..)

• <command>firewall-drop</command>
• <command>opnsense-ban</command>

← Wazuh – Scovare e reagire ad un attacco Shellshock