Bootcamp: da OS X a Windows per il “superior hardware”

Dopo aver lasciato sbizzarrire gli hacker in complicate conversioni, per portare OS X su PC, Apple ha rilasciato ieri Bootcamp, un “invertitore di flusso” per il mercato hardware, più che software. Cosa significa “invertitore di flusso”? Ci torneremo in seguito. Per ora limitiamoci a capire a cosa serve Bootcamp: semplicemente, si tratta di un’utility grafica che semplifica il lavoro di ripartizionamento del disco di un Mac Intel, automatizzando nel contempo la creazione di un cd di driver tramite il quale diventa possibile installare Windows XP sulle nuova macchine Apple, senza troppi problemi. Basta armarsi di un cd di installazione originale di Windows XP, un cd vergine sul quale masterizzare i driver, lanciare Bootcamp e alla fine riavviare il computer: l’utente si ritroverà con un sistema dual boot OS X/Windows XP, praticamente il sogno di molti che ancora non vogliono acquistare un Mac per paura di abbandonare un sistema operativo ben conosciuto e familiare come quello di Microsoft. Da notare che Bootcamp è disponibile per ora in forma di beta gratuita liberamente disponibile, ma sarà integrato nella prossima release di OS X, denominata Leopard e questo lascia pensare a qualcosa più di una semplice helper utility, buttata lì quasi casualmente.

Ma tutto questo, giova veramente e solamente all’utente?
Proviamo a compiere due riflessioni senza rete.

E’ interessante richiamare alla mente la strategia di posizionamento di Apple nella catena di valore che definisce la redditività di un prodotto di largo consumo come iPod: dalla creazione, alla distribuzione, alla fornitura di contenuti digitali, tenuta alla briglia dal DRM applicato ai prodotti iTunes, quasi tutta la filiera è saldamente nelle mani di Apple. Indubbiamente ciò è un bene per l’utente finale: Apple ricava a ogni passaggio un piccolo guadagno e il prezzo di ogni singolo stadio si attesta su valori tutto sommato bassi. E’ l’azione sinergica dovuta al possesso dei vari anelli della catena del valore a consentire che ogni step sia poco oneroso, garantendo nel contempo un buon guadagno complessivo del prodotto iPod, visto come unione fra prodotto materiale e contenuti multimediali offerti dallo stesso player, la casa di Cupertino.

A ben vedere, si tratta della stessa strategia perseguita nel tempo da Apple anche con i prodotti Mac: chiusura verso l’esterno, hardware proprietario, sistema operativo proprietario. Ma questa non ha avuto la stessa fortuna incontrata da un prodotto tutto sommato a basso costo e dall’acquisto compulsivo quale è l’iPod. E basta ritornare al 1997 per sentire Michael Dell suggerire la sua soluzione alla crisi profonda nella quale Apple versava in quegli anni: chiudere l’azienda e restituire i soldi agli azionisti.

Si era al culmine di una parabola discendente, di un meccanismo di produzione di valore negativo, fallito, rimasto confinato in una nicchia di utenti per lo più “creativi”, certo non di massa, tant’è che solo nel 2000 Jobs riesce a recuperare una situazione finanziaria critica e a ridare fiato all’azienda con l’introduzione dell’iPod, ma siamo nel 2001.

Di massa era sicuramente Windows, un sistema tutto sommato sul limine opposto a quello di Apple: un sistema operativo per nulla integrato con la soluzione hardware pilotata, aperto alle incursioni di produttori di ogni dove.

Il risultato? Computer meno costosi, sistema operativo estremamente diffuso, apertura di Microsoft sul fronte delle applicazioni. Non c’è da nascondersi che il fatto di produrre un sistema operativo avvantaggi chi sia intenzionato a scrivere delle applicazioni per questo sistema e Office è la maggior fonte di rendita per Microsoft: è ovunque, utilizzato da chiunque, per qualunque scopo. Ovviamente generalizziamo, ma è una generalizzazione che rende l’idea.

Se Office è la principale fonte di guadagno di Microsoft, più di Windows stesso, nelle sue varie forme, quale è il peso della strategicità dello scrivere o possedere il sistema operativo sul quale questo risiede?

Non sfugge certo il tentativo di Microsoft di spostate parte del business su Live, la piattaforma che centralizzerà gli applicativi e i dati da essi prodotti sui server remoti gestiti da Microsoft stessa. Progetto inseguito da molto tempo, ma che solo l’avvento del broadband diffuso ha consentito di rendere un’idea praticabile, spostando la produttività dal computer periferico, fondamentalmente incontrollabile, a una sorgente di erogazione di servizi remota, centralizzata, maggiormente controllabile.

Il sistema operativo si sta lentamente “virtualizzando”, diventando accessorio rispetto alle applicazioni, ai programmi, che siano dedicati alla produttività d’ufficio, alla gestione delle email, ai giochi ormai molto diffusi online.

E veniamo all’hardware. I Core Duo di Intel non sono una prerogativa esclusiva di Mac e gradatamente, senza troppo clamore, nelle fasce più alte di prodotto, soprattutto per i notebook, stanno arrivando i nuovi processori Intel, associati ai chip di Trusted Computing.

Ma cosa frena gli utenti dal prendere OS X funzionante su processore INTEL e portarlo sulle piattaforme PC dotate dello stesso tipo di CPU? Nulla, in effetti già qualcosa è stato fatto aggirando la protezione dei chip TC presenti, finora sfruttati al minimo delle loro potenzialità.

Prendendo la palla al balzo, però, Apple inverte i termini del gioco: perché portare OS X su PC, quando è Windows che può essere fatto scivolare senza problemi dentro un Mac Intel?

Lo scambio dei fattori, a ben vedere, è molto più redditizio. Non è il portare un sistema software “sconosciuto” su una piattaforma hardware familiare ad ampliare la base di mercato, ma è proprio il contrario, cioè portare un sistema operativo familiare su una piattaforma hardware sconosciuta.

A ben vedere, portare OS X su PC non ha né molto senso nè grandi vantaggi: la piattaforma Mac ha sempre goduto di buone prestazioni e affidabilità proprio per la forte compenetrazione fra sistema operativo e hardware, entrambi in mano ad Apple e quindi ben conosciuti e ben sfruttati. Muovere qualche passo nel mondo dei PC costringe a inerpicarsi in quella babele di periferiche, schede e processori che hanno reso si molto diffuso Windows ma ne ha anche limitato le prestazioni e inficiato la stabilità.

OS X, in fin dei conti, non ne avrebbe molto da guadagnare soprattutto se si tiene conto degli sforzi compiuti da Apple per accreditare i propri computer come oggetti di qualità, facili da utilizzare e costruiti con materiali di buona fattura.

Ha maggior senso l’operazione inversa: portare gli utenti Windows dalle piattaforme hardware PC a Mac.

Perché? Sostanzialmente per eliminare un gap sostanziale che ostacola la diffusione di OS X, ovvero la diffidenza di quegli utenti che sono nati in Windows e cresciuti con le sue applicazioni. Chi si butterebbe a corpo libero in un sistema operativo sconosciuto, con il timore di non ritrovarvi le applicazioni di sempre?

Lungi dal pensare all’utente avanzato, Apple ha a che fare con il cliente che utilizza il computer prima ancora di comprenderlo, che lo accende e vi ritrova quelle applicazioni che è solito utilizzare. Questi possono essere portati a OS X essenzialmente con due operazioni sinergiche:

  1. Con la riaffermazione dell’immagine di prodotto. Mac è semplice, Mac è user friendly, Mac funziona e non ha schermate blu, rosse o verdi. Mac è, dopo il successo di iPod, ancora più trendy, definisce uno stile di vita, un’immagine di sé, veicolata dal prodotto, vincente. Determina una identità di appartenenza a un gruppo connotato da forti attributi positivi e di integrazione sociale;
  2. Rassicurazione dell’utente. In OS X si possono ritrovare le applicazioni che vengono utilizzate in Windows. E se non vi sono, ora diventa possibili tenere Windows su Mac, accanto a OS X, e utilizzare uno o l’altro, forse il meglio di uno e dell’altro.

La transizione, quindi, può non solo completarsi, ma, aspetto più interessante, può iniziare.

L’utente è blandito e rassicurato, viene traghettato in una immagine positiva e nel contempo non è costretto ad abbandonare il mondo di riferimento, un po’ come un bambino che muova i primi passi attaccato alla gonna della madre.

Cosa ci guadagnerebbe Apple? Sicuramente inizierebbe a traghettare nel proprio mondo tutti quegli utenti curiosi, interessanti, ma poco disposti ad abbandonare un sistema operativo, o meglio una serie di applicazioni, utilizzate quotidianamente, a casa come in ufficio.

Altrettanto sicuramente, porterebbe questi utenti a conoscere OS X, visto che Windows XP si installerà solo come secondo sistema operativo, lasciando presente e attivo il sistema nativo Apple.

Infine, porterebbe i clienti a scoprire la qualità dell’hardware Apple, definito nelle parole di Philip Schiller, senior vice president del Worldwide Product Marketing di Apple “superior hardware”, che quindi sarà “more appealing to Windows users considering making the switch”.

Ma a discapito di chi andrà questa transizione? Di Microsoft? Difficile a dirsi. Certo è che se si vogliono cogliere segnali di nervosismo, questi andrebbero, per ironia, attribuiti a Dell, che ha appena acquisito Alienware, azienda specializzata nella produzione di computer che, non a caso, costituisce in parte un omologo di Apple nel mondo dei PC: crea hardware di qualità e computer dall’aspetto molto curato.

Microsoft, dal canto suo, può tutto sommato rimanere a guardare: il proprio sistema operativo inizia un viaggio su piattaforme del tutto nuove, mentre proprio lì dove finora arrivava con difficoltà, nel mondo Apple, ora può entrare a pieno titolo, con le proprie applicazioni in modalità nativa. Se, poi, dovesse perdersi il sistema operativo lato consumer, non è su quello che si crea business, ma su Office, che già ora sta guardando a nuovi orizzonti, lasciandosi dietro i vecchi PC “disconnessi”.

E così Apple arriverebbe a coronare un vecchio sogno, ovvero arrivare a controllare la catena di produzione del valore associata ai computer, strategia riuscita con iPod, assolutamente fallita con i Mac, non tanto per una questione di controllo, quanto per una resa produttiva inficiata dai numeri finora troppo bassi.

Di sfuggita, potremmo accennare a un nuovo problema: con l’avvicendamento di nuovo hardware pare ridursi la fetta di computer privi dei nuovi chip dedicati al Trusted Computing. DRM e TC, due facce della stessa medaglia, paiono essere i leitmotiv dell’industria dei prossimi anni, impegnata a gestire, salvaguardare e ottimizzare la gestione dei contenuti sulle piattaforme end user, decidendo chi può fare cosa, dove e quando.

Cosa fare se il mercato pare imprimere una decisiva svolta in questa direzione? Ci ritroveremo, come per i monitor LCD, senza più la possibilità di scegliere computer non TC? Già, perché basta andare in un qualsiasi centro commerciale per accorgersi che è il mercato dei computer a formare la domanda e non viceversa: provate a cercare un vecchio monitor a tubo catodico. Semplicemente, non se ne fanno più.

E quando non si faranno più computer privi di TC e DRM? Dovremo iniziare a pensare in termini di Hardware Libero? Difficile. Se nel mondo del software la creatività è affiancata da un ridotto costo materiale, nella sfera dell’hardware il discorso cambia radicalmente. Una scheda madre va ingegnerizzata, realizzata in prototipi, provata per poi essere messa in produzione su una linea di gestione appositamente attrezzata. E tutto questo richiede investimenti non comparabili con quelli richiesti per lo sviluppo di un progetto unicamente software.

C’è chi riduce la questione dei DRM a una semplice questione di interoperabilità, tesi interessante ma fuorviante, e chi tenta di far passare il Trusted Computing come strumento essenziale per combattere virus, troiani e malware in generale.

Ma chi ha da guadagnarci in tutto questo?

L’utente, tutto sommato, ben poco. Su gnuvox trovate una serie di link utili a risorse per approfondire i problemi legati ai DRM.

Il mercato ha tutto da guadagnarci, rafforzando il controllo sui “contenuti”, nuova parola d’ordine per il futuro prossimo venturo.

E quando non avremo più scelta? Dove vorrete andare, domani?

Bye, bye, baby

client_malevolo.png

E’ da tempo che mi dico che è ora di cambiare il portatile.

  • Si è bruciato un banco di ram e non è facile trovarne un altro;
  • Non riconosce più floppy e cdrom;
  • Se lo appoggi meno che molto delicatamente, semplicemente si blocca;
  • Se appoggi i polsi con troppo peso, inizia a dare errori nel riconoscimento del disco rigido;
  • Se premi troppo leggermente i tasti, nemmeno li vede, se troppo forte, raddoppia la digitazione;
  • L’uscita audio è andata.

E’ pur sempre un vecchio Dell Latitude Cpx PIII. Gran macchina. A parte questi ultimi problemi, ha sempre fatto il suo dovere e si è anche lasciato usare come walkman dentro la mia borsa, in accoppiata con mp3blaster. Certo, non è piccolo come un iPod, ma è pur sempre il mio piccolino.

A dire il vero, a mio avviso, a generare l’errore sono due processi concorrenti con utente root che stanno andando in conflitto.

Però, però, come dice il libro dell’Ecclesiaste, c’è un tempo per tutto e il suo, mi sa, è arrivato.

Cosa è Unix?

GNU/Linux è un sistema operativo Unix-like, ovvero è un sistema che si comporta come Unix, ma non è Unix. Sembra un gioco di parole, ma il problema si annida nella storia stessa di Unix, un sistema operativo nato più di 30 anni fa per uso commerciale e che è stato standardizzato negli anni attraverso le Single UNIX Specification (SUS), una famiglia di standard utilizzati per qualificare quei sistemi operativi che possono definirsi Unix.
Ricostruiamo, a brevi linee, l’albero genealogico di GNU/Linux, partendo dal lontano 1969, dai laboratori Bell della AT&T, nei quali venne sviluppato il primo sistema operativo per il PDP-7, un calcolatore a transistor dell’epoca. Al primo ricercatore, Ken Thompson, si unì ben presto Dennis Ritchie e insieme diedero vita a UNIX, nome suggerito da Brian Kernighan e nel 1973, Thompson riscrisse UNIX utilizzando il nuovo linguaggio C, ideato da Ritchie. In breve, siamo nel 1975, da questa prima versione viene scritto lo UNIX versione 6, il cui utilizzo si espande anche al di fuori dei laboratori Bell. A questo punto inizia un po’ di confusione: essendo un sistema operativo libero, Unix subisce una serie di mutazioni, rinascendo in differenti versioni, riscritte dai produttori di elaboratori per adattarle alle proprie macchine e spesso incompatibili fra di loro.
Non bisogna avere troppa fantasia per immaginare i problemi legati a questo sviluppo incontrollato: programmi scritti per una variante di Unix non era scontato che funzionassero su un’altra versione, amministrare un sistema Unix significava imparare le particolarità legate alla implementazione di ogni singolo produttore. Insomma, non era vita facile per programmatori, amministratori e nemmeno per i produttori che desideravano fornire insieme al proprio Unix un programma creato per qualche altro sistema, sempre chiamato Unix ma incompatibile. Per ovviare al problema, nel 1984 viene fondata X/Open, una società il cui scopo consiste nel definire gli standard dei sistemi aperti. Nel 1987 AT&T, proprietaria del marchio UNIX, costituisce insieme a Sun, UNIX International, organismo deputato alla definizione degli standard Unix. A complicare maggiormente la questione, gli altri produttori di Unix danno vita alla Open Software Foundation, il cui scopo è, neanche a dirlo, la definizione di standard Unix. Facciamo un salto al 1993, quando AT&T trasferisce le attività legate a Unix alla società UNIX Systema Laboratories, che vende a Novell. A sua volta, Novell vende il marchio X/Open e, nel 1995, cede i laboratori di sviluppo Unix, la cui versione viene definita UnixWare, a SCO. Nel 1996, X/Open e Open Software Foundation si fondono, creando The Open Group, il nuovo organismo deputato alla definizione degli standard UNIX, che da questa fusione eredita gli standard creati da X/Open, per primo il 1770, seguito da UNIX 95 e da Single Unix Specification Versione 2, per passare nel 1998 alla creazione di UNIX 98 e nel 2001 a Unix 03.
Per potersi definire Unix, un sistema operativo deve aderire agli standard UNIX definiti da The Open Group, ricevere la certificazione e quindi acqusisce il diritto di utilizzare il marchio UNIX.
Quei sistemi operativi che non aderiscono integralmente alle specifiche definite da The Open Group, o non vogliono investire il denaro necessario a garantirsi l’utilizzo del marchio UNIX, non possono definirsi sistemi operativi Unix, anche nel caso in cui, come per GNU/Linux, l’ambiente agisca proprio come Unix.
Insomma, GNU/Linux non è certificato UNIX e quindi non può essere definito un sistema Unix, non può ustilizzare il lorgo ma agisce come Unix. Un bel gioco di parole per dire che GNU/Linux non può essere chiamato Unix, ma quando ci si lavora sembra proprio di utilizzare Unix.
Alcuni preferiscono definire GNU/Linux un sistema aderente alle specifiche POSIX, Portable Operating System Interface, un insieme di specifiche, elaborate dal PASC (Portable Applications Standard Committee), comitato dello IEEE, Institute of Electrical and Electronics Engineers, emanate nel 1988 nella prima versione.
POSIX, termine coniato da Richard Stallman, è un insieme di API (Application Program Interface), che consentono di definire una interfaccia standard al sistema operativo e all’ambiente, il che si concretizza nello sviluppo di un interprete, ovvero una shell e di un insieme di utility comuni che facilitino la portabilità delle applicazioni a livello di codice sorgente e non di binario.
Ora, se non è possibile definire GNU/Linux un sistema UNIX, data la mancanza di una certificazione ufficiale da parte del The Open Group e se la definizione Unix-like appare abbastanza ambigua, nell’indicare qualcosa che è come qualcos’altro ma non lo è, indicare GNU/Linux come sistema POSIX compliant può far sorgere quantomeno una qualche ilarità. Nessun dubbio, GNU/Linux aderisce alle specifiche, quindi la definizione è calzante. Aggiungiamo, però, che anche altri sistemi operativi, come VMS, MVS, MPE sono sistemi aderenti alle stesse specifiche. Concludiamo che anche Microsoft Windows NT, per esempio, aderisce a POSIX. GNU/Linux e Windows NT possono essere accomunati sotto le stesse specifiche? Si. Quindi, forse meglio lasciare da parte un sistema di classificazione che non fa direttamente riferimento al sistema operativo, per evitare gustosi equivoci.

Hardening Apache, download e installazione

Aprire una porta su internet, lasciare che ignoti visitatori entrino e diano uno sguardo nell’anticamera del vostro server è sicuramente un’operazione affascinante e, spesso, utile. Un server web dovrebbe proprio servire a questo, a creare uno spazio destinato ad accogliere le richieste più diverse, a mostrare le informazioni che si vogliono condividere. Con il tempo, però, le esigenze sono cresciute, sono divenute più sofisticate, tanto che il semplice HTML è diventato un linguaggio inadeguato ai nuovi scopi: pagine dinamiche, applicazioni su web, portali, weblog e tutta la teoria di strumenti interattivi ha reso più sofisticati i siti e più complessi i server web alle loro spalle.
Apache è un ottimo esempio di server versatile, potente e, tutto sommato, semplice da configurare: può essere utilizzato da un utente di media esperienza per gestire il proprio sito Internet, come lo si può riscontrare in portali o siti di classe enterprise a servire intranet ed extranet più simili a vere e proprie applicazione browser-driven che a pagine di consultazione. Proprio la notevole interattività delle applicazioni che possono essere costruite attorno a un web server ha portato all’emergere, nel corso degli anni, di una serie di problematiche legate alla sicurezza sia del framework, Apache, che dei programmi, scritti nei più disparati linguaggi, dal Perl o C, per esempio, alle pagine PHP o JavaScript. Insomma, all’aumentare dell’interattività delle pagine web è corrisposta una crescita considerevole dei problemi legati alla sicurezza e delle contromisure che un amministratore di sistema deve essere in grado di porre in campo per assicurare una discreta sicurezza alle proprie installazioni.

Sicurezza stratificata

Cosa comporta mettere in sicurezza un web server?
Il problema, come spesso accade, si riflette su diversi livelli di amministrazione su un server:

  1. Mettere in sicurezza il sistema operativo;
  2. Mettere in sicurezza il framework (Apache);
  3. Mettere in sicurezza le applicazioni.

In questa occasione tralasceremo la sicurezza relativa al sistema operativo, un’operazione decisamente complessa che richiederebbe un intero ciclo di articoli a se stante. Di passaggio possiamo solo fornire un suggerimento: una prima soluzione potrebbe consistere nel ricompilare il kernel utilizzando le patch grsecurity (www.grsecurity.net), impostando un alto livello di protezione. Non è la soluzione ottimale, dato che la difesa di un sistema operativo si basa anch’essa su più livelli di intervento, che vanno dalla ricompilazione dei sorgenti degli applicativi alle operazioni, almeno le più elementari, di auditing; però, l’installazione di grsecurity può essere un primo punto di approccio al problema, dal quale partire e approfondire in seguito.

Ciò che qui ci interessa è, primariamente, rendere più affidabile Apache, partendo dalle “radici” del problema, iniziando a lavorare a livello di sorgente, per assicurarci della bontà del programma e per mettere in gioco qualche diversivo in grado di disorientare i malintenzionati meno ferrati in materia di sicurezza.

Il nostro primo passo sarà, quindi scaricare i sorgenti di Apache: è indifferente quale si decida di utilizzare, se appartenente alla versione 1.x o alla 2.x.

Verifichiamo i sorgenti

La prima buona pratica da tenere a mente è quella di preferire i server ufficiali del progetto Apache come fonte dalla quale scaricare i sorgenti sui quali si vuole lavorare. E’ una semplice questione di sicurezza: è decisamente più difficile per qualche malintenzionato penetrare in queste macchine piuttosto che in un computer gestito in maniera amatoriale da qualche volenteroso.

Una volta ottenuti i sorgenti, proseguiamo con una verifica della loro bontà: ogni sorgente fornito ufficialmente dal progetto Apache viene firmato digitalmente dal gestore della versione rilasciata e quindi bisognerà provvedere a scaricare sia le firme PGP che gli hash MD5.

Nel nostro esempio utilizzeremo i sorgenti contenuti nell’archivio:

httpd-2.0.54.tar.gz

Una volta scaricato il sorgente, dobbiamo prelevare anche la relativa firma PGP e l’hash MD5:

httpd-2.0.54.tar.gz.md5
httpd-2.0.54.tar.gz.asc

Provvediamo a confrontare la firma ottenuta con i sorgenti scaricati, utilizzando un tool di gestione quale potrebbe essere GNU Privacy Guard:

~$ gpg httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: Impossibile controllare la firma: chiave pubblica non trovata

Qui incontriamo il primo ostacolo. Non possiamo controllare la bontà dei sorgenti, dato che non abbiamo la chiave pubblica corrispondente. Da notare che l’identificativo della chiave pubblica messa a disposizione dal gestore di questa versione dei sorgenti per verificare la loro integrità è:

DE885DD3

Il problema è di facile soluzione: basterà utilizzare un gestore pubblico di chiavi per scaricare quella corrispondente all’identificativo indicato. Nel nostro caso useremo keyserver.linux.it, il quale è fornito anche di una comoda interfaccia web che facilita notevolmente il compito a chi si trova un po’ a disagio nell’utilizzo di gpg:

~$ gpg --keyserver keyserver.linux.it --recv-key DE885DD3
gpg: requesting key DE885DD3 from hkp server keyserver.linux.it
gpg: key DE885DD3: public key "Sander Striker " imported
gpg: non è stata trovata alcuna chiave definitivamente affidabile
gpg: Numero totale esaminato: 1
gpg: importate: 1

Abbiamo installato la chiave pubblica che ci interessa, prendendola da keyserver.linux.it: dato che i key server sono interconnessi fra di loro e si scambiano le chiavi, ognuno può scegliere quello che ritiene migliore e più affidabile.

Possiamo ora verificare che la firma apposta ai sorgenti sia buona e lo faremo utilizzando la chiave fornita da Sander Striker tramite il key server:

$ gpg httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: Good signature from "Sander Striker "
gpg: aka "Sander Striker
"
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata!
gpg: Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3

Attenzione. Abbiamo una buona e una cattiva notizia:

  • La buona notizia consiste nel fatto che la firma sui sorgenti è buona;
  • La cattiva è che la chiave con cui abbiamo gestito la verifica non è affidabile.

Chiunque potrebbe creare un chiave pubblica corrispondente a una firma falsa sui sorgenti scaricati e indurci a credere che sia tutto a posto. Dobbiamo fare un passo ulteriore: siamo costretti a verificare che la chiave connotata dall’identificativo DE885DD3 sia stata creata davvero da Sander Striker, ovvero dobbiamo validarla:

$ gpg --fingerprint DE885DD3
pub 1024D/DE885DD3 2002-04-10
Key fingerprint = 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3
uid Sander Striker
uid Sander Striker

sub 2048g/532D14CA 2002-04-10

In questo caso abbiamo verificato l’impronta della chiave che abbiamo scaricato, ma nemmeno questo è sufficiente. Ciò che ci potrebbe aiutare è entrare in un web of trust, ovvero costruire una rete di referenti affidabili, da cui abbiamo ricevuto direttamente l’impronta delle loro chiavi e quindi siamo sicuri della loro identità. Se una delle maglie di questa rete ci porta a qualcuno che ha firmato la chiave di Sander Striker, potremo considerare affidabile la chiave di quest’ultimo e tutte le chiavi da lui firmate. Il metodo più affidabile per verificare la chiave di qualcuno è scambiare l’impronta “de visu”, in modo da essere sicuri di chi ci sta fornendo l’informazione, ma questo è possibile solo per i nostri referenti diretti. Per poter ovviare al problema di incontrare faccia a faccia Sander Striker, operazione difficile e scomoda, possiamo scaricare dal sito del progetto Apache il file

http://www.apache.org/dist/httpd/KEYS

contenente le chiavi pubbliche degli sviluppatori di Apache. Dato che gli sviluppatori hanno firmato reciprocamente le loro chiavi, considerando valide le chiavi pubbliche di uno, verranno considerate valide tutte:

$ gpg --edit-key DE885DD3
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

gpg: controllo il trustdb
gpg: non è stata trovata alcuna chiave definitivamente affidabile
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: undefined validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker

Comando> trust
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: undefined validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu

Cosa hai deciso? 5
Do you really want to set this key to ultimate trust? (y/N) y

pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: ultimate validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker

Nota che la validità della chiave indicata non sarà necessariamente corretta
finchè non eseguirai di nuovo il programma.
Comando> quit

A questo punto, la chiave di Sander Strike è considerata valida a tutti gli effetti. Proviamo ora a verificare i sorgenti:

$ gpg --verify httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0 valid: 1 signed: 3 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 3 signed: 9 trust: 3-, 0q, 0n, 0m, 0f, 0u
gpg: Good signature from "Sander Striker "
gpg: aka "Sander Striker

La firma è considerata valida ed è stata utilizzata una chiave valida. Ovviamente, se riuscite a farvi dare l’impronta della chiave di prima mano, anche tramite un vostro buon web of trust, l’operazione è da considerarsi ancora più sicura.

Un secondo metodo per controllare l’integrità dell’archivio contenente i file sorgente è costituito nella verifica della sua firma MD5. Senza addentrarci troppo nei dettagli tecnici, possiamo definire la firma MD5 come una stringa a 128 bit (hash) generato in base a una stringa di partenza variabile. Data la stessa stringa di partenza, si otterrà sempre la stessa stringa di arrivo, ma non è vero il contrario: dal codice ottenuto non si può risalire alla stringa di partenza. Quindi, siamo di fronte a un algoritmo definito one way, che non consente praticamente a un malintenzionato di alterare i dati di partenza senza che questi si riflettano nel codice di controllo. E nemmeno è praticamente fattibile creare due stringhe di partenza che diano lo stesso hash finale. Insomma, data l’alta improbabilità di poter alterare la stringa di partenza senza che ciò alteri anche il codice di controllo, è possibile usare la l’algoritmo MD5, dandogli come input l’archivio contenente i file sorgente di Apache, per poi controllarne la stringa di hash con quella generata fornita tramite il sito del progetto: se i due hash corrispondono vi è una probabilità molto alta, talmente alta da dare una certezza pratica, che il file in nostro possesso non sia stato alterato. Controlliamo quindi la firma del nostro file, generandola tramite l’utility md5sum, contenuta nel pacchetto textutils, riversandola in un file temporaneo che confronteremo tramite diff con il file scaricato dal sito di Apache:

$ cat httpd-2.0.54.tar.gz.md5
772503748ffb85301385d47fb2b96eca httpd-2.0.54.tar.gz
$ md5sum httpd-2.0.54.tar.gz > verifica
$ diff verifica httpd-2.0.54.tar.gz.md5
$

L’output generato da diff è nullo, quindi i due file sono identici e ciò significa che la firma generata dal file in nostro possesso è identica alla firma generata con la copia ufficiale di Apache, quindi vi è un’alta probabilità che anche i due file di partenza siano identici.

Patchwork

Una volta ottenuti dei sorgenti affidabili, è necessario assicurarsi che questi siano privi di bachi sensibili.
Il primo accorgimento per evitare problemi nascosti nei sorgenti, consiste puntare all’URL http://archive.apache.org/dist/httpd/patches/ o a un mirror affidabile e aggiornato e controllare se per la versione in proprio possesso esiste una patch critica, che va quindi scaricata nella directory dei sorgenti e applicata utilizzando il comando:

patch -s < nome_patch.patch

Questo primo passo è necessario ma non sufficiente a garantire che i sorgenti siano privi di bachi importanti, dato che questi spesso vengono rilevati a distanza dal loro rilascio, evidenziati durante l'utilizzo su numerose installazioni. Per evitare di rimanere con un server afflitto da bachi è necessario rimanere sempre aggiornati sullo sviluppo dei sorgenti, iscrivendosi alla mailing list announce@httpd.apache.org

(che è più bollettino che mailing list vera e propria, dato che vi circolano solo gli annunci di nuove versioni o di patch, inviati dalla Fondazione). Se vi saranno aggiornamenti critici, una volta iscritti questi arriveranno comodamente nella vostra casella postale, mettendovi al riparo da future, sgradite sorprese.

Mistificazioni

Resistere all’attacco di un malintenzionato in gamba è decisamente difficile, ma togliersi di torno l’improvvisato di turno non è un’operazione che richieda grandi sforzi. Un semplice trucco per confondere le acque a chi stia cercando di collezionare più informazioni possibile sul nostro server, come per esempio la versione utilizzata (utile per cercare bachi non patchati), quale PHP o libreria SSL vengano implementate, è abbastanza semplice e richiede la modifica di un solo file header nei sorgenti.

Apache 1.x

Nella configurazione standard, Apache è decisamente “chiacchierone” e rivela fin troppo facilmente la propria versione e i vari moduli compilati, consentendo a chiunque, semplicemente richiamando una pagina esistente, di sapere se sono installati i moduli PHP e SSL e le relative versioni, per esempio. Troppo semplice e troppo invitante soprattutto per uno “script kiddie”, uno smanettone senza troppe competenze ma fornito all’inverosimile di script e programmi in grado di condurre autonomamente una vasta serie di attacchi.
Il nostro scopo, ora, consiste non solo e non tanto nell’ammutolire Apache, ma nel renderlo menzognero, facendogli dire qualche piacevole fandonia. Per raggiungere questo risultato, con i sorgenti della versione 1.x, basterà modificare il file

httpd.h

Nel nostro esempio, utilizzeremo i sorgenti contenuti nell’archivio

apache_1.3.33.tar.gz

Una volta decompresso, entriamo nella directory

apache_1.3.33/src/include

e apriamo in file httpd.h, nel quale troveremo alcune righe interessanti:

#define SERVER_BASEVENDOR "Apache Group"
#define SERVER_BASEPRODUCT "Apache"
#define SERVER_BASEREVISION "1.3.33"

#define APACHE_RELEASE 10333100
#define SERVER_SUPPORT "http://www.apache.org/"

Sono le informazioni contenute in queste direttive a essere utilizzate per generare i messaggi “di sistema” mostrati ai navigatori. Modifichiamoli leggermente:

#define SERVER_BASEVENDOR "Suppa Lovva Group"
#define SERVER_BASEPRODUCT "Lovva Server"
#define SERVER_BASEREVISION "1.2.3.4.x.x.x"

#define APACHE_RELEASE 99887766554433221100
#define SERVER_SUPPORT "http://www.suppalovva.net"

Ora basterà lanciare un semplice

./configure
make
make install

dalla directory radice dei sorgenti, avviare il server, richiamare una pagina inesistente e il risultato sarà quello visibile nella figura sottostante.

Lovva Server
Il nostro server appare decisamente strano. Suppa Lovva?

Apache 2.x

In Apache 2.x si può ottenere lo stesso risultato modificando un differente file. Nel nostro esempio, abbiamo decompresso l’archivio httpd-2.0.54.tar.gz, editando il file

httpd-2.0.54/include/ap_release.h

Al suo interno, ritroviamo delle stringhe decisamente familiari:

#define AP_SERVER_BASEVENDOR "Apache Software Foundation"
#define AP_SERVER_BASEPRODUCT "Apache"
#define AP_SERVER_MAJORVERSION "2"
#define AP_SERVER_MINORVERSION "0"
#define AP_SERVER_PATCHLEVEL "54"

Modifichiamole a piacere:

#define AP_SERVER_BASEVENDOR "Free Love Foundation"
#define AP_SERVER_BASEPRODUCT "StupidCupid"
#define AP_SERVER_MAJORVERSION "99"
#define AP_SERVER_MINORVERSION "00"
#define AP_SERVER_PATCHLEVEL "11"

Compiliamo i sorgenti, installiamoli, lanciamo Apache e richiamiamo una pagina inesistente. Il risultato sarà quello mostrato nella figura sottostante.

Stupid Cupid
Volendo giocare con gli header si possono apportare parecchie modifiche

Gli amministratori con uno spiccato senso dello humor potrebbero avere già inteso cosa si può fare giocando con gli header: basta modificare poche righe per simulare le risposte di IIS o di qualche altro server web a piacere.

La direttiva ServerTokens

Se vogliamo rendere la vita ancora più difficile al malintenzionato di turno, possiamo giocare un po’ con la configurazione del file httpd.conf, abilitando la direttiva ServerTokens, che gestisce la quantità di informazioni sul server restituite dagli header inviati da Apache ai client. Questa direttiva, però, è disponibile solo dalla versione 1.3 del server – ovviamente esiste anche nella 2.x, e accetta una serie di modificatori:

  • ServerTokens Prod(uctOnly)
    Viene inviato solo il nome del web server, per es: Server: Apache Server;
  • ServerTokens Min(imal)
    Viene inviata anche la versione, per es.: Apache/1.3.33 Server;
  • ServerTokens OS
    Viene inviato anche il tipo di sistema operativo: per es. : Apache/1.3.33 (Unix);
  • ServerTokens Full (o senza argomento)
    Vengono inviati tutti i dati possibili, compresi quelli relativi ai moduli compilatiServer sends (e.g.): Server: Apache/1.3.33 (Unix) PHP/5.0.5

Attenzione però: questa direttiva può essere abilitata solo a livello di server e non può essere modificata nei singoli host virtuali eventualmente configurati.

Prima di compilare

Questo primo articolo sulla sicurezza in Apache si chiude con un consiglio di buona condotta al momento di configurare i sorgenti per la compilazione del server. Seguendo il sempre valido motto KISS, Keep It Simple Stupid, cerchiamo di mantenere il più semplice possibile i binari installati sul nostro sistema. Certo, compilare monoliticamente o a moduli dinamici tutte le funzioni aggiuntive di Apache può risultare comodo: prima o poi potrebbero servire e non bisogna nemmeno ricompilare. Per una maggiore sicurezza, però, è meglio non avere in giro funzionalità che non vengono utilizzate, magari lasciate attivate per una dimenticanza: meglio non compilare nemmeno ciò che non serve. Già, ma cosa serve? Quali sono i moduli di base, il minimo indispensabile per avere un server web funzionale? Ecco quale è l’insieme minimo di moduli da installare per poter servire pagine senza troppi fronzoli:

  • httpd_core
    Modulo con le funzionalità di base, necessarie all’avvio di Apache;
  • mod_access
    Modulo che presiede alle direttive Allow, Deny e Order per l’accesso condizionato ai namespace;
  • mod_auth
    Modulo che offre l’autenticazione HTTP di base;
  • mod_dir
    Modulo che consente di implementare la direttiva DirectoryIndex, per indicare il file index di una directory;
  • mod_log_config
    Modulo per l’mplementazione delle funzioni di logging;
  • mod_mime
    Gestisce i set di caratteri l’encoding dei contenuti, il linguaggio predefinito delle pagine da servire e i tipi MIME dei documenti e altro ancora. Insomma, gestisce tutte le meta informazioni riguardanti le pagine servite.

Da disabilitare assolutamente, se non utilizzati:

  • mod_auto_index
    Consente di visualizzare il contenuto di una directory priva di file di indice;
  • mod_info
    Fornisce una lista di informazioni sul server, sui moduli compilati e sulle direttive di configurazione.

Conclusioni

Per ora abbiamo finito. Siamo arrivati fino alla configurazione dei sorgenti e compilazione del server. Nel prossimo articolo, approfondiremo quelle direttive di configurazione di Apache, che ci consentiranno di applicare delle direttive sufficientemente restrittive per limitare ragionevolmente la maggior parte degli attacchi più triviali.
Una volta configurato in maniera sicura il nostro server, lo sbatteremo in cella, in una chroot jail, dal quale un eventuale aggressore non uscirà molto facilmente.

Quanto è sicuro il vostro antivirus?

Av-test.org

Non si è ancora spenta l’eco del baco nei file WMF, che AV-Test ?? mette al banco di prova i più diffusi antivirus, sottoponendo loro ben 73 varianti degli exploit che si possono trovare in giro per la rete e che sfruttano la falla aperta dal formato grafico WMF. Quali antivirus sono riusciti a identificare tutti e 73 file come exploit e quindi come dannosi per il sistema operativo?

  • Alwil Software (Avast)
  • Softwin (BitDefender)
  • ClamAV
  • F-Secure Inc.
  • Fortinet Inc.
  • McAfee Inc.
  • ESET (Nod32)
  • Panda Software
  • Sophos Plc
  • Symantec Corp.
  • Trend Micro Inc.
  • VirusBuster

Questi altri, invece, ne hanno riconosciuti solo alcuni…

  • 62 — eTrust-VET
  • 62 — QuickHeal
  • 61 — AntiVir
  • 61 — Dr Web
  • 61 — Kaspersky
  • 60 — AVG
  • 19 — Command
  • 19 — F-Prot
  • 11 — Ewido
  • 7 — eSafe
  • 7 — eTrust-INO
  • 6 — Ikarus
  • 6 — VBA32
  • 0 — Norman

Ahem…fate vobis. Io vi do un suggerimento: Clamav è gratuito, libero ed è disponibile per diversi sistemi operativi, tra i quali Windows, Linux e Mac OSX.

[Via eWeek]