Esistono modi fattibili per bloccare l'utilità stunnel a livello di rete?

Poiché si esclude l'intercettazione SSL (ad esempio non è possibile installare certificati) e si esclude anche qualsiasi tipo di analisi del modello di traffico, non rimane molto. Quello che potrebbe essere provato è analizzare l'handshake TLS stesso:

• Gli stack TLS e anche le applicazioni che utilizzano TLS spesso lasciano un'impronta utilizzabile in ClientHello, ovvero quale versione del protocollo, quali codici sono offerti in quale ordine, quali estensioni sono utilizzate e quale ordine ecc. Niente di nuovo e molte informazioni possono essere trovate su questo . Ovviamente, un cliente potrebbe in teoria replicare perfettamente un altro Client Clientello per nascondersi.
• Analisi passive simili potrebbero essere fatte per il lato server. Ma la varietà di configurazioni del server che si riflettono nello stack TLS è molto più grande che sul lato client, quindi probabilmente non è così efficace come analizzare ClientHello.

Per chiarire: questa è solo euristica. Può causare falsi positivi e non riesce a rilevare le istanze di stunnel. Ciò è particolarmente vero in reti complesse con una varietà di client diversi e solo poche volte per analizzare manualmente se una specifica impronta digitale comune dovrebbe essere consentita in generale, a un target specifico o dovrebbe essere bloccata.

Nessuna intercettazione, nessun modo.

Questo è un problema da risolvere con criterio , non tecnologia . Non puoi fermare gli utenti con tecnologia, infrastruttura o configurazione. L'unico modo sicuro è criterio . Se usi una regola complessa su webshells, stunnel e accesso remoto, e applicali davvero, i tuoi utenti saranno meno inclini a fare buchi sul muro.

Ma se vuoi il percorso più frustrante, ci sono alcune cattive notizie: non puoi farlo senza intercettazione. Indipendentemente dal tipo di ispezione passiva che utilizzi, gli utenti lo eviteranno.

Connessione al sito per vedere se c'è un sito Web non funzionerà. Utilizzando sslh è possibile utilizzare la stessa porta per HTTPS, SSH, OpenVPN, XMPP e HTTP semplice, tutti al stessa ora.

Un'altra opzione è cavatappi . Trasformerà in modo trasparente SSH sul proxy HTTPS. Se non intercetti la connessione e la controlli, il tuo firewall non rileverà nulla.

Anche se analizzi e blocchi altri protocolli, un utente pieno di risorse può utilizzare AjaxTerm o Shell in a Box , esfiltrando i dati anche se provi a bloccare SSH.

Potresti avere un software che stabilisce la propria connessione a ciascun host, porta e SNI, e forse altri parametri come la versione TLS e le cipherità se pensi che qualcuno possa intrufolarsi in quelle e vedere se risponde a un richiesta come un normale server HTTPS. Se non risponde con il formato HTTP tramite la connessione SSL / TLS, si può presumere che sia SSH stunnelato o qualcos'altro di dubbia come il torrente e la lista nera. Forse con scadenza dopo un periodo definito, nel caso si tratti di un IP dinamico e viene riassegnato.

Tuttavia, invece di SSH (TCP) -over-SSL / TLS (stunnel) qualcuno potrebbe usare un software che fa SSH (TCP) -over-HTTPS i.e. SSH (TCP) -over-HTTP-over-SSL / TLS. Ciò sarà essenzialmente impossibile da rilevare semplicemente provando una richiesta HTTPS arbitraria, poiché il tunnel HTTP potrebbe utilizzare qualsiasi tipo di autenticazione o di offuscamento che non si conosce a causa di SSL / TLS. In quel caso probabilmente la tua unica opzione è quella di investigare manualmente i server desiderati e autorizzare quelli che giudichi sicuri (e stabili); a meno che tu non lo limiti abbastanza rigorosamente - forse wikipedia, linkedin, alcune banche e ristoranti locali e Stack (ovviamente) - probabilmente avrai bisogno di diversi dipendenti a tempo pieno per ogni dipendente che vuoi monitorare - e poi tu Avremo bisogno di un modo per monitorare i monitor.

In alternativa, un'approssimazione a buon mercato è solo l'RST di qualsiasi connessione che dura più di 30 secondi (modifica) tra le trasmissioni di dati. Anche se i client HTTPS (in particolare i browser) tenderanno a mantenere aperte le connessioni inattive per risparmiare il costo della riconnessione, il protocollo HTTP (e quindi anche HTTPS) viene definito e (quasi universalmente) implementato per funzionare correttamente se deve rifare il connessione di trasporto frequentemente (modifica) per qualsiasi o qualsiasi richiesta. Al contrario la maggior parte delle cose fatte su SSH dipendono dal mantenere la stessa connessione - ma non tutte, quindi un cheater sufficientemente determinato potrebbe aggirare anche questo.