Bloccare il traffico delle botnet prima che arrivi al database

La maggior parte degli stack applicativi nasce per essere “gentile”. Arriva una richiesta, il router la passa a un controller, il controller apre una connessione al database, esegue una query e restituisce una risposta. È un percorso sensato per gli esseri umani. Per una botnet, è un regalo.

Una botnet distribuita non ha bisogno di sfruttare una vulnerabilità per creare danni. Le basta che l’applicazione continui a dire sì: sì al form di login, sì all’endpoint di ricerca, sì all’email di reset password, sì a un’altra connessione presa dal pool. Quando il traffico arriva all’ORM, avete già pagato il costo di TLS, lookup di sessione e round trip verso il database — moltiplicato per migliaia di nodi al minuto.

La richiesta meno costosa è quella che non elaborate mai. È questo il principio del filtro IP applicato all’edge.

Che aspetto ha davvero una botnet a livello IP

Il traffico di una botnet raramente arriva da un solo indirizzo. Arriva da molti indirizzi, e di solito rientra in alcune categorie abbastanza riconoscibili:

• Host residenziali compromessi. Router domestici, dispositivi IoT e desktop infetti. Poco volume presi singolarmente, enormi nel loro insieme.
• Capacità datacenter affittata. Istanze VPS economiche create in massa. Un cliente umano quasi mai naviga il vostro checkout da un range AWS, OVH o Hetzner.
• Reti proxy commerciali. Pool di proxy residenziali e mobile rivenduti a gigabyte, spesso pubblicizzati proprio come strumenti per aggirare i blocchi basati su IP.
• VPN pubbliche e nodi di uscita TOR. Legittimi per chi tiene alla privacy, ma sovrarappresentati negli abusi.

Nessuna di queste categorie è automaticamente malevola. Un IP datacenter potrebbe essere un sistema di monitoraggio che avete configurato voi. Un’uscita VPN potrebbe essere un cliente collegato dal Wi-Fi di un hotel. Proprio per questo la decisione deve restare nelle vostre mani, non in una blocklist indiscriminata: vi serve la classificazione, poi applicate la vostra policy.

Bloccare prima del database, non dopo

L’ordine delle operazioni conta più dell’accuratezza di un singolo segnale. Prendiamo due versioni dello stesso endpoint di login.

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

L’hashing delle password è volutamente lento: è il suo mestiere. Ma un attacco di credential stuffing contro un login non protetto trasforma un controllo di sicurezza in un vettore di denial-of-service. Spostare la decisione sull’IP prima di quel passaggio significa che un nodo d’attacco riceve un 403 al costo di un accesso a una hash map, mentre il pool di connessioni al database resta disponibile per i clienti reali.

Lo stesso ragionamento vale per gli endpoint di ricerca che interrogano indici full-text, per i form di registrazione che attivano email transazionali e per qualsiasi endpoint che scriva una riga di audit a ogni tentativo.

Una policy pratica, non un muro

Bloccare in modo rigido tutto ciò che sembra sospetto è il modo più rapido per riempire il supporto di ticket arrabbiati. Funziona meglio una risposta a livelli, facile da esprimere quando per ogni indirizzo avete un punteggio di rischio e una tipologia:

• Consentire senza attrito. Indirizzi residenziali e business ISP con un risk score basso. Sono la stragrande maggioranza del traffico reale.
• Aggiungere frizione. VPN o uscite TOR solo sulle azioni sensibili: signup, reset password, modifiche ai payout. Mostrate una challenge, richiedete conferma via email, non concedete automaticamente il free trial.
• Limitare in modo deciso. Range datacenter e hosting che colpiscono endpoint pensati per utenti umani. Le integrazioni legittime devono stare sulla vostra API con una chiave, non sul form di login.
• Rifiutare all’edge. Infrastrutture proxy note per abuso che martellano l’autenticazione, o qualsiasi sorgente che abbia già superato il budget per IP.

Il punto 4 dovrebbe essere il contenitore più piccolo, non l’impostazione predefinita. L’obiettivo è rendere costoso l’abuso, non rendere irraggiungibile il prodotto.

Dove inserire il controllo nello stack

Ci sono tre punti possibili, in ordine indicativo di efficacia:

• CDN o reverse proxy. Il punto più anticipato. La richiesta non tocca nemmeno un application server. Ideale per regole generali su range evidentemente ostili.
• Middleware nell’applicazione. Esegue il controllo prima del routing e prima di qualsiasi chiamata al database. È qui che vivono le policy più sfumate e per endpoint: severe su /login, più permissive su /pricing.
• Dentro la business logic. Per decisioni che richiedono il contesto dell’account, per esempio segnalare un login da IP datacenter su un account che ha sempre usato un solo operatore mobile.

Per la maggior parte dei team, il punto da cui partire è il secondo. Sono poche righe prima del router e proteggono tutto ciò che sta dietro.

Cache aggressiva, fail open

Due regole operative evitano che un controllo di reputazione IP diventi a sua volta un punto di failure:

Cache per indirizzo. Le botnet riutilizzano i nodi. Un TTL breve in memoria — minuti, non giorni — comprime migliaia di richieste in un singolo lookup e mantiene la latenza aggiunta nell’ordine dei microsecondi per chi insiste. Guarda mette in cache le lookup lato server proprio per questo motivo, e la finestra di cache è configurabile.

Fail open, log rumoroso. Se il servizio di reputazione non è raggiungibile, lasciate passare la richiesta e registrate l’evento. Un controllo anti-abuso che butta giù il checkout perché un fornitore terzo ha una giornata storta costa più dell’abuso che dovrebbe contenere. Riservate il fail-closed solo alle azioni davvero ad alto rischio, come i prelievi.

Cosa misurare dopo

Attivate prima il filtro in modalità solo log e confrontate una settimana di traffico con una settimana di blocco:

• Richieste respinte prima di raggiungere il database, come quota del totale.
• Saturazione del pool di connessioni al database durante i picchi di abuso.
• Tentativi di login falliti per ora.
• Ticket di supporto che citano "non riesco ad accedere" — il canarino dei falsi positivi.
• Rapporto tra signup e account verificati, che di solito migliora nettamente quando si fermano le registrazioni usa e getta da datacenter.

Se gli ultimi due indicatori si muovono nella direzione sbagliata, alleggerite il livello di risposta invece di spegnere tutto.

Limiti, senza illusioni

La reputazione IP è uno strato, non un firewall. I pool di proxy residenziali ruotano su indirizzi consumer reali, indistinguibili da quelli dei vostri clienti. Il carrier-grade NAT fa sì che un singolo IP mobile possa rappresentare migliaia di persone. E chi attacca con budget troverà sempre infrastrutture più pulite rispetto a chi attacca senza budget.

Ciò che il filtro IP fa in modo affidabile è rimuovere la maggioranza economica e ad alto volume: flood automatizzati su server affittati e liste proxy ormai bruciate. In questo modo le difese più lente e intelligenti — device fingerprinting, analisi comportamentale, MFA, rate limit legati agli account — devono ragionare su una popolazione molto più piccola e molto più interessante.

Il risultato realistico è questo: non un perimetro impenetrabile, ma un database che continua a rispondere alle query anche mentre siete sotto attacco.

Potete classificare qualsiasi indirizzo usando i segnali di Guarda su proxy, VPN, TOR, hosting e risk score con il controllo gratuito in homepage, e poi integrare la stessa chiamata nel middleware davanti alle vostre route.