Come fare a...
Web
Come fare a...

Analisi forense di un sistema Linux

Analisi del sistema

Pagine: Pagina precedente 2 di 2
Autore: Andrea Ghirardini e Gabriele Faggioli - Tratto: Computer forensics - Apogeo

Analisi

L’analisi di un sistema GNU/Linux può essere una sfida per un computer forensics expert.
Da un lato il sistema fornisce tonnellate di informazioni in più rispetto a un sistema Windows. Esistono decine di log differenti che sono assolutamente prodighi di informazioni. Inoltre, il sistema è molto più standardizzato e ordinato di quanto ci si potrebbe aspettare rispetto all’anarchia di Windows.
Dall’altro lato la piena libertà di cui gode l’amministratore di sistema, compresa quella di ricompilare il kernel includendo le patch che maggiormente desidera, fa sì che, per esempio, un hack a kernel level possa diventare un incubo da gestire.
L’analisi deve quindi procedere per raffinazioni successive, per partire dagli elementi più semplici fino a scendere, nei casi peggiori, all’analisi dei sorgenti dello specifico kernel installato o al dump della RAM.

Log

Tutti i sistemi Unix (tra cui, quindi, GNU/Linux) utilizzano un sistema standard per la gestione del log. Questo sistema prende il nome di syslog. La stragrande maggioranza delle applicazioni (sia programmi aggiuntivi sia di sistema) utilizza syslog di default per la scrittura dei log.
Syslog si basa su un daemon (l’equivalente Unix di un servizio Windows) chiamato syslogd. Esso si incarica di effettuare il servizio di data collecting per l’intero sistema (o per più sistemi nel caso sia configurato per agire da log server). Una volta ricevuto un messaggio di log, syslogd segue le direttive contenute nel file di configurazione /etc/syslog.conf per decidere dove scrivere tale entry.
Le entry syslog sono gestire tramite due parametri con i quali il daemon può decidere cosa fare. Essi sono chiamati “facility” e “severity”. Questi parametri sono standard per tutti i sistemi Unix e sono definiti nella RFC 3164.
Per il parametro facility i valori ammessi sono quelli di tabella 4.

Codice Descrizione
0 Messaggio kernel
1 Messaggio da user-level
2 Sottosistema di mail
3 Daemon di sistema
4 Messaggio di security/autorizzazione
5 Messaggio generato internamente da syslog
6 Messaggio dallo spool di stampa
7 Messaggio dal sistema di network news
8 Sottosistema UUCP
9 Daemon funzionanti con il clock (cron/at)
10 Messaggio di security/autorizzazione
11 Daemon FTP
12 Daemon NTP
13 Log Audit
14 Log Alert
15 Clock daemon
16 Local0
17 Local1
18 Local2
19 Local3
20 Local4
21 Local5
22 Local6
23 Local7

Tabella 4: valori ammessi per il parametro facility

Ogni messaggio ha inoltre un livello di priorità (severity) compreso tra quelli di tabella 5.

Codice Descrizione
0 Emergency: sistema non utilizzabile.
1 Alert: si richiede una azione immediata.
2 Critical: condizione critica.
3 Errore: condizione di errore.
4 Warning: avviso.
5 Notice: notifica di un evento significativo.
6 Informational: nota informativa.
7 Debug: messaggio di debug.

Tabella 5: livelli di priorità

La maggior parte delle direttive nel file di configurazione di syslog sono basate su questi parametri. In base a questi le entry saranno salvate in file di log differenti.
Di norma i file di log si trovano nella directory /var/log. Il più significativo tra questi è sicuramente il file “messages” dove sono contenuti la maggior parte (tranne quelli del sottosistema di mail che sono l’eccezione più rilevante) degli eventi occorsi all’interno della macchina.
Vi si trovano infatti entry relative all’hardware collegato e scollegato, ai file system montati e smontati, agli eventi critici occorsi, a eventuali messaggi relativi all’autenticazione e molto altro.

Nota
Syslog è un sistema di logging di rete. Perciò, non è assolutamente scontato il fatto che i log risiedano necessariamente sul sistema che li ha generati. Molto spesso una misura precauzionale per evitare l’alterazione di log è proprio quella di utilizzare un log server separato, specialmente per quanto riguarda le macchine poste in luoghi dove potrebbero essere soggetti ad attacchi, come, per esempio, in DMZ. La configurazione di syslog evidenzierà in questo caso l’indirizzo del log server che riceverà i dati.

Syslog-ng
Syslog, come molti software nel mondo Unix, ha una veneranda età. Come tale, dimostra qualche inefficienza e qualche problema di sicurezza. In particolare, syslog spedisce i log in chiaro via UDP e non è molto duttile nella gestione della suddivisione degli eventi su più file di testo. Per ovviare a questi e ad altri problemi è stato introdotto syslog-ng. Molte distribuzioni Linux usano di default syslog-ng al posto di syslog. Syslog-ng migliora nettamente la parte di filtering, permette l’utilizzo di canali TCP per la spedizione dei log, l’uso di macro all’interno del file di configurazione, una gestione intelligente delle timezone, e altre caratteristiche avanzate che lo rendono un rimpiazzo consigliato a syslog per tutte le piattaforme che lo supportano.

L’unico log presente sui sistemi Unix (quindi anche su Linux) che non sia un file di testo è il file wtmp.Tale file, conservato dal sistema in formato binario, è quello che logga gli accessi (avvenuti con successo) di coloro che hanno utilizzato il sistema.
È visibile con un opportuno decoder o con il comando Unix last che legge il file wtmp dal suo inizio e stampa a video la lista degli utenti che si sono collegati, la provenienza e il lasso temporale nel quale sono stati all’interno del sistema.
Si ricorda che tutti i log presenti in un sistema Linux sono comunemente ruotati. Questi significa che un apposito comando, logrotate, si incarica periodicamente di eseguire una archiviazione dei log e una reinizializzazione degli stessi. Il comportamento del programma logrotate è descritto in un opportuno file di configurazione contenuto nella directory /etc.
Si ricorda, infine, che non tutti i programmi utilizzano syslog per effettuare il log. Alcuni processi agiscono per conto proprio salvando i file direttamente. Tra questi possiamo ricordare, per esempio, Apache o Samba. Nel caso si voglia essere sicuri di aver trovato tutti i file di log conservati all’interno del sistema è possibile usare il programma logfinder, in grado di esaminare il file system alla ricerca di file di log.

Configurazione del sistema

Linux, come tutti i sistemi Unix, è configurabile tramite un solo unico programma, un editor di testo. Non per nulla tutti gli hard core Unix sys-admin sono soliti dire che il miglior programma di system administration di tutti i tempi sia vi, in una delle sue molteplici incarnazioni.
Tutte le configurazioni sono contenute all’interno della directory /etc e sono sparpagliate in una serie di file di testo. Se questo può spaventare i neofiti, costretti a rinunciare a una comoda GUI di configurazione (anche se esistono dei programmi che agiscono da wrapper alla complessità di configurazione via file di testo, come webmin o yast), sicuramente aiuta sia il sistemista, che può variare il comportamento del sistema con pochi semplici comandi.
Anche l’analisi forense è avvantaggiata da questa struttura in quanto è possibile verificare lo stato di configurazione del sistema con alcuni semplici programmi di ricerca come find o grep.
Di norma ogni singolo componente del sistema, sia esso un sottosistema del kernel (come lo stack TCP/IP) o un programma (come il web server Apache), salvano le loro configurazioni in un file nella directory /etc o in una sottocartella al suo interno. Inoltre, i nomi file sono descrittivi, nella maggior parte dei casi, quindi non è difficile individuare il file corretto tra le decine di quelli presenti. Per esempio, il file di configurazione di Apache è chiamato apache.conf e, di solito, è contenuto all’interno della directory /etc/http. Alcune distribuzioni utilizzano inoltre una sottodirectory (prevista dalla specifica LSB) nota come /etc/sysconfig all’interno della quale sono salvati una serie di file di testo che contengono un insieme di variabili che, una volta settate al valore desiderato dall’amministratore di sistema, possono influenzarne il comportamento.Tale sistema permette di semplificare la parte di amministrazione in quanto ci saranno una serie di programmi, o di script, che leggeranno il valore di tali variabili e andranno in autonomia a settare uno o più file di configurazione all’interno della directory /etc. In particolare, OpenSuSE utilizza tali file con la sua interfaccia di gestione yast e il processo che poi va a implementare effettivamente tali configurazioni, ovvero SuSEConfig.
Per la configurazione di molti programmi (specialmente quelli che hanno un’interazione con l’utente) nella directory /etc sono contenuti i file di configurazione di default.
Nel momento in cui l’utente desidera variare il comportamento di uno di questi programmi il sistema salverà una copia del file di configurazione in un file o una directory nascosta all’interno della sua home directory, rendendo così tale modifica privata dell’utente.

Nota
Al contrario di quanto avviene nei system Microsoft, un file nascosto in Unix non è basato su un attributo del file stesso (come l’attributo “H” di Windows) quanto piuttosto sul primo carattere del suo nome. Se tale carattere è un punto (“.”) il file non verrà normalmente mostrato dal comando ls o da un file manager. Dato che i file di configurazione sono quasi sempre salvati come file nascosti nella home directory dell’utente prendono spesso il nome di “file punto”. Per visualizzarli con il comando ls è sufficiente specificare il parametro -a.

All’interno della directory /etc sono contenuti anche i file necessari all’inizializzazione del sistema in fase di boot. La procedura di boot di un sistema Linux varia in base alla sua famiglia, ovvero se è di derivazione System V o BSD. Linux attinge a piene mani da entrambe le famiglie. Lo standard LSB specifica che i file di boot debbano seguire i dettami di System V 4.2 ma vi sono delle notevoli eccezioni. La distribuzione Slackware da sempre usa un sistema di inizializzazione di derivazione BSD, così come molte distribuzioni volte all’uso in sistemi embedded o multimediali (come i lettori Archos PMA400). Per capire come funziona la specifica distribuzione con la quale si sta operando è sufficiente esaminare la struttura del file di boot principale, ovvero inittab.
All’interno della directory /etc si troverà anche tutta la parte relativa all’autenticazione. Se questa è locale l’elenco degli utenti si troverà nel file /etc/passwd, mentre le password si troveranno nel file /etc/shadow. La maggior parte delle distribuzioni GNU/Linux sul mercato si avvale di un sistema di autenticazione noto come PAM (Pluggable Authentication Module). Mediante le PAM un sistema Linux può variare la maniera in cui l’utente viene autenticato senza che le applicazioni debbano in alcun modo essere variate. Esistono moduli PAM che permettono di usare i più svariati sistemi di autenticazione disponibili sul mercato, come NIS, OpenLDAP, Active Directory, NDS, Kerberos oppure hardware dedicati, come i sistemi biometrici.
È bene quindi, controllando un sistema GNU/Linux, dedicare sempre un po’ di tempo a esaminare la parte relativa a PAM per capire come il sistema si integrava in una rete locale o se utilizzava sistemi particolari per la gestione delle credenziali di accesso.

Home directory

Il concetto di home directory nei sistemi Unix è molto più radicale di quello presente in altri sistemi operativi. Storicamente, gli unici tre posti dove un utente comune può scrivere all’interno del sistema sono la propria home directory (/home/[nomeutente]), la directory dove appoggiare i propri programmi (/usr/local/bin) e la directory dei file temporanei (/tmp).

Unix e rapporto con gli utenti
Nei sistemi Unix esistono due sole categorie di utenti, gli utenti comuni e root. Non vi è nulla nel mezzo. Non vi sono utenti amministratori, power users, advanced users, subadmin o chissà che altro. Inoltre, vi è una differenza fondamentale tra il “root” di Unix e l’”Administrator” di Windows. In entrambi i casi si tratta di utenti con privilegi amministrativi, ma Unix ha piena fiducia nel proprio amministratore di sistema. Windows, al contrario, si rifiuta di eseguire azioni dichiaratamente lesive per il sistema, come per esempio, formattare il disco di sistema. Non per nulla su Internet si trovano vari paper con nomi del tipo “Unix Administration Horror Stories” che narrano di errori clamorosi di amministratori di sistema Unix. Questo ha portato a due comportamenti diametralmente opposti. Gli amministratori di sistema Windows usano la login di Administrator per svolgere il loro lavoro quotidiano, che esso richieda i privilegi di amministrazione oppure che sia semplice routine. Al contrario i sys-admin Unix usano un’utenza non privilegiata per la maggior parte del tempo limitandosi ad attivare la login di root per il tempo necessario per eseguire le operazioni che richiedono privilegi amministrativi. Tutto questo si riflette in ambito forense. Indagando su un sys-admin Windows sarà bene concentrarsi anche sul profilo di Administrator. Un sys-admin Unix probabilmente terrà la maggior parte dei suoi file all’interno della home directory del suo comune utente.

Le home directory in un sistema Unix sono quindi uno dei primissimi posti dove guardare alla ricerca di molti tipi di informazioni. Vi si troverà, per esempio, quanto segue:

  • Dati dell’utente: molti file utilizzati comunemente dall’utente saranno posti all’interno della home directory. In un sistema standalone vi si troverà probabilmente la quasi totalità del suo lavoro, in uno di rete vi si troverà magari quello su cui sta lavorando recentemente, prima che sia salvato in un repository comune montato attraverso uno dei numerosi protocolli di rete.
    Shell history: quasi ogni shell Unix conserva nella home directory dell’utente la lista dei comandi che egli ha digitato. Osservare questo file alla ricerca di indizi può essere utilissimo.Vi si potrebbero trovare:
    − i comandi digitati da qualcuno che ha compromesso quell’account;
    − il file linkato a /dev/null (in modo che non registri alcuna informazione);
    − indizi sull’attività dell’utente, che consentono di trovare altri file interessanti;
    − tentativi di cambiare il livello del proprio account (con un comando su o su [nomealtroutente];
    − cambiamenti nell’attività dell’utente, tipo una segretaria che, improvvisamente, comincia a compilare e modificare programmi o a scrivere complessi comandi da sys-admin.
  • Cache: in un sistema Unix tutte le cache dei programmi usati da un utente si trovano nella sua home, ivi compresi browser, P2P, downloader, web sucker e altro.
  • File con configurazione: tutte le personalizzazioni dell’utente rispetto alle configurazioni standard di sistema (sia per il sistema operativo sia per i programmi) si troveranno nella sua home all’interno di file o directory nascoste.

In molte reti basate su GNU/Linux o Unix, le home directory sono spesso conservate in un file server centrale. In questo modo, l’utente ritroverà il proprio ambiente indipendentemente dal client utilizzato per collegarsi alla rete.

Swap

Linux può utilizzare sia un semplice file di swap appoggiato a una partizione FAT (tecnica usata dalle Live CD Distro), sia un’apposita partizione marcata come tipo 0x83 (tecnica comune a quasi tutte le distribuzioni). Oltre all’uso di un editor esadecimale e di comandi come strings per l’estrazione delle stringhe ASCII da tale partizione, è stato rivelante, in più di un’occasione, l’uso di un file carver. Certo, molto spesso un file contenuto all’interno di un file di swap può non essere probante (nei casi riguardanti pedopornografia online non può essere usato per dimostrare alcuna attività illecita legata al fenomeno specifico), ma può essere utilizzato per indirizzare le indagini.

Var

Una delle parti più importanti nell’analisi di un sistema Unix è la directory /var. Come si evince dal nome stesso della directory,/var contiene la parte “variabile” dei programmi, quindi tutti i dati non privati degli utenti. Vi si trovano quindi (elenco forzatamente limitato):

  • log di sistema
  • spool di stampa
  • mail in transito e code
  • tablespace degli RDBM
  • cache di sistema
  • confi gurazione dei vari tool
  • database dei pacchetti installati
  • file di bind
  • database di LDAP
  • database di sistema di AFS
  • database di Kerberos

È quindi indispensabile esaminare con cura ogni singola directory contenuta in /var, che, specialmente nei server, può contenere svariati gigabyte di informazioni relative a tutti i maggiori programmi e servizi installati.

Condivisione dati

GNU/Linux è un sistema eccezionale specialmente sul versante della condivisione dei dati. Si è già avuto modo di esaltare le qualità di GNU/Linux come sistema base per l’analisi forense in quanto il kernel, di per sé, è in grado di leggere un numero impressionante di file system differenti (recentemente, attraverso il progetto FUSE, http://fuse. sourceforge.net, il numero si è ulteriormente accresciuto, oltre ad avere il supporto per NTFS anche in modalità lettura/scrittura).
Sulla parte rete le cose sono ancora, forse, più impressionanti. Il supporto ai file system di rete di Linux comprende (ma non è limitato a):

  • NFS: un classico della condivisione sotto Unix. È un file system di rete pensato specialmente per reti “full Unix”;
  • SMB: il protocollo di condivisione di Microsoft. Utile per reti miste Unix/Windows;
  • CIFS: variante di SMB, permette un supporto al file system di rete avanzato di Microsoft;
  • NCP: permette di montare i volumi di Novell Netware;
  • AFS e OpenAFS: l’Andrew File System è nato come un file system di rete multiarchitettura, sicuro, ridondato e crittografato, ottimo specialmente per grandi realtà ove sia necessario anche un elevato grado di sicurezza;
  • CODA: il system di rete avanzato della Carnegie Mellon University;
  • Lustre: file system da cluster utilizzato anche all’interno di Storage Area Network;
  • Apple File Server: per la condivisione dati con sistemi Mac OS.

Altri file system di rete possono essere utilizzati semplicemente mettendo qualche patch all’interno del kernel e ricompilandolo. Questo comunque si traduce nel fatto che un sistema GNU/Linux installato su un portatile può integrarsi semplicemente con quasi tutti i sistemi di rete presenti al momento sul mercato. Di conseguenza, è un ottimo sistema anche per chi, per esempio, volesse rubare dati all’interno di una rete. A seconda del tipo di reato è bene quindi prestare particolare attenzione alla configurazione dei sistemi Linux rinvenuti.

Diario di un computer forensics expert
Si stava investigando a proposito del furto di dati all’interno di un laboratorio di ricerca. Tutta la rete era basata su sistemi Mac OS X con un sistema di autenticazione basato su LDAP e server su piattaforma Xserver di Apple. Non si capiva come i dati venissero trafugati. A un certo punto l’interesse si spostò su un dirigente e, in special modo sul suo palmare, uno Sharp Zaurus. A una prima analisi parve normale ma, dedicandovi un po’ più di tempo, si notò che il sistema operativo originale era stato sostituito da una distribuzione basata su Debian (familiar) + interfaccia grafica Opie (un fork di Qtopia libero). In particolare, il kernel del sistema era stato ricompilato per utilizzare i protocolli di condivisione di Apple Inc. L’utente si connetteva quindi con una scheda Ethernet CF e, usando il palmare, montava i dischi di rete e copiava i dati più interessanti in essi contenuti.

Data hiding

Con i mezzi messi a disposizione sia dal design tipico di Unix sia dalle specifiche uniche di GNU/Linux, il data hiding all’interno di sistemi Linux è limitato probabilmente solo dalla fantasia. Unendo infatti la gestione a basso livello ottenuta tramite la rappresentazione come file nella directory /dev e l’uso di tool per l’accesso sequenziale come dd oppure dei loop device è possibile usare delle tecniche interessantissime. Ecco alcuni esempi.

File system dentro un file system
Si provi la seguente tecnica:

  • Si prenda una porzione di file system e ne si misuri la grandezza: Per esempio, si crei una partizione da 2 GB (2 097 152 KB), si crei un file system all’interno di essa, si controlli il cilindro di file partizione, si cancelli la partizione e la si ricrei da 2.5 GB (2 621 440 KB).
  • Si crei un file vuoto delle stesse dimensioni: dd if=/dev/zero of=file.img bs=1024 count=524288
  • Si usi il file attraverso un loop device: losetup /dev/loop0 file.img
  • Si crei un file system all’interno del file: mkfs.ext3 /dev/loop0
  • Si copi, tramite dd, il file nella parte del disco che gli abbiamo riservato (si ponga /dev/hda2 la partizione appena creata): dd if=file.img of=/dev/hda2 skip=2097152 bs=1024
  • Si monti il file system creato ad hoc mediante il comando mount e l’opzione di offset:
  • mount –o rw,offset=2147483648 /dev/hda2 /mnt

Tale file system non sarà normalmente visibile dato che viene montato di norma quello posto all’inizio della partizione. È possibile complicare ulteriormente la situazione utilizzando la crittografia messa a disposizione dai loop device utilizzando gli encrypted file system (CryptoFS e EncFS) che utilizzano FUSE.

Utilizzo della traccia 0
Come già specificato, la traccia 0 di un hard disk non viene di norma utilizzata. Si parte con il primo cilindro dove risiede il boot sector per poi cominciare con la prima partizione posta al 64-esimo settore. Indirizzare la traccia 0 con GNU/Linux è banale:

  • Si crei un file vuoto delle dimensioni corrette. Sarà di 62 settori da 512 byte (31744 byte): dd if=/dev/zero of=t0.img bs=512 count=62
  • Si usi un loop device per ottenere un device: losetup /dev/loop1 t0.img
  • Si storino le informazioni. Con poco più di 31 KB conviene usare un tar o un cpio (magari compresso) piuttosto che un file system;
  • Si copi il file immagine nella traccia 0: dd if=t0.img of=/dev/hda bs=512 skip=1 Anche in questo caso il file potrebbe essere crittografato prima di essere posto nella traccia 0.

File system steganografico
Vi sono due progetti per Linux, StegFS e magikfs. Entrambi non sono più aggiornati da anni e non funzionano correttamente con gli ultimi kernel. Al momento si tratta quindi di chimere.

Utilizzo di un sistema RAID

  • Si prendano tre chiavette USB di pari capacità e le si colleghi a una macchina Linux.
  • Si crei per ognuna una partizione e la si setti di tipo Oxfd.
  • Si crei un RAID5 software tra le tre chiavette: mdadm –create /dev/md0 –level=5 –raid-disks=3 /dev/sda1 /dev/sdb1 /dev/sdc1
  • Si formatti il disco RAID ottenuto: mkfs.ext3 /dev/md0
  • Si monti il disco /dev/md0 in una directory.
  • Si copino i dati nel RAID.
  • Si smonti il raid, si tolgano le chiavette. Queste potranno essere date, per esempio, a tre persone diverse. Per recuperare i dati dovranno essere presenti almeno due persone. Una delle chiavette a caso può andare perduta.

Anche in questo caso il contenuto può essere crittografato.

Conclusioni

In questo articolo che conclude il nostro speciale sulla computer forensics in ambito di indagine criminale, abbiamo visto come vengono analizzati i sistemi basati su Linux e quali sono le difficoltà a cui si va incontro.

l libro

Computer Forensics Computer Forensics
Per Computer Forensics si intende l’applicazione di un metodo investigativo scientifico al mondo digitale per ricavare elementi, informazioni, prove da portare in sede processuale. Un investigatore deve cioè essere in grado di avvicinarsi a un sistema informativo per determinare se esso sia stato utilizzato in attività illecite o non autorizzate, avendo cura di non alterare le possibili prove. La scena del crimine può quindi essere un computer, un supporto removibile, una rete o qualsiasi altro medium digitale. Ma c’è di più. Poiché la disciplina coinvolge la materia legale, il valore di una prova in sede processuale varia a seconda della legislazione. Quindi è necessario sapere come e che tipo di prova può essere considerata valida in Italia.
Questo libro, il primo manuale sul tema specifico per la scena italiana, è scritto da un esperto di indagini forensi nel “mondo elettronico” coadiuvato da un legale specializzato negli aspetti giuridici degli “illeciti digitali”..

Come acquistare il libro

Se desideri approfondire gli argomenti trattati in questo libro puoi acquistarlo online direttamente 
dal sito di Apogeo.

 

La recensione del libro

Vuoi scoprire gli altri contenuti presenti nel libro dai cui è tratto questo articolo, consulta la pagine Computer Forensics.

Gli autori

Andrea Ghirardini è uno dei precursori della Computer Forensics in Italia. Certificato CISSP e socio CLUSIT, con la sua azienda, @ PSS, presta la sua opera di consulenza sia a Forze dell’Ordine, sia a organizzazioni private, e sino a oggi ha partecipato a oltre 300 indagini che spaziano dalla violazione informatica in senso stretto, a reati come lo spaccio di stupefacenti, la criminalità eversiva e le frodi fiscali. Nel suo diario online, http://blog.is-a-forenser.net/, racconta la sua esperienza di computer forensics expert.

Gabriele Faggioli, legale, è Partner di ISL e Of Counsel dello Studio Legale ISL. Docente presso il MIP-Politecnico di Milano, è specializzato in contrattualistica, informatica e telematica, in information and telecommunication law e negli aspetti legali della sicurezza informatica. È autore di numerosi libri e articoli e membro del Consiglio Direttivo e del Comitato Tecnico Scientifico del CLUSIT.
Resta sempre aggiornato sulle novità del sito Resta sempre aggiornato sulle novità del sito
Per mantenerti sempre aggiornato su nuovi contenuti interessanti, Come fare a... vi offre la possibilità di abbonarvi gratuitamente alla Newsletter Come fare a..., all'RSS o, se usate Windows Live Messenger, di abbonarvi ai nostri Windows Live Alerts. Per gli utenti di Mac OS X è disponibile gratuitamente un Widget che vi terrà sempre informati sulle ultime novità. Vieni a trovarci anche su Facebook e su Twitter.
Scarica l'articolo (291 Kb)
Fine: Pagina precedente 2 di 2
Condividi

Apogeo

Vedi anche...

Sempre aggiornato





Abbonati alla newsletter di Come fare a... Sottoscrivi l'RSS di Come fare a... Usi Windows Live Messenger? Abbonati ai nostri Windows Live Alerts Diventa fan di Come fare a... su Facebook Seguici su Twitter Scarica il Widget per Mac OS X