Protezione del server Web

In questa pagina

	Argomenti del modulo
	Obiettivi
	Ambito di applicazione
	Utilizzo del modulo
	Cenni preliminari
	Pericoli e contromisure
	Metodologia per proteggere un server Web
	Considerazioni sull'installazione di IIS e .NET Framework
	Raccomandazioni di installazione
	Procedura per proteggere un server Web
	Passaggio 1. Patch e aggiornamenti
	Passaggio 2. IISLockdown
	Passaggio 3. Servizi
	Passaggio 4. Protocolli
	Passaggio 5. Account
	Passaggio 6. File e directory
	Passaggio 7. Condivisioni
	Passaggio 8. Porte
	Passaggio 9. Registro di sistema
	Passaggio 10. Controllo e registrazione
	Passaggio 11. Siti e directory virtuali
	Passaggio 12. Mapping degli script
	Passaggio 13. Filtri ISAPI
	Passaggio 14. Metabase IIS
	Passaggio 15. Certificati server
	Passaggio 16. Machine.Config
	Passaggio 17. Protezione dall'accesso di codice
	Riepilogo delle caratteristiche di un server Web protetto
	Mantenimento della protezione
	Amministrazione remota
	Semplificazione e automatizzazione della protezione
	Riepilogo
	Ulteriori risorse

Argomenti del modulo

Il server Web si trova sul front-end dell'infrastruttura di hosting. È direttamente connesso a Internet ed è responsabile del ricevimento delle richieste dai client, della creazione di pagine Web dinamiche e della risposta contenente i dati richiesti.

Un server Web protetto rappresenta una solida base per l'ambiente di hosting, dove la sua configurazione svolge un ruolo cruciale per la protezione generale delle applicazioni Web. È opportuno chiedersi però quali sono le caratteristiche di un server Web protetto. Per proteggere il server Web è di fondamentale importanza comprendere con precisione l'obiettivo. Una volta stabilito cosa si intende con server Web protetto, è possibile apprendere come applicare le impostazioni di configurazione richieste per realizzarlo.

In questo modulo viene presentato un metodo sistematico e ripetibile, che è possibile adottare per configurare un server Web protetto. Viene illustrata la metodologia per proteggere il server Web che consiste nel separarne la configurazione in dodici aree di protezione. A ognuna di queste aree viene dedicata una serie di procedure di alto livello. Le procedure sono modulari e spiegano come applicare la metodologia.

Inizio pagina

Obiettivi

Il modulo consente di:

Inizio pagina

Ambito di applicazione

Le informazioni contenute in questo modulo sono valide per i seguenti prodotti e tecnologie:

Inizio pagina

Utilizzo del modulo

Per trarre il massimo vantaggio dal modulo:

Inizio pagina

Cenni preliminari

È opportuno chiedersi quali sono le caratteristiche di un server Web protetto. Per proteggere il server Web è di fondamentale importanza comprendere con precisione l'obiettivo. Una volta stabilito cosa si intende con server Web protetto, è possibile apprendere come applicare le impostazioni di configurazione richieste per realizzarlo. In questo modulo viene presentato un metodo sistematico e ripetibile, che è possibile adottare per configurare un server Web protetto.

All'inizio vengono passati in rassegna i pericoli più comuni che interessano i server Web. Quindi, su questa base viene creata la metodologia. Successivamente, si passa alla messa in pratica della metodologia e a illustrare dettagliatamente come migliorare la protezione del server Web. Anche se la metodologia di base può essere riutilizzata per varie tecnologie, questo modulo è dedicato a illustrare la protezione di un server Web con il sistema operativo Microsoft Windows 2000 e che ospita Microsoft .NET Framework.

Inizio pagina

Pericoli e contromisure

Il fatto che un pirata informatico possa colpire da una posizione remota fa di un server Web un bersaglio attraente. Capire quali sono i pericoli per un server Web ed essere in grado di identificare le contromisure appropriate permette di prevenire molti attacchi e sventare le intenzioni del gruppo sempre più numeroso di pirati informatici.

I principali pericoli per un server Web sono:

Nella Figura 16.1 sono riassunti gli attacchi principali e le vulnerabilità comuni.

Figura 16.1
Pericoli principali per un server Web e vulnerabilità comuni

Profiling

Il profiling, o enumerazione host, è un processo esplorativo utilizzato per raccogliere informazioni su un sito Web. Un pirata informatico si serve di queste informazioni per attaccare i punti deboli conosciuti.

Vulnerabilità

Le vulnerabilità comuni che rendono il server soggetto al profiling sono:

Attacchi

Gli attacchi comuni utilizzati per il profiling sono:

Contromisure

Le contromisure includono il blocco di tutte le porte non necessarie, il blocco del traffico Internet Control Message Protocol (ICMP) e la disattivazione dei protocolli non necessari quali NetBIOS e SMB.

Denial of Service (Negazione del servizio)

Gli attacchi Denial of Service si verificano quando il server è sovraccarico di richieste di servizio. Il pericolo è dato dal fatto che, a causa di questo sovraccarico, il server Web non potrà rispondere alle richieste client legittime.

Vulnerabilità

Le vulnerabilità che fanno aumentare il rischio di attacchi DoS sono:

Attacchi

Gli attacchi DoS più comuni sono:

Contromisure

Le contromisure includono il rafforzamento della protezione dello stack TCP/IP e l'applicazione coerente delle ultime patch software e degli aggiornamenti al software di sistema.

Accesso non autorizzato

L'accesso non autorizzato si verifica quando un utente senza le autorizzazioni corrette accede a informazioni riservate o effettua un'operazione vietata.

Vulnerabilità

Le vulnerabilità comuni che portano a un accesso non autorizzato sono:

Contromisure

Le contromisure includono l'utilizzo di autorizzazioni Web protette, autorizzazioni NTFS e meccanismi di controllo dell'accesso .NET Framework compresa l'autorizzazione URL.

Esecuzione arbitraria di codice

Gli attacchi di esecuzione di codice si verificano quando un pirata informatico esegue codice dannoso sul server per comprometterne le risorse o per organizzare ulteriori attacchi contro i sistemi a valle.

Vulnerabilità

Le vulnerabilità che possono portare all'esecuzione di codice dannoso sono:

Attacchi

Gli attacchi comuni di esecuzione di codice sono:

Contromisure

Le contromisure includono la configurazione di IIS in maniera che respinga gli URL con "../" per impedire l'attraversamento del percorso, il blocco dei comandi di sistema e delle utilità con ACL (Access Control List) con restrizioni e l'installazione di nuove patch e di nuovi aggiornamenti.

Aumento del livello dei privilegi

Gli attacchi che mirano a elevare i privilegi si verificano quando un pirata informatico esegue codice utilizzando un account di processo con privilegi.

Vulnerabilità

Le vulnerabilità comuni che espongono il server Web agli attacchi di aumento del livello dei privilegi sono:

Contromisure

Le contromisure includono l'esecuzione di processi tramite account con privilegi minimi e l'utilizzo di account utente e di servizio con privilegi minimi.

Virus, worm e cavalli di Troia

Il codice dannoso può essere introdotto in vari modi, tra cui:

In molti casi, la presenza di codice dannoso non viene notata finché non consuma le risorse di sistema e non rallenta o interrompe l'esecuzione di altri programmi. Il worm Code Red, ad esempio, è stato uno dei codici più dannosi che abbiano colpito IIS e faceva affidamento su una vulnerabilità relativa all'overflow del buffer in un filtro ISAPI.

Vulnerabilità

Le vulnerabilità comuni che espongono a virus, worm e cavalli di Troia sono:

Contromisure

Le contromisure includono la sollecita applicazione delle ultime patch software, la disattivazione delle funzionalità inutilizzate quali i filtri e le estensioni ISAPI e l'esecuzione di processi con account con privilegi minimi per ridurre i danni in caso di attacco.

Inizio pagina

Metodologia per proteggere un server Web

Per proteggere un server Web, è necessario applicare molte impostazioni di configurazione per ridurre la vulnerabilità del server agli attacchi. Per sapere da dove iniziare e quando il processo di protezione può dirsi concluso, l'approccio migliore consiste nell'organizzare in categorie le precauzioni da prendere e le impostazioni da configurare. L'utilizzo di categorie consente di percorrere sistematicamente l'intero processo di protezione dall'alto in basso o di scegliere una particolare categoria e di completare la procedura specifica.

Categorie di configurazione

La metodologia di protezione illustrata in questo modulo è stata suddivisa nelle categorie riportate nella Figura 16.2.

Figure 16.2
Categorie di configurazione di un server Web

Questa categorizzazione si basa sui seguenti presupposti:

Inizio pagina

Considerazioni sull'installazione di IIS e .NET Framework

Prima di poter proteggere il server Web, è necessario conoscere quali sono i componenti presenti in un server Windows 2000 dopo l'installazione di IIS e .NET Framework. In questa sezione viene spiegato quali sono i componenti installati.

Componenti installati da IIS

IIS installa diversi servizi, account, cartelle e siti Web. Alcuni potrebbero non essere utilizzati dalle proprie applicazioni Web e, se sono presenti nel server, potrebbero renderlo vulnerabile agli attacchi. Nella Tabella 16.1 sono elencati i servizi, gli account e le cartelle creati da un'installazione completa di IIS in Windows 2000 Server con tutti i componenti selezionati.

Tabella 16.1 Installazioni predefinite di IIS

Elementi installati da .NET Framework

Quando si installa .NET Framework in un server che ospita IIS, .NET Framework registra ASP.NET. Come parte del processo, viene creato un account locale con privilegi minimi chiamato ASPNET. Questo account esegue il processo di lavoro di ASP.NET (aspnet_wp.exe) e il servizio sullo stato sessione (aspnet_state.exe), che possono essere utilizzati per gestire lo stato della sessione utente.

Nota: su computer server con Windows 2000 e IIS 5.0, tutte le applicazioni Web ASP.NET vengono eseguite in un'istanza singola del processo di lavoro di ASP.NET e l'isolamento è offerto dai domini di applicazioni. Su Windows Server 2003, IIS 6.0 offre l'isolamento a livello di processo tramite l'utilizzo di pool di applicazioni.

Nella Tabella 16.2 sono riportati i servizi, gli account e le cartelle creati da un'installazione predefinita della versione 1.1 di .NET Framework.

Tabella 16.2 Installazioni predefinite di .NET Framework

Inizio pagina

Raccomandazioni di installazione

Per impostazione predefinita, il programma di installazione di Windows 2000 Server installa IIS. Si consiglia tuttavia di non installare IIS come parte dell'installazione del sistema operativo ma in un secondo momento, dopo aver aggiornato e installato le patch del sistema operativo di base. Una volta installato IIS, è necessario riapplicare le sue patch e rafforzare la sua configurazione per accertasi che sia totalmente protetta. Solo a questo punto la connessione del server alla rete sarà protetta.

Raccomandazioni di installazione di IIS

Se si installa e si configura un nuovo server Web, attenersi alla procedura riportata qui di seguito.

Raccomandazioni di installazione di .NET Framework

Non installare il Software Development Kit (SDK) di .NET Framework in un server di produzione. L'SDK contiene utilità che non sono richieste dal server. Se un pirata informatico ottiene l'accesso a un server, può utilizzare alcuni di questi strumenti come supporto per altri tipi di attacchi.

Installare invece il pacchetto ridistribuibile, che può essere scaricato dal collegamento "Downloads" del sito .NET Framework di Microsoft.com all'indirizzo http://www.microsoft.com/net/ (in inglese).

Inclusione di service pack con un'installazione di base

Se è necessario creare più server, è possibile incorporare i service pack direttamente nelle installazioni di Windows. I service pack includono un programma chiamato Update.exe per combinare un service pack con i file di installazione di Windows.

Per ulteriori informazioni, vedere l'articolo di MSDN, "Customizing Unattended Win2K Installations" all'indirizzo http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag01/html/custominstall.asp (in inglese).

Inizio pagina

Procedura per proteggere un server Web

Nelle prossime sezioni viene illustrato dettagliatamente il processo di protezione di un server Web, tramite le categorie di configurazione introdotte nella sezione "Metodologia per proteggere un server Web" di questo modulo. Ogni procedura di livello elevato contiene una o più azioni per proteggere una particolare area o funzionalità.

Inizio pagina

Passaggio 1. Patch e aggiornamenti

Aggiornare il server con i service pack e le patch più recenti. È necessario aggiornare e implementare le patch per tutti i componenti del server Web, compresi Windows 2000 (e IIS), .NET Framework e Microsoft Data Access Components (MDAC).

In questo passaggio verrà descritto come:

Individuare e installare patch e aggiornamenti

Utilizzare Microsoft Baseline Security Analyzer (MBSA) per individuare le patch e gli aggiornamenti che potrebbero non essere presenti nell'installazione corrente. MBSA confronta l'installazione con un elenco degli aggiornamenti correntemente disponibili mantenuto in un file XML. MBSA può scaricare il file XML quando effettua la scansione del server, oppure il file può essere scaricato manualmente nel server o essere reso disponibile in un server di rete.

Aggiornare .NET Framework

Al momento della stesura del presente modulo (maggio 2003), MBSA non è in grado di rilevare gli aggiornamenti e le patch di .NET Framework. Pertanto è necessario individuarli manualmente.

Inizio pagina

Passaggio 2. IISLockdown

Lo strumento IISLockdown aiuta ad automatizzare determinati passaggi relativi alla protezione. IISLockdown riduce moltissimo la vulnerabilità di un server Web Windows 2000. Consente di selezionare uno specifico tipo di ruolo server e di utilizzare quindi modelli personalizzati per migliorare la protezione per quel particolare server. I modelli disattivano o proteggono varie funzionalità. Inoltre, IISLockdown installa il filtro ISAPI URLScan. URLScan consente agli amministratori dei siti Web di limitare il tipo di richieste HTTP che il server può elaborare, in base a una serie di regole controllate dagli amministratori. Bloccando specifiche richieste HTTP, il filtro URLScan impedisce che richieste potenzialmente dannose raggiungano il server e provochino problemi.

In questo passaggio verrà descritto come:

Installare ed eseguire IISLockdown

IISLockdown è disponibile come download Internet dal sito Web Microsoft all'indirizzo http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe (in inglese).

Salvare IISlockd.exe in una cartella locale. IISlockd.exe è la procedura guidata di IISLockdown e non un programma di installazione. È possibile annullare qualsiasi modifica effettuata da IISLockdown eseguendo IISlockd.exe una seconda volta.

Se si blocca un computer basato su Windows 2000 che ospita pagine ASP.NET, selezionare il modello Dynamic Web Server quando richiesto dallo strumento IISLockdown. Se si seleziona Dynamic Web Server, IISLockdown effettua le azioni seguenti:

Nota: se non si utilizza ASP classico, non utilizzare il modello di server Web statico. Questo modello rimuove le funzionalità di base di cui hanno bisogno le pagine ASP.NET, quale il supporto per il comando POST.

File registro

IISLockdown crea due report in cui sono elencate le modifiche che ha applicato:

Gruppi Web Anonymous Users e Web Application

IISLockdown crea il gruppo Web Anonymous Users e il gruppo Web Application. Il gruppo Web Anonymous Users contiene l'account IUSR_MACHINE. Il gruppo Web Application contiene l'account IWAM_MACHINE. Le autorizzazioni vengono assegnate alle utilità di sistema e alle directory contenuto sulla base di questi gruppi, non direttamente agli account IUSR e IWAM. Per esaminare le autorizzazioni specifiche visualizzare il registro IISLockdown, %windir%\system32\inetsrv\oblt-log.log.

404.dll

IISLockdown installa 404.dll, alla quale è possibile mappare le estensioni dei file che non devono essere eseguiti dal client. Per ulteriori informazioni, vedere "Passaggio 12: Mapping degli script".

URLScan

Se si installa il filtro ISAPI URLScan come parte di IISLockdown, le impostazioni di URLScan sono integrate con il ruolo server selezionato al momento dell'esecuzione di IISLockdown. Se si seleziona ad esempio un server Web statico, URLScan blocca il comando POST.

Annullamento delle modifiche di IISLockdown

Per annullare le modifiche effettuate da IISLockdown, eseguire IISLockd.exe una seconda volta. Questa azione non comporta la rimozione del filtro ISAPI URLScan. Per ulteriori informazioni, vedere "Rimozione di URLScan" nel prossimo argomento.

Ulteriori informazioni

Per ulteriori informazioni su IISLockdown, vedere gli articoli seguenti:

Installare e configurare URLScan

URLScan viene installato quando si esegue IISLockdown, sebbene possa essere scaricato e installato separatamente.

URLScan blocca le richieste che contengono caratteri non sicuri (ad esempio quelli che sono stati utilizzati per sfruttare le vulnerabilità, quale ".." utilizzato per l'attraversamento delle directory). URLScan registra le richieste che contengono questi caratteri nella directory %windir%\system32\inetsrv\urlscan.

Configurare URLScan utilizzando le impostazioni nel file ini %windir%\system32\inetsrv\urlscan\urlscan.ini.

Oltre a bloccare le richieste dannose, è possibile utilizzare URLScan per difendere il server da attacchi di tipo Denial of Service prima che le richieste raggiungano ASP.NET. A questo fine, impostare il limite negli argomenti MaxAllowedContentLength, MaxUrl e MaxQueryString nel file URLScan.ini. Per ulteriori informazioni, vedere "Procedura: Utilizzo di URLScan" nella sezione "Procedure" di questa guida.

Annullamento delle modifiche di URLScan

Non esiste alcuna operazione automatica per rimuovere URLScan. Se si hanno problemi con URLScan, è possibile rimuoverlo da IIS o analizzare il problema registrando le richieste che vengono respinte. A questo fine, utilizzare l'opzione RejectResponseUrl=/~* nel file ini di URLScan.

Per ulteriori informazioni sulla rimozione dei filtri ISAPi, vedere "Passaggio 13: Filtri ISAPI" più avanti in questo modulo.

Ulteriori informazioni

Per ulteriori informazioni sullo strumento URLScan, vedere gli articoli seguenti:

Inizio pagina

Passaggio 3. Servizi

I servizi che non autenticano i client, i servizi che utilizzano protocolli non protetti o i servizi che vengono eseguiti con un numero eccessivo di privilegi, comportano dei rischi. Evitare di eseguire i servizi che non sono necessari. Disattivando i servizi non necessari si riduce rapidamente e facilmente la superficie di attacco. Si riduce inoltre il sovraccarico in termini di manutenzione (patch, account di servizio e così via).

Se si esegue un servizio, controllare che sia protetto e gestito. A questo fine, eseguirlo tramite un account con privilegi minimi e tenerlo aggiornato applicando le patch.

In questo passaggio verrà descritto come:

Disattivare i servizi non necessari

I servizi di Windows sono vulnerabili agli attacchi dei pirati informatici che possono sfruttare i loro privilegi e le loro capacità e ottenere l'accesso alle risorse di sistema remote e locali. Come misura difensiva, disattivare i servizi di Windows che non sono richiesti dai propri sistemi e dalle proprie applicazioni. Per disattivare i servizi di Windows, utilizzare lo snap-in MMC Servizi che si trova nel gruppo di programmi Strumenti di amministrazione.

Nota: prima di disattivare un servizio, testare l'impatto in un ambiente di test o temporaneo.

Nella maggior parte dei casi, in un server Web i seguenti servizi predefiniti di Windows non sono necessari: Avvisi, Browser del computer, Messenger, Accesso rete (richiesto solo per i controller di dominio), Servizi TCP/IP semplificati e Spooler di stampa.

Il servizio Telnet è installato con Windows, ma per impostazione predefinita non è attivato. Gli amministratori di IIS spesso attivano Telnet. Si tratta tuttavia di un protocollo non protetto e quindi esposto agli attacchi. Servizi terminal offre un'opzione di amministrazione remota più protetta. Per ulteriori informazioni sull'amministrazione remota, vedere "Amministrazione remota" più avanti in questo modulo.

Disattivare FTP, SMTP e NNTP, a meno che non siano necessari

FTP, SMTP e NNTP sono esempi di protocolli non protetti e quindi esposti a un utilizzo improprio. Evitare di eseguire i servizi che non sono necessari. Se sono utilizzati, cercare un'alternativa sicura. Se è necessario eseguirli, proteggerli.

Nota: IISLockdown fornisce opzioni per disattivare FTP, SMTP e NNTP.

Per eliminare la possibilità che FTP venga sfruttato, disattivare il servizio FTP se non è utilizzato. Se FTP è attivato ed è disponibile per le connessioni in uscita, un pirata informatico può utilizzarlo per caricare i file e gli strumenti del suo sistema remoto in un server Web. Una volta che file e strumenti si trovano nel server Web, il pirata informatico può attaccare il server Web o altri sistemi connessi.

Se si utilizza il protocollo FTP, né il nome utente e la password utilizzati per accedere al sito FTP né i dati che vengono trasferiti sono codificati o crittografati. IIS non supporta SSL per FTP. Se le comunicazioni protette sono importanti e si utilizza FTP come protocollo di trasferimento, invece del protocollo WebDAV (World Wide Web Distributed Authoring and Versioning) su SSL, considerare la possibilità di utilizzare FTP su un canale crittografato quale una rete privata virtuale (VPN, Virtual Private Network) che sia protetta con PPTP (Point-to-Point Tunneling Protocol) o IPSec (Internet Protocol Security).

Disattivare ASP.NET State Service, a meno che non sia necessario

.NET Framework installa ASP.NET State Service (aspnet_state.exe) per gestire lo stato sessione utente out-of-process per applicazioni Web ASP.NET e servizi Web. Per impostazione predefinita, questo servizio è configurato per l'avvio manuale e viene eseguito come account ASPNET locale con privilegi minimi. Se nessuna delle applicazioni archivia lo stato utilizzando questo servizio, disattivarlo. Per ulteriori informazioni sulla protezione dello stato sessione ASP.NET, vedere la sezione "Stato sessione" nel modulo 19 "Protezione dell'applicazione ASP.NET e dei servizi Web".

Inizio pagina

Passaggio 4. Protocolli

Impedendo l'utilizzo dei protocolli non necessari si riducono i potenziali attacchi. .NET Framework fornisce un controllo granulare dei protocolli tramite le impostazioni nel file Machine.config. È ad esempio possibile controllare se i servizi Web possono utilizzare HTTP GET, POST o SOAP. Per ulteriori informazioni sulla configurazione dei protocolli in Machine.config, vedere "Passaggio 16: Machine.config".

In questo passaggio verrà descritto come:

Disattivare o proteggere WebDav

IIS supporta il protocollo WebDAV, un'estensione standard a HTTP 1.1 per la pubblicazione collaborativa del contenuto. Disattivare questo protocollo sui server di produzione, se non è utilizzato.

Nota: IISLockdown fornisce un'opzione per rimuovere il supporto per WebDAV.

WebDAV è preferibile a FTP dal punto di vista della protezione, ma deve essere protetto. Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 323470, "How To: Create a Secure WebDAV Publishing Directory" (in inglese).

Se non si ha necessità di WebDAV, vedere l'articolo della Microsoft Knowledge Base 241520, "How To: Disable WebDAV for IIS 5.0" (in inglese).

Rafforzare la protezione dello stack TCP/IP

Windows 2000 supporta il controllo granulare di molti parametri che configurano la sua implementazione TCP/IP. Alcune impostazioni predefinite sono configurate per fornire la disponibilità server e altre funzionalità specifiche.

Per informazioni su come rafforzare la protezione dello stack TCP/IP vedere "Procedura: Rafforzamento delle protezioni dello stack TCP/IP" nella sezione "Procedure" di questa guida.

Disattivare NetBIOS e SMB

Disattivare tutti i protocolli non necessari, inclusi NetBIOS e SMB. I server Web non richiedono NetBIOS o SMB nelle loro schede di interfaccia di rete (NIC) connesse a Internet. Disattivare questi protocolli per contrastare il pericolo dell'enumerazione host.

Nota: il protocollo SMB può restituire moltissime informazioni su un computer a utenti non autenticati su una sessione Null. Per bloccare le sessioni Null, impostare la chiave del Registro di sistema RestrictAnonymous come descritto nel "Passaggio 9: Registro di sistema".

Disattivazione di NetBIOS

NetBIOS utilizza le porte seguenti:

La sola disattivazione di NetBIOS non è sufficiente a impedire le comunicazioni SMB perché se non è disponibile una porta NetBIOS standard, SMB utilizza la porta TCP 445, nota come SMB Direct Host. Di conseguenza, è necessario intraprendere le azioni di disattivazione di NetBIOS e SMB separatamente.

Nota: questa procedura disattiva il driver Nbt.sys e richiede il riavvio del sistema.

Disattivazione di SMB

SMB utilizza le porte seguenti:

Per disattivare SMB, utilizzare la finestra di dialogo delle proprietà TCP/IP nelle proprietàConnessione alla rete locale per disattivare SMB dalla porta connessa a Internet.

Nota: la scheda WINS della finestra di dialogo Impostazioni avanzate TCP/IP contiene l'opzione Disabilita NetBIOS su TCP/IP. La selezione di questa opzione consente di disattivare il servizio sessione NetBIOS che utilizza la porta TCP 139. Non consente di disattivare completamente SMB. A tal fine, utilizzare la procedura illustrata in precedenza.

Inizio pagina

Passaggio 5. Account

Gli account inutilizzati dovrebbero essere rimossi, perché un pirata informatico potrebbe individuarli e utilizzarli. Richiedono password complesse. Password vulnerabili aumentano la probabilità di un attacco di tipo "brute force" o del dizionario. Utilizzare privilegi minimi. Questa precauzione consente di evitare che un pirata informatico possa utilizzare un account dotato di privilegi elevati per accedere a risorse non autorizzate.

In questo passaggio verrà descritto come:

Eliminare o disattivare gli account non utilizzati

Gli account inutilizzati e i relativi privilegi possono essere utilizzati da un pirata informatico per ottenere l'accesso a un server. Controllare gli account locali sul server e disattivare quelli inutilizzati. Se la disattivazione dell'account non causa problemi, eliminarlo. (Gli account eliminati non possono essere ripristinati.) Disattivare gli account in un server di test prima di disattivarli in un server di produzione. Controllare che la disattivazione di un account non pregiudichi il funzionamento dell'applicazione.

Nota: l'account Administrator e l'account Guest non possono essere eliminati.

Disattivare l'account Guest

L'account Guest viene utilizzato per le connessioni anonime al computer. Disattivandolo, è possibile limitare le connessioni anonime al computer. L'account Guest è disattivato per impostazione predefinita in Windows 2000. Per controllare se è attivato o disattivato, visualizzare la cartella Users nello strumento Gestione computer. L'account Guest deve essere visualizzato con un'icona barrata da una croce. Se non è disattivato, visualizzare la relativa finestra di dialogo Proprietà e selezionare Account disabilitato.

Rinominare l'account Administrator

L'account locale predefinito Administrator è un bersaglio per i malintenzionati a causa dei privilegi elevati di cui dispone. Per migliorare la protezione, rinominare l'account Administrator predefinito e assegnargli una password complessa.

Se si ha intenzione di effettuare operazioni di amministrazione locale, configurare l'account in maniera che neghi i diritti di accesso in rete e chieda all'amministratore di accedere interattivamente. Questa configurazione impedisce agli utenti (sia ben intenzionati che non) di utilizzare l'account Administrator per accedere al server da una postazione remota. Se un criterio di amministrazione locale è troppo rigido, implementare una soluzione di amministrazione remota protetta. Per ulteriori informazioni, vedere "Amministrazione remota" più avanti in questo modulo.

Disattivare l'account IUSR

Disattivare l'account utente Internet anonimo, IUSR_MACHINE. Questo account viene creato durante l'installazione di IIS. MACHINE è il nome NetBIOS del server al momento dell'installazione di IIS.

Creare un account Web anonimo personalizzato

Se l'applicazione supporta l'accesso anonimo (ad esempio perché utilizza un meccanismo di autenticazione personalizzato quale l'autenticazione Form), creare un account anonimo personalizzato con privilegi minimi. Se si esegue IISLockdown, aggiungere l'utente personalizzato al gruppo Web Anonymous Users che viene creato. IISLockdown nega al gruppo Web Anonymous Users l'accesso alle utilità di sistema e la capacità di scrivere nelle directory con contenuto Web.

Se il server Web ospita più applicazioni Web, potrebbe essere utile utilizzare più account anonimi, uno per ogni applicazione, per proteggerle e controllarne il funzionamento in maniera indipendente l'una dall'altra.

Per ulteriori informazioni sull'hosting di più applicazioni Web, vedere il modulo 20 "Hosting di più applicazioni ASP.NET".

Applicare criteri per password complesse

Per contrastare gli attacchi di tipo "brute force" e di violazione delle password sull'applicazione, applicare criteri per password complesse. Per applicare un criterio per password complesse:

Nella Tabella 16.4 sono riportate le impostazioni predefinite e consigliate per i criteri per le password.

Tabella 16.4. Impostazioni predefinite e consigliate per i criteri per le password

Registrare inoltre i tentativi di accesso non riusciti in maniera da poter rilevare e tener traccia di situazioni pericolose. Per ulteriori informazioni, vedere "Passaggio 10: Controllo e registrazione".

Limitare gli accessi remoti

Rimuovere il privilegio Accedi al computer dalla rete dal gruppo Everyone per limitare il numero di coloro che possono accedere al server in modalità remota.

Disattivare le sessioni Null (accessi anonimi)

Per impedire gli accessi anonimi è necessario disattivare le sessioni Null. Si tratta di sessioni non autenticate o anonime stabilite tra due computer. Se le sessioni Null non sono disattivate, un pirata informatico può connettersi al server in forma anonima senza essere autenticato.

Stabilendo una sessione Null un pirata informatico ha a disposizione una serie di possibili attacchi, comprese le tecniche di enumerazione utilizzate per raccogliere dal computer aggredito informazioni relative al sistema e che potranno agevolare successivi attacchi. Le informazioni che possono essere restituite in una sessione Null includono dettagli su domini e attendibilità, condivisioni, informazioni sugli utenti, compresi diritti utente e gruppi e chiavi del Registro di sistema.

Limitare le sessioni Null impostando RestrictAnonymous su 1 nel Registro di sistema nella sottochiave seguente:

HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 246261 "How To: Use the RestrictAnonymous Registry Value in Windows 2000" (in inglese).

Considerazioni aggiuntive

Qui di seguito è riportato un elenco di altri passaggi da applicare per migliorare ulteriormente la protezione del server Web:

Inizio pagina

Passaggio 6. File e directory

Installare Windows 2000 in partizioni formattate con il file system NTFS in maniera da beneficiare delle autorizzazioni NTFS per limitare l'accesso. Per proteggere file e directory riservati è necessario utilizzare controlli di accesso avanzati. Nella maggior parte delle situazioni, l'approccio più efficace non consiste nel negare l'accesso a specifici account, ma nel consentirlo solo a specifici account. Se possibile, impostare l'accesso a livello di directory. Poiché i file aggiunti alla cartella ne erediteranno le autorizzazioni, non saranno necessarie ulteriori impostazioni.

In questo passaggio verrà descritto come:

Imporre restrizioni al gruppo Everyone

Le autorizzazioni NTFS predefinite per Windows 2000 concedono ai membri del gruppo Everyone l'accesso con controllo completo a numerosi percorsi chiave, inclusa la directory principale, \inetpub e \inetpub\scripts.

Concedere innanzitutto il CONTROLLO COMPLETO all'account Administrator sulla directory principale (\), quindi rimuovere i diritti di accesso per il gruppo Everyone dalle directory seguenti.

Limitare l'accesso all'account anonimo di IIS

L'account anonimo è molto noto. I pirati informatici attaccano questo account per effettuare azioni dannose. Per proteggere l'account anonimo:

Proteggere o rimuovere strumenti, utilità e SDK

SDK e Resource Kit non devono essere installati in un server Web di produzione. Se presenti, rimuoverli.

Rimuovere i file di esempio

Le applicazioni di esempio in genere non sono configurate con livelli di protezione elevati. Un pirata informatico potrebbe sfruttare una debolezza intrinseca dell'applicazione di esempio o della sua configurazione per attaccare un sito Web. Rimuovere le applicazioni di esempio per ridurre le aree in cui il server Web può essere attaccato.

Considerazioni aggiuntive

Valutare inoltre la rimozione dei nomi origine dati (DSN, Data Source Names) non necessari. Questi nomi contengono dettagli sulle connessioni non crittografate utilizzate dalle applicazioni per connettersi alle origini dati OLE DB. Nel server Web devono essere installati solo i DSN richiesti dalle applicazioni Web.

Inizio pagina

Passaggio 7. Condivisioni

Rimuovere le condivisioni inutilizzate e proteggere ulteriormente le autorizzazioni NTFS su qualsiasi condivisione essenziale. Per impostazione predefinita, tutti gli utenti hanno il controllo totale sulle condivisioni di file appena create. Rafforzare la protezione di queste autorizzazioni predefinite in maniera che solo gli utenti autorizzati possano accedere ai file esposti dalla condivisione. Oltre alle autorizzazioni di condivisione esplicite, utilizzare ACL NTFS per i file e le cartelle esposti dalla condivisione.

In questo passaggio verrà descritto come:

Rimuovere le condivisioni non necessarie

Rimuovere tutte le condivisioni non necessarie. Per visualizzare le condivisioni e le autorizzazioni associate, eseguire lo snap-in MMC Gestione computer e selezionare Condivisioni sotto Cartelle condivise come illustrato nella Figura 16.3.

Figura 16.3
Condivisioni dello snap-in MMC Gestione computer

Limitare l'accesso alle condivisioni necessarie

Rimuovere il gruppo Everyone e concedere autorizzazioni specifiche. Il gruppo Everyone è utilizzato quando non vi sono restrizioni su chi può accedere alla condivisione.

Considerazioni aggiuntive

Se non è necessario consentire l'amministrazione remota del server, rimuovere le condivisioni amministrative inutilizzate, ad esempio C$ e Admin$.

Nota: per alcune applicazioni potrebbero essere necessarie condivisioni amministrative, ad esempio per Microsoft Systems Management Server (SMS) e Microsoft Operations Manager (MOM). Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 318751 "How To: Remove Administrative Shares in Windows 2000 or Windows NT 4.0" (in inglese).

Inizio pagina

Passaggio 8. Porte

I servizi che vengono eseguiti nel server utilizzano porte specifiche in maniera da poter servire le richieste in ingresso. Chiudere tutte le porte non necessarie ed effettuare controlli regolari per individuare lo stato delle nuove porte in ascolto, al fine di scoprire gli eventuali accessi non autorizzati e i pericoli per la protezione.

In questo passaggio verrà descritto come:

Limitare le porte connesse a Internet a TCP 80 e 443

Limitare il traffico in ingresso alla porta 80 per HTTP e alla porta 443 per HTTPS (SSL).

Per le NIC in uscita (connesse a Internet), utilizzare IPSec o i filtri TCP. Per ulteriori informazioni, vedere "Procedura: Utilizzo di IPSec per filtrare le porte e l'autenticazione" nella sezione "Procedure" di questa guida.

Crittografare o limitare il traffico Intranet

Nel caso di NIC in ingresso (connesse alle reti Intranet), se non si dispone di un centro dati protetto e tra i computer vengono passate informazioni riservate, valutare la possibilità di crittografare il traffico o di limitare le comunicazioni tra il server Web e i server a valle (ad esempio un server per applicazioni o un server di database). La crittografia del traffico di rete permette di eliminare il pericolo rappresentato dall'ascolto e intercettazione di rete non autorizzati. Se il rischio viene giudicato sufficientemente basso, è possibile scegliere di non crittografare il traffico.

Dal tipo di crittografia utilizzata dipendono anche i tipi di pericoli contrastati. SSL, ad esempio, è una crittografia a livello di applicazione, mentre IPSec è una crittografia a livello di trasporto. Di conseguenza, oltre al pericolo dell'ascolto e intercettazione di rete non autorizzati, SSL contrasta anche quello della manomissione dei dati o della divulgazione di informazioni da un altro processo sullo stesso computer, specie se in esecuzione sotto un account diverso.

Inizio pagina

Passaggio 9. Registro di sistema

Il Registro di sistema è l'archivio in cui vengono memorizzate molte impostazioni di configurazione importanti. Di conseguenza, è indispensabile assicurarsi che possano accedervi solo gli amministratori autorizzati. Se un pirata informatico è in grado di modificare il Registro di sistema, può riconfigurare e compromettere la protezione del server.

In questo passaggio verrà descritto come:

Limitare l'amministrazione remota del Registro di sistema

Dalla chiave Winreg dipende la disponibilità delle chiavi del Registro di sistema per l'accesso remoto. Per impostazione predefinita, questa chiave è configurata per impedire agli utenti di vedere in modalità remota la maggior parte delle chiavi presenti nel Registro di sistema e permettere solo agli utenti con privilegi elevati di modificarle. In Windows 2000, l'accesso remoto al Registro di sistema è limitato per impostazione predefinita ai membri dei gruppi Administrators e Backup operators. Gli amministratori hanno il controllo completo, mentre gli operatori di backup hanno solo l'accesso in lettura.

Il tipo di utenti che possono accedere in modalità remota al Registro di sistema dipende dalle autorizzazioni associate nel seguente percorso del Registro di sistema.

HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

Per visualizzare le autorizzazioni per questa chiave del Registro di sistema, eseguire Regedt32.exe, portarsi sulla chiave e scegliere Autorizzazioni dal menu Protezione.

Nota: alcuni servizi necessitano dell'accesso remoto al Registro di sistema. Fare riferimento all'articolo della Microsoft Knowledge Base 153183, "How to Restrict Access to the Registry from a Remote Computer" (in inglese), per vedere se la situazione corrente richiede un accesso remoto limitato al Registro di sistema.

Proteggere il database di Gestione account di protezione (solo server autonomi)

Nei server autonomi sono archiviati i nomi account e hash delle password unilaterali (non reversibili) (LMHash) nel database di Gestione account di protezione (SAM, Security Account Manager)locale. SAM fa parte del Registro di sistema. In genere, solo i membri del gruppo Administrators hanno accesso alle informazioni dell'account.

Anche se le password non sono di fatto archiviate in SAM e gli hash delle password non sono reversibili, se un pirata informatico riesce a ottenere una copia del database SAM può utilizzare le tecniche di tipo "brute force" sulla password per ottenere nomi utente e password validi.

Limitare l'archiviazione LMHash in SAM creando la chiave (non il valore) NoLMHash nel Registro di sistema come indicato qui di seguito:

HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 299656 "How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases" (in inglese).

Inizio pagina

Passaggio 10. Controllo e registrazione

Il controllo non impedisce gli attacchi al sistema, anche se è una precauzione importante per identificare gli intrusi e gli attacchi in corso e per agevolare la diagnosi delle tracce degli attacchi. Attivare un livello minimo di controllo sul server Web e utilizzare le autorizzazioni NTFS per proteggere i file registro in maniera che un pirata informatico non possa coprire le sue tracce eliminando o aggiornando questi file. Utilizzare il controllo del formato di file registro W3C esteso di IIS.

In questo passaggio verrà descritto come:

Registrare tutti i tentativi di accesso non riusciti

Per poter individuare e tenere traccia di un comportamento sospetto, è necessario registrare i tentativi di accesso non riusciti.

I tentativi di accesso vengono registrati come eventi nel registro eventi di protezione di Windows. Gli ID evento riportati di seguito sono sospetti:

Registrare tutte le azioni non riuscite nel file system

Utilizzare le funzioni di controllo NTFS nel file system per individuare tentativi potenzialmente dannosi. Questo è un processo in due passaggi.

Spostare e proteggere i file registro di IIS

Lo spostamento e l'assegnazione di un nuovo nome ai file registro di IIS rendono più difficile per un pirata informatico coprire le proprie tracce. Prima di poter alterare i file registro, il pirata informatico deve individuarli. Per contrastare ulteriormente le intenzioni di un pirata informatico, utilizzare autorizzazioni NTFS per proteggere i file registro.

Rinominare la directory dei file registro di IIS e spostarla in un volume che non sia il proprio sito Web. Non utilizzare il volume di sistema. Applicare quindi le seguenti autorizzazioni NTFS alla cartella dei file registro e alle sottocartelle.

Archiviare i file registro per l'analisi non in linea

Per facilitare l'analisi non in linea dei file registro di IIS, è possibile utilizzare uno script per automatizzarne la rimozione protetta da un server IIS. I file registro devono essere rimossi almeno ogni 24 ore. Uno script automatizzato può utilizzare FTP, SMTP, HTTP o SMB per trasferire i file registro da un computer server. Se però si attiva uno di questi protocolli, farlo in maniera protetta per evitare di aprire altre opportunità di attacco. Utilizzare un criterio IPSec per proteggere porte e canali.

Controllare l'accesso al file MetaBase.bin

Controllare tutti i tentativi non riusciti, da parte del gruppo Everyone, di accedere al file metabase.bin di IIS posto in \WINNT\System32\inetsrv\. Ripetere il controllo sulla cartella di backup \Metabase per le copie di backup della metabase.

Considerazioni aggiuntive

È inoltre possibile configurare il controllo del formato di file registro W3C esteso di IIS. Selezionare Formato di file registro esteso W3C nella scheda Sito Web della finestra di dialogo delle proprietà del sito Web. Quindi scegliere Proprietà estese quali Origine URI e Query URI.

Inizio pagina

Passaggio 11. Siti e directory virtuali

Spostare le directory Web principali e virtuali in una partizione non di sistema per proteggersi dagli attacchi di attraversamento delle directory che consentono a un pirata informatico di eseguire programmi e utilità del sistema operativo. Non è possibile attraversare le unità. Questo approccio provoca il fallimento di qualsiasi futuro worm canonicalization che permette a un pirata informatico di accedere ai file di sistema. Se il pirata informatico formula, ad esempio, un URL che contiene il seguente percorso, la richiesta non riesce:

/scripts/..%5c../winnt/system32/cmd.exe

In questo passaggio verrà descritto come:

Spostare il sito Web in un volume non di sistema

Non utilizzare la directory predefinita \inetpub\wwwroot. Se ad esempio il sistema è installato nell'unità C:, è possibile spostare il sito e la directory con il relativo contenuto nell'unità D:. Si riducono così i rischi associati a problemi imprevisti di canonicalization e attacchi di attraversamento delle directory.

Disattivare l'impostazione dei percorsi principali

Questa impostazione della metabase di IIS impedisce di utilizzare ".." nello script e impedisce alle chiamate di applicazioni di fungere da MapPath. Contribuisce quindi a proteggere da attacchi di attraversamento delle directory.

Nota: se si utilizza Application Center 2002 Administration Site, vedere l'articolo della Microsoft Knowledge Base 288309, "PRB: Disabling Parent Paths Breaks User Interface" (in inglese).

Rimuovere le directory virtuali potenzialmente pericolose

Le applicazioni di esempio non sono installate per impostazione predefinita e non devono essere installate nei server Web di produzione. Rimuovere tutte le applicazioni di esempio, comprese quelle alle quali è possibile accedere solo dal computer locale con http://localhost o http://127.0.0.1.

Rimuovere le seguenti directory virtuali dai server di produzione: IISSamples, IISAdmin, IISHelp e Scripts.

Nota: IISLockdown fornisce un'opzione per rimuovere le directory virtuali Scripts, IISSamples, IISAdmin e IISHelp.

Rimuovere o proteggere RDS

Remote Data Services (RDS) è un componente che permette l'accesso Internet controllato alle risorse dei dati remoti tramite IIS. L'interfaccia RDS viene fornita da Msadcs.dll, che si trova nella directory seguente: Programmi\File comuni\System\msadc.

Rimozione di RDS

Se l'applicazione non utilizza RDS, rimuoverlo.

Nota: IISLockdown fornisce un'opzione per rimuovere la directory virtuale MSADC. Tenere presente che IISLockdown rimuove solo la directory virtuale, non i file o la chiave del Registro di sistema.

Protezione di RDS

Se l'applicazione richiede RDS, proteggerlo.

Nota: è possibile utilizzare il file script del Registro di sistema Handsafe.reg per cambiare la chiave del Registro di sistema. Il file script si trova nella directory msadc:

\Programmi\File comuni\System\msadc

Per ulteriori informazioni sulla protezione di RDS, vedere quanto segue:

Impostare autorizzazioni Web

Le autorizzazioni Web sono configurate tramite lo snap-in IIS e sono conservate nella metabase IIS. Non si tratta di autorizzazioni NTFS.

Utilizzare le autorizzazioni Web seguenti:

Rimuovere o proteggere Estensioni server FrontPage

Se non si utilizza Estensioni server FrontPage (FPSE, FrontPage Server Extensions), disattivarlo. Se si utilizza FPSE, prendere le seguenti precauzioni per migliorare la protezione:

Inizio pagina

Passaggio 12. Mapping degli script

I mapping degli script associano una particolare estensione file, ad esempio asp, all'estensione ISAPI che la gestisce, ad esempio Asp.dll. IIS è configurato per supportare un intervallo di estensioni incluse asp, shtm, hdc e altre ancora. I gestori HTTP di ASP.NET equivalgono approssimativamente alle estensioni ISAPI. In IIS, estensioni file quali aspx, vengono prima di tutto mappate in IIS a Aspnet_isapi.dll, che inoltra la richiesta al processo di lavoro di ASP.NET. Il gestore HTTP effettivo che elabora l'estensione file viene quindi stabilito dal mapping <HttpHandler> in Machine.config o Web.config.

Qui di seguito sono riportati i principali problemi relativi alla protezione associati ai mapping degli script:

In questo passaggio verrà descritto come:

Mappare le estensioni file di IIS

In Windows 2000, le estensioni file di IIS da prendere in considerazione sono: asp, asa, cer, cdx, htr, idc, shtm, shtml, stm e printer.

Se non si utilizza una qualsiasi di queste estensioni, mapparla a 404.dll, fornito da IISLockdown. Se, ad esempio, non si desidera fornire le pagine ASP ai client, mappare asp a 404.dll.

I mapping modificati da IISLockdown dipendono dal modello server scelto:

Ragioni del mapping a 404.dll

Il mapping delle estensioni file a 404.dll impedisce ai file di essere restituiti e scaricati su HTTP. Se si richiede un file con un'estensione mappata a 404.dll, viene visualizzata una pagina Web con il messaggio "HTTP 404 - File not found". Si consiglia di mappare le estensioni non utilizzate a 404.dll, invece di eliminare il mapping. Se si elimina un mapping e per errore nel server viene lasciato o messo un file, il file può essere visualizzato non crittografato quando viene richiesto perché IIS non sa come elaborarlo.

•

Per mappare un'estensione file a 404.dll 1. Avviare IIS. 2. Fare clic con il pulsante destro del mouse sul nome server nella finestra di sinistra, quindi scegliere Proprietà. 3. Controllare che nell'elenco a discesa Proprietà master sia selezionato WWWService, quindi scegliere il pulsante Modifica accanto. 4. Fare clic sulla scheda Home Directory. 5. Fare clic su Configurazione. Viene visualizzata la pagina a schede illustrata nella Figura 16.4. Figura 16.4 Mapping delle estensioni delle applicazioni 6. Selezionare una delle estensioni dall'elenco, quindi scegliere Edit. 7. Fare clic su Browse e portarsi su \WINNT\system32\inetsrv\404.dll. Nota: questo passaggio presume che in precedenza sia stato eseguito IISlockd.exe, dato che 404.dll è installato dallo strumento IISLockdown. 8. Fare clic su Open, quindi scegliere OK. 9. Ripetere i passaggi 6, 7 e 8 per tutte le altre estensioni file.

Mappare le estensioni file di .NET Framework

Le seguenti estensioni file di .NET Framework vengono mappate ad aspnet_isapi.dll: asax, ascx, ashx, asmx, aspx, axd, vsdisco, jsl, java, vjsproj, rem, soap, config, cs, csproj, .vb, vbproj, webinfo, licx, resx e resources.

.NET Framework protegge le estensioni file che non devono essere chiamate direttamente dai client associandole con System.Web.HttpForbiddenHandler in Machine.config. Le seguenti estensioni file vengono mappate a System.Web.HttpForbiddenHandler, per impostazione predefinita: asax, ascx, config, cs, csproj, vb, vbproj, webinfo, asp, licx, resx e resources.

Per ulteriori informazioni sui gestori HTTP, vedere "Passaggio 16: Machine.config".

Considerazioni aggiuntive

Dato che IIS elabora per prima una richiesta Web, le estensioni file di .NET Framework che non si desidera vengano chiamate dai client potrebbero essere mappate direttamente a 404.dll. In questo caso avvengono due operazioni:

Inizio pagina

Passaggio 13. Filtri ISAPI

In passato, le vulnerabilità nei filtri ISAPI erano fonte di grave sfruttamento di IIS. Non vi sono filtri ISAPI non necessari dopo una normale installazione di IIS, sebbene .NET Framework installi il filtro ISAPI di ASP.NET (Aspnet_filter.dll), che viene caricato nello spazio dell'indirizzo di processo di IIS (Inetinfo.exe) ed è utilizzato per supportare la gestione dello stato sessione senza cookie.

Se le applicazioni non devono supportare lo stato sessione senza cookie e non impostano l'attributo cookieless su true nell'elemento <sessionState>, questo filtro può essere rimosso.

Durante questo passaggio si rimuovono i filtri ISAPI non utilizzati.

Rimuovere i filtri ISAPI non utilizzati

Rimuovere tutti i filtri ISAPI non utilizzati come spiegato nella sezione seguente.

•

Per visualizzare i filtri ISAPI 1. Per avviare IIS, selezionare Gestione servizi Internet dal gruppo di programmi Strumenti di amministrazione. 2. Fare clic con il pulsante destro del mouse sul computer (non sul sito Web, perché i filtri sono a livello di computer), quindi scegliere Proprietà. 3. Fare clic su Modifica. 4. Fare clic sulla scheda Filtri ISAPI. Viene visualizzata la pagina a schede illustrata nella Figura 16.5: Figura 16.5 Rimozione dei filtri ISAPI inutilizzati

Inizio pagina

Passaggio 14. Metabase IIS

Le impostazioni di protezione e altre impostazioni di configurazione di IIS vengono mantenute nel file metabase IIS. Rafforzare le protezioni delle autorizzazioni NTFS sulla metabase IIS (e sul file metabase di backup) per evitare che i pirati informatici possano modificare in qualche modo la configurazione di IIS, ad esempio per disattivare l'autenticazione per una particolare directory virtuale.

In questo passaggio verrà descritto come:

Limitare l'accesso alla metabase utilizzando le autorizzazioni NTFS

Impostare le seguenti autorizzazioni NTFS sul file metabase IIS (Metabase.bin) nella directory \WINNT\system32\inetsrv.

Limitare le informazioni di intestazione restituite da IIS

Le informazioni di intestazione possono rivelare le versioni software e altri dati che possono agevolare gli attacchi da parte di utenti malintenzionati. Possono rivelare ad esempio il software in esecuzione, permettendo a un pirata informatico di sfruttarne le vulnerabilità conosciute.

Quando si recupera una pagina statica, ad esempio un file htm o gif, alla risposta viene aggiunta un'intestazione con il percorso del contenuto. Per impostazione predefinita, questa intestazione con il contenuto fa riferimento all'indirizzo IP e non al nome di dominio completo (FQDN, Fully Qualified Domain Name). Questo significa che l'indirizzo IP interno viene involontariamente esposto. La seguente intestazione di risposta HTTP, ad esempio, mostra l'indirizzo IP in grassetto:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://10.1.1.1/Default.htm
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

Per nascondere il percorso del contenuto restituito nelle intestazioni di risposta HTTP, modificare un valore nella metabase IIS per cambiare il funzionamento predefinito e far sì che invece dell'esposizione degli indirizzi IP venga inviato l'FQDN.

Per ulteriori informazioni sull'occultamento del percorso del contenuto nelle risposte HTTP, vedere l'articolo della Microsoft Knowledge Base 218180, "Internet Information Server Returns IP Address in HTTP Header (Content-Location)" (in inglese).

Inizio pagina

Passaggio 15. Certificati server

Se l'applicazione Web supporta HTTPS (SSL) sulla porta 443, è necessario installare un certificato server. Questa installazione è richiesta come parte del processo di negoziazione della sessione che ha luogo quando un client stabilisce una sessione HTTPS protetta.

Un certificato valido fornisce un'autenticazione protetta, per cui un client può dare attendibilità al server con cui comunica, e protegge le comunicazioni in maniera che i dati riservati rimangano tali e non possano essere manomessi in rete.

Durante questo passaggio, viene convalidato il certificato server.

Convalidare il certificato server

Controllare i quattro punti seguenti per verificare la validità del certificato server Web:

Inizio pagina

Passaggio 16. Machine.Config

In questa sezione vengono date informazioni su come rafforzare la protezione delle impostazioni a livello di computer valide per tutte le applicazioni. Per impostazioni specifiche di protezione avanzata per le applicazioni, vedere il modulo 19 "Protezione dell'applicazione ASP.NET e dei servizi Web".

Il file Machine.config mantiene numerose impostazioni a livello di computer per .NET Framework, molte delle quali influiscono sulla protezione. Machine.config si trova nella directory seguente:

%windir%\Microsoft.NET\Framework\{versione}\CONFIG

Nota: per modificare i file di configurazione XML è possibile utilizzare qualsiasi editor di testo o XML (Blocco note, ad esempio). I tag XML distinguono tra maiuscole e minuscole, pertanto è necessario controllare che questa distinzione venga rispettata.

In questo passaggio verrà descritto come:

Mappare le risorse protette a HttpForbiddenHandler

I gestori HTTP si trovano in Machine.config sotto l'elemento <httpHandlers>. I gestori HTTP consentono l'elaborazione delle richieste Web relative a estensioni file specifiche. Il Remoting non deve essere attivato sui server Web front-end. Attivarlo solo sui server per applicazioni che sono isolati da Internet.

In Machine.config le seguenti estensioni file sono mappate ai gestori HTTP:

Per le risorse di .NET Framework, se non si utilizza un'estensione file mapparla a System.Web.HttpForbiddenHandler in Machine.config, come mostrato nell'esempio seguente:

<add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" />

In questo caso l'estensione file vbproj è mappata a System.Web.HttpForbiddenHandler. Se un client richiede un percorso che termina con vbproj, ASP.NET restituisce il messaggio "This type of page is not served".

Per la gestione delle estensioni file di .NET Framework vengono applicate le linee guida seguenti:

Disattivare .NET Remoting

Per disattivare .NET Remoting, disattivare le richieste di estensioni rem e soap utilizzando i seguenti elementi sotto <httpHandlers>:

<add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/>

Nota: ciò non impedisce il collegamento di un'applicazione Web residente su un server Web a un oggetto a valle mediante l'infrastruttura di Remoting. Impedisce però ai client di connettersi agli oggetti nel server Web.

Controllare che le funzionalità di analisi siano disattivate

Per configurare le funzionalità di analisi in Machine.config, utilizzare l'elemento <trace>. Anche se la funzionalità di analisi è utile sui server di sviluppo e di test, non attivarla sui server di produzione, perché le informazioni di analisi a livello di sistema possono essere di grande aiuto a un pirata informatico per il profiling di un'applicazione e per sondarne i punti deboli.

Sui server di produzione, utilizzare la configurazione seguente:

<trace enabled="false" localOnly="true" pageOutput="false" 
	 requestLimit="10" traceMode="SortByTime"/>

Impostare enabled="false" sui server di produzione. Se è indispensabile analizzare i problemi delle applicazioni installate, simulare il problema in un ambiente di test oppure, se necessario, attivare la funzionalità di analisi e impostare localOnly="true" per evitare che i dettagli dell'analisi vengano restituiti ai client remoti.

Controllare che le compilazioni di debug siano disattivate

È possibile controllare se il compilatore produce build di debug che includono i simboli di debug utilizzando l'elemento <compilation>. Per disattivare le compilazioni di debug, impostare debug="false" come indicato qui di seguito:

<compilation debug="false" explicit="true" defaultLanguage="vb" />

Controllare che al client non vengano restituiti errori ASP.NET

È possibile utilizzare l'elemento <customErrors> per configurare messaggi di errore generici personalizzati che devono essere restituiti al client qualora si verifichi una condizione di eccezione dell'applicazione.

Controllare che l'attributo di tipo mode sia impostato su "RemoteOnly" come indicato nell'esempio seguente:

<customErrors mode="RemoteOnly" />

Dopo aver installato un'applicazione ASP.NET, è possibile configurare l'impostazione in modo che indirizzi alla pagina di errori personalizzata, come illustrato nell'esempio seguente:

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

Controllare le impostazioni dello stato sessione

Se non si utilizza lo stato sessione, controllare che sia disattivato in Machine.config come illustrato nell'esempio seguente:

<sessionState mode="Off" . . . />

Controllare inoltre che ASP.NET State Service sia disattivato. La modalità dello stato sessione predefinita è "InProc" e ASP.NET State Service è impostato su manuale. Per ulteriori informazioni sulla protezione dello stato sessione se si installa un'applicazione ASP.NET che la richiede, vedere "Stato sessione" nel modulo 19 "Protezione dell'applicazione ASP.NET e dei servizi Web".

Inizio pagina

Passaggio 17. Protezione dall'accesso di codice

Il criterio di protezione dall'accesso di codice a livello di computer è determinato dalle impostazioni nel file Security.config che si trova nella directory seguente:
%windir%\Microsoft.NET\Framework\{versione}\CONFIG

Eseguire il comando seguente per essere certi che nel server sia attivata la protezione dall'accesso di codice:

caspol -s On

Per ulteriori informazioni sulla configurazione della protezione dall'accesso di codice per le applicazioni Web ASP.NET, vedere il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET".

In questo passaggio verrà descritto come:

Rimuovere tutte le autorizzazioni per l'area Intranet locale

L'area Intranet locale applica le autorizzazioni al codice eseguito da condivisioni UNC o siti Web interni. Riconfigurare quest'area per non concedere autorizzazioni associandola all'autorizzazione Nothing impostata.

•

Per rimuovere tutte le autorizzazioni per l'area Intranet locale 1. Avviare lo strumento Microsoft .NET Framework Configuration 1.1 dal gruppo di programmi Strumenti di amministrazione. 2. Espandere Runtime Security Policy, Machine, quindi Code Groups. 3. Espandere All_Code quindi selezionare LocalIntranet_Zone. 4. Fare clic su Edit Code Group Properties. 5. Fare clic sulla scheda Permission Set. 6. Selezionare Nothing dall'elenco a discesa Permission. 7. Scegliere OK. Viene visualizzata la finestra di dialogo illustrata nella Figura 16.6.

Figura 16.6
Impostazione delle autorizzazioni del codice LocalIntranet_Zone su Nothing

Rimuovere tutte le autorizzazioni per l'area Internet

L'area Internet applica le autorizzazioni di accesso al codice, al codice scaricato via Internet. Sui server Web, riconfigurare quest'area per non concedere autorizzazioni associandola al set di autorizzazioni Nothing.

Ripetere i passaggi illustrati nella sezione precedente, "Rimuovere tutte le autorizzazioni per l'area Intranet locale" ma impostare Internet_Zone sul set di autorizzazioni Nothing.

Inizio pagina

Riepilogo delle caratteristiche di un server Web protetto

Il riepilogo degli attributi di un server Web protetto permette di confrontare rapidamente e facilmente le impostazioni con quelle del proprio server Web. Le impostazioni riportate nella Tabella 16.5 sono basate su server Web che ospitano siti Web che si sono rivelati molto resistenti agli attacchi e dimostrano pratiche di protezione efficaci. Seguendo i passaggi precedenti è possibile generare un server configurato in maniera identica, rispetto alla protezione.

Tabella 16.5: Riepilogo delle caratteristiche di un server Web protetto

<httpHandlers>
<add verb="*" path="*.rem" 
	type="System.Web.HttpForbiddenHandler"/>  
<add verb="*" path="*.soap"       
	 type="System.Web.HttpForbiddenHandler"/>
 </httpHandlers>

<trace  enabled="false">

<compilation debug="false"/>

<customErrors mode="On" /> 

<sessionState  mode="Off" />

Inizio pagina

Mantenimento della protezione

È necessario controllare lo stato di protezione del server e aggiornarlo regolarmente per impedire che vengano sfruttate le vulnerabilità scoperte di recente. Per proteggere il server:

Controllare l'appartenenza ai gruppi

Tenere traccia dell'appartenenza ai gruppi utenti, in particolar modo per gruppi privilegiati quale Administrators. Nel comando seguente sono elencati i membri del gruppo Administrators:

net localgroup administrators

Monitorare i registri di controllo

Monitorare regolarmente i registri di controllo e analizzare i file registro visualizzandoli manualmente oppure utilizzare la tecnica descritta nell'articolo della Microsoft Knowledge Base 296085, "How To: Use SQL Server to Analyze Web Logs" (in inglese).

Disporre di service pack e di patch aggiornati

Impostare un programma per analizzare il software per i server e iscriversi agli avvisi per la protezione. Utilizzare MBSA per eseguire periodicamente la scansione del server alla ricerca di patch mancanti. Gli ultimi aggiornamenti sono disponibili tramite i collegamenti seguenti:

Eseguire verifiche della protezione

MBSA può essere utilizzato per verificare periodicamente la presenza di vulnerabilità di protezione e per identificare le patch e gli aggiornamenti mancanti. È consigliabile pianificarne l'esecuzione quotidiana e analizzare i risultati in modo da poter adottare le misure necessarie. Per ulteriori informazioni sull'automazione di MBSA, vedere "Procedura: Utilizzo di Microsoft Baseline Security Analyzer" nella sezione "Procedure" di questa Guida.

Utilizzare il servizio Security Notification Services

Utilizzare i servizi Microsoft elencati nella Tabella 16.3 per ottenere i bollettini sulla sicurezza con la notifica delle possibili vulnerabilità del sistema.

Tabella 16.3 Security Notification Services

Inoltre, iscriversi ai servizi di gestione degli avvisi per la protezione industriale mostrati nella Tabella 16.4. Ciò consente di valutare il pericolo di una vulnerabilità per la quale non è ancora disponibile una patch.

Tabella 16.4 Industry Security Notification Services

Inizio pagina

Amministrazione remota

Spesso gli amministratori devono essere in grado di amministrare più server. Accertarsi che i requisiti della soluzione di amministrazione remota adottata non compromettano la protezione. Se sono richieste capacità di amministrazione remota, ai fini di una migliore protezione possono risultare utili le raccomandazioni seguenti:

Protezione di Servizi terminal

È possibile utilizzare Servizi terminal di Microsoft in maniera protetta per amministrare in modalità remota il proprio server Web.

Servizi terminal è basato sul protocollo proprietario RDP (Remote Desktop Protocol, Protocollo desktop remoto) Microsoft. Il protocollo RDP utilizza la porta 3389 TCP e supporta due utenti simultanei. Nelle sezioni seguenti vengono descritte le procedure di installazione e configurazione di Servizi terminal per usufruire di funzioni di amministrazione protette:

Installare Servizi terminal

Per installare Servizi terminal:

Configurare Servizi terminal

Utilizzare lo snap-in MMC Configurazione di Servizi terminal disponibile nel gruppo di programmi Strumenti di amministrazione per configurare quanto segue:

Per usufruire di funzioni di protezione avanzate, utilizzare una connessione VPN protetta tra il client e il server oppure le funzioni di tunneling IPSec. Questo approccio fornisce un'autenticazione reciproca e il payload RDP viene crittografato.

Copia di file con il protocollo RDP

In Servizi terminal non sono disponibili funzioni incorporate per il trasferimento dei file. È tuttavia possibile installare l'utilità File Copy dal Resource Kit di Windows 2000 Server per aggiungere le funzionalità di trasferimento alla funzione di reindirizzamento clipboard di Servizi terminal. Per ulteriori informazioni sull'utilità e sulle istruzioni di installazione, vedere l'articolo della Microsoft Knowledge Base 244732, "How To: Install the File Copy Tool Included with the Windows 2000 Resource Kit" (in inglese).

Inizio pagina

Semplificazione e automatizzazione della protezione

In questo modulo è stato illustrato come configurare manualmente le impostazioni di protezione per un server Web ASP.NET. Il processo manuale aiuta a capire la configurazione ma può richiedere molto tempo. Per meglio automatizzare i passaggi presentati in questo modulo, utilizzare le risorse seguenti:

Inizio pagina

Riepilogo

Un server Web protetto rappresenta una base sicura per ospitare le applicazioni Web. In questo modulo sono stati illustrati i pericoli principali che possono avere ripercussioni sul server Web ASP.NET e sono stati indicati i passaggi di protezione richiesti per ridurre questi pericoli. Seguendo queste indicazioni è possibile creare una piattaforma protetta e ospitare un'infrastruttura per supportare applicazioni Web ASP.NET e servizi Web.

La metodologia utilizzata in questo modulo consente di creare un server Web protetto partendo da zero e di rafforzare la configurazione di protezione di un server Web esistente. Il passaggio successivo consiste nel controllare che tutte le applicazioni distribuite siano configurate in maniera corretta.

Inizio pagina

Ulteriori risorse

Per ulteriori informazioni, consultare le risorse seguenti:

Inizio pagina