¿Cómo deshabilito SSLv3 en un servidor OpenSSH SSH para evitar POODLE?

A raíz de la vulnerabilidad POODLE recientemente descubierta , me gustaría deshabilitar SSLv3 en todos mis servidores SSH. ¿Cómo consigo esto con OpenSSH?

— drs
fuente

Ni siquiera se ve afectado, consulte CVE-2014-3566

— Braiam

@Braiam, se me solicitó hacer esta pregunta porque el artículo vinculado aconseja a los usuarios que protejan sus servidores SSH contra esta vulnerabilidad.

— Dres

Fue su error. Google, el que lo descubrió, no dijo nada sobre SSH.

— Braiam

-1 porque SSH y SSL / TLS son dos protocolos completamente diferentes. ZDnet no es una fuente técnica confiable.

— bortzmeyer

@bortzmeyer mientras técnicamente tienes razón, la pregunta no es tan mala. Y mucha gente probablemente pregunta lo mismo.

— Peter

Esto no es un problema para OpenSSH ya que no hace uso de SSL.

Extracto: ¿Cuál es la diferencia entre SSL y SSH? ¿Cuál es más seguro?

Difieren en las cosas que están alrededor del túnel. SSL utiliza tradicionalmente certificados X.509 para anunciar claves públicas de servidor y cliente; SSH tiene su propio formato. Además, SSH viene con un conjunto de protocolos para lo que pasa dentro del túnel (multiplexar varias transferencias, realizar autenticación basada en contraseña dentro del túnel, gestión de terminales ...) mientras no exista tal cosa en SSL o, más exactamente, cuando tales cosas se usan en SSL que no se consideran parte de SSL (por ejemplo, cuando se realiza una autenticación HTTP basada en contraseña en un túnel SSL, decimos que es parte de "HTTPS", pero realmente funciona de manera similar a lo que sucede con SSH).

Conceptualmente, podría tomar SSH y reemplazar la parte del túnel con la de SSL. También puede tomar HTTPS y reemplazar la cosa SSL con SSH-with-data-transport y un enlace para extraer la clave pública del servidor de su certificado. No hay imposibilidad científica y, si se hace correctamente, la seguridad seguirá siendo la misma. Sin embargo, no existe un conjunto generalizado de convenciones o herramientas existentes para eso.

Como evidencia adicional, lo dirigiría a RFC 4253 , que analiza el "Protocolo de capa de transporte de Secure Shell (SSH)". Esta es la capa de transporte personalizada de SSH, no usa la misma que usa HTTPS / SSL.

Este documento describe el protocolo de capa de transporte SSH, que generalmente se ejecuta sobre TCP / IP. El protocolo se puede utilizar como base para una serie de servicios de red seguros. Proporciona cifrado sólido, autenticación de servidor y protección de integridad. También puede proporcionar compresión.

Por último, este Q&A del sitio de seguridad SE titulado: La vulnerabilidad SSL3 "Poodle" tenía esto que decir sobre el ataque POODLE.

extracto

El ataque Poodle funciona en un contexto de texto plano elegido, como BEAST y CRIME antes. El atacante está interesado en los datos que se protegen con SSL, y puede:

inyectar datos propios antes y después del valor secreto que desea obtener;

inspeccionar, interceptar y modificar los bytes resultantes en el cable.

El escenario principal y casi único en el que se cumplen tales condiciones es un contexto web: el atacante ejecuta un punto de acceso WiFi falso e inyecta un Javascript propio como parte de una página web (HTTP, no HTTPS) que la víctima busca. El malvado Javascript hace que el navegador envíe solicitudes a un sitio HTTPS (por ejemplo, un sitio web del banco) para el cual el navegador de la víctima tiene una cookie. El atacante quiere esa galleta.

Por lo tanto, no es necesario tomar medidas para OpenSSH contra esta amenaza en particular.

Referencias

Más lectura

Vulnerabilidad de SSL3 "Poodle"

— slm
fuente