TCP/IP: El protocolo clave de Internet

CURSO DE TCP/IP INTRODUCCIoN
Si alguna vez has intentado comprender Internet, seguro que has acabado frente a un libro de TCP-IP. Y seguro que a la sexta pgina lo has dado por IMPOSIBLE!!! TCP-IP es el alma de la red, nosotros te ofrecemos un curso MUY ESPECIAL ;)
1.Introduccin a la introduccin.
Probablemente muchos de vosotros esperabais con impaciencia un curso como este, as que espero que vuestra alegra, al ver que al fin nos metemos de lleno con el tema en esta revista, no se vea frustrada al descubrir que vuestro profe en este curso va a ser el mismo que mes tras mes os ha ido aburriendo soberanamente con la serie RAW. ;-) Si es cierto que os parezco aburrido, en mi defensa he de alegar que la descripcin detallada de un protocolo es algo aburrido de por s y, aunque he hecho lo posible por hacer artculos amenos, cuando hay que ponerse serio, hay que ponerse serio. Aprovecho esta ocasin para agradecer a Adhara (conocida como MariAn antes de digievolucionar) su aportacin en este sentido, con las caricaturas e ilustraciones que ha aportado para amenizar en la medida de lo posible la serie RAW y que, por supuesto, tambin seguir aportando en este curso que comienza. Os plantear el terrible dilema que he sufrido para poder comenzarlo. Para ayudarme a la hora de estructurar un poco las ideas he ojeado multitud de libros y cursos de TCP/IP para ver cmo abordaban el problema y poder explicarlo desde cero, que era mi gran reto. Lamentablemente, en ninguno he encontrado lo que yo buscaba, una forma de introducir los conceptos de forma que alguien sin ningn conocimiento pueda no slo aprenderse de memoria un montn de formatos de cabeceras, comandos de protocolos, y un PC PASO A PASO N 17
glosario de trminos; si no realmente llegar a hacer suyos los conceptos y comprenderlos de una forma totalmente natural. Por supuesto, ya se que la mayora de los lectores de esta revista tienen ya un nivel aceptable de conocimientos, pero he de enfocarlo no slo para los lectores veteranos, si no tambin para aquellos totalmente novatos que, sin duda, sern los que ms se beneficien de este curso y que les abrir las puertas para llegar a comprender en profundidad todo lo dems que se ensee en la revista a partir de ahora. Sin duda alguna, el TCP/IP es uno de los pilares de todo este jaleo en el que estamos metidos. ;-) As que decid coger al toro por los cuernos, y enfocar la cuestin desde un punto de vista diferente.
TCP/IP
TCP / IP: Transmission Control Protocol / Internet Protocol = Protocolo de Control de Transmisin / Protocolo de Internet
Cuntos cursos de TCP/IP empiezan contando el modelo OSI (Open Systems Interconnection = Interconexin de Sistemas Abiertos)? A los que hayis seguido alguno de esos cursos publicados en Internet o en otras revistas, os qued claro desde el principio, por ejemplo, para qu servia la capa de sesin del modelo OSI? No pensis que quiz empezar abordando el problema planteando un modelo terico tan complejo puede ser contraproducente? No os quedaron Pgina 31
Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin
ms dudas despus de terminar el tema de introduccin que antes de empezarlo? Seguro que la mayora dejasteis el curso a la mitad (y otros ni siquiera pasasteis de las primeras pginas). El empezar cualquier curso de TCP/IP hablando del modelo OSI parece que ha sido la solucin estndar para solucionar el reto de mostrar el concepto de los protocolos por capas a gente totalmente nueva en el tema. Pero a m personalmente nunca me ha parecido una buena idea, as que he tomado una medida muy arriesgada, y es intentar dar un nuevo enfoque a este reto. No s qu resultados tendr mi enfoque, pero espero que al menos sea una alternativa para que aquellos que no terminan de captar los conceptos por los medios clsicos tengan aqu una segunda oportunidad. Qu esperabais? Que mi curso de TCP/IP fuese como todos los dems? Para eso tenis millones de libros sobre el tema! Lo que pretendemos dar en esta revista son nuevas visiones que no se pueden encontrar en las fuentes convencionales. El juzgar si nuestro enfoque es mejor que el convencional, ya depende de cada lector, y confo en que todos vosotros tendris buen juicio para escoger la opcin que para cada uno de vosotros resulte ms adecuada. Como veris, mi enfoque intenta mostrar los conceptos puros, al margen de cualquier detalle tcnico, mediante varios smiles con otros conceptos, bien conocidos por todos, de nuestra vida cotidiana. Por supuesto, despus de este primer artculo vendrn otros, y ah si que veremos ya en profundidad los detalles tcnicos, los cuales nos entrarn con muchsima ms facilidad si previamente hemos dedicado un tiempo imprescindible a llegar al fondo de los conceptos. Pgina 32
2. El concepto fundamental de protocolo por capas

Empezaremos nuestro viaje metafrico por el mundo de los protocolos situndonos en un hospital, donde los doctores PyC y Scherzo hablan acerca de la prxima operacin a corazn abierto que tendrn que llevar a cabo. El doctor PyC tiene unas dudas acerca de la complicadsima operacin, y acude al doctor Scherzo en busca de ayuda.
PC PASO A PASO N 17
Dios mo, como haya entre los lectores algn mdico o estudiante de medicina... que me perdone por la increble cantidad de estupideces que acabo de soltar! XD Al margen de si tiene sentido o no la parrafada, supondremos que se trataba de una conversacin perfectamente normal entre cirujanos. Ahora vamos a plantearnos una serie de cuestiones sobre estas vietas. En primer lugar, qu han hecho bsicamente PyC y Scherzo? COMUNICARSE. Se convertira en sta otra: Ahora vamos a analizar un poco en qu ha consistido esa comunicacin. En primer lugar, lo que ms nos llama la atencin es el lenguaje tcnico utilizado, que slo es comprendido por los cirujanos. Igual que los cirujanos tienen su propio lenguaje tcnico, los informticos tambin tienen el suyo, los arquitectos el suyo, y los abogados el suyo, todos ellos diferentes entre s. Pero, a pesar de que todos estos lenguajes tcnicos sean diferentes, todos ellos se apoyan en una misma base, que es el idioma; en este caso, el castellano. El lenguaje tcnico de los cirujanos consiste nicamente en una serie de palabras y expresiones que permiten expresar los trminos especficos que requieren los cirujanos para comunicarse en su trabajo. Por tanto, no es un lenguaje completo, ya que no posee una gramtica propia que permita mantener una conversacin sin apoyarse en un idioma bsico, como puede ser el castellano. Si, por ejemplo, eliminsemos de la parrafada del doctor PyC todo aquello que no formase parte exclusivamente del lenguaje tcnico de los cirujanos, esta frase: PC PASO A PASO N 17
Por la cara que pone el doctor Scherzo podemos estar seguros de que utilizando tan slo el lenguaje tcnico, sin apoyarnos en la base que es el idioma castellano, es imposible que dos cirujanos se comuniquen. Lo mismo que pasa con los cirujanos pasa con cualquier otro grupo de profesionales que utilicen su propio lenguaje tcnico. Todos ellos apoyan toda su conversacin en un idioma comn, que puede ser el castellano, el ingls, o cualquier otro. Por supuesto, para que dos profesionales se entiendan tienen que hablar no slo el mismo lenguaje tcnico, si no tambin el mismo idioma comn. Pgina 33
Si el doctor PyC hablase Japons, sin duda el doctor Scherzo habra puesto la misma cara de incomprensin. Segn lo que hemos visto hasta ahora, la comunicacin entre los dos doctores funciona gracias a dos capas independientes: el idioma, y el lenguaje tcnico.
entrar ms en profundidad en la comunicacin que vimos en las vietas. Qu otro medio comn han utilizado el doctor Scherzo y el doctor Pyc para comunicarse? El habla! Si trasladsemos toda esa conversacin a un papel, no tendra el mismo sentido? Y si la trasladsemos a una conversacin telefnica? O a una conversacin por IRC (Internet Relay Chat)? Los dos doctores se han apoyado en un medio fsico comn, que es la voz, pero perfectamente podran haber mantenido la misma conversacin a travs de otro medio fsico, como la escritura, o el telfono.
Cul es el motivo por el cual es esto as? Pues, si pensis un poco, llegaris vosotros mismos a la conclusin. Imaginad que el lenguaje tcnico de los cirujanos fuese un lenguaje completo, con sus frmulas de saludos, despedidas, una gramtica completa para construir las frases, palabras para expresar cualquier trmino comn en cualquier comunicacin (como los habituales: me lo repita, habla ms despacio, que no me da tiempo a apuntarlo!, etc.), e incluso tuviese sus propios nombres, en lugar de los que tenemos en castellano (doctor Pyc, y doctor Scherzo). Sera una completa locura! Desde luego, no sera nada prctico que cualquier cirujano tuviese que aprender un idioma totalmente nuevo slo para poder comunicarse con sus colegas. Lo ms prctico, y lo ms lgico, es utilizar el recurso conocido por todos que es el idioma castellano, y simplemente ampliarlo con una serie de trminos que permitan entrar en detalle en los conceptos manejados por los cirujanos. Una vez comprendida la necesidad de comunicarse utilizando dos capas, vamos a Pgina 34
Tanto si esa conversacin es hablada como si es escrita, seguira utilizando tanto el lenguaje tcnico de los cirujanos, como el idioma castellano. En nada cambiara, salvo en el hecho de que el medio utilizado sera diferente. Ahora bien, igual que un cirujano japons no puede entenderse con un cirujano de Jan, si el doctor PyC le hubiese soltado la parrafada al doctor Scherzo por correo, y ste le hubiese respondido a viva voz cuando recibiese la carta (es decir, que se lo habra contado a las paredes), tampoco habra sido posible una comunicacin. Ambos interlocutores tienen que compartir el mismo medio fsico para comunicarse. Si un interlocutor est utilizando el telfono, y el otro est respondiendo por escrito en un papel, jams podr haber una comunicacin. Por supuesto, tampoco sirve de nada que ambos hablen a viva voz, si cada uno est en un lugar diferente, donde no se puedan escuchar mutuamente. Podemos considerar, por tanto, al medio fsico como otra capa de la comunicacin. En este caso, esta capa ya no existe por una conveniencia de hacer las cosas ms fciles, si no por una necesidad natural. PC PASO A PASO N 17
entre los dos interlocutores. Nos da exactamente igual que el intrprete no entienda ni papa de la conversacin, ya que esa conversacin no va dirigida a l, no es ms que un mero intermediario. l tiene que saber nicamente ambos idiomas: japons y castellano. Una vez que el intrprete ha traducido la frase Vamos a hacer una incisin subyugular ya ser problema de los cirujanos entenderse entre ellos, ya que el intrprete no tiene ni idea de qu es una incisin subyugular, pero si que sabe traducir las palabras literalmente. Vamos a ver qu ocurre ahora si el doctor Me-Iwa, de Japn, quiere hablar con el doctor PyC acerca de la operacin de cardiopata precartida. Por supuesto, no podrn comunicarse directamente, al hablar distintos idiomas, pero por suerte el doctor Me-Iwa tiene un intrprete que puede hablar tanto en castellano como en japons, por lo que ste sera el escenario ahora: Por tanto, podramos considerar al intrprete como un intermediario en la conversacin que slo llega a comprender hasta cierta capa de la comunicacin pero que, an as, es capaz de transmitir todo, confiando en que los interlocutores sern capaces de comprenderse una vez traducido el idioma. Ms adelante profundizaremos mucho ms en la cuestin de los intermediarios en la comunicacin, as que quedaos bien con esta idea. ;-)
3. Las capas de TCP/IP

Al fin vamos a ver la relacin que tiene todo esto con el tema que nos interesa! Ya hemos comprendido la necesidad de estructurar la comunicacin en diferentes capas, tanto por necesidad fsica, como por conveniencia para facilitar la comunicacin (reducir su complejidad). Por supuesto, eso es algo que ocurre en todo tipo de comunicacin y, por tanto, la comunicacin entre mquinas no va a ser menos. Por un momento, imaginemos que no hubiese capas en la comunicacin por Internet. Si yo tuviese que programar un cliente de correo electrnico (como por ejemplo el Outlook Express, tendra que idear desde cero toda una serie de funciones para interconectar al remitente y al destinatario, una serie de Pgina 35
Ahora meditemos un poco acerca de este nuevo personaje, el intrprete. Lo ms probable es que este intrprete sea un estudiante de filologa, o simplemente un estudiante de idiomas de academia pero, en cualquier caso, es poco probable que el intrprete sea un cirujano. Pero, es realmente necesario que el intrprete sepa algo de ciruga? El lenguaje tcnico de los cirujanos al fin y al cabo no es ms que una extensin del idioma, por lo que bastara con que el intrprete simplemente conociese ambos idiomas para transmitir la conversacin PC PASO A PASO N 17
funciones para asegurarme de que el mensaje llegue sin errores hasta el destino, una serie de funciones para identificar a ambas partes, etc., etc. Si despus me da por programar un cliente de FTP (si no sabes lo que es el FTP File Transfer Protocol-, descrgate gratis el nmero 1 de esta revista desde www.hackxcrack.com), tendra que inventarme de nuevo y desde cero unas funciones para interconectar ambas partes (nuestro cliente con el servidor), unas funciones para asegurarme de que los ficheros y los comandos lleguen sin errores, una serie de funciones para identificar ambas partes, etc., etc. El hacer las cosas de esta manera, no slo sera una cantidad ingente de trabajo innecesario, si no que adems dificultara enormemente que los programas se entendiesen entre s. Si todas las aplicaciones que utilizan Internet tienen que realizar una serie de tareas comunes, como son la interconexin de las partes implicadas en la comunicacin, la identificacin de ambas partes, la correccin de errores, el ajuste de las velocidades de recepcin y transmisin, etc., etc., por qu no utilizar un lenguaje comn para todas ellas? Igual que todos los profesionales (cirujanos, informticos, arquitectos...) utilizan el idioma castellano como base sobre la cual apoyan luego sus lenguajes tcnicos propios, tambin las mquinas conectadas a Internet utilizan un mismo idioma comn como base sobre la que luego apoyar cada lenguaje especfico. En este caso, el idioma comn de las mquinas es el famoso TCP/IP, y los lenguajes tcnicos que utiliza cada mquina apoyndose en TCP/IP son los que permiten las diferentes tareas, como transmitir ficheros (FTP), enviar correo (SMTP), mostrar pginas Web (HTTP), etc., etc. Pgina 36
Comparacin entre las capas de la comunicacin entre dos personas y la comunicacin entre dos mquinas. Esta comparacin no es muy precisa, as que la muestro slo como una primera aproximacin a la idea.
Los que hayis seguido mi serie RAW desde el principio, comprenderis ahora por qu una y otra vez repeta frases como: protocolo que funciona sobre TCP/IP, o protocolos por encima del nivel de TCP/IP, etc. Por ejemplo, tenis a mano el nmero 14 de la revista, en el que hablaba sobre el protocolo DNS? Mirad el primer prrafo de ese artculo, y veris que deca: Por primera vez en la ya veterana serie RAW, no se trata de un protocolo basado en TCP, si no en el an desconocido UDP! Esto sera lo mismo que decir: este lenguaje que vamos a contar no se basa en el idioma castellano, si no en el idioma japons. Ahora ya comprendemos la necesidad de separar por capas las comunicaciones entre mquinas para facilitar la comunicacin, y reutilizar el trabajo ya hecho para no tener que reprogramarlo cada vez. Y precisamente esas funciones que son utilizadas por muchos programas para que estos no tengan que reprogramarlas desde cero, son precisamente las funciones que te da la API de un Sistema Operativo . PC PASO A PASO N 17
Por ejemplo, un programa que funcione bajo Windows no tiene que preocuparse de saber cmo dibujar una ventana en la pantalla, si no que simplemente le dice al sistema dibjame una ventana de estas caractersticas y Windows har el trabajo sucio por l. Todava recuerdo los tiempos en los que programaba aplicaciones grficas en MS-DOS y me tena que currar desde cero todo el interfaz... un autntico infierno. Perdas ms tiempo con el interfaz que con el propio programa. Pues lo mismo que ocurre con las ventanas, que son una funcin comn a todas las aplicaciones de Windows, tambin ocurre con las comunicaciones, que tienen una serie de funciones comunes a todas las aplicaciones de comunicaciones. Estas funciones comunes, que son las que proporciona el idioma TCP/IP, se ubican precisamente en el Sistema Operativo, para que sea l el que lidie con los detalles, igual que las ventanas las gestiona el Sistema Operativo, y es l el nico que se preocupa de conocer los detalles para dibujarlas. Este es el motivo por el que, antes de conectar con Internet o con cualquier otra red, tenemos que configurar el protocolo TCP/IP en n u e s t r o sistema. Configuracin de TCP/IP en W indows. A lo largo del curso probablemente veremos cmo configurar correctamente el idioma TCP/IP con diferentes sistemas. PC PASO A PASO N 17
Por el momento, continuaremos con los conceptos sin entrar en ningn detalle. Ahora que ya habis comprendido el concepto de capas, he de pediros que os olvidis del ejemplo de los cirujanos, porque mi intencin era nicamente que comprendieseis el concepto de capas, pero no mostrar metafricamente cada capa del protocolo TCP/IP con su equivalente en el mundo real, ya que las capas que forman TCP/IP no tienen prcticamente nada que ver con las capas que forman la comunicacin entre dos cirujanos. La nica capa que s que tienen en comn tanto las mquinas como los cirujanos es la del medio fsico ya que, como dije, esta capa no surge como una facilidad para la comunicacin, si no que es una necesidad natural irremediable. Igual que dos cirujanos necesitan compartir un mismo medio para comunicarse, tambin han de hacerlo dos mquinas.
En el caso de las mquinas, hay que tener en cuenta no slo la tecnologa utilizada en los propios cables que interconectan las mquinas (que sera el medio fsico) si no tambin el cmo estn conectadas: cada cable conecta slo dos mquinas, un slo cable conecta a la vez a muchas mquinas entre s, etc. Es decir, cmo se enlazan las mquinas entre s. Ya veremos mucho ms sobre esto ms adelante, pero de momento nos quedaremos con la idea de que existe una segunda capa, conocida como capa de enlace. Para los impacientes, deciros que aqu es donde se ubicara el famoso protocolo ARP (Protocolo de Resolucin de Direcciones), que es una parte de la capa de enlace utilizada normalmente en nuestros PCs. Pgina 37
Por encima del nivel de enlace, tenemos ya la primera capa que realmente nos sonar, que es la llamada capa de red y que, en nuestro caso (el caso de TCP/IP) es la capa llamada IP. Cul es la responsabilidad de esta capa? Pues principalmente una: conseguir que la comunicacin llegue desde el origen hasta el destino. sta es la capa encargada de identificar a las diferentes mquinas, para que stas puedan diferenciarse unas de otras, y mantener as comunicaciones separadas. Si no existiese esta capa, todos los datos de Internet llegaran a todas las mquinas conectadas a la red. No habra forma de ver una pgina Web, ya que no se podra diferenciar una de otra; no se podra enviar un e-mail, ya que no sabramos cmo encontrar nuestro servidor de correo, etc., etc. Supongo que esto no os sonar muy raro, teniendo en cuenta que las direcciones utilizadas en Internet se llaman precisamente direcciones IP. Casualidad? ;-)
Las funciones de esta capa son muchas, pero bsicamente podramos resumirlo en una: permitir el establecimiento de conexiones independientes y seguras, con todo lo que ello implica. Para comprender esto, as como para comprender mejor la capa IP, os muestro a continuacin una serie de puntos que, de nuevo a base de smiles, os explicarn muchas de las funciones llevadas a cabo por cada capa.
3.1. La capa IP: La necesidad de direccional

Para comprender la necesidad de la capa IP (Internet Protocol = Protocolo de Internet) presentaremos un nuevo escenario, bien conocido por todos, que es el correo postal de toda la vida. En nuestro ejemplo, PyC, residente en Madrid, quiere enviar una carta a la siguiente direccin: Perico Palotes C/Pirulin. N12. 1 A. 35003 Villapalotes (Huelva). Cmo puede llegar hasta su destino la carta despus de que PyC la eche en el buzn de su barrio? Todos conocemos bien el proceso. Primero, el cartero del barrio recoge todas las cartas del buzn, y las lleva a la oficina de correos ms cercana. Una vez ah, se ve que el destino de esta carta es Huelva y, por tanto, el sobre es transportado hasta esa provincia en un furgn de Correos. En esa provincia, el sobre se lleva a la oficina de correos PC PASO A PASO N 17
Pero, an nos faltan muchas funciones comunes, verdad? Como podis adivinar, del resto de funciones se encarga la capa que est por encima de la capa IP que es, precisamente, la capa TCP.
En cualquier modelo (ya que TCP/IP no es el nico modelo de protocolo por capas que existe) a esta capa se la conoce como capa de transporte.
Pgina 38
correspondiente. En esa oficina, comprueban la direccin, y llevan la carta hasta el buzn personal de Perico Palotes.
Funcionamiento bsico del sistema de correo postal.

Gracias a las direcciones postales todo el sistema de Correos puede funcionar. Y no slo gracias a la direccin del destinatario, si no tambin a la del remitente, que ser una direccin con el mismo formato (nombre, calle, cdigo postal, poblacin, y provincia). Gracias a la direccin del remitente se sabr a quin informar si la carta no llega a su destino, y el destinatario podr responder a la carta si lo desea. Pues exactamente lo mismo ocurre con las direcciones de Internet. Aunque estas direcciones, las famosas IPs, aparentemente no consten de varios campos (nombre, calle, poblacin, etc.), en realidad esos campos s que existen, y estn codificados dentro del propio nmero que forma la direccin IP. Igual que existen las oficinas de correos, tambin existen una serie de mquinas dedicadas exclusivamente a transportar los sobres de Internet de una mquina a otra. Estas mquinas mediadoras en la comunicacin son conocidas habitualmente como routers. Estos routers, al igual que hacen las oficinas de Correos, se dedican a analizar las direcciones Ips para saber dnde tendrn que enviar el sobre para que, paso a paso, termine llegando a su destino. PC PASO A PASO N 17
Comparacin entre los elementos del correo postal y los elementos de la comunicacin de dos mquinas en Internet. Los furgones de correos, los carteros, y las oficinas de correos que forman la red postal, seran los routers que forman la red Internet. Igual que los carteros no abren las cartas, porque les basta slo con ver el sobre, los routers tampoco ven el interior de nuestros paquetes, si no que miran slo el equivalente al sobre para saber dnde mandarlos, como veremos ms adelante.
3.2. La capa TCP (Transmission Control Protocol = Protocolo de Control de Transmisin) : La necesidad de las conexiones para tener una comunicacin fiable
Volvamos ahora al escenario del hospital. En esta ocasin, el doctor PyC recibe un aviso de urgencia a travs del servicio de megafona del hospital.
Pgina 39
Pero, qu ocurrira si el doctor PyC no estuviese en ese momento en el hospital? Y si estuviese en esos momentos escuchando msica y no oyese el aviso? Cuando se lanza un aviso por megafona se tiene cierta confianza en que el mensaje llegar a su destinatario, pero en realidad no se puede tener nunca esa certeza. Sueltas el mensaje al vaco, y no tienes forma de saber si al otro lado hay alguien escuchando. Esto es lo que se llama una comunicacin no orientada a conexin. Esta solucin en muchos casos no es aceptable, pero en muchos otros s que puede ser suficiente. Por ejemplo, en el caso de la megafona del hospital, si el doctor PyC no ha acudido al aviso en un cierto tiempo, probablemente se le volver a llamar. Existen otros casos de comunicacin no orientada a conexin en los que directamente enviamos el mensaje con la esperanza de que llegue pero, si no llega, nos aguantamos y, a otra cosa, mariposa. Un ejemplo es el del envo de postales navideas. T mandas un porrn, y si llegan o no a su destino es algo que en muchos casos nunca sabrs pero, lo que sin duda si que sabes, es que ni por asomo te vas a poner a reenviarlas por si acaso no han llegado. Como en algunos casos la comunicacin no orientada a conexin es suficiente, en las mquinas tambin es utilizada para algunos casos concretos. Cuando no necesitamos saber si nuestro interlocutor nos est escuchando, no necesitaremos utilizar un protocolo de transporte fiable, como es TCP, si no que nos bastar con utilizar un protocolo no orientado a conexin, que tambin os sonar bastante, y es el UDP (Protocolo de Datagramas de Usuario). Por tanto, UDP es tambin un protocolo de transporte e, igual que la mayora de aplicaciones de comunicaciones utilizan como apoyo TCP/IP, tambin hay varias aplicaciones que en lugar de eso utilizan como apoyo UDP/IP. Pgina 40
Os remito de nuevo al nmero 14 de la revista, donde vimos un ejemplo de protocolo apoyado en UDP/IP, que es el protocolo DNS. A lo largo del curso ya veremos en profundidad el protocolo de transporte UDP.
Comentario de Hack x Crack...
Para aquellas mentes inquietas, apuntaremos un detalle. El protocolo TCP podemos clasificarlo como pesado porque, al estar orientado a la conexin, consume muchos ms recursos de red, es decir, el proceso para establecer una comunicacin de este tipo est formada por muchos pasos. El protocolo UDP podemos considerarlo como ligero porque, al no estar orientado a la conexin, consume pocos recursos de red, es decir, el proceso tiene muy pocos pasos. El protocolo UDP es muy utilizado, por ejemplo, en la emisin de video por Internet o los programas de intercambio de archivos tipo eMule. Para que se entienda, en la transmisin de video en tiempo real por Internet (por ejemplo), lo que interesa es que al receptor le llegue la mxima informacin posible en el menor espacio de tiempo posible, no importa si se pierden unos cuantos frames de pelcula por el camino (es imperceptible), lo importante es que la pelcula no se pare y se pueda ver fluida en tiempo real. Sera absurdo que si el frame 7 no llega, se parase la pelcula, pidisemos de nuevo al emisor el frame 7, espersemos su llegada, la comprobsemos y volvisemos a activar la pelcula. Si pensamos que llegan entre 15 y 30 frames por segundo, bufff, estaramos parando la pelcula cada dos por tres es mejor despreciar ese frame que no ha llegado y seguir con la peli :) En el caso de los programas de intercambio de archivos tipo P2P (como el eMule, http://www.emule-project.net/), el tema se complica un poquito, pero solo un poquito. Si estamos descargando un programa llamado officexp.zip (de 650MB) desde 7 usuarios a la vez, este nos llega en trocitos pequeos. Lo importante es que nos lleguen cuanto ms trocitos mejor y en el menor espacio de tiempo. Pero claro, tambin es importante que no perdamos ningn trocito (o despus el ZIP nos dar errores).
PC PASO A PASO N 17
En este caso, podramos pensar que es mejor utilizar TCP, puesto que nos asegura que llegan todos los trocitos; pero entonces estaramos sobrecargando la red P2P con centenares de peticiones de comprobacin y la descarga sera muy lenta. Cmo resolvemos esto? Pues trabajamos con UDP y hacemos que sea el programa P2P quien compruebe si faltan trocitos. En caso de faltar algn trozo se reclama y en caso de no faltar no se reclama.
DOCTOR en un sistema UDP en un mundo P2P :) El doctor (receptor) recibe por megafona un mensaje (archivo) PERO el tipo del megfono (emisor) es MUY DESPREOCUPADO y no le importa si el doctor (receptor) recibe o no el mensaje. El mensaje (archivo) a transmitir es: PRESNTESE INMEDIATAMENTE EN EL QUIRFANO. 1.- El tipo del megfono (emisor) emite la primera palabra (primera parte del archivo): PRESNTESE 2.- El doctor (receptor) en teora recibe la primera palabra (primera parte del archivo): PRESNTESE 3.- El tipo del megfono (emisor) emite la segunda palabra (segunda parte del archivo): INMEDIATAMENTE 4.- El doctor (receptor) en teora recibe la segunda palabra (segunda parte del archivo): INMEDIATAMENTE 5.- Seguiramos as hasta que el doctor (receptor) en teora recibiese la ltima palabra (ltimo trozo del archivo). En ese momento el doctor (receptor) unira todas las palabras (trozos de archivo) obteniendo el mensaje completo (archivo). Como podemos ver, la comunicacin es mucho ms rpida (nos ahorramos las confirmaciones) pero y si el doctor se ha perdido alguna palabra?... quizs se ha perdido la palabra INMEDIATAMENTE si el doctor estaba tomndose un caf quiz prefiere acabrselo antes de acudir al quirfano (y seguro que su paciente muere desangrado). En el caso de emisin de video por Internet en tiempo real ya hemos dicho que no nos importaba perder unos cuantos frames, pero en el caso del P2P QUEREMOS TODOS los trocitos de archivo, queremos que el doctor no deje morir a su paciente Cmo lo solucionamos si no queremos utilizar el sistema TCP? Tenemos un problema: No queremos sobrecargar la red telefnica del hospital confirmando cada palabra que recibimos (TCP) pero queremos asegurarnos de recibir los mensajes completitos. Muy bien, pues en este caso tendremos que dotar a los intervinientes (el Sr. del megfono y el doctor) de un poquito de inteligencia :) El Sr. del megfono (software emisor) y el doctor (software receptor) se renen y despus de un buen rato discutiendo el problema llegan a una solucin. Deciden utilizar el sistema UDP
PARALELISMO: Por si alguien no lo ha pillado, retomemos el caso del doctor y hagamos un paralelismo con el mundo P2P. DOCTOR en un sistema TCP en un mundo P2P :) El doctor (receptor) recibe por megafona un mensaje (archivo) PERO el tipo del megfono (emisor) es MUY EXIGENTE y OBLIGA al doctor (receptor) que confirme la correcta recepcin de cada palabra (parte del archivo) que recibe. El mensaje (archivo) a transmitir es: PRESNTESE INMEDIATAMENTE EN EL QUIRFANO. 1.- El tipo del megfono (emisor) emite la primera palabra (primera parte del archivo): PRESNTESE 2.- El pobre doctor (receptor) va corriendo a un telfono, llama al tipo del megfono y le dice que ha recibido correctamente la palabra (trozo de archivo): PRESENTESE 3.- El tipo del megfono (emisor) emite la segunda palabra (segunda parte del archivo): INMEDIATAMENTE 4.- El pobre doctor (receptor) va corriendo a un telfono, llama al tipo del megfono y le dice que ha recibido correctamente la p a l a b r a ( t ro z o d e a rc h i v o ) : I N M E D I ATA M E N T E 5.- Y as seguiremos hasta que el doctor (receptor) confirma la llegada de la ltima palabra (trozo de archivo) QUIRFANO. En ese momento el doctor (receptor) une todas las palabras (trozos de archivo) y obtiene el mensaje (archivo): PRESNTESE INMEDIATAMENTE EN EL QUIRFANO. Como podemos ver, la comunicacin es 100% segura, el doctor confirma la llegada de cada palabra (trozo de archivo); pero han invertido mucho tiempo y muchas llamaditas de confirmacin.
PC PASO A PASO N 17
Pgina 41
pero cada palabra (trozo de archivo) emitida tendr estar precedida de un nmero correlativo (nmero de control). Vamos a verlo. DOCTOR en un sistema UDP en un mundo P2P (con control aadido). El doctor (receptor) recibe por megafona un mensaje (archivo) con un sistema previamente pactado :) El mensaje (archivo) a transmitir es: PRESNTESE INMEDIATAMENTE EN EL QUIRFANO. Segn han pactado, el mensaje a transmitir ser: UNOPRESNTESE DOSINMEDIATAMENTE TRESEN CUATROEL CINCOQUIRFANO. 1.- El tipo del megfono (emisor) emite la primera palabra ( p r i m e r a p a r t e d e l a rc h i v o ) : U N O P R E S N T E S E 2.- El doctor (receptor) en teora recibe la primera palabra ( p r i m e r a p a r t e d e l a rc h i v o ) : U N O P R E S N T E S E 3.- El tipo del megfono (emisor) emite la segunda palabra (segunda parte del archivo): DOSINMEDIATAMENTE 4.- El doctor (receptor) en teora recibe la segunda palabra (segunda parte del archivo): DOSINMEDIATAMENTE 5.- Seguiramos as hasta que el doctor (receptor) en teora recibiese la ltima palabra (ltimo trozo del archivo). En ese momento el doctor (receptor/software receptor) comprobara que tiene en su poder las palabras (trozos de archivo) y que no falta ninguna (se puede comprobar gracias a que tienen nmeros correlativos). Solo en caso de que faltase alguna palabra (trozo de archivo) el doctor llamara por telfono al emisor pidindole UNICAMENTE la palabra que le falta. Como podemos ver, ahora la conexin sigue siendo del tipo UDP (cargamos poco la red); pero gracias a que hemos dotado al Sr. del megfono y al doctor (software emisor y receptor) de inteligencia (software), hemos conseguido adems bastante seguridad en la comunicacin. ACABANDO Y PUNTUALIZANDO: Acabamos de aprender algo importantsimo que ya nunca Pgina 42
deberamos poder olvidar. Una cosa es el tipo de protocolo que estamos utilizando para nuestras conexiones (TCP o UDP e incluso ambos a la vez) y sus consecuencias sobre la red y, OTRA MUY DISTINTA, cmo programamos el software para mejorar el rendimiento de dichas conexiones. Hemos visto que las carencias de seguridad del protocolo UDP (capa de transporte) han sido "salvadas" gracias a cmo hemos programado el software (nivel de aplicacin). PARA LOS QUISQUILLOSOS: - Si, pero y si el doctor (software receptor) no recibe ninguna palabra (trocito de archivo) porque est dormido? Pues entonces dotamos de un poco ms de inteligencia al programa para que la primera palabra (trocito de archivo) se haga por TCP (confirmacion aobligatoria) y el resto por UDP. De esta forma no se emitirn mas palabras (trocitos de archivo) por megafona hasta que el doctor llame al Sr. del megfono confirmando que la recibido la primera palabra. - Si, pero y si el doctor (software receptor) no confirma la recepcin de esa primera palabra (trocito de archivo)? Pues hacemos que el Sr. de megafona (software emisor) enve un mensaje al telfono mvil del doctor cada 5 minutos durante 2 horas hasta que conteste. Y si a pesar de todo no contesta? Pues llamamos a otro doctor mientras el primero est dormido (en un P2P sera el equivalente a servir el archivo a otro cliente mientras el primero pasa a una lista de espera :) La intencin de esta extensa nota no es otra que ACERCAR ese extrao mundo de las capas OSI a la realidad, a programas que utilizamos diariamente y que no tenemos ni idea de cmo funcionan (por ejemplo la visualizacin de video en tiempo real y los P2P). Quizs ahora pensemos un poco ms en lo que hay detrs de esas cosas que utilizamos mecnicamente sin pensar :)
Olvidndonos ya de UDP, vamos a ver entonces qu es TCP, que es el que ms nos interesa. A diferencia de las comunicaciones no orientadas a conexin, las orientadas a conexin son aquellas en las cuales hay un dilogo directo con el interlocutor. Es decir, no es ningn monlogo que sueltas con la esperanza de que alguien te escuche, si no que es una conversacin entre dos o ms PC PASO A PASO N 17
interlocutores, donde todos saben en todo momento si estn siendo escuchados por los dems. Como ejemplo de comunicacin orientada a conexin tenemos el telfono, donde en todo momento sabes si la persona con la que ests hablando est siguiendo el dilogo. Por el contrario, cuando hablas con un contestador automtico telefnico, se trata precisamente de una comunicacin no orientada a conexin.
necesitars saber que tu servidor de correo lo est recibiendo (aunque si llega al buzn del destinatario o no es ya un asunto aparte), si ests en un Chat necesitas saber que la persona o personas con las que hablas estn conectadas en ese momento, y leyndote. Hasta donde la capa IP entiende, slo existen sobres que circulan desde una direccin de remitente hacia una direccin de destinatario, pero en ningn momento existe un dilogo entre remitentes y destinatarios. Es en la capa TCP donde aparece este nuevo concepto, que engloba l o s s o b r e s q u e p a ra I P c i r c u l a n p o r separado, en un nico flujo de dilogo entre las dos partes. En el caso de TCP, existen unos sobres especiales que lo nico que hacen es decir te estoy escuchando. Cada vez que un remitente enve un sobre a un destinatario, ste responder con un nuevo sobre, en el que simplemente dir te he escuchado. Gracias a este mecanismo, se puede saber en todo momento si estamos hablando solos, o estamos en un dilogo.
Al hablar por telfono mantenemos una conversacin orientada a conexin, donde ambas partes saben que el otro est escuchando.
3.3. La capa TCP: El tamao de los paquetes.

Pero, ahora que sabemos que el protocolo TCP exige a los destinatarios que constantemente confirmen que han recibido lo que se les enviaba, qu ocurre si en algn momento no se recibe esa confirmacin? Pues el remitente, transcurrido un tiempo en el que no haya recibido confirmacin, tendr que reenviar el paquete y esperar de nuevo la confirmacin, como en el ejemplo de la megafona del hospital. Pero, qu ocurre entonces si el mensaje de megafona era muy largo? Imaginemos que, en lugar de decir: Doctor PyC, acuda a la sala de ciruga cardiovascular, el Pgina 43
Al hablar con un contestador telefnico mantenemos una conversacin no orientada a conexin, pues no sabemos si la otra parte llegar a escuchar nuestro mensaje.
La mayora de servicios de comunicacin entre mquinas requieren una comunicacin orientada a conexin. Por ejemplo, si estas transfiriendo un fichero, normalmente necesitars saber que ste est siendo recibido, si ests enviando un e-mail PC PASO A PASO N 17
mensaje dijese: Doctor PyC, acuda a la sala de ciruga cardiovascular para atender una urgencia de cardiopata precartida en un paciente varn de 70 aos, diabtico, de grupo sanguneo AB+, y cuyo color preferido es el fucsia. Si el Doctor PyC no respondiese a la primera llamada, habra que repetir toda la parrafada de nuevo. No tiene sentido soltar parrafadas muy largas si no tienes la certeza de que ests siendo escuchado. Por eso, si lo que tienes que transmitir es muy largo, lo mejor es que lo vayas contando poco a poco, y esperando la confirmacin de que cada parte ha sido escuchada. Cuando hablamos por telfono, normalmente no soltamos un rollo de varias horas sin parar (aunque los hay que si...), si no que estamos pendientes de que cada cierto tiempo nuestro sufrido interlocutor nos d las confirmaciones de rigor como si, si, o aja, o que te calles ya. Normalmente, si llevamos dos minutos seguidos hablando y no hemos escuchado un aja de nuestro interlocutor, nos mosqueamos bastante, y decimos oye, sigues ah?. En resumen, lo natural a la hora de transmitir mucha informacin es hacerlo en pequeos trozos, cada uno de los cuales confirmar su recepcin por separado. Lo mismo ocurre en la comunicacin entre mquinas. Como TCP se encarga de enviar confirmaciones, es tambin el que se encarga de partir los paquetes muy grandes en paquetes ms pequeos para que estas confirmaciones puedan llegar poco a poco, y no tener que retransmitir todo si no llegase la confirmacin.
Esto nos permite, adems, adaptarnos a la capacidad de nuestro interlocutor. Por ejemplo, si nos suscribisemos a una enciclopedia por fascculos, y nos enviasen toda la coleccin de golpe, probablemente el cartero mandara al garete a los tos de Espasa, y les dira que los 20 volmenes los iba a llevar hasta all su simptica abuela.
Los buzones de correos tienen un tamao limitado y, si bien cada fascculo por separado cabe perfectamente en el buzn, la coleccin entera no cabra en ningn buzn. Lo mismo ocurre con las mquinas, que tienen un buzn de recepcin de un tamao limitado, y hemos de ajustarnos a esas limitaciones tecnolgicas.
3.4. La capa TCP: Las conexiones simultneas

Una de las principales funciones de la capa TCP es la de permitir que existan varios dilogos simultneos entre dos interlocutores. Aqu no recurrir a ms metforas, si no que ser ms sencillo verlo directamente en nuestro campo de trabajo. Si, por ejemplo, est PyC en MSN chateando con Scherzo, y a la vez le est enviando un archivo, no estarn manteniendo dos dilogos simultneos? Por un lado, estn chateando, y por otro lado estn enviando un archivo. Suponiendo que un Chat en MSN funcionase mediante una conexin punto a punto (que no es as, como sabris si habis ledo mi artculo sobre MSN, pero imaginaremos que s), habra una serie de paquetes cuyo remitente sera PyC y cuyo destinatario sera Scherzo, pero de esos paquetes algunos seran parte del archivo que se est transfiriendo (que, por supuesto, estara partido en trozos, tal y como vimos en el punto anterior), y otros seran parte de la conversacin que mantienen PyC y Scherzo a travs del Chat. Para permitir que esto ocurra, el protocolo de transporte, TCP, tiene que tener algn sistema que identifique qu paquetes son del Chat, y qu paquetes son del archivo. Esto lo hace asignando un nmero a cada dilogo simultneo y, segn el nmero que haya en cada paquete, sabr si ste forma parte del archivo, o del Chat.
Pues estos nmeros mgicos de los que estoy hablando no son otros que los archiconocidos PUERTOS .
Pgina 44
PC PASO A PASO N 17
Un puerto es un campo del protocolo TCP que permite identificar el servicio al que va destinado cada paquete en una conexin entre dos mquinas. As, cada vez que una mquina reciba un paquete con el nmero de puerto 25, sabr que ese paquete es un e-mail, cada vez que reciba un paquete con el nmero de puerto 21, sabr que ese paquete es un comando de FTP, cada vez que reciba un paquete con el nmero de puerto 80 sabr que es una conexin Web, etc., etc.
4. Ejemplo: Enviando un archivo.

Para recapitular todas las ideas mostradas a lo largo del artculo, termino con un ejemplo bastante completo que muestra paso a paso el envo de un archivo de PyC a Scherzo. Estad muy atentos a cada paso, porque espero que este ejemplo os ayude a comprender mucho mejor todos los conceptos que necesitareis para seguir el resto del curso. Fijad tambin vuestra atencin en todas las ilustraciones, pues muestran grficamente toda la secuencia del ejemplo, y adems los datos que aparezcan en las propias ilustraciones son tambin fundamentales. A lo largo de la serie RAW os he explicado ya varios sistemas de transferencia de archivos (FTP, DCC, MSN,...). En este ejemplo usaremos, por ejemplo, una transferencia por FTP. Antes de nada, vamos a ver cmo sera el proceso si slo nos fijsemos en la capa de arriba, es decir, en la capa sobre la que he ido hablando mes tras mes en la serie RAW. 1. PyC abre su servidor FTP: pone un puerto en escucha, gracias a una funcin que da el sistema operativo que permite a cualquier aplicacin realizar estas y otras funciones de TCP/IP. 2. Scherzo abre una conexin con el servidor FTP de PyC: el modo en que PC PASO A PASO N 17
se abre esta conexin lo detallaremos a lo largo del curso, pero no en este artculo. De momento lo que s que sabemos es que la responsable de abrir y mantener las conexiones es la capa TCP. 3. Scherzo escoge el archivo que quiere bajar : comandos CWD, CDUP, LIST,... todo esto ya lo vimos en los artculos sobre FTP de la serie RAW, y ahora no nos interesa mucho. 4. Scherzo inicia la transferencia del archivo: comandos PORT o PASV, y RETR o REST. Tambin lo vimos en los artculos de la serie RAW, y tampoco nos interesa ahora. 5. El archivo se transfiere desde el servidor de PyC hacia el cliente de Scherzo: Aqu unos enanitos se encargan de llevar el archivo de una mquina a otra, cargando los datos en sacos que llevan a la espalda. Pero... espera! Si esto no es la serie RAW! En la serie RAW no me quedaba ms remedio que deciros estas cosas, porque al llegar a este punto no poda daros ms detalles, ya que ms de una vez os mencion que explicar lo que ocurre en estos momentos sera suficiente para llenar no slo un artculo, si no una serie entera. Y al fin ha llegado esa serie! As que esperad unas cuantas lneas, que enseguida os explico cmo funcionan las cosas realmente. Tampoco quiero chafar la ilusin a nadie, as que si alguien no quiere dejar de creer en los enanitos que transportan paquetes de datos, que no siga leyendo! ;-) 6. Finaliza la transferencia del archivo: y a otra cosa, mariposa. Para qu os he mostrado todos estos pasos que conocis ya perfectamente (sobre todo si habis seguido la serie RAW)? Pues sencillamente, para que veis que entre los pasos 5 y 6 ocurren una gran cantidad de cosas que siempre hemos obviado, y que sern las que precisamente detalle en este ejemplo. Nos olvidaremos, por tanto, del resto de pasos, y nos centraremos nicamente en lo que ocurre Pgina 45
desde que comienza la transferencia del archivo, hasta que sta finaliza. Algunos conceptos los simplificar mucho, y otros incluso los obviar, esperando as facilitar la comprensin de los conceptos fundamentales, aunque tenga que sacrificar parte de la verdad.
operativo dicindole ale, ya est transmitido el archivo, o bien cualquier error que haya podido ocurrir oye, no he podido enviarlo porque el usuario se ha desconectado, etc. Como esto es todo lo que ve el programa de FTP, tendremos que descender al oscuro reino del sistema operativo para comprender mejor qu es lo que ocurre desde que se llama a esa funcin hasta que el sistema operativo avisa de que el envo ha finalizado.
4.1.
En el servidor FTP de PyC
Empezamos nuestro viaje por el mundo de los enanitos en el reino que nosotros conocemos, que es el del servidor FTP de PyC. El servidor lo nico que sabe es que tiene un archivo de 4500 KB que tiene que enviar al usuario Scherzo, que previamente hizo un login en el servidor. El que program el servidor FTP no tena ni idea de TCP/IP, as que lo nico que saba era que el no tena ms que dar una orden al sistema operativo, y ste se encargara de hacer todo el trabajo sucio. As que el software del servidor simplemente llama a una funcin mgica del sistema operativo, parecida a esta: EnviaFichero (fichero.doc, usuario) Donde fichero.doc es el nombre del archivo que quiere enviar, y usuario es una variable que contiene un nmero que identifica al usuario Scherzo. El valor de esa variable usuario no lo asign el programa de FTP, si no que lo hizo el propio sistema operativo en el momento en que Scherzo se conect al servidor. Como es el sistema operativo el que maneja estos nmeros mgicos que identifican a las conexiones (que, como veremos a lo largo del curso, se llaman sockets), el programa de FTP podr pasarle este dato al sistema, y ste ya sabr perfectamente lo que hacer con l. Una vez que el programa FTP llama a esta funcin mgica del sistema operativo, lo prximo que ver ser la respuesta del sistema Pgina 46
4.2. En el Sistema Operativo de PyC: La capa TCP.

Lo primero que hace la capa TCP nada ms ver el archivo de 4500KB es decir: buf, este chorizo es demasiado largo. Qu criterio utiliza TCP para decidir si algo es demasiado largo? Es algo que veremos a lo largo del curso, pero de momento nos basta con saber que el tamao mximo de un paquete es algo que determin previamente la capa TCP segn las limitaciones de la red. Supongamos que ha determinado que el tamao mximo de paquete son 1500KB. Tendr que coger el archivo y partirlo en tres trozos, cada uno de 1500KB.
A cada trozo le asigna un nmero que determina la secuencia en la que han de unirse de nuevo los trozos. A este nmero se le llama precisamente nmero de secuencia. Una peculiaridad del nmero de secuencia es que no se numera segn el nmero de trozo, PC PASO A PASO N 17
si no segn el nmero de byte del archivo en el que empieza ese trozo. As, el primer trozo tendr un nmero de secuencia 0, el segundo un nmero de secuencia 1500, y el tercero un nmero de secuencia 3000. Pero, es ste el nico dato que ha de asignar la capa TCP a cada trozo? Pues me temo que n o, ya q u e s a b e m o s b i e n q u e l a s responsabilidades de esta capa van ms all de simplemente partir los paquetes en bloques. Hablamos tambin de los nmeros de puerto, as que tendr que aadir a cada trozo los dos puertos implicados en la conexin. Adivinis cules son estos puertos? Je, je... era una pregunta con trampa. Si habis pensado que uno de los puertos era el 21, puerto asignado al servicio FTP, os habis equivocado, aunque he de reconocer que lo he preguntado a mala leche. 0:-) Si repasis mejor el artculo de la serie RAW sobre FTP veris que el puerto 21 slo se utiliza para enviar comandos al servidor, pero no para la transferencia de archivos. Para sta se utiliza otro puerto que es acordado previamente mediante el comando PORT o el comando PASV. Para los que no sepis de qu hablo porque no conocis el protocolo FTP, olvidaos de todo esto y quedaos simplemente con la idea de que tanto el puerto de PyC (origen) como el puerto de Scherzo (destino) son nmeros que han acordado previamente, por ejemplo, el 20 y el 3600. Por tanto, si aadimos a cada trozo los tres numerajos que hemos dicho (numero de secuencia, puerto de origen, y puerto de destino) nos queda el siguiente escenario:
La capa TCP ya ha terminado su trabajo inicial, y de momento se puede relajar un poco mandando los bloques a la capa IP, que sabr qu hacer con ellos a continuacin. Pero, a diferencia del programa de FTP, la capa TCP no se puede dormir en los laureles esperando a que la transferencia del archivo termine, si no que tendr que seguir trabajando ms adelante, tal y como iremos viendo.
4.3. En el sistema operativo de PyC: La capa IP.

En cuanto TCP llama a la capa IP, y le pasa los 3 bloques, sta se pone en marcha. Su labor principal consiste en aadir a cada bloque las direcciones IP de PyC y Scherzo para que, una vez que los bloques estn flotando por el ciberespacio, todos aquellos mediadores por los que pasen sepan dnde llevarlos. La direccin IP de PyC la conoce, por supuesto, el propio sistema operativo de PyC (bien porque la introdujimos nosotros manualmente al configurar nuestra LAN, bien porque el sistema la asign automticamente mediante DHCP, o bien porque se nos asign una IP dinmica al conectar con nuestro ISP). La direccin IP de Scherzo la puede obtener el sistema a partir de la variable usuario ya que, cuando Scherzo conect con el programa FTP, el sistema operativo automticamente asoci la IP de Scherzo a esa variable. Tiene que aadir algo ms la capa IP? Pues si! Vamos a ver. Para qu serva en la capa TCP meter los nmeros de puerto en cada bloque? Si no metisemos los nmeros de puerto, cuando el bloque llegase al destinatario (Scherzo) ste no sabra qu hacer con l. Scherzo probablemente tendra abiertas en ese momento varias aplicaciones de comunicaciones, y cada paquete que le llegase tendra que indicar de algn modo a cul de todas esas aplicaciones iba dirigido. Pues algo parecido ocurre con la capa IP. Como ya vimos, no slo existe TCP como protocolo Pgina 47
Los tres paquetes que forman el archivo, con sus correspondientes cabeceras TCP. Fijaos bien en los campos que forman la cabecera.
PC PASO A PASO N 17
de transporte, si no tambin otros como UDP. Adems, existen otra serie de protocolos que funcionan sobre IP, como ICMP, pero de eso no vamos a hablar ahora. Lo que ahora nos interesa es que de alguna manera el bloque tiene que decir de alguna forma que es un bloque TCP, y no UDP. Para ello, la capa IP asigna mete un numerajo en cada bloque que identifica el protocolo de transporte desde el que le lleg ese bloque.
4.4. En el sistema operativo de PyC: la capa de enlace.

Hasta el momento hemos hablado poco de esta capa para evitar liaros ms. Si bien las capas TCP e IP son iguales para todos los sistemas, la capa de enlace puede variar totalmente de un sistema a otro. Es aqu donde se encuentran las diferencias entre una conexin por mdem, una conexin ADSL, y cualquier otro tipo de conexin. Es decir, la capa de enlace depende de la tecnologa utilizada para crear el enlace entre nuestra mquina e Internet. Vamos a suponer que el enlace que tiene PyC es el ms comn hoy da, es decir, un enlace Ethernet. ste es el que usamos si tenemos una tarjeta de red (bien con ADSL, o con cable, o con otras tecnologas). Supongamos que PyC tiene en su casa una configuracin muy habitual hoy da, que es la de una conexin a Internet a travs de un router ADSL, con una pequea LAN (red local) en casa compuesta por dos ordenadores: el suyo, y el de su hermano.
Como, en este caso, los bloques le llegaron a IP desde la capa TCP, la capa IP meter en cada bloque un nmero que dir que se es un bloque TCP. Por tanto, as nos queda el escenario ahora:
Los tres paquetes que forman el archivo, con sus cabeceras TCP e IP. Como podis observar, la cabecera IP es igual para los tres paquetes.
Una vez que los paquetes ya estn listos, se los manda a la capa de abajo, la capa de enlace, de la que hemos hablado poco hasta el momento. Pgina 48
Esquema de la LAN de PyC, con las IPs de cada elemento. El router ADSL tiene 2 IPs: 192.168.1.1 para la LAN, y 217.15.22.1 de cara a Internet.
PC PASO A PASO N 17
Como vemos en la ilustracin, la nica mquina que se comunica directamente con Internet es el router ADSL, y es ste el que tiene que encargarse de llevar todos los paquetes de PyC y de su hermano a Internet. Para ello, ambos ordenadores estn conectados al router mediante un cable de red (si el router slo tiene un conector RJ-45 tendra que haber en medio un switch, pero esa cuestin la obviamos por salirse del tema). El problema aqu es que la comunicacin en Ethernet es de tipo broadcast. Esto significa que lo que circula por el cable llega a todas las mquinas que estn conectadas al mismo, y hay que idear alguna forma de hacer que slo atienda a los datos la mquina interesada. Este es precisamente el motivo por el que funciona un sniffer en una red local. Todos los datos de la red local circulan por el cable al que se conecta tu tarjeta de red, y slo hay que engaar a la tarjeta de red para que te muestre todos los datos que hay en el cable, y no slo los que van dirigidos a ella. Pero lo que nos interesa aqu es conocer el mecanismo utilizado para distinguir unas mquinas de otras en una LAN. Como podis imaginar, esto se consigue asignando un nmero diferente a cada tarjeta de red de las mquinas conectadas a la LAN. Este nmero es nico en el mundo para cada tarjeta de red. Los fabricantes de dispositivos Ethernet tienen un acuerdo para que nunca se fabriquen dos tarjetas de red con el mismo nmero. Este nmero mgico es precisamente la famosa direccin MAC (comnmente conocida como direccin fsica) de la que probablemente habris odo hablar. Al haber una MAC diferente por cada dispositivo Ethernet del mundo, las direcciones MAC tienen que ser lo suficientemente grandes PC PASO A PASO N 17
como para que nunca tengan que repetirse. Estas direcciones, ms largas que las direcciones IP, constan de 48 bits, por lo que tericamente permiten identificar casi 300 Billones de dispositivos Ethernet diferentes. Entonces, qu datos aadir el nivel Ethernet a cada bloque que queremos transmitir? Pues, al igual que la capa IP, aadir una direccin MAC de origen, y una direccin MAC de destino. Y, tambin igual que en la capa IP, tendr que aadir un dato ms, que es un identificador de la capa superior que le pas los bloques, es decir, en este caso la capa IP.
Los tres paquetes que forman el archivo, con sus cabeceras TCP, IP, y Ethernet. En sta la MAC de origen ser la de PyC, y la MAC de destino la del router ADSL de PyC, que ser el prximo punto con el que habr que enlazar la comunicacin. El ordenador de PyC conoce la direccin MAC del router gracias al protocolo ARP, pero eso se sale del tema del artculo.
No sabes...
No sabes la MAC de tu tarjeta de Red? de verdad?... bueno, bueno tendras que haber ledo los anteriores nmeros de esta revista :) Abre una ventana de comandos (Men inicio --> Todos los Programas --> Accesorios --> Smbolo del sistema). Escribe IPCONFIG /ALL. Pulsa enter y ZAS!!! Ah tienes la MAC de tu/s tarjetas Ethernet (Tarjetas de Red).
Pgina 49
El primer paquete al fin sale del ordenador de PyC, hacia el router ADSL.
4.6. En el router ADSL de PyC: Las capas fsica y de enlace

En este caso podemos ver 2 tarjetas de red y cada una tiene una MAC (direccin fsica). La tarjeta D-Link AirPlus tiene la MAC 00-80-C8-1E-4F-0C y la Realtek tiene la MAC 00-05-1C-9A-84-B1 Como apunte interesante, aclarar que aunque la MAC es nica en el mundo, existen Tarjetas de Red especiales y otros dispositivos (como algunos routers) que permiten "falsear" la MAC (poner la MAC que tu quieras ;). La mayora de tcnicos de Red tienen entre sus "herramientas de trabajo" una de estas tarjetas para comprobar el buen funcionamiento de los Sistema de Red.
Una vez que los datos llegan al router, ste detectar mediante hardware la presencia de datos en el cable, y enviar los bloques recibidos a su capa de nivel de enlace. Aqu es importante tener en cuenta que el nivel de enlace del router debe ser tambin Ethernet. De no ser as, la comunicacin entre PyC y su router sera imposible. Por tanto, una vez que los datos llegan a la capa Ethernet del router, ste analiza la cabecera Ethernet del paquete. Al analizar la cabecera, descubre que la direccin MAC de destino era la suya, por lo que decide continuar el procesamiento del paquete, ya que le corresponde a l hacerlo. Para poder continuar el procesamiento debe saber a qu capa pasarle la pelota. Para ello analiza la cabecera Ethernet del paquete y descubre la capa de encima tiene que ser la capa IP. As, el router elimina la cabecera Ethernet del paquete (ya que la capa IP es incapaz de comprenderla), y pasa el resto del paquete a la capa IP.
4.5. En la tarjeta de red de PyC: La capa fsica

Una vez que el nivel de enlace ya ha hecho lo que tena que hacer con los bloques, no tiene ms que acceder ya directamente al hardware, en este caso la tarjeta de red, y los datos salen al fin de la mquina de PyC. Por supuesto, existen muchas tecnologas diferentes en la capa fsica: RJ-45 (la que casi todos tenemos), coaxial, inalmbricas (muy de moda ltimamente), etc., etc. Una vez lanzados los paquetes a travs del cable que une la mquina de PyC con el router ADSL estos, por supuesto, llegarn hasta el router.
El router analiza la cabecera Ethernet, comprobando que la MAC de destino es la suya, y pasa el resto del paquete (sin la cabecera Ethernet) a la capa IP.
PC PASO A PASO N 17
Pgina 50
4.7. En el router ADSL de PyC: La capa IP

Una vez que la capa IP recibe el paquete, analiza su cabecera. Ah encuentra la direccin IP de destino, que es la de Scherzo. El router tiene configurada internamente una tabla parecida a esta:
Esto es debido a que la conexin entre el router ADSL y el router del ISP no es mediante un enlace Ethernet, si no mediante una tecnologa de enlace ADSL. No vamos a detallar aqu ms capas de enlace, o buen barullo montaramos, as que nos imaginaremos que esta capa aadir sus propias direcciones y su identificador de la capa superior, y enviar el paquete a la capa fsica, que esta vez no ser el cable Ethernet, si no el cable telefnico que va hacia el splitter.
Lo que vemos en esta tabla es que el router ADSL enviar al router de su ISP cualquier paquete que tenga como IP de destino una que no pertenezca a la LAN de PyC. Como la direccin IP de Scherzo no es una de las de la LAN de PyC, el paquete ser enviado al router del ISP de PyC. Una vez encontrado el siguiente mediador al que tiene que enviar el paquete, el trabajo del router ADSL termina aqu. No le interesa para nada lo que haya dentro del paquete, es decir, la cabecera TCP, y los datos del archivo que estamos enviando. Eso ya ser problema del PC de Scherzo cuando reciba el paquete. Lo nico que tiene que hacer ahora el router ADSL es devolver el paquete a la capa de enlace para que sta sepa qu hacer con l.
El paquete ya puede salir a Internet, una vez reconstruidas las cabeceras IP y de enlace. La cabecera TCP y los datos del archivo (zona azul del paquete) se han mantenido intactas.
4.9.
En el router del ISP de PyC
Una vez que el paquete llega al router del ISP, ste repetir el proceso de recoger el paquete, analizar desde la capa de enlace si va dirigido a l, pasarlo a la capa IP, mirar su tabla de encaminamiento interna, y decidir a qu mediador enviar el paquete a continuacin. Imaginemos que sta es una parte de la tabla de encaminamiento de este router:
En funcin de esta tabla, el router decidir enviar el paquete a otro router, cuya IP es 215.12.133.2. As, construir una nueva cabecera de enlace, y reenviar el paquete por el cable fsico adecuado.
El router modifica la cabecera IP, sustituyendo la IP de LAN de PyC por la IP pblica para que pueda salir ya al resto de la red Internet. Ya explicaremos esto mejor a lo largo del curso.
4.10. Flotando en el ciberespacio

Este proceso de saltar de un router a otro buscando un camino que llegue hasta Scherzo puede constar de muchos pasos. Si queris hacer la prueba vosotros mismos, tenis un comando en vuestro sistema que os permite ver por qu routers van pasando vuestros paquetes al enviarlos a un destino concreto. Pgina 51
4.8. En el router adsl de PyC: De nuevo en la capa de enlace.

Pero... Sorpresa! Con quien ha contactado la capa IP del router no es con la capa Ethernet, si no con otra capa de enlace diferente!!
PC PASO A PASO N 17
Ya os explicar cmo funciona internamente este comando, pero de momento haced la prueba en una ventana MS-DOS (Ventana de Comandos), o una consola Linux: tracert www.google.com Cada lnea es uno de los routers que forman el camino entre vosotros y la Web de Google. En cada uno de estos routers se repetir todo el proceso de analizar el paquete hasta la capa IP, e ir relanzndolo por los distintos cables que forman la autntica telaraa de Internet.
IP de LAN y por su direccin MAC. El cmo sabe el router a qu mquina enviar el paquete se sale ya del tema que puedo abarcar por hoy, as que nos creeremos que sabe dirigir el paquete a su destino dentro de la LAN. Para ello, construye una nueva cabecera Ethernet (capa de enlace) que tiene como direccin MAC de destino la direccin MAC de Scherzo.
4.12. En el PC de Scherzo: la capa Ethernet.

Una vez que el paquete llega a Scherzo, su tarjeta de red empieza analizando la capa de enlace (Ethernet) y, al ver que la direccin MAC de destino es la suya, sabe que el paquete es para l. A continuacin, lee el campo de la cabecera Ethernet que le dice que la siguiente capa que tiene que analizar el paquete es la capa IP, y le pasa la pelota a esta capa del sistema operativo.
Cada router por el que pase el paquete analizar sus cabeceras de enlace e IP, para ir retransmitiendo el paquete a cada punto que forma el camino entre el origen y el destino.
Cuando, a lo largo del curso, hable sobre la capa TCP, veremos que los paquetes no siguen siempre el mismo camino, e incluso pueden llegar desordenados a su destino, pero de momento no vamos a entrar en tanto detalle, que me falta ya espacio. ;-)
Una vez analizada la cabecera Ethernet, se elimina, y se pasa el resto del paquete a la capa IP.
4.11. En el router ADSL de Scherzo

Al fin el paquete lleg hasta el ltimo router del camino! Este, por supuesto, es el router ADSL de Scherzo. ste analizar el paquete, y ver que en la capa IP tiene como direccin IP de destino la IP de Scherzo, as que ahora slo le falta saber a cul de los PCs de la LAN de Scherzo enviarlo. Todos los PCs de la LAN de Scherzo comparten una misma IP de cara a Internet, que es la IP del router, y ste los diferencia slo por su Pgina 52
4.13. En el sistema operativo de Scherzo: la capa IP

La capa IP de Scherzo analizar ahora no slo
la IP de destino (que es la de Scherzo), si no tambin la de origen (que es la de PyC), ya que tendr que enviar sus respuestas a esa direccin. Una vez que se queda con estos dos datos, manda el paquete a la capa superior que, segn la cabecera IP, es la capa TCP. En todos los saltos que ha ido dando el paquete de un router a otro, ninguno ha analizado su cabecera TCP, ya que esto es slo responsabilidad del destinatario final (Scherzo).
PC PASO A PASO N 17
primero de los tres trozos, habremos recibido hasta el byte 1500 del archivo. Por tanto, construimos una cabecera como esta:
Una vez analizada la cabecera IP, se elimina, y se pasa el resto del paquete a la capa TCP.
4.14. En el sistema operativo de Scherzo: la capa TCP

La capa TCP de Scherzo coger el paquete, y ver que no es un paquete completo, si no slo un trozo (recordemos que el archivo se parti en 3 trozos en la capa TCP de PyC). La capa TCP de Scherzo tiene ahora dos responsabilidades: responder a PyC dicindole que ha recibido el primer trozo, y mandar el paquete a la capa de arriba, es decir, a la aplicacin cliente de FTP, que ser la que sepa qu hacer con los datos contenidos en el paquete. Con respecto al segundo punto, poco hay que decir. Simplemente, se eliminar la cabecera TCP y lo que quedar ser un paquete de datos limpio y sin ninguna cabecera, que es lo que comprende la aplicacin de PyC. La capa TCP esperar a tener el resto de trozos del archivo para poder reconstruirlo en el orden adecuado gracias a los nmeros de secuencia. Con respecto al primer punto, la capa TCP de Scherzo tiene que avisar a PyC de que ha recibido el primer trozo, as que comienza la construccin de un paquete totalmente nuevo. Este paquete simplemente tendr un aviso del tipo oye, que te estoy escuchando, y he recibido ese paquete. Para ello, tiene una cabecera TCP especial que incluye, adems del aviso de que est escuchando, un dato que es el ltimo byte recibido del archivo. Como hemos recibido de momento slo el PC PASO A PASO N 17
El sistema de Scherzo construye un nuevo paquete para indicar a PyC que recibi el suyo. La cabecera TCP de este nuevo paquete constar de un campo ACK con el mismo valor que el nmero de secuencia del paquete al que quiere responder, e intercambiar los puertos de origen y de destino. El contenido del paquete (zona azul) estar vaco, ya que lo nico importante aqu son las cabeceras.
4.15. En el sistema operativo de Scherzo: de vuelta en la capa IP

Esta cabecera la pasaremos a la capa IP, que conoce la IP de PyC, por lo que construye una cabecera IP adecuada para ese paquete:
En la cabecera IP del nuevo paquete tambin se intercambian las IPs de origen y de destino.
4.16. Vamos pa atrs!

Y as contina el proceso, llevando el nuevo paquete de vuelta por el camino inverso al que sigui el paquete de PyC, hasta que el nuevo paquete llegue a PyC, ste analice su cabecera TCP, descubra que el primer paquete
que envi lleg con xito a su destino, y se despreocupe as ya al fin del paquete de marras. Normalmente, no esperar a que Scherzo le vaya avisando de que recibe cada paquete, si no que enviar varios de golpe y, slo si no recibe alguna de las respuestas, entonces reenviar aquel o aquellos de los que no ha recibido respuesta.
Pgina 53
Por tanto, es probable que para cuando PyC haya recibido la primera respuesta de Scherzo, ya haya enviado tambin los otros dos paquetes que forman el archivo, ante los cuales tambin esperar la respuesta de Scherzo.
4.17. Conseguido!
Una vez que Scherzo tiene ya los tres trozos del archivo, ya no tiene ms que unirlos en el orden adecuado, el cual conoce gracias al nmero de secuencia de cada trozo, reconstruyendo as el archivo original, y mandndolo a la aplicacin de FTP de Scherzo sin que sta tenga ni idea de cmo ha llegado hasta all ese archivo, confiando en que unos enanitos mgicos se habrn encargado del trabajo sucio. ;-)
PyC enva los tres paquetes y espera un tiempo razonable a que le llegue la respuesta (ACK) de Scherzo diciendo que ha recibido cada uno de los paquetes
Gracias al nmero de secuencia de cada paquete se puede reconstruir el archivo original, uniendo cada fragmento en el punto (posicin en bytes) indicado por el nmero de secuencia.
Autor: PyC (Lco)
Ilustraciones: Adhara (Lco)
PC PASO A PASO busca personas que posean conocimientos de informtica y deseen publicar sus trabajos. SABEMOS que muchas personas (quizs tu eres una de ellas) han creado textos y cursos para consumo propio o de unos pocos. SABEMOS que muchas personas tienen inquietudes periodsticas pero nunca se han atrevido a presentar sus trabajos a una editorial. SABEMOS que hay verdaderas obras de arte creadas por personas como tu o yo y que nunca vern la luz. PC PASO A PASO desea contactar contigo!
QUIERES COLABORAR CON PC PASO A PASO?
NOSOTROS PODEMOS PUBLICAR TU OBRA!!!

SI DESEAS MS INFORMACIN, envanos un mail a empleo@editotrans.com y te responderemos concretando nuestra oferta.
CURSO DE TCP/IP (2 Entrega)

EL PROTOCOLO DE TRANSPORTE
UDP
(PROTOCOLO DE DA T AGRAMAS DE USUARIO)
- Vamos a descubrir las herramientas necesarias para "crear" paquetes de red - Empezaremos a desgranar las capas de red - Trataremos el Protocolo de Datagramas de Usuario
1.
INTRODUCCIN
Espero que no os perdieseis el primer artculo del curso de TCP/IP (Transmisin Control Protocol / Internet Protocol --- Protocolo de Control de Transmisin / Protocolo de Internet), porque voy a asumir que habis comprendido a grandes rasgos el concepto de capas de protocolos, y el mecanismo bsico de transporte de paquetes de datos a travs de Internet (o cualquier otra red TCP/IP).
el protocolo UDP, pero en futuras lecciones exprimiremos al mximo las herramientas para hacer maravillas con las dems capas de protocolos: TCP, IP, ARP (Address Resolution Protocol --- Protocolo de Resolucin de Direcciones), etc. Empezar explicando a grandes rasgos el mecanismo de transporte de un paquete UDP a travs de Internet para luego detallar las cabeceras UDP y, por ltimo, veremos todo esto de forma prctica utilizando unas herramientas que nos permiten construir paquetes UDP desde cero (los llamados raw sockets). Pero, antes de empezar, he de aclararos un asunto. Supongo que algunos de vosotros os preguntareis qu ha pasado con la serie RAW. Mis intenciones no eran de ninguna manera sustituir la serie RAW por el curso de TCP/IP, si no desarrollar ambos en paralelo. Pero es increble de qu manera pueden conspirar juntas las circunstancias de la vida para cambiar por completo tu rumbo cuando menos te lo esperas. En poco ms de un mes me han surgido una serie de problemas de todo tipo (familiares, personales, de salud, laborales, y acadmicos) por los cuales ahora (y sin plazo definido) dispongo de muchsimo menos tiempo. He barajado un poco mis posibilidades, y creo que lo que puedo permitirme de momento es continuar slo con el curso de TCP/IP, aunque no descarto publicar algn otro artculo de la serie RAW algn mes que consiga juntar algo ms de tiempo. Con esto lo que os quiero PC PASO A PASO N 18
NOTA DE PC PASO A PASO / HXC
Para todos aquellos que no tienen la primera entrega del curso de TCP / IP publicada en el nmero 17 de PC PASO A PASO, hemos decidido pasarla a formato PDF y liberarla en la Web de la revista (www.hackxcrack.com). Tambin aprovechamos esta nota para indicar a nuestros lectores que todos los artculos liberados y los programas que mencionamos en los artculos estn disponibles en la seccin ARTCULOS LIBERADOS Y DESCARGAS de la Web.
Para esta primera leccin he escogido un protocolo muy sencillo, el protocolo UDP (User Datagram Protocol --- Protocolo de Datagramas de Usuario), para as poder extenderme ms en explicaros algunas herramientas que nos pueden ser tiles a lo largo de todo el curso. De momento, estas herramientas las utilizaremos para manejar Pgina 22
Curso de TCP/IP (2) - UDP - Curso de TCP/IP (2) - UDP - Curso de TCP/IP (2) - UDP
decir es que no os prometo nada con respecto a la serie RAW, pero que har lo que est en mi mano para que no termine aqu, aunque haya que avanzar ahora mucho ms despacio. Gracias por vuestra comprensin. ;-)
NOTA EDITORIAL
protocolo DNS. Vamos a utilizar este protocolo como ejemplo para ver qu ocurre desde que un cliente solicita una consulta DNS a un servidor, hasta que ste cliente recibe la respuesta pertinente. Os aconsejo que leis el artculo sobre DNS de la serie RAW, que se encuentra en el nmero 14 de la revista, aunque voy a empezar haciendo una introduccin sobre este protocolo.
Para los nuevos lectores, simplemente decir que la serie de artculos denominada SERIE RAW ha estado presente en casi todos los nmeros de esta publicacin y ha constituido uno de los pilares de la misma. La Serie RAW ya nos ha aportado conocimientos sobre los Protocolos ms importantes y desde hace mucho tiempo se nos ha reclamado el inicio de un curso de TCP / IP. Finalmente, desde el anterior nmero 17 por fin ese curso ha llegado. Tal y como nos describe el autor, esperamos poder hacer ms entregas de la Serie Raw en futuros nmeros, pero de forma ms dilatada en el tiempo. Mientras tanto disfrutemos de este excelente curso de TCP / IP, una serie de artculos ampliamente reclamada y esperada por nuestros lectores.
NOTA DE PC PASO A PASO / HXC:
El artculo SERIE RAW: DNS mencionado por el autor ha sido liberado y est disponible en nuestra Web: www.hackxcrack.com
2.1. LAS CAPAS DE UDP/IP

Os recuerdo que el protocolo DNS es el que nos permite utilizar las famosas URLs en lugar de direcciones IP. Es decir, nos permite escribir en nuestro navegador http://www.google.com en lugar de tener que escribir http://216.239.39.99, que es la direccin IP de Google. Para conseguir esto, existen repartidos por el mundo una serie de servidores encargados de traducir URLs a IPs, e IPs a URLs. Nuestros PCs se comunicarn con alguno de estos servidores cada vez que quieran utilizar una URL, para obtener as su IP correspondiente. Esta comunicacin se lleva a cabo a travs del protocolo DNS. Cuando escribimos en nuestro navegador una URL, por ejemplo http://neworder.box.sk, nuestro sistema enviar una consulta DNS a un servidor, indicando en la consulta el nombre que desea traducir (en este caso neworder.box.sk, ya que el prefijo http:// es slo una indicacin al navegador sobre el protocolo a utilizar, pero no forma parte del nombre que deseamos traducir).
2. FUNCIONAMIENTO DEL PROTOCOLO UDP

Los que os perdisteis la introduccin de este curso no tenis que preocuparos, ya que este primer punto resume en cierto modo lo que expliqu entonces. An as, os recomiendo que leis la introduccin, ya que aqu voy a resumir en un par de pginas lo que all explicaba en ms de 20 pginas. Para los que s que lesteis la introduccin, este punto creo que os puede ayudar a aclarar las ideas a modo de resumen. A lo largo de la serie RAW os expliqu varios protocolos que funcionaban sobre TCP, pero slo uno que funcionase sobre UDP: el PC PASO A PASO N 18
Pgina 23
En segundo lugar, sabiendo que en Internet todas las mquinas estn conectadas entre s mediante una compleja red de cables y conexiones inalmbricas, es lgico pensar que ser necesario conocer el camino a recorrer en toda esa maraa de cables para enlazar ambas mquinas entre s. En tercer lugar, el cliente necesitar conocer la direccin IP del servidor DNS, ya que slo conociendo la direccin IP de una mquina puedes acceder a ella a travs de Internet. En cuarto lugar, tiene que existir algn mecanismo que le indique al servidor que la consulta que le estamos haciendo es una consulta DNS, y no de cualquier otro tipo. Por ejemplo, el servidor DNS podra ser al mismo tiempo un servidor Web, y un servidor de correo electrnico. Por tanto, tiene que existir un mecanismo que le permita distinguir qu clientes solicitan servicios DNS, cules solicitan servicios Web, y cules solicitan servicios de correo eletrnico. A grandes rasgos, son cuatro los problemas que hemos encontrado para conseguir llevar a cabo esta comunicacin. Y, por supuesto, no es coincidencia que sean cuatro las capas de protocolos utilizadas en una comunicacin UDP: capa fsica, capa de enlace, capa de red, y capa de transporte. Si no fuese gracias a la existencia de estas 4 capas diferenciadas, el protocolo DNS debera encargarse por s slo de solucionar todos estos problemas. Es decir, el protocolo DNS debera tener sus propias conexiones fsicas entre mquinas, sus mecanismos para encontrar un camino entre todas las mquinas que estn conectadas simultneamente, sus propias direcciones IP, y sus propios mecanismos para diferenciarse de otros servicios (como la Web o el correo electrnico). Esto convertira al aparentemente sencillo protocolo DNS en un sistema de una complejidad inabarcable, y lo mismo ocurrira con cualquier otro protocolo que tuviese que
El servidor DNS nos enviar una respuesta que contendr la IP correspondiente a ese nombre.
Gracias a esto, a continuacin nuestro navegador podr acceder a la mquina que contiene la pgina Web que deseamos visitar, ya que slo puede existir una comunicacin directa entre dos mquinas si cada una conoce la direccin IP de la otra. Ahora vamos a pensar un poco en cmo se podra conseguir todo este mecanismo del DNS, en el cual un cliente solicita un nombre a un servidor, y el servidor le responde con la IP correspondiente. Qu problemas se nos presentan a la hora de llevar a cabo este proceso aparentemente tan sencillo? Pensadlo un poco, y despus mirad la lista de problemas a salvar que os pongo a continuacin, para ver si habis llegado a las mismas conclusiones: En primer lugar, por supuesto, hay que conseguir que ambas mquinas (cliente y servidor) tengan una conexin fsica, ya sea por cables, por radio, o por cualquier otro medio fsico que les permita establecer una comunicacin bidireccional. Pgina 24
PC PASO A PASO N 18
lidiar l solito con todos los problemas existentes en una comunicacin. Vamos a ver entonces cmo se reparte el trabajo de la comunicacin para permitir que el protocolo DNS se abstraiga de todo lo que no sea su misin directa. Empezamos escribiendo una url en nuestro navegador: http://neworder.box.sk/home.html En primer lugar, nuestro navegador quitar la parte de la URL que no corresponda al nombre, que es: neworder.box.sk . Teniendo ya el nombre, nuestro sistema construye un paquete que contiene la consulta DNS.
de origen, en cambio, servir para que el servidor pueda responder a nuestra consulta, utilizando como puerto de destino el que para n o s o t r o s e ra u n p u e r t o d e o r i g e n . En resumen, lo que el protocolo UDP ha conseguido es identificar una comunicacin entre dos mquinas, entre las cuales podra haber simultneamente varias comunicaciones establecidas. Lo que hace UDP es envolver el paquete con una pequea cabecera que aade la informacin necesaria, es decir, los puertos.
Y ah termina la responsabilidad del protocolo DNS, ya que su nica funcin consiste en enviar consultas de nombres para recibir direcciones IP en respuesta. Por tanto, nuestro sistema pasar ahora la bola a otro protocolo, que ser el encargado del transporte del paquete DNS. Existen varios protocolos de transporte, aunque los ms importantes son TCP y UDP. En este caso, el protocolo de transporte utilizado ser UDP, as que el sistema pasar el paquete DNS al protocolo UDP para que ste realice su funcin, que consiste bsicamente en marcar el paquete con un puerto de origen y otro de destino. Segn el puerto de destino asignado, la mquina que reciba el paquete (el servidor DNS) podr saber a qu servicio est destinado. En este caso, el puerto de destino es el 53 y, por tanto, es un paquete DNS. El puerto PC PASO A PASO N 18
El trabajo de UDP ya ha terminado, y tiene que pasar el paquete a otro protocolo para que se encargue del resto de problemas de comunicacin. Concretamente, el prximo protocolo tendr que solucionar el problema de identificar a dos mquinas (cliente y servidor) dentro de los millones que hay en toda la red Internet. En este caso, el protocolo de red utilizado ser el protocolo IP. Este protocolo se encargar de asignar las direcciones IP al paquete: la de origen ser la nuestra, y la de destino ser la del servidor DNS. Igual que slo podemos llamar a una persona por telfono si marcamos su nmero, slo podremos acceder a una mquina de Internet si marcamos su direccin IP. El protocolo IP, por tanto, aade al paquete una nueva cabecera, que contendr las IPs de origen y de destino, as como una indicacin de que el protocolo desde el cual le lleg el paquete fue el protocolo UDP. Pgina 25
mucho ms en prximos artculos, por lo que de momento nos quedamos slo con la idea de que el protocolo Ethernet aade su propia cabecera a todas las que haba ya en el paquete.
El paquete pasa ahora al protocolo Ethernet, un protocolo que permite encontrar el camino fsico para enlazar dos mquinas (cada una con una direccin IP que ya conocemos gracias al protocolo IP). Si cada mquina de Internet tuviese millones de cables para enlazarse con todas y cada una de las dems mquinas conectadas a la red, no sera necesario el uso de protocolos de enlace. Pero, al estar en Internet todo conectado con todo, necesitamos un mecanismo para encontrar el camino entre dos mquinas, an conociendo las direcciones que las identifican (direcciones IP). Exactamente lo mismo ocurre en el telfono, lo cual podemos ver claramente si recordamos a las telefonistas de antao. Antiguamente (y hoy tambin ocurre, pero con la diferencia de que est automatizado) en el instante en que marcabas un nmero de telfono no se estableca una comunicacin. Para conseguir esto haca falta un procedimiento intermedio, que era el de las telefonistas. Las telefonistas se encargaban de ir conectando y desconectando cables en sus paneles para conseguir enlazar los dos puntos de la comunicacin. En el caso de Internet, a pesar de lo que os hayan contado vuestros padres, no existe una raza de enanitos encargada de conectar y desconectar cables, as que todo esto ocurre de forma automtica y virtual, es decir, no se conecta ni se desconecta nada fsicamente, si no que simplemente se establecen conexiones lgicas. Para establecer estas conexiones se utilizan otro tipo de direcciones sobre las que ya habl un poco en el artculo anterior, y hablar Pgina 26 Hasta ahora ya hemos solucionado los tres ltimos problemas que mencion (volved atrs y revisad la lista de problemas, y veris que en efecto estn solucionados), as que slo nos queda el primer problema: la conexin fsica. La solucin a este problema es bien sencilla: enchufa el cable del mdem, porque si no, por mucho protocolo que tengas seguro que no vas a poder enviar ninguna consulta DNS! :-P Una vez que nuestro paquete est ya circulando por los cables fsicos (u ondas de radio fsicas), terminar llegando hasta el servidor DNS. El servidor analizar el paquete, ver que se trata de una consulta DNS, y har lo que tenga que hacer para conseguir el resultado pedido (explicado en detalle en el artculo sobre DNS de la serie RAW, en el nmero 14 de la revista). Una vez encontrada la respuesta, tendr que construir un sencillo paquete de respuesta DNS que simplemente contendr la direccin IP pedida como resultado de la traduccin del nombre neworder.box.sk. Este paquete, para poder circular hasta nosotros de vuelta, tambin tendr que tener sus propias cabeceras UDP, IP, y Ethernet. El paquete completo (con las cabeceras) de respuesta podra ser parecido a este: RESPUESTA DNS: IP = 66.250.131.132 CABECERA UDP: Puerto origen = 53 Puerto destino = 20 PC PASO A PASO N 18
CABECERA IP: IP origen = 215.22.1.13 IP destino = 217.12.1.15 Protocolo = UDP CABECERA Ethernet: MAC origen = 548F44A5558D MAC destino = 54F566A47F88 Protocolo = IP Os recomiendo que volvis atrs para ir comparando cada campo de la respuesta con los campos correspondientes en la consulta. Posiblemente veris varias cosas que os parecern muy extraas. Por ejemplo, por qu la IP de destino de la respuesta no es 192.168.1.2?Esto ya lo explicar cuando hable sobre el protocolo IP a lo largo del curso. Y, por qu ninguna de las dos direcciones MAC tiene nada que ver con las que haba en la consulta? Un poco de paciencia, por favor! Que ya explicar todo esto a lo largo del curso! :-)
quedado muy clara, pero quiz no tenis tan clara la necesidad de especificar tambin un puerto de origen. Imaginemos que nuestro navegador realiza una consulta DNS con nuestro servidor DNS, pero casi al mismo tiempo nuestro cliente de correo electrnico tambin est realizando otra consulta DNS al mismo servidor. No podemos saber de ninguna manera cul de las dos respuestas nos llegar antes. Por una parte, si lesteis el artculo sobre DNS de la serie RAW, sabris que el tiempo para procesar una consulta DNS puede variar enormemente. Por ejemplo, una traduccin que se encuentre en la cache del servidor DNS nos llegar casi al instante, mientras que otra traduccin menos afortunada podra requerir establecer varias conexiones con varias mquinas, desde los servidores raz, y los servidores del TLD, hasta el ltimo servidor de la jerarqua DNS. Si no sabis de qu hablo no os asustis, que esto no tiene nada que ver con UDP, si no con DNS, y no os hace falta conocerlo ahora. :-) La idea con la que os tenis que quedar es que de ninguna manera se puede asumir que al hacer dos consultas una detrs de otra, las dos respuestas nos llegarn en el mismo orden. Por tanto, si el servidor nos enva las dos respuestas, necesitamos de alguna manera saber cul de las dos es la que solicit nuestro navegador, y cul es la que solicit nuestro cliente de correo electrnico. De ah la necesidad del puerto de origen! Por supuesto, si lesteis el artculo sobre DNS os estaris preguntando: y qu hay de los transaction ID? Permiten perfectamente diferenciar una consulta DNS de cualquier otra! Pues s, es cierto, pero el caso de DNS es un poco especial, ya que no es normal que los protocolos que utilicen UDP (o TCP) para e l t ra n s p o r t e i n c l u ya n s u s p r o p i o s identificadores para cada conexin. Si se hizo as en el caso de DNS no fue por motivos de identificar cada conexin, ya que para eso Pgina 27
2.2. FUNCIONES DE LA CAPA DE TRANSPORTE UDP 2.2.1. Identificacin conexiones de
Lo importante que tenemos que comprender ahora, una vez hecho este repaso al sistema de protocolos por capas UDP/IP, es que gracias al protocolo UDP se puede identificar una comunicacin especfica entre dos mquinas, gracias a los puertos de origen y de destino. Esto nos permite tener varias conexiones simultneas entre dos mquinas (aunque las direcciones IP de cada conexin sean las mismas, las conexiones se pueden diferenciar gracias a los puertos), y tambin nos permite acceder al mismo servicio en varias mquinas diferentes (podemos, por ejemplo, estar viendo dos pginas Web de dos servidores diferentes al mismo tiempo). Supongo que la necesidad de especificar un puerto de destino en cada paquete os habr PC PASO A PASO N 18
sobraba con lo que hace UDP, si no por motivos de seguridad, como ya vimos al hablar en la s e r i e R AW s o b r e l o s a t a q u e s p o r envenenamiento de DNS. En la prctica, hay casos en los que el puerto de origen es irrelevante, por lo que no siempre es obligatorio especificarlo. En estos casos, lo que se hace es usar el puerto 0 como origen.
gruones que se dedican a desconectar cables de vez en cuando, ocasionando as la prdida de paquetes. No cabe duda de que ninguna tecnologa es perfecta, y por eso siempre puede haber prdidas de datos en cualquier comunicacin. Qu ocurrira, por ejemplo, si no nos llegase la respuesta del servidor DNS, a pesar de que ste la hubiera enviado? Si, por cualquier motivo, la respuesta se perdiese por el camino, no pudiendo llegar hasta nosotros, habra alguna forma de detectar y solventar esta situacin? Analizando el funcionamiento bsico del protocolo UDP, tal y como lo hemos visto, no habra ninguna manera. En UDP cada mquina enva sus paquetes a la red, sin tener ninguna certeza de si llegarn o no a su destino. Una vez que el servidor DNS enve su respuesta, se desentender del asunto, al no tener forma de saber si la respuesta nos ha llegado o no. Este es el principal problema de los protocolos no orientados a conexin, como es el caso de UDP. Como ya vimos en el artculo sobre DNS, en el caso de TCP esto es muy diferente, ya que TCP es un protocolo orientado a conexin. Por cada paquete transmitido en TCP es obligatorio que el receptor enve un acuse de recibo para que el emisor sepa con certeza que los datos han llegado al destino. Esto no es as en UDP. En UDP no hay manera de saber si los datos llegan al destino. Esto es una gran desventaja pero, por otra parte, tiene la gran ventaja de hacer la comunicacin mucho ms fluida, al no verse interrumpida constantemente por miles de paquetes de acuse de recibo. Esta caracterstica convierte a UDP en un p r o t o c o l o d e t ra n s p o r t e i d e a l p a ra comunicaciones sencillas (como DNS, o TFTP (Trivial File Transfer Protocol --- Protocolo Trivial de Transferencia de Ficheros)), y para envos masivos de flujos de datos (como en PC PASO A PASO N 18
2.2.2. Correccin en los datos

Imaginad que por cualquier problema en la lnea los datos llegasen corruptos hasta nosotros, y uno de los nmeros que forman la IP que hemos solicitado al servidor DNS es incorrecto. Sera un gran problema no tener una cierta seguridad de que los datos que nos llegan de un servidor DNS son correctos. Estaramos cada dos por tres estableciendo conexiones con direcciones IP incorrectas. UDP no puede garantizar que los datos lleguen, pero si que nos da cierta garanta de que, si han llegado, son correctos. Para ello incorpora en su cabecera un dato que no hemos visto antes (ya que estabamos vindolo slo a grandes rasgos), que nos permite comprobar que los datos son correctos, tal y como veremos ms adelante. Este problema de la correccin de los datos perfectamente podra haberlo incluido en la lista de problemas de la comunicacin, pero no lo hice a propsito para que saliesen justo cuatro. :-P
2.3. LO QUE NOS DA EL PROTOCOLO UDP FRENTE A TCP 2.3.1. Fiabilidad comunicacin en la
NO
Aunque antes desment el mito de los enanitos telefonistas de Internet, unos enanos que sin duda si que existen en la red son los enanos Pgina 28
transmisiones multimedia de vdeo, audio, ...), pero en un protocolo que de ninguna manera sirve para comunicaciones que requieren fiabilidad (FTP, IRC, HTTP, ...). Por ejemplo, ahora que menciono el IRC, imaginemos lo que sera una conversacin en un chat en el que no tuvisemos la certeza de que lo que decimos vaya a llegar al resto de interlocutores. Algunas frases se perderan por el camino, y nadie podra saberlo, por lo que muchas conversaciones perderan su sentido y, probablemente, se convertiran en dilogos de besugos (aunque, incluso utilizando TCP hay gran cantidad de dilogos de besugos en IRC, pero eso ms que un problema tecnolgico es un problema intelectual).
2.3.3.Tratamiento adecuado de los paquetes grandes

Imaginemos que enviamos una consulta de DNS a un servidor, y ste nos responde, pero su respuesta se ha perdido por el camino. En una situacin normal, tras pasar un tiempo sin recibir la respuesta, volveramos a solicitarla, asumiendo que se perdi por el camino. Vaya! Eso s que es genial. Acabamos de solucionar el problema de la fiabilidad en la comunicacin. O no?... Que ocurrira si en lugar de ser una simple consulta DNS nuestro paquete fuese una solicitud a un servidor FTP para bajarnos un archivo grande (por ejemplo una ISO de 700MB? Si se perdiese el paquete de respuesta, el servidor tendra que volver a enviar nada menos que 700MB! Esto, por supuesto, es una barbaridad, y lo ideal para minimizar este tipo de problemas es dividir los paquetes demasiado grandes en paquetes ms pequeos, para que luego estos se unan en el orden adecuado al llegar al destino, y reconstruir as el paquete original. Si ha habido algn fallo tecnolgico en un momento dado, normalmente slo se perder alguno de los paquetes pequeos, que podr ser reenviado sin problemas. UDP no incorpora ningn mecanismo para partir los paquetes grandes, por lo que tampoco es adecuado para esta clase de comunicaciones. Quiz ahora os estaris preguntando por qu entonces he dicho que UDP puede ser adecuado para transmisiones multimedia donde, sin duda, el flujo de datos es enorme. La cuestin fundamental aqu es que en los contenidos multimedia no es crtica la prdida de los datos. Por ejemplo, podemos estar transmitiendo una pelcula a razn de 20 fotogramas por segundo, enviando por ejemplo cada fotograma en un paquete independiente. En este caso, la prdida de un nico paquete Pgina 29
2.3.2. Flujo ordenado de datos

Otro gran problema potencial de UDP es el del desorden. En el caso de DNS parece todo muy sencillo: una consulta -> una respuesta. Pero, qu ocurrira si, por ejemplo, intentsemos hacer un chat mediante UDP? Internet es una red increblemente compleja, y existen muchos factores que pueden determinar que los paquetes vayan ms o menos rpidos en cada instante. Esto puede dar lugar a situaciones tan extraas como que dos paquetes salgan uno tras otro de una mquina, pero primero llegue al receptor el ltimo que sali. Si no hay un mecanismo para controlar el orden en que deben ir los paquetes, en el chat veramos respuestas a preguntas an no formuladas, monlogos sin sentido, etc. Otros protocolos de transporte, como TCP, s que incluyen mecanismos para garantizar el correcto orden de los paquetes; pero no es el caso de UDP, por lo que es otro aspecto a tener en cuenta a la hora de decidir si nuestra aplicacin funcionar mejor sobre un protocolo seguro y robusto como es TCP, o sobre un protocolo ms fluido como es UDP. PC PASO A PASO N 18
no sera en absoluto crtica. Simplemente perderamos un fotograma, y eso sera prcticamente imperceptible para el ojo humano, y para nada afectara al espectador de la pelcula. En cualquier caso, nunca sera necesario reenviar el paquete. El tema de la particin de paquetes grandes es mucho ms complejo de lo que puede parecer en un principio ya que, entre otras cosas, no slo es misin del protocolo de nivel de transporte, pero mejor que me quede calladito ahora, que si no os voy a liar bastante, y ya habr tiempo de ver todo eso a lo largo del curso. ;-)
Como ya hemos explicado los conceptos, podemos permitirnos el lujo de poner las cabeceras sin explicar nada, como hace el RFC :)
3.
UDP EN DETALLE
Antes de deciros cul es el RFC que detalla el protocolo UDP os tengo que poner sobre aviso: podis asustaros del tamao del RFC, as que no tengis miedo, que yo har todo lo posible por resumiros lo ms importante, como siempre. ;-) El RFC en cuestin es el RFC 768 (ftp://ftp.rfceditor.org/in-notes/rfc768.txt). Ejem... esto.... slo dos pginas? Bueno, quiz he exagerado un peln con eso del tamao. 0;-)
Esta es la estructura de una cabecera UDP, es decir, del trozo que se aade a cada paquete para luego pasarlo al protocolo IP, el cual a su vez aadir otro trozo, que se sumar tambin al trozo que luego aadir el protocolo Ethernet. En los ejemplos anteriores veamos slo dos campos: puerto de origen, y puerto de destino. Aqu no slo vemos todos los campos, si no que adems vemos su longitud. Los numerajos que he puesto en la ilustracin encima de la cabecera son el nmero de bits. Es decir, el campo Puerto origen abarca desde el bit 0 hasta el bit 15, es decir, 16 bits, 16 que son 2 bytes. Por tanto, como 2 son 65536, ste es el nmero de puertos que existen en UDP (y tambin en TCP, por cierto). Como vemos, el campo Puerto destino abarca desde el bit 16 hasta el 31, que son otros 16 bits. El campo Tamao paquete son otros 16 bits, as como el campo Suma de comprobacin. En el campo DATOS es donde se encuentra todo lo que ha englobado el paquete UDP. Por ejemplo, en el caso de DNS, la consulta DNS estara en el campo DATOS del paquete UDP. Su tamao ahora puede ser cualquiera, y precisamente para eso sirve el campo Tamao paquete. PC PASO A PASO N 18
NOTA DE PC PASO A PASO / HXC
Para los que nunca nos han leido, decir que RFC (Request For Comments) son una serie de ms de 3000 documentos donde se detalla todo lo relacionado con la tecnologa de Internet. Para los ALERGICOS al ingls, tienes al final de este artculo el RFC en perfecto castellano ;)
El RFC de UDP est sin duda escrito para gente entendida en el tema, por lo que no se andan con explicaciones, van directamente al grano, que es la especificacin de las cabeceras UDP. Pgina 30
Lo he llamado Tamao paquete porque es un nombre ms claro, pero su nombre original es Length (por si leis algo sobre el tema y os lais). Este campo indica el nmero de bytes que ocupa todo el paquete UDP, incluyendo la cabecera. Al ser la cabecera de un tamao fijo de 64 bits, es decir, 8 bytes, el campo Length ser siempre como mnimo 8 (sera el caso de un paquete que no contenga datos). Con respecto al campo Suma de comprobacin (checksum en el original) hay bastante ms que decir. ste es el campo que nos permite comprobar que los datos que hemos recibido son correctos, es decir, que el paquete no ha tenido problemas que hayan corrompido los datos durante su transporte. Para calcular la Suma de comprobacin se genera una cabecera con los siguientes campos:
Si habis echado un vistazo a la lista, habris visto que el protocolo UDP tiene asignado el nmero 17. Por tanto, en la cabecera que estamos tratando ahora habra que poner un 17 en el campo Protocolo. Con todos estos campos se realiza una operacin de aritmtica binaria, que es la suma en complemento a uno de 16 bits de toda la cabecera. No voy a entrar en detalles de cmo se realiza esta operacin, as que si tenis curiosidad podis consultar el RFC 1071 o, si lo prefers, tenis aqu directamente un cdigo en C que calcula la suma de comprobacin (checksum) para el protocolo TCP: h t t p : / / w w w. n e t f o r 2 . c o m / t c p s u m . h t m. Si queris utilizar este cdigo para el caso de UDP slo tenis que cambiar esta lnea: u16 prot_tcp=6; Por esta otra: u16 prot_tcp=17; Aunque, si queris que quede un poco ms bonito, preocupaos de cambiar tambin el nombre de la variable para que se llame prot_udp. ;-)
Todos estos campos los conocemos, excepto el campo Protocolo. Cada protocolo existente tiene un nmero nico asignado que le diferencia de los dems protocolos, y esto permite por ejemplo, propagar la informacin sobre a qu protocolo hay que pasar un paquete despus de procesarlo, tal y como hemos visto en el ejemplo al principio de este artculo, en el cual la cabecera IP contena un campo Protocolo = UDP, y la cabecera Ethernet contena un campo Protocolo = IP. Esta lista est mantenida por el IANA (Internet Assigned Numbers Authority), as que podis consultarla en www.iana.org. Si queris una lista ms sencilla, aunque no actualizada, la tenis en el RFC 1700 (http://www.rfc-editor.org/rfc/rfc1700.txt). PC PASO A PASO N 18
Cuando recibimos un paquete UDP, nuestro sistema compara la suma de comprobacin con los datos que conoce sobre el paquete (IP de origen, IP de destino, y tamao de paquete UDP), y si algo no concuerda sabr que ha habido algn problema y los datos del paquete no son vlidos. Un detalle curioso con respecto al complemento a uno (la forma de representacin binaria utilizada en la suma de comprobacin) es que existen dos formas de representar el cero: o bien que todos los dgitos sean 1, o bien que todos sean 0. Esto nos es til en nuestro caso, ya que lo que se hace es usar la primera representacin del cero (todos los dgitos son 1) para las Pgina 31
sumas cuyo resultado son cero, y la otra representacin del cero (todos los dgitos son 0) indica simplemente que ese paquete no incluye una suma de comprobacin, por el motivo que sea (por ejemplo, si el protocolo no requiere una comprobacin de los datos).
http://winpcap.polito.it/, pincharemos en DOWNLOADS (en el men de la izquierda) y aparecer una lista descargas. Tenemos que descargarnos el WINPCAP 3.0
4.
UDP EN LA PRCTICA
Aqu voy a presentar algunas herramientas que nos pueden ser tiles a lo largo de todo el curso de TCP/IP. Intentar no discriminar a nadie, explicando herramientas tanto para Windows como para Linux. Concretamente, las herramientas que vamos a utilizar nos permiten construir paquetes desde cero para varios protocolos diferentes (en este caso, el que nos interesa es UDP). Para que estos programas funcionen, nuestro sistema tiene que permitir el uso de raw sockets, es decir, de paquetes generados desde cero. Linux siempre ha permitido los raw sockets, y Windows slo lo hace desde sus versiones XP y 2000. Si an queda algn usuario de Windows 9x (95, 98, o Millenium), que tampoco se preocupe, ya que puede utilizar las libreras WinPCap para que su sistema admita raw sockets. Estas libreras las tenis en: http://winpcap.polito.it/. De todas maneras, nosotros vamos a utilizar para nuestras prcticas en Windows un programita llamado Nemesis. Esta aplicacin necesitar las libreras WinPCap incluso si tienes un Windows XP y 2000 tranquilos, ahora veremos detalladamente todo esto :)
No cometas el error de bajarte la ltima versin (WINPCAP 3.1 BETA), hemos podido comprobar que no funciona correctamente en bastantes de nuestros equipos, incluso con configuraciones muy normalitas. As que ya sabes, descarga la versin 3.0 tal y como te indicamos :) Una vez descargado el archivo mencionado (WinPcap_3_0.exe) lo ejecutaremos para que se instale en el sistema. Si te pide reiniciar Windows, hazle caso :) A continuacin, ya podemos bajar el Nemesis, que lo tenis aqu: http://www.packetfactory.net/Projects/nem esis/ (Por supuesto, bajad la versin para Windows).
4.1. NEMESIS PARA WINDOWS (TODAS LAS VERSIONES)

En primer lugar vamos con los usuarios de Windows, no porque sean ms importantes, si no porque ya he empezado hablando de ellos antes. :-P Lo primero que tenemos que hacer es bajarnos las libreras WinPCap. Para ello abriremos nuestro navegador preferido e iremos a Pgina 32 PC PASO A PASO N 18
Obtendremos el archivo comprimido nemesis1.4beta3.zip y lo descomprimiremos en la carpeta c:\nemesis. Este programa no necesita instalarse, ahora veremos cmo utilizarlo ;) Podemos pasar ya a la accin. Si vais al directorio (carpeta) sobre donde habis descomprimido el Nemesis (en nuestro caso c:\nemesis), veris que hay una serie de archivos TXT, uno de los cuales se llama nemesis-udp.txt. En ese archivo tenis instrucciones para utilizar Nemesis con UDP, que es lo que nos interesa ahora. Enseguida descubriris que Nemesis es una aplicacin ms prctica que esttica, ya que no tiene interfaz grfica, si no que funciona desde la consola MS-DOS. Vamos a ver un primer ejemplo de uso de Nemesis: Primero abrimos una consola de MS-DOS (una de nuestras habituales ventanitas negras). Cmo se hace eso? Ya lo hemos explicado mil veces, tienes dos opciones: Menu Inicio --> Todos los Programas --> Accesorios --> Smbolo del sistema Menu Inicio --> Ejecutar y en la ventana que nos aparezca escribimos command y pulsamos enter Ahora, utilizando nuestra consola de MS-DOS vamos al directorio donde hemos tenemos en Nemesis esperndonos. Para el que no sepa hacer eso (que a estas alturas de la publicacin ya deberan ser MUY POCOS): En nuestra ventanita negra escribimos cd c:\ y pulsamos enter (con esto nos vamos al directorio raz del disco duro C). E n n u e s t ra ve n t a n i t a n e g ra escribiremos cd c:\nemesis y pulsaremos enter (con esto nos posicionamos en el directorio donde tenemos nuestro Nemesis). PC PASO A PASO N 18
Escribimos dir y pulsamos enter. Con ello veremos un listado del contenido de la carpeta Nemesis, veremos, entre otros el archivo nemesis.exe (nuestro preciado Nemesis ;))
Por fin, escribimos:

nemesis udp v y 53 D 194.224.52.6 P
y pulsamos enter, nos aparecer algo como esto: UDP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22) [IP] 68.253.120.0 > 194.224.52.6 [IP ID] 64988 [IP Proto] UDP (17) [IP TTL] 255 [IP TOS] 00 [IP Frag offset] 0000 [IP Frag flags] [UDP Ports] 64988 > 53
Pgina 33
A continuacin, escribimos cualquier cosa: hola Wrote 33 byte UDP packet. UDP Packet Injected Vamos a analizar lo que hemos hecho. En primer lugar, al llamar a Nemesis con la opcin udp en primer lugar (nemesis udp) le decimos que queremos enviar un paquete UDP , de entre todos los protocolos que soporta Nemesis. La opcin v es la clsica opcin verbose de muchos programas, que nos permite ver en pantalla informacin detallada sobre lo que estamos haciendo. La opcin y sirve para detallar el puerto UDP de destino . En este caso, hemos utilizado el conocido puerto 53, que es el puerto de DNS. La opcin D sirve para especificar la direccin IP de destino . En este caso, hemos utilizado la direccin de un servidor DNS de Telefnica. Por ltimo, la opcin P sirve para indicar qu datos queremos meter en el campo DATOS del paquete UDP. Por ejemplo, en este caso, debera ir aqu la supuesta consulta DNS. En el caso de este ejemplo, poniendo P indicamos a la aplicacin que queremos meter nosotros los datos directamente desde teclado. Analicemos ahora el comportamiento de Nemesis. En primer lugar, vemos que ha utilizado como IP de origen una que no es la nuestra, por lo que la respuesta a este paquete difcilmente podra llegarnos a nosotros. Es ms, es tambin improbable que el paquete llegue siquiera a su destino, ya que los routers que habr en los primeros pasos del camino (por ejemplo, nuestro router ADSL, o el router de nuestro ISP) probablemente rechazarn el paquete al no provenir supuestamente de
una de las mquinas a las que tienen que dar servicio. Y cual puede ser la utilidad de utilizar una IP que no es la tuya? Pues ya hablaremos sobre todo eso a lo largo del curso, pero os adelanto que esto puede servir para llevar a cabo gran nmero de ataques. En nuestro caso no queremos atacar a nadie, simplemente queremos comprender de forma prctica el funcionamiento del protocolo UDP. Por lo tanto preferimos utilizar nuestra IP como IP de origen: nemesis udp v y 53 S 192.168.1.2 D 194.224.52.6 P Hemos aadido la opcin S para especificar la IP de origen. Si estamos detrs de un router, tendremos que especificar nuestra IP privada (de nuestra red local), ya que el router ya se encargar de convertirla luego en vuestra IP pblica.
Ya se explico...
Ya se ha explicado mil veces, pero bueno para saber cul es tu IP, simplemente abre una "ventanita negra", escribe ipconfig /all y pulsa enter. Este tema ya se trat en profundidad en los primeros nmeros de Hack x Crack.
Si seguimos observando el comportamiento de Nemesis, veremos que ha escogido un puerto aleatorio como puerto de origen. Para la mayora de las aplicaciones esto nos valdr, pero si queremos probar a especificar un puerto de origen en concreto utilizaremos la opcin x: nemesis udp v x 1000 y 53 S 192.168.1.2 D 194.224.52.6 P Esto puede sernos til si estamos detrs de un firewall muy exigente que slo nos permita utilizar algunos puertos UDP determinados (en el caso del ejemplo, el puerto 1000). PC PASO A PASO N 18
Pgina 34
Por ltimo, os habris dado cuenta de que no es nada prctico meter los datos directamente desde teclado, ya que es bastante complicado generar una consulta DNS a pelo e introducirla desde el teclado. En la mayora de los casos, os ser mucho ms til construir primero la consulta con algn editor hexadecimal (por ejemplo, podis utilizar UltraEdit, que adems de ser un magnfico editor y visor de textos, es tambin un editor hexadecimal bsico), guardarla en un fichero, y luego cargarla directamente en Nemesis con la opcin P. Por ejemplo, si nuestro fichero se llama consulta.txt haremos: nemesis udp v x 1000 y 53 S 192.168.1.2 D 194.224.52.6 P consulta.txt Podemos, por ejemplo, capturar una consulta DNS real con un sniffer, despus modificarla a nuestra voluntad con el editor hexadecimal, guardar la consulta modificada en un archivo, y despus enviarla a travs de Nemesis. En el artculo de la Serie RAW sobre DNS habl acerca de la tcnica de envenenamiento de cache DNS . Con Nemesis, y un sencillo shell script podramos explotar esta tcnica una vez conseguidos los datos necesarios. Si no habis ledo el artculo sobre DNS, os recomiendo que pasis este punto, porque probablemente no os enteraris de nada. :-) Si, por ejemplo, tenemos estos datos para llevar a cabo el ataque: Direccin IP del servidor DNS de la vctima = 194.224.52.6 Direccin IP del servidor DNS authoritative que queremos suplantar = 194.220.51.2 Puerto UDP utilizado por el servidor DNS de la vctima = 1200 Suponemos, por supuesto, que conocemos tambin el identificador de transaccin, y que con l hemos construido una respuesta DNS PC PASO A PASO N 18
falsa que tenemos almacenada en el archivo envenenamiento.txt. La forma de lanzar esta respuesta falsa sera: nemesis udp x 53 y 1200 S 194.220.51.2 D 194.224.52.6 P envenenamiento.txt Podemos automatizar esto mediante un script que haga un bucle en el cual vaya utilizando distintos Transaction ID y, tal y como vimos en el artculo sobre DNS, segn la versin de BIND que utilice el servidor DNS de la vctima tendremos una mayor o menor probabilidad de xito.
4.2. HPING PARA LINUX

Existe tambin versin de Nemesis para Linux, pero os ensear mejor una herramienta bastante ms potente, que es Hping. Podis bajar Hping de www.hping.org. Para instalarlo tendris que compilarlo primero. Los pasos a seguir son los tpicos: Primero, una vez bajado el archivo con extensin .tar.gz , lo descomprimimos y desempaquetamos con el comando: tar -zxvf hping2.0.0-rc2.tar.gz Nos crear un directorio hping2-rc2, en el cual entraremos ( cd hping2-rc2 ), para despus ejecutar: ./configure A continuacin, ejecutamos: Make Y, por ltimo: make install En caso de cualquier problema con este sistema estndar de instalacin, podis consultar el archivo INSTALL con instrucciones ms detalladas sobre el proceso. Una vez instalado, vamos a probar un poco su funcionamiento. Por supuesto, tendris la correspondiente pgina del manual de hping: man hping2 Hping no slo permite enviar un nico paquete, Pgina 35
si no que adems implementa sencillos bucles para poder generar muchos paquetes sin necesidad de programar scripts. Si queremos que enve un nico paquete tendremos que usar la opcin --count 1. Aunque mejor que veamos directamente un ejemplo: hping2 193.224.52.6 --udp --destport 53 --file envenenamiento.dat --data 14 -count 1 El primer parmetro (193.224.52.6), como podis imaginar, es la IP de destino del paquete, y es el nico parmetro obligatorio. El parmetro --count ya hemos dicho que indica el nmero de paquetes a enviar. Segn las opciones estos paquetes podrn ser diferentes entre s, por ejemplo, incrementando el puerto de origen en cada paquete. Si queris ms detalle sobre estas opciones consultad la pgina del manual. Por defecto, el puerto de origen se incrementa con cada paquete, as que si queremos utilizar siempre el mismo puerto utilizaremos la opcin --keep. El parmetro --udp, por supuesto, indica que el protocolo a utilizar ser UDP. El parmetro --destport es el puerto de destino del paquete. El parmetro --file es el fichero en el que tenemos el campo DATOS del paquete, es decir, por ejemplo la consulta DNS, o la respuesta falsa para el caso de que estemos haciendo un ataque de envenenamiento de cache DNS. El parmetro --data es el tamao de los datos sin la cabecera, es decir, en este caso sera igual al campo Tamao paquete de la cabecera UDP, pero restndole 8 bytes, que son los que ocupa la cabecera UDP. Si quisisemos especificar un puerto de origen usaramos el parmetro --baseport. Si no se especifica, el puerto de origen ser aleatorio. Pgina 36
Una opcin curiosa de hping es la opcin --badcksum que genera una suma de comprobacin invlida en el paquete enviado, lo cual puede ser til para comprobar la reaccin de un sistema ante un paquete malformado. A lo largo del curso, entraremos en ms detalle en el funcionamiento de stas y otras herramientas. Por el momento, os animo a que vayis investigando por vuestra cuenta.
Autor: PyC (LCo)

RFC 768 J. Postel ISI 28 de Agosto de 1980
PROTOCOLO DE DATAGRAMAS DE USUARIO (User Datagram Protocol) (Traduccin al castellano: Diciembre de 1999) (Por Domingo Snchez Ruiz <domingo@quark.fis.ucm.es>) Introduccin Este Protocolo de Datagramas de Usuario (UDP: User Datagram Protocol)se define con la intencin de hacer disponible un tipo de datagramas para la comunicacin por intercambio de paquetes entre ordenadores en el entorno de un conjunto interconectado de redes de computadoras. Este protocolo asume que el Protocolo de Internet (IP: Internet protocol) [1] se utiliza como protocolo subyacente. Este protocolo aporta un procedimiento para que los programas de aplicacin puedan enviar mensajes a otros programas con un mnimo de mecanismo de protocolo. El protocolo se orienta a transacciones, y tanto la entrega como la proteccin ante duplicados no se garantizan. Las aplicaciones que requieran de una entrega fiable y ordenada de secuencias de datos deberan utilizar el Protocolo de Control de Transmisin (TCP: Transmission Control Protocol). [2]
PC PASO A PASO N 18
Formato 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Puerto de | Puerto de | | Origen | Destino | +--------+--------+--------+--------+ | | | | Longitud | Suma de Control | +--------+--------+--------+--------+ | | octetos de datos ... +---------------- ... Formato de la Cabecera de un Datagrama de Usuario Campos El campo Puerto de Origen es opcional; cuando tiene sentido, indica el puerto del proceso emisor, y puede que se asuma que se sea el puerto al cual la respuesta debera ser dirigida en ausencia de otra informacin. Si no se utiliza, se inserta un valor cero. El campo Puerto de Destino tiene significado dentro del contexto de una direccin de destino en un entorno internet particular. El campo Longitud representa la longitud en octetos de este datagrama de usuario, incluyendo la cabecera y los datos. (Esto implica que el valor mnimo del campo Longitud es ocho.) El campo Suma de Control (Checksum) es el complemento a uno de 16 bits de la suma de los complementos a uno de las palabras de la combinacin de una pseudo-cabecera construida con informacin de la cabecera IP, la cabecera UDP y los datos, y rellenada con octetos de valor cero en la parte final (si es necesario) hasta tener un mltiplo de dos octetos. La pseudo-cabecera que imaginariamente antecede a la cabecera UDP contiene la direccin de origen, la direccin de destino, el protocolo y la longitud UDP. Esta informacin proporciona proteccin frente a datagramas mal encaminados. Este procedimiento de comprobacin es el mismo que el utilizado en TCP. PC PASO A PASO N 18
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | direccin de origen | +--------+--------+--------+--------+ | direccin de destino | +--------+--------+--------+--------+ | cero |protocol| longitud UDP | +--------+--------+--------+--------+
Si la suma de control calculada es cero, se transmite como un campo de unos (el equivalente en la aritmtica del complemento a uno). Un valor de la suma de control trasmitido como un campo de ceros significa que el emisor no gener la suma de control (para depuracin o para protocolos de ms alto nivel a los que este campo les sea indiferente).
Interfaz de Usuario Un interfaz de usuario debera permitir: la creacin de nuevos puertos de recepcin, operaciones de recepcin en los puertos de recepcin que devuelvan los octetos de datos y una indicacin del puerto de origen y de la direccin de origen, y una operacin que permita enviar un datagrama, especificando los datos y los puertos de origen y de destino y las direcciones a las que se debe enviar. Interfaz IP El mdulo UDP debe ser capaz de determinar las direcciones de origen y destino en un entorno internet as como el campo de protocolo de la cabecera del protocolo internet. Una posible interfaz UDP/IP devolvera el datagrama de internet completo, incluyendo toda la cabecera, en respuesta a una operacin de recepcin. Un interfaz de este tipo permitira tambin al mdulo UDP pasar un datagrama deinternet completo con cabecera al mdulo IP para ser enviado. IP verificara ciertos campos por consistencia y calculara la suma de control de la cabecera del protocolo internet. Pgina 37
Aplicacin del Protocolo Los usos principales de este protocolo son el Servidor de Nombres de Internet [3] y la Transferencia Trivial de Ficheros (Trivial File Transfer) [4]. Nmero del protocolo Este es el protocolo 17 (21 en octal) cuando se utilice en el Protocolo de Internet (IP). Se indican otros nmeros de protocolo en [5]. Referencias [1] Postel, J., "Internet Protocol," RFC 760, USC/Information Sciences Institute, Enero de 1980. (Nota del T. Hay traduccin al espaol por P.J. Ponce de Len: "Protocolo Internet", Mayo 1999.) [2] Postel, J., "Transmission Control Protocol," RFC 761, USC/Information Sciences Institute, Enero de 1980.
EL GANADOR DEL SORTEO DE UN SUSE LINUX 9 DEL MES DE Febrero ES:

Manuel perez garcia
sevilla
PERSONALIZA MOVIL TU MOVIL PERSONALIZA TU MOVIL MOVIL PERSONALIZA TU MOVIL MOVIL PERSONALIZA TU MOVIL TU MOVIL PERSONALIZA MOVIL TU PERSONALIZA MOVIL MOVIL TU PERSONALIZA MOVIL MOVIL TU PERSONALIZA MOVIL TU MOVIL PERSONALIZA MOVIL TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA MOVIL TU MOVIL PERSONALIZA MOVIL TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA TU MOVIL MOVIL TU PERSONALIZA MOVIL TU MOVIL PERSONALIZA MOVIL MOVIL PERSONALIZA TU MOVIL
PERSONALIZA MOVIL TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA MOVIL TU MOVIL PERSONALIZA TU MOVIL PERSONALIZA MOVIL TU MOVIL PERSONALIZA MOVIL TU MOVIL PERSONALIZA TU MOVIL MOVIL PERSONALIZA TU MOVIL
[3]
Postel, J., "Internet Name Server," USC/Information Sciences Institute, IEN 116, Agosto de 1979. Sollins, K., "The TFTP Protocol," Massachusetts Institute of Technology, IEN 133, Enero de 1980. Postel, J., "Assigned Numbers," USC/Information Sciences Institute, RFC 762, Enero de 1980.
[4]
[5]
Nota del traductor Este documento y las traducciones al espaol mencionadas en las referencias pueden encontrarse en: http://lucas.hispalinux.es/htmls/estandare s.html El proyecto de traduccin de RFC al espaol tiene su web de desarrollo en: http://www.arrakis.es/~pjleon/rfc-es Pgina 38
HAY MUCHOS MAS EN http://pclog.buscalogos.com/

PC PASO A PASO N 18
CURSO DE TCP/IP: (3 ENTREGA) TCP (TRANSMISION CONTROL PROTOCOL) - 1 parte.

- Empezaremos a estudiar las CABECERAS TCP - Veremos las diferencias entre TCP y UDP - Qu es eso de "protocolo orientado a la conexin"? ---> conexiones virtuales
1. INTRODUCCION
Despus de haber estado hablando indirectamente sobre el protocolo TCP/IP durante 10 meses en la serie RAW, al fin vamos a entrar de lleno en la base de todo esto: la base sobre la que se apoy toda la serie RAW. Al hablar del protocolo TCP al fin vamos a comprender qu es lo que ocurre realmente cuando hacemos un Telnet y la necesidad de establecer conexiones de este tipo. Comprenderemos tambin por qu se utiliza TCP como protocolo de transporte para la mayora de las aplicaciones, al compararlo con UDP y comprobar que son muchas las ventajas. Con este artculo, entramos a fondo en conceptos nuevos, como son las conexiones virtuales, el control de flujo, los flags, etc. Quiz no os queden del todo claros los conceptos despus de terminar de leerlo, pero no os preocupis, que est todo previsto. El curso continuar con una segunda entrega dedicada a TCP, en la cual aclararemos muchos de los conceptos que quedarn hoy en el aire, y veremos una serie de ejemplos que conseguirn
Pgina 14
con la prctica lo que no se puede conseguir con la mera teora. Adems, para hacerlo un poco ms amena, la segunda entrega incluir tambin algunas tcnicas de hacking basadas en el funcionamiento de TCP, que es lo que a muchos de vosotros ms os interesa. ;-) Aprenderemos adems a construir las cabeceras tal y como son en realidad, en binario. Pero lo ms importante es que podremos ver en detalle cmo es el trfico que circula constantemente entre nuestro ordenador y la red Internet.
2. DIFERENCIAS ENTRE TCP Y UDP

Por si no lo habis hecho, es importante que antes de continuar repasis los dos artculos anteriores del curso de TCP/IP (Introduccin, y UDP), ya que vamos a empezar comparando este nuevo protocolo con el que ya conocamos, el protocolo UDP.
2.1. Conexiones virtuales

Volvemos a insistir una vez ms en que una de las principales diferencias entre TCP y UDP es la existencia de conexiones virtuales. Como ya vimos, el protocolo TCP se dice que es orientado a conexin
PC PASO A PASO N 20
CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)
(en realidad conexiones virtuales), al contrario que UDP (no orientado a conexin). Las implicaciones de esto son muchas, tal y como iremos viendo a lo largo del artculo. De momento quedmonos con la idea de conexin virtual. Por qu se habla de conexiones virtuales, y no de conexiones a secas? Para encontrar una respuesta a esta pregunta basta con pensar un poco en la arquitectura de la red Internet (y de cualquier red TCP/IP). Si Internet hubiese existido hace 50 aos, probablemente su arquitectura hubiera sido muy diferente, igual que la red telefnica de ahora es muy diferente a la que haba entonces. La red telefnica de aquellos aos dependa de una figura humana bien conocida: la telefonista. Las telefonistas eran unas mujeres casi binicas que actuaban como intermediarias entre los distintos clientes de la red telefnica para que estos pudieran comunicarse entre s. Cuando un cliente deseaba hablar con otro, una telefonista tena que establecer una conexin manual entre las lneas de a m b o s clientes, conectando los cables correspondientes en un panel de conexiones.
PC PASO A PASO N 20
Imaginemos cmo habra sido la Internet en aquellos aos. Un autentico ejrcito de internetistas trabajando 24 horas para dar servicio a todas las conexiones que estableciese cualquier cliente: cada vez que alguien desease leer su correo electrnico, una internetista tendra que establecer una conexin en el panel entre el cliente y su servidor de POP3, cada vez que alguien visitase una pgina web una internetista tendra que establecer una conexin entre el cliente y el servidor de la pgina web, etc., etc. Desde luego, esto habra sido una locura inviable, sin contar con el hecho de que la red sera muy lenta y muy insegura. Si tratsemos de mejorar esta idea sustituyendo a las internetistas humanas por un medio mecnico automatizado que estableciese las conexiones mediante rels seguiramos teniendo muchos problemas, y uno de los ms preocupantes sera el de la velocidad. Se mire por donde se mire, una red en la que haya que establecer nuevas conexiones cada vez que se desee utilizar un servicio siempre ser ms lenta que una red en la que todo est conectado de antemano. Y precisamente esa es la topologa de la red Internet: todo est conectado de antemano. Nuestro PC siempre tiene un nico cable que nos conecta con Internet (el cable de red que va al router, o el cable que va al modem, o el cable etreo que nos une con nuestra estacin wireless). Y lo mismo ocurre con cualquier mquina conectada a Internet. Nunca hay que cambiar ningn cable de sitio, por muy diferentes que sean las conexiones que queramos establecer. Tanto si vamos a enviar un correo a
Pgina 15
nuestro mejor amigo, como si vamos a ver una pgina web de Japn, las conexiones fsicas son siempre las mismas. Esto hace que los protocolos de la red Internet tengan necesariamente que estar muy bien pensados para que esto no de lugar a un completo caos. Para evitar estas confusiones nace el concepto de conexin virtual, que busca las ventajas de las redes en las que las conexiones no estn establecidas de antemano, pero sin toparse con sus desventajas. Si bien todo sigue conectado de antemano, las conexiones virtuales emulan el mecanismo por el cual, antes de comenzar una comunicacin entre dos puntos, es necesario poner a ambas partes de acuerdo y establecer una conexin entre ambas. En teora, las conexiones virtuales permiten, igual que una conexin real, que la comunicacin no sea escuchada por nadie que no est conectado al cable que une ambos puntos, que terceras personas no puedan intervenir en la comunicacin enviando datos que no sean de ninguna de las dos partes legtimas, que nadie pueda hacerse pasar por otro, etc., etc. Por supuesto, todo esto es en teora pero, como bien sabemos, nada en este mundo funciona como en teora debera. ;-) Qu es lo que caracteriza una conexin? Las conexiones de las que hemos hablado son siempre conexiones entre dos puntos, y as son todas las conexiones en TCP. Aunque puedas estar en un chat hablando con 100 personas a la vez, en realidad toda esa comunicacin se realiza a travs de pares de conexiones.
Pgina 16
Para entenderlo, veamos el caso de un chat entre 3 personas. Podramos pensar en primer lugar en una solucin que fuese un nico cable con 3 conectores que conectase entre s a los 3 interlocutores.
Pero, que ocurrira si quisiramos meter a una persona ms en la conversacin? Tendramos que quitar el cable de 3 conectores y cambiarlo por uno de 4? Sera mucho ms sencillo un sistema en el cual todo funcionase mediante cables de slo dos conectores. Para que alguien entrase o saliese del chat, bastara con conectar o desconectar un slo cable, pero no habra que modificar toda la red, y el resto de usuarios del chat no se veran afectados por lo que hiciera uno solo. Para poder realizar este chat entre 3 personas mediante cables de 2 conectores se hace imprescindible la presencia de un intermediario que gestione todas las conexiones de todos los usuarios. Esta es precisamente la misin de un servidor de chat.
PC PASO A PASO N 20
Por lo que hemos visto hasta ahora, es obvio que lo primero que caracteriza a una conexin son los dos extremos que conecta. En nuestro contexto, los extremos de la conexin se identifican mediante las conocidas direcciones IP. Pero la identificacin de los extremos no es lo nico que caracteriza una conexin. Cada uno de los extremos podra tener varios conectores diferentes, as que no slo basta saber con quin conectas, si no tambin dnde. En nuestro contexto, cada uno de los conectores de un mismo extremo seran los diferentes servicios : HTTP, FTP, POP3, etc. Por tanto, al igual que ocurra con UDP, otro de los parmetros que caracterizan una conexin TCP son los puertos de conexin de ambos extremos. Si se tratase de conexiones fsicas, no hara falta mucho ms para ser caracterizadas. En cambio, al tratarse de conexiones virtuales, necesitamos algn mecanismo que identifique una conexin establecida. Y es aqu donde vemos la principal diferencia entre TCP y UDP. Los paquetes TCP contienen un campo en su cabecera que no contienen los paquetes UDP. Este campo adicional es el que permite identificar la conexin virtual a travs de la cual circula el paquete. La solucin ms obvia que podramos encontrar para implementar este identificador de conexin sera utilizar un nmero que identificase unvocamente la conexin. Pero esta solucin presentara varios problemas, el mayor de los cuales sera quiz la seguridad. Si una conexin se identifica permanentemente por un mismo nmero, es slo cuestin de tiempo que un atacante encuentre ese nmero por fuerza bruta y as, con slo spoofear su IP (utilizar algn mecanismo para enviar paquetes en nombre de una IP que no sea la suya), se pueda colar en la conexin ajena. Una solucin mucho mejor es utilizar un nmero que vaya cambiando con cada paquete, segn unas ciertas normas establecidas entre los dos extremos.
Pgina 17
Como vemos en esta otra imagen, ahora hay 3 cables en lugar de uno slo, y cada cable conecta a un nico usuario con el servidor que gestiona el chat. Es importante comprender que esto que hemos dicho de los cables de slo dos conectores no se refiere a las conexiones fsicas de Internet, si no a las conexiones virtuales que nos da el protocolo TCP. De hecho, muchas redes TCP/IP tienen fsicamente conectadas todas sus mquinas entre s, en lugar de realizar las conexiones mediante cables punto a punto, pero insisto en que esto slo ocurre con las conexiones fsicas, pero no con las conexiones virtuales, que son siempre punto a punto.
Hablando claro...
Hablando claro, no importa como conectes fsicamente tu PC a otros PCs (hay mil maneras de hacerlo, unas son punto a punto y otras no). Lo importante es que TU PC (y cualquier otro PC del mundo), cuando utilice el protocolo TCP, establecer siempre conexiones virtuales punto a punto.
PC PASO A PASO N 20
Esto en realidad no es tal y como lo pinto. Este nmero cambiante realmente existe, pero su principal finalidad no es la de identificar conexiones, si no ms bien la de mantener el estado de evolucin de una conexin, y saber as en todo momento qu paquetes se pueden enviar y qu paquetes se pueden recibir a travs de esa conexin. Este nmero es el llamado nmero de secuencia, pero mejor ser que no nos precipitemos ms, que ya habr tiempo de ver todo esto en detalle.
Una solucin mucho ms eficiente es englobar en un slo paquete los datos transmitidos y la confirmacin de los datos recibidos.
2.2. Fiabilidad en la comunicacin

Como ya cont en el artculo sobre UDP, al contrario que ste, el protocolo TCP tiene un mecanismo para asegurar que los datos llegan correctamente a su destino. Para conseguir esto, cada paquete TCP que llegue a un destino ha de ser respondido por ste mediante otro pequeo paquete que confirme la recepcin.
En esta figura vemos cmo las mquinas A y B intercambian paquetes a travs de una misma conexin, actuando ambos simultneamente como transmisores y receptores. En primer lugar, la mquina A enva el primer paquete (Paquete 1 A). Una vez recibido el paquete 1 A, la mquina B decide tambin empezar a enviar sus propios paquetes, por lo que enva un nico paquete a A en el que engloba la confirmacin de que recibi el paquete 1 A, as como su propio paquete 1 B. A esto responder la mquina A enviando el siguiente paquete de los que desea transmitir, pero englobando en el mismo tambin la confirmacin de que recibi correctamente el paquete 1 B. As continuara la comunicacin, hasta que la mquina A decidiese dejar de transmitir sus propios datos, por lo que su nica misin consistira ya slo en seguir confirmando la recepcin de los paquetes que le enva B, como ocurre en la figura con el caso del paquete 2 B, al cual la mquina A responde slo con una confirmacin de recepcin, pero sin englobar ms datos en el mismo paquete, ya que A no tiene ya nada ms que desee enviar.
PC PASO A PASO N 20
Esto sera as en el caso ms sencillo, pero menos comn, que sera el de una comunicacin unidireccional, donde slo una de las partes enviase datos a la otra. En la prctica, la mayora de los servicios son bidireccionales, por lo que es necesario intercalar los paquetes transmitidos con las confirmaciones de los paquetes recibidos. Esto podra dar lugar a un gran nmero de paquetes (el doble, exactamente), ya que a cada paquete de datos habra que sumar adems el correspondiente paquete de confirmacin.
Pgina 18
Qu ocurre si uno de los paquetes se pierde por el camino? Cada vez que una mquina transmite un paquete TCP, sta no lo borra de su memoria, si no que lo deja almacenado an por un tiempo, esperando que llegue la confirmacin de su recepcin. Si sta llega, se podr borrar el paquete de la memoria, y olvidarse para siempre de l. En cambio, si pasado un tiempo prudencial no ha llegado la confirmacin de su recepcin, se asumir que el paquete no ha llegado a su destino, por lo que ste se retransmitir. As, el paquete se conservar en la memoria todo el tiempo que sea necesario, reenvindolo cada cierto tiempo, hasta que al fin llegue la confirmacin de que el paquete fue recibido. En el caso de que, debido a estos reenvos, un mismo paquete llegue ms de una vez al mismo destino, no habr ningn problema, ya que el diseo de TCP permite diferenciar perfectamente un paquete de otro, por lo que al detectar la duplicacin simplemente se rechazar la copia.
2.4. Tratamiento de paquetes grandes

Esta capacidad de dividir los datos en fragmentos ordenados, combinada con el sistema de confirmacin de respuestas de TCP, convierte a ste protocolo en un protocolo de transporte ideal para la transmisin segura de grandes cantidades de datos.
2.5. Control de flujo

Aqu entramos ya en un nuevo concepto que habr que introducir, ya que es uno de los conceptos bsicos del campo de las redes y telecomunicaciones. Hasta ahora hemos tratado las redes y las mquinas como si fuesen perfectas, sin limitaciones. Pero sabemos muy bien que en la vida real esto no es as ya que, por ejemplo, el ancho de banda de una red es uno de los factores ms determinantes de su efectividad. Hemos asumido que los paquetes se iban transmitiendo a diestro y siniestro, y que estos iban a ser recibidos sin problemas. Bueno, no exactamente... Hemos dicho que s que poda haber problemas en la recepcin, pero realmente no hemos hablado de los problemas del ancho de banda. Si la nica solucin ante la congestin de la red fuese el mecanismo explicado anteriormente para asegurarnos de que todos los datos llegan al destino, el problema no se solucionara si no que, al contrario, sera cada vez mayor. Imaginemos la situacin. La mquina A, que transmite los paquetes, es demasiado rpida para lo que es capaz de procesar
Pgina 19
2.3. Orden en los datos

Tal y como decamos tambin en el anterior artculo, TCP identifica cada paquete con un nmero de secuencia que permite ordenarlos correctamente independientemente de su orden de llegada al destino. En el caso de UDP, los paquetes se iban procesando segn iban llegando. En cambio, en TCP un paquete se puede dividir en fragmentos que podrn llegar en cualquier orden, y los datos no se procesarn hasta que se hayan recibido todos los fragmentos y estos se hayan ordenado segn el nmero de secuencia de cada paquete.
PC PASO A PASO N 20
la mquina B, que recibe los paquetes. Por tanto, la mquina A empieza a enviar paquetes a toda velocidad y sin compasin, esperando las confirmaciones de la mquina B. Como B no da abasto, no es capaz de enviar las confirmaciones de recepcin a tiempo. Al no llegar las confirmaciones, A se pondr a reenviar los paquetes anteriores, al mismo tiempo que contina enviando paquetes a diestro y siniestro, por lo que la congestin, sumando los paquetes nuevos y los viejos, ser muchsimo mayor.
comunicacin, a no ser que sea un malnacido (que los hay), tendr que actuar en consecuencia, relajndose un poco y dndonos tiempo a asimilar lo que ya nos ha enviado. Ms adelante veremos en detalle cmo se implementa el control de flujo en TCP.
Todo esto que...
Todo esto que estamos explicando despus lo tocaremos en la realidad. Veremos los paquetes TCP y dnde est localizado cada concepto del que hablamos.
3. LO QUE S QUE TIENEN EN COMN TCP Y UDP

Como no todo va a ser diferencias, vamos a ver los puntos en comn entre ambos protocolos de transporte que, en el fondo, son bastante parecidos. En primer lugar, TCP tambin se apoya sobre el protocolo IP y, en este caso, el nmero de protocolo asignado a TCP para que la capa de red (la capa IP) pueda identificar el protocolo de transporte, es el nmero 6. Como ya sabemos, la cabecera IP contendr entre sus campos uno que identifique el protocolo de transporte que est por encima de l.
Si no se implementa algn mecanismo para evitar este caos, la situacin puede hacerse insostenible en poco tiempo. Un mecanismo que se encargue de ajustar el flujo de la comunicacin es precisamente lo que se conoce como control de flujo. En el caso de TCP, disponemos de un sencillo mecanismo de control de flujo, que consiste en incluir en la cabecera de cada paquete un campo que indica al otro extremo de la comunicacin cmo estamos de congestionados. Esta medida de la congestin la llevamos a cabo diciendo cuntos bytes estamos preparados para recibir. Segn nos vayamos saturando, este nmero ser cada vez menor, y el otro extremo de la
Pgina 20
PC PASO A PASO N 20
El punto en comn ms importante entre TCP y UDP es que el mecanismo de identificacin de servicios es el mismo: cada paquete, tanto en TCP como en UDP, lleva dos nmeros de puerto (origen, y destino), ambos comprendidos entre 0 y 65535 (16 bits). Los puertos de TCP funcionan
RFC 793 en espaol
RFC 793 en perfecto espaol!!! Como ya hemos comentado muchas veces, tenemos traducidos muchos de los RFC al espaol en la Web www.rfc-es.org. Este es el trabajo de muchas personas que desinteresadamente estn colaborando en un proyecto realmente descomunal: traducir los ms de 3000 documentos, si controlas de Ingles y te animas, ya sabes :) El RFC 793 en castellano est en http://www.rfces.org/getfile.php?rfc=0793
exactamente igual que los de UDP, pero no tienen ninguna relacin entre s, es decir, existen 65536 puertos para TCP, y otros 65536 puertos diferentes para UDP. Si, por ejemplo, en un firewall cierras el puerto 21 de TCP, no estars cerrando al mismo tiempo el puerto 21 de UDP, ya que son totalmente independientes. Otro punto en comn es que ambos protocolos incluyen una suma de comprobacin en cada paquete, que verifica la correccin de los datos incluidos en el mismo. La cabecera que se codifica en la suma de comprobacin de TCP es muy similar a la que se utiliza en UDP.
Como vemos, el RFC tiene 91 pginas, por lo que es bastante ms denso que la mayora de los RFCs que hemos visto hasta ahora (tanto en la serie RAW como en el curso de TCP/IP). An as, no es demasiado duro de leer, sobre todo si prescindimos de algunas cosas poco importantes para la comprensin del protocolo, como la especificacin de las variables del TCB, o toda la parte del final relativa al procesamiento de eventos. En cualquier caso, ya sabis que aqu tendris un buen resumen de todo lo ms importante. ;-) Como ya somos expertos en protocolos, vamos a plantar aqu directamente la cabecera TCP. No pierdas de vista esta imagen, haremos referencia a ella a lo largo de todo el artculo.
4. LA CABECERA TCP EN DETALLE

Entramos ya en los detalles tcnicos del protocolo TCP. En este caso, el RFC que los especifica es el RFC 793. Desde la pgina de los RFC (http://www.rfceditor.org) podemos bajar tanto versin en TXT (http://www.rfc-editor.org/cgibin/rfcdoctype.pl?loc=RFC&letsgo=793 &type=ftp&file_format=txt), como versin en PDF (http://www.rfc-editor.org/cgibin/rfcdoctype.pl?loc=RFC&letsgo=793 &type=ftp&file_format=pdf).
PC PASO A PASO N 20
Pgina 21
Bueno, bueno, la cosa ya va siendo ms seria, eh? ;-) Que nadie se asuste! Ya veris como en un momento comprendemos todo lo que hay en esa imagen aparentemente tan complicada. Vamos a ir viendo campo por campo toda la cabecera, para luego entrar en detalle en el tamao de los campos a nivel de bit (ya en el prximo artculo).
Por un lado, identifica unvocamente a cada paquete dentro de una conexin, y dentro de un margen de tiempo. Es este nmero el que nos permite detectar si un paquete nos llega duplicado. Durante un margen de tiempo (que depende del flujo de los datos y, por tanto, tambin del ancho de banda) tenemos la garanta de que en una determinada conexin virtual no habr dos paquetes diferentes con el mismo nmero de secuencia. Por ejemplo, en una conexin de 2Mbps, este margen de tiempo es de unas 4 horas y media, mientras que en una conexin de 100Mbps el margen es de 54 minutos. Por qu este margen de tiempo vara en funcin del flujo de datos? Pues lo comprenderemos en cuanto veamos qu es exactamente el nmero de secuencia. Y es que el nmero de secuencia es mucho ms que un mero identificador de paquetes. El valor del nmero de secuencia no es aleatorio, si no que tiene un significado muy concreto. El nmero de secuencia es el orden en bytes que ocupan los datos contenidos en el paquete, dentro de una sesin . Es decir, supongamos que el primer paquete enviado una vez establecida una conexin tiene un nmero de secuencia 0, y el paquete contiene 200 bytes de datos. El siguiente paquete que se enviase tendra que tener 200 como nmero de secuencia, ya que el primer paquete contena los bytes del 0 al 199 y, por tanto, el orden que ocupan los datos del segundo paquete es el siguiente: 200. Por qu decamos entonces que el nmero de secuencia identifica unvocamente un paquete dentro de un margen de tiempo? Porque el nmero de
PC PASO A PASO N 20
4.1. Puerto de origen

Este campo tiene el mismo significado que en el caso de UDP. En TCP es de especial importancia, porque es condicin necesaria (aunque no suficiente) para identificar una conexin virtual.
4.2. Puerto de destino

Tambin tiene el mismo significado que en UDP, y tambin es condicin necesaria (aunque no suficiente) para identificar una conexin virtual. Es decir, si nos llega un paquete que coincide en IP de origen, IP de destino, Puerto de origen, y nmero de secuencia, con los de una conexin virtual, pero no coincide el puerto de destino, entonces ese paquete no se puede considerar perteneciente a esa conexin virtual. Lo mismo ocurre si el que cambia es el puerto de origen.
4.3. Nmero de Secuencia

Aqu empieza lo ms divertido, ya que este campo es uno de los que ms nos dar que hablar. El nmero de secuencia es un nmero bastante grande (32 bits) que tiene varias funciones.
Pgina 22
secuencia es siempre creciente, por lo que un paquete posterior a otro siempre tendr un nmero de secuencia mayor. Claro que... ser mayor en mdulo 32. Esto significa que, una vez que el nmero de secuencia valga 232 1, es decir, el mayor nmero que se puede representar con 32 bits, el prximo nmero de secuencia utilizado ser 0, es decir, se dar la vuelta al marcador. Por supuesto, cunto se tarda en dar la vuelta al marcador depende directamente de cuntos datos se enven, y en cuanto tiempo.
quedara: 0 1 + 300 = 299. Por tanto, 299 sera el nmero de secuencia del prximo paquete. En realidad, el nmero de secuencia no tiene por qu comenzar en cero. El principal motivo es que si todas las conexiones empezasen en 0, no se podran reutilizar las conexiones. Ya a estas alturas, habiendo visto todos los campos relevantes, podemos afirmar que lo que identifica una conexin son estos 5 parmetros: ip de origen, ip de destino, puerto de origen, puerto de destino, y nmero de secuencia . Imaginemos que, por ejemplo, nuestro software de correo electrnico est configurado para comprobar si tenemos mensajes nuevos cada 30 segundos. El programa tendr que establecer una conexin TCP/IP con el puerto 110 (puerto de POP3) de un servidor POP3 cada 5 segundos. En este caso, 4 de los parmetros que identifican la conexin podran ser iguales: puerto de origen, puerto de destino, ip de origen, e ip de destino. Digo que podran porque el puerto de origen se podra cambiar de una conexin a otra (el resto de parmetros no se podran cambiar de ninguna manera), aunque esto en muchos casos no ser posible o conveniente. Por tanto, el nico parmetro con el que podemos jugar para poder establecer nuevas conexiones similares sin que se confunda la nueva con una vieja que ya se cerr, es el nmero de secuencia. Si cada vez que el programa de correo se reconecta al servidor POP3 utilizamos el mismo nmero de secuencia para comenzar la sesin (por ejemplo, 0), si
Pgina 23
En la imagen podemos ver reflejado esto. Como vemos, el primer nmero de secuencia es 0, y el primer paquete contiene 200 bytes de datos. Por tanto, el segundo paquete tendr nmero de secuencia 200. Este paquete contiene 12345 bytes de datos, por lo que el prximo paquete tendr como nmero de secuencia: 200 (nmero de secuencia anterior) + 12345 = 15345. As contina la sesin, hasta que un paquete tiene como nmero de secuencia 232 1, y contiene 300 bytes de datos. En teora, el prximo nmero de secuencia tendra que ser 232 1 + 300 pero, como solo contamos con 32 bits para representar este nmero, tendremos que dar la vuelta al marcador, es decir, convertir el 232 en un 0, por lo que nos
PC PASO A PASO N 20
llegase un paquete muy retrasado del servidor de correo de una conexin anterior (de los 5 segundos anteriores), no habra forma de saber si este paquete perteneca a la sesin anterior, o a la nueva sesin. Una forma sencilla de evitar esto es no utilizar siempre el mismo nmero de secuencia para comenzar una sesin, si no ir utilizando nmeros de secuencia cada vez mayores. Veamos un ejemplo de esto a partir de la siguiente figura.
ms de lo normal en llegar a B. Como A ya ha enviado lo que quera, cierra la conexin, a pesar de que todava no ha recibido la confirmacin de que B recibi el paquete Seq = 200. Inmediatamente despus, A decide establecer una nueva conexin con B para enviarle otros datos. Comienza enviando un primer paquete con Seq = 0, al cual responde B con su confirmacin de recepcin. Para entonces, ya ha llegado a B el paquete Seq = 200 de la anterior conexin, por lo que construye su paquete de confirmacin. Pero la mala suerte se confabula contra estas dos mquinas, y justo en ese instante A enva un nuevo paquete, que tiene tambin nmero de secuencia 200. Inmediatamente B enva la confirmacin de recepcin del paquete Seq = 200 de la anterior conexin. Qu ocurre a partir de aqu? 1.- Desde el punto de vista de A, B ha recibido correctamente el ltimo paquete, por lo que contina transmitiendo nuevos paquetes, borrando de su memoria el paquete Seq = 200, por lo que nunca lo reenviar. 2.- Desde el punto de vista de B, acaba de recibir un nuevo paquete Seq = 200. Como B ya haba recibido un paquete Seq = 200, interpreta que ste paquete es un reenvo del anterior, por lo que lo desecha. Por tanto, ni B recoge el paquete Seq = 200, ni A se entera de lo que ha pasado. En realidad las cosas no son exactamente como las pinto, pero ya iremos viendo ms adelante cmo es todo esto realmente.
PC PASO A PASO N 20
En primer lugar, la mquina A abre una conexin con la mquina B. Una vez abierta la conexin, A empieza a transmitir sus datos, empezando por un paquete con nmero de secuencia Seq = 0. B lo recibe y devuelve su confirmacin de recepcin. A continuacin, A transmite un nuevo paquete, con nmero de secuencia 200 (por tanto, el primer paquete tena que contener 200 bytes de datos). Por algn azar del destino, este paquete va a tardar
Pgina 24
Por supuesto, el nmero de secuencia no sirve slo para detectar paquetes duplicados, o para diferenciar unas conexiones de otras, si no tambin para poder ordenar los paquetes. Como el nmero de secuencia representa el orden exacto en bytes de los datos, es imposible confundirse a la hora de unir los datos en el orden correcto.
4.4. Nmero de confirmacin

Este campo es el que se utiliza para hacer las confirmaciones de recepcin de las que tanto hemos hablado. Su funcionamiento es muy similar al del nmero de secuencia, porque en realidad tambin representa un orden en bytes de los datos. Lo que se enva en el nmero de confirmacin es otro nmero de 32 bytes que indica cul es el prximo byte que estamos esperando recibir. Este campo slo tiene significado si el paquete tiene activo el flag ACK, pero eso ya lo veremos ms adelante.
4.5. Comienzo de datos

Este campo no era necesario en el caso de UDP, ya que la cabecera UDP tiene un tamao fijo de 8 bytes. En cambio, la cabecera TCP puede tener un tamao variable, tal y como veremos ms adelante, por lo que es necesario indicar a partir de qu punto comienzan los datos y termina la cabecera. Este punto de comienzo no se expresa en bytes, como podramos esperar, si no en palabras de 32 bits. Si nos fijamos en la cabecera, veremos que est estructurada en filas, cada una de las cuales mide 32 bits. La primera fila contiene los puertos de origen y destino, la segunda el nmero de secuencia, la tercera el nmero de confirmacin, etc. El valor ms habitual para este campo es 5, que equivale a 20 bytes de cabecera, es decir, lo mnimo que puede ocupar la cabecera TCP.
Pgina 25
Si nuestro compaero en una conexin nos enva un paquete con nmero de secuencia 2000, y el paquete contiene 350 bytes de datos, el prximo nmero de secuencia sera el 2350. Si queremos confirmar que hemos recibido el paquete con nmero de secuencia 2000, tendremos que enviar en nuestro paquete de respuesta un nmero de confirmacin que valga 2350, diciendo as: Ya puedes enviarme el paquete 2350. He recibido todo bien hasta aqu. Vamos a ver la misma figura que pusimos al hablar sobre el nmero de secuencia, pero esta vez incluyendo los nmeros de confirmacin.
PC PASO A PASO N 20
4.6. Espacio reservado

Despus del campo comienzo de datos, ve m o s q u e h ay u n o e n e l q u e simplemente pone 0. Este es un espacio reservado de 4 bits, que hay que dejar a cero, sin ms.
Imaginemos que queremos ver el contenido de un archivo remoto, por ejemplo en Linux, y hacemos un cat del archivo: cat archivo.txt
4.7. FLAGS (URG, ACK, PSH, RST, SYN, FIN)

Aqu tenemos tambin un asunto que va a dar mucho que hablar. Los flags son una serie de indicadores de control, de un nico bit cada uno, con diferentes funciones que detallo a continuacin.
Qu no sabis...
Qu no sabis lo que es cat? Pues tendris que repasar los artculos ya publicados sobre Linux de esta misma revista. ;-) y si no, consulta el google (www.google.com).
4.7.1. Flag URG (Urgent)

Cuando este flag est activo (vale 1, en lugar de 0), estamos indicando que el paquete contiene datos urgentes. La especificacin de TCP no detalla qu se debe hacer exactamente ante unos datos urgentes, pero lo normal es atenderlos con mxima prioridad. Si, por ejemplo, estamos procesando datos anteriores, y nos llega un paquete con datos urgentes, normalmente aplazaremos el procesamiento de los datos anteriores para prestar toda nuestra atencin a los datos urgentes. Y para qu pueden servir los datos urgentes? No es habitual encontrarlos, pero un claro ejemplo es cuando deseamos abortar alguna accin. Por ejemplo, si alguna vez habis conectado por Telnet con un sistema remoto (el propio servicio de Telnet del puerto 23, no los experimentos raros que hacamos en la serie RAW ;-) sabris que con la combinacin de teclas CONTROL- C se puede abortar cualquier accin.
Pgina 26
El caso es que, despus de hacer el cat, descubrimos que el archivo es mucho ms largo de lo que esperbamos y, para colmo, no nos interesa. Pulsamos CONTROL-C y el listado del archivo se aborta sin necesidad de esperar a que el archivo termine de mostrarse entero. El paquete que hemos enviado a la mquina remota conteniendo la orden de abortar el listado, tiene un flag URG activo. Si no existiese este mecanismo, probablemente la mquina remota seguira enfrascada en su asunto inmediato, que es mostrar el listado del archivo, y no habra hecho caso a nuestro CONTROLC hasta que no hubiera terminado con lo suyo. Para garantizar una mayor efectividad del flag URG hay que combinarlo con el flag PSH , que veremos ms adelante.
4.7.2. Flag ACK (Acknowledge)

Cuando este flag est activo (vale 1, en lugar de 0) significa que nuestro paquete, aparte de los datos propios que pueda c o n t e n e r, c o n t i e n e a d e m s u n a
PC PASO A PASO N 20
confirmacin de respuesta a los paquetes que est enviando el otro extremo de la conexin. Por tanto, el campo nmero de confirmacin no tiene significado a no ser que est activo este flag.
4.7.3.
Flag
PSH
(Push)
En la imagen podemos ver cmo los paquetes sin flag PSH se van encolando en el buffer de transmisin. Cuando el sistema construye el ltimo paquete (el paquete Seq = 300), ya puede comenzar el envo del archivo. Por tanto, en el ltimo paquete incluye el flag PSH. A partir del instante en que hemos metido en el buffer el paquete con flag PSH, el sistema ir enviando uno tras otro los paquetes a travs del cuello de botella que supone el canal de salida. Se trata de un cuello de botella porque por l slo puede pasar un nico paquete en cada instante, por lo que los paquetes tendrn que ir envindose de uno en uno segn el orden en que fueron ubicados en el buffer de transmisin. Al tratarse de una cola, el primero en llegar ser el primero en salir (lo que se llama una cola FIFO), por lo que primero saldr el paquete con Seq = 0. El ltimo paquete en salir ser el que tiene Seq = 300, que es precisamente el que lleva el flag PSH. En la siguiente imagen vemos todo esto desde el punto de vista del receptor.
Cuando este flag est activo (vale 1, en lugar de 0) indicamos a nuestro propio sistema, y al sistema remoto con el que estamos conectados, que deben vaciar sus buffers de transmisin y recepcin... Creo que ha llegado el momento de hablar sobre los buffers de transmisin y recepcin. :-m En todo sistema TCP tiene que haber dos pequeas memorias, o buffers: una para transmisin, y otra para recepcin. Estas memorias son unas colas de paquetes en las que se van almacenando los paquetes que hay que procesar en espera del momento adecuado. Por ejemplo, supongamos que una aplicacin que corre en nuestro sistema desea enviar un archivo, que ser partido en 4 paquetes TCP. A pesar de que nuestra aplicacin lance la orden de enviar el archivo en un slo instante, nuestro sistema no podr enviar de golpe los 4 paquetes. Por tanto, tendr que construir los paquetes, y luego ponerlos en una cola para que se vayan enviando uno tras otro. Si el sistema pudiera enviar los 4 paquetes a la vez no habra necesidad de tener ninguna cola, pero en la prctica, como en cualquier cola, slo se puede pasar de uno en uno.
PC PASO A PASO N 20
Pgina 27
Por el canal de entrada irn llegando los paquetes uno tras otro. Se irn almacenando en el buffer de recepcin, y no sern procesados hasta que llegue el ltimo paquete, que contiene el flag PSH . Como este paquete es el que completa el archivo de 400B, para cuando llegue, el sistema receptor ya podr procesar los datos de los 4 paquetes y reconstruir el archivo original. Como decamos, el flag PSH debe combinarse con el flag URG cuando haya datos urgentes. El flag URG ser el encargado de decir al receptor que ha de atender los datos con mxima prioridad, y el flag PSH se asegurar de que el paquete no se retrase esperando en los buffers.
servidor el resto de nuestros intentos de conexin, el servidor nos responder con RST a cada nuevo intento de conexin, para que nos olvidemos de esa conexin y nos centremos en la que ya tenemos.
4.7.5. Flag SYN (Synchronization)

Cuando este flag est activo (vale 1, en lugar de 0), estamos indicando al otro extremo que deseamos establecer una nueva conexin. Este flag se utiliza nicamente al abrir una nueva conexin. Ms adelante veremos el mecanismo exacto por el que se establecen las conexiones, as como algunas cuestiones de seguridad relacionadas con este flag.
4.7.4. Flag RST (Reset)

Cuando este flag est activo (vale 1, en lugar de 0), estamos indicando al otro extremo de la conexin que algo no anda bien, ya que los datos que nos han llegado no coinciden con nuestra conexin, por lo que se ha perdido la sincronizacin entre ambas partes. Ante cualquier campo incorrecto que recibamos (nmeros de secuencia invlidos, o flags no esperados) tendremos que responder con un paquete con este flag activo, para que el otro extremo se entere del problema, y se cierre la conexin para re-sincronizar ambas partes. Un uso tpico de este flag es cuando estamos intentando conectar con un servidor, enviando varios paquetes para establecer la conexin, y al final uno de ellos tiene xito. Si despus de ese paquete de conexin siguen llegando al
Pgina 28
4.7.6. Flag FIN (Finish)

Cuando este flag est activo (vale 1, en lugar de 0), indicamos al otro extremo de la conexin de que, por lo que a nosotros respecta, la conexin ya se puede cerrar. Normalmente, una vez que enviemos nuestro propio FIN , tendremos que esperar a que nuestro compaero nos enve el suyo. Una vez puestos los dos de acuerdo en que no hay ms que hablar, se puede cerrar la conexin pacficamente. Tanto RST como FIN se utilizan para finalizar conexiones, pero la diferencia es que RST avisa de una situacin de error, mientras que FIN avisa de una terminacin sin problemas. Ante una terminacin con RST, normalmente las aplicaciones avisarn al usuario, por ejemplo con una ventana avisando que se ha perdido la conexin.
PC PASO A PASO N 20
4.8. Ventana
Este campo es el que se utiliza para llevar a cabo el control de flujo implementado en TCP. Como ya dije, el control de flujo permite evitar la congestin debida a la diferencia de velocidad (bien por capacidad de procesamiento, o bien por ancho de banda) entre ambas partes de una conexin. Una forma muy sencilla de conseguir esto es hacer que cada extremo de la conexin vaya indicando a cada momento cmo de congestionado est. La mejor forma de indicar esta medida de congestin es decir cuntos bytes vamos a ser capaces de procesar en un momento dado. Por tanto, a cada paquete le acompaa un nmero de 16 bits, que es el nmero de bytes que estamos preparados para recibir en el prximo paquete. Esto significa que, como mximo, un paquete podr contener 65536 bytes de datos, es decir, 64KB, ya que es el mximo que podemos solicitar en cada momento. Normalmente, el tamao de la ventana est relacionado con la cantidad de espacio libre que tenemos en el buffer de recepcin. Vamos a ver un ejemplo.
En primer lugar, la mquina A enva un paquete de 1000 Bytes, con nmero de secuencia 0. La mquina B lo recibe y procesa correctamente, y enva su confirmacin de recepcin, indicando que la mquina A puede continuar enviando a partir del byte 1000 (Ack=1000). Adems, le indica que est preparada para recibir otros 1000 bytes ms. Si hacemos cuentas, en realidad lo que est diciendo la mquina B es que est preparada para recibir los bytes del 1000 al 1999. La mquina A contina transmitiendo, y lo hace esta vez con 1000 bytes ms de datos, empezando, por supuesto, por el nmero de secuencia 1000. La mquina B tambin los recibe sin problemas, pero se est empezando a agobiar un poco, por lo que avisa en su confirmacin de que el prximo paquete no podr ser tan grande y, como mucho, tendr que ser de 500 bytes nada ms. La mquina A, en cambio, no ha recibido a tiempo la nueva ventana, y ha seguido enviando los paquetes al ritmo que llevaba anteriormente. Por tanto, el prximo paquete (Seq=2000) contiene tambin 1000 bytes de datos, a pesar de que la nueva ventana de B admite slo 500 bytes. Justo despus de enviar este paquete demasiado grande, la mquina A recibe ya el aviso de B de que se est congestionando, por lo que decide esperar a ver cmo se las apaa su compaero. Cuando B ha podido procesar unos cuantos datos, avisa a A de que puede seguir enviando, aunque slo ha procesado 500 bytes de los 1000 que le envi y,
PC PASO A PASO N 20
Pgina 29
adems, el prximo paquete tendr que ser como mximo de 250 bytes. En respuesta, A enva un nuevo paquete, comenzando en el byte 2500, y conteniendo tan slo 250 bytes. Todo esto es muy bonito, A y B son muy amigos, y A le va enviando a B las cosas poco a poco cuando ste se agobia. Pero esto en realidad no es una idea muy buena. Si A va haciendo caso a B segn ste le vaya diciendo lo que puede manejar, y B va avisando a A segn vaya liberando hueco en su buffer de recepcin, los paquetes que se transmitan irn siendo cada vez ms pequeos. En el peor de los casos, podra llegar a ser 0 la ventana de B, y en el instante en que hiciese hueco para un msero byte, avisar a A, por lo que A le enviara un paquete con un nico byte de datos. Esto dara lugar a una transferencia muy poco efectiva de los datos, donde muchos de los paquetes seran de un tamao ridculo. Por tanto, es aconsejable no ir ajustndose literalmente al tamao de la ventana, si no dejar unos pequeos mrgenes. Por ejemplo, cuando se detecte que la ventana va decreciendo por momentos, lo mejor es esperar un tiempo para dejar que la ventana vuelva a recuperar toda su capacidad, y continuar entonces la transmisin. Si fusemos con prisas, empendonos en enviar ms y ms datos, la reduccin de tamao de la ventana sera cada vez mayor, y la transferencia cada vez menos eficiente. En el caso de que la ventana llegue a ser cero, la responsabilidad del receptor (el que se ha congestionado) es avisar cuando su ventana se recupere, con un
Pgina 30
mensaje (vaco si hace falta) cuya nica finalidad sea precisamente avisar del cambio de la ventana. Por otra parte, la responsabilidad del emisor (el que ha congestionado al otro) es dejar de enviar ms datos, y esperar un tiempo prudencial para continuar la transmisin pasados unos dos minutos, si es que el receptor no ha enviado una nueva ventana antes.
4.9. Suma de comprobacin

Al igual que en el caso de UDP, la suma de comprobacin se calcula mediante una operacin de aritmtica binaria (suma en complemento a uno de 16 bits) que se realiza sobre una cabecera especial que contiene los datos ms relevantes. Cada vez que se recibe un paquete TCP, hay que realizar esta misma operacin con los datos recibidos, y comparar el nmero obtenido con el campo suma de comprobacin del paquete. Si ambos nmeros no son iguales, los datos son incorrectos, y ser necesaria una retransmisin de los mismos. En ese caso, no enviaremos la confirmacin de recepcin pertinente, esperando a que el emisor decida retransmitir el paquete al ver que no les respondemos. Aunque ya lo coment en el anterior artculo, os recuerdo que tenis detallada la operacin de la suma de comprobacin en el RFC 1071, y que tenis un cdigo de ejemplo en C en la siguiente URL: http://www.netfor2.com/tcpsum.htm En este caso no tenis que realizar ninguna modificacin sobre el cdigo, ya que sirve precisamente para calcular la suma de comprobacin de TCP. La cabecera que se forma para llevar a cabo la suma de comprobacin es la siguiente:
PC PASO A PASO N 20
4.11. Opciones
Como vemos, es igual que la de UDP, slo que en este caso el protocolo es el 6, en lugar del 17. Llegamos al fin al ltimo campo de la cabecera TCP. Este campo es opcional, y es el responsable de que la cabecera TCP sea de tamao variable y, por tanto, de la necesidad del campo comienzo de datos. En realidad, slo existe una opcin definida por el estndar en el RFC de TCP, pero la cabecera se dise con previsin de incluir otras opciones. La opcin definida se utiliza nicamente al establecer una nueva conexin. Lo que indica este campo opcional es el mximo tamao de los segmentos que estamos dispuestos a recibir. Un segmento es cada una de las partes en las que se dividen los datos, por lo que nuestro compaero de conexin no debe enviarnos nunca paquetes ms grandes de lo que indiquemos con esta opcin. En el caso de que no usemos este campo opcional, nos podr enviar paquetes de cualquier tamao ajustndose, eso s, a nuestra ventana de recepcin. Y qu relacin hay entonces entre la ventana de recepcin y el tamao mximo de segmento? Pues la ventana es un parmetro dinmico, que va variando segn la congestin que hay en cada momento, mientras que el tamao mximo de segmento es una constante para toda la sesin, que se establece de antemano. Muchas veces, el tamao mximo de segmento ser menor que la ventana. Esto puede parecer absurdo, pero no es as, ya que el tener
Pgina 31
4.10. Puntero de urgencia

Cuando hablamos sobre el flag URG dijimos que serva para indicar que el paquete contiene datos urgentes. Pero, significa esto que los datos tienen que ir en un nico paquete para ellos solos? Esto podra ser poco eficiente, ya que los datos urgentes podran ser tan slo unos pocos bytes, y nos obligara a enviar paquetes casi vacos slo para poder transmitir el dato urgente. Por ejemplo, el CONTROL-C del que hablbamos, es un comando muy breve, y sera un desperdicio enviar paquetes vacos que slo llevasen ese comando. Por tanto, TCP permite combinar en un mismo paquete datos urgentes con datos no urgentes. Para conseguir esto, el campo puntero de urgencia nos indica el punto a partir del cual terminan los datos urgentes. Si, por ejemplo, nuestro paquete contiene 1000 bytes de datos, y el puntero de urgencia es 150, sabremos que los 150 primeros bytes del paquete son urgentes, y los otros 850 son datos normales. Por supuesto, esto slo tendr sentido si el flag URG est activo. Si no es as, el campo puntero de urgencia simplemente ser ignorado.
PC PASO A PASO N 20
una ventana mayor que el tamao mximo de segmento indica que tenemos recursos suficientes para recibir varios paquetes en poco tiempo. Por tanto, el tamao mximo de segmento no es til para realizar un control de flujo, si no tan slo una restriccin para el tamao mximo que pueden tener los paquetes. Pero vamos a ver cmo se indica exactamente esta opcin. Como ya hemos visto, existen dos casos: o que no indiquemos ninguna opcin , o que indiquemos el tamao mximo de segmento. En el primer caso, simplemente terminar en este punto la cabecera TCP, y comenzarn a partir de aqu los datos. Por eso, cuando hablbamos del campo comienzo de datos dijimos que el tamao mnimo de la cabecera (que es este caso) es de 20 bytes.
La opcin que hemos mencionado, la nica definida en el RFC, encaja exactamente en 32 bits, por lo que no hay que hacer ningn ajuste. El formato exacto de esta opcin lo veremos ms adelante cuando veamos las cabeceras a nivel de bits. En cambio, no slo existen las opciones definidas en el RFC 793. Podemos ver una lista de opciones TCP mantenidas, p a r a v a r i a r, p o r e l I A N A , e n : http://www.iana.org/assignments/tcpparameters Una opcin que nos podremos encontrar con facilidad de las de esa lista, es la opcin SACK, utilizada para confirmaciones selectivas ( S elective ACKnowledgment). Los detalles sobre esta opcin los tenis en el RFC 2018 (ftp://ftp.rfc-editor.org/innotes/rfc2018.txt). Si las opciones no encajan en 32 bits, habr que completar la fila con ceros. Para separar las opciones entre s se utiliza una opcin especial sin ningn efecto (NOP = No OPeration) que ocupa un nico byte. Para terminar la lista de opciones existe tambin otra opcin especial, de un nico byte, que indica que no hay mas opciones y, por tanto, una vez completada la palabra de 32 bits, vendrn a continuacin los datos del paquete. Todo esto lo veremos en ms detalle en el prximo artculo, en el cual empezaremos construyendo como ejercicio una cabecera TCP desde cero a bajo nivel, es decir, en binario puro y duro. Espero que estis preparados! ;-)
PC PASO A PASO N 20
En el segundo caso, en cambio, habr que rellenar el campo opciones de la cabecera. Y no slo eso, si no que adems hay que ajustarlo a un tamao de 32 bits, que es lo que ocupa cada fila de la cabecera TCP (en realidad, se trata del tamao de la palabra, ya que la idea de filas es slo una abstraccin para ver ms fcilmente la estructura de la cabecera).
Pgina 32
Para terminar, os incluyo aqu la cabecera TCP con los nombres originales, en ingls, por si completis este curso con alguna otra lectura, para que veis la correspondencia y no os liis.
IMPORTANTE
IMPORTANTE: Ya habr tiempo de pasar a la practica, ahora es importante que empecemos a familiarizarnos con un montn de trminos y conceptos que seguramente (para la mayora) son completamente desconocidos. No te preocupes demasiado si muchas cosas te han quedado oscuras, ya empezars a verlas claras cuando relacionemos la teora con la practica y veas la utilidad real de cada concepto explicado aqu.
Autor: PyC (LCo)
CURSO DE TCP/IP: 2
ENTREGA
TCP (TRANSMISION CONTROL PROTOCOL) parte
Este mes nos metemos de lleno en los paquetes de Internet. Crearemos un paquete desde cero, nos adentraremos en el cdigo binario y para rematar comprenderemos de una vez por todas el significado de algunos ataques ya conocidos por todos.
1. Fundamentos comunicacin digital.
de
la
esos ceros y unos de los que vamos a hablar ahora. De momento, nos quedaremos con una simplificacin de la idea de qu es exactamente un cero y un uno. Como sabemos, los datos que circulan en una red lo hacen siempre a travs de un medio fsico. Este medio, normalmente, ser un cable elctrico, pero puede ser tambin, por ejemplo, una onda de radiofrecuencia, un cable ptico, o cualquier otro medio fsico empleado en la interconexin de mquinas. Quedmonos con el caso ms comn, el del cable elctrico, aunque todo lo explicado se puede extrapolar, por supuesto, a cualquier otro medio fsico. Como es lgico, por un cable elctrico circula electricidad. La electricidad por si misma no contiene mucha informacin. Un medio de transmisin de informacin ser ms verstil cuantos ms parmetros posea. Por ejemplo, una imagen puede transmitir una gran cantidad de informacin (ya se sabe que una imagen vale ms que mil palabras), ya que posee muchsimos parmetros, como son los colores en cada punto, la iluminacin, etc. En cambio, la electricidad posee pocos parmetros propios, como pueden ser la tensin elctrica (voltaje), y la intensidad elctrica (corriente). Para colmo, estos dos parmetros estn directamente relacionados entre s (recordis la famosa ley de Ohm, o vosotros tambin suspendais fsica en el cole? Por tanto, una primera solucin intuitiva para transmitir informacin por medio de la Pgina 13
Cuando empec con el curso de TCP/IP, cuya cuarta entrega tenis ahora mismo en vuestras manos, ya os advert de que, cansado de ver una y otra vez las mismas tcnicas para explicar los conceptos en todos los libros y tutoriales, este curso pretenda ser una apuesta arriesgada, orientando la explicacin de los mismos conceptos desde un punto de vista bastante diferente. Siguiendo en esta lnea un tanto experimental, voy a dar otro nuevo paso que no he visto en ningn libro sobre TCP/IP, para tratar de que os familiaricis ms an con TCP/IP. Lo que pretendo conseguir ahora es que convirtis esos misteriosos paquetes TCP que tenis rondando ahora mismo por vuestras cabezas, en algo tangible, de carne y hueso, o ms bien debera decir de unos y ceros. Para ello, vamos a ver con un ejemplo cmo est construido exactamente un paquete TCP. Mi intencin es que despus de este ejemplo, los paquetes TCP dejen de ser al fin para vosotros unos entes tericos de los cuales conocis el funcionamiento, pero no su constitucin fsica. Por supuesto, esta constitucin fsica no podremos terminar de comprenderla hasta que lleguemos a la capa inferior de la jerarqua de capas de TCP/IP: el nivel fsico. As que habr que esperar an unos cuantos meses antes de que veamos qu son exactamente PC PASO A PASO N 21
Curso de TCP/IP - TCP (II) - Curso de TCP/IP - TCP (II) - Curso de TCP/IP - TCP (II)
electricidad sera hacer variar esos parmetros en funcin de lo que quisiramos transmitir. Por ejemplo, si queremos transmitir un nmero, podemos ajustar el voltaje del cable en relacin directa con el valor de ese nmero. Por ejemplo, para transmitir un 5 pondramos 5 voltios en el cable, y para transmitir un 7 pondramos 7 voltios en el cable. Si, en cambio, queremos transmitir el nmero 250000, ms nos vale no tocar el cablecito, a no ser que queramos seguir este curso desde el ms all (all tambin llega, desde que la revista cambi de distribuidor). Supongo que las mentes ms despiertas habrn descubierto ya aqu una de las ms destructivas tcnicas de hacking. Si algn da os encontris por un chat al <malnacido> ese que os rob la novia, basta con que le enviis un paquete que contenga un nmero tocho con ganas, como el 176874375618276543, y por su mdem circular tal tensin elctrica, que en el lugar que ocupaba su casa veris un cono atmico que ni el de Hiroshima. Bueno, antes de que se me eche alguien encima por decir semejantes estupideces, tendr que reconocer que, como es lgico, las cosas no funcionan as en la prctica. Pero no os creis que sea algo tan descabellado! Y si en lugar de una proporcin 1/1 utilizamos otra clase de proporcionalidad para transmitir los nmeros? Por ejemplo, supongamos que no queremos superar los 10 voltios y, en cambio, queremos transmitir nmeros entre 1 y 1000. Pues basta con que establezcamos el convenio de que 10 voltios equivalen al nmero 1000 y, por tanto, 5 voltios al 500, 25 voltios al 250, etc., etc. Esta solucin no slo es mucho ms realista, si no que incluso ha sido el sistema de transmisin de informacin en el que se ha basado toda la electrnica hasta que lleg la revolucin digital. Y el nombre de esto os sonar mucho, ya que a esto es a lo que se llama comunicacin ANALGICA. Pgina 14
Siempre habris escuchado el trmino analgico como opuesto al trmino digital. Vamos a ver ahora mismo en qu consisten las diferencias entre analgico y digital. Si bien la tecnologa analgica aprovecha la tensin elctrica, uno de los parmetros que caracterizan la electricidad que circula por un cable, la tecnologa digital no utiliza ninguno de los parmetros de la electricidad para transmitir la informacin. Cmo puede transmitirse la informacin entonces? Evidentemente, siempre es imprescindible la presencia de una variable que se pueda modificar convenientemente para codificar la informacin que se desea transmitir. La diferencia es que en el caso de la transmisin digital el parmetro que se utiliza para portar la informacin no es inherente a la propia electricidad, si no que es un parmetro ms sencillo: el tiempo. Evidentemente, el tiempo es siempre un parmetro fundamental en toda comunicacin, ya que es imprescindible que haya una sincronizacin temporal entre transmisor y receptor. Volviendo al caso de la transmisin analgica, pensemos por ejemplo en el caso en el que se transmitan slo nmeros del 0 al 9 y, para conseguir representar nmeros ms altos lo que se hace es transmitir cada una de sus cifras por separado (unidades, decenas, centenas, etc.). Si, por ejemplo, quisiramos t ra n s m i t i r e l n m e r o 5 2 3 , p r i m e r o transmitiramos 5 voltios, luego 2 voltios, y por ltimo 3 voltios. En la imagen podemos ver la transmisin del nmero 523 por una lnea analgica. En el eje X (el horizontal) se representa el tiempo, por ejemplo, en segundos, y en el eje Y (el vertical) se representa la tensin en voltios. PC PASO A PASO N 21
Lgicamente, es necesario establecer un convenio entre el transmisor y el receptor para saber cunto tiempo tiene que pasar entre la transmisin de cada cifra. Si no fuese as, imaginad lo que pasara si tratsemos de transmitir el nmero 5551. Si la lnea se mantiene en 5 voltios el tiempo necesario para transmitir las tres primeras cifras, cmo podr saber el receptor que en ese tiempo se han transmitido tres cincos, y no slo uno, o doce? Por tanto, ha de existir un convenio previo entre emisor y receptor que diga cada segundo se transmitir una nueva cifra. Por tanto, si pasado un segundo el voltaje no ha cambiado, significa que la siguiente cifra es igual a la anterior. Lo que hace la tecnologa digital es explotar al mximo este tipo de convenios. Pero empecemos viendo el caso ms simple de todos, que es igual al caso de la transmisin analgica. Imaginemos que queremos transmitir nmeros pero que slo puedan ser 0 o 1. En ese caso, la cosa funcionara igual: a cada segundo una nueva cifra, y no hay ms misterio. La diferencia sera que la tensin slo podra tener dos valores: 0 o 1 voltios. La diferencia viene cuando queremos transmitir nmeros ms grandes, que es cuando hay que hacer convenios raros. En realidad, estos convenios tienen poco de raro, al menos para un matemtico, ya que no es ninguna invencin, si no simplemente una aplicacin directa de las matemticas. Concretamente, lo que se aplica es la aritmtica binaria. Este convenio asigna una secuencia diferente para representar cada nmero decimal, que podemos ver en la tabla de la izquierda. PC PASO A PASO N 21
Por tanto, si queremos transmitir digitalmente el nmero 9, estos sern los voltajes que tendremos que poner en la lnea: Es decir, primero 1 voltio durante un segundo, luego 0 voltios durante dos segundos y, por ltimo, 1 voltio durante el ltimo segundo. Cmo podemos entonces transmitir un nmero de dos cifras, como por ejemplo el 12? Pues de nuevo hay que hacer otro convenio entre el emisor y el receptor y decir: cada cifra decimal va a constar de 4 cifras binarias. Por tanto, si transmitimos la secuencia: 0001 0010 (ver la tabla anterior) estaremos transmitiendo el nmero 12, segn el convenio preestablecido, tal y como vemos en la siguiente imagen.
De esta manera, a base de acuerdos entre el transmisor y el receptor, podemos transmitir cualquier informacin, con slo transmitir ceros y unos. Cul es la ventaja de transmitir slo dos valores en lugar de variar el voltaje en funcin del valor que se desea transmitir? Pues son varias las ventajas, pero la ms obvia es la gran fiabilidad de la transmisin. Imaginemos que nuestro cable lo hemos comprado en el Todo a 100 y falla ms que una escopeta de feria. Pretendemos transmitir 5 voltios y, en cambio, unas veces el cable transmite 4 voltios, otras veces 3,5, otras veces 2... Estos fallos del cable seran crticos en una transmisin analgica, ya que el voltaje se traduce directamente en la informacin que transmitimos. En cambio, la transmisin digital Pgina 15
nos permite unos mrgenes de error muy grandes. Al fin y al cabo, transmitir ceros y unos se limita tan slo a diferenciar no hay electricidad en el cable de s hay electricidad en el cable. Por tanto, podemos decir por ejemplo: si hay menos de un voltio en el cable, consideramos que es un cero. Si hay ms de un voltio, consideramos que es un uno. As, todos esos fallos del cable de Todo a 100 no afectaran a la transmisin digital, ya que incluso 2 voltios seguira siendo considerado como s hay electricidad en el cable y, por tanto, sera considerado como un 1. Son muchas otras las ventajas de lo digital frente a lo analgico, como la mayor facilidad a la hora de almacenar y procesar la informacin, pero esas ventajas no se deducen de lo explicado hasta ahora, por lo que no entraremos ahora en ms detalle. De momento, la idea con la que nos tenemos que quedar es con que a la hora de transmitir informacin, la transmisin digital tiene una mayor inmunidad al ruido y, en general, a cualquier error, que la transmisin analgica. Por supuesto, nada de lo explicado hasta ahora es en la prctica tal y como lo he contado (para aquellos que sepan de qu va el tema y estn flipando), pero mi intencin no es escribir un RFC sobre transmisin analgica vs. transmisin digital, si no tan slo explicar conceptos, aunque tenga que ser faltando a la realidad en muchas ocasiones. Lo importante es que comprendis los conceptos que subyacen a una transmisin de datos digitales, como es el caso de TCP/IP. Para los ms quisquillosos que sigan insistiendo en que las cosas no son as, y que realmente incluso las transmisiones digitales circulan de forma analgica, insisto en que no estoy tratando de explicar el nivel fsico (cosa que ya har dentro de unos cuantos artculos, y donde todo esto quedar finalmente aclarado), si no tan slo abstraerme de los detalles para explicar los conceptos bsicos. Pgina 16
Y si el mundo...
1. Muchas personas, cuando les dices que el mundo informtico

funciona con CEROS y UNOS, nunca llegan a entenderlo. Con lo sencillo que sera trabajar con el sistema decimal (0,1,2,3,4,5,6,7,8,9) e incluso con letras. Acabamos de descubrir que aplicar el sistema decimal supondra 10 niveles de voltaje en un cable elctrico, algo tcnicamente posible pero MUY CARO. Como ya hemos dicho los cables deberan ser muy buenos y los dispositivos que detectasen los cambios de voltaje deberan ser muy precisos. Pero esto es hablando del mundo analgico si nos vamos al digital la cosa se pone interesante. Hemos dicho que en el MUNDO DIGITAL solo hay dos estados, es decir, "unos" (abierto, con electricidad, iluminado) y ceros (cerrado, sin electricidad, apagado). Pero por qu? por qu el hombre ha decidido que el mundo digital solo tenga dos estados en lugar de 10? Muy sencillo, POR DINERO!!! Cmo? qu?... En el diminuto universo que conocemos, nuestro planeta, es muy sencillo (y barato) encontrar sustancias que sean capaces de tener dos estados claramente diferenciados, que puedan ser capaces de pasar de un estado a otro muy rpidamente, que lo hagan de forma barata y para colmo que sea muy fcil detectar esos estados. Al igual que una bombilla puede estar encendida o apagada y todos podemos percibirlo mirndola (luz/oscuridad) o tocndola (calor/fro), en el caso de la informtica EL DIOS ES EL SILICIO. Simplificando mucho el tema, podemos decir el silicio deja pasar la electricidad o no (ceros y unos), lo hace rapidsimamente (todos queremos tener un PC ultrarrpido) y detectar el estado ("cargado" o "descargado") es tecnolgicamente sencillo y por lo tanto barato. Y si el mundo fuese distinto? Imagina otro elemento, por ejemplo el agua. Todos conocemos tres de sus estados, el slido, el lquido y el gaseoso si el agua se pareciese al silicio (si fuese sencillo pasar de un estado a otro, lo hiciese a la velocidad del rayo y fuese sencillo detectar esos cambios de estado) nuestro ordenador estara basado en un procesador de agua y, en ese caso sera MUCHO ms potente y rpido que los que ahora tenemos basados en silicio. Qu? Cmo? S, porque tendramos un sistema de TRES estados (apagado -hielo-, neutro -lquido- y encendido -gaseoso-) PC PASO A PASO N 21
Y si el mundo fuese distinto?
en lugar de DOS estados (apagado/encendido). Eso significa que en lugar del cdigo BINARIO utilizaramos el cdigo TRINRIO (el nombre me lo acabo de inventar). Al haber tres estados en lugar de dos podramos crear convenios mucho ms optimizados, es decir, transmitir informacin de forma mucho ms optimizada y por lo tanto mucho ms rpida. Deja volar tu imaginacin si un buen da alguien encuentra (o fabrica, o trae de otra galaxia) un material parecido al silicio pero que pudiese tener 600 estados en lugar de dos bufff el mundo informtico dara un salto astronmico en velocidad de clculo. Para la humanidad sera comparable al paso de la edad de Piedra a la edad de Hierro. Actualmente, a falta de materiales nuevos los cientficos intentan utilizar elementos conocidos pero difciles de "controlar". Unos basados en dos estados y otros en multiestados por ejemplo los tomos. Al final, la orgullosa humanidad depende de los materiales que su "humilde" entorno proporciona.
los ordenadores personales, llamamos byte. Un byte es simplemente una palabra de 8 bits, es decir, de 8 cifras binarias (cero o uno). Si quisiramos representar los nmeros decimales con un byte, sta podra ser la tabla correspondiente:
2.- Codificacin binaria.

Llegados a este punto, posiblemente ya habris perdido un poco de miedo a eso de los ceros y los unos. Lo que nos queda por ver es cmo se codifica realmente la informacin en binario (utilizando tan slo ceros y unos), es decir, cules son los convenios reales de los que hemos hablado, que permiten que un transmisor y un receptor se puedan entender. Es aqu donde entra el concepto fundamental de palabra (word). La forma en que se representa la informacin depende del tamao de la palabra utilizada. En el ejemplo anterior, donde representbamos cada nmero decimal con 4 cifras binarias, es decir, con 4 bits (bit es simplemente el nombre dado a una cifra binaria, es decir, un nmero que slo puede ser un cero o un uno), tenamos una palabra de 4 bits para representar los nmeros decimales. La palabra ms comnmente utilizada en informtica es el octeto que, en el caso de PC PASO A PASO N 21
Vamos al fin a ver algo directamente relacionado con TCP. Volvamos al ltimo artculo de la revista, y repasemos la cabecera TCP. Por si no lo tenis a mano, aqu os la vuelvo a mostrar.
Como vemos, en la cabecera TCP se manejan distintos tamaos de palabra. En primer lugar, para los campos puerto origen y puerto destino contamos con 16 bits, despus, para los nmeros de secuencia y de confirmacin tenemos 32 bits, 4 bits para el campo comienzo de datos, 1 bit para cada uno de los flags, etc. Para saber cuntos valores se pueden representar con cada tamao de palabra, basta con hacer la potencia de 2 con el tamao de la palabra en bits. Es decir, con una Pgina 17
4 palabra de 4 bits podemos representar 2 = 16 valores diferentes, con una palabra de 8 8 16 bits 2 = 256 valores, con 16 bits 2 = 65536, etc. Ahora podis comprender por qu todo lo relacionado con la tecnologa digital sigue siempre estos nmeros. La memoria RAM que compras para el PC, las tarjetas de memoria para la cmara digital, la velocidad del ADSL, siempre son los mismos nmeros; 8, 16, 32, 64, 128, 256, 512, 1024, 2048... Todos esos nmeros son las diferentes potencias de 2. El caso ms sencillo es el de 1 nico bit, 1 donde tenemos 2 = 2, es decir, se pueden representar slo 2 valores con 1 bit. Estos 2 valores son, por supuesto: cero, y uno. En el caso, por ejemplo, de 3 bits, tenemos 3 2 = 8 valores diferentes, que son todas las posibles combinaciones de 3 cifras, donde cada cifra puede ser un uno o un cero, tal y como vemos en la tabla. Como vemos, no quedan ms p o s i b l e s combinaciones de ceros y unos con slo 3 cifras, y esto nos permite representar tan slo los nmeros del 0 al 7. Como ya dije antes, para un matemtico estos convenios para representar los nmeros decimales mediante cifras binarias no son ningn misterio, ya que basta con aplicar las bases de la aritmtica modular. Voy a tratar de explicar rpidamente en qu consisten estas frmulas porque, aunque al principio os puedan parecer complicadas, en realidad son realmente sencillas y, como todo, es slo cuestin de prctica el aplicarlas de forma natural.
2.1. P a s a n d o d e b i n a r i o a decimal
Vamos a ver en primer lugar cmo traducir una secuencia de ceros y unos en algo comprensible para nuestras mentes decimales. En la base decimal, que es la que nosotros utilizamos, llamamos a cada cifra de una manera diferente segn el orden que ocupa: unidades, decenas, centenas, etc. Como nos explicaron en los primeros aos del cole, para calcular un nmero a partir de su representacin decimal, tenemos que sumar las unidades a las decenas multiplicadas por diez, las centenas multiplicadas por 100, etc., etc. Es decir: 534 = 5 * 100 + 3 * 10 + 4 * 1. 2 En realidad, 100 es una potencia de 10 (10 = 100). Y por supuesto 10 tambin es una 1 potencia de 10 (10 = 10). pero tambin el 1 lo es, ya que 1 es potencia de cualquier 0 nmero, pues X = 1, donde en este caso, es X = 10, es decir, 10 elevado a cero es uno. Por tanto, el nmero 534 se puede representar 2 1 0 como: 534 = 5*10 + 3*10 + 4*10 . Esta regla se puede aplicar a cualquier otra base que no sea 10. Volvamos a la tabla anterior, y veremos que el nmero 7 se representa como 111 en base 2. Si aplicamos la frmula anterior, pero en este caso utilizando base 2, tendremos: 2 1 0 1 * 2 + 1*2 + 1*2 = 7. En efecto, se 2 1 0 cumple, ya que 2 = 4, 2 = 2, y 2 = 1, luego: 1*4 + 1*2 + 1*1 = 7. Con esta sencilla frmula de las potencias de 2 se puede convertir cualquier nmero binario a su equivalente en decimal. Por ejemplo, vamos a traducir a decimal el nmero 10011010. 7 Empezamos aplicando la frmula: 1*2 + 6 5 4 3 2 1 0*2 + 0*2 + 1*2 + 1*2 + 0*2 + 1*2 0 + 0*2 . Ahora, sabiendo los valores de cada potencia de dos (cualquier geek que se precie tiene que conocer como mnimo todas las PC PASO A PASO N 21
Pgina 18
potencias de 2 con exponentes de 0 a 16), podemos traducir esa frmula en: 1*128 + 0*64 + 0*32 + 1*16 + 1*8 + 0*4 + 1*2 + 0*1. Es decir, nos queda la siguiente suma: 128 + 16 + 8 + 2 = 154. Por tanto, el nmero binario 10011010 representa al nmero 154 en decimal. Por si queris practicar, os dejo como ejercicio algunos nmeros ms, con su traduccin, para que lo comprobis vosotros mismos: 10110101 = 181 00111100 = 60 111010001010101010100101 = 15248037
Pero nosotros no nos conformamos con hacer las cosas, si no que nuestro autntico inters es el saber cmo se hacen. As que os explico rpidamente un algoritmo para convertir cualquier nmero decimal a binario. Usemos para el ejemplo el nmero 137. El proceso a seguir ser ir dividiendo el nmero (en este caso 137) por 2 y, en cada divisin, quedarnos con el resto de la divisin (que slo podr ser cero o uno). Ahora te quedar claro. El resultado de la primera divisin (llamado cociente, en verde) es 68, y el resto (en rojo) es 1. Este 1 ser el bit menos significativo, es decir, la cifra binaria que est a la derecha del todo. Continuamos el proceso con el nuevo cociente que hemos obtenido: Ahora hemos obtenido un 0, que ser la siguiente cifra binaria. Continuamos el proceso con el nuevo cociente, 34: 3 4 / 2 17 / 2 8 / 2 = 4 / 2 = 2 / 2 = 1, = 1 7 , con re st o 0. = 8, con resto 1. 4, con resto 0. 2, con resto 0. con resto 0.
2.2. Pasando de decimal a binario.

Aqu la cosa ya se pone ms chunga. Aun as, jurara que esto ya lo expliqu en alguno de mis artculos. Hay varios trucos para convertir de decimal a binario. El ms sencillo, por supuesto, es meter el nmero en la calculadora de windows, y luego pinchar en donde pone BIN para que lo pase automticamente, jeje.
Esta ltima operacin (en azul) es fundamental, ya que el bit ms significativo, es decir, el que hay ms a la izquierda, ser el ltimo cociente, es decir 2/2 = 1. Por tanto, el nmero 137 en binario nos quedar: 1 0 0 0 1 0 0 1.
Para que...
Para que a nadie se le ocurra enviar un mail diciendo que la calculadora de Windows no puede hacer eso, venga, lo explicamos muy rpido. Abre la calculadora, Menu Ver y pulsa sobre Cientfica. Ya est Ahora introduce cualquier nmero y pulsa sobre Bin PC PASO A PASO N 21
Si tienes...
Si tienes inters en avanzar por tu cuanta en clculo binario, hay miles de pginas en Internet que te lo explican perfectamente y por supuesto de forma gratuita. Busca en www.google.com y avanza tanto como quieras Pgina 19
Construyendo un paquete TCP desde cero.

Ya podemos ponernos manos a la obra con el tema que nos ocupa, que son los paquetes TCP. Vamos a recordar la cabecera TCP (volved atrs un poco para ver la imagen), y a ir campo por campo construyendo el paquete. Vamos a poner como ejemplo, el primer paquete que se enva cuando queremos establecer una conexin con un servidor de FTP. En primer lugar, tenemos que conocer los puertos de origen y de destino (los dos primeros campos de la cabecera TCP). El puerto de destino ser el 21 , que es el asignado por el estndar al servicio de FTP (aunque bien sabris muchos de vosotros que no siempre se usa este puerto, como en el caso de los dumps, donde se suelen usar otros puertos menos sospechosos). El puerto de origen ser un puerto aleatorio asignado por el sistema operativo a la hora de abrir el socket, es decir, la estructura utilizada por el sistema para establecer la nueva conexin TCP/IP. Supongamos que el sistema nos ha asignado el puerto 1345 como puerto de origen. Ya tenemos los datos necesarios para rellenar la primera fila de la cabecera TCP. En primer lugar, tenemos que convertir el nmero 1345 en su equivalente binario, y lo mismo con el nmero 21. Aplicando el algoritmo explicado en el punto anterior, obtenemos: 1345 = 10101000001 21 = 10101 Para construir la primera fila de la cabecera TCP tenemos que concatenar el puerto origen con el puerto destino, por lo que quedara: 10101000001 10101. Tenemos, por tanto, que nuestra primera fila consta de 16 bits... pero... no puede ser, si habamos quedado en que cada fila de la cabecera TCP eran 32 bits.
El problema es que no hemos ajustado cada campo a su tamao de palabra. El tamao de palabra de cada uno de estos dos campos es de 16 bits, por lo que cada uno de los dos nmeros obtenidos tiene que ser representado con 16 cifras binarias. Para ello, habr que poner el suficiente nmero de ceros a la izquierda, para rellenar las 16 cifras. As, nos quedar: 1345 = 0000010101000001 21 = 0000000000010101 Ahora ya si que podemos concatenar ambos para conseguir la primera fila de la cabecera: 00000101010000010000000000010101 Como experimento, probad a convertir este nmero en su equivalente decimal. El resultado es 88145941. Y qu nos dice este nmero? Pues absolutamente nada, ya que lo importante a la hora de traducir un nmero de una base a otra no es slo la secuencia de cifras, si no tambin el cmo se agrupen estas. Si agrupamos esta secuencia en grupos de 16, entonces si que tendr un sentido, pero si la agrupamos en una nica secuencia de 32 bits, el nmero resultante no tiene ningn inters para nosotros. Por tanto, es absolutamente imprescindible conocer el tamao de las palabras. Vamos ahora con la segunda fila de la cabecera. Como vemos, ahora nos toca el campo nmero de secuencia. Este nmero tambin ser asignado por el sistema operativo (recordemos del artculo anterior que no conviene que sea 0 cada vez que se establece una nueva conexin). En nuestro ejemplo el sistema nos asignar el nmero 21423994. Lo convertimos a binario, y nos da el nmero: 1010001101110011101111010. Este nmero es de 25 bits, por lo que habr que poner 7 ceros a su izquierda, para completar los 32 bits de la palabra que corresponde a este campo. Por tanto, la segunda fila de nuestra cabecera TCP ser: 00000001010001101110011101111010
Pgina 20
PC PASO A PASO N 21
En este caso, el nmero completo de 32 cifras s que tiene significado para nosotros, ya que el tamao de la palabra es precisamente de 32 bits. La tercera fila corresponde al campo nmero de confirmacin. En nuestro caso tiene que ser cero, ya que es una conexin que an no se ha establecido, por lo que el primer paquete no llevar confirmacin de otro paquete anterior. Para representar el 0 con 32 bits, basta con meter 32 ceros. 00000000000000000000000000000000 Ahora nos toca el campo comienzo de datos. Como ya vimos, el valor ms habitual para este campo es 5, en el caso de que no haya ninguna opcin. Pero nosotros vamos a incluir una opcin, que ocupar 32 bits, como veremos ms adelante. Como el campo Comienzo de datos indica el nmero de palabras de 32 bits que ocupa la cabecera TCP, al tener una palabra ms para la opcin, tendr que ser 6, es decir: 110. Como el campo tiene una palabra de 4 bits, aadimos un cero a la izquierda: 0110. A continuacin, la cabecera TCP tiene un campo vaco de 6 bits, que hay que rellenar con ceros: 000000. Por tanto, de momento esta fila de la cabecera nos va quedando: 0110000000. Ahora le toca el turno a los flags. Como vimos en el artculo anterior, siempre que se desee establecer una nueva conexin el paquete ha de tener activado su flag SYN. El resto de flags estarn desactivados. Es decir, ste ser el valor que tomarn todos los flags: URG = 0 ACK = 0 PSH = 0 RST = 0 SYN = 1 FIN = 0 Si los colocamos todos juntitos en su orden nos quedar: 000010. PC PASO A PASO N 21
Esto habr que concatenarlo a lo que llevbamos ya construido de esta fila, por lo que nos quedara: 0110000000000010 Vamos ahora con el campo tamao de la ventana. Un valor tpico es, por ejemplo, 8192. Este nmero es una potencia de 2, 13 concretamente 2 . Por tanto, la traduccin a binario es instantnea. Basta con poner 13 ceros a la derecha, y poner un nico 1 a la izquierda del todo: 10000000000000. Esto nos da un nmero de 14 cifras, por lo que tenemos que ajustarlo al tamao de la palabra de 16 bits con dos ceros a la izquierda: 0010000000000000. Por tanto, finalmente, la cuarta fila de la cabecera TCP nos quedar: 01100000000000100010000000000000 El prximo campo es el campo suma de comprobacin, y es el que ms quebraderos de cabeza nos va a dar. Si habis seguido el resto del curso, habris visto que hasta ahora he eludido un poco el tema, dndoos slo una URL donde tenais un cdigo en C ya hecho para calcular automticamente los checksums (sumas de comprobacin). Si lo hice as hasta ahora era porque saba que ms adelante llegara el momento de enfrentarse cara a cara con los checksums, y ese momento ya ha llegado. Quiz os estaris preguntando, y por qu hay que enfrentarse al checksum si tenemos ya un cdigo que nos lo calcula? Para qu sirven todas estas vueltas y revueltas que estoy dando a los paquetes TCP cuando bastara con conocer lo necesario para poder manejarlos? Creo que es importante que hablemos aqu acerca del significado original de la palabra HACK, que forma parte del nombre de esta revista, y que justifica el hecho de que profundicemos hasta el ms mnimo detalle en lo que explicamos. Pgina 21
El trmino Hacker ha sido muy desvirtuado con el paso del tiempo. Originalmente, un hacker era una persona cuya pasin era conocer el funcionamiento de las cosas. Para las personas normales una mquina es slo una herramienta que se utiliza para algn fin concreto. En cambio, un hacker no se conforma slo con usar las mquinas, si no que adems ansa conocer su funcionamiento interno. Hace aos, se llamaba hackers a los grandes programadores, a los gurs de cualquier campo de la informtica, y a toda esa clase de chiflados (a los cuales aspiro orgullosamente a pertenecer). Posteriormente, los medios de comunicacin tergiversaron todo, y dieron a la palabra hacker el significado que antiguamente tena la palabra cracker, y despus estos trminos han seguido evolucionando hasta el punto actual, en el cual hay mil y una definiciones para cada uno de los trminos. La cuestin es que si realmente queris ser hackers, de los de toda la vida, vuestra pasin debe ser conocer hasta el mnimo detalle de cmo funcionan las cosas, y no slo saber manejarlas sin ms. Un to que dedique a entrar en sitios donde tericamente le estaba prohibido el paso, ser un hacker slo si su motivacin para hacerlo sea explorar el funcionamiento de los sistemas, en caso contrario, su calificativo ms apropiado ser
lamer, script kiddie, o el que ms os guste.
Por ltimo, tenemos el campo DATOS. Como el paquete es slo para establecer una conexin, no habr ningn dato, por lo que este campo estar en blanco (ya no con ceros, si no que directamente no habr nada ). Pero... un momento! Si habamos dicho que bamos a meter una opcin! Entonces el campo DATOS no ser el ltimo, si no que tendremos antes el campo de opciones TCP. Para el caso nos va a dar igual, porque al fin y al cabo no hay campo de DATOS, as que en cualquier caso el campo opciones ira inmediatamente despus del campo puntero de urgencia. La opcin que vamos a incluir es la nica definida en el RFC de TCP, aunque ya vimos que existen muchas ms: Maximum Segment Size (MSS). Todas las opciones empiezan con un byte que indica el tipo de opcin. En nuestro caso, el cdigo para la opcin MSS es el 2, es decir: 00000010. En el caso de la opcin MSS, el siguiente byte contendr la longitud en bytes de la opcin que, contando con los dos primeros bytes que ya hemos mencionado (el que indica el cdigo, y el que indica la longitud) ser siempre 4. Por tanto, el segundo byte de la opcin MSS ser siempre fijo: 00000100. Por ltimo, los otros dos bytes que completaran la fila de 32 bits sern los que contengan el dato que queremos transmitir: el tamao mximo de segmento . Si, por ejemplo, queremos un tamao mximo de segmento de 1460 bytes, codificaremos este valor en 16 bits: 0000010110110100. Por tanto, toda la fila de 32 bits para la opcin MSS nos quedara: 00000010000001000000010110110100.
Pero bueno, ya he vuelto a salirme del tema... estbamos con el checksum. Pues me temo que de momento tenemos que dejar este punto en blanco, porque para calcular el checksum tenemos que tener terminada el resto de la cabecera, as que vamos a ver antes el resto de campos, y luego volvemos atrs sobre este punto. El siguiente campo es el puntero de urgencia. Como el flag URG no est activo, este campo puede ser 0. Como son 16 bits, tendremos aqu: 0000000000000000 . Pgina 22
Calculando la suma de comprobacin (checksum).

Ya podemos volver atrs un poco y calcular el ltimo campo que nos falta para completar PC PASO A PASO N 21
la cabecera TCP de nuestro paquete. El primer paso a seguir es coger todo lo que tenemos hasta ahora, y agruparlo en palabras de 16 bits. Es decir, partimos de todos estos chorizos binarios:
0000 0101 0100 0001 = puerto de origen 0000 0000 0001 0101 = puerto de destino 0000 0001 0100 0110 = primeros 16 bits del nmero de secuencia 1110 0111 0111 1010 = ltimos 16 bits del nmero de secuencia 0000 0000 0000 0000 = primeros 16 bits del nmero de confirmacin 0000 0000 0000 0000 = ltimos 16 bits del nmero de confirmacin 0110 0000 0000 0010 = comienzo de datos, y flags 0010 0000 0000 0000 = tamao de la ventana 0000 0000 0000 0000 = puntero de urgencia 0000 0010 0000 0100 = cdigo y longitud de la opcin MSS 0000 0101 1011 0100 = opcin MSS
hay en la cabecera TCP, y todos los bytes de DATOS. Como en nuestro paquete no hay datos, bastar con contar los bytes (grupos de 8 bits) que ocupa la cabecera. Cada fila de la cabecera son 4 bytes (32 / 8 = 4), y tenemos un total de 6 filas, por lo que el tamao de paquete ser de 6 * 4 = 24. Ahora tenemos que pasar todo esto a binario:
IP de origen = 1100 0000 . 1010 1000 . 0000 0001 . 0000 0001 IP de destino = 1000 0010 . 1100 1110 . 0000 0001 . 0000 0101 Protocolo = 0000000000000110 Tamao de paquete = 0000000000011000
Por si todas estas ristras de ceros y unos os parecen pocas, todava tenemos que aadir unas cuantas ms, y es aqu cuando entra en juego esa pequea cabecera de la que os habl que se utilizaba a la hora de calcular el checksum. Recordemos esta cabecera:
Lo que hay que hacer ahora con todos estos chorizos binarios es simplemente sumarlos (de ah el nombre de suma de comprobacin). El problema es que, si no tenis prctica, sumar en binario os puede resultar complicado. Sera ya demasiado explicaros ahora toda la aritmtica binaria, as que eso os lo dejo como ejercicio para que lo estudiis por vuestra cuenta (www.google.com o utiliza la calculadora de Windows). Lo que voy a hacer yo es pasar todo esto a hexadecimal para manejar menos cifras engorrosas. Lo que me queda al final es todo esto: C0A8 + 0101 + 82CE + 0105 + 0006 + 0018 = 1459A Este primer resultado es la suma de toda la pseudocabecera de checksum que acabamos de calcular. Ahora hay que hacer otra suma, pero con todos los chorizos que sacamos antes, de la propia cabecera TCP: 0541 + 0015 + 0146 + E77A + 0000 + 0000 + 6002 + 2000 + 0000 + 0204 + 05B4 = 175D0. Ahora slo tenemos dos nmeros, que tendremos que sumar a su vez: 1459A + 175D0 = 2BB6A Este no es todava el resultado, entre otros motivos porque el checksum ha de ocupar Pgina 23
En primer lugar, necesitamos la IP de origen. Supongamos que tenemos un router ADSL que nos conecta con Internet, por lo que nuestra IP ser una IP de red local, como por ejemplo: 192.168.1.1. Si, por ejemplo, el FTP al que conectamos es el de Rediris (ftp.rediris.es) sabemos que su IP es 130.206.1.5. El nmero de protocolo asignado a TCP es el 6. Por ltimo, el tamao del paquete TCP lo calculamos contando todos los bytes que PC PASO A PASO N 21
slo 16 bits, y un nmero hexadecimal de 5 cifras, como el 2BB6A, ocupa 20 bits. Por tanto, lo que hacemos es coger la primera cifra (el 2) y sumarla al resto: BB6A + 2 = BB6C Ya tenemos completada la operacin conocida como suma en complemento a uno . Ahora slo nos falta sacar a su vez el complemento a uno de este nmero, es decir, invertir todos los bits (donde haya un uno, poner un cero, y viceversa). Si pasamos este nmero (BB6C) a binario tenemos: 1011 1011 0110 1100. Si invertimos cada bit nos queda: 0100 0100 1001 0011 Este nmero de 16 bits es al fin lo que tenemos que poner en el campo que nos quedaba por rellenar: la suma de comprobacin. Repasamos por tanto todo lo visto acerca de la suma de comprobacin: 1- Agrupamos toda la cabecera TCP en grupos de 16 bits, y sumamos todos esos grupos entre s. 2 - A continuacin, construimos la pseudocabecera con las ips de origen y de destino, el protocolo, y el tamao de paquete, y agrupamos todo esto tambin en grupos de 16 bits . 3 - Sumamos estos nuevos grupos al resultado obtenido en el primer paso. 4- Del nmero obtenido en el paso 3, nos quedamos slo con los 16 ltimos bits, y los sobrantes los sumamos a estos 16, quedndonos as un resultado de 16 bits. 5- El resultado del cuarto paso, lo invertimos, cambiando cada cero por un uno, y viceversa. Pgina 24
Que cmo he hecho todas esas sumas en hexadecimal? Pues, por supuesto, no de cabeza, si no usando una calculadora cientfica que admita hexadecimal.
En esta captura podemos verme en plena faena, calculando el checksum de un paquete capturado con un sniffer. El sniffer me da directamente el paquete en hexadecimal, por lo que me facilita los clculos. Y cul es la utilidad de todas estas operaciones? Pues para comprenderlo necesitis saber que el complemento a uno de un nmero es el opuesto de ese nmero en complemento a uno, es decir, si sumas en complemento a uno un nmero cualquiera y su complemento a uno, el resultado tiene que ser siempre cero. Vamos, en resumen, que es como decir que -5 es el complemento a uno de 5, ya que 5 + (-5) = 0. Esto hace que el procesamiento de los paquetes sea bastante rpido a la hora de verificar los checksum, ya que basta con que el software sume todos los datos del paquete y, si el paquete es correcto, el resultado tiene que ser 0. PC PASO A PASO N 21
Esto es lgico, ya que la suma que nosotros hemos hecho hace un momento contena todos los datos del paquete excepto uno: la propia suma de comprobacin. El paquete que llegue al receptor, en cambio, si que contendr adems ese dato, y como ese dato es precisamente el opuesto de la suma de todos los dems, al sumar todos los datos ms la suma de comprobacin, el resultado ser: checksum + resto de cabecera = 0 Ya que, insisto: checksum = - (resto de cabecera). Os propongo como ejercicio que comprobis todo esto con un sniffer. Capturad un paquete TCP, sumad todos los datos de la cabecera T C P, d e l c a m p o D AT O S , y d e l a pseudocabecera utilizada en el checksum, y comprobaris que, si el paquete no contiene errores, el resultado es siempre cero.
Vamos a analizarlo: En primer lugar, los puertos de destino y de origen estn intercambiados, como es lgico. En segundo lugar, vemos que el nmero de secuencia no tiene nada que ver con el nuestro, ya que cada extremo de la comunicacin usar sus propios nmeros de secuencia. En cambio, el que s que tiene que ver con nuestro nmero de secuencia es su nmero de confirmacin . Al no contener datos nuestro paquete, el prximo byte que enviaramos sera el inmediatamente posterior al nmero de secuencia de nuestro paquete anterior. Por tanto, el servidor de Rediris estar esperando recibir en el prximo paquete un nmero de secuencia que sea el que enviamos antes, + 1. Vemos que su campo comienzo de datos es el mismo que el nuestro, ya que el paquete tambin contendr una nica fila de opciones (de 32 bits). Donde vemos que s que hay un cambio es en los flags, ya que aqu no slo est activado el flag SYN, si no tambin el flag ACK. En el prximo punto veremos en detalle a qu se debe esto. Vemos tambin que el tamao de la ventana es diferente, ya que cada extremo de la comunicacin puede tener su propio tamao de ventana.
Resumiendo
Al final, este es el paquete que nos queda, y que ser enviado tal cual desde nuestro PC hasta el receptor (en este caso, el servidor FTP de Rediris):
4. La respuesta a nuestro paquete

Al recibir este paquete el servidor FTP de Rediris, nos responder con el siguiente paquete, que os muestro como ejercicio para que lo analicemos:
La suma de comprobacin, por supuesto, es diferente para cada paquete. Os propongo como ejercicio que comprobis la validez de la suma de comprobacin de este paquete y, en caso de que sea incorrecta, que calculis cul sera el checksum correcto. El puntero de urgencia tambin est a cero, ya que tampoco tiene el flag URG activado. Por ltimo, vemos que tambin aade la opcin MSS, con el mismo tamao mximo
PC PASO A PASO N 21
Pgina 25
de segmento: 1460 bytes. El paquete tampoco contiene nada en el campo DATOS, ya que es otro de los paquetes utilizado nicamente para establecer la conexin.
5. Los estados de conexin TCP

No podemos completar un curso sobre TCP sin hablar de los estados de conexin. Para ello, empezaremos viendo una serie de procedimientos que se llevan a cabo en las conexiones TCP, para luego enumerar los estados que hemos ido descubriendo.
Por ejemplo, en el caso del servidor de Rediris, si habis probado a conectaros habris visto que nada ms conectar enva un texto de presentacin. Si nosotros no respondisemos al servidor dicindole que aceptamos la conexin, an habindola solicitado nosotros, el servidor se pondra en vano a enviar todo ese texto sin saber si al otro lado hay alguien escuchando. Estos tres paquetes especiales utilizados en el 3-way handshake se caracterizan por sus flags: El cliente solicita conexin al servidor: flag SYN. El servidor acepta la conexin: flags SYN y ACK. El cliente acepta la conexin: flag ACK.
5.1. Establecimiento de conexin TCP.

En el ejemplo anterior, los paquetes involucrados correspondan a un establecimiento de conexin. Como vimos, haba por lo menos dos paquetes encargados de establecer la conexin: uno por nuestra parte, que le deca al servidor de Rediris que queramos establecer la conexin, y otro por parte del servidor de Rediris que nos deca que estaba de acuerdo y l tambin quera establecer la conexin. En realidad, el establecimiento de conexin TCP requiere an otro paquete ms, y es lo que hace que a este sistema de establecimiento de conexin se le llame 3way handshake o, traducido as a lo bruto: saludo de 3 pasos. El sistema de establecimiento de conexin TCP consiste en lo siguiente: 1- El cliente solicita al servidor una conexin. 2- El servidor responde aceptando la conexin. 3- El cliente responde aceptando la conexin. A qu se debe la necesidad de este tercer paso? Este tercer paso permite una sincronizacin exacta entre cliente y servidor, y adems permite al cliente echarse atrs si no le gusta algo en la respuesta del servidor. Pgina 26
Esto ha de ser siempre as, y si alguno de esos flags no es enviado en el orden correcto, todo el establecimiento de conexin ser anulado. Intuitivamente, nos damos cuenta de que todo este mecanismo nos da lugar a diferentes estados en la conexin: En primer lugar, el estado primordial es el estado DESCONECTADO, que es cuando an ni siquiera hemos enviado el SYN. En segundo lugar, una vez enviado el SYN, estamos en un estado diferente que espera al prximo paso. A este paso lo podemos llamar SYN ENVIADO . Una vez que el servidor recibe el primer SYN, nos enviar su respuesta con el SYN y el ACK en el mismo PC PASO A PASO N 21
paquete. En ese caso, pasaremos a un estado que podemos llamar SYN RECIBIDO. Ahora nos falta esperar al ltimo paso del establecimiento, que es el ltimo ACK. Una vez recibido el ltimo ACK, nuestra conexin pasar finalmente al estado de conexin ESTABLECIDA.
que tengan como respuesta un SYN, ACK correspondern a los puertos abiertos de la mquina. Los paquetes que no tengan respuesta, o bien que sean respondidos con un flag RST, estarn cerrados. Lo interesante aqu es que nosotros no responderemos a ninguno de los SYN, ACK, por lo que ninguna conexin quedar establecida, ya que sera necesario que respondisemos con un nuevo paquete ACK por cada paquete SYN que envisemos.
Si alguna vez habis utilizado la herramienta netstat posiblemente os suenen estos nombres. Si no, probad ahora mismo, desde una shell de Linux/Unix, o una ventana MsDOS de Windows, a escribir: netstat Veris la lista de conexiones de vuestra mquina, con el estado de cada una. Las conexiones que estn en estado ESTABLECIDA, que son las ms habituales, aparecern como ESTABLISHED. Podris ver otros estados como CLOSE_WAIT, FIN_WAIT, LISTEN, etc. En breve explicaremos todos ellos.
Ataque SYN Flood

Ya que hemos empezado hablando de cosas divertidas, como el escaneo de puertos, vamos a rematar la faena hablando de una tcnica de hacking realmente interesante, aunque ms por el inters de su funcionamiento que por su utilidad prctica, ya que es un ataque de tipo DoS (Denial of Service), es decir, que slo sirve para fastidiar y tirar abajo un servidor. Por qu hablamos de diferentes estados en una conexin? Pues porque es necesario tener en cuenta los diferentes estados a la hora de llevar a cabo todos los pasos necesarios para conseguir llevar a cabo la comunicacin. Por ejemplo, en el momento en que pasamos al estado SYN_SENT, tenemos que crear una estructura de datos que necesitaremos para mantener controlado el estado de la conexin en todo momento. Sera absurdo tener estos Pgina 27
Escaneo de puertos con SYN

Os propongo como experimento que pongis en marcha alguna aplicacin de escaneo de puertos, y a continuacin hagis un netstat. Probablemente (dependiendo del tipo de escaneo que utilice la aplicacin), veris que hay montones de conexiones en estado SYN_SENT, es decir, lo que nosotros hemos llamado SYN ENVIADO. Esto se debe a que un sistema clsico de escaneo consiste en hacer solicitudes al servidor para establecer conexiones en cada uno de los puertos, es decir, enviamos un paquete SYN a cada puerto. Los paquetes PC PASO A PASO N 21
datos creados de antemano, ya que ocuparan una gran cantidad de memoria innecesaria y, adems, tampoco podramos saber cuntas estructuras de este tipo necesitaramos, pues depende en todo momento de cuntas conexiones tengamos establecidas. Por tanto, al cambiar un sistema al estado SYN_SENT, crear una estructura de datos para mantener la conexin inminente. Esta estructura de datos se llama TCB (Transmision Control Block). Por tanto, cada vez que intentamos conectar con un servidor, estamos hacindole crear una estructura que ocupa lugar en su memoria. En el momento en que se cierre esa conexin, el servidor podr borrar el TCB correspondiente, recuperando as el espacio que haba ocupado en su memoria. Qu pasara entonces si satursemos al servidor a base de conexiones? Si esta saturacin es suficiente, conseguiremos dejar sin memoria al servidor para establecer nuevas conexiones. Para que esta saturacin sea efectiva, es conveniente que utilicemos direcciones IP falsas, es decir, que hagamos un IP Spoofing. Si conseguimos enviar al servidor una gran cantidad de paquetes, cada uno de ellos conteniendo un flag SYN solicitando una conexin, y cada uno con una direccin IP falsa, el servidor crear un TCB para cada una de esas conexiones falsas inminentes y, al mismo tiempo, enviar el SYN, ACK a cada una de las direcciones falsas. A continuacin, se quedar esperando a recibir el ACK para completar el establecimiento de conexin de cada una de las conexiones falsas. Por supuesto, este ACK jams llegar, y el servidor se quedar esperando hasta que se canse. Lo malo es que los servidores son Pgina 28
bastante pacientes, y suelen esperar en torno a unos 3 minutos antes de dar por perdida una conexin. Por tanto, si saturamos al servidor a base de SYNs, en unos 3 minutos nadie podr conectarse legtimamente al servidor, ya que su memoria para nuevas conexiones estar llena en espera de completar las que tiene pendientes. Si este bombardeo de SYN s se repite constantemente, el servidor quedar inutilizado mientras dure el bombardeo.
Si lesteis mi artculo de la serie RAW sobre el protocolo DNS, o mi artculo sobre UDP del curso de TCP/IP, conoceris la tcnica de envenenamiento de cach DNS. Cuando expliqu esta tcnica mencion que una ayuda para hacer ms efectivo el ataque era conseguir hacer una denegacin de servicio (DoS) al servidor DNS legtimo. En cambio, la tcnica de SYN Flood no puede funcionar en UDP, ya que sencillamente UDP no tiene ningn flag, y menos an el flag SYN, por lo que en este caso el utilizar UDP frente a TCP es una ventaja para el protocolo DNS. Ms adelante veremos cmo llevar a cabo un ataque SYN Flood en detalle de forma prctica.
5.2. Cierre de conexin TCP

Continuando con el asunto de los estados de conexin en TCP, vamos a ver otro procedimiento que se puede llevar a cabo con cualquier conexin, y es el cierre de la misma.
PC PASO A PASO N 21
Si pensamos un poco, nos daremos cuenta de que hay un pequeo problema inherente a cualquier conexin full-duplex, es decir, las conexiones en las que cualquiera de las dos partes puede tanto transmitir como recibir. El problema es que, si ambos quieren transmitir datos, ambos tendrn que ponerse de acuerdo para decidir en qu momento hay que cerrar la conexin. Si no hubiese esta clase de acuerdos, ocurriran cosas poco deseables, como por ejemplo que conectsemos con un FTP, solicitsemos un archivo, y tras envirnoslo el servidor nos cerrase la conexin, asumiendo que ya no queremos bajar ni subir nada ms. O, por ejemplo, conectarnos a un chat, decir hola, y que el servidor decidiese que ya no queremos decir nada ms y, por tanto, nos cerrase la conexin. Por tanto, en una conexin full-duplex es necesario que ambas partes se pongan de acuerdo sobre el momento en el que hay que cerrar la conexin. En el caso de TCP, el sistema que se utiliza para conseguir esto es sencillamente que cada uno, por su cuenta, indique al otro el momento en el que quiere cerrar la conexin. Una vez que el otro se ha enterado, habr que esperar a que l tambin desee cerrar la conexin. Es decir, si hemos terminado de enviar datos, decimos Por mi ya est todo hecho. Avisame cuando termines t. En el momento en que el otro termine, avisar diciendo: Vale, yo tambin he terminado, as que hasta luego. Para dar este tipo de avisos lo que se hace es enviar un paquete especial que tiene activado un flag que sirve precisamente para indicar que deseamos FINalizar la conexin. Este flag es el flag FIN. A partir del momento en que enviamos un paquete con el flag FIN, ya no debemos enviar ningn paquete ms (excepto en el PC PASO A PASO N 21
caso de que tuviramos que reenviar un paquete anterior porque no recibisemos su confirmacin), y lo nico que debemos hacer es seguir recibiendo los datos de nuestro compaero, hasta que ste tambin nos enve su paquete con el flag FIN.
Esto, una vez ms, nos da lugar a nuevos estados de conexin. Una vez que enviamos nuestro FIN entramos en un estado en el que no podemos enviar, y slo podemos recibir. A este estado lo podemos llamar ESPERA DEL FIN. En realidad, el cierre de conexin da lugar a varios estados diferentes, que podemos ver en la siguiente imagen:
Aqu he puesto ya los nombres autnticos de los estados, en ingls, porque sera demasiado rebuscado tratar de traducirlos, jeje. Como vemos, el estado que he llamado antes ESPERA DEL FIN es el que se llama FIN_WAIT_1. En el momento en que nuestro compaero recibe nuestro FIN, l entra en otro estado diferente, que es el CLOSE_WAIT, es decir, Pgina 29
en espera de cerrar, ya que es ahora responsabilidad suya terminar de enviar cuando pueda, para enviar l tambin su FIN. Por otra parte, cuando recibe nuestro FIN, tiene que confirmarnos su recepecin, igual que con cualquier otro paquete, envindonos un ACK. En el momento en que recibimos ese ACK, entramos en otro estado, que es el FIN_WAIT_2. En el momento en que nuestro compaero termina, ste enva su FIN, y queda en espera de recibir nuestra confirmacin. Durante esta espera, entra en estado LAST_ACK . Una vez que recibimos ese FIN, entramos en estado TIME_WAIT, y enviamos el ACK para el FIN de nuestro compaero. Una vez completado todo esto, ambas partes pasan a estado CERRADO, y se acab el tema. La mquina A esperar un tiempo prudencial para pasar a estado CERRADO, ya que no puede estar seguro de que B haya recibido correctamente su ltimo ACK .
SYN_RECEIVED Se entra en este estado cuando tanto cliente como servidor han enviado sus correspondientes SYN, y estamos en espera de que se complete el tercer y ltimo paso del establecimiento de conexin. (Ver establecimiento de conexin). ESTABLISHED Conexin establecida. Es el estado habitual. FIN_WAIT_1 Hemos enviado un paquete FIN, y slo podemos recibir, pero no enviar. Estamos esperando a que nuestro compaero nos confirme que ha recibido nuestro FIN. Queremos cerrar la conexin, pero an no sabemos si nuestro compaero se ha enterado. (Ver cierre de conexin). FIN_WAIT_2 Hemos enviado un paquete FIN, y slo podemos recibir, pero no enviar, pero adems hemos recibido ya la confirmacin (ACK) de nuestro FIN. Por lo tanto, sabemos ya que nuestro compaero conoce nuestras intenciones de cerrar la conexin. (Ver cierre de conexin). CLOSE_WAIT Hemos recibido el FIN de nuestro compaero, pero a nosotros todava nos quedan datos por enviar. (Ver cierre de conexin). CLOSING Esperamos a la ltima confirmacin para cerrar definitivamente la conexin. Es un estado al que se llega cuando ambas partes desean cerrar la conexin simultneamente, al contrario del caso que explicamos anteriormente. LAST_ACK Esperamos a la confirmacin (ACK) de nuestro FIN, cuando eramos nosotros los ltimos que faltabamos por enviar el FIN. (Ver cierre de conexin). TIME_WAIT Hemos enviado la confirmacin del FIN a nuestro compaero, cuando era l el que faltaba por enviar el FIN. Se llama as, porque lo que hacemos es esperar un tiempo prudencial para asumir que ha recibido nuestra confirmacin. Siempre que nosotros cerremos PC PASO A PASO N 21
5.3. Lista de estados TCP

Ya podemos ver la lista completa de estados de conexin en TCP, que os servir como gua de referencia, sobre todo para cuando utilicis herramientas como netstat. LISTEN Es el estado en el que permanece cualquier servidor cuando est en espera a que un cliente se conecte. Todos los puertos que tengamos abiertos en nuestro PC nos generarn un socket TCP (o UDP, segn el caso) en estado LISTEN. Cada vez que un cliente se conecte, si permitimos ms de una conexin, se crear un socket en estado ESTABLISHED para ese cliente, y otro en estado LISTEN para esperar al resto de clientes. SYN_SENT Se entra en este estado cuando solicitamos una conexin a un servidor (enviamos un paquete SYN), y an no hemos recibido su aceptacin o su rechazo. (Ver establecimiento de conexin). Pgina 30
una conexin, durante un tiempo permaneceremos en estado TIME_WAIT, por lo que es bastante comn encontrar este estado cuando hacemos netstat. (Ver cierre de conexin). CLOSED Es un estado ficticio, que simplemente dice que no hay ningn tipo de conexin. A continuacin, muestro el diagrama de estados de TCP, tal y como lo podis encontrar en el RFC:
6.1. Hping2 para Linux

El caso de TCP es bastante ms complicado que el de UDP, ya que TCP da muchsimo ms juego. No hay ms que ver el manual: man hping2 Para ver la gran cantidad de opciones que hay para TCP que, por cierto, es el protocolo por defecto de Hping2. Nosotros vamos a ver slo las opciones que directamente tienen que ver con lo explicado hasta ahora. Empezamos con la prueba ms sencilla: hping2 130.206.1.5 --destport 21 --count 1 Con esto enviamos un nico (--count 1) paquete TCP a la direccin 130.206.1.5, al puerto 21. Este paquete tendr todos sus parmetros tal y como los tiene configurados hping2 por defecto, es decir, sin ningn flag, con un tamao de ventana de 64 bytes, y sin opciones. Este paquete, por tanto, sirve para bien poco, aunque en el manual de hping2 nos explican que, si ni siquiera utilizamos el parmetro -destport, por defecto enva el paquete al puerto 0, y esto puede ser til para hacer un ping a una mquina que tenga un firewall que filtre los autnticos pings (que no son TCP, si no ICMP, que es otro protocolo), y adems es probable que ste intento nuestro de ping ni siquiera quede reflejado en los logs de la mquina. An as, esto es algo que yo no he comprobado, as que no s qu utilidad tendr. Os propongo que lo probis vosotros
6. RAW Sockets TCP (Nemesis y Hping)

Vamos a recordar un poco las herramientas que expliqu para manejar RAW sockets en el artculo sobre UDP, pero en este caso aplicadas al caso de TCP. Esta vez empezaremos por Linux.
mismos como ejercicio. Vamos a ver las diversas opciones que nos da Hping2 para TCP: --baseport: permite especificar nuestro puerto de origen. --destport: permite especificar el puerto de destino. --keep: si enviamos varios paquetes, evita Pgina 31
PC PASO A PASO N 21
que el puerto de origen se vaya incrementando automticamente, tal y como vimos con UDP. --win: fija el tamao de la ventana TCP. --tcpoff: enva un valor falso para el campo Comienzo de Datos de la cabecera TCP. --tcpseq: especifica el Nmero de Secuencia. --tcpack: especifica el Nmero de Confirmacin. --badcksum: igual que en UDP, enva un checksum errneo. --fin: el paquete que enviamos tiene activo el flag FIN. --syn: el paquete que enviamos tiene activo el flag SYN. --rst: el paquete que enviamos tiene activo el flag RST. --push: el paquete que enviamos tiene activo el flag PUSH. --ack: el paquete que enviamos tiene activo el flag ACK. --data: especifica el tamao del campo DATOS, sin contar con la cabecera. --file: igual que en UDP, permite rellenar el campo DATOS con los contenidos de un archivo que especifiquemos. --safe: nos permite asegurarnos de que los paquetes que enviamos llegan a su destino ya que, tal y como ha de hacerse en TCP, si no recibimos la confirmacin de alguno de los paquetes, hping2 lo reenviar automticamente. Vamos a ver todo esto y mucho ms con un ejemplo muy interesante, que es para poner en prctica la tcnica de SYN Flood explicada anteriormente.
fastidiando por fastidiar. Adems, es poco probable que funcione un IP spoofig a pelo como el que voy a explicar, ya que los routers que haya en el camino desde vosotros hasta vuestra vctima probablemente rechacen los paquetes si no provienen de una IP que forme parte de su red. Recordemos que para explotar la tcnica de SYN Flood simplemente hay que enviar gran cantidad de paquetes con flag SYN, cada uno con una direccin IP de origen falsa y, a ser posible, diferente. Hping2 casualmente tiene opciones para automatizar todo esto, por lo que nos basta con esta lnea: hping2 192.168.1.1 --rand-source -destport 21 --syn --count 100 Con esta lnea enviaremos 100 paquetes (-count 100) al puerto 21 de la IP 192.168.1.1, utilizando como IP de origen una aleatoria en cada paquete (--rand-source), y con el flag SYN activado. Os puedo asegurar que esta lnea funciona, ya que acabo de probarla ahora mismo con el puerto de telnet (--destport 23) de mi router ADSL, y ahora me es imposible conectar con el telnet del router. Significa esto que yo, que precisamente estoy explicando estas cosas, tengo un grave problema de seguridad? Realmente no, por tres motivos. En primer lugar, porque el puerto de Telnet lo tengo abierto slo hacia mi red local, por lo que slo podra atacarme... yo mismo. En segundo lugar, porque no es un servicio de importancia crtica, es decir, me da igual tirarme el tiempo que sea sin poder acceder al telnet de mi router, ya que slo lo uso muy rara vez, cuando tengo que modificar algo en la configuracin. En tercer lugar, al tratarse de un router hardware y no de un simple programa de PC, tendra que esperar a que saliese una nueva actualizacin del firmware que solucionase este problema, as que en cualquier caso no est en mi mano la solucin, si no en la del fabricante del router. Ya que la cosa se est calentando un poco, PC PASO A PASO N 21
SYN Flood mediante Hping2.

Esta tcnica slo debis utilizarla para hacer pruebas con vosotros mismos, para comprender el funcionamiento de la tcnica, y tambin para poner a prueba la seguridad de vuestra red, por si queris hacer una auditora de seguridad y arreglar los agujeros que tengis. Cualquier otro uso que le deis, al margen de que pueda ser ilegal, ticamente ser indeseable, ya que no estaris ms que Pgina 32
vamos a probar alguna tcnica ms de hacking relacionada con TCP.
Ataques por adivinacin de nmero de secuencia con Hping2.

Vamos ahora con una tcnica realmente interesante que, de hecho, utiliz incluso el propio Kevin Mitnick (uno de los hackers ms famosos de la historia) como parte de las andanzas que le hicieron terminar en la crcel (aplicaos el cuento, jeje). En este caso, no se trata de un simple ataque DoS, como el SYN Flood, si no de un ataque mucho ms verstil que nos permitir colarnos en conexiones ajenas, con todo lo que ello implica. Conseguir un ataque de este tipo con xito es realmente complicado, as que lo que voy a contar, que en la teora puede parecer tan sencillo, en la prctica choca con mil y un inconvenientes, empezando por la dificultad que coment antes de hacer un IP Spoofing sin que se enteren los routers que transportan el paquete. Como lo importante es comprender la teora de las cosas, y no meternos en los, voy a explicar las bases de este tipo de ataques. Para comprender el funcionamiento de estos ataques debemos recordar qu es lo que define exactamente una conexin, es decir, lo que identifica unvocamente a una conexin para diferenciarla de cualquier otra de Internet. Pues son estos los parmetros: una IP de origen, una IP de destino, un puerto de origen, un puerto de destino, y los nmeros de secuencia de cada una de las dos partes. Por tanto, si conociramos todos estos datos, teniendo una herramienta como Hping2 que nos permite crear paquetes a medida, podramos insertar cualquier dato en una conexin ajena. Por ejemplo, si sabemos que la mquina A, con IP 192.168.1.2, tiene establecida una PC PASO A PASO N 21
conexin de FTP (puerto de destino 21) con la mquina B, con IP 192.168.1.5, utilizando como puerto de origen el 3560, nos bastara con saber el nmero de secuencia que est utilizando la mquina A para poder inyectar p a q u e t e s e n s u c o n e x i n d e F T P. Supongamos que sabemos que su nmero de secuencia es el 24560. Bastar con hacer: hping2 192.168.1.5 --spoof 192.168.1.2 --baseport 3560 --destport 21 --tcpseq 24560 --file comandos.txt --data 14 -count 1 Con esto enviamos un nico paquete (--count 1) enviando como IP spoofeada la de la mquina A (--spoof 192.168.1.2), e inyectando como datos unos comandos de FTP que hemos metido previamente en el archivo COMANDOS.TXT. Por supuesto, el gran problema de esto es que es realmente complicado conocer el nmero de secuencia de una conexin ya que, adems de ser un nmero realmente grande (32 bits), va cambiando constantemente a lo largo de una conexin. Hping2 nos ofrece una herramienta para ayudarnos a la hora de adivinar el nmero de secuencia, comprobando si un determinado sistema utiliza nmeros de secuencia fciles de predecir. Para ello nos da la opcin -seqnum, que hace un anlisis de los nmeros de secuencia utilizados por un sistema: hping2 192.168.1.5 --seqnum --destport 21 --syn Con esto veramos cmo varan los nmeros de secuencia de la mquina B cada vez que intentamos conectar con su puerto de FTP. Hping2 nos mostrar el nmero de secuencia utilizado, y el incremento con respecto al utilizado anteriormente. Si este incremento es siempre el mismo, entonces estaremos ante una mquina con nmeros de secuencia fcilmente predecibles. Pgina 33
Una vez que ya tenemos una idea del rango de nmeros de secuencia que puede utilizar la mquina que queremos suplantar, podemos intentar lanzar miles de paquetes iguales, en los cuales slo cambie el nmero de secuencia, y esperar que el azar nos recompense con la suerte de que alguno de ellos haya acertado, y el paquete se inyecte correctamente en la conexin ajena.
de urgencia. -o : permite incluir un fichero que contenga las opciones TCP que queramos. -v : activa el modo verbose que nos da informacin ms detallada de lo que estamos haciendo. Os recuerdo tambin que necesitaremos un par de opciones referentes a IP: -D : permite especificar la IP de destino (imprescindible). -S : permite especificar la IP de origen (IP Spoofing). Por ejemplo, si queremos enviar un paquete de solicitud de conexin al FTP de Rediris podemos hacer: Nemesis tcp -v S 192.168.1.1 D 130.206.1.5 x 1000 y 21 fS a 0 En primer lugar especificamos nuestra IP (-S 192.168.1.1), que en este caso es una IP de red local porque nos encontramos detrs de un router ADSL. En segundo lugar indicamos la IP de destino, es decir, la del servidor FTP de Rediris (-D 130.206.1.5). A continuacin especificamos los puertos de origen y de destino (-x 1000 y 21). A continuacin, activamos el flag SYN para este paquete (fS). Por ltimo, ponemos un 0 en el campo nmero de confirmacin, ya que es para una conexin an no establecida (-a 0).
6.1. Nemesis para Windows

Para empezar, os recuerdo que en el directorio de Nemesis tenis un archivo de ayuda para cada protocolo. En este caso el que nos interesa es el archivo nemesis-tcp.txt . Como ya me estoy quedando sin espacio, os resumo brevemente las opciones que nos da Nemesis para TCP, que son bastantes: -x : permite especificar el puerto de origen. -y : permite especificar el puerto de destino. -s : permite especificar el nmero de Secuencia. -a : permite especificar el numero de confirmacin. -fS : activa el flag SYN -fA : activa el flag ACK -fR : activa el flag RST -fP : activa el flag PSH -fF : activa el flag FIN -fU : activa el flag URG -w : permite especificar el tamao de la ventana. -u : permite especificar el campo puntero

PC PASO A PASO busca personas que posean conocimientos de informtica y deseen publicar sus trabajos. SABEMOS que muchas personas (quizs tu eres una de ellas) han creado textos y cur sos par a consumo pr opio o de unos pocos. SABEMOS que muchas personas tienen inquietudes periodsticas pero nunca se han atrevido a presentar sus trabajos a una editorial. SABEMOS que hay verdaderas obras de arte creadas por personas como tu o yo y que nunca vern la luz. PC PASO A PASO desea contactar contigo!

CURSO DE TCP/IP: ICMP (Protocolo de Mensajes de Control de Internet).

- ICMP es, posiblemente, el protocola ms utilizado por los hackers - ICPM nos dar informacin MUY VALIOSA sobre el funcionamiento de las conexiones. - Veremos que este protocolo nos permite detectar gusanos y ataques, tracear conexiones, destruir firewalls, degradar servicios, descubrir datos sobre nuestras "victimas"... ...
1.
Introduccin
Imagino que muchos de los lectores que han seguido fielmente el curso de TCP/IP desde sus comienzos estarais esperando que este mes hablase del protocolo IP, ya que una vez explicados los protocolos de transporte clsicos (TCP y UDP) el orden lgico sera llegar a la capa inferior, o la capa de red. Pero, para vuestra sorpresa, an no vamos a llegar a esa parte tan esperada, pero tambin tan compleja; si no que vamos a seguir con el orden lgico, con un protocolo que, aunque no sea un protocolo de transporte, si que funciona por encima del protocolo IP. La diferencia entre ICMP y otros protocolos que funcionen por encima de IP (como TCP, UDP, u otros que no hemos mencionado) es que ICMP se considera casi una parte de IP, y las especificaciones estndar de IP obligan a que cualquier sistema que implemente el protocolo IP tenga tambin soporte para ICMP. Y por qu es tan importante ICMP para IP? Pues porque IP no es un protocolo 100% fiable (como nada en esta vida), e ICMP es precisamente el que se encarga de manejar los errores ocasionales que se puedan dar en IP.
Pgina 14
Por tanto, ICMP es un protocolo de Control (Internet Control Message Protocol), que sirve para avisar de los errores en el procesamiento de los datagramas, es decir, de los paquetes IP. Como ICMP funciona sobre IP, los paquetes ICMP sern siempre a su vez paquetes IP. Esto podra dar lugar a situaciones en las que se generasen bucles infinitos donde un paquete ICMP avisa de errores de otro paquete ICMP. Para evitar esto, hay una regla de oro, y es que, aunque los paquetes ICMP sirvan para arreglar errores de otros paquetes, jams se enviarn paquetes ICMP para avisar de errores en otro paquete ICMP. Aunque esto suene a trabalenguas, ya iremos viendo en detalle el funcionamiento del protocolo ICMP, y se aclararn muchas cosas. Muchos de vosotros conoceris ya algo sobre ICMP, pero quiz alguno se est preguntando: Pero realmente es tan importante este protocolo? Si jams he odo hablar de l! Seguro que no se usa para nada!. Pues por supuesto que se usa, y mucho, aunque es normal que no os suene, teniendo en cuenta que es un protocolo que no suele usar la gente en su casita, si no que es usado sobre todo por los routers.
PC PASO A PASO N 23
Protocolo ICMP - Protocolo ICMP - Protocolo ICMP - Protocolo ICMP - Protocolo ICMP
An as, aunque los paquetes ICMP sean generados normalmente por un router, el receptor del paquete suele ser un usuario como t, as que en realidad s que ests usando el protocolo ICMP aunque no te des cuenta. Por ejemplo, cuando intentas acceder a una IP que no existe, normalmente se te notificar por medio de un mensaje ICMP. Adems, hay tambin una serie de aplicaciones, como Ping, o Traceroute, que utilizan ICMP, y en este caso s que eres t el que genera los paquetes. Aparte de todo esto, para nosotros ICMP es especialmente interesante ya que, tal y como podis leer en ms de un documento de los que circulan en la red sobre ICMP, se dice de este protocolo que es mucho ms til para un hacker que para un usuario normal. Para este artculo ir explicando uno a uno los diferentes mensajes ICMP, y contando en cada uno alguna curiosidad un poco ms oscura para darle ms gracia a la cosa (buscad los epgrafes en color rojo). Por ltimo, como era de esperar, terminar explicando cmo generar paquetes ICMP desde cero con las aplicaciones ya conocidas.
Aqu podrs encontrar la traduccin al espaol del RFC 792 (Protocolo ICMP), concretamente en el enlace h t t p : / / w w w. r f c - e s . o r g / g e t f i l e . p h p ? r f c = 0 7 9 2 No dudes en pasarte por www.rfc-es.org y, si te es posible, participar en su proyecto. Desde esta revista damos las gracias a quienes colaboran de forma totalmente desinteresada en este tipo de iniciativas que nos benefician a todos. El protocolo ICMP consta simplemente de una serie de mensajes totalmente independientes que se generan para cada situacin de error que se de en el procesamiento de un paquete IP, o bien por otras circunstancias especiales en las que un usuario desea conocer cierta informacin sobre una mquina. Por eso, no hay que andar con complejas explicaciones sobre conexiones virtuales, ni nada de nada. Simplemente basta con ir explicando cada mensaje por separado.
2.1. Destino inalcanzable (Destination Unreachable)

Este es el primer mensaje ICMP, que sirve para avisar de un gran nmero de situaciones de error, aunque todas con una misma consecuencia: no se ha podido acceder al destino que se solicitaba. Cuando intentas acceder a una IP (una pgina Web, u otro servidor de cualquier tipo), puede haber muchos motivos por los que no puedas llegar a acceder y, siempre que estos motivos tengan que ver directamente con la parte de la que se encarga el protocolo de red (IP), cualquier dificultad que haya te ser notificada mediante un mensaje ICMP de este tipo.
2.
Directamente al grano
Igual que hacen en el RFC que explica el protocolo ICMP (RFC 792 : ftp://ftp.rfceditor.org/in-notes/rfc792.txt), no nos enrollaremos mucho con explicaciones previas, e iremos directamente al grano.
Como ya debes...
Como ya debes suponer, los RFCs son documentos escritos originalmente en ingls. Para quien no domine el idioma, contamos con la inestimable ayuda de la Web www.rfc-es.org
PC PASO A PASO N 23
Pgina 15
Por supuesto, puede haber otros motivos por los que no puedas acceder a los contenidos que buscas. Por ejemplo, al intentar acceder a una pgina Web, el Servidor Web podra responderte con un error 404 (te recuerdo que expliqu todo esto en mi artculo sobre HTTP en la serie RAW, hace ya unos cuantos nmeros...). Esta situacin de error no es responsabilidad de IP y, por tanto, tampoco de ICMP, por lo que este error no se notificara mediante un mensaje ICMP, si no que sera responsabilidad del Servidor Web el generar una respuesta de error 404 de HTTP. Un error que s que sera responsabilidad de IP al intentar acceder a una pgina Web sera que la IP del Servidor Web que buscamos no existiese. Hay muchos otros motivos por los que un destino puede ser inalcanzable, como veremos en detalle ahora mismo. De momento, vamos a ver el formato detallado del mensaje:
Por supuesto, me imagino que no entendis ni papa de los contenidos de esta tabla. Explicar todos los cdigos en detalle va a ser demasiado (y, realmente, poco interesante), as que explicar slo lo suficiente para que os hagis una idea de lo ms importante. En primer lugar, no hay que ser muy observador para darse cuenta de que la mayora de los errores estn duplicados, refirindose siempre o bien a la red, o bien al host. Imaginemos que estamos en una red local, cuyas direcciones IP abarcan desde la 192.168.1.1 hasta la 192.168.1.255, pero en la cual slo existen tres mquinas: 192.168.1.1 Mquina 1 192.168.1.5 Mquina 2 Y mquina 3 192.168.1.100 Si intentamos acceder a la mquina 192.168.1.200 recibiremos un mensaje de Host inalcanzable (cdigo 1). La IP 192.168.1.200 forma parte de una red a la que tenemos acceso, pero en cambio ese host concreto no existe en la red. En cambio, si intentamos acceder en el mismo escenario a la IP 10.12.200.1, estaremos intentando acceder a una red que no es la nuestra, por lo que el router
PC PASO A PASO N 23
Campo: Type El primer campo, Type, se encuentra en todos los mensajes ICMP, y especifica el tipo de mensaje. En el caso del mensaje Destination Unreachable el tipo de mensaje es 3. Campo: Code El campo Code permite precisar el motivo por el que el destino es inalcanzable. Segn el valor de este campo, podemos saber el motivo exacto, consultando la siguiente tabla:
Pgina 16
no podr darnos acceso, y tendr que respondernos con un error de Red inalcanzable (cdigo 0). Con esta breve explicacin de paso he explicado los dos primeros cdigos. Slo queda comentar que el cdigo 1 slo lo enviar el ltimo router dentro del camino que lleve desde nuestra mquina hasta el host de destino, ya que ste ltimo router ser el que sepa qu mquinas en concreto existen dentro de su red. En cambio, el cdigo 0 puede ser enviado por cualquiera de los routers que haya en el camino entre tu mquina y el host de destino, ya que en cualquier punto del camino se podra detectar que la red de destino es inalcanzable.
cuando se intenta acceder a un protocolo de transporte que no est implementado en el host de destino. Por ejemplo, si enviamos un paquete UDP a una mquina que no tiene implementado UDP. Como la capa IP es la encargada de reconocer al protocolo de nivel superior, ser responsabilidad suya, y por tanto de ICMP, el notificar de los errores de protocolos no implementados. El mensaje de Puerto inalcanzable (cdigo 3) se genera cuando se intenta acceder a un puerto en un protocolo de transporte (por ejemplo, TCP o UDP), y ese puerto no est accesible en el host de destino. En muchos casos, el propio protocolo de transporte se encargar de notificar este error (por ejemplo, en TCP mediante el flag RST), pero siempre que el protocolo de transporte no tenga implementado un mecanismo para notificar esta situacin, ser responsabilidad de ICMP hacerlo. El mensaje de Paquete demasiado grande, y no puede ser fragmentado (cdigo 4) tiene relacin con un campo de la cabecera IP que veremos ms adelante en el curso de TCP/IP. Este campo especifica si un paquete puede ser o no fragmentado en trozos ms pequeos. En el caso de que est especificado que el paquete no puede ser fragmentado, y el paquete sea demasiado grande como para ser enviado de una sola vez, el paquete no podr ser transmitido. De momento con esto creo que tenemos suficiente, que no quiero llenar el artculo entero slo con el primero de los mensajes ICMP y, al fin y al cabo, ya he explicado los cdigos ms comunes. Campo: Checksum Pues aqu nos encontramos de nuevo con
Pgina 17
En la imagen la mquina H1 solicita acceder a la IP 10.1.2.3 al router R1. ste pasa la bola a R2, el cual est conectado a la red 10.x.x.x, donde debera encontrarse la IP solicitada. Como R2 sabe que el host 10.1.2.3 no existe, responder con un mensaje ICMP Host inalcanzable. El mensaje ICMP llegar a R1, que lo retransmitir hasta H1. Con respecto al siguiente cdigo, Protocolo inalcanzable (cdigo 2), en primer lugar hay que decir que no se genera en un router, si no en el propio host de destino. Este error se genera
PC PASO A PASO N 23
otro checksum, como los que ya vimos en anteriores entregas cuando tratamos el UDP y TCP. En el artculo anterior detall cmo generar un checksum para TCP, y tambin como realizar su comprobacin para un paquete recibido. En el caso de ICMP, los checksums (sumas de comprobacin) se generan mediante la misma operacin, pero en este caso no es necesario aadir una pseudocabecera, si no que directamente la operacin se realiza nicamente con todos los bits que componen la cabecera ICMP. Campo: Unused Pues eso, qu queris que os cuente sobre un campo que no se usa? Simplemente lo rellenis con ceros, y ya est. Campo: Internet Header + 64 bits of original data datagram Aqu ya hay bastante ms que decir, ya que adems este campo es comn a muchos mensajes ICMP. Este campo es especialmente importante, ya que es el que nos permite identificar de forma unvoca a qu datagrama (paquete IP) se refiere el mensaje ICMP. Como ya he dicho, un paquete ICMP puede ser una respuesta a un paquete IP que ha generado algn tipo de error. Si nos llegasen paquetes ICMP sin ms no podramos saber cul de nuestros paquetes IP gener el error. Por eso, muchos paquetes ICMP llevan incluidos en su propia cabecera la cabecera IP del paquete que gener el error. Adems, para terminar de
Pgina 18
asegurarnos de que se trata de nuestro paquete, se incluyen tambin los 64 primeros bits del campo de DATOS del datagrama, por lo que el paquete puede quedar identificado sin lugar a dudas. Por ejemplo, imaginemos que enviamos el siguiente paquete:
En el caso de que este paquete genere, por ejemplo, un error de Destino inalcanzable, ste ser el paquete ICMP que nos llegar en respuesta:
Dentro de la cabecera ICMP podemos ver en verde la copia de la cabecera IP del paquete que gener el mensaje, as como los primeros datos del campo de DATOS (en azul). Tambin es importante destacar que, como se ve en la imagen, el nmero de protocolo asignado a ICMP es el 1. Detectando gusanos mediante Destination Unreachable Como os dije, comentar algn detalle curioso sobre cada uno de los mensajes ICMP. Os voy a comentar una posible
PC PASO A PASO N 23
seal de alarma en relacin con los mensajes Destination Unreachable. Si observamos los logs de nuestra conexin... que qu es eso? Pues en un sistema que tenga implementada una buena poltica de seguridad es habitual tener un mecanismo de monitorizacin que guarde un registro (un log) de lo que ocurre con las conexiones de nuestra mquina. En caso de que no tengis nada de esto montado (sera motivo para varios artculos el explicar cmo hacerlo bien hecho), podis hacer pruebas simplemente poniendo en marcha un sniffer, como los que he explicado ya en otros artculos (por ejemplo, Iris para Windows, o Ethereal o Snort para Linux). Pues como deca, si observamos lo que ocurre en nuestra conexin con Internet, y detectamos que nos llegan una gran cantidad de mensajes ICMP de tipo Destination Unreachable, podra ser sntoma de que estamos infectados con algn gusano (Worm). Un gusano es un tipo de virus informtico cuya principal funcin consiste en reproducirse a toda costa al mayor nmero de vctimas posible. La gran mayora de los virus que existen hoy da pueden ser calificados como gusanos, siendo buenos ejemplos los conocidos virus Sasser, MyDoom, etc. Algunos de estos gusanos intentarn reproducirse por un sistema tan burdo como es el generar direcciones IP aleatorias, e intentar acceder a todas ellas para tratar de infectar una nueva mquina. Esto es especialmente til en gusanos como el Sasser (y, de hecho, el Sasser utiliza este sistema), que no necesitan
PC PASO A PASO N 23
ser ejecutados para infectar una mquina (por ejemplo mediante un correo electrnico), si no que basta con que den con una mquina vulnerable (es decir, que tenga cierta versin de Windows sin parchear). Por supuesto, si el gusano genera direcciones IP que no existen, recibiremos un mensaje Destination Unreachable cada vez que el gusano intente infectar una de estas IPs. Por tanto, encontrar varios mensajes ICMP de este tipo cuyo origen desconocemos puede ser un sntoma de que tenemos un visitante no deseado en nuestro PC. No slo eso, si no que adems analizando en detalle la cabecera ICMP podremos seguramente extraer informacin acerca del gusano, ya que estos mensajes ICMP, tal y como acabamos de ver, incluyen en su cabecera toda la cabecera IP del mensaje que gener el error, as como los primeros 64 bits de datos. Este sistema no es definitivo, por supuesto, ya que no todos los gusanos utilizan este sistema para buscar vctimas, as que el hecho de no recibir mensajes Destination Unreachable no significa ni mucho menos que no podamos estar contaminados con algn otro tipo de gusano ms inteligente. Podra comentar muchos otros aspectos oscuros de este tipo de mensajes ICMP, como los ataques Smack , Bloop , WinNewK, etc. Pero como el espacio es limitado, y adems tengo que despertar un poco en vosotros la capacidad y el nimo de investigar por vuestra cuenta, ah os he dejado los nombres, para que vuestro amigo Google os d ms detalles.
Pgina 19
Path MTU Discovery (P-MTU-D) Una aplicacin importante de los mensajes Destination Unreachable, es el proceso de Path MTU Discovery. Ya sabemos que entre dos mquinas que se comunican suele haber varias mquinas intermedias, que actan como routers para encaminar los paquetes entre ambas mquinas. El problema es que cada mquina de todas las involucradas en el proceso (incluyendo las mquinas de origen y destino) puede tener una configuracin y unas caractersticas diferentes. Esto da lugar a que haya mquinas preparadas para manejar paquetes ms o menos grandes. El tamao mximo de paquete que puede manejar una mquina se denomina MTU (Max Transmission Unit), y depende de la tecnologa utilizada, tal y como veremos cuando hablemos sobre el nivel de enlace a lo largo del curso. Por ejemplo, una tecnologa Ethernet utiliza una MTU de 1500 Bytes, mientras que en X.25 se utiliza una MTU de slo 576 Bytes. Pero bueno, ya explicaremos esto en otro nmero... De momento, tenemos que tener la idea intuitiva de lo que es la MTU que, por cierto, est bastante relacionada con el MSS, es decir, el tamao mximo de segmento que vimos en TCP. El tamao mximo de segmento indica el tamao mximo del campo de datos de un paquete TCP, el cual estar directamente relacionado con el tamao de MTU de la mquina que envi el paquete TCP. Si queremos que funcione correctamente una comunicacin entre dos mquinas tendr que haber un acuerdo sobre qu
Pgina 20
tamao de MTU utilizar ya que, no slo cada una de las dos mquinas tendr una MTU diferente, si no que tambin podran tener MTUs diferentes cada uno de los routers que se encuentran en el camino entre las dos mquinas. Cuando un router se encuentra con un paquete cuyo tamao es mayor que el de su MTU, tendr que fragmentarlo en trozos ms pequeos que s que quepan en su MTU. El problema con esto es que la fragmentacin es muy poco deseable, por motivos que explicar a lo largo del curso, por lo que conviene evitarla. Para poder evitar la fragmentacin, una buena idea consiste en conseguir un acuerdo sobre el tamao mximo de los paquetes entre todas las mquinas involucradas en la conexin. El mecanismo para conseguir este acuerdo se denomina Path MTU Discovery, y viene detallado en el RFC 1191 . A grandes rasgos, lo que se hace es enviar un paquete demasiado grande, pero forzando a que no sea fragmentado (mediante una opcin que se puede especificar en la cabecera IP). Si alguna mquina del camino del paquete no puede manejar un paquete tan grande, al no poder tampoco fragmentarlo no le quedar ms remedio que responder con un ICMP Destination Unreachable Code 4. A partir de ah, se ir repitiendo el proceso con diferentes tamaos de paquete, hasta que se de con un tamao que s que sea aceptado por todas las mquinas. Este tamao mximo para todo el camino que se ha encontrado se denomina precisamente Path MTU.
PC PASO A PASO N 23
2.2. Tiempo excedido (Time Exceeded)

Como podemos ver, la cabecera de este mensaje consta de los mismos campos que el mensaje anterior:
determinado, y este valor se ir decrementando en cada router por el que pase el paquete. As, si por ejemplo un paquete tiene un TTL = 3, el primer router que reciba el paquete modificar este valor haciendo TTL=2, y reenviar el paquete al prximo router del camino entre el origen y el destino. En caso de que un paquete con TTL=0 llegue a un router, significar que el paquete no ha podido llegar a su destino en un plazo limitado, por lo que el router tendr que responder al transmisor del mensaje con un ICMP de tipo Time Exceeded, y Code 0. Code 1: Tiempo de reensamblaje superado. Otra situacin en la que un paquete puede caducar tiene relacin con la fragmentacin que ya mencion antes. Como dije, un paquete demasiado grande puede ser dividido en fragmentos para facilitar su transmisin. Los fragmentos irn llegando al destino en cualquier orden, y ste se encargar de reensamblar el paquete. Por supuesto, hay un lmite de tiempo por el que estar esperando el destino a que le lleguen todos los fragmentos, para evitar quedarse esperando indefinidamente en caso de que haya habido algn problema de transmisin. Si un paquete que est en proceso de reensamblaje no se completa en un tiempo determinado, se enviar un mensaje ICMP de tipo Time Exceeded , y Code 1 , indicando que no se ha podido completar el reensamblaje del paquete.
Para explicar la utilidad de este mensaje vamos a ver mejor los campos que lo forman. Campo: Type Para este tipo de mensajes, su valor ha de ser 11, en decimal, por supuesto. Campo: Code En este caso slo existen dos posibles valores, ya que este mensaje puede ser enviado por dos motivos diferentes: Code 0: Tiempo de vida superado. Como veremos a lo largo del curso, en la cabecera IP existe un campo TTL (Time To Live) que permite limitar el nmero de routers que atravesar un paquete para llegar a su destino. Si no limitsemos este nmero de saltos, se podra dar el caso de que un paquete quedase circulando para siempre en la red en caso de que algn router mal configurado produjese un bucle cerrado en el que los paquetes van de un router a otro sin sentido, sin llegar jams a su destino. Cada paquete IP llevar, por tanto, un campo TTL con un valor numrico
PC PASO A PASO N 23
Pgina 21
Trazado de rutas mediante Time Exceeded Posiblemente habris utilizado alguna vez la conocida herramienta traceroute. Como sabris, esta herramienta permite conocer todos los routers que existen en el camino entre un origen y un destino. Esta herramienta funciona precisamente gracias a los mensajes ICMP de tipo Time Exceeded, concretamente a los de Code 0. Lo que hace traceroute es empezar enviando un paquete cualquiera al destino que queremos trazar, pero utilizando en el paquete un TTL=1. En cuanto este paquete llegue al primer router que haya en el camino entre tu mquina y la mquina de destino, este router decrementar el TTL, por lo que lo dejar en TTL=0. Al no poder reenviarlo, ya que el tiempo de vida del paquete ha expirado, tendr que enviar un ICMP Time Exceeded Code 0 en respuesta.
reenvindolo, por lo que el paquete llegar al prximo router, R2. En cambio, en este segundo router ocurrir lo mismo que antes, pues se encontrar con un paquete con TTL=0 que no podr reenviar, por lo que tendr que responder con un ICMP Time Exceeded Code 0.
Este proceso continuar, incrementando en uno cada vez el valor de TTL, hasta que finalmente sea el host de destino el que nos responda:
Este paquete contendr como IP de origen la del router que lo gener (R1), por lo que conocemos as ya la IP del primer router que nos hemos encontrado en el camino. A continuacin, traceroute enviar otro paquete similar, pero con un TTL=2. El primer router del camino, R1 (cuya IP ya conocemos), decrementar el TTL, pero al ser ahora el TTL=1, podr seguir
Pgina 22
Como vemos en la imagen, el host de destino no nos responder con un Time Exceeded, ya que el paquete s que ha podido llegar hasta l antes de expirar. En lugar de eso, nos responder con otro mensaje ICMP, de tipo Echo Reply, que veremos ms adelante. Esto se debe a que los paquetes que va enviando traceroute son en realidad mensajes ICMP de tipo Echo Request. Como ya he dicho, ms adelante comprenderemos de lo que estoy hablando.
2.3. Problema de parmetros (Parameter Problem).

Este mensaje se enva cuando algn parmetro de la cabecera IP tiene un valor incorrecto, siempre y cuando no sea un campo que tenga ya otro mensaje ICMP especfico para notificar el error.
PC PASO A PASO N 23
Este es el formato del mensaje:
Destruyendo firewalls Como comentario sobre este tipo de mensaje ICMP comentar un exploit para una aplicacin en concreto, que siempre puede ser interesante.
Campo: Type El valor en este caso es 12. Campo: Code Aunque el RFC slo especifica un posible valor para este campo, en realidad pueden ser implementados otros valores (como ya ha pasado con otros campos vistos anteriormente). Estos son los posibles valores:
La aplicacin no es ni ms ni menos que Gauntlet Firewall , un firewall de Network Associates, la compaa del famoso (y bastante triste) antivirus McAffee que, por cierto, hace poco apareci la noticia de que es posible que Microsoft compre tambin esta compaa. El exploit que, por cierto, tambin afecta a otro producto de la misma compaa, WebShield, aprovecha una vulnerabilidad de estos programas que da lugar a una denegacin de servicio (DoS) con slo enviar un mensaje ICMP Parameter Problem malformado. El exploit, y su explicacin en castellano los tenis en: http://www.hakim.ws/ezines/RazaMexi cana/raza011/0x02.txt
El valor ms habitual es el Code 0. En este caso, el campo Pointer indicar la posicin de la cabecera IP en la que se encuentra el error. Conociendo la cabecera IP, podemos localizar el parmetro exacto cuyo valor es incorrecto. El Code 1 es usado cuando una trasmisin requiere opciones IP adicionales, como las usadas por el ejrcito de los EEUU al utilizar transmisiones seguras, en las que son requeridas ciertas opciones de seguridad en los datagramas. Sobre el Code 2 no hay mucho que decir, ya que se explica por s slo. Campo: Pointer Si el campo Code tiene valor 0, este campo especifica la posicin en bytes dentro de la cabecera IP donde se encuentra el parmetro errneo.
PC PASO A PASO N 23
2.4. Calmar al transmisor (Source Quench)

Este mensaje es til para implementar un control de flujo rudimentario. Ya he explicado algo sobre el control de flujo a lo largo del curso. Como su nombre indica, este mensaje permite calmar al transmisor cuando est enviando demasiados paquetes, y estos no pueden ser procesados debido a la excesiva velocidad. Cuando un paquete no pueda ser procesado adecuadamente debido a la
Pgina 23
saturacin del buffer de recepcin, habr que notificar esta situacin mediante un ICMP Source Quench . Cuando el transmisor reciba uno o ms Source Quench , debe bajar la tasa de transferencia para no seguir saturando al receptor. Este mecanismo es ms efectivo si el receptor empieza a enviar los Source Quench antes de que haya realmente un problema, es decir, cuando est cerca del lmite, pero sin haberlo superado an. El formato del mensaje nos es ya muy familiar:
avisando as de que no da a basto. Si estamos realizando un ataque de flood y empezamos a recibir mensajes Source Quench de la vctima tenemos una buena prueba de que nuestro ataque est funcionando. Por otra parte, el Source Quench mismo puede servir para realizar ataques DoS. Si enviamos mensajes Source Quench a la vctima le estaremos pidiendo que limite su ancho de banda porque supuestamente nos est saturando. Si conseguimos suplantar la personalidad de una mquina a la que est conectada la vctima (mediante spoofing) podremos echar abajo esa conexin, limitando cada vez ms el ancho de banda.
2.5. Redireccionar (Redirect)

Campo: Type El valor es 4. Este mensaje, bastante peligroso, se utiliza cuando un router R recibe un paquete que debe llevar hasta un destino, pero se da cuenta de que existe un camino ms corto hasta ese destino que no pasa por R. Ve a m o s p o r e j e m p l o e s t e c a s o :
Campo: Code Aqu es siempre 0. Denegacin de servicio y Source Quench Algunos de los ataques que he comentado aprovechando el protocolo ICMP son ataques de tipo Flood, es decir, ataques DoS que funcionan mediante un bombardeo masivo de paquetes. Es posible que un sistema que est siendo floodeado intente calmar al atacante envindole mensajes ICMP Source Quench, pensando que el bombardeo no es malintencionado y, por tanto,
Pgina 24
PC PASO A PASO N 23
La mquina H1 enva un datagrama al router R1 para que lo transmita hasta la mquina H2. El router R1 mira en su tabla de enrutamiento y descubre que para llegar a H2 tiene que pasar primero por R2. Analizando las direcciones de R2 y H1 deduce que ambos pertenecen a la misma red, por lo que H1 podra acceder directamente a R2 sin necesidad de pasar por R1. Si no notificase esta situacin a H1 toda la comunicacin entre H1 y H2 seguira el siguiente camino:
Veamos el formato del mensaje:
Campo: Type El valor es 5. Campo: Code De nuevo, tenemos varios posibles valores para este campo:
El segundo caso, Code 1, es el explicado en el ejemplo anterior. El Code 0, es lo mismo, pero en lugar de tratarse de un host de destino se trata de toda una red. Mientras que si avisa de esta situacin mediante un ICMP Redirect, podra ahorrarse un salto en el camino yendo de forma ms directa: Para el Code 2 y el Code 3 hay que anticipar de nuevo algo sobre el protocolo IP, que an no hemos visto. Uno de los campos de la cabecera IP es el TOS (Type Of Service), o Tipo de Servicio. Este campo permite definir diferentes servicios en funcin del ancho de banda, fiabilidad, e interactividad que requieren. Por ejemplo, un servicio de transferencia de archivos requiere mucho ancho de banda pero poca interactividad, mientras que un servicio de terminal remota (como un telnet) generalmente necesitar poco ancho de banda, pero mucha interactividad. Todo esto ya lo veremos en detalle cuando hablemos del protocolo IP.
Pgina 25
PC PASO A PASO N 23
En ciertos casos, un determinado router puede estar ms dedicado a transmitir cierto tipo de servicio, por lo que se puede optimizar la comunicacin utilizando los caminos adecuados para cada caso. El RFC 1349 da detalles sobre el campo T O S y s u r e l a c i n c o n I C M P, concretamente con los ICMPs Redirect, y Destination Unreachable (donde vimos que los Code 11 y 12 tambin se refieren al tipo de servicio). Campo: Gateway Internet Address Para los que an no lo sepis, un gateway es lo que nosotros estamos llamando un router, por lo que este campo indica precisamente la direccin IP del router al que queremos redireccionar el trfico. Por ejemplo, en el caso citado anteriormente, el router R1 enviara un mensaje ICMP Redirect donde este campo contendra la direccin IP del router R2. Super Source Quench, y otras historias Entre los mil usos ilegtimos que se pueden hacer de los mensajes ICMP Redirect , se encuentra el ataque conocido como Super Source Quench. A pesar de que su nombre pueda confundirnos, este ataque no tiene nada que ver con el ICMP Source Quench, aunque s que es cierto que, si bien un Source Quench puede ralentizar tu conexin, un Super Source Quench lo que hace es tirrtela por completo. El ataque consiste simplemente en enviar un mensaje ICMP spoofeado (para que aparentemente provenga de un router
Pgina 26
legtimo) de tipo Redirect, en el cual el campo Gateway Internet Address contenga la propia direccin IP de la vctima. Si la vctima es vulnerable a este ataque, desde que reciba el paquete de Super Source Quench, redirigir todo su trfico hacia si mismo, dando lugar a un bucle infinito de tres pares de narices. El Super Source Quench es, por supuesto, un ataque de tipo DoS, pero gracias a los paquetes Redirect de ICMP se pueden llevar a cabo todo tipo de ataques de lo ms variopintos. Existen herramientas para automatizar este tipo de ataques, como WinFreez, que permiten realizar ataques DoS, ataques de suplantacin man in the middle, etc, etc. En el momento que tienes el poder de redirigir el trfico de una vctima hacia donde t quieras los lmites slo los pone tu imaginacin.
2.6. Peticin de Eco (Echo Request)

Este es uno de los mensajes ICMP ms interesantes, aunque en principio pueda parecer tan simple que carezca de inters. Adems de utilizarse en la herramienta traceroute, como ya vimos, es tambin la base del funcionamiento del famoso PING , ya que su funcin consiste simplemente en solicitar a otra mquina que nos devuelva lo que le decimos, como si de un eco se tratase. Un mensaje Echo Request contendr unos pocos datos de muestra (por ejemplo, se suele usar el abecedario: abcdefghijklmnopqrstuvwxyz), y el host que lo reciba debera responder mediante otro mensaje ICMP diferente, que es el
PC PASO A PASO N 23
Echo Reply (lo veremos a continuacin), que contendr los mismos datos de muestra (el abecedario de nuevo, por ejemplo).
mensaje concreto de Echo Request, para que el Echo Reply correspondiente pueda especificar a qu peticin de eco en concreto est respondiendo. El campo Sequence Number simula de manera muy rudimentaria un nmero de secuencia TCP, siendo por tanto un n m e r o q u e s i m p l e m e n t e s e va incrementando con cada Echo Request para un mismo Identifier. De nuevo, el estndar nos deja libertad para que utilicemos este campo segn las necesidades. Campo: Data Este campo contiene los datos de muestra que queremos que nos sean devueltos, como cuando gritamos Eco! y nos vuelve la respuesta Eco!.... En lugar de Eco podramos poner cualquier otra palabra, como el ya mencionado abecedario. As que ya sabis, cuando vayis por la montaa y encontris a un to que est berreando el abecedario abcdefghijklmnopqrstuvwxyz, no debis asustaros, ya que slo ser un friki con una indigestin de mis artculos que habr terminado creyndose que es un PC y est intentando hacer un ping Sobre el mensaje Echo Request no voy a comentar nada de momento (en color rojo, me refiero , ya que comentar luego juntos los mensajes Echo Request y Echo Reply despus de hablar sobre ste ltimo.
Como vemos, el formato del mensaje es ms complejo que el de los anteriores tipos de ICMP. Campo: Type En este caso el valor es 8. Campo: Code Siempre tomar valor 0. Campo: Identifier Este campo simula en cierto modo el comportamiento de los puertos UDP, aunque de forma mucho ms simple. Simplemente es un nmero que sirve para identificar una sesin de mensajes de eco. Se usa por ejemplo cuando hacemos un ping a una mquina, ya que siempre se har ms de un Echo Request a la misma mquina. Toda esta serie de Echo Request que componen un ping tendrn normalmente el mismo valor en el campo Identifier. Realmente, el estndar no exige ninguna forma concreta de generar este campo, por lo que se deja un poco a las necesidades de cada aplicacin. Campo: Sequence Number Este campo, combinado con el anterior, permite identificar unvocamente un
PC PASO A PASO N 23
2.7. Respuesta de Eco (Echo Reply)

Este mensaje tiene exactamente el mismo formato, con los mismos campos.
Pgina 27
Todos los campos de la cabecera deben llevar una copia exacta de los campos del mensaje Echo Request al que estn respondiendo, excepto el campo Type, que debe ser 0, que es el nmero asignado al tipo de mensaje ICMP Echo Reply. La invasin de los pitufos No se puede hablar de ICMP sin hablar de una de las tcnicas ms clsicas para explotar este protocolo con fines poco ticos, que es la conocida como el pitufo. Jejeje, bueno, sta sera la traduccin al castellano. En realidad el trmino tcnico es smurf. La tcnica de smurf consiste en un ataque DoS basado en los mensajes Echo Request y Echo Reply, y que se puede llevar a cabo sin necesidad de ninguna herramienta especial, ni siquiera un software para manipular raw sockets (como Nemesis o Hping, sobre los que hablar al final del artculo), si no que basta con la herramienta PING que podemos encontrar en cualquier sistema operativo. El ataque consiste exactamente en un flood mediante mensajes Echo Reply generados por mquinas que no son la del propio atacante, por lo que se hace bastante complicado para la vctima el encontrar al culpable. Va m o s a v e r exactamente: en qu consiste
Como ya sabemos, todas las mquinas de una red estn interconectadas, por lo que tericamente todos los paquetes que circulan por la red llegan a todas las mquinas de la red. Cada mquina tendr que ser capaz de discernir qu paquetes van dirigidos a ella y cuales no. Este es el motivo por el que un sniffer puede funcionar. Lo que hace el sniffer es poner a la mquina en modo promiscuo, es decir, hacer que recoja todos los paquetes, aunque no sean dirigidos para esa mquina. Una mquina que no est en modo promiscuo slo debera recoger dos tipos de paquetes: los que van dirigidos a su direccin IP, y los que van dirigidos a la direccin broadcast. Por tanto, qu pasara si envisemos un mensaje Echo Request a la direccin broadcast de una red? Pues tericamente todas las mquinas de la red tendran que recibir ese mensaje y, por tanto, enviar un Echo Reply en respuesta. Imaginemos que estamos en una red con mil mquinas. Con slo enviar nosotros un mensaje, habremos recibido mil mensajes en respuesta... Qu pasara entonces si envisemos ese Echo Request con la IP de origen spoofeada para aparentar que quien manda el mensaje no somos nosotros, si no la mquina de nuestra vctima? Pues, tericamente, la vctima recibira 1000 mensajes Echo Reply que no tiene ni idea de dnde narices han salido. Sabr que las respuestas llegan de las mquinas de la red que hemos utilizado, pero no podr saber quin dio la orden a esa red de que le mandase los mensajes. Si lanzamos varios Echo Request a varias redes diferentes, podremos conseguir que llegue un autntico bombardeo de
PC PASO A PASO N 23
Todas las redes tienen definidas una direccin especial, que es la denominada direccin broadcast. Esta direccin IP especial est reservada para paquetes que estn dirigidos a todas las mquinas de la red, y no a una sola.
Pgina 28
mensajes Echo Reply a la vctima, con lo que podramos llegar a saturar su conexin.
Para evitar convertir nuestra red en una amplificadora de ataques smurf, tenemos que configurarla para que las mquinas no respondan a mensajes ICMP dirigidos a la direccin broadcast. El ping de la muerte Que nadie se eche las manos a la cabeza diciendo: Pero si el ping de la muerte est ms pasado de moda que las patillas de Curro Jimnez!. Es cierto que el ping de la muerte es un ataque que difcilmente puede funcionar hoy da, pero en su momento fue una autntica bomba as que merece al menos una mencin en este artculo en el que no slo se trata la actualidad, si no tambin la historia de ICMP. Digo lo de bomba porque es importante diferenciar entre un DoS de tipo flood, y un DoS de tipo nuke. Un flood ya hemos visto lo que es: tirar abajo un sistema a base de saturarlo con miles de paquetes. En cambio, un nuke es un ataque que tambin puede tirar abajo un sistema, pero en este caso con slo uno o unos pocos paquetes. Vimos un ejemplo de nuke al hablar del ICMP Parameter Problem, y un ejemplo de flood por ejemplo en la tcnica de smurf mencionada anteriormente. El ping de la muerte (ping of death), y sus variantes (como el jolt, o el IceNewk) es un ataque DoS de tipo nuke que explota una limitacin de los sistemas operativos, ya que estos suelen tener limitado a 65536 el tamao mximo de paquete que pueden manejar. No confundamos este tamao con la MTU, ni con el MSS, ya que en este caso se refiere al tamao que puede manejar el
Pgina 29
Como vemos en la imagen, lo nico que tiene que hacer el atacante es lanzar unos cuantos pings, uno por cada red que quiera utilizar como amplificadora del ataque, utilizando en cada uno la direccin de broadcast, que es la que vemos en la imagen. Una direccin broadcast normalmente se obtiene poniendo un 255 en aquellos bytes de la IP que puedan variar segn el tipo de red, es decir, poniendo un 255 donde en la mscara de red hay un 0. Por ejemplo, para una red 192.168.1.1, con mscara de red 255.255.255.0, la direccin broadcast ser 192.168.1.255. En general, para una red de clase A habr que poner un 255 en las 3 ltimas cifras de la IP, en una red de clase B un 255 en las 2 ltimas cifras de la IP, y en una red de clase C un 255 slo en la ltima cifra de la IP. Qu no sabis de qu hablo? Pues esperad al prximo artculo del curso, que tratar sobre el protocolo IP.
PC PASO A PASO N 23
propio sistema operativo, y no el tamao de los paquetes que se pueden transmitir a travs de una conexin. Como la MTU siempre ser menor de 65536 la forma en que se consegua enviar el ping de la muerte era utilizando la fragmentacin de la que ya hemos hablado. El ping de la muerte consista simplemente en un mensaje Echo Request de un tamao mayor que el que poda manejar el sistema operativo receptor, que se enviaba fragmentado para que pudiese circular hasta su destino. Una vez en el destino, el sistema receptor intentaba reensamblar el paquete uniendo los fragmentos y, al encontrarse con que el paquete era ms grande de lo que poda manejar, el sistema directamente cascaba. Este problema fue descubierto en 1996, y en 1997 la mayora de los sistemas operativos ya disponan de parches para arreglar este problema, pero.... quin sabe cuntos sistemas pueden quedar ah fuera sin parchear?... Tneles para pasar informacin a travs de firewalls Un sistema que es utilizado por programas maliciosos, como troyanos, demonios de redes DDoS, o cualquier otra aplicacin que necesite pasar informacin a travs de un firewall, es el crear un tnel mediante mensajes ICMP. Qu os ha sonado muy raro eso de los demonios de redes DDoS? Jeje, he conseguido despertar vuestra curiosidad una vez ms soltando por ah un trmino raro como quien no quiere la cosa. Pues si queris saciar vuestra curiosidad podis leer este documento en castellano:
Pgina 30
http://www.fi.upm.es/~flimon/ddos.pdf Es un documento muy interesante y fcil de leer, en el que encontraris tambin una descripcin detallada del ataque smurf que mencion anteriormente. Antes de que me vaya ms del tema, estaba diciendo que se puede aprovechar un mensaje ICMP para pasar informacin sin que un firewall se entere. Si tenemos, por ejemplo, un troyano en nuestro sistema, pero tenemos un firewall, lo que no podr hacer el troyano es abrir un puerto TCP en escucha para que su controlador se conecte remotamente a nuestra mquina para hacernos todo tipo de judiadas. Como los firewalls son cada da ms comunes, los troyanos tienen que buscar otros sistemas ms ingeniosos para poder comunicarse con su controlador. Uno de estos sistemas consiste precisamente en aprovechar los mensajes Echo Request y Echo Reply. Como hemos visto, ambos mensajes contienen un campo DATA en el que se puede meter cualquier cosa... pues simplemente intercambiando mensajes de Echo que contengan todos los datos que queramos transmitir entre el troyano y su controlador, estos podrn realizar una comunicacin bastante similar a la que podran llevar a cabo a travs de un puerto UDP. Otra historia es si el firewall filtra tambin los mensajes ICMP, pero en la mayora de los sistemas se deja abierto el Echo Request hacia el exterior, y el Echo Reply desde el exterior, por lo que el troyano podra utilizar Echo Request para enviar sus datos, y el controlador del troyano podra utilizar Echo Reply para lanzar sus rdenes.
PC PASO A PASO N 23
2.8. Peticin de Sello de Tiempo y Respuesta de Sello de Tiempo (Timestamp Request y Timestamp Reply)
Estos mensajes, al igual que los anteriores, tambin son una pareja. El Timestamp sirve para medir los tiempos de respuesta en una comunicacin entre dos mquinas. El mensaje Timestamp Request enva un dato con el instante en que el mensaje fue enviado, y el mensaje de respuesta Timestamp Reply contendr otros datos informando sobre el tiempo que tard el paquete en ser procesado, tal y como veremos en breve.
momento exacto en el que el emisor del Timestamp Request envi el mensaje. Este tiempo se mide en milisegundos transcurridos desde la medianoche Campo: Receive Timestamp Este campo se generar en el mensaje Timestamp Reply . Especifica el momento exacto en el que el receptor del Timestamp Request (que, por supuesto, ser el emisor del Timestamp Reply) recibi el mensaje Timestamp Request. Campo: Transmit Timestamp Este campo se genera tambin en el mensaje Timestamp Reply. Especifica el momento exacto en el que el emisor del Timestamp Reply envo el mensaje. Comparando este campo con el anterior podemos hacernos una idea del tiempo que se ha tardado en procesar los mensajes. Explotando sistemas de seguridad basados en el tiempo
Campo: Type El tipo para el mensaje Timestamp Request es 13 , y para el mensaje Timestamp Reply es 14. Campo: Code Es siempre 0 en ambos mensajes. Campos: Identifier y Sequence Number Tienen el mismo significado que en el caso de Echo Request y Echo Reply. Campo: Originate Timestamp Este campo es generado en el mensaje Timestamp Request . Especifica el
PC PASO A PASO N 23
Muchos sistemas de seguridad dependen de la generacin de nmeros pseudoaleatorios. Un ordenador es una mquina totalmente determinista, por lo que es imposible conseguir que genere un nmero totalmente aleatorio, es decir, sin estar basado en ninguna regla matemtica que lo genere. Lo que se suele hacer para simular esta aleatoriedad es aprovechar un parmetro que est en permanente cambio: el tiempo. Los nmeros pseudoaleatorios que genera un ordenador suelen estar basados en una frmula matemtica que incluye como
Pgina 31
una de sus variables el tiempo exacto en el que se est generando el nmero (en milisegundos, o cualquier otra medida). Esto permite que dos nmeros generados consecutivamente con la misma frmula den resultados diferentes. Por tanto, el permitir que cualquier mquina nos pregunte la hora exacta (con precisin de milisegundos) que tenemos en nuestra mquina, es facilitarle en gran medida la explotacin de cualquier sistema que maneje nmeros aleatorios. Recordemos por ejemplo lo que cont en el artculo sobre TCP acerca de los nmeros de secuencia, y de las graves consecuencias que tendra que un atacante conociese los nmeros pseudoaleatorios que hemos utilizado para generar los nmeros de secuencia en nuestras conexiones TCP. Tambin cont algo sobre la adivinacin de nmeros pseudoaleatorios en el artculo sobre DNS de la serie RAW, as que a los aficionados a las matemticas les recomiendo que le echen un vistazo.
directamente en red, y nada ms arrancar necesitaban conocer la red en la que entraban. El mecanismo consista en enviar un datagrama que tuviese ceros en las direcciones IP de origen y de destino (Information Request). Este paquete, al ser recibido por la mquina que se encargase del asunto dentro de la red, sera respondido con otro mensaje que s que tuviese direcciones IP de origen y de destino ( Information Reply ). La direccin IP de destino del Information Reply sera la IP asignada a la mquina que la solicit.
Ya conocemos el significado de todos los campos, as que slo hay que decir que el campo Type para Information Request es 15, y para Information Reply es 16. El campo Code para ambos ser 0. Buscando vctimas potenciales Uno de los usos ms clsicos de ICMP para fines oscuros es el de la deteccin de mquinas en una red, para apuntar vctimas potenciales. No he hablado de ello hasta ahora porque el sistema ms obvio y ms comn es utilizar simplemente un escaneo de pings que vaya recorriendo todas las posibles IPs para ver cules de ellas responden al ping. Cada IP que responda es una mquina que est funcionando en la red y, por tanto, una vctima potencial. Como este sistema es bien conocido por cualquier administrador que vigile mnimamente la seguridad, es fcil
PC PASO A PASO N 23
2.9. Peticin de Informacin y Respuesta de Informacin (Information Request, e Information Reply)

Esta nueva parejita de mensajes est en realidad obsoleta, ya que su funcionalidad ha sido sustituida y mejorada por otros sistemas, como BOOT o DHCP . Al igual que en estos protocolos, el objetivo de estos mensajes es conseguir que una mquina entre en una red de forma automatizada, es decir, sin conocer previamente la configuracin de la red. Este sistema era til en estaciones de trabajo sin disco que arrancaban
Pgina 32
encontrarse con sistemas que tengan cerrados los mensajes de Echo, por lo que no responderan al Echo Request, aunque la mquina estuviese vivita y coleando. Un escaneo de pings nos dira que esas mquinas no existen, ya que no han respondido a nuestra llamada. Existen herramientas que aprovechan otros tipos de mensajes ICMP menos comunes para hacer exactamente lo mismo, con la ventaja de que, al ser un mensaje poco conocido y, aparentemente inocente, es ms probable que el administrador no los haya cerrado en el firewall. Un ejemplo de estas herramientas es ICMPEnum, que utiliza precisamente no slo Echo Request para hacer los escaneos, si no tambin Timestamp Request, e Information Request. Como ya hemos visto que los dos primeros tienen otros problemas potenciales de seguridad, quiz podamos tener suerte y encontrarnos con que el administrador ha considerado totalmente inofensivo el Information Request, y haya dejado aqu la puerta abierta que buscbamos. Cul es la conclusin que podemos sacar de este comentario rojo y de todos los dems? Pues, abreviando, que si queremos estar seguros lo mejor es cerrar en nuestro firewall CASI TODOS los mensajes ICMP. Como mucho, podemos dejar entrar los mensajes de respuesta (como Echo Reply), para poder hacer ping y traceroute nosotros desde nuestra mquina, pero pocos motivos hay para dejar abiertos sus contrarios, los mensajes que, en lugar de respondernos, nos preguntan a nosotros desde fuera.
PC PASO A PASO N 23
Yo personalmente tengo abiertos slo los mensajes Echo Reply (para poder hacer ping y traceroute), Time Exceeded (para poder hacer traceroute), y Destination Unreachable (para poder hacer P-MTUD, entre otras cosas). Si queris asegurar de verdad vuestro sistema o vuestra red os aconsejo que investiguis bien el tema y lleguis a establecer una decisin sobre vuestra poltica de seguridad con ICMP.
2.10. Otros mensajes ICMP.

Aunque el RFC 792 ni siquiera los menciona, existen otros tipos de mensaje ICMP definidos. Al no formar parte del estndar definido en el RFC, slo nombrar alguno de ellos por si os interesa buscar informacin sobre alguno en concreto. Personalmente, yo no me he encontrado nunca con casi ninguno de estos mensajes ICMP, as que no s hasta qu punto ser til conocerlos.
Como de costumbre, la lista completa de nmeros asignados a ICMP es mantenida por el IANA (Internet Assigned Numbers Authority), y la podis consultar en: http://www.iana.org/assignments/icmpparameters
Pgina 33
Buscando huellas He dejado para el final esta tcnica que es en realidad una de las que dan ms utilidad a ICMP a la hora de encontrar informacin sobre un sistema para un posible ataque. Lo he dejado para el final porque es una tcnica que est relacionada no con uno slo, si no con muchos tipos de mensajes ICMP. La tcnica conocida como OS Fingerprinting consiste en analizar las reacciones de un sistema ante distintos tipos de mensajes ICMP y, conociendo cual es la reaccin de cada sistema operativo conocido, poder realizar as una comparacin que nos lleve a deducir qu sistema operativo est corriendo en la mquina que estamos analizando. Hay una panda de chiflados (con cario) que se dedican a hacer tablas que reflejan el comportamiento de cada sistema ante cada tipo de mensaje, aunque no llegan a estar tan chiflados como para tratar de usar es informacin a palo seco... lo que hacen es introducir toda esta informacin en una aplicacin que automatiza la tarea de comparar las reacciones del sistema con la informacin conocida sobre cada sistema operativo. La ms conocida de esas aplicaciones es NMap , de la que ya hemos hablado bastante en la revista. Nmap contiene gran cantidad de informacin sobre las reacciones de cada SO ante determinados paquetes, y utiliza esta i n f o r m a c i n p a ra h a c e r u n O S Fingerprinting, es decir, para deducir cul es el sistema operativo de la mquina que estamos analizando. Para que os hagis una idea del tipo de informacin de la que estoy hablando, podemos mostrar por ejemplo este rbol:
Pgina 34
Aqu vemos que ante un mensaje ICMP TimeStamp Request a la direccin broadcast de una red, podemos obtener informacin precisa sobre el sistema operativo, siempre que la mquina responda con un TimeStamp Reply. En caso de que no responda, se considerar (de momento) un SO desconocido, y habr que hacer otras pruebas similares. Si ha respondido, tenemos 3 posibles SOs: HPUX 10.20, Sun Solaris, o Linux Kernel 2.2.x. En ese caso, habr que continuar con la prueba, haciendo ahora un Information Request a la direccin broadcast. Si responde, ya sabemos que se trata de un HPUX 10.20 . Si no responde, habr que continuar probando, esta vez con un Address Mask Request (uno de los ICMPs que no hemos visto). Si responde, se trata de un Sun Solaris, y si no, de un Linux Kernel 2.2.x. Esta informacin tambin se puede mostrar en tablas ms complejas, como sta, que muestra el valor del campo TTL que usa cada sistema operativo al enviar mensajes ICMP de Echo:
PC PASO A PASO N 23
Como ya he dicho, esta informacin no nos hace falta conocerla, ya que viene automatizada en herramientas como Nmap , o Xprobe , pero si queris informacin detallada y tenis los c*j*n*s... como los de un toro, podis leeros la biblia del ICMP, que la tenis en h t t p : / / w w w . s y s security.com/archive/papers/ICMP_Sca nning_v3.0.pdf .
-P : permite especificar un archivo con los datos, por ejemplo para un Echo Request. -G : permite especificar el campo Gateway Address para los mensajes Redirect. -qE : inyecta un paquete de Echo. -qU : inyecta un paquete Destination Unreachable. -qX : inyecta un paquete Time Exceeded. -qR : inyecta un paquete Redirect. -qT : inyecta un paquete Timestamp. Si, por ejemplo, queremos lanzar un ataque Super Source Quench a la IP 192.168.2.2 para cortar su conexin TCP con la IP 215.22.69.22, podramos hacer: nemesis icmp i 5 c 1 G 127.0.0.1 v b 192.168.2.2 B 215.22.69.22 D 192.168.2.2 S 215.22.69.22 p 6 El parmetro i 5 especifica que se trata de un mensaje de tipo Redirect, que sera como utilizar la opcin qR . El parmetro c 1 especifica un Code 1, es decir, redireccionar los datagramas para el host de destino. El parmetro G 127.0.0.1 es la base del ataque Super Source Quench, ya que indicamos aqu a la vctima que redirija sus paquetes a la direccin de loopback , 127.0.0.1 , es decir, a s mismo. El parmetro v es el clsico verbose que nos muestra informacin de lo que estamos haciendo. El parmetro b no lo he explicado, y forma parte del campo Internet Header + 64 bits of Original Data Datagram. Es concretamente la IP de origen del
Pgina 35
3.
RAW Sockets ICMP
Para terminar, volvemos con nuestros amigos Nemesis y Hping para jugar esta vez con el protocolo ICMP. Existen herramientas dedicadas para explotar el protocolo ICMP, como algunas de las ya mencionadas, o la herramienta SING (Send ICMP Nasty Garbage), pero por no romper la tradicin vamos a seguir en nuestra lnea, utilizando las herramientas ya conocidas.
3.1. Nemesis
Empezamos con Nemesis, cuyas instrucciones tenemos en el archivo nemesis-icmp.txt de la carpeta en la que instalamos la aplicacin. Resumo aqu las opciones ms bsicas: -i : permite especificar el valor del campo Type. -c : permite especificar el valor del campo Code. -e : permite especificar el valor del campo Identifier.
PC PASO A PASO N 23
datagrama que gener el supuesto error que dio lugar a que se generase el mensaje Redirect. El parmetro B forma parte tambin de ese campo, y contiene la direccin IP de destino del datagrama original que supuestamente origin el Redirect. Los parmetros D y S ya los conocemos de haber usado otras veces Nemesis, y son la IP de destino y de origen respectivamente para este mismo paquete. El parmetro p 6 forma parte tambin del campo Internet Header + 64 bits of Original Data Datagram, ya que es el nmero de protocolo de transporte que haba especificado en el datagrama original, el cual, al tratarse de TCP, ser 6. Por supuesto, os muestro este ejemplo slo para mostrar el funcionamiento de Nemesis ICMP, y no garantizo que vaya a funcionar.
--spoof :permite especificar cualquier IP de origen (IP spoofing). --rand-source : permite hacer un IP spoofing con direcciones IP aleatorias. --rand-dest : permite utilizar direcciones IP de destino aleatorias. Algo parecido a lo que expliqu que hacan algunos gusanos, aunque en realidad lo normal es que un gusano utilice algn tipo de heurstica para generar las IPs de una forma ms inteligente que una aleatoriedad pura y dura. --dont-frag : obliga a que el paquete no sea fragmentado. Esta opcin puede ser t i l p a ra r e a l i z a r u n P - M T U - D . --tos : permite definir el tipo de servicio que, como hemos visto, est relacionado con algunos mensajes ICMP. --ttl : permite marcar un tiempo de vida para el paquete IP. Como ya sabemos, esto nos permite, entre otras cosas, hacer un traceroute. --tr-keep-ttl : esta opcin, combinada con la anterior, permite investigar un router en concreto del camino. Esta opcin fija el valor de ttl, por lo que podramos enviar varios paquetes, por ejemplo, al cuarto router del camino haciendo: --ttl 4 --tr-keep-ttl. Por ltimo, algunas de las opciones especficas para ICMP. Por supuesto, tenis todo mucho mejor explicado en man hping2 : --icmptype : permite especificar un Type en la cabecera ICMP. --icmpcode : permite especificar un Code en la cabecera ICMP. --icmpipproto : podemos especificar tambin los valores del campo Internet
PC PASO A PASO N 23
3.2. Hping2
Vamos a ver algunas de las opciones que nos da hping2 para ICMP. En primer lugar, veamos las opciones generales: --verbose : el clsico modo verbose para ver informacin en pantalla. --count : permite especificar el nmero de paquetes que queremos enviar. --traceroute : este es un modo especial que permite hacer un traceroute. Con respecto a la parte IP que, por supuesto, tambin es necesaria para generar paquetes ICMP, tenemos:
Pgina 36
Header + 64 bits of Original Data Datagram. Por ejemplo, este parmetro es para especificar el nmero de protocolo del datagrama que origin el mensaje ICMP. --icmpcksum : nos permite generar un checksum invlido. Por defecto, si no ponemos esta opcin, hping2 generar automticamente el checksum correcto. --file : permite especificar un fichero para el campo de DATOS. Vamos a ver un ejemplo sencillsimo, para realizar un ataque smurf a la IP 217.138.2.2, utilizando como amplificadora la red 209.5.x.x : hping2 209.5.255.255 --icmp -verbose --spoof 217.138.2.2 As de simple! Por cierto, que tenis disponibles listas de redes que han sido probadas y se sabe que pueden funcionar como amplificadores smurf (es decir, que responden a paquetes Echo Request a la direccin broadcast ). Podis encontrar un registro de estas redes por ejemplo en: http://www.powertech.no/smurf/ . Aunque pueda parecer que este tipo de listas son mantenidas por lamers que dedican su tiempo a ir destruyendo mquinas ajenas, en realidad su cometido suele ser justo el contrario. Se publican estas listas no para ayudar a los atacantes, si no para que la gente que quiera configurar su firewall pueda filtrar directamente todas las redes que sean susceptibles de convertirse en fuentes de un ataque smurf. Pero claro, en realidad al final el resultado suele ser el contrario del esperado. Est
PC PASO A PASO N 23
claro que no todo el mundo consulta estas pginas para protegerse, y en cambio basta con que una sola persona consulte esta lista con fines perversos para que pueda atacar a cualquier otra persona que no haya tenido en cuenta la lista. As que, una vez ms, no se sabe si es peor el remedio o la enfermedad. Espero que este artculo os haya resultado interesante, y que por lo menos haya despertado en vosotros la curiosidad por muchsimas cosas que he esbozado para que vosotros ampliis informacin de lo que ms os haya llamado la atencin. Por este artculo han circulado muchos nombres que pueden ser fcilmente consultados en Google, as que os animo a que lo hagis. Autor: PyC (LCo)
Pgina 37
CURSO DE TCP/IP: LA CAPA IP

(primera parte).
LAS DIRECCIONES IP.

Este mes vamos a descubrir qu es realmente una IP, qu es una Direccin de Red, qu son y cmo funcionan las Mscaras de Red, cmo un paquete es encaminado en una red, cmo se reparten el pastel de los rangos de IPs los ISPs y muchas cosas mas.
INTRODUCCIN
Este mes empezamos con uno de los puntos ms interesantes: la capa de red, es decir, la capa IP, que es una de las que dan su nombre a toda la pila de protocolos que componen el llamado TCP/IP. Mucho hay que decir sobre esta capa, quiz la ms importante, por lo que de momento esta primera entrega la dedicar nicamente a presentar algunos de los conceptos relacionados con ella, concretamente todo lo referente a las direcciones IP. Mucho se ha mencionado a estos numerajos en la revista, pero pocas veces se ha entrado en detalle sobre lo que realmente son y cmo funcionan. A lo largo de este artculo veremos en detalle en qu consiste una direccin de red, cmo funcionan las mscaras, el encaminamiento en una red TCP/IP como Internet, las clases de redes, las direcciones reservadas, las redes locales , las direcciones broadcast , e introduciremos otros protocolos relacionados, como son el DHCP o el ARP. Dejo ya para otro artculo la explicacin de la cabecera IP, as como el funcionamiento detallado del protocolo.
PC PASO A PASO N 24
Si todo sigue el rumbo que espero, una vez que termine la parte bsica del curso de TCP/IP lo completar con un artculo dedicado al protocolo IPv6. Este es una nueva versin del protocolo IP, an no extendida mundialmente, que es el futuro para una Internet que est llegando actualmente al lmite de sus posibilidades tcnicas. Una vez ms tengo que insistir en que mi forma de explicar las cosas no es la clsica, ya que pienso que es absurdo repetir una vez ms aquello que est explicado de la misma forma en mil sitios diferentes. Por tanto, aprovechando que esta revista se llama PC PASO A PASO, mi forma de explicar las cosas ser muy lenta, pero segura, no mostrando las cosas sin ms, si no llegando a ellas desde el fondo de los conceptos bsicos. As, ruego un poco de paciencia a aquellos que digan pero cmo puede estar explicando lo que es una mscara de red en 20 pginas, si en cualquier sitio est explicado en slo una pgina?, Mi intencin es que este curso no sea un curso ms de TCP/IP, si no un curso diferente, una alternativa para aquellos que estn cansados de encontrar una y otra vez la misma forma de contar las cosas (muchas veces imposible de entender por lo crptico del lenguaje utilizado) y una y otra vez muchas
Pgina 15
CURSO DE TCP/IP - LA CAPA IP - LAS DIRECCIONES IP - CURSO DE TCP/IP - LA CAPA IP
personas dejan de estudiar estos temas porque no llegan a entender lo que leen vamos a ver si conseguimos arrojar un poco de luz!!!
una comunicacin entre slo dos de ellos, ser imprescindible asignar a cada uno una direccin nica que permita identificarles unvocamente. As, la red telefnica tiene millones de abonados, pero cada uno de ellos tiene un nmero de telfono siempre diferente a los dems. Lo mismo ocurre con la red de correo postal, en la que cada persona tiene una direccin nica. En la red postal, la combinacin de la direccin de destino de la carta o paquete (lugar donde debe llegar el paquete), y el remite del mismo (lugar de donde se enva el paquete), definen claramente los dos elementos de la comunicacin. Lo mismo ocurre en la red telefnica, con la combinacin de los dos nmeros de telfono (al que llamas, y desde el que llamas). Internet es una red formada por millones de ordenadores de todo el mundo pero, a diferencia de lo que puede parecer, las comunicaciones son siempre entre slo dos ordenadores. Cuando entramos en un chat en el que hay 30 usuarios (o 50, o 200), en realidad todo funciona gracias a varios pares de conexiones entre los diferentes usuarios y un servidor central. Lo mismo ocurre cuando estamos jugando a un juego ON LINE en el que haya varios jugadores simultneamente, o en cualquier otro entorno en el que parezca que hay muchos ordenadores conectados entre s al mismo tiempo. As que repito: en Internet (y, en general, en cualquier red TCP/IP) jams se conectan directamente entre s ms de dos mquinas.
PC PASO A PASO N 24
1. LA FUNCIN DE LAS DIRECCIONES IP

El concepto fundamental de lo que es una direccin IP ya lo he repetido en varias ocasiones, pero es tan importante que ha de ser repetido una y otra vez, sobre todo para aquellos nuevos lectores que se incorporan ahora al curso de TCP/IP (aunque a estos nuevos lectores les advierto que van a tener muy complicado poder seguir el curso a partir de este punto sin haberlo pillado desde el principio).
Este curso...
Este curso es de los ms veteranos de la revista PC PASO A PASO. Se empez con la serie de artculos RAW (donde se trataron en profundidad los protocolos ms importantes) y se sigui con las serie TCP/IP (donde "asaltamos el corazn" de las comunicaciones por red). Aunque intentamos que cada artculo sea comprensible "en s mismo", llega un momento en que es muy difcil asumir el contenido de los mismos sin haber estudiado las anteriores entregas de la serie. Te recomendamos que pidas las revistas a n t e r i o r e s a u n a m i g o o l a s e n c a rg u e s e n www.hackxcrack.com. La funcin de una direccin IP es la misma que la de un nmero de telfono, o la de una direccin postal: identificar unvocamente a uno de los participantes en una red de comunicacin. En cualquier entorno en el que haya ms de dos elementos, y se desee establecer
Pgina 16
servidor de chat, que es el nico que conoce las direcciones IP de todos los usuarios del chat. Cmo sabe el servidor cul es la IP del usuario que se acaba de conectar? Pues sencillamente mirando la cabecera IP del paquete de inicio de conexin del usuario, ya que en todas las cabeceras IP estn siempre especificadas las direcciones IP de origen y destino del paquete, tal y como veremos en el prximo artculo, en el que detallaremos el formato de la cabecera IP. En la imagen vemos el ejemplo de un chat entre 4 personas, el cual funciona gracias a pares de conexiones entre cada usuario y el servidor central. Observamos tambin una quinta conexin, entre dos usuarios, que podra ser la transferencia de un archivo (por ejemplo, un DCC en una red de IRC). Por tanto, es fundamental que cada uno de los usuarios del chat conozca la direccin IP del servidor de chat. Una vez que ellos se conecten al servidor de chat, ste conocer tambin la direccin de ellos, igual que cuando recibimos una llamada de telfono podemos ver el nmero desde el cual nos estn llamando. Si bien en el telfono no es imprescindible conocer el nmero del que nos llama, en el caso de TCP/IP no sera posible la comunicacin si las dos partes no conocen perfectamente la direccin IP de su interlocutor. Para el caso de la transferencia del archivo que vemos en la imagen, sera necesario que uno de los dos usuarios conociese la direccin IP del otro para poder conectarse a l. Para esto, lo que hace es pedir esta direccin IP a travs del
PC PASO A PASO N 24
Los que no hayis seguido todos mis artculos probablemente os estaris preguntando ahora por qu he dicho que los usuarios del chat tienen que conocer la direccin IP del servidor para poder conectarse, ya que probablemente muchos de vosotros habris entrado en una red de IRC (o cualquier otro Chat) y jams habis tenido que aprenderos ningn nmero raro para poder conectar. Gracias a Dios (o ms bien al IETF ), los seres humanos no tenemos que tratar (normalmente) con todos esos numerajos difciles de recordar, si no que podemos utilizar unos nombres equivalentes mucho ms intuitivos, como: www.google.com, irc.efnet.nl, etc., etc. Esto se consigue gracias a un sistema llamado DNS que permite asociar un nombre ms humano a cada direccin IP. De esta forma, cada vez que queremos acceder a una mquina nos basta con conocer su nombre, y no los nmeros que forman su direccin IP. Cuando solicitamos una conexin con una mquina a partir de su nombre, nuestro ordenador (sin que nosotros nos enteremos), primero tendr que traducir el nombre de la mquina para obtener la
Pgina 17
direccin IP asociada, lo cual har mediante una serie de consultas a unos servidores especiales que conocen las direcciones IP asociadas a cada nombre. Una vez que ya tiene la direccin IP, se conectar a esa mquina sin que nosotros nos hayamos enterado del proceso. Desde nuestro punto de vista parece como si directamente pudisemos conectarnos conociendo slo el nombre, y no los numerajos. Todo el sistema DNS lo expliqu con todo detalle en la serie RAW de esta revista, hace ya varios meses, por lo que espero que el artculo est liberado para que lo podis bajar y comprender cmo funciona realmente todo esto. Ahora posiblemente os estaris haciendo otra pregunta: de dnde salen las direcciones IP? Est claro de donde salen los nmeros de telfono: es Telefnica la que asigna un nmero diferente a cada abonado. Tambin est claro de donde salen las direcciones postales: Correos asigna un cdigo postal a cada zona y el resto de la direccin postal depende de la calle y piso y puerta en el que viva cada usuario (el nombre de la calle lo pone el ayuntamiento y el piso y la puerta el constructor de la vivienda). En el caso de las direcciones IP, tambin tiene que haber algn organismo regulador que evite que dos mquinas tengan la misma direccin IP en una misma red. Este organismo es InterNIC, que se encarga de asignar unos rangos de direcciones IP a cada organizacin. InterNIC delega en cada organizacin para que asignen cada IP especfica a cada mquina dentro de ese rango.
Pgina 18
Ponemos un caso real y lo entenderemos rpidamente: CASO REAL TELEFNICA: Un buen da, Telefnica decide ofrecer a sus usuarios conexin a Internet y para ello necesita un montn de direcciones IP. Pues eso, llama a InterNIC y le dice que le pase un montn de IPs. InterNIC, una vez estudiada la peticin, le asigna a Telefnica un generoso rango de direcciones. Telefnica YA TIENE IPs!!! Ahora pone a sus genios de publicidad a trabajar y nos machaca con sus anuncios en todos los medios de comunicacin... contrata tu acceso a Internet con Telefnica y bla, bla, bla. Por cierto, uno de sus anuncios era muy interesante recuerdas el del mono?... en ese nos insultaba a todos los usuarios de Internet espaoles comparndonos con un mono (a tragar y a callar) Cuando T (o Yo) llamamos a telefnica y contratamos el acceso a Internet, NO ES INTERNIC quien te asignar una IP, ser TELEFNICA quien te asigne la IP. Por supuesto, TELEFNICA te dar una de las IPs que previamente INTERNIC le ha asignado a ella. Telefnica puede hacer con sus IPs LO QUE QUIERA!!! Desde drtela a ti (su nuevo cliente) hasta ceder (alquilar) a terceras compaas parte del rango que previamente le confi INTERNIC. Esta libertad para que el ISP de turno haga lo que quiera con su rango de IPs es lo que da lugar a la existencia de direcciones IP dinmicas. Nuestro ISP (proveedor de servicios de Internet, como
PC PASO A PASO N 24
Telefnica en este ejemplo) podr decidir asignarte una u otra IP en cada momento segn los usuarios que haya conectados, sin tener que dar explicaciones a InterNIC o ningn otro organismo. Mientras Telefnica se encargue de que nunca haya dos direcciones IP iguales, y de que nunca utilice una direccin IP que no est dentro de su rango asignado, podr cambiar a su gusto las direcciones IP de cada usuario segn le convenga.
Estos puntos lo que hacen en realidad es separar las cifras del nmero. Cifras? Pero si la primera cifra es 192! Yo pens que una cifra iba slo desde 0 hasta 9... Pues esto es as en la base que estamos acostumbrados a utilizar: la base 10, o base decimal. En base decimal tenemos las cifras 0, 1, 2, 3, 4, 5, 6, 7, 8, o 9. Pero pueden existir muchas bases diferentes, por ejemplo: la base 2 , o base binaria (nicamente hay 2 cifras): las cifras son slo 0, o 1. la base 16, o base hexadecimal (hay 16 cifras): hay ms cifras que en la base 10, siendo stas 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, y F
Desgraciadamente...
Desgraciadamente, cuando decimos que el ISP puede hacer "lo que quiera" con sus IPs, incluimos desagradables sorpresas: Hay ISPs que nicamente te ofrecen IPs Dinmicas. Esto provoca que no puedas tener ciertos servicios en tu PC (por ejemplo un servidor FTP) sin utilizar algn tipo de re-direccionamiento automtico por nombre (en anteriores nmeros de la revista ya explicamos como hacer esto con todo detalle). Hay ISPs que nicamente de dan una IP FIJA si la pides expresamente, pero sorpresa!!! Te cobrarn entre 6 y 24 euros al mes por tan "preciada" posesin.
Fjate que como...
Fjate que como se nos han acabado las cifras de la base decimal, para llegar a 16 cifras se utilizan letras. Los que se "inventaron" el sistema hexadecimal podran haber utilizado cualquier otro smbolo para sus cifras, por ejemplo letras griegas o "dibujitos" egipcios.
2. LAS DIRECCIONES IP TAL Y COMO SON

Hasta ahora he estado hablando de unos numerajos asumiendo que todos habis visto alguna vez una direccin IP, y espero que as sea. Para los nuevos (nuevsimos) de la clase os muestro aqu el aspecto de una direccin IP tal y como las solemos conocer: 192.168.2.15 Como vemos, es un nmero compuesto de 4 nmeros separados por puntos.
PC PASO A PASO N 24
Como vemos, la base 10 tiene 10 cifras diferentes, la base 2 tiene 2 cifras diferentes, y la base 16 tiene 16 cifras diferentes. Por tanto, la base 256 tendr... 256 cifras diferentes. Cada una de estas cifras estara comprendida entre 0 y 255 (1, 2, 3, 4 58, 59 102, 103 198, 199 253, 254 y 255). Una direccin IP no es ms que un nmero de 4 cifras en base 256. Por tanto, la primera cifra del nmero del ejemplo ser 192, la segunda 168, la tercera 2, y la ltima ser 15 ------> 192.168.2.15
Pgina 19
Y por qu se utiliza esta base tan rara cuando estamos acostumbrados a utilizar la base decimal de toda la vida? Pues porque, aunque las personas estemos acostumbrados a la base decimal , sta no es muy apropiada para las mquinas, que son las que realmente tienen que lidiar con las direcciones IP. Concretamente, a las mquinas slo les gusta la base 2 (binaria), y sus derivadas. Una base muy ntimamente ligada a la base 2 es la base 256, que es la que da lugar a la existencia de los famosos bytes, u octetos. Por tanto, cada una de las cifras de una direccin IP corresponde a un byte, por lo que cada direccin IP tiene un tamao de 4 bytes. Un byte es, en cierto modo, el tamao elemental de informacin que puede manejar una mquina (esto no es del todo as, pero es para que nos entendamos). Si no te ha quedado claro sigue leyendo Como he dicho, las mquinas slo entienden el lenguaje binario, pero esa IP que os he mostrado (192.168.2.15) est en realidad representada de forma que sea fcilmente comprensible para un humano (con cada cifra expresada en el clsico formato decimal). Cul es entonces el autntico aspecto de una direccin IP? Pues es, por supuesto, una fantstica ristra de ceros y unos, de esas que aparecen en las pelis de hackers. Veamos por ejemplo el autntico aspecto de la direccin del ejemplo:
11000000 . 10101000 . 00000010 . 00001111
Para lo que voy a explicar a continuacin es imprescindible que conozcis la forma de convertir una IP en su formato clsico (192.168.2.15) a su formato real, con todas las cifras binarias. As que ruego un poco de paciencia a los que estis ya un poco hartos de mi insistencia con el tema de la aritmtica binaria, porque voy a explicar de nuevo cmo convertir nmeros de decimal a binario, aunque en esta ocasin no voy a explicar el mtodo matemtico, si no el sistema que utilizo yo para poder hacerlo de cabeza, sin necesidad de lpiz y papel La gran ventaja de esta forma de cambiar de base decimal a binaria es que no es necesario realizar ninguna divisin, ni ninguno de los engorros que expliqu en aquel otro artculo. En cambio, la desventaja es que es necesario estar bastante familiarizado con la aritmtica binaria, hasta el punto de que hay que conocer de memoria todas las potencias de 2, con exponentes de 0 a 8. Quiz esto os suene a una especie de locura propia de un friki que slo sale de su casa para comprar ms memoria RAM o ms cafena, pero en realidad aprenderse estos nmeros es mucho ms fcil de lo que parece, ya que estos nmeros nos rodean a diario sin que nos demos cuenta. Las 9 primeras potencias de 2 son estas: 20 21 22 23 24 25 26 27 28 = = = = = = = = = 1 2 4 8 16 32 64 128 256
PC PASO A PASO N 24
Como vemos, cada cifra en base 256 est formada de 8 cifras binarias (cero o uno), por lo que una direccin IP consta de un total de 32 cifras binarias (bits).
Pgina 20
A que os suenan todos esos nmeros? Los veris cada vez que veis cualquier cosa relacionada con la informtica (la velocidad del ADSL, la capacidad de las tarjetas de memoria, etc, etc). Lo que yo hago para convertir un byte en su formato decimal al formato binario es: (mientras lees los pasos fjate en la imagen) PUNTO 1.- En primer lugar, miramos entre qu dos potencias de 2 est comprendido. Por ejemplo, para el caso del nmero 192, est comprendido entre 128 y 256. Por tanto, la cifra binaria correspondiente a 128 (27) tiene que estar a uno. PUNTO 2.- Para ver qu ms cifras estn a uno, cojo el 192 y le resto 128, y nos da como resultado 64. PUNTO 3.- Repetimos el proceso del punto 1 con este nuevo nmero, el 64: miramos entre qu dos potencias est comprendido el 64 y vemos que est entre 64 y 128. Por tanto la cifra 26, correspondiente al 64, tendr que estar tambin a uno. PUNTO 4.- Igual que en el PUNTO 2: ahora 64 64 = 0 , significa que tenemos ya el nmero exacto, y no hay que continuar el proceso. Por tanto, como hemos visto que hay que marcar a uno las cifras 7 y 6, contando 8 cifras empezando por la derecha, y siendo la primera la cifra 0, obtenemos la imgen:
Para el caso de 168 hacemos lo mismo: 168 est entre 128, y 256, por lo que marcamos la cifra 7; 168 128 = 40, que est entre 32 y 64, por lo que marcamos la cifra 5, correspondiente al 32; 40 32 = 8 que est entre 8 y 16, por lo que marcamos la cifra 3 , correspondiente al 8, y tenemos ya el nmero completo, pues 8 8 = 0. Nos queda 10101000 Para el nmero 2: 2 est entre 2 y 4, por lo que directamente marcamos la cifra 1, correspondiente a 21, y 2 2 = 0, por lo que ya tenemos el nmero, que ser una ristra de 7 ceros y un solo uno, en la segunda posicin empezando por la derecha. Nos queda 00000010 Para el nmero 15: vemos que est entre 8 y 16, por lo que marcamos la cifra 3; a continuacin hacemos 15 8 = 7, que est entre 4 y 8, por lo que marcamos la cifra 2 , correspondiente al 4; a continuacin hacemos 7 4 = 3, que est entre 2 y 4, por lo que marcamos la cifra 1; por ltimo, hacemos 3 2 = 1, que est entre 1 y 2, por lo que marcamos la cifra 0, y tenemos ya el nmero c o m p l e t o, q u e s e r 0 0 0 0 1 1 1 1 . Por lo tanto la IP en binario es:
11000000 . 10101000 . 00000010 . 00001111
3. LAS DIRECCIONES DE RED

En muchos casos la direccin IP por si sola no es suficiente para todas las necesidades de una comunicacin TCP/IP. Para entenderlo haremos el paralelismo con algo que todos conocemos: un nmero de telfono.
PC PASO A PASO N 24
Pgina 21
Un nmero de telfono consta de uno o varios prefijos, seguido del nmero ya propiamente dicho. La red telefnica utiliza estos prefijos para saber cmo dirigir el trfico de la red entre las distintas zonas. Podramos tambin hacer el paralelismo con el correo postal. El correo postal consta de un cdigo postal (que podra ser considerado como un prefijo), y el resto de la direccin. Como en los dos casos anteriores, tambin las direcciones IP tienen en cierto modo prefijos que permiten diferenciar diferentes zonas entre los diferentes usuarios de la red. En el caso del correo postal, la parte de prefijo que permite separar las zonas est claramente diferenciado del resto de la direccin (no hay forma de confundir el cdigo postal con el nombre de la calle). En cambio, en el caso del telfono ya es otro asunto. Por ejemplo, el prefijo para Madrid es el 91, mientras que el prefijo para Murcia es el 968, por lo que a priori no hay forma de saber hasta dnde llega el prefijo, ya que unos tienen 2 cifras, y otros tienen 3. Hasta hace unos aos, el prefijo no se marcaba cuando se estaba dentro de una misma provincia. Por tanto, si te decan: vivo en Madrid y mi telfono es el 915758976, no sabas si, estando en Madrid, tenas que marcar 5758976, o 758976, a no ser que supieses que el prefijo de Madrid es el 91, por lo que slo habra que prescindir de las dos primeras cifras.
Pgina 22
Actualmente, esto de los prefijos es ya transparente al usuario del telfono (siempre que llamamos a alguien marcamos prefijo y nmero, todo junto). ---los prefijos de las direcciones IP tambin son transparentes para los usuarios de Internet--En cambio, las mquinas de la red telefnica encargadas de conmutar los circuitos para comunicar a los dos abonados en una llamada s que necesitan diferenciar los prefijos, para as saber por dnde ir dirigiendo la llamada para crear un enlace entre los dos puntos. Del mismo modo, las mquinas encargadas de direccionar el trfico en una red TCP/IP (como Internet) necesitan conocer los prefijos de las direcciones IP para conseguir establecer un camino entre las dos mquinas que quieren comunicarse. Estas mquinas encargadas de direccionar el trfico TCP/IP suelen ser los denominados gateways o, por usar un trmino ms familiar, los routers . Por tanto, para conectar mediante TCP/IP con una mquina, no nos basta con saber su direccin IP, si no que tambin tenemos que conocer qu porcin de sta IP es prefijo, y cul no. Al igual que en los nmeros de telfono, los prefijos de las direcciones IP son de longitud variable, por lo que es imposible saber a priori qu parte de la IP es prefijo, y qu parte es la direccin propiamente dicha de nuestra mquina. Esto da lugar a la necesidad de que una direccin IP tenga que ir acompaada de otro nmero que indique simplemente cul es la longitud del prefijo dentro de esa IP. En el caso de los nmeros de telfono podramos representar esto de la siguiente forma: 915758976 / 2. La ltima cifra, detrs de la barra / nos indicara la
PC PASO A PASO N 24
longitud del prefijo. Por tanto, sabemos que este nmero sera 5758976, y las dos primeras cifras, el 91 , seran el prefijo. Esta misma representacin se utiliza con las direcciones IP, pero contando el nmero de cifras binarias (bits). Por ejemplo, la IP 192.168.2.15 / 24 , estara compuesta por un prefijo de 24 bits (24 cifras binarias), y el resto sera la direccin IP de la mquina, es decir, sta constara de 8 bits (ya que el total de bits en una direccin IP hemos dicho que es 32). Viendo la IP en su formato binario:
11000000 . 10101000 . 00000010 . 00001111
Hemos visto una forma de representar la longitud del prefijo de la direccin IP, que consiste en acompaar a la direccin de una barra separadora y un nmero que representa el nmero de bits que ocupa este prefijo. Esta forma se suele utilizar bastante, pero tambin se utiliza otra representacin, quiz ms conocida, que veremos ahora mismo. En cualquier caso, se use la representacin que se use, a este nmero que especifica el tamao del prefijo se le llama mscara de red. Y esto que hasta ahora hemos estado llamando prefijo es lo que en realidad se denomina direccin de red. Fjate en la imagen para que no te pierdas y a partir de ahora, mientras lees, consulta continuamente la imagen.
Sabemos ya que las primeras 24 cifras: 11000000 10101000 00000010 , componen el prefijo (llamado direccin de red, como veremos ms adelante). Sabemos tambin que las ltimas 8: 00001111 componen la direccin de la mquina (llamada direccin de host) dentro de la zona marcada por el prefijo.
Todo esto de...
** Como una direccin de red se obtiene combinando la direccin IP y la mscara de red, en muchos textos encontrareis que se llama direccin de red al conjunto de estos dos nmeros: la direccin IP + la mscara de red (192.168.2.15 /24).
Todo esto de las zonas y los prefijos tiene relacin con lo que expliqu sobre cmo InterNIC asigna las direcciones IP. La parte de prefijo sera aquella que asigna ste organismo a cada organizacin (Telefnica, gobierno de los Estados Unidos, Universidad Politcnica de Madrid, Microsoft, ...), y el resto de la direccin IP sera el rango de direcciones en las que tiene libertad la organizacin para asignarlas como quiera a sus usuarios. Por tanto el prefijo determinar la organizacin a la que est asignada esa IP, y el resto de la direccin determinar a una mquina concreta dentro de esa organizacin.
Lo que hasta ahora hemos estado llamando zona es lo que en realidad deberamos llamar red. Cada red tiene una direccin de red al igual que cada calle de tu ciudad tiene un nombre. Por tanto, Internet est dividida en varias redes (zonas), cada una de las cuales
Pgina 23
PC PASO A PASO N 24
tiene asociada una direccin de red (un prefijo), cuya longitud viene determinada por la mscara de red. Antes dijimos que haba otra forma (quiz ms conocida) de representar la mscara de red. Vamos a ver ahora cul es esa otra forma y, para el que piense que con aprenderse una es suficiente, ya puede ir cambiando de opinin las dos son ampliamente utilizadas en libros tcnicos, textos, etc. Lo que en realidad nos est diciendo la mscara de red es qu bits de nuestra direccin IP pertenecen a la red (o zona), y qu bits pertenecen a la mquina concreta dentro de esa red. Po r t a n t o, l a d i r e c c i n d e r e d 192.168.2.15/24 podramos representarla tambin as:
Direccin IP = 11000000 . 10101000 . 00000010 . 00001111 Mscara de red = 11111111 . 11111111 . 11111111 . 00000000
Quiz os preguntis ahora por qu es tan habitual escribir las mscaras de red en este formato binario, que es menos intuitivo que el anterior. El motivo es que la mscara de red sirve para realizar determinadas operaciones de aritmtica binaria que han de ser realizadas viendo la mscara de red en su formato binario. Y qu operaciones son esas y para qu sirven? Eso es precisamente lo que veremos en el prximo punto.
4. EL ENCAMINAMIENTO EN REDES TCP/IP

Vamos a descubrir al fin cmo se puede encontrar el camino entre dos de las millones de mquinas conectadas caticamente a Internet. Comprenderemos as la necesidad de la existencia de las mscaras de red, y la utilidad de su representacin binaria. Para ello, vamos a ver un ejemplo de cmo se establecen diversas conexiones desde un PC de una empresa. El ejemplo que te presento ha sido intencionadamente muy muy simplificado, pero nos servir perfectamente para lo que deseamos explicar. En nuestro ejemplo tenemos una red corporativa compuesta de dos subredes: una zona interna, donde estn los PCs de cada empleado una zona DMZ donde se encuentra el servidor web de la compaa (se sale del tema hablar sobre lo que es una DMZ, y realmente no necesitis saberlo para este ejemplo, pero al final del artculo aclarar por encima estos conceptos).
PC PASO A PASO N 24
Para representar en binario la Mscara de Red (/24) lo que hacemos es poner tantos unos como nos indica la notacin (/24) y el resto lo completamos con ceros. Los bits que estn a 1 en la mscara de red son los bits que pertenecen al prefijo. Si convertimos esta mscara de red de binario a la clsica representacin decimal que utilizamos para las direcciones IP, nos quedara la siguiente direccin de red (como ya sabemos, 11111111 en binario corresponde a 255 en decimal y 00000000 en binario corresponde a 0 en decimal): Direccin IP = 192.168.2.15 Mscara de red = 255.255.255.0 Estoy seguro de que esto ya os suena bastante ms.
Pgina 24
Dos oficinas: una en Madrid: esta es la oficina principal, en la que estamos nosotros, y est conectada a Internet a travs de un modem ADSL otra en Barcelona (una sucursal) Las oficinas estn unidas entre si mediante una red directa. Lo hemos hecho as para simplificar el ejemplo
El ordenador de la oficina de Barcelona tiene como direccin de red 172.16.1.23/12. sta es la configuracin TCP/IP de nuestro ordenador en Madrid: Direccin IP: 192.168.2.5 Mscara de red: 255.255.255.0 Puerta de enlace predeterminada: 192.168.2.1 Ya sabemos lo que significan los dos primeros parmetros (Direccin IP y Mscara de Red). El ltimo parmetro (Puerta de Enlace Predeterminada) quiere decir que todo paquete que no sepamos encaminar lo tendremos que enviar a esa direccin que, en nuestro caso, es la del router central. Por tanto, para enviar el email a la oficina de Barcelona (IP 172.16.1.23) , el primer paso ser pasar la pelota a la puerta de enlace predeterminada (192.168.2.1) , es decir, al router central.
Veamos en primer lugar qu ocurre si queremos enviar un correo electrnico directamente desde la oficina de Madrid a una mquina de la oficina de Barcelona. Nosotros estamos en la oficina de Madrid , frente a un PC de la RED INTERNA. Concretando, el ordenador en el que estamos nosotros tiene la direccin de red 192.168.2.5/24 (fjate en la imagen). El router central, que intercomunica todas las redes de la empresa, tiene como direccin de red 192.168.2.1/24 dentro de la red interna (fjate en la imagen).
PC PASO A PASO N 24
Una vez en el router central, ste tendr que decidir qu hacer con el paquete. Para ello tiene que mirar en las tablas que tiene configuradas, que son las siguientes:
Veamos el significado de esta interesante tabla. Gracias a esta tabla, el router sabe: que cualquier paquete que coincida con la direccin de red 192.168.1.0/24 tiene que ser dirigido al interfaz eth0
Pgina 25
que cualquier paquete que coincida con la direccin de red 172.16.0.0/12 debe ser dirigido al interfaz eth1 que cualquier paquete que coincida con la direccin de red 192.168.2.0/24 se enviar al interfaz eth2 y, por ltimo, que cualquier paquete que no coincida con ninguna de las anteriores direcciones de red, tendr que coincidir por narices con la direccin de red 0.0.0.0/0, por lo que ir al interfaz ppp0. Por tanto, el interfaz ppp0 ser para el router central el equivalente a la puerta de enlace predeterminada, donde van todos los paquetes que no se sabe cmo encaminar. Normalmente, estos paquetes sern los que vayan a Internet y, de hecho, el interfaz ppp0 estar conectado a un modem que conectar con Internet. No os suena eso de los interfaces eth0, eth1, etc? Para que os hagis una idea, seran como diferentes tarjetas de red: Un router tendr una tarjeta de red por cada red a la que est conectado. En cada tarjeta, por supuesto, habr un cable que lo unir con cada red, por eso es necesaria la tabla, para saber por qu cable tiene que enviar cada paquete segn su destino. El interfaz ppp0 es otro tipo de interfaz que no corresponde a una tarjeta de red, si no a una conexin PPP. Para no liaros, basta con que os quedis con la idea de que el interfaz PPP es una interfaz con un modem. Como cada tarjeta de red tiene una direccin IP asociada, el router tendr por tanto 3 direcciones IP diferentes, una por cada interfaz eth (mira la
Pgina 26
imagen siguiente mientras lees las siguientes lneas): El router tendr la direccin IP 192.168.1.1 en el interfaz eth0. Esta es la red donde tenemos la DMZ. El router tendr la direccin IP 172.16.0.2 en el interfaz eth1. Esta es la red donde tenemos el ordenador de Barcelona. El router tendr la direccin IP 192.168.2.1 en el interfaz eth2. Esta es la red donde tenemos nuestro PC (Red Interna). De esta forma, se podr acceder al router central desde las tres redes de la organizacin (la red interna, la red DMZ, y la red de la oficina de Barcelona), ya que tendr una IP diferente para cada una de estas redes. Esta es una de las bases para comprender el trabajo de un router. Un router es como una araa que tiene una pata en cada red que desea enrutar. Un router nunca podr enrutar (dirigir) una red a la que no pertenezca.
Y ahora viene lo realmente interesante: Nosotros estamos intentando enviar un paquete desde nuestro PC con la IP 192.168.2.5 al un PC de la oficina de Barcelona con la IP 172.16.1.23 El router solo sabe la IP de origen (192.168.2.5) y la IP de destino (172.16.1.23). Cmo sabe el router a partir de la direccin IP del
PC PASO A PASO N 24
paquete a qu cable debe enviarlo? Es aqu donde llega la importancia de las direcciones de red. Para comprenderlo tenemos que conocer un poquitn de la aritmtica binaria ms bsica. Simplemente tenemos que comprender el funcionamiento del operador lgico AND. Igual que en la aritmtica decimal de toda la vida existen una serie de operaciones como son la suma, la resta, la multiplicacin, etc; en aritmtica binaria existen, adems de estas operaciones, otro grupo de operaciones llamadas operaciones lgicas. Las operaciones lgicas permiten operar sobre cifras binarias haciendo preguntas sobre ellas. Una respuesta SI se considerara un 1, y una respuesta NO se considerara un 0. Una de las operaciones lgicas ms bsicas es la operacin AND (traducido literalmente, la operacin y ). Por ejemplo, si tenemos dos variables binarias, A y B, donde cada una de ellas puede valer cero o uno, podemos preguntar: estn a uno A Y B? Si la respuesta es SI, el resultado ser un 1. Si la respuesta es NO, el resultado ser un 0. Esto nos da lugar a la siguiente tabla:
Para comprenderlo mejor, compararemos esta operacin con otra operacin lgica, que es la operacin OR (traducido, la operacin o). En este caso la pregunta es est a uno A O B? Esta sera la tabla resultante:
La operacin que nos interesa ahora es la operacin AND, es la que permitir a nuestro router comparar cada direccin de red con la direccin IP de destino de nuestro paquete. Recordamos que la IP de destino del paquete era 172.16.1.23. En este caso el router no sabe la mscara de red, ya que en un paquete IP slo se enva la direccin IP, pero no la mscara de red. Por tanto, tenemos tan slo una direccin, pero no sabemos cul es la longitud de su prefijo. Al no conocer la longitud de este prefijo, es decir, la direccin de red, no sabremos a priori a qu red pertenece esta direccin IP. La nica informacin de la que dispone el router central es la tabla que vimos anteriormente, por lo que el router tendr que comparar esta informacin con la direccin IP del paquete. La comparacin que hace es sencilla: realiza una operacin AND entre la IP del paquete y cada una de las mscaras de red que tenga en su tabla si el resultado despus de la operacin AND es alguna de las direcciones de red que hay en la tabla, entonces el paquete ser dirigido al cable correspondiente a esa direccin de red
Por tanto, la operacin AND nos devolver 1 slo cuando ambas variables valgan 1.
PC PASO A PASO N 24
Pgina 27
en caso de que ninguna direccin de red coincida con la del paquete, ste se enviar a la puerta de enlace predeterminada, en el interfaz ppp0. Veamos esto paso por paso. En primer lugar, pasemos a binario la IP del paquete, 172.16.1.23:
10101100 . 00010000 . 00000001 . 00010111
Vamos ahora con la segunda mscara de red:

10101100 . 00010000 . 00000001 . 00010111
AND
11111111 . 11110000 . 00000000 . 00000000 10101100 . 00010000 . 00000000 . 00000000 = 172.16.0.0
Y tambin las direcciones de red de la tabla del router:

192.168.1.0 = 11000000 . 10101000 . 00000001 . 00000000 Mscara = 11111111 . 11111111 . 11111111 . 00000000 172.16.0.0 = 10101100 . 00010000 . 00000000 . 00000000 Mscara = 11111111 . 11110000 . 00000000 . 00000000 192.168.2.0 = 11000000 . 10101000 . 00000010 . 00000000 Mscara = 11111111 . 11111111 . 11111111 . 00000000 0.0.0.0 Mscara = 00000000 . 00000000 . 00000000 . 00000000 = 00000000 . 00000000 . 00000000 . 00000000
Empezamos realizando la operacin AND entre la IP del paquete y la primera de las mscaras:
10101100 . 00010000 . 00000001 . 00010111
Tenemos que comprobar ahora que el resultado (172.16.0.0) coincida con la segunda direccin de red , que es 172.16.0.0. En este caso s que coincide, por lo que el router ha encontrado ya la red a la que ha de enviar el paquete. Consulta entonces su tabla y ve que ese paquete ha de ser enviado al interfaz eth1. Por tanto, ubicar fsicamente el paquete por el cable conectado a la tarjeta de red eth1, y podr llegar as hasta la red de la oficina de Barcelona, donde probablemente otro router se encargue de terminar de encaminar el paquete ya dentro de esa red. Si ahora queremos enviar otro paquete cuyo destino sea la IP 217.155.1.13, que es una IP de Internet, nuestro router comparar de nuevo las direcciones de red:
217.155.1.13AND255.255.255.0=217.155.1.0->nocoincidecon192.168.1.0 217.155.1.13 AND 255.240.0.0 = 217.144.0.0 -> no coincide con 172.16.0.0 217.155.1.13AND255.255.255.0=217.155.1.0->nocoincidecon192.168.2.0 217.155.1.13 AND 0.0.0.0 = 0.0.0.0 -> S coincide con 0.0.0.0
AND
11111111 . 11111111 . 11111111 . 00000000
10101100 . 00010000 . 00000001 . 00000000 = 172.16.1.0
Tenemos que comprobar ahora si 172.16.1.0 es igual a 192.168.1.0, que es la direccin de red correspondiente a la primera de las mscaras, con la que acabamos de realizar el AND . Por supuesto, no son iguales, por lo que el paquete no pertenece a esta primera red.
Por tanto, este paquete ser enviado al interfaz PPP0, que es el que nos conecta con Internet a travs del modem. Como vemos, es fcil realizar la operacin AND en formato decimal cuando la mscara de red divide la direccin en bytes (es decir, la mscara slo tiene 255 o 0). En este caso, bastar con poner a
PC PASO A PASO N 24
Pgina 28
0 aquellos bytes de la IP en los que haya un 0 en la mscara de red (217.155.1.13 AND 255.255.255.0 = 217.155.1.0). En cambio, para otro tipo de mscaras, ya es necesario operar en binario (217.155.1.13 AND 255.240.0.0 = 217.144.0.0). Como este ltimo ejemplo no se ve de forma clara en formato decimal, lo muestro aqu en su formato binario:
11011001 . 10011011 . 00000001 . 00001101
bits se utilizan para diferenciar la red, y los otros 24 bits se utilizan para identificar a una mquina concreta dentro de la red. Adems, el primer bit de una direccin de red de clase A tiene que ser 0, por lo que en realidad slo nos quedan 7 bits para identificar unvocamente una red de clase A. Teniendo en cuenta que hay adems algunas direcciones reservadas, esto da lugar a que slo existen 124 redes de clase A en Internet. Estas son las que tienen desde la direccin 1.*.*.* hasta la direccin 126.*.*.* Si bien son pocas las diferentes redes de clase A que se pueden direccionar con slo 7 bits, en cambio, son muchsimas las mquinas que se pueden direccionar dentro de esa red, ya que seran 224, que son casi 17 millones de mquinas.
AND
11111111 . 11110000 . 00000000 . 00000000
11011001 . 10010000 . 00000000 . 00000000 = 217.144.0.0
5.
CLASES DE REDES
Existen tres tipos bsicos de redes en funcin de la direccin de red (el famoso prefijo). Cada clase de red se utilizar para un fin distinto. Por ejemplo, una red de clase A se utilizar para grandes organizaciones, y slo existen 124 direcciones para redes de este tipo. En cambio, una red de clase C se utiliza en pequeas organizaciones, y existen ms de 2 millones de direcciones de clase C. Pero vamos a ver en detalle en qu consiste cada una de las clases de redes.
5.2. CLASE B
Las redes de clase B tienen una mscara de red /16 (255.255.0.0), es decir, la mitad de la direccin de red especifica la red, y la otra mitad la mquina dentro de la red. Los dos primeros bits de la direccin de red han de ser 10, por lo que al final nos quedan slo 14 bits para identificar la red. Esto da lugar a que haya 16382 direcciones de red de clase B diferentes, que abarcan desde la 128.1.*.* hasta la 191.254.*.*
Pgina 29
5.1. CLASE A
Las redes de clase A son aquellas que tienen una mscara de red /8 (255.0.0.0), es decir, slo los 8 primeros
PC PASO A PASO N 24
Cada red de clase B puede direccionar 65534 mquinas diferentes, por lo que estas redes siguen siendo utilizadas tan slo por grandes organizaciones.
Dentro de las diferentes redes destacan las llamadas clase D y clase E, muy poco utilizadas: Las de clase D , utilizadas para multicast, son las que empiezan por 1110. Las de clase E, direcciones para uso experimental, son las comprendidas entre 240.0.0.0 y 247.255.255.255.
5.3. CLASE C
Las redes de clase C tienen una mscara de red /24 (255.255.255.0), por lo que slo los ltimos 8 bits de la direccin permiten especificar una mquina dentro de la red. Los 3 primeros bits de una direccin de clase C tienen que ser 110, por lo que al final nos quedan slo 21 bits para direccionar la red, lo cual da lugar a que haya ms de 2 millones de redes de clase C diferentes. Dentro de cada red de clase C se pueden direccionar 254 mquinas diferentes, por lo que estas redes ya no son vlidas para grandes organizaciones. Las redes de clase C abarcan desde la 192.0.1.* hasta la 223.255.254.*.
No debemos...
No debemos asustarnos si encontramos direcciones de red con mscaras de red como esta: 255.255.255.128. Las mscaras de red no siempre estn construidas con 255 o 0, es decir, las direcciones de red no constan siempre de un nmero entero de bytes. Por ejemplo, la mscara de red 255.255.255.128 sera en binario: 11111111 . 11111111 . 11111111 . 10000000 Con este nmero en binario ya podemos operar con la operacin lgica AND exactamente igual a como lo hacamos con las mscaras ms "clsicas". Ya vimos un ejemplo de este tipo de mscaras en el punto anterior (255.240.0.0).
5.5. DIRECCIONES DE RED RESERVADAS

Hay algunas direcciones de red reservadas para ciertos fines, y que no pueden ser asignadas a ninguna mquina de Internet. La ms conocida es el famoso localhost: 127.0.0.1. Esta direccin siempre se refiere a tu propia mquina (tu PC), por lo que cualquier acceso que hagas a esa IP sern a c c e s o s a t u p r o p i o o r d e n a d o r. La direccin de red 10.0.0.0/8 (es decir, todas las IPs entre 10.0.0.0 y 10.255.255.255) estn reservadas para
PC PASO A PASO N 24
5.4. OTRAS CLASES DE REDES

Aparte de las 3 clases bsicas, pueden existir redes con diferentes mscaras que no se ajusten necesariamente a una de estas 3 clases.
Pgina 30
redes de rea local de gran tamao, ya que permiten direccionar 2 24 mquinas. Tambin para redes de rea local se usan las direcciones 172.16.0.0/12 (es decir, desde la IP 172.16.0.0 hasta la 172.31.255.255), y las 192.168.0.0/16 (desde la IP 192.168.0.0 hasta la 192.168.255.255). Estos rangos de IPs son los que podemos utilizar nosotros cuando montamos una red en nuestra casa o en la oficina. Por tanto, cualquiera en su casa es libre de hacer lo que quiera con esos rangos de IPs, ya que tienen garantizado que no existe en Internet ninguna mquina con esas direcciones. En el prximo punto veremos con ms detalle (aunque tampoco demasiado, pues no es realmente el tema del artculo) el funcionamiento de una red local. Existen otras direcciones reservadas para otros fines, como las 128.0.*.*, 191.255.*.*, 223.255.255.* , etc.
mes), y acompaar el curso de TCP/IP de un nuevo nmero de la serie RAW en el que explique algunos protocolos de encaminamiento, como RIP u OSPF. Lo que queda por aclarar entonces es el funcionamiento bsico de una red local. Una red local es una red independiente de Internet que, en el caso de que est conectada a Internet, lo har (normalmente) nicamente a travs de un slo punto. Por muchos ordenadores que haya conectados dentro de la red local, todos se conectarn con el exterior (Internet) mediante un nico punto. Al conectar con el exterior a travs de un slo punto, se consigue que el tamao y la configuracin de la red local sea transparente para los usuarios del exterior, es decir, para Internet. Si alguien desde la china intentase ver nuestra Red Interna compuesta por 600 ordenadores (o 2 o 3000, los que sean), nicamente vera una IP PBLICA, es decir, un nico punto de acceso. Esta IP seguramente correspondera a la del modem que da acceso a Internet a todos nuestros ordenadores. Esto es lo que permite que una empresa, una universidad, o cualquier otra organizacin, pueda tener un gran nmero de ordenadores, sin que cada uno de ellos tenga que tener su propia direccin IP dentro de Internet, lo cual saturara intilmente el rango de direcciones IP disponibles para Internet. Por supuesto, una red local no da ventajas slo de cara al exterior, para evitar la saturacin de las direcciones de Internet, si no tambin de cara al interior, para independizar la red de la empresa de la red Internet.
Pgina 31
6. FUNCIONAMIENTO BSICO DE UNA RED LOCAL

Para terminar, vamos a intentar aclarar algunos conceptos que he utilizado a lo largo del artculo, concretamente en el punto 4, en el que he hablado del encaminamiento. En primer lugar, tengo que dejar claro que el tema del encaminamiento es mucho ms complicado de lo que he mostrado aqu, pero explicarlo en detalle se sala por completo del tema del artculo. Espero disponer de un poco ms de tiempo en breve (quiz para el prximo
PC PASO A PASO N 24
El tener una red independiente tiene muchas ventajas de seguridad, de velocidad, etc. Una red local tpica, como la que podras tener t en tu casa por muy poco dinero, tiene una velocidad de 100Mbps. Esta velocidad dista mucho de las velocidades de que disponemos en casa para acceder a Internet. Por tanto, el tener una red local nos permitir tener una gran velocidad de conexin entre los ordenadores de nuestra casa, empresa, u organizacin de cualquier tipo, sin depender de la velocidad de acceso o incluso de la saturacin del trfico de Internet. Por otro lado, las ventajas con respecto a la seguridad son evidentes, ya que el trfico de la red local se puede aislar totalmente de Internet si se desea, evitando as cualquier tipo de ataque o de espionaje. En muchas organizaciones se opta por una configuracin local dividida en dos redes. Una de ellas, comunmente llamada zona interna, ser la que utilicen los usuarios comunes (por ejemplo, los empleados de una empresa), y tendr un acceso a Internet totalmente limitado. Esto hace que sea muy difcil que un hacker realice cualquier tipo de ataque o espionaje contra los ordenadores de los empleados (al mismo tiempo, tambin permite limitar el acceso a los empleados, para que no pasen el tiempo chateando o viendo fotos guarrillas). Por supuesto, la empresa no puede funcionar slo con una conexin tan restringida como sta, ya que necesitar tener una serie de servidores (servidor web, servidor de correo, etc) que tengan un acceso mucho ms abierto hacia Internet. Por eso se crea otra zona,
Pgina 32
llamada comunmente zona desmilitarizada, o DMZ, en la cual se alojarn todos los servidores, y aquellas mquinas que no hayan de estar bajo la proteccin de la zona interna.
Al ser independiente de Internet, en una red local se pueden utilizar direcciones IP libremente, siempre y cuando sean direcciones reservadas que no existan en Internet. Ya mencion antes cuales son las direcciones IP reservadas para redes locales. Una gran ventaja de esto es que facilita mucho la configuracin de los ordenadores conectados a la red local, ya que existen protocolos, de los cuales el ms famoso es el DHCP (Dynamic Host Configuration P rotocol), que permiten configurar automticamente cualquier nuevo ordenador que se conecte a la red local. Cada vez que se conecta una mquina, sta pide al servidor DHCP los datos de su configuracin (como su direccin IP), y queda as automticamente configurado.
PC PASO A PASO N 24
Esto puede dar lugar a la existencia de IPs dinmicas , que ya mencion al principio del artculo. Segn una serie de criterios, el servidor DHCP podr decidir en un momento dado asignar a una mquina una direccin IP diferente a la que le asign la ltima vez que esta mquina se conect. En una red local no slo ser necesario un protocolo que facilite la configuracin automtica de cada equipo, si no que har falta tambin otro protocolo que permita a los diferentes equipos de la red conocerse entre s, es decir, saber qu direccin IP tiene no slo l mismo, si no tambin sus compaeros a los que quiera acceder. El protocolo ms conocido para este fin es el ARP (Address Resolution Protocol), que permite asociar direcciones IP con direcciones MAC, tal y como veremos en el curso ms adelante, cuando hablemos del nivel de enlace. Por ltimo, slo me queda mencionar el funcionamiento de las direcciones broadcast, de las cuales ya habl un poco a lo largo del curso de TCP/IP. Por si no lo recordis, una direccin broadcast es una direccin IP especial que se refiere no a una sola mquina, si no a todas las mquinas de una misma red. Si, por ejemplo, enviamos un ping a una direccin IP, recibiremos respuesta nicamente de una mquina. En cambio, si esa direccin IP es la direccin broadcast de la red, todas las mquinas que estn conectadas a la red en ese momento respondern a nuestro ping (con los consiguientes problemas de seguridad de los que ya habl en artculos anteriores).
PC PASO A PASO N 24
Para simplificar, dije que una direccin broadcast se formaba poniendo un 255 en el ltimo byte de la IP, pero esto no es del todo cierto, ya que ste es slo el caso ms comn. Para comprender la formacin de la direccin broadcast tenemos que volver al tema de los operadores lgicos binarios, por lo que voy a introducir un nuevo operador, el ms simple de todos, que es el operador NOT. El operador NOT lo nico que hace es invertir todos los bits del nmero binario, es decir, cambiar todos los ceros por unos, y todos los unos por ceros. As: NOT 1001110101 = 0110001010 El primer paso para obtener la direccin broadcast de una red, ser aplicar el operador NOT sobre la mscara de red. E s d e c i r, s i t e n e m o s l a r e d 172.16.0.0/12, sta ser la mscara de red en formato binario:
11111111 . 11110000 . 00000000 . 00000000
Y sta ser la mscara despues de aplicar el operador NOT:

00000000 . 00001111 . 11111111 . 11111111
Teniendo ya esta mscara invertida, slo tenemos que aplicar un operador OR entre la mscara invertida y la direccin de red. Os recuerdo aqu cual era el funcionamiento del operador OR:
Por tanto, si la direccin de red en nuestro ejemplo es:

172.16.0.0 = 10101100 . 00010000 . 00000000 . 00000000
Pgina 33
Realizamos la operacin:
10101100 . 00010000 . 00000000 . 00000000

PC PASO A PASO busca personas que posean conocimientos de informtica y deseen publicar sus trabajos. SABEMOS que muchas personas (quizs tu eres una de ellas) han creado textos y cursos para consumo propio o de unos pocos. SABEMOS que muchas personas tienen inquietudes periodsticas pero nunca se han atrevido a presentar sus trabajos a una editorial. SABEMOS que hay verdaderas obras de arte creadas por personas como tu o yo y que nunca vern la luz. PC PASO A PASO desea contactar contigo!
OR
00000000 . 00001111 . 11111111 . 11111111 10101100 . 00011111 . 11111111 . 11111111 = 172.31.255.255
Por tanto, la direccin broadcast para la red 172.16.0.0/12 ser 172.31.255.255. En el prximo nmero, continuaremos con la capa IP de la pila TCP/IP, pero esta vez entrando de lleno en el formato de las cabeceras IP, por lo que nos esperar un artculo denso y, espero que bastante interesante. Autor: PyC (LCo).

SUSCRIBETE A PC PASO A PASO

SUSCRIPCIN POR: 1 AO 11 NUMEROS
45 EUROS (10% DE DESCUENTO) + SORTEO DE UNA CONSOLA XBOX + SORTEO 2 JUEGOS PC (A ELEGIR)
Contra
R e e m b o l s o Giro Post al
Envanos un GIRO POSTAL por valor de 45 EUROS a: CALLE PERE MARTELL20, 2 1. CP 43001 TARRAGONA ESPAA IMPORTANTE: En el TEXTO DEL GIRO escribe un mail de contacto o un nmero de Telfono. Y enviarnos un mail a preferente@hackxcrack.com indicando: - Nombre - Apellidos - Direccin Completa - Poblacin - Provincia - Cgigo Postal - Mail de Contacto y/o Telfono Contacto Es imprescindible que nos facilites un mail o telfono de contacto. - Tipo de Subscripcin: GIRO POSTAL - Nmero de Revista: Este ser el nmero a partir del cual quieres subscribirte. Si deseas (por ejemplo) subscribirte a partir del nmero 5 (incluido), debes poner un 5 y te enviaremos desde el 5 hasta el 15 (ambos incluidos) APRECIACIONES: * Junto con el primer nmero recibirs una carta donde se te indicar tu nmero de Cliente Preferente y justificante/factura de la subscripcin. * Puedes hacernos llegar estos datos POR MAIL,tal como te hemos indicado; o envindonos una carta a la siguiente direccin: CALLE PERE MARTELL N20, 2-1 CP 43001 TARRAGONA ESPAA * Cualquier consulta referente a las subscripciones puedes enviarla por mail a preferente@hackxcrack.com
Solo tienes que enviarnos un mail a preferente@hackxcrack.com indicando: - Nombre - Apellidos - Direccin Completa - Poblacin - Provincia - Cgigo Postal - Mail de Contacto y/o Telfono Contacto Es imprescindible que nos facilites un mail o telfono de contacto. - Tipo de Subscripcin: CONTRAREEMBOLSO - Nmero de Revista: Este ser el nmero a partir del cual quieres subscribirte. Si deseas (por ejemplo) subscribirte a partir del nmero 5 (incluido), debes poner un 5 y te enviaremos desde el 5 hasta el 15 (ambos incluidos) APRECIACIONES: * Junto con el primer nmero recibirs el abono de 45 euros, precio de la subscripcin por 11 nmeros (un ao) y una carta donde se te indicar tu nmero de Cliente Preferente y justificante/factura de la subscripcin. * Puedes hacernos llegar estos datos POR MAIL,tal como te hemos indicado; rellenando el formulario de nuestra WEB (www.hackxcrack.com) o envindonos una carta a la siguiente direccin: CALLE PERE MARTELL N20, 2-1 CP 43001 TARRAGONA ESPAA * Cualquier consulta referente a las subscripciones puedes enviarla por mail a preferente@hackxcrack.com
CURSO DE TCP/IP: LA CAPA IP

(segunda parte)
Los datagramas
En el numero anterior empezamos con uno de los puntos mas interesantes de este curso: La -Capa IP- y en concreto tratamos las -Direcciones IP-. Este mes seguimos con la -Capa IP- pero nos centraremos en los -datagramas- y los cambios que sufren en sus "andares" por Internet (fragmentacin, etc). INTRODUCCIN
A estas alturas ya tenemos que comprender bastante bien cmo circulan los paquetes a travs de Internet, o cualquier otra red TCP/IP. Conocemos ya los mecanismos de transporte (protocolos TCP y UDP), los mecanismos de control de errores (ICMP), y sabemos algo sobre el encaminamiento (tablas de encaminamiento de los routers, direcciones y mscaras de red, etc). Durante muchos meses he ido explicando a mi manera un gran nmero de documentos RFC (no slo en el curso de TCP/IP, si no tambin en la serie RAW), intentando as abriros una puerta fcil a unos documentos excesivamente tcnicos que de otra manera probablemente os habra costado bastante comprender. Llegados a este punto, despus de ms de un ao siguiendo esta lnea, creo que ha llegado el momento de hacer una pequea prueba para que comprobis vosotros mismos si estis preparados para enfrentaros directamente con los RFC y prescindir de mis servicios. Por supuesto, no voy a plantaros aqu un RFC tal cual, entre otras cosas porque probablemente tendra que ser en ingls, y tampoco pretendo hacer una traduccin
PC PASO A PASO N 25
de ningn RFC. En lugar de eso, lo que voy a hacer es seguir, como siempre, explicando las cosas a mi manera, pero en este caso lo har siguiendo la estructura de un RFC, en este caso del RFC 791 ( f t p : / / f t p . r f c - e d i t o r. o r g / i n notes/rfc791.txt), que es el que especifica el protocolo IP. Y, acaso no han seguido algn RFC el resto de mis artculos? Pues realmente no, ya que la estructura de los RFC (es decir, el orden en el que cuentan las cosas), en mi opinin, no suele ser a d e c u a d a p a ra q u e a l g u i e n s i n conocimientos sobre el tema comprenda lo que se est explicando. Hasta ahora, cada vez que escriba un artculo, dedicaba casi la mayor parte del tiempo simplemente a estructurar las ideas y hacer un esqueleto del orden en que las iba a contar. Posiblemente no notis mucha diferencia entre este artculo y el resto y, sinceramente, espero que as sea, porque eso significara que ya prcticamente estis preparados para enfrentaros solitos a la jungla de los RFCs. El prximo paso sera que cogieseis directamente un RFC, pero ese es un paso que daris vosotros mismos, pues yo no os voy a plantar en el prximo nmero un RFC, entre otras cosas porque no os voy a hacer pagar 45 euros por algo que podis descargar gratuitamente.
Pgina 43
Curso de TCP - Los DATAGRAMAS - Curso de TCP - Los DATAGRAMAS

Probablemente pensaris que estoy exagerando al hablar de la jungla de los RFCs y, realmente as es. Los RFCs no se han comido nadie hasta ahora y,,, como todo en esta vida, solo requiere un poco de tiempo para tenerlos bajo control. El problema que yo veo a enfrentarse directamente a los RFCs, sin tener conocimientos previos, es el mismo que vera a intentar aprender castellano con un diccionario. Cuando t buscas una definicin de una palabra en un diccionario, siempre te la definen con otras palabras, que a su vez estn en el diccionario. Por tanto, es imposible entrar en ese crculo vicioso de definiciones si t previamente no sabes hablar castellano, y conoces ya un conjunto bastante amplio de palabras. Lo mismo ocurre con los RFC, ya que son documentos escritos asumiendo que la persona que los leer sabr ya bastante sobre el tema. En cada RFC prcticamente se asume que se sabe de antemano todo aquello que no se explique en ese propio RFC, igual que en una definicin de diccionario se asume que conoces todas las palabras que puedan entrar en la definicin. Si en un RFC, por ejemplo, se habla del protocolo TCP, se asume que se sabr todo sobre el protocolo IP, los protocolos de enlace, los protocolos de aplicacin, las direcciones IP, etc, etc. Pues, igual que cuando ya sabemos hablar castellano ya estamos preparados para utilizar el diccionario, yo pienso que vosotros ya sabis hablar el suficiente TCP/IP como para poder utilizar los RFC que, al igual que un diccionario, una vez que los puedes utilizar se convierten en una herramienta imprescindible. As, como os he dicho, seguir parte de la estructura del RFC, no toda, pues son 45 pginas, y hay algunos puntos que
Pgina 44 PC PASO A PASO N 25
eliminar por no considerarlos importantes, o bien por considerarlos demasiado complejos para la lnea que est siguiendo este curso. Os aconsejo que cojis el RFC 791 y lo vayis siguiendo junto con este artculo. En lugar de seguir una numeracin ordenada para este artculo, ir poniendo la numeracin correspondiente a cada uno de los puntos del RFC que trate. As, el artculo empezar con el punto 1.4 del RFC 791.
No dominas el Ingles?
No dominas el Ingles? Pues una vez ms te aconsejamos un paseo por la Web www.rfc-es.org En ella encontrars el RFC 791 en perfecto castellano y, por supuesto, damos las gracias a los masters y colaboradores de dicha Web por el fantstico trabajo de traduccin que estn realizando.
Curso de TCP - Los DATAGRAMAS - Curso de TCP - Los DATAGRAMAS 1.4. OPERACIN
El protocolo IP ( I nternet P rotocol) implementa dos funciones bsicas: direccionamiento, y fragmentacin. La funcin de direccionamiento ya la conocemos bien, pues el artculo anterior estaba ntegramente dedicado a este tema (aunque an tengo pendiente completar este curso con una nueva entrega de la serie RAW que trate sobre protocolos de encaminamiento). Como ya sabemos, es la capa IP la que se encarga de asignar direcciones nicas a cada mquina, para que podamos acceder a cada una de ellas como si de nmeros de telfono se tratase. Con respecto a la fragmentacin, algo he comentado a lo largo del curso, pero en este artculo lo veremos en detalle. El protocolo IP permite dividir los datagramas (paquetes IP) en trozos lo suficientemente pequeos como para adaptarse a las capacidades tecnolgicas de cada red. IP no slo se encarga de dividir los fragmentos, si no que adems debe garantizar un mecanismo para reconstruir los paquetes originales a partir de los fragmentos. El protocolo IP utiliza 4 mecanismos clave para implementar estos servicios: el tipo de servicio (TOS), el tiempo de vida (TTL) , las opciones , y la suma de comprobacin (checksum). Iremos viendo en detalle a lo largo del artculo cada uno de estos mecanismos, pero os voy adelantando que el tipo de servicio es un mecanismo que permite asignar prioridades a los datagramas, para que as los gateways encargados de encaminarlos puedan tomar ciertas decisiones.
PC PASO A PASO N 25
Por ejemplo, en funcin del tipo de servicio, un gateway puede decidir encaminar un paquete bien hacia otro gateway que tenga un gran ancho de banda pero poca fiabilidad, o bien hacia un gateway ms lento pero ms seguro, siempre y cuando ambos caminos permitan llegar al mismo destino. Adems, un gateway podra incluso decidir descartar un datagrama en caso de congestin en la red (en caso de que el datagrama no tenga una prioridad alta). Algo habl ya sobre el tipo de servicio a lo largo del curso. Con respecto al tiempo de vida, s que lo detall bastante en el artculo sobre ICMP, cuando expliqu el funcionamiento de la herramienta traceroute. Para los que no hayis ledo ese artculo, os resumo diciendo que el tiempo de vida es un parmetro de cada datagrama que permite limitar el nmero de gateways que puede atravesar el datagrama antes de llegar a su destino. Si este nmero de pasos se sobrepasa, el datagrama sencillamente ser descartado, y el transmisor del datagrama ser notificado del problema (mediante un mensaje ICMP de tipo Time Exceeded). Con respecto a las opciones, se trata de una serie de cabeceras opcionales para cada datagrama, en las cuales se pueden implementar diversos servicios, como instrucciones explcitas de encaminamiento para ese datagrama, opciones de seguridad, etc. Por ltimo, la suma de comprobacin ya sabemos para qu sirve, ya que funciona exactamente igual que las sumas de comprobacin (checksums) de TCP, UDP, e ICMP. Os resumo diciendo que la suma de comprobacin es un sello que
Pgina 45

se pone a cada datagrama que, comparndolo con los contenidos del datagrama, permite detectar si ha habido algn error en la transmisin que haya deteriorado los contenidos. Como estamos viendo, hay un gran nmero de situaciones por las que tendra que haber una notificacin de errores, como cuando se descarta un datagrama por haber superado su tiempo de vida, o cuando un datagrama de baja prioridad es rechazado por una red congestionada, etc., etc. El protocolo IP por si mismo no proporciona ningn mecanismo de notificacin ni control de errores, por lo que es un requisito obligado que cualquier implementacin de IP est acompaada de una implementacin de ICMP, que es el protocolo encargado de la notificacin de errores de la capa IP. Si bien la implementacin de ICMP es obligada para cualquier mquina que utilice IP, hay otros servicios que tampoco estn garantizados por IP y que, en cambio, no son de uso obligado. Por ejemplo, el protocolo IP proporciona un servicio no orientado a conexin, donde cada datagrama es independiente, y no existen conexiones, sesiones, puertos, ni nada parecido. Todos estos servicios son proporcionados por los protocolos de transporte (TCP , o UDP) que pueden funcionar por encima de IP, aunque el uso de estos protocolos de transporte es opcional segn las necesidades de cada aplicacin. El protocolo IP no proporciona una comunicacin fiable (al no haber respuestas de confirmacin para los datagramas), ni mecanismos de control de errores (excepto el checksum, que permite detectar algunos errores, pero nunca corregirlos), ni mecanismos de control de flujo .
Pgina 46
De todas estas funciones se tendrn que ocupar otros protocolos (en caso de que sean necesarias), por lo que IP funciona siempre en una jerarqua de protocolos por capas, tal y como hemos visto desde el principio del curso.
2.2. MODELO DE OPERACIN

Ya se que los epgrafes probablemente no os estn diciendo nada, porque eso de que el primer punto se llame operacin- y el segundo -modelo de operacin- no es precisamente muy descriptivo, pero es que quiero conservar los nombres originales del RFC. Los puntos de los que he prescindido hasta ahora (prefacio, 1.1, 1.2, 1.3, y 2.1) son temas que ya he explicado a lo largo del curso. En este punto lo que nos encontramos es un ejemplo bsico de funcionamiento del protocolo IP y, a pesar de que este tipo de ejemplos ya los hemos visto a lo largo del curso, he considerado adecuado repetirlo una vez ms para ir consolidando las ideas fundamentales. En este ejemplo tenemos dos mquinas (A y B) que se comunican entre s a travs de un gateway (G).
En un caso real, lo normal es que no haya un nico gateway, si no toda una cadena de ellos para comunicar a A con B . Supongamos que A quiere enviar un datagrama a B, y que ese paquete forma parte de la comunicacin entre dos aplicaciones que corren en A y en B, por
PC PASO A PASO N 25

ejemplo, un servidor web (Apache) corriendo en B, y un navegador (Opera, Firefox, Netscape...) corriendo en A . En primer lugar, la aplicacin que corre en A, por ejemplo, Firefox, solicitar a la capa IP del sistema operativo de A la transmisin del paquete, con los datos que quiera que ste contenga, por ejemplo, una peticin GET de HTTP (recordis mi artculo de la serie RAW sobre el protocolo HTTP?). Para ello, no bastar con que se le proporcionen a la capa IP los datos que contendr el paquete (incluyendo en estos datos las cabeceras de protocolos de nivel superior, como podra ser TCP), si no que adems es necesario decirle cul va a ser la direccin IP de destino del paquete, as como otros parmetros que ya iremos viendo. datagrama, si no tambin una serie de parmetros que sta necesitar. El parmetro ms importante ser la direccin de destino, pero en este caso no ser una direccin IP, si no una direccin de red local. Cuando hablemos en este curso sobre los protocolos de nivel de enlace ya veremos ms sobre esto. Lo que s que tenemos que tener claro ahora es que la direccin que pasa de la capa IP a la capa de enlace no es la direccin de B, si no la direccin de G, que ser la nica mquina que establecer una conexin directa con A. Por supuesto, G se tendr que encargar de enviar luego el datagrama a B, igual que si A hubiera conectado directamente con B.
Una vez que la capa IP tiene el paquete y los parmetros necesarios, tendr que construir su propia cabecera que aadir al paquete, formando as un datagrama. Bueno... uno o varios, pues podra decidir fragmentar el paquete por ser demasiado grande, pero en este ejemplo simple vamos a suponer que no es necesaria la fragmentacin. Ahora que ya tenemos el datagrama formado, tenemos que enviarlo a la capa inferior, que nosotros conocemos como capa de enlace. A esta capa de enlace no slo tendremos que darle el
PC PASO A PASO N 25
Una vez que el datagrama ya est en la capa de enlace, junto con los parmetros necesarios, esta capa se encargar de aadir al datagrama su propia cabecera y, una vez hecho esto, ya slo f a l t a r enviar el paquete a travs del cable fsico. Una vez en el cable (medio fsico) que conecta con la red local , el paquete llegar a todas las mquinas que hay conectadas a esa red local. Una de esas mquinas ser el router G , que al comprobar que la direccin de red de destino del paquete es la suya, ser el
Pgina 47

nico que se quede con el paquete (bueno, claro, a no ser que en la red haya alguna mquina maligna que est en modo promiscuo, por ejemplo si est usando un sniffer para capturar todo el trfico de la red, aunque no vaya dirigido a ella). no complicar las cosas), por lo que lo nico que tendr que hacer ser generar una nueva cabecera de enlace para que ste llegue hasta B. Para ello, pasa el datragrama a su propia capa de enlace, indicndole la direccin de red de B.
Una vez que el paquete est en G, como ya ha utilizado la informacin de la cabecera de enlace, es decir, su propia direccin de red para saber que el paquete iba dirigido a l, puede prescindir de la cabecera de enlace, y obtener as el datagrama tal y como lo gener la capa IP de la mquina A.
Una vez que la capa de enlace de G tiene todos los d a t o s necesarios, crear una n u e v a cabecera de enlace que aadir al datagrama, y ya podr lanzarlo a travs del cable fsico que une a G con B . El paquete llegar a B que, gracias a la nueva cabecera de enlace generada por G, sabr que el paquete va destinado a l.
Una vez que el datagrama est en la capa IP de la mquina G, sta descubre que el datagrama no va dirigido a ella, ya que la IP de destino no es la suya, si no la de la mquina B, por lo que deduce que ella es la encargada de retransmitir el paquete para que pueda llegar hasta su destino. La mquina G no modificar absolutamente nada del datagrama (o al menos eso creeremos de momento, para
Pgina 48
Sabiendo ya esto, ya no necesita ms esa cabecera de enlace, por lo que la

PC PASO A PASO N 25

destruye y pasa el resto del paquete (el datagrama) a su propia capa IP . Con respecto al direccionamiento contar poco, ya que para ello dediqu el artculo anterior slo a este tema.
Direccionamiento
Probablemente en el ejemplo anterior no os habr quedado muy claro el tema de las direcciones de red. Cmo sabe la capa IP qu direcciones de red tiene cada mquina? En la capa IP de la mquina B , sta descubre que el destinatario final del datagrama es ella misma, por lo que busca en la cabecera IP el dato que le diga a qu capa superior tiene que pasar el datagrama. Con esto, ya slo tendr que enviar el datagrama a las capas superiores, donde la aplicacin de B (el servidor Apache) har con los datos del paquete lo que le plazca (es decir, procesar la peticin GET de HTTP que hizo A). Aqu el RFC hace una distincin entre 3 conceptos: nombres, direcciones, y rutas. Un nombre indica qu buscamos. Una direccin indica dnde est lo que buscamos. Una ruta indica cmo llegar hasta esa direccin. La responsabilidad de convertir nombres en direcciones reside en los protocolos de nivel superior a IP. Por supuesto, aqu el RFC se refiere al protocolo DNS, que traduce nombres a IPs, y viceversa. Pero, igual que IP se aprovecha de funciones cuya responsabilidad pertenece a protocolos superiores, IP tambin se aprovecha de funciones llevadas a cabo por protocolos inferiores, es decir, por la capa de enlace. La capa de enlace es la que se encarga de mantener la traduccin de direcciones IP a direcciones de red (las que utiliza la capa de enlace). Por ejemplo, si utilizamos Ethernet en la capa de enlace, necesitaremos el protocolo ARP (Address Resolution Protocol) para mantener la traduccin entre direcciones IP y direcciones de red local que, en este caso, sern las famosas direcciones MAC. Todo esto ya lo iremos viendo a lo largo del curso.
Pgina 49
2.3. DESCRIPCIN FUNCIONES
DE
Aqu el RFC entra en algo ms de detalle sobre las dos funciones bsicas que menciona al principio: direccionamiento, y fragmentacin. Para entrar ya en todos los detalles habr que esperar a llegar ms adelante, cuando se describen uno a uno los campos de la cabecera IP.
PC PASO A PASO N 25
Curso de TCP - Los DATAGRAMAS - Curso de TCP - Los DATAGRAMAS Fragmentacin

Como ya he dicho, segn la tecnologa utilizada en cada red, los paquetes tendrn limitado su tamao mximo. Internet es una red muy heterognea, en la que conviven todo tipo de tecnologas, por lo que se hacen imprescindibles mecanismos para adaptar estas diferencias de forma transparente. Y no slo de forma transparente al usuario final, si no tambin a cualquier protocolo que no se encuentre en la capa que se encargue de esta funcin, dentro de la jerarqua de capas de protocolos. Por tanto, al encargarse la capa IP de esta funcin, la fragmentacin tiene que ser transparente para los protocolos superiores, como TCP, o los protocolos de aplicacin. Quin decide cundo hay que fragmentar un datagrama? Esta decisin normalmente no se tomar en la mquina que gener el datagrama (el transmisor), ya que sta difcilmente podr saber los problemas con los que se encontrar el datagrama en su camino hasta el destino, por lo que es responsabilidad de cada uno de los gateways que haya en el camino juzgar si el datagrama va a tener que pasar por algn cuello de botella por el que sea necesario fragmentarlo. Ahora que comprendemos quin y por qu lleva a cabo la fragmentacin, nos falta conocer el cmo se lleva a cabo esta fragmentacin. Si pensamos un poco, enseguida nos daremos cuenta intuitivamente de que hacen falta bsicamente dos cosas: un campo que nos indique a qu datagrama pertenece ese fragmento, y otro campo que nos indique qu posicin ocupa ese fragmento dentro del datagrama original. Para llevar a cabo la identificacin del datagrama al que pertenece el fragmento se recurre a una combinacin de campos, de los cuales el ms importante es el campo llamado Identification (identificacin). Este campo es un nmero que puede identificar unvocamente un datagrama para una escenario concreto. Es decir, la combinacin de las ips de origen y destino , y el protocolo de nivel superior (TCP, UDP, ...,...) junto con el campo Identification es siempre nica para cada datagrama. Podremos encontrar dos datagramas diferentes con el mismo campo Identification, si por ejemplo es diferente la IP de destino, pero nunca los 4 campos podrn ser iguales para diferentes datagramas: ip de origen, ip de destino, protocolo, e identificacin. Para saber qu posicin ocupa el fragmento dentro de ese datagrama se recurre a otro campo, llamado Fragment Offset (desplazamiento del fragmento), que nos indica en qu byte del datagrama original comienza este fragmento. En realidad la unidad de medida para este campo no son bytes, si no octetos de bytes , es decir, grupos de 64 bits .
En la imagen vemos cmo sale un nico datagrama del transmisor, que llega en primer lugar hasta el gateway G1. G1 sabe que el prximo gateway en el camino es G2, y sabe que ste se encuentra en una red de una tecnologa diferente (la nubecita azul) que no puede manejar paquetes tan grandes, por lo que G1 decide fragmentar en dos el datagrama original.
Curso de TCP - Los DATAGRAMAS - Curso de TCP - Los DATAGRAMAS 3.1. FORMATO DE LA CABECERA IP
Si estis siguiendo el RFC al mismo tiempo que el artculo os habris dado cuenta de que interpretado la traduccin de este epgrafe muy libremente, ya que el original se llama Internet Header Format, lo cual se traducira como: FORMATO DE LA CABECERA DE INTERNET. He preferido traducir Internet por IP, porque eso es a lo que realmente se refiere el RFC. Como ya sabemos, IP es el acrnimo de Internet Protocol, por lo que el RFC abrevia llamando Internet al protocolo IP. Esta terminologa me parece muy ambigua (y seguro que a vosotros tambin), por lo que he preferido referirme a IP en todo momento, en lugar de referirme a Internet a secas. Sin ms prembulos, vamos a plantar aqu el aspecto de la cabecera de un datagrama:
En la imagen vemos como un datagrama de 712 bytes es fragmentado para poder pasar a travs de una red que permite un mximo de 512 bytes. El Fragment Offset del segundo fragmento ser 512/8 = 64, ya que el offset se mide en unidades de 64 bits (8 bytes).
Ahora que ya tenemos la idea intuitiva de cmo se lleva a cabo la fragmentacin, si somos lo suficientemente avispados, nos habremos dado cuenta de que algo falta aqu. Por supuesto, tiene que haber alguna forma de indicar cul es el ltimo fragmento o si no, de otra forma, saber cul era el tamao original del datagrama fragmentado, para saber cundo tenemos todos los fragmentos para reconstruirlo. En IP se ha optado por la primera opcin, es decir, marcar con un flag (un indicador de un simple bit) cul es el ltimo fragmento.
Pero ste no es el nico flag que se utiliza para controlar el mecanismo de fragmentacin de datagramas. Existe otro flag que sirve para indicar que un datagrama en concreto no debe ser fragmentado bajo ningn concepto. En caso de que un datagrama marcado con este flag tenga que circular a travs de una red que requiere paquetes ms pequeos, el datagrama sencillamente ser rechazado.
PC PASO A PASO N 25
Veamos cada campo.
Versin (Version): 4 bits

Aqu estamos hablando de la versin clsica IPv4, pero en un artculo futuro ya hablaremos de la versin IPv6 que ser el prximo estndar que definir el funcionamiento de la nueva red Internet. Por tanto, este campo de momento para nosotros valdr siempre 4 ( 0100 en binario).
Pgina 51
Curso de TCP - Los DATAGRAMAS - Curso de TCP - Los DATAGRAMAS Longitud de la cabecera IP (IHL: Internet Header Length): 4 bits
Este campo indica la longitud de la cabecera IP (esta misma cabecera) medida en palabras de 32 bits. Como la cabecera IP puede contener opciones de tamao variable, es necesario este campo que nos indica en qu punto termina la cabecera y comienzan los propios datos del paquete. Una cabecera sin ninguna opcin mide 160 bits, es decir, 5 filas de 32 bits, por lo que el valor mnimo para este campo y, de hecho, tambin el valor ms tpico, es 5 ( 0101 en binario). con la idea de que, cuanto mayor es este nmero, mayor es la prioridad de un datagrama. En caso de congestin en la red, los datagramas que sern descartados en primer lugar sern los que tengan prioridad 000 (rutinarios). Precisamente, prcticamente todo el trfico que solemos utilizar en nuestras casitas es de prioridad 000. La segunda parte del TOS son otros 5 bits que funcionan a modo de flags, es d e c i r, c a d a b i t e s u n i n d i c a d o r independiente de alguna caracterstica del datagrama. Estos son los significados de cada flag:
Tipo de servicio (TOS: Type Of Service): 8 bits

Una vez ms vuelve a entrar en escena este campo sobre el que siempre he hablado muy por encima. Al fin ha llegado el momento de que entremos en detalle. El campo TOS en realidad se podra decir que consta de dos partes. Por un lado, una parte que, mediante 3 bits, especifica un nivel de prioridad para el datagrama. Cuanto mayor es el valor de estos 3 bits, mayor prioridad, tomando estos nombres las 8 prioridades que se pueden especificar: Empezamos a contar a partir del bit 3, ya que los bits 0-2 son los que especifican la prioridad (precedence), tal y como vemos en este esquema que resume toda la estructura del campo TOS:
Los bits 6 a 7 no se usan, por lo que se ponen siempre a 0. Los otros 3 flags (D, T, y R) mantienen un compromiso mutuo entre 3 caractersticas de la comunicacin incompatibles entre s. Es decir, por poner un ejemplo, en general, cuanto ms rpida (mayor ancho de banda) es una comunicacin, menor fiabilidad tendr. Si el flag D (Delay) est activo significa que el tipo de servicio que est ofreciendo este datagrama requiere un retardo mnimo . Por ejemplo, cualquier aplicacin interactiva requerir retardos mnimos, por lo que los datagramas de estas aplicaciones deberan ser dirigidos a travs de redes que, aunque sean lentas
PC PASO A PASO N 25
No es muy importante comprender el significado de estos nombres ya que, entre otras cosas, los que he puesto han sido traducciones libres que he hecho yo mismo. Lo importante es que os quedis
Pgina 52

y/o poco fiables, al menos s que garanticen que la respuesta ser lo ms inmediata posible. Si el flag T (Throughput) est activo significa que el tipo de servicio que est ofreciendo este datagrama requiere el mximo ancho de banda que se le pueda ofrecer. Por ejemplo, este flag es til para transmisiones de contenidos multimedia, donde lo importante es poder transmitir a toda velocidad, al margen de que se pueda perder algn dato (por ejemplo, un simple fotograma de una pelcula), es decir, aunque el servicio tenga baja fiabilidad, y tambin al margen de que los datos lleguen en tiempo real, es decir, que el retardo no sea un factor crtico. Si el flag R (Reliability) est activo significa que el tipo de servicio que est ofreciendo este datagrama requiere una mxima fiabilidad, al margen de que la comunicacin sea en tiempo real (retardo), o del ancho de banda de la misma. Cualquier aplicacin que requiera precisin en los datos , como la transferencia de archivos binarios , entrara dentro de este tipo de servicios. En realidad estos flags no suelen utilizarse por muchas aplicaciones, ya que requieren un coste adicional en el procesamiento de los datagramas. An as, cabe destacar que hay tipos de servicio que pueden tener requisitos tan fuertes que tengan activados dos de los tres flags, pero activar los 3 sera absurdo, ya que estaramos pidiendo que se optimizasen 3 parmetros relacionados inversamente entre s. Po r e j e m p l o, u n a a p l i c a c i n d e videoconferencia podra requerir al mismo tiempo un bajo retardo (flag D) (por supuesto, una videoconferencia tiene que ser en tiempo real), y tambin un gran
PC PASO A PASO N 25
ancho de banda (flag T), pero en cambio no se puede exigir que para colmo la comunicacin tenga mxima fiabilidad (flag R) y no se pierda ni un slo detalle de la imagen por el camino.
Longitud Total (Total Length): 16 bits

Si bien el campo IHL slo media la longitud de la cabecera IP para saber en qu punto comienzan los datos, este campo indica, en bytes, la longitud total de todo el datagrama , para saber dnde terminan los datos. Al ser 16 bits, el tamao mximo de paquete ser de 65536 bytes, lo cual est muy por encima del tamao de paquete que puede circular por cualquier red normal.
Identificacin (Identification): 16 bits

Este es el campo que se utiliza para identificar el datagrama al que pertenece un fragmento. Como ya dije, la combinacin de este campo con la ip de origen, la ip de destino, y el nmero de protocolo, identifica unvocamente un datagrama para permitir su reensamblaje a partir de sus fragmentos.
Indicadores (flags): 3 bits

Aqu tenemos 2 indicadores de los que ya he hablado:
El bit 0 es de uso reservado, por lo que siempre se pondr a 0. El flag DF (Dont Fragment), en caso de estar activo, indica que este datagrama
Pgina 53

no puede ser fragmentado, por lo que, en caso de que el datagrama no quepa en una red, tendr que ser descartado. En otros artculos ya hemos visto algunas aplicaciones de este tipo de datagramas, como el mecanismo de Path MTU Discovery (PMTUD) que expliqu en el artculo sobre ICMP. Os recomiendo que volvis a leer ahora ese apartado para que lo comprendis mejor conociendo ahora el mecanismo de fragmentacin. El flag MF (More Fragments), en caso de estar activo, indica que este fragmento NO es el ltimo de los que forman el datagrama original. En caso de que s que sea el ltimo, se indicar poniendo a 0 este flag. Por supuesto, si est activo al mismo tiempo el flag DF, no tendr sentido el uso de este flag, por lo que se podr dejar a 0 tranquilamente. Cada gateway por el que pase el datagrama tendr que restar en 1 este valor, y si en algn caso llega a valer 0, el gateway que didio este valor tiene que interrumpir en ese punto la transmisin del datagrama, y devolver a su transmisor original un mensaje ICMP de tipo Time Exceeded. Si estis bien despiertos habris observado en este punto un detalle importante, y es que (a pesar de que en el ejemplo del punto 2.2 dije que los gateways no modifican la cabecera IP original) los gateways que actan como intermediarios en la transmisin de un datagrama pueden, y en casos como ste deben, modificar algn campo de la cabecera IP.
Protocolo (Protocol): 8 bits

Este campo identifica el protocolo de nivel superior en la jerarqua, para que el mdulo de la capa IP del receptor sepa cmo debe procesar el datagrama. Como ya sabemos, por ejemplo, el protocolo TCP se identifica con el valor 6 (00000110 en binario).
Desplazamiento del fragmento ( Fragment Offset ): 13 bits

Indica la posicin del fragmento dentro del datagrama original, en unidades de 8 octetos, es decir, 64 bits. El primer fragmento tendr siempre un desplazamiento 0. Si, por ejemplo, el primer fragmento tena un tamao de 512 bytes, el segundo fragmento tendr un desplazamiento de 512/8 = 64.
Suma de comprobacin de la cabecera (Header Checksum): 16 bits

Ya sabemos bien cmo funcionan las sumas de comprobacin. El algoritmo es el mismo que en el caso de TCP, UDP, o ICMP. El problema aqu es que, como los gateways que procesan el datagrama a lo largo de todo el camino modifican la cabecera (como acabamos de ver al hablar del campo TTL), es necesario recalcular una nueva suma de comprobacin en cada gateway por el que pasa el datagrama. Por tanto, cada gateway, en primer lugar comprueba el checksum del datagrama
PC PASO A PASO N 25
Tiempo de Vida (TTL: Time To Live): 8 bits

Ya habl bastante sobre este campo, sobre todo en el artculo sobre ICMP. Como ya sabemos, indica el nmero mximo de gateways que puede atravesar el datagrama antes de considerarse caducado.
Pgina 54

que ha recibido, si es valido hace lo que tenga que hacer con l (como decrementar el valor TTL), y por ltimo, ya con la cabecera modificada, recalcula un nuevo checksum, que susituirsustituir al anterior. Por tanto, tenemos aqu un nuevo ejemplo de un campo de la cabecera IP que es modificado en cada gateway por el que pasa el datagrama. Por tanto, se hace imprescindible la presencia del campo IHL que, como vimos, indica en qu punto termina la cabecera IP y comienzan los datos. Como ya vimos, el campo IHL mide la longitud de la cabecera en palabras de 32 bits. Esto no significa que las opciones de la cabecera tengan que ajustarse necesariamente a este tamao. Por este motivo, en caso de que el tamao de las opciones no sea mltiplo de 32 bits, ser necesario rellenar con ceros los bits necesarios hasta que se complete una fila de 32 bits. Estos ceros son los que aparecen como Padding en el dibujo de la cabecera que puse al principio. El campo Options consta de una, ninguna, o varias opciones. En caso de que haya varias opciones, estas irn seguidas una detrs de otra, hasta que ya no haya ms opciones. El formato de cada una de las opciones es variable. El nico campo que tienen en comn todas las opciones es un campo de un byte que sirve precisamente para identificar el tipo de opcin. Este byte, llamado Tipo de opcin (option-type), consta a su vez de varios campos que, combinados, identifican un tipo concreto de opcin. Esta es la estructura del option-type:
Direccin IP de origen (Source Address): 32 bits

Como ya sabemos, una direccin IP ocupa 32 bits. Este campo es uno de los ms importantes de la cabecera IP, y especifica la direccin IP del transmisor del datagrama. Es el campo que se modifica cuando hacemos un IP Spoofing.
Direccin IP de destino (Destination Address): 32 bits

Pues eso, la direccin IP del receptor del datagrama. Por supuesto, es tambin uno de los campos ms importantes.
Opciones (Options): longitud variable

Esta es, sin duda, la parte ms compleja de la cabecera IP. En primer lugar, porque su longitud es variable. Puede haber datagramas que no tengan ninguna opcin y, por tanto, todo este campo sea inexistente, y justo despus de la direccin IP de destino se encuentren ya los datos del paquete. De hecho, los datagramas sin opciones son probablemente los ms comunes. Pero, igual que puede haber datagramas sin opciones, tambin los puede haber con un gran nmero de opciones, y cada una de ellas adems con una longitud variable.
PC PASO A PASO N 25
El primer bit es el bit de copiado (copied flag). Este bit se utiliza slo en datagramas fragmentados. En caso de que este bit est a 1 significa que esta opcin se repite en todos los fragmentos del mismo datagrama, es decir, es una opcin del datagrama original, y no slo del fragmento.
Pgina 55

A continuacin tenemos los 2 bits de clase de opcin (option class). Existen 4 clases definidas, de las cuales slo se utilizan 2 y, para colmo, de estas dos prcticamente slo se utiliza la primera:
Sin operacin (No Operation)

Esta opcin consta tambin de un nico byte (00000001), y es un clsico NOP, es decir, una instruccin que no hace nada. La utilidad de esta opcin es simplemente separar opciones para ajustarlas a palabras de 32 bits, es decir, si una opcin ocupa 24 bits, se podra poner un No Operation entre sta y la siguiente, si quisisemos que la siguiente opcin comenzase en una nueva fila de 32 bits (ya que 24+8 = 32).
Por ltimo, tenemos 5 bits que especifican el tipo concreto de opcin dentro de esa clase (option number). Esta es la lista de opciones definidas para cada clase:
Opciones (Security)
de
seguridad
Qu poco me gusta esto de traducir trminos tan tcnicos... pero no os preocupis, que ahora ir hablando de cada opcin, e incluir, a parte de esta traduccin, tambin los nombres originales en ingls.
A pesar de lo atractivo del nombre de esta opcin, me temo que no voy a poder contaros mucho, ya que el uso de esta opcin es tan complejo que requiere un RFC propio para detallarla. Este es el RFC 1 1 0 8 (f t p : / / f t p. r f c- e d i t o r. o r g / i n notes/rfc1108.txt). Esta opcin est definida por el departamento de defensa de los estados unidos, e incorpora informacin de distintos niveles de confidencialidad a los datagramas (desde informacin desclasificada, hasta alto secreto). Tampoco creo que os enteris de mucho leyendo el RFC 1108 as que, teniendo en cuenta que esta opcin no os la vais a encontrar habitualmente, en principio podis ignorarla. Por supuesto, animo al que tenga inters a que investigue por su cuenta (aunque os advierto de antemano que no os bastar con el RFC 1108).
PC PASO A PASO N 25
Definiciones especficas de las opciones

Fin de lista de opciones (End of options list)
Esta opcin consta de un nico byte, con 8 ceros (00000000), y se coloca siempre como ltima opcin, para marcar que ya no hay ms opciones. No ser necesaria en caso de que el tamao de las opciones se ajuste a un mltiplo de 32 bits, por lo que el fin de las opciones vendr delimitado por el campo IHL.
Pgina 56

Slo he de destacar dos detalles, para que identifiquis esta opcin si os la encontris. Esta opcin obligatoriamente tiene que tener activo el flag copied, es decir, el primer bit del option-type, por lo que su byte option-type siempre ser 10000010 (130 en decimal). Aparte del option-type, los 10 prximos bytes pertenecern a esta opcin (ya que tiene una longitud total de 11 bytes ). El primer byte, por supuesto, es el optiontype que, como vemos, tiene que tener obligatoriamente activo su flag copied (el primer bit). El segundo byte indica la longitud en bytes de toda la opcin LSRR, incluyendo el option-type y el propio byte de longitud (length). El tercer byte, es el puntero (pointer) que permite ir rastreando la lista de gateways segn el datagrama va recorriendo su camino. El cuarto campo, de longitud variable, los datos de enrutamiento (route data) es donde se encuentra la lista de gateways que debe atravesar el datagrama. Para comprender el funcionamiento del LSRR vamos a verlo con un ejemplo. Supongamos que tenemos esta opcin LSRR:
Encaminamiento dbilmente especificado por el transmisor (LSRR: Loose source and record route)
Esta opcin permite especificar el camino que debe seguir el datagrama para llegar hasta su destino, es decir, una lista de gateways por los que debe pasar obligatoriamente el datagrama en el camino hacia su destino. Cada uno de estos gateways puede decidir hacer pasar el datagrama por otros gateways intermedios no especificados en la lista, pero al final el datagrama tiene que haber pasado por todos los gateways de la lista. Si bien es obligado que el datagrama pase por todos los gateways de la lista, el datagrama tambin puede pasar adems por otros gateways que no estn en la lista, motivo por el cual se habla de encaminamiento DEBILMENTE especificado. Como veremos despus, la diferencia con el encaminamiento ESTRICTAMENTE especificado es que en este segundo caso el datagrama slo podr pasar por los gateways de la lista, y no podr haber otros intermedios. Para implementar esta funcin, la opcin LSRR consta de 4 campos:
PC PASO A PASO N 25
Y nuestro datagrama tiene como IP de destino la IP 217.15.12.100. En primer lugar, vamos a comprobar el byte length . Como vemos, vale 00001111, que es 15 en decimal. En efecto, si tenemos 3 direcciones IP en el campo route data, con 4 bytes por IP tenemos un total de 3 x 4 = 12 bytes para el campo route data. Si a esos 12 le sumamos los 3 bytes que ocupan los campos option-type, length, y pointer, tenemos un total de 15 bytes para toda la opcin.
Pgina 57

En principio, el pointer vale 00000100, que es 4 en decimal. Esto significa que el primer gateway de la lista se encuentra en el byte 4 de la opcin. Es evidente que el campo pointer siempre tiene que empezar valiendo 4, ya que el cuarto byte de la opcin LSRR es siempre donde empieza la lista de gateways (el campo route data). En cuanto nuestro datagrama salga de nuestra mquina, tendr que ir al gateway 215.20.1.1, ya que es al que est apuntando nuestro puntero. Una vez que el datagrama est en el segundo gateway de la lista, ste volver a incrementar en 4 el puntero: 8+4 = 12 , luego el nuevo puntero ser 00001100. Ahora el puntero apuntar al gateway 84.2.100.1. Pero no tenemos conexin directa con este gateway, por lo que el datagrama ser enviado a otro gateway que sabemos que s que puede alcanzar la red de 84.2.100.1.
En cuanto el datagrama llega a este gateway, ste tendr que modificar el puntero, para que apunte a la siguiente IP de la lista, es decir, a 80.6.13.200. Como una IP son 4 bytes, habr que incrementar en 4 el puntero: 4+4 = 8, luego el nuevo valor del puntero ser 00001000. A continuacin, el gateway 215.20.1.1 enviar el datagrama al gateway 80.6.13.200.
Cuando el datagrama llegue a este gateway intermedio, ste no modificar el puntero, y simplemente retransmitir el datagrama al gateway 84.2.100.1, que era donde queramos llegar.
Una vez en el ltimo gateway de la lista, ste incrementar de nuevo el puntero en 4: 12+4 = 16, luego el nuevo puntero ser 00010000. Ahora nuestro puntero est fuera de rango, por lo que se considera que ya ha terminado el encaminamiento explcito,

y a partir de este punto se sigue un encaminamiento normal, es decir, basndonos en la IP de destino, 217.15.12.100. En el ejemplo anterior, el datagrama no podra haber pasado por el gateway 82.15.1.1 si se hubiese tratado de una opcin SSRR, en lugar de una LSRR.
Registro de ruta (Record route)

El formato de esta opcin es similar al de las opciones LSRR y SSRR:
Pero el funcionamiento es diferente. Con todo esto (adems de conseguir que, por los motivos que sean, nuestro datagrama atraviese un camino prefijado) adems al destinatario del datagrama le llegar un registro de estos gateways por los que ha ido pasando el datagrama que le ha llegado, ya que la lista se mantiene ntegra en el campo route data, y es slo el puntero el que se va modificando para ir rastreando la lista. Inicialmente, el campo route data estar en blanco , y tendr un tamao lo suficientemente grande como para que quepa toda la ruta que se estima que siga el datagrama. Si bien en las opciones LSRR y SSRR hay que activar el flag copied, para que todos los fragmentos puedan encaminarse correctamente a travs del camino prefijado, en el caso de la opcin record route ocurre lo contrario. No tendra sentido repetir la misma informacin en todos los fragmentos, por lo que esta opcin slo se incluir en el primer fragmento y, por tanto, tendr a 0 su flag copied. En esta opcin, el campo route data est El funcionamiento de esta opcin, as como su formato, es exactamente el mismo que el de la opcin LSRR, con la diferencia de que en este caso el datagrama no podr atravesar ningn gateway que no est en la lista route data. En caso de que el datagrama no pueda llegar hasta su destino utilizando nicamente los gateways especificados, el datagrama tendr que ser rechazado.
PC PASO A PASO N 25
Encaminamiento estrictamente especificado por el transmisor (SSRR: Strict Source and Record Route)
vaco cuando el datagrama sale del transmisor. Cada gateway por el que pase el datagrama tendr que aadir al route data su propia direccin IP, y avanzar el puntero en 4 bytes. As, cuando el datagrama llegue finalmente a su receptor, ste tendr en route data un registro completo de todos los gateways que ha ido atravesando el datagrama en su camino.
Pgina 59

En el caso de que durante la ruta el datagrama llegue a un gateway y ste no pueda insertar en el registro su direccin IP (porque no quepa en route data), ste gateway tendra que devolver al transmisor del datagrama un ICMP de tipo Parameter Problem para avisar del problema. An as, el datagrama debe llegar a su destino, por lo que sta no es una situacin de error crtica. Mirad detenidamente la siguiente imagen, siguiendo el camino del datagrama desde el transmisor hasta el receptor:
Sello de Tiempo ( Internet Timestamp)

Esta es quiz la ms complicada de las opciones, pero eso, por supuesto, no ser un problema para nosotros.
Esta opcin permite seguir el rastro al camino del datagrama, pero ahora con mucho ms detalle, ya que lo que se consigue con esta opcin es saber en qu momento exacto (con precisin de milisegundos) pas el datagrama por cada gateway. Esto permite, entre otras cosas, comprobar la calidad de la comunicacin entre dos mquinas, teniendo en cuenta el camino intermedio que hay entre ellas. De forma intuitiva, podemos pensar que esta opcin es parecida a la Record Route , pero incluyendo no slo la direccin IP de cada gateway por el que pasa el datagrama, si no tambin un sello de tiempo que indique en qu momento exacto cogi el datagrama ese gateway. En realidad, sta es slo una de las tres formas diferentes en las que puede funcionar esta opcin.
Identificador de flujo (Stream Identifier)
En la imagen vemos como cada gateway va incluyendo su propia direccin y su sello de tiempo en cada posicin libre del registro.
Esta opcin ha quedado obsoleta, tal y como especifica el RFC 1122, por lo que lo normal es que una mquina que reciba un datagrama con esta opcin sencillamente la ignore. Esta opcin serva para incluir en un datagrama un identificador de la red SATNET (Atlantic Satellite Packet Network). Para ello, la opcin constaba de 4 bytes. El primer byte era, por supuesto, el option-type, el segundo especificaba la longitud, que siempre era 4 (00000100). Los dos ltimos bytes formaban el Stream ID, es decir, el identificador de SATNET.
Pgina 60
Otra opcin consiste en que slo se incluyan los sellos de tiempo, pero no la direccin IP de cada gateway. Por tanto, tendramos tan slo un registro de tiempos pero no una lista de direcciones IP, en caso de que slo nos interese comprobar la calidad de la comunicacin, independientemente de por dnde haya pasado el datagrama.
PC PASO A PASO N 25

por los que tiene que pasar el datagrama, por lo que podramos incluir simplemente los sellos de tiempo (hasta 9, como hemos visto), sin necesidad de acompaarlos de las direcciones IP mediante una opcin Record Route.
Esta imagen es similar, pero con la diferencia de que en este caso los gateways slo incluyen su sello de tiempo, y no su direccin IP.
En este caso, esta opcin se podra acompaar de una opcin Record Route, pero sera absurdo, ya que se obtendra el mismo resultado que utilizando directamente la opcin Timestamp pero incluyendo las direcciones IP en los propios timestamp. El nico motivo para hacer esto sera que el camino entre las dos mquinas fuese demasiado largo (muchos gateways), ya que la longitud mxima de la opcin timestamp es de 40 bytes y, por tanto, si se incluyen las direcciones IP en los timestamp slo podramos incluir sellos de tiempo para 4 gateways, mientras que si las direcciones IP se incluyen aparte (con una opcin Record Route) podramos incluir sellos de tiempo para 9 gateways. Ms adelante veremos el
Si en lugar de una opcin SSRR fuese una opcin LSRR, no tendramos manera de saber qu gateways han incluido su sello de tiempo, ya que no podemos saber por qu gateways intermedios ha pasado el datagrama aparte de los especificados en el route data de la opcin LSRR.
Aqu el datagrama, adems de los sellos de tiempo, lleva una opcin SSRR que nos dice de antemano las IPs de todos los gateways que dejarn su sello de tiempo.
En este ejemplo, quien se encarga de incluir las direcciones IP de los gateways es una opcin Record Route, mostrada en la imagen como RR.
por qu de estos nmeros. En el caso de que el datagrama venga acompaado de una opcin SSRR ya sabramos de antemano los gateways
Por tanto, una tercera forma de funcionamiento de la opcin Internet Timestamp consiste en que el transmisor del datagrama i n c l u ya l a l i s t a d e l o s g a t e w a y s cuyo sello de tiempo desea conocer, lo cual sera una buena combinacin junto con la opcin LSRR, aunque tambin sera til independientemente.
Como vemos en la imagen, aqu no todos los gateways que han dejado su sello de tiempo estn en el route data de la opcin LSRR (concretamente el gateway 82.15.1.1), por lo que no hay manera de saber a qu gateway pertenece cada uno de los 4 sellos de tiempo.
PC PASO A PASO N 25
Pgina 61

bytes (option-type, length, pointer, y overflow+flag), por lo que nos queda: 40 4 = 36 bytes para el campo TimeStamps. Teniendo en cuenta que cada timestamp, al igual que una direccin IP, ocupa 32 bits (4 bytes), tendremos un total de 36/4 = 9 filas en el campo TimeStamps.
Aqu la lista de gateways (LG) no es una opcin aparte, si no que acompaa a cada sello de tiempo. Como vemos, el gateway que no est en la lista (82.15.1.1) no deja su sello de tiempo.
No se si con todo esto os habr liado ms,

as que mejor vamos a ver punto por punto el funcionamiento de esta opcin. Este es el formato bsico de la opcin Internet Timestamp:
Por tanto, en el mejor de los casos (si slo incluimos informacin de timestamps, y no de direcciones IP), slo podremos incluir informacin sobre 9 gateways. An as, la opcin timestamp puede funcionar con hasta 24 gateways aunque, por supuesto, incluyendo slo informacin sobre 9 de ellos como mucho. Para permitir este desbordamiento de la lista de gateways, se incluye el campo overflow (desbordamiento), de 4 bits. Una vez que la lista de timestamps est ya llena, si el datagrama sigue pasando por ms gateways que deberan incluir informacin en el registro de timestamps, lo que harn estos gateways ser simplemente incrementar en 1 el campo overflow (que inicialmente estar a 0), con lo que dejan una marca de que, aunque el datagrama pas por ellos, no pudieron dejar su sello de tiempo. Por tanto, con 4 bits podemos permitir que hasta 15 gateways dejen el aviso de que no pudieron marcar el datagrama con su sello de tiempo.
Los dos primeros bytes ya los conocemos. El primero es el option-type , y el segundo especifica la longitud de la opcin (en bytes, contando desde el option-type inclusive). La mxima longitud, segn el RFC es 40 ( 00101000 ). Por supuesto, esta longitud es fija desde que la especifica el transmisor del datagrama, por lo que deber ser suficientemente grande para el tamao que se estima que ocupar toda la opcin una vez que haya llegado al receptor del datagrama. El puntero (pointer) apunta al primer byte libre dentro del campo timestamp, por lo que el valor de inicio del puntero ser siempre 5 (00000101). Vamos a hacer ahora unos pocos clculos Si hemos dicho que la longitud mxima de la opcin Internet Timestamp es de 40 bytes, para calcular el tamao mximo del campo TimeStamps tendremos que restar los 4 primeros
Pgina 62
En esta imagen slo se reservaron dos filas para los sellos de tiempo (length = 12), por lo que los dos ltimos gateways no pueden incluir su sello de tiempo, si no slo una marca de overflow.
PC PASO A PASO N 25

El siguiente campo, Flag , de 4 bits, permite especificar uno de los 3 modos de funcionamiento de la opcin Internet Timestamp. En realidad, habra sobrado con 2 bits para este campo, pero su tamao se redonde a 4 bits para ajustar la longitud total de la opcin. Estos son los posibles valores para este campo: En caso de que se especifique la medida en cualquier otro formato habr que poner a 1 el primer bit del sello de tiempo. Cuando la opcin Internet Timestamp funciona de esta manera permite incluir sellos de tiempo de hasta 9 gateways.
Veamos caso por caso.
0000 Slo sellos de tiempo 0001 Sellos de tiempo con registro de direcciones IP
En este primer caso, cada fila de 32 bits del campo TimeStamps contendr un sello de tiempo de cada gateway por el que pase el datagrama. Cada sello de tiempo consta en realidad de 31 bits, ya que el primero (el ms significativo) se usa para especificar el formato del sello de tiempo. En caso de que est a cero este bit, el formato del sello de tiempo ser estndar, y si est a uno, el sello de tiempo tendr cualquier otro formato no estndar (que en principio no se puede especificar, pues no quedan ms bits para dar ms detalles, aunque se podran aprovechar los 31 bits restantes si se llega a un convenio entre el transmisor y el receptor). El formato estndar de sello de tiempo lo que mide es el nmero de milisegundos transcurridos desde la medianoche del UT (Universal Time), que es una hora universal independiente de las franja horarias.
PC PASO A PASO N 25
Esta forma de funcionamiento de la opcin combina los sellos de tiempo con la funcin que hara un Record Route. Cada sello de tiempo, por tanto, viene precedido por la direccin IP del gateway que deja el sello. Por tanto, para cada gateway habr que reservar 8 bytes (4 para la direccin IP, y 4 para el sello de tiempo), por lo que con un mximo de 36 bytes para este campo, tendramos 36/8 = 45. Como no puede meterse un gateway a medias tenemos que redondear por lo bajo, por lo que slo podramos incluir informacin de 4 gateways. Cualquier otro gateway que coja el datagrama una vez rellenadas las 4 filas tendr simplemente que incrementar el campo overflow .
Pgina 63

y el transmisor ser notificado con un mensaje ICMP de tipo Parameter Problem. Tambin habr que hacer esto en el caso de que un gateway no pueda incluir toda su informacin, caso que se da por ejemplo cuando se combinan sellos de tiempo con registro de direcciones (flag 0001).
0011 Sellos de tiempo para gateways predefinidos
Como vimos en ese caso, para un valor 40 en el campo length, tendramos una fila que nos quedara incompleta, es decir, nos cabra slo la direccin IP del gateway, pero no su sello de tiempo. En caso de que ese gateway se encontrase con un hueco insuficiente tendra que rechazar el datagrama, y enviar un ICMP de tipo Parameter Problem al transmisor del datagrama. Es importante, por tanto, estimar correctamente el tamao del campo length para esta opcin. An nos quedan muchas cosas por ver sobre la capa IP, sobre todo desde el punto de vista prctico. Cmo se utilizan todos estos conceptos tericos en el mundo real? Qu podemos hacer nosotros til con toda esta informacin? Hay alguna forma de utilizar todo esto para comprometer la seguridad de un sistema? Cmo conviene que configuremos nuestro propio sistema para evitar esos problemas? Todo esto, y mucho ms, lo veremos en el prximo artculo. Autor: PyC (LCo)
En este caso las direcciones IP no estn inicialmente a 0, si no que estn especificadas, igual que en una opcin LSRR. El datagrama podr pasar por todos los gateways que sea necesario, pero slo los gateways incluidos en la lista tendrn que dejar su sello de tiempo. Esta es la nica opcin que permite que un datagrama con opcin Internet Timestamp circule a travs de ms de 24 gateways.
En cualquier otro caso, si el campo overflow se desborda, es decir, si supera su mximo valor 1111 (15 en decimal), el datagrama tendr que ser rechazado,
L A C A PA I P 3 PA R T E : F R AG M E N TAC I o N D E DATAG R A M A S
Este mes hay MUCHA miga: - Nos meteremos de lleno en los algoritmos de fragmentacin y reensambado de paquetes - Trataremos los problemas de seguridad derivados de la fragmentacin de datagramas - DoS / Exploits Jolt, Jolt2 y TEARDROP / Floog Y Nuke - Saltaremos Firewalls e IDSs
INTRODUCCIN
Cada vez me voy sintiendo ms a gusto escribiendo para esta revista, ya que hemos avanzado juntos ya muchsimos pasos durante todos estos meses de curso TCP/IP y tambin, por supuesto, con la serie RAW. Esto hace que cada vez pueda hablar con ms soltura, sin pensar en todo momento si los lectores conocern tal cosa a la que hago referencia. Mis referencias son cada vez ms a artculos ya escritos, ms que a cosas totalmente desconocidas para vosotros. Esto me da muchsima ms libertad para centrarme en temas ms especficos, y este artculo es buena prueba de ello. Difcilmente habra podido escribir este artculo sin asumir que parts ya de una base bastante slida. Quiz os parezca que abuso un poco de vosotros, ya que para poder seguir este artculo enterndose de todo no slo es imprescindible haber seguido mi curso de TCP/IP, si no que tambin asumo que habis seguido el resto de la revista. Para seguir este artculo es necesario que hayis seguido el imprescindible curso de Linux de la revista (ya que centro en Linux mis ejemplos), as como el magnfico curso de diseo de firewalls (basado en iptables), y otros artculos, como los que hablaban del uso de exploits. Pgina 44
Todos estos ingredientes hacen que el nivel de este artculo sea ya bastante alto y, por tanto, tambin bastante interesante, en mi opinin. A pesar de eso, me he reservado algunos de los detalles ms especficos para una prxima entrega, en la que quiero, entre otras cosas, hacer un compendio de las tcnicas de hacking que utilizan ip-spoofing, para ir explicndolas con ejemplos concretos. A pesar de lo especfico del tema del artculo, me ha faltado espacio para explicar con mucho ms detalle muchas cosas, pero siempre debis considerar esta revista como un punto de partida para vuestro estudio personal, con el gran maestro Google, y con vuestra propia experimentacin, que es absolutamente fundamental. Una vez ms he de insistir en que los que busquen un tutorial sobre cmo destruir una mquina escribiendo un comando o ejecutando una aplicacin llena de ventanitas y dibujitos, que no pierdan el tiempo leyendo mi artculo. Lo que aqu se explica no slo en muchos casos ni siquiera tendr aplicacin prctica, si no que adems todo el enfoque del artculo no es desde un punto de vista prctico, si no orientado a aquellos que, como yo, disfrutan conociendo el funcionamiento de las cosas, incluso aunque sean cosas que ya han quedado obsoletas. PC PASO A PASO N 26
Curso de TCP - Fragmentacin De Los DATAGRAMAS

1. Es deseable la fragmentacin de datagramas?
La respuesta a la pregunta que planteo aqu es sencilla: no , no es deseable la fragmentacin. La fragmentacin da la oportunidad a un hacker de llevar a cabo un gran nmero de ataques, como ataques DoS, o tcnicas para saltarse la proteccin de un firewall o un IDS. Para comprender todo esto, voy a dividir el artculo en tres partes: E n p r i m e r l u g a r, e s p e c i f i c a r detalladamente los algoritmos utilizados para fragmentar y reensamblar datagramas. En segundo lugar, presentar algunas tcnicas utilizadas para aprovechar el mecanismo de fragmentacin en un ataque. Por ltimo, explicar como configurar un sistema para evitar la fragmentacin y, por tanto, cerrar la posibilidad de sufrir este tipo de ataques.
RFCs. Traducir un RFC del Ingles al castellano es una tarea larga y compleja, pero hacerlo con la pulcritud que ellos lo hacen es merecedor de nuestros mejores halagos. Si algn lector desea colaborar con ellos en su gran proyecto, seguro que sois recibidos con los brazos abiertos. Pero, igual que quedamos en que bamos a tratar de comprender todo el RFC, tambin tenis que recordar que lo que nos diferencia a nosotros del resto de los usuarios de ordenadores son precisamente estas cosas. Un usuario considera el ordenador una herramienta. No tiene ningn inters en cmo funcione por dentro, y cuanto ms masticado le d todo el ordenador, mucho mejor para l. En cambio, para nosotros... esta bien, digamos para un hacker, el ordenador no es slo una herramienta para conseguir algo que nos interesa, si no que el propio ordenador nos resulta interesante. Por tanto, lo que nos diferencia es que mientras que los usuarios comunes intentan abstraerse lo mximo posible del funcionamiento interno de la mquina, nosotros al contrario buscamos conocer cada vez con ms detalle este funcionamiento. As que, una vez explicado a grandes rasgos e l m e c a n i s m o d e f ra g m e n t a c i n d e datagramas, nuestras mentes inquietas no se conformarn con eso, y buscarn vidamente cada vez ms detalle. Este detalle es el que nos da el RFC, y ms abajo no podemos llegar, ya que especifica detalladamente un algoritmo que puede ser implementado directamente por cualquier programador. Por tanto, vamos a tratar de comprender estos algoritmos.
2. Algoritmos de fragmentacin y reensamblado

En el RFC 791 se explica en detalle un algoritmo para la fragmentacin de datagramas, y otro para su reensamblado. Si habis ojeado el RFC, estoy seguro de que la mayora de vosotros habris pasado ese punto al encontrar un montn de letras raras que n o o s i n t e r e s a b a n l o m s m n i m o.
Para los nuevos...
Para los nuevos lectores (y perdonen los curtidos veteranos por repetir una vez ms esta nota en cada nmero de la revista) informarles que en la Web www.rfc-es.org tienen a su disposicin el RFC 791 en perfecto castellano. Una vez ms agradecemos a todos los colaboradores de www.rfces.org la aportacin desinteresada de las traducciones de los PC PASO A PASO N 26
2.1. Algoritmo de fragmentacin de datagramas del RFC 791.

Pero antes de nada... hay alguien aqu que no sepa lo que es un algoritmo? Si es as, no os asustis, que no tiene nada que ver con las matemticas (uno de los Pgina 45

errores ms comunes de la gente no acostumbrada a tratar con estos trminos es confundir la palabra algoritmo con logaritmo). Un algoritmo es simplemente la explicacin detallada de una forma de resolver un problema. Por ejemplo, vamos a ver un algoritmo sencillo que tenemos todos implementados en nuestro cerebro, y lo usamos a diario: el algoritmo para cruzar una calle. Un algoritmo suele venir detallado por una serie de pasos secuenciales. Se empieza en un primer paso, en el que se llevan a cabo unas acciones. Cuando se termina este paso se sigue en el paso siguiente, y as sucesivamente. En algunos pasos puede haber saltos que te lleven atrs a un paso que ya hicimos anteriormente, o bien adelante, saltndonos as varios pasos que no es necesario que llevemos a cabo por los motivos que sean. En cada paso puede haber acciones a realizar, o bien preguntas a responder acerca del estado del problema. Las respuestas a estas preguntas nos llevarn por un camino u otro dentro del algoritmo, movindonos de un paso a otro no siempre de forma secuencial, hasta que lleguemos a algn paso que termine el algoritmo (un paso de FIN). Veamos, por tanto, el algoritmo que utilizamos nosotros para cruzar la calle: Paso 1: Buscamos un paso de peatones y nos acercamos a l, situndonos en el borde de la acera. Paso 2: Miramos a la izquierda. Paso 3: --> Si viene algn coche por la izquierda, entonces volvemos al Paso 2. -->Si no viene ningn coche por la izquierda, entonces continuamos por el Paso 4. Paso 4: Miramos a la derecha. Paso 5 --> Si viene algn coche por la derecha, entonces pasamos al Paso 7. --> Si no viene ningn coche por la derecha, entonces continuamos por el Paso 6. Paso 6: Podemos cruzar la calle. FIN. Paso 7: Miramos a la derecha. La diferencia de este paso con el 4, es que como aqu permaneceremos un tiempo mirando a la derecha, durante este tiempo podra volver a haber coches en el lado izquierdo, por lo que antes de cruzar tendremos que volver a comprobar este lado, tal y como veremos ahora mismo. Paso 8: --> Si no viene ningn coche por la derecha, entonces volvemos al Paso 2. --> Si viene algn coche por la derecha, entonces volvemos al Paso 7. No creo que haya ninguna duda sobre el funcionamiento de este algoritmo, ya que todos lo utilizamos casi inconscientemente. Un programador se tiene que encontrar constantemente con este problema de racionalizar y detallar en un algoritmo muchas cosas que hacemos de forma inconsciente sin reparar en la complejidad de lo que estamos haciendo. Por supuesto, este algoritmo para cruzar una calle es muy simple, y el que utilizamos nosotros realmente es mucho ms complejo. Nuestro cerebro tiene en cuenta mil factores ms: que la calle sea de doble o nico sentido, que haya semforos, que los coches estn atascados, etc, etc. Ahora que ya comprendemos el mecanismo bsico de un algoritmo, podemos enfrentarnos al algoritmo de fragmentacin planteado en el RFC. Para ello, en primer lugar tenemos que dar nombres a una serie de variables que se van a utilizar en el algoritmo. TL Longitud total del datagrama (antes de ser fragmentado). [Total Length] PC PASO A PASO N 26
Pgina 46

MTU Ms adelante hablaremos mucho ms sobre la MTU. La MTU es el tamao mximo que puede tener un datagrama segn la tecnologa de la red que va a tener que atravesar en su prximo paso. [Maximum Transmission Unit] DF Flag de la cabecera IP que obliga a que un datagrama no pueda ser fragmentado. [Dont Fragment] IHL Campo de la cabecera IP que especifica el tamao de esta cabecera. A lo largo del algoritmo, se referir en unos momentos al IHL del datagrama original, o al IHL del fragmento, tal y como veremos. [Internet Header Length] OIHL Variable de uso auxiliar, que nos permite recordar el tamao de la cabecera IP que tena el datagrama antes de ser fragmentado. [Old Internet Header Length] OTL Variable de uso auxiliar, que nos permite recordar el tamao total del datagrama antes de ser fragmentado. [Old Total Length] FO Campo de la cabecera IP Fragment Offset, que nos permite saber qu posicin ocupa un fragmento dentro del datagrama original. [Fragment Offset] OFO Variable de uso auxiliar, que nos permite recordar el Fragment Offset del datagrama antes de ser fragmentado. [Old Fragment Offset] MF Flag de la cabecera IP que indica que este fragmento no es el ltimo, y an han de venir ms fragmentos del mismo datagrama. [More Fragments] OMF Variable de uso auxiliar, que nos permite recordar el flag MF del datagrama antes de ser fragmentado. [Old More Fragments] NFB Nmero de bloques de datos de los que se compone un fragmento. [Number of Fragment Blocks] PC PASO A PASO N 26 Vamos a ver ahora el algoritmo detallado. Os recomiendo que segn lo voy explicando vayis siguiendo cada paso del algoritmo tal y como viene en el RFC (bastante ms ofuscado de lo que lo explicar yo aqu), para que os acostumbris a la notacin utilizada en los RFCs. El algoritmo del RFC muestra slo el caso ms simple, de un datagrama que se divida en slo dos fragmentos. Empecemos viendo el primer paso, que llamaremos Paso 0 para que se correspondan el resto de pasos con los del RFC: Paso 0 Si TL es menor o igual que la MTU, entonces el datagrama cabr por la red y no habr que fragmentarlo. FIN. En el caso contrario (TL > MTU), entonces tenemos que comprobar el flag DF . Si el flag DF est activo, no podemos fragmentar, por lo que tenemos que descartar este datagrama, y enviar un ICMP para notificar el problema. FIN. Si el flag DF no est activo, entonces podemos continuar por el Paso 1. Este paso, tal y como est escrito, es como solemos hablar nosotros informalmente. Pero esta no es una buena forma de detallar un algoritmo, ya que se presta a muchas ambigedades. Una forma mucho ms correcta es utilizar ciertas estructuras bien conocidas para detallar la secuencia que siguen los pasos del algoritmo. La estructura ms simple para detallar el flujo del algoritmo es el IF THEN, ELSE THEN . Lo traduciremos por SI ENTONCES, SI NO ENTONCES. Vamos a ver este mismo paso, pero detallado con esta estructura:
Pgina 47

Paso 0 SI TL es menor o igual que la MTU ENTONCES El datagrama cabr por la red y no habr que fragmentarlo. FIN. SI NO, ENTONCES Comprobar el flag DF. SI el flag DF est activo ENTONCES No podemos fragmentar. Descartar el datagrama. Enviar un ICMP para notificar el problema. FIN. SI NO, ENTONCES Continuar por el Paso 1. Verdad que esto es mucho ms claro una vez que nos acostumbramos a leerlo as? Adems, tal y como est escrito esto, se puede escribir de forma casi directa en cualquier lenguaje de programacin, por lo que facilitamos mucho el trabajo a los programadores que tengan que implementar este algoritmo en una mquina. Ve a m o s ya e l a l g o r i t m o c o m p l e t o : Paso 0 SI TL es menor o igual que la MTU ENTONCES El datagrama cabr por la red y no habr que fragmentarlo. FIN. SI NO ENTONCES Comprobar el flag DF. SI el flag DF est activo ENTONCES No podemos fragmentar. Descartar el datagrama. Enviar un ICMP para notificar el problema. FIN. SI NO ENTONCES Continuar por el Paso 1. Paso 1 Copia toda la cabecera IP al primer fragmento que vamos a crear. Paso 2 Damos valor a las variables auxiliares, ya que necesitamos seguir conociendo los datos del datagrama original, pero tenemos que modificar las variables TL, IHL, FO, y MF para nuestro nuevo fragmento. OIHL = IHL. OTL = TL. OFO = FO OMF = MF Paso 3 NFB = (MTU IHL x 4) / 8. Calculamos el tamao de los datos del fragmento. El tamao mximo para todo el datagrama est determinado por la MTU. Como, adems de los datos, hay que incluir la cabecera, el tamao de los datos estar en funcin de la MTU y del tamao de la cabecera (IHL). Paso 4Aadir al fragmento NFB x 8 bytes de datos. Ahora ya no slo tenemos la cabecera del fragmento, si no tambin los datos, que son solo una porcin de todos los datos que haba en el datagrama original. Paso 5Ahora que ya est el fragmento casi construido, slo nos queda modificar la cabecera para que se vea claramente que es el primer fragmento. Activamos el flag MF. TL = (IHL x 4) + (NFB x 8). Calculamos un checksum para este fragmento, una vez modificada la cabecera. Como en OTL hemos guardado la longitud total del datagrama original, podemos sobrescribir el valor de la variable TL sin perder ese dato, que ms adelante nos har falta. El nuevo TL (para este fragmento) se calcula en funcin de la cabecera (IHL) y de los datos (NFB). PC PASO A PASO N 26
Pgina 48

Paso 6 El primer fragmento ya est listo, y se enva al nivel de enlace. Continuamos ahora con el segundo fragmento. Paso 7 Copiamos la cabecera del datagrama original al nuevo fragmento. Habr que revisar el campo Opciones de la cabecera IP, para ver cules de las opciones tendrn que ser copiadas a todos los fragmentos. Por tanto, la cabecera del fragmento podra ser ms pequea que la del datagrama original, al no tener copia de todas las opciones. Paso 8 Como este algoritmo slo explica como dividir en 2 fragmentos, asumimos que ste es el ltimo, por lo que aadimos despus de la cabecera todos los datos que faltaban (los que haba en el datagrama original a partir de la posicin NFB x 8). Paso 9 Ahora ajustamos varios campos de la cabecera del fragmento, en 5 pasos: IHL = ((OIHL x 4) L + 3) / 4. TL = OTL (NFB x 8) ((OIHL IHL) x 4). FO = OFO + NFB. MF = OMF. Calculamos el checksum. Vaya formulitas, eh? En primer lugar, vemos que el IHL del nuevo fragmento, como dijimos, podra ser menor que el del datagrama original, porque podra haber opciones que no se han copiado. La variable L que he puesto en la frmula es la longitud de las opciones que no han sido copiadas en el fragmento. En el caso del TL del fragmento, lo obtenemos a partir del TL del datagrama original, restndole todo lo que ocupaba el primer fragmento, y la diferencia del tamao de las cabeceras. Por supuesto, si slo hay dos fragmentos, el tamao del segundo fragmento ser el tamao del original sin fragmentar menos el tamao del primer fragmento. Con respecto a FO, es evidente que, ya que el FO del primer fragmento era 0, el del segundo depender nicamente de NFB, que es lo que ocupaban los datos del primer fragmento. Por ltimo, el flag MF estar activo slo si el propio datagrama original sin fragmentar era ya un fragmento de alguna fragmentacin anterior. Paso 10 El fragmento ya est listo, y lo podemos enviar a la capa de enlace para que lo procese. FIN. Bueno, bueno, bueno... Os dije que esto no iba a ser fcil. Pero llevamos ya el suficiente tiempo dando caa a los protocolos como para que os pueda exigir ya a estas alturas que os lo curris bien y analicis paso a paso el algoritmo para comprenderlo. Es difcil darlo ya ms masticado de lo que os lo he dado yo, as que mucho ms no puedo hacer. Lo que es complicado, es complicado.
2.2. Algoritmo de reensamblado de datagramas del RFC 791.

Este algoritmo es bastante ms denso y complicado de entender, as que en este caso es casi mejor contar con la descripcin general del algoritmo que viene en el RFC antes de detallar sus pasos. Esta descripcin nos aclara algunos detalles que quiz nos quedaban como lagunas hasta ahora. Por ejemplo, el mecanismo para diferenciar un datagrama fragmentado de uno no fragmentado, es que los no fragmentados siempre tendrn su FO (Fragment Offset) a 0, y al mismo tiempo el flag MF (More Fragments) a 0 tambin. Pgina 49
PC PASO A PASO N 26

Si, en cambio, su FO no fuese 0, pero s el MF, entonces sabramos que se trata del ltimo fragmento. Si el FO si fuese 0, pero el MF no, entonces tendramos el primer fragmento. Por ltimo, si ni el FO ni el MF son 0, entonces se tratara de un fragmento intermedio (ni el primero ni el ltimo). Resumo todo esto en una tabla: componiendo los datos que forman el datagrama segn nos van llegando en desorden. El buffer ser como una mesa vaca sobre la que iremos colocando las piezas de un puzzle segn las vayamos sacando de la caja. En realidad no se trata slo de un buffer, si no de dos: uno para los datos, y otro para la cabecera. Aparte de los buffers, se crea tambin una tabla vaca donde se van marcando los fragmentos segn se van recibiendo (una tabla que simplemente contiene un bit por cada fragmento , marcando a 1 los que vayan llegando). Ta m b i n t e n e m o s u n a va r i a b l e q u e inicializamos a cero, que es el Total Data Length, que ahora veremos en qu consiste. Por ltimo, tenemos un temporizador que nos servir para no permanecer eternamente esperando fragmentos que se hayan podido perder por el camino. Si el temporizador llega al fin de su cuenta y no se han recibido todos los fragmentos, entonces habr que descartar el datagrama i n c o m p l e t o, y l i b e ra r l o s r e c u r s o s . Vamos a ver un ejemplo de como se va reensamblando un datagrama. En primer lugar, recibimos un fragmento con Offset 3000. Nosotros an no lo sabemos, pero ste ser el tercero de los fragmentos que componen el datagrama. Lo que s que sabemos es que es un fragmento intermedio, ya que su bit MF est activado, y su Offset es mayor que 0.
Sabiendo esto, lo primero que se hace cuando se recibe un datagrama es comprobar estos dos campos. Si FO y MF estn a cero , entonces no se trata de un fragmento, y no hay que reensamblar. En cambio, si alguno de los dos no es cero, tenemos que ver a qu datagrama corresponde ese fragmento. Ya sabemos que los datagramas se identifican por los campos de la cabecera IP: direccin IP de origen, direccin IP de destino, protocolo, e identificador . A partir de estos datos, identificamos el datagrama. Ahora se nos pueden dar dos situaciones: que sea el primer fragmento que nos llega de ese datagrama, o que antes ya nos h u b i e ra n l l e g a d o o t r o s f ra g m e n t o s . Por supuesto, hablo del primer fragmento EN LLEGAR, que no tiene por que ser el primer fragmento de los que componen el datagrama. Los fragmentos pueden llegar al destino en cualquier orden, por diversos motivos. No siempre el primero que recibimos es el que tiene FO = 0, y MF = 1 (es decir, el primer fragmento que compone el datagrama original). En el caso de que sea el primer fragmento QUE NOS LLEGA, tendremos que reservar recursos en nuestra mquina para preparar el advenimiento del nuevo datagrama (qu religioso me ha quedado eso). Son varios los recursos que hay que reservar. En primer lugar, por supuesto, un buffer (espacio de memoria) en el que iremos Pgina 50
PC PASO A PASO N 26

En esta imagen podemos ver cmo la recepcin del datagrama, al ser el primero EN LLEGAR que tenga esa identificacin (es decir, esa combinacin de ip de origen, ip de destino, protocolo, e identificador), causa la creacin de una serie de recursos. Arriba a la derecha podemos ver la tabla binaria en la que se van marcando los fragmentos segn van llegando. A priori no sabemos el tamao que tendr esa tabla, ya que no sabemos cuntos fragmentos habr, pero lo que s que sabemos es que en el momento en que todas las posiciones de la tabla estn a 1, el datagrama estar completo. Lo que s que sabemos es que, al ser un fragmento intermedio, como mnimo tiene que haber un fragmento a su izquierda, y otro a su derecha, por lo que podemos crear 3 posiciones en la tabla, de las cuales slo est ocupada la intermedia. Debajo de la tabla tenemos la variable Total Data Length , cuyo valor de momento desconocemos, as que la inicializamos a 0, o con cualquier valor. Debajo tenemos el temporizador, cuya cuenta se pone en marcha para no quedarnos esperando eternamente el resto del datagrama. Por ltima, debajo tenemos la mesa marrn sobre la que iremos construyendo el puzzle. No sabemos de antemano qu tamao tendr, as que procuramos hacerla bastante grande para que nos quepan todas las piezas. Esta mesa es el buffer de recepcin. La primera pieza del puzzle se saca de los datos del fragmento que acabamos de recibir. A continuacin, nos llega otro fragmento, con Offset 1500. Nosotros no lo sabemos, pero este fragmento es el segundo de los que forman el datagrama original. Como su Offset sigue sin ser 0, sabemos que sigue tratndose de un fragmento intermedio. Por supuesto, el flag MF tiene que estar activado por narices, ya que el fragmento que habamos recibido previamente est a continuacin de ste. PC PASO A PASO N 26 Fijndonos en la Longitud de este segundo fragmento, vemos que mide 1500 bytes, por lo que encaja en nuestro puzzle perfectamente pegado justo a la izquierda del fragmento que recibimos antes.
Este fragmento modifica la tabla, aadiendo un 1 en una posicin intermedia, quedando ahora la tabla con 4 casillas. Adems, aade una nueva pieza al puzzle. Ahora nos llega un fragmento con Offset 4500, y con el flag MF a 0. Esto significa que es el ltimo fragmento . Como la Longitud del primer fragmento que nos lleg era de 1500 bytes, al sumar su offset y su longitud tenemos: 3000 + 1500 = 4500, que coincide con el Offset de este ltimo fragmento. Por tanto, el ltimo fragmento est en nuestro puzzle justo a la derecha del primer fragmento que nos lleg.
Nuestra nueva tabla ya no tendr hueco por la derecha, por lo que slo nos falta rellenar los fragmentos que nos falten por la izquierda. Pgina 51

La variable Total Data Length ahora puede ser calculada. Cogemos el Offset de nuestro fragmento, y le sumamos su Longitud. En este ejemplo la Longitud de este ltimo fragmento es de 350 bytes, por lo que: 4500 + 350 = 4850 bytes. Adems, hemos podido reducir el tamao de la mesa del puzzle, ya que sabemos que no vamos a necesitar ms espacio a la derecha. Ahora nos llega un fragmento ms. Su Offset es 0, y su Longitud es 1500 bytes. Por supuesto, el flag MF est activado. Sin lugar a dudas se trata del primer fragmento y, adems, al sumar su Offset y su Longitud, nos damos cuenta de que ya no faltan ms fragmentos, ya que encaja perfectamente en el puzzle a la izquierda del que ahora ya sabemos que es el segundo fragmento. Una de las grandes ventajas es que el algoritmo de reensamblado del RFC 815 consume menos recursos, lo cual veremos ms adelante que puede suponernos una ayuda contra ciertos tipos de ataques, aunque en cualquier caso si se proponen hacernos un DoS con alguna de las tcnicas que explicaremos, de poco nos va a servir ahorrarnos unos cuantos bytes en los buffers... Os dejo como ejercicio empollaros este RFC, que es muy cortito, a ver si consegus comprender ms o menos los algoritmos que explica.
3. Problemas de seguridad de la fragmentacin de datagramas.

Llegamos ya a la parte ms divertida. Los ataques que aprovechan la fragmentacin IP han estado siempre muy extendidos, y esto ha dado lugar incluso a la aparicin de un par de RFCs tratando exclusivamente este problema. El RFC que trata algunos de estos problemas de forma ms general es el RFC 1858. El RFC 3128 trata sobre una tcnica concreta de explotacin, y la proteccin contra la misma, ampliando as la informacin del RFC 1858.
Como vemos, la tabla ha sido ya completada. El puzzle est completo con todas sus piezas. El temporizador no ha vencido en el tiempo que hemos tardado en recomponer el datagrama original. Como resultado, podemos sacar del puzzle el datagrama original, ya listo para ser procesado como cualquier otro datagrama.
Pero no nos podemos conformar con la informacin contenida en estos RFCs, ya que no todos los posibles ataques de fragmentacin existentes estn detallados en estos documentos. De hecho, algunos de los ms conocidos, como el Ping of Death , o el Teardrop no son mencionados en ningn documento RFC (o al menos que yo sepa). A grandes rasgos, los ataques que explotan la fragmentacin se pueden dividir en dos grupos: ataques DoS, y ataques para atravesar firewalls.
2.3. Algoritmos de fragmentacin y reensamblado del RFC 815.

En el RFC 815 (ftp://ftp.rfc-editor.org/innotes/rfc815.txt) hay detallados unos algoritmos alternativos que simplifican bastante los algoritmos del RFC 791.
3.1. Ataques DoS

Estos son los ataques que considero ms fciles de comprender en principio. Los algoritmos de reensamblaje de fragmentos especificados en los RFCs 791 y PC PASO A PASO N 26
Pgina 52

815 son propensos a gran cantidad de problemas ya que, como ocurre con la mayora de los protocolos bsicos de Internet, fueron pensados para situaciones de buena fe, donde todo funciona como debera. Por tanto, no se tienen en cuenta muchas situaciones anmalas, como valores imposibles para los offsets de los fragmentos, flujos de datagramas incompletos, o fragmentos que forman datagramas demasiado grandes. Vamos a ver en detalle algunas de las tcnicas DoS que permiten explotar este exceso de confianza de los algoritmos de reensamblado. Los sistemas operativos modernos estn protegidos contra muchas de estas tcnicas, pero an siguen quedando servidores sin actualizar que pueden ser vulnerables. En cualquier caso, siempre es interesante conocer todo lo que se puede hacer gracias a un algoritmo mal diseado. Estad preparados, porque aqu hay mucha chicha. y con eso: hop! la mquina 80.12.1.4 quedaba petada. Dependiendo del sistema operativo de la vctima, la mquina poda reiniciarse, colgarse, o, slo en los casos ms raros, salir indemne (la mayora de los sistemas operativos eran vulnerables). La opcin -l en el comando ping de Windows sirve para especificar la longitud del campo DATOS del mensaje ICMP Echo Request que enviar el ping. Los pings normales (el valor por defecto) envan tan slo 64 bytes de datos . Con esta opcin -l le estamos diciendo que enve 65510 bytes de datos por cada ping. Cualquier valor igual o mayor que 65510 puede servir para llevar a cabo el DoS. Ms adelante veremos por qu esto causa un problema. En el caso de Linux, la longitud del campo de datos se especifica con la opcin -s, pero en este caso est limitado a un mximo de 65507 bytes, lo cual no permite llevar acabo este ataque (si, esos 3 bytes son f u n d a m e n t a l e s , c o m o ya v e r e m o s ) . Hoy da dudo que queden muchas mquinas conectadas que todava sean vulnerables al Ping of Death, pero me parece un ejemplo muy didctico de en qu puede consistir un ataque DoS que explote la fragmentacin IP. Vamos a ver paso a paso qu es lo que pasa con un ICMP Echo Request que contenga 65510 bytes de datos . Para ello os recomiendo que revisis el artculo anterior (que trataba sobre la cabecera IP), as como el artculo sobre ICMP de este mismo curso. En primer lugar, vamos a calcular el tamao total de este paquete. La cabecera del mensaje ICMP Echo Request son 8 bytes (como vimos en el artculo sobre ICMP ), mientras que la cabecera IP sin opciones es de 20 bytes. Por tantos, si sumamos estos 28 bytes de cabeceras a los 65510 bytes del campo de datos, tenemos un total de 65538 bytes.
3.1.1. Ping of Death

Este ataque, el ping de la muerte, fue muy popular cuando fue descubierto en 1996. Durante un par de aos fue el paraso sobre todo para los scriptkiddies (o lamers, para que nos entendamos) que encontraron una forma universal de destruir cualquier mquina con slo escribir un simple comando. Este comando se poda escribir directamente desde Windows 95 o Windows NT, que eran los sistemas operativos de Microsoft que haba en el momento, sin necesidad ni siquiera de instalar ninguna aplicacin para explotar el ataque. En cambio, para los usuarios de Linux era necesario compilar un pequeo cdigo. Si un usuario de Windows 95/NT quera petar a un to cuya ip fuese 80.12.1.4, slo tena que escribir en una ventana MS-DOS : ping -l 65510 80.12.1.4 PC PASO A PASO N 26
Pgina 53

Por qu el ping de algunos sistemas operativos como Linux no permiten hacer este ping? Pues porque, si recordamos del artculo anterior el campo Total Length de la cabecera IP, sabremos que este campo especifica con slo 16 bits el tamao del datagrama, por lo que el tamao mximo de un datagrama tendra que ser 65536 bytes. Precisamente en este punto es donde est la clave del ataque. Slo hay una forma en la que este datagrama puede enviarse, ya que el campo Total Length de la cabecera IP no da ms de si. El nico medio es fragmentar el datagrama, y ajustar de forma adecuada el tamao de cada fragmento. En el caso ms sencillo, el datagrama sera fragmentado en dos de la siguiente forma: De momento, ningn problema: cada paquete es correcto por separado. Pero el problema viene cuando el sistema trata de reensamblar estos dos fragmentos. Al unir los fragmentos el sistema ha de computar el tamao del datagrama original (el Total Length). Para ello se hace una suma de 16 bits de los tamaos de cada fragmento. El resultado de esta suma en este caso sera 32768 + 32770 = 65538, lo cual se sale del rango de la suma, que estaba limitada a 16 bits. Esta suma fuera de rango no estaba prevista por el sistema operativo y, por tanto, producir resultados inesperados que, en la mayora de los casos, daban lugar a que el sistema se colgase, o bien se reiniciase. Por qu se utilizaba precisamente un ping cuando cualquier otro tipo de datagrama h a b r a s e r v i d o p a ra e l m i s m o f i n ? Pues bien, en efecto hay variantes del POD (Ping Of Death) que utilizan otro tipo de datagramas, como datagramas UDP, u otros tipos de ICMP. Pero las grandes ventajas de usar ping son dos: por una parte, que ICMP es un servicio no orientado a conexin, por lo que no es necesaria ninguna informacin para colarse en una conexin como podra ser el caso de TCP. El hecho de no tener que colarse en una conexin nos da la gran ventaja de que podemos enviar el ataque sin preocuparnos de tener que recibir ninguna respuesta. Al no tener que esperar respuestas, podemos perfectamente enviar el ataque con un IP-Spoofing, tal y como veremos en el prximo artculo, en el cual entraremos en todo detalle en las tcnicas de IP-Spoofing. Esto permita realizar el ataque de forma totalmente annima. La otra ventaja de utilizar el ping es que, hasta el momento en que surgieron este tipo de ataques, prcticamente ningn firewall filtraba los mensajes ICMP Echo Request, al considerarlos totalmente inofensivos. Despus de la aparicin de estos ataques basados en el ping, la mayora de los firewalls empezaron a filtrar los mensajes ICMP Echo Request. Esto fue una medida de defensa
Estos fragmentos siguen siendo demasiado grandes para pasar por cualquier red, por lo que sin duda seran fragmentados a su vez para ajustarse a la MTU de la red por la que tuviesen que circular. Pero esto lo vamos a obviar, por lo que supondremos que lo que llega a la vctima son directamente estos dos paquetes (para simplificar mucho el ejemplo). El sistema operativo de la vctima recibir el primer fragmento, con Offset 0, tamao de paquete (TL) de 32768 bytes, y el flag MF activado. A continuacin (aunque no tendran por qu llegar necesariamente en este orden, como ya sabemos) recibir el segundo paquete, con Offset 32768, tamao de paquete de 32770 bytes , y el flag MF desactivado (ya que es el ltimo fragmento).
Pgina 54
PC PASO A PASO N 26

bastante ingenua, ya que enseguida surgieron nuevas variantes del POD que utilizaban cualquier otro tipo de datagramas, ya que el fin ltimo al fin y al cabo era simplemente conseguir hacer llegar un datagrama fragmentado, fuese de la naturaleza que fuese. Cmo puede ser entonces que hoy da la inmensa mayora de los sistemas sean inmunes a este tipo de ataques, si no se pueden evitar filtrando el ping en un firewall? Pues sencillamente, la solucin al problema se implement en el propio sistema operativo. Salieron parches para los sistemas existentes en el momento, y adems todos los sistemas que se hicieron despus eran ya inmunes de fbrica, es decir, tenan prevista la situacin de que un datagrama pudiese medir ms de 65536 bytes tras ser reensamblados sus fragmentos. Como ejemplo, los kernels de Linux posteriores al 2.0.23 son ya todos inmunes a estos ataques. En cualquier caso, no slo nos tenemos que resignar a confiar en lo que haga nuestro sistema operativo, si no que tambin podemos nosotros tomar parte activa en la proteccin de nuestra mquina ante estos ataques. A la hora de implementar protecciones en nuestro firewall contra ataques especficos es fundamental conocer con detalle el funcionamiento del ataque. Por ejemplo, buscando por Google, podemos encontrar esto: # Block PING OF DEATH
$IPT -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j LOG --log-prefix "Ping of Death Blocked: "
$IPT -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j DROP

$IPT -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j LOG --log-prefix "Ping of Death Blocked: "
$IPT -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j DROP Si habis seguido el curso de implementacin de firewalls de la revista, sabris que estas lneas son una serie de reglas de IPTABLES, el firewall implementado en el kernel de Linux. Si conocemos el funcionamiento de iptables (man iptables) sabremos que lo que hacen estas lneas es limitar a que slo podamos recibir un mximo de un ping por segundo (protocolo ICMP, tipo de mensaje Echo Request, y limite de 1/segundo). Aunque estas reglas de iptables presuman de ser una proteccin contra el POD, nada ms lejos de la realidad. Lo nico que hacen es evitar un flood de pings, que podra ser resultado de algn ataque DDoS (DoS distribuido). Lo que os quiero decir con esto es que no podemos fiarnos de las soluciones que encontremos por ah, ya que si bien muchas veces encontraremos soluciones adecuadas, en cualquier caso siempre tenemos que estar preparados para analizar con nuestros propios conocimientos si esa es realmente una solucin para nuestro problema, o si ms bien el to que lo escribi (probablemente con toda su buena fe) no tena mucha idea de en qu consiste realmente el ataque. Seguramente alguno de vosotros en este punto habr pensado que, si bien esa proteccin no sirve contra el POD, si que podra servir contra un ataque Smurf, que consiste precisamente en un flood de pings (tal y como expliqu en el artculo sobre ICMP). Pues para todos los que hayis pensado eso, os pongo un punto positivo, ya que demuestra que habis estado bastante atentos al curso. Ahora bien... para quien pongo ya no uno sino tres puntos positivos es para el que se haya dado cuenta de que los que hayan pensado eso estn equivocados, ya que falla un pequeo detalle. El ataque smurf,
PC PASO A PASO N 26
Pgina 55

en efecto, se lanza mediante pings, pero lo que la vctima recibe no son los pings, si no los pongs, es decir, no recibe un flood de Echo Request, si no de Echo Reply. Por tanto, esta s sera una proteccin contra Smurf con iptables: # Bloqueo de Flood por ataque Smurf
$IPT -A FORWARD -p icmp --icmp-type echo-reply -m limit --limit 1/s -j LOG --log-prefix "Smurf a red interna: "
$IPT -A FORWARD -p icmp --icmp-type echo-reply -m limit --limit 1/s -j DROP $IPT -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j LOG --log-prefix "Smurf al firewall: " $IPT -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j DROP Esto, por supuesto, no nos servira para evitar convertirnos en un amplificador Smurf, es decir, convertirnos en colaboradores involuntarios del ataque contra otra persona. Como ya vimos, el ataque Smurf depende de mquinas inocentes que respondan a los mensajes de ping a la direccin broadcast de la red. La solucin a este problema es mejor implementarla a otro nivel, que no es el de las iptables, dicindole directamente a nuestro sistema operativo que ignore cualquier ICMP Echo Request que tenga como destino la direccin broadcast de la red. Esto lo podemos hacer con la siguiente lnea: echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts Esta lnea la podemos incluir como parte de los scripts de arranque del sistema (los clsicos de /etc/rc.d), o bien en el archivo /etc/sysctl.conf. Pero no nos salgamos del tema, y pensemos cmo podemos protegernos contra el POD con iptables. Una solucin especfica contra POD sera esta: # Esto s que bloquea un Ping Of Death iptables -A INPUT -p icmp --icmp-type echo-request --fragment -j LOG --log-prefix Ping fragmentado: iptables -A INPUT -p icmp --icmp-type echo-request --fragment -j DROP iptables -A FORWARD -p icmp --icmp-type echo-request --fragment -j LOG --log-prefix Ping fragmentado: iptables -A FORWARD -p icmp --icmp-type echo-request --fragment -j DROP Aqu estamos rechazando cualquier fragmento que pertenezca a un datagrama ICMP Echo Request. No hay ningn motivo legal por el que nadie quisiese enviarnos un Echo Request fragmentado, por lo que no estamos impidiendo el correcto funcionamiento de nuestra red por aadir esta regla. Como podemos suponer, esta regla no es lo suficientemente restrictiva, ya que si bien evitara el ataque POD, alguna de sus variantes (las que utilicen otros tipos de mensaje ICMP, o bien otros protocolos, como UDP o TCP) s que pasaran por el firewall. Para evitar las variantes que utilicen otro tipo de mensajes ICMP podramos ser menos especficos en la regla, y filtrar cualquier ICMP fragmentado, ya que en general no existe ningn uso legal para ningn tipo de ICMP fragmentado: # Esto bloquea cualquier ataque por mensajes ICMP fragmentados iptables -A INPUT -p icmp --fragment -j LOG --log-prefix ICMP fragmentado: iptables -A INPUT -p icmp --fragment -j DROP iptables -A FORWARD -p icmp --fragment -j LOG --log-prefix ICMP fragmentado: iptables -A FORWARD -p icmp --fragment -j DROP
Pgina 56
PC PASO A PASO N 26

Con esto an no solucionaramos el problema de los ataques tipo POD que utilicen otros protocolos distintos a ICMP. Por lgica podramos pensar que otros protocolos, como TCP, que transportan protocolos de nivel superior que pueden llevar un gran flujo de datos (como FTP), no podran funcionar correctamente sin la fragmentacin. Por tanto, de momento dejamos aqu el tema, y nos conformamos con haber encontrado una solucin para que nuestro firewall filtre los ataques POD clsicos (con mensajes ICMP), y ms adelante iremos viendo cmo solucionar el problema con el resto de protocolos. El flood consiste en tirar un sistema a base de saturar sus recursos por fuerza bruta, mientras que el nuke consiste en explotar un bug concreto de un sistema que no es capaz de responder bien ante cierta situacin. Por ejemplo, el POD es un claro ejemplo de nuke , en el cual con un slo datagrama podemos tirar un sistema. En cambio, el smurf es un claro ejemplo de flood, en el cual se tira el sistema a base de saturarlo con miles de ICMPs. Con respecto a jolt2 hubo ciertas discusiones sobre si realmente era un nuke, o si en realidad era un simple flood, ya que el exploit que circulaba (jolt2.c, lo podis buscar en Google) enviaba paquetes a toda pastilla, tanto incluso que saturaba la conexin del propio atacante. En cambio, poco despus circul una nueva versin de jolt2 ( jolt2mod.c , tambin lo podis buscar) que ralentizaba el envo de paquetes para no saturar la conexin del atacante. Cada vez que hablo de un tema diferente me gusta contarlo de una forma diferente, as que os voy a hablar en primer lugar de los retoques que he tenido que hacer al cdigo fuente de ambos exploits. En primer lugar, al tratar de compilar el cdigo de Jolt (jolt.c, lo podis buscar tambin), con: gcc jolt.c -o jolt Descubro que no compila, ya que da un error con un campo de una estructura que no existe. As que edit el cdigo: vi jolt.c Y busqu cualquier referencia a ese campo, y vi que apareca una nica vez, en una lnea que slo le daba un valor 0. As que coment esa lnea (la met entre /* y */), salv el archivo, y lo volv a compilar, esta vez sin problemas. No os he dicho los pasos exactos para proponeros que lo hagis vosotros mismos como ejercicio. Pgina 57
3.1.2.Jolt y jolt2
Estos dos exploits explotan dos bugs diferentes, pero ambos relacionados con la fragmentacin. Jolt es ms antiguo, y os costar encontrar alguna mquina vulnerable hoy da, pero Jolt2 se supone que puede tirar a varios sistemas, incluido Windows 2000 . No hay mucho que explicar sobre estos exploits, ya que lo que hacen simplemente es enviar una serie de paquetes fragmentados que muchos sistemas operativos no saben cmo tratar y, por tanto, pueden colgar el sistema. Y por qu no hay mucho que contar? Pues porque son unas tcnicas ms empricas que lgicas. Al menos hasta donde yo he podido documentarme, no he encontrado ninguna explicacin convincente de por qu estos paquetes pueden colgar un sistema. De hecho, lo que s que he encontrado han sido discusiones en foros de seguridad sobre qu hace o deja de hacer cada uno, y por qu lo hace o lo deja de hacer. En cualquier caso, sea magia o sea ciencia, el caso es que ambos exploits han sido de los ms famosos en la historia de los nukes. Como ya cont en otro artculo, existen bsicamente dos tipos de DoS: el flood y el nuke. PC PASO A PASO N 26

Para usar el exploit slo tenis que decir la ip de destino y la de origen (permite ipspoofing): ./jolt ip.victima ip.spoofeada Lo ms probable es que esta tcnica no os funcione, ya no slo porque queden pocos sistemas vulnerables, si no porque probablemente ni siquiera pueda atravesar alguno de los routers que haya en la ruta, al ser un paquete malformado que podra ser rechazado. An as, por si tenis curiosidad, podis analizar con un sniffer lo que hace Jolt. Os ahorro el trabajo si os cuento que simplemente enva una serie de fragmentos solapados, es decir, fragmentos en los que el campo offset de un fragmento no se corresponde con el total length del anterior fragmento. Ms adelante veremos usos mucho ms interesantes para el solapamiento de fragmentos. Con respecto a Jolt2, tambin tuve que hacer una modificacin al cdigo fuente. En este caso us la variante jolt2mod.c. Supuestamente, el exploit debera permitir un ip-spoofing utilizando la opcin -s, tal y como podis ver si despus de compilarlo: gcc jolt2mod.c -o jolt2mod Lo ejecutis, para que os muestre su funcionamiento:
Bellatrix:/home/pyc/hackxcrack/ip3# ./jolt2mod Usage: ./jolt2mod [-s src_addr] [-p port] dest_addr Note: UDP used if a port is specified, otherwise ICMP
de esas lneas era nulo. Una vez corregido el cdigo es as como queda esa parte: src_addr = host_to_ip(optarg); if (!src_addr) quit("Bad source address given."); break; Os dejo como ejercicio tambin que os las apais vosotros para hacer esta correccin. Una vez corregido esto, vemos el mismo problema. Los paquetes estn malformados y es probable que no puedan pasar por todos los routers. Si analizamos su funcionamiento con un sniffer (o analizando el cdigo fuente) veremos que lo que hace es enviar una y otra vez el mismo fragmento, con todos los campos exactamente iguales. Por qu esto puede tirar un Windows? Sinceramente, no tengo ni idea; eso que se lo pregunten a Bill Gates.
3.1.3. Ataques de flood de fragmentos

Si vuestras mentes estn despiertas probablemente se os haya ocurrido pensar que Jolt2 funciona porque cada vez que Windows recibe un fragmento reserva unos recursos para ese paquete (como ya vimos antes), y al no recibir el resto de fragmentos llega un momento en el que los recursos del sistema se agotan. Esta es una deduccin muy buena, pero tiene un pequeo fallo, y es que el identificador es el mismo para todos los fragmentos. Por tanto, cada fragmento nuevo no obligara al sistema (en teora) a reservar nuevos recursos. En cambio, si utilizamos diferentes identificadores para cada fragmento, s que podramos llegar a saturar los recursos de la mquina, al hacer reservar buffers para cada nuevo fragmento, esperando todos ellos llegar a completar el datagrama al que pertenecen. Esto es algo que fcilmente puede ocurrir con firewalls que ignoren los fragmentos, incluso de forma no intencionada.
En cambio, al analizar el funcionamiento de jolt2 con un sniffer (Ethereal, concretamente) descubr que hace caso omiso a la opcin s. Revisando el cdigo fuente descubr que en una lnea en la que debera poner src_addr pona dst_addr, por lo que lo que se estaba cambiando no era la ip de origen (para hacer el ip-spoofing), si no la ip de destino. Como la ip de destino (dst_addr) en cualquier caso se volva a modificar ms adelante, el efecto Pgina 58
PC PASO A PASO N 26

Un comportamiento tpico de un firewall ante un datagrama fragmentado es analizar nicamente el primer fragmento (que es donde se encuentran las cabeceras). En caso de que ese primer fragmento sea rechazado por el firewall, el resto de fragmentos s que atravesarn el firewall en cualquier caso. Por tanto, a la mquina que haya detrs le llegarn todos los fragmentos excepto el primero. Esto provocar que la mquina reserve recursos intilmente para formar un datagrama que nunca llegar, ya que le falta el primer fragmento. acaso es necesario eso? Acaso no surgen constantemente nuevos exploits para Windows, del cual nadie tiene el cdigo fuente? En cambio, el hecho de tener el cdigo fuente disponible s que favorece todo lo contrario: en el momento en que surja un problema, cualquiera podr buscar la causa, y darle un remedio. No dependemos de las actualizaciones mensuales de Microsoft (si es que a Microsoft le sale de las narices corregir ese problema). Nosotros mismos podemos corregirlo o, si no, cualquier usuario de la comunidad Linux que amablemente lo haya corregido por nosotros y haya hecho esa solucin pblica. Una vez ms: GNU - 1, Microsoft 0. Este exploit de tipo nuke utiliza tambin el (igual que Jolt), pero en este caso s que soy capaz de explicar mejor por qu funciona. En mi defensa puedo decir que Jolt es un exploit para Windows, y como el cdigo fuente de windows no est disponible, muchas veces es imposible decir por qu est fallando algo. En cambio, Teardrop es un exploit que afecta tambin a Linux, cuyo cdigo fuente est disponible para todo el mundo. Por tanto, viendo el cdigo, si que podemos decir por qu est fallando algo. Aqu llegamos a una cuestin que se plantea muchas veces a la hora de discutir si es bueno o no tener el cdigo fuente disponible. Un argumento bastante irreflexivo consiste en decir rpidamente: pero claro, si un hacker maligno puede ver el cdigo fuente, podr entonces encontrar formas de atacar a ese sistema. Pues s, en efecto, revisando el cdigo fuente de un sistema operativo puedes encontrar problemas potenciales de seguridad, pero... PC PASO A PASO N 26 Bueno, pues volviendo al tema, vamos a razonar el funcionamiento del Teardrop . Para ello, vamos a ver una captura de un sniffer ( Ethereal ) tras lanzar el exploit .
3.1.4. Teardrop
Para ejecutar el exploit, primero tendremos que compilar el cdigo teardrop.c: gcc teardrop.c -o teardrop Y a continuacin lo lanzamos con: ./teardrop ip.spoofeada ip.victima Pgina 59

Y vamos al sniffer a ver qu ha hecho. Repito una vez ms que tambin se puede analizar el comportamiento mirando el cdigo fuente en lugar del sniffer. Si lo analizamos vemos en primer lugar que slo son dos fragmentos (increble poder tirar un sistema con slo dos paquetitos), y que ambos pertenecen al mismo datagrama (mismas ips de origen y destino, ambos con protocolo udp, y ambos con el mismo identificador). Lo que cambia entre los dos fragmentos son los campos Total Length y Offset, y aqu es donde est la clave. El primer fragmento tiene: Total Length = 56 bytes Offset = 0 (flag MF activado) El segundo fragmento tiene: Total Length = 24 Offset = 24 Como el segundo fragmento no tiene activado el flag MF, es de suponer que es el ltimo fragmento. El sistema operativo que recibe estos fragmentos tratar de computar el Total Length del datagrama original sumando los campos Total Length y Offset del ltimo fragmento : 24 + 4 = 48 bytes . Esto da lugar a una situacin imposible, ya que el primer fragmento tiene una longitud mayor que la que supuestamente tiene el datagrama original (56 bytes). El cdigo que realiza el reensamblado del datagrama encuentra aqu una situacin en la que tiene que reservar memoria para un nmero de bytes negativo. Este nmero negativo ser interpretado como un nmero positivo muy grande (por cmo son tratados los nmeros negativos en variables en las que no son esperados), por lo que el sistema tratara de reservar demasiada memoria y, por tanto, se colgara. Estos cuelgues no ocurren cuando es una aplicacin la que trata de reservar demasiada memoria, ya que el sistema operativo se encarga de que esto no ocurra, pero cuando es el propio sistema operativo el que realiza esta operacin imposible, entonces no hay santo que nos proteja. Pgina 60
3.2. Saltando firewalls e IDSs.

Vamos a ver aqu un problema de compromiso a la hora de configurar nuestro firewall, ya que muchas veces las soluciones contra los ataques DoS favorecen este otro tipo de ataques, y viceversa. An as, en el ltimo punto del artculo explicar la que podra ser una solucin definitiva contra ambos tipos de ataques. Este problema de seguridad es, en mi opinin, mucho ms serio y ms interesante que el de los ataques DoS. De hecho, es esta cuestin la que dio lugar a la aparicin de los RFCs 1858 y 3128. Un ataque DoS puede ser un complemento para llevar a cabo un ataque ms complejo, como vimos por ejemplo en el caso del envenenamiento DNS . En cambio, esta tcnica es ya una forma concreta de saltarse la seguridad de una red. La tcnica ms conocida que explota esta vulnerabilidad es la conocida como Tiny Fragment Attack. Personalmente, me parece una de las formas ms elegantes de explotar las potencialidades de un protocolo. La idea bsica del Tiny Fragment Attack (TFA) consiste en hacer picar al firewall con un cebo falso, como un caballo de troya, para luego soltar a todo el ejrcito una vez que el firewall nos ha abierto sus puertas. Un firewall clsico de filtrado de paquetes funciona bsicamente analizando ciertos campos de la cabecera de un paquete, y comparndolos con sus reglas de filtrado. En caso de que haya una coincidencia, ese paquete deber ser rechazado o aceptado, segn lo que indique la regla. Veamos como ejemplo una lista de reglas de un firewall muy simple: Iptables A FORWARD p tcp --destport 21 j ACCEPT Iptables A FORWARD p tcp j DROP Con estas dos lneas, en primer lugar analizaramos cualquier paquete TCP entrante para ver si el puerto de destino es el 21. PC PASO A PASO N 26

En caso afirmativo, lo aceptamos . En cualquier otro caso, el paquete pasara a la segunda regla, que sencillamente rechaza absolutamente todo paquete TCP que le llegue. Supongamos que queremos acceder al puerto 80 de la mquina que hay detrs del firewall. Por supuesto, el firewall nos lo est impidiendo, ya que slo pasarn los paquetes que tengan como puerto de destino el 21. Veamos qu ocurre si enviamos este paquete: Como vemos, el datagrama que resulta tras terminar el reensamblado es totalmente diferente del que pas felizmente por las defensas del firewall, ya que este nuevo datagrama tiene como puerto de destino el 80, y no el 21. Podramos pensar que una posible solucin para este problema podra ser configurar nuestro firewall para que l mismo reensamble los fragmentos, para aplicar las reglas sobre los fragmentos ya reensamblados. Este paquete coincidir con la primera regla del firewall (puerto de destino = 21), por lo que podr pasar las defensas inocentemente. Por tanto, el firewall, todo confiado, dejar pasar el resto de fragmentos que componen este datagrama. Pero... y si el segundo fragmento es de esta forma? : Pero es aqu donde nos damos cuenta de lo que deca al principio de este punto, y es que el remedio podra ser peor que la enfermedad. Si hacemos que el firewall se encargue del reensamblado, y en lugar de un ataque TFA estuvisemos recibiendo alguna de las muchas variantes de ataques DoS que explotan las vulnerabilidades de los algoritmos de reensamblado, el firewall podra quedar DoSeado y, por tanto, denegar el servicio a todas las mquinas de la red que estn amparadas por l. El RFC 1858 nos recomienda que impongamos un valor mnimo para el campo Offset de cualquier fragmento (excepto el valor 0, claro, que sera siempre el Offset del primer fragmento), para que un fragmento que no sea el primero no pueda contener nunca parte Como vemos, el Offset es tan slo de 2 bytes, por lo que a la hora de reensamblar el supuesto datagrama original, los datos del segundo fragmento se solaparn sobre los del primero : PC PASO A PASO N 26 de la cabecera TCP . Es decir, el primer fragmento siempre debe contener, como mnimo, la cabecera completa TCP, y los siguientes fragmentos slo podrn contener los datos del paquete. Pgina 61

En cualquier caso, si continuamos leyendo, encontraremos la que podra ser la solucin universal para todos nuestros problemas. script de iptables de 358 lneas, hace unos aos), aunque trataban el tema de los fragmentos, eran mucho menos restrictivas. Como para escribir mis artculos no me basta slo con documentarme, si no que tambin recurro a la experimentacin de todo lo que explico, prob hace unos das a meter estas dos lneas, y... magia! todo sigue funcionando exactamente igual. No solo eso, si no que mis iptables no han logeado ni un solo fragmento (iptables -A FORWARD --fragment -j LOG --log-prefix Fragmento: ), por lo que queda demostrado que en los das que han estado activas esas reglas no he recibido ni un slo datagrama fragmentado . Por supuesto, esto no me ha pillado de sorpresa, ya que conoca de antemano el tema del que os voy a hablar ahora, pero s que me sorprendi un poco comprobar la importancia que tiene realmente esta forma de evitar la fragmentacin. He hecho pruebas bastante exhaustivas con ICMP y TCP, y todo funciona perfectamente. Lo que ya no he probado tanto ha sido el UDP, as que os invito a que probis vosotros mismos los resultados. Por lo que os voy a explicar ahora, es posible que con UDP las cosas no funcionen tan bien, as que quiz deberamos cambiar esas 2 reglas tan radicales por estas (pongo solo las de FORWARD, para INPUT podramos copiarlas tal cual): iptables -A FORWARD -p tcp --fragment -j DROP iptables -A FORWARD -p icmp --fragment -j DROP
iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
4. Cmo prescindir de la fragmentacin, y que todo siga funcionando.

Empecemos preguntndonos, realmente debemos prescindir de la fragmentacin? Pues ya hemos visto muchos motivos de seguridad por los que la fragmentacin es poco deseable. Aunque la mayora de las tcnicas que he explicado estn prcticamente obsoletas hoy da, est claro que la fragmentacin da mucho juego para encontrar nuevas formas de retorcer los protocolos hasta conseguir que hagan lo que se supone que no deberan hacer. Por otra parte, el nico motivo por el que la fragmentacin no es deseable no es slo la seguridad. Tambin es importante el consumo extra de recursos que supone tener que gestionar la fragmentacin, y sobre todo el reensamblado. Una mquina que tenga que estar reensamblando datagramas tendr un aumento en su consumo de CPU y de memoria, dos recursos que en muchas mquinas valen como el oro, y hay que intentar optimizar al mximo. Despus de todo lo que hemos visto, a que os dan ganas de meter estas lneas en las iptables? iptables -A INPUT --fragment -j DROP iptables -A FORWARD --fragment -j DROP Estas lneas rechazaran cualquier paquete fragmentado, fuese de la naturaleza que fuese. Pero claro, ponemos eso, y lgicamente todo dejar de funcionar.... o no? Para escribir este artculo he tenido que documentarme mucho sobre el tema (como es lgico), y en ningn sitio he ledo que nadie aconseje aplicar unas reglas tan radicales a un firewall. De hecho, las reglas que tena yo en mis propias iptables (cuando me curr mi Pgina 62
Y esa ltima lnea? Se le ha pirado la pinza al chaval con tanta iptable? Pues no, tranquilos, que an no me he vuelto loco. Esa ltima lnea es necesaria para que funcione la tcnica que os voy a explicar a continuacin que permite prescindir de la fragmentacin IP. PMTUD Posiblemente este ttulo os suene ya de algo, ya que en el artculo sobre ICMP expliqu a PC PASO A PASO N 26

grandes rasgos en qu consiste el PMTUD (Path MTU Discovery). El PMTUD es un mecanismo relativamente simple que permite encontrar el PMTU de una ruta entre dos mquinas. Y qu es el PMTU? Pues bueno, hasta el momento sabemos lo que es la MTU. La MTU (Maximum Transmission Unit) es el tamao mximo de paquete que puede transportar una red de una tecnologa concreta (por ejemplo, 1500 bytes para el caso de redes Ethernet). El problema es que Internet es una red terriblemente heterognea, donde conviven todo tipo de tecnologas de red diferentes. En el camino que puede haber entre dos mquinas conectadas a Internet puede haber routers que interconecten tecnologas de lo ms variopintas. As, en el camino entre nuestro PC y un servidor web nos podemos encontrar fcilmente con que nuestros paquetes circulan por redes Ethernet, PPPoE (tecnologa utilizada en ADSL ), y muchas otras tecnologas diferentes. Cada una de las redes por las que pase el paquete tendr su propia MTU . Pero lo que a nosotros nos importa realmente a la hora de enviar nuestro paquete, si no lo queremos fragmentar, es cul es LA MENOR de todas esas MTUs que nos encontraremos por el camino (path, en ingls). A la menor de las MTUs que hay en un camino (path) entre dos mquinas, la denominamos Path MTU, o PMTU. Si nuestros paquetes no superan en tamao a la PMTU, no habr ningn motivo por el que nuestros datagramas tengan que ser fragmentados para llegar a su destino. Entonces, aqu tenemos la solucin para evitar la fragmentacin! Nos basta con encontrar de alguna manera cul es la PMTU de la ruta que hay entre nuestro PC y la otra PC PASO A PASO N 26 mquina con la que queremos conectarnos. Una vez que la conocemos, sern los protocolos de nivel superior los que se encarguen de dividir sus datos de forma conveniente, en lugar de dejar esa responsabilidad a la capa IP. Pero, es que los protocolos que estn por encima de IP tambin dividen sus datos? Pues claro! Acaso pensis que cuando queremos enviar un archivo de 650MBs (como una ISO de un CD) lo que hace nuestra capa TCP es enviar de golpe los 650MBs a la capa IP para que sta se apae y los fragmente como pueda? Esta claro que la capa TCP tambin tiene sus limitaciones y no puede andar trasteando con paquetes de cualquier tamao. De hecho, algo sabemos acerca de esta limitacin, pues ya hablamos en este curso acerca de la opcin MSS ( M aximum S egment S ize) de la cabecera TCP. Precisamente en este campo MSS es donde se apoya el mecanismo de PMTUD. Como ya vimos, la opcin MSS se incluye slo en el primer paquete de una conexin TCP, es decir, en el paquete que lleva el flag SYN. En el caso del cliente, ser el paquete inicial de la conexin, que llevar solo el flag SYN, y en el caso del servidor ser el segundo paquete de la conexin (primero que enva el servidor), que es el que lleva los flags SYN y ACK. Este primer paquete es la primera pista para el mecanismo de PMTUD. Pero mejor vamos a ir viendo esto paso por paso con un ejemplo concreto. Tenemos 2 mquinas: cliente, y servidor. Cliente establece una conexin TCP con Servidor, para lo cual tiene que enviar su paquete TCP inicial (con el flag SYN, y la opcin MSS). Este paquete circular a travs de toda la ruta que une ambas mquinas. Pgina 63

de MSS tendremos que restar 40 bytes a la MTU. Es decir, en nuestro caso: 1500 -40 = 1460. Por tanto, en nuestro campo MSS tendremos que poner 1460 si queremos que nuestros paquetes TCP se ajusten a nuestra MTU una vez que sean convertidos en datagramas. Vamos a ver qu ocurre ahora cuando nuestro primer paquete, con MSS = 1460 y el flag DF activado, intenta llegar hasta el servidor. Y la clave de todo est en cierto campo de este primer paquete, y ms concretamente en un nico bit. El flag DF de todos los paquetes (incluyendo, por supuesto, este primero) tiene que estar activado. Esta es la clave del funcionamiento del PMTUD. Por tanto, con este primer paquete, adems de intentar establecer la conexin (flag SYN), estamos haciendo dos cosas ms. Por una parte, estamos informando al Servidor del tamao de paquetes que podemos manejar (opcin MSS), y por otra estamos tanteando la ruta que hay entre nosotros y el servidor, ya que al activar el flag DF, nuestro paquete slo podr llegar a su destino si tiene un tamao adecuado, es decir, si es menor o igual que la PMTU entre el Cliente y el Servidor. Con respecto a la primera cuestin, la de informar al Servidor acerca de nuestra MSS, seremos un poco listos a la hora de escoger el valor de MSS que le daremos al Servidor. Imaginemos que nuestra capa TCP puede manejar buffers de hasta 65535 bytes. En principio, ste podra ser el valor que daramos al campo MSS, indicando que TCP puede procesar paquetes de hasta 64KB. Pero, qu utilidad tendra esto si sabemos de antemano que otras capas inferiores no van a poder con ese paquete? Vale, nosotros no sabemos cual es la PMTU, es decir, no sabemos cmo de pequeos tendrn que ser los paquetes para poder recorrer toda la ruta, pero lo que s que sabemos es cul es NUESTRA MTU, es decir, el tamao mximo de paquete para la red a la que nosotros estamos conectados. Por tanto, lo ms lgico es partir ya en principio de una primera aproximacin a la PMTU, ya que sabemos de antemano que la PMTU nunca podr ser mayor que nuestra propia MTU (ya que la PMTU es la menor de todas las MTUs que haya en toda la ruta, incluida la nuestra, por supuesto). Pongmonos en el caso de que nuestra red sea una Ethernet, que tiene una MTU de 1500 bytes. Debemos poner entonces 1500 en el campo MSS? Pues no! No tan rpido! Hay que tener en cuenta que 1500 bytes es el tamao mximo para un datagrama, es decir, para un paquete IP. Pero la opcin MSS no se refiere a paquetes IP, si no a paquetes TCP. Un paquete TCP es un paquete IP al cual le hemos quitado (o ms bien, an no le hemos aadido) la cabecera IP. Y el campo MSS se refiere al tamao de los datos de un paquete TCP (es decir, sin la cabecera TCP). Por tanto, teniendo en cuenta que el tamao de una cabecera TCP (sin opciones, claro) es de 40 bytes, para calcular el valor He aqu la necesidad de estas lneas que vimos antes:
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
En primer lugar, el paquete llega a la conexin que hay entre nuestro router y nuestro ISP. Esta conexin, como vemos, tiene una MTU de 1480 bytes.
Como nuestro paquete mide 1500 bytes (1460 de TCP + 40 de la cabecera IP) y tenemos activado el flag DF, el paquete no podr circular ms all, por lo que nuestro router nos lo rechazar, indicndonos el motivo con un mensaje ICMP de tipo Destination Unreachable (type 3) y con cdigo Fragmentation needed and DF set (code 4).
Ya que ante este mensaje ICMP, nuestra mquina tendr que responder, sabiendo que de ahora en adelante los paquetes tendrn que ser ms pequeos para poder pasar al menos el primer tramo del camino. Pero... cmo de pequeos? Pues aqu es donde entra en juego un nuevo RFC, el RFC 1191 (http://www.ietf.org/rfc/rfc1191.txt) que, como vemos, tiene por ttulo precisamente Path MTU Discovery. Por lo que vimos en el artculo sobre ICMP, ste es el formato de un ensaje ICMP Destination Unreachable:
Pgina 64
PC PASO A PASO N 26

Lo que especifica este RFC es un pequeo aadido a este formato, que consiste en utilizar parte del campo UNUSED para incluir el dato que nosotros necesitamos: la MTU de la red a la que hemos intentado acceder. El mensaje ICMP llegar hasta nosotros, donde reajustaremos de nuevo el tamao de nuestros datagramas, esta vez a 576 bytes, y reenviaremos una vez ms el paquete.
Por tanto, con el mensaje ICMP de nuestro router, nos llegar tambin el valor al que tenemos que ajustar nuestro nuevo paquete, que sern 1480 bytes:
Esta vez si que ha llegado! El Servidor ve el campo MSS de nuestro paquete, en el cual se encuentra ya a estas alturas el resultado de nuestra bsqueda de la PMTU (PMTUD), que en este caso es de 576 bytes. Con esto l ya sabe que en la ruta que hay entre l y nosotros hay que utilizar datagramas que se ajusten en tamao a la PMTU. Como el valor de nuestra MSS es 536, el servidor sabr que sumando 40 a este nmero tiene ya la PMTU = 536 + 40 = 576 bytes. Por tanto, cuando nos responda con el paquete SYN,ACK, lo har partiendo ya de un valor de MSS = 536. Por supuesto, su flag DF estar activado, como lo tiene que estar para TODOS los paquetes que circulen en ambos sentidos. Por tanto, el mecanismo de PMTUD no se utiliza slo en el establecimiento de la conexin, si no que el tamao de los datagramas se puede ir ajustando dinmicamente para cada paquete. Hay muchos motivos por los que la PMTU puede cambiar a lo largo del tiempo. Uno de los motivos principales es que se establezca una nueva conexin que, aunque sea entre las dos mismas mquinas, utilice un tipo de servicio (TOS) diferente. Muchas veces los routers modifican la ruta entre dos mquinas en funcin del TOS, por lo que, al haber una nueva ruta, el PMTU puede cambiar. Por tanto, el sistema operativo de cada mquina tiene que guardar un registro de las PMTUs encontradas para las rutas ya conocidas. Una ruta incluir no slo una direccin IP de origen y una de destino , si no tambin un tipo de servicio (TOS). Como todos los paquetes tendrn siempre el bit DF activado, en cuanto algn paquete sea rechazado con un mensaje ICMP type 3 code 4, ya sabremos que tenemos que reducir el tamao de nuestros datagramas. Aunque no podamos ya cambiar el valor del campo MSS (ya que esta opcin es enviada SLO en el establecimiento de la conexin TCP ), s que podremos ir ajustando dinmicamente el tamao de los datagramas, igual que ir haciendo el otro extremo de la comunicacin segn se vaya encontrando con los mismos obstculos. Igual que puede haber limitaciones que aparezcan dinmicamente en el tamao de la PMTU, tambin puede ocurrir el caso contrario: que la PMTU se incremente en un momento dado. Si la ruta cambia hacia una ruta mejor, es decir, con una PMTU ms grande, estaremos desaprovechando la capacidad de nuestra ruta
Como este paquete no ha llegado a su destino, tendremos que reintentarlo, pero esta vez, por supuesto, ajustando el tamao de nuestro datagrama a 1480 bytes. Por tanto, ahora nuestro MSS ser de 1440 bytes. En el siguiente paso, nos encontramos con una red que tiene una MTU de 2048 bytes. Nuestro paquete cabe de sobra por esa red, por lo que podr atravesarla sin mayor problema:
A continuacin, el paquete tiene que llegar a la ltima red que tenemos en nuestra ruta, la cual tiene una MTU de 576 bytes. Por aqu no podr pasar, as que el router de turno nos responder con un ICMP type 3 code 4:
PC PASO A PASO N 26
Pgina 65

al seguir i n s i s t i e n d o en enviar paquetes tan pequeos como los que debamos enviar antes en funcin de la PMTU antigua. Para estos casos, el RFC 1191 recomienda que cada cierto tiempo se vuelva a intentar enviar paquetes grandes, a ver si cuela esta vez (slo colar si la ruta ha cambiado sin que nos diramos cuenta, claro). Como la probabilidad de que cambie la ruta no es muy alta, no merece la pena estar reintentando paquetes grandes cada dos por tres, ya que supondra estar constantemente reajustando el tamao de nuestros datagramas. Por eso, el RFC recomienda hacer estos reintentos aproximadamente cada 10 minutos. Si vuestras mentes son tan retorcidas como las mas, habris encontrado aqu una idea para un ataque DoS. No he visto prcticamente nada documentado acerca de este tipo de ataque. nicamente he encontrado un documento que compendia los ataques que explotan el protocolo ICMP, y comentaban como curiosidad la posibilidad de este ataque, indicando que no ha sido probado. En el prximo artculo os contar mis resultados prcticos con este experimento. Pero bueno, deja de enrollarte ya, y cuntanos en qu consiste esa tcnica DoS que te has inventado! Pues imaginad qu pasara si se nos ocurriese suplantar a uno de los routers que hay en el camino entre dos mquinas. Hacemos un simple ip-spoofing para que la IP de origen de nuestro paquete sea la del router, y enviamos a una de las dos mquinas (la que queramos DoSear) un mensaje ICMP type 3 code 4 trucado a mano, en el cual le haremos creer que la PMTU ha cambiado a un valor todo lo bajo que podamos indicarle. En teora podramos poner aqu un 0, por lo que se creera que no puede enviar ni un msero byte, y no podra continuar enviando ningn dato. En cambio, el RFC 1191 obliga a que el valor mnimo para este campo sea de 68 bytes. Ahora bien, una cosa es lo que diga el RFC y otra lo que implementen los programadores de los sistemas, as que habra que probar si realmente alguien ha hecho caso a esta recomendacin del mnimo de 68 bytes. En cualquier caso, aunque se sigan las recomendaciones del RFC 1191, podramos reducir la PMTU de una conexin hasta en 68 bytes. Por poner un ejemplo real, la PMTU que me suelo encontrar yo prcticamente siempre es de 1500 bytes, por lo que por cada 1460 bytes de datos, estamos enviando 1500 bytes (sumando los 40 bytes de cabeceras). En cambio, si reducimos a 68 bytes la PMTU, por cada 28 bytes de datos estaremos enviando 68 bytes (al sumar los 40 de las cabeceras), por lo que si bien antes un 97% de cada paquete eran datos, ahora slo un 41% de cada paquete sern datos. Conseguiramos tericamente reducir as prcticamente a la mitad el ancho de banda de una conexin enviando tan slo un nico paquete spoofeado. Como el RFC 1191 recomienda que no se revisen los incrementos en la PMTU en menos de 5 minutos, podremos mantener este ataque sin que nos suponga a nosotros ningn consumo de ancho de banda, enviando el mismo paquete, por ejemplo, una vez por minuto. Los detalles de este ataque espero poder mostrarlos en el prximo artculo, donde har un compendio de tcnicas que utilicen ipspoofing, incluida sta. An as, a pesar de este peligro potencial que se nos presenta al utilizar el PMTUD, son muchas ms las ventajas que los inconvenientes, por lo que en principio parece una buena opcin aadir estas lneas a nuestras iptables:
# PMTUD iptables -A INPUT -p tcp --fragment -j DROP iptables -A FORWARD -p tcp --fragment -j DROP
En caso de que veamos que algo no funciona como debera, entonces tendramos que revisar nuestras iptables y hacerlas menos restrictivas, tal y como fuimos viendo en los puntos anteriores, donde comentbamos tcnicas concretas para filtrar cada tipo de ataque especfico. De encontrar algn problema lo encontraramos en algn protocolo que utilizase grandes flujos de datos, y que por algn motivo requiriese fragmentacin obligatoriamente. Yo no utilizo NFS, pero por lo que he ledo es posible que por ejemplo con este protocolo s que pudiesen surgir problemas al rechazar toda la fragmentacin.
Resumiendo
Esta es la solucin que propongo yo para implementar un firewall con iptables protegido contra los ataques de fragmentacin. Por supuesto, estoy abierto a todo tipo de mejoras, dudas, crticas, o comentarios de cualquier tipo: # Bloqueo de ataques con ICMP fragmentados
iptables A INPUT p icmp --fragment j LOG --log-prefix ICMP Frag:
iptables A INPUT p icmp --fragment j DROP

iptables A FORWARD p icmp --fragment j LOG --log-prefix ICMP Frag:
iptables A FORWARD p icmp --fragment j DROP # PMTUD

iptables A INPUT p tcp --fragment j LOG --log-prefix TCP Frag:
iptables -A INPUT -p tcp --fragment -j DROP

iptables A FORWARD p tcp --fragment j LOG --log-prefix TCP Frag:
iptables -A FORWARD -p tcp --fragment -j DROP

Autor: PyC (LCo)
Pgina 66
PC PASO A PASO N 26
Proteccin con iptables en una red corporativa
La realizacin de este artculo me ha planteado un gran dilema, pero al final me he decidido a hacerlo, por ser fiel a mis planes iniciales. El problema es que, desde que empec el curso de TCP/IP (all por el nmero 17), tena una idea de la estructura que iba a seguir el curso, y de las cosas que quera contar. Dentro de ese plan entraba el dedicar un artculo a las iptables una vez que terminase de ex plicar toda la teora del protocolo IP y todos los que tiene por encima (TCP, UDP, e ICMP). Pero claro, no contaba con que ste es un tema tan interesante, que la probabilidad de que alguien se me adelantase era bastante alta. Y con lo que tampoco contaba era que, para colmo, el curso de firewalls se desarrollase de una forma tan magnfica y completa, as que desde aqu mis felicitaciones para Vic_Thor. Dando vueltas al asunto llegu a la conclusin de que, si saba aprovechar la situacin, podra ser una ventaja ms que un obstculo para mis planes. Poda aprovechar que Vic_Thor ya os dio toda la base necesaria para comprender las iptables y, por tanto, poda ir directamente al meollo del asunto sin tener que escribir tropecientas pginas explicando detalles de las iptables que, en reali dad, se salen de la temtica del curso de TCP/IP. Por tanto, si consigo mis objetivos con este artculo, habremos conseguido una combinacin perfec ta: un curso de firewalls para explicar el funcionamiento de las iptables, y un curso de TCP/IP que aprovecha esos conocimientos para aplicarlos a lo explicado en el curso. Lo que no os puedo prometer es que este artculo sea complementario al curso de diseo de firewa lls, ya que no puedo ir tachando todo lo que ya ha sido contado para contar slo cosas nuevas, pues el artculo quedara totalmente inconexo y perdera toda su utilidad. As que podis tomarlo de dos formas: para los que no seguisteis el curso de firewalls, ser esta vuestra segunda oportunidad para conocer este apasionante tema en profundidad, y para los que s lo seguisteis, tenis aqu un nuevo punto de vista sobre el mismo tema. Este nuevo punto de vista consistir en ir repasando todo lo explicado a lo largo del curso de TCP/IP, y tambin algunas cosas de la veterana serie RAW, y aplicando lo que vimos entonces al diseo de un firewall completo, de arriba a abajo, que implemente proteccin para prcticamente todos los ataques que he ido explicando durante casi 2 aos (ya he perdido la cuenta de cuanto tiempo llevo en la revista...).
30/68

Ya que de esto se encarg el curso de firewalls, no os voy a ir presentando una serie de escenarios, empezando por el ms sencillo para ir complicando cada vez ms la cosa. Directamente os voy a plantear un escenario complicado y terminamos antes, jeje. Os voy a plantear un escenario muy tpico en cualquier corporacin, pero no tan tpico en un ambiente domstico. An as, el montaje que tengo yo en mi propia casa es bas tante parecido al que voy a plantear (aunque no exactamen te igual, ya que tampoco me gusta revelar los detalles inter nos de mi red a todo el planeta), por lo que es perfectamente viable para un usuario normal que, ms que dinero (ya que de eso no me sobra precisamente), lo que tenga sean las su ficientes ganas. Hoy da es muy habitual tener 2 pcs: el pc viejo que utilizaste hasta hace x aos, y el pc relativamente nuevo que es el que utilizas normalmente. Para hacerse con ms ordenadores puedes optar por varias opciones. Puedes ir como un buitre detrs de tus amigos, o familiares, en espera de que alguien se deshaga de algn PC viejo, o de que la empresa en la que trabaje alguien renueve los equipos informticos (ste es el gran chollo). Otra opcin es comprar algn PC cutre de segunda mano por cuatro duros. Y por ltimo, la opcin ms cutre de todas, pe ro tambin quiz la ms divertida, es dedicarte a buscar en los contenedores, jeje. No se como ser en otras ciudades, u otros barrios, as que lo mismo es que yo tengo mucha suerte por vivir donde vivo. Pero el caso es que por donde yo me muevo (cierto barrio de Madrid) es bastante habitual encontrar restos de PCs aban donados por las calles, llorando y diciendo: yo nunca lo ha ra. Cuando digo habitualmente podra decir que ms o menos la media es de una vez al mes. Hay meses que increblemen te me puedo encontrar un hallazgo cada fin de semana (los fines de semana suele ser ms habitual, no se bien por qu), y luego pasar varios meses sin encontrar absolutamente na da. Si habis encontrado alguno de estos hallazgos y habis sido lo suficientemente cutres (como yo) como para pararos a mi rar si hay algo aprovechable, probablemente la mayora de las veces habris comprobado que los restos han sido muti lados, llevndose cualquier parte interesante (CPU, memoria, tarjetas que cuesten ms de 20 euros, etc). Pero, an as, muchas veces se encuentran autnticos yaci mientos que son como minas que requieren hasta maquina ria para ser explotadas . Nunca olvidar aquella ocasin en la que pas por enfrente de una oficina del INEM y descubr un contenedor entero lleno de material informtico. Rpidamente, llamada al mvil de m hermano para que vi niese con el coche. Pero antes de que llegase mi hermano apareci un to con una furgoneta y empez a cargar todo lo rpido que poda, mientras yo iba sacando como poda cualquier cosa que en contrase aprovechable hasta que llegasen los refuerzos. De aquella oportunidad nica, aparte de varias broncas de mi madre y la novia de mi hermano, sali material para abastecer a varias personas (que si no se quin quiere un teclado, que si este monitor cutre para no se cuantos...). Resumiendo, que si realmente te lo curras, a pesar de que no tengas un duro, tu principal limitacin a la hora de montar una red de estas caractersticas ya no ser la falta de equi pos, si no, como en mi caso, la falta de espacio y (tambin hay que tenerlo en cuenta) el incremento en la cuenta de Iberdrola que supondr tener todas esas mquinas encendi das 24 horas (eso s, por lo menos lo que gastas en electrici dad luego te lo puedes ahorrar en calefaccin). Pero bueno, ya estoy otra vez contando mi vida. Vamos a ver en primer lugar con una imagen el escenario que estamos planteando:
Como vemos, en el escenario aparecen 4 redes: La primera red es, por supuesto, Internet. Esta red cons ta de una nubecita llena de millones de mquinas, de las cuales una de ellas es nuestro router ADSL , llamado Zeus. La segunda red est formada por slo dos mquinas: Zeus, y nuestro firewall, llamado Cerbero. Como segura mente sabris, Cerbero era el perro infernal que guardaba las puertas del Hades, el reino de los muertos de los anti guos griegos. Al igual que el can Cerbero, nuestro Cerbero tiene 3 ca bezas, cada una de ellas conectada a una red, y se encar ga tambin de vigilar la entrada de cada reino, para que los vivos no se junten con los muertos, ni los muertos con los vivos.
31/68

A esta red que une a Zeus y Cerbero la llamaremos Olimpo. La tercera red est formada de momento por slo dos m quinas: Cerbero, y un servidor web al que hemos llama do Persefone . Esta red es, por supuesto, una DMZ , ya que aqu es donde se encuentran nuestros servidores. Cualquier otro servidor que quisiramos poner (de correo, de dns, etc) tendramos que ubicarlo aqu. A esta red, la DMZ, la llamaremos Hades. La cuarta y ltima red es nuestra red interna, y est for mada de momento por 3 mquinas: Cerbero, y dos PCs llamados Eolo y Poseidon. A esta red, la red interna, la llamaremos Gaia. Y a qu viene esta tontera de poner nombres a las m quinas y a las redes? El que pregunte esto probablemente nunca habr tenido que manejar redes con ms de dos mquinas. Cuando diseas una red lo tienes que hacer siempre en previsin de que sta pueda crecer y cambiar. Con respecto al primer punto (el crecimiento de la red), sera absurdo llamar a las mquinas: SERVIDOR, FIREWALL, ROUTER, y PC. En cuanto aadisemos otro servidor, otro router, o cualquier otro elemento a la red, ya empezara a haber ambigedades que terminaran con tribuyendo al caos que ya es de por s el mantener una red corporativa. Y con respecto al segundo punto (los cambios en la red) os puedo hablar de mi propia experiencia en una empresa en la que trabaj como administrador de sistemas. En principio se opt (yo no trabajaba all por aquel entonces) por llamar a cada PC con el nombre del empleado que lo utilizaba. Al cabo de unos aos, casi la mitad de la plantilla haba cambiado, y tenamos a un hombre barbudo traba jando con un PC llamado Rosita, y eso al final tambin ter minaba causando cierta confusin, como imaginaris. Y vamos, si tu duda es ya que cul es la necesidad de po ner nombres, sean cuales sean, entonces imagnate lo que puede ser realizar cualquier configuracin o depuracin de la red con varias mquinas llamadas todas con nmeros como 192.168.34.15. Es exactamente lo mismo que ocurre con los DNS que utilizamos en Internet, de cuya utilidad no creo que nadie dude. Resumiendo, mi consejo es que utilicis nombres que sean hasta cierto punto significativos, pero no dependientes del contexto, pues ste podra cambiar. El ejemplo que planteo aqu de los dioses griegos me parece una opcin muy bue na, y como otro ejemplo tenis el que uso yo actualmente, que son nombres de estrellas para las mquinas, y de constelaciones para las redes. Tenis incluso un RFC dedicado a la eleccin de nombres para redes. Este es el RFC 1178, y lo tenis traducido al castellano en http://www.rfc-es.org/getfile.php?rfc=1178. Como podemos deducir por la imagen, la red Olimpo est definida por las direcciones 192.168.1.0/24 . La red Hades por las direcciones 192.168.2.0/24, y la red Gaia por las direcciones 192.168.3.0/24. Por supuesto, la primera red, que es Internet, tiene sus propias direcciones, entre las cuales se encuentra la 80.15.13.100, que es la direccin IP de Zeus de cara a Internet (Zeus tendr otra IP, que ser la que tenga en la red Olimpo). Para quien no le haya quedado claro, la mscara de red para las 3 redes, Olimpo, Hades, y Gaia, es 255.255.255.0. Tambin vemos en la imagen que Cerbero tiene 3 tarjetas de red: eth0, eth1, y eth2. La tarjeta eth0 es la que co necta a Cerbero con la red Hades, la tarjeta eth1 conecta a Cerbero con la red Olimpo, y la tarjeta eth2 conecta a Cerbero con la red Gaia. Nos vamos a centrar nicamente en la configuracin de la m q u i n a m s i m p o r t a n t e d e l e s c e n a r i o, q u e s e r a Cerbero. A lo largo del artculo iremos recordando lo que he ido explicando en la serie RAW y en el curso de TCP/IP, y aplicando estos conocimientos a la configuracin de Cerbero. Os muestro aqu la configuracin completa de IPTABLES de Cerbero, e iremos recorriendo esta configuracin a lo largo de todo el artculo: #! /bin/sh ################################## # IPTABLES CERBERO # ~~~~~~~~~~~~~~~~ # Curso de TCP/IP. # Revista PC PASO A PASO. # # PyC (LCo). Diciembre 2004. # # Este script de iptables ha sido # realizado exclusivamente para # la revista PC PASO A PASO. # Eres libre de utilizarlo o # modificarlo a tu antojo. :-) ################################## ########################### # DEFINICION DE VARIABLES ########################### ServidorDNS=193.15.25.1 #################### # DIOSES (MAQUINAS) Zeus_Internet=80.15.13.100 # OLIMPO Zeus=192.168.1.2 Cerbero_Olimpo=192.168.1.1
32/68

# HADES Persefone=192.168.2.2 Cerbero_Hades=192.168.2.1 # GAIA Eolo=192.168.3.2 Poseidon=192.168.3.3 Cerbero_Gaia=192.168.3.1 ################# # REINOS (REDES) hades=eth0 olimpo=eth1 gaia=eth2 #################################### case "$1" in restart) $0 stop $1 start ;; stop) iptables -F iptables -X iptables -Z iptables -t nat -F ;; status) iptables --list ;; start) #################################### # BORRAMOS LA CONFIGURACION ACTUAL DE IPTABLES #################################### iptables -F iptables -X iptables -Z iptables -t nat -F ######################## # CONFIGURACION GENERAL ######################## # incluimos modulo para FTP modprobe ip_conntrack_ftp # Habilitamos el forward de paquetes echo 1 > /proc/sys/net/ipv4/ip_forward # Habilitamos proteccion anti-spoofing for f in /proc/sys/net/ipv4/conf/*/rp_filter # Creamos reglas de bloqueo iptables --insert FORWARD 1 -j DROP iptables --insert INPUT 1 -j DROP iptables --insert OUTPUT 1 -j DROP # Configuramos la politica por defecto iptables --policy FORWARD DROP iptables --policy INPUT DROP iptables --policy OUTPUT DROP ############################ # HABILITAMOS TRAFICO LOCAL ############################ iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #################################### # --- REGLAS --# #################################### ############ # TABLA NAT ############ # SERVIDOR FTP EN PERSEFONE iptables -t nat -A PREROUTING \ -p tcp --dport ftp -i $olimpo -j DNAT --to $Persefone # SERVIDOR WWW EN PERSEFONE iptables -t nat -A PREROUTING \ -p tcp --dport www -i $olimpo -j DNAT --to $Persefone # DCC PARA EOLO iptables -t nat -A PREROUTING \ -p tcp --dport 5000:5005 -i $olimpo -j DNAT --to $Eolo # DCC PARA POSEIDON iptables -t nat -A PREROUTING \ -p tcp --dport 5010:5015 -i $olimpo -j DNAT --to $Poseidon # EMULE PARA POSEIDON do echo 1 > $f done # Habilitamos proteccion anti-smurf echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Habilitamos proteccion contra source route spoofing echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route # Registramos marcianos para el proyecto SETI echo 1 > /proc/sys/net/ipv4/conf/all/log_martians #################################### # BLOQUEAMOS TODO MIENTRAS ESTAMOS CONFIGURANDO ####################################
33/68

iptables -t nat -A PREROUTING \ -p tcp --dport 4662 -i $olimpo -j DNAT --to $Poseidon # ENMASCARAMIENTO HACIA EL EXTERIOR # ENMASCARAMIENTO PARA LA RED HADES iptables -t nat -A POSTROUTING \ -s 192.168.2.1/24 -o $olimpo -j SNAT --to $Cerbero_Olimpo # ENMASCARAMIENTO PARA LA RED GAIA iptables -t nat -A POSTROUTING \ -s 192.168.3.1/24 -o $olimpo -j SNAT --to $Cerbero_Olimpo ######################## # REGLAS DE USO GENERAL ######################## ############################# # CADENA DE REGLAS PARA ICMP iptables --new-chain reglas_icmp # PING iptables -A reglas_icmp -p icmp \ --icmp-type echo-reply -j ACCEPT # PONG iptables -A reglas_icmp -p icmp \ --icmp-type echo-request -j ACCEPT # PERMITIMOS PMTUD (DESTINATION UNREACHABLE) iptables -A reglas_icmp -p icmp \ --icmp-type destination-unreachable -j ACCEPT # PERMITIMOS TRACEROUTE (TIME EXCEEDED) iptables -A reglas_icmp -p icmp \ --icmp-type time-exceeded -j ACCEPT # LOGEAMOS Y RECHAZAMOS CUALQUIER OTRO ICMP iptables -A reglas_icmp -p icmp \ --j LOG --log-prefix "ICMP: " iptables -A reglas_icmp -p icmp -j DROP ################################## # CADENA PARA ESTADOS DE CONEXION iptables --new-chain keep_state # MANTENEMOS CONEXIONES ESTABLECIDAS iptables -A keep_state -m state \ --state RELATED,ESTABLISHED -j ACCEPT # RECHAZAMOS CONEXIONES INVALIDAS iptables -A keep_state -m state \ --state INVALID -j DROP ################################# # CADENA PARA ANALIZAR FLAGS TCP iptables --new-chain flags_tcp # RECHAZAMOS Y LOGEAMOS ESCANEO NMAP-XMAS # SERVICIOS QUE DA PERSEFONE A LA RED GAIA iptables -A gaia_hades -d $Persefone -p tcp --dport www -j ACCEPT iptables -A gaia_hades -d $Persefone -p tcp --dport ftp -j ACCEPT # SERVICIOS QUE DA PERSEFONE SOLO A EOLO iptables -A gaia_hades -d $Persefone \ -p tcp --dport ssh -s $Eolo -j ACCEPT # RECHAZAMOS Y LOGEAMOS CUALQUIER OTRO TRAFICO iptables -A gaia_hades -j LOG --log-prefix "GAIA->HADES: " iptables -A gaia_hades -j DROP ################################### # RECHAZAMOS Y LOGEAMOS ESCANEO SYN/RST iptables -A flags_tcp -p tcp --tcp-flags SYN,RST SYN,RST \ -m limit --limit 5/minute -j LOG --log-prefix "SYN/RST SCAN: " iptables -A flags_tcp -p tcp --tcp-flags SYN,RST SYN,RST -j DROP # RECHAZAMOS Y LOGEAMOS ESCANEO SYN/FIN iptables -A flags_tcp -p tcp --tcp-flags SYN,FIN SYN,FIN \ -m limit --limit 5/minute -j LOG --log-prefix "SYN/FIN SCAN: " iptables -A flags_tcp -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP # RECHAZAMOS Y LOGEAMOS ESCANEO PSH/FIN iptables -A flags_tcp -p tcp --tcp-flags PSH,FIN PSH,FIN \ -m limit --limit 5/minute -j LOG --log-prefix "PSH/FIN SCAN: " iptables -A flags_tcp -p tcp --tcp-flags PSH,FIN PSH,FIN -j DROP # RECHAZAMOS Y LOGEAMOS EL NULL SCAN iptables -A flags_tcp -p tcp --tcp-flags ALL NONE \ -m limit --limit 5/minute -j LOG --log-prefix "NULL SCAN: " iptables -A flags_tcp -p tcp --tcp-flags ALL NONE -j DROP ################################## # ESTAS CADENAS SE APLICAN A TODO iptables -A FORWARD -p tcp -j keep_state iptables -A INPUT -p tcp -j keep_state iptables -A OUTPUT -p tcp -j keep_state iptables -A FORWARD -p tcp -j flags_tcp iptables -A INPUT -p tcp -j flags_tcp iptables -A OUTPUT -p tcp -j flags_tcp iptables -A FORWARD -p icmp -j reglas_icmp iptables -A INPUT -p icmp -j reglas_icmp iptables -A OUTPUT -p icmp -j reglas_icmp ################################### # CADENA DE REGLAS DE GAIA A HADES ################################### # INTERNA -> DMZ iptables --new-chain gaia_hades iptables -A FORWARD -i $gaia -o $hades -j gaia_hades iptables -A flags_tcp -p tcp --tcp-flags ALL FIN,URG,PSH \ -m limit --limit 5/minute -j LOG --log-prefix "NMAP-XMAS SCAN: " iptables -A flags_tcp -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
34/68

# CADENA DE REGLAS DE HADES A GAIA ################################### # DMZ -> INTERNA iptables --new-chain hades_gaia iptables -A FORWARD -i $hades -o $gaia -j hades_gaia # RECHAZAMOS Y LOGEAMOS TODO! iptables -A hades_gaia -j LOG --log-prefix "HADES->GAIA: " iptables -A hades_gaia -j DROP ##################################### # CADENA DE REGLAS DE HADES A OLIMPO ##################################### # DMZ -> INTERNET iptables --new-chain hades_olimpo iptables -A FORWARD -i $hades -o $olimpo -j hades_olimpo # PERMITIMOS TODO EL TRAFICO HACIA EL EXTERIOR iptables -A hades_olimpo -j ACCEPT ##################################### # CADENA DE REGLAS DE OLIMPO A HADES ##################################### # INTERNET -> DMZ iptables --new-chain olimpo_hades iptables -A FORWARD -i $olimpo -o $hades -j olimpo_hades # PERMITIMOS DNS iptables -A olimpo_hades -s $ServidorDNS \ -p udp --sport domain -j ACCEPT # SERVICIOS QUE OFRECE HADES A INTERNET iptables -A olimpo_hades -p tcp --dport www -j ACCEPT iptables -A olimpo_hades -p tcp --dport ftp -j ACCEPT # RECHAZAMOS Y LOGEAMOS EL RESTO DEL TRAFICO iptables -A olimpo_hades -j LOG --log-prefix "OLIMPO->HADES: " iptables -A olimpo_hades -j DROP #################################### # CADENA DE REGLAS DE GAIA A OLIMPO #################################### # INTERNA -> INTERNET iptables --new-chain gaia_olimpo iptables -A FORWARD -i $gaia -o $olimpo -j gaia_olimpo # ACEPTAMOS TODO EL TRAFICO HACIA INTERNET iptables -A gaia_olimpo -j ACCEPT #################################### # CADENA DE REGLAS DE OLIMPO A GAIA #################################### # INTERNET -> INTERNA iptables --new-chain olimpo_gaia iptables -A FORWARD -i $olimpo -o $gaia -j olimpo_gaia # PERMITIMOS DNS iptables -A olimpo_gaia -s $ServidorDNS \ -p udp --sport domain -j ACCEPT # PERMITIMOS DCC A EOLO iptables -A olimpo_gaia -d $Eolo \ -p tcp --dport 5000:5005 -j ACCEPT # PERMITIMOS DCC A POSEIDON iptables -A olimpo_gaia -d $Poseidon \ -p tcp --dport 5010:5015 -j ACCEPT # PERMITIMOS EMULE A POSEIDON iptables -A olimpo_gaia -d $Poseidon \ -p tcp --dport 4662 -j ACCEPT # RECHAZAMOS Y LOGEAMOS TODO LO DEMAS iptables -A olimpo_gaia -j LOG --log-prefix "OLIMPO->GAIA: " iptables -A olimpo_gaia -j DROP ######################################## # REGLAS PARA EL PROPIO CERBERO (INPUT) ######################################## iptables --new-chain olimpo_cerbero iptables --new-chain hades_cerbero iptables --new-chain gaia_cerbero iptables -A INPUT -i $olimpo -j olimpo_cerbero iptables -A INPUT -i $hades -j hades_cerbero iptables -A INPUT -i $gaia -j gaia_cerbero ################# # OLIMPO_CERBERO ####################### # INTERNET -> FIREWALL # PERMITIMOS DNS iptables -A olimpo_cerbero -s $ServidorDNS \ -p udp --sport domain -j ACCEPT # RECHAZAMOS Y LOGEAMOS EL RESTO DEL TRAFICO iptables -A olimpo_cerbero -j LOG --log-prefix "OLIMPO->CERBERO: " iptables -A olimpo_cerbero -j DROP ################ # HADES_CERBERO ################## # DMZ -> FIREWALL # RECHAZAMOS Y LOGEAMOS TODO! iptables -A hades_cerbero -j LOG --log-prefix "HADES->CERBERO: " iptables -A hades_cerbero -j DROP ############### # GAIA_CERBERO ###################### # INTERNA -> FIREWALL
35/68

# RECHAZAMOS Y LOGEAMOS TODO! iptables -A gaia_cerbero -j LOG --log-prefix "GAIA->CERBERO: " iptables -A gaia_cerbero -j DROP ######################################### # REGLAS PARA EL PROPIO CERBERO (OUTPUT) ######################################### # PERMITIMOS LA SALIDA DE CONSULTAS DNS iptables -A OUTPUT -o $olimpo -d $ServidorDNS \ -p udp --dport domain -j ACCEPT # RECHAZAMOS Y LOGEAMOS EL RESTO DEL TRAFICO iptables -A OUTPUT -j LOG --log-prefix "OUTPUT: " iptables -A OUTPUT -j DROP ######################### # NOS PONEMOS EN MARCHA! ######################### iptables -D INPUT 1 iptables -D FORWARD 1 iptables -D OUTPUT 1 ;; *) echo "Uso: $0 {start|stop|restart|status}" exit 1 ;; esac A la vista de estas iptables, podemos deducir que los ser vicios de cada mquina sern: Persefone: Ofrece servidor www y ftp tanto a Internet como a la red Gaia. Ofrece servidor ssh para administracin remota slo para Eolo. Tiene acceso total a Internet. Solo tiene limitado el acceso desde Internet. Responde a un conjunto mnimo de mensajes ICMP. Cerbero: Su nica comunicacin con cualquier red son las consultas al servidor DNS, y respuesta a un conjunto mnimo de mensajes ICMP. Eolo: Tiene acceso total hacia Internet, pero muy restringi do desde Internet. Tiene acceso a Persefone como cliente ssh, para ad ministrar remotamente el servidor web. Tiene abiertos 6 puertos para DCC, ya que el usuario de Eolo quiere utilizar IRC. Responde a un conjunto mnimo de mensajes ICMP. 36/68 Ahora que ya hemos visto a grandes rasgos el escenario, vamos a ir analizando paso a paso todas las lneas de es tas iptables. Poseidon: Tiene acceso total hacia Internet, pero muy restringi do desde Internet. El usuario de Poseidon utiliza emule. Tiene abiertos 6 puertos para DCC, ya que el usuario de Poseidon quiere tambin utilizar IRC. Responde a un conjunto mnimo de mensajes ICMP. Zeus: Es un router ADSL que hace NAT a todos los puertos que utilizarn todas las redes, para que los gestione Cerbero. Por tanto, la tabla NAT de Zeus ser parecida a esta:
En esta primera seccin del archivo de configuracin de ip tables vemos una serie de definiciones que nos sern tiles para todo el script. Podemos comprobar que algunos de los valores definidos no son usados luego en el script. An as, conviene definir los tambin, pues definimos as todo el contexto, y nos permitir hacer cualquier modificacin o ampliacin en el futuro sin tener que preocuparnos de si tenamos definido o no tal elemento que hasta el momento no habamos uti lizado.

La primera lnea: ServidorDNS=193.15.25.1 Indica la direccin IP del servidor DNS que utilizamos (pro bablemente el que nos haya dado nuestro ISP). Normalmente, esta direccin IP, as como probablemente tambin las del resto de mquinas a las que nos referimos en el script, se encontrarn ya en la configuracin del sis tema. Concretamente, los servidores DNS los tendremos en /etc/resolv.conf, y el resto de mquinas en /etc/hosts. Depende de la decisin de cada administrador el incluir aqu o no todas estas variables. Si no las incluimos el script puede ser menos legible, al no tener en el propio script toda la informacin necesaria para ser interpretado. Como contrapartida, si las incluimos en el script tenemos el problema potencial de que en algn momento pueda ha ber incoherencia entre la informacin almacenada en /etc/hosts y el script de iptables. Yo personalmente prefiero incluir las definiciones en el pro pio script de iptables, a pesar de que estn ya definidas todas las mquinas en el sistema. Para los que prefiris no incluir las definiciones, simple mente tenis que eliminar el smbolo $ que precede a los nombres de mquinas en todo el script. Por ejemplo, la l nea: iptables -A olimpo_hades -s $ServidorDNS \ -p udp --sport domain -j ACCEPT Quedara: iptables -A olimpo_hades -s ServidorDNS \ -p udp --sport domain -j ACCEPT Como vemos, tambin incluyo definiciones para las 3 tar jetas de red: eth0, eth1, y eth2. Esto es fundamental, ya que la mejor forma de asegurarnos de por dnde estn cir culando los paquetes es utilizar como referencia el propio dispositivo fsico, es decir, la tarjeta de red. Si utilizsemos direcciones IP como referencia para identificar cada red, podramos ser engaados por algn tipo de spoofing (aun que tengamos proteccin contra IP-spoofing, como ya ve remos). status) ** acciones para la opcin status ** ;; start) ** acciones para la opcin start ** ;; *) ** acciones para cualquier otro valor ** ;; esac Como vemos, las acciones para cada opcin terminan con ;;, y toda la sentencia case termina con esac. Este archivo de configuracin de iptables no es ms que un script para la shell de Linux y, por tanto, puede utilizar toda la potencia del lenguaje de programacin de la shell. Aqu nosotros estamos implementando una funcin muy tpica en Linux, que consiste en poder pasar un parmetro a un comando a la hora de lanzarlo, para que acte de una forma u otra segn el parmetro. Veremos ahora una por una todas las opciones que hemos incluido en el script. RESTART) Como ya he dicho, un restart es tan simple como hacer un stop, y a continuacin un start. stop) ** acciones para la opcin stop ** ;; Las opciones que damos a nuestro comando de iptables son (suponiendo que el script se llama iptpyc): ./iptpyc stop : Borra toda la configuracin de ipta bles. ./iptpyc start : Configura las iptables con todas las reglas que hemos incluido en el script. ./iptpyc restart : Hace un stop y un start, reinician do as toda la configuracin de iptables. ./iptpyc status : Muestra la configuracin actual de iptables. Para implementar estos comandos hacemos un CASE sobre el parametro $1. En un script de shell el parmetro $0 es siempre el propio nombre del parmetro (en este caso ip tpyc), y el parmetro $1 es el primer parmetro que hay justo detrs del nombre del script. Un CASE es una sentencia condicional que, a la diferencia de un IF THEN ELSE, que slo permite seleccionar una opcin u otra segn dos posibles condiciones sobre la va riable de entrada (SI cumple, y NO cumple), el CASE nos permite seleccionar tantas condiciones como queramos. En este caso nuestro CASE considera las condiciones de que $1 sea stop, start, restart, status, o cualquier otra cosa que no sea ninguna de las anteriores. Es decir, tenemos 5 condiciones sobre la variable $1, por lo que la estructura bsica de nuestro CASE es la siguiente: case $1 in restart) ** acciones para la opcin restart ** ;;
37/68

STOP) Esta opcin vaca toda la configuracin de iptables, tanto si fue previamente ejecutado nuestro script (con start), co mo si no. STATUS) Tan sencillo como llamar a la opcin --list del comando ip tables. *) Ahora os pido que bajis hasta el final del script para ver esta opcin, ya que tiene que ser incluida despus de to das las dems. Como vemos, si se introduce cualquier opcin que no sea una de las que reconoce nuestro script, mostraremos el t pico mensaje que indica al usuario las opciones disponi bles. START) Todo el resto del artculo est dedicado a la opcin de start, as que aqu viene la chicha. En realidad, el sitio adecuado para incluir cualquier mdulo sera el archivo /etc/modules , pero nosotros lo hemos incluido en el script de iptables, para que tengamos todo junto, y as tener una visin ms global. Por cierto, que ya que hablo de visin global, no estara de ms que os mostrase aqu tambin el resto de configuracin bsica de Cerbero: hostname Cerbero ifconfig eth0 192.168.2.1 netmask 255.255.255.0 ifconfig eth1 192.168.1.1 netmask 255.255.255.0 ifconfig eth2 192.168.3.1 netmask 255.255.255.0 route add default gw Zeus Con los comandos ifconfig estamos configurando las 3 tarjetas de red, asignando una IP y una mscara de red a cada una. Con el comando route estamos definiendo la ru ta por defecto hacia Zeus (lo que Windows llama puerta de enlace predeterminada). Pero, volviendo a nuestro script, vamos a ver ms sobre el mdulo que estamos cargando en Cerbero. Aqu es donde empezamos a echar la vista atrs, recor dando aquellos buenos tiempos de la serie RAW, y nos encontramos con los dos artculos que dediqu al protocolo FTP. Este es un buen momento para repasar esos articulillos y recordar el funcionamiento del FTP pasivo, y el no pasivo. Volved aqu cuando hayis hecho el repaso. Como ya sabemos (si hemos repasado la leccin), cada vez que un servidor FTP recibe un comando PASV ha de abrir dinmicamente un puerto para que el cliente se co necte a un nuevo canal de datos. Por otra parte, cada vez que un cliente lanza un comando PORT, ha de abrir din micamente un puerto para que el servidor se conecte y es tablezca un nuevo canal de datos. Si estamos utilizando iptables, estos mecanismos no po dran funcionar as por las buenas, como es lgico. Para que puedan funcionar tenemos que incluir el mdulo ip_conntrack_ftp, que se encarga de analizar el campo DATOS de los paquetes TCP/IP en busca de comandos PORT y PASV. Cuando encuentra uno de estos comandos, los interpreta, y abre dinmicamente los puertos que haya que abrir. Cuando no estamos seguros de lo que hace un mdulo de Linux siempre tenemos la posibilidad de analizar el cdigo fuente, cosa que de ninguna manera podemos hacer con Windows. Por eso Windows, mientras no libere su cdigo, seguir siendo un sistema oscuro a cuyos caprichos esta rn sujetos todos sus usuarios. En Linux siempre tienes la posibilidad de comprobar t mismo el funcionamiento de las cosas, o bien de que otro con ms conocimientos que t lo haga, y publique sus conclusiones en cualquier web o publicacin a la que tenga acceso todo el mundo.
Empezamos haciendo lo mismo que hace el comando stop, para empezar con una configuracin limpia sobre la que ir trabajando.
En este punto se encuentran algunas de las caractersticas ms interesantes de nuestro script. Vamos a ir viendo una a una cada una de las lneas de esta parte del script. # incluimos modulo para FTP modprobe ip_conntrack_ftp Linux pretende ser un sistema operativo con cierta modu laridad, lo cual se consigue gracias a ciertos comandos co mo modprobe (man modprobe). Existen una gran cantidad de mdulos que podemos cargar dinmicamente, y estos suelen encontrarse en /lib/modules . Si queremos ver un listado completo de los mdulos que tenemos disponibles para ser cargados, podemos hacer: modprobe -l Desde una shell de root. Para ver los mdulos que tenemos cargados en estos mo mentos: lsmod Tambin slo para root.
38/68

Si al instalar nuestra distribucin de Linux escogimos ins talar tambin los paquetes de sources (cdigo fuente), tendremos el cdigo del mdulo ip_conntrack_ftp.c en el directorio /usr/src/linux/net/ipv4/netfilter/ . Por si no instalasteis los fuentes, podis ver igualmente el cdigo f u e n t e d e e s t e m d u l o e n http://joshua.raleigh.nc.us/docs/linux2.4.10_html/577570.html. Podemos ver en el fuente cmo analiza los paquetes en busca de PORT o 227, que correspondera respectiva mente a los comandos PORT y PASV (ya que 227 es el cdigo de respuesta de PASV ). Tambin analiza los co mandos EPRT ( E xtender P o RT ) y EPSV ( E xtended PaSsiVe), que no vimos en la serie RAW. Los comandos EPRT y EPSV fueron propuestos en el RFC 2428, para facilitar la futura sustitucin del actual proto colo ipv4 por el nuevo ipv6 (del que ya hablaremos a lo largo del curso). Las direcciones IP de ipv6 son diferentes a las de ipv4, por lo que los actuales comandos PORT y PASV no podran ser directamente portados a ipv6, al utilizar las clsicas direc ciones de 32 bits. Los comandos EPRT y EPSV tienen la misma funcionalidad que sus predecesores, pero aaden adems la posibilidad de utilizar direcciones ipv6. Analicemos, por ejemplo, el comando EPRT. Para conse guir lo que he mencionado, este comando tiene 3 parme tros: EPRT |protocolo|direccinIP|puerto| El primer parmetro, protocolo, puede valer 1 2. En el caso de que sea 1, indicamos que se trata del protocolo ipv4 y, por tanto, igual al clsico PORT que ya conoce mos. Si es un 2, se tratar del protocolo ipv6 y, por tanto, el siguiente parmetro (direccinIP) vendr en el formato de direcciones IP v6. El segundo parmetro, direccinIP, en el caso de que el anterior parmetro sea 1 (ipv4) ser simplemente una direccin IP de las de toda la vida, pero con la diferencia (con respecto al comando PORT) de que los dgitos no ven drn separados por comas, si no por puntos. El tercer y ltimo parmetro, puerto, tendr tambin una diferencia con respecto al comando PORT, y es que no ha br que hacer clculos para hallar el nmero de puerto, si no que ste vendr especificado tal cual. Es decir, aqu tenemos un ejemplo de comando EPRT que hara la misma funcin que un comando PORT 80,15,13,100,10,15: EPRT |1|80.15.13.100|2575| Ya que, como sabemos, el puerto 10,15 del comando PORT se traducira en: 10*256 + 15 = 2575. Al soportar ambos comandos tambin el protocolo ipv4, la idea es que vayan siendo implementados por todos los ser vidores y clientes FTP, para ir preparndonos para un futu ro que est siendo ya implantado. # Habilitamos el forward de paquetes echo 1 > /proc/sys/net/ipv4/ip_forward Las principales responsabilidades de Cerbero sern dos: servir de cortafuegos para todas las redes, y encaminar y reenviar todos los paquetes de una red a otra. Para que pueda hacer esta segunda funcin, tenemos que activar el forward de paquetes, lo cual hacemos escribiendo un sim ple 1 en el archivo /proc/sys/net/ipv4/ip_forward. Probad desde una shell de root a escribir estos dos coman dos: echo 1 > /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/ip_forward Como veis, lo nico que se hace es escribir un 1 en el ar chivo ip_forward , como si fuese un simple archivo de texto. # Habilitamos proteccion anti-spoofing for f in /proc/sys/net/ipv4/conf/*/rp_filter do echo 1 > $f done Todava nos falta hablar ms sobre ip-spoofing en este curso, pero de momento ya sabemos bastante bien en qu consiste esta tcnica tan verstil, que se suele usar en combinacin con gran cantidad de ataques. Este bucle recorre varios directorios, cada uno correspon diente a un dispositivo de red (eth0, eth1, eth2, y lo, bsi camente). En cada uno de estos directorios tendremos una serie de opciones de configuracin para el correspondiente dispositivo (es decir, una configuracin independiente para cada tarjeta de red). En este caso, nosotros activaremos una opcin que tenemos en el archivo rp_filter. Si escri bimos un 1 en este archivo, impedimos que el dispositivo acepte direcciones IP que no pertenezcan a su red. Esta es una sencilla proteccin contra ip-spoofing, aunque no nos protege contra otras tcnicas, como el source-route spoofing. Cuando hablemos ms en profundidad sobre ip-spoofing mostraremos esto con ms detalle. # Habilitamos proteccion anti-smurf echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts Esto ya lo vimos en el artculo sobre fragmentacin. Escribiendo un 1 en este archivo estamos anulando la res 39/68

puesta a pings a la direccin broadcast, lo cual impide que nos convirtamos en un amplificador para un ataque smurf. # Habilitamos proteccion contra source route spoofing echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route Esto lo veremos ms adelante en el curso, cuando hable mos de la tcnica de source-route spoofing. De momen to nos quedamos con la idea de que esta lnea nos permite desactivar la respuesta a datagramas que lleven activadas opciones de enrutamiento explcito, es decir, las opciones LSRR y SSRR. Esto no significa que vayamos a rechazar esos datagra mas, si no simplemente que no responderemos a lo que nos pide esa opcin, es decir, que no seguiremos la ruta especificada en nuestra respuesta. # Registramos marcianos para el proyecto SETI echo 1 > /proc/sys/net/ipv4/conf/all/log_martians Bueno... en realidad el proyecto SETI no tiene mucho que ver con todo esto, pero no he podido resistirme a poner alguna chorrada en este artculo (es que si no, no me que do a gusto). Esta opcin lo que hace es logear cualquier paquete que tenga como direccin IP de origen o destino una direccin imposible . Esto tambin incluye las direcciones IP spo ofeadas, ya que una direccin que no pertenece a la red en la que estamos es en realidad una direccin imposible. Con esto permitimos que el propio Cerbero se haga a si mismo PING, o lo que quiera. Todo el trfico entre Cerbero y el propio Cerbero est permitido. Ahora bien, recomien do que en una mquina como Cerbero, dedicada exclusiva mente a un firewall, no metamos ninguna otra aplicacin, ni mucho menos ninguna clase de servidor. Por tanto, el trfico entre Cerbero y s mismo normalmente ser muy limitado o nulo. An as, no tiene ningn peligro permitir el trfico local, por lo que podemos hacerlo sin miedo (es pero que Murphy no me est leyendo). Como vemos, para identificar el trfico local no hemos uti lizado la opcin -s 127.0.0.1, que sera como decir: trfi co que tenga como IP de origen la direccin de loopback. Aunque tengamos protecciones contra ip-spoofing, sera una temeridad absurda hacer esto, pudiendo directamente reconocer la fuente por el DISPOSITIVO , y no por la direccin IP, que es mucho ms fcil de ser suplantada. Por tanto, en lugar de -s 127.0.0.1 utilizaremos: -i lo. Durante el segundo en que estemos cargando las iptables, nuestra red no funcionar, ya que estaremos rechazando todos los paquetes. Al final del script es imprescindible que no olvidemos elimi nar estas reglas porque, como sabemos, las reglas de ipta bles se ejecutan secuencialmente, por lo que si la primera regla rechaza todo, las dems nunca se ejecutarn.
Empezamos ya con las reglas. Todo lo que hay a partir de aqu podra ser modificado segn fuese cambiando nuestro escenario. Empezamos configurando la tabla NAT, de la cual ya os habl con detalle Vic_Thor. Si recordamos la configuracin de Zeus, ste tena una ta bla NAT que diriga todos los puertos abiertos a una nica IP, que era la de Cerbero. Lo que estaba haciendo Zeus era simplemente pasar la bola, aplazando la cuestin, para que fuese Cerbero quien realmente se encargase del NAT. Como vemos, Cerbero repartir los paquetitos de la si guiente forma: Los paquetes a los puertos 80 y 21 (www, y ftp) para Persefone. Los paquetes a los puertos 5000 a 5005 para que Eolo pueda tener DCC. Los paquetes a los puertos 5010 a 5015 para el DCC de Poseidon. Los paquetes al puerto 4662 para el emule de Poseidon.
Aqu, aparte de establecer la poltica DROP por defecto, es decir, poltica paranoica, estamos utilizando un meca nismo muy sencillo para evitar problemas MIENTRAS esta mos configurando las iptables. El script de iptables normalmente no tardar ms de un segundo en ser cargado en Cerbero (depende de cmo de potente sea la mquina), pero durante ese segundo pue den ocurrir mil cosas. Qu pasar con los paquetes que nos lleguen durante ese segundo? Podra ser el momento ideal para que se nos colasen, y todos los esfuerzos poste riores seran en vano. Mientras el script se esta cargando hemos de asumir que estamos totalmente desprotegidos por lo que, antes de to car nada, tenemos que asegurarnos de que se cierran to das las puertas, y no las abriremos hasta que no hayamos terminado de configurar todo. Para ello, insertamos una regla en la primera posicin de cada cadena (INPUT, OUTPUT, y FORWARD), que directa mente rechace todos los paquetes.
40/68

Una vez que ya se han establecido los caminos para cada paquete, luego tendremos que analizar la cadena FORWARD , para ver cmo se trata independientemente cada uno. Por ltimo, tenemos aqu las reglas de enmascaramien to, las cuales son imprescindibles para que el router adsl (Zeus) permita el trfico de todas las mquinas que hay detrs de Cerbero. Con estas reglas, cualquier paquete que tenga como IP de origen alguna que pertenezca a las redes Hades o Gaia , su IP de origen se convertir en la nica que Zeus conoce, que es la IP de Cerbero en la red Olimpo (192.168.1.1). Por si alguien se la con el smbolo \ , sirve simplemente para cortar una lnea y poder continuarla en la lnea si guiente (como el guin que usamos en castellano para cortar las palabras). permitimos los mensajes Time Exceeded para que funcio ne el traceroute. El resto de mensajes ICMP pueden ser prescindibles, y cualquier otro mensaje ICMP que se reciba o se enve ser logeado, y podremos encontrarlo fcilmente en el log bus cando la cadena ICMP, ya que hemos incluido ese pre fijo para el log.
Como ya explic Vic_Thor, hay que mantener las conexio nes ya establecidas, y rechazar las invlidas (paquetes con algn parmetro que no se corresponda con ninguna conexin establecida). Por tanto, los paquetes TCP sern analizados slo si son para establecer una nueva conexin (flag SYN), pero una vez que la conexin ya ha sido aceptada, el resto de pa quetes de la misma circularn libremente a travs de nuestras iptables.
Qu ms me queda por decir sobre las reglas de ICMP en iptables despus de todo lo que cont ya en artculos ante riores? Ya sabemos que necesitamos poder recibir mensajes ECHO-REPLY (pong) y enviar mensajes ECHO-REQUEST (ping) para que nos funcionen el PING, el TRACEROUTE, y otras aplicaciones. En cambio, no tenemos porque aceptar recibir mensajes ECHO-REQUEST (ping), ya que quiz no tenemos inters en responder nosotros al ping. Me he ahorrado trabajo al definir unas reglas generales de ICMP para todas las cadenas, pero en realidad habra que definir unas reglas especficas para cada cadena si quere mos ser puristas. Por ejemplo, el PING podra permitirse desde Hades y Gaia hacia Cerbero, para que las mquinas de estas redes pu diesen comprobar que el firewall/router est vivo. Pero no habra motivo para permitir un PING desde la red Olimpo, ya que no tenemos por qu dar ninguna informacin al ex terior, donde estn todos esos hackers malos. Como las consecuencias de esto son mnimas, he preferido ahorrar trabajo y crear unas reglas genricas de ICMP, pe ro insisto en que, si queris perfeccionar vuestro firewall, tendrais que definir reglas independientes para cada posi ble camino. Tambin insisto en que las iptables que tengo yo no son estas, por lo que el hecho de que me haya aho rrado trabajo en las iptables de este artculo, no significa que lo haya hecho en las mas. Os propongo como ejercicio que modifiquis estas iptables para que haya reglas independientes de ICMP para cada cadena. Aparte de los ping y pong tambin tenemos los clicks de playmobil, esto.... quiero decir.... que aparte de los ping y los pong tambin permitimos los mensajes Destination Unreachable, para que funcione el mecanismo de PMTUD que ya hemos visto a lo largo del curso. Tambin
Aqu tenemos un bonito surtido (como los de Cuetara) de diferentes tipos de escaneo de puertos que vamos a fil trar. Todos estos tipos de escaneo los puede hacer la mag nfica herramienta NMAP, y algunos de ellos tambin pue den ser utilizados por otras herramientas. NMAP intenta saltarse los firewalls utilizando, entre otras cosas, diferentes combinaciones de flags TCP. Ya se ha hablado sobre esto en la revista. Con esta serie de reglas estamos rechazando todos los pa quetes que tienen los flags que se sabe que son utilizados para este tipo de escaneos, y por otra parte estamos lo geando el escaneo. Como un escaneo completo suelen ser 65535 paquetes (uno por cada puerto TCP), sera una lo cura almacenar todo esto en el log. Por eso limitamos a que slo guarde registro de 5 de estos paquetes por minu to. Con eso tenemos suficiente para detectar el intento de escaneo, pero sin saturar nuestros logs.
Las tres cadenas anteriores, reglas_icmp, keep_state, y flags_tcp, slo quedaron definidas, pero no se especific en ningn momento sobre qu paquetes deban ser aplica das. En esta seccin de nuestro script indicamos que estas 3 cadenas han de ser aplicadas en todos los sentidos: INPUT, OUTPUT, y FORWARD. Si quisisemos aplicar reglas diferentes de icmp para cada camino, tendramos que eliminar estas reglas, ya que pre valeceran sobre las que pusisemos despus.
41/68

Tambin es posible que quisiramos aplicar reglas diferen tes para los flags TCP, permitiendo as por ejemplo que no sotros podamos hacer NMAP al exterior, pero que no nos lo puedan hacer a nosotros desde el exterior. En cambio, las reglas de keep_state si que las necesitare mos siempre para cualquier camino. Propongo como ejercicio tambin que modifiquis esta seccin a vuestro gusto.
Si bien Gaia puede acceder a los servicios de Hades, Hades de ninguna manera puede acceder a Gaia. Precisamente aqu es donde se encuentra la esencia de las redes con DMZ. Una DMZ es bsicamente una zona sus ceptible de ser hackeada. Si un hacker lograse hacerse con el control absoluto de la red DMZ, estaramos perdidos si hubiese algn acceso desde sta hacia la red interna. Ya se nos pueden colar todos los hackers que quieran en nuestros servidores (Hades), que desde ellos no lograrn llegar a nuestra red interna (Gaia), a no ser que consigan adems hackear nuestro firewall (Cerbero). Cmo puede entonces funcionar la comunicacin de Gaia hacia Hades si todo el trfico de Hades hacia Gaia est ce rrado? No tendramos que permitir al menos las respues tas que tenga que enviar Hades a Gaia cuando por ejemplo Eolo se conecta por SSH a Persefone? Pues claro que s, pero esta situacin ya la tenemos con templada en la cadena keep_state . Es Eolo quien enva el paquete SYN que establece la conexin entre Eolo y Persefone. Una vez establecida la conexin, nuestra cade na keep_state prevalecer sobre la regla que tenemos aqu: iptables -A hades_gaia -j DROP Y por qu prevalece? Pues lgicamente, porque la inser tamos antes, concretamente en este punto: iptables -A FORWARD -p tcp -j keep_state Normalmente, si vemos en el log alguna lnea con el prefi jo HADES->GAIA: , que es el que hemos puesto para este camino, tendremos que estar alertas porque es una posible seal de que hemos sido atacados a travs de la DMZ.
En nuestro escenario tenemos 3 redes: Gaia, Hades, y Olimpo. Por tanto, habr 6 posibles caminos entre estas redes: De Gaia a Hades De Gaia a Olimpo De Hades a Gaia De Hades a Olimpo De Olimpo a Gaia De Olimpo a Hades A partir de esta seccin, vamos detallando las reglas que tendr que seguir cada uno de estos 6 caminos. El primero de estos, De Gaia a Hades, es el que describimos aqu. Como sabemos, Gaia es la red interna, y Hades la red DMZ. Tpicamente, en una configuracin con DMZ, la red interna puede tener acceso a la DMZ para poder utilizar los mis mos servicios que la DMZ est dando al exterior (es decir, a Internet o, en nuestro escenario, la red Olimpo, que es la intermediaria directa con Internet). Aparte de poder utilizar los servicios de la DMZ, es tam bin muy tpico que el administrador de sistemas tenga tambin su PC dentro de la red interna, y que se abra al gunas puertecillas para poder administrar remotamente los servidores sin tener que estar yendo de una mquina a otra. En este caso, hemos abierto una administracin re mota del servidor Persefone a travs de SSH, a la cual slo tendr acceso la mquina Eolo. Quiz la lnea mas importante en esta seccin es esta: iptables -A FORWARD -i $gaia -o $hades -j gaia_hades Todo lo que entre por el dispositivo que conecta a la red Gaia (-i $gaia) y salga por el dispositivo que conecta a la red Hades ( -o $hades ) tendr que atravesar la cadena gaia_hades que acabamos de crear. Una vez ms, insisto en que es ms seguro identificar los caminos por los dispositivos de entrada y salida, ms que por direcciones IP.
Esta es otra seccin que podra ser mejorada enormemen te, y que tambin os dejo como ejercicio. En principio, permito que los servidores de la DMZ tengan acceso total a Internet. As, si en algn momento el admi nistrador se sienta a los mandos para bajar actualizaciones de software, o cualquier otra cosa, no tendr limitado el acceso. En cambio, esta no es la opcin ms segura, y lo mejor sera limitar el acceso al exterior de forma inteligente. As, si alguien llegase a penetrar en algn servidor, tendra muy limitado el acceso al exterior. Qu tal, por poner un ejemplo, limitar la salida del protocolo TFTP? Recordis aquellos sistemas clsicos para meter troyanos en una m quina medio-hackeada?
42/68

En una configuracin totalmente paranoica, esto sera im pensable. Pero como estamos considerando una configuracin ms bien domstica, es normal que los usua rios de la red interna utilicen ciertos servicios como IRC, redes P2P, ... As que en primer lugar, por supuesto, tenemos que dejar que pasen las respuestas a nuestras consultas DNS , tal y como vimos antes. Ahora tenemos que recordar el artculo sobre DCC de la serie RAW. Cunto tiempo hace de aquello ya, verdad? En nuestro caso, hemos abierto 6 puertos de DCC para ca da mquina de la red interna. Tanto Eolo como Poseidon tendrn que configurar sus clientes de IRC (mIRC, xchat, o el que sea...) para que el DCC vaya slo a travs de los 6 puertos que tienen asignados. Aparte de esto, slo nos queda el Emule de Poseidon, que necesitar tener abierto el puerto 4662 de TCP para fun cionar correctamente. Por supuesto, todo lo dems tendr que ser rechazado. Aunque en realidad ser difcil que nos lleguen paquetes que no encajen aqu, ya que previamente la tabla NAT se encarg de redireccionar hacia Gaia slo los puertos que ya hemos tratado.
Aqu es donde se encuentra reflejada la funcionalidad de la red DMZ. En primer lugar, para cualquier camino que venga desde Olimpo tenemos que permitir los paquetes que tienen co mo IP de origen la de nuestro servidor DNS (o servido res, si tenemos configurado ms de uno), como protocolo UDP, y como puerto de origen el 53 (el puerto de DNS, llamado con el alias domain). Por supuesto, igual que tenemos que dejar entrar las res puestas a nuestras consultas DNS, tambin tenemos que dejar salir nuestras consultas. Esto sera responsabilidad de los caminos que van hacia Olimpo, y no los que vie nen desde Olimpo, como este. Por ejemplo, el camino an terior, hades_olimpo, iba hacia Olimpo, pero al permitir todo el trfico, implcitamente estamos permitiendo tam bin las consultas DNS. Aparte del DNS, tenemos que permitir la entrada de co nexiones hacia los puertos de ftp y web. El puerto de ssh, por supuesto, no estar abierto hacia la red Olimpo, ya que slo Eolo (que pertenece a la red Gaia) puede admi nistrar remotamente a Persefone.
Aqu de nuevo estamos permitiendo que los usuarios de la red interna tengan acceso de salida total hacia Internet. Tambin os dejo como ejercicio que limitis este acceso, si queris, aunque en general en una red domstica lo ms conveniente ser dejarlo abierto, para que podamos mo vernos a nuestras anchas por Internet desde nuestro PC. En cambio, en una red corporativa, podra ser interesante limitar el acceso de los empleados, para que por ejemplo no puedan conectarse a chats, o a otros servicios no de seados. En cualquier caso, la mejor forma de limitar este acceso al exterior no seran las iptables, si no un proxy, como por ejemplo el famoso Squid que, entre otras cosas, nos per mitir por ejemplo limitar qu paginas web pueden ver los empleados, y cules no (evitamos as una de las mayores prdidas de tiempo de los empleados, que es la pornogra fa).
Aqu creamos 3 nuevas cadenas de reglas, que se aplica rn a cualquier paquete que tenga como IP de destino la del propio Cerbero : una cadena para los paquetes que provienen de la red Olimpo, otra para los de la red Gaia, y otra para los de la red Hades. En el caso de la red Olimpo, slo permitimos que nos trai ga de vuelta la respuesta a las consultas DNS que poda mos hacer desde el propio Cerbero. En realidad, hasta esto podramos quitarlo, ya que normalmente nunca nos senta remos a los mandos de Cerbero para hacer nada, por lo que no hay motivo para necesitar hacer consultas DNS. En el caso de Hades, no permitimos ningn trafico hacia Cerbero, faltara ms... Si hemos dicho que la DMZ (Ha des) es la red potencialmente ms vulnerable, de ninguna manera podemos permitir ningn tipo de acceso desde es ta red hacia el corazn de nuestro sistema de seguridad, que es Cerbero. Si vemos en los logs alguna lnea que empiece por el pre fijo que hemos puesto para este camino, "HADES ->CERBERO: " , entonces s que nos podemos mosquear, porque es probable que alguien haya entrado en la red DMZ, y est intentando penetrar en el firewall a travs de ah. Bastante buenos estamos siendo ya permitiendo que des de la DMZ se pueda hacer ping al firewall (por la cadena
Nuestra configuracin no es muy purista que digamos. Puertos abiertos en la red interna!
43/68
reglas_icmp), por lo que sta sera una de las reglas que interesara modificar a la hora de personalizar las reglas de ICMP para cada camino. Por ltimo, con respecto a Gaia, tenemos ms de lo mis mo. En este caso, tericamente, no sera tan grave permi tir algn tipo de acceso hacia Cerbero, pero... para qu? Si no hay ningn motivo por el cual tengamos que comuni carnos desde Gaia hacia Cerbero, mejor cerrar todo y cu rarnos en salud.
Para activar todo el script que hemos creado slo nos falta una cosa: eliminar las reglas de bloqueo que colocamos al principio de cada cadena (INPUT, OUTPUT, y FORWARD). Por tanto, con slo borrar la regla nmero 1 de cada cade na: hop! iptables funcionando. Por cierto! Antes de que me vaya, por si alguien no lo sa be, todas las mquinas de Hades y Gaia tienen que tener como puerta de enlace a Cerbero (con la IP de Cerbero que corresponda segn la red en la que estemos), y como mscara de red 255.255.255.0. Es decir, stas seran las puertas de enlace de cada mquina: Persefone: 192.168.2.1 Eolo: 192.168.3.1 Poseidon: 192.168.3.1
Como ya dije, en principio permitimos que el propio Cerbero pueda hacer consultas DNS, aunque perfectamen te podramos eliminar esta opcin. En cualquier caso... para qu lo bamos a querer, si todo el resto del trfico est cerrado? Como vemos, cerramos todo el trfico desde Cerbero hacia el exterior, as que olvidaos de navegar por Internet desde el firewall.
Autor: PyC (LCo)
44/68

TCP/IP: El protocolo clave de Internet

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TCP/IP: El protocolo clave de Internet

Загружено:

Авторское право:

Доступные форматы

CURSO DE TCP/IP INTRODUCCIoN

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

2. El concepto fundamental de protocolo por capas

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

3. Las capas de TCP/IP

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

3.1. La capa IP: La necesidad de direccional

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Funcionamiento bsico del sistema de correo postal.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Comentario de Hack x Crack...

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

3.3. La capa TCP: El tamao de los paquetes.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

3.4. La capa TCP: Las conexiones simultneas

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4. Ejemplo: Enviando un archivo.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

En el servidor FTP de PyC

4.2. En el Sistema Operativo de PyC: La capa TCP.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4.3. En el sistema operativo de PyC: La capa IP.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4.4. En el sistema operativo de PyC: la capa de enlace.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4.6. En el router ADSL de PyC: Las capas fsica y de enlace

4.5. En la tarjeta de red de PyC: La capa fsica

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4.7. En el router ADSL de PyC: La capa IP

En el router del ISP de PyC

4.10. Flotando en el ciberespacio

4.8. En el router adsl de PyC: De nuevo en la capa de enlace.

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4.12. En el PC de Scherzo: la capa Ethernet.

4.11. En el router ADSL de Scherzo

4.13. En el sistema operativo de Scherzo: la capa IP

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

4.14. En el sistema operativo de Scherzo: la capa TCP

4.15. En el sistema operativo de Scherzo: de vuelta en la capa IP

4.16. Vamos pa atrs!

Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin - Curso de TCP/IP - Introduccin

Autor: PyC (Lco)

Ilustraciones: Adhara (Lco)

QUIERES COLABORAR CON PC PASO A PASO?

NOSOTROS PODEMOS PUBLICAR TU OBRA!!!

CURSO DE TCP/IP (2 Entrega)

(PROTOCOLO DE DA T AGRAMAS DE USUARIO)

NOTA DE PC PASO A PASO / HXC

NOTA DE PC PASO A PASO / HXC:

2.1. LAS CAPAS DE UDP/IP

2. FUNCIONAMIENTO DEL PROTOCOLO UDP

2.2. FUNCIONES DE LA CAPA DE TRANSPORTE UDP 2.2.1. Identificacin conexiones de

2.2.2. Correccin en los datos

2.3.3.Tratamiento adecuado de los paquetes grandes

2.3.2. Flujo ordenado de datos