Perché l'accesso esterno a un server tramite SSH è considerato non sicuro?

In primo luogo, chiunque affermi "questo non è sicuro, ma non so perché" sta completamente negando il diritto di parlare da una posizione di autorità in materia.

Alcune persone hanno toccato il motivo base per cui l'apertura di un vettore di attacco è spesso scoraggiata, ma ecco alcune cose che annullano il bisogno di paura se usate correttamente:

• VPN nella rete, quindi SSH sul dispositivo
• Utilizza una porta non standard
• Utilizza coppie di chiavi private
• Implementa strumenti come fail2ban
• Rifiuta i login dell'utente root

Onestamente, solo una di queste opzioni rende l'hacking molto più difficile. Implementando almeno due mezzi puoi usare SSH senza preoccupazioni.

L'appaltatore IT dovrebbe davvero considerare un nuovo commercio.

SSH non è in genere considerato insicuro di per sé ma è un protocollo amministrativo e alcune organizzazioni richiedono due o più livelli di controllo per ottenere l'accesso a una console di gestione . Ad esempio, connettendo prima tramite una VPN, quindi aprendo una sessione SSH che si connette attraverso quella VPN. Ciò fornisce semplicemente più livelli di difesa in profondità e impedisce ai tuoi sistemi di essere direttamente interessati dalle ultime vulnerabilità di SSH.

Nota: questo NON è un punto debole nello stesso SSH e molte organizzazioni espongono ancora SSH su porte TCP alte per l'utilizzo come server SFTP, quindi hanno uno script per spostare i dati da e verso quel sistema (non permettendo il server SSH / SFTP esterno per connettersi al resto della loro rete).

Tutti i protocolli alla fine presentano vulnerabilità quindi se puoi richiedere l'utilizzo di due diversi (es. IPSEC VPN e SSH) e rimanere disciplinato sugli sforzi di riparazione quando vengono scoperte le vulnerabilità, la finestra temporale in cui è noto le vulnerabilità presenti in entrambi i protocolli contemporaneamente sulla tua rete dovrebbero essere molto piccole. Statisticamente, il requisito per l'utilizzo di due protocolli dovrebbe ridurre la quantità di tempo in cui si dovrebbe esporre un singolo protocollo con una vulnerabilità nota (supponendo che in realtà si patch / rimediare alle vulnerabilità).

Come grafica di testo scadente, guarda quanto segue:

Time ---> 

IPSEC ------------------------     ----------------

SSH   ---------       -----------------------------

Contro avere solo SSH, o una VPN, da solo:

SSH   ---------       -----------------------------

Nel primo esempio in cui è emersa una vulnerabilità SSH, non ce n'era uno per IPSEC e viceversa, quindi non c'è mai stato un tempo, in questo esempio approssimativo, in cui i sistemi presentavano vulnerabilità a entrambi gli strati. Questa difesa in profondità è ciò che protegge il sistema dietro questi protocolli che a volte possono avere vulnerabilità.

Nel secondo esempio, SSH da solo, nel momento in cui vi è una vulnerabilità, o una violazione della password, o un numero qualsiasi di altri problemi, un utente malintenzionato può accedere direttamente al sistema vulnerabile durante la finestra di esposizione.

Vorrei chiedere se sono stati esposti altri protocolli amministrativi e, in tal caso, è possibile mettere in discussione il bias della tecnologia, ma molto probabilmente si può essere in un'organizzazione che non consente l'accesso a qualsiasi protocollo amministrativo direttamente da Internet.

I asked for an explanation and unfortunately did not understand it - the contractor stated SSH was insecure but did not know why.

Why is SSH insecure? There seems to be something I missed during our conversation that I desperately want to understand.

Il trattamento della sicurezza come un binario "sicuro" o "non sicuro" riflette una scarsa comprensione della sicurezza; la sicurezza è sempre un continuum e nulla è perfettamente sicuro.

L'appaltatore in questione sembra avere una grande mancanza di informazioni su SSH se lui / lei non può nemmeno dire perché SSH è insicuro, ma crede fermamente che lo sia. L'ignoranza genera paura e la mia ipotesi è che l'appaltatore stia reagendo alla paura piuttosto che alla conoscenza.

SSH non è meno sicuro delle VPN dei principali fornitori. Anche le VPN hanno vulnerabilità di sicurezza e non sono "fatte di magia". Lo sappiamo dalle varie falle della NSA e non c'è motivo di credere che queste vulnerabilità siano nelle mani della sola NSA.

La vera domanda deriva dalla necessità di accedere a necessità di sicurezza, non di un protocollo piuttosto che di un altro. L'accesso remoto probabilmente ridurrà un po 'la sicurezza. Due metodi di accesso remoto ridurranno ulteriormente il tuo metodo di sicurezza. Se abiliti uno o più metodi di accesso remoto dovrebbe essere giudicato dai compromessi coinvolti, non mantenendo un falso senso di "sicurezza" come concetto binario.

Che cosa è insicuro, esattamente?

Per dirla in breve, "Perché l'accesso esterno a SSH è considerato non sicuro?" : non è "SSH" che non è sicuro, è " accesso esterno " parte della tua domanda che è.

SSH è solo un mezzo tecnico tra gli altri per aprire la tua rete interna al mondo esterno (che è altamente rischioso). Può essere utilizzato, standalone o associato ad altre tecnologie, al fine di implementare la tua politica di accesso remoto.

La politica di accesso remoto è la definizione formale che indica chi può accedere a cosa, quando e da dove, definisce tutte le regole che verranno poi implementate utilizzando vari controlli tecnici che forniranno a loro volta autentici servizi di autenticazione, autorizzazione e controllo . Tutto ciò, ovviamente, deve essere adeguatamente documentato e mantenuto.

Ovviamente, potresti continuare senza tutti questi oneri amministrativi e di manutenzione, ma ecco il punto: prendere tale scorciatoia è esattamente ciò che sarebbe insicuro nella tua domanda.

Quindi, perché l'accesso esterno a SSH è considerato non sicuro? Perché costerebbe troppo per implementarlo correttamente in relazione al ritorno sull'investimento previsto dalla società.

Domanda costo

Il costo qui non riguarda l'acquisto di software, si tratta semplicemente di pagare le persone in un primo momento per progettare e configurare questo servizio, e quindi per mantenerlo nel tempo (mentre queste persone sono occupate da questo ci sono altri compiti che non star facendo). Il costo effettivo sarà quindi molto dipendente dallo stipendio, dalle attuali competenze e dalla complessità della tua attuale infrastruttura.

Da un punto di vista tecnico, l'autenticazione basata su chiavi e fail2ban è una soluzione buona e ben documentata. Eseguirlo su porte alte lo farà uscire dalla maggior parte degli avvistamenti dei bot. Ma questo non impedirà ad esempio a un vero dipendente di connettersi alla rete interna dal suo computer di famiglia traboccante di worm, virus e backdoor di ogni genere, quindi involontariamente comprendente la rete dell'azienda. Questo è uno dei rischi che potresti dover affrontare.

Da un punto di vista gestionale è probabile che il "capo" possa essere più interessato alla (monetaria) ponderazione dei vari rischi rispetto al rendimento atteso sugli investimenti: quanto costerà costare alla configurazione e alla manutenzione? Quanto questo permetterà alla compagnia di guadagnare o economizzare? Quanto potrebbe costare in caso di disastro?

Il rischio è sempre lì, con tutto. Se riesci a dimostrare che dal punto di vista commerciale aprire la rete interna (o forse alcune parti ben definite di esso, che sarebbero un modo efficace per ridurre il rischio) sarà una mossa proficua per l'azienda, avrai fatto metà se non la maggior parte del viaggio. Come fare sarà quindi solo una questione di scelte tecniche a seconda di ciò che hai pianificato di fare. Ma devi certamente risolvere la questione da un punto di vista aziendale e funzionale prima di scendere nei dettagli tecnici.

SSH non è insicuro, tuttavia non è necessariamente una buona pratica esporre SSH a Internet per timore di un compromesso remoto. Aprendo SSH al mondo, inviti visitatori non necessari che eseguiranno bot contro il tuo deployment cercando di ottenerlo. Anche se non ci riescono, non è ancora necessario; se hanno successo, potresti trovarti in un mondo di dolore. Se il sistema esposto viene compromesso, è facile installare una backdoor persistente e utilizzare questo sistema come punto di leva per attaccare gli altri nella rete.

Se lo esporti su Internet, disabilita l'autenticazione della password e disabilita l'accesso root, solo consentire l'accesso basato su chiave. Se devi consentire le password, non permetterle per root e utilizzare una soluzione a 2 fattori con password generate casualmente.

SSH potrebbe essere considerato non sicuro perché la tua organizzazione potrebbe non disporre di criteri per il controllo delle credenziali.

Nel tempo i dipendenti vanno e vengono. Possono anche cambiare ruolo. Se non c'è alcun meccanismo per disabilitare l'accesso SSH quando necessario, SSH sarebbe insicuro. Questo non indica un problema con il protocollo o il software. Piuttosto è un problema generale applicabile a qualsiasi accesso remoto.

Qualsiasi organizzazione che consente l'accesso SSH probabilmente vorrebbe evitare che la password venga compromessa dall'attacco del dizionario (oltre a verificare che il software SSH sia aggiornato). Potrebbero scegliere di limitare i tentativi di accesso falliti, forse per IP. Potrebbero scegliere di non consentire affatto il login della password tramite SSH, o come altri menzionati potrebbero richiedere l'autenticazione a doppio fattore. Tuttavia, se non hanno una politica, la politica migliore potrebbe essere quella di non consentire l'accesso remoto SSH.

Se il contraente non sa perché potrebbe essere insicuro, potrebbe effettivamente prendere la decisione migliore per non consentire l'accesso remoto.