Un utente malintenzionato può "simulare" un indirizzo IP privato?

In breve no. Dato che SSH gira su TCP (sebbene esista una versione UDP, questo è inusuale) è necessario un handshake TCP per iniziare l'autenticazione del protocollo SSH e la sua comunicazione successiva. Un indirizzo privato non attraverserà il tuo router perimetrale da e verso l'Internet pubblico, quindi qualsiasi spoofing di un indirizzo interno quando entra (non assumendo anti-spoofing sul router o sul firewall che è una misura di sicurezza comune) comporterà la chiusura dell'SSH server che tenta di rispondere a quell'indirizzo interno e non tornerà mai più alla rete pubblica e al computer dell'aggressore. Nessuna connessione può essere stabilita.

Prima che l'attaccante possa inviare dati al server SSH, deve completare un handshake TCP. Ciò significa che l'attaccante deve indovinare un numero di sequenza a 32 bit. (Se vengono utilizzati i cookie SYN, le probabilità che l'autore dell'attacco possa migliorare .)

Supponendo che il tuo server stia generando buoni numeri di sequenza, questo ridurrà in modo significativo la capacità di attaccanti di attaccare il tuo server SSH usando un indirizzo IP client falsificato.

Ma forse non ti fidi del tuo server per generare buoni numeri di sequenza, o forse pensi che 32 bit di sicurezza non siano abbastanza buoni. Quindi potresti ancora voler sapere, cosa succederebbe una volta che l'aggressore ha indovinato un numero di sequenza corretto.

Prima di tutto notiamo che l'attaccante sarà in grado di capire se un numero di sequenza indovinato è corretto o meno. Un'ipotesi corretta causerà l'apertura di una connessione, quindi conterà verso il limite specificato utilizzando MaxStartups . L'utente malintenzionato può tentare di aprire un'altra connessione utilizzando un indirizzo non falsificato per scoprire se tale limite è stato raggiunto. Può mantenere il server sempre al di sotto di tale limite in ogni momento, in modo tale che una connessione riuscita con un indirizzo falsificato abbia sempre l'ultima connessione disponibile.

Senza il trucco di notare un numero di sequenza indovinato con successo, l'utente malintenzionato avrebbe dovuto inviare tentativi di password nei non vedenti senza sapere se esiste anche la connessione che erano stati inviati. Ciò potrebbe potenzialmente rallentare l'attaccante di un fattore di 2 ³.

Tuttavia, anche se un utente malintenzionato può ottenere un feedback per indicare se un numero di sequenza è stato indovinato correttamente, esistono altri blocchi stradali che impediscono di indovinare la password su una connessione TCP falsificata.

Durante lo scambio delle chiavi, sia client che server sceglieranno un valore casuale da inviare tramite la connessione. Questi valori casuali influenzano la chiave di sessione. Ciò significa che un utente malintenzionato che lavora in blind (perché non vede le risposte inviate dal server all'IP di spoofing) non conoscerà la chiave di sessione.

La mancanza di conoscenza della chiave di sessione significa che l'attaccante dovrà indovinare un codice di autenticazione del messaggio. Questo è essenzialmente equivalente all'esecuzione di un attacco MITM su una connessione legittima. Inoltre, l'utente malintenzionato deve inviare la password crittografata per essere decodificata dal server. Poiché l'utente malintenzionato non conosce la chiave di crittografia in uso, non saprà quali password ha provato.

La finestra temporale per il completamento dell'attacco da parte dell'utente malintenzionato dura solo fino a quando l'indirizzo IP di spoofing non ha risposto con un pacchetto RST TCP. Dal momento che il tempo di andata e ritorno tra l'attaccante e il server è probabile che sarà maggiore del tempo di andata e ritorno tra server e indirizzi locali, questo potrebbe impedire all'utente malintenzionato di utilizzare qualsiasi tipo di feedback, inclusa la verifica del numero di sequenza correttamente indovinato.

È possibile fornire all'avversario una finestra più lunga per completare l'attacco installando un firewall che impedisca a SYN ACK di raggiungere l'indirizzo IP falsificato o impedendo al server RST di raggiungere il server. Ciò tuttavia non rende l'attacco molto più fattibile.

La risposta è sì, è possibile. Tuttavia, ci sono alcune limitazioni significative. Attraverso l'uso dello spoofing IP, potrebbe essere possibile stabilire una connessione che potrebbe essere utilizzata per consegnare un carico utile alla destinazione, ma non sarà possibile stabilire una vera connessione TCP bidirezionale. In termini semplici, l'autore dell'attacco può far rispondere la macchina di destinazione, ma non riceverà le risposte poiché non verranno indirizzate a loro (questo è il motivo per cui lo spoofing IP è più comunemente utilizzato con connessioni UDP piuttosto che TCP). Tuttavia, l'utente malintenzionato può simulare la ricezione dei pacchetti e rimandare i pacchetti di riconoscimento falso e da lì arrivare al punto in cui possono potenzialmente fornire un carico utile. Questo payload potrebbe teoricamente essere utilizzato per impostare un trojan sul target che poi chiama il sistema C & C degli aggressori, stabilendo una connessione nel sistema interno.

Sebbene ciò sia possibile, è un trucco difficile e potrebbe non essere possibile su tutti i sistemi poiché ci sono stati cambiamenti nel modo in cui varie piattaforme gestiscono connessioni TCP che rendono più difficile per l'attaccante simulare i pacchetti ack. Considerate tutte le recenti rivelazioni sulla scarsa sicurezza dei router, l'attacco molto più probabile sarebbe quello di compromettere il router e configurare il port forwarding o utilizzare UPnP per ingannare il sistema nell'iniziare una connessione esterna, ecc.