DB-IP Lite, RIR o MaxMind GeoLite 2? Differenze ed affidabilità di tre sistemi apparentemente simili

Come un indirizzo IP tedesco è finito bloccato come «brasiliano», e cosa ci ha insegnato sulle basi dati di geolocalizzazione.

Qualche giorno fa ci è arrivata una segnalazione che, a prima vista, sembrava un banale problema di rete. Un cliente ci scriveva che il suo server non riusciva più a comunicare con uno dei siti che gestiamo: le chiamate partivano, ma dall’altra parte non arrivava nulla. Nessun errore applicativo, nessun certificato scaduto, nessuna modifica recente al DNS.

Il server del cliente era ospitato su Hostinger. Il sito che non riusciva a raggiungere era protetto da CFM 4 Linux, la nostra soluzione per l’amministrazione centralizzata dei firewall dei server Linux, sul quale era attiva una regola di Geo Blocking piuttosto comune: bloccare il traffico in arrivo dal Sud America, Brasile compreso, lasciando passare il resto del mondo e in particolare l’Europa.

Il problema è che il server del cliente non era in Sud America. Era a Düsseldorf, in Germania.

Questo articolo racconta come ci siamo arrivati, perché è successo e, soprattutto, perché tre fonti che sembrano rispondere alla stessa domanda – «di che paese è questo IP?» – in realtà rispondono a tre domande diverse. Se gestite un firewall, un CDN, un sistema antifrode o anche solo un plugin di sicurezza che blocca per nazione, è una distinzione che vale la pena conoscere prima di trovarsi un cliente bloccato senza motivo.

Il contesto: CFM 4 Linux e il suo Geo Blocking

CFM 4 Linux (Centralized Firewall Manager) è lo strumento che abbiamo sviluppato internamente per gestire da un’unica console le regole firewall di tutti i server Linux che amministriamo. È nato quando la gestione manuale, server per server, ha smesso di reggere: bot aggressivi, crawler di intelligenza artificiale, attacchi distribuiti che richiedono di applicare la stessa regola su decine o centinaia di macchine in pochi secondi.

L’architettura è semplice:

• un server centrale con la console web, dove si definiscono le politiche: regole di blocco, whitelist globale con precedenza sui blocchi, gruppi di server, eccezioni per singolo nodo;
• un agente leggero su ogni server, che chiede periodicamente al centro la politica aggiornata (modello pull su HTTPS, senza porte aperte in ingresso) e la applica al firewall locale: iptables, nftables o firewalld, sempre in catene dedicate, senza toccare le regole di sistema;
• politiche versionate, con differenze tra versioni e ritorno alla versione precedente in caso di errore.

Tra le funzioni, il Geo Blocking è una di quelle che usiamo di più. Permette di bloccare intere nazioni o interi continenti con un click, e per ogni server di scegliere come comportarsi:

• Inherit: segue la politica geografica globale;
• Allow-Only: il server risponde solo alle nazioni esplicitamente consentite;
• Deny-Only: blocca solo le nazioni indicate, la scelta più comune.

Sotto il cofano, la regola non è una lista di IP scritta a mano. È una lista di paesi, che CFM 4 Linux traduce in prefissi di rete usando una base dati GeoIP: bloccare un paese grande significa caricare decine di migliaia di prefissi (per la Cina sono circa 80.000 prefissi IPv4). Sui server con nftables i prefissi finiscono in set dedicati, con ricerca in tempo costante. Fino a oggi le basi dati usate erano due: DB-IP Lite e le deleghe dei registri regionali (RIR: RIPE, ARIN, APNIC, LACNIC, AFRINIC).

Ed è proprio lì, nel passaggio da «paese» a «prefissi», che è nato il problema di questo articolo.

L’indagine: un IP, quattro risposte uguali e una diversa

L’indirizzo del server del cliente apparteneva al blocco 187.126.0.0/19: 8.192 indirizzi, che per comodità chiameremo con uno di essi, 187.126.16.144.

La prima cosa che abbiamo fatto è stata chiedere a fonti indipendenti dove si trovasse. Ecco cosa abbiamo ottenuto, il 27 ottobre 2026:

Quattro fonti su sei dicono Germania. Una dice Lituania. Una dice Brasile, ed è proprio quella su cui si basava la regola geografica.

Per capire come sia possibile bisogna fare un passo indietro e raccontare la storia di questo blocco di indirizzi.

Breve storia di un blocco IPv4

Gli indirizzi IP non sono distribuiti a caso. L’autorità centrale (IANA) assegna grandi blocchi a cinque registri regionali (RIR):

• AFRINIC per l’Africa;
• APNIC per l’Asia e il Pacifico;
• ARIN per il Nord America;
• LACNIC per l’America Latina e i Caraibi;
• RIPE NCC per l’Europa, il Medio Oriente e parte dell’Asia centrale.

Il blocco 187.0.0.0/8 nasce in America Latina, sotto LACNIC. Per anni gli indirizzi 187.126.x.x sono stati, in modo del tutto legittimo, indirizzi brasiliani, assegnati a operatori del Brasile.

Poi è successa una cosa che negli ultimi anni è diventata frequentissima: gli indirizzi IPv4 sono finiti. Non se ne creano di nuovi, e chi ne ha bisogno li compra da chi ne ha in eccesso. Esiste un vero mercato dei trasferimenti, regolato dai registri, che permette di spostare un blocco da un titolare a un altro e, in certi casi, da un registro all’altro.

Il nostro 187.126.0.0/19 è uno di questi casi. Secondo i dati del registro europeo, il blocco è oggi registrato presso il RIPE NCC a nome di Hostinger, con una registrazione datata 13 marzo 2025. Hostinger lo usa nei suoi datacenter in Germania, ed è lì che si trovava il server del nostro cliente.

Quindi un indirizzo che per tutta la sua storia precedente era stato brasiliano, da marzo 2025 è a tutti gli effetti un indirizzo europeo, usato in Germania. Il mondo reale è cambiato. La domanda è: le basi dati di geolocalizzazione se ne sono accorte?

Come abbiamo visto, non tutte.

Tre fonti, tre domande diverse

Il cuore del problema è che tendiamo a mettere sullo stesso piano tre tipi di dati molto diversi. Vediamoli uno alla volta.

1. I file di delega dei RIR: «a chi è stato assegnato questo blocco?»

Ogni registro regionale pubblica ogni giorno dei file di statistiche, i cosiddetti file delegated, che elencano tutti i blocchi di indirizzi che ha assegnato. Ogni riga dice: quale registro, quale paese, che tipo di risorsa, l’indirizzo di inizio, quanti indirizzi, una data e lo stato. È esattamente la riga che abbiamo visto sopra:

ripencc|LT|ipv4|187.126.0.0|8192|20250313|allocated

È un dato ufficiale, gratuito e aggiornatissimo: per costruzione, i registri sanno sempre a chi appartiene cosa. Ed è il primo a recepire i trasferimenti: nel file del RIPE NCC il blocco compare già come europeo.

Ma attenzione al significato di quel LT. La specifica ufficiale del formato è molto chiara:

«The cc value identifies the country in which the resource holder is legally based.» («Il valore cc identifica il paese in cui il titolare della risorsa ha la propria sede legale.»)

E aggiunge, senza giri di parole:

«This value can therefore not be reliably used to map IP addresses to countries.» («Questo valore non può quindi essere usato in modo affidabile per associare gli indirizzi IP ai paesi.»)

Il LT non significa che il server sia in Lituania. Significa che il titolare del blocco, in questo caso la società di Hostinger che fa da Local Internet Registry, ha sede legale in Lituania. I server, invece, sono in Germania.

È lo stesso motivo per cui gli indirizzi dei grandi provider cloud e delle CDN, che sono assegnati a società con sede in un paese ma usati in datacenter sparsi per il mondo, risultano spesso «americani» o «irlandesi» anche quando rispondono da Milano o da Francoforte.

In sintesi:

• Pregi: ufficiali, gratuiti, aggiornati ogni giorno, seguono subito i trasferimenti.
• Difetti: non sono geolocalizzazione. Dicono chi possiede il blocco e dove ha sede, non dove vengono usati gli indirizzi. La granularità è grossolana: blocchi interi, non le singole reti.
• Quando usarli: per regole di natura amministrativa («non voglio indirizzi intestati a organizzazioni del paese X»), come controprova di coerenza e per accorgersi di un trasferimento.

2. DB-IP Lite: «dove si trova, probabilmente, chi usa questo IP?»

DB-IP è un fornitore di dati di geolocalizzazione che offre, accanto ai prodotti commerciali, una serie di database gratuiti chiamati Lite: IP to Country Lite, IP to City Lite e IP to ASN Lite, scaricabili in CSV o MMDB.

Il grande vantaggio di DB-IP Lite è la semplicità:

• nessuna registrazione;
• download diretto;
• licenza Creative Commons Attribution 4.0, che consente l’uso a patto di citare DB-IP come fonte (per le applicazioni web è richiesto un link a db-ip.com).

È per questo che lo si trova in moltissimi strumenti open source e in tanti pannelli di sicurezza.

Proprio per questo è importante leggere bene ciò che DB-IP stesso dichiara sui suoi database gratuiti. Le versioni Lite:

• sono aggiornate una volta al mese;
• sono, testualmente, «subsets of the commercial databases with reduced coverage and accuracy»: sottoinsiemi dei database commerciali, con copertura e precisione ridotte.

Le versioni a pagamento offrono, sempre secondo DB-IP, maggiore precisione, più record e aggiornamenti giornalieri.

Nel nostro caso, la versione Lite di ottobre 2026 classificava ancora 187.126.0.0/19 come Brasile, a più di diciannove mesi da quando quel blocco era passato a un registro europeo e a un datacenter tedesco. Non sappiamo se la versione commerciale avesse già il dato corretto: possiamo solo constatare che la versione gratuita no.

In sintesi:

• Pregi: libero, senza account, licenza permissiva, copertura completa IPv4 e IPv6.
• Difetti: aggiornamento mensile, precisione ridotta rispetto al commerciale e, come mostra il nostro caso, una certa inerzia sui blocchi trasferiti.

3. MaxMind GeoLite2: la stessa domanda, con un’altra base dati e un altro ritmo

MaxMind è probabilmente il nome più noto della geolocalizzazione IP. Anche MaxMind affianca ai suoi prodotti commerciali (GeoIP2) una famiglia di database gratuiti chiamati GeoLite: Country, City e ASN, in formato MMDB o CSV.

Rispetto a DB-IP Lite, le differenze pratiche sono tre.

L’accesso. Dal 2019 GeoLite non è più un download anonimo. Serve un account gratuito, si genera una license key e si accetta un contratto di licenza (la GeoLite End User License Agreement, aggiornata l’ultima volta il 12 febbraio 2026). I download dei database sono limitati a 30 al giorno, ampiamente sufficienti per chi aggiorna un server centrale.

Il ritmo. Secondo la documentazione MaxMind:

• i database Country e City vengono aggiornati ogni martedì e venerdì;
• il database ASN tutti i giorni feriali.

Due volte a settimana contro una volta al mese.

La licenza, che va letta con attenzione, soprattutto da chi fornisce servizi ad altri. La versione gratuita:

• richiede l’attribuzione, con un testo del tipo «This product includes GeoLite Data created by MaxMind»;
• impone di usare la versione più recente e di distruggere le copie vecchie entro 30 giorni dall’uscita di una nuova release;
• concede l’uso «for your own internal business purposes», cioè per i propri scopi interni.

Chi integra questi dati in un prodotto o in un servizio per clienti farebbe bene a chiedersi, ed eventualmente a chiedere a MaxMind, se il proprio caso rientra in questa formula o se serve una delle licenze commerciali (MaxMind ne prevede una specifica per la redistribuzione dei dati GeoLite).

Nel nostro caso, GeoLite rispondeva correttamente: Germania, Düsseldorf.

È giusto dire anche che la stessa MaxMind è onesta sui limiti della geolocalizzazione: la definisce «inherently imprecise» e avverte che la versione gratuita City è «considerably less accurate» di quella a pagamento. Per il livello di paese, che è quello che serve a un firewall, l’affidabilità è molto maggiore che per la città. Ma resta sempre una stima, non un fatto anagrafico.

In sintesi:

• Pregi: aggiornamento due volte a settimana, ottima tenuta sui trasferimenti nel caso che abbiamo analizzato, formato diffusissimo.
• Difetti: account obbligatorio, licenza gratuita più restrittiva da valutare caso per caso, obbligo di aggiornare entro 30 giorni (che va automatizzato) e attribuzione richiesta.

Il confronto in una tabella

Gli errori che rendono il problema peggiore

Fin qui potrebbe sembrare la storia di una base dati che sbaglia un indirizzo. In realtà, analizzando il caso, abbiamo trovato tre errori di progettazione nel Geo Blocking di CFM 4 Linux. Sono errori comuni, e li raccontiamo apertamente perché crediamo siano utili a chiunque costruisca un sistema di blocco geografico.

Errore n. 1: sommare le fonti

Per «andare sul sicuro», CFM 4 Linux usava due fonti insieme, DB-IP Lite e i dati RIR, e considerava un indirizzo appartenente a un paese se almeno una delle due lo diceva.

Sembra prudente. È l’opposto. Se blocchi il Brasile e anche solo una fonte su due dice «Brasile», l’indirizzo viene bloccato. Nel nostro caso:

• DB-IP diceva BR, e questo da solo bastava a bloccarlo;
• i dati RIR dicevano LT, un paese europeo che la regola avrebbe lasciato passare, ma non contava;
• la realtà era DE.

Sommando due fonti imperfette non si somma la loro affidabilità, si sommano i loro errori. Basta che una sola sia indietro per produrre un falso positivo. E con una regola ampia come «tutto il Sud America», di falsi positivi ce ne possono essere molti.

Errore n. 2: risposte diverse per lo stesso IP

C’è un effetto collaterale più sottile. Quando due fonti assegnano lo stesso identico prefisso (/19 in entrambi i casi) a due paesi diversi, uno strumento che cerca «il prefisso più specifico che contiene l’IP» si trova con un pareggio. A seconda di come il database ordina internamente i risultati, la risposta può essere ora BR, ora LT.

Per chi indaga è disorientante: lo stesso indirizzo cambia nazionalità da una ricerca all’altra, e nessuna delle due risposte è quella giusta.

Errore n. 3: aggiornare la base dati non vuol dire aggiornare i firewall

Il terzo errore è il più insidioso, e riguarda qualunque architettura in cui i dati vengono preparati in un punto centrale e usati su tanti server.

In CFM 4 Linux, gli agenti sui singoli server ricevono dal server centrale l’elenco dei prefissi da bloccare e lo tengono in una cache locale, per non scaricare ogni volta centinaia di migliaia di righe. Il server centrale avvisa gli agenti quando la politica cambia, per esempio quando si aggiunge o si toglie un paese. Ma un aggiornamento della base dati GeoIP, a parità di paesi bloccati, non era considerato un cambiamento della politica. Così i server continuavano a usare tranquillamente l’elenco di prefissi della versione precedente, anche settimane dopo l’aggiornamento centrale.

In questo caso specifico non avrebbe cambiato nulla, perché anche il nuovo database DB-IP diceva ancora Brasile. Ma è la ragione per cui «abbiamo aggiornato il database GeoIP» non basta come risposta a un cliente bloccato: bisogna verificare che l’aggiornamento sia arrivato davvero fino al firewall che ha preso la decisione.

C’è anche un rovescio della medaglia, che vale la pena citare: quando si forza un aggiornamento su tutta la flotta, centinaia di server chiedono gli stessi dati nello stesso momento. Se il sistema centrale rallenta e un server resta senza la sua copia dei prefissi, la scelta di progetto diventa critica: è meglio mantenere le regole che si avevano piuttosto che applicare la nuova politica senza la parte geografica e restare, di fatto, senza protezione.

Cosa abbiamo fatto, e cosa consigliamo

Nell’immediato

La soluzione per il cliente è stata semplice e mirata: un’eccezione per la rete del suo provider, che ha sbloccato subito il traffico senza indebolire la regola per tutti gli altri. È una buona regola generale: quando un partner noto viene bloccato per un errore di geolocalizzazione, la correzione più rapida e sicura è un’eccezione puntuale (sull’IP, sul blocco o sull’ASN), non l’allentamento della regola geografica.

A regime

Il caso ci ha convinto a rivedere l’intera gestione della geolocalizzazione. Le scelte che abbiamo fatto, e che consigliamo, sono queste.

1. Una sola fonte primaria per decidere i blocchi. Abbiamo pianificato il passaggio del Geo Blocking di CFM 4 Linux a MaxMind come unica fonte, al posto dell’unione di DB-IP Lite e RIR (l’integrazione di MaxMind era già nella roadmap del progetto). Il motivo è il ritmo di aggiornamento e il comportamento sui blocchi trasferiti, che nel nostro caso è stato quello corretto. Prima del passaggio ci siamo posti, e posto a MaxMind, la domanda sulla licenza: per chi fornisce un servizio gestito non è un dettaglio.

2. Le altre fonti come controprova, non come voto aggiuntivo. Il dato del registro resta prezioso per un motivo preciso: quando la geolocalizzazione e il registro non sono d’accordo, quasi sempre c’è una storia dietro, che sia un trasferimento, un datacenter o un provider globale. Il disaccordo va mostrato all’operatore, non risolto in silenzio con una somma. Indicazioni come «localizzato in Germania, registrato in Lituania» aiutano a capire al volo un caso come il nostro.

3. Aggiornamenti automatici e verificabili. Il database si aggiorna da solo due volte a settimana. Prima che il nuovo dato entri in vigore, un’anteprima mostra per ogni server quanti prefissi verrebbero sbloccati e quanti bloccati per la prima volta. Se le differenze superano una soglia ragionevole, l’aggiornamento si ferma e chiede conferma a una persona.

4. Propagazione garantita, a ondate. Ogni aggiornamento della base dati viene trattato come un cambiamento reale della politica e raggiunge tutti i server, a gruppi, per non sovraccaricare il sistema centrale. In caso di problemi, i firewall conservano le regole correnti invece di restare senza protezione geografica.

5. Una verifica con casi noti. A ogni aggiornamento controlliamo che una manciata di indirizzi dalla posizione certa risultino nel paese giusto. Il nostro 187.126.16.144 è entrato in questa lista: da oggi deve risultare sempre tedesco.

Qualche consiglio generale per chi fa geo-blocking

• Decidete quale domanda state facendo. Se vi interessa da dove arriva il traffico, vi serve la geolocalizzazione. Se vi interessa a chi appartengono gli indirizzi, vi serve il registro. Usare l’una al posto dell’altra produce errori.
• Ricordate che la geolocalizzazione è una stima. Anche la migliore base dati sbaglia, soprattutto su blocchi trasferiti di recente, reti mobili, VPN, CDN e provider cloud. Una regola che blocca un intero continente accetta per definizione una quota di falsi positivi.
• Preferite le eccezioni mirate alle regole larghe. Bloccare «tutto il Sud America» è comodo, ma colpisce anche clienti, fornitori e servizi legittimi. Dove possibile, è meglio combinare la geolocalizzazione con altri segnali: reputazione degli IP, limiti di frequenza, autenticazione.
• Tenete d’occhio il calendario. Un database gratuito aggiornato una volta al mese può essere indietro di settimane, e su certi blocchi, come abbiamo visto, molto di più.
• Leggete le licenze. «Gratuito» non vuol dire «senza condizioni»: attribuzione, uso interno, obbligo di aggiornamento sono vincoli reali, soprattutto per chi offre servizi a terzi.

Conclusione

Tre sistemi che sembrano dare la stessa risposta, in realtà rispondono a tre domande diverse:

• i file dei RIR dicono dove ha sede chi possiede un blocco di indirizzi, e lo dicono in modo ufficiale e tempestivo;
• DB-IP Lite stima dove si trova chi usa un indirizzo, con un database gratuito, comodo e aggiornato una volta al mese;
• MaxMind GeoLite2 fa la stessa stima con un’altra base dati e un ritmo bisettimanale, a fronte di una licenza più impegnativa.

Nessuno dei tre è «sbagliato» in assoluto. Diventano sbagliati quando li si usa per la domanda sbagliata, quando li si somma alla cieca, o quando si dà per scontato che un dato aggiornato sul server centrale sia automaticamente quello che decide sul firewall.

Il nostro indirizzo tedesco con un passato brasiliano ce lo ha ricordato nel modo più concreto possibile: con un cliente che non riusciva a lavorare. Abbiamo risolto il suo caso in pochi minuti. Rivedere il sistema perché non si ripeta ci ha richiesto un po’ più di lavoro, ed è il motivo per cui abbiamo deciso di raccontarlo.

Fonti

• RDAP del registro: https://rdap.org/ip/187.126.16.144 (consultato il 27/10/2026)
• File di delega del RIPE NCC: https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest
• Specifica del formato statistico dei RIR: https://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt
• RIPEstat, geolocalizzazione MaxMind e panoramica del prefisso: https://stat.ripe.net/
• DB-IP Lite: https://db-ip.com/db/lite.php
• MaxMind GeoLite: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
• MaxMind GeoLite EULA: https://www.maxmind.com/en/geolite/eula
• MaxMind, frequenze di aggiornamento: https://support.maxmind.com/knowledge-base/articles/download-and-update-maxmind-databases

Questo prodotto include dati GeoLite creati da MaxMind, disponibili presso https://www.maxmind.com.