Filtraciones de información como Wikileaks y Panama Papers, ataques al sistema electoral de los EE.UU., secuestros de información por ransomware, hackeos a las fuerzas de seguridad de la Argentina, robo de cuentas de email y redes sociales. La lista de noticias relacionadas con la seguridad informática crece a diario. Así como la informática atraviesa cada vez más aspectos de nuestra vida y quehaceres, la vulneración de sistemas informáticos tiene cada día mayor impacto. Y así como la informática es una disciplina científica joven, más aún lo es la seguridad informática.

Desde individuos hasta gobiernos, pasando por organizaciones de diverso tipo y tamaño, todos pueden ser eventualmente víctimas de ataques. Cómo protegerse es un problema al que el mundo presta cada día más atención. Desde fabricantes de dispositivos informáticos hasta los brazos armados de los Estados destinan cada día mayor presupuesto y esfuerzo a resolver esta problemática.

La situación en nuestro país es tan variada como en el resto del mundo, incluso cuando la Argentina destaca por el nivel y la cantidad de profesionales dedicados a la materia. Tomemos como ejemplo el penúltimo gran ataque con ransomware: Wannacry. Este tuvo un gran impacto mundial, aún cuando se basaba en un problema de seguridad que había sido solucionado más de un mes atrás. Pero la situación en el país fue bastante heterogénea, ya que ciertas organizaciones tuvieron que realizar un «apagón informático», en tanto que otras no tuvieron inconveniente alguno.

El panorama en la Argentina es mejor en el ámbito privado, ya que las empresas de mayor envergadura acostumbran contratar auditorías externas para controlar el estado de la seguridad de sus sistemas y procesos. En el Estado, lamentablemente, esta no es una práctica generalizada; y aunque en algunas áreas puntuales haya equipos de profesionales capacitados, en otras hay un completo abandono en la materia. En los últimos meses hemos sido testigos de esto a la luz de los hackeos del Ministerio de Seguridad, la Policía de Seguridad Aeroportuaria y la Policía Federal Argentina.

La seguridad no es un producto, sino un proceso. No basta la adquisición de equipamiento (hardware) y de programas (software), ni siquiera la correcta implantación de éstos en el ámbito organizacional. Para mantener un nivel de seguridad adecuado es necesaria además una permanente revisión y actualización de las políticas y los procedimientos. Las técnicas de ataque a sistemas informáticos evolucionan a la par de éstos, por lo que la actualización de las defensas debe seguir el mismo ritmo.

A diario crece la utilización de dispositivos informáticos para controlar dispositivos físicos. Los automóviles modernos, los electrodomésticos, las redes de distribución de energía e incluso dispositivos médicos como marcapasos o bombas de insulina se basan cada vez más en sistemas informáticos. Esto hace que la posibilidad de ataques con «bits» tenga cada vez mayor repercusión en el mundo real y tangible. Por ello la ciberdefensa se ha convertido hoy en el cuarto brazo armado de los Estados más importantes del mundo.

Si bien se trata de un artículo del año 2003, cuando aún no existían Gmail, Youtube, Facebook ni Twitter. Notará, sin embargo, que las cosas no han cambiado mucho y que muchos han aprendido muy poco.

Mundo de Extremos

Qué es Internet y Cómo Dejar de Confundirla con Otra Cosa

por Doc Searls y David Weinberger

Hay errores y errores.

De algunos errores aprendemos. Por ejemplo: pensar que vender juguetes para mascotas en la Web es una excelente forma de volverse rico. No volveremos a hacerlo de nuevo.

Otros errores insistimos en cometerlos una y otra vez. Por ejemplo, pensar que:

• …la Web, como la televisión, es una forma de mantener los ojos quietos mientras los anunciantes los rocían con mensajes.
• …Internet es algo que las empresas de telecomunicaciones y de cable deben filtrar, controlar y, de algún modo, «mejorar».
• …es algo malo para los usuarios comunicarse a través de distintos tipos de sistemas de mensajería instantánea en Internet.
• …Internet sufre de una falta de regulación para proteger a las industrias que se sienten amenazadas por ella.

Cuando se trata de Internet, muchos de nosotros sufrimos del Síndrome del Error Repetitivo. Esto es especialmente cierto para los editores de diarios y revistas, radio y televisión, televisión por cable, la industria discográfica, la industria cinematográfica y la industria telefónica, por nombrar sólo a seis.

Gracias a la enorme influencia de estas industrias en Washington, el Síndrome del Error Repetitivo también afecta a los legisladores, reguladores e inclusive a las cortes. El año pasado (2002) la radio de Internet, una prometedora nueva industria que amenazaba dar a los radioescuchas opciones que por lejos excedían cualquiera de las cada vez más uniformes (y tecnológicamente paleolíticas) emisoras de AM y FM, fue asesinada en la cuna. Las armas, las municiones y los gritos de aliento fueron provistos por la industria discográfica y la Ley de Copyright del Milenio Digital (Digital Millennium Copyright Act), que incorpora todos los miedos que sentían los dinosaurios de Hollywood cuando hicieron lobby a favor de la Ley a través del Congreso en 1998.

«Internet interpreta la censura como un daño y la rodea para esquivarla», según una famosa frase de John Gilmore. Y es verdad. A la larga, la radio de Internet tendrá éxito. Los sistemas de mensajería instantánea interoperarán. Las compañías bobas se volverán listas o morirán. Las leyes estúpidas serán matadas o reemplazadas. Pero entonces, como dijo John Mainard Keynes, «a la larga, estaremos todos muertos».

Todo lo que necesitamos hacer es poner atención a lo que realmente es Internet. No es difícil. La Red no es ingeniería espacial. No es ni siquiera ciencia de sexto grado. Podemos poner fin a la tragedia del Síndrome del Error Repetitivo durante nuestras vidas y economizar unos cuantos miles de millones de dólares en decisiones tontas, si solamente recordamos un hecho simple: la Red es un mundo de extremos. Usted está en un extremo; todo y todos los demás están en los otros extremos.

Claro, esta es una declaración simplista que afirma que todo el mundo tiene valor en Internet. Pero es también el hecho más básico y sólido sobre la arquitectura técnica de la Red. Y el valor de Internet se basa en su arquitectura técnica.

Afortunadamente, la verdadera naturaleza de Internet no es difícil de entender. De hecho, sólo un puñado de afirmaciones se encuentran entre el Síndrome del Error Repetitivo y la Iluminación.

1. Internet no es complicada

La idea detrás de Internet, en primer lugar, fue aprovechar el asombroso poder de la simplicidad; tan simple como la gravedad en el mundo real. Excepto que en vez de mantener pequeñas piedras sujetas a una gran piedra redonda, Internet fue diseñada para mantener pequeñas redes juntas, transformándolas en una gran red.

La forma de lograr esto fue hacer fácil, fácil, fácil para las redes el enviar y recibir datos hacia y desde otra red. Por lo tanto, Internet fue diseñada para ser la forma más simple concebible para enviar bits desde cualquier A hacia cualquier B.

2. Internet no es una cosa. Es un acuerdo

Cuando miramos los postes, vemos a las redes como cables. Y vemos a esos cables como partes de sistemas: el sistema telefónico, el sistema de alimentación eléctrica, el sistema de televisión por cable.

Cuando escuchamos la radio o miramos televisión, se nos dice en cada corte que las redes son fuentes de programación que es transmitida a través del aire o de los cables.

Pero Internet es diferente. No es un cableado. No es un sistema. Y no es una fuente de programación.

Internet es una forma para que todas las cosas que se dicen «redes» coexistan y trabajen de manera conjunta. Es trabajo entre-redes (inter-network, en inglés). Literalmente.

Lo que hace que sea una inter-red es el hecho de que Internet es simplemente un protocolo: el Internet Protocol, para ser más exactos. Un protocolo es un acuerdo sobre como las cosas trabajan juntas.

Este protocolo no especifica qué puede hacer la gente con la red, qué puede construir en sus bordes, qué se puede decir, quién puede hablar. El protocolo simplemente dice: si usted quiere intercambiar bits con otros, así es como debe hacerlo. Si usted quiere poner una computadora o un teléfono celular o un refrigerador en la red, tiene que aceptar el acuerdo que representa Internet.

3. Internet es estúpida

El sistema telefónico, que no es Internet (al menos no aún), es terriblemente inteligente. Sabe quién está llamando a quién, donde están ubicados, si es una llamada de voz o de datos, qué tan lejos llega la llamada, cuánto cuesta, etc. Y provee servicios que sólo tienen que ver con una red telefónica: llamada en espera, identificador de llamada y otras muchas cosas que a las compañías telefónicas les encanta vender.

Internet, por otra parte, es estúpida. A propósito. Sus diseñadores se aseguraron de que la red más grande e inclusiva de todas sea tan tonta como una caja de piedras. (Ver «End-to-End Arguments in System Design«, de J.H. Saltzer, D.P. Reed, D.D. Clark y «Rise of the Stupid Network«, de David Isenberg).

Internet no sabe muchas cosas que una red inteligente, como la telefónica, conoce: identidades, permisos, prioridades, etc. Internet sólo sabe una cosa: este montón de bits necesita ir desde un extremo de la Red hasta otro.

Hay motivos técnicos por los cuales la estupidez es un buen diseño. La estupidez es robusta. Si un ruteador falla, los paquetes se rutean esquivándolo, lo que significa que la Red sigue de pié. Gracias a la estupidez, Internet acoge nuevos dispositivos y gente, de manera que crece rápidamente y en todas las direcciones. También es fácil para los arquitectos incorporar capacidades de acceso a la red en todo tipo de dispositivos inteligentes —filmadoras, teléfonos, regadores de jardín— que viven en los extremos de la Red.

La razón más importante por la que la estupidez es buena tiene poco que ver con la tecnología y mucho con el valor…

4. Agregar valor a Internet disminuye su valor

Suena extraño, pero es cierto. Si usted optimiza una red para un tipo de aplicación, la empeora para otros. Por ejemplo, si usted deja que la red dé prioridad a los datos de voz o vídeo, asumiendo que necesitan llegar más rápidamente, le está diciendo a otras aplicaciones que deberán esperar. Y ni bien haga eso, habrá transformado Internet de algo simple, para todos, en algo complicado, sólo para un propósito. Ya no es más Internet.

5. Todo el valor de Internet crece en sus bordes

Si Internet fuese una red inteligente, sus diseñadores habrían anticipado la importancia de un buen buscador y habrían incorporado capacidades de búsqueda dentro de ella. Pero dado que sus diseñadores fueron listos, la hicieron muy estúpida para eso. Por lo tanto, las búsquedas son un servicio que puede ser construido en uno de los millones de extremos de Internet. Dado que la gente puede ofrecer cualquier servicio que desee desde su extremo, los buscadores
compiten, lo que se traduce en alternativas para los usuarios y asombrosa innovación.

Los buscadores son sólo un ejemplo. Dado que Internet mueve bits desde un extremo hasta otro, los innovadores pueden construir cualquier cosa que imaginen, contando con Internet para mover los datos por ellos. Usted no tiene que preocuparse por obtener permisos de los dueños de Internet o los administradores de sistemas o del Vice Presidente del Servicio de Prioritización. ¿Usted tiene una idea? Realícela. Y cada vez que lo haga, el valor de Internet crecerá.

Internet fue creada como un mercado libre para la innovación. Ésta es la clave del valor de Internet. Del mismo modo…

6. El dinero va hacia los suburbios

Si todo el valor de Internet está en sus bordes, la conectividad de Internet se vuelve un «commodity». Debe permitirse que eso suceda.

Existen buenos negocios en la provisión de «commodities», pero cada intento de agregar valor a Internet por sí misma debe ser resistido. Para ser más específicos: aquellos quienes proveen conectividad a Internet, inevitablemente desearán proveer contenidos y servicios adicionales, ya que la conectividad en sí misma sería demasiado barata. Manteniendo las dos funciones separadas, habilitaremos al mercado a fijar los precios que maximizarán el acceso y maximizarán también la innovación de contenidos y/o servicios. (Ver «The Paradox of the Best Network«, de Isenberg y Weinberger).

7. ¿El fin del mundo? No, un mundo de extremos. (The end of the world? Nah, the world of ends)

Cuando Craig Burton describe la arquitectura estúpida de Internet como una esfera hueca enteramente formada por extremos, pinta una imagen que captura lo más destacable de su arquitectura: quite el valor del centro y habilitará un enloquecido florecimiento del valor entre los extremos conectados. Porque, por supuesto, cuando cada extremo está conectado, uno con uno y uno con todos, los extremos dejan de ser puntos finales.

¿Y qué hacemos nosotros, los extremos? Cualquier cosa que pueda ser hecha por cualquiera que desee mover bits.

¿Nota el orgullo en nuestra voz cuando decimos «cualquier cosa» y «cualquiera»? Proviene directamente desde la simple y estúpida arquitectura técnica de Internet.

Porque Internet es un acuerdo, no le pertenece a ninguna persona o grupo. Ni a las influyentes compañías que proveen su «columna vertebral» («backbone», en inglés). Ni a los ISPs que proveen nuestras conexiones. Ni a las empresas de alojamiento que alquilan nuestros servidores. Ni a las asociaciones de industrias que
creen que ven amenazada su existencia por lo que el resto de nosotros hace en la Red. Ni a ningún gobierno, no importa que tan sinceramente crea que está tratando de mantener a sus ciudadanos seguros y satisfechos.

Conectarse a Internet es aceptar el crecimiento del valor en sus bordes. Y entonces ocurre algo realmente interesante. Estamos todos conectados en igualdad de condiciones. No importa la distancia. Los obstáculos desaparecen y, por primera vez, la necesidad humana de conectarse puede ser satisfecha sin barreras artificiales.

Internet nos da, por primera vez, los medios para transformarnos en un mundo de extremos.

8. Las tres virtudes de Internet

Estos son los hechos acerca de Internet. Ya ve, le dijimos que eran simples.

¿Pero, qué significan para nuestro comportamiento y, más importante aún, para el comportamiento de las mega-corporaciones y gobiernos que hasta ahora han actuado como si Internet les perteneciera?

Aquí están tres reglas básicas del comportamiento que están directamente ligadas a la naturaleza básica de Internet:

• Nadie la posee
• Todos pueden usarla
• Cualquiera puede mejorarla

Examinemos más de cerca cada una…

8.a. Nadie la posee

Internet no puede ser poseída, ni siquiera por las empresas a través de cuyas «tuberías» fluye, porque es un acuerdo, no una cosa. Internet no sólo está en el dominio público, sino que es un dominio público.

Y esto es algo bueno:

• Internet es un recurso confiable. Podemos construir negocios sin tener que preocuparnos de que «Internet Inc.» vaya a forzarnos a actualizarnos, duplique su precio una vez que hayamos comprado o sea adquirida por uno de nuestros competidores.
• No tenemos que preocuparnos por que algunas partes trabajen con un proveedor y otras con otro distinto, como ocurre con el negocio de los teléfonos celulares en los EE.UU. actualmente.
• No tenemos que preocuparnos por que sus funciones básicas vayan a funcionar solamente con «plataformas» de Microsoft, Apple o AOL, porque están por encima de ellos, fuera de su control propietario.
• La manutención de Internet está distribuida entre todos los usuarios, no concentrada en las manos de un proveedor que pueda quebrar. Todos nosotros somos un recurso más robusto de lo que puede ser cualquier grupo centralizado.

8.b. Todos pueden usarla

Internet fue construida para incluir a cada habitante del planeta.

Es cierto, sólo una décima parte del mundo (unas 600 millones de personas) se conecta actualmente a Internet. Por eso la palabra «pueden» en la frase «Todos pueden usarla» está sujeta a las variaciones miserables de la suerte. Pero, si usted tiene la suerte de ser lo suficientemente rico para poseer una conexión y un dispositivo de conexión, la Red no le impone ningún obstáculo a su participación. No necesita que un administrador de sistemas se digne dejarlo participar. Internet intencionalmente deja los permisos del lado de afuera del sistema.

Es por eso que muchos de nosotros consideramos a Internet como un recurso natural. Nos aprovechamos de ella como si fuese una parte de la naturaleza humana que estaba esperando aparecer, de la misma manera que hablar y escribir ahora se sienten como parte de lo que significa ser humano.

8.c. Cualquiera puede mejorarla

Cualquiera puede hacer de Internet un mejor lugar para vivir, trabajar y criar niños. Empeorarla requiere de una gran estupidez, junto con una voluntad de acero.

Hay dos formas de mejorarla. Primero, puede construir un servicio en el borde de Internet, que esté disponible a quien lo desee. Hacerlo gratuito, hacer que la gente pague por él, poner un recipiente para que depositen monedas, lo que sea.

Segundo, puede hacer algo más importante: habilitar un conjunto de nuevos servicios «del extremo hacia la Red», mediante un nuevo acuerdo. Así es como fue creado el correo electrónico. Y los grupos de noticias. E inclusive la Web. Los creadores de estos servicios no hicieron simplemente aplicaciones finales y, seguramente, no manosearon el protocolo de Internet. En cambio, crearon nuevos protocolos que usan a Internet tal como es, de la misma manera que el acuerdo sobre cómo codificar imágenes en papel que es usado por las máquinas de fax para utilizar las líneas telefónicas sin requerir ningún cambio en el sistema telefónico propiamente dicho.

Recuerde sin embargo, que si usted crea un nuevo acuerdo, para generar valor tan rápidamente como lo hizo Internet, tiene que ser abierto, no propietario y para todos. Este es exactamente el por qué la mensajería instantánea a fallado en alcanzar su potencial: los sistemas líderes de mensajería instantánea (el AIM de AOL, ICQ y el MSN Messenger de Microsoft) son territorios privados que pueden correr sobre la Red, pero que no son parte de la Red. Cuando AOL y Microsoft decidan que deben correr sus sistemas de mensajería instantánea usando un protocolo estúpido que nadie posea y que todos puedan usar, habrán mejorado Internet enormemente. Hasta entonces, sólo están siendo estúpidos, y no en el buen sentido de la palabra.

9. Si Internet es tan simple, ¿por qué tantos se confunden sobre ella?

¿Será porque las tres virtudes de Internet son la antítesis de la visión de los gobiernos y las empresas acerca del mundo?

• Nadie la posee: Las empresas están definidas por lo que poseen, tal como los gobiernos están definidos por lo que controlan.
• Todos pueden usarla: En los negocios, vender bienes significa transferir derechos exclusivos de uso del vendedor al comprador; en los gobiernos, hacer leyes significa imponer restricciones a la gente.
• Cualquiera puede mejorarla: Empresas y gobiernos valorizan roles exclusivos. Es sólo el trabajo de cierta gente hacer ciertas cosas, hacer los cambios apropiados.

Empresas y negocios, por su naturaleza, están predispuestos a malinterpretar la naturaleza de Internet.

Existe otra razón por la cual Internet no ha hecho un gran trabajo explicándose a sí misma: «El Gran Dinero» preferiría mantenernos pensando que la Red es solamente televisión lenta.

Internet ha sido como Walt Whitman escribió en «Canción de mí mismo» («Song of Myself»): No me preocupo por ser comprendido. Veo que las leyes elementales nunca piden disculpas.

Por otra parte, las leyes elementales de Internet nunca imaginaron que habría gente que basaría sus carreras en no entenderlas.

10. Algunos errores que ya podemos dejar de cometer

Las empresas cuyo valor proviene de distribuir contenido de formas que el mercado ya no desea —¿puedes oírnos, Industria Discográfica?— pueden dejar de pensar en los bits como si fueran átomos livianos. Nunca nos impedirán copiar los bits que queramos. En cambio, ¿por qué no nos dan algunas razones para preferir comprarles música a ustedes? Diablos, hasta les podríamos ayudar a vender sus cosas si nos lo pidieran.

Los funcionarios gubernamentales que han confundido el valor de Internet con el valor de sus contenidos, podrían darse cuenta de que al manosear el corazón de Internet están realmente disminuyendo su valor. De hecho, también podrían entender que tener un sistema que transporte todos los bits con igualdad, sin censura de gobiernos o empresas, es la fuerza más poderosa para la democracia y los mercados abiertos de la historia.

Los influyentes proveedores de servicios de redes —pista: comienza con «tele» y termina con «com»— podrían aceptar que la red estúpida va a devorar a sus redes inteligentes. Podrían morder esa bala ahora en vez de gastar miles de millones de dólares en los costos de demorar y pelear contra lo inevitable.

Las agencias federales responsables por la administración del espectro, podrían darse cuenta de que el valor de un espectro abierto es igual al verdadero valor de Internet.

Los que quieren censurar ideas, podrían darse cuenta de que Internet no puede distinguir entre un bit bueno y un bit malo, en ninguna circunstancia. Cualquier censura efectiva debería ocurrir en los extremos de la Red, y eso no funcionaría muy bien.

Tal vez las compañías que piensan que pueden forzarnos a escuchar sus mensajes —sus banners, sus gráficos entrometidos que se superponen con las páginas que estamos tratando de leer— se darán cuenta de que nuestra habilidad de movernos de sitio en sitio es intrínseca a la arquitectura de la Web. Podrían simplemente poner un banner que diga «¡Hola! No entendemos lo que es Internet. Ah, por cierto, te odiamos.»

Ya es suficiente. Dejemos de machacar nuestras cabezas contra los hechos de la vida de Internet.

No tenemos nada que perder, excepto nuestra estupidez.

Realmente, es un ataque muy simple y que prácticamente no consume ancho de banda en el atacante, por lo que en este momento cualquiera puede (con un mínimo esfuerzo) dejar totalmente inaccesible cualquier sitio web que esté alojado en un servidor vulnerable.

Para probar la vulnerabilidad

slowloris.pl

Requerimientos:

• perl
• IO::Socket::INET (perl -MCPAN -e 'install IO::Socket::INET')
• IO::Socket::SSL (perl -MCPAN -e 'install IO::Socket::SSL')
• GetOpt::Long (perl -MCPAN -e 'install GetOpt::Long')

Cuestiones éticas aparte, si hubiera tomado control de riocuarto.gov.ar no se me hubiera ocurrido hacer algo tan tonto como simplemente eliminar los datos de delegación. Por eso me quedé pensando (y dejo este artículo abierto a ideas y sugerencias): «¿Qué haría si tomara el control del dominio de la Municipalidad?».

Disclaimer

Como está visto que hace falta, aclaro: No estoy proponiendo a nadie que ataque nada (ni el DNS de la Municipalidad, ni ninguna otra cosa). Este es un artículo humorístico.

Algunas ideas….

Cambiar el MX

Apuntar el registro MX a un servidor controlado por mí, derivando hacia él todo el tráfico de correo electrónico (SMTP). Luego, posiblemente, volver a inyectarlo hacia el servidor real. Si en 5 días no se dieron cuenta de que el dominio no estaba funcionando, imagino que en 1 año tampoco notarían esto.

¡Ah, por cierto! También estaría bueno tomar los mensajes más interesantes y publicarlos en un blog, justo en época de elecciones. :)

Agregar una entrada TXT

Agregar una entrada TXT en el DNS, usando SPF, para indicar que el único servidor SMTP válido del dominio riocuarto.gov.ar es W.X.Y.Z (alguna IP arbitraria de por ahí…). Apuesto que se hubieran pasado meses preguntándose por qué cuernos todo el correo enviado desde cuentas de riocuarto.gov.ar es tachado como spam por todos los servidores de Internet.

Cambiar el host www

Apuntarlo a www.cordobesitas.com.ar o algún sitio por el estilo (desconcertado va a quedar aquel que busque una foto del Intendente municipal…).

Otra muy buena sería redirigirlo a un servidor proxy que haga algunas modificaciones sobre el contenido original, como por ejemplo reemplazar todas las ocurrencias de «Jure» por «Jure en falso», «Juez» o algo por el estilo. También se podría hacer algo más gracioso (e inofensivo) como dar vuelta todas las imágenes.

Definir hosts nuevos

Cosas como, por ejemplo, quienlevantalabasuraen.riocuarto.gov.ar, deremate.riocuarto.gov.ar o lasgaritasmascarasdelmundo.riocuarto.gov.ar. Algo más divertido podría ser darle algo de contenido a estos sitios…

¿Ideas?

Escucho ocurrencias… :)

¿Esto fue hecho adrede por los administradores informáticos de la Municipalidad? ¿Fue un error involuntario? ¿Se trata acaso de un nuevo ataque conducido contra los sistemas de la Municipalidad de Río Cuarto? Es difícil determinar la causa, lo que más llama la atención es el absoluto silencio de los medios locales con respecto al tema.

Delegación de dominio dada de baja

En el sitio del NIC Argentina (el organismo oficial que administra los dominios .ar), puede verse (en la opción «Trámites vía web» -> «Trámites por nombre de dominio») que la delegación del dominio riocuarto.gov.ar ha sido dada de baja:

La situación es clara: El día 21 de mayo de 2009 a las 13:11 horas, mediante el trámite administrativo DEL3743701 la delegación de DNS del dominio riocuarto.gov.ar fue dada de baja. Esto significa que fueron eliminados los datos de los servidores de nombres encargados de la resolución de dicho dominio. A partir de ese momento dejaron de funcionar, por ejemplo, tanto los sitios web de la Municipalidad y del Consejo deliberante como las direcciones de correo de los funcionarios y dependencias municipales.

Posibles causas

La misteriosa desaparición del dominio puede deberse a alguna de las siguientes causas:

• Error de NIC Argentina: Algún administrador desprevenido, o alguna falla en el sistema del NIC ocasionaron la baja de la delegación. Esto es muy poco probable, ya que existe un trámite identificado mediante el cual se realizó la baja (DEL3743701).
• Error de un administrador de la Municipalidad de Río Cuarto: Algún administrador desprevenido realizó el trámite de baja de la delegación. Esto requiere la realización de un trámite vía web más la confirmación a través del correo electrónico. Cuesta creer que alguien pudiera cometer un error tan grosero (pero bueno, todo es posible…).
• Ataque a la Municipalidad: Alguien deliberadamente realizó el trámite de baja de la delegación. Esto requeriría de, al menos, acceso a la cuenta de correo electrónico utilizada ante NIC Argentina para la realización de trámites administrativos del dominio riocuarto.gov.ar. Si este fuera el caso, significa que alguien tomó control de dicha cuenta (o del servidor de correo), lo que implica un incidente bastante más grave aún.

Silencio de radio

A la fecha de publicación de este artículo ya han transcurrido cinco días. Seguramente cualquier ciudadano que haya querido acceder a un sitio de la Municipalidad de Río Cuarto, o comunicarse por email con alguna autoridad, habrá notado la existencia del problema (ni hablar de quienes trabajan en el ámbito municipal). Sin embargo, no ha habido (hasta donde sé) ninguna comunicación oficial, ni medio de prensa que se haya hecho eco del incidente.

Cinco días sin sitios web, sin email (y vaya a saber con qué otros inconvenientes) no constituyen un incidente menor; máxime teniendo en cuenta el abultado presupuesto que nuestra Municipalidad destina al área informática (prometiéndonos «ciudades digitales» y «conectadas» cuando en este momento ni siquiera pueden recibir un mensaje de correo electrónico).

Una vez más, el resultado es lamentable.

Actualización 1: (para los «técnicos»)

Para comprobar que riocuarto.gov.ar en la práctica no existe como dominio en Internet, podemos hacer la siguiente prueba (en GNU/Linux):

dig @ns1.retina.ar ns riocuarto.gov.ar

Con esto, le estamos preguntando al servidor DNS ns1.retina.ar (una de las autoridades de la zona gov.ar) cuál es el servidor de nombres del dominio riocuarto.gov.ar. La respuesta es nula. (Puede reemplazarse ns1.retina.ar por cualquiera de los otros NS de la zona gov.ar, que pueden a su vez obtenerse con el comando «dig ns gov.ar«.)

Actualización 2: (26 de mayo de 2009, 11 hs)

Según me comenta un amigo, los administradores acaban de enterarse del problema (porque alguien les avisó). Parece increible que hayan pasado 5 días sin siquiera notar el «inconveniente». Veremos cuánto más tardan ahora en solucionarlo…

Actualización 3: (fui yo)

Ahora, según dice gente de la Municipalidad, parece ser que el culpable del incidente fui yo. Según afirman, media hora después de dado de baja el dominio yo ya lo sabía (¿cómo lo sabrán, si ellos se enteraron recién hoy?). ¿Cómo lo hice? Supuestamente accedí a una de las cuentas de correo habilitadas para las gestiones ante el NIC.

No se si se habrá notado, pero en todo el artículo traté de utilizar terminología bastante neutra, sin calificativos que pudieran resultar ofensivos para los responsables del problema. Como todavía me queda media vuelta de rosca, antes de que se me zafe la tuerca del todo, voy a esperar los acontecimientos de las próximas horas (a ver si siguen echándome la culpa de su incompetencia), antes de despacharme con el arsenal de adjetivos que tengo en la punta de los dedos.

Por ahora, agradecido, señores. Si se enteraron de este problema fue por mi artículo (como ya antes se enteraron de varios problemas de seguridad en reuniones personales y sin que les haya cobrado un centavo). Denle nomás, échenme la culpa, trátenme de «bobo», vienen bárbaro…

Actualización 4: (en vía de solución)

Hace unos momentos uno de los administradores de la Municipalidad (a quien conozco, y que como suponía no fue el babieca al que se le ocurrió matar al cartero) me comunicó que ya fue iniciado el trámite en el NIC Argentina para restablecer el funcionamiento de riocuarto.gov.ar.

Por mi parte (como ciudadano riocuartense), espero que se solucione a la brevedad, se aclare qué y cómo ocurrió, y no vuelva a suceder.

Actualización 5: (la prensa se hace eco)

Finalmente, a las 20 horas del día 26 de mayo, el diario Puntal publica una nota sobre el incidente. Claro que, como lamentablemente era de esperarse, se trata de minimizar el problema. Según declara un responsable técnico al diario:

“Esto provoca que al cargar la dirección www.riocuarto.gov.ar en el navegador no se encuentre el servidor, hasta tanto se realice el trámite que vuelve a relacionar el nombre con nuestro IP, que ya fue iniciado”.

Claro, provoca eso… y varias cosas más. Entre ellas, que otros dominios como emos.gov.ar y concejoriocuarto.gov.ar tampoco funcionaran (ni para acceder a los sitios web, ni para el envío de correo electrónico, «pequeño detalle» que omiten). Por supuesto, tampoco dicen que el problema se produjo un jueves y fue detectado recién el martes siguiente.

Y luego, para colocar la guinda sobre la torta, dicen que:

«se encuentran investigando … para intentar dilucidar si alguna persona ingresó con la contraseña intencionalmente o si se trata de algún error en los sistemas de NIC ARGENTINA»

Claro, si, seguro. NIC Argentina tiene registrados más de un millón de dominios. Y tiene un error que permite a alguien modificar un dominio a su antojo. Y solamente le ocurre a la Municipalidad de Río Cuarto. Perfectamente probable, cómo no. (Me cerraba más la hipótesis de que había sido yo que accedí a la cuenta de correo.)

Actualización 6: (¿final?)

En este momento (27 de mayo de 2009) el dominio riocuarto.gov.ar está funcionando nuevamente.

El diario La Voz del Interior también publicó la noticia (de forma mucho más detallada y cercana a la realidad que Puntal). Nobleza obliga, tengo que agradecer a Nicolás Llamosas por haberme librado de los rumores difamatorios que circularon ayer por la Municipalidad (y, Nicolás, no era necesario el reconocimiento público por algún aporte previo, pero se agradece doblemente).

Ojalá NIC Argentina coopere brindando la información necesaria para intentar descubrir el origen de este incidente y ojalá se tomen las medidas para que este (u otro) ataque no pueda tener éxito en el futuro.

Un «hacker» riocuartense

El primer entrevistado es un autoproclamado «hacker» que dice dedicarse a la seguridad informática (sería todo un hallazgo encontrar a un experto en la materia en la ciudad de Río Cuarto), quien hace afirmaciones como la siguiente:

«Se­ría me­jor si no hu­bie­ra hac­kers. Por­que los hac­kers son la con­se­cuen­cia de la so­cie­dad.»

Tal sinsentido se contradice con lo expresado por él mismo en otra parte de la entrevista, donde explica que:

«Ser hac­ker sig­ni­fi­ca for­zar los sis­te­mas a lo má­xi­mo, eso im­pli­ca co­no­ci­mien­tos y ver si hay fa­llas de se­gu­ri­dad y có­mo es­tá he­cho, sim­ple­men­te eso. No ha­cer da­ño, ni nin­gu­na ac­ti­vi­dad ile­gal.»

«Una de las mo­ti­va­cio­nes de un hac­ker es el de­sa­fío mis­mo de ha­cer es­to y la bús­que­da de co­no­ci­mien­tos. Hay mu­chos hac­kers que vi­ven de eso, de la se­gu­ri­dad, con los co­no­ci­mien­tos que se van ad­qui­rien­do. Otro mo­ti­vo es el pen­sa­mien­to de que las co­sas de­ben es­tar bien he­chas. Y, cuan­do es­tán mal, se tra­ta de de­rri­bar­las pa­ra que se vuel­van a ha­cer bien.»

Queda de manifiesto que el tal «Zar» (así es como se hace llamar) ni siquiera tiene bien en claro qué es ser un hacker. Si bien es cierta su definición, no se entiende por qué para él sería mejor que no hubiera personas con esa disposición, ni por qué son una consecuencia supuestamente indeseable de la sociedad (y menos se entiende cuando compara el «hackeo» con vender marihuana).

Para finalizar, con respecto al ataque al sitio de LV16 este personaje se despacha diciendo que:

«Yo ubi­qué a es­te hac­ker, a par­tir de in­di­cios. Cru­zan­do da­tos se con­si­gue. Es un chi­co de 17 años, que vi­ve en Mar del Pla­ta, que per­te­ne­ce a un gru­po que se co­no­cen por Fa­ce­book y Mes­sen­ger, que con­si­guie­ron una re­ce­ta pa­ra hac­kear una pá­gi­na y que­rían ver si ser­vía. Fue ca­sual. Uno de ellos es de Ve­na­do Tuer­to. Pe­ro, al chi­co no le va a pa­sar na­da.»

No se que datos habrá cruzado el tal «Zar», pero el autor de dicho ataque dejó un comentario en mi artículo sobre el tema invitando a cualquiera a agregarlo a MSN. En breve publicaré una entrevista que le realicé, y donde queda de manifiesto lo errado de las especulaciones de este supuesto experto en seguridad.

La guinda sobre la torta (y el helado en la frente)

Más allá de lo anecdótico de las contradictorias y hasta simpáticas afirmaciones del supuesto hacker «Zar», realmente preocupa ver que el Dr. Oscar Taurian (Director del Centro de Cómputos de la Universidad Nacional de Río Cuarto) haga afirmaciones como esta:

«Por ejem­plo, Cien­cias Eco­nó­mi­cas tie­ne el ser­vi­dor de­sac­tua­li­za­do y se lo pue­de usar pa­ra ata­car a las otras má­qui­nas.»

El Dr. Taurian (que no es doctor en informática, sino en alguna otra cosa) parece desconocer una norma básica de la seguridad informática. Utilizando un medio público acaba de dar una excelente pista a cualquiera que desee atacar la red de la UNRC, apuntando con el dedo al servidor de la Facultad de Ciencias Económicas. Imagine el lector a un comisario declarando en un periódico que el Banco X tiene un pésimo sistema de seguridad. Totalmente ridículo.

Fuentes confiables…

Así cubre uno de los principales medios periodísticos de Río Cuarto el problema de la seguridad informática. Lo hace consultando a supuestos expertos que no son tales y publicando sus afirmaciones como hechos. ¿Se conducirán de la misma manera en otras áreas como la economía y la salud? Da que pensar.

Aunque en algún momento estará disponible en el sitio del evento (junto con el video de la charla), no resití la tentación de publicar la presentación que utilicé.

Experiencias en la implementación de un ISP con software libre

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

El DNS se utiliza principalmente para la resolución de nombres, esto es, decidir qué dirección IP pertenece a determinado nombre completo de host.

También puede descargar este tutorial en otros formatos (HTML sin decoraciones y PDF).

Usos del DNS

El DNS se utiliza para distintos propósitos. Los más comunes son:

• Resolución de nombres: Dado el nombre completo de un host (por ejemplo blog.smaldone.com.ar), obtener su dirección IP (en este caso, 208.97.175.41).
• Resolución inversa de direcciones: Es el mecanismo inverso al anterior. Consiste en, dada una dirección IP, obtener el nombre asociado a la misma.
• Resolución de servidores de correo: Dado un nombre de dominio (por ejemplo gmail.com) obtener el servidor a través del cual debe realizarse la entrega del correo electrónico (en este caso, gmail-smtp-in.l.google.com).

Por tratarse de un sistema muy flexible, es utilizado también para muchas otras funciones, tales como la obtención de claves públicas de cifrado asimétrico y la validación de envío de e-mails (a través de mecanismos como SPF).

Terminología básica

Antes de proseguir, es necesario introducir algunos términos básicos para evitar confusiones y ambigüedades. Otros términos más complejos serán tratados más adelante.

• Host Name: El nombre de un host es una sola «palabra» (formada por letras, números y guiones). Ejemplos de nombres de host son «www«, «blog» y «obelix«.
• Fully Qualified Domain Name (FQDN): Es el «nombre completo» de un host. Está formado por el hostname, seguido de un punto y su correspondiente nombre de dominio. Por ejemplo, «blog.smaldone.com.ar«
• Domain Name: El nombre de dominio es una sucesión de nombres concatenados por puntos. Algunos ejemplos son «smaldone.com.ar«, «com.ar» y «ar«.
• Top Level Domains (TLD): Los dominios de nivel superior son aquellos que no pertenecen a otro dominio. Ejemplos de este tipo son «com«, «org«, «ar» y «es«.

Arquitectura del DNS

El sistema DNS funciona principalmente en base al protocolo UDP. Los requerimientos se realizan a través del puerto 53.

El sistema está estructurado en forma de «árbol«. Cada nodo del árbol está compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algún subdominio de la zona sobre la que él tiene autoridad). Un subdominio puede verse como una especialización de un dominio de nivel anterior. Por ejemplo, «smaldone.com.ar» es un subdominio de «com.ar«, que a su vez lo es del TLD «ar«.

El siguiente diagrama ilustra esto a través de un ejemplo:

Los «root servers» (o «servidores raíz«) tienen autoridad sobre el dominio raíz («.»), devolviendo los servidores con autoridad para cada uno de los TLD. Son fijos, ya que rara vez cambian, siendo actualmente 13.

Tomemos como ejemplo el dominio «com.ar«. Este dominio pertenece al TLD «ar«.

Los servidores con autoridad sobre el dominio «ar» son:

ns-ar.ripe.net
merapi.switch.ch
uucp-gw-1.pa.dec.com
uucp-gw-2.pa.dec.com
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar

En tanto que los servidores con autoridad sobre «com.ar» son:

merapi.switch.ch
relay1.mecon.gov.ar
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar

Podemos ver que ns.uu.net, ns1.retina.ar, athea.ar y ctina.ar tienen autoridad tanto sobre «com.ar» como sobre «ar«.

El proceso de resolución de nombres

Cuando una aplicación (cliente) necesita resolver un FQHN envía un requerimiento al servidor de nombres configurado en el sistema (normalmente, el provisto por el ISP). A partir de entonces se desencadena el proceso de resolución del nombre:

1. El servidor de nombres inicial consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente).
2. Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.
3. El servidor inicial interroga al nuevo servidor.
4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.
5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo interroga.
6. El servidor resuelve el nombre correspondiente, si este existe.
7. El servidor inicial informa al cliente el nombre resuelto.

Ilustremos esto con un ejemplo concreto. Supongamos que el navegador necesita resolver el nombre «blog.smaldone.com.ar«.

1. El sistema tiene configurado el servidor de nombres 200.49.156.3 (perteneciente al proveedor argentino Fibertel). Por lo tanto envía a éste el requerimiento de resolver «blog.smaldone.com.ar«.
2. El servidor de 200.49.156.3 envía la consulta root server 198.41.0.4.
3. 198.41.0.4 le informa que el servidor con autoridad sobre «ar» es athea.ar, cuya dirección IP es 200.16.98.2. (En realidad, informa la lista de todos los servidores con tal autoridad, pero para simplificar el ejemplo tomaremos solamente uno.)
4. 200.49.156.3 envía nuevamente el requerimiento a athea.ar (el cual, recordemos, también tiene autoridad sobre «com.ar«).
5. athea.ar responde que la autoridad sobre smaldone.com.ar la tiene ns1.mydomain.com cuya dirección IP es 64.94.117.213.
6. 200.49.156.3 envía ahora la consulta a ns1.mydomain.com.
7. ns1.mydomain.com informa que la dirección IP de «blog.smaldone.com.ar» es 208.97.175.41.
8. Finalmente, 200.49.156.3 devuelve este resultado a la aplicación que originó la consulta.

Mecanismos de caché

Cada vez que un servidor de nombres envía una respuesta, lo hace adjuntando el tiempo de validez de la misma (TTL o «tiempo de vida«). Esto posibilita que el receptor, antes la necesidad de volver a resolver la misma consulta, pueda utilizar la información previamente obtenida en vez de realizar un nuevo requerimiento.

Esta es la razón por la cual los cambios realizados en el DNS no se propagan instantáneamente a través del sistema. Dependiendo de la naturaleza de los mismos (y de la configuración de cada servidor), la propagación puede tardar desde algunos minutos hasta varios días.

Correo electrónico y resolución de nombres

Normalmente los usuarios de correo electrónico redactan su mensajes usando un cliente de correo y enviándolo a través de un servidor SMTP provisto por su ISP o a través de un sistema de correo vía web (webmail). En cualquier caso, una vez que el mensaje es recibido por el servidor, debe ser entregado al destinatario. Aquí interviene el sistema DNS:

1. El servidor del emisor solicita al DNS (de acuerdo al mecanismo analizado anteriormente), la entrada MX del dominio del receptor del mensaje. MX significa «mail exchanger«, esto es, el nombre del servidor (o los servidores) encargado de recibir los mensajes destinados a determinado dominio.
2. El DNS devuelve el FQHN y la dirección IP del mail exchanger.
3. El servidor del emisor se conecta al puerto 25, mediante TCP, del servidor del destinatario y entrega el mensaje según el protocolo SMTP.
4. El proceso podrá continuar si el servidor receptor del mensaje no es el último de la cadena. Existen servidores que actúan como «puertas de enlace» o «gateways» de correo electrónico, y que se encargan de recibir los mensajes de determinados dominios para luego enviarlos a otros servidores.

Tipos de registro en un servidor de nombres

Un servidor de nombres puede almacenar distinta información. Para ello, en cada zona de autoridad dispondrá de entradas de distinto tipo. Entre los más importantes se encuentran:

• A (Address): Este registro se utiliza para traducir nombres de hosts del dominio en cuestión a direcciones IP.
• CNAME (Canonical Name): El nombre canónico es un alias para un host determinado. (No define una dirección IP, sino un nuevo nombre.)
• NS (Name Server): Especifica el servidor (o servidores) de nombres para un dominio.
• MX (Mail Exchange): Define el servidor encargado de recibir el correo electrónico para el dominio.
• PTR (Pointer): Especifica un «registro inverso«, a la inversa del registro A, permitiendo la traducción de direcciones IP a nombres.
• TXT (Text): Permite asociar información adicional a un dominio. Esto se utiliza para otros fines, como el almacenamiento de claves de cifrado, «DomainKeys» o «Sender Policy Framework«.

Bind, «el» servidor de nombres

Prácticamente el único software utilizado en los servidores de nombres de Internet es bind («Berkeley Internet Name Domain«), creado originalmente en la Universidad de California, y actualmente propiedad del Internet Systems Consortium.

Este programa, distribuido bajo una licencia libre, es utilizado en prácticamente todos los sistemas Unix del mundo. Esto ha sido considerado un problema de seguridad, al punto que se ha propuesto la migración de algunos root servers a otro sistema, ya que la aparición de algún problema de seguridad en bind podría implicar la caída de todo el DNS de Internet.

Uso del DNS en una red local

Ya en redes de tamaño medio (quizás más de 5 equipos) es conveniente la utilización de DNS. Esto nada tiene que ver con el DNS de Internet (aunque el servidor local puede estar vinculado a este sistema).

Básicamente, es conveniente montar un servidor local de DNS por los siguientes motivos:

• Agilizar el acceso a Internet: Al tener un servidor de nombres en nuestra propia red local (que acceda al DNS de nuestro proveedor o directamente a los root servers) se agiliza el mecanismo de resolución de nombres, manteniendo en caché los nombres recientemente usados en la red y disminuyendo el tráfico hacia/desde Internet.
• Simplificar la administración de la red local: Al contar con un DNS propio (ya sea uno o varios servidores de nombres) es posible definir zonas locales (no válidas ni accesibles desde Internet) para asignar nombres a cada uno de los hosts de la LAN. De esta forma es posible, por ejemplo, referirnos a la impresora de red como «hplaser.mired.local» en vez de «192.168.0.2» y a nuestro servidor de correo interno como «smtp.mired.local» en vez de «192.168.0.3«. (Pensemos, por ejemplo, que ocurriría con las configuraciones de las aplicaciones si un día decidimos cambiar el esquema de direcciones IP de nuestra red.)

Problemas del DNS

El principal problema que presenta el DNS es que, al estar basado en UDP (protocolo de transporte que no garantiza la recepción de la información enviada), tanto las consultas como las respuestas pueden «perderse» (por ejemplo, a causa de congestionamiento en algún enlace de la red). Es común apreciar cómo, en el caso de servidores y redes no muy bien configuradas, la resolución de nombres se resiente sensiblemente ante cualquier anomalía (saturación de tráfico o del servidor de nombres local).

Otro inconveniente, que ya hemos hecho notar, es la lentitud de la propagación de las modificaciones en el sistema, producto de la propia arquitectura del mismo.

Pero quizás el mayor problema no sea inherente al sistema mismo, sino a la pésima configuración de los servidores de muchos ISP. Fibertel, el proveedor que utilizo, es un notable ejemplo de esta falencia. Una buena solución a esta situación es ejecutar un servidor de nombres en alguna PC de la red local, de forma tal que se comunique directamente con los root servers (evitando de esta forma pasar a través de los servidores de nombres de nuestro proveedor).

Herramientas para aprender más

En sistemas Unix el comando dig (ver «man dig«) permite realizar requerimientos «a mano» para poder investigar un poco más sobre el funcionamiento del DNS y, cómo no, también para detectar y solucionar problemas en la red.

Los usuarios de sistemas Windows disponen del comando nslookup (aunque no tan potente como dig), para el mismo propósito.

Lectura adicional

• La página de Wikipedia sobre DNS contiene bastante información y buenos enlaces sobre este tema.
• El «DNS Cómo» explica la configuración de bind en GNU/Linux.
• El RFC 1591 explica detalladamente la estructura del DNS.
• Los RFC 1034 y 1035 (ambos en inglés), describen completamente el DNS.

A través de este sencillo experimento, podremos recorrer los conceptos fundamentales de las redes TCP/IP, para reafirmar la idea de que este protocolo es muy simple. El objetivo es lograr, sin demasiados conocimientos previos, una comprensión profunda de sus mecanismos.

También puede descargar este tutorial en otros formatos (HTML sin decoraciones y PDF).

Requisitos previos

No se requieren conocimientos de programación, aunque sí una base de conocimientos informáticos en general. Para continuar experimentando más allá de los expuesto aquí, se recomienda la utilización del programa Wireshark (antes conocido como Ethereal), disponible para GNU/Linux, Microsoft Windows, Mac OS/X y Solaris .

Quizás el requisito más importante sean las ganas de aprender, investigar, jugar y divertirse con redes TCP/IP.

Referencias

Cada vez que se introduzca un término relevante, el mismo contendrá un enlace a una página con mayor información, por lo general de la Wikipedia y, de ser posible, en español (aunque se recomienda ampliamente visitar su equivalente en inglés).

Un libro muy recomendable y claro (en inglés) es «TCP/IP Illustrated Volume 1» de W. Richard Stevens. Finalmente, la fuente de consulta definitiva, para conocer tanto los aspectos técnicos como la evolución historica de cada uno de los protocolos y normas, son los Request for Comments (RFC), algunos de los cuales han sido traducidos al español.

Nuestro experimento

Estableceremos una conexión TCP/IP entre un cliente y un servidor que intercambiarán información. Para ello, utilizaremos el servidor desarrollado en el tutorial sobre programación en redes (no es necesario que lo lea completamente, si no le interesa la programación, pero sería conveniente que revise los conceptos introductorios y el protocolo definido).

Ejecutamos entonces el servidor en el host 100.0.0.1, utilizando el puerto 2222 (cualquiera de las versiones desarrolladas en el tutorial anterior sirve, ya que el protocolo es idéntico) y usamos el comando telnet para actuar como cliente desde el host 200.0.0.1 (el texto en cursiva es introducido por nosotros y el texto en negrita es la respuesta del servidor):

javier@200.0.0.1:~$ telnet 100.0.0.1 2222
Trying 100.0.0.1...
Connected to 100.0.0.1.
Escape character is '^]'.
Bienvenido.
salir
Adios.
Connection closed by foreign host.
javier@200.0.0.1:~$

Esto es todo. Ahora procederemos a analizar cómo se ha llevado a cabo esta comunicación a distintos niveles de abstracción.

Nivel de aplicación

A «nivel de aplicación» (lo que «ven» los programas), la comunicación se ha desarrollado de la siguiente manera:

1. El cliente se conecta al servidor.
2. El servidor envía el mensaje «Bienvenido.«.
3. El cliente envía el comando «salir«.
4. El servidor responde con el mensaje «Adios.«.
5. El servidor cierra la conexión.
6. El cliente cierra la conexión.

Esto es prácticamente lo mismo que podemos observar de la salida del comando telnet utilizado, lo cual no es casual; intencionalmente a este nivel se ocultan todos los detalles de implementación, que aparecerán cuando analicemos los niveles inferiores.

Nivel de transporte

El protocolo utilizado a «nivel de transporte» es TCP. Este protocolo es el encargado de establecer la conexión y dividir la información en paquetes, garantizando que los mismos son entregados correctamente (sin pérdidas y en el orden apropiado).

Cabe resaltar aquí que el otro protocolo de transporte de TCP/IP, UDP no garantiza ni el arribo de todos los paquetes enviados, ni el orden en que estos llegan a destino. Por esto es mucho más simple, no incluyendo algunas de las características de TCP como números de secuencia y asentimientos.

A continuación analizaremos algunos aspectos del protocolo TCP.

Puertos y direcciones

El protocolo TCP se basa en direcciones IP para identificar los equipos (hosts) desde donde provienen y hacia donde se envían los paquetes.

Los puertos (ports) son valores numéricos (entre 0 y 65535) que se utilizan para identificar a los procesos que se están comunicando. En cada extremo, cada proceso interviniente en la comunicación utiliza un puerto único para enviar y recibir datos.

En conjunción, dos pares de puertos y direcciones IP identifican univocamente a dos procesos en una red TCP/IP.

Números de secuencia

TCP garantiza que la información es recibida en orden. Para ello, cada paquete enviado tiene un número de secuencia. Cada uno de los dos procesos involucrados mantiene su propia secuencia, que se inicia con un valor aleatorio y luego va incrementándose según la cantidad de bytes enviados.

Por ejemplo, si un paquete tiene número de secuencia x y contiene k bytes de datos, el número de secuencia del siguiente paquete emitido será x + k. (Sí, el número de secuencia va contando la cantidad de bytes enviados por cada host.)

Paquetes y acuses de recibo

TCP también asegura que toda la información emitida es recibida. Para ello, por cada paquete emitido, debe recibirse un asentimiento (en inglés «acknowledgement«, abreviado ACK). Si pasado determinado tiempo no se recibe el ACK correspondiente, la información será retransmitida.

El ACK hace referencia al número de secuencia (que ha su vez involucra la cantidad de bytes enviados). Por ejemplo, para comunicar que se ha recibido correctamente el paquete cuyo número de secuencia es x, que contiene k bytes, se enviará un ACK con el valor x + k (que coincide con el próximo número de secuencia a utilizar por parte del emisor del paquete en cuestión). Si el número de secuencia inicial es x, un valor de ACK t significa que el receptor ha recibido correctamente los primeros t–x bytes (en este sentido, el ACK es acumulativo).

El ACK no es un paquete especial, sino un campo dentro de un paquete TCP normal. Por esto, puede ocurrir que se envíe un paquete a solo efecto de asentir una determinada cantidad de bytes, o como parte de un paquete de otro tipo (por ejemplo, aprovechando el envío de nuevos datos, para comunicar la recepción de datos anteriores). De hecho, aunque ya se haya enviado un paquete exclusivamente de ACK con un valor t, si luego se envía un paquete de datos, puede repetirse en él el ACK con el mismo valor t, sin que esto confunda al emisor de los datos que se están asintiendo. (Por simplicidad, en nuestro ejemplo hemos eliminado esta información redundante).

Otros campos de un paquete TCP

El protocolo TCP incorpora mecanismos tales como control de integridad de los datos (checksum), prevención de congestiones, entre otros, que no serán mencionados aquí por la simplicidad de este tutorial.

Inicio y fin de la conexión

Para dar comienzo a la conexión, el cliente envía un paquete SYN al puerto e IP en donde «escucha» el servidor, con un número de secuencia inicial aleatorio. Este último, responde con otro paquete SYN, con un número de secuencia inicial aleatorio y un ACK con el número de secuencia del paquete SYN recibido, más uno. El cliente envía un paquete con el ACK del SYN recibido, y una vez hecho esto la conexión se encuentra establecida y puede darse comienzo a la transmisión de datos (iniciada por cualquiera de las partes, según el protocolo de aplicación que utilicen).

La razón por la cual se intercambian números de secuencia aleatorios es para evitar que se confunda el inicio de dos conexiones diferentes y algunos ataques que se basan en falsear el comienzo de una conexión (spoofing).

La siguiente figura ilustra el establecimiento de una conexión TCP, llamada «negociación de tres pasos» o «3-way handshake«:

Para finalizar la conexión, uno de los dos procesos envía un paquete FIN, a lo que el otro responderá con un ACK. A su vez, el otro proceso puede enviar un paquete FIN (recibiendo también un ACK) y la conexión quedará cerrada definitivamente.

Nótese que el segundo proceso puede no enviar el paquete FIN. Esto significa que ese extremo de la conexión no se cerrará, pudiendo aún enviar datos a través de la misma. De lo contrario, en caso de desear terminar la conexión, puede combinar el ACK y el FIN en un solo paquete (esta es la situación más común).

La siguiente figura ilustra la forma general de terminación de una conexión TCP:

Análisis a nivel de transporte

Habiendo revisado los conceptos más relevantes, analizaremos ahora la conexión realizada desde el punto de vista del protocolo TCP. Supondremos que el puerto utilizado por el cliente es 4683 (el del servidor, recordemos, es 2222).

La siguiente figura muestra una visión simplificada de esta conexión:

(Ver imagen ampliada)

Veamos qué función cumple cada paquete:

1. El cliente envía un SYN al servidor, con número de secuencia x₀.
2. El servidor responde con un paquete SYN, con número de secuencia y₀ y un ACK con x₀+1 (en adelante, x₁).
3. El cliente envía un paquete ACK del SYN que acaba de recibir, con valor y₀+1 (en adelante, y₁). (A partir de este momento la conexión se encuentra establecida y puede comenzar el intercambio de datos entre las aplicaciones.)
4. El servidor envía un paquete PSH («push«) conteniendo la cadena «Bienvenido.\n» (12 bytes), con número se secuencia y₁. (El caracter «\n«, newline, representa el fin de línea.)
5. El cliente envía un ACK por la correcta recepción del paquete anterior. El número de ACK es y₁+12 (que llamaremos y₂ y será el próximo número de secuencia utilizado por el servidor).
6. El cliente envía la cadena «salir\r\n«, con número de secuencia x₁. (Los caracteres «\r\n» representan el fin de línea. Ver nota al final de la sección.)
7. El servidor envía el ACK correspondiente, con el valor x₁ más la longitud de «salir\r\n» (7), que llamaremos x₃.
8. El servidor envía la cadena «Adios\n» (7 bytes), con número de secuencia y₂.
9. El cliente envía el ACK con el valor y₂+7 (en adelante, y₃).
10. El servidor cierra su lado de la conexión enviando un paquete FIN, con secuencia y₃.
11. El cliente, que también cierra su conexión, envía un paquete FIN con secuencia x₃, con el ACK del paquete anterior (y₃+1).
12. El servidor envía el ACK del anterior paquete FIN (con valor x₃+1), con lo cual la conexión finaliza.

Nota: En este ejemplo podemos ver un error en el diseño del protocolo de aplicación, ya que el servidor representa los fines de línea con el caracter «\n» («newline», código ASCII 10), en tanto que el cliente está usando los caracteres «\r\n» («newline» y «carriage return», códigos ASCII 10 y 13, respectivamente). Esta última es la forma de representación más utilizada en aplicaciones TCP/IP.

Nivel de red

Antes de realizar el análisis a «nivel de red» (protocolo IP) vamos a suponer que tenemos la siguiente topología:

El cliente se ejecuta en el host cuya dirección IP es 200.0.0.1. El mismo está conectado a la red local 200.0.0.0/24 y su gateway («router«, «enrutador» o «puerta de enlace«) es el host 200.0.0.21.

La dirección de red local está compuesta por la dirección de red propiamente dicha, 200.0.0.0, y la máscara de red, 24 (que también puede ser representada como 255.255.255.0). Esto significa que los primeros 24 bits de cualquier dirección serán interpretados como identificador de la red, en tanto que los últimos 8 identificarán a cada host (recordemos que, aunque la notación usual es escribir las direcciones IP como cuatro números decimales separados por puntos, en realidad se componen de 32 bits).

Por ejemplo, en el contexto de esta red, la dirección 200.0.0.45 será considerada una dirección local (por coincidir los primeros 24 bits con los de la dirección de red). Esto significa que cualquier paquete destinado a dicha dirección IP, será entregado «localmente» (o sea, directamente a través del protocolo de enlace, como veremos más adelante).

En el caso de una dirección de destino «no-local», los paquetes serán entregados al gateway 200.0.0.21 (usando el protocolo de enlace), quien será luego el encargado de entregar el paquete al host de destino (si este perteneciera a alguna red local a la que dicho gateway esté conectado), o reenviarlo a través de otro gateway (en caso contrario).

De la misma manera el servidor, cuya dirección IP es 100.0.0.1, pertenece a la red 100.0.0.0/24, cuyo gateway es 100.0.0.35.

Análisis a nivel de red

A nivel IP no hay demasiado que agregar. Aquí se realiza el «ruteo» (o «encaminamiento«) de los paquetes provenientes de la capa de transporte (que en este nivel se denominan «datagramas«) desde la dirección IP de origen hasta la de destino (alternando estos roles 100.0.0.1 y 200.0.0.1 según sea el emisor el servidor o el cliente, respectivamente).

Un campo interesante que se añade es el TTL («tiempo de vida» o «time to live«), que tiene un valor inicial en el host que produce el paquete (generalmente 64) y luego es decrementado por cada gateway por el que pasa. Si un gateway recibe un paquete con el campo TTL en cero, el mismo es descartado y se genera un paquete del protocolo ICMP (usado para control y mensajes de error) dirigido a su emisor, indicando que dicho paquete ha excedido la cantidad máxima de saltos. Esta medida es implementada para evitar que, quizás por un error de ruteo, un paquete quede indefinidamente «dando vueltas» por la red.

En este ejemplo supondremos que el enrutamiento de paquetes es simple (estático), para facilitar las explicaciones. Existen casos complejos en donde se utiliza enrutamiento dinámico, en los cuales paquetes pertenecientes a la misma comunicación pueden enviarse por caminos distintos, alterando inclusive el orden en que llegan al destino (y hasta pudiendo producirse pérdidas).

Debemos tener en cuenta que estamos usando el llamado IPv4 (IP versión 4), ya que también existe el IPv6 (IP versión 6), cuya aplicación se está difundiendo rápidamente en Internet y que soluciona muchos inconvenientes que presenta el anterior.

Nivel de enlace

El «nivel de enlace» es el nivel más cercano al «nivel físico» y es totalmente independiente del protocolo TCP/IP. Existen gran variedad de tecnologías de este tipo; siendo las más comunes Ethernet, WiFi, PPP, Frame Relay, ATM, entre otras.

Supondremos el caso más común: una red Ethernet. Este protocolo se basa en el uso de direcciones de 6 bytes (48 bits), que no son «ruteables» (aquí no existen gateways), por lo cual se utiliza en redes de área local (LANs). Cada dispositivo Ethernet tiene asociada una dirección única (asignada por el fabricante del mismo), la que usualmente se denomina MAC Address.

Resolución de direcciones

Supongamos que el host 200.0.0.1 quiere enviar un paquete IP al host 200.0.0.33. Como ambos están en la misma red local (los primeros 24 bits de sus direcciones coinciden), lo único que debe hacer es averiguar cuál es la dirección Ethernet de este último. Para ello, se utiliza el protocolo ARP («Address Resolution Protocol«).

El funcionamiento es muy simple. El host 200.0.0.1 envía un paquete (en terminología de Ethernet se denomina «frame«) a la dirección ff:ff:ff:ff:ff:ff (las direcciones Ethernet se denotan con seis bytes en hexadecimal separados por dos puntos), que es la dirección de broadcast (que llega a todos los hosts de la red) preguntando quién tiene la dirección IP 200.0.0.33. Dicha solicitud ARP tiene como origen la dirección Ethernet del emisor (supongamos, 00:30:b8:80:dd:11).

El poseedor de esa dirección IP le responderá con otro frame con su dirección Ethernet como origen (supongamos, 01:4e:bb:a1:01:8b). De ahora en más, cada vez que el host 200.0.0.1 quiera enviar un paquete IP al host 200.0.0.33, enviará un frame Ethernet proveniente de la dirección 00:30:b8:80:dd:11 a la dirección 01:4e:bb:a1:01:8b, conteniendo el paquete original. (La información sobre las direcciones ARP se almacenan en cada host en una tabla que tiene una duración de algunos minutos.)

Fragmentación

Puede ocurrir que el tamaño de los paquetes producidos por la capa de red (IP, en nuestro caso) sean de un tamaño mayor al máximo que puede transmitir el medio físico utilizado (MTU o «unidad máxima de transferencia«. Por esto, puede ocurrir que los paquetes se fragmenten, para acomodarse a esta limitación.

Esta situación puede volver a presentarse a lo largo del camino «físico» que recorra la información, siendo responsabilidad de cada gateway el fragmentar y reensamblar los paquetes para preservar los datos.

Análisis a nivel de enlace

Volviendo ahora a nuestro experimento, el host donde se ejecuta la aplicación cliente (200.0.0.1) debe enviar paquetes IP al host en donde se ejecuta el servidor (100.0.0.1). Claramente, éste último no pertenece a su red local, por lo cual deberá enviarlo a través del gateway.

Para ello, usando el protocolo ARP averigua la dirección Ethernet del gateway (cuya dirección IP, recordemos, es 200.0.0.21), que supondremos es 00:01:02:ed:41:61. Una vez hecho esto, envía un frame Ethernet (con origen
00:30:b8:80:dd:11 y destino 00:01:02:ed:41:61), conteniendo el paquete IP cuyo origen es 200.0.0.1 y con destino a 100.0.0.1.

El gateway recibirá el frame (puesto que la dirección Ethernet de destino es la suya) y dentro de él encontrará un paquete IP dirigido a 100.0.0.1. Decrementará el campo TTL y, en base a las reglas definidas en su «tabla de enrutamiento» (o «tabla de ruteo«), lo reenviará hacia el gateway correspondiente (usando el protocolo asociado al medio físico mediante el cual esté conectado con éste).

Una situación similar se presenta considerando los paquetes emitidos por el host 100.0.0.1 hacia 200.0.0.1.

De esta manera, el mismo paquete IP va atravesando distintos gateways a través de distintos medios físicos (que involucran diferentes protocolos de enlace), hasta llegar al host de destino. Por ejemplo, el paquete original puede llegar al primer gateway a través de un frame Ethernet, ser enviado por este al gateway del proveedor de Internet a través de un paquete PPP, atravesar una red ATM en Internet, luego llegar por un enlace Frame Relay al gateway de la red de destino, y ser entregado en otro frame Ethernet al host de destino.

El camino de la información a través de las distintos niveles

La siguiente figura ilustra un ejemplo del camino que sigue la información desde la aplicación que la produce, a través de los distintos niveles o capas de cada protocolo.

(Ver imagen ampliada)

Nota: Este ejemplo es una simplificación de la realidad. Se han omitido muchos otros datos que forman parte de cada protocolo (controles de error, delimitadores, indicadores de longitud, etc.), que no son relevantes en el contexto de este tutorial.

1. Nivel de aplicación: La aplicación (en este caso, el programa cliente), escribe la cadena «salir\n«.
2. Nivel de transporte: En la capa TCP forma un paquete agregando el número de secuencia (20), puerto de origen (4781) y puerto de destino (2222).
3. Nivel de red: En la capa IP se forma un paquete (datagrama) añadiendo la dirección IP origen (200.0.0.1), destino (100.0.0.1), el TTL (64) y un valor que identifica el protocolo del paquete encapsulado (0x06, valor hexadecimal que representa al protocolo TCP).
4. Nivel de enlace: En la capa Ethernet se forma un nuevo paquete (frame) agregando las direcciones Ethernet de origen (00:30:b8:80:dd:11) y destino (00:01:02:ed:41:61, la dirección del gateway, cuya IP es 200.0.0.21). Se añade además el identificador del tipo de protocolo del paquete contenido (el valor 0x800 corresponde al protocolo IP).
5. Nivel físico: El frame formado es enviado a través del medio físico que vincula los hosts de la red local (típicamente, cable de par trenzado).

Como puede apreciarse, tanto el protocolo IP como Ethernet «encapsulan» a otros protocolos. Esto permite realizar distintas combinaciones, creando «túneles» (como en el caso del ampliamente difundido y utilizado PPPoE).

Software, modelo conceptual y hardware

El siguiente diagrama muestra la relación entre cada uno de los componentes lógicos analizados, su implementación y la división entre hardware y software.

Para finalizar

En este tutorial hemos recorrido cada uno de los principales componentes del protocolo TCP/IP y analizado su función a través de un ejemplo concreto (aunque simple).

Deliberadamente, hemos omitido algunos puntos importantes, como el sistema DNS (que posibilita la utilización de nombres en vez de direcciones IP), la asignación automática de direcciones IP (a través del protocolo DHCP), y algunos detalles sobre direccionamiento y enrutamiento IP. (Quizás algunos de ellos sean motivo de próximos tutoriales.)

Es el deseo del autor que a través de la lectura del presente tutorial se haya podido lograr un panorama general acerca del funcionamiento de las redes TCP/IP, posibilitando al lector su avance hacia temas (y, por qué no, experimentos) más complejos e interesantes.

Las críticas, sugerencias y comentarios son bienvenidos y agradecidos.

(Recuerde que puede descargar este tutorial en otros formatos (HTML sin decoraciones y PDF).)

Actualización del 5 de diciembre de 2006: He publicado un artículo sobre el funcionamiento del DNS, uno de los temas no cubiertos por el presente tutorial.

En muchos casos, no ayudan ni el pésimo nivel de muchas materias universitarias (algunos analistas son formados sin siquiera una introducción a las redes), ni el afán de ocultar la realidad de muchos libros de texto. No me ocuparé del primer caso (al menos por ahora), pero sí quiero hacer hincapié en el segundo.

Muchos textos nos presentan algunas definiciones, en términos demasiado amplios y poco técnicos, para luego guiarnos por distintas configuraciones (típicamente usando ejemplos sobre la plataforma Windows, plagados de capturas de pantallas y cuadros de diálogo). Parecen querer esquivar, a toda costa, los detalles «duros» detrás de todo esto: el conjunto de protocolos TCP/IP. Apenas se detienen en lo indispensable: direccionamiento IP y algo (lo menos posible) sobre enrutamiento de paquetes (o ruteo).

Así es que luego aparecen informáticos que creen que un «puerto» abierto es algo peligroso y poco recomendable, que son incapaces de detectar la causa del menor problema en la red («se cayó la red«, es todo lo que pueden decir) y gente que habla de «puertas de enlace» y «conectividad limitada o nula» sin tener la menor sospecha de qué significan estas cosas.

Es notable el caso de la bibliografía producida por empresas como Microsoft y Cisco que, con la promesa de introducir al lector al campo de las redes informáticas, lo único que hacen es tratar de «capturarlo» en el mundo de sus productos. Esto se logra, por ejemplo, redefiniendo todas las palabras que les sea posible a su terminología propia, impidiendo al desafortunado lector el poder relacionar los conocimientos adquiridos con otros textos. De esta forma se forman «especialistas» que desconocen los fundamentos y las cuestiones más generales.

Más allá del por qué de este enfoque poco útil (aunque tan usual), lo importante es destacar que el protocolo TCP/IP es extremadamente simple.

TCP/IP fue diseñado a principios de la década de los ’70 con el objetivo de interconectar redes de gran tamaño. Si nos detenemos a pensar en las capacidades de las computadoras de la época, sumando el hecho de que no podía desperdiciarse equipamiento en las funciones de la red, resulta claro que el protocolo a diseñar debía ser simple y no requerir de gran poder de cómputo para su implementación.

La simpleza de TCP/IP ha sido la clave del éxito de Internet y es la razón por la cual ésta está dejando obsoleta a otras redes complejas como el sistema de telefonía. (Un excelente artículo, «The rise of the stupid network«, analiza esto de forma muy clara.)

Desde un punto de vista «no técnico» la simpleza de Internet está claramente explicada en el artículo «World of Ends» (traducido al castellano como «Mundo de Extremos«).

Para aquellos con una base de conocimientos técnicos, he aquí una serie de sugerencias:

• En Wikipedia hay una página dedicada a los protocolos de Internet con abundante información sobre cada uno de ellos y con enlaces muy recomendables.
• El mejor libro que he leído sobre TCP/IP es «TCP/IP Illustrated Volume 1» de W. Richard Stevens.
• Existen herramientas muy útiles, como WireShark (antes llamado Ethereal), que permiten capturar tráfico de la red y analizarlo. Así es posible «ver» cómo funcionan los protocolos. Un experimento muy simple, por ejemplo, es capturar el tráfico mientras uno abre una página web en su navegador.
• Ejercitar el pensamiento crítico. Buscar, indagar y experimentar acerca del funcionamiento de las redes.
• Para profundizar tanto como se desee, no es necesario comprar ningún libro. Toda la documentación de los protocolos de Internet y su evolución está disponible a través de los «Request For Comments«, o RFC (gran cantidad de ellos traducidos al castellano).

Es penoso ver a programadores que no saben en dónde ni cómo se ejecutan sus aplicaciones. Por más que posean una herramienta de desarrollo que, con hacer un clic, les genere un sistema cliente/servidor muy complejo; sin comprender lo que hay «detrás» jamás serán capaces de descubrir el origen de ciertos errores («en mi PC corria bien, pero cuando lo subo al servidor no anda«).

También es triste ver a informáticos recomendando la compra de dispositivos de red (switches, routers, etc.) para solucionar problemas que podrían resolverse con un direccionamiento IP apropiado.

Lo más lamentable de esto es que la solución es muy simple, y está al alcance de cualquiera. Realmente… ¿quién no quiere comprender cómo funciona Internet?