Hace unos días, investigando sobre programación concurrente, sistemas operativos de tiempo real y sistemas de alta confiabilidad, me encontré con este supuesto white paper: Linux in Defense: An Urgent Threat to National Security.

Para extraer rápidamente las ideas más importantes:

• Linux es un sistema operativo que jóvenes delincuentes (algo así como crackers) hackean en su tiempo libre.
• Si eso pueden hacerlo unos adolescentes aburridos, imagínense lo que pueden hacer organizaciones de gobierno enemigas o terroristas.
• Siempre hay una lista de vulnerabilidades pendientes, porque el sistema siempre tiene errores.
• Gente mal intencionada puede insertar troyanos en el código fuente de Linux ya que es de código abierto.
• La CIA insertó troyanos en software que luego utilizaron los soviéticos, así que bien pueden nuestros enemigos estar insertando troyanos en estos sistemas de desarrollo colaborativo y open source.
• La solución es utilizar el sistema operativo de esta compañía, closed source, seguro y que nunca fallará.

Mis anotaciones al supuesto white paper:

• No es un white paper: es una publinota. El artículo está escrito por el CEO de la empresa que lo publica, fabricante del sistema operativo Integrity.
• Linux no es hackeado por adolescentes rusos en su tiempo libre, ese es Microsoft Windows, sistema closed source. Y por adolescentes americanos también, entre otros muchos países.
• Si en los sistemas colaborativos se pueden insertar troyanos, ¿por qué no en el closed source? Con más razón un troyano insertado en software closed source será más difícil, o imposible, de detectar. El mismo ejemplo que pone el autor acerca de la CIA lo demuestra.
• La solución no es desconfiar del software open source, sino controlarlo de cerca, al igual que se haría con una solución closed source de un contratista privado y nacional. Incluso controlar la seguridad de un sistema open source será más sencilla, ya que muchos problemas habrán sido descubiertos por la comunidad de desarrollo.
• Si siempre hay una lista de vulnerabilidades es porque el sistema evoluciona constantemente. Para hacer decrecer la lista se debe detener la incorporación de nuevas características. Esto sucede en el mundo open source y en cualquier otro, nada más que resulta visible en mayor o menor medida para el público.
• Todo sistema tendrá fallas y nunca será perfecto. Nunca existirá un sistema 100% seguro, y esto es algo que sabe casi todo el mundo, por lo que no se puede proponer una solución porque es perfecta.

Está bien demostrado que lo mejor que se puede hacer por la seguridad y estabilidad de una pieza de software es la utilización del esquema open source.

Dos cerebros suelen pensar más que uno. No digo mejor sino más, y eso es esencial para descubrir problemas en el software, donde se deben descubrir problemas en lugar de las soluciones.

¿Cómo se puede sostener, por ejemplo, que un compilador de C desarrollado por 20 programadores es mejor que GCC, desarrollado por miles? Suponiendo que se parten de los mismos objetivos, siempre será mejor que el código sea visto/desarrollado/revisado por la mayor cantidad de programadores posible.

Sí sí, otra vez vuelvo sobre el tema, porque realmente es de nunca acabar. Bueno, es la fuerza que tienen las leyes comprobadas de la ciencia.

Como en muchas otras empresas, trabajamos con servidores de prueba y de producción, separados. En uno de ellos se lleva a cabo el desarrollo y testing de las aplicaciones y luego de superadas ciertas etapas se “sube” a producción, en donde el código tiene su feliz vida dentro de la aplicación real que navegan los usuarios finales.

Hoy quiero contar algo que me pasó en estos días, al intentar subir unos cambios a una aplicación, alojada en un servidor que también me toca administrar. Entre los servidores de desarrollo y producción, en este caso, hay algunas diferencias, pero no demasiado sustanciales. De hecho, no afectan para nada el desarrollo y, casi el cien por ciento de las veces, todos los cambios se limitan a una simple transferencia de archivos.

Hoy fue la excepción. En ciertos casos de uso… bueno, con algunas urls, parte de la aplicación dejó de funcionar. Vueltas y vueltas, configuración de php, investigar las reglas del mod_rewrite, url encodings… ¿qué está sucediendo?

En desarrollo todo iba perfecto, pero en producción, con ciertas combinaciones de caracteres en la url, se obtenian errores 400 alias “bad request” que, junto al 500 (”internal server error“), formaría algo así como la pantalla azul de la muerte para Apache.
Como casi todos los problemas insondables del universo que alguna vez fueron resueltos (y seguramente lo mismo pasará con los que no lo fueron aún), di en la tecla por una suerte de inspiración momentanea, o iluminación. La fuente del problema era una regla del mod_security.

Claro! En desarrollo no lo utilizamos tan severamente como en producción, y el error se veía tan genérico que ni se me ocurrió. Se me ocurrieron decenas de otras causas antes de dar con la correcta.

Ahora bien: ¿qué tiene que ver con el título de mi post? ¿Seguridad y usabilidad? ¿Dónde?

La usabilidad no es sólo de los usuarios. Hace rato que observo diariamente lo que yo llamo “usabilidad del código“, o como quieran llamarle. Se trata de la facilidad de edición de un programa, por ejemplo. En este caso, la facilidad de subir cambios a un servidor de producción.

Como en producción (o live) tenemos reglas más severas, a veces se producen este tipo de cosas inesperadas.

Para dar otro ejemplo un poco más simple: transferir archivos por ssh es un poco (mínimamente) más incómodo que por ftp liso y llano. Pero, por seguridad, nos molestamos un poco más y lo hacemos bien.

Si quisieramos que todo fuera más cómodo, deberíamos bajar nuestros niveles de seguridad. Mientras que si queremos sistemas más seguros, perdemos un poco de comodidad diaria.

La comodidad diaria no es otra cosa más que la usabilidad o, en otras palabras, esos cachitos de felicidad imperceptibles para nuestra consciencia que alguna parte de nuestro cerebro disfruta cuando todo va bien.

Y la seguridad no es otra cosa más que ponerle trabas a esa comodidad. Porque para estar más seguros tenemos que pensar más a través de todo el proceso, y pensar no nos resulta cómodo.

Hoy me encuentro con un artículo muy interesante en el blog de los amigos de Hispasec.

Resulta que una persona se hizo con las claves de las cuentas de correo de cientos de embajadores y altos mandos corporativos a través de la explotación de la red TOR.

La red TOR es un sistema de enrutamiento anónimo. Es básicamente un proxy que ofusca de tal manera el tráfico de los paquetes a través de distintos nodos alrededor del mundo que, prácticamente, es imposible rastrear el origen de un paquete. Es utilizada para navegar de manera anónima.

Si bien todo el tráfico dentro de la red es cifrado, el último tramo no lo es. Esto quiere decir que todo el tráfico que se enrute a través de un nodo TOR, si éste es el último de los nodos que recorrerá nuestro paquete, puede ser capturado directamente, sin más tecnología que un sniffer.

Este ha sido el origen del robo de contraseñas. El atacante instaló varios nodos TOR (cualquiera de nosotros puede abrir un nodo TOR) únicamente para minar su tráfico.

Nuevamente, debemos decir que la inseguridad no está en TOR, sino en la ingenuidad del usuario. O, mejor dicho, el desconocimiento que de cosas tan técnicas tienen los usuarios.

Como bien explican en Hispasec, si no se utiliza el cifrado punto a punto (como SSL), no puede garantizarse la privacidad de los datos en tránsito.

¿Podemos culpar a los usuarios de no conocer a fondo los detalles técnicos del enrutamiento en internet, o de los protocolos de cifrado y de control de tráfico? Por supuesto que no.

Tratándose de usuarios gubernamentales y corporativos, supongo que el mayor peso de la culpa debería recaer sobre los respectivos departamentos de sistemas. Pero claro, todos sabemos que los usuarios suelen tomar iniciativas propias y más hoy en día, cuando los instaladores de software y wizards de configuración facilitan todo al punto de poder prescindir de todo “departamento” de sistemas.
Pero muchachos, de todas formas van a culparlos. “¿Por qué no me avisaste?“… simplemente porque no sabía que lo estabas haciendo. ¿Entonces debemos monitorear todo lo que se hace?

En todo caso vuelve a repetirse la historia: la seguridad es la inversa de la usabilidad.

Les hago llegar la información sobre un seminario que se dictará este lunes en el Aula Magna de la UTN. El seminario es gratuito y está abierto a la comunidad. Está a cargo de Luciano Bello, experto en seguridad informática y desarrollador Debian, reconocido en el ámbito linuxero.

Los temás serán:

• Teoría: Criptografía fácil y útil
  Critografía simétrica y asimétrica. Funciones de hash
• Uso seguro del correo
  Ejemplos de mails firmados y cifrados PGP Web of trust Envio de un ejemplo y chequeo
• Ataques a usuarios domésticos
  Malware (Botnets) Análisis de los antivirus. Precauciones en el gestor de correo Phising
• Transacciones Financieras en la Web
  Que es SSL. De qué nos protege. Cómo funciona PKI Que chequear cuando ingresamos a un sitio con seguro Precauciones a tener en cuenta. (Keyloggers/teclado virtual)

Cuándo
19:00 hs del Lunes 16 de abril de 2007.
Dónde
Sede Medrano de la Universidad Tecnologica Nacional
Medrano 951 - Aula Magna
Capital Federal, Buenos Aires. Argentina
Sin duda de interés para todo usuario de ordenadores ;)

Mil veces escuchamos decir -y un par yo también repetí por ahí- que PHP es seguro, que las inseguras son las aplicaciones creadas sobre este lenguaje.

Pues, ahora alguien que se supone sabe mucho del código fuente del mismísimo PHP (o esa que no es un phpichi -gracias Cafesolo) decidió hablar definitivamente del tema, nada más y nada menos que para decir que internamente es un desastre.

Son realmente inimaginables las consecuencias que puede tener la divulgación de algún fallo que nos involucre a todos, a todas las aplicaciones web del universo.

Link con información, de Hispasec.

¿Alguna vez se te ocurrió que usando el Visual Studio podías llegar a embichar tu pc? Pues, hermano, si abres archivos manipulados a tal efecto podés instalarte alguna de las tantas porquerías que andan por ahí.

La noticia completa en Hispasec, siempre tan correctos.

Larga vida al gcc.

Acabo de ver que bajó como actualización de Windows el Internet Explorer 7.

No lo instalé porque se interpuso no sé qué cosa de Windows legítimo… así que quedó en el arcón de las actualizaciones que nunca serán.

Tiemblo de sólo pensar en IE7. Las betas que probé eran malísimas. ¿Tendremos que salir a inventar nuevos hacks para nuestros sitios?

Si no lo hiciste, HACELO YA
www.getfirefox.com

Los sistemas de Apple siempre se han caracterizado, o al menos esa es la creencia popular, de ser más seguros que otros sistemas de la actualidad. Es cierto que el sistema está bien diseñado (es un Unix en el fondo), pero también es cierto que la popularidad propia de los equipos es bastante reducida (compárese con las PCs) y eso hace que los estímulos para crear este tipo de software (para generar dinero con la venta de publicidad) sean menores.

Desde Hispasec nos desayunamos hoy con la noticia de que se ha creado una prueba de concepto que demuestra que es posible instalar un adware sin interacción del usuario (generalmente los problemas de seguridad no vienen tanto por vulnerabilidades propias de los sistemas, sino por acciones de los usuarios) y sin privilegios de administrador. Esta noticia, creo, no deja de ser una pequeña bomba.

Les dejo el link: aquí.

Sí, sí, acaba de empezar a andar el ssl para nuestro Apache.

¿Para qué nos servirá? Si bien no estamos certificados por una autoridad certificante (por ejemplo Verisign, un gigante), ahora podemos comunicarnos con nuestros servidores de manera segura, y trabajar con la tranquilidad de que el tráfico no puede ser interceptado y/o modificado. (Tana: te acordás las clases de “”"”seguridad”"”" de PG ?? jajaja). Esta tranquilidad es fundamental para tareas administrativas, que realizamos, obviamente, a través de la red :).

Estuve muchas horas luchando, y al final, como siempre, resulta que no andaba por una pavada. Había que decirle al Apache que escuche en el puerto 443 :)

Gracias a mantisa, que desde el cielo de los servers nos acompaña. Amén.