La maggior parte dell’opera non consiste nel vedere se una cosa smetterà di funzionare bensì nel pensare a cosa fare quando quella cosa smetterà sicuramente di funzionare.

Questa cosa è presente anche nell’informatica e nelle telecomunicazioni: ad esempio non possiamo garantire che le trasmissioni attraverso un canale siano perfettamente prive di errori, anzi, gli errori sono sempre dannatamente frequenti se paragonati alla quantità di dati che attraversano la rete e alla precisione che ci aspettiamo in uscita.

Scarichiamo solitamente file di un paio di mega, circa 2 milioni di byte che corrispondono a 16 milioni di bit. Anche solo un errore su 100.000 bit inviati (una percentuale di errore dello 0.001%) si ripercuoterebbe nel file per 160 volte e sappiamo che, specialmente in file eseguibili, basta anche un solo bit fuori posto per mandare all’aria l’intera applicazione.

Il metodo più utilizzato per ovviare al problema è senza dubbio la ridondanza ovvero la ripetizione delle informazioni nella speranza che, anche nel caso in cui un pacchetto di informazioni venga danneggiato da un errore di trasferimento, il ricevente abbia sempre a disposizione una “copia di riserva” da cui recuperare l’informazione.

La ridondanza viene solitamente applicata su più livelli e nella pila protocollare ci sono almeno 2-3 meccanismi di ridondanza più un meccanismo di “rinvio”. Quindi possiamo dire che nel traffico di rete l’informazione utile è meno della metà del totale dei bit in transito.

Al livello più basso il meccanismo di codifica più basso e semplice che possiamo immaginare è quello di duplicare brutalmente l’informazione: se dobbiamo inviare la sequenza di bit 011010 invieremo, per sicurezza, 000111111000111000. In questo modo anche se abbiamo un errore all’interno della tripletta di bit sapremo sempre qual’era il messaggio originale. Infatti se riceviamo la tripletta 010 sappiamo che in realtà la tripletta originale era 000 e non 111 per il semplice fatto che la probabilità di un errore è molto più alta che la probabilità di due errori nella stessa tripletta! Ovviamente non abbiamo la garanzia assoluta ed è per questo che ci sono meccanismi di ridondanza anche ad alto livello.

Ma perché abbiamo messo triplette invece di coppie? Semplicemente perché la tripletta ci permette di eseguire sia la rilevazione che il recupero dell’errore. Supponendo infatti di inviare coppie quali 00 o 11 alla presenza di un errore, mettiamo 01, non possiamo distinguere se ci sia stato un errore nel primo bit (e quindi l’originale era 11) oppure l’errore fosse del secondo bit (e quindi l’originale era 00). In questo caso possiamo solamente rilevare l’errore ma non possiamo recuperarlo.

Questo fatto è indicato dalla distanza di Hamming la quale indica il numero di “errori” necessari per convertire una stringa di bit in un altra. Il primo codice che abbiamo usato ha una distanza fra i suoi elementi (ovvero fra 000 e 111) di 3. Il sistema quindi sceglierà, in caso di errore, la stringa che dista di meno da quella ricevuta. Nel nostro esempio la stringa 010 dista 1 da 000 e dista 2 da 111. Scegliendo quella a distanza minore scegliamo proprio 000.

Notiamo quindi che scegliere un codice che abbia distanza di Hamming dispari fra i propri elementi garantisce sempre il recupero dell’errore perché il sistema ha sempre una parola di codice più vicina di un altra. Una distanza di Hamming pari fra le parole invece presenta sempre, seppure improbabili, delle stringhe ricevute che distano in egual misura da due parole distinte. In questo caso il sistema è solo in grado di rilevare l’errore e non di correggerlo.

Ma la ridondanza non viene solamente utilizzata per rilevare e correggere errori. Anche le prestazioni di un programma possono beneficiarne. Supponiamo ad esempio una classe Triangolo che mantiene al suo interno informazioni sui tre angoli interni dello stesso. Notiamo subito che potremmo operare in due modi: creare tre attributi che mantengono i tre angoli, oppure mantenere solo 2 angoli e ricavare il 3° tramite una funzione. Se scegliamo di inserire il terzo angolo inseriamo una ridondanza. Se abbiamo un triangolo con due angoli di 45°sappiamo automaticamente che il terzo dovrà essere di 90°. Facendo così risparmieremo sì spazio ma renderemo la classe triangolo più onerosa dal punto di vista della CPU.

Questa cosa è sempre vera, anche nel caso della rilevazione dell’errore. Quando scegliamo di utilizzare la ridondanza scegliamo di sacrificare lo spazio per guadagnare tempo. E’ questa la grande coperta dell’informatica: dobbiamo sempre saper scegliere se il sacrificio di spazio dia guadagni in tempo significativi o, viceversa, se risparmiare spazio non faccia perdere troppo tempo.

E’ un concetto sottile ma essenziale per progettare sistemi ad alta efficenza e soprattutto adatti all’ambiente che vogliamo utilizzare.

In questi giorni è trapelata la notizia che il protocollo SSL è afflitto da una vulnerabilità che permetterebbe attacchi di tipo man in the middle. Ma cos’è l’attacco man in the middle? Semplice.

L’attacco man in the middle, chiamato anche semplicemente MIM, è un tipo di attacco che affligge per lo più i protocolli a chiave pubblica. L’attacco MIM è un attacco parecchio insidioso in quanto permette all’attaccante di leggere, inserire o modificare a piacere i messaggi tra due host in modo tale che nessuno dei due si renda conto che il collegamento è compromesso.

Vediamo come funziona. Supponiamo che le divinità nordiche, negli ultimi anni, si siano modernizzate e abbiano il loro bel profilo su Facebook o su Gmail. Supponiamo che Aegir, il creatore della birra, voglia comunicare con Baldr, dio della giustizia. Supponiamo poi che l’astuto Loki voglia spiare la conversazione e consegnare a Baldr dei messaggi mendaci.

I passi con cui si sviluppa l’attacco sono i seguenti:

• Per iniziare la comunicazione, Aegir deve chiedere a Baldr la sua chiave pubblica.
• Baldr invia la sua chiave pubblica ad Aegir
• Loki a questo punto si finge Baldr agli occhi di Aegir e riceve così la sua chiave pubblica.
• A questo punto Loki ha la chiave di Aegir. Si finge quindi Aegir agli occhi di Baldr.
• Loki invia a Baldr la sua chiave pubblica spacciandola per quella di Aegis.
• Inoltre Loki invia ad Aegir la sua chiave pubblica spacciandola per quella di Baldr.

A questo punto è lampante che Loki si trova al centro fra le comunicazioni senza che nessuno dei due comunicanti si sia accorto dell’inganno. Ma vediamo come procede la truffa.

• Aegir, credendo di avere la chiave pubblica di Bob, cifra i suoi messaggi con la chiave di Loki.
• Aegir invia i messaggi cifrati al Baldr (che in realtà è Loki)
• Loki è in grado di decifrare questi messaggi, ne tiene una copia e li re-cifra con la chiave pubblica di Baldr.
• Loki invia il messaggio a Baldr.
• Baldr riceve il messaggio e crede che provenga da Aegir.

E così via. Loki ripete le stesse operazioni a parti invertite quando sarà Baldr a inviare un messaggio.

Questo tipo di attacchi può essere eseguito su qualunque flusso di dati venga scambiato su protocolli a chiave pubblica.

COME OVVIARE IL PROBLEMA?

L’attacco è neutralizzato dalla presenza di chiavi certificate. Queste chiavi, garantite da un organo terzo di garanzia, assicura che nessuno possa spacciare una chiave per un altra. Loki non sarebbe stato in grado di spacciare la sua chiave per la chiave di Baldr.

PERCHÈ QUESTA VULNERABILITÀ ALLORA?

La vulnerabilità scoperta sta in un protocollo di rinegoziazione in cui le due parti si riscambiano certificati e chiavi. Secondo questa vulnerabilità un attaccante di tipo MIM potrebbe far certificare la sua chiave.

COME OVVIARE ALLA VULNERABILITÀ?

La soluzione è ancora in discussione. Per il momento tutti i principali software che usano SSL hanno disattivato la possibilità di rinegoziare la connessione.

Questa mattina mi sono svegliato con una mezza idea. Avevo bisogno di scrivere un programmino in Scheme che fosse un minimo didattico così da dare del buon materiale a chi segue la mia guida. Inoltre pensavo a un “simulatore di brute forcing” per dare una valutazione approssimata della robustezza delle mie password. Così ho scritto questo piccolissimo script che unisce le due cose.

Per valutare la robustezza di una password sono indicative due cose:

• La lunghezza. Ovvero il numero di caratteri che la compone.
• Il set di caratteri. Ovvero quali insiemi di caratteri utilizza (maiuscole, minuscole, numeri, etc…)

Le due cose non hanno la stessa importanza: la variare la lunghezza fa variare la complessità del brute-forcing esponenzialmente, variare il set fa variare la complessità polinomialmente. Questo ci indica che usare un set di caratteri molto ampio è tanto più efficace quanto più la password è corta. Per password immense in teoria basta anche un set di caratteri ristretto. Tuttavia è bene avere entrambe le cose più grandi possibile.

Il programmino che ho fatto fa due cose molto semplici. Per prima cosa vi chiede di inserire la password fra virgolette “”. Dopodiché ricava il set dei caratteri utilizzato e fa due prove:

• Un bruteforcing seriale. Ovvero suppone che ci sia un solo computer ad eseguire la forzatura.
• Un bruteforcing distribuito. Ovvero suppone che un worm sfrutti un “esercito” di computer zombie per eseguire il bruteforcing in parallelo.

I dati su cui si basano i test sono molto ottimistici (dal punto di vista della password, in realtà potrebbe volerci molto meno) e basati sulla velocità di ricerca di un software di bruteforcing attivo su un quad-core.

Ad esempio proviamo a vedere quanto regge una password tipo “19051987″ ovvero la classica “data di nascita”.

Ottimisticamente un software di bruteforcing impiega solo 17 minuti. Oppure proviamo il semplice nome:

Come vedete sono tutte e due password farlocche. Questo senza contare che i moderni software di brute-forcing attingono anche a parole “comuni” diminuendo di almeno un fattore 100 il tempo necessario!! (ad esempio la password “admin” viene beccata in qualche millisecondo).

Ora per curiosità vi posto il risultato della mia password (ovviamente senza che vi dica quale sia xD)

Direi che posso stare relativamente tranquillo!

Ecco il download comprensivo del sorgente. Dal sorgente potete variare i parametri (come il numero di chiavi analizzate al secondo) a piacimento per adattarli a casi particolari.

SCARICA IL FILE

DynDNS, servizio di DNS Dinamici

Continuiamo la nostra piccola guida a puntate per configurare il nostro PC in un affidabile server FTP.

Nell’articolo precedente avevamo istruito il nostro router ad aggiornare automaticamente DynDNS con il vostro IP ogni volta che vi viene cambiato in modo da avere un indirizzo nominale sempre collegato al vostro PC.

Ora non ci resta che istallare il server ftp sulla macchina locale e sistemare le ultime configurazioni.

2. Installare il server FTP

L’istallazione è veramente semplice come tutte le istallazioni su sistemi Debian-based. Aprite il terminale o il vostro gestore pacchetti preferito e installate VSFTPD, sigla che sta per Very Secure FTP Demon.

apt-get install vsftpd

Il nostro server è già bello installato e funzionante.

Per la versione di Debian avevo riscontrato una configurazione che mi piaceva poco. Quindi assicuratevi che all’interno del file /etc/vsftpd.conf siano presenti le seguenti righe:

# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES

Altrimenti di default vengono abilitati soltanto gli accessi anonimi mentre io vorrei che ogni utente locale accedesse alla propia home. Inoltre ho abilitato i comandi di scrittura perchè voglio anche uploadare documenti da remoto, ma se a voi non serve mettete un bel NO.

Per maggiori informazioni sulle altre configurazioni vi rimando a guide ad hoc.

Se avete modificato il file, infine, riavviate il demone con:

/etc/init.d/vsftpd restart

Ora dobbiamo provarlo. Prendete Firefox, inserite nella barra degli indirizzi ftp://localhost/, inserite nome e password del vostro utente locale e, se tutto funziona, vi apparirà la lista dei file della vostra home.

3. Il Port Forwarding

Ora avete un server FTP sulla vostra rete locale. Vorremmo però che il server FTP sia esteso al resto di internet. Ci ricorderemo però che dall’esterno è visibile solo il nostro router e non il nostro PC!

Rimediamo subito.

Innanzitutto è necessario che il nostro PC ottenga ad ogni avvio sempre lo stesso indirizzo IP privato dal router. Per fare questo bastano 3 righe nei file di configurazione in /etc/network/interfaces

Solitamente vi connettete con l’interfaccia eth0, nella descrizione di questa interfaccia, al posto della riga in cui compare DHCP inserite:

address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1

Dove address è l’indirizzo IP che volete (assicuratevi che non ci siano altri PC che vogliano o possano prendere questo indirizzo), gateway è l’indirizzo del router (quello con cui accedete alla configurazione, e netmask è sempre 255.255.255.0 (salvo strane apparecchiature o se avete una LAN con più di 253 computer).

Ora dovreste riavviare il router per far si che prendiate proprio l’indirizzo specificato.

Ora andate alla configurazione del router. Andate alla pagina del Virtual Server (Advanced Setup -> NAT -> Virtual Server) e configurate come in figura.

Configurazioni di un Virtual Server

A questo punto il gioco è fatto. Il server è funzionante. Per provarlo però dovete accedere con un PC fuori dalla LAN o con servizi di anonimato perchè il router riconosce se l’ip proviene dalla LAN e fa un po di storie.

DynDNS, servizio di DNS Dinamici

Rieccomi qui dopo un 30 a Modelli e un 30 e lode a Fisica (vantiamoci finchè possiamo xD). Per festeggiare, invece di Pub e Cinema come ho sempre fatto, questa volta passerò una mezz’oretta a spiegarvi come trasformare il vostro PC, o qualche mondezzone inutilizzato in un pratico e comodo server FTP accessibile da ogni parte del mondo.

In realtà preferirei molto fare Pub e Cinema, ma non ho trovato nessuno disponibile e la mia ragazza abita a 70Km… quindi ritenetevi fortunati.

Tornando in tema, per fare ciò ci occorre semplicemente una connessione flat a internet (ovviamente), un router che supporta i DNS Dinamici e, per ultimo ma non per importanza, il nostro sistema operativo.

Io utilizzerò nella guida un modem-router Trust MD-4050 e il sistema operativo Debian Testing. Per quanto riguarda il router non ci sono grandi differenze, variano le immagini ma i passi rimangono quelli. Per chi invece avesse la sfortuna di usare Windows può continuare a leggere tutto fino alla parte della configurazione del PC e di cercare una guida per impostare al proprio PC l’IP Locale statico. Penso che scriverò presto una guida al riguardo per Windows XP (mi spiace ma Vista/Seven non lo ho proprio a disposizione e non ci tengo ad averlo, però chi vuole può scrivere una guida al riguardo che sarò lieto di pubblicare).

Ma cominciamo subito.

1. Registrazione ad un servizio di DNS Dinamici.

Questa parte è molto semplice. Per prima cosa scegliamo un servizio di DNS Dinamici a piacere. Io uso e consiglio DynDNS per tre motivi: funziona, è gratis ed è quello che utilizzerò nella guida.

Seguite le istruzioni per registrare il vostro account. Una volta registrati accedete al vstro account e andate su Add Host Services. A questo punto non vi resta che scegliere il nome dell’indirizzo che punterà al vostro PC, ad esempio supernerd.dyndns.org e immettere il vostro IP attuale (niente paura, il sito riconosce da solo il vostro IP).

2. Configuare il router.

Ora che avete inserito il vostro nome e registrato il vostro dominio siete subito in grado di accedere al vostro pc. Provate a inserire il nome del vostro host nella barra indirizzi di Firefox e con buona probabilità vi salterà fuori la pagina di configurazione del vostro router.

Oibò! Giusto quello che ci serviva!

Infatti dobbiamo configurarlo per due motivi:

1. L’indirizzo IP che avete inserito in fase di registrazione non dura per sempre. La maggior parte dei provider (Wind, Alice, ecc…) fornisce al vostro computer un indirizzo IP diverso ogni volta che vi connettete (ogni volta che riavviate o spegnete il router o per svariate ragioni il maledetto si disconnette). Si parla in questo caso di IP Dinamico.
   A noi però interessa accedere al nostro PC sempre, anche se il modem si disconnette e riconnette accidentalmente mentre siamo via. Inoltre, anche se fossimo a casa, non sarebbe pratico andare ad aggiornare manualmente l’indirizzo. Dobbiamo quindi istruire il router ad aggiornare automaticamente l’IP di DynDNS.
2. La pagina di configuarazione del nostro router è si interessante e magari anche piacevole da vedere, ma a noi interessa comunicare col nostro PC, non con il router. Il problema che il nostro pg è invisibile all’esterno perchè (probabilmente) ci troviamo dietro una rete NAT. Dobbiamo quindi dire al nostro router di passare al nostro pc tutte le connessioni sulla porta 20 e 21 in ingresso.Questo si fa grazie al port forwarding.

Fare questo non è difficile.

Per prima cosa accediamo alla configurazione del router all’indirizzo 192.168.1.1 (oppure 198.168.0.1 oppure 198.168.1.254).

La schermata di Access Manager

Andate in Acces Management e poi in DDNS. Potete vedere come appare nell’immagine qui sopra.

Riempite questi campi con le informazioni del vostro Host e del vostro account DynDNS. L’opzione Wildcard support va impostata su Yes solo se quando avete creato l’host avete scelto di usare nomi per l’host del tipo *.supernerd.dyndns.org ovvero se volete che il vostro server sia raggiungibile da www.supernerd.dyndns.org, ppp.supernerd.dyndns.org e via dicendo.

Una volta salvato avete sistemato il primo problema. Dobbiamo quindi occuparci del secondo, ma prima di fare ciò dobbiamo istallare il server ftp. Cosa che vedremo nel prossimo articolo.