Security Art Work

Comenzamos con este artículo una serie de tres entradas en las que se va a mostrar como construir un (relativamente) sencillo laboratorio virtual sobre una única máquina física para la detección y prevención de ataques. Como requisitos previos, el laboratorio se monta sobre un entorno Linux, empleando la herramienta VirtualBox para las máquinas virtuales. Para conectar las máquinas virtuales entre si se empleará un hub virtual mediante la herramienta de virtualización UML (uml_switch).

Este entorno va a estar formado por tres máquinas virtuales: la primera será la máquina atacante (Linux Debian), la máquina víctima (Windows 2000 SP4) y por último la máquina IDS (Linux Ubuntu Server). Esta última dispondrá de una serie de herramientas de monitorización para observar y analizar los ataques producidos desde la máquina atacante a la máquina víctima, y de esta forma localizar un patrón que identifique dichos ataques. En concreto hemos instalado un servidor OSSEC (HIDS), una sonda Snort sobre un MySQL con B.A.S.E. (NIDS) y un analizador de red (wireshark y tcpdump).

Hechas las pertinentes presentaciones, vamos al tajo. Primero de todo, comenzamos creando el hub virtual; en nuestro caso el usuario será jmoreno, el grupo jmoreno y la interfaz tap0:

# tunctl -u jmoreno -g jmoreno -t tap0 
Set 'tap0' persistent and owned by uid 1002 gid 1002 
# ifconfig tap0 10.0.0.4 netmask 255.255.255.0 up 
# uml_switch -hub -tap tap0 -unix /tmp/mipuente 
uml_switch will be a hub instead of a switch 
uml_switch attached to unix socket '/tmp/mipuente' tap device 'tap0' 
New connection 
(Veremos las conexiones a nuestro hub)

A continuación nos creamos tres máquinas virtuales con VirtualBox. La configuración de la red para cada máquina virtual será de “puente o bridge” seleccionando como interfaz “tap0”. Para nuestro laboratorio vamos a asignar las siguientes IPs a cada una de las máquinas virtuales:

Atacante: 10.0.0.1 
Víctima: 10.0.0.2 
IDS: 10.0.0.3

Para finalizar esta primera entrada, inicializamos las máquinas virtuales y comprobamos que la comunicación entre el servidor OSSEC y el cliente está funcionando correctamente. Adicionalmente realizamos una serie de calibraciones sobre el Snort que demuestran su correcto funcionamiento:

Como ven el funcionamiento es correcto. Por tanto en este momento disponemos de un laboratorio donde poder, desde la máquina atacante, explotar las vulnerabilidades de la Víctima, y a su vez, monitorizar mediante el IDS todos los sucesos que ocurren entre ambas máquinas, y encontrar patrones que permitan poder detectar dichos ataques. Por hoy, esto es todo; mañana continuaremos, aunque les recomiendo que, si están interesados y disponen de tiempo, ganas y un Linux para trastear, me acompañen durante estas entradas, e iremos resolviendo los problemas y dudas que les vayan surgiendo.

Algunos tuvimos la oportunidad de celebrar el pasado día mundial de Internet con una mesa redonda sobre Cloud Computing en la que participaron ocho personalidades de distintas multinacionales, de las que solo una de ellas era española. La mesa redonda estuvo moderada por la Consejera de Justicia y Administraciones Públicas de la Generalitat Valenciana y la verdad es que fue bastante interesante, e incluso yo diría que pertinente y adecuada en los tiempos que corren, tanto por la forma, como por el fondo.

Cloud es una moda. Todos estaban de acuerdo en que ya no es una utopía. Es una realidad, pero una realidad de moda. También parecían estar todos de acuerdo que una de las grandes ventajas que tiene este nuevo paradigma (así lo presentan algunos) es la reducción de costes. “Es una nueva forma de hacer outsourcing en un entorno global y virtual”, decían algunos. “Es una forma clara de reducir costes e incluso de incrementar la productividad”, decían otros. La verdad es que en medio de todas estas afirmaciones, vertidas incluso en ocasiones con pasión, yo me preguntaba si no será este otro de esos conceptos que usan las grandes firmas para seguir haciendo negocio con cosas que el resto de los mortales no acaban de entender.

En mi humilde opinión Cloud Computing es un concepto muy interesante que seguro ya tiene y tendrá aplicaciones en diversos campos, ahora bien, la solución a todos los problemas no es el Cloud Computing, ni siquiera es un modelo de gestión o una tecnología disruptiva equivalente, como algunos defienden, a la aparición de Internet. Para empezar, porque es un modelo que ya funciona en la red desde hace tiempo y porque lo único que se ha hecho es bautizarlo con un nombre pegadizo que estoy seguro moverá cifras millonarias en los próximos años.

Se habla de la consolidación de unos cuantos Data Centers gigantes a nivel mundial como proveedores de servicios en la nube y su connivencia con unos cuantos operadores y algunos proveedores de aplicaciones en la misma nube. Se habla del traslado de cantidades ingentes de información a la nube, de información de todo tipo y color, se habla de los inmensos beneficios que le puede suponer para una empresa de tamaño medio hacer uso de este modelo, e incluso, alguno se atreve a poner un ejemplo dónde los ahorros de costes superan el 50%, citando incluso la organización en cuestión.

Yo no sé si esto será exacto o si será una “realidad aumentada”, pero ¿alguien se ha parado a pensar lo que realmente significa esto? ¿Alguien se ha parado a pensar en las implicaciones de seguridad que puede tener el traslado indiscriminado del conocimiento de las organizaciones de todo tipo a la nube? ¿Alguien se ha parado a pensar en el riesgo de la concentración de activos y conocimiento para una compañía o para un estado? Si a veces no pueden las organizaciones confiar en sus propios equipos, ¿por qué van a hacerlo en los equipos de terceros de forma masiva e indiscriminada? ¿No creen ustedes que aunque este modelo tiene y va a tener sentido para algún tipo de aplicaciones e información no lo puede tener nunca para otro?

Yo creo que como siempre se han hecho algunos análisis interesados de las virtudes de este concepto y que se han propagado a los cuatro vientos sus ventajas, pero también creo que no se ha contado de la misma forma sus inconvenientes, aunque me consta que si se han analizado. No hay más que ver el estudio que ha publicado recientemente la Cloud Security Alliance (CSA) [PDF] donde tímidamente o superficialmente (como quieran ustedes llamarlo) analizan los principales problemas de seguridad con los que se encuentra el Cloud Computing llevado a sus extremos. Cloud Computing es por tanto una moda con grandes virtudes y con grandes defectos. Si no se desarrolla con sumo cuidado, el mismo concepto es, en sí mismo, una amenaza para la seguridad de las organizaciones. No conté las palabras que se usaron en la mesa redonda pero les aseguro que la palabra Seguridad salió muchas veces y la usaron todos los participantes en la mesa redonda, incluyendo algunos invitados del público. Evidentemente esto quiere decir algo, ¿no creen?

Seguro que seguiremos hablando del recién nacido “Cloud” porque va a dar mucho juego….

Ayer, leyendo noticias sobre la serie “Lost”, de la cual soy fan, he visto algo que me ha llamado la atención. Panda Security, a través de PandaLabs ha publicado que en las últimas horas han proliferado en los motores de búsqueda numerosas páginas web que distribuyen el falso antivirus (rogueware) “MySecurityEngine”, usando para ello como gancho el final de la serie “Lost”. Cuando alguien busca en Internet información sobre la serie o referencias para visualizar el ultimo capitulo online mediante streaming aparecen como resultados webs falsas que han sido indexadas para aparecer en las primeras posiciones. Cuando el usuario pincha uno de estos enlaces se le pide su consentimiento para descargar algún archivo, como por ejemplo un códec, momento en el cuál se instala el falso antivirus en su ordenador; sorprende la velocidad con la que consiguen crear las webs e indexarlas a través de Google.

También se comenta que no sólo se usa el final de “Lost” para engañar a los internautas; series como Padre de Familia, Glee , la película Iron Man 2, o el reciente fallecimiento del cantante de ‘Rainbow’ o ‘Black Sabbath’, Ronnie James Dio, también son usados como reclamo para desplegar un ataques de Black Hat SEO a través de Internet, es decir usando métodos y técnicas que no son admitidas como legales para posicionarse en los buscadores, pero que son efectivas.

Respecto a la serie “Lost”,algunas de las palabras clave que pueden dar como resultado malware son las siguientes: Lost New Episode April 27, Lost New Episode Time, Lost New Episode Online, Lost New Episode Tonight. Según publican en PandaLabs:

“si pulsas el enlace de alguno de los resultados maliciosos, serás redirigido a páginas como www.1.saveppc2d.xorg.pl o wwww.1.bestfast31p.xorg.pl desde las que se descarga un archivo llamado PACKUPDATE_BUILD107_195.EXE y que corresponde a Adware/MySecurityEngine“.

Los ‘rogueware‘ o falsos antivirus son un tipo de amenaza que consiste en falsas soluciones de antivirus diseñadas para obtener dinero de los usuarios, cobrándoles por “desinfectar” sus ordenadores de amenazas que, en realidad, no existen. Como se indica en la imagen de PandaLabs, las cifras indican que a mediados del 2009 se habían detectado cerca de 640.000 tipos diferentes de falsos antivirus, 10 veces mas que el año anterior. Como vemos este tipo de malware crece de manera espectacular, y se calcula que se infectan aproximadamente unos 25 millones de nuevos ordenadores cada mes, generando unos 34 millones de dólares mensuales. Por supuesto el tema económico es la razón mas importante por la que el crecimiento del malware no cesa. No me extrañaría nada que involucrada en el tema estuviese la Iniciativa Dharma.

En cualquier caso, pasen un buen fin de semana, no se descarguen antivirus sospechosos, y esperamos que el final de “Lost” no nos decepcione…

Noticia de hoy, calentita: un fallo en la web del Ministerio de Vivienda daba acceso a datos personales de solicitantes de la renta de emancipación, permitiendo al parecer acceder incluso a información fiscal de otros solicitantes (datos de nivel medio). Pero no, no voy a entrar en la desgastada discusión de que si esto pasa o no pasa porque las administraciones públicas no tienen una especial sensibilidad ni concienciación en cuanto a sus responsabilidades en el tratamiento de los datos de carácter personal, de si esto pasa porque no están sujetas al régimen sancionador de la LOPD, etc.

Quiero ir por otro lado. A mi juicio este incidente es un ejemplo práctico y claro que hace patente la necesidad de que el Esquema Nacional de Seguridad (ENS) pase de ser una mera declaración de intenciones a una obligación real y efectiva. El servicio de gestión, consulta y seguimiento del estado de tramitación de las citadas solicitudes de renta de emancipación ante el Ministerio de Vivienda es un servicio sujeto, se mire por donde se mire, al cumplimiento de la Ley 11/2007 de acceso electrónico de los ciudadanos a los servicios públicos. El artículo 42 de esta ley decía que se establecerían unos criterios para definir el marco en materia de seguridad, normalización de la información y de las aplicaciones a utilizar para que este acceso electrónico se desarrolle de manera segura. Por eso en enero de este año se publicaron el Esquema Nacional de Seguridad (RD 3/2010) y el Esquema Nacional de Interoperabilidad (RD 4/2010).

El principal objetivo del ENS es definir el marco de confianza necesario para que se desarrolle adecuadamente el intercambio de información entre las administraciones públicas y los ciudadanos y terceras empresas a través de estos medios electrónicos, determinando las medidas de seguridad necesarias que deben cumplir los sistemas de información que les dan soporte. Porque el ENS habla de la seguridad integral, y de que debe ser una función segregada, y de lo importante que es la formación y la profesionalidad, y del marco operacional en el que se deben mover los servicios externos, y de medidas de seguridad sobre sistemas, sobre aplicaciones…

Y esto entronca con la necesidad imperiosa (lo estamos viendo casi a diario en muchos de los proyectos en los que trabajamos) de que se implanten metodologías de desarrollo de software seguro, que integren los criterios de seguridad desde la etapa del diseño de requerimientos de cualquier aplicativo (véase el art. 19 del ENS), y con la necesidad imperiosa de que las empresas de desarrollo acrediten que efectivamente tienen en cuenta estos criterios al desarrollar sus servicios —de hecho el ENS viene a contemplar una reacción en cadena en cuanto a que las administraciones públicas deberán solicitar a sus proveedores evidencias de que gestionan de manera segura los servicios que prestan (ISO 27001, etc.)—.

Y esto —a mi modesto entender— no tiene nada que ver con si eso pasa porque no hay un colegio de ingenieros en informática que ejerza como tal, que si eso pasa porque los telecos están invadiendo las competencias de los informáticos, que si eso pasa porque estas empresas son “cárnicas” o no lo son… (reconozco que este último párrafo casi orienta el post a la sección GOTO…).

No tengo tiempo para extenderme más. Sólo quería compartir con ustedes esas dos o tres ideas que me han venido a la cabeza al leer la noticia que les he referido.

(N.d.E.: El error en la web de la DGT del que Samuel Parra se hacía eco justo ayer va por los mismos derroteros)

Seguimos con la serie sobre Honeynets, esta vez para hablar de las tipologías, que dependerán de los recursos de los que disponemos para implantar la honeynet. Según la tipología, aún siendo válidas todas ellas, estarán más o menos limitadas en el cumplimiento de los objetivos propuestos.

Tendremos en cuenta la clasificación que propusimos en el anterior post donde se diferenciaba por localización. El tipo de honeynet a implantar, bien sea conviviendo con nuestros sistemas en producción o en un entorno totalmente aislado de la organización, marcará las directrices a la hora de decidir que tecnologías utilizar.

Entorno de PRODUCCIÓN

Si nos decantamos por una honeynet integrada en nuestra red organizativa en producción, debemos conocer las tecnologías que forman parte de nuestros sistemas para no utilizar otra que pueda interferir en el modelo productivo. En este caso y como ejemplo, si tenemos una política de seguridad donde se exige que la implantación de nuevos sistemas debe hacerse mediante virtualización, sabemos que la instalación de los diferentes honeypots no podrá realizarse en sistemas físicos convencionales.

[Read more…]

Resulta que el pasado 27 de abril la agencia de protección de datos alemana realizó una queja a Google relacionada con la información Wi-Fi recogida por la flota de coches Street View, que por si no lo sabían, además de realizar fotografías, también capta información de SSIDs y MACs. El departamento legal de Google respondió que la única información Wi-Fi que recopilaban era, en efecto, esa. Es decir, en palabras de Google, que Networks also send information to other computers that are using the network, called payload data, but Google does not collect or store payload data

El caso es que la agencia de protección de datos alemana, que es una desconfiada, se queda con la mosca detrás de la oreja, y a principios de mayo se le antoja realizar una auditoría de esa información Wi-Fi. Y en estas que estamos, Google descubre, atónita y con sorpresa mayúscula, que aunque pensaba una cosa, ha resultado otra. Pensábamos que no, y resulta que sí; qué confusión más tonta.

¿El culpable? Pues de nuevo en palabras de Google, Quite simply, it was a mistake. Al parecer, un trozo de código experimental fue a parar inexplicablemente al código del proyecto a través del que Google recopila SSIDs y MACs mediante los coches Street View, y nadie se dio cuenta. Lo que parece sugerir, si hay que creerse la explicación, que nadie en Google sabía que esa información se estaba recogiendo ni que el código responsable había sido incorporado al proyecto. Entonces, ¿mintió el departamento legal en la primera consulta? The Register dice que no, y lo justifica esto en la estructura interna de Google, eminentemente formada por ingenieros, de manera que es posible de alguna forma que el departamento legal de Google estuviese diciendo la verdad e ignorase la realidad de los hechos. Claro que no sabe uno qué es peor, si que estén mintiendo, o que no sepan cómo se trata la información dentro de Google. En cualquier caso, es razonable suponer que los abogados no sabían qué se cocía, aunque eso no les exima de culpa.

Volvamos al argumento de Google, es decir, que fue un simple error. Lo cierto es que si estuviésemos hablando de un par de semanas, el argumento de Google tendría su parte de credibilidad; quizá no mucha, pero alguna. Pero después de tres años de estar recogiendo información, que según esta nota de Google (en pdf, un certificado de destrucción de los datos recopilados por los coches Street View correspondientes a Irlanda, emitida por la consultora ISEC) ocupa cuatro discos duros, y según cita The Register podría llegar a 600 GB, el argumento no pasa casi ni por una mala excusa. Tres años es mucho tiempo.

Vale. Es cierto que 600GB no son muchos datos para el volumen de información que Google gestiona, pero no es descabellado pensar que durante ese tiempo, y dado que hablamos de treinta países y un número significativo de coches, alguien en algún momento se daría cuenta de que esa información estaba siendo recogida. *Alguien* debería haberse dado cuenta. O quizá la cuestión no era “darse cuenta de”, sino “darse cuenta de y preguntarse si”. Es decir, quizá los ingenieros trataban la información que necesitaban tratar (MACs y SSIDs) y dejaban el resto, sin plantearse qué hacía allí, si era necesaria para algo o incluso si debía ser recogida; eso no es cosa mía.

Resumiendo. Durante tres años, o el departamento legal no sabía qué pasaba dentro de Google con el tema de los coches o miente, y el personal técnico o no sabía qué datos estaba recogiendo o miente. De las cuatro posibles combinaciones, quédense con la que quieran; no estoy seguro de que haya alguna mejor que las demás. Ahora piensen en toda la información a la que Google accede, y toda la que puede estar recogiendo intencionadamente o por “descuido”; en buenas manos estamos.

Acaba de publicarse la noticia de que Microsoft dejará de actualizar la seguridad de los equipos con Windows XP y Service Pack 2 el próximo 13 de Julio, para actualizar únicamente las versiones mas modernas de este operativo. No han querido valorar cuántos equipos dejarán de estar actualizados, pero esta noticia revela la importancia de disponer de un repositorio centralizado para las actualizaciones de los equipos, y sobre todo de monitorizar que dichas actualizaciones se aplican correctamente.

En muchas organizaciones se siguen políticas centralizadas para la instalación de los parches del sistema operativo, para ciertas aplicaciones corporativas, para el uso de los antivirus corporativos con reglas restrictivas, para el uso de accesos externos a la empresa como VPN, etc. Sin embargo, no hay que dejar de lado que la mayor parte de las aplicaciones no permiten una actualización por políticas centralizadas, y que en la mayor parte de los entornos, un equipo suele tener instalados una infinidad de programas (necesarios) cuya actualización no es para nada sencilla, y que van mucho más allá del sistema operativo, Microsoft Office y el navegador. Tampoco conviene olvidar que la aplicación final de las actualizaciones suele depender del usuario, por varias razones.

En primer lugar, aunque las actualizaciones del SO se descarguen e incluso instalen de manera automática, el reinicio posterior que a menudo es necesario suele postergarse días o incluso semanas, porque esa es una de las cosas que al usuario más le molestan; tampoco es recomendable que dicho reinicio se fuerce, porque eso puede provocar algún que otro roce y problemas con personal interno. En segundo lugar, muchos usuarios evitan las actualizaciones de programas de adobe, o los propios navegadores, aunque son relativamente sencillas, ya sea por el consabido “si funciona no lo toques”, por simple pereza o por evitarse interrupciones “innecesarias”. En tercer lugar, tenemos aquellos programas que no proporcionan una actualización a través de una opción “Buscar actualizaciones”, sino todo lo más avisan de la existencia de ésta, tras lo cual es necesario ir a la página del producto en cuestión y volverlo a instalar; ni que decir tiene que si en las situaciones anteriores el usuario evita por todos los medios una actualización relativamente sencilla y transparente, en este caso las molestias son casi inconmensurables. En cualquier caso, hasta aquí el usuario tiene un medio, más o menos fiable, más o menos rápido, más o menos transparente, de actualizar sus aplicaciones y sistema operativo, y el que no lo hace es porque no quiere. Ahí es donde entran las herramientas de inventario automático y las campañas de concienciación y sensibilización de los departamentos de TI.

No obstante, hay un cuarto caso mucho más complicado que el resto, y cuya actualización puede suponer, justificadamente, un dolor de cabeza para usuarios experimentados. Este es el caso de algunas aplicaciones Open Source para Windows, con dependencias específicas de librerías, versiones de programas, entornos, etc. Es decir, básicamente lo que sucede en los entornos GNU/Linux, que han sabido solucionar a través de herramientas como APT, que se encargan de verificar las dependencias de librerias, programas, incompatibilidades, etc. Sin embargo, parece lógico que esto no existiese para Windows, por ser en teoría la antítesis de los entornos Open Source; aunque Microsoft proporciona la herramienta WSUS para la centralización de actualizaciones, lo cierto es que ésta se limita a sus propios programas y al sistema operativo, algo que resulta normal después de todo.

Afortunadamente, para eliminar o mitigar en lo posible este problema, Garret Serrack, desarrollador del departamento de código abierto de Microsoft, ha desarrollado CoApp, que viene a solucionar lo que nos puede suponer un gran quebradero de cabeza, proporcionando un sistema por paquetes similar al APT, pero para entornos Windows. La idea es facilitar la actualización de las aplicaciones de código abierto que tengamos instaladas, solucionando conflictos con múltiples versiones de librerías o 32/64 bits, e incluso ayudar a la actualización conjunta de programas y librerías. Si ustedes hacen un uso habitual de estas herramientas, vale la pena que le echen un ojo, seguro que les resultará interesante.

Como ven, a veces, la seguridad no depende de grandes proyectos, sino de pequeños pasos. Pasen un buen fin de semana, les vemos el lunes.

Aunque la tecnología RFID va siempre asociada —al menos en estos ámbitos, cosa lógica por otro lado— a peligros sobre la privacidad y la intimidad de las personas, lo cierto es que cuando se descubren las posibilidades de futuro de esta tecnología, es fácil quedar abrumado con las infinitas posibilidades que ésta puede proporcionar en innumerables campos, tanto de ámbito logístico y comercial como de seguridad y comodidad. De hecho, gran parte de las cosas que a menudo nos dejan boquiabiertos y nos ponen los pelos de punta en las películas son posibles gracias a esta tecnología. Sirva esta entrada para des-demonizar esta tecnología… de momento al menos.

Podemos empezar con nuestros “vecinos” los japoneses, que como saben en esto de las tecnologías de película siempre están al pie del cañón. Al parecer, existen ya tiendas de ropa en las que todas las prendas están etiquetadas con tags RFID pasivos, a partir de los cuales la infinidad de aplicaciones que pueden desarrollar es casi infinita. Una de éstas es la instalación de probadores con monitores en los espejos y antenas que interactuan con la ropa, de manera que al detectar la prenda podemos ver en la pantalla una imagen de la misma con toda la gama de colores posibles, todos los accesorios a juego con dicha prenda o incluso el mismo catálogo de la tienda. De esta manera, el cliente desde el mismo probador puede seleccionar lo que quiere probarse y qué tallas, mientras los vendedores, que monitorizan toda la información, les hacen llegar al probador las prendas solicitadas. De esta forma, con llevar una sola prenda al probador se puede salir de él con toda la temporada primavera-verano. Hasta el momento, los resultados han sido satisfactorios, ya que se ha conseguido aumentar la cesta media del cliente y destacarse frente a la competencia. Por supuesto, esto impone requisitos en cuanto al personal disponible para la atención de los probadores, y sería interesante ver esta tecnología en acción en una tienda estilo Bershka un sábado por la tarde.

Pasando a los supermercados, las ventajas tampoco se quedan cortas. Por un lado, sería un consuelo poder llegar con el carro de la compra hasta los topes a la caja y que en unos segundos o fracciones de segundo pudiéramos saber el total de la compra, sin necesidad de tener que sacarlo todo, poner primero lo duro y luego lo blando en la cinta, cuidado con los huevos,… y sobre todo, ¡sin esperar haciendo colas de horas! Por otro, aunque intuyo que comercialmente no sería interesante, los carros podrían, mediante una sencilla pantalla de cristal líquido, indicar cuál es el importe total de lo que llevamos en el carro, y facilitar así la planificación de presupuestos (echando al traste toda esa ingeniería que hace que salgamos del super con dos docenas de productos con los que inicialmente no contábamos).

Además, si han sido como yo, de los que han trabajado en comercios, recordarán los inventarios, que se hacían en nuestras muy preciadas 8 horas de los domingos y que luego era compensado con un martes libre que no valía para nada. Pues bien, si todo utilizara tags RFID y antenas óptimamente posicionadas se podrían realizar inventarios en minutos sin necesidad de hacer que todo el personal acudiera a la tienda, lo que reduciría las molestias, los costes y con la posibilidad de generar un inventario mensual, semanal e incluso diario teniendo el stock actualizado en todo momento, reduciendo de nuevo los costes y de manera que nunca faltara producto para el cliente.

Aunque parezcan situaciones a décadas vista, lo cierto es que cada vez son funcionalidades que empezamos a asumir como posibles. Actualmente ya están desarrollando carros de plástico que no interfieran con las señales de radiofrecuencia, y muchas compañías están insertando etiquetas en los productos, primero a nivel de palets para disponer de la trazabilidad del producto en su recorrido logístico, pero en breve comenzarán a nivel de unidades, de manera que en los centros comerciales se puedan aprovechar de este potencial.

Fuera del ámbito comercial tenemos la comodidad de, por ejemplo, el forfait que cada vez más estaciones de esquí han convertido en una simple tarjeta RFID que podemos llevar en el bolsillo. Así, con sólo acercarse al torno, este se abre para pasar al telesilla, no teniendo que llevar el dichoso gancho en la cremallera y evitando tener que disponer de personal que vigile quién lleva y quién no la pegatina. Un ejemplo más reciente y real es la tarjeta del bus que nos ahorra el tiempo perdido en las colas, o las tarjetas de identificación de la oficina que nos permiten acceder al recinto… etc.

No obstante, siempre tiene que haber un pero ligado a una nueva tecnología. Cuanto más se lee, más fácil es encontrar detractores del RFID, que dicen que esta tecnología provocará que perdamos nuestro derecho a la intimidad, o que sólo la utilizarán para crear patrones de conducta del cliente y así poder “atacarnos” con publicidad personalizada y poder tener un control de nuestros hábitos… Ante esto, sólo puedo decir que RFID es el futuro y que no es posible negar la innumerable cantidad de ventajas que puede ofrecernos, muchas de ellas ni siquiera alcanzamos a vislumbrar. Como siempre, la tecnología no es el problema, sino la finalidad con la que se utiliza, y el uso de los datos que se pueden obtener.

RFID está aquí para quedarse, y en lugar de luchar contra ella, es mejor que desarrollemos mecanismos de seguridad y legales para proteger nuestra identidad e intimidad. Es necesario evitar la creación de bases de datos que relacionen al cliente con sus hábitos, que pueda ser explotada con fines malintencionados o simplemente ilegales. Es más, incluso en algunos entornos es deseable dejar de lado la intimidad y la privacidad si eso sirve para incrementar la seguridad de las personas. Piensen en ciertas minas, donde el personal lleva un chip insertado, de manera que en caso de desprendimiento se puede localizar con mayor rapidez a los mineros que han quedado sepultados permitiendo así un rescate mucho más rápido.

Es muy difícil encontrar un compromiso entre seguridad y funcionalidad de la información obtenida con esta tecnología, pero espero que se encuentre pronto para que la seguridad no haga de freno a lo que sin duda es el futuro. Les dejo con un pequeño vídeo explicativo, vía Paloma Llaneza, que aunque está en inglés, no tendrán problemas para seguir:

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.