Attacco SSH MITM in corso

4

AGGIORNAMENTO: La fonte di questo problema si è fortunatamente rivelata essere un client SSH buggato utilizzato su 2 diversi dispositivi, non un attacco MITM. Tuttavia, apprezzerei ancora una risposta completa alla domanda originale: vale a dire, nel caso di un attacco MITM originale , quali passi deve seguire un amministratore dopo averlo rilevato ? La presenza di un vero aggressore MITM rende effettivamente impossibile l'accesso SSH a quel server per tutto il tempo in cui tenta di intercettare il traffico? La porta sshd è sufficiente per rispondere?

QUESTIONE ORIGINALE: Gradirei qualche consiglio su quali misure dovrei prendere per affrontare questo.

Durante il tentativo di connettersi al server di casa oggi tramite SSH utilizzando l'autorizzazione della chiave pubblica (l'accesso con password è disabilitato), ho ricevuto il messaggio "Impronta digitale cambiata". Poiché ho una copia dell'impronta digitale della chiave pubblica del server su di me, posso vedere che non corrispondono.

Questo significa che non riesco a connettermi al server su SSH a tempo indefinito senza mettere a repentaglio la sicurezza? Posso combattere l'attacco in alcun modo? Mentre sono sempre stato consapevole del potenziale degli attacchi SSH MITM, e c'è un sacco di letture disponibili su rilevare un simile attacco, non riesco a trovare alcun consiglio su contrastare / trattare con esso una volta in corso.

Grazie in anticipo.

UPDATE: la chiave pubblica dell'host SSH e la copia che ho sono identiche. Ma quando ci si collega da remoto (usando DDNS o IP diretto), il messaggio "Autentica dell'host non può essere stabilito" mostra un'impronta digitale diversa da quella del server. Ho bisogno di consigli su come mi connetto al server tramite SSH d'ora in poi alla luce di qualcuno potenzialmente facendo qualcosa di nefasto. Devo semplicemente cambiare la porta del server SSH? Devo generare nuove chiavi?

    
posta py4on 17.05.2014 - 13:29
fonte

1 risposta

2

Se disponi di un accesso fisico al server, accedi alla sua console e verifica se la chiave pubblica del server è effettivamente cambiata. Se è cambiato, prova a capire perché; in caso contrario, significa che quando si tenta di connettersi al server con SSH si sta effettivamente parlando con un'altra macchina, probabilmente a causa di un tentativo di attacco in corso, ma più probabilmente a causa di alcuni errori di routing o di configurazione DNS.

Per i server ospitati, il provider dovrebbe offrire alcuni sistemi KVM o di salvataggio basati su IP che sarebbero equivalenti all'accesso fisico (in quel contesto).

    
risposta data 17.05.2014 - 15:04
fonte

Leggi altre domande sui tag