Che danni fa un secondo DHCP server?

I client accettano la prima offerta che arriva. Se in rete c’è un secondo server, una parte dei dispositivi prende indirizzo, gateway e DNS sbagliati: niente internet, stampanti irraggiungibili e un guasto “a macchia di leopardo” che fa impazzire chiunque provi a capirlo. Il colpevole, di solito, è un router domestico collegato al contrario da qualcuno con le migliori intenzioni. Nel caso peggiore è messo lì apposta per dirottare il traffico.

In laboratorio l’ho visto succedere: con un secondo server sulla stessa LAN, il PC di prova ha preso 192.168.250.198 con il gateway del server pirata, invece del suo solito 192.168.88.199. Nessun errore, nessun avviso: semplicemente, quel PC non era più nella rete giusta.

MikroTik ti dà due strumenti: l’alert, che ti avvisa, e il DHCP snooping, che blocca.

Schema: MikroTik con DHCP server, alert e DHCP snooping; un router pirata su bridge-lan le cui offerte vengono bloccate
L’alert scopre il secondo DHCP server e avvisa; il DHCP snooping lascia passare le offerte solo dalla porta trusted.

Passo 1: qual è il DHCP server buono?

Prima di cercare il pirata, conosci il legittimo. Se il DHCP server è il router stesso, lo vedi qui:

/ip dhcp-server print

Il server del router non fa mai scattare l’allarme: non serve dichiararlo. Se invece il server legittimo è un’altra macchina (un Windows Server, un altro router), ti serve il suo MAC address, da indicare come server valido al passo 2.

Negli esempi le porte della LAN sono nel bridge bridge-lan: sostituisci il nome con il tuo.

Passo 2: come mi faccio avvisare da MikroTik?

Con l’alert del DHCP server: indichi l’interfaccia da sorvegliare e, se c’è, il MAC del server legittimo che non è il router. Qualunque altro server risponda fa scattare l’avviso.

/ip dhcp-server alert add interface=bridge-lan valid-server=00:0C:42:8D:D1:30 \
    alert-timeout=1h on-alert=":log warning \"DHCP server non autorizzato su bridge-lan\""
/ip dhcp-server alert enable [find interface=bridge-lan]

⚠️ Attenzione: gli alert nascono disabilitati. Senza la seconda riga l’alert resta lì, con la sua X davanti, e non avvisa nessuno. È l’errore più comune: l’ho fatto anch’io.

  • interface: se le porte della LAN sono in un bridge, si sorveglia il bridge, non la singola porta ethernet;
  • valid-server: il MAC del server DHCP legittimo, solo se non è il router stesso. Se il server è il router, puoi ometterlo;
  • alert-timeout: dopo quanto tempo il router “dimentica” un server pirata già trovato; se è ancora lì, scatta un nuovo avviso.

Per non perdere le risposte inviate direttamente ai client, l’alert si comporta anche da client DHCP: circa una volta al minuto manda una sua richiesta e ascolta chi risponde. Per questo non va messo su un’interfaccia dove il router stesso prende l’indirizzo via DHCP, per esempio la WAN verso il modem. I dettagli sono nel manuale MikroTik: DHCP Alerts.

Quando il pirata si fa vivo, nel log compare questo (output reale del laboratorio):

dhcp,critical,error dhcp alert on bridge-lan: discovered unknown dhcp server, mac 50:00:00:1A:00:01, ip 192.168.250.1
script,warning DHCP server non autorizzato su bridge-lan

MAC e IP del server pirata restano visibili anche qui:

/ip dhcp-server alert print detail

Il MAC è la pista migliore per trovare il colpevole: cercalo nella tabella degli host del bridge (/interface bridge host print where mac-address=…) per sapere su quale porta è collegato.

Passo 3: come ricevo l’avviso via email?

Mettendo un invio di posta in on-alert. Prima però il router deve saper mandare la posta: c’è un howto dedicato a inviare email da MikroTik con Gmail.

/ip dhcp-server alert set [find interface=bridge-lan] on-alert={
    :log warning "DHCP server non autorizzato su bridge-lan"
    /tool e-mail send to="admin@example.com" subject="ALLARME: DHCP server non autorizzato" \
        body=("Rilevato un DHCP server non autorizzato sulla LAN di " . [/system identity get name] . ". Vedi /ip dhcp-server alert.")
}

Il nome del router (/system identity) nell’email è prezioso quando gestisci decine di clienti: sai subito da quale rete arriva l’allarme.

Per riprovare senza aspettare l’alert-timeout, fai dimenticare al router i server già trovati:

/ip dhcp-server alert reset-alert [find interface=bridge-lan]

Se la mail non parte, l’errore finisce nel log con il topic e-mail, mentre la riga di :log warning resta comunque.

Passo 4: come blocco il server pirata?

Con il DHCP snooping del bridge. Lo attivi sul bridge e dichiari “fidate” (trusted) solo le porte da cui può arrivare un server legittimo: le risposte DHCP che entrano dalle altre porte vengono scartate.

/interface bridge set [find name=bridge-lan] dhcp-snooping=yes
/interface bridge port set [find interface=ether1] trusted=yes

La seconda riga serve solo se il server legittimo sta dietro una porta del bridge, qui ether1. Se il DHCP server è il router stesso, non serve nessuna porta trusted: il router non passa da una porta del bridge.

In laboratorio, con lo snooping attivo e il pirata collegato a una porta non fidata, il PC è tornato subito al suo 192.168.88.199 e l’alert è rimasto zitto: le offerte del pirata vengono scartate sulla porta prima ancora di arrivare al router.

⚠️ Attenzione: lo snooping ferma il pirata solo se è collegato a una porta diversa da quella dei client. Se il pirata e i PC stanno sullo stesso switch “stupido” collegato a una sola porta del MikroTik, si parlano direttamente nello switch e il MikroTik non può farci niente. Ecco perché conviene attivare lo snooping proprio sugli switch di accesso.

Controlla quali porte hai dichiarato fidate:

/interface bridge port print where trusted=yes

Passo 5: e l’Option 82?

Con lo snooping attivo il bridge può aggiungere alle richieste dei client l’Option 82: un’etichetta che dice al server DHCP da quale switch e da quale porta arriva il cliente. In una rete da operatore o in un condominio vuol dire poter dare l’indirizzo in base alla porta, non al dispositivo.

Da RouterOS 7.23 si configura così (la vecchia opzione add-dhcp-option82=yes non esiste più: su RouterOS 7.24.5 risponde bad parameter):

/interface bridge set [find name=bridge-lan] dhcp-agent-circuit-id="\$(INTERFACE)" \
    dhcp-agent-remote-id="\$(HOSTNAME)"

$(INTERFACE) diventa il nome della porta del client, $(HOSTNAME) il nome del router; ci sono anche $(VID) e $(BRIDGEMAC). Il \ davanti al dollaro serve nel terminale, altrimenti RouterOS lo scambia per una sua variabile. Se il tuo server DHCP non usa l’Option 82, questo passo puoi saltarlo. Esempio completo con due switch e tutte le variabili nel manuale MikroTik: DHCP Snooping and DHCP Option 82.

Passo 6: funziona anche sugli switch?

Sì, e sugli switch rende di più, perché blocca il pirata sulla porta a cui è collegato, prima che il traffico arrivi al router. Secondo la documentazione MikroTik, sugli switch con chip Marvell Prestera (come le serie CRS3xx e CRS5xx) DHCP snooping e Option 82 sono gestiti interamente in hardware. Sugli altri apparati funzionano anche con l’offload hardware attivo, ma solo se sul bridge non c’è nessuna configurazione VLAN.

Passo 7: cosa controllo prima di metterlo in produzione?

Alert e snooping proteggono la LAN, non il router. Se non l’hai ancora fatto, segui l’Hardening di base di un router MikroTik: utente diverso da admin, servizi limitati, firewall verso internet.

Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable), un client Linux e un secondo router come DHCP server pirata: alert disabilitato e abilitato, avviso con email, DHCP snooping, nuova sintassi dell’Option 82. Il comportamento sugli switch fisici viene dalla documentazione MikroTik.

Domande frequenti

Come scopro un DHCP server non autorizzato con MikroTik?

Con /ip dhcp-server alert: indichi l’interfaccia da sorvegliare, abiliti l’alert (nasce disabilitato) e, quando risponde un server sconosciuto, RouterOS scrive nel log e lancia lo script di on-alert.

Perché il mio alert DHCP non scatta?

Quasi sempre perché è disabilitato: gli alert nascono con la X e vanno abilitati con /ip dhcp-server alert enable. Il server DHCP del router stesso, invece, non fa mai scattare l’allarme.

Su quale interfaccia va messo l’alert DHCP?

Sull’interfaccia che rappresenta la LAN: se le porte sono in un bridge, sul bridge e non sulla singola porta ethernet. Non va messo su un’interfaccia dove il router prende l’indirizzo via DHCP.

Che differenza c’è fra alert e DHCP snooping?

L’alert segnala che c’è un DHCP server non autorizzato ma non lo ferma; il DHCP snooping del bridge scarta le risposte DHCP che arrivano dalle porte non fidate, quindi il server pirata non riesce a dare indirizzi.

Quali porte vanno marcate come trusted?

Solo quelle da cui può arrivare il server DHCP legittimo, per esempio la porta verso il server o verso lo switch di distribuzione. Le porte verso gli utenti restano non fidate. Se il server è il router stesso, nessuna.

add-dhcp-option82 non funziona più, perché?

Da RouterOS 7.23 l’opzione è stata tolta: l’Option 82 si configura con dhcp-agent-circuit-id e dhcp-agent-remote-id sul bridge, usando variabili come $(INTERFACE) e $(HOSTNAME).

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