In che modo un amministratore di rete blocca l'SSH inverso in azienda?

Il traffico SSH è diverso da HTTP e HTTPS. Il traffico SSH semplicemente tunnelato attraverso la porta 80 o 443 (cioè ssh -p80... ) può essere rilevato osservando il primo pacchetto di risposta che contiene già la versione SSH e non la versione HTTP o TLS ServerHello. Ma potresti anche semplicemente far rispettare l'uso di un proxy HTTP all'interno della rete che rende impossibile l'uso di SSH semplice.

Questo lascia la possibilità di eseguire il tunnel SSH all'interno di un altro protocollo, come semplicemente creare un tunnel attraverso il proxy usando una richiesta CONNECT o anche nascondere la connessione SSH all'interno di una connessione TLS completa, usando semplicemente HTTP, usando WebSockets, con DNS o simili . Questo è molto più difficile da rilevare anche se alcune analisi statistiche potrebbero essere utili perché SSH mostra un comportamento diverso rispetto al normale traffico HTTP. Ma tale analisi potrebbe essere facilmente confusa con il traffico WebSocket comune di oggi.

Alla fine è una gara e dovresti chiederti perché ti concentri comunque sui tunnel SSH. Questi tunnel non sono altro che uno strumento per trasportare i dati tra interno ed esterno. Tali trasporti di dati possono anche essere fatti usando il normale HTTP / HTTPS, può essere fatto con chiavette USB ecc. Quindi concentrarsi su un singolo vettore impedisce la perdita di dati o impedire che l'attaccante che entra nella rete sia IMHO nel modo sbagliato. E per avere una politica: è più sicuro avere una lista bianca su ciò che è permesso piuttosto che avere una lista nera su ciò che non è permesso.

Un modo per renderlo un po 'più difficile potrebbe essere avere un proxy HTTP in posizione in modo che le connessioni non possano essere fatte direttamente oltre 80/443 a meno che non sia una connessione HTTP valida, ma anche quella può essere aggirata usando qualcosa come Proxytunnel . Un altro modo per aggirare questo sarebbe semplicemente eseguire una console Web e accedervi normalmente oltre 80/443.

Rendere più difficile per loro probabilmente non li fermerà, ma alla fine se lo hai nella tua politica che non è permesso e controlli la rete allora gli avvertimenti possono essere dati alle persone che infrangono questa regola.

Qui, hanno bloccato SSH attraverso la porta 443 bloccando il metodo CONNECT del proxy HTTP.

Una seconda soluzione consiste nell'utilizzare una falsa pagina di "accesso". L'utilizzo del proxy può richiedere la password, che viene richiesta normalmente dal browser o immessa nei campi di autenticazione in app che possono utilizzare un proxy. Ma puoi bypassarlo sul server proxy usando una pagina di login falsa che richiede login / password.

Questo metodo è orribile, in quanto solo l'applicazione che visualizza questa pagina può passare attraverso il proxy. Ad esempio, Putty non può visualizzare questa pagina e quindi non può autenticarsi sul proxy.

La prima domanda dovrebbe essere il motivo per cui gli utenti / amministratori utilizzano i tunnel ssh inversi. Ho lavorato in un'azienda che disponeva di una VPN veramente poco implementata per la gestione remota, che consentiva solo la connettività a un server Citrix con strumenti scadenti, quindi abbiamo utilizzato i tunnel remoti SSH per gestire adeguatamente i nostri server da remoto. I tunnel in cui è consentito solo da un host bastione. L'host è stato configurato con l'autenticazione password disabilitata, accesso root disabilitato e autenticazione basata su chiave Enabled. Il tunnel inverso consentiva il passaggio delle connessioni ssh alla DMZ, quindi gli utenti dell'host bastion potevano accedere a una manciata di altri host bastion. Invece di andare giù nella tana del coniglio per bloccare il tunneling ssh con MITM che intercettano i proxy, IDS, bloccando l'accesso agli IP domestici degli amministratori e ai firewall DPI. Fornire una soluzione migliore agli utenti / amministratori, soddisfare le loro esigenze, quindi attuare una politica delle risorse umane e applicarla.

Luajit via Suricata IDPS fornisce alcuni meccanismi avanzati per il controllo di SSH e di tunnel SSL / TLS per prevenire sovversioni proxy, reverse shell, ecc.

Guarda questa guida piuttosto approfondita, anche se non completamente completa, per trovare certificati autofirmati usando Suricata e luajit - link

Chiedendo come proteggere ssh apre una lattina di worm, ecco i worm.

Alcuni saranno pazzi quando dico questo, ma è qualcosa di abbastanza semplice che può essere realizzato e "dovrebbe essere stato costruito in questo modo" molto tempo fa.

Questo può essere fatto, la maggior parte di coloro che non sono d'accordo sono neighsayer e probabilmente responsabili delle vulnerabilità che attualmente affrontiamo nel mondo ... Sto divagando.

Il suggerimento sopra esposto di forzare tutto il traffico tramite proxy che richiedono visibilità nel traffico prima della consegna è un buon inizio e dovrebbe essere un concetto distribuito in cima e allineato con la rete e le politiche e le metodologie di sicurezza fisica, a volte fino al laptop / mobile della guardia giurata che fanno servizio di sala.

Controlla le workstation dei tuoi clienti. Legali in modo appropriato. Segregare da wireless. Monitoraggio costante delle statistiche sui client "terminali stupidi". Usb disattivato. Fornire hub di alimentazione per le persone che necessitano di energia. Tutte le esportazioni vengono lasciate attraverso un processo di approvazione, che include le procedure di amministrazione IT.

Il software su queste workstation può essere una semplice piattaforma con capacità minima che fornisce un'interfaccia web o un'applicazione client che li guidi in modo sicuro a risorse accessibili che sono appropriate solo per il loro ruolo.

Il wireless dovrebbe essere evitato a meno che non si trovi su un tronco completamente diverso.

Servizi come "piattaforme di social media" dovrebbero essere "sovrascrutizzati" in quanto dovrebbero essere più falsi allarmi di quelli effettivi, in modo che l'azienda possa trarre vantaggio dalle informazioni che entrano ed escono da una rete di social media "utilizzata". "

Tutto questo è da un agente di supporto di basso livello con troppo tempo a disposizione. Tuttavia, se si dispone di una rete con queste metodologie implementate, si attesta che è prezioso conoscere l'andirivieni dei dipendenti, non un'invasione della privacy, ma una risorsa. Nel luogo in cui si trovano i dati protetti, l'unica cosa che chiunque dovrebbe nascondere è la società e i suoi dati, inclusi chi lo gestisce e come.

In questo giorno ed età, se hai una ragione per la sicurezza delle informazioni, hai bisogno di garanzie in quelle persone che assicurano di fornire informazioni sicure.

Non è necessario che i dipendenti spostino i dati dell'azienda in maniera così libera come in questi giorni.

Tutto ciò può essere notevolmente mitigato al minimo, per non parlare del rispetto dei protocolli di sicurezza fisica e per limitare gli aspetti fotografici e video dei metodi exfil, oltre alla solita penna e carta, "drive usb killer", ecc.