Il firewall non basta più! L’AI può bloccare gli attacchi prima che colpiscano

Le botnet non aspettano più l'uomo. WAF, IDS e Threat Intelligence possono essere potenziati con modelli di Machine Learning capaci di riconoscere anomalie, bloccare ASN malevoli e anticipare gli attacchi. Un approccio pratico che migliora sicurezza, resilienza e conformità NIS2.

La difesa perimetrale contro gli attacchi odierni non può più contare su tempi di reazione umani, per accorgersene basta attivare una VPS qualsiasi, per assistere, nel giro di poche ore, ai primi attacchi automatizzati, e chi lavora con server esposti conosce bene tale fenomeno, e sa che dietro quei tentativi non si trova un soggetto specifico.

Honeypot e sonde sparsi in giro per la rete misurano questo traffico da anni e i risultati sono sconcertanti: servizi di Botnet che setacciano interi blocchi di indirizzi IP cercando una porta aperta, scanner che controllano che versione hai di un certo software per capire se sei patchato, script che riprovano exploit vecchi di mesi contro qualunque cosa risponda.

Per chi attacca il costo di un singolo tentativo è quasi pari allo zero, quindi di attacchi ne partono a valanghe. Chi pubblica servizi in rete capisce presto che qualcosa che filtri il traffico ostile prima di atterrare sulle tue applicazioni è necessario, e si accorge immediatamente che non è più sufficiente un semplice firewall, essendo diventato necessario passare ai Next Generation Firewall, che integrino funzionalità di Intrusion Detection, Intrusion Prevention e verifica delle applicazioni web. Di concerto scoprirà anche che i costi di queste soluzioni spesso superano quelli relativi alle infrastrutture in utilizzo, soprattutto quando si tratta di piccoli progetti esposti.

In questo articolo ho voluto condividere la mia esperienza relativa alla gestione di una difesa perimetrale che integri sistemi WAF e IDS, e ne correla i log, in accordo con Threat Intelligence collaborativa, per poter fornire dati compiuti, di traffico esistente e conosciuto, a modelli di Machine Learning, supervisionati e non, che possano agire in maniera asincrona per permettere di difendere i servizi esposti.
I security team che gestiscono NGFW e sistemi di difesa perimetrale, si scontrano con alcuni problemi, il primo sicuramente è la latenza, tra il momento in cui si segnala un’attività sospetta e l’applicazione di un blocco effettivo; tra le due attività infatti è possibile che passino ore. Il secondo problema può essere la perdita di contesto, poiché con difficoltà si tende a correlare quanto accaduto in precedenza con quanto si attua al momento. Il terzo è il decadimento della protezione, con ban che scadono, e mancanza di tracciamento per eventuali ripristini immediati.

Il sistema di difesa perimetrale che ho studiato ed applicato è organizzato su tre livelli principali: al livello superiore si trova il livello di Threat Intelligence, che raccoglie i dati grezzi dagli applicativi, quali WAF, IDS, software anti brute force in correlazione con gli eventuali servizi esposti, al quale si affianca una prima analisi comportamentale tramite modelli di machine learning. Al centro opera un Decision Hub che funge da collettore, dove vengono registrate tutte le decisioni, gli score assegnati dagli applicativi e le azioni. Sotto, due pipeline distinte si occupano rispettivamente degli IP e degli ASN, prima identificandoli e poi censendoli, configurandone poi i ban verso il firewall, di sistema o NGFW, o di infrastruttura se IAAS. Il sistema utilizza poi un meccanismo di escalation progressiva basato sul numero di volte in cui un ASN è già stato visto e/o bannato in precedenza.

Ho preferito identificare gli Autonomous System Number come vettori di traffico malevolo, in quanto ho potuto appurare come attacchi combinati spalmino il traffico su diversi ASN contemporaneamente; le analisi effettuate sui dati di attacchi conosciuti, possibili solo a posteriori, permettono sostanzialmente di analizzare una grande differenza: un ASN legittimo tenderà a mostrare stabilità, con identificazione geografica circoscritta e quindi pochi IP, orari e comportamenti di navigazione prevedibili, poche categorie di attività. Un ASN compromesso o gestito da botnet mostra invece dispersione più elevata, traffico massivo e riconoscibilità dello stesso, molte volte tale riconoscibilità è riflessa su altri IP, e quindi ulteriori ASN identificati.

La sezione relativa alla machine learning di questa difesa perimetrale, si affida a due modelli distinti, con due approcci complementari, uno unsupervised, Isolation Forest, per individuare comportamenti anomali, e uno supervised per classificare gli attacchi noti, detto Random Forest.
Il modello Isolation Forest lavora su finestre mobili di sette giorni per ogni ASN identificata, con analisi degli IP univoci identificati da software di sicurezza (unique_ips), ne analizza la varietà e la distribuzione delle tecniche d’attacco (attack_variety) da essi provenienti, la varianza oraria (hour_std) e la distribuzione settimanale. L’algoritmo isola i punti che si distinguono, e costruisce centinaia di alberi decisionali casuali. Ogni albero prova a separare i dati in osservazioni anomale, segnalando quelle con un numero minore di split, quindi con occorrenze che per l’algoritmo sono finalizzate a comportamenti automatizzati; una volta addestrato, il modello può valutare nuovi IP e nuovi ASN, restituendo uno score di anomalia in anticipo, considerando il valore basso come indicatore della probabilità che quell’ASN stia mostrando un pattern insolito, lo raffronta al quinto percentile del traffico settimanale, e se necessario ne applica il ban preventivo di 48 ore, passando il dato al secondo modello.

Di seguito un esempio di come vengono estratte le caratteristiche e rilevate le anomalie attraverso il modello preaddestrato:

import sqlite3
import pandas as pd
import joblib
from datetime import datetime

DB_PATH = "/data/decisions.db"
MODEL_PATH = "/data/isolation_forest_model.pkl"

def load_features():
conn = sqlite3.connect(DB_PATH)
df = pd.read_sql_query("""
SELECT ip, asn, country, category, created_at
FROM decisions
WHERE created_at >= datetime('now', '-7 days') AND asn IS NOT NULL
""", conn)
conn.close()
return df

def feature_engineering(df):
df['created_at'] = pd.to_datetime(df['created_at'])
df['hour'] = df['created_at'].dt.hour
df['dayofweek'] = df['created_at'].dt.dayofweek
features = df.groupby('asn').agg({
'ip': 'nunique',
'category': 'nunique',
'hour': 'std',
'dayofweek': 'nunique'
}).rename(columns={
'ip': 'unique_ips',
'category': 'attack_variety',
'hour': 'hour_std'
})
features['total_attacks'] = df.groupby('asn').size()
features = features.fillna(0)
for col in ['unique_ips', 'total_attacks']:
if features[col].max() > 0:
features[f'{col}_norm'] = features[col] / features[col].max()
return features[['unique_ips_norm', 'total_attacks_norm', 'attack_variety', 'hour_std', 'dayofweek']]

Il modello Random Forest viene addestrato sulle etichette generate da un classificatore sul quale convergono i dati dei software di sicurezza (exploit, brute_force, scan, spam, bad_ua), includendo ora del giorno, giorno della settimana, numero totale di attacchi e IP unici, con l’obiettivo di fornire una classificazione più precisa degli eventi ambigui, affiancandola allo scoring del classificatore, e generare informazioni utili per training e tuning di entrambi i modelli.
I due modelli quindi si alimentano a vicenda, facendo convergere nelle tabelle condivise le anomalie scoperte da Isolation Forest, tradotti in dati di training per Random Forest, mentre le categorie apprese da quest’ultimo migliorano la qualità delle feature del modello unsupervised.

Sul piano operativo è utile tenere il tutto in container dedicati, così che modelli, motore di inferenza, e calcoli di priorità abbia il suo ambiente dedicato, pulito e indipendente dagli altri, per non considerare che allenare un modello pretende risorse, e i servizi in produzione ne farebbero le spese. Impostare limiti rigorosi alle risorse permette di dare un limite ai processi di apprendimento in modo che la stabilità dei server non sia mai a rischio.

Associare le liste di Threat Intelligence, i registri degli applicativi di sicurezza e i modelli predittivi che lavorano su un database centralizzato, viene fuori un modo diverso di fare difesa, applicando quindi una strategia che si può misurare, correlando ciò che accade sul tuo server con quello che la rete ha già imparato, e permettere ai modelli di machine learning ad agire prima che il problema arrivi.

Vale la pena, in chiusura, spostare l’attenzione sul piano normativo, perché per molte organizzazioni rimane complesso instillare tali discorsi tecnici in ragioni di funzionamento di un’azienda, in funzione di motivazioni che supportino investimenti. La direttiva NIS2 ha alzato sensibilmente l’asticella degli obblighi in materia di sicurezza delle reti e resilienza operativa, e la ISO 27001, dal canto suo, richiede un sistema di gestione della sicurezza in cui i controlli siano adottati, documentati e verificabili nel tempo. Un’infrastruttura come quella descritta in questo testo può rispondere a entrambe le esigenze per natura del suo funzionamento, attraverso monitoraggio continuo delle anomalie, registrazione di audit trail strutturati, risposta agli incidenti, entro tempi documentabili, producendo evidenze che revisori e autorità si aspettano di trovare.

Chi ha sostenuto almeno una volta un audit conosce la differenza tra rendere un sistema sicuro e riuscire a dimostrarlo nel tempo. Quando la raccolta delle evidenze viene integrata direttamente nei meccanismi di difesa, la conformità ne può diventare un risultato naturale, generata senza interventi aggiuntivi, con l’obiettivo di farla diventare la conseguenza

Emanuele Nigro

Ho maturato la mia esperienza tra sistemi Linux e cybersecurity, occupandomi di hardening, incident response, vulnerability assessment e remediation plan in ambienti IaaS. Mi interesso di attività di analisi e studio, tramite strumenti OSINT, su data breach e DDoS.