The Cable GuyModelli host forti e vulnerabili

Joseph Davies

La configurazione sempre più comune per gli host di rete è multihomed con più interfacce di rete. Un host multihomed fornisce una migliore connettività perché è in grado di collegarsi contemporaneamente a più reti, come intranet o Internet. Proprio perché possono essere connessi sia alla rete intranet che a

Internet, tuttavia, i servizi in esecuzione su host multihomed possono essere vulnerabili ad attacchi. Per evitarli e per avere un'idea di come viene elaborato il traffico IP per un host multihomed, di seguito viene riportata una rapida panoramica sui modelli di host multihomed forti e vulnerabili e quindi viene descritto come tali modelli sono supportati in Windows®.

RFC 1122 è la specifica che descrive i due modelli per un host multihomed che non funziona come router ma invia e riceve solamente traffico IP unicast. Questi modelli, noti come host forte e host vulnerabile, specificano se il traffico unicast inviato o ricevuto deve essere associato all'interfaccia di rete su cui il traffico viaggia. Determinano, inoltre, il modo in cui un host invia e riceve pacchetti e influisce sulla vulnerabilità dei servizi in esecuzione sull'host.

Sebbene RFC 1122 definisca questi modelli per IPv4, essi si applicano anche a IPv6. Esempio di un host multihomed per IPv6 è un computer che utilizza sia IPv4 che IPv6 che disponga di un adattatore di rete connesso a una rete intranet e un'interfaccia di tunneling IPv6.

Modello host vulnerabile

Nel modello host vulnerabile, un host IP (IPv4 o IPv6) può inviare pacchetti a un'interfaccia a cui non è assegnato l'indirizzo IP di origine del pacchetto inviato. Ciò è noto come processo di invio dell'host vulnerabile. Un host IP può anche ricevere pacchetti su un'interfaccia a cui non è assegnato l'indirizzo IP di destinazione del pacchetto ricevuto. Ciò è noto come processo di ricezione dell'host vulnerabile.

Quando si dispone di un host IP multihomed con più interfacce, l'attivazione del processo di ricezione dell'host vulnerabile sulle interfacce potrebbe rendere l'host vulnerabile ad attacchi multihome. Ad esempio, la Figura 1 mostra l'Host A connesso sia a Internet che a intranet. L'Host A dispone dell'indirizzo IPv4 pubblico 131.107.89.211 assegnato alla relativa interfaccia Internet e dell'indirizzo IPv4 privato 192.168.17.48 assegnato alla relativa interfaccia intranet.

Figura 1** Esempio di un computer multihomed **

Con il processo di invio dell'host vulnerabile attivato sia sull'interfaccia Internet che intranet, l'Host A può inviare pacchetti da 131.107.89.211 sulla relativa interfaccia Internet, pacchetti da 192.168.17.48 sulla relativa interfaccia Internet, pacchetti da 131.107.89.211 sulla relativa interfaccia intranet e pacchetti da 192.168.17.48 sulla relativa interfaccia intranet.

Con il processo di ricezione dell'host vulnerabile attivato, l'Host A può ricevere i seguenti tipi di pacchetti (supponendo che le regole del firewall dell'host consentano il traffico in entrata): pacchetti a 131.107.89.211 sulla relativa interfaccia Internet, pacchetti a 192.168.17.48 sulla relativa interfaccia Internet, pacchetti a 131.107.89.211 sulla relativa interfaccia intranet, pacchetti a 192.168.17.48 sulla relativa interfaccia intranet.

Quando si dispone del processo di ricezione dell'host vulnerabile attivato, un utente malintenzionato su Internet può inviare pacchetti all'interfaccia Internet dell'Host A per attaccare i servizi in esecuzione sull'Host A disponibili solo per gli host sulla rete intranet. Questo tipo di attacco può verificarsi se l'infrastruttura di Internet supporta l'inoltro di pacchetti destinati a 192.168.17.48 all'interfaccia Internet dell'Host A. È possibile evitarlo impostando le regole del firewall appropriate sull'interfaccia Internet dell'Host A. Anche facendo questo, tuttavia, i servizi in esecuzione sull'Host A disponibili per i client intranet possono essere a rischio.

Modello host forte

Nel modello host forte, i processi di ricezione e invio sono diversi. Con le operazioni di invio dell'host forte, l'host può inviare pacchetti a un'interfaccia solo se all'interfaccia è assegnato l'indirizzo IP di origine del pacchetto inviato. Con le operazioni di ricezione dell'host forte, l'host può ricevere pacchetti su un'interfaccia solo se all'interfaccia è assegnato l'indirizzo IP di destinazione del pacchetto ricevuto.

Con il processo di invio dell'host forte attivato sulle relative interfacce Internet e intranet, l'Host A nella Figura 1 può solo inviare pacchetti da 131.107.89.211 sulla relativa interfaccia Internet e pacchetti da 192.168.17.48 sulla relativa interfaccia intranet.

Con il processo di ricezione dell'host forte attivato, l'Host A può solo ricevere pacchetti a 131.107.89.211 sulla relativa interfaccia Internet e pacchetti a 192.168.17.48 sulla relativa interfaccia intranet.

Nella Figura 1, il modello di host forte per l'Host A lascia cadere tutti i pacchetti in entrata sull'interfaccia Internet indirizzati a 192.168.17.48 senza bisogno che l'utente configuri le regole del firewall, isolando efficacemente l'interfaccia intranet dell'Host A da Internet.

Quando si seleziona il modello di host forte, tenere presente che ciò potrebbe influire su alcuni tipi di connettività progettati per il processo dell'host vulnerabile. Ad esempio, alcune implementazioni di bilanciamento del carico potrebbero utilizzare il processo di ricezione dell'host vulnerabile per ricevere pacchetti su qualsiasi interfaccia e quindi indirizzarli all'interfaccia appropriata internamente. Anche un host che utilizza le operazioni di invio dell'host vulnerabile per inviare dati da qualsiasi indirizzo di origine su un'interfaccia corrispondente a una connessione veloce potrebbe essere interessato.

Invio e ricezione dell'host forte

Verrà ora illustrato il modo in cui si svolge il processo di invio e ricezione su un host generico per IPv4 o per IPv6 quando le operazioni di ricezione e invio dell'host forte vengono attivate o disattivate sulle singole interfacce.

Per i pacchetti inviati, l'IP verifica prima se è già stato specificato un indirizzo di origine. Se così non fosse, l'IP esegue una ricerca libera dell'indirizzo di destinazione del pacchetto nella tabella di routing. In una ricerca libera, vengono considerate tutte le route nella tabella di routing. In base alla route selezionata per la destinazione, l'IP determina l'interfaccia hop successiva (l'interfaccia utilizzata per posizionare il pacchetto a livello di collegamento) e l'indirizzo hop successivo. In base all'interfaccia hop successiva, l'IP utilizza il processo di selezione dell'indirizzo definito in RFC 3484 come necessario per determinare l'indirizzo di origine migliore. A questo punto, l'IP dispone di tutto ciò di cui necessita per inviare il pacchetto: gli indirizzi di origine e destinazione, l'interfaccia hop successiva e l'indirizzo hop successivo.

Se l'indirizzo di origine è stato specificato, l'interfaccia di origine è nota. All'interfaccia di origine viene assegnato l'indirizzo di origine. L'IP quindi determina se le operazioni di invio dell'host forte sono attivate sull'interfaccia di origine.

Se sono disattivate, l'IP esegue una ricerca libera dell'indirizzo di destinazione del pacchetto nella tabella di routing. In base alla migliore route corrispondente per la destinazione, l'IP determina l'interfaccia hop successiva e l'indirizzo hop successivo. L'IP dispone degli indirizzi di origine e destinazione, l'interfaccia hop successiva e l'indirizzo hop successivo. Si noti che con il processo di invio dell'host forte disattivato sull'interfaccia di origine, l'interfaccia hop successiva potrebbe non essere uguale all'interfaccia di origine.

Se le operazioni di invio dell'host forte sono attivate sull'interfaccia di origine, l'IP esegue una ricerca vincolata dell'indirizzo di destinazione del pacchetto nella tabella di routing. In una ricerca vincolata, vengono considerate solo le route con un'interfaccia hop successiva dell'interfaccia di origine. In base alla route selezionata per la destinazione, l'IP determina l'indirizzo hop successivo. L'IP dispone degli indirizzi di origine e destinazione, l'interfaccia hop successiva e l'indirizzo hop successivo. Si noti che con il processo di invio dell'host forte attivato sull'interfaccia di origine, l'interfaccia hop successiva è sempre uguale all'interfaccia di origine. Nella Figura 2 viene illustrato il processo host di invio IP generico.

Figura 2** Processo host di invio IP generico **(Fare clic sull'immagine per ingrandirla)

Quando è stato specificato l'indirizzo di origine, la ricerca vincolata della route può selezionare una route con una metrica superiore tra più route nella tabella di routing che hanno una maggiore corrispondenza con la destinazione. Ad esempio, l'Host A nella Figura 1 dispone di due route predefinite, una diretta a Internet con una metrica di 10 e una diretta a intranet con una metrica di 20. Il processo dell'host forte è attivato su entrambe le interfacce LAN.

Se l'applicazione di invio sull'Host A non specifica un indirizzo di origine, il risultato della ricerca di route è la route predefinita con la metrica più bassa; l'Host A invia sempre il traffico all'esterno dell'interfaccia Internet con un indirizzo di origine di 131.107.89.211. Tuttavia, se l'applicazione di invio sull'Host A specifica un indirizzo di origine di 131.107.89.211, il risultato della ricerca è la route predefinita per l'interfaccia Internet; l'Host A invia il traffico all'esterno dell'interfaccia Internet. Se l'applicazione di invio sull'Host A specifica un indirizzo di origine di 192.168.17.48, la ricerca seleziona la route predefinita per l'interfaccia intranet; l'Host A invia il traffico all'esterno dell'interfaccia intranet. Con la ricerca di route vincolata, l'IP invia dati con un indirizzo di origine di 192.168.17.48 utilizzando la route predefinita con la metrica più alta.

Per il traffico ricevuto, l'IP innanzitutto determina se è destinato all'host. Se non lo fosse, l'IP elimina silenziosamente il pacchetto perché l'host non sta funzionando come router. L'IP quindi determina se le operazioni di ricezione dell'host forte sono attivate sull'interfaccia in entrata (l'interfaccia su cui è stato ricevuto il pacchetto). Se sono disattivate, elabora il pacchetto. Se sono attivate, determina se l'indirizzo di destinazione nel pacchetto è assegnato all'interfaccia in entrata. In questo caso, elabora il pacchetto. Altrimenti, elimina silenziosamente il pacchetto. Nella Figura 3 viene mostrato il processo host di ricezione generico.

Figura 3** Processo host di ricezione **

Processo host forte e vulnerabile in Windows

Windows XP e Windows Server® 2003 utilizzano il modello di host vulnerabile per le operazioni di invio e ricezione per tutte le interfacce IPv4 e il modello di host forte per le operazioni di invio e ricezione per tutte le interfacce IPv6. Non è possibile configurare questo processo. Lo stack TCP/IP di ultima generazione di Windows Vista e Windows Server 2008 supporta le operazioni di invio e ricezione dell'host forte sia per IPv4 che per IPv6 per impostazione predefinita su tutte le interfacce eccetto l'interfaccia di tunneling Teredo per una trasmissione specifica dell'host Teredo. Nella Figura 4 vengono elencati i comandi che è possibile utilizzare per configurare il processo di invio e ricezione sia per IPv4 che per IPv6 su ogni singola interfaccia. Si noti che InterfaceNameOrIndex è il nome dell'interfaccia dalla cartella Connessioni di rete o l'indice della relativa interfaccia. È possibile ottenere l'indice di un'interfaccia dalla visualizzazione del comando:

Figure 4 Comandi per configurare il processo di invio e ricezione forte e vulnerabile

netsh interface ipv6 show interface

Processo host forte e vulnerabile e RFC 3484

Per fornire un metodo standardizzato di scelta degli indirizzi IPv6 e IPv4 di origine e destinazione con cui tentare le connessioni, RFC 3484 definisce due algoritmi. Il primo è un algoritmo di selezione dell'indirizzo di origine per scegliere l'indirizzo di origine migliore da utilizzare con un indirizzo di destinazione. L'altro è un algoritmo di selezione dell'indirizzo di destinazione per ordinare l'elenco dei possibili indirizzi di destinazione in base alla preferenza.

Il processo host forte e vulnerabile è in realtà la determinazione dell'elenco di possibili indirizzi di origine per un dato indirizzo di destinazione e riguarda anche l'elenco finale ordinato di indirizzi di destinazione. Per il processo di invio dell'host forte, l'elenco dei possibili indirizzi di origine consiste negli indirizzi unicast assegnati all'interfaccia di invio per la destinazione. Per il processo di invio dell'host vulnerabile, l'elenco dei candidati può contenere indirizzi assegnati a qualsiasi interfaccia che disponga delle operazioni di invio dell'host vulnerabile attivate. Per ulteriori informazioni sulla selezione dell'indirizzo di origine e destinazione, andare all'indirizzo microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

Per impostazione predefinita, sia le operazioni di invio che di ricezione dell'host vulnerabile sono disattivate sia per IPv4 che per IPv6, per tutte le interfacce eccetto l'interfaccia di tunneling Teredo per una trasmissione specifica dell'host Teredo.

Per ulteriori informazioni su RFC 3484, vedere la sezione "Processo host forte e vulnerabile e RFC 3484".

Disattivazione delle route predefinite per le connessioni VPN di accesso remoto

Un client VPN (Virtual Private Network) di accesso remoto è un altro esempio di host multihomed. Sebbene possa disporre di un'unica interfaccia LAN connessa a Internet, quando un client VPN di accesso remoto completa una connessione VPN, significa che è multihomed. Dispone di due interfacce: l'interfaccia LAN e un'interfaccia basata su Point-to-Point Protocol (PPP) per la connessione VPN. Dispone anche di due indirizzi IPv4: un indirizzo IPv4 assegnato dal provider di servizi Internet per l'interfaccia LAN e un indirizzo IPv4 assegnato dal server VPN per l'interfaccia basata su PPP.

Per accertarsi che il client VPN invii traffico della route predefinita attraverso la connessione VPN alla rete intranet, Windows XP e Windows Server 2003 modificano la tabella di routing IPv4 aumentando la metrica della route esistente predefinita e aggiungendo una nuova route predefinita con una metrica inferiore che utilizza l'interfaccia PPP. Questo processo predefinito rende i percorsi su intranet accessibili e quasi tutti i percorsi su Internet non accessibili per la durata della connessione VPN. È possibile configurare un client VPN in modo che suddivida il tunneling per disporre dell'accesso simultaneo ai percorsi Internet e intranet non aggiungendo la route predefinita per la connessione VPN e aggiungendo route specifiche per le destinazioni intranet. Tuttavia, suddividendo il tunneling si corre il rischio che i client VPN possano indirizzare i pacchetti tra Internet e intranet. Per ulteriori informazioni, andare all'indirizzo microsoft.com/technet/community/columns/cableguy/cg1003.mspx.

Il processo predefinito del client VPN in Windows XP e Windows Server 2003 è stato progettato per il processo di invio dell'host vulnerabile. La ricerca di route utilizza sempre la route predefinita per la connessione VPN perché dispone della metrica inferiore. Tuttavia, quando si utilizza il processo di invio dell'host forte, la route predefinita utilizzata per il traffico inviato dipende dall'indirizzo IP di origine nel pacchetto. La ricerca di route del traffico dall'indirizzo IPv4 assegnato dall'ISP utilizzerà la route predefinita che utilizza l'interfaccia LAN, rendendo accessibili tutti i percorsi di Internet. La ricerca di route del traffico dall'indirizzo IPv4 assegnato dal server VPN utilizzerà la route predefinita che utilizza l'interfaccia PPP, rendendo accessibili tutti i percorsi di intranet. Pertanto, quando si utilizza il processo di invio dell'host forte, il client VPN dispone di una configurazione di tunneling suddiviso e di accesso simultaneo sia a Internet che a intranet, anche per le applicazioni che non dispongono dei privilegi di livello di amministratore per modificare direttamente la tabella di routing IPv4.

Per impedire che il processo di invio dell'host forte crei una configurazione di tunneling condiviso per impostazione predefinita, il client VPN in Windows Vista® e Windows Server 2008 disattiva automaticamente le route predefinite delle interfacce LAN una volta terminata la connessione VPN. Questo processo assicura che vi sia solo una route predefinita attiva nella tabella di routing che utilizza l'interfaccia PPP. Assicura inoltre che le applicazioni senza privilegi a livello di amministratore non possano eseguire il tunneling suddiviso.

Poiché il traffico proveniente dal computer client VPN deve avere origine dall'indirizzo IPv4 assegnato dal server VPN, questo processo fornisce un migliore isolamento di intranet da Internet. Una volta terminata la connessione VPN, le route predefinite disattivate vengono riattivate.

È possibile controllare questo processo con il comando:

netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Joseph Daviesè un autore tecnico di Microsoft. Dal 1992 tiene corsi e scrive su argomenti legati alle reti Microsoft. Ha scritto cinque libri per Microsoft Press ed è autore della rubrica mensile Cable Guy di TechNet.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.