Conceptos básicos de seguridad Basado en el artículo Seguridad en Linux de Gonzalo Álvarez Marañón y Pedro Pablo Fábrega Martínez

Conceptos básicos de Conceptos básicos de seguridadseguridad

eman ta zabal zazu

Universidad del País Vasco

Euskal Herriko Unibertsitatea

Basado en el artículo Seguridad en Linux de Gonzalo Álvarez Marañón y Pedro Pablo Fábrega Martínez

Conceptos básicos de seguridad 2 de 30

SeguridadSeguridad

• Introducción.• Seguridad Física.• Seguridad Local.• Seguridad del Sistema de Archivos.• Seguridad del Núcleo.• Seguridad de Red. • Links.


IntroducciónIntroducción

• Ante todo Linux es un sistema multiusuario real. Puede haber varios usuarios distintos trabajando a la vez cada uno desde su terminal. El sistema tiene la obligación de proteger a unos usuarios frente a otros y protegerse a sí mismo.

• Linux es una excelente estación de trabajo aislada, pero lo habitual es que cada máquina linux esté conectada a una red y además esté prestando servicios de red. El sistema tiene la obligación de garantizar los servicios que presta.

• La seguridad es un requisito básico, ya que la red global es insegura por definición.

• También queremos remarcar el carácter dinámico de la seguridad de los sistemas en red. Continuamente aparecen nuevos métodos para conseguir accesos indebidos o comprometer el correcto funcionamiento de la red.


Introducción (II)Introducción (II)

• Ningún sistema es "completamente" seguro. El único sistema seguro es aquel que no está conectado en red, que está apagado y encerrado bajo llave.

• Lo único que se puede hacer es aumentar la dificultad para que alguien pueda comprometer la seguridad del sistema.

• También tenemos que tener en cuenta que existe una relación inversa entre seguridad y funcionalidad. Tiene que decidir dónde está el equilibrio entre la facilidad de uso de su sistema y su seguridad.

• Como las fuentes del núcleo de Linux son abiertas, el tiempo que tarda en aparecer la solución para cualquier debilidad se mide más fácilmente en horas que en días.

• Gracias a esto, Linux es conocido por su alto nivel de estabilidad que parte del propio núcleo del sistema operativo (lo que propiamente es Linux).


Seguridad FísicaSeguridad Física

• Hay que tener en cuenta quiénes tienen acceso físico a las máquinas y si realmente deberían acceder.

• El nivel de seguridad física que necesita en su sistema depende de su situación concreta. Un usuario doméstico no necesita preocuparse demasiado por la protección física, salvo proteger su máquina de un niño o algo así. En una oficina puede ser diferente.

• Linux proporciona los niveles exigibles de seguridad física para un sistema operativo: – Un arranque seguro

– Posibilidad de bloquear las terminales

– Por supuesto, las capacidades de un sistema multiusuario real.


Seguridad Física (II)Seguridad Física (II)

• Pantalla de login: el sistema está pidiendo que se identifique. El sistema registra todos los intentos de acceso (fallidos o no), por lo que no pasarán desapercibidos intentos repetidos de acceso no autorizado.

• Se pueden pasar parámetros a LILO para modificar su comportamiento. • Con init single, el sistema se inicia en modo monousuario y

proporciona una shell de root sin contraseña. Para evitarlo, se puede utilizar el parámetro restricted en el fichero de configuración de LILO.

• Este parámetro le permite iniciar normalmente el sistema, salvo en el caso de que se hayan incluido argumentos en la llamada a LILO, que solicita una clave. Esto proporciona un nivel de seguridad razonable: permite iniciar el sistema, pero no manipular el arranque.

• Para mayor seguridad se puede incluir la opción password. De esta forma se necesitará una clave para iniciar el sistema.

Seguridad en el arranque


Seguridad Física (III)Seguridad Física (III)

• Es conveniente poder bloquear la consola cuando nos alejamos de nuestra máquina para que nadie pueda manipularla. Dos programas que hacen esto son xlock y vlock.

• xlock bloquea la pantalla cuando nos encontramos en modo gráfico. En general se puede ejecutar xlock desde cualquier xterm de su consola y bloqueará la pantalla de forma que necesitará su clave para desbloquearla.

• vlock es un simple programa que permite cerrar alguna o todas las consolas virtuales de su máquina Linux. Se puede bloquear sólo aquélla en la que se está trabajando o todas. Si sólo se cierra una, las otras se pueden abrir y utilizar la consola, pero no se podrá usar esa vty hasta que no la desbloquee.

• Desde luego, bloquear una consola prevendrá que alguien manipule nuestro trabajo, pero no previene de reinicios de la máquina u otras formas de deteriorar nuestro trabajo.

Bloqueos de consola


Seguridad LocalSeguridad Local

• Linux es un sistema operativo multiusuario real: puede haber varios usuarios trabajando simultáneamente con él, cada uno en su terminal. Esto obliga a tener en cuenta medidas de seguridad adicionales.

• El mayor porcentaje de violaciones de un sistema son realizadas por usuarios locales. Pero no sólo hay que protegerse de las violaciones intencionadas, sino que el sistema debe protegernos de operaciones accidentales debidas a descuidos o ignorancia de los usuarios.

• En este aspecto de la seguridad, Linux dispone de todas las características de los sistemas Unix: un control de acceso a los usuarios verificando una pareja de usuario y clave; cada fichero y directorio tienen sus propietario y permisos.

Introducción


Seguridad Local (II)Seguridad Local (II)

• Por otro lado, la meta de la mayoría de los ataques es conseguir acceso como root, lo que garantiza un control total sobre el sistema. Primero se intentará conseguir acceso como usuario "normal" para posteriormente ir incrementando sus niveles de privilegio utilizando las posibles debilidades del sistema: programas con errores, configuraciones deficientes de los servicios o el descifrado de claves cifradas.

• Incluso se utilizan técnicas denominadas "ingeniería social", consistentes en convencer a ciertos usuarios para que suministren una información que debiera ser mantenida en secreto, como sus nombres de usuario y contraseñas.

Introducción (II)


Seguridad Local (III)Seguridad Local (III)

• Cada usuario del sistema está definido por una línea en el fichero /etc/passwd y cada grupo por otra línea en el fichero /etc/group. Cada usuario pertenece a uno o varios grupos y cada recurso pertenece a un usuario y un grupo.

• Los permisos para un recurso se pueden asignar al propietario, al grupo y a otros (resto de los usuarios).

• El administrador tiene que conocer las necesidades de cada uno de sus usuarios y asignarle los mínimos privilegios para que pueda realizar su trabajo sin resultar un peligro para otros usuarios o el sistema.

• Otro peligro potencial para el sistema es mantener cuentas abiertas que se han dejado de utilizar. Estas cuentas pueden constituir un buen refugio para un potencial atacante y pasar desapercibidas sus acciones.

Cuentas de usuario, grupos


Seguridad Local (IV)Seguridad Local (IV)

• La seguridad de una sola cuenta puede comprometer la seguridad de todo el sistema.

• Por un lado tenemos que asegurarnos de que nuestros usuarios utilizan claves sólidas: – No deben ser una palabra conocida. – Deberían contener letras, números y caracteres especiales. – Deben ser fáciles de recordar y difíciles de adivinar.

• Existen varios programas que van probando varias palabras de diccionario, claves habituales y combinaciones de caracteres, que son cifrados con el mismo algoritmo que usa el sistema para mantener sus claves; después son comparadas con el valor de la clave cifrada que queremos averiguar hasta que el valor obtenido de un cifrado coincide con una clave cifrada.

Seguridad de las claves


Seguridad Local (V)Seguridad Local (V)

• Usando este mecanismo, al menos podemos garantizar que no estaremos en inferioridad de condiciones con respecto a los atacantes locales.

• Un conocido programa para realizar el descifrado de claves es John the Ripper.

• Por otro lado, las claves cifradas se almacenan en el fichero /etc/passwd. Cualquier usuario del sistema tiene permiso de lectura sobre este fichero. Entonces puede parecer a primera vista que nos encontramos con un grave agujero de seguridad. El atacante, una vez obtenido el fichero /etc/passwd no tiene más que ejecutar su programa “revienta-claves” favorito y sentarse a esperar hasta que empiecen a aparecer nombres de usuario con sus respectivas contraseñas, algo que suele pasar muy rápidamente.

Seguridad de las claves (II)


Seguridad Local (VI)Seguridad Local (VI)

• Con suerte, si el administrador es ingenuo o dejado, incluso dará con la clave del root, abriéndosele así las puertas a la máquina objetivo.

• Para solucionar esta vulnerabilidad, podemos recurrir a contraseñas en la sombra (shadow passwords), un mecanismo consistente en extraer las claves cifradas del fichero /etc/passwd y situarlas en otro fichero llamado /etc/shadow, que sólo puede leer el root y dejar el resto de la información en el original /etc/passwd.

• El fichero /etc/shadow sólo contiene el nombre de usuario y su clave, e información administrativa, como cuándo expira la cuenta, etc.

Seguridad de las claves (III)


Seguridad Local (VII)Seguridad Local (VII)

• En muchas ocasiones un proceso necesita ejecutarse con unos privilegios mayores (o menores) que el usuario que lo lanzó. Por ejemplo, un usuario puede modificar su propia clave con el mandato passwd, pero esto implica modificar el fichero /etc/passwd, y para esto un usuario "de a pie" no tiene permiso. ¿Cómo se soluciona? Pues activando el bit SUID del comando passwd (nótese que cuando esto sucede, la x de ejecutable pasa a ser una s): ls -la /usr/bin/passw* -r-sr-xr-x 1 root bin 15613 abr 27 1998 /usr/bin/passwd

• Esto quiere decir que cuando se ejecute, el proceso correspondiente va a tener los privilegios del propietario del comando (es decir, el root), no del usuario que lo lanzó. En otras palabras, el proceso generado por passwd pertenece a root.

El bit SUID/SGID


Seguridad Local (VIII)Seguridad Local (VIII)

• A primera vista, esto puede parecer una seria brecha de seguridad. Y lo es. Si el programa funciona correctamente, no tiene por qué dar problemas; pero pequeños defectos en el programa pueden ser utilizados por alguien para tratar de ejecutar otro código distinto con los privilegios de este proceso. El método suele ser el desbordamiento de la pila (buffer overflow).

• Cualquier atacante que haya entrado en un sistema de forma ilegítima intentará dejar una shell con el bit SUID para mantener ese nivel de privilegio cuando vuelva a entrar en el sistema.

• SGID es lo mismo que SUID, pero aplicado al grupo. • Así pues, hay que tener cuidado con los programas con el bit

SUID/SGIG. • Nunca hay que escribir scripts de shell SUID

El bit SUID/SGID (II)


Seguridad Local (IX)Seguridad Local (IX)

• En muchas ocasiones el propio administrador destroza el sistema bien por descuido, por exceso de confianza o por ignorancia.

• No usar la cuenta de root por norma. • Ejecutar los comandos de forma segura verificando previamente la

acción que va a realizar. • Ciertos mandatos admiten una opción (-i) para actuar de forma

interactiva. Es conveniente activarla, si no lo está ya añadiendo estas líneas a su fichero de recursos para la shell: – alias rm='rm -i' – alias cp='cp -i' – alias mv='mv -i'

• Siempre puede evitar estas preguntas, con el mandato yes, cuando esté seguro de la operación que está realizando:

$ yes s|rm borrar.*

Seguridad del root


Seguridad Local (X)Seguridad Local (X)

• El directorio actual no está, por defecto, en el PATH. Esto garantiza que no lanzaremos, sin darnos cuenta, un ejecutable que esté en el directorio actual llamado, por ejemplo ls.

• Evitar que la clave del root viaje por una red sin cifrar. Utilizar ssh u otro canal seguro.

• Limitar los terminales desde los que se puede conectar root. Es preferible limitarlo a la consola del sistema (/etc/securetty). Si se necesita una sesión remota como root, entramos como usuario normal y luego usamos su.

• Actuar con cuidado cuando sea root. • Hay herramientas como sudo que permiten a ciertos usuarios utilizar

comandos privilegiados sin necesidad de ser root, como montar o desmontar dispositivos. Registra las actividades que se realizan, lo que ayuda a determinar lo que hace el usuario.

Seguridad del root (II)


Seguridad del Sistema de ArchivosSeguridad del Sistema de Archivos

• Hay que dar a cada usuario sólo los permisos necesarios para poder cubrir las necesidades de su trabajo sin poner en riesgo el trabajo de los demás.

• Cada soporte, disco, partición, disquete o CD tiene su propia organización lógica, un sistema de ficheros. Para poder usar uno de estos soportes tenemos que "montarlo" en un directorio existente. El contenido de la partición nos aparecerá como el contenido del directorio.

• Un primer criterio para mantener un sistema seguro sería hacer una correcta distribución del espacio de almacenamiento. Esto limita el riesgo de que el deterioro de una partición afecte a todo el sistema.

Árbol de directorios


Seguridad del Sistema de Archivos (II)Seguridad del Sistema de Archivos (II)

• Consejos: – Si el sistema va a dar servicio a múltiples usuarios que requieren

almacenamiento para sus datos privados, sería conveniente que el directorio /home tuviera su propia partición.

– Si el equipo va a ser un servidor de correo, impresión, etc., el directorio /var o incluso /var/spool podrían tener su propia partición.

– Algunos directorios son necesarios en la partición raíz. Contienen datos que son necesarios durante el proceso de arranque del sistema. Son /dev/, /etc, /bin, /sbin, /lib, /boot.

– El directorio /usr/local contiene los programas compilados e instalados por el administrador. Resulta conveniente usar una partición propia para proteger estos programas personalizados de futuras actualizaciones del sistema. Este criterio también se puede aplicar al directorio /opt.

Árbol de directorios (II)


Seguridad del Sistema de Archivos Seguridad del Sistema de Archivos

(III)(III)

• Linux, como sistema multiusuario, asigna un propietario y un grupo a cada fichero (y directorio) y unos permisos al propietario, al grupo y al resto de los usuarios.

• El sistema de ficheros tiene que admitir esta característica, como es el caso del sistema de ficheros ext2 (Linux nativo). En los sistemas de ficheros pensados para entornos monousario, como msdos o vfat, no tenemos esta característica, por lo que son inseguros y su uso no es aconsejable bajo Linux.

• Es conveniente tener claros los permisos que se pueden asignar a un fichero o directorio. Puede que algunas aplicaciones no funcionen bien si algún fichero no tiene el permiso o el propietario correctos, bien por falta de permisos o bien por exceso.

Permisos



(IV)(IV)

• Hay que tener cuidado con aquellos directorios que tengan permiso de escritura. Cualquiera podría borrar un fichero, aunque no sea de su propiedad y esto puede ser un riesgo, tanto para el sistema como para los datos de los usuarios.

• Además tenemos otros bits de permisos que no podemos pasar por alto cuando estamos tratando de temas de seguridad.

• Sticky bit: El sticky bit tiene su significado propio cuando se aplica a

directorios. Si el sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son de su propiedad o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios.

Permisos (II)


Seguridad del Sistema de Archivos (V)Seguridad del Sistema de Archivos (V)

• Atributo SUID: (Para Ficheros) Describe el conjunto de permisos de identidad de

usuario sobre el fichero. Cuando el modo de acceso al conjunto de identidad de usuario se configura como permisos de propietario, y el fichero es ejecutable, a los procesos que se ejecutan bajo él se les concede acceso a los recursos del sistema basándose en el usuario dueño del fichero, como opuesto al usuario que ha creado el proceso.

• Atributo SGID : (Para Ficheros) Si se configura en los permisos de grupo, este bit

controla la posición del "paquete de identidad de grupo" de un fichero. Actúa de la misma manera que el SUID, excepto en que es el grupo el afectado. El fichero debe ser ejecutable para que esto tenga algún efecto.

Permisos (III)



(VI)(VI)

• Atributo SGID: (Para directorios) Al poner el bit SGID en un directorio (con chmod

g+s directory), los ficheros creados en ese directorio tendrán su configuración de grupo para el grupo del directorio.

• Scripts de Shell SUID Los scripts de shell SUID son un riesgo importante

de seguridad y por esta razón el núcleo no los acepta. Con independencia de lo seguro que consideremos que es el script de shell, puede ser explotado para dar al cracker un shell de root.

Permisos (IV)



(VII)(VII)

• Una forma cómoda de detectar ataques locales (y también de red) en el sistema es ejecutar un programa que verifique la integridad de la información almacenada en los ficheros, tal como Tripwire

• Tripwire ejecuta varias comprobaciones tipo checksum en todos los ficheros binarios y de configuración importantes y los compara contra una base de datos previa de valores de referencia bien conocidos. De este modo, todos los cambios en los ficheros se notarán.

• Conviene instalar Tripwire en un floppy y protegerlo contra escritura. Así, los intrusos no podrán modificar el Tripwire ni cambiar la base de datos.

Tripwire



(VIII)(VIII)

• Una ataque posible a cualquier sistema es intentar consumir todo el espacio del disco duro. Una primera protección contra este ataque es separar el árbol de directorios en diversos discos y particiones. Pero esto puede no ser suficiente y por eso el núcleo del sistema proporciona la posibilidad de controlar el espacio de almacenamiento por usuario o grupo.

• El sistema de cuotas de Linux permite limitar el número de bloques y el número de i-nodos que un usuario puede tener.

• Hay que comprobar que nuestro núcleo soporta las cuotas de usuario:

# dmesg | grep quotasVFS: Diskquotas version dquot_6.4.0 initialized

Cuotas


Seguridad del núcleoSeguridad del núcleo

• Linux tiene la gran ventaja de tener disponible el código fuente del núcleo; en realidad Linux propiamente dicho es sólo el núcleo. Esto nos permite la posibilidad de crear núcleos a medida de nuestras necesidades. Y parte de nuestras necesidades será la mejora de la seguridad.

• Como el núcleo controla las características de red de su sistema, es importante que el núcleo tenga las opciones que garanticen la seguridad y que el propio núcleo no pueda ser comprometido.

• Habrá que compilar el núcleo con unas opciones u otras dependiendo de las características de nuestro sistema.

Introducción


Seguridad del núcleo (II)Seguridad del núcleo (II)

• Hay algunos dispositivos de bloque y carácter disponibles en Linux que también son útiles para mantener la seguridad de sus sistema.

• Los dos dispositivos /dev/random y /dev/urandom los proporciona el núcleo para generar datos aleatorios en cualquier instante. Por ejemplo, se utilizan para iniciar un número de secuencia para conexiones TCP/IP.

• Ambos, /dev/random y /dev/urandom, deberían ser suficientemente seguros como para generar claves PGP, SSH y otras aplicaciones donde son un requisito números aleatorios seguros para generar claves válidas para una sesión. Los atacantes no deberían ser capaces de determinar el siguiente número dada cualquier secuencia de números con este origen.

Dispositivos del núcleo


Seguridad de RedSeguridad de Red

• SSH (Secure Shell), stelnet: – SSH y stelnet son programas que permiten efectuar conexiones con

sistemas remotos y mantener una conexión cifrada. Con esto evitamos, entre otras cosas, que las claves circulen por la red sin cifrar.

• Cryptographic IP Encapsulation (CIPE): – CIPE cifra los datos a nivel de red. El viaje de los paquetes entre

hosts se hace cifrado. A diferencia de SSH que cifra los datos por conexión, lo hace a nivel de socket. Así un conexión lógica entre programas que se ejecutan en hosts diferentes está cifrada. CIPE se puede usar en tunnelling para crear una Red Virtual Privada. El cifrado a bajo nivel tiene la ventaja de poder hacer trabajar la red de forma transparente entre las dos redes conectadas en la RVP sin ningún cambio en el software de aplicación.

Canales de comunicación seguros


Seguridad de Red (II)Seguridad de Red (II)

• SSL(Secure Sockets Layer): – Diseñado y propuesto en 1994 por Netscape Communications

Corporation junto con su primera versión del Navigator como un protocolo para dotar de seguridad a las sesiones de navegación a través de Internet.

– En su estado actual proporciona los siguientes servicios: • Cifrado de datos: la información transferida es ininteligible. • Autenticación de servidores: el usuario puede asegurarse de la identidad

del servidor al que se conecta. • Integridad de mensajes: se impide que modificaciones intencionadas o

accidentales en la información mientras viaja por Internet pasen inadvertidas.

• Opcionalmente, autenticación de cliente: permite al servidor conocer la identidad del usuario, con el fin de decidir si puede acceder a ciertas áreas protegidas.

Canales de comunicación seguros (II)


LinksLinks

• http://www.iec.csic.es/criptonomicon/seguridad/

• http://www.geocities.com/galinux2000/numero1/doc-es/seguridadelinuxcomo.htm

• http://glub.ehu.es/seguridad/

http://www.iec.csic.es/criptonomicon/seguridad/










http://www.geocities.com/galinux2000/numero1/doc-es/seguridadelinuxcomo.htm













http://glub.ehu.es/seguridad/






Documents

Conceptos básicos de seguridad Basado en el artículo Seguridad en Linux de Gonzalo Álvarez Marañón y Pedro Pablo Fábrega Martínez