Tenant Session Tracking and Abuse Attribution in MDU WiFi: Mapping Meraki Flows to Purple iPSK Identity

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

Cosa fa effettivamente l'attribuzione degli abusi su una rete MDU?

Purple Multi-Tenant WiFi offre a ogni residente in un'unità abitativa plurifamiliare (MDU), in un blocco destinato all'affitto (BTR) o in una residenza studentesca una rete privata che offre la stessa esperienza della banda larga domestica. Dietro questa esperienza si cela un dato architettonico preciso. Ogni residente esce dall'edificio attraverso lo stesso indirizzo WAN pubblico, utilizzando la traduzione degli indirizzi di porta (PAT). Il PAT è una forma di NAT in cui molti host interni condividono un unico IP pubblico, distinguendosi solo per la porta sorgente assegnata dal gateway. Quando un titolare di copyright, un ufficio abusi o un agente di polizia effettua una ricerca su di te, vede un solo IP. Si aspettano un solo abbonato dietro di esso. Tu ne hai centinaia.

L'attribuzione degli abusi ricostruisce questa mappatura perduta. Lo fa a partire da due piani dati indipendenti: 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 tempo, ti portano da un IP pubblico e una porta a un appartamento designato.

Perché un solo IP pubblico interrompe l'attribuzione

Un tipico avviso ai sensi del Digital Millennium Copyright Act (DMCA) statunitense, 17 U.S.C. § 512, contiene tre campi: IP pubblico, porta sorgente e timestamp. La RFC 6302, la guida dell'IETF per i server esposti a Internet, raccomanda di registrare la porta sorgente e un timestamp accurato proprio perché l'indirizzamento condiviso rende ambiguo il solo IP. Il tuo compito è rispettare questa progettazione. Se i tuoi log contengono la porta tradotta e un orario sincronizzato con precisione, l'avviso diventa tracciabile. In caso contrario, potrai identificare l'edificio e nulla più.

Cosa contribuisce l'iPSK

Questa guida presuppone che tu sappia già cosa sia l'iPSK (Identity Pre-Shared Key). Le guide di Purple "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison" coprono i requisiti preliminari. In breve, l'iPSK assegna a ogni inquilino una passphrase univoca su un SSID condiviso, e il server RADIUS associa tale chiave a un'identità. RADIUS (Remote Authentication Dial-In User Service, RFC 2865) autentica la sessione. RADIUS Accounting (RFC 2866) registra quando inizia, quanto dura e quando si interrompe. Questa guida copre il livello operativo sovrastante: trasformare quei record di identità in prove da consegnare ai legali.

Di cosa hai bisogno prima di iniziare?

Hai bisogno di quattro elementi pronti prima che arrivi il primo avviso. Costruirli a posteriori non funziona, perché le prove di cui hai bisogno saranno già andate perdute.

1. Un design VLAN-per-iPSK. La chiave di ogni inquilino inserisce i suoi 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 con i relativi timestamp.3. Purple RADIUS Accounting abilitato, oltre a un'esportazione regolare della mappa iPSK-tenant.
3. Una policy di conservazione approvata dal consulente legale, e NTP in esecuzione su ogni dispositivo della catena.

Perché la VLAN-per-iPSK supera un SSID condiviso piatto

Una VLAN (LAN virtuale) è un segmento logico di livello 2, definito in IEEE 802.1Q, che isola un gruppo di dispositivi dall'altro. La risposta RADIUS di Purple può assegnare una VLAN per iPSK, in modo che ogni appartamento atterri nella propria sottorete. Tale sottorete diventa un secondo identificatore indipendente. Anche se un MAC viene contraffatto o randomizzato, l'IP di origine interno identifica comunque il segmento dell'appartamento.

Progettazione	Granularità di attribuzione	Sopravvive alla randomizzazione MAC	Isolamento dei tenant	A chi è adatto
SSID condiviso piatto, una PSK	Solo edificio	No	Nessuno per impostazione predefinita	Piccoli bar o reti ospiti per reception, non residenziale
SSID condiviso, iPSK, senza VLAN	Da MAC del dispositivo a tenant	Parzialmente, tramite record di accounting al momento della sessione	Solo client isolation	Fase transitoria durante la migrazione
iPSK con VLAN per tenant	Sottorete dell'appartamento e MAC	Sì, la sottorete identifica comunque l'appartamento	Segmentazione Layer-3 per appartamento	MDU, BTR, alloggi per studenti, appartamenti serviti
802.1X con credenziali per persona	Individuo nominato	Sì	Policy per utente	Uffici aziendali multi-tenant con dispositivi gestiti

Per i complessi residenziali, la VLAN-per-iPSK rappresenta 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) raggiunge l'individuo. Tuttavia, presenta difficoltà con console di 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 di eventi e flussi tramite Syslog (RFC 5424) ed esportare record di traffico tramite NetFlow versione 9 (RFC 3954). Configura entrambi nel Meraki Dashboard sotto le impostazioni di reportistica dell'appliance. Segui la documentazione di Cisco Meraki per i percorsi di menu aggiornati.

Ciò che conta è l'insieme di campi che raggiunge il tuo raccoglitore. Per ogni connessione tradotta hai bisogno di:

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

La porta post-NAT è il campo che gli operatori trovano più spesso mancante. In IPFIX (RFC 7011), gli elementi informativi rilevanti sono postNATSourceIPv4Address e postNAPTSourceTransportPort, entrambi definiti nel registro IANA IPFIX. Prima di fare affidamento sull'esportazione, acquisisci un campione. Conferma che il tuo firmware compili la porta tradotta. In caso contrario, la soluzione di ripiego è l'unione dei log del firewall MX e del Syslog di flusso con un log di traduzione NAT proveniente da un dispositivo a monte che lo registri. Risolvi questo aspetto prima che si presenti la necessità.

Associa i dati di flusso con i log dei lease DHCP. I lease forniscono un'associazione IP-MAC limitata nel tempo. Tale associazione rappresenta la tua rete di sicurezza quando un record di flusso contiene l'IP ma non il MAC.

Acquisizione 2: identità da Purple

Purple fornisce la componente di identità per l'unione dei dati. I record di 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 per ogni vendor supportato. L'articolo di supporto di Purple per Avaya mostra una configurazione tipica, con l'accounting abilitato e un intervallo di accounting provvisorio impostato.

Lo stesso articolo evidenzia un dettaglio che potrebbe compromettere l'unione dei dati. I vendor formattano gli indirizzi MAC in modi diversi: maiuscolo con trattini su uno, minuscolo separato da due punti su un altro. Normalizza ogni MAC in un unico formato al momento dell'importazione, su entrambi i piani dati.

Il secondo input di identità è la mappa iPSK-tenant: quale chiave appartiene a quale appartamento e quale VLAN assegna. Esporta questo report giornalmente da Purple. In questo modo disporrai di un'istantanea datata di chi possedeva ciascuna chiave nel giorno in questione, e non solo di chi la possiede oggi. I contratti di locazione cambiano. Una chiave che oggi appartiene all'appartamento 4.12 potrebbe essere appartenuta a un inquilino precedente sei mesi fa.

Creare la pipeline in autonomia

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

1. Collettore. Esegui Fluentd o Logstash. Ascolta sulla porta UDP 514, la porta Syslog assegnata da IANA, e sulla porta NetFlow scelta; UDP 2055 è la convenzione comune. Logstash analizza NetFlow v9 e IPFIX con il suo codec netflow.
2. Normalizzazione all'importazione. Converti tutti i timestamp in UTC. Converti tutti i MAC in un unico formato. Tagga ogni record con sito e VLAN.
3. Archiviazione. Invia a Elasticsearch o Grafana Loki. In Elasticsearch, un criterio di Index Lifecycle Management (ILM) ruota gli indici giornalmente e li elimina al raggiungimento del limite di conservazione. In Loki, il compattatore applica un periodo di conservazione. In entrambi i casi, l'eliminazione è automatica e verificabile.
4. Istantanea dell'identità. Pianifica un cron job giornaliero che estragga la mappa iPSK-tenant attiva da Purple. Scrivila in una tabella di ricerca locale datata. Mantieni le istantanee con lo stesso programma di conservazione dei flussi.
5. Controllo degli accessi. Limita l'accesso alle query al personale nominato. Registra ogni ricerca. Questi record identificano i residenti, pertanto trattali come dati personali ai sensi del GDPR.

Il risultato: in caso di mandato d'esibizione, esegui l'unione offline, sui tuoi stessi dati, senza attendere terze parti.

Come si risponde a una notifica di abuso?

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

Notifica di abuso
(IP pubblico, porta sorgente, timestamp)
        |
        v
[1] Log di flusso Meraki
    corrispondenza IP post-NAT + porta tradotta
    entro la tolleranza del clock di +/- 
        |
        v
(IP interno, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    corrispondenza MAC con sessione attiva al timestamp
        |
        v
[3] Snapshot datato iPSK-to-tenant
    corrispondenza iPSK + VLAN in quella data
        |
        v
Appartamento / occupante registrato

Tre verifiche mantengono il risultato difendibile:

• Disciplina del fuso orario. Converti prima il timestamp della notifica in UTC. Molte notifiche arrivano nell'ora locale del mittente.
• Accordo tra identificatori. La VLAN del record di flusso deve corrispondere alla VLAN assegnata dall'iPSK. Una mancata corrispondenza indica che qualcosa non va. Fermati e indaga prima di fare qualsiasi nome.
• Il consulente legale decide la divulgazione. Il tuo output è un record di attribuzione interno. Se e come divulgare, notificare al residente o opporsi è 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 sorgente 41822, alle 22:17:05 UTC del 14 marzo.
2. Query di flusso. Cerchi nell'indice dei flussi 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 record corrisponde. Sorgente interna 10.40.12.37, porta 51544, VLAN 412.
3. Da IP a MAC. Il registro dei 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 si è 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. Consegni la catena al consulente legale.

Ogni passaggio è un record con timestamp proveniente da un sistema indipendente. Questa indipendenza è ciò che rende credibile la catena.

Come verificare che la catena funzioni?

Non aspettare una notifica reale per scoprire una lacuna. Esegui un'esercitazione trimestrale:

• Da un dispositivo di test su un iPSK noto, apri una connessione a un server esterno che controlli. Registra l'IP pubblico, la porta e l'ora dai log di quel server.
• Esegui l'intero flusso di lavoro alla cieca, partendo solo dal record lato server.
• Conferma di arrivare all'appartamento di test corretto. Prendi nota del tempo impiegato.
• Verifica che il record più vecchio in ciascun indice si trovi al tuo limite di conservazione e non oltre. La conservazione eccessiva è di per sé un problema in termini di GDPR.

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

Cosa interrompe la catena di attribuzione e come risolverlo?

Disallineamento dell'orologio

L'unione dipende dal tempo. Le porte tradotte vengono riutilizzate nel giro di pochi secondi su un gateway trafficato, quindi pochi secondi di disallineamento possono corrispondere al flusso errato. Indirizza l'MX, i tuoi punti di accesso, il collettore e qualsiasi dispositivo NAT a monte verso le stesse sorgenti NTP (Network Time Protocol, RFC 5905). Registra ovunque in UTC. Invia un avviso quando l'offset di qualsiasi dispositivo supera un secondo. Se due flussi corrispondono all'interno della tua finestra di tolleranza, segnala l'ambiguità al consulente legale anziché sceglierne uno.

Carrier-grade NAT a monte

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

Condivisione della PSK tra inquilini

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

Randomizzazione dell'indirizzo MAC

Le versioni attuali di iOS e Android presentano un MAC privato per rete per impostazione predefinita, e alcune impostazioni lo ruotano. Questo è il motivo per cui l'associazione avviene sul record RADIUS Accounting attivo al momento del timestamp, e non su un registro statico dei dispositivi iscritti. Con la VLAN per iPSK, la sottorete identifica comunque l'appartamento anche quando il MAC è nuovo.

Per quanto tempo conservare i log?

La conservazione è una questione legale. Concordala con il tuo ufficio legale locale prima di configurare qualsiasi cosa. Come base minima, la maggior parte degli operatori conserva i record 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 forze 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à del trattamento. 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. Scrivi il periodo concordato nella tua informativa sulla privacy e nei termini di locazione. Dopodiché lascia che la conservazione di ILM o Loki lo applichi automaticamente.

Quanto costa e quali sono i vantaggi?

La pipeline fai-da-te funziona su una singola macchina virtuale di dimensioni modeste più lo storage. Dimensiona lo storage misurando una settimana di volume di flusso, moltiplicando per 52 e aggiungendo un margine di sicurezza. Il contributo di Purple, ovvero il livello di identità iPSK e il RADIUS Accounting, viene eseguito sugli access point che già possiedi. Purple è hardware-agnostic e supporta Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, senza richiedere alcuna sostituzione di hardware.

Il ritorno sull'investimento si misura in termini di disservizi evitati. Due scenari illustrativi mostrano la differenza.

Scenario 1: appartamenti serviti in un complesso ricettivo

Un complesso di appartamenti serviti da 180 unità, gestito insieme a un'attività di hotel, riceveva ripetute segnalazioni di violazione del copyright su una rete condivisa flat. Senza la possibilità di attribuirle a un utente specifico, l'operatore ha inviato un avviso via email a tutti i residenti. Ne sono scaturiti reclami e l'ISP ha minacciato la sospensione del servizio. L'operatore è passato a una configurazione VLAN-per-iPSK sulla sua infrastruttura Meraki esistente e ha implementato la pipeline Logstash descritta sopra. La segnalazione successiva è stata ricondotta a un singolo appartamento in meno di 20 minuti. Solo quel residente è stato contattato e non sono stati più necessari ulteriori avvisi a tutto l'edificio.

Scenario 2: alloggi per lavoratori chiave nel settore pubblico

Un edificio di proprietà del consiglio comunale con 90 appartamenti per lavoratori chiave vicino a un sito ospedaliero ha ricevuto una richiesta di dati dalla polizia riguardante un IP pubblico e una porta. Il team di gestione degli alloggi disponeva di iPSK e VLAN per appartamento, ma conservava solo 30 giorni di log. L'evento rientrava al di fuori di tale finestra temporale. Dopo una revisione legale, il team ha esteso la conservazione a 365 giorni, ha aggiunto l'istantanea giornaliera dell'identità e ha avviato esercitazioni trimestrali. Una richiesta successiva ha ricevuto risposta entro un giorno lavorativo, identificando un singolo appartamento, con ogni passaggio documentato per i consulenti legali.

Collocazione all'interno della tua infrastruttura più ampia

Lo stesso problema si presenta negli uffici aziendali multi-tenant. Un operatore di coworking, o un fornitore SaaS che gestisce un'infrastruttura condivisa tra diversi tenant client, si trova a gestire un unico IP pubblico con molte organizzazioni alle sue spalle. Purple Staff WiFi applica lo stesso modello incentrato sull'identità in quel contesto, tipicamente con 802.1X e Microsoft Entra ID, Okta o Google Workspace come origine di identità. Il flusso di unione descritto qui si applica in modo identico. Lo stesso schema serve progetti a uso misto retail con appartamenti sopra i negozi e strutture di healthcare che gestiscono alloggi per il personale.

Per maggiori informazioni, consulta le guide Purple Multi-Tenant WiFi e le guide iPSK di Purple, "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison". Se stai confrontando i fornitori di cloud RADIUS 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 integra come overlay cloud sopra i tuoi access point Cisco Meraki e dispositivi MX esistenti. Abilita iPSK con assegnazione VLAN tramite il RADIUS di Purple, attiva il RADIUS Accounting e configura l'esportazione dei flussi sul dispositivo MX. Lo stesso approccio funziona su HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Il gateway deve solo esportare l'indirizzamento pre-NAT e post-NAT con i relativi timestamp.

Purple memorizza i log dei flussi Meraki per noi?

No. Purple conserva la metà della catena relativa all'identità: assegnazioni iPSK, mappatura VLAN e sessioni di RADIUS Accounting. I record dei flussi Meraki e del NAT rimangono in un raccoglitore sotto il tuo controllo, che si tratti di Elasticsearch, Grafana Loki o di un SIEM esistente. Questa suddivisione ti consente di mantenere il controllo su conservazione, controllo degli accessi e divulgazione dei dati. Queste sono decisioni che spettano al tuo consulente legale, non a una terza parte.

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

La maggior parte degli operatori conserva entrambi per 365 giorni, ma la conservazione è una decisione legale che spetta ai vostri consulenti legali. L'Articolo 5(1)(e) del GDPR limita la conservazione a quanto richiesto dalle finalità del trattamento. 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 nella vostra informativa sulla privacy e applicate la cancellazione automatica con i criteri di conservazione di ILM o Loki.

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

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

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

Le chiavi condivise uniscono i dati di due nuclei familiari in un unico record d'appartamento, pertanto è necessario prevenirle. Limitate il numero di dispositivi per iPSK e richiedete ai residenti di registrare i nuovi dispositivi tramite Purple. Monitorate eventuali picchi improvvisi nel numero di dispositivi o sessioni simultanee. Utilizzando una VLAN-per-iPSK, la chiave condivisa farà comunque riferimento al segmento di un singolo appartamento. Questo offre ai vostri consulenti legali un punto di partenza difendibile, con una riserva documentata.

Possiamo rispondere a un mandato di comparizione se il nostro ISP utilizza un CGNAT (carrier-grade NAT)?

Sì, ma solo se i vostri log sono completi. Dietro a un CGNAT, la notifica riporta l'indirizzo condiviso dell'ISP. L'ISP mappa quell'indirizzo sulla vostra WAN, e i vostri registri devono mappare la vostra WAN su un appartamento specifico. I vostri log diventano così l'unico record di attribuzione all'interno dell'edificio. Richiedete al vostro ISP un IP pubblico dedicato, ove possibile, e mantenete una sincronizzazione precisa del protocollo 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. Questa include un raccoglitore Fluentd o Logstash, uno storage Elasticsearch o Loki, una policy di conservazione automatizzata e un'esportazione giornaliera delle identità da Purple. Lo sforzo maggiore risiede nella validazione. Verificate che il firmware del vostro MX esporti la porta sorgente tradotta, quindi eseguite un test di attribuzione alla cieca prima di fare affidamento sulla pipeline per una notifica reale.