Tracciamento delle sessioni dei residenti e attribuzione degli abusi nelle reti WiFi MDU: Mappatura dei flussi Meraki sull'identità iPSK di Purple

Per attribuire gli abusi su una rete MDU con un singolo IP pubblico, è necessario unire due record. L'esportazione dei flussi di Meraki MX associa l'IP pubblico, la porta sorgente tradotta e il timestamp a un IP interno, un indirizzo MAC e una VLAN. L'identità iPSK e i record di accounting RADIUS di Purple associano quel MAC e quella VLAN a un appartamento specifico. Conserva entrambi per 365 giorni, fatto salvo diverso parere legale.

Che cos'è e come funziona l'attribuzione degli abusi su una rete MDU?

Purple Multi-Tenant WiFi offre a ogni residente di un complesso residenziale multifamiliare (MDU), di un immobile build-to-rent (BTR) o di uno studentato una rete privata del tutto simile alla connessione domestica. Dietro questa esperienza si cela tuttavia un dato architetturale concreto. Ogni residente esce dall'edificio attraverso lo stesso indirizzo WAN pubblico, utilizzando la traduzione delle porte (PAT). La PAT è una forma di NAT in cui molti host interni condividono un unico IP pubblico, distinti solo dalla porta sorgente assegnata dal gateway. Quando un titolare del copyright, un ufficio gestione abusi o le forze dell'ordine effettuano un controllo, vedono un unico indirizzo IP. Si aspettano un solo abbonato dietro di esso, ma in realtà ce ne sono centinaia.

L'attribuzione degli abusi ricostruisce la mappatura mancante. Lo fa combinando i dati provenienti da due piani distinti: i flussi di rete del gateway e i record di identità di Purple. Nessuno dei due è sufficiente da solo. Uniti per indirizzo MAC, VLAN e orario, permettono di risalire da un IP pubblico e da una porta fino a un appartamento con nome e cognome.

Perché un singolo IP pubblico impedisce l'attribuzione

Una tipica segnalazione ai sensi del Digital Millennium Copyright Act americano (DMCA), 17 U.S.C. § 512, contiene tre campi: IP pubblico, porta sorgente e timestamp. La RFC 6302, ovvero le linee guida IETF per i server esposti su Internet, raccomanda di registrare la porta sorgente e un timestamp preciso proprio perché l'indirizzamento condiviso rende ambiguo l'IP da solo. Il tuo compito è rispettare questa struttura. Se i tuoi log contengono la porta tradotta e un orario sincronizzato, è possibile rispondere alla segnalazione. In caso contrario, potrai identificare solo l'edificio e niente di più.

Il ruolo di iPSK

Questa guida presuppone che tu sappia già che cos'è la tecnologia iPSK (Identity Pre-Shared Key). Le guide di Purple "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison" ne coprono i prerequisiti. In breve, la tecnologia iPSK assegna a ogni inquilino una passphrase univoca su un SSID condiviso, e il server RADIUS associa quella chiave a un'identità. Il protocollo RADIUS (Remote Authentication Dial-In User Service, RFC 2865) autentica la sessione. Il RADIUS Accounting (RFC 2866) registra quando la sessione ha inizio, quanto dura e quando termina. Questa guida descrive il livello operativo superiore: trasformare questi record di identità in prove da presentare in sede legale.

Che cosa serve prima di iniziare?

È necessario predisporre quattro elementi prima che arrivi la prima segnalazione. Configurarli a posteriori non funziona, poiché le prove necessarie saranno già andate perse.

1. Un'architettura VLAN per iPSK. La chiave di ciascun inquilino inserisce i propri dispositivi in un segmento layer-3 dedicato prima del confine NAT.
2. Un'esportazione dei flussi da Meraki MX che riporti l'indirizzamento pre-NAT e post-NAT completo di timestamp.
3. Accounting Purple RADIUS abilitato, oltre a un'esportazione regolare della mappa iPSK-tenant.
4. Una politica di conservazione approvata dall'ufficio legale, e NTP in esecuzione su ciascun dispositivo della catena.

Perché la configurazione VLAN per iPSK è superiore a un SSID condiviso unico

Una VLAN (LAN virtuale) è un segmento logico di livello 2, definito dallo standard IEEE 802.1Q, che isola un gruppo di dispositivi da un altro. La risposta RADIUS di Purple può assegnare una VLAN per iPSK, in modo che ogni appartamento venga inserito nella propria sottorete. Questa sottorete diventa un secondo identificatore indipendente. Anche se un indirizzo MAC viene camuffato o reso casuale, l'IP sorgente interno identifica comunque il segmento dell'appartamento.

Architettura	Granularità di attribuzione	Resiste alla casualità del MAC	Isolamento tenant	A chi si adatta
SSID condiviso unico, una sola PSK	Solo edificio	No	Nessuno per impostazione predefinita	Piccoli bar o rete ospite per hall, non residenziale
SSID condiviso, iPSK, senza VLAN	Da MAC del dispositivo a tenant	In parte, tramite registro di accounting al momento della sessione	Solo isolamento client	Fase intermedia durante la migrazione
iPSK con VLAN per tenant	Sottorete dell'appartamento e MAC	Sì, la sottorete identifica comunque l'appartamento	Segmentazione di livello 3 per appartamento	MDU, BTR, alloggi studenteschi, appartamenti con servizi
802.1X con credenziali individuali	Singolo individuo nominativo	Sì	Criterio per utente	Uffici aziendali multi-tenant con dispositivi gestiti

Per i complessi residenziali, la combinazione VLAN per iPSK è la scelta predefinita corretta. Offre due identificatori che devono coincidere: la VLAN e il MAC. Lo standard 802.1X (lo standard IEEE per il controllo dell'accesso basato su porta) identifica il singolo utente. Tuttavia, presenta difficoltà con consolle da gioco, smart TV e altri dispositivi portati dai residenti.

Come si configurano le due acquisizioni dati?

Acquisizione 1: flussi di rete dal Meraki MX

Il Meraki MX può inviare dati relativi a eventi e flussi tramite Syslog (RFC 5424) ed esportare i registri del traffico tramite NetFlow versione 9 (RFC 3954). Configura entrambi nel Dashboard Meraki nelle impostazioni di reportistica del dispositivo. Segui la documentazione ufficiale di Cisco Meraki per i percorsi di menu aggiornati.

Ciò che conta è il set di campi che raggiunge il tuo sistema di raccolta. Per ogni connessione tradotta occorrono:

• IP sorgente interno e porta sorgente
• Indirizzo MAC del client o un'associazione IP-MAC affidabile dai log DHCP
• VLAN o sottorete sorgente
• IP pubblico post-NAT e porta sorgente tradotta
• Timestamp di inizio e fine, con risoluzione al millisecondo dove supportato dall'esportatore

La porta post-NAT è il campo che gli operatori riscontrano mancante più di frequente. In IPFIX (RFC 7011), gli elementi informativi rilevanti sono postNATSourceIPv4Address e postNAPTSourceTransportPort, entrambi definiti nel registro IANA IPFIX. Prima di affidarti all'esportazione, acquisisci un campione. Conferma che il tuo firmware popoli la porta tradotta. In caso contrario, la soluzione alternativa è combinare il firewall MX e il Syslog di flusso con un log di traduzione NAT da un dispositivo a monte che lo registri. Risolvi questo aspetto prima di averne effettivamente bisogno.

Associa i dati di flusso ai log dei lease DHCP. I lease ti forniscono un'associazione tra IP e MAC limitata nel tempo. Tale associazione è la tua rete di salvataggio quando un record di flusso contiene l'IP ma non il MAC.

Acquisizione 2: identità da Purple

Purple fornisce la componente di identità per la combinazione. I record RADIUS Accounting contengono il MAC del client nell'attributo Calling-Station-Id, l'access point in Called-Station-Id e gli orari di inizio e fine sessione. L'Accounting è una parte standard della configurazione RADIUS di Purple su ogni vendor supportato. L'articolo di supporto Purple per Avaya mostra una configurazione tipica, con accounting abilitato e un intervallo di accounting intermedio impostato.

Quello stesso articolo segnala un dettaglio che potrebbe compromettere la tua combinazione. I vendor formattano gli indirizzi MAC in modo diverso: maiuscolo con trattini su uno, minuscolo separato da due punti su un altro. Normalizza ogni MAC in un unico formato al momento dell'ingestione, su entrambi i piani dati.

Il secondo input di identità è la mappa da iPSK a tenant: quale chiave appartiene a quale appartamento e quale VLAN assegna. Esporta questi dati quotidianamente da Purple. In questo modo disporrai di uno snapshot datato di chi possedeva ciascuna chiave nel giorno in questione, non solo di chi la possiede oggi. Le locazioni cambiano. Una chiave che appartiene all'interno 4.12 oggi potrebbe essere appartenuta a un residente precedente sei mesi fa.

Creare la pipeline in autonomia

Se non centralizzi già il Syslog di Meraki, una pipeline open source leggera è sufficiente. Una piccola macchina virtuale Linux basta per la maggior parte delle proprietà con un singolo sito.

1. Collector. Esegui Fluentd o Logstash. Rimani in ascolto su UDP 514, la porta Syslog assegnata dall'IANA, e sulla porta NetFlow prescelta; UDP 2055 è la convenzione comune. Logstash analizza NetFlow v9 e IPFIX con il suo codec netflow.
2. Normalizza all'ingestione. Converti tutti i timestamp in UTC. Converti tutti i MAC in un unico formato. Etichetta ogni record con sito e VLAN.
3. Archivia. Instrada verso Elasticsearch o Grafana Loki. In Elasticsearch, una policy Index Lifecycle Management (ILM) aggiorna gli indici quotidianamente e li elimina al raggiungimento del limite di conservazione. In Loki, il compactor applica un periodo di conservazione. In entrambi i casi, l'eliminazione è automatica e verificabile.
4. Snapshot dell'identità. Pianifica un cron job giornaliero che estrae la mappa attiva da iPSK a tenant da Purple. Scrivila in una tabella di consultazione locale datata. Mantieni gli snapshot con lo stesso piano di conservazione dei flussi.
5. Controllo degli accessi. Limita l'accesso alle query al solo personale nominato. Registra ogni ricerca. Questi record identificano i residenti, quindi trattali come dati personali ai sensi del GDPR.

Il risultato: al momento di una citazione in giudizio, esegui la combinazione offline, sui tuoi dati, senza dover attendere terze parti.

Come si risponde a una segnalazione di abuso?

Quando arriva una segnalazione, esegui ogni volta lo stesso flusso di lavoro.

Segnalazione di abuso
(IP pubblico, porta sorgente, timestamp)
        |
        v
[1] Log di flusso Meraki
    corrispondenza IP post-NAT + porta tradotta
    entro +/- la tolleranza dell'orologio
        |
        v
(IP interno, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    match MAC with session active at timestamp
        |
        v
[3] Dated iPSK-to-tenant snapshot
    match iPSK + VLAN on that date
        |
        v
Apartment / registered occupant

Tre verifiche mantengono il risultato difendibile:

• Disciplina del fuso orario. Convertire prima il timestamp della notifica in UTC. Molte notifiche arrivano nell'ora locale del mittente.
• Coerenza tra identificatori. La VLAN dal registro del flusso deve corrispondere alla VLAN assegnata dall'iPSK. Una mancata corrispondenza indica un errore. Fermarsi e verificare prima di indicare qualsiasi nome.
• La consulenza legale decide la divulgazione. Il risultato è un registro di attribuzione interno. Decidere se e come divulgare, notificare il residente o respingere la richiesta è una decisione legale.

Esempio pratico: dalla notifica all'appartamento

Questa catena utilizza indirizzi di documentazione (RFC 5737) e valori fittizi.

1. Notifica. Un titolare dei diritti segnala un evento di file-sharing da 203.0.113.10, porta di origine 41822, alle 22:17:05 UTC del 14 marzo.
2. Query del flusso. Cercare nell'indice del flusso MX l'IP post-NAT 203.0.113.10 e la porta tradotta 41822, tra le 22:17:03 e le 22:17:07. Un registro corrisponde. Origine interna 10.40.12.37, porta 51544, VLAN 412.
3. Da IP a MAC. Il registro di lease DHCP mostra 10.40.12.37 associato al MAC 3C-22-FB-1A-7E-09 dalle 19:02 alle 23:58 di quel giorno.
4. Query di identità. Purple RADIUS Accounting mostra quel MAC con una sessione attiva dalle 19:02 alle 00:41. La sessione è stata autenticata con l'iPSK assegnato alla VLAN 412.
5. Ricerca dell'inquilino. Lo snapshot iPSK del 14 marzo mappa quella chiave e la VLAN 412 all'appartamento 4.12. Si trasmette la catena alla consulenza legale.

Ogni passaggio è un registro con marca temporale proveniente da un sistema indipendente. Quell'indipendenza è ciò che rende credibile la catena.

Come verificare che la catena funzioni?

Non attendere una vera notifica per scoprire una lacuna. Eseguire una simulazione trimestrale:

• Da un dispositivo di test su un iPSK noto, aprire una connessione a un server esterno controllato. Registrare l'IP pubblico, la porta e l'ora dai log di quel server.
• Eseguire l'intero flusso di lavoro al buio, partendo solo dal registro lato server.
• Confermare che si arrivi all'appartamento di test corretto. Annotare quanto tempo è stato necessario.
• Verificare che il registro più vecchio in ciascun indice si trovi entro il limite di conservazione e non oltre. Una conservazione eccessiva rappresenta un problema relativo al GDPR di per sé.

Se la simulazione fallisce, la causa più comune è una porta post-NAT mancante o un disallineamento dell'orologio. Entrambi sono trattati di seguito.

Cosa interrompe la catena di attribuzione e come risolverlo?

Drift dell'orologio

L'associazione dipende dal tempo. Le porte tradotte vengono riutilizzate nel giro di pochi secondi su un gateway trafficato, quindi pochi secondi di drift possono associare il flusso errato. Puntare l'MX, i punti di accesso, il collector e qualsiasi dispositivo NAT a monte sulle stesse sorgenti NTP (Network Time Protocol, RFC 5905). Registrare i log ovunque in UTC. Inviare un avviso quando lo scostamento di un dispositivo supera un secondo. Se due flussi corrispondono all'interno della finestra di tolleranza, segnalare l'ambiguità alla consulenza legale anziché sceglierne uno.

Carrier-grade NAT a monte

Alcuni ISP posizionano la tua WAN dietro a un NAT carrier-grade (CGNAT, descritto in RFC 6888). L'indirizzo pubblico del tuo MX diventa quindi esso stesso privato. L'avviso conterrà l'indirizzo condiviso e la porta dell'ISP. Solo l'ISP può mappare tali dati sulla tua WAN, e solo i tuoi log possono mappare la tua WAN a un singolo appartamento. I tuoi registri diventano l'unico registro di attribuzione all'interno dell'edificio. Chiedi al tuo ISP se ti trovi dietro CGNAT e richiedi un IP pubblico dedicato, ove possibile.

Condivisione della PSK tra inquilini

Se un residente fornisce la propria iPSK a un vicino, entrambe le famiglie appariranno come un unico appartamento. Imponi la registrazione dei dispositivi: limita i dispositivi per iPSK e richiedi ai residenti di registrare i nuovi dispositivi tramite Purple. Controlla le chiavi il cui numero di dispositivi o sessioni simultanee aumenta all'improvviso. Ruota una chiave il giorno stesso del trasloco dell'utente, come parte del tuo processo di gestione di ingressi, trasferimenti e uscite.

Randomizzazione del MAC

Le attuali versioni di iOS e Android presentano di default un indirizzo MAC privato per rete, e alcune impostazioni lo ruotano. Questo è il motivo per cui ti associ al registro RADIUS Accounting attivo al momento della registrazione, e non a un registro statico dei dispositivi registrati. Con VLAN-per-iPSK, la subnet identifica comunque l'appartamento anche quando un indirizzo MAC è nuovo.

Per quanto tempo si dovrebbero conservare i log?

La conservazione è una questione legale. Concordala con il tuo consulente legale locale prima di configurare qualsiasi cosa. Come base operativa, la maggior parte degli operatori conserva i registri di flusso e di identità per 365 giorni. Questo copre il tempo che solitamente impiega ad arrivare una citazione civile o una richiesta della polizia.

Due pressioni spingono in direzioni opposte. Ai sensi dell'Articolo 5(1)(e) del GDPR, è possibile conservare i dati personali solo per il tempo richiesto dalla finalità. Nel Regno Unito, l'Investigatory Powers Act 2016 limita gli avvisi di conservazione dei dati a 12 mesi. Negli Stati Uniti, le citazioni ai sensi del DMCA § 512(h) possono arrivare molto tempo dopo l'evento. Inserisci il periodo concordato nell'informativa sulla privacy e nelle condizioni di locazione. Lascia quindi che la conservazione di ILM o Loki la applichi automaticamente.

Quanto costa e cosa si ottiene in cambio?

La pipeline fai-da-te funziona su una singola macchina virtuale modesta più lo storage. Dimensiona lo storage misurando una settimana di volume di flusso, moltiplicando per 52 e aggiungendo del margine. Il contributo di Purple, il livello di identità iPSK e RADIUS Accounting, è eseguito sugli access point che già possiedi. Purple è indipendente dall'hardware ed è compatibile con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, senza alcuna necessità di sostituire l'infrastruttura esistente.

Il ritorno si misura nella prevenzione delle interruzioni operativo-gestionali. Due scenari illustrativi mostrano la differenza.

Scenario 1: appartamenti con servizi inclusi in un complesso ricettivo

Un complesso di 180 appartamenti con servizi, gestito insieme a un'attività alberghiera, riceveva ripetute segnalazioni di violazione del copyright su una rete condivisa della struttura. Non essendoci modo di attribuirle, l'operatore ha inviato un'avvertenza via e-mail a tutti i residenti. Sono seguite proteste e l'ISP ha minacciato la sospensione del servizio. L'operatore è quindi passato al modello VLAN per iPSK sull'infrastruttura Meraki esistente e ha attivato la pipeline Logstash descritta sopra. La successiva segnalazione è stata ricondotta a un singolo appartamento in meno di 20 minuti. È stato contattato solo quel residente e non sono stati più necessari avvisi a tutto l'edificio.

Scenario 2: alloggi per lavoratori essenziali del settore pubblico

Un edificio di 90 appartamenti per lavoratori essenziali di proprietà del comune, situato vicino a un ospedale, ha ricevuto una richiesta di dati da parte della polizia relativa a un IP pubblico e una porta. Il team di gestione degli alloggi utilizzava iPSK e VLAN per appartamento, ma conservava i log solo per 30 giorni. L'evento risaliva a un periodo precedente. Dopo una verifica legale, il team ha esteso la conservazione a 365 giorni, ha aggiunto lo snapshot giornaliero delle identità e ha avviato esercitazioni trimestrali. Una richiesta successiva ha ottenuto risposta entro un giorno lavorativo, identificando un singolo appartamento e fornendo la documentazione di ogni hop per i consulenti legali.

Come si adatta al resto della tua infrastruttura

Lo stesso problema si presenta negli uffici aziendali multi-tenant. Un operatore di coworking o un fornitore SaaS che gestisce un'infrastruttura condivisa tra più clienti si trova ad affrontare un unico IP pubblico con molte organizzazioni al di sotto di esso. Purple Staff WiFi applica lo stesso modello incentrato sull'identità, solitamente con 802.1X e Microsoft Entra ID, Okta o Google Workspace come fonte di identità. Il join dei flussi descritto qui si applica esattamente allo stesso modo. Lo stesso schema funziona per i complessi retail ad uso misto con appartamenti sopra i negozi e per le strutture di cura sanitarie che gestiscono alloggi per il personale.

Per maggiori informazioni, consulta le guide su Purple Multi-Tenant WiFi e iPSK di Purple, "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison". Se stai valutando fornitori di RADIUS cloud per questo ruolo, leggi IronWiFi Alternatives for Enterprise Deployments.

Domande frequenti

Dobbiamo sostituire il nostro hardware Meraki per ottenere l'attribuzione a livello di tenant?

No. Purple si sovrappone ai tuoi access point Cisco Meraki e alle appliance MX esistenti come overlay cloud. È sufficiente abilitare iPSK con assegnazione VLAN tramite il RADIUS di Purple, attivare RADIUS Accounting e configurare l'esportazione dei flussi su MX. Lo stesso approccio funziona su HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Il gateway deve solo esportare gli indirizzi pre-NAT e post-NAT con i relativi timestamp.

Purple memorizza i log dei flussi Meraki per noi?

No. Purple gestisce la metà della catena relativa alle identità: assegnazioni iPSK, mappatura VLAN e sessioni RADIUS Accounting. I record dei flussi Meraki e del NAT rimangono in un collector gestito da te, che si tratti di Elasticsearch, Grafana Loki o di un SIEM esistente. Questa separazione ti consente di mantenere il controllo su conservazione, controllo degli accessi e divulgazione. Queste sono decisioni che spettano ai tuoi consulenti legali, non a terze parti.

Per quanto tempo dovremmo conservare i log di flusso e identità?

La maggior parte degli operatori conserva entrambi per 365 giorni, ma la retention è una decisione legale di competenza del vostro ufficio legale. L'Articolo 5(1)(e) del GDPR limita la conservazione a quanto richiesto dalla finalità. Nel Regno Unito, gli avvisi di conservazione dei dati ai sensi dell'Investigatory Powers Act 2016 sono limitati a un massimo di 12 mesi. Qualunque sia il periodo concordato, pubblicatelo nell'informativa sulla privacy ed applicate l'eliminazione automatica con le policy di retention di ILM o Loki.

La registrazione del traffico dei residenti è compatibile con il GDPR?

Sì, a condizione che vengano registrati i metadati di connessione e non i contenuti, e che questi vengano trattati come dati personali. Registrate una base giuridica, in genere legittimo interesse o obbligo di legge, e indicate la finalità e il periodo di conservazione nell'informativa sulla privacy. Limitate l'accesso alle query al personale autorizzato e verificate ogni ricerca. Purple è certificato ISO 27001 e conforme al GDPR, quindi la gestione delle identità rientra già in un framework di controllo certificato.

Cosa succede se un residente condivide la propria iPSK con un vicino?

Le chiavi condivise uniscono due nuclei familiari in un unico record d'appartamento, quindi è necessario prevenirle. Limitate il numero di dispositivi per iPSK e richiedete ai residenti di registrare i nuovi dispositivi tramite Purple. Monitorate eventuali aumenti improvvisi del numero di dispositivi o di sessioni simultanee. Con una VLAN-per-iPSK, la chiave condivisa corrisponde comunque al segmento di un singolo appartamento. Ciò fornisce all'ufficio legale un punto di partenza difendibile, con una riserva documentata.

Possiamo rispondere a una citazione in giudizio se il nostro ISP utilizza un CGNAT (carrier-grade NAT)?

Sì, ma solo se i vostri log sono completi. Dietro un CGNAT, la richiesta riporta l'indirizzo condiviso dell'ISP. L'ISP lo mappa sulla vostra rete WAN e i vostri registri devono mappare la WAN a un appartamento. I vostri log diventano così l'unico registro di attribuzione all'interno dell'edificio. Richiedete al vostro ISP un IP pubblico dedicato, se possibile, e mantenete una rigorosa disciplina NTP.

Quanto sforzo richiede l'implementazione di una pipeline di logging fai-da-te?

Un ingegnere di rete competente può configurare la pipeline open-source su una singola macchina virtuale Linux. Questo copre un collector Fluentd o Logstash, uno storage Elasticsearch o Loki, una policy di retention automatizzata e un'esportazione giornaliera delle identità da Purple. Lo sforzo maggiore risiede nella convalida. Confermate che il firmware della vostra MX esporti la porta sorgente tradotta, quindi eseguite una simulazione di attribuzione al buio prima di affidarvi alla pipeline per una richiesta reale.