Perché scrivere il nome utente nel log?
Nell’howto su come registrare il traffico degli utenti dell’hotspot abbiamo visto come annotare ogni nuova connessione. Il giorno in cui serve davvero, per esempio per una richiesta dell’autorità su un certo indirizzo a una certa ora, comincia il calvario: capire quale utente aveva quell’indirizzo privato in quel momento, incrociando il log del firewall con quello dei login. Nel 2016 mi sono chiesto: e se il nome fosse già lì, in ogni riga?
Come funziona?
Il log-prefix di una regola di firewall è un testo fisso: non può contenere variabili. Quindi serve una regola per utente, creata quando l’utente entra e cancellata quando esce:
- al login, uno script crea una regola
action=logconsrc-addressuguale all’indirizzo dell’utente elog-prefixuguale al suo nome; - al logout, lo script cancella quella regola, riconoscendola dal commento.

Passo 1: c’è la regola generale di log?
Questo howto parte dalla regola di log dell’howto precedente, quella con il commento Log connessioni hotspot. Le regole per utente andranno messe subito prima.
C’è un dettaglio da sistemare. action=log scrive la riga e lascia passare il pacchetto alla regola successiva: se anche la regola generale prende gli utenti autenticati, ogni connessione finisce nel log due volte, una con il nome e una senza. In laboratorio è successo proprio questo. La soluzione è far registrare alla regola generale solo i client non ancora autenticati:
/ip firewall filter set [find comment="Log connessioni hotspot"] hotspot=from-client,!auth
Passo 2: come configuro gli script dell’hotspot?
Negli script on-login e on-logout del profilo utente dell’hotspot trovi già pronte le variabili $user (il nome utente) e $address (l’indirizzo del client).
/ip hotspot user profile set [find name=default] on-login={
/ip firewall filter add chain=forward src-address=$address connection-state=new \
action=log log-prefix=("HS-" . $user) comment=("log-utente " . $address) \
place-before=[find comment="Log connessioni hotspot"]
} on-logout={
/ip firewall filter remove [find comment=("log-utente " . $address)]
}
Se i tuoi utenti usano un profilo diverso da default, cambia il nome. Le altre impostazioni dei profili utente sono nel manuale MikroTik: HotSpot User Profiles.
Passo 3: come verifico che funzioni?
Fai login con un utente e apri un sito. Sul router, la regola dell’utente deve comparire:
/ip firewall filter print where comment~"log-utente"
E nel log, al posto del generico HS, c’è il nome. Nel mio laboratorio, con l’utente test:
firewall,info HS-test forward: in:bridge-lan out:ether5, connection-state:new src-mac 50:00:00:1E:00:00, proto TCP (SYN), 192.168.88.199:38646->104.20.21.8:80, len 60
Se gli utenti si registrano con il numero di cellulare, nel log c’è direttamente il numero. Al logout la regola sparisce da sola: ripeti il primo comando per controllare.
Passo 4: e per il PPPoE?
Stessa logica, negli script on-up e on-down del profilo PPP. Le variabili sono $user e $"remote-address", fra virgolette per via del trattino:
/ppp profile set [find name=default] on-up={
/ip firewall filter add chain=forward src-address=$"remote-address" connection-state=new \
action=log log-prefix=("PPP-" . $user) comment=("log-utente " . $"remote-address")
} on-down={
/ip firewall filter remove [find comment=("log-utente " . $"remote-address")]
}
In laboratorio, con un client PPPoE cliente1:
firewall,info PPP-cliente1 forward: in:<pppoe-cliente1> out:bridge-lan, connection-state:new proto ICMP (type 8, code 0), 10.99.0.2->192.168.88.199, len 56
Alla disconnessione la regola viene cancellata. Profili e script PPP sono nel manuale MikroTik: PPP User Profiles.
Passo 5: cosa succede se il router si riavvia?
Le regole create dagli script sono normali regole di firewall: dopo un riavvio restano lì, mentre gli utenti devono rifare il login. Le regole orfane non fanno danni, ma confondono: uno script all’avvio le pulisce.
/system scheduler add name=pulisci-log-utenti start-time=startup \
on-event="/ip firewall filter remove [find comment~\"^log-utente \"]"
Passo 6: ci sono controindicazioni?
Sì, da valutare:
- una regola per utente: con poche centinaia di utenti non è un problema, con migliaia il firewall si allunga e ogni nuova connessione attraversa più regole. Per reti grandi è meglio un RADIUS con accounting, che lega utente e indirizzo nel suo database;
- l’ordine conta: le regole per utente devono stare prima della regola generale, che resta a coprire i client non ancora autenticati.
Passo 7: cosa controllo prima di metterlo in produzione?
Un router che conserva i nomi degli utenti accanto alla loro navigazione va protetto per primo. Se non l’hai ancora fatto, segui l’Hardening di base di un router MikroTik.
Provato in laboratorio su PNETLab con CHR RouterOS 7.24.5 (stable): hotspot con login da client Linux, PPPoE fra due CHR, creazione e cancellazione automatica delle regole, righe di log con il nome utente, pulizia all’avvio.
Domande frequenti
Si può usare una variabile nel log-prefix del firewall MikroTik?
No, il log-prefix è un testo fisso. Per avere il nome utente nel log si crea una regola per ogni utente, con lo script di login, e la si cancella al logout.
Quali variabili ci sono negli script on-login dell’hotspot?
Negli script del profilo utente dell’hotspot si usano $user, il nome utente, e $address, l’indirizzo IP del client.
E negli script del PPPoE?
Negli script on-up e on-down del profilo PPP si usano $user e $"remote-address", l’indirizzo assegnato al client, da scrivere fra virgolette per via del trattino.
Perché ogni connessione compare due volte nel log?
Perché action=log non ferma il pacchetto: lo registra la regola dell’utente e poi anche quella generale. Con hotspot=from-client,!auth sulla regola generale, gli utenti autenticati compaiono una volta sola, con il loro nome.
Che cosa succede alle regole se il router si riavvia?
Le regole create dagli script restano, mentre gli utenti devono riconnettersi. Uno script nello scheduler con start-time=startup le cancella al riavvio, così non restano regole orfane.
Questo howto aggiorna a RouterOS 7 un articolo del 2016 sul mio vecchio blog wirelessguru.it, ormai offline.



