Amministrare un Raspberry Pi su una LAN senza collegamento internet

Due dispositivi su una LAN privata possono scambiare traffico protetto senza alcun collegamento in uscita. Ciò che non possono fare è far comparire i servizi che il loro modello di sicurezza scelto si aspetta. Il lavoro è quindi metà selezione e metà inventario: scegli la protezione adatta al compito, poi elenca tutto ciò che cercherebbe silenziosamente internet.

Il presupposto di questo percorso è che entrambi i dispositivi abbiano indirizzi approvati sulla stessa rete privata. Non dedurre la raggiungibilità dal fatto che entrambi si siano collegati allo stesso wifi; il collegamento, l'instradamento e le regole di accesso lo decidono ancora.

Scegli la protezione in base al compito, non per abitudine

Una sessione terminale o un compito di amministrazione dei file supportato si adatta a SSH, la cui architettura separa l'autenticazione del server, l'autenticazione dell'utente e i canali trasportati dentro il trasporto protetto. Nessuno di questi ruoli richiede un fornitore VPN commerciale, e nessuno di essi smette di funzionare perché non esiste una rotta predefinita verso internet.

Un servizio TCP in più può viaggiare attraverso un inoltro SSH autorizzato quando il server lo consente: mantieni l'ascoltatore locale strettamente vincolato e la destinazione esplicita, e ricorda che questo inoltra quel singolo servizio invece di riprodurre un segmento Ethernet.

L'accesso instradato a più indirizzi o protocolli è un requisito diverso, e una VPN terminata localmente può fornirlo. Il peer in quel caso è un gateway locale raggiungibile, non un endpoint da qualche parte su internet, e il gateway ha comunque bisogno delle rotte previste, delle regole di inoltro e dei permessi di servizio. Dove una singola applicazione parla già correttamente TLS, lasciarle proteggere la propria connessione è spesso la risposta più piccola che funziona.

Inventaria ciò che lascerebbe la LAN

Metti in atto software, identità host e credenziali prima di dipendere da un banco isolato, oppure usa il processo di consegna offline supportato dall'organizzazione. Un comando di download non è un piano di installazione per una macchina che non può raggiungere l'origine, e scoprirlo durante un'interruzione è un pessimo momento per impararlo.

Rendi deliberata la denominazione. Usa il servizio DNS locale previsto o una disposizione di indirizzi documentata, perché un resolver pubblico configurato non crea un percorso verso sé stesso. Cambiare un indirizzo socket non è nemmeno una giustificazione per saltare i controlli di identità dell'applicazione. Se la risposta è che il banco usa semplicemente indirizzi, scrivilo, così il prossimo ingegnere non passa un'ora su un dominio di ricerca che non è mai stato configurato.

Poi leggi il modello di autenticazione e verifica per le dipendenze esterne: registrazione, un provider di identità, un'approvazione a più fattori, il recupero dello stato del certificato, una fonte di tempo. Ognuna è un potenziale blocco su una rete isolata. Elencale prima della finestra di manutenzione, non durante, perché una dipendenza scoperta al momento sbagliato trasforma un compito di cinque minuti in un pomeriggio. Predisponi una soluzione raggiungibile approvata o scegli un modello che funzioni offline, e non disattivare mai silenziosamente un controllo perché manca il suo servizio.

Tieni i controlli di identità dove appartengono

Verifica la chiave host o il certificato atteso tramite il processo di provisioning di cui ti fidi, e mantieni l'orologio corretto dove il protocollo convalida gli orari dei certificati. Condividere uno switch con un dispositivo non rende quel dispositivo quello che intendevi raggiungere, e supporre il contrario è esattamente l'errore che un attaccante sullo stesso segmento vorrebbe che tu facessi.

Il tempo merita una riga propria nel piano. Molti protocolli rifiutano credenziali altrimenti valide quando l'orologio è andato alla deriva abbastanza a lungo, e un Pi senza fonte di tempo di rete può andare alla deriva in silenzio per mesi prima che qualcosa si lamenti.

Prova con il collegamento in uscita realmente assente

Scollega il collegamento in uscita, poi esegui esattamente l'operazione di manutenzione per cui hai progettato: la sessione terminale, la copia del file, il servizio inoltrato, la connessione instradata. Conferma che un'identità negata o una risorsa vietata siano ancora negate, perché un progetto che dimostra solo il percorso felice non è stato affatto testato. Leggi i log mentre lo fai, perché i guasti interessanti sono quelli che lasciano una traccia senza cambiare l'esito.

Registra l'endpoint locale, il meccanismo di protezione e ogni dipendenza usata dall'operazione. L'uscita verso internet e un percorso sicuro per l'amministrazione locale sono due requisiti diversi, e tenerli separati è ciò che permette al secondo di sopravvivere alla perdita del primo.