In questi giorni è circolata la notizia (v.rif. a fine post) che le tracce delle prove scritte dei prossimi Esami di Maturità non saranno più trasferite fisicamente in forma cartacea (come avveniva finora), bensì trasmesse "per via telematica" attraverso un cosiddetto "plico telematico". A quanto si è capito, si tratterebbe di uno o più file criptati, contenenti appunto le tracce delle prove d'esame, che i Presidenti di Commissione dovrebbero "aprire" (decriptare) la mattina stessa in cui si svolgono gli Esami.
martedì 27 marzo 2012
giovedì 15 marzo 2012
Ci risiamo!
Torno su un argomento che mi sta a cuore: azioni tecnicamente arbitrarie e assolutamente fuori standard compiute dai Provider.
Caro il mio Provider (che non nomino, tanto tu lo sai e per gli altri il discorso è analogo, se si comportano allo stesso modo), Internet è un mondo affollato, complesso, ma anche ben regolamentato dal punto di vista tecnico.
In particolare, l'uso e l'assegnazione degli indirizzi IP v4 è stato stabilito e regolamentato da diverse RFC (vedi elenco alla fine di questo articolo). Fino a prova contraria (sono andato a rileggerle tutte, perché mi pareva di aver sognato), l'indirizzo 127.0.0.1 è assegnato all'interfaccia locale di loopback di ciascun computer, e non può comparire in nessun pacchetto IP v4 che viaggia in rete. Questo indirizzo (in realtà tutta la rete 127.0.0.0/8) può venire utilizzato per servizi locali richiamati da software eseguito localmente. Mi spiego con un esempio pratico: configuro un webserver locale a supporto di un prodotto simpatico come Nagios3, e tramite il browser in locale raggiungo http://127.0.0.1/qualcosa e visualizzo le informazioni che mi interessano, raccolte da Nagios3.
A questo punto sorge spontanea la domanda: quando tu Provider devi bloccare l'accesso a un dominio DNS, per quale motivo mi risolvi quel dominio con l'indirizzo 127.0.0.1? Quale sarebbe la necessità tecnica di questa scelta? Perché invadi il campo degli indirizzi assegnati all'interfaccia di loopback del mio computer invece di restituirmi semplicemente l'errore DNS NXDOMAIN?
Non sono certo qui per insegnarti a fare bene il tuo mestiere, ma in questo caso l'errore concettuale è troppo evidente per essere taciuto. Non mi aspetto una risposta poiché questo piccolo blog non ha quella risonanza e fama che altri possono vantare, ma almeno lasciami mettere i puntini sulle "i", anzi sugli IP address.
---
Elenco delle RFC riguardanti l'uso speciale di alcuni indirizzi IP:
Caro il mio Provider (che non nomino, tanto tu lo sai e per gli altri il discorso è analogo, se si comportano allo stesso modo), Internet è un mondo affollato, complesso, ma anche ben regolamentato dal punto di vista tecnico.
In particolare, l'uso e l'assegnazione degli indirizzi IP v4 è stato stabilito e regolamentato da diverse RFC (vedi elenco alla fine di questo articolo). Fino a prova contraria (sono andato a rileggerle tutte, perché mi pareva di aver sognato), l'indirizzo 127.0.0.1 è assegnato all'interfaccia locale di loopback di ciascun computer, e non può comparire in nessun pacchetto IP v4 che viaggia in rete. Questo indirizzo (in realtà tutta la rete 127.0.0.0/8) può venire utilizzato per servizi locali richiamati da software eseguito localmente. Mi spiego con un esempio pratico: configuro un webserver locale a supporto di un prodotto simpatico come Nagios3, e tramite il browser in locale raggiungo http://127.0.0.1/qualcosa e visualizzo le informazioni che mi interessano, raccolte da Nagios3.
A questo punto sorge spontanea la domanda: quando tu Provider devi bloccare l'accesso a un dominio DNS, per quale motivo mi risolvi quel dominio con l'indirizzo 127.0.0.1? Quale sarebbe la necessità tecnica di questa scelta? Perché invadi il campo degli indirizzi assegnati all'interfaccia di loopback del mio computer invece di restituirmi semplicemente l'errore DNS NXDOMAIN?
Non sono certo qui per insegnarti a fare bene il tuo mestiere, ma in questo caso l'errore concettuale è troppo evidente per essere taciuto. Non mi aspetto una risposta poiché questo piccolo blog non ha quella risonanza e fama che altri possono vantare, ma almeno lasciami mettere i puntini sulle "i", anzi sugli IP address.
---
Elenco delle RFC riguardanti l'uso speciale di alcuni indirizzi IP:
- RFC 3330 - obsoleta, ma sempre utile da conoscere
- RFC 5735 - sostituisce la 3330, affermando gli stessi principi per gli indirizzi di loopback
- RFC 1122 sez. 3.2.1.3 - dice chiaramente che gli indirizzi 127.<any> "MUST NOT appear outside a host"
domenica 19 febbraio 2012
Lo strano caso di un sito fantasma
ATTENZIONE: TUTTO QUANTO DESCRITTO NEL PRESENTE ARTICOLO CORRISPONDE A FATTI REALMENTE AVVENUTI, COSÌ COME RIPORTATI. IL SOTTOSCRITTO NON HA NESSUNA RELAZIONE CON LE PERSONE O GLI ENTI INDICATI E NON INTENDE CON LE SUE PAROLE ESPRIMERE VALUTAZIONI SU DI ESSI. L'ARTICOLO HA ESCLUSIVAMENTE VALORE DI RICERCA TECNICA NELL'AMBITO DELLA SICUREZZA INFORMATICA, ED A TALE AMBITO ESCLUSIVO SI RIFERISCE. L'AUTORE RESTA COMUNQUE A DISPOSIIZIONE PER EVENTUALI CHIARIMENTI IN MERITO A QUANTO ESPOSTO.
Leggendo i giornali(1), sono venuto a conoscenza del fatto che un GIP avrebbe ordinato il sequestro e l'oscuramento di un sito Web(2). Fin qui nulla di strano: ogni giorno vengono individuati siti con contenuto pedo-pornografico oppure siti che permettono la condivisione di materiale protetto dai diritti d'autore. In questo caso, tuttavia, sembra trattarsi di altro (diffamazione, ex art. 595 c.p.: per una sua definizione v. p.es. http://www.studiolegale-online.net/penale_r02.php). Quindi si tratterebbe (il condizionale è d'obbligo, in quanto non ho sottomano il Decreto del GIP) per la prima volta nella giurisprudenza italiana di un oscuramento di un sito (in Italia) per un presunto reato di questo tipo, oltretutto in fase indiziaria, prima che il Giudice Ordinario abbia potuto prendere in carico il caso. L'ulteriore anomalia, a mio modo di vedere, consisterebbe nel fatto di aver richiesto esplicitamente l'inibizione all'accesso all'indirizzo IP relativo al sito in questione, senza tenere in considerazione la possibilità che tale indirizzo IP possa essere condiviso con altri e ben distiniti siti web che nulla hanno a che vedere con quello incriminato e che sono gestiti e amministrati da soggetti del tutto diversi. In effetti, avviene che l'indirizzo IP 72.167.232.231 sia condiviso anche (e non solo) dai siti: "www.jacklondon.com" e "fedora-tunisia.org".
Implementazione del "blocco".
Ma vediamo come i provider italiani, a cui il Decreto del GIP si rivolge per ottenere l'oscuramento, hanno realizzato quanto richiesto.
Posso portare testimonianza diretta di ciò che avviene accedendo ad Internet tramite il mio provider (AliceADSL): se qualcuno dei lettori vuole aggiungere informazioni, è ovviamente il benvenuto.
Dunque sul mio pc avviene che il nome "www.vajont.info" venga risolto con l'indirizzo IP: 127.0.0.1. Sorpresa! Quindi il sito incriminato "esiste" e per di più sarebbe localizzato sul mio pc! Sta di fatto che io ho attivo un webserver sull'indirizzo 127.0.0.1 che utilizzo ovviamente in locale (dal mio stesso pc, e non sarebbe possibile altrimenti) per tutt'altro scopo, non certo per scimmiottare "www.vajont.info". Quindi se io, all'oscuro di tutta la faccenda, cercassi di raggiungere "www.vajont.info" verrei magicamente dirottato sul sito di default del mio stesso webserver: direi che il fatto è piuttosto singolare, se non oltremodo irritante (e non ho indagato oltre, se questo anomalo comportamento del provider possa configurarsi come illecito).
Un'altra sorpresa è stata quando un mio amico italiano che vive all'estero mi ha confermato che "www.vajont.info" è tranquillamente raggiungibile, e risponde all'indirizzo IP 72.167.232.231. Si potrebbe obiettare che la giurisdizione di un GIP italiano si ferma ai nostri confini, ma è altrettanto vero che, se lo scopo dell'oscuramento è quello di impedire la visualizzazione di quel sito ai cittadini italiani, si stanno trascurando gli italiani all'estero. Non faccio menzione degli italiani in Italia che, con semplici artifici, riescono comunque a raggiungere quel sito anche dall'Italia, perché si tratta di comportamenti in qualche misura censurabili, ancorché diffusi.
In altre parole, quel provvedimento, per la maniera in cui è stato attuato, si rivela abbastanza inefficace.
Sottolineo la circostanza che l'indirizzo IP 72.167.232.231 non è stato affatto disabilitato, nemmeno dall'Italia, in quanto i già nominati siti "www.jacklondon.com" e "fedora-tunisia.org" risultano normalmente raggiungibili dal mio pc proprio attraverso quell'indirizzo. E giustamente, secondo la mia opinione. Per fare un parallelo con la vita comune, se viene commesso un omicidio in un appartamento, si sequestra (se necessario) l'appartamento, e non tutto lo stabile, né tantomeno il quartiere in cui è avvenuto il fatto.
Effetti collaterali.
A poca distanza dal fatto sopra riportato, ne avviene un altro, che sembra ad esso collegato, stando alle dichiarazioni di chi dice di averlo messo in opera(3). Il sito internet di uno degli autori della denuncia da cui tutto ciò ha avuto origine(4) viene violato dal sedicente gruppo "Anonymous Italia", che mette il sito in condizioni non operative e inserisce un proprio messaggio all'interno del sito stesso(5). Osservazione: se è stato così velocemente possibile eseguire queste (illecite) operazioni, si può dedurre che il soggetto non ha riposto sufficiente attenzione ai livelli di sicurezza del proprio sito istituzionale, né ha delegato tale incombenza a persone che potessero proteggerlo da questo sfortunato incidente.
Considerazioni finali.
Da un punto di vista di "analisi del rischio" si potrebbe concludere che difendere la propria reputazione in rete è più importante che tutelare il proprio sito istituzionale da attacchi dei "soliti hacker" (espressione che disconosco, come i miei lettori sanno benissimo). Per il mestiere che mi onoro di avere scelto, non sono d'accordo.
----
Note:
(1) http://www.repubblica.it/tecnologia/2012/02/17/news/giudice_chiude_sito_scilipoti-30053511/
(2) http://www.vajont.info/
(3) http://pastebin.com/S0FCaLmV
(4) http://www.mauriziopaniz.it/
(5) http://www.mauriziopaniz.it/public/
IP 72.167.232.231
mercoledì 15 febbraio 2012
Ron e Whit
Brutte notizie per la crittografia basata su algoritmo RSA, o almeno così sembra, stando alla ricerca pubblicata da alcuni esperti (dettagli e link in fondo a questo articolo).
In poche parole, sono stati analizzati oltre 6 milioni di certificati X.509, contenenti altrettante chiavi pubbliche di crittografia, riscontrando una significativa ricorrenza (1%) di moduli duplicati.
Che cosa significa in pratica? che utilizzando quei particolari certificati, si potrebbe facilmente risalire alle relative chiavi private di cifratura, e quindi decriptare i dati (in transito). Semplificando al massimo, in quei casi sarebbe come non utilizzare affatto la crittografia, essendo tuttavia formalmente convinti di sfruttarne ancora le proprietà.
Diciamo che non è un pericolo immediato per la sopravvivenza della crittografia così come oggi la conosciamo e usiamo, ma piuttosto una mina vagante che impedisce di dormire sonni tranquilli.
Senza dubbio verranno prese le opportune contromisure, ma tutto ciò richiede tempo, e soprattutto non potrà essere messo in produzione a breve.
Nel frattempo, speriamo che il nostro home-banking resti abbastanza sicuro.
E ora i link promessi:
In poche parole, sono stati analizzati oltre 6 milioni di certificati X.509, contenenti altrettante chiavi pubbliche di crittografia, riscontrando una significativa ricorrenza (1%) di moduli duplicati.
Che cosa significa in pratica? che utilizzando quei particolari certificati, si potrebbe facilmente risalire alle relative chiavi private di cifratura, e quindi decriptare i dati (in transito). Semplificando al massimo, in quei casi sarebbe come non utilizzare affatto la crittografia, essendo tuttavia formalmente convinti di sfruttarne ancora le proprietà.
Diciamo che non è un pericolo immediato per la sopravvivenza della crittografia così come oggi la conosciamo e usiamo, ma piuttosto una mina vagante che impedisce di dormire sonni tranquilli.
Senza dubbio verranno prese le opportune contromisure, ma tutto ciò richiede tempo, e soprattutto non potrà essere messo in produzione a breve.
Nel frattempo, speriamo che il nostro home-banking resti abbastanza sicuro.
E ora i link promessi:
Ron e Whit
Brutte notizie per la crittografia basata su algoritmo RSA, o almeno così sembra, stando alla ricerca pubblicata da alcuni esperti (dettagli e link in fondo a questo articolo).
In poche parole, sono stati analizzati oltre 6 milioni di certificati X.509, contenenti altrettante chiavi pubbliche di crittografia, riscontrando una significativa ricorrenza (1%) di moduli duplicati.
Che cosa significa in pratica? che utilizzando quei particolari certificati, si potrebbe facilmente risalire alle relative chiavi private di cifratura, e quindi decriptare i dati (in transito). Semplificando al massimo, in quei casi sarebbe come non utilizzare affatto la crittografia, essendo tuttavia formalmente convinti di sfruttarne ancora le proprietà.
Diciamo che non è un pericolo immediato per la sopravvivenza della crittografia così come oggi la conosciamo e usiamo, ma piuttosto una mina vagante che impedisce di dormire sonni tranquilli.
Senza dubbio verranno prese le opportune contromisure, ma tutto ciò richiede tempo, e soprattutto non potrà essere messo in produzione a breve.
Nel frattempo, speriamo che il nostro home-banking resti abbastanza sicuro.
E ora i link promessi:
(wordpress permettendo)
martedì 17 gennaio 2012
Achab è morto
Ricordate Moby Dick? E il Capitano che le dava la caccia? Bene, erano altri tempi, e soprattutto quello di Melville è un romanzo. La realtà è ben differente.
Quando avevo la responsabilità della Sicurezza IT di oltre 5000 utenti e diverse decine di Server con dati "sensibili", ogni sera uscendo dal lavoro pensavo a quello che sarebbe successo se una notte... se mi fossi trovato con gli utenti impossibilitati a lavorare, magari a causa di un incidente di sicurezza. Eppure non sono Achab. Ma sapevo che in quel caso mi sarei alzato nel cuore della notte e sarei "salito a bordo della nave", semplicemente perché fa parte del mio mestiere.
Ognuno ha le proprie responsabilità, e se le assume. E quando non se le assume è giusto che ci sia qualcun altro che lo mette alle corde. Per il bene e la salvezza di una moltitudine, ma anche per il bene e la salvezza di una professione. Certe competenze non si improvvisano, e se pur possedendole non si mettono in campo, allora è giunto il momento di cambiare mestiere.
Quando ho letto: "nave con oltre 4000 posti", ho subito pensato: "una gigantesca bara galleggiante". Un mezzo stadio di calcio in balia del Mare e della tecnologia (il Mare lo scrivo in maiuscolo perché lo rispetto). Per qualsiasi professionista della sicurezza, gestire 4000 persone riunite in un solo posto è un incubo. Sarebbe come gestire un progetto con 4000 milestone indipendenti. Un incubo, appunto.
Come quando si mette in piedi una LAN da 5000 postazioni in un unico dominio di broadcast. Cito questo esempio perché purtroppo l'ho visto fare, e l'ho subito in prima persona come "problema" nel momento in cui "qualcosa" è andato storto, cioè ha scatenato un "broadcast storm". Tutto fermo e lo spanning tree impazzito
.La gestione della Security tramite falsi concetti statistici ("non è mai successo, perché dovrebbe succedere adesso, perché proprio a noi?") è purtroppo tragicamente reale. Non solo nell'IT.
Quando avevo la responsabilità della Sicurezza IT di oltre 5000 utenti e diverse decine di Server con dati "sensibili", ogni sera uscendo dal lavoro pensavo a quello che sarebbe successo se una notte... se mi fossi trovato con gli utenti impossibilitati a lavorare, magari a causa di un incidente di sicurezza. Eppure non sono Achab. Ma sapevo che in quel caso mi sarei alzato nel cuore della notte e sarei "salito a bordo della nave", semplicemente perché fa parte del mio mestiere.
Ognuno ha le proprie responsabilità, e se le assume. E quando non se le assume è giusto che ci sia qualcun altro che lo mette alle corde. Per il bene e la salvezza di una moltitudine, ma anche per il bene e la salvezza di una professione. Certe competenze non si improvvisano, e se pur possedendole non si mettono in campo, allora è giunto il momento di cambiare mestiere.
Quando ho letto: "nave con oltre 4000 posti", ho subito pensato: "una gigantesca bara galleggiante". Un mezzo stadio di calcio in balia del Mare e della tecnologia (il Mare lo scrivo in maiuscolo perché lo rispetto). Per qualsiasi professionista della sicurezza, gestire 4000 persone riunite in un solo posto è un incubo. Sarebbe come gestire un progetto con 4000 milestone indipendenti. Un incubo, appunto.
Come quando si mette in piedi una LAN da 5000 postazioni in un unico dominio di broadcast. Cito questo esempio perché purtroppo l'ho visto fare, e l'ho subito in prima persona come "problema" nel momento in cui "qualcosa" è andato storto, cioè ha scatenato un "broadcast storm". Tutto fermo e lo spanning tree impazzito
.La gestione della Security tramite falsi concetti statistici ("non è mai successo, perché dovrebbe succedere adesso, perché proprio a noi?") è purtroppo tragicamente reale. Non solo nell'IT.
Iscriviti a:
Post (Atom)