This article is an automated machine-translation of an article in English. We know the translation isn't perfect, but we hope it's useful for people who don't read English.

Persianas FreeBSD algunos servidores después incumplimiento de claves SSH

Filed Under: Featured, Operating Systems

Venerable BSD sistema operativo basado en FreeBSD distro ha anunciado un compromiso del sistema más bien pequeño.

Los administradores FreeBSD tomó un montón de servidores fuera de línea para investigar, y publicó una cuenta de golpe-por-golpe de lo que saben sobre el incumplimiento hasta el momento.

FreeBSD no es el primer sistema operativo de código abierto que sufrir una intrusión en sus servidores centrales.

Los desarrolladores de Linux famoso sufrido tanto un ataque de malware y un compromiso servidor el año pasado que vio kernel.org desaparecer sin conexión hace más de un mes.

En este caso, sin embargo, el equipo de FreeBSD y sus usuarios no parecen haber sufrido demasiado mal.

Ninguno de los repositorios base llamados fueron tocados - que es donde los componentes básicos, tales como el kernel, las bibliotecas del sistema, compilador, herramientas básicas de línea de comandos y daemons (software servidor) residen. Sólo los servidores de hosting código fuente para paquetes de terceros se vieron afectados.

Afortunadamente, la investigación hasta el momento no ha aparecido ningún paquete de software que se Trojanised por los intrusos. Así que el efecto en cadena de la ruptura en probablemente resultará ser mínimo.

La razón oficial se da como probable un compromiso de clave SSH de un desarrollador.

SSH, o Secure Shell, es el principal protocolo de acceso remoto para sistemas no-Windows.

Es compatible con una amplia gama de esquemas de autenticación, en muchos sistemas, administradores de acabar con nombres de usuarios en todo el alambre y las contraseñas, y optar en su lugar para la autenticación basada en pares de claves públicas / privadas.

La idea es que generar un par de claves y enviar mi clave pública.

Después de verificar cuidadosamente que lo que realmente es mi llave, por ejemplo, con una llamada telefónica, cargar mi clave pública al servidor. Mi cliente SSH se puede utilizar mi clave privada para mí iniciar la sesión, el servidor utiliza la clave pública correspondiente para verificar mi identidad.

Desde mi clave privada es a su vez protegido por una contraseña (o debería ser), que siguen disfrutando de los beneficios de la seguridad basada en contraseñas - además de la ventaja que conocer mi contraseña no es suficiente para un atacante. Él necesita una copia física de mi archivo de clave privada, también.

En este caso, parece como si el atacante se las arregló para robar dos factores de autenticación - archivo de clave y contraseña - desde el desarrollador.

Este es un recordatorio cordial que una cadena es tan fuerte como su eslabón más débil.

En particular, no olvide que la seguridad de sus sistemas internos puede muy bien no ser mejores que la seguridad de los sistemas externos de todos y cada uno - si los servidores, ordenadores portátiles o incluso dispositivos móviles - de los que acepta el acceso remoto.

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog