Solito post segnalibro per non dimenticarmi le cose.

I parametri corretti per impostare una VPN per iPhone e/o iPad lato server sono:

Fase 1:

Encryption: 3DES

Autentication: SHA1

Fase 2:

Protocol: ESP

Encryption: 3DES

Naturalmente servono anche il servizio L2PT abilitato e un utente VPN con le corrette autorizzazioni.

Lato iPhone / iPad la configurazione va inserita in Settings –>General –> Network –> Add VPN Configuration…

Description: un campo mnemonico da compilare a piacimento;

Server: l’indirizzo IP del server VPN (credo funzioni anche con il nome);

Account: il nome utente;

RSA SecurID: OFF;

Password: la password;

Secret: lo shared secret della connessione VPN (preso dal server);

Send All Traffic: ON (provare anche OFF, dipende dalla configurazione).

Per attivarla, Settings –> VPN.

Sul client non c’è modo di cambiare alcun parametro, quindi eventuali prove vanno fatte modificando il lato server. Questa configurazione è certamente funzionante; non escludo ce ne siano altre, ma io non l’ho trovate.

Ci sono diversi casi in cui un dominio viene registrato presso un fornitore mentre l’hosting (o un altro servizio) è altrove; i casi più comuni che mi vengono in mente sono i blog su Blogger e i Tumblr che desiderano utilizzare un proprio nome a dominio mantenendo la comodità di una piattaforma pubblica, oppure quando il dominio di primo livello che avete scelto non è gestito dall’hoster: un caso molto comune sono i domini .it su un provider statunitense. In quest’ultimo caso, poiché non sono supportati i .it, è necessario registrare il dominio altrove e poi intervenire sul DNS in modo da “puntare” il dominio sui server corretti.

Tanto per fare chiarezza sui termini: il “registrar” è l’entità presso la quale avete registrato e pagato il nome a dominio, l’”hoster” è il fornitore di servizi che vi fornisce i server (o parti di essi) sui quali “girano” i servizi legati al dominio. Di solito coincidono, ma quando non è così è necessario intervenire sui DNS.

Gestire le funzioni di base di un DNS non è difficile, ma presuppone la conoscenza di alcuni concetti che vanno capiti prima di effettuare modifiche; normalmente è difficile fare danni irreparabili, ma se si fanno pasticci si rischia di rendere irraggiungibile il proprio sito per diverse ore. Il tutto è reso ancora più scomodo dal tempo di propagazione: prima che le modifiche vengano “recepite” da tutto internet è necessario attendere alcune ore, in certi casi anche 24/36.

Se desiderate una breve spiegazione a proposito del DNS, ne avevo scritto tempo fa; in questo post vorrei parlare delle poche cose da sapere nel caso si voglia gestire il proprio dominio.

Ciascun registrar, l’entità presso la quale avete “comprato” il nome a dominio, gestisce uno o più server DNS. Questi server usano un database nel quale ai nomi a dominio (detti anche “zone”) sono associati diversi record; quelli ai quali siamo interessati sono i record NS, A, CNAME e MX. (Ce ne sono molti altri, ma per i nostri scopi basta gestire questi). Una zona (dominio) comprende uno o più host che erogano i servizi. (In realtà quello che viene chiamato “database” è un semplice file di testo che contiene le diverse righe dei record).

La modifica dei record si fa generalmente tramite il pannello di controllo del registrar, con modalità che cambiano di volta in volta, ma in genere si tratta di interfacce abbastanza intuitive.

Uno dei record più importanti con il quale si ha a che fare è NS. Esso stabilisce chi sono i server DNS per la zona; viene indicato nella forma:

NS	nome.delserver.com.

Si possono specificare piu’ DNS per una singola zona, ma non è possibile sapere quale sarà usato dai resolver: dipende dall’implementazione del resolver stesso, quindi tutti vanno tenuti aggiornati.

In alcuni casi, la modifica di questo record è tutto quello che ci serve. Facciamo un esempio abbastanza comune: un dominio .it registrato in Italia e hostato presso un provider statunitense, per esempio Dreamhost. Una volta che il pannello di DH è pronto per “accogliere” il dominio, è sufficiente modificare i record NS sul registrar in modo che puntino ai DNS americani. In questo modo, la registrazione rimane in Italia, tutto il resto passa a Dreamhost, che diventa responsabile pubblicamente per tutti gli host di quel dominio. Modificando NS, la palla passa a DH che è già pronto per ospitare il nuovo dominio nei suoi DNS; tempo della propagazione e tutto funzionerà alla perfezione.

State attenti: il nome del server va scritto con il punto in fondo, per indicare che è proprio quello e non è un host di quel dominio. Se manca il punto il record verrà interpretato come nome.delserver.com.miodominio.it, e non funzionerà più nulla.

Nel caso non si dovesse e/o potesse modificare il nameserver è necessario intervenire su altri tipi di record. E’ il caso, per esempio, di Tumbr associato a un proprio dominio. Tumblr non fornisce server DNS, quindi dovrò modificare un record A.

Un record A traduce un nome host in un indirizzo IP:

nome IN A    12.34.56.78

dato che la zona è quella del dominio miodominio.it, la riga qui sopra dice che l’host nome.miodominio.it risponde all’indirizzo 12.34.56.78.

Se la riga fosse:

tumblr IN A    72.32.231.8

avremmo appena creato un dominio di terzo livello tumblr.miodominio.it che punta ai server di Tumblr, dove il nostro tlog, opportunamente configurato, è pronto per servire le pagine. Potete trovare maggiori informazioni in un altro mio post.

E’ possibile assegnare più indirizzi IP allo stesso host; essi verranno restituiti come risultato della query DNS e sta al resolver del client decidere quale usare. E’ un meccanismo che talvolta viene utilizzato per ottenere un rozzo bilanciamento di carico tra server distinti.

Spesso un singolo server ospita diversi servizi, accessibili con un nome diverso. Il caso più comune è il seguente:

www IN A    12.34.56.78
ftp IN A    12.34.56.78

In questo caso il singolo host risponderà sia su www.miodominio.it che su ftp.miodominio.it.

C’è un altro modo di ottenere questo risultato, e questo ci introduce all’uso di un altro tipo di record: CNAME. Questo tipo di record permette, usando le parole di Wikipedia, “di collegare un nome DNS ad un altro. La risoluzione continuerà con il nuovo nome indicato dal record CNAME. Questa funzione è molto utile quando, per esempio, sullo stesso server sono disponibili più servizi come FTP, HTTP ecc operanti su porte differenti. Ciascun servizio potrà avere il suo riferimento DNS (ad esempio ftp.example.com. e www.example.com.“.

L’esempio qui sopra potrà quindi essere configurato anche così:

www IN A      12.34.56.78
ftp IN CNAME  www.miodominio.it.

Attenzione, sempre, al punto finale quando si scrive un nome FQDN completo. In questo caso il server DNS restituirà al client che richiede ftp.miodominio.it non un indirizzo IP, ma un altro nome (www.miodominio.it); verrà quindi effettuata una seconda query, dalla quale otterremo finalmente l’indirizzo desiderato. Si dice che ftp.miodominio.it è un “alias” di www.miodominio.it.

Utilizzando i record descritti fin qui si possono gestire la quasi totalità delle configurazioni dove il registrar è separato dall’hosting. Per completezza vediamo l’ultimo record, MX.

Il record MX è molto importante per il recapito della posta perché contiene il nome del server deputato a ricevere messaggi quel particolare dominio. E’ fatto così:

MX	10	posta.miodominio.it.
MX	20	mail.provider.com.

In questo esempio il dominio ha due mail server. Il primo, più importante, è quello con il campo priorità più basso (10) ed è il primo che verrà contattato. Se esso non risponde si passa all’altro (se c’è) che fa da backup e si incaricherà di inoltrare i messaggi al server principale non appena esso tornerà online; impostando due priorità uguali si può ottenere una specie di bilanciamento di carico. Maggiori informazioni sul recapito della posta, il protocollo SMTP e una breve prova pratica li trovate in un mio vecchio post.

La modifica del record MX è necessaria, per esempio, nel caso si utilizzi Gmail per per proprio dominio; è un servizio fantastico ed è gratuito fino a 50 utenti. In pratica Google vi regala una Gmail personalizzata per il vostro dominio, insieme a calendario, contatti condivisi, Google Docs e Google Site.

Vi ricordo che le modifiche hanno bisogno di 24/36 ore per essere propagate a tutto il mondo: una volta cambiati i parametri sul pannello, il server DNS aggiorna (di solito automaticamente) il serial number del record SOA, che serve per sapere se i dati sono stati modificati e quindi aggiornati su tutto il sistema DNS mondiale.

(Alcuni aspetti sono stati volutamente semplificati: una trattazione rigorosa richiede tempo e sarebbe comunque inutile, vista la quantità di materiale reperibile in rete al riguardo.)

Grazie a Mario di BuzzParadise ho ricevuto i nuovi altoparlanti ZiiSound D5 di Creative. Il sito ufficiale è stranamente parco di specifiche tecniche e mi chiedo perché. Gli amici Francesco e Francesca ne hanno già parlato e vi rimando alle loro recensioni che sostanzialmente condivido.

Si tratta di un sistema di altoparlanti compatto con un ricevitore Bluetooth integrato; un dongle (piciurlo) in dotazione si attacca al sedere del vostro iCoso e lo connette senza fili. Grazie al piccolo spazio ricavato sulla sommità, può essere anche usato per ricaricare e fare da alloggiamento per tutti i riproduttori Apple supportati, per i quali vengono fornite una serie di staffe di supporto.

La qualità costruttiva è molto buona, l’assemblaggio è perfetto e i materiali sembrano robusti. L’unico (grande) difetto è la tela nera fonoassorbente di cui è rivestito su due lati: sembra fatta apposta per attirare la polvere e dopo qualche giorno il sistema perde quell’aria di “nuovo di zecca” che aveva appena estratto dalla confezione. Anche la mia unità, come quella di Francesca, presenta delle fastidiose macchie di polvere bianca prorpio al centro del lato anteriore.

L’alimentatore è esterno e i comandi sono ridotti al minimo. L’ergonomia è buona ma migliorabile: le aree touch sensibili non sono chiaramente evidenziate e la procedura di accoppiamento con i dispositivi Bluetooth non è proprio immediata a causa del poco feedback fornito dall’unica spia anteriore. Sul retro si trovano: presa di alimentazione, ingresso line-in e pulsante di accensione; sul lato superiore c’è l’area sensibile al tocco per la regolazione del volume, con una doppia fila di piccoli led bianchi, molto stilosi.

Il suono è veramente molto buono: bassi pieni, alti cristallini e medi ben bilanciati e senza effetto “scatola”; la distorsione sembra molto bassa: la fatica di ascolto è bassissima anche dopo molte ore di uso. Per forza di cose l’effetto stereo è molto basso, ma non è un grosso problema. Il timbro mi sembra abbastanza neutro e poco “colorato”, ma sono passati anni da quando ero appassionato di HiFi e il mio orecchio non è più allenato. Il bass reflex è ben bilanciato e non si sente alcuna distorsione ai bassi, anche grazie al diametro per forza di cose ridotto del foro posteriore. Il suono è potente e anche all’aperto difficilmente si supera il 60% del volume.

L’ho usato in diversi modi: connesso via BT all’iPhone, all’iPod, al mio notebook e a un Nokia E51; tramite cavo con una AirPort Express pilotata tramite Remote sull’iPhone connesso alla libreria iTunes sul mio iMac, e collegato a un Roku SoundBridge; in tutti i casi l’audio è sempre di ottima qualità. L’unica pecca è la regolazione del volume, troppo rozza e poco modulabile sia dal dispositivo che dagli iCosi.

Lo comprerei? Non lo so: il prezzo di listino è molto alto, intorno ai 300 euro. Secondo me è alto perché ho ascoltato analoghi dispositivi con qualità audio confrontabile che costavano meno. A onor del vero qui c’è la parte Bluetooth in più, ma è una caratteristica che può servire o meno, dipende dall’uso che si vuol fare dell’oggetto. Tutto il resto l’ho trovato di ottima qualità e buona funzionalità.

Trasparenza per un mondo migliore: l’oggetto mi è stato regalato.

Scenario 1: siamo connessi ad internet tramite un firewall con politiche restrittive che non permette il traffico verso i server di cui abbiamo bisogno e/o verso alcuni siti web.

Scenario 2: siamo connessi ad internet tramite una rete non fidata (internet cafè, lanparty, hackmeeting) e sospettiamo che il nostro traffico possa essere sniffato da qualche malintenzionato.

In questi casi, avendo a disposizione un account su un server SSH pubblico raggiungibile su una qualunque porta (anche diversa dalla stardard TCP/22) possiamo utilizzare il dynamic port forwarding, un sistema particolarmente comodo di veicolare traffico criptato bypassando eventuali restrizioni.

Il port forwarding dinamico (dynamic port forwarding) è un meccanismo trasparente che supporta il protocollo SOCKS4 o SOCKS5. Invece di configurare un port forwarding da porte specifiche dell’host locale verso porte specifiche del server remoto, esso permette di specificare un server SOCKS che può essere utilizzato dalle applicazioni. Il Client SSH apre una porta sull’host locale e simula un server SOCKS per ciascuna delle applicazioni opportunamente configurate. Quando queste applicazioni devono connettersi a servizi come HTTP, FTP, POP3, SMTP ecc., esse “parlano” al client SSH che simula un server SOCKS e crea un port forwarding verso il server SSH remoto, al quale inoltra il traffico crittografato dal protocollo SSH.

In pratica tutto il traffico in uscita dalle applicazioni configurate per usare il server SOCKS locale viene incapsulato nella connessione SSH verso il server remoto, da dove esce e viene poi veicolato verso i server di competenza. Per effetto di questo meccanismo otteniamo il duplice risultato di bypassare le eventuali regole restrittive del firewall (in quanto la connessione in uscita è solo verso il server SSH), e di criptare tutto il traffico dal client fino al server SSH, nascondendolo agli sguardi indiscreti.

Il requisito principale è un accesso shell via SSH a un server che possiamo raggiungere: potrebbe essere anche un computer a casa che abbiamo configurato per essere raggiungibile dall’esterno con varie tecniche, ad esempio DynDNS. Praticamente tutte le distribuzioni linux contengono OpenSSH, disponibile anche per Windows e su OS/X si abiliterà il login remoto. Il giochino funziona anche se avete un account su un server di un provider che fornisce una shell SSH, ad esempio DreamHost, e riuscite a raggiungerlo dalla vostra posizione. I client sono Putty per Windows e nativi negli altri casi.

Putty può essere usato tramite linea di comando o interfaccia grafica. La sintassi per la linea di comando è la seguente:

putty -ssh -D 9999 -P 80  serverssh.dominio.com

dove:

• -ssh indica usare il protocollo SSH.
• -D 9999 indica al client di ascoltare sulla porta 9999/TCP. Potete utilizzare qualunque porta libera sul vostro client: controllate con netstat -an -p TCP | findstr LISTENING (Windows) o netstat -an -p TCP | grep LISTEN (OS/X e linux).
• -P 80 identifica la porta sulla quale è in ascolto il server SSH remoto. Se è la default TCP/22 non serve indicarla.
• serverssh.dominio.com è il nome del server SSH. Si può usare anche l’indirizzo IP.

Se si usa l’interfaccia grafica bisogna stabilire una normale connessione, poi aggiungere un tunnel nel menu Connection –> SSH –>Tunnels compilando il campo “Source port” (la porta locale di ascolto),  lasciare vuoto “Destination”, scegliere “Dynamic” e cliccare su “Add”

La sintassi per linux e OS/X è:

ssh -D porta_locale utente@serverssh

Una volta autenticati e stabilita la connessione si può minimizzare la finestra della console senza chiuderla e passare alla configurazione delle applicazioni. In Windows si possono utilizzare tutte quelle che supportino l’utilizzo di un server SOCKS. Praticamente tutti i browser lo fanno e molti altri programmi hanno il supporto, per esempio Pidgin.

In Firefox la configurazione si fa tramite il menu Strumenti –> Opzioni –> Avanzate –> Rete  –> Impostazioni –> Configurazione manuale del proxy –> Host SOCKS e si specifica “localhost” (o 127.0.0.1) e la porta locale sulla quale ascolta il client SSH (9999 nell’esempio qui sopra).

Una comoda alternativa è rappresentata da una categora di tool chiamati socksifier, che permettono a qualunque applicativo di connettersi all’esterno tamite SOCKS. Uno dei più utilizzati per Windows è gratuito e si chiama WideCap. Su linux si può usare tsocks, avendo cura di modificare prima il file /etc/tsocks.conf specificando 127.0.0.1 nella variabile “server” e la porta desiderata in “server_port”.  Per OS/X il supporto è nativo: Preferenze di sistema –> Network –> scegliete l’interfaccia con la quale siete collegati ad internet –> Avanzate –> Proxy –> Abilitare “Proxy SOCKS” e compilare i capi “Server” (localhost) e porta (quella scelta precedentemente). In questo modo tutte le connessioni uscenti da quella scheda di rete transiteranno attraverso il proxy SOCKS, e non ci sarà bisogno di toccare la configurazione delle applicazioni poiché il meccanismo è completamente trasparente.

Questo è un breve screencast che mostra come utilizzare Putty e Firefox per ottenere un port forwarding dinamico.

(Utilizzate questi metodi con giudizio: bypassare le policy di sicurezza aziendali vi potrebbe mettere nei guai.)

Ieri sono stato invitato a visitare la filiale italiana di Kroll Ontrack, una multinazionale che si occupa di recupero dati, cancellazione sicura e computer forensic. Mattinata molto interessante, grazie al taglio abbastanza “tecnico” dell’incontro. Dopo una chiacchierata con Massimo (marketing) che ci ha brevemente introdotto l’azienda ed è stato molto disponibile nelle sue risposte, abbiamo avuto modo di visitare la camera bianca. Si tratta di una camera di classe 100, dall’aspetto molto meno fantascentifico dell’iconografia classica, ma adatta all’apertura dei dischi fissi. La dotazione di strumenti contribuisce a renderla un luogo particolarmente interessante. Mi pare di capire che si tratti dell’unica in Italia dedicata a questa attività.

In questo laboratorio i tecnici ricevono gli hard disk danneggiati e tentano di farli ripartire, spesso sostituendo incolucri, motori, testine ed elettroniche. Se l’operazione ha successo, il pezzo viene collegato a una workstation e ne viene fatta un’immagine sulla quale lavoreranno poi altre persone per ricostruire i dati eventualmente danneggiati. Il lavoro è uno strano incrocio tra orologeria, tecnica elettronica e artigianato, e come per tutti i mestieri di questo tipo ci si divide tra la routine quotidiana e le sfide che diventano quasi personali. Massimo e Luca ci hanno descritto il loro lavoro e hanno risposto alle nostre domande; non si incontrano tutti i giorni persone che svolgono questa attività, per questo ho cercato di carpirne per quanto possibile piccole passioni e idiosincrasie che si sviluppano con l’esperienza. Da quanto ho capito le diverse interfacce dei controller e il sistema operativo non incidono sulla distribuzione dei guasti tra i vari sistemi, le brusche interruzioni di corrente e il suo repentino ritorno sono deleteri, gli urti a dischi in movimento possono essere letali. Ciascun braccetto ha un allineamento peculiare delle testine che viene misurato tramite un microscopio al momento della sostituzione. Lo sfasamento viene poi replicato in modo da permettere la corretta lettura dei dati. Mi ha molto divertito il foglio di cellophan appiccicato al monitor con l’immagine ingrandita sul quale si segna con un pennarello la posizione delle testine per poi riportarla sulle nuove.

La percentuale di successo dichiarata mi ha stupito: pare che mediamente si riesca a recuperare il 90% dei dati su dispositivi non precedentemente manomessi da tecnici improvvisati: ci è stato raccontato di casi in cui i dischi sono arrivati con una elettronica non originale, con impronte digitali sui piatti o testine palesemente danneggiate da interventi non riusciti. In tutti questi casi la percentuale di successo diminuisce drasticamente, e non è difficile capire perché. La leggenda metropolitana che girava qualche anno fa (non ci ho mai creduto), secondo la quale mettendo il disco in frigo aumenterebbero le probabilità di riavvio, è completamente infondata: in più di un caso i dischi sono arrivati con dell’acqua all’interno, dovuta alla condensazione dell’aria per lo sbalzo termico.

Mi è stato confermato che esiste una “stagionalità” dei guasti: la calura estiva e i temporali sono fattori di rischio che aumentano sensibilmente i guasti. Quindi ambienti termostabili e buoni UPS non sono mai quattrini mal spesi.

Ho avuto l’impressione di un ambiente tranquillo, competente, con grande attenzione alla privacy e alla sicurezza dei dati ripristinati. Prima di questa visita ho avuto solo un paio di esperienze di clienti che hanno usufruito del servizio, e in entrambi i casi sono stati soddisfatti dal lavoro effettuato.

(Tra le altre cose mi ha fatto piacere scoprire che una mia personale impressione, maturata negli anni, è condivisa da persone che vedono decine di unità al giorno.)

(Le foto linkate sono di Elena.)

Oggi ho terminato lo spostamento di hosting da Aruba a WebPerTe di Mamma Imperfetta. Il caso è interessante perché, malgrado le dimensioni del database non propriamente maneggevoli e la quantità di dati da spostare, il processo si è svolto rapidamente e senza inconvenienti grazie a un minimo di pianificazione e alla disponibilità del nuovo hoster. Lo spostamento prevedeva anche il cambio mantainer, fatto in concomitanza con l’hosting.

Appena Silvia ha avviato le pratiche di acquisto e trasferimento del dominio, ho provveduto a salvare 350 MB di file via FTP e 30 MB di database. La configurazione del blog è abbastanza complessa, sia per l’elevato numero di plugin (circa 40) che per l’altissimo numero di file generati da un paio di essi. Per stare sul sicuro ho fatto sia un salvataggio del db via PHPMyAdmin, nel doppio formato testo e compresso, che una esportazione del file XML via pannello di amministrazione. Per precauzione supplementare ho salvato uno screenshot dei plugin attivi e uno della configurazione degli widget della sidebar. Tutti i dati sono stati duplicati su due computer diversi e su DropBox (*).

Durante il periodo di attesa non sono stati pubblicati ulteriori post e ho ripetuto la procedura di backup ogni giorno, in modo da avere una copia del database il più fresca possibile. Nel frattempo ho preparato una rudimentale maintenance page da pubblicare sul nuovo hosting durante i lavori.

Al termine del trasferimento e dopo la propagazione dei DNS, è apparsa la landing page del nuovo dominio, che ho immediatamente sostituito con quella preparata da me, in modo da non disorientare i lettori abituali.

Sul pannello di amministrazione ho creato un nuovo database vuoto con relativo utente, ed ho apportato le necessarie modifiche al file wp-config.php offline. Ho rinominato index.php in index.tmp e .htaccess in htaccess.tmp e ho lanciato l’upload dei file, ai quali ho aggiunto anche l’ultimo dump del db, opportunamente compresso.

Mentre FileZilla era al lavoro ho aperto un ticket all’assistenza, specificando nome del db e relativo server, chiedendo la cortesia di importare il dump che stavo uploadando. Non disponendo di accesso SSH avrei dovuto spezzare il file a mano ed effettuare l’import in sessioni ripetute, perdendo parecchio tempo e rischiando errori, mentre via terminale l’operazione consta di una semplice istruzione e impiega pochissimo.

Al di là di ogni più rosea previsione, WebPerTe ha fatto quanto richiesto nel giro di 6 (sei!) minuti: in pratica avevo appena finito l’upload. A questo punto ho cancellato la maintenance page e rinominato correttamente index.php e .htaccess. Bum! Funziona tutto alla perfezione. Ho dovuto solo far ricreare le Google Sitemap dall’apposito plugin, nessun’altra operazione si è resa necessaria. Avendo mantenuto lo stesso wp-config.php non è stato neppure nescessario riautenticarsi sulla dashboard perché il cookie era ancora valido.

Ho scritto altre volte di questa operazione: Spostare WordPress su un altro hosting e Trasferimento di WordPress su un altro hosting: un metodo veloce.)

(*)Nel link c’è il mio referral per DropBox.

Il concetto di “Leading Innovation” di Toshiba deve avere a che fare con il vendere alle aziende computer farciti di software non richiesto e largamente inutile.

(È appena uscito dalla scatola.)

Il giorno 21 aprile 2010, per una limitata finestra temporale, McAfee ha rilasciato un aggiornamento che causa la perdita della connessione di rete sui computer XP Service Pack 3 attaccando erroneamente svchost.exe (falso positivo). Sono riportati anche errori più gravi come BSOD e riavvi.

McAfee’s “DAT” file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and loose all network access. We have individual reports of other versions of Windows being affected as well. However, only particular configurations of these versions appear affected. The bad DAT file may infect individual workstations as well as workstations connected to a domain. The use of “ePolicyOrchestrator”, which is used to update virus definitions across a network, appears to have lead to a faster spread of the bad DAT file. The ePolicyOrchestrator is used to update “DAT” files throughout enterprises. It can not be used to undo this bad signature because affected system will lose network connectivity(*).

L’aggiornamento incriminato è il DAT 5958 rilasciato il 21 aprile 2010. McAfee ha rilasciato il giorno seguente degli appositi tool con relative istruzioni per ripristinare la funzionalità dei computer: qui il documento per utenti aziendali e qui quello per gli utenti home o singoli.

La soluzione del problema è abbastanza semplice: si tratta di scaricare una patch ed eseguirla, meglio se in modalità provvisoria. L’alternativa “manuale” è l’aggiornamento del DAT e il ripristino del file svchost.exe prelevato da un computer con lo stesso livello di service pack.

Pare che la moda del momento sia chiedere che i propri dipendenti non usino Facebook e non chattino su MSN. Pur non essendo d’accordo, credo si tratti di una richiesta lecita se fatta da chi paga sia le persone che la banda(*).

I sistemi di content filtering possono essere costosi e/o impegnativi nella manutenzione per aziende di piccole dimensioni che magari dispongono a malapena un firewall. Ci sono un paio di tecniche che permettono di filtrare abbastanza agevolmente senza dover fare alcun investimento. Il principio è controllare le query DNS, intercettando i domini da bloccare e/o utilizzando l’apposito servizio gratuito fornito da OpenDNS. Della situazione speculare, il blocco totale con pochi domini in whitelist avevo già parlato qui.

Come spesso accade, in azienda c’è un piccolo server Windows 200x o Small Business Server che adempie alle solite funzioni (AD controller, file e print server, DNS, DHCP ecc ecc.); concentriamoci sul DNS. In questo esempio mi interessa bloccare il traffico verso Facebook, quindi ne carico una pagina e do una scorsa al sorgente HTML, dal quale mi accorgo che gli unici domini interessati sono Facebook.com e fbcdn.net. Provvedo quindi a creare due nuove zone di ricerca diretta primarie, integrate in AD e replicate su tutti i server DNS proprio per quei due domini (facebook.com e fbcdn.net).

Il risultato di questa operazione sarà che il mio server sarà convinto di essere autoritativo per i domini in questione e non si preoccuperà di recuperare dai suoi forwarder, o dai root server, l’indirizzo IP degli host di quei domini(**). Non avendo alcun record di tipo A definito, restituirà al client un messaggio di host sconosciuto (“www.facebook.com non esiste“); otteniamo così il risultato di rendere Facebook non raggiungibile. (Naturalmente devo attendere che la cache DNS sui client sia scaduta o forzarne il refresh con ipconfig /flushdns)

Per evitare che un utente più smaliziato usi un server DNS pubblico, bisogna bloccare sul firewall tutto il traffico in uscita sulla porta 53 sia TCP che UDP, tranne quello proveniente dai server DNS interni.

Per bloccare Messenger e per un controllo su altre categorie di siti, si può usare il servizio gratuito offerto da OpenDNS, dove basta registrarsi, configurare il proprio server DNS con gli appositi forwarder, registrare e confermare il proprio network seguendo le semplici indicazioni (c’è anche un client per chi non ha un IP pubblico statico) e attivare il content filtering. Questo è un esempio di configurazione che blocca Messenger ed altre categorie di siti.

Queste impostazioni che vedete sono disponibili anche nella versione gratuita, che assolve egregiamente ai suoi scopi. Si possono anche specificare singoli domini da blacklistare. Il servizio offre anche un po’ di statistiche. Le pagine bloccate vengono catturate e viene restituita una pagina con messaggi personalizzabili e logo dell’azienda.

E’ evidente che questi metodi non resistono ad un utente con competenze evolute (non riuscirete a bloccare il traffico a un ufficio di sistemisti), ma per la maggior parte dell’utenza è uno scoglio insormontabile.

Pregi:

• Sono gratuiti.
• Sono molto semplici da implementare.
• Sono facili da spiegare ai clienti.
• Richiedono pochissima manutenzione.
• Sono adatti a aziende piccole o medio-piccole.
• Sono facilmente reversibili alla configurazione “tutto aperto”.

Difetti:

• Pasticciare con le query DNS non è affatto elegante.
• Ci si affida a un servizio esterno con tutto ciò che ne consegue in termini di sicurezza, privacy e continuità del servizio.
• Utilizzare un servizio come OpenDNS che raccoglie un database di query e lucra sul traffico rediretto è comunque un compromesso.
• Non scalano bene nel caso le esigenze di controllo diventino più granulari.
• Non sono adatti ad aziende più grandi con infrastrutture più complesse.

(*)Ulteriori considerazioni sul filtrare i contenuti internet sono al di fuori dello scopo di questo post.

(**)Semplificazione. Per una spiegazione più approfondita, leggimi qui.

Tapullo: “Non esiste parola che si possa paragonare a Tapullo. Trattasi di riparazione di fortuna che spesso dura nel tempo e aggiunge nuove funzionalità (…). I Genovesi, da sempre parsimoniosi, sono abili nei Tapulli. I Tapulli vengono mostrati con fierezza agli amici, alcuni diventano perfino leggendari e spesso i grandi marchi vi si ispirano per migliorare i propri prodotti. A volte viene usato il termine per denigrare una riparazione di fortuna (raro), o per indicare una soluzione temporanea (più comune).” Fonte.

Ricetta quick’n dirty per creare una VPN tra un client remoto ed un server, entrambi con sistema operativo Windows. Destinata a cuochi mediamente abili. Versione routed(*).

Ingredienti:

• Un host che faccia da server, con IP privato statico (es: 192.168.1.2/24), collegato ad internet, acceso 24/7 e a cui il router inoltri almeno una porta TCP(**) (Es: TCP/11900). Windows 2000 o successivi, non necessariamente Server.
• Un client con connessione ad internet con IP privato di classe diversa dal server (es: 192.168.254.0/24).
• OpenVPN.

Esecuzione:

• Generare una chiave simmetrica key.txt tramite l’apposita utility e copiarla nelle cartelle “config” di OpenVPN di entrambi gli host.
• Scegliere una terza subnet diversa da entrambe le subnet degli host coinvolti. Es: 172.30.0.0/16.
• Aggiungere sul default gateway (tipicamente il router) della rete del server una rotta statica che inoltri tutto il traffico destinato alla rete 172.30.0.0/16 verso l’IP privato del server (192.168.1.2).
• Registrarsi su DynDNS e creare un hostname per il server (es: mioserver.dnsalias.net).
• Installare sul server il client DynDNS (versione per 200x Server in fondo alla pagina) e configurarlo per usare l’hostname appena creato. Accertarsi che il relativo servizio parta automaticamente.
• Installare OpenVPN su entrambi gli host, e inserire nelle cartelle “config” di OpenVPN i ripettivi file di configurazione, con estensione .ovpn.

File: client.ovpn
remote mioserver.dnsalias.net
dev tap
proto tcp-client
rport 11900
ifconfig 172.30.1.2 255.255.0.0
route 192.168.2.0 255.255.255.0 172.30.1.1
secret key.txt
verb 3

File: server.ovpn
dev tap
proto tcp-server
lport 11900
ifconfig 172.30.1.1 255.255.0.0
secret key.txt
verb 3

• Sul server avviare il servizio “OpenVPN Server” e impostarne l’avvio automatico.
• Sul client, collegato ad internet con una connessione internet diversa dal server,  eseguire “OpenVPN GUI” in modalità amministratore, cliccare col tasto destro sull’icona nella systray e scegliere “connect”.
• Effettuare dei test di connettività. In caso di problemi, i log di OpenVPN sono molto esplicativi già a verb 3.

Guarnire con quanta più banda possibile e servire con due righe di istruzioni per l’utente.

(*)Le due reti non sono in bridging, configurazione comunque possibile ma leggermente più complicata.

(**)Si può usare anche UPD, che sarebbe il default di OpenVPN, ma su alcuni router SOHO non si possono inoltrare le relative porte.