Come eseguire uno script per ogni lease del DHCP server di Mikrotik

Come eseguire uno script per ogni lease del DHCP server di Mikrotik

WirelessGuru-Mikrotik-HowtoAvete mai avuto l'esigenza di eseguire uno script per ogni client che si collega al dhcp server di Mikrotik?

Nelle recenti versioni di RouterOS è stata proprio aggiunta questa possibilità. Nella sezione DHCP server abbiamo una nuova opzione chiamata "Lease Script" che ci permette di eseguire un comando/script per ogni client a cui viene assegnato l'indirizzo ip dal nostro DHCP server o per ogni client che viene rilasciato/liberato dall'elenco dei leases (in quanto non  più presente).
Come variabili, a livello global, nel nostro script possiamo utlizzare:

  • $leaseBound 
  • $leaseServerName
  • $leaseActMAC
  • $leaseActIP

$leaseBound avrà valore 1 se il server ha dato l'ip a quel client, mentre ha valore 0 (zero) se il server ha liberato l'ip dai leases.

$leaseServerName avrà il nome del server DHCP che ha dialogato con il client.

$leaseActMAC conterrà il mac-address della macchina che ha ricevuto l'ip dal server.

$leaseActIP infine conterrà il l'ip assegnato in quel momento al client.

[nextpage title="Esempi d'uso"]

Ma a cosa può servire? Beh come molte opzioni presenti in RouterOS può sembrare inizialmente oscura la sua applicazione pratica, ma potrebbe capitare di doverla usare.

Ad esempio potremmo creare un sistema che generi dei walled garden temporanei per gli host; una esigenza potrebbe essere quella di permettere per 10 minuti l'accesso a social network (ad esempio Facebook) per sfruttarne le sue API ed implementare sul nostro hotspot un Social Login.
Come tutti ben sanno, ad oggi, non è possibile implementare il Social Login di Facebook senza mettere nei walled garden tutto Facebook, ma grazie al Lease-script del DHCP di RouterOS possiamo "liberare" Facebook in maniera temporanea host per host.

Visto l'alto interesse riguardo a questo argomento (permettere temporaneamente l'accesso a Facebook per un tempo limitato), mi riprometto di creare una guida step-by-step nei prossimi giorni.

 

 

Proteggere gli host collegati alla WAN del captive portal da potenziali attacchi dei client della rete Hotspot WiFi

Proteggere gli host collegati alla WAN del captive portal da potenziali attacchi dei client della rete Hotspot WiFi

Nelle installazioni di aree hotspot non dobbiamo sottovalutare la sicurezza della rete del cliente.

La rete hotspot vista la sua natura di rete "aperta" agli ospiti è necessario sia isolata dalla rete LAN dove risiedono normalmente server ed host "a rischio". Per fare questo andrebbero utilizzate delle vlan o addirittura reti parallele isolate e con accesso ad internet dedicato.

Purtroppo troppo spesso questo non è fattibile, sia per problematiche di budget che strutturali. In questi casi è necessario configurare opportunamente il firewall interno degli apparati RouterOS per garantire un buon livello di sicurezza.

Ipotizzando che la lan da proteggere sia 10.10.0.0/16 andremo ad aggiungere questa semplice regola:

/ip firewall filter add chain=forward \
hotspot=from-client dst-address=10.10.10.0/24 \
action=reject reject-with=icmp-net-prohibited \
comment="Protect LAN from Hotspot Clients"

Con questa regola di firewall abbiamo inibito qualunque accesso/attacco alla rete del cliente dalla sottorete gestista dall'hotspot. Semplice no?

Vediamo in dettaglio cosa abbiamo inserito:

hotspot=from-client dst-address=10.10.10.0/24 \

in questo punto definiamo 2 cose importanti:

  1. Cosa dobbiamo proteggere: tutta la classe 10.10.10.0/24
  2. Da chi. E qui vieni in aiuto l'helper "hotspot" del firewall di RouterOS che ci permette di catturare tutti i pacchetti generati dai client dell'area WiFi
action=reject reject-with=icmp-net-prohibited \
comment="Protect LAN from Hotspot Clients"

qui andiamo a specificare l'azione da attuare sui pacchetti identificati. L'action "reject" si occupa di bloccare il pacchetto e di inviare al client un errore icmp "Network Prohibited", in alternativa è utilizzabile anche l'action "drop" che in maniera silente blocca solo il traffico indesiderato.

In chiusura non dimentichiamoci di inserire un commento descrittivo alla regola inserita in modo da poterne comprendere il significato anche a distanza di mesi dalla configurazione.

E se non conosciamo a priori la classe ip da proteggere? Immaginiamo di voler una configurazione flessibile con il device hotspot in DHCP client sulla parte WAN.

Come facciamo a proteggerla?

In questo caso la configurazione si complica, ma attraverso uno script lanciato dallo scheduler interno della macchina riusciamo a risolvere.

Create il seguente script nella repository interna e chiamatelo "WAN-Guardian":

:local WANIface
:local IP;
:local NETWORK;
:local NETWORK2;
:local BITMASK;
:local i;
:local L;
:local wanGuardItem;

:set WANIface ether1

:set NETWORK [/ip address get [find interface=$WANIface network];
:set IP [/ip address get [find interface=$WANIface] address];
:set L [:len $IP]

:for i from=( [:len $IP] - 1) to=0 do={
 :if ( [:pick $IP $i] = "/") do={
 :set BITMASK [:pick $IP $i $L]
 }
 }
 :set NETWORK2 ("$NETWORK" . "$BITMASK");
 :log info "Customer LAN is NETWORK $NETWORK2" ;

#rimuovo la vecchia address-list del firewall
 :foreach wanGuardItem in=[/ip firewall address-list find list=wanGuard] do={
 /ip firewall address-list remove $wanGuardItem;
 }

#Aggiungo la nuova entry
 /ip firewall address-list add list=wanGuard address=$NETWORK2;

Lo script appena creato estrae l'indirizzo ip e la maschera a bit assegnata all'interfaccia WAN (da specificare nello script) e popola una address list del firewall chiamata wanGuard.

A questo punto la regola di firewall creata precedentemente, dove in maniera esplicita indicavamo la network da proteggere, deve essere modificata in (riga 2):

 /ip firewall filter add chain=forward \
 hotspot=from-client dst-address-list=wanGuard \
 action=reject reject-with=icmp-net-prohibited \
 comment="Protect LAN from Hotspot Clients"

in questo modo la regola di firewall andrà a leggere gli indirizzi di destinazione nella address list popolata dal nostro script.

Adesso basterà creare un evento schedulato in System -> Scheduler che lanci ogni tot minuti lo script WAN-Guard in modo da tenere aggiornata la nostra address-list:

/system scheduler add name=WAN-Guardian \
 start-time=startup interval=10m \
 on-event=WAN-Guardian

A questo punto abbiamo realizzato una protezione flessibile della WAN in quanto anche modificando in un secondo momento l'ip o spostando di sede la macchina non dobbiamo preoccuparci di adeguare le regole di firewall.

HashFlare
HashFlare
HashFlare
HashFlare
HashFlare
HashFlare
HashFlare
HashFlare
HashFlare
HashFlare
HashFlare