SSH non è generalmente 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 amministrazione . Ad esempio, connettersi prima tramite una VPN e poi aprire una sessione SSH che si connette tramite quella VPN. Questo fornisce semplicemente più livelli di difesa in profondità e impedisce ai tuoi sistemi di essere direttamente interessati dalle ultime vulnerabilità SSH.

Nota: questo NON è un punto debole di SSH stesso e molte organizzazioni continueranno a esporre SSH su porte TCP elevate per l'utilizzo come server SFTP, quindi avranno uno script per spostare i dati da e verso quello sistema (che non consente al server SSH / SFTP esterno di connettersi al resto della rete).

Tutti i protocolli alla fine hanno delle vulnerabilità quindi se è possibile richiedere l'uso di due diversi (cioè IPSEC VPN e SSH) e mantieni la disciplina sugli sforzi di riparazione quando vengono scoperte delle vulnerabilità, il periodo di tempo in cui esistono vulnerabilità note in entrambi i protocolli contemporaneamente sulla tua rete dovrebbe essere molto piccolo. Statisticamente, il requisito per l'utilizzo di due protocolli dovrebbe ridurre la quantità di tempo in cui si avrebbe un singolo protocollo esposto a una vulnerabilità nota (supponendo che effettivamente si correggano / correggano le vulnerabilità).

Come una grafica di testo scadente, guarda quanto segue:

  Ora --- > IPSEC ------------------ ------ ---------------- SSH --------- ------------------ -----------  

Rispetto ad avere solo SSH, o una VPN, da solo:

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

Nel primo esempio in cui è emersa una vulnerabilità SSH non ce n'era una per IPSEC e viceversa, quindi non c'è mai stato un momento, in questo semplice esempio, in cui i tuoi sistemi presentassero vulnerabilità a entrambi i livelli. Questa difesa in profondità è ciò che protegge il sistema dietro questi protocolli che occasionalmente possono presentare vulnerabilità.

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

Chiederei se vengono esposti altri protocolli amministrativi e, in tal caso, puoi mettere in dubbio il bias tecnologico, ma molto probabilmente potresti trovarti in un'organizzazione che non consente l'accesso diretto ai protocolli amministrativi Internet.

Ho chiesto una spiegazione e sfortunatamente non l'ho capito: il contraente ha dichiarato che SSH non era sicuro ma non sapeva perché.

Perché SSH è insicuro? Sembra che ci sia qualcosa che mi sono perso durante la nostra conversazione che desidero disperatamente capire.

Trattare la 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 non può nemmeno dire perché SSH è insicuro, ma crede fermamente è così. 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 fughe di notizie dalla NSA e non c'è motivo di credere che queste vulnerabilità siano nelle mani solo della NSA.

La vera questione si riduce alla necessità di accesso rispetto alla necessità di sicurezza, non un protocollo su un altro. L'accesso remoto probabilmente ridurrà un po 'la tua sicurezza. Due metodi di accesso remoto ridurranno ulteriormente il metodo di sicurezza. L'abilitazione di uno o più metodi di accesso remoto dovrebbe essere giudicato in base ai compromessi coinvolti, non mantenendo un falso senso di "sicurezza" come concetto binario.

Cos'è insicuro, esattamente?

Per dirlo brevemente, "Perché l'accesso esterno a SSH è considerato insicuro?" : non è "SSH" che è insicuro, è la parte "accesso esterno" della tua domanda che lo è.

SSH è solo un mezzo tecnico tra gli altri per aprire la tua rete interna all'esterno mondo (che altamente rischioso). Può essere utilizzato, da solo o associato ad altre tecnologie, per 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 attraverso vari controlli tecnici che forniranno, a loro volta, adeguati servizi di autenticazione, autorizzazione e audit. Tutto questo, ovviamente, deve essere adeguatamente documentato e mantenuto.

Naturalmente, potresti semplicemente andare avanti 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 insicuro? Perché sarebbe troppo costoso implementarlo correttamente per quanto riguarda il ritorno sull'investimento previsto dall'azienda.

Domanda sui costi

Il costo qui non riguarda l'acquisto di software, si limiterà semplicemente a pagare il tempo delle persone prima di progettare e configurare questo servizio e poi di mantenerlo tempo (mentre queste persone sono occupate con questo, ci sono altri compiti che non faranno). Il costo effettivo dipenderà quindi molto dallo stipendio, dalle competenze attuali e dalla complessità della tua attuale infrastruttura.

Da un punto di vista tecnico, l'autenticazione basata su chiavi e fail2ban sono una soluzione valida e ben documentata. Eseguirlo su porte alte lo farà anche uscire dalla vista della maggior parte dei bot. Ma ciò non impedirà, ad esempio, a un vero dipendente di connettersi alla rete interna dal computer di famiglia traboccante di worm, virus e backdoor di ogni tipo, costituendo così involontariamente la rete dell'azienda. Questo è uno dei rischi che potresti dover affrontare.

Dal punto di vista della gestione, è probabile che il "capo" sia più interessato alla ponderazione (monetaria) dei vari rischi rispetto al rendimento atteso sugli investimenti: cosa questo costerà l'installazione e la manutenzione? Quanto consentirà all'azienda di guadagnare o economizzare? Quanto potrebbe costare in caso di disastro?

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

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

Alcune persone hanno toccato la base sul motivo per cui aprire un vettore di attacco è spesso scoraggiato, ma ecco alcune cose che annullano la necessità di paura se usato correttamente:

• VPN nella rete, quindi SSH al dispositivo
• Utilizza una porta non standard
• Utilizza coppie di chiavi private
• Implementa strumenti come fail2ban
• Nega accessi utente root

Onestamente, solo una di queste opzioni rende l'hacking molto più difficile. L'implementazione di almeno due significa che puoi utilizzare SSH senza preoccupazioni.

Che l'appaltatore IT dovrebbe davvero prendere in considerazione un nuovo scambio.

SSH non è insicuro, tuttavia non è necessariamente una buona pratica esporre SSH a Internet per paura di compromissione remota. Aprendo SSH al mondo, inviti visitatori non necessari che eseguiranno bot contro la tua distribuzione cercando di ottenerlo. Anche se non riescono, è comunque inutile; se riescono, 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 altri nella rete.

Se lo esponi su Internet, disabilita l'autenticazione della password e disabilita accesso root, consente solo l'accesso basato su chiave. Se è necessario consentire le password, non consentirle per root e utilizzare una soluzione a due fattori con password generate casualmente.

SSH può essere considerato insicuro perché la tua organizzazione potrebbe non disporre di politiche in atto per controllare le credenziali.

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

Qualsiasi organizzazione che consenta l'accesso SSH probabilmente vorrebbe prevenire la compromissione della password da parte del dizionario (oltre ad assicurarsi che il software SSH sia aggiornato). Potrebbero scegliere di limitare i tentativi di accesso non riusciti forse tramite IP. Potrebbero scegliere di non consentire affatto l'accesso con password tramite SSH o, come altri menzionati, potrebbero richiedere l'autenticazione a due fattori. Tuttavia, se non hanno una politica, la politica migliore potrebbe essere quella di non consentire l'accesso remoto SSH.

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