Administración de la seguridad en un sistema GNU/Linux

Administración de la seguridad
en un sistema GNU/Linux
Implementación y herramientas
Javier Fernández-Sanguino Peña
[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