SELinux: Teoria

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.

¿Cómo funciona SELinux? Pues se basa en atributos extendidos del sistema de ficheros que indican el tipo de usuario (que no tiene porque ser usuario del sistema), el rol, y el tipo del objeto. Por ejemplo, si hacemos un ls -lZ para ver los atributos extendidos del directorio /etc/httpd, podremos ver que permisos le asigna una distribución Red Hat a los ficheros de configuración de Apache (la quinta línea se ha partido para facilitar su presentación):

[root@localhost httpd]# ls -lZ
drwxr-xr-x root root system_u:object_r:httpd_config_t conf
drwxr-xr-x root root system_u:object_r:httpd_config_t conf.d
lrwxrwxrwx root root system_u:object_r:httpd_log_t logs -> ../../var/log/httpd
lrwxrwxrwx root root system_u:object_r:httpd_modules_t modules -> 
           ../../usr/lib/httpd/modules
lrwxrwxrwx root root system_u:object_r:httpd_config_t run -> ../../var/run

Como podemos ver, el usuario y rol es el mismo, pero el tipo cambia. Estos atributos son los que en función de las políticas definidas en SELinux, indican las interacciones entre ellos y los diferentes objetos del sistema. Estos atributos están definidos en el sistema, y puede haber cientos, tantos como la granularidad que queramos obtener. La mayoría de distribuciones que usan SELinux vienen ya con varios tipos predeterminados para ayudarnos en su administración, pero nosotros podemos definir más. Si queremos ver todos los tipos disponibles, lo podemos hacer con el comando

#getsebool -a

Ahora que ya conocemos los atributos, ahora nos falta conocer un poco las políticas que utilizan estos atributos. Al más alto nivel, existen dos tipos de políticas básicas: targeted y strict:

  • strict: En modo estricto, por defecto todo está denegado, y tan sólo se permite lo especificado en la políticas. Esto, que sigue el principio de mínimo privilegio, es complicado de administrar y llevaría a la mayoría de los sysadmins a desactivar SELinux.
  • targeted: Tan sólo ciertos servicios están bajo la supervisión de SELinux, como por ejemplo los demonios httpd, bind, postgresql, etc. El resto están libres de restricciones. La denominacion Targeted proviene del hecho de que tan solo los servicios señalados serán vigilados.

Para saber qué tipo de política tenemos configurada, en un sistema Red Hat podemos averiguarlo en el fichero /etc/sysconfig/selinux.

Por debajo de estos modos, se sitúan las políticas en sí, que definen las interacciones entre objetos. Dichas políticas pueden usar diferentes controles de acceso, en función de los atributos extra que utilicen. Normalmente se suele usar Type Enforcement en el cual tan solo se utiliza el atributo tipo, y es el modo usado por la política targeted. Existen otros métodos como el Role-Based Access Control que utiliza los atributos de usuario y rol pero normalmente, dado que como política se utiliza targeted, el modo de acceso mas común es el Type Enforcement.

Ya tan sólo nos queda saber qué es lo que exactamente permite o impide que podamos acceder a un objeto. Aquí entran en juego las políticas, que dependiendo del control de acceso utilizado y los atributos de los objetos, permiten o deniegan un acceso. Así pues, si usamos el modo de Type Enforcement, es el tipo de un objecto el atributo determinante. En este caso, si un servicio esta en el modo vigilado tan solo podrá acceder a objetos con un tipo similar. En las políticas se definen los tipos similares y las excepciones que permiten que el sistema funcione. Así, por ejemplo, si inspeccionamos con que permisos se ejecuta el demonio Apache (la segunda línea se ha partido para facilitar su presentación):

[root@localhost etc]# ps auxZ | grep httpd
user_u:system_r:httpd_t  root  2869 0.3 0.5 10548 2924 ? Ss 15:46 0:00 
          /usr/sbin/httpd

Vemos que dicho demonio tan solo podrá interactuar con objetos de un tipo similar, como por ejemplo los que están en el directorio /etc/httpd. Esto implica que aunque nosotros tuviéramos un fichero con permisos de lectura y escritura para todos, como por ejemplo:

[root@localhost jvela]# ls -lZ /home/jvela
drwxr-xrwx jvela jvela user_u:object_r:user_home_t  prueba_selinux

Un atacante que comprometiera el demonio de httpd no podría acceder porque dicho demonio esta en el dominio de SELinux y el tipo de nuestro archivo no pertenece a la “familia” httpd.

Hemos visto por encima que es SElinux, cómo esta estructurado y como consigue aplicar el MAC a un sistema GNU\Linux. Por supuesto, como pasa siempre, la mejor manera de comprender su funcionamiento es jugando con él y poniéndolo en marcha, algo a lo que les invito. No obstante, si les queda alguna duda o hay algo de lo dicho sobre lo que les gustaría que incidiese, no tienen más que indicarlo en los comentarios y estaré encantado de aclarar las dudas que tengan. En la siguiente entrada pasaremos de la teoría a la práctica, con ejemplos de su funcionamiento y las múltiples opciones de configuración que lo convierten en un sistema tan flexible.

Saludos, y hasta la próxima.

La Ley Ómnibus…¿y?

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.

Las implicaciones de esta ley están generando muchos comentarios en el ámbito de la seguridad; de un lado, están las empresas de Seguridad Privada “clásicas” que ven cómo se liberaliza una parte de su nicho de mercado, hasta ahora fuertemente regulado y restringido a unos pocos, y por otra están las empresas de servicios que ven cómo se eliminan las barreras a ese negocio que hasta ahora tenían vetado. Como siempre, no ha llovido a gusto de todos, y cada uno defiende sus intereses como buenamente puede.

Más allá de apoyos y rechazos, de buenos y malos, de problemas y soluciones… en los que no voy a entrar esta vez (cada uno tiene sus razones y todas, hasta cierto punto, parecen razonables), y por supuesto más allá de las implicaciones -y lagunas- que esta Ley pueda introducir con respecto a otras (seguro que los compañeros de Consultoría van a preparar próximamente un post sobre la Ley Ómnibus y sus implicaciones en videovigilancia -por poner un ejemplo- en relación a la LOPD), para mí, la Ley Ómnibus no ha hecho más que poner el dedo en la llaga de un problema mucho más serio que muchos venimos señalando desde hace años: la necesaria remodelización al completo de la Ley de Seguridad Privada. Nos cansamos -todos- de decir que la seguridad ha cambiado mucho en los últimos años (11S, inteligencia, information sharing, terrorismo, convergencia…) y, sin embargo, en España la regulamos con una ley que está a punto de cumplir la mayoría de edad…

La LSP, bajo mi punto de vista, necesita no una disposición adicional sexta como la introducida por la Ley Ómnibus (y podemos discutir si es buena o mala), sino un lavado de cara completo, que defina nuevos roles en materia de Seguridad Privada (¿la hora del “auditor” junto al “inspector”? ¿la hora del “cibervigilante” junto al “vigilante”?), que marque nuevos requisitos de formación para el personal de seguridad privada (no es admisible, bajo ningún concepto, que el Director de Seguridad de una entidad financiera considere, como alguno me ha llegado a decir, que el phishing no es un problema de seguridad para él… imagino que porque no sabe combatirlo con una pistola) y que actualice las regulaciones, requisitos y demás que contempla la Ley -y por extensión, el Reglamento de Seguridad Privada- para trabajar en el ámbito de la seguridad.

Y es que, con todas los cambios que a diario surgen en el ámbito de la seguridad, creo que estas legislaciones son, cuanto menos, obsoletas; ojo, no hablo de eliminarlas, sino simplemente de adaptarlas, incluyendo una visión mucho más amplia de lo que es en la actualidad la Seguridad Privada y el rol que tiene en nuestra sociedad. Para ser Vigilante de Seguridad o Director de Seguridad Privada hacen falta unos requisitos perfectamente definidos por el Ministerio del Interior (seguramente mejorables, pero definidos). Para trabajar en otros ámbitos de la seguridad, como el de la seguridad de la información, no hace falta nada. ¿Quién puede hacer una auditoría de ISO 28000 o de ISO 27002? ¿Un ingeniero? ¿Un abogado? ¿Un CISA? ¿Todos? ¿Nadie? ¿Por qué para proteger un supermercado del robo de productos se exigen unos requisitos, y para proteger la información de un VIP no?

Hasta que no regulemos (o desregulemos, ¿por qué no?) de alguna forma estos aspectos -y si empezamos a regularlos, seguramente discutiremos, pero eso es bueno- seguiremos pegándonos por los detalles. Como los de la Ley Ómnibus.

Introducción a la esteganografía (III)

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.

Estegoanálisis estadístico: Consiste en detectar modificaciones esteganográficas mediante la observación de desviaciones respecto a la norma de algunas propiedades estadísticas (por ejemplo, la entropía siempre aumenta). En el caso de tener como contenedor una imagen, se realizaría un cotejo de la frecuencia de distribución de colores del estego-objeto a través de un software especializado. Una de estas técnicas es el ataque Chi-Square, que permite estimar el tamaño de la posible información oculta en un estego-objeto. Es aplicable cuando un conjunto fijo de parejas de valores conmutan de un valor al otro de la pareja cuando se insertan los bits del mensaje oculto. Como indican Arturo Ribagorda, Juan M.Estevez-Tapiador y Julio César Hernández en el documento que les apuntábamos el otro día, Esteganografia, esteganalisis e Internet (PDF), este tipo de estegoanálisis presenta limitaciones importantes, como son a) falsos positivos al procesar gran cantidad de contenidos, b) dificultad en la elección de la norma, y c) gran dependencia del tamaño del mensaje oculto y del medio.

Casualmente hace unas semanas la comunidad científica se ha hecho eco de una nueva técnica que se puede usar para un estegoanálisis. Dicha técnica revela imágenes en objetos ocultos y puede que algún día mejore la capacidad de los pilotos para volar a través de condiciones de poca visibilidad por niebla, o a los médicos a ver con mas precisión en el cuerpo humano sin necesitad de cirugía. Desarrollado por ingenieros de la Universidad de Princeton, el método se basa en la alta capacidad para aclarar una imagen mediante rayos de luz que normalmente hacen que la imagen sea irreconocible (europapress, tendencias21). Dichos resultados han sido publicados en Nature Photonics.

En sus experimentos, los investigadores Fleischer y Dmitry Dylov, empleando materiales ópticos no lineales, restauraron una imagen oculta en un patrón claro de números y lineas. Según Dylov “Es como si hubiésemos tomado una foto de una persona en la oscuridad, y hayamos hecho a la persona mas brillante y el fondo mas oscuro. El contraste hace que la persona se destaque”. Personalmente espero y confío que en el futuro se pueda perfeccionar esta técnica y pueda ser útil y de gran ayuda para por ejemplo diagnósticos precoces en el ámbito médico, o incluso combinándola con otras técnicas sea útil para operar sin cirugía, a través de láser u otro tipo de método ya que el nivel de visión interno sería mucho más preciso.

Para acabar, y en cuanto a software, existe una gran variedad tanto para esconder mensajes (HIP, MP3Stego, JPHide y JPSeek, BitCrypt, S-Tools,BlindSide Cryptographic Tool, StegoVideo, Xiao steganography,OpenStego,…) como para descubrirlos a través del estegoanálisis (Stegdetct, StegSecret, Stego Suite, Stegkit, Digital Invisible Ink Toolkit, StegSpy, SteGUI, Stepic, StegAlyzerSS,…). Queda como ejercicio para el lector interesado indagar en las características y propiedades de cada una de estas aplicaciones. Para ampliar esta y otra información, pueden tirar de la Wikipedia, el documento indicado previamente, el artículo de INTECO, y por supuesto, de los innumerables recursos que aporta Internet.

Introducción a la esteganografía (II)

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.
  • Sustitución de bits del objeto contenedor: Consiste en sustituir ciertos bits del fichero contenedor por los de la información a ocultar. El tamaño del fichero no se ve alterado y, generalmente tampoco se ve mermada su calidad. En un fichero de sonido se podrían emplear los bits que no son audibles por el oído humano para ser reemplazados por los bits del mensaje a ocultar. Si se trabaja con imágenes, lo habitual seria sustituir los bits menos significativos (LSB), en una escala de color de 24 bits. Esto se traduce a que en un pixel con un tono rojo se ve un 1% mas oscuro, un cambio inapreciable para la vista humana.

    Como hemos comentado antes, el contenedor más usado es el de las imágenes digitales, concretamente en formato BMP por su sencillez; es un formato estándar de imagen de mapa de bits en sistemas operativos DOS, Windows y válido para MAC y PC, que soporta imágenes de 24 bits y 8 bits, y puede trabajar en escala de grises, RGB y CMYK. Cada pixel de un archivo BMP de 24 bits está representado por tres bytes, cada uno de los cuales contiene la intensidad de color rojo, verde y azul (RGB). Combinando los valores en esas posiciones podemos obtener los más de 16 millones de colores que puede mostrar un pixel. A su vez, cada byte contiene un valor entre 0 y 255, es decir entre 00000000 y 11111111 en binario, siendo el dígito de la izquierda el de mayor peso, por lo que se pueden modificar los bits menos significativos de un pixel sin producir mayor alteración. El hecho es que cambiando un bit en cada componente de un pixel, se pueden meter tres bits de información oculta por cada pixel de una imagen sin producir cambios importantes en la imagen. Teniendo en cuenta que se necesitan ocho pixeles para ocultar tres bytes de información, en codificación ASCII esto son 3 letras de información oculta, por lo que en una imagen BMP de 502×126 pixeles se puede ocultar un mensaje de 23.719 carácteres ASCII.

  • Inserción de bits en el objeto contenedor: Se añaden los bits de información a partir de una determinada marca estructural del fichero (fin de fichero, espacios de padding o alineamiento, etc.). El problema de esta técnica es que se incrementa el tamaño del fichero contenedor, por lo que no es muy discreta.

    Por ejemplo, en una imagen BMP los primeros 54 bytes contienen los metadatos de la imagen. Cuatro de esos bytes se destinan al offset, o distancia entra la cabecera y el primer pixel de la imagen. Así pues, la forma mas fácil de ocultar datos consiste en introducirlos justo después de los metadatos y antes de los datos de la imagen en sí, y modificar el campo offset. De esta manera, se puede dejar espacio para todo el contenido adicional que se desee añadir.

  • Creación de un fichero contenedor propio partiendo de la información a ocultar: Consiste en crear un fichero contenedor con la propia información que se quiere ocultar. Por ejemplo, dado un algoritmo especifico de reordenamiento de los bytes de los datos a ocultar se puede generar una secuencia de pixeles de un archivo BMP que tenga cierto significado visual.

    En vídeo suele utilizarse el método DCT (Transformada de coseno discreta) basada en la DFT (Transformada de Fourier discreta), pero haciendo uso únicamente de números reales. DCT funciona cambiando ligeramente cada uno de los fotogramas del vídeo, de manera que no sea perceptible por el ojo humano. Por ejemplo, en la completa presentación titulada Esteganografia, esteganalisis e Internet (aquí en PDF) de Arturo Ribagorda, Juan M.Estevez-Tapiador y Julio César Hernández se muestra un procedimiento para ello, cuya extracción sería sencilla aplicando el procedimiento inverso:

    1. Calcular la DCT de la imagen
    2. Sustituir los coeficientes menores que un cierto valor umbral por bits de la información a ocultar
    3. Calcular la inversa de la DCT de la imagen
    4. Almacenar

Utilizando estas técnicas, existen múltiples escenarios en los cuales podría emplearse la esteganografia. Por un lado, empleando el protocolo TCP/IP, ya que éste es apropiado para crear canales encubiertos de comunicación enviando datos relevantes a través de las cabeceras entre dos entidades que hayan acordado un protocolo encubierto. De la misma manera, con la finalidad de fortalecer los canales de comunicación maliciosa, la esteganografia es de gran utilidad. De hecho, los creadores del gusano Waledac ya han empleado esteganografia para que éste tenga la capacidad de descargar e interpretar un archivo de imagen JPEG especialmente manipulado. Dicho archivo es una imagen JPEG normal a la que se le ha añadido un ejecutable tras la imagen en sí, después de un determinado marcador JPEG para ser coherente con el estándar. Por supuesto, no todas las aplicaciones de la esteganografia tienen que ser maliciosas. Estas técnicas se pueden usar para meter información de pacientes en radiografías , TACs, etc… pero seguramente no les parecerán tan interesantes.

En la siguiente entrada finalizaremos con un vistazo al estegoanálisis, pero como les decíamos en el artículo anterior, pueden encontrar información en la Wikipedia, en el artículo que el Inteco le dedicó, y en la excelente presentación que les señalábamos arriba. Por supuesto, siempre tendrán los innumerables recursos que aporta Internet.

Honeynets II: Honeypots (Para aprender, perder… o no)

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.

Según la LOCALIZACIÓN, pueden situarse en un entorno de:

  • Producción: El objetivo que se pretende alcanzar al implantar un honeypot en una red en producción no es otro que la obtención de información sobre las técnicas empleadas para tratar de vulnerar los sistemas que componen dicha infraestructura.

    El abanico de posibilidades que nos ofrece un honeypot en una red en producción es muy amplio. Desde la posibilidad de ubicar el honeypot en el segmento de la red de servidores internos de la compañía, con el objetivo de detectar posibles accesos por parte de usuarios internos a recursos críticos de la organización (por ejemplo al fichero de nóminas), hasta la publicación de un servicio web con idéntica configuración y diseño que el mismo servicio que está en producción o preproducción.

    El mayor inconveniente que supone esta elección es el peligro que supone para los sistemas organizativos el permitir (incluso provocar) que el tráfico malintencionado conviva con el legítimo.

  • Investigación: En este caso, el principal objetivo es la recopilación de la mayor cantidad de información que permita al investigador poder analizar las nuevas tendencias en los métodos de ataque, así como los principales objetivos perseguidos y los distintos orígenes de los ataques. El resultado de este análisis es recogido en informes cuyo objetivo es respaldar la toma de decisiones en la implantación de las medidas de seguridad preventivas.

    La principal ventaja de situar el honeypot en una red independiente, dedicada únicamente a la investigación, es la separación del sistema vulnerable del resto de sistemas productivos y evitar así la posibilidad de sufrir un ataque a través del propio honeypot. Por el contrario, el inconveniente es la cantidad de recursos necesarios. Sobre la arquitectura a emplear profundizaremos en próximos posts.

Otro método de clasificación de los “tarros de miel” es el que define la INTERACCIÓN con el atacante. En este caso, los honeypots se agrupan en dos tipos:

  • Baja Interacción: El honeypot emula un servicio, una aplicación o un sistema vulnerable. Sus características principales son su sencilla instalación y configuración, junto con lo limitado de su capacidad para obtener diferentes tipos de datos. Unos ejemplos de honeypots de este tipo son:
    • Honeyd: Quizás uno de los honeypots más sencillos y populares. Es un demonio que crea hosts virtuales en una red. Los anfitriones pueden ser configurados para ejecutar servicios arbitrarios, y su comportamiento puede ser adaptado para que simule estar en ejecución en ciertos sistemas operativos.
    • HoneyC: El objetivo de este honeypot es la identificación de servidores web maliciosos en la red. Para ello emula varios clientes y recaba la mayor cantidad posible de información de las respuestas de los servidores cuando estos contestan a sus solicitudes de conexión. HoneyC es ampliable de diversas formas: pueden utilizarse diferentes clientes, sistemas de búsqueda y algoritmos de análisis.
    • Nephentes: Honeypot de baja interacción que pretende emular vulnerabilidades conocidas para recopilar información sobre posibles ataques. Nepenthes está diseñado para emular vulnerabilidades que los gusanos utilizan para propagarse y cuando estos intentan aprovecharlas, captura su código para su posterior análisis.
    • Honeytrap: Este honeypot está destinado a la observación de ataques contra servicios de red. En contraste con otros honeypots, que se suelen centrar en la recogida de malware, el objetivo de Honeytrap es la captura de exploits.
    • Glastopf: Emula miles de vulnerabilidades para recopilar datos de los ataques contra aplicaciones web. La base para la recolección de información es la respuesta correcta que se le ofrece al atacante cuando intenta explotar la aplicación web. Es fácil de configurar y una vez indexado por los buscadores, los intentos de explotación de sus vulnerabilidades se multiplican.
  • Alta Interacción: En este caso el honeypot es una aplicación con la cual se puede interactuar y que responde como se espera, con la diferencia de que su diseño está orientado a realizar un registro exhaustivo de la actividad que se lleva a cabo sobre ella y de que la información que contiene no es relevante en ningún caso.
    • HI-HAT (High Interaction Honeypot Analysis Toolkit): Herramienta que transforma aplicaciones php en aplicaciones honeypot de alta interacción. Además ofrece una interfaz web que permite consultar y monitorizar los datos registrados.
    • HoneyBow: Herramienta de recopilación de malware que puede integrarse con el honeypot de baja interacción Nephentes para crear una herramienta de recolección mucho más completa.
    • Sebek: Funciona como un HIDS (Host-based Intrusion Detection System) permitiendo capturar una gran variedad de información sobre la actividad en un sistema ya que actúa a muy bajo nivel. Es una arquitectura cliente-servidor, con capacidad multiplataforma, que permite desplegar honeypots cliente en sistemas Windows, Linux, Solaris, *BSD, etc., que se encargan de la captura y el envío de la actividad recopilada hacia el servidor Sebek. Podríamos decir que forma parte de una tercera generación de honeypots.
    • Capture-HPC: Del tipo cliente, como HoneyC, identifica servidores potencialmente maliciosos interactuando con ellos, utilizando una máquina virtual dedicada y observando cambios de sistema no previstos o autorizados.

Otra opción a destacar en cuanto a la elección de un honeypot es la de la web Project HoneyPot. Se trata de un portal que facilita un recurso web para usarlo como honeypot. Este genera una página con un código script, la cual utiliza diversas técnicas para la recopilación de información (IPs, logins usados en ataques de fuerza bruta, spammers, etc…).

Para acabar con esta entrada, no quisiéramos dejar pasar la oportunidad de destacar un honeypot, creado por un español, que emula un servidor SSH y que se despliega con la intención de recopilar información de los diversos ataques que existen contra este servicio. Su nombre no podía ser más explícito: Kojoney. Pasen un buen fin de semana; nos vemos el lunes, aquí mismo.

(Entrada escrita en colaboración con Raúl Rodriguez, co-autor de la serie)

ACL en GNU/Linux (II)

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.

En segundo lugar están los temas puramente técnicos. Como buenos administradores, deberemos hacer copias de seguridad, y es aquí cuando nos encontramos que el comando cp no funciona adecuadamente si no usamos la opción preserve:

# cp --preserve=all  ./ACL/prueba ./ACL2/

Así, al hacer copias de seguridad muchas veces usaremos el comando tar para empaquetar, y aquí es cuando nos damos cuenta de que tar no soporta los atributos extendidos en el sistema de ficheros. Investigando un poco aparece star, un tar “posix compliant” que permite realizar, usando un sistema de empaquetado especial, manejar dichos atributos. Para comprimir y empaquetar usaríamos:

# star -c acl2 -file=acl2.tar -H=exustar -acl 

-c: Directorio a archivar
-file: Nombre del fichero de salida
-H: formato del archivo tar, en nuestro caso exustar que es el que soporta ACL
-acl: Archiva los atributos extendidos de ACL

Para desempaquetar, más sencillo:

#star -vx file=acl2.tar

También querremos poder heredar permisos de las carpetas padre, para facilitar la tarea de asignar ACL y forzar a que dichos archivos tengan unos determinados permisos. Para ello debemos de recurrir a las “default ACL” que nos permiten indicar las ACL por defecto que heredará un objeto al crearse dentro de una carpeta padre, lo cual en Unix con los controles de acceso tradicionales se hace con el bit setgid.

#setfacl -d --set u:jvela:rw-,g:jvela:r--,o::- prueba_dir
# file: prueba_dir/ 
# owner: jvela 
# group: jvela 
user::rwx 
group::r-x 
other::r-- 
default:user::rw- 
default:group::r-- 
default:other::---

Aquí estamos asignando una ACL por defecto, sobrescribiendo las anteriores (se usa –set, no -m) para que todos los archivos que se creen en dicho directorio tengan una ACL para el usuario y grupo jvela
En este caso volvemos a toparnos con el mismo problema. Las posibilidades son enormes, pero su administración es compleja. Las ACL permiten mucho más, desde asignarlas recursivamente con la opción -R como con cualquier comando Unix, hasta clonar ACL desde un objeto. Podremos realizar casi cualquier tarea que realizamos con los controles de acceso normales, y con mucha más flexibilidad, pero con la contrapartida de una administración más compleja.

Hasta aquí todo lo básico para manejar ACL, donde hemos visto desde sus virtudes y la versatilidad que proveen hasta los problemas que conllevan y el cuidado que hay que tener con ellas. Nada más sobre este tema. Sean buenos y no acaben en un Active Directory por usar ACL ;)

Bad Behaviour: Un enfoque diferente del control anti spam

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.

Esta alternativa que les presentamos, llamada Bad Behaviour por razones obvias, partiendo de la base de la lucha contra el spam va un paso más allá, impidiendo a estos usuarios (o robots) maliciosos la entrada a su página web objetivo. Esto está muy bien pero, ¿cómo funciona Bad Behaviour? Es muy sencillo. La aplicación recibe cada petición realizada a su entorno web y comprueba diversos parámetros de la misma para detectar si la petición la ha realizado un usuario legítimo y no se trata de ningún robot ni usuario malintencionado. En caso de que encuentre una petición de este tipo, devuelve un simple error del tipo “403 Bad Behaviour”, en lugar del contenido original de la página solicitada.

Entrando más al detalle, este proceso se realiza de dos formas claramente diferenciadas. Por una parte la aplicación contiene un listado de posibles elementos o comportamientos que pueden convertir una petición en sospechosa de ser maliciosa (por ejemplo cabeceras erróneas, como la User-Agent, o peticiones que no respetan el contenido del fichero robots.txt en caso de que lo tengamos configurado), y por otra rechaza peticiones de orígenes maliciosos al conectarse a una base de datos pública de IPs maliciosas constantemente actualizada.

Este proceso puede parecer lento y su demanda de recursos alta, pero se ha demostrado que puede llegar a introducir una mejora en el tiempo de carga de las webs ya que al bloquear los accesos malintencionados se dejan de enviar páginas web completas (con todos sus elementos y contenido multimedia) y se envía un simple mensaje de error en su lugar, lo que reduce considerablemente el ancho de banda consumido por estas peticiones y la carga de los servidores.

En lo que respecta a la instalación, esta aplicación se creó inicialmente como una extensión para WordPress (motor que da vida a este mismo blog), pero su diseño modular le permite adaptarse a prácticamente cualquier aplicación basada en PHP. Actualmente existen instrucciones de instalación para otras de las aplicaciones web más comunes como MediaWiki, Drupal, DokuWiki y Geeklog, e incluso algunos CMS lo incluyen en su instalación por defecto (es el caso de LifeType).

Si no la conocían, espero que la prueben y nos dejen sus comentarios sobre la funcionalidad de esta aplicación y su funcionamiento.

ConAn

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.

Para utilizar esta aplicación es necesario registrarse previamente en la web que INTECO ha preparado al respecto para posteriormente proceder a la descarga de la aplicación. La descarga es liviana (ocupa menos de 1MB) y su proceso de instalación es el típico de aplicaciones Windows.

Una vez instalada, la aplicación pide de nuevo los datos de conexión utilizados para descargar la aplicación, dado que tras el análisis del sistema (proceso que realiza con bastante celeridad, al menos en las máquinas probadas) la aplicación vuelca el informe a la web de INTECO, para que pueda ser accedido posteriormente con mayor facilidad. Si no disponemos de conexión a Internet en la máquina a analizar tampoco hay ningún problema, ya que podremos realizar el análisis sin conexión y enviarlo posteriormente en el apartado correspondiente de la web de ConAn.

Dejando aparte los posibles problemas de privacidad y robo de datos que este envío de informes pudiera suponer y que discutiremos en otras entradas, cabe remarcar que los informes destacan por su buena estructura, el uso de iconos para mostrar los distintos niveles de seguridad y el uso de un lenguaje claro y directo que los usuarios poco familiarizados con los entresijos de la informática seguro que podrán entender. Además, en cada punto del informe se proporcionan una serie de recomendaciones de seguridad proporcionadas por la Oficina de Seguridad del Internauta, y también información adicional de organismos y otras fuentes externas, que complementan la información proporcionada por el propio INTECO. A continuación hemos incluido algunas pantallas del programa, aunque es recomendable que lo prueben ustedes mismos.

Más información y noticia original en INTECO.

Descarga del programa: ConAn

* * *

False friends

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.

IDS de red: Los IDS tienen el mismo problema que los antivirus: son “IDSs de patrones conocidos”, pero son mucho peores que los AV ya que por lo general no toman medidas inmediatas, sino que se limitan a registrar e informar. Además, existen numerosas ocasiones en las que están “ciegos”, como por ejemplo en el tráfico cifrado en el que funcionan todas nuestras web corporativas importantes. Además únicamente registran intrusos en base a patrones “técnicos”, pero no a nivel de “negocio”, de modo que alguien puede estar haciendo transferencias bancarias de forma masiva, y el IDS sólo vera un usuario utilizando la aplicación de transferencias.

Los auditores de vulnerabilidades (Nessus / OpenVAS / etc): Volvemos a lo mismo. No podemos estar tranquilos con haber pasado un scanner de vulnerabilidades y ver que todo queda corregido, dado que éstos únicamente lo son de vulnerabilidades conocidas y en su gran mayoría de software conocido, por lo que todos los desarrollos adhoc pueden ser completamente vulnerables a ataques de todo tipo y pasar inadvertidos. Es cierto que en este campo las herramientas están evolucionando y cada vez son mas capaces de analizar desarrollos desconocidos, pero cualquier auditoria automática de este tipo debería incluir un disclaimer en el que se indique que la herramienta sólo comprueba vulnerabilidades en versiones y configuraciones de programas conocidos, por lo que no incluye la detección de problemas en desarrollos propios, programas no conocidos o partes no públicas que pueden ser facilmente explotables por usuarios maliciosos. De aquí la necesidad e importancia de que una auditoría de este tipo sea complementada con auditorías manuales, tanto de los desarrollos a nivel de código, como a nivel de interacción con el usuario final.

Dicho esto, ¿cómo actuar en estos casos? El planteamiento es muy sencillo: se debe trabajar con el supuesto de que las herramientas no existen:

Antivirus: Debemos actuar como si no se dispusiera de antivirus. En un entorno de oficina, por ejemplo, no ejecutar programas de los que no se conozca el origen, limitar la ejecución de binarios y código externo, eliminar los ejecutables que llegan por correo electrónico, restringir la descarga de ejecutables a través del proxy web, y deshabilitar el acceso a programas en unidades CD/USB.

Detección de intrusos de red: Al IDS de red le pasan desapercibidas muchas cosas, y potencialmente puede generar un gran número de falsos positivos. No obstante, si conoce su negocio y sus aplicaciones seguro que sabe dónde mirar para detectar cosas extrañas; trate de añadir IDS de host, o integrados dentro de la lógica del negocio, ya que serán mucho más efectivos. Y por supuesto no los utilice como excusa para no tener en perfecto estado de revista la seguridad de sus servidores.

Auditorías de vulnerabilidades: Como se ha comentado, no es suficiente con los análisis que se limitan a los datos de la caja negra. Debemos revisar de manera no exclusivamente automática las actualizaciones de versiones de los programas, su funcionamiento cuando interactúan con el usuario, la configuración de las aplicaciones con respecto a la seguridad (usando guías de buenas practicas, o mediante el análisis de todas sus funcionalidades), y por supuesto controlar el desarrollo desde su orígenes, incluyendo la seguridad en todo el ciclo. La idea es que el hecho de que la herramienta de auditoría que utilizamos no haya encontrado un problema de seguridad no significa que no exista, e incluso puede estar más cerca de lo que pensamos.

Entonces, ¿dejamos de utilizar estas incompletas e imperfectas medidas de seguridad? Repasemos de nuevo los tres puntos:

Antivirus: Hoy en día, en ninguna cabeza cabe el no disponer de antivirus en cualquier entorno Windows, así que además de aplicar las prácticas seguras descritas previamente, hay que asegurarse de su correcta actualización de este, para que al menos esté al día de los virus conocidos. Es decir, que obviamente sí lo debemos de tener.

IDS: Mi opinion sobre los IDS (no compartida por muchos miembros de este blog) es que son bastante inútiles (esta entrada que va un poco en esa línea), y si no tienen funcionalidad automática de IPS sirven para muy poco (aunque eso puede generar otro tipo de problemas diferentes). En todo caso, la mayor utilidad que le veo a un IDS es la de detectar malware interno poco sofisticado, es decir intrusos internos, con lo que sí pueden ser positivos, aunque el objetivo debería ser que no llegaran dentro. También puede ser útil como herramienta de diagnóstico, para buscar algún patrón concreto en difusión amplia de malware. En definitiva, para ciertas finalidades contar con un IDS es sumamente interesante.

Auditor de vulnerabilidades: Aunque sean herramientas imperfectas, por su bajo coste de ejecución (se realiza de manera centralizada) pueden ser un primer paso para auditar una red. Aunque es verdad que cada vez son mas inteligentes y son mas capaces de auditar desarrollos genéricos (sqlmap es una maravilla), siguen siendo potencialmente peligrosas en cuanto a que la visión de auditoria de caja negra dista mucho de ser todo lo completa que la puede realizar un “humano” y puede generar una percepción de seguridad inexistente, además de ser infinitamente mas incompleta que una auditoria de caja blanca.

Como creo que era de esperar, usen todas ellas, pero tengan en cuenta siempre los disclaimers correspondientes y no se queden tranquilos con estos “false friends“. En una entrada posterior veremos qué pasa con las certificaciones: ¿”false friends“, o no?

Securizando nuestra DMZ (II)

(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.

[Read more…]