Exploit zero-day del server SSH - Suggerimenti per proteggerci

13

Secondo Internet Storm Center , sembra che ci sia un exploit zero-day SSH là fuori.

C'è qualche prova del codice di concetto qui e alcuni riferimenti:

Questo sembra essere un problema serio, quindi ogni amministratore di sistema Linux / Unix dovrebbe stare attento.

Come possiamo proteggerci se questo problema non viene corretto in tempo? O come gestisci gli exploit zero-day in generale?

* Pubblicherò il mio suggerimento nelle risposte.

— Sucuri
fonte

Quanto è reale? Un piccolo googletrolling ha rivelato seclists.org/fulldisclosure/2009/Jul/0028.html come la fonte più originale di questa voce. Qualcuno ha una verifica indipendente di questo?

— chris,

Molti buoni commenti su Hacker Notizie su questo problema: news.ycombinator.com/item?id=692036

— sucuri

6

Commento di Damien Miller (sviluppatore OpenSSH): http://lwn.net/Articles/340483/

In particolare, ho trascorso un po 'di tempo ad analizzare una traccia di pacchetto fornita da lui, ma sembra consistere in semplici attacchi di forza bruta.

Quindi, non sono convinto che esista un giorno 0. Le uniche prove finora sono alcune voci anonime e trascrizioni di intrusioni non verificabili.

— x-way
fonte

Penso che possiamo prendere la sua parola per ora ...

— sucuri,

11

Il mio suggerimento è di bloccare l'accesso SSH sul firewall a chiunque altro oltre al tuo IP. Su iptables:

/sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP

— Sucuri
fonte

5

Secondo così il post SANS, questo exploit does not work against current versions of SSH, e quindi non è proprio uno 0 giorni. Patch i tuoi server e dovresti andare bene.

— Dentrasi
fonte

2

tecnicamente è un exploit di 0 giorni (non pubblicato e sconosciuto) ma funziona solo su versioni precedenti di SSH. Tuttavia, la versione predefinita su RHEL, Fedora è vulnerabile (secondo il secondo post). Quindi, è un grosso problema se non ci sono patch dalla tua distribuzione (a meno che tu non usi ssh dal sorgente che non è comune) ...

— sucuri

1

Stanno ipotizzando quello sulla base dei registri degli attacchi. Nessuno lo sa per certo ... Anche l'ultima versione potrebbe essere vulnerabile

— sucuri,

3

Reclami ai tuoi fornitori

In questo modo tutti ottengono la versione più recente.

— Brad Gilbert
fonte

3

Cordiali saluti, la fonte originale della storia: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Ci sono anche due storie simili (hacking astalavista.com e un altro sito): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Sembra che qualcuno abbia un ordine del giorno: romeo.copyandpaste.info/ ("Mantieni privati 0 giorni")

— x-way
fonte

Concordato. Il gruppo dietro i registri originali che ha iniziato questo ha una dichiarazione di missione per pasticciare con "l'industria della sicurezza" - e quale modo migliore per farlo che ottenere tutti in subbuglio per "omg! Openssh 0day ?! come posso trovarlo / fermarmi it / hack con esso? "

— cji,

Non sarebbe la prima volta che tali voci e clamore si sono rivelati falsi.

— Dan Carley,

2

Compilo SSH per usare le tcprule e ho un piccolo numero di regole di consenso, negando tutte le altre.

Questo assicura anche che i tentativi di password vengano quasi eliminati e che quando ricevo segnalazioni sui tentativi di violazione, posso prenderli sul serio.

— Ernie
fonte

2

Non eseguo ssh sulla porta 22. Dato che accedo spesso da macchine diverse, non mi piace impedire l'accesso tramite iptables .

Questa è una buona protezione contro gli attacchi zero-day , che sicuramente seguiranno la configurazione predefinita. È meno efficace contro qualcuno che sta cercando di compromettere solo il mio server. Una scansione delle porte mostrerà su quale porta sto eseguendo ssh, ma uno script che attacca le porte SSH casuali salterà i miei host.

Per cambiare la tua porta, aggiungi semplicemente / modifica la Porta nel tuo file / etc / ssh / sshd_config .

— brianegge
fonte

L'esecuzione di SSH su una porta non standard sembra ridurre la quantità di attacchi di forza bruta a cui è soggetta e probabilmente ti proteggerà dalla maggior parte dei worm. Tuttavia, non è una difesa contro qualcuno che esegue manualmente la scansione delle cose, e in futuro un worm potrebbe semplicemente scansionare tutte le porte in cerca di ssh (che è facile, richiede solo tempo)

— MarkR

@MarkR: Potrebbe non fermare un determinato "cracker / kiddie / hacker", ma manterrà i bot a bada fino al rilascio di una correzione. Questo è l'imho più importante.

— Andrioid,

2

Vorrei firewall e aspettare. Il mio istinto è una delle due cose:

A> Hoax. Dalle informazioni poco e mancate fornite finora, è o questo ..

o...

B> Questo è un tentativo di "fumo e inganno", che causa preoccupazione per 4.3. Perché? E se tu, qualche organizzazione di hacker, trovi un exploit zero-day davvero interessante in sshd 5.2.

Peccato che solo versioni all'avanguardia (Fedora) incorporino questa versione. Nessuna entità sostanziale lo utilizza nella produzione. Molto uso RHEL / CentOS. Grandi obiettivi. È noto il backport RHEL / CentOS di tutte le loro correzioni di sicurezza per mantenere una sorta di controllo di versione di base. Le squadre dietro questo non devono essere prese in giro. RHEL ha pubblicato (ho letto, avrebbe dovuto scavare il link) che hanno esaurito tutti i tentativi di trovare qualche difetto in 4.3. Parole da non prendere alla leggera.

Quindi, torniamo all'idea. Un hacker decide di in qualche modo suscitare scalpore verso 4.3, portando l'isteria di massa a UG a 5.2p1. Chiedo: quanti di voi hanno già?

Per creare una "prova" per la direzione errata, tutto ciò che "detto gruppo" dovrebbe fare ora è assumere un sistema precedentemente compromesso ( WHMCS ? SSH precedente?), Creare alcuni log con alcune mezze verità (attack-ee verificato "qualcosa" accaduto, eppure alcune cose non verificabili dal bersaglio) sperando che qualcuno potesse "mordere". Basta un'entità più grande per fare qualcosa di drastico (... HostGator ...) per renderlo un po 'più serio, in mezzo alla crescente ansia e confusione.

Molte entità di grandi dimensioni possono eseguire il backport, ma alcune potrebbero semplicemente aggiornarsi. Quelli che si aggiornano, ora si aprono al vero attacco zero-day senza ancora rivelarlo.

Ho visto accadere cose più strane. Ad esempio, un gruppo di celebrità che muoiono tutte di fila ...

— Peter Mortensen
fonte

0

Passare a Telnet? :)

Scherzi a parte, se il firewall è configurato correttamente, consente già l'accesso SSH a pochi host. Quindi sei al sicuro.

Una soluzione rapida potrebbe essere quella di installare SSH dal sorgente (scaricandolo da openssh.org), invece di utilizzare vecchie versioni presenti nelle ultime distribuzioni Linux.

— Sucuri
fonte

Telnet Kerberized è in realtà ragionevolmente sicuro. La cosa bella di Kerberos è che puoi revocare centralmente una chiave se vuoi, a differenza di ssh dove devi visitare ogni host e rimuovere una chiave da ogni file authorized_keys.

— chris,