MikroTik e Hotspot 2.0 (802.11u e/o Wi-Fi Certified Passpoint), guardate cosa ho scoperto!

MikroTik e Hotspot 2.0 (802.11u e/o Wi-Fi Certified Passpoint), guardate cosa ho scoperto!

Sicuramente conoscerete i nuovi standard Hotspot 2.0, Wi-Fi Certified Passpoint e 802.11u vero? Se non conoscete ancora le nuove specifiche, che descrivono gli hotspot del "futuro", vi invito a visionare i molti docs presenti su internet, alla fine di questo post ne metterò alcuni, in ogni caso sappiate che la maggior parte dei device client presenti sul mercato (sia Apple, Windows o Android) già supportano il "Wi-Fi Certified Passpoint" o Hotspot 2.0 che è una applicazione della WiFi Alliance che si basa sulle specifiche del protocollo 802.11u.

Per chi mi conosce sa che seguo, da sempre, gli sviluppi sia teorici che pratici degli hotspot WiFi, in particolare, sia le sue applicazioni attuali, sia gli sviluppi futuri. Quindi, è ovvio che seguo anche le novità introdotte dal protocollo 802.11u e dal Wi-Fi Certified Passpoint.

Essendo Trainer MikroTik, ogni volta che esce un nuovo firmware, cerco nei changelog qualcosa a riguardo i nuovi standard 802.11u o Hotspot 2.0, ma purtroppo, fino ad oggi, senza successo.

Pochi giorni fa però, girovagando per caso su un terminale di una Routerboard wireless mi è sfuggito un TAB di troppo e mi è apparso un menù mai visto fino ad oggi, il menù "interworking-profiles":

come potete notare, dentro wireless, da un po' di versioni (lo screenshoot è stato acquisito su una 6.33.3) abbiamo un nuovo sotto-menù non documentato. Infatti anche cercando sul wiki ufficiale di MikroTik ma non ho trovato alcuna documentazione in merito e questo mi fa pensare che MikroTik ci stia lavorando ma che non sia ancora pronta per annunciarne l'uscita.

Direi, senza ombra di dubbio, che questa sia un'ottima notizia. Temevo che MikroTik non si allineasse con i "big" degli hotspot (Rockuss, Aruba etc) ma rimanesse "indietro", ma anche questa volta MikroTik non ha deluso.

Come potete apprezzare si parla esplicitamente di hotspot20, ASRA, 3GPP... tutte voci che si leggono nei docs di altri brand ufficialmente compatibili con il nuovo standard hotspot 2.0, come ad esempio Aruba Networks:

http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Content/ArubaFrameStyles/hotspot/predepoyment_overview.htm

Per adesso mi limito a segnalarvi questa "scoperta", dopo aver studiato un po' meglio quello che MikroTik sta sviluppando farò alcuni test e vi aggiornerò.

Ecco qui alcuni link relativi allo standard 802.11u e al WiFi Certified Passpoint (Hotspot 2.0):

https://en.wikipedia.org/wiki/IEEE_802.11u#Hotspot_2.0

https://standards.ieee.org/findstds/standard/802.11u-2011.html

https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint

Conoscete già il nuovo standard Hotspot 2.0 ed le sue specifiche? Sapevate di questo nuovo menù non documentato che rende MikroTik compatibile con il Wi-Fi Certified Passpoint? Lo avete già provato su MikroTik?

Se pensate che questo articolo possa interessare ai vostri colleghi condividetelo subito su Linkedin!

 

SMS Station login failed: You are calling outside your allowed timespan

SMS Station login failed: You are calling outside your allowed timespan

WirelessGuru-SMS-Station-HowtoSe a seguito di una mancata alimentazione della SMS Station di SICE all'improvviso tutta la vostra rete hotspot si blocca, andate a vedere nei log dei captive portal Mikrotik o SICE.

Se nei log trovate il seguente messaggio "Login failed: You are calling outside your allowed timespan" allora si sono disallineate le policy nel database della SMS Station.

La mancata alimentazione, quindi il non corretto shutdown della macchina, può in rari casi causare un problema con la sincronia delle policy. La SMS Station ha le policy collegate anche a funzionalità temporali , in quanto è presente una modulazione dinamica della velocità, ed ecco spiegato l'errore sibillino che appare nei captive portal. Per risolvere la situazione basterà entrare nel pannello di amministrazione della SMS Station (versione 4), andare su "System" e facendo click col tasto destro del mouse andare su "Policy prodotti". Ci verrà presenta la lista delle policy configurate sull'apparato. Entrare sulla prima e fare una modifica, ad esempio abilitare o disabilitare la modulazione dinamica della velocità. Salvare e poi rimettere come prima la policy modificate e, ovviamente, risalvare.

Eseguire questa operazione per tutte le policy presenti nell'elenco.

Una volta fatta questa operazione gli utenti tornaranno online senza problemi.

Vorrei puntualizzare che la SMS Station è un server Linux (basato su CentOS) ottimizzato per ripartire senza problemi anche a fronte di mancata alimentazione. In rari casi, e sottolineo rari casi, può accadere che tale mancanza faccia perdere qualche dato, evidentemente importante, che risiedeva nella cache dell'hard disk e che non è stata correttamente scritta. Al riavvio della macchina il server SQL si trova con delle tabelle incongruenti e tenta una ricostruzione che non sempre finisce in modo felice causando il messaggio di errore.

Come fare a proteggersi? Banalmente assicuratevi di mettere sempre sotto gruppo di continuità o semplice UPS la SMS Station. Se dovete fare dei lavori di spostamento nella sala server che implicano lo spegnimento della macchina eseguire prima un regolare shutdown della macchina ed attendere che Linux abbia completato la procedura di spegnimento.

Per eseguire lo shutdown della SMS Station entrare nella pagina amministrativa e fare click sull'icona di "Chiudi sessione" e poi scegliere il bottone "Spegni".

CAPsMAN: Abilitare il Client Isolation per gli hotspot WiFi Mikrotik

CAPsMAN: Abilitare il Client Isolation per gli hotspot WiFi Mikrotik

WirelessGuru-Mikrotik-Howto

Dalla versione RouterOS 6.11 è stato introdotto il nuovo sistema di gestione centralizzata degli access point chiamato CAPsMAN. Dalla versione 6.23 è disponibile la versione v2 (beta ma perfettamente funzionate e stabile) del controller.

Prima del CAPsMAN per abilitare il Client Isolation dei client wireless collegati agli Access Point WiFi avevamo bisogno di togliere il "flag" default-forwarding nelle impostazioni della scheda radio.

Con il CAPsMAN invece basterà configurare adeguatamente il DataPath relativo disabilitando il "Client-to-Client Forwarding", tale impostazione si effettua, ipotizzando di avere un DataPath configurato chiamato datapath1 con il seguente comando:

[code]

/caps-man datapath set datapath1 client-to-client-forwarding=no

[/code]

[nextpage title="Vantaggi di CAPsMAN"]

Il vantaggio di utilizzare CAPsMAN anche nelle piccole reti WiFi, sia che sia un Hotspot, sia che siano aree private o aziendali protette da WPA2, è che evita di disattivare manualmente il "Default Forwarding" su ogni Access Point ed evita anche l'incapsulamento in vlan o tunnel EoIP dei singoli access point WiFi.

CAPsMAN quindi pur semplificando la gestione e configurazione degli Access Point WiFi, aumenta sensibilmente la sicurezza in quanto implicitamente imposta tunnel di comunicazione tra Controller centralizzato ed Access Point e poi con un semplice comando abilita o disabilita il forwarding dei pacchetti tra i client.

Mi riprometto di scrivere un articolo più esaustivo su controller centralizzato di RouterOS (CAPsMAN) in modo da presentare meglio i pregi introdotti con questo fantastico upgrade.

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.

 

 

Come creare un hotspot WiFi da zero con Mikrotik

Come creare un hotspot WiFi da zero con Mikrotik

Come si configura un'area hotspot WiFi con apparati Mikrotik partendo da zero? Vediamo di seguito come in pochi semplici passi riusciamo a creare un'area WiFi protetta dal captive portal di Mikrotik.

Innanzitutto definiamo l'area hotspot WiFi. Un'area hotspot WiFi è un'area senza protezioni wireless (open, senza wpa/wpa2 o altro) a cui è possibile connettersi liberamente. I tentativi di navigazione saranno però redirezionati verso una pagina di login dal servizio captive portal interno.

Per realizzare un'area hotspot è fondamentale innanzitutto separare l'area hotspot WiFi dalla LAN a cui è connesso internet. Per questo motivo dobbiamo obbligatoriamente utilizzare due subnet distinte di ip. Non è quindi possibile realizzare un'area hotspot WiFi in modalità transparent bridge.

Eseguire sull'apparato un

[code gutter="false"]/system reset-configuration no-default=yes[/code]

per portarlo ad uno stato di inizializzazione. A questo punto assegnamo due indirizzi ip, uno alla scheda wlan1 (la scheda wireless) ed un'altro alla scheda ether1 (la scheda ethernet da cui prenderemo banda internet):

[code gutter="false"]/ip address add address=192.168.1.2/24 interface=ether1 disabled=no
/ip address add address=172.16.0.1/16 interface=wlan1 disabled=no[/code]

l'indirizzo della scheda ether1 in questo esempio è casuale, va ovviamente adattato alla rete che ospiterà il nostro apparato hotspot. Anche l'indirizzo assegnato alla scheda wireless è casuale, ma qui, non avendo vincoli possiamo assegnare una classe ip di nostro gradimento con la sola accortezza di settarla diversa da quella della erher1. Nell'esempio abbiamo assegnato una /16 come maschera a bit (65534 ip), non ci sono regole specifiche per questa scelta, ma è largamento consigliato non limitare il range del dhcp dell'hotspot a "pochi" ip visto che oggigiorno ci sono molti device wireless che si connettono alle aree hotspot gratuite ed una volta che il server dhcp ha esaurito gli ip disponibili si ha l'effetto di una rete wifi "non funzionante".

Una volta configurati gli indirizzi ip dovremo settare anche il default gateway che ci permetterà di raggiungere la rete internet:

[code gutter="false"]/ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1[/code]

il gateway impostato, così come l'ip della ether1, è solo un esempio da adattare alla rete ospite in una configurazione reale.

[nextpage title="Auto Configuratore"]

Una volta assegnati gli indirizzi ip siamo pronti per far partire l'auto configuraratore presente in RouterOS, basta seguire passo passo le richieste del configuratore per arrivare ad avere un buon hotspot setup di base:

[code gutter="false" highlight="1,3,5,6,12,14,16,18,19"]
/ip hotspot setup
Select interface to run HotSpot on
hotspot interface: wlan1
Set HotSpot address for interface
local address of network: 172.16.0.1/16
masquerade network: yes
Set pool for HotSpot addresses
address pool of network: 172.16.0.2-172.16.255.254
Select hotspot SSL certificate
select certificate: none
Select SMTP server
ip address of smtp server: 0.0.0.0
Setup DNS configuration
dns servers: 8.8.8.8
DNS name of local hotspot server
dns name: hotspot.wirelessguru.it
Create local hotspot user
name of local hotspot user: test
password for the user: test
[/code]

Una volta completato il wizard avremo tutto configurato. Basterà configurare la scheda wireless con l'ssid desiderato e la modalità access point (ap-bridge):

[code gutter="false"] /interface wlan1 set ssid=wirelessguru \

mode=ap-bridge wireless-protocol=802.11 \

disabled=no[/code]

A questo punto collegandosi all'ssid configurato si avrà in risposta una pagina di login. Nel wizard abbiamo creato anche un utente test con password test.
Inserendola navigheremo su internet attraverso il nuovo hotspot appena creato.

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