Indice
- Poco prima delle otto di martedì sera
- Cosa vede un Repeater, e cosa no
- Quanto era davvero?
- Una serata nel gruppo
- Detective con dei limiti
- La terza notte: una scritta sulla mappa
- Il mittente ha violato le regole?
- Chi legge, e chi accusa
- E nel caso di emergenza?
- Il test e cosa ha mostrato
- Cosa se ne può trarre
- Nota di trasparenza
La cosa più importante subito: la rete ha retto. Per tre giorni la rete MeshCore della Carinzia è stata inondata di spam e di nodi falsi, e ha continuato a funzionare. Lo vedo come un test che non avrei mai ordinato e che la rete ha superato comunque. Qui racconto cosa è successo, dal mio punto di vista di uno dei gestori.
Poco prima delle otto di martedì sera
Il 10 novembre alle 19:37 è cominciato. Nella rete MeshCore della Carinzia sono comparsi messaggi che nessuno può scrivere così in fretta: sul canale pubblico e su quattro canali hashtag, al massimo 19 al minuto, cioè uno ogni tre secondi. Fino alle 00:35 furono 471 messaggi da nove nomi di dispositivo fissi.
Poi è tornata la calma. Per tutta la notte e la mattina la rete ha funzionato come se nulla fosse.
Mercoledì alle 17:12 è ricominciato, questa volta con un trucco. Il nome del dispositivo cambiava dopo ogni singolo messaggio. In poco più di due ore, fino alle 19:16, sono arrivati 377 messaggi sotto 261 nomi diversi, partendo da soli sette nomi di base, con da 116 a 163 nomi nuovi all'ora. Chi vuole nascondere una cosa del genere non va lontano con una lista di blocco.
Non se n'è accorto uno solo. Se ne è accorta tutta la rete. Chi aveva il canale pubblico aperto vedeva scorrere i messaggi.
Tutti gli orari nel testo sono CET (ora dell'Europa centrale), il grafico qui sotto è in UTC. I numeri provengono dai pacchetti della mappa pubblica e sono calcolati, non misurati via radio.
Cosa vede un Repeater, e cosa no
Perché è così difficile difendersi da una cosa del genere? Perché un Repeater MeshCore non sa quasi nulla.
Un messaggio di canale è cifrato. Il Repeater vede l'intestazione del pacchetto, il percorso fatto finora e un hash del canale. Contenuto, nome e mittente non li vede. Inoltra il pacchetto come qualsiasi altro.
Questo inoltro si chiama Flood: ogni Repeater nel raggio di ricezione ripete il pacchetto, i suoi vicini lo ripetono di nuovo, finché non è arrivato dappertutto. Questo rende robusta una rete senza percorsi fissi. La rende anche vulnerabile. Con i parametri radio di CarinthiaMesh (SF8, 62,5 kHz, CR8) un pacchetto di circa 109 byte occupa circa un secondo di tempo di trasmissione per ogni inoltro, e ognuno di questi costa spazio radio a tutti quelli nel raggio.
Quanto era davvero?
Un giorno normale nella rete si presenta così: in media circa 180 pacchetti Flood all'ora. Al picco della prima ondata (notte sull'11.11., dalle 00 alle 01) furono 390, di cui 243 dal mittente, cioè il 62 per cento. Al picco della seconda ondata (11.11., dalle 18 alle 19) furono 348, di cui 200, ovvero il 57 per cento.
Il carico sui Repeater è quindi circa raddoppiato, e la rete lo ha sopportato senza problemi: il normale traffico dei canali è proseguito, tutti e sei gli Observer sono rimasti attivi e la rete è rimasta utilizzabile. Come prova di stress era un buon segnale.
Colpiva ancora una cosa nei percorsi della seconda ondata. Nessun Observer ha sentito un pacchetto con meno di due Hop. Nel 40 per cento dei percorsi lo stesso Repeater compariva due volte, nel resto del traffico è il 13 per cento. E i primi Hop si distribuivano in modo uniforme su molti Repeater in tutta la Carinzia. Sembra un percorso falso, precompilato. Un gestore del gruppo l'ha vista allo stesso modo: il mittente scrive qualche pseudo-Hop nell'intestazione per confondere. Per la localizzazione questi percorsi sono quindi inutili.
Una serata nel gruppo
Mentre la seconda ondata era in corso, nel gruppo MeshCore di Kärnten Funkt è successo quello che succede sempre in questi momenti: prima la rabbia, poi le idee, poi il lavoro.
La rabbia era vera. Uno ha detto che finché andava avanti così non si poteva nemmeno pensare a delle esercitazioni. Un altro ha proposto di spegnere subito i Repeater in tutta la regione, perché al mittente passi la voglia.
Poi si è passati al concreto, e il gruppo ha chiarito alcune cose che ogni principiante dovrebbe sapere:
- Bloccare nel proprio client ripulisce solo la propria visualizzazione. I pacchetti continuano a circolare nella rete e consumano tempo di trasmissione. E poiché il nome cambia di continuo, non c'è nulla su cui filtrare.
- Il mittente non si può bloccare. Si possono solo staccare dalla rete i punti da cui entra. Ma allora restano fuori anche tutti gli altri.
- Spegnere non significa spegnere davvero. Si intende disattivare l'inoltro (
set repeat off). Il Repeater resta raggiungibile, semplicemente non porta più nulla attraverso la rete. Anche questo è stato chiarito in breve, perché tutti facessero la stessa cosa.
Poi si è passati all'azione. Per prima è caduta la ritrasmissione in un punto di ingresso nella zona di Spittal. Poi l'ho disattivata io sul Dobratsch, lo snodo tra la Carinzia meridionale e occidentale e il resto, e per ultima è caduta sulla Koralpe a est, perché la piena non uscisse verso l'Austria attraverso il ramo del Lavanttal. Un gestore ha tolto il suo Repeater dalla rete per tutta la notte. Poco dopo lo spegnimento è tornata la calma, se sia stato un caso o un effetto non lo sappiamo. E la calma non è durata: più tardi, in serata, i gestori hanno segnalato che era ricominciato. Questa fase non è inclusa nei numeri di questo articolo.
Dopo, tutti i Repeater sono tornati in funzione. Chi spegne al punto di ingresso toglie a tutti gli altri la strada verso la rete, questo è il prezzo. Il piano nato da questa valutazione è nel wiki: wiki.carinthiamesh.com/flood-abwehr (riconoscere i loop, limite di Hop, duty cycle, interruttore di emergenza, trovare il mittente).
Detective con dei limiti
Nel frattempo alcuni gestori hanno cominciato a stringere il cerchio intorno al mittente. In due hanno unito le forze. Uno ha registrato dalla sera ogni pacchetto con tutti i metadati e ha offerto i dati a chiunque volesse farci analisi proprie. Altri hanno pensato a una radiogoniometria con SDR e antenna direttiva per gli 869 MHz.
Poi è arrivata la domanda se dall'intensità di ricezione si possa ricavare una distanza. La risposta del gruppo: non in modo affidabile. Il rapporto segnale/rumore dipende anche dal rumore locale, la potenza ricevuta (RSSI) sarebbe il valore migliore. Un gestore ha misurato in un giorno un Repeater a 18 chilometri più forte di uno a 8 chilometri, entrambi in vista libera. Altri hanno riferito di Repeater che non si sentono nonostante la breve distanza perché c'è una collina in mezzo, e di percorsi in cui comparivano Repeater che in realtà non dovrebbero potersi sentire. Questo concorda con quello che già sospettiamo: il percorso è stato probabilmente falsificato. Triangolare, in conclusione, è più difficile di quanto si pensasse.
Chi sia, quindi, non lo sappiamo.
La terza notte: una scritta sulla mappa
Poi è arrivato giovedì, e con lui una sorpresa che con i messaggi non c'entrava nulla. Nella notte sul 12 novembre sulla mappa sono comparsi all'improvviso 190 nodi nuovi, le cui posizioni messe insieme formavano una scritta a nord della Carinzia.
I fatti: dalle 01:39 alle 02:06, per circa 27 minuti, sono arrivati 356 pacchetti Advert, fino a 24 al minuto, sotto 190 nomi diversi. 90 nomi sono comparsi con un solo Advert, gli altri con da due a cinque. I pacchetti circolavano come normali Flood su tutti i Repeater, lunghi in media 124 byte, e cinque Observer li hanno sentiti. Dopo non è arrivato più nulla.
Il danno: la mappa è falsata finché i nodi non scadono dopo sette giorni. Al traffico radio ha fatto poco male, 356 pacchetti in mezz'ora sono sopportabili per la rete. Se dietro ci sia lo stesso mittente delle piene di messaggi resta aperto.
Il mittente ha violato le regole?
Nel gruppo qualcuno ha chiesto se il mittente, così facendo, abbia violato delle regole. Per rispondere bisogna sapere cosa vale in realtà nella nostra banda.
MeshCore in Europa funziona nella banda degli 869 MHz, una banda per dispositivi a corto raggio (Short Range Devices). Si può usare senza licenza, ma non senza condizioni. L'Austria rimanda per questo, nell'ordinanza austriaca sull'uso delle frequenze 2013 (FNV 2013), alla decisione UE 2006/771/CE sui dispositivi a corto raggio. Per la gamma da 869,4 a 869,65 MHz vale quanto segue: al massimo 500 mW di potenza di trasmissione (ERP, potenza irradiata effettiva) e, in alternativa, tecniche di accesso allo spettro e di mitigazione delle interferenze oppure un duty cycle di al massimo il 10 per cento. L'ordinanza riporta queste prescrizioni nella colonna "condizioni d'uso".
Il duty cycle è la quota di tempo in cui un singolo dispositivo trasmette effettivamente, misurata su un'ora continua. Il 10 per cento di un'ora sono 360 secondi di tempo di trasmissione. Con i nostri parametri radio e circa un secondo per pacchetto sono circa 360 pacchetti all'ora per dispositivo.
Cosa significa in pratica:
- Conta la somma sull'ora, non la velocità. Chi trasmette per poco tempo molto in fretta e poi fa una lunga pausa può restare nel limite.
- Il limite vale per ogni dispositivo trasmittente singolarmente, anche per i Repeater. Anche i pacchetti inoltrati contano come tempo di trasmissione.
- Il limite regola il tempo di trasmissione, non il contenuto. Lo spam può rientrare nel limite ed essere comunque fastidioso.
- Solo chi supera il 10 per cento viola le condizioni d'uso della banda. Al di sotto è sgradito, ma non è una violazione delle regole.
Ora il calcolo. Calcoliamo con i pacchetti che i nostri Observer hanno sentito e con 1,0 fino a 1,17 secondi di tempo di trasmissione per pacchetto. Il limite è il 10 per cento all'ora, cioè 360 secondi. Come mittente assumiamo un solo dispositivo. Sospettiamo che dietro ce ne fosse davvero uno solo, ma non possiamo dimostrarlo.
- Ondata 1: nell'ora di picco 243 pacchetti, circa 243 secondi di tempo di trasmissione, cioè circa il 6,8 per cento.
- Ondata 2: nell'ora di picco 200 pacchetti, circa 200 secondi, cioè circa il 5,6 per cento.
- Gli Advert della terza notte: 356 pacchetti in 27 minuti, circa da 404 a 416 secondi, cioè circa l'11 per cento dell'ora, nei dieci minuti peggiori addirittura circa il 37 per cento di tempo di trasmissione.
Questa è una stima, non una misura: mancano i pacchetti che nessun Observer ha sentito, quindi il vero tempo di trasmissione può essere più alto. Se a trasmettere erano più dispositivi, ciascuno stava sotto. Le due piene di messaggi sono quindi rimaste sotto il 10 per cento. Gli Advert erano sopra, se li ha trasmessi un solo dispositivo.
La mia conclusione: la rete di Repeater deve costruirsi da sola la propria resistenza. Un'autorità difficilmente aiuterà, a meno che non diventi una questione di uso delle frequenze.
Chi legge, e chi accusa
Diversi gestori avevano la sensazione che il mittente leggesse nel gruppo Telegram. Nessuno può dimostrarlo, e in un gruppo aperto non si può comunque escludere nessuno.
Qui per me è importante un punto: le accuse, dirette o indirette, non hanno posto né nel mesh né nel gruppo. Ognuno può darsi qualsiasi nome di dispositivo. Un nome non dice nulla su chi c'è dietro.
Nel canale pubblico è successo lo stesso durante la seconda ondata. Lì si è speculato su chi ci fosse dietro i messaggi, e un gruppo di radioamatori della Carinzia è stato accusato in blocco, a partire da un dispositivo dietro il quale, a giudicare dal nome, potrebbe esserci un radioamatore. Chi ci sia davvero dietro e se c'entri qualcosa con la piena, nessuno può dirlo.
Più tardi nel gruppo sono arrivate di nuovo delle insinuazioni, anche qui senza prove. La mia impressione è che vengano dalla stessa voce.
Ritengo possibile che proprio questo sia l'obiettivo. Una piena che mette i gestori l'uno contro l'altro fa più danni di una che costa soltanto tempo di trasmissione.
E nel caso di emergenza?
La domanda che dopo la piena è stata posta più forte nel gruppo è la più scomoda. Un gestore ha fatto notare che MeshCore è più una rete per la popolazione che per le forze di intervento. Se la rete di telefonia mobile cade, il timore è che il numero di messaggi salga di colpo e che la rete sia sotto carico, senza alcuna cattiva intenzione.
Dal 13 al 15 novembre in Carinzia si svolge l'esercitazione di protezione civile Combined Success, che il Land Carinzia e l'esercito federale organizzano dal 2009. Per quanto ne so, stavolta simula un terremoto, e i radioamatori trasmettono le segnalazioni su 2 m e 70 cm. MeshCore finora non è previsto. Ho chiesto agli interessati e ho suggerito di prenderlo in considerazione in futuro.
Per me ne consegue questo: dovremmo esercitarci nella rete su come si trasmette in caso di emergenza, con canali definiti e accordi chiari. Una proposta dal gruppo: togliere dai Repeater gli Scope ampi (*, Europa, Austria) e lavorare solo a livello locale. Io lo applicherei appena qualcosa torna a muoversi. Attuarlo in modo coordinato su tutti i Repeater è il vero lavoro, ed è proprio questo che dovremmo esercitare, invece di impararlo nell'emergenza.
Il test e cosa ha mostrato
Vedo questi tre giorni come un test, ed è andato bene. Piena, nodi falsi e percorsi falsificati la rete li ha sopportati senza problemi, il resto del traffico è proseguito. Almeno altrettanto importante della tecnica è stato ciò che è successo tra di noi che gestiamo i nodi MeshCore: ci siamo coordinati in fretta, senza che qualcuno dovesse decidere. Alla fine di questi giorni uno di noi ha scritto che si sta uniti e si collabora. C'è poco da aggiungere. Da noi partecipa chiunque abbia un dispositivo, in associazione o a titolo privato, e questa è la vera difesa. La sola tecnica qui avrebbe aiutato poco.
Il test ha anche mostrato su cosa dovremmo lavorare: una difesa minima uniforme su tutti i Repeater, una procedura collaudata per l'emergenza e più Observer che condividono i dati.
E nel bel mezzo dell'agitazione, giovedì a mezzogiorno è arrivata dal gruppo una domanda dal tono completamente diverso: cosa si pensa di un Repeater presso Feldkirchen, con vista diretta sul Magdalensberg e verso Ossiach? Ho risposto: buona idea, e ho chiesto se per questo c'è già un sito o solo l'idea, e di che hardware ci sarebbe bisogno.
La rete continua a crescere.
Cosa se ne può trarre
Come procedere in caso di attacco, in sei passi
- Documentare la situazione con dei conteggi, senza i contenuti dei messaggi.
- Informare i gestori e per ora non cambiare nulla.
- Difesa minima uniforme su tutti i Repeater.
- Spegnere il punto di ingresso per un tempo limitato (
set repeat off), se necessario. - Circoscrivere la fonte, parlarne invece di additare.
- Poi documentare.
Cosa funziona, cosa no
- Un canale privato protegge il contenuto, ma non dalla piena.
- Uno Scope ordina, ma non protegge, perché il codice si può calcolare dal nome della regione.
- Percorsi e intensità di ricezione sono per la localizzazione solo un indizio, non una traccia, soprattutto con intestazioni falsificate.
- Funzionano solo le misure che limitano quantità e portata dei Flood. Nell'emergenza è lo spegnimento temporaneo dell'inoltro al punto di ingresso, con il prezzo che lì tutti gli altri restano fuori.
Appello
- Non leggere altri nomi come motivo di sospetto, e non accusare nessuno senza prove.
- La rete non appartiene a nessuno da solo. Vive degli accordi della community, per esempio nel dare i nomi ai dispositivi. Chi partecipa li rispetta e non presenta la rete come propria.
- Configurare i Repeater in modo uniforme e tenere visibile la versione del firmware.
- Gestire propri Observer e condividere i dati: chi registra i pacchetti può poi dimostrare cosa è successo.
- Chi rispetta potenza di trasmissione e duty cycle agisce entro le regole, e comunque una rete può soffrire. Per questo servono degli accordi.
73, Michi OE8YML
Nota di trasparenza
Ho scritto e controllato questo articolo con il supporto di un'IA (Claude, Anthropic), sulla base delle mie analisi e delle osservazioni del gruppo dei gestori. Tutti i numeri sono calcolati dai pacchetti della mappa pubblica (map.carinthiamesh.com), non misurati via radio, i tempi di trasmissione sono stime con le ipotesi indicate. L'articolo non contiene contenuti di messaggi, chiavi né posizioni di privati. Chi si nasconda dietro i messaggi e i nodi falsi è sconosciuto. Le due immagini di apertura sono generate con IA e servono solo a scopo illustrativo. Correzioni e integrazioni sono benvenute a [email protected].
