DNS over HTTPS

Siamo abituati a ritenere che la risoluzione dei nomi avvenga tramite una richiesta in chiaro con protocollo UDP sulla porta 53 di uno dei server specificati nella configurazione dell’host. Per estensione, siamo abituati a credere che se si controllano in un qualche modo i server DNS impostati in un host, si può controllare il modo in cui l’host accede a determinati nomi a dominio.

DoH (DNS over HTTPS) potrebbe cambiare le regole del gioco e le nostre granitiche certezze.

Leggi tutto “DNS over HTTPS”

DNS server alternativi

Il sistema dei nomi a dominio è una delle tecnologie essenziali per il funzionamento del servizio Internet come viene percepito dagli utenti.

Le connessioni ad Internet in cui c’è solamente l’apparecchio del provider forniscono come server DNS quello del provider stesso, ma non è obbligatorio (non per ora…) utilizzare per forza quel server. Leggi tutto “DNS server alternativi”

Nomi degli host in LAN

Ogni host IP in una rete ha almeno un indirizzo e almeno un nome.

Se gli indirizzi sono spesso una classe /24 con spazio di manovra ridotto e, salvo eccezioni, vengono gestiti per lo più in maniera automatica, nella scelta dei nomi si scatenano fantasie e perversioni di utenti e amministratori. Leggi tutto “Nomi degli host in LAN”

Risolvere i nomi a casa propria

by Paul MasonOgni server che ho installato da che ci sono le connessioni fisse a Internet ha sempre avuto un DNS server locale senza inoltro al DNS del provider.

Il DNS è spesso visto come una bestia nera da parte di molti tecnici, secondo forse solamente al subnetting delle classi IP. Su Linux uno dei problemi di BIND è che nelle prime versioni non era esattamente verboso in merito ai messaggi di errore, anzi era del tutto ermetico, quasi binario: o partiva o non partiva e forse ti faceva la grazia di dire qual era la zona con l’errore, ma poi erano affari tuoi.

Questo ha fatto in modo che, negli anni, molti tecnici abbiano sempre evitato di aver a che fare con la bestia e preferivano delegare ad altri la (ri)soluzione del problema.

La risoluzione di un nome a dominio è una faccenda troppo delicata per essere lasciata in mano a terzi, specialmente da quando sono iniziati gli attacchi ai DNS.

Le buone ragioni per avere un DNS locale sono molteplici e sono di gran lunga maggiori di quelle che consigliano di non averlo: Leggi tutto “Risolvere i nomi a casa propria”

Attacchi ai router ADSL

luce rossaTeam Cymru ha pubblicato un report [PDF] che descrive una serie di attacchi portati ai router ADSL di fascia casalinga o SOHO.

I dispositivi coinvolti sono di molte marche tra cui TP-Link, ZxXEL, D-Link, Micronet, Tenda. Le vittime di questi attacchi sono concentrate in pochi Stati, tra cui anche l’Italia.

L’attacco sfrutta delle vulnerabilità del firmware dei dispositivi che permettono di modificare la configurazione dei dispositivi da remoto senza conoscere la password di accesso. Questi router permettono di modificare la configurazione da un IP esterno alla LAN per consentire al provider o comunque a chi fornisce il supporto di modificare le impostazioni senza intervenire sul posto. Leggi tutto “Attacchi ai router ADSL”

DNS amplification attack

I recenti fatti che hanno riguardato Spamhaus hanno rimesso in risalto il problema non nuovo di un DNS amplification attack al punto che anche l’US-CERT ha diramato un bollettino in merito.

Innanzi tutto la risposta alla domanda legittima: cosa diavolo viene amplificato in questo attacco?

Leggi tutto “DNS amplification attack”

I titoli di Star Wars in un traceroute

Ryan Werber era annoiato dal cattivo tempo di Boston.

Ryan ha creato uno script PHP per configurare delle tabelle di routing virtuali su alcuni apparati CISCO. Quindi ha aggiornato in maniera opportuna i reverse DNS di un /24 IPv4.

Il risultato lo si può vedere facendo traceroute verso 216.81.59.173, avendo l’accortezza di usare il parametro -m (-h per Windows) per allungare il TTL e vedere tutta la storia.

Leggi tutto “I titoli di Star Wars in un traceroute”

D.ROOT-SERVERS.NET cambierà indirizzo IPv4

D.ROOT-SERVERS.NET cambierà IPv4 il 3 gennaio 2013.

Il nuovo IPv4 è 199.7.91.13 che sostituisce l’attuale 128.8.10.90, che risolve anche TERP.UMD.EDU

Al fine di ridurre eventuali disservizi, il nuovo IPv4 del root DNS è già attivo e raggiungibile e il vecchio indirizzo sarà attivo per non meno di sei mesi dopo il cambio.

I SysAdmin possono cambiare, quindi, già da ora il file con le hint dei DNS che gestiscono. Dal 3 gennaio 2013 verranno aggiornati i file named.root e named.cache disponibili per il download presso InterNIC.

L’IPv6 del root DNS non cambia e rimane 2001:500:2d::d. (via nanog)

Elenco aggiornato dei TLD

Ci sono alcuni contesti in cui farebbe comodo avere a disposizione un elenco aggiornato dei TLD.

IANA mette a disposizione questo elenco in formato testo [MD5].

L’ultimo aggiornamento del 12 agosto saluta di questo file l’arrivo del TLD .POST voluto dall’UPU.

La gestione del nuovo TLD verrà delegata all’UPU; la registrazioni di domini di secondo livello non sarà accessibile al pubblico, ma saranno riservate agli operatori pubblici e privati, alle organizzazioni e agenzie governative che forniscono e supportano servizi postali universali sicuri ed affidabili.

IDN? No grazie… (almeno per il momento)

Dalle ore 14:00 dell’11 luglio 2012 il NIC italiano (l’ente preposto a regolamentare e gestire la registrazione dei domini con estensione .it) consente di registrare domini IDN (internationalized domain name) ovvero domini contenenti lettere accentate ed altri caratteri speciali che prima non erano consentiti nei domini italiani.

Peccato che nessuno si è preso la briga di controllare se i vari programmi in uso dagli utenti o in funzione sui server siano compatibili e supportino i nuovi domini.

Lo standard per i nomi di dominio non permette normalmente caratteri non ASCII ma alla fine un metodo per internazionalizzare i nomi di dominio in un formato ASCII standard è stato trovato, salvaguardando con ciò la stabilità del Domain Name System. La prima bozza di IDN è stata proposta nel 1996 ed implementata nel 1998. Nel marzo 2008 l’Internet Engineering Task Force ha formato un nuovo IDN Working Group per rimodernare il corrente protocollo IDNA.

Attualmente diverse decine di domini di primo livello supportano la registrazione gli IDN. Anche il dominio di primo livello .eu, dal 10 dicembre 2009, supporta gli IDN.

Ovviamente perché tutto funzioni tutte le varie tessere del mosaico di software che costituisce Internet deve essere aggiornato e compatibile. E quì cominciano i problemi.

Ho eseguito personalmente dei test di invio mail da alcuni dei più grandi (come numero utenti) sistemi webmail verso delle mailbox appositamente create con domini IDN ed i risultati a parer mio sono sono disastrosi.

Gmail e Tiscali non supportano gli IDN e non consentono l’invio del messaggio. Yahoo prima lo accetta poi manda un messaggio d’errore perché uno dei suoi server non riesce ad inviare il messaggio a destinazione. V’invito ad effettuare dei test con altri account, se lasciate un commento, indicando la vostra mail vera nell’apposito campo, con il quale chiedete di collaborare al test vi contatterò personalmente per indicarvi un paio di indirizzi verso cui inviare i test. I risultati saranno pubblicati su questo blog.

ATTENZIONE! Non indicate la mail nel commento ma nell’apposito spazio del form. In questo modo io potrò vedere la vostra mail e contattarvi ma questa non sarà pubblicata sul sito.

KRB_AP_ERR_MODIFIED

Cosa c’è di meglio che iniziare la settimana con un errore del genere da un cliente?

Due server Windows (un 2003 e un 2008), sul 2003 la snap-in Active Directory Users and Computers all’avvio mostra un bell’errore “Nome principale di destinazione scorretto” e non mostra utenti; ovviamente nessuni si può collegare al server.

Leggi tutto “KRB_AP_ERR_MODIFIED”

Dove sono i root DNS?

Come abbiamo visto in un altro articolo, il sistema dei nomi a dominio si basa sui root DNS.

Non ci vuole certo un esperto di networking per capire che i root DNS non solo sono un punto critico del sistema dei nomi a dominio, ma sono anche dei server molto trafficati.

Più i root DNS sono prossimi agli utenti più questi saranno veloci nel risolvere i nomi e, quindi, ad accedere ai servizi della Rete.

paf  ha raccolto su Google Maps la posizione dei root DNS nel mondo; la mappa potrebbe non essere aggiornatissima, ma aiuta molto a capire come sono distribuiti questi server.

Val la pena di evidenziare che, a causa della topologia di Internet, per molti utenti di Milano potrebbe essere più vicino il root DNS di Roma o di un’altra città europea.

Aggiornamento 17/2/2012 18:30Il sito dei root DNS ha una mappa piu precisa e aggiornata da cui si evince che in Italia ci sono due istanze a Torino, tre a Milano, due a Roma e una a Napoli.

La propagazione del DNS

Le modifiche sono a posto, ora deve aspettare 48 ore perché si propaghino

Ve l’hanno detto talmente tante volte che il concetto che il DNS si deve propagare in 48 ore è radicato nella mente di tutti, anche di alcuni SysAdmin.

Eppure nessuno (o pochi) si è mai chiesto come mai riesco a parlare in tempo reale con l’altro lato del mondo, riesco a scaricare in pochi istanti un’immagine da un server remoto, riesco ad inviare velocemente una mail, ma ci vogliono due giorni per far propagare una modifica del DNS, manco le portassero UPS o DHL con consegne overnight da un server all’altro.

Leggi tutto “La propagazione del DNS”

Possibile DoS in BIND 9

Alcune organizzazioni hanno notato che BIND 9 è vulnerabile ad un attacco di tipo DoS quando risponde a query ricorsive.

È stato, infatti, notato che le versioni 9.4-ESV, 9.6-ESV, 9.7.x e 9.8.x di BIND escono in maniera anomala loggando l’errore INSIST(! dns_rdataset_isassociated(sigrdataset)) quando rispondono a determinate query ricorsive.

Sono disponibili le patch alle versioni coinvolte; le versioni che non presentano questo problema sono 9.8.1-P1, 9.7.4-P1, 9.6-ESV-R5-P1 e 9.4-ESV-R5-P1 (via ISC).

 

DNS poisoning

Leggo che il tema del DNS poisoning è ancora attuale, circa tre anni dopo la sua esplosione.

Prima di tutto, un’introduzione per chi non conosce il funzionamento del DNS.

Ogni macchina su Internet è identificata da un indirizzo numerico (per ora, principalmente nella forma a.b.c.d dove le lettere rappresentano dei numeri da 0 a 255 decimale), ma è un dato difficile da ricordare e su uno stesso IP possono vivere più server virtuali, nel caso di httpd. È stato quindi creato un sistema che associa delle sequenze più facili da ricordare ad un indirizzo numerico: è più facile ricordare siamogeek.com piuttosto che 84.19.182.37. Il sistema per passare dal nome usato dagli umani all’indirizzo numerico utilizzato dalle macchine è detto risoluzione del nome, il quale si basa sul sistema dei nomi a dominio (DNS). Quando voglio risolvere siamogeek.com, il mio computer genera un numero di sicurezza a caso tra 0 e 65.535 e lo scrive in una richiesta che invia al server DNS di riferimento (quello definito nelle impostazioni del TCP/IP del computer). Il server DNS, elabora la richiesta e risponde allegando quel numero nella risposta per fare in modo che io abbia la (relativa) sicurezza che mi ha risposto il server legittimo e non un malintenzionato. Prima del 1995 i numeri erano scelti in sequenza e, quindi, facilmente indovinabili; ora tutti i computer li scelgono a caso, ma la bontà della casualità della scelta dipende dalla piattaforma che la esegue e, quindi, potrebbe essere facilmente indovinabile. Leggi tutto “DNS poisoning”

DNS prefetching: una pessima idea

browser moderni hanno una funzione apparentemente utile, ma che provoca un notevole e inutile incremento di traffico DNS.

Una piccola spiegazione a grandi linee su cime funziona la risoluzione dei nomi, una delle tecnologie che stanno alla base del funzionamento di Internet per l’utente finale.

Ogni macchina (host) collegata a Internet ha un indirizzo IP che è necessariamente univoco (tralasciamo i NAT delle reti private che non ci interessano in questo contesto). L’indirizzo IP è, per ora, formato da una quaterna di numeri decimali da 0 a 255 separati da punti, tipo 1.2.3.4

Per rendere più facile la memorizzazione dei siti, esiste un sistema che assegna ad ogni indirizzo (ad esempio 209.62.58.154) uno più nomi a dominio (ad esempio siamogeek.com). Questo accoppiamento è gestito dal DNS.

Leggi tutto “DNS prefetching: una pessima idea”

Script per blacklistare i domini su Windows Server

BloccoDarknet ha pubblicato un interessante script in PowerShell 2 di Jason Fossen che permette di blacklistare alcuni nomi a dominio ritenuti pericolosi.

Lo script crea una zona e, opzionalmente, degli host su un server DNS di Windows associandoli all’IP 0.0.0.0 o ad un altro indirizzo indicato. Leggi tutto “Script per blacklistare i domini su Windows Server”