PROBLEMAS DE SEGURIDAD EN EL MUNDO UNIX - LINUX

1.- Introduccin 1.1.- Conceptos generales sobre seguridad 1.2.- Polticas de seguridad 1.3.- Seguridad por ocultacin 2.- Clasificacin de Sistemas operativos confiables: Libro Naranja 2.1.- Introduccin 2.2.- Clases de seguridad 2.2.1.- D: seguridad mnima 2.2.2.- C1: proteccin mediante seguridad discrecional 2.2.3.- C2: proteccin mediante accesos controlados 2.2.4.- B1: proteccin mediante seguridad etiquetada 2.2.5.- B2: proteccin estructurada 2.2.6.- B3: dominios de seguridad 2.2.7.- A1: diseo verificado 2.2.8.- Tabla resumen 3.- Mecanismos de seguridad de UNIX 3.1.- Introduccin 3.2.- Usuarios y grupos en UNIX 3.2.1.- Cuentas de usuario 3.2.2.- El archivo /etc/passwd 3.2.3.- Identificador de usuario (UID) 3.2.4.- Grupos 3.2.5.- El archivo /etc/group 3.2.6.- Identificador de grupo (GID) 3.2.7.- Contraseas 3.2.8.- Usuarios especiales: el superusuario 3.2.9.- El comando su 3.3.- El sistema de ficheros de UNIX 3.3.1.- Introduccin 3.3.2.-Tipos bsicos de archivos

3.3.3.- Inodos o nodos indice 3.3.4.- Fechas de los archivos 3.3.5.- Permisos de un archivo 3.3.6.- SUID, SGID y los bits adhesivos 3.3.6.1.- Cambio de UID: setuid() 3.3.7.- Listas de control de acceso (ACLs) 3.3.8.- Archivos de dispositivo 3.3.9.- Sistemas de ficheros montados 4.- Mantenimiento de sistemas confiables 4.1.- Introduccin 4.2.- Criptografa 4.3.- Defensa de cuentas 4.3.1.- Cuentas sin contrasea 4.3.2.- Cuentas predeterminadas 4.3.3.- Cuentas que ejecutan slo una instruccin 4.3.4.- Cuentas abiertas 4.3.4.1.- interpretes de comandos restringidos 4.3.4.2.- Sistemas de archivos restringidos 4.4.- Auditora 4.4.1.- Introduccin 4.4.2.- El sistema de log en UNIX 4.4.3.- El demonio syslogd 4.4.4 Algunos archivos de log 4.5.- Amenazas programadas 4.5.1.-Introduccin 4.5.2.-Base Fiable de Cmputo 4.5.3.-Tipos de amenazas programadas 4.5.4.-Programacin segura 4.5.4.1.-Buffer overflow 4.5.4.2.- Recomendaciones para una programacin segura 4.5.4.3.- Utilizacin segura de funciones de biblioteca 5.- Bibliografa

1.- Introduccin.
1.1.- Conceptos generales sobre seguridad.
Seguridad informtica "Una computadora es segura si se puede confiar en que, junto con sus programas, funcione como se espera." Una computadora se considera segura (o confiable, introduciremos este concepto ms adelante) si los datos contenidos en ella seguirn estando all y nadie que no deba leerlos los lea. Segn esto, los desastres naturales y los errores de programacin son amenazas a la seguridad al igual que los usuarios no autorizados. Por lo tanto no existe diferencia si los datos se pierden por actos de un estudiante vengativo, por un virus, un error inesperado o un rayo: los datos se han perdido de igual forma. Seguridad y UNIX Dennis Ritchie dijo sobre UNIX: "No se dise para ser seguro. Se dise para que se pudiera usar la seguridad." UNIX es un sistema operativo multiusuario y multitarea. Una de las funciones naturales de estos sistemas es prevenir que distintos usuarios o programas que estn usando la misma computadora se estorben. Si no existiera esta proteccin un programa podra afectar al funcionamiento de los programas de otros usuarios, borrar accidentalmente datos e incluso parar todo el sistema. Para evitar esto UNIX siempre ha contado con algn tipo de mecanismos de seguridad. Pero esta seguridad no se limita a la proteccin de la memoria. UNIX posee un sistema de archivos que controla la forma en que los usuarios acceden a los archivos y a los recursos del sistema. La mayor parte de los fallos de seguridad que se han encontrado se deben a problemas de configuracin y programas con errores, y no a defectos en el diseo del sistema. Confiabilidad Al referirse al nivel de seguridad de un sistema operativo, no es habitual utilizar los trminos "seguro" o "inseguro" , sino que se usa el trmino "confiable" para describir el nivel de confianza que se tiene en que un sistema se comporte como se espera. Esto implica que no se puede lograr la seguridad absoluta, sino que se trata de acercarse a ella intentando conseguir un grado de confianza suficiente

para garantizar el funcionamiento correcto del sistema, dependiendo del contexto en el que se encuentre.

1.2.- Polticas de seguridad.

A pesar de no ser el objetivo fundamental de este trabajo, es importante considerar el establecimiento de polticas de seguridad a la hora de estudiar la seguridad de un sistema informtico. Debido a esto, resumiremos los conceptos ms relevantes de las polticas de seguridad. La planificacin de las polticas de seguridad se dividen en seis etapas diferentes: a.-Planificacin de las necesidades de seguridad: Existen diferentes clases de seguridad, por lo que, dependiendo del tipo de sistema, habr que dar mayor o menor importancia a las que tengan ms relevancia: Confidencialidad: Impedir el acceso a la informacin a usuarios no autorizados. Integridad de los datos: Evitar el borrado o alteracin indeseados de la informacin, incluidos los programas. Disponibilidad: Asegurar que los servicios est siempre disponibles para un usuario autorizado. Consistencia: Asegurar que el sistema se comporta como esperan los usuarios autorizados; imagine lo que ocurrira si el comando ls borrara archivos de vez en cuando en lugar de listarlos. Control: Reglamentar el acceso al sistema, de forma que programas e individuos no autorizados y desconocidos no alteren el normal funcionamiento del sistema. Auditora: Determinar qu se hizo, quin lo hizo y qu fue afectado. Para esto es necesario llevar un registro inexpugnable de todas las actividades realizadas en el sistema y que identifica de forma no ambigua a los usuarios que las llevaron a cabo. b.-Anlisis de riesgos: Trata de responder a tres preguntas: qu se debe proteger?, contra qu debe protegieres?, cunto se est dispuesto a invertir para obtener una proteccin adecuada?. Para responder a estas preguntas, el anlisis de riesgos se divide en tres etapas: Identificacin de los activos.

Identificacin de las amenazas. Clculo de los riesgos. c.- Anlisis de costo-beneficio. Consiste en asignar un costo a cada riesgo, y determinar el costo de defenderse. De esta manera se puede decidir qu medidas hay que adoptar para proteger qu activos. Este aspecto no lo desarrollaremos por que no entra en el mbito de este estudio. d.-Polticas de seguridad. Las polticas sirven para definir qu se considera valioso y especifican qu medidas hay que tomar para proteger esos activos. Deben aclarar qu se est protegiendo, establecer la responsabilidad de la proteccin y poner las bases para resolver e interpretar conflictos posteriores. No deben hacer una lista de riesgos especficos, computadoras o individuos por nombre. Deben ser generales y no variar mucho a lo largo del tiempo. e.-Implementacin. f.- Auditora y respuesta ante incidentes. Estos dos ltimos apartados constituyen el resto de este trabajo.

1.3.- Seguridad por ocultacin

Esta costumbre proviene de las aplicaciones militares, donde la ocultacin es una forma efectiva de proteccin. Pero trasladar este concepto a un ambiente de computacin no resulta apropiado, pudiendo resultar incluso daino para la seguridad. La ocultacin presenta bastantes inconvenientes. Por ejemplo, al negar el acceso a los manuales a los usuarios, un administrador puede pensar que ha mejorado la seguridad al impedir a estos el conocimiento de comandos y opciones que pueden usarse para penetrar el sistema. Sin embargo, resulta sencillo conseguir esa documentacin por diversos medios (universidades, Internet, libreras, ...), por lo que los administradores no pueden impedir que los usuarios accedan a la documentacin. Adems, esto redunda en una prdida de eficacia de los usuarios, al no poder consultar los manuales. Esto tambin conlleva una actitud negativa porque da a entender que no se confa en los usuarios. Los errores de programacin o caractersticas excepcionales son tambin objeto habitual de la ocultacin, pero esto tambin es una mala poltica. Los desarrolladores colocan frecuentemente puertas traseras en sus programas

que permiten obtener privilegios sin autentificarse debidamente. Otras veces esto permite que errores de programacin que afectan gravemente a la seguridad del sistema persistan ya que se supone que nadie los conoce. El problema es que estos agujeros de seguridad tienden a ser descubiertos por accidente o por intrusos persistentes. Otra prctica habitual es mantener en secreto algoritmos desarrollados localmente, tales como algoritmos de cifrado. Esto tambin presenta algunos inconvenientes. Sin un estudio en profundidad estos podran presentar graves fallos de seguridad, y este estudio no es posible si se mantienen en secreto. Desde el punto de vista de los sistemas operativos, mantener el cdigo fuente en secreto no garantiza la seguridad. Si un intruso desea penetrar en el sistema, antes o despus descubrir algn fallo de seguridad (estos siempre existen), pero el resto de usuarios bienintencionados no podr revisar el cdigo en busca de estos fallos. Es mejor usar algoritmos y mecanismos robustos aunque sean conocidos por los enemigos, ya que esto adems puede desalentar a un posible atacante consciente de la fiabilidad del mecanismo. "Poner dinero en una caja fuerte es mejor que esconderlo en un frasco de mayonesa en la cocina porque nadie sabe que est all."

2.- Clasificacin de Sistemas operativos confiables: Libro Naranja.

2.1.- Introduccin
El Libro Naranja (Trusted Computer System Evaluation Criteria), elaborado por el Ministerio de Defensa de los E.E.U.U en 1983, establece criterios para medir la fiabilidad de los sistemas informticos en lo respectivo a la seguridad. Antes de describir los diferentes niveles de seguridad, es necesario conocer algunos conceptos relevantes : Base fiable de cmputo(TCB): Es el conjunto de mecanismos relevantes a efectos de la seguridad del sistema. En las clases con una fiabilidad elevada, la TCB se construye en torno a un monitor de referencias que impone las relaciones de acceso autorizadas entre los sujetos y objetos de un sistema. Control de accesos discrecional: Permite restringir el acceso a los objetos basndose en la identidad de los usuarios y/o grupos de usuarios a

los que pertenecen. Los usuarios protegen sus objetos indicando quin puede acceder y el tipo de acceso permitido. Reutilizacin de objetos: Implica proteger ficheros, memoria y otros objetos de accesos por parte de un usuario tras su uso por otro. Por ejemplo: Un usuario crea un fichero en el que almacena informacin confidencial y despus lo borra. A continuacin otro usuario malicioso reserva espacio en el disco y el sistema le asigna esos mismos bloques. Si el sistema no borra fsicamente la informacin del usuario anterior, el otro usuario podra leer la informacin borrada por el dueo original . Etiquetas: Las etiquetas de confidencialidad se asocian a cada sujeto (usuario, proceso) y a cada objeto (fichero, directorio, ...) e indican su nivel de autoridad asociado y se denomina habilitacin. La etiqueta de confidencialidad de un fichero especifica el nivel de autoridad que un usuario debe tener para acceder al mismo. Identificacin y autentificacin: Es necesario que los usuarios se identifiquen antes de realizar cualquier actividad que implique una interaccin con la TCB (ejecutar un programa, leer un fichero). En los sistemas UNIX la identificacin se realiza mediante un nombre de conexin (login) y la autentificacin mediante una contrasea (password). Va fiable: En algunos sistemas se requiere que los usuarios puedan conectarse desde un terminal al sistema a travs de lo que llamaremos una va fiable. Para ello existe una secuencia de teclas, que al pulsarse elimina todos los procesos actuales y establece una conexin segura con la TCB permitiendo su autentificacin. Esto evita ataques sistemticos contra el sistema mediante programas marcadores y la introduccin de caballos de Troya en los programas de conexin al sistema Auditoria: Es el registro y examen de la actividades relacionadas con la seguridad en un sistema fiable. Las actividades relacionadas con la seguridad son los accesos (y sus intentos) de un sujeto sobre un objeto y suelen denominarse sucesos. Cada vez que se produce un suceso, debe almacenarse en el registro de auditoria la siguiente informacin: fecha, hora, identificador del usuario, tipo, si ha tenido xito, terminal, nombre de objeto, descripcin de las modificaciones en la TCB y clases de seguridad del sujeto y del objeto. Arquitectura del sistema: Estn relacionados con el diseo de un sistema para que sea posible la seguridad." Integridad del sistema: Se refiere al conjunto de pruebas de integridad que se ejecutan siempre que se arranca el ordenador, o peridicamente siguiendo un mantenimiento preventivo (en UNIX, se lleva a cabo un chequeo del sistema de ficheros cada vez que se monta un determinado numero de veces).

Canales ocultos: Son rutas de informacin que habitualmente no se utilizan como medio de comunicacin en el sistema y, por lo tanto, no estn protegidos por sus mecanismos de seguridad. Utilidad para la administracin de la fiabilidad: Implica asignar todas las actividades de seguridad a una persona diferente al administrador de sistema. Esto se basa en el principio de que es mejor asignar las actividades de seguridad a varias personas, para que el control total no recaiga sobre una sola persona, lo que podra comprometerlo. Gestin de configuracin: protege a un sistema fiable mientras se disea, desarrolla y mantiene. Implica controlar todos lo cambios realizados en la TCB. As se mantiene un control del sistema durante su ciclo de vida, asegurando que el sistema que se utiliza no es una versin antigua del mismo. Distribucin segura: Garantiza la proteccin del sistema mientras se enva a un cliente, asegurando que el sistema que recibe es idntico al suministrado por el vendedor. Gua de usuario sobre las caractersticas de seguridad: I ndica a los usuarios no privilegiados del sistema todo lo que deben saber sobre la seguridad. Manual para la administracin de la seguridad: Proporciona a los administradores toda la informacin necesaria para establecer e implantar la seguridad del sistema Documentacin de pruebas: Debe contener un plan de pruebas con el objeto de encontrar cualquier posible error en el diseo o implementacin de la TCB, que permite a un usuario acceder a informacin no autorizada. Documentacin de diseo: Permite conocer la construccin interna de la TCB, ayudando a los equipos de diseo y desarrollo a definir el modelo de seguridad del sistema y su construccin.

2.2.- Clases de seguridad

El Libro Naranja divide su clasificacin en cuatro niveles de seguridad. Los requisitos para un determinado nivel siempre lo son para el siguiente, pudiendo este restringir ms an los criterios, ya que se trata de una jerarqua de niveles:

2.2.1.- D: seguridad mnima

En esta categora estn englobados todos los sistemas que han sido valorados y no han superado los requisitos mnimos para pertenecer a un nivel de seguridad superior. En esta categora no existen requisitos de seguridad."

En realidad ningn sistema pertenece a esta categora, puesto que ningn vendedor evaluara un sistema para obtener un nivel de seguridad "D". Ordenadores bajo MS-DOS o las versiones personales de Windows (familia 9x), adems de otros sistemas antiguos son un ejemplo de sistemas que perteneceran a esta categora.

2.2.2.- C1: proteccin mediante seguridad discrecional

Todos los usuarios manejan los datos al mismo nivel . En este nivel se procura evitar que los usuarios cometan errores y daen al sistema. Las caractersticas mas importantes de este nivel son el control de autentificacin mediante contraseas y la proteccin discrecional de los objetos. El cdigo del sistema debe estar protegido frente a ataques procedentes de programas de usuario (en UNIX, un proceso no puede salirse de su espacio virtual de direcciones ,y si lo intenta, morir. Un sistema de este nivel no necesita distinguir entre usuarios individuales, Tan solo entre tipos de accesos permitidos o rechazados. En UNIX C1 hay que ser dueo de un objeto para ceder sus derechos de accesos y siempre se protege a los objetos de nueva creacin.

2.2.3.- C2: proteccin mediante accesos controlados

A partir de este nivel, el sistema debe ser capaz de distinguir entre los usuarios individuales. Generalmente el usuario debe ser dueo de un objeto para ceder los derechos de acceso sobre l. En la mayora de los sistemas UNIX a partir de este nivel, existen listas de control de acceso (ACLs). Debe permitir que los recursos del sistema se protejan mediante accesos controlados. En UNIX el acceso a los perifricos (dispositivos de E/S) siguen un esquema de permisos idntico al de los ficheros de los usuarios. Se aplican los requisitos de reutilizacin de objetos cuando esos mismos se reasignan. Se requiere a partir de este nivel que el sistema disponga de auditoria. Por ello cada usuario debe tener un identificador nico que se utiliza para comprobar todas las acciones solicitadas. Se deben auditar todos los sucesos relacionados con la seguridad y proteger la informacin de la auditoria. El sistema debe ser capaz de auditar a nivel de usuario. La mayor parte de los UNIX comerciales pertenecen a este nivel, puesto que lo nico que han tenido que aadir los fabricantes es un paquete de auditoria.

2.2.4.- B1: proteccin mediante seguridad etiquetada

A partir de este nivel, los sistemas poseen un sistema de control de accesos obligatorio que implica colocar una etiqueta a los objetos (principalmente sobre los ficheros). Esto, junto con el nivel de habilitacin de los usuarios es utilizado para reforzar la poltica de seguridad del sistema. En estos

sistemas, el dueo no es el responsable de la proteccin del objeto, a menos que disponga de la habilitacin necesaria. En cuanto a la auditoria, el sistema debe ser capaz de registrar cualquier cambio o anulacin en los niveles de seguridad, y tambin hacerlo selectivamente por nivel de seguridad." Debe existir una documentacin que incluya el modelo de seguridad soportado por el sistema. No es necesaria una demostracin matemtica, pero si una exposicin de las reglas implantadas por las caractersticas de seguridad del sistema.

2.2.5.- B2: proteccin estructurada

A partir de este nivel, los cambios en los requisitos no son visibles desde el punto de vista del usuario respecto de los niveles anteriores. En B2, todos los objetos del sistema estn etiquetados, incluidos los dispositivos. Deben existir vas fiables que garanticen la comunicacin segura entre un usuario y el sistema. Los sistemas deben ser modulares y utilizar componentes fsicos para aislar las funciones relacionadas con la seguridad de las dems. Requieren una declaracin formal del modelo de seguridad del sistema, y que haya una gestin de la configuracin. Tambin deben buscarse los canales ocultos.

2.2.6.- B3: dominios de seguridad

Es necesario que exista un administrador de seguridad, que sea alertado automticamente si se detecta una violacin inminente de la seguridad. Deben existir procedimientos para garantizar que la seguridad se mantiene aunque el ordenador se caiga y luego rearranque. Es obligatoria la existencia de un monitor de referencia sencillo, a prueba de agresiones e imposible de eludir. La TCB debe excluir todo el cdigo fuente que no sea necesario para proteger el sistema.

2.2.7.- A1: diseo verificado

Esta es la clase de certificacin ms alta, aunque el Libro Naranja no descarta la posibilidad de exigir requisitos adicionales. Son sistemas funcionlmente equivalentes a B4. Tan solo se aade la distribucin fiable que refuerza la seguridad. Los sistemas A1 tienen la confiabilidad adicional que ofrece el anlisis formal y la demostracin matemtica de que el diseo del sistema cumple el modelo de seguridad y sus especificaciones de diseo. En la siguiente tabla se resumen las caractersticas principales de los diferentes niveles de seguridad definidos en el Libro Naranja:

2.2.8.- Tabla resumen

Requisito Control de accesos discrecional Reutilizacin de objetos Dispositivos mononivel/multinivel Control de accesos obligatorio Etiquetas Identificacin y autentificacin Auditoria Vas fiables Arquitectura del sistema Integridad del sistema Pruebas de seguridad Especificacin y verificacin del diseo Canales ocultos Facilidad para la administracin de la fiabilidad Gestin de configuracin Recuperacin segura Distribucin segura Gua de usuario de seguridad Gua de administracin de la seguridad Documentacin de pruebas Documentacin de diseo

C1 nue no no no no nue no no nue nue nue no no no no no no nue nue nue nue

C2 mej nue no no no mej nue no mej sin mej no no no no no no sin mej sin sin

B1 sin sin nue nue no mej mej no mej sin mej nue no no no no no sin mej sin mej

B2 sin sin sin mej nue sin mej nue mej sin mej mej nue nue nue no no sin mej mej mej

B3 mej sin sin sin sin sin mej mej mej sin mej mej mej mej sin nue no sin mej sin mej

A1 sin sin sin sin sin sin sin sin sin sin mej mej mej sin mej sin nue sin sin mej mej

Leyenda: no: no existe criterio en esta clase. nue: criterio nuevo para esta clase mej: nuevos requisitos para el criterio en esta clase. sin: no existen requisitos adicionales para el criterio en esta clase.

3.- Mecanismos de seguridad de UNIX

3.1.- Introduccin
En este captulo se destacan los principales mecanismos de seguridad de UNIX, es decir, aquellos recursos que el sistema operativo proporciona y que conforman la base sobre la que se establece la seguridad. El conocimiento de estos mecanismos por parte del administrador de seguridad es completamente imprescindible, puesto que, bien utilizados permiten que el sistema se muestre robusto ante cualquier ataque o fallo. Por otro lado, mal utilizados proporcionarn una puerta abierta a cualquier atacante o convertirn un programa inocente en un autntico agujero de seguridad.

3.2.- Usuarios y grupos en UNIX

Las cuentas de usuario son el primer objetivo de cualquier atacante, su finalidad suele ser casi siempre esta, penetrar en el sistema consiguiendo apoderarse de una cuenta de usuario (preferentemente la del root ). Despus pueden robar, destruir o falsificar datos o simplemente dejar una nota, pero el dao ya est hecho: la seguridad del sistema se ha visto comprometida. 3.2.1.- Cuentas de usuario Como se seala en el captulo anterior, la identificacin en los sistemas UNIX se realiza mediante un nombres de usuarios (login) y la autentificacin mediante contraseas (password). Los nombres de usuario se conocen tambin como nombres de cuenta. Para iniciar una sesin en un sistema UNIX, es necesario conocer tanto el nombre de usuario como la contrasea correspondiente. Por ejemplo, Manuel Rodrguez posee una cuenta en el servidor de practicas de su universidad. Su nombre de usuario es manurod y su contrasea es "as35FgS". Cuando Manuel desee iniciar una sesin de trabajo en el laboratorio, deber autentificarse como usuario autorizado ante la mquina de la siguiente manera: Bienvenido al servidor X de la Universidad Y login: manurod password: as35FgS De esta manera, el usuario queda totalmente autentificado y obtendr un interprete de comandos (shell) desde el que podr realizar

diferentes tareas. Otra posibilidad es que el servidor disponga de un entorno de trabajo en modo grfico (X-Window), en ese caso el proceso de autentificacin se realiza de idntica manera, con la nica diferencia de que el usuario obtendr un entorno grfico de trabajo en lugar del shell habitual. Los nombres de usuario estndar en UNIX tienen una longitud que puede ir de 1 a 8 caracteres. Estos nombres deben ser nicos en una misma computadora, puesto que deben identificar al usuario de forma inequvoca (despus se vera que esto no es estrictamente cierto, puesto que dos usuarios pueden compartir el mismo UID). Las contraseas en UNIX tradicionalmente tenan una longitud de entre 1 y 8 caracteres, aunque algunas versiones comerciales permiten contraseas mas largas. El uso de contraseas mas largas implica una mayor seguridad, por que son mas difciles de adivinar. La contrasea no debe ser obligatoriamente nica para cada usuario, varios usuarios pueden tener, de hecho, la misma contrasea, aunque de ser as, esto indicara que estos usuarios han elegido una mala contrasea. La eleccin de las contraseas, as como las posibles restricciones que se pueden establecer sobre ellas, es de vital importancia a la hora de evitar intrusiones en el sistema, por ello, se dedicar a esto otro apartado. 3.2.2.- El archivo /etc/passwd En los sistemas tipo UNIX , la informacin sobre las cuentas de usuario se almacenan en una base de datos localizada en el archivo /etc/passwd. Esta es un fichero de texto en el que los diferentes registros se encuentran separados por el carcter dos puntos (:). Se puede emplear el comando cat para visualizar el contenido del fichero passwd. A continuacin se puede ver una muestra de un archivo tpico como ejemplo :
root:o8o7aSVh13nLD:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/var/spool/news: uucp:*:10:14:uucp:/var/spool/uucp:

operator:*:11:0:operator:/root: ftp:*:14:50:FTP User:/home/ftp: nobody:*:99:99:Nobody:/: manurod:EH5/.mj7J5dFh:501:100:Manuel Rodrguez:/home/alumnos/manurod:/bin/bash maripet:aCq87MC03c9e:502:100:Mario Petru:/home/alumnos/maripet:/bin/bash javitup:md0mHM86yn3aW:503:100:Javier Tup:/home/alumnos/javitup:/bin/bash

Algunas de las cuentas del ejemplo son cuentas del sistema como root,daemon o apm. El resto son cuentas de usuario regulares del sistema como manurod, javitup, maripet. Las cuentas que tienen un * en al campo de la contrasea no pueden ser utilizadas para iniciar una sesin desde un terminal, es necesario utilizar la orden su. Son cuentas de sistema (en ocasiones usuarios 'castigados'), que poseen archivos, a veces muy importantes, que realizan tares administrativas o dan servicios. Cada campo individual del archivo passwd posee un significado directo. En la siguiente tabla se explica el significado de una de las lneas del ejemplo: Campo manurod EH5/.mj7J5dFh 501 500 Manuel Rodrguez /home/alumnos/manurod/ /bin/bash Contenido Nombre de usuario Contrasea cifrada del usuario Numero de identificacin del usuario (UID) Numero de identificacin de grupo del usuario (GID) Nombre completo del usuario Directorio base del usuario Interprete de comandos del usuario

La contrasea se guarda cifrada. La contrasea en s no se guarda tal cual en el sistema, si as se hiciera, esto representara un grave riesgo

para la seguridad, y solo es aceptable cuando la poltica de seguridad lo admita por razones particulares. En la actualidad, muchas organizaciones poseen grandes redes de tipo cliente-servidor que contienen muchos servidores y una gran cantidad de estaciones de trabajo. Normalmente es deseable que los usuarios entren en cualquiera de estas computadoras, y que lo hagan con el mismo nombre de usuario y la misma contrasea. Esto conlleva que cada usuario tenga una cuenta en cada estacin de trabajo. Este requisito hace que sea extremadamente difcil mantener la coherencia entre las bases de datos de usuarios de todas las computadores. Para lograr esto se utilizan diversos paquetes software que proporcionan el contenido del fichero /etc/passwd a toda la red. Algunos de estos sistemas son: Network Information System (NIS:Sistema de Informacin para la Red) de Sun Microsystems. NIS+ de Sun Microsystems Distributed Computing Environment (DCE: Ambiente de Computacin Distribuido) de Open Software Foundation. NetInfo de NeXT Computers Todos estos sistemas toman la informacin, que por lo general, est almacenada en cada estacin de trabajo y la ponen en una o mas computadoras que se usan como servidores de red. Al usar estos sistemas, ya no se puede usar simplemente el comando cat , sino que hay que utilizar una instruccin especifica para cada sistema para ver el contenido del archivo /etc/passwd. El servicio NIS de Sun complementa la informacin almacenada en los archivos de las estaciones de trabajo. Por lo tanto, para ver la lista completa de las cuentas de usuario, es necesario listar el contenido del archivo passwd local y ademas utilizar la siguiente instruccin: % ypcat passwd El servicio NIS+, tambin de Sun, se puede configurar para complementar sustituir sus entradas sobre cuentas de usuario en lugar de las que estn en el archivo passwd local, dependiendo del contenido del archivo /etc/nsswitch.conf . Para ver la lista de usuarios bajo NIS+ hay que utilizar el comando niscat y especificar el dominio de NIS+. Por ejemplo : % niscat -o passwd.dominio

En las computadoras que ejecutan NetInfo, el archivo local no se toma en cuenta y en su lugar se usa la versin de red. Por ejemplo, para ver las cuentas de usuario, si se usa NetInfo, hay que escribir: % nidump passwd / Las computadoras que usan DCE emplean una base de datos de red cifrada como alternativa a las contraseas cifradas y al archivo /etc/passwd. Muchos administradores no utilizan sistemas de administracin de bases de datos en red porque temen que la seguridad se vea comprometida. Estos temores provienen del hecho de que la configuracin de estos sistemas es, en ocasiones, muy complicada y los protocolos que utilizan pueden no ser particularmente resistentes a ataques. Es una practica habitual entre los administradores mantener simplemente un archivo central con la informacin de los usuarios y copiarlo de forma peridica en las computadoras remotas. El inconveniente que se presenta es que con frecuencia el administrador tiene que cambiar manualmente contraseas de usuarios. En general, es preferible aprender a dominar la configuracin de estos sistemas y luego colocar otras medidas defensivas como es el caso del cortafuegos (firewall). 3.2.3.- Identificador de usuario (UID) El UID es un nmero entero real de 16 bits (de 0 a 65535). Los primeros UID se usan principalmente para funciones del sistema. Para las personas, normalmente empiezan en el 20, el 100 o el 500. Es habitual asignar el UID dependiendo del grupo primario del usuario: los usuarios del grupo 500 tendrn los UID 501, 502, 503, y as sucesivamente. Algunas versiones de UNIX permiten ahora UID de 32 bits. En las versiones antiguas de UNIX los UID son enteros de 16 bits con signo (de -32768 a 32767). UNIX utiliza el archivo /etc/passwd para almacenar la correspondencia entre el nombre de cada usuario y su UID. El UID de cada usuario se guarda en el tercer campo, despus de la contrasea cifrada. Esta es una lnea del ejemplo anterior:
manurod:EH5/.mj7J5dFh:501:100:Manuel Rodrguez:/home/alumnos/manurod:/bin/bash

Aqu se puede ver que el UID de manurod es 501. El UID es la informacin real que utiliza el sistema operativo para identificar al usuario. Los nombre de usuario son solo una comodidad para nosotros. Si dos usuarios tienen el mismo UID, UNIX los trata como si fueran el mismo usuario, aunque tengan nombres y contraseas distintos. Dos usuarios con el mismo UID pueden leerse y

borrarse archivos libremente el uno al otro, as como suspenderse los programas que ejecuten. Asignar a dos usuarios el mismo UID es, por lo general, una mala idea, salvo algunas excepciones. 3.2.4.- Grupos Todos los usuarios de UNIX pertenecen a uno o ms grupos. El administrador del sistema puede utilizar los grupos para definir conjuntos de usuarios que tendrn permiso de leer, escribir y/o ejecutar ciertos archivos, directorios o dispositivos. Cada usuario pertenece a un grupo primario, que se anota en el archivo /etc/passwd. El GID del grupo primario de un usuario aparece despus del UID del usuario. Los grupos permiten manejar cmodamente a varios usuarios de alguna manera. Por ejemplo, tal vez se quiera abrir un grupo para un equipo de estudiantes que trabajan en un proyecto y permitirles a ellos y slo a ellos leer y modificar los archivos del equipo. Los grupos tambin se usan para restringir el acceso a la informacin confidencial o aplicaciones con licencias especificas. Por ejemplo, en muchas computadoras que usan UNIX, solamente se permite examinar el contenido de la memoria del kernel del sistema a ls usuarios que pertenecen al grupo kmem . El grupo ingres se usa normalmente para quienes estn registrados como usuarios del programa comercial del manejo de bases de datos Ingres. Algunas versiones especiales de UNIX permiten usar CAO o Controles de Acceso Obligatorio (MAC: Mandatory Access Controls), los cuales controlan el acceso mediante etiquetas en los datos, ademas o en lugar de los controles tradicionales CAV o Controles de Acceso Voluntario (DAC: Discretionary Access Controls) de UNIX . Los sistemas que se basan en CAO/CAV (MAC/DAC) no emplean los grupos tradicionales de UNIX. En su lugar, los valores de los GID y el archivo /etc/group se pueden usar para especificar etiquetas de seguridad para el control de acceso o bien para apuntar a listas de capacidades. 3.2.5.- El archivo /etc/group El archivo /etc/group contiene la base de datos con todos los grupos que hay en la computadora y sus GID correspondientes. Su formato es similar del del archivo /etc/passwd. He aqu una muestra de archivo /etc/group que pertenece a un sistema tpico:
root:*:0:root

bin:*:1:root,bin,daemon daemon:*:2:root,bin,daemon sys:*:3:root,bin,adm adm:*:4:root,adm,daemon lp:*:7:daemon,lp kmem:*:9: wheel:*:10:root,javitup mail:*:12:mail news:*:13:news uucp:*:14:uucp ftp:*:50: users:*:100: floppy:*:19: cdwriter:*:500:manurod pppusers:*:44:maripet

La primera lnea define el grupo root . Los campos se detallan en la siguiente tabla:

Campo root * 0 root

Contenido Nombre de grupo Contrasea de grupo (cifrada) Numero de identificacin del grupo (GID) Lista de usuarios miembros del grupo

Los usuario que aparecen en el archivo /etc/group pertenecen a los grupos que se indican, adems de pertenecer a sus grupos primario los

cuales se indican en el archivo /etc/passwd. Por ejemplo, manurod, maripet y javitup pertenecen al grupo users a pesar de no aparecer explcitamente en el archivo /etc/group porque su grupo primario es el 100. En algunas versiones de UNIX, se puede ejecutar el comando groups o id para ver la lista de grupos a los que se pertenece. 3.2.6.- Identificador de grupo (GID) Todos los usuarios de UNIX pertenecen a uno o ms grupos. Al igual que las cuentas de usuario, los grupos tienen un nombre de grupo y un nmero de identificacin de grupo (GID). Usualmente, los valores de los GID tambin son enteros de 16 bits. Anlogamente al UID, el GID representa al g rupo en el sistema, y no su nombre. Los grupos permiten agrupar a varios usuario que posean el mismo grupo primario (campo GID del archivo /etc/passwd) o que aparezcan en el archivo /etc/group. Las versiones de UNIX de AT&T anteriores a SVR4 slo permitan que un usuario estuviera en un grupo a la vez. Para cambiar de grupo haba que usar el comando newgrp. Cuando un usuario intentaba acceder a un archivo sobre el que tena permiso por pertenecer al mismo grupo, se le denegaba el acceso si, en ese instante, el usuario no estaba en ese mismo grupo. Por eso deba usar el comando newgrp. En la actualidad, los usuarios pertenecen a todos los grupos en los que aparecen en el archivo /etc/group a la vez. El sistema operativo chequea todos los grupos a los que pertenece el usuario para comprobar sus derechos de acceso. Aun as, el comando newgrp sigue teniendo cierta importancia. Si un usuario quiere que sus archivos tengan un grupo (GID) en especial de entre los que posee, debe utilizar el comando newgrp en cada archivo para cambiarlos de grupo. Esto puede ser un poco pesado, si est generando muchos archivos, as que puede cambiar de grupo con newgrp, de forma que todos los archivos que genere tengan el nuevo GID. 3.2.7.- Contraseas Para autentificar a un usuario, este debe demostrar su identidad. Existen tres maneras por la que un usuario puede autentificarse ante el sistema. Puede usarse una o varias de estas a la vez: Se puede indicar algo que se sabe (por ejemplo, una contrasea) Se puede mostrar algo que se tiene (por ejemplo, una tarjeta) La computadora puede considerar alguna caracterstica personal (por ejemplo, una huella dactilar).

Ninguno de estos sistemas es infalible. Alguien puede robar la contrasea 'husmeando' la linea de un terminal, puede robar la tarjeta en un atraco, y si tiene un cuchillo, quizs pueda obtener una huella dactilar. En general, cuanto ms confiable sea la forma de identificacin, ms complicada ser de usar, y ms agresivo deber ser el agresor para violarla. Las contraseas son el sistema de autentificacin ms simple: son un secreto que se comparte con la computadora. Al iniciar la sesin, se escribe la contrasea para demostrar a la computadora de quin se trata. La computadora se asegura de que la contrasea corresponde al nombre de usuario que se ha especificado. Si corresponde, se puede continuar. En el sistema UNIX no se despliega la contrasea, es decir, no se escribe en el terminal a medida que se teclea. Esto proporciona proteccin adicional si alguien est mirando por encima del hombro del que escribe. Esto puede parecer trivial, pero constituye la primera medida de seguridad. Las contraseas son la primera linea de defensa de UNIX contra los extraos que quieren penetrar en el sistema. Aunque se puede penetrar en el sistema o robar informacin a travs de la red sin abrir una sesin, muchas intrusiones se deben a contraseas mal elegidas y mal protegidas. En los sistemas personales de escritorio no se usan contraseas. La seguridad se basa en mtodos fsicos como paredes, puertas y cerraduras. En algunos ambientes de confianza tampoco se usan contraseas, la confianza y el respeto pueden ser suficientes como medida de seguridad. Pero cuando una computadora e st conectada a un modem y se puede acceder desde casi cualquier parte del mundo, o cuando est conectada a una red, sobre todo Internet, entonces las contraseas son absolutamente necesarias. Si una cuenta de una computadora que pertenece a una red se ve comprometida, puede poner en peligro a toda la red. Las contraseas convencionales han sido parte de UNIX desde sus primeros aos. La ventaja de las contraseas es que funcionan sin un equipo especial (como lectores de tarjeta y de huellas digitales). En la actualidad las contraseas convencionales en sistemas de red (la mayora) no son suficiente. Es necesario usar contraseas descartables o criptografa, o ambas. En algunas versiones de UNIX, si alguien intenta iniciar una sesin varias veces seguidas de forma invlida se bloquea la cuenta. Slo el administrados puede desbloquearla. El bloqueo protege al sistema de

quienes intentan adivinar una contrasea y avisa de que alguien ha intentado penetrar en la cuenta. Esta tctica puede ser utilizada en ataques de negacin de servicio, para bloquear a ciertos usuarios del sistema, o simplemente para fastidiar. En lugar del bloqueo, algunos sistemas (como Linux) introducen un retardo mayor cada vez que se falla una conexin desde un terminal, lo que limita los ataques de negacin del servicio, cumpliendo el mismo efecto que el bloqueo. El cambio de contrasea es otro momento crtico. El comando passwd, que sirve para cambiar la contrasea, solicita primero la contrasea anterior antes de la nueva. As se evita que alguien se siente en un terminal abierto y cambie la contrasea. Dejar un terminal abierto sin proteccin, es un fallo de seguridad bastante grave, pero, por lo general, bastante comn. El comando passwd, tambin requiere que se repita la contrasea. Esto evita que, por un error tipogrfico, se cambie la contrasea por una desconocida. Si se recibe un correo del administrador pidiendo que contrasea a una determinada, se debe ignorar administrador. Este tipo de mensajes se enva con usuarios novatos. Si se cumple la orden, puede tener devastadoras. se cambie la y avisar al frecuencia a consecuencias

Si se comete un error, o se olvida la contrasea y se pierde es acceso a la cuenta, hay que recurrir al administrador. Este no puede descifrar la contrasea de ningn usuario. Pero puede eliminar la contrasea o cambiarla, (esta parece la mejor opcin) sin dar la contrasea vigente. Uno de los fallos ms habituales es asignar como contrasea el nombre de usuario. Esta es en algunos sistemas una prctica habitual cuando se crea un usuario. Se debe obligar al usuario a cambiar la contrasea en la primera sesin. Si no lo hace, es probable que cualquiera que intente entrar en la computadora no tarde ms de diez minutos en conseguirlo. En general, se deben evitar las siguientes contraseas: El nombre propio, el de la esposa o del socio En nombre de la mascota o del hijo Los nombre de amigos o compaeros de trabajo Los nombres de los personajes favoritos El nombre del jefe

El nombre de cualquier persona El nombre del sistema operativo que se est utilizando El nombre de la computadora que se usa El nmero de telfono o el de la matricula del coche Cualquier parte del dni o nmero de la Seguridad Social Cualquier cumpleaos Cualquier otra informacin que sea fcil de averiguar (direccin, universidad, etc.) Cualquier forma del nombre maysculas o con letras dobles) de usuario (por ejemplo, en

Cualquier palabra que aparezca en un diccionario en cualquier idioma Nombre propios de lugares o personas Contraseas que sean una repeticin de la misma letra Patrones simples de letras del teclado: por ejemplo, qwerty Cualquiera de stos escrito al revs Cualquiera de stos con un dgito al principio o al final En general, cualquier combinacin de cualquiera de las anteriores. El motivo de estas recomendaciones, es que uno de los ataques ms habituales consiste en conseguir el archivo /etc/passwd de la computadora, y utilizar despus un generador de contraseas. Estos programas (como el programa Crack) utilizan un diccionario y un archivo de normas. En el archivo de normas se encuentran reglas para combinar las palabras del diccionario. As se genera una lista de posibles contraseas que se encriptan (el algoritmo es pblico) y se comparan con las contenidas en el archivo /etc/passwd. 3.2.8.- Usuarios especiales: el superusuario Adems de los usuarios normales, UNIX tiene varios usuarios especiales para propsitos administrativos y contables. Ya se han mencionado algunos. El ms importante es el root , el superusuario. Todos los sistemas UNIX tienen un usuario especial en el archivo /etc/passwd cuyo UID es 0. Este es realmente el nico usuario

realmente especial del sistema, los dems son especiales porque son propietarios de determinados archivos o pertenecen a determinados grupos (que a su vez tienen archivos importantes). La cuenta root es la identidad que usa el sistema operativo para llevar a cabo sus funciones bsicas, tales como el inicio y la terminacin de sesiones de usuario, el registro de la informacin contable y la administracin de dispositivos de entrada/salida. Por esta razn, el superusuario tiene el control de casi todo el sistema operativo: cualquier programa ejecutado por root puede eludir casi todas las restricciones de seguridad y se desactivan casi todas las verificaciones y advertencias. Como se indic en la seccin sobre el identificador de usuario (UID), dos cuentas que tengan el mismo UID son la misma para el sistema operativo. De esta manera, cualquier cuenta que tenga el UID 0 tiene los privilegios del superusuario. El nombre de usuario root es simplemente convencional. Hay que sospechar inmediatamente de cualquier cuenta que aparezca en el sistema con UID 0 que no haya sido creada por el administrador. Estas cuentas se aaden con frecuencia por personas que penetran en las computadoras como una manera sencilla de obtener privilegios de superusuario en el futuro. La cuenta root no se ha diseado para que el administrador la use como cuenta personal. Debido a que se inhabilitan todas las pruebas de seguridad para el superusuario, un error tipogrfico fcilmente puede destruir todo el sistema. Con frecuencia el administrador de un sistema UNIX tendr que convertirse en superusuario para llevar a cabo funciones administrativas. Este cambio de estado se puede lograr mediante el comando su para crear un intrprete de comandos privilegiado. Cuando de tiene la capacidad del superusuario se deben tomar precauciones extremas. Cuando cese la necesidad de tener este tipo de acceso, el administrador debe cerrar el intrprete de comandos privilegiado. Cualquier proceso que tiene UID efectivo 0 se ejecuta como si fuera el superusuario, es decir, cualquier proceso con UID 0 se ejecuta sin verificaciones de seguridad y puede hacer prcticamente lo que sea. Las verificaciones y controles de seguridad se ignoran en el caso del superusuario aunque la mayor parte de los sistemas s registran en las bitcoras y auditan algunas de las acciones del superusuario. El usuario es la principal debilidad de seguridad del sistema operativo UNIX. Dado el privilegio del superusuario, las personas que penetran en un sistema UNIX tratan de convertirse en el superusuario.

Para evitar este problema con el superusuario, se ha intentado varias veces disear un sistema UNIX seguro (que cumpla todos los requisitos para un sistema altamente confiable) adoptando la estrategia de dividir los privilegios del superusuario en muchas categoras. Lamentablemente estos intentos a menudo fallan. Casi siempre, muchos de los privilegios en los que se divide el superusuario pueden usarse para obtener los dems. Se cambia un gran fallo de seguridad por otros ms pequeos que llevan al mismo final. 3.2.9.- El comando su A veces un usuario debe tomar la identidad de otro. Pos ejemplo si se desea acceder a archivos propios estando sentado delante el terminal de un amigo. En lugar de cerrar la sesin del amigo e iniciar una propia, UNIX permite cambiar temporalmente el nmero de identificacin de usuario. El comando que lo permite se llama su,que son las iniciales de substitute user (sustituir usuario). su requiere que se use la contrasea del usuario al que se est cambiando. Los procesos en sistemas UNIX tienen al m enos dos identidades en cada momento. Normalmente estas dos identidades son la misma. La primera identidad es el UID real. El UID real es la identidad verdadera y coincide, normalmente con el nombre de usuario con el que se inici la sesin. A veces se quiere asumir la identidad de otro usuario para acceder a algunos archivos o ejecutar algunos comandos. Esto se puede lograr iniciando una sesin con el otro nombre y obteniendo de esa forma un intrprete de comandos cuyo proceso subyacente tenga un UID igual al del usuario. Como alternativa, si slo se desea ejecutar algunos comandos con la identidad de otro usuario, se puede emplear el comando su para crear nuevos procesos. Esto ejecutar otra copia del intrprete de comandos que tendr la identidad (UID real) del otro usuario. Para emplear el comando su es necesario conocer la contrasea del otro usuario o ser en ese momento el superusuario. Si se escribe su sin un nombre de usuario, se indica a UNIX que se quiere convertir en superusuario. Entonces se solicita la contrasea del superusuario. Si la contrasea de root se escribe correctamente, se ejecuta un intrprete de comandos con UID 0. Al convertirse en superusuario, el prompt cambiar por defecto al carcter '#', lo que recordar los nuevos poderes que se han adquirido. Cuando se usa en comando su para convertirse en superusuario, siempre debe usarse la trayectoria completa del comando /bin/su. Al hacerlo as, se asegura la ejecucin del comando su autntico y de que no se ha ejecutado algn otro comando su que se encuentre en la trayectoria de bsqueda. Esto es una manera importante de protegerse y proteger la contrasea del superusuario contra algn caballo de Troya.

Es recomendable invocar al comando su con un argumento simple en forma de guin cuando se quiere convertir en superusuario: $ /bin/su De esta forma, su invoca al intrprete de comandos de forma que este lea todos loa archivos de configuracin necesarios y simule un inicio de sesin. Esto es importante porque as se evita que la trayectoria de bsqueda (PATH) sea la del usuario que invoco su y no la del superusuario. Algunas versiones del UNIX de tipo Berkeley no permiten usar su a ninguna cuenta que no sea miembro del grupo wheel. Sin embargo la versin de su de GNU no utiliza esta caracterstica. Esta es la explicacin de Richard Stallman sacada de la propia pgina de manual de su.
A veces, algunos listillos intentan hacerse con el poder total sobre el resto de usuarios. Por ejemplo, en 1984, un grupo de usuarios del laboratorio de Inteligencia Artificial del MIT decidieron tomar el poder cambiando el password de operador del sistema Twenex y mantenindolo secreto para el resto de usuarios. (De todas maneras, hubiera sido posible desbaratar la situacin y devolver el control a los usuarios legtimos parcheando el kernel, pero no sabra como realizar esta operacin en un sistema UNIX.)

Sin embargo, casualmente alguien cont el secreto. Mediante el uso habitual de su una vez que alguien conoce el password de root puede contrselo al resto de u suarios. El grupo "wheel" har que esto sea imposible, protegiendo as el poder de los superusuarios.

Yo estoy del lado de las masas, no de los superusuarios. Si eres de los que estn de acuerdo con los jefes y los administradores de sistemas en cualquier cosa que hagan, al principio encontrars esta idea algo extraa.

Muchas versiones registran los intentos fallidos del comando su. Las versiones ms viejas de UNIX enviaban explcitamente a la consola los avisos de los intentos fallidos de su y tambin l os colocaban en el archivo /var/adm/messages. Las versiones ms modernas registran los intentos fallidos de usar su a travs del programa syslog, el cual permite enviar los mensajes que se quieran a un archivo especfico o anotarlos en bitcoras que estn en computadoras remotas a travs de la red.

3.3.- El sistemas de ficheros de UNIX

3.3.1.- Introduccin El sistema de ficheros de UNIX controla el modo en el que la informacin se almacena en el disco y otras formas de almacenamiento secundarias. Dentro del sistema UNIX todo son archivos: desde la memoria fsica del equipo hasta el ratn, pasando por modems, teclado, impresoras o terminales. Por esto, una correcta utilizacin de los permisos, atributos y otros controles sobre ficheros es vital para la seguridad de un sistema. El sistema de ficheros proporciona las herramientas bsicas para el administrador, pero tambin para el atacante, sea este voluntario, un fallo de un usuario o de un programa. Ya que en UNIX todos los objetos son elementos del sistema de ficheros (a partir de aqu archivos o ficheros, indistintamente), un error en un permiso puede facilitar la escritura de cualquier usuario en un disco o en un directorio importante, la consecucin de un shell privilegiado, o la posibilidad de que un usuario 'vea' la memoria de todos los dems usuarios(y la del sistema). 3.3.2.-Tipos bsicos de archivos. En un sistema UNIX existen tres tipos bsicos de archivos: ficheros planos, directorios y ficheros especiales (dispositivos). Tambin existen otros tipos de archivos como los enlaces simblicos, los sockets o las tuberas, pero no se tratarn aqu. Ficheros planos: Son secuencias de bytes, que a priori no poseen ni estructura interna ni contenido significante para el sistema, su significado depende de las aplicaciones que interpretan su contenido. Directorios: Son archivos cuyo contenido son otros ficheros de cualquier tipo (planos, otros directorios y otros ficheros especiales). Ficheros especiales: Son archivos que representan dispositivos del sistema. Se dividen en dos grupos: los dispositivos orientados a carcter y los orientados a bloque. La principal diferencia entre ambos es la forma de realizar operaciones de entrada/salida:mientras que los dispositivos orientados a carcter la realizan byte a byte (esto es, carcter a carcter ), los orientados a bloque la realizan en bloques de caracteres . 3.3.3.- Inodos o nodos indice Para cada objeto en el sistema de ficheros, UNIX guarda informacin administrativa en una estructura llamada inodo. Los inodos residen en

el disco y no tienen nombre, en vez de ello, tienen indices (nmeros) que indican su posicin en un arreglo de inodos. Un inodo es una estructura de datos que relaciona un grupo de bloques de un dispositivo con un determinado nombre del sistema de ficheros. Cada inodo generalmente contiene lo siguiente: La ubicacin del contenido del tem en el disco, si existe . El tipo del tem (es decir, archivo, directorio, enlace simblico, etc.) El tamao total del tem, en bytes, si esto se aplica. La fecha de la ltima modificacin del archivo del inodo (el ctime). La fecha de la ultima modificacin del contenido del archivo del inodo (el mtime). La fecha del ultimo acceso al archivo (el atime) para read(), exec(),etc. El numero de enlaces fsicos que tiene ese archivo. Tamao de bloque para el sistema de ficheros de E/S Numero de bloques asignados. Tipo de dispositivo El dueo del archivo (UID). El grupo del archivo (GID). Los bits de proteccin. Estos tres ltimos, que se guardan para cada archivo, junto con la informacin UID/GID del proceso que se ejecuta, son los datos fundamentales que se emplean en UNIX para controlar el acceso de los usuarios a los archivos, y por lo tanto, prcticamente para toda la seguridad del sistema operativo. 3.3.4.- Fechas de los archivos. Las fechas que aparecen al ejecutarse la instruccin ls -l son las fechas de modificacin de los archivos (mtime). Se puede obtener la fecha del ultimo acceso (atime) usando la opcin -u (escribiendo, por ejemplo, ls -lu). Ambas fechas se pueden cambiar usando una llamada a una rutina de la biblioteca del sistema. Por lo tanto, los administradores deben adquirir el habito de verificar la fecha de cambio del inodo (ctime) usando la opcin -c. Por ejemplo, ls -lc. Bajo circunstancias

normales, no se puede cambiar el ctime de un archivo. El sistema operativo lo actualiza cada vez que hay un cambio en el inodo del archivo. Puesto que el inodo cambia cuando se modifica un archivo, ctime indica la fecha de la ultima escritura, cambio de proteccin o cambio de dueo. Un agresor puede cambiar el mtime o el atime de un archivo, pero normalmente el ctime ser correcto. Un agresor listo, que adquiere privilegios de superusuario, puede cambiar el reloj del sistema y luego aplicar touch al inodo, forzando as que aparezca un ctime engaoso en el archivo. Ademas el agresor puede cambiar el ctime escribiendo directamente al disco, evitando el uso de las verificaciones del sistema operativo completamente. Si usa Linux, con el sistema de archivos ext2, un agresor puede modificar el contenido del inodo directamente usando la instruccin debugfs. Si la cuenta del superusuario del sistema ha sido comprometida no se puede asumir que ninguna de las tres fechas que se almacenan para cada archivo o directorio sean correctas. Por esta razn, no se puede basar el control de archivos en las fechas. 3.3.5.- Permisos de un archivo Los permisos de un archivo pueden verse en cada lnea (los diez primeros caracteres) del listado al ejecutar la orden ls -l. Indican qu es el archivo y qu tipo de acceso otorga (es decir, la posibilidad de leer, escribir o ejecutar ) a los diversos usuarios del sistema. He aqu dos ejemplos de permisos de archivo: drwxr-xr-x -rwsr-sr-x

El primer smbolo del campo de modo del archivo indica el tipo del archivo, como se explica en la siguiente tabla: Contenido d c b Archivo plano Directorio Dispositivo de tipo carcter (tty,impresora, ...) Dispositivo de bloque (disco, CD-Rom, etc.) Significado

l s =op

Enlace simblico Socket FIFO

Los siguientes nueve smbolos tomados en grupos de tres indican quin y qu tipo de operaciones se pueden hacer con los archivos en la computadora. Hay tres tipos de permisos: r w x permiso de lectura permiso de escritura permiso de ejecucin

De manera anloga, existen tres clases de permisos: owner group other propietario del archivo usuarios que estn en el grupo del propietario todo el mundo (excepto el superusuario)

En el siguiente grfico se muestra como interpretar los distintos privilegios:

Los permisos de lectura,escritura y ejecucin tienen los siguientes significados especficos: r (READ): El permiso de lectura quiere decir exactamente eso: el archivo se puede abrir con la llamada de sistema open() y su contenido puede leerse con read().

w (WRITE): El permiso de escritura permite sobreescribir con uno nuevo o modificar su contenido. Tambin se puede usar write() para hacerlo mas grande y truncate() o ftruncate() para hacerlo ms corto. x (EXECUTE):Este permiso slo tiene sentido en el caso de programas. Si un archivo tiene los bits de ejecucin habilitados, se puede ejecutar escribiendo su trayectoria (o ejecutndolo con algn miembro de la familia de llamadas del sistema exec()). La manera en que se ejecuta el programa depende de los dos primeros bytes del archivo. Se supone que los dos primeros bytes de un archivo ejecutable son un nmeros mgico que indica la naturaleza del archivo. Algunos nmeros significan que el archivo es algn tipo de archivo binario en lenguaje maquina. La secuencia especial de dos bytes #! significa que es un guin ejecutable de algn modo. Si los valores son desconocidos se supone que es un guin de interprete de instruccin y se ejecuta de esa manera. Los permisos de un archivo se aplican a los dispositivos y a los sockets con nombre del mismo modo que a los archivos normales. Si se tiene permiso de escritura se puede escribir informacin al archivo o al objeto. Si se tiene permiso de lectura se puede leer el contenido. Y si no se tienen ninguno de estos permisos, mala suerte. Los permisos de archivo no se aplican a los enlaces simblicos. El que se pueda o no leer de un archivo al que apunta un enlace simblico depende de los permisos propios del archivo, y no de los permisos del enlace. De hecho, los enlaces simblicos casi siempre se crean con los permisos rwxrwxrwx (en modo 0777, en octal) y el sistema operativo no los usa para nada. Las siguientes consideraciones sobre los permisos de un archivo son importantes: Se puede tener permiso de ejecucin sin tener permiso de lectura. En ese caso se puede ejecutar un programa pero no leerlo. Esto es til si se desea ocultar el contenido de un programa. Otra forma de usar esto es permitir a los usuarios emplear el programa pero no copiarlo (salvo en servidores de ficheros NFS, que no distinguen este caso, pues para ejecutar un archivo este debe ser enviado al cliente). Si se tiene permiso de lectura pero no de ejecucin, se puede hacer una copia del archivo y ejecutarla. No obstante, la copia ser distinta principalmente en dos maneras. Tendr una trayectoria absoluta diferente y ser propiedad de quien la haya copiado y no del dueo original del programa (esto se importante en los archivos con el bit SUID o SGID activado). En algunas versiones de UNIX (incluyendo Linux) un guin de instrucciones ejecutable debe tener los bits de lectura y ejecucin habilitados para que sea posible ejecutarlo.

Los permisos de un archivo se pueden cambiar con la instruccin chmod o con las llamadas al sistema chmod() y fchmod(). Slo el dueo de un archivo puede cambiar los permisos. La nica excepcin a esta regla es el superusuario: si alguien est en una sesin de superusuario puede cambiar los permisos de cualquier archivo. Los administradores expertos, prefieren usar chmod especificando los permisos en octal. Al usuario inexperto puede parecerle incmodo, pero una vez que se aprende, es mucho ms rpido. Los permisos de un archivo estn representados por doce bits, un bit por cada permiso, estos permisos son la interpretacin en octal del nmero binario resultante de poner a uno el permiso deseado y a cero los dems. La siguiente tabla, resume los diferentes permisos en octal: Octal 4000 2000 1000 0400 0200 0100 0040 0020 0010 0004 0002 0001 SUID SGID Bit adhesivo(sticky) Lectura por el dueo Escritura por el dueo Ejecucin por el dueo Lectura por el grupo Escritura por el grupo Ejecucin por el grupo Lectura por otros Escritura por otros Ejecucin por otros Permiso
--S----------S----------T r--------w--------x--------r--------w--------x--------r--------w--------x 100000000000 010000000000 001000000000 000100000000 000010000000 000001000000 000000100000 000000010000 000000001000 000000000100 000000000010 000000000001

El clculo del valor octal que representa los permisos que se desean, se realiza efectuando un OR o suma (en este caso es lo mismo) de los valores de los permisos, o convirtiendo a octal el binario correspondiente a esos permisos, si se est acostumbrado. Dada la importancia de los permisos, UNIX provee una utilidad, llamada umask , que permite especificar los permisos de creacin por defecto. Realmente, el argumento que acepta umask es una mscara en octal con los permisos que no se quieren asignar a los archivos nuevos. El valor ms usual es 022, que elimina el permiso de escritura para el grupo y otros.

Cuando los permisos de archivo se aplican sobre un directorio, estos tienen significados especiales: r: Se permite usar las funciones opendir() y readdir() (o el comando ls) para buscar qu archivos estn en el directorio. w:Se puede aadir, renombrar o quitar entradas en ese directorio. x: Se puede emplear stat al contenido del directorio (es decir, se puede determinar quines son los dueos y cules son los tamaos de los archivos que estn en el directorio). Tambin se requiere permiso de ejecucin a un directorio para convertirlo en directorio actual o para abrir archivos que estn dentro de ese directorio (o en cualquiera de sus subdirectorios). 3.3.6.- SUID, SGID y los bits adhesivos Muchos programas, como su, basan su funcionamiento en el uso de los bits SUID y SGID. Para entender completamente como maneja UNIX esta tcnica es imprescindible conocer los conceptos de UID real, UID efectivo y UID guardado. UNIX almacena para todos los procesos que ejecuta dos identificadores bsicos de usuario: UID real y UID efectivo. Para un proceso normal, resultante de la ejecucin de un programa que no es SUID, los dos identificadores son el mismo e iguales al UID del proceso que lo gener. Esto resulta ms sencillo con un ejemplo: cuando un usuario inicia una sesin, el proceso login verifica la identidad del usuario en el fichero /etc/passwd y genera un shell con UIDs real y efectivo iguales al del usuario. Cuando el usuario ejecuta cualquier programa que no sea SUID, sea suyo o no, sobre el que por supuesto debe tener permiso de ejecucin, el proceso creado hereda los UIDs del shell. Este comportamiento se mantiene si este proceso crea otros procesos, que a su vez pueden crear otros procesos, y as sucesivamente. Pensemos, por ejemplo, en un usuario que teclea bash continuamente, todos los shell creados tendrn los mismos UIDs. De esta manera, si no tenemos en cuenta la existencia del bit SUID, bastara con un UID que identificara al usuario durante toda la sesin, puesto que no hay forma de que el usuario cambie el UID de un proceso. El problema es que UNIX utiliza el UID efectivo del proceso (Linux utiliza un cuarto identificador, el FSUID) para analizar los privilegios que este tiene sobre el sistema de ficheros. Pero un usuario necesita escribir en archivos que no le pertenecen: para cambiar su contrasea necesita escribir en /etc/passwd, para imprimir debe dejar sus archivos en un directorio de spool, y multitud de tareas ms.

Si no se hubiera implementado ninguna manera de alterar esto, slo habra una forma de que el usuario escribiera en directorios y archivos que no le pertenecen: darle permiso sobre estos y, por extensin, a todos los usuarios del sistema. Pero esto es imposible, acabara con el sentido de la proteccin en el sistema de ficheros y con la seguridad de UNIX. Para evitar estos problemas, UNIX permite que los programas tengan privilegios. Los procesos que ejecutan estos programas pueden adquirir un UID o GID distinto al propio cuando se estn ejecutando. Un programa que cambia su UID se llama programa SUID, y un programa que cambia su GID se llama programa SGID. Un programa puede ser SUID y SGID al mismo tiempo. Cuando se ejecuta un programa SUID, su UID efectivo se convierte en el del dueo del archivo, en lugar del UID del usuario que lo est ejecutando. Este concepto es tan ingenioso que AT&T (Dennis Ritchie) lo patent, aunque despus la patente ha sido transferida al dominio pblico. En el siguiente grfico se muestra como interpretar los distintos privilegios:

SUID: Un proceso que ejecuta un programa SUID obtiene un UID efectivo que es el del dueo del programa. SGID: Un proceso que ejecuta un programa SGID tiene su GID efectivo cambiado al GID del programa. Los archivos creados por el proceso tambin pueden tener su grupo primario establecido a este GID, dependiendo de los permisos del directorio donde se crean los archivos. En las versiones de UNIX derivadas de Berkeley (tambin en Linux), un proceso que ejecuta un programa SGID adquiere tambin el GID del programa temporalmente, el cual se coloca en la lista de GID del proceso. Solaris y otros UNIX derivados de System V usan el bit de GID de los archivos de datos para habilitar el bloqueo obligatorio de archivos.

Adhesivo: Est obsoleto en lo que se refiere a archivos, pero se usa para directorios. Cuando un archivo ejecutable tena el bit adhesivo activado, significaba que deba permanecer en memoria principal el mayor tiempo posible. Esto mejoraba el rendimiento en computadores con una cantidad muy limitada de memoria RAM (sobre 64K, incluso). Pero esto ya no tiene mucho sentido. Sin embargo, si un directorio tiene activado el sticky bit (bit adhesivo o de permanencia), significa que aunque varios usuarios tengan permiso de escritura en l, slo el propietario del archivo y el superusuario pueden borrar un archivo. Esto es til en directorios donde pueden escribir muchos usuarios, pero no se desea que los usuarios se borren archivos unos a otros,como en /tmp o en un directorio de spool. El bit SGID en directorios tambin tiene un comportamiento particular. Si est activado, los archivos de usuario que se crean en ese directorio, tendrn el mismo GID que el directorio, si el usuario tambin est en ese grupo. Si el usuario no est en el grupo del directorio, los archivos se crean con el GID del usuario (por lo general el primario), como es normal. Es importante sealar que para activar estos permisos, tambin debe darse el permiso de ejecucin correspondiente, es decir, ejecucin para el propietario para el bit SUID, ejecucin para el grupo para el bit SGID y ejecucin para otros para el bit adhesivo. Si no se hace as, el bit correspondiente aparecer en maysculas (S o T) y no en minsculas (s o t), lo que indica que el bit est establecido pero no tendr efecto. Esta caracterstica que hace que UNIX sea tan verstil, es tambin uno de los mayores problemas de seguridad. Cualquier usuario puede convertirse en superusuario simplemente ejecutando una copia SUID de bash que sea propiedad del root . Afortunadamente, slo el superusuario puede realizar esta copia. Por lo tanto, uno de los objetivos del administrador ser evitar que existan este tipo de archivos en la computadora. Si se deja un terminal sin vigilancia, cualquiera puede apoderarse de la cuenta simplemente introduciendo las siguientes instrucciones: % cp /bin/bash /tmp/trampa % chmod 4755 /tmp/trampa % Estas instrucciones crean una copia SUID del programa bash. Cada vez que el agresor ejecute este programa se convierte en el usuario, con pleno acceso a los archivos y privilegios. Se supone que el usuario tiene algn archivo interesante para el agresor, privilegios que le

permitan acceder al superusuario, o quiere suplantarle para alguna actividad delictiva, en el peor caso el usuario ser el propio root . El agresor podra copiar ese programa en un directorio oculto que slo el superusuario, buscando archivos de este tipo, podra encontrar. Pero no todos los administradores realizan esta tarea con regularidad. Es importante notar que el programa no tiene porque ser un interprete de comandos, un simple editor de textos SUID puede permitir al agresor modificar archivos o incluso crear un interprete de comandos que se ejecute con el UID del usuario ( vi lo permite con el comando shell). La mayor parte de los programas SUID de un sistema son SUID de root , es decir, se convierten en el superusuario cuando se ejecutan. Tericamente, esto no es un fallo de seguridad, porque un programa compilado nicamente puede llevar a cabo las funciones para las que fue compilado (se puede cambiar la contrasea propia usando passwd, pero no se puede cambiar la contrasea de otro usuario). Pero se han encontrado muchos fallos de seguridad creados por gente que se las ha ingeniado para lograr que un programa SUID haga algo para lo que n o fue diseado. En muchos casos programas que son UID de root podran haberse diseado para ser SUID de otra cuenta (como daemon). Con demasiada frecuencia se usa SUID de root cuando sera suficiente con privilegios menores. Un ejemplo de programa SGID con un fallo de seguridad es el programa write. Como write permite escribir en el terminal de otro usuario, este programa es SGID de tty. Esto permite que write escriba nuestro texto en el otro terminal. El fallo es que write permita que el usuario ejecute cualquier instruccin escribiendo el carcter '!' al principio de una lnea. El programa ejecutado heredara el GID efectivo de tty, lo que permitira al usuario, por ejemplo, 'escuchar' los terminales de otros usuarios. En la actualidad, el programa write sigue siendo SGID de tty, pero cambia el GID de tty al del usuario antes de ejecutar el shell (ms adelante se ver como se consigue esto) y luego lo restablece al de tty. En algunas versiones, esta caracterstica est deshabilitada. Otro ejemplo, esta vez de SUID, era el programa /usr/lib/preserve, que realizaba las copias de seguridad para los editores vi y ex . Para poder hacer copias de seguridad en el directorio, el programa era SUID de root , de forma que el directorio estaba protegido contra la lectura por parte de los usuario (quizs alguien estuviera editando algo importante y no se poda permitir que lo leyera cualquiera). Haba tres detalles que hicieron que el programa fuera un fallo de seguridad: Era SUID de root

Ejecutaba /bin/mail como root para avisar a los usuarios de que su archivo estaba copiado Ejecutaba el programa mail con la llamada al sistema system() El problema era que system() usa sh para leer la cadena que ejecuta. Hay una variable del intrprete de comandos, llamada IFS (separador interno de campos), que sh utiliza para ubicar las separaciones entre las palabras de cada lnea que lee. Normalmente IFS es el espacio en blanco, pero si se estableca IFS como '/' entonces, al llamar a /bin/mail se estaba llamando en realidad a un programa llamado bin del directorio actual, pero con privilegio de root . El resto es fcil, haciendo una copia de un shell en el directorio actual y llamndola bin, bastaba con ejecutar vi para convertirse en root . El problema era que el programa preserve tena ms privilegios de los necesarios. La norma del privilegio mnimo establece que los programas (y usuarios) tengan los privilegios imprescindibles para realizar su labor, y no ms. En este c aso, habra bastado con hacer a preserve SGID del grupo preserve, creado expresamente. Esto no hubiera eliminado el fallo, pero lo habra minimizado. El agresor slo podra leer las copias de los trabajos de otros usuarios. Las versiones actuales de sh no toman en cuenta IFS si se ejecuta en modo root o si el UID efectivo es diferente del real. El problema de los bits SUID y SGID est muy unido al ataque basado en la tcnica del desbordamiento de pila (buffer overflow), que se tratar ms adelante. 3.3.6.1.- Cambio de UID: setuid() Con el objeto de facilitar la programacin de utilidades seguras, UNIX proporciona una serie de funciones que permiten cambiar entre los UID real, efectivo y guardado. Como se ha visto en el ejemplo de write, para que la aplicacin pueda ejecutar una orden del usuario sin peligro para la seguridad, esta debe cambiar al GID del usuario antes de ejecutarla y luego restablecer el GID anterior. Una solucin para esto podra ser permitir el cambio entre los UID efectivo y real (o entre los GID efectivo y real, el funcionamiento es el mismo) de forma que durante la ejecucin de esa parte del proceso (o la de sus hijos, si es el caso) se perdieran los privilegios que se tenan. Veamos un ejemplo: Si el usuario 501 ejecuta el programa write, ste tiene GID real 501(usuario) y GID efectivo 5(tty). Al introducir una lnea que

comienza por '!', el programa write detecta que tiene que ejecutar un comando: para ello primero intercambia los GID, quedando GID real 5(tty) y GID efectivo 501(usuario) y despus ejecuta el comando. Ahora, el comando ha heredado los GID (y los UID) de write, pero ya no tiene el GID efectivo de tty sino 501, el del usuario. Despus, write puede volver a intercambiar los GID y continuar su ejecucin normalmente. Esto tiene un fallo: nada impide al proceso del usuario volver a intercambiar los GID, y recuperar los privilegios anteriores. Para solucionar definitivamente este problema, UNIX utiliza la familia de funciones setuid() y setgid(). Estas funciones utilizan un tercer UID llamado UID guardado o salvado. El cambio a un UID/GID real o efectivo slo est permitido si el proceso posee ese UID/GID como UID/GID efectivo, real o guardado. Slo un proceso con UID 0(root) puede cambiar a cualquier otro UID/GID. En el ejemplo anterior (nuevamente, el funcionamiento es igual con el UID), write puede establecer el GID efectivo a 501(usuario) dejando el GID real como estaba (501(usuario)), quedando como GID guardado el 5(tty). De esta forma, el proceso generado hereda estos dos GID, pero no el guardado, y no puede cambiar otra vez al GID 5(tty) puesto que no lo tiene. Pero write s puede restablecer el GID efectivo a 5(tty), puesto que se es el GID guardado. Esta vez todo se ha hecho de forma segura, y el agujero de seguridad de write ha desaparecido. Este es el funcionamiento de las diferentes funciones que permiten realizar estos cambios (por lo menos, en su versin Linux): getuid(void): Devuelve el UID real del proceso actual. geteuid(void): Devuelve el UID efectivo del proceso actual. setuid(uid_t uid): (POSIX) Establece el UID efectivo del proceso en curso. Si el UID efectivo del proceso que las llama es 0(root ) o si el proceso es SUID de root , se establecen tambin los UID real y guardado. Esto impide a un proceso del root que deja sus privilegios que los recupere ms tarde. setreuid(uid_t ruid,uid_t euid) (BSD): Establece el UID real y el efectivo del proceso en curso. Un valor de -1 para el UID real o efectivo fuerza al sistema a dejar dicho ID sin cambios. Si el UID real es cambiado, o el UID efectivo se pone a un valor

distinto del UID real previo, el UID guardado tomar en valor del nuevo UID efectivo. seteuid(uid_t euid) (BSD): Es funcionlmente equivalente a setreuid(-1, euid). getgid(void): Devuelve el GID real del proceso actual. getegid(void): Devuelve el GID efectivo del proceso actual. setgid(gid_t gid) (POSIX): Establece el GID efectivo del proceso en curso. Si el GID efectivo del proceso que las llama es 0(root ) o si el proceso es SGID de root , se establecen tambin los GID real y guardado. Esto impide a un proceso del root que deja sus privilegios que los recupere ms tarde. setregid(gid_t rgid, gid_t egid) (BSD):Establece el GID real y el GID efectivo del proceso en curso. Un valor de -1 para el GID real o efectivo f uerza al sistema a dejar dicho ID sin cambios. Si el GID real es cambiado, o el GID efectivo se pone a un valor distinto del GID real previo, el GID guardado tomar el valor del nuevo GID efectivo. setegid(gid_t egid) (BSD): Es funcionlmente equivalente a setregid(-1, egid). 3.3.7.- Listas de control de acceso (ACLs) Algunas versiones de UNIX permiten usar listas de control de acceso (ACL, Access Control Lists). stas se ofrecen normalmente como extensiones a los modos de permisos de archivo estndar de UNIX. Usando ACLs se pueden especificar derechos adicionales de acceso para cada archivo y directorio a muchos usuarios en individual, en lugar de tener que hacerlo colocando a todos en un grupo nuevo o en la categora 'otros'. Tambin se pueden asignar permisos distintos a grupos diferentes. Se trata de una caracterstica que se popularizar en los prximos aos. Lamentablemente cada proveedor las ha implementado de forma diferente. Las ACLs permiten refinar la capacidad de otorgar permisos de archivo que tiene el UNIX estndar. Permiten la especificacin completa del acceso a subconjuntos completamente arbitrarios de usuarios y/o grupos de usuarios. Tanto AIX como HP-UX ofrecen listas de control de acceso. Solaris y Linux supuestamente las ofrecern en versiones futuras. Para muchos propsitos las ACLs son mejores que el mecanismo de grupos que ofrece UNIX a proyectos de colaboracin pequeos. Si Ana quiere darle a Miriam, y slo a Miriam, acceso a un archivo en particular, puede modificar la ACL del archivo para otorgrselo. Sin

ACLs Ana tendra que acudir al administrador del sistema, pedirle que cree un grupo nuevo que tuviera como miembros tanto a Ana como a Miriam (y slo a ellas) y luego cambiar el grupo del archivo para otorgar privilegios al nuevo grupo. 3.3.8.- Archivos de dispositivo Como ya se ha comentado antes, todos los dispositivos en UNIX se representan como archivos normales. En el inodo se especifica que se trata de un dispositivo, el tipo de dispositivo, y su nmeros de dispositivo principal y secundario que permiten al sistema identificar al dispositivo. El hecho de que los dispositivos sean archivos, da a UNIX una gran flexibilidad y unifica el acceso a los dispositivos, de forma que los programadores pueden desarrollar sus programas sin saber el tipo de dispositivo que se va a utilizar. Pero esto tambin representa un problema de seguridad. Si un usuario consigue acceso sin restricciones a un archivo de dispositivo, podr hacer lo que quiera con l. Si es un terminal, podr leer lo que otro usuario escribe, si es un disco, podr escribir y leer en cualquier sitio, si es el dispositivo kmem, podr cambiar su UID o bloquear el sistema escribiendo basura en el rea de memoria reservada para ste. UNIX agrupa todos los archivos de dispositivo en el directorio /dev . Por esta razn es muy importante que el administrador revise peridicamente los permisos de estos archivos. Unos pocos dispositivos deben permitir el acceso a todos los usuarios, como /dev/null o /dev/tty. Pero casi todos los dems no deben permitir lectura ni escritura por los usuarios normales. Tambin se debe revisar el sistema en busca de archivos de dispositivo creados por un intruso en cualquier parte del sistema de ficheros, y que podra darle acceso a este dispositivo. 3.3.9.- Sistemas de ficheros montados Para poder acceder de forma uniforme a distintos tipos de sistemas de ficheros, UNIX incorpora una capa superior de abstraccin denominada VFS, Virtual File System o Sistema de Ficheros Virtual, que se ocupa de proporcionar este acceso uniforme a diferentes tipos de sistemas de ficheros. Montar un sistema de ficheros consiste en asociar un determinado nombre de directorio (punto de montaje) con el sistema de ficheros en cuestin. A partir de ese momento el sistema de ficheros montado podr ser utilizado de forma normal por los usuarios. Es habitual en grandes sistemas UNIX montar diferentes partes de la estructura de directorios estndar (por ejemplo /home o /usr) en distintos dispositivos. Esto no presenta ningn problema de seguridad, puesto

que estos sistemas se montan cada vez que se inicia el sistema, normalmente son necesarios para el funcionamiento normal del sistema. Pero para utilizar discos removibles, CD-ROMs o sistemas de ficheros en red (NFS) no queda ms remedio que m ontarlos como parte del sistema de ficheros. Esto si que representa un problema de seguridad. Estos sistemas de ficheros pueden contener archivos ejecutables (por ejemplo un shell con SUID de root ) que pueden comprometer la seguridad del sistema. Para evitar estos problemas, el archivo de configuracin fstab, que almacena la forma en que se montan los distintos dispositivos, y el comando mount , que se encarga de montarlo, aceptan una serie de opciones que protegern nuestro sistema. Estas opciones son: auto/noauto: Puede o no montarse con la opcin -a (se montan todos automticamente) dev/nodev : Interpreta o no dispositivos especiales exec/noexec: Permite o no la ejecucin de binarios rw/ro: El sistema de ficheros de monta como de lectura/escritura o como slo lectura. suid/nosuid: Permite o no el efecto de los bits SETUID y SGID user/nouser: Permite o no que los usuarios ordinarios monten el sistema de ficheros. La opcin user implica noexec, nosuid y nodev a menos que se indique lo contrario explcitamente. sync: Toda E/S ha de realizarse de forma sncrona. Esta opciones bien utilizadas impiden que un usuario monte un sistema de ficheros que pueda contener peligros como un dispositivo que apunte a nuestro disco (y sobre el que tenga permisos), un shell SUID de root y peligros similares. En muchos sistemas es habitual que slo el superusuario pueda montar sistemas de ficheros, incluso que slo l tenga acceso fsico a los dispositivos.

4.- Mantenimiento de sistemas confiables

4.1.- Introduccin

En este tema, se tratan las principales labores a realizar por parte del administrador, para mantener un sistema seguro, as como las tcnicas mas utilizadas para evitar la prdida de datos y para responder a los ataques de los intrusos.

4.2.- Criptografa
Aunque la misin principal de la seguridad en un sistema informtico es mantener la informacin confidencial, en ocasiones, no podemos confiar slo en la seguridad del sistema. Cuando la informacin es demasiado importante, se enva a travs de medios de comunicacin poco confiables o es imposible mantenerla en secreto, no queda ms remedio que recurrir a la criptografa. En la actualidad, existen multitud de mtodos y aplicaciones criptogrficas. Como no es el objetivo de este trabajo, slo haremos una breve mencin de los diferentes tipos de sistemas criptogrficos y su relacin con el cifrado de contraseas. Hasta la dcada de los 70, todos los criptosistemas conocidos, funcionaban con una clave de cifrado igual a la de descifrado o, si eran diferentes, una poda obtenerse de la otra en un tiempo y con unos recursos razonables. La invulnerabilidad de tales sistemas dependa, por tanto, del mantenimiento en secreto de la clave. Consiguientemente, deba transmitirse del emisor al receptor a travs de un canal seguro, obviamente diferente del canal del criptosistema, que por hiptesis est amenazado por posibles interceptores. Estos criptosistemas se denominan de clave secreta, de clave nica y tambin simtricos. Sin embargo, en 1976, Diffie y Hellman demostraron la posibilidad de conseguir criptosistemas que no precisaban transferir una clave secreta entre el emisor y el receptor, evitando as los problemas inherentes a la bsqueda de canales seguros para tal transferencia, previamente al establecimiento de una transmisin cifrada. En estos criptosistemas la clave de cifrado, denominada clave pblica, se hace de general conocimiento. Sin embargo la clave de descifrado, denominada clave privada, se mantiene en secreto. Obviamente ambas claves no son independientes, pero del conocimiento de la pblica no se infiere la privada, a no ser que se tenga algn dato adicional que tambin habr que mantenerse en secreto o, mejor, destruirse una vez generado el par clave pblica-clave privada. Cuando un usuario desea recibir informaciones cifradas, da a conocer a todos los potenciales remitentes su clave pblica. As, stos cifrarn los mensajes destinados al citado usuario con la misma clave, la pblica del destinatario. Sin embargo, no conociendo nadie ms la clave privada, ni pudindola obtener a partir de la pblica, slo el destinatario podr descifrar la informacin a l remitida.

Estos criptosistemas se denominan, de clave pblica o asimtricos, pues del conocimiento de una clave no se deduce la otra. Todava se puede considerar un ltimo tipo de sistemas de cifrado denominados criptosistemas irreversibles, basados en algoritmos no invertibles. En estos criptosistemas, dado el criptograma no es posible obtener el mensaje en claro. Figuradamente, se puede decir que slo trabajan en un sentido, el que lleva del mensaje en texto claro al texto cifrado, pero no en el contrario, que conduce de este ltimo a aqul. Estos cifrados se emplean en aplicaciones que no requieren descifrar los criptogramas. Una de estas aplicaciones consiste en la determinacin de si un cierto mensaje se corresponde con un determinado texto cifrado almacenado en un sistema. Para ello el algoritmo de cifrado produce un criptograma, que se compara con el guardado en la memoria. Para esta aplicacin se requiere, adems de que el algoritmo sea no invertible, que sea unvoco, es decir, que dos mensajes distintos produzcan dos cifrados diferentes. Un ejemplo de este tipo de aplicaciones se tiene en el almacenamiento de las contraseas de usuarios de un sistema. El mantenimiento en memoria de las mismas sin cifrar representa un grave riesgo, pues alguien puede averiguarlas y suplantar a los legtimos usuarios. Almacenarlas cifradas mediante criptosistemas de los tipos vistos hasta ahora tambin es inseguro, pues la clave descifrada puede ser conocida por el administrador del sistema (y posiblemente por ms profesionales informticos que trabajen sobre el ordenador), quien con el conocimiento del algoritmo de cifrado y de las contraseas criptografiadas es capaz de averiguar las contraseas en claro. Por lo anterior, para el almacenamiento de contraseas se emplean algoritmos no invertibles. Cada vez que el usuario introduce su contrasea, se cifra y compara con la contrasea cifrada almacenada en la tabla correspondiente. El acceso se permite slo si coinciden ambas. Esto implica que una contrasea olvidada no se puede recuperar, debindose generar otra que ser nuevamente almacenada como un criptograma.

4.3.- Defensa de cuentas

Cada una de las cuentas en la computadora, es una puerta al exterior, un portal a travs del cual usuarios autorizados y no autorizados pueden entrar. Algunos de los portales estn bien protegidos, mientras que otros pueden no estarlo. El administrador del sistema debe buscar puntos dbiles y sellarlos. 4.3.1.- Cuentas sin contrasea La contrasea de cada una de las cuentas es la primera lnea de defensa de un sistema. Una cuenta sin contrasea es una puerta sin cerradura, cualquiera que conozca el nombre de la cuenta puede entrar. Muchos de los intrusos t ienen xito, slo por que son buenos para encontrar cuentas sin contrasea o cuentas que tienen contraseas fciles de adivinar.

En la versin SVR4 de UNIX, se pueden rastrear cuentas sin contrasea usando la instruccin: # logins -p Tambin se pueden rastrear las cuentas sin contrasea usando la instruccin: % cat-passwd | awk -F: 'length($2)<1 {print $1}' manurod maripet En este ejemplo, manurod y maripet no tienen contrasea no tienen contrasea. Obsrvense los registros en el archivo /etc/passwd.
manurod:EH5/.mj7J5dFh:501:100:Manuel Rodrguez:/home/alumnos/manurod:/bin/bash maripet:aCq87MC03c9e:502:100:Mario Petru:/home/alumnos/maripet:/bin/bash

Puede que el archivo /etc/passwd no sea el ms indicado para buscar cuentas sin contrasea en los sistemas que tienen instalados archivos de contraseas ocultas. Diferentes sistemas de contraseas ocultas almacenan las contraseas cifradas reales en diferentes lugares. Tambin es el caso de sistemas que usan NIS, NIS+ o DCE. 4.3.2.- Cuentas predeterminadas Muchos sistemas se entregan al usuario final con una o ms cuentas predeterminadas. Estas cuentas generalmente tienen contraseas estndar. Por ejemplo, muchas computadoras UNIX vienen con una cuenta root que no tiene contrasea. Los distribuidores aconsejan a los usuarios asignar contraseas a esas cuentas, pero con mucha frecuencia los usuarios no lo hacen. Una forma de solucionar este problema que han utilizado muchos distribuidores es hacer que el sistema operativo solicite contraseas para cuentas especiales como root cuando se instala por primera vez. Algunos programas de aplicacin instalan automticamente cuentas con nombres como demo (que se usa para demostrar los programas). Es necesario asegurarse de borrar o inhabilitar esas cuentas despus de instalar el programa 4.3.3.- Cuentas que ejecutan slo una instruccin

UNIX permite al administrador crear cuentas que pueden ejecutar simplemente una sola instruccin o programa de aplicacin, en lugar del intrprete de comandos, cuando un usuario entra en ellas. A menudo estas cuentas no tienen contrasea. Si se tienen estas cuentas instaladas en la computadora, alguien puede usarlas para encontrar la hora o determinar quin est conectado a la computadora al teclear simplemente el nombre de la instruccin en el indicador login:. Si se decide configurar una cuenta de este tipo, se debe asegurar de que la instruccin que se ejecuta no reciba ninguna entrada desde teclado, y que no pueda forzarse a dar al usuario un proceso interactivo. Especficamente, estos programas no deben tener escapes al interprete de comandos. 4.3.4.- Cuentas abiertas Muchos sistemas proporcionan cuentas en las cuales los visitantes pueden acceder a juegos, a un modem o a una conexin a la red. Estas cuentas reciben nombres como play, open o guest y no suelen precisar de contrasea. Debido a que los nombres de estas cuentas son conocidos o fciles de adivinar, representan potencialmente violaciones a la seguridad, ya que un agresor puede entrar inicialmente a una de estas cuentas para, rastrear desde all fallos de seguridad de mayor ndole . 4.3.4.1.- interpretes de comandos restringidos Un intrprete de instrucciones restringido se puede usar para minimizar los peligros que representa una cuenta abierta. Este modo ocurre cuando se invoca al intrprete de instrucciones en la lnea de comandos con la opcin -r, o con la instruccin llamada rsh (interprete de instrucciones restringido). Cuando rsh se inicia, ejecuta las instrucciones en el archivo $HOME/.profile. Una vez que el .profile se procesa, la siguientes restricciones tienen efecto: El usuario no puede cambiar el directorio actual. El usuario no puede cambiar el valor de la variable PATH. El usuario no puede usar nombres de instrucciones que contengan '/'. El usuario no puede redirigir la salida con '>' o '>>'.

Como una medida de seguridad adicional, si el usuario trata de interrumpir el rsh mientras est procesando el archivo $HOME/.profile , el rsh sale inmediatamente. 4.3.4.2.- Sistemas de archivos restringidos Otra forma de restringir a los usuarios del sistema es ponindolos en un sistema de archivos restringidos. La forma de hacer esto es con la llamada del sistema chroot(), que cambia la vista que un proceso tiene del sistema de archivos, de tal manera que el directorio raz que ve no es el del sistema de archivos real sino uno de sus descendientes. En SVR4 esto se puede conseguir poniendo un '*' en el campo de intrprete de instrucciones del usuario en el archivo /etc/passwd , entonces el sistema har una llamada a chroot()con el campo de directorio HOME del usuario. El sistema de archivos restringido debe contener todos los archivos e instrucciones necesarios para que el programa login se ejecute y para poder ejecutar programas, incluyendo bibliotecas compartidas. Esto es til para mantener cuentas de usuario limitadas, para que estos usuarios slo puedan realizar un conjunto limitado de tareas y para la evaluacin de programas nuevos de funcionamiento dudoso

4.4.- Auditora
4.4.1.- Introduccin Casi todas las actividades realizadas en un sistema UNIX son susceptibles de ser monitorizadas: desde las horas de acceso de cada usuario al sistema hasta las paginas web ms visitadas, pasando por los intentos fallidos de conexin, los programas ejecutados o incluso el tiempo de CPU que cada usuario consume. Obviamente esta facilidad de UNIX para recoger informacin tiene unas ventajas inmediatas para la seguridad: es posible detectar un intento de ataque nada mas producirse el mismo, as como detectar usos indebidos de los recursos o actividades sospechosas; sin embargo, existen desventajas, ya que la gran cantidad de informacin que potencialmente se registra puede ser aprovechada para crear negaciones de servicio o esa cantidad de informacin puede hacer difcil detectar problemas por el volumen de datos a analizar. La mayora de los log en UNIX son simples ficheros de texto, que se pueden visualizar con un cat. Por una parte esto es bastante cmodo para el administrador del sistema, ya que no necesita de herramientas

especiales para poder revisar los logs e incluso puede programar shellscripts para comprobar los informes generados de forma automtica, con ordenes como awk, grep o sed. No obstante, el hecho de que estos ficheros sean texto plano hace que un atacante lo tenga muy fcil para ocultar ciertos registros modificando los archivos con cualquier editor de textos. 4.4.2.- El sistema de log en UNIX Una desventaja aadida al sistema de auditora en UNIX puede ser la complejidad que puede alcanzar una correcta configuracin; por si la dificultad del sistema no fuera suficiente, en cada UNIX el sistema de logs tiene peculiaridades que pueden propiciar la perdida de informacin interesante de cara al mantenimiento de sistemas seguros. Aunque muchos de los ficheros de log de los que hablaremos a continuacin son comunes en cualquier sistema, su localizacin, o incluso su formato, pueden variar entre diferentes sistemas. La localizacin de ficheros y ciertas ordenes relativas a la auditora varan de unas maquinas a otras, por lo que es muy recomendable consultar las paginas del manual antes de ponerse a configurar el sistema de auditora en un equipo concreto. La principal diferencia entre los diferentes sistemas es el denominado process accounting o simplemente accounting, consistente en registrar todos los programas ejecutados por cada usuario; evidentemente, los informes generados en este proceso pueden llegar a ocupar muchsimo espacio en disco (dependiendo del numero de usuarios en nuestro sistema) por lo que solo es recomendable en situaciones muy concretas, por ejemplo para detectar actividades sospechosas en una maquina o para cobrar por el tiempo de CPU consumido. En los sistemas System V el process accounting esta desactivado por defecto; se puede iniciar mediante /usr/lib/acct/startup, y para visualizar los informes se utiliza la orden acctcom. En la familia BSD los equivalentes a estas ordenes son accton y lastcomm; en este caso el process accounting esta inicializado por defecto. Con el modelo clsico se genera un registro tras la ejecucin de cada proceso, en UNIX C2 se proporciona una pista de auditora donde se registran los accesos y los intentos de acceso de una entidad a un objeto, as como cada cambio en el estado del objeto, la entidad o el sistema global. Esto se consigue asignando un identificador denominado Audit ID a cada grupo de procesos ejecutados (desde el propio login), identificador que se registra junto a la mayora de llamadas al sistema que un proceso realiza, incluyendo algunas tan comunes como write(), open(), close() o read(). Registrar todo esto conlleva un gran cantidad de espacio y de CPU, por lo que en la mayora de sistemas, el modelo de auditora C2 es innecesario y en muchas ocasiones se convierte en una monitorizacion

intil si no se dispone de mecanismos para interpretar o reducir la gran cantidad de datos registrados: el administrador guarda tanta informacin que es casi imposible analizarla en busca de actividades sospechosas. 4.4.3.- El demonio syslogd El demonio syslogd (Syslog Daemon) se lanza automticamente al arrancar un sistema UNIX, y es el encargado de guardar informes sobre el funcionamiento de la maquina. Recibe mensajes de las diferentes partes del sistema (ncleo, programas. . . ) y los enva y/o almacena en diferentes localizaciones, tanto locales como remotas, siguiendo un criterio definido en el fichero de configuracin /etc/syslog.conf, donde especificamos las reglas a seguir para gestionar el almacenamiento de mensajes del sistema. Las lneas de este archivo que comienzan por `#' son comentarios, con lo cual son ignoradas de la misma forma que las lneas e n blanco; si ocurriera un error al interpretar una de las lneas del fichero, se ignorara la lnea completa. Un ejemplo de fichero /etc/syslog.conf es el siguiente:
# Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* /var/log/maillog # Everybody gets emergency messages, plus log them on another # machine. *.emerg * # Save mail and news errors of level err and higher in a # special file.

uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log

Podemos ver que cada regla del archivo tiene dos campos: un campo de seleccin y un campo de accin, separados por espacios o tabuladores. El campo de seleccin esta formado a su vez de dos partes: una del servicio que enva el mensaje y otra de su prioridad, separadas por un punto ( . ); ambas son indiferentes a maysculas y minsculas. La parte del servicio contiene una de las siguientes palabras clave: auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (equivalente a auth), syslog, user, uucp y local0 hasta local7. Esta parte especifica el subsistema que ha generado ese mensaje (por ejemplo, todos los programas relacionados con el correo generaran mensajes ligados al servicio mail). La prioridad esta compuesta de uno de los siguientes trminos, en orden ascendente: debug, info, notice, warning, warn (equivalente a warning), err, error (equivalente a err), crit, alert, emerg, y panic (equivalente a emerg). La prioridad define la gravedad o importancia del mensaje almacenado. Todos los mensajes de la prioridad especificada y superiores son almacenados de acuerdo con la accin requerida. Ademas de los trminos mencionados hasta ahora, el demonio syslogd emplea los siguientes caracteres especiales: '*' (asterisco) Empleado como comodn para todas las prioridades y servicios anteriores, dependiendo de dnde son usados (si antes o despus del carcter de separacin . ):
# Guardar todos los mensajes del servicio mail en /var/adm/mail # mail.* /var/adm/mail

' ' (blanco, espacio, nulo) Indica que no hay prioridad definida para el servicio de la linea almacenada. ',' (coma) Con este carcter es posible especificar mltiples servicios con el mismo patrn de prioridad en una misma lnea. Es posible enumerar cuantos servicios se quieran:
# Guardar todos los mensajes mail.info y news.info en # /var/adm/info

mail,news.=info /var/adm/info

';' (punto y coma) Es posible dirigir los mensajes de varios servicios y prioridades a un mismo destino, separndolos por este carcter:
# Guardamos los mensajes de prioridad "info" y "notice" # en el archivo /var/log/messages *.=info;*.=notice /var/log/messages

'=' (igual) De este modo solo se almacenan los mensajes con la prioridad exacta especificada y no incluyendo las superiores:
# Guardar todos los mensajes crticos en /var/adm/critical # *.=crit /var/adm/critical

'!' (exclamacin) Preceder el campo de prioridad con un signo de exclamacin sirve para ignorar todas las prioridades, teniendo la posibilidad de escoger entre la especificada (!=prioridad) y la especificada ms todas las superiores (!prioridad). Cuando se usan conjuntamente los caracteres `=' y `!', el signo de exclamacin `!' debe preceder obligatoriamente al signo igual `=', de esta forma:!=.
# Guardar mensajes del kernel de prioridad info, pero no de # prioridad err y superiores # Guardar mensajes de mail excepto los de prioridad info kern.info;kern.!err /var/adm/kernel-info mail.*;mail.!=info /var/adm/mail

Por su parte, el campo de accin describe el destino de los mensajes, que puede ser : Un fichero plano: Normalmente los mensajes del sistema son almacenados en ficheros planos. Dichos ficheros han de estar especificados con la ruta de acceso completa (comenzando con `/'). Podemos preceder cada entrada con el signo menos, - , para omitir la sincronizacin del archivo (vaciado del buffer de memoria a disco). Aunque puede ocurrir que se pierda informacin si el sistema cae justo despus de un intento de escritura en el archivo, utilizando este signo se puede conseguir una mejora importante en la velocidad,

especialmente si estamos ejecutando programas que mandan muchos mensajes al demonio syslogd.
# Guardamos todos los mensajes de prioridad critica en critical # *.=crit /var/adm/critical

Un terminal (o la consola): Tambin tenemos la posibilidad enviar los mensajes a terminales; de este modo podemos tener uno los terminales virtuales que muchos sistemas UNIX ofrecen en consola dedicado a listar los mensajes del sistema, que podrn consultados con solo cambiar a ese terminal:

de de su ser

# Enviamos todos los mensajes a tty12 (ALT+F12 en Linux) y # todos los mensajes crticos del ncleo a consola # *.* /dev/tty12 kern.crit /dev/console

Una tubera con nombre: Algunas versiones de syslogd permiten enviar registros a ficheros de tipo pipe simplemente anteponiendo el smbolo ` | ' al nombre del archivo; dicho fichero ha de ser creado antes de iniciar el demonio syslogd, mediante ordenes como mkfifo o mknod. Esto es til para debug y tambin para procesar los registros utilizando cualquier aplicacin de UNIX, tal y como veremos al hablar de logs remotos cifrados. Por ejemplo, la siguiente lnea de /etc/syslog.conf enviara todos los mensajes de cualquier prioridad a uno de estos ficheros denominado /var/log/mififo:
# Enviamos todos los mensajes a la tubera con nombre # /var/log/mififo # *.* |/var/log/mififo

Una mquina remota: Se pueden enviar los mensajes del sistema a otra maquina, de manera que sean almacenados remotamente. Esto es til si tenemos una maquina segura, en la que podemos confiar, conectada a la red, ya que de esta manera se guardara all una copia de los mensajes de nuestro sistema y no podran ser modificados en caso de que alguien entrase en nuestra maquina. Esto es especialmente

til para detectar usuarios ocultos en nuestro sistema (usuarios maliciosos que han conseguido los suficientes privilegios para ocultar sus procesos o su conexin):
# Enviamos los mensajes de prioridad warning y superiores al # fichero "syslog" y todos los mensajes (incluidos los # anteriores) a la maquina "secure.upv.es" # *.warn /usr/adm/syslog *.* @secure.machine.es

Unos usuarios del sistema (si estn conectados): Se especifica la lista de usuarios que deben recibir un tipo de mensajes simplemente escribiendo su login, separados por comas:
# Enviamos los mensajes con la prioridad "alert" a root y toni # *.alert root, maripet

Todos los usuarios que estn conectados: Los errores con una prioridad de emergencia se suelen enviar a todos los usuarios que estn conectados al sistema, de manera que se den cuenta de que algo va mal:
# Mostramos los mensajes urgentes a todos los usuarios # conectados, mediante wall *.=emerg *

4.4.4 Algunos archivos de log En funcin de la configuracin del sistema de auditora de cada equipo UNIX los eventos que sucedan en la maquina se registraran en determinados ficheros; aunque podemos loggear en cualquier fichero (incluso a travs de la red o en dispositivos, como veremos luego), existen ciertos archivos de registro habituales en los que se almacena informacin. A continuacin comentamos los mas comunes y la informacin que almacenan. syslog

El archivo syslog (guardado en /var/adm/ o /var/log/) es quizs el fichero de log mas importante del sistema; en l se guardan, en texto claro, mensajes relativos a la seguridad de la maquina, como los accesos o los intentos de acceso a ciertos servicios. Sin embargo, este fichero es escrito por syslogd, por lo que dependiendo de nuestro fichero de configuracin encontraremos en el archivo una u otra informacin. Al estar guardado en formato texto, podemos visualizar su contenido con un simple cat:
Mar 5 04:15:23 anita in.telnetd[11632]: connect from localhost Mar 5 06:16:52 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 5 06:16:53 anita last message repeated 3 times Mar 5 06:35:08 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 5 18:26:56 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 5 18:28:47 anita last message repeated 1 time Mar 5 18:32:43 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 6 02:30:26 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 6 03:31:37 anita rpcbind: connect from 127.0.0.1 to getport(R ) Mar 6 11:07:04 anita in.telnetd[14847]: connect from rosita Mar 6 11:40:43 anita in.telnetd[14964]: connect from localhost

messages En este archivo de texto se almacenan datos informativos de ciertos programas, mensajes de baja o media prioridad destinados mas a informar que a avisar de sucesos importantes, como informacin relativa al arranque de la maquina; no obstante, como suceda con el fichero syslog, en funcin de /etc/syslog.conf podremos guardar todo tipo de datos. Para visualizar su contenido es suficiente una orden como cat o similares (slo se muestra un pequeo fragmento, este archivo contiene 1392 lneas en este momento):

Dec 2 16:21:21 localhost syslogd 1.3-3: restart. Dec 2 16:21:21 localhost syslog: syslogd startup succeeded Dec 2 16:21:21 localhost kernel: klogd 1.3-3, log source = /proc/kmsg started. Dec 2 16:21:21 localhost syslog: klogd startup succeeded Dec 2 16:21:21 localhost kernel: Inspecting /boot/System.map-2.2.14-5.0 Dec 2 16:21:21 localhost kernel: Loaded 7364 symbols from /boot/System.map-2.2.14-5.0. Dec 2 16:21:21 localhost kernel: Symbols match kernel version 2.2.14. Dec 2 16:21:21 localhost kernel: Loaded 189 symbols from 9 modules. Dec 2 16:21:21 localhost kernel: Linux version 2.2.14-5.0 (root@porky.devel.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 7 21:07:39 EST 2000 Dec 2 16:21:21 localhost kernel: Detected 501145385 Hz processor. Dec 2 16:21:21 localhost kernel: Console: colour VGA+ 80x25 Dec 2 16:21:21 localhost kernel: Calibrating delay loop. 499.71 BogoMIPS Dec 2 16:21:21 localhost kernel: Memory: 127852k/131008k available (1060k kernel code, 416k reserved, 1616k data, 64k init, 0k bigmem) Dec 2 16:21:21 localhost kernel: Dentry hash table entries: 262144 (order 9, 2048k) Dec 2 16:21:21 localhost kernel: Buffer cache hash table entries: 131072 (order 7, 512k) Dec 2 16:21:21 localhost kernel: Page cache hash table entries: 32768 (order 5, 128k) Dec 2 16:21:21 localhost kernel: VFS: Diskquotas version dquot_6.4.0 initialized Dec 2 16:21:21 localhost kernel: CPU: Intel Pentium III (Katmai) stepping 03 Dec 2 16:21:21 localhost kernel: Enabling extended fast FPU save and restore...done. Dec 2 16:21:21 localhost kernel: Not enabling KNI unmasked exception support

Dec 2 16:21:21 localhost kernel: Exception 19 error handler not integrated yet Dec 2 16:21:22 localhost kernel: Disabling CPUID Serial number...done. Dec 2 16:21:22 localhost kernel: Checking 386/387 coupling. OK, FPU using exception 16 error reporting.

wtmp Este archivo es un fichero binario (no se puede leer su contenido directamente volcndolo con cat o similares) que almacena informacin relativa a cada conexin y desconexin al sistema. Podemos ver su contenido con ordenes como last:
anita:/# last -10 toni pts/11 localhost Mon Mar 6 11:07 - 11:07 (00:00) toni pts/11 rosita Sun Mar 5 04:22 - 04:25 (00:03) ftp ftp andercheran.aiin Sun Mar 5 02:30 still logged in ftp ftp andercheran.aiin Sun Mar 5 00:28 02:30 (02:01) ftp ftp anita Thu Mar 2 03:02 - 00:28 (2+21:25) ftp ftp anita Thu Mar 2 03:01 - 03:02 (00:00)

Los registros guardados en este archivo (y tambin en utmp) tienen el formato de la estructura utmp, que contiene informacin como el nombre de usuario, la lnea por la que accede, el lugar desde donde lo hace y la hora de acceso. Algunas variantes de UNIX (como Solaris o IRIX) utilizan un fichero wtmp extendido denominado wtmpx, con campos adicionales que proporcionan mas informacin sobre cada conexin. utmp El archivo utmp es un fichero binario con informacin de cada usuario que est conectado en un momento dado; el programa /bin/login genera un registro en este fichero cuando un usuario conecta, mientras que init lo elimina cuando desconecta. Aunque habitualmente este archivo est situado en /var/adm/, junto a otros ficheros de log. Para visualizar el contenido de este archivo podemos utilizar ordenes como last (indicando el nombre de fichero mediante la opcin -f), w o who:
anita:/# who

root console Mar 2 00:13 root pts/2 Mar 3 00:47 (UNIX) root pts/3 Mar 2 00:18 (UNIX) root pts/5 Mar 2 00:56 (UNIX) root pts/6 Mar 2 02:23 (UNIX:0.0) root pts/8 Mar 3 00:02 (UNIX:0.0) root pts/7 Mar 2 23:43 (UNIX:0.0) root pts/9 Mar 3 00:51 (UNIX) root pts/10 Mar 6 00:23 (UNIX) anita:/#

Como suceda con wtmp, algunos UNIX utilizan tambin una versin extendida de utmp (utmpx) con campos adicionales. lastlog El archivo lastlog es un fichero binario guardado generalmente en /var/adm/, y que contiene un registro para cada usuario con la fecha y hora de su ultima conexin; podemos visualizar estos datos para un usuario dado mediante la orden finger:
anita:/# finger toni Login name: toni In real life: Toni at ANITA Directory: /export/home/toni Shell: /bin/sh Last login Mon Mar 6 11:07 on pts/11 from localhost No unread mail No Plan. anita:/#

faillog Este fichero es equivalente al anterior, pero en lugar de guardar informacin sobre la fecha y hora del ultimo acceso al sistema lo hace del ultimo intento de acceso de cada usuario; una conexin es fallida si el usuario (o alguien en su lugar) teclea incorrectamente su

contrasea. Esta informacin se muestra la siguiente vez que dicho usuario entra correctamente a la maquina:
andercheran login: toni Password: Linux 2.0.33. 1 failure since last login. Last was 14:39:41 on ttyp9. Last login: Wed May 13 14:37:46 on ttyp9 from pleione.cc.upv.es. Andercheran:~$

loginlog Si en algunas versiones de UNIX (como Solaris) creamos el archivo /var/adm/loginlog (que originalmente no existe), se registraran en l los intentos fallidos de login, siempre y cuando se produzcan cinco o mas de ellos seguidos:
anita:/# cat /var/adm/loginlog toni:/dev/pts/6:Thu Jan 6 07:02:53 2000 toni:/dev/pts/6:Thu Jan 6 07:03:00 2000 toni:/dev/pts/6:Thu Jan 6 07:03:08 2000 toni:/dev/pts/6:Thu Jan 6 07:03:37 2000 toni:/dev/pts/6:Thu Jan 6 07:03:44 2000 anita:/#

btmp En algunas distribuciones de UNIX, como Linux o HP-UX, el fichero btmp se utiliza para registrar las conexiones fallidas al sistema, con un formato similar al que wtmp utiliza para las conexiones que han tenido xito:
andercheran:~# last -f /var/adm/btmp |head -7 pnvarro ttyq1 term104.aiind.up Wed Feb 9 16:27 - 15:38 (23:11)

jomonra ttyq2 deportes.etsii.u Fri Feb 4 14:27 - 09:37 (9+19:09) PNAVARRO ttyq4 term69.aiind.upv Wed Feb 2 12:56 - 13:09 (20+00:12) panavarr ttyq2 term180.aiind.up Fri Jan 28 12:45 - 14:27 (7+01:42) barra ttyp0 dtra-51.ter.upv. Thu Jan 27 18:42 20:17 (01:34) andercheran:~#

sulog Este es un fichero de texto donde se registran las ejecuciones de la orden su, indicando fecha, hora, usuario que lanza el programa y usuario cuya identidad adopta, terminal asociada y xito ('+') o fracaso ('-') de la operacin:
anita:/# head -4 /var/adm/sulog SU 12/27 07:41 + console root-toni SU 12/28 23:42 - vt01 toni-root SU 12/28 23:43 + vt01 toni-root SU 12/29 01:09 + vt04 toni-root anita:/#

debug En este archivo de texto se registra informacin de depuracin (de debug) de los programas que se ejecutan en la maquina; esta informacin puede ser enviada por las propias aplicaciones o por el ncleo del sistema operativo: luisa:~# tail -8 /var/adm/debug
Dec 17 18:51:50 luisa kernel: ISO9660 Extensions: RRIP_1991A Dec 18 08:15:32 luisa sshd[3951]: debug: sshd version 1.2.21 [i486unknown-linux] Dec 18 08:15:32 luisa sshd[3951]: debug: Initializing random number generator; seed file /etc/ssh_random_seed Dec 18 08:15:32 luisa sshd[3951]: debug: inetd sockets after dupping: 7, 8

Dec 18 08:15:34 luisa sshd[3951]: debug: Client protocol version 1.5; client software version 1.2.21 Dec 18 08:15:34 luisa sshd[3951]: debug: Calling cleanup 0x800cf90(0x0) Dec 18 16:33:59 luisa kernel: VFS: Disk change detected on device 02:00 Dec 18 23:41:12 luisa identd[2268]: Successful lookup: 1593 , 22 : toni.users luisa:~#

4.5.- Amenazas programadas

4.5.1.- Introduccin En 1990 Barton P. Miller y un grupo de investigadores publicaron un artculo en el que se mostraba que demasiadas herramientas estndar (ms del 25%) de UNIX fallaban ante elementos tan simples como una entrada anormal. Cinco aos ms tarde otro grupo de investigacin, dirigido tambin por Barton P. Miller, realiz el estudio, lamentablemente no publicado; las conclusiones en este ltimo estudio fueron sorprendentes: el sistema con las herramientas ms estables era Slackware Linux, un UNIX gratuito y de cdigo fuente libre que presentaba una tasa de fallos muy inferior al de sistemas comerciales como Solaris o IRIX. Era preocupante comprobar como la mayora de problemas descubiertos en 1990 segua presente en los sistemas UNIX estudiados. Aunque por fortuna la calidad del software ha mejorado mucho en los ltimos aos, y esa mejora lleva asociada una mejora en la robustez del cdigo, los fallos y errores de diseo en aplicaciones o en el propio ncleo son una de las fuentes de amenazas a la seguridad de todo sistema informtico. Pero no slo los errores son problemticos, sino que existen programas como los virus realizados en la mayora de situaciones no para realizar tareas tiles sino para comprometer la seguridad de una mquina o de toda una red. Este tipo de programas solamente compromete la seguridad cuando afectan al administrador; si un virus infecta ficheros de un usuario, o si ste ejecuta un troyano, solo podr perjudicarse a s mismo: podr borrar sus ficheros, enviar correo en su nombre o matar sus procesos, pero no hacer lo mismo con el resto de usuarios o el root. El problema para la seguridad viene cuando es el propio administrador quien utiliza programas contaminados por cualquier clase de fauna, y para evitar esto hay una medida de proteccin bsica: la prevencin. Es crucial que las actividades como administrador se reduzcan al mnimo, ejecutando como usuario normal las tareas que no requieran de privilegios. Cuando no quede ms remedio que trabajar c omo root

(por ejemplo a la hora de instalar software en el sistema), no hemos de ejecutar nada que no provenga de una fuente fiable, e incluso as tomar precauciones en caso de que el programa realice funciones mnimamente delicadas para el sistema operativo (por ejemplo, probarlo antes en una mquina de testeo, o en entornos cerrados con chroot()). Es muy normal, sobre todo entre administradores de Linux, el recomendar que no se ejecute nada sin haber ledo previamente el cdigo fuente, o al menos que dicho cdigo est disponible; esto, aunque es una solucin perfecta al problema, es inaplicable en la mayora de situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su cdigo abierto a sus usuarios, por lo que nos estaramos restringiendo a utilizar programas generalmente no comerciales algo que quizs no depende de nosotros, como administradores. Por otro, resulta absurdo pensar que un administrador tenga el tiempo necesario para leer (y lo ms importante, para comprobar) cada lnea del cdigo de todos los programas instalados en sus mquinas. 4.5.2.-Base Fiable de Cmputo La base fiable de cmputo (Trusted Computing Base, TCB) es una caracterstica de ciertos UNIX que incrementa la seguridad del sistema marcando ciertos elementos del mismo como seguros . Aunque estos elementos son bsicamente el hardware y ciertos ficheros, la parte software es mucho ms importante para el administrador que la mquina fsica, por lo que aqu hablaremos principalmente de ella. Los ficheros pertenecientes a la base segura de cmputo, y la TCB en su conjunto, tratan de asegurar al administrador que est ejecutando el programa que desea y no otro que un intruso haya podido poner en su lugar (conteniendo, por ejemplo, un troyano). La TCB implementa la poltica de seguridad del sistema inspeccionando y vigilando las interacciones entre entidades (procesos) y objetos (principalmente ficheros); dicha poltica suele consistir en un control de accesos y en la reutilizacin de objetos (cmo debe inicializarse o desinstalarse un objeto antes de ser reasignado). Los ficheros con la marca de seguridad activada son generalmente el propio ncleo del sistema operativo y archivos que mantienen datos relevantes para la seguridad, contenidos en ciertos directorios como /tcb/ o /etc/auth/; cualquier fichero nuevo o que pertenezca a la TCB pero que haya sido modificado automticamente tiene su marca desactivada. Puede ser activada o reactivada por el administrador (por ejemplo, en AIX con la orden tcbck -a), aunque en algunos sistemas para que un archivo pertenezca a la TCB tiene que haber sido creado con programas que ya pertenecan a la TCB. Con este mecanismo se trata de asegurar que nadie, y especialmente el root, va a ejecutar por accidente cdigo peligroso: si el administrador ha de ejecutar tareas sensibles de cara a la seguridad, puede arrancar un intrprete de

comandos seguro (perteneciente a la TCB) que slo le permitir ejecutar programas que estn en la base. La comunicacin entre la base fiable de cmputo y el usuario se h a de realizar a travs de lo que se denomina la ruta de comunicacin fiable (Trusted Communication Path, TCP), ruta que se ha de invocar mediante una combinacin de teclas (por ejemplo, Ctrl-X Ctrl-R en AIX) denominada SAK (Secure Attention Key) siempre que el usuario deba introducir datos que no deban ser comprometidos, como una clave. Tras invocar a la ruta de comunicacin fiable mediante la combinacin de teclas correspondiente el sistema operativo se ha de asegurar de que los programas no fiables (los n o incluidos en la TCB) no puedan acceder a la terminal desde la que se ha introducido el SAK; una vez conseguido esto generalmente a partir de init se solicitar al usuario en la terminal su login y su password, y si ambos son correctos se lanzar un shell fiable (tsh), que slo ejecutar programas miembros de la TCB (algo que es muy til por ejemplo para establecer un entorno seguro para la administracin del sistema, si el usuario es el root). Desde el punto de vista del usuario, tras pulsar el SAK lo nico que aparecer ser un prompt solicitando el login y la clave; si en lugar de esto aparece el smbolo de tsh, significa que alguien ha intentado robar nuestra contrasea: deberemos averiguar quin est haciendo uso de esa terminal (por ejemplo mediante w ho) y notificarlo al administrador o tomar las medidas oportunas si ese administrador somos nosotros . A pesar de la utilidad de la TCB, es recomendable recordar que un fichero incluido en ella, con la marca activada, no siempre es garanta de seguridad; como todos los mecanismos existentes, la base fiable de cmputo est pensada para utilizarse junto a otros mecanismos, y no en lugar de ellos. 4.5.3.-Tipos de amenazas programadas Virus Un virus es una secuencia de cdigo que se inserta en un fichero ejecutable, denominado host, de forma que al ejecutar el programa, tambin se ejecuta el virus. Generalmente esta ejecucin implica la copia del cdigo del virus, en otros programas. El virus necesita un programa donde insertarse para ejecutarse, por lo que no puede ser considerado como un programa o proceso independiente. Durante aos, se ha discutido sobre la existencia de virus en el entorno UNIX. Realmente, existen virus que infectan tanto binarios ELF como shellscripts. Sin embargo la existencia de virus no tiene mucho inters en sistemas UNIX, ya que generalmente sus efectos no suelen ser muy perjudiciales en los sistemas UNIX de hoy en da.

Gusanos Un gusano es un programa capaz de viajar por s mismo a travs de redes de ordenadores para realizar cualquier actividad una vez alcanzada la mquina. Aunque esta actividad no tiene por qu entraar peligro, un gusano puede instalar en el sistema alcanzado un virus, atacar este sistema como hara un intruso o simplemente consumir excesivas cantidades de ancho de banda en la red afectada. Conejos Los conejos o bacterias son programas que de forma directa no daan al sistema, sino que se limitan a reproducirse, generalmente de forma exponencial, hasta que la cantidad de recursos consumidos (procesador, memoria, disco,...) se convierte en una negacin de servicio para el sistema afectado. La mejor forma de prevenir ataques de conejos ( o simples errores en los programas, que hagan que estos consuman excesivos recursos) es utilizar las facilidades de los ncleos de cualquier UNIX moderno ofrecen para limitar los recursos que un determinado proceso o usuario puede llegar a consumir. Caballos de Troya Un caballo de Troya actual (al igual que el de la mitologa griega) es un programa que aparentemente realiza una funcin til para quin lo ejecuta, pero que en realidad, o aparte, realiza una funcin que el usuario desconoce, generalmente daina. La forma ms fcil de descubrir caballos de Troya (aparte de sufrir sus efectos una vez ejecutado) es comparar los ficheros bajo sospecha con una copia de los originales. Tambin es recomendable realizar resmenes MD5 de nuestros programas y compararlos con los resmenes originales. Applets hostiles En los ltimos aos, con la proliferacin de la web, Java y Javascript, han aparecido los denominados applets hostiles, que al ser descargados intentan monopolizar o explotar los recursos del sistema de forma inapropiada. Esto incluye desde ataques clsicos como negacin de servicio o ejecucin remota de programas en la mquina cliente hasta amenazas mucho ms elaboradas, como difusin de virus, ruptura lgica de cortafuegos o uso de recursos remotos para grandes clculos cientficos.

La propia Sun Microsystems ha reconocido el problema y est trabajando para minimizar los potenciales efectos de estos applets. No obstante, aunque se solucionen los problemas de seguridad del cdigo, es probable que se puedan seguir usando applets como una forma de ataque a los sistemas: mientras que estos programas puedan realizar conexiones por red, no habrn desaparecido los problemas. Bombas lgicas Las bombas lgicas funcionan de manera similar a los troyanos, la diferencia entre ellos es que as como un troyano se ejecuta cada vez que se ejecuta el programa que lo contiene (o al que sustituye), una bomba lgica slo se activa bajo ciertas condiciones, como una determinada fecha, la existencia de un cierto fichero, o el alcance de cierto nmero de ejecuciones. De esta manera, una bomba lgica puede permanecer en el sistema inactiva y sin ser detectada durante mucho tiempo y sin que nadie note nada anormal hasta que el dao producido por la bomba ya est hecho. Puertas traseras Las puertas traseras son trozos de cdigo en un programa que permiten a quin conoce su funcionamiento saltarse los mtodos usuales de autentificacin para realizar cierta tarea. Los programadores suelen usarlas para probar su cdigo durante el desarrollo, pero pueden mantenerlas en el programa final, ya sea deliberada o involuntariamente. Pensemos por ejemplo en un programa que solicita cinco claves para realizar cierta tarea, es muy probable que el programador instale una puerta trasera una vez que ha comprobado el funcionamiento de dichas claves. A parte de puertas traseras en los programas, tambin existen otros tipos de puertas traseras. Son las que instalan los intrusos para garantizarse el futuro acceso al sistema, como aadir un usuario con UID 0, aadir un nuevo servicio en un puerto no utilizado o incluso utilizar cron para reinstalar peridicamente dichas puertas en caso de que hayan sido eliminadas. 4.5.4.-Programacin segura Dado el gran impacto que pueden tener sobre la seguridad los errores de programacin en las aplicaciones, es de vital importancia utilizar tcnicas de programacin seguras. 4.5.4.1.-Buffer overflow Seguramente uno de los errores ms comunes, y sin duda el ms conocido y utilizado es el stack smashing o desbordamiento de

pila, tambin conocido por buffer overflow. Aunque el gusano de Morris (1988) ya lo utilizaba, no fue hasta 1997 cuando este fallo se hizo realmente popular. Aunque cada vez los programas son ms seguros, especialmente los programas SUID, es casi seguro que un potencial atacante que acceda a nuestro sistema va a intentar si no lo ha hecho ya conseguir privilegios de administrador a travs de un buffer overflow. La idea del stack smashing es sencilla: en algunas implementaciones de C es posible corromper la pila de ejecucin de un programa escribiendo ms all de los lmites de un array declarado auto en una funcin; esto puede causar que la direccin de retorno de dicha funcin sea una direccin aleatoria. Esto, unido a permisos de los ficheros ejecutables en UNIX (principalmente a los bits de SUID y SGID), hace que el sistema operativo pueda otorgar acceso root a usuarios sin privilegios. Por ejemplo, imaginemos una funcin que trate de copiar con strcpy() un array de 200 caracteres en uno de 20: al ejecutar el programa, se generar una violacin de segmento (y por tanto el clsico core dump al que los usuarios de UNIX estamos acostumbrados). Se ha producido una sobreescritura de la direccin de retorno de la funcin; si logramos que esta sobreescritura no sea aleatoria sino que apunte a un cdigo concreto (habitualmente el cdigo de un shell), dicho cdigo se va a ejecutar. El problema reside en los programas SUID y SGID; recordemos que cuando alguien los ejecuta, est trabajando con los privilegios de quien los cre, y todo lo que ejecute lo hace con esos privilegios. . . incluido el cdigo que se ha insertado en la direccin de retorno de nuestra funcin problemtica. Si, como hemos dicho, este cdigo es el de un intrprete de comandos y el fichero pertenece al administrador, el atacante consigue ejecutar un shell con privilegios de root. Para minimizar los efectos del desbordamiento de pila, los administradores han de mantener al mnimo el nmero de ficheros SUID y SGID en sus sistemas y los programadores tienen que esforzarse en generar cdigo con menos puntos de desbordamiento. 4.5.4.2.- Recomendaciones para una programacin segura Despus de analizar los problemas que un cdigo mal diseado puede causar, vamos a citar algunas recomendaciones para la elaboracin de programas seguros bajo UNIX. Vamos a hablar de programacin en C, obviamente por ser el lenguaje ms utilizado en UNIX.

El principal problema de la programacin en UNIX lo constituyen los programas SUID y SGID, si un programa sin este bit activo tiene un fallo, lo normal es que ese fallo solamente afecte a quien lo ejecuta. Al tratarse de un error de programacin, algo no intencionado, su primera consecuencia ser el mal funcionamiento de ese programa. Esto cambia cuando el programa es SUID o SGID: en este caso, el error puede comprometer tanto a quien lo ejecuta como a su propietario, y como ese propietario es por norma general root, automticamente se compromete a todo el sistema. Para la codificacin segura de este tipo de programas, se proporcionan unas lneas bsicas: Mximas restricciones a la hora de elegir el UID y el GID: Una medida de seguridad bsica que todo administrador de sistemas UNIX ha de seguir es realizar todas las tareas con el mnimo privilegio que estas requieran; as, a nadie se le ocurre conectarse al IRC o aprender a manejar una aplicacin como root. Esto tambin se aplica a la hora de programar: cuando se crea un programa SUID o SGID se le ha de asignar tanto el UID como el GID menos peligroso para el sistema. Reset de los UIDs y GIDs efectivos antes de llamar a exec(): Uno de los grandes problemas de los programas SUID es la ejecucin de otros programas. Por ejemplo, si el usuario introduce ciertos datos desde teclado, datos que se han de pasar como argumento a otra aplicacin, nada nos asegura que esos datos sean correctos. Por tanto, es aconsejable restablecer el UID y el GID efectivos a los del usuario antes de invocar a exec(), de forma que cualquier ejecucin inesperada se realice con el mnimo privilegio necesario; esto es aplicable a funciones que indirectamente realicen el exec(), como system() o popen(). Es necesario cerrar todos los descriptores de fichero, excepto los estrictamente necesarios, antes de llamar a exec(): Los descriptores de ficheros son un parmetro que los procesos UNIX heredan de sus padres; de esta forma, si un programa SUID est leyendo un archivo, cualquier proceso hijo tendr acceso a ese archivo a no ser que explcitamente se cierre su descriptor antes de ejecutar el exec(). La forma ms fcil de prevenir este problema es activando un flag que indique al sistema que ha de cerrar cierto descriptor cada vez que se invoque a exec(). Esto se consigue mediante las llamadas fcntl() e ioctl(). Hay que asegurarse de que chroot() realmente restringe: Los enlaces duros entre directorios son algo que el ncleo de muchos sistemas UNIX no permiten debido a que genera bucles en el sistema de ficheros, algo que crea problemas a determinadas

aplicaciones. Por ejemplo, Linux no permite crear estos enlaces, pero Solaris o Minix s. En estos ltimos, en los clones de UNIX que permiten hard links entre directorios, la llamada chroot() puede perder su funcionalidad: estos enlaces pueden seguirse aunque no se limiten al entorno con el directorio raz restringido. Es necesario asegurarse de que no hay directorios enlazados a ninguno de los contenidos en el entorno chroot() (podemos verlo con la opcin `-l' de la orden ls, que muestra el nmero de enlaces de cada archivo). Comprobaciones del entorno en que se ejecutar el programa: En UNIX todo proceso hereda una serie de variables de sus progenitores, como el umask, los descriptores de ficheros, o ciertas variables de entorno ($PATH, $IFS. . . ). Para una ejecucin segura, es necesario controlar todos y cada uno de estos elementos que afectan al entorno de un proceso. Especialmente crticas son las funciones que dependen del shell para ejecutar un programa, como system() o execvp(): en estos casos es muy difcil asegurar que el shell va a ejecutar la tarea prevista y no otra. Nunca hacer shellscripts SUID: Aunque en muchos sistemas UNIX la activacin del bit setuid en shellscripts no tiene ningn efecto, muchos otros an permiten que los usuarios especialmente el root creen procesos interpretados y SUID. La potencia de los intrpretes de rdenes de UNIX hace casi imposible controlar que estos programas no realicen acciones no deseadas, violando la seguridad del sistema, por lo que bajo ningn concepto se ha de utilizar un proceso por lotes para realizar acciones privilegiadas con SUID. No utilizar creat() para bloquear: Una forma de crear un fichero de bloqueo es invocar a creat() con un modo que no permita la escritura del archivo (habitualmente el 000), de forma que si otro usuario tratara de hacer lo mismo, su llamada a creat() fallara. Esto, que a primera vista parece completamente vlido, no lo es: en cualquier sistema UNIX, la proteccin que proporcionan los permisos de un fichero slo es aplicable si quien trata de acceder a l no es el root. Si esto es as, es decir, si el UID efectivo del usuario que est accediendo al archivo es 0, los permisos son ignorados completamente y el acceso est permitido. De esta forma, el root puede sobreescribir archivos sin que le importen sus bits rwx, lo que implica que si uno de los procesos que compiten por el recurso bloqueado es SUID a nombre del administrador, el esquema de bloqueo anterior se viene abajo. Para poder bloquear recursos en un programa SUID se utiliza la llamada link(), ya que si se intenta crear un enlace a un fichero que ya existe link() falla aunque el proceso que lo invoque sea

propiedad del root (y aunque el fichero sobre el que se realice no le pertenezca). Tambin es posible utilizar la llamada al sistema flock() de algunos UNIX, aunque es menos recomendable por motivos de portabilidad entre clones. Capturar todas las seales: Un problema que puede comprometer la seguridad del sistema UNIX es el volcado de la imagen en memoria de un proceso cuando ste recibe ciertas seales (el clsico core dump). Esto puede provocar el volcado de informacin sensible que el programa estaba leyendo: por ejemplo, en versiones del programa login de algunos UNIX antiguos, se poda leer parte de /etc/shadow enviando al proceso la seal sigterm y consultando el fichero de volcado. No obstante, este problema no resulta tan grave como otro tambin relacionado con los core dump: cuando un programa SUID vuelca su imagen el fichero resultante tiene el mismo UID que el UID real del proceso. Esto puede permitir a un usuario obtener un fichero con permiso de escritura para todo el mundo pero que pertenezca a otro usuario (por ejemplo, el root): evidentemente esto es muy perjudicial, por lo que parece claro que en un programa SUID necesitamos capturar todas las seales que UNIX nos permita (recordemos que sigkill no puede capturarse ni ignorarse, por norma general). Hay que asegurarse de que las verificaciones realmente verifican: Otra norma a la hora de escribir aplicaciones S UID es la desconfianza de cualquier elemento externo al programa. Hemos de verificar siempre que las entradas (teclado, ficheros. . . ) son correctas, no slo en su formato sino tambin en su origen. Cuidado con las recuperaciones y detecciones de errores:Ante cualquier situacin inesperada y por lo general, poco habitual, incluso forzada por un atacante un programa SUID debe detenerse sin ms; nada de intentar recuperarse del error: detenerse sin ms. Esto, que quizs rompe muchos de los esquemas clsicos sobre programacin robusta, tiene una explicacin sencilla: cuando un programa detecta una situacin inesperada, a menudo el programador asume condiciones sobre el error (o sobre su causa) que no tienen por qu cumplirse, lo que suele desembocar en un problema ms grave que la propia situacin inesperada. Para cada posible problema que un programa encuentre (entradas muy largas, caracteres errneos o de control, formatos de datos errneos. . . ) es necesario que el programador se plantee qu es lo que su cdigo debe hacer, y ante la mnima duda detener el programa. Cuidado con las operaciones de entrada/salida: La entrada/salida entre el proceso y el resto del sistema constituye

otro de los problemas comunes en programas SUID, especialmente a la hora de trabajar con ficheros; las condiciones de carrera aqu son algo demasiado frecuente: el ejemplo clsico se produce cuando un programa SUID ha de escribir en un archivo propiedad del usuario que ejecuta el programa (no de su propietario). En esta situacin lo habitual es que el proceso cree el fichero, realice sobre l un chown() al UID real y al GID real del proceso (es decir, a los identificadores de quin est ejecutando el programa), y posteriormente escriba en el archivo. Pero, qu sucede si el programa se interrumpe tras realizar el open() pero antes de invocar a fchown(), y adems el umask del usuario es 0? El proceso habr dejado un archivo que pertenece al propietario del programa (generalmente el root) y que tiene permiso de escritura para todo el mundo. La forma ms efectiva de solucionar el problema consiste en que el proceso engendre un hijo mediante fork(), hijo que asignar a sus UID efectivo y GID efectivo los valores de su UID real y GID real (los identificadores del usuario que lo ha ejecutado, no de su propietario). El padre podr enviar datos a su hijo mediante pipe(), datos que el hijo escribir en el fichero correspondiente: as el fichero en ningn momento tendr por qu pertenecer al usuario propietario del programa, con lo que evitamos la condicin de carrera expuesta anteriormente. 4.5.4.3.- Utilizacin segura de funciones de biblioteca Sin embargo, un correcto estilo de programacin no siempre es la solucin a los problemas de seguridad del cdigo. Existen llamadas a sistema o funciones de librera que son un clsico a la hora de hablar de bugs en nuestro software. Como norma, tras cualquier llamada se ha de comprobar su valor de retorno y manejar los posibles errores que tenga asociados, con la evidente excepcin de las llamadas que estn diseadas para sobreescribir el espacio de memoria de un proceso (la familia exec() por ejemplo) o las que hacen que el programa finalice (tpicamente, exit()) . Algunas de las llamadas consideradas ms peligrosas (bien porque no realizan las comprobaciones necesarias, bien porque pueden recibir datos del usuario) son las siguientes: system(): Esta es la llamada que cualquier programa SUID debe evitar a toda costa. Si aparece en un cdigo destinado a ejecutarse con privilegios, significa casi con toda certeza un grave problema de seguridad. En algunas ocasiones su peligrosidad es obvia (por ejemplo si leemos datos tecleados por el usuario y a continuacin hacemos un system() de esos datos, ese usuario no tendra ms que teclear /bin/bash para conseguir los privilegios del propietario del programa), pero en otras no lo es tanto.

exec(), popen(): Similares a la anterior; es preferible utilizar execv() o execl(), pero si han de recibir parmetros del usuario sigue siendo necesaria una estricta comprobacin de los mismos. setuid(), setgid(). . . :Los programas de usuario no deberan utilizar estas llamadas, ya que no han de tener privilegios innecesarios. strcpy(), strcat(), sprintf(), vsprintf(). . . : Estas funciones no comprueban la longitud de las cadenas con las que trabajan, por lo que son una gran fuente de buffer overflows. Se han de sustituir por llamadas equivalentes que s realicen comprobacin de lmites (strncpy(), strncat(). . . ) y, si no es posible, realizar dichas comprobaciones manualmente. getenv(): Otra excelente fuente de desbordamientos de buffer; adems, el uso que hagamos de la informacin leda puede ser peligroso, ya que recordemos que es el usuario el que generalmente puede modificar el valor de las variables de entorno. gets(), scanf(), fscanf(), getpass(), realpath(), getopt(). . . : Estas funciones no realizan las comprobaciones adecuadas de los datos introducidos, por lo que pueden desbordar en algunos casos el buffer destino o un buffer esttico interno al sistema. Es preferible el uso de read() o fgets() siempre que sea posible (incluso para leer una contrasea, haciendo por supuesto que no se escriba en pantalla), y si no lo es al menos realizar manualmente comprobaciones de longitud de los datos ledos. gethostbyname(), gethostbyaddr(): Seguramente ver las amenazas que provienen del uso de estas llamadas no es tan inmediato como ver las del resto; generalmente hablamos de desbordamiento de buffers, de comprobaciones de lmites de datos introducidos por el usuario. . . pero no nos paramos a pensar en datos que un atacante no introduce directamente desde teclado o desde un archivo, pero cuyo valor puede forzar incluso desde sistemas que ni siquiera son el nuestro. syslog(): Hemos de tener la precaucin de utilizar una versin de esta funcin de librera que compruebe la longitud de sus argumentos; si no lo hacemos y esa longitud sobrepasa un cierto lmite (generalmente, 1024 bytes) podemos causar un desbordamiento en los buffers de nuestro sistema de log, dejndolo inutilizable. realloc(): Ningn programa privilegiado o no que maneje datos sensibles (por ejemplo, contraseas, correo electrnico. . . y especialmente aplicaciones criptogrficas) debe utilizar esta llamada. realloc() se suele utilizar para aumentar dinmicamente

la cantidad de memoria reservada para un puntero. Lo habitual es que la nueva zona de memoria sea contigua a la que ya estaba reservada, pero si esto no es posible realloc() copia la zona antigua a una nueva ubicacin donde pueda aadirle el espacio especificado. Cul es el problema? La zona de memoria antigua se libera (perdemos el puntero a ella) pero no se pone a cero, con lo que sus contenidos permanecen inalterados hasta que un nuevo proceso reserva esa zona; accediendo a bajo nivel a la memoria (por ejemplo, leyendo /proc/kcore o /dev/kmem) sera posible para un atacante tener acceso a esa informacin. De cualquier forma, si vamos a liberar una zona en la que est almacenada informacin sensible, lo mejor en cualquier caso es ponerla a cero manualmente, por ejemplo mediante bzero() o memset(). open(): El sistema de ficheros puede modificarse durante la ejecucin de un programa de formas que en ocasiones ni siquiera imaginamos; por ejemplo, en UNIX se ha de evitar escribir siguiendo enlaces de archivos inesperados (un archivo que cambia entre una llamada a lstat() para comprobar si existe y una llamada a open() para abrirlo en caso positivo). No obstante, no hay ninguna forma de realizar esta operacin atmicamente sin llegar a mecanismos de entrada/salida de muy bajo nivel.

Bibliografa
A. Ribagorda, A. Calvo, M. Angel Gallardo. Seguridad en UNIX. Sistemas abiertos e Internet. Paraninfo, 1996 S. Garfinkel, G. Spafford Seguridad prctica en UNIX e Internet., 2 edicin Mc Graw Hill, 1999 A. Villaln Huerta Seguridad en UNIX y redes., versin 1.2 Open Publication License, http://www.opencontent.org/openpub/, 2000 A. Silberschatz, P. Galvin

"Sistemas Operativos. Conceptos Fundamentales., 5 edicin Addison-Wesley-Longman, 1999 G. Mourani Securing and Optimizing Linux. RedHat Edition -A Hands on Guide Open Network Architecture http://www.openna.com, 2000 K. Seifried Gua de Seguridad del Administrador de Linux http://segurinet.com/gsal, 1999 L. Wirzenius The Linux System Administrators' Guide, versin 0.6.2 Linux Documentation Project, http://sunsite.unc.edu/LDP/, 1998 W. Tarreau Security under Linux : the Buffer Overflow Problem linux-stack-overflow.tgz

Pedro Gmez Ochoa Jacobo Chamorro