Sunteți pe pagina 1din 21

SISTEMAS DISTRIBUIDOS

Seguridad y Proteccin

UNIVERSIDAD NACIONAL DE TRUJILLO


ESCUELA DE INFORMATICA

SEGURIDAD Y PROTECCIN EN SISTEMAS DISTRIBUIDOS


Resumen: En los ltimos aos el tema de la seguridad en los sistemas se ha tornado en un asunto de primera importancia dado el incremento de prestaciones de las mismas, as como la imparable ola de ataques o violaciones a las barreras de acceso a los sistemas implementados en aquellas. Los "incidentes de seguridad" reportados continan creciendo cada vez a un ritmo ms acelerado, a la par de la masicacin del Internet y de la complejidad del software desarrollado. Teniendo presente que no existe un sistema seguro pero que si se puede proteger es que existen mtodos para proteger los datos de un sistema as mismo recomendaciones para el uso de dichos sistemas. 1. SEGURIDAD Es la capacidad del sistema para proteger datos, servicios y recursos de usuarios no autorizados. El fin de la seguridad es garantizar la proteccin o estar libre de todo peligro y/o dao, y que en cierta manera es infalible. Como esta caracterstica, particularizando para el caso de sistemas operativos o redes de computadores, es muy difcil de conseguir (segn la mayora de expertos, imposible), se suaviza la definicin de seguridad y se pasa a hablar de fiabilidad (probabilidad de que un sistema se comporte tal y como se espera de el) ms 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 able) consiste bsicamente en garantizar tres aspectos: confidencialidad, integridad y disponibilidad. Algunos estudios integran la seguridad dentro de una propiedad ms general de los sistemas, la confiabilidad, entendida como el nivel de calidad del servicio ofrecido. Consideran la disponibilidad como un aspecto al mismo nivel que la seguridad y no como parte de ella, por lo que dividen esta ltima en slo las dos facetas restantes, confidencialidad e integridad. En este trabajo no seguiremos esa corriente por considerarla minoritaria. La condencialidad: 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 informacin en disponible para otras entidades. La integridad: Significa que los objetos slo pueden ser modificados por elementos autorizados, y de una manera controlada. La disponibilidad: Indica que los objetos del sistema tienen que permanecer accesibles a elementos autorizados; es el contrario de la negacin de servicio.

Generalmente tienen que existir los tres aspectos descritos para que haya seguridad: por ejemplo en un sistema Unix puede conseguir condencialidad para un determinado fichero haciendo que

ningn usuario (ni siquiera el root) pueda leerlo, pero este mecanismo no proporciona disponibilidad alguna. Dependiendo del entorno en que un sistema Unix trabaje, a sus responsables les interesara dar prioridad a un cierto aspecto de la seguridad. Por ejemplo, en un sistema militar se antepondra la condencialidad de los datos almacenados o transmitidos sobre su disponibilidad: seguramente, es preferible que alguien borre informacin confidencial (que se podra recuperar despus desde una cinta de backup) a que ese mismo atacante pueda leerla, o a que esa informacin est disponible en un instante dado para los usuarios autorizados. En cambio, en un servidor NFS de un departamento se premiar la disponibilidad frente a la condencialidad: importa poco que un atacante lea una unidad, pero que esa misma unidad no sea leda por usuarios autorizados va a suponer una prdida de tiempo y dinero. En un entorno bancario, la faceta que mas ha de preocupar a los responsables del sistema es la integridad de los datos, frente a su disponibilidad o su condencialidad: Es menos grave que un usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda modificarlo. 2. QU QUEREMOS PROTEGER Los tres elementos principales a proteger en cualquier sistema informtico son el software, el hardware y los datos. Hardware: Entendemos por hardware al conjunto formado por todos los elementos fsicos de un sistema informtico, como CPUs, terminales, cableado, medios de almacenamiento secundario (cintas, CD-ROMs, diskettes. . .) o tarjetas de red. Software Entendemos por software al conjunto de programas lgicos que hacen funcional al hardware, tanto sistemas operativos como aplicaciones, Datos Entendemos por dato al conjunto de informacin lgica 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, tners, cintas magnticas, diskettes. . .).

Habitualmente los datos constituyen el principal elemento de los tres a proteger, ya que es el ms amenazado y seguramente el ms difcil de recuperar: con toda seguridad en una mquina. Contra cualquiera de los tres elementos descritos anteriormente (pero principalmente sobre los datos) se pueden realizar multitud de ataques o, dicho de otra forma, estn expuestos a diferentes amenazas. Generalmente, la taxonoma ms elemental de estas amenazas las divide en cuatro grandes grupos: interrupcin, interceptacin, modificacin y fabricacin. Un ataque se clasifica como 1. Interrupcin: Si hace que un objeto del sistema se pierda, quede inutilizable o no disponible. 2. Interceptacin Si un elemento no autorizado consigue un acceso a un determinado objeto del sistema. 3. Modificacin: Si adems de conseguir el acceso consigue modificar el objeto; algunos autores consideran un caso especial de la modificacin: la destruccin, entendindola como una modicacin que inutiliza al objeto afectado. 4. Fabricacin: Si se trata de una modificacin destinada a conseguir un objeto similar al atacado de forma que sea difcil distinguir entre el objeto original y el fabricado. En la (figura 1) se muestran estos tipos de ataque de una forma grfica.

Figura: Flujo normal de informacin entre el emisor/receptor y posibles amenazas: (a) Interrupcin (b) Interceptacin (c) Modificacin (d) Fabricacin

3. DE QU NOS QUEREMOS PROTEGER En la gran mayora de publicaciones relativas a la seguridad informtica en general, y especialmente en las relativas a seguridad, tarde o temprano se intenta clasificar en grupos a los posibles elementos que pueden atacar nuestro sistema. Con frecuencia, especialmente en las obras menos tcnicas y ms orientadas a otros aspectos de la seguridad, se suele identificara los atacantes nicamente como personas; esto tiene sentido si hablamos por ejemplo de responsabilidades por un delito informtico. Pero en este trabajo es preferible hablar de elementos y no de personas: aunque a veces lo olvidemos, nuestro sistema puede verse perjudicado por mltiples entidades aparte de humanos, como por ejemplo programas, catstrofes naturales, si un usuario pierde un trabajo importante a causa de un ataque, poco le importara que haya sido un intruso, un gusano, un simple error del administrador, o un alien que haya abducido un disco duro.

A continuacin se presenta una relacin de los elementos que potencialmente pueden amenazar a nuestro sistema. No se pretende ser exhaustiva, ni por supuesto una taxonoma formal; simplemente se trata de proporcionar una idea acerca de qu o quin amenaza un sistema Unix. A lo largo de este proyecto se ahondara en aspectos de algunos de los elementos presentados aqu. Personas La mayora de ataques a nuestro sistema van a provenir en ltima instancia de personas que, intencionada o inintencionadamente, pueden causarnos enormes prdidas. Generalmente se tratara de piratas que intentan conseguir el mximo nivel de privilegio posible aprovechando alguno (o algunos) de los riesgos lgicos de los que hablaremos a continuacin, especialmente agujeros del software. Pero con demasiada frecuencia se suele olvidar que los piratas clsicos no son los nicos que amenazan nuestros equipos: es especialmente preocupante que mientras que hoy en da cualquier administrador mnimamente preocupado por la seguridad va a conseguir un sistema relativamente able de una forma lgica (permaneciendo atento a vulnerabilidades de su software, restringiendo servicios, utilizando cifrado de datos, en otros), pocos administradores tienen en cuenta factores como la ingeniera social o el basureo a la hora de disear una poltica de seguridad. 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, y los Activos. o o Pasivos: aquellos que fisgonean por el sistema pero no lo modifican o no destruyen, y los Activos: aquellos que daan el objetivo atacado, o lo modifican en su favor.

Generalmente los curiosos y los crackers realizan ataques pasivos (que se pueden convertir en activos), mientras que los terroristas y ex-empleados realizan ataques activos puros; los intrusos remunerados suelen ser atacantes pasivos si nuestra red o equipo no es su objetivo, y activos en caso contrario, y el personal realiza ambos tipos indistintamente, dependiendo de la situacin concreta. Describiremos algunos de ataques que realizan las personas: o Personal Las amenazas a la seguridad de un sistema provenientes del personal de la propia organizacin 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 organizacin, incluso el personal ajeno a la infraestructura informtica (secretariado, personal de seguridad, personal de limpieza y mantenimiento, entre otros) puede comprometer la seguridad de los equipos. Aunque los ataques pueden ser intencionados (en cuyo caso sus efectos son extremadamente dainos, recordemos que nadie mejor que el propio personal de la organizacin conoce mejor los sistemas y sus debilidades), lo normal es que ms que de ataques se trate de accidentes causados por un error o por desconocimiento de las normas bsicas de seguridad: un empleado de mantenimiento que corta el suministro elctrico para hacer una reparacin puede llegar a ser tan peligroso como el ms experto de los administradores que se equivoca al teclear una orden y borra todos los sistemas de ficheros; y en el primer caso, el atacante ni siquiera ha de tener acceso lgico (ni fsico!) a los equipos, ni conocer nada sobre seguridad . Hemos de recordar siempre que decir No lo hice a propsito no va a servir para recuperar datos perdidos ni para restaurar un hardware daado o robado. o Ex-empleados 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). Generalmente, se trata de personas descontentas con la organizacin que pueden

aprovechar debilidades de un sistema que conocen perfectamente para daarlo como venganza por algn hecho que no consideran justo: amparados en excusas como No me han pagado lo que me deben o Es una gran universidad, se lo pueden permitir pueden insertar troyanos, bombas lgicas, virus, o simplemente conectarse al sistema como si an trabajaran para la organizacin (muchas veces se mantienen las cuentas abiertas incluso meses despus de abandonar la universidad o empresa), conseguir el privilegio necesario, y daarlo de la forma que deseen, incluso chantajeando a sus ex-compaeros o ex-jefes. o Curiosos Junto con los crackers, los curiosos son los atacantes ms habituales de los sistemas en redes de I+D. Recordemos que los equipos estn trabajando en entornos donde se forma a futuros profesionales de la informtica y las telecomunicaciones (gente que a priori tiene inters por las nuevas tecnologas), y recordemos tambin que las personas suelen ser curiosas por naturaleza; esta combinacin produce una avalancha de estudiantes o personal intentando conseguir mayor privilegio del que tienen o intentando acceder a sistemas a los que oficialmente no tienen acceso. Y en la mayora de ocasiones esto se hace simplemente para leer el correo de un amigo, enterarse de cuanto cobra un compaero, copiar un trabajo o comprobar que es posible romper la seguridad de un sistema concreto. Aunque en la mayora de situaciones se trata de ataques no destructivos (a excepcin del borrado de huellas para evitar la deteccin), parece claro que no benefician en absoluto al entorno de fiabilidad que podamos generar en un determinado sistema. Crackers Los entornos de seguridad media son un objetivo tpico de los intrusos, ya sea para fisgonear, para utilizarlas como enlace hacia otras redes o simplemente por diversin. Por un lado, son redes generalmente abiertas, y la seguridad no es un factor tenido muy en cuenta en ellas; por otro, el gran nmero y variedad de sistemas conectados a estas redes provoca, casi por simple probabilidad, que al menos algunos de sus equipos (cuando no la mayora) sean vulnerables a problemas conocidos de antemano. De esta forma un atacante slo ha de utilizar un escner 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 fcil y apetecible para piratas con cualquier nivel de conocimientos, desde los ms novatos (y a veces ms peligrosos) hasta los expertos, que pueden utilizar toda la red para probar nuevos ataques o como nodo intermedio en un ataque a otros organismos, con el consiguiente deterioro de imagen (y a veces de presupuesto) que supone para una universidad ser, sin desearlo, un apoyo a los piratas que atacan sistemas tericamente ms protegidos, como los militares. Terroristas Por terroristas no debemos entender simplemente a los que se dedican a poner bombas o quemar autobuses; bajo esta definicin se engloba a cualquier persona que ataca al sistema simplemente por causar algn tipo de dao en el. Por ejemplo, alguien puede intentar borrar las bases de datos de un partido poltico enemigo o destruir los sistemas de ficheros de un servidor que alberga pginas web de algn grupo religioso; en el caso de redes de I+D, tpicos ataques son la destruccin de sistemas de prcticas o la modificacin de pginas web de algn departamento o de ciertos profesores, generalmente por parte de alumnos descontentos. Intrusos remunerados Este es el grupo de atacantes de un sistema ms peligroso, aunque por fortuna el menos habitual en redes normales; suele afectar ms a las grandes muy grandes empresas o a organismos de defensa. Se trata de piratas con gran experiencia en problemas de seguridad y un amplio conocimiento del sistema, que son pagados por una tercera parte generalmente para robar secretos (el nuevo dise de un procesador, una base de datos de clientes, informacin confidencial sobre las posiciones de satlites espa) o simplemente para daar

la imagen de la entidad afectada. Esta tercera parte suele ser una empresa de la competencia o un organismo de inteligencia, es decir, una organizacin que puede permitirse un gran gasto en el ataque; de ah su peligrosidad: se suele pagar bien a los mejores piratas, y por si esto fuera poco los atacantes van a tener todos los medios necesarios a su alcance. Aunque como hemos dicho los intrusos remunerados son los menos comunes en la mayora de situaciones, en ciertas circunstancias pueden aprovechar nuestras redes como plataforma para atacar otros organismos; Amenazas lgicas Bajo la etiqueta de amenazas lgicas encontramos todo tipo de programas que de una forma u otra pueden daar a nuestro sistema, creados de forma intencionada para ello (software malicioso, tambin conocido como malware) o simplemente por error (bugs o agujeros). A continuacin presentamos algunos tipos de amenazas lgicas: o Software incorrecto Las amenazas ms habituales a un sistema provienen de errores cometidos de forma involuntaria por los programadores de sistemas o de aplicaciones. Una situacin no contemplada a la hora de disear el sistema de red del kernel o un error accediendo a memoria en un fichero . A estos errores de programacin 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 ms comn contra sistemas, ya que cualquiera puede conseguir un exploit y utilizarlo contra nuestra mquina sin ni siquiera saber cmo funciona y sin unos conocimientos mnimos; incluso hay exploits que daan seriamente la integridad de un sistema (negaciones de servicio o incluso acceso root remoto) y estn preparados para ser utilizados desde MS-DOS, con lo que cualquier pirata novato (comnmente, se les denomina Script Kiddies) puede utilizarlos contra un servidor y conseguir un control total de una mquina de varios millones de dinero desde su PC sin saber nada del sistema atacado; incluso hay situaciones en las que se analizan los logs de estos ataques y se descubre que el pirata incluso intenta ejecutar ordenes de MS-DOS. Herramientas de seguridad 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 informacin sobre las vulnerabilidades de un host o de una red completa. La conveniencia de disear y distribuir libremente herramientas que puedan facilitar un ataque es un tema peliagudo; incluso expertos reconocidos como Alec Muet (autor del adivinador de contraseas Crack) han recibido enormes crticas por disear determinadas herramientas de seguridad. Puertas traseras Durante el desarrollo de aplicaciones grandes o de sistemas operativos es habitual entre los programadores insertar atajos en los sistemas habituales de autenticacin del programa o del ncleo que se est diseando. A estos atajos se les denomina puertas traseras, y con ellos se consigue mayor velocidad a la hora de detectar y depurar fallos: por ejemplo, los diseadores de un software de gestin de bases de datos en el que para acceder a una tabla se necesiten cuatro claves diferentes de diez caracteres cada una pueden insertar una rutina para conseguir ese acceso mediante una nica clave especial, con el objetivo de perder menos tiempo al depurar el sistema. Algunos programadores pueden dejar estos atajos en las versiones definitivas de su software para facilitar un mantenimiento posterior, para garantizar su propio acceso, o simplemente por descuido; la cuestin es que si un atacante descubre una de estas puertas traseras (no nos importa el mtodo que utilice para hacerlo)

va a tener un acceso global a datos que no debera poder leer, lo que obviamente supone un grave peligro para la integridad de nuestro sistema. Bombas lgicas. Las bombas lgicas son partes de cdigo de ciertos programas que permanecen sin realizar ninguna funcin hasta que son activadas; en ese punto, la funcin que realizan no es la original del programa, sino que generalmente se trata de una accin perjudicial. Los activadores mas comunes de estas bombas lgicas pueden ser la ausencia o presencia de ciertos ficheros, la ejecucin bajo un determinado UID o la llegada de una fecha concreta; cuando la bomba se activa va a poder realizar cualquier tarea que pueda realizar la persona que ejecuta el programa: si las activa el root, o el programa que contiene la bomba est situado a su nombre, los efectos obviamente pueden ser fatales. o Canales cubiertos Los canales son canales de comunicacin que permiten a un proceso transferir informacin de forma que viole la poltica de seguridad del sistema; dicho de otra forma, un proceso transmite informacin a otros (locales o remotos) que no estn autorizados a leer dicha informacin. Los canales cubiertos no son una amenaza demasiado habitual en redes de I+D, ya que suele ser mucho ms fcil para un atacante aprovechar cualquier otro mecanismo de ataque lgico; sin embargo, es posible su existencia, y en este caso su deteccin suele ser difcil: algo tan simple como el puerto finger abierto en una mquina puede ser utilizado a modo de covert channel por un pirata con algo de experiencia. Virus Un virus es una secuencia de cdigo que se inserta en un fichero ejecutable (denominado husped), de forma que cuando el archivo se ejecuta, el virus tambin lo hace, insertndose a s mismo en otros programas. Todo el mundo conoce los efectos de los virus en algunos sistemas operativos de sobremesa. Gusanos Un gusano es un programa capaz de ejecutarse y propagarse por si mismo a travs de redes, en ocasiones portando virus o aprovechando bugs de los sistemas a los que conecta para daarlos. Al ser difciles de programar su nmero no es muy elevado, pero el dao que pueden causar es muy grande: el mayor incidente de seguridad en Internet fue precisamente el Internet Worm, un gusano que en 1988 caus prdidas millonarias al infectar y detener ms de 6000 maquinas conectadas a la red. Hemos de pensar que un gusano puede automatizar y ejecutar en unos segundos todos los pasos que seguira un atacante humano para acceder a nuestro sistema: mientras que una persona, por muchos conocimientos y medios que posea, tardara como mnimo horas en controlar nuestra red completa (un tiempo ms que razonable para detectarlo), un gusano puede hacer eso mismo en pocos minutos: de ah su enorme peligro y sus devastadores efectos. Caballos de Troya 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 (generalmente en detrimento de la seguridad) sin el conocimiento del usuario; como el Caballo de Troya de la mitologa griega, al que deben su nombre, ocultan su funcin real bajo la apariencia de un programa inofensivo que a primera vista funciona correctamente. Por ejemplo para que al recibir un cierto nombre de usuario y contrasea proporcione acceso al sistema sin necesidad de consultar /etc/passwd. Programas conejo o bacterias Bajo este nombre se conoce a los programas que no hacen nada til, sino que simplemente se dedican a reproducirse hasta que el nmero de copias acaba con los recursos del sistema (memoria, procesador, disco), produciendo una negacin de servicio. Por si mismos no hacen ningn dao, sino que lo que realmente perjudica es el gran nmero de copias suyas

en el sistema, que en algunas situaciones pueden llegar a provocar la parada total de la mquina. Hemos de pensar hay ciertos programas que pueden actuar como conejos sin proponrselo. o Tcnicas salami Por tcnica salami se conoce al robo automatizado de pequeas cantidades de bienes (generalmente dinero) de una gran cantidad origen. El hecho de que la cantidad inicial sea grande y la robada pequea hace extremadamente difcil su deteccin: si de una cuenta con varios millones de dinero se roban unos cntimos, nadie va a darse cuenta de ello; si esto se automatiza para, por ejemplo, descontar una peseta de cada nomina pagada en la universidad o de cada beca concedida, tras un mes de actividad seguramente se habr robado una enorme cantidad de dinero sin que nadie se haya percatado de este hecho, ya que de cada origen se ha tomado una cantidad nfima. Las tcnicas salami no se suelen utilizar para atacar sistemas normales, sino que su uso ms habitual es en sistemas bancarios; sin embargo, como en una red con requerimientos de seguridad medios es posible que haya ordenadores dedicados a contabilidad, facturacin de un departamento o gestin de nminas del personal, comentamos esta potencial amenaza contra el software encargado de estas tareas.

Catstrofes Las catstrofes (naturales o artificiales) son la amenaza menos probable contra los entornos habituales: simplemente por su ubicacin geogrfica, a nadie se le escapa que la probabilidad de sufrir un terremoto o una inundacin que afecte a los sistemas informticos en una gran ciudad como Madrid, Valencia o Barcelona, es relativamente baja, al menos en comparacin con el riesgo de sufrir un intento de acceso por parte de un pirata o una infeccin por virus. Sin embargo, el hecho de que las catstrofes sean amenazas poco probables no implica que contra ellas no se tomen unas medidas bsicas, ya que si se produjeran generaran los mayores daos. Un subgrupo de las catstrofes es el denominado de riesgos poco probables. Obviamente se denomina as al conjunto de riesgos que, aunque existen, la posibilidad de que se produzcan es tan baja (menor incluso que la del resto de catstrofes) que nadie toma, o nadie puede tomar, medidas contra ellos. Ejemplos habituales de riesgos poco probables son un ataque nuclear contra el sistema, el impacto de un satlite contra la sala de operaciones, o la abduccin de un operador por una nave extraterrestre. Nada nos asegura que este tipo de catstrofes no vaya a ocurrir, pero la probabilidad es tan baja y los sistemas de prevencin tan costosos que no vale la pena tomar medidas contra ellas. Como ejemplos de catstrofes hablaremos de terremotos, inundaciones, incendios, humo o atentados de baja magnitud (ms comunes de lo que podamos pensar); obviamente los riesgos poco probables los trataremos como algo anecdtico. De cualquier forma, vamos a hablar de estas amenazas sin extendernos mucho, ya que el objetivo de este proyecto no puede ser el proporcionar las directrices para una construccin de edicios a prueba de terremotos, o un plan formal de evacuacin en caso de incendio. 4. COMO NOS PODEMOS PROTEGER Hasta ahora hemos hablado de los aspectos que engloba la seguridad informtica, de los elementos a proteger, de los tipos de amenazas que contra ellos se presentan y del origen de tales amenazas; parece claro que, para completar nuestra visin de la seguridad, hemos de hablar de las formas de proteccin de nuestros sistemas. Cuando hayamos completado este punto, habremos presentado a grandes rasgos los diferentes puntos a tratar en este proyecto, tal y como se sintetiza en la figura 2. Para proteger nuestro sistema hemos de realizar un anlisis de las amenazas potenciales que puede sufrir, las prdidas que podran generar, y la probabilidad de su ocurrencia; a partir de este anlisis hemos de disear una poltica 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 poltica de seguridad se les denomina mecanismos de seguridad; son la parte ms visible de nuestro sistema de seguridad, y se convierten en la herramienta bsica para garantizar la proteccin de los sistemas o de la propia red.

Los mecanismos de seguridad se dividen en tres grandes grupos: de prevencin, de deteccin y de recuperacin. Los mecanismos de prevencin: 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 transmisin 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 en la red. Los Mecanismos de deteccin: Se conoce a aquellos que se utilizan para detectar violaciones de la seguridad o intentos de violacin; ejemplos de estos mecanismos son los programas de auditoria como Tripwire. Finalmente Los mecanismos de recuperacin: Son aquellos que se aplican cuando una violacin del sistema se ha detectado, para retornar a ste a su funcionamiento correcto; ejemplos de estos mecanismos son la utilizacin de copias de seguridad o el hardware adicional. Dentro de este ltimo grupo de mecanismos de seguridad encontramos un subgrupo denominado mecanismos de anlisis forense, cuyo objetivo no es simplemente retornar al sistema a su modo de trabajo normal, sino averiguar el alcance de la violacin, las actividades de un intruso en el sistema, y la puerta utilizada para entrar; de esta forma se previenen ataques posteriores y se detectan ataques a otros sistemas de nuestra red. Parece claro que, aunque los tres tipos de mecanismos son importantes para la seguridad de nuestro sistema, hemos de enfatizar en el uso de mecanismos de prevencin y de deteccin; la mxima popular ms vale prevenir que curar se puede aplicar a la seguridad informtica: para nosotros, evitar un ataque, detectar un intento de violacin, o detectar una violacin exitosa inmediatamente despus de que ocurra es mucho ms productivo y menos comprometedor para el sistema que restaurar el estado tras una penetracin de la mquina. Es ms, si consiguiramos un sistema sin vulnerabilidades y cuya poltica de seguridad se implementara mediante mecanismos de prevencin de una forma completa, no necesitaramos mecanismos de deteccin o recuperacin.

Figura 2: Visin global de la seguridad informtica


5. TOLERANCIA A FALLOS Un sistema falla si no puede lograr sus objetivos, si ocurren fallos que producen errores Tolerancia a fallos es que un sistema no falle aunque ocurran fallos, para esto debe ser confiable (disponibilidad, fiabilidad, seguridad, mantenibilidad). Tipos de fallos por su duracin:

o o o

Transitorios: El elemento solo falla una vez y despus vuelve a funcionar correctamente Intermitentes: El fallo en el elemento aparece de forma intermitente. Permanentes: Una vez el elemento falla, ya no se recupera.

Modelos de fallos En general puede ocurrir cualquier tipo de fallo, pero se simplifica para poder disear sistemas y protocolos. El tipo de fallos que se consideran relevantes, constituyen el modelo de fallos. Tipos de fallos a considerar en los modelos: o Fallos de parada: El elemento que falla, simplemente deja de funcionar y no interfiere con el resto del sistema una vez falla. o Fallos de omisin: El elemento que falla no hace cierta parte de su cometido: por ejemplo: un canal de comunicacin puede presentar fallos de omisin de envo o de respuesta. o Fallos de temporizacin: El elemento que falla no lo hace en el tiempo previsto. o Fallos de respuesta: El elemento responde incorrectamente a las peticiones que se le realizan. o Fallos arbitrarios: El componente que falla funciona de forma descontrolada. Enmascaramiento de fallos por redundancia o Enmarcar fallos: los fallos ocurren, pero el sistema no los muestra hacia su entorno. o Tcnica fundamental: redundancia Informacin redundante: informacin que solo es til para comprobar que no hay fallos. Por ejemplo: los CRCs Redundancia en el tiempo (el nmero de veces que se realiza una operacin) Redundancia de elementos: Utilizar varios elementos iguales para intentar disminuir la probabilidad de que no se proporcione servicio: replicacin. Fallos en entornos cliente/servidor En la interaccin entre un cliente y un servidor pueden ocurrir muchos tipos de fallos: en el servidor, en el canal y en el cliente: o El cliente no encuentra al servidor: sin solucin. Simplemente se lanza una excepcin o La peticin del cliente al servidor se pierde: retransmisin despus de cierto tiempo. Se deben detectar peticiones duplicadas en el servidor, para que las descarte. o El servidor falla: Al recibir la peticin, antes de procesarla. A mitad de procesar la peticin: diferentes semnticas (prxima transparencia). Al terminar el procesamiento, antes de responder. o La respuesta del servidor se pierde: Difcil solucin: retransmisin del mensaje del cliente, que el servidor debe identificar para responderle con los resultados previos. Aparece problema de recoleccin de residuos! El cliente falla antes de recibir la respuesta: Problema de peticiones hurfanas. Difcil solucin. o Falla el servidor a mitad de procesar la peticin. Semnticas posibles: Semntica como mnimo una vez: se debe garantizar que el servidor ejecuta el servicio como mnimo una vez. Como ha fallado, se debe esperar a que recupere, para reintentar la misma peticin. Semntica como mximo una vez. No se reintenta la operacin. Semntica exactamente una vez: En general imposible de lograr. Por ejemplo: la operacin implica imprimir un documento. Cundo sabe el cliente que fue impreso? En este ejemplo, solo posible si la impresora colabora.

Grupos de procesos o Efectiva tcnica de enmascaramiento de fallos: se replican los procesos. o Un conjunto de procesos idnticos recibe y procesa cada peticin. Opciones: El cliente se queda con una de las respuestas. Se toleran fallos de parada. El cliente se queda con la respuesta que proporcione la mayora: Votacin. Se toleran fallos arbitrarios. o Son necesarios protocolos de comunicacin a grupos que garanticen que los mensajes lleguen a todos los miembros del grupo o a ninguno: Comunicacin a grupos atmica. 6. Mecanismos de seguridad Cifrado o Simtrico (clave secreta) o Asimtrico (par de claves pblica y privada)

Autenticacin o Passwords o Protocolos de reto-respuesta.

Autorizacin o Listas de control de accesos, Credenciales o Firewalls

Auditora o Mantenimiento y anlisis de trazas (logs) 7. Kerberos La autenticacin en redes de computadores se realizaba principalmente de dos formas: o bien se aplicaba la autenticacin por declaracin (Authentication by assertion), en la que el usuario es libre de indicar el servicio al que desea acceder (por ejemplo, mediante el uso de un cliente determinado), o bien se utilizaban contraseas para cada servicio de red. Evidentemente el primer modelo proporciona un nivel de seguridad muy bajo, ya que se le otorga demasiado poder al cliente sobre el servidor; el segundo modelo tampoco es muy bueno: por un lado se obliga al usuario a ir tecleando continuamente su clave, de forma que se pierde demasiado tiempo y adems la contrasea est viajando continuamente por la red. Kerberos trata de mejorar estos esquemas intentando por un lado que un cliente necesite autorizacin para comunicar con un servidor (y que esa autorizacin provenga de una mquina confiable), y por otro eliminando la necesidad de demostrar el conocimiento de informacin privada (la contrasea del usuario) divulgando dicha informacin. El uso de Kerberos se produce principalmente en el login, en el acceso a otros servidores (por ejemplo, mediante rlogin) y en el acceso a sistemas de ficheros en red como NFS. Una vez que un cliente est autenticado o bien se asume que todos sus mensajes son fiables, o si se desea mayor seguridad se puede elegir trabajar con mensajes seguros (autenticados) o privados (autenticados y cifrados). Kerberos se puede implementar en un servidor que se ejecute en una mquina segura, mediante un conjunto de bibliotecas que utilizan tanto los clientes como las aplicaciones; se trata de un sistema fcilmente escalable y que admite replicacin, por lo que se puede utilizar incluso en sistemas de alta disponibilidad

Esquema bsico de kerberos Arquitectura de Kerberos Un servidor Kerberos se denomina KDC (Kerberos Distribution Center), y provee de dos servicios fundamentales: el de autenticacin (AS, Authentication Service) y el de tickets (TGS, Ticket Granting Service). El primero tiene como funcin autenticar inicialmente a los clientes y proporcionarles un ticket para comunicarse con el segundo, el servidor de tickets, que proporcionara a los clientes las credenciales necesarias para comunicarse con un servidor final que es quien realmente ofrece un servicio. Adems, el servidor posee una base de datos de sus clientes (usuarios o programas) con sus respectivas claves privadas, conocidas nicamente por dicho servidor y por el cliente que al que pertenece. La arquitectura de Kerberos est basada en tres objetos de seguridad: Clave de Sesin, Ticket y Autenticador. o La clave de sesin es una clave secreta generada por Kerberos y expedida a un cliente para uso con un servidor durante una sesin; no es obligatorio utilizarla en toda la comunicacin con el servidor, slo si el servidor lo requiere (porque los datos son confidenciales) o si el servidor es un servidor de autenticacin. Se suele denominar a esta clave KCS, para la comunicacin entre un cliente C y un servidor S. Las claves de sesin se utilizan para minimizar el uso de las claves secretas de los diferentes agentes: estas ltimas son vlidas durante mucho tiempo, por lo que es conveniente para minimizar ataques utilizarlas lo menos posible. o El ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar los servicios de un servidor; garantiza que el cliente ha sido autenticado recientemente. A un ticket de un cliente C para acceder a un servicio S se le denomina {ticket(C, S)}KS = {C, S, t1, t2,KCS}KS . Este ticket incluye el nombre del cliente C, para evitar su posible uso por impostores, un periodo de validez [t1, t2] y una clave de sesin KCS asociada para uso de cliente y servidor. Kerberos siempre proporciona el ticket ya cifrado con la clave secreta del servidor al que se le entrega. o El autenticador es un testigo construido por el cliente y enviado a un servidor para probar su identidad y la actualidad de la comunicacin; slo puede ser utilizado una vez. Un autenticador de un cliente C ante un servidor S se denota por {auth(C)}KCS = {C, t}KCS . Este autenticador contiene, cifrado con la clave de la sesin, el nombre del cliente y un timestamp. Kerberos sigue de cerca el protocolo de Needham y Schroeder ([NS78]) con clave secreta, utilizando timestamps como pruebas de frescura con dos propsitos: evitar reenvos de viejos mensajes capturados en la red o la reutilizacin de viejos tickets obtenidos de zonas de

memoria del usuario autorizado, y a la vez poder revocar a los usuarios los derechos al cabo de un tiempo.

8.

Recomendaciones de seguridad 1. Efectuar un anlisis de riesgos Esto se suele mencionar en la literatura como el primer paso a realizarse cuando se plantea la seguridad en un sistema. La idea es muy sencilla: trazar todos los elementos que conforman nuestro sistema (hardware y software) y observar cules involucran ms o menos riesgo. Esto desembocar en un plan de seguridad cuyo objetivo es disminuir el riesgo total del sistema, que se puede modelar como la suma de los riesgos de sus componentes: RIESGO TOTAL = RIESGO(componente 1) + RIESGO(componente 2) ... El riesgo de cada componente est en funcin directa a las prdidas que ocasionara el que ste deje de operar, as como en funcin de cun vulnerable es dicho componente en este momento. Por ejemplo, una base de datos de clientes involucra un gran riesgo debido al gran valor que la informacin representa para una organizacin; pero una simple PC Windows de la misma organizacin conectada directamente al Internet (sin firewall/Proxy de por medio) tambin lo representa, debido a que puede ser objeto de un ataque desde el exterior, con el posible riesgo de fcil propagacin hacia otros computadores de nuestra red. El riesgo no es fcil de cuantificar, siendo en general un estimador subjetivo. A modo de ejemplo podramos plantear una frmula como la que sigue: RIESGO(componente) = P * V Donde P=prdida, es la prdida en dinero que implicara la inoperatividad del componente hasta su reparacin, aunque se pueden agregar otros estimadores como el desprestigio ante nuestros clientes. A veces ayuda considerarlo como "el valor" que representa para la organizacin. V=vulnerabilidad, es tanto o ms subjetiva puesto que no hay una manera segura de establecer para todos los casos si los supuestos mecanismos de proteccin (del componente) son o no realmente confiables. As por ejemplo, podramos suponer que la vulnerabilidad de ciertos documentos importantes es muy baja, puesto que estn protegidos por cierto antivirus. Sin embargo, esto realmente estar en funcin de diversas caractersticas del antivirus, como pueden ser: recientes actualizaciones, ejecucin automtica, capacidad de eliminar virus locales, licencias no caducadas, configuracin adecuada, etc. Pero por algo se debe comenzar. Por ejemplo, se puede asignar nmeros como 1, 2, 3, 4, para sealar una

vulnerabilidad mnima, regular, importante y peligrosa, respectivamente. Para una extensa (y compleja) explicacin, Esto normalmente demanda el acopio de mucha informacin, la que muchas veces no est a cargo de una sola persona. Esto implica que todo el staff encargado de las distintas partes del sistema debe colaborar en el anlisis. 2. Lo ms valioso debe alejarse de lo ms vulnerable En la frmula del "riesgo" propuesta arriba, es evidente que los componentes de nuestro sistema con algo valor y alta vulnerabilidad sern de lejos los que presenten mayor riesgo. Sin embargo, en muchos casos no es sencillo disminuir el valor de cierto componente (y por tanto la prdida en caso de problemas), y tampoco se puede eliminar completamente la vulnerabilidad del mismo (por ejemplo, si est de cara a Internet.) En este caso lo que conviene es separar o dividir este componente en dos partes suficientemente alejadas e independientes a fin de que el riesgo total disminuya. Por ejemplo, los portales de comercio electrnico deben dar cara a Internet (siendo vulnerables en principio) y a la vez manejar informacin muy costosa (como transacciones con tarjeta de crdito.) Esto los convierte en un sistema de alto riesgo. Sin embargo es casi universal la separacin que se efecta entre los componentes dedicados a dar cara a Internet (como los Web Servers) y los componentes que manipulan la informacin comercial (generalmente sistemas DBMS.) En trminos prcticos, esto significa que el hacker no puede acceder directamente al DBMS (lo que sera catastrfico), y slo podra atacar al Web Server, lo que en principio no acarrea mayores consecuencias. Juguemos con los nmeros siguiendo las ideas expuestas ms arriba. Suponiendo que los datos relacionados al negocio valen para nosotros $50000, y estn en un computador donde corre un Web Server IIS que no ha sido parchado adecuadamente. Entonces el riesgo sera: R total = 50000 x 5 = 250000 Supongamos ahora que los datos estn en otro computador "mnimamente vulnerable" (con V=1) adecuadamente aislado del Web Server (que todava no ha sido parchado). La prdida por una interrupcin del servicio del Web Server, por da se ha estimado en $2000 (asumimos que ese es el tiempo que toma en restablecerse el servicio tras el ataque.) Entonces el riesgo total se convierte en: R total = R1 + R2 = 50000 x 1 + 2000 x 5 = 60000 3. Mantener las cosas simples Un sistema complejo es ms difcil de asegurar y potencialmente proporciona una mayor cantidad de puertas abiertas a los atacantes. En general, es recomendable intentar dividir el problema mediante la simplificacin de la configuracin, para as identificar los puntos o rutas de control vulnerables para incrementar la seguridad. Un ejemplo frecuentemente citado es la seguridad de una red de estaciones Windows manipulada por usuarios inexpertos. En muchos casos no resulta prctico efectuar un profundo trabajo de seguridad en las estaciones (ms all de la instalacin del antivirus, por ejemplo), puesto que por un lado, son muchas, y por otro, los usuarios suelen modificar la configuracin en tanto instalan y desinstalan su software sin dar aviso a nadie. En estos casos es aconsejable centrarnos en un nico punto que centralice la seguridad de todas las estaciones. Una configuracin de red que obligue a que todo su trfico pase a travs de un gateway permitira crear un nico punto de control para todas las estaciones, con lo cual simplificamos la administracin. Todo esto generalmente conlleva a situaciones en las que hay que hacer un compromiso. Por ejemplo, en la recomendacin anterior, optamos por separar la base de datos del servidor Web con lo que la complejidad del sistema se increment, aunque se redujo el riesgo total. 4. Asegurar la seguridad en todos los niveles Esto se puede expresar ms sencillamente como: no confiar el sistema a un nico mecanismo de seguridad. La informacin fluye a travs de los distintos componentes y/o capas del sistema y son muchas las instancias en las que se puede mejorar su seguridad. La recomendacin estipula que

utilicemos todas estas instancias a pesar de que en principio puedan parecer redundantes. Por lo general los administradores tienden a preocuparse por un nico punto de acceso desde donde supuestamente hay una gran probabilidad de ser atacados (por ejemplo, la conexin a Internet.) Por tanto se invierte esfuerzo y dinero en controlar este nico punto bajo la asuncin de que es la nica puerta de entrada a los maleantes y que por tanto, tras asegurarla, todo el sistema quedar seguro. Esto tiene dos problemas: Muchos ataques o "vulnerabilidades" se originan (de forma inocente o intencional) desde dentro de la organizacin El sistema que controla la "puerta" siempre puede fallar Esto obliga a implementar la seguridad no en un nico punto evidentemente vulnerable, sino en todos los lugares por donde fluye la informacin al interior de cada componente involucrado. Un ejemplo tpico lo constituye un filtro de paquetes TCP/IP, operando a nivel de capas 3 y 4 del modelo OSI. Estos por lo general hacen un gran servicio restringiendo accesos a servicios de red internos y se suelen colocar en la "puerta" o "gateway" que da cara a Internet o a una red insegura a modo de "firewall". Tomando literalmente la idea de "niveles" o "capas", podramos pensar qu hacer en este gateway para mejorar la seguridad. Son 7 las capas OSI y podramos intentar aadir instancias de control adicionales a las mencionadas. Por ejemplo, en la capa 7 (aplicacin) es frecuente y muy recomendable el empleo de proxys HTTP. Algunos rewalls proporcionan control a nivel de la capa 2 (especficamente, del MAC Address.) Sin embargo, esto se debe complementar con otras medidas que van ms all del gateway y que se implementan a lo largo de todo el sistema (pudindose considerar como niveles o "capas" adicionales), tales como redes perimtricas, el uso de encriptacin, etc. 5. Encriptar tanto como sea posible La encriptacin es un tema complejo pero cuya implementacin resulta cada vez ms sencilla conforme aparecen ms productos. Los cambios del ao pasado en la legislacin norteamericana con respecto a la exportacin de productos que encriptan, son un incentivo claro para que los desarrolladores y vendedores se interesen ms en el tema. En general, los canales de comunicacin ms vulnerables o de mayor cercana al pblico requieren una encriptacin "ms fuerte", es decir, ms difcil de descifrar por los curiosos o atacantes. Cierta informacin conlleva ms riesgo que otra, y por tanto requerir un nivel de encriptacin diferenciado. Las herramientas capaces de hacer esto son muchas, dependiendo del contexto en que nos encontremos. Por ejemplo, los sistemas DBMS ms avanzados incorporan la encriptacin como una opcin normal para los datos almacenados, generalmente bajo esquemas propietarios. La tecnologa de encriptacin de informacin destinada a pasar a travs de la red ha evolucionado bastante, hacindose popular el trmino VPN para hacer referencia a canales que encriptan la informacin de un modo ms o menos transparente. Hay soluciones propietarias as como estndares relativamente implementados como IP Sec. Ciertas aplicaciones estndar han recibido soluciones de encriptacin tambin estndar. El caso del Web encriptado bajo SSL (HTTPS) junto con la industria de certificados digitales es el caso ms conspicuo. De igual modo los estndares para correo electrnico PGP (o derivados) y S/MIME son integrados cada vez con mayor frecuencia en las aplicaciones de los usuarios finales. Retornemos al principio. En nuestra organizacin deberamos encriptar todo lo que sea posible. La razn de esto es evidente si de lo que se trata es de enviar un mensaje privado por Internet. Sin embargo, al interior de la organizacin la encriptacin puede ayudar tambin. Por ejemplo, es usual que cierta informacin sea manejada exclusivamente por un nmero reducido de personas (los contratos salariales, por poner un caso.) Un caso ms dramtico se presenta cuando un hacker ha logrado infiltrarse en la organizacin: si la informacin est encriptada, los datos que robe le sern intiles dado que no posee las claves correspondientes. Naturalmente hay que sopesar los inconvenientes que trae la encriptacin en trminos de incomodidad de uso, costo de licencias, ciclos de CPU, etctera; con el hecho de que cierta informacin es definitivamente de carcter pblico y por tanto no tiene sentido que est

encriptada. Por ejemplo, la informacin que se publica en Internet va el Web Server de la empresa. En se puede obtener regularmente mucha informacin interesante y actualizada sobre la encriptacin. 6. No confiar en la autenticacin estndar Las redes locales, y por extensin, el Internet, NO fueron diseados en principio para ser seguros. La mayora del software y hardware creados hasta incluso mediados de los aos 90, no tuvieron la seguridad como objetivo de primer orden. Esto implica que muchos de los sistemas que compramos y usamos en la actualidad tienen serias deficiencias, pero que por mantener la compatibilidad no se han podido corregir. Un caso crtico es lo concerniente a la autenticacin de los accesos. En la gran mayora de casos esto se limita a proporcionar una contrasea por parte de quien pretende acceder al recurso correspondiente, cosa que funciona bien en un ambiente seguro en el que todos estamos de acuerdo en no ir ms all de este mecanismo. Sin embargo esto no siempre es cierto (y menos en Internet.) Son muchos los mecanismos que puede emplear un hacker para "capturar" las contraseas de usuarios reales, as como para "adivinar" las mismas. Otros esquemas pretenden ser ms seguros basndose en el anlisis de la direccin de red de quien intenta conectarse, pero de igual modo los hackers pueden "simular" una direccin de red sin mayores inconvenientes. En tanto los ataques son cada vez ms sofisticados, es de rigor que la autenticacin tambin sea cada vez ms sofisticada, lo cual implica abandonar para siempre diversos mecanismos estndar muy arraigados. El ejemplo ms paradigmtico tal vez sea el comando "telnet" de los sistemas Unix, utilizado para obtener una sesin en un sistema remoto. Este comando se distribuye (y se seguir distribuyendo sin duda) en prcticamente todas las encarnaciones de los sistemas Unix y sus clones (como Linux.) Es tan popular y til que incluso los sistemas Windows lo proporcionan. Sin embargo, ningn administrador serio recomendara su uso para una conexin remota, y quiz tampoco al interior de la red. La razn estriba en que toda la informacin de autenticacin (el nombre de usuario y su contrasea) viaja sin encriptacin tal cual es, y cualquier persona con acceso a un nodo intermedio o al canal de la conexin puede extraer esta informacin con relativa facilidad. Actualmente diversos productos y estndares promueven la seguridad en la autenticacin. Como muestra podemos mencionar a SSH, S/Key , Kerberos, Tcpwrappers, etc. 7. No usar la configuracin "estndar" Esto se puede considerar una generalizacin de la recomendacin anterior. Por lo general los sistemas operativos y las aplicaciones se instalan con una configuracin determinada y de carcter genrico. En muchos casos el administrador no tiene necesidad de modificarla pues el sistema aparentemente funciona bien. Sin embargo, los atacantes al no tener conocimiento de la configuracin de nuestro sistema, asumen que sta es justamente la "estndar", y programan sus ataques basados en dicha asuncin. Muchos administradores (y sus jefes) pretenden elevar la seguridad tan slo a costa de comprar un producto costoso. Imaginmonos una ciudad en la que todas las casas comprar un mismo modelo de cerradura. Entonces lgicamente los ladrones se dedicarn sin parar a conseguir la llave correspondiente que les abrir las puertas de todas las casas. Ahora imaginemos otra ciudad en la que todos los habitantes son cerrajeros. Seguramente los ladrones dejarn de pensar en las llaves y a no ser que encuentren otro mecanismo distinto, tendrn que mudarse. 8. La seguridad hacia el interior Algunos reportes han puesto de relieve que en una gran cantidad de casos la mayor amenaza de ataques al sistema no proviene de fuera, sino que parte desde el interior de la organizacin. Muchos ataques exitosos desde el exterior han necesitado de cierta ayuda inicial activada en el interior de la organizacin, donde por lo general nadie sospecha de este tipo de prcticas.

Por tanto, el anlisis de riesgos debe incluir posibles ataques originados en el interior, incluyndose el robo de contraseas, la modificacin de archivos de configuracin, la desactivacin de las barreras de proteccin, etc. Un caso muy comn de este tipo de ataque lo constituye el trabajador despedido o castigado que decide tomar venganza. Antes de retirarse definitivamente puede efectuar este tipo de tareas maliciosas e incluso ponerse en combinacin con un atacante externo. En ciertos casos la simple introduccin intencional de un virus puede acarrear efectos devastadores. La nica manera de reducir el riesgo en estos casos, consiste en planificar el acceso al sistema de modo tal que ningn elemento crtico dependa de una sola persona. Dicho de otro modo, para daar un sistema, no debe bastar con un nico individuo disconforme. Esto muchas veces no es posible con los sistemas operativos comerciales actuales (por ejemplo, con las estaciones Windows 9x) y se hace an ms difcil si el despedido es el administrador! Algunos sistemas intentan por tanto dividir las responsabilidades en diversos administradores, pero en el sector comercial todava falta mucho camino por recorrer. Los usuarios de Linux podran interesarse en el sistema LIDS a fin de implementar esta recomendacin. 9. Educar a los usuarios Una de las mayores ayudas que puede recibir un hacker que intenta infiltrarse en el sistema de una organizacin consiste en obtener informacin acerca de ste. En este sentido, las prcticas empleadas por el atacante comprenden muchas veces la interaccin encubierta con los usuarios de la organizacin a los cuales se les extrae (sin que tomen conciencia de esto) una serie de datos tiles para el hacker. El caso ms evidente consiste en obtener "como jugando" una contrasea de parte de este incauto. Y ciertamente las contraseas de los usuarios comunes suelen ser muy malas, por lo que pueden liberarlas inadvertidamente al interlocutor en medio de una conversacin aparentemente inocente. Esto se suele denominar "Ingeniera Social". La nica forma de combatir esto es con educacin para los usuarios. Por ejemplo, es necesario hacer que ellos sean conscientes de este tipo de ataque (o entrevista), y que una de las mejores medidas a tomarse es el uso de contraseas suficientemente complicadas como para que no surjan de improviso en cualquier dilogo. Otra recomendacin (o norma obligatoria si se desea) consiste en que los usuarios no divulguen detalles acerca de la configuracin del sistema. Esta es una prctica increblemente extendida: Auxiliares, programadores, ingenieros, e incluso administradores, que en su deseo de hacer alarde del "sper sistema" que utiliza su empresa, empiezan de pronto a nombrar todos y cada uno de sus componentes, tanto de hardware como de software, con nmero de versin incluido. Esto puede ser inmediatamente aprovechado por el atacante, pues empezar a "disparar" los ataques ya conocidos para ese hardware/software especfico. 10. No confiar (totalmente) en nosotros mismos Esto puede sonar extrao, sin embargo lo nico que quiero indicar es la necesidad de que otra persona verifique la seguridad de nuestro sistema. Como se sabe, existen empresas consultoras especializadas en auditar nuestra organizacin con este fin. Si esta ltima opcin no es posible (por ejemplo, por el costo involucrado) entonces es de rigor solicitar a otro administrador o ingeniero que verifique las medidas que hemos considerado. En sistemas y redes complejas es muy posible que una sola persona (nosotros) hayamos dejado pasar alguna puerta insegura. Mientras ms personas verifiquen nuestro trabajo, habr ms probabilidades de que ste est adecuadamente realizado. Esta es la idea que est detrs de mucho software Open Source, siendo el Kernel de Linux el caso ms conspicuo. Naturalmente evitaremos mostrar estos detalles a personas ajenas a la organizacin, a fin de disminuir el conocimiento que se tiene en el exterior acerca de nuestro sistema. 11. Ejecutar slo los servicios imprescindibles

Algunas personas tienen la mana de instalar los sistemas con la mayor cantidad posible de opciones que puedan entrar en el disco duro. Los administradores de sistemas seguros deben ir exactamente en sentido inverso: en un sistema de alto riesgo es de rigor que se ejecute nicamente lo imprescindible. El ejemplo ms conocido corresponde a los servicios de red, los cuales muchas veces vienen configurados para estar activos tan pronto como se instala un sistema operativo, crendose automticamente nuevas oportunidades para los atacantes. El administrador debera asegurarse de que slo est instalado lo imprescindible para que el sistema siga en operacin. Debe descartar incluso el software aparentemente ms inofensivo. Recuerdo haber ledo de un caso en el cual el sistema de manuales de Solaris tena una vulnerabilidad explotable que permita a cualquier usuario ejecutar programas con mayores privilegios. Sistemas que en apariencia no tienen nada de riesgosos han presentado serias amenazas para la seguridad, como por ejemplo, las conexiones X Window, las libreras compartidas, los mdulos del kernel, etc. 12. Descargas de software de Internet Como regla general, el software no debera ser descargado de Internet, sino adquirido de una fuente confiable. Sin embargo en muchos casos esto es imprescindible por lo que deberamos seguir algunas reglas mnimas para no terminar descargando un virus o un "caballo de Troya". En primer lugar, debemos asegurarnos que el software que descargamos es realmente lo que hemos pretendido descargar. La idea es que un atacante podra modificar los datos que estamos recibiendo e introducir modificaciones en aquello que descargamos. Luego nosotros confiadamente ejecutamos el archivo en cuestin y... la historia es conocida. Para evitar esto, cada vez con mayor frecuencia los portales de descarga incluyen una serie de alternativas para verificar que lo que hemos descargado no ha sido alterado. Un mtodo comn consiste en el "checksum MD5" que el usuario debera aplicar a todo archivo que descargue, a fin de obtener una especie de "firma" que ha de coincidir con la que se anuncia en el portal. Es asimismo muy recomendable que los portales de descarga utilicen certificados digitales, de modo que no seamos presas de un portal ficticio implementado por atacantes (esto ltimo es realmente es muy difcil, pero no imposible.) 13. Mantener contacto con el proveedor de lneas de comunicacin Diversos problemas pueden aparecer en las comunicaciones desde nuestra red hacia el exterior en los cuales slo el proveedor del enlace puede ayudarnos. Ciertos tipos de ataques necesitan de la participacin de uno o ms proveedores de Internet para paliarlos, como son ciertos tipos de ataque DoS (Deny of Service) ante los que nuestro firewall podra quedar indefenso. Slo mediante el concurso de uno o ms nodos de alto nivel del Internet se podra bloquear al atacante. Por suerte los ataques ms sofisticados de este tipo no son muy frecuentes 14. No permitir conexiones directas desde la red interna a Internet Asumimos que en Internet estn los malos, y por tanto nuestra red interna no debera tomar contacto con ellos. Sin embargo el Internet es irresistible e imprescindible para muchas personas de nuestra organizacin, por lo que debemos buscar algn mecanismo de proteccin. Una de las soluciones ms generalizadas a este problema la constituyen los sistemas denominados proxy. En este caso, los usuarios de nuestra red local (a los que protegemos), se conectan aparentemente a Internet, pero realmente lo hacen hacia nuestro programa proxy. La funcin de ste es bsicamente conectarse a Internet en beneficio de los usuarios internos que lo solicitan. El resultado es que los posibles atacantes observarn al proxy conectndose, pero no podrn acceder a la red interna. Obviamente nos aseguraremos que el proxy est bien seguro. Esto es ms sencillo que cuidar a cada estacin con usuarios incautos y sus sistemas operativos inseguros. En resumen: cuando sea posible, use proxy para dar acceso a Internet para la red interna. Los proxys pueden presentar otras ventajas, como ahorro del ancho de banda y mayor velocidad de acceso a las pginas web ms populares (proxy-cach.)

15. Vigilancia La vigilancia del buen funcionamiento del sistema es un asunto ms complicado de lo que parece. El problema es que los ataques frecuentemente estn disfrazados de conexiones ms o menos vlidas, y por otro lado, los sistemas de cmputo normalmente no avisan cuando son alterados, a no ser que esto se haya establecido de antemano. Los ataques generalmente tratan de aparentar que no ha ocurrido nada, a fin de conseguir hacer ms y ms modificaciones sin ser detectados y detenidos. Todo esto obliga a considerar de antemano ciertos indicadores que nos ayuden a determinar si un sistema ha sido comprometido o est en proceso de serlo. Esto en ciertos casos puede requerir mucha sagacidad y un profundo conocimiento de los mecanismos internos del sistema, as como la activacin de una mayor descripcin de eventos. Pero generalmente este anlisis no se pone en prctica hasta que los sntomas aparecen y el ataque ya est muy avanzado, lo que ha motivado el incremento de productos que intentan adelantarse y dar aviso cuando algo anda mal. A estos sistemas se les conoce como sistemas de deteccin de intrusiones (IDS o NIDS.) El administrador precavido har bien en considerarlos como parte de las medidas de seguridad. 10. CONCLUSIONES Actualmente no existe un sistema seguro sino que es un sistema fiable. Unos de los sistemas de autenticacin en los sistemas distribuidos recomendable es el Kerberos. La seguridad de un sistema distribuido no hay que tomarse a la ligera, sino que hay que aplicar todas las medidas de seguridad posibles. 11. Bibliografa [1]: http://www.sc.ehu.es/acwlaroa/SDI/Apuntes/Seguridad.pdf [2]: mx.geocities.com/nancy_aguas/seguridad.pdf [3]: Seguridad en Unix y Redes Versin 2.0 Antonio Villaln Huerta [4]: Recomendaciones de seguridad en sistemas distribuidos de cmputo - (V0.11) Diego Bravo Estrada. [5]: Tanenbaum Capitulo 7 ~ 8

S-ar putea să vă placă și