(in)sicurezza digitale

2026-07-05 11:24:48

JADEPUFFER: il primo ransomware condotto interamente da un agente AI, dalla violazione al wipe del database

Il ransomware ha sempre avuto un umano dietro la tastiera, o quantomeno dietro lo script. Il Threat Research Team di Sysdig sostiene di aver documentato per la prima volta il contrario: un’estorsione digitale condotta interamente, dalla ricognizione iniziale alla distruzione dei dati, da un modello linguistico di grandi dimensioni senza intervento umano diretto. L’hanno battezzata JADEPUFFER, e i log che ha lasciato dietro di sé si leggono come il diario di bordo — auto-narrato, letteralmente — di un operatore che ragiona, sbaglia, si corregge e ripiega su un piano B in 31 secondi.

Il punto d’ingresso: un server Langflow esposto

JADEPUFFER ha ottenuto l’accesso iniziale sfruttando CVE-2025-3248, una falla di mancata autenticazione nell’endpoint di validazione del codice di Langflow, popolare framework open source per costruire applicazioni e workflow di agenti basati su LLM. Il difetto permette a chiunque raggiunga il servizio di eseguire codice Python arbitrario senza credenziali. Langflow resta un bersaglio ricorrente proprio perché le sue istanze, spesso esposte in fretta e senza controlli di rete, custodiscono tipicamente chiavi API di provider AI e credenziali cloud nell’ambiente circostante — un aperitivo perfetto per chi cerca un punto d’appoggio.

Tutti i payload sono stati consegnati come Python codificato in Base64 attraverso l’endpoint RCE, e da lì l’agente ha iniziato a muoversi da solo.

Fase 1: ricognizione e razzia sull’host compromesso

Subito dopo l’esecuzione, l’LLM ha enumerato l’host (id, uname -a, hostname, interfacce di rete, processi attivi) e ha setacciato in parallelo l’ambiente per categorie di segreti: chiavi API di provider AI (OpenAI, Anthropic, DeepSeek, Gemini e altri), credenziali cloud — con una copertura esplicita dei provider cinesi (Alibaba, Aliyun, Tencent, Huawei) oltre ad AWS, GCP e Azure — wallet di criptovalute e seed phrase, credenziali e file di configurazione di database.

Ha poi scaricato il database Postgres di backend dello stesso Langflow, sondato lo spazio di indirizzi interno alla ricerca di servizi raggiungibili e, trovato un endpoint MinIO (l’archivio oggetti compatibile S3 usato per dati applicativi, backup e modelli ML) protetto solo dalle credenziali di default minioadmin:minioadmin, ha eseguito l’intero playbook di enumerazione: elenco dei bucket — incluso uno dedicato allo stato Terraform — e recupero mirato di file .env e credentials.json. Quando un tentativo iniziale con ?format=json ha restituito XML invece del JSON atteso, l’agente ha adattato all’istante il proprio parser allo schema di risposta S3 e ha rilanciato la richiesta: un dettaglio piccolo ma rivelatore, perché è esattamente il tipo di correzione che un toolkit fisso non farebbe mai da solo.

Prima di spostarsi sul bersaglio vero, ha installato una persistenza banale ma efficace: un cron job che ogni 30 minuti invia un beacon all’infrastruttura d’attacco.

Fase 2: il vero obiettivo — un server Nacos/MySQL di produzione

Gli artefatti catturati mostrano che il bersaglio reale dell’operazione non era Langflow, ma un server di produzione separato che eseguiva MySQL e Alibaba Nacos, la piattaforma di service discovery e configurazione dinamica molto diffusa nelle architetture a microservizi. Nacos porta con sé una storia documentata di bypass di autenticazione (CVE-2021-29441 e varianti correlate) e una chiave di firma JWT di default nota pubblicamente dal 2020, che in molte installazioni non viene mai cambiata, rendendo banale la falsificazione dei token.

Con accesso root al database — le cui credenziali non risultano raccolte nell’ambiente della vittima, e la cui origine resta ignota — l’agente ha inserito direttamente un amministratore backdoor nel database di Nacos. Ed è qui che emerge la sequenza più interessante dell’intera analisi Sysdig: il primo tentativo di login con l’account appena creato fallisce; 12 secondi dopo l’LLM prova contemporaneamente le credenziali di default nacos:nacos e genera un nuovo hash per una password più semplice; 19 secondi più tardi emette un payload correttivo che passa da una chiamata subprocess a un import diretto della libreria bcrypt, cancella la riga corrotta e la ricrea con l’hash generato correttamente. Il login riesce. Dal fallimento alla correzione funzionante: 31 secondi, quindici righe di codice coordinato — cancellare, diagnosticare, ricostruire, reinserire.

Segue una fase di ricognizione per un possibile container escape — scritture di test su file MySQL, tentativi di lettura di docker.sock e /proc/1/cgroup, verifica dei permessi su /proc/1/mountinfo — condotta con precisione chirurgica in circa otto minuti e chiusa da un marcatore di completamento esplicito scritto su disco. Non è il comportamento di uno script fisso: è un agente strutturato che segnala da solo di essere pronto per la fase successiva.

Cifratura, estorsione e distruzione — con un colpo di scena

L’agente ha cifrato 1.342 elementi di configurazione del servizio Nacos usando la funzione AES_ENCRYPT() di MySQL, eliminato le tabelle originali config_info e la relativa cronologia, e creato una tabella di estorsione, README_RANSOM, con la richiesta di riscatto, un indirizzo Bitcoin e un contatto ProtonMail. La nota rivendica AES-256, ma AES_ENCRYPT() di default usa AES-128-ECB salvo riconfigurazione: un dettaglio che forse esagera l’algoritmo ma non cambia l’impatto pratico.

Il colpo di scena è nella chiave: generata come base64(uuid4().bytes + uuid4().bytes), quindi sostanzialmente casuale, stampata una sola volta a schermo e mai salvata né trasmessa altrove. Anche pagando, la vittima non potrebbe recuperare nulla — l’estorsione, in questo caso, è tecnicamente impossibile da onorare. Nella fase finale, l’agente è passato dalla cancellazione di singole righe all’eliminazione di schemi di database interi, commentando nel proprio stesso codice la logica di scelta dei bersagli (“database ad alto ROI da eliminare”) come farebbe un operatore che spiega a sé stesso perché sta agendo così.

Come si fa a dire che è stata davvero un’IA

Sysdig basa la propria valutazione su quattro elementi: codice auto-narrante saturo di commenti in linguaggio naturale che spiegano il “perché” di ogni azione; diagnosi e correzione degli errori a velocità di macchina, con timestamp che mostrano una finestra di 31 secondi tra un fallimento e una correzione multi-step accurata; comprensione dimostrata di testo libero incontrato durante l’operazione, non un semplice pattern-matching; e oltre 600 payload distinti ed efficaci eseguiti in una finestra temporale compressa. Anche l’indirizzo Bitcoin usato nella nota di riscatto è curioso: è l’esempio canonico di formato Pay-to-Script-Hash che compare in tutta la documentazione per sviluppatori Bitcoin — un caso da manuale di possibile “allucinazione” di un modello che ha semplicemente riprodotto un esempio della sua base di addestramento, oppure, alternativamente, un wallet reale scelto deliberatamente dall’operatore. Sysdig non è in grado di distinguere le due ipotesi senza visibilità sul system prompt dell’agente.

Cosa cambia per chi difende

Nessuna delle tecniche usate da JADEPUFFER è nuova: è la loro concatenazione autonoma, end-to-end, contro infrastrutture esposte e trascurate, a segnare un punto di svolta. La soglia di competenza per condurre un’estorsione digitale completa si sta abbassando a quanto costa far girare un agente — e se quell’agente gira su credenziali cloud rubate (LLMjacking), il costo per l’attaccante si avvicina allo zero.

• Applicare la patch per CVE-2025-3248 su ogni istanza Langflow e non esporre mai endpoint di validazione/esecuzione codice a Internet
• Non fare girare server di orchestrazione AI con chiavi API di provider o credenziali cloud nell’ambiente: isolarle in un secret manager lontano da processi raggiungibili dal web
• Cambiare la chiave di firma token di default in Nacos, non esporlo mai a Internet e impedirgli di connettersi al database di backend come root
• Non esporre mai account amministrativi di database su Internet; applicare credenziali forti e restrizioni per IP sorgente sulle porte di gestione
• Applicare controlli di egress così che un host applicativo compromesso non possa contattare liberamente destinazioni esterne o database di staging
• Monitorare cron job che invocano chiamate di rete in uscita e anomalie nello User-Agent, oltre agli IoC indicati sotto

Sysdig prevede che il volume e la varietà di queste campagne aumenteranno man mano che il tooling agentico matura. Il consiglio è trattare server applicativi esposti, config store non irrobustiti e account admin di database raggiungibili da Internet come le prime superfici che verranno colpite — non più da un operatore umano con uno script, ma da un agente che scrive da solo il proprio piano d’attacco, verificandolo passo dopo passo.

Indicatori di compromissione

Nome campagna: JADEPUFFER (agentic threat actor)
Vulnerabilità d'ingresso: CVE-2025-3248 (Langflow, RCE non autenticato)
C2 / accesso iniziale: 45.131.66[.]106
Beacon di persistenza: hxxp://45.131.66[.]106:4444/beacon (cron ogni 30 minuti)
Server di staging/exfil dichiarato: 64.20.53[.]230 (InterServer, AS19318)
Bersaglio secondario: server MySQL + Alibaba Nacos esposto
Vulnerabilità sfruttata sul bersaglio: CVE-2021-29441 (Nacos auth bypass) + chiave JWT di default
Credenziali MinIO sfruttate: minioadmin:minioadmin
Tabella di estorsione: README_RANSOM
Indirizzo Bitcoin: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
Contatto: e78393397[@]proton[.]me
Dati distrutti: 1.342 elementi di configurazione Nacos + tabelle config_info/his_config_info
Chiave di cifratura: generata casualmente, mai salvata né trasmessa (dati non recuperabili)

(in)sicurezza digitale

2026-07-05 11:25:51

Armored Likho: la APT che spia governi ed energia con il Python stealer BusySnake

Un attore APT mai documentato prima, battezzato Armored Likho, sta colpendo agenzie governative e il settore elettrico in Russia, Brasile e Kazakistan con un nuovo infostealer Python chiamato BusySnake. Kaspersky, che ha pubblicato l’analisi tecnica il 3 luglio, descrive un toolkit modulare, offuscato con PyArmor Pro e in parte generato con l’assistenza di strumenti di intelligenza artificiale: un caso di scuola di come lo spionaggio informatico stia adottando l’AI-assisted malware development anche nelle campagne di fascia media.

Chi è Armored Likho

Armored Likho non è un gruppo esordiente: secondo Kaspersky, il suo profilo operativo mescola campagne a sfondo finanziario contro privati con operazioni di cyberspionaggio mirate contro organizzazioni pubbliche e infrastrutture critiche. È proprio questa doppia natura — cybercrime opportunistico e intelligence gathering mirato — a rendere l’attribuzione complessa e la minaccia particolarmente insidiosa: la stessa toolchain può colpire un privato cittadino per rubare credenziali bancarie o un ministero per sottrarre documenti riservati.

I ricercatori segnalano possibili sovrapposizioni con un cluster tracciato da BI.ZONE con il nome Eagle Werewolf, attivo almeno dal maggio 2023 e storicamente focalizzato su enti governativi e della difesa, in particolare organizzazioni coinvolte nello sviluppo e nella produzione di droni (UAV). Nel febbraio 2026 Eagle Werewolf era già stato osservato compromettere un canale Telegram dedicato al mondo dei droni per distribuire il RAT AquilaRAT tramite un dropper Rust travestito da checklist per l’attivazione di dispositivi Starlink. Le sovrapposizioni tecniche tra AquilaRAT e BusySnake — stessi schemi di ricezione dei task dal C2, stessa modalità di persistenza tramite scheduled task, endpoint di comunicazione simili — rafforzano l’ipotesi che si tratti dello stesso ecosistema di sviluppo, se non dello stesso gruppo.

La catena d’attacco

Il vettore d’ingresso resta il più classico: email di spear-phishing con esche legate a comunicazioni governative ufficiali o programmi sociali, che distribuiscono un archivio RAR contenente eseguibili droppati da un repository GitHub. Il dropper crea due file VBScript, uno dei quali cancella le tracce dell’esecuzione iniziale mentre l’altro registra un’attività pianificata (scheduled task) per lanciare lo stealer ogni cinque minuti, mascherata da un innocuo processo di sistema chiamato WindowsHelper — la stessa convenzione di naming usata da AquilaRAT con MicrosoftOfficeUpdate.

Una catena alternativa sfrutta invece file di collegamento Windows (LNK) che abusano di CVE-2025-9491 (nota anche come ZDI-CAN-25373), la vulnerabilità nella gestione degli shortcut corretta da Microsoft nel Patch Tuesday di novembre 2025 ma già sfruttata in passato da una dozzina di gruppi APT dal 2017. In questo scenario, il file LNK innesca un comando PowerShell offuscato che avvia un loader: quest’ultimo mostra un documento esca alla vittima mentre in background prepara l’ambiente per l’esecuzione del vero payload, scaricando un interprete Python 3.12 portatile, lo script get-pip.py per installare le dipendenze e un archivio contenente il payload finale module.pyw.

BusySnake Stealer: un infostealer Python pensato per l’evasione

Il cuore della campagna è BusySnake, un infostealer scritto in Python e mai documentato prima. Il codice è offuscato e cifrato con PyArmor Pro 9.2.0: il malware decripta il proprio bytecode solo nell’istante esatto in cui una funzione viene invocata, per poi ricifrarlo immediatamente dopo l’esecuzione, complicando enormemente l’analisi statica e dinamica. L’estensione .pyw gli permette inoltre di girare in background senza mai aprire una finestra di console visibile.

Dopo l’inizializzazione, che legge da un file di configurazione l’indirizzo del C2, i percorsi delle directory, gli intervalli per gli screenshot e uno user-agent dedicato, BusySnake si mette in ascolto di comandi tramite una funzione poll_task che interroga costantemente il server. Tra le capacità operative documentate da Kaspersky:

• Furto di dati dagli appunti di sistema (clipboard)
• Enumerazione dei file sul disco con logging dei metadati in un database locale
• Ricerca di chiavi esadecimali a 64 caratteri nei file — un pattern tipico dei wallet di criptovalute — e relativa esfiltrazione
• Cattura periodica di screenshot, archiviazione e invio al C2
• Keylogging con invio ed eliminazione periodica del log
• Furto di cookie e password da browser Chromium e Firefox, tramite lettura diretta dei file Cookies/cookies.sqlite e della master key in Login State
• Furto di sessioni e credenziali Telegram dalla cartella tdata, previa terminazione forzata del processo telegram.exe
• Apertura di un tunnel SSH inverso riutilizzando una chiave privata fornita dal C2 (funzionalità ereditata dal tool standalone Go2Tunnel, ora integrata nativamente nello stealer)
• Installazione o riavvio di RustDesk per ottenere il controllo remoto, con cattura dello screenshot delle credenziali inserite dalla vittima al momento del login

Kaspersky ha inoltre individuato una versione più recente dello stealer che introduce un vero e proprio framework di gestione dei task: ogni comando ricevuto dal C2 viene assegnato a un identificativo univoco e transita attraverso quattro stati operativi — SCHEDULED, IN_PROGRESS, SUCCEEDED, FAILED — per un reporting più granulare verso l’infrastruttura d’attacco. Un dettaglio che segnala una maturazione ingegneristica non banale per un tool di questa fascia.

L’ombra dell’AI nel malware development

Un elemento che merita attenzione da parte degli analisti: secondo Kaspersky, i payload di primo stadio (loader e stager) mostrano segni di essere stati generati, almeno in parte, con l’assistenza di strumenti di intelligenza artificiale, a giudicare dalla presenza di commenti ridondanti e blocchi di codice ripetitivi tipici dell’output di modelli linguistici. Non è un caso isolato nel panorama 2026, ma conferma una tendenza: gruppi di livello medio stanno abbassando i tempi di sviluppo del malware affidandosi a copiloti AI, con tutte le implicazioni che questo comporta in termini di volume e velocità di iterazione delle campagne.

Due righe per i difensori

Per i team di detection, il caso Armored Likho offre alcuni punti di leva concreti. Il monitoraggio di scheduled task con nomi che imitano processi Microsoft legittimi (WindowsHelper, ma anche varianti simili) dovrebbe essere prioritario in ambienti governativi e OT/ICS del settore energetico. Vale la pena bloccare o ispezionare il download di interpreti Python portatili e script get-pip.py da endpoint non di sviluppo, un comportamento anomalo per la maggior parte delle postazioni impiegatizie. È inoltre opportuno verificare che la patch per CVE-2025-9491 sia stata applicata su tutta la flotta Windows, dato che il bug LNK continua a essere riciclato da attori eterogenei quasi un decennio dopo la sua prima comparsa. Infine, il traffico verso servizi di tunneling SSH inverso avviato da processi non amministrativi è un segnale da allarme immediato, così come i tentativi di reinstallazione o riavvio non richiesti di RustDesk.

Kaspersky segnala di continuare a monitorare attivamente l’evoluzione della campagna e dell’infrastruttura di rete associata: è ragionevole aspettarsi nuove varianti di BusySnake nei prossimi mesi, considerato il ritmo di sviluppo osservato finora.

Indicatori di compromissione (IoC)

# Hash MD5 (selezione)
5D5C3E483C5E544260CE98FC29FBF192  - PS1 stager
0041FD1B2358CD08DBCBC28EA8FC3D20  - EXE dropper
894332174F536C2E1EFEDA05CBA79F8B  - DLL loader
CF74AC018D158EA2C2CFA1B1D71D95BC  - LNK malevolo
C7622A1EFFA27BBFEE6D6E03D6474343  - BusySnake Stealer (PYW)
80B7700053E115D65365CE7330383320  - BusySnake Stealer (nuova versione, PYW)
6B45DDB39A6E86229348DCBBA3857E7C  - Archivio RAR con BusySnake
006887732CA4A4A46A97989CF4DEEEF6  - Archivio RAR con BusySnake
732C31ACF971A81C7E51B2A3DAE82020  - Archivio RAR con BusySnake
# Domini C2
winupdate[.]live
arvax[.]xyz
varenie[.]live
lvl99[.]store
onetoken[.]ink
winupdate[.]ink
# CVE sfruttata
CVE-2025-9491 (ZDI-CAN-25373) - Windows LNK RCE, patchata Nov 2025
# Scheduled task sospetto
WindowsHelper (persistenza BusySnake)
MicrosoftOfficeUpdate (persistenza AquilaRAT)

Fonti: Kaspersky/Securelist, The Hacker News, BI.ZONE Threat Intelligence.

Dyne.org foundation

2026-06-26 10:41:32

🚨 They are bringing back #ChatControl 🚨

Discussion is scheduled for Monday, so act now: fightchatcontrol.eu/

#No2Surveillance #Privacy #Security

Fight Chat Control - Protect Digital Privacy in the EU

Learn about the EU Chat Control proposal and contact your representatives to protect digital privacy and encryption.

^{fightchatcontrol.eu}

Spcnet.it

2026-07-04 08:02:15

Fail2ban su Linux: la configurazione giusta per proteggere davvero il server dal brute-force

Il rumore di fondo di internet

Basta esporre un server Linux con SSH o un pannello di login web e, nel giro di poche ore, i log di autenticazione iniziano a riempirsi di tentativi falliti: scanner automatici che provano credenziali comuni su SSH, bot che martellano i form di login di WordPress, richieste che cercano endpoint vulnerabili. Non è un attacco mirato: è rumore costante e automatizzato a cui ogni IP pubblico è esposto, ventiquattr’ore su ventiquattro.

Fail2ban resta la risposta più pragmatica a questo problema da oltre quindici anni. Osserva i file di log (o il journal di systemd), riconosce pattern di autenticazione fallita e, superata una soglia configurabile, banna l’IP a livello di firewall. È leggero, flessibile e presente nei repository di ogni distribuzione. In questo articolo vediamo come installarlo, configurarlo correttamente — evitando l’errore più comune, cioè modificare il file sbagliato — e alcune tecniche di tuning che fanno la differenza tra una protezione reale e un servizio che gira senza incidere davvero.

Come funziona, in tre concetti

Fail2ban si basa su tre elementi che vale la pena avere chiari prima di toccare la configurazione:

• Filter: un insieme di pattern regex che riconoscono le righe di log corrispondenti a un fallimento di autenticazione.
• Jail: combina un filtro con un percorso di log, le soglie di attivazione e l’azione da eseguire.
• Action: cosa succede al superamento della soglia — tipicamente un ban a livello di firewall, ma può includere anche una notifica email.

Fail2ban include già filtri e jail pronti per decine di servizi: SSH, Apache, Nginx, Postfix, Dovecot e altri. Nella maggior parte dei casi basta abilitare le jail che servono e regolare pochi parametri numerici.

Installazione

# Debian / Ubuntu
sudo apt update
sudo apt install fail2ban

# Fedora / RHEL 9+ / Rocky / AlmaLinux
sudo dnf install fail2ban

# Arch Linux
sudo pacman -S fail2ban

Abilitazione e avvio del servizio:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Se lo stato non riporta active (running), i log spiegano quasi sempre il motivo:

sudo journalctl -u fail2ban -n 50

Il modo corretto di configurare Fail2ban

Il primo errore, molto comune tra chi lo usa per la prima volta, è modificare direttamente /etc/fail2ban/jail.conf. Quel file viene sovrascritto ad ogni aggiornamento del pacchetto, e tutte le modifiche vanno perse silenziosamente al primo upgrade.

L’approccio corretto è creare un file separato nella directory jail.d:

sudo nano /etc/fail2ban/jail.d/custom.conf

In alternativa, si può copiare il file di default e modificare la copia:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Le impostazioni nei file sotto jail.d/ e in jail.local sovrascrivono quelle di default in jail.conf. Usate sempre uno di questi due metodi, mai il file originale.

La sezione [DEFAULT]: i parametri che contano

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

Vale la pena capire bene ciascun valore:

• bantime: durata del ban. Il default di molte distribuzioni è 10 minuti, decisamente troppo poco. Un’ora è un minimo ragionevole; per attaccanti persistenti si può salire a 24 ore o anche una settimana.
• findtime: la finestra temporale in cui vengono contati i fallimenti. Con i valori di esempio, 5 fallimenti in 10 minuti fanno scattare il ban.
• maxretry: numero di fallimenti prima del ban. 5 è ragionevole per SSH; si può scendere a 3 per una protezione più aggressiva.
• ignoreip: IP che non verranno mai bannati. Aggiungete sempre il vostro IP qui prima di abilitare qualsiasi jail — restare bloccati fuori dal proprio server è un problema fastidioso da risolvere da remoto.

Se il server ha anche un indirizzo IPv6 pubblico, includetelo in ignoreip: Fail2ban supporta IPv6, ma alcuni filtri più datati riconoscono solo pattern IPv4, quindi vale la pena verificare che le jail intercettino entrambi i protocolli.

ignoreip = 127.0.0.1/8 ::1 VOSTRO.IP.PUBBLICO

Nota: bantime accetta anche il valore -1 per un ban permanente. Da usare con cautela, perché un errore di configurazione può bloccare IP legittimi in modo definitivo.

Jail SSH, Apache e Nginx

La jail SSH è quella più importante per la maggior parte dei server, anche se in alcune distribuzioni va abilitata esplicitamente:

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 1h

Se SSH è stato spostato su una porta non standard (buona pratica), aggiornate la riga port:

port = 2222

Sui sistemi basati su systemd, la variabile %(sshd_log)s punta automaticamente al journal. Sui sistemi più datati che scrivono su /var/log/auth.log o /var/log/secure, Fail2ban gestisce la differenza tramite il parametro backend.

Per i server web, Apache e Nginx attirano un tipo di abuso diverso: scanner di endpoint 404, bruteforcer di login, bot che generano richieste inutili.

# Apache
[apache-auth]
enabled  = true
logpath  = %(apache_error_log)s
maxretry = 5

[apache-badbots]
enabled  = true
logpath  = %(apache_access_log)s
maxretry = 2

# Nginx
[nginx-http-auth]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 3

[nginx-limit-req]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 10

La jail nginx-limit-req intercetta i client che superano i limiti impostati con limit_req nella configurazione Nginx: una combinazione utile se avete già lavorato sul tuning delle performance del web server. Se Fail2ban segnala che un percorso di log non esiste, impostatelo esplicitamente, ad esempio logpath = /var/log/nginx/error.log.

Dopo ogni modifica, ricaricate la configurazione:

sudo fail2ban-client reload

Verificare lo stato delle jail e i ban attivi

sudo fail2ban-client status

Status
|- Number of jail:      3
`- Jail list:   nginx-http-auth, sshd, apache-badbots

Per il dettaglio di una singola jail:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     143
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 5
   |- Total banned:     38
   `- Banned IP list:   203.0.113.7 198.51.100.22 ...

Centoquaranta tentativi falliti in pochi giorni non sono un’anomalia: su un server esposto a internet è la norma, ed è proprio per questo che Fail2ban è utile.

Ban e unban manuali sono comandi da tenere a portata di mano:

sudo fail2ban-client set sshd banip 203.0.113.99
sudo fail2ban-client set sshd unbanip 203.0.113.99

La jail recidive: bloccare chi torna

Una delle funzionalità meno usate ma più efficaci è la jail recidive, che osserva il log di Fail2ban stesso e banna in modo più severo gli IP che, dopo un ban scaduto, ricominciano subito.

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
action   = %(action_mwl)s
bantime  = 1w
findtime = 1d
maxretry = 5

Con questa configurazione, un IP bannato 5 volte in un giorno riceve un ban di una settimana. È quanto di più vicino a una blocklist persistente di attaccanti si possa ottenere senza ricorrere a feed di threat intelligence esterni. Se il sistema non scrive su /var/log/fail2ban.log (setup solo journal), impostate backend = systemd nella jail recidive.

Testare i filtri prima di fidarsi

Prima di abilitare una jail, conviene verificare che il filtro corrisponda davvero alle righe di log presenti sul sistema:

sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

L’output mostra quante righe sono state riconosciute e quali IP sono stati estratti. Un filtro che non intercetta nulla non protegge nulla — vale soprattutto quando si scrivono filtri personalizzati per applicazioni custom, che vivono in /etc/fail2ban/filter.d/:

# /etc/fail2ban/filter.d/miaapp-auth.conf
[Definition]
failregex = ^ .* "POST /login" 401
ignoreregex =

Il tag <HOST> è obbligatorio in un filtro reale: Fail2ban lo sostituisce con una regex che cattura l’indirizzo IP da bannare. Senza, il filtro non estrae nulla di utile. Tenete la regex il più specifica possibile: un pattern troppo largo rischia di bannare traffico legittimo.

nftables e firewalld: adattare il backend

Su Debian 12+ e Ubuntu 22.04+, nftables è il backend firewall predefinito. L’azione di default di Fail2ban usa ancora iptables, che sui sistemi moderni funziona tramite il layer di compatibilità iptables-nft. Su installazioni nftables “pure”, senza quel layer, va impostata esplicitamente l’azione corretta:

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

Su RHEL, Fedora e Rocky, dove il firewall è gestito da firewalld, serve analogamente:

[DEFAULT]
banaction = firewallcmd-rich-rules
banaction_allports = firewallcmd-allports

Verificare quale sia effettivamente attivo evita ban silenziosamente inefficaci: sudo nft list ruleset per nftables, sudo systemctl status firewalld per firewalld.

Ban persistenti e notifiche email

Per default i ban vivono in memoria e un riavvio del server li cancella tutti. Per renderli persistenti:

[DEFAULT]
dbfile     = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d

Su Debian 12+, Ubuntu 22.04+ e Fedora 38+ il database SQLite è già abilitato per default. Questo stesso database alimenta anche la jail recidive, quindi il parametro conta doppio se la usate.

Per ricevere una notifica email ad ogni ban (richiede un setup di invio funzionante, ad esempio postfix o msmtp):

# Solo ban:
action = %(action_)s
# Ban + notifica email:
action = %(action_mw)s
# Ban + email con le righe di log rilevanti:
action = %(action_mwl)s

[DEFAULT]
destemail = voi@vostrodominio.it
sender    = fail2ban@vostroserver.it

Una configurazione di partenza completa

[DEFAULT]
bantime    = 2h
findtime   = 10m
maxretry   = 5
ignoreip   = 127.0.0.1/8 ::1
dbfile     = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 6h

[nginx-http-auth]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 4

[nginx-limit-req]
enabled  = true
logpath  = %(nginx_error_log)s
maxretry = 10

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

sudo fail2ban-client reload
sudo fail2ban-client status

Cosa Fail2ban non risolve

Fail2ban è reattivo, non preventivo: banna dopo che l’attacco è già in corso. Non copre attacchi brute-force distribuiti su migliaia di IP diversi (con uno o due tentativi ciascuno), exploit zero-day che non generano righe di log, o attacchi a livello applicativo che non falliscono l’autenticazione in modo riconoscibile.

Per una protezione a più livelli, Fail2ban va affiancato ad autenticazione SSH tramite chiave (disabilitando del tutto l’autenticazione a password), un firewall configurato correttamente e revisioni periodiche dei log. Vale anche la pena controllare i limiti di sistema (file descriptor) se il volume di ban è elevato, per evitare che sia Fail2ban stesso a saturare le risorse.

Riferimento rapido

sudo fail2ban-client status                          # elenco jail
sudo fail2ban-client status sshd                      # stato di una jail
sudo fail2ban-client set sshd banip 1.2.3.4           # ban manuale
sudo fail2ban-client set sshd unbanip 1.2.3.4         # unban
sudo fail2ban-client reload                           # ricarica config
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf  # test filtro
sudo tail -f /var/log/fail2ban.log                    # ban in tempo reale

Conclusione

Fail2ban è uno di quegli strumenti che si guadagnano un posto fisso su ogni server Linux esposto a internet: l’installazione richiede pochi minuti e, anche con un tuning minimo, elimina una quantità enorme di rumore da scanner SSH e probe web. La differenza pratica maggiore la fanno tre accorgimenti: impostare un bantime sensato (i 10 minuti di default sono quasi inutili), aggiungere sempre il proprio IP a ignoreip prima di abilitare le jail, e attivare la jail recidive. Da soli, questi tre passaggi migliorano drasticamente l’efficacia di Fail2ban rispetto a un’installazione lasciata ai valori di default.

Fonte originale: LinuxBlog.io – Fail2ban on Linux: Protect Your Server from Brute-Force Attacks

Fail2ban on Linux: Protect Your Server from Brute-Force Attacks | LinuxBlog.io

Fail2ban watches your log files and automatically bans IPs that repeatedly fail authentication, protecting your Linux server from brute-force attacks on SSH, web servers, and more.

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-04 08:02:02

Agenti AI invisibili in Microsoft Entra: come rilevarli e prevenirli prima che diventino un rischio

Il punto cieco della governance AI: gli agenti che Entra non vede

Negli ultimi mesi ogni organizzazione con un tenant Microsoft 365 è passata da “come possiamo sfruttare l’AI” a “come possiamo controllarla”. Microsoft ha risposto irrobustendo l’integrazione degli agenti con Entra Agent ID e Copilot Studio, e anche fornitori terzi come Anthropic si stanno muovendo nella stessa direzione con connettori applicativi per M365. Il problema è che molti agenti AI sono già entrati nel tenant prima che questi meccanismi esistessero, e alcuni percorsi permettono tuttora a un’AI “non autorizzata” di operare senza lasciare traccia evidente.

Il rischio più concreto non sono gli agenti registrati e visibili in Entra, ma quelli che operano nascosti dietro identità utente legittime e dispositivi considerati attendibili. Prima di investire in controlli specifici per l’AI, vale la pena sistemare l’igiene dell’identità e la visibilità sugli endpoint. Vediamo tre scenari concreti in cui un agente AI può sfuggire al controllo, come rilevarli e come prevenirli.

Scenario 1 — Il consenso utente come porta d’accesso più semplice

Microsoft ha investito molto nell’irrobustire il flusso di consenso, imponendo il consenso amministrativo per i permessi più pericolosi. Di default esiste una deny list che copre principalmente gli scope di lettura-scrittura più sensibili, ma gli utenti possono ancora acconsentire autonomamente a scope in sola lettura come User.Read, openid, profile ed email.

Lo scope consentibile dall’utente più pericoloso per un agente AI è offline_access: consegna all’agente un refresh token, ovvero accesso persistente in background, anche quando l’utente non è più connesso.

Il punto a favore dei difensori è che questo percorso registra comunque un service principal individuabile e un record di consenso: c’è quindi una traccia da controllare.

Come rilevarlo

• Rivedi periodicamente l’application consent history del tenant
• Analizza gli end-user consent log per individuare consensi anomali o non richiesti dall’IT

Come prevenirlo

La mitigazione è semplice quanto efficace: disabilita completamente il consenso utente e instrada ogni richiesta di permesso attraverso l’admin consent workflow. In Entra questo si configura da Enterprise Applications > Consent and permissions > User consent settings, impostando “Do not allow user consent”.

Scenario 2 — Token senza alcuna impronta in Entra

Il secondo percorso è ancora più insidioso: un flusso guidato dall’utente che produce direttamente un token, senza passare da un vero consenso applicativo. In pratica, l’utente fornisce all’agente username e password (o un flusso equivalente), e l’agente si maschera dietro un’applicazione Microsoft first-party già fidata. In questo caso non viene creato alcun service principal né alcun record di consenso: Entra registra semplicemente un normale login utente.

Esistono diverse varianti di questo pattern, ognuna con la propria contromisura:

• OAuth 2.0 Resource Owner Password Credentials (ROPC): un flusso legacy a singolo fattore. La difesa è imporre MFA sempre, su tutto, senza eccezioni.
• Device Code Flow: si blocca con una semplice policy di Conditional Access dedicata.
• Family of Client IDs (FOCI): un token emesso per un’applicazione della “famiglia” è riutilizzabile su tutte le altre applicazioni della stessa famiglia, e non esiste un interruttore per disabilitare questo comportamento. Il Conditional Access per singola app viene quindi aggirato banalmente: la mitigazione si sposta sul rilevamento, revocando i token in caso di sospetto abuso e affidandosi alla Continuous Access Evaluation, pur sapendo che la sua copertura non è universale.

Scenario 3 — Dispositivi attendibili: dove i controlli identity smettono di aiutare

Lo scenario più complesso è quello di una postazione dedicata all’AI: il classico Mac Mini nuovo di zecca comparso in una nota spese. Il dipendente lo unisce al tenant tramite hybrid join o come dispositivo conforme, e una volta effettuato il join ottiene un Primary Refresh Token (PRT) legato al TPM. L’agente gira come quell’utente e richiede silenziosamente token al Web Account Manager (WAM) broker, ottenendo una connessione persistente e sempre attiva.

Questo è il caso più difficile da chiudere: l’agente supera ogni verifica di Conditional Access perché, di fatto, è l’utente, su un dispositivo fidato. Il Token Protection lega i token al dispositivo, ma non riesce a distinguere “l’utente” da “un processo agente che gira come l’utente” sulla stessa macchina.

Prevenzione e rilevamento

La prevenzione parte dal non permettere agli utenti di unire autonomamente i propri dispositivi al tenant, supportata da policy di Conditional Access rigorose sulla compliance. Il rilevamento deve invece spostarsi sull’endpoint:

• Advanced hunting in Microsoft Defender for Endpoint su DeviceProcessEvents (flag per browser headless, processi figli inattesi)
• Analisi di DeviceNetworkEvents (un processo locale che contatta una API AI esterna)
• Blocco delle app non autorizzate tramite Defender for Cloud Apps

Le fondamenta contano più dei controlli AI-specifici

Il messaggio centrale è che l’igiene dell’identità, per quanto “vecchia” come disciplina, chiude già la maggior parte di questi scenari:

• Impostare il consenso utente su Do not allow user consent
• Abilitare l’admin consent workflow
• Imporre MFA ovunque, sempre, tramite Conditional Access
• Bloccare il device-code flow con una policy dedicata
• Limitare la possibilità per gli utenti di unire dispositivi a Entra
• Imporre la compliance dei dispositivi via Conditional Access

La configurazione di base, però, non copre tutto: ciò che non può essere mitigato deve essere rilevato, il che significa spostare parte dell’attenzione dal piano identità a quello del dispositivo. E il Purview Data Security Posture Management (DSPM) for AI? È uno strumento genuinamente utile, ma va inquadrato correttamente: offre visibilità, non enforcement. DLP e Insider Risk vanno comunque configurati manualmente, il monitoraggio delle AI di terze parti si appoggia agli stessi endpoint ed estensioni browser già citati, le funzionalità più ricche richiedono licenze premium, e la protezione basata su etichette è cieca sui dati non etichettati. Va trattato come una rete di sicurezza aggiuntiva, non come la prima linea di difesa.

Conclusione

Se la strategia di sicurezza di un’organizzazione si basa sull’identificare gli agenti registrati in Entra, ha già perso di vista la categoria di rischio più insidiosa: quella degli agenti che operano mascherati da utenti normali. La lezione pratica per chi amministra un tenant Microsoft 365 è partire dalle basi già note — consenso, MFA, Conditional Access, compliance dei dispositivi — prima di rincorrere soluzioni AI-specifiche, e progettare i controlli assumendo che alcuni agenti stiano già operando sotto mentite spoglie di un utente reale.

Fonte: Petri IT Knowledgebase – The Agents Entra Can’t See: Detecting and Preventing Rogue AI

The Agents Entra Can’t See: Detecting and Preventing Rogue AI - Petri IT Knowledgebase

Talk about AI and agents has swept the tech industry for the better part of a year, and organizations have shifted from "how can we leverage AI" to "how can

^{Brandon Colley (Petri IT Knowledgebase)}