Explotación de día cero del servidor SSH: sugerencias para protegernos

13

Según el Centro de tormentas de Internet , parece que hay un exploit SSH de día cero.

Aquí hay alguna prueba de código de concepto y alguna referencia:

Esto parece ser un problema grave, por lo que todos los administradores de sistemas Linux / Unix deben tener cuidado.

¿Cómo nos protegemos si este problema no se repara a tiempo? ¿O cómo manejas las vulnerabilidades de día cero en general?

* Publicaré mi sugerencia en las respuestas.

— sucursales
fuente

¿Cuán real es esto? Un poco de googletrolling apareció seclists.org/fulldisclosure/2009/Jul/0028.html como la fuente más original de este rumor. ¿Alguien tiene una verificación independiente de esto?

— Chris

Muchos buenos comentarios en Hacker News sobre este tema: news.ycombinator.com/item?id=692036

— sucuri

6

Comentario de Damien Miller (desarrollador de OpenSSH): http://lwn.net/Articles/340483/

En particular, pasé algún tiempo analizando el rastreo de paquetes que proporcionó, pero parece consistir en simples ataques de fuerza bruta.

Por lo tanto, no me persigue que exista un día 0 en absoluto. La única evidencia hasta ahora son algunos rumores anónimos y transcripciones de intrusión no verificables.

— x-way
fuente

Creo que podemos tomar su palabra por ahora ...

— sucuri

11

Mi sugerencia es bloquear el acceso SSH en el firewall a todos los demás además de su ip. En iptables:

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

— sucursales
fuente

5

De acuerdo con la publicación de SANS, esta hazaña does not work against current versions of SSH, y por lo tanto no es realmente un día 0. Parchea tus servidores, y deberías estar bien.

— Dentrasi
fuente

2

técnicamente es un exploit de 0 días (no publicado y desconocido) pero que solo funciona en versiones anteriores de SSH. Sin embargo, la versión predeterminada en RHEL, Fedora es vulnerable (según la segunda publicación). Por lo tanto, es un gran problema si no hay un parche de su distribución (a menos que utilice ssh desde la fuente que no es común) ...

— sucuri

1

Están especulando sobre la base de los registros de ataque. No se sabe a ciencia cierta ... Incluso la versión más reciente podría ser vulnerable

— sucuri

3

Quejarse a sus vendedores

De esa manera todos obtienen la versión más nueva.

— Brad Gilbert
fuente

3

FYI, la fuente original de la historia: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

También hay dos historias similares (pirateando astalavista.com y otro sitio): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Parece que alguien tiene una agenda: romeo.copyandpaste.info/ ("Keep 0days private")

— x-way
fuente

Convenido. El grupo detrás de los registros originales que comenzaron esto tiene una declaración de misión para meterse con "la industria de la seguridad", y ¿qué mejor manera de hacerlo que hacer que todos se vuelvan escandalosos por "omg! Openssh 0day ?! ¿Cómo puedo encontrarlo / detenerlo? ¿Hackearlo? "

— cji

Tampoco sería la primera vez que tales rumores y exageraciones resultaron ser falsas.

— Dan Carley

2

Compilo SSH para usar tcprules, y tengo un pequeño número de reglas de permiso, negando todas las demás.

Esto también garantiza que los intentos de contraseña se eliminen casi por completo y que cuando me envíen informes sobre intentos de ruptura, pueda tomarlos en serio.

— Ernie
fuente

2

No ejecuto ssh en el puerto 22. Dado que a menudo inicio sesión desde diferentes máquinas, no me gusta evitar el acceso a través de iptables .

Esta es una buena protección contra ataques de día cero , que seguramente irá después de la configuración predeterminada. Es menos efectivo contra alguien que está tratando de comprometer solo mi servidor. Un escaneo de puertos mostrará en qué puerto estoy ejecutando ssh, pero un script que ataca puertos SSH aleatorios omitirá mis hosts.

Para cambiar su puerto, simplemente agregue / modifique el Puerto en su archivo / etc / ssh / sshd_config .

— brianegge
fuente

Ejecutar SSH en un puerto no estándar parece reducir la cantidad de ataques de fuerza bruta a los que está sujeto y probablemente lo protegerá de la mayoría de los gusanos. No es una defensa contra alguien escanear manualmente cosas embargo, y un gusano puede en el futuro solo puerto de escanear cada puerto en busca de ssh (que es fácil, requiere mucho tiempo solo)

— MarkR

@MarkR: Puede que no detenga un determinado 'cracker / kiddie / hacker' pero mantendrá a raya a los bots hasta que se libere una solución. Eso es lo más importante en mi humilde opinión.

— Andrioid

2

Cortaría el firewall y esperaría. Mi instinto es una de dos cosas:

A> engaño. Por la poca y falsa información dada hasta ahora, es esto ...

o...

B> Este es un intento de "humo y engaño", para causar preocupación sobre 4.3. ¿Por qué? ¿Qué pasa si usted, alguna organización de hackers, encuentra un exploit de día cero realmente genial en sshd 5.2?

Lástima que solo las versiones de vanguardia (Fedora) incorporen esta versión. Ninguna entidad sustancial usa esto en la producción. Muchos usan RHEL / CentOS. Grandes objetivos Es bien conocido que RHEL / CentOS respaldan todas sus correcciones de seguridad para retener algún tipo de control de versión básico. Los equipos detrás de esto no deben ser despreciados. RHEL ha publicado (leí, tendría que desenterrar el enlace) que han agotado todos los intentos de encontrar cualquier falla en 4.3. Palabras a no ser tomadas a la ligera.

Entonces, volviendo a la idea. Un pirata informático decide de alguna manera provocar un revuelo de aproximadamente 4.3, causando histeria colectiva a UG a 5.2p1. Pregunto: ¿cuántos de ustedes ya tienen?

Para crear alguna "prueba" para la dirección errónea, todo lo que "dicho grupo" tendría que hacer ahora es hacerse cargo de algún sistema previamente comprometido ( WHMCS ? SSH anterior?), Crear algunos registros con algunas verdades a medias (ataque-ee verificado "algo" sucedió, sin embargo, algunas cosas no se pueden verificar por objetivo) con la esperanza de que alguien "muerda". Todo lo que se necesita es una entidad más grande para hacer algo drástico (... HostGator ...) para hacerlo un poco más serio, en medio de la creciente ansiedad y confusión.

Muchas entidades grandes pueden tener backport, pero algunas pueden simplemente actualizarse. Aquellos que actualizan, ahora están abiertos al verdadero ataque de día cero sin revelación hasta el momento.

He visto cosas más extrañas suceder. Como, un montón de celebridades muriendo en una fila ...

— Peter Mortensen
fuente

0

¿Cambiar a Telnet? :)

Bromas aparte, si tiene su firewall configurado correctamente, ya solo está permitiendo el acceso SSH a algunos hosts. Entonces estás a salvo.

Una solución rápida podría ser instalar SSH desde la fuente (descargándolo de openssh.org), en lugar de usar versiones antiguas que están presentes en las últimas distribuciones de Linux.

— sucursales
fuente

Telnet kerberizado es en realidad razonablemente seguro. Lo bueno de kerberos es que puede revocar centralmente una clave si lo desea, a diferencia de ssh, donde debe visitar cada host y eliminar una clave de cada archivo autorizado_keys.

— chris