Un ripetitore radioamatoriale moderno può essere molto più di un apparato RF.
All’interno della stessa postazione possiamo trovare:
- router;
- modem LTE/5G;
- Starlink;
- Raspberry Pi;
- MMDVM;
- server Linux;
- controller di alimentazione;
- telecamere IP;
- sensori;
- sistemi SNMP;
- dashboard web;
- VPN;
- interfacce SSH;
- gateway verso reti digitali.
Dal punto di vista operativo è fantastico.
Dal punto di vista della sicurezza significa però una cosa molto semplice:
abbiamo trasformato una postazione radio in una piccola rete informatica remota.
E quella rete deve essere protetta esattamente come qualunque altra infrastruttura connessa a Internet.
CISA raccomanda, per le infrastrutture di comunicazione, segmentazione di rete, firewall stateful, VLAN, gestione dei dispositivi esclusivamente da reti fidate, logging centralizzato, aggiornamenti tempestivi, eliminazione delle password predefinite e autenticazione forte per gli accessi amministrativi.
Vediamo come tradurre questi principi nel mondo radioamatoriale.
Il primo errore: “tanto chi vuoi che attacchi un ripetitore?”
È probabilmente la frase più pericolosa.
Un dispositivo esposto su Internet non deve necessariamente essere preso di mira personalmente.
Molte attività malevole sono automatizzate.
Un servizio aperto può essere individuato semplicemente perché:
IP pubblico
+
porta aperta
+
servizio riconoscibile
CISA sottolinea proprio come configurazioni errate, credenziali predefinite e software obsoleto possano lasciare apparati raggiungibili e individuabili da strumenti di scansione Internet.
Quindi l’attaccante non deve sapere:
“Questo è il ripetitore di una rete radioamatoriale italiana.”
Gli basta sapere:
“Su questo IP esiste un servizio che posso provare ad attaccare.”
Prima regola: non esporre ciò che non serve
Supponiamo di avere:
22 SSH
80 Web
443 HTTPS
8291 management router
1883 MQTT
3000 Grafana
9100 exporter
Aprire tutte queste porte direttamente su Internet è generalmente una pessima strategia.
La domanda deve essere:
quale servizio deve davvero essere raggiungibile dall’intera Internet?
Spesso la risposta è:
nessuno.
Per l’amministrazione remota è molto meglio usare una VPN.
MikroTik raccomanda esplicitamente di non rimuovere le regole firewall che bloccano l’accesso WAN salvo necessità e, qualora sia necessario amministrare il router da remoto, suggerisce l’utilizzo di una VPN come WireGuard.
L’architettura dovrebbe quindi essere:
SYSOP
│
▼
INTERNET
│
▼
VPN
│
▼
FIREWALL
│
▼
RETE MANAGEMENT
non:
INTERNET
├── SSH
├── Grafana
├── router
├── Raspberry
├── webcam
└── controller
Ridurre la superficie d’attacco
La attack surface è, in termini pratici, l’insieme dei servizi e dei punti attraverso cui qualcuno può tentare di entrare.
Più servizi abilitiamo:
SSH
FTP
Telnet
HTTP
SNMP
UPnP
API
WinBox
MQTT
più aumentano le cose da:
- aggiornare;
- configurare;
- monitorare;
- proteggere.
La regola migliore è quindi:
se non serve, spegnilo.
MikroTik, nelle proprie indicazioni di hardening, raccomanda di disabilitare in produzione servizi non necessari come MAC-Telnet, MAC-WinBox, MAC-Ping, neighbor discovery, bandwidth server e, se non utilizzati, proxy, SOCKS e UPnP.
Il principio è valido indipendentemente dal produttore.
Il firewall deve essere “default deny”
Una filosofia particolarmente efficace è:
TUTTO BLOCCATO
e successivamente:
APRI SOLO QUELLO CHE SERVE
non il contrario.
Per esempio:
VPN → router management ACCEPT
VPN → Raspberry SSH ACCEPT
Monitoring → SNMP ACCEPT
Repeater → master server ACCEPT
LAN → NTP ACCEPT
TUTTO IL RESTO DROP
Un firewall stateful mantiene informazioni sulle connessioni già stabilite e può distinguere traffico nuovo, esistente e correlato. RouterOS utilizza connection tracking e supporta sia filtraggio stateful sia stateless.
Separare RADIO e MANAGEMENT
Uno degli errori più comuni consiste nel mettere tutto nella stessa rete:
192.168.1.0/24
dove troviamo contemporaneamente:
router
ripetitore
Raspberry
telecamera
Wi-Fi
PC
server
Funziona.
Ma significa che, una volta compromesso un dispositivo, diventa più semplice tentare di raggiungere gli altri.
Meglio creare VLAN.
Per esempio:
VLAN 10 MANAGEMENT
VLAN 20 RADIO
VLAN 30 SERVER
VLAN 40 TELECAMERE
VLAN 50 MONITORING
VLAN 60 GUEST
CISA raccomanda esplicitamente segmentazione attraverso ACL, firewall, DMZ e VLAN per isolare gruppi di dispositivi e limitare il movimento laterale.
Esempio pratico
Immaginiamo:
VLAN 10 MANAGEMENT
192.168.10.0/24
VLAN 20 RADIO
192.168.20.0/24
VLAN 30 MONITORING
192.168.30.0/24
Il ripetitore:
192.168.20.10
non ha bisogno di collegarsi liberamente a:
192.168.10.1 router management
Potremmo consentire solamente:
RADIO → Internet
RADIO → master server
MANAGEMENT → RADIO
e bloccare:
RADIO → MANAGEMENT
In questo modo un apparato compromesso nella VLAN RADIO non ottiene automaticamente accesso ai dispositivi amministrativi.
La rete management dovrebbe essere speciale
La VLAN di management dovrebbe contenere soltanto ciò che serve ad amministrare:
- router;
- switch;
- Proxmox;
- Raspberry;
- PDU;
- UPS;
- controller.
L’accesso dovrebbe arrivare soltanto da:
VPN
o da un PC amministrativo fisicamente presente.
CISA raccomanda di non amministrare apparati direttamente da Internet, ma da dispositivi fidati presenti in zone di management dedicate.
VPN prima di tutto
La soluzione più interessante per molte postazioni radioamatoriali è:
WireGuard
Il modello ideale:
POSTAZIONE REMOTA
│
▼
crea tunnel
│
▼
VPN HUB / VPS
▲
│
SYSOP
La postazione può così trovarsi anche dietro NAT o CGNAT.
Il Sysop entra nella VPN e soltanto allora raggiunge:
SSH
router
dashboard
monitoring
MikroTik indica WireGuard come soluzione raccomandata quando serve accesso remoto al dispositivo.
Non basta avere una VPN: serve il firewall anche dentro
Errore:
VPN CONNECTED
↓
ACCESSO A TUTTO
Meglio:
SYSOP1
├→ Router
├→ Raspberry
└→ Proxmox
MONITORING SERVER
├→ SNMP
└→ exporters
ALTRO PEER
└→ solo servizio X
Ogni peer dovrebbe poter raggiungere soltanto le risorse necessarie.
La VPN cifra il traffico.
Il firewall decide chi può andare dove.
Password uniche
Mai utilizzare:
admin / admin
oppure:
iz1xxx / iz1xxx
e soprattutto mai utilizzare la stessa password per:
router
Raspberry
Grafana
NAS
telecamera
Se una credenziale viene scoperta, l’attaccante proverà spesso la stessa combinazione sugli altri servizi.
MikroTik raccomanda password non ripetute e complesse e suggerisce anche di sostituire/disabilitare l’utente amministrativo predefinito.
CISA raccomanda inoltre di eliminare le password predefinite e usare MFA per gli accessi amministrativi quando disponibile.
SSH: meglio le chiavi
Per un server Linux remoto, preferirei:
SSH KEY
alla semplice autenticazione tramite password.
Schema:
PC SYSOP
private key
│
▼
SSH
│
▼
SERVER
public key autorizzata
Possiamo quindi, dopo aver verificato il corretto accesso, disabilitare l’autenticazione SSH tramite password quando compatibile con le esigenze operative.
Inoltre:
root login diretto
non dovrebbe essere la configurazione predefinita per l’amministrazione ordinaria.
Account personali, non un unico “admin”
Se tre Sysop amministrano la rete:
sysop1
sysop2
sysop3
è meglio di:
admin
con password condivisa.
Perché?
Perché possiamo:
- revocare un singolo account;
- sapere chi ha fatto cosa;
- applicare privilegi differenti;
- mantenere una traccia nei log.
CISA raccomanda RBAC, least privilege e revisione periodica degli account.
Principio del minimo privilegio
Supponiamo che uno script abbia bisogno soltanto di:
leggere temperatura
non deve avere:
root
Un exporter Prometheus che legge metriche non dovrebbe poter:
riavviare il ripetitore
se non strettamente necessario.
La regola:
ogni servizio riceve solo i privilegi necessari.
Aggiornare, ma con criterio
Un dispositivo remoto dimenticato per anni è un rischio.
MikroTik raccomanda esplicitamente di mantenere RouterOS aggiornato perché release precedenti possono contenere vulnerabilità successivamente corrette.
CISA raccomanda un processo di patch management che includa monitoraggio delle comunicazioni dei vendor, applicazione tempestiva delle patch e test prima della distribuzione.
Per una rete radioamatoriale adotterei quindi:
1. backup
2. controllo changelog
3. aggiornamento laboratorio
4. test
5. aggiornamento produzione
anziché:
apt full-upgrade
alle 18:00 sul ripetitore principale.
Non aggiornare tutto automaticamente alla cieca
Una postazione remota deve essere stabile.
Quindi distinguerei:
PATCH DI SICUREZZA CRITICA
da:
nuova major release
Per un server non critico gli aggiornamenti automatici possono avere senso.
Per un router remoto o un sistema fondamentale è spesso meglio una procedura controllata.
Backup della configurazione
Bisogna poter ricostruire il sito.
Conserviamo almeno:
- configurazione router;
- configurazione firewall;
- WireGuard;
- file MMDVM;
- HBLink;
- script;
- dashboard;
- mapping VLAN;
- lista IP;
- configurazioni UPS/PDU.
Idealmente:
POSTAZIONE
│
▼
backup cifrato
│
▼
NAS / server centrale
Non soltanto sul Raspberry stesso.
Se l’SD card muore, un backup sulla stessa SD card non serve a nulla.
Attenzione alle chiavi private nei backup
Un file come:
wg0.conf
può contenere:
PrivateKey=
Quindi il backup di configurazione può essere altamente sensibile.
Proteggiamolo con:
- cifratura;
- permessi;
- accesso ristretto.
Mai pubblicare su forum un file di configurazione senza aver rimosso:
password
token
private key
API key
SNMP: se possibile, SNMPv3
SNMP è molto utile per monitoring.
Ma non dovrebbe essere esposto liberamente.
CISA raccomanda, quando SNMP viene utilizzato, SNMPv3 con autenticazione e cifratura, accompagnato da ACL per limitarne l’accesso.
Schema:
PROMETHEUS / NMS
│
▼
SNMPv3
│
▼
ROUTER / SWITCH
non:
INTERNET → SNMP
Logging: senza log siamo ciechi
Dovremmo sapere almeno:
chi si è collegato?
da quale IP?
quando?
quali servizi sono caduti?
chi ha modificato il firewall?
quando è stato riavviato il router?
Una postazione seria dovrebbe inviare i log verso un server remoto.
ROUTER
│
├→ log locale
│
└→ SYSLOG CENTRALE
Così, anche se il router si guasta o viene compromesso, parte dello storico rimane altrove.
CISA raccomanda logging centralizzato, copie off-site e monitoraggio degli accessi amministrativi.
Alert
I log diventano davvero utili quando possono generare avvisi.
Per esempio:
LOGIN FALLITO × 20
↓
ALERT
oppure:
NUOVO LOGIN ADMIN
↓
NOTIFICA
oppure:
CONFIGURATION CHANGED
↓
LOG
Non serve necessariamente un SOC enterprise.
Anche una piccola integrazione con:
- Grafana Alerting;
- email;
- Telegram;
- ntfy;
può essere sufficiente per una rete amatoriale.
Le telecamere meritano una VLAN separata
Le telecamere IP hanno spesso bisogno solo di:
VLAN CAMERA → NVR
Non devono poter raggiungere:
router
Raspberry
ripetitore
Configurazione ideale:
VLAN CAMERA
│
├→ NVR
└→ eventualmente Internet limitato
X
MANAGEMENT
È esattamente questo il motivo per cui la segmentazione è così potente.
I dispositivi IoT non sono dispositivi “fidati”
Controller economici, prese IP, relay e sensori possono essere utilissimi.
Ma non li considererei automaticamente sicuri.
Se un relay Wi-Fi deve soltanto ricevere comandi da:
192.168.30.10
il firewall dovrebbe consentire solo quel traffico.
UPnP: generalmente no in una postazione remota
UPnP può consentire ai dispositivi interni di chiedere automaticamente al router l’apertura di porte.
In una rete di gestione remota questo è spesso l’opposto di ciò che vogliamo.
MikroTik raccomanda di disabilitare UPnP nelle configurazioni di produzione quando non necessario.
Le aperture WAN dovrebbero essere:
deliberate, documentate e controllate.
Port forwarding: se proprio serve
Se una porta deve essere esposta:
Internet
│
▼
SERVIZIO
applicherei almeno:
IP sorgente limitato
firewall
TLS
autenticazione forte
log
rate limit
patch
Meglio ancora:
Internet
│
▼
reverse proxy / jump host
│
▼
servizio
CISA raccomanda di valutare continuamente quali servizi debbano davvero essere esposti e di rimuovere o restringere quelli non necessari.
Port knocking? Non è una soluzione principale
Può ridurre rumore da scansioni automatiche.
Ma non sostituisce:
- VPN;
- autenticazione;
- firewall;
- patch.
La sicurezza non deve dipendere dal fatto che qualcuno “non conosca la porta”.
Cambiare la porta SSH non rende SSH sicuro
Spostare:
22
su:
48222
può ridurre parte dei tentativi automatici più banali.
Ma un servizio esposto rimane un servizio esposto.
La protezione reale deriva da:
VPN
chiavi
firewall
aggiornamenti
MFA quando disponibile
Fail2ban
Su server Linux esposti, Fail2ban può essere un ulteriore livello utile per bloccare temporaneamente IP che producono numerosi tentativi falliti.
Ma anche qui:
meglio non esporre SSH se possiamo raggiungerlo tramite VPN.
La supply chain conta
Scaricare uno script con:
curl URL | bash
significa eseguire immediatamente codice remoto.
Meglio:
download
↓
leggi
↓
verifica
↓
esegui
Soprattutto quando parliamo di un server che amministra:
ripetitori
VPN
rete
Attenzione ai repository non mantenuti
Un software radioamatoriale può funzionare magnificamente da dieci anni.
Ma se dipende da:
Python obsoleto
librerie abbandonate
sistema operativo EOL
può diventare difficile da proteggere.
Separare i servizi in container o VM aiuta molto.
Possiamo mantenere:
legacy service
isolato dal resto della rete, riducendo il rischio.
Una possibile architettura sicura D2ALP
INTERNET
│
▼
ROUTER FIREWALL
│
┌──────┴──────┐
│ │
VPN WireGuard WAN
│
VLAN MANAGEMENT
│
┌─────────┼──────────┐
│ │ │
ROUTER PROXMOX SYSOP TOOLS
FIREWALL
│
┌───────────┼─────────────┐
│ │ │
VLAN RADIO VLAN SERVER VLAN MONITOR
│ │ │
RIPETITORE HBLink Grafana
MMDVM Reflector Prometheus
Telecamere:
VLAN CAMERA
separate da tutto il resto.
Checklist essenziale
Internet
□ Nessuna porta inutile esposta
□ Amministrazione tramite VPN
□ Firewall default deny
□ UPnP disattivato se inutile
Router
□ Firmware aggiornato
□ Password unica
□ Account default disabilitato/modificato
□ Servizi inutili spenti
□ Backup configurazione
Server Linux
□ SSH con chiavi
□ utenti separati
□ privilegi minimi
□ aggiornamenti
□ firewall locale
□ log
Rete
□ VLAN management
□ VLAN radio
□ VLAN telecamere
□ regole inter-VLAN
Monitoring
□ log remoto
□ alert accessi
□ alert servizi
□ controllo modifiche
Recovery
□ backup fuori dal sito
□ configurazioni documentate
□ chiavi conservate in sicurezza
□ procedura di reinstallazione
Conclusioni
La cybersecurity di una postazione radioamatoriale non richiede necessariamente infrastrutture costosissime.
Richiede soprattutto metodo.
L’errore più grave è trattare il ripetitore connesso a Internet come se fosse ancora soltanto una radio.
Non lo è più.
È:
RADIO
+
LINUX
+
ROUTER
+
INTERNET
+
SERVIZI
+
ACCESSO REMOTO
E quindi deve essere progettato secondo una filosofia moderna:
ridurre l’esposizione, segmentare, cifrare, aggiornare, monitorare e fare backup.
Il principio più importante può essere riassunto in una sola frase:
Internet non deve poter raggiungere direttamente ciò che Internet non ha alcun motivo di raggiungere.
Una VPN, un buon firewall e una rete segmentata fanno molto più per la sicurezza di cento porte “nascoste”.
E una rete D2ALP ben progettata dovrebbe essere affidabile non soltanto quando qualcuno preme il PTT, ma anche quando qualcuno dall’altra parte di Internet prova ad aprire una porta che non dovrebbe poter aprire.