Domanda:
Quali alternative ci sono quando SSH viene attivamente filtrato?
Moein7tl
2012-01-03 03:18:18 UTC
view on stackexchange narkive permalink

Sfortunatamente il nostro governo filtra il protocollo SSH, quindi ora non possiamo connetterci al nostro server Linux.

Fanno il filtraggio controllando l'intestazione di ogni pacchetto nel livello di rete (e non semplicemente chiudendo porta). Inoltre eliminano i protocolli VPN.

Esiste un modo alternativo per connettersi in modo sicuro a un server Linux?

Questo potrebbe benissimo essere un primo caso d'uso per Hackerspace Global Grid ...
Se stai pensando di votare per chiudere questa domanda per motivi di "troppo localizzazione", considera che ** molte ** di aziende bloccano anche ssh al perimetro, quindi le risposte interesseranno molte più persone rispetto a quelle che hanno per comunicare oltre questo confine. Anche se le domande sulla sovvertimento delle impostazioni del firewall locale potrebbero essere considerate poco sagge, per quanto ne so non sono chiudibili solo per questo motivo.
Penso che vogliamo evitare la politica, ma abbiamo bisogno di discutere le questioni tecniche anche quando riconosciamo che possono essere utilizzate per violare la politica di qualcuno. Il punto è che le politiche di sicurezza tecnicamente valide possono essere in conflitto. Vedi http://meta.security.stackexchange.com/questions/664/conflicting-policies-and-discussing-technical-issues-involving-privacy-vs-contr
Anche http://mosh.mit.edu/ potrebbe valere la pena provare
La mia scuola blocca SSH, ma porto avanti per usare la porta 53 o simile.
Undici risposte:
petrus
2012-01-03 03:38:01 UTC
view on stackexchange narkive permalink

Da quello che ho sentito prima oggi, https / ssl scorre correttamente attraverso i tuoi confini.

Dovresti quindi controllare Corkscrew.

Analogamente a netcat , viene utilizzato per racchiudere ssh in https per consentire l'uso di proxy https.

Un'altra soluzione sarebbe usare LSH che, avendo una firma diversa da ssh, lavora dall'Iran come ha notato Siavash nel suo messaggio.

In realtà, dovresti essere in grado di cambiare la porta ssh a 443 e poi connetterti attraverso di essa. A meno che non stiano eseguendo un attacco man-in-the-middle, non dovrebbero essere in grado di distinguere tra ssh e https. Questo ha funzionato su tutti i firewall su cui l'ho provato. Ho aggiunto una risposta per questo, fammi sapere se funziona.
@user606723: L'ISP (e il governo) ** è ** l'uomo al centro. Questo non è un attacco, ma una sorveglianza. E sì, sono in grado di distinguere tra ssh e https utilizzando DPI.
spiegare come si può fare utilizzando solo DPI e non alcun tipo di intervento? O forse dovrei creare una domanda? Per riferimento, "attacco man-in-the-middle" si riferisce a qualcosa di specifico. http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Forse la stretta di mano è diversa tra ssl e ssh?
@user606723: ssh è un protocollo. ssl è un meccanismo di crittografia, utilizzato ad esempio con FTP e http. Questo non ha niente in comune.
Suppongo tu abbia ragione. per la cronaca, anche ssl è un protocollo.
Un handshake SSL / TLS non è crittografato. Puoi facilmente vedere la versione del protocollo, le cyphersuite supportate (dal client), la cifratura scelta, l'host virtuale (ammesso che l'estensione sia utilizzata e la maggior parte dei browser lo faccia), i certificati presentati. È possibile utilizzare queste informazioni per provare a eseguire il fingerprint del software server / client. In breve TLS non tenta di nascondersi, cerca solo di proteggere i dati dell'applicazione dopo che l'handshake è stato completato. Non so molto del livello di crittografia SSH, ma la sua stretta di mano sembra sicuramente diversa da TLS. Non hai bisogno di un MitM attivo, basta guardare passivamente i pacchetti
Una connessione SSH inizia con il server che invia "SSH" in chiaro, quindi è banale da individuare per chiunque guardi la connessione. Il cavatappi in realtà lo oscura, o imposta semplicemente la connessione tramite proxy e lascia visibile "SSH"?
@Kevin Se controlli la sorgente, invia una richiesta proxy HTTP e una richiesta con codifica base64, quindi non penso che faccia nulla per nascondere effettivamente l'identificatore di testo normale del protocollo, solo un cambiamento nella tecnologia utilizzata per accedervi.
nealmcb
2012-01-04 00:57:07 UTC
view on stackexchange narkive permalink

Sulla base di un discorso alla conferenza CCC - 28C3: Come i governi hanno cercato di bloccare Tor - il Progetto Tor ha i migliori risultati in questo campo dinamico e stimolante e può essere utilizzato per SSH. L'uso innovativo dei ponti Tor è uno degli ultimi sviluppi. Il 28C3 Tor talk è anche su YouTube e le diapositive sono su https://svn.torproject.org/svn/projects/presentations/slides-28c3.pdf

Si noti che l'utilizzo di metodi evasivi che possono essere identificati troppo facilmente può esporre l'utente a ulteriori violazioni dei propri diritti umani e della sicurezza personale. Fai attenzione.

Aggiornamento : l'articolo 19 della Dichiarazione universale dei diritti umani è pertinente qui:

  • Articolo 19: Ogni individuo ha diritto alla libertà di opinione e di espressione; questo diritto include la libertà di avere opinioni senza interferenze e di cercare, ricevere e diffondere informazioni e idee attraverso qualsiasi mezzo e indipendentemente dalle frontiere.
"Si noti che l'utilizzo di metodi evasivi che possono essere identificati troppo facilmente può esporre l'utente a ulteriori violazioni dei propri diritti umani" "- Non che sia d'accordo con il tipo di filtro che fanno l'Iran e altri, ma difficilmente penso che l'uso di SSH dovrebbe essere considerato un diritto umano.
@MDMarra Non credo che Neal stia cercando di dire che SSH è di per sé un diritto umano. È ciò che il tunneling SSH * consente * (libertà di parola e accesso alle informazioni) per coloro che si trovano in tali paesi con restrizioni, ovvero.
Penso che il problema qui sia che il PO vuole fare qualcosa di perfettamente innocuo, anche dal punto di vista di un governo restrittivo, ma i mezzi per farlo in modo sicuro sono fuorilegge o `` sospetti '', quindi usarli può portare a tutti i tipi di problemi con il autorità.
@MDMarra - In un mondo in cui l'accesso alla rete sta diventando sempre più importante, il [diritto all'accesso a Internet] (http://en.wikipedia.org/wiki/Human_rights#Information_and_communication_technologies) è sempre più dibattuto.
Vint Cerf, padre di Internet e sosia di Matrix Architect [sembra non essere d'accordo] (http://news.dice.com/2012/01/05/cerf-internet-access)
@MDMarra Grazie per il collegamento. Penso che Cerf abbia ragione. Per la situazione qui, prenderò nota dell'articolo 19 della [Dichiarazione universale dei diritti umani] (http://un.org/en/documents/udhr) che è più quello che stavo cercando di ottenere e con cui Mi aspetto che Cerf sia d'accordo: "Tutti hanno diritto alla libertà di opinione e di espressione; questo diritto include la libertà di avere opinioni senza interferenze e di cercare, ricevere e diffondere informazioni e idee attraverso qualsiasi media e indipendentemente dalle frontiere".
@nealmcb Abbastanza giusto, il mio punto più grande (che è troppo grande per un commento, in realtà) è che non penso che dovrebbe spettare a noi decidere cosa è e cosa non è giusto per una nazione sovrana straniera per controllare all'interno del proprio frontiere. Anche se sono assolutamente in disaccordo con il filtraggio in Iran e in altre nazioni soppresse in modo simile, non penso che sia compito mio fornire soluzioni alternative per la politica governativa. Certo, probabilmente è in bianco e nero per la maggior parte per questo problema specifico, ma è un pendio scivoloso. Se apri la porta per un round di sovversione governativa, dove viene tracciata la linea per altri casi
@MDMarra In effetti, non è facile. Molti problemi sono eccessivamente limitati, poiché obiettivi e politiche diversi e ragionevoli sono in conflitto. Per ulteriori discussioni, vedere http://meta.security.stackexchange.com/q/664/453
pfo
2012-01-03 05:01:51 UTC
view on stackexchange narkive permalink

Se hai https non filtrato puoi fare qualcosa come AjaxTerm o qualsiasi altro emulatore di terminale basato su AJAX o HTML5 in esecuzione su un sito protetto all'interno di un server web che può connettersi a un demone ssh locale o in determinati casi a quelli remoti su altre interfacce della tua macchina.

Un'altra opzione (difficile un po 'oscura) se hai ICMP sulla tua macchina sarebbe quella di eseguire TCP / IP su ICMP se è aperto. Vedi qui.

nessun tunnel con AjaxTerm immagino?
strtok
2012-01-07 04:28:43 UTC
view on stackexchange narkive permalink

Prova a inviare l'handshake SSH su più di un pacchetto. Molta tecnologia di filtraggio dei pacchetti opera a livello di pacchetto e non bufferizza per l'ispezione.

Se questo non funziona, prova a farlo ma mandando le due o più parti dell'handshake fuori ordine. Solo se la scatola DPI viene riassemblata, potrebbe catturare la stretta di mano.

come posso farlo in pratica? abbassare la MTU?
@JanusTroelsen: Modifica il tuo client e server ssh per inviare S, S, H in chiamate di scrittura separate con sleep 1 tra di loro.
ashwoods
2012-01-03 09:24:49 UTC
view on stackexchange narkive permalink

Sono disponibili diverse opzioni per il tunneling dell'IP su altri protocolli. Oltre a usare qualcosa come un cavatappi, potresti provare a implementare IP / DNS (cioè con iodine) o IP / ICMP.

In altri casi potresti anche usa qualcosa come http://www.serfish.com/console/

Juicy Scripter
2012-01-03 17:07:44 UTC
view on stackexchange narkive permalink

Puoi anche considerare di eseguire il tunneling del traffico SSH su DNS utilizzando strumenti come OzymanDNS o iodine

MDMarra
2012-01-03 03:21:08 UTC
view on stackexchange narkive permalink

Potresti usare qualcosa come VNC, ma senza un tunnel sicuro come VPN o SSH, non è molto sicuro. Se filtrano anche questo, avrai difficoltà.

L'ho provato anch'io, è stato filtrato anche io: | goditi la tua libertà uomo perché non sei nato all'inferno: |
TimB
2012-01-03 09:47:07 UTC
view on stackexchange narkive permalink

Un'altra opzione, ma che richiederà che tu abbia prima accesso al tuo server in qualche altro modo in modo da poter installare il demone, è telnet-ssl / telnetd-ssl.

A differenza di alcune altre opzioni che sono state suggerite, questo non richiederà molto overhead di rete ed è molto semplice da usare (una volta che il demone è in esecuzione).

È improbabile che la porta 992 sia completamente aperta se la porta 22 è chiusa.
ma 443 potrebbe essere aperto. E sono abbastanza sicuro che sia impossibile capire la differenza tra https e telnet-ssl.
In linea di principio non dovrebbe essere possibile riconoscere quale tipo di applicazione è in esecuzione su SSL / TLS. Ma la stretta di mano offre molte possibilità di rilevamento delle impronte digitali. Quindi, a meno che non venga prestata particolare attenzione, è probabilmente spesso possibile almeno dire quale libreria SSL client viene utilizzata. La presenza dell'estensione del nome host virtuale e l'elenco delle suite crittografiche supportate sarebbero le prime cose che guarderei quando provo a differenziare https e telnet-ssl. Il sondaggio attivo, come fa la Cina, è un'altra possibilità e relativamente difficile da proteggere.
ttt
2012-01-03 19:49:37 UTC
view on stackexchange narkive permalink

Se sai che la tua connessione Internet corrente è stata filtrata, utilizza un metodo di connessione Internet diverso come un provider di servizi Internet via satellite. Esistono diversi fornitori di servizi Internet via satellite: list1, list2.

(la domanda originale dell'autore non prevedeva alcuna restrizione per ottenere forma di connettività.)

Sembra fantastico essere arrestato come "spia occidentale".
user606723
2012-01-04 23:02:37 UTC
view on stackexchange narkive permalink

Dovresti essere in grado di cambiare la porta ssh in 443 e poi connetterti attraverso di essa. A meno che non stiano eseguendo un attacco man-in-the-middle, non dovrebbero essere in grado di distinguere tra ssh e https.

Questo ha funzionato su tutti i firewall su cui l'ho provato. (certamente non così tanti)

Sarei interessato a sapere se funziona. Grazie.

L'utilizzo della porta 443 per SSH funziona sulla maggior parte dei firewall. +1 per questo. Ma richiede uno strumento aggiuntivo per il comando SSH connect. Vedi qui per i dettagli: http://daniel.haxx.se/docs/sshproxy.html
-1
Il DPI passivo è probabilmente sufficiente per rilevare la differenza tra SSL e SSH. SSL / TLS ha un handshake facilmente visibile.
@CodeInChaos: forse è visibile, ma nessuno guarda.
L'OP ha detto che non è solo filtrato in base alla porta. E ci sono certamente paesi che hanno provato a filtrare TOR in base a DPI, quindi non è improbabile che l'Iran filtri SSH con DPI.
Ali
2015-04-05 16:55:26 UTC
view on stackexchange narkive permalink

Ho lo stesso problema. Al giorno d'oggi la connessione SSH iniziale viene stabilita ma dopo una certa trasmissione di pacchetti viene interrotta. Credo che abbiano iniziato a rilasciare pacchetti SSH dopo che è stato raggiunto un limite. Sono passato a MOSH https://mosh.mit.edu/. Si autentica utilizzando SSH e quindi passa a UDP. È più veloce di SSH e facile da installare e utilizzare.

Per usarlo, installalo sul tuo server, apri la porta udp 60000: 61000 nel firewall e connettiti al server con un client mosh come fai con un client ssh (non è necessario avviare nulla). 

  sudo yum install moshsudo iptables -I INPUT 1 -p udp --dport 60000: 61000 -j ACCEPT

Un buon client Windows è MobaXTerm http://mobaxterm.mobatek.net/download-home-edition.html



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...