Ricerche IT

Si prenda in considerazione uno scenario in cui si ha un server Windows Server 2003 con i Terminal Services installati ed un client Windows, diciamo Windows 2000 Professional o Windows XP Professional; in uno scenario del genere, per un motivo che ancora non ho capito, per il semplice motivo che mi rifiuto di capire la perversa politica di licensing di Microsoft, può capitare saltuariamente che uno di questi client, all’atto della connessione al server Terminal, dia questo errore:

The remote session was disconnected because there are no Terminal Server client access licenses available for this computer

La soluzione a questo problema che ho trovato non è certamente elegante, ma funziona, e consiste nel cancellare la chiave del registro di configurazione

HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing

In questo “posto” vengono archiviate le informazioni relative alla licenza client per la connessione ad un server con i Terminal Services abilitati. Cancellando questa chiave, si cancella quindi la licenza client, per cui, ritentando la connessione, viene installata nuovamente la licenza client e si riuscirà ad accedere nuovamente al server via RDP.

Sito di riferimento

http://www.chicagotech.net/netforums/viewtopic.php?p=936

Su un server Linux, uno strumento indispensabile per l’amministrazione del server stesso è il server SSH, come OpenSSH, tramite il quale possiamo avere un accesso sicuro alla shell del sistema operativo, per poter amministratore comodamente il nostro server Linux.

In ambiente Windows, un accesso SSH non è una cosa indispensabile, risulta più utile avere un accesso via Remote Desktop per amministrare il server, allo stesso tempo però, può comunque avere un senso l’accesso SSH su server Windows, un po’ per determinate operazioni da svolgere via riga di comando, un po’ per poter scaricare o caricare file da o sul server attraverso SCP e SFTP, che possono diventare comodi soprattutto se ci connettiamo al server in remoto, via VPN, oppure se dobbiamo amministrare o trasferire dati da una macchina Linux ad una macchina Windows, in questo modo non saremo costretti ad utilizzare X oppure ad installare Samba per il trasferimento dati da/verso Windows.

Per quanto concerne il software che funge da server SSH, ne esistono diversi, e direi che più o meno tutti sono un’implementazione di SSH in ambiente emulato Cygwin; io ne ho provati due, Freesshd e CopSSH, che rispondono a due esigenze diverse, in particolare, Freesshd fornisce l’ambiente di shell di Windows, mentre CopSSH fornisce un sottoinsieme dei comandi presenti nella shell Bash di Linux.

Personalmente, tra un’implementazione completa della shell di Windows come quella di Freesshd (che appunto richiama direttamente l’interprete dei comandi di Windows, cmd.exe) ed una che (secondo le mie prove, che ammetto non essere state esaustive) risulta, all’atto pratico, avere una parte dei comandi Bash ed una parte dei comandi di Windows, come accade con CopSSH, preferisco Freesshd; tanto per fare un esempio, con Freesshd riesco a vedere i processi in esecuzione con il comando tasklist, cosa che non riesco a fare con Copssh.

Per poter utilizzare un server SSH su Windows, l’utente col quale faccio il logon al server deve obbligatoriamente consentire l’accesso interattivo al server, se così non è, va modificata l’opportuna policy (si tratta di policies diverse a seconda se il server è controller di dominio oppure no) sul server Windows, e questo può comportare qualche problema di sicurezza in più, cosa che secondo me rappresenta il vero svantaggio dell’avere attivo un server SSH su Windows. Entrambi i software hanno una procedura che permette di specificare quali utenti definiti sul server Windows possono accedere via SSH al server stesso, va da sé che, se vogliamo amministrare decentemente il server Windows, dovremo accedere allo stesso con un’utenza amministrativa, se invece necessitiamo del solo SFTP, è sufficiente abilitare l’utente all’accesso, dopodiché saranno le autorizzazioni impostate sulle cartelle del server Windows a stabilire le possibili azioni dell’utente.

Tornando a FreeSSHD, l’installazione del prodotto è decisamente banale, basta cliccare sempre su Avanti (Next); durante l’installazione verrà creato il servizio FreeSSHDService, in modo che il “demone” sia sempre attivo, quindi dovremo accedere alla configurazione del programma, cliccando col tasto destro sull’icona del programma posta nella systray e, scegliendo la voce Settings dal menu contestuale, è possibile gestire il server SSH, e soprattutto, è possibile abilitare o disabilitare l’accesso SSH agli utenti di Windows tramite la scheda Users, come mostrato in figura 1:

Figura 1 - Scheda Users di FreeSSHD

A questo punto, è sufficiente utilizzare un client SSH come Putty in ambiente Windows, o utilizzando il comando ssh in ambiente Linux/Unix, e collegandosi al server (finora ho provato solamente con nome utente e password, senza utilizzare certificati) si può testare il corretto accesso al server Windows.

Purtroppo, per un motivo che non sono ancora riuscito a capire, al primo tentativo viene restituito l’errore “Incoming packet was garbled on decryption” con Putty oppure l’errore “Bad packet length” su Linux, seguito da un numero; la cosa strana è che tentando una seconda volta, senza cambiare nulla, la connessione avviene senza nessun problema, se qualcuno sa o ha idea da cosa possa dipendere, farebbe cosa molto gradita scrivendolo nei commenti.

Una volta verificato il corretto accesso al server Windows, è possibile configurare anche SFTP, andando a specificare nella configurazione di FreeSSHD qual è la directory root SFTP del server Windows tramite la scheda SFTP, come mostrato in figura 2:

Figura 2 - Scheda SFTP di FreeSSHD

Ora non ci resta che testare il corretto funzionamento di una connessione SFTP; per Windows, si possono utilizzare due programmi, WinSCP (che a dispetto del nome consente anche la connessione SFTP) e FileZilla, il quale, oltre alle normali connessioni FTP, permette di stabilire connessioni SFTP basandosi sull’onnipresente Putty.

Questa configurazione, secondo le prove che ho potuto fare, funziona abbastanza bene, con alcuni difetti: per prima cosa, ho letto sul Web che FreeSSHD peccherebbe un po’ in stabilità, finora io non ho avuto problemi, ma non ne ho fatto un uso intensivo; secondariamente, per quanto riguarda SFTP, l’unica configurazione possibile riguarda la root directory accessibile dagli utenti, impedendo agli stessi di poter accedere alle cartelle di livello superiore, e ciò è positivo dal punto di vista della sicurezza, poiché in questo modo si possono abilitare diversi utenti che comunque non hanno la possibilità di gironzolare per il disco, però, allo stesso tempo, questa impostazione riguarda TUTTI gli utenti, per cui anche gli utenti con privilegi amministrativi, utilizzando SFTP, non possono operare ad un livello superiore rispetto alla home directory, anche se, in realtà, utilizzando Linux, è possibile superare questa limitazione utilizzando scp, per poterlo fare però bisogna conoscere il percorso esatto del file da prelevare; altra limitazione, la shell fornita per default da FreeSSHD è quella di Windows, per cui WinSCP non funziona in modalità SCP, funziona però perfettamente in modalità SFTP.

In conclusione, installare un server SSH su Windows, è utile, secondo me, solo in determinate occasioni, soprattutto se da client Linux dobbiamo accedere o condividere file con un server Windows, oppure può risultare utile su connessioni remote particolarmente lente, altrimenti, secondo me è più utile utilizzare Remote Desktop, utilizzabile anche da Linux tramite il pacchetto rdesktop.

Recentemente mi è accaduta una cosa curiosa, su un PC di un utente, facendo doppio click su un file Excel con estensione .xls, si apre normalmente Excel ma non viene aperto il file, senza nessuna notifica o messaggio d’errore da parte del programma. Provando a cliccare col tasto destro sul file, selezionando la voce "Apri con…" e scegliendo Microsoft Excel dall’elenco, viene visualizzato un messaggio d’errore che indica l’impossibilità di trovare il percorso del file. Se invece si apre Excel, e si va su File -> Apri selezionando dalla finestra di dialogo il file da aprire, la cartella di lavoro si apre normalmente.

Per ritornare ad una situazione decente, è sufficiente andare nelle opzioni di Excel (menu Strumenti -> Opzioni), andare sulla scheda Generale e deselezionare la casella "Ignora altre applicazioni". Se invece si possiede una copia di Excel 2007, bisogna cliccare sul pulsante di Office (cioé la riedizione del pulsante Start di Windows in salsa Office), quindi andare su Opzioni, Avanzate e lì, nell’area Generale, deselezionare la casella "Ignora altre applicazioni".

Così facendo, la cartella di lavoro si aprirà normalmente con un semplice doppio click sul file Excel.

Link di riferimento
http://support.microsoft.com/kb/211494

La corretta gestione dell’ora dei sistemi è molto importante in una rete con un dominio Active Directory, poiché il protocollo di autenticazione predefinito, Kerberos, richiede che l’ora di server e client sia sincronizzata, pena la possibile mancata autenticazione del client, il quale non sarà quindi in grado di fruire dei servizi erogati dal/dai server.

In primis, è buona norma configurare il domain controller che svolge il ruolo di master operazioni PDC in modo tale che prenda l’ora da un riferimento esterno; utilizzando il protocollo Network Time Protocol (NTP), il controllore di dominio sincronizza l’ora, tramite il servizio "Ora di Windows" (W32Time) , con uno o più server NTP, accessibili tramite la rete Internet. Per sincronizzare il controllore di dominio con una o più fonti esterne, è possibile utilizzare la metodica descritta in un precedente articolo. Il passo successivo riguarda la sincronizzazione dei client: se si tratta di postazioni Windows XP e, direi (ma non ho ancora avuto esperienza diretta), Windows Vista, che sono iscritte nel dominio, l’ora sarà sincronizzata automaticamente per impostazione predefinita, prendendo come riferimento il domain controller in questione. Lo stesso avviene per server membri e controller di dominio Windows 2003. Il protocollo utilizzato per questo tipo di sincronizzazione non è NTP ma NT5DS.

In alcuni casi, è possibile che il domain controller non riesca a sincronizzarsi con il/i server NTP, in tal caso, bisogna cercare di capire come mai questo avviene. Il primo passo da seguire, è verificare se non esiste già un’applicazione che utilizza la porta UDP 123, con il comando:

netstat -noa | find "123"

Se ci viene restituita una riga in cui compare un’applicazione che utilizza la porta UDP 123, bisogna segnarsi il PID (Process ID) del processo in questione (ad esempio, 4127), quindi, si utilizza il comando tasklist per identificare quale processo sta utilizzando la porta 123:

tasklist | find "4127"

e così sapremo quale applicazione utilizza la porta 123.

Se invece non risulta nessuna applicazione che utilizza la porta UDP 123, dovremo cercare di capire che avviene durante la sincronizzazione dell’ora. A tal fine, si può abilitare la registrazione del debug del servizio Ora di Windows, andando ad aggiungere alcuni parametri nella chiave del registro di sistema

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Questi parametri consistono nell’aggiunta di nuovi valori stringa chiamati FileLogSize, FileLogName e FileLogEntries, i cui dati valore sono indicati nella relativa pagina della Knowledge Base Microsoft. Dopo aver aggiunto questi valori, riavviare il servizio Ora di Windows col comando

net stop w32time && net start w32time

quindi digitare il comando

w32tm /resync

per forzare la sincronizzazione dell’ora. Fatto ciò, bisogna aprire con un editor di testo il file specificato precedentemente nel parametro FileLogName del servizio Ora di Windows, che ci mostrerà le varie operazioni svolte durante la sincronizzazione, sperando che ciò ci sia d’aiuto per risolvere i problemi di sincronizzazione dell’ora.

Windows Server 2003 R2 integra ed estende le funzionalità di Distributed File System (d’ora in poi DFS), il componente che permette di gestire file system distribuiti tra più host in una rete Windows. In particolare, quest’articolo tratta della creazione di uno spazio dei nomi DFS su due server domain controller (d’ora in poi DC) Windows Server 2003, della creazione di cartelle e relative sottocartelle, in modo da avere più share distribuite su due server, situati su due diverse LAN e nei relativi siti Active Directory (d’ora in poi AD), LAN connesse tra di loro tramite un collegamento geografico a bassa velocità; la situazione viene mostrata in figura 1:

Figura 1

Il primo DC è DCServer, che ha indirizzo IP 172.16.1.1 sulla rete 172.16.1.0/24, il secondo DC è Coriolis, che ha indirizzo IP 192.168.1.10 sulla rete 192.168.1.0/24; ognuno dei due server funge da Global Catalog per il proprio sito AD di appartenenza.

In breve, un namespace (spazio dei nomi) DFS consente di avere più cartelle condivise su più server che fanno parte di un unico contenitore, il namespace appunto, che sarà accessibile dagli host del dominio secondo una struttura che viene impostata dall’amministratore di rete; così facendo, gli utenti di rete non dovranno preoccuparsi di sapere su quale server è situata una risorsa condivisa, semplicemente, l’unica cosa che dovranno conoscere è la struttura del namespace, che diventa l’unico "repository" logico dell’intera struttura dati aziendale; nella situazione descritta all’inizio dell’articolo, si noterà la differenza tra cartelle residenti sulla propria LAN e le cartelle residenti sul server remoto, unicamente in funzione della velocità di accesso alle cartelle stesse, dove ovviamente il browsing delle cartelle poste sul server remoto sarà notevolmente più lento. Si comprenderanno meglio questi concetti una volta messo in funzione lo spazio dei nomi DFS.

Per attivare DFS, bisogna installare sui due server il ruolo "File Server", utilizzando lo strumento "Manage your server" che si apre dopo il logon e che è accessibile anche andando su Start -> Programs -> Administrative Tools; cliccare ora su "Add or remove a role", cliccare su Next e, nella lista dei ruoli, selezionare la voce "File Server", dopodiché cliccare due volte su Next; a questo punto compare un ulteriore wizard, "Add File Server Role Wizard", cliccare su Next e selezionare il ruolo (relativo al File Server) "Replicate data to and from this server", che installa il servizio "DFS Replication", come mostrato in figura 2.

Figura 2

Il servizio DFS Replication è una novità introdotta con Windows Server 2003 R2 che consente di replicare i file tra due o più server in presenza di link di rete a bassa velocità, tipici delle WAN. In questo articolo non verrà trattato in dettaglio DFS Replication (che sarà oggetto di un articolo a parte), si sappia che uno spazio dei nomi DFS non necessita obbligatoriamente di DFS Replication, il quale a sua volta non necessita di uno namespace DFS; DFS replication e i namespace DFS comunque sono studiati per integrarsi senza problemi, anzi, molto spesso si utilizzeranno insieme, se si ha l’esigenza di creare uno spazio dei nomi DFS. Giunti qui, cliccare su Next e completare l’installazione del ruolo; tenere presente che per installare il ruolo File Server con DFS Replication è necessario avere a disposizione il CD 2 di Windows Server 2003 R2, che verrà richiesto durante l’installazione.

Una volta fatte queste operazioni su entrambi i server, posizionarsi sul server che ospiterà il namespace (che prende l’ovvio nome "namespace server") e creare lo spazio dei nomi DFS andando sulla console di gestione del servizio da Start -> Programs -> Administrative Tools -> DFS Management; aperta la console MMC, creeremo un nuovo spazio dei nomi basato su dominio, pertanto, nella colonna di destra cliccare sulla voce "New Namespace…", si aprirà l’immancabile wizard, in cui dovremo scegliere il server che fungerà da "namespace server", in questo caso DCServer, andare avanti e dare un nome allo spazio dei nomi, ad esempio "Cartella", che rappresenta la condivisione radice, che "conterrà" (dal punto di vista logico) tutti i dati che rientrano nel namespace DFS; fatto questo, cliccare su Next e lasciare selezionata la voce "Domain-based namespace", che indica la creazione di uno spazio dei nomi basato su dominio, quindi andare avanti e cliccare sul pulsante Create e poi sul pulsante Close per completare la creazione del namespace DFS. Ora bisogna aggiungere il secondo DC nell’ambito del namespace, quindi selezionare nella colonna di sinistra lo spazio dei nomi "\\terminus.lan\Cartella", e cliccare sulla colonna di destra (pannello Actions) la voce "Add Namespace Server…" ed aggiungere il server Coriolis nella casella "Namespace server", infine cliccare su Ok per aggiungere Coriolis come server dello spazio dei nomi per il namespace "\\terminus.lan\Cartella", come indicato in figura 3, dove è possibile osservare che i due server sono su due siti AD diversi.

Figura 3

Creato il namespace, ora bisogna creare la struttura delle sottocartelle del namespace appena creato, sottocartelle che, in questa particolare casistica, risiederanno ognuna solamente su un server, visto che al momento non verrà presa in esame la replica dei dati tra i diversi server facenti parte dello spazio dei nomi. Su entrambi i server, abbiamo una cartella condivisa che prende il nome "Dati", in cui sono situati i dati dell’organizzazione, accessibili secondo la classica formula \\nomeserver\nomecondivisione, che nei due casi descritti diventa \\dcserver\dati e \\coriolis\dati; ora vedremo come poter creare due sottocartelle del namespace, in modo tale che le due risorse condivise siano raggiungibili passando sempre dallo spazio dei nomi, secondo la formula \\terminus.lan\cartella\dati_dcserver e \\terminus.lan\cartella\dati_coriolis. Per creare una cartella dipendente dallo spazio dei nomi, cliccare sulla colonna di sinistra sul namespace \\terminus.lan\cartella quindi cliccare sulla voce "New Folder…" presente nel pannello di destra Actions, si aprirà la finestra di creazione della nuova cartella, in cui bisogna specificare il nome della cartella, nel nostro caso dati_dcserver, quindi cliccare sul pulsante Add… per aggiungere la destinazione cartella (folder target), che nel nostro caso sarà \\dcserver\dati; ripetere ora gli stessi passaggi per creare la cartella dati_coriolis con destinazione cartella \\coriolis\dati. è possibile che all’atto della creazione della cartella ci venga proposto un messaggio in cui è sconsigliata la creazione di una cartella che ha come destinazione una cartella già esistente, noi possiamo comunque ignorare il messaggio e confermare l’operazione. Ora l’interfaccia di DFS Management avrà l’aspetto mostrato in figura 4:

Figura 4

Ora questa struttura di cartelle sarà disponibile su tutti i computer del dominio, a prescindere dalla LAN di appartenenza, infatti, se digitiamo il percorso \\terminus.lan\cartella (corrispondente, come noto, al namespace creato in DFS Management) da vari host presenti sia sul sito "Rete192", sia sul sito "Rete172", avremo una finestra simile a quella mostrata in figura 5:

Figura 5

Da questa finestra, è possibile vedere su quale server sono residenti le due cartelle (anche se il nome delle cartelle spiega tutto) cliccando col tasto destro su una cartella e selezionando la voce Proprietà, dove è presente la scheda DFS, che mostra appunto qual è il percorso "reale" della cartella.

Come indicato in precedenza, se da un host qualsiasi appartenente alla LAN 172.16.1.0/24 sfogliamo e cerchiamo di accedere ai dati presenti nella cartella dati_coriolis, avremo una velocità d’accesso limitata dalla banda disponibile sul collegamento in WAN. Per ovviare a questo problema, è consigliabile utilizzare il meccanismo di replica che in Windows Server 2003 prende il nome "Replica DFS", che sarà oggetto di un prossimo articolo.

Se si gestisce un server Dell con installato Windows Server OEM (preinstallato da Dell), si potrà notare che nella fase precedente il logon viene caricato uno sfondo personalizzato di Dell. Il file di sfondo è un file BMP (dellwall.bmp) di quasi 2MB di dimensione presente all’interno della cartella “%systemroot%\system32\”. La cosa in sé non è fastidiosa, ma lo diventa se ci si connette tramite Remote Desktop su una linea lenta, come può essere una connessione VPN su linea ADSL; in questo caso, prima che compaia la finestra di logon, il nostro sistema dovrà “scaricare” quasi 2MB di immagine rappresentante un frontale di un server Dell, ed a parer mio, il sistemista che gestisce il server sa già che sta lavorando su un server Dell e non ha la minima intenzione di sprecare tempo e banda in questo modo.

Per risolvere il problema, basta modificare una voce di registro, e più precisamente impostare il valore della voce “Wallpaper” all’interno della chiave

HKEY_USERS\.DEFAULT\Control Panel\Desktop

sostituendo il percorso dello sfondo con una stringa vuota, in altre parole, basta cancellare il valore della voce “Wallpaper”.

Così facendo, elimineremo questo fastidioso contrattempo che nasce quando ci si connette ad un server Dell via RDP.

Leggendo questo post di Andrea Beggi, e proseguendo la lettura dei relativi commenti, viene descritta una situazione in cui si ha una rete che esce verso Internet tramite un router, e contestualmente si ha una VPN con un’altra sede che esce tramite un router separato, per cui bisogna lavorare bene con l’instradamento del traffico, facendo in modo che il traffico verso la VPN non esca tramite il router Internet, ma tramite il router VPN. Andrea Beggi propone una soluzione che consiste nel creare una route statica sul default gateway della rete locale, che sia in grado di reinstradare il traffico verso la VPN in modo trasparente all’utente; il problema potrebbe porsi nel traffico dalla sede remota ad un host della rete locale e ritorno, se infatti l’host non ha una valida configurazione di routing, la sede remota potrebbe comunque non comunicare con gli host della rete locale. In realtà normalmente ciò non accade, poiché il router, una volta configurato, utilizza il meccanismo chiamato ICMP Redirect Message per mandare messaggi ICMP ai vari host con le informazioni necessarie ad aggiornare la tabella di routing degli host, informandoli sul percorso più corretto da seguire per raggiungere la sottorete corrispondente alla sede remota connessa in VPN.

Nei commenti al post di Andrea Beggi, c’è chi ha proposto soluzioni alternative per raggiungere lo stesso fine, tra cui mi ha colpito la tecnica di distribuire una (o più) route statiche ai client della rete locale tramite server DHCP; il motivo principale per cui mi ha colpito è che ignoravo quest’opzione di DHCP. Al momento ho testato la soluzione solamente su un server Windows Server 2003 R2 SP1 e su un client Windows XP Professional SP2, e devo dire funziona senza problemi. In sostanza, l’obiettivo che vogliamo ottenere è fare in modo che i client della rete 172.16.1.0/24 possano raggiungere la rete 192.168.1.0/24 tramite il router 172.16.1.253; per raggiungere lo scopo, è necessario configurare nelle opzioni dell’ambito DHCP precedentemente configurato l’opzione “249 Classless Static Routes”, in cui indicare (tramite il tasto Add Route) la rete di destinazione, la subnet mask e il router tramite il quale raggiungere la sottorete in questione, come visibile dalla figura 1:

Fatto questo, dare conferma, riavviare il servizio DHCP e infine verificare che la distribuzione delle route statiche avvenga correttamente. Tenere presente che esiste un’altra opzione di DHCP che si occupa di distribuire route statiche ai client, la “033 Static Route Option”, che però non è applicabile nella nostra situazione, in quanto con questa route è possibile specificare solamente un host come destinazione e non un’intera sottorete.

Quando su un PC siamo in presenza di sintomi chiari di un’infezione da malware, e riusciamo a salvarci un file che riteniamo veicolo dell’infezione, possiamo utilizzarlo per poter fare con calma alcune indagini, allo scopo di cercare di capire il più possibile su come funziona il malware in questione. La prima preoccupazione dev’essere quella per testare il file infetto in sicurezza, senza quindi intaccare i dati ed i programmi che utilizziamo normalmente. Per evitare problemi, il modo migliore sarebbe quello di utilizzare uno o più PC dedicati proprio a sperimentazioni di vario tipo, altrimenti, se non si dispone dei mezzi/spazi/risorse per avere un ambiente di test, è possibile utilizzare un software di virtualizzazione come VMWare o Virtual PC, con cui creare una o più macchine virtuali a scopi di testing.

Nella mia prova, utilizzerò VMWare, in cui prima di ogni altra cosa utilizzerò la funzione di snapshot, che mi permetterà di tornare alla situazione pre-test su quelle macchine virtuali che utilizzerò per le operazioni di testing. Il passo successivo consiste nel copiare il presunto file infetto nella macchina virtuale per fare un primo esame, che consiste nell’esaminare il file col servizio VirusTotal, che permette di fare una scansione antivirus con una pletora di motori di scansione di diversi produttori, in modo da identificare il tipo di malware con cui abbiamo a che fare. Com’è possibile vedere dall’immagine, il malware in questione è il trojan Win32.Dialer.tl, di cui, dopo una ricerca con Google, possiamo trovare alcune informazioni sul suo funzionamento sul sito ThreatExpert.

Figura 1

Ora sappiamo quindi che il file in esame è un trojan e conosciamo alcune caratteristiche peculiari di questo malware, per cui abbiamo già un’idea di cosa ci aspetta; in particolare, essendo anche un dialer, il trojan andrà a modificare il file rasphone.pbk per creare una nuova connessione di rete (comportamento appunto tipico di un dialer), quindi creerà un nuovo processo in memoria, modificherà alcune voci di registro legate ad Internet Explorer ed infine creerà un mutex che impedirà che il processo infetto sia attivo più volte in memoria.

Raccolte informazioni sul malware, possiamo passare alla parte "pratica". Per prima cosa, scarichiamo alcuni software che ci possono essere utili per capire il comportamento del trojan in questione una volta entrato in azione:

Process Monitor: software di Sysinternals (ora acquisita da Microsoft) che ci permette di vedere in tempo reale ciò che avviene sulla nostra macchina, in particolare controlla quali processi sono in esecuzione e le variazioni effettuate sul registro di sistema;

TCPView: altra utility Sysinternals che consente di verificare le connessioni di rete attive ed in ascolto, in pratica, un’interfaccia grafica per il comando netstat;

Wireshark: sniffer di rete che permette di monitorare e registrare il traffico di rete in entrata ed in uscita da un PC.

Installate o copiate queste utilità sulle due macchine virtuali, cambiamo indirizzo IP ad entrambe in modo tale che non comunichino con la rete del nostro sistema principale e che non possano uscire verso Internet, dopodiché facciamo partire Process Monitor e TCPView e lanciamo il file infetto (cosa DA NON FARE se non a scopi di testing ed avendo cura di non infettare le proprie macchine di produzione e soprattutto di non creare traffico inutile e potenzialmente dannoso sulla rete Internet). Una volta lanciato l’eseguibile infetto dal disco E:, lasciamo fare al PC, dando ogni tanto un’occhiata a TCPView, e dopo qualche minuto, possiamo salvare il log relativo a Process Monitor per osservarlo con calma; per salvare il log, dalla finestra di Process Monitor cliccare su File, quindi su Save e comparirà la finestra illustrata in Figura 2:

Figura 2

La cosa più evidente è una certa attività relativa al file infetto 9268125.exe, che va a creare una connessione di rete ad un numero internazionale andando a modificare il file %CommonAppData%\Microsoft\Network\Connections\Pbk\rasphone.pbk, ed inoltre si può notare dalla Figura 3 che il file in questione va a ricercare diverse librerie nella stessa directory da cui è stato lanciato (E:\), non trovandole poiché queste librerie si trovano nella cartella di sistema C:\Windows\System32, quindi per fare in modo che il dialer agisca nel pieno delle proprie facoltà (dannose), probabilmente dovrei far partire il file dalla cartella System32.

Figura 3

Forse per il fatto di aver "sbagliato" la posizione del file infetto da eseguire, gli effetti sono stati piuttosto limitati, infatti, per quanto ho potuto constatare, di fatto l’infezione consiste semplicemente nella creazione del dialer di nome "Internet", inutile e causa di scarsi problemi se in presenza di un collegamento ad Internet di tipo xDSL o in fibra. Questa è una prima analisi superficiale fatta solamente con lo strumento File Monitor, più avanti proverò ad analizzare un worm, file maligno per cui saranno utili le utilità TCPView e Wireshark.

Sto scrivendo questo post con Windows Live Writer, un programma distribuito gratuitamente da Microsoft che permette di aggiornare post e pagine del proprio blog senza dover connettersi all’interfaccia di gestione del blog stesso. Windows Live Writer supporta diverse piattaforme di blogging (tra cui Wordpress) e permette di gestire più blog, cosa anch’essa molto utile. Una mancanza secondo me piuttosto grave è l’impossibilità di fare upload di file che non siano immagini (o almeno, io non ho trovato un modo per farlo), cosa che può risultare piuttosto antipatica in certe situazioni.

Per fortuna però Microsoft ha dotato il software della possibilità di estenderlo tramite plug-in (un po’ come fa Firefox con le estensioni), e, sebbene al momento il numero di plug-in scaricabili sia piuttosto esiguo, è possibile scaricare ed installare il plug-in Insert File Plugin, che consente il caricamento di un qualsiasi tipo di file, ciò permette di fare l’upload di materiale senza dover utilizzare lo scomodo server FTP. Il plug-in richiede la presenza in primis di Windows Live Writer (ovviamente), ed in secundis del .NET Framework 2.0 o successivi. Sia Windows Live Writer che Insert File Plugin funzionano con Windows Vista, non ho notizie per il momento di eventuali ed improbabili malfunzionamenti con Windows XP.

Quando si fa un backup su Windows Server 2003 utilizzando l’utilità integrata (ntbackup), può capitare che per qualche motivo non venga eseguito il backup; le cause possono essere varie, ed a questo proposito è bene controllare il log di ntbackup, che di solito descrive, seppur in modo striminzito, le ragioni del mancato salvataggio. Se il log dà un responso simile a questo:

Backup Status
The requested media failed to mount. The operation was aborted.

e nel log degli eventi compare un evento con Id 168 e l’origine Removable Storage Service, ciò significa che per qualche ragione il servizio Removable Storage non riesce a comunicare con l’unità di backup. In questo caso, una possibile soluzione consiste nel disinstallare da Gestione periferiche (Device manager) l’unità di backup e nel successivo riavvio del server, in modo tale che Windows reinstalli l’unità di backup appena disinstallata; fatto questo, se tutto va bene avremo di nuovo il nostro backup funzionante.