SSH a IP anziché a hostname completo: questo riduce il rischio MITM?

Question

SSH a IP anziché a hostname completo: questo riduce il rischio MITM?

#1 da (2 voti)

2

Sto applicando la gestione della configurazione a un VPS ospitato da una società di hosting VPS. Purtroppo la modifica della società di hosting non è un'opzione,

Questo VPS ha le seguenti proprietà:

quando è di nuovo imaged o reimaging, genera una nuova coppia di chiavi pubblica / privata SSH;
né l'interfaccia web dell'azienda di hosting VPS, né l'API della società di hosting VPS forniscono un modo per sostituire quella coppia di chiavi di una coppia di chiavi nota;
né l'interfaccia web dell'azienda di hosting VPS, né l'API della società di hosting VPS, forniscono un modo per ottenere l'impronta digitale della chiave pubblica della coppia di chiavi;
l'host VPS non ha record DNS firmati (ad esempio DNSSEC);
l'interfaccia web della società di hosting VPS e l'API do consentono di recuperare l'indirizzo IP del VPS;
l'interfaccia web della società di hosting VPS e l'API do utilizzano TLS e hanno un certificato valido da una CA decente;
l'interfaccia web dell'azienda di hosting VPS fa consente di caricare la chiave pubblica di un client SSH, dopo di che ogni volta che il VPS viene reimmaginato aggiungerà quella chiave pubblica al .ssh/authorized_keys dell'account specificato file.

Il primo punto sopra è normalmente una buona cosa, ma accoppiato con i prossimi due punti, significa che è impossibile per lo strumento di gestione della configurazione, quando tenta di accedere al VPS tramite SSH per la prima volta dopo il VPS è stato reimaging, per dire con certezza se la connessione è man-in-the-middled. In altre parole, lo strumento di gestione della configurazione può, nella migliore delle ipotesi, utilizzare il trust-on-first-use ("TOFU") approccio.

Normalmente, utilizzerei il nome host completo di VPS come identificativo del VPS nello strumento di gestione della configurazione, eviterei di dover utilizzare TOFU ottenendo separatamente l'impronta digitale della chiave pubblica SSH del VPS fuori banda (ad esempio tramite un'API sicura) . Con questo particolare VPS, però, quest'ultimo passaggio non è possibile.

Pertanto, la connessione tramite il nome host completo sembra rischiare un attacco MITM, ad es. tramite spoofing DNS , sfruttando il fatto che lo strumento di gestione della configurazione dovrebbe TOFU.

Mi sembra che l'opzione più sicura qui sarebbe quella di recuperare l'indirizzo IP del VPS dall'API su HTTPS, e avere invece lo strumento di gestione della configurazione SSH. Almeno questo eviterebbe il rischio di spoofing del DNS.

(Inoltre, approfittare del punto 7 sopra significa che anche se un server malevolo si maschera con successo come VPS, almeno il server malintenzionato non otterrà la password o la chiave privata del client.)

Sono corretto su questo? Ci sono altri rischi, o soluzioni migliori, che sto trascurando?

configuration ssh man-in-the-middle vps ssh-host-key

posta sampablokuper 26.01.2018 - 22:20

fonte

1 risposta

Leggi altre domande sui tag configuration ssh man-in-the-middle vps ssh-host-key

È un certificato WiFi (Radius) utilizzato anche dai browser Web (https)? Come può Google Chrome aggiornarsi in C: \ Programmi?

score 2 · Accepted Answer

Generalmente, l'utilizzo dell'API della società VPS è una buona idea, data la sua affidabilità e le risorse sufficienti per implementarlo e mantenerlo dalla tua parte. Dopo tutto, la funzionalità di gestione delle chiavi SSH può essere aggiunta a detta API prima o poi (forse anche sulla tua richiesta di funzionalità, chissà?).

Tuttavia, l'avvelenamento della cache DNS da solo è, per usare un eufemismo, un attacco raro e complesso. E nel tuo caso particolare c'è anche una finestra di attacco piuttosto breve (tra un VPS viene creato e assegnato un FQDN e il primo tentativo di accesso), che richiede un tempismo perfetto o una conoscenza interna (o entrambi) da parte di un attaccante. . Inoltre, nella maggior parte dei casi, i server virtuali vengono assegnati FQDN piuttosto casuali e oscuri, e un utente malintenzionato deve indovinare anche quello.

Successivamente, i server DNS della società VPS molto probabilmente recuperano il FQDN del VPS da un file di configurazione locale o da un database di qualche tipo. Supponendo che; se il tuo ISP e tutti gli ISP di transito tra il tuo resolver e la rete della compagnia VPS non stanno facendo attacchi malvagi MitM; se si è in grado di utilizzare direttamente i server DNS dell'azienda VPS per risolvere il FQDN di un VPS appena creato; quindi l'unico posto nella rete in cui potrebbe essere teoricamente applicato l'avvelenamento della cache DNS è il tuo risolutore. Pertanto, data la natura dell'attacco di avvelenamento del DNS al giorno d'oggi, sarebbe piuttosto facile per te rilevare e attenuare adeguatamente un tentativo di avvelenamento del DNS.

Inoltre, se il tuo modello di minaccia include attacchi di questo tipo, tieni presente che l'instradamento Internet non è più sicuro di DNS . Quindi potrebbe essere una buona idea impostare un VPS dedicato nella stessa posizione in cui verranno allocati tutti i server virtuali successivi, in modo che il primo utilizzo di un VPS appena creato provenga da una macchina nello stesso segmento di rete, eliminando una possibilità di dirottare l'indirizzo IP assegnato.

Lo

spoofing ARP potrebbe anche essere dannoso in gran parte allo stesso modo, anche se dipende in gran parte dalla rispettiva architettura di rete virtuale.

Nonostante tutto ciò, come ho sottolineato, quegli attacchi sono piuttosto ipotetici per un servizio medio con connessione a Internet. Il tuo chilometraggio può variare; tuttavia, farei meglio a concentrarmi su monitoraggio e rapporti adeguati per assicurarti che, nel caso in cui qualcosa di simile accadesse, lo saprai non appena possibile.