Perché bloccare la porta 22 in uscita?

Sono un programmatore e ho lavorato per alcuni client le cui reti bloccano le connessioni in uscita sulla porta 22. Considerando che i programmatori spesso devono utilizzare la porta 22 per ssh, questa sembra una procedura controproducente. Nella migliore delle ipotesi, costringe i programmatori a fatturare alla compagnia Internet 3G. Nel peggiore dei casi, significa che non possono svolgere efficacemente il proprio lavoro.

Date le difficoltà che ciò crea, un amministratore di sistema esperto potrebbe spiegare il beneficio desiderato a quella che sembra un'azione perdente?

Non vedo che nessuno abbia spiegato dettagliatamente il rischio specifico con il port forwarding SSH.

Se ti trovi all'interno di un firewall e disponi dell'accesso SSH in uscita a un computer su Internet pubblico, puoi SSH su quel sistema pubblico e nel frattempo creare un tunnel in modo che le persone su Internet pubblico possano accedere a un sistema all'interno della tua rete, completamente aggirando il firewall.

Se fred è il tuo desktop e barney è un server importante nella tua azienda e wilma è pubblico, in esecuzione (su fred):

ssh -R *: 9000: barney: 22 wilma

e l'accesso consentirà a un attaccante di accedere alla porta 9000 su Wilma e parlare con il demone SSH di Barney.

Il firewall non lo vede mai come una connessione in entrata perché i dati vengono passati attraverso una connessione originariamente stabilita nella direzione in uscita.

È fastidioso, ma una politica di sicurezza della rete completamente legittima.

Se stanno bloccando un miscuglio di porte, lasciando passare alcune cose e bloccando altre cose a caso (adoro la triste storia di Paul Tomblin delle persone che bloccano SSH e hanno permesso a Telnet) allora hanno entrambi un caso molto strano per come andare in giro a proteggere il loro perimetro di rete, o le loro politiche di sicurezza sono, almeno dall'esterno, apparentemente mal pensate. Non puoi dare un senso a situazioni del genere, quindi carica loro il tasso corrente per le persone che sono dolorose e proseguono la giornata.

Se stanno bloccando TUTTE le porte a meno che non vi sia un caso aziendale specifico per consentire il traffico attraverso quella porta, a quel punto è gestito con cura, lo stanno facendo perché sono competenti nel loro lavoro.

Quando si tenta di scrivere un'applicazione protetta, è facile per altri processi leggere e scrivere informazioni su di essa a proprio piacimento o si dispone di alcune API accuratamente documentate che ci si aspetta che le persone chiamino e che si disinfettano attentamente?

Gestione dei rischi: se ritieni che il traffico da o verso la tua rete sia un rischio, allora cerchi di ridurre al minimo la quantità di modi in cui il traffico può raggiungere Internet, sia in termini di numero di percorsi che di numero di metodi. È quindi possibile monitorare e filtrare i gateway e le porte "benedetti" scelti per provare e assicurarsi che il traffico che li percorre sia quello che ci si aspetta.

Questa è una politica del firewall "default deny" ed è generalmente considerata una buona idea, con un paio di avvertenze alle quali verrò. Ciò significa che tutto è bloccato a meno che non vi sia una ragione specifica per sbloccarlo e i benefici della ragione superano i rischi.

Modifica: dovrei chiarire, non sto solo parlando dei rischi di un protocollo autorizzato e di un altro bloccato, sto parlando dei potenziali rischi per il business delle informazioni che possono scorrere all'interno o all'esterno della rete in modo incontrollato modo.

Ora per le avvertenze, e forse un piano per liberare le cose:

Può essere fastidioso quando sei bloccato fuori da qualcosa, che è la posizione in cui ti trovi con alcuni dei tuoi clienti. Troppo spesso, i responsabili del firewall pensano che il loro compito sia dire "No", invece di "Ecco i rischi, ora quali sono i vantaggi, vediamo cosa possiamo fare".

Se parli con chiunque gestisca la sicurezza della rete per i tuoi clienti, questi potrebbero essere pronti a creare qualcosa per te. Se riesci a identificare alcuni sistemi specifici alla loro estremità, devi accedere ae / o garantire che ti collegherai solo da un indirizzo IP specifico, potrebbero essere molto più felici di creare un'eccezione del firewall per le connessioni SSH per quelle condizioni specifiche rispetto a loro sarebbe semplicemente aprire connessioni a tutta Internet. Oppure possono avere una funzione VPN che puoi usare per attraversare il firewall.

Una certa grande compagnia a Rochester, NY, che faceva molti film bloccava la ssh in uscita quando lavoravo lì, ma permetteva telnet ! Quando ho chiesto a questo proposito, hanno detto che ssh era una falla di sicurezza.

In altre parole, le aziende a volte prendono decisioni stupide e poi inventano scuse baloney sulla sicurezza piuttosto che ammettere i propri errori.

Sono in grado di comprendere il blocco delle comunicazioni SSH in entrata se la società non consente l'accesso esterno. Ma questa è la prima volta che sento parlare di un blocco SSH in uscita.

Ciò che è importante notare è che tale firewall limiterà probabilmente solo l'utente SSH occasionale. Se qualcuno vuole davvero SSH all'esterno (che in genere si troverà su un server / macchina a cui ha un accesso significativo, al di fuori della rete aziendale) può facilmente eseguire il server SSH su una porta diversa da 22 (diciamo, porta 80). Il blocco verrà bypassato facilmente.

Esistono anche diversi strumenti di dominio pubblico che ti consentiranno di uscire dall'azienda su HTTP (porta 80 o HTTPS 443) e di fornire proxy per connetterti alla porta 22 esterna.

Modifica: Ok, aspetta un secondo, ho un'idea del perché questa potrebbe essere una politica.

A volte, le persone usano i tunnel SSH per bypassare i firewall di base in uscita per protocolli come IM e Bittorrent (ad esempio). Questo // potrebbe // aver innescato una tale politica. Tuttavia, ritengo ancora che la maggior parte di questi strumenti di tunnel sarebbe in grado di funzionare su porte diverse da 22.

L'unico modo in cui tali tunnel in uscita possono essere bloccati è rilevando la comunicazione SSH al volo e (dinamicamente) bloccando queste connessioni TCP.

È probabilmente un problema di regolamentazione / conformità. Il tuo datore di lavoro vuole essere in grado di leggere / archiviare tutte le comunicazioni. Questo è molto spesso un requisito in settori come quello bancario.

A mio avviso, ci sono due motivi principali per bloccare la porta 22 in uscita.

Innanzitutto, come è stato menzionato, il port forwarding SSH può essere utilizzato come proxy o bypassare altre porte e servizi per evitare che i criteri IT affermino che tale traffico non è consentito.

In secondo luogo, molti malware / botnet utilizzeranno la porta 22 perché è spesso vista come "sicura" e quindi consentita. Possono quindi avviare i processi da quella porta e i computer infetti potrebbero anche lanciare attacchi di forza bruta SSH.

Il più delle volte è più un caso di blocco di tutte le connessioni in uscita a meno che non sia necessario e fino a quando non si è tentato nessuno aveva richiesto la porta 22 di essere disponibile per le connessioni in uscita (solo 80, 433 e così via). In tal caso, la soluzione potrebbe essere semplice come contattare IS / IT e dire loro perché è necessario aggiungere un'eccezione in modo che la propria stazione possa effettuare connessioni SSH in uscita verso host specifici o in generale.

A volte è la preoccupazione che le persone possano utilizzare la struttura per utilizzare SSH come un modo per impostare i proxy (tramite il port forwarding sul collegamento) per eludere altri controlli. Questo può essere un fattore molto importante in alcuni settori regolamentati (ad es. Banche) in cui tutte le comunicazioni devono essere monitorate / registrate per motivi legali (scoraggiare l'insider trading, rilevare / bloccare il trasferimento di dati aziendali o personali e così via) o società in cui vi sono è un grande timore che le perdite interne rivelino, inavvertitamente o in altro modo, segreti commerciali. In questi casi l'utilizzo del collegamento 3G (o altre tecniche come tentare di tunnelizzare SSH tramite HTTP) per aggirare le restrizioni può costituire una violazione del contratto e quindi un reato di licenziamento (o, probabilmente peggio, un reato legale), quindi fai attenzione a ottenere la tua azione concordata prima di tentare.

Un altro motivo potrebbe essere quello di ridurre l'impronta in uscita (ai servizi interni accessibili agli host all'interno dei firewall aziendali e al mondo in generale) nel caso in cui qualcosa di spiacevole riesca a installarsi su una macchina funzionante. Se non sono possibili connessioni SSH sulla porta 22, molti hack più semplici che tentano di utilizzare accessi SSH a forza bruta poiché una delle loro rotte di propagazione verranno bloccate. In questo caso potresti nuovamente chiedere un'eccezione in modo che la tua macchina possa effettuare connessioni SSH, se queste connessioni possono essere giustificate alle persone che controllano i firewall.

I tuoi clienti sono probabilmente in possesso di dati non banali che vorrebbero conservare. L'SSH in uscita è davvero brutto da aprire per un'intera rete. È piuttosto banale bypassare i proxy, perdere dati sensibili ed essere generalmente odioso.

IMO, tutto ciò che passa attraverso il perimetro di rete / Internet dovrebbe essere compreso e controllabile. Se un gruppo di sviluppatori ha bisogno di accedere ai server di un provider di hosting tramite ssh, va bene, ma deve anche essere documentato. In generale nei luoghi in cui ho lavorato, stabiliamo connessioni VPN site-to-site dedicate a posizioni esterne alla nostra rete (essenzialmente estendendo la nostra rete interna) ed evitiamo protocolli client come SSH su Internet.

Perché SSH può essere utilizzato come VPN. È crittografato, quindi gli amministratori di rete non hanno letteralmente idea di cosa stia lasciando la loro rete (dump del database dei clienti, ecc.). Ho appena trattato queste cose nella mia rubrica mensile "Tunnel segreti" . Il costo di alcuni Internet 3G è molto meno che doversi preoccupare dei protocolli crittografati che convogliano i tuoi dati fuori dalla rete. Inoltre, se si blocca per impostazione predefinita la porta in uscita 22 e si verifica il traffico, è possibile trovare facilmente SSH su porte non standard e quindi trovare persone che violano la politica di sicurezza.

Conosco un paio di persone che abusano delle capacità di SSH di installare un proxy SOCKS tramite SSH, aggirando così alcune restrizioni del sito.

O anche un semplice port forwarding ( ssh -L ....), se la porta è effettivamente bloccata a causa delle restrizioni del sito, andrei a:

• l'amministratore locale e
• il tuo project manager

portali a un tavolo e lasciali elaborare il motivo per cui questo è bloccato. Ovviamente devi avere buoni motivi per cui hai bisogno di accedere a una porta SSH esterna per lo sviluppo di un prodotto interno (essere interno: perché hai bisogno di accedere a boxA.example.com quando lavori per un'azienda snakeoil.invalid)

Ma devo ancora vedere una società che blocca SSH in uscita :)

Le risposte ovvie sono state tutte dichiarate. È un protocollo crittografato che può essere utilizzato per aggirare la politica attraverso la creazione di tunnel (questo è un ottimo modo per superare i filtri Web aziendali) e la minaccia rappresentata da canali di comunicazione non autorizzati (proxy inverso).

È vero, telnet dovrebbe essere distrutto in qualsiasi rete moderna. Ma posso vedere come consentire a telnet di uscire dalla rete mentre bandisce ssh. Telnet è meno capace di ssh e posso sempre monitorare lo streaming, in tempo reale, attraverso i miei sniffer. Se non ho alcun dispositivo Telnet nella mia rete principale e alcuni utenti vogliono telnet fuori, cosa me ne importa. Posso vederlo e verificare che non sia una minaccia.

Ovviamente, tutto ciò dipende dall'idea che la politica di default è quella di bloccare tutti i flussi di uscita e consentire solo protocolli specifici. Punti bonus se li stai inoltrando prima del colpo al limite.

Non si tratta in particolare di bloccare la porta 22 perché gli amministratori hanno qualcosa contro SSH, piuttosto si tratta solo di aprire le porte che sanno di dover aprire. Se al tuo amministratore non è stato detto che SSH è necessario aprire, l'amministratore lo bloccherà, con lo stesso principio che si applica alla disabilitazione dei servizi inutilizzati su un server.

Chiaramente, un blocco TCP / 22 in uscita è facile da eludere a meno che gli amministratori di rete non abbiano compiuto sforzi seri e seri per bloccare il traffico SSH in modo specifico . Inoltre, gli amministratori di risorse devono essere abbastanza in gamba per eseguire l'inventario delle risorse sufficiente per catturare modem 3G e indirizzi IP sospetti sulle seconde schede di rete. Abbiamo il servizio ClearWire nella nostra zona, quindi abbiamo anche WiMax come opzione di fine corsa per la sicurezza della nostra rete.

Non siamo un'istituzione che si occupa principalmente della perdita di informazioni. Ma se lo fossimo, avremmo bisogno di combinare una politica di sicurezza della rete draconiana con una politica patrimoniale draconiana, con l'auditing. Per quanto ne so, non penso che esista un pacchetto di sicurezza standard che disattiverà il jack di rete di un asset che inventari con una connessione di rete esterna di qualche tipo. Potrebbe venire.

In assenza di tale pacchetto, il processo di inventario delle risorse è uno dei modi migliori per catturare una connessione di rete di fine corsa come 3G o WiMax.

Infine, il blocco cieco di TCP / 22 bloccherà solo il minimo inganno degli utenti finali intenzionati a violare l'AUP per la propria rete di lavoro.

Ho visto 22 bloccati quando hanno scoperto che la gente dirigeva il traffico http attraverso 22. Era un punto fermo per quelli di noi che ne avevano bisogno, ma l'org è rimasta ferma.

La maggior parte delle organizzazioni più grandi bloccherà tutto e consentirà l'accesso HTTP / HTTPS solo tramite un server proxy.

Sarei molto sorpreso di sapere di qualsiasi società che consenta connessioni esterne dirette da desktop o server a meno che non ci fosse una necessità specifica.

Nulla ti impedisce di eseguire il tuo sshd remoto sulla porta 80. Sia ssh che sshd hanno un'opzione -p per impostare la porta.

Naturalmente, se i tuoi amministratori sono intelligenti, dovrebbero guardare per il traffico ssh, non solo per il traffico della porta 22. Quindi, sembra che tu abbia un problema politico, non un problema tecnico.

Come altri hanno sottolineato, tuttavia, i protocolli crittografati possono causare bruciori di stomaco alle persone che devono preoccuparsi di problemi di conformità assortiti.