Port Security e MAC Lockout, ovvero come aumentare la sicurezza partendo dallo switch

Gli switch sono indubbiamente uno degli strumenti meno sfruttati in una rete. Da quelle di medie dimensioni con qualche centinaio di host a quelle piccole, gli switch di una rete spesso sono visti come oggetti "Plug&Play" dove, al massimo, si configura un indirizzo IP (giusto per scrupolo).

Fortunatamente non sempre è così e molti amministratori di rete invece utilizzano delle funzionalità comode ed in alcuni casi irrinunciabili come ad esempio le VLAN 802.11q, il Link Aggregation Control Protocol (LACP) oppure il noto Rapid Spanning Tree Protocol (RSTP, tipicamente utile anche come "loop protection").

L'articolo di oggi andrà oltre, approfondendo quelle funzioni di sicurezza poco note, come il Port Security o il MAC Lockout.

Port Security

In sicurezza informatica, l'accesso fisico alle risorse è sempre stato uno dei problemi cardine. Dando per veritiera la nota affermazione che "la maggior parte degli incidenti di sicurezza avviene dall'interno della rete stessa, e non dall'esterno come spesso si tende a credere", uno dei problemi più frequenti è il controllare e gestire l'accesso fisico alle risorse. Nel caso di una sala CED, i sistemi sono tutto sommato semplici (controllo accessi, tastiera numerica, badge, etc..). Nel caso però di una presa RJ45, il discorso si complica.

Affrontando il problema da un punto di vista fisico, qualche vendor ha sviluppato delle patch con una speciale chiave in grado di bloccarle in posizione, rendendole inamovibili dal relativo frutto o dalla NIC. Da un punto di vista logico, invece, gli switch ci tornano estremamente comodi per via del loro naturale posizionamento in una rete.

Il Port Security viene sovente utilizzato nelle grandi aziende per evitare che siano introdotti apparati non autorizzati (notebook personali, etc..). Mediante il port security possiamo definire i MAC address abilitati ad accedere su ogni singola porta dello switch.

Cosa succede se un MAC non autorizzato accede alla porta? Si definisce un comportamento:

• Spegnere la porta (l'utente quindi chiamerà l'amministratore di rete lamentando un disservizio)
• Inviare una Trap all'amministratore di rete, ma lasciare la porta accesa
• Bloccare il MAC non autorizzato ma non spegnere la porta

Qualcuno potrà contestare il fatto che i MAC address sono modificabili, ma come ogni azione di sicurezza, essa agisce per livelli. Non tutti gli utenti sono in grado di fare un MAC Spoofing, e se lo scopo è quello di evitare l'inserimento del notebook privato (e se abbiamo deciso semplicemente di inviare un alert senza far seguire alcuna altra azione, affinchè l'amministratore approfondisca il problema di persona) con una ragionevole tranquillità possiamo reputare lo scopo raggiunto.

Learning e Uplink

Per evitare di inserire a mano tutti i MAC address su tutti gli switch, possiamo mettere lo stesso in learning, indicandogli di apprendere solamente il primo MAC address che vede sulla porta.

Attenzione agli uplink: i collegamenti tra switch ovviamente riportano sulla MAC Table di ogni uplink tutti i MAC address che si raggiungono passando dallo stesso. E' quindi buona norma disattivare il Port Security su ogni uplink e quantomeno gestirlo su tutti quei apparati che concentrano più host, come ad esempio gli Access Point.

MAC Lockout

Il MAC Lockout ci consente di bloccare il MAC address definitivamente, a livello di switch e non più di singola porta. E' facile intuirne le potenzialità unite ad uno script che propaghi queste informazioni su tutti gli switch dell'infrastruttura di rete.
Non tutti gli switch hanno la funzionalità di MAC Lockout, ad esempio per HP questa feature è riservata agli switch modulari blade o a fasce medio alte di apparati.

Qualche esempio

Poniamo di essere su uno switch HP Procurve e di voler abilitare la porta eth22 ad un solo mac address (magari perchè quella porta si trova in una vlan speciale e da controllare) ed in caso di abuso di voler istruire lo switch ad eseguire uno spegnimento della porta stessa:

port-security 22 learn-mode configured action send-disable mac-address 1a2b3c4d5e6f

Adesso immaginiamo di trovarci in uno scenario in cui, stando su uno switch blade completamente popolato con 8 moduli e 24 porte per modulo, non abbiamo alcuna voglia di inserire a mano 190 mac address:

port-security A1-H24 learn-mode limited-continuous address-limit 1 action send-alarm

Così facendo lo switch prenderà per buono il primo MAC che si collega. Al secondo ci invierà un alert  (secondo quanto configurato nella sezione delle trap) indicandoci che su una stessa porta si è collegata una seconda postazione (magari scollegando la prima oppure tramite un microswitch o un access point, ad esempio).




Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Blacklistare gli scanner applicativi che intervengono sui WebServer

Su ogni webserver pubblicato su internet, dal più piccolo al più gettonato, riceveremo costantemente scansioni alla ricerca di servizi aperti o vulnerabili.

Chiunque abbia mai prestato un minimo di attenzione ai log del proprio webserver, non potrà non aver notato richieste a phpmyadmin o a wp-login, anche se tali servizi in realtà non ci risultano nè esposti nè presenti.

Come da sempre è stato e come sarà (almeno fin quando ipv6 non entrerà a regime, rendendo le scansioni almeno un minimo più difficoltose per via dell'enorme quantità di indirizzi ip allocabili), la tendenza è quella di trovare server che espongano servizi vulnerabili per poi tentare una serie di preset di vulnerabilità note.

Una forma di prevenzione potrebbe essere quella di iniziare a leggere i log e blacklistare chi cerca palesemente servizi che in realtà non esponiamo. Banalmente tramite uno script in bash potremmo mandare in iptable l'ip sorgente (ammesso che questo sia davvero quello dell'attaccante) e magari anche geolocalizzarlo per farci un'idea generica della provenienza:

#!/bin/bash

SCANNER="FOCA\|DirBuster\|Morfeus strikes again"

SERVIZI="awstats.pl\|wrnnro1.html\|DirectDownload.jsp\|caspadmin\|php.exe\|how_to_login.html\wp-login.php\|w00tw00t.at\|phpmyadmin\|blog\|wordpress\|manager\|CFIDE\|admin\|horde\|vtigercrm\|pbx\|freepbx\|Cgi-Bin\|sqlweb\|sqladmin\|phppath\|PMA\|pma\|whois.raw\|sqlmanager\|.passwd\|typo3\|order\|phpMyAdmin\|websql\|phpmy-admin\|php-myadmin\|piranha\|xampp\|php-my-admin"

while true; do

   LINE=$( grep "$SCANNER\|$SERVIZI" /var/log/apache2/access_log | grep -v blacklistedip.log | tail -n 1 )

    if [ "$LINE" != "" ]; then 

        IP=$( echo $LINE | awk '{ print $1 }' );

        date +%c >>  blacklistedip.log;

        echo "IP Address: $IP" >>  blacklistedip.log;

        geoiplookup $IP >>  blacklistedip.log;

        iptables -A INPUT -s $IP -j DROP; 

    fi

sleep 30

done

Intendiamoci:

1. questo semplice script ha come scopo ultimo quello di dare un'idea: leggere, prestare attenzione e parsare i log. Può essere certamente affinato, migliorato, scritto in linguaggi più efficienti e più veloci. Non è intenzione di questo articolo trattare la sintassi o l'efficienza dello script;
2. geoip deve essere scaricato e mantenuto aggiornato con geoip fetch, altrimenti avremo informazioni poco attendibili; al tempo stesso vanno verificati anche i percorsi dei log e se apache è configurato per scrivere anche in error_log;
3. è opportuno creare dei meccanismi di whitelist, magari anteponendo in iptables classi e ip trust, onde evitare di essere blacklistati per errore;
4. i servizi e gli scanner vanno attentamente rivisti, se utilizziamo awstat, ad esempio, non sarà una buona idea blacklistarlo!

E' bene ricordare, inoltre, che

1. Questo tipo di operazione è solo la punta di un iceberg, mettere in sicurezza un webserver è un'operazione ben più articolata. Blacklistare gli scanner parsando i log è un "sofismo" accessorio, non certo alternativo a delle canoniche e tradizionali regole di sicurezza informatica. Se si espone phpmyadmin senza la dovuta attenzione, dedicarsi a parsare i log è l'ultimo dei problemi che l'amministratore di rete si deve porre.
2. Altri programmi fanno già questo tipo di analisi, come il noto scanlogd che, unito a fail2ban, potrebbe fornire un'alternativa più userfriendly del crearsi uno script ad hoc.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Crittografia quantistica e algoritmi matematicamente sicuri

Partiamo da un presupposto: ad oggi c'è un solo protocollo matematicamente sicuro, tutti gli altri si basano su problemi matematici irrisolti o la cui elaborazione è estremamente onerosa in termini di risorse, richiedendo un tempo di elaborazione irragionevole o simile a quello di un Brute Force Attack.

Detto questo, il protocollo matematicamente sicuro si chiama OTP (One Time Pad), ed è ormai quasi non più utilizzato se non per applicazioni specifiche. Ma come?? C'è un motivo.

Come funziona OTP

OTP è un algoritmo molto semplice.

Data una stringa da cifrare, data una chiave di pari valore, si effettua uno XOR. Il risultato derivante sarà una stringa apparentemente randomica, reversibile solo mediante la medesima chiave.

Lo XOR prevede che: 

1 XOR 1 restituisca 0

1 XOR 0 restituisca 1

0 XOR 1 restituisca 1

0 XOR 0 restituisca 0

Facciamo quindi un esempio:

Il dato è :                           1101101000100110

La chiave è :                      0111001001001011

La stringa risultante sarà:   1010100001101101

Quest'ultima è il dato che viaggia tra i due interlocutori, ossia il messaggio cifrato. Apparentemente è randomico e non reversibile se non con l'apposita chiave.

Proviamo a simulare cosa accade, quindi, quando il dato arriva al destinatario in possesso della chiave:

Stringa crittografata:    1010100001101101

La chiave:                    0111001001001011

Il dato originario:          1101101000100110

Proprio per via della sua semplicità e della sua "robustezza matematica", questo è l'unico algoritmo, ad oggi, ad essere stato dichiarato "matematicamente sicuro".

Perchè quindi non viene quasi più utilizzato?

Semplicemente perchè:

1. La chiave deve essere usata una sola volta, altrimenti diventa "relativamente facile" stabilire correlazioni tra più dati e la stringa crittografata, quindi, diviene sempre meno apparentemente randomica (ci sono casi storici e documentati di violazioni dovute, appunto, all'aver utilizzato di frequente la stessa chiave per più dati)
2. I due interlocutori devono essere in possesso della chiave; oltretutto tale algoritmo non prevede meccanismi di scambio chiave (è proprio durante lo scambio delle chiavi che si verifica un numero significativo di incidenti di sicurezza)
3. E' necessario fare molta attenzione alla randomicità della chiave. Il concetto di casualità informatica è molto relativo ed è uno dei nodi più complessi del problema (seed ricorrenti, pseudocasualità, etc..), per rendere sicuro OTP dobbiamo essere assolutamente certi della casualità della chiave.

Salvo applicazioni molto rare, quindi, risulta estremamente scomodo (o persino spesso insicuro) utilizzare l'algoritmo OTP. 

Cosa centra la crittografia quantistica?

La crittografia quantistica o QKD (Quantum Key Distribution) interviene esclusivamente nello scambio delle chiavi (il dato poi viaggia secondo mezzi tradizionali) e, grazie alle proprietà della meccanica quantistica (che non approfondiremo in questo articolo) abbiamo delle caratteristiche estremamente importanti ed alcune assolutamente uniche ed irraggiungibili mediante soluzioni attualmente in uso:

1. Le particelle elementari possono essere rilevate tramite metodi indiretti ed in ogni caso alterano inevitabilmente il comportamento delle stesse. Da questo ne deriva che qualsiasi attacco di tipo Man-In-The-Middle altererà inevitabilmente lo scambio delle chiavi, portando a conoscenza il mittente ed il destinatario di un tentativo di eavesdropping.
2. La meccanica quantistica genera e ci consente di avere un livello di casualità estremamente elevato, non è possibile, infatti, predire matematicamente la polarizzazione dei fotoni generati.

Questi due aspetti, uniti a quanto descritto nel protocollo OTP, rendono una trasmissione estremamente sicura.

Anche qui però abbiamo delle scomodità che è bene quantomeno accennare:

• La comunicazione quantistica può avvenire esclusivamente via fibra ottica o via etere tra due punti a vista
• C'è un margine di errore strumentale abbastanza elevato (intorno al 20%) e ci sono recenti risvolti per cui la misurazione potrebbe rientrare sotto questo margine d'errore, vanificando in parte la protezione contro Eavesdropping e Man-In-The-Middle. Tuttavia sono risvolti che dovrebbero tendere a scomparire con la realizzazione di macchine più precise, oltretutto ci sono meccanismi di "Riconciliazione" che correggono gli errori tra mittente e destinatario preservando il principio per cui un MITM rimane comunque riconoscibile
• Lo sviluppo è ancora acerbo, nonostante se ne parli fin dagli anni 80

L'argomento, estremamente interessante, ha suscitato l'attenzione di enti governativi. Il SECOQC è un ente finanziato dall'Unione Europea con lo scopo di sviluppare le tecnologie di crittografia quantistica al fine di rendere sicure le comunicazioni critiche (http://www.secoqc.net/html/project/).

Nel prossimo articolo approfondiremo quali sono i problemi matematici irrisolti a cui inizialmente si faceva riferimento.

Tunnel SSH, questi pericolosi sconosciuti

Chi gestisce un server linux non può non aver abilitato almeno una volta sshd. La shell, su molte installazioni (soprattutto se solo testuali), è spesso indispensabile.

Non ci soffermeremo in questo articolo sui dettagli della sicurezza di OpenSSH o se è corretto o meno esporre il servizio SSH con password o certificato. Lo scopo di questo articolo è richiamare l'attenzione sui tunnel SSH, spesso ignorati dagli EDP ma estremamente usati da chi intende compromettere un sistema linux.

Cos'è un tunnel SSH?

Che la si chiami "VPN SSL", "Binding SSH", "SSH Forwarding" o semplicemente "Tunnel SSH", poco cambia.  I tunnel SSH sono uno strumento potentissimo, in grado di farsi carico del traffico di una socket e trasportarla ove risiede il server SSH.

Proviamo a fare qualche esempio.

Dando per scontato che un client SSH esterno ad una rete possa collegarsi ad un server linux interno con il servizio SSH attivo, e che non vi siano altre porte aperte e accessibili, è possibile raggiungere qualsiasi host o servizio della rete interna.

Schematizziamo:

Cosa si evince da questo schema? Ok, che uso ancora Paint (e per la precisione ho persino scaricato Paint per MAC). Ma non era qui che volevo arrivare.

Presupponiamo che:

• Il server SSH accetti le tunnellizzazioni e sia in ascolto sulla porta di default 22/TCP, per semplicità diciamo che non c'è NAT e che il server ha due schede di rete in routing che consentono il forwarding dei pacchetti (ma questo è del tutto irrilevante, si tratta di una esemplificazione; l'importante è arrivare a stabilire una sessione SSH, che questa avvenga su un IP pubblico statico o mediante un Port Address Translation è del tutto indifferente)
• Il Firewall, locato virtualmente tra internet ed il server, consenta esclusivamente la connessione SSH e in nessun caso l'apertura di altre porte (a noi basta la 22/TCP)
• Sul PC vi sia il servizio Terminal Service (Remote Desktop Protocol) di Microsoft in ascolto (ma può essere qualsiasi altro servizio

semplicemente stabilendo una connessione come segue è possibile aprire un tunnel verso il desktop remoto del pc interno alla rete, senza che questo abbia alcun servizio pubblicato all'esterno:

ssh -L 3389:192.168.1.2:3389 utente@11.22.33.44

(ma è possibile farlo con qualsiasi client, dall'intramontabile Putty a SecureCRT)

dove: 

-L sta per "crea un tunnel SSH", 

il primo 3389 sta per "apri in localhost la porta 3389"

192.168.1.2:3389 sta per "termina il tunnel contattando l'host 192.168.1.2 sulla porta 3389"

ed il resto sono le credenziali del server ssh.

A questo punto basterà collegarsi (con qualsiasi client RDP) in localhost per entrare nel tunnel

Facciamo delle considerazioni:

• L'host (nel nostro caso 192.168.1.2) vede connessioni arrivare dal server 192.168.1.1, e non dal nosro ip pubblico (per risalire al reale mittente è necessario consultare i log del server ssh... e se questo è compromesso come minimo dei log non ce ne facciamo molto)
• Tutto il traffico all'interno del tunnel è crittografato (essendo, di fatto, traffico al pari di ssh)

Facciamo qualche esercizio

Se all'interno di un'azienda il cui server web linux semiabbandonato dove ci girano due paginette statiche e "tanto anche se succede qualcosa non c'è niente di importante" espone un server SSH  compromesso (che consente tunnellizzazioni) cosa succede?

Tutto ciò che può succedere quando c'è un hacker seduto alla scrivania accanto alla nostra con il suo bel notebook collegato sulla stessa rete del server compromesso. 

Sostanzialmente, il server compromesso diventa il ponte tra la rete interna e l'attaccante, superando le canoniche policy di firewalling che isolano il mondo esterno da quello interno.

Ancora un esercizio:

ssh -L 8800:192.168.1.99:80 utente@11.22.33.44

Se 192.168.1.99 è il riservatissimo webserver Intranet degli ordini, categoricamente chiuso a qualsiasi accesso dal mondo esterno, ma terribilmente aperto dalla LAN ("perchè tanto lì ci sono solo i commerciali"), andando su http://127.0.0.1:8800 cosa vedrò?

Il riservatissimo webserver degli ordini.

E chi sono io?

Un tizio che viene dal mondo esterno.

Capite perchè è bene tenere a mente questo tipo di meccanismo?

Conclusioni e accorgimenti

Ci sono svariati modi per evitare spiacevolezze. 

• Non esporre, ove possibile, il servizio SSH. E se proprio non si può fare a meno di farlo, utilizzare il meccanismo dei certificati, più robusto della semplice password.

• Disabilitare, se possibile, la tunnellizzazione SSH nel file /etc/ssh/sshd_conf (o dove è locato il file di conf in base alla distro utilizzata). Salvo, ovviamente, che non la si usi esplicitamente.
• AllowTcpForwarding no
• X11Forwarding no

• Specificare chi può accedere e chi no, per evitare che tutti gli utenti con una shell possano gironzolare in ssh. E, perchè no, incrementare la verbosità dei log.
• AllowUsers pippo pluto
• DenyUsers topolino paperino
• LogLevel INFO

• Implementare meccanismi di fail2ban in grado di blacklistare ip che tentano attacchi di tipo bruteforce (http://www.fail2ban.org/)

• Separare i server pubblici da quelli privati, creando una DMZ tramite firewall perimetrali e, ove necessario, VLAN sugli switch (se i server pubblici rimangono confinati in una zona "intermedia" che non ha accesso alle risorse private di LAN, i danni possono essere significativamente contenuti)

• Trattare i server pubblici come host "ostili" e non come host di LAN. Spesso le regole di firewalling che interessano i server pubblici sono troppo morbide (o semplicemente comode). Le policy di firewalling non devono solo gestire le transazioni tra internet ed il server pubblico, ma anche tra il server pubblico ed il resto della rete! Questo è un errore estremamente ricorrente: fidarsi di un server pubblico (seppur proprio e nella propria rete) è spesso un ottimo modo per rovinarsi qualche giornata.

E' bene, inoltre, ricordare che in genere le tunnellizzazioni SSH sono abilitate di default su moltissime distribuzioni linux.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Storage Cloud: privacy e alternative a Dropbox & co.

Lo storage in cloud è comodo, questo non lo si può negare. Ma raramente la comodità si abbina alla sicurezza. Analizziamo in dettaglio i pro ed i contro di queste splendide ma pericolose soluzioni.

Il funzionamento

Come ormai tutti sanno, è possibile iscriversi ad un servizio di storage in cloud per avere a disposizione uno spazio. Questo viene poi ridistribuito tra i devices, siano essi mobili o classici poco importa. Modificando, eliminando o creando un file su uno dei devices, l'agent provvederà a propagare la variazione a tutti gli altri dispositivi non appena questi avranno a disposizione una connessione ad internet. I file risiedono sui server di chi ci offre il servizio e sono disponibili anche tramite una comoda interfaccia web. 

I conflitti tra file vengono gestiti dall'agent che cerca di risolverli, ove possibile, oppure creare un duplicato specificando il motivo del conflitto (accade quando due periferiche modificano lo stesso file pur essendo offline, nel momento in cui si connettono ad internet è impossibile stabilire chi abbia diritto a mantenere la sua copia del file sullo spazio comune).

Gli attori

• In principio fu Dropbox, eroga di default 2Gb estendibile, come tutti, a pagamento. La sua idea innovativa fu subito imitata. Consente l'utilizzo della strong authentication mediante doppio passaggio password/sms.
• Microsoft ha il suo SkyDrive, con 7Gb di spazio ed una gestione ben fatta dell'agent. Incredibilmente non compatibile con Windows XP, a differenza di tutti gli altri.
• Google con GoogleDrive, come al solito, ha strafatto con i suoi 15Gb, anch'essa consente la strong authentication con password/SMS oppure password/google_authenticator (un'app android con 6 caratteri numerici a rinnovo continuo, come nelle chiavette hardware con display)

Citiamo per completezza anche

• iCloud di Apple
• MEGA con i suoi 50Gb ma solo su web (https://mega.co.nz/)

Privacy

Possiamo e possono dire ciò che desiderano, decantando innumerevoli features di sicurezza avanzata, ma sta di fatto che i nostri file stanno anche lì, sui loro server. Questo ci potrebbe esporre, come minimo, a due problematiche:

1. La compromissione di un account comporta inevitabilmente l'esposizione dei dati in esso contenuti. Che questo accada per una falla di sicurezza (come accaduto a Dropbox almeno una volta) o per incuria dell'utente (credenziali non robuste o donate al mondo per errore) poco importa: i nostri dati sono in giro.
2. La raccolta di informazioni da parte di chi eroga servizi in cloud è, purtroppo, troppo spesso la prassi (https://www.google.com/settings/dashboard?hl=it, per dirne una seppur autorizzata). Nonostante la profilazione sia del tutto illegale in Italia, è indubbio che la raccolta dati sia il core business di molti colossi del web. Non dimentichiamoci che le pubblicità che vediamo sono contestuali, e fare delle ricerche su dove passare le nostre vacanze comporterà inevitabilmente per mesi delle pubblicità di splendide mete esotiche. No. Se ancora ve lo state chiedendo, non è un caso.

Come risolvere?

Dipende da ciò che dobbiamo fare. Se la necessità è quella di avere a portata di mano la musica, in caso di account compromesso non potranno che ascoltarsi i Pink Floyd con noi, rendendoci al massimo inconsapevoli DJ e creatori di più o meno gradevoli Playlist. Ma se l'esigenza inizia a diventare aziendale, con agenti sempre in giro e che chiedono all'EDP la stessa versatilità di GoogleDrive sui propri dati personali... allora le cose si complicano.

Di sicuro potrebbe essere utile pensare a servizi che integrano nativamente la Strong Authentication, elevando il grado di sicurezza. Ma questo non risolve il secondo punto (ed in realtà nemmeno completamente il primo).

Quindi potremmo crittografare i file (si spera con una password diversa da quella dell'account e di almeno una dozzina di caratteri) mediante appositi software come il sempreverde Axcrypt scaricabile qui. Ma poi i nostri utenti potrebbero lamentarsi della scomodità di dover crittografare e decrittografare ogni file (poche come come la pigrizia minano la sicurezza informatica). Oltretutto file voluminosi diventerebbero del tutto ingestibili.

Un'alternativa potrebbe essere una chiavetta USB hardware come iTwin SecureBox per Dropbox che crittografa tutto in maniera trasparente all'utilizzatore. Si ma i dispositivi mobili? E i costi? E per quanti device?

BitTorrent Sync

Ed eccoci arrivati alla diavoleria tanto attesa. Il famoso BitTorrent, sfruttando appunto l'algoritmo da cui prende il nome, permette di creare un personal cloud su di un proprio server. Tranquilli, i dati vengono condivisi solo con chi volete, trasferendo una stringa di autorizzazione che può essere abilitata in lettura, in lettura e scrittura oppure per un one time access (dopo il primo accesso la stringa diventa inutilizzabile).

Installando il client BitTorrent Sync (ancora in fase sperimentale ma ad ogni modo molto stabile http://labs.bittorrent.com/experiments/sync.html) è possibile condividere delle risorse (directory, file,..) pur mantenendoli su un proprio server. Le risorse rimangono sincronizzate fin quando almeno un dispositivo è connesso ad internet.

In fase di installazione BTSync chiede se abbiamo una chiave, semplificando le istruzioni da dare gli utilizzatori finali.

Per ogni device possiamo risalire alla quantità di dati inviati e ricevuti e revocarne l'accesso.

Ogni directory che decidiamo di condividere, ha le sue credenziali, che potremo dare ai nostri interlocutori.

I vantaggi sono innumerevoli:

• i dati risiedono sui nostri server, garantendoci un grado di privacy molto diverso da altri servizi in cloud
• lo spazio è teoricamente illimitato e soggetto esclusivamente all'hardware in nostro possesso
• è possibile revocare le stringhe di accesso (che posso generare per singolo device o utente)
• si presta molto bene a soluzioni tipo "agente commerciale in giro", perchè la gestione e la revoca delle stringhe è davvero ben fatta
• tutto il traffico tra client e server è crittografato

Di contro:

• non vi è un'interfaccia web (è un contro?)
• dobbiamo preoccuparci di mantenere online almeno una macchina se vogliamo un sincronismo efficace
• dobbiamo esporre pubblicamente un servizio su di un nostro server, pertanto l'utilizzo di una macchina dedicata (virtuale o fisica) locata in una DMZ è auspicabile.

Conclusioni

Non vi è un modo semplice e assolutamente sicuro per condividere dati, soprattutto con dispositivi mobili e postazioni remote. Ma è possibile scegliere quali dati e come condividerli per ridurre al minimo i rischi di questa operazione.

Se non è possibile strutturare un'infrastruttura con VPN IPSec o SSL (e questo sui dispositivi mobili spesso diventa complesso da fare), allora ci sono strumenti come BTSync che possono aiutarci.

Note

Con i servizi di storage su web, è importante tenere a mente che molti servizi erogano nativamente l'equivalente di "time machine" in MAC o le "shadow copy" di Microsoft, quindi l'eliminazione di un file sensibile va verificata. Con un servizio di "cronologia del dato" è semplice ripristinare quel file com'era N giorni prima dell'eliminazione. E questo a volte non è un bene.

Cos'è il bitcoin mining? Ci pagano davvero per fare elaborazioni?

Si, ma non vi illudete, la bolla speculativa è ormai alla frutta, salvo investire seriamente. Ma andiamo con ordine.

Cos'è il Bitcoin?

Il bitcoin è una moneta virtuale (ma nemmeno poi tanto) inventata da un certo Satoshi Nakamoto, attualmente irreperibile. Memorizzate questa informazione, perchè ne parleremo più avanti.

La struttura del bitcoin è molto particolare. La moneta virtuale, difatti, è distribuita tramite un software (chiamato appunto bitcoin) non gestito centralmente ma mediante dei "blocchi" distribuiti e crittografati che contengono l'elenco delle transazioni. Questo aspetto è molto importante, perchè nessuno può emettere nuovi bitcoin, pertanto la moneta non subisce i fenomeni classici di inflazione.

Ognuno può creare e possedere un portafoglio, scaricando il software qui http://bitcoin.org/en/download. Il download durerà parecchio tempo, tutti i blocchi occupano svariati Gb. E' importante effettuare un backup del proprio portafoglio e conservare questi dati in un luogo sicuro. Appena terminato il download, sarà possibile generare un stringa alfanumerica, sulla quale altri possessori di bitcoin possono effettuarci un pagamento.

E' davvero virtuale questa moneta?

Ni. E' una moneta virtuale e fuori dal controllo dei governi (non ci soffermeremo qui nei dettagli legali, a mio avviso comunque importanti per evitare l'esposizione a fenomeni di riciclaggio e comunque affrontati da testate accreditate come il sole 24 ore), ma molti enti trasformano bitcoin in euro o dollari (trattenendo una percentuale nemmeno poi così esosa). E comunque molti negozi, tra cui Amazon, accettano anche bitcoin. Quindi trasformare in soldi veri questa valuta diventa molto facile in ogni caso.

E' bene tenere a mente, però, che per questa valuta virtuale non vi è alcun grado di protezione. Chi entra nel nostro portafoglio virtuale può fare transazioni irreversibili e non contestabili.

Inoltre questa valuta è estremamente volubile, nella stessa giornata può prendere o perdere anche il 20% rispetto al dollaro e all'euro, rendendo tutto il mercato un azzardo allo stato puro. Ad oggi, gli ultimi 60 giorni si presentano così:

Come mi procuro bitcoin?

Qui viene il bello. I bitcoin posso riceverli da altri utenti oppure "minarli". Proprio così, come ben spiegato dalla simpatica pubblicità di bitcoin, possiamo minare i bitcoin come un minatore si procura metalli e risorse da una miniera. La miniera sono degli hash da risolvere, i minatori siamo noi e i picconi sono la nostra capacità elaborativa.

Più elaboriamo, più guadagnamo. L'unità di misura è il Mh/s (Mega hash al secondo). Ad oggi, 17 giugno 2013, 100 Mh/s ci fanno guadagnare 0,19 euro/gg. Con grado di difficulty 19339258 e conversione di 1 bitcoin a 74 euro circa (ma questi due fattori li approfondiamo più in avanti).

Un interessante sito dove procurarsi l'andamento della valuta virtuale lo si può trovare qui: http://cryptocur.com/exchanges/bitcoin-euro-exchange-rate/

I numeri

Parliamo di numeri (prezzi aggiornati ad oggi!):

- Elaborare con una CPU Xeon Quad Core 2,4Ghz ci fa fare circa 24Mh/s (0,05 euro/gg)

- una CPU i7 3Ghz circa 21 Mh/s (0,04 euro/gg)

- una scheda video Ati Radeon HD4850 fa 85 Mh/s (0,16 euro/gg)

- una scheda video Ati Radeon HD5870 fa 380 Mh/s (0,72 euro/gg)

Un elenco completo delle stime lo si può trovare qui: http://zoomq.qiniudn.com/ZQScrapBook/ZqFLOSS/data/20110526173742/

Vanno fatte delle considerazioni. Le CPU o le GPU lavorano al 100%, consumando molta corrente. Quindi già oggi elaborare con le CPU non ha più alcun senso, perchè tenere un i7 o uno Xeon al 100% costa in energia elettrica (e raffreddamento) certo più di quanto si guadagna.

I pool

I bitcoin vengono pagati in tranche da 25 o 50, un numero davvero difficile da raggiungere. Pertanto sono nati i pool che pagano anche 0.1 bitcoin (ad oggi circa 7,40 euro).

Uno dei più famosi e meglio strutturati è http://50btc.com, al suo interno è spiegato cosa e come minare per loro e come farsi pagare.

I grafici sono ben fatti e si ha sempre il controllo di ciò che si sta facendo:

Le tecnologie

Prima era: Il calcolo primordiale era fatto da CPU, assolutamente poco performanti. Attualmente del tutto inutile come indicato in precedenza.

Seconda era: Le schede grafiche elaborano molto più rapidamente, ma consumano molto.

Terza era: FPGA, cpu specializzate di prima generazione, performanti quanto una scheda video potente, costose uguali (spesso anche più) ma con consumi nell'ordine di un decimo (rendendo nuovamente conveniente l'investimento).

Quarta era: ASIC, cpu specializzate di seconda generazione, performanti 40 volte più di un FPGA e con consumo uguale a quest'ultima. Costi ridotti di un quarto. Una board di 16 ASIC in genere produce 4500Mh (producendo ora 8,47 euro/gg) e costa circa 220 euro consumando appena 35W circa.

Il grado di difficulty

Vanno tenute a mente due cose fondamentali. Fissate queste, possiamo fare delle considerazioni tutt'altro che banali.

1) Tutto il mercato del mining è associato al valore di difficulty. Tale valore esprime il coefficiente di difficoltà nel fare 1BT. Quindi se con un difficulty di 1000 serve 1h per fare 1BT con una data capacità elaborativa, con un difficulty di 2000 serviranno 2h a parità di capacità computazionale.

2) Il coefficiente di difficulty aumenta all'aumentare della capacità elaborativa. La capacità elaborativa è influenzata dal costo dell'hardware come investimento iniziale e dal suo consumo energetico. Il mercato è studiato per arrivare ad un punto di saturazione, ossia quando il consumo energetico andrà a pari con il guadagno e quindi non varrà più la pena investire in tal senso.

Tenendo bene a mente questi due fattori fondamentali, si possono facilmente fare delle previsioni estremamente oculate.

Cosa accade adesso?

La maggior parte dei miner utilizzano schede grafiche ed i più evoluti FPGA. A marzo sono iniziati ad uscire sul mercato i primissimi ASIC per pochissimi eletti (probabilmente 1/500 degli ordini fatti).

Ci sono ordini in coda anche da 1 anno e siamo agli sgoccioli con l'uscita di progetti open per utilizzare questi potentissimi (ma economicissimi, sia in termini di investimento sia in termini di consumo energetico) processori.

Cosa accadrà nel breve?

L'immissione a breve di una potenza di calcolo centinaia di volte maggiore farà schizzare il coefficiente di difficulty ad un valore che renderà del tutto inutile minare con schede video e difficoltoso minare anche con gli ASIC meno performanti.

Già oggi i primi ASIC usciti a marzo hanno pesantemente svalutato la capacità elaborativa, come viene evidenziato da questo storico tratto da 50btc.com:

Oltretutto ci sono in ordine diverse decine di macchine da 1,5Th (1500000Mh/s, qualora non si fosse capito). Quando entreranno in funzione queste "bestie", il mercato ridiventerà di nicchia escludendo tutti i miner sotto i 3-4Gh.

Dato il bassissimo consumo energetico degli ASIC, molti stanno investendo parecchi soldi.

Va detto però che una scheda video ha anche altri usi (e mercati), gli FPGA e gli ASIC sono utili solo a  "minare", e senza tale scopo diventano dei bei soprammobili o fermacarte.

Conclusioni: cosa conviene fare?

Conviene studiare attivamente i progetti di costruzione di macchine ASIC in autonomia (calcolando l'aumento esponenziale del grado di difficulty). Il progetto Klondike è il più famoso di quelli non commerciali (https://bitcointalk.org/index.php?topic=190731.0). Per chi volesse andare su soluzioni commerciali (in realtà anch'esse in fase embrionale) deve rivolgersi a Butterfly Labs (http://www.butterflylabs.com/) o Avalon direttamente (http://launch.avalon-asics.com/), ma entrambi stanno evadendo ora gli ordini di agosto 2011. Loro assicurano tempi di consegna di 3-4 mesi, ma non c'è da stupirsi se molti scettici ritengono giusto mettere in conto 1 anno di attesa.

E le schede video? Minare ORA con le GPU è possibile, a patto di non investire 1 solo euro (perchè entro 2-3 mesi saranno del tutto inutilizzabili per effetto dell'aumento esponenziale del grado di difficulty e dell'aumento dei continui costi energetici). Quindi: chi ha schede video potenti, che le usi ora. Chi non ne ha, non le acquisti perchè tanto non se le ripagherebbe.

Spero di aver riassunto al meglio il mondo dei bitcoin ai neofiti, costretti a girare qui e li per raccogliere documentazione spesso molto frammentata nella speranza di fare affari senza contare fattori come il grado di difficulty.
Nel prossimo articolo descriveremo la correlazione tra elaborazione e decrittografia. Chi paga per fare cosa?


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.