¿QUÉ ES SEGURIDAD?

Podemos entender como seguridad una característica de cualquier sistema (informático o no) que nos indica que ese sistema está libre de todo peligro, daño o riesgo, y que es, en cierta manera, infalible. Como esta característica, particularizando para el caso de sistemas operativos o redes de computadoras, es muy difícil de conseguir (según la mayoría de expertos, imposible), se suaviza la definición de seguridad y se pasa a hablar de fiabilidad (probabilidad de que un sistema se comporte tal y como se espera de él) más que de seguridad; por tanto, se habla de sistemas fiables en lugar de hacerlo de sistemas seguros.

A grandes rasgos se entiende que mantener un sistema seguro (o fiable) consiste básicamente en garantizar tres aspectos: confidencialidad, integridad y disponibilidad. La confidencialidad nos dice que los objetos de un sistema han de ser accedidos únicamente por elementos autorizados a ello, y que esos elementos autorizados no van a convertir esa información en disponible para otras entidades; la integridad significa que los objetos sólo pueden ser modificados por elementos autorizados, y de una manera controlada, y la disponibilidad indica que los objetos del sistema tienen que permanecer accesibles a elementos autorizados; Es el contrario de la negación de servicio.

Algunos estudios integran la seguridad dentro de una propiedad más general de los sistemas, la confiabilidad, entendida como el nivel de calidad del servicio ofrecido.

Dependiendo del entorno en que un sistema UNIX trabaje, a sus responsables les interesará dar prioridad a un cierto aspecto de la seguridad. Por ejemplo, en un sistema militar se antepondrá la confidencialidad de los datos almacenados o transmitidos sobre su disponibilidad: seguramente, es preferible que alguien borre información confidencial (que se podría recuperar después desde una cinta de backup) a que ese mismo atacante pueda leerla, o a que esa información esté disponible en un instante dado para los usuarios autorizados.

¿SEGURIDAD EN UNIX?

En la década de los ochenta para mucha gente el concepto de seguridad era algo inimaginable en el entorno UNIX: la facilidad con que un experto podía acceder a un sistema, burlar todos sus mecanismos de protección y conseguir el máximo nivel de privilegio era algo de sobra conocido por todos, por lo que nadie podía pensar en un sistema UNIX seguro.

En la actualidad UNIX ha añadido numerosas herramientas, aplicaciones, y cualidades; en especial en lo referente a redes: rlogin, rexec, NFS, BOOTPARM, etc., y es aquí donde residen la mayoría de los problemas de seguridad. Convirtiéndose en el primer sistema operativo en alcanzar niveles de seguridad muy altos. En la actualidad se puede considerar el sistema operativo de propósito general más fiable del mercado; desde los clones habituales (Solarios, HP-UX, IRIX.), hasta los "Trusted Unix (Unix seguros), considerados los sistemas operativos más seguros del mundo"), pasando por los sistemas gratuitos (Linux; que requiere una mínima puesta a punto, FreeBSD.). Cualquier entorno Unix puede ofrecer los mecanismos de seguridad suficientes para satisfacer las necesidades de la mayoría de instituciones.

A la hora de configurar una red a nivel lógico (software), casi nunca se tiene en cuenta su seguridad, o al menos todo lo que debería tenerse.

La seguridad de una red no es una tarea fácil, y requiere personal altamente cualificado, con profundos conocimientos sobre el sistema operativo en el que se montará el servidor (o los servidores) y las máquinas cliente.

ELEMENTOS FUNDAMENTALES A PROTEGER

Un sistema Operativo que reúna estos tres aspectos mencionados, debe ser capaz de proteger los tres elementos principales en cualquier sistema informático que son: el software, el hardware y los datos. Por hardware entendemos el conjunto formado por todos los elementos físicos de un sistema informático, como CPUs, terminales, cableado, medios de almacenamiento secundario (cintas, CD-ROMs, diskettes, etc.) o tarjetas de red. Por software entendemos el conjunto de programas lógicos que hacen funcional al hardware, tanto sistemas operativos como aplicaciones, y por datos el conjunto de información lógica que manejan el software y el hardware, como por ejemplo paquetes que circulan por un cable de red o entradas de una base de datos. Aunque generalmente en las auditorias de seguridad se habla de un cuarto elemento a proteger, los fungibles (elementos que se gastan o desgastan con el uso continuo, como papel de impresora, tóners, cintas magnéticas, diskettes.), aquí no consideraremos la seguridad de estos elementos por ser externos al sistema Unix.

Habitualmente los datos constituyen el principal elemento de los tres a proteger, ya que es el más amenazado y seguramente el más difícil de recuperar: con toda seguridad una máquina Unix está ubicada en un lugar de acceso físico restringido, o al menos controlado, y además en caso de pérdida de una aplicación (o un programa de sistema, o el propio núcleo de Unix) este software se puede restaurar sin problemas desde su medio original (por ejemplo, el CD-ROM con el sistema operativo que se utilizó para su instalación). Sin embargo, en caso de pérdida de una base de datos o de un proyecto de un usuario, no tenemos un medio "original" desde el que restaurar: hemos de pasar obligatoriamente por un sistema de copias de seguridad, y a menos que la política de copias sea muy estricta, es difícil devolver los datos al estado en que se encontraban antes de la pérdida.

Tipos de Amenazas

Generalmente, la taxonomía más elemental de estas amenazas las divide en cuatro grandes grupos: interrupción, interceptación, modificación y fabricación. Un ataque se clasifica como interrupción si hace que un objeto del sistema se pierda, quede inutilizable o no disponible. Se tratará de una interceptación si un elemento no autorizado consigue un acceso a un determinado objeto del sistema, y de una modificación si además de conseguir el acceso consigue modificar el objeto; algunos autores consideran un caso especial de la modificación: la destrucción, entendiéndola como una modificación que inutiliza al objeto afectado. Por ultimo, se dice que un ataque es una fabricación si se trata de una modificación destinada a conseguir un objeto similar al atacado de forma que sea difícil distinguir entre el objeto original y el "fabricado".

¿DE QUÉ NOS QUEREMOS PROTEGER?

En seguridad informática en general, y especialmente en las relativas a seguridad en Unix, se intenta clasificar en grupos a los posibles elementos que pueden atacar nuestro sistema. A continuación se presenta una relación de los elementos que potencialmente pueden amenazar a nuestro sistema:

  1. Personas

La mayoría de ataques a nuestro sistema van a provenir en última instancia de personas que, intencionada o inintencionadamente, pueden causarnos enormes pérdidas. Generalmente se tratará de piratas que intentan conseguir el máximo nivel de privilegio posible aprovechando alguno (o algunos) agujeros del software. Pero con demasiada frecuencia se suele olvidar que los piratas "clásicos" no son los únicos que amenazan nuestros equipos.

Aquí se describen brevemente los diferentes tipos de personas que de una u otra forma pueden constituir un riesgo para nuestros sistemas. Generalmente se dividen en dos grandes grupos: los atacantes pasivos, aquellos que fisgonean por el sistema pero no lo modifican -o destruyen-, y los activos, aquellos que dañan el objetivo atacado, o lo modifican en su favor.

Las amenazas a la seguridad de un sistema proveniente del personal de la propia organización rara vez son tomadas en cuenta; se presupone un entorno de confianza donde a veces no existe, por lo que se pasa por alto el hecho de que casi cualquier persona de la organización, incluso el personal ajeno a la infraestructura informática (secretariado, personal de seguridad, personal de limpieza y mantenimiento, etc.) puede comprometer la seguridad de los equipos. Aunque los ataques pueden ser intencionados lo normal es que más que de ataques se trate de accidentes causados por un error o por desconocimiento de las normas básicas de seguridad.

Otro gran grupo de personas potencialmente interesadas en atacar nuestro sistema son los antiguos empleados del mismo, especialmente los que no abandonaron el entorno por voluntad propia (y en el caso de redes de empresas, los que pasaron a la competencia). Personas descontentas con la organización que pueden aprovechar debilidades de un sistema que conocen perfectamente para dañarlo como venganza por algún hecho que no consideran justo

Junto con los crackers, los curiosos son los atacantes más habituales de sistemas Unix en redes de I+D. Aunque en la mayoría de situaciones se trata de ataques no destructivos, parece claro que no benefician en absoluto al entorno de fiabilidad que podamos generar en un determinado sistema.

Los entornos de seguridad media son un objetivo típico de los intrusos, ya sea para fisgonear, para utilizarlas como enlace hacia otras redes o simplemente por diversión. Las redes son generalmente abiertas, y la seguridad no es un factor tenido muy en cuenta en ellas; por otro lado, el gran número y variedad de sistemas Unix conectados a estas redes provoca, que al menos algunos de sus equipos sean vulnerables a problemas conocidos de antemano. De esta forma un atacante sólo ha de utilizar un escáner de seguridad contra el dominio completo y luego atacar mediante un simple exploit los equipos que presentan vulnerabilidades; esto convierte a las redes de I+D, a las de empresas, o a las de ISPs en un objetivo fácil y apetecible para piratas con cualquier nivel de conocimientos.

Por "terroristas" no debemos entender simplemente a los que se dedican a poner bombas o quemar autobuses; bajo esta definición se engloba a cualquier persona que ataca al sistema simplemente por causar algún tipo de daño en él.

Se trata de piratas con gran experiencia en problemas de seguridad y un amplio conocimiento del sistema, que son pagados para robar secretos (el nuevo diseño de un procesador, una base de datos de clientes, información confidencial sobre las posiciones de satélites espía.) o simplemente para dañar la imagen de la entidad afectada.

 

 

  1. Amenazas lógicas

Bajo la etiqueta de "amenazas lógicas’ encontramos todo tipo de programas que de una forma u otra pueden dañar a nuestro sistema, creados de forma intencionada para ello (software malicioso, también conocido como malware) o simplemente por error (bugs o agujeros). Algunas de las amenazas con que nos podemos encontrar son:

Las amenazas más habituales a un sistema Unix provienen de errores cometidos de forma involuntaria por los programadores de sistemas o de aplicaciones.

A estos errores de programación se les denomina bugs, y a los programas utilizados para aprovechar uno de estos fallos y atacar al sistema, exploits. Como hemos dicho, representan la amenaza más común contra Unix, ya que cualquiera puede conseguir un exploit y utilizarlo contra nuestra máquina sin ni siquiera saber cómo funciona y sin unos conocimientos mínimos de Unix; incluso hay exploits que dañan seriamente la integridad de un sistema (negaciones de servicio o incluso acceso root remoto).

Cualquier herramienta de seguridad representa un arma de doble filo: de la misma forma que un administrador las utiliza para detectar y solucionar fallos en sus sistemas o en la subred completa, un potencial intruso las puede utilizar para detectar esos mismos fallos y aprovecharlos para atacar los equipos. Herramientas como nessus, saint o satan pasan de ser útiles a ser peligrosas cuando las utilizan crackers que buscan información sobre las vulnerabilidades de un host o de una red completa.

Durante el desarrollo de aplicaciones grandes o de sistemas operativos es habitual entre los programadores insertar "atajos" en los sistemas habituales de autenticación del programa o del núcleo que se está diseñando. A estos atajos se los denomina puertas traseras, y con ellos se consigue mayor velocidad a la hora de detectar y depurar fallos.

Las bombas lógicas son partes de código de ciertos programas que permanecen sin realizar ninguna función hasta que son activadas; en ese punto, la función que realizan no es la original del programa, sino que generalmente se trata de una acción perjudicial.

Los activadores más comunes de estas bombas lógicas pueden ser la ausencia o presencia de ciertos ficheros, la ejecución bajo un determinado UID o la llegada de una fecha concreta; si las activa el root, o el programa que contiene la bomba está setuidado a su nombre, los efectos obviamente pueden ser fatales.

Los canales cubiertos (o canales ocultos) son canales de comunicación que permiten a un proceso transferir información de forma que viole la política de seguridad del sistema. No constituyen una amenaza demasiado habitual en redes de I+D, sin embargo, es posible su existencia, y en este caso su detección suele ser difícil.

Un virus es una secuencia de código que se inserta en un fichero ejecutable (denominado huésped), de forma que cuando el archivo se ejecuta, el virus también lo hace, insertándose a sí mismo en otros programas.

Aunque los virus existentes para entornos Unix son más una curiosidad que una amenaza real, en sistemas sobre plataformas IBM-PC o compatibles (Linux, FreeBSD, NetBSD, Minix, Solaris.) ciertos virus, especialmente los de boot, pueden tener efectos nocivos, como dañar el sector de arranque.

Un gusano es un programa capaz de ejecutarse y propagarse por sí mismo a través de redes, en ocasiones portando virus o aprovechando bugs de los sistemas a los que conecta para dañarlos. Al ser difíciles de programar su número no es muy elevado, pero el daño que pueden causar es muy grande.

Un gusano puede automatizar y ejecutar en unos segundos todos los pasos que seguiría un atacante humano para acceder a nuestro sistema, pero en un tiempo muchísimo menor. De ahí su enorme peligro y sus devastadores efectos.

Los troyanos o caballos de Troya son instrucciones escondidas en un programa de forma que éste parezca realizar las tareas que un usuario espera de él, pero que realmente ejecute funciones ocultas, es decir que ocultan su función real bajo la apariencia de un programa inofensivo que a primera vista funciona correctamente.

En la práctica totalidad de los ataques a Unix, cuando un intruso consigue el privilegio necesario en el sistema instala troyanos para ocultar su presencia o para asegurarse la entrada en caso de ser descubierto: por ejemplo, es típico utilizar lo que se denomina un rootkit, que no es más que un conjunto de versiones troyanas de ciertas utilidades (netstat, ps, who).

Son los programas que no hacen nada útil, sino que simplemente se dedican a reproducirse hasta que el número de copias acaba con los recursos del sistema (memoria, procesador, disco, etc.), produciendo una negación de servicio.

Por técnica salami se conoce al robo automatizado de pequeñas cantidades de bienes (generalmente dinero) de una gran cantidad origen. El hecho de que la cantidad inicial sea grande y la robada pequeña hace extremadamente difícil su detección.

Las técnicas salami no se suelen utilizar para atacar sistemas normales, sino que su uso más habitual es en sistemas bancarios; sin embargo, en una red con requerimientos de seguridad medios es posible que haya ordenadores dedicados a contabilidad, facturación de un departamento o gestión de nóminas del personal, etc.

    1. Catástrofes

Las catástrofes (naturales o artificiales) son la amenaza menos probable contra los entornos habituales: Como ejemplos de catástrofes hablaremos de terremotos, inundaciones, incendios, humo o atentados de baja magnitud (más comunes de lo que podamos pensar).

¿CÓMO NOS PODEMOS PROTEGER?

Hasta ahora hemos hablado de los aspectos que engloba la seguridad informática, de los elementos a proteger, de los tipos de amenazas que contra ellos se presentan y del origen de tales amenazas; para completar nuestra visión global de la seguridad, nos queda hablar de las formas de protección de nuestros sistemas.

 

 

Figura 1.2: Visión global de la seguridad informática.

 

Para proteger nuestro sistema se deben realizar análisis de las amenazas potenciales que puede sufrir nuestro sistema, las pérdidas que podrían generar, y la probabilidad de su ocurrencia; a partir de este análisis hemos de diseñar una política de seguridad que defina responsabilidades y reglas a seguir para evitar tales amenazas o minimizar sus efectos en caso de que se produzcan.

A los mecanismos utilizados para implementar esta política de seguridad se las denomina mecanismos de seguridad; son la parte más visible de nuestro sistema de seguridad, que garantizan la protección de los sistemas o de la propia red.

Los mecanismos de prevención son aquellos que aumentan la seguridad de un sistema durante el funcionamiento normal de éste, previniendo la ocurrencia de violaciones a la seguridad; por ejemplo, el uso de cifrado en la transmisión de datos se puede considerar un mecanismo de este tipo, ya que evita que un posible atacante escuche las conexiones hacia o desde un sistema Unix en la red. Por mecanismos de detección se conoce a aquellos que se utilizan para detectar violaciones de la seguridad o intentos de violación; ejemplos de estos mecanismos son los programas de auditoria como Tripwire. Finalmente, los mecanismos de recuperación son aquellos que se aplican cuando una violación del sistema se ha detectado, para retornar a éste a su funcionamiento correcto.

Hemos de enfatizar en el uso de mecanismos de prevención y de detección, ya que esto desde ya es mucho más productivo para el sistema, a que tener que restaurar la máquina tras una penetración. Por lo que estos dos mencionados serán los de más interés para nosotros.

Los mecanismos de prevención más habituales en Unix y en redes son los siguientes:

Estos mecanismos hacen posible identificar entidades del sistema de una forma única, y posteriormente, una vez identificadas, autenticarlas (comprobar que la entidad es quién dice ser). Son los mecanismos más importantes en cualquier sistema, ya que forman la base de otros mecanismos que basan su funcionamiento en la identidad de las entidades que acceden a un objeto.

Cualquier objeto del sistema ha de estar protegido mediante mecanismos de control de acceso, que controlan todos los tipos de acceso sobre el objeto por parte de cualquier entidad del sistema. Dentro de Unix, el control de acceso más habitual es el discrecional (DAC, Discretionary Access Control) y las listas de control de acceso para cada fichero (objeto) del sistema; sin embargo, también se permiten especificar controles de acceso obligatorio (MAC).

Cualquier sistema con diferentes niveles de seguridad ha de implementar mecanismos que permitan separar los objetos dentro de cada nivel, evitando el flujo de información entre objetos y entidades de diferentes niveles siempre que no exista una autorización expresa del mecanismo de control de acceso.

Los mecanismos de separación se dividen en cinco grandes grupos, en función de como separan a los objetos: separación física, temporal, lógica, criptográfica y fragmentación. Dentro de Unix, el mecanismo de separación más habitual es el de separación lógica o aislamiento, implementado en algunos sistemas mediante una Base Segura de Cómputo (TCB).

Es especialmente importante para la seguridad de nuestro sistema el proteger la integridad y la privacidad de los datos cuando se transmiten a través de la red. Para garantizar esta seguridad en las comunicaciones, debemos utilizar ciertos mecanismos, la mayoría de los cuales se basan en la Criptografía: cifrado de clave pública, de clave privada, firmas digi-tales, etc. Aunque cada vez se utilizan más los protocolos seguros (como SSH o Kerberos, en el caso de sistemas Unix en red), aún es frecuente encontrar conexiones en texto claro ya no sólo entre máquinas de una misma subred, sino entre redes diferentes.

 

CLASIFICACIÓN DE SISTEMAS

Tenemos en claro que la palabra seguridad implica muchas cosas y que si hablamos de seguridad en sistemas informáticos, en especial en sistemas UNIX, que es el que nos lleva a desarrollar este tema, debemos entender que son varios los aspectos que considerar si queremos encontrarnos con un sistema medianamente seguro o mejor dicho "más fiable".

A continuación y para brindar una visión un poco más cercana a la realidad, que esta muy alejada a la que suponemos, se dará a conocer las diversas ramas que encierra la seguridad:

 

I. SEGURIDAD DEL ENTORNO DE OPERACIONES

La seguridad del entorno de operaciones comprende dos aspectos que generalizan este entorno:

SEGURIDAD FÍSICA DE SISTEMAS

La seguridad física de los sistemas informáticos consiste en la aplicación de barreras físicas y procedimientos de control como medidas de prevención y contramedidas contra las amenazas a los recursos y la información confidencial. Para el caso de equipos Unix y sus centros de operación, por "seguridad física" podemos entender todos aquellas mecanismos – generalmente de prevención y detección – destinados a proteger físicamente cualquier recurso del sistema; estos recursos son desde un simple teclado hasta una cinta de backup con toda la información que hay en el sistema, pasando por la propia CPU de la máquina.

La seguridad física abarca la protección del hardware (del acceso fisico y de desastres naturales o climatológicos) y la protección de los datos.

ADMINISTRADORES, USUARIOS Y PERSONAL

El punto más débil de cualquier sistema informático son las personas relacionadas en mayor o menor medida con él; desde un administrador sin una preparación adecuada o sin la suficiente experiencia, hasta un guardia de seguridad que ni siquiera tiene acceso lógico al sistema, pasando por supuesto por la gran mayoría de usuarios, que no suelen ser conscientes de que la seguridad también les concierne a ellos.

Existen otras amenazas a la seguridad provenientes de ese personal que no son necesariamente ataques en un sentido estricto de la palabra; en muchos casos no son intencionados, sino accidentales, lo cual también implica que se deben prevenir.

Entre algunos de los ataques potenciales que pueden ser causados por estas personas, encontramos:

II. SEGURIDAD DEL SISTEMA

Es un sistema que sin dudas es uno de los más importantes y donde podemos encontrar la base de todo sistema informático y que constituye el elemento fundamental a proteger, nos estamos refiriendo a los datos, ya que seguramente son los más difíciles de recuperar.

Los sistemas que abarcan la administración de los mismos son los siguientes:

SEGURIDAD EN CUENTAS

Este segmento trata de la prevención contra el acceso de un Cracker o alguien ajeno a la empresa, por ej, en un sistema informático colándose en la cuenta de algún otro usuario. Ya que el acceso a las mismas, en algunos casos, es bastante fácil. Debido a que numerosos sistemas tienen todavía cuentas activas de usuarios que ya no están en la compañía, o cuentas con passwords fáciles.

Crack: Es un potente programa adivinador de contraseñas (password ), que permite a cualquier administrador verificar que los passwords de sus usuarios son aceptables (esto es, mínimamente resistentes a un ataque de fuerza bruta), examinando el fichero de contraseñas de cualquier sistema Unix, y utilizando en la mayoría de casos unos diccionarios como patrón.

El sistema contiene componentes visibles para el usuario que son importantes para la seguridad que son los siguientes:

Identificación y autentificación (I&A)

La identificación es el mecanismo mediante el cual, a través de un ID de entrada, el sistema reconoce a un usuario como usuario legítimo para UnixWare. La autentificación es el mecanismo mediante el cual, a través de una contraseña, el sistema verifica la identidad del usuario. Estos mecanismos, juntos, se denominan identificación y autentificación (I&A).

Cuando el sistema identifica y autentifica a un usuario, se revela también cierta información sobre el acceso de dicho usuario a la información, es decir, sus atributos de acceso.

Los mecanismos de I&A evitan que los usuarios no autorizados entren en el sistema y aseguran que los usuarios entran sólo en las áreas para las que están autorizados.

Los sistemas de autenticación se dividen en tres grandes grupos: sistemas basados en algo conocido (una contraseña), sistemas basados en algo poseído (una tarjeta inteligente) y sistemas biométricos (basados en características del individuo, como por ejemplo el trazo de la firma o una huella dactilar).

Sistemas basados en algo conocido

El modelo de autenticación más básico consiste en decidir si un usuario es quien dice ser simplemente basándonos en una prueba de conocimiento que a priori sólo ese usuario puede superar. El mecanismo más común dentro de los de este tipo es la contraseña, que hoy constituye el más común de los sistemas de autenticación debido principalmente al bajo costo que implica, pero desgraciadamente, también es el más vulnerable.

Los programas que ejecutan la I&A basados en algo conocido en son:

Login

En cualquier sistema Unix, todo usuario tiene asociado un nombre de entrada al sistema (login) y una contraseña (password).

El programa Login identifica y autentifica a los usuarios. Pide un nombre de entrada y una contraseña, se encarga de validar éstas y otras entradas introducidas en el indicativo de entrada. Sin embargo, el sistema no reconoce a los usuarios por este nombre de usuario, sino que cada uno tiene asociado un número (el UID, User IDentification) que corresponde con su login. Podremos tener varios usuarios con el mismo UID pero distinto login, y se hace así para poder tener a distintos usuarios con el mismo nivel de privilegios. De esto modo, podremos tener, por ejemplo, a más de un super-usuario en el sistema.

La información sobre entradas está en el archivo /etc/passwd.

La instrucción login comprueba la contraseña introducida, comparándola con las contraseñas codificadas del archivo /etc/shadow

Si se ha introducido un nombre de entrada y una contraseña válidos, login ejecuta el programa especificado en el archivo password

Password

El password es la parte vital de la seguridad de cuentas en los sistemas. Si un cracker es capaz de adivinar el password de un usuario podrá entrar en el sistema con todos los permisos de ese usuario, y una vez allí el sistema queda bajo su control. Si el password obtenido por éste es el de super-usuario (root) el problema es serio del todo.

El programa passwd de UNIX contiene numerosas restricciones a la hora de seleccionar el password.

Esta es una de las tareas de los Administradores de Sistemas. Lo mejor es establecer normas para passwords (ya sea a través de programas comerciales o mediante shell-scripts)

Actualmente hay varios programas destinados a verificar la seguridad de sistemas UNIX. El más conocido es el SATAN.

Sistemas basados en algo poseído

En este tipo de sistemas, lo habitual es usar tarjetas inteligentes, cuya complejidad es muy alta y cuyo rango de aplicación es amplísimo: desde una sencilla tarjeta monedero hasta el acceso a instalaciones militares.

Una tarjeta inteligente es un dispositivo de seguridad del tamaño de una tarjeta de crédito, resistente a la adulteración, con un microprocesador miniaturizado incorporado, que ofrece funciones para un almacenamiento seguro de información. Poseen un chip empotrado en la propia tarjeta que puede implementar un sistema de ficheros cifrado y funciones criptográficas, y además puede detectar activamente intentos no válidos de acceso a la información almacenada.

 

 Sistemas de autenticación biométrica

Estos sistemas son los denominados biométricos, basados en características físicas del usuario a identificar.

El funcionamiento de estos dispositivos es, a grandes rasgos el siguiente: existe un mecanismo que captura una imagen de la característica a analizar (retina, iris, huella dactilar...), de esta imagen se extraen los datos necesarios para la comparación con los de la base de datos, y finalmente, se decide si el usuario es válido o no.

Entre los métodos de autentificación biométrica nos podemos encontrar con varias alternativas posibles. A continuación se nombrarán algunas de las más conocidas:

 

 

 

 Control discrecional de acceso (DAC)

La política de seguridad de UnixWare prescribe una relación entre las reglas de acceso y los atributos de acceso. Los atributos de acceso permiten al sistema definir distintos niveles de autorización y las reglas de acceso ofrecen el mecanismo para que el sistema pueda evitar el acceso no autorizado a la información confidencial.

El acceso a un archivo está determinado por la ruta de acceso absoluta de ese archivo. El núcleo determina si se debe permitir el proceso solicitado por el tipo de acceso (lectura, escritura, ejecución/búsqueda), basándose en los IDs de usuario y de grupo asociados al proceso, los privilegios (si los hay) asociados al proceso, los controles discrecionales (en forma de bits de permiso y, posiblemente, listas de control de acceso (ACLs)) asociados al archivo y a todos los directorios que forman parte de su ruta de acceso absoluta.

El control discrecional de acceso (DAC) se ocupa de controlar el uso compartido de objetos por parte de varios sujetos. DAC es parte del mecanismo "quién puede acceder a qué". Con DAC, el propietario de un objeto puede, si lo desea, conceder permisos de acceso a otros usuarios.

Existen dos mecanismos complementarios de DAC:

Privilegios de procesos

Tener un privilegio significa tener la capacidad de anular controles de acceso para ejecutar una operación delicada del sistema. En las versiones anteriores de UnixWare, había un privilegio comúnmente llamado root o superusuario, que podía anular cualquier restricción y ejecutar servicios delicados. Lo cual aumenta significativa y evidentemente los riesgos de seguridad de este privilegio omnipotente.

Para que el sistema sea seguro, la política de seguridad requiere que este privilegio único de superusuario se subdivida en un conjunto de privilegios conocidos comúnmente como privilegios de procesos. Los privilegios ya no están asociados con IDs de usuario, sino con procesos y archivos ejecutables.

Un proceso que acceda a componentes privilegiados de un sistema operativo requerirá el privilegio correspondiente. De este modo, todo proceso que se ejecute con privilegios se considera parte del sistema operativo, porque el privilegio que tiene le da la autorización para ejecutar alguna acción delicada.

La división de la capacidad para ejecutar ciertas tareas privilegiadas es necesaria para aplicar el principio de mínimo privilegio que requiere la política de seguridad. Según este principio, un proceso no debe tener nunca más privilegios de los necesarios para ejecutarlo en un momento dado.

SISTEMAS DE FICHEROS

En Unix, todos los dispositivos del sistema son ficheros o archivos, desde la memoria física hasta una unidad Zip, pasando por el módem, ratón, teclado o terminales. Este enfoque es uno de los más potentes, pero también es uno de los más peligrosos, ya que un error en un permiso podría permitir a un atacante borrar todo el disco duro de una máquina o leer los datos que alguien escribe en un terminal. Por esto, una correcta utilización de los permisos, atributos y otros controles sobre los ficheros es vital para la seguridad de un sistema.

En un sistema Unix típico existen tres tipos básicos de archivos: ficheros planos, directorios, y ficheros especiales (dispositivos); generalmente, al hablar de ficheros nos solemos referir a todos ellos si no se especifica lo contrario.

Los 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. Los directorios son archivos cuyo contenido son otros ficheros de cualquier tipo (planos, más directorios, o ficheros especiales), y los ficheros especiales son ficheros que representan dispositivos del sistema.

Cada sistema Unix tiene su sistema de archivos nativo( interfaz única de almacenamiento, que es la parte más visible del núcleo), por lo que para acceder a todos ellos de la misma forma el núcleo de Unix incorpora una capa superior denominada VFS (Virtual File System) encargada de proporcionar un acceso uniforme a diferentes tipos de sistema de ficheros.

Permisos de un archivo

Los permisos de cada fichero son la protección más básica de estos objetos del sistema operativo; definen quién puede acceder a cada uno de ellos, y de qué forma puede hacerlo. Cuando hacemos un listado largo de ciertos archivos podemos ver sus permisos junto al tipo de fichero correspondiente.

 

 

-rwxr--r-- root sys 2689 Dec 1 1998 /sbin/rc0

anita:~#

En este caso vemos que el archivo listado es un fichero plano (el primer carácter es un `-') y sus permisos son `rwxr--r--`. ¿Cómo se interpretan estos caracteres?. Los permisos se dividen en tres ternas en función de a que usuarios afectan; cada una de ellas indica la existencia o la ausencia de permiso para leer, escribir o ejecutar el fichero: una r indica un permiso de lectura, una w de escritura, una x de ejecución y un `-' indica que el permiso correspondiente no esta activado. Así, si en una de las ternas tenemos los caracteres rwx, el usuario o usuarios afectados por esa terna tiene o tienen permisos para realizar cualquier operación sobre el fichero. ¿De que usuarios se trata en cada caso? La primera terna afecta al propietario del fichero, la segunda al grupo del propietario cuando lo creó (recordemos un mismo usuario puede pertenecer a varios grupos) y la tercera al resto de usuarios. De esta forma, volviendo al ejemplo anterior, tenemos los permisos mostrados en la figura 4.1.

Cuando un usuario (excepto el root) intenta acceder en algún modo a un archivo, el sistema comprueba qué terna de permisos es la aplicable y se basa únicamente en ella para conceder o denegar el acceso; así, si un usuario es el propietario del fichero solo se comprueban permisos de la primera terna; si no, se pasa a la segunda y se aplica en caso de que los grupos coincidan, y de no ser así se aplican los permisos de la última terna.

Permisos en los ficheros: los bits SUID, SGID y sticky

Los permisos en ficheros son la protección más básica que podemos tener en un sistema Unix. Los bits SUID (4000), SGID (2000) y de permanencia o sticky (1000) son unos bits especiales y de los cuales casi nadie conoce.

Bit SUID o setuid. Este bit se activa añadiéndole 4000 a la representación octal de los permisos del fichero y dándole además permiso de ejecución al propietario del mismo. Este bit indica que todo aquél que ejecute el fichero va a tener durante su ejecución los privilegios de quien lo creó. El problema que tiene esto es el de los errores en los buffer overflows. Si algún programa o shellscript setuidado tiene algún error grave, se le presente al usuario una shell de root. De hecho, se considera una amenaza contra la seguridad del sistema y se aconseja desactivar este bit cuanto antes.

Bit SGID o setgid. Se activa sumando 2000 a los permisos del fichero o directorio y dándole permiso de ejecución al grupo. Todo lo explicado para el bit SUID es válido para el SGID pero trasladándolo a nivel del grupo, en vez de a nivel del propietario. Es decir, en vez de trabajar con el UID del usuario que creó el fichero, se trabajará con los privilegios del grupo al que pertenece el fichero.

Bit de permanencia o sticky. Se activa sumándole 1000 a la representación octal de los permisos del fichero o directorio y otorgándole permiso de ejecución. Cualquier usuario puede activar este bit y con su activación se consigue un doble efecto:

Atributos de un archivo

En este sistema operativo y concretamente en su sistema de archivos, ext2 (Second Extended File System), existen unos bits especiales e inexistentes en otros sistemas Unix (LINUX)para proteger aún más los ficheros. Algunos con los que nos podemos encontrar son:

Listas de control de acceso: ACLs

Las listas de control de acceso (ACLs, Access Control Lists) proveen de un nivel adicional de seguridad a los ficheros extendiendo el clásico esquema de permisos en Unix: las ACLs van a permitir asignar permisos a usuarios o grupos concretos; por ejemplo, se pueden otorgar ciertos permisos a dos usuarios sobre unos ficheros sin necesidad de incluirlos en el mismo grupo. Este mecanismo está disponible en la mayoría de Unices (Solaris, AIX, HP-UX, etc.), mientras que en otros que no lo proporcionan por defecto, como Linux, puede instalarse como un software adicional.

El concepto de ACL permite un control más preciso que los permisos del archivo por sí solos, al dar al propietario de un objeto la capacidad de conceder o denegar accesos con un nivel de precisión de usuario por usuario.

Las ACLs de UnixWare también permiten especificar los derechos de acceso para los miembros de grupos definidos en el sistema en el archivo administrativo /etc/group. El administrador del sistema puede determinar el número máximo de entradas por ACL, configurando un parámetro regulable.

Almacenamiento seguro

Ø La orden crypt(1): permite cifrar y descifrar ficheros en diferentes sistemas Unix;

Ø PGP (Pretty Good Privacy): El software PGP, permite el cifrado de archivos de forma convencional mediante criptografía simétrica; convirtiendo a este programa en una excelente herramienta para cifrar archivos que almacenamos en nuestro sistema;

Ø TCFS (Transparent Cryptographic File System): es un software que proporciona una solución al problema de la privacidad en sistemas de ficheros distribuidos. TCFS almacena los ficheros cifrados, y son pasados a texto claro antes de ser leídos; todo el proceso se realiza en la máquina cliente, por lo que las claves nunca son enviadas a través de la red.

Otros métodos de almacenamiento seguro

Ø sistema CFS (Cryptographic File System): Provee de servicios de cifrado a cualquier sistema de ficheros habitual en Unix.

Ø SFS (Secure File System). El SFS de Unix funciona de una forma similar a CFS pero utilizando el criptosistema Blowfish.

Criptografía

La criptografía es la herramienta principal utilizada en la mayoría de los sistemas de almacenamiento seguro; sin embargo, todos ellos plantean un grave problema: toda su seguridad reside en la clave de cifrado, de forma que el usuario se encuentra indefenso ante métodos legales - o ilegales - que le puedan obligar a develar esta clave una vez que se ha determinado la presencia de información cifrada en un dispositivo de almacenamiento.

PROGRAMAS SEGUROS, INSEGUROS Y NOCIVOS

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 protección básica: la prevención.

Errores en los programas

Los errores o bugs a la hora de programar código de aplicaciones o del propio núcleo de Uníx constituyen una de las amenazas a la seguridad informática. En la mayoría de situaciones no se trata de desconocimiento a la hora de realizar programas seguros, sino del hecho que es prácticamente imposible no equivocarse en miles de líneas de código: simplemente el núcleo de Minix, un mini-Unix diseñado por Andrew Tanenbaum con fines docentes, tiene mas de 13000 líneas de código en su versión 1.0.

Ø Buffer overflows: Seguramente uno de los errores más comunes, y sin duda el más conocido y utilizado es el stack smashing o desbordamiento de pila, también conocido por buffer overflow.

Ø Condiciones de carrera: Otro error muy conocido en el mundo de los sistemas operativos son las condiciones de carrera, situaciones en las que dos o más procesos leen o escriben en un área compartida y el resultado final depende de los instantes de ejecución de cada uno. Cuando una situación de este tipo se produce y acciones que deberían ser automáticas no lo son, existe un intervalo de tiempo durante el que un atacante puede obtener privilegios, leer y escribir ficheros protegidos, y en definitiva violar las políticas de seguridad del sistema.

Fauna y otras amenazas

No todas las amenazas lógicas provienen de simples errores: ciertos programas, denomi-nados en su conjunto malware o software malicioso, son creados con la intención principal de atacar a la seguridad. En esta sección vamos a nombrar algunos tipos de malware, ya que sus características y efectos potenciales fueron descriptos con anterioridad.

Podemos encontrarnos con Virus, Gusanos, Conejos, Caballos de Trolla, Bombas lógicas, Puertas traseras, Applets hostiles, Superzapping y Programas salami entro otros.

Programación segura

Parece obvio que después de analizar los problemas que un código malicioso o simplemente mal diseñado puede causar, dediquemos un apartado a comentar brevemente algunos aspectos a tener en cuenta a la hora de crear programas seguros. Vamos a hablar de programación en C, por ser el lenguaje más utilizado en Unix;

Para la codificación segura de este tipo de programas, proporciona unas líneas básicas:

Ø Máximas restricciones a la hora de elegir el UID y el GID.

Ø Reset de los UIDs y GIDs efectivos antes de llamar a exec().

Ø Es necesario cerrar todos los descriptores de fichero, excepto los estrictamente necesarios, antes de llamar a exec().

Ø Hay que asegurarse de que chroot() realmente restringe.

Ø Comprobaciones del entorno en que se ejecutará el programa.

Ø Nunca setuidar shellscripts.

Ø No utilizar creat() para bloquear.

Ø Capturar todas las señales.

Ø Hay que asegurarse de que las verificaciones realmente verifican.

Ø Cuidado con las recuperaciones y detecciones de errores.

Ø Cuidado con las operaciones de entrada/salida.

 

 

III. EL SISTEMA DE RED

Por sistema de red de un equipo Unix se entiende el conjunto de software que posibilita la interconexión entre diferentes máquinas. Este software está dividido en dos espacios: por un lado, tenemos el soporte de red dentro del kernel del sistema operativo, encargado de implementar las tareas de más bajo nivel necesarias para la comunicación entre sistemas, como la pila de protocolos tcp/ip o los controladores de tarjetas de red; por otro, ya en el espacio de usuario, tenemos el conjunto de programas y ficheros utilizados para configurar parámetros del sistema relacionados con la red, como la dirección IP, las tablas de rutado, o el comportamiento de una máquina ante solicitudes de servicio desde otros equipos conectados lógicamente a ella.

A continuación se brindará una muy pequeña introducción a una parte del sistema de red de UNIX, sin entrar en ningún detalle; para temas más concretos, como la configuración del soporte de red en núcleo, la configuración de interfaces de red, servicios de nombres o la configuración de las tablas de rutado.

Algunos ficheros importantes

El fichero /etc/hosts

Este fichero se utiliza para obtener una relación entre un nombre de máquina y una dirección ip: en cada línea de /etc/hosts se especifica una dirección ip y los nombres de máquina que le correspondan, de forma que un usuario no tenga que recordar direcciones sino nombres de hosts.

Habitualmente se suelen incluir las direcciones, nombres y aliases de todos los equipos conectados a la red local, de forma que para comunicación dentro de la red no se tenga que recurrir a DNS a la hora de resolver un nombre de máquina.

Hosts Fiables

Uno de los conceptos mas potentes del software de red que implementa UNIX es el de "host fiable" (o "trusted hosts"). Permite que aquellos sistemas que se consideren como "fiables" (incluso sus usuarios) puedan entrar en la máquina sin necesidad de autentificación por password (utilizando los comandos "r", como rlogin, rsh, etc). Puede ser muy conveniente para un departamento de una empresa o algo similar, en donde los usuarios se conocen, son del mismo equipo de trabajo pero están alejados físicamente.

El fichero hosts.equiv

El fichero /etc/hosts.equiv es utilizado para indicar aquellos sistemas fiables. Cada uno de estos sistemas es listado en el fichero, de forma que cada host se pone en una línea. Si un usuario intenta lanzar un comando "r" para entrar en el sistema (mediante rlogin) o ejecuta un comando remoto (mediante rsh), y ese usuario se encuentra en una de las máquinas listadas en el /etc/hosts.equiv, se le concederá el acceso sin necesidad de password. Por tanto, siempre habrá que tener mucho cuidado con este fichero, y las máquinas que se introducen en él. Lo mejor es aislar por SubRedes y habilitar acceso a una red interna que cuelgue de la nuestra.

El fichero .rhosts

El fichero .rhosts es similar, en concepto, al /etc/hosts.equiv. Su diferencia estriba en que el .rhosts solo permite acceso a usuarios determinados (considerados fiables) en lugar de permitir acceso a máquinas totales. Evidentemente esto es un problema: el /etc/hosts.equiv es cosa del Administrador del Sistema, mientras que el .rhosts está al alcance de cualquier usuario.

El archivo /etc/ethers

En este fichero se establece una correspondencia entre nombres de máquina y direcciones ethernet, en un formato muy similar al fichero /etc/hosts.

El fichero /etc/networks

Este fichero, cada vez más en desuso, permite asignar un nombre simbólico a las redes, de una forma similar a lo que /etc/hosts. En cada línea del fichero se especifica un nombre de red, su dirección, y sus aliases.

El fichero /etc/services

En cada línea de este fichero se especifican el nombre, número de puerto, protocolo utilizado y aliases de todos los servicios de red existentes. Es utilizado por los servidores y por los clientes para obtener el número de puerto en el que deben escuchar o al que deben enviar peticiones, de forma que se pueda cambiar un número de puerto sin afectar a las aplicacio-nes. Por ejemplo, para especificar que el servicio de smtp utilizará el puerto 25, el protocolo tcp y que un alias para él es mail, existirá una línea similar a la siguiente:

smtp 25/tcp mail

luisa:~# telnet anita 25

Trying 195.195.5.3...

Connected to anita.

Escape character is '^]'.

El fichero /etc/protocols

El sistema de red en Unix utiliza un número de protocolo, para identificar el protocolo de transporte específico que la máquina recibe; esto permite al software de red decodificar correctamente la información recibida. En el archivo /etc/protocols se identifican todos los protocolos de transporte reconocidos junto a su número de protocolo y sus aliases:

luisa:~# cat /etc/protocols

ip 0 IP # internet protocol, pseudo protocol number

icmp 1 ICMP # internet control message protocol

igmp 2 IGMP # internet group multicast protocol

ggp 3 GGP # gateway-gateway protocol

tcp 6 TCP # transmission control protocol

pup 12 PUP # PARC universal packet protocol

udp 17 UDP # user datagram protocol

idp 22 IDP # WhatsThis?

raw 255 RAW # RAW IP interface

luisa:~#

No es usual – ni recomendable – que el administrador modifique este fichero; es el software de red el que lo va actualizando al ser instalado en la máquina.

El fichero /etc/hosts.equiv

En este fichero se indican, una en cada línea, las máquinas confiables. Es decir aquella en la que confiamos tanto en su seguridad como en la nuestra, por lo que para facilitar la compar-tición de recursos, no se van a pedir contraseñas a los usuarios que quieran conectar desde estas máquinas con el mismo login, utilizando las órdenes bsd r* (rlogin, rsh, rcp, etc.). Por ejemplo, si en el fichero /etc/hosts.equiv del servidor maquina1 hay una entrada para el nombre de host maquina2, cualquier usuario 1 de este sistema puede ejecutar una orden como para conectar a maquina1 ¡sin necesidad de ninguna clave!.

Por ej.:

maquina2:~$ rlogin maquina1

Last login: Sun Oct 31 08:27:54 from localhost

Sun Microsystems Inc. SunOS 5.7 Generic October 1998

maquina1:~$

Obviamente, esto supone un gran problema de seguridad, por lo que lo más recomendable es que el fichero /etc/hosts.equiv esté vacío o no exista. De la misma forma, los usuarios pue-den crear ficheros $HOME/.rhosts para establecer un mecanismo de confiabilidad bastante similar al de /etc/hosts.equiv; es importante para la seguridad de nuestro sistema controlar la existencia y el contenido de estos archivos .rhosts.

El fichero .netrc

El mecanismo /etc/hosts.equiv de autenticación sólo funciona con las órdenes r* de Unix bsd; la conexión vía ftp seguirá solicitando un nombre de usuario y una clave para acceder a sistemas remotos. Una forma de automatizar ftp para que no solicite estos datos, es mediante el uso de un archivo situado en el directorio $HOME de cada usuario (en la máquina desde donde se invoca a ftp, no en el servidor) y llamado .netrc. En el que se especifica, en texto claro, nombres de máquina, nombres de usuario y contraseñas de sistemas remotos.

Si este archivo existe, cuando conecte al sistema remoto no se le solicitará ningún nombre de usuario ni contraseña. Lo que puede acarrear graves problemas de seguridad, ya que si un atacante consigue leer nuestro fichero .netrc, automáticamente obtiene nuestro nombre de usuario y nuestra clave en un sistema remoto. Por lo tanto, para que el mecanismo funcione correctamente, este fichero sólo puede ser leído por su propietario; si no es así, no se permitirá el acceso al sistema remoto (aunque los datos de .netrc sean correctos).

Existe una diferencia abismal entre el uso de .rhosts y el de .netrc; en el primer caso se consigue que nuestra clave no se envíe a través de la red, pero mediante .netrc lo único que conseguimos es no tener que teclear la clave y el login explícitamente: se envían de forma automática.

El fichero /etc/inetd.conf

Este fichero es el utilizado por el demonio inetd, conocido como el superservidor de red. El demonio inetd es el encargado de ofrecer la mayoría de servicios de nuestro equipo hacia el resto de máquinas, y por tanto debemos cuidar mucho su correcta configuración.

Cada línea del archivo /etc/inetd.conf le indica a inetd cómo se ha de comportar cuando recibe una petición en cierto puerto y el significado es el siguiente:

Si se trata de servicios RPC, de nuevo hay que indicarlo utilizando rpc antes del nombre del protocolo, separado de él por el carácter "/".

Algunas órdenes importantes

La orden ifconfig

La orden ifconfig se utiliza para configurar correctamente las interfaces de red de nuestro sistema Unix; habitualmente con ifconfig se indican parámetros como la dirección ip de la máquina, la máscara de la red local o la dirección de broadcast.

Podemos utilizar ifconfig para detectar un funcionamiento anórmal de la tarjeta de red; el cual suele ser la causa de uno de los tres siguientes problemas:

La orden route

Este comando se utiliza para configurar las tablas de rutado del núcleo de nuestro sistema. Generalmente en todo equipo de una red local tenemos al menos tres rutas: la de loopback, utilizando un dispositivo de bucle interno, la de red local (localnet), que utiliza la tarjeta de red para comunicarse con equipos dentro del mismo segmento de red, y una default que también utiliza la tarjeta para enviar a un router o gateway paquetes que no son para equipos de nuestro segmento. Si no se especifica ningún parámetro, route muestra la configuración actual de las tablas de rutado.

La orden netstat

Esta orden se utiliza para visualizar el estado de diversas estructuras de datos del sistema de red, desde las tablas de rutado hasta el estado de todas las conexiones a y desde nuestra máquina, pasando por las tablas arp, en función de los parámetros que reciba.

En temas referentes a la seguridad, netstat se suele utilizar además, para mostrar los puertos abiertos que escuchan peticiones de red y para visualizar conexiones a nuestro equipo (o desde él) que puedan salirse de lo habitual.

Cualquiera puede conectar a este servicio y, si no lo evitamos mediante TCP Wrappers, utilizarlo para enviarle peticiones.

La orden ping

El comando ping se utiliza generalmente para testear aspectos de la red, como comprobar que un sistema está encendido y conectado; esto se consigue enviando a dicha máquina paquetes icmp (de tipo echo request), tramas que causarán que el núcleo del sistema remoto responda con paquetes icmp, pero esta vez de tipo echo response. Al recibirlos, se asume que la máquina está encendida. Esto es para sistemas como SOLARIS

Aunque un simple ping resulta inofensivo en la mayoría de situaciones, existen casos en los que se puede utilizar como un arma – efectiva – para atacar sistemas; por ejemplo, uno de los ataques más conocidos es el Ping Flood, consistente en saturar una línea lenta con un número de paquetes icmp suficientemente grande. Esta saturación causará una degradación del servicio importante, incluso la desconexión del sistema si se ataca una línea telefónica (un objetivo muy habitual para los piratas).

La orden traceroute

Esta orden se utiliza para imprimir la ruta que los paquetes siguen desde nuestro sistema hasta otra máquina; para ello utiliza el campo ttl (Time To Live) del protocolo ip La idea es que cada vez que un paquete pase por un router o una pasarela, esta se encarga de decrementar el campo ttl en una unidad; en el caso de que se alcance un valor 0, se devuelve un paquete time exceeded y se descarta la trama. Así, traceroute inicializa a 1 este campo, lo que ocasiona que el primer router encontrado ya devuelva el mensaje de error; al recibirlo, lo inicializa a 2, y ahora es el segundo router el que descarta el paquete y envía otro mensaje de error, y así sucesivamente. De esta forma se va construyendo la ruta hasta un determinado host remoto.

Traceroute se utiliza para realizar pruebas, medidas y administración de una red; introduce mucha sobrecarga, lo que evidentemente puede acarrear problemas de rendimiento, llegando incluso a negaciones de servicio por el elevado tiempo de respuesta que el resto de aplicaciones de red pueden presentar. Además, se trata de un programa contenido en un fichero setuidado, por lo que es interesante resetear el bit de setuid de forma que sólo el root pueda ejecutar la orden: es de pensar que un usuario normal rara vez tiene que realizar pruebas sobre la red, por lo que el bit setuid de traceroute no es más que un posible problema para nuestra seguridad.

Algunos servicios y protocolos

En este segmento vamos a hablar de la seguridad (e inseguridad) de algunos de los protocolos, servicios y programas que los implementan en los entornos Unix. Podemos ver los diferentes servicios que un sistema Unix ofrece como potenciales puertas de entrada al mismo.

Servicios básicos de red

Dentro de este apartado vamos a comentar brevemente la función de algunos servicios de Unix y sus potenciales problemas de seguridad. Los que exponemos a continuación son servicios que habitualmente han de estar cerrados, por lo que no implican excesivos problemas de seguridad conocidos.

Systat

El servicio systat se asocia al puerto 11 de una máquina Unix, para recibir peticiones mediante tcp el demonio inetd ofrece una imagen de la tabla de procesos del sistema.

Si se ofrece la tabla de procesos o bien otro tipo de información sobre el sistema, este servi-cio es habitual encontrarlo deshabilitado, ya que cualquier dato sobre nuestro sistema puede ser aprovechado por un pirata para atacar el equipo. Si por motivos de comodidad a la hora de administrar varios hosts dentro de una red local necesitamos tener abierto systat, debemos restringir las direcciones desde las que se puede acceder al servicio mediante TCP Wrappers.

Daytime

El servicio daytime, asociado al puerto 13, tanto tcp como udp, es un servicio interno de inetd que al recibir una conexión a este puerto, el sistema mostrará la fecha y la hora, en un formato muy similar al resultado de la orden date. Suele ser recomendable cerrarlo, para mayor seguridad y para evitarnos inconvenientes con intrusos.

Un servicio parecido en muchos aspectos a daytime es time (puerto 37, tcp y udp); también indica la fecha y hora del equipo, pero esta vez en un formato que no es inteligible para las personas.

Netstat

De la misma forma que systat ofrecía información sobre el estado de nuestro sistema, netstat la ofrece sobre el estado de nuestra red. Este servicio muestra principalmente las conexiones activas en la máquina.

También es recomendable deshabilitar este servicio comentando la línea correspondiente de /etc/inetd.conf, o en todo caso restringir el acceso al mismo a máquinas de nuestra red local, mediante TCP Wrappers. Si no se hace esto puede ser perjudicial, ya que le permite a un atacante conocer los nombres de hosts y además le permite hacerse una idea del tráfico que soporta la máquina, de los servicios que ofrece, de los hábitos de conexión de los usuarios, etc.

Chargen

Es un generador de caracteres servido internamente por inetd, que se utiliza sobre todo para comprobar el estado de las conexiones en la red; cuando alguien accede a este servicio simplemente ve en su terminal una secuencia de caracteres ASCII que se repite indefini-damente. Lo que lo hace incomprensible para usuarios comunes.

Los posibles problemas de seguridad relacionados con chargen suelen ser negaciones de servicio, tanto para la parte cliente como para la servidora.

TFTP

TFTP (Trivial File Transfer Protocol) es un protocolo de transferencia de ficheros que en general no proporciona ninguna seguridad. Por lo tanto es obligatorio que este servicio esté desactivado; su uso principal es el arranque de estaciones diskless o de routers a través de la red, ya que la simpleza del protocolo permite implementarlo en un chip, y sólo en ese caso nos veremos obligados a ofrecer el servicio. Si es este el caso, los ficheros que deseemos que sean públicos se han de situar en un determinado directorio (dependiendo del clon de Unix) o utilizar otros nombres de directorio como argumentos del demonio en /etc/inetd.conf, algo no recomendable.

Finger

Típicamente el servicio finger (puerto 79, tcp) ha sido una de las principales fuentes de problemas de Unix. Este protocolo proporciona información – demasiado detallada – de los usuarios de una máquina, estén o no conectados en el momento de acceder al servicio; para hacerlo, se utiliza la aplicación finger desde un cliente, dándole como argumento un nombre de máquina precedido del símbolo "@" o "0"y, opcionalmente, de un nombre de usuario. En el primer caso, finger nos dará datos generales de los usuarios conectados en ese momento a la máquina, y en el segundo nos informará con más detalle del usuario especificado como parámetro, esté o no conectado:

anita:~# finger @rosita

[rosita]

Login Name Tty Idle Login Time Office Office Phone

toni Toni at ROSITA */0 28 Apr 20 04:43 (anita)

root El Spiritu Santo 1 12 Apr 11 02:10

anita:~# finger toni@rosita

[rosita]

Login: toni Name: Toni at ROSITA

Directory: /home/toni Shell: /bin/bash

On since Thu Apr 20 04:43 (CEST) on pts/0 from anita

30 minutes 28 seconds idle

(messages off)

No mail.

No Plan.

anita:~#

Como podemos ver, finger está proporcionando mucha información que podría ser de utilidad para un atacante. Está claro que esto es fácilmente aprovechable por un pirata para practicar ingeniería social contra nuestros usuarios – o contra el propio administrador –. Es básico para la integridad de nuestras máquinas deshabilitar este servicio, restringir su acceso a unos cuantos equipos de la red local mediante TCP Wrappers o utilizar versiones del demonio fingerd como ph (Phone Book), que permiten especificar la información que se muestra al acceder al servicio desde cada máquina.

POP

El servicio pop (Post Office Protocol, puertos 109 y 110 en tcp) se utiliza para que los usuarios puedan acceder a su correo sin necesidad de montar sistemas de ficheros compartidos mediante nfs: los clientes utilizan smtp para enviar correo y pop para recogerlo del servidor, de forma que el procesamiento se realice en la máquina del usuario. Se trata de un servicio que podríamos considerar peligroso, por lo que – como el resto, pero este especialmente – debemos deshabilitarlo a no ser que sea estrictamente necesario ofrecerlo; en ese caso debemos restringir al máximo los lugares desde los que se puede acceder, mediante TCP Wrappers.

En algunos sistemas se utiliza pop simplemente para evitar otorgar cuentas completas a los usuarios: si sólo van a utilizar la máquina para leer su correo, en algunos demonios de pop han surgido bugs que incluso otorgaban un privilegio de root remoto sin necesidad de ninguna clave, estamos generando un tránsito peligroso de contraseñas a través de la red. POP ofrece tres modelos distintos de autenticación: uno basado en Kerberos, apenas utilizado, otro basado en un protocolo desafío–respuesta (apop, que tampoco se suele utilizar), y otro basado en un simple nombre de usuario con su password correspondiente. Este ´ ultimo, el más usado en todo tipo de entornos, es un excelente objetivo para un pirata con un sniffer.

Auth

Se llama socket a la combinación de una dirección de máquina y un puerto; esta entidad identifica un proceso único en la red. Un par de sockets, uno en la máquina receptora y otro en la emisora definen una conexión en protocolos como tcp; esta conexión también será única en la red en un instante dado. Como vemos, no entra en juego ningún nombre de usuario: en tcp/ip se establecen canales de comunicación entre máquinas, no entre personas.

El protocolo auth (puerto 113, tcp) viene a solucionar este problema con un esquema muy simple: cuando un servidor necesita determinar el usuario que ha iniciado una conexión contacta con el demonio identd y le envía los datos necesarios para distinguir dicha conexión (los componentes de los dos sockets que intervienen) de las demás. De esta forma, el demonio identifica al usuario en cuestión y devuelve al servidor información sobre dicho usuario, generalmente su login.

NTP

El servicio NNTP (Network News Transfer Protocol, puerto 119 tcp) se utiliza para intercambiar mensajes de grupos de noticias entre servidores de news. Los diferentes demonios encargados de esta tarea (como in.nntpd o innd) suelen discriminar conexiones en función de la dirección o el nombre de la máquina cliente; por ejemplo, el primero utiliza el fichero nntp access para decidir si ofrece el servicio de news a un determinado host, y si es así concretar de que forma puede acceder a el (sólo lectura, sólo ciertos grupos. . . ). De esta forma, los servidores nntp son muy vulnerables a cualquier ataque que permita falsear la identidad de la máquina origen, como el IP Spoofing.

Los problemas relacionados con las news no suelen ser excesivamente graves desde un punto de vista estrictamente técnico. Por ejemplo, habría que evaluar el daño que le supone a la imagen de nuestra organización el que un atacante envíe mensajes insultantes o pornográficos utilizando nuestro nombre o nuestros recursos. También es un problema la mala educación de los usuarios en materias de seguridad informática: tienden a creer todo lo que leen en ciertos grupos de noticias, por lo que un atacante podría utilizar ingeniería social para perjudicar a nuestra organización. Otra amenaza común es el uso de grupos de news privados (internos) para tratar información confidencial en la organización.

NTP

NTP (Network Time Protocol, puerto 123 udp y tcp) es un protocolo utilizado para sincronizar relojes de máquinas de una forma muy precisa; a pesar de su sofisticación no fue diseñado con una idea de robustez ante ataques, por lo que puede convertirse en una gran fuente de problemas si no está correctamente configurado.

Son muchos los problemas de seguridad relacionados con un tiempo correcto; el más simple y obvio es la poca fiabilidad que ofrecerá nuestro sistema de log a la hora de determinar cuando sucedió o determinado evento. Otro problema típico radica en las facilidades que ofrece Unix para la planificación de tareas: si el reloj tiene problemas, es posible que ciertas tareas no se lleguen a ejecutar, que se ejecuten varias veces, o que se ejecuten cuando no han de hacerlo; esto es especialmente peligroso para tareas de las que depende nuestra seguridad, como la rotación de logs. Si hablamos de problemas más sofisticados, podemos pensar en sistemas distribuidos, en los que una correcta sincronización entre nodos es básica para garantizar el correcto funcionamiento del sistema global.

Como hemos visto, una correcta sincronización del reloj de nuestro equipo es vital para la seguridad.

UUCP

UUCP (Unix to Unix CoPy, puerto 540 tcp) es un servicio que, como su nombre indica, se utiliza para copiar ficheros entre máquinas Unix, generalmente a través de líneas telefónicas o redes de baja velocidad; aunque hoy en día apenas se utiliza, durante años ha sido la base de los sistemas de correo electrónico y de news.

Dos riesgos fundamentales amenazan a uucp: al tratarse de una transmisión en texto claro, un potencial atacante puede tener acceso a información privada de los usuarios, vulnerando su privacidad.

El segundo riesgo es incluso más preocupante que la pérdida de privacidad: las contraseñas de los usuarios también se transmiten en texto claro, con el consiguiente peligro que supone

la interceptación por parte de un pirata de dichas claves.

Como siempre, y dado que como hemos dicho uucp no se suele utilizar hoy en día, lo más recomendable es deshabilitar este servicio.

Una medida de protección básica es asignar un login y password diferente para cada sistema que conecte con el nuestro mediante este método.

El servicio FTP

FTP (File Transfer Protocol, puerto 21 tcp) es, como su nombre indica, un protocolo de transferencia de ficheros entre sistemas.

Un problema básico y grave de ftp es que está pensado para ofrecer la máxima velocidad en la conexión, pero ni mucho menos para ofrecer la máxima seguridad; todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier fichero, se realiza en texto claro, con lo que un atacante lo tiene muy fácil para capturar todo ese trafico y conseguir así un acceso válido al servidor. Incluso puede ser una amenaza a la privacidad de nuestros datos el hecho de que ese atacante también pueda capturar y reproducir los ficheros transferidos. Para solucionar este problema es conveniente concientizar a nuestros usuarios de la utilidad de aplicaciones como scp y sftp, que permiten transferir ficheros pero cifrando todo el tráfico; de esta forma, son el mejor sustituto de ftp.

FTP anónimo: Una de las numerosas características del FTP es la conocida como el "login anónimo", que permite a usuarios que no tienen cuenta en el sistema acceder a un directorio restringido del sistema de ficheros de la máquina.

Pero lo ideal sería dedicar un servidor exclusivo para esto y por supuesto verificar los archivos que se transfieran a la máquina.

FTP invitado: Los potenciales problemas de seguridad han dado lugar a un tercer tipo de acceso ftp denominado invitado (guest), que se puede contemplar como una mezcla de los dos vistos hasta el momento. La idea de este mecanismo es muy sencilla: se trata de permitir que cada usuario conecte a la máquina mediante su login y su contraseña, pero evitando que tenga acceso a partes del sistema de ficheros que no necesita para realizar su trabajo.

El servicio TELNET

El protocolo telnet (tcp, puerto 23) permite utilizar una máquina como terminal virtual de otra a través de la red, de forma que se crea un canal virtual de comunicaciones similar – pero mucho más inseguro – a utilizar una terminal físicamente conectada a un servidor; la idea es sencilla: estamos accediendo remotamente en modo texto a un equipo – en principio potente – igual que si estuviéramos utilizando su consola o una de sus terminales físicas, lo que nos permite aprovechar toda su potencia de cálculo si necesidad de desplazarnos hasta la ubicación de ese servidor, sino trabajando cómodamente desde nuestro propio equipo.

Lo más normal es que este servicio esté disponible para que los usuarios puedan trabajar remotamente, al menos desde un conjunto de máquinas determinado. Evidentemente, reducir al mínimo imprescindible el conjunto de sistemas desde donde es posible la conexión es una primera medida de seguridad. Cualquier atacante con un analizador de red (o un vulgar sniffer) puede capturar el login y el password utilizados en una conexión; el sniffing siempre es peligroso, pero más aun en sesiones telnet en las que transmitimos nombres de usuarios y contraseñas: estamos otorgando a cualquiera que lea esos datos un acceso total a la máquina destino, bajo nuestra identidad. Por tanto, es muy recomendable no utilizar telnet para conexiones remotas, sino sustituirlo por aplicaciones equivalentes pero que utilicen cifrado para la transmisión de datos: ssh o SSL-Telnet son las más comunes.

El servicio SMTP

El servicio smtp (Simple Mail Transfer Protocol, puerto 25 tcp) se utiliza para transferir correo electrónico entre equipos remotos. Este servicio suele ser atendido por un demonio denominado sendmail, que ha sido uno de los que más problemas de seguridad ha tenido a lo largo de la historia de Unix; y no es para menos: se trata de un software muy complejo y potente, por lo es inevitable que en su código existan bugs.

Una medida de protección básica para nuestro servicio smtp, y que muchos administradores desconocen, es la posibilidad de servir sendmail desde inetd en lugar de hacerlo como un demonio independiente, y por tanto poder restringir el acceso al mismo mediante TCP Wrappers. En la mayoría de organizaciones existe un servidor de correo principal que es el encargado de recoger el mail para todas las direcciones `*@*.upv.es'; el resto de equipos solo recibirán correo desde este equipo. Entonces, parece claro que si nuestro sendmail sólo recibe correo válido desde una máquina, lo lógico es configurarlo para que sólo acepte peticiones desde ella: en lugar de lanzar el demonio al arrancar el sistema, en uno de los scripts de /etc/rc.d/ o similar, lo serviremos desde inetd.

Servidores WWW

Hoy en día las conexiones a servidores web son sin duda las más extendidas entre usuarios de Internet.

Los problemas de seguridad relacionados con el protocolo http se dividen en tres grandes grupos en función de los datos a los que pueden afectar :

Es necesario garantizar que la información almacenada en la máquina servidora no pueda ser modificada sin autorización, que permanezca disponible y que sólo pueda ser accedida por los usuarios a los que les esté legítimamente permitido.

Cuando un usuario conecta a un servidor web se produce un intercambio de información entre ambos; es vital garantizar que los datos que recibe el cliente desde el servidor sean los mismos que se están enviando (esto es, que no sufran modificaciones de terceros), y también garantizar que la información que el usuario envía hacia el servidor no sea capturada, destruida o modificada por un atacante.

Por ultimo es necesario garantizar al usuario que lo que descarga de un servidor no va a perjudicar a la seguridad de su equipo; sin llegar a extremos de applets maliciosos o programas con virus.

Asegurar el servidor implica – aparte de las medidas habituales para cualquier máquina Unix– medidas excepcionales dedicadas al demonio servidor de web y su entorno de trabajo; estas medidas son propias para cada programa servidor. No obstante, y sea cual sea el servidor utilizado (Apache, NCSA, Netscape, etc.), es necesario seguir un consejo básico: minimizar el número de usuarios en la máquina y minimizar el número de servicios ofrecidos en ella.

XWindow

El entorno X Window proporciona herramientas increíblemente potentes, pero que si no son correctamente configuradas pueden convertirse en peligrosas. Este sistema está formado por una serie de piezas que trabajan conjuntamente para ofrecer al usuario final un interfaz gráfico:

Es el servidor X Window quien establece su política de seguridad para permitir a determinados clientes utilizar sus servicios.

Terminales Seguros

En las nuevas versiones de UNIX, se ha introducido también el concepto de "terminal seguro". El objetivo es muy simple: permitir que el super-usuario (root) SOLO pueda entrar a través de un terminal (o solo lo pueda hacer desde la consola). En máquinas SUN el fichero /etc/ttytab se suele utilizar para éstos propósitos, mientras que en LINUX en fichero en cuestión es el /etc/securetty.

FIREWALLS

Una de las nuevas medidas de seguridad que se está empezando a implantar en "La Red" son los firewalls (Cortafuegos). Básicamente un cortafuegos es una máquina especial situada entre InterNet y una LAN interna. Este host no envía hacia "La Red" información de ruteo de la LAN de forma que ésta es invisible desde. A la hora de configurar un firewall se han de tomar las siguientes consideraciones:

1. El firewall no lanza información sobre la tabla de enrrutamiento (esto significa que los usuarios internos han de iniciar sesión en el firewall para poder "salir hacia fuera")

2. Todo el Email de los usuarios de la LAN ha de ser "forwardeado" al firewall para que pueda tener salida

3. El firewall NO debe montar ningún sistema de ficheros via NFS.

El objetivo del firewall es el de prevenir y evitar accesos a los hosts de la LAN por parte de crackers, etc. Hay que recordar que si un cracker es capaz de entrar en el firewall podrán hacerlo en cualquier máquina de la LAN.

 

 

                     

   Anterior          Índice          Siguiente

 

Para mayor información, seleccione una opción:

Número de visitas efectuadas desde el 17/12/2001: 
 
Estadísticas diarias desde el 10/07/2002:    

Número de visitantes actuales disponible desde el 14/07/2002:

 

AddFreeStats.com Free Web Stats in real-time !  

 

 

 

Autor: lrmdavid@exa.unne.edu.ar

Ó FACENA - http://exa.unne.edu.ar

Servicios WEB: webmaster@exa.unne.edu.ar