Passa al contenuto principale
Peplink

Peplink 8.6.0 sicurezza: FIPS, RadSec, WireGuard e cosa è cambiato

Peplink 8.6.0 sicurezza: FIPS, RadSec, WireGuard e cosa è cambiato

Introduzione

La sicurezza nell'infrastruttura di rete non è uno stato, ma un processo continuo. Peplink Firmware 8.6.0, rilasciata il 29 luglio 2026, traccia una linea chiara: invece di miglioramenti puntuali isolati, questo rilascio consegna un pacchetto di sicurezza coerente che spazia dagli standard crittografici ai protocolli di autenticazione, fino alle correzioni concrete di vulnerabilità. Al centro sta la keyword Peplink FIPS RadSec — la combinazione di funzionamento FIPS 140-3 permanente e RadSec (RADIUS over TLS), che per le organizzazioni con requisiti di compliance normativa rappresenta un progresso misurabile.

Per i CISO e i team di IT security la 8.6.0 significa che ostacoli operativi pluriennali vengono meno: il funzionamento FIPS ora si attiva in modo permanente nell'interfaccia utente locale. RadSec protegge il traffico di autenticazione RADIUS lungo il percorso attraverso reti pubbliche. WireGuard completa le opzioni VPN con un protocollo moderno e verificabile, dal footprint di codebase snello. E tre vulnerabilità chiuse — tra cui un accesso non autenticato alla Web Admin — eliminano superfici d'attacco che nei penetration test sarebbero emerse ripetutamente.

Questo articolo esamina ogni modifica dal punto di vista dei responsabili della sicurezza: cosa cambia tecnicamente, quali obblighi di configurazione nascono con l'aggiornamento e quali rischi vengono mitigati. Tutte le indicazioni si basano sulle note di rilascio ufficiali Peplink e sono state validate dagli ingegneri certificati Peplink di Ascend.

1. FIPS 140-3 permanente — nessun Care Plan necessario

Cosa cambia

Secondo la pagina ufficiale Peplink della Firmware 8.6.0, con la 8.6.0 FIPS diventa una funzione permanente, integrata nell'interfaccia utente locale, per i dispositivi idonei: FIPS 140-3 si attiva in modo permanente nella UI locale — senza Care Plan attivo. Nota: Peplink University e altre fonti secondarie parlano ancora di FIPS 140-2; fa fede l'indicazione del produttore.

Dettagli tecnici

  • L'attivazione FIPS avviene direttamente nella Web UI locale, nelle impostazioni di sicurezza. InControl 2 rispecchia lo stato, ma l'interruttore vero e proprio sta sul dispositivo.
  • Quali dispositivi siano idonei lo elenca Peplink per serie nelle note di rilascio ufficiali; l'elenco va verificato concretamente prima dell'aggiornamento.
  • Con FIPS attivo valgono requisiti inaspriti per le configurazioni IPsec: le pre-shared key (PSK) devono essere lunghe almeno 14 caratteri. Secondo le note di rilascio, i profili IPsec esistenti con PSK più corte possono dopo l'aggiornamento non stabilire più la connessione, finché le chiavi non sono aggiornate.
  • Novità inoltre SHA2-384 come algoritmo di hash per la Fase 2 IPsec, che porta l'integrità delle negoziazioni dei tunnel a un livello superiore.

Raccomandazioni operative prima dell'aggiornamento

  1. Eseguire un audit delle PSK: prima dell'aggiornamento alla 8.6.0 verificare tutte le pre-shared key IPsec. Più corte di 14 caratteri? Sostituirle prima dell'aggiornamento, altrimenti il tunnel si interrompe.
  2. Verificare il contratto di servizio: la funzione FIPS in sé non è vincolata a un Care Plan attivo; a quale diritto di aggiornamenti software ha diritto il vostro dispositivo dipende dal vostro contratto di servizio Peplink.
  3. Documentare lo stato FIPS: dopo l'aggiornamento attivare la modalità FIPS nella UI locale e documentare lo stato a fini di audit.
Nota per i dispositivi PrimeCare: InControl deve rimanere attivo per ricevere gli aggiornamenti delle funzioni software. FIPS funziona in modo permanente senza Care Plan, ma la distribuzione delle funzioni avviene tramite InControl.

2. RadSec — RADIUS over TLS per l'autenticazione WLAN

Perché RadSec è rilevante

RADIUS è il protocollo standard per l'autenticazione negli ambienti WLAN — dall'802.1X enterprise con WPA2/WPA3 ai portali guest. Nella sua forma classica RADIUS trasmette i dati di autenticazione non cifrati. Finché server RADIUS e access point si trovano nello stesso segmento di rete protetto, è accettabile. Non appena però il traffico di autenticazione attraversa reti pubbliche — ad esempio con filiali distribuite, servizi Cloud-RADIUS o connessioni MPLS tra più provider — nasce una superficie d'attacco reale: credenziali, token challenge-response e session key sono intercettabili.

RadSec risolve questo problema incapsulando l'intero traffico RADIUS in un tunnel TLS. Autenticazione, autorizzazione e accounting (AAA) transitano su un canale cifrato, autenticato reciprocamente anche tramite certificati. Peplink 8.6.0 porta il supporto nativo RadSec su una ampia gamma di modelli.

Modelli supportati

RadSec è disponibile su: Balance 20X, 310 Fiber 5G, 310 5G HW3, tutti i modelli Dome e MBX, tutti i modelli UBR, la maggior parte della serie BR, nonché tutti i modelli Transit, Orbit e B One. La matrice precisa dei modelli è nelle note di rilascio.

Passaggi di configurazione

  1. Preparare il server RADIUS per RadSec: il server RADIUS di destinazione deve supportare RadSec (RFC 6614) — FreeRADIUS, Microsoft NPS con gateway RadSec o provider Cloud-RADIUS come CloudPath.
  2. Depositare i certificati nel Certificate Manager Peplink: vanno importati sia il certificato client del router Peplink sia il certificato CA del server RADIUS.
  3. Configurare RadSec come profilo di autenticazione: lì si può selezionare RadSec come protocollo di autenticazione; come porta è tipicamente preimpostata la 2083 (il RADIUS classico usa la 1812).
  4. Passare gli AP WLAN al nuovo profilo: nell'AP Controller assegnare il profilo di autenticazione al profilo SSID corrispondente.

Esempio pratico: rete di filiali con Cloud-RADIUS

Un'azienda gestisce 40 filiali, ognuna con un Peplink Balance e più AP Wi-Fi. L'autenticazione RADIUS gira in modo centralizzato su un servizio Cloud-RADIUS. Finora il traffico RADIUS tra filiali e cloud era non protetto o richiedeva un VPN a monte. Con RadSec nella 8.6.0 basta un tunnel TLS — configurato nel Certificate Manager Peplink — e l'autenticazione è cifrata end-to-end. Questo riduce la complessità ed elimina una superficie d'attacco che nei deployment distribuiti spesso resta irrisolta.

3. VPN WireGuard — remote access moderno

Cosa distingue WireGuard da OpenVPN e IPsec

WireGuard è disponibile con la Firmware 8.6.0 su tutti i modelli Peplink come VPN di remote user access. Si affianca alle opzioni esistenti (OpenVPN, L2TP, PPTP) — non in sostituzione, ma come alternativa moderna con vantaggi specifici:

  • Dimensione della codebase: WireGuard circa 4.000 righe, stack OpenVPN nell'ordine di 100.000 righe e più — meno codice, minore superficie d'attacco.
  • Stabilimento della connessione: WireGuard si attiva in una frazione del tempo necessario ai protocolli classici.
  • Handover al cambio di rete: WireGuard resta attivo in modo trasparente; con OpenVPN la sessione in genere si interrompe.
  • Crittografia: WireGuard con ChaCha20 + Poly1305 cablati; IPsec configurabile (con FIPS tra l'altro SHA2-384).
  • Verificabilità: elevata grazie alla codebase ridotta; gli stack complessi sono più onerosi da auditare.

Perché è importante per i CISO

  • Superficie d'attacco minima: la codebase di WireGuard è circa 25 volte più piccola di quella di OpenVPN. Significa meno vulnerabilità potenziali, audit di sicurezza più rapidi e processi di certificazione più semplici.
  • Mobilità: WireGuard mantiene le sessioni al cambio di interfaccia di rete (es. WLAN → LTE). Per i dipendenti remoti sul campo o in trasferta significa niente tunnel VPN che si interrompono al cambio di rete — un vantaggio operativo che riduce anche il tasso di ticket all'helpdesk.
  • Crittografia standard robusta: WireGuard usa fisso ChaCha20 per la simmetria e Poly1305 per il MAC — nessuna cipher suite configurabile e potenzialmente debole.

Scenari d'impiego con Peplink

WireGuard nella 8.6.0 è concepito in primis per il Remote User Access — cioè l'accesso di singoli client (laptop, smartphone, app Peplink SFC) al router Peplink. Per le connessioni site-to-site tra dispositivi Peplink resta SpeedFusion la scelta raccomandata, poiché offre in più WAN bonding e failover. SFC Direct Access (anch'esso novità della 8.6.0) completa WireGuard per i casi in cui serve una connessione diretta Peplink-to-Peplink senza un classico tunnel VPN.

Nota di configurazione

WireGuard si configura nella Web UI Peplink; per ogni client viene generato o importato un paio di chiavi pubblica/privata. La gestione dei peer segue il noto modello WireGuard — nessun overhead di certificati X.509 come con OpenVPN, ma in cambio una gestione esplicita delle chiavi come disciplina.

4. Modernizzazione dei certificati — cosa non è più supportato

Le modifiche in sintesi

La Firmware 8.6.0 opera una risistemazione consequenziale dei formati di certificato accettati. I seguenti tipi non sono più accettati:

  • Tipo di certificato: DSA (Digital Signature Algorithm) · Stato prima della 8.6.0: accettato · Stato dalla 8.6.0: non più accettato
  • Tipo di certificato: chiavi RSA corte · Stato prima della 8.6.0: accettato · Stato dalla 8.6.0: non più accettato
  • Tipo di certificato: container PKCS#12 legacy · Stato prima della 8.6.0: accettato · Stato dalla 8.6.0: non più accettato
  • Tipo di certificato: RSA ≥2048 bit, ECDSA, Ed25519 · Stato prima della 8.6.0: accettato · Stato dalla 8.6.0: accettato (standard)

I certificati non più accettati vengono sostituiti da un certificato predefinito sicuro, che funge automaticamente da fallback. L'esercizio non si interrompe — la cifratura prosegue, ma con il certificato predefinito invece che con un certificato legacy scaduto o insicuro.

Perché è importante

  • DSA è considerato obsoleto. Il NIST raccomanda la migrazione a ECDSA o RSA ≥2048 (NIST SP 800-131A); anche il BSI privilegia nelle sue prescrizioni i metodi moderni. Peplink segue questa direzione con la modernizzazione dei certificati.
  • Le chiavi RSA corte sono considerate insicure (NIST SP 800-131A richiede almeno 2048 bit per le firme digitali). Nei penetration test e negli audit di compliance vengono classificate come finding. Quali lunghezze di chiave RSA rifiuti concretamente Peplink nella 8.6.0 non è quantificato nelle note di rilascio — verificate i vostri certificati nel Certificate Manager.
  • I container PKCS#12 legacy possono contenere formati di cifratura datati che non rispondono più agli standard attuali.

Obbligo in vista dell'aggiornamento: verificare il Certificate Manager

Prima dell'aggiornamento alla 8.6.0:

  1. Nel Certificate Manager Peplink elencare tutti i certificati importati.
  2. Verificare ogni certificato per DSA o chiavi RSA insolitamente corte.
  3. Sostituire i certificati interessati con nuovi certificati RSA-2048+ o ECDSA.

Dopo l'aggiornamento alla 8.6.0:

  1. Verificare di nuovo il Certificate Manager — i certificati interessati saranno stati sostituiti dal certificato predefinito.
  2. Se per finalità di gestione o VPN era in uso un certificato autofirmato, sostituire i certificati sostitutivi predefiniti con propri certificati da 2048+ bit.
  3. Per le connessioni TLS interessate (Synergy Mode, RadSec, Web Admin) informare i client del cambio di certificato, per evitare problemi di pinning del trust store.
Synergy Mode: la 8.6.0 porta un certificato di fallback dedicato per le connessioni TLS Synergy. Anche qui vale: verificare il parco certificati prima dell'aggiornamento.

5. Patch CVE e fix di sicurezza

CVE-2026-42945 — componente del web service

Questa vulnerabilità riguardava una componente del web service Peplink. Peplink ha consegnato la patch direttamente nella 8.6.0. I dettagli sul vettore esatto sono stati comunicati da Peplink con riserve — prassi tipica dei produttori di appliance di rete per mantenere piccola la finestra di sfruttabilità. Cosa devono sapere i CISO: la patch esiste solo dalla 8.6.0 — un aggiornamento tempestivo è caldamente raccomandato.

CLI Command Injection — chiusa

Una vulnerabilità di command injection nella CLI è stata chiusa. Le vulnerabilità di command injection consentono agli attaccanti di eseguire comandi arbitrari con i privilegi del processo CLI — in genere di livello amministrativo. La superficie d'attacco presuppone un accesso CLI autenticato, ma il rischio resta critico: sono possibili privilege escalation verticale e controllo completo del dispositivo. La patch chiude l'elaborazione degli input iniettabili.

Web Admin — accesso non autenticato chiuso

La più grave delle tre vulnerabilità chiuse: era possibile un accesso non autenticato all'interfaccia Web Admin. Significa che un attaccante senza credenziali poteva raggiungere funzioni o informazioni di rilevanza amministrativa. I dettagli sull'effettiva portata non sono stati pienamente divulgati, ma la sola categoria — accesso admin non autenticato — giustifica la classificazione come critica e rende l'aggiornamento una priorità.

Default degli AP Wi-Fi su WPA2/WPA3 Personal

Una modifica sottovalutata dal grande effetto: i nuovi AP Wi-Fi dalla 8.6.0 in poi vengono configurati per impostazione predefinita con WPA2/WPA3 Personal — non più con il datato WPA, tantomeno in modalità open. È particolarmente rilevante perché le configurazioni predefinite nella pratica spesso restano intatte per giorni o per sempre. Con WPA3 come opzione predefinita il rischio di attacchi alla cifratura WLAN datata diminuisce nettamente.

Riepilogo dei fix di sicurezza

  • Vulnerabilità: componente del web service · Categoria: vulnerabilità di servizio · CVE: CVE-2026-42945 · Corretta in: 8.6.0
  • Vulnerabilità: CLI Command Injection · Categoria: command injection autenticata · CVE: — · Corretta in: 8.6.0
  • Vulnerabilità: accesso non autenticato alla Web Admin · Categoria: accesso admin non autenticato · CVE: — · Corretta in: 8.6.0
  • Vulnerabilità: default degli AP Wi-Fi · Categoria: configurazione predefinita debole · CVE: — · Corretta in: 8.6.0

Conclusioni

Sotto il profilo della sicurezza, Peplink Firmware 8.6.0 è un rilascio centrale. La combinazione di Peplink FIPS RadSec — FIPS 140-3 permanente senza vincolo al Care Plan e RadSec per RADIUS over TLS —, WireGuard come standard VPN moderno, una consequenziale modernizzazione dei certificati e la chiusura di tre vulnerabilità critiche dà un pacchetto di sicurezza coerente che non tralascia alcun aspetto del livello appliance di rete.

Per i CISO e i team di IT security dei settori regolamentati — pubbliche amministrazioni, sanità, finanza, infrastrutture critiche — questo aggiornamento non è un "nice to have", ma un obbligo di compliance e gestione del rischio. Da sole le tre vulnerabilità chiuse giustificano un aggiornamento tempestivo; FIPS, RadSec e WireGuard sono il valore aggiunto ulteriore.

Raccomandazione operativa: verificate i vostri dispositivi Peplink sulla prontezza all'aggiornamento (lunghezza PSK, certificati, aggiornamento a stadi per determinati modelli), pianificate una finestra di manutenzione ed eseguite l'aggiornamento. Ascend come Peplink Gold Partner vi supporta nella pianificazione, nell'audit di PSK e certificati e nel rollout.

Prossimo passo: contattate Ascend per un colloquio di consulenza sull'aggiornamento — verifichiamo la vostra flotta Peplink sulla prontezza per la 8.6.0, identifichiamo certificati e pre-shared key interessati e pianifichiamo il rollout insieme a voi.

Domande frequenti

Richiedi una consulenza sull'aggiornamento

Verifichiamo la vostra flotta Peplink sulla prontezza per la 8.6.0: lunghezza delle PSK, parco certificati, percorsi di aggiornamento a stadi — e pianifichiamo il rollout insieme a voi.

Prodotti Peplink adatti

Hardware adatto direttamente dallo shop Ascend — disponibilità e prezzi le trovate nella pagina di dettaglio del prodotto.

Approfondimenti

Questo articolo è stato redatto e verificato con il supporto dell'IA e controllato prima della pubblicazione dagli ingegneri certificati Peplink di Ascend.

Pronto per il tuo prossimo progetto?

Parla con il nostro team delle tue esigenze.

Di norma rispondiamo entro un giorno lavorativo · non condividiamo mai i tuoi dati

Articoli correlati