SSH plausibilmente sdegnato - ha senso?

Question

SSH plausibilmente sdegnato - ha senso?

#1 da (10 voti)
#2 da (1 voti)

4

Il mio collega mi ha appena detto che non può effettuare connessioni SSH in uscita nelle sue reti aziendali, quindi gli ho consigliato di configurare un server su 443 e ha funzionato. Ho quindi iniziato a pensare che l'amministratore potesse rilevare che si tratta in realtà di una connessione SSH che utilizza l'ispezione deep packet e / o la connessione al server, ma penso di aver trovato un modo per renderlo più difficile che non implichi l'offuscamento del protocollo (che non indosso Mi piace, perché potrebbe rompere il mastice).

Mentre è ovvio che se non si modifica il protocollo, la connessione rimarrà nei log, ma ho pensato che l'amministratore potrebbe sentirsi confuso se potessi dimostrargli che in realtà esiste un sito Web HTTPS sulla porta e il server in realtà non parla SSH. Per fare il trucco, ho pensato a un proxy che avvolge la porta e fa sempre le richieste SSL, ma lascia in SSH solo dopo un tentativo di accesso sicuro su HTTPS. Dal momento che non conosco ancora i protocolli né di SSL né di SSH, puoi pensare a una ragione per cui questo non potrebbe funzionare? In caso contrario, pensi che potrebbe effettivamente essere convincente / utile?

ssh tls

posta d33tah 02.10.2013 - 13:19

fonte

2 risposte

Leggi altre domande sui tag ssh tls

openssl - generazione della coppia di chiavi rsa - chiave pubblica Cosa c'è di più sicuro: ISDN, modem via cavo, DSL, T1, ecc ...?

score 10 · Answer 1

Tecnicamente , i primi byte di una connessione SSL e il primo byte di una connessione SSH, differiscono. Fondamentalmente, con SSL, il client parla per primo, e il primo byte ha valore 22 (0x16) per il record che contiene il suo ClientHello (vedi lo standard ). Con SSH, client e server parlano simultaneamente, ma il server può attendere che il client parli per primo e inviano i loro "banner" che iniziano con "SSH" (vedi standard ), quindi il primo byte del client sarà 83 (0x53, per una "S" ASCII).

Quindi, potresti scrivere del software server che ascolta sulla porta 443, guarda il primo byte e, a seconda del byte, reindirizza a un server SSH o SSL locale. I due protocolli possono essere multiplexati sulla stessa porta in quel modo (l'ho usato per SSL vs RDP). Tuttavia, naturalmente, ci sarà ancora il traffico SSH sul socket quando si esegue SSH, quindi le cose sull'ispezione dei pacchetti continueranno a vedere "Pattern simili a SSH".

Lo stesso vale per la tua idea. Anche se si esegue prima una finestra di dialogo basata su SSL completa, nel momento in cui si passa a SSH sullo stesso socket, gli ispettori di pacchetto potrebbero rilevarti. Se vuoi davvero eluderli, devi fare la cosa SSL completamente : iniziare con SSL, quindi eseguire SSH all'interno del tunnel SSL. Fondamentalmente, esegui una VPN basata su SSL. Dall'esterno, sarà sempre SSL da sempre; all'interno, pacchetti IP arbitrari, che possono trasmettere alcuni SSH o qualsiasi altra cosa, in realtà.

(Si noti che la crittografia SSL non nasconde il pacchetto dimensione e il traffico SSH include molti piccoli pacchetti che implicano un modello di traffico distinto dal "normale Web". Un amministratore di sistema ficcanaso può ancora scoprire il tuo tentativo di eludere le politiche locali. Il crimine non è un mestiere facile!)

score 1 · Answer 2

Una soluzione semplice consiste nell'impostare un proxy HTTP (su HTTPS, tecnicamente), quindi configurare il client SSH per connettersi tramite quel proxy. Putty supporta questo in modo esplicito nell'interfaccia, mentre altri client possono richiedere ulteriore lavoro.

Dietro le quinte, il tuo cliente farà una richiesta HTTPS al tuo server proxy (che potrebbe anche essere il tuo server SSH) ed emetterà un comando CONNECT invece di un GET o POST. Per quanto riguarda il proxy dell'organizzazione, HTTPS è completamente opaco, ma anche non inaspettato.

La differenza principale tra il traffico proxy HTTPS e il traffico GET / POST standard rispetto a HTTPS è che il traffico proxy è in genere più bidirezionale in modo interattivo. Cioè, si inviano alcuni byte, io invio alcuni byte e avanti e indietro. In genere, il traffico HTTP coinvolge ogni sito a turno, inviando l'intera richiesta o l'intera risposta. Ma all'interno dell'incapsulamento proxy, SSH non è facilmente distinguibile da nessun altro protocollo interattivo senza un campione statisticamente significativo e un'attenta analisi temporale.

Inoltre, è possibile eseguire un proxy HTTPS su un server web normale , condividendo l'indirizzo, la porta e il certificato SSL con il sito live esistente, il che significa che l'unica "pistola fumante" in modo da parla è il volume del traffico e modelli di temporizzazione.