C'è un modo per proteggere una macchina Linux in modo che nessun altro (ma io) possa accedere ai suoi contenuti? [chiuso]

-4

E voglio dire, anche se qualcuno prova a fare il tifo con un Live CD, anche se uno prende l'HDD e lo collega da qualche altra parte, ecc ...

Voglio essere in grado di dare a un client una macchina con un servizio in esecuzione, ma non voglio permetterlo di sbirciare dentro, affatto.

Modifica: Oh ok, giusto per chiarire, l'utente non utilizzerà direttamente il computer, il servizio è esposto attraverso una porta TCP ed è così che interagiscono con esso.

Scenario più ampio: fornisco un servizio tramite Internet, perché i dati dei miei utenti sono in qualche modo sensibili, molti di loro mi hanno chiesto di fornire loro un server che avrebbero potuto avere a livello locale e stare tranquilli perché i loro dati non lasciano l'edificio. Sono d'accordo, ma non voglio che controllino il mio codice sorgente e lo rubino / lo modifichino.

    
posta almosnow 11.03.2016 - 22:31
fonte

3 risposte

2

Se l'utente ha accesso fisico alla macchina, tutte le scommesse sono disattivate.

Il metodo più ovvio per tentare di proteggere la macchina sarebbe quello di crittografare il disco rigido. Il problema è che una macchina in esecuzione DEVE contenere la chiave di crittografia da qualche parte nella memoria, altrimenti il sistema operativo non può funzionare. Poiché la chiave di decodifica è in memoria, sei vulnerabile a un attacco di avvio a freddo

Inoltre, ci sono altre vulnerabilità che l'accesso fisico ti darebbe. BadUSB è un esempio.

    
risposta data 11.03.2016 - 23:03
fonte
1

Dipende molto da ciò che stai affrontando (il tuo scenario ).

Un utente "normale" può essere considerato affidabile con una macchina headless e un'installazione Linux chiusa, chiudendo semplicemente GRUB. Questo e un adeguato contratto / licenza sarebbero sufficienti. Puoi scollegare tastiera e mouse dalla scheda madre, sigillare l'unità e esportare solo il tuo servizio e SSH.

Il livello successivo è la crittografia del disco: un tipo più sofisticato ma ancora bagnato dietro le orecchie proverà a montare il disco da un'altra macchina, e potrebbe anche non sapere che esiste una cosa come una ext4 o una NTFS - possibilmente "Il disco deve essere formattato!" sarà sufficiente a spaventarlo, o proverà con un lettore extfs e non sarà in grado di accedere alla partizione crittografata.

Questo è più o meno dove vorresti fermarti. L'aggiunta aggiunge complessità e non può ancora raggiungere la sicurezza totale .

Il livello successivo è un utente abbastanza esperto da capire che se il disco è crittografato eppure si avvia , significa che la sequenza di avvio ha accesso alla chiave di decodifica. Ho sentito di driver sperimentali (che lavorano principalmente attraverso l'oscurità) che nascondono la chiave in posti strani, dalla memoria CMOS inutilizzata alle EEPROM esterne, ma come dice la vecchia battuta, abbiamo già stabilito come andrà a finire, ora discutiamo solo del prezzo - quanti sforzi saranno necessari da un determinato hacker con accesso completo all'hardware per irrompere. Perché se è determinato abbastanza, farà .

Esistono driver (e dispositivi hardware non rilevabili e metodi di virtualizzazione) che consentono di intercettare sia la porta parallela che il traffico USB. Controllando l'orologio hardware e l'I / O, diventa possibile un attacco di replay che consente l'avvio in un sistema manomesso, consentendo quindi l'accesso al disco decrittografato dal "fuori" di una VM o avviando servizi aggiuntivi che consentano lo stesso. Quindi è necessario aggiungere sofisticati meccanismi di autocontrollo per evitare questo.

A questo punto, controlla le risposte al nuovo problema e considera l'utilizzo di un PC appositamente progettato dove non è possibile rimuovere il disco rigido. Ricorda che "non posso" significa che tu e io non potremmo, ma Chuck Norris qualcuno (di nuovo: abbastanza determinato, abbastanza ricco, abbastanza informato, abbastanza spietato ) can.

Qualcosa che potresti provare (e ancora non fornisce una sicurezza completa) è quello di richiedere che la macchina sia sempre connessa a Internet. Sì, i dati sono al sicuro all'interno e non escono, ma quando si avvia , la macchina può accedere a un server esterno e ottenere la sua password di decrittografia da lì usando uno schema resistente agli attacchi di replay.

Ovviamente, se ti trovi contro un hacker determinato, un giorno la macchina che si connette al tuo server non sarà la macchina reale ma una parte di codice sovvertito che tenterà di rubare la chiave di decrittazione. Con un po 'di fortuna, tuttavia, questo non riuscirà al primo tentativo e nei registri di keyserver vedrai una sequenza di alcuni riavvii e richieste chiave mentre il ragazzo supera le difese.

Un'altra possibilità sarebbe quella di consentire all'utente di inserire una risposta a una sfida via SMS. Ciò garantirebbe al cliente che il server non può esporre nulla e che avresti ancora una sorta di impulso sulla situazione.

Modifica dell'architettura

Un'altra possibilità che mi viene in mente è che il PC dell'utente contiene i loro dati, ma non contiene il tuo servizio . Questo viene scaricato direttamente in memoria in modo sicuro da Internet ed eseguito ad ogni avvio. Avresti bisogno di un'applicazione "supervisore" che ne esaminasse l'ambiente e ne determinasse la sicurezza e la non-compatibilità, quindi le richieste tramite SSL e la presentazione di una chiave di licenza l'ultima versione dell'applicazione binaria dal tuo server. Il download binario e inizia a fare quello che deve fare sui dati nel PC di destinazione, senza mai essere salvato su disco. Il server può verificare l'indirizzo IP del chiamante se appartiene a una rete di clienti noti.

Ora l'attaccante deve ingannare l'applicazione supervisore (che ancora connettere e richiedere un binario anche se rileva un ambiente manomesso, lo farà semplicemente includendo un suggerimento sottile che agisce sotto costrizione - un " simbolo di buona fortuna hawaiana " se lo si desidera), e a meno che l'attaccante non sia il cliente stesso, anche ingannare il server e impadronirsi del computer. Ancora possibile, intendiamoci, ma molto più difficile.

    
risposta data 12.03.2016 - 15:10
fonte
-3

Sì, assolutamente. La risposta un po 'impraticabile è installare Linux su una macchina e poi tenerlo offline e con voi 24x7 in modo che nessun altro abbia accesso alla macchina.

Non proprio. Sembra come se volessi un livello di sicurezza poco pratico. Per un esempio, vedi Microsoft e tutti i loro vari tentativi di rilasciare software e tenerlo agli utenti nascosti. Ricorda che quando lavori con le persone devi scambiare alcune informazioni e devi fidarti delle persone con le informazioni scambiate con loro.

A tuo favore, conosci il codice, lo mantieni e rubare parte del codice richiederebbe probabilmente conoscenze specialistiche. Un altro punto a tuo favore, è che puoi organizzare per mantenere la macchina con il codice su di esso. C'è probabilmente un pericolo maggiore per gli hacker che rubano il tuo codice rispetto a quello che i tuoi partner commerciali potrebbero rubare.

Per una sicurezza ottimale, scegli una potente distribuzione Linux che scarichi rapidamente gli aggiornamenti di sicurezza, installa un SO pulito, aggiornalo regolarmente, installa il minor software possibile sulla scatola, blocca tutte le porte, configura un firewall strong e scrivere codice lato server molto stretto. Se sei veramente attento alla sicurezza, esegui questa macchina sulla propria sottorete con un firewall gateway indipendente e la tua scelta di server DNS.

    
risposta data 11.03.2016 - 22:45
fonte

Leggi altre domande sui tag