Il bandwidth test è lo strumento con cui due MikroTik si misurano la banda a vicenda. Comodo. Il problema è che il server di questo test, sul router appena configurato, è già acceso — e sta in ascolto su una porta che da Internet qualcuno prova a bussare tutto il giorno. In questo articolo lo apriamo in laboratorio e guardiamo cosa succede davvero: cosa vede chi scansiona la porta 2000, cosa cambia con l'autenticazione accesa o spenta, e come un router lasciato aperto diventa un generatore di traffico al servizio di estranei. Poi lo chiudiamo, con il pacchetto alla mano.

Passo 1: cos'è il bandwidth test (e di cosa è fatto)

Il bandwidth test ha due metà. Da una parte il client (/tool bandwidth-test): è chi lancia la misura. Dall'altra il server (/tool bandwidth-server): è chi accetta la misura e fa da partner. Per misurare la banda, il client riempie il collegamento di pacchetti più in fretta che può e conta quanti ne arrivano dall'altra parte. In pratica è un piccolo flood controllato, fatto apposta.

Terminologia utile: direction=transmit misura il traffico dal client verso il server, receive il contrario, both tutti e due. Tienilo a mente, perché "chi genera il traffico" cambia a seconda della direzione.

Passo 2: lo stato di fabbrica sorprende

Prendiamo un router pulito (qui un CHR appena resettato) e guardiamo com'è il server del bandwidth test senza aver toccato niente:

Tre cose da notare. Il server è già enabled: yes: nessuno l'ha acceso, era così. Richiede l'autenticazione (authenticate: yes), e questa è la nostra fortuna. E l'elenco degli indirizzi ammessi (allowed-addresses4) è vuoto, che qui significa "chiunque". Su un router senza firewall — un CHR, o un apparato appena resettato prima di metterci le regole — questo vuol dire che la porta 2000 risponde al mondo.

⚠️ Attenzione: "acceso di fabbrica" non vuol dire "spalancato". Con l'autenticazione accesa serve ancora una credenziale valida del router per usarlo. Ma la porta si vede, e questo da solo è già un'informazione che regali a chi scansiona.

Passo 3: cosa vede chi scansiona la porta 2000

Sulla WAN di un router pubblico, alla porta TCP 2000 bussano in continuazione: sono scansioni automatiche che cercano proprio i bandwidth server lasciati aperti. Mettiamo lo sniffer sul segmento e guardiamo i tre casi possibili, pacchetto per pacchetto. È lo stesso schema "aperto / chiuso / filtrato" che userebbe un qualsiasi scanner di porte. (Qui lo sniffer è sul segmento; lo stesso traffico lo puoi ricevere a distanza con dojo.tzsp, che legge il mirror TZSP di RouterOS.)

Server acceso: la porta risponde (aperto)

La stretta di mano TCP si completa. Per lo scanner è la risposta che cercava: qui c'è un bandwidth server.

Server spento: porta chiusa

Con /tool bandwidth-server set enabled=no il router rifiuta attivamente la connessione con un RST. La porta risulta chiusa. Lo scanner lo sa in un colpo solo, ma almeno non trova un servizio da provare.

Porta filtrata dal firewall: silenzio

Con una regola di drop in input, il router non risponde affatto: lo scanner ritrasmette il SYN qualche volta e poi lascia perdere, in timeout. Dal di fuori non si capisce nemmeno se il router esista. È il risultato migliore, e lo otteniamo nel Passo 7.

Passo 4: con l'autenticazione, la porta parla ma non cede

Proviamo a lanciare un test contro il nostro router di fabbrica (autenticazione accesa) con una password sbagliata. Ecco cosa cattura lo sniffer:

La porta ha parlato — handshake e sfida di autenticazione — ma senza credenziali valide il server chiude e basta. Nessun pacchetto UDP, nessun traffico di misura. Morale: l'autenticazione accesa (il default) fa il suo lavoro. Il guaio comincia quando qualcuno la spegne.

Passo 4-bis: l’autenticazione è cifrata? No (ma la password non viaggia in chiaro)

Domanda legittima: quando il test si autentica, le credenziali passano in chiaro come sull’API non-SSL? Non si indovina — si cattura. Ho acceso un server con authenticate=yes, ho dato all’utente la password dojo12345! e ho lanciato il test con quelle credenziali, sniffando a pacchetto pieno l’intero canale di controllo TCP 2000. Tre cose, tutte lette sulla cattura:

Come la verifica allora il server? Con una sfida/risposta: il server manda un valore casuale, il client risponde con un digest di 16 byte (schema MD5, lo stesso del vecchio login Winbox pre-6.43). È il blocco che segue subito admin\0 nel pacchetto di autenticazione — catturato davvero:

Quindi uno sniffer non legge la password al volo. Ma “non in chiaro” non vuol dire “al sicuro”:

Non è teoria — è la CVE-2018-14847 (come già riprodotta in laboratorio). Nel 2018 una falla nel parser di Winbox (porta 8291) permetteva a un attaccante non autenticato di leggere file arbitrari dal router — tra cui user.dat, il database degli utenti, da cui si recuperano le password. Ne uscì una delle più grandi ondate di compromissione mai viste su RouterOS — circa 200.000 router infettati per cryptojacking (oltre a VPNFilter e simili). MikroTik corse ai ripari cambiando lo schema di login con la 6.43. Il digest che hai appena visto passare sul btest appartiene proprio a quel mondo pre-6.43: è lo stesso motivo per cui non va mai esposto.

Morale: il bandwidth test non ti dà un canale sicuro. Protegge la password dietro una sfida (non leggibile subito), ma lascia scoperti lo username e la crackabilità offline. Le due difese che contano sono quelle del Passo 7: password robusta e, soprattutto, porta chiusa dall’esterno — così quello scambio da sniffare non arriva nemmeno.

Passo 5: senza autenticazione, il router diventa un megafono di traffico

Capita di trovare in giro la "soluzione" veloce a un test che non parte: authenticate=no. Ecco cosa significa davvero. Lo impostiamo sul server e lanciamo il test da un'altra macchina senza passare nessuna credenziale:

Il test parte lo stesso. Lo sniffer, dopo la breve stretta di mano sulla 2000, si riempie di questo:

Chiunque abbia trovato quella porta ora può usare il tuo router come partner di un flood. Con direction=receive se lo fa spedire dal tuo router: è la tua banda in uscita e la tua CPU a lavorare per lui. Con both, in tutte e due le direzioni. Un router è un generatore di traffico molto efficiente: è esattamente il motivo per cui authenticate=no su un apparato raggiungibile da Internet è un regalo agli estranei.

Non è una reflection spoofata. Attenzione a non confonderlo con le amplificazioni tipo DNS o NTP: lì basta un pacchetto UDP con sorgente falsa per far rimbalzare una risposta enorme verso una vittima inconsapevole. Qui no. Il canale di controllo è TCP sulla 2000, e un handshake TCP non lo completi con un indirizzo falso — il SYN-ACK del router tornerebbe all’IP spoofato, non a chi attacca. Perciò la sorgente è auto-validata e il flood UDP non si può dirottare su un terzo: il bersaglio è sempre e solo il router stesso, la sua CPU e la sua banda.

⚠️ Attenzione: non impostare mai authenticate=no su un router che ha un piede su Internet. Se un test "non parte", il problema sono le credenziali o il firewall, non l'autenticazione: si risolve con l'utente giusto, non spegnendo la serratura.

Passo 6: l'uso legittimo (come si misura davvero)

Detto il rischio, lo strumento serve. Per misurare la banda verso un altro MikroTik che controlli tu, dal client lanci:

(198.51.100.1 è l'indirizzo del router-server; le credenziali sono quelle del server.) Durante il test vedi scorrere i numeri: tx-total-average, rx-total-average, i pacchetti persi e il carico CPU dei due lati (local-cpu-load, remote-cpu-load).

⚠️ Attenzione: il bandwidth test satura il collegamento per il tempo del test. Su un link in produzione significa degradare tutto il resto per quei secondi; su apparati piccoli il limite lo mette la CPU, non la linea, e il numero che leggi è quello. Fallo su link che puoi permetterti di riempire, e per pochi secondi.

Passo 7: come chiuderlo (a strati)

Dal più semplice al più robusto. Fai quello che serve al tuo caso — spesso basta il primo.

Se non lo usi: spegni il server

La porta 2000 passa da "aperta" a "chiusa" (quel RST del Passo 3). Niente server, niente superficie d'attacco. È la scelta giusta per la maggioranza dei router, che un bandwidth server non ce l'hanno mai usato.

Se lo usi: tieni l'autenticazione e restringi gli indirizzi

Lascia authenticate=yes (non toccarlo mai) e, se possibile, di' al server da quali indirizzi accettare, con la lista integrata del servizio:

Con la lista valorizzata, un test che arriva da un indirizzo fuori lista non viene nemmeno negoziato: il client resta su connecting e va in can not connect. Solo l'indirizzo in lista (qui la tua postazione di gestione) riesce a far partire la misura. È una ACL che vive nel servizio, prima e oltre il firewall.

In ogni caso: chiudi la porta dalla WAN con il firewall

La difesa che conta per un router esposto è non far arrivare quei pacchetti dalla rete pubblica. Due regole mirate in input (il comment ti ricorderà perché ci sono):

La prima regola — quella sulla TCP 2000 — è l'essenziale: senza il canale di controllo, nessun test parte. La seconda chiude anche le porte UDP di misura, per completezza. Da fuori, la porta diventa filtrata: silenzio totale, come nel Passo 3.

Se hai già fatto l'hardening di base del router, il tuo input probabilmente scarta già tutto ciò che arriva dalla WAN e non è esplicitamente permesso: in quel caso la 2000 è già chiusa e queste due regole sono solo una conferma esplicita. Puoi verificarlo guardando i contatori delle regole di drop mentre qualcuno bussa.

Domande frequenti

Il bandwidth server è davvero acceso di fabbrica?

Sì: su RouterOS /tool bandwidth-server nasce con enabled=yes e authenticate=yes. Su un router con la configurazione di default c'è anche un firewall che para la WAN; su un CHR o su un apparato appena resettato, finché non metti le regole, la porta 2000 è raggiungibile. Controlla con /tool bandwidth-server print.

Perché nei log della WAN vedo tanti tentativi sulla porta 2000?

Perché gli scanner automatici cercano proprio i bandwidth server aperti. Un SYN sulla 2000 è una domanda: "c'è un server qui?". Se chiudi la porta con il firewall, la domanda resta senza risposta e smetti di comparire nei loro elenchi.

Che differenza c'è tra spegnere il server e chiuderlo col firewall?

Spegnere il server (enabled=no) fa rispondere la porta con un RST: lo scanner capisce subito che è chiusa. Il firewall in drop non risponde affatto: la porta risulta filtrata e il router, da fuori, è invisibile. Se non usi il server, fai entrambe le cose: spegnilo e tienilo fuori dalla WAN col firewall.

Chi lancia il test consuma la mia banda o la sua?

Dipende dalla direzione. transmit misura dal client al server, receive dal server al client, both tutte e due. Con receive è il tuo router a spedire: se il server è tuo e aperto, un estraneo può farsi mandare traffico usando la tua banda in uscita e la tua CPU.

Se blocco la porta 2000 rompo qualcosa?

No, a meno che tu non usi davvero il bandwidth test verso quel router dall'esterno. I test che lanci tu verso altri router continuano a funzionare: il blocco è in input, riguarda solo chi vuole usare il server sul tuo apparato.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable): stato di fabbrica del bandwidth-server (acceso, con autenticazione, lista indirizzi vuota); cattura reale dei tre casi dello scanner sulla porta 2000 (SYN-ACK a server acceso, RST a server spento, nessuna risposta con il drop del firewall); test con password errata (autenticazione fallita, nessun traffico di misura) e con autenticazione disattivata (flood UDP dalla porta 2000 in su senza credenziali); restrizione con allowed-addresses4 e blocco in input verificati con lo sniffer sul segmento di prova; cattura full-packet del canale di controllo TCP 2000 durante un test autenticato (password dojo12345!), che mostra l’assenza di TLS, lo username in chiaro e la password come digest MD5 di sfida/risposta — mai in chiaro.