¿Por qué es necesaria la seguridad?

Linux es un sistema multiusuario, ya que en él pueden haber varios usuarios trabajando a la vez, cada uno desde su terminal. Por lo tanto el sistema debe proteger a unos usuarios de otros y también protegerse a sí mismo. Además con la generalización de Internet y el rápido desarrollo del software la seguridad se está convirtiendo en algo cada día más importante. Cuando enviamos cierta información desde un cierto sistema informático X a otro sistema Y, esta información pasa por distintos puntos donde puede ser interceptada o modificada por otros usuarios de la red si disponen de los medios adecuados, realizando algo que nos puede resultar perjudicial. Además con la masificación de Internet se han reducido notablemente los costes de un atacante para asaltar un sistema en red, a la vez que aumentan el número de potenciales atacantes.

¿Cómo de seguro es seguro?

Ningún sistema es "completamente" seguro, tan sólo aquel que no está conectado, que esta apagado y cerrado bajo llave. Lo único que podemos hacer es aumentar la dificultad para que alguien pueda comprometer la seguridad de nuestro sistema. También cabe destacar en este punto que no todos los mismos sistemas tienen el mismo riesgo de ser asaltados, o dicho de otro manera, que no todos los usuarios tienen la misma necesidad de seguridad de sus entornos. Además, seguridad y funcionalidad son factores inversamente proporcionales, por lo que se tiene que decidir donde está el equilibrio entre "seguro" y  "fácil de usar" de nuestro sistema.

¿Qué queremos proteger?

En un sistema informático hay tres elementos básicos que proteger que son el software, el hardware y los datos. Normalmente el elemento que más nos preocupará son los datos, porque también es lo más difícil de recuperar. Normalmente se querrá garantizar que el sistema permanezca en funcionamiento de forma adecuada y que nadie pueda obtener o modificar una información a la que no tiene derecho legítimo. Una buena planificación ayuda bastante a conseguir los niveles de seguridad que pretendemos. Antes de intentar asegurarse un sistema, debería determinarse contra qué nivel de amenaza se quiere proteger, qué riesgo se acepta o no y, como resultado, cómo de vulnerable es el sistema. Riesgo es la posibilidad de que un intruso pueda intentar acceder con éxito a nuestro equipo. ¿Puede un intruso leer y escribir en ficheros o ejecutar programas que puedan causar daño?¿Pueden borrar datos críticos?  Recuérdese también que alguien que obtenga acceso a nuestro sistema también puede hacerse pasar por nosotros. 

La vulnerabilidad describe el nivel de protección de nuestro equipo frente a otra red, y la posibilidad potencial para alguien que pueda obtener acceso no autorizado.  ¿Cuánto tiempo me llevaría recuperar/recrear cualquier dato que se ha perdido? Una inversión en tiempo ahora puede ahorrar diez veces más de tiempo con posterioridad si se tienen que recrear los datos que se perdieron.

Requisitos de seguridad

La seguridad pretende que los sistemas informáticos que utiliza una entidad se mantengan en funcionamiento según los requisitos de la política establecida por la propia entidad. Cada entidad define una serie de servicios que pretende obtener de una red de ordenadores para prestarlos a unos usuarios legítimos. Básicamente los requisitos de seguridad se pueden resumir en una serie de puntos ilustrativos: -    DISPONIBILIDAD: consiste en poder acceder a cualquier información del sistema en cualquier momento. La disponibilidad es muy fácil de atacar y muy complicada de mantener en entornos abiertos. -   INTEGRIDAD: consiste en mantener la información en buen estado y sin que haya sido manipulada por quien no deba. Consiste normalmente en realizar una serie de copias de seguridad y en controlar el acceso a dicha información. -     AUTENTICIDAD: Tiene como objetivo establecer con seguridad el origen de la información, es decir que la información sea auténtica. Es relativamente fácil de proveer, pero puede ocasionar problemas. Muy ligado a este concepto se encuentra el "no repudio", que consiste en que la persona que haya manipulado una información no pueda negarlo. -    CONFIDENCIALIDAD: se trata de que la información mantenga un carácter privado a personas ajenas a la propiedad de la información. Es un objetivo muy importante que se consigue restringiendo el acceso( mediante el uso de software o de herramientas físicas) a  la información mediante la criptografía, que nos permite esconder la información.

¿De quien nos queremos proteger?

Hay varios tipos de amenazas para un sistema informático y que se pueden clasificar según dos criterios, el primero de ellos nos permite clasificar las amenazas basándonos en el efecto, aquí encontramos la intercepción, que ocurre cuando alguien entra en un sitio al que no tiene acceso; en la modificación, además de interceptar los datos son modificados; la interrupción que consiste en interrumpir un proceso; o la generación, que consistiría por ejemplo en añadir códigos a un programa, datos a una base de datos..., esta última es la manera de actuar de los virus. Por otro lado las amenazas también se pueden clasificar según el origen. Aquí aparecen en primer lugar las amenazas naturales o físicas, que podrían

encuadrarse dentro de las amenazas como involuntarias; y por otro lado las intencionadas, que son las más importantes. En este último caso puede tratarse de personas(curiosos, maliciosos, interesados...) o de amenazas programadas           ( virus, gusanos, bombas lógicas....) Hay que decir que el tema de las amenazas da mucho más de sí, pero hablar de amenazas no es el objetivo de mi trabajo así que a partir de aquí pasaré a tratar el tema de la seguridad en Unix más a fondo.

¿Seguridad en Unix?

En la primera mitad de la década de los ochenta Unix era un sistema operativo muy vulnerable e inseguro, pero a final de los ochenta, los sistemas Unix se constituyen  de los más seguros que existen. De entre los sistemas Unix cabe destacar una rama conocida como los Trusted Unix, ente los que se encuentran el ATT&T system V/MLS o el OSF/1. Estos son sistemas altamente seguros, que alcanzan niveles de seguridad A o B por la NSA(National Security Agency) americana. La otra gran parte de sistemas Unix como Solaris, Linux o AXT, están considerados con niveles de seguridad C2. En definitiva que Unix a pasado de ser un sistema totalmente arcaico en cuanto a seguridad a ser uno sin duda de los más seguros que existen con un alto nivel de fiabilidad. No obstante dentro del mundillo de la informática hay mucha gente que sigue pensando que hay sistemas Unix como Linux que no son seguros ya que se pueden obtener gratuitamente, pero lo son sólo como se instalan por defecto, pero después de una mínima puesta a punto en cuanto a seguridad serán sistemas altamente fiables. Estas personas optan normalmente por sustituir sus sistemas Unix por WindowsNT o Windows9x, pero basta mirar alguna comparativa de seguridad entre ambos sistemas para darnos cuenta que están equivocados. 

índice

SEGURIDAD FÍSICA

 Las primeras medidas de seguridad que se han de tener en un sistema Unix son medidas de seguridad física, es decir, hay que tener controlado quien tiene acceso físico a la máquina y si realmente debería tenerlo. El nivel de seguridad física de un sistema depende de su situación concreta, habrá sistemas que precisen de un alto nivel de seguridad física y otros que no deban preocuparse prácticamente por este aspecto, como por ejemplo un usuario doméstico que tan sólo debe protegerlo de un niño o de algo por el estilo. De todos modos, Unix proporciona unos niveles de seguridad física altamente fiables, como son un arranque seguro, la posibilidad de bloqueo de la consola y todas las propiedades de un sistema multiusuario real. 

Vamos a tratar en primer lugar el arranque seguro: Cuando alguien inicia el sistema Unix se encuentra con la petición de login: el sistema está pidiendo que se identifique. Si es un usuario conocido para el sistema podrá iniciar una sesión y trabajar con el sistema, pero si no lo es, no tendrá opción de hacer absolutamente nada. Además, el sistema registra todos los intentos de acceso (fallidos o no), por lo que no pasarán desapercibidos intentos repetidos de acceso no autorizado. LILO (Linux Loader) es el encargado de cargar el sistema operativo en memoria y pasarle información para su inicio. A su vez, nosotros podemos pasarle parámetros a LILO para modificar su comportamiento.Por ejemplo, si alguien en el indicador de LILO añade init single, el sistema se inicia en modo monousuario y proporciona una shell de root sin contraseña. Si en nuestro entorno de trabajo creemos necesario evitar que alguien pueda iniciar el sistema de esta forma, deberíamos utilizar el parámetrorestricted en el fichero de configuración de LILO (habitualmente /etc/lilo.conf). Este parámetro nos 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. Si se tiene mayores necesidades de seguridad puede incluir la opción password. De esta forma necesitará una clave para iniciar el sistema. En estas condiciones, sólo podrá iniciar el sistema quien conozca la clave. Otras cuestiones que podrían resultarnos útiles son por ejemplo preparar un disco de arranque del sistema. Simplemente se tiene que copiar el núcleo del sistema operativo en el disco, sin sistema de ficheros, e indicarle cual es la partición raíz del sistema.

# dd if=/boot/vmlinuz of=/dev/fd0 # rdev /dev/fd0 /dev/hdXY

Suponiendo que estemos usando un disco duro IDE, X indica el disco (a ,b , c, o d), Y indica la partición (1,2,...). Pero hay que tener en cuenta que ningún sistema es realmente seguro si alguien, con los     conocimientos necesarios, puede usar nuestro propio disco para arrancar. Hablaremos ahora sobre el bloqueo de la consola: En los entornos Unix es conocido el truco de ejecutar en una terminal, que alguien ha dejado inocentemente abierto, un guión que simule la pantalla de presentación al sistema. Entonces un usuario incauto introducirá su nombre y clave, que quedarán a merced del autor del engaño. Si nos alejamos de nuestramáquina de vez en cuando, estaría bien poder bloquear nuestra consola para que nadie pueda manipularla o mirar nuestro trabajo. Dos programas que hacen esto son xlock y vlock. 

-xlock bloquea la pantalla cuando nos encontramos en modo gráfico. Está incluido en la mayoría de las distribuciones Linux que soportan X. En general 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 le permite cerrar alguna o todas las consolas virtuales de su máquina Linux. Puede bloquear sólo aquélla en la que está trabajando o todas. Si sólo cierra una, las otras se pueden abrir y utilizar la consola, pero no se podrá usar su vty hasta que no la desbloquee. Desde luego, bloquear una consola prevendrá que alguien manipule su trabajo, pero no previene de reinicios de la máquina u otras formas de deteriorar su trabajo

indice

SEGURIDAD LOCAL

Introducción

Cuentas de usuario, grupos

Seguridad de las claves

El bit SUID/SGID

Seguridad del root

Introducción

Las máquinas Unix son sistemas operativos 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. Además, según hablan las estadísticas, 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, las características de los sistemas Unix son el control de acceso a los usuarios verificando una pareja de usuario y clave, y que cada fichero y directorio tienen sus propietario y permisos. 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. En este apartado de seguridad local lo que se pretende es dar unas ideas generales de los riesgos existentes, mecanismos para su solución y unas directrices de actuación que deberían convertirse en hábitos cotidianos.

Cuentas de usuarios, grupos

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). Ahora bien, para mantener un sistema seguro, pero funcional, tendremos que realizar las combinaciones necesarias entre el propietario y grupo de un recurso con los permisos de los propietarios, grupos y otros. Por ejemplo, la unidad de disco flexible tiene las siguientes características:

r-- 1 root floppy 2,0 may 5 1998 /dev/fd0 

-Propietario: root con permiso de lectura y escritura. -Grupo: floppy con permiso de lectura y escritura. -Otros: resto de los usuarios con permiso de lectura.

Cuando queramos que un usuario pueda escribir en la unidad de disco, sólo tendremos que incluirlo en el grupo floppy. Cualquier otro usuario que no pertenezca al grupo floppy (salvo root) sólo podrá leer el disquete. 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. Los valores que traen por defecto las distribuciones de Linux son suficientes para mantener el sistema seguro. 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.

Seguridad de las claves

La seguridad de una sola cuenta puede comprometer la seguridad de todo el sistema. Esto es una realidad ante la que debemos protegernos. Por un lado tenemos que asegurarnos 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. Para comprobar que este requisito se verifica en nuestro sistema, podemos usar los mismos mecanismos que utilizan los atacantes. 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. Posteriormente notificaremos al usuario que su clave es débil y le solicitaremos que la modifique. 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. Lo que es peor, agujeros en los navegadores permiten que se puedan leer ficheros arbitrarios de una máquina (evidentemente, que el usuario de navegador tenga permiso para leer), de manera que lleguen hasta un hacker que cree páginas web que exploten estos agujeros. 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 revientaclaves 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. 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. El formato del fichero /etc/shadow es similar al siguiente:

usuario : clave : ultimo : puede : debe : aviso : expira : desactiva : reservado

-usuario: El nombre del usario.  -clave: La clave cifrada -ultimo: Días transcurridos del último cambio de clave desde el día 1/1/70 -puede: Días transcurridos antes de que la clave se pueda modificar. 

-tiene: Días transcurridos antes de que la clave tenga que ser modificada. -aviso: Dias de aviso al usuario antes de que expire la clave. -expira: Días que se desactiva la cuenta tras expirar la clave. -desactiva: Días de duración de la cuenta desde el 1/1/70. -reservado: sin comentarios.

Un ejemplo podría ser:

sergio : gEvm4sbKnGRlg : 10627 : 0 :  99999 : 7 : -1 : -1 : 134529868 

El paquete de Shadow Passwords se puede descargar desde cualquiera de los siguientes sitios, con instrucciones para su instalación: -ftp://i17linuxb.ists.pwr.wroc.pl/pub/linux/shadow/shadow-current.tar.gz -ftp://ftp.icm.edu.pl/pub/Linux/shadow/shadow-current.tar.gz -ftp://iguana.hut.fi/pub/linux/shadow/shadow-current.tar.gz -ftp://ftp.cin.net/usr/ggallag/shadow/shadow-current.tar.gz -ftp://ftp.netural.com/pub/linux/shadow/shadow-current.tar.gz Para activar contraseñas en la sombra, se tiene que ejecutar pwconv como root; acción que creará nuestro fichero /etc/shadow. Hasta ahora hemos visto diversas situaciones en las que podemos aumentar la seguridad usando una clave. Hay que tener en cuenta que tenemos que recordar cada una de las claves que utilizamos, no se debe nunca anotar nuestra clave en un papel (y menos pegarla a la pantalla). En alguna situación olvidar una clave puede ser un serio problema.

El bit SUID/SGID

En muchas ocasiones un proceso debe ser lanzado con unos privilegios mayores o menores que el usuario que lo lanzó. Por ejemplo, un usuario puede querer modificar su clave de acceso mediante el comando passwd, pero hacer esto implica que sea modificado el fichero /etc/passwd, y para ello un usuario de "a pié" no tiene permiso. Este problema se soluciona activando el bit SUID del comando passwd . Cuando ésto sucede, la x de ejecutable pasará a ser una s(más abajo se verán con más detalle los permisos en el sistema

de ficheros): 

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. 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.Se pueden encontrar con :

root# find /-type f \( -perm -04000 -o -perm -02000 \) -print 

Se debe tener en cuenta que algunos programas (como passwd) tienen que tener el bit SUID. Hay que compruebe en los lugares habituales que ninguno de los programas propiedad del root o SUID que utilizamos en nuestro sistema, tiene un fallo de seguridad conocido que pueda ser explotado. Nunca debemos permitir que quede una shell SUID corriendo en el sistema. Si el root deja desatendida la consola durante unos instantes (recuérdese que se debe utilizar siempre xlock), un intruso podría escribir lo siguiente:

# cp /bin/sh /tmp/cuenta-root # chmod 4755 /tmp/cuenta-root

creándose una versión SUID de la shell sh. En el futuro, cuando el atacante ejecute ese programa, cuenta-root, ¡se convertirá en root! Si lo escondiera en un directorio oculto, la única forma de encontrarlo sería escaneando el sistema completo. Por último hay que recordar que nunca se deben escribir guiones de shell SUID.

Seguridad del Root

Los peores destrozos de un sistema es probable que no vengan de ningún cracker, o de un malévolo intruso. En muchísimas más ocasiones ha sido el propio administrador el que ha destrozado el sistema. Sí, el root. ¿Por qué? Por descuido, por exceso de confianza, por ignorancia. Evitar este problema no es difícil. Siguiendo unas fáciles normas, el administrador podrá protegerse de si mismo: -No usar la cuenta de root por norma. 

-Intentar primero cualquier acción como un usuario normal, y si ve que no tiene permiso, pensar porqué y usar el comando su si es necesario. -Ejecutar los comandos de forma segura verificando previamente la acción que se va a realizar. Por ejemplo si quiere ejecutar rm borrar.*, ejecute primero ls borrar.* y si es lo que pretende modifique el mandato y ejecútelo.  -Ciertos mandatos admiten una opción (-i) para actuar de forma interactiva. Actívarla, si no lo está ya añadiendo estas líneas a el fichero de recursos para la shell:

alias rm='rm -i'  alias cp='cp -i'  alias mv='mv -i'

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

$ yes s|rm borrar.*

-El directorio actual no está, por defecto, en la ruta de búsqueda de ejecutables (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. Utilice ssh u otro canal seguro. -Limitar los terminales desde los que se puede conectar root. Es preferible limitarlo a la consola del sistema. Esto se puede decidir en /etc/securetty. Si se necesita una sesión remota como root, entrar como usuario normal y luego usar su. -Actúar de forma lenta y meditada cuando sea root. Nuestras acciones podrían afectar a un montón de cosas. Hay herramientas como "sudo" que permiten a ciertos usuarios utilizar comandos privilegiados sin necesidad de ser root, como montar o desmontar dispositivos. Además registra las actividades que se realizan, lo que ayuda a determinar qué hace realmente este usuario.

índice

SEGURIDAD DEL SISTEMA DE FICHEROS

Introducción

El árbol de directorios

Permisos de ficheros y directorios

Verificar la integridad con Tripwire

Limitar el espacio

Normas prácticas para aumentar la seguridad

Introducción

Dentro de un sistema Unix todo son archivos, desde la memoria física del sistema hasta el ratón; este diseño potenciara mucho a Unix pero también es muy peligroso, ya que un simple fallo al dar los permisos a los distintos ficheros y podríamos facilitar que cualquier usuario modifique todo el disco duro. Estos archivos pueden ser de tres tipos:  

-Ficheros planos: son simplemente secuencias de bytes que sólo tienen sentido para las aplicaciones que interpretan su contenido. -Directorios: son ficheros cuyo contenido son otros ficheros que pueden ser de cualquier tipo, incluso otros directorios. -Ficheros especiales: representan dispositivos del sistema y se pueden dividir en orientados a carácter(realizan las operaciones de input/output byte a byte) y orientadas a bloque(las realizan en bloques de bytes).

Cada sistema Unix tiene su sistema de ficheros por lo que para acceder igual a todos ellos, Uníx incorpora una capa superior llamada VFS. Es aquí donde aparece el concepto de inodo, que es una estructura de datos que relaciona un grupo de bloques de un dispositivo con el nombre de un sistema de ficheros . Internamente, Unix no distingue sus archivos por el nombre, sino por el número de inodo. Cuando se arranca un sistema Unix es obligado incorporar almenos un sistema de ficheros a la jerarquía de ficheros del sistema, esto se realiza normalmente mediante la orden mount. Para saber que sistemas se han montado al arranca una máquina Unix, el sistema utiliza un archivo cuyo nombre varía según el sistema Unix que utilicemos (/etc/vfstab en Solaris, /etc/fstab en Linux. . . ), su función - e incluso su sintaxis - es siempre la misma.  

El árbol de directorios

Para quienes no estén familiarizados con las características del sistema de almacenamiento de información en sistemas Unix, hay que indicar que se organizan en un único árbol de directorios. 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. La pérdida se limitaría al contenido de esa partición. No hay unas normas generales aplicables; el uso al que vaya destinado el sistema y la experiencia son las bases de la decisión adecuada, aunque sí que se pueden dar algunos 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/spoolpodrí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.

Permisos de los ficheros y directorios

Unix es un sistema multiusuario que asigna un propietario y un grupo a cada fichero (a partir de ahora me referiré como fichero a los ficheros planos) o directorio, así como una serie de permisos al propietario, al grupo y al resto de usuarios. Una forma muy rápida de comprobar esta característica es usar el comando ls -la. De esta forma nos aparece el tipo de fichero, el propietario, el grupo y alguna información adicional. Por supuesto, el sistema de ficheros tiene que admitir esta característica, como es el caso del sistema de ficheros ext2 (Linux nativo). 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. Como decíamos anteriormente, tenemos que asegurarnos de que los ficheros del

sistema y los de cada usuario sólo son accesibles por quienes tienen que hacerlo y de la forma que deben. No sólo hay que protegerse de ataques o miradas indiscretas, también hay que protegerse de acciones accidentales. Tanto el propietario como el grupo són únicos para cada fichero o directorio. Eso sí, a un grupo pueden pertenecer múltiples usuarios. Todas estas características se almacenan en un inodo.Vamos a ver a hora la organización de los permisos en un sistema Unix:

Propiedad: Qué usuario y grupo posee el control de los permisos del inodo. Se almacenan como dos valores numéricos, el uid (user id) y gid (group id). Permisos: Bits individuales que definen el acceso a un fichero o directorio. Los permisos para directorio tienen un sentido diferente a los permisos para ficheros. Más abajo se explican algunas diferencias.

Lectura (r): -Fichero: Poder acceder a los contenidos de un fichero -Directorio: Poder leer un directorio, ver qué ficheros contiene

Escritura (w): -Fichero: Poder modificar o añadir contenido a un fichero -Directorio: Poder borrar o mover ficheros en un directorio

Ejecución(x): -Fichero: Poder ejecutar un programa binario o guion de shell -Directorio: Poder entrar en un directorio Estos permisos se pueden aplicar a: -usuario (u): El propietario del fichero -grupo (g): El grupo al que pertenece el fichero -otros (o): El resto de los usuarios del sistema

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.

drwxrwxrwt 19 root root 8192 Jun 24 14:40 tmp  Attributo SUID: (Para Ficheros)

Este bit describe permisos al identificador de usuario del fichero. Cuando el modo de acceso de ID de usuario está activo en los permisos del propietario, y ese fichero es ejecutable, los procesos que lo ejecutan obtienen acceso a los recursos del sistema basados en el usuario que crea el proceso (no el usuario que lo lanza). Por ejemplo /usr/bin/passwd es un ejecutable propiedad de root y con el bit SUIDactivo. ¿Por qué? Este programa lo puede usar cualquier usuario para modificar su clave de acceso, que se almacena en 

-rw-r--r-- 1 root root 1265 Jun 22 17:35 /etc/passwd 

pero según los permisos que observamos en este fichero, sólo root puede escribir y modificar en él. Entonces sería imposible que un usuario pudiera cambiar su clave si no puede modificar este fichero. La solución para este problema consiste en activar el bit SUID para este fichero: -r-s--x--x 1 root root 10704 Apr 14 23:21 /usr/bin/passwd 

de forma que cuando se ejecute, el proceso generado por él es un proceso propiedad de root con todos los privilegios que ello acarrea. ¿Esto puede ser un riesgo para la seguridad? Efectivamente lo podría ser si no mantenemos un mínimo de atención, ya que en este tipo de programas se pueden producir desbordamiento de buffer que comprometan nuestro sistema. Hay que recordar siempre lo siguiente: -No asignar el bit SUID salvo cuando sea estrictamente necesario. -Comprobar que cualquier programa con este bit activo no tiene ningún desbordamiento de buffer (conocido).

Atributo SGID: (Para ficheros) Si está activo en los permisos de grupo, este bit controla el estado de "poner id de grupo" de un fichero. Actúa de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algún efecto.

Atributo SGID: (Para directorios) 

Si activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrán puesto su grupo como el grupo del directorio. A continuación se describen los significados de los permisos de acceso

individuales para un fichero. Normalmente un fichero tendrá una combinación de los siguientes permisos:

-r-------- Permite acceso de lectura al propietario

--w------- Permite modificar o borrar el fichero al propietario

---x------ Permite ejecutar este programa al propietario, (los guiones de shell también requieren permisos de lectura al propietario)

---s------ Se ejecutará con usuario efectivo ID = propietario

-------s-- Se ejecutará con usuario efectivo ID = grupo

-rw------T No actualiza "instante de última modificación". Normalmente usado para ficheros de intercambio (swap)

---t------ No tiene efecto. (antes sticky bit)

A continuación se describen los significados de los permisos de acceso individuales para un directorio. Normalmente un directorio tendrá una combinación de los siguientes permisos: dr-------- Permite listar el contenido pero no se pueden leer los atributos.

d--x------ Permite entrar en el directorio y usar en las rutas de ejecución completas.

dr-x------ Permite leer los atributos del fichero por el propietario.

d-wx------ Permite crear/borra ficheros.

d------x-t Previene el borrado de ficheros por otros con acceso de escritura. Usado en /tmp

d---s--s-- No tiene efecto

Los ficheros de configuración del sistema (normalmente en /etc) es habitual que tengan el modo 640 (-rw-r-----), y que sean propiedad del root. Dependiendo de los requisitos de seguridad del sistema, esto se puede modificar. Nunca hay que dejar un fichero del sistema con permiso de escritura para un grupo o para otros. Los sistemas de ficheros de tipo Unix permiten crear enlaces entre ficheros. Los

enlaces pueden ser duros o simbólicos: -Un enlace duro consiste en asignar más de un nombre a los mismos datos en disco. Un enlace duro no consume más espacio adicional que el que pueda representar el nuevo nombre que le damos a unos datos y sólo es válido para ficheros que estén en el mismo sistema de ficheros, es decir, la misma partición. -Los enlaces simbólicos son ficheros que apuntan a otro fichero o directorio. Crean un nuevo fichero pequeño que contiene la ruta del fichero destino

Verificar la integridad con Tripwire

Una forma cómoda de detectar ataques locales (y también de red) en un sistema es ejecutar un programa que verifique la integridad de la información almacenada en los ficheros, tal como Tripwire. El programaTripwire ejecuta varios cheksums de todos los binarios importantes y ficheros de configuración y los compara con una base de datos con valores de referencia aceptados como buenos. Así se detecta cualquier cambio en los ficheros. Es buena idea instalar tripwire en un disquete y protegerlo físicamente. De esta forma no se puede alterartripwire o modificar su base de datos. Una vez que tripwire se ha configurado, es buena idea ejecutarlo como parte de de los deberes habituales de administración para ver si algo ha cambiado. Incluso se puede añadir una entrada a crontab para ejecutar tripwire desde su disquete todas las noches y enviar por correo los resultados y verlos por la mañana, algo como esto:

MAILTO=sergio 15 05 * * * root /usr/local/bin/tripwire

queenviará por correo un informe cada mañana a las 5:15 am. Tripwire puede ser una de la mejores herramientas para detectar intrusos antes de que tenga otro tipo de noticias de ellos. Como son muchos los ficheros que se modifican en un sistema, hay que tener cuidado para discernir lo que es la actividad de un cracker y lo que es la activiadad normal del sistema.

Limitar el espacio

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. Lo primero que tendríamos que hacer es asegurarnos de que nuestro núcleo tiene soporte para las cuotas de usuarios.

# dmesg | grep quotas VFS: Diskquotas version dquot_6.4.0 initialized

En caso contrario, el núcleo no ha sido compilado con soporte para el sistema de cuotas para usuarios. En este caso será necesario compilar un nuevo núcleo Linux. El resto del procedimiento de instalación se puede realizar utilizando la documentación existente. Ahora es necesario editar el fichero /etc/fstab y añadir usrquota o grpquota en la partición o particiones en las que nos interese limitar el espacio de almacenamiento. El siguiente ejemplo establece el sistema de cuotas para el uso del directorio /home montado en la partición /dev/hda3:

/dev/hda3 /home ext2 defaults,usrquota 1 2 

Ahora podemos recopilar la información de las particiones donde se haya definido el sistema de cuotas. Podemos usar el comando:

/sbin/quotachek -av 

Scanning /dev/hda3 [/home] done Checked 215 directories and 2056 files Using quotafile /home/quota.user Updating in-core user quotas

Al ejecutar este comando también se crea un fichero llamado quota.user o quota.grp en la partición o particiones afectada(s).

# ls -la /home/quota.user -rw------- 1 root root 16224 Feb 04 14:47 quota.user

Ya está activo el sistema de cuotas y la próxima vez que se inicie el sistema, se activarán automáticamente en todas las particiones que se hayan definido. Ya no será necesario volver a ejecutar manualmente este comando, ya que el sistema lo hara de forma automática al comprobar y montar cada uno de los sistemas de ficheros desde el fichero/etc/rc.d/rc.sysinit. El siguiente paso es definir la cuotas para cada usuario. Para ello existen dos métodos. El primero consiste en editar la cuota de cada usuario. Por ejemplo, para editar la cuota del usuarioantonio, se ejecuta desde el usuario root el comando:

# edquota -u antonio Quotas for user antonio: /dev/hda3: blocks in use:15542,limits (soft=0,hard=0) inodes in use: 2139, limits (soft = 0, hard = 0)

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. Los valores a modificar son los límites que están puestos entre paréntesis (que ahora valen 0). Ahí se puede especificar cualquier cantidad (en Kbytes). Por ejemplo, para limitar la cuota de disco del usuario antonio a 1 Mb, se pondría lo siguiente:

Quotas for user antonio: /dev/hda7:blocks in use:18542,limits (soft=1024,hard=1024) inodes in use: 1139, limits (soft = 0, hard = 0)

El límite soft es un límite de aviso y el límite hard es un límite insalvable, es decir, el sistema ya no le asigna más espacio. De una forma análoga, podríamos modificar la cuota de espacio asignada al grupo users con: # edquota -g users    

Normas prácticas para aumentar la seguridad

Aunque sea necesario tener claros los conceptos y dedicarle algo de tiempo a una correcta planificación, tampoco los peligros expuestos tienen por qué asustar a nadie. Todas las distribuciones Unix traen unos valores por defecto que son más que razonables para cubrir unas necesidades normales.

-nosuid, nodev, noexec. 

Salvo casos excepcionales, no debería haber ninguna razón para que se permita la ejecución de programas SUID/SGID en los directorios home de los usuarios. Esto lo podemos evitar usando la opción `nosuid' en el fichero /etc/fstab para las particiones que tengan permiso de escritura por alguien que no sea el root. También puede ser útil usar `nodev' y `noexec' en las particiones de los directorios personales de los usuarios y en /var, lo que prohíbe la creación dispositivos de bloque o carácter y la ejecución de programas.

-Sistemas de ficheros en red Si queremos exportar sistemas de archivos vía NFS, hay que estar seguro de configurar /etc/exports con los accesos lo más restrictivos posibles. Esto significa no usar plantillas, no permitir acceso de escritura a root y montar como sólo lectura siempre que sea posible.

-umask Se debe configurar la máscara de creación de ficheros para que sea lo más restrictiva posible. Son habituales 022, 033, y la más restictiva 077, y añadirla a /etc/profile. El comando umask se puede usar para determinar el modo de creación de ficheros por defecto en un sistema. Es el complemento octal a los modos de fichero deseado. Si los ficheros se crean sin ningún miramiento de estado de permisos, el usuario, de forma inadvertida, podrá asignar permisos de lectura o escritura a alguien que no debería tenerlos. De forma típica, el estado de umask incluye 022, 027 y 077, que es lo más restrictivo. Normalmente umask se pone en /etc/profile y por tanto se aplica a todos los usuarios del sistema. Por ejemplo, puede tener una línea parecida a la siguiente:

# Pone el valor por defecto de umask del usuario umask 033

El valor umask de root es 077, lo cual desactiva los permisos de lectura, escritura y ejecución para otros usuarios, salvo que explícitamente se use chmod(1). Si se está usando , y se utiliza un esquema de creación de idetificador de grupos y usuarios (User Private Groups), sólo es necesario usar 002 para umask. Esto se debe a que al crear un usuario se crea un grupo exclusivo para ese usuario.

-Limitar recursos Se deben poner límites al sistema de ficheros en lugar de 'ilimitado' como está por defecto. Se puede controlar el límite por usuario utilizando el módulo PAM de límite de recursos y /etc/pam.d/limits.conf. Por ejemplo, los límites para un grupo `users' podría parecerse a esto:

@users hard core 0 @users hard nproc 50 @users hard rss 5000

Esto dice que se prohiba la creación de ficheros core, restringe el número de procesos a 50, y restringe el uso de memoria por usuario a 5M.

-wtmp, utmp Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexión de todos los usuarios de su sistema. Se debe mantener su integridad, ya que determinan cuándo y desde dónde entró en el sistema un usuario o un potencial intruso. Los ficheros deberían tener los permisos 644, sin afectar a la operación normal del sistema.

-Sticky bit Elsticky bit se puede usar para prevenir borrados accidentales o proteger un fichero para sobreescritura. También previene que alguien cree enlaces simbólicos a un fichero, que ha sido el origen de ataques basados en el borrado de los ficheros/etc/passwd o /etc/shadow.

-SUID y SGID Los ficheros SUID y SGID de un sistema son potenciales riesgos de seguridad y deberían ser controlados. Como estos programas garantizan privilegios especiales al usuario que los ejecuta, es necesario estar seguro que no hay instalados programas inseguros. Un truco favorito de los crackers es explotar programas con el bit SUID y entonces dejar un programa SUID como puerta trasera para entrar la próxima vez, incluso aunque el agujero original ya esté tapado. Hay que encontrar todos los programas SUID/SGID de un sistema y mantener la pista de lo que son, para estar prevenido de cualquier cambio que podría indicar un potencial intruso. El siguiente comando sirve para localizar todos los progrmas SUID/SGID en un sistema:

root# find / -type f \( -perm -04000 -o -perm -02000 \) 

Incluso se podría crear una base de datos de progrmas SUID con

root# find / -type f \( -perm -04000 -o -perm -02000 \)>/var/suid 

y posteriormente verificar si ha aparecido alguno nuevo con el siguiente guión:

for fich in `find / -type f \( -perm -04000 -o -perm -02000 \)` do if ! grep $fich /var/suid then echo "$fich es un nuevo fichero con SUID" fi done echo "Actualiza la base de datos si es necesario"

-Permisos de escritura Los ficheros con permiso de escritura global, particularmente los del sistema, pueden ser un agujero de seguridad si un cracker obtiene acceso a su sistema y los modifica. Además, los directorios con permiso de escritura global son

peligrosos, ya que permiten a un cracker añadir y borrar los ficheros que quiera. Para localizar los ficheros con permiso de escritura global, se usa el siguiente comando:

root# find / -perm -2 -print 

y hay que estar seguro de saber por qué tienen esos permisos de escritura. En el curso normal de una operación los ficheros tendrán permisos de escritura, incluidos algunos de /dev y enlaces simbólicos.

-Ficheros extraños Los ficheros sin propietario también pueden ser un indicio de que un intruso ha accedido a su sistema. Se pueden localizar los ficheros de su sistema que no tienen propietario o que no pertenecen a un grupo con el comando:

root# find / -nouser -o -nogroup -print 

-Ficheros peligrosos

La localización de ficheros .rhosts debería ser uno de los deberes regulares de la administración de un sistema, ya que estos ficheros no se deberían permitir en nuestro sistema. Recuerdese que un cracker sólo necesita una cuenta insegura para potencialmente obtener acceso a toda nuestra red. Se pueden localizar todos los ficheros .rhosts de su sistema con el siguiente comando:

root# find /home -name .rhosts -print   

indice

SEGURIDAD DEL NÚCLEO

Introducción

Opciones de compilación

Dispositivos del núcleo

Introducción  

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. Para compilar el núcleo primero tendremos que configurar las opciones que nos interesen. Los fuentes del núcleo se guardan habitualmente en el directorio /usr/src/linux, y una vez situados en él, tendremos que ejecutar «make menuconfig» (o «make xconfig» si estamos en modo gráfico). Así nos aparecen todas las opciones de configuración. Dentro de ellas nos vamos a fijar en las que están relacionadas con la seguridad, viendo una breve explicación de lo que hacen y cómo se usan. Como el núcleo controla las características de red de nuestro sistema, es importante que el núcleo tenga las opciones que garanticen la seguridad y que el propio núcleo no pueda ser comprometido. Para prevenir algunos de los últimos ataques de red, deberemos intentar mantener una versión del núcleo actualizada. Una de las características más interesantes del núcleo Linux es la posibilidad de realizar enmascaramiento de direcciones. Con esta técnica podremos dar acceso a Internet a una red local con direcciones privadas de forma transparente, es decir, sin ningún tipo de modificación en la configuración de las aplicaciones clientes, a diferencia de los proxies clásicos. Consiste en que el sistema Linux que posee la conexión hacia el exterior recibe las peticiones de conexión desde los equipos de la red local que tienen direcciones no válidas para Internet. El equipo Linux rehace la petición poniendo su propia dirección IP y modificando el puerto al que tiene que responder el equipo remoto. Cuando Linux recibe la respuesta del equipo remoto, mira el puerto al que va destinado y vuelve a rehacer el paquete para enviarlo al equipo concreto de la red local que solicitó la conexión. De esta forma podemos mantener un nivel aceptable de protección para los equipos de la red local, ya que sólo podrán recibir respuestas a peticiones que ellos mismos originaron.

Opciones de compilación

IP: Drop source routed frames (CONFIG_IP_NOSR)Esta opción debería estar activada. Source routed frames contienen la ruta completa de los destinos dentro del paquete. Esto significa que los enrutadores a través de los que circula el paquete no necesitan inspeccionarlo, y sólo lo reenvían. Esto podría ocasionar que los datos que entran a un sistema puedan ser un exploit potencial.IP: Firewalling (CONFIG_IP_FIREWALL)Esta opción es necesaria si va a configurar la máquina como un cortafuegos, hacer enmascaramiento o se desea proteger la estación de trabajo con línea telefónica de que alguien entre a través de un interfaz PPP. Con esta opción activa podremos usar el filtrado de paquetes en el propio núcleo del sistema, decidiendo el tráfico que llega o sale de nuestro equipo.IP: forwarding/gatewaying (CONFIG_IP_FORWARD)

Si activa reenvío IP (IP forwarding), nuestro Linux esencialmente se convierte en un encaminador (router). Si la máquina está en una red, podríamos estar enviando datos de una red a otra, y quizás saltándonos un cortafuegos que esté puesto allí para evitar que esto suceda. A los usuarios con un puesto aislado y conexión telefónica les interesará desactivar esta característica. Otros usuarios deberían pensar en las implicaciones de seguridad de hacer esto en su caso concreto. Las máquinas que actúen como cortafuegos tendrán que activar esta característica y usarla junto al software cortafuegos. Se puede activar y desactivar el reenvío IP (IP forwarding) dinámicamente usando el siguiente comando:  root# echo 1 > /proc/sys/net/ipv4/ip_forwardACTIVAR root# echo 0 > /proc/sys/net/ipv4/ip_forwardDESACTIVAR

Ese fichero (y muchos otros ficheros de /proc) aparecerá con longitud cero, pero en realidad no es un fichero en el sentido clásico, sino que son datos guardados en memoria. IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE)

Esta opción suministra información sobre los paquetes que nuestro cortafuegos recibe, como remitente, destinatario, puerto, etc. Así podremos rastrear los orígenes de los posibles intentos de ataque.IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)Generalmente esta opción está desactivada, pero si se está construyendo un host cortafuegos o para enmascaramiento, deberemos activarla. Cuando se envían paquetes de un host a otro, no siempre se envían como simples paquetes de datos, sino que se fragmentan en varios trozos. El problema es que los números de puerto sólo se almacenan en el primer fragmento. Esto significa que alguien puede insertar información en el resto de los paquetes para la conexión que se supone que no deberían estar allí.IP: syn cookies (CONFIG_SYN_COOKIES)El ataque SYN es un ataque de denegación de servicio (denial of service, DoS) que consume todos los recursos de nuestra máquina forzando un reinicio. No podemos encontrar ninguna razón por la que no debieramos activar esto.

Dispositivos del núcleo

 Hay algunos dispositivos de bloque y carácter disponibles en Linux que tambiénresultan útiles para mantener la seguridad de un 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. Se han dedicado muchos esfuerzos para garantizar que los números que se obtienen de esta fuente son pseudoaleatorios en todos los sentidos de la palabra pseudoaleatorio. La única diferencia es que /dev/random suministra bytes aleatorios y hace esperar para que se acumulen más. Obsérvese que en algunos sistemas se puede bloquear durante un rato a la espera de que se genere una nueva entrada de usuario al sistema. Por lo tanto se debe tener cuidado al usar /dev/random. (Quizás lo mejor que se puede hacer es usarlo cuando se esté generando información sensible de claves e indicarle al usuario que pulse una tecla repetidas veces hasta que indique por la pantalla "Ya es suficiente"). -/dev/random tiene gran calidad de entropía, midiendo tiempos entre interrupciones, etc. Bloquea hasta que hay disponibles suficientes bits de datos aleatorios. -/dev/urandom es parecido, no es tan seguro, pero suficiente para la mayoría de las aplicaciones. Se puede leer los dispositivos usando algo parecido a lo siguiente:

root# head -c 6 /dev/urandom | uuencode -

Esto imprimirá seis caracteres aleatorios en la consola, válidos para la generación de una clave.

indice

SEGURIDAD DEL ROOT

Introducción

Hábitos seguros

Consejos

Introducción

A menudo, el mayor enemigo del sistema es el propio administrador del sistema, sí, tiene todos los privilegios y cualquier acción puede ser irreversible y hacernos perder posteriormente mucho más tiempo que el que hubieramos perdido por realizar las tareas de forma segura. Puede borrar cualquier fichero e incluso destruir el propio sistema, mientras que un usuario «normal» sólo puede

perjudicarse a sí mismo. Por estos motivos, conseguir privilegios de root es la meta de cualquier ataque. Tampoco hay que alarmarse. En un sistema operativo monousuario cualquiera podría darle formato al disco duro y perder toda la información almacenada o borrar cuaquier fichero necesario para el funcionamiento del sistema. En un sistema estilo Unix, como Linux, esto sólo lo podría hacer el usuarioroot.

Hábitos seguros

La seguridad del administrador es simple, en mayor medida consiste en tener unos hábitos seguros y también en utilizar herramientas seguras. Una primera norma que siempre deberíamos tener presente es usar la cuenta de root sólo para realizar tareas concretas y breves y el resto hacerlo como usuario normal. Es una costumbre muy peligrosa usar todo el tiempo la cuenta de root. Al principio, a los usuarios de Linux les gusta sentir todo el poder de la cuenta de root, les molesta que su propio sistema les deniegue el permiso para hacer algo, pero van cambiando de opinión poco a poco, conforme se van familiarizando con el sistema o cuando han realizado un destrozo de esos que nos hacen proferir insultos contra nosotros mismos acompañados de un desesperado puñetazo en la mesa (o en el teclado). Cuando el sistema nos deniega alguna operación es porque puede conllevar algún riesgo. El sistema nos avisa para que pensemos dos veces lo que estamos haciendo: En los casos de tareas que necesiten privilegios de administrador para realizar una operación concreta, podemos usar la orden «su» (Super Usuario) o también «sudo». De esta forma podremos acceder a los privilegios de root sólo cuando nos interese.

Consejos

Asegúrarse de que en los borrados de ficheros por parte del root se pide confirmación. Esto lo podemos hacer poniendo «alias rm="rm -i"». Esto es lo habitual para el root. Si en alguna ocasión tenemos que borrar muchos ficheros y no queremos confirmar cada uno de ellos, puede usar la opción «-f» para no pedir confirmación, deshacer el alias con «alias rm=rm» o bien usando la orden «yes», poniendo «yes|rm ficheros» para ir confirmando automáticamente cada una de las preguntas de la orden. Procurar prever los resultados de una orden, intentándolo antes de una forma no irreversible. Por ejemplo, si se quieren borrar todos los ficheros terminados en «~» ejecutar primero «ls -la *~» y una vez que hayamos verificado a qué va a afectar la orden, ejecute «rm *~». Vigilar la variable de entorno «PATH». Limitar la búsqueda automática de ejecutables a las ubicaciones estándar del sistema. De forma particular evitar

incluir el directorio actual, es decir «.», en esta búsqueda. Bastaría incluir un ejecutable llamado «ls» en un directorio para que nosotros mismos ejecutáramos un código desconocido con privilegios de root, y cuando nos diéramos cuenta de lo que hemos hecho sea demasiado tarde. Además, no debemos tener directorios con permiso de escritura en nuestra ruta de búsquedas, ya que esto puede permitir a un posible atacante modificar o poner nuevos binarios que se puedan ejecutar como root la próxima vez que ejecutemos una determinada orden. No utilizar las herramientas rlogin/rsh/rexec como root. Pueden ser objeto de diversos tipos de ataques y es peligroso ejecutarlas como root. Nunca crear un fichero.rhosts para root. Evitar que la clave del root circule por la red sin cifrar. Si tenemos la necesidad de ofrecer servicios de shell o ejecución remotas sobre un canal inseguro utilizar «ssh» en lugar de «telnet» u otra herramienta que no cifre los datos de las conexiones. Los servicios remotos como «rlogin», «rsh» y «rexec» no suelen ser seguros si se utilizan canales no seguros. Es mejor deshabilitarlos. Limitar las ubicaciones desde donde alguien se puede conectar como root al sistema. En el fichero /etc/securettyse puede especificar la lista de terminales desde los cuales se puede conectar el root. Los terminales predeterminados para conectarse como root sólo incluyen las consolas virtuales (vtys). Si tuvieramos que conectarnos como root desde una ubicación distinta a la consola, deberíamos hacerlo como usuario normal primero y luego utilizar «su» para acceder a los privilegios de root. De esta forma un posible atacante tendría que conocer el nombre de un usuario del sistema, conocer su clave y también conocer la clave del root. Esto pone más dificultades para obtener privilegios remotos en nuestro sistema. 

Evitar siempre dar la clave de root, no hacerlo bajo ningún concepto por mucha confianza que se tenga con una persona. Si se tienen que otorgar privilegios a algún usuario para realizar alguna tarea de administración, como montar un CD u otro dispositivo similar, utilizar «sudo» para permitirlo con la propia clave del usuario. Así se puede decidir qué usuario tiene acceso a una determinada orden. No modificar los permisos de un fichero o directorio si no sabe realmente qué se está haciendo. Los valores que trae la instalación de las distintas distribuciones suelen ser adecuados. NO conectarse jamás a un servicio IRC como usuario root.

indice

COPIAS DE SEGURIDAD

Introducción

Consejos

Utilización de   tar

Utilización de   cpio

Introducción

Existen varios tipos de problemas que pueden resultar en la pérdida de datos: borrado accidental de archivos, fallos del hardware, información importante que deja de estar disponible... En estos casos los usuarios de un sistema Unix necesitan tener la confianza de poder acceder a una copia de seguridad de los archivos perdidos. La copia de archivos no es una actividad muy atractiva, pero ningún administrador debe ignorarlas. Las copias de seguridad en un sistema pueden ser completas o progresivas. Las copias de seguridad completas copian cada uno de los archivos, esto es un proceso muy costoso y requiere de una gran cantidad de dispositivos de almacenamiento. Por su parte las copias de seguridad progresivas solo copian aquellos archivos que se han modificado desde la última copia de seguridad. Hay que asegurarse de tener copias actualizadas de todos los sistemas de archivos. Existen muchos tipos de dispositivos para la realización de copias de seguridad, como cintas magnéticas, disquetes, CD-Rom o el mismo disco duro entre otros. Los comandos más utilizados para la realización de las copias de seguridad son dos comandos muy sencillos: tar y cpio. Es importante etiquetar todo el material copiado de manera que se pueda utilizar para recuperar archivos cuando sea necesario. Algunos procedimientos y comandos permiten preparar una tabla de contenidos o una lista del material del que se ha realizado una copia de seguridad.

Consejos

Hay que preparar un programa de copias de seguridad que detalle los archivos a salvaguardar, la frecuencia con la que se van a realizar dichas copias y la forma de la que se van a restaurar los archivos. Verificar siempre las copias de seguridad. La comprobación puede consistir, por ejemplo, en la lectura de una tabla de contenidos del medio urtilizado para realizar la copia de seguridad, o en la reatauración de un archivo elegido al azar. Hacer las copias de seguridad de forma que los archivos puedan restaurarse en cualquier lugar del sistema de ficheros o en otro sistema informático. Etiquetar todos los medios usados. Se debe planificar pensando en lo peor. Almacenar las copias en un lugar diferente a donde se encuentre el propio sistema informático. 

Planificación de unprograma de copias de seguridad: La situación ideal sería poder restaurar cualquier archivo en cualquier momento, aunque desgraciadamente eso no es posible. A continuación se muestra una planificación fijada a partir de las definiciones de copia de seguridad completa y copia de seguridad progresiva definidas anteriormente: Día 1copia de seguridad completa Día 2copia de seguridad progresiva Día 3copia de seguridad progresiva Y así sucesivamente.  

Utilización de tar

La orden tar puede utilizarse para copiar a cualquier tipo de dispositivo. Es fiable, estable y sencilla de utilizar. No puede realizar copias de algunos archivos especiales, como por ejemplo los archivos de dispositivos. De por si, sólo puede realizar copias de seguridad completas, se tendría que hacer algún programa en shell para que realizara copias de seguridad progresivas. A continuación se muestra un ejemplo de cómo se copiaría el directorio /home a la unidad de disquete /dev/fd0:

tar cf /dev/fd0 /home

A continuación se muestran algunas de las opciones de tar más comunes: c:crea un contenedor x:extrae o restaura archivos desde el contenedor que se encuentra en el dispositivo predeterminado o en el dispositivo especificado en la opción f. f: namecrea el contenedor o lee el contenedor desde name, donde name es un nombre de fichero o de un dispositivo especificado en /dev. Z:Comprime o descomprime el contenedor tar z:comprime o descomprime el contenedor tar con gzip M:crea una copia de seguridad tar de nivel múltiple t:Crea un índice de todos los archivos almacenados en un contenedor v:modalidad detallada El comando siguiente también archiva al directorio /home:

tar cvfzM /dev/fd0

La opción v indica la modalidad detallada; la opción z indica que debería comprimirse el archivo para ahorrar espacio; y la opción M pide a tar que genere una copia de seguridad de volumen múltiple. Cuando un disquete está completo, tar indica que se inserte otro. Se envía una lista de los archivos copiados a

homeindex. Es una buena idea examinar este archivo para ver que se ha copiado. También puede utilizarse el comando tar para crear archivos de contenedor en el sistema de archivos, en lugar de escribir en un dispositivo de comandos de seguridad. Para ello se debe dar el nombre de un fichero a la opción f, en lugar del nombre de un dispositivo. Por ejemplo:

tar cvf /home/backup.tar /home/dave

Esta orden crea el archivo /home/backup.tarque contiene una copia de seguridad del fichero /home/dave, y todos los ficheros y subdirectorios por debajo del mismo.

Utilización de cpio

Cpio es un comando de uso generalizado para copiar contenedores de archivos. Se puede usar para crear copias de seguridad utilizando la opción -o, o para restaurar archivos utilizando la opción -i. La orden cpio puede hacer copias de seguridad de cualquier juego de archivos( también de archivos especiales), almacena información de una forma más efectiva que tar, se salta sectores defectuosos o bloques erróneos al restaurar datos y además sus copias de seguridad se pueden restaurar en casi cualquier sistema Unix. Pero la sintaxis de cpio es más compleja que la de tar, y es necesario programar en shell para realizar copias de seguridad progresivas. A continuación se muestran las opciones más importantes de cpio: -ocopiar fuera. Crea un archivo en la salida estándar -BBloquea entrada o salida a 5120 bytes por registro. Útil para almacenamiento eficiente en cinta magnética -icopiar dentro. Extrae archivos de entradas estándar -tcrea una tabla de contenidos de la entrada A continuación se muestra un ejemplo de cómo se copiaría el directorio /home a la unidad de disquete /dev/fd0:

ls/home | cpio -o > /dev/fd0 

El ejemplo siguiente extrae los archivos del dispositivo /dev/fd0 y crea un índice en el archivo bkup.indx:

cpio -it < /dev/fd0 > bkup.indx

En resumen, la realización de copias de seguridad regulares de un sistema es un proceso crítico para la protección de datos. Un programa de copias de seguridad puede hacer que restaura un sistema en caso de ataque o de pérdida de datos por

cualquier otro motivo sea mucho más sencillo. Los comandos tar y cpio proporcionan la capacidad para realizar copias de seguridad del sistema.

indice

POLÍTICAS DE SEGURIDAD

Introducción

Análisis de riesgos

Estrategias de respuesta

Introducción

Política de seguridad se define como el conjunto de requisitos definidos por los responsables de un sistema que indica en términos generales qué está y qué no está permitido en el área de seguridad durante la operación general de dicho sistema. Las políticas de seguridad pueden ser prohibitivas (prohíben todo aquello que no está expresamente permitido) o permisivas (permiten todo aquello que no está expresamente prohibido). Las políticas de seguridad prohibitivas son mucho más seguras que las permisivas, ya que se contemplan todas las actividades permitidas por el sistema y el resto son ilegales. Finalmente cabe reseñar que toda política debe cumplir los requisitos de confidencialidad, integridad, disponibilidad y autenticidad ya definidos anteriormente, así como los de utilidad (Los recursos del sistema y la información manejada en el mismo ha de ser útil para alguna función) y posesión(Los propietarios de un sistema han de ser capaces de controlarlo en todo momento; perder este control en favor de un usuario malicioso compromete la seguridad del sistema hacia el resto de usuarios).

Análisis de riesgos

Lo primero que debe hacer una política de seguridad es conocer y evaluar los riesgos a los que se enfrenta e implementar soluciones prácticas para minimizar los daños. En primer lugar se deben identificar todos aquellos recursos que pueden ser dañados, estos son el hardware, el software y la información almacenada. Una vez identificados estos recursos se debe intentar identificar todas las amenazas y vulnerabilidades del sistema informático. Las amenazas aprovechan las vulnerabilidades del sistema para atacarle por ahí, de modo que un sistema sin vulnerabilidades será un sistema sin amenazas. Las amenazas se suelen dividir en: 

-    Desastres del entorno, como son las catástrofes naturales, desastres producidos por elementos cercanos al sistema como un corte de la electricidad; y por último peligros relacionados con operadores, programadores o usuarios de sistema. -    Amenazas de sistema, que son todas las vulnerabilidades del equipo y su software, como puede ser un fallo del sistema operativo, un fallo de un programa, copias de seguridad.. -    Amenazas en la red,  cada día más numerosas por el desarrollo de la comunicación en red, especialmente de Internet. Normalmente cuando hablamos de amenazas solemos pensar en piratas informáticos ya que son los que más se oyen en los medios de comunicación, pero hay muchas más amenazas, muchas de las cuales pueden ser involuntarias, como apagar el ordenador sin guardar el fichero en el que se estaba trabajando. Una vez conocidos los recursos a proteger, así como las vulnerabilidades y amenazas del sistema, hemos de estudiar como proteger nuestro sistema sin pasar todavía a la implementación, ya que esto ya serían mecanismos de seguridad y estamos hablando de políticas. En primer lugar debemos cuantificar los daños que nos causaría un posible ataque, basándonos en ataques que hayan sucedido con anterioridad y evaluando los daños que causaron. La clasificación de riesgos de cara a estudiar medidas de protección debe realizarse en base a los daños causados y la probabilidad de que ese daño se convierta en realidad. Se trata de no gastar más dinero en proteger un recurso de lo que cueste el propio o recurso o lo que cueste repararlo.Llamamos Ri al riesgo de perder un recurso i (a la probabilidad de que se produzca un ataque), y le asignamos un valor de 0 a 10 (valores más altos implican más probabilidad); de la misma forma, definimos también de 0 a 10 la importancia de cada recurso, Wi, siendo 10 la importancia más alta. La evaluación del riesgo es entonces el producto de ambos valores, llamado peso o riesgo evaluado de un recurso, WRi, y medido en dinero perdido por unidad de tiempo (generalmente, por año): 

WRi = Ri * Wi 

Evidentemente, los recursos que presenten un riesgo mayor, serán los que más atención precisen. Es especialmente importante un grupo de riesgos denominados inaceptables, que son aquellos cuyo peso supera un cierto umbral, son problemas que no nos podemos permitir en nuestro sistema para que todo funcione correctamente. Después lo que debemos realizar es realizar el análisis de costes y beneficios, que consiste en compara el coste de un problema con el coste de prevenir dicho problema. Evidentemente el segundo debe ser menor que el primero para que sea una medida de protección correcta.

Estrategias de respuesta

Cuando se hayan violado nuestras medidas de seguridad, la respuesta que debemos dar dependerá de la gravedad de la infracción, del daño que ha causado... La respuesta puede ser desde una amonestación verbal hasta la toma de medidas legales. Existen dos estrategias de respuesta ante un incidente de seguridad: La primera es proteger y proceder, que se suele aplicar cuando la organización es muy vulnerable o el nivel de los atacantes es muy elevado; y consiste en proteger de manera inmediata la red y los sistemas e intentar así que todo vuelva a la normalidad en el menor tiempo posible. La segunda es perseguir y procesar, que permite al atacante proseguir con sus actividades, pero bajo la mirada de los administradores de la forma más discreta posible; y se intentan guardadr pruebas para después poder acusar al atacante. Evidentemente esta segunda estrategia conlleva un alto riesgo, ya que se deja al atacante trabajar a su aire, pero también puede ser muy efectiva. indice

EN RESUMEN...  

La seguridad es un proceso continuo, que requiere tener previsto hasta lo imprevisible. Tener unos buenos hábitos y tomar unas pequeñas precauciones nos ayudarán mucho. Hay que desactivar todos los servicios que no vaya a prestar, en particular revisar los ficheros /etc/inittab,/etc/inetd.conf y los demonios que se lanzan durante el arranque. Si no estamos realmente seguros de lo que hacemos, mejor no hacer nada; las distribuciones más modernas incorporan unos mínimos de seguridad aceptables para un usuario medio.No tiene sentido tener abierto un servicio del que no va a hacer uso ningún usuario legal. Puede que estemos consumiendo recursos de nuestro sistema para ofrecer a algún atacante la posibilidad de violarlo. Podemos usar un analizador de puertos para ver qué parte de su sistema es visible desde el exterior. Existen utilidades como SATAN, Nessus o nmap que realizan esta labor. Trinux es una minidistribución de Linux totalmente portable que se puede llevar en 2 ó 3 disquetes y se ejecuta por completo en RAM, puediéndose usar desde cualquier equipo para la red. Se arranca desde el disquete y no utiliza el disco duro para nada. Contiene las últimas versiones de algunas herramientas muy prácticas enfocadas a la seguridad en redes. Nos permitirá analizar el tráfico de la red, analizar puertos e incluso ver el contenido de los paquetes que circulan por la red. Deberíamos vigilar los permisos de ficheros y directorios: 

La gran mayoría del sofware que acompaña a Linux es de código fuente público, como el propio núcleo. Esto es una garantía de seguridad en sí. Cientos de expertos analizan minuciosamente el código para detectar alguna pega que poder publicar en las listas de correo sobre seguridad más prestigiosas, y se corrigen con gran rapidez. De esta forma nos garantizamos un software de calidad y no una mera seguridad aparente. Esto por otro lado nos obliga a ir sustituyendo las versiones defectuosas por otras corregidas y que mejoran las prestaciones. En cualquier sistema operativo, mantener un software que ha demostrado tener fallos supone asumir un riesgo innecesario. Existen acontecimientos de los que nos puede resultar muy difícil protegernos como son los desastres naturales, únicamente podremos seguir una serie de pasos para evitar que su incidencia sea lo menor posible. La mejor solución es mantener un buen conjunto de copias de seguridad sobre toda la información necesaria del sistema. Hay que pensar que las copias de seguridad no sólo nos protegen de desastres naturales, también de los desastres que pueda ocasionar algún intruso en nuestro sistema, de cualquier ataque a la disponibilidad o integridad de la información del sistema. Si los datos tienen un tamaño inferior a 650Mb, puede ser una buena opción grabarlos en un CD, bien permanente (ya que es más difícil de falsificar con posterioridad, y si están almacenados de forma adecuada pueden durar mucho tiempo) o regrabable. Las cintas y otros medios sobre los que se puede escribir deberían protegerse tan pronto como se completa la copia y se verifica para evitar la falsificación. Hay que tener cuidado y almacenar la copia de seguridad en un sitio seguro. Una buena copia de seguridad nos asegura un buen punto desde el que restaurar nuestro sistema en caso necesario. Hay que insistir en la seguridad de las copias de seguridad. Si las copias de seguridad no están almacenadas en un sitio seguro, puede que el posible intruso no tenga necesidad de idear métodos sofisticados para obtenerla, si le basta con copiar o sustraer un CD. Cuando se realice una copia de seguridad es conveniente seleccionar un método que garantice la conservación de las características de la información como son derechos y permisos. Si realizamos una copia de seguridad de una forma o sobre un soporte que no contemple esta posibilidad, si tenemos que restaurar los datos sobre el sistema el resultado sobre la seguridad y funcionalidad globales puede ser impredecible. Es necesario tener un política de copias de seguridad adecuada a las características de la entidad que estamos gestionando. Quizás el mejor método es el de rotación de cintas. Pasamos a verlo con un ejemplo: Un ciclo de seis cintas es fácil de mantener. Esto incluye cuatro cintas para la semana, una cinta para cada Viernes y una cinta para para los Viernes impares. Se realiza una copia incremental cada día, y una copia completa en la cinta

adecuada de cada Viernes. Si hace algún cambio importante o añade datos importantes a su sistema también sería adecuado efectuar una copia. Existe cierta información del sistema que es imprescindible para su correcto funcionamiento. Es conveniente tener una copia de estos ficheros en una ubicación segura. En particular resulta conveniente tener una copia del contenido del directorio /etc. También hay que mantenerla en lugar seguro, ya que tiene copias de los ficheros /etc/passwd y /etc/shadows, entre otros que puedan contener claves de usuarios que no están cifradas. También en cada sistema se puede tener una base de datos de las aplicaciones que hay instaladas en el servidor. Cada distribución dispone de alguna herramienta que nos realiza el mantenimiento de la base de datos a la misma vez que instala o desinstala aplicaciones. La pérdida de esta base de datos nos haría perder el control sobre qué aplicaciones tenemos instaladas. En muchas situaciones también será necesario tener copia de seguridad de los ficheros de registro de incidencias, para tener constancia de las distintas actividades del sistema. He aquí algunos consejos : -Suscribirse a las listas de correo de alertas de seguridad para estar actualizado. -Prestar atención a los ficheros de registro. -Actualizar el software inseguro. -Verificar regularmente la integridad de los ficheros con algún software como tripwire. -Tener unas copias de seguridad adecuadas. -Utilizar PGP o GnuPG para garantizar la autenticidad y la privacidad. -Verificar con periodicidad los puertos de los equipos. -Revisar periódicamente las cuentas de usuario. -Asignar cuotas de uso de recursos del sistema. -Mantener los terminales seguros. -Asegurarse de tener claves sólidas. -Mantener el sistema de ficheros con propietarios y permisos adecuados. -Instalar cortafuegos. Ahora, una vez vistas las características generales de seguridad, lo que queda es aplicar el sentido común. Tenemos que ver nuestra situación y respondernos a una serie de preguntas: -¿Qué queremos proteger? -¿Qué valor tiene lo que queremos proteger? -¿Qué coste tiene la seguridad? -¿De quién nos queremos proteger? -¿Cuáles son los puntos débiles de nuestro sistema? Las posibles respuestas a estas preguntas nos promocionan un abanico de posibilidades demasiado amplio como para poderlo tratar todo. 

Lo primero que tenemos que determinar es lo que queremos proteger. No será lo mismo una estación de trabajo personal aislada con conexiones a Internet esporádicas que un servidor web con conexión permanente o un cortafuegos. También tendremos que considerar el coste de lo que queremos proteger: posible coste económico, tiempo de restauración o instalación, prestigio, perdida de clientes, etc. También el coste de la seguridad en unos términos parecidos a los anteriores. Sería absurdo que invirtiéramos más en protección que el coste de lo protegido. También hay que considerar que existe una relación inversa entre seguridad y funcionalidad. Cuanto más seguro hacemos un sistema, menos funcional resulta, ofreciendo menos servicios y más limitaciones de acceso. Esto también constituye otro coste adicional: facilidad de uso. Después de saber qué y de qué tenemos que protegernos, de quiénes y cuáles son sus posibles objetivos, y viendo los servicios que necesariamente hay que prestar o usar, obtendremos un esquema elemental de nuestra situación y de las medidas que tenemos que tomar.

indice

BIBLIOGRAFÍA

Para la relizacón de este trabajo he recopilado la información necesaria de los siguientes libros: -"Utlizando Linux", 2ª edición del libro de la editorial Prentice Hall, escrito por Jack Tackett Jr y David Gunter -"Administración de sistemas Linux", de la misma editorial y escrito por M Carling, Stephen Degler y James Dennis -"Seguridad en Unix y Redes", de Antonio Villalón Huerta 

También me he apoyado en la página web http://www.linuxdoc.org/HOWTO/Security-HOWTO.html, y en los apuntes de la asignatura. Sergio Sánchez San Martín

indice