Ejemplo de seguridad de la vida real de SELinux?

11

¿Alguien puede dar un ejemplo de la vida real de dónde SELinux guardó su tocino de seguridad? (o AppArmour si lo desea). Si no es el tuyo, ¿un puntero a alguien con una experiencia creíble?

No es una prueba de laboratorio, no es un documento técnico, no es una práctica recomendada, no es un aviso del CERT, sino un ejemplo real, algo así como audit2 ¿por qué muestra un intento de piratería real detenido en seco?

(Si no tiene ningún ejemplo, guarde comentarios en los comentarios en lugar de Respuestas).

¡Gracias!

linux security selinux

— kmarsh
fuente

Hay una condición en esta pregunta que es difícil de responder. El problema es que cuando los sistemas no están comprometidos, no son noticia. Solo aparecen en las noticias cuando están comprometidos. Y entonces, hay noticias sobre muchos sistemas CentOS comprometidos, que se vieron comprometidos exactamente porque sus administradores deshabilitaron SELinux porque no quieren molestarse en aprender cómo configurarlo y mantenerlo. Si no hubieran deshabilitado SELinux, no habrían sido comprometidos.

— Juliano

Gracias, pero no estaba buscando noticias tanto como experiencias personales reales.

— kmarsh

5

¿Qué tal esto de Russell Coker ? Es un ejemplo de la vida real, ya que ha invitado a todos a su máquina como root. A primera vista, pensé que esto era una locura, pero luego te das cuenta del poder de SELinux para hacer que la raíz sea algo inútil.

Aquí hay algunos ejemplos de la vida real de su sitio.

— keithosu
fuente

1

Interesante. En el primer enlace, regala acceso a la raíz pero (supongo) se bloquea con SELinux casi todo lo que la raíz normalmente podría hacer. Si bien esta es una computadora real, califica para la vida real solo de la misma manera que lo hace un programa de televisión. ¿Cuántos SysAdmins configurarían una máquina de esta manera? El segundo enlace es más lo que estoy buscando. Los revisaré. ¡Gracias!

— kmarsh

4

SELinux no se trata necesariamente de protección contra hackers; se trata de documentar y aplicar políticas sobre cómo se comporta un sistema. Es una herramienta en la caja de herramientas que es valiosa, pero requiere habilidad para usarla bien.

Un ejemplo de la vida real de cómo te salva es algo como esto:

Una vulnerabilidad en un demonio FTP permite que un usuario anónimo obtenga privilegios de root. Un atacante usa esa vulnerabilidad para acceder a los directorios de inicio de los usuarios y robar claves privadas SSH, algunas de las cuales no tienen una frase de contraseña.

Si SELinux está configurado para no permitir la política "Permitir que los servicios ftp lean y escriban archivos en los directorios de inicio de los usuarios", la explotación no tendrá éxito y se registrará la violación de la política.

— duffbeer703
fuente

2

Ese no es un ejemplo de la vida real, es un ejemplo de cómo podría ser un ejemplo de la vida real. Es un ejemplo hipotético de la vida real. Lo cual el OP no pidió.

— Jürgen A. Erhard

3

Aquí hay una descripción detallada de un ataque que SELinux detuvo en seco, con detalles de registro y una explicación de las técnicas forenses utilizadas. Tengo este artículo publicado en Linux Journal:

http://www.linuxjournal.com/article/9176

Aquí hay un extracto del principio:

Si opera servidores conectados a Internet, es probable que eventualmente tenga que lidiar con un ataque exitoso. El año pasado, descubrí que a pesar de las defensas de varias capas en un servidor web de prueba (targetbox), un atacante había logrado utilizar un exploit en un intento parcialmente exitoso de obtener acceso. Este servidor ejecutaba Red Hat Enterprise Linux 4 (RHEL 4) y el sistema de gestión de contenido Mambo. Tenía múltiples defensas en su lugar, incluido Linux con seguridad mejorada (SELinux). SELinux evitó que el atacante ejecutara la segunda etapa del ataque, posiblemente evitando un compromiso de raíz.

Este artículo presenta un estudio de caso de la respuesta a la intrusión, explicando cómo descubrí la intrusión, qué pasos tomé para identificar el exploit, cómo me recuperé del ataque y qué lecciones aprendí con respecto a la seguridad del sistema. He cambiado los nombres de las máquinas y las direcciones IP por razones de privacidad.

— obscurerichard
fuente