Il peggio è passato, tanti i post pubblicati (date una occhiata qui), chi più e chi meno tempestivamente “sul pezzo“. Twitter ha subito nella giornata di ieri un attacco XSS, forse meglio conosciuto come Cross-site scripting.

In breve, ecco di cosa si tratta:

Il Cross-site scripting (XSS) è una vulnerabilità che affligge siti web dinamici che impiegano un insufficiente controllo dell’input (parametri di richieste HTTP GET o contenuto di richieste HTTP POST). Un XSS permette ad un attaccante di inserire codice al fine di modificare il contenuto della pagina web visitata. In questo modo si potranno sottrarre dati sensibili presenti nel browser degli utenti che visiteranno successivamente quella pagina. Gli attacchi alle vulnerabilità XSS hanno effetti dirompenti per i siti con un elevato numero di utenti, dato che è sufficiente una sola compromissione per colpire chiunque visiti la stessa pagina.

L’attacco è partito alle 2.54 ora del pacifico (PDT), in Italia ho visto spuntar fuori il primo thread su Friendfeed circa 24 ore fa grazie a Massimo Cavazzini. L’ultima mania per gente famosa e comune messo in ginocchio da un codice javascript tutto sommato semplice (volutamente messo su più righe qui di seguito):

http://t.co/@%22onmouseover=%22document.getElementById(%27status%27)

.value=%27RT%20Matsta%27;$(%27.status-update-form%27).submit();
%22class=%22modal-overlay%22/

All’evento “onMouseOver” (semplice passaggio del mouse) sarebbe partito un retweet dell’ultimo messaggio dell’utente “Matsta“ (analizzato nell’esempio), innescando così un meccanismo bloccato da Twitter solo alle 7 ora del pacifico (una discreta manciata di ore dopo).

Secondo il blog ufficiale del servizio si tratta di un vecchio bug, già patchato ma tornato “disponibile” in seguito ad un aggiornamento di piattaforma che non ha nulla a che fare con il nuovo Twitter che sta per arrivare:

We discovered and patched this issue last month. However, a recent site update (unrelated to new Twitter) unknowingly resurfaced it.

Durante l’attacco anche Graham Cluley (Sophos) si è mosso realizzando un articolo che documentasse l’accaduto con immagini e casistiche varie.

Chiunque abbia utilizzato nel frattempo il sito “mobile” di Twitter non ha riscontrato alcun problema, lo stesso vale per chiunque abbia utilizzato un client di terze parti. Il consiglio ovviamente è quello di appoggiarsi a questi client quotidianamente (siete già riusciti ad utilizzare almeno una volta Twimbow?) o -se proprio non potete farne a meno- utilizzare Firefox provvisto di NoScript di Giorgio Maone (ne ho parlato anche in vecchi miei articoli).

Un titolo piuttosto complesso, me ne rendo conto. Dato che a breve con molta probabilità Sophos Experts Italy sarà archiviato (numeri che poco convincono, collaborazione pressoché nulla, a meno che qualcuno non mi scriva in merito due righe a breve) ricomincio a scrivere articoli riguardanti le piattaforme Sophos sul mio blog, convinto che possano avere maggiore visibilità e andare ad arricchire la serie di articoli già pubblicati in passato.

Stavolta vorrei parlarvi di una casistica analizzata presso un cliente che ha deciso di aggiornare la sua console 3 passando alla nuova 4, basandosi su un sistema Windows Server 2008 a 64 bit (una configurazione che raramente vedo presso altre aziende, ancora oggi).

Il problema? Dopo l’upgrade del software installato sul server, i client hanno deciso di non aggiornarsi con i nuovi motori antivirus, motivo per il quale i clienti rimangono scoperti dal rilascio dei nuovi aggiornamenti da parte della nota azienda di sicurezza informatica. La risoluzione? Forzare un’installazione del nuovo antivirus nel momento in cui le macchine (gli utenti) fanno ingresso nel dominio.

A cosa appoggiarsi

Una stringa di controllo in Kix32 (software sempre più utilizzato, associato al netlogon) e un banale script batch che carichi il software necessario. La procedura è presto spiegata:

$PGRFILE=%Programfiles%+"\Sophos\Sophos Anti-Virus\SAVControl.dll"
if exist ($PGRFILE)
 ? "Antivirus Aggiornato" @CRLF
ELSE
 ? "Installo Antivirus" @CRLF
 ;shell '%comspec% /C '
 shell "cmd /c "+$LogonServer+"\netlogon\instSophos.bat /scrub"
ENDIF
EXIT

Perché il controllo su una DLL? Sophos 7 (versione dell’antivirus gestita dalla console 3) non ha tra i suoi file quella libreria. E’ invece presente tra i file di una installazione della versione 9 (gestita dalla console 4).

A questo punto sarà necessario rimuovere il precedente antivirus e partire con l’installazione del nuovo. Per andare ancora più sul sicuro ho preferito lanciare prima il CRT (Competitor Removal Tool) ed in seguito il setup:

@ECHO OFF
echo Verifica e installazione Sophos Antivirus ...
echo Non chiudere questa finestra.
echo;
REM --- Deploy to Windows 2000/XP/2003
\\SERVERSOPHOS\SophosUpdate\CIDs\S000\SAVSCFXP\crt\avremove.exe
\\SERVERSOPHOS\SophosUpdate\CIDs\S000\SAVSCFXP\Setup.exe -updp "\\SERVERSOPHOS\SophosUpdate\CIDs\S000\SAVSCFXP" -user "DOMINIO\AMMINISTRATORE" -pwd "PASSWORD" -mng yes
REM --- End of the script
:_End

L’operazione richiederà pochi minuti (a patto che le macchine non siano particolarmente datate o con risorse hardware molto limitate) e verrà ovviamente eseguita una sola volta per postazione. Il controllo (dalla seconda connessione al dominio) fallirà e l’utente avrà rapido accesso ai suoi dati ed al suo desktop.

Buon lavoro :)

Su giusto suggerimento di Paolo ho “rinnovato la linea mirror Sophos 09/10” :mrgreen:

# perché creare SnowLeopard?

Con l’avvento di Snow Leopard, Sophos ha realizzato e rilasciato una nuova versione del suo client antivirus. A seguito di questa scelta è stato necessario introdurre una nuova CID (Central Installation Directory) per la distribuzione degli aggiornamenti dedicati alla nuova versione del software, motivo per il quale la versione 7 (magari aggiornatasi automaticamente dalla 4) non riesce più a scaricare gli aggiornamenti da Storm.

sophos.com/support/knowledgebase/article/62329.html

# installare Sophos Antivirus

Come già specificato nel precedente paragrafo, Sophos ha pubblicato la nuova release 7.05 che funziona correttamente con Snow Leopard. Il mio consiglio è quello di disinstallare la vecchia 4.x e installare questa “da zero” ;)

Ancora una volta Sophos per Mac OS X è facilmente reperibile attraverso siti web specializzati nella tracciatura di applicativi dedicati al sistema operativo Apple. Uno tra i più utilizzati (anche dal sottoscritto) è sicuramente VersionTracker.com. Detto fatto, qui di seguito il collegamento alla pagina del pacchetto:

versiontracker.com/dyn/moreinfo/macosx/9815

Compatibile con:

• Mac OS X 10.4+ Intel (quindi anche 10.6 Snow Leopard sempre su Intel)

Se non avete un account registrato su Sophos.com diventa tutto più difficile, ma anche questa volta reperire l’applicativo “nudo” è stato semplice con una ricerca sul solito Google. Il pacchetto DMG occupa circa 50 MB.

# impostare SnowLeopard come mirror primario

Per l’installazione del nuovo client non cambia assolutamente nulla rispetto all’ultima volta che ho avuto modo di parlarvene (ricordate Storm?), la procedura è quindi disponibile nello stesso paragrafo del seguente articolo:

gioxx.org/2009/04/10/sophos-external-mirror-codename-storm

Chiaramente si tratta di andare a cambiare indirizzo per l’aggiornamento del client, cosa semplice se lo avete già fatto:

cliccare per ingrandire

Provando a salvare le impostazioni e lanciando un update forzato dovrebbe partire la verifica dell’indirizzo e -di conseguenza- del download :)

cliccare per ingrandire

Le restanti opzioni potete personalizzarle secondo le vostre esigenze.

# soddisfatti o rimborsati disinstallati

Non siete soddisfatti di Sophos Antivirus per Mac e volete disinstallarlo? Non sapete come procedere perché non basta spostare l’applicazione nel Cestino come fate solitamente? C’è uno script automatizzato che -una volta inseriti nome utente e password dell’amministratore della macchina- vi permetterà di non muovere più un dito e attendere che tutto venga eliminato senza lasciare tracce. Trovate il tutto dentro

Macintosh HD > Library > Application Support > Sophos Anti-Virus

o, in italiano (e cambia molto molto poco):

Macintosh HD > Libreria > Application Support > Sophos Anti-Virus

ed il gioco è fatto.

# avvertenze prima dell’utilizzo

SnowLeopard, così come Storm & Wolverine, è a vostra disposizione. Sono stati nuovamente modificati gli script che si preoccupano di aggiornare questo terzo mirror e funziona tutto correttamente con tanto di notifiche di successo / insuccesso comodamente recapitate nella mia mailbox (così che non sfugga nulla). Ancora una volta ribadisco che non si tratta di favorire la pirateria ma di proteggere quante più macchine possibili affidando il proprio hardware alla bontà del prodotto Sophos.

Questo ennesimo minuscolo progetto è in fase BETA persistente, potrei decidere di eliminarlo tra qualche giorno o tra qualche mese (anno? :P ) quindi non fateci cieco affidamento. Banda e spazio messo a disposizione dal sottoscritto e dall’allegra banda GxWare, fatene buon uso.

Per controllare la data dell’ultimo aggiornamento file potete fare riferimento alla seguente pagina:

users.gxware.org/snowleopard/version.php

Cheers.

Un processo troppo spesso sottovalutato è quello del backup, talvolta anche in azienda (sigh!). La colpa viene sempre data al poco tempo a disposizione, alla poca voglia forse, sporadicamente del non sapere dove / come / quando fare un backup. Oggi ho notato che ho predicato bene ma ho razzolato male fino all’ultimo momento, il server antivirus aziendale non effettuava regolare backup SQL quotidianamente.

Per questo motivo ho deciso di rimediare e mettere in piedi un processo automatico che svolge lo sporco lavoro ogni notte, operazione schedulata alle 3.00 per l’esattezza.

Mi sono servito ancora una volta di uno script batch, il 7-Zip Command Line Version, l’eseguibile sleep presente nel Windows 2003 Server Resource Kit e di un secondo batch già presente in tutte le installazioni di Sophos (%programfiles%\Sophos\Enterprise Console\DB\BackupDB.bat).

Prima di partire vi invito a copiare il 7za.exe ed lo sleep.exe all’interno della cartella Windows\System32 della vostra macchina, così da poter essere richiamati facilmente dal prompt di MS-Dos.

Lo script è davvero semplice, può essere salvato in qualsiasi posizione. Nel mio caso ho deciso di lasciarlo in %programfiles%\Sophos.

Prima il codice, poi la spiegazione :-)

@echo off
cls
echo Backup Database SOPHOS su macchina locale
echo;
echo Controllo esistenza cartella bck su disco C ...
echo;
if not exist C:\bck mkdir C:\bck
cd "%programfiles%\Sophos\Enterprise Console\DB"
echo Avvio procedura di backup Database ...
echo Tempo di attesa: 20 sec.
for /f "tokens=1-3 delims=/- " %%a in ('date /t') do set xdate=%%a_%%b_%%c
start /min BackupDB.bat C:\bck\sophos_%xdate%.sql SOPHOS
sleep 20
echo;
echo Backup effettuato.
echo;
echo Compressione con 7zip ...
echo;
7za.exe a -t7z -mx5 C:\bck\sophos_%xdate%.7z C:\bck\sophos_%xdate%.sql
echo;
echo Cancellazione file temporanei ...
del C:\bck\sophos_%xdate%.sql
echo;
echo Processo terminato

La cartella usata per tenere in piedi i backup è la C:\bck, potete tranquillamente cambiarla sostituendola nello script. Sappiate comunque che il batch di Sophos gestisce meglio i nomi di cartelle senza spazi al loro interno, regolatevi di conseguenza ;)

Per differenziare le versioni dei backup ho deciso di includere la data. Il parametro funzionante sotto DOS è “%date%” che però restituisce un valore come questo qui di seguito:

C:\Documents and Settings\Giovanni>echo %date%
24/07/2009

C:\Documents and Settings\Giovanni>

motivo per il quale diventa necessario sostituire quegli slash con qualcosa di più compatibile. Il ciclo for inserito nello script permette di farlo inserendo gli underscore perfettamente compatibili con il batch di Sophos (e con il mio!), generando un nuovo valore %xdate% richiamabile in qualsiasi momento.

Lo sleep.exe viene richiamato nel frattempo che va in funzione lo “start BackupDB.bat” che si preoccupa di effettuare in una finestra minimizzata il file SQL di esportazione dall’Enterprise Console. 20 secondi bastano e avanzano per un file che racchiude informazioni per un totale di circa 200 macchine. Nel vostro caso potrebbe essere necessario aumentare il numero di secondi (dipende da quanto è grande l’esportazione).

Il funzionamento (molto elementare) del batch BackupDB realizzato da Sophos è spiegato nel /? lanciato da DOS, lo riporto:

C:\Program Files\Sophos\Enterprise Console\DB>BackupDB.bat

Usage:
 BackupDB backup_file_path [instance_name]

C:\Program Files\Sophos\Enterprise Console\DB>

altrimenti bisognerebbe far riferimento alla procedura manuale, spiegata in un documento della KB Sophos.com all’indirizzo:

sophos.com/support/knowledgebase/article/27265.html

Finito il backup si passa alla compressione grazie alla riga di comando del 7za precedentemente copiato nella Windows\System32. La riga che lancia la compressione del file SQL indica all’applicativo la necessità di generare un file 7z (-t7z) con compressione normale dandogli lo stesso nome del file originale. Per conoscere tutti i segreti della riga di comando di 7za vi rimando ad un fantastico documento, davvero completo:

http://dotnetperls.com/7-zip-examples

Il processo di compressione potrebbe anche impiegare diversi minuti (15 / 20 talvolta) ma schedulando questo lavoro a notte fonda non penso ci siano grossi problemi di sovraccarico della macchina, giusto? ;-)

Come chicca finale si cancella il file *.SQL recuperando spazio sul disco e mantenendo solo il .7z compresso.

Basterà ora aggiungere alle Operazioni Pianificate del sistema il lancio quotidiano (o settimanale se più vi aggrada) del batch, all’ora esatta desiderata.

Cheers.

Giusto ad inizio settimana un collega mi ha richiesto una “automatizzazione di un processo” di installazione Sophos Antivirus su delle macchine virtuali (Thin client per la precisione), in un certo senso si parla di un fritto misto tra processi unattended e VDI (Virtual Desktop Infrastructure). C’è una scheda tecnica abbastanza dettagliata a tal proposito, nella KB del sito Sophos.com:

sophos.com/support/knowledgebase/article/28591.html

Riporta passo dopo passo le operazioni da compiere, fortunatamente semplici da replicare tramite batch senza l’intervento umano. Chiaramente il batch che si andrà a realizzare avrà la necessità di essere avviato come amministratori della macchina (locali o di dominio, non ha importanza), questo perché si richiamano delle stringhe di installazioni che verrebbero inibite ad un utente normale.

# la procedura da seguire

qui di seguito i passaggi suggeriti dalla documentazione ufficiale:

1. Install Sophos Anti-Virus to a client machine as if it was a fresh install.
2. After update has finished, stop the Sophos AutoUpdate service. (This prevents an update starting during the procedure, which would attempt to install the other components, breaking the image. The service will restart automatically at the end of the procedure.)
3. Go to the folder C:\Program Files\Sophos\Remote Management System, and make copies of the following files :
   • cac.pem
   • mrinit.conf
4. Go to ‘Add/Remove Programs’, and remove the following components :
   • Sophos Anti-Virus
   • Sophos Remote Management System
5. Delete the contents of the : C:\Program Files\Sophos\AutoUpdate\Cache folder
6. Delete the : C:\Program Files\Sophos\AutoUpdate\data\status\status.xml file
7. Re-create the : C:\Program Files\Sophos\Remote Management System folder, and add (to it) the copies of cac.pem, and mrinit.conf you made (above)
8. Now take the image

# il batch spiegato passo-passo

Tutto parte quindi da un’installazione pulita di Sophos Antivirus, da eseguire con procedura standard su una macchina che si vorrà utilizzare poi come master (clone) per le altre a venire.

Fermando il servizio AutoUpdate si eviteranno interventi da parte del server, condizione fondamentale durante il processo di preparazione:

echo *** Fermo il servizio Update ... ***
echo.
net stop "Sophos AutoUpdate Service"

si copiano quindi i file di configurazione del RMS (Remote Management System) fuori dalla cartella iniziale, basta la root della cartella dell’antivirus:

echo *** Copio file RMS ... ***
echo.
cd "%programfiles%\Sophos\Remote Management System"
copy cac.pem ..\cac.pem
copy mrinit.conf ..\mrinit.conf

e si procede con la disinstallazione di RMS e parte AntiVirus (lasciando solo -quindi- la parte AutoUpdate):

echo *** Disinstallo Sophos Antivirus ... ***
MsiExec.exe /X{034759DA-E21A-4795-BFB3-C66D17FAD183} REBOOT=SUPPRESS /qn 2>NUL
echo.
echo Eseguito.
echo.
echo *** Disinstallo Sophos Remote Management System ... ***
MsiExec.exe /X{FF11005D-CBC8-45D5-A288-25C7BB304121} REBOOT=SUPPRESS /qn 2>NUL
echo.
echo Eseguito.

una veloce pulizia della cartella Cache seguita a ruota dalla rimozione del file di status dell’ultimo update ricevuto:

echo *** Cancello cartella Cache ... ***
cd ..\AutoUpdate
rd Cache /S /Q
echo.
echo *** Cancello Status Update ... ***
cd data\status
del status.xml

per arrivare infine al ripopolamento della cartella RMS precedentemente disinstallato:

echo *** Popolo cartella Remote Management System ***
cd %programfiles%\Sophos
if not exist "Remote Management System" mkdir "Remote Management System"
move cac.pem "Remote Management System"
move mrinit.conf "Remote Management System"

il gioco è praticamente fatto, la macchina da clonare è pronta (provando ad immaginare che Sophos sia stato l’ultimo software da preparare per il master).

Sulla macchina clonata basterà attendere (o lanciare forzatamente) un aggiornamento del client per far partire immediatamente il download dei pacchetti mancanti con conseguente installazione, nome macchina differente (sicuramente) ma configurazioni praticamente identiche alla macchina che ha generato il clone.

Facile, comodo, veloce :-)

Buon lavoro!