{"id":36775,"date":"2026-10-21T15:47:13","date_gmt":"2026-10-21T13:47:13","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36775"},"modified":"2026-10-21T15:49:43","modified_gmt":"2026-10-21T13:49:43","slug":"archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/","title":{"rendered":"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995"},"content":{"rendered":"\n

Stratigrafia di un’infrastruttura: ricostruire un ISP del 1995 grazie alla digital forensics<\/strong><\/p>\n\n\n\n

Qualche tempo fa stavo cercando del vecchio materiale per rispondere a una domanda di un amico quando mi sono imbattuto in alcune directory su un NAS che non aprivo da quasi trent\u2019anni. Erano i backup e la documentazione che avevo creato per Internet Force, l\u2019Internet Service Provider di cui ero system e network administrator nel 1995.<\/p>\n\n\n\n

Dentro c\u2019erano configurazioni dei router Cisco, zone BIND, file di Sendmail, configurazioni XTACACS, script, mappe SNMP create con tkined, file \/etc\/hosts e \/etc\/networks, configurazioni di routing, documentazione operativa e perfino gli inventari di hardware, dischi e filesystem delle macchine Sun. Alcuni backup erano corrotti ed altri file erano mancanti, probabilmente si erano persi nelle numerose migrazioni di computer che li hanno visti coinvolti. Ricordavano un po\u2019 le vestigia di una gloriosa civilt\u00e0 del passato e come per i templi, guardando anche solo le colonne si capiva cosa dovevano essere stati.<\/p>\n\n\n\n

Nel rispondere alle domande del mio amico mi sono accorto di due cose. La prima \u00e8 che quel materiale suscita ancora una curiosit\u00e0 quasi irrazionale in una certa categoria di persone che, per semplicit\u00e0, chiameremo geek. La seconda \u00e8 che oggi \u00e8 sorprendentemente difficile trovare una descrizione completa di come fosse costruito e funzionasse realmente un piccolo Internet Service Provider commerciale della met\u00e0 degli anni Novanta<\/strong>.<\/p>\n\n\n\n

Ho cominciato a seguire le tracce dei dati ritrovati. Un indirizzo IP in un file rimandava a un host in un altro; una route spiegava il percorso verso un POP; una regola di FireWall-1 chiariva perch\u00e9 un servizio fosse raggiungibile da una rete ma non da un\u2019altra. Alcuni documenti fotografavano momenti diversi e apparentemente si contraddicevano. A quel punto la somiglianza con un lavoro archeologico ha smesso di essere soltanto una metafora simpatica: dagli artefatti si poteva ricostruire non solo quali macchine esistessero, ma come funzionasse davvero l\u2019organismo nel suo insieme.<\/p>\n\n\n\n

Ho quindi deciso di ricostruire quella storia confrontando i materiali originali, la mia memoria e, dove serviva, una assistenza mirata della IA per ricostruire parti mancanti o file corrotti. <\/p>\n\n\n\n

Il problema era che non avevo un unico backup coerente, congelato in un preciso giorno del 1995 (o del 96). I backup regolari di un tempo non li avevo conservati. C\u2019erano invece strati diversi: copie sopravvissute a numerose migrazioni di computer, configurazioni aggiornate in momenti successivi (e che mi erano servite negli anni come base per attivit\u00e0 varie di consulenza), file incompleti e documenti che fotografavano fasi differenti dell\u2019infrastruttura. A volte due reperti sembravano contraddirsi semplicemente perch\u00e9 appartenevano a mesi diversi. <\/p>\n\n\n\n

Ad un certo punto mi \u00e8 venuto in mente che mi era \u201crimasta\u201d una copia di un backup su nastro della mia workstation. La cassetta DAT era sopravvissuta per quasi trent\u2019anni in un contenitore in cantina. Il backup originale era stato scritto con un lettore DAT Sun collegato via SCSI a DVLP, una macchina SunOS; per provare a recuperarlo ho invece noleggiato un lettore DAT USB e l\u2019ho collegato a una macchina Linux.<\/p>\n\n\n\n

Da l\u00ec \u00e8 iniziata la parte pi\u00f9 vicina alla digital forensics vera e propria. Ho usato tar per cercare di estrarre il contenuto e, quando sembrava esserci compressione, gzip per capire cosa fosse ancora leggibile. Il risultato non era affatto un archivio ordinato: alcuni file uscivano normalmente, altri avevano dimensione zero, altri ancora sembravano archivi .tar.Z ma non si aprivano pi\u00f9. In diversi casi ottenevo semplicemente blob con nomi illeggibili o contenuti parzialmente corrotti.<\/p>\n\n\n\n

A quel punto il recupero diventava un lavoro per indizi. Guardavo header, stringhe leggibili, dimensioni, nomi vicini nell\u2019archivio e confrontavo ci\u00f2 che emergeva con configurazioni gi\u00e0 recuperate altrove. In alcuni casi ho usato anche DeepSeek tramite OpenCode per provare a interpretare i blob danneggiati e riconoscere strutture plausibili: non per \u201cinventare\u201d il file mancante, ma per capire se dentro quei frammenti fosse ancora riconoscibile una configurazione, uno script o un archivio compresso.<\/p>\n\n\n\n

Anche quando un file si apriva correttamente, per\u00f2, restava da capire quando fotografasse l\u2019infrastruttura. Una configurazione Cisco poteva sembrare quella del lancio e contenere invece rotte verso POP aggiunti soltanto nel 1996. Una mappa tkined poteva rappresentare una fase precedente; un file DNS, una tabella di routing o una policy del firewall permettevano di collocarla meglio nel tempo. La ricostruzione \u00e8 diventata quindi soprattutto un lavoro di stratigrafia: non chiedersi soltanto \u201cquesto file \u00e8 autentico?\u201d, ma \u201ca quale momento della rete appartiene?\u201d.<\/p>\n\n\n\n

Anche la mia memoria faceva parte delle fonti, ma non era il metro con cui costringere i file a confermare quello che ricordavo. Quando memoria e reperti non coincidevano, cercavo un terzo elemento: una configurazione, una mail, una data, una mappa, un documento operativo. In alcuni casi ho dovuto correggere ricordi che dopo trent\u2019anni avevano finito per sovrapporre momenti diversi della storia della rete. In altri erano proprio i file a restituire dettagli che avevo completamente dimenticato.<\/p>\n\n\n\n

Nel repository ho cercato di conservare anche questa distinzione temporale: quando una configurazione appartiene chiaramente alla fase iniziale, quando \u00e8 una revisione successiva e quando invece un passaggio \u00e8 stato ricostruito a posteriori incrociando pi\u00f9 fonti. L\u2019articolo pu\u00f2 quindi seguire la storia; chi vuole verificare come ci sono arrivato pu\u00f2 scendere fino ai singoli reperti.<\/p>\n\n\n\n

Da ci\u00f2 \u00e8 nato questo articolo e un repository GitHub che ne conserva tutti i dettagli tecnici. Qui su Codemotion non voglio fare un catalogo di configurazioni: voglio raccontare i processi. Cosa accadeva quando un cliente di Milano o di un POP remoto componeva il numero del provider? Come veniva autenticato? Come raggiungeva Internet? Dove finiva la sua posta? Come si costruiva e pubblicava un sito Web? E come lavorava, dietro a tutto questo, un piccolo ufficio pieno di Sun, Cisco, Macintosh, un PC Linux e, a un certo punto, perfino Windows NT con Oracle?<\/p>\n\n\n\n

Il repository serve a chi vuole scendere di un livello e vedere i reperti: configurazioni Cisco, file Unix, policy, documentazione e ricostruzioni tecniche. L\u2019articolo prova invece a rimettere quei reperti in movimento.<\/p>\n\n\n\n

Il percorso parte dal recupero di quei reperti e dal contesto tecnico in cui erano nati, entra poi nell\u2019architettura di Internet Force e segue una connessione dial-up dal modem fino a Internet; alla fine torneremo ai materiali meno infrastrutturali riemersi dai backup e a ci\u00f2 che sopravvisse alla societ\u00e0.<\/p>\n\n\n\n

La storia seguir\u00e0 questo percorso:<\/p>\n\n\n\n

Recuperare un ISP trent\u2019anni dopo \u2192 il contesto di Internet nel 1995 \u2192 come nacque l\u2019architettura di Internet Force \u2192 sicurezza e servizi \u2192 seguire una connessione dal modem a Internet \u2192 l\u2019ufficio e il lavoro quotidiano \u2192 il repository e gli altri materiali recuperati \u2192 cosa accadde dopo la chiusura.<\/p>\n\n\n\n

Dal modem alla fibra: cambiano le tecnologie, non le domande<\/strong><\/h1>\n\n\n\n

Prima di entrare nei dettagli di Internet Force vale la pena fermarsi un momento su una differenza fondamentale fra allora e oggi. Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete. Oggi, con una connessione fissa, diamo invece per scontato che Internet sia sempre presente. Sotto questa differenza enorme, per\u00f2, il provider deve ancora risolvere problemi sorprendentemente simili. Di seguito una sintesi delle principali differenze <\/p>\n\n\n\n

TL;DR:<\/strong><\/p>\n\n\n\n

ISP met\u00e0 anni \u201990<\/strong> = accesso punto-punto su doppino telefonico: modem, terminal server\/access server, autenticazione su DB centrale, poi IP.<\/p>\n\n\n\n

ISP FTTH oggi<\/strong> = accesso punto-multipunto su fibra passiva: ONT, PON con splitter passivi, OLT, BNG, AAA\/RADIUS, backbone, peering\/transit.<\/p>\n\n\n\n

Confronto di dettaglio<\/strong><\/p>\n\n\n\n

Aspetto<\/strong><\/td>Dial-up anni \u201990<\/strong><\/td>FTTH oggi<\/strong><\/td><\/tr>
Mezzo fisico<\/td>Linea telefonica, modem 28,8 kbit\/s, chiamata<\/td>Fibra ottica, ONT (Optical Network Terminal, terminale di rete ottica) a casa<\/td><\/tr>
Concentrazione<\/td>Modem pool \u2192 terminal\/access server<\/td>Splitter passivi \u2192 OLT (Optical Line Terminal, terminale di linea ottica)<\/td><\/tr>
Sessione\/autenticazione<\/td>Terminal server interroga DB centrale utenti<\/td>BNG (Broadband Network Gateway, gateway di rete a banda larga) + AAA\/RADIUS: identifica, autorizza, accounting<\/td><\/tr>
IP<\/td>Assegnato dopo riconoscimento abbonato<\/td>BNG gestisce connettivit\u00e0 IP e profili servizio<\/td><\/tr>
Uscita Internet<\/td>Router provider \u2192 Internet<\/td>Backbone \u2192 peering\/IXP o transit<\/td><\/tr>
Filosofia<\/td>Point-to-point, apparati eterogenei<\/td>PON (Passive Optical Network, rete ottica passiva), controllo centralizzato software\/policy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Differenza sostanziale: prima il collo di bottiglia era modem + linea telefonica; oggi la parte ottica \u00e8 passiva e condivisa, mentre intelligenza e controllo stanno in OLT\/BNG\/AAA.<\/p>\n\n\n\n

L\u2019altra differenza evidente \u00e8 che non si \u201cchiama\u201d pi\u00f9 Internet. La connessione \u00e8 permanente, condivisa e a commutazione di pacchetto fin dalla rete di accesso. Ma l’idea generale rimane la stessa: accesso \u2192 identificazione dell’abbonato \u2192 assegnazione della connettivit\u00e0 IP \u2192 aggregazione \u2192 backbone \u2192 Internet.<\/p>\n\n\n\n

\u00c8 proprio questa continuit\u00e0 funzionale, nascosta sotto tecnologie completamente diverse, a rendere interessante questa archeologia di un ISP.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Figura 1 \u2014 Due modi di fornire accesso a Internet: dial-up nel 1995 e una tipica architettura FTTH contemporanea. Gli apparati cambiano, le funzioni fondamentali restano riconoscibili.<\/em><\/p>\n\n\n\n

Un Internet molto pi\u00f9 piccolo<\/strong><\/h1>\n\n\n\n

Per capire davvero, bisogna prima tornare mentalmente al 1995. Nel 1994 l\u2019ITU stimava circa 20 milioni di utenti Internet nel mondo<\/strong>, appena lo 0,3% della popolazione. Amazon avrebbe aperto il proprio bookstore sul Web nel luglio 1995; nell\u2019ottobre dello stesso anno annunciava di ricevere gi\u00e0 ordini da 45 paesi. <\/p>\n\n\n\n

Proprio nell\u2019autunno del 1995 (ho trovato una ricevuta!) anch\u2019io ordinavo da Amazon manuali e testi informatici in inglese, difficili da trovare in Italia, facendomeli spedire in ufficio. La documentazione sul funzionamento dei servizi Internet era cos\u00ec recente ed evolveva cos\u00ec in fretta che la si trovava solo online.<\/p>\n\n\n\n

Internet commerciale esisteva, il Web stava accelerando, ma per la maggior parte delle persone in Italia collegarsi significava ancora trasformare una linea telefonica in una connessione dati per qualche ora sottraendola spesso al resto della famiglia. <\/p>\n\n\n\n

Usenet: imparare e restituire alla rete<\/strong><\/h1>\n\n\n\n

Un\u2019altra grande scuola era Usenet. Nei newsgroup tecnici si potevano incontrare persone estremamente competenti e chiedere aiuto, ma l\u2019etichetta era piuttosto chiara: prima si cercavano le FAQ, si leggeva la documentazione e si provava a capire il problema; poi si faceva una domanda riportando sistema, versione, configurazione, messaggio di errore e tentativi gi\u00e0 effettuati. <\/p>\n\n\n\n

Da quella cultura nasceva anche il celebre RTFM, \u201cRead The Fucking Manual\u201d: una risposta oggi poco diplomatica, ma allora perfettamente comprensibile nel contesto. Non significava semplicemente \u201carrangiati\u201d; implicava che prima di chiedere aiuto ci si aspettasse almeno il tentativo di leggere il manuale, le FAQ e la documentazione disponibile. La comunit\u00e0 condivideva moltissima conoscenza, ma chiedeva in cambio un minimo di lavoro preliminare.<\/p>\n\n\n\n

La presunzione che tutti siano a propria disposizione non rappresentava ancora una conquista dell\u2019umanit\u00e0.<\/p>\n\n\n\n

Usenet non era un sito n\u00e9 apparteneva a una piattaforma. Era un sistema distribuito di gruppi di discussione organizzati per argomento: i messaggi pubblicati in un newsgroup venivano propagati fra i news server che partecipavano alla rete. Per chi lavorava con Unix e Internet era insieme luogo di discussione, supporto tecnico, archivio di esperienza e punto d\u2019incontro con persone che stavano risolvendo gli stessi problemi dall\u2019altra parte del mondo. Usenet esiste ancora tecnicamente, ma quel ruolo centrale nella cultura della rete \u00e8 in gran parte scomparso.<\/p>\n\n\n\n

C\u2019era anche un principio di reciprocit\u00e0 che oggi mi sembra importante ricordare. Per lavoro crescevo continuamente attingendo a documentazione, FAQ, mailing list, sorgenti e discussioni che altri avevano messo a disposizione. Quando potevo, cercavo quindi di restituire alla rete una parte di quella conoscenza. In quegli anni diventai autore della FAQ di it.comp.linux e pubblicai in it.faq documenti sulle emoticon, sul cyberspazio e sul gergo hacker, oltre ad altro materiale tecnico e culturale. Ho ritrovato diversi di quei post originali, completi degli header con cui circolavano su Usenet, e li ho salvati nel repository insieme agli altri reperti.<\/p>\n\n\n\n

Per questo ho deciso di creare nel repository, oltre alle configurazioni delle macchine, una piccola sezione dedicata a Usenet, che raccoglie i documenti che pubblicavo allora mantenendone le date originali; una selezione curata delle mailbox permette invece di conservare qualche frammento della vita quotidiana della rete. Pi\u00f9 avanti torner\u00f2 su questi materiali e su alcune altre cose riemerse dagli stessi backup, perch\u00e9 raccontano aspetti della cultura tecnica dell\u2019epoca che le sole configurazioni non possono mostrare. I messaggi di terzi sono pubblicati solo quando appropriato e, dove necessario, sanitizzati: l\u2019archeologia digitale non vuole risvegliare miei contatti dormienti da pi\u00f9 di trent\u2019anni.<\/p>\n\n\n\n

Come si diventa system administrator senza essere ancora un system administrator<\/strong><\/h1>\n\n\n\n

C\u2019\u00e8 un antefatto che vale la pena raccontare, soprattutto perch\u00e9 evita una possibile interpretazione sbagliata di ci\u00f2 che segue. Quando i soci di Internet Force pubblicarono l\u2019annuncio per cercare il system administrator del provider che stavano costruendo, facevo gi\u00e0 consulenze informatiche da qualche anno, assemblavo PC all\u2019occorrenza, programmavo da autodidatta, avevo inoltre  lavorato in un centro elaborazione dati della Marina in cui avevo potuto imparare parecchio, avevo iniziato a realizzare pagine Web per piccoli provider milanesi (HTML) e collaboravo con alcune riviste di informatica scrivendo articoli tecnici. <\/p>\n\n\n\n

Unix, per\u00f2, lo avevo approcciato solo da utente ai tempi dell\u2019universit\u00e0.<\/p>\n\n\n\n

Mi candidai comunque. Studiai manuali la sera, imparando abbastanza Unix da sostenere il colloquio e riuscii a convincere i soci, che tecnicamente ne sapevano meno di me. In termini meno eleganti: avevo bluffato piuttosto bene.<\/p>\n\n\n\n

Il problema arriv\u00f2 quando entrarono in scena i consulenti israeliani di Xpert UNIX Systems<\/a>, ai quali era stata affidata la progettazione tecnica dell\u2019ISP. A loro bastarono pochi giorni per capire quale fosse realmente il mio livello. Mesi dopo mi dissero che avevano per\u00f2 apprezzato la determinazione e la velocit\u00e0 con cui imparavo e per questo decisero di formarmi.<\/p>\n\n\n\n

In particolare mi affiancarono il mitico Yahel Ben-David, che fecero arrivare appositamente da Israele e che divenne di fatto il mio tutor. Il metodo era molto diverso dal consegnarmi configurazioni gi\u00e0 pronte da copiare: mi coinvolgeva nella progettazione, mi chiedeva quale soluzione avrei adottato e perch\u00e9. Quando sbagliavo, spesso mi lasciava procedere abbastanza da farmi capire dove fosse il problema e poi mi faceva rifare il percorso. Era praticamente un approccio maieutico: trascorrevamo tutto il giorno insieme dalle 8 alle 23 in modo che potessi arrivare alla data del lancio adeguatamente preparato e in grado di gestire il provider. Inutile dire che divenimmo presto amici.  <\/p>\n\n\n\n

Furono sempre loro a farmi conoscere Linux e convinsero i soci a dotarmi di una workstation 486DX piuttosto potente, con 16 MB di RAM con controller (Adaptec AHA2940) e dischi SCSI (cosa rara ai tempi su PC), perch\u00e9 potessi sperimentare autonomamente. Mentre in Italia aspettavamo l\u2019arrivo di una macchina Sun mancante e l\u2019attivazione del collegamento internazionale, trascorsi circa sei mesi a Tel Aviv continuando quella formazione direttamente alla fonte.<\/p>\n\n\n\n

Quando Internet Force inizi\u00f2 a operare nel 1995, quindi, non stavo semplicemente amministrando una rete progettata da altri: avevo partecipato alla sua stessa costruzione imparando a comprenderne le scelte e a ricostruirla da zero in caso di bisogno.<\/p>\n\n\n\n

Un ISP pensato come una rete, non come una BBS evoluta<\/strong><\/h1>\n\n\n\n

Nel 1995 la parola provider poteva indicare realt\u00e0 tecnicamente molto diverse. Molti piccoli operatori italiani provenivano direttamente dal mondo delle BBS e di FidoNet. Li conobbi bene anche negli anni successivi, quando lavorai come consulente alla trasformazione di alcuni ISP milanesi: PC commodity, batterie di modem aggiunte progressivamente, cablaggi e servizi cresciuti intorno ad un paio di PC e, quando andava bene, un collegamento permanente da 64 kbit\/s verso un carrier nazionale.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

ricostruzione di un piccolo provider\/BBS italiano dell\u2019epoca, prima di un mio intervento di refactoring nel \u201897.<\/em><\/p>\n\n\n\n

Internet Force era stato concepito in modo diverso fin dall\u2019inizio. I soci si erano rivolti alla statunitense IDT<\/a>, che li aveva messi in contatto con Xpert UNIX Systems. Il modello era vicino a quello degli ISP statunitensi dell\u2019epoca: sistemi Unix dedicati, router e access server Cisco, POP distribuiti, autenticazione centralizzata, separazione dei ruoli tra le macchine e sicurezza considerata parte dell\u2019architettura.<\/p>\n\n\n\n

Il collegamento internazionale part\u00ec a 128 kbit\/s e, dopo circa sei mesi, venne portato a 2 Mbit\/s verso IDT negli Stati Uniti. <\/p>\n\n\n\n

Anche la scala era ormai significativa. Nella fase di espansione del 1996, considerando i nuovi POP, l\u2019aumento delle linee a Milano e il rapporto fra abbonati e modem utilizzato per dimensionare il servizio, Internet Force aveva raggiunto circa 2.000 abbonati. In un ISP dial-up il numero importante non era soltanto quanti clienti avevi, ma quanti potevano collegarsi contemporaneamente: vendere accesso a migliaia di persone significava dimensionare modem, linee telefoniche e collegamenti geografici sulla probabilit\u00e0 che solo una parte di loro fosse online nello stesso momento.<\/p>\n\n\n\n

Quel numero diventa pi\u00f9 comprensibile guardando il dimensionamento delle linee. Con la regola empirica di 8-16 abbonati per modem, ogni gruppo di sedici modem rappresentava una capacit\u00e0 commerciale nell\u2019ordine di 128-256 clienti. Aggiungendo i nuovi POP del 1996 e l\u2019espansione delle linee su Milano, si arrivava quindi a servire qualche migliaio di abbonati senza dover avere qualche migliaio di modem.<\/p>\n\n\n\n

Per dare un ordine di grandezza, nel 1995 Video On Line, allora il maggiore provider nazionale, contava circa 15.000 abbonati, pari a circa il 30% del mercato italiano. Internet Force rimaneva quindi un operatore molto pi\u00f9 piccolo, ma duemila abbonati erano gi\u00e0 una dimensione tutt\u2019altro che amatoriale.<\/p>\n\n\n\n

Due megabit oggi sono meno della banda che una pagina Web moderna riesce a sprecare prima ancora di mostrare il titolo; per un piccolo ISP italiano del 1995 erano invece una capacit\u00e0 importante.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Internet Force Network Map: vista complessiva dell\u2019infrastruttura, ricostruita a partire dalla mappa tkined originale e dagli artefatti conservati.<\/em><\/p>\n\n\n\n

Internet si assemblava<\/strong><\/h1>\n\n\n\n

C\u2019\u00e8 un aspetto dell\u2019Internet di quegli anni che oggi rischia di essere poco evidente: la rete non era aperta soltanto nei protocolli. Le specifiche erano pubblicate nelle RFC e una parte importante del software necessario a costruire i servizi Internet circolava in sorgente, poteva essere compilata sulle diverse piattaforme Unix e veniva sviluppata da universit\u00e0, gruppi di ricerca e comunit\u00e0 distribuite.<\/p>\n\n\n\n

BIND implementava il DNS; Sendmail gestiva SMTP; daemon distinti offrivano FTP, POP e IMAP; altri software gestivano Usenet, mailing list e IRC. Sul Web, nel 1996, NCSA HTTPd avrebbe ceduto il passo al neonato progetto Apache. Non tutto ci\u00f2 che usavamo corrisponderebbe automaticamente alla definizione moderna di \u201copen source\u201d, termine che sarebbe arrivato solo nel 1998, ma la cultura tecnica era fondata su standard pubblici, interoperabilit\u00e0 e una disponibilit\u00e0 del codice che rendeva possibile capire, adattare e integrare i componenti.<\/p>\n\n\n\n

Per amministrare un ISP non si acquistava quindi necessariamente una suite che fornisse \u201cInternet\u201d. Internet si assemblava. Si prendevano protocolli definiti pubblicamente, implementazioni disponibili in sorgente, daemon differenti, li si compilava sulla propria piattaforma Unix, li si configurava e li si faceva interoperare.<\/p>\n\n\n\n

Era esattamente ci\u00f2 che avevamo fatto in Internet Force. DNS, posta, Web, autenticazione, FTP, News e mailing list erano servizi distinti, costruiti attorno a programmi diversi che il system administrator doveva conoscere abbastanza da poterli integrare. \u00c8 anche il motivo per cui, trent\u2019anni dopo, pubblicare le configurazioni nel repository mi sembra coerente con la cultura da cui quella rete era nata: il modo migliore per capire un sistema \u00e8 poterlo ispezionare.<\/p>\n\n\n\n

Unix al centro<\/strong><\/h1>\n\n\n\n

Il cuore dell\u2019ISP era costituito da sistemi Sun con SunOS. La scelta di SunOS invece del pi\u00f9 recente Solaris rifletteva la valutazione dei consulenti di Xpert: per un\u2019infrastruttura che doveva essere esposta a Internet preferivano in quel momento una piattaforma che consideravano pi\u00f9 matura e conosciuta.<\/p>\n\n\n\n

Le macchine avevano ruoli distinti. DATA ospitava il Web pubblico, il DNS primario, FTP anonimo, mailing list e, in diverse fasi, servizi legati a Usenet. USERS concentrava identit\u00e0 e servizi degli utenti: autenticazione XTACACS, posta, home directory, POP3 e IMAP, oltre al DNS secondario. DVLP era la macchina di sviluppo e build. La mia workstation Linux, \u201cmarco\u201d, era invece il posto da cui amministravo e monitoravo l\u2019infrastruttura.<\/p>\n\n\n\n

Anche i nomi delle macchine raccontavano qualcosa dell\u2019azienda, sebbene in questo caso non esattamente quello che avrei voluto raccontassero. Nel mondo Unix era prassi abbastanza consolidata scegliere per gli host nomi appartenenti a uno stesso universo: personaggi mitologici, astronomia, letteratura o fantascienza. La mia prima proposta fu il Signore degli Anelli; come seconda scelta avevo l\u2019Olimpo greco e, in terza posizione, Star Wars.<\/p>\n\n\n\n

I soci di Internet Force considerarono l\u2019idea troppo giocosa per un\u2019azienda e optarono per una nomenclatura decisamente pi\u00f9 sobria: i server presero il nome della loro funzione, \u201cdata\u201d, \u201cusers\u201d, \u201cdvlp\u201d, mentre alle workstation vennero assegnati nomi legati ai loro utilizzatori. A trent\u2019anni di distanza, da hacker nell\u2019accezione originaria del Tech Model Railroad Club del MIT, tengo a mettere formalmente agli atti il mio dissenso. Avevamo la possibilit\u00e0 di chiamare un server \u201cgandalf\u201d e scegliemmo \u201cusers\u201d.<\/p>\n\n\n\n

Una piccola rivincita arriv\u00f2 l\u2019anno successivo. Quando installai il sistema Windows NT destinato agli esperimenti con Oracle, gli assegnai personalmente l\u2019hostname \u201coracolo\u201d. Questa volta, prudentemente, non convocai alcun comitato per la scelta del nome.<\/p>\n\n\n\n

La filosofia di base per sistemi pubblicamente esposti era ridurre il pi\u00f9 possibile ci\u00f2 che esisteva sui sistemi di produzione. Compilatori, strumenti di sviluppo e software non necessario al ruolo del server stavano solo su DVLP; i server esposti venivano installati e sottoposti a hardening lasciando solo ci\u00f2 che serviva. Si compilava su DVLP e si trasferivano gli eseguibili sulle macchine operative. Nel 1995 usavamo anche FTP interno per questi trasferimenti; non molto dopo il modo di lavorare evolse con l\u2019introduzione di strumenti pi\u00f9 sicuri (ssh e scp).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Systems Overview: DATA, USERS, DVLP, firewall, workstation di amministrazione e Office LAN.<\/em><\/p>\n\n\n\n

La sicurezza come architettura<\/strong><\/h1>\n\n\n\n

Un\u2019altra scelta significativa era Check Point FireWall-1, installato su una Sun SPARCstation 5 con SunOS 4.1.4. <\/p>\n\n\n\n

FireWall-1 era stato commercializzato da pochissimo e portava un\u2019idea allora molto avanzata: la Stateful Inspection, insieme a una GUI X11 (quindi in ambiente grafico) che permetteva di esprimere le policy usando oggetti che rappresentavano host, reti e servizi.<\/p>\n\n\n\n

La cosa interessante non era soltanto avere un firewall, ma il modo in cui era inserito nella rete. DATA e USERS disponevano di collegamenti Ethernet separati verso il firewall; l\u2019Office LAN costituiva un altro segmento. Non era una singola LAN piatta con un filtro davanti. Le policy descrivevano esplicitamente chi potesse raggiungere quale sistema e attraverso quali protocolli.<\/p>\n\n\n\n

Tra i materiali recuperati c\u2019\u00e8 anche un GIF originale della rule base di FireWall-1. \u00c8 uno dei reperti che preferisco perch\u00e9 non mostra soltanto che avevamo un firewall: racconta concretamente come funzionava la rete. La regola 7, ts \u2192 users, tacacs, \u00e8 il ramo laterale dell\u2019autenticazione: i terminal server potevano interrogare USERS senza che il traffico Internet degli abbonati dovesse attraversare il server. La regola 12, news.ios.com \u2192 data, nntp, mostra invece il feed Usenet proveniente dall\u2019esterno. La 13 autorizzava xpert.com verso DVLP e la mia workstation \u201cmarco\u201d per talk e deslogin: accesso remoto del fornitore israeliano, con un meccanismo di login cifrato, prima che SSH diventasse il modo normale di fare la stessa cosa.<\/p>\n\n\n\n

In una sola schermata compaiono quindi autenticazione centralizzata, feed Usenet e accesso remoto di un fornitore esterno: problemi che oggi chiameremmo identity, service exposure e third-party access. E in fondo alla policy c\u2019era la regola che dava senso a tutte le altre: Any \u2192 Any \u2192 Any: STOP. Tutto ci\u00f2 che doveva passare doveva essere autorizzato esplicitamente prima.<\/p>\n\n\n\n

C\u2019\u00e8 per\u00f2 una distinzione importante: i clienti dial-up non erano \u201cdietro\u201d FireWall-1. Il firewall proteggeva i server centrali e l\u2019ufficio. Il traffico ordinario dei clienti verso Internet rimaneva sul lato world della rete; attraversava il firewall solo quando doveva raggiungere un servizio protetto, per esempio l\u2019autenticazione su USERS o i servizi centrali consentiti dalle policy.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Screenshot originale della rule base Check Point FireWall-1 su X11, 1995.<\/em><\/p>\n\n\n\n

Seguire una connessione: da Milano a Internet<\/strong><\/h1>\n\n\n\n

Il modo pi\u00f9 semplice per spiegare il resto dell\u2019architettura \u00e8 seguire un utente. Nel 1995 non si apriva un\u2019app: si faceva una telefonata.<\/p>\n\n\n\n

Prima che potesse fare quella telefonata, per\u00f2, il cliente doveva essere stato attivato. L\u2019area commerciale lasciava in segreteria un modulo cartaceo con i dati del cliente e il contratto firmato; dalla workstation chiamata \u201canna\u201d quei dati venivano inseriti nel gestionale e poi inviati via email a me, perch\u00e9 creassi l\u2019account sui sistemi del provider e ne abilitassi l\u2019accesso. Dalla stessa macchina arrivavano anche le richieste di assistenza via email: i problemi pi\u00f9 comuni venivano gestiti facendo riferimento alle FAQ che avevo preparato, mentre le questioni pi\u00f9 tecniche mi venivano inoltrate. Fra i materiali recuperati sono sopravvissuti anche alcuni di questi scambi, ed \u00e8 attraverso quegli scambi che ho ricostruito il passaggio quotidiano fra commerciale, amministrazione, customer care e infrastruttura tecnica.<\/p>\n\n\n\n

Il cliente di Milano componeva il numero di accesso. La rete telefonica usava un gruppo di ricerca per inoltrare la chiamata su una linea libera, collegata a uno dei modem. All\u2019inizio il POP disponeva di sedici modem: sedici linee significavano sedici utenti contemporanei, perch\u00e9 ogni sessione occupava fisicamente un modem e una linea telefonica per tutta la durata del collegamento.<\/p>\n\n\n\n

Il modem negoziava la connessione con quello del cliente e consegnava la linea seriale a un Cisco 2511. Sul 2511 le interfacce asincrone erano configurate per PPP. Era l\u2019access server a ricevere username e password, ma non era lui a possedere il database degli utenti.<\/p>\n\n\n\n

L\u2019autenticazione era il primo passaggio<\/strong><\/h2>\n\n\n\n

Il Cisco 2511 interrogava via XTACACS il server USERS. Questo passaggio \u00e8 importante da visualizzare correttamente: USERS non era \u201cin mezzo\u201d al traffico Internet del cliente. Il 2511 chiedeva a USERS se quelle credenziali fossero valide; ottenuta la risposta, la sessione PPP poteva proseguire sulla rete. Un unico sistema di autenticazione serviva quindi tutti i POP.<\/p>\n\n\n\n

Su molti PC Windows l\u2019accesso TCP\/IP richiedeva ancora software dedicato. Tra i materiali conservati c\u2019\u00e8, per esempio, la distribuzione di Trumpet Winsock 3.0 insieme alla documentazione di configurazione fornita agli utenti. <\/p>\n\n\n\n

Il Welcome Kit di Internet Force, che ho recuperato integralmente (e di cui ho deciso di pubblicare anche i sorgenti), lo avevo realizzato per i clienti del provider: forniva software (tra cui le versioni di Netscape ed Eudora di allora) e istruzioni per configurare il collegamento e iniziare a navigare. \u00c8 un reperto interessante perch\u00e9 mostra l\u2019altra estremit\u00e0 dell\u2019infrastruttura: da una parte Cisco, Sun, DNS e autenticazione; dall\u2019altra un utente con Windows, un modem e nessuna ragione per sapere cosa fosse PPP.<\/p>\n\n\n\n

Poi arrivavano DNS e routing<\/strong><\/h2>\n\n\n\n

Una volta autenticato, il cliente era davvero sulla rete. Se apriva Netscape e digitava il nome di un sito, prima ancora di scaricare una pagina il resolver doveva ottenere dal DNS l\u2019indirizzo IP corrispondente. Internet Force gestiva direttamente i propri name server, primario e secondario, sui sistemi centrali.<\/p>\n\n\n\n

Ottenuto l\u2019indirizzo, i pacchetti del cliente milanese passavano dal 2511 alla backbone \u201cworld\u201d e raggiungevano il Cisco 2501 centrale, che instradava il traffico sul collegamento Frame Relay verso IDT e da l\u00ec su Internet. Il firewall non era sul percorso ordinario di quella sessione.<\/p>\n\n\n\n

Anche l\u2019indirizzo IP della sessione veniva assegnato dinamicamente: il pool era gestito dal servizio DHCP fornito dagli stessi access point. Il routing della rete, invece, rimase statico. Il progetto discusso con Xpert prevedeva di introdurre IGRP quando la crescita dell\u2019infrastruttura lo avesse reso utile; con l\u2019aggiunta di un secondo collegamento verso un carrier italiano Internet Force avrebbe inoltre dovuto evolvere verso un proprio Autonomous System. La societ\u00e0 chiuse prima che quel passaggio diventasse necessario.<\/p>\n\n\n\n

La stessa telefonata da Pesaro, Palermo o Gorgonzola<\/strong><\/h1>\n\n\n\n

I POP remoti aggiungevano un passaggio, ma non duplicavano i servizi centrali. Pesaro, Palermo e Gorgonzola avevano ciascuno una coppia di apparati Cisco: un 2511 per le linee asincrone e l\u2019accesso dial-up, e un 2501 che collegava il POP alla backbone del provider. I due router erano collegati localmente; da l\u00ec il POP raggiungeva Milano attraverso un circuito dedicato CDA\/CDN da 64 kbit\/s.<\/p>\n\n\n\n

Il cliente di Pesaro, per esempio, faceva un percorso concettualmente semplice: telefono \u2192 modem \u2192 Cisco 2511 \u2192 Cisco 2501 del POP \u2192 backbone \u2192 Cisco 2501 centrale \u2192 IDT \u2192 Internet. Quando serviva autenticarsi, il 2511 apriva invece il ramo XTACACS verso USERS a Milano.<\/p>\n\n\n\n

Questa scelta permetteva di mantenere i POP relativamente semplici. Non c\u2019erano server utenti, mail server o DNS completi da amministrare in ogni citt\u00e0: il bordo della rete raccoglieva le connessioni, mentre identit\u00e0 e servizi rimanevano centralizzati.<\/p>\n\n\n\n

Xpert mi aveva insegnato anche una regola empirica per dimensionare queste reti. Il numero magico era 8, non 42. Per la banda, prendevamo la capacit\u00e0 del collegamento geografico e la moltiplicavamo per otto, confrontandola con la banda nominale complessiva dei modem. In un POP con 16 modem da 28,8 kbit\/s il carico teorico massimo era circa 461 kbit\/s; 64 kbit\/s di CDN moltiplicati per otto davano invece 512 kbit\/s. Finch\u00e9 il secondo valore rimaneva superiore al primo, il dimensionamento era considerato adeguato. Era naturalmente una regola statistica: si assumeva che non tutti gli utenti trasferissero dati contemporaneamente alla massima velocit\u00e0.<\/p>\n\n\n\n

Una logica analoga valeva per il numero di linee. I tecnici di Xpert mi indicavano come riferimento per un provider di buona qualit\u00e0 fra gli 8 e i 16 abbonati per modem: abbastanza pochi da mantenere ragionevole la probabilit\u00e0 di trovare una linea libera nelle ore di punta. Un POP con 16 modem poteva quindi servire indicativamente fra 128 e 256 abbonati senza che fosse necessario avere una linea telefonica dedicata a ciascuno.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Dettaglio dei POP: Milano e i tre POP remoti iniziali, con la successiva espansione del 1996.<\/em><\/p>\n\n\n\n

Essere online significava usare i servizi del provider<\/strong><\/h1>\n\n\n\n

Raggiungere Internet era solo una parte dell\u2019esperienza. Un ISP doveva offrire e amministrare direttamente una quantit\u00e0 di servizi che oggi tendiamo a dare per scontati o a delegare a piattaforme esterne.<\/p>\n\n\n\n

Posta elettronica<\/strong><\/h2>\n\n\n\n

La posta arrivava via SMTP e veniva conservata sui sistemi del provider. Il client dell\u2019utente la recuperava tramite POP3 o IMAP. USERS ospitava quindi non soltanto l\u2019identit\u00e0 necessaria per collegarsi, ma anche una parte importante della vita digitale quotidiana dell\u2019abbonato.<\/p>\n\n\n\n

Web, FTP, News e mailing list<\/strong><\/h2>\n\n\n\n

DATA ospitava il Web pubblico e l\u2019FTP anonimo, oltre a servizi e contenuti che cambiarono nel tempo. Le mailing list erano gestite con Majordomo. Usenet faceva ancora parte dell\u2019esperienza normale di Internet. Il feed esterno arrivava da news.ios.com via NNTP: \u00e8 lo stesso flusso che compare nella regola 12 della policy FireWall-1.<\/p>\n\n\n\n

Questa \u00e8 forse la differenza pi\u00f9 evidente rispetto a molti servizi Internet contemporanei: il provider non vendeva soltanto un \u201ctubo\u201d. Doveva costruire e mantenere un piccolo ecosistema di servizi interoperabili. Per l\u2019utente erano icone separate sul desktop: Netscape, Eudora, un client FTP, un newsreader, Telnet. Dietro ciascuna icona c\u2019era un protocollo, e dietro quel protocollo un daemon che qualcuno doveva configurare e tenere in vita.<\/p>\n\n\n\n

Dietro la rete c\u2019era un ufficio<\/strong><\/h1>\n\n\n\n

Le configurazioni raccontano bene i pacchetti, ma meno bene le persone. Eppure anche l\u2019Office LAN ha lasciato una specie di organigramma fossile: i nomi delle macchine. Alcuni erano funzionali, come \u201cdvlp\u201d e \u201chtml\u201d; altri coincidevano con i nomi con cui in ufficio identificavamo le workstation. Rivederli oggi \u00e8 probabilmente il modo pi\u00f9 rapido perch\u00e9 un ex collega riconosca il proprio posto di lavoro senza che io debba trasformare questo articolo nell\u2019elenco telefonico del 1995.<\/p>\n\n\n\n

L\u2019ambiente era molto eterogeneo. La mia workstation \u201cmarco\u201d era un 486DX con Linux Slackware; DVLP era una Sun SPARCstation; \u201cmaxi\u201d, usata da uno dei commerciali, era un PowerBook; diverse workstation dell\u2019ufficio erano Macintosh con System 7.5.x. \u201cLaura\u201d e \u201cAlice\u201d, in particolare, erano Power Macintosh 9500 della redazione. Nel 1996 comparve anche \u201coracolo\u201d, un sistema Windows NT con Oracle. Tutto conviveva sulla stessa infrastruttura Ethernet dell\u2019ufficio, collegata tramite un hub 3Com.<\/p>\n\n\n\n

La redazione: Web e carta<\/strong><\/h2>\n\n\n\n

Internet Force aveva una redazione giornalistica che produceva contenuti per il Web ma anche una rivista cartacea. laura e alice erano workstation Power Macintosh 9500 equipaggiate con una suite completa di desktop publishing e trattamento delle immagini: QuarkXPress, Adobe PageMaker, Adobe Photoshop e Adobe Type Manager.<\/p>\n\n\n\n

La direzione artistica lavorava invece sulla macchina \u201csalvatore\u201d, preparando anche le immagini finite destinate ai siti. La macchina \u201cHTML\u201d aveva un compito molto meno ambiguo del suo nome: l\u00ec le pagine venivano scritte a mano in HTML. Nel 1995, se si voleva controllare davvero il risultato, era una pratica perfettamente normale.<\/p>\n\n\n\n

Dal file HTML al server pubblico<\/strong><\/h2>\n\n\n\n

Il passaggio dalla redazione alla produzione era gi\u00e0 separato. Avevo predisposto su DVLP un\u2019area FTP a uso interno. salvatore forniva a HTML gli asset grafici; HTML costruiva le pagine e, quando il sito era completo, l\u2019intero artefatto veniva depositato in una cartella dedicata ai siti sull\u2019FTP interno.<\/p>\n\n\n\n

A quel punto intervenivo io. Prelevavo il sito, verificavo che fosse completo e funzionasse come previsto e lo caricavo su DATA. La redazione, quindi, non pubblicava direttamente sul Web server di produzione. C\u2019erano authoring, un\u2019area di scambio che oggi chiameremmo staging, una verifica tecnica e infine il deployment. Non lo chiamavamo CI\/CD, e forse \u00e8 meglio cos\u00ec: funzionava anche senza una dashboard con dodici badge verdi.<\/p>\n\n\n\n

Quando serviva interattivit\u00e0 sviluppavo personalmente dei CGI. Nel marzo 1996 installai PHP\/FI (una delle primissime versioni di PHP da compilare come cgi); successivamente arriv\u00f2 anche Postgres95 su DATA, database che in futuro sarebbe divenuto noto come PostgreSQL. Non ricordo ancora la data esatta dell\u2019installazione del database, e l\u2019archeologia serve anche a questo: lasciare aperta una data finch\u00e9 non salta fuori il reperto che la chiude.<\/p>\n\n\n\n

In pochi mesi quella pipeline racconta una trasformazione pi\u00f9 ampia del Web: pagine statiche scritte a mano, CGI, scripting server-side e infine dati persistenti gestiti da un database.<\/p>\n\n\n\n

Un server Oracle perch\u00e9 il mestiere cambiava continuamente<\/strong><\/h2>\n\n\n\n

\u201coracolo\u201d, documentato nell\u2019archivio nel 1996, era un esperimento Windows NT con Oracle. Non faceva parte del cuore Unix dell\u2019ISP: i soci volevano costruire competenze su quella piattaforma per poter proporre anche consulenza ai clienti. Il dettaglio divertente \u00e8 che io Oracle e Windows NT non li conoscevo.<\/p>\n\n\n\n

Li studiai da autodidatta in circa sette-dieci giorni e realizzai il progetto. \u00c8 un episodio che descrive abbastanza bene cosa significasse essere il responsabile tecnico di una piccola societ\u00e0 Internet in quegli anni: non esisteva un team Unix, uno database, uno security, uno networking e uno Web. Il perimetro del ruolo si spostava insieme al problema.<\/p>\n\n\n\n

Una rete che potevi vedere<\/strong><\/h1>\n\n\n\n

L\u2019intero sistema veniva monitorato dalla mia workstation Linux attraverso Scotty\/Tkined, un ambiente Tcl\/Tk per la gestione delle reti. La mappa non era soltanto un disegno: tramite SNMP potevo osservare il traffico sulle interfacce, l\u2019utilizzo delle linee asincrone dei Cisco, lo stato dei nodi e altri indicatori operativi.<\/p>\n\n\n\n

\u00c8 proprio da una mappa tkined originale conservata nei backup che \u00e8 partita una parte importante della ricostruzione del 2026. Confrontandola con configurazioni Cisco, file di routing, DNS, documenti hardware e policy del firewall \u00e8 stato possibile distinguere ci\u00f2 che ricordavo correttamente, ci\u00f2 che apparteneva a momenti diversi e qualche dettaglio che trent\u2019anni avevano inevitabilmente mescolato.<\/p>\n\n\n\n

Guardata oggi, l\u2019infrastruttura sembra minuscola: poche Sun, alcuni Cisco, rack di modem, due hub Ethernet e un collegamento internazionale che prima misurava 128 kilobit e poi due megabit. Ma dentro quella mappa c\u2019erano gi\u00e0 quasi tutti i problemi fondamentali di un provider: accesso, routing, AAA, DNS, posta, Web, sicurezza, monitoring, provisioning e pubblicazione dei contenuti.<\/p>\n\n\n\n

Il repository: il livello sotto la storia<\/strong><\/h1>\n\n\n\n

Questo articolo segue volutamente i processi e non i file. Il repository GitHub fa il contrario: permette di aprire il cofano e scendere dentro l\u2019infrastruttura. Le configurazioni Cisco e Unix, le zone DNS, la policy del firewall, le mappe di rete, i documenti operativi e i reperti recuperati sono organizzati in modo da poter essere letti nel loro contesto, distinguendo i materiali originali dalle ricostruzioni.<\/p>\n\n\n\n

Ho cercato per\u00f2 di non trasformarlo in una semplice collezione di vecchi file. Le mappe interattive permettono di esplorare i POP, la rete centrale e i singoli sistemi, arrivando dalle macchine alle configurazioni che sono sopravvissute. Chi preferisce seguire un percorso tecnico pu\u00f2 invece partire da \u201cBuild an Internet Force POP\u201d, una guida che prova a rispondere a una domanda molto concreta: se nel 1995 aveste dovuto costruire un Internet provider, da dove avreste cominciato?<\/p>\n\n\n\n

Il percorso parte dalla preparazione di una macchina Unix e attraversa routing, modem e access server, autenticazione, DNS, posta, Web, sicurezza, monitoring e gestione operativa. In pratica segue dall\u2019interno molti degli stessi processi raccontati in questo articolo, ma permettendo di aprire i file e vedere come erano realmente configurati.<\/p>\n\n\n\n

Tra le cose che l\u2019archivio ha permesso di ricostruire ci sono anche procedure quotidiane ormai completamente scomparse. Registrare un dominio, per esempio, era molto pi\u00f9 complesso di oggi; per i .it esistevano inoltre vincoli amministrativi e tecnici particolarmente rigidi. Nel repository \u00e8 ricostruita l\u2019intera procedura, passo per passo, insieme ad alcuni esempi reali di registrazioni che ho effettuato ai tempi come Internet Force.<\/p>\n\n\n\n

Nel repository sono finiti anche reperti meno infrastrutturali: il Welcome Kit destinato ai clienti, documenti e post Usenet, materiali recuperati dalle mailbox, i sorgenti della Guida ad Internet e alla realt\u00e0 virtuale e altri frammenti della cultura tecnica di quegli anni. Non perch\u00e9 tutto ci\u00f2 facesse parte dello stesso \u201csistema\u201d, ma perch\u00e9 un ISP non era soltanto router e daemon: era anche il modo in cui quelle tecnologie venivano imparate, spiegate e utilizzate.<\/p>\n\n\n\n

Altri strati dell\u2019archivio<\/strong><\/h1>\n\n\n\n

Nei backup della mia workstation Linux<\/a> di allora sono riemerse anche alcune cartelle di posta originali. Dentro ci sono messaggi tecnici e mailing list, i ringraziamenti di persone che avevano scaricato la mia Guida ad Internet e alla realt\u00e0 virtuale, scambi personali e inevitabili barzellette nerd. <\/p>\n\n\n\n

Nei backup sono riemersi anche i sorgenti della Guida ad Internet e alla realt\u00e0 virtuale<\/a> stessa, insieme ad altro materiale legato agli esperimenti che facevamo allora con il Web e con VRML. Nel 1995-96 la realt\u00e0 virtuale sul Web sembrava una delle possibili direzioni in cui Internet avrebbe potuto evolvere: mondi tridimensionali descritti in VRML, navigabili dal browser con gli strumenti dell\u2019epoca. Rivedere oggi quei sorgenti \u00e8 interessante proprio perch\u00e9 conserva non soltanto ci\u00f2 che Internet era, ma anche alcune delle idee su ci\u00f2 che pensavamo potesse diventare.<\/p>\n\n\n\n

Nello stesso backup \u00e8 riemerso anche il materiale di un articolo che scrissi nel 1997, dopo aver partecipato al DEFCON V<\/a> di Las Vegas, una delle prime edizioni della convention hacker. \u00c8 successivo alla chiusura di Internet Force e quindi non appartiene alla storia dell\u2019ISP, ma il fatto che sia rimasto nello stesso backup DAT racconta bene un\u2019altra caratteristica dell\u2019archeologia digitale: gli archivi personali non rispettano i confini delle aziende o dei progetti, continuano semplicemente ad accumulare strati.<\/p>\n\n\n\n

Rileggerle fa emergere un\u2019altra differenza apparentemente minuscola: le signature delle email. Ai tempi spesso non erano noiosi blocchi aziendali standardizzati, ma piccole dichiarazioni di identit\u00e0 fatte di citazioni, motti, ASCII art o battute. Anche da quattro righe in fondo a un messaggio traspariva la personalit\u00e0 di chi scriveva.<\/p>\n\n\n\n

Il repository \u00e8 pubblico qui: https:\/\/github.com\/pippocom\/internetforce-1995<\/a>. Se questo articolo racconta cosa accadeva quando un cliente si collegava, l\u00ec si pu\u00f2 seguire il percorso fino ai file di configurazione e, volendo, provare a capire come si costruiva davvero un ISP nel 1995. Il repository comprende anche la guida Build an Internet Force POP<\/a>, che attraversa passo per passo la costruzione dell\u2019infrastruttura; le mappe interattive permettono invece di esplorare la rete complessiva<\/a>, la struttura dei POP<\/a>  e i dettagli dei server centrali<\/a>.<\/p>\n\n\n\n

C\u2019\u00e8 anche un motivo pi\u00f9 personale per averlo pubblicato. Gran parte di ci\u00f2 che avevamo imparato allora proveniva da RFC pubbliche, sorgenti leggibili, FAQ, mailing list e discussioni tecniche aperte. Trent\u2019anni dopo, rendere nuovamente ispezionabile quell\u2019infrastruttura mi sembra un modo abbastanza naturale di restituire alla rete una parte di ci\u00f2 che la rete aveva dato a me.<\/p>\n\n\n\n

Che fine fece Internet Force?<\/strong><\/h1>\n\n\n\n

La storia della societ\u00e0 fu molto pi\u00f9 breve di quella di alcune parti della sua rete. Internet Force termin\u00f2 prematuramente la propria attivit\u00e0 alla fine del 1996: i suoi soci pensavano che non fosse un business cos\u00ec redditizio come avevano pensato e decisero di chiuderla proprio alla vigilia degli anni in cui Internet avrebbe iniziato a crescere molto pi\u00f9 rapidamente anche in Italia.<\/p>\n\n\n\n

Ma la fine della societ\u00e0 non signific\u00f2 che tutto ci\u00f2 che era stato costruito venisse semplicemente spento. Mi piace pensare che, nel suo piccolo, Internet Force avesse gettato dei semi nelle aree in cui aveva aperto i propri POP. Portare un punto di accesso locale significava installare infrastruttura e competenze, ma anche stimolare un bisogno in persone e aziende che fino a poco prima non lo avevano avuto a portata di telefonata.<\/p>\n\n\n\n

Quando Internet Force chiuse<\/a>, alcuni di quei nodi continuarono quindi una vita autonoma. Il POP di Gorgonzola prosegu\u00ec come Pointest, che ritroviamo successivamente citata anche in una delle edizioni italiane della Guida a Internet della Electronic Frontier Foundation. A Pesaro, Pesaro Point continu\u00f2 invece a crescere fino a diventare un ISP regionale: pochi anni dopo il suo sito presentava una rete articolata su nove POP nelle Marche.<\/p>\n\n\n\n

Sono soltanto due esempi, ma rendono meno netta la data in cui questa storia dovrebbe finire. Internet Force come societ\u00e0 scomparve prima di poter partecipare al boom che stava arrivando; alcuni dei POP che aveva contribuito a mettere in rete continuarono invece a crescere proprio dentro quel boom. La societ\u00e0 non raccolse quei frutti, ma qualche seme aveva germogliato.<\/p>\n\n\n\n

Cosa pu\u00f2 insegnare un provider del 1995 a chi sviluppa software oggi<\/strong><\/h1>\n\n\n\n

A trent’anni di distanza, le tecnologie utilizzate da Internet Force possono sembrare rudimentali. Eppure, osservando l’architettura e le scelte operative, emerge qualcosa di interessante: molti dei problemi che oggi affrontiamo con piattaforme cloud, strumenti DevOps e infrastrutture automatizzate erano gi\u00e0 presenti allora.<\/p>\n\n\n\n

Le tecnologie cambiano molto pi\u00f9 rapidamente dei problemi che devono risolvere.<\/p>\n\n\n\n

L’accesso alla rete richiedeva di autenticare gli utenti, gestire autorizzazioni e coordinare sistemi differenti. Oggi parliamo di Identity and Access Management, federazione delle identit\u00e0 e Zero Trust. Sono architetture e modelli di sicurezza molto pi\u00f9 evoluti, ma rispondono anche a esigenze che un provider degli anni Novanta conosceva bene: sapere chi sta accedendo, a quali risorse e con quali privilegi.<\/p>\n\n\n\n

Anche la separazione degli ambienti non nasce con i container. Compilare software su una macchina e distribuirlo su un’altra, limitare i servizi esposti, distinguere gli ambienti di lavoro da quelli operativi erano scelte tecniche che potevano essere adottate ben prima dell’esistenza delle moderne pipeline CI\/CD. L’automazione \u00e8 cambiata radicalmente; la necessit\u00e0 di controllare ci\u00f2 che viene messo in produzione, molto meno.<\/p>\n\n\n\n

Un’altra lezione riguarda la rete. Oggi l’osservabilit\u00e0 si concentra spesso su applicazioni, container e metriche dei servizi. Ma per un Internet Service Provider la rete non era uno strato trasparente: era parte integrante del sistema da comprendere, configurare e diagnosticare. \u00c8 un promemoria ancora attuale: monitorare un’applicazione senza comprenderne le dipendenze di rete significa osservarne soltanto una parte.<\/p>\n\n\n\n

C’\u00e8 poi il ruolo degli standard aperti e del software ispezionabile. Internet \u00e8 cresciuta grazie a protocolli interoperabili e a un ecosistema nel quale era possibile studiare, modificare e integrare componenti software. Non tutto era open source, naturalmente, ma la possibilit\u00e0 di comprendere il funzionamento dei sistemi, anzich\u00e9 trattarli esclusivamente come scatole nere, era una risorsa tecnica fondamentale. Lo \u00e8 ancora oggi, soprattutto quando valutiamo dipendenze tecnologiche, sicurezza e rischio di vendor lock-in.<\/p>\n\n\n\n

Infine, questi archivi ricordano una cosa che rischiamo di sottovalutare: la documentazione tecnica \u00e8 parte dell’infrastruttura, anche quando l’infrastruttura non esiste pi\u00f9.<\/p>\n\n\n\n

Configurazioni, sorgenti, script, procedure operative e persino errori raccontano non soltanto come funzionava un sistema, ma perch\u00e9 erano state prese determinate decisioni. Conservarli permette di ricostruire vincoli, compromessi e soluzioni che altrimenti andrebbero perduti.<\/p>\n\n\n\n

Conclusione: prima che Internet semplicemente \u201cci fosse\u201d<\/strong><\/h1>\n\n\n\n

La cosa che mi ha colpito di pi\u00f9 durante questa ricostruzione non \u00e8 quanto fossero primitive le tecnologie del 1995. \u00c8 il contrario: molti dei problemi erano gi\u00e0 sorprendentemente familiari. Separare sviluppo e produzione, ridurre la superficie di attacco, centralizzare l\u2019identit\u00e0, distribuire l\u2019accesso, monitorare la rete, definire policy esplicite, evitare che chi produce contenuti pubblichi direttamente sui sistemi operativi. Sono problemi che continuiamo a risolvere con strumenti molto pi\u00f9 potenti e, occasionalmente, con diagrammi molto pi\u00f9 belli.<\/p>\n\n\n\n

La differenza \u00e8 che allora i confini erano visibili. Una connessione occupava un modem. Un POP era una coppia di router e un rack di linee telefoniche. La posta era un processo su una macchina che potevi indicare con il dito. Se il DNS non funzionava, sapevi quale daemon andare a guardare. E se volevi capire Internet, prima o poi finivi per leggere una RFC o un file di configurazione.<\/p>\n\n\n\n

\u00c8 per questo che considero questi backup una piccola forma di archeologia digitale. Presi singolarmente sono resti: una route, una zone file, una policy, una directory FTP, il nome di un Macintosh. Rimessi nel loro contesto raccontano invece una comunit\u00e0 di utenti, un ufficio, una redazione e una rete che ogni giorno trasformava telefonate analogiche in accesso a Internet.<\/p>\n\n\n\n

Rimettere online tracce di un\u2019Internet in cui l\u2019infrastruttura tecnica e la comunit\u00e0 che la costruiva erano molto pi\u00f9 visibilmente intrecciate, significa restituire ancora oggi alla rete un po\u2019 della conoscenza che la rete aveva dato a me.<\/p>\n\n\n\n

Prima che Internet diventasse qualcosa che semplicemente \u201cc\u2019\u00e8\u201d, qualcuno doveva costruirlo. Un modem, un daemon e una regola di routing alla volta.<\/p>\n","protected":false},"excerpt":{"rendered":"

Stratigrafia di un’infrastruttura: ricostruire un ISP del 1995 grazie alla digital forensics Qualche tempo fa stavo cercando del vecchio materiale per rispondere a una domanda di un amico quando mi sono imbattuto in alcune directory su un NAS che non aprivo da quasi trent\u2019anni. Erano i backup e la documentazione che avevo creato per Internet… Read more<\/a><\/p>\n","protected":false},"author":352,"featured_media":36808,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_editorskit_title_hidden":false,"_editorskit_reading_time":0,"_editorskit_is_block_options_detached":false,"_editorskit_block_options_position":"{}","_uag_custom_page_level_css":"","_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[10295],"tags":[14420],"collections":[],"class_list":["post-36775","post","type-post","status-publish","format-standard","has-post-thumbnail","category-storie","tag-security-manager-it","entry"],"yoast_head":"\nArcheologia di un ISP: come funzionava davvero un Internet provider nel 1995 - Codemotion Magazine<\/title>\n<meta name=\"description\" content=\"Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995\" \/>\n<meta property=\"og:description\" content=\"Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/\" \/>\n<meta property=\"og:site_name\" content=\"Codemotion Magazine\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/Codemotion.Italy\/\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-21T13:47:13+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-21T13:49:43+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1672\" \/>\n\t<meta property=\"og:image:height\" content=\"941\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Marco Iannacone\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@CodemotionIT\" \/>\n<meta name=\"twitter:site\" content=\"@CodemotionIT\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Marco Iannacone\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"34 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/\"},\"author\":{\"name\":\"Marco Iannacone\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#\\\/schema\\\/person\\\/b307df6dc7f46ee8df1f1e82d4846ea6\"},\"headline\":\"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995\",\"datePublished\":\"2026-10-21T13:47:13+00:00\",\"dateModified\":\"2026-10-21T13:49:43+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/\"},\"wordCount\":7415,\"publisher\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/Connessione-a-Internet-1995-1.png\",\"keywords\":[\"Security Manager\"],\"articleSection\":[\"Storie\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/\",\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/\",\"name\":\"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995 - Codemotion Magazine\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/Connessione-a-Internet-1995-1.png\",\"datePublished\":\"2026-10-21T13:47:13+00:00\",\"dateModified\":\"2026-10-21T13:49:43+00:00\",\"description\":\"Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/Connessione-a-Internet-1995-1.png\",\"contentUrl\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/Connessione-a-Internet-1995-1.png\",\"width\":1672,\"height\":941},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Dev Life\",\"item\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Storie\",\"item\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/it\\\/dev-life-it\\\/storie\\\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#website\",\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/\",\"name\":\"Codemotion Magazine\",\"description\":\"We code the future. Together\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#organization\",\"name\":\"Codemotion\",\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2019\\\/11\\\/codemotionlogo.png\",\"contentUrl\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2019\\\/11\\\/codemotionlogo.png\",\"width\":225,\"height\":225,\"caption\":\"Codemotion\"},\"image\":{\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/Codemotion.Italy\\\/\",\"https:\\\/\\\/x.com\\\/CodemotionIT\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/#\\\/schema\\\/person\\\/b307df6dc7f46ee8df1f1e82d4846ea6\",\"name\":\"Marco Iannacone\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/iannacone-100x100.jpg\",\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/iannacone-100x100.jpg\",\"contentUrl\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/iannacone-100x100.jpg\",\"caption\":\"Marco Iannacone\"},\"url\":\"https:\\\/\\\/www.codemotion.com\\\/magazine\\\/author\\\/marco-iannacone\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995 - Codemotion Magazine","description":"Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/","og_locale":"en_US","og_type":"article","og_title":"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995","og_description":"Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete","og_url":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/","og_site_name":"Codemotion Magazine","article_publisher":"https:\/\/www.facebook.com\/Codemotion.Italy\/","article_published_time":"2026-10-21T13:47:13+00:00","article_modified_time":"2026-10-21T13:49:43+00:00","og_image":[{"width":1672,"height":941,"url":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png","type":"image\/png"}],"author":"Marco Iannacone","twitter_card":"summary_large_image","twitter_creator":"@CodemotionIT","twitter_site":"@CodemotionIT","twitter_misc":{"Written by":"Marco Iannacone","Est. reading time":"34 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#article","isPartOf":{"@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/"},"author":{"name":"Marco Iannacone","@id":"https:\/\/www.codemotion.com\/magazine\/#\/schema\/person\/b307df6dc7f46ee8df1f1e82d4846ea6"},"headline":"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995","datePublished":"2026-10-21T13:47:13+00:00","dateModified":"2026-10-21T13:49:43+00:00","mainEntityOfPage":{"@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/"},"wordCount":7415,"publisher":{"@id":"https:\/\/www.codemotion.com\/magazine\/#organization"},"image":{"@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#primaryimage"},"thumbnailUrl":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png","keywords":["Security Manager"],"articleSection":["Storie"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/","url":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/","name":"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995 - Codemotion Magazine","isPartOf":{"@id":"https:\/\/www.codemotion.com\/magazine\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#primaryimage"},"image":{"@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#primaryimage"},"thumbnailUrl":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png","datePublished":"2026-10-21T13:47:13+00:00","dateModified":"2026-10-21T13:49:43+00:00","description":"Nel 1995 collegarsi a Internet era un\u2019azione esplicita: il computer chiamava telefonicamente il provider, i due modem negoziavano la connessione e soltanto a quel punto iniziava una sessione di rete","breadcrumb":{"@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#primaryimage","url":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png","contentUrl":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png","width":1672,"height":941},{"@type":"BreadcrumbList","@id":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/archeologia-di-un-isp-come-funzionava-davvero-un-internet-provider-nel-1995\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.codemotion.com\/magazine\/"},{"@type":"ListItem","position":2,"name":"Dev Life","item":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/"},{"@type":"ListItem","position":3,"name":"Storie","item":"https:\/\/www.codemotion.com\/magazine\/it\/dev-life-it\/storie\/"},{"@type":"ListItem","position":4,"name":"Archeologia di un ISP: come funzionava davvero un Internet provider nel 1995"}]},{"@type":"WebSite","@id":"https:\/\/www.codemotion.com\/magazine\/#website","url":"https:\/\/www.codemotion.com\/magazine\/","name":"Codemotion Magazine","description":"We code the future. Together","publisher":{"@id":"https:\/\/www.codemotion.com\/magazine\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.codemotion.com\/magazine\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.codemotion.com\/magazine\/#organization","name":"Codemotion","url":"https:\/\/www.codemotion.com\/magazine\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.codemotion.com\/magazine\/#\/schema\/logo\/image\/","url":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2019\/11\/codemotionlogo.png","contentUrl":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2019\/11\/codemotionlogo.png","width":225,"height":225,"caption":"Codemotion"},"image":{"@id":"https:\/\/www.codemotion.com\/magazine\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/Codemotion.Italy\/","https:\/\/x.com\/CodemotionIT"]},{"@type":"Person","@id":"https:\/\/www.codemotion.com\/magazine\/#\/schema\/person\/b307df6dc7f46ee8df1f1e82d4846ea6","name":"Marco Iannacone","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/iannacone-100x100.jpg","url":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/iannacone-100x100.jpg","contentUrl":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/08\/iannacone-100x100.jpg","caption":"Marco Iannacone"},"url":"https:\/\/www.codemotion.com\/magazine\/author\/marco-iannacone\/"}]}},"featured_image_src":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-600x400.png","featured_image_src_square":"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-600x600.png","author_info":{"display_name":"Marco Iannacone","author_link":"https:\/\/www.codemotion.com\/magazine\/author\/marco-iannacone\/"},"uagb_featured_image_src":{"full":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png",1672,941,false],"thumbnail":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-150x150.png",150,150,true],"medium":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-300x169.png",300,169,true],"medium_large":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-768x432.png",768,432,true],"large":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-1024x576.png",1024,576,true],"1536x1536":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-1536x864.png",1536,864,true],"2048x2048":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1.png",1672,941,false],"small-home-featured":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-100x100.png",100,100,true],"sidebar-featured":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-180x128.png",180,128,true],"genesis-singular-images":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-896x504.png",896,504,true],"archive-featured":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-400x225.png",400,225,true],"gb-block-post-grid-landscape":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-600x400.png",600,400,true],"gb-block-post-grid-square":["https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/10\/Connessione-a-Internet-1995-1-600x600.png",600,600,true]},"uagb_author_info":{"display_name":"Marco Iannacone","author_link":"https:\/\/www.codemotion.com\/magazine\/author\/marco-iannacone\/"},"uagb_comment_info":0,"uagb_excerpt":"Stratigrafia di un’infrastruttura: ricostruire un ISP del 1995 grazie alla digital forensics Qualche tempo fa stavo cercando del vecchio materiale per rispondere a una domanda di un amico quando mi sono imbattuto in alcune directory su un NAS che non aprivo da quasi trent\u2019anni. Erano i backup e la documentazione che avevo creato per Internet……","lang":"it","_links":{"self":[{"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/posts\/36775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/users\/352"}],"replies":[{"embeddable":true,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/comments?post=36775"}],"version-history":[{"count":3,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/posts\/36775\/revisions"}],"predecessor-version":[{"id":36810,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/posts\/36775\/revisions\/36810"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/media\/36808"}],"wp:attachment":[{"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/media?parent=36775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/categories?post=36775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/tags?post=36775"},{"taxonomy":"collections","embeddable":true,"href":"https:\/\/www.codemotion.com\/magazine\/wp-json\/wp\/v2\/collections?post=36775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}