UNIVERSIDAD NACIONAL DEL NORDESTE FACULTAD DE CIENCIAS EXACTAS Y NATURALES Y AGRIMENSURA

SEGURIDAD EN SISTEMAS OPERATIVOS LINUX

CARRERA: Lic. En Sistemas de Informacin

ASIGNATURA: Sistemas Operativos

ALUMNO:

Mendoza, Martn

L.U. 42.275

AO: 2011

INDICE Introduccin 3 Linux es seguro... 5 Por qu es necesaria la seguridad. 5 Seguridad en el desarrollo de Linux. 6 Servicios en Linux.. 7 Seguridad fsica.. 7 Seguridad Local. 9 Seguridad Del Sistema De Archivos 13 Seguridad Del Ncleo... 23 Seguridad De Red.... 26 Seguridad del root 29 Preparacin Para La Seguridad 31 Conclusin 33 Bibliografa.. 34

SEGURIDAD EN LINUX
Introduccin LINUX es un sistema operativo, compatible Unix. Dos caractersticas muy peculiares lo diferencian del resto de los sistemas que podemos encontrar en el mercado, la primera, es que es libre, esto significa que no tenemos que pagar ningn tipo de licencia a ninguna casa desarrolladora de software por el uso del mismo, la segunda, es que el sistema viene acompaado del cdigo fuente. El sistema lo forman el ncleo del sistema (kernel) mas un gran nmero de programas / libreras que hacen posible su utilizacin. Linux fue creado inicialmente como un hobbies por un estudiante joven, Linus Torvalds, en la universidad de Helsinki en Finlandia, con asistencia por un grupo de hackers a travs de Internet. Linus tena un inters en Minix, un sistema pequeo o abreviado del UNIX (desarrollado por Andy Tanenbaum); y decidido a desarrollar un sistema que excedi los estndares de Minix. Quera llevar a cabo un sistema operativo que aprovechase la arquitectura de 32 bits para multitarea y eliminar las barreras del direccionamiento de memoria. Torvalds empez escribiendo el ncleo del proyecto en ensamblador, y luego comenz a aadir cdigo en C, lo cual increment la velocidad de desarrollo, e hizo que empezara a tomarse en serio su idea. l comenz su trabajo en 1991 cuando l realiz la versin 0,02, la cual no la di a conocer porque ni siquiera tena drivers de disquete, adems de llevar un sistema de almacenamiento de archivos muy defectuoso. Trabaj constantemente hasta 1994 en que la versin 1,0 del ncleo (KERNEL) de Linux se concret. La versin completamente equipada 2,2 (versin concluida el 25 de enero de 1999). Linux tiene todas las prestaciones que se se pueden esperar de un Unix moderno y completamente desarrollado: multitarea real, memoria virtual, bibliotecas compartidas, carga de sistemas a demanda, compartimiento, manejo de debido de la memoria y soporte de redes TCP/IP. La parte central de Linux (conocida como ncleo o kernel) se distribuye a travs de la Licencia Pblica General GNU, lo que bsicamente significa que se puede ser copiado libremente, cambiado y distribuido, pero no es posible imponer restricciones adicionales a los productos obtenidos y, adicionalmente, se debe dejar el cdigo fuente disponible, de la misma forma que est disponible el cdigo de Linux. An cuando Linux tenga registro de Copyright, y no sea estrictamente de dominio pblico. La licencia tiene por objeto asegurar que Linux siga siendo gratuito y a la vez estndar. El sistema ha sido diseado y programado por multitud de programadores alrededor del mundo. El ncleo del sistema sigue en continuo desarrollo bajo la coordinacin de Linus Torvalds. Da a da, ms y ms programas / aplicaciones estn disponibles para este sistema, y la calidad de los mismos aumenta de versin a versin. La gran mayora de los mismos vienen acompaados del cdigo fuente y se distribuyen gratuitamente bajo los trminos de licencia de la GNU Public License. En los ltimos tiempos, ciertas casas de software comercial han empezado a distribuir sus productos para Linux y la presencia del mismo en empresas aumenta rpidamente por la excelente relacin calidad precio que se consigue con Linux.
3

Linux es Seguro: El concepto de seguridad es siempre relativo. Un sistema se puede ser seguro para un determinado tipo de actividades e inseguro para otras. Por ejemplo, no sera recomendable guardar secretos de estado en un sistema Linux al que pudiera acceder mucha gente y careciese de un administrador dedicado absolutamente a la tarea, ya que segn todos los hackers, no hay sistema cuya seguridad sea perfecta. El sistema de contraseas que protege el acceso al sistema se basa en el algoritmo DES, el ms probado de los algoritmos de seguridad. Pero claro, por muy bueno que sea el algoritmo, si despus permitimos a sus usuarios poner como contrasea su nombre de usuario, de nada servir la contrasea y todos sus esfuerzos. Si se quiere que el sistema sea seguro, se debe administrar de tal forma que se tengan controlados a los usuarios en todo momento, para poder aconsejarles e incluso regaarles, en caso de que cometan alguna imprudencia, todo ello con el fin de mantener la propia seguridad de sus datos y de los nuestros. Para ayudarse a mantener la seguridad surgen nuevas herramientas constantemente, tanto para detectar intrusos como para encontrar fallos en el sistema y evitar as ataques desde el exterior. La seguridad se consigue a travs de la interaccin del usuario con el software, no es que un producto sea ms seguro que otro. De esta forma los reportes de errores o vulnerabilidades son una ayuda esencial para mejorarlo, crear patches de seguridad, etc. Si el usuario acta facilitando o dificultando un ataque al sistema es un punto clave. Entonces un Sistema Operativo debera dar herramientas para protegerse. Algunos puntos en aspectos de seguridad q propone Linux son: 1. Mejores herramientas para realizar patches: las actualizaciones de seguridad de Linux afectan a todas las aplicaciones y componentes de modo que cada aplicacin no deba ser actualizada y patcheada por separado. 2. Mejor configuraciones de usuarios: Linux fue diseado como un sistema operativo multiusuario. Si por desgracia se ejecutara un soft malicioso afectara slo al usuario que est utilizando el sistema. 3. Diseo modular: Si un componente del sistema est fallando o es vulnerable, es ms fcil desactivarlo para que no d problemas. 4. Mejores herramientas para la proteccin contra ataques Zero-Day: los ataques basados en vulnerabilidades que no han sido corregidas por los fabricantes y desarrolladores a tiempo y que los exploits aprovechan son menos peligrosos en Linux. Herramientas como SELinux o AppArmor proporcionan un control de seguridad con una granularidad muy alta. 5. Arquitecturas Open Source: todos ven el cdigo, de modo que cualquiera se puede colaborar para corregir fallos. 6. Entorno muy diverso: Las distintas versiones de Linux y de sus aplicaciones hacen ms complicado el desarrollo de exploits que tengan un gran potencial.

Por qu es necesaria la seguridad Ante todo Linux es un sistema multiusuario real. Se puede haber varios usuarios distintos trabajando a la vez cada uno desde su terminal. El sistema tiene la obligacin de proteger a unos usuarios frente a otros y protegerse a s mismo. Linux es una excelente estacin de trabajo aislada, pero lo habitual es que cada mquina linux est conectada a una red y adems est prestando servicios de red. El sistema tiene la obligacin de garantizar los servicios que presta. Adems, con la generalizacin de las conexiones con Internet y el rpido desarrollo del software, la seguridad se est convirtiendo en una cuestin cada vez ms importante. Ahora, la seguridad es un requisito bsico, ya que la red global es insegura por definicin. Mientras sus datos estn almacenados en un soporte informtico, mientras sus datos vayan desde un sistema X a otro sistema Y a travs de un medio fsico, Internet, por ejemplo, se puede pasar por ciertos puntos durante el camino proporcionando a otros usuarios la posibilidad de interceptarlos, e incluso alterar la informacin contenida. Incluso algn usuario de su sistema se puede modificar datos de forma maliciosa para hacer algo que nos pueda resultar perjudicial. Con el acceso masivo y barato a Internet se han reducido notablemente los costes de un atacante para asaltar un sistema en red, a la vez que ha aumentado paralelamente el nmero de potenciales atacantes. Ningn sistema es "completamente" seguro. El nico sistema seguro es aquel que no est conectado en red, que est apagado y encerrado bajo llave. Desde esta perspectiva, lo nico que se puede hacer es aumentar la dificultad para que alguien pueda comprometer la seguridad del sistema. Tampoco todos los usuarios tienen las mismas necesidades de seguridad en sus entornos. Por ejemplo, los usuarios domsticos de Linux, no necesitan demasiado trabajo para mantener alejados a los crackers ocasionales, mientras que para los usuarios muy especializados de Linux, como por ejemplo servidores de Internet, bancos, compaas de telecomunicaciones, etc., se necesita un trabajo mucho ms detallado para garantizar la seguridad en los trminos previstos. Tambin debemos tener en cuenta que existe una relacin inversa entre seguridad y funcionalidad. Tiene que decidir dnde est el equilibrio entre la facilidad de uso de su sistema y su seguridad. Por ejemplo, se puede necesitar que cualquiera que llame por el mdem a su sistema, y nuestro mdem tenga que devolver la llamada a su nmero de casa. Este mecanismo garantiza un mayor nivel de seguridad, pero si alguien no est en casa, le hace ms difcil conectarse. Tambin existe una relacin inversa entre el nivel de seguridad y el nmero de servicios distintos que presta un sistema. Cada servicio prestado por un sistema se puede ser susceptible de ser utilizado contra el propio equipo servidor, como se puede ser el caso de bloqueos intencionados, conocidos como ataque de denegacin de servicio. Pero un sistema servidor que no presta servicios es menos servidor.

En el caso de administrar una instalacin mediana o grande conviene establecer una "Poltica de Seguridad" que fije el nivel de seguridad que requiere ese sitio y que sistema de comprobacin se realiza. Seguridad en el desarrollo de Linux Como las fuentes del ncleo de linux son abiertas. Cualquiera puede obtenerlas, analizarlas y modificarlas. Este modelo de desarrollo abierto, que siguen tanto Linux como la mayora de las aplicaciones que se ejecutan sobre l, conduce a altos niveles de seguridad. Es cierto que cualquiera puede acceder al cdigo fuente para encontrar las debilidades, pero no es menos cierto que el tiempo que tarda en aparecer la solucin para cualquier debilidad se mide ms fcilmente en horas que en das. Gracias a esto, Linux es conocido por su alto nivel de estabilidad que parte del propio ncleo del sistema operativo (lo que propiamente es Linux). Servicios en Linux Linux tiene disponible todos los servicios habituales en una red:

Bases de datos. Servicios de internet. Servicio de ficheros e impresin. Utilidades necesarias para mantener el nivel de seguridad requerido.

Pero adems hay que resear que cada servicio funciona sin afectar al resto de los servicios. Vd. se puede modificar la direccin IP de su equipo, las rutas, aadir, parar o reiniciar un servicio concreto sin que el resto de los servicios se vean afectados. Slo es necesario detener el equipo para realizar operaciones con el hardware, como aadir un disco duro, o utilizar un nuevo ncleo. No tendr, pues, la necesidad de tener que ser Vd. mismo el atacante de su propio sistema, a diferencia de lo que ocurre en otros sistemas operativos. Qu Proteger? La seguridad pretende que los sistemas informticos que utiliza una entidad se mantengan en funcionamiento segn los requisitos de la poltica 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 legtimos. Bsicamente los requisitos de seguridad se se puede resumir en una serie de puntos ilustrativos:
o

Disponibilidad: consistente en mantener la informacin y los recursos de acuerdo con los requisitos de utilizacin que pretende la entidad que utiliza la red informtica. La disponibilidad de la informacin pretende garantizar que no se limite el acceso autorizado a la informacin y el correcto funcionamiento de los recursos.

Integridad: la informacin que se almacena en los sistemas o que circula por las lneas de comunicacin debe estar protegida contra la modificacin no autorizada. Requiere que la informacin slo pueda ser modificada por las entidades autorizadas. Autenticidad: la informacin que se almacena o circula por una red debe permanecer protegida ante falsificaciones. La autenticidad requiere mecanismos de identificacin correctos, asegurando que las comunicaciones se realizan entre entidades legtimas. Confidencialidad: pretende evitar la difusin no autorizada de la informacin. Requiere que la informacin sea accesible nicamente por las entidades autorizadas. No rechazo: establecer los mecanismos para que nadie pueda negar que ha realizado una determinada comunicacin.

En Linux tendremos que proteger ciertos ficheros que contienen informacin sobre los usuarios (/etc/passwd, /etc/shadow), los ficheros de configuracin del sistema (los contenidos en /etc), el acceso al sistema para que se realice segn marca la poltica prevista y la correcta utilizacin de los recursos para evitar abusos (p.e. si un usuario tiene slo una cuenta de correo, que no pueda abrir una shell en el sistema). A todo esto habr que sumar la proteccin de los distintos servicios que presta. SEGURIDAD FISICA Las primeras medidas de seguridad que necesita tener en cuenta son las de seguridad fsica de sus sistemas. Hay que tomar en consideracin quines tienen acceso fsico a las mquinas y si realmente deberan acceder. El nivel de seguridad fsica que necesita en su sistema depende de su situacin concreta. Un usuario domstico no necesita preocuparse demasiado por la proteccin fsica, salvo proteger su mquina de un nio o algo as. En una oficina se puede ser diferente. Linux proporciona los niveles exigibles de seguridad fsica para un sistema operativo:

Un arranque seguro Posibilidad de bloquear las terminales Por supuesto, las capacidades de un sistema multiusuario real.

Seguridad en el arranque Cuando alguien inicia el sistema operativo Linux se encuentra con una pantalla de login: el sistema est pidiendo que se identifique. Si es un usuario conocido, podr iniciar una sesin y trabajar con el sistema. Si no lo es, no tendr opcin de hacer absolutamente nada. Adems, el sistema registra todos los intentos de acceso (fallidos o no), por lo que no pasarn desapercibidos intentos repetidos de acceso no autorizado.

LILO (Linux Loader) es el encargado de cargar el sistema operativo en memoria y pasarle informacin para su inicio. A su vez, Vd. se puede pasarle parmetros a LILO para modificar su comportamiento. Por ejemplo, si alguien en el indicador de LILO aade init single, el sistema se inicia en modo monousuario y proporciona una shell de root sin contrasea. Si en su entorno de trabajo cree necesario evitar que alguien pueda iniciar el sistema de esta forma, debera utilizar el parmetro restricted en el fichero de configuracin de LILO (habitualmente/etc/lilo.conf). Este parmetro 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. Si se tiene mayores necesidades de seguridad se se puede incluir la opcin password. De esta forma necesitar una clave para iniciar el sistema. En estas condiciones, slo podr iniciar el sistema quien conozca la clave. Bloqueo de la consola En los entornos Unix es conocido el truco de ejecutar en una teminal, que alguien ha dejado inocentemente abierto, un guion que simule la pantalla de presentacin al sistema. Entonces un usuario incauto introudcir su nombre y clave, que quedarn a merced del autor del engao. Si se aleja de su mquina de vez en cuando, estara bien poder bloquear su consola para que nadie pueda manipularla o mirar su trabajo. Dos programas que hacen esto son xlock y vlock. xlock bloquea la pantalla cuando nos encontramos en modo grfico. Est incluido en la mayora de las distribuciones Linux que soportan X. En general se se puede ejecutar xlock desde cualquier xterm de la consola y bloquear la pantalla de forma que se necesitar la clave para desbloquearla. vlock es un simple programa que permite cerrar alguna o todas las consolas virtuales de la mquina Linux. Se puede bloquear slo aqulla en la que se est trabajando o todas. Si slo se cierra una, las otras se se pueden abrir y utilizar la consola, pero no se podr usar la vty hasta que no la desbloquee. Desde luego, bloquear una consola prevendr que alguien manipule los trabajos, pero no previene de reinicios de la mquina u otras formas de deteriorar los trabajos.

SEGURIDAD LOCAL Introduccin Linux es un sistema operativo multiusuario real: se puede haber varios usuarios trabajando simultneamente con l, cada uno en su terminal. Esto obliga a tener en cuenta medidas de seguridad adicionales. Adems, segn hablan las estadsticas, el mayor porcentaje de violaciones de un sistema son realizadas por usuarios locales. Pero no slo 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 caractersticas de los sistemas Unix: un control de acceso a los usuarios verificando una pareja de usuario y clave; cada fichero y directorio tienen sus propietarios y permisos. Por otro lado, la meta de la mayora 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 tcnicas denominadas "ingeniera social", consistentes en convencer a ciertos usuarios para que suministren una informacin que debiera ser mantenida en secreto, como los nombres de usuario y contraseas. Cuentas de usuario, grupos Cada usuario del sistema est definido por una lnea en el fichero /etc/passwd y cada grupo por otra lnea 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 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. Otro peligro potencial para el sistema es mantener cuentas abiertas que se han dejado de utilizar. Estas cuentas se pueden constituir un buen refugio para un potencial atacante y pasar desapercibidas sus acciones. Seguridad de las claves La seguridad de una sola cuenta se puede comprometer la seguridad de todo el sistema. Esto es una realidad ante la que se debe estar protegido. Por un lado los usuarios deberan utilizar claves slidas:

No deben ser una palabra conocida.

9

Deberan contener letras, nmeros y caracteres especiales. Deben ser fciles de recordar y difciles 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; despus 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 dbil 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 mquina (evidentemente, que el usuario de navegador tenga permiso para leer), de manera que lleguen hasta un hacker que cree pginas web que exploten estos agujeros. Entonces se 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 ms que ejecutar su programa revientaclaves favorito y sentarse a esperar hasta que empiecen a aparecer nombres de usuario con sus respectivas contraseas, algo que suele pasar muy rpidamente. Con suerte, si el administrador es ingenuo o dejado, incluso dar con la clave del root, abrindosele as las puertas a la mquina objetivo. Para solucionar esta vulnerabilidad, podemos recurrir a contraseas 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 slo se puede leer el root y dejar el resto de la informacin en el original /etc/passwd. El fichero /etc/shadow slo contiene el nombre de usuario y su clave, e informacin administrativa, como cundo expira la cuenta, etc. El formato del fichero /etc/shadow es similar al siguiente: usuario : clave : ultimo : se puede : debe : aviso : expira : desactiva : reservado

usuario: El nombre del usuario. clave: La clave cifrada ultimo: Das transcurridos del ltimo cambio de clave. se puede: Das transcurridos antes de que la clave se pueda modificar. tiene: Das transcurridos antes de que la clave tenga que ser modificada. aviso: Das de aviso al usuario antes de que expire la clave. expira: Das que se desactiva la cuenta tras expirar la clave. desactiva: Das de duracin de la cuenta.
10

reservado: sin comentarios.

Un ejemplo podra ser: julia : gEvm4sbKnGRlg : 10627 : 0 : 99999 : 7 : -1 : -1 : 134529868

El paquete de Shadow Passwords se se puede descargar desde cualquiera de los siguientes sitios, con instrucciones para su instalacin:

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 contraseas en la sombra, se debe ejecutar pwconv como root; accin que crear su fichero /etc/shadow. Si la distribucin de Linux no incluye contraseas en la sombra o se encuentra alguna dificultad para incorporar esta caracterstica, existe un documento HOWTO (CMO) titulado Shadow-Password-HOWTO que se puede resultar de gran utilidad. Aqu se podr encontrar tambin informacin adicional que se puede ayudar a mantener la seguridad local. El bit SUID/SGID En muchas ocasiones un proceso necesita ejecutarse con unos privilegios mayores (o menores) que el usuario que lo lanz. Por ejemplo, un usuario se 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. Cmo se soluciona? Pues activando el bit SUID del comando 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 se puede parecer una seria brecha de seguridad. Y lo es. Si el programa funciona correctamente, no tiene por qu dar problemas; pero pequeos defectos en el programa se pueden ser utilizados por alguien para tratar de ejecutar otro cdigo distinto con los privilegios de este proceso. El mtodo suele ser el desbordamiento de la pila (buffer overflow). Cualquier atacante que haya entrado en un sistema de forma ilegtima 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.

11

Los programas con el bit SUID/SGIG. Se puede encontrarlos 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. Se debe comprobar en los lugares habituales, (que indicamos en la seccin correspondiente) que ninguno de los programas propiedad del root o SUID que se utiliza en el sistema, tiene un fallo de seguridad conocido que pueda ser explotado. No se debe permitir que quede una shell SUID corriendo en el sistema. Si el root deja desatendida la consola durante unos instantes, un intruso podra escribir lo siguiente: # cp # chmod 4755 /tmp/cuenta-root /bin/sh /tmp/cuenta-root

Crendose una versin 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 sera escaneando el sistema completo como se ha explicado antes. Seguridad del root Los peores destrozos de un sistema es probable que no vengan de ningn cracker, o de un malvolo intruso. En muchsimas ms 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 difcil. Siguiendo unas fciles normas, se se puede proteger de Vd. mismo:

No usar la cuenta de root por norma. Evitarla. Intentar primero cualquier accin como un usuario normal, y si al ver que no se tiene permiso, pensar porqu y usar el comando su si es necesario. Ejecutar los comandos de forma segura verificando previamente la accin que va a realizar. Por ejemplo si se quiere ejecutar rm borrar.*, ejecutar primero ls borrar.* si lo que se pretende es modificar el mandato. Ciertos mandatos admiten una opcin (-i) para actuar de forma interactiva. Actvar, si no lo est ya aadiendo estas lneas al fichero de recursos par la shell: o alias rm='rm -i' o alias cp='cp -i' o alias mv='mv -i' Siempre se se puede evitar estas preguntas, a veces incordiosas, con el mandato yes, cuando est seguro de la operacin que est realizando:

12

$ yes s|rm borrar.*

El directorio actual no est, por defecto, en la ruta de bsqueda 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. Utilicar ssh u otro canal seguro. Limitar los terminales desde los que se se puede conectar root. Es preferible limitarlo a la consola del sistema. Esto se se puede decidir en/etc/securetty. Si se necesita una sesin remota como root, entrar como usuario normal y luego usar su. Actuar de forma lenta y meditada 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. Adems registra las actividades que se realizan, lo que ayuda a determinar qu hace realmente este usuario.

SEGURIDAD DEL SISTEMA DE ARCHIVOS Introduccin Una norma bsica de seguridad radica en la asignacin a cada usuario slo de los permisos necesarios para poder cubrir las necesidades de su trabajo sin poner en riesgo el trabajo de los dems. Cmo se se puede poner en riesgo el correcto funcionamiento del sistema? Podemos apuntar algunas ideas: violando la privacidad de la informacin, obteniendo unos privilegios que no le corresponde a un usuario, haciendo un uso desmedido de los recursos o modificando informacin legtima contenida en una mquina, como se pueden ser el contenido de una pgina web o una base de datos. Cmo podemos mantener un almacenamiento seguro? La respuesta no se puede ser concreta, pero s que se se pueden tomar ciertas medidas que garanticen un mnimo de seguridad y funcionalidad. Si Vd. va a administrar un sistema Linux para dar servicio a diversos usuarios, debera tener algunas nociones sobre sistemas de ficheros.

13

El rbol de directorios Para quienes no estn familiarizados con las caractersticas del sistema de almacenamiento de informacin en sistemas Unix, hay que indicar que se organizan en un nico rbol de directorios. Cada soporte, disco, particin, disquete o CD tiene su propia organizacin lgica, un sistema de ficheros. Para poder usar uno de estos soportes tenemos que "montarlo" en un directorio existente. El contenido de la particin nos aparecer como el contenido del directorio. Un primer criterio para mantener un sistema seguro sera hacer una correcta distribucin del espacio de almacenamiento. Esto limita el riesgo de que el deterioro de una particin afecte a todo el sistema. La prdida se limitara al contenido de esa particin. No hay unas normas generales aplicables; el uso al que vaya destinado el sistema y la experiencia son las bases de la decisin adecuada.

Si el sistema va a dar servicio a mltiples usuarios que requieren almacenamiento para sus datos privados, sera conveniente que el directorio /home tuviera su propia particin. Si el equipo va a ser un servidor de correo, impresin, etc., el directorio /var o incluso /var/spool podran tener su propia particin. Algunos directorios son necesarios en la particin raz. 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 particin propia para proteger estos programas personalizados de futuras actualizaciones del sistema. Este criterio tambin se se puede aplicar al directorio /opt.

Permisos 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. La forma ms rpida de comprobar esta caracterstica es usar el comando ls -la. As nos aparece el tipo de fichero, el propietario, el grupo, los permisos e informacin adicional. Por supuesto, el sistema de ficheros tiene que admitir esta caracterstica, 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 caracterstica, por lo que son inseguros y su uso no es aconsejable bajo Linux. Es conveniente tener claros los permisos que se se pueden asignar a un fichero o directorio. Se puede que algunas aplicaciones no funcionen bien si algn fichero no tiene el permiso o el propietario correctos, bien por falta de permisos o bien por exceso. Algunas aplicaciones son un poco quisquillosas en este aspecto. Por ejemplo, fetchmail es un programa que podemos usar para recoger el correo de un servidor pop (por ejemplo). Este programa se configura en el fichero .fetchmailrc, donde tendremos que indicar la clave que usamos en el

14

servidor; pues bien, si este fichero tiene permiso de lectura para otro usuario que no sea el propietario, fetchmail no funcionar. Otras aplicaciones, como por ejemplo inn (un servidor de noticias de Internet) tampoco funcionarn si el propietario de sus ficheros es otro usuario distinto a news. Todo esto est perfectamente documentado en cada uno de los programas, por lo que es conveniente leer la documentacin que aporta y las pginas del manual. Permisos de ficheros y directorios Tenemos que asegurarnos de que los ficheros del sistema y los de cada usuario slo son accesibles por quienes tienen que hacerlo y de la forma que deben. No slo hay que protegerse de ataques o miradas indiscretas, tambin hay que protegerse de acciones accidentales. En general, cualquier sistema UNIX divide el control de acceso a ficheros y directorios en tres elementos: propietario, grupo y otros. Tanto el propietario como el grupo sn nicos para cada fichero o directorio. Eso s, a un grupo se pueden pertenecer mltiples usuarios. Otros hace referencia a los usuarios que ni son el propietario ni pertenecen al grupo. Todas estas caractersticas se almacenan en el sistema de ficheros, en particular en un inodo, que es un elemento que describe las caractersticas de un fichero en disco (salvo su nombre). Una rpida explicacin de los permisos Unix: Propiedad: Qu usuario y grupo posee el control de los permisos del i-nodo. Se almacenan como dos valores numricos, 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.

Lectura (r): o Fichero: Poder acceder a los contenidos de un fichero o Directorio: Poder leer un directorio, ver qu ficheros contiene Escritura (w): o Fichero: Poder modificar o aadir contenido a un fichero o Directorio: Poder borrar o mover ficheros en un directorio Ejecucin(x): o Fichero: Poder ejecutar un programa binario o guion de shell o Directorio: Poder entrar en un directorio
15

Estos permisos se 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

Adems 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 slo se puede borrar ficheros que son de su propiedad o para los que tiene permiso explcito 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 SUID activo. Por qu? Este programa lo se 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 segn los permisos que observamos en este fichero, slo root se puede escribir y modificar en l. Entonces sera imposible que un usuario pudiera cambiar su clave si no se puede modificar este fichero. La solucin 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.

16

Podra ser un riesgo si no mantenemos un mnimo de atencin, ya que en este tipo de programas se se pueden producir desbordamientos de bfer que comprometan al sistema.

No asignar el bit SUID salvo cuando sea estrictamente necesario. Comprobar que cualquier programa con este bit activo no tiene ningn desbordamiento de buffer (conocido). No asignarlo jams si el programa permite salir a la shell.

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. Acta de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algn efecto. Atributo SGID: (Para directorios) Si se activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrn puesto su grupo como el grupo del directorio. Normalmente un fichero tendr una combinacin 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 tambin 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 modificacin". Normalmente usado para ficheros de intercambio (swap) ---t------ No tiene efecto. (antes sticky bit) Normalmente un directorio tendr una combinacin de los siguientes permisos: dr-------- Permite listar el contenido pero no se se pueden leer los atributos. d--x------ Permite entrar en el directorio y usar en las rutas de ejecucin 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 configuracin 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 se puede modificar. Nunca se debera dejar un fichero del sistema con permiso de escritura para un grupo o para otros. Algunos ficheros de configuracin, incluyendo/etc/shadow, slo deberan tener permiso de lectura por root, y los directorios de /etc no deberan ser accesibles, al menos por otros.
17

SUID Shell Scripts Los scripts de shell SUID son un serio riesgo de seguridad, y por esta razn el ncleo no los acepta. Sin importar lo seguro que piense que es su script de shell, se puede ser utilizado para que un cracker pueda obtener acceso a una shell de root. Enlaces Los sistemas de ficheros de tipo Unix permiten crear enlaces entre ficheros. Los enlaces se pueden ser duros o simblicos. El primer caso consiste en asignar ms de un nombre a los mismos datos en disco. Un enlace duro no consume ms espacio adicional que el que pueda representar el nuevo nombre que le damos a unos datos y slo es vlido para ficheros que estn en el mismo sistema de ficheros, es decir, la misma particin. Los enlaces simblicos son ficheros que apuntan a otro fichero o directorio. Crean un nuevo fichero pequeo que contiene la ruta del fichero destino. Verificar la integridad con Tripwire Una forma cmoda de detectar ataques locales (y tambin de red) en el sistema es ejecutar un programa que verifique la integridad de la informacin almacenada en los ficheros, tal como Tripwire. El programa Tripwire ejecuta varios cheksums de todos los binarios importantes y ficheros de configuracin 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 fsicamente. De esta forma no se se puede alterar tripwire 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 administracin para ver si algo ha cambiado. Tripwire se puede ser una de las mejores herramientas para detectar intrusos antes de tener otro tipo de noticias de ellos. Como son muchos los ficheros que se modifican en el sistema, se debera tener cuidado para discernir lo que es la actividad de un cracker y lo que es la actividad normal del sistema. Limitar el espacio asignado a los usuarios Un ataque posible a cualquier sistema es intentar consumir todo el espacio del disco duro. Una primera proteccin contra este ataque es separar el rbol de directorios en diversos discos y particiones. Pero esto se puede no ser suficiente y por eso el ncleo del sistema proporciona la posibilidad de controlar el espacio de almacenamiento por usuario o grupo. Lo primero que tendramos que hacer es asegurarnos de que nuestro ncleo tiene soporte para las cuotas de usuarios.

18

En caso contrario, el ncleo no ha sido compilado con soporte para el sistema de cuotas para usuarios. En este caso ser necesario compilar un nuevo ncleo Linux. El resto del procedimiento de instalacin se se puede realizar utilizando la documentacin existente. Ahora es necesario editar el fichero /etc/fstab y aadir usrquota ogrpquota en la particin 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 particin /dev/hda3: /dev/hda3 /home ext2 defaults,usrquota 1 2 Ahora podemos recopilar la informacin 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 tambin se crea un fichero llamado quota.user oquota.grp en la particin 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 prxima vez que se inicie el sistema, se activarn automticamente 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 automtica 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 cuota para cada usuario. Para ello existen dos mtodos. El primero consiste en editar la quota de cada usuario. Por ejemplo, para editar la cuota del usuario antonio, 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)
19

El sistema de cuotas de Linux permite limitar el nmero de bloques y el nmero de i-nodos que un usuario se puede tener. Los valores a modificar son los lmites que estn puestos entre parntesis (que ahora valen 0). Ah se se puede especificar cualquier cantidad (en Kbytes). Por ejemplo, para limitar la cuota de disco del usuario antonio a 1 Mb, se pondra 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 lmite soft es un lmite de aviso y el lmite hard es un lmite insalvable, es decir, el sistema ya no le asigna ms espacio. De una forma anloga, podramos modificar la cuota de espacio asignada al grupo users con: # edquota -g users Normas prcticas para aumentar la seguridad Aunque sea necesario tener claros los conceptos y dedicarle algo de tiempo a una correcta planificacin, tampoco los peligros expuestos tienen por qu asustar a nadie. Todas las distribuciones de Linux traen unos valores por defecto que son ms que razonables para cubrir unas necesidades normales.

nosuid, nodev, noexec. Salvo casos excepcionales, no debera haber ninguna razn para que se permita la ejecucin de programas SUID/SGID en los directorios home de los usuarios. Esto lo podemos evitar usando la opcin `nosuid'en el fichero /etc/fstab para las particiones que tengan permiso de escritura por alguien que no sea el root. Tambin se puede ser til usar`nodev' y `noexec' en las particiones de los directorios personales de los usuarios y en /var, lo que prohbe la creacin dispositivos de bloque o carcter y la ejecucin de programas.

Sistemas de ficheros en red Si se exporta sistemas de archivos va NFS, lo recomendable seria configurar/etc/exports con los accesos lo ms restrictivos posibles. Esto significa no usar plantillas, no permitir acceso de escritura a root y montar como slo lectura siempre que sea posible.

umask Configurar la mscara de creacin de ficheros para que sea lo ms restrictiva posible. Son habituales 022, 033, y la ms restrictiva 077, y aadirla a /etc/profile.
20

El comando umask se se puede usar para determinar el modo de creacin de ficheros por defecto en su sistema. Es el complemento octal a los modos de fichero deseado. Si los ficheros se crean sin ningn miramiento de estado de permisos, el usuario, de forma inadvertida, podr asignar permisos de lectura o escritura a alguien que no debera tenerlos. De forma tpica, el estado de umask incluye 022, 027 y 077, que es lo ms restrictivo. Normalmente umask se pone en /etc/profiley por tanto se aplica a todos los usuarios del sistema. Por ejemplo, se puede tener una lnea parecida a la siguiente: # Pone umask 033 el valor por defecto de umask del usuario

El valor umask de root es 077, lo cual desactiva los permisos de lectura, escritura y ejecucin para otros usuarios, salvo que explcitamente use chmod(1). Si se utiliza el esquema de creacin de idetificador de grupos y usuarios (User Private Groups), slo 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 Es recomendable poner lmites al sistema de ficheros en lugar de 'ilimitado' como est por defecto. Se se puede controlar el lmite por usuario utilizando el mdulo PAM de lmite de recursos y /etc/pam.d/limits.conf. Por ejemplo, los lmites para un grupo `users' podra parecer a esto: @users hard core 0 @users hard nproc 50 @users hard rss 5000 Esto dice que se prohiba la creacin de ficheros core, restringe el nmero de procesos a 50, y restringe el uso de memoria por usuario a 5Mb.

wtmp, utmp Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexin de todos los usuarios del sistema. Se debe mantener su integridad, ya que determinan cundo y desde dnde entr en el sistema un usuario o un potencial intruso. Los ficheros deberan tener los permisos 644, sin afectar a la normal operacin del sistema.

Sticky bit El sticky bit se se puede usar para prevenir borrados accidentales o proteger un fichero para sobreescritura. Tambin previene que alguien cree enlaces simblicos a

21

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 del sistema son potenciales riesgos de seguridad y deberan 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 prxima vez, incluso aunque el agujero original ya est tapado. Se puede eliminar los permisos SUID o SGIG de un programa con chmod, y siempre se puede volver a su estado original si es absolutamente necesario.

Permisos de escritura Los ficheros con permiso de escritura global, particularmente los del sistema, se pueden ser un agujero de seguridad si un cracker obtiene acceso a su sistema y los modifica. Adems, los directorios con permiso de escritura global son peligrosos, ya que permiten a un cracker aadir y borrar los ficheros que quiera. Para localizar los ficheros con permiso de escritura global, con el siguiente comando: root# find / -perm -2 -print Se se puede estar seguro de saber por qu tienen esos permisos de escritura. En el curso normal de una operacin los ficheros tendrn permisos de escritura, incluidos algunos de /dev y enlaces simblicos.

Ficheros extraos Los ficheros sin propietario tambin se pueden ser un indicio de que un intruso ha accedido a su sistema. Se se puede localizar los ficheros del sistema que no tienen propietario o que no pertenecen a un grupo con el comando: root# find / -nouser -o -nogroup -print

Ficheros peligrosos La localizacin de ficheros .rhosts debera ser uno de los deberes regulares de la administracin del sistema, ya que estos ficheros no se deberan permitir en el sistema. Un cracker slo necesita una cuenta insegura para potencialmente obtener acceso a toda la red. Se puede localizar todos los ficheros .rhosts del sistema con el siguiente comando: root# find /home -name .rhosts -print
22

Permisos Finalmente, antes de cambiar permisos en cualquier sistema de ficheros, se debe estar seguro de que se entiende lo que se hace. No se debe cambiar permisos de un fichero simplemente porque parezca la forma fcil de hacer que algo funcione. Siempre se debe determinar por qu el fichero tiene esos permisos y propietario antes de modificarlos.

SEGURIDAD DEL NUCLEO Introduccin Linux tiene la gran ventaja de tener disponible el cdigo fuente del ncleo; en realidad Linux propiamente dicho es slo el ncleo. Esto nos permite la posibilidad de crear ncleos a medida de nuestras necesidades. Y parte de nuestras necesidades ser la mejora de la seguridad. Para compilar el ncleo primero tendremos que configurar las opciones que nos interesen. Los fuentes del ncleo se guardan habitualmente en el directorio /usr/src/linux, y una vez situados en l, tendremos que ejecutarmake menuconfig (o make xconfig si estamos en modo grfico). As nos aparecen todas las opciones de configuracin. Como el ncleo controla las caractersticas de red del sistema, es importante que el ncleo tenga las opciones que garanticen la seguridad y que el propio ncleo no pueda ser comprometido. Para prevenir algunos de los ltimos ataques de red, se debe intentar mantener una versin del ncleo actualizada. Una de las caractersticas ms interesantes del ncleo Linux es la posibilidad de realizar enmascaramiento de direcciones. Con esta tcnica podremos dar acceso a Internet a una red local con direcciones privadas de forma transparente, es decir, sin ningn tipo de modificacin en la configuracin de las aplicaciones clientes, a diferencia de los proxies clsicos. Consiste en que el sistema Linux que posee la conexin hacia el exterior recibe las peticiones de conexin desde los equipos de la red local que tienen direcciones no vlidas para Internet. El equipo Linux rehace la peticin poniendo su propia direccin 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 conexin. De esta forma podemos mantener un nivel aceptable de proteccin para los equipos de la red local, ya que slo podrn recibir respuestas a peticiones que ellos mismos originaron.

23

Opciones de compilacin del ncleo IP: Drop source routed frames (CONFIG_IP_NOSR) Esta opcin debera estar activada. Source routed frames contienen la ruta completa de sus destinos dentro del paquete. Esto significa que los enrutadores a travs de los que circula el paquete no necesitan inspeccionarlo, y slo lo reenvan. Esto podra ocasionar que los datos que entran a su sistema puedan ser un exploit potencial. IP: Firewalling (CONFIG_IP_FIREWALL) Esta opcin es necesaria si va a configurar su mquina como un cortafuegos, hacer enmascaramiento o desea proteger su estacin de trabajo con lnea telefnica de que alguien entre a travs de su interfaz PPP. Con esta opcin activa podremos usar el filtrado de paquetes en el propio ncleo del sistema, decidiendo el trfico que llega o sale de nuestro equipo. IP: forwarding/gatewaying (CONFIG_IP_FORWARD) Si activa reenvo IP (IP forwarding), su Linux esencialmente se convierte en un encaminador (router). Si su mquina est en una red, podra estar enviando datos de una red a otra, y quizs saltndose un cortafuegos que est puesto all para evitar que esto suceda. A los usuarios con un puesto aislado y conexin telefnica les interesar desactivar esta caracterstica. Otros usuarios deberan pensar en las implicaciones de seguridad de hacer esto en un caso concreto. Las mquinas que acten como cortafuegos tendrn que activar esta caracterstica y usarla junto al software cortafuegos. Se se puede activar y desactivar el reenvo IP (IP forwarding) dinmicamente usando el siguiente comando: root# echo 1 > /proc/sys/net/ipv4/ip_forward

y desactivarlo con el comando: root# echo 0 > /proc/sys/net/ipv4/ip_forward

Ese fichero (y muchos otros ficheros de /proc) aparecer con longitud cero, pero en realidad no es un fichero en el sentido clsico, sino que son datos guardados en memoria. IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) Esta opcin le suministra informacin sobre los paquetes que su cortafuegos recibe, como remitente, destinatario, puerto, etc. As podremos rastrear los orgenes de los posibles intentos de ataque.

24

IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) Generalmente esta opcin est desactivada, pero si est construyendo un host cortafuegos o para enmascaramiento, deber activarla. Cuando se envan paquetes de un host a otro, no siempre se envan como simples paquetes de datos, sino que se fragmentan en varios trozos. El problema es que los nmeros de puerto slo se almacenan en el primer fragmento. Esto significa que alguien se puede insertar informacin en el resto de los paquetes para la conexin que se supone que no deberan estar all. IP: syn cookies (CONFIG_SYN_COOKIES) El ataque SYN es un ataque de denegacin de servicio (denial of service, DoS) que consume todos los recursos de la mquina forzando un reinicio. No podemos encontrar ninguna razn por la que no debiera activar esto. Dispositivos del ncleo Hay algunos dispositivos de bloque y carcter disponibles en Linux que tambin le resultarn tiles para mantener la seguridad del sistema. Los dos dispositivos /dev/random y /dev/urandom los proporciona el ncleo para generar datos aleatorios en cualquier instante. Por ejemplo, se utilizan para iniciar un nmero de secuencia para conexiones TCP/IP. Ambos, /dev/random y /dev/urandom, deberan ser suficientemente seguros como para generar claves PGP, SSH y otras aplicaciones donde son un requisito nmeros aleatorios seguros para generar claves vlidas para una sesin. Los atacantes no deberan ser capaces de determinar el siguiente nmero dada cualquier secuencia de nmeros con este origen. Se han dedicado muchos esfuerzos para garantizar que los nmeros que se obtienen de esta fuente son pseudoaleatorios. La nica diferencia es que /dev/random suministra bytes aleatorios y le hace esperar para que se acumulen ms. Observe 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 tanto se debe tener cuidado al usar /dev/random. /dev/random tiene gran calidad de entropa, 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 mayora de las aplicaciones. Se se puede leer los dispositivos usando algo parecido a lo siguiente: root# head -c 6 /dev/urandom | uuencode -

25

Esto imprimir seis caracteres aleatorios en la consola, vlidos para la generacin de una clave.

SEGURIDAD DE RED Introduccin La seguridad de las conexiones en red merecen en la actualidad una atencin especial, incluso por medios de comunicacin no especializados, por el impacto que representan los fallos ante la opinin pblica. El propio desarrollo tanto de Linux, como de la mayora del software que lo acompaa, es de fuentes abiertas. Podemos ver y estudiar el cdigo. Esto tiene la ventaja de que la seguridad en Linux no sea una mera apariencia, sino que el cdigo est siendo escrutado por muchas personas distintas que rpidamente detectan los fallos y los corrigen con una velocidad asombrosa. Si adems comprendemos los mecanismos que se siguen en las conexiones en red, y mantenemos actualizados nuestros programas, podemos tener un nivel de seguridad y una funcionalidad aceptables. Tampoco tienen las mismas necesidades de seguridad un equipo domstico, con conexiones espordicas a Internet, que un servidor conectado permanentemente y que acte como pasarela entre una intranet e Internet. Para describir las pautas de actuacin seguras iremos examinando cmo actan las conexiones y cmo podemos protegerlas. inetd Para atender las solicitudes de conexin que llegan a nuestro equipo existe un demonio llamado inetd que est a la escucha de todos los intentos de conexin que se realicen a su mquina. Cuando le llega una solicitud de conexin ir dirigida a un puerto (nmero de servicio, quizs sea ms claro que puerto), por ejemplo, el 80 sera una solicitud al servidor de pginas web, 23 para telnet, 25 para smtp, etc. Los servicios de red que presta la mquina estn descritos en /etc/inetd.conf (y en /etc/services los nmeros de puertos). Por ejemplo, en /etc/inetd.conf podemos encontrar las siguientes lneas: (...) pop-3 stream tcp nowait root # imap stream tcp nowait root (...)

/usr/sbin/tcpd /usr/sbin/tcpd

ipop3d imapd

26

Esto quiere decir que, cuando llegue una solicitud de conexin al puerto 110 (pop3) se ejecutar el programa /usr/sbin/tcpd ipop3d. Sin embargo, el servicio imap est deshabilitado (est comentado con un # delante), por lo que el sistema no le responde. TCP Wrapper El siguiente paso es /usr/sbin/tcpd, que es el tcp_wrapper: un servicio que verifica el origen de las conexiones con la base de datos /etc/hosts.allow(equipos autorizados) y /etc/hosts.deny (equipos a los que se les deniega la conexin). tcpd anota todos los intentos de conexin que llegan en /var/log/securepara que tenga la posibilidad de saber quin intenta conectarse a la mquina y si lo consigue. Si tcpd autoriza la conexin, ejecuta ipop3d que es el programa que realmente atiende la conexin, ante el cual se tiene que validar el usuario mediante una clave. Se observa que ya llevamos tres niveles de seguridad: prestar un servicio, autorizar una conexin y validar un usuario. Tambin hay que asegurarse de que el programa ipop3d no tenga ninguna vulnerabilidad, es decir, que est actualizado. Existen numerosos medios para estar al da de las vulnerabilidades que aparecen. Una buena lista de correo o una revista electrnica tal vez sean la forma ms rpida de conocer los incidentes, las causas y las soluciones. Posiblemente la mejor lista de correo para el mundo Unix sea Bugtraq (busque en forums). Pero esto no es todo, adems se puede filtrar las conexiones que lleguen desde el exterior para que ni siquiera alcancen a los tcp_wrappers. Por ejemplo, en el caso de conexiones a Internet por mdem: ipchains -A input -j DENY -s 0/0 -d $4/32 23 -p tcp -i ppp0 l

poniendo la anterior lnea en el fichero /etc/ppp/ip-up (y ipchains -F input en ip-down) estaramos aadiendo (-A) un filtro de entrada (input), que deniega (-j DENY) desde cualquier sitio de internet (-s 0/0) dirigidas a nuestro equipo (-d $4/32) al puerto telnet (23) por tcp (-p tcp) que lleguen desde internet (en este caso -i ppp0) y que adems las anote en el registro de incidencias (-l) ($4 es la direccin IP que obtenemos dinmicamente. El mecanismo de filtrado de conexiones se realiza en el ncleo del sistema operativo y si ha sido compilado con estas opciones. Normalmente lo est. Este filtrado se realiza a nivel de red y transporte: cuando llega un paquete por un interfaz de red se analiza siguiendo los filtros de entrada. Este paquete se puede ser aceptado, denegado o rechazado, en este ltimo caso se avisa al remitente. Si los filtros de entrada aceptan el paquete, pasa al sistema si era su destino final o pasa por los filtros de reenvo o enmascaramiento, donde se vuelve a repetir una de las acciones. Por ltimo, los paquetes que proceden del propio sistema o los que han sido aceptados por los filtros de reenvo o enmascaramiento pasan al filtro de salida. En cualquiera de estos filtros se puede indicar que lo anote en el registro de incidencias.

27

Registro y conocimiento de incidencias A parte de todo esto, se puede conocer las incidencias que ocurren durante el funcionamiento del sistema. Por un lado conviene familiarizarse con los procesos que se ejecutan habitualmente en una mquina. Es una buena costumbre ejecutar peridicamente ps axu. Cualquier cosa extraa debiramos aclararla. Se puede matar cualquier proceso con la orden kill -9 pid (o killall -9 nombre_proceso). Pero en caso de ataque activo, lo mejor es desconectar de la red inmediatamente, si es posible, claro est. Despus tenemos los registros de incidencias (las ubicaciones se pueden ser diferentes dependiendo del sistema, pero no radicalmente distintas) de /var/log. Trabajando en modo texto se se puede hacer en una consola virtual (comoroot) tail -f /var/log/messages

y tail -f /var/log/secure

y de esta forma podemos ir viendo las incidencias del sistema. Conviene tambin familiarizarse con las anotaciones que aparecen habitualmente para diferenciarlas de las que puedan presentar un problema. En modo grfico hay un programa llamado ktail que le muestra las incidencias de una forma similar a la anterior. Comunicaciones seguras Por ltimo, nos interesar mantener unas comunicaciones seguras para garantizar la privacidad e integridad de la informacin. Actualmente existen las herramientas necesarias para cada necesidad. Podemos usar cifrados simtricos como pgp y gpg para documentos, correo electrnico y comunicaciones sobre canales inseguros Podemos crear canales de comunicacin seguros de distinto tipo:

SSH (Secure Shell), stelnet: SSH y stelnet son programas que le permiten efectuar conexiones con sistemas remotos y mantener una conexin 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 conexin, lo hace a nivel de socket. As un conexin lgica entre programas que
28

se ejecutan en hosts diferentes est cifrada. CIPE se 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 ningn cambio en el software de aplicacin. SSL: o Secure Sockets Layer, fue diseado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versin del Navigator como un protocolo para dotar de seguridad a las sesiones de navegacin a travs de Internet. Proporciona los siguientes servicios: o Cifrado de datos: la informacin transferida, aunque caiga en manos de un atacante, ser indescifrable, garantizando as la confidencialidad. o Autenticacin de servidores: el usuario se puede asegurarse de la identidad del servidor al que se conecta y al que posiblemente enve informacin personal confidencial. o Integridad de mensajes: se impide que modificaciones intencionadas o accidentales en la informacin mientras viaja por Internet pasen inadvertidas. o Opcionalmente, autenticacin de cliente: permite al servidor conocer la identidad del usuario, con el fin de decidir si se puede acceder a ciertas reas protegidas.

SEGURIDAD DEL ROOT Introduccin A menudo, el mayor enemigo del sistema es el propio administrador del sistema, s, tiene todos los privilegios y cualquier accin puede ser irreversible y hacerle perder posteriormente mucho ms tiempo que el que hubiera perdido por realizar las tareas de forma segura. Se puede borrar cualquier fichero e incluso destruir el propio sistema, mientras que un usuario normal slo puede perjudicarse a s mismo. Por estos motivos, conseguir privilegios de root es la meta de cualquier ataque. Tampoco hay que alarmarse. Un sistema operativo monousuario cualquiera podra darle formato al disco duro y perder toda la informacin almacenada o borrar cuaquier fichero necesario para el funcionamiento del sistema. En un sistema estilo Unix, como Linux, esto slo lo podra hacer el usuario root. Hbitos seguros La seguridad del administrador es simple, en mayor medida consiste en tener unos hbitos seguros y tambin en utilizar herramientas seguras. Una primera norma que siempre se debera tener presente es usar la cuenta de root slo 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 opinin poco a
29

poco, conforme se van familiarizando con el sistema o cuando han realizado un destrozo de esos que nos hacen proferir insultos contra nosotros mismos acompaados de un desesperado puetazo en la mesa (o en el teclado). Piense que cuando el sistema le deniega alguna operacin es porque se puede conllevar algn riesgo. El sistema le avisa para que piense dos veces lo que est haciendo. En los casos de tareas que necesiten privilegios de administrador para realizar una operacin concreta, podemos usar la orden su (Super Usuario) o tambin sudo. De esta forma podremos acceder a los privilegios de root slo cuando nos interese.

PREPARACION PARA LA SEGURIDAD La seguridad es un proceso continuo, que requiere tener previsto hasta lo imprevisible. Tener unos buenos hbitos y tomar unas pequeas precauciones nos ayudarn mucho. Determinar los servicios activos Desactivar todos los servicios que no se vaya a prestar, en particular revisar los ficheros /etc/inittab, /etc/inetd.conf y los demonios que se lanzan durante el arranque. Si no se est realmente seguro de lo que se hace, mejor no hacer nada; las distribuciones ms modernas incorporan unos mnimos de seguridad aceptables para un usuario medio. No tiene sentido tener abierto un servicio del que no se va a hacer uso ningn usuario legal. Se puede que est consumiendo recursos del sistema para ofrecer a algn atacante la posibilidad de violarlo. Se puede 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 minidistribucin de Linux totalmente portable que se ejecuta por completo en RAM, puedindose usar desde cualquier equipo para la red. Se arranca desde la unidad q lo lleva y no utiliza el disco duro para nada. Contiene las ltimas versiones de algunas herramientas muy prcticas enfocadas a la seguridad en redes. Nos permitir analizar el trfico de la red, analizar puertos e incluso ver el contenido de los paquetes que circulan por la red. Proteger los ficheros importantes Existe un parche para el ncleo Linux que impide que ciertos ficheros puedan ser modificado, incluso por el propio root. El ncleo parcheado de esta forma se puede garantizarnos la integridad de la informacin almacenada incluso en el caso de que alguien consiguiera privilegios de root en nuestro sistema. Si no queremos aplicar el parche, deberamos vigilar los permisos de ficheros y directorios.

30

Software actualizado La gran mayora del software que acompaa a Linux es de cdigo fuente pblico, como el propio ncleo. Esto es una garanta de seguridad en s. Cientos de expertos analizan minuciosamente el cdigo para detectar alguna pega que poder publicar en las listas de correo sobre seguridad ms 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. Prevenir prdidas de informacin Existen acontecimientos de los que nos se puede resultar muy difcil protegernos como son los desastres naturales, nicamente podremos seguir una serie de pasos para evitar que su incidencia sea lo menor posible. La mejor solucin es mantener un buen conjunto de copias de seguridad sobre toda la informacin necesaria del sistema. Hay que pensar que las copias de seguridad no slo nos protegen de desastres naturales, tambin de los desastres que pueda ocasionar algn intruso en nuestro sistema, de cualquier ataque a la disponibilidad o integridad de la informacin del sistema. Hay que tener cuidado y almacenar la copia de seguridad en un sitio seguro. Una buena copia de seguridad le asegura que tiene un buen punto desde el cual restaurar su sistema. Caractersticas de las copias de seguridad Cuando se realice una copia de seguridad es conveniente seleccionar un mtodo que garantice la conservacin de las caractersticas de la informacin 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 global puede ser impredecible. Copiar las Bases de Datos del Sistema Existe cierta informacin del sistema que es imprescindible para su correcto funcionamiento. Es conveniente tener una copia de estos ficheros en una ubicacin segura. En particular resulta conveniente tener una copia del contenido del directorio /etc. Tambin 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 estn cifradas. Tambin en cada sistema se puede tener una base de datos de las aplicaciones que hay instaladas en el servidor. Cada distribucin dispone de alguna herramienta que nos realiza el mantenimiento de la base de datos al mismo tiempo que instala o desinstala aplicaciones. La prdida de esta base de datos nos hara perder el control sobre qu aplicaciones tenemos instaladas.
31

En muchas situaciones tambin ser necesario tener copia de seguridad de los ficheros de registro de incidencias, para tener constancia de las distintas actividades del sistema.

32

Conclusin Lo primero que tenemos que determinar es lo que queremos proteger. No ser lo mismo una estacin de trabajo personal aislada con conexiones a Internet espordicas que un servidor web con conexin permanente o un cortafuegos. Tambin tendremos que considerar el coste de lo que queremos proteger: posible coste econmico, tiempo de restauracin o instalacin, prestigio, prdida de clientes, etc. Tambin el coste de la seguridad en unos trminos parecidos a los anteriores. Sera absurdo que invirtiramos ms en proteccin que el coste de lo protegido.

Suscribirse a las listas de correo de alertas de seguridad para estar actualizado. Prestar atencin a los ficheros de registro. Actualizar el software inseguro. Verificar regularmente la integridad de los ficheros con algn 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 peridicamente las cuentas de usuario. Asignar cuotas de uso de recursos del sistema. Mantener los terminales seguros. Asegurarse de tener claves slidas. Mantener el sistema de ficheros con propietarios y permisos adecuados. Instalar cortafuegos.

Tambin hay que considerar que existe una relacin inversa entre seguridad y funcionalidad. Cuanto ms seguro hacemos un sistema, menos funcional resulta, ofreciendo menos servicios y ms limitaciones de acceso. Esto tambin constituye otro coste adicional: facilidad de uso. Despus de saber qu y de qu tenemos que protegernos, de quines y cules son sus posibles objetivos, y viendo los servicios que necesariamente hay que prestar o usar, obtendremos un esquema elemental de nuestra situacin y de las medidas que tenemos que tomar.

33

BIBLIOGRAFIA SEGURIDAD EN UNIX Y REDES Versin 2.1. Antonio Villaln Huerta.

http://www.tel.uva.es/~celgom/seguridad/seguridad.html
http://www.iec.csic.es/ http://es.wikipedia.org/ http://www.jollycom.ca/iptables-tutorial/iptables-tutorial.html

34