Perché serve proteggere la LAN dagli ospiti?

Perché un hotspot è, per definizione, una rete aperta a sconosciuti. La soluzione ideale è una connessione e un’infrastruttura separate, o almeno una VLAN dedicata fino al router. Spesso però l’hotspot è “appoggiato” alla rete dell’ufficio o del locale: in quel caso il firewall del MikroTik è l’unica cosa che separa uno smartphone sconosciuto dal gestionale del cliente.

Questo howto parte da un hotspot già funzionante. Se devi ancora crearlo, c’è l’howto su come creare un hotspot WiFi con MikroTik e RouterOS 7.

Schema: rete LAN del cliente, router MikroTik con hotspot che blocca gli ospiti verso la LAN e lascia passare il traffico verso internet
Il router dell’hotspot sta dentro la LAN del cliente: una regola blocca gli ospiti verso la LAN e verso la gestione del router.

Passo 1: qual è la rete da proteggere?

Il caso tipico: la WAN del router hotspot è collegata alla rete del cliente, ed è proprio quella la rete da proteggere. Nel mio laboratorio la WAN è 10.6.0.10/12, quindi la rete del cliente è 10.0.0.0/12.

⚠️ Attenzione: sostituisci 10.0.0.0/12 con la rete reale da proteggere, quella a cui è collegata la WAN del tuo hotspot. Se non sei sicuro, l’IP calculator del Dojo te la ricava dall’indirizzo della WAN. Dal router la vedi anche qui, nella colonna NETWORK:

/ip address print where interface=ether1

Passo 2: come blocco l’accesso degli ospiti alla LAN?

Una sola regola fa il lavoro:

/ip firewall filter add chain=forward hotspot=from-client \
    dst-address=10.0.0.0/12 action=reject reject-with=icmp-net-prohibited \
    comment="Ospiti hotspot: niente accesso alla LAN"
  • hotspot=from-client prende i pacchetti dei client dell’hotspot, autenticati e non;
  • reject blocca e risponde con un errore, drop blocca in silenzio. Per gli ospiti preferisco reject: chi sbaglia indirizzo lo capisce subito, invece di aspettare un timeout.

Il gateway 10.0.0.1 sta dentro la rete bloccata, ma la navigazione non si interrompe: il traffico verso internet ha come destinazione i siti, non il gateway, e la regola blocca solo le connessioni dirette verso la rete del cliente. Anche il DNS è al sicuro: l’hotspot intercetta da solo le richieste DNS dei suoi client e risponde lui.

La regola va messa prima delle eventuali regole che accettano il traffico in forward. Per spostarla in cima:

/ip firewall filter move [find comment="Ospiti hotspot: niente accesso alla LAN"] destination=0

Passo 3: come verifico che la regola funzioni?

Da un dispositivo collegato all’hotspot, dopo il login, prova un ping a un host della LAN e uno verso internet. In laboratorio, con la rete del cliente su 192.168.250.0/24, il risultato è stato questo:

ping 192.168.250.1
From 192.168.88.1 icmp_seq=1 Destination Net Prohibited
From 192.168.88.1 icmp_seq=2 Destination Net Prohibited

ping 8.8.8.8
2 packets transmitted, 2 received, 0% packet loss

La LAN risponde “Destination Net Prohibited”, internet funziona. Sul router i contatori della regola devono salire:

/ip firewall filter print stats where comment~"Ospiti hotspot"

Passo 4: e se le reti da proteggere sono più di una?

Meglio una address list al posto dell’indirizzo scritto nella regola: aggiungi reti senza toccare il firewall. Questa regola sostituisce quella del passo 2:

/ip firewall address-list add list=lan-protette address=10.0.0.0/12 comment="Rete del cliente (WAN)"
/ip firewall address-list add list=lan-protette address=192.168.50.0/24 comment="Rete server"
/ip firewall filter add chain=forward hotspot=from-client \
    dst-address-list=lan-protette action=reject reject-with=icmp-net-prohibited \
    comment="Ospiti hotspot: niente accesso alle reti protette" place-before=0

place-before=0 la mette direttamente in cima, senza bisogno del move.

Passo 5: come proteggo il router stesso?

Gli ospiti non devono raggiungere nemmeno WinBox, SSH e gli altri servizi di gestione del router:

/ip firewall filter add chain=input hotspot=from-client protocol=tcp \
    dst-port=21,22,23,8291,8728,8729 action=drop \
    comment="Ospiti hotspot: niente gestione del router"

E le porte 80 e 443, quelle di WebFig? Non servono nella lista: l’hotspot dirotta già tutto il traffico web dei suoi client verso le proprie porte interne (da 64872 a 64875), che servono la pagina di login: le regole dinamiche che l’hotspot crea sono descritte nel manuale MikroTik: HotSpot – Captive portal. In laboratorio, con questa regola attiva, il login funzionava e WinBox e SSH erano irraggiungibili dagli ospiti.

Passo 6: e se la WAN prende l’indirizzo in DHCP?

Allora la rete del cliente può cambiare, e una rete scritta a mano nella address list prima o poi diventa sbagliata. Nel 2015 avevo risolto con uno script lanciato dallo scheduler; in RouterOS 7 c’è un modo più pulito: lo script del client DHCP, che parte da solo ogni volta che il router riceve o perde il lease.

/ip dhcp-client set [find interface=ether1] script={
    :if ($bound = 1) do={
        :local addr [/ip address get [find interface=$interface dynamic] address]
        :local net  [/ip address get [find interface=$interface dynamic] network]
        :local len  [:pick $addr ([:find $addr "/"] + 1) [:len $addr]]
        /ip firewall address-list remove [find list=lan-protette comment="WAN dinamica"]
        /ip firewall address-list add list=lan-protette address=($net . "/" . $len) comment="WAN dinamica"
        :log info ("hotspot: rete WAN protetta " . $net . "/" . $len)
    }
}

Quando il router riceve l’indirizzo ($bound = 1), lo script ricava la rete della WAN e la mette nella address list lan-protette, al posto di quella vecchia. La regola del passo 4 resta sempre la stessa.

Per provarlo senza aspettare: rilascia il lease, il client ne chiede subito uno nuovo e lo script parte.

/ip dhcp-client release [find interface=ether1]
/ip firewall address-list print where list=lan-protette
/log print where message~"WAN protetta"

⚠️ Attenzione: il release fa perdere la connessione al router per qualche secondo. Non farlo da remoto passando proprio da quella WAN.

Passo 7: cosa controllo prima di metterlo in produzione?

Queste regole proteggono la LAN dagli ospiti, ma il router deve essere protetto anche da internet. Se non l’hai ancora fatto, segui l’Hardening di base di un router MikroTik: utente diverso da admin, servizi limitati, firewall in input verso internet.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable), un hotspot e un client Linux autenticato: blocco verso la LAN con indirizzo e con address list, navigazione verso internet, regola in input con login funzionante, script del client DHCP.

Domande frequenti

Che cosa fa il matcher hotspot=from-client?

Il matcher hotspot=from-client del firewall MikroTik seleziona i pacchetti che arrivano dai client gestiti dall’hotspot, a prescindere dall’indirizzo IP. Si può combinare con auth per distinguere i client autenticati.

Meglio reject o drop per bloccare gli ospiti?

Per la rete degli ospiti reject è più comodo: chi tenta di raggiungere la LAN riceve subito un errore invece di un timeout. drop non risponde affatto ed è preferibile verso internet.

La regola va nella chain forward o input?

Nella chain forward si blocca il traffico che attraversa il router verso la LAN; nella chain input si blocca quello diretto al router stesso, per esempio WinBox e SSH. Per un hotspot servono entrambe.

Bloccando la porta 80 in input si rompe la pagina di login?

No: l’hotspot dirotta il traffico web dei client verso le sue porte interne (64872–64875) prima del firewall in input. Per questo nella regola bastano le porte di gestione (21, 22, 23, 8291, 8728, 8729).

Lo script del client DHCP funziona anche dopo un riavvio?

Sì: al riavvio il client DHCP ottiene di nuovo il lease e lo script parte, aggiornando l’address list con la rete corrente.

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