Riepilogo delle puntate precedenti: la SUN Ultra 1 effettua correttamente il NAT tra le due interfacce. Il cielo sta passando dal nero al blu e questo significa che presto sorgerà il sole e con esso sorgerà anche un'orda di utenti che vorranno leggere le loro email e postare i loro gattini su Facebook. Al nostro eroe non rimane molto tempo per configurare anche il DHCP e il DNS...
Quinto episodio: DHCP e DNS.
Agli albori di Internet il numero dei computer connessi (host) era talmente esiguo che essi erano configurati a mano e che un singolo file di testo (chiamato "HOSTS.TXT") conteneva tutto l'elenco dei nomi degli host di tutta la rete Internet. Chiaramente una simile situazione non era destinata a durare a lungo.
Se volete approfondire la storia del DNS vi consiglio la lettura del RFC 882 presso il sito dell'IETF (Internet Engineering Task Force). Il documento ha più che altro un valore storico, ma è una buona introduzione hai motivi che hanno portato alla definizione del DNS.
Per i più pigri l'URL è: http://www.ietf.org/rfc/rfc0882.txt
Sì, la data è esatta: Novembre 1983. Quel documento ha passato i trent'anni d'età e lo potete leggere ancora oggi nel suo formato originale grazie ad ASCII.
Ora che la vostra mente è sconvolta concedetemi un attimo e finirò l'opera: senza il DNS il traffico del World Wide Web e delle email crollerebbe praticamente a zero. BOOM!
"Perché scrivi questo?". Perché è vero: ogni volta che voi cliccate su un link (stavo per scrivere "digitate un indirizzo nel browser", ma poi mi sono reso conto che non lo fa più nessuno) attivate senza saperlo tutta una serie di operazioni che hanno il solo scopo di mettervi in grado di fruire delle informazioni che avevate richiesto. L'intera infrastruttura è concepita per essere trasparente all'utente e ci riesce talmente bene che adesso i quindicenni non "navigano su Internet" ma "usano Facebook e YouTube" totalmente ignari dell'universo oscuro popolato da esseri barbuti e poco socievoli che c'è dietro. Sappiatelo: Internet vista da dentro somiglia molto alle Miniere di Moria.
"Ma quali sono queste operazioni?". Semplificando moltissimo e SENZA scendere al di sotto del livello applicativo dello stack TCP/IP possiamo dire che, in linea di massima, le operazioni solo le seguenti:
- Il browser provvede a suddividere l'URL nelle sue parti fondamentali estraendo protocollo, nome host (o indirizzo IP), porta (se presente), percorso della risorsa ed eventuali opzioni (tutto quello che viene dopo il punto di domanda).
- Se il protocollo è supportato dal browser questo prosegue a processare la richiesta, altrimenti controlla se ci sono altri programmi di sua conoscenza che possono evadere la richiesta al posto suo. Se entrambe le condizioni non si verificano il browser di solito notifica l'errore all'utente.
- Se l'URL contiene un indirizzo IP il browser provvede ad inviare la richiesta per quella risorsa (secondo le regole imposte dal protocollo specificato) direttamente all'IP specificato, altrimenti invia una richiesta al proprio server DNS affinché questo risolva la corrispondenza nome host -> indirizzo IP.
Arrivati a questo punto il browser ha fatto tutto quello che era in suo potere per ottenere la risorsa richiesta e tutto quello che può fare è mettersi in attesa di una risposta dal DNS o dall'IP specificato.
Se la risposta del DNS non arriva, arriva troppo tardi oppure arriva ma è errata l'utente non sarà in grado di collegarsi alla risorsa richiesta e si arrabbierà moltissimo per questo.
Lo stesso discorso vale per le email: la parte dopo la "@" indica il dominio a cui inviare quella email. Il server di posta che riceve l'email dal client provvederà ad interrogare il DNS per sapere chi è il server di posta per quel dominio e quindi provvederà ad inoltrare l'email a quel server.
Quindi per riassumere: levi il DNS e Internet MUORE. Punto. Il server che espone la risorsa può tranquillamente continuare a funzionare, ma se gli utenti non hanno modo di raggiungerlo perché il sistema che associa il nome (che loro conoscono) all'indirizzo IP (che non conoscono e che può anche cambiare tra un accesso e il successivo) non risponde di fatto tale risorsa non è più accessibile.
Come tutti noi sappiamo non esiste catastrofe peggiore al mondo: uragani, terremoti, l'uscita di un nuovo album di Nicki Minaj sono NULLA in confronto alla perdita della connessione ad Internet.
Si suppone che un servizio così fondamentale sia robusto, veloce e sicuro. In effetti gode di una ridondanza che va dal buono all'ottimo, sfrutta tutti i trucchi possibili per ridurre al minimo l'intervallo di tempo tra l'invio della richiesta e la risposta... Però sul lato sicurezza siamo decisamente scadenti.
Non starò ad elencare tutti i problemi di sicurezza del DNS, c'è una nutrita serie di articoli in merito per chi conosce l'inglese e sa usare un motore di ricerca. Mi limiterò ad una considerazione: un sistema sicuro solitamente ha controlli multipli ridondanti che rallentano l'accesso all'informazione e il servizio di risoluzione dei nomi a dominio è pensato per essere veloce perché da esso dipende buona parte della latenza iniziale nella comunicazione. Chiunque chieda sicurezza e velocità, a mio modesto avviso, vuole la botte piena e la moglie ubriaca.
L'approccio degli sviluppatori di OpenBSD al problema del DNS è piuttosto pragmatico: "prendiamo il server DNS con licenza BSD più diffuso (Bind), eliminiamo dal codice tutti i bug che potrebbero minare la sicurezza del software in questione e mandiamo upstream le patch nella speranza che le includano nella versione ufficiale". Tutto questo in attesa che ci si decida a trovare un'alternativa all'attuale sistema che sia condivisa da tutti.
L'alternativa ovviamente tarda ad arrivare, come sta tardando ad arrivare l'utilizzo di massa della versione 6 del protocollo IP. Quando si tratta di mettere TUTTI d'accordo c'è sempre da mettere in conto una notevole resistenza a qualsiasi cambiamento.
L'altro protocollo di cui discuterò è il DHCP (Dynamic Host Configuration Protocol). Anche il DHCP è nato per risolvere un problema dovuto all'aumento degli host connessi ad Internet: il problema della configurazione degli host medesimi.
Quando le reti sono piccole e il numero degli host connessi costante il problema non si pone: li si configura a mano tutti una volta per tutte e poi si provvede a configurare gli host che vengono aggiunti/sostituiti. Ma quando si cominciano ad avere centinaia di macchine e/o un ricambio continuo degli host le cose si complicano di molto. Occorre avere un sistema automatico che consenta ad un host non configurato di ricevere tutti i parametri necessari per collegarsi alla rete di appartenenza.
Come in altri casi il DHCP non è magicamente disceso tra noi in un alone di luce accompagnato da cori angelici ma è frutto dell'evoluzione di RARP in BOOTP e quindi in DHCP. A chi fosse curioso di scoprire tutti i segreti di questi protocolli consiglio la lettura degli RFC 903 (RARP), RFC 951 (BOOTP) e RFC 2131 (DHCP). Per tutti gli altri: continuate a leggere per avere la spiegazione da 30 secondi.
In breve un host connesso tramite scheda di rete Ethernet ha un indirizzo MAC (Media Access Control) salvato in un chip di memoria sulla scheda stessa. I protocolli summenzionati si appoggiano ad Ethernet e al fatto che ogni rete Ethernet ha un indirizzo di broadcast (FF:FF:FF:FF:FF:FF) a cui tutte le schede connesse rispondono. Un server si mette in ascolto per le richieste di configurazione da parte dei client e fornisce loro la configurazione basandosi sul fatto che ogni frame Ethernet contiene sia l'indirizzo MAC del mittente che quello del destinatario. I dettagli sono squisitamente descritti con dovizia di particolari in ciascuno degli RFC che ho elencato precedentemente.
Il DHCP non si limita ad inviare solo l'indirizzo IP, ma può inviare ad un host anche altre informazioni di configurazione come l'indirizzo del default gateway, l'indirizzo del server DNS (o dei server DNS) ed anche dove reperire il file con il kernel e il ramdisk di avvio per il boot da rete tramite TFPT. Oltre a questo il DHCP può essere esteso per fornire altre informazioni di configurazione agli host.
Un'altra cosa che può fare un server DHCP è sfruttare la sua conoscenza degli host connessi per aggiornare dinamicamente un server DNS sulle associazioni tra i nomi degli host e gli indirizzi IP che ha assegnato loro. Come potete immaginare una semplice ricerca per "DHCP DNS update" produrrà una nutrita serie di HOWTO e tutorial in merito.
Quello su cui voglio farvi riflettere adesso è una piccola ed inquietante considerazione: immaginate di essere in un luogo pubblico con una rete WiFi aperta (non criptata) e che qualcuno abbia avviato un server DHCP che indichi agli host che si connettono il suo PC come gateway. Se la sua risposta arriverà PRIMA di quella del DHCP ufficiale sarà presa per buona e la configurazione ricevuta sarà applicata. Costui sarà in grado di intercettare il traffico di quegli host e potrà bloccare loro l'accesso a certi siti e/o intercettare le credenziali con cui si collegano ad altri siti.
Questo genere di attacco informatico si chiama "Man In The Middle" (Uomo Nel Mezzo, abbreviato con MITM) ed è ESTREMAMENTE pericoloso e molto difficile da individuare. Sappiate inoltre che è ILLEGALE attuare un simile attacco e che non mi assumo NESSUNA responsabilità qualora decidiate di infrangere la Legge. Tutto quello che ho scritto in questo articolo è da intendersi come pura speculazione teorica ad uso didattico. Quello che decidete di fare con queste informazioni è affar vostro.
E dopo essermi parato il fondoschiena vi saluto e vi rimando al sesto ed ultimo articolo di questa serie.
Nessun commento: