Recomendaciones de Seguridad en Sistemas de Cómputo Distribuido

Historial de revisiones
Revisión 1.027/3/2002
Diego Bravo Estrada
Primera versión
Revisión 1.04/4/2010
Diego Bravo Estrada
Revisión de las recomendaciones (originalmente publicado en blog de Americati)

Tabla de contenidos

1. Introducción
2. Las Recomendaciones
2.1. Efectuar un análisis de riesgos
2.2. Lo más valioso debe alejarse de lo más vulnerable
2.3. Mantener las cosas simples
2.4. Emplear seguridad en distintos niveles
2.5. Encriptar tanto como sea posible
2.6. No confiar en la autenticación estándar
2.7. La seguridad hacia el interior
2.8. Educar a los usuarios
2.9. No confiar (totalmente) en nosotros mismos
2.10. Ejecutar sólo los servicios imprescindibles
2.11. Mantenerse al día con las actualizaciones
2.12. Escaneos regulares
2.13. Descargas de software de Internet
2.14. Establecer planes de contingencia y sistemas de respaldo
2.15. Mantener contacto con el proveedor de líneas de comunicación
2.16. Uso de red perimétrica o zona desmilitarizada
2.17. Prácticas de programación segura
2.18. Vigilancia
2.19. Establecimiento de políticas
3. Conclusión
4. Agradecimiento
A. Revisión al 2010
Referencias

Resumen

Esto es una introducción rápida a un conjunto de recomendaciones compiladas en diversos lugares con el objetivo de mejorar la seguridad en ambientes de cómputo típicos. Este documento fue confeccionado originalmente en 2002. Se ha eliminado la recomendación "No usar la configuración estándar" pues (a mi criterio) es obsoleta. De igual modo, "No permitir conexiones directas desde la red interna a Internet" (y su alternativa) parece ser poco comprensible para la audiencia.

1. Introducción

Desde la última vez que publicara este artículo, la seguridad informática se ha tornado un asunto de primordial importancia no sólo para los profesionales de la computación, sino también para el (frustrado) público en general.

No obstante el cuantioso dinero invertido, y las incontables promesas de los vendedores, los sistemas continúan siendo inseguros tanto a nivel de aplicación, sistema operativo y red. Es el precio a pagar por una mayor complejidad[COMPLEX] (para soportar mayores prestaciones) pero también ante el descuido de los desarrolladores (de software y hardware) que anteponen el interés comercial a la calidad del producto y la satisfacción a largo plazo de sus clientes.

Este texto pretende presentar brevemente algunas recomendaciones dirigidas a los administradores e implementadores de redes informáticas, y lo he preparado a modo de síntesis breve a partir de diversos materiales difuminados en Internet. No pretendo hacer un listado exhaustivo de las responsabilidades del administrador ni explicar detalles acerca de la implementación de las recomendaciones, aunque sugiero algunos puntos de partida para esto.

2. Las Recomendaciones

2.1. Efectuar un análisis 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 cuáles involucran más o menos riesgo. Esto concluirá 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 función directa a las pérdidas que ocasionaría el que éste deje de operar, así como en función de cuán 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 información representa para una organización; pero una simple PC Windows de la misma organización conectada directamente al Internet (sin firewall/proxy de por medio) también lo representa, debido a que puede ser objeto de un ataque desde el exterior, con el posible riesgo de fácil propagación hacia otros computadores de nuestra red.

El riesgo no es fácil de cuantificar, siendo en general un estimador subjetivo. A modo de ejemplo podríamos plantear una fórmula como la que sigue:

RIESGO(componente) = P * V

Donde P=pérdida, es la pérdida en dinero que implicaría la inoperatividad del componente hasta su reparación, aunque se pueden agregar otros estimadores como el desprestigio ante nuestros clientes. A veces ayuda considerarlo como "el valor" que representa para la organización. V=vulnerabilidad, es tanto o más subjetiva puesto que no hay una manera segura de establecer para todos los casos si los supuestos mecanismos de protección (del componente) son o no realmente confiables. Así por ejemplo, podríamos suponer que la vulnerabilidad de ciertos documentos importantes es muy baja, puesto que están protegidos por cierto antivirus. Sin embargo, esto realmente estará en función de diversas características del antivirus, como pueden ser: recientes actualizaciones, ejecución automática, capacidad de eliminar virus locales, licencias no caducadas, configuración adecuada, etc. Pero por algo se debe comenzar. Por ejemplo, se puede asignar números como 1, 2, 3, 4, para señalar una vulnerabilidad mínima, regular, importante y peligrosa, respectivamente. Para una extensa (y compleja) explicación, ver [RIESGO].

Esto normalmente demanda el acopio de mucha información, 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 análisis.

Téngase en cuenta que las "fórmulas" presentadas son totalmente arbitrarias y pueden ser modificadas convenientemente de acuerdo a los objetivos concretos. Por ejemplo, un analista (con conocimientos de estadística) podría formular el riesgo total como la "media armónica" de los riesgos individuales, etc. con las ventajas y desventajas que esta medida involucra.

2.2. Lo más valioso debe alejarse de lo más vulnerable

En la fórmula del "riesgo individual" propuesta arriba, es evidente que los componentes de nuestro sistema con algo valor y alta vulnerabilidad serán 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 pérdida 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 electrónico deben dar cara a Internet (siendo vulnerables en principio) y a la vez manejar información muy "costosa" (como números de tarjetas de crédito.) Esto los convierte en un sistema de muy alto riesgo.

Sin embargo es casi universal la separación que se efectúa entre los componentes dedicados a dar cara a Internet (como los Web Servers) y los componentes que manipulan la información comercial (generalmente sistemas DBMS.) En términos prácticos, esto significa que el hacker no puede acceder directamente al DBMS (lo que es catastrófico), y sólo podría atacar al Web Server, lo cual es más fácil de reparar.

Juguemos con los números siguiendo las ideas expuestas más arriba. Suponiendo que los datos relacionados al negocio valen para nosotros $50000, y están en un computador donde corre un Web Server IIS que no ha sido parchado adecuadamente. Entonces el riesgo sería:

R total = 50000 x 5 = 250000

Supongamos ahora que los datos están en otro computador "mínimamente vulnerable" (con V=1) adecuadamente aislado del Web Server (que todavía no ha sido parchado). La pérdida por una interrupción del servicio del Web Server, por día 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

2.3. Mantener las cosas simples

Un sistema complejo es más difícil de asegurar y potencialmente proporciona una mayor cantidad de puertas abiertas a los atacantes[COMPLEX]. En general, es recomendable intentar dividir el problema mediante la simplificación de la configuración, 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 práctico efectuar un profundo trabajo de seguridad en las estaciones más allá de la instalación del antivirus (mal necesario en dichos sistemas), puesto que por un lado, son muchas, y por otro, los usuarios en ciertos ambientes pueden y deben modificar la configuración y/o instalar software adicional.

En estos casos es aconsejable centrarnos en un único punto que centralice la seguridad de todas las estaciones. Una configuración de red que obligue a que todo su tráfico pase a través de un gateway permitiría crear un único punto de control para todas las estaciones, con lo cual simplificamos la administración.

Todo esto generalmente conlleva a situaciones en las que hay que hacer un compromiso. Por ejemplo, en la recomendación 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.

2.4. Emplear seguridad en distintos niveles

Esto se puede expresar más sencillamente como: no confiar el sistema a un único mecanismo de seguridad.

La información fluye a través de los distintos componentes y/o capas del sistema y son muchas las instancias en las que se puede mejorar su seguridad. La recomendación 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 conexión a Internet.) Por tanto se invierte esfuerzo y dinero en controlar este único punto bajo la asunción 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 organización
  • El sistema que controla la "puerta" siempre puede fallar

Esto obliga a implementar la seguridad no solamente en el "único punto evidentemente vulnerable", sino en todos los lugares por donde fluye la información al interior de cada componente involucrado.

Un ejemplo típico 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 "capas", podríamos pensar qué hacer en este gateway para mejorar la seguridad. Son 7 las capas OSI y podríamos intentar añadir instancias de control adicionales a las mencionadas. Por ejemplo, en la capa 7 (aplicación) es frecuente y muy recomendable el empleo de proxy’s HTTP. Algunos firewalls proporcionan control a nivel de la capa 2 (específicamente, del MAC Address.)

Sin embargo, esto se debe complementar con otras medidas que van más allá del gateway y que se implementan a lo largo de todo el sistema (pudiéndose considerar como niveles o "capas" adicionales), tales como redes perimétricas, el uso de encriptación, etc.

El lado negativo de esta recomendación es:

  1. Toma mucho más tiempo implementar medidas poco obvias
  2. Cuando se desea modificar la configuración (por ejemplo, para permitir tráfico de un nuevo tipo) el trabajo necesario se incrementa

2.5. Encriptar tanto como sea posible

La encriptación es un tema complejo pero cuya implementación resulta cada vez más sencilla conforme aparecen más productos.

En general, los canales de comunicación más vulnerables o de mayor cercanía al público requieren una encriptación "más fuerte", es decir, más difícil de descifrar por los curiosos o atacantes. Cierta información conlleva más riesgo que otra, y por tanto requerirá un nivel de encriptación diferenciado.

Las herramientas capaces de hacer esto son muchas, dependiendo del contexto en que nos encontremos. Por ejemplo, los sistemas DBMS más avanzados incorporan la encriptación como una opción normal para los datos almacenados, generalmente bajo esquemas propietarios.

La tecnología de encriptación de información destinada a pasar a través de la red ha evolucionado bastante, haciéndose popular el término VPN [VPN1], [VPN2] para hacer referencia a canales que encriptan la información de un modo más o menos transparente.

Ciertas aplicaciones estándar han recibido soluciones de encriptación también estándar. El caso del Web encriptado bajo SSL (HTTPS) junto con la industria de certificados digitales es el caso más conspicuo. De igual modo los estándares para correo electrónico PGP (o derivados) y S/MIME son integrados cada vez con mayor frecuencia en las aplicaciones de los usuarios finales (aunque esto se ha desacelerado relativamente.)

Retornemos al principio. En nuestra organización deberíamos encriptar todo lo que sea posible. La razón de esto es evidente si de lo que se trata es de enviar un mensaje privado por Internet. Sin embargo, al interior de la organización la encriptación puede ayudar también. Por ejemplo, es usual que cierta información sea manejada exclusivamente por un número reducido de personas (los contratos salariales, por poner un caso.) Un caso más dramático se presenta cuando un hacker ha logrado infiltrarse en la organización: si la información está encriptada, los datos que robe le serán inútiles dado que no posee las claves correspondientes.

Naturalmente hay que sopesar los inconvenientes que trae la encriptación en términos de incomodidad de uso, costo de licencias, ciclos de CPU, etcétera; con el hecho de que cierta información es definitivamente de carácter público y por tanto no tiene sentido que esté encriptada. Por ejemplo, la información que se publica en Internet vía el Web Server de la empresa. Uno de los problemas más importantes (y que se suele soslayar) es el de la administración de las claves: quién las almacena? en qué medio? cada cuándo deben ser regeneradas? qué hacer si el encargado no está disponible?

Una fuente (newsletter) muy interesante sobre este tema se puede obtener en [CRIPT].

2.6. No confiar en la autenticación estándar

Las redes locales, y por extensión, el Internet, NO fueron diseñados en principio para ser seguros. La mayoría del software y hardware creados hasta incluso mediados de los años 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 crítico es lo concerniente a la autenticación de los accesos. En la gran mayoría de casos esto se limita a proporcionar una contraseña 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 más 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 contraseñas de usuarios reales, así como para "adivinar" las mismas. Otros esquemas pretenden ser más seguros basándose en una mayor "complejidad"; por ejemplo, el análisis de la dirección de red de quien intenta conectarse, pero de igual modo los hackers pueden "simular" una dirección de red sin mayores inconvenientes.

En tanto los ataques son cada vez más sofisticados, es de rigor que la autenticación también sea cada vez más sofisticada, lo cual implica abandonar para siempre diversos mecanismos estándar muy arraigados. Un ejemplo paradigmático tal vez sea el comando "telnet" de los sistemas Unix, utilizado para obtener una sesión en un sistema remoto. Este comando se distribuye (y se seguirá distribuyendo sin duda) en prácticamente 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, ningún administrador serio recomendaría su uso para una conexión remota, y quizá tampoco al interior de la red. La razón estriba en que toda la información de autenticación (el nombre de usuario y su contraseña) viaja sin encriptación tal cual es, y cualquier persona con acceso a un nodo intermedio o al canal de la conexión puede extraer esta información con relativa facilidad.

Actualmente diversos productos y estándares promueven la seguridad en la autenticación. Como muestra podemos mencionar a SSH [SSH], S/Key [SKEY], Kerberos [KERB], Tcpwrappers, etc.

2.7. La seguridad hacia el interior

Muchos reportes y artículos [INTER2] 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 organización. Muchos ataques exitosos desde el exterior han necesitado de cierta ayuda inicial activada en el interior de la organización, donde por lo general nadie sospecha de este tipo de prácticas.

Por tanto, el análisis de riesgos debe incluir posibles ataques originados en el interior, incluyéndose el robo de contraseñas, la modificación de archivos de configuración, la desactivación de las barreras de protección, etc.

Un caso muy común 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 combinación con un atacante externo. En ciertos casos la simple introducción 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 ningún elemento crítico dependa de una sola persona. Dicho de otro modo, para dañar un sistema, no debe bastar con un único individuo disconforme.

Esto se hace especialmente difícil si el despedido es un administrador' Algunos sistemas intentan por tanto dividir las responsabilidades en diversos administradores, pero en el sector comercial todavía falta mucho camino por recorrer. Como es usual, la solución existe en el papel (y en la mente de abogados reguladores que nunca aprendieron a contar en base 2), pero en la práctica los administradores necesitan saltar esta clase de norma para satisfacer los requerimientos que les imponen.

2.8. Educar a los usuarios

Una de las mayores ayudas que puede recibir un hacker que intenta infiltrarse en el sistema de una organización consiste en obtener información acerca de éste. En este sentido, las prácticas empleadas por el atacante comprenden muchas veces la interacción encubierta con los usuarios de la organización a los cuales se les extrae (sin que tomen conciencia de esto) una serie de datos útiles para el hacker. El caso más evidente consiste en obtener "como jugando" una contraseña de parte de este incauto. Y ciertamente las contraseñas de los usuarios comunes suelen ser muy malas, por lo que pueden liberarlas inadvertidamente al interlocutor en medio de una conversación aparentemente inocente. Esto se suele denominar "Ingeniería Social".

Uno de las acciones destinadas a reducir este problema consiste en la educación 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 contraseñas suficientemente complicadas como para que no surjan de improviso en cualquier diálogo.

Otra recomendación (o norma obligatoria si se desea) consiste en que los usuarios no divulguen detalles acerca de la configuración del sistema. Esta es una práctica increíblemente extendida: Auxiliares, programadores, ingenieros, e incluso administradores, que en su deseo de hacer alarde del "super sistema" que utiliza su empresa, empiezan de pronto a nombrar todos y cada uno de sus componentes, tanto de hardware como de software, con número de versión incluido.

Esto puede ser inmediatamente aprovechado por el atacante, pues empezará a "disparar" los ataques ya conocidos para ese hardware/software específico.

Hasta hace algún tiempo se tenía cierta esperanza en que la educación resolvería muchos de estos problemas, pero la experiencia ha sido contraria. Los usuarios finales rara vez toman en cuenta estas consideraciones o simplemente no las comprenden. Para los usuarios finales quizá la mejor recomendación es que simplemente no custodien imformación importante; por ejemplo, si divulgan sus contraseñas, éstas deberían ser inútiles desde el exterior o desde un computador distinto al asignado al usuario.

2.9. No confiar (totalmente) en nosotros mismos

Esto puede sonar extraño, 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 organización con este fin. Si esta última opción 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 más personas verifiquen nuestro trabajo, habrá más probabilidades de que éste esté adecuadamente realizado. Esta es la idea que está detrás de mucho software Open Source, siendo el Kernel de Linux el caso más conspicuo.

Naturalmente evitaremos mostrar estos detalles a personas ajenas a la organización, a fin de disminuir el conocimiento que se tiene en el exterior acerca de nuestro sistema.

2.10. Ejecutar sólo los servicios imprescindibles

Algunas personas tienen la manía de instalar los sistemas con la mayor cantidad posible de opciones que puedan alcanzar en los discos duros. 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 más conocido corresponde a los servicios de red, los cuales muchas veces vienen configurados para estar activos tan pronto como se instala un sistema operativo, creándose automáticamente nuevas oportunidades para los atacantes.

El administrador debería asegurarse de que sólo esté instalado lo imprescindible para que el sistema siga en operación. Debe descartar incluso el software aparentemente más inofensivo. Recuerdo haber leído de un caso en el cual el "sistema de manuales" de Solaris tenía una vulnerabilidad explotable que permitía a cualquier usuario ejecutar programas con mayores privilegios.

Software "accesorio" que en apariencia no tiene nada de riesgoso, ha presentado serias amenazas para la seguridad, como por ejemplo, las conexiones de X Window, las librerías compartidas, los módulos del kernel, etc.

2.11. Mantenerse al día con las actualizaciones

Afortunadamente la industria ha avanzado bastante en este sentido (probablemente por la oportunidad comercial presentada a los vendedores.) El software, pese a los esfuerzos y la propaganda, continuará teniendo errores y puertas ocultas. Y la tendencia sigue en aumento con la complejidad del mismo. Esto implica que los vendedores deberán proporcionar parches o versiones mejoradas a sus clientes cada vez que se descubra alguna vulnerabilidad.

En sistemas operativos que involucran muchos componentes (como casi todos en la actualidad) es de esperarse que las vulnerabilidades surjan con una frecuencia extremadamente alta. Desde el punto de vista de la casa de software, esto significaría incomodar con demasiada frecuencia a los administradores (que se convertirían en eternos "parchadores") por lo que usualmente se distribuyen parches a intervalos relativamente extensos y que corrigen de un solo golpe todas vulnerabilidades halladas hasta la fecha, generalmente acompañadas de aditamentos al sistema de modo tal que no luzca como un simple parche (piénsese en los "service pack".) Obviamente, los administradores que se limitan a esperar el lanzamiento del próximo super-parche corren un gran riesgo en este lapso.

En un ambiente de alta seguridad esto no es recomendable: los parches de cada componente deben aplicarse tan pronto como sea posible. Por tanto, si no deseamos que la administración se convierta en un parchar y parchar, deberíamos asegurarnos que nuestro sistema realmente tenga pocos componentes (y por tanto, menos necesidad de parches.) Como se indicó en la recomendación anterior, en todo sistema seguro, lo más indicado es evitar que se ejecuten servicios innecesarios. He aquí un motivo más para seguir esta regla.

Otro corolario de esto es el establecimiento de una rigurosa política de actualización, para lo cual normalmente existen diversos canales en Internet proporcionados por el vendedor. De igual modo, es menester mantenerse informado acerca de las nuevas vulnerabilidades descubiertas, para lo cual existen diversas publicaciones electrónicas especializadas como la que proporciona [CERT].

2.12. Escaneos regulares

Un "scanner" es un programa que intenta indagar acerca de qué servicios proporciona un computador de la red. Una vez que se conocen estos servicios, un atacante puede centrar sus ataques hacia los mismos.

Esta herramienta es empleada regularmente por los hackers. Sin embargo, la podemos emplear en nuestro propio beneficio, puesto que así nosotros podremos descubrir si hemos dejado ciertas puertas abiertas. El scanner sólo se limita a proporcionar esta información y por tanto su uso es seguro e inofensivo.

El "escaneo" se debería hacer desde fuera de nuestra red (por ejemplo, desde un computador de Internet), así como desde su interior contra nuestras estaciones de trabajo [NMAP].

2.13. Descargas de software de Internet

Como regla general, el software no debería ser descargado de Internet, sino adquirido de una fuente confiable. Sin embargo en muchos casos esto es imprescindible por lo que deberíamos seguir algunas reglas mínimas 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 podría modificar los datos que estamos recibiendo e introducir modificaciones en aquello que descargamos. Luego nosotros confiadamente ejecutamos el archivo en cuestión 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 método común consiste en el "checksum MD5" que el usuario debería 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 (phishing). Esto ocurre típicamente cuando se trata de conectarse a sitios web que mantienen información comercial crítica (Paypal, ebay, bancos, etc.)

2.14. Establecer planes de contingencia y sistemas de respaldo

No existe ninguna garantía de que nuestro sistema sea invulnerable. Más allá de las medidas que podamos adoptar, siempre existirá la posibilidad de ser atacados. Esto nos obliga a tener presentes ciertas medidas de contingencia traducidas preferentemente en políticas de seguridad bien establecidas.

En otras palabras, debemos imaginarnos sucesivamente un conjunto de escenarios de ataques exitosos. ¿Qué hacemos si…

  • Sospechamos que un hacker está atacando el firewall
  • Sospechamos que ya ha tomado control del firewall
  • Comprobamos que ya ha tomado control del firewall
  • Sospechamos que el servidor de base de datos ha sido alterado
  • Descubrimos que las PCs Windows han sido infectadas con un virus

Las posibilidades evidentemente son muchas, y las acciones a tomarse también. Sin embargo es mejor tener esto por escrito a no tener absolutamente nada el día que las quejas sobre sucesos extraños en el sistema empiecen a acaecer.

Ahora bien, cualquier administrador medianamente decente tendrá establecida una política de backups para situaciones críticas. En el caso de ataques a través de la red las consecuencias pueden obligar a requerir de estos backups, por lo que es imperativo que éstos estén actualizados y preparados para su uso.

Este tipo de análisis no debe ser extraño puesto que los sistemas pueden tener problemas por múltiples motivos que no tienen nada que ver con los ataques (por ejemplo, un fallo de hardware) que deberían también poseer planes de contingencia.

Los administradores más minuciosos podrían efectuar simulacros de desastres: No hay nada más frustrante en medio de un desastre que descubrir que los backups diarios nunca se grabaron por problemas en la unidad de cinta.

2.15. Mantener contacto con el proveedor de líneas de comunicación

Diversos problemas pueden aparecer en las comunicaciones desde nuestra red hacia el exterior en los cuales sólo el proveedor del enlace puede ayudarnos. Ciertos tipos de ataques necesitan de la participación de uno o más proveedores de Internet para paliarlos, como son ciertos tipos de ataque DoS (Deny of Service) ante los cuales nuestro firewall podría quedar indefenso. Sólo mediante el concurso de uno o más nodos de alto nivel del Internet se podría bloquear al atacante [DOS1].

En [SEGINT] se puede leer una revisión general acerca de la seguridad de los sistemas en Internet.

2.16. Uso de red perimétrica o zona desmilitarizada

Si Ud. tiene servidores que dan cara a Internet, entonces deberá permitir ciertas conexiones de el exterior a sus servidores. Esto es problemático y debe ser controlado.

Muchos especialistas recomiendan mantener estos servidores protegidos mediante firewalls, pero a la vez separados de la red interna donde se encuentra, por ejemplo, nuestra base de datos. La idea es que estos servidores están en una zona de peligrosidad intermedia protegidos de Internet, pero no al nivel de nuestro sistema más interno. Es por eso que se les suele asignar una red especial independiente denominada "perimétrica" o zona desmilitarizada (DMZ) con la intención de reducir la vulnerabilidad de nuestros datos más importantes mediante el alejamiento de los computadores que son blanco directo de las conexiones exteriores.

2.17. Prácticas de programación segura

Si su organización desarrolla software de cualquier tipo, y en especial, si este software dará cara a Internet, entonces Ud. debería asegurarse de que los desarrolladores conozcan las recomendaciones de seguridad correspondientes al lenguaje de programación o herramienta de desarrollo empleada así como del ambiente (sistema operativo o red) en que se ejecutan. De igual modo los diseñadores de la arquitectura deben considerar la seguridad de la misma desde el principio del proyecto. Los programas que dan cara a Internet son un caso muy especial donde la seguridad reviste aún más importancia a juzgar por las malas experiencias producidas.

Lo bueno en este sentido es el crecimiento de la literatura accesible a los desarrolladores. Lo negativo es que simplemente no la leen (al no entender su importancia.) De igual modo sigue siendo extraño que los administradores/gerentes de las casas de software decidan hacer algo al respecto.

2.18. Vigilancia

La vigilancia del buen funcionamiento del sistema es un asunto más complicado de lo que parece. El problema es que los ataques frecuentemente están disfrazados de conexiones más o menos válidas, y por otro lado, los sistemas de cómputo 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 más y más 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 activación de una mayor descripción de eventos. Pero generalmente este análisis no se pone en práctica hasta que los síntomas 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 detección de intrusiones (IDS o NIDS.) El administrador precavido hará bien en considerarlos como parte de las medidas de seguridad [IDS1], [SNORT], [TRIP] pero ha de comprender que requieren una considerable dedicación en cuanto a su configuración para que realmente aporten valor.

2.19. Establecimiento de políticas

Para terminar, una recomendación que en cierto modo engloba a todas las anteriores. El establecimiento de políticas corresponde a un mecanismo que permite asegurar que la seguridad se mantenga en todas las situaciones y se deriva del "compromiso con la seguridad" de la organización. La idea detrás de todo esto es que nadie puede saber de antemano lo que piensa el administrador o el encargado de la seguridad sin ser informado. Muchas organizaciones no tienen esto en cuenta y se da el caso en que un gerente se limita a reunir a los empleados y decirles "no hagan nada que pueda atentar contra la seguridad de la organización, o serán castigados …" El problema es que la gente normalmente no piensa en términos de seguridad sino en términos de cumplimiento de obligaciones y logro de resultados, y el camino más corto no siempre es el más seguro.

Las políticas justamente intentan abordar estos problemas mediante el establecimiento de normas que han de cumplir todos los miembros de la organización. Las políticas son documentos destinados a personas con responsabilidades claramente definidas y detallan cuidadosamente su alcance y aplicación. Explican tanto procedimientos informáticos como logísticos en términos de la jerarquía de la organización.

Una ventaja colateral es la posibilidad de identificar responsables en problemas (¡y así salvar su cabeza el administrador')

El cumplimiento de las políticas pasa por hacer tomar consciencia de su importancia a los destinatarios, para lo cual es imprescindible que su aplicación sea impulsada desde el más alto nivel jerárquico. Es recomendable, por ejemplo, que sea leída y firmada a modo de compromiso por parte del destinatario, y su difusión puede estar acompañada por charlas informativas por parte del administrador o del staff responsable.

La actualización responsable de las políticas es crítica para su cumplimiento, por lo que en ciertos casos se indica la designación de un responsable de las mismas o incluso de un equipo responsable, especialmente durante su elaboración y establecimiento inicial.

Las políticas no deberían escribirse en un lenguaje oscuro y técnico, sino adecuado a la audiencia correspondiente (que suelen ser usuarios finales). Ocasionalmente parecen contener frases huecas (a las que nadie da importancia) simplemente por no ser adecuadamente explicadas (los ejemplos ayudan mucho.)

3. Conclusión

Brevemente hemos pasado revista a un conjunto de recomendaciones genéricas de seguridad que pueden ser aplicadas prácticamente a cualquier red de computadores. No pretendo que sea un listado exhaustivo, y de hecho existen diversas publicaciones especializadas que sin duda trascienden lo expuesto aquí. Tan sólo he pretendido presentar un resumen de lo que a mi juicio es lo más importante.

La seguridad de la red requiere ir más allá de lograr que los sistemas simplemente funcionen bien. Se requiere creatividad, así como un considerable conocimiento de la tecnología involucrada. Una dosis de paranoya puede ser indispensable.

En Internet se puede encontrar numerosas listas con "los pasos" a llevarse a cabo para asegurar la red que pueden resultar útiles al lector [SASB]. Por otro lado, cada plataforma cuenta con muchas recomendaciones de seguridad específicas que es menester conocer. Diversos portales especializados en seguridad proporcionan una fuente invaluable de información que los administradores deberían aprovechar [CERT], [NETSECURITY].

4. Agradecimiento

A las instituciones e individuos que cito, y a quienes me proporcionaron críticas y sugerencias.

A. Revisión al 2010

El texto "Recomendaciones de Seguridad en Sistemas Distribuidos de Cómputo" que originalmente escribí a modo de resumen auxiliar durante un curso que dicté, ha tenido una difusión algo más amplia que la originalmente concebida. Esto de seguro debido a la relativa escacez de documentos similares en español.

Habiendo transcurrido algunos años vale la pena hacerle algunas críticas desde una o más ópticas más alejadas del día a día del administrador del sistema.

Como en la mayoría de aspectos de la vida, las recomendaciones del pasado suelen ser mayormente aplicables al presente; repasemos el documento. Para cada recomendación copio un párrafo relevante, y agrego los comentarios o críticas.

RECOMENDACIÓN 1: Efectuar un análisis 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 cuáles involucran más o menos riesgo."

El documento ilustra una serie de ideas algo inocentes acerca de cómo cuantificar dicho riesgo, las cuales en sí no son incorrectas; sin embargo, su correcta aplicación resulta impráctica debido -en primer lugar- a la dificultad o imposibilidad de estimar los niveles de riesgo por parte del personal a cargo. Cómo estimar el riesgo de un Web Server? Quién lo puede o debe estimar? Debe considerarse para esto el parchado del Web Server? De qué manera se está considerando el riesgo en las aplicaciones que se ejecutan en su interior? y en el sistema operativo que lo aloja?… sin un análisis detallado de esto (que como indico, sospecho que es muy difícil en cualquier organización estándar), el análisis numérico recomendado se convierte en un ejercicio inútil.

Contrarrestar esta situación merece una futura publicación.

RECOMENDACION 2: Lo más valioso debe alejarse de lo más vulnerable. "… en muchos casos no es sencillo disminuir el valor de cierto componente (y por tanto la pérdida en caso de problemas), y tampoco se puede eliminar completamente la vulnerabilidad del mismo …" 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. Los ejemplos proporcionados en el documento son los más evidentes y el sentido común dicta esta norma como obligatoria para hacerle la vida más difícil al hacker, el cual potencialmente accederá a la zona de riesgo.

El problema de todo esto es que la "separación" no necesariamente implica "protección". Siguiendo el ejemplo del documento, un Web Server que separa al Internet de una base de datos puede convertirse en una excelente puerta de acceso a ésta, dado que en la operación diaria la base de datos debe permitirle tales accesos. Es frecuente por tanto encontrar contraseñas (de base de datos) de facil lectura en los Web Servers. Este es un caso obvio en que la separación no proporcionó adecuada protección. En conclusión, la "separación" deberá ir acompañada del establecimiento de medidas complementarias para que tenga sentido.

RECOMENDACION 3: Mantener las cosas simples. "Un sistema complejo es más difícil de asegurar y potencialmente proporciona una mayor cantidad de puertas abiertas a los atacantes. En general, es recomendable intentar dividir el problema mediante la simplificación de la configuración, para así identificar los puntos o rutas de control vulnerables para incrementar la seguridad."

Esta recomendación es puro sentido común, sin embargo, difícilmente aplicable en organizaciones de "personal siempre ocupado". La red se complejiza imparablemente conforme surgen nuevos requerimientos, y nunca queda tiempo ni recursos para simplificar la configuración general (ni se desea sufir interrupciones de servicio por dicho concepto aparentemente improductivo.)

RECOMENDACION 4: Asegurar la seguridad en todos los niveles. "Esto se puede expresar más sencillamente como: no confiar el sistema a un único mecanismo de seguridad."

Esto siempre será válido, pero también adolece de los problemas típicos de la seguridad "excesiva": 1) el acceso autorizado se hace más difícil con lo que el trabajo se entorpece; 2) requiere de más conocimientos de parte de los implementadores; 3) dificulta los cambios en la configuración.

RECOMENDACION 5: Encriptar tanto como sea posible. "La encriptación es un tema complejo pero cuya implementación resulta cada vez más sencilla conforme aparecen más productos."

Tal vez aquí pequé de optimista; la encriptación no debería requerir productos adicionales (que agregan complejidad sin demostrar valor); nadie se quiere responsabilizar de las contraseñas; los usuarios no quieren memorizar o guardar más contraseñas. Podríamos mejorar la recomendación considerando sólo alquel tráfico que nunca debe caer en manos indebidas.

RECOMENDACION 6: No confiar en la autenticación estándar. "… En tanto los ataques son cada vez más sofisticados, es de rigor que la autenticación también sea cada vez más sofisticada, lo cual implica abandonar para siempre diversos mecanismos estándar muy arraigados. El ejemplo más paradigmático tal vez sea el comando telnet de los sistemas Unix."

Podríamos agregar las contraseñas de fábrica en los routers, y otros dispositivos diversos. Esta recomendación obliga a tomar conciencia de que la seguridad está presente en cualquier dispositivo (no sólo en los servidores centrales.)

RECOMENDACION 7: La seguridad hacia el interior. "… 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 organización. Muchos ataques exitosos desde el exterior han necesitado de cierta ayuda inicial activada en el interior de la organización, donde por lo general nadie sospecha de este tipo de prácticas. Por tanto, el análisis de riesgos debe incluir posibles ataques originados en el inte- rior, incluyéndose el robo de contraseñas, la modificación de archivos de configura- ción, la desactivación de las barreras de protección, etc."

Esto ya se ha hecho un lugar común; no requiere más comentario.

RECOMENDACION 8: Educar a los usuarios. "Hasta hace algún tiempo se tenía cierta esperanza en que la educación resolvería muchos de estos problemas, pero la experiencia ha sido contraria. Los usuarios finales rara vez toman en cuenta estas consideraciones o simplemente no las comprenden. Para los usuarios finales quizá la mejor recomendación es que simplemente no custodien imformación importante; por ejemplo, si divulgan sus contraseñas, éstas deberían ser inútiles desde el exterior o desde un computador distinto al asignado al usuario."

No es que la educación al usuario no sirva de nada; simplemente debemos aceptarla como algo falible; de hecho, puede ayudar a reducir el tiempo dedicado a corregir sus errores, pero no a eliminarlos. Por ejemplo, es preferible dar una charla de una hora acerca de virus en attachments y así tener que reformatear un PC con Windows al mes, que no dar la charla y requerir reinstalar diez sistemas Windows cada semana.

RECOMENDACION 9: No confiar (totalmente) en nosotros mismos. "…la necesidad de que otra persona verifique la seguridad de nuestro sistema. Como se sabe, existen empresas consultoras especializadas en auditar nuestra organización con este fin."

Si bien una consultora especializada puede ayudar (especialmente si la organización cliente no tiene ninguna experiencia en seguridad), tengo mis dudas acerca de cómo validar la calidad de dicha consultora (salvo con trabajos anteriores o referencias confiables, jamás con certificaciones); asimismo, la consultora puede ser prestigiosa pero inevitablemente dispondrá de personal de diversa experiencia. Finalmente, ninguna consultora conocerá el sistema de una organización como el propio personal de la organización, por lo que necesariamente se abocará en los aspectos o debilidades más comunes del sector. Eventualmente es el mismo personal interno quien deberá atacar los problemas a detalle día a día.

RECOMENDACION 10: Ejecutar sólo los servicios imprescindibles. "Algunas personas tienen la manía de instalar los sistemas con la mayor cantidad posible de opciones que puedan alcanzar en los discos duros. Los administrado- res de sistemas seguros deben ir exactamente en sentido inverso: en un sistema de alto riesgo es de rigor que se ejecute únicamente lo imprescindible."

Totalmente correcto.

RECOMENDACION 11: Mantenerse al día con las actualizaciones. "Afortunadamente la industria ha avanzado bastante en este sentido (probablemente por la oportunidad comercial presentada a los vendedores.)"

Tener en cuenta que las actualizaciones requieren distintas maneras de aplicación. Por ejemplo, los parches de seguridad en un servidor de cara a internet deben aplicarse de inmediato, mientras que otras correcciones dirigidas a sistemas internos suelen requerir de cierto análisis previo y posiblemente de un periodo de prueba en un ambiente auxiliar. Esto debido a que las "correcciones" suelen introducir nuevos problemas en cualquier plataforma.

RECOMENDACION 12: Escaneos regulares. "Un scanner es un programa que intenta indagar acerca de qué servicios proporciona un computador de la red. Una vez que se conocen estos servicios, un atacante puede centrar sus ataques hacia los mismos."

Esto puede ayudar a detectar problemas obvios de mala configuración, pero en la mayoría de organizaciones con un administrador competente, es poco lo que debería reportar un scaneer; sin embargo, esto no debe crear un falso sentido de seguridad: el escaneo tradicional está destinado a detectar un porcentaje extremadamente pequeño de todos los posibles riesgos latentes.

RECOMENDACION 13: Descargas de software de Internet. "Como regla general, el software no debería ser descargado de Internet, sino adquirido de una fuente confiable."

Esto sigue vigente; como complemento, los usuarios no deberían ser capaces de descargar ninguna clase de software, pero las aplicaciones no han sido diseñadas en este sentido.

RECOMENDACION 14: Establecer planes de contingencia y sistemas de respaldo. "No existe ninguna garantía de que nuestro sistema sea invulnerable. Más allá de las medidas que podamos adoptar, siempre existirá la posibilidad de ser atacados."

Recomendación totalmente válida. Considerar además los casos de desastre total causados por los sismos recientes en nuestra región. El gran problema es que se requiere dinero y en general esto es un "megaproyecto" dentro de la organización, con todos los retrasos consiguientes; típicamente irrealizable si la alta dirección no está convencida.

RECOMENDACION 15: Mantener contacto con el proveedor de líneas de comunicación. "Diversos problemas pueden aparecer en las comunicaciones desde nuestra red hacia el exterior en los cuales sólo el proveedor del enlace puede ayudarnos."

Para casos en los que el portal institucional es muy importante, esto se puede simplificar delegando en servidores de hosting especializados cuyo día a día comprende evitar estos inconvenientes.

RECOMENDACION 16: No permitir conexiones directas desde la red interna a Internet. "Asumimos que en Internet están los malos, y por tanto nuestra red interna no debería tomar contacto con ellos."

Esta recomendación no ha surtido el efecto deseado. A pesar de los diversos mecanismos de intermediación (proxys) las vulnerabilidades en las aplicaciones han aparecido a un ritmo imparable por lo que la "solución" ha pasado por 1) una revisión y modificación de lo que ejecuta el usuario, 2) no permitirle navegar libremente. Un tercer caso -algo anecdótico- lo constituyen las cabinas internet en las que se acepta la imposibilidad de una navegación segura, y se cuenta con sistemas que realizan algo equivalente a una "reinstalación total" del sistema operativo y las aplicaciones de manera instantánea a intervalos muy cortos.

RECOMENDACION 17: Uso de red perimétrica o zona desmilitarizada. "…Muchos especialistas recomiendan mantener estos servidores protegidos mediante firewalls, pero a la vez separados de la red interna donde se encuentra, por ejemplo, nuestra base de datos. La idea es que estos servidores están en una zona de peligrosidad intermedia protegidos de Internet, pero no al nivel de nuestro sistema más interno."

Esto actualmente es una norma; no hay mucho que decir salvo lo ya mencionado en la recomendación número dos.

RECOMENDACIÓN 18. Prácticas de programación segura. "Si su organización desarrolla software de cualquier tipo, y en especial, si este software dará cara a Internet, entonces Ud. debería asegurarse de que los desarrolladores conozcan las recomendaciones de seguridad correspondientes al lenguaje de programación o herramienta de desarrollo empleada así como del ambiente (sistema operativo o red) en que se ejecutan."

Quizá aquí está el talón de aquiles en todo este tema. Por diversos motivos las garantías de seguridad del software no se suelen introducir adecuadamente en las etapas de requerimientos, menos en la implementación. Menos información tendrá el administrador que nunca tuvo contacto con los encargados del desarrollo.

Algunos productos de seguridad (orientados al administrador) bastante nuevos apuntan a cubrir este vacío con análisis más cercanos al software (como la detección de SQL inyection); el problema es que su correcto uso requiere que el administrador esté al tanto de estos temas normalmente considerados de desarrollo de software. Sería muy largo referirme aquí al por qué de esta situación tan caótica en la seguridad del software, pero el administrador responsable hará bien en documentarse en los principales "antipatrones" que generan los problemas.

RECOMENDACION 19: Vigilancia. "La vigilancia del buen funcionamiento del sistema es un asunto más complicado de lo que parece. El problema es que los ataques frecuentemente están disfrazados de conexiones más o menos válidas, y por otro lado, los sistemas de cómputo 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 más y más modificaciones sin ser detectados y detenidos."

En este terreno ha habido un avance significativo en los productos de seguridad. Quizá lo que suele quedar poco claro es la manera de interactuar con estos productos, y los procedimientos correctivos a seguir en caso de detección.

RECOMENDACION 20: Establecimiento de políticas. "El establecimiento de políticas corresponde a un mecanismo que permite asegurar que la seguridad se mantenga en todas las situaciones y se deriva del compromiso con la seguridad de la organización. La idea detrás de todo esto es que nadie puede saber de antemano lo que piensa el administrador o el encargado de la seguridad sin ser informado."

Al igual que en cualquier tarea legislativa, establecer políticas (o cualquier norma en general) que regulen sin entorpecer la operación normal, es todo un arte. Sin embargo, se hace necesario conforme la organización crece y más aún cuando ésta está sujeta a regulaciones externas en el tratamiento de la información. Busque ejemplos, parta con lo más obvio y evolucione gradualmente.

De todos modos, creo que no está de más insistir en los "vicios" de las malas políticas, y sus consecuencias: el administrador que se pasa 10 horas al día reinstalando sistemas operativos tiende a establecer políticas draconianas que generan dos efectos típicos: 1) se ignoran por considerarse ridículas; 2) se toman al pie de la letra, y el trabajo se paraliza. En cualquier caso el efecto de la política es indeseado (y terminará golpeando cual boumerang al administrador), por lo que debe tenerse sumo cuidado de no producir una total alienación de los supuestos defendidos.

Una sugerencia es convocar anticipadamente a algunos usuarios representativos y solicitarles sus opiniones, a fin de conocer en qué manera podría una política futura impactar en sus actividades diarias; esto incluso puede permitir que se descubran alternativas más seguras y que satisfacen los mismos requerimientos funcionales que las menos seguras. Este camino evidentemente tomará más tiempo, y asimismo requerirá que el administrador haya hecho "su tarea" de investigación de productos alternativos, pero a largo plazo es preferible a políticas-letra-muerta.

Referencias

[COMPLEX] http://www.schneier.com/crypto-gram-0003.html#SoftwareComplexityandSecurity The future of digital systems is complexity, and complexity is the worst enemy of security

[CERT] http://www.cert.org/ El CERT/CC

[RIESGO] http://cisac.stanford.edu/publications/how_much_is_enough__a_riskmanagement_approach_to_computer_security/ Extenso documento sobre administración de riesgos (How Much Is Enough? A Risk-Management Approach to Computer Security)

[VPN2] http://www.vpnlabs.org/ VPN Labs

[CRIPT] http://www.schneier.com/crypto-gram.html Cryptogram newsletter

[SSH] http://www.openssh.org/ OpenSSH Home

[DOS1] http://www.denialinfo.com/ Deny Of Service resources

[SEGINT] http://www.cert.org/encyc_article/tocencyc.html La seguridad en Internet

[IDS1] http://online.securityfocus.com/infocus/1558 Previniendo y detectando ataques con IDS’s

[SNORT] http://www.snort.org/ Snort: Network instrusion detection system

[TRIP] http://www.tripwire.org/ Tripwire: Host based IDS

[NETSECURITY] http://netsecurity.about.com/ Recursos de seguridad