Asegur@IT… y OpenBTS

El pasado día 9 tuvieron lugar en Valencia las conferencias Asegur@IT en su octava edición, evento que contó con la participación de empresas como Microsoft, Wintercore, Informatica64, Taddong e Hispasec, además de representantes del blog Security By Default. Y varios representantes de S2 Grupo estuvimos presentes.

En general, las charlas fueron de un gran interés; desde Chema Alonso presentando La Foquetta hasta Sergio de los Santos hablando de malware, pasando por Rubén Santamarta hablándonos sobre Bindiffing Patches y Alejandro Ramos sobre seguridad en archivos PDF, entre otros. Pero la charla que mas llamó mi atención fue la que impartieron David Pérez y José Picó, de Taddong, sobre “Nuevas amenazas en dispositivos móviles”, en la que nos mostraban a través de pruebas reales que los dispositivos móviles, elementos críticos de acceso a información sensible, cada vez más son acechados por nuevas amenazas, y que si no se protegen adecuadamente dentro de poco serán una de las vías de ataque favoritas por los delincuentes.

El experimento en cuestión trataba sobre la creación una falsa estación base de Telefonía móvil mediante el uso de OpenBTS. Pudimos ver mediante varios vídeos cómo suplantar la identidad de una estación base Movistar dentro de un entorno creado expresamente para dicho experimento, el cual consistía en una jaula de Faraday “autoconstruida”. El efecto jaula de Faraday provoca que el campo electromagnético en el interior de un conductor en equilibrio sea nulo, anulando el efecto de los campos externos (se pone de manifiesto por ejemplo al meternos con nuestro teléfono móvil en los ascensores o en edificios con estructura de rejilla de acero). Con una simple tela especial -de tipo mosquitera de alambre- podemos fabricarnos de forma casera una caja y simular una jaula de Faraday. En el caso, claro está, que no se disponga de una cámara anecoica en condiciones, que eso es un pelín mas complicado de conseguir :)

Dentro de la jaula, evitando señales externas provenientes de la legítima estación base, se introdujo la falsa estación de telefonía, que se configuró para emitir en la frecuencia deseada (imaginamos que en la banda de frecuencias de uso, 900/1800 Mhz) y con los parámetros adecuados, de forma que el teléfono móvil “víctima” acabó reconociendo esta falsa estación base como auténtica y se registró contra ella. De ésta forma el control del teléfono lo tiene la estación falsa, permitiendo control de llamadas entrantes y salientes, modificación de mensajes, etc. Podríamos plantearnos que si en nuestro radio de búsqueda de cobertura, nuestro teléfono encuentra antes una estación falsa (porque emita con más potencia, por ejemplo) se podría registrar contra ella y no contra la auténtica. Me quedé bastante impresionada con esta charla y la relativa facilidad a la hora de suplantar una legitima estación base de telefonía por una falsa, dejando bastantes preguntas abiertas sobre este tema, además de plantearnos una línea más de investigación sobre la seguridad en éste ámbito y, en general, sobre las comunicaciones móviles.

Dejando un poco a un lado el tema de la seguridad me empecé a plantear el hecho de la posibilidad de construcción de mi propia red móvil e indagué un poco sobre OpenBTS y los proyectos que había relacionados, encontrando bastante información (un link y otro, a modo de ejemplo).

OpenBTS propone un sistema de comunicación móvil con un coste menor, ideal para zonas rurales, o apartadas (como por ejemplo las plataformas petrolíferas). OpenBTS es una aplicación Unix de código abierto que usa el Universal Software Radio Peripheral (USRP), que presenta una interfaz de aire GSM para teléfonos GSM estándar y que usa el software Asterisk para conectar llamadas entre los conmutadores o PBX. La combinación de la interfaz de aire GSM con una distribución de voz sobre el protocolo VoIP sería la base de un nuevo tipo de red celular que podría implantarse y operarse con un coste mucho menor que las tecnologías existentes. Hasta ahora la construcción de semejante red móvil es tan sólo una promesa, y está abierta a iniciativas y colaboraciones. Sin embargo ya se probó su funcionamiento en el festival Burning Man en Black Rock Deserte de Nevada (USA) y en la isla de Niue, en el Pacifico Sur. Los usuarios de teléfonos móviles dentro de este tipo de red pueden hacer llamadas entre sí y, si la red está conectada a Internet, también a personas en cualquier parte del mundo; para ello se necesitaría un periférico de radio de software universal (pieza de hardware barata y fácil de comprar por Internet que se puede ajustar para proporcionar varios tipos de señales de radio; se usaría para enviar y recibir transmisiones de radio entre la estación base y el teléfono de un usuario móvil), el software Asterisk (ya que OpenBTS corre sobre él), una conexión IP (los usuarios de teléfonos móviles en un red OpenBTS pueden comunicarse entre ellos incluso si el sistema no está conectado a Internet, aunque para comunicarte con alguien fuera de la red se requiere obviamente conexión a Internet), una fuente de alimentación (se han hecho diversos experimentos y los resultados obtenidos han demostrado que la alimentación que se consume es muy baja, por lo que una estación base podría funcionar con energía eólica o solar), un teléfono GSM y una antena de acuerdo al rango que el operador de red quiera alcanzar. Como vemos, material muy asequible económicamente y fácil de conseguir…

Por si a alguno se le pasa por la cabeza probar todo esto… RECORDAD que el espectro radioeléctrico se trata de un bien de dominio público cuya TITULARIDAD, GESTIÓN, PLANIFICACIÓN, ADMINISTRACIÓN Y CONTROL CORRESPONDE AL ESTADO. O sea, que es ilegal emitir en el espectro radioeléctrico a no ser que se realice en un entorno concreto y controlado. En la ETSIT de la UPV disponíamos de una cámara anecoica que quizá, bajo un proyecto interesante y justificado, nos dejarían usar para pruebas, pero es sólo una idea… :)

La importancia de las pruebas de restauración (II)

(Continuamos hoy con la entrada de ayer, sobre la importancia de las pruebas de restauración en dispositivos de red)

Backup del sistema

Según nuestra política de seguridad, lo habitual es que se realicen copias de seguridad periódicas de los sistemas, incluyendo por supuesto, la electrónica de red, de forma que, ante una caída, sea posible restaurar el sistema en el mínimo tiempo posible para garantizar el menor impacto a la organización. El proceso de backup del sistema depende del operativo sobre el cual hemos instalado Firewall-1, no obstante, a través de la variable de entorno FWDIR, es posible acceder al directorio donde el sistema esta instalado, siendo <systemroot>\fw1 en sistemas Windows y /opt/CPfw1-65 (dependiendo de la versión) en sistemas Unix/Linux.

Aunque la política de seguridad corporativa especifique que se deben realizar copias periódicas de los elementos de red, es posible que éstas no se realicen correctamente, por lo que, ante un problema con los equipos, el impacto sería crítico para la organización.

Para nuestro ejemplo de recuperación en caso de desastre, vamos a basarnos en una arquitectura distribuida de Firewall-1. Al tener una instalación distribuida, los Enforcement Modules mantienen la última política de seguridad instalada (actualizada), sin embargo, el SmartCenter Server tiene una política obsoleta y todas nuestras copias de seguridad del propio SmartCenter Server están corruptas.

[Read more…]

La importancia de las pruebas de restauración (I)

Habitualmente, cuando realizamos una auditoría de seguridad es muy poco común encontrarse con empresas que no realizan copias de seguridad de sus sistemas, siendo lo común encontrar empresas que realizan copias periódicas (ya sea mediante procesos manuales o software dedicado). No obstante, muchas empresas se quedan ahí; creen que teniendo copia de seguridad de sus sistemas están protegidos ante un desastre, y no nos equivoquemos, en parte, tienen razón. Sin embargo, nada es seguro al 100%, nuestro sistema no iba a ser menos, y en caso de que lo fuera, tranquilos que aparecería Murphy darnos más dolores de cabeza.

Puesto que en nuestra política de copias no podemos incluir a Murphy, tenemos que pensar que realizando copias periódicas, por ejemplo en cinta, manteniéndolas en varias ubicaciones (alguna de ellas fuera de la oficina), protegidas de su deterioro, controlando la caducidad de los soportes y realizando pruebas de restauración periódicas de varios sistemas, estamos protegidos. Y sí, todo esto es correcto, aunque lo ideal sería además, mantener todos nuestros sistemas replicados y sincronizados en un CPD de respaldo, pero claro, cuanto más azúcar más dulce, o dicho de otra forma, cuanto mejor es la solución, más cara de implementar resulta, por lo tanto, nos conformaremos con la situación anterior.

Este tipo de políticas de backup es habitual encontrarlas en empresas de mediano y gran tamaño, donde disponen de equipos para poder hacer pruebas de restauración o incluso sistemas virtuales donde levantar una imagen de un equipo suele ser algo trivial. No obstante, si llevamos este planteamiento a la electrónica de red, la visión es totalmente distinta. La mayor parte de las empresas no suele hacer copia de las configuraciones de sus equipos de comunicaciones (firewalls, switches, routers,..) salvo en contadas ocasiones, y éstas las hacen de forma periódica (mensualmente, trimestralmente), ya que ven muy complicado disponer de hardware donde restaurar la copia de seguridad y comprobar que todo el proceso es correcto.

Recientemente, he tenido la desgracia de encontrarme de frente con un problema de este tipo: una implantación de un cluster Firewall-1 de Checkpoint, con el propio firewall alta disponibilidad y del cual se realizan copias de seguridad periódicas. No obstante, ante un problema software del sistema de gestión del firewall, se ha detectado que las copias, aunque se realizaban periódicamente, no llevaban asociadas tareas de restauración debido al alto coste que supone duplicar los elementos de la infraestructura.

En este post y en los sucesivos, se va a realizar una pequeña descripción de Check Point Firewall-1, tratando de describir mínimamente las características principales y el proceso de recuperación del sistema de gestión realizado, contando únicamente con la información almacenada en el propio firewall, que como se podrá ver a continuación, difiere del resto de sistemas. Lógicamente, Firewall-1 dispone de herramientas propias de backup y restaurado de sus sistemas, por lo que partiremos de la premisa de que el dispositivo en funcionamiento posee la configuración actualizada, y la estación de gestión una copia obsoleta de la misma, no pudiendo recuperarla de las copias periódicas realizadas.

Introducción a FW-1

Firewall-1 es un Firewall desarrollado por la compañía israelí Check Point Software Technologies Ltd.. Firewall-1 se ejecuta sobre diferentes sistemas operativos, tanto Unix/Linux, como servidores Microsoft Windows, o incluso sobre appliances propietarios, por ejemplo la desarrollada por Nokia, cuyo sistema operativo (IPSO) esta basado en FreeBSD. En sus inicios, el sistema Firewall-1 funcionaba únicamente como sistema cortafuegos y concentrador VPN, no obstante, el sistema ha ido evolucionando con el paso del tiempo, convirtiéndose en un sistema UTM, el cual incluye módulos para el filtrado de contenidos, IPS (smartdefense) o QoS (Floodgate-1).

Arquitectura de FW-1

Firewall-1 posee una arquitectura modular basada en tres componentes:

  • Smart Clients: son un conjunto de aplicaciones para gestionar de forma gráfica la infraestructura global de seguridad. La principal aplicación es SmartDashboard, la cual gestiona las políticas de toda nuestra infraestructura.
  • SmartCenter Server: constituye la estación gestora de la infraestructura. Como tal, contiene todos los objetos definidos en el sistema (redes, hosts, servicios, horarios), la base de datos de usuarios, los registros de log del sistema y las políticas del sistema. Los objetos creados son comunes para todas las políticas de seguridad del sistema.
  • Enforcement Module: constituye el propio firewall que implementa la política de seguridad. Tiene dos componentes principales: Inspection Module y Security Server.

El funcionamiento de la arquitectura es sencillo: a través de la aplicación SmartDashboard, nos conectamos al SmartCenter Server donde definimos y almacenamos los distintos objetos y la política de seguridad. Finalmente, el SmartCenter Server realiza una compilación de la información y la distribuye entre los distintos Enforcement Module de la red.

SmartCenter Server define la política de seguridad en un lenguaje propietario llamado INSPECT y la representa como un ‘inspection script’. Dicho fichero es generado para cada Enforcement Module, donde el módulo de inspección (Inspection module) analiza el tráfico y realiza las acciones acorde a la política de seguridad.

Tipos de arquitecturas

Firewall-1 soporta dos tipos de arquitecturas, llamadas standalone y distributed:

  • Standalone: el SmartCenter Server y el Enforcement Module se ubican en el mismo sistema físico.
  • Distributed: el SmartCenter Server y el Enforcement Module residen en sistemas distintos.

De momento hasta aquí, estos son los conceptos básicos de FW-1. En la siguiente entrada veremos en detalle aspectos propios del backup y la recuperación del dispositivo: Backup del sistema, recuperación de objetos y recuperación de la política. Manténganse a la escucha, y si tienen algún comentario, estaré encantado de responderlos.

DNI electrónico (2 de 2): Seguridad

Cerramos con este post, segundo y último, el primer acercamiento al DNI-e, ahora ya hablando no de generalidades sino de la seguridad que posee y de las posibilidades que ofrece al ciudadano o la administración; para empezar, teniendo en cuenta los objetivos principales del documento (acreditar la identidad de su titular electrónicamente y posibilitar la firma electrónica), la información electrónica que almacena el chip del DNI es la siguiente:

  1. Certificado electrónico de componente, que no contiene ninguna información del titular del DNIe.
  2. Certificado electrónico de identificación / autenticación que permite que el titular del DNIe pueda acreditar su identidad electrónicamente.
  3. Certificado electrónico reconocido para firma electrónica, que permite al titular realizar la firma electrónica de documentos.
  4. Datos del titular que aparecen en la superficie de la tarjeta.
  5. Huella dactilar digitalizada, una fotografía también digitalizada y el IDESP.

[Read more…]

Honeynets IV: Tareas y Herramientas

En anteriores entradas sobre honeynets ya tratamos los diferentes tipos de honeypots y sobre las arquitecturas posibles en una red trampa. En este artículo vamos a identificar otros componentes esenciales para completar una honeynet: las herramientas de control, captura, monitorización y análisis de datos.

Como se indicó en el primer artículo, uno de los objetivos buscados a la hora de implantar una honeynet es el de analizar los vectores de ataque de la que ésta es víctima. Para alcanzar este propósito, hemos de tener en cuenta el resto de las tareas a gestionar de una honeynet y las herramientas o aplicaciones que ayudan a acometerlas.

  • Control de Datos: Siempre cabe la posibilidad de que nuestra red trampa sea vulnerada por un atacante o incluso que sea utilizada para realizar desde ella otros ataques a mayor escala. Para mitigar en lo posible este riesgo, es necesario llevar a cabo un correcto control sobre los datos de entrada y salida de la honeynet. Veamos algunos mecanismos:
    • Firewall: Una de las herramientas fundamentales para realizar un correcto control de datos es un cortafuegos (p.e. IPtables). En él se deberá definir claramente el tipo y la cantidad de conexiones que se permite en nuestra red, tanto de salida como de entrada, evitando así la posibilidad de, por ejemplo, recibir o realizar ataques de fuerza bruta. También deberá estar correctamente especificado el tráfico que permitimos de una parte a otra dentro de la propia red, evitando la posibilidad de que el atacante pueda acceder a la parte de administración de la misma o incluso, si existe, a zonas de la red en producción. Todas estas restricciones deberán estar enfocadas a que el atacante disponga de un cierto grado de libertad para interactuar con nuestros honeypots, de lo contrario la honeynet no podrá cumplir con su objetivo. Finalmente, es muy recomendable realizar un control de datos por capas (p.e. cantidad de conexiones entrantes o salientes, restricción de protocolos, restricciones de ancho de banda…) en el que no exista un único punto de fallo y se pueda reaccionar a tiempo ante ataques novedosos.
    • Honeymole: Se utiliza para las granjas de honeypots. Implementa varios sensores que redirigen el tráfico a una colección centralizada de honeypots. Desarrollada y mantenida por el Chapter de Portugal de Honeynet Project.
    • Honeysnap: Herramienta usada para la extracción y análisis de datos de archivos pcap, incluidas las comunicaciones IRC. Desarrollado y mantenido por Arthur Clune del Chapter del Reino Unido.
  • Captura de Datos: La captura y almacenamiento de la actividad, tanto de entrada como de salida, es una tarea fundamental en una honeynet. Un análisis de los datos, ya sea con el objetivo de la formación o aprendizaje, como si es el de analizar un posible ataque fuera de los controles habituales de la red, necesita de una buena recolección de información. Es recomendable efectuar una captura de datos a varios niveles. Podemos diferenciar entre 3 niveles diferentes y complementarios:
    • El registro del Firewall: “Logear” todo el tráfico controlado por el cortafuegos. Es el punto crítico y donde es posible obtener mayor información sobre las actividades llevadas a cabo por el atacante.
    • El tráfico de red: Captura de cada paquete, junto con su contenido (payload), que entra y sale de la red. Para esta tarea, la herramienta más indicada es un IDS (Sistema de Detección de Intrusiones), concretamente se aconseja el uso de Snort, un IDS de software libre usado masivamente por los administradores de sistemas y grupos de seguridad, y que ofrece una configuración y clasificación envidiable. Puede usarse la aplicación BASE (Basic Analysis and Security Engine) para acceder y analizar la información capturada de una forma ágil y sencilla.
    • Actividad del sistema: La captura de la actividad ocurrida en el honeypot es otra parte fundamental para la comprensión del ataque. Esta puede resultar más complicada de lo que en un principio pueda parecer ya que actualmente se utilizan conexiones cifradas. Aún así, si el honeypot lleva a cabo correctamente su cometido, la comunicación será descifrada y podrá ser analizada. Como ya comentamos en el post de la serie que trataba los diferentes honeypots, uno de los de alta interacción, Sebek, está orientado a registrar las pulsaciones de teclado del atacante directamente desde el kernel, lo que nos permite seguir de una forma muy efectiva su actividad en el honeypot.
  • Monitorización de Sistemas: Para comprobar el correcto funcionamiento de nuestros sistemas en la honeynet, es muy aconsejable mantenerlos en constante monitorización. Una caída de un servidor (físico o virtual) provocada por un atacante, un aumento excesivo en el tráfico de red en una zona específica de la red, una subida de carga de CPU, memoria o una reducción del espacio de disco, son posibles síntomas de estar recibiendo un ataque efectivo sobre nuestros sistemas, por lo que estos deben estar controlados y deben ser detectados lo antes posible.
    • Nagios: Herramienta de monitorización de software libre muy popular en los entornos de administración de sistemas. Su modularidad y sencillez, a la vez que las múltiples posibilidades de monitorización que ofrece, la hacen una pieza prácticamente esencial en cualquier red. En el caso de una red trampa, más si cabe.
  • Análisis de Datos: Finalmente, llegamos al objetivo por el cual se implantan y despliegan los honeypots en una red: el análisis y la interpretación de los datos y la actividad recolectados. Para ello podemos consultar todo tipo de ficheros de log creados por cada uno de los honeypots y las herramientas que se han especificado anteriormente, o tratar de centralizar los datos para un estudio mucho más cómodo y completo, pudiendo relacionar actividad y datos provenientes de diversas fuentes.
    • Prelude: Herramienta que recoge y centraliza información concreta y clasificada de los honeypots que se hayan integrado. Esta herramienta dispone de una interfaz web, Prewika, que facilita el acceso a la información recogida para posteriormente analizarla de forma rápida y sencilla. De esta forma es posible tener un centro de control del comportamiento de la honeynet donde poder analizar de una forma centralizada la información recolectada por nuestros botes de miel.
    • Capture BAT: Herramienta de análisis de comportamiento de las aplicaciones para sistemas de la familia Win32. CaptureBAT es capaz de controlar el estado del sistema durante la ejecución de aplicaciones y el procesado de documentos y que proporciona un análisis completo de cómo funciona el software, aún cuando no está disponible el código fuente. CaptureBAT monitoriza los cambios de estado del núcleo a bajo nivel y se puede utilizar con facilidad en diversas versiones y configuraciones de sistemas Win32. CaptureBAT está desarrollado y mantenido por Christian Seifert del Chapter de Nueva Zelanda de Honeynet Project.

Con esto, y a lo largo de cuatro entradas, hemos intentado analizar más o menos en profundidad los aspectos más importantes de las honeynets, serie que esperamos que les haya sido de utilidad. No obstante, si en algún punto quieren que incidamos algo más, o que expliquemos con más detalle alguna cuestión, ya saben que no tienen más que indicarlo en los comentarios.

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

DNI electrónico (1 de 2): Introducción

Recientemente he realizado un curso de formación online de INTECO acerca del DNI electrónico, curso que me ha animado a plantear un post sobre dicho DNI-e “para toda la familia” (esto es, sin entrar en profundidad en el detalle técnico); la información planteada aquí está obviamente extraída de este curso. Y para comenzar, vamos a recordar dos cuestiones fundamentales que se desarrollan dentro de nuestro entorno diario en cualquier parte y en cualquier lugar.

La primera cuestión es el concepto de Identidad, derecho fundamental de todos los ciudadanos y por el cual los gobiernos deben poner a nuestro alcance los medios necesarios para poder demostrar nuestra identidad tal y como declara el Art. 6 de la Declaración Universal de Derechos Humanos: “Todo ser humano tiene derecho, en todas partes, al reconocimiento de su personalidad jurídica“. La segunda de estas cuestiones hace referencia al gran avance tecnológico que hemos vivido y vivimos y por el que se han impulsado grandes cambios en diversos ámbitos como el legislativo, el social, o el económico. Gracias a las nuevas tecnologías han aparecido nuevos servicios, los usuarios cada vez más demandan un mayor acceso a la información a través de Internet, a la tramitación de cualquier tipo, mejores y más servicios tanto a nivel público como en el sector privado y así, con todo esto, surgió la necesidad de comenzar una integración completa por parte de las tecnologías de la información (TI) en todos los procesos de negocio y actividades en las organizaciones, incluida la administración pública, dando como resultado la administración electrónica (eAdministracion). Poco a poco la tramitación electrónica está tomando el relevo de la tradicional, con las ventajas que conlleva, modernizando los servicios empresariales y acercándonos cada vez más a la llamada Sociedad de la Información.

La llegada de la Ley 11/2007, de 22 de junio, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos, supuso un gran impulso para el desarrollo de la eAdministracion; las administraciones comenzaron un proceso por el cual tratan de adecuar sus servicios a los requerimientos de la ley y de los usuarios. Para que la tramitación electrónica se hiciera posible, han sido necesarios nuevos desarrollos y normativas, como es el caso de la Ley 59/2003, de 19 de diciembre, de Firma Electrónica, una herramienta necesaria para la realización de cualquier trámite electrónico con las debidas garantías legales y de seguridad. Pero uno de los mayores avances, y que ha supuesto un acercamiento de las tecnologías de la información a los ciudadanos, ha sido el Documento Nacional de Identidad electrónico, que en España ya está totalmente operativo y su uso cada vez está más extendido a pesar de las largas colas que se forman para obtenerlo :D

El DNI electrónico es fundamental desde el punto de vista de la tramitación electrónica, ya que dota al ciudadano de un conjunto de herramientas y mecanismos para ayudarle a realizar de forma segura y cómoda sus trámites en la Red. Al igual que el DNI convencional, el electrónico es un documento emitido por una entidad reconocida, avalada, acreditada, certificada y apoyada por una legislación, incorporando a su vez un certificado electrónico que debe estar emitido por una entidad acreditada como emisora de certificados electrónicos o CA (Certification Authority) de identificación, de forma que podemos identificarnos tanto el mundo físico como en el electrónico. La CA es la responsable de emitir y revocar los certificados utilizados en la firma electrónica, para lo cual se emplea la criptografía de clave pública.

El DNI electrónico tiene todas las características que el DNI convencional (acredita de forma inequívoca la identidad del titular, su número figura en el 97% de las BBDD de entidades y organizaciones, es obligatorio para la expedición de otros documentos, etc.) y muchas más, puesto que tiene cabida en todo tipo de transacciones y trámites electrónicos. Por supuesto se apoya en un conjunto de leyes determinado, y la Dirección General de la Policía es la encargada de la gestión y mantenimiento de dicho documento (al igual que lo es del DNI convencional). Existe un conjunto de normativas relativas al DNI electrónico, de las que la principal es el Real Decreto 1553/2005, de 23 de diciembre, que regula el Documento Nacional de Identidad, así como sus certificados y otros aspectos.

En lo relativo al soporte físico, el DNI electrónico tiene las siguientes características:

  1. Está fabricado en policarbonato, lo que le confiere una gran durabilidad y resistencia, estimada en 10 años. Como curiosidad cabe decir que el policarbonato podemos encontrarlo en lentes, se usa como materia prima para CD, DVD, cristales antibalas o escudos anti-disturbios.
  2. Incorpora un chip electrónico que en su interior alberga un microprocesador, capaz de realizar operaciones y memoria, donde se almacenan los datos que contiene el DNI.
  3. Dispone de todas las medidas de seguridad disponibles para este tipo de dispositivos.
  4. El soporte físico incorpora un número que lo identifica de forma única, conocido como IDESP, gracias al cual cada DNI electrónico es único.

Por su parte, el chip electrónico que incorpora el DNIe presenta las siguientes características:

  1. Es un chip electrónico de la familia ST19, crypto-processor de STMicroelectronics.
  2. El modelo específico es el ST19WL34, incluye 34 Kbytes de EEPROM segura para almacenamiento de datos personales y 224 Kbytes de ROM de usuario para el sistema operativo y el código de programa. Los 6 Kbytes de RAM de usuario, combinados con la potencia de procesos del microcontrolador securizado de 8 bits, permiten un preprocesamiento rápido de datos y ofrece una retención de datos de al menos diez años.
  3. Este chip incorpora un Procesador Aritmético Modular (MAP) de 1088 bit para criptografía de clave publica, y un motor de hardware DES.
  4. Está certificado EAL4+ según el perfil de protección CEN CWA14169 por el Centro Criptológico Nacional (CNI).
  5. Es un dispositivo seguro de creación de firma electrónica, de acuerdo con el artículo 24.3 de la Ley 59/2003 de Firma Electrónica.

Con esta descripción, creo que cualquiera puede hacerse una idea general (para toda la familia :) de qué es realmente su DNIe. En el próximo —y último de momento— post sobre el DNI electrónico entraremos ya en sus capacidades de seguridad, la información que contiene y el uso que se le puede dar… en breve, en este mismo blog :)

Dropbox: Sincronización de archivos fácil y… ¿segura?

Hace algunos meses oí hablar de Dropbox, un servicio de respaldo de archivos de seguridad basado en web. El servicio se basa en la posibilidad de acceder a un directorio de archivos (MyDropbox), con capacidad desde 2GB (gratuito) hasta 100GB ($19.99 al mes) desde cualquier equipo con sólo instalar el cliente de Dropbox. Por tanto, permite sincronizar archivos automáticamente entre múltiples equipos, por ejemplo el PC de sobremesa, el portátil o el iPhone, de forma realmente fácil. Tan sólo dejando caer un archivo en MyDropbox desde uno de los equipos con el cliente instalado se sincroniza automáticamente en la nube o disco virtual y en el resto de equipos.

Los usuarios de la aplicación pueden acceder a una cuenta de administración para compartir directorios a determinados usuarios, subir ficheros, restaurar versiones anteriores o recuperar archivos borrados. Tiene por tanto soporte para historial de revisiones, de forma que los archivos borrados de la carpeta de Dropbox pueden ser recuperados desde cualquiera de los equipos. También existe la funcionalidad de conocer la historia de un archivo en el que se esté trabajando, permitiendo que una persona pueda editar y cargar los archivos sin peligro de que se puedan perder las versiones previas. El historial de los archivos está limitado a un período de 30 días, aunque en la versión de pago que ofrece el historial ilimitado; el historial utiliza la tecnología de delta encoding.

Una primera aplicación que puede venir a la mente consiste en la simplicidad de sincronizar los archivos de trabajo en la oficina con el portátil personal. Ahí es donde empieza a ser algo serio en relación a la seguridad en empresas. Indagando acerca de la seguridad de Dropbox, los datos se transfieren a los servidores de Dropbox mediante SSL y antes de almacenarlo en sus servidores, se cifra mediante AES-256. Sin embargo, desde la parte de cliente, es una vía de salida de información confidencial al exterior de las empresas, inutilizando las configuraciones de firewalls y exponiendo datos sin control. En mi opinión, aplicaciones como éstas deben incluirse en el grupo de aplicaciones restringidas.

Si el análisis lo hacemos desde el punto de vista de la sincronización de archivos personales fuera del ámbito profesional, sin utilizar la herramienta para manejar información corporativa, también genera ciertas dudas, ya que existen directorios de contenido compartido, pudiendo acceder a información contenida en el mismo y en sus subniveles. Además, una de las opciones de compartición de archivos o directorios consiste en que Dropbox envía una URL de acceso al recurso vía email, sin necesidad siquiera de autenticación en una cuenta de Dropbox, por lo que otro puede acceder al recurso con sólo acceder a la URL adecuada.

Debo confesar que la idea de Dropbox como servicio me parece muy útil, pero creo que a día de hoy tiene mucho que mejorar en relación a seguridad y privacidad. Cabría estudiar si, utilizada junto a herramientas como TrueCrypt, podríamos confiar en su uso. También he leído que se está desarrollando una versión que pueda ser utilizada en las empresas, lo que confirmaría la aceptación del hecho que su utilización con la versión actual no debe ser muy adecuada. La proliferación de este tipo de aplicaciones está haciendo el trabajo aún más difícil al sector de la seguridad, ya que incluye una tarea importante, el control de la instalación de aplicaciones restringidas, no sólo en asegurar que los usuarios no instalan y utilizan las conocidas, sino en permanecer alerta ante nuevas aplicaciones que no cumplan los requisitos de seguridad.

Medidas de seguridad por Geolocalizacion de dirección IP

Aprovechando que se acerca el periodo estival en el cual es posible que decidamos realizar algún viaje, me gustaría comentar ciertas medidas de protección implantadas en diversos sistemas de login relacionados con la ubicación geográfica del usuario. Para empezar, comentar que existen BBDD de IPs que las relacionan con su posición física, de manera que puedes consultar dónde esta ubicada una dirección IP con bastante precisión, hasta el punto de que en el mejor de los casos es posible acertar con la población en la que te encuentras; en el peor de los casos, el acierto se limita al país.

Esto es aprovechado hoy en día por cada vez mas aplicaciones, como por ejemplo para ofrecer servicios específicos para la población en que te encuentras. Por ejemplo en mi caso Google hace publicidad ofreciéndome comercios y servicios por ejemplo de la ciudad de Valencia. Esta información se viene utilizando también de manera habitual para orientar, limitar y prohibir el acceso a los contenidos en función de la ubicación física de la persona. Un ejemplo de ello son las cadenas de televisión que emiten video por Internet, limitando dichos contenidos al país en el que tienen licencias para emitir ciertos contenidos (por ejemplo, eventos deportivos concretos). En España esto es utilizado por La Sexta o Telecinco en sus emisiones de TV Online, ya que no tienen licencias de emisión universales. Por supuesto, estas técnicas le quitan universalidad a Internet, pero eso un tema para otro día. Siguiendo con las prohibiciones (que es casi el uso más habitual), existen BBDD de direcciones IP para poder limitar por países enteros; en http://ip.ludost.net/ tenemos herramientas que permiten incorporar estos límites de países a las ACLs de Apache o iptables, lo que puede ser util si queremos interaccionar solo con un país. Como aspecto positivo, también se utiliza para mejorar la seguridad, en módulos de login o transacciones de compras, siendo una medida habitual en los módulos anti-fraude.

No obstante, como todas las tecnologías están sujetas a imprecisiones y problemas. Por ejemplo, pueden fallar si estás dentro de una WAN de tu organización y los proxys se encuentran en una ubicación remota, ya que los contenidos a los que podrás tener acceso no son aquellos que por tu geolocalización deberías tener. Esto pasa con proveedores de Internet globales como AOL, o por ejemplo, en multinacionales en las que la salida a Internet pueda estar centralizada en una ubicación, a pesar de disponer de sedes repartidas por todo el globo (por ejemplo, la salida a Internet de Ford Motor Company puede estar en Estados Unidos, aunque disponga de fábricas por todo el mundo). Otro punto de fallo es la navegación por dispositivos móviles, ya que también está sujeta a cómo tu operador gestione el tráfico a Internet, o cuando hagas roaming, si estas en modo WiFi, conexiones por satélite, etc. Por último, los proxys de navegación como el diseñado por Opera para acelerar las conexiones a Internet, sufren este problema que pueden resultar en quebraderos y falsos positivos con las consiguientes inconveniencias para los usuarios.

A pesar de todo, el aspecto más positivo de este tipo de información es su utilización para evitar el fraude, de una manera muy sencilla. Por ejemplo, es posible comparar si la ubicación habitual de nuestro cliente y su ubicación actual son cercanas o han variado en miles de km, podemos ver si existen accesos simultáneos a servicios desde ubicaciones separadas miles de km, o analizar si el histórico de conexiones de nuestro cliente cumple cierto patrón. Esto genera contramedidas que ya han sido aplicadas por algunos proveedores de servicios. Por ejemplo, si Facebook detecta que alguien se está conectando desde una ubicación remota desde el móvil, puede cortar el acceso solicitando una conexión desde el PC habitual, o solicitar una serie de datos adicionales (fecha de nacimiento y otras) para su verificación. Por otra parte, Paypal, uno de los mayores objetivos de fraude, si detecta compras desde ubicaciones no habituales del usuario y con entrega en éstas, puede decidir bloquear la cuenta (a quien le pasó esto aún no se si ha podido restablecer la cuenta).

Todas estas medidas están diseñadas para proteger al usuario ante los problemas de fraude, normalmente cuando hay transacciones bancarias, compras de productos, u otros temas sensibles. Desgraciadamente, como todo, tienen su parte de molestia, ya que es probable que si se encuentra en Shangai de vacaciones, puede resultar que su banco no le quiera, Facebook no se fíe de usted y no pueda realizar compras mediante Paypal. En ese caso, lo mejor es dejar el portátil o Smartphone y disfrutar de las vacaciones. La tecnología seguirá ahí a su vuelta.

IDS en el cortafuegos

A la hora de hablar de detección de intrusos, un modelo dentro de los NIDS que no es muy habitual es la detección en el cortafuegos (o en los cortafuegos) corporativo; digo que no es muy habitual -al menos por mi experiencia- y no sé muy bien por qué, ya que bajo mi punto de vista se trata de algo bastante sencillo de implantar en la mayor parte de firewalls, con un mantenimiento simple y, sobre todo, con una tasa muy baja de falsos positivos. Además, creo que le ahorraría bastante trabajo a los sistemas de detección ubicados en las redes internas, algo que en el caso de seguridad pasiva (IDS) se traduce directamente en un ahorro de costes en el personal dedicado a revisar las alertas de un SNORT o similar.

Un cortafuegos suele manejarse muy bien con las cabeceras de los paquetes y menos bien (o simplemente, muy mal) con los campos de datos; así, para hablar de detección en el cortafuegos, podemos centrarnos en los ataques -o en las anomalías, por no hablar aún de ataques- de dichas cabeceras. ¿Y qué información hay en los campos de cabecera de protocolos como TCP o IP? Direcciones origen y destino, puertos origen y destino, información del protocolo, bits URG, FIN, etc. Un montón de información que, correctamente analizada, permitirá bloquear tráficos anómalos que tratan de entrar en nuestra red y nos proporcionará información útil de eventos cuanto menos sospechosos.

Para empezar, lo obvio: de una determinada zona de red -interna o externa- no puede llegar tráfico con dirección origen otra zona de red. Así, si nuestra red de usuarios tiene un direccionamiento 192.168.1.0/24, desde esa red no debería llegar nunca un paquete con origen en otro direccionamiento -al menos, en condiciones normales-, por lo que podemos definir reglas que acoten qué direcciones origen pueden provenir de cada zona de red. Y seguimos con más cosas obvias: hay puertos que deben estar filtrados sí o sí (o casi sí), y cualquier actividad con destino dichos puertos puede ser a priori considerada sospechosa. ¿Quién utiliza hoy en día el protocolo UUCP? ¿Y gopher? ¿Alguien conoce algún uso lícito y habitual de chargen? ¿Y de finger? Si en mi cortafuegos veo tráfico hacia esos puertos, lo más probable es que me encuentre ante un ataque -típicamente un barrido de puertos, un information gathering o incluso malware-, por lo que me va a interesar bloquear y registrar este tráfico. Algunos puertos interesantes para enterarnos de estas acciones -sin menoscabo, por supuesto, de que todo lo no explícitamente autorizado esté cortado en nuestro firewall- pueden ser discard, daytime, chargen, gopher, finger, pop2, biff, r-* o uucp, por citar sólo unos cuantos. En el caso de puertos utilizados por malware, algunos muy conocidos son 12345 (NetBus) o 31337 (BackOrifice), y de la misma forma podemos bloquearlos y registrar su uso con cualquier cortafuegos (ejemplo para ipf, Solaris 10):


block in log quick on hme0 from any to any port = 31337
block in log quick on hme0 from any to any port = 12345
block in log quick on hme0 from any to any port = 70
block in log quick on hme0 from any to any port = 79
block in log quick on hme0 from any to any port = 540
...

Más cosas a considerar; en el RFC 3330 se definen unos rangos de direcciones IP “especiales” -no asignadas, privadas, bucle local…-, direcciones que no deben encontrarse en determinadas patas de nuestro cortafuegos; así, por ejemplo, en la pata de conexión con Internet nunca deberemos ver tráfico -salvo configuraciones excepcionales- que provenga de estas direcciones, y si lo vemos, al menos deberemos prestarle atención:


block in log quick on hme0 from 192.168.0.0/16 to any
block in log quick on hme0 from 0.0.0.0/8 to any
block in log quick on hme0 from 172.16.0.0/12 to any
block in log quick on hme0 from 198.18.0.0/15 to any
...

Seguimos: violaciones de protocolo o uso de protocolos fuera de lo habitual. Por definición de los protocolos TCP e IP, existen ciertas combinaciones de bits que no pueden encontrarse, en situación normal, en las cabeceras de los paquetes; así, no es correcto que un paquete TCP tenga activos los bits FIN y SYN de forma simultánea, ya que eso violaría el protocolo (estaríamos solicitando un inicio de conexión y a la vez un cierre, algo no coherente), ni tampoco está aceptado que una trama IP tenga activos al mismo tiempo los bits DF (Don’t Fragment) y MF (More Fragments). Si vemos tráfico con estas violaciones, se trata de una anomalía -lo de antes, por no llamarle ataque directamente- que nos interesa conocer, ya que los ataques de fragmentación IP o los barridos de puertos en base a violaciones del protocolo TCP son el pan nuestro de cada día (una herramienta como nmap implementa diferentes técnicas de este tipo). Adicionalmente, podemos encontrarnos tramas válidas según protocolo pero no habituales, y que por lo tanto puede ser necesario registrar. Algunas reglas más para ipf (podemos encontrar auténticos recopilatorios en Internet, y escoger las que más nos interesen):


block in log proto tcp all with short
block in log quick on hme0 all with opt lsrr
block in log quick on hme0 all with opt ssrr
block in log quick on hme0 proto tcp all flags FUP
block in log quick on hme0 proto tcp all flags FUP/FUP
block in log quick on hme0 proto tcp all flags /FSRPAU
block in log quick on hme0 proto tcp all flags FSRPAU
block in log quick on hme0 proto tcp all flags SF/SFRA
block in log quick on hme0 proto tcp all flags /SFRA
block in log quick on hme0 proto tcp all flags F/SFRA
block in log quick on hme0 proto tcp all flags U/SFRAU
block in log quick on hme0 proto tcp all flags P
block in log quick on hme0 proto tcp all flags FUP/WEUAPRSF
block in log quick on hme0 proto tcp all flags WEUAPRSF/WEUAPRSF
block in log quick on hme0 proto tcp all flags SRAFU/WEUAPRSF
block in log quick on hme0 proto tcp all flags /WEUAPRSF
block in log quick on hme0 proto tcp all flags SR/SR
block in log quick on hme0 proto tcp all flags SF/SF
block in log quick on hme0 proto tcp all flags /S

Con estas líneas y algunas más tenemos de forma sencilla un mini sistema de detección de intrusos implantado en nuestro firewall ipf (en todos los cortafuegos habituales podemos hacer cosas parecidas), sistema que obviamente puede ser mejorado por todas partes pero que, de momento, será capaz de alertarnos ante tráficos sospechosos; las líneas anteriores, aparte de bloquear el tráfico, generarán un log en tiempo real (man ipmon), log que puede ser tratado con cualquier script para integrarlo en nuestro esquema de detección de intrusos global, que más allá del NIDS habitual debería recoger y procesar los registros todos los sistemas de detección que tengamos implantados, tanto a nivel de host como a nivel de red, para proporcionar información correlada en base a todos los datos de los diferentes IDS. Esto, por supuesto, sin entrar en técnicas que ya se alejan de lo que sería un NIDS en el cortafuegos, como utilizar return-rst en nuestro ipf para “contaminar” los resultados del atacante (útil frente a barridos de puertos) o ejecutar ciertas órdenes del sistema ante tráficos anómalos detectados, que ya es material para otro post :)

Seguridad sectorial (VIII): espectáculos de masas

Sin duda este fin de semana, en el que los amantes del deporte -ente los que no me incluyo- están disfrutando de los mundiales de Sudáfrica y de campeonato de Fórmula I en Valencia, es un momento inmejorable para aportar un nuevo post a la serie sobre seguridad sectorial, en este caso para hablar de los aspectos de seguridad en espectáculos de masas: competiciones deportivas, conciertos, actos políticos o sindicales, concentraciones de todo tipo…

Como en cualquier libro sobre seguridad podemos ver, toda actividad que implica grandes concentraciones de personas tiene implícitas amenazas como las avalanchas, el vandalismo, las agresiones o el terrorismo, por citar unas cuentas; sin duda la última de ellas, el terrorismo, es la más preocupante tanto para los organizadores como para la sociedad en general, ya que la simple amenaza puede causar un grave daño reputacional y cuantiosas pérdidas económicas -imaginemos un estadio que hay que “vaciar” en pleno partido por una amenaza de bomba-, por no hablar de los casos en los que la amenaza se materializa, añadiendo a los problemas anteriores daños materiales y contra la integridad física de las personas. Por ello, cualquier acto con una gran afluencia de personas debe disponer obligatoriamente de determinadas medidas de seguridad, que pueden ir desde el control de acceso -técnico o humano- a los recintos hasta un número concreto de vigilantes o policías; esto es especialmente necesario en aquellos actos en los que la amenaza pueda ser mayor, como los mítines políticos, eventos con una elevada concentración de personalidades o encuentros deportivos de los denominados “de alto riesgo”.

Por fortuna, a pesar de ser la de mayor impacto, el terrorismo no es la amenaza más probable en las concentraciones de masas. Las minorías extremistas o enfervorizadas suelen ser, más allá del terrorismo, el caldo de cultivo ideal para materializar otras amenazas propias de las grandes concentraciones, como las agresiones o el vandalismo; esto es especialmente frecuente en los encuentros deportivos -fútbol sobre todo-, en los que los grupos “ultra” deben ser controlados no sólo durante el encuentro, sino también antes y después de éste para evitar enfrentamientos con otros hinchas. También la actividad de estas minorías puede ser el origen de avalanchas humanas, aunque esta última amenaza puede ser causada de forma fortuita, simplemente por el elevado movimiento de personas en un determinado lugar (todos recordamos los problemas de seguridad que año tras año se producen en la peregrinación musulmana a La Meca).

Para evitar estos -y otros- problemas, en todas las actividades que implican una gran concentración de personas debe disponer, como hemos dicho, de personal de seguridad pública y privada y de medios técnicos suficientes para prevenir y detectar cualquier amenaza, así como para minimizar el impacto en caso de que ésta se materialice (vías de evacuación, Plan Integral de Seguridad, planes de emergencia…). Los organizadores del evento tienen una serie de obligaciones bien definidas desde el punto de vista de seguridad, que en caso de no ser cumplidas pueden acarrear sanciones más o menos duras (tema por otra parte muy discutible, ya que en ocasiones hay casos claros de incumplimiento y las sanciones aplicables son irrisorias).

Para hacernos una idea de la importancia de la seguridad en este tipo de eventos, simplemente unos datos que leía en el número de este mes de Security Management, la revista de ASIS, relativos al mundial de fútbol de Sudáfrica: SAPS (South African Police Service) ha renovado buena parte de su equipamiento de cara a la celebración del evento, incluyendo desde helicópteros a cañones de agua, ha reforzado su personal con 55.000 nuevos oficiales, y 8.500 policías del cuerpo han realizado un curso ad hoc de un año de duración en Francia, cuya Gendarmería tiene experiencia en la seguridad de estos eventos desde el mundial celebrado en 1998 en el país galo. Todo esto son simples números, sin hablar de las medidas organizativas o técnicas implantadas para el evento: perímetros de seguridad alrededor de los estadios, protección especial de altos cargos, control de acceso al país con conexión directa a bases de datos de INTERPOL, etc. Como vemos, desde el punto de vista de seguridad, la celebración de un mundial es mucho más compleja de lo que nos parece a los simples espectadores (y eso sin profundizar en protección de la información, que evidentemente también requieren estos eventos).