La Seguridad en el origen: Unix e Internet

El tema de fondo en éste y otros artículos es la seguridad informática y de ahí el título cuando se desarrolla un texto que pretende comentar unos cuantos aspectos muy importantes para entender la cuestión: cómo fueron las cosas al principio. Pero un título más correcto para el contenido de este artículo debería de ser: "La Inseguridad en el origen: Unix e Internet"

La historia de Internet comienza en los años 70 y he hablado de ella en unos cuantos artículos. La historia de Unix está fuertemente entrelazada con la de Internet, al punto de que podrías pensar que durante décadas Internet ha sido la forma de conectar sistemas Unix y no estarías muy lejos de la idea.

Lo más importante es tener en cuenta que tanto Unix como Internet se desarrollaron bajo la tutela de universitarios más o menos organizados. Fueron ellos los que decidieron usar el protocolo TCP/IP para las conectar redes completas entre sí, en lugar de utilizar algún sistema "punto a punto" como el telefónico tradicional. Por su parte, Unix en su primera encarnación no incluía Internet, pero desde la segunda versión ya incluía el protocolo de comunicaciones en su propio núcleo.

No siempre es fácil valorar la importancia de ese origen: la inmensa mayoría de usuarios han conocido y utilizado internet en los últimos 20 o 25 años, y una mayoría abrumadora de éstos lo han hecho desde una computadora de escritorio doméstica, y con casi total certeza utilizando el sistema operativo Windows. Nada que ver con el investigador universitario de San Francisco que compartía su investigación con otro investigador canadiense y que intercambiaba correspondencia (electrónica) con otros investigadores europeos.

Empecemos por Unix es un sistema multiusuario. Eso significa que un montón de usuarios diferentes pueden utilizar el sistema de forma simultánea. Nuestro investigador de San Francisco probablemente compartiría el equipo de su departamento, o con menos suerte, o de varios departamientos, con otra decena de usuarios o más. El investigador canadiense estaría en una situación similar, al igual que los europeos. Al principio Unix no incorporaba cuentas de usuario: uno se conectaba, usaba el sistema para lo que fuese, se desconectaba y listo. Hay varias razones generales para añadir un sistema de control de quien se conecta, todas ellas fundamentalmente económicas: una puede ser asegurarse de que el sistema lo utilizan aquellos para quienes está destinado realmente el sistema, lo que garantiza su eficiencia y disponibilidad; otra más evidente es el cobrar por cada cuenta de usuario, que de hecho fue el modo general de negocio de las distintas empresas que proporcionaban sistemas Unix.

Sin embargo, ni la privacidad ni la seguridad aparecen remotamente. Contaba Stallman en alguna entrevista que cuando en su universidad se comenzó a incorporar el sistema de cuentas de usuario, ellos se dedicaban a obtener dichas claves, a enviársela a sus dueños en un correo tal que así: "tienes una cuenta en el sistema Unix con la clave laquesea. Esa clave es un rollo, ¿por qué no haces como nosotros y utilizas en su lugar secreto, que es más fácil de recordar?" Y es que pese a las políticas de las empresas que proporcionaban acceso a servidores Unix, el sistema operativo en sí estaba pensado para facilitar el trabajo en grupo y la colaboración. Es cierto, la seguridad, tal y como la entendemos hoy, nunca estuvo entre los principios de diseño de Unix. Unix era seguro en otro sentido: fiable, robusto, accesible.

Es interesante que 40 años después Linus Tolvards siga los mismos principios para su núcleo Linux. Según él, la seguridad debe de proveerse con herramientas específicas para el grado de seguridad requerido, y debe de estar fuera de la política general de desarrollo del núcleo del sistema operativo. Es uno (más) de los debates más interesantes alrededor del desarrollo de Linux. Las empresas que distribuyen el sistema para su uso empresarial están interesadas en garantizarle la seguridad a sus usuarios, y por ello consideran que los informes de fallos de seguridad deben de atenderse con más inmediatez que otros errores. Para Tolvards, en cambio, los errores de seguridad no dejan de ser errores a subsanar como los demás y, por tanto, no requieren de ningún trato privilegiado. Una vez le argumentaron qué pasaría si "una central nuclear que utilizase un sistema Linux y que estuviese conectada a Internet pudiese tener un fallo de seguridad aprovechable por un terrorista", a lo que Tolvards replicó preguntando quien, en su sano juicio, podía conectar una máquina tan sensible "con Internet".

El desarrollo del protocolo de comunicaciones de Internet, TCP/IP, estuvo marcado por principios similares a los que inspiraron Unix. En este caso, el protocolo pretendía ser una forma sencilla y eficaz de conectar redes de computadores, pero no muy eficiente. Veamos: tú tomas el fichero que quieres enviar por Internet y lo divides en trocitos muy pequeños que llamas "paquetes". A cada paquete le añades la dirección de envío, y la información básica para reconstruir todo el fichero en el destino. Aunque es un aproximación burda, imaginemos que lo que haces es numerarla (y añadir algún código para saber que son parte del mismo fichero). Coges todos los paquetes y los envías a tu pasarela de Internet, quien a su vez los envía a la pasarela más próxima, y así sucesivamente, hasta que llegan a destino, la máquina que los recibe es capaz de reconocerlos (lee el código de identificación y el número de orden en el fichero) y reconstruye la copia del fichero original.

¿Cómo se encaminan los mensajes hasta que llegan a su destino? bien, lo que haces es: compruebas si es para ti, o si tienes que reenviarlo; y si lo reenvías, lo haces a la máquina más próxima. La máquina más próxima, por su parte, la conoces porque en tu tiempo libre te dedicas a comprobar cuáles son las máquinas más próximas y elaboras una lista. Así, cuando encaminas un mensaje, digamos que lo mandas sin preguntar: si por cualquier razón la máquina no lo recibe, lo mandas a otra máquina. ¿Cómo sabes que la otra máquina no lo ha recibido? pues con un acuse de recibo; si transcurrido un tiempo determinado no te ha mandado el acuse, asumes que no lo ha recibido.

Bien, esto se hace con todos los mensajes a la vez. Eventualmente, puede suceder que una máquina encamine unos mensajes por una pasarela y otros mensajes (recuerda: son partes del mismo fichero) por otra, por mucho que lo usual es que si el primer mensaje va por una lo habitual es que todos vayan por la misma. Lo importante es que puede suceder. Incluso puede suceder es que la pasarela haya enviado un mensaje pero se haya recibido tarde su acuse de recibo, por lo que ya se habrá mandado una copia por otra pasarela diferente, de forma que la destinataria recibirá dos copias del mismo mensaje. Fijaos: en cada pasarela se mantiene una copia de todos los mensajes que forman nuestro fichero, al menos el tiempo suficiente para garantizar que se han enviado todos a la siguiente pasarela.

Bien, TCP/IP no incorpora ninguna medida de seguridad: está diseñado para ser simple y eficiente, como se ha dicho antes, pero no para ser seguro en su acepción moderna. Sus impulsores pretendían comunicarse, no poner trabas a dicha comunicación.

Uno de los primeros problemas es que la máquina destino tiene la información necesaria para reconstruir el fichero, pero no para saber con seguridad quién lo ha emitido. Tampoco tiene información que garantice que nadie haya interceptado la comunicación, y tampoco ofrece mecanismos útiles para garantizar que nadie ha alterado el fichero original. Al igual que en el caso de Unix o de Linux comentado antes, estas limitaciones se solventan con herramientas externas al protocolo de comunicaciones. Por ejemplo, SSL garantiza que una vez que te estás comunicando con una máquina, toda la comunicación tiene lugar con ésa máquina y no otra. TLS, además, lo que hace es encriptar la clave que permite usar SSL, ya que si alguien obtuviese la clave que requiere SSL para crear la conexión, podría suplantarte en otro momento.

Cuando pienses en la seguridad informática, recuerda: las cosas se inventaron para facilitarnos el compartir nuestras cosas. Así que poner restricciones a qué queremos compartir y con quién es, en cierta forma, actuar contra los principios de nuestros sistemas de telecomunicaciones. No esperes que el sistema te proteja en los tiempos que corren.