Ricerca personalizzata

domenica 25 settembre 2011

Pacchetti applicativi confezionati appositamente per le distribuzioni GNU/Linux.

Ogni distribuzione GNU/Linux utilizza un metodo per il confezionamento dei pacchetti (blocchi) che compongono l'intero sistema. Il problema principale è quello di tenere traccia della collocazione dei file di ogni applicazione, delle sue dipendenze da altri pacchetti e di permetterne l'aggiornamento o l'eliminazione senza danneggiare il sistema e senza lasciare file ignoti inutilizzati.

La distribuzione GNU/Linux particolare può avere un'attenzione differente rispetto alla preparazione e alla gestione del sistema che si occupa di installare e disinstallare questi pacchetti. È il caso di citare la distribuzione Debian, a questo proposito, in cui tale sistema è particolarmente complesso. Naturalmente, una gestione troppo semplificata dei pacchetti di applicativi è un incentivo all'utilizzo della distribuzione per un principiante, ma poi tutto questo si traduce in gravi difficoltà nel momento in cui si vuole aggiornare la distribuzione, o semplicemente si desidera fare qualcosa di più rispetto al solito.

Distinguere tra «pacchetti» e «archivi».

Per evitare di fare confusione, sarebbe bene distinguere tra «il pacchetto», che rappresenta un componente installato, da installare, o da eliminare dal sistema, rispetto al suo contenitore, ovvero «l'archivio». Per esempio, si può dire che l'archivio make_3.77-4.deb contenga il pacchetto make nella versione 3.77-4.

Purtroppo, questa distinzione non viene utilizzata da tutti; ci sono distribuzioni in cui si parla indifferentemente di «pacchetto» per fare riferimento all'archivio che lo contiene e a ciò che si ottiene installandolo. Questa anomalia, poi, la si riscontra anche nelle sigle usate nelle opzioni della riga di comando, dove potrebbe capitare che si utilizzi la lettera «p» (package) per fare riferimento ai file degli archivi.

Binari e sorgenti.

Gran parte del software distribuito con i sistemi GNU/Linux è sottoposto alla licenza GNU-GPL (GNU general public license, sezione 402), che impone la disponibilità dei sorgenti. Per questo motivo, una distribuzione GNU/Linux, oltre a organizzare i pacchetti compilati e archiviati opportunamente, quando richiesto dalla licenza, deve mettere a disposizione i sorgenti, assieme alle modifiche eventuali, generalmente in forma di file di differenze. Si distingue così tra pacchetti binari (archiviati in qualche modo) e pacchetti sorgenti.

Il pacchetto binario si compone dei file già compilati e pronti per essere collocati dove previsto. Il pacchetto sorgente è qualcosa di diverso: contiene l'archivio originale dell'applicativo (quello dei sorgenti), assieme a tutte le informazioni necessarie per modificarlo e per compilarlo nel modo più appropriato per la distribuzione GNU/Linux in cui deve essere installato. Inoltre, dovrebbe contenere le informazioni necessarie a generare il pacchetto binario relativo.

In generale, quando si parla di «pacchetti», si fa riferimento implicitamente a quelli contenenti i binari, o comunque i file finali da installare.

Interdipendenza tra i pacchetti.

I pacchetti, ovvero i vari blocchi in cui è suddiviso il software, devono convivere in modo armonico nel sistema. Questo fatto sembra ovvio, ma la cosa più difficile da definire è proprio la relazione corretta tra questi.

Con il termine «dipendenza», si fa riferimento al fatto che un pacchetto può dipendere da altri per il suo funzionamento. In pratica, se il pacchetto «A» richiede che sia presente anche il pacchetto «B», si dice che «A» dipende da «B». Con il termine «incompatibilità», si fa riferimento al fatto che un pacchetto non può coesistere con un altro per qualche ragione. Per esempio, se il pacchetto «A» non può stare assieme a «C» si dice che «A» è incompatibile con «C».

I due concetti sono abbastanza semplici, ma a questi se ne aggiunge un altro: la dipendenza prima dell'installazione. Infatti, un pacchetto potrebbe dipendere da un altro che deve essere già presente prima che questo venga installato. A questo proposito, si parla a volte di «pre-dipendenza». Questo tipo di dipendenza impone quindi un ordine nell'installazione dei pacchetti.

In certi casi, un pacchetto può dipendere da una funzionalità che può essere offerta da diversi altri pacchetti. Per esempio, un programma può richiedere la presenza del comando mail per inviare dei messaggi; più in generale questo dipenderebbe dalla funzionalità di invio della posta elettronica. Nel caso della distribuzione Debian, si parla di «pacchetti virtuali», per fare riferimento a queste funzionalità generiche da cui possono dipendere altri pacchetti (reali).

Fasi dell'installazione e della disinstallazione di un pacchetto.

Da quanto esposto, si possono intuire alcune delle fasi riferite all'installazione e alla disinstallazione di un pacchetto:

prima dell'installazione occorre verificare che siano rispettate le dipendenze e che non ci siano incompatibilità;

prima della disinstallazione occorre verificare che non ci siano altri pacchetti che rimangono installati e dipendono da quello che si vuole eliminare.

Ma i problemi non si limitano a questi. Infatti, un pacchetto che si installa può richiedere la predisposizione di qualcosa, come dei collegamenti simbolici, dei file di dispositivo nella directory /dev/ e dei file di configurazione. In generale, gli archivi dei pacchetti utilizzati dalle distribuzioni GNU/Linux contengono degli script realizzati specificatamente per questo, cioè per sistemare le cose in fase di installazione e anche quando si disinstalla un pacchetto. Volendo si può arrivare a distinguere tra quattro script corrispondenti ad altrettante fasi:

uno script da eseguire prima dell'estrazione dell'archivio contenente il pacchetto da installare;

uno script da eseguire dopo l'estrazione dell'archivio contenente il pacchetto da installare;

uno script da eseguire prima della cancellazione dei file che compongono un pacchetto da disinstallare;

uno script da eseguire dopo la cancellazione dei file che compongono un pacchetto da disinstallare.

Naturalmente, dipende dalle caratteristiche di un pacchetto il fatto che siano necessari o meno questi script. In generale, la configurazione rappresenta un problema particolare, che viene affrontato in maniera differente dalle varie distribuzioni GNU/Linux.

Configurazione di un pacchetto.

Per poter utilizzare un pacchetto, oltre all'installazione può essere necessaria la sua configurazione. La configurazione può richiedere di fatto la creazione o la modifica di un file di testo, secondo una sintassi determinata, oppure l'interazione con un programma apposito (che si occupa di fare le domande necessarie e di memorizzare le risposte nel modo più opportuno). I file che contengono le informazioni sulla configurazione di un pacchetto, fanno parte del pacchetto stesso e sono candidati per la cancellazione nel momento in cui si decide di disinstallarlo. Tuttavia, il sistema di gestione dei pacchetti potrebbe distinguere opportunamente il caso in cui si vuole disinstallare un pacchetto conservando però i file di configurazione, rispetto al caso in cui si vuole eliminare tutto senza porsi problemi di alcun tipo.

A parte il dettaglio importante relativo al fatto di trattare in modo distinto i file di configurazione nel momento della disinstallazione, le distribuzioni GNU/Linux possono distinguersi in modo notevole in base alla gestione della configurazione stessa. In pratica si potrebbero avere due estremi:

definire una configurazione minima e indispensabile prima di iniziare una nuova installazione della distribuzione GNU/Linux, lasciando che il resto venga fatto dall'utilizzatore quando vuole, dopo che l'installazione è terminata;

definire la configurazione mano a mano che i pacchetti vengono installati.

Nel primo caso, la procedura di installazione si limiterebbe a chiedere le informazioni indispensabili per il completamento della stessa (i dischi, le partizioni, la tastiera, eventualmente la rete, ecc.); successivamente verrebbero installati i pacchetti senza disturbare più l'utilizzatore, che alla fine deve configurare per conto proprio i servizi che gli interessano.

Nel secondo caso, ogni volta che si installa un pacchetto che richiede una configurazione (indipendentemente dal fatto che si tratti della prima installazione della distribuzione o che si tratti di un lavoro fatto in seguito), gli script che lo corredano interrogano l'utilizzatore su come configurare, almeno in modo grossolano, ciò che serve.

Tra i due estremi ci sono delle situazioni intermedie, nelle quali si possono fissare alcune informazioni che tornano utili ai pacchetti più importanti, già in fase di prima installazione, in modo da alleggerire il carico di notizie da fornire nel momento della configurazione finale legata all'installazione del singolo pacchetto.

L'esempio tipico di una distribuzione GNU/Linux in cui la configurazione avviene mano a mano che i pacchetti vengono installati è quello della Debian. Quando si installa un pacchetto nuovo in un sistema GNU/Linux già funzionante, il fatto che durante l'installazione vengano richieste (eventualmente) le informazioni necessarie a dargli una configurazione minima, è sicuramente un fatto positivo. Tuttavia, quando l'utente inesperto tenta di installare per la prima volta questa distribuzione dopo avere selezionato una grande quantità di pacchetti, questo si trova disorientato di fronte alla quantità di cose che devono essere configurate e che non aveva previsto, oltre all'eccessiva quantità di tempo necessaria per completare l'installazione.

Da quanto scritto si intuisce che: di fronte a una distribuzione GNU/Linux organizzata in modo da gestire la configurazione dei pacchetti mano a mano che questi vengono installati, è indispensabile, in fase di prima installazione del sistema, iniziare con la selezione del minimo possibile, riservandosi di aggiungere ciò che manca in un momento successivo.
 
Caratteristiche di un pacchetto nei confronti di un sistema funzionante.

Un sistema sofisticato di gestione dei pacchetti di una distribuzione GNU/Linux, potrebbe non limitarsi a riportare il fatto che un pacchetto sia installato o meno, dando qualche informazione in più. Un pacchetto potrebbe essere:

non installato;

installato (correttamente);

non installato, ma con i file di configurazione ancora presenti (in pratica, è stato installato e successivamente disinstallato senza eliminare i file di configurazione);

installato in parte (l'archivio è stato estratto, ma gli script necessari al completamento della procedura hanno rilevato un qualche tipo di errore, per cui il pacchetto potrebbe non essere operativo).

Aggiornamento.

L'aggiornamento di un pacchetto implica la sostituzione di quello installato con uno di una versione più aggiornata. Si tratta di un problema comune, tuttavia pone dei problemi importanti. Un aggiornamento, perché non vada a danno di chi lo fa, dovrebbe preservare la sua configurazione precedente. In pratica, se il pacchetto «A» utilizza il file di configurazione /etc/A.conf, è bene che questo file non venga sovrascritto, o almeno venga conservato in qualche modo.

La politica delle distribuzioni GNU/Linux può essere varia:

i file di configurazione potrebbero essere sostituiti senza salvare quelli precedenti;

i file di configurazione potrebbero essere sostituiti salvandone una copia a cui viene data un'estensione particolare;

i file di configurazione potrebbero non essere sostituiti, affiancando eventualmente la nuova versione standard di questi file con un'estensione particolare.

Tanto per fare un esempio pratico, la distribuzione Red Hat salva i file di configurazione precedenti utilizzando l'estensione .rpmorig, mentre la distribuzione Debian si limita a non sostituire i file vecchi, affiancando eventualmente una copia della configurazione nuova, distinguendola con l'aggiunta dell'estensione .dpkg-dist.

File di configurazione comuni.

Alcuni pacchetti potrebbero condividere uno stesso file di configurazione, oppure potrebbero dipenderne in qualche modo. Questo comporta dei problemi che non sono facili da risolvere in generale, tanto che si cerca di evitare il più possibile che questo debba succedere. Il caso più evidente di una tale dipendenza è quello dei file /etc/passwd e /etc/group, che potrebbero richiedere una modifica ogni volta che si installa un servizio particolare per il quale si deve definire un utente fittizio specifico, oppure un gruppo.

In questa situazione, l'installazione di un pacchetto può richiedere la modifica di un file di configurazione già esistente. Questo potrebbe avvenire per opera degli script che lo accompagnano, ma in tal caso, questi dovrebbero avere l'accortezza di salvare una copia della versione precedente di questo file. Di solito si notano estensioni del tipo .orig oppure .old. Al contrario, un'estensione del tipo .new suggerisce trattarsi di un file che dovrebbe essere usato in sostituzione di quello attuale, lasciando all'utilizzatore il compito di sostituirlo manualmente.

sabato 24 settembre 2011

Uso e configurazione di Secure Shell, protocollo di rete che permette di stabilire una sessione remota cifrata.

SSH (Secure SHell, shell sicura) è un protocollo di rete che permette di stabilire una sessione remota cifrata tramite interfaccia a riga di comando con un altro host di una rete informatica.

E' il protocollo che ha sostituito l'analogo ma insicuro Telnet.

Al giorno d'oggi la maggior parte delle comunicazioni su Internet avviene attraverso i protocolli della suite TCP/IP (POP, IMAP, SMTP, HTTP, X11, TELNET), che però sono nati in un'epoca in cui la possibilità di scambiarsi dati era considerata più importante rispetto alla sicurezza degli stessi.

Come risultato Internet, la cui infrastruttura è proprio basata su TCP/IP, è un mezzo di comunicazione fondamentalmente insicuro. Caratteristica dei protocolli elencati è, infatti, che tutte le transazioni avvengono in chiaro; cioè se qualcuno ha il controllo di una macchina situata in un punto qualsiasi del percorso di comunicazione che connette due host, può spiare il traffico ed analizzarlo alla ricerca di informazioni riservate come passwords, numeri di carte di credito, comunicazioni personali. Nelle future versioni del protocollo IP uno scenario del genere non sarà più possibile perchè si avrà una codifica dei dati in maniera trasparente. Fino ad allora l'unico modo per difendersi è quello di utilizzare la crittografia.
La crittografia è la scienza che studia le comunicazioni sicure. Crittografare un messaggio significa trasformarlo da una forma intelligibile in una forma inintelligibile: ciò avviene attraverso opportuni algoritmi che operano una trasformazione sul messaggio originale utilizzando le cosiddette "chiavi", cioè sequenze di bit la cui lunghezza può essere variabile. Solo il possessore della chiave giusta può effettuare la trasformazione inversa e riportare il messaggio in una forma intelligibile. All' aumentare della lunghezza della chiave di codifica diventa più difficile, per chi non possiede la chiave giusta, risalire al messaggio originale partendo da quello codificato.
Gli algoritmi di crittografia si possono classificare in due famiglie: a chiave simmetrica e a chiave asimmetrica.
Gli algoritmi di crittografia a chiave simmetrica sono chiamati cosi' perchè utilizzano la stessa chiave sia per la codifica che per la decodifica di un messaggio. L'inconveniente fondamentale di questa famiglia di algoritmi deriva dalla necessità di mettere d'accordo gli interlocutori sulla chiave da utilizzare. Dato che per scambiarsi la chiave deve esserci necessariamente una forma di comunicazione tra gli interlocutori, bisogna fare in modo che questa non avvenga attraverso un mezzo insicuro come può essere il telefono o, peggio ancora, la rete stessa. Un modo sicuro potrebbe essere, ad esempio, un incontro di persona, ma tale soluzione non è sempre praticabile.
Questo genere di inconvenienti viene superato con la crittografia a chiave asimmetrica. Ogni interlocutore dispone di una coppia di chiavi: una chiave pubblica che, come dice il nome, può essere divulgata, e una chiave privata che invece va custodita e protetta adeguatamente mediante password. Le due chiavi sono legate matematicamente tra di loro e non è in alcun modo possibile, in una scala di tempi ragionevolmente utile, derivare l'una dall'altra. La peculiarità di questi algoritmi è che un messaggio codificato con una delle chiavi può essere decodificato solo ed esclusivamente utilizzando l'altra chiave.
Anche questo tipo di crittografia però introduce un inconveniente, cioè la necessità di essere sicuri che una determinata chiave pubblica appartenga proprio all'interlocutore col quale stiamo comunicando. La soluzione è quella di accertarsene personalmente o, nel caso non sia possibile, affidarsi a entità esterne, che possono essere persone o enti di provata fiducia, che certificano e garantiscono l'associazione tra una chiave pubblica e il suo possessore, sia questi una persona o un host, una volta che ne hanno accertato l'identità. In questo modo, chiunque si fidi dell'entità esterna può fidarsi anche delle chiavi pubbliche certificate da quest'ultima.

Secure Shell.

Ssh è un protocollo di comunicazione nato per rimpiazzare i comandi Berkeley r* (rsh, rlogin, rcp) e a differenza di questi fornisce una infrastruttura per connessioni crittografate nonchè autenticazione forte tra host e host e tra utente e host. Chiude inoltre alcuni noti problemi di sicurezza dei protocolli TCP/IP come l'IP spoofing (falsificazione dell'indirizzo IP del mittente), il DNS spoofing (falsificazione delle informazioni contenute nel DNS) e il routing spoofing (falsificazione delle rotte intraprese dai pacchetti e instradamento su percorsi diversi).
I comandi r* possono essere addirittura rimpiazzati dalle rispettive versioni sicure (ssh, slogin, scp) in maniera trasparente per l'utente.
Esistono due versioni del protocollo ssh: la versione 1, più vecchia, che da questo momento in poi chiameremo ssh1, e la versione 2, che chiameremo ssh2, chè è una completa riscrittura della vecchia versione ed è più sicura.
Un ruolo primario nello scenario di ssh ce l'hanno due società finlandesi, la SSH Communications Security (http://www.ssh.org), che ha sviluppato i protocolli ssh1 e ssh2 e che mantiene le distribuzioni principali di ssh, e la Data Fellows (http://www.datafellows.com), che ha acquistato dalla prima la licenza di vendere e supportare ssh.
In particolare la Data Fellows ha imposto i limiti di utilizzo per il software: ssh1 può essere utilizzato liberamente a patto che non se ne ricavi guadagno; ssh2 invece può essere utilizzato liberamente solo privatamente o in ambito educational.
Tuttavia i protocolli ssh1 e ssh2 sono pubblicati come Internet Drafts e ci sono alcuni progetti che si occupano di scriverne una implementazione free: OpenSSH (http://www.openssh.com), nato per far parte del sistema operativo OpenBSD, implementa il protocollo ssh1 utilizzando solo algoritmi di crittografia non patentati, cioè senza restrizioni di utilizzo; OSSH (ftp://ftp.pdc.kth.se/pub/krypto/ossh/), che implementa il protocollo ssh1; lsh (http://www.net.lut.ac.uk/psst/), che implementa il protocollo ssh2.
Tutti i prodotti qui descritti sono sviluppati al di fuori degli U.S.A.: in questa nazione infatti vigono alcune leggi che impongono delle restrizioni sulla esportazione di prodotti che implementano crittografia forte; tali prodotti sono trattati dalle leggi alla stregua di armamenti militari e non possono utilizzare chiavi con lunghezza superiore ad un certo numero di bit, dipendente dall'algoritmo.

Come funziona ssh.

Le informazioni di seguito riguardano ssh1, la versione 1 del protocollo.
Ogni host su cui è installato ssh possiede una coppia di chiavi RSA (un algoritmo di crittografia a chiave asimmetrica) lunghe 1024 bit, una pubblica ed una privata. In più, ogni utente che utilizza ssh può opzionalmente generare una propria coppia di chiavi RSA.
All'atto della connessione, il server comunica al client due chiavi pubbliche: una fissa di 1024 bit che è la vera e propria chiave dell'host e l'altra di 768 bit che viene rigenerata ogni ora. Il client allora genera una sequenza casuale di 256 bit e la codifica con le chiavi pubbliche del server. Da questo momento in poi la connessione viene crittografata con uno degli algoritmi a chiave simmetrica supportati da ssh (IDEA, DES, 3DES, Arcfour, Blowfish) e si passa alla fase di autenticazione.
Ssh può autenticare un utente in vari modi:
  • RhostsAuthentication:


questo metodo si basa sulla normale autenticazione dei comandi r*: se il nome dell'host client è inserito all'interno del file /etc/hosts.equiv sul server allora ad un utente è concesso il login senza password a patto che abbia uno username sul server uguale a quello sul client; analogamente è concesso il login senza password se la coppia "client username/client host" è inserita all'interno del file $HOME/.rhosts sul server (dove $HOME è la home directory dell'utente sul server).
Questo è il metodo di autenticazione meno sicuro, in quanto è suscettibile ai problemi di sicurezza descritti all'inizio ed in una installazione di default è disabilitato.
I file coinvolti in questo tipo di autenticazione sono i seguenti:
CLIENT
Nessuno
SERVER
/etc/hosts.equiv
$HOME/.rhosts

  • RhostsRSAAuthentication:


questo è il metodo principale di autenticazione. Si basa fondamentalmente sulla RhostsAuthentication, ma l'identità dell'host client viene accertata attraverso la sua chiave pubblica RSA: il server possiede una copia della chiave pubblica degli host autorizzati alla connessione all'interno del file /etc/ssh_known_hosts ed inoltre ogni utente può crearsi una propria lista personalizzata di chiavi pubbliche utilizzando il file $HOME/.ssh/known_hosts, nella sua home directory sul server. Una volta accertata l'identità dell'host client la connessione viene autorizzata e il login viene effettuato con le modalità della RhostsAuthentication. Alternativamente ai file /etc/hosts.equiv e $HOME/.rhosts sul server si possono utilizzare i file /etc/shosts.equiv e $HOME/.shosts, di formato identico; in questo modo ci si svincola completamente da qualsiasi legame con i vecchi comandi r* e non si incorre nei loro problemi di security.
I file coinvolti in questo tipo di autenticazione sono i seguenti:
CLIENT
/etc/ssh_known_hosts
$HOME/.ssh/known_hosts

SERVER
/etc/ssh_known_hosts
$HOME/.ssh/known_hosts
/etc/hosts.equiv
/etc/shosts.equiv
$HOME/.rhosts
$HOME/.shosts

  • RSAAuthentication:


questo tipo di autenticazione si basa sulla sola crittografia a chiave asimmetrica e presuppone che l'utente possegga una coppia di chiavi RSA. Se la chiave pubblica dell'utente è inserita nel file $HOME/.ssh/authorized_keys sul server, il server stesso genera una sequenza casuale di bit, la codifica con la chiave pubblica dell'utente e spedisce il tutto al client; il client decodifica con la chiave privata dell'utente la sequenza di bit e la rispedisce al server codificandola con le chiavi pubbliche del server. Cosi' facendo il client dimostra di conoscere la chiave privata, autenticandosi col server. Con questo tipo di autenticazione è richiesto all'utente di inserire la password che sblocca la sua chiave privata.
I file coinvolti in questo tipo di autenticazione sono i seguenti:
CLIENT
/etc/ssh_known_hosts
$HOME/.ssh/known_hosts
$HOME/.ssh/identity.pub
$HOME/.ssh/identity

SERVER
$HOME/.ssh/authorized_keys

Se un utente vuole utilizzare tale forma di autenticazione, è necessario che distribuisca la propria chiave pubblica a tutti i server ai quali vuole connettersi, in pratica copiando il contenuto del file $HOME/.ssh/identity.pub, presente all'interno della sua home directory sul client, all'interno del file $HOME/.ssh/authorized_keys sugli host server.
  • TISAuthentication:
Questo tipo di autenticazione richiede la presenza di un server di autenticazione TIS: il server ssh cercherà di autenticare l'utente interagendo con il server di autenticazione TIS, agendo da tramite tra quest'ultimo e l'utente. Se l'utente viene autenticato dal server TIS, il server ssh concede l'accesso.
  • Password:


Quando i metodi di cui sopra falliscono, all'utente viene chiesto di inserire la password del suo account sul server: da notare che la comunicazione sta comunque avvenendo in maniera crittografata.
Caratteristica interessante di ssh è la possibilità di effettuare una codifica di qualsiasi tipo di connessione, creando cosi' un canale di comunicazione crittografato tra client e server sul quale veicolare la connessione vera e propria. Questa caratteristica è chiamata port forwarding.
Nel caso del protocollo X11 ssh ne effettua in maniera automatica la codifica, a patto che dal lato client sia definita la variabile di ambiente DISPLAY: in questo caso, sul server al quale ci si è connessi, viene creato un X server fittizio e la variabile DISPLAY viene modificata in modo tale da puntare ad esso. Questo X server si occuperà in realtà solo di inoltrare i dati sul canale di comunicazione sicuro creato da ssh, che poi provvederà a passare i dati decodificati all'X server reale.

Prestazioni

Come è facile intuire, una comunicazione attraverso ssh avviene più lentamente rispetto ad una comunicazione non crittografata. La velocità della comunicazione dipende dall'algoritmo di crittografia utilizzato. Nel file README.CIPHERS, presente nella distribuzione standard di ssh, vengono elencate le prestazioni di ogni singolo algoritmo rispetto all'algoritmo "None" (nessuna crittografia) che viene quindi fissato come riferimento.
Abbiamo testato ssh su sessioni X11. Tale protocollo, per sua natura molto pesante, risente maggiormente di una lentezza della comunicazione rispetto, ad esempio, ad una sessione interattiva a caratteri o ad un trasferimento passivo di files.
Entrambi i test effettuati sono consistiti nella riproduzione di una serie di filmati attraverso il programma xanim versione 2.80.0 (http://xanim.va.pubnix.com).
Il primo test è consistito nel calcolo del tempo impiegato nella riproduzione di 3 filmati in formato AVI e 1 in formato MOV; ogni serie di filmati è stata riprodotta 5 volte e poi è stata calcolata una media dei tempi, il tutto per ogni algoritmo di crittografia supportato da ssh. Lo scopo è stato quello di verificare le prestazioni dei vari algoritmi di crittografia a chiave simmetrica.
Le macchine utilizzate per il test sono le seguenti, cosi' configurate:
ws1
Modello: Alphastation 255
CPU: Alpha 21064 a 233 Mhz
RAM: 128 MB
Interfaccia di rete: Fast Ethernet, 100 Mbit/s
S.O.: Digital Unix 4.0D
Versione ssh: 1.2.27

ws2
Modello: Alphaserver 1000 4/200
CPU: Alpha 21064 a 150 Mhz
RAM: 192 MB
Interfaccia di rete: FDDI su fibra ottica, 100 Mbit/s
S.O.: Digital Unix 4.0D
Versione ssh: 1.2.27

Il test è stato effettuato due volte, una utilizzando ws1 sia come client che come server e l'altra utilizzando ws1 come client e ws2 come server.
I dati rilevati sono riassunti nella seguente tabella:


Protocollo Client Server Tempo 1 Tempo 2 Tempo 3 Tempo 4 Tempo 5 Media %
Telnet ws1 ws1 03:54 03:52 03:53 03:53 03:53 03:53 135%
Ssh/None ws1 ws1 05:13 05:18 05:13 05:27 05:07 05:15 100%
Ssh/IDEA ws1 ws1 07:31 07:27 07:24 07:44 06:11 07:15 72%
Ssh/DES ws1 ws1 06:44 06:56 07:12 06:58 06:50 06:56 76%
Ssh/3DES ws1 ws1 09:45 10:23 10:11 11:07 10:26 10:22 51%
Ssh/Arcfour ws1 ws1 06:07 06:08 06:32 06:15 05:19 06:04 87%
Ssh/Blowfish ws1 ws1 06:10 06:07 06:10 06:15 06:59 06:20 83%
Telnet ws1 ws2 08:18 08:20 08:12 08:53 08:55 08:32 131%
Ssh/None ws1 ws2 09:18 10:08 11:59 10:47 13:44 11:11 100%
Ssh/IDEA ws1 ws2 17:52 16:47 15:07 19:18 18:00 17:24 64%
Ssh/DES ws1 ws2 19:50 19:36 17:51 15:00 16:13 17:42 63%
Ssh/3DES ws1 ws2 29:18 30:00 40:09 28:31 41:53 33:58 33%
Ssh/Arcfour ws1 ws2 12:28 12:19 14:48 12:36 10:25 12:31 89%
Ssh/Blowfish ws1 ws2 13:38 13:02 14:28 13:41 16:46 14:19 78%

Analogamente a quanto descritto nel file README.CIPHERS della distribuzione, abbiamo preso come riferimento l'algoritmo "None" assegnandogli una percentuale del 100%. Si può notare come le prestazioni di ssh in tale modalità siano inferiori rispetto ad una tradizionale connessione telnet.
A titolo comparativo, riportiamo i valori di performance cosi' come compaiono nel file README.CIPHERS:
None: 100%
IDEA: 64%
DES: 71%
3DES: 45%
Arcfour: 91%
Blowfish: 88%

Il secondo test è consistito nella riproduzione del solo filmato in formato MOV, 5 volte e col calcolo della media dei tempi , utilizzando l'algoritmo di crittografia IDEA e variando i parametri di compressione della trasmissione, possibilità offerta da ssh. Lo scopo è stato quello di verificare l'effettiva convenienza dell'utilizzo della compressione nel caso di connessioni su WAN.
Le macchine utilizzate per il test sono le seguenti, cosi' configurate:
ws1 (Bari)
Modello: Alphastation 255
CPU: Alpha 21064 a 233 Mhz
RAM: 128 MB
Interfaccia di rete: Fast Ethernet, 100 Mbit/s
S.O.: Digital Unix 4.0D
Versione ssh: 1.2.27

pc1 (Firenze)
Modello: Personal Computer
CPU: Pentium II 450 Mhz
RAM: 512 MB
Interfaccia di rete: Fast Ethernet, 100 Mbit/s
S.O.: FreeBSD 3.4
Versione ssh: 1.2.27

I dati rilevati sono riassunti nella seguente tabella:


Compressione Client Server Tempo 1 Tempo 2 Tempo 3 Tempo 4 Tempo 5 Media %
None ws1 pc1 15:53 15:53 15:54 15:43 15:28 15:46 100%
Fast (1) ws1 pc1 11:55 11:19 12:06 10:55 10:45 11:24 138%
Slow (9) ws1 pc1 14:34 14:13 14:17 14:14 14:01 14:16 111%

Abbiamo considerato come riferimento il comportamento di default di ssh, cioè nessuna compressione della trasmissione. Dalla tabella risulta che, almeno per quanto riguarda le connessioni su WAN, conviene in ogni caso abilitare la compressione. Il consiglio è quello di abilitarla, specialmente nel caso di trasmissioni utilizzanti una banda limitata.

 Installazione e configurazione

Scaricare la distribuzione di ssh da ftp://ftp.cs.hut.fi/pub/ssh/
Per quanto riguarda ssh1 l'ultima versione al momento disponibile è la 1.2.27 mentre per ssh2 l'ultima versione è la 2.0.13. In ogni caso, dopo aver scaricato il file, per eseguire l'installazione è di norma sufficiente dare i seguenti comandi:
      $  ./configure
      $  make
      $  su
      $  make install
ssh si compila senza problemi su una grande varietà di piattaforme. Una volta installato si deve fare in modo che il processo sshd parta automaticamente ad ogni bootstrap: questa fase richiede la modifica degli script di partenza e dipende ovviamente dal sistema operativo.
Da notare che sebbene gli algoritmi di crittografia a chiave simmetrica supportati da ssh siano sei (IDEA, DES, 3DES, Arcfour, Blowfish, None), alcuni di questi non sono abilitati in una installazione di default: DES perchè al giorno d'oggi non è ritenuto sicuro a causa della non sufficiente lunghezza della chiave utilizzata (56 bit); Arcfour perchè ha dei problemi di implementazione in ssh1, corretti però in ssh2; None perchè implementa una trasmissione non crittografata e dovrebbe essere usato solo per motivi di debugging o test.
Durante l'installazione viene generata anche la coppia di chiavi RSA per l'host.
Sebbene sia possibile definire già nel file di configurazione di sshd un elenco di hosts o domini abilitati alla connessione, è possibile compilare ssh con il supporto per i TCP Wrappers (ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz) di Wietse Wenema in modo tale che il controllo di accesso venga fatto utilizzando i files /etc/hosts.allow e /etc/hosts.deny: basta dare al comando configure il parametro --with-libwrap.
Per fare in modo che i vecchi comandi rsh, rcp e rlogin siano sostituiti dalle rispettive versioni sicure in maniera trasparente, bisogna compilare ssh dando al comando configure il parametro --with-rsh=<path>, dove <path> è una directory nella quale vanno copiati gli eseguibili rsh, rcp e rlogin; dopodichè ssh, slogin e scp vanno copiati al posto di rsh, rlogin e rcp, quindi rinominandoli. Inoltre va copiata la chiave pubblica dell'host, /etc/ssh_host_key.pub, all'interno del file /etc/ssh_known_hosts sui server ai quali ci si vuole collegare. Se su di un server remoto non è installato ssh, il client locale eseguirà il vecchio comando r* prendendolo dalla directory specificata all'atto della compilazione.

Uso.
ssh-keygen
Questo comando serve per la generazione di una coppia di chiavi RSA, delle quali è possibile scegliere la lunghezza in bit. Il comando viene utilizzato per generare la coppia di chiavi per l'host e per generare le chiavi degli utenti.
La sintassi è la seguente, con i flags più comuni:

      $   ssh-keygen -b 1024 -N 'password'

Dove:
-b   specifica la lunghezza in bit delle chiavi;
"password" serve per proteggere la chiave privata.


ssh, slogin

Questi sono i comandi per l'accesso ad un server remoto. slogin è in realtà un link simbolico all'eseguibile ssh.
La sintassi è la seguente, con i flags più comuni:
      $   ssh [-vxC] [-l username] [-c cipher] host [comando]
Dove:
-v   abilita la modalità "verbose", utile per debugging;
-x   disabilita il forward automatico delle connessioni X11;
-C   abilita la compressione;
-l   specifica lo username da utilizzare sul server, nel caso sia diverso dallo username locale;
-c   serve per scegliere l'algoritmo di crittografia a chiave simmetrica da utilizzare per la connessione;
"comando"   è un comando da eseguire sul server.



scp

Questo comando serve per trasferire files da locale a remoto o viceversa in maniera sicura.
La sintassi è la seguente, con i flags più comuni:
      $   scp [-vrC] [-c cipher] [[user@]host1:]file1 [[user@host2:]file2
Dove:
-v abilita la modalità "verbose";
-r   copia un intero sottoalbero;
-C   abilita la compressione;
-c   serve per scegliere l'algoritmo di crittografia a chiave simmetrica da utilizzare per la connessione;



ssh-agent, ssh-add

Questi comandi servono per mantenere in memoria le chiavi private dell'utente in maniera da evitargli di digitare la password per sbloccarle ogni volta che si collega ad un server mediante RSAAuthentication.
La sintassi è:
      $   ssh-agent [comando]
Dove "comando" è di solito una shell oppure uno script di inizializzazione di una sessione X11. ssh-agent va a questo punto in background ed è pronto ad accettare le chiavi, fornitegli attraverso il comando:
      $   ssh-add [file]
Dove "file" è il nome del file contenente la chiave privata. Viene chiesta la password per sbloccarla, dopodichè ssh-agent si occuperà automaticamente di utilizzarla in maniera automatica per le connessioni con autenticazione RSAAuthentication.


Port forwarding

Come già detto, il port forwarding permette di creare un canale di comunicazione sicuro attraverso il quale veicolare qualsiasi conenssione TCP. Il suo funzionamento può essere spiegato attraverso un esempio.
Immaginiamo il seguente scenario:



Host A è separato dalla intranet da una rete insicura e deve comunicare via telnet con Host C. Host B permette connessioni ssh.
Con il port forwarding di ssh viene creato il canale sicuro tra Host A e Host B, mentre la connessione telnet vera e propria viene effettuata tra Host B e Host C.
Con il seguente comando, dato su Host A:
       hostA>   ssh   -L   1111:HostC:23   HostB   sleep   100
viene allocata la porta TCP 1111 su Host A attraverso la quale, passando per il canale sicuro, si arriva alla porta 23 (telnet) di Host C.
Per completare la connessione vera e propria bisogna effettuare un telnet a questa porta:
       hostA>   telnet   localhost   1111
Da notare che Host B e Host C possono coincidere.
L'esempio illustrato riguarda il forwarding di una porta dall'host locale verso un host remoto. E' possibile effettuare anche l'operazione inversa, ossia il forward di una porta remota attraverso l'host locale.

fonte: Cert Garr




Ricerca personalizzata

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

venerdì 23 settembre 2011

Lincity videogioco open source ispirato, ma con differenze radicali, a SimCity.

Lincity è un videogioco per personal computer open source, ispirato, ma con differenze radicali, a SimCity (del 1989).

Lincity è stato creato all'origine solamente per Linux e per sistemi Unix-like.

Ha una grafica complessa, in 2D, con visuale dall'alto.

L'ultimo aggiornamento (versione 2.0) risale 25/01/2009.

. Tutte le modifiche successive al 1999 sono considerate minori. Usa le SVGALib o X11 come interfaccia grafica API su sistemi Unix, con cambiamenti nelle varie piattaforme diverse da Unix.

Caratteristiche

In Lincity il giocatore prende il controllo della gestione di ogni aspetto dell'economia di una città. Una varietà di edifici possono essere costruiti. Tutte le strutture necessitano di soldi per essere costruite, ma poche possono essere pagate a rate senza danneggiare le casse della città per colpa degli interessi. La costruzione di case permette di creare lavoro nei vicini negozi, e il lavoro necessita di vie di trasporto (tramite strade o ferrovie). I lavori necessitano di strutture dove immagazzinare i materiali. Altre strutture complesse permettono di svolgere una varietà di compiti o possono produrre più di un prodotto. Alcune strutture necessitano sempre di elettricità, che, al contrario delle altre comodità del gioco, viene trasmessa attraverso linee elettriche.

Alcune strutture possono incrementare il livello tecnologico della città. Quando il livello tecnologico sale si possono costruire palazzi più avanzati. Quando la città è sufficientemente avanzata, verrà avviato un programma spaziale che può essere usato eventualemnte per evacuare la città e vincere il gioco.

Esiste un fork del gioco, Lincity-NG, che usa le SDL e OpenGL, e una grafica 3D isometrica, simile a SimCity 3000. Tuttavia, la giocabilità è identica e legge i salvataggi di lincity. Gira su Linux come piattaforma principale e supporta Windows, Mac OS X, BeOS, e gli altri sistemi Unix. Il binario Windows più i file di gioco di Lincity-NG è circa 40 MB, in confronto ai 800 KB dell'originale Lincity, diverso principalmente per grafica e suono.

Download.

Installazione.


 
Installare LinCity-NG da repository.
Per chi possiede Ubuntu e vuole provare a cimentarsi con LinCity-NG, c'è la possibilità di installare il tutto attraverso il sempre comodo terminale:

sudo apt-get install lincity-ng

Installare LinCity-NG da sorgenti.
Per installare LinCity-NG il primo passo è scaricare il pacchetto dei sorgenti di LinCity-NG v2.0. Possiamo scaricare il pacchetto .tar.bz2 da qui oppure possiamo dare un'occhiata alla pagina di download.
 
 
Installazione di LinCity-NG.
Dopo aver scaricato il pacchetto .tar.bz2 di LinCity-NG 2.0 e dopo averne estratto il contenuto occorre compilare i sorgenti. Qui c'è una piccola nota: questo progetto usa jam e non make per la compilazione, quindi occorre prima dotarsi di questo programma e poi iniziare la compilazione. Per compilare occorre lanciare il seguente trio nella cartella estratta dall'archivio .tar.bz2:

./configure
jam
sudo jam install

Per lanciare il gioco è sufficiente lanciare, da terminale, il comando:


lincity-ng

Si può anche installare (per le ultime versioni di Ubuntu) usando Ubuntu Software Center.
 
 




Ricerca personalizzata

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

martedì 20 settembre 2011

MonoDevelop è un ambiente di sviluppo (IDE) open source realizzato principalmente per C# e altri linguaggi .NET.

MonoDevelop è un ambiente di sviluppo (IDE) open source realizzato principalmente per C# e altri linguaggi .NET.

Originariamente era un "porting" di SharpDevelop (IDE open source per Microsoft Windows) su GTK#, ma successivamente si è sviluppato indipendentemente.

Tra le varie caratteristiche di MonoDevelop, il supporto allo sviluppo multipiattaforma (Linux, Windows e Mac OSX), l'ambiente di lavoro configurabile, il supporto a vari linguaggi (C#, Visual Basic, C/C++ e altri), debugger e IDE integrati e personalizzabili e il designer grafico per GTK+.

Giunto attualmente alla versione 2.6, MonoDevelop è un progetto in costante evoluzione e dotato ancora di scarsa documentazione, basata in effetti principalmente sulla collaborazione attiva degli utenti.

MonoDevelop fa parte del progetto Mono.

L'origine del progetto Mono.



Mono è un progetto nato nel 2001 ad opera di Miguel de Icaza (Ximian) e sponsorizzato da Novell (che nel frattempo ha acquisito Ximian).

Obiettivo del progetto è creare una implementazione Open Source degli standard ECMA per C# e per il Common Language Infrastructure.

Tali standard sono stati sottoposti all'approvazione dell'ECMA nell'Agosto del 2000 da un gruppo di aziende tra cui Microsoft, Hewlett-Packard e Intel Corporation.

Download.

Installare con Ubuntu Software Center:








Ricerca personalizzata

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

domenica 18 settembre 2011

Utilizzo dei colori nel web: la tabella HTML

Come un pittore sceglie con cura i colori della sua tavolozza, così il web designer deve, nei limiti del possibile,scegliere la "palette" di colori ideale per realizzare le sue creazioni artistiche. (Una palette di colori non è altro che un set, un insieme di colori.)

I colori in HTML si possono esprimere in due modi:

- in formato RGB (Red Green Blue);
- indicandone il nome (solo con Netscape e Internet Explorer).


Il primo è sicuramente il più flessibile ed è anche il metodo utilizzato da gran parte degli editor per le elaborazioni delle immagini.

Si basa sulla combinazione dei tre colori fondamentali Rosso, Verde e Blu per ottenere un qualsiasi colore nella gamma di quelli disponibili. 

A ciascuno di questi tre colori è possiblie assegnare un valore esadecimale compreso tra "00" e "FF" (corrispondenti a 0 e 255) combinandoli in modo da ottenere la tonalità desiderata.

Si ottengono in questo modo dei codici di sei cifre che vanno sempre preceduti dal simbolo # e compresi tra apici.

La seconda possibilità, non compatibile per tutti i browser, permette di indicare direttamente il colore desiderato (naturalmente in inglese).


Si riportano di seguito i codici esadecimali e i nomi dei 126 colori fondamentali riconosciuti da Netscape Navigator 2.0 (per poterli visualizzare la scheda grafica deve supportare almeno 256 colori).


 

"#A0CE00" "ALICEBLUE"
"#FAEBD7" "ANTIQUEWHITE"

"#00FFFF" "AQUA"
"#7FFFD4" "AQUAMARINE"

"#F0FFFF" "AZURE"
"#F5F5DC" "BEIGE"

"#FFE4C4" "BISQUE"
"#000000" "BLACK"

"#FFEBCD" "BLANCHEDALMOND"
"#0000FF" "BLUE"

"#8A2BE2" "BLUEVIOLET"
"#A52A2A" "BROWN"

"#DEB887" "BURLYWOOD"
"#5F9EA0" "CADETBLUE"

"#7FFF00" "CHARTREUSE"
"#D2691E" "CHOCOLATE"

"#FF7F50" "CORAL"
"#6495ED" "CORNFLOWERBLUE"

"#FFF8DC" "CORNSILK"
"#DC143C" "CRIMSON"

"#00FFFF" "CYAN"
"#00008B" "DARKBLUE"

"#483D8B" "DARKSLATEBLUE"
"##008B8B" "DARKCYAN"

"#B8860B" "DARKGOLDENROD"
"#A9A9A9" "DARKGRAY"

"#FF1493" "DEEPPINK"
"#00BFFF" "DEEPSKYBLUE"

"##696969" "DIMGRAY"
"#1E90FF" "DODGERBLUE"

"#822222" "FIREBRICK"
"#FFFAF0" "FLORALWHITE"

"#228B22" "FORESTGREEN"
"#FF00FF" "FUCHSIA"

"#DCDCDC" "GAINSBORO"
"#F8F8FF" "GHOSTWHITE"

"#FFD700" "GOLD"
"#DAA520" "GOLDENROD"

"#808080" "GRAY"
"#008800" "GREEN"

"#ADFF2F" "GREENYELLOW"
"#F0FFF0" "HONEYDEW"

"#FF69B4" "HOTPINK"
"#CD5C5C" "INDIANRED"

"#4B0082" "INDIGO"
"#FFFFF0" "IVORY"

"#F0E68C" "KHAKY"
"#E6E6FA" "LAVENDER"

"#FFF0F5" "LAVENDERBLUSH"
"#FFFACD" "LEMONCHIFFON"

"#ADD8E6" "LIGHTBLUE"
"#F08080" "LIGHTCORAL"

"#E0FFFF" "LIGHTCYAN"
"#FAFAD2" "LIGHTGOLDENRODYELLOW"

"#90EE90" "LIGHTGREEN"
"#D3D3D3" "LIGHTGRAY"

"#FFB6C1" "LIGHTPINK"
"#FFA07A" "LIGHTSALMON"

"#20B2AA" "LIGHTSEAGREEN"
"#87CEFA" "LIGHTSKYBLUE"

"#778899" "LIGHTSLATEGRAY"
"#B0C4DE" "LIGHTSTEELBLUE"

"#FFFFE0" "LIGHTYELLOW"
"#00FF00" "LIME"

"#32CD32" "LIMEGREEN"
"#FAF0E6" "LINEN"

"#FF00FF" "MAGENTA"
"#800000" "MAROON"

"#66CDAA" "MEDIUMAQUAMARINE"
"#0000CD" "MEDIUMBLUE"

"#BA55D3" "MEDIUMMORCHID"
"#9370DB" "MEDIUMPURPLE"

"#3CB371" "MEDIUMSEAGREEN"
"#7B68EE" "MEDIUMSLATEBLUE"

"#00FA9A" "MEDIUMSPRINGGREEN"
"#48D1CC" "MEDIUMTORQUOISE"

"#C71585" "MEDIUMVIOLETRED"
"#191970" "MIDNIGHTBLUE"

"#F5FFFA" "MINTCREAM"
"#FFE4E1" "MISTYROSE"

"#FFDEAD" "NAVAJOWHITE"
"#000080" "NAVY"

"#FDF5E6" "OLDLACE"
"#808000" "OLIVE"

"#6B8E23" "OLIVEDRAB"
"#FFA500" "ORANGE"

"#FF4500" "ORANGERED"
"#DA70D6" "ORCHID"

"#EEE8AA" "PALEGOLDENROD"
"#98FB98" "PALEGREEN"

"#AFEEEE" "PALETURQUOISE"
"#DB7093" "PALEVIOLETRED"

"#FFEFD5" "PAPAYAWHIP"
"#FFDAB9" "PEACHPUFF"

"#CD853F" "PERU"
"#FFC0CB" "PINK"

"#DDA0DD" "PLUM"
"#B0E0E6" "POWDERBLUE"

"#800080" "PURPLE"
"#FF0000" "RED"

"#BC8F8F" "ROSYBROWN"
"#4169E1" "ROYALBLUE"

"#8B4513" "SADDLEBROWN"
"#FA8072" "SALMON"

"#F4A460" "SANDYBROWN"
"#2E8B57" "SEAGREEN"

"#FFF5EE" "SEASHELL"
"#A0522D" "SIENNA"

"#C0C0C0" "SILVER"
"#87CEEB" "SKYBLUE"

"#6A5ACD" "SLATEBLUE"
"#708090" "SLATEGRAY"

"#FFFAFA" "SNOW"
"#00FF7F" "SPRINGGREEN"

"#468284" "STEELBLUE"
"#D2B48C" "TAN"

"#008080" "TEAL"
"#D8BFD8" "THISTLE"

"#FF6347" "TOMATO"
"#40E0D0" "TURQUOISE"

"#EE82EE" "VIOLET"
"#F5DEB3" "WHEAT"

"#FFFFFF" "WHITE"
"#F5F5F5" "WHITESMOKE"

"#FFFF00" "YELLOW"
"#9ACD32" "YELLOWGREEN"

Oltre a questi colori fondamentali è possibile ottenere tantissime altre combinazioni.
Ad esempio per le diverse tonalità del blu si possono usare:


"#0000CC"

"#000088"

"#000055"

"#000022"
 
ma tutte le combinazioni possibili sono supportate solo da schede grafiche con 16M di colori.
 

Ricerca personalizzata

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:

Ultimi post pubblicati

RSVP (Raccomandati Se Vi Piacciono)

Mutui & Finanze on Line

Finaziamenti Image Banner 468 x 60_f

Flickr Photostream

Antipixels & Counters

iFeed WebShake – tecnologia Blogstreet - dove il blog è di casaVero Geek iwinuxfeed.altervista.org Add to Technorati Favorites ElencoSiti tutto blog Aggregatore Directory dei blog italiani Blog360gradi - L’aggregatore di notizie a 360°

 provenienti dal mondo dei blog! BlogItalia.it - La directory italiana dei blog Feed XML offerto da BlogItalia.it Sito preferito Il Bloggatore Italian Bloggers visitor stats Programming Blogs - Blog Catalog Blog Directory AddThis Social Bookmark Button Aggregato su SocialBlog Feedelissimo Yourpage live news aggregator Paperblog : le migliori informazioni in diretta dai blog Notizie Informatiche