Lo prometido es deuda, y hoy vamos a explicar un poco que es SELinux [Security-Enhanced Linux, enlace de la NSA] y cómo opera. Recomiendo releer la entrada sobre MAC y DAC para recordar conceptos. Tras esto, ¿qué es SELinux? SELinux es una implementacion del MAC que funciona a nivel de kernel, lo que implica que las aplicaciones no necesitan ser modificadas para aprovechar toda su potencia, ya que para ellas SELinux es transparente, algo muy importante a la hora de que el sistema sea desplegado en un entorno real.

La razón de usar SELinux es limitar el acceso que tienen las aplicaciones a otras aplicaciones y a los ficheros, impidiendo que un proceso pueda modificar cualquier fichero del usuario con el que se lanzó. Por ejemplo, Firefox jamas debería ser capaz de cambiar los permisos de mi clave privada ssh, lo cual con un sistema de control de acceso DAC sí sería posible si un atacante toma el control del navegador.

El pasado día 26 la Unidad Central de Seguridad Privada (Cuerpo Nacional de Policía) hacía llegar una nota informativa acerca de las implicaciones de la conocida como Ley Ómnibus (Ley 25/2009, de 22 de diciembre, de modificación de diversas leyes para su adaptación a la Ley sobre el libre acceso a las actividades de servicios y su ejercicio) en el régimen de autorización, inspección y sanción en materia de Seguridad Privada.

El resumen de la situación es sencillo: hasta este momento, sólo las empresas de seguridad privada (esto es, las autorizadas por el Ministerio del Interior con arreglo al artículo 5 de la Ley 23/1992, de 30 de julio, de Seguridad Privada) estaban capacitadas para la instalación y mantenimiento de aparatos, dispositivos y sistemas de seguridad; con la disposición que introduce la Ley Ómnibus, se liberaliza el servicio, permitiendo la venta, entrega, instalación y mantenimiento de los equipos o sistemas de seguridad a los que se hace referencia por parte de particulares o empresas distintas a las de Seguridad Privada, siempre que la instalación no implique una conexión a CRA o CECON, por lo que -con ciertas salvedades- ya no es necesario recurrir a empresas autorizadas por el Ministerio para la instalación o manejo de estos dispositivos (por ejemplo, en el caso de soluciones de videovigilancia), y por supuesto siempre que el prestador no se dedique a otras actividades de Seguridad Privada establecidas legalmente.

Par acabar con esta breve serie sobre esteganografía, entraremos brevemente en el concepto de estegoanálisis, que como ya se ha comentado en alguna entrada anterior, es la técnica que se usa para recuperar mensajes ocultos o para impedir la comunicación por esteganografía. Básicamente, podríamos hablar de dos tipos principales de estegoanálisis:

Estegoanálisis manual: Consiste en buscar de forma manual diferencias entre el objeto contenedor y el estego-objeto buscando cambios en la estructura para localizar datos ocultos. En este caso es imprescindible disponer del objeto contenedor, y aunque en muchas ocasiones se detecta información oculta resulta imposible recuperarla. Un estegoanálisis manual podría consistir en un escenario en el que a partir de un archivo BMP donde el bit menos significativo de las componentes de algunos de sus píxeles hubiese sido sustituido por información oculta, aplicásemos un filtro de modo que sólo se considere el bit menos significativo de cada componente RGB de cada píxel.

Tras la introducción a la esteganografía de la entrada anterior, vamos a dar un repaso general a las técnicas esteganográficas más utilizadas, enfocadas sobre todo a que nuestro objeto contenedor sea una imagen, son las siguientes:

• Enmascaramiento y filtrado: la información se oculta dentro de una imagen digital empleando marcas de agua. El watemarking o marca de agua digital tiene como objetivo poner de manifiesto el uso no legal de un cierto servicio digital por parte de un usuario no autorizado. Esta técnica consiste en insertar un mensaje (un grupo de bits que contiene información sobre el autor por propietario intelectual) en el interior de un objeto digital. Otra técnica relacionada es el fingerprinting o huella digital, donde se introduce en el mensaje no sólo información sobre el autor o propietario sino además información del usuario que ha adquirido los derechos de uso de ese objeto. Así se puede perseguir la distribución ilegal de servicios digitales.
(Leer el resto de la entrada…)

Continuando con la serie sobre Honeynets que empezamos hace un mes, en esta entrada vamos a identificar y clasificar los diferentes tipos de Honeypots, los elementos esenciales de las “redes trampa”. Un honeypot no es más que una aplicación, servicio o sistema que simula ser lo que no es. No tiene un valor productivo para quien lo implanta y está preparado para ser sondeado, atacado y comprometido. Es básicamente un señuelo con el objeto de engañar al atacante que pretenda amenazar nuestros sistemas, al mismo tiempo que ayuda a entender las técnicas de ataque utilizadas.

Por estas razones, es lógico pensar que cualquier actividad que se genere desde o hacia un honeypot, será muy probablemente una actividad ilegítima o no autorizada. Existen diversas formas de clasificar los honeypots. Aquí lo haremos basándonos en dos de sus propiedades principales: la localización concreta dentro de una red y la interacción que permite con el atacante.

En el anterior post descubrimos las bondades de las ACL en GNU/Linux, i.e. cómo se podía aumentar la seguridad de nuestro sistemas a través de la granularidad que este sistema de acceso nos ofrecía. Hoy toca la parte menos bonita de las ACL, que en parte son la razón de que no sean ampliamente utilizadas en todo los sistemas Linux.

Una de las primeras cosas que saltan a la vista al usar ACL es que no son fáciles de administrar, al menos no tanto como los tradiciones controles de acceso. La información no está a la vista, y hay que usar comandos para inspeccionar cada fichero. Dado que cada objeto puede tener un numero variable de ACLs, puede resultar tedioso averiguar que permisos tienen los ficheros de un directorio determinado. Esto nos obliga a intentar reducir las ACL al mínimo, intentando usar las mismas ACL en todos los ficheros de un directorio e intentar usar tan sólo ACL de grupo para no tener casos demasiado específicos, lo que obviamente va contra la filosofía de las ACL.

Desde siempre el spam ha sido un problema para el buen funcionamiento de cualquier proyecto web. Tampoco es un secreto que uno de los mayores factores de generación de spam son los robots que recorren la totalidad de multitud de webs dejando huella de su paso en forma de, generalmente, comentarios y mensajes con contenido malicioso.

Pero, ¿qué medidas fiables tenemos para luchar contra el problema del spam? Muchos se basan en hacer que el usuario introduzca un texto o resultado de operación matemática, incluyéndolo de forma que una persona lo pueda procesar fácilmente pero no así un robot; estos son los conocidos Captchas. En este caso estamos dejando al usuario malintencionado (o robot de spam) entrar a nuestra web, e intentamos evitar que interactúe con ella.

Como muchos de ustedes sabrán, el pasado 6 de abril el INTECO (Instituto Nacional de Tecnologías de la Comunicación) publicó la primera versión de su aplicación ConAn, su herramienta de análisis de seguridad para entornos Windows. Se presenta como un complemento a otros sistemas de seguridad que pueda tener el cliente instalados en su máquina, ya que no interfiere en el funcionamiento de antivirus ni firewalls, sino que los complementa.

En lo que respecta a funcionalidad, ConAn agrupa la funcionalidad que hasta ahora ofrecían por separado otras herramientas, permitiendo por ejemplo revisar, entre otros, las actualizaciones del sistema y la seguridad de Internet Explorer (al estilo de MBSA), detalles sobre los procesos y servicios en ejecución (al estilo de multitud de programas, entre los que se encuentra el archiconocido Process Explorer, de Sysinternals), detalles sobre las conexiones de red establecidas y los programas que las están realizando (como en cualquier software cortafuegos), etcétera.

Siguiendo con la entrada sobre la inseguridad de sentirse seguro, me gustaría ahora describirles 3 tecnologías de uso habitual que dan una falsa sensación de seguridad:

- Antivirus: Siempre que le explico a algún no especialista que es un antivirus, le explico que no es un “antivirus”. Es muy sencillo; un antivirus es la forma abreviada (o comercial) de decir que es un antivirus de virus conocidos. Sí, existen módulos heurísticos y otras historias de ciencia ficción, pero la realidad es que los virus nuevos no son detectados por los antivirus hasta que son conocidos. Esto implica que si tenemos la mala suerte de toparnos con un virus de relativa novedad no conocido por nuestro antivirus, éste será de poca utilidad. Obviamente, aunque el antivirus que utilizamos lo reconozca, si el nuestro no se encuentra actualizado, la consecuencia es la misma, de ahí la importancia de actualizar las firmas del AV.

(Continuamos con la interrupción de las entradas de la Black Hat, en este caso para hablar de PVLANs. El lunes que viene sin falta retomamos el día 2 de la BH)

Hace unas semanas, José Luis introducía el concepto de Private VLANs (PVLANs) para la securización de las DMZ. Vamos a ver en esta entrada algunos aspectos interesantes de esta tecnología.

Como vimos, las PVLANs (Private Vlan’s) consiguen el objetivo propuesto de aislar los servidores de la DMZ unos de otros. Lo que no está claro es qué rango de direcciones IP, o mejor dicho a qué subred va a ir asociado cada servidor. Hay gente que tiene la falsa creencia de que para conseguir aislar los servidores unos de otros tenemos que gastar subredes distintas, utilizando una para cada servidor, e incluso gastando para ello las PVLAN’s. Y aquí es donde radica la ventaja de dicha tecnología: sólo necesitamos una subred para asignar direcciones IP a nuestros servidores alojados en la DMZ. Por ejemplo, si disponemos de 50 servidores en la DMZ, y no queremos que se vean unos a otros, en lugar de utilizar 50 subredes diferentes (por ejemplo, 192.168.1.x, 192.168.2.x., …, 192.168.50.x) podemos utilizar una única subred para todos ellos (por ejemplo, 192.168.1.1, 192.168.1.2, …, 192.168.1.50), y con PVLANs conseguiríamos el objetivo de aislar los servidores, dando la sensación de que cada servidor está aislado del resto.