Perché nascondere i router al traceroute?

Se gestisci la rete di un WISP o di un ISP, un traceroute dal PC di un cliente disegna la tua dorsale: indirizzo dopo indirizzo, ogni router fra lui e internet. Non è una vulnerabilità in sé, ma è una mappa regalata: chi vuole provare un brute force o un DoS sa già a quali porte bussare.

Come funziona il trucco del TTL?

Ogni pacchetto IP ha un contatore, il TTL. Ogni router che lo inoltra lo abbassa di uno; quando arriva a zero, il router scarta il pacchetto e risponde al mittente con un “time exceeded”. Il traceroute sfrutta proprio questo: manda pacchetti con TTL 1, 2, 3… e annota chi risponde a ogni giro.

Il trucco: se il router alza di uno il TTL appena il pacchetto entra, il decremento dell’inoltro lo riporta al valore di partenza. Il TTL non arriva mai a zero su quel router, che quindi non risponde mai: per il traceroute non esiste.

Schema: cliente che fa traceroute verso 8.8.8.8, router MikroTik con mangle change-ttl sulla lista CLIENTI, e i salti successivi
Il router aumenta di uno il TTL dei pacchetti dei clienti: il traceroute parte dal salto successivo e lui non compare.

Passo 1: com’è la rete vista dal cliente?

Prima di nascondere qualcosa, guarda cosa si vede oggi. Da un PC del cliente:

tracert 8.8.8.8         (Windows)
traceroute 8.8.8.8      (Linux e macOS)

In laboratorio ho fatto la stessa prova con ping -t 1, ping -t 2 e così via da un PC Linux: è un traceroute fatto a mano, un salto alla volta. Prima della modifica:

From 192.168.88.1 icmp_seq=1 Time to live exceeded
From 192.168.250.1 icmp_seq=1 Time to live exceeded
From 10.0.0.1 icmp_seq=1 Time to live exceeded
From 10.255.255.216 icmp_seq=1 Time to live exceeded

Il primo salto, 192.168.88.1, è il router MikroTik che vogliamo far sparire.

Passo 2: quali sono le interfacce dei clienti?

La regola va applicata solo al traffico che arriva dai clienti, non a tutto (al passo 6 vediamo perché). Raccogliamo le interfacce dei clienti in una lista:

/interface list add name=CLIENTI
/interface list member add list=CLIENTI interface=vlan100-clienti

Sostituisci vlan100-clienti con le tue porte, VLAN o bridge verso i clienti. Se i clienti arrivano in PPPoE, le loro interfacce nascono e muoiono a ogni connessione: invece di aggiungerle a mano, fai entrare nella lista ogni sessione dal profilo PPP che usano:

/ppp profile set [find name=default] interface-list=CLIENTI

Usa il nome del profilo dei tuoi clienti se non è default.

Passo 3: come aggiungo la regola?

Una sola regola di mangle, in prerouting, limitata alla lista dei clienti:

/ip firewall mangle add chain=prerouting in-interface-list=CLIENTI \
    action=change-ttl new-ttl=increment:1 passthrough=yes \
    comment="Nasconde questo router al traceroute dei clienti"

Va ripetuta su ogni router che vuoi nascondere: ognuno compensa solo il proprio decremento. Le altre azioni di mangle, change-ttl compresa, sono nel manuale MikroTik: Mangle.

Passo 4: come verifico che funzioni?

Rifai il traceroute dal cliente. In laboratorio, stessa prova del passo 1, dopo la regola:

From 192.168.250.1 icmp_seq=1 Time to live exceeded
From 10.0.0.1 icmp_seq=1 Time to live exceeded
From 10.255.255.216 icmp_seq=1 Time to live exceeded
From 172.29.0.9 icmp_seq=1 Time to live exceeded

192.168.88.1 è sparito: il primo a rispondere ora è il router successivo. Tutto il resto funziona come prima.

Ho provato anche con il fasttrack attivo, come nella configurazione di fabbrica: il router resta nascosto. Dal router puoi controllare che la regola stia lavorando guardando i contatori:

/ip firewall mangle print stats where comment~"traceroute"

Passo 5: e per IPv6?

Stesso principio, ma in IPv6 il contatore si chiama hop limit:

/ipv6 firewall mangle add chain=prerouting in-interface-list=CLIENTI \
    action=change-hop-limit new-hop-limit=increment:1 passthrough=yes \
    comment="Nasconde questo router al traceroute IPv6 dei clienti"

Passo 6: perché non su tutte le interfacce?

Per due motivi.

  • Troubleshooting: anche tu userai il traceroute per trovare un guasto. Se la regola vale ovunque, i tuoi router spariscono anche per te. Limitandola ai clienti, dal NOC li vedi ancora.
  • Loop di routing: il TTL esiste proprio per far morire i pacchetti che girano in tondo. Se due router in loop si rialzano il TTL a vicenda, un pacchetto non scade mai e consuma banda finché il loop non si risolve. Con la regola solo in ingresso dai clienti, il pacchetto viene incrementato una volta sola, al confine, e il TTL torna a fare il suo lavoro nella dorsale.

⚠️ Attenzione: nascondere i router non li protegge. Chi conosce già i loro indirizzi li raggiunge comunque: la protezione vera è il firewall in input, che trovi nell’Hardening di base di un router MikroTik. Fallo prima di mettere il router in produzione, poi aggiungi questa regola.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable) e un client Linux: TTL dei salti prima e dopo la regola, con e senza fasttrack, regola IPv6 e lista di interfacce dal profilo PPP.

Domande frequenti

Come si nasconde un router MikroTik al traceroute?

Con una regola di firewall mangle in prerouting con action=change-ttl new-ttl=increment:1: il TTL incrementato compensa il decremento dell’inoltro e il router non compare fra i salti del traceroute.

La regola rallenta il router?

Non in modo apprezzabile: è la modifica di un campo dell’intestazione IP. Su router con molto traffico conviene comunque limitarla alle interfacce dei clienti, che è anche la scelta più sicura.

Posso ancora fare traceroute io dalla mia rete?

Sì, se la regola è limitata con in-interface-list alle interfacce dei clienti: il traffico che parte dal NOC o dalla dorsale non viene modificato e i router restano visibili.

Come metto i clienti PPPoE nella lista di interfacce?

Dal profilo PPP: con interface-list=CLIENTI nel profilo usato dai clienti, ogni sessione PPPoE entra da sola nella lista quando si collega.

È una vera misura di sicurezza?

È una misura di riservatezza: nasconde la topologia della rete ai clienti curiosi. Non sostituisce il firewall in input sui router, che resta la protezione vera contro accessi e attacchi.

Questo howto aggiorna a RouterOS 7 un articolo del 2015 sul mio vecchio blog wirelessguru.it, ormai offline.