Security Art Work

Aún recuerdo cuando empecé a introducirme en el mundo de la auditoría y seguridad allá por el año 2001, en una asignatura de la universidad, con un profesor que daba una asignatura enfocada a la gestión de empresas, y pensé este hombre habla de cosas interesantes y no de teoremas y algoritmos que probablemente no emplearé en esta vida. A partir de ese momento comencé a asistir a charlas en las que me dejaba impresionar por la corbata y la dialéctica de los ponentes y asistentes que disponían de sabiduría sobre todos los campos de la materia. Ya sabéis: corbatas, trajes, y retórica (nada nuevo bajo el sol).

Pensaréis que a qué viene todo esto. Pues bien, hubo un momento a partir del cual me di cuenta de que no era oro todo lo que relucía; que no todos los profesionales del sector eran eruditos de las tecnologías ni expertos en todos los campos de la informática. Lo recuerdo como si fuera ayer. Estaba una charla en la que se hablaban de subvenciones relacionadas con proyectos tecnológicos, y en un momento se produjo una discusión sobre LOPD entre dos personas. Uno de ellos dijo que su formación universitaria provenía de un campo diametralmente opuesto a las ingenierías, aunque defendía vehemente sus ideas en cuanto a LOPD. En ese momento me pregunte a mí mismo si mi vecino el charcutero podría firmar un informe de auditoría del RDLOPD.

Releyendo la LOPD obtuve la respuesta, que se imaginarán: efectivamente, mi vecino el charcutero podría firmar auditorías del RDLOPD, lo que más adelante tuve ocasión de confirmar en una charla de la propia Agencia de Protección de datos a la que asistí. Una de las transparencias exponía lo siguiente:

• ¿La auditoría es LOPD? ¿quién debe realizarla? ¿debe notificarse?
• No se define o reconoce el perfil funcional o profesional de los auditores

Resulta curioso que el charcutero pueda firmar auditorias LOPD pero no pueda hacer la prevención de riesgos laborales. Pasado el tiempo podemos llegar a aceptar que esto sea así, pero cual fue mi sorpresa cuando el otro día acabe con el libro de mesita de cama y empecé con el borrador del Esquema Nacional de Seguridad (véase I, II y III) y no encontré ningún requisito para el auditor, más que lo siguiente:

Lo que me hace pensar en la necesidad imperante de subsanar estos “vacíos legales” por el órgano pertinente. Reflexionando sobre esto, me queda claro que no es un asunto trivial, y que realmente si no se ha especificado más detalladamente el perfil del auditor, es por la problemática asociada: ¿a qué colectivos favorecemos y a qué colectivos dejamos fuera? Lo que está claro es que no va a llover a gusto de todos.

No dispongo de cifras pero estamos hablando de algo más que un puñado de millones de euros, y como todos sabréis, todos quieren su parte del pastel, lo que supone un claro conflicto de intereses.

¿Cómo y a quien otorgar la calificación de auditor?

En una de las últimas jornadas que asistí, este fue uno de los temas a tratar y se comentó tangencialmente la creación de asociaciones privadas “sin ánimo de lucro” tanto en el ámbito LOPD como el de la seguridad, que tuvieran el privilegio de nominar auditores a golpe de varita mágica; la existencia de una Sociedad General de Auditores, una especie de SGAE II, me pone los pelos como escarpias de solo pensarlo. Imaginen la cúpula de esa asociación, formada por los directores mejores relacionados de las auditoras y consultoras más influyentes, limitando únicamente la ejecución de auditorías a sus empresas… oligopolio es la palabra que me viene a la cabeza, y no exagero un ápice.

Descartemos este acercamiento al problema por “mercado de libre competencia”, y ataquemos el asunto de los auditores por la vertiente de la formación. Tras examinar el Esquema Nacional de Seguridad, se observa que éste aboga por una vertiente puramente técnica, al contrario que la LOPD, donde se considera de facto la presencia de un abogado en la auditoria, y la figura técnica queda difusa pudiendo ser realizada por cualquier “técnico”.

Por tanto partamos de la hipótesis de que el auditor debe ser ingeniero, pero vamos a hilar más fino. Cojamos un punto del esquema, “4.2 Control de accesos” y veamos qué ingenierías dan formación específica en este punto. Obviamente en Industriales la materia más difícil es “configura tus servidor radius para autenticación remota”, y en telecomunicaciones donde el primer año te explican cómo configurar LDAP para integrarlo con el dominio…

¿Se os ocurre qué ingeniería debería ocupar ese puesto? Una vez más la ingeniería más agraviada, la única que no dispone de atribuciones.

Pero aceptemos que una ingeniería de carácter técnico pueda acometer estos proyectos, y limitamos el agravio comparativo. Pensemos en el futuro en el plan Bolonia, aceptemos los estudios de grado. Llegados a este punto es posible que se cumplan los requisitos y no se dispongan de las destrezas necesarias; ¿cómo damos esas destrezas a las personas?

Una propuesta que se me ocurre sería la creación de un postgrado oficial en seguridad de la información, reconocido por el estado e impartido por universidades públicas, que sería convalidable por aquel titulado universitario que pudiera acreditar X años de experiencia en el sector y los méritos apropiados. Pero queda claro que únicamente el personal cualificado debería acometer este tipo de proyectos y mientras esto no sea así, seguiremos asociando la profesión del consultor de seguridad a la venta de humo.

¿Están ustedes de acuerdo? ¿Qué opinan al respecto y qué alternativas se les ocurren?

(N.d.E. Durante el fin de semana hemos estado haciendo algunos cambios en el blog, para lo que tuvimos que desactivar algunas funcionalidades. En cualquier caso, ahora todo debería funcionar correctamente)

No hace falta que les hable sobre las ventajas de los snapshots. Tener una “foto” del servidor antes de hacer cualquier intervención crítica (o no tan crítica) en ella, es un valor por el que hubiésemos dado un brazo hace unos años. Con la difusión de la virtualización, esta práctica se ha vuelto mucho más común. La sencillez de hacer un simple “click” y tener las espaldas cubiertas hace que se llegue a utilizar más de lo necesario. Pero como casi todo en esta vida, los excesos se pagan. En ningún momento nuestra intención es desaconsejar su uso, al contrario, se pretende compartir errores y problemas tenidos para aprovechar al máximo y con seguridad esta gran herramienta.

La teoría del snapshot en un entorno virtual es sencilla. Cuando se lanza un snapshot, el disco virtual (vmdk) queda en un estado congelado, y se crea un nuevo disco virtual, separado del primero, donde se almacenan todos los cambios generados desde ese punto. Hay que tener cuidado al manejar estos “discos hijo”, intentar manipularlos o cambiar la configuración de estos vmdk, ya que esto puede ocasionar una pérdida total de datos.

Otra cuestión a tomar en cuenta es la generación de snapshots sobre snapshots. Me explico con un ejemplo: antes de una intervención hemos generado un snapshot, todo ha ido bien, pero no lo borramos “por si acaso”. Al poco tiempo tenemos otra intervención en el mismo servidor, y generamos de nuevo otro snapshot. Esto es totalmente posible y se hace habitualmente, pero no creo que sea una práctica recomendable. El resultado es que se van generando “discos hijos”, cada uno con sus puntos de cambios, y al final el disco virtual inicial acaba siendo una segregación de ficheros, los cuales en caso de error son mucho más complicados de tratar. Personalmente, después de una intervención tras comprobar que todo ha ido bien siempre consolido los snapshots, con lo cual se vuelven a fundir los discos en uno sólo. Tal vez el gráfico que se muestra (fuente VmWare) ayude un poco más en la comprensión del problema.

Pero esto no es todo. Uno de los descuidos más comunes es el llenado de los “datastores”, (donde se almacenan las máquinas virtuales) por culpa de estos snapshots. El espacio ocupado por un disco virtual en un datastore es un valor fijo, es decir, si tenemos libre 400Gb y montamos un servidor con un disco de 300Gb, el espacio libre en ese datastore será SIEMPRE de 100Gb. Pero ojo, una vez hagamos un snapshot de ese disco, el vmdk de 100Gb quedará congelado y se generará un nuevo disco donde se irán almacenando los nuevos cambios. Es decir, ese espacio libre que creíamos que teníamos puede llenarse y darnos una sorpresa. Una buena manera de evitar este problema es tener bien monitorizados los datastores de nuestra infraestructura, pero ese es un tema que trataremos en otra entrada….

¿A quién no le han llamado innumerables veces a lo largo del día ofreciéndole tarifas mucho más baratas de telefonía, luz, gas, etc. (aunque no te salgan los números) o el mejor móvil del mercado, a juicio del teleoperador? Es el comúnmente conocido como spam telefónico, técnicas abusivas e insufribles por las que, quien más o quién menos, todos hemos tenido que pasar.

¿Qué puede hacer el usuario en contra de éstas prácticas para defenderse? Bien, por si alguien no lo sabe vamos a hacer un breve resumen de las acciones que podemos poner en marcha al respecto. La Ley Orgánica de Protección de Datos nos ampara en este aspecto poniendo a nuestra disposición los derechos ARCO (de Acceso, Rectificación, Cancelación y Oposición). Veamos un par de artículos interesantes de la ley, resaltado lo que más nos interesa.

En primer lugar, El artículo 6 de la LOPD, Consentimiento del afectado, dictamina:

En segundo lugar, según el artículo 30 de la LOPD sobre Tratamientos con fines de publicidad y de prospección comercial tenemos:

Por lo tanto, tenemos el derecho de conocer en todo momento la identidad del responsable de realizar dicha llamada (la empresa en cuestión), de dónde proceden nuestros datos (que podría ser, como indica el artículo 30.2, por fuentes accesible al público, como las guías telefónicas, o facilitados por los propios interesados, léase por ejemplo letra pequeña de algunos contratos firmados por nosotros con nuestros datos personales donde pone cesión de datos a terceros; de otra forma sin nuestro consentimiento estarían infringiendo la ley) y finalmente exigir que sean eliminados de facto de sus bases de datos o medios que utilicen para almacenarlos.

Lo normal en estos casos es que haciendo uso de sus derechos de “remolonería” y yéndose por los cerros de Úbeda intenten por todos los medios posibles evitar nuestra petición. En tal caso siempre podemos realizar dicha operación mediante el tradicional correo certificado, si queremos asegurarnos que llega a su destinatario (lo cual, cierto, no deja de ser un engorro y el respaldo burocrático de las grandes organizaciones). La Agencia Española de Protección de Datos pone a nuestra disposición unos modelos que nos servirán como base para ejercer dichos derechos, que cumplimentaremos y enviaremos, adjuntando una fotocopia del DNI para identificarnos.

A partir del momento en que la empresa recibe la carta, dispone de un plazo hábil de 10 días para cancelar los datos y 30 días para pronunciarse respondiendo a nuestra petición. Si pasa el plazo legal establecido y no se ha obtenido respuesta alguna ni hemos conseguido nuestro objetivo, podremos proceder a solicitar a la AEPD que nos tutele, como remarca el artículo 18.2 de la LOPD Tutela de los derechos. En otras palabras, ahora sería la Agencia la que se encargue del tema poniéndose en contacto con la empresa en cuestión, con la posibilidad de iniciar un procedimiento sancionador hacia la misma.

Esto es estupendo, pero hay todavía un aspecto que no hemos comentado, que cada día se hace más frecuente y del que poco o nada podemos hacer al respecto. ¿Qué hay de las llamadas con números ocultos/privados? Otra de las tradicionales cruzadas. Todo se vuelve más hosco cuando somos incapaces de identificar a la persona que tenemos al otro lado (cuando no es una máquina, ya que en ese caso estaríamos ante una ilegalidad declarada).

Respecto a esto, el 31 de diciembre de 2009 se publicó en el BOE una modificación que afecta a este ámbito en cuanto a Prácticas agresivas por acoso. Su artículo 29.2 dicta:

Por lo tanto, quedan prohibidas las llamadas comerciales a través de números ocultos, algo que esperemos que se haga notar desde ya. No obstante, esto todavía no significa que queden prohibidas para otros propósitos, y este es el punto que me gustaría resaltar y donde creo los usuarios están más desprotegidos al respecto. ¿Alguien ha recibido decenas de llamadas en un mismo día, durante semanas, a diferentes teléfonos de su domicilio, y escuchar silencio tras descolgar? A un presente le ha pasado. Métase en el mismo saco timos, bromas telefónicas y teleoperadores anónimos varios. En definitiva, no saber quién está realmente al otro lado del hilo telefónico.

Existen multitud de leyendas urbanas acerca de cómo averiguar estos números ocultos: dobles desvíos de llamadas, rellamadas automáticas, programas de identificación de números privados, etc. Muchos aprovechando posibles agujeros de seguridad de según qué operadora, pero nada de manera oficial y menos aun que funcione de verdad. A raíz de esto, curioseando encontré una interesante aplicación, TrapCall, que es capaz de descubrir el número mediante el cual te están llamando en 6 segundos. Estupendo, si no fuera porque por ahora sólo funcionan en las redes de AT&T y T-Mobile.

Aquí en España al menos, las operadoras se lavan las manos al respecto, ya que no te facilitan estos números a menos que se pida por orden judicial y tras una denuncia previa en casos extremos. La única solución que te suelen dar es que desvíes todas estas llamadas con número oculto y que lo hagas tú mismo. Esto que se lo expliquen a mi abuela.

Como veis el tema de la seguridad en las comunicaciones es extenso y podríamos pasarnos el día hablando de ello, desde los innumerables timos que se producen a diario o el más que comentado sistema de escuchas telefónicas del Ministerio del Interior “SITEL” (Sistema Integrado de Interceptación de Telecomunicaciones), sobre lo que por cierto el pasado martes 19 de enero la AEPD publicó el informe de la inspección que podéis leer aquí mismo. Pero todo esto será en próximas entradas.

Por lo demás, pasen un buen fin de semana, ya que mañana no habrá nada nuevo que leer por aquí. Nos vemos el lunes, en el mismo sitio y a la misma hora (o a cualquier otra). Sean buenos.

Hasta el próximo viernes 29 de enero a las 15h, Security Art Work inicia el segundo consultorio online sobre la LOPD y su Reglamento de Desarrollo (pueden ver las respuestas al primero en la entrada correspondiente), a cuyas cuestiones el equipo de consultoría y auditoría de S2 Grupo contestará en la entrada del próximo viernes 5 de febrero, según nuestro mejor saber y entender.

En ningún caso se publicarán datos de carácter personal (correos electrónicos, nombres de empresas, etc.), ni se contactará con los remitentes de las preguntas, salvo que éstos lo autoricen expresamente (y lo consideremos necesario). Pueden remitir las preguntas por correo electrónico a openlopd@argopolis.es, indicarlas en los comentarios o remitirlas vía mensaje privado al usuario securityartwork de Twitter.

Está a punto de salir el nuevo “megaproyecto” web de la compañía y como desgraciadamente sucede en algunas ocasiones, los aspectos de seguridad no han sido revisados previamente a la puesta en producción. Para solventar esto, a última hora recae sobre el equipo de explotación la responsabilidad de auditar el sistema, detectar las posibles vulnerabilidades y decidir si se pueden arreglar, o si por el contrario son de tal magnitud que impiden la salida a producción del proyecto. La presión por parte de la organización en estos momentos es alta frente al equipo de explotación, por lo que las recomendaciones y decisiones que se tomen deben ser firmes y estar fuertemente razonadas.

El equipo técnico auditor mediante la utilización de ciertas herramientas automáticas y otras manuales entrega el informe, en el que aparecen tres vulnerabilidades de criticidad “grave”, cinco de criticidad “media” y tres de vulnerabilidad “baja”. ¿Qué hacemos ahora?

En primer lugar, cualquier responsable en esta situación lo primero que pide es que se solucionen todas las vulnerabilidades, y normalmente un alto numero de ellas son de resolución mas o menos sencilla: cambios en parámetros de la configuración, actualizaciones de versión en productos que no tienen interrelaciones, eliminado de ejemplos de configuración o funcionalidades innecesarias. Bien, con eso eliminamos una parte, pero en nuestro caso hipotético nos encontramos con que seguimos teniendo dos graves, tres medias y una baja. ¿Qué hacer en estos casos?

El siguiente paso es analizar la clasificación habitual de grave, media o baja, ya que es claramente insuficiente y dependerá mucho del proyecto y de la vulnerabilidad especifica. Por ejemplo, una vulnerabilidad grave que produzca una denegación de servicio, es realmente grave si se trata de un servicio en el que la disponibilidad sea un elemento indispensable, pero puede ser una vulnerabilidad aceptable en casos en los que una pérdida de servicio temporal es tolerable. Una vulnerabilidad de XSS puede ser perfectamente aceptable si afecta a una web estática, en la cual no se puedan robar ningún tipo de credenciales ni interactuar con la pagina, si bien hay que tener en cuenta que aquellos XSS que permiten modificar el resultado en el navegador haciendo parecer contenido licito puede llevar a malentendidos como los recientes de la pagina española de la Unión Europea (aunque no se pueda llegar a ella de manera directa sino a través de un enlace como si fuera phising).

En general hay que analizar con detalle como afecta cada una de las vulnerabilidades a las funcionalidades del servicio que se ofrece, y una vez hemos determinado cuantas vulnerabilidades tenemos y cuáles son sus implicaciones, si existe alguna especialmente grave, el siguiente paso no debería tener mucho misterio, aunque decisiones de ese tipo no siempre son fáciles de tomar ni dependen del personal técnico: o se arregla el problema, o no se sale a producción. Por suerte o por desgracia, en ocasiones existen criterios económicos y compromisos de otro tipo que deja poco margen de libertad, por lo que no queda otra que reducir al máximo la vulnerabilidad, trabajar para eliminarla lo antes posible, y rezar si es uno creyente.

Estas clasificaciones sobre las que he descrito de manera informal se encuentran estandarizadas y normalizadas por el FIRST; los detalles están en http://www.first.org/cvss/cvss-guide.html. Para acabar, me he permitido la libertad traducir las clasificaciones generales de vulnerabilidades:

Métrica Base

• Vector de acceso (Access Vector (AV))
  • Local: vulnerabilidades sólo explotables desde el equipo local.
  • Red adyacente: Solo explotables desde la misma red (ataques de N2 por ejemplo).
  • Remoto: Accesibles desde cualquier acceso remoto de red.
• Complejidad de acceso (Access Complexity (AC))
  • Alta: Complejidad en el ataque, combinación de ataques y de circustancias.
  • Media: Complejidad media para un grupo de usuario.
  • Baja: Configuracion y usuarios por defecto.
• Autenticación: Describe si…
  • Múltiple: Si se requieren varias autenticaciones para poder explotar la vulnerabilidad.
  • Simple: Si sólo se requiere una autenticación para poder explotar la vulnerabilidad.
  • Ninguna: Si no se requiere autenticación para poder explotar la vulnerabilidad.
• Impacto en la confidencialidad: Si se ve afectada la confidencialidad.
• Impacto en la integridad: Si se ve afectada la integridad.
• Impacto en la disponibilidad: Si se ve afectada la disponibilidad.

Métricas temporales

• Explotabilidad: Si existen o no exploits disponibles.
• Facilidad de corrección:Si es fácil de solucionar.
• Fiabilidad del informe de vulnerabilidad: En ocasiones se anuncia la existencia de la vulnerabilidad pero no se confirman las fuentes.

Métricas de entorno

• Daños colaterales: Posibilidades que se produzcan daños económicos o humanos por esta vulnerabilidad.
• Distribución de equipos vulnerables: Si el número de equipos que tienen la vulnerabilidad es elevado o no.
• Requisitos de seguridad: Si cumple con los requisitos de seguridad comprometidos por política.

Con esta clasificación el estándar define una serie de ponderaciones para obtener una puntuación exacta que resulta útil para comparar productos, organizaciones, auditorias, etc. Volviendo al origen de este artículo, una valoración global no creo que sea útil para evaluar y decidir si una vulnerabilidad te impide o no que un proyecto pase a producción, por lo que separar dicho valor agrupado mediante esta clasificación es una buena aproximación para analizar el detalle, y en base a éstos tomar las decisiones adecuadas.

En todo caso, lo que hay que tener claro es que antes de asumir el riesgo de tener una vulnerabilidad, por muy leve que sea, hay que conocer todos los detalles y tomar la decisión adecuada. Cosa que, como todos sabemos, no siempre es fácil.

Según parece, el Consejo de Ministros ha aprobado el Esquema Nacional de Seguridad para la administración electrónica del que tanto hemos hablado últimamente (véase I, II y III). El artículo 13 de la primera propuesta de dicho esquema, que aparece referenciado en la página del Esquema Nacional de Seguridad, dice así:

A la vista de esto, y teniendo en cuenta en particular el texto resaltado en negrita…

[Read more…]

A lo largo de mi carrera como estudiante universitario, y más tarde durante mi etapa como técnico de sistemas, me he encontrado a menudo con el tema de debate preferido por el personal técnico —y no tan técnico— de sistemas: Windows vs. Linux. Será que me estoy haciendo mayor para discutir, o que tengo otras preocupaciones, pero lo cierto es que actualmente no es una cuestión que me preocupe lo más mínimo; si quieren saber mi opinión, cada uno tiene sus ventajas y sus desventajas, y el resto es simple miopía (o ceguera, en los peores casos). De cualquier modo, hay veces que esta discusión muta y se convierte en una igual de estéril pero mucho más relacionada a mi parecer con la seguridad, que es de lo que he venido a hablar aquí: open source vs. closed source. Es decir, código abierto vs. código propietario (que me disculpen los puristas del lenguaje y de las licencias si la traducción de Open Source no es la mejor).

Y como por lo general los que más ruido arman son los defensores del open source, lo que vengo a criticar es que sus ventajas ni son tantas ni tan buenas como sus partidarios quieren hacer creer. Aun diría más: la etiqueta en cuestión no sólo no garantiza absolutamente nada en términos de seguridad y/o funcionalidad, sino que puede inducir a engaño y una falsa sensación de seguridad, sobre todo en aquellas personas más “creyentes” en la causa. Ya verán.

Nuestra historia comienza en el momento que alguien afirma que como el kernel de Linux es open source, pues es “obviamente” mejor que Windows, porque eso nos permite modificar su código y adaptarlo a nuestras necesidades, además de que nos aseguramos de que su código sea revisado y validado por miles de ojos, y por tanto esté libre de errores o vulnerabilidades. Francamente, no sé ustedes, pero yo no conozco muchas personas de las que utilizan Linux a diario que hayan echado nunca un vistazo al código fuente del S.O. con intención de hacer algo productivo, entre los que me incluyo; a todo lo que llegué fue a la soberana idiotez de compilar todo el sistema como se puede/podía hacer con Gentoo, pero ello sin mirar ni una puñetera línea de código (que por otra parte, hubiesen dejado en evidencia mis limitados conocimientos de C). En general, cualquier vistazo a los fuentes del kernel es motivado por problemas de compilación, que nunca son problema del código sino de una configuración errónea, conclusión a la que llega uno tras decidir que ya ha perdido bastante el tiempo. Resumiendo, que el código fuente del kernel de Linux está ahí, pero aparte de unos cuantos privilegiados, nadie le mete mano por su complejidad. Y a pesar de esos miles de ojos, periódicamente se publican vulnerabilidades del kernel que se supone que el hecho de que sea código abierto nos garantiza que no deberían estar ahí.

Este último aspecto es algo que me llama mucho la atención del código abierto. Dejando atrás el kernel, hay programas cuyos fuentes son públicos, y protocolos universalmente conocidos que un buen día, después de años sin mayores problemas, resulta que algún genio en estado de gracia demuestra que son vulnerables, si Marte se sitúa en el cuarto cuadrante de Sagitario y en ese momento tienes hambre. Así, sin más. ¿Cómo es que nadie se había dado cuenta hasta entonces? ¿Pero no había miles de ojos? Protocolos abiertos, conocidos, muchas veces implementados, estudiados y revisados… ¿cómo es posible que este tipo de cosas sigan pasando, año tras año? Lo más interesante de todo es: si hubiesen sido código propietario, ¿cuánto tiempo habríamos tardado en descubrir esa vulnerabilidad? ¿Más, o menos?

Hace ya cierto tiempo, fui a parar al caso de g-archiver. La utilidad de este software, que hasta hace un tiempo podían comprar/descargar desde su web aunque era totalmente desaconsejable, es/era facilitar la realización de copias de respaldo del contenido de una cuenta de Gmail. Por fortuna, Dustin Brooks descubrió que su autor, John Terry, no sólo había cometido la estupidez de hardcodear en el código el usuario y la clave de una cuenta de Gmail, sino que además enviaba a dicha cuenta de correo el usuario y contraseña de cualquier usuario que utilizase el programa. Es cierto que esto parece un argumento en toda regla a favor del código abierto, pero lo cierto es que al menos 1700 usuarios confiaron en el programa antes de que Dustin descubriese este problema, lo cual me hace pensar que la etiqueta open source no supone en realidad ningún tipo de garantía sino que además puede llevar a pensar a los defensores del código abierto que el programa está libre de malas prácticas o vulnerabilidades graves.

Es cierto que si dicho programa hubiese sido código propietario, el problema hubiese sido probablemente descubierto mucho más tarde. Claro que eso demuestra simplemente la poca sensatez del personal, y es una lección más de que no hay que confiar en cualquier programa que encuentre uno en Internet, independientemente de si el código está disponible o no. Me atrevo a afirmar que si el tal John hubiese sido un mejor desarrollador (asumiendo que el descuido fue malintencionado y no un trozo de código utilizado para testear que desafortunadamente acabó en la versión de producción), habría sido capaz de ocultar su usuario, su clave y el envío de las credenciales de los usuarios con técnicas de ofuscación, de modo que nadie se hubiese percatado de sus intenciones al revisar el código, más que con un análisis muy exhaustivo… cosa que no es demasiado habitual.

Seguramente saben lo que es el Javascript. La mayor parte de las páginas utilizan algo de javascript, y se utiliza prácticamente para todo (y cada vez más). Además, como es código que tiene que ser interpretado por el navegador del cliente, tiene que ir en claro; si quieres ocultar algo, mejor utiliza flash (o eso creo; francamente, de tecnologías web no sé más que lo justo). Eso parece apuntar a que cualquier desarrollo que hagamos puede ser “robado” por otros desarrolladores. Nada más lejos de la realidad; existen programas para comprimir y ofuscar el código, que lo hacen virtualmente ininteligible para cualquier persona, incluyendo a su autor. Por tanto, el hecho de que dispongamos del código de dichos desarrollos no supone ni una ventaja ni una desventaja; unas veces es una necesidad de tamaño (tamaño del código) y otras una necesidad de protección (propiedad del código).

Podría parecer, llegado este punto, que defiendo que el código propietario es más seguro que el código abierto. Pues tampoco. La muestra son no sólo las frecuentes vulnerabilidades del software propietario como el de Microsoft, Adobe y otros, sino la velocidad a la que dichas vulnerabilidades se descubren cuando alguien está realmente interesado en encontrarlas (véase cualquier código relacionado con DRM). Por tanto, la verdad es que por lo general da exactamente lo mismo; no se fíen ni de uno, ni de otro. Con lo cual llegamos a lo que les comentaba al principio: que la conversación es tan estéril como el del huevo y la gallina, y tampoco sirve para dar conversación a la vecina del sexto en el ascensor. Es más, seguro que te mira raro y piensa que eres un friki; mejor utiliza la previsión del tiempo.

Acabo. Si recuerdan, el principio denominado “Seguridad por oscuridad” (Security thru obscurity) consiste en ocultar los detalles de diseño e implementación —entre otros— de un programa o dispositivo, consiguiendo que el producto actúe como una caja negra y por tanto sus potenciales puntos débiles no puedan ser descubiertos. En principio, eso se considera una mala política, porque además de que la exposición pública incrementa la posibilidad de que sus vulnerabilidades sean descubiertas (algo que como hemos visto no exactamente cierto), siempre hay alguien que acaba descubriendo sus vulnerabilidades, explotándolas, y entonces es cuando decimos que una vulnerabilidad esta siendo explotada “in the wild”. Lo cierto es que eso pasa con código abierto y con código propietario, a pesar de lo que puedan pensar; las vulnerabilidades están ahí hasta que alguien las descubre públicamente, y mientras tanto, quién sabe.

El problema no es, en realidad, código abierto frente a código cerrado. El problema son empresas responsables frente a empresas irresponsables. No me hagan dar nombres, que me entra la risa.

Nada más. Tengan cuidado ahí fuera y pasen un buen fin de semana.

Como siempre ocurre cuando hay una actualización del núcleo de Linux, uno comprueba cuales son las mejoras que este aporta respecto a su última versión para realizar un estudio de riesgos que implicaría la actualización a dicha versión y si realmente vale la pena. Por ello hace unas semanas me encontraba leyendo la información acerca del nuevo núcleo (2.6.32) y leí un apartado enfocado a la virtualización. En él, los chicos de Red Hat habían aplicado un concepto que normalmente se emplea en los sistema de ficheros, pero esta vez aplicando la idea a la memoria principal; se trata del COW o copia en escritura (Copy On Write).

Para explicar la nueva mejora vamos a exponer primero el funcionamiento de la tecnología COW aplicada en los sistemas de ficheros de entornos virtuales. COW emplea ficheros Sparse: ficheros distribuidos en bloques, donde existe un índice que indica qué bloques están ocupados. Por ello, podemos crear ficheros de un determinado tamaño, y sólo ocupará espacio realmente el tamaño de aquellos bloques que tengan información valida. Por ejemplo, antes si yo quería crear un fichero vacío de 1GB, el fichero se creaba pero ocupaba 1GB aunque no contuviese ningún tipo de información. Con los ficheros sparse puedes crear un fichero vacío de 1GB y éste ocupara sólo 4Kbyte.

Y dirán, ¿pero cómo puedo emplear esto en la virtualización? Pues muy sencillo. Imagínense que tienen un entorno con 20 máquinas virtuales en las que la única diferencia entre cada máquina virtual son un par de binarios o ficheros de configuración; por ejemplo, varios servidores Linux Debian. Con la tecnología COW usted puede tener un único fichero de tamaño X para todas las máquinas virtuales y un fichero COW para cada máquina virtual. Los ficheros que se modifiquen en la máquina virtual se escribirán única y exclusivamente en el bloque modificado del fichero COW de la máquina por lo que, si la distribución ocupa 1GB, en vez de necesitar 20GB (1GB x 20 máquinas virtuales) necesitará 1GB más lo que ocupe cada COW, que serían de media entre 10 y 50MB. Es decir, que con menos de 2GB es posible tener 20 máquinas virtuales totalmente independientes en vez de necesitar 20GB.

A su vez, se habrán dado cuenta que es la tecnología que emplean la mayoría de productos de virtualización para hacer una captura del estado actual de una máquina virtual, ya que lo que hacen es guardar el estado actual y todas las modificaciones posteriores se realizan sobre un fichero COW en lugar de sobre la imagen, por lo que para volver a un estado anterior, únicamente requerirá eliminar el fichero COW.

Además, esto presenta una mejora de rendimiento, puesto que es muy probable que una máquina solicite al sistema de ficheros un dato que previamente haya sido ya solicitado por otra máquina virtual y se encuentre ya en la memoria principal, por lo que no será necesario tener que cargarlo de disco a memoria, obteniendo un aumento considerable de la velocidad. Incluso se permite el lujo de poder cargar mediante tmpfs la imagen de la distribución totalmente en memoria principal puesto que no es lo mismo tener cargado 20GB en memoria principal que 2GB, ¿verdad?

El problema de esta tecnología es cuando se emplean máquinas distintas puesto que al final hay más bloques modificados en el fichero COW que en la imagen centralizada. A su vez, no todas las tecnologías de virtualización soportan este tipo de ficheros por lo que hacen que no se explote toda la capacidad de la tecnología COW.

Entonces, han pensado los chicos de Red Hat… ¿Por qué no aplicamos directamente el principio de la tecnología COW a la memoria principal? Si un dato que fue solicitado anteriormente por una máquina virtual se encuentra ya en memoria, cuando otra máquina virtual solicite ese mismo dato ¿que lógica tendría solicitar el dato al fichero en disco, tardando más y ocupando en la memoria datos replicados? Para ello, lo que se hace es revisar la memoria en busca de datos replicados, eliminando el dato replicado y suministrando a las máquinas virtuales los datos de la única copia que hay en memoria principal. De esta forma se consigue incrementar el rendimiento, puesto que se solicitan menos datos al sistema de ficheros, mucho más lento que la memoria, y se consigue un ahorro de memoria principal muy grande, por lo que con una misma cantidad de memoria principal se podrá virtualizar un número mayor de máquinas.

A la aplicación de los principios de la tecnología COW en memoria se conoce como deduplicación de memoria. En el caso del kernel Linux usa el hilo KSMd (Kernel Samepage Merging) para revisar la memoria en busca de áreas idénticas, eliminando las copias y conservando solo una de éstas. La prueba de concepto fue realizada sobre un servidor de virtualización con 16GB de memoria principal donde se hizo funcionar hasta 52 máquinas virtuales Windows XP concediendo 1GB de memoria principal a cada máquina virtual.

¿Les ha quedado alguna duda?

(Una vez pasadas totalmente las fiestas navideñas, retomamos con esta entrada la programación y periodicidad habitual, esperando que sigan con nosotros y que los Reyes Magos les hayan traído muchas cosas)

Hace cerca de 10 años que soy usuario de Linux; no por que lo considere mejor ni peor que otras opciones, sino porque es la opción que más se adapta a mis necesidades. Desde mi primera Linux SuSE 5.3 que compré en un kiosco con su increíble KDE 1.0 recién salido al no disponer de Internet por aquellos entonces, he usado en casa Linux. De SuSE pase a RedHat, luego a Debian, seguir con Gentoo durante 3 años, y actualmente uso Ubuntu. Sí, sé que es raro pasar de una Gentoo a una Ubuntu, pero la comodidad que me aporta, el gran número de paquetes disponibles y la versión actualizada de éstos me ha convencido para ser mi distribución.

Como ustedes sabrán las versiones de Ubuntu están formadas por dos cifras separadas por un punto: la primera cifra indica el año y la segunda el mes de la fecha de cuándo se va a lanzar la versión final. En concreto la última versión ha sido la 9.10 (Octubre del 2009).

[Read more…]

Una de las mejores definiciones que he leído de Seguridad es aquella que dice que la Seguridad es una sensación. Las personas tenemos la sensación de estar seguras o inseguras en base percepciones, estímulos que recibimos del entorno y que nos hacen sentirnos de esa manera.

El otro día en una conversación con unos amigos en la cual estábamos recordando anécdotas del verano, con mucha morriña por supuesto, uno de ellos comentaba que este verano en su casa del pueblo había pasado algunos momentos de intranquilidad y quería poner remedio para que el verano que viene no le pasara lo mismo.

En esta casa mi amigo tiene una pequeña piscina, y a lo largo del verano había recibido muchas visitas de familiares que venían con niños pequeños de edades entre 2 – 7 años, no se trataba de visitas puntuales sino que eran estancias de varios días. El tener niños correteando por la parcela y en los alrededores de la piscina, le había hecho estar muy intranquilo teniendo que estar pendiente todo el rato por si acaso algún niño se caía al agua.

[Read more…]