Nelle ultime settimane diverse persone mi hanno chiesto informazioni su percorsi che appaiono misteriosamente e poi scompaiono. Ad esempio
route print Gateway predefinito: 10.10.10.1 Indirizzo di rete Indirizzo gateway Maschera di sottorete Reindirizzamento Durata 172.16.0.0 10.10.10.172 255.255.0.0 |
| Figura 1 – Tabella di routing originale |
E poi
route print
Gateway predefinito: 10.10.10.1
Indirizzo di rete Indirizzo gateway Maschera di sottorete Reindirizzamento Durata
172.16.0.0 10.10.10.172 255.255.0.0
172.16.1.2 255.255.255.255 10.10.10.254 5 minuti
|
| Figura 2 – percorso dinamico aggiunto |
E 5 minuti dopo
route print Gateway predefinito: 10.10.10.1 Indirizzo di rete Indirizzo gateway Maschera di sottorete Reindirizzamento Durata 172.16.0.0 10.10.10.172 255.255.0.0 |
| Figura 3 – percorso dinamico eliminato |
Questi percorsi dinamici vengono aggiunti quando lo stack STCP riceve un messaggio di reindirizzamento ICMP da un router che gli indica di utilizzare un router diverso. Come indicato dal display, i percorsi hanno una durata di 5 minuti, quindi dopo 5 minuti vengono eliminati. Naturalmente possono tornare immediatamente se lo stack riceve un altro messaggio di reindirizzamento.
Per descrivere il processo in dettaglio, supponiamo che STCP sia definito con un percorso verso la rete 172.16.0.0/16 attraverso il router 10.10.10.172. Inoltre, sulla rete è presente un altro router con indirizzo IP 10.10.10.254. Mi riferirò a questi router come R-172 e R-254. Sia R-172 che R-254 possono raggiungere la rete 172.16.0.0/16, ma R-172 utilizza una connessione T3 ad alta larghezza di banda, mentre R-254 utilizza un collegamento ISDN dial-up a bassa larghezza di banda.
I percorsi STCP sono simili a quelli illustrati nella figura 1 sopra riportata; si noti che non esiste un percorso esplicito che utilizza R-254.
Quando il collegamento T3 di R-172 non funziona più, non è più in grado di raggiungere la rete 172.16.0.0/16, ma sa che R-254 può farlo, quindi quando arriva un pacchetto per 172.16.1.2, inoltra il pacchetto a R-254 e invia anche un messaggio di reindirizzamento ICMP al mittente. Il mittente, in questo caso STCP, crea una route host dinamica indicando che per raggiungere 172.16.1.2 deve inviare il pacchetto a R-254, figura 2.
Poiché si tratta di percorsi host, ogni host sulla rete 172.16.0.0/16 a cui viene inviato un pacchetto otterrà il proprio percorso con un timer di 5 minuti. Il comando route mostra la durata residua corrente per ogni percorso.
route print Gateway predefinito: 10.10.10.1 Indirizzo di rete Indirizzo gateway Maschera di sottorete Reindirizzamento Durata 172.16.0.0 10.10.10.172 255.255.0.0 172.16.1.1 255.255.255.255 10.10.10.254 5 minuti 172.16.1.8 255.255.255.255 10.10.10.254 2 minuti 172.16.1.23 255.255.255.255 10.10.10.254 2 minuti 172.16.1.65 255.255.255.255 10.10.10.254 2 minuti 172.16.1.101 255.255.255.255 10.10.10.254 3 minuti 172.16.1.200 255.255.255.255 10.10.10.254 5 minuti |
| Figura 4 – Percorsi host multipli |
Quando il collegamento T3 di R-172 diventa operativo, ciò che dovrebbe accadere è che gli host che non dispongono di una route host utilizzino R-172 come se nulla fosse successo. Gli host con un percorso host utilizzano R-254, che sa che il collegamento di R-172 è tornato attivo (i router si scambiano lo stato dei percorsi tra loro) e quindi inoltra il pacchetto a R-172. R-254 dovrebbe anche inviare un reindirizzamento ICMP al mittente, con il risultato di un nuovo percorso host che utilizza R-172 (figura 5).
route print Gateway predefinito: 10.10.10.1 Indirizzo di rete Indirizzo gateway Maschera di sottorete Reindirizzamento Durata 172.16.0.0 10.10.10.172 255.255.0.0 172.16.1.9 255.255.255.255 10.10.10.172 3 minuti 172.16.1.18 255.255.255.255 10.10.10.172 4 minuti 172.16.1.20 255.255.255.255 10.10.10.172 2 minuti |
| Figura 5 – Percorsi host reindirizzati al router originale |
In alcune condizioni può essere opportuno che STCP non crei alcuna route dinamica. Ad esempio, cosa succede se R-254 è inattivo e le informazioni di R-172 sono una voce statica che non è mai stata rimossa? In tal caso, i pacchetti destinati agli host sulla rete 172.16.0.0/16 vengono semplicemente eliminati quando R-254 non è raggiungibile. Quando il T3 di R-172 torna in funzione, si verifica la situazione in cui gli host 172.16.0.0/16 senza una route host sono raggiungibili, mentre quelli con la route host R-254 non lo sono. Con il passare del tempo, man mano che le route R-254 vanno in timeout, sempre più host saranno raggiungibili, ma ci vorranno 5 minuti per il ripristino completo.
Alcuni esperti di sicurezza ritengono inoltre che le rotte dinamiche create in questo modo rappresentino un problema di sicurezza. Qualsiasi host sulla rete può inviare un messaggio di reindirizzamento ICMP, reindirizzando i pacchetti verso un gateway diverso, dove è possibile intercettare pacchetti con contenuti sensibili quali password o informazioni sull'account.
Esiste un modo per impedire la creazione di questi percorsi?
Sì, il parametro di configurazione STCP listen_redirects controlla il modo in cui STCP gestisce i messaggi di reindirizzamento ICMP. L'impostazione predefinita "on" indica a STCP di creare queste rotte dinamiche, mentre l'impostazione "off" indica a STCP di ignorare i messaggi di reindirizzamento ICMP.
come: list_stcp_params listen_redirects ascolta i reindirizzamenti ICMP [off/on] (listen_redirects) on come: set_stcp_param listen_redirects off Modifica dell'ascolto dei reindirizzamenti ICMP (listen_redirects) da on a off |
| Figura 6 – Impostazione del parametro STCP listen_redirect |
Si noti che questo parametro influisce sul sistema nel suo complesso, non è possibile specificare che STCP debba ascoltare i reindirizzamenti da alcuni router ma non da altri.