Administración de la seguridad en un sistema GNU/Linux Implementación y herramientas ´ ˜ Javier Fernandez-Sanguino Pena [email protected]

UCM-FI Abril 2005 – p. 1

Índice de la presentación ¿Por qué hablar de seguridad en Linux? Implementación de la seguridad en el núcleo de Linux Seguridad en el S.O. Fortificación del S.O. Herramientas de seguridad para Linux Parches de seguridad Certificación Conclusiones

UCM-FI Abril 2005 – p. 2

¿Por qué hablar de seguridad en Linux?

La seguridad es algo difícil, incluso en Linux. Puede ser difícil encontrar buenas fuentes de información. La documentación no siempre es completa. Es una buena oportunidad para hacer preguntas.

UCM-FI Abril 2005 – p. 3

¿Seguridad de sistemas operativos?

"Si yo sólo lo quiero para trabajar" Confidencialidad: sólo las personas autorizadas pueden acceder a la información. Integridad: la información de un sistema no se ve modificada arbitrariamente. Disponibilidad: la información está disponible para aquellos que la deben utilizar. En realidad, la seguridad de un sistema operativo es más compleja. Al final (CC) consiste en definir un "perfil de protección".

UCM-FI Abril 2005 – p. 4

¿Qué es realmente Linux?

Linux es simplemente un núcleo de sistema operativo. Deberíamos hablar en realidad de.... ¿GNU/Linux? ¿Apache/GNU/Linux? ¿OpenSSH/OpenSSL/Apache/GNU/Linux? ¿Ext2/GNU/Linux? También hay múltiples distribuciones de Linux (Debian, Fedora, Mandrake, Red Hat, SuSE...). ¿De cuál hablamos?

UCM-FI Abril 2005 – p. 5

Consideraciones iniciales Los aspectos de diseño del SO son comúnes Linux (el núcleo) incluye funciones de seguridad (SO UNIX) ¿Qué herramientas puedo utilizar? ¿Cómo puedo mantener un sistema seguro? Lo más importante: la seguridad no es un producto, es un proceso (pero sí utilizaremos herramientas)

UCM-FI Abril 2005 – p. 6

Más términos generales

Algunos términos generales aplicables a seguridad en sistemas operativos: Programación segura Minimo privilegio Defensa en profundidad Fortificación

UCM-FI Abril 2005 – p. 7

Algunos datos

La mayoría de los ataques en Internet son indiscriminados y dirigidos a compromenter la seguridad configuraciones por omisión o sistemas no parcheados / inseguros. "Know Your Enemy: Statistics Analyzing the past .. predicting the future" (http://www.honeynet.org/paper/stats) Una instalación de Red Hat 6.2 se comprometió en Internet en menos de 72 horas (año 2000) El menor tiempo en que un sistema fue controlado por un atacante desde que éste se conectó a Internet fue de 15 minutos: MS Windows 98 (año 1999) Tiempo de vida hoy: 4 minutos (MS Windows XP SP1). ¿En el futuro?

UCM-FI Abril 2005 – p. 8

Funciones de seguridad de un núcleo Linux

Un núcleo Linux decente ofrece una serie de funciones de seguridad: Separación de usuarios (multi-usuario) Separación de tareas (multi-tarea) Capacidades POSIX Control de acceso del sistema de ficheros Registros de auditoría Filtrado de tráfico de red (syncookies) Generadores aleatorios puros (necesarios para criptografía) Otras funcionalidades están disponibles externas al núcleo: subsistema LSM (SElinux, LIDS, OpenWall), protección contra sobrecarga de búfer (Exec-shield, PaX), controles MAC (SElinux, RSBAC), ACLs POSIX... UCM-FI Abril 2005 – p. 9

Funcionalidades en el espacio de usuario

Muchos SO basado en GNU/Linux proveen: Mecanismos de autenticación diversos (PAM) Herramientas de auditoría de seguridad (remota o local) Herramientas de control de integridad Herramientas criptográficas Para gestión de certificados: OpenSSL De datos: GPG, EncFS De comunicaciones: OpenSSH, OpenSwan

UCM-FI Abril 2005 – p. 10

Funcionalidades en el espacio de usuario (y II)

Herramientas de bastionado automático Herramientas de análisis forense Herramientas para pruebas de intrusión Programas para análisis automático de código Más de una herramienta para la misma tarea Lo más importante: con código fuente (son auditables y mejorables)

UCM-FI Abril 2005 – p. 11

¿Es seguro un S.O. estándar GNU/Linux

No existe un S.O. estándar Hay 10 distribuciones grandes y 346 distribuciones de menor rango. Algunos fabricantes están más enfocados en hacer un sistema fácil que un sistema seguro. usability Puedes elegir: quieres un sistema orientado al usuario e inseguro como Linspire o una distribución orientada a la seguridad como Adamantix. Existen además distribuciones enfocadas a tareas concretas: servidores de correo, servidores web, cortafuegos...

UCM-FI Abril 2005 – p. 12

¿Es seguro un S.O. estándar GNU/Linux? (II)

La mayor parte de los fabricantes hacen un diseño con consideraciones de seguridad (especialmente tras el gusano Ramen/Lion): Reducir la exposición (sin servicios de red en la instalación básica) Separación de privilegios (no ejecutar como root) Auditorías de código Nuevas (o mejores) herramientas de gestión de la seguridad. Pero nada es perfecto, todo se puede mejorar...

UCM-FI Abril 2005 – p. 13

Fortificación de una instalación GNU/Linux Cosas a considerar: ¿Qué tienes? ¿Para qué lo quieres utilizar? ¿Cuáll es tu política de seguridad? (¿Tienes una?) ¿Hasta dónde quieres llegar en la fortificación? (cual es tu nivel de paranoia) ¿Cómo quieres hacerlo? ¿Cómo vas a revisar el nivel de seguridad a lo largo del tiempo?

UCM-FI Abril 2005 – p. 14

Fortificación del sistema Pasos comúnes (valen para cualquier S.O.): Instalación específica para el propósito (empezar con poco...) Particionado en función de necesidad. Instalación de software necesario, nada más. Configuración de autenticación y administración básica. Instalación de servicios y aplicaciones adicionales. Actualización del sistema: Parches recomendados y de seguridad. A veces necesaria conexión a red (¡preparate!)

UCM-FI Abril 2005 – p. 15

Fortificación del sistema (II)

Revisión de la seguridad del sistema. Fortificación de lsistema: Eliminación de servicios no necesarios Restricciones adicionales a los servicios (jaulas, capacidades, mínimo privilegio...) Revisión y volver a fortificar. Herramientas de gestión de la seguridad y auditoría (detectar ataques, mantener el nivel de seguridad)

UCM-FI Abril 2005 – p. 16

Aplicación del principio "defensa en profunidad"

Defensa en profundidad significa que se utilizan distintas barreras para bloquear un ataque de forma que si el una barrera falla no se compromete el sistema. Por ejemplo, para proteger al sistema frente a ataques desde una red de comunicaciones: Eliminar servicios no necesarios en el sistema ... Pero ¿y si alguien los activa de nuevo? (descuido, parche mal instalado...) Desinstalar los servicios... Pero podrían instalarse de nuevo Filtrar acceso a servicios con tcpwrappers... Pero no todos los servicios lo utilizan Filtrar el acceso a servicios con reglas de filtrado en el núcleo... Pero ¿y si se pierden las reglas del cortafuegos? Realizar comprobaciones periódicas para determinar si hay nuevos servicios de red. ... UCM-FI Abril 2005 – p. 17

Fortificación automática: Herramientas Algunos cambios son aburridos y repetitivos, es mejor que lo haga una herramienta (si funciona bien): Bastille (www.bastille-linux.org): una herramienta interactiva de fortificación. Ayuda a implementar una política de seguridad guiando al administrador a través de distintas preguntas. Portable y robusta. Titan (www.fish.com/titan): una herramienta automática de fortificación "en masa". Algunas distribuciones ofrecen la posibilidad de definir un nivel de seguridad. Nota: a veces sólo cambia las reglas de filtrado de red. UCM-FI Abril 2005 – p. 18

Herramientas de seguridad

Una vez fortificado (o antes de hacerlo) existen una serie de herramientas que pueden ser de ayuda: Parches de seguridad para el núcleo Herramientas de auditoría de seguridad (remota o local) IDS (basados en host o en red) Sistemas de gestión de parches Sistemas de comprobación de integridad Otros sólo serán útiles más adelante (análisis forense, copias de seguridad) o para otros propósitos específicos (herramientas para romper contraseñas, herramientas para pruebas de intrusión, redes trampa...)

UCM-FI Abril 2005 – p. 19

Auditorías de seguridad

Del RFC2828 (Glosario de Seguridad en Internet) auditoría de seguridad (I) Una revisión y análisis independiente de los registros y actividades en un sistema para determinar si los controles implantados son adecuados, asegurar el cumplimiento de las políticas y procediminetos de seguridad definidos, detectar intrusiones en los servicios y recomendar cambios que sean necesarios para implantar contramedidas. [I7498 Part 2, NCS01]

UCM-FI Abril 2005 – p. 20

Herramientas de auditoría de seguridad

Análisis remoto: Nessus (sondeo de vulnerabilidades), nmap (sondeo de puertos) Análisis y revisión local: Herramientas específicas: Tiger, checksecurity, sec-check, msec Herramientas de fortificación: Bastille, Titan Otras herramientas más específicas: LSAT, OVAL

UCM-FI Abril 2005 – p. 21

Detección de intrusos La detección de intrusos en un SO se puede implementar a distintos niveles: Basada en host: Auditoría del núcleo Análisis de integridad del sistema de ficheros Análisis de actividades "sospechosas" Basada en red: Inspección de los paquetes que se envían (a cualquier sistema) Inspección de los paquetes que recibe el sistema

UCM-FI Abril 2005 – p. 22

Herramientas de IDS de red

Snort es la principal herramienta de detección de intrusos basada en red para sistemas GNU/Linux (y se incluye en muchas distribuciones) Algunas otras son: arpwatch, psad, ippl (no utilizar portscand)

UCM-FI Abril 2005 – p. 23

Herramientas de IDS de host En el espacio de usuario: Comprobaciones rutinarias: checksecurity (en distribuciones Linux y BSD) Analisis de ficheros de registro: logcheck, log-analysis,logsnorter Comprobaciones de integridad del sistema de ficheros (hashes, permisos..): tripwire, aide, integrit samhain, bsign. También lo hacen los sistemas de gestión de paquetes (rpm y dpkg) Problemas de configuración: Nabou Otros: chkrootkit, checkps, adeos, dtk UCM-FI Abril 2005 – p. 24

Un vistazo a una herramienta genérica HIDS: Tiger

Sistema de detección de intrusos basado en host Modular: múltiples pruebas para detectar desviaciones de la política definida. Comprobaciones de: permisos en el sistema de ficheros, ficheros de configuración $PATH, actividad de usuarios, servicios de red.. Puede interopera con otras herramientas (tripwire, john, chkrootkit...) Doble uso: herramienta de auditoría (ejecutar una vez y obtener un informe), detección de intrusos (periodicamente, comprobar con resultados previos) UCM-FI Abril 2005 – p. 25

Herramientas de IDS de host - núcleo

LIDS (http://www.lids.org/) Parche al núcleo Implementa monitor de referencia También MAC (Mandatory Access Control) Puede ser utilizado para detectar intrusiones cuando éstas intentan hacer uso de capacidades que no pueden utilizar.

UCM-FI Abril 2005 – p. 26

Parcheando el sistema Degragación de la seguridad con el tiempo (salen nuevas vulnerabilidades o nuevos tipos de vulnerabilidades) Determinar si tienen que aplicarse parches a un sistema (priorizar vulnerabilidades) Verificar el origen de un parche (firmas digitales) Verificar que el parche no cambia el nivel de seguridad (instala nuevas cosas o cambia la configuración) Actualmente: herramientas de gestión de parches = gestión de paquetes. up2date (Red Hat), apt (Debian), apt-rpm, urpmi (Mandrake), apt4rpm (SuSE)...

UCM-FI Abril 2005 – p. 27

Certificación de Seguridad

La certificación del sistema operativo es importante en algunos entornos (militar, guvernamental). Certificaciones Common Criteria de productos basados en Linux: Cortafuego: Watchguard, Stonegate SuSE Linux Enterprise Server 8 - CAPP/EAL3+ (Diciembre 2003), previamente EAL2 (agosto 2003) Red Hat Enterprise Linux AS/ES/WS 3 - EAL2 (febrero 2004) a estas le seguirán otras distribuciones en el futuro probablemente (ltp.sourceforge.net) Certificación de procesos de seguridad Mitre ofrece la certificación CVE para servicios de vulnerabilidades compatibles con CVE Debian y Red Hat son compatibles CVE. Mandrake y Gentoo en proceso.

UCM-FI Abril 2005 – p. 28

Conclusiones finales La seguridad en un SO Linux puede ser como tú quieras que sea: estricta o laxa. El núcleo dispone de funciones muy avanzadas de seguridad. Cada distribución ofrece una perspectiva distinta a la seguridad: aprender a mejorar. Muchas herramientas sw libre de seguridad incluidas (o desarrolladas para), algunas portadas. Mejoras constantes (Darwinianas) ¿Auditoría de código?

UCM-FI Abril 2005 – p. 29

Gracias ¡Gracias!

¿(Más) Preguntas?

UCM-FI Abril 2005 – p. 30

Referencias adicionales Linux Security HOWTO, Kevin Fenzi y Dave Wreski, http://www.linuxsecurity.com/docs/LDP/Security-HOWTO/ Secure Programming for Linux and Unix HOWTO, David A. Wheeler, disponible en http://www.dwheeler.com/secure-programs Securing and Optimizing Linux: The Ultimate Solution, Gerhard Mourani http://www.openna.com/products/books/sol/solus.php Securing Debian Manual, Javier Fernández-Sanguino, http://www.debian.org/doc/manuals/securing-debian-howto/ Linux Security Overview, ISSA-PS 2003, Brian Hatch, http://www.ifokr.org/bri/presentations/issa-2003/ Linux: The Securable Operating System, Brian Hatch, http://www.ifokr.org/bri/presentations/lfnw-2003/

UCM-FI Abril 2005 – p. 31

y más referencias...

http://www.linuxsecurity.com http://www.linuxquestions.org/ (Security Forum) http://www.bastille-linux.org/jay/security-articles-jjb.html

UCM-FI Abril 2005 – p. 32