Curso HXC de TCP-IP PDF

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 página lo has dado por IMPOSIBLE!!!
TCP-IP es el alma de la red, nosotros te ofrecemos un curso MUY ESPECIAL ;)
1.Introducción a la introducción. glosario de términos; si no realmente llegar

a hacer suyos los conceptos y comprenderlos
Probablemente muchos de vosotros esperabais de una forma totalmente natural.
con impaciencia un curso como este, así que
espero que vuestra alegría, al ver que al fin Por supuesto, ya se que la mayoría de los
nos metemos de lleno con el tema en esta lectores de esta revista tienen ya un nivel
revista, no se vea frustrada al descubrir que aceptable de conocimientos, pero he de
vuestro profe en este curso va a ser el enfocarlo no sólo para los lectores veteranos,
mismo que mes tras mes os ha ido aburriendo si no también para aquellos totalmente novatos
soberanamente con la serie RAW. ;-) que, sin duda, serán los que más se beneficien
de este curso y que les abrirá las puertas para
Si es cierto que os parezco aburrido, en mi llegar a comprender en profundidad todo lo
defensa he de alegar que la descripción demás que se enseñe en la revista a partir de
detallada de un protocolo es algo aburrido de ahora.
por sí y, aunque he hecho lo posible por hacer
artículos amenos, cuando hay que ponerse Sin duda alguna, el TCP/IP es uno de los pilares
serio, hay que ponerse serio. de todo este jaleo en el que estamos metidos.
;-) Así que decidí coger al toro por los cuernos,
Aprovecho esta ocasión para agradecer a y enfocar la cuestión desde un punto de vista
Adhara (conocida como MariAn antes de diferente.
digievolucionar) su aportación en este sentido,
con las caricaturas e ilustraciones que ha
aportado para amenizar en la medida de lo
! TCP/IP
posible la serie RAW y que, por supuesto,
también seguirá aportando en este curso que TCP / IP: Transmission Control Protocol / Internet Protocol
comienza. = Protocolo de Control de Transmisión / Protocolo de
Internet
Os plantearé el terrible dilema que he sufrido
para poder comenzarlo. Para ayudarme a la
hora de estructurar un poco las ideas he ¿Cuántos cursos de TCP/IP empiezan contando
ojeado multitud de libros y cursos de TCP/IP el modelo OSI (Open Systems
para ver cómo abordaban el problema y poder Interconnection = Interconexión de
explicarlo desde cero, que era mi gran reto. Sistemas Abiertos)? A los que hayáis seguido
alguno de esos cursos publicados en Internet
Lamentablemente, en ninguno he encontrado o en otras revistas, ¿os quedó claro desde el
lo que yo buscaba, una forma de introducir principio, por ejemplo, para qué servia la capa
los conceptos de forma que alguien sin ningún de sesión del modelo OSI? ¿No pensáis que
conocimiento pueda no sólo aprenderse de quizá empezar abordando el problema
memoria un montón de formatos de planteando un modelo teórico tan complejo
cabeceras, comandos de protocolos, y un puede ser contraproducente? ¿No os quedaron
PC PASO A PASO Nº 17 Página 31

Curso de TCP/IP - Introducción - Curso de TCP/IP - Introducción - Curso de TCP/IP - Introducción
más dudas después de terminar el tema de 2. El concepto fundamental de

introducción que antes de empezarlo? Seguro protocolo por capas
que la mayoría dejasteis el curso a la mitad
(y otros ni siquiera pasasteis de las primeras Empezaremos nuestro viaje metafórico por el
páginas). mundo de los protocolos situándonos en un
hospital, donde los doctores PyC y Scherzo
El empezar cualquier curso de TCP/IP hablan acerca de la próxima operación a
hablando del modelo OSI parece que corazón abierto que tendrán que llevar a cabo.
ha sido la solución estándar para solucionar
el reto de mostrar el concepto de los El doctor PyC tiene unas dudas acerca de la
protocolos por capas a gente totalmente complicadísima operación, y acude al doctor
nueva en el tema. Pero a mí personalmente Scherzo en busca de ayuda.
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 clásicos tengan
aquí una segunda oportunidad.
¿Qué esperabais? ¿Que mi curso de TCP/IP

fuese como todos los demás? ¡Para eso tenéis
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
confío en que todos vosotros tendréis buen
juicio para escoger la opción que para cada
uno de vosotros resulte más adecuada.
Como veréis, mi enfoque intenta mostrar los

conceptos puros, al margen de cualquier
detalle técnico, mediante varios símiles con
otros conceptos, bien conocidos por todos,
de nuestra vida cotidiana.
Por supuesto, después de este primer artículo

vendrán otros, y ahí si que veremos ya en
profundidad los detalles técnicos, los cuales
nos entrarán con muchísima más facilidad si
previamente hemos dedicado un tiempo
imprescindible a llegar al fondo de los
conceptos.
Página 32 PC PASO A PASO Nº 17

Dios mío, como haya entre los lectores algún

médico o estudiante de medicina... ¡que me
perdone por la increíble cantidad de
estupideces que acabo de soltar! XD
Al margen de si tiene sentido o no la parrafada,

supondremos que se trataba de una
conversación perfectamente normal entre
cirujanos.
Ahora vamos a plantearnos una serie de

cuestiones sobre estas viñetas. En primer
lugar, ¿qué han hecho básicamente PyC y
Scherzo?
COMUNICARSE.
Se convertiría en ésta otra:
Ahora vamos a analizar un poco en qué ha

consistido esa comunicación.
En primer lugar, lo que más nos llama la

atención es el lenguaje técnico utilizado, que
sólo es comprendido por los cirujanos.
Igual que los cirujanos tienen su propio

lenguaje técnico, los informáticos también
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

técnicos sean diferentes, todos ellos se apoyan
en una misma base, que es el idioma; en este Por la cara que pone el doctor Scherzo podemos
caso, el castellano. estar seguros de que utilizando tan sólo el
lenguaje técnico, sin apoyarnos en la base que
El lenguaje técnico de los cirujanos consiste es el idioma castellano, es imposible que dos
únicamente en una serie de palabras y cirujanos se comuniquen.
expresiones que permiten expresar los
términos específicos que requieren los Lo mismo que pasa con los cirujanos pasa con
cirujanos para comunicarse en su trabajo. Por cualquier otro grupo de profesionales que
tanto, no es un lenguaje completo, ya que no utilicen su propio lenguaje técnico. Todos ellos
posee una gramática propia que permita apoyan toda su conversación en un idioma
mantener una conversación sin apoyarse en común, que puede ser el castellano, el inglés,
un idioma básico, como puede ser el castellano. o cualquier otro.
Si, por ejemplo, eliminásemos de la parrafada Por supuesto, para que dos profesionales se
del doctor PyC todo aquello que no formase entiendan tienen que hablar no sólo el mismo
parte exclusivamente del lenguaje técnico de lenguaje técnico, si no también el mismo
los cirujanos, esta frase: idioma común.

Si el doctor PyC hablase Japonés, sin duda entrar más en profundidad en la comunicación
el doctor Scherzo habría puesto la misma que vimos en las viñetas.
cara de incomprensión.
¿Qué otro medio común han utilizado el doctor
Según lo que hemos visto hasta ahora, la Scherzo y el doctor Pyc para comunicarse?
comunicación entre los dos doctores funciona ¡El habla!
gracias a dos capas independientes: el idioma, Si trasladásemos toda esa conversación a un
y el lenguaje técnico. papel, ¿no tendría el mismo sentido? ¿Y si la
trasladásemos a una conversación telefónica?
¿O a una conversación por IRC (Internet Relay
Chat)?
Los dos doctores se han apoyado en un medio

físico común, que es la voz, pero perfectamente
podrían haber mantenido la misma
conversación a través de otro medio físico,
como la escritura, o el teléfono.
¿Cuál es el motivo por el cual es esto así? Tanto si esa conversación es hablada como si
Pues, si pensáis un poco, llegaréis vosotros es escrita, seguiría utilizando tanto el lenguaje
mismos a la conclusión. técnico de los cirujanos, como el idioma
castellano. En nada cambiaría, salvo en el
Imaginad que el lenguaje técnico de los hecho de que el medio utilizado sería diferente.
cirujanos fuese un lenguaje completo, con
sus fórmulas de saludos, despedidas, una Ahora bien, igual que un cirujano japonés no
gramática completa para construir las frases, puede entenderse con un cirujano de Jaén, si
palabras para expresar cualquier término el doctor PyC le hubiese soltado la parrafada
común en cualquier comunicación (como los al doctor Scherzo por correo, y éste le hubiese
habituales: me lo repita, ¡habla más respondido a viva voz cuando recibiese la
despacio, que no me da tiempo a apuntarlo!, carta (es decir, que se lo habría contado a las
etc.), e incluso tuviese sus propios nombres, paredes), tampoco habría sido posible una
en lugar de los que tenemos en castellano comunicación.
(doctor Pyc, y doctor Scherzo). ¡Sería una
completa locura! Ambos interlocutores tienen que compartir el
mismo medio físico para comunicarse. Si un
Desde luego, no sería nada práctico que interlocutor está utilizando el teléfono, y el
cualquier cirujano tuviese que aprender un otro está respondiendo por escrito en un papel,
idioma totalmente nuevo sólo para poder jamás podrá haber una comunicación.
comunicarse con sus colegas.
Por supuesto, tampoco sirve de nada que
Lo más práctico, y lo más lógico, es utilizar ambos hablen a viva voz, si cada uno está en
el recurso conocido por todos que es el idioma un lugar diferente, donde no se puedan
castellano, y simplemente ampliarlo con una escuchar mutuamente.
serie de términos que permitan entrar en
detalle en los conceptos manejados por los Podemos considerar, por tanto, al medio físico
cirujanos. como otra capa de la comunicación. En este
caso, esta capa ya no existe por una
Una vez comprendida la necesidad de conveniencia de hacer las cosas más fáciles,
comunicarse utilizando dos capas, vamos a si no por una necesidad natural.

entre los dos interlocutores. Nos da

exactamente igual que el intérprete no
entienda ni papa de la conversación, ya que
esa conversación no va dirigida a él, no es
más que un mero intermediario. Él tiene que
saber únicamente ambos idiomas: japonés y
castellano.
Una vez que el intérprete ha traducido la frase

Vamos a hacer una incisión subyugular ya
será problema de los cirujanos entenderse
entre ellos, ya que el intérprete no tiene ni
idea de qué es una incisión subyugular, pero
si que sabe traducir las palabras literalmente.
Vamos a ver qué ocurre ahora si el doctor
Me-Iwa, de Japón, quiere hablar con el doctor Por tanto, podríamos considerar al intérprete
PyC acerca de la operación de cardiopatía como un intermediario en la conversación que
precarótida. sólo llega a comprender hasta cierta capa de
la comunicación pero que, aún así, es capaz
Por supuesto, no podrán comunicarse de transmitir todo, confiando en que los
directamente, al hablar distintos idiomas, interlocutores serán capaces de comprenderse
pero por suerte el doctor Me-Iwa tiene un una vez traducido el idioma.
intérprete que puede hablar tanto en castellano
como en japonés, por lo que éste sería el Más adelante profundizaremos mucho más
escenario ahora: en la cuestión de los intermediarios en la
comunicación, así que quedaos bien con esta
idea. ;-)
3. Las capas de TCP/IP
¡Al fin vamos a ver la relación que tiene todo

esto con el tema que nos interesa!
Ya hemos comprendido la necesidad de
estructurar la comunicación en diferentes
capas, tanto por necesidad física, como por
Ahora meditemos un poco acerca de este conveniencia para facilitar la comunicación
nuevo personaje, el intérprete. Lo más (reducir su complejidad). Por supuesto, eso
probable es que este intérprete sea un es algo que ocurre en todo tipo de
estudiante de filología, o simplemente un comunicación y, por tanto, la comunicación
estudiante de idiomas de academia pero, en entre máquinas no va a ser menos.
cualquier caso, es poco probable que el
intérprete sea un cirujano. Por un momento, imaginemos que no hubiese
capas en la comunicación por Internet.
Pero, ¿es realmente necesario que el intérprete
sepa algo de cirugía? El lenguaje técnico de Si yo tuviese que programar un cliente de
los cirujanos al fin y al cabo no es más que correo electrónico (como por ejemplo el
una extensión del idioma, por lo que bastaría Outlook Express, tendría que idear desde cero
con que el intérprete simplemente conociese toda una serie de funciones para interconectar
ambos idiomas para transmitir la conversación al remitente y al destinatario, una serie de

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 después me da por programar un cliente

de FTP (si no sabes lo que es el FTP File
Transfer Protocol-, descárgate gratis el número
1 de esta revista desde www.hackxcrack.com),
tendría 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.
Comparación entre las capas de la comunicación entre dos
personas y la comunicación entre dos máquinas. Esta
El hacer las cosas de esta manera, no sólo comparación no es muy precisa, así que la muestro sólo
sería una cantidad ingente de trabajo como una primera aproximación a la idea.
innecesario, si no que además dificultaría
enormemente que los programas se Los que hayáis seguido mi serie RAW desde
entendiesen entre sí. el principio, comprenderéis ahora por qué una
y otra vez repetía frases como: protocolo que
Si todas las aplicaciones que utilizan Internet funciona sobre TCP/IP, o protocolos por
tienen que realizar una serie de tareas encima del nivel de TCP/IP, etc.
comunes, como son la interconexión de las
partes implicadas en la comunicación, la Por ejemplo, ¿tenéis a mano el número 14 de
identificación de ambas partes, la corrección la revista, en el que hablaba sobre el protocolo
de errores, el ajuste de las velocidades de DNS? Mirad el primer párrafo de ese artículo,
recepción y transmisión, etc., etc., ¿por qué y veréis que decía:
no utilizar un lenguaje común para todas Por primera vez en la ya veterana serie RAW,
ellas? no se trata de un protocolo basado en TCP,
¡si no en el aún desconocido UDP!
Igual que todos los profesionales (cirujanos,
informáticos, arquitectos...) utilizan el idioma Esto sería lo mismo que decir: este lenguaje
castellano como base sobre la cual apoyan que vamos a contar no se basa en el idioma
luego sus lenguajes técnicos propios, castellano, si no en el idioma japonés.
también las máquinas conectadas a Internet
utilizan un mismo idioma común como base Ahora ya comprendemos la necesidad de
sobre la que luego apoyar cada lenguaje separar por capas las comunicaciones entre
específico. máquinas para facilitar la comunicación, y
reutilizar el trabajo ya hecho para no tener
En este caso, el idioma común de las máquinas que reprogramarlo cada vez.
es el famoso TCP/IP, y los lenguajes técnicos
que utiliza cada máquina apoyándose en Y precisamente esas funciones que son
TCP/IP son los que permiten las diferentes utilizadas por muchos programas para que
tareas, como transmitir ficheros (FTP), enviar estos no tengan que reprogramarlas desde
correo (SMTP), mostrar páginas Web (HTTP), cero, son precisamente las funciones que te
etc., etc. da la API de un Sistema Operativo.

Por ejemplo, un programa que funcione bajo Por el momento, continuaremos con los
Windows no tiene que preocuparse de saber conceptos sin entrar en ningún detalle.
cómo dibujar una ventana en la pantalla, si Ahora que ya habéis comprendido el concepto
no que simplemente le dice al sistema de capas, he de pediros que os olvidéis del
dibújame una ventana de estas ejemplo de los cirujanos, porque mi intención
características y Windows hará el trabajo era únicamente que comprendieseis el
sucio por él. concepto de capas, pero no mostrar
metafóricamente cada capa del protocolo
Todavía recuerdo los tiempos en los que TCP/IP con su equivalente en el mundo real,
programaba aplicaciones gráficas en MS-DOS ya que las capas que forman TCP/IP no tienen
y me tenía que currar desde cero todo el prácticamente nada que ver con las capas que
interfaz... un auténtico infierno. Perdías más forman la comunicación entre dos cirujanos.
tiempo con el interfaz que con el propio
programa. La única capa que sí que tienen en común
tanto las máquinas como los cirujanos es la
Pues lo mismo que ocurre con las ventanas, del medio físico ya que, como dije, esta capa
que son una función común a todas las no surge como una facilidad para la
aplicaciones de Windows, también ocurre con comunicación, si no que es una necesidad
las comunicaciones, que tienen una serie de natural irremediable. Igual que dos cirujanos
funciones comunes a todas las aplicaciones necesitan compartir un mismo medio para
de comunicaciones. Estas funciones comunes, comunicarse, también han de hacerlo dos
que son las que proporciona el idioma TCP/IP, máquinas.
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 En el caso de las máquinas, hay que tener en

motivo por el cuenta no sólo la tecnología utilizada en los
que, antes de propios cables que interconectan las
conectar con máquinas (que sería el medio físico) si no
Internet o con también el cómo están conectadas: cada cable
cualquier otra conecta sólo dos máquinas, un sólo cable
red, tenemos conecta a la vez a muchas máquinas entre sí,
que configurar etc. Es decir, cómo se enlazan las máquinas
el protocolo entre sí. Ya veremos mucho más sobre esto
TCP/IP en más adelante, pero de momento nos
n u e s t r o quedaremos con la idea de que existe una
sistema. segunda capa, conocida como capa de enlace.
Configuración de TCP/IP en Windows. Para los impacientes, deciros que aquí es

donde se ubicaría el famoso protocolo ARP
A lo largo del curso probablemente veremos (Protocolo de Resolución de Direcciones),
cómo configurar correctamente el idioma que es una parte de la capa de enlace utilizada
TCP/IP con diferentes sistemas. normalmente en nuestros PCs.

Las funciones de esta capa son muchas, pero

básicamente podríamos 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
Por encima del nivel de enlace, tenemos ya continuación una serie de puntos que, de
la primera capa que realmente nos sonará, nuevo a base de símiles, os explicarán muchas
que es la llamada capa de red y que, en de las funciones llevadas a cabo por cada
nuestro caso (el caso de TCP/IP) es la capa capa.
llamada IP.
¿Cuál es la responsabilidad de esta capa?

Pues principalmente una: conseguir que la
comunicación llegue desde el origen hasta el
destino. Ésta es la capa encargada de
identificar a las diferentes máquinas, para
que éstas puedan diferenciarse unas de otras,
y mantener así comunicaciones separadas.
Si no existiese esta capa, todos los datos de
Internet llegarían a todas las máquinas
conectadas a la red. No habría forma de ver
una página Web, ya que no se podría
diferenciar una de otra; no se podría enviar 3.1. La capa IP: La necesidad de
un e-mail, ya que no sabríamos cómo direccional
encontrar nuestro servidor de correo, etc.,
etc. Para comprender la necesidad de la capa IP
(Internet Protocol = Protocolo de Internet)
Supongo que esto no os sonará muy raro, presentaremos un nuevo escenario, bien
teniendo en cuenta que las direcciones conocido por todos, que es el correo postal
utilizadas en Internet se llaman precisamente de toda la vida.
direcciones IP. ¿Casualidad? ;-)
En nuestro ejemplo, PyC, residente en Madrid,
quiere enviar una carta a la siguiente dirección:
Perico Palotes
C/Pirulin. Nº12. 1º A.
35003 Villapalotes (Huelva).
¿Cómo puede llegar hasta su destino la carta

Pero, aún nos faltan muchas funciones después de que PyC la eche en el buzón de
comunes, ¿verdad? Como podéis adivinar, su barrio? Todos conocemos bien el proceso.
del resto de funciones se encarga la capa que Primero, el cartero del barrio recoge todas las
está por encima de la capa IP que es, cartas del buzón, y las lleva a la oficina de
precisamente, la capa TCP. correos más cercana. Una vez ahí, se ve que
el destino de esta carta es Huelva y, por tanto,
En cualquier modelo (ya que TCP/IP no es el único
el sobre es transportado hasta esa provincia
modelo de protocolo por capas que existe) a esta
en un furgón de Correos. En esa provincia,
capa se la conoce como capa de transporte.
el sobre se lleva a la oficina de correos

correspondiente. En esa oficina, comprueban la

dirección, y llevan la carta hasta el buzón personal
de Perico Palotes.
Comparación entre los elementos del correo postal y los elementos

de la comunicación de dos máquinas en Internet. Los furgones
de correos, los carteros, y las oficinas de correos que forman la
red postal, serían los routers que forman la red Internet. Igual
que los carteros no abren las cartas, porque les basta sólo con
ver el sobre, los routers tampoco ven el interior de nuestros
paquetes, si no que miran sólo el equivalente al sobre para saber
dónde mandarlos, como veremos más adelante.
Funcionamiento básico del sistema de correo postal.
Gracias a las direcciones postales todo el sistema 3.2. La capa TCP (Transmission
de Correos puede funcionar. Y no sólo gracias a la Control Protocol = Protocolo de
dirección del destinatario, si no también a la del Control de Transmisión) : La
remitente, que será una dirección con el mismo
formato (nombre, calle, código postal, población, y
necesidad de las conexiones para
provincia). tener una comunicación fiable
Gracias a la dirección del remitente se sabrá a quién Volvamos ahora al escenario del hospital. En
informar si la carta no llega a su destino, y el esta ocasión, el doctor PyC recibe un aviso de
destinatario podrá responder a la carta si lo desea. urgencia a través del servicio de megafonía
del hospital.
Pues exactamente lo mismo ocurre con las
direcciones de Internet. Aunque estas direcciones,
las famosas IPs, aparentemente no consten de varios
campos (nombre, calle, población, etc.), en realidad
esos campos sí que existen, y están codificados
dentro del propio número que forma la dirección IP.
Igual que existen las oficinas de correos, también

existen una serie de máquinas dedicadas
exclusivamente a transportar los sobres de Internet
de una máquina a otra.
Estas máquinas mediadoras en la comunicación son
conocidas habitualmente como routers. Estos routers,
al igual que hacen las oficinas de Correos, se dedican
a analizar las direcciones Ips para saber dónde
tendrán que enviar el sobre para que, paso a paso,
termine llegando a su destino.

Pero, ¿qué ocurriría si el doctor PyC no Os remito de nuevo al número 14 de la revista,

estuviese en ese momento en el hospital? ¿Y donde vimos un ejemplo de protocolo apoyado
si estuviese en esos momentos escuchando en UDP/IP, que es el protocolo DNS. A lo largo
música y no oyese el aviso? Cuando se lanza del curso ya veremos en profundidad el
un aviso por megafonía se tiene cierta protocolo de transporte UDP.
confianza en que el mensaje llegará a su
destinatario, pero en realidad no se puede
tener nunca esa certeza. Sueltas el mensaje ! Comentario de Hack x Crack...
al vacío, y no tienes forma de saber si al otro
lado hay alguien escuchando. Esto es lo que Para aquellas mentes inquietas, apuntaremos un detalle.
se llama una comunicación no orientada a
conexión. El protocolo TCP podemos clasificarlo como pesado porque,
al estar orientado a la conexión, consume muchos más recursos
Esta solución en muchos casos no es de red, es decir, el proceso para establecer una comunicación de
aceptable, pero en muchos otros sí que puede este tipo está formada por muchos pasos.
ser suficiente. Por ejemplo, en el caso de la
megafonía del hospital, si el doctor PyC no El protocolo UDP podemos considerarlo como ligero porque,
ha acudido al aviso en un cierto tiempo, al no estar orientado a la conexión, consume pocos recursos de
probablemente se le volverá a llamar. red, es decir, el proceso tiene muy pocos pasos.
Existen otros casos de comunicación no
orientada a conexión en los que directamente El protocolo UDP es muy utilizado, por ejemplo, en la emisión
enviamos el mensaje con la esperanza de de video por Internet o los programas de intercambio de archivos
que llegue pero, si no llega, nos aguantamos tipo eMule.
y, a otra cosa, mariposa. Un ejemplo es el
del envío de postales navideñas. Tú mandas Para que se entienda, en la transmisión de video en tiempo real
un porrón, y si llegan o no a su destino es por Internet (por ejemplo), lo que interesa es que al receptor le
algo que en muchos casos nunca sabrás pero, llegue la máxima información posible en el menor espacio de
lo que sin duda si que sabes, es que ni por tiempo posible, no importa si se pierden unos cuantos frames de
asomo te vas a poner a reenviarlas por si película por el camino (es imperceptible), lo importante es que
acaso no han llegado. la película no se pare y se pueda ver fluida en tiempo real.
Como en algunos casos la comunicación no Sería absurdo que si el frame 7 no llega, se parase la película,
orientada a conexión es suficiente, en las pidiésemos de nuevo al emisor el frame 7, esperásemos su llegada,
máquinas también es utilizada para algunos la comprobásemos y volviésemos a activar la película. Si pensamos
casos concretos. Cuando no necesitamos que llegan entre 15 y 30 frames por segundo, bufff, estaríamos
saber si nuestro interlocutor nos está parando la película cada dos por tres es mejor despreciar
escuchando, no necesitaremos utilizar un ese frame que no ha llegado y seguir con la peli :)
protocolo de transporte fiable, como es TCP,
si no que nos bastará con utilizar un protocolo En el caso de los programas de intercambio de archivos tipo P2P
no orientado a conexión, que también os (como el eMule, http://www.emule-project.net/), el tema se
sonará bastante, y es el UDP (Protocolo de complica un poquito, pero solo un poquito.
Datagramas de Usuario).
Si estamos descargando un programa llamado officexp.zip (de
Por tanto, UDP es también un protocolo de 650MB) desde 7 usuarios a la vez, este nos llega en trocitos
transporte e, igual que la mayoría de pequeños. Lo importante es que nos lleguen cuanto más trocitos
aplicaciones de comunicaciones utilizan como mejor y en el menor espacio de tiempo. Pero claro, también es
apoyo TCP/IP, también hay varias aplicaciones importante que no perdamos ningún trocito (o después el ZIP
que en lugar de eso utilizan como apoyo nos dará errores).
UDP/IP.

En este caso, podríamos pensar que es mejor utilizar TCP, puesto DOCTOR en un sistema UDP en un mundo P2P :)
que nos asegura que llegan todos los trocitos; pero entonces El doctor (receptor) recibe por megafonía un mensaje (archivo)
estaríamos sobrecargando la red P2P con centenares de peticiones PERO el tipo del megáfono (emisor) es MUY DESPREOCUPADO
de comprobación y la descarga sería muy lenta. ¿Cómo resolvemos y no le importa si el doctor (receptor) recibe o no el mensaje.
esto?
El mensaje (archivo) a transmitir es: PRESÉNTESE
Pues trabajamos con UDP y hacemos que sea el programa P2P INMEDIATAMENTE EN EL QUIRÓFANO.
quien compruebe si faltan trocitos. En caso de faltar algún trozo
se reclama y en caso de no faltar no se reclama. 1.- El tipo del megáfono (emisor) emite la primera palabra
(primera parte del archivo): PRESÉNTESE
PARALELISMO: Por si alguien no lo ha pillado, retomemos el 2.- El doctor (receptor) en teoría recibe la primera palabra
caso del doctor y hagamos un paralelismo con el mundo P2P. (primera parte del archivo): PRESÉNTESE
DOCTOR en un sistema TCP en un mundo P2P :) 3.- El tipo del megáfono (emisor) emite la segunda palabra
El doctor (receptor) recibe por megafonía un mensaje (archivo) (segunda parte del archivo): INMEDIATAMENTE
PERO el tipo del megáfono (emisor) es MUY EXIGENTE y
4.- El doctor (receptor) en teoría recibe la segunda palabra
OBLIGA al doctor (receptor) que confirme la correcta recepción
(segunda parte del archivo): INMEDIATAMENTE
de cada palabra (parte del archivo) que recibe.
5.- Seguiríamos así hasta que el doctor (receptor) en teoría

recibiese la última palabra (último trozo del archivo). En ese
INMEDIATAMENTE EN EL QUIRÓFANO.
momento el doctor (receptor) uniría todas las palabras (trozos
de archivo) obteniendo el mensaje completo (archivo).
1.- El tipo del megáfono (emisor) emite la primera palabra
(primera parte del archivo): PRESÉNTESE
Como podemos ver, la comunicación es mucho más rápida (nos
ahorramos las confirmaciones) pero ¿y si el doctor se ha
2.- El pobre doctor (receptor) va corriendo a un teléfono, llama
perdido alguna palabra?... quizás se ha perdido la palabra
al tipo del megáfono y le dice que ha recibido correctamente la
INMEDIATAMENTE si el doctor estaba tomándose un café
palabra (trozo de archivo): PRESENTESE
quizá prefiere acabárselo antes de acudir al quirófano (y seguro
que su paciente muere desangrado).
3.- El tipo del megáfono (emisor) emite la segunda palabra
(segunda parte del archivo): INMEDIATAMENTE En el caso de emisión de video por Internet en tiempo real ya
hemos dicho que no nos importaba perder unos cuantos frames,
4.- El pobre doctor (receptor) va corriendo a un teléfono, llama pero en el caso del P2P QUEREMOS TODOS los trocitos de
al tipo del megáfono y le dice que ha recibido correctamente la archivo, queremos que el doctor no deje morir a su paciente
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 ¿Cómo lo solucionamos si no queremos utilizar el sistema
TCP?
5.- Y así seguiremos hasta que el doctor (receptor) confirma la
llegada de la última palabra (trozo de archivo) QUIRÓFANO. Tenemos un problema: No queremos sobrecargar la red telefónica
En ese momento el doctor (receptor) une todas las palabras del hospital confirmando cada palabra que recibimos (TCP) pero
(trozos de archivo) y obtiene el mensaje (archivo): PRESÉNTESE queremos asegurarnos de recibir los mensajes completitos. Muy
INMEDIATAMENTE EN EL QUIRÓFANO. bien, pues en este caso tendremos que dotar a los intervinientes
(el Sr. del megáfono y el doctor) de un poquito de inteligencia :)
Como podemos ver, la comunicación es 100% segura, el doctor
confirma la llegada de cada palabra (trozo de archivo); pero han El Sr. del megáfono (software emisor) y el doctor (software
invertido mucho tiempo y muchas llamaditas de confirmación. receptor) se reúnen y después de un buen rato discutiendo el
problema llegan a una solución. Deciden utilizar el sistema UDP

pero cada palabra (trozo de archivo) emitida tendrá estará deberíamos poder olvidar. Una cosa es el tipo de protocolo que
precedida de un número correlativo (número de control). Vamos estamos utilizando para nuestras conexiones (TCP o UDP e
a verlo. incluso ambos a la vez) y sus consecuencias sobre la red y, OTRA
MUY DISTINTA, cómo programamos el software para mejorar
DOCTOR en un sistema UDP en un mundo P2P (con control el rendimiento de dichas conexiones.
añadido).
El doctor (receptor) recibe por megafonía un mensaje (archivo) Hemos visto que las carencias de seguridad del protocolo UDP
con un sistema previamente pactado :) (capa de transporte) han sido "salvadas" gracias a cómo hemos
programado el software (nivel de aplicación).
INMEDIATAMENTE EN EL QUIRÓFANO. PARA LOS QUISQUILLOSOS:
- Si, pero ¿y si el doctor (software receptor) no recibe ninguna
Según han pactado, el mensaje a transmitir será: palabra (trocito de archivo) porque está dormido?
UNOPRESÉNTESE DOSINMEDIATAMENTE TRESEN Pues entonces dotamos de un poco más de inteligencia al programa
CUATROEL CINCOQUIRÓFANO. para que la primera palabra (trocito de archivo) se haga por
TCP (confirmacion aobligatoria) y el resto por UDP. De esta
1.- El tipo del megáfono (emisor) emite la primera palabra forma no se emitirán mas palabras (trocitos de archivo) por
( 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 megafonía hasta que el doctor llame al Sr. del megáfono
confirmando que la recibido la primera palabra.
2.- El doctor (receptor) en teoría 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 - Si, pero ¿y si el doctor (software receptor) no confirma la
recepción de esa primera palabra (trocito de archivo)?
3.- El tipo del megáfono (emisor) emite la segunda palabra Pues hacemos que el Sr. de megafonía (software emisor) envíe
(segunda parte del archivo): DOSINMEDIATAMENTE un mensaje al teléfono móvil del doctor cada 5 minutos durante
2 horas hasta que conteste.
4.- El doctor (receptor) en teoría recibe la segunda palabra
(segunda parte del archivo): DOSINMEDIATAMENTE ¿Y si a pesar de todo no contesta? Pues llamamos a otro doctor
mientras el primero está dormido (en un P2P sería el equivalente
5.- Seguiríamos así hasta que el doctor (receptor) en teoría a servir el archivo a otro cliente mientras el primero pasa a una
recibiese la última palabra (último trozo del archivo). En ese lista de espera :)
momento el doctor (receptor/software receptor) comprobaría que
tiene en su poder las palabras (trozos de archivo) y que no falta La intención de esta extensa nota no es otra que ACERCAR ese
ninguna (se puede comprobar gracias a que tienen números extraño mundo de las capas OSI a la realidad, a programas que
correlativos). utilizamos diariamente y que no tenemos ni idea de cómo funcionan
(por ejemplo la visualización de video en tiempo real y los P2P).
Solo en caso de que faltase alguna palabra (trozo de archivo) el Quizás ahora pensemos un poco más en lo que hay detrás de
doctor llamaría por teléfono al emisor pidiéndole UNICAMENTE esas cosas que utilizamos mecánicamente sin pensar :)
la palabra que le falta.
Como podemos ver, ahora la conexión sigue siendo del tipo UDP Olvidándonos ya de UDP, vamos a ver entonces
(cargamos poco la red); pero gracias a que hemos dotado al Sr. qué es TCP, que es el que más nos interesa.
del megáfono y al doctor (software emisor y receptor) de A diferencia de las comunicaciones no
inteligencia (software), hemos conseguido además bastante orientadas a conexión, las orientadas a
seguridad en la comunicación. conexión son aquellas en las cuales hay un
diálogo directo con el interlocutor. Es decir, no
ACABANDO Y PUNTUALIZANDO: es ningún monólogo que sueltas con la
esperanza de que alguien te escuche, si no
Acabamos de aprender algo importantísimo que ya nunca que es una conversación entre dos o más

interlocutores, donde todos saben en todo necesitarás saber que tu servidor de correo
momento si están siendo escuchados por lo está recibiendo (aunque si llega al buzón
los demás. del destinatario o no es ya un asunto
aparte), si estás en un Chat necesitas saber
Como ejemplo de comunicación orientada que la persona o personas con las que
a conexión tenemos el teléfono, donde en hablas están conectadas en ese momento,
todo momento sabes si la persona con la y leyéndote.
que estás hablando está siguiendo el
diálogo. Por el contrario, cuando hablas Hasta donde la capa IP entiende, sólo
con un contestador automático telefónico, existen sobres que circulan desde una
se trata precisamente de una comunicación dirección de remitente hacia una dirección
no orientada a conexión. de destinatario, pero en ningún momento
existe un diálogo 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 diálogo
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 envíe un sobre a un destinatario,
éste responderá con un nuevo sobre, en
Al hablar por teléfono mantenemos una conversación el que simplemente dirá te he escuchado.
orientada a conexión, donde ambas partes saben que el otro
está escuchando. Gracias a este mecanismo, se puede saber
en todo momento si estamos hablando
solos, o estamos en un diálogo.
3.3. La capa TCP: El tamaño 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
algún momento no se recibe esa
confirmación? Pues el remitente,
Al hablar con un contestador telefónico mantenemos una transcurrido un tiempo en el que no haya
conversación no orientada a conexión, pues no sabemos si recibido confirmación, tendrá que reenviar
la otra parte llegará a escuchar nuestro mensaje.
el paquete y esperar de nuevo la
confirmación, como en el ejemplo de la
La mayoría de servicios de comunicación
megafonía del hospital.
entre máquinas requieren una comunicación
orientada a conexión. Por ejemplo, si estas
Pero, ¿qué ocurre entonces si el mensaje
transfiriendo un fichero, normalmente
de megafonía era muy largo? Imaginemos
necesitarás saber que éste está siendo
que, en lugar de decir: Doctor PyC, acuda
recibido, si estás enviando un e-mail
a la sala de cirugía cardiovascular, el

mensaje dijese: Doctor PyC, acuda a la sala Los buzones de correos tienen un tamaño
de cirugía cardiovascular para atender una limitado y, si bien cada fascículo por separado
urgencia de cardiopatía precarótida en un cabe perfectamente en el buzón, la colección
paciente varón de 70 años, diabético, de entera no cabría en ningún buzón.
grupo sanguíneo AB+, y cuyo color preferido Lo mismo ocurre con las máquinas, que tienen
es el fucsia. Si el Doctor PyC no respondiese un buzón de recepción de un tamaño limitado,
a la primera llamada, habría que repetir toda y hemos de ajustarnos a esas limitaciones
la parrafada de nuevo. tecnológicas.
No tiene sentido soltar parrafadas muy largas 3.4. La capa TCP: Las conexiones
si no tienes la certeza de que estás siendo simultáneas
escuchado. Por eso, si lo que tienes que
transmitir es muy largo, lo mejor es que lo Una de las principales funciones de la capa
vayas contando poco a poco, y esperando la TCP es la de permitir que existan varios
confirmación de que cada parte ha sido diálogos simultáneos entre dos interlocutores.
escuchada. Aquí no recurriré a más metáforas, si no que
será más sencillo verlo directamente en nuestro
Cuando hablamos por teléfono, normalmente campo de trabajo.
no soltamos un rollo de varias horas sin parar
(aunque los hay que si...), si no que estamos Si, por ejemplo, está PyC en MSN chateando
pendientes de que cada cierto tiempo nuestro con Scherzo, y a la vez le está enviando un
sufrido interlocutor nos dé las confirmaciones archivo, ¿no estarán manteniendo dos diálogos
de rigor como si, si, o aja, o que te calles simultáneos? Por un lado, están chateando,
ya. Normalmente, si llevamos dos minutos y por otro lado están enviando un archivo.
seguidos hablando y no hemos escuchado un
aja de nuestro interlocutor, nos mosqueamos Suponiendo que un Chat en MSN funcionase
bastante, y decimos oye, ¿sigues ahí?. mediante una conexión punto a punto (que
no es así, como sabréis si habéis leído mi
En resumen, lo natural a la hora de transmitir artículo sobre MSN, pero imaginaremos que
mucha información es hacerlo en pequeños sí), habría una serie de paquetes cuyo
trozos, cada uno de los cuales confirmará su remitente sería PyC y cuyo destinatario sería
recepción por separado. Scherzo, pero de esos paquetes algunos serían
parte del archivo que se está transfiriendo
Lo mismo ocurre en la comunicación entre (que, por supuesto, estaría partido en trozos,
máquinas. Como TCP se encarga de enviar tal y como vimos en el punto anterior), y otros
confirmaciones, es también el que se encarga serían parte de la conversación que mantienen
de partir los paquetes muy grandes en PyC y Scherzo a través del Chat.
paquetes más pequeños para que estas
confirmaciones puedan llegar poco a poco, y Para permitir que esto ocurra, el protocolo de
no tener que retransmitir todo si no llegase transporte, TCP, tiene que tener algún sistema
la confirmación. que identifique qué paquetes son del Chat, y
qué paquetes son del archivo. Esto lo hace
Esto nos permite, además, adaptarnos a la capacidad
asignando un número a cada diálogo
de nuestro interlocutor. Por ejemplo, si nos
simultáneo y, según el número que haya en
suscribiésemos a una enciclopedia por fascículos,
cada paquete, sabrá si éste forma parte del
y nos enviasen toda la colección de golpe,
probablemente el cartero mandaría al garete a los
archivo, o del Chat.
tíos de Espasa, y les diría que los 20 volúmenes
Pues estos números mágicos de los que estoy hablando
los iba a llevar hasta allí su simpática abuela.
no son otros que los archiconocidos PUERTOS.

Un puerto es un campo del protocolo TCP que se abre esta conexión lo detallaremos a lo
permite identificar el servicio al que va largo del curso, pero no en este artículo.
destinado cada paquete en una conexión De momento lo que sí que sabemos es que
entre dos máquinas. la responsable de abrir y mantener las
conexiones es la capa TCP.
Así, cada vez que una máquina reciba un 3. Scherzo escoge el archivo que
paquete con el número de puerto 25, sabrá quiere bajar: comandos CWD, CDUP,
que ese paquete es un e-mail, cada vez que LIST,... todo esto ya lo vimos en los artículos
reciba un paquete con el número de puerto sobre FTP de la serie RAW, y ahora no nos
21, sabrá que ese paquete es un comando interesa mucho.
de FTP, cada vez que reciba un paquete con 4. Scherzo inicia la transferencia del
el número de puerto 80 sabrá que es una archivo: comandos PORT o PASV, y RETR
conexión Web, etc., etc. o REST. También lo vimos en los artículos
de la serie RAW, y tampoco nos interesa
4. Ejemplo: Enviando un archivo. ahora.
5. El archivo se transfiere desde el
Para recapitular todas las ideas mostradas a servidor de PyC hacia el cliente de
lo largo del artículo, termino con un ejemplo Scherzo: Aquí unos enanitos se encargan
bastante completo que muestra paso a paso de llevar el archivo de una máquina a otra,
el envío de un archivo de PyC a Scherzo. cargando los datos en sacos que llevan a
la espalda. Pero... ¡espera! ¡Si esto no es
Estad muy atentos a cada paso, porque espero la serie RAW! En la serie RAW no me
que este ejemplo os ayude a comprender quedaba más remedio que deciros estas
mucho mejor todos los conceptos que cosas, porque al llegar a este punto no
necesitareis para seguir el resto del curso. podía daros más detalles, ya que más de
Fijad también vuestra atención en todas las una vez os mencioné que explicar lo que
ilustraciones, pues muestran gráficamente ocurre en estos momentos sería suficiente
toda la secuencia del ejemplo, y además los para llenar no sólo un artículo, si no una
datos que aparezcan en las propias serie entera. ¡Y al fin ha llegado esa serie!
ilustraciones son también fundamentales. Así que esperad unas cuantas líneas, que
enseguida os explico cómo funcionan las
A lo largo de la serie RAW os he explicado ya cosas realmente. Tampoco quiero chafar
varios sistemas de transferencia de archivos la ilusión a nadie, así que si alguien no
(FTP, DCC, MSN,...). En este ejemplo quiere dejar de creer en los enanitos que
usaremos, por ejemplo, una transferencia transportan paquetes de datos, que no siga
por FTP. leyendo! ;-)
6. Finaliza la transferencia del
Antes de nada, vamos a ver cómo sería el archivo: y a otra cosa, mariposa.
proceso si sólo nos fijásemos en la capa de
arriba, es decir, en la capa sobre la que he ¿Para qué os he mostrado todos estos pasos
ido hablando mes tras mes en la serie RAW. que conocéis ya perfectamente (sobre todo si
habéis seguido la serie RAW)? Pues
1. PyC abre su servidor FTP: pone sencillamente, para que veáis que entre los
un puerto en escucha, gracias a una pasos 5 y 6 ocurren una gran cantidad de
función que da el sistema operativo que cosas que siempre hemos obviado, y que serán
permite a cualquier aplicación realizar las que precisamente detalle en este ejemplo.
estas y otras funciones de TCP/IP.
2. Scherzo abre una conexión con Nos olvidaremos, por tanto, del resto de pasos,
el servidor FTP de PyC: el modo en que y nos centraremos únicamente en lo que ocurre

desde que comienza la transferencia del operativo diciéndole ale, ya está

archivo, hasta que ésta finaliza. transmitido el archivo, o bien cualquier
Algunos conceptos los simplificaré mucho, y error que haya podido ocurrir oye, no he
otros incluso los obviaré, esperando así facilitar podido enviarlo porque el usuario se ha
la comprensión de los conceptos desconectado, etc.
fundamentales, aunque tenga que sacrificar
parte de la verdad. Como esto es todo lo que ve el programa de
FTP, tendremos que descender al oscuro reino
4.1. En el servidor FTP de PyC del sistema operativo para comprender mejor
qué es lo que ocurre desde que se llama a
Empezamos nuestro viaje por el mundo de
esa función hasta que el sistema operativo
los enanitos en el reino que nosotros
avisa de que el envío ha finalizado.
conocemos, que es el del servidor FTP de
PyC.
4.2. En el Sistema Operativo de
El servidor lo único que sabe es que tiene un PyC: La capa TCP.
archivo de 4500 KB que tiene que enviar al
usuario Scherzo, que previamente hizo un Lo primero que hace la capa TCP nada más
login en el servidor. ver el archivo de 4500KB es decir: buf, este
chorizo es demasiado largo. ¿Qué criterio
El que programó el servidor FTP no tenía ni utiliza TCP para decidir si algo es demasiado
idea de TCP/IP, así que lo único que sabía era largo? Es algo que veremos a lo largo del
que el no tenía más que dar una orden al curso, pero de momento nos basta con saber
sistema operativo, y éste se encargaría de que el tamaño máximo de un paquete es algo
hacer todo el trabajo sucio. Así que el software que determinó previamente la capa TCP según
del servidor simplemente llama a una función las limitaciones de la red.
mágica del sistema operativo, parecida a esta:
Supongamos que ha determinado que el
EnviaFichero (fichero.doc, usuario)
tamaño máximo de paquete son 1500KB.
Donde fichero.doc es el nombre del archivo Tendrá que coger el archivo y partirlo en tres
que quiere enviar, y usuario es una variable trozos, cada uno de 1500KB.
que contiene un número 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 números mágicos 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
A cada trozo le asigna un número que
éste ya sabrá perfectamente lo que hacer con
determina la secuencia en la que han de unirse
él.
de nuevo los trozos. A este número se le llama
precisamente número de secuencia.
Una vez que el programa FTP llama a esta
función mágica del sistema operativo, lo
Una peculiaridad del número de secuencia es
próximo que verá será la respuesta del sistema
que no se numera según el número de trozo,

si no según el número de byte del archivo en La capa TCP ya ha terminado su trabajo inicial,
el que empieza ese trozo. Así, el primer trozo y de momento se puede relajar un poco
tendrá un número de secuencia 0, el segundo mandando los bloques a la capa IP, que sabrá
un número de secuencia 1500, y el tercero qué hacer con ellos a continuación. Pero, a
un número de secuencia 3000. diferencia del programa de FTP, la capa TCP
no se puede dormir en los laureles esperando
Pero, ¿es éste el único dato que ha de asignar a que la transferencia del archivo termine, si
la capa TCP a cada trozo? Pues me temo que no que tendrá que seguir trabajando más
n o, ya q u e s a b e m o s b i e n q u e l a s adelante, tal y como iremos viendo.
responsabilidades de esta capa van más allá
de simplemente partir los paquetes en bloques. 4.3. En el sistema operativo de
Hablamos también de los números de puerto, PyC: La capa IP.
así que tendrá que añadir a cada trozo los
dos puertos implicados en la conexión. En cuanto TCP llama a la capa IP, y le pasa
¿Adivináis cuáles son estos puertos? los 3 bloques, ésta se pone en marcha. Su
labor principal consiste en añadir a cada bloque
Je, je... era una pregunta con trampa. Si
las direcciones IP de PyC y Scherzo para que,
habéis pensado que uno de los puertos era
el 21, puerto asignado al servicio FTP, os una vez que los bloques estén flotando por el
habéis equivocado, aunque he de reconocer ciberespacio, todos aquellos mediadores por
que lo he preguntado a mala leche. 0:-) los que pasen sepan dónde llevarlos.
Si repasáis mejor el artículo de la serie RAW

La dirección IP de PyC la conoce, por supuesto,
sobre FTP veréis que el puerto 21 sólo se
utiliza para enviar comandos al servidor, pero el propio sistema operativo de PyC (bien
no para la transferencia de archivos. Para porque la introdujimos nosotros manualmente
ésta se utiliza otro puerto que es acordado al configurar nuestra LAN, bien porque el
previamente mediante el comando PORT o sistema la asignó automáticamente mediante
el comando PASV. Para los que no sepáis de DHCP, o bien porque se nos asignó una IP
qué hablo porque no conocéis el protocolo
dinámica al conectar con nuestro ISP).
FTP, olvidaos de todo esto y quedaos
simplemente con la idea de que tanto el
puerto de PyC (origen) como el puerto de La dirección IP de Scherzo la puede obtener
Scherzo (destino) son números que han el sistema a partir de la variable usuario ya
acordado previamente, por ejemplo, el 20 y que, cuando Scherzo conectó con el programa
el 3600.
FTP, el sistema operativo automáticamente
Por tanto, si añadimos a cada trozo los tres asoció la IP de Scherzo a esa variable.
numerajos que hemos dicho (numero de
secuencia, puerto de origen, y puerto de ¿Tiene que añadir algo más la capa IP? ¡Pues
destino) nos queda el siguiente escenario: si! Vamos a ver. ¿Para qué servía en la capa
TCP meter los números de puerto en cada
bloque? Si no metiésemos los números de
puerto, cuando el bloque llegase al destinatario
(Scherzo) éste no sabría qué hacer con él.
Scherzo probablemente tendría abiertas en
ese momento varias aplicaciones de
comunicaciones, y cada paquete que le llegase
tendría que indicar de algún modo a cuál de
todas esas aplicaciones iba dirigido.
Los tres paquetes que forman el archivo, con sus
correspondientes cabeceras TCP. Fijaos bien en los campos
que forman la cabecera. Pues algo parecido ocurre con la capa IP. Como
ya vimos, no sólo existe TCP como protocolo

de transporte, si no también otros como UDP. 4.4. En el sistema operativo de

Además, existen otra serie de protocolos que PyC: la capa de enlace.
funcionan sobre IP, como ICMP, pero de eso
no vamos a hablar ahora. Hasta el momento hemos hablado poco de
esta capa para evitar liaros más. Si bien las
Lo que ahora nos interesa es que de alguna capas TCP e IP son iguales para todos los
manera el bloque tiene que decir de alguna sistemas, la capa de enlace puede variar
forma que es un bloque TCP, y no UDP. Para totalmente de un sistema a otro. Es aquí donde
ello, la capa IP asigna mete un numerajo en se encuentran las diferencias entre una
cada bloque que identifica el protocolo de conexión por módem, una conexión ADSL, y
transporte desde el que le llegó ese bloque. cualquier otro tipo de conexión.
Es decir, la capa de enlace depende de la

Como, en este caso, los bloques le llegaron tecnología utilizada para crear el enlace entre
a IP desde la capa TCP, la capa IP meterá en nuestra máquina e Internet.
cada bloque un número que dirá que ése es
un bloque TCP. Vamos a suponer que el enlace que tiene PyC
es el más común hoy día, es decir, un enlace
Por tanto, así nos queda el escenario ahora: Ethernet. Éste es el que usamos si tenemos
una tarjeta de red (bien con ADSL, o con
cable, o con otras tecnologías).
Supongamos que PyC tiene en su casa una
configuración muy habitual hoy día, que es la
de una conexión a Internet a través de un
router ADSL, con una pequeña LAN (red local)
en casa compuesta por dos ordenadores: el
suyo, y el de su hermano.
Los tres paquetes que forman el archivo, con sus cabeceras

TCP e IP. Como podéis observar, la cabecera IP es igual
para los tres paquetes.
Una vez que los paquetes ya están listos, se

los manda a la capa de abajo, la capa de Esquema de la LAN de PyC, con las IPs de cada elemento.
enlace, de la que hemos hablado poco hasta El router ADSL tiene 2 IPs: 192.168.1.1 para la LAN, y
el momento.
217.15.22.1 de cara a Internet.

Como vemos en la ilustración, la única como para que nunca tengan que repetirse.
máquina que se comunica directamente con Estas direcciones, más largas que las
Internet es el router ADSL, y es éste el que direcciones IP, constan de 48 bits, por lo que
tiene que encargarse de llevar todos los teóricamente permiten identificar casi 300
paquetes de PyC y de su hermano a Internet. Billones de dispositivos Ethernet diferentes.
Para ello, ambos ordenadores están Entonces, ¿qué datos añadirá el nivel Ethernet
conectados al router mediante un cable de a cada bloque que queremos transmitir? Pues,
red (si el router sólo tiene un conector RJ-45 al igual que la capa IP, añadirá una dirección
tendría que haber en medio un switch, pero MAC de origen, y una dirección MAC de destino.
esa cuestión la obviamos por salirse del tema). Y, también igual que en la capa IP, tendrá que
añadir un dato más, que es un identificador
El problema aquí es que la comunicación en de la capa superior que le pasó los bloques,
Ethernet es de tipo broadcast. es decir, en este caso la capa IP.
Esto significa que lo que circula por el cable

llega a todas las máquinas que estén
conectadas al mismo, y hay que idear alguna
forma de hacer que sólo atienda a los datos
la máquina 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 sólo
hay que engañar a la tarjeta de red para
que te muestre todos los datos que hay en
el cable, y no sólo los que van dirigidos a ella.
Pero lo que nos interesa aquí es conocer el Los tres paquetes que forman el archivo, con sus cabeceras TCP,
mecanismo utilizado para distinguir unas IP, y Ethernet. En ésta la MAC de origen será la de PyC, y la
máquinas de otras en una LAN. MAC de destino la del router ADSL de PyC, que será el próximo
punto con el que habrá que enlazar la comunicación. El ordenador
Como podéis imaginar, esto se consigue de PyC conoce la dirección MAC del router gracias al protocolo
asignando un número diferente a cada tarjeta ARP, pero eso se sale del tema del artículo.
de red de las máquinas conectadas a la LAN.
Este número es único en el mundo para cada
tarjeta de red.
! ¿No sabes...
Los fabricantes de dispositivos Ethernet tienen
un acuerdo para que nunca se fabriquen dos ¿No sabes la MAC de tu tarjeta de Red? ¿de verdad?...
tarjetas de red con el mismo número. Este
bueno, bueno tendrías que haber leído los anteriores
número mágico es precisamente la famosa
números de esta revista :)
dirección MAC (comúnmente conocida
como dirección física) de la que
probablemente habréis oído hablar.
Abre una ventana de comandos (Menú inicio --> Todos
los Programas --> Accesorios --> Símbolo del sistema).
Al haber una MAC diferente por cada Escribe IPCONFIG /ALL. Pulsa enter y ZAS!!! Ahí tienes
dispositivo Ethernet del mundo, las direcciones la MAC de tu/s tarjetas Ethernet (Tarjetas de Red).
MAC tienen que ser lo suficientemente grandes

El primer paquete al fin sale del ordenador de PyC, hacia el

router ADSL.
4.6. En el router ADSL de PyC:

Las capas física y de enlace
Una vez que los datos llegan al router, éste

En este caso podemos ver 2 tarjetas de red y cada una tiene detectará mediante hardware la presencia de
una MAC (dirección física). La tarjeta D-Link AirPlus datos en el cable, y enviará los bloques
tiene la MAC 00-80-C8-1E-4F-0C y la Realtek tiene la recibidos a su capa de nivel de enlace.
MAC 00-05-1C-9A-84-B1 Aquí es importante tener en cuenta que el
nivel de enlace del router debe ser también
Como apunte interesante, aclarar que aunque la MAC es Ethernet. De no ser así, la comunicación entre
única en el mundo, existen Tarjetas de Red especiales y PyC y su router sería imposible.
otros dispositivos (como algunos routers) que permiten
"falsear" la MAC (poner la MAC que tu quieras ;). La Por tanto, una vez que los datos llegan a la
mayoría de técnicos de Red tienen entre sus "herramientas capa Ethernet del router, éste analiza la
cabecera Ethernet del paquete.
de trabajo" una de estas tarjetas para comprobar el buen
funcionamiento de los Sistema de Red.
Al analizar la cabecera, descubre que la
dirección MAC de destino era la suya, por lo
que decide continuar el procesamiento del
4.5. En la tarjeta de red de PyC: paquete, ya que le corresponde a él hacerlo.
La capa física Para poder continuar el procesamiento debe
saber a qué capa pasarle la pelota. Para ello
Una vez que el nivel de enlace ya ha hecho analiza la cabecera Ethernet del paquete y
lo que tenía que hacer con los bloques, no descubre la capa de encima tiene que ser la
tiene más que acceder ya directamente al capa IP. Así, el router elimina la cabecera
hardware, en este caso la tarjeta de red, y Ethernet del paquete (ya que la capa IP es
los datos salen al fin de la máquina de PyC. incapaz de comprenderla), y pasa el resto del
paquete a la capa IP.
Por supuesto, existen muchas tecnologías
diferentes en la capa física: RJ-45 (la que
casi todos tenemos), coaxial, inalámbricas
(muy de moda últimamente), etc., etc.
Una vez lanzados los paquetes a través del

cable que une la máquina de PyC con el router
ADSL estos, por supuesto, llegarán hasta el El router analiza la cabecera Ethernet, comprobando que la
router. MAC de destino es la suya, y pasa el resto del paquete (sin la
cabecera Ethernet) a la capa IP.

4.7. En el router ADSL de PyC: Esto es debido a que la conexión entre el

router ADSL y el router del ISP no es mediante
La capa IP un enlace Ethernet, si no mediante una
tecnología de enlace ADSL.
Una vez que la capa IP recibe el paquete,
analiza su cabecera. Ahí encuentra la dirección No vamos a detallar aquí más capas de enlace,
o buen barullo montaríamos, así que nos
IP de destino, que es la de Scherzo. El router
imaginaremos que esta capa añadirá sus
tiene configurada internamente una tabla propias direcciones y su identificador de la
parecida a esta: capa superior, y enviará el paquete a la capa
física, que esta vez no será el cable Ethernet,
si no el cable telefónico que va hacia el splitter.
El paquete ya puede salir a Internet, una vez reconstruidas las

cabeceras IP y de enlace. La cabecera TCP y los datos del
Lo que vemos en esta tabla es que el router archivo (zona azul del paquete) se han mantenido intactas.
ADSL enviará al router de su ISP cualquier
paquete que tenga como IP de destino una 4.9. En el router del ISP de PyC
que no pertenezca a la LAN de PyC.
Como la dirección IP de Scherzo no es una Una vez que el paquete llega al router del ISP,
de las de la LAN de PyC, el paquete será éste repetirá el proceso de recoger el paquete,
analizar desde la capa de enlace si va dirigido
enviado al router del ISP de PyC.
a él, pasarlo a la capa IP, mirar su tabla de
encaminamiento interna, y decidir a qué
Una vez encontrado el siguiente mediador al mediador enviar el paquete a continuación.
que tiene que enviar el paquete, el trabajo
del router ADSL termina aquí. No le interesa
para nada lo que haya dentro del paquete, Imaginemos que ésta es una parte de la tabla
es decir, la cabecera TCP, y los datos del de encaminamiento de este router:
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.
En función 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 físico adecuado.
El router modifica la cabecera IP, sustituyendo la IP de LAN
de PyC por la IP pública para que pueda salir ya al resto de 4.10. Flotando en el ciberespacio
la red Internet. Ya explicaremos esto mejor a lo largo del curso.
Este proceso de saltar de un router a otro

4.8. En el router adsl de PyC: De buscando un camino que llegue hasta Scherzo
puede constar de muchos pasos. Si queréis
nuevo en la capa de enlace.
hacer la prueba vosotros mismos, tenéis un
Pero... ¡Sorpresa! Con quien ha contactado la capa comando en vuestro sistema que os permite
IP del router no es con la capa Ethernet, si no con ver por qué routers van pasando vuestros
otra capa de enlace diferente!! paquetes al enviarlos a un destino concreto.

Ya os explicaré cómo funciona internamente IP de LAN y por su dirección MAC. El cómo

este comando, pero de momento haced la sabe el router a qué máquina enviar el paquete
prueba en una ventana MS-DOS (Ventana de se sale ya del tema que puedo abarcar por
Comandos), o una consola Linux: hoy, así que nos creeremos que sabe dirigir
el paquete a su destino dentro de la LAN.
tracert www.google.com
Para ello, construye una nueva cabecera
Cada línea es uno de los routers que forman Ethernet (capa de enlace) que tiene como
el camino entre vosotros y la Web de Google. dirección MAC de destino la dirección MAC de
Scherzo.
En cada uno de estos routers se repetirá todo
el proceso de analizar el paquete hasta la 4.12. En el PC de Scherzo: la capa
capa IP, e ir relanzándolo por los distintos Ethernet.
cables que forman la auténtica telaraña de
Internet. Una vez que el paquete llega a Scherzo, su
tarjeta de red empieza analizando la capa de
enlace (Ethernet) y, al ver que la dirección
MAC de destino es la suya, sabe que el paquete
es para él. A continuación, 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
Una vez analizada la cabecera Ethernet, se elimina, y se pasa
momento no vamos a entrar en tanto detalle, el resto del paquete a la capa IP.
que me falta ya espacio. ;-)
4.11. En el router ADSL de 4.13. En el sistema operativo de

Scherzo Scherzo: la capa IP
¡Al fin el paquete llegó hasta el último router La capa IP de Scherzo analizará ahora no sólo
del camino! Este, por supuesto, es el router la IP de destino (que es la de Scherzo), si no también
ADSL de Scherzo. Éste analizará el paquete, la de origen (que es la de PyC), ya que tendrá que
y verá que en la capa IP tiene como dirección enviar sus respuestas a esa dirección. Una vez que
IP de destino la IP de Scherzo, así que ahora se queda con estos dos datos, manda el paquete
sólo le falta saber a cuál de los PCs de la LAN a la capa superior que, según la cabecera IP, es la
de Scherzo enviarlo. capa TCP.
En todos los saltos que ha ido dando el paquete de
un router a otro, ninguno ha analizado su cabecera
Todos los PCs de la LAN de Scherzo comparten
TCP, ya que esto es sólo responsabilidad del
una misma IP de cara a Internet, que es la
destinatario final (Scherzo).
IP del router, y éste los diferencia sólo por su

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 El sistema de Scherzo construye un nuevo paquete para indicar
del paquete a la capa TCP.
a PyC que recibió el suyo. La cabecera TCP de este nuevo
paquete constará de un campo ACK con el mismo valor que el
número de secuencia del paquete al que quiere responder, e
4.14. En el sistema operativo de intercambiará los puertos de origen y de destino. El contenido
Scherzo: la capa TCP del paquete (zona azul) estará vacío, ya que lo único importante
aquí son las cabeceras.
La capa TCP de Scherzo cogerá el paquete,
y verá que no es un paquete completo, si no
sólo un trozo (recordemos que el archivo se
partió en 3 trozos en la capa TCP de PyC). 4.15. En el sistema operativo de
Scherzo: de vuelta en la capa IP
La capa TCP de Scherzo tiene ahora dos
responsabilidades: responder a PyC diciéndole Esta cabecera la pasaremos a la capa IP, que
que ha recibido el primer trozo, y mandar el conoce la IP de PyC, por lo que construye una
paquete a la capa de arriba, es decir, a la cabecera IP adecuada para ese paquete:
aplicación 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
En la cabecera IP del nuevo paquete también se intercambian
lo que comprende la aplicación de PyC. La las IPs de origen y de destino.
capa TCP esperará a tener el resto de trozos
del archivo para poder reconstruirlo en el
orden adecuado gracias a los números de 4.16. ¡Vamos pa atrás!
secuencia.
Con respecto al primer punto, la capa TCP de Y así continúa el proceso, llevando el nuevo
Scherzo tiene que avisar a PyC de que ha paquete de vuelta por el camino inverso al
recibido el primer trozo, así que comienza la que siguió el paquete de PyC, hasta que el
construcción de un paquete totalmente nuevo. nuevo paquete llegue a PyC, éste analice su
cabecera TCP, descubra que el primer paquete
Este paquete simplemente tendrá un aviso que envió llegó con éxito a su destino, y se
del tipo oye, que te estoy escuchando, y he despreocupe así ya al fin del paquete de marras.
recibido ese paquete. Para ello, tiene una
cabecera TCP especial que incluye, además Normalmente, no esperará a que Scherzo le vaya
del aviso de que está escuchando, un dato avisando de que recibe cada paquete, si no que
enviará varios de golpe y, sólo si no recibe alguna
que es el último byte recibido del archivo. de las respuestas, entonces reenviará aquel o
Como hemos recibido de momento sólo el aquellos de los que no ha recibido respuesta.

Por tanto, es probable que para cuando PyC 4.17. ¡Conseguido!

haya recibido la primera respuesta de Scherzo,
ya haya enviado también los otros dos Una vez que Scherzo tiene ya los tres trozos
paquetes que forman el archivo, ante los del archivo, ya no tiene más que unirlos en el
cuales también esperará la respuesta de orden adecuado, el cual conoce gracias al
Scherzo. número de secuencia de cada trozo,
reconstruyendo así el archivo original, y
mandándolo a la aplicación de FTP de Scherzo
sin que ésta tenga ni idea de cómo ha llegado
hasta allí ese archivo, confiando en que unos
enanitos mágicos se habrán encargado del
trabajo sucio. ;-)
PyC envía los tres paquetes y espera un tiempo razonable a Gracias al número de secuencia de cada paquete se puede
que le llegue la respuesta (ACK) de Scherzo diciendo que ha reconstruir el archivo original, uniendo cada fragmento en el
recibido cada uno de los paquetes punto (posición en bytes) indicado por el número de secuencia.
Autor: PyC (Lco) Ilustraciones: Adhara (Lco)
¿QUIERES COLABORAR CON PC PASO A PASO?

PC PASO A PASO busca personas que posean conocimientos de
informática y deseen publicar sus trabajos.
SABEMOS que muchas personas (quizás tu eres una de ellas) han creado
textos y cursos para consumo propio o de unos pocos.
SABEMOS que muchas personas tienen inquietudes periodísticas 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 verán la luz.
PC PASO A PASO desea contactar contigo!

NOSOTROS PODEMOS PUBLICAR TU OBRA!!!
SI DESEAS MÁS INFORMACIÓN, envíanos 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 DATAGRAMAS 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. INTRODUCCIÓN el protocolo UDP, pero en futuras lecciones

exprimiremos al máximo las herramientas
Espero que no os perdieseis el primer artículo para hacer maravillas con las demás capas de
del curso de TCP/IP (Transmisión Control protocolos: TCP, IP, ARP (Address Resolution
Protocol / Internet Protocol --- Protocolo de Protocol --- Protocolo de Resolución de
Control de Transmisión / Protocolo de Direcciones), etc.
Internet), porque voy a asumir que habéis Empezaré explicando a grandes rasgos el
comprendido a grandes rasgos el concepto mecanismo de transporte de un paquete UDP
de capas de protocolos, y el mecanismo básico a través de Internet para luego detallar las
de transporte de paquetes de datos a través cabeceras UDP y, por último, veremos todo
de Internet (o cualquier otra red TCP/IP). esto de forma práctica utilizando unas
herramientas que nos permiten construir
! NOTA DE PC PASO A PASO / HXC

paquetes UDP desde cero (los llamados raw
sockets).
Para todos aquellos que no tienen la primera entrega del Pero, antes de empezar, he de aclararos un
curso de TCP / IP publicada en el número 17 de PC PASO asunto. Supongo que algunos de vosotros os
preguntareis qué ha pasado con la serie RAW.
A PASO, hemos decidido pasarla a formato PDF y liberarla
Mis intenciones no eran de ninguna manera
en la Web de la revista (www.hackxcrack.com).
sustituir la serie RAW por el curso de TCP/IP,
si no desarrollar ambos en paralelo. Pero es
También aprovechamos esta nota para indicar
increíble de qué manera pueden conspirar
a nuestros lectores que todos los artículos juntas las circunstancias de la vida para
liberados y los programas que mencionamos cambiar por completo tu rumbo cuando menos
en los artículos están disponibles en la sección te lo esperas. En poco más de un mes me han
ARTÍCULOS LIBERADOS Y DESCARGAS de la surgido una serie de problemas de todo tipo
Web. (familiares, personales, de salud, laborales,
y académicos) por los cuales ahora (y sin
Para esta primera lección he escogido un plazo definido) dispongo de muchísimo menos
protocolo muy sencillo, el protocolo UDP (User tiempo.
Datagram Protocol --- Protocolo de He barajado un poco mis posibilidades, y creo
Datagramas de Usuario), para así poder que lo que puedo permitirme de momento es
extenderme más en explicaros algunas continuar sólo con el curso de TCP/IP, aunque
herramientas que nos pueden ser útiles a lo no descarto publicar algún otro artículo de la
largo de todo el curso. De momento, estas serie RAW algún mes que consiga juntar algo
herramientas las utilizaremos para manejar más de tiempo. Con esto lo que os quiero

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 protocolo DNS. Vamos a utilizar este protocolo
a la serie RAW, pero que haré lo que esté en como ejemplo para ver qué ocurre desde que
mi mano para que no termine aquí, aunque un cliente solicita una consulta DNS a un
haya que avanzar ahora mucho más despacio. servidor, hasta que éste cliente recibe la
respuesta pertinente. Os aconsejo que leáis
Gracias por vuestra comprensión. ;-) el artículo sobre DNS de la serie RAW, que se
encuentra en el número 14 de la revista,
! NOTA EDITORIAL aunque voy a empezar haciendo una
introducción sobre este protocolo.
Para los nuevos lectores, simplemente decir que la serie

de artículos denominada SERIE RAW ha estado presente
en casi todos los números de esta publicación y ha ! NOTA DE PC PASO A PASO / HXC:
constituido uno de los pilares de la misma.
El artículo SERIE RAW: DNS mencionado por el autor ha
La Serie RAW ya nos ha aportado conocimientos sobre los sido liberado y está disponible en nuestra Web:
Protocolos más importantes y desde hace mucho tiempo www.hackxcrack.com
se nos ha reclamado el inicio de un curso de TCP / IP.
Finalmente, desde el anterior número 17 por fin ese curso
ha llegado. 2.1. LAS CAPAS DE UDP/IP
Tal y como nos describe el autor, esperamos poder hacer Os recuerdo que el protocolo DNS es el que
más entregas de la Serie Raw en futuros números, pero de nos permite utilizar las famosas URLs en lugar
forma más dilatada en el tiempo. Mientras tanto disfrutemos de direcciones IP. Es decir, nos permite escribir
de este excelente curso de TCP / IP, una serie de artículos en nuestro navegador http://www.google.com
ampliamente reclamada y esperada por nuestros lectores. en lugar de tener que escribir
http://216.239.39.99, que es la dirección IP
de Google.
2. FUNCIONAMIENTO DEL Para conseguir esto, existen repartidos por el

PROTOCOLO UDP mundo una serie de servidores encargados
de traducir URLs a IPs, e IPs a URLs. Nuestros
PCs se comunicarán con alguno de estos
Los que os perdisteis la introducción de este
servidores cada vez que quieran utilizar una
curso no tenéis que preocuparos, ya que este
URL, para obtener así su IP correspondiente.
primer punto resume en cierto modo lo que
Esta comunicación se lleva a cabo a través
expliqué entonces. Aún así, os recomiendo
del protocolo DNS.
que leáis la introducción, ya que aquí voy a
resumir en un par de páginas lo que allí
Cuando escribimos en nuestro navegador una
explicaba en más de 20 páginas.
URL, por ejemplo http://neworder.box.sk,
nuestro sistema enviará una consulta DNS a
Para los que sí que leísteis la introducción,
un servidor, indicando en la consulta el nombre
este punto creo que os puede ayudar a aclarar
que desea traducir (en este caso
las ideas a modo de resumen.
neworder.box.sk, ya que el prefijo http:// es
sólo una indicación al navegador sobre el
A lo largo de la serie RAW os expliqué varios
protocolo a utilizar, pero no forma parte del
protocolos que funcionaban sobre TCP, pero
nombre que deseamos traducir).
sólo uno que funcionase sobre UDP: el

En segundo lugar, sabiendo que en Internet

todas las máquinas están conectadas entre sí
mediante una compleja red de cables y
conexiones inalámbricas, es lógico pensar que
será necesario conocer el camino a recorrer
en toda esa maraña de cables para enlazar
ambas máquinas entre sí.
En tercer lugar, el cliente necesitará conocer

la dirección IP del servidor DNS, ya que sólo
conociendo la dirección IP de una máquina
El servidor DNS nos enviará una respuesta puedes acceder a ella a través de Internet.
que contendrá la IP correspondiente a ese
nombre. En cuarto lugar, tiene que existir algún
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 podría ser al mismo
tiempo un servidor Web, y un servidor de
correo electrónico. Por tanto, tiene que existir
un mecanismo que le permita distinguir qué
clientes solicitan servicios DNS, cuáles
solicitan servicios Web, y cuáles solicitan
servicios de correo eletrónico.
Gracias a esto, a continuación nuestro A grandes rasgos, son cuatro los problemas
navegador podrá acceder a la máquina que que hemos encontrado para conseguir llevar
contiene la página Web que deseamos visitar, a cabo esta comunicación. Y, por supuesto,
ya que sólo puede existir una comunicación no es coincidencia que sean cuatro las capas
directa entre dos máquinas si cada una conoce de protocolos utilizadas en una comunicación
la dirección IP de la otra. UDP: capa física, capa de enlace, capa de
red, y capa de transporte.
Ahora vamos a pensar un poco en cómo se
podría conseguir todo este mecanismo del Si no fuese gracias a la existencia de estas 4
DNS, en el cual un cliente solicita un nombre capas diferenciadas, el protocolo DNS debería
a un servidor, y el servidor le responde con encargarse por sí sólo de solucionar todos
la IP correspondiente. ¿Qué problemas se nos estos problemas. Es decir, el protocolo DNS
presentan a la hora de llevar a cabo este debería tener sus propias conexiones físicas
proceso aparentemente tan sencillo? Pensadlo entre máquinas, sus mecanismos para
un poco, y después mirad la lista de problemas encontrar un camino entre todas las máquinas
a salvar que os pongo a continuación, para que están conectadas simultáneamente, sus
ver si habéis llegado a las mismas propias direcciones IP, y sus propios
conclusiones: mecanismos para diferenciarse de
otros servicios (como la Web o el correo
En primer lugar, por supuesto, hay que electrónico).
conseguir que ambas máquinas (cliente y
Esto convertiría al aparentemente sencillo
servidor) tengan una conexión física, ya
protocolo DNS en un sistema de una
sea por cables, por radio, o por cualquier otro
complejidad inabarcable, y lo mismo ocurriría
medio físico que les permita establecer una
con cualquier otro protocolo que tuviese que
comunicación bidireccional.

lidiar él solito con todos los problemas de origen, en cambio, servirá para que el
existentes en una comunicación. servidor pueda responder a nuestra consulta,
utilizando como puerto de destino el que para
Vamos a ver entonces cómo se reparte el 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 .
trabajo de la comunicación para permitir que
En resumen, lo que el protocolo UDP ha
el protocolo DNS se abstraiga de todo lo que
conseguido es identificar una comunicación
no sea su misión directa.
entre dos máquinas, entre las cuales podría
haber simultáneamente varias comunicaciones
Empezamos escribiendo una url en nuestro
establecidas.
navegador:
http://neworder.box.sk/home.html Lo que hace UDP es envolver el paquete con
una pequeña cabecera que añade la
En primer lugar, nuestro navegador quitará información necesaria, es decir, los puertos.
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.
Y ahí termina la responsabilidad del protocolo El trabajo de UDP ya ha terminado, y

DNS, ya que su única función consiste en tiene que pasar el paquete a otro protocolo
enviar consultas de nombres para recibir para que se encargue del resto de
direcciones IP en respuesta. Por tanto, nuestro problemas de comunicación. Concretamente,
sistema pasará ahora la bola a otro protocolo, el próximo protocolo tendrá que solucionar
que será el encargado del transporte del el problema de identificar a dos máquinas
paquete DNS. (cliente y servidor) dentro de los millones que
hay en toda la red Internet. En este caso,
Existen varios protocolos de transporte, el protocolo de red utilizado será el
aunque los más importantes son TCP y UDP. protocolo IP.
En este caso, el protocolo de transporte Este protocolo se encargará de asignar las

utilizado será UDP, así que el sistema pasará direcciones IP al paquete: la de origen será
el paquete DNS al protocolo UDP para que la nuestra, y la de destino será la del
éste realice su función, que consiste servidor DNS. Igual que sólo podemos llamar
básicamente en marcar el paquete con un a una persona por teléfono si marcamos su
puerto de origen y otro de destino. número, sólo podremos acceder a una
máquina de Internet si marcamos su
Según el puerto de destino asignado, la dirección IP.
máquina que reciba el paquete (el servidor
DNS) podrá saber a qué servicio está El protocolo IP, por tanto, añade al paquete
destinado. una nueva cabecera, que contendrá las IPs
de origen y de destino, así como una indicación
En este caso, el puerto de destino es el 53 de que el protocolo desde el cual le llegó el
y, por tanto, es un paquete DNS. El puerto paquete fue el protocolo UDP.

mucho más en próximos artículos, por lo que

de momento nos quedamos sólo con la idea
de que el protocolo Ethernet añade su propia
cabecera a todas las que había ya en el
paquete.
El paquete pasa ahora al protocolo Ethernet,

un protocolo que permite encontrar el camino
físico para enlazar dos máquinas (cada una
con una dirección IP que ya conocemos gracias
al protocolo IP).
Hasta ahora ya hemos solucionado los tres
Si cada máquina de Internet tuviese millones últimos problemas que mencioné (volved atrás
de cables para enlazarse con todas y cada y revisad la lista de problemas, y veréis que
una de las demás máquinas conectadas a la en efecto están solucionados), así que sólo
red, no sería necesario el uso de protocolos nos queda el primer problema: la conexión
de enlace. Pero, al estar en Internet todo física. La solución a este problema es bien
conectado con todo, necesitamos un sencilla: ¡enchufa el cable del módem, porque
mecanismo para encontrar el camino entre si no, por mucho protocolo que tengas seguro
dos máquinas, aún conociendo las direcciones que no vas a poder enviar ninguna consulta
que las identifican (direcciones IP). DNS! :-P
Exactamente lo mismo ocurre en el teléfono, Una vez que nuestro paquete está ya circulando
lo cual podemos ver claramente si recordamos por los cables físicos (u ondas de radio físicas),
a las telefonistas de antaño. Antiguamente terminará llegando hasta el servidor DNS. El
(y hoy también ocurre, pero con la diferencia servidor analizará el paquete, verá que se
de que está automatizado) en el instante en trata de una consulta DNS, y hará lo que tenga
que marcabas un número de teléfono no se que hacer para conseguir el resultado pedido
establecía una comunicación. Para conseguir (explicado en detalle en el artículo sobre DNS
esto hacía falta un procedimiento intermedio, de la serie RAW, en el número 14 de la revista).
que era el de las telefonistas. Las telefonistas
se encargaban de ir conectando y Una vez encontrada la respuesta, tendrá que
desconectando cables en sus paneles para construir un sencillo paquete de respuesta
conseguir enlazar los dos puntos de la DNS que simplemente contendrá la dirección
comunicación. IP pedida como resultado de la traducción del
nombre neworder.box.sk. Este paquete, para
En el caso de Internet, a pesar de lo que os poder circular hasta nosotros de vuelta,
hayan contado vuestros padres, no existe también tendrá que tener sus propias
una raza de enanitos encargada de conectar cabeceras UDP, IP, y Ethernet.
y desconectar cables, así que todo esto ocurre
El paquete completo (con las cabeceras) de
de forma automática y virtual, es decir, no
respuesta podría ser parecido a este:
se conecta ni se desconecta nada físicamente,
si no que simplemente se establecen
RESPUESTA DNS:
conexiones lógicas.
IP = 66.250.131.132
Para establecer estas conexiones se utilizan

CABECERA UDP:
otro tipo de direcciones sobre las que ya hablé
Puerto origen = 53
un poco en el artículo anterior, y hablaré
Puerto destino = 20

CABECERA IP: quedado muy clara, pero quizá no tenéis tan

IP origen = 215.22.1.13 clara la necesidad de especificar también un
IP destino = 217.12.1.15 puerto de origen.
Protocolo = UDP
Imaginemos que nuestro navegador realiza
CABECERA Ethernet: una consulta DNS con nuestro servidor DNS,
MAC origen = 548F44A5558D pero casi al mismo tiempo nuestro cliente de
MAC destino = 54F566A47F88 correo electrónico también está realizando
Protocolo = IP otra consulta DNS al mismo servidor. No
podemos saber de ninguna manera cuál de
Os recomiendo que volváis atrás para ir las dos respuestas nos llegará antes.
comparando cada campo de la respuesta con
los campos correspondientes en la consulta. Por una parte, si leísteis el artículo sobre DNS
Posiblemente veréis varias cosas que os de la serie RAW, sabréis que el tiempo para
parecerán muy extrañas. Por ejemplo, ¿por procesar una consulta DNS puede variar
qué la IP de destino de la respuesta no es enormemente. Por ejemplo, una traducción
192.168.1.2?Esto ya lo explicaré cuando hable que se encuentre en la cache del servidor DNS
sobre el protocolo IP a lo largo del curso. Y, nos llegará casi al instante, mientras que otra
¿por qué ninguna de las dos direcciones MAC traducción menos afortunada podría requerir
tiene nada que ver con las que había en la establecer varias conexiones con varias
consulta? ¡Un poco de paciencia, por favor! máquinas, desde los servidores raíz, y los
¡Que ya explicaré todo esto a lo largo del servidores del TLD, hasta el último servidor
curso! :-) de la jerarquía DNS. Si no sabéis de qué hablo
no os asustéis, que esto no tiene nada que
2.2. FUNCIONES DE LA CAPA DE ver con UDP, si no con DNS, y no os hace falta
TRANSPORTE UDP conocerlo ahora. :-)
2.2.1. Identificación de La idea con la que os tenéis que quedar es

que de ninguna manera se puede asumir que
conexiones
al hacer dos consultas una detrás de otra, las
Lo importante que tenemos que comprender dos respuestas nos llegarán en el mismo orden.
ahora, una vez hecho este repaso al sistema Por tanto, si el servidor nos envía las dos
de protocolos por capas UDP/IP, es que gracias respuestas, necesitamos de alguna manera
al protocolo UDP se puede identificar una saber cuál de las dos es la que solicitó nuestro
comunicación específica entre dos máquinas, navegador, y cuál es la que solicitó nuestro
gracias a los puertos de origen y de destino. cliente de correo electrónico. ¡De ahí la
necesidad del puerto de origen!
Esto nos permite tener varias conexiones
simultáneas entre dos máquinas (aunque las Por supuesto, si leísteis el artículo sobre DNS
direcciones IP de cada conexión sean las os estaréis preguntando: ¿y qué hay de los
mismas, las conexiones se pueden diferenciar transaction ID? ¡Permiten perfectamente
gracias a los puertos), y también nos permite diferenciar una consulta DNS de cualquier
acceder al mismo servicio en varias máquinas otra! Pues sí, es cierto, pero el caso de DNS
diferentes (podemos, por ejemplo, estar es un poco especial, ya que no es normal que
viendo dos páginas Web de dos servidores los protocolos que utilicen UDP (o TCP) para
diferentes al mismo tiempo). 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 conexión. Si se hizo
Supongo que la necesidad de especificar un así en el caso de DNS no fue por motivos de
puerto de destino en cada paquete os habrá identificar cada conexión, ya que para eso

sobraba con lo que hace UDP, si no por motivos gruñones que se dedican a desconectar cables
de seguridad, como ya vimos al hablar en la de vez en cuando, ocasionando así la pérdida
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 de paquetes.
envenenamiento de DNS.
No cabe duda de que ninguna tecnología es
En la práctica, hay casos en los que el puerto perfecta, y por eso siempre puede haber
de origen es irrelevante, por lo que no siempre pérdidas de datos en cualquier comunicación.
es obligatorio especificarlo. En estos casos, ¿Qué ocurriría, por ejemplo, si no nos llegase
lo que se hace es usar el puerto 0 como la respuesta del servidor DNS, a pesar de que
origen. éste la hubiera enviado? Si, por cualquier
motivo, la respuesta se perdiese por el camino,
no pudiendo llegar hasta nosotros, ¿habría
2.2.2. Corrección en los datos
alguna forma de detectar y solventar esta
Imaginad que por cualquier problema en la situación?
línea los datos llegasen corruptos hasta
nosotros, y uno de los números que forman Analizando el funcionamiento básico del
la IP que hemos solicitado al servidor DNS protocolo UDP, tal y como lo hemos visto,
es incorrecto. no habría ninguna manera. En UDP cada
máquina envía sus paquetes a la red, sin tener
Sería un gran problema no tener una cierta ninguna certeza de si llegarán o no a su
seguridad de que los datos que nos llegan de destino. Una vez que el servidor DNS envíe
un servidor DNS son correctos. Estaríamos su respuesta, se desentenderá del asunto, al
cada dos por tres estableciendo conexiones no tener forma de saber si la respuesta nos
con direcciones IP incorrectas. ha llegado o no.
UDP no puede garantizar que los datos lleguen, Este es el principal problema de los protocolos
pero si que nos da cierta garantía de que, si no orientados a conexión, como es el caso
han llegado, son correctos. Para ello incorpora de UDP. Como ya vimos en el artículo sobre
en su cabecera un dato que no hemos visto DNS, en el caso de TCP esto es muy diferente,
antes (ya que estabamos viéndolo sólo a ya que TCP es un protocolo orientado a
grandes rasgos), que nos permite comprobar conexión. Por cada paquete transmitido en
que los datos son correctos, tal y como TCP es obligatorio que el receptor envíe un
veremos más adelante. acuse de recibo para que el emisor sepa con
certeza que los datos han llegado al destino.
Este problema de la corrección de los datos Esto no es así en UDP.
perfectamente podría haberlo incluido en la
lista de problemas de la comunicación, pero En UDP no hay manera de saber si los datos
no lo hice a propósito para que saliesen justo llegan al destino. Esto es una gran desventaja
cuatro. :-P pero, por otra parte, tiene la gran ventaja de
hacer la comunicación mucho más fluida, al
2.3. LO QUE NO
NOS DA EL no verse interrumpida constantemente por
miles de paquetes de acuse de recibo.
PROTOCOLO UDP FRENTE A TCP
Esta característica convierte a UDP en un
2.3.1. Fiabilidad en la
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
comunicación comunicaciones sencillas (como DNS, o TFTP
(Trivial File Transfer Protocol --- Protocolo
Aunque antes desmentí el mito de los enanitos
Trivial de Transferencia de Ficheros)), y para
telefonistas de Internet, unos enanos que sin
envíos masivos de flujos de datos (como en
duda si que existen en la red son los enanos

transmisiones multimedia de vídeo, audio, 2.3.3.Tratamiento adecuado de

...), pero en un protocolo que de ninguna los paquetes grandes
manera sirve para comunicaciones que
requieren fiabilidad (FTP, IRC, HTTP, ...). Imaginemos que enviamos una consulta de
DNS a un servidor, y éste nos responde, pero
Por ejemplo, ahora que menciono el IRC, su respuesta se ha perdido por el camino. En
imaginemos lo que sería una conversación una situación normal, tras pasar un tiempo
en un chat en el que no tuviésemos la certeza sin recibir la respuesta, volveríamos a
de que lo que decimos vaya a llegar al resto solicitarla, asumiendo que se perdió por el
de interlocutores. Algunas frases se perderían camino. ¡Vaya! Eso sí que es genial. Acabamos
por el camino, y nadie podría saberlo, por lo de solucionar el problema de la fiabilidad en
que muchas conversaciones perderían su la comunicación. ¿O no?...
sentido y, probablemente, se convertirían en
diálogos de besugos (aunque, incluso ¿Que ocurriría si en lugar de ser una simple
utilizando TCP hay gran cantidad de diálogos consulta DNS nuestro paquete fuese una
de besugos en IRC, pero eso más que un solicitud a un servidor FTP para bajarnos un
problema tecnológico es un problema archivo grande (por ejemplo una ISO de
intelectual). 700MB?
2.3.2. Flujo ordenado de datos Si se perdiese el paquete de respuesta, el

servidor tendría que volver a enviar nada
Otro gran problema potencial de UDP es el menos que 700MB! Esto, por supuesto, es
del desorden. En el caso de DNS parece todo una barbaridad, y lo ideal para minimizar este
muy sencillo: una consulta -> una respuesta. tipo de problemas es dividir los paquetes
Pero, ¿qué ocurriría si, por ejemplo, demasiado grandes en paquetes más
intentásemos hacer un chat mediante UDP? pequeños, para que luego estos se unan en
el orden adecuado al llegar al destino, y
Internet es una red increíblemente compleja, reconstruir así el paquete original. Si ha habido
y existen muchos factores que pueden algún fallo tecnológico en un momento dado,
determinar que los paquetes vayan más o normalmente sólo se perderá alguno de los
menos rápidos en cada instante. Esto puede paquetes pequeños, que podrá ser reenviado
dar lugar a situaciones tan extrañas como sin problemas.
que dos paquetes salgan uno tras otro de
una máquina, pero primero llegue al receptor UDP no incorpora ningún mecanismo para
el último que salió. Si no hay un mecanismo partir los paquetes grandes, por lo que tampoco
para controlar el orden en que deben ir los es adecuado para esta clase de
paquetes, en el chat veríamos respuestas a comunicaciones. Quizá ahora os estaréis
preguntas aún no formuladas, monólogos sin preguntando por qué entonces he dicho que
sentido, etc. UDP puede ser adecuado para transmisiones
multimedia donde, sin duda, el flujo de datos
Otros protocolos de transporte, como TCP, sí es enorme.
que incluyen mecanismos para garantizar el
correcto orden de los paquetes; pero no es La cuestión fundamental aquí es que en los
el caso de UDP, por lo que es otro aspecto a contenidos multimedia no es crítica la pérdida
tener en cuenta a la hora de decidir si nuestra de los datos. Por ejemplo, podemos estar
aplicación funcionará mejor sobre un transmitiendo una película a razón de 20
protocolo seguro y robusto como es TCP, o fotogramas por segundo, enviando por ejemplo
sobre un protocolo más fluido como cada fotograma en un paquete independiente.
es UDP. En este caso, la pérdida de un único paquete

no sería en absoluto crítica. Simplemente Como ya hemos explicado los conceptos,

perderíamos un fotograma, y eso sería podemos permitirnos el lujo de poner las
prácticamente imperceptible para el ojo cabeceras sin explicar nada, como hace el RFC :)
humano, y para nada afectaría al espectador
de la película. En cualquier caso, nunca sería
necesario reenviar el paquete.
El tema de la partición de paquetes grandes

es mucho más complejo de lo que puede
parecer en un principio ya que, entre otras
cosas, no sólo es misión 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. ;-)
3. UDP EN DETALLE Esta es la estructura de una cabecera UDP, es

decir, del trozo que se añade a cada paquete
Antes de deciros cuál es el RFC que detalla
para luego pasarlo al protocolo IP, el cual a
el protocolo UDP os tengo que poner sobre
su vez añadirá otro trozo, que se sumará
aviso: podéis asustaros del tamaño del RFC,
también al trozo que luego añadirá el protocolo
así que no tengáis miedo, que yo haré todo
Ethernet.
lo posible por resumiros lo más importante,
como siempre. ;-) En los ejemplos anteriores veíamos sólo dos
campos: puerto de origen, y puerto de destino.
El RFC en cuestión es el RFC 768 (ftp://ftp.rfc- Aquí no sólo vemos todos los campos, si no
editor.org/in-notes/rfc768.txt). Ejem... esto.... que además vemos su longitud.
¿sólo dos páginas? Bueno, quizá he exagerado
un pelín con eso del tamaño. 0;-) Los numerajos que he puesto en la ilustración
encima de la cabecera son el número de bits.
Es decir, el campo Puerto origen abarca
! NOTA DE PC PASO A PASO / HXC 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 número de puertos que
Para los que nunca nos han leido, decir que RFC (Request existen en UDP (y también en TCP, por cierto).
For Comments) son una serie de más de 3000 documentos
Como vemos, el campo Puerto destino abarca
donde se detalla todo lo relacionado con la tecnología de desde el bit 16 hasta el 31, que son otros 16
Internet. bits.
Para los ALERGICOS al inglés, tienes al final de este El campo Tamaño paquete son otros 16 bits,
artículo el RFC en perfecto castellano ;) así como el campo Suma de comprobación.
En el campo DATOS es donde se encuentra

todo lo que ha englobado el paquete UDP. Por
El RFC de UDP está sin duda escrito para ejemplo, en el caso de DNS, la consulta DNS
gente entendida en el tema, por lo que no se estaría en el campo DATOS del paquete UDP.
andan con explicaciones, van directamente Su tamaño ahora puede ser cualquiera, y
al grano, que es la especificación de las precisamente para eso sirve el campo Tamaño
cabeceras UDP. paquete.

Lo he llamado Tamaño paquete porque es Si habéis echado un vistazo a la lista, habréis

un nombre más claro, pero su nombre original visto que el protocolo UDP tiene asignado el
es Length (por si leéis algo sobre el tema y número 17. Por tanto, en la cabecera que
os líais). Este campo indica el número de estamos tratando ahora habría que poner un
bytes que ocupa todo el paquete UDP, 17 en el campo Protocolo.
incluyendo la cabecera. Al ser la cabecera de
un tamaño fijo de 64 bits, es decir, 8 bytes, Con todos estos campos se realiza una
el campo Length será siempre como mínimo operación de aritmética binaria, que es la
8 (sería el caso de un paquete que no contenga suma en complemento a uno de 16 bits de
datos). toda la cabecera. No voy a entrar en detalles
de cómo se realiza esta operación, así que si
Con respecto al campo Suma de tenéis curiosidad podéis consultar el RFC
comprobación (checksum en el original) 1071 o, si lo preferís, tenéis aquí directamente
hay bastante más que decir. Éste es el campo un código en C que calcula la suma de
que nos permite comprobar que los datos comprobación (checksum) para el protocolo
que hemos recibido son correctos, es decir, TCP:
que el paquete no ha tenido problemas que 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.
hayan corrompido los datos durante su
transporte. Para calcular la Suma de Si queréis utilizar este código para el caso de
comprobación se genera una cabecera con UDP sólo tenéis que cambiar esta línea:
los siguientes campos:
u16 prot_tcp=6;
Por esta otra:
u16 prot_tcp=17;
Aunque, si queréis que quede un poco más

bonito, preocupaos de cambiar también el
nombre de la variable para que se llame
prot_udp. ;-)
Todos estos campos los conocemos, excepto

Cuando recibimos un paquete UDP, nuestro
el campo Protocolo. Cada protocolo existente
sistema compara la suma de comprobación
tiene un número único asignado que le
con los datos que conoce sobre el paquete (IP
diferencia de los demás protocolos, y esto
de origen, IP de destino, y tamaño de paquete
permite por ejemplo, propagar la información
UDP), y si algo no concuerda sabrá que ha
sobre a qué protocolo hay que pasar un
habido algún problema y los datos del paquete
paquete después de procesarlo, tal y como
no son válidos.
hemos visto en el ejemplo al principio de este
artículo, en el cual la cabecera IP contenía
Un detalle curioso con respecto al complemento
un campo Protocolo = UDP, y la cabecera
a uno (la forma de representación binaria
Ethernet contenía un campo Protocolo = IP.
utilizada en la suma de comprobación) es que
existen dos formas de representar el cero: o
Esta lista está mantenida por el IANA
bien que todos los dígitos sean 1, o bien que
(Internet Assigned Numbers Authority), así
todos sean 0.
que podéis consultarla en www.iana.org. Si
queréis una lista más sencilla, aunque no
Esto nos es útil en nuestro caso, ya que lo
actualizada, la tenéis en el RFC 1700
que se hace es usar la primera representación
(http://www.rfc-editor.org/rfc/rfc1700.txt).
del cero (todos los dígitos son 1) para las

sumas cuyo resultado son cero, y la otra http://winpcap.polito.it/, pincharemos en

representación del cero (todos los dígitos son DOWNLOADS (en el menú de la izquierda) y
0) indica simplemente que ese paquete no aparecerá una lista descargas. Tenemos que
incluye una suma de comprobación, por el descargarnos el WINPCAP 3.0
motivo que sea (por ejemplo, si el protocolo
no requiere una comprobación de los datos).
4. UDP EN LA PRÁCTICA
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).
No cometas el error de bajarte la última versión
Para que estos programas funcionen, nuestro (WINPCAP 3.1 BETA), hemos podido comprobar
sistema tiene que permitir el uso de raw que no funciona correctamente en bastantes
sockets, es decir, de paquetes generados de nuestros equipos, incluso con
desde cero. Linux siempre ha permitido los configuraciones muy normalitas. Así que ya
raw sockets, y Windows sólo lo hace desde sabes, descarga la versión 3.0 tal y como te
sus versiones XP y 2000. Si aún queda algún indicamos :)
usuario de Windows 9x (95, 98, o Millenium),
que tampoco se preocupe, ya que puede Una vez descargado el archivo mencionado
utilizar las librerías WinPCap para que su (WinPcap_3_0.exe) lo ejecutaremos para que
sistema admita raw sockets. Estas librerías se instale en el sistema. Si te pide reiniciar
las tenéis en: http://winpcap.polito.it/. Windows, hazle caso :)
De todas maneras, nosotros vamos a utilizar A continuación, ya podemos bajar el Nemesis,

para nuestras prácticas en Windows un que lo tenéis aquí:
programita llamado Nemesis. Esta aplicación
http://www.packetfactory.net/Projects/nem
necesitará las librerías WinPCap incluso si
esis/ (Por supuesto, bajad la versión para
tienes un Windows XP y 2000 tranquilos,
Windows).
ahora veremos detalladamente todo esto :)
4.1. NEMESIS PARA WINDOWS

(TODAS LAS VERSIONES)
En primer lugar vamos con los usuarios de

Windows, no porque sean más importantes,
si no porque ya he empezado hablando de
ellos antes. :-P
Lo primero que tenemos que hacer es bajarnos

las librerías WinPCap. Para ello abriremos
nuestro navegador preferido e iremos a

Obtendremos el archivo comprimido nemesis- Escribimos dir y pulsamos enter. Con

1.4beta3.zip y lo descomprimiremos en la ello veremos un listado del contenido
carpeta c:\nemesis. Este programa no necesita de la carpeta Nemesis, veremos, entre
instalarse, ahora veremos cómo otros el archivo nemesis.exe (nuestro
utilizarlo ;) preciado Nemesis ;))
Podemos pasar ya a la acción. Si vais al

directorio (carpeta) sobre donde habéis
descomprimido el Nemesis (en nuestro caso
c:\nemesis), veréis que hay una serie de
archivos TXT, uno de los cuales se llama
nemesis-udp.txt. En ese archivo tenéis
instrucciones para utilizar Nemesis con UDP,
que es lo que nos interesa ahora.
Enseguida descubriréis que Nemesis es una
aplicación más práctica que estética, ya que
no tiene interfaz gráfica, 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). ¿Cómo se hace eso? Ya lo hemos
explicado mil veces, tienes dos opciones:
Menu Inicio --> Todos los Programas

--> Accesorios --> Símbolo del sistema
Por fin, escribimos:

Menu Inicio --> Ejecutar y en la
ventana que nos aparezca escribimos
nemesis udp v y 53 D 194.224.52.6 P
command y pulsamos enter
y pulsamos enter, nos aparecerá algo como

Ahora, utilizando nuestra consola de MS-DOS
esto:
vamos al directorio donde hemos tenemos
en Nemesis esperándonos. Para el que no
UDP Packet Injection -=- The NEMESIS
sepa hacer eso (que a estas alturas de la
Project Version 1.4beta3 (Build 22)
publicación ya deberían ser MUY POCOS):
En nuestra ventanita negra escribimos [IP] 68.253.120.0 > 194.224.52.6

cd c:\ y pulsamos enter (con esto nos [IP ID] 64988
vamos al directorio raíz del disco duro [IP Proto] UDP (17)
C). [IP TTL] 255
[IP TOS] 00
E n n u e s t ra ve n t a n i t a n e g ra [IP Frag offset] 0000
escribiremos cd c:\nemesis y [IP Frag flags]
pulsaremos enter (con esto nos
posicionamos en el directorio donde [UDP Ports] 64988 > 53
tenemos nuestro Nemesis).

A continuación, escribimos cualquier cosa: una de las máquinas a las que tienen que dar
servicio.
hola
Wrote 33 byte UDP packet. ¿Y cual puede ser la utilidad de utilizar una IP
que no es la tuya? Pues ya hablaremos sobre
UDP Packet Injected todo eso a lo largo del curso, pero os adelanto
que esto puede servir para llevar a cabo gran
Vamos a analizar lo que hemos hecho. número de ataques.
En primer lugar, al llamar a Nemesis con la
En nuestro caso no queremos atacar a nadie,
opción udp en primer lugar (nemesis udp)
simplemente queremos comprender de forma
le decimos que queremos enviar un paquete
práctica el funcionamiento del protocolo UDP.
UDP, de entre todos los protocolos que
Por lo tanto preferimos utilizar nuestra IP
soporta Nemesis.
como IP de origen:
La opción v es la clásica opción verbose de nemesis udp v y 53 S 192.168.1.2 D

muchos programas, que nos permite ver en 194.224.52.6 P
pantalla información detallada sobre lo que
estamos haciendo. Hemos añadido la opción S para especificar
la IP de origen. Si estamos detrás de un
La opción y sirve para detallar el puerto router, tendremos que especificar nuestra IP
UDP de destino. En este caso, hemos privada (de nuestra red local), ya que el router
utilizado el conocido puerto 53, que es el ya se encargará de convertirla luego en vuestra
puerto de DNS. IP pública.
La opción D sirve para especificar la

dirección IP de destino. En este caso, ! Ya se explico...
hemos utilizado la dirección de un servidor
DNS de Telefónica.
Ya se ha explicado mil veces, pero bueno para saber
Por último, la opción P sirve para indicar cuál es tu IP, simplemente abre una "ventanita negra",
qué datos queremos meter en el campo escribe ipconfig /all y pulsa enter. Este tema ya se trató
DATOS del paquete UDP. Por ejemplo, en en profundidad en los primeros números de Hack x Crack.
este caso, debería ir aquí la supuesta consulta
DNS. En el caso de este ejemplo, poniendo
P indicamos a la aplicación que queremos
meter nosotros los datos directamente desde Si seguimos observando el comportamiento
teclado. de Nemesis, veremos que ha escogido un
puerto aleatorio como puerto de origen.
Analicemos ahora el comportamiento de Para la mayoría de las aplicaciones esto nos
Nemesis. En primer lugar, vemos que ha valdrá, pero si queremos probar a especificar
utilizado como IP de origen una que no es la un puerto de origen en concreto utilizaremos
nuestra, por lo que la respuesta a este paquete la opción x:
difícilmente podría llegarnos a nosotros. Es
más, es también improbable que el paquete nemesis udp v x 1000 y 53 S
llegue siquiera a su destino, ya que los routers 192.168.1.2 D 194.224.52.6 P
que habrá en los primeros pasos del camino
Esto puede sernos útil si estamos detrás de
(por ejemplo, nuestro router ADSL, o el router
un firewall muy exigente que sólo nos permita
de nuestro ISP) probablemente rechazarán
utilizar algunos puertos UDP determinados
el paquete al no provenir supuestamente de
(en el caso del ejemplo, el puerto 1000).

Por último, os habréis dado cuenta de que no falsa que tenemos almacenada en el archivo
es nada práctico meter los datos directamente envenenamiento.txt. La forma de lanzar
desde teclado, ya que es bastante complicado esta respuesta falsa sería:
generar una consulta DNS a pelo e introducirla
nemesis udp x 53 y 1200 S
desde el teclado. En la mayoría de los casos,
194.220.51.2 D 194.224.52.6 P
os será mucho más útil construir primero la
envenenamiento.txt
consulta con algún editor hexadecimal (por
ejemplo, podéis utilizar UltraEdit, que además
Podemos automatizar esto mediante un script
de ser un magnífico editor y visor de textos,
que haga un bucle en el cual vaya utilizando
es también un editor hexadecimal básico),
distintos Transaction ID y, tal y como vimos
guardarla en un fichero, y luego cargarla
en el artículo sobre DNS, según la versión de
directamente en Nemesis con la opción P.
BIND que utilice el servidor DNS de la víctima
Por ejemplo, si nuestro fichero se llama
tendremos una mayor o menor probabilidad
consulta.txt haremos:
de éxito.
nemesis udp v x 1000 y 53 S
192.168.1.2 D 194.224.52.6 P 4.2. HPING PARA LINUX
consulta.txt
Existe también versión de Nemesis para Linux,
pero os enseñaré mejor una herramienta
Podemos, por ejemplo, capturar una consulta
bastante más potente, que es Hping. Podéis
DNS real con un sniffer, después modificarla
bajar Hping de www.hping.org. Para instalarlo
a nuestra voluntad con el editor hexadecimal,
tendréis que compilarlo primero. Los pasos a
guardar la consulta modificada en un archivo,
seguir son los típicos:
y después enviarla a través de Nemesis.
Primero, una vez bajado el archivo con

En el artículo de la Serie RAW sobre DNS
extensión .tar.gz, lo descomprimimos y
hablé acerca de la técnica de
desempaquetamos con el comando:
envenenamiento de cache DNS. Con
tar -zxvf hping2.0.0-rc2.tar.gz
Nemesis, y un sencillo shell script podríamos
explotar esta técnica una vez conseguidos los
Nos creará un directorio hping2-rc2, en el
datos necesarios. Si no habéis leído el artículo
cual entraremos (cd hping2-rc2), para
sobre DNS, os recomiendo que paséis este
después ejecutar:
punto, porque probablemente no os enteraréis
./configure
de nada. :-)
A continuación, ejecutamos:
Si, por ejemplo, tenemos estos datos para Make
llevar a cabo el ataque:
Y, por último:
Dirección IP del servidor DNS de la make install
víctima = 194.224.52.6
En caso de cualquier problema con este sistema
Dirección IP del servidor DNS
estándar de instalación, podéis consultar el
authoritative que queremos suplantar =
archivo INSTALL con instrucciones más
194.220.51.2 detalladas sobre el proceso.
Puerto UDP utilizado por el servidor
DNS de la víctima = 1200 Una vez instalado, vamos a probar un poco
su funcionamiento. Por supuesto, tendréis la
Suponemos, por supuesto, que conocemos correspondiente página del manual de hping:
también el identificador de transacción, y que man hping2
con él hemos construido una respuesta DNS Hping no sólo permite enviar un único paquete,

si no que además implementa sencillos bucles Una opción curiosa de hping es la opción --badcksum
para poder generar muchos paquetes sin que genera una suma de comprobación inválida en el
necesidad de programar scripts. Si queremos paquete enviado, lo cual puede ser útil para comprobar la
que envíe un único paquete tendremos que reacción de un sistema ante un paquete malformado.
usar la opción --count 1. Aunque mejor que
veamos directamente un ejemplo: A lo largo del curso, entraremos en más detalle en el
funcionamiento de éstas y otras herramientas. Por el
hping2 193.224.52.6 --udp --destport 53
momento, os animo a que vayáis investigando por vuestra
--file envenenamiento.dat --data 14 --
cuenta.
count 1
Autor: PyC (LCo)

El primer parámetro (193.224.52.6), como
podéis imaginar, es la IP de destino del
paquete, y es el único parámetro obligatorio. RFC 768 J. Postel
ISI
El parámetro --count ya hemos dicho que 28 de Agosto de 1980
indica el número de paquetes a enviar.
Según las opciones estos paquetes podrán PROTOCOLO DE DATAGRAMAS DE USUARIO
ser diferentes entre sí, por ejemplo, (User Datagram Protocol)
incrementando el puerto de origen en cada
paquete. Si queréis más detalle sobre estas (Traducción al castellano: Diciembre de 1999)
opciones consultad la página del manual. Por (Por Domingo Sánchez Ruiz <domingo@quark.fis.ucm.es>)
defecto, el puerto de origen se incrementa
con cada paquete, así que si queremos utilizar Introducción
siempre el mismo puerto utilizaremos la
opción --keep. Este Protocolo de Datagramas de Usuario (UDP:
User Datagram Protocol)se define con la
El parámetro --udp, por supuesto, indica que intención de hacer disponible un tipo de
el protocolo a utilizar será UDP. datagramas para la comunicación por intercambio
de paquetes entre ordenadores en el entorno
El parámetro --destport es el puerto de de un conjunto interconectado de redes de
destino del paquete. computadoras.
El parámetro --file es el fichero en el que Este protocolo asume que el Protocolo de

tenemos el campo DATOS del paquete, es Internet (IP: Internet protocol) [1] se
decir, por ejemplo la consulta DNS, o la utiliza como protocolo subyacente.
respuesta falsa para el caso de que estemos
haciendo un ataque de envenenamiento de Este protocolo aporta un procedimiento para
cache DNS. que los programas de aplicación puedan enviar
mensajes a otros programas con un mínimo de
El parámetro --data es el tamaño de los mecanismo de protocolo. El protocolo se
datos sin la cabecera, es decir, en este caso orienta a transacciones, y tanto la entrega
sería igual al campo Tamaño paquete de la como la protección ante duplicados no se
cabecera UDP, pero restándole 8 bytes, que garantizan.
son los que ocupa la cabecera UDP. Las aplicaciones que requieran de una entrega
fiable y ordenada de secuencias de datos
Si quisiésemos especificar un puerto de deberían utilizar el Protocolo de Control de
origen usaríamos el parámetro --baseport. Transmisión (TCP: Transmission Control
Si no se especifica, el puerto de origen será Protocol). [2]
aleatorio.

Formato 0 7 8 15 16 23 24 31
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+
+--------+--------+--------+--------+ | dirección de origen |
| Puerto de | Puerto de | +--------+--------+--------+--------+
| Origen | Destino | | dirección de destino |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | | cero |protocol| longitud UDP |
| Longitud | Suma de Control | +--------+--------+--------+--------+
+--------+--------+--------+--------+
|
| octetos de datos ... Si la suma de control calculada es cero, se
+---------------- ... transmite como un campo de unos (el equivalente
en la aritmética del complemento a uno). Un
Formato de la Cabecera de un Datagrama de Usuario valor de la suma de control trasmitido como
un campo de ceros significa que el emisor
Campos no generó la suma de control (para depuración
o para protocolos de más alto nivel a los
El campo Puerto de Origen es opcional; cuando que este campo les sea indiferente).
tiene sentido, indica el puerto del proceso
emisor, y puede que se asuma que ése sea el
puerto al cual la respuesta debería ser Interfaz de Usuario
dirigida en ausencia de otra información. Si
no se utiliza, se inserta un valor cero. Un interfaz de usuario debería permitir:
El campo Puerto de Destino tiene significado la creación de nuevos puertos de recepción,

dentro del contexto de una dirección de operaciones de recepción en los puertos de
destino en un entorno internet particular. recepción que devuelvan los octetos de datos
y una indicación del puerto de origen y de
El campo Longitud representa la longitud en la dirección de origen, y una operación que
octetos de este datagrama de usuario, incluyendo permita enviar un datagrama, especificando
la cabecera y los datos. (Esto implica que los datos y los puertos de origen y de destino
el valor mínimo del campo Longitud es ocho.) y las direcciones a las que se debe enviar.
El campo Suma de Control (Checksum) es el Interfaz IP

complemento a uno de 16 bits de la suma de
los complementos a uno de las palabras de la El módulo UDP debe ser capaz de determinar
combinación de una pseudo-cabecera construida las direcciones de origen y destino en un
con información de la cabecera IP, la cabecera entorno internet así como el campo de protocolo
UDP y los datos, y rellenada con octetos de de la cabecera del protocolo internet. Una
valor cero en la parte final (si es necesario) posible interfaz UDP/IP devolvería el datagrama
hasta tener un múltiplo de dos octetos. de internet completo, incluyendo toda la
cabecera, en respuesta a una operación de
La pseudo-cabecera que imaginariamente antecede recepción. Un interfaz de este tipo permitiría
a la cabecera UDP contiene la dirección de también al módulo UDP pasar un datagrama
origen, la dirección de destino, el protocolo deinternet completo con cabecera al módulo
y la longitud UDP. Esta información proporciona IP para ser enviado. IP verificaría ciertos
protección frente a datagramas mal encaminados. campos por consistencia y calcularía la suma
Este procedimiento de comprobación es el de control de la cabecera del protocolo
mismo que el utilizado en TCP. internet.

Aplicación del Protocolo
Los usos principales de este protocolo son

el Servidor de Nombres de Internet [3] y la
EL GANADOR DEL
Transferencia Trivial de Ficheros (Trivial
File Transfer) [4].
SORTEO DE UN SUSE
Número del protocolo
Este es el protocolo 17 (21 en octal) cuando LINUX 9 DEL MES DE

se utilice en el Protocolo de Internet (IP).
Febrero ES:
Se indican otros números de protocolo en [5].
Referencias
[1] Postel, J., "Internet Protocol," RFC Manuel perez garcia

760, USC/Information Sciences Institute, Enero de
1980. (Nota del T. Hay traducción al español por
P.J. Ponce de León: "Protocolo Internet", Mayo
1999.)
sevilla
[2] Postel, J., "Transmission Control
Protocol," RFC 761, USC/Information
Sciences Institute, Enero de 1980. PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA TU
TU
TU
TU
TU
TU
TU
TU
TU
TU
TU
TU
TU
TU
TU
TU MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
PERSONALIZA
PERSONALIZA
PERSONALIZATU
TU
PERSONALIZA TU
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA
PERSONALIZA MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
TU
TU
TU
TU
TU
TU
TU
PERSONALIZA TU MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
MOVIL
[3] Postel, J., "Internet Name Server,"
USC/Information Sciences Institute, IEN
116, Agosto de 1979.
[4] Sollins, K., "The TFTP Protocol,"

Massachusetts Institute of Technology,
IEN 133, Enero de 1980.
[5] Postel, J., "Assigned Numbers,"

USC/Information Sciences Institute, RFC
762, Enero de 1980.
Nota del traductor
Este documento y las traducciones al español

mencionadas en las referencias pueden
encontrarse en:
http://lucas.hispalinux.es/htmls/estandare
s.html
El proyecto de traducción de RFC al español

tiene su web de desarrollo en:
HAY MUCHOS MAS EN
http://pclog.buscalogos.com/
http://www.arrakis.es/~pjleon/rfc-es

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 conexión"? ---> conexiones virtuales
1. INTRODUCCION con la práctica lo que no se puede

conseguir con la mera teoría.
Después de haber estado hablando
indirectamente sobre el protocolo TCP/IP Además, para hacerlo un poco más
durante 10 meses en la serie RAW, al fin amena, la segunda entrega incluirá
vamos a entrar de lleno en la base de también algunas técnicas de hacking
todo esto: la base sobre la que se apoyó basadas en el funcionamiento de TCP,
toda la serie RAW. que es lo que a muchos de vosotros más
os interesa. ;-) Aprenderemos además a
Al hablar del protocolo TCP al fin vamos construir las cabeceras tal y como son en
a comprender qué es lo que ocurre realidad, en binario. Pero lo más
realmente cuando hacemos un Telnet y importante es que podremos ver en detalle
la necesidad de establecer conexiones cómo es el tráfico que circula
de este tipo. constantemente entre nuestro ordenador
y la red Internet.
Comprenderemos también por qué se
utiliza TCP como protocolo de transporte 2. DIFERENCIAS ENTRE TCP Y
para la mayoría de las aplicaciones, al UDP
compararlo con UDP y comprobar que
son muchas las ventajas. Por si no lo habéis hecho, es importante
que antes de continuar repaséis los dos
Con este artículo, entramos a fondo en artículos anteriores del curso de TCP/IP
conceptos nuevos, como son las (Introducción, y UDP), ya que vamos a
conexiones virtuales, el control de flujo, empezar comparando este nuevo
los flags, etc. Quizá no os queden del protocolo con el que ya conocíamos, el
todo claros los conceptos después de protocolo UDP.
terminar de leerlo, pero no os preocupéis,
que está todo previsto.
2.1. Conexiones virtuales
El curso continuará con una segunda
Volvemos a insistir una vez más en que
entrega dedicada a TCP, en la cual
una de las principales diferencias entre
aclararemos muchos de los conceptos
TCP y UDP es la existencia de conexiones
que quedarán hoy en el aire, y veremos
virtuales. Como ya vimos, el protocolo
una serie de ejemplos que conseguirán
TCP se dice que es orientado a conexión

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)
(en realidad conexiones virtuales), Imaginemos cómo habría sido la Internet

al contrario que UDP (no orientado a en aquellos años. Un autentico ejército
conexión). de internetistas trabajando 24 horas
para dar servicio a todas las conexiones
Las implicaciones de esto son muchas, que estableciese cualquier cliente: cada
tal y como iremos viendo a lo largo del vez que alguien desease leer su correo
artículo. electrónico, una internetista tendría que
establecer una conexión en el panel entre
De momento quedémonos con la idea de el cliente y su servidor de POP3, cada vez
conexión virtual. que alguien visitase una página web una
internetista tendría que establecer una
¿Por qué se habla de conexiones virtuales,
conexión entre el cliente y el servidor de
y no de conexiones a secas? Para
la página web, etc., etc.
encontrar una respuesta a esta pregunta
basta con pensar un poco en la
Desde luego, esto habría sido una locura
arquitectura de la red Internet (y de
inviable, sin contar con el hecho de que
cualquier red TCP/IP).
la red sería muy lenta y muy insegura.
Si Internet hubiese existido hace 50 años,

Si tratásemos de mejorar esta idea
probablemente su arquitectura hubiera
sustituyendo a las internetistas humanas
sido muy diferente, igual que la red
por un medio mecánico automatizado que
telefónica de ahora es muy diferente a
estableciese las conexiones mediante
la que había entonces. La red telefónica
relés seguiríamos teniendo muchos
de aquellos años dependía de una figura
problemas, y uno de los más preocupantes
humana bien conocida: la telefonista.
sería el de la velocidad.
Las telefonistas eran unas mujeres casi

Se mire por donde se mire, una red en
biónicas que actuaban como
la que haya que establecer nuevas
intermediarias entre los distintos clientes
conexiones cada vez que se desee utilizar
de la red telefónica para que estos
un servicio siempre será más lenta que
pudieran comunicarse entre sí. Cuando
una red en la que todo esté conectado
un cliente deseaba hablar con otro, una
de antemano.
telefonista
tenía que
Y precisamente esa es la topología de la
establecer
red Internet: todo está conectado de
una conexión
antemano. Nuestro PC siempre tiene un
manual entre
único cable que nos conecta con Internet
las líneas de
(el cable de red que va al router, o el
a m b o s
cable que va al modem, o el cable etéreo
clientes,
que nos une con nuestra estación
conectando
wireless). Y lo mismo ocurre con cualquier
los cables
máquina conectada a Internet. Nunca
correspon-
hay que cambiar ningún cable de sitio,
dientes en un
por muy diferentes que sean las
panel de
conexiones que queramos establecer.
conexiones.
Tanto si vamos a enviar un correo a

nuestro mejor amigo, como si vamos a Para entenderlo, veamos el caso de un

ver una página web de Japón, las chat entre 3 personas. Podríamos pensar
conexiones físicas son siempre las en primer lugar en una solución que fuese
mismas. un único cable con 3 conectores que
conectase entre sí a los 3 interlocutores.
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
conexión virtual, que busca las ventajas
de las redes en las que las conexiones
no están 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 comunicación entre dos
puntos, es necesario poner a ambas
partes de acuerdo y establecer una
conexión entre ambas.
En teoría, las conexiones virtuales

permiten, igual que una conexión real,
que la comunicación no sea escuchada
por nadie que no esté conectado al cable
que une ambos puntos, que terceras Pero, ¿que ocurriría si quisiéramos meter
personas no puedan intervenir en la a una persona más en la conversación?
comunicación enviando datos que no ¿Tendríamos que quitar el cable de 3
sean de ninguna de las dos partes conectores y cambiarlo por uno de 4?
legítimas, que nadie pueda hacerse pasar Sería mucho más sencillo un sistema en
por otro, etc., etc. Por supuesto, todo el cual todo funcionase mediante cables
esto es en teoría pero, como bien de sólo dos conectores. Para que alguien
sabemos, nada en este mundo entrase o saliese del chat, bastaría con
funciona como en teoría debería. ;-) conectar o desconectar un sólo cable,
pero no habría que modificar toda la red,
¿Qué es lo que caracteriza una y el resto de usuarios del chat no se verían
conexión? afectados por lo que hiciera uno solo.
Las conexiones de las que hemos hablado Para poder realizar este chat entre 3
son siempre conexiones entre dos personas mediante cables de 2 conectores
puntos, y así son todas las conexiones se hace imprescindible la presencia de un
en TCP. Aunque puedas estar en un chat intermediario que gestione todas las
hablando con 100 personas a la vez, en conexiones de todos los usuarios. Esta es
realidad toda esa comunicación se realiza precisamente la misión de un servidor
a través de pares de conexiones. de chat.

Por lo que hemos visto hasta ahora, es obvio que lo

primero que caracteriza a una conexión son los dos
extremos que conecta. En nuestro contexto, los
extremos de la conexión se identifican mediante las
conocidas direcciones IP.
Pero la identificación de los extremos no es lo único

que caracteriza una conexión. Cada uno de los
extremos podría tener varios conectores diferentes,
así que no sólo basta saber con quién conectas, si
no también dónde. En nuestro contexto, cada uno
de los conectores de un mismo extremo serían los
diferentes servicios: HTTP, FTP, POP3, etc.
Por tanto, al igual que ocurría con UDP, otro de los
parámetros que caracterizan una conexión TCP son
los puertos de conexión de ambos extremos.
Si se tratase de conexiones físicas, no haría falta

mucho más para ser caracterizadas. En cambio, al
Como vemos en esta otra imagen, ahora tratarse de conexiones virtuales, necesitamos algún
hay 3 cables en lugar de uno sólo, y cada mecanismo que identifique una conexión establecida.
cable conecta a un único usuario con el Y es aquí donde vemos la principal diferencia entre
servidor que gestiona el chat. TCP y UDP.
Es importante comprender que esto que
Los paquetes TCP contienen un campo en su cabecera
hemos dicho de los cables de sólo dos
que no contienen los paquetes UDP. Este campo
conectores no se refiere a las
adicional es el que permite identificar la conexión
conexiones físicas de Internet, si no
virtual a través de la cual circula el paquete.
a las conexiones virtuales que nos da el
protocolo TCP.
La solución más obvia que podríamos encontrar
De hecho, muchas redes TCP/IP tienen para implementar este identificador de conexión
físicamente conectadas todas sus sería utilizar un número que identificase
máquinas entre sí, en lugar de realizar unívocamente la conexión. Pero esta solución
las conexiones mediante cables punto a presentaría varios problemas, el mayor de los cuales
punto, pero insisto en que esto sólo sería quizá la seguridad.
ocurre con las conexiones físicas, pero
no con las conexiones virtuales, que son Si una conexión se identifica permanentemente por
siempre punto a punto. un mismo número, es sólo cuestión de tiempo que
un atacante encuentre ese número por fuerza bruta
! Hablando claro... y así, con sólo spoofear su IP (utilizar algún
mecanismo para enviar paquetes en nombre de una
Hablando claro, no importa como conectes físicamente tu PC IP que no sea la suya), se pueda colar en la conexión
a otros PCs (hay mil maneras de hacerlo, unas son punto a ajena. Una solución mucho mejor es utilizar un
punto y otras no). Lo importante es que TU PC (y cualquier número que vaya cambiando con cada paquete,
otro PC del mundo), cuando utilice el protocolo TCP,
según unas ciertas normas establecidas entre los
establecerá siempre conexiones virtuales punto a punto.
dos extremos.

Esto en realidad no es tal y como lo pinto. Este Una solución mucho más eficiente es
número cambiante realmente existe, pero su principal englobar en un sólo paquete los datos
finalidad no es la de identificar conexiones, si no transmitidos y la confirmación de los datos
más bien la de mantener el estado de evolución de recibidos.
una conexión, y saber así en todo momento qué
paquetes se pueden enviar y qué paquetes se pueden
recibir a través de esa conexión.
Este número es el llamado número de secuencia,

pero mejor será que no nos precipitemos más, que
ya habrá tiempo de ver todo esto en detalle.
2.2. Fiabilidad en la comunicación

En esta figura vemos cómo las máquinas
Como ya conté en el artículo sobre UDP, al contrario A y B intercambian paquetes a través de
que éste, el protocolo TCP tiene un mecanismo para una misma conexión, actuando ambos
asegurar que los datos llegan correctamente a su simultáneamente como transmisores y
destino. Para conseguir esto, cada paquete TCP que receptores.
llegue a un destino ha de ser respondido por éste
mediante otro pequeño paquete que confirme la En primer lugar, la máquina A envía el
recepción. primer paquete (Paquete 1 A). Una vez
recibido el paquete 1 A, la máquina B
decide también empezar a enviar sus
propios paquetes, por lo que envía un
único paquete a A en el que engloba la
confirmación de que recibió el paquete 1
A, así como su propio paquete 1 B.
A esto responderá la máquina A enviando

el siguiente paquete de los que desea
Esto sería así en el caso más sencillo, transmitir, pero englobando en el mismo
pero menos común, que sería el de una también la confirmación de que recibió
comunicación unidireccional, donde sólo correctamente el paquete 1 B.
una de las partes enviase datos a la otra.
Así continuaría la comunicación, hasta
En la práctica, la mayoría de los servicios que la máquina A decidiese dejar de
son bidireccionales, por lo que es transmitir sus propios datos, por lo que
necesario intercalar los paquetes su única misión consistiría ya sólo en
transmitidos con las confirmaciones de seguir confirmando la recepción de los
los paquetes recibidos. paquetes que le envía B, como ocurre en
Esto podría dar lugar a un gran número la figura con el caso del paquete 2 B, al
de paquetes (el doble, exactamente), ya cual la máquina A responde sólo con una
que a cada paquete de datos habría que confirmación de recepción, pero sin
sumar además el correspondiente englobar más datos en el mismo paquete,
paquete de confirmación. ya que A no tiene ya nada más que desee
enviar.

¿Qué ocurre si uno de los paquetes 2.4. Tratamiento de paquetes

se pierde por el camino? Cada vez que
grandes
una máquina transmite un paquete TCP,
ésta no lo borra de su memoria, si no
Esta capacidad de dividir los datos en
que lo deja almacenado aún por un
fragmentos ordenados, combinada con el
tiempo, esperando que llegue la
sistema de confirmación de respuestas
confirmación de su recepción. Si ésta
de TCP, convierte a éste protocolo en un
llega, se podrá borrar el paquete de la
protocolo de transporte ideal para la
memoria, y olvidarse para siempre de
transmisión segura de grandes cantidades
él. En cambio, si pasado un tiempo
de datos.
prudencial no ha llegado la confirmación
de su recepción, se asumirá que el
2.5. Control de flujo
paquete no ha llegado a su destino, por
lo que éste se retransmitirá. Así, el
Aquí entramos ya en un nuevo concepto
paquete se conservará en la memoria
que habrá que introducir, ya que es uno
todo el tiempo que sea necesario,
de los conceptos básicos del campo de
reenviándolo cada cierto tiempo, hasta
las redes y telecomunicaciones.
que al fin llegue la confirmación de que
el paquete fue recibido.
Hasta ahora hemos tratado las redes y
En el caso de que, debido a estos las máquinas como si fuesen perfectas,
reenvíos, un mismo paquete llegue más sin limitaciones. Pero sabemos muy bien
de una vez al mismo destino, no habrá que en la vida real esto no es así ya que,
ningún problema, ya que el diseño de por ejemplo, el ancho de banda de una
TCP permite diferenciar perfectamente red es uno de los factores más
un paquete de otro, por lo que al detectar determinantes de su efectividad.
la duplicación simplemente se rechazará
la copia. Hemos asumido que los paquetes se iban
transmitiendo a diestro y siniestro, y que
2.3. Orden en los datos estos iban a ser recibidos sin problemas.
Bueno, no exactamente... Hemos dicho
Tal y como decíamos también en el
que sí que podía haber problemas en la
anterior artículo, TCP identifica cada
recepción, pero realmente no hemos
paquete con un número de secuencia
hablado de los problemas del ancho de
que permite ordenarlos correctamente
banda.
independientemente de su orden de
llegada al destino.
Si la única solución ante la congestión de
En el caso de UDP, los paquetes se iban la red fuese el mecanismo explicado
procesando según iban llegando. En anteriormente para asegurarnos de que
cambio, en TCP un paquete se puede todos los datos llegan al destino, el
dividir en fragmentos que podrán llegar problema no se solucionaría si no que, al
en cualquier orden, y los datos no se contrario, sería cada vez mayor.
procesarán hasta que se hayan recibido
todos los fragmentos y estos se hayan Imaginemos la situación. La máquina A,
ordenado según el número de secuencia que transmite los paquetes, es demasiado
de cada paquete. rápida para lo que es capaz de procesar

la máquina B, que recibe los paquetes. comunicación, a no ser que sea un mal-
Por tanto, la máquina A empieza a enviar nacido (que los hay), tendrá que actuar
paquetes a toda velocidad y sin en consecuencia, relajándose un poco y
compasión, esperando las confirmaciones dándonos tiempo a asimilar lo que ya nos
de la máquina B. Como B no da abasto, ha enviado.
no es capaz de enviar las confirmaciones
de recepción a tiempo. Al no llegar las Más adelante veremos en detalle cómo
confirmaciones, A se pondrá a reenviar se implementa el control de flujo en TCP.
los paquetes anteriores, al mismo tiempo
que continúa enviando paquetes a diestro
y siniestro, por lo que la congestión, ! Todo esto que...
sumando los paquetes nuevos y los viejos,
será muchísimo mayor. Todo esto que estamos explicando después lo tocaremos
en la realidad. Veremos los paquetes TCP y dónde está
localizado cada concepto del que hablamos.
3. LO QUE SÍ QUE TIENEN EN

COMÚN TCP Y UDP
Como no todo va a ser diferencias, vamos

a ver los puntos en común entre ambos
protocolos de transporte que, en el fondo,
son bastante parecidos.
En primer lugar, TCP también se apoya

Si no se implementa algún mecanismo sobre el protocolo IP y, en este caso, el
para evitar este caos, la situación puede número de protocolo asignado a TCP
hacerse insostenible en poco tiempo. Un para que la capa de red (la capa IP) pueda
mecanismo que se encargue de ajustar identificar el protocolo de transporte, es
el flujo de la comunicación es el número 6.
precisamente lo que se conoce como
control de flujo. Como ya sabemos, la cabecera IP
contendrá entre sus campos uno que
En el caso de TCP, disponemos de un identifique el protocolo de transporte que
sencillo mecanismo de control de flujo, está por encima de él.
que consiste en incluir en la cabecera de
cada paquete un campo que indica al
otro extremo de la comunicación cómo
estamos de congestionados. Esta medida
de la congestión la llevamos a cabo
diciendo cuántos bytes estamos
preparados para recibir. Según nos
vayamos saturando, este número será
cada vez menor, y el otro extremo de la

El punto en común más importante entre

TCP y UDP es que el mecanismo de ! RFC 793 en español
identificación de servicios es el mismo:
cada paquete, tanto en TCP como en RFC 793 en perfecto español!!! Como ya hemos comentado
muchas veces, tenemos traducidos muchos de los RFC al español
UDP, lleva dos números de puerto
en la Web www.rfc-es.org. Este es el trabajo de muchas personas
(origen, y destino), ambos comprendidos que desinteresadamente están colaborando en un proyecto
entre 0 y 65535 (16 bits). realmente descomunal: traducir los más de 3000 documentos, si
controlas de Ingles y te animas, ya sabes :)
Los puertos de TCP funcionan
El RFC 793 en castellano está en http://www.rfc-
exactamente igual que los de UDP, pero
es.org/getfile.php?rfc=0793
no tienen ninguna relación entre sí, es
decir, existen 65536 puertos para TCP, y
otros 65536 puertos diferentes para UDP. Como vemos, el RFC tiene 91 páginas,
por lo que es bastante más denso que la
Si, por ejemplo, en un firewall cierras el
mayoría de los RFCs que hemos visto
puerto 21 de TCP, no estarás cerrando
hasta ahora (tanto en la serie RAW como
al mismo tiempo el puerto 21 de UDP,
en el curso de TCP/IP). Aún así, no es
ya que son totalmente independientes. demasiado duro de leer, sobre todo si
prescindimos de algunas cosas poco
Otro punto en común es que ambos importantes para la comprensión del
protocolos incluyen una suma de protocolo, como la especificación de las
comprobación en cada paquete, que variables del TCB, o toda la parte del final
verifica la corrección de los datos incluidos relativa al procesamiento de eventos. En
cualquier caso, ya sabéis que aquí tendréis
en el mismo. La cabecera que se codifica
un buen resumen de todo lo más
en la suma de comprobación de TCP es
importante. ;-)
muy similar a la que se utiliza en UDP.
Como ya somos expertos en protocolos,
vamos a plantar aquí directamente la
4. LA CABECERA TCP EN
cabecera TCP. No pierdas de vista esta
DETALLE imagen, haremos referencia a ella a lo
largo de todo el artículo.
Entramos ya en los detalles técnicos del
protocolo TCP. En este caso, el RFC que
los especifica es el RFC 793. Desde la
página de los RFC (http://www.rfc-
editor.org) podemos bajar tanto versión
en TXT (http://www.rfc-editor.org/cgi-
bin/rfcdoctype.pl?loc=RFC&letsgo=793
&type=ftp&file_format=txt), como versión
en PDF (http://www.rfc-editor.org/cgi-
bin/rfcdoctype.pl?loc=RFC&letsgo=793
&type=ftp&file_format=pdf).

Bueno, bueno, la cosa ya va siendo más Por un lado, identifica unívocamente

seria, ¿eh? ;-) a cada paquete dentro de una conexión,
¡Que nadie se asuste! Ya veréis como y dentro de un margen de tiempo. Es
en un momento comprendemos todo lo este número el que nos permite detectar
que hay en esa imagen aparentemente si un paquete nos llega duplicado. Durante
tan complicada. un margen de tiempo (que depende del
flujo de los datos y, por tanto, también
Vamos a ir viendo campo por campo toda del ancho de banda) tenemos la garantía
la cabecera, para luego entrar en detalle de que en una determinada conexión
en el tamaño de los campos a nivel de virtual no habrá dos paquetes diferentes
bit (ya en el próximo artículo). con el mismo número de secuencia.
4.1. Puerto de origen Por ejemplo, en una conexión de 2Mbps,

este margen de tiempo es de unas 4 horas
Este campo tiene el mismo significado y media, mientras que en una conexión
que en el caso de UDP. En TCP es de de 100Mbps el margen es de 54 minutos.
especial importancia, porque es condición
necesaria (aunque no suficiente) para ¿Por qué este margen de tiempo varía en
identificar una conexión virtual. función del flujo de datos? Pues lo
comprenderemos en cuanto veamos qué
es exactamente el número de secuencia.
4.2. Puerto de destino
Y es que el número de secuencia es mucho
También tiene el mismo significado que
más que un mero identificador de
en UDP, y también es condición necesaria
paquetes. El valor del número de
(aunque no suficiente) para identificar
secuencia no es aleatorio, si no que tiene
una conexión virtual.
un significado muy concreto. El número
de secuencia es el orden en bytes que
Es decir, si nos llega un paquete que
ocupan los datos contenidos en el
coincide en IP de origen, IP de destino,
paquete, dentro de una sesión.
Puerto de origen, y número de secuencia,
con los de una conexión virtual, pero no
Es decir, supongamos que el primer
coincide el puerto de destino, entonces
paquete enviado una vez establecida una
ese paquete no se puede considerar
conexión tiene un número de secuencia
perteneciente a esa conexión virtual. Lo
0, y el paquete contiene 200 bytes de
mismo ocurre si el que cambia es el
datos. El siguiente paquete que se enviase
puerto de origen.
tendría que tener 200 como número de
secuencia, ya que el primer paquete
4.3. Número de Secuencia contenía los bytes del 0 al 199 y, por
tanto, el orden que ocupan los datos del
Aquí empieza lo más divertido, ya que segundo paquete es el siguiente: 200.
este campo es uno de los que más nos
dará que hablar. El número de secuencia ¿Por qué decíamos entonces que el
es un número bastante grande (32 bits) número de secuencia identifica
que tiene varias funciones. unívocamente un paquete dentro de un
margen de tiempo? Porque el número de

secuencia es siempre creciente, por lo quedaría: 0 1 + 300 = 299. Por tanto,

que un paquete posterior a otro siempre 299 sería el número de secuencia del
tendrá un número de secuencia mayor. próximo paquete.
Claro que... será mayor en módulo 32.
Esto significa que, una vez que el número En realidad, el número de secuencia no
de secuencia valga 232 1, es decir, el tiene por qué comenzar en cero. El
mayor número que se puede representar principal motivo es que si todas las
con 32 bits, el próximo número de conexiones empezasen en 0, no se podrían
secuencia utilizado será 0, es decir, se reutilizar las conexiones.
dará la vuelta al marcador.
Ya a estas alturas, habiendo visto todos
Por supuesto, cuánto se tarda en dar la los campos relevantes, podemos afirmar
vuelta al marcador depende directamente que lo que identifica una conexión son
de cuántos datos se envíen, y en cuanto estos 5 parámetros: ip de origen, ip de
tiempo. destino, puerto de origen, puerto de
destino, y número de secuencia.
Imaginemos que, por ejemplo, nuestro

software de correo electrónico está
configurado para comprobar si tenemos
mensajes nuevos cada 30 segundos. El
programa tendrá que establecer una
conexión TCP/IP con el puerto 110 (puerto
de POP3) de un servidor POP3 cada 5
segundos. En este caso, 4 de los
parámetros que identifican la conexión
En la imagen podemos ver reflejado esto. podrían ser iguales: puerto de origen,
Como vemos, el primer número de puerto de destino, ip de origen, e ip de
secuencia es 0, y el primer paquete destino.
contiene 200 bytes de datos. Por tanto,
el segundo paquete tendrá número de Digo que podrían porque el puerto de
secuencia 200. Este paquete contiene origen se podría cambiar de una conexión
12345 bytes de datos, por lo que el a otra (el resto de parámetros no se
próximo paquete tendrá como número podrían cambiar de ninguna manera),
de secuencia: 200 (número de secuencia aunque esto en muchos casos no será
anterior) + 12345 = 15345. posible o conveniente. Por tanto, el único
parámetro con el que podemos jugar para
Así continúa la sesión, hasta que un poder establecer nuevas conexiones
paquete tiene como número de secuencia similares sin que se confunda la nueva
232 1, y contiene 300 bytes de datos. con una vieja que ya se cerró, es el
En teoría, el próximo número de secuencia número de secuencia.
tendría que ser 232 1 + 300 pero, como
solo contamos con 32 bits para Si cada vez que el programa de correo
representar este número, tendremos que se reconecta al servidor POP3 utilizamos
dar la vuelta al marcador, es decir, el mismo número de secuencia para
convertir el 232 en un 0, por lo que nos comenzar la sesión (por ejemplo, 0), si

llegase un paquete muy retrasado del más de lo normal en llegar a B. Como A

servidor de correo de una conexión ya ha enviado lo que quería, cierra la
anterior (de los 5 segundos anteriores), conexión, a pesar de que todavía no ha
no habría forma de saber si este paquete recibido la confirmación de que B recibió
pertenecía a la sesión anterior, o a la el paquete Seq = 200.
nueva sesión. Una forma sencilla de evitar
esto es no utilizar siempre el mismo Inmediatamente después, A decide
número de secuencia para comenzar una establecer una nueva conexión con B para
sesión, si no ir utilizando números de enviarle otros datos. Comienza enviando
secuencia cada vez mayores. un primer paquete con Seq = 0, al cual
responde B con su confirmación de
Veamos un ejemplo de esto a partir de recepción. Para entonces, ya ha llegado
la siguiente figura. a B el paquete Seq = 200 de la anterior
conexión, por lo que construye su paquete
de confirmación. Pero la mala suerte se
confabula contra estas dos máquinas, y
justo en ese instante A envía un nuevo
paquete, que tiene también número de
secuencia 200. Inmediatamente B envía
la confirmación de recepción del paquete
Seq = 200 de la anterior conexión.
¿Qué ocurre a partir de aquí?
1.- Desde el punto de vista de A, B

ha recibido correctamente el último
paquete, por lo que continúa
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,

En primer lugar, la máquina A abre una acaba de recibir un nuevo paquete
conexión con la máquina B. Una vez Seq = 200. Como B ya había
abierta la conexión, A empieza a recibido un paquete Seq = 200,
transmitir sus datos, empezando por un interpreta que éste paquete es un
paquete con número de secuencia reenvío del anterior, por lo que lo
Seq = 0. B lo recibe y devuelve su desecha.
confirmación de recepción.
Por tanto, ni B recoge el paquete
A continuación, A transmite un nuevo Seq = 200, ni A se entera de lo que ha
paquete, con número de secuencia 200 pasado. En realidad las cosas no son
(por tanto, el primer paquete tenía que exactamente como las pinto, pero ya
contener 200 bytes de datos). Por algún iremos viendo más adelante cómo es todo
azar del destino, este paquete va a tardar esto realmente.

Por supuesto, el número de secuencia

no sirve sólo para detectar paquetes
duplicados, o para diferenciar unas
conexiones de otras, si no también para
poder ordenar los paquetes. Como el
número 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. Número de confirmación
Este campo es el que se utiliza para hacer

las confirmaciones de recepción de las
que tanto hemos hablado. Su
funcionamiento es muy similar al del Este campo sólo tiene significado si el
número de secuencia, porque en realidad paquete tiene activo el flag ACK, pero
eso ya lo veremos más adelante.
también representa un orden en bytes
de los datos.
4.5. Comienzo de datos
Lo que se envía en el número de Este campo no era necesario en el caso

confirmación es otro número de 32 bytes de UDP, ya que la cabecera UDP tiene un
que indica cuál es el próximo byte que tamaño fijo de 8 bytes. En cambio, la
estamos esperando recibir. cabecera TCP puede tener un tamaño
variable, tal y como veremos más
adelante, por lo que es necesario indicar
Si nuestro compañero en una conexión
a partir de qué punto comienzan los datos
nos envía un paquete con número de
y termina la cabecera.
secuencia 2000, y el paquete contiene
350 bytes de datos, el próximo número Este punto de comienzo no se expresa
de secuencia sería el 2350. Si queremos en bytes, como podríamos esperar, si no
confirmar que hemos recibido el paquete en palabras de 32 bits. Si nos fijamos
con número de secuencia 2000, en la cabecera, veremos que está
estructurada en filas, cada una de las
tendremos que enviar en nuestro paquete
cuales mide 32 bits. La primera fila
de respuesta un número de confirmación
contiene los puertos de origen y destino,
que valga 2350, diciendo así: Ya puedes la segunda el número de secuencia, la
enviarme el paquete 2350. He recibido tercera el número de confirmación, etc.
todo bien hasta aquí. Vamos a ver la
misma figura que pusimos al hablar sobre El valor más habitual para este campo es
el número de secuencia, pero esta vez 5, que equivale a 20 bytes de cabecera,
incluyendo los números de confirmación. es decir, lo mínimo que puede ocupar la
cabecera TCP.

4.6. Espacio reservado Imaginemos que queremos ver el

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

! ¿Qué no sabéis...
RST, SYN, FIN)
¿Qué no sabéis lo que es cat? Pues tendréis que repasar los
artículos ya publicados sobre Linux de esta misma revista.
Aquí tenemos también un asunto que va
;-) y si no, consulta el google (www.google.com).
a dar mucho que hablar. Los flags son
una serie de indicadores de control, de
un único bit cada uno, con diferentes
El caso es que, después de hacer el cat,
funciones que detallo a continuación.
descubrimos que el archivo es mucho
más largo de lo que esperábamos y, para
4.7.1. Flag URG (Urgent)
colmo, no nos interesa. Pulsamos
CONTROL-C y el listado del archivo se
Cuando este flag está activo (vale 1, en
aborta sin necesidad de esperar a que el
lugar de 0), estamos indicando que el
archivo termine de mostrarse entero.
paquete contiene datos urgentes. La
especificación de TCP no detalla qué se
El paquete que hemos enviado a la
debe hacer exactamente ante unos datos
máquina remota conteniendo la orden de
urgentes, pero lo normal es atenderlos
abortar el listado, tiene un flag URG
con máxima prioridad.
activo.
Si no existiese este mecanismo,
Si, por ejemplo, estamos procesando
probablemente la máquina remota seguiría
datos anteriores, y nos llega un paquete
enfrascada en su asunto inmediato, que
con datos urgentes, normalmente
es mostrar el listado del archivo, y no
aplazaremos el procesamiento de los
habría hecho caso a nuestro CONTROL-
datos anteriores para prestar toda nuestra
C hasta que no hubiera terminado con lo
atención a los datos urgentes.
suyo.
¿Y para qué pueden servir los datos

Para garantizar una mayor efectividad del
urgentes? No es habitual encontrarlos,
flag URG hay que combinarlo con el flag
pero un claro ejemplo es cuando
PSH, que veremos más adelante.
deseamos abortar alguna acción. Por
ejemplo, si alguna vez habéis conectado
por Telnet con un sistema remoto (el
4.7.2. Flag ACK (Acknowledge)
propio servicio de Telnet del puerto 23,
no los experimentos raros que hacíamos Cuando este flag está activo (vale 1, en
en la serie RAW ;-) sabréis que con la lugar de 0) significa que nuestro paquete,
combinación de teclas CONTROL- C se aparte de los datos propios que pueda
puede abortar cualquier acción. c o n t e n e r, c o n t i e n e a d e m á s u n a

confirmación de respuesta a los

paquetes que está enviando el otro
extremo de la conexión.
Por tanto, el campo número de

confirmación no tiene significado a no
ser que esté activo este flag.
4.7.3. Flag PSH (Push)
En la imagen podemos ver cómo los

paquetes sin flag PSH se van encolando
lugar de 0) indicamos a nuestro propio
en el buffer de transmisión. Cuando el
sistema, y al sistema remoto con el que
sistema construye el último paquete (el
estamos conectados, que deben vaciar
paquete Seq = 300), ya puede comenzar
sus buffers de transmisión y recepción... el envío del archivo. Por tanto, en el último
Creo que ha llegado el momento de hablar paquete incluye el flag PSH.
sobre los buffers de transmisión y
recepción. :-m A partir del instante en que hemos metido
en el buffer el paquete con flag PSH, el
sistema irá enviando uno tras otro los
En todo sistema TCP tiene que haber dos
paquetes a través del cuello de botella
pequeñas memorias, o buffers: una para
que supone el canal de salida. Se trata
transmisión, y otra para recepción. Estas
de un cuello de botella porque por él sólo
memorias son unas colas de paquetes
puede pasar un único paquete en cada
en las que se van almacenando los instante, por lo que los paquetes tendrán
paquetes que hay que procesar en espera que ir enviándose de uno en uno según
del momento adecuado. el orden en que fueron ubicados en el
buffer de transmisión. Al tratarse de una
Por ejemplo, supongamos que una cola, el primero en llegar será el primero
aplicación que corre en nuestro sistema en salir (lo que se llama una cola FIFO),
desea enviar un archivo, que será partido por lo que primero saldrá el paquete con
en 4 paquetes TCP. A pesar de que Seq = 0.
nuestra aplicación lance la orden de enviar
el archivo en un sólo instante, nuestro El último paquete en salir será el que
sistema no podrá enviar de golpe los 4 tiene Seq = 300, que es precisamente el
paquetes. Por tanto, tendrá que construir que lleva el flag PSH. En la siguiente
los paquetes, y luego ponerlos en una imagen vemos todo esto desde el punto
cola para que se vayan enviando uno tras de vista del receptor.
otro.
Si el sistema pudiera enviar los 4 paquetes

a la vez no habría necesidad de tener
ninguna cola, pero en la práctica, como
en cualquier cola, sólo se puede pasar
de uno en uno.

Por el canal de entrada irán llegando los servidor el resto de nuestros intentos de
paquetes uno tras otro. Se irán conexión, el servidor nos responderá con
almacenando en el buffer de recepción, RST a cada nuevo intento de conexión,
y no serán procesados hasta que llegue para que nos olvidemos de esa conexión
el último paquete, que contiene el flag y nos centremos en la que ya tenemos.
PSH. Como este paquete es el que
completa el archivo de 400B, para cuando 4.7.5. Flag SYN (Synchronization)
llegue, el sistema receptor ya podrá
procesar los datos de los 4 paquetes y Cuando este flag está activo (vale 1, en
reconstruir el archivo original. lugar de 0), estamos indicando al otro
extremo que deseamos establecer una
Como decíamos, el flag PSH debe nueva conexión. Este flag se utiliza
combinarse con el flag URG cuando haya únicamente al abrir una nueva conexión.
datos urgentes. El flag URG será el
encargado de decir al receptor que ha Más adelante veremos el mecanismo
de atender los datos con máxima exacto por el que se establecen las
prioridad, y el flag PSH se asegurará de conexiones, así como algunas cuestiones
que el paquete no se retrase esperando de seguridad relacionadas con este flag.
en los buffers.
4.7.6. Flag FIN (Finish)
4.7.4. Flag RST (Reset)
Cuando este flag está activo (vale 1, en lugar de 0), indicamos al otro extremo
lugar de 0), estamos indicando al otro de la conexión de que, por lo que a
extremo de la conexión que algo no anda nosotros respecta, la conexión ya se
bien, ya que los datos que nos han llegado puede cerrar.
no coinciden con nuestra conexión, por
lo que se ha perdido la sincronización Normalmente, una vez que enviemos
entre ambas partes. nuestro propio FIN, tendremos que
esperar a que nuestro compañero nos
Ante cualquier campo incorrecto que envíe el suyo. Una vez puestos los dos
recibamos (números de secuencia de acuerdo en que no hay más que hablar,
inválidos, o flags no esperados) se puede cerrar la conexión pacíficamente.
tendremos que responder con un paquete
con este flag activo, para que el otro
Tanto RST como FIN se utilizan para
extremo se entere del problema, y se
finalizar conexiones, pero la diferencia es
cierre la conexión para re-sincronizar
que RST avisa de una situación de error,
ambas partes.
mientras que FIN avisa de una
terminación sin problemas.
Un uso típico de este flag es cuando
estamos intentando conectar con un
servidor, enviando varios paquetes para Ante una terminación con RST,
establecer la conexión, y al final uno de normalmente las aplicaciones avisarán al
ellos tiene éxito. Si después de ese usuario, por ejemplo con una ventana
paquete de conexión siguen llegando al avisando que se ha perdido la conexión.

4.8. Ventana En primer lugar, la máquina A envía un

paquete de 1000 Bytes, con número de
Este campo es el que se utiliza para llevar secuencia 0.
a cabo el control de flujo implementado
en TCP. La máquina B lo recibe y procesa
correctamente, y envía su confirmación
Como ya dije, el control de flujo permite de recepción, indicando que la máquina
evitar la congestión debida a la diferencia A puede continuar enviando a partir del
de velocidad (bien por capacidad de byte 1000 (Ack=1000). Además, le indica
procesamiento, o bien por ancho de que está preparada para recibir otros
banda) entre ambas partes de una 1000 bytes más. Si hacemos cuentas, en
conexión. realidad lo que está diciendo la máquina
B es que está preparada para recibir los
Una forma muy sencilla de conseguir esto bytes del 1000 al 1999.
es hacer que cada extremo de la conexión
vaya indicando a cada momento cómo La máquina A continúa transmitiendo, y
de congestionado está. La mejor forma lo hace esta vez con 1000 bytes más de
de indicar esta medida de congestión es datos, empezando, por supuesto, por el
decir cuántos bytes vamos a ser capaces número de secuencia 1000.
de procesar en un momento dado.
La máquina B también los recibe sin
Por tanto, a cada paquete le acompaña problemas, pero se está empezando a
un número de 16 bits, que es el número agobiar un poco, por lo que avisa en su
de bytes que estamos preparados confirmación de que el próximo paquete
para recibir en el próximo paquete. Esto no podrá ser tan grande y, como mucho,
significa que, como máximo, un paquete tendrá que ser de 500 bytes nada más.
podrá contener 65536 bytes de datos,
es decir, 64KB, ya que es el máximo que La máquina A, en cambio, no ha recibido
podemos solicitar en cada momento. a tiempo la nueva ventana, y ha seguido
enviando los paquetes al ritmo que llevaba
Normalmente, el tamaño de la ventana anteriormente. Por tanto, el próximo
está relacionado con la cantidad de paquete (Seq=2000) contiene también
espacio libre que tenemos en el buffer 1000 bytes de datos, a pesar de que la
de recepción. nueva ventana de B admite sólo 500
bytes.
Vamos a ver un ejemplo.
Justo después de enviar este paquete
demasiado grande, la máquina A recibe
ya el aviso de B de que se está
congestionando, por lo que decide esperar
a ver cómo se las apaña su compañero.
Cuando B ha podido procesar unos

cuantos datos, avisa a A de que puede
seguir enviando, aunque sólo ha procesado
500 bytes de los 1000 que le envió y,

además, el próximo paquete tendrá que mensaje (vacío si hace falta) cuya única
ser como máximo de 250 bytes. finalidad sea precisamente avisar del
cambio de la ventana. Por otra parte, la
En respuesta, A envía un nuevo paquete, responsabilidad del emisor (el que ha
comenzando en el byte 2500, y congestionado al otro) es dejar de enviar
conteniendo tan sólo 250 bytes. más datos, y esperar un tiempo prudencial
para continuar la transmisión pasados
Todo esto es muy bonito, A y B son muy unos dos minutos, si es que el receptor
amigos, y A le va enviando a B las cosas no ha enviado una nueva ventana antes.
poco a poco cuando éste se agobia. Pero
esto en realidad no es una idea muy 4.9. Suma de comprobación
buena. Si A va haciendo caso a B según Al igual que en el caso de UDP, la suma
éste le vaya diciendo lo que puede de comprobación se calcula mediante una
manejar, y B va avisando a A según vaya operación de aritmética binaria (suma en
liberando hueco en su buffer de recepción, complemento a uno de 16 bits) que se
los paquetes que se transmitan irán realiza sobre una cabecera especial que
siendo cada vez más pequeños. contiene los datos más relevantes.
En el peor de los casos, podría llegar a Cada vez que se recibe un paquete TCP,
ser 0 la ventana de B, y en el instante hay que realizar esta misma operación
en que hiciese hueco para un mísero con los datos recibidos, y comparar el
byte, avisar a A, por lo que A le enviaría número obtenido con el campo suma de
un paquete con un único byte de datos. comprobación del paquete. Si ambos
Esto daría lugar a una transferencia muy números no son iguales, los datos son
poco efectiva de los datos, donde muchos incorrectos, y será necesaria una
de los paquetes serían de un tamaño retransmisión de los mismos. En ese caso,
ridículo. no enviaremos la confirmación de
recepción pertinente, esperando a que el
Por tanto, es aconsejable no ir emisor decida retransmitir el paquete al
ajustándose literalmente al tamaño de ver que no les respondemos.
la ventana, si no dejar unos pequeños
márgenes. Por ejemplo, cuando se detecte Aunque ya lo comenté en el anterior
que la ventana va decreciendo por artículo, os recuerdo que tenéis detallada
momentos, lo mejor es esperar un tiempo la operación de la suma de comprobación
para dejar que la ventana vuelva a en el RFC 1071, y que tenéis un código
recuperar toda su capacidad, y continuar de ejemplo en C en la siguiente URL:
entonces la transmisión. Si fuésemos con http://www.netfor2.com/tcpsum.htm
prisas, empeñándonos en enviar más y
más datos, la reducción de tamaño de la En este caso no tenéis que realizar ninguna
ventana sería cada vez mayor, y la modificación sobre el código, ya que sirve
transferencia cada vez menos eficiente. precisamente para calcular la suma de
comprobación de TCP.
En el caso de que la ventana llegue a ser
La cabecera que se forma para llevar a
cero, la responsabilidad del receptor (el
cabo la suma de comprobación es la
que se ha congestionado) es avisar
siguiente:
cuando su ventana se recupere, con un

4.11. Opciones
Llegamos al fin al último campo de la

Como vemos, es igual que la de UDP, cabecera TCP. Este campo es opcional, y
sólo que en este caso el protocolo es el es el responsable de que la cabecera TCP
6, en lugar del 17. sea de tamaño variable y, por tanto, de
la necesidad del campo comienzo de
4.10. Puntero de urgencia datos. En realidad, sólo existe una opción
definida por el estándar en el RFC de
Cuando hablamos sobre el flag URG
TCP, pero la cabecera se diseñó con
dijimos que servía para indicar que el
previsión de incluir otras opciones.
paquete contiene datos urgentes.
Pero, ¿significa esto que los datos tienen La opción definida se utiliza únicamente
que ir en un único paquete para ellos al establecer una nueva conexión. Lo que
solos? Esto podría ser poco eficiente, ya indica este campo opcional es el máximo
que los datos urgentes podrían ser tan tamaño de los segmentos que estamos
sólo unos pocos bytes, y nos obligaría a dispuestos a recibir. Un segmento es cada
enviar paquetes casi vacíos sólo para una de las partes en las que se dividen
poder transmitir el dato urgente. los datos, por lo que nuestro compañero
de conexión no debe enviarnos nunca
Por ejemplo, el CONTROL-C del que paquetes más grandes de lo que
hablábamos, es un comando muy breve, indiquemos con esta opción. En el caso
y sería un desperdicio enviar paquetes de que no usemos este campo opcional,
vacíos que sólo llevasen ese comando. nos podrá enviar paquetes de cualquier
Por tanto, TCP permite combinar en tamaño ajustándose, eso sí, a nuestra
un mismo paquete datos urgentes ventana de recepción.
con datos no urgentes.
¿Y qué relación hay entonces entre la
Para conseguir esto, el campo puntero
ventana de recepción y el tamaño máximo
de urgencia nos indica el punto a partir
de segmento?
del cual terminan los datos urgentes.
Si, por ejemplo, nuestro paquete contiene Pues la ventana es un parámetro dinámico,
1000 bytes de datos, y el puntero de que va variando según la congestión que
urgencia es 150, sabremos que los 150 hay en cada momento, mientras que el
primeros bytes del paquete son urgentes, tamaño máximo de segmento es una
y los otros 850 son datos normales. constante para toda la sesión, que se
Por supuesto, esto sólo tendrá sentido si establece de antemano. Muchas veces,
el flag URG está activo. Si no es así, el el tamaño máximo de segmento será
campo puntero de urgencia menor que la ventana. Esto puede parecer
simplemente será ignorado. absurdo, pero no es así, ya que el tener

una ventana mayor que el tamaño La opción que hemos mencionado, la

máximo de segmento indica que tenemos única definida en el RFC, encaja
recursos suficientes para recibir varios exactamente en 32 bits, por lo que no
paquetes en poco tiempo. hay que hacer ningún ajuste. El formato
exacto de esta opción lo veremos más
Por tanto, el tamaño máximo de
adelante cuando veamos las cabeceras a
segmento no es útil para realizar un
nivel de bits.
control de flujo, si no tan sólo una
restricción para el tamaño máximo que
En cambio, no sólo existen las opciones
pueden tener los paquetes.
definidas en el RFC 793. Podemos ver
Pero vamos a ver cómo se indica una lista de opciones TCP mantenidas,
exactamente esta opción. Como ya hemos p a r a v a r i a r, p o r e l I A N A , e n :
visto, existen dos casos: o que no http://www.iana.org/assignments/tcp-
indiquemos ninguna opción, o que parameters
indiquemos el tamaño máximo de
segmento. Una opción que nos podremos encontrar
En el primer caso, simplemente terminará con facilidad de las de esa lista, es la
en este punto la cabecera TCP, y opción SACK, utilizada para
comenzarán a partir de aquí los datos. confirmaciones selectivas (Selective
Por eso, cuando hablábamos del campo ACKnowledgment).
comienzo de datos dijimos que el Los detalles sobre esta opción los tenéis
tamaño mínimo de la cabecera (que es en el RFC 2018 (ftp://ftp.rfc-editor.org/in-
este caso) es de 20 bytes. notes/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 opción especial sin ningún efecto
(NOP = No OPeration) que ocupa un
único byte.
Para terminar la lista de opciones existe

también otra opción especial, de un único
byte, que indica que no hay mas opciones
En el segundo caso, en cambio, habrá y, por tanto, una vez completada la palabra
que rellenar el campo opciones de la de 32 bits, vendrán a continuación los
cabecera. Y no sólo eso, si no que además datos del paquete.
hay que ajustarlo a un tamaño de 32
bits, que es lo que ocupa cada fila de la Todo esto lo veremos en más detalle
cabecera TCP (en realidad, se trata del en el próximo artículo, en el cual
tamaño de la palabra, ya que la idea de empezaremos construyendo como
filas es sólo una abstracción para ver ejercicio una cabecera TCP desde cero
más fácilmente la estructura de la a bajo nivel, es decir, en binario puro
cabecera). y duro. Espero que estéis preparados!
;-)

Para terminar, os incluyo aquí la cabecera

TCP con los nombres originales, en inglés, ! IMPORTANTE
por si completáis este curso con alguna
otra lectura, para que veáis la IMPORTANTE:
correspondencia y no os liéis. Ya habrá tiempo de pasar a la practica, ahora es importante
que empecemos a familiarizarnos con un montón de
términos y conceptos que seguramente (para la mayoría)
son completamente desconocidos.
No te preocupes demasiado si muchas cosas te han quedado

oscuras, ya empezarás a verlas claras cuando relacionemos
la teoría con la practica y veas la utilidad real de cada
concepto explicado aquí.
Autor: PyC (LCo)

CURSO DE TCP/IP: 4ª ENTREGA
TCP (TRANSMISION CONTROL PROTOCOL)
2ª parte
Este mes nos metemos de lleno en los paquetes de Internet. Crearemos un paquete desde
cero, nos adentraremos en el código binario y para rematar comprenderemos de una
vez por todas el significado de algunos ataques ya conocidos por todos.
1. Fundamentos de la esos ceros y unos de los que vamos a hablar

comunicación digital. ahora.
Cuando empecé con el curso de TCP/IP, cuya De momento, nos quedaremos con una
cuarta entrega tenéis ahora mismo en vuestras simplificación de la idea de qué es exactamente
manos, ya os advertí de que, cansado de ver un cero y un uno. Como sabemos, los datos
una y otra vez las mismas técnicas para que circulan en una red lo hacen siempre a
explicar los conceptos en todos los libros y través de un medio físico. Este medio,
tutoriales, este curso pretendía ser una normalmente, será un cable eléctrico, pero
apuesta arriesgada, orientando la explicación puede ser también, por ejemplo, una onda de
de los mismos conceptos desde un punto de radiofrecuencia, un cable óptico, o cualquier
vista bastante diferente. otro medio físico empleado en la interconexión
de máquinas. Quedémonos con el caso más
Siguiendo en esta línea un tanto experimental, común, el del cable eléctrico, aunque todo lo
voy a dar otro nuevo paso que no he visto explicado se puede extrapolar, por supuesto,
en ningún libro sobre TCP/IP, para tratar de a cualquier otro medio físico.
que os familiaricéis más aún con TCP/IP.
Como es lógico, por un cable eléctrico circula
Lo que pretendo conseguir ahora es que electricidad. La electricidad por si misma no
convirtáis esos misteriosos paquetes TCP que contiene mucha información. Un medio de
tenéis rondando ahora mismo por vuestras transmisión de información será más versátil
cabezas, en algo tangible, de carne y hueso, cuantos más parámetros posea.
o más bien debería decir de unos y ceros.
Por ejemplo, una imagen puede transmitir
Para ello, vamos a ver con un ejemplo cómo una gran cantidad de información (ya se sabe
está construido exactamente un paquete TCP. que una imagen vale más que mil palabras),
Mi intención es que después de este ejemplo, ya que posee muchísimos parámetros, como
los paquetes TCP dejen de ser al fin para son los colores en cada punto, la iluminación,
vosotros unos entes teóricos de los cuales etc. En cambio, la electricidad posee pocos
conocéis el funcionamiento, pero no su parámetros propios, como pueden ser la
constitución física. tensión eléctrica (voltaje), y la intensidad
eléctrica (corriente). Para colmo, estos dos
Por supuesto, esta constitución física no parámetros están directamente relacionados
podremos terminar de comprenderla hasta entre sí (¿recordáis la famosa ley de Ohm, o
que lleguemos a la capa inferior de la jerarquía vosotros también suspendíais física en el cole?
de capas de TCP/IP: el nivel físico. Así que
habrá que esperar aún unos cuantos meses Por tanto, una primera solución intuitiva para
antes de que veamos qué son exactamente transmitir información por medio de la

Curso de TCP/IP - TCP (II) - Curso de TCP/IP - TCP (II) - Curso de TCP/IP - TCP (II)
electricidad sería hacer variar esos parámetros Siempre habréis escuchado el término
en función de lo que quisiéramos transmitir. analógico como opuesto al término digital.
Vamos a ver ahora mismo en qué consisten
Por ejemplo, si queremos transmitir un las diferencias entre analógico y digital.
número, podemos ajustar el voltaje del cable
en relación directa con el valor de ese número. Si bien la tecnología analógica aprovecha la
Por ejemplo, para transmitir un 5 pondríamos tensión eléctrica, uno de los parámetros que
5 voltios en el cable, y para transmitir un 7 caracterizan la electricidad que circula por un
pondríamos 7 voltios en el cable. Si, en cable, la tecnología digital no utiliza ninguno
cambio, queremos transmitir el número de los parámetros de la electricidad para
250000, más nos vale no tocar el cablecito, transmitir la información.
a no ser que queramos seguir este curso
desde el más allá (allí también llega, desde ¿Cómo puede transmitirse la información
que la revista cambió de distribuidor). entonces? Evidentemente, siempre es
imprescindible la presencia de una variable
Supongo que las mentes más despiertas que se pueda modificar convenientemente
habrán descubierto ya aquí una de las más para codificar la información que se desea
destructivas técnicas de hacking. Si algún día transmitir. La diferencia es que en el caso de
os encontráis por un chat al <malnacido> ese la transmisión digital el parámetro que se
que os robó la novia, basta con que le enviéis utiliza para portar la información no es
un paquete que contenga un número tocho inherente a la propia electricidad, si no que
con ganas, como el 176874375618276543, es un parámetro más sencillo: el tiempo.
y por su módem circulará tal tensión eléctrica,
que en el lugar que ocupaba su casa veréis Evidentemente, el tiempo es siempre un
un cono atómico que ni el de Hiroshima. parámetro fundamental en toda comunicación,
ya que es imprescindible que haya una
Bueno, antes de que se me eche alguien sincronización temporal entre transmisor y
encima por decir semejantes estupideces, receptor.
tendré que reconocer que, como es lógico,
las cosas no funcionan así en la práctica. Volviendo al caso de la transmisión analógica,
¡Pero no os creáis que sea algo tan pensemos por ejemplo en el caso en el que
descabellado! ¿Y si en lugar de una proporción se transmitan sólo números del 0 al 9 y, para
1/1 utilizamos otra clase de proporcionalidad conseguir representar números más altos lo
para transmitir los números? que se hace es transmitir cada una de sus
cifras por separado (unidades, decenas,
Por ejemplo, supongamos que no queremos centenas, etc.). Si, por ejemplo, quisiéramos
superar los 10 voltios y, en cambio, queremos 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
transmitir números entre 1 y 1000. Pues basta transmitiríamos 5 voltios, luego 2 voltios, y
con que establezcamos el convenio de que por último 3 voltios.
10 voltios equivalen al número 1000 y, por
tanto, 5 voltios al 500, 25 voltios al 250, etc., En la imagen podemos
etc. ver la transmisión del
número 523 por una
Esta solución no sólo es mucho más realista,
línea analógica. En el eje
si no que incluso ha sido el sistema de
X (el horizontal) se
transmisión de información en el que se ha
representa el tiempo, por
basado toda la electrónica hasta que llegó la
ejemplo, en segundos, y
revolución digital. Y el nombre de esto os
en el eje Y (el vertical)
sonará mucho, ya que a esto es a lo que se
se representa la tensión en voltios.
llama comunicación ANALÓGICA.

Lógicamente, es necesario establecer un Por tanto, si queremos transmitir digitalmente

convenio entre el transmisor y el receptor el número 9, estos serán los voltajes que
para saber cuánto tiempo tiene que pasar tendremos que poner en la línea:
entre la transmisión de cada cifra. Si no fuese
así, imaginad lo que pasaría si tratásemos de Es decir, primero 1 voltio
transmitir el número 5551. Si la línea se durante un segundo,
mantiene en 5 voltios el tiempo necesario luego 0 voltios durante
para transmitir las tres primeras cifras, ¿cómo dos segundos y, por
podrá saber el receptor que en ese tiempo último, 1 voltio durante
se han transmitido tres cincos, y no sólo uno, el último segundo.
o doce?
¿Cómo podemos entonces transmitir un
Por tanto, ha de existir un convenio previo número de dos cifras, como por ejemplo el
entre emisor y receptor que diga cada 12?
segundo se transmitirá una nueva cifra. Por Pues de nuevo hay que hacer otro convenio
tanto, si pasado un segundo el voltaje no ha entre el emisor y el receptor y decir: cada
cambiado, significa que la siguiente cifra es cifra decimal va a constar de 4 cifras binarias.
igual a la anterior. Por tanto, si transmitimos la secuencia: 0001
0010 (ver la tabla anterior) estaremos
Lo que hace la tecnología digital es explotar transmitiendo el número 12, según el convenio
al máximo este tipo de convenios. Pero preestablecido, tal y como vemos en la
empecemos viendo el caso más simple de siguiente imagen.
todos, que es igual al caso de la transmisión
analógica.
Imaginemos que queremos transmitir números

pero que sólo puedan ser 0 o 1. En ese caso,
la cosa funcionaría igual: a cada segundo una De esta manera, a base de acuerdos entre el
nueva cifra, y no hay más misterio. La transmisor y el receptor, podemos transmitir
diferencia sería que la tensión sólo podría cualquier información, con sólo transmitir ceros
tener dos valores: 0 o 1 voltios. y unos.
La diferencia viene cuando queremos
transmitir números más grandes, que es ¿Cuál es la ventaja de transmitir sólo dos
cuando hay que hacer convenios raros. valores en lugar de variar el voltaje en función
del valor que se desea transmitir? Pues son
En realidad, estos convenios tienen poco de varias las ventajas, pero la más obvia es la
raro, al menos para un matemático, ya que gran fiabilidad de la transmisión.
no es ninguna invención, si no simplemente
una aplicación directa de las matemáticas. Imaginemos que nuestro cable lo hemos
Concretamente, lo que se aplica es la comprado en el Todo a 100 y falla más que
aritmética binaria. una escopeta de feria. Pretendemos transmitir
5 voltios y, en cambio, unas veces el cable
Este convenio asigna transmite 4 voltios, otras veces 3,5, otras
una secuencia veces 2...
diferente para
representar cada Estos fallos del cable serían críticos en una
número decimal, que transmisión analógica, ya que el voltaje se
podemos ver en la traduce directamente en la información que
tabla de la izquierda. transmitimos. En cambio, la transmisión digital

nos permite unos márgenes de error muy

grandes. Al fin y al cabo, transmitir ceros y ! ¿Y si el mundo...
unos se limita tan sólo a diferenciar no hay
electricidad en el cable de sí hay electricidad
¿Y si el mundo fuese distinto?
en el cable. 1. Muchas personas, cuando les dices que el mundo informático
Por tanto, podemos decir por ejemplo: si funciona con CEROS y UNOS, nunca llegan a entenderlo. Con
hay menos de un voltio en el cable, lo sencillo que sería trabajar con el sistema decimal
consideramos que es un cero. Si hay más de (0,1,2,3,4,5,6,7,8,9) e incluso con letras.
un voltio, consideramos que es un uno. Así,
todos esos fallos del cable de Todo a 100 no Acabamos de descubrir que aplicar el sistema decimal supondría
afectarían a la transmisión digital, ya que 10 niveles de voltaje en un cable eléctrico, algo técnicamente
incluso 2 voltios seguiría siendo considerado posible pero MUY CARO. Como ya hemos dicho los cables
como sí hay electricidad en el cable y, por deberían ser muy buenos y los dispositivos que detectasen los
tanto, sería considerado como un 1. cambios de voltaje deberían ser muy precisos. Pero esto es
hablando del mundo analógico si nos vamos al digital la cosa
Son muchas otras las ventajas de lo digital se pone interesante.
frente a lo analógico, como la mayor facilidad
a la hora de almacenar y procesar la Hemos dicho que en el MUNDO DIGITAL solo hay dos estados,
información, pero esas ventajas no se deducen es decir, "unos" (abierto, con electricidad, iluminado) y ceros
de lo explicado hasta ahora, por lo que no (cerrado, sin electricidad, apagado). Pero ¿por qué? ¿por qué el
entraremos ahora en más detalle. De hombre ha decidido que el mundo digital solo tenga dos estados
momento, la idea con la que nos tenemos en lugar de 10?
que quedar es con que a la hora de transmitir
información, la transmisión digital tiene una Muy sencillo, POR DINERO!!! ¿Cómo? ¿qué?... En el diminuto
mayor inmunidad al ruido y, en general, a universo que conocemos, nuestro planeta, es muy sencillo (y
cualquier error, que la transmisión analógica. barato) encontrar sustancias que sean capaces de tener dos estados
claramente diferenciados, que puedan ser capaces de pasar de un
Por supuesto, nada de lo explicado hasta estado a otro muy rápidamente, que lo hagan de forma barata y
ahora es en la práctica tal y como lo he para colmo que sea muy fácil detectar esos estados.
contado (para aquellos que sepan de qué va
el tema y estén flipando), pero mi intención Al igual que una bombilla puede estar encendida o apagada y
no es escribir un RFC sobre transmisión todos podemos percibirlo mirándola (luz/oscuridad) o tocándola
analógica vs. transmisión digital, si no tan (calor/frío), en el caso de la informática EL DIOS ES EL SILICIO.
sólo explicar conceptos, aunque tenga que Simplificando mucho el tema, podemos decir el silicio deja pasar
ser faltando a la realidad en muchas la electricidad o no (ceros y unos), lo hace rapidísimamente (todos
ocasiones. Lo importante es que comprendáis queremos tener un PC ultrarrápido) y detectar el estado ("cargado"
los conceptos que subyacen a una transmisión o "descargado") es tecnológicamente sencillo y por lo tanto barato.
de datos digitales, como es el caso de TCP/IP.
¿Y si el mundo fuese distinto?
Para los más quisquillosos que sigan Imagina otro elemento, por ejemplo el agua. Todos conocemos
insistiendo en que las cosas no son así, y que tres de sus estados, el sólido, el líquido y el gaseoso si el agua
realmente incluso las transmisiones digitales se pareciese al silicio (si fuese sencillo pasar de un estado a otro,
circulan de forma analógica, insisto en que lo hiciese a la velocidad del rayo y fuese sencillo detectar esos
no estoy tratando de explicar el nivel físico cambios de estado) nuestro ordenador estaría basado en un
(cosa que ya haré dentro de unos cuantos procesador de agua y, en ese caso sería MUCHO más potente
artículos, y donde todo esto quedará y rápido que los que ahora tenemos basados en silicio.
finalmente aclarado), si no tan sólo
abstraerme de los detalles para explicar los ¿Qué? ¿Cómo? Sí, porque tendríamos un sistema de TRES
estados (apagado -hielo-, neutro -líquido- y encendido -gaseoso-)
conceptos básicos.

los ordenadores personales, llamamos byte.

en lugar de DOS estados (apagado/encendido). Eso significa que Un byte es simplemente una palabra de 8 bits,
en lugar del código BINARIO utilizaríamos el código TRINÁRIO es decir, de 8 cifras binarias (cero o uno). Si
(el nombre me lo acabo de inventar). Al haber tres estados en quisiéramos representar los números decimales
lugar de dos podríamos crear convenios mucho más optimizados, con un byte, ésta podría ser la tabla
es decir, transmitir información de forma mucho más optimizada correspondiente:
y por lo tanto mucho más rápida.
Deja volar tu imaginación si un buen día 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
informático daría un salto astronómico en velocidad de cálculo.
Para la humanidad sería comparable al paso de la edad de Piedra
a la edad de Hierro.
Actualmente, a falta de materiales nuevos los científicos intentan

utilizar elementos conocidos pero difíciles de "controlar". Unos
basados en dos estados y otros en multiestados por ejemplo
los átomos.
Vamos al fin a ver algo directamente
Al final, la orgullosa humanidad depende de los materiales que relacionado con TCP. Volvamos al último artículo
su "humilde" entorno proporciona. de la revista, y repasemos la cabecera TCP.
Por si no lo tenéis a mano, aquí os la vuelvo
a mostrar.
2.- Codificación binaria.
Llegados a este punto, posiblemente ya

habréis perdido un poco de miedo a eso de
los ceros y los unos. Lo que nos queda por
ver es cómo se codifica realmente la
información en binario (utilizando tan sólo
ceros y unos), es decir, cuáles 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 Como vemos, en la cabecera TCP se manejan
representa la información depende del tamaño distintos tamaños de palabra. En primer lugar,
de la palabra utilizada. En el ejemplo anterior, para los campos puerto origen y puerto
donde representábamos cada número decimal destino contamos con 16 bits, después, para
con 4 cifras binarias, es decir, con 4 bits (bit los números de secuencia y de
es simplemente el nombre dado a una cifra confirmación tenemos 32 bits, 4 bits para
binaria, es decir, un número que sólo puede el campo comienzo de datos, 1 bit para cada
ser un cero o un uno), teníamos una palabra uno de los flags, etc.
de 4 bits para representar los números
decimales. Para saber cuántos valores se pueden
representar con cada tamaño de palabra, basta
La palabra más comúnmente utilizada en con hacer la potencia de 2 con el tamaño
informática es el octeto que, en el caso de de la palabra en bits. Es decir, con una

4
palabra de 4 bits podemos representar 2 = 2.1. P a s a n d o d e b i n a r i o a
16 valores diferentes, con una palabra de 8
8 16 decimal
bits 2 = 256 valores, con 16 bits 2 =
65536, etc.
Vamos a ver en primer lugar cómo traducir
una secuencia de ceros y unos en algo
Ahora podéis comprender por qué todo lo
comprensible para nuestras mentes decimales.
relacionado con la tecnología digital sigue
siempre estos números. La memoria RAM que
En la base decimal, que es la que nosotros
compras para el PC, las tarjetas de memoria
utilizamos, llamamos a cada cifra de una
para la cámara digital, la velocidad del ADSL,
manera diferente según el orden que ocupa:
siempre son los mismos números; 8, 16, 32,
unidades, decenas, centenas, etc. Como nos
64, 128, 256, 512, 1024, 2048... Todos esos
explicaron en los primeros años del cole, para
números son las diferentes potencias de 2.
calcular un número a partir de su
representación decimal, tenemos que sumar
El caso más sencillo es el de 1 único bit,
1 las unidades a las decenas multiplicadas por
donde tenemos 2 = 2, es decir, se pueden
diez, las centenas multiplicadas por 100, etc.,
representar sólo 2 valores con 1 bit. Estos 2
etc. Es decir: 534 = 5 * 100 + 3 * 10 + 4 * 1.
valores son, por supuesto: cero, y uno.
2
En realidad, 100 es una potencia de 10 (10
En el caso, por ejemplo, de 3 bits, tenemos
3 = 100). Y por supuesto 10 también es una
2 = 8 valores diferentes, que son todas las 1
potencia de 10 (10 = 10). pero también el
posibles combinaciones de 3 cifras, donde
1 lo es, ya que 1 es potencia de cualquier
cada cifra puede ser un uno o un cero, tal y 0
número, pues X = 1, donde en este caso, es
como vemos en la tabla.
X = 10, es decir, 10 elevado a cero es uno.
Como vemos, no
Por tanto, el número 534 se puede representar
quedan más 2 1 0
como: 534 = 5*10 + 3*10 + 4*10 .
p o s i b l e s
combinaciones de
Esta regla se puede aplicar a cualquier otra
ceros y unos con
base que no sea 10. Volvamos a la tabla
sólo 3 cifras, y
anterior, y veremos que el número 7 se
esto nos permite
representa como 111 en base 2.
representar tan
sólo los números Si aplicamos la fórmula anterior, pero en este
del 0 al 7. caso utilizando base 2, tendremos:
2 1 0
1 * 2 + 1*2 + 1*2 = 7. En efecto, se
Como ya dije antes, para un matemático estos 2 1 0
cumple, ya que 2 = 4, 2 = 2, y 2 = 1,
convenios para representar los números luego: 1*4 + 1*2 + 1*1 = 7.
decimales mediante cifras binarias no son
ningún misterio, ya que basta con aplicar las Con esta sencilla fórmula de las potencias de
bases de la aritmética modular. 2 se puede convertir cualquier número binario
a su equivalente en decimal. Por ejemplo,
Voy a tratar de explicar rápidamente en qué vamos a traducir a decimal el número
consisten estas fórmulas porque, aunque al 10011010.
principio os puedan parecer complicadas, en 7
Empezamos aplicando la fórmula: 1*2 +
realidad son realmente sencillas y, como todo, 6 5 4 3 2 1
0*2 + 0*2 + 1*2 + 1*2 + 0*2 + 1*2
es sólo cuestión de práctica el aplicarlas de 0
+ 0*2 . Ahora, sabiendo los valores de cada
forma natural.
potencia de dos (cualquier geek que se precie
tiene que conocer como mínimo todas las

potencias de 2 con exponentes de 0 a 16), Pero nosotros no nos conformamos con hacer
podemos traducir esa fórmula en: 1*128 + las cosas, si no que nuestro auténtico interés
0*64 + 0*32 + 1*16 + 1*8 + 0*4 + 1*2 + es el saber cómo se hacen. Así que os explico
0*1. Es decir, nos queda la siguiente suma: rápidamente un algoritmo para convertir
128 + 16 + 8 + 2 = 154. Por tanto, el número cualquier número decimal a binario.
binario 10011010 representa al número 154
en decimal. Usemos para el ejemplo el número 137.
Por si queréis practicar, os dejo como ejercicio El proceso a seguir será ir dividiendo el
algunos números más, con su traducción, número (en este caso 137) por 2 y, en cada
para que lo comprobéis vosotros mismos: división, quedarnos con el resto de la división
(que sólo podrá ser cero o uno). Ahora te
10110101 = 181
quedará claro.
00111100 = 60
111010001010101010100101 = 15248037
El resultado de la primera
división (llamado cociente, en
2.2. Pasando de decimal a
verde) es 68, y el resto (en
binario.
rojo) es 1. Este 1 será el bit
Aquí la cosa ya se pone más chunga. Aun así, menos significativo, es decir, la cifra binaria
juraría que esto ya lo expliqué en alguno de que está a la derecha del todo.
mis artículos.
Continuamos el proceso con el nuevo cociente
Hay varios trucos para convertir de decimal que hemos obtenido:
a binario. El más sencillo, por supuesto, es
meter el número en la calculadora de windows, Ahora hemos obtenido un 0,
y luego pinchar en donde pone BIN para que que será la siguiente cifra
lo pase automáticamente, jeje. binaria. Continuamos el proceso
con el nuevo cociente, 34:
3 4 / 2 = 1 7 , con re st o 0.
17 / 2 = 8, con resto 1.
8 / 2 = 4, con resto 0.
4 / 2 = 2, con resto 0.
2 / 2 = 1, con resto 0.
Esta última operación (en azul) es fundamental,

ya que el bit más significativo, es decir, el que
hay más a la izquierda, será el último cociente,
es decir 2/2 = 1.
Por tanto, el número 137 en binario nos

quedará: 1 0 0 0 1 0 0 1.
! Para que...
! Si tienes...
Para que a nadie se le ocurra enviar un mail diciendo que la
calculadora de Windows no puede hacer eso, venga, lo explicamos Si tienes interés en avanzar por tu cuanta en cálculo binario, hay
muy rápido. Abre la calculadora, Menu Ver y pulsa sobre Científica. miles de páginas en Internet que te lo explican perfectamente y
Ya está por supuesto de forma gratuita. Busca en www.google.com y
Ahora introduce cualquier número y pulsa sobre Bin avanza tanto como quieras

Construyendo un paquete TCP El problema es que no hemos ajustado cada

desde cero. campo a su tamaño de palabra. El tamaño
de palabra de cada uno de estos dos campos
Ya podemos ponernos manos a la obra con el es de 16 bits, por lo que cada uno de los dos
tema que nos ocupa, que son los paquetes números obtenidos tiene que ser representado
TCP. Vamos a recordar la cabecera TCP (volved con 16 cifras binarias. Para ello, habrá que
atrás un poco para ver la imagen), y a ir poner el suficiente número de ceros a la
campo por campo construyendo el paquete. izquierda, para rellenar las 16 cifras. Así, nos
quedará:
Vamos a poner como ejemplo, el primer
1345 = 0000010101000001
paquete que se envía cuando queremos
21 = 0000000000010101
establecer una conexión con un servidor de
FTP.
Ahora ya si que podemos concatenar ambos
En primer lugar, tenemos que conocer los para conseguir la primera fila de la cabecera:
puertos de origen y de destino (los dos
primeros campos de la cabecera TCP). El 00000101010000010000000000010101
puerto de destino será el 21, que es el
asignado por el estándar al servicio de FTP Como experimento, probad a convertir este
(aunque bien sabréis muchos de vosotros que número en su equivalente decimal. El resultado
no siempre se usa este puerto, como en el es 88145941. ¿Y qué nos dice este número?
caso de los dumps, donde se suelen usar otros Pues absolutamente nada, ya que lo importante
puertos menos sospechosos). a la hora de traducir un número de una base
El puerto de origen será un puerto aleatorio a otra no es sólo la secuencia de cifras, si no
asignado por el sistema operativo a la hora también el cómo se agrupen estas. Si
de abrir el socket, es decir, la estructura agrupamos esta secuencia en grupos de 16,
utilizada por el sistema para establecer la entonces si que tendrá un sentido, pero si la
nueva conexión TCP/IP. Supongamos que el agrupamos en una única secuencia de 32 bits,
sistema nos ha asignado el puerto 1345 como el número resultante no tiene ningún interés
puerto de origen. para nosotros. Por tanto, es absolutamente
imprescindible conocer el tamaño de las
Ya tenemos los datos necesarios para rellenar palabras.
la primera fila de la cabecera TCP.
En primer lugar, tenemos que convertir el Vamos ahora con la segunda fila de la cabecera.
número 1345 en su equivalente binario, y lo Como vemos, ahora nos toca el campo
mismo con el número 21. número de secuencia. Este número también
será asignado por el sistema operativo
Aplicando el algoritmo explicado en el punto
(recordemos del artículo anterior que no
anterior, obtenemos:
conviene que sea 0 cada vez que se establece
1345 = 10101000001
una nueva conexión). En nuestro ejemplo el
21 = 10101
sistema nos asignará el número 21423994.
Para construir la primera fila de la cabecera Lo convertimos a binario, y nos da el número:
TCP tenemos que concatenar el puerto origen 1010001101110011101111010.
con el puerto destino, por lo que quedaría:
10101000001 10101. Este número es de 25 bits, por lo que habrá
que poner 7 ceros a su izquierda, para
Tenemos, por tanto, que nuestra primera fila
completar los 32 bits de la palabra que
consta de 16 bits... pero... no puede ser, si
corresponde a este campo. Por tanto, la
habíamos quedado en que cada fila de la
segunda fila de nuestra cabecera TCP será:
cabecera TCP eran 32 bits.
00000001010001101110011101111010

En este caso, el número completo de 32 cifras Esto habrá que concatenarlo a lo que
sí que tiene significado para nosotros, ya que llevábamos ya construido de esta fila, por lo
el tamaño de la palabra es precisamente de que nos quedaría: 0110000000000010
32 bits.
Vamos ahora con el campo tamaño de la
La tercera fila corresponde al campo número
ventana. Un valor típico es, por ejemplo,
de confirmación. En nuestro caso tiene que
8192. Este número es una potencia de 2,
ser cero, ya que es una conexión que aún no 13
se ha establecido, por lo que el primer paquete concretamente 2 . Por tanto, la traducción
no llevará confirmación de otro paquete a binario es instantánea. Basta con poner 13
anterior. Para representar el 0 con 32 bits, ceros a la derecha, y poner un único 1 a la
basta con meter 32 ceros. izquierda del todo: 10000000000000. Esto
nos da un número de 14 cifras, por lo que
00000000000000000000000000000000 tenemos que ajustarlo al tamaño de la palabra
de 16 bits con dos ceros a la izquierda:
Ahora nos toca el campo comienzo de datos.
0010000000000000.
Como ya vimos, el valor más habitual para
este campo es 5, en el caso de que no haya
Por tanto, finalmente, la cuarta fila de la
ninguna opción. Pero nosotros vamos a incluir
cabecera TCP nos quedará:
una opción, que ocupará 32 bits, como
veremos más adelante. Como el campo
01100000000000100010000000000000
Comienzo de datos indica el número de
palabras de 32 bits que ocupa la cabecera
El próximo campo es el campo suma de
TCP, al tener una palabra más para la opción,
comprobación, y es el que más quebraderos
tendrá que ser 6, es decir: 110. Como el
de cabeza nos va a dar. Si habéis seguido el
campo tiene una palabra de 4 bits, añadimos
resto del curso, habréis visto que hasta ahora
un cero a la izquierda: 0110.
he eludido un poco el tema, dándoos sólo
una URL donde teníais un código en C ya
A continuación, la cabecera TCP tiene un
hecho para calcular automáticamente los
campo vacío de 6 bits, que hay que rellenar
checksums (sumas de comprobación). Si lo
con ceros: 000000. Por tanto, de momento
hice así hasta ahora era porque sabía que más
esta fila de la cabecera nos va quedando:
adelante llegaría el momento de enfrentarse
0110000000.
cara a cara con los checksums, y ese
momento ya ha llegado.
Ahora le toca el turno a los flags. Como vimos
en el artículo anterior, siempre que se desee
Quizá os estaréis preguntando, ¿y por qué
establecer una nueva conexión el paquete ha
hay que enfrentarse al checksum si tenemos
de tener activado su flag SYN. El resto de
ya un código que nos lo calcula? ¿Para qué
flags estarán desactivados. Es decir, éste será
sirven todas estas vueltas y revueltas que
el valor que tomarán todos los flags:
estoy dando a los paquetes TCP cuando
bastaría con conocer lo necesario para poder
URG = 0
manejarlos?
ACK = 0
PSH = 0
Creo que es importante que hablemos aquí
RST = 0
acerca del significado original de la palabra
SYN = 1
HACK, que forma parte del nombre de esta
FIN = 0
revista, y que justifica el hecho de que
profundicemos hasta el más mínimo detalle
Si los colocamos todos juntitos en su orden
en lo que explicamos.
nos quedará: 000010.

El término Hacker ha sido muy desvirtuado Por último, tenemos el campo DATOS. Como
con el paso del tiempo. Originalmente, un el paquete es sólo para establecer una
hacker era una persona cuya pasión era conexión, no habrá ningún dato, por lo que
conocer el funcionamiento de las cosas. Para este campo estará en blanco (ya no con ceros,
las personas normales una máquina es sólo si no que directamente no habrá nada).
una herramienta que se utiliza para algún fin
concreto. En cambio, un hacker no se Pero... ¡un momento! ¡Si habíamos dicho que
conforma sólo con usar las máquinas, si no íbamos a meter una opción! Entonces el campo
que además ansía conocer su funcionamiento DATOS no será el último, si no que tendremos
interno. antes el campo de opciones TCP. Para el
caso nos va a dar igual, porque al fin y al cabo
Hace años, se llamaba hackers a los grandes no hay campo de DATOS, así que en cualquier
programadores, a los gurús de cualquier caso el campo opciones iría inmediatamente
campo de la informática, y a toda esa clase después del campo puntero de urgencia.
de chiflados (a los cuales aspiro
orgullosamente a pertenecer). Posteriormente, La opción que vamos a incluir es la única
los medios de comunicación tergiversaron definida en el RFC de TCP, aunque ya vimos
todo, y dieron a la palabra hacker el significado que existen muchas más: Maximum
que antiguamente tenía la palabra cracker, y Segment Size (MSS).
después estos términos han seguido
evolucionando hasta el punto actual, en el Todas las opciones empiezan con un byte que
cual hay mil y una definiciones para cada uno indica el tipo de opción. En nuestro caso, el
de los términos. código para la opción MSS es el 2, es decir:
00000010.
La cuestión es que si realmente queréis ser
hackers, de los de toda la vida, vuestra pasión En el caso de la opción MSS, el siguiente byte
debe ser conocer hasta el mínimo detalle de contendrá la longitud en bytes de la opción
cómo funcionan las cosas, y no sólo saber que, contando con los dos primeros bytes que
manejarlas sin más. Un tío que dedique a ya hemos mencionado (el que indica el código,
entrar en sitios donde teóricamente le estaba y el que indica la longitud) será siempre 4.
prohibido el paso, será un hacker sólo si su Por tanto, el segundo byte de la opción MSS
motivación para hacerlo sea explorar el será siempre fijo: 00000100.
funcionamiento de los sistemas, en caso
contrario, su calificativo más apropiado será Por último, los otros dos bytes que completarían
lamer, script kiddie, o el que más os guste. la fila de 32 bits serán los que contengan el
dato que queremos transmitir: el tamaño
Pero bueno, ya he vuelto a salirme del tema... máximo de segmento. Si, por ejemplo,
estábamos con el checksum. Pues me temo queremos un tamaño máximo de segmento
que de momento tenemos que dejar este de 1460 bytes, codificaremos este valor en
punto en blanco, porque para calcular el 16 bits: 0000010110110100.
checksum tenemos que tener terminada el
resto de la cabecera, así que vamos a ver Por tanto, toda la fila de 32 bits para la
antes el resto de campos, y luego volvemos opción MSS nos quedaría:
atrás sobre este punto. 00000010000001000000010110110100.
Calculando la suma de
El siguiente campo es el puntero de
comprobación (checksum).
urgencia. Como el flag URG no está activo,
este campo puede ser 0. Como son 16 bits, Ya podemos volver atrás un poco y calcular
tendremos aquí: 0000000000000000. el último campo que nos falta para completar

la cabecera TCP de nuestro paquete. hay en la cabecera TCP, y todos los bytes
El primer paso a seguir es coger todo lo que de DATOS. Como en nuestro paquete no hay
tenemos hasta ahora, y agruparlo en palabras datos, bastará con contar los bytes (grupos
de 16 bits. Es decir, partimos de todos estos de 8 bits) que ocupa la cabecera. Cada fila de
chorizos binarios: la cabecera son 4 bytes (32 / 8 = 4), y tenemos
0000 0101 0100 0001 = puerto de origen un total de 6 filas, por lo que el tamaño de
0000 0000 0001 0101 = puerto de destino paquete será de 6 * 4 = 24.
0000 0001 0100 0110 = primeros 16 bits del número de secuencia
1110 0111 0111 1010 = últimos 16 bits del número de secuencia
0000 0000 0000 0000 = primeros 16 bits del número de confirmación
Ahora tenemos que pasar todo esto a binario:
0000 0000 0000 0000 = últimos 16 bits del número de confirmación
IP de origen = 1100 0000 . 1010 1000 . 0000 0001 . 0000 0001
0110 0000 0000 0010 = comienzo de datos, y flags
IP de destino = 1000 0010 . 1100 1110 . 0000 0001 . 0000 0101
0010 0000 0000 0000 = tamaño de la ventana
Protocolo = 0000000000000110
0000 0000 0000 0000 = puntero de urgencia
Tamaño de paquete = 0000000000011000
0000 0010 0000 0100 = código y longitud de la opción MSS
0000 0101 1011 0100 = opción MSS
Lo que hay que hacer ahora con todos estos
Por si todas estas ristras de ceros y unos os chorizos binarios es simplemente sumarlos
parecen pocas, todavía tenemos que añadir (de ahí el nombre de suma de comprobación).
unas cuantas más, y es aquí cuando entra en El problema es que, si no tenéis práctica,
juego esa pequeña cabecera de la que os sumar en binario os puede resultar complicado.
hablé que se utilizaba a la hora de calcular Sería ya demasiado explicaros ahora toda la
el checksum. aritmética binaria, así que eso os lo dejo como
ejercicio para que lo estudiéis por vuestra
Recordemos esta cabecera: 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

En primer lugar, necesitamos la IP de origen. pseudocabecera de checksum que acabamos
Supongamos que tenemos un router ADSL de calcular. Ahora hay que hacer otra suma,
que nos conecta con Internet, por lo que pero con todos los chorizos que sacamos antes,
nuestra IP será una IP de red local, como por de la propia cabecera TCP:
ejemplo: 192.168.1.1.
0541 + 0015 + 0146 + E77A + 0000 +
Si, por ejemplo, el FTP al que conectamos es 0000 + 6002 + 2000 + 0000 + 0204 +
el de Rediris (ftp.rediris.es) sabemos que su 05B4 = 175D0.
IP es 130.206.1.5.
Ahora sólo tenemos dos números, que
El número de protocolo asignado a TCP es tendremos que sumar a su vez:
el 6. 1459A + 175D0 = 2BB6A
Por último, el tamaño del paquete TCP Este no es todavía el resultado, entre otros
lo calculamos contando todos los bytes que motivos porque el checksum ha de ocupar

sólo 16 bits, y un número hexadecimal de ¿Que cómo he hecho todas esas sumas en
5 cifras, como el 2BB6A, ocupa 20 bits. Por hexadecimal? Pues, por supuesto, no de
tanto, lo que hacemos es coger la primera cabeza, si no usando una calculadora científica
cifra (el 2) y sumarla al resto: que admita hexadecimal.
BB6A + 2 = BB6C
Ya tenemos completada la
operación conocida como suma
en complemento a uno.
Ahora sólo nos falta sacar a su

vez el complemento a uno
de este número, es decir,
invertir todos los bits (donde
haya un uno, poner un cero, y
viceversa). Si pasamos este
número (BB6C) a binario
tenemos: 1011 1011 0110
1100.
Si invertimos cada bit nos

queda:
0100 0100 1001 0011
Este número de 16 bits es al
fin lo que tenemos que poner
en el campo que nos quedaba por rellenar: En esta captura podemos verme en plena
la suma de comprobación. faena, calculando el checksum de un paquete
capturado con un sniffer. El sniffer me da
Repasamos por tanto todo lo visto acerca de directamente el paquete en hexadecimal, por
la suma de comprobación: lo que me facilita los cálculos.
1- Agrupamos toda la cabecera TCP ¿Y cuál es la utilidad de todas estas

en grupos de 16 bits, y sumamos operaciones?
todos esos grupos entre sí. Pues para comprenderlo necesitáis saber que
2 - A continuación, construimos la el complemento a uno de un número es el
pseudocabecera con las ips de origen opuesto de ese número en complemento a
y de destino, el protocolo, y el tamaño uno, es decir, si sumas en complemento a uno
de paquete, y agrupamos todo esto un número cualquiera y su complemento a
también en grupos de 16 bits. uno, el resultado tiene que ser siempre cero.
3 - Sumamos estos nuevos grupos al Vamos, en resumen, que es como decir que
resultado obtenido en el primer paso. -5 es el complemento a uno de 5, ya que 5 +
4- Del número obtenido en el paso 3, (-5) = 0.
nos quedamos sólo con los 16 últimos
bits, y los sobrantes los sumamos Esto hace que el procesamiento de los paquetes
a estos 16, quedándonos así un sea bastante rápido a la hora de verificar los
resultado de 16 bits. checksum, ya que basta con que el software
5- El resultado del cuarto paso, lo sume todos los datos del paquete y, si el
invertimos, cambiando cada cero por paquete es correcto, el resultado tiene que
un uno, y viceversa. ser 0.

Esto es lógico, ya que la suma que nosotros Vamos a analizarlo:

hemos hecho hace un momento contenía
todos los datos del paquete excepto uno: la En primer lugar, los puertos de destino y
propia suma de comprobación. El paquete de origen están intercambiados, como es
que llegue al receptor, en cambio, si que lógico.
contendrá además ese dato, y como ese dato
En segundo lugar, vemos que el número de
es precisamente el opuesto de la suma de
secuencia no tiene nada que ver con el
todos los demás, al sumar todos los datos
nuestro, ya que cada extremo de la
más la suma de comprobación, el resultado
comunicación usará sus propios números de
será:
secuencia.
checksum + resto de cabecera = 0 En cambio, el que sí que tiene que ver con
nuestro número de secuencia es su número
Ya que, insisto: de confirmación. Al no contener datos
nuestro paquete, el próximo byte que
checksum = - (resto de cabecera). enviaríamos sería el inmediatamente posterior
al número de secuencia de nuestro paquete
Os propongo como ejercicio que comprobéis anterior. Por tanto, el servidor de Rediris estará
todo esto con un sniffer. Capturad un paquete esperando recibir en el próximo paquete un
TCP, sumad todos los datos de la cabecera número de secuencia que sea el que enviamos
T C P, d e l c a m p o D AT O S , y d e l a antes, + 1.
pseudocabecera utilizada en el checksum, y
comprobaréis que, si el paquete no contiene Vemos que su campo comienzo de datos es
errores, el resultado es siempre cero. el mismo que el nuestro, ya que el paquete
también contendrá una única fila de opciones
(de 32 bits).
Resumiendo
Donde vemos que sí que hay un cambio es
Al final, este es el paquete que nos queda, y en los flags, ya que aquí no sólo está activado
que será enviado tal cual desde nuestro PC el flag SYN, si no también el flag ACK. En el
hasta el receptor (en este caso, el servidor próximo punto veremos en detalle a qué se
FTP de Rediris): debe esto.
Vemos también que el tamaño de la ventana

es diferente, ya que cada extremo de la
comunicación puede tener su propio tamaño
de ventana.
4. La respuesta a nuestro paquete La suma de comprobación, por supuesto,

es diferente para cada paquete. Os propongo
como ejercicio que comprobéis la validez de
Al recibir este paquete el servidor FTP de
la suma de comprobación de este paquete y,
Rediris, nos responderá con el siguiente
en caso de que sea incorrecta, que calculéis
paquete, que os muestro como ejercicio para
cuál sería el checksum correcto.
que lo analicemos:
El puntero de urgencia también está a cero,

ya que tampoco tiene el flag URG activado.
Por último, vemos que también añade la

opción MSS, con el mismo tamaño máximo

de segmento: 1460 bytes. Por ejemplo, en el caso del servidor de Rediris,

si habéis probado a conectaros habréis visto
El paquete tampoco contiene nada en el que nada más conectar envía un texto de
campo DATOS, ya que es otro de los paquetes presentación. Si nosotros no respondiésemos
utilizado únicamente para establecer la al servidor diciéndole que aceptamos la
conexión. conexión, aún habiéndola solicitado nosotros,
el servidor se pondría en vano a enviar todo
5. Los estados de conexión TCP
ese texto sin saber si al otro lado hay alguien
No podemos completar un curso sobre TCP escuchando.
sin hablar de los estados de conexión. Para
ello, empezaremos viendo una serie de Estos tres paquetes especiales utilizados en
procedimientos que se llevan a cabo en las el 3-way handshake se caracterizan por sus
conexiones TCP, para luego enumerar los flags:
estados que hemos ido descubriendo.
El cliente solicita conexión al servidor:
flag SYN.
5.1. Establecimiento de conexión
El servidor acepta la conexión: flags
TCP.
SYN y ACK.
En el ejemplo anterior, los paquetes El cliente acepta la conexión: flag
involucrados correspondían a un ACK.
establecimiento de conexión. Como vimos,
había por lo menos dos paquetes encargados
de establecer la conexión: uno por nuestra
parte, que le decía al servidor de Rediris que
queríamos establecer la conexión, y otro por
parte del servidor de Rediris que nos decía
que estaba de acuerdo y él también quería
establecer la conexión.
En realidad, el establecimiento de conexión Esto ha de ser siempre así, y si alguno de

TCP requiere aún otro paquete más, y es lo esos flags no es enviado en el orden correcto,
que hace que a este sistema de todo el establecimiento de conexión será
establecimiento de conexión se le llame 3- anulado.
way handshake o, traducido así a lo bruto:
saludo de 3 pasos. Intuitivamente, nos damos cuenta de que todo
este mecanismo nos da lugar a diferentes
El sistema de establecimiento de conexión estados en la conexión:
TCP consiste en lo siguiente:
1- El cliente solicita al servidor una En primer lugar, el estado primordial
conexión. es el estado DESCONECTADO, que es
2- El servidor responde aceptando la cuando aún ni siquiera hemos enviado
conexión. el SYN.
3- El cliente responde aceptando la En segundo lugar, una vez enviado el
conexión. SYN, estamos en un estado diferente
que espera al próximo paso. A este paso
¿A qué se debe la necesidad de este tercer
lo podemos llamar SYN ENVIADO.
paso? Este tercer paso permite una
sincronización exacta entre cliente y servidor, Una vez que el servidor recibe el
y además permite al cliente echarse atrás primer SYN, nos enviará su respuesta
si no le gusta algo en la respuesta del servidor. con el SYN y el ACK en el mismo

paquete. En ese caso, pasaremos a un que tengan como respuesta un SYN, ACK
estado que podemos llamar SYN corresponderán a los puertos abiertos de la
RECIBIDO. Ahora nos falta esperar al máquina. Los paquetes que no tengan
último paso del establecimiento, que respuesta, o bien que sean respondidos con
es el último ACK. un flag RST, estarán cerrados.
Una vez recibido el último ACK,
nuestra conexión pasará finalmente al Lo interesante aquí es que nosotros no
estado de conexión ESTABLECIDA. responderemos a ninguno de los SYN, ACK,
por lo que ninguna conexión quedará
establecida, ya que sería necesario que
respondiésemos con un nuevo paquete ACK
por cada paquete SYN que enviásemos.
Si alguna vez habéis utilizado la herramienta

netstat posiblemente os suenen estos
nombres. Si no, probad ahora mismo, desde
una shell de Linux/Unix, o una ventana Ms-
DOS de Windows, a escribir:
netstat
Veréis la lista de conexiones de vuestra

máquina, con el estado de cada una. Las
conexiones que estén en estado ESTABLECIDA,
que son las más habituales, aparecerán como
ESTABLISHED. Ataque SYN Flood
Podréis ver otros estados como Ya que hemos empezado hablando de cosas
CLOSE_WAIT, FIN_WAIT, LISTEN, etc. divertidas, como el escaneo de puertos, vamos
En breve explicaremos todos ellos. a rematar la faena hablando de una técnica
de hacking realmente interesante, aunque
Escaneo de puertos con SYN más por el interés de su funcionamiento que
por su utilidad práctica, ya que es un ataque
Os propongo como experimento que pongáis de tipo DoS (Denial of Service), es decir, que
en marcha alguna aplicación de escaneo de sólo sirve para fastidiar y tirar abajo un servidor.
puertos, y a continuación hagáis un netstat.
¿Por qué hablamos de diferentes estados en
Probablemente (dependiendo del tipo de
una conexión? Pues porque es necesario tener
escaneo que utilice la aplicación), veréis que
en cuenta los diferentes estados a la hora de
hay montones de conexiones en estado
llevar a cabo todos los pasos necesarios para
SYN_SENT, es decir, lo que nosotros hemos
conseguir llevar a cabo la comunicación.
llamado SYN ENVIADO.
Esto se debe a que un sistema clásico de Por ejemplo, en el momento en que pasamos
escaneo consiste en hacer solicitudes al al estado SYN_SENT, tenemos que crear una
servidor para establecer conexiones en cada estructura de datos que necesitaremos para
uno de los puertos, es decir, enviamos un mantener controlado el estado de la conexión
paquete SYN a cada puerto. Los paquetes en todo momento. Sería absurdo tener estos

datos creados de antemano, ya que ocuparían bastante pacientes, y suelen esperar en torno
una gran cantidad de memoria innecesaria y, a unos 3 minutos antes de dar por perdida
además, tampoco podríamos saber cuántas una conexión. Por tanto, si saturamos al
estructuras de este tipo necesitaríamos, pues servidor a base de SYNs, en unos 3 minutos
depende en todo momento de cuántas nadie podrá conectarse legítimamente al
conexiones tengamos establecidas. Por tanto, servidor, ya que su memoria para nuevas
al cambiar un sistema al estado SYN_SENT, conexiones estará llena en espera de completar
creará una estructura de datos para mantener las que tiene pendientes.
la conexión inminente. Esta estructura de
datos se llama TCB (Transmision Control Si este bombardeo de SYNs se repite
Block). constantemente, el servidor quedará inutilizado
mientras dure el bombardeo.
Por tanto, cada vez que
intentamos conectar con un
servidor, estamos haciéndole
crear una estructura que ocupa
lugar en su memoria. En el
momento en que se cierre esa
conexión, el servidor podrá
borrar el TCB correspondiente,
recuperando así el espacio que
había ocupado en su memoria.
¿Qué pasaría entonces si

saturásemos al servidor a base
de conexiones? Si esta
saturación es suficiente, conseguiremos dejar Si leísteis mi artículo de la serie RAW sobre
sin memoria al servidor para establecer nuevas el protocolo DNS, o mi artículo sobre UDP
conexiones. del curso de TCP/IP, conoceréis la técnica de
envenenamiento de caché DNS. Cuando
Para que esta saturación sea efectiva, es expliqué esta técnica mencioné que una ayuda
conveniente que utilicemos direcciones IP para hacer más efectivo el ataque era conseguir
falsas, es decir, que hagamos un IP Spoofing. hacer una denegación de servicio (DoS) al
servidor DNS legítimo.
Si conseguimos enviar al servidor una gran
cantidad de paquetes, cada uno de ellos En cambio, la técnica de SYN Flood no puede
conteniendo un flag SYN solicitando una funcionar en UDP, ya que sencillamente UDP
conexión, y cada uno con una dirección IP no tiene ningún flag, y menos aún el flag SYN,
falsa, el servidor creará un TCB para cada por lo que en este caso el utilizar UDP frente
una de esas conexiones falsas inminentes y, a TCP es una ventaja para el protocolo DNS.
al mismo tiempo, enviará el SYN, ACK a cada
una de las direcciones falsas. Más adelante veremos cómo llevar a cabo un
ataque SYN Flood en detalle de forma práctica.
A continuación, se quedará esperando a recibir
5.2. Cierre de conexión TCP
el ACK para completar el establecimiento de
conexión de cada una de las conexiones falsas.
Continuando con el asunto de los estados de
conexión en TCP, vamos a ver otro
Por supuesto, este ACK jamás llegará, y el
procedimiento que se puede llevar a cabo con
servidor se quedará esperando hasta que se
cualquier conexión, y es el cierre de la misma.
canse. Lo malo es que los servidores son

Si pensamos un poco, nos daremos cuenta caso de que tuviéramos que reenviar un
de que hay un pequeño problema inherente paquete anterior porque no recibiésemos su
a cualquier conexión full-duplex, es decir, confirmación), y lo único que debemos hacer
las conexiones en las que cualquiera de las es seguir recibiendo los datos de nuestro
dos partes puede tanto transmitir como recibir. compañero, hasta que éste también nos envíe
El problema es que, si ambos quieren su paquete con el flag FIN.
transmitir datos, ambos tendrán que ponerse
de acuerdo para decidir en qué momento hay
que cerrar la conexión.
Si no hubiese esta clase de acuerdos, ocurrirían

cosas poco deseables, como por ejemplo que
conectásemos con un FTP, solicitásemos un
archivo, y tras enviárnoslo el servidor nos
cerrase la conexión, asumiendo que ya no
queremos bajar ni subir nada más. O, por
ejemplo, conectarnos a un chat, decir hola,
y que el servidor decidiese que ya no queremos
decir nada más y, por tanto, nos cerrase la Esto, una vez más, nos da lugar a nuevos
conexión. estados de conexión. Una vez que enviamos
nuestro FIN entramos en un estado en el que
Por tanto, en una conexión full-duplex es no podemos enviar, y sólo podemos recibir. A
necesario que ambas partes se pongan de este estado lo podemos llamar ESPERA DEL
acuerdo sobre el momento en el que hay que FIN.
cerrar la conexión.
En realidad, el cierre de conexión da lugar a
varios estados diferentes, que podemos ver
En el caso de TCP, el sistema que se utiliza
en la siguiente imagen:
para conseguir esto es sencillamente que
cada uno, por su cuenta, indique al otro el
momento en el que quiere cerrar la conexión.
Una vez que el otro se ha enterado, habrá

que esperar a que él también desee cerrar la
conexión. 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 también he terminado,
así que hasta luego.
Aquí he puesto ya los nombres auténticos de
los estados, en inglés, porque sería demasiado
Para dar este tipo de avisos lo que se hace
rebuscado tratar de traducirlos, jeje.
es enviar un paquete especial que tiene
activado un flag que sirve precisamente para Como vemos, el estado que he llamado antes
indicar que deseamos FINalizar la conexión. ESPERA DEL FIN es el que se llama
Este flag es el flag FIN. FIN_WAIT_1.
A partir del momento en que enviamos un En el momento en que nuestro compañero

paquete con el flag FIN, ya no debemos recibe nuestro FIN, él entra en otro estado
enviar ningún paquete más (excepto en el diferente, que es el CLOSE_WAIT, es decir,

en espera de cerrar, ya que es ahora SYN_RECEIVED Se entra en este estado

responsabilidad suya terminar de enviar cuando tanto cliente como servidor han enviado
cuando pueda, para enviar él también su FIN. sus correspondientes SYN, y estamos en espera
de que se complete el tercer y último paso
Por otra parte, cuando recibe nuestro FIN, del establecimiento de conexión. (Ver
tiene que confirmarnos su recepeción, igual establecimiento de conexión).
que con cualquier otro paquete, enviándonos
un ACK. ESTABLISHED Conexión establecida. Es el
estado habitual.
En el momento en que recibimos ese ACK,
entramos en otro estado, que es el
FIN_WAIT_1 Hemos enviado un paquete
FIN_WAIT_2.
FIN, y sólo podemos recibir, pero no enviar.
En el momento en que nuestro compañero Estamos esperando a que nuestro compañero
termina, éste envía su FIN, y queda en espera nos confirme que ha recibido nuestro FIN.
de recibir nuestra confirmación. Durante esta Queremos cerrar la conexión, pero aún no
espera, entra en estado LAST_ACK. sabemos si nuestro compañero se ha enterado.
(Ver cierre de conexión).
Una vez que recibimos ese FIN, entramos en
estado TIME_WAIT, y enviamos el ACK para FIN_WAIT_2 Hemos enviado un paquete
el FIN de nuestro compañero. FIN, y sólo podemos recibir, pero no enviar,
pero además hemos recibido ya la confirmación
Una vez completado todo esto, ambas partes
(ACK) de nuestro FIN. Por lo tanto, sabemos
pasan a estado CERRADO, y se acabó el
tema. La máquina A esperará un tiempo ya que nuestro compañero conoce nuestras
prudencial para pasar a estado CERRADO, intenciones de cerrar la conexión. (Ver cierre
ya que no puede estar seguro de que B haya de conexión).
recibido correctamente su último ACK.
CLOSE_WAIT Hemos recibido el FIN de
5.3. Lista de estados TCP nuestro compañero, pero a nosotros todavía
nos quedan datos por enviar. (Ver cierre de
Ya podemos ver la lista completa de estados conexión).
de conexión en TCP, que os servirá como guía
de referencia, sobre todo para cuando utilicéis CLOSING Esperamos a la última
herramientas como netstat. confirmación para cerrar definitivamente la
conexión. Es un estado al que se llega cuando
LISTEN Es el estado en el que permanece
ambas partes desean cerrar la conexión
cualquier servidor cuando está en espera a
que un cliente se conecte. Todos los puertos simultáneamente, al contrario del caso que
que tengamos abiertos en nuestro PC nos explicamos anteriormente.
generarán un socket TCP (o UDP, según el
caso) en estado LISTEN. Cada vez que un LAST_ACK Esperamos a la confirmación
cliente se conecte, si permitimos más de una (ACK) de nuestro FIN, cuando eramos nosotros
conexión, se creará un socket en estado los últimos que faltabamos por enviar el FIN.
ESTABLISHED para ese cliente, y otro en (Ver cierre de conexión).
estado LISTEN para esperar al resto de
clientes. TIME_WAIT Hemos enviado la confirmación
del FIN a nuestro compañero, cuando era él
SYN_SENT Se entra en este estado cuando
el que faltaba por enviar el FIN. Se llama así,
solicitamos una conexión a un servidor
porque lo que hacemos es esperar un tiempo
(enviamos un paquete SYN), y aún no hemos
prudencial para asumir que ha recibido nuestra
recibido su aceptación o su rechazo. (Ver
confirmación. Siempre que nosotros cerremos
establecimiento de conexión).

una conexión, durante un tiempo 6.1. Hping2 para Linux

permaneceremos en estado TIME_WAIT, por
lo que es bastante común encontrar este El caso de TCP es bastante más complicado
estado cuando hacemos netstat. (Ver cierre que el de UDP, ya que TCP da muchísimo más
de conexión). juego. No hay más que ver el manual:
CLOSED Es un estado ficticio, que

man hping2
simplemente dice que no hay ningún tipo de
conexión.
Para ver la gran cantidad de opciones que hay
A continuación, muestro el diagrama de para TCP que, por cierto, es el protocolo por
estados de TCP, tal y como lo podéis encontrar defecto de Hping2. Nosotros vamos a ver sólo
en el RFC: las opciones que directamente tienen que ver
con lo explicado hasta ahora.
Empezamos con la prueba más sencilla:

hping2 130.206.1.5 --destport 21 --count 1
Con esto enviamos un único (--count 1)

paquete TCP a la dirección 130.206.1.5, al
puerto 21.
Este paquete tendrá todos sus parámetros

tal y como los tiene configurados hping2 por
defecto, es decir, sin ningún flag, con un
tamaño 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 parámetro -
-destport, por defecto envía el paquete al
puerto 0, y esto puede ser útil para hacer
un ping a una máquina que tenga un firewall
que filtre los auténticos pings (que no son
TCP, si no ICMP, que es otro protocolo), y
además es probable que éste intento nuestro
de ping ni siquiera quede reflejado en los logs
de la máquina. Aún así, esto es algo que yo
no he comprobado, así que no sé qué utilidad
tendrá. Os propongo que lo probéis vosotros
mismos como ejercicio.
6. RAW Sockets TCP (Nemesis y
Hping) Vamos a ver las diversas opciones que nos da
Hping2 para TCP:
Vamos a recordar un poco las herramientas
que expliqué para manejar RAW sockets en --baseport: permite especificar nuestro puerto
el artículo sobre UDP, pero en este caso de origen.
aplicadas al caso de TCP. Esta vez --destport: permite especificar el puerto de
empezaremos por Linux. destino.
--keep: si enviamos varios paquetes, evita

que el puerto de origen se vaya incrementando fastidiando por fastidiar. Además, es poco
automáticamente, tal y como vimos con UDP. probable que funcione un IP spoofig a pelo
--win: fija el tamaño de la ventana TCP. como el que voy a explicar, ya que los routers
--tcpoff: envía un valor falso para el campo que haya en el camino desde vosotros hasta
Comienzo de Datos de la cabecera TCP. vuestra víctima probablemente rechacen los
--tcpseq: especifica el Número de Secuencia. paquetes si no provienen de una IP que forme
--tcpack: especifica el Número de parte de su red.
Confirmación.
--badcksum: igual que en UDP, envía un Recordemos que para explotar la técnica de
checksum erróneo. SYN Flood simplemente hay que enviar gran
--fin: el paquete que enviamos tiene activo cantidad de paquetes con flag SYN, cada uno
el flag FIN. con una dirección IP de origen falsa y, a
--syn: el paquete que enviamos tiene activo ser posible, diferente. Hping2 casualmente
el flag SYN. tiene opciones para automatizar todo esto,
--rst: el paquete que enviamos tiene activo por lo que nos basta con esta línea:
el flag RST.
hping2 192.168.1.1 --rand-source --
--push: el paquete que enviamos tiene activo
destport 21 --syn --count 100
el flag PUSH.
--ack: el paquete que enviamos tiene activo
Con esta línea enviaremos 100 paquetes (--
el flag ACK.
count 100) al puerto 21 de la IP 192.168.1.1,
--data: especifica el tamaño del campo
utilizando como IP de origen una aleatoria en
DATOS, sin contar con la cabecera.
cada paquete (--rand-source), y con el flag
--file: igual que en UDP, permite rellenar el
SYN activado.
campo DATOS con los contenidos de un archivo
que especifiquemos.
Os puedo asegurar que esta línea funciona,
--safe: nos permite asegurarnos de que los
ya que acabo de probarla ahora mismo con
paquetes que enviamos llegan a su destino
el puerto de telnet (--destport 23) de mi router
ya que, tal y como ha de hacerse en TCP, si
ADSL, y ahora me es imposible conectar con
no recibimos la confirmación de alguno de
el telnet del router.
los paquetes, hping2 lo reenviará
automáticamente.
¿Significa esto que yo, que precisamente estoy
Vamos a ver todo esto y mucho más con un explicando estas cosas, tengo un grave
ejemplo muy interesante, que es para poner problema de seguridad? Realmente no, por
en práctica la técnica de SYN Flood explicada tres motivos. En primer lugar, porque el puerto
anteriormente. de Telnet lo tengo abierto sólo hacia mi red
local, por lo que sólo podría atacarme... yo
SYN Flood mediante Hping2. mismo. En segundo lugar, porque no es un
servicio de importancia crítica, es decir, me
Esta técnica sólo debéis utilizarla para hacer da igual tirarme el tiempo que sea sin poder
pruebas con vosotros mismos, para acceder al telnet de mi router, ya que sólo lo
comprender el funcionamiento de la técnica, uso muy rara vez, cuando tengo que modificar
y también para poner a prueba la seguridad algo en la configuración. En tercer lugar, al
de vuestra red, por si queréis hacer una tratarse de un router hardware y no de un
auditoría de seguridad y arreglar los agujeros simple programa de PC, tendría que esperar
que tengáis. a que saliese una nueva actualización del
firmware que solucionase este problema, así
Cualquier otro uso que le deis, al margen de que en cualquier caso no está en mi mano la
que pueda ser ilegal, éticamente será solución, si no en la del fabricante del router.
indeseable, ya que no estaréis más que Ya que la cosa se está calentando un poco,

vamos a probar alguna técnica más de hacking conexión de FTP (puerto de destino 21) con
relacionada con TCP. la máquina B, con IP 192.168.1.5, utilizando
como puerto de origen el 3560, nos bastaría
Ataques por adivinación de con saber el número de secuencia que está
número de secuencia con Hping2. utilizando la máquina 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.
Vamos ahora con una técnica realmente Supongamos que sabemos que su número de
interesante que, de hecho, utilizó incluso el secuencia es el 24560.
propio Kevin Mitnick (uno de los hackers más
famosos de la historia) como parte de las Bastará con hacer:
andanzas que le hicieron terminar en la cárcel hping2 192.168.1.5 --spoof 192.168.1.2
(aplicaos el cuento, jeje). --baseport 3560 --destport 21 --tcpseq
24560 --file comandos.txt --data 14 --
En este caso, no se trata de un simple ataque count 1
DoS, como el SYN Flood, si no de un ataque
mucho más versátil que nos permitirá Con esto enviamos un único paquete (--count
colarnos en conexiones ajenas, con todo 1) enviando como IP spoofeada la de la
lo que ello implica. máquina A (--spoof 192.168.1.2), e inyectando
como datos unos comandos de FTP que hemos
Conseguir un ataque de este tipo con éxito
metido previamente en el archivo
es realmente complicado, así que lo que voy
COMANDOS.TXT.
a contar, que en la teoría puede parecer tan
sencillo, en la práctica choca con mil y un
Por supuesto, el gran problema de esto es
inconvenientes, empezando por la dificultad
que es realmente complicado conocer el
que comenté antes de hacer un IP Spoofing
número de secuencia de una conexión ya que,
sin que se enteren los routers que transportan
además de ser un número realmente grande
el paquete.
(32 bits), va cambiando constantemente a lo
Como lo importante es comprender la teoría largo de una conexión.
de las cosas, y no meternos en líos, voy a
explicar las bases de este tipo de ataques. Hping2 nos ofrece una herramienta para
ayudarnos a la hora de adivinar el número de
Para comprender el funcionamiento de estos secuencia, comprobando si un determinado
ataques debemos recordar qué es lo que sistema utiliza números de secuencia fáciles
define exactamente una conexión, es decir, de predecir. Para ello nos da la opción --
lo que identifica unívocamente a una conexión seqnum, que hace un análisis de los números
para diferenciarla de cualquier otra de Internet. de secuencia utilizados por un sistema:
Pues son estos los parámetros: una IP de
origen, una IP de destino, un puerto de hping2 192.168.1.5 --seqnum --destport
origen, un puerto de destino, y los 21 --syn
números de secuencia de cada una de
las dos partes. Con esto veríamos cómo varían los números
de secuencia de la máquina B cada vez que
Por tanto, si conociéramos todos estos datos, intentamos conectar con su puerto de FTP.
teniendo una herramienta como Hping2 que Hping2 nos mostrará el número de secuencia
nos permite crear paquetes a medida, utilizado, y el incremento con respecto al
podríamos insertar cualquier dato en una
utilizado anteriormente. Si este incremento
conexión ajena.
es siempre el mismo, entonces estaremos
ante una máquina con números de secuencia
Por ejemplo, si sabemos que la máquina A,
fácilmente predecibles.
con IP 192.168.1.2, tiene establecida una

Una vez que ya tenemos una idea del rango de urgencia.

de números de secuencia que puede utilizar -o : permite incluir un fichero que contenga
la máquina que queremos suplantar, podemos las opciones TCP que queramos.
intentar lanzar miles de paquetes iguales, en -v : activa el modo verbose que nos da
los cuales sólo cambie el número de secuencia, información más detallada de lo que estamos
haciendo.
y esperar que el azar nos recompense con la
suerte de que alguno de ellos haya acertado,
Os recuerdo también que necesitaremos un
y el paquete se inyecte correctamente en la
par de opciones referentes a IP:
conexión ajena.
-D : permite especificar la IP de destino
6.1. Nemesis para Windows
(imprescindible).
Para empezar, os recuerdo que en el directorio -S : permite especificar la IP de origen (IP
de Nemesis tenéis un archivo de ayuda para Spoofing).
cada protocolo. En este caso el que nos
interesa es el archivo nemesis-tcp.txt. Por ejemplo, si queremos enviar un paquete
Como ya me estoy quedando sin espacio, os de solicitud de conexión al FTP de Rediris
resumo brevemente las opciones que nos da podemos hacer:
Nemesis para TCP, que son bastantes:
Nemesis tcp -v S 192.168.1.1 D
-x : permite especificar el puerto de origen. 130.206.1.5 x 1000 y 21 fS a 0
-y : permite especificar el puerto de destino.
-s : permite especificar el número de En primer lugar especificamos nuestra IP
Secuencia. (-S 192.168.1.1), que en este caso es una IP
-a : permite especificar el numero de de red local porque nos encontramos detrás
confirmación. de un router ADSL. En segundo lugar indicamos
-fS : activa el flag SYN la IP de destino, es decir, la del servidor FTP
-fA : activa el flag ACK de Rediris (-D 130.206.1.5). A continuación
-fR : activa el flag RST especificamos los puertos de origen y de
-fP : activa el flag PSH destino (-x 1000 y 21). A continuación,
-fF : activa el flag FIN activamos el flag SYN para este paquete (-
-fU : activa el flag URG fS). Por último, ponemos un 0 en el campo
-w : permite especificar el tamaño de la número de confirmación, ya que es para una
ventana. conexión aún no establecida (-a 0).
-u : permite especificar el campo puntero

textos y cur sos par a consumo pr opio o de unos pocos.

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 verán la luz.
NOSOTROS PODEMOS PUBLICAR TU OBRA!!!

CURSO DE TCP/IP: ICMP
(Protocolo de Mensajes de
Control de Internet).
- ICMP es, posiblemente, el protocola más utilizado por los hackers
- ICPM nos dará información 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. Introducción Por tanto, ICMP es un protocolo de Control

(Internet Control Message Protocol), que
Imagino que muchos de los lectores que sirve para avisar de los errores en el
han seguido fielmente el curso de TCP/IP procesamiento de los datagramas, es
desde sus comienzos estaríais esperando decir, de los paquetes IP.
que este mes hablase del protocolo IP, Como ICMP funciona sobre IP, los
ya que una vez explicados los protocolos paquetes ICMP serán siempre a su vez
de transporte clásicos (TCP y UDP) el paquetes IP. Esto podría dar lugar a
orden lógico sería llegar a la capa inferior, situaciones en las que se generasen bucles
o la capa de red. infinitos donde un paquete ICMP avisa de
errores de otro paquete ICMP. Para evitar
Pero, para vuestra sorpresa, aún no esto, hay una regla de oro, y es que,
vamos a llegar a esa parte tan esperada, aunque los paquetes ICMP sirvan para
pero también tan compleja; si no que arreglar errores de otros paquetes, jamás
vamos a seguir con el orden lógico, con se enviarán paquetes ICMP para avisar
un protocolo que, aunque no sea un de errores en otro paquete ICMP.
protocolo de transporte, si que funciona
por encima del protocolo IP. Aunque esto suene a trabalenguas, ya
iremos viendo en detalle el funcionamiento
La diferencia entre ICMP y otros del protocolo ICMP, y se aclararán muchas
protocolos que funcionen por encima de cosas.
IP (como TCP, UDP, u otros que no hemos
Muchos de vosotros conoceréis ya algo
mencionado) es que ICMP se considera
sobre ICMP, pero quizá alguno se esté
casi una parte de IP, y las especificaciones
preguntando: ¿Pero realmente es tan
estándar de IP obligan a que cualquier
importante este protocolo? ¡Si jamás he
sistema que implemente el protocolo IP
oído hablar de él! ¡Seguro que no se usa
tenga también soporte para ICMP.
para nada!.
¿Y por qué es tan importante ICMP para Pues por supuesto que se usa, y mucho,
IP? Pues porque IP no es un protocolo aunque es normal que no os suene,
100% fiable (como nada en esta vida), teniendo en cuenta que es un protocolo
e ICMP es precisamente el que se encarga que no suele usar la gente en su casita,
de manejar los errores ocasionales que si no que es usado sobre todo por los
se puedan dar en IP. routers.

Protocolo ICMP - Protocolo ICMP - Protocolo ICMP - Protocolo ICMP - Protocolo ICMP
Aún así, aunque los paquetes ICMP sean

generados normalmente por un router, Aquí podrás encontrar la traducción al español del RFC
el receptor del paquete suele ser un 792 (Protocolo ICMP), concretamente en el enlace
usuario como tú, así que en realidad sí 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
que estás usando el protocolo ICMP
aunque no te des cuenta. No dudes en pasarte por www.rfc-es.org y, si te es posible,
participar en su proyecto. Desde esta revista damos las
Por ejemplo, cuando intentas acceder a gracias a quienes colaboran de forma totalmente
una IP que no existe, normalmente se te desinteresada en este tipo de iniciativas que nos benefician
notificará por medio de un mensaje ICMP. a todos.
Además, hay también una serie de
aplicaciones, como Ping, o Traceroute, El protocolo ICMP consta simplemente de
que utilizan ICMP, y en este caso sí que una serie de mensajes totalmente
eres tú el que genera los paquetes. independientes que se generan para cada
situación de error que se de en el
Aparte de todo esto, para nosotros ICMP procesamiento de un paquete IP, o bien
es especialmente interesante ya que, tal por otras circunstancias especiales en las
y como podéis leer en más de un que un usuario desea conocer cierta
documento de los que circulan en la red información sobre una máquina.
sobre ICMP, se dice de este protocolo que
es mucho más útil para un hacker que Por eso, no hay que andar con complejas
para un usuario normal. explicaciones sobre conexiones virtuales,
ni nada de nada. Simplemente basta con
Para este artículo iré explicando uno a
ir explicando cada mensaje por separado.
uno los diferentes mensajes ICMP, y
contando en cada uno alguna curiosidad
un poco más oscura para darle más gracia
2.1. Destino inalcanzable
a la cosa (buscad los epígrafes en color
rojo). Por último, como era de esperar, (Destination Unreachable)
terminaré explicando cómo generar
Este es el primer mensaje ICMP, que sirve
paquetes ICMP desde cero con las
para avisar de un gran número de
aplicaciones ya conocidas.
situaciones de error, aunque todas con
una misma consecuencia: no se ha podido
2. Directamente al grano acceder al destino que se solicitaba.
Igual que hacen en el RFC que explica el

Cuando intentas acceder a una IP (una
protocolo ICMP (RFC 792 : ftp://ftp.rfc-
página Web, u otro servidor de cualquier
editor.org/in-notes/rfc792.txt), no nos
tipo), puede haber muchos motivos por
enrollaremos mucho con explicaciones
los que no puedas llegar a acceder y,
previas, e iremos directamente al grano.
siempre que estos motivos tengan que
ver directamente con la parte de la que
! Como ya debes...
se encarga el protocolo de red (IP),
cualquier dificultad que haya te será
Como ya debes suponer, los RFCs son documentos escritos
notificada mediante un mensaje ICMP de
originalmente en inglés. Para quien no domine el idioma,
este tipo.
contamos con la inestimable ayuda de la Web www.rfc-es.org

Por supuesto, puede haber otros motivos

por los que no puedas acceder a los
contenidos que buscas. Por ejemplo, al
intentar acceder a una página Web, el
Servidor Web podría responderte con un
error 404 (te recuerdo que expliqué
todo esto en mi artículo sobre HTTP en
la serie RAW, hace ya unos cuantos
números...).
Esta situación de error no es

responsabilidad de IP y, por tanto,
tampoco de ICMP, por lo que este error
Por supuesto, me imagino que no
no se notificaría mediante un mensaje
entendéis ni papa de los contenidos de
ICMP, si no que sería responsabilidad del
esta tabla.
Servidor Web el generar una respuesta
de error 404 de HTTP. Explicar todos los códigos en detalle va a
ser demasiado (y, realmente, poco
Un error que sí que sería responsabilidad
interesante), así que explicaré sólo lo
de IP al intentar acceder a una página
suficiente para que os hagáis una idea de
Web sería que la IP del Servidor Web que
lo más importante.
buscamos no existiese.
En primer lugar, no hay que ser muy
Hay muchos otros motivos por los que
observador para darse cuenta de que la
un destino puede ser inalcanzable, como
mayoría de los errores están duplicados,
veremos en detalle ahora mismo. De
refiriéndose siempre o bien a la red, o
momento, vamos a ver el formato
bien al host.
detallado del mensaje:
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 sólo existen tres máquinas:
Máquina 1 192.168.1.1
Máquina 2 192.168.1.5
Campo: Type Y máquina 3 192.168.1.100
El primer campo, Type, se encuentra en
Si intentamos acceder a la máquina
todos los mensajes ICMP, y especifica el
192.168.1.200 recibiremos un mensaje
tipo de mensaje. En el caso del mensaje
de Host inalcanzable (código 1). La IP
Destination Unreachable el tipo de
192.168.1.200 forma parte de una red a
mensaje es 3.
la que tenemos acceso, pero en cambio
Campo: Code ese host concreto no existe en la red.
El campo Code permite precisar el motivo
por el que el destino es inalcanzable. En cambio, si intentamos acceder en el
Según el valor de este campo, podemos mismo escenario a la IP 10.12.200.1,
saber el motivo exacto, consultando la estaremos intentando acceder a una red
siguiente tabla: que no es la nuestra, por lo que el router

no podrá darnos acceso, y tendrá que cuando se intenta acceder a un protocolo

respondernos con un error de Red de transporte que no está implementado
inalcanzable (código 0). en el host de destino.
Con esta breve explicación de paso he Por ejemplo, si enviamos un paquete UDP
explicado los dos primeros códigos. Sólo a una máquina que no tiene implementado
queda comentar que el código 1 sólo lo UDP. Como la capa IP es la encargada de
enviará el último router dentro del camino reconocer al protocolo de nivel superior,
que lleve desde nuestra máquina hasta será responsabilidad suya, y por tanto de
el host de destino, ya que éste último ICMP, el notificar de los errores de
router será el que sepa qué máquinas protocolos no implementados.
en concreto existen dentro de su red. En
El mensaje de Puerto inalcanzable
cambio, el código 0 puede ser enviado
(código 3) se genera cuando se intenta
por cualquiera de los routers que haya
acceder a un puerto en un protocolo de
en el camino entre tu máquina y el host
transporte (por ejemplo, TCP o UDP), y
de destino, ya que en cualquier punto
ese puerto no está accesible en el host
del camino se podría detectar que la red
de destino. En muchos casos, el propio
de destino es inalcanzable.
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 situación, será
responsabilidad de ICMP hacerlo.
El mensaje de Paquete demasiado

grande, y no puede ser fragmentado
(código 4) tiene relación con un campo
de la cabecera IP que veremos más
adelante en el curso de TCP/IP. Este campo
especifica si un paquete puede ser o no
En la imagen la máquina H1 solicita fragmentado en trozos más pequeños.
acceder a la IP 10.1.2.3 al router R1. En el caso de que esté especificado que
Éste pasa la bola a R2, el cual está el paquete no puede ser fragmentado, y
conectado a la red 10.x.x.x, donde el paquete sea demasiado grande como
debería encontrarse la IP solicitada. Como para ser enviado de una sola vez, el
R2 sabe que el host 10.1.2.3 no existe, paquete no podrá ser transmitido.
responderá con un mensaje ICMP Host
inalcanzable. El mensaje ICMP llegará a De momento con esto creo que tenemos
R1, que lo retransmitirá hasta H1. suficiente, que no quiero llenar el artículo
entero sólo con el primero de los mensajes
Con respecto al siguiente código, ICMP y, al fin y al cabo, ya he explicado
Protocolo inalcanzable (código 2), los códigos más comunes.
en primer lugar hay que decir que no se
Campo: Checksum
genera en un router, si no en el propio
host de destino. Este error se genera
Pues aquí nos encontramos de nuevo con

otro checksum, como los que ya vimos asegurarnos de que se trata de nuestro
en anteriores entregas cuando tratamos paquete, se incluyen también los 64
el UDP y TCP. En el artículo anterior primeros bits del campo de DATOS del
detallé cómo generar un checksum para datagrama, por lo que el paquete puede
TCP, y también como realizar su quedar identificado sin lugar a dudas.
comprobación para un paquete recibido.
Por ejemplo, imaginemos que enviamos
En el caso de ICMP, los checksums (sumas el siguiente paquete:
de comprobación) se generan mediante
la misma operación, pero en este caso
no es necesario añadir una
pseudocabecera, si no que directamente
la operación se realiza únicamente con
todos los bits que componen la cabecera
ICMP.
En el caso de que este paquete genere,
Campo: Unused por ejemplo, un error de Destino
inalcanzable, éste será el paquete ICMP
Pues eso, ¿qué queréis que os cuente que nos llegará en respuesta:
sobre un campo que no se usa?
Simplemente lo rellenáis con ceros, y ya
está.
Campo: Internet Header + 64 bits of

original data datagram
Aquí ya hay bastante más que decir, ya

que además este campo es común a
muchos mensajes ICMP. Este campo es
especialmente importante, ya que es el
que nos permite identificar de forma
unívoca a qué datagrama (paquete IP)
se refiere el mensaje ICMP. Dentro de la cabecera ICMP podemos ver
en verde la copia de la cabecera IP del
Como ya he dicho, un paquete ICMP paquete que generó el mensaje, así como
puede ser una respuesta a un paquete los primeros datos del campo de DATOS
IP que ha generado algún tipo de error. (en azul). También es importante destacar
Si nos llegasen paquetes ICMP sin más que, como se ve en la imagen, el número
no podríamos saber cuál de nuestros de protocolo asignado a ICMP es el 1.
paquetes IP generó el error.
Detectando gusanos mediante
Por eso, muchos paquetes ICMP llevan Destination Unreachable
incluidos en su propia cabecera la
cabecera IP del paquete que generó el Como os dije, comentaré algún detalle
error. Además, para terminar de curioso sobre cada uno de los mensajes
ICMP. Os voy a comentar una posible

señal de alarma en relación con los ser ejecutados para infectar una máquina
mensajes Destination Unreachable. (por ejemplo mediante un correo
electrónico), si no que basta con que den
Si observamos los logs de nuestra
con una máquina vulnerable (es decir,
conexión... ¿que qué es eso? Pues en un
que tenga cierta versión de Windows sin
sistema que tenga implementada una
parchear).
buena política de seguridad es habitual
tener un mecanismo de monitorización
Por supuesto, si el gusano genera
que guarde un registro (un log) de lo que
direcciones IP que no existen, recibiremos
ocurre con las conexiones de nuestra
un mensaje Destination Unreachable
máquina.
cada vez que el gusano intente infectar
En caso de que no tengáis nada de esto una de estas IPs. Por tanto, encontrar
montado (sería motivo para varios varios mensajes ICMP de este tipo cuyo
artículos el explicar cómo hacerlo bien origen desconocemos puede ser un
hecho), podéis hacer pruebas síntoma de que tenemos un visitante no
simplemente poniendo en marcha un deseado en nuestro PC.
sniffer, como los que he explicado ya
en otros artículos (por ejemplo, Iris para No sólo eso, si no que además analizando
Windows, o Ethereal o Snort para Linux). en detalle la cabecera ICMP podremos
seguramente extraer información acerca
Pues como decía, si observamos lo que
del gusano, ya que estos mensajes ICMP,
ocurre en nuestra conexión con Internet,
tal y como acabamos de ver, incluyen en
y detectamos que nos llegan una gran
su cabecera toda la cabecera IP del
cantidad de mensajes ICMP de tipo
mensaje que generó el error, así como
Destination Unreachable, podría ser
los primeros 64 bits de datos.
síntoma de que estamos infectados con
algún gusano (Worm).
Este sistema no es definitivo, por
Un gusano es un tipo de virus informático supuesto, ya que no todos los gusanos
cuya principal función consiste en utilizan este sistema para buscar víctimas,
reproducirse a toda costa al mayor así que el hecho de no recibir mensajes
número de víctimas posible. La gran Destination Unreachable no significa
mayoría de los virus que existen hoy día ni mucho menos que no podamos estar
pueden ser calificados como gusanos, contaminados con algún otro tipo de
siendo buenos ejemplos los conocidos gusano más inteligente.
virus Sasser, MyDoom, etc.
Podría comentar muchos otros aspectos
Algunos de estos gusanos intentarán oscuros de este tipo de mensajes ICMP,
reproducirse por un sistema tan burdo como los ataques Smack, Bloop,
como es el generar direcciones IP WinNewK, etc. Pero como el espacio es
aleatorias, e intentar acceder a todas limitado, y además tengo que despertar
ellas para tratar de infectar una nueva un poco en vosotros la capacidad y el
máquina. ánimo de investigar por vuestra cuenta,
ahí os he dejado los nombres, para que
Esto es especialmente útil en gusanos vuestro amigo Google os dé más detalles.
como el Sasser (y, de hecho, el Sasser
utiliza este sistema), que no necesitan

Path MTU Discovery (P-MTU-D) tamaño de MTU utilizar ya que, no sólo

cada una de las dos máquinas tendrá una
Una aplicación importante de los mensajes MTU diferente, si no que también podrían
Destination Unreachable, es el proceso tener MTUs diferentes cada uno de los
de Path MTU Discovery. routers que se encuentran en el camino
Ya sabemos que entre dos máquinas que entre las dos máquinas.
se comunican suele haber varias
Cuando un router se encuentra con un
máquinas intermedias, que actúan como
paquete cuyo tamaño es mayor que el de
routers para encaminar los paquetes
su MTU, tendrá que fragmentarlo en
entre ambas máquinas.
trozos más pequeños que sí que quepan
El problema es que cada máquina de en su MTU.
todas las involucradas en el proceso
(incluyendo las máquinas de origen y El problema con esto es que la
destino) puede tener una configuración fragmentación es muy poco deseable, por
y unas características diferentes. Esto da motivos que explicaré a lo largo del curso,
lugar a que haya máquinas preparadas por lo que conviene evitarla. Para poder
para manejar paquetes más o menos evitar la fragmentación, una buena idea
grandes. consiste en conseguir un acuerdo sobre
el tamaño máximo de los paquetes entre
El tamaño máximo de paquete que puede
todas las máquinas involucradas en la
manejar una máquina se denomina MTU
conexión.
(Max Transmission Unit), y depende de
la tecnología utilizada, tal y como veremos
El mecanismo para conseguir este acuerdo
cuando hablemos sobre el nivel de enlace
se denomina Path MTU Discovery, y
a lo largo del curso.
viene detallado en el RFC 1191.
Por ejemplo, una tecnología Ethernet
utiliza una MTU de 1500 Bytes, mientras A grandes rasgos, lo que se hace es enviar
que en X.25 se utiliza una MTU de sólo un paquete demasiado grande, pero
576 Bytes. Pero bueno, ya explicaremos forzando a que no sea fragmentado
esto en otro número... (mediante una opción que se puede
especificar en la cabecera IP). Si alguna
De momento, tenemos que tener la idea máquina del camino del paquete no puede
intuitiva de lo que es la MTU que, por manejar un paquete tan grande, al no
cierto, está bastante relacionada con el poder tampoco fragmentarlo no le quedará
MSS, es decir, el tamaño máximo de más remedio que responder con un ICMP
segmento que vimos en TCP. El tamaño Destination Unreachable Code 4. A
máximo de segmento indica el tamaño partir de ahí, se irá repitiendo el proceso
máximo del campo de datos de un con diferentes tamaños de paquete, hasta
paquete TCP, el cual estará directamente que se de con un tamaño que sí que sea
relacionado con el tamaño de MTU de la aceptado por todas las máquinas.
máquina que envió el paquete TCP.
Este tamaño máximo para todo el camino
Si queremos que funcione correctamente
que se ha encontrado se denomina
una comunicación entre dos máquinas
precisamente Path MTU.
tendrá que haber un acuerdo sobre qué

2.2. Tiempo excedido (Time determinado, y este valor se irá

Exceeded) decrementando en cada router por el que
pase el paquete.
Como podemos ver, la cabecera de este
mensaje consta de los mismos campos Así, si por ejemplo un paquete tiene un
que el mensaje anterior: TTL = 3, el primer router que reciba el
paquete modificará este valor haciendo
TTL=2, y reenviará el paquete al próximo
router del camino entre el origen y el
destino.
En caso de que un paquete con TTL=0

Para explicar la utilidad de este mensaje llegue a un router, significará que el
vamos a ver mejor los campos que lo paquete no ha podido llegar a su destino
forman. en un plazo limitado, por lo que el router
tendrá que responder al transmisor del
Campo: Type mensaje con un ICMP de tipo Time
Exceeded, y Code 0.
Para este tipo de mensajes, su valor ha
Code 1: Tiempo de reensamblaje
de ser 11, en decimal, por supuesto.
superado.
Campo: Code
Otra situación en la que un paquete puede
caducar tiene relación con la
En este caso sólo existen dos posibles
fragmentación que ya mencioné antes.
valores, ya que este mensaje puede ser
enviado por dos motivos diferentes:
Como dije, un paquete demasiado grande
Code 0: Tiempo de vida superado.
puede ser dividido en fragmentos para
facilitar su transmisión. Los fragmentos
Como veremos a lo largo del curso, en
irán llegando al destino en cualquier orden,
la cabecera IP existe un campo TTL
y éste se encargará de reensamblar el
(Time To Live) que permite limitar el
paquete. Por supuesto, hay un límite de
número de routers que atravesará un
tiempo por el que estará esperando el
paquete para llegar a su destino.
destino a que le lleguen todos los
fragmentos, para evitar quedarse
Si no limitásemos este número de saltos,
esperando indefinidamente en caso de
se podría dar el caso de que un paquete
que haya habido algún problema de
quedase circulando para siempre en la
transmisión.
red en caso de que algún router mal
configurado produjese un bucle cerrado
Si un paquete que está en proceso de
en el que los paquetes van de un router
reensamblaje no se completa en un tiempo
a otro sin sentido, sin llegar jamás a su
determinado, se enviará un mensaje ICMP
destino.
de tipo Time Exceeded, y Code 1,
indicando que no se ha podido completar
Cada paquete IP llevará, por tanto, un
el reensamblaje del paquete.
campo TTL con un valor numérico

Trazado de rutas mediante Time reenviándolo, por lo que el paquete llegará

Exceeded al próximo router, R2. En cambio, en este
segundo router ocurrirá lo mismo que
Posiblemente habréis utilizado alguna antes, pues se encontrará con un paquete
vez la conocida herramienta traceroute. con TTL=0 que no podrá reenviar, por lo
que tendrá que responder con un ICMP
Como sabréis, esta herramienta permite Time Exceeded Code 0.
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. Este proceso continuará, incrementando
en uno cada vez el valor de TTL, hasta
Lo que hace traceroute es empezar que finalmente sea el host de destino
enviando un paquete cualquiera al destino el que nos responda:
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 máquina y la
máquina de destino, este router
decrementará el TTL, por lo que lo dejará
Como vemos en la imagen, el host de
en TTL=0. Al no poder reenviarlo, ya
destino no nos responderá con un Time
que el tiempo de vida del paquete ha
Exceeded, ya que el paquete sí que ha
expirado, tendrá que enviar un ICMP
podido llegar hasta él antes de expirar.
Time Exceeded Code 0 en respuesta.
En lugar de eso, nos responderá con otro
mensaje ICMP, de tipo Echo Reply, que
veremos más 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, más adelante comprenderemos
Este paquete contendrá como IP de
de lo que estoy hablando.
origen la del router que lo generó (R1),
por lo que conocemos así ya la IP del
2.3. Problema de parámetros
primer router que nos hemos encontrado
(Parameter Problem).
en el camino.
Este mensaje se envía cuando algún

A continuación, traceroute enviará otro
parámetro de la cabecera IP tiene un
paquete similar, pero con un TTL=2. El
valor incorrecto, siempre y cuando no sea
primer router del camino, R1 (cuya IP
un campo que tenga ya otro mensaje
ya conocemos), decrementará el TTL,
ICMP específico para notificar el error.
pero al ser ahora el TTL=1, podrá seguir

Este es el formato del mensaje: Destruyendo firewalls
Como comentario sobre este tipo de

mensaje ICMP comentaré un exploit para
una aplicación en concreto, que siempre
puede ser interesante.
Campo: Type La aplicación no es ni más ni menos que

Gauntlet Firewall, un firewall de
El valor en este caso es 12. Network Associates, la compañía del
famoso (y bastante triste) antivirus
Campo: Code
McAffee que, por cierto, hace poco
Aunque el RFC sólo especifica un posible apareció la noticia de que es posible que
valor para este campo, en realidad pueden Microsoft compre también esta compañía.
ser implementados otros valores (como
ya ha pasado con otros campos vistos
El exploit que, por cierto, también afecta
anteriormente).
a otro producto de la misma compañía,
Estos son los posibles valores: WebShield, aprovecha una vulnerabilidad
de estos programas que da lugar a una
denegación de servicio (DoS) con sólo
enviar un mensaje ICMP Parameter
Problem malformado.
El valor más habitual es el Code 0.
El exploit, y su explicación en
En este caso, el campo Pointer indicará castellano los tenéis en:
la posición de la cabecera IP en la que http://www.hakim.ws/ezines/RazaMexi
se encuentra el error. Conociendo la cana/raza011/0x02.txt
cabecera IP, podemos localizar el
parámetro exacto cuyo valor es incorrecto.
El Code 1 es usado cuando una 2.4. Calmar al transmisor

trasmisión requiere opciones IP (Source Quench)
adicionales, como las usadas por el
ejército de los EEUU al utilizar Este mensaje es útil para implementar
transmisiones seguras, en las que son un control de flujo rudimentario. Ya he
requeridas ciertas opciones de seguridad explicado algo sobre el control de flujo a
en los datagramas. lo largo del curso.
Sobre el Code 2 no hay mucho que decir, Como su nombre indica, este mensaje
ya que se explica por sí sólo. permite calmar al transmisor cuando está
Campo: Pointer enviando demasiados paquetes, y estos
no pueden ser procesados debido a la
Si el campo Code tiene valor 0, este excesiva velocidad.
campo especifica la posición en bytes
dentro de la cabecera IP donde se Cuando un paquete no pueda ser
encuentra el parámetro erróneo. procesado adecuadamente debido a la

saturación del buffer de recepción, habrá avisando así de que no da a basto.

que notificar esta situación mediante un
ICMP Source Quench. Cuando el Si estamos realizando un ataque de flood
transmisor reciba uno o más Source y empezamos a recibir mensajes Source
Quench, debe bajar la tasa de Quench de la víctima tenemos una buena
transferencia para no seguir saturando prueba de que nuestro ataque está
al receptor. funcionando.
Este mecanismo es más efectivo si el Por otra parte, el Source Quench mismo
receptor empieza a enviar los Source puede servir para realizar ataques DoS.
Quench antes de que haya realmente Si enviamos mensajes Source Quench
un problema, es decir, cuando esté cerca a la víctima le estaremos pidiendo que
del límite, pero sin haberlo superado aún. limite su ancho de banda porque
supuestamente nos está saturando. Si
El formato del mensaje nos es ya muy conseguimos suplantar la personalidad
familiar: de una máquina a la que esté conectada
la víctima (mediante spoofing) podremos
echar abajo esa conexión, limitando cada
vez más el ancho de banda.
2.5. Redireccionar (Redirect)
Este mensaje, bastante peligroso, se

Campo: Type
utiliza cuando un router R recibe un
paquete que debe llevar hasta un destino,
El valor es 4.
pero se da cuenta de que existe un camino
más corto hasta ese destino que no pasa
por R.
Campo: Code
Ve a m o s p o r e j e m p l o e s t e c a s o :
Aquí es siempre 0.
Denegación 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
enviándole mensajes ICMP Source
Quench, pensando que el bombardeo
no es malintencionado y, por tanto,

La máquina H1 envía un datagrama al Veamos el formato del mensaje:

router R1 para que lo transmita hasta la
máquina 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 podría Campo: Type
acceder directamente a R2 sin necesidad
de pasar por R1. El valor es 5.
Campo: Code
Si no notificase esta situación a H1 toda
la comunicación entre H1 y H2 seguiría De nuevo, tenemos varios posibles valores
el siguiente camino: 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.
Para el Code 2 y el Code 3 hay que

Mientras que si avisa de esta situación
anticipar de nuevo algo sobre el protocolo
mediante un ICMP Redirect, podría
IP, que aún no hemos visto.
ahorrarse un salto en el camino yendo
de forma más directa:
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 función 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.

En ciertos casos, un determinado router legítimo) de tipo Redirect, en el cual el

puede estar más dedicado a transmitir campo Gateway Internet Address
cierto tipo de servicio, por lo que se puede contenga la propia dirección IP de la
optimizar la comunicación utilizando los víctima.
caminos adecuados para cada caso.
Si la víctima es vulnerable a este ataque,
El RFC 1349 da detalles sobre el campo desde que reciba el paquete de Super
T O S y s u r e l a c i ó n c o n I C M P, Source Quench, redirigirá todo su tráfico
concretamente con los ICMPs Redirect, hacia si mismo, dando lugar a un bucle
y Destination Unreachable (donde infinito de tres pares de narices.
vimos que los Code 11 y 12 también se
refieren al tipo de servicio). El Super Source Quench es, por supuesto,
un ataque de tipo DoS, pero gracias a los
Campo: Gateway Internet Address paquetes Redirect de ICMP se pueden
llevar a cabo todo tipo de ataques de lo
Para los que aún no lo sepáis, un gateway más variopintos. Existen herramientas
es lo que nosotros estamos llamando un para automatizar este tipo de ataques,
router, por lo que este campo indica como WinFreez, que permiten realizar
precisamente la dirección IP del router ataques DoS, ataques de suplantación
al que queremos redireccionar el tráfico. man in the middle, etc, etc. En el momento
que tienes el poder de redirigir el tráfico
Por ejemplo, en el caso citado de una víctima hacia donde tú quieras los
anteriormente, el router R1 enviaría un límites sólo los pone tu imaginación.
mensaje ICMP Redirect donde este
campo contendría la dirección IP del 2.6. Petición de Eco (Echo
router R2.
Request)
Super Source Quench, y otras
Este es uno de los mensajes ICMP más
historias
interesantes, aunque en principio pueda
parecer tan simple que carezca de interés.
Entre los mil usos ilegítimos que se
pueden hacer de los mensajes ICMP
Además de utilizarse en la herramienta
Redirect, se encuentra el ataque
traceroute, como ya vimos, es también
conocido como Super Source Quench.
la base del funcionamiento del famoso
PING, ya que su función consiste
A pesar de que su nombre pueda
simplemente en solicitar a otra máquina
confundirnos, este ataque no tiene nada
que nos devuelva lo que le decimos, como
que ver con el ICMP Source Quench,
si de un eco se tratase.
aunque sí que es cierto que, si bien un
Source Quench puede ralentizar tu
Un mensaje Echo Request contendrá
conexión, un Super Source Quench lo
unos pocos datos de muestra (por
que hace es tirártela por completo.
ejemplo, se suele usar el abecedario:
abcdefghijklmnopqrstuvwxyz), y el host
El ataque consiste simplemente en enviar
que lo reciba debería responder mediante
un mensaje ICMP spoofeado (para que
otro mensaje ICMP diferente, que es el
aparentemente provenga de un router

Echo Reply (lo veremos a continuación), mensaje concreto de Echo Request, para
que contendrá los mismos datos de que el Echo Reply correspondiente pueda
muestra (el abecedario de nuevo, por especificar a qué petición de eco en
ejemplo). concreto está respondiendo.
El campo Sequence Number simula de

manera muy rudimentaria un número
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.
Como vemos, el formato del mensaje es
más complejo que el de los anteriores De nuevo, el estándar nos deja libertad
tipos de ICMP. para que utilicemos este campo según
las necesidades.
Campo: Type
Campo: Data
En este caso el valor es 8.
Este campo contiene los datos de muestra
Campo: Code
que queremos que nos sean devueltos,
Siempre tomará valor 0. como cuando gritamos Eco! y nos vuelve
la respuesta Eco!....
Campo: Identifier
En lugar de Eco podríamos poner cualquier
Este campo simula en cierto modo el
otra palabra, como el ya mencionado
comportamiento de los puertos UDP,
abecedario.
aunque de forma mucho más simple.
Así que ya sabéis, cuando vayáis por la
Simplemente es un número que sirve montaña y encontréis a un tío que está
para identificar una sesión de mensajes berreando el abecedario
de eco. abcdefghijklmnopqrstuvwxyz, no debéis
asustaros, ya que sólo será un friki con
Se usa por ejemplo cuando hacemos un una indigestión de mis artículos que habrá
ping a una máquina, ya que siempre se terminado creyéndose que es un PC y
hará más de un Echo Request a la está intentando hacer un ping
misma máquina. Toda esta serie de Echo
Sobre el mensaje Echo Request no voy
Request que componen un ping tendrán
a comentar nada de momento (en color
normalmente el mismo valor en el campo
rojo, me refiero , ya que comentaré
Identifier.
luego juntos los mensajes Echo Request
Realmente, el estándar no exige ninguna y Echo Reply después de hablar sobre
forma concreta de generar este campo, éste último.
por lo que se deja un poco a las
necesidades de cada aplicación. 2.7. Respuesta de Eco (Echo
Reply)
Campo: Sequence Number
Este mensaje tiene exactamente el mismo
Este campo, combinado con el anterior, formato, con los mismos campos.
permite identificar unívocamente un

Todos los campos de la cabecera deben Como ya sabemos, todas las máquinas
llevar una copia exacta de los campos de una red están interconectadas, por lo
del mensaje Echo Request al que están que teóricamente todos los paquetes que
respondiendo, excepto el campo Type, circulan por la red llegan a todas las
que debe ser 0, que es el número máquinas de la red. Cada máquina tendrá
asignado al tipo de mensaje ICMP Echo que ser capaz de discernir qué paquetes
Reply. van dirigidos a ella y cuales no. Este es
el motivo por el que un sniffer puede
La invasión de los pitufos funcionar.
No se puede hablar de ICMP sin hablar Lo que hace el sniffer es poner a la

de una de las técnicas más clásicas para máquina en modo promiscuo, es decir,
explotar este protocolo con fines poco hacer que recoja todos los paquetes,
éticos, que es la conocida como el pitufo. aunque no sean dirigidos para esa
Jejeje, bueno, ésta sería la traducción al máquina. Una máquina que no esté en
castellano. En realidad el término técnico modo promiscuo sólo debería recoger dos
es smurf. tipos de paquetes: los que van dirigidos
a su dirección IP, y los que van dirigidos
La técnica de smurf consiste en un ataque a la dirección broadcast.
DoS basado en los mensajes Echo
Por tanto, ¿qué pasaría si enviásemos un
Request y Echo Reply, y que se puede
mensaje Echo Request a la dirección
llevar a cabo sin necesidad de ninguna broadcast de una red? Pues teóricamente
herramienta especial, ni siquiera un todas las máquinas de la red tendrían
software para manipular raw sockets que recibir ese mensaje y, por tanto,
(como Nemesis o Hping, sobre los que enviar un Echo Reply en respuesta.
hablaré al final del artículo), si no que Imaginemos que estamos en una red con
basta con la herramienta PING que mil máquinas. Con sólo enviar nosotros
podemos encontrar en cualquier sistema un mensaje, habremos recibido mil
operativo. mensajes en respuesta...
El ataque consiste exactamente en un ¿Qué pasaría entonces si enviásemos ese

flood mediante mensajes Echo Reply Echo Request con la IP de origen
generados por máquinas que no son la spoofeada para aparentar que quien
del propio atacante, por lo que se hace manda el mensaje no somos nosotros, si
bastante complicado para la víctima el no la máquina de nuestra víctima?
encontrar al culpable. Pues, teóricamente, la víctima recibiría
1000 mensajes Echo Reply que no tiene
Va m o s a v e r en qué consiste
ni idea de dónde narices han salido. Sabrá
exactamente:
que las respuestas llegan de las máquinas
Todas las redes tienen definidas una de la red que hemos utilizado, pero no
dirección especial, que es la denominada podrá saber quién dio la orden a esa
dirección broadcast. Esta dirección IP red de que le mandase los mensajes.
especial está reservada para paquetes
Si lanzamos varios Echo Request a varias
que estén dirigidos a todas las
redes diferentes, podremos conseguir que
máquinas de la red, y no a una sola.
llegue un auténtico bombardeo de

mensajes Echo Reply a la víctima, con Para evitar convertir nuestra red en una
lo que podríamos llegar a saturar su amplificadora de ataques smurf, tenemos
conexión. que configurarla para que las máquinas
no respondan a mensajes ICMP dirigidos
a la dirección broadcast.
El ping de la muerte
Que nadie se eche las manos a la cabeza

diciendo: ¡Pero si el ping de la muerte
está más pasado de moda que las patillas
de Curro Jiménez!.
Es cierto que el ping de la muerte es un

ataque que difícilmente puede funcionar
hoy día, pero en su momento fue una
auténtica bomba así que merece al
menos una mención en este artículo en
el que no sólo se trata la actualidad, si
Como vemos en la imagen, lo único que
no también la historia de ICMP.
tiene que hacer el atacante es lanzar
unos cuantos pings, uno por cada red Digo lo de bomba porque es importante
que quiera utilizar como amplificadora diferenciar entre un DoS de tipo flood,
del ataque, utilizando en cada uno la y un DoS de tipo nuke.
dirección de broadcast, que es la que
Un flood ya hemos visto lo que es: tirar
vemos en la imagen.
abajo un sistema a base de saturarlo con
miles de paquetes. En cambio, un nuke
Una dirección broadcast normalmente se
es un ataque que también puede tirar
obtiene poniendo un 255 en aquellos
abajo un sistema, pero en este caso con
bytes de la IP que puedan variar según
sólo uno o unos pocos paquetes.
el tipo de red, es decir, poniendo un 255
donde en la máscara de red hay un 0.
Vimos un ejemplo de nuke al hablar del
ICMP Parameter Problem, y un ejemplo
Por ejemplo, para una red 192.168.1.1,
de flood por ejemplo en la técnica de
con máscara de red 255.255.255.0, la
smurf mencionada anteriormente.
dirección broadcast será
192.168.1.255.
El ping de la muerte (ping of death), y
sus variantes (como el jolt, o el IceNewk)
En general, para una red de clase A
es un ataque DoS de tipo nuke que
habrá que poner un 255 en las 3 últimas
explota una limitación de los sistemas
cifras de la IP, en una red de clase B
operativos, ya que estos suelen tener
un 255 en las 2 últimas cifras de la IP,
limitado a 65536 el tamaño máximo de
y en una red de clase C un 255 sólo en
paquete que pueden manejar.
la última cifra de la IP. ¿Qué no sabéis
de qué hablo? Pues esperad al próximo
No confundamos este tamaño con la MTU,
artículo del curso, que tratará sobre el
ni con el MSS, ya que en este caso se
protocolo IP.
refiere al tamaño que puede manejar el

propio sistema operativo, y no el tamaño http://www.fi.upm.es/~flimon/ddos.pdf

de los paquetes que se pueden transmitir Es un documento muy interesante y fácil
a través de una conexión. de leer, en el que encontraréis también
una descripción detallada del ataque smurf
Como la MTU siempre será menor de que mencioné anteriormente.
65536 la forma en que se conseguía
enviar el ping de la muerte era utilizando Antes de que me vaya más del tema,
la fragmentación de la que ya hemos estaba diciendo que se puede aprovechar
hablado. El ping de la muerte consistía un mensaje ICMP para pasar información
simplemente en un mensaje Echo sin que un firewall se entere.
Request de un tamaño mayor que el
Si tenemos, por ejemplo, un troyano en
que podía manejar el sistema operativo
nuestro sistema, pero tenemos un
receptor, que se enviaba fragmentado
firewall, lo que no podrá hacer el troyano
para que pudiese circular hasta su destino.
es abrir un puerto TCP en escucha para
Una vez en el destino, el sistema receptor
que su controlador se conecte
intentaba reensamblar el paquete
remotamente a nuestra máquina para
uniendo los fragmentos y, al encontrarse
hacernos todo tipo de judiadas.
con que el paquete era más grande de
lo que podía manejar, el sistema
Como los firewalls son cada día más
directamente cascaba.
comunes, los troyanos tienen que buscar
otros sistemas más ingeniosos para poder
Este problema fue descubierto en 1996,
comunicarse con su controlador. Uno de
y en 1997 la mayoría de los sistemas
estos sistemas consiste precisamente en
operativos ya disponían de parches para
aprovechar los mensajes Echo Request
arreglar este problema, pero.... ¿quién
y Echo Reply.
sabe cuántos sistemas pueden quedar
ahí fuera sin parchear?... Como hemos visto, ambos mensajes
contienen un campo DATA en el que se
Túneles para pasar información a puede meter cualquier cosa... pues
través de firewalls simplemente intercambiando mensajes
de Echo que contengan todos los datos
Un sistema que es utilizado por programas que queramos transmitir entre el troyano
maliciosos, como troyanos, demonios de y su controlador, estos podrán realizar
redes DDoS, o cualquier otra aplicación una comunicación bastante similar a la
que necesite pasar información a través que podrían llevar a cabo a través de un
de un firewall, es el crear un túnel puerto UDP.
mediante mensajes ICMP.
Otra historia es si el firewall filtra también
¿Qué os ha sonado muy raro eso de los los mensajes ICMP, pero en la mayoría
demonios de redes DDoS? Jeje, he de los sistemas se deja abierto el Echo
conseguido despertar vuestra curiosidad Request hacia el exterior, y el Echo
una vez más soltando por ahí un término Reply desde el exterior, por lo que el
raro como quien no quiere la cosa. troyano podría utilizar Echo Request para
enviar sus datos, y el controlador del
Pues si queréis saciar vuestra curiosidad troyano podría utilizar Echo Reply para
podéis leer este documento en castellano: lanzar sus órdenes.

2.8. Petición de Sello de momento exacto en el que el emisor del

Tiempo y Respuesta de Sello Timestamp Request envió el mensaje.
Este tiempo se mide en milisegundos
de Tiempo (Timestamp
transcurridos desde la medianoche
Request y Timestamp Reply)
Campo: Receive Timestamp
Estos mensajes, al igual que los
anteriores, también son una pareja. Este campo se generará en el mensaje
Timestamp Reply. Especifica el
El Timestamp sirve para medir los momento exacto en el que el receptor del
tiempos de respuesta en una Timestamp Request (que, por supuesto,
comunicación entre dos máquinas. El será el emisor del Timestamp Reply)
mensaje Timestamp Request envía un recibió el mensaje Timestamp Request.
dato con el instante en que el mensaje Campo: Transmit Timestamp
fue enviado, y el mensaje de respuesta
Timestamp Reply contendrá otros datos Este campo se genera también en el
informando sobre el tiempo que tardó el mensaje Timestamp Reply. Especifica
paquete en ser procesado, tal y como el momento exacto en el que el emisor
veremos en breve. del Timestamp Reply envío 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 Muchos sistemas de seguridad dependen

de la generación de números
El tipo para el mensaje Timestamp pseudoaleatorios.
Request es 13, y para el mensaje
Timestamp Reply es 14. Un ordenador es una máquina totalmente
determinista, por lo que es imposible
Campo: Code conseguir que genere un número
totalmente aleatorio, es decir, sin estar
Es siempre 0 en ambos mensajes. basado en ninguna regla matemática que
lo genere.
Campos: Identifier y Sequence
Number Lo que se suele hacer para simular esta
aleatoriedad es aprovechar un parámetro
Tienen el mismo significado que en el que está en permanente cambio: el
caso de Echo Request y Echo Reply. tiempo.
Campo: Originate Timestamp Los números pseudoaleatorios que genera

un ordenador suelen estar basados en
Este campo es generado en el mensaje
una fórmula matemática que incluye como
Timestamp Request. Especifica el

una de sus variables el tiempo exacto en directamente en red, y nada más arrancar
el que se está generando el número (en necesitaban conocer la red en la que
milisegundos, o cualquier otra medida). entraban.
Esto permite que dos números generados
consecutivamente con la misma fórmula El mecanismo consistía en enviar un
den resultados diferentes. datagrama que tuviese ceros en las
direcciones IP de origen y de destino
Por tanto, el permitir que cualquier (Information Request). Este paquete,
máquina nos pregunte la hora exacta al ser recibido por la máquina que se
(con precisión de milisegundos) que encargase del asunto dentro de la red,
tenemos en nuestra máquina, es facilitarle sería respondido con otro mensaje que
en gran medida la explotación de sí que tuviese direcciones IP de origen y
cualquier sistema que maneje números de destino (Information Reply). La
aleatorios. Recordemos por ejemplo lo dirección IP de destino del Information
que conté en el artículo sobre TCP acerca Reply sería la IP asignada a la máquina
de los números de secuencia, y de las que la solicitó.
graves consecuencias que tendría que
un atacante conociese los números
pseudoaleatorios que hemos utilizado
para generar los números de secuencia
en nuestras conexiones TCP.
Ya conocemos el significado de todos los
También conté algo sobre la adivinación campos, así que sólo hay que decir que
de números pseudoaleatorios en el el campo Type para Information
artículo sobre DNS de la serie RAW, así Request es 15, y para Information
que a los aficionados a las matemáticas Reply es 16. El campo Code para ambos
les recomiendo que le echen un vistazo. será 0.
Buscando víctimas potenciales

2.9. Petición de Información
y Respuesta de Información Uno de los usos más clásicos de ICMP
(Information Request, e para fines oscuros es el de la detección
de máquinas en una red, para apuntar
Information Reply)
víctimas potenciales.
Esta nueva parejita de mensajes está en

No he hablado de ello hasta ahora porque
realidad obsoleta, ya que su funcionalidad
el sistema más obvio y más común es
ha sido sustituida y mejorada por otros
utilizar simplemente un escaneo de
sistemas, como BOOT o DHCP.
pings que vaya recorriendo todas las
posibles IPs para ver cuáles de ellas
Al igual que en estos protocolos, el
responden al ping. Cada IP que responda
objetivo de estos mensajes es conseguir
es una máquina que está funcionando en
que una máquina entre en una red de
la red y, por tanto, una víctima potencial.
forma automatizada, es decir, sin conocer
previamente la configuración de la red. Como este sistema es bien conocido por
Este sistema era útil en estaciones de cualquier administrador que vigile
trabajo sin disco que arrancaban mínimamente la seguridad, es fácil

encontrarse con sistemas que tengan Yo personalmente tengo abiertos sólo los
cerrados los mensajes de Echo, por lo mensajes Echo Reply (para poder hacer
que no responderían al Echo Request, ping y traceroute), Time Exceeded (para
aunque la máquina estuviese vivita y poder hacer traceroute), y Destination
coleando. Un escaneo de pings nos diría Unreachable (para poder hacer P-MTU-
que esas máquinas no existen, ya que D, entre otras cosas).
no han respondido a nuestra llamada.
Si queréis asegurar de verdad vuestro
Existen herramientas que aprovechan sistema o vuestra red os aconsejo que
otros tipos de mensajes ICMP menos investiguéis bien el tema y lleguéis a
comunes para hacer exactamente lo establecer una decisión sobre vuestra
mismo, con la ventaja de que, al ser un política de seguridad con ICMP.
mensaje poco conocido y, aparentemente
inocente, es más probable que el 2.10. Otros mensajes ICMP.
administrador no los haya cerrado en el
firewall. Un ejemplo de estas Aunque el RFC 792 ni siquiera los
herramientas es ICMPEnum, que utiliza menciona, existen otros tipos de mensaje
precisamente no sólo Echo Request para ICMP definidos. Al no formar parte del
hacer los escaneos, si no también estándar definido en el RFC, sólo nombraré
Timestamp Request, e Information alguno de ellos por si os interesa buscar
Request. información sobre alguno en concreto.
Como ya hemos visto que los dos Personalmente, yo no me he encontrado

primeros tienen otros problemas nunca con casi ninguno de estos mensajes
potenciales de seguridad, quizá podamos ICMP, así que no sé hasta qué punto será
tener suerte y encontrarnos con que el útil conocerlos.
administrador ha considerado totalmente
inofensivo el Information Request, y
haya dejado aquí la puerta abierta que
buscábamos.
¿Cuál es la conclusión que podemos sacar

de este comentario rojo y de todos los
demás? 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 Como de costumbre, la lista completa de
ping y traceroute nosotros desde números asignados a ICMP es mantenida
nuestra máquina, pero pocos motivos por el IANA (Internet Assigned Numbers
hay para dejar abiertos sus contrarios, Authority), y la podéis consultar en:
los mensajes que, en lugar de
http://www.iana.org/assignments/icmp-
respondernos, nos preguntan a nosotros
parameters
desde fuera.

Buscando huellas
He dejado para el final esta técnica que

es en realidad una de las que dan más
utilidad a ICMP a la hora de encontrar
información sobre un sistema para un
posible ataque. Lo he dejado para el final
porque es una técnica que está
relacionada no con uno sólo, si no con
muchos tipos de mensajes ICMP.
La técnica conocida como OS

Fingerprinting consiste en analizar las
reacciones de un sistema ante distintos
tipos de mensajes ICMP y, conociendo
cual es la reacción de cada sistema Aquí vemos que ante un mensaje ICMP
operativo conocido, poder realizar así TimeStamp Request a la dirección
una comparación que nos lleve a deducir broadcast de una red, podemos obtener
qué sistema operativo está corriendo en información precisa sobre el sistema
la máquina que estamos analizando. operativo, siempre que la máquina
Hay una panda de chiflados (con cariño) responda con un TimeStamp Reply.
que se dedican a hacer tablas que reflejan
el comportamiento de cada sistema ante En caso de que no responda, se
cada tipo de mensaje, aunque no llegan considerará (de momento) un SO
a estar tan chiflados como para tratar desconocido, y habrá que hacer otras
de usar es información a palo seco... lo pruebas similares.
que hacen es introducir toda esta
información en una aplicación que Si ha respondido, tenemos 3 posibles
automatiza la tarea de comparar las SOs: HPUX 10.20, Sun Solaris, o Linux
reacciones del sistema con la información Kernel 2.2.x. En ese caso, habrá que
conocida sobre cada sistema operativo. continuar con la prueba, haciendo ahora
un Information Request a la dirección
La más conocida de esas aplicaciones es broadcast. Si responde, ya sabemos que
NMap, de la que ya hemos hablado se trata de un HPUX 10.20. Si no
bastante en la revista. Nmap contiene responde, habrá que continuar probando,
gran cantidad de información sobre las esta vez con un Address Mask Request
reacciones de cada SO ante (uno de los ICMPs que no hemos visto).
determinados paquetes, y utiliza esta Si responde, se trata de un Sun Solaris,
i n f o r m a c i ó n p a ra h a c e r u n O S y si no, de un Linux Kernel 2.2.x.
Fingerprinting, es decir, para deducir
cuál es el sistema operativo de la máquina Esta información también se puede
que estamos analizando. mostrar en tablas más complejas, como
ésta, que muestra el valor del campo TTL
Para que os hagáis una idea del tipo de que usa cada sistema operativo al enviar
información de la que estoy hablando, mensajes ICMP de Echo:
podemos mostrar por ejemplo este árbol:

-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.
Como ya he dicho, esta información no -qE : inyecta un paquete de Echo.
nos hace falta conocerla, ya que viene -qU : inyecta un paquete Destination
automatizada en herramientas como Unreachable.
Nmap, o Xprobe, pero si queréis -qX : inyecta un paquete Time
información detallada y tenéis los Exceeded.
c*j*n*s... como los de un toro, podéis -qR : inyecta un paquete Redirect.
leeros la biblia del ICMP, que la tenéis en -qT : inyecta un paquete Timestamp.
h t t p : / / w w w . s y s -
security.com/archive/papers/ICMP_Sca Si, por ejemplo, queremos lanzar un
nning_v3.0.pdf . ataque Super Source Quench a la IP
192.168.2.2 para cortar su conexión TCP
3. RAW Sockets ICMP con la IP 215.22.69.22, podríamos hacer:
Para terminar, volvemos con nuestros nemesis icmp i 5 c 1 G 127.0.0.1

amigos Nemesis y Hping para jugar esta v b 192.168.2.2 B 215.22.69.22
vez con el protocolo ICMP. D 192.168.2.2 S 215.22.69.22 p
6
Existen herramientas dedicadas para
explotar el protocolo ICMP, como algunas El parámetro i 5 especifica que se trata
de las ya mencionadas, o la herramienta de un mensaje de tipo Redirect, que
SING (Send ICMP Nasty Garbage), pero sería como utilizar la opción qR. El
por no romper la tradición vamos a seguir parámetro c 1 especifica un Code 1, es
en nuestra línea, utilizando las decir, redireccionar los datagramas para
herramientas ya conocidas. el host de destino.
3.1. Nemesis El parámetro G 127.0.0.1 es la base

del ataque Super Source Quench, ya
Empezamos con Nemesis, cuyas que indicamos aquí a la víctima que
instrucciones tenemos en el archivo redirija sus paquetes a la dirección de
nemesis-icmp.txt de la carpeta en la loopback, 127.0.0.1, es decir, a sí
que instalamos la aplicación. mismo.
Resumo aquí las opciones más básicas: El parámetro v es el clásico verbose

que nos muestra información de lo que
-i : permite especificar el valor del campo estamos haciendo.
Type.
-c : permite especificar el valor del campo El parámetro b no lo he explicado, y
Code. forma parte del campo Internet Header
-e : permite especificar el valor del campo + 64 bits of Original Data Datagram.
Identifier. Es concretamente la IP de origen del

datagrama que generó el supuesto error --spoof :permite especificar cualquier IP

que dio lugar a que se generase el de origen (IP spoofing).
mensaje Redirect.
--rand-source : permite hacer un IP
El parámetro B forma parte también de spoofing con direcciones IP aleatorias.
ese campo, y contiene la dirección IP de
--rand-dest : permite utilizar direcciones
destino del datagrama original que
IP de destino aleatorias. Algo parecido
supuestamente originó el Redirect.
a lo que expliqué que hacían algunos
gusanos, aunque en realidad lo normal
Los parámetros D y S ya los
es que un gusano utilice algún tipo de
conocemos de haber usado otras veces
heurística para generar las IPs de una
Nemesis, y son la IP de destino y de
forma más inteligente que una
origen respectivamente para este mismo
aleatoriedad pura y dura.
paquete.
--dont-frag : obliga a que el paquete no
El parámetro p 6 forma parte también
sea fragmentado. Esta opción puede ser
del campo Internet Header + 64 bits
ú t i l p a ra r e a l i z a r u n P - M T U - D .
of Original Data Datagram, ya que es
el número de protocolo de transporte --tos : permite definir el tipo de servicio
que había especificado en el datagrama que, como hemos visto, está relacionado
original, el cual, al tratarse de TCP, será con algunos mensajes ICMP.
6.
--ttl : permite marcar un tiempo de vida
Por supuesto, os muestro este ejemplo
para el paquete IP. Como ya sabemos,
sólo para mostrar el funcionamiento de
esto nos permite, entre otras cosas, hacer
Nemesis ICMP, y no garantizo que vaya
un traceroute.
a funcionar.
--tr-keep-ttl : esta opción, combinada
3.2. Hping2 con la anterior, permite investigar un
router en concreto del camino. Esta opción
Vamos a ver algunas de las opciones que fija el valor de ttl, por lo que podríamos
nos da hping2 para ICMP. enviar varios paquetes, por ejemplo, al
En primer lugar, veamos las opciones cuarto router del camino haciendo: --ttl
generales: 4 --tr-keep-ttl.
--verbose : el clásico modo verbose Por último, algunas de las opciones

para ver información en pantalla. específicas para ICMP. Por supuesto,
tenéis todo mucho mejor explicado en
--count : permite especificar el número man hping2 :
de paquetes que queremos enviar.
--icmptype : permite especificar un Type
--traceroute : este es un modo especial en la cabecera ICMP.
que permite hacer un traceroute.
--icmpcode : permite especificar un Code
en la cabecera ICMP.
Con respecto a la parte IP que, por
supuesto, también es necesaria para --icmpipproto : podemos especificar
generar paquetes ICMP, tenemos: también los valores del campo Internet

Header + 64 bits of Original Data claro que no todo el mundo consulta estas
Datagram. Por ejemplo, este parámetro páginas para protegerse, y en cambio
es para especificar el número de basta con que una sola persona consulte
protocolo del datagrama que originó el esta lista con fines perversos para que
mensaje ICMP. pueda atacar a cualquier otra persona
que no haya tenido en cuenta la lista. Así
--icmpcksum : nos permite generar un que, una vez más, no se sabe si es peor
checksum inválido. Por defecto, si no el remedio o la enfermedad.
ponemos esta opción, hping2 generará
automáticamente el checksum correcto. Espero que este artículo os haya resultado
interesante, y que por lo menos haya
--file : permite especificar un fichero despertado en vosotros la curiosidad por
para el campo de DATOS. muchísimas cosas que he esbozado para
que vosotros ampliéis información de lo
Vamos a ver un ejemplo sencillísimo, que más os haya llamado la atención.
para realizar un ataque smurf a la IP
217.138.2.2, utilizando como Por este artículo han circulado muchos
amplificadora la red 209.5.x.x : nombres que pueden ser fácilmente
consultados en Google, así que os animo
hping2 209.5.255.255 --icmp -- a que lo hagáis.
verbose --spoof 217.138.2.2
Autor: PyC (LCo)
¡Así de simple! Por cierto, que tenéis
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 dirección broadcast). Podéis
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
máquinas 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á

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 Dirección de Red, qué son
y cómo funcionan las Máscaras de Red, cómo un paquete es encaminado en una red, cómo
se reparten el pastel de los rangos de IPs los ISPs y muchas cosas mas.
INTRODUCCIÓN Si todo sigue el rumbo que espero, una

vez que termine la parte básica del
Este mes empezamos con uno de los curso de TCP/IP lo completaré con un
puntos más interesantes: la capa de artículo dedicado al protocolo IPv6. Este
red, es decir, la capa IP, que es una de es una nueva versión del protocolo IP,
las que dan su nombre a toda la pila de aún no extendida mundialmente, que es
protocolos que componen el llamado el futuro para una Internet que está
TCP/IP. llegando actualmente al límite de sus
posibilidades técnicas.
Mucho hay que decir sobre esta capa,
quizá la más importante, por lo que de Una vez más tengo que insistir en que
momento esta primera entrega la mi forma de explicar las cosas no es la
dedicaré únicamente a presentar algunos clásica, ya que pienso que es absurdo
de los conceptos relacionados con ella, repetir una vez más aquello que está
concretamente todo lo referente a las explicado de la misma forma en mil sitios
direcciones IP. diferentes. Por tanto, aprovechando que
esta revista se llama PC PASO A PASO,
Mucho se ha mencionado a estos mi forma de explicar las cosas será muy
numerajos en la revista, pero pocas lenta, pero segura, no mostrando las
veces se ha entrado en detalle sobre lo cosas sin más, si no llegando a ellas desde
que realmente son y cómo funcionan. el fondo de los conceptos básicos.
A lo largo de este artículo veremos en Así, ruego un poco de paciencia a aquellos

detalle en qué consiste una dirección que digan ¿pero cómo puede estar
de red, cómo funcionan las máscaras, explicando lo que es una máscara de red
el encaminamiento en una red en 20 páginas, si en cualquier sitio está
TCP/IP como Internet, las clases de explicado en sólo una página?,
redes, las direcciones reservadas, las
redes locales, las direcciones Mi intención es que este curso no sea un
broadcast, e introduciremos otros curso más de TCP/IP, si no un curso
protocolos relacionados, como son el diferente, una alternativa para aquellos
DHCP o el ARP. que están cansados de encontrar una y
otra vez la misma forma de contar las
Dejo ya para otro artículo la explicación cosas (muchas veces imposible de
de la cabecera IP, así como el entender por lo críptico del lenguaje
funcionamiento detallado del protocolo. utilizado) y una y otra vez muchas

CURSO DE TCP/IP - LA CAPA IP - LAS DIRECCIONES IP - CURSO DE TCP/IP - LA CAPA IP
personas dejan de estudiar estos temas una comunicación entre sólo dos de ellos,
porque no llegan a entender lo que leen será imprescindible asignar a cada uno
vamos a ver si conseguimos arrojar un una dirección única que permita
poco de luz!!! identificarles unívocamente.
1. LA FUNCIÓN DE LAS Así, la red telefónica tiene millones de

DIRECCIONES IP abonados, pero cada uno de ellos tiene
un número de teléfono siempre
diferente a los demás.
El concepto fundamental de lo que es
una dirección IP ya lo he repetido en
Lo mismo ocurre con la red de correo
varias ocasiones, pero es tan importante
postal, en la que cada persona tiene una
que ha de ser repetido una y otra vez,
dirección única.
sobre todo para aquellos nuevos lectores
que se incorporan ahora al curso de
En la red postal, la combinación de la
TCP/IP (aunque a estos nuevos lectores
les advierto que van a tener muy dirección de destino de la carta o paquete
complicado poder seguir el curso a partir (lugar donde debe llegar el paquete), y
de este punto sin haberlo pillado desde el remite del mismo (lugar de donde se
el principio). envía el paquete), definen claramente los
dos elementos de la comunicación. Lo
mismo ocurre en la red telefónica, con la
! Este curso... combinación de los dos números de
teléfono (al que llamas, y desde el que
Este curso es de los más veteranos de la revista PC PASO llamas).
A PASO. Se empezó con la serie de artículos RAW (donde
se trataron en profundidad los protocolos más importantes) Internet es una red formada por millones
y se siguió con las serie TCP/IP (donde "asaltamos el de ordenadores de todo el mundo pero,
corazón" de las comunicaciones por red). a diferencia de lo que puede parecer, las
comunicaciones son siempre entre sólo
Aunque intentamos que cada artículo sea comprensible "en dos ordenadores.
sí mismo", llega un momento en que es muy difícil asumir
el contenido de los mismos sin haber estudiado las anteriores Cuando entramos en un chat en el que
entregas de la serie. Te recomendamos que pidas las revistas hay 30 usuarios (o 50, o 200), en realidad
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 todo funciona gracias a varios pares de
www.hackxcrack.com. conexiones entre los diferentes usuarios
y un servidor central. Lo mismo ocurre
La función de una dirección IP es la cuando estamos jugando a un juego ON
misma que la de un número de teléfono, LINE en el que haya varios jugadores
o la de una dirección postal: identificar simultáneamente, o en cualquier otro
unívocamente a uno de los entorno en el que parezca que hay muchos
participantes en una red de ordenadores conectados entre sí al mismo
comunicación. tiempo. Así que repito: en Internet (y,
en general, en cualquier red TCP/IP)
En cualquier entorno en el que haya más jamás se conectan directamente
de dos elementos, y se desee establecer entre sí más de dos máquinas.

servidor de chat, que es el único que

conoce las direcciones IP de todos los
usuarios del chat.
¿Cómo sabe el servidor cuál es la IP del

usuario que se acaba de conectar? Pues
sencillamente mirando la cabecera IP
del paquete de inicio de conexión del
usuario, ya que en todas las cabeceras IP
están siempre especificadas las direcciones
IP de origen y destino del paquete, tal y
como veremos en el próximo artículo, en
el que detallaremos el formato de la
cabecera IP.
En la imagen vemos el ejemplo de un Los que no hayáis seguido todos mis

chat entre 4 personas, el cual funciona artículos probablemente os estaréis
gracias a pares de conexiones entre cada preguntando ahora por qué he dicho que
usuario y el servidor central. Observamos los usuarios del chat tienen que conocer
también una quinta conexión, entre dos la dirección IP del servidor para poder
usuarios, que podría ser la transferencia conectarse, ya que probablemente muchos
de un archivo (por ejemplo, un DCC en de vosotros habréis entrado en una red
una red de IRC). de IRC (o cualquier otro Chat) y jamás
habéis tenido que aprenderos ningún
Por tanto, es fundamental que cada uno número raro para poder conectar. Gracias
de los usuarios del chat conozca la a Dios (o más bien al IETF ), los seres
dirección IP del servidor de chat. Una humanos no tenemos que tratar
vez que ellos se conecten al servidor de (normalmente) con todos esos numerajos
chat, éste conocerá también la dirección difíciles de recordar, si no que podemos
de ellos, igual que cuando recibimos una utilizar unos nombres equivalentes mucho
llamada de teléfono podemos ver el más intuitivos, como:
número desde el cual nos están llamando. www.google.com, irc.efnet.nl, etc., etc.
Si bien en el teléfono no es imprescindible Esto se consigue gracias a un sistema

conocer el número del que nos llama, en llamado DNS que permite asociar un
el caso de TCP/IP no sería posible la nombre más humano a cada dirección
comunicación si las dos partes no conocen IP. De esta forma, cada vez que queremos
perfectamente la dirección IP de su acceder a una máquina nos basta con
interlocutor. conocer su nombre, y no los números
que forman su dirección IP.
Para el caso de la transferencia del archivo
que vemos en la imagen, sería necesario Cuando solicitamos una conexión con una
que uno de los dos usuarios conociese máquina a partir de su nombre, nuestro
la dirección IP del otro para poder ordenador (sin que nosotros nos
conectarse a él. Para esto, lo que hace enteremos), primero tendrá que traducir
es pedir esta dirección IP a través del el nombre de la máquina para obtener la

dirección IP asociada, lo cual hará Ponemos un caso real y lo entenderemos

mediante una serie de consultas a unos rápidamente:
servidores especiales que conocen las
direcciones IP asociadas a cada nombre. CASO REAL TELEFÓNICA:
Un buen día, Telefónica decide ofrecer
Una vez que ya tiene la dirección IP, se a sus usuarios conexión a Internet y
conectará a esa máquina sin que nosotros para ello necesita un montón de
nos hayamos enterado del proceso. Desde direcciones IP. Pues eso, llama a
nuestro punto de vista parece como si InterNIC y le dice que le pase un
directamente pudiésemos conectarnos montón de IPs.
conociendo sólo el nombre, y no los
InterNIC, una vez estudiada la
numerajos.
petición, le asigna a Telefónica un
generoso rango de direcciones.
Todo el sistema DNS lo expliqué con todo
Telefónica YA TIENE IPs!!! Ahora
detalle en la serie RAW de esta revista,
pone a sus genios de publicidad a
hace ya varios meses, por lo que espero
trabajar y nos machaca con sus
que el artículo esté liberado para que lo
anuncios en todos los medios de
podáis bajar y comprender cómo funciona
comunicación... contrata tu acceso a
realmente todo esto.
Internet con Telefónica y bla, bla, bla.
Por cierto, uno de sus anuncios era
Ahora posiblemente os estaréis haciendo
muy interesante ¿recuerdas el del
otra pregunta: ¿de dónde salen las
mono?... en ese nos insultaba a todos
direcciones IP?
los usuarios de Internet españoles
comparándonos con un mono (a
Está claro de donde salen los números
tragar y a callar)
de teléfono: es Telefónica la que asigna
Cuando Tú (o Yo) llamamos a
un número diferente a cada abonado.
telefónica y contratamos el acceso a
También está claro de donde salen las
Internet, NO ES INTERNIC quien te
direcciones postales: Correos asigna un
asignará una IP, será TELEFÓNICA
código postal a cada zona y el resto de
quien te asigne la IP. Por supuesto,
la dirección postal depende de la calle y
TELEFÓNICA te dará una de las IPs
piso y puerta en el que viva cada usuario
que previamente INTERNIC le ha
(el nombre de la calle lo pone el
asignado a ella.
ayuntamiento y el piso y la puerta el
constructor de la vivienda).
Telefónica puede hacer con sus IPs LO
QUE QUIERA!!! Desde dártela a ti (su
En el caso de las direcciones IP, también
nuevo cliente) hasta ceder (alquilar) a
tiene que haber algún organismo
terceras compañías parte del rango que
regulador que evite que dos máquinas
previamente le confió INTERNIC.
tengan la misma dirección IP en una
misma red. Este organismo es InterNIC,
Esta libertad para que el ISP de turno
que se encarga de asignar unos rangos
haga lo que quiera con su rango de IPs
de direcciones IP a cada organización.
es lo que da lugar a la existencia de
InterNIC delega en cada organización
direcciones IP dinámicas. Nuestro ISP
para que asignen cada IP específica a
(proveedor de servicios de Internet, como
cada máquina dentro de ese rango.

Estos puntos lo que hacen en realidad es

Telefónica en este ejemplo) podrá decidir separar las cifras del número. ¿Cifras?
asignarte una u otra IP en cada momento ¡Pero si la primera cifra es 192! Yo pensé
según los usuarios que haya conectados, que una cifra iba sólo desde 0 hasta 9...
sin tener que dar explicaciones a
InterNIC o ningún otro organismo. Pues esto es así en la base que estamos
Mientras Telefónica se encargue de que acostumbrados a utilizar: la base 10, o
nunca haya dos direcciones IP iguales, y base decimal. En base decimal tenemos
de que nunca utilice una dirección IP que las cifras 0, 1, 2, 3, 4, 5, 6, 7, 8, o 9.
no esté dentro de su rango asignado, Pero pueden existir muchas bases
podrá cambiar a su gusto las direcciones diferentes, por ejemplo:
IP de cada usuario según le convenga.
la base 2, o base binaria
(únicamente hay 2 cifras): las cifras
! Desgraciadamente...
son sólo 0, o 1.
la base 16, o base hexadecimal
Desgraciadamente, cuando decimos que el ISP puede hacer
(hay 16 cifras): hay más cifras que
"lo que quiera" con sus IPs, incluimos desagradables
en la base 10, siendo éstas 0, 1, 2, 3,
sorpresas:
4, 5, 6, 7, 8, 9, A, B, C, D, E, y F
Hay ISPs que únicamente te ofrecen IPs Dinámicas.
Esto provoca que no puedas tener ciertos servicios en
tu PC (por ejemplo un servidor FTP) sin utilizar algún ! Fíjate que como...
tipo de re-direccionamiento automático por nombre (en
anteriores números de la revista ya explicamos como
Fíjate que como se nos han acabado las cifras de la base
hacer esto con todo detalle).
decimal, para llegar a 16 cifras se utilizan letras. Los que
Hay ISPs que únicamente de dan una IP FIJA si la
se "inventaron" el sistema hexadecimal podrían haber
pides expresamente, pero sorpresa!!! Te cobrarán entre
utilizado cualquier otro símbolo para sus cifras, por ejemplo
6 y 24 euros al mes por tan "preciada" posesión.
letras griegas o "dibujitos" egipcios.
2. LAS DIRECCIONES IP TAL Como vemos, la base 10 tiene 10 cifras

Y COMO SON diferentes, la base 2 tiene 2 cifras
diferentes, y la base 16 tiene 16 cifras
Hasta ahora he estado hablando de unos diferentes. Por tanto, la base 256
numerajos asumiendo que todos habéis tendrá... 256 cifras diferentes. Cada una
visto alguna vez una dirección IP, y espero de estas cifras estaría comprendida entre
que así sea. Para los nuevos (nuevísimos) 0 y 255 (1, 2, 3, 4 58, 59 102, 103
de la clase os muestro aquí el aspecto 198, 199 253, 254 y 255).
de una dirección IP tal y como las solemos
conocer: Una dirección IP no es más que un
número de 4 cifras en base 256. Por
192.168.2.15 tanto, la primera cifra del número del
ejemplo será 192, la segunda 168, la
Como vemos, es un número compuesto tercera 2, y la última será 15 ------>
de 4 números separados por puntos. 192.168.2.15

¿Y por qué se utiliza esta base tan Para lo que voy a explicar a continuación
rara cuando estamos acostumbrados es imprescindible que conozcáis la forma
a utilizar la base decimal de toda la de convertir una IP en su formato clásico
vida? Pues porque, aunque las (192.168.2.15) a su formato real, con
personas estemos acostumbrados a
todas las cifras binarias. Así que ruego
la base decimal, ésta no es muy
un poco de paciencia a los que estáis ya
apropiada para las máquinas, que son
un poco hartos de mi insistencia con el
las que realmente tienen que lidiar con
las direcciones IP. Concretamente, a tema de la aritmética binaria, porque voy
las máquinas sólo les gusta la base 2 a explicar de nuevo cómo convertir
(binaria), y sus derivadas. números de decimal a binario, aunque en
esta ocasión no voy a explicar el método
Una base muy íntimamente ligada a la matemático, si no el sistema que utilizo
base 2 es la base 256, que es la que yo para poder hacerlo de cabeza, sin
da lugar a la existencia de los famosos necesidad de lápiz y papel
bytes, u octetos. Por tanto, cada una de
las cifras de una dirección IP corresponde La gran ventaja de esta forma de cambiar
a un byte, por lo que cada dirección IP de base decimal a binaria es que no es
tiene un tamaño de 4 bytes. Un byte necesario realizar ninguna división, ni
es, en cierto modo, el tamaño elemental ninguno de los engorros que expliqué en
de información que puede manejar una aquel otro artículo.
máquina (esto no es del todo así, pero
es para que nos entendamos). Si no te En cambio, la desventaja es que es
ha quedado claro sigue leyendo necesario estar bastante familiarizado con
la aritmética binaria, hasta el punto de
Como he dicho, las máquinas sólo
que hay que conocer de memoria todas
entienden el lenguaje binario, pero esa
las potencias de 2, con exponentes de 0
IP que os he mostrado (192.168.2.15)
a 8.
está en realidad representada de forma
que sea fácilmente comprensible para un
humano (con cada cifra expresada en el Quizá esto os suene a una especie de
clásico formato decimal). ¿Cuál es locura propia de un friki que sólo sale de
entonces el auténtico aspecto de una su casa para comprar más memoria RAM
dirección IP? Pues es, por supuesto, o más cafeína, pero en realidad aprenderse
una fantástica ristra de ceros y unos, de estos números es mucho más fácil de lo
esas que aparecen en las pelis de que parece, ya que estos números nos
hackers. rodean a diario sin que nos demos cuenta.
Las 9 primeras potencias de 2 son estas:
Veamos por ejemplo el auténtico aspecto
de la dirección del ejemplo: 20 = 1
21 = 2
11000000 . 10101000 . 00000010 . 00001111 22 = 4
23 = 8
Como vemos, cada cifra en base 256
24 = 16
está formada de 8 cifras binarias (cero
25 = 32
o uno), por lo que una dirección IP
26 = 64
consta de un total de 32 cifras
27 = 128
binarias (bits).
28 = 256

¿A que os suenan todos esos números? Para el caso de 168 hacemos lo mismo:
Los veréis cada vez que veáis cualquier 168 está entre 128, y 256, por lo que
cosa relacionada con la informática (la marcamos la cifra 7; 168 128 = 40,
velocidad del ADSL, la capacidad de las que está entre 32 y 64, por lo que
tarjetas de memoria, etc, etc). marcamos la cifra 5, correspondiente al
32; 40 32 = 8 que está entre 8 y 16,
Lo que yo hago para convertir un byte por lo que marcamos la cifra 3,
en su formato decimal al formato binario
correspondiente al 8, y tenemos ya el
es: (mientras lees los pasos fíjate en la
número completo, pues 8 8 = 0. Nos
imagen)
queda 10101000
PUNTO 1.- En primer lugar, miramos

entre qué dos potencias de 2 está Para el número 2: 2 está entre 2 y 4,
comprendido. Por ejemplo, para el por lo que directamente marcamos la
caso del número 192, está cifra 1, correspondiente a 21, y 2 2 =
comprendido entre 128 y 256. Por 0, por lo que ya tenemos el número, que
tanto, la cifra binaria correspondiente será una ristra de 7 ceros y un solo uno,
a 128 (27) tiene que estar a uno. en la segunda posición empezando por
la derecha. Nos queda 00000010
PUNTO 2.- Para ver qué más cifras
están a uno, cojo el 192 y le resto Para el número 15: vemos que está entre
128, y nos da como resultado 64. 8 y 16, por lo que marcamos la cifra 3;
a continuación hacemos 15 8 = 7, que
PUNTO 3.- Repetimos el proceso del
está entre 4 y 8, por lo que marcamos la
punto 1 con este nuevo número, el
cifra 2, correspondiente al 4; a
64: miramos entre qué dos potencias
continuación hacemos 7 4 = 3, que
está comprendido el 64 y vemos que
está entre 64 y 128. Por tanto la cifra está entre 2 y 4, por lo que marcamos la
26, correspondiente al 64, tendrá que cifra 1; por último, hacemos 3 2 = 1,
estar también a uno. que está entre 1 y 2, por lo que marcamos
la cifra 0, y tenemos ya el número
PUNTO 4.- Igual que en el PUNTO 2: c o m p l e t o, q u e s e r á 0 0 0 0 1 1 1 1 .
ahora 64 64 = 0, significa que
tenemos ya el número exacto, y no Por lo tanto la IP en binario es:
hay que continuar el proceso. 11000000 . 10101000 . 00000010 . 00001111
Por tanto, como hemos visto que hay

3. LAS DIRECCIONES DE RED
que marcar a uno las cifras 7 y 6,
contando 8 cifras empezando por la
derecha, y En muchos casos la dirección IP por si
siendo la sola no es suficiente para todas las
primera la necesidades de una comunicación TCP/IP.
cifra 0, Para entenderlo haremos el paralelismo
obtenemos la con algo que todos conocemos: un número
imágen: de teléfono.

Un número de teléfono consta de uno o Actualmente, esto de los prefijos es ya

varios prefijos, seguido del número ya transparente al usuario del teléfono
propiamente dicho. La red telefónica (siempre que llamamos a alguien
utiliza estos prefijos para saber cómo marcamos prefijo y número, todo junto).
dirigir el tráfico de la red entre las distintas ---los prefijos de las direcciones IP
zonas. también son transparentes para los
usuarios de Internet---
Podríamos también hacer el paralelismo
con el correo postal. El correo postal En cambio, las máquinas de la red
consta de un código postal (que podría telefónica encargadas de conmutar los
ser considerado como un prefijo), y el circuitos para comunicar a los dos
resto de la dirección. abonados en una llamada sí que necesitan
diferenciar los prefijos, para así saber por
dónde ir dirigiendo la llamada para crear
Como en los dos casos anteriores,
un enlace entre los dos puntos. Del mismo
también las direcciones IP tienen en cierto
modo, las máquinas encargadas de
modo prefijos que permiten diferenciar
direccionar el tráfico en una red TCP/IP
diferentes zonas entre los diferentes (como Internet) necesitan conocer los
usuarios de la red. prefijos de las direcciones IP para
conseguir establecer un camino entre las
En el caso del correo postal, la parte de dos máquinas que quieren comunicarse.
prefijo que permite separar las zonas Estas máquinas encargadas de direccionar
está claramente diferenciado del resto el tráfico TCP/IP suelen ser los
de la dirección (no hay forma de confundir denominados gateways o, por usar un
el código postal con el nombre de la término más familiar, los routers.
calle).
Por tanto, para conectar mediante TCP/IP
En cambio, en el caso del teléfono ya es con una máquina, no nos basta con saber
otro asunto. Por ejemplo, el prefijo para su dirección IP, si no que también tenemos
Madrid es el 91, mientras que el prefijo que conocer qué porción de ésta IP es
para Murcia es el 968, por lo que a priori prefijo, y cuál no. Al igual que en los
no hay forma de saber hasta dónde llega números de teléfono, los prefijos de las
el prefijo, ya que unos tienen 2 cifras, y direcciones IP son de longitud variable,
por lo que es imposible saber a priori qué
otros tienen 3.
parte de la IP es prefijo, y qué parte es
la dirección propiamente dicha de nuestra
Hasta hace unos años, el prefijo no se
máquina. Esto da lugar a la necesidad de
marcaba cuando se estaba dentro de una
que una dirección IP tenga que ir
misma provincia. Por tanto, si te decían:
acompañada de otro número que indique
vivo en Madrid y mi teléfono es el
simplemente cuál es la longitud del prefijo
915758976, no sabías si, estando en
dentro de esa IP.
Madrid, tenías que marcar 5758976, o
758976, a no ser que supieses que el En el caso de los números de teléfono
prefijo de Madrid es el 91, por lo que podríamos representar esto de la siguiente
sólo habría que prescindir de las dos forma: 915758976 / 2. La última cifra,
primeras cifras. detrás de la barra / nos indicaría la

longitud del prefijo. Por tanto, sabemos Hemos visto una forma de representar la
que este número sería 5758976, y las longitud del prefijo de la dirección
dos primeras cifras, el 91, serían el IP, que consiste en acompañar a la
prefijo. dirección de una barra separadora y un
número que representa el número de bits
Esta misma representación se utiliza con que ocupa este prefijo. Esta forma se
las direcciones IP, pero contando el suele utilizar bastante, pero también se
número de cifras binarias (bits). Por utiliza otra representación, quizá más
ejemplo, la IP 192.168.2.15 / 24, conocida, que veremos ahora mismo.
estaría compuesta por un prefijo de 24
bits (24 cifras binarias), y el resto sería En cualquier caso, se use la representación
la dirección IP de la máquina, es decir, que se use, a este número que especifica
ésta constaría de 8 bits (ya que el total el tamaño del prefijo se le llama
de bits en una dirección IP hemos dicho máscara de red. Y esto que hasta ahora
que es 32). hemos estado llamando prefijo es lo que
en realidad se denomina dirección de
Viendo la IP en su formato binario: red. Fíjate en la imagen para que no te
pierdas y a partir de ahora, mientras lees,
11000000 . 10101000 . 00000010 . 00001111 consulta continuamente la imagen.
Sabemos ya que las primeras 24 cifras:

11000000 10101000 00000010,
componen el prefijo (llamado dirección
de red, como veremos más adelante).
Sabemos también que las últimas 8:

00001111 componen la dirección de
la máquina (llamada dirección de host)
dentro de la zona marcada por el prefijo.
! Todo esto de...

** Como una dirección de red se obtiene
combinando la dirección IP y la máscara de red,
en muchos textos encontrareis que se llama
Todo esto de las zonas y los prefijos tiene relación con lo que
dirección de red al conjunto de estos dos
expliqué sobre cómo InterNIC asigna las direcciones IP.
números: la dirección IP + la máscara de red
(192.168.2.15 /24).
La parte de prefijo sería aquella que asigna éste organismo a cada
organización (Telefónica, gobierno de los Estados Unidos,
Lo que hasta ahora hemos estado
Universidad Politécnica de Madrid, Microsoft, ...), y el resto de la
llamando zona es lo que en realidad
dirección IP sería el rango de direcciones en las que tiene libertad
deberíamos llamar red. Cada red tiene
la organización para asignarlas como quiera a sus usuarios.
una dirección de red al igual que cada
Por tanto el prefijo determinará la organización a la que está asignada calle de tu ciudad tiene un nombre.
esa IP, y el resto de la dirección determinará a una máquina concreta
dentro de esa organización. Por tanto, Internet está dividida en varias
redes (zonas), cada una de las cuales

tiene asociada una dirección de red (un Quizá os preguntéis ahora por qué es tan
prefijo), cuya longitud viene determinada habitual escribir las máscaras de red en
por la máscara de red. este formato binario, que es menos
intuitivo que el anterior. El motivo es que
Antes dijimos que había otra forma (quizá la máscara de red sirve para realizar
más conocida) de representar la máscara
determinadas operaciones de aritmética
de red. Vamos a ver ahora cuál es esa
binaria que han de ser realizadas viendo
otra forma y, para el que piense que
la máscara de red en su formato binario.
con aprenderse una es suficiente, ya
Y qué operaciones son esas y para qué
puede ir cambiando de opinión las dos
son ampliamente utilizadas en libros sirven? Eso es precisamente lo que
técnicos, textos, etc. veremos en el próximo punto.
Lo que en realidad nos está diciendo la 4. EL ENCAMINAMIENTO EN

máscara de red es qué bits de nuestra REDES TCP/IP
dirección IP pertenecen a la red (o
zona), y qué bits pertenecen a la
Vamos a descubrir al fin cómo se puede
máquina concreta dentro de esa red.
encontrar el camino entre dos de las
Po r t a n t o, l a d i r e c c i ó n d e r e d
millones de máquinas conectadas
192.168.2.15/24 podríamos
caóticamente a Internet.
representarla también así:
Comprenderemos así la necesidad de la
Dirección IP = 11000000 . 10101000 . 00000010 . 00001111 existencia de las máscaras de red, y la
Máscara de red = 11111111 . 11111111 . 11111111 . 00000000
utilidad de su representación binaria.
Para representar en binario la Máscara
de Red (/24) lo que hacemos es poner Para ello, vamos a ver un ejemplo de
tantos unos como nos indica la notación cómo se establecen diversas conexiones
(/24) y el resto lo completamos con ceros. desde un PC de una empresa. El ejemplo
Los bits que estén a 1 en la máscara que te presento ha sido intencionadamente
de red son los bits que pertenecen muy muy simplificado, pero nos servirá
al prefijo. perfectamente para lo que deseamos
explicar.
Si convertimos esta máscara de red de
binario a la clásica representación decimal
En nuestro ejemplo tenemos una red
que utilizamos para las direcciones IP,
corporativa compuesta de dos subredes:
nos quedaría la siguiente dirección de
red (como ya sabemos, 11111111 en una zona interna, donde están los
binario corresponde a 255 en decimal y PCs de cada empleado
00000000 en binario corresponde a 0 en una zona DMZ donde se encuentra
decimal): el servidor web de la compañía (se
sale del tema hablar sobre lo que es
Dirección IP = 192.168.2.15 una DMZ, y realmente no necesitáis
Máscara de red = 255.255.255.0 saberlo para este ejemplo, pero al final
del artículo aclararé por encima estos
Estoy seguro de que esto ya os suena
conceptos).
bastante más.

Dos oficinas: El ordenador de la oficina de Barcelona

una en Madrid: esta es la oficina tiene como dirección de red
principal, en la que estamos 172.16.1.23/12.
nosotros, y está conectada a
Internet a través de un modem Ésta es la configuración TCP/IP de nuestro
ADSL ordenador en Madrid:
otra en Barcelona (una sucursal) Dirección IP: 192.168.2.5
Las oficinas están unidas entre si Máscara de red: 255.255.255.0
mediante una red directa. Lo hemos Puerta de enlace predeterminada:
hecho así para simplificar el ejemplo 192.168.2.1
Ya sabemos lo que significan los dos

primeros parámetros (Dirección IP y
Máscara de Red).
El último parámetro (Puerta de Enlace
Predeterminada) quiere decir que todo
paquete que no sepamos encaminar
lo tendremos que enviar a esa dirección
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 Una vez en el router central, éste tendrá
queremos enviar un correo electrónico que decidir qué hacer con el paquete.
directamente desde la oficina de Madrid Para ello tiene que mirar en las tablas
a una máquina de la oficina de que tiene configuradas, que son las
Barcelona. siguientes:
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
dirección de red 192.168.2.5/24 (fíjate Veamos el significado de esta interesante
en la imagen). tabla. Gracias a esta tabla, el router sabe:
El router central, que intercomunica que cualquier paquete que coincida

todas las redes de la empresa, tiene con la dirección de red
como dirección de red 192.168.2.1/24 192.168.1.0/24 tiene que ser dirigido
dentro de la red interna (fíjate en la al interfaz eth0
imagen).

que cualquier paquete que coincida imagen siguiente mientras lees las
con la dirección de red siguientes líneas):
172.16.0.0/12 debe ser dirigido al El router tendrá la dirección IP
interfaz eth1 192.168.1.1 en el interfaz eth0. Esta
que cualquier paquete que coincida es la red donde tenemos la DMZ.
con la dirección de red El router tendrá la dirección IP
192.168.2.0/24 se enviará al interfaz 172.16.0.2 en el interfaz eth1. Esta
eth2 es la red donde tenemos el ordenador
y, por último, que cualquier paquete de Barcelona.
que no coincida con ninguna de las El router tendrá la dirección IP
anteriores direcciones de red, tendrá 192.168.2.1 en el interfaz eth2. Esta
que coincidir por narices con la es la red donde tenemos nuestro PC
dirección de red 0.0.0.0/0, por lo (Red Interna).
que irá al interfaz ppp0.
De esta forma, se podrá acceder al router
Por tanto, el interfaz ppp0 será para el central desde las tres redes de la
router central el equivalente a la puerta organización (la red interna, la red DMZ,
de enlace predeterminada, donde van y la red de la oficina de Barcelona), ya
todos los paquetes que no se sabe cómo que tendrá una IP diferente para cada
encaminar. Normalmente, estos paquetes una de estas redes.
serán los que vayan a Internet y, de
hecho, el interfaz ppp0 estará conectado Esta es una de las bases para comprender
a un modem que conectará con Internet. el trabajo de un router. Un router es como
una araña que tiene una pata en cada
¿No os suena eso de los interfaces eth0, red que desea enrutar. Un router nunca
eth1, etc? Para que os hagáis una idea, podrá enrutar (dirigir) una red a la que
serían como diferentes tarjetas de red: no pertenezca.
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 según su destino.
El interfaz ppp0 es otro tipo de interfaz
que no corresponde a una tarjeta de Y ahora viene lo realmente
red, si no a una conexión PPP. Para interesante:
no liaros, basta con que os quedéis con Nosotros estamos intentando enviar
la idea de que el interfaz PPP es una un paquete desde nuestro PC con la
interfaz con un modem. IP 192.168.2.5 al un PC de la oficina
de Barcelona con la IP 172.16.1.23
Como cada tarjeta de red tiene una El router solo sabe la IP de origen
dirección IP asociada, el router tendrá (192.168.2.5) y la IP de destino
por tanto 3 direcciones IP diferentes, (172.16.1.23). ¿Cómo sabe el router
una por cada interfaz eth (mira la a partir de la dirección IP del

paquete a qué cable debe Para comprenderlo mejor,

enviarlo? Es aquí donde llega la compararemos esta operación con
importancia de las direcciones de otra operación lógica, que es la
red. operación OR (traducido, la operación
o). En este caso la pregunta es ¿está
Para comprenderlo tenemos que conocer a uno A O B? Esta sería la tabla resultante:
un poquitín de la aritmética binaria más
básica. Simplemente tenemos que
comprender el funcionamiento del
operador lógico AND.
Igual que en la aritmética decimal de La operación que nos interesa ahora es

toda la vida existen una serie de la operación AND, es la que permitirá a
operaciones como son la suma, la resta, nuestro router comparar cada dirección
la multiplicación, etc; en aritmética binaria de red con la dirección IP de destino de
existen, además de estas operaciones, nuestro paquete.
otro grupo de operaciones llamadas
operaciones lógicas. Recordamos que la IP de destino del
paquete era 172.16.1.23. En este caso
Las operaciones lógicas permiten operar el router no sabe la máscara de red, ya
sobre cifras binarias haciendo preguntas que en un paquete IP sólo se envía la
sobre ellas. Una respuesta SI se dirección IP, pero no la máscara de red.
consideraría un 1, y una respuesta NO
se consideraría un 0. Por tanto, tenemos tan sólo una dirección,
pero no sabemos cuál es la longitud de
Una de las operaciones lógicas más su prefijo. Al no conocer la longitud de
básicas es la operación AND (traducido este prefijo, es decir, la dirección de
literalmente, la operación y). red, no sabremos a priori a qué red
pertenece esta dirección IP.
Por ejemplo, si tenemos dos variables
binarias, A y B, donde cada una de ellas La única información de la que dispone
puede valer cero o uno, podemos el router central es la tabla que vimos
preguntar: ¿están a uno A Y B? Si la anteriormente, por lo que el router tendrá
respuesta es SI, el resultado será un 1. que comparar esta información con la
Si la respuesta es NO, el resultado será dirección IP del paquete. La comparación
un 0. Esto nos da lugar a la siguiente que hace es sencilla:
tabla: realiza una operación AND entre la
IP del paquete y cada una de las
máscaras de red que tenga en su
tabla
si el resultado después de la operación
AND es alguna de las direcciones de
red que hay en la tabla, entonces el
Por tanto, la operación AND nos paquete será dirigido al cable
devolverá 1 sólo cuando ambas correspondiente a esa dirección de red
variables valgan 1.

en caso de que ninguna dirección Vamos ahora con la segunda máscara de

de red coincida con la del paquete, red:
éste se enviará a la puerta de enlace
predeterminada, en el interfaz ppp0. 10101100 . 00010000 . 00000001 . 00010111
Veamos esto paso por paso. AND
En primer lugar, pasemos a binario la IP 11111111 . 11110000 . 00000000 . 00000000

del paquete, 172.16.1.23:
10101100 . 00010000 . 00000000 . 00000000 = 172.16.0.0
10101100 . 00010000 . 00000001 . 00010111
Tenemos que comprobar ahora que el

Y también las direcciones de red de la
resultado (172.16.0.0) coincida con la
tabla del router:
segunda dirección de red, que es
192.168.1.0 = 11000000 . 10101000 . 00000001 . 00000000
172.16.0.0. En este caso sí que coincide,
Máscara = 11111111 . 11111111 . 11111111 . 00000000
por lo que el router ha encontrado ya la
172.16.0.0 = 10101100 . 00010000 . 00000000 . 00000000 red a la que ha de enviar el paquete.
Máscara = 11111111 . 11110000 . 00000000 . 00000000 Consulta entonces su tabla y ve que ese
paquete ha de ser enviado al interfaz
192.168.2.0 = 11000000 . 10101000 . 00000010 . 00000000 eth1. Por tanto, ubicará físicamente el
Máscara = 11111111 . 11111111 . 11111111 . 00000000
paquete por el cable conectado a la tarjeta
de red eth1, y podrá llegar así hasta la
0.0.0.0 = 00000000 . 00000000 . 00000000 . 00000000
Máscara = 00000000 . 00000000 . 00000000 . 00000000 red de la oficina de Barcelona, donde
probablemente otro router se encargue
Empezamos realizando la operación AND
de terminar de encaminar el paquete ya
entre la IP del paquete y la primera de
dentro de esa red.
las máscaras:
Si ahora queremos enviar otro paquete

10101100 . 00010000 . 00000001 . 00010111 cuyo destino sea la IP 217.155.1.13,
que es una IP de Internet, nuestro router
AND
comparará de nuevo las direcciones de
11111111 . 11111111 . 11111111 . 00000000
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
10101100 . 00010000 . 00000001 . 00000000 = 172.16.1.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
Tenemos que comprobar ahora si Por tanto, este paquete será enviado al
172.16.1.0 es igual a 192.168.1.0, que interfaz PPP0, que es el que nos conecta
es la dirección de red correspondiente con Internet a través del modem.
a la primera de las máscaras, con la que
acabamos de realizar el AND. Por Como vemos, es fácil realizar la operación
AND en formato decimal cuando la
supuesto, no son iguales, por lo que el
máscara de red divide la dirección en
paquete no pertenece a esta primera
bytes (es decir, la máscara sólo tiene 255
red.
o 0). En este caso, bastará con poner a

0 aquellos bytes de la IP en los que bits se utilizan para diferenciar la red, y

haya un 0 en la máscara de red los otros 24 bits se utilizan para identificar
(217.155.1.13 AND 255.255.255.0 = a una máquina concreta dentro de la red.
217.155.1.0). En cambio, para otro tipo
de máscaras, ya es necesario operar en Además, el primer bit de una dirección
binario (217.155.1.13 AND 255.240.0.0 de red de clase A tiene que ser 0, por lo
= 217.144.0.0). que en realidad sólo nos quedan 7 bits
para identificar unívocamente una red de
Como este último ejemplo no se ve de clase A.
forma clara en formato decimal, lo
muestro aquí en su formato binario: Teniendo en cuenta que hay además
algunas direcciones reservadas, esto da
11011001 . 10011011 . 00000001 . 00001101 lugar a que sólo existen 124 redes de
clase A en Internet. Estas son las que
AND
tienen desde la dirección 1.*.*.* hasta
la dirección 126.*.*.*
11111111 . 11110000 . 00000000 . 00000000
Si bien son pocas las diferentes redes de

11011001 . 10010000 . 00000000 . 00000000 = 217.144.0.0
clase A que se pueden direccionar con
sólo 7 bits, en cambio, son muchísimas
las máquinas que se pueden direccionar
5. CLASES DE REDES dentro de esa red, ya que serían 224,
que son casi 17 millones de máquinas.
Existen tres tipos básicos de redes en
función de la dirección 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 sólo existen 124 direcciones para redes
de este tipo. 5.2. CLASE B
En cambio, una red de clase C se utiliza Las redes de clase B tienen una máscara
en pequeñas organizaciones, y existen de red /16 (255.255.0.0), es decir, la
más de 2 millones de direcciones de clase mitad de la dirección de red especifica la
C. red, y la otra mitad la máquina dentro de
la red.
Pero vamos a ver en detalle en qué
consiste cada una de las clases de redes. Los dos primeros bits de la dirección
de red han de ser 10, por lo que al final
5.1. CLASE A nos quedan sólo 14 bits para identificar
la red. Esto da lugar a que haya 16382
Las redes de clase A son aquellas que direcciones de red de clase B diferentes,
tienen una máscara de red /8 que abarcan desde la 128.1.*.* hasta la
(255.0.0.0), es decir, sólo los 8 primeros 191.254.*.*

Cada red de clase B puede direccionar Dentro de las diferentes redes destacan
65534 máquinas diferentes, por lo que las llamadas clase D y clase E, muy poco
estas redes siguen siendo utilizadas tan utilizadas:
sólo por grandes organizaciones. 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
! No debemos...
Las redes de clase C tienen una máscara
de red /24 (255.255.255.0), por lo No debemos asustarnos si encontramos direcciones de red
que sólo los últimos 8 bits de la dirección con máscaras de red como esta: 255.255.255.128. Las
permiten especificar una máquina dentro máscaras de red no siempre están construidas con 255 o 0,
de la red. es decir, las direcciones de red no constan siempre de un
número entero de bytes. Por ejemplo, la máscara de red
Los 3 primeros bits de una dirección 255.255.255.128 sería en binario:
de clase C tienen que ser 110, por lo
que al final nos quedan sólo 21 bits 11111111 . 11111111 . 11111111 . 10000000
para direccionar la red, lo cual da lugar
a que haya más de 2 millones de redes Con este número en binario ya podemos operar con la
de clase C diferentes. operación lógica AND exactamente igual a como lo
hacíamos con las máscaras más "clásicas". Ya vimos un
Dentro de cada red de clase C se pueden ejemplo de este tipo de máscaras en el punto anterior
direccionar 254 máquinas diferentes, por (255.240.0.0).
lo que estas redes ya no son válidas para
grandes organizaciones.
5.5. DIRECCIONES DE RED
RESERVADAS
Las redes de clase C abarcan desde la
192.0.1.* hasta la 223.255.254.*.
Hay algunas direcciones de red reservadas
para ciertos fines, y que no pueden ser
asignadas a ninguna máquina de Internet.
La más conocida es el famoso localhost:

127.0.0.1.
Esta dirección siempre se refiere a tu
propia máquina (tu PC), por lo que
cualquier acceso que hagas a esa IP serán
5.4. OTRAS CLASES DE REDES 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.
Aparte de las 3 clases básicas, pueden

La dirección de red 10.0.0.0/8 (es decir,
existir redes con diferentes máscaras que
todas las IPs entre 10.0.0.0 y
no se ajusten necesariamente a una de
10.255.255.255) están reservadas para
estas 3 clases.

redes de área local de gran tamaño, mes), y acompañar el curso de TCP/IP

ya que permiten direccionar 2 24 de un nuevo número de la serie RAW en
máquinas. el que explique algunos protocolos de
encaminamiento, como RIP u OSPF.
También para redes de área local se
usan las direcciones 172.16.0.0/12 (es Lo que queda por aclarar entonces es el
decir, desde la IP 172.16.0.0 hasta la funcionamiento básico de una red local.
172.31.255.255), y las 192.168.0.0/16
(desde la IP 192.168.0.0 hasta la Una red local es una red independiente
192.168.255.255). Estos rangos de IPs de Internet que, en el caso de que esté
son los que podemos utilizar nosotros conectada a Internet, lo hará
cuando montamos una red en nuestra (normalmente) únicamente a través de
casa o en la oficina. un sólo punto. Por muchos ordenadores
que haya conectados dentro de la red
Por tanto, cualquiera en su casa es libre local, todos se conectarán con el exterior
de hacer lo que quiera con esos rangos (Internet) mediante un único punto.
de IPs, ya que tienen garantizado que
no existe en Internet ninguna máquina Al conectar con el exterior a través de
con esas direcciones. En el próximo punto un sólo punto, se consigue que el tamaño
veremos con más detalle (aunque y la configuración de la red local sea
tampoco demasiado, pues no es transparente para los usuarios del exterior,
realmente el tema del artículo) el es decir, para Internet. Si alguien desde
funcionamiento de una red local. la china intentase ver nuestra Red
Interna compuesta por 600 ordenadores
Existen otras direcciones reservadas para (o 2 o 3000, los que sean), únicamente
otros fines, como las 128.0.*.*, vería una IP PÚBLICA, es decir, un único
191.255.*.*, 223.255.255.*, etc. punto de acceso. Esta IP seguramente
correspondería a la del modem que da
6. FUNCIONAMIENTO acceso a Internet a todos nuestros
ordenadores.
BÁSICO DE UNA RED LOCAL
Esto es lo que permite que una empresa,
Para terminar, vamos a intentar aclarar
una universidad, o cualquier otra
algunos conceptos que he utilizado a lo
organización, pueda tener un gran número
largo del artículo, concretamente en el
de ordenadores, sin que cada uno de ellos
punto 4, en el que he hablado del
tenga que tener su propia dirección IP
encaminamiento.
dentro de Internet, lo cual saturaría
inútilmente el rango de direcciones IP
En primer lugar, tengo que dejar claro
disponibles para Internet.
que el tema del encaminamiento es
mucho más complicado de lo que he
Por supuesto, una red local no da ventajas
mostrado aquí, pero explicarlo en detalle
sólo de cara al exterior, para evitar la
se salía por completo del tema del artículo.
saturación de las direcciones de Internet,
si no también de cara al interior, para
Espero disponer de un poco más de
independizar la red de la empresa de la
tiempo en breve (quizá para el próximo
red Internet.

El tener una red independiente tiene llamada comunmente zona

muchas ventajas de seguridad, de desmilitarizada, o DMZ, en la cual se
velocidad, etc. Una red local típica, como alojarán todos los servidores, y aquellas
la que podrías tener tú en tu casa por máquinas que no hayan de estar bajo la
muy poco dinero, tiene una velocidad de protección de la zona interna.
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 conexión entre los
ordenadores de nuestra casa, empresa,
u organización de cualquier tipo, sin
depender de la velocidad de acceso o
incluso de la saturación del tráfico de
Internet.
Por otro lado, las ventajas con respecto

a la seguridad son evidentes, ya que el
tráfico 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 configuración local dividida en dos
redes. Una de ellas, comunmente llamada
zona interna, será la que utilicen los Al ser independiente de Internet, en una
usuarios comunes (por ejemplo, los red local se pueden utilizar direcciones
empleados de una empresa), y tendrá IP libremente, siempre y cuando sean
un acceso a Internet totalmente limitado. direcciones reservadas que no existan en
Internet. Ya mencioné antes cuales son
Esto hace que sea muy difícil que un las direcciones IP reservadas para redes
hacker realice cualquier tipo de ataque locales.
o espionaje contra los ordenadores de
los empleados (al mismo tiempo, también Una gran ventaja de esto es que facilita
permite limitar el acceso a los empleados, mucho la configuración de los ordenadores
para que no pasen el tiempo chateando conectados a la red local, ya que existen
o viendo fotos guarrillas). protocolos, de los cuales el más famoso
es el DHCP (Dynamic Host Configuration
Por supuesto, la empresa no puede Protocol), que permiten configurar
funcionar sólo con una conexión tan automáticamente cualquier nuevo
restringida como ésta, ya que necesitará ordenador que se conecte a la red local.
tener una serie de servidores (servidor Cada vez que se conecta una máquina,
web, servidor de correo, etc) que tengan ésta pide al servidor DHCP los datos de
un acceso mucho más abierto hacia su configuración (como su dirección IP),
Internet. Por eso se crea otra zona, y queda así automáticamente configurado.

Esto puede dar lugar a la existencia de Para simplificar, dije que una dirección
IPs dinámicas, que ya mencioné al broadcast se formaba poniendo un 255
principio del artículo. Según una serie de en el último byte de la IP, pero esto no
criterios, el servidor DHCP podrá decidir es del todo cierto, ya que éste es sólo el
en un momento dado asignar a una caso más común.
máquina una dirección IP diferente a la
que le asignó la última vez que esta Para comprender la formación de la
máquina se conectó. dirección broadcast tenemos que volver
al tema de los operadores lógicos binarios,
En una red local no sólo será necesario por lo que voy a introducir un nuevo
un protocolo que facilite la configuración operador, el más simple de todos, que es
automática de cada equipo, si no que el operador NOT.
hará falta también otro protocolo que
permita a los diferentes equipos de la El operador NOT lo único que hace es
red conocerse entre sí, es decir, saber invertir todos los bits del número
qué dirección IP tiene no sólo él mismo, binario, es decir, cambiar todos los ceros
si no también sus compañeros a los que por unos, y todos los unos por ceros.
quiera acceder. Así:
NOT 1001110101 = 0110001010
El protocolo más conocido para este fin
es el ARP (Address Resolution Protocol), El primer paso para obtener la dirección
que permite asociar direcciones IP con broadcast de una red, será aplicar el
direcciones MAC, tal y como veremos operador NOT sobre la máscara de red.
en el curso más adelante, cuando E s d e c i r, s i t e n e m o s l a r e d
hablemos del nivel de enlace. 172.16.0.0/12, ésta será la máscara de
red en formato binario:
Por último, sólo me queda mencionar el
funcionamiento de las direcciones
11111111 . 11110000 . 00000000 . 00000000
broadcast, de las cuales ya hablé un
poco a lo largo del curso de TCP/IP.
Y ésta será la máscara despues de aplicar
el operador NOT:
Por si no lo recordáis, una dirección
broadcast es una dirección IP especial 00000000 . 00001111 . 11111111 . 11111111
que se refiere no a una sola máquina, si
no a todas las máquinas de una Teniendo ya esta máscara invertida, sólo
misma red. tenemos que aplicar un operador OR
entre la máscara invertida y la
Si, por ejemplo, enviamos un ping a una
dirección de red. Os recuerdo aquí cual
dirección IP, recibiremos respuesta
era el funcionamiento del operador OR:
únicamente de una máquina. En cambio,
si esa dirección IP es la dirección
broadcast de la red, todas las máquinas
que estén conectadas a la red en ese
momento responderán a nuestro ping Por tanto, si la dirección de red en nuestro
(con los consiguientes problemas de ejemplo es:
seguridad de los que ya hablé en artículos
172.16.0.0 = 10101100 . 00010000 . 00000000 . 00000000
anteriores).

Realizamos la operación:
10101100 . 00010000 . 00000000 . 00000000
OR textos y cursos para consumo propio o de unos pocos.
00000000 . 00001111 . 11111111 . 11111111

10101100 . 00011111 . 11111111 . 11111111 = 172.31.255.255 nunca se han atrevido a presentar sus trabajos a una editorial.
Por tanto, la dirección broadcast para la SABEMOS que hay verdaderas obras de arte creadas por personas
red 172.16.0.0/12 será 172.31.255.255. como tu o yo y que nunca verán la luz.
En el próximo número, continuaremos

con la capa IP de la pila TCP/IP, pero esta
vez entrando de lleno en el formato de NOSOTROS PODEMOS PUBLICAR TU OBRA!!!
las cabeceras IP, por lo que nos esperará
un artículo denso y, espero que bastante
interesante.
Autor: PyC (LCo).
SUSCRIBETE A
PC PASO A PASO
45 EUROS (10% DE DESCUENTO)
SUSCRIPCIÓN POR: +
1 AÑO = SORTEO DE UNA CONSOLA XBOX
+
11 NUMEROS SORTEO 2 JUEGOS PC (A ELEGIR)
Contra R e e m b o l s o Giro Post al
Solo tienes que enviarnos un mail a preferente@hackxcrack.com Envíanos un GIRO POSTAL por valor de 45 EUROS a:
indicando: CALLE PERE MARTELL20, 2º 1ª.
- Nombre CP 43001 TARRAGONA
- Apellidos ESPAÑA
- Dirección Completa IMPORTANTE: En el TEXTO DEL GIRO escribe un mail de contacto
- Población o un número de Teléfono.
- Provincia
- Cógigo Postal Y enviarnos un mail a preferente@hackxcrack.com indicando:
- Mail de Contacto y/o Teléfono Contacto - Nombre
Es imprescindible que nos facilites un mail o teléfono de contacto. - Apellidos
- Tipo de Subscripción: CONTRAREEMBOLSO - Dirección Completa
- Número de Revista: - Población
Este será el número a partir del cual quieres subscribirte. Si deseas - Provincia
(por ejemplo) subscribirte a partir del número 5 (incluido), debes poner - Cógigo Postal
un 5 y te enviaremos desde el 5 hasta el 15 (ambos incluidos) - Mail de Contacto y/o Teléfono Contacto
Es imprescindible que nos facilites un mail o teléfono de contacto.
APRECIACIONES: - Tipo de Subscripción: GIRO POSTAL
* Junto con el primer número recibirás el abono de 45 euros, precio - Número de Revista:
de la subscripción por 11 números (un año) y una carta donde se te Este será el número a partir del cual quieres subscribirte. Si deseas
indicará tu número de Cliente Preferente y justificante/factura de la (por ejemplo) subscribirte a partir del número 5 (incluido), debes poner
subscripción. un 5 y te enviaremos desde el 5 hasta el 15 (ambos incluidos)
* Puedes hacernos llegar estos datos POR MAIL,tal como te hemos
indicado; rellenando el formulario de nuestra WEB APRECIACIONES:
(www.hackxcrack.com) o enviándonos una carta a la siguiente dirección: * Junto con el primer número recibirás una carta donde se te indicará
CALLE PERE MARTELL Nº20, 2º-1ª tu número de Cliente Preferente y justificante/factura de la subscripción.
CP 43001 TARRAGONA * Puedes hacernos llegar estos datos POR MAIL,tal como te hemos
ESPAÑA indicado; o enviándonos una carta a la siguiente dirección:
* Cualquier consulta referente a las subscripciones puedes enviarla CALLE PERE MARTELL Nº20, 2º-1ª
por mail a preferente@hackxcrack.com CP 43001 TARRAGONA
ESPAÑA
* 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 (fragmentación, etc).
INTRODUCCIÓN de ningún RFC. En lugar de eso, lo que

voy a hacer es seguir, como siempre,
explicando las cosas a mi manera, pero
A estas alturas ya tenemos que
en este caso lo haré siguiendo la estructura
comprender bastante bien cómo circulan
de un RFC, en este caso del RFC 791
los paquetes a través de Internet, o
( f t p : / / f t p . r f c - e d i t o r. o r g / i n -
cualquier otra red TCP/IP. Conocemos ya
notes/rfc791.txt), que es el que especifica
los mecanismos de transporte (protocolos
el protocolo IP.
TCP y UDP), los mecanismos de control
de errores (ICMP), y sabemos algo sobre Y, ¿acaso no han seguido algún RFC el
el encaminamiento (tablas de resto de mis artículos? Pues realmente
encaminamiento de los routers, no, ya que la estructura de los RFC (es
direcciones y máscaras de red, etc). decir, el orden en el que cuentan las
cosas), en mi opinión, no suele ser
Durante muchos meses he ido explicando a d e c u a d a p a ra q u e a l g u i e n s i n
a mi manera un gran número de conocimientos sobre el tema comprenda
documentos RFC (no sólo en el curso lo que se está explicando. Hasta ahora,
de TCP/IP, si no también en la serie cada vez que escribía un artículo, dedicaba
RAW), intentando así abriros una puerta casi la mayor parte del tiempo
fácil a unos documentos excesivamente simplemente a estructurar las ideas y
técnicos que de otra manera hacer un esqueleto del orden en que
probablemente os habría costado bastante las iba a contar.
comprender.
Posiblemente no notéis mucha diferencia
Llegados a este punto, después de más entre este artículo y el resto y,
de un año siguiendo esta línea, creo que sinceramente, espero que así sea, porque
ha llegado el momento de hacer una eso significaría que ya prácticamente
pequeña prueba para que comprobéis estáis preparados para enfrentaros solitos
vosotros mismos si estáis preparados a la jungla de los RFCs. El próximo paso
para enfrentaros directamente con los sería que cogieseis directamente un RFC,
RFC y prescindir de mis servicios. pero ese es un paso que daréis vosotros
mismos, pues yo no os voy a plantar en
Por supuesto, no voy a plantaros aquí un el próximo número un RFC, entre otras
RFC tal cual, entre otras cosas porque cosas porque no os voy a hacer pagar
probablemente tendría que ser en inglés, 45 euros por algo que podéis descargar
y tampoco pretendo hacer una traducción gratuitamente.

Curso de TCP - Los DATAGRAMAS - Curso de TCP - Los DATAGRAMAS
Probablemente pensaréis que estoy eliminaré por no considerarlos

exagerando al hablar de la jungla de los importantes, o bien por considerarlos
RFCs y, realmente así es. demasiado complejos para la línea que
está siguiendo este curso.
Los RFCs no se han comido nadie hasta
ahora y,,, como todo en esta vida, solo Os aconsejo que cojáis el RFC 791 y lo
requiere un poco de tiempo para tenerlos vayáis siguiendo junto con este artículo.
bajo control. El problema que yo veo a En lugar de seguir una numeración
enfrentarse directamente a los RFCs, sin ordenada para este artículo, iré poniendo
tener conocimientos previos, es el mismo la numeración correspondiente a cada
que vería a intentar aprender castellano uno de los puntos del RFC que trate. Así,
con un diccionario. Cuando tú buscas una el artículo empezará con el punto 1.4 del
definición de una palabra en un RFC 791.
diccionario, siempre te la definen con
otras palabras, que a su vez están en el
diccionario. Por tanto, es imposible entrar ! ¿No dominas el Ingles?
en ese círculo vicioso de definiciones si
tú previamente no sabes hablar castellano, ¿No dominas el Ingles? Pues una vez más te aconsejamos
y conoces ya un conjunto bastante amplio un paseo por la Web www.rfc-es.org
de palabras.
En ella encontrarás el RFC 791 en perfecto castellano y,
Lo mismo ocurre con los RFC, ya que son por supuesto, damos las gracias a los masters y
documentos escritos asumiendo que la colaboradores de dicha Web por el fantástico trabajo de
persona que los leerá sabrá ya bastante traducción que están realizando.
sobre el tema. En cada RFC prácticamente
se asume que se sabe de antemano todo
aquello que no se explique en ese propio
RFC, igual que en una definición de
diccionario se asume que conoces todas
las palabras que puedan entrar en la
definición. 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
aplicación, 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 sabéis 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 páginas, y hay algunos puntos que

1.4. OPERACIÓN Por ejemplo, en función del tipo de

servicio, un gateway puede decidir
El protocolo IP (Internet Protocol) encaminar un paquete bien hacia otro
implementa dos funciones básicas: gateway que tenga un gran ancho de
direccionamiento, y fragmentación. banda pero poca fiabilidad, o bien hacia
un gateway más lento pero más seguro,
La función de direccionamiento ya la siempre y cuando ambos caminos
permitan llegar al mismo destino.
conocemos bien, pues el artículo anterior
estaba íntegramente dedicado a este
Además, un gateway podría incluso decidir
tema (aunque aún tengo pendiente
descartar un datagrama en caso de
completar este curso con una nueva
congestión en la red (en caso de que el
entrega de la serie RAW que trate sobre
datagrama no tenga una prioridad alta).
protocolos de encaminamiento). Como
Algo hablé ya sobre el tipo de servicio a
ya sabemos, es la capa IP la que se
lo largo del curso.
encarga de asignar direcciones únicas a
cada máquina, para que podamos acceder Con respecto al tiempo de vida, sí que
a cada una de ellas como si de números lo detallé bastante en el artículo sobre
de teléfono se tratase. ICMP, cuando expliqué el funcionamiento
de la herramienta traceroute. Para los
Con respecto a la fragmentación, algo que no hayáis leído ese artículo, os resumo
he comentado a lo largo del curso, pero diciendo que el tiempo de vida es un
en este artículo lo veremos en detalle. parámetro de cada datagrama que permite
El protocolo IP permite dividir los limitar el número de gateways que puede
datagramas (paquetes IP) en trozos lo atravesar el datagrama antes de llegar a
suficientemente pequeños como para su destino.
adaptarse a las capacidades tecnológicas
de cada red. IP no sólo se encarga de Si este número de pasos se sobrepasa,
dividir los fragmentos, si no que además el datagrama sencillamente será
debe garantizar un mecanismo para descartado, y el transmisor del datagrama
reconstruir los paquetes originales a partir será notificado del problema (mediante
de los fragmentos. un mensaje ICMP de tipo Time
Exceeded).
El protocolo IP utiliza 4 mecanismos clave
para implementar estos servicios: el tipo Con respecto a las opciones, se trata de
de servicio (TOS), el tiempo de vida una serie de cabeceras opcionales para
cada datagrama, en las cuales se pueden
(TTL), las opciones, y la suma de
implementar diversos servicios, como
comprobación (checksum).
instrucciones explícitas de encaminamiento
para ese datagrama, opciones de
Iremos viendo en detalle a lo largo del
seguridad, etc.
artículo cada uno de estos mecanismos,
pero os voy adelantando que el tipo de
Por último, la suma de comprobación
servicio es un mecanismo que permite
ya sabemos para qué sirve, ya que
asignar prioridades a los datagramas,
funciona exactamente igual que las sumas
para que así los gateways encargados de comprobación (checksums) de TCP,
de encaminarlos puedan tomar ciertas UDP, e ICMP. Os resumo diciendo que la
decisiones. suma de comprobación es un sello que

se pone a cada datagrama que, De todas estas funciones se tendrán que

comparándolo con los contenidos del ocupar otros protocolos (en caso de que
datagrama, permite detectar si ha habido sean necesarias), por lo que IP funciona
algún error en la transmisión que haya siempre en una jerarquía de protocolos
deteriorado los contenidos. por capas, tal y como hemos visto desde
el principio del curso.
Como estamos viendo, hay un gran
número de situaciones por las que tendría
que haber una notificación de errores, 2.2. MODELO DE OPERACIÓN
como cuando se descarta un datagrama
por haber superado su tiempo de vida, Ya se que los epígrafes probablemente
o cuando un datagrama de baja prioridad no os estén diciendo nada, porque eso
es rechazado por una red congestionada, de que el primer punto se llame
etc., etc. operación- y el segundo -modelo de
El protocolo IP por si mismo no operación- no es precisamente muy
proporciona ningún mecanismo de descriptivo, pero es que quiero conservar
notificación ni control de errores, por lo los nombres originales del RFC. Los puntos
que es un requisito obligado que cualquier de los que he prescindido hasta ahora
implementación de IP esté acompañada (prefacio, 1.1, 1.2, 1.3, y 2.1) son temas
de una implementación de ICMP, que que ya he explicado a lo largo del curso.
es el protocolo encargado de la
notificación de errores de la capa IP. En este punto lo que nos encontramos
es un ejemplo básico de funcionamiento
Si bien la implementación de ICMP es del protocolo IP y, a pesar de que este
obligada para cualquier máquina que tipo de ejemplos ya los hemos visto a lo
utilice IP, hay otros servicios que tampoco largo del curso, he considerado adecuado
están garantizados por IP y que, en repetirlo una vez más para ir consolidando
cambio, no son de uso obligado. las ideas fundamentales.
Por ejemplo, el protocolo IP proporciona

En este ejemplo tenemos dos máquinas
un servicio no orientado a conexión,
(A y B) que se comunican entre sí a
donde cada datagrama es independiente,
través de un gateway (G).
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 según las
necesidades de cada aplicación.
El protocolo IP no proporciona una En un caso real, lo normal es que no haya

comunicación fiable (al no haber un único gateway, si no toda una cadena
respuestas de confirmación para los de ellos para comunicar a A con B.
datagramas), ni mecanismos de
control de errores (excepto el Supongamos que A quiere enviar un
checksum, que permite detectar algunos datagrama a B, y que ese paquete forma
errores, pero nunca corregirlos), ni parte de la comunicación entre dos
mecanismos de control de flujo. aplicaciones que corren en A y en B, por

ejemplo, un servidor web (Apache) datagrama, si no también una serie de

corriendo en B, y un navegador (Opera, parámetros que ésta necesitará.
Firefox, Netscape...) corriendo en A.
El parámetro más importante será la
En primer lugar, la aplicación que corre dirección de destino, pero en este caso
en A, por ejemplo, Firefox, solicitará a no será una dirección IP, si no una
la capa IP del sistema operativo de A la dirección de red local. Cuando hablemos
transmisión del paquete, con los datos en este curso sobre los protocolos de nivel
que quiera que éste contenga, por de enlace ya veremos más sobre esto. Lo
ejemplo, una petición GET de HTTP que sí que tenemos que tener claro ahora
(¿recordáis mi artículo de la serie RAW es que la dirección que pasa de la capa
sobre el protocolo HTTP?). IP a la capa de enlace no es la dirección
de B, si no la dirección de G, que será
Para ello, no bastará con que se le la única máquina que establecerá una
proporcionen a la capa IP los datos que conexión directa con A.
contendrá el paquete (incluyendo en
estos datos las cabeceras de protocolos Por supuesto, G se tendrá que encargar
de nivel superior, como podría ser TCP), de enviar luego el datagrama a B, igual
si no que además es necesario decirle que si A hubiera conectado directamente
cuál va a ser la dirección IP de destino con B.
del paquete, así como otros parámetros
que ya iremos viendo.
Una vez que la capa IP tiene el paquete Una vez que el datagrama ya está en la
y los parámetros necesarios, tendrá que capa de enlace, junto con los parámetros
construir su propia cabecera que necesarios, esta capa se encargará de
añadirá al paquete, formando así un añadir al datagrama su propia cabecera
datagrama. Bueno... uno o varios, pues y, una vez
podría decidir fragmentar el paquete por hecho esto,
ser demasiado grande, pero en este ya sólo
ejemplo simple f a l t a r á
vamos a enviar el
suponer que no paquete a través del cable físico.
es necesaria la
fragmentación. Una vez en el cable (medio físico) que
conecta con la red local, el paquete
Ahora que ya tenemos el datagrama llegará a todas las máquinas que hay
formado, tenemos que enviarlo a la capa conectadas a esa red local. Una de esas
inferior, que nosotros conocemos como máquinas será el router G, que al
capa de enlace. A esta capa de enlace comprobar que la dirección de red de
no sólo tendremos que darle el destino del paquete es la suya, será el

único que se quede con el paquete no complicar las cosas), por lo que lo
(bueno, claro, a no ser que en la red único que tendrá que hacer será generar
haya alguna máquina maligna que esté una nueva cabecera de enlace para
en modo promiscuo, por ejemplo si está que éste llegue hasta B.
usando un sniffer para capturar todo el
tráfico de la red, aunque no vaya dirigido Para ello, pasa el datragrama a su propia
a ella). capa de enlace, indicándole la dirección
de red de B.
Una vez que el paquete está en G, como

ya ha utilizado la información de la
Una vez que la capa de enlace de G tiene
cabecera de enlace, es decir, su propia
todos los
dirección de red para saber que el paquete
d a t o s
iba dirigido a él, puede prescindir de
la cabecera de enlace, y obtener así necesarios,
el datagrama tal y como lo generó la creará una
capa IP de la máquina A. n u e v a
cabecera de enlace que añadirá al
datagrama, y ya podrá lanzarlo a través
del cable físico 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 máquina 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 máquina B, por lo que deduce
que ella es la encargada de retransmitir
el paquete para que pueda llegar hasta
su destino.
La máquina G no modificará
absolutamente nada del datagrama (o al Sabiendo ya esto, ya no necesita más
menos eso creeremos de momento, para esa cabecera de enlace, por lo que la

destruye y pasa el resto del paquete (el Con respecto al direccionamiento contaré
datagrama) a su propia capa IP. poco, ya que para ello dediqué el artículo
anterior sólo a este tema.
Direccionamiento
Probablemente en el ejemplo anterior no

os habrá quedado muy claro el tema de
las direcciones de red. ¿Cómo sabe la
capa IP qué direcciones de red tiene cada
máquina?
Aquí el RFC hace una distinción entre 3

En la capa IP de la máquina B, ésta
conceptos: nombres, direcciones, y rutas.
descubre que el destinatario final del
datagrama es ella misma, por lo que
busca en la cabecera IP el dato que le Un nombre indica qué buscamos.
diga a qué capa superior tiene que pasar Una dirección indica dónde está lo
el datagrama. que buscamos.
Una ruta indica cómo llegar hasta
Con esto, ya sólo tendrá que enviar el
esa dirección.
datagrama a las capas superiores, donde
la aplicación de B (el servidor Apache)
La responsabilidad de convertir nombres
hará con los datos del paquete lo que le
en direcciones reside en los protocolos
plazca (es decir, procesará la petición
de nivel superior a IP. Por supuesto, aquí
GET de HTTP que hizo A).
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 también 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 traducción de direcciones
IP a direcciones de red (las que utiliza la
2.3. DESCRIPCIÓN DE capa de enlace). Por ejemplo, si utilizamos
FUNCIONES Ethernet en la capa de enlace,
necesitaremos el protocolo ARP (Address
Aquí el RFC entra en algo más de detalle
Resolution Protocol) para mantener la
sobre las dos funciones básicas que
traducción entre direcciones IP y
menciona al principio: direccionamiento,
y fragmentación. Para entrar ya en todos direcciones de red local que, en este caso,
los detalles habrá que esperar a llegar serán las famosas direcciones MAC. Todo
más adelante, cuando se describen uno esto ya lo iremos viendo a lo largo del
a uno los campos de la cabecera IP. curso.

Fragmentación Ahora que comprendemos quién y por

qué lleva a cabo la fragmentación, nos
Como ya he dicho, según la tecnología falta conocer el cómo se lleva a cabo esta
utilizada en cada red, los paquetes fragmentación.
tendrán limitado su tamaño máximo.
Si pensamos un poco, enseguida nos
Internet es una red muy heterogénea, daremos cuenta intuitivamente de que
en la que conviven todo tipo de hacen falta básicamente dos cosas: un
tecnologías, por lo que se hacen campo que nos indique a qué datagrama
imprescindibles mecanismos para adaptar pertenece ese fragmento, y otro campo
estas diferencias de forma transparente. que nos indique qué posición ocupa ese
Y no sólo de forma transparente al usuario fragmento dentro del datagrama original.
final, si no también a cualquier protocolo
que no se encuentre en la capa que se
Para llevar a cabo la identificación del
encargue de esta función, dentro de la
datagrama al que pertenece el fragmento
jerarquía de capas de protocolos.
se recurre a una combinación de campos,
de los cuales el más importante es el
Por tanto, al encargarse la capa IP de
campo llamado Identification
esta función, la fragmentación tiene que
(identificación).
ser transparente para los protocolos
En la imagen vemos superiores, como TCP, o los protocolos
cómo sale un único Este campo es un número que puede
de aplicación.
datagrama del identificar unívocamente un datagrama
transmisor, que llega para una escenario concreto. Es decir, la
en primer lugar hasta ¿Quién decide cuándo hay que fragmentar
un datagrama? Esta decisión combinación de las ips de origen y
el gateway G1. G1
sabe que el próximo normalmente no se tomará en la máquina destino, y el protocolo de nivel
gateway en el camino que generó el datagrama (el transmisor), superior (TCP, UDP, ...,...) junto con el
es G2, y sabe que campo Identification es siempre única
ya que ésta difícilmente podrá saber los
éste se encuentra en
problemas con los que se encontrará el para cada datagrama.
una red de una
tecnología diferente datagrama en su camino hasta el destino,
(la nubecita azul) que por lo que es responsabilidad de cada Podremos encontrar dos datagramas
no puede manejar uno de los gateways que haya en el diferentes con el mismo campo
paquetes tan grandes, camino juzgar si el datagrama va a tener Identification, si por ejemplo es diferente
por lo que G1 decide
que pasar por algún cuello de botella por la IP de destino, pero nunca los 4 campos
fragmentar en dos el
el que sea necesario fragmentarlo. podrán ser iguales para diferentes
datagrama original.
datagramas: ip de origen, ip de
destino, protocolo, e identificación.
Para saber qué posición 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.

3.1. FORMATO DE LA CABECERA

IP
Si estáis siguiendo el RFC al mismo tiempo

que el artículo os habréis dado cuenta de
que interpretado la traducción de este
epígrafe muy libremente, ya que el original
se llama Internet Header Format, lo cual
En la imagen vemos
se traduciría como: FORMATO DE LA
como un datagrama Ahora que ya tenemos la idea intuitiva
de 712 bytes es
CABECERA DE INTERNET.
de cómo se lleva a cabo la fragmentación,
fragmentado para
si somos lo suficientemente avispados, He preferido traducir Internet por IP,
poder pasar a través
de una red que nos habremos dado cuenta de que algo porque eso es a lo que realmente se
permite un máximo de falta aquí. Por supuesto, tiene que haber refiere el RFC. Como ya sabemos, IP es
512 bytes. El
alguna forma de indicar cuál es el último el acrónimo de Internet Protocol, por lo
Fragment Offset del
segundo fragmento fragmento o si no, de otra forma, saber que el RFC abrevia llamando Internet al
será 512/8 = 64, ya cuál era el tamaño original del datagrama protocolo IP. Esta terminología me parece
que el offset se mide fragmentado, para saber cuándo tenemos muy ambigua (y seguro que a vosotros
en unidades de 64 bits también), por lo que he preferido referirme
(8 bytes).
todos los fragmentos para reconstruirlo.
a IP en todo momento, en lugar de
referirme a Internet a secas.
En IP se ha optado por la primera opción,
es decir, marcar con un flag (un indicador Sin más preámbulos, vamos a plantar
de un simple bit) cuál es el último aquí el aspecto de la cabecera de un
fragmento. datagrama:
Pero éste no es el único flag que se utiliza Veamos cada campo.

para controlar el mecanismo de
fragmentación de datagramas. Existe Versión (Version): 4 bits
otro flag que sirve para indicar que un
datagrama en concreto no debe ser Aquí estamos hablando de la versión
clásica IPv4, pero en un artículo futuro
fragmentado bajo ningún concepto. En
ya hablaremos de la versión IPv6 que
caso de que un datagrama marcado con
será el próximo estándar que definirá el
este flag tenga que circular a través de
funcionamiento de la nueva red Internet.
una red que requiere paquetes más Por tanto, este campo de momento para
pequeños, el datagrama sencillamente nosotros valdrá siempre 4 (0100 en
será rechazado. binario).

Longitud de la cabecera IP con la idea de que, cuanto mayor es este

(IHL: Internet Header Length): número, mayor es la prioridad de un
datagrama.
4 bits
En caso de congestión en la red, los
Este campo indica la longitud de la
datagramas que serán descartados en
cabecera IP (esta misma cabecera)
primer lugar serán los que tengan
medida en palabras de 32 bits. Como
prioridad 000 (rutinarios). Precisamente,
la cabecera IP puede contener opciones
prácticamente todo el tráfico que solemos
de tamaño variable, es necesario este
utilizar en nuestras casitas es de prioridad
campo que nos indica en qué punto
000.
termina la cabecera y comienzan los
propios datos del paquete. La segunda parte del TOS son otros 5
bits que funcionan a modo de flags, es
Una cabecera sin ninguna opción mide
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
160 bits, es decir, 5 filas de 32 bits,
independiente de alguna característica
por lo que el valor mínimo para este
del datagrama. Estos son los significados
campo y, de hecho, también el valor más
de cada flag:
típico, es 5 (0101 en binario).
Tipo de servicio (TOS: Type Of

Service): 8 bits
Una vez más vuelve a entrar en escena Empezamos a contar a partir del bit 3,
este campo sobre el que siempre he ya que los bits 0-2 son los que especifican
hablado muy por encima. Al fin ha la prioridad (precedence), tal y como
llegado el momento de que entremos vemos en este esquema que resume toda
la estructura del campo TOS:
en detalle.
El campo TOS en realidad se podría 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, Los bits 6 a 7 no se usan, por lo que se
mayor prioridad, tomando estos nombres ponen siempre a 0. Los otros 3 flags (D,
las 8 prioridades que se pueden T, y R) mantienen un compromiso mutuo
especificar: entre 3 características de la comunicación
incompatibles entre sí. Es decir, por poner
un ejemplo, en general, cuanto más rápida
(mayor ancho de banda) es una
comunicación, menor fiabilidad tendrá.
Si el flag D (Delay) está activo significa

que el tipo de servicio que está ofreciendo
este datagrama requiere un retardo
No es muy importante comprender el mínimo. Por ejemplo, cualquier
significado de estos nombres ya que, aplicación interactiva requerirá retardos
entre otras cosas, los que he puesto han mínimos, por lo que los datagramas de
sido traducciones libres que he hecho yo estas aplicaciones deberían ser dirigidos
mismo. Lo importante es que os quedéis a través de redes que, aunque sean lentas

y/o poco fiables, al menos sí que ancho de banda (flag T), pero en cambio
garanticen que la respuesta será lo más no se puede exigir que para colmo la
inmediata posible. comunicación tenga máxima fiabilidad
(flag R) y no se pierda ni un sólo detalle
Si el flag T (Throughput) está activo de la imagen por el camino.
significa que el tipo de servicio que está
ofreciendo este datagrama requiere el Longitud Total (Total Length):
máximo ancho de banda que se le 16 bits
pueda ofrecer. Por ejemplo, este flag es
útil para transmisiones de contenidos
Si bien el campo IHL sólo media la
multimedia, donde lo importante es
longitud de la cabecera IP para saber en
poder transmitir a toda velocidad, al
qué punto comienzan los datos, este
margen de que se pueda perder algún
campo indica, en bytes, la longitud total
dato (por ejemplo, un simple fotograma
de todo el datagrama, para saber
de una película), es decir, aunque el
dónde terminan los datos.
servicio tenga baja fiabilidad, y también
al margen de que los datos lleguen en
Al ser 16 bits, el tamaño máximo de
tiempo real, es decir, que el retardo no
paquete será de 65536 bytes, lo cual
sea un factor crítico.
está muy por encima del tamaño de
paquete que puede circular por cualquier
Si el flag R (Reliability) está activo
red normal.
significa que el tipo de servicio que está
ofreciendo este datagrama requiere una
máxima fiabilidad, al margen de que
Identificación (Identification):
la comunicación sea en tiempo real 16 bits
(retardo), o del ancho de banda de la
misma. Cualquier aplicación que requiera Este es el campo que se utiliza para
precisión en los datos, como la identificar el datagrama al que pertenece
transferencia de archivos binarios, un fragmento. Como ya dije, la
entraría dentro de este tipo de servicios. combinación de este campo con la ip de
origen, la ip de destino, y el número de
En realidad estos flags no suelen utilizarse protocolo, identifica unívocamente un
por muchas aplicaciones, ya que requieren datagrama para permitir su reensamblaje
un coste adicional en el procesamiento a partir de sus fragmentos.
de los datagramas. Aún así, cabe destacar
que hay tipos de servicio que pueden Indicadores (flags): 3 bits
tener requisitos tan fuertes que tengan
activados dos de los tres flags, pero Aquí tenemos 2 indicadores de los que
activar los 3 sería absurdo, ya que ya he hablado:
estaríamos pidiendo que se optimizasen
3 parámetros 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 El bit 0 es de uso reservado, por lo que

videoconferencia podría requerir al mismo siempre se pondrá a 0.
tiempo un bajo retardo (flag D) (por
supuesto, una videoconferencia tiene que El flag DF (Dont Fragment), en caso
ser en tiempo real), y también un gran de estar activo, indica que este datagrama

no puede ser fragmentado, por lo que, Cada gateway por el que pase el
en caso de que el datagrama no quepa datagrama tendrá que restar en 1 este
en una red, tendrá que ser descartado. valor, y si en algún caso llega a valer 0,
En otros artículos ya hemos visto algunas el gateway que diódio este valor tiene
aplicaciones de este tipo de datagramas, que interrumpir en ese punto la
como el mecanismo de Path MTU transmisión del datagrama, y devolver a
Discovery (PMTUD) que expliqué en su transmisor original un mensaje ICMP
el artículo sobre ICMP. Os recomiendo de tipo Time Exceeded.
que volváis a leer ahora ese apartado
para que lo comprendáis mejor Si estáis bien despiertos habréis observado
conociendo ahora el mecanismo de en este punto un detalle importante, y
fragmentación. es que (a pesar de que en el ejemplo del
punto 2.2 dije que los gateways no
El flag MF (More Fragments), en caso modifican la cabecera IP original) los
de estar activo, indica que este gateways que actúan como intermediarios
fragmento NO es el último de los que en la transmisión de un datagrama
forman el datagrama original. En caso pueden, y en casos como éste deben,
de que sí que sea el último, se indicará modificar algún campo de la cabecera IP.
poniendo a 0 este flag. Por supuesto, si
está activo al mismo tiempo el flag DF, Protocolo (Protocol): 8 bits
no tendrá sentido el uso de este flag,
por lo que se podrá dejar a 0 Este campo identifica el protocolo de
tranquilamente. nivel superior en la jerarquía, para que
el módulo de la capa IP del receptor sepa
Desplazamiento del fragmento cómo debe procesar el datagrama. Como
(Fragment Offset): 13 bits ya sabemos, por ejemplo, el protocolo
TCP se identifica con el valor 6
(00000110 en binario).
Indica la posición del fragmento dentro
del datagrama original, en unidades de
8 octetos, es decir, 64 bits. Suma de comprobación de la
cabecera (Header Checksum):
El primer fragmento tendrá siempre un 16 bits
desplazamiento 0. Si, por ejemplo, el
primer fragmento tenía un tamaño de Ya sabemos bien cómo funcionan las
512 bytes, el segundo fragmento tendrá sumas de comprobación. El algoritmo es
un desplazamiento de 512/8 = 64. el mismo que en el caso de TCP, UDP,
o ICMP. El problema aquí es que, como
Tiempo de Vida (TTL: Time To los gateways que procesan el datagrama
a lo largo de todo el camino modifican la
Live): 8 bits
cabecera (como acabamos de ver al hablar
del campo TTL), es necesario recalcular
Ya hablé bastante sobre este campo,
una nueva suma de comprobación en
sobre todo en el artículo sobre ICMP.
cada gateway por el que pasa el
Como ya sabemos, indica el número
datagrama.
máximo de gateways que puede
atravesar el datagrama antes de Por tanto, cada gateway, en primer lugar
considerarse caducado. comprueba el checksum del datagrama

que ha recibido, si es valido hace lo que Por tanto, se hace imprescindible la

tenga que hacer con él (como presencia del campo IHL que, como
decrementar el valor TTL), y por último, vimos, indica en qué punto termina la
ya con la cabecera modificada, recalcula cabecera IP y comienzan los datos.
un nuevo checksum, que
susituirásustituirá al anterior. Como ya vimos, el campo IHL mide la
longitud de la cabecera en palabras de
Por tanto, tenemos aquí un nuevo ejemplo 32 bits. Esto no significa que las opciones
de un campo de la cabecera IP que es de la cabecera tengan que ajustarse
modificado en cada gateway por el que necesariamente a este tamaño. Por este
pasa el datagrama. motivo, en caso de que el tamaño de las
opciones no sea múltiplo de 32 bits, será
Dirección IP de origen (Source necesario rellenar con ceros los bits
Address): 32 bits necesarios hasta que se complete una
fila de 32 bits. Estos ceros son los que
aparecen como Padding en el dibujo de
Como ya sabemos, una dirección IP ocupa
la cabecera que puse al principio.
32 bits. Este campo es uno de los más
importantes de la cabecera IP, y especifica
El campo Options consta de una,
la dirección IP del transmisor del
ninguna, o varias opciones. En caso de
datagrama. Es el campo que se modifica
que haya varias opciones, estas irán
cuando hacemos un IP Spoofing.
seguidas una detrás de otra, hasta que
ya no haya más opciones. El formato de
Dirección IP de destino
cada una de las opciones es variable.
(Destination Address): 32 bits
El único campo que tienen en común
Pues eso, la dirección IP del receptor todas las opciones es un campo de un
del datagrama. Por supuesto, es también byte que sirve precisamente para
uno de los campos más importantes. identificar el tipo de opción.
Opciones (Options): longitud Este byte, llamado Tipo de opción

variable (option-type), consta a su vez de varios
campos que, combinados, identifican un
Esta es, sin duda, la parte más compleja tipo concreto de opción.
de la cabecera IP. En primer lugar, porque
su longitud es variable. Esta es la estructura del option-type:
Puede haber datagramas que no tengan

ninguna opción y, por tanto, todo este
campo sea inexistente, y justo después El primer bit es el bit de copiado (copied
de la dirección IP de destino se encuentren flag). Este bit se utiliza sólo en
ya los datos del paquete. De hecho, los datagramas fragmentados. En caso de
datagramas sin opciones son que este bit esté a 1 significa que esta
probablemente los más comunes. Pero, opción se repite en todos los fragmentos
igual que puede haber datagramas sin del mismo datagrama, es decir, es una
opciones, también los puede haber con opción del datagrama original, y no sólo
un gran número de opciones, y cada una del fragmento.
de ellas además con una longitud variable.

A continuación tenemos los 2 bits de Sin operación (No Operation)

clase de opción (option class). Existen
4 clases definidas, de las cuales sólo se Esta opción consta también
utilizan 2 y, para colmo, de estas dos de un único byte
prácticamente sólo se utiliza la primera: (00000001), y es un clásico
NOP, es decir, una instrucción que no
hace nada.
La utilidad de esta opción es

simplemente separar opciones para
Por último, tenemos 5 bits que especifican ajustarlas a palabras de 32 bits, es decir,
el tipo concreto de opción dentro de si una opción ocupa 24 bits, se podría
esa clase (option number). Esta es la poner un No Operation entre ésta y la
lista de opciones definidas para cada siguiente, si quisiésemos que la siguiente
clase: opción comenzase en una nueva fila de
32 bits (ya que 24+8 = 32).
Opciones de seguridad
(Security)
A pesar de lo atractivo del nombre de

Qué poco me gusta esto de traducir
términos tan técnicos... pero no os esta opción, me temo que no voy a poder
preocupéis, que ahora iré hablando de contaros mucho, ya que el uso de esta
cada opción, e incluiré, a parte de esta opción es tan complejo que requiere un
traducción, también los nombres RFC propio para detallarla. Este es el RFC
originales en inglés. 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).
Definiciones específicas de
Esta opción está definida por el
las opciones departamento de defensa de los estados
unidos, e incorpora información de
Fin de lista de opciones (End distintos niveles de confidencialidad a los
of options list) datagramas (desde información
desclasificada, hasta alto secreto).
Esta opción consta de un
único byte, con 8 ceros Tampoco creo que os enteréis de mucho
(00000000), y se coloca
leyendo el RFC 1108 así que, teniendo
siempre como última opción, para marcar
en cuenta que esta opción no os la vais
que ya no hay más opciones.
a encontrar habitualmente, en principio
No será necesaria en caso de que el podéis ignorarla. Por supuesto, animo al
tamaño de las opciones se ajuste a un que tenga interés a que investigue por
múltiplo de 32 bits, por lo que el fin de su cuenta (aunque os advierto de
las opciones vendrá delimitado por el antemano que no os bastará con el RFC
campo IHL. 1108).

Sólo he de destacar dos detalles, para

que identifiquéis esta opción si os la
encontráis.
Esta opción obligatoriamente tiene que El primer byte, por supuesto, es el option-
tener activo el flag copied, es decir, el type que, como vemos, tiene que tener
primer bit del option-type, por lo que su obligatoriamente activo su flag copied
byte option-type siempre será (el primer bit).
10000010 (130 en decimal). Aparte del
option-type, los 10 próximos bytes El segundo byte indica la longitud en
pertenecerán a esta opción (ya que tiene bytes de toda la opción LSRR, incluyendo
una longitud total de 11 bytes). el option-type y el propio byte de longitud
(length).
Encaminamiento débilmente
especificado por el transmisor El tercer byte, es el puntero (pointer)
que permite ir rastreando la lista de
(LSRR: Loose source and
gateways según el datagrama va
record route)
recorriendo su camino.
Esta opción permite especificar el camino El cuarto campo, de longitud variable, los
que debe seguir el datagrama para llegar datos de enrutamiento (route data)
hasta su destino, es decir, una lista de es donde se encuentra la lista de
gateways por los que debe pasar gateways que debe atravesar el
obligatoriamente el datagrama en el datagrama.
camino hacia su destino.
Para comprender el funcionamiento del
Cada uno de estos gateways puede decidir LSRR vamos a verlo con un ejemplo.
hacer pasar el datagrama por otros Supongamos que tenemos esta opción
gateways intermedios no especificados LSRR:
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
Y nuestro datagrama tiene como IP de
gateways de la lista, el datagrama
también puede pasar además por otros destino la IP 217.15.12.100.
gateways que no estén en la lista, motivo
por el cual se habla de encaminamiento En primer lugar, vamos a comprobar el
DEBILMENTE especificado. byte length. Como vemos, vale
00001111, que es 15 en decimal. En
Como veremos después, la diferencia con efecto, si tenemos 3 direcciones IP en
el encaminamiento ESTRICTAMENTE el campo route data, con 4 bytes por
especificado es que en este segundo caso IP tenemos un total de 3 x 4 = 12 bytes
el datagrama sólo podrá pasar por los para el campo route data. Si a esos
gateways de la lista, y no podrá haber 12 le sumamos los 3 bytes que ocupan
otros intermedios.
los campos option-type, length, y pointer,
tenemos un total de 15 bytes para toda
Para implementar esta función, la opción
la opción.
LSRR consta de 4 campos:

En principio, el pointer vale 00000100, Una vez que el datagrama está en el

que es 4 en decimal. Esto significa que segundo gateway de la lista, éste volverá
el primer gateway de la lista se encuentra a incrementar en 4 el puntero: 8+4
en el byte 4 de la opción. Es evidente = 12, luego el nuevo puntero será
que el campo pointer siempre tiene que 00001100. Ahora el puntero apuntará
empezar valiendo 4, ya que el cuarto al gateway 84.2.100.1. Pero no tenemos
byte de la opción LSRR es siempre donde conexión directa con este gateway, por
empieza la lista de gateways (el campo lo que el datagrama será enviado a otro
route data). gateway que sabemos que sí que puede
a l c a n z a r l a r e d d e 8 4 . 2 . 1 0 0 . 1.
En cuanto nuestro datagrama salga de
nuestra máquina, tendrá que ir al
gateway 215.20.1.1, ya que es al que
está apuntando nuestro puntero.
Cuando el datagrama llegue a este

gateway intermedio, éste no
modificará el puntero, y simplemente
retransmitirá el datagrama al gateway
En cuanto el datagrama llega a este 84.2.100.1, que era donde queríamos
gateway, éste tendrá que modificar el llegar.
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 continuación, el gateway
215.20.1.1 enviará el datagrama al
gateway 80.6.13.200.
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 explícito,

y a partir de este punto se sigue un En el ejemplo anterior, el datagrama no

encaminamiento normal, es decir, podría haber pasado por el gateway
basándonos en la IP de destino, 82.15.1.1 si se hubiese tratado de una
217.15.12.100. opción SSRR, en lugar de una LSRR.
Registro de ruta (Record route)
El formato de esta opción es similar al de

las opciones LSRR y SSRR:
Pero el funcionamiento es diferente.
Con todo esto (además de conseguir que, Inicialmente, el campo route data estará
por los motivos que sean, nuestro en blanco, y tendrá un tamaño lo
datagrama atraviese un camino prefijado) suficientemente grande como para que
además al destinatario del datagrama le quepa toda la ruta que se estima que siga
llegará un registro de estos gateways
el datagrama.
por los que ha ido pasando el datagrama
que le ha llegado, ya que la lista se
Si bien en las opciones LSRR y SSRR hay
mantiene íntegra en el campo route
data, y es sólo el puntero el que se va que activar el flag copied, para que todos
modificando para ir rastreando la lista. los fragmentos puedan encaminarse
correctamente a través del camino
Encaminamiento estrictamente prefijado, en el caso de la opción record
especificado por el transmisor route ocurre lo contrario. No tendría
(SSRR: Strict Source and sentido repetir la misma información en
Record Route) todos los fragmentos, por lo que esta
opción sólo se incluirá en el primer
fragmento y, por tanto, tendrá a 0 su
flag copied.
En esta opción, el campo route data está

El funcionamiento de esta opción, así vacío cuando el datagrama sale del
como su formato, es exactamente el transmisor. Cada gateway por el que pase
mismo que el de la opción LSRR, con la el datagrama tendrá que añadir al route
diferencia de que en este caso el data su propia dirección IP, y avanzar
datagrama no podrá atravesar ningún el puntero en 4 bytes. Así, cuando el
gateway que no esté en la lista route datagrama llegue finalmente a su receptor,
data. En caso de que el datagrama no éste tendrá en route data un registro
pueda llegar hasta su destino utilizando completo de todos los gateways que
únicamente los gateways especificados, ha ido atravesando el datagrama en
el datagrama tendrá que ser rechazado. su camino.

En el caso de que durante la ruta el Sello de Tiempo (Internet

datagrama llegue a un gateway y éste Timestamp)
no pueda insertar en el registro su
dirección IP (porque no quepa en route
Esta es quizá la más complicada de las
data), éste gateway tendría que devolver opciones, pero eso, por supuesto, no será
al transmisor del datagrama un ICMP
un problema para nosotros.
de tipo Parameter Problem para avisar
del problema. Aún así, el datagrama debe Esta opción permite seguir el rastro al
llegar a su destino, por lo que ésta no es camino del datagrama, pero ahora con
una situación de error crítica. mucho más detalle, ya que lo que se
consigue con esta opción es saber en
Mirad detenidamente la siguiente imagen, qué momento exacto (con precisión de
siguiendo el camino del datagrama desde milisegundos) pasó el datagrama por cada
el transmisor hasta el receptor: gateway. Esto permite, entre otras cosas,
comprobar la calidad de la comunicación
entre dos máquinas, teniendo en cuenta
el camino intermedio que hay entre ellas.
De forma intuitiva, podemos pensar que

esta opción es parecida a la Record
Route, pero incluyendo no sólo la
dirección IP de cada gateway por el que
pasa el datagrama, si no también un sello
En la imagen vemos
de tiempo que indique en qué momento
como cada gateway
exacto cogió el datagrama ese gateway. va incluyendo su
propia dirección y su
En realidad, ésta es sólo una de las tres sello de tiempo en
formas diferentes en las que puede cada posición libre del
Identificador de flujo (Stream funcionar esta opción. registro.
Identifier)
Esta opción ha quedado obsoleta, tal y como

especifica el RFC 1122, por lo que lo normal
es que una máquina que reciba un datagrama
con esta opción sencillamente la ignore.
Otra opción consiste en que sólo se

Esta opción servía para incluir en un datagrama
incluyan los sellos de tiempo, pero no
un identificador de la red SATNET (Atlantic
la dirección IP de cada gateway.
Satellite Packet Network). Para ello, la opción
constaba de 4 bytes. El primer byte era, por Por tanto, tendríamos tan sólo un registro
supuesto, el option-type, el segundo de tiempos pero no una lista de
especificaba la longitud, que siempre era 4 direcciones IP, en caso de que sólo nos
(00000100). Los dos últimos bytes formaban interese comprobar la calidad de la
el Stream ID, es decir, el identificador de comunicación, independientemente de
SATNET. por dónde haya pasado el datagrama.

por los que tiene que pasar el datagrama,

por lo que podríamos incluir simplemente
los sellos de tiempo (hasta 9, como hemos
visto), sin necesidad de acompañarlos de
las direcciones IP mediante una opción
Record Route.
Esta imagen es
En este caso, esta opción se podría
similar, pero con la
diferencia de que en
acompañar de una opción Record Route,
este caso los pero sería absurdo, ya que se obtendría
gateways sólo el mismo resultado que utilizando
incluyen su sello de
directamente la opción Timestamp pero
tiempo, y no su
dirección IP.
incluyendo las direcciones IP en los
propios timestamp. Aquí el datagrama,
Si en lugar de una opción SSRR fuese
además de los sellos
una opción LSRR, no tendríamos manera de tiempo, lleva una
El único motivo para hacer esto sería que
de saber qué gateways han incluido su opción SSRR que nos
el camino entre las dos máquinas fuese
sello de tiempo, ya que no podemos saber dice de antemano las
demasiado largo (muchos gateways), ya IPs de todos los
por qué gateways intermedios ha pasado
que la longitud máxima de la opción gateways que dejarán
el datagrama aparte de los especificados su sello de tiempo.
timestamp es de 40 bytes y, por tanto,
en el route data de la opción LSRR.
si se incluyen las direcciones IP en los
timestamp sólo podríamos incluir sellos
En este ejemplo, de tiempo para 4 gateways, mientras
quien se encarga de
que si las direcciones IP se incluyen
incluir las direcciones
IP de los gateways es aparte (con una opción Record Route)
una opción Record podríamos incluir sellos de tiempo para
Route, mostrada en la 9 gateways. Más adelante veremos el
imagen como RR.
Como vemos en la
Por tanto, una tercera forma de
imagen, aquí no todos
funcionamiento de la opción los gateways que han
Internet Timestamp consiste en dejado su sello de
que el transmisor del datagrama tiempo están en el
route data de la opción
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
LSRR (concretamente
cuyo sello de tiempo desea el gateway 82.15.1.1),
conocer, lo cual sería una buena por lo que no hay
por qué de estos números.
combinación junto con la opción manera de saber a
En el caso de que el datagrama venga qué gateway
LSRR, aunque también sería útil
acompañado de una opción SSRR ya pertenece cada uno
independientemente. de los 4 sellos de
sabríamos de antemano los gateways
tiempo.

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 dirección IP, ocupa 32
bits (4 bytes), tendremos un total de 36/4
= 9 filas en el campo TimeStamps.
Por tanto, en el mejor de los casos (si

Aquí la lista de
No se si con todo esto os habré liado más, sólo incluimos información de timestamps,
gateways (LG) no es
así que mejor vamos a ver punto por y no de direcciones IP), sólo podremos
una opción aparte, si
no que acompaña a punto el funcionamiento de esta opción. incluir información sobre 9 gateways.
cada sello de tiempo.
Como vemos, el Aún así, la opción timestamp puede
Este es el formato básico de la opción
gateway que no está funcionar con hasta 24 gateways
Internet Timestamp:
en la lista (82.15.1.1) aunque, por supuesto, incluyendo sólo
no deja su sello de información sobre 9 de ellos como mucho.
tiempo.
Para permitir este desbordamiento de
Los dos primeros bytes ya los conocemos. la lista de gateways, se incluye el campo
El primero es el option-type, y el overflow (desbordamiento), de 4 bits.
segundo especifica la longitud de la
opción (en bytes, contando desde el Una vez que la lista de timestamps esté
option-type inclusive). ya llena, si el datagrama sigue pasando
por más gateways que deberían incluir
La máxima longitud, según el RFC es información en el registro de timestamps,
40 (00101000). Por supuesto, esta lo que harán estos gateways será
longitud es fija desde que la especifica simplemente incrementar en 1 el En esta imagen sólo
el transmisor del datagrama, por lo que campo overflow (que inicialmente estará se reservaron dos filas
deberá ser suficientemente grande para a 0), con lo que dejan una marca de que, para los sellos de
tiempo (length = 12),
el tamaño que se estima que ocupará aunque el datagrama pasó por ellos, no
por lo que los dos
toda la opción una vez que haya llegado pudieron dejar su sello de tiempo. Por
últimos gateways no
al receptor del datagrama. tanto, con 4 bits podemos permitir que pueden incluir su sello
hasta 15 gateways dejen el aviso de de tiempo, si no sólo
El puntero (pointer) apunta al primer que no pudieron marcar el datagrama una marca de
byte libre dentro del campo timestamp, con su sello de tiempo. overflow.
por lo que el valor de inicio del puntero

será siempre 5 (00000101).
Vamos a hacer ahora unos pocos

cálculos
Si hemos dicho que la longitud máxima

de la opción Internet Timestamp es
de 40 bytes, para calcular el tamaño
máximo del campo TimeStamps
tendremos que restar los 4 primeros

El siguiente campo, Flag, de 4 bits, En caso de que se especifique la medida

permite especificar uno de los 3 modos en cualquier otro formato habrá que poner
de funcionamiento de la opción a 1 el primer bit del sello de tiempo.
Internet Timestamp.
Cuando la opción Internet Timestamp
En realidad, habría sobrado con 2 bits funciona de esta manera permite incluir
para este campo, pero su tamaño se sellos de tiempo de hasta 9 gateways.
redondeó a 4 bits para ajustar la longitud
total de la opción. Estos son los posibles
valores para este campo:
Veamos caso por caso.
0000 Sólo 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.
Esta forma de funcionamiento de la opción
Cada sello de tiempo consta en realidad combina los sellos de tiempo con la función
de 31 bits, ya que el primero (el más que haría un Record Route.
significativo) se usa para especificar el
formato del sello de tiempo. En caso de Cada sello de tiempo, por tanto, viene
que esté a cero este bit, el formato del precedido por la dirección IP del gateway
sello de tiempo será estándar, y si está que deja el sello. Por tanto, para cada
a uno, el sello de tiempo tendrá cualquier gateway habrá que reservar 8 bytes (4
otro formato no estándar (que en para la dirección IP, y 4 para el sello de
principio no se puede especificar, pues tiempo), por lo que con un máximo de
no quedan más bits para dar más detalles, 36 bytes para este campo, tendríamos
aunque se podrían aprovechar los 31 bits 36/8 = 45.
restantes si se llega a un convenio entre
el transmisor y el receptor). Como no puede meterse un gateway a
medias tenemos que redondear por lo bajo,
El formato estándar de sello de tiempo por lo que sólo podríamos incluir información
lo que mide es el número de de 4 gateways. Cualquier otro gateway
milisegundos transcurridos desde la que coja el datagrama una vez rellenadas
medianoche del UT (Universal Time), las 4 filas tendrá simplemente que
que es una hora universal independiente incrementar el campo overflow.
de las franja horarias.

y el transmisor será notificado con un

mensaje ICMP de tipo Parameter
Problem.
También habrá que hacer esto en el caso

de que un gateway no pueda incluir toda
su información, caso que se da por
ejemplo cuando se combinan sellos de
tiempo con registro de direcciones (flag
0001).
Como vimos en ese caso, para un valor

0011 Sellos de tiempo para
40 en el campo length, tendríamos una
gateways predefinidos fila que nos quedaría incompleta, es decir,
nos cabría sólo la dirección IP del gateway,
pero no su sello de tiempo.
En caso de que ese gateway se encontrase

con un hueco insuficiente tendría que
rechazar el datagrama, y enviar un ICMP
En este caso las direcciones IP no están de tipo Parameter Problem al transmisor
inicialmente a 0, si no que están del datagrama.
especificadas, igual que en una opción
LSRR. Es importante, por tanto, estimar
correctamente el tamaño del campo
El datagrama podrá pasar por todos los length para esta opción.
gateways que sea necesario, pero sólo
los gateways incluidos en la lista tendrán Aún nos quedan muchas cosas por ver
que dejar su sello de tiempo. Esta es la sobre la capa IP, sobre todo desde el
única opción que permite que un punto de vista práctico. ¿Cómo se
datagrama con opción Internet utilizan todos estos conceptos
Timestamp circule a través de más de teóricos en el mundo real?
24 gateways. ¿Qué podemos hacer nosotros útil
con toda esta información? ¿Hay
alguna forma de utilizar todo esto
para comprometer la seguridad de
un sistema? ¿Cómo conviene que
configuremos nuestro propio sistema
para evitar esos problemas? Todo esto,
y mucho más, lo veremos en el próximo
artículo.
Autor: PyC (LCo)
En cualquier otro caso, si el campo

overflow se desborda, es decir, si supera
su máximo 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 fragmentación y reensambado de paquetes
- Trataremos los problemas de seguridad derivados de la fragmentación de datagramas
- DoS / Exploits Jolt, Jolt2 y TEARDROP / Floog Y Nuke
- Saltaremos Firewalls e IDSs
INTRODUCCIÓN Todos estos ingredientes hacen que el nivel

de este artículo sea ya bastante alto y, por
Cada vez me voy sintiendo más a gusto tanto, también bastante interesante, en mi
escribiendo para esta revista, ya que hemos opinión.
avanzado juntos ya muchísimos pasos durante
todos estos meses de curso TCP/IP y también, A pesar de eso, me he reservado algunos de
por supuesto, con la serie RAW. los detalles más específicos para una próxima
entrega, en la que quiero, entre otras cosas,
Esto hace que cada vez pueda hablar con más hacer un compendio de las técnicas de hacking
soltura, sin pensar en todo momento si los que utilizan ip-spoofing, para ir explicándolas
lectores conocerán tal cosa a la que hago con ejemplos concretos.
referencia. Mis referencias son cada vez más
a artículos ya escritos, más que a cosas A pesar de lo específico del tema del artículo,
totalmente desconocidas para vosotros. Esto me ha faltado espacio para explicar con mucho
me da muchísima más libertad para centrarme más detalle muchas cosas, pero siempre debéis
en temas más específicos, y este artículo es considerar esta revista como un punto de
buena prueba de ello. partida para vuestro estudio personal, con el
gran maestro Google, y con vuestra propia
Difícilmente habría podido escribir este artículo
experimentación, que es absolutamente
sin asumir que partís ya de una base bastante
fundamental.
sólida.
Una vez más he de insistir en que los que

Quizá os parezca que abuso un poco de
busquen un tutorial sobre cómo destruir una
vosotros, ya que para poder seguir este artículo
máquina escribiendo un comando o ejecutando
enterándose de todo no sólo es imprescindible
una aplicación llena de ventanitas y dibujitos,
haber seguido mi curso de TCP/IP, si no
que también asumo que habéis seguido el que no pierdan el tiempo leyendo mi artículo.
resto de la revista.
Lo que aquí se explica no sólo en muchos
Para seguir este artículo es necesario que casos ni siquiera tendrá aplicación práctica,
hayáis seguido el imprescindible curso de si no que además todo el enfoque del artículo
Linux de la revista (ya que centro en Linux no es desde un punto de vista práctico, si no
mis ejemplos), así como el magnífico curso orientado a aquellos que, como yo, disfrutan
de diseño de firewalls (basado en iptables), conociendo el funcionamiento de las cosas,
y otros artículos, como los que hablaban del incluso aunque sean cosas que ya han quedado
uso de exploits. obsoletas.

Curso de TCP - Fragmentación De Los DATAGRAMAS
1. ¿Es deseable la fragmentación

RFCs. Traducir un RFC del Ingles al castellano es una tarea
de datagramas?
larga y compleja, pero hacerlo con la pulcritud que ellos lo hacen
es merecedor de nuestros mejores halagos.
La respuesta a la pregunta que planteo aquí
es sencilla: no, no es deseable la
Si algún lector desea colaborar con ellos en su gran proyecto,
fragmentación.
seguro que sois recibidos con los brazos abiertos.
La fragmentación da la oportunidad a un
Pero, igual que quedamos en que íbamos a
hacker de llevar a cabo un gran número de
tratar de comprender todo el RFC, también
ataques, como ataques DoS, o técnicas para
tenéis que recordar que lo que nos diferencia
saltarse la protección de un firewall o un
a nosotros del resto de los usuarios de
IDS.
ordenadores son precisamente estas cosas.
Para comprender todo esto, voy a dividir el

Un usuario considera el ordenador una
artículo en tres partes:
herramienta. No tiene ningún interés en
cómo funcione por dentro, y cuanto más
E n p r i m e r l u g a r, e s p e c i f i c a r é
masticado le dé todo el ordenador, mucho
detalladamente los algoritmos utilizados
mejor para él.
para fragmentar y reensamblar
datagramas.
En cambio, para nosotros... esta bien, digamos
En segundo lugar, presentaré algunas
para un hacker, el ordenador no es sólo una
técnicas utilizadas para aprovechar el
herramienta para conseguir algo que nos
mecanismo de fragmentación en un ataque.
interesa, si no que el propio ordenador nos
Por último, explicaré como configurar resulta interesante. Por tanto, lo que nos
un sistema para evitar la fragmentación diferencia es que mientras que los usuarios
y, por tanto, cerrar la posibilidad de sufrir comunes intentan abstraerse lo máximo posible
este tipo de ataques. del funcionamiento interno de la máquina,
nosotros al contrario buscamos conocer cada
2. Algoritmos de fragmentación vez con más detalle este funcionamiento.
y reensamblado
Así que, una vez explicado a grandes rasgos
En el RFC 791 se explica en detalle un 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
algoritmo para la fragmentación de datagramas, nuestras mentes inquietas no se
datagramas, y otro para su reensamblado. Si conformarán con eso, y buscarán ávidamente
habéis ojeado el RFC, estoy seguro de que la cada vez más detalle. Este detalle es el que
mayoría de vosotros habréis pasado ese punto nos da el RFC, y más abajo no podemos llegar,
al encontrar un montón de letras raras que ya que especifica detalladamente un algoritmo
n o o s i n t e r e s a b a n l o m á s m í n i m o. que puede ser implementado directamente
por cualquier programador.
Por tanto, vamos a tratar de comprender estos
algoritmos.
! Para los nuevos...
2.1. Algoritmo de fragmentación
Para los nuevos lectores (y perdonen los curtidos veteranos por de datagramas del RFC 791.
repetir una vez más esta nota en cada número de la revista)
informarles que en la Web www.rfc-es.org tienen a su disposición
Pero antes de nada... ¿hay alguien aquí que
el RFC 791 en perfecto castellano.
no sepa lo que es un algoritmo?
Una vez más agradecemos a todos los colaboradores de www.rfc-

Si es así, no os asustéis, que no tiene nada
es.org la aportación desinteresada de las traducciones de los
que ver con las matemáticas (uno de los

errores más comunes de la gente no Paso 5

acostumbrada a tratar con estos términos es --> Si viene algún coche por la derecha,
confundir la palabra algoritmo con logaritmo). entonces pasamos al Paso 7.
--> Si no viene ningún coche por la derecha,
Un algoritmo es simplemente la explicación entonces continuamos por el Paso 6.
detallada de una forma de resolver un
problema. Paso 6: Podemos cruzar la calle. FIN.
Por ejemplo, vamos a ver un algoritmo sencillo Paso 7: Miramos a la derecha. La diferencia
que tenemos todos implementados en nuestro de este paso con el 4, es que como aquí
cerebro, y lo usamos a diario: el algoritmo permaneceremos un tiempo mirando a la
para cruzar una calle. derecha, durante este tiempo podría volver a
haber coches en el lado izquierdo, por lo que
Un algoritmo suele venir detallado por una antes de cruzar tendremos que volver a
serie de pasos secuenciales. Se empieza en comprobar este lado, tal y como veremos
un primer paso, en el que se llevan a cabo ahora mismo.
unas acciones. Cuando se termina este paso
se sigue en el paso siguiente, y así Paso 8:
sucesivamente. --> Si no viene ningún coche por la derecha,
entonces volvemos al Paso 2.
En algunos pasos puede haber saltos que te --> Si viene algún coche por la derecha,
lleven atrás a un paso que ya hicimos entonces volvemos al Paso 7.
anteriormente, o bien adelante, saltándonos
así varios pasos que no es necesario que No creo que haya ninguna duda sobre el
llevemos a cabo por los motivos que sean. funcionamiento de este algoritmo, ya que
todos lo utilizamos casi inconscientemente.
En cada paso puede haber acciones a realizar, Un programador se tiene que encontrar
o bien preguntas a responder acerca del constantemente con este problema de
estado del problema. Las respuestas a estas racionalizar y detallar en un algoritmo muchas
preguntas nos llevarán por un camino u otro cosas que hacemos de forma inconsciente sin
dentro del algoritmo, moviéndonos de un reparar en la complejidad de lo que estamos
paso a otro no siempre de forma secuencial, haciendo.
hasta que lleguemos a algún paso que termine
el algoritmo (un paso de FIN). Por supuesto, este algoritmo para cruzar una
calle es muy simple, y el que utilizamos
Veamos, por tanto, el algoritmo que utilizamos nosotros realmente es mucho más complejo.
nosotros para cruzar la calle: Nuestro cerebro tiene en cuenta mil factores
más: que la calle sea de doble o único sentido,
Paso 1: Buscamos un paso de peatones y
que haya semáforos, que los coches estén
nos acercamos a él, situándonos en el borde
atascados, etc, etc.
de la acera.
Ahora que ya comprendemos el mecanismo
Paso 2: Miramos a la izquierda. básico de un algoritmo, podemos enfrentarnos
al algoritmo de fragmentación planteado
Paso 3: en el RFC.
--> Si viene algún coche por la izquierda,
entonces volvemos al Paso 2. Para ello, en primer lugar tenemos que dar
-->Si no viene ningún coche por la izquierda, nombres a una serie de variables que se van
entonces continuamos por el Paso 4. a utilizar en el algoritmo.
TL Longitud total del datagrama (antes de

Paso 4: Miramos a la derecha.
ser fragmentado). [Total Length]

MTU Más adelante hablaremos mucho más Vamos a ver ahora el algoritmo detallado. Os
sobre la MTU. La MTU es el tamaño máximo recomiendo que según lo voy explicando
que puede tener un datagrama según la vayáis siguiendo cada paso del algoritmo tal
tecnología de la red que va a tener que
y como viene en el RFC (bastante más
atravesar en su próximo paso. [Maximum
ofuscado de lo que lo explicaré yo aquí), para
Transmission Unit]
que os acostumbréis a la notación utilizada
DF Flag de la cabecera IP que obliga a que en los RFCs.
un datagrama no pueda ser fragmentado.
[Dont Fragment] El algoritmo del RFC muestra sólo el caso más
simple, de un datagrama que se divida en
IHL Campo de la cabecera IP que especifica
sólo dos fragmentos.
el tamaño de esta cabecera. A lo largo del
algoritmo, se referirá en unos momentos al
IHL del datagrama original, o al IHL del Empecemos viendo el primer paso, que
fragmento, tal y como veremos. [Internet llamaremos Paso 0 para que se correspondan
Header Length] el resto de pasos con los del RFC:
OIHL Variable de uso auxiliar, que nos Paso 0 Si TL es menor o igual que la MTU,
permite recordar el tamaño de la cabecera entonces el datagrama cabrá por la red y no
IP que tenía el datagrama antes de ser habrá que fragmentarlo. FIN.
fragmentado. [Old Internet Header Length]
En el caso contrario (TL > MTU), entonces
OTL Variable de uso auxiliar, que nos tenemos que comprobar el flag DF.
permite recordar el tamaño total del
Si el flag DF está activo, no podemos
datagrama antes de ser fragmentado. [Old
Total Length] fragmentar, por lo que tenemos que descartar
este datagrama, y enviar un ICMP para notificar
FO Campo de la cabecera IP Fragment el problema. FIN.
Offset, que nos permite saber qué posición
ocupa un fragmento dentro del datagrama
Si el flag DF no está activo, entonces podemos
original. [Fragment Offset]
continuar por el Paso 1.
OFO Variable de uso auxiliar, que nos

permite recordar el Fragment Offset del Este paso, tal y como está escrito, es como
datagrama antes de ser fragmentado. [Old solemos hablar nosotros informalmente. Pero
Fragment Offset] esta no es una buena forma de detallar un
algoritmo, ya que se presta a muchas
MF Flag de la cabecera IP que indica que
ambigüedades.
este fragmento no es el último, y aún han de
venir más fragmentos del mismo datagrama.
[More Fragments] Una forma mucho más correcta es utilizar
ciertas estructuras bien conocidas para detallar
OMF Variable de uso auxiliar, que nos la secuencia que siguen los pasos del
permite recordar el flag MF del datagrama algoritmo. La estructura más simple para
antes de ser fragmentado. [Old More
detallar el flujo del algoritmo es el IF THEN,
Fragments]
ELSE THEN. Lo traduciremos por SI
NFB Número de bloques de datos de los ENTONCES, SI NO ENTONCES. Vamos a

que se compone un fragmento. [Number of ver este mismo paso, pero detallado con esta
Fragment Blocks] estructura:

Paso 0 Paso 2
SI TL es menor o igual que la MTU ENTONCES
El datagrama cabrá por la red y no Damos valor a las variables auxiliares, ya que
habrá que fragmentarlo. necesitamos seguir conociendo los datos del
FIN. datagrama original, pero tenemos que
SI NO, ENTONCES modificar las variables TL, IHL, FO, y MF para
Comprobar el flag DF. nuestro nuevo fragmento.
SI el flag DF está activo ENTONCES
OIHL = IHL.
No podemos fragmentar.
OTL = TL.
Descartar el datagrama.
OFO = FO
Enviar un ICMP para notificar OMF = MF
el problema.
FIN. Paso 3
SI NO, ENTONCES
NFB = (MTU IHL x 4) / 8.
Continuar por el Paso 1.
Calculamos el tamaño de los datos del
fragmento. El tamaño máximo para todo el
¿Verdad que esto es mucho más claro una
datagrama está determinado por la MTU.
vez que nos acostumbramos a leerlo así?
Como, además de los datos, hay que incluir
la cabecera, el tamaño de los datos estará en
Además, tal y como está escrito esto, se
función de la MTU y del tamaño de la cabecera
puede escribir de forma casi directa en (IHL).
cualquier lenguaje de programación, por lo
que facilitamos mucho el trabajo a los Paso 4-
programadores que tengan que implementar
este algoritmo en una máquina. Añadir al fragmento NFB x 8 bytes de datos.
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 : Ahora ya no sólo tenemos la cabecera del

fragmento, si no también los datos, que son
Paso 0 solo una porción de todos los datos que había
en el datagrama original.
SI TL es menor o igual que la MTU ENTONCES
Paso 5-
El datagrama cabrá por la red y no
habrá que fragmentarlo.
Ahora que ya está el fragmento casi construido,
FIN.
sólo nos queda modificar la cabecera para que
SI NO ENTONCES
se vea claramente que es el primer fragmento.
Comprobar el flag DF.
SI el flag DF está activo ENTONCES
Activamos el flag MF.
No podemos fragmentar.
Descartar el datagrama. TL = (IHL x 4) + (NFB x 8).
Enviar un ICMP para notificar
el problema. Calculamos un checksum para este fragmento,
FIN. una vez modificada la cabecera.
SI NO ENTONCES
Continuar por el Paso 1. Como en OTL hemos guardado la longitud
total del datagrama original, podemos
Paso 1 sobrescribir el valor de la variable TL sin perder
ese dato, que más adelante nos hará falta. El
Copia toda la cabecera IP al primer fragmento nuevo TL (para este fragmento) se calcula en
que vamos a crear. función de la cabecera (IHL) y de los datos
(NFB).

Paso 6 cabeceras. Por supuesto, si sólo hay dos

fragmentos, el tamaño del segundo fragmento
El primer fragmento ya está listo, y se envía será el tamaño del original sin fragmentar
al nivel de enlace. Continuamos ahora con el menos el tamaño del primer fragmento.
segundo fragmento. Con respecto a FO, es evidente que, ya que
el FO del primer fragmento era 0, el del
Paso 7 segundo dependerá únicamente de NFB, que
es lo que ocupaban los datos del primer
Copiamos la cabecera del datagrama original fragmento.
al nuevo fragmento. Habrá que revisar el
campo Opciones de la cabecera IP, para ver Por último, el flag MF estará activo sólo si el
cuáles de las opciones tendrán que ser propio datagrama original sin fragmentar era
copiadas a todos los fragmentos. Por tanto, ya un fragmento de alguna fragmentación
la cabecera del fragmento podría ser más anterior.
pequeña que la del datagrama original, al no
tener copia de todas las opciones.
Paso 10
Paso 8
El fragmento ya está listo, y lo podemos enviar
Como este algoritmo sólo explica como dividir a la capa de enlace para que lo procese. FIN.
en 2 fragmentos, asumimos que éste es el
último, por lo que añadimos después de la Bueno, bueno, bueno... Os dije que esto no
cabecera todos los datos que faltaban (los iba a ser fácil.
que había en el datagrama original a partir
de la posición NFB x 8). Pero llevamos ya el suficiente tiempo dando
caña a los protocolos como para que os pueda
Paso 9 exigir ya a estas alturas que os lo curréis bien
y analicéis paso a paso el algoritmo para
Ahora ajustamos varios campos de la cabecera
comprenderlo. Es difícil darlo ya más masticado
del fragmento, en 5 pasos:
de lo que os lo he dado yo, así que mucho
más no puedo hacer. Lo que es complicado,
IHL = ((OIHL x 4) L + 3) / 4.
TL = OTL (NFB x 8) ((OIHL IHL) x 4). es complicado.
FO = OFO + NFB.
MF = OMF. 2.2. Algoritmo de reensamblado
de datagramas del RFC 791.
Calculamos el checksum. Vaya formulitas,
¿eh?
Este algoritmo es bastante más denso y
complicado de entender, así que en este caso
En primer lugar, vemos que el IHL del nuevo
es casi mejor contar con la descripción general
fragmento, como dijimos, podría ser menor
del algoritmo que viene en el RFC antes de
que el del datagrama original, porque podría
detallar sus pasos.
haber opciones que no se han copiado. La
variable L que he puesto en la fórmula es la
Esta descripción nos aclara algunos detalles
longitud de las opciones que no han sido
que quizá nos quedaban como lagunas hasta
copiadas en el fragmento.
ahora. Por ejemplo, el mecanismo para
diferenciar un datagrama fragmentado
En el caso del TL del fragmento, lo obtenemos
de uno no fragmentado, es que los no
a partir del TL del datagrama original,
fragmentados siempre tendrán su FO
restándole todo lo que ocupaba el primer
(Fragment Offset) a 0, y al mismo tiempo el
fragmento, y la diferencia del tamaño de las
flag MF (More Fragments) a 0 también.

Si, en cambio, su FO no fuese 0, pero sí el componiendo los datos que forman el

MF, entonces sabríamos que se trata del datagrama según nos van llegando en
último fragmento. Si el FO si fuese 0, pero desorden. El buffer será como una mesa vacía
el MF no, entonces tendríamos el primer sobre la que iremos colocando las piezas de
fragmento. Por último, si ni el FO ni el MF un puzzle según las vayamos sacando de la
son 0, entonces se trataría de un fragmento caja.
intermedio (ni el primero ni el último).
Resumo todo esto en una tabla: En realidad no se trata sólo de un buffer, si
no de dos: uno para los datos, y otro para la
cabecera. Aparte de los buffers, se crea
también una tabla vacía donde se van
marcando los fragmentos según se van
recibiendo (una tabla que simplemente
contiene un bit por cada fragmento,
marcando a 1 los que vayan llegando).
Sabiendo esto, lo primero que se hace cuando 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
se recibe un datagrama es comprobar estos
inicializamos a cero, que es el Total Data
dos campos. Si FO y MF están a cero,
Length, que ahora veremos en qué consiste.
entonces no se trata de un fragmento, y no
Por último, tenemos un temporizador que
hay que reensamblar.
nos servirá para no permanecer eternamente
En cambio, si alguno de los dos no es cero, esperando fragmentos que se hayan podido
tenemos que ver a qué datagrama perder por el camino.
corresponde ese fragmento. Ya sabemos que
los datagramas se identifican por los campos Si el temporizador llega al fin de su cuenta y
de la cabecera IP: dirección IP de origen, no se han recibido todos los fragmentos,
dirección IP de destino, protocolo, e entonces habrá que descartar el datagrama
identificador. A partir de estos datos, 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 .
identificamos el datagrama.
Vamos a ver un ejemplo de como se va
Ahora se nos pueden dar dos situaciones:
reensamblando un datagrama.
que sea el primer fragmento que nos llega
de ese datagrama, o que antes ya nos
En primer lugar, recibimos un fragmento con
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 Offset 3000. Nosotros aún no lo sabemos,
LLEGAR, que no tiene por que ser el primer pero éste será el tercero de los fragmentos
fragmento de los que componen el datagrama. que componen el datagrama.
Los fragmentos pueden llegar al destino en
cualquier orden, por diversos motivos. No Lo que sí que sabemos es que es un
siempre el primero que recibimos es el que fragmento intermedio, ya que su bit MF
tiene FO = 0, y MF = 1 (es decir, el primer está activado, y su Offset es mayor que 0.
fragmento que compone el datagrama
original).
En el caso de que sea el primer fragmento

QUE NOS LLEGA, tendremos que reservar
recursos en nuestra máquina 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

En esta imagen podemos ver cómo la Fijándonos en la Longitud de este segundo

recepción del datagrama, al ser el primero fragmento, vemos que mide 1500 bytes, por
EN LLEGAR que tenga esa identificación (es lo que encaja en nuestro puzzle
decir, esa combinación de ip de origen, ip
perfectamente pegado justo a la izquierda
de destino, protocolo, e identificador),
del fragmento que recibimos antes.
causa la creación de una serie de recursos.
Arriba a la derecha podemos ver la tabla

binaria en la que se van marcando los
fragmentos según van llegando. A priori no
sabemos el tamaño que tendrá esa tabla, ya
que no sabemos cuántos fragmentos habrá,
pero lo que sí que sabemos es que en el
momento en que todas las posiciones de la
tabla estén a 1, el datagrama estará completo.
Lo que sí que sabemos es que, al ser un

fragmento intermedio, como mínimo tiene
que haber un fragmento a su izquierda, y Este fragmento modifica la tabla, añadiendo
otro a su derecha, por lo que podemos crear un 1 en una posición intermedia, quedando
3 posiciones en la tabla, de las cuales sólo ahora la tabla con 4 casillas. Además, añade
está ocupada la intermedia. una nueva pieza al puzzle.
Debajo de la tabla tenemos la variable Total

Ahora nos llega un fragmento con Offset
Data Length, cuyo valor de momento
4500, y con el flag MF a 0. Esto significa
desconocemos, así que la inicializamos a 0,
o con cualquier valor. que es el último fragmento. Como la
Longitud del primer fragmento que nos llegó
Debajo tenemos el temporizador, cuya era de 1500 bytes, al sumar su offset y
cuenta se pone en marcha para no quedarnos su longitud tenemos: 3000 + 1500 = 4500,
esperando eternamente el resto del que coincide con el Offset de este último
datagrama. fragmento. Por tanto, el último fragmento
está en nuestro puzzle justo a la derecha
Por última, debajo tenemos la mesa marrón
del primer fragmento que nos llegó.
sobre la que iremos construyendo el puzzle.
No sabemos de antemano qué tamaño tendrá,
así que procuramos hacerla bastante grande
para que nos quepan todas las piezas. Esta
mesa es el buffer de recepción.
La primera pieza del puzzle se saca de los

datos del fragmento que acabamos de recibir.
A continuación, 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 tratándose
de un fragmento intermedio. Por supuesto, Nuestra nueva tabla ya no tendrá hueco por
el flag MF tiene que estar activado por narices,
la derecha, por lo que sólo nos falta rellenar
ya que el fragmento que habíamos recibido
los fragmentos que nos falten por la izquierda.
previamente está a continuación de éste.

La variable Total Data Length ahora puede Una de las grandes ventajas es que el algoritmo
ser calculada. Cogemos el Offset de nuestro de reensamblado del RFC 815 consume menos
fragmento, y le sumamos su Longitud. En recursos, lo cual veremos más adelante que
este ejemplo la Longitud de este último puede suponernos una ayuda contra ciertos
fragmento es de 350 bytes, por lo que: 4500 tipos de ataques, aunque en cualquier caso si
+ 350 = 4850 bytes. se proponen hacernos un DoS con alguna de
las técnicas que explicaremos, de poco nos
Además, hemos podido reducir el tamaño de va a servir ahorrarnos unos cuantos bytes en
la mesa del puzzle, ya que sabemos que no los buffers...
vamos a necesitar más espacio a la derecha.
Os dejo como ejercicio empollaros este RFC,
Ahora nos llega un fragmento más. Su Offset que es muy cortito, a ver si conseguís
es 0, y su Longitud es 1500 bytes. Por comprender más o menos los algoritmos que
supuesto, el flag MF está activado. Sin lugar explica.
a dudas se trata del primer fragmento y,
además, al sumar su Offset y su Longitud, 3. Problemas de seguridad de la
nos damos cuenta de que ya no faltan más fragmentación de datagramas.
fragmentos, ya que encaja perfectamente
en el puzzle a la izquierda del que ahora
Llegamos ya a la parte más divertida.
ya sabemos que es el segundo fragmento.
Los ataques que aprovechan la fragmentación
IP han estado siempre muy extendidos, y esto
ha dado lugar incluso a la aparición de un par
de RFCs tratando exclusivamente este
problema.
El RFC que trata algunos de estos problemas

de forma más general es el RFC 1858. El
RFC 3128 trata sobre una técnica concreta
de explotación, y la protección contra la misma,
ampliando así la información del RFC 1858.
Como vemos, la tabla ha sido ya completada.
Pero no nos podemos conformar con la
El puzzle está completo con todas sus piezas. información contenida en estos RFCs, ya que
no todos los posibles ataques de fragmentación
El temporizador no ha vencido en el tiempo existentes están detallados en estos
que hemos tardado en recomponer el documentos. De hecho, algunos de los más
datagrama original. conocidos, como el Ping of Death, o el
Teardrop no son mencionados en ningún
Como resultado, podemos sacar del puzzle documento RFC (o al menos que yo sepa).
el datagrama original, ya listo para ser
A grandes rasgos, los ataques que explotan
procesado como cualquier otro datagrama.
la fragmentación se pueden dividir en dos
grupos: ataques DoS, y ataques para atravesar
2.3. Algoritmos de fragmentación firewalls.
y reensamblado del RFC 815.
3.1. Ataques DoS
En el RFC 815 (ftp://ftp.rfc-editor.org/in-
Estos son los ataques que considero más
notes/rfc815.txt) hay detallados unos
fáciles de comprender en principio.
algoritmos alternativos que simplifican
bastante los algoritmos del RFC 791. Los algoritmos de reensamblaje de
fragmentos especificados en los RFCs 791 y

815 son propensos a gran cantidad de y con eso: hop! la máquina 80.12.1.4 quedaba
problemas ya que, como ocurre con la mayoría petada.
de los protocolos básicos de Internet, fueron
pensados para situaciones de buena fe, donde Dependiendo del sistema operativo de la
todo funciona como debería. víctima, la máquina podía reiniciarse, colgarse,
o, sólo en los casos más raros, salir indemne
Por tanto, no se tienen en cuenta muchas (la mayoría de los sistemas operativos eran
situaciones anómalas, como valores imposibles vulnerables).
para los offsets de los fragmentos, flujos de
datagramas incompletos, o fragmentos que La opción -l en el comando ping de Windows
forman datagramas demasiado grandes. sirve para especificar la longitud del campo
DATOS del mensaje ICMP Echo Request
Vamos a ver en detalle algunas de las técnicas que enviará el ping. Los pings normales (el
DoS que permiten explotar este exceso de valor por defecto) envían tan sólo 64 bytes
confianza de los algoritmos de reensamblado. de datos. Con esta opción -l le estamos
Los sistemas operativos modernos están diciendo que envíe 65510 bytes de datos
protegidos contra muchas de estas técnicas, por cada ping. Cualquier valor igual o mayor
pero aún siguen quedando servidores sin que 65510 puede servir para llevar a cabo el
actualizar que pueden ser vulnerables. En DoS. Más adelante veremos por qué esto
cualquier caso, siempre es interesante conocer causa un problema.
todo lo que se puede hacer gracias a un
algoritmo mal diseñado. En el caso de Linux, la longitud del campo
de datos se especifica con la opción -s, pero
Estad preparados, porque aquí hay mucha en este caso está limitado a un máximo de
chicha. 65507 bytes, lo cual no permite llevar acabo
este ataque (si, esos 3 bytes son
3.1.1. Ping of Death 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 ) .
Este ataque, el ping de la muerte, fue muy Hoy día dudo que queden muchas máquinas
popular cuando fue descubierto en 1996. conectadas que todavía sean vulnerables al
Ping of Death, pero me parece un ejemplo
Durante un par de años fue el paraíso sobre muy didáctico de en qué puede consistir un
todo para los scriptkiddies (o lamers, para ataque DoS que explote la fragmentación IP.
que nos entendamos) que encontraron una
forma universal de destruir cualquier Vamos a ver paso a paso qué es lo que pasa
máquina con sólo escribir un simple comando. con un ICMP Echo Request que contenga
65510 bytes de datos. Para ello os
Este comando se podía escribir directamente recomiendo que reviséis el artículo anterior
desde Windows 95 o Windows NT, que (que trataba sobre la cabecera IP), así como
eran los sistemas operativos de Microsoft que el artículo sobre ICMP de este mismo curso.
había en el momento, sin necesidad ni siquiera
de instalar ninguna aplicación para explotar En primer lugar, vamos a calcular el tamaño
el ataque. En cambio, para los usuarios de total de este paquete.
Linux era necesario compilar un pequeño
código. La cabecera del mensaje ICMP Echo
Request son 8 bytes (como vimos en el
Si un usuario de Windows 95/NT quería petar artículo sobre ICMP), mientras que la
a un tío cuya ip fuese 80.12.1.4, sólo tenía cabecera IP sin opciones es de 20 bytes.
que escribir en una ventana MS-DOS: Por tantos, si sumamos estos 28 bytes de
cabeceras a los 65510 bytes del campo de
ping -l 65510 80.12.1.4 datos, tenemos un total de 65538 bytes.

¿Por qué el ping de algunos sistemas De momento, ningún problema: cada paquete
operativos como Linux no permiten hacer es correcto por separado. Pero el problema
este ping? Pues porque, si recordamos del viene cuando el sistema trata de reensamblar
artículo anterior el campo Total Length de estos dos fragmentos. Al unir los fragmentos
la cabecera IP, sabremos que este campo el sistema ha de computar el tamaño del
especifica con sólo 16 bits el tamaño del datagrama original (el Total Length). Para
datagrama, por lo que el tamaño máximo de ello se hace una suma de 16 bits de los
un datagrama tendría que ser 65536 bytes. tamaños de cada fragmento. El resultado de
Precisamente en este punto es donde está la esta suma en este caso sería 32768 + 32770
clave del ataque. = 65538, lo cual se sale del rango de la suma,
que estaba limitada a 16 bits.
Sólo hay una forma en la que este datagrama
puede enviarse, ya que el campo Total Esta suma fuera de rango no estaba prevista
Length de la cabecera IP no da más de si. por el sistema operativo y, por tanto, producirá
El único medio es fragmentar el datagrama, resultados inesperados que, en la mayoría de
y ajustar de forma adecuada el tamaño de los casos, daban lugar a que el sistema se
cada fragmento. colgase, o bien se reiniciase.
En el caso más sencillo, el datagrama sería ¿Por qué se utilizaba precisamente un ping
fragmentado en dos de la siguiente forma: 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 conexión, por
lo que no es necesaria ninguna información
para colarse en una conexión como podría ser
el caso de TCP. El hecho de no tener que
colarse en una conexión nos da la gran ventaja
de que podemos enviar el ataque sin
preocuparnos de tener que recibir ninguna
Estos fragmentos siguen siendo demasiado respuesta. Al no tener que esperar respuestas,
grandes para pasar por cualquier red, por lo podemos perfectamente enviar el ataque con
que sin duda serían fragmentados a su vez un IP-Spoofing, tal y como veremos en el
para ajustarse a la MTU de la red por la que próximo artículo, en el cual entraremos en
tuviesen que circular. Pero esto lo vamos a todo detalle en las técnicas de IP-Spoofing.
obviar, por lo que supondremos que lo que Esto permitía realizar el ataque de forma
llega a la víctima son directamente estos dos totalmente anónima.
paquetes (para simplificar mucho el ejemplo).
La otra ventaja de utilizar el ping es que,
El sistema operativo de la víctima recibirá el hasta el momento en que surgieron este tipo
primer fragmento, con Offset 0, tamaño de de ataques, prácticamente ningún firewall
paquete (TL) de 32768 bytes, y el flag MF filtraba los mensajes ICMP Echo Request,
activado. A continuación (aunque no tendrían al considerarlos totalmente inofensivos.
por qué llegar necesariamente en este orden,
como ya sabemos) recibirá el segundo Después de la aparición de estos ataques
paquete, con Offset 32768, tamaño de basados en el ping, la mayoría de los firewalls
paquete de 32770 bytes, y el flag MF empezaron a filtrar los mensajes ICMP Echo
desactivado (ya que es el último fragmento). Request. Esto fue una medida de defensa

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.
¿Cómo puede ser entonces que hoy día la inmensa mayoría de los sistemas sean inmunes a este tipo de
ataques, si no se pueden evitar filtrando el ping en un firewall?
Pues sencillamente, la solución al problema se implementó en el propio sistema operativo. Salieron parches
para los sistemas existentes en el momento, y además todos los sistemas que se hicieron después eran
ya inmunes de fábrica, es decir, tenían prevista la situación de que un datagrama pudiese medir más 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 sólo nos tenemos que resignar a confiar en lo que haga nuestro sistema operativo,
si no que también podemos nosotros tomar parte activa en la protección de nuestra máquina ante estos
ataques.
A la hora de implementar protecciones en nuestro firewall contra ataques específicos 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 habéis seguido el curso de implementación de firewalls de la revista, sabréis que estas líneas 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 líneas es limitar a que sólo
podamos recibir un máximo 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 protección contra el POD, nada más lejos de la
realidad. Lo único que hacen es evitar un flood de pings, que podría ser resultado de algún 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 solución
para nuestro problema, o si más bien el tío que lo escribió (probablemente con toda su buena fe) no tenía
mucha idea de en qué consiste realmente el ataque.
Seguramente alguno de vosotros en este punto habrá pensado que, si bien esa protección no sirve contra
el POD, si que podría servir contra un ataque Smurf, que consiste precisamente en un flood de pings
(tal y como expliqué en el artículo sobre ICMP).
Pues para todos los que hayáis pensado eso, os pongo un punto positivo, ya que demuestra que habéis
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 están equivocados, ya que falla un pequeño detalle. El ataque smurf,

en efecto, se lanza mediante pings, pero lo que la víctima 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í sería una protección 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 serviría 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 máquinas inocentes que respondan a los mensajes de ping a la dirección
broadcast de la red.
La solución a este problema es mejor implementarla a otro nivel, que no es el de las iptables, diciéndole directamente
a nuestro sistema operativo que ignore cualquier ICMP Echo Request que tenga como destino la dirección broadcast
de la red. Esto lo podemos hacer con la siguiente línea:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Esta línea la podemos incluir como parte de los scripts de arranque del sistema (los clásicos de /etc/rc.d), o bien en
el archivo /etc/sysctl.conf.
Pero no nos salgamos del tema, y pensemos cómo podemos protegernos contra el POD con iptables. Una solución
específica contra POD sería 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 ningún
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 añadir esta regla.
Como podemos suponer, esta regla no es lo suficientemente restrictiva, ya que si bien evitaría 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 pasarían
por el firewall.
Para evitar las variantes que utilicen otro tipo de mensajes ICMP podríamos ser menos específicos en la regla, y filtrar
cualquier ICMP fragmentado, ya que en general no existe ningún uso legal para ningún 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

Con esto aún no solucionaríamos el problema El flood consiste en tirar un sistema a base
de los ataques tipo POD que utilicen otros de saturar sus recursos por fuerza bruta,
protocolos distintos a ICMP. Por lógica mientras que el nuke consiste en explotar un
podríamos pensar que otros protocolos, como bug concreto de un sistema que no es capaz
TCP, que transportan protocolos de nivel de responder bien ante cierta situación.
superior que pueden llevar un gran flujo de
datos (como FTP), no podrían funcionar Por ejemplo, el POD es un claro ejemplo de
correctamente sin la fragmentación. nuke, en el cual con un sólo datagrama
podemos tirar un sistema. En cambio, el smurf
Por tanto, de momento dejamos aquí el tema, es un claro ejemplo de flood, en el cual se
y nos conformamos con haber encontrado tira el sistema a base de saturarlo con miles
una solución para que nuestro firewall filtre de ICMPs.
los ataques POD clásicos (con mensajes
Con respecto a jolt2 hubo ciertas discusiones
ICMP), y más adelante iremos viendo cómo
sobre si realmente era un nuke, o si en realidad
solucionar el problema con el resto de
era un simple flood, ya que el exploit que
protocolos. circulaba (jolt2.c, lo podéis buscar en Google)
enviaba paquetes a toda pastilla, tanto incluso
3.1.2.Jolt y jolt2
que saturaba la conexión del propio atacante.
Estos dos exploits explotan dos bugs En cambio, poco después circuló una nueva
diferentes, pero ambos relacionados con la versión de jolt2 (jolt2mod.c, también lo
fragmentación. podéis buscar) que ralentizaba el envío de
paquetes para no saturar la conexión del
Jolt es más antiguo, y os costará encontrar atacante.
alguna máquina vulnerable hoy día, pero
Cada vez que hablo de un tema diferente me
Jolt2 se supone que puede tirar a varios
gusta contarlo de una forma diferente, así que
sistemas, incluido Windows 2000.
os voy a hablar en primer lugar de los
retoques que he tenido que hacer al código
No hay mucho que explicar sobre estos
fuente de ambos exploits.
exploits, ya que lo que hacen simplemente
es enviar una serie de paquetes fragmentados En primer lugar, al tratar de compilar el código
que muchos sistemas operativos no saben de Jolt (jolt.c, lo podéis buscar también),
cómo tratar y, por tanto, pueden colgar el con:
sistema.
gcc jolt.c -o jolt
¿Y por qué no hay mucho que contar? Pues
Descubro que no compila, ya que da un error
porque son unas técnicas más empíricas que
con un campo de una estructura que no existe.
lógicas. Al menos hasta donde yo he podido
Así que edité el código:
documentarme, no he encontrado ninguna
explicación convincente de por qué estos
vi jolt.c
paquetes pueden colgar un sistema. De hecho,
lo que sí que he encontrado han sido
Y busqué cualquier referencia a ese campo,
discusiones en foros de seguridad sobre qué
y vi que aparecía una única vez, en una línea
hace o deja de hacer cada uno, y por qué lo
que sólo le daba un valor 0. Así que comenté
hace o lo deja de hacer.
esa línea (la metí entre /* y */), salvé el
archivo, y lo volví a compilar, esta vez sin
En cualquier caso, sea magia o sea ciencia,
problemas.
el caso es que ambos exploits han sido de
los más famosos en la historia de los nukes.
No os he dicho los pasos exactos para
Como ya conté en otro artículo, existen
proponeros que lo hagáis vosotros mismos
básicamente dos tipos de DoS: el flood y el
como ejercicio.
nuke.

Para usar el exploit sólo tenéis que decir la de esas líneas era nulo. Una vez corregido el
ip de destino y la de origen (permite ip- código es así como queda esa parte:
spoofing):
src_addr = host_to_ip(optarg);
./jolt ip.victima ip.spoofeada if (!src_addr)
quit("Bad source address given.");
Lo más probable es que esta técnica no os
break;
funcione, ya no sólo porque queden pocos
sistemas vulnerables, si no porque
Os dejo como ejercicio también que os las
probablemente ni siquiera pueda atravesar
apañéis vosotros para hacer esta corrección.
alguno de los routers que haya en la ruta, al
ser un paquete malformado que podría ser
Una vez corregido esto, vemos el mismo
rechazado.
problema. Los paquetes están malformados
y es probable que no puedan pasar por todos
Aún así, por si tenéis curiosidad, podéis
los routers. Si analizamos su funcionamiento
analizar con un sniffer lo que hace Jolt. Os
con un sniffer (o analizando el código fuente)
ahorro el trabajo si os cuento que simplemente
veremos que lo que hace es enviar una y otra
envía una serie de fragmentos solapados,
vez el mismo fragmento, con todos los campos
es decir, fragmentos en los que el campo
exactamente iguales. ¿Por qué esto puede
offset de un fragmento no se corresponde
tirar un Windows? Sinceramente, no tengo ni
con el total length del anterior fragmento.
Más adelante veremos usos mucho más idea; eso que se lo pregunten a Bill Gates.
interesantes para el solapamiento de
fragmentos. 3.1.3. Ataques de flood de
fragmentos
Con respecto a Jolt2, también tuve que hacer
una modificación al código fuente. En este Si vuestras mentes están despiertas
caso usé la variante jolt2mod.c. probablemente se os haya ocurrido pensar
que Jolt2 funciona porque cada vez que
Supuestamente, el exploit debería permitir Windows recibe un fragmento reserva unos
un ip-spoofing utilizando la opción -s, tal y recursos para ese paquete (como ya vimos
como podéis ver si después de compilarlo: antes), y al no recibir el resto de fragmentos
llega un momento en el que los recursos del
gcc jolt2mod.c -o jolt2mod sistema se agotan.
Lo ejecutáis, para que os muestre su Esta es una deducción muy buena, pero tiene
funcionamiento: un pequeño fallo, y es que el identificador
es el mismo para todos los fragmentos. Por
Bellatrix:/home/pyc/hackxcrack/ip3# ./jolt2mod tanto, cada fragmento nuevo no obligaría al
Usage: ./jolt2mod [-s src_addr] [-p port] dest_addr
sistema (en teoría) a reservar nuevos recursos.
Note: UDP used if a port is specified, otherwise ICMP
En cambio, si utilizamos diferentes

En cambio, al analizar el funcionamiento de
identificadores para cada fragmento, sí que
jolt2 con un sniffer (Ethereal, concretamente)
podríamos llegar a saturar los recursos de la
descubrí que hace caso omiso a la opción -
máquina, al hacer reservar buffers para cada
s. Revisando el código fuente descubrí que
nuevo fragmento, esperando todos ellos llegar
en una línea en la que debería poner src_addr
a completar el datagrama al que pertenecen.
ponía dst_addr, por lo que lo que se estaba
cambiando no era la ip de origen (para hacer
Esto es algo que fácilmente puede ocurrir
el ip-spoofing), si no la ip de destino. Como
con firewalls que ignoren los fragmentos,
la ip de destino (dst_addr) en cualquier caso
incluso de forma no intencionada.
se volvía a modificar más adelante, el efecto

Un comportamiento típico de un firewall ante ¿acaso es necesario eso? ¿Acaso no surgen

un datagrama fragmentado es analizar constantemente nuevos exploits para Windows,
únicamente el primer fragmento (que es del cual nadie tiene el código fuente?
donde se encuentran las cabeceras). En caso
de que ese primer fragmento sea rechazado En cambio, el hecho de tener el código fuente
por el firewall, el resto de fragmentos sí que disponible sí que favorece todo lo contrario:
atravesarán el firewall en cualquier caso. Por en el momento en que surja un problema,
tanto, a la máquina que haya detrás le llegarán cualquiera podrá buscar la causa, y darle un
todos los fragmentos excepto el primero. Esto remedio. No dependemos de las actualizaciones
provocará que la máquina reserve recursos mensuales de Microsoft (si es que a Microsoft
inútilmente para formar un datagrama que le sale de las narices corregir ese problema).
nunca llegará, ya que le falta el primer Nosotros mismos podemos corregirlo o, si no,
fragmento. cualquier usuario de la comunidad Linux que
amablemente lo haya corregido por nosotros
3.1.4. Teardrop y haya hecho esa solución pública. Una vez
más: GNU - 1, Microsoft 0.
Este exploit de tipo nuke utiliza también el
(igual que Jolt), pero en este caso sí que soy Bueno, pues volviendo al tema, vamos a
capaz de explicar mejor por qué funciona. razonar el funcionamiento del Teardrop.
Para ello, vamos a ver una captura de un
En mi defensa puedo decir que Jolt es un sniffer (Ethereal) tras lanzar el exploit.
exploit para Windows, y
como el código fuente
de windows no está
disponible, muchas veces
es imposible decir por qué
está fallando algo. En
cambio, Teardrop es un
exploit que afecta
también a Linux, cuyo
código fuente está
disponible para todo el
mundo. Por tanto, viendo
el código, si que podemos
decir por qué está
fallando algo.
Aquí llegamos a una

cuestión que se plantea
muchas veces a la hora
de discutir si es bueno o
no tener el código fuente
disponible. Un argumento
bastante irreflexivo consiste en decir
rápidamente: pero claro, si un hacker maligno Para ejecutar el exploit, primero tendremos
puede ver el código fuente, podrá entonces que compilar el código teardrop.c:
encontrar formas de atacar a ese sistema.
gcc teardrop.c -o teardrop
Pues sí, en efecto, revisando el código fuente Y a continuación lo lanzamos con:

de un sistema operativo puedes encontrar
problemas potenciales de seguridad, pero... ./teardrop ip.spoofeada ip.victima

Y vamos al sniffer a ver qué ha hecho. Repito 3.2. Saltando firewalls e IDSs.
una vez más que también se puede analizar
el comportamiento mirando el código fuente Vamos a ver aquí un problema de compromiso
en lugar del sniffer. a la hora de configurar nuestro firewall, ya
que muchas veces las soluciones contra los
Si lo analizamos vemos en primer lugar que
ataques DoS favorecen este otro tipo de
sólo son dos fragmentos (increíble poder
ataques, y viceversa. Aún así, en el último
tirar un sistema con sólo dos paquetitos), y
punto del artículo explicaré la que podría ser
que ambos pertenecen al mismo datagrama
una solución definitiva contra ambos tipos de
(mismas ips de origen y destino, ambos con
ataques.
protocolo udp, y ambos con el mismo
identificador). Este problema de seguridad es, en mi opinión,
mucho más serio y más interesante que el de
Lo que cambia entre los dos fragmentos son
los ataques DoS. De hecho, es esta cuestión
los campos Total Length y Offset, y aquí
la que dio lugar a la aparición de los RFCs
es donde está la clave.
1858 y 3128.
El primer fragmento tiene:
Un ataque DoS puede ser un complemento
Total Length = 56 bytes
para llevar a cabo un ataque más complejo,
Offset = 0 (flag MF activado)
como vimos por ejemplo en el caso del
El segundo fragmento tiene: envenenamiento DNS. En cambio, esta
Total Length = 24 técnica es ya una forma concreta de saltarse
Offset = 24 la seguridad de una red.
Como el segundo fragmento no tiene activado La técnica más conocida que explota esta
el flag MF, es de suponer que es el último vulnerabilidad es la conocida como Tiny
fragmento. El sistema operativo que recibe Fragment Attack. Personalmente, me parece
estos fragmentos tratará de computar el Total una de las formas más elegantes de explotar
Length del datagrama original sumando los las potencialidades de un protocolo.
campos Total Length y Offset del último
fragmento: 24 + 4 = 48 bytes. La idea básica del Tiny Fragment Attack (TFA)
consiste en hacer picar al firewall con un cebo
Esto da lugar a una situación imposible, ya falso, como un caballo de troya, para luego
que el primer fragmento tiene una longitud soltar a todo el ejército una vez que el firewall
mayor que la que supuestamente tiene el nos ha abierto sus puertas.
datagrama original (56 bytes). El código que
realiza el reensamblado del datagrama Un firewall clásico de filtrado de paquetes
encuentra aquí una situación en la que tiene funciona básicamente analizando ciertos
que reservar memoria para un número de campos de la cabecera de un paquete, y
bytes negativo. Este número negativo será comparándolos con sus reglas de filtrado. En
interpretado como un número positivo muy
caso de que haya una coincidencia, ese paquete
grande (por cómo son tratados los números
deberá ser rechazado o aceptado, según lo
negativos en variables en las que no son
que indique la regla.
esperados), por lo que el sistema trataría de
reservar demasiada memoria y, por tanto, se
Veamos como ejemplo una lista de reglas de
colgaría.
un firewall muy simple:
Estos cuelgues no ocurren cuando es una Iptables A FORWARD p tcp --destport 21 j ACCEPT
aplicación la que trata de reservar demasiada
Iptables A FORWARD p tcp j DROP
memoria, ya que el sistema operativo se
encarga de que esto no ocurra, pero cuando
Con estas dos líneas, en primer lugar
es el propio sistema operativo el que realiza
analizaríamos cualquier paquete TCP entrante
esta operación imposible, entonces no hay
para ver si el puerto de destino es el 21.
santo que nos proteja.

En caso afirmativo, lo aceptamos. En

cualquier otro caso, el paquete pasaría a la
segunda regla, que sencillamente rechaza
absolutamente todo paquete TCP que le
llegue.
Supongamos que queremos acceder al puerto

80 de la máquina que hay detrás del firewall.
Por supuesto, el firewall nos lo está impidiendo,
ya que sólo pasarán 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.
Podríamos pensar que una posible solución

para este problema podría 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 Pero es aquí donde nos damos cuenta de lo
del firewall (puerto de destino = 21), por que decía al principio de este punto, y es que
lo que podrá pasar las defensas el remedio podría ser peor que la enfermedad.
inocentemente. Por tanto, el firewall, todo
confiado, dejará pasar el resto de Si hacemos que el firewall se encargue del
fragmentos que componen este datagrama. reensamblado, y en lugar de un ataque TFA
estuviésemos recibiendo alguna de las muchas
Pero... ¿y si el segundo fragmento es de variantes de ataques DoS que explotan las
esta forma? : vulnerabilidades de los algoritmos de
reensamblado, el firewall podría quedar
DoSeado y, por tanto, denegar el servicio a
todas las máquinas de la red que estén
amparadas por él.
El RFC 1858 nos recomienda que impongamos

un valor mínimo para el campo Offset de
cualquier fragmento (excepto el valor 0, claro,
que sería 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 sólo de 2 de la cabecera TCP. Es decir, el primer
bytes, por lo que a la hora de reensamblar fragmento siempre debe contener, como
el supuesto datagrama original, los datos del mínimo, la cabecera completa TCP, y los
segundo fragmento se solaparán sobre los siguientes fragmentos sólo podrán contener
del primero : los datos del paquete.

En cualquier caso, si continuamos leyendo, script de iptables de 358 líneas, hace unos
encontraremos la que podría ser la solución años), aunque trataban el tema de los
universal para todos nuestros problemas. fragmentos, eran mucho menos restrictivas.
4. Cómo prescindir de la Como para escribir mis artículos no me basta

sólo con documentarme, si no que también
fragmentación, y que todo siga
recurro a la experimentación de todo lo que
funcionando.
explico, probé hace unos días a meter estas
dos líneas, y... ¡magia! todo sigue funcionando
Empecemos preguntándonos, ¿realmente
exactamente igual. No solo eso, si no que mis
debemos prescindir de la fragmentación?
iptables no han logeado ni un solo fragmento
(iptables -A FORWARD --fragment -j LOG
Pues ya hemos visto muchos motivos de
--log-prefix Fragmento: ), por lo que
seguridad por los que la fragmentación es
queda demostrado que en los días que han
poco deseable. Aunque la mayoría de las
estado activas esas reglas no he recibido ni
técnicas que he explicado estén prácticamente
un sólo datagrama fragmentado.
obsoletas hoy día, está claro que la
fragmentación da mucho juego para encontrar
Por supuesto, esto no me ha pillado de
nuevas formas de retorcer los protocolos
sorpresa, ya que conocía de antemano el tema
hasta conseguir que hagan lo que se supone
del que os voy a hablar ahora, pero sí que me
que no deberían hacer.
sorprendió un poco comprobar la importancia
que tiene realmente esta forma de evitar la
Por otra parte, el único motivo por el que la
fragmentación.
fragmentación no es deseable no es sólo la
seguridad. También es importante el consumo
He hecho pruebas bastante exhaustivas con
extra de recursos que supone tener que
ICMP y TCP, y todo funciona perfectamente.
gestionar la fragmentación, y sobre todo el
Lo que ya no he probado tanto ha sido el UDP,
reensamblado. Una máquina que tenga que
así que os invito a que probéis vosotros mismos
estar reensamblando datagramas tendrá un
los resultados. Por lo que os voy a explicar
aumento en su consumo de CPU y de
ahora, es posible que con UDP las cosas no
memoria, dos recursos que en muchas
funcionen tan bien, así que quizá deberíamos
máquinas valen como el oro, y hay que
cambiar esas 2 reglas tan radicales por estas
intentar optimizar al máximo.
(pongo solo las de FORWARD, para INPUT
podríamos copiarlas tal cual):
Después de todo lo que hemos visto, ¿a que
os dan ganas de meter estas líneas en las iptables -A FORWARD -p tcp --fragment -j DROP
iptables? iptables -A FORWARD -p icmp --fragment -j DROP
iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT --fragment -j DROP
¿Y esa última línea? ¿Se le ha pirado la pinza
iptables -A FORWARD --fragment -j DROP
al chaval con tanta iptable? Pues no, tranquilos,
que aún no me he vuelto loco.
Estas líneas rechazarían cualquier paquete
fragmentado, fuese de la naturaleza que
Esa última línea es necesaria para que funcione
fuese. Pero claro, ponemos eso, y lógicamente
la técnica que os voy a explicar a continuación
todo dejará de funcionar.... ¿o no?
que permite prescindir de la fragmentación
IP.
Para escribir este artículo he tenido que
documentarme mucho sobre el tema (como
PMTUD
es lógico), y en ningún sitio he leído que nadie
aconseje aplicar unas reglas tan radicales a
Posiblemente este título os suene ya de algo,
un firewall. De hecho, las reglas que tenía yo
ya que en el artículo sobre ICMP expliqué a
en mis propias iptables (cuando me curré mi

grandes rasgos en qué consiste el PMTUD máquina con la que queremos conectarnos.
(Path MTU Discovery). Una vez que la conocemos, serán los protocolos
de nivel superior los que se encarguen de
El PMTUD es un mecanismo relativamente dividir sus datos de forma conveniente, en
simple que permite encontrar el PMTU de lugar de dejar esa responsabilidad a la capa
una ruta entre dos máquinas. IP.
¿Y qué es el PMTU? Pues bueno, hasta el Pero, ¿es que los protocolos que están por
momento sabemos lo que es la MTU. La MTU encima de IP también dividen sus datos?
(Maximum Transmission Unit) es el tamaño
máximo de paquete que puede transportar ¡Pues claro! ¿Acaso pensáis que cuando
una red de una tecnología concreta (por queremos enviar un archivo de 650MBs (como
ejemplo, 1500 bytes para el caso de redes una ISO de un CD) lo que hace nuestra capa
Ethernet). TCP es enviar de golpe los 650MBs a la capa
IP para que ésta se apañe y los fragmente
El problema es que Internet es una red como pueda?
terriblemente heterogénea, donde conviven
todo tipo de tecnologías de red diferentes. Esta claro que la capa TCP también tiene sus
En el camino que puede haber entre dos limitaciones y no puede andar trasteando con
máquinas conectadas a Internet puede haber paquetes de cualquier tamaño. De hecho, algo
routers que interconecten tecnologías de lo sabemos acerca de esta limitación, pues ya
más variopintas. hablamos en este curso acerca de la opción
MSS (Maximum Segment Size) de la
Así, en el camino entre nuestro PC y un cabecera TCP. Precisamente en este campo
servidor web nos podemos encontrar MSS es donde se apoya el mecanismo de
fácilmente con que nuestros paquetes circulan PMTUD.
por redes Ethernet, PPPoE (tecnología utilizada
en ADSL), y muchas otras tecnologías Como ya vimos, la opción MSS se incluye sólo
diferentes. Cada una de las redes por las que en el primer paquete de una conexión
pase el paquete tendrá su propia MTU. TCP, es decir, en el paquete que lleva el flag
SYN. En el caso del cliente, será el paquete
Pero lo que a nosotros nos importa realmente inicial de la conexión, que llevará solo el flag
a la hora de enviar nuestro paquete, si no lo SYN, y en el caso del servidor será el segundo
queremos fragmentar, es cuál es LA MENOR paquete de la conexión (primero que envía el
de todas esas MTUs que nos encontraremos servidor), que es el que lleva los flags SYN y
por el camino (path, en inglés). A la menor ACK.
de las MTUs que hay en un camino (path)
entre dos máquinas, la denominamos Este primer paquete es la primera pista para
Path MTU, o PMTU. Si nuestros paquetes el mecanismo de PMTUD. Pero mejor vamos
no superan en tamaño a la PMTU, no habrá a ir viendo esto paso por paso con un ejemplo
ningún motivo por el que nuestros datagramas concreto.
tengan que ser fragmentados para llegar a
su destino. Tenemos 2 máquinas: cliente, y servidor.
Cliente establece una conexión TCP con
Entonces, ¡aquí tenemos la solución para Servidor, para lo cual tiene que enviar su
evitar la fragmentación! Nos basta con paquete TCP inicial (con el flag SYN, y la
encontrar de alguna manera cuál es la PMTU opción MSS). Este paquete circulará a través
de la ruta que hay entre nuestro PC y la otra de toda la ruta que une ambas máquinas.

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 más

En primer lugar, el paquete llega a la conexión que hay entre
concretamente en un único bit. El flag DF de todos los paquetes
nuestro router y nuestro ISP. Esta conexión, como vemos, tiene
(incluyendo, por supuesto, este primero) tiene que estar
una MTU de 1480 bytes.
activado. Esta es la clave del funcionamiento del PMTUD.
Por tanto, con este primer paquete, además de intentar establecer la

conexión (flag SYN), estamos haciendo dos cosas más.
Por una parte, estamos informando al Servidor del tamaño de paquetes

que podemos manejar (opción MSS), y por otra estamos tanteando la
ruta que hay entre nosotros y el servidor, ya que al activar el flag DF,
nuestro paquete sólo podrá llegar a su destino si tiene un tamaño
adecuado, es decir, si es menor o igual que la PMTU entre el Cliente y
Como nuestro paquete mide 1500 bytes (1460 de TCP + 40 de
el Servidor.
la cabecera IP) y tenemos activado el flag DF, el paquete no podrá
Con respecto a la primera cuestión, la de informar al Servidor circular más allá, por lo que nuestro router nos lo rechazará,
acerca de nuestra MSS, seremos un poco listos a la hora de escoger indicándonos el motivo con un mensaje ICMP de tipo Destination
el valor de MSS que le daremos al Servidor. Imaginemos que Unreachable (type 3) y con código Fragmentation needed
nuestra capa TCP puede manejar buffers de hasta 65535 bytes. and DF set (code 4).
En principio, éste podría ser el valor que daríamos al campo MSS, indicando
que TCP puede procesar paquetes de hasta 64KB. Pero, ¿qué utilidad
tendría 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 cómo de pequeños tendrán que ser los paquetes
para poder recorrer toda la ruta, pero lo que sí que sabemos es cuál es
NUESTRA MTU, es decir, el tamaño máximo de paquete para la red
a la que nosotros estamos conectados.
He aquí la necesidad de estas líneas que vimos antes:
Por tanto, lo más lógico es partir ya en principio de una primera
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
aproximación a la PMTU, ya que sabemos de antemano que la
iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
PMTU nunca podrá ser mayor que nuestra propia MTU (ya que Ya que ante este mensaje ICMP, nuestra máquina tendrá que
la PMTU es la menor de todas las MTUs que haya en toda la ruta,
responder, sabiendo que de ahora en adelante los paquetes
incluida la nuestra, por supuesto).
tendrán que ser más pequeños para poder pasar al menos el
Pongámonos en el caso de que nuestra red sea una Ethernet, primer tramo del camino. Pero... ¿cómo de pequeños?
que tiene una MTU de 1500 bytes. ¿Debemos poner entonces
1500 en el campo MSS? ¡Pues no! ¡No tan rápido! Hay que tener Pues aquí es donde entra en juego un nuevo RFC, el RFC 1191
en cuenta que 1500 bytes es el tamaño máximo para un (http://www.ietf.org/rfc/rfc1191.txt) que, como vemos, tiene por
datagrama, es decir, para un paquete IP. título precisamente Path MTU Discovery.
Pero la opción MSS no se refiere a paquetes IP, si no a paquetes
TCP. Un paquete TCP es un paquete IP al cual le hemos quitado Por lo que vimos en el artículo sobre ICMP, éste es el formato
(o más bien, aún no le hemos añadido) la cabecera IP. Y el campo de un ensaje ICMP Destination Unreachable:
MSS se refiere al tamaño de los datos de un paquete TCP (es
decir, sin la cabecera TCP).
Por tanto, teniendo en cuenta que el tamaño de una cabecera

TCP (sin opciones, claro) es de 40 bytes, para calcular el valor

Lo que especifica este RFC es un pequeño añadido a este formato, El mensaje ICMP llegará hasta nosotros, donde reajustaremos de
que consiste en utilizar parte del campo UNUSED para incluir el nuevo el tamaño de nuestros datagramas, esta vez a 576 bytes,
y reenviaremos una vez más el paquete.
dato que nosotros necesitamos: la MTU de la red a la que hemos
intentado acceder.
Por tanto, con el mensaje ICMP de nuestro router, nos llegará

Esta vez si que ha llegado! El Servidor ve el campo MSS de
también el valor al que tenemos que ajustar nuestro nuevo nuestro paquete, en el cual se encuentra ya a estas alturas el
paquete, que serán 1480 bytes: resultado de nuestra búsqueda 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 tamaño a la PMTU. Como el valor de nuestra MSS es
536, el servidor sabrá que sumando 40 a este número 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 sólo en el

Como este paquete no ha llegado a su destino, tendremos que establecimiento de la conexión, si no que el tamaño de los
reintentarlo, pero esta vez, por supuesto, ajustando el tamaño datagramas se puede ir ajustando dinámicamente para cada
de nuestro datagrama a 1480 bytes. Por tanto, ahora nuestro paquete.
MSS será de 1440 bytes.
Hay muchos motivos por los que la PMTU puede cambiar a lo
En el siguiente paso, nos encontramos con una red que tiene una largo del tiempo. Uno de los motivos principales es que se
establezca una nueva conexión que, aunque sea entre las dos
MTU de 2048 bytes. Nuestro paquete cabe de sobra por esa red,
mismas máquinas, utilice un tipo de servicio (TOS) diferente.
por lo que podrá atravesarla sin mayor problema:
Muchas veces los routers modifican la ruta entre dos máquinas
en función del TOS, por lo que, al haber una nueva ruta, el PMTU
puede cambiar.
Por tanto, el sistema operativo de cada máquina tiene que guardar

un registro de las PMTUs encontradas para las rutas ya conocidas.
Una ruta incluirá no sólo una dirección IP de origen y una de
destino, si no también un tipo de servicio (TOS).
Como todos los paquetes tendrán siempre el bit DF activado, en

cuanto algún paquete sea rechazado con un mensaje ICMP type
A continuación, el paquete tiene que llegar a la última red que
3 code 4, ya sabremos que tenemos que reducir el tamaño de
tenemos en nuestra ruta, la cual tiene una MTU de 576 bytes.
nuestros datagramas. Aunque no podamos ya cambiar el valor
Por aquí no podrá pasar, así que el router de turno nos responderá
del campo MSS (ya que esta opción es enviada SÓLO en el
con un ICMP type 3 code 4:
establecimiento de la conexión TCP), sí que podremos ir
ajustando dinámicamente el tamaño de los datagramas, igual que
irá haciendo el otro extremo de la comunicación según se vaya
encontrando con los mismos obstáculos.
Igual que puede haber limitaciones que aparezcan dinámicamente

en el tamaño de la PMTU, también 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 más
grande, estaremos desaprovechando la capacidad de nuestra ruta

al seguir i n s i s t i e n d o en enviar paquetes tan pequeños como ataque sin que nos suponga a nosotros ningún consumo de ancho
los que debíamos enviar antes en función de la PMTU antigua. de banda, enviando el mismo paquete, por ejemplo, una vez por
minuto.
Para estos casos, el RFC 1191 recomienda que cada cierto tiempo
se vuelva a intentar enviar paquetes grandes, a ver si cuela esta Los detalles de este ataque espero poder mostrarlos en el próximo
vez (sólo colará si la ruta ha cambiado sin que nos diéramos artículo, donde haré un compendio de técnicas que utilicen ip-
cuenta, claro). Como la probabilidad de que cambie la ruta no es spoofing, incluida ésta.
muy alta, no merece la pena estar reintentando paquetes grandes
cada dos por tres, ya que supondría estar constantemente Aún así, a pesar de este peligro potencial que se nos presenta al
reajustando el tamaño de nuestros datagramas. Por eso, el RFC utilizar el PMTUD, son muchas más las ventajas que los
recomienda hacer estos reintentos aproximadamente cada 10 inconvenientes, por lo que en principio parece una buena opción
minutos. añadir estas líneas a nuestras iptables:
Si vuestras mentes son tan retorcidas como las mías, habréis
# PMTUD
encontrado aquí una idea para un ataque DoS.
iptables -A INPUT -p tcp --fragment -j DROP
No he visto prácticamente nada documentado acerca de este tipo iptables -A FORWARD -p tcp --fragment -j DROP
de ataque. Únicamente he encontrado un documento que compendia iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
los ataques que explotan el protocolo ICMP, y comentaban como iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
curiosidad la posibilidad de este ataque, indicando que no ha En caso de que veamos que algo no funciona como debería,
sido probado. entonces tendríamos que revisar nuestras iptables y hacerlas
menos restrictivas, tal y como fuimos viendo en los puntos
En el próximo artículo os contaré mis resultados prácticos con este anteriores, donde comentábamos técnicas concretas para filtrar
experimento. cada tipo de ataque específico. De encontrar algún problema lo
encontraríamos en algún protocolo que utilizase grandes flujos
Pero bueno, ¡deja de enrollarte ya, y cuéntanos en qué consiste de datos, y que por algún motivo requiriese fragmentación
esa técnica DoS que te has inventado! obligatoriamente. Yo no utilizo NFS, pero por lo que he leído es
posible que por ejemplo con este protocolo sí que pudiesen surgir
Pues imaginad qué pasaría si se nos ocurriese suplantar a uno problemas al rechazar toda la fragmentación.
de los routers que hay en el camino entre dos máquinas. Hacemos
Resumiendo
un simple ip-spoofing para que la IP de origen de nuestro paquete
sea la del router, y enviamos a una de las dos máquinas (la que
Esta es la solución que propongo yo para implementar un firewall
queramos DoSear) un mensaje ICMP type 3 code 4 trucado a
con iptables protegido contra los ataques de fragmentación.
mano, en el cual le haremos creer que la PMTU ha cambiado a
un valor todo lo bajo que podamos indicarle.
Por supuesto, estoy abierto a todo tipo de mejoras, dudas, críticas, o
En teoría podríamos poner aquí un 0, por lo que se creería que comentarios de cualquier tipo:
no puede enviar ni un mísero byte, y no podría continuar enviando
ningún dato. En cambio, el RFC 1191 obliga a que el valor mínimo # Bloqueo de ataques con ICMP fragmentados
para este campo sea de 68 bytes. Ahora bien, una cosa es lo que iptables A INPUT p icmp --fragment j LOG --log-prefix ICMP Frag:
diga el RFC y otra lo que implementen los programadores de los iptables A INPUT p icmp --fragment j DROP
sistemas, así que habría que probar si realmente alguien ha hecho iptables A FORWARD p icmp --fragment j LOG --log-prefix ICMP Frag:
caso a esta recomendación del mínimo de 68 bytes. iptables A FORWARD p icmp --fragment j DROP
En cualquier caso, aunque se sigan las recomendaciones del RFC # PMTUD

1191, podríamos reducir la PMTU de una conexión hasta en 68 iptables A INPUT p tcp --fragment j LOG --log-prefix TCP Frag:
bytes. iptables -A INPUT -p tcp --fragment -j DROP
iptables A FORWARD p tcp --fragment j LOG --log-prefix TCP Frag:
Por poner un ejemplo real, la PMTU que me suelo encontrar yo iptables -A FORWARD -p tcp --fragment -j DROP
prácticamente siempre es de 1500 bytes, por lo que por cada iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
1460 bytes de datos, estamos enviando 1500 bytes (sumando los iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
40 bytes de cabeceras).
En cambio, si reducimos a 68 bytes la PMTU, por cada 28 bytes Autor: PyC (LCo)
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 sólo un 41% de cada paquete serán datos.
Conseguiríamos teóricamente reducir así prácticamente a la mitad

el ancho de banda de una conexión enviando tan sólo 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

Protección con iptables en una red corporativa
La realización de este artículo 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 número 17), tenía una idea de la estructura que iba a seguir el curso, y de
las cosas que quería contar.
Dentro de ese plan entraba el dedicar un artículo a las iptables una vez que terminase de ex
plicar toda la teoría 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 magnífica y completa, así que desde aquí mis felicitaciones para Vic_Thor.
Dando vueltas al asunto llegué a la conclusión de que, si sabía aprovechar la situación, podría ser
una ventaja más que un obstáculo para mis planes. Podía aprovechar que Vic_Thor ya os dio toda
la base necesaria para comprender las iptables y, por tanto, podía ir directamente al meollo del
asunto sin tener que escribir tropecientas páginas explicando detalles de las iptables que, en reali
dad, se salen de la temática del curso de TCP/IP.
Por tanto, si consigo mis objetivos con este artículo, habremos conseguido una combinación 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 artículo sea complementario al curso de diseño de firewa
lls, ya que no puedo ir tachando todo lo que ya ha sido contado para contar sólo cosas nuevas, pues
el artículo quedaría totalmente inconexo y perdería toda su utilidad.
Así que podéis 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, tenéis 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 también algunas cosas de la veterana serie RAW, y aplicando lo que vimos entonces al diseño de
un firewall completo, de arriba a abajo, que implemente protección para prácticamente todos los
ataques que he ido explicando durante casi 2 años (ya he perdido la cuenta de cuanto tiempo llevo
en la revista...).
30/68
Pero antes de que llegase mi hermano apareció un tío con
una furgoneta y empezó a cargar todo lo rápido que podía,
Ya que de esto se encargó el curso de firewalls, no os voy a mientras yo iba sacando como podía cualquier cosa que en
ir presentando una serie de escenarios, empezando por el contrase aprovechable hasta que llegasen los refuerzos.
más sencillo para ir complicando cada vez más la cosa.
De aquella oportunidad única, aparte de varias broncas de
Directamente os voy a plantear un escenario complicado y mi madre y la novia de mi hermano, salió material para
terminamos antes, jeje. abastecer a varias personas (que si no se quién quiere un
teclado, que si este monitor cutre para no se cuantos...).
Os voy a plantear un escenario muy típico en cualquier
corporación, pero no tan típico en un ambiente doméstico. Resumiendo, que si realmente te lo curras, a pesar de que
Aún así, el montaje que tengo yo en mi propia casa es bas no tengas un duro, tu principal limitación a la hora de montar
tante parecido al que voy a plantear (aunque no exactamen una red de estas características ya no será la falta de equi
te igual, ya que tampoco me gusta revelar los detalles inter pos, si no, como en mi caso, la falta de espacio y (también
nos de mi red a todo el planeta), por lo que es perfectamente hay que tenerlo en cuenta) el incremento en la cuenta de
viable para un usuario normal que, más que dinero (ya que Iberdrola que supondrá tener todas esas máquinas encendi
de eso no me sobra precisamente), lo que tenga sean las su das 24 horas (eso sí, por lo menos lo que gastas en electrici
ficientes ganas. dad luego te lo puedes ahorrar en calefacción).
Hoy día es muy habitual tener 2 pcs: el pc viejo que utilizaste Pero bueno, ya estoy otra vez contando mi vida. Vamos a ver
hasta hace x años, y el pc relativamente nuevo que es el que en primer lugar con una imagen el escenario que estamos
utilizas normalmente. planteando:
Para hacerse con más ordenadores puedes optar por varias

opciones. Puedes ir como un buitre detrás de tus amigos, o
familiares, en espera de que alguien se deshaga de algún PC
viejo, o de que la empresa en la que trabaje alguien renueve
los equipos informáticos (éste es el gran chollo).
Otra opción es comprar algún PC cutre de segunda mano por

cuatro duros. Y por último, la opción más cutre de todas, pe
ro también quizá la más 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
ría.
Cuando digo habitualmente podría decir que más o menos

la media es de una vez al mes. Hay meses que increíblemen
te me puedo encontrar un hallazgo cada fin de semana (los
fines de semana suele ser más habitual, no se bien por qué), Como vemos, en el escenario aparecen 4 redes:
y luego pasar varios meses sin encontrar absolutamente na
da. La primera red es, por supuesto, Internet. Esta red cons
ta de una nubecita llena de millones de máquinas, de las
Si habéis encontrado alguno de estos hallazgos y habéis sido cuales una de ellas es nuestro router ADSL, llamado
lo suficientemente cutres (como yo) como para pararos a mi Zeus.
rar si hay algo aprovechable, probablemente la mayoría de
las veces habréis comprobado que los restos han sido muti La segunda red está formada por sólo dos máquinas:
lados, llevándose cualquier parte interesante (CPU, memoria, Zeus, y nuestro firewall, llamado Cerbero. Como segura
tarjetas que cuesten más de 20 euros, etc). mente sabréis, Cerbero era el perro infernal que guardaba
las puertas del Hades, el reino de los muertos de los anti
Pero, aún así, muchas veces se encuentran auténticos yaci guos griegos.
mientos que son como minas que requieren hasta maquina
ria para ser explotadas . Nunca olvidaré aquella ocasión en Al igual que el can Cerbero, nuestro Cerbero tiene 3 ca
la que pasé por enfrente de una oficina del INEM y descubrí bezas, cada una de ellas conectada a una red, y se encar
un contenedor entero lleno de material informático. ga también de vigilar la entrada de cada reino, para que
Rápidamente, llamada al móvil de mí hermano para que vi los vivos no se junten con los muertos, ni los muertos con
niese con el coche. los vivos.
31/68
A esta red que une a Zeus y Cerbero la llamaremos Como podemos deducir por la imagen, la red Olimpo está
Olimpo. definida por las direcciones 192.168.1.0/24. La red
Hades por las direcciones 192.168.2.0/24, y la red Gaia
La tercera red está formada de momento por sólo dos má por las direcciones 192.168.3.0/24.
quinas: Cerbero, y un servidor web al que hemos llama
do Persefone. Esta red es, por supuesto, una DMZ, ya Por supuesto, la primera red, que es Internet, tiene sus
que aquí es donde se encuentran nuestros servidores. propias direcciones, entre las cuales se encuentra la
Cualquier otro servidor que quisiéramos poner (de correo, 80.15.13.100, que es la dirección IP de Zeus de cara a
de dns, etc) tendríamos que ubicarlo aquí. Internet (Zeus tendrá otra IP, que será la que tenga en la
red Olimpo).
A esta red, la DMZ, la llamaremos Hades.
Para quien no le haya quedado claro, la máscara de red
La cuarta y última red es nuestra red interna, y está for para las 3 redes, Olimpo, Hades, y Gaia, es
mada de momento por 3 máquinas: Cerbero, y dos PCs 255.255.255.0.
llamados Eolo y Poseidon.
También vemos en la imagen que Cerbero tiene 3 tarjetas
A esta red, la red interna, la llamaremos Gaia. de red: eth0, eth1, y eth2. La tarjeta eth0 es la que co
necta a Cerbero con la red Hades, la tarjeta eth1 conecta
¿Y a qué viene esta tontería de poner nombres a las má
a Cerbero con la red Olimpo, y la tarjeta eth2 conecta a
quinas y a las redes? El que pregunte esto probablemente
Cerbero con la red Gaia.
nunca habrá tenido que manejar redes con más de dos
máquinas. Cuando diseñas una red lo tienes que hacer Nos vamos a centrar únicamente en la configuración de la
siempre en previsión de que ésta pueda crecer y cambiar. 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 artículo iremos recordando lo que
Con respecto al primer punto (el crecimiento de la red),
he ido explicando en la serie RAW y en el curso de TCP/IP,
sería absurdo llamar a las máquinas: SERVIDOR,
y aplicando estos conocimientos a la configuración de
FIREWALL, ROUTER, y PC. En cuanto añadiésemos otro
Cerbero. Os muestro aquí la configuración completa de
servidor, otro router, o cualquier otro elemento a la red,
IPTABLES de Cerbero, e iremos recorriendo esta
ya empezaría a haber ambigüedades que terminarían con
configuración a lo largo de todo el artículo:
tribuyendo al caos que ya es de por sí el mantener una red
corporativa. #! /bin/sh
Y con respecto al segundo punto (los cambios en la red)

##################################
os puedo hablar de mi propia experiencia en una empresa
# IPTABLES CERBERO
en la que trabajé como administrador de sistemas. En
# ~~~~~~~~~~~~~~~~
principio se optó (yo no trabajaba allí por aquel entonces)
# Curso de TCP/IP.
por llamar a cada PC con el nombre del empleado que lo
# Revista PC PASO A PASO.
utilizaba. Al cabo de unos años, casi la mitad de la plantilla
#
había cambiado, y teníamos a un hombre barbudo traba
# PyC (LCo). Diciembre 2004.
jando con un PC llamado Rosita, y eso al final también ter
#
minaba causando cierta confusión, como imaginaréis.
# Este script de iptables ha sido
Y vamos, si tu duda es ya que cuál es la necesidad de po # realizado exclusivamente para
ner nombres, sean cuales sean, entonces imagínate lo que # la revista PC PASO A PASO.
puede ser realizar cualquier configuración o depuración de # Eres libre de utilizarlo o
la red con varias máquinas llamadas todas con números # modificarlo a tu antojo. :-)
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. ###########################
# DEFINICION DE VARIABLES
Resumiendo, mi consejo es que utilicéis nombres que sean ###########################
hasta cierto punto significativos, pero no dependientes del
contexto, pues éste podría cambiar. El ejemplo que planteo ServidorDNS=193.15.25.1
aquí de los dioses griegos me parece una opción muy bue
na, y como otro ejemplo tenéis el que uso yo actualmente, ####################
que son nombres de estrellas para las máquinas, y de # DIOSES (MAQUINAS)
constelaciones para las redes. Zeus_Internet=80.15.13.100
Tenéis incluso un RFC dedicado a la elección de nombres

# OLIMPO
para redes. Este es el RFC 1178, y lo tenéis traducido al
Zeus=192.168.1.2
castellano en http://www.rfc-es.org/getfile.php?rfc=1178.
Cerbero_Olimpo=192.168.1.1
32/68
# HADES do
Persefone=192.168.2.2 echo 1 > $f
Cerbero_Hades=192.168.2.1 done
# GAIA # Habilitamos proteccion anti-smurf

Eolo=192.168.3.2 echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Poseidon=192.168.3.3
Cerbero_Gaia=192.168.3.1 # Habilitamos proteccion contra source route spoofing
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
#################
# REINOS (REDES) # Registramos marcianos para el proyecto SETI
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
hades=eth0
olimpo=eth1 ####################################
gaia=eth2 # BLOQUEAMOS TODO MIENTRAS ESTAMOS CONFIGURANDO
####################################
####################################
# Creamos reglas de bloqueo
case "$1" in iptables --insert FORWARD 1 -j DROP
iptables --insert INPUT 1 -j DROP
restart) iptables --insert OUTPUT 1 -j DROP
$0 stop
$1 start # Configuramos la politica por defecto
;; iptables --policy FORWARD DROP
iptables --policy INPUT DROP
stop) iptables --policy OUTPUT DROP
iptables -F
iptables -X ############################
iptables -Z # HABILITAMOS TRAFICO LOCAL
iptables -t nat -F ############################
;;
iptables -A INPUT -i lo -j ACCEPT
status) iptables -A OUTPUT -o lo -j ACCEPT
iptables --list
;; ####################################
# --- REGLAS --- #
start) ####################################
#################################### ############
# BORRAMOS LA CONFIGURACION ACTUAL DE IPTABLES # TABLA NAT
#################################### ############
iptables -F # SERVIDOR FTP EN PERSEFONE

iptables -X iptables -t nat -A PREROUTING \
iptables -Z -p tcp --dport ftp -i $olimpo -j DNAT --to $Persefone
iptables -t nat -F
# SERVIDOR WWW EN PERSEFONE
######################## iptables -t nat -A PREROUTING \
# CONFIGURACION GENERAL -p tcp --dport www -i $olimpo -j DNAT --to $Persefone
########################
# DCC PARA EOLO
# incluimos modulo para FTP iptables -t nat -A PREROUTING \
modprobe ip_conntrack_ftp -p tcp --dport 5000:5005 -i $olimpo -j DNAT --to $Eolo
# Habilitamos el forward de paquetes # DCC PARA POSEIDON

echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A PREROUTING \
-p tcp --dport 5010:5015 -i $olimpo -j DNAT --to $Poseidon
# Habilitamos proteccion anti-spoofing
for f in /proc/sys/net/ipv4/conf/*/rp_filter # EMULE PARA POSEIDON
33/68
iptables -t nat -A PREROUTING \ iptables -A flags_tcp -p tcp --tcp-flags ALL FIN,URG,PSH \
-p tcp --dport 4662 -i $olimpo -j DNAT --to $Poseidon -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
# ENMASCARAMIENTO HACIA EL EXTERIOR
# RECHAZAMOS Y LOGEAMOS ESCANEO SYN/RST
# ENMASCARAMIENTO PARA LA RED HADES iptables -A flags_tcp -p tcp --tcp-flags SYN,RST SYN,RST \
iptables -t nat -A POSTROUTING \ -m limit --limit 5/minute -j LOG --log-prefix "SYN/RST SCAN: "
-s 192.168.2.1/24 -o $olimpo -j SNAT --to $Cerbero_Olimpo iptables -A flags_tcp -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# ENMASCARAMIENTO PARA LA RED GAIA # RECHAZAMOS Y LOGEAMOS ESCANEO SYN/FIN

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

iptables -A FORWARD -i $hades -o $gaia -j hades_gaia iptables -A olimpo_gaia -d $Eolo \
-p tcp --dport 5000:5005 -j ACCEPT
# RECHAZAMOS Y LOGEAMOS TODO!
iptables -A hades_gaia -j LOG --log-prefix "HADES->GAIA: " # PERMITIMOS DCC A POSEIDON
iptables -A hades_gaia -j DROP iptables -A olimpo_gaia -d $Poseidon \
-p tcp --dport 5010:5015 -j ACCEPT
#####################################
# CADENA DE REGLAS DE HADES A OLIMPO # PERMITIMOS EMULE A POSEIDON
##################################### iptables -A olimpo_gaia -d $Poseidon \
# DMZ -> INTERNET -p tcp --dport 4662 -j ACCEPT
iptables --new-chain hades_olimpo

# RECHAZAMOS Y LOGEAMOS TODO LO DEMAS
iptables -A FORWARD -i $hades -o $olimpo -j hades_olimpo
iptables -A olimpo_gaia -j LOG --log-prefix "OLIMPO->GAIA: "
iptables -A olimpo_gaia -j DROP
# PERMITIMOS TODO EL TRAFICO HACIA EL EXTERIOR
iptables -A hades_olimpo -j ACCEPT
########################################
# REGLAS PARA EL PROPIO CERBERO (INPUT)
#####################################
########################################
# CADENA DE REGLAS DE OLIMPO A HADES
#####################################
iptables --new-chain olimpo_cerbero
# INTERNET -> DMZ
iptables --new-chain hades_cerbero
iptables --new-chain olimpo_hades iptables --new-chain gaia_cerbero
iptables -A FORWARD -i $olimpo -o $hades -j olimpo_hades
iptables -A INPUT -i $olimpo -j olimpo_cerbero
# PERMITIMOS DNS iptables -A INPUT -i $hades -j hades_cerbero
iptables -A olimpo_hades -s $ServidorDNS \ iptables -A INPUT -i $gaia -j gaia_cerbero
-p udp --sport domain -j ACCEPT
#################
# SERVICIOS QUE OFRECE HADES A INTERNET # OLIMPO_CERBERO
iptables -A olimpo_hades -p tcp --dport www -j ACCEPT #######################
iptables -A olimpo_hades -p tcp --dport ftp -j ACCEPT # INTERNET -> FIREWALL
# RECHAZAMOS Y LOGEAMOS EL RESTO DEL TRAFICO # PERMITIMOS DNS

iptables -A olimpo_hades -j LOG --log-prefix "OLIMPO->HADES: " iptables -A olimpo_cerbero -s $ServidorDNS \
iptables -A olimpo_hades -j DROP -p udp --sport domain -j ACCEPT
#################################### # RECHAZAMOS Y LOGEAMOS EL RESTO DEL TRAFICO

# CADENA DE REGLAS DE GAIA A OLIMPO iptables -A olimpo_cerbero -j LOG --log-prefix "OLIMPO->CERBERO: "
#################################### iptables -A olimpo_cerbero -j DROP
# INTERNA -> INTERNET
################
iptables --new-chain gaia_olimpo # HADES_CERBERO
iptables -A FORWARD -i $gaia -o $olimpo -j gaia_olimpo ##################
# DMZ -> FIREWALL
# ACEPTAMOS TODO EL TRAFICO HACIA INTERNET
iptables -A gaia_olimpo -j ACCEPT # RECHAZAMOS Y LOGEAMOS TODO!
iptables -A hades_cerbero -j LOG --log-prefix "HADES->CERBERO: "
#################################### iptables -A hades_cerbero -j DROP
# CADENA DE REGLAS DE OLIMPO A GAIA
#################################### ###############
# INTERNET -> INTERNA # GAIA_CERBERO
iptables --new-chain olimpo_gaia ######################

iptables -A FORWARD -i $olimpo -o $gaia -j olimpo_gaia # INTERNA -> FIREWALL
35/68
# RECHAZAMOS Y LOGEAMOS TODO! Poseidon:
iptables -A gaia_cerbero -j LOG --log-prefix "GAIA->CERBERO: "
iptables -A gaia_cerbero -j DROP Tiene acceso total hacia Internet, pero muy restringi
do desde Internet.
#########################################
# REGLAS PARA EL PROPIO CERBERO (OUTPUT) El usuario de Poseidon utiliza emule.
#########################################
Tiene abiertos 6 puertos para DCC, ya que el usuario
# PERMITIMOS LA SALIDA DE CONSULTAS DNS de Poseidon quiere también utilizar IRC.
iptables -A OUTPUT -o $olimpo -d $ServidorDNS \
Responde a un conjunto mínimo de mensajes ICMP.
-p udp --dport domain -j ACCEPT
Zeus:
# RECHAZAMOS Y LOGEAMOS EL RESTO DEL TRAFICO
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT: " Es un router ADSL que hace NAT a todos los puertos que
iptables -A OUTPUT -j DROP utilizarán todas las redes, para que los gestione Cerbero.
Por tanto, la tabla NAT de Zeus será parecida a esta:
#########################
# 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 máquina serán:
Persefone:
Ofrece servidor www y ftp tanto a Internet como a la

red Gaia.
Ofrece servidor ssh para administración remota sólo

para Eolo.
Tiene acceso total a Internet. Solo tiene limitado el

acceso desde Internet.
Responde a un conjunto mínimo de mensajes ICMP. Ahora que ya hemos visto a grandes rasgos el escenario,
vamos a ir analizando paso a paso todas las líneas de es
Cerbero:
tas iptables.
Su única comunicación con cualquier red son las consultas
al servidor DNS, y respuesta a un conjunto mínimo de
mensajes ICMP.
En esta primera sección del archivo de configuración de ip
Eolo: tables vemos una serie de definiciones que nos serán útiles
para todo el script.
Tiene acceso total hacia Internet, pero muy restringi
do desde Internet. Podemos comprobar que algunos de los valores definidos
no son usados luego en el script. Aún así, conviene definir
Tiene acceso a Persefone como cliente ssh, para ad los también, pues definimos así todo el contexto, y nos
ministrar remotamente el servidor web. permitirá hacer cualquier modificación o ampliación en el
futuro sin tener que preocuparnos de si teníamos definido
Tiene abiertos 6 puertos para DCC, ya que el usuario
o no tal elemento que hasta el momento no habíamos uti
de Eolo quiere utilizar IRC.
lizado.
Responde a un conjunto mínimo de mensajes ICMP.
36/68
La primera línea: Las opciones que damos a nuestro comando de iptables
son (suponiendo que el script se llama iptpyc):
ServidorDNS=193.15.25.1
./iptpyc stop : Borra toda la configuración de ipta
Indica la dirección IP del servidor DNS que utilizamos (pro
bles.
bablemente el que nos haya dado nuestro ISP).
Normalmente, esta dirección IP, así como probablemente ./iptpyc start : Configura las iptables con todas las
también las del resto de máquinas a las que nos referimos reglas que hemos incluido en el script.
en el script, se encontrarán ya en la configuración del sis
tema. ./iptpyc restart : Hace un stop y un start, reinician
do así toda la configuración de iptables.
Concretamente, los servidores DNS los tendremos en
/etc/resolv.conf, y el resto de máquinas en /etc/hosts. ./iptpyc status : Muestra la configuración actual de
iptables.
Depende de la decisión de cada administrador el incluir
aquí o no todas estas variables. Si no las incluimos el Para implementar estos comandos hacemos un CASE sobre
script puede ser menos legible, al no tener en el propio el parametro $1. En un script de shell el parámetro $0 es
script toda la información necesaria para ser interpretado. siempre el propio nombre del parámetro (en este caso ip
Como contrapartida, si las incluimos en el script tenemos tpyc), y el parámetro $1 es el primer parámetro que hay
el problema potencial de que en algún momento pueda ha justo detrás del nombre del script.
ber incoherencia entre la información almacenada en
/etc/hosts y el script de iptables. Un CASE es una sentencia condicional que, a la diferencia
de un IF THEN ELSE, que sólo permite seleccionar una
Yo personalmente prefiero incluir las definiciones en el pro opción u otra según dos posibles condiciones sobre la va
pio script de iptables, a pesar de que estén ya definidas riable de entrada (SI cumple, y NO cumple), el CASE nos
todas las máquinas en el sistema. permite seleccionar tantas condiciones como queramos.
Para los que prefiráis no incluir las definiciones, simple En este caso nuestro CASE considera las condiciones de
mente tenéis que eliminar el símbolo $ que precede a los que $1 sea stop, start, restart, status, o cualquier
nombres de máquinas en todo el script. Por ejemplo, la lí otra cosa que no sea ninguna de las anteriores. Es decir,
nea: tenemos 5 condiciones sobre la variable $1, por lo que la
estructura básica de nuestro CASE es la siguiente:
iptables -A olimpo_hades -s $ServidorDNS \
case $1 in
-p udp --sport domain -j ACCEPT
restart)
** acciones para la opción restart **
Quedaría:
;;
iptables -A olimpo_hades -s ServidorDNS \ stop)
** acciones para la opción stop **
-p udp --sport domain -j ACCEPT ;;
status)
Como vemos, también incluyo definiciones para las 3 tar
** acciones para la opción status **
jetas de red: eth0, eth1, y eth2. Esto es fundamental, ya
;;
que la mejor forma de asegurarnos de por dónde están cir
start)
culando los paquetes es utilizar como referencia el propio
** acciones para la opción start **
dispositivo físico, es decir, la tarjeta de red. Si utilizásemos
;;
direcciones IP como referencia para identificar cada red,
*)
podríamos ser engañados por algún tipo de spoofing (aun
** acciones para cualquier otro valor **
que tengamos protección contra IP-spoofing, como ya ve
;;
remos).
esac
Como vemos, las acciones para cada opción terminan con

;;, y toda la sentencia case termina con esac.
Este archivo de configuración de iptables no es más que
Veremos ahora una por una todas las opciones que hemos
un script para la shell de Linux y, por tanto, puede utilizar
incluido en el script.
toda la potencia del lenguaje de programación de la shell.
RESTART)
Aquí nosotros estamos implementando una función muy
típica en Linux, que consiste en poder pasar un parámetro Como ya he dicho, un restart es tan simple como hacer un
a un comando a la hora de lanzarlo, para que actúe de una stop, y a continuación un start.
forma u otra según el parámetro.
37/68
STOP) En realidad, el sitio adecuado para incluir cualquier módulo
sería el archivo /etc/modules, pero nosotros lo hemos
Esta opción vacía toda la configuración de iptables, tanto incluido en el script de iptables, para que tengamos todo
si fue previamente ejecutado nuestro script (con start), co junto, y así tener una visión más global.
mo si no.
Por cierto, que ya que hablo de visión global, no estaría de
STATUS) más que os mostrase aquí también el resto de
configuración básica de Cerbero:
Tan sencillo como llamar a la opción --list del comando ip
tables. hostname Cerbero
*) ifconfig eth0 192.168.2.1 netmask 255.255.255.0
Ahora os pido que bajéis hasta el final del script para ver ifconfig eth1 192.168.1.1 netmask 255.255.255.0
esta opción, ya que tiene que ser incluida después de to
das las demás. ifconfig eth2 192.168.3.1 netmask 255.255.255.0
Como vemos, si se introduce cualquier opción que no sea route add default gw Zeus
una de las que reconoce nuestro script, mostraremos el tí
pico mensaje que indica al usuario las opciones disponi Con los comandos ifconfig estamos configurando las 3
bles. tarjetas de red, asignando una IP y una máscara de red a
cada una. Con el comando route estamos definiendo la ru
START) ta por defecto hacia Zeus (lo que Windows llama puerta
de enlace predeterminada).
Todo el resto del artículo está dedicado a la opción de Pero, volviendo a nuestro script, vamos a ver más sobre
start, así que aquí viene la chicha. el módulo que estamos cargando en Cerbero.
Aquí es donde empezamos a echar la vista atrás, recor

dando aquellos buenos tiempos de la serie RAW, y nos
encontramos con los dos artículos que dediqué al protocolo
Empezamos haciendo lo mismo que hace el comando stop, FTP.
para empezar con una configuración limpia sobre la que ir
trabajando. Este es un buen momento para repasar esos articulillos y
recordar el funcionamiento del FTP pasivo, y el no pasivo.
Volved aquí cuando hayáis hecho el repaso.
Como ya sabemos (si hemos repasado la lección), cada

En este punto se encuentran algunas de las características vez que un servidor FTP recibe un comando PASV ha de
más interesantes de nuestro script. Vamos a ir viendo una abrir dinámicamente un puerto para que el cliente se co
a una cada una de las líneas de esta parte del script. necte a un nuevo canal de datos. Por otra parte, cada vez
que un cliente lanza un comando PORT, ha de abrir diná
# incluimos modulo para FTP
micamente un puerto para que el servidor se conecte y es
modprobe ip_conntrack_ftp tablezca un nuevo canal de datos.
Si estamos utilizando iptables, estos mecanismos no po
Linux pretende ser un sistema operativo con cierta modu drían funcionar así por las buenas, como es lógico. Para
laridad, lo cual se consigue gracias a ciertos comandos co que puedan funcionar tenemos que incluir el módulo
mo modprobe (man modprobe). ip_conntrack_ftp, que se encarga de analizar el campo
DATOS de los paquetes TCP/IP en busca de comandos
Existen una gran cantidad de módulos que podemos cargar
PORT y PASV. Cuando encuentra uno de estos comandos,
dinámicamente, y estos suelen encontrarse en
los interpreta, y abre dinámicamente los puertos que haya
/lib/modules. Si queremos ver un listado completo de
que abrir.
los módulos que tenemos disponibles para ser cargados,
podemos hacer: Cuando no estamos seguros de lo que hace un módulo de
Linux siempre tenemos la posibilidad de analizar el código
modprobe -l
fuente, cosa que de ninguna manera podemos hacer con
Desde una shell de root. Windows. Por eso Windows, mientras no libere su código,
Para ver los módulos que tenemos cargados en estos mo seguirá siendo un sistema oscuro a cuyos caprichos esta
mentos: rán sujetos todos sus usuarios. En Linux siempre tienes la
posibilidad de comprobar tú mismo el funcionamiento de
lsmod las cosas, o bien de que otro con más conocimientos que
tú lo haga, y publique sus conclusiones en cualquier web
También sólo para root. o publicación a la que tenga acceso todo el mundo.
38/68
Si al instalar nuestra distribución de Linux escogimos ins Al soportar ambos comandos también el protocolo ipv4, la
talar también los paquetes de sources (código fuente), idea es que vayan siendo implementados por todos los ser
tendremos el código del módulo ip_conntrack_ftp.c en el vidores y clientes FTP, para ir preparándonos para un futu
directorio /usr/src/linux/net/ipv4/netfilter/. Por si ro que está siendo ya implantado.
no instalasteis los fuentes, podéis ver igualmente el código
f u e n t e d e e s t e m ó d u l o e n # Habilitamos el forward de paquetes
http://joshua.raleigh.nc.us/docs/linux-
echo 1 > /proc/sys/net/ipv4/ip_forward
2.4.10_html/577570.html.
Las principales responsabilidades de Cerbero serán dos:
Podemos ver en el fuente cómo analiza los paquetes en
servir de cortafuegos para todas las redes, y encaminar y
busca de PORT o 227, que correspondería respectiva
reenviar todos los paquetes de una red a otra. Para que
mente a los comandos PORT y PASV (ya que 227 es el
pueda hacer esta segunda función, tenemos que activar el
código de respuesta de PASV). También analiza los co
forward de paquetes, lo cual hacemos escribiendo un sim
mandos EPRT (Extender PoRT) y EPSV (Extended
ple 1 en el archivo /proc/sys/net/ipv4/ip_forward.
PaSsiVe), que no vimos en la serie RAW.
Probad desde una shell de root a escribir estos dos coman
Los comandos EPRT y EPSV fueron propuestos en el RFC
dos:
2428, para facilitar la futura sustitución del actual proto
colo ipv4 por el nuevo ipv6 (del que ya hablaremos a lo echo 1 > /proc/sys/net/ipv4/ip_forward
largo del curso).
cat /proc/sys/net/ipv4/ip_forward
Las direcciones IP de ipv6 son diferentes a las de ipv4, por
lo que los actuales comandos PORT y PASV no podrían ser Como veis, lo único que se hace es escribir un 1 en el ar
directamente portados a ipv6, al utilizar las clásicas direc chivo ip_forward, como si fuese un simple archivo de
ciones de 32 bits. texto.
Los comandos EPRT y EPSV tienen la misma funcionalidad # Habilitamos proteccion anti-spoofing
que sus predecesores, pero añaden además la posibilidad
for f in /proc/sys/net/ipv4/conf/*/rp_filter
de utilizar direcciones ipv6.
do
Analicemos, por ejemplo, el comando EPRT. Para conse
guir lo que he mencionado, este comando tiene 3 paráme echo 1 > $f
tros:
done
EPRT |protocolo|direcciónIP|puerto|
Todavía nos falta hablar más sobre ip-spoofing en este
El primer parámetro, protocolo, puede valer 1 ó 2. En el curso, pero de momento ya sabemos bastante bien en qué
caso de que sea 1, indicamos que se trata del protocolo consiste esta técnica tan versátil, que se suele usar en
ipv4 y, por tanto, igual al clásico PORT que ya conoce combinación con gran cantidad de ataques.
mos. Si es un 2, se tratará del protocolo ipv6 y, por tanto,
el siguiente parámetro (direcciónIP) vendrá en el formato Este bucle recorre varios directorios, cada uno correspon
de direcciones IP v6. diente a un dispositivo de red (eth0, eth1, eth2, y lo, bási
camente). En cada uno de estos directorios tendremos una
El segundo parámetro, direcciónIP, en el caso de que el serie de opciones de configuración para el correspondiente
anterior parámetro sea 1 (ipv4) será simplemente una dispositivo (es decir, una configuración independiente para
dirección IP de las de toda la vida, pero con la diferencia cada tarjeta de red). En este caso, nosotros activaremos
(con respecto al comando PORT) de que los dígitos no ven una opción que tenemos en el archivo rp_filter. Si escri
drán separados por comas, si no por puntos. bimos un 1 en este archivo, impedimos que el dispositivo
acepte direcciones IP que no pertenezcan a su red.
El tercer y último parámetro, puerto, tendrá también una
diferencia con respecto al comando PORT, y es que no ha Esta es una sencilla protección contra ip-spoofing, aunque
brá que hacer cálculos para hallar el número de puerto, si no nos protege contra otras técnicas, como el source-route
no que éste vendrá especificado tal cual. spoofing.
Es decir, aquí tenemos un ejemplo de comando EPRT que Cuando hablemos más en profundidad sobre ip-spoofing
haría la misma función que un comando PORT mostraremos esto con más detalle.
80,15,13,100,10,15:
# Habilitamos proteccion anti-smurf
EPRT |1|80.15.13.100|2575|
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Ya que, como sabemos, el puerto 10,15 del comando
PORT se traduciría en: 10*256 + 15 = 2575. Esto ya lo vimos en el artículo sobre fragmentación.
Escribiendo un 1 en este archivo estamos anulando la res
39/68
puesta a pings a la dirección broadcast, lo cual impide Durante el segundo en que estemos cargando las iptables,
que nos convirtamos en un amplificador para un ataque nuestra red no funcionará, ya que estaremos rechazando
smurf. todos los paquetes.
Al final del script es imprescindible que no olvidemos elimi

# Habilitamos proteccion contra source route spoofing
nar estas reglas porque, como sabemos, las reglas de ipta
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route bles se ejecutan secuencialmente, por lo que si la primera
regla rechaza todo, las demás nunca se ejecutarán.
Esto lo veremos más adelante en el curso, cuando hable
mos de la técnica de source-route spoofing. De momen
to nos quedamos con la idea de que esta línea nos permite
desactivar la respuesta a datagramas que lleven activadas Con esto permitimos que el propio Cerbero se haga a si
opciones de enrutamiento explícito, es decir, las opciones mismo PING, o lo que quiera. Todo el tráfico entre Cerbero
LSRR y SSRR. y el propio Cerbero está permitido. Ahora bien, recomien
do que en una máquina como Cerbero, dedicada exclusiva
Esto no significa que vayamos a rechazar esos datagra mente a un firewall, no metamos ninguna otra aplicación,
mas, si no simplemente que no responderemos a lo que ni mucho menos ninguna clase de servidor. Por tanto, el
nos pide esa opción, es decir, que no seguiremos la ruta tráfico entre Cerbero y sí mismo normalmente será muy
especificada en nuestra respuesta. limitado o nulo. Aún así, no tiene ningún peligro permitir
el tráfico local, por lo que podemos hacerlo sin miedo (es
# Registramos marcianos para el proyecto SETI pero que Murphy no me esté leyendo).
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians Como vemos, para identificar el tráfico local no hemos uti
lizado la opción -s 127.0.0.1, que sería como decir: tráfi
Bueno... en realidad el proyecto SETI no tiene mucho que
co que tenga como IP de origen la dirección de loopback.
ver con todo esto, pero no he podido resistirme a poner
Aunque tengamos protecciones contra ip-spoofing, sería
alguna chorrada en este artículo (es que si no, no me que
una temeridad absurda hacer esto, pudiendo directamente
do a gusto).
reconocer la fuente por el DISPOSITIVO, y no por la
Esta opción lo que hace es logear cualquier paquete que dirección IP, que es mucho más fácil de ser suplantada. Por
tenga como dirección IP de origen o destino una dirección tanto, en lugar de -s 127.0.0.1 utilizaremos: -i lo.
imposible. Esto también incluye las direcciones IP spo
ofeadas, ya que una dirección que no pertenece a la red
en la que estamos es en realidad una dirección imposible. Empezamos ya con las reglas. Todo lo que hay a partir de
aquí podría ser modificado según fuese cambiando nuestro
escenario.
Empezamos configurando la tabla NAT, de la cual ya os

habló con detalle Vic_Thor.
Aquí, aparte de establecer la política DROP por defecto,
es decir, política paranoica, estamos utilizando un meca Si recordamos la configuración de Zeus, éste tenía una ta
nismo muy sencillo para evitar problemas MIENTRAS esta bla NAT que dirigía todos los puertos abiertos a una única
mos configurando las iptables. IP, que era la de Cerbero. Lo que estaba haciendo Zeus era
simplemente pasar la bola, aplazando la cuestión, para
El script de iptables normalmente no tardará más de un
que fuese Cerbero quien realmente se encargase del NAT.
segundo en ser cargado en Cerbero (depende de cómo de
potente sea la máquina), pero durante ese segundo pue Como vemos, Cerbero repartirá los paquetitos de la si
den ocurrir mil cosas. ¿Qué pasará con los paquetes que guiente forma:
nos lleguen durante ese segundo? Podría ser el momento
ideal para que se nos colasen, y todos los esfuerzos poste Los paquetes a los puertos 80 y 21 (www, y ftp) para
riores serían en vano. Persefone.
Mientras el script se esta cargando hemos de asumir que Los paquetes a los puertos 5000 a 5005 para que
estamos totalmente desprotegidos por lo que, antes de to Eolo pueda tener DCC.
car nada, tenemos que asegurarnos de que se cierran to
das las puertas, y no las abriremos hasta que no hayamos Los paquetes a los puertos 5010 a 5015 para el DCC
terminado de configurar todo. de Poseidon.
Para ello, insertamos una regla en la primera posición de Los paquetes al puerto 4662 para el emule de
cada cadena (INPUT, OUTPUT, y FORWARD), que directa Poseidon.
mente rechace todos los paquetes.
40/68
Una vez que ya se han establecido los caminos para cada permitimos los mensajes Time Exceeded para que funcio
paquete, luego tendremos que analizar la cadena ne el traceroute.
FORWARD, para ver cómo se trata independientemente
cada uno. El resto de mensajes ICMP pueden ser prescindibles, y
cualquier otro mensaje ICMP que se reciba o se envíe será
Por último, tenemos aquí las reglas de enmascaramien logeado, y podremos encontrarlo fácilmente en el log bus
to, las cuales son imprescindibles para que el router adsl cando la cadena ICMP, ya que hemos incluido ese pre
(Zeus) permita el tráfico de todas las máquinas que hay fijo para el log.
detrás 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). Como ya explicó Vic_Thor, hay que mantener las conexio
nes ya establecidas, y rechazar las inválidas (paquetes con
Por si alguien se lía con el símbolo \, sirve simplemente
algún parámetro que no se corresponda con ninguna
para cortar una línea y poder continuarla en la línea si
conexión establecida).
guiente (como el guión que usamos en castellano para
cortar las palabras). Por tanto, los paquetes TCP serán analizados sólo si son
para establecer una nueva conexión (flag SYN), pero una
vez que la conexión ya ha sido aceptada, el resto de pa
¿Qué más me queda por decir sobre las reglas de ICMP en quetes de la misma circularán libremente a través de
iptables después de todo lo que conté ya en artículos ante nuestras iptables.
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 Aquí tenemos un bonito surtido (como los de Cuetara) de
otras aplicaciones. En cambio, no tenemos porque aceptar diferentes tipos de escaneo de puertos que vamos a fil
recibir mensajes ECHO-REQUEST (ping), ya que quizá no trar. Todos estos tipos de escaneo los puede hacer la mag
tenemos interés en responder nosotros al ping. nífica herramienta NMAP, y algunos de ellos también pue
den ser utilizados por otras herramientas.
Me he ahorrado trabajo al definir unas reglas generales de
ICMP para todas las cadenas, pero en realidad habría que NMAP intenta saltarse los firewalls utilizando, entre otras
definir unas reglas específicas para cada cadena si quere cosas, diferentes combinaciones de flags TCP. Ya se ha
mos ser puristas. hablado sobre esto en la revista.
Por ejemplo, el PING podría permitirse desde Hades y Gaia Con esta serie de reglas estamos rechazando todos los pa
hacia Cerbero, para que las máquinas de estas redes pu quetes que tienen los flags que se sabe que son utilizados
diesen comprobar que el firewall/router está vivo. Pero no para este tipo de escaneos, y por otra parte estamos lo
habría motivo para permitir un PING desde la red Olimpo, geando el escaneo. Como un escaneo completo suelen ser
ya que no tenemos por qué dar ninguna información al ex 65535 paquetes (uno por cada puerto TCP), sería una lo
terior, donde están todos esos hackers malos. cura almacenar todo esto en el log. Por eso limitamos a
que sólo guarde registro de 5 de estos paquetes por minu
Como las consecuencias de esto son mínimas, he preferido
to. Con eso tenemos suficiente para detectar el intento de
ahorrar trabajo y crear unas reglas genéricas de ICMP, pe
escaneo, pero sin saturar nuestros logs.
ro insisto en que, si queréis perfeccionar vuestro firewall,
tendríais que definir reglas independientes para cada posi
ble camino. También 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 artículo, no significa
Las tres cadenas anteriores, reglas_icmp, keep_state, y
que lo haya hecho en las mías.
flags_tcp, sólo quedaron definidas, pero no se especificó
Os propongo como ejercicio que modifiquéis estas iptables en ningún momento sobre qué paquetes debían ser aplica
para que haya reglas independientes de ICMP para cada das.
cadena. En esta sección de nuestro script indicamos que estas 3
cadenas han de ser aplicadas en todos los sentidos:
Aparte de los ping y pong también tenemos los clicks de
INPUT, OUTPUT, y FORWARD.
playmobil, esto.... quiero decir.... que aparte de los ping y
los pong también permitimos los mensajes Destination Si quisiésemos aplicar reglas diferentes de icmp para cada
Unreachable, para que funcione el mecanismo de camino, tendríamos que eliminar estas reglas, ya que pre
PMTUD que ya hemos visto a lo largo del curso. También valecerían sobre las que pusiésemos después.
41/68
También es posible que quisiéramos 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. Si bien Gaia puede acceder a los servicios de Hades, Hades
de ninguna manera puede acceder a Gaia.
En cambio, las reglas de keep_state si que las necesitare
Precisamente aquí es donde se encuentra la esencia de las
mos siempre para cualquier camino.
redes con DMZ. Una DMZ es básicamente una zona sus
Propongo como ejercicio también que modifiquéis esta ceptible de ser hackeada. Si un hacker lograse hacerse con
sección a vuestro gusto. el control absoluto de la red DMZ, estaríamos perdidos si
hubiese algún 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 lograrán
llegar a nuestra red interna (Gaia), a no ser que consigan
además hackear nuestro firewall (Cerbero).
En nuestro escenario tenemos 3 redes: Gaia, Hades, y
Olimpo. Por tanto, habrá 6 posibles caminos entre estas ¿Cómo puede entonces funcionar la comunicación de Gaia
redes: hacia Hades si todo el tráfico de Hades hacia Gaia está ce
rrado? ¿No tendríamos que permitir al menos las respues
De Gaia a Hades
tas que tenga que enviar Hades a Gaia cuando por ejemplo
De Gaia a Olimpo Eolo se conecta por SSH a Persefone?
De Hades a Gaia Pues claro que sí, pero esta situación ya la tenemos con
De Hades a Olimpo templada en la cadena keep_state. Es Eolo quien envía
el paquete SYN que establece la conexión entre Eolo y
De Olimpo a Gaia Persefone. Una vez establecida la conexión, nuestra cade
De Olimpo a Hades na keep_state prevalecerá sobre la regla que tenemos
aquí:
A partir de esta sección, vamos detallando las reglas que iptables -A hades_gaia -j DROP
tendrá que seguir cada uno de estos 6 caminos. El primero
de estos, De Gaia a Hades, es el que describimos aquí. ¿Y por qué prevalece? Pues lógicamente, porque la inser
tamos antes, concretamente en este punto:
Como sabemos, Gaia es la red interna, y Hades la red
DMZ. iptables -A FORWARD -p tcp -j keep_state
Típicamente, en una configuración con DMZ, la red interna Normalmente, si vemos en el log alguna línea con el prefi
puede tener acceso a la DMZ para poder utilizar los mis jo HADES->GAIA: , que es el que hemos puesto para
mos servicios que la DMZ está dando al exterior (es decir, este camino, tendremos que estar alertas porque es una
a Internet o, en nuestro escenario, la red Olimpo, que es posible señal de que hemos sido atacados a través de la
la intermediaria directa con Internet). DMZ.
Aparte de poder utilizar los servicios de la DMZ, es tam

bién muy típico que el administrador de sistemas tenga
también su PC dentro de la red interna, y que se abra al
gunas puertecillas para poder administrar remotamente los Esta es otra sección que podría ser mejorada enormemen
servidores sin tener que estar yendo de una máquina a te, y que también os dejo como ejercicio.
otra. En este caso, hemos abierto una administración re
mota del servidor Persefone a través de SSH, a la cual En principio, permito que los servidores de la DMZ tengan
sólo tendrá acceso la máquina Eolo. acceso total a Internet. Así, si en algún momento el admi
nistrador se sienta a los mandos para bajar actualizaciones
Quizá la línea mas importante en esta sección es esta: de software, o cualquier otra cosa, no tendrá limitado el
acceso.
iptables -A FORWARD -i $gaia -o $hades -j gaia_hades
En cambio, esta no es la opción más segura, y lo mejor
Todo lo que entre por el dispositivo que conecta a la red
sería limitar el acceso al exterior de forma inteligente. Así,
Gaia (-i $gaia) y salga por el dispositivo que conecta a la
si alguien llegase a penetrar en algún servidor, tendría
red Hades (-o $hades) tendrá que atravesar la cadena
muy limitado el acceso al exterior. ¿Qué tal, por poner un
gaia_hades que acabamos de crear.
ejemplo, limitar la salida del protocolo TFTP? ¿Recordáis
Una vez más, insisto en que es más seguro identificar los aquellos sistemas clásicos para meter troyanos en una má
caminos por los dispositivos de entrada y salida, más que quina medio-hackeada?
por direcciones IP.
42/68
En una configuración totalmente paranoica, esto sería im
pensable. Pero como estamos considerando una
configuración más bien doméstica, es normal que los usua
rios de la red interna utilicen ciertos servicios como IRC,
Aquí es donde se encuentra reflejada la funcionalidad de
redes P2P, ...
la red DMZ.
Así que en primer lugar, por supuesto, tenemos que dejar
En primer lugar, para cualquier camino que venga desde
que pasen las respuestas a nuestras consultas DNS,
Olimpo tenemos que permitir los paquetes que tienen co
tal y como vimos antes.
mo IP de origen la de nuestro servidor DNS (o servido
res, si tenemos configurado más de uno), como protocolo Ahora tenemos que recordar el artículo sobre DCC de la
UDP, y como puerto de origen el 53 (el puerto de DNS, serie RAW. Cuánto tiempo hace de aquello ya, ¿verdad?
llamado con el alias domain).
En nuestro caso, hemos abierto 6 puertos de DCC para ca
Por supuesto, igual que tenemos que dejar entrar las res da máquina de la red interna. Tanto Eolo como Poseidon
puestas a nuestras consultas DNS, también tenemos que tendrán que configurar sus clientes de IRC (mIRC, xchat,
dejar salir nuestras consultas. Esto sería responsabilidad o el que sea...) para que el DCC vaya sólo a través de los
de los caminos que van hacia Olimpo, y no los que vie 6 puertos que tienen asignados.
nen desde Olimpo, como este. Por ejemplo, el camino an
terior, hades_olimpo, iba hacia Olimpo, pero al permitir Aparte de esto, sólo nos queda el Emule de Poseidon, que
todo el tráfico, implícitamente estamos permitiendo tam necesitará tener abierto el puerto 4662 de TCP para fun
bién las consultas DNS. cionar correctamente.
Aparte del DNS, tenemos que permitir la entrada de co Por supuesto, todo lo demás tendrá que ser rechazado.
nexiones hacia los puertos de ftp y web. El puerto de ssh, Aunque en realidad será difícil que nos lleguen paquetes
por supuesto, no estará abierto hacia la red Olimpo, ya que no encajen aquí, ya que previamente la tabla NAT se
que sólo Eolo (que pertenece a la red Gaia) puede admi encargó de redireccionar hacia Gaia sólo los puertos que
nistrar remotamente a Persefone. ya hemos tratado.
Aquí de nuevo estamos permitiendo que los usuarios de la Aquí creamos 3 nuevas cadenas de reglas, que se aplica
red interna tengan acceso de salida total hacia Internet. rán a cualquier paquete que tenga como IP de destino la
del propio Cerbero: una cadena para los paquetes que
También os dejo como ejercicio que limitéis este acceso, provienen de la red Olimpo, otra para los de la red Gaia,
si queréis, aunque en general en una red doméstica lo más y otra para los de la red Hades.
conveniente será dejarlo abierto, para que podamos mo
vernos a nuestras anchas por Internet desde nuestro PC. En el caso de la red Olimpo, sólo permitimos que nos trai
ga de vuelta la respuesta a las consultas DNS que poda
En cambio, en una red corporativa, podría ser interesante mos hacer desde el propio Cerbero. En realidad, hasta esto
limitar el acceso de los empleados, para que por ejemplo podríamos quitarlo, ya que normalmente nunca nos senta
no puedan conectarse a chats, o a otros servicios no de remos a los mandos de Cerbero para hacer nada, por lo
seados. que no hay motivo para necesitar hacer consultas DNS.
En cualquier caso, la mejor forma de limitar este acceso al En el caso de Hades, no permitimos ningún trafico hacia
exterior no serían las iptables, si no un proxy, como por Cerbero, faltaría más... Si hemos dicho que la DMZ (Ha
ejemplo el famoso Squid que, entre otras cosas, nos per des) es la red potencialmente más vulnerable, de ninguna
mitirá por ejemplo limitar qué paginas web pueden ver los manera podemos permitir ningún tipo de acceso desde es
empleados, y cuáles no (evitamos así una de las mayores ta red hacia el corazón de nuestro sistema de seguridad,
pérdidas de tiempo de los empleados, que es la pornogra que es Cerbero.
fía).
Si vemos en los logs alguna línea 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
través de ahí.
Nuestra configuración no es muy purista que digamos.
¡Puertos abiertos en la red interna! Bastante buenos estamos siendo ya permitiendo que des
de la DMZ se pueda hacer ping al firewall (por la cadena
43/68
reglas_icmp), por lo que ésta sería una de las reglas que

interesaría modificar a la hora de personalizar las reglas
de ICMP para cada camino. Para activar todo el script que hemos creado sólo nos falta
una cosa: eliminar las reglas de bloqueo que colocamos al
Por último, con respecto a Gaia, tenemos más de lo mis principio de cada cadena (INPUT, OUTPUT, y FORWARD).
mo. En este caso, teóricamente, no sería tan grave permi
tir algún tipo de acceso hacia Cerbero, pero... ¿para qué? Por tanto, con sólo borrar la regla número 1 de cada cade
na: hop! iptables funcionando.
Si no hay ningún motivo por el cual tengamos que comuni
carnos desde Gaia hacia Cerbero, mejor cerrar todo y cu Por cierto! Antes de que me vaya, por si alguien no lo sa
rarnos en salud. be, todas las máquinas de Hades y Gaia tienen que tener
como puerta de enlace a Cerbero (con la IP de Cerbero
que corresponda según la red en la que estemos), y como
máscara de red 255.255.255.0. Es decir, éstas serían
las puertas de enlace de cada máquina:
Como ya dije, en principio permitimos que el propio Persefone: 192.168.2.1

Cerbero pueda hacer consultas DNS, aunque perfectamen
te podríamos eliminar esta opción. En cualquier caso... Eolo: 192.168.3.1
¿para qué lo íbamos a querer, si todo el resto del tráfico
está cerrado? Poseidon: 192.168.3.1
Como vemos, cerramos todo el tráfico desde Cerbero hacia

el exterior, así que olvidaos de navegar por Internet desde
Autor: PyC (LCo)
el firewall.
44/68

Curso HXC de TCP-IP PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Curso HXC de TCP-IP PDF

Caricato da

Copyright:

Formati disponibili

CURSO DE TCP/IP

1.Introducción a la introducción. glosario de términos; si no realmente llegar

PC PASO A PASO Nº 17 Página 31

más dudas después de terminar el tema de 2. El concepto fundamental de

No sé qué resultados tendrá mi enfoque, pero

¿Qué esperabais? ¿Que mi curso de TCP/IP

El juzgar si nuestro enfoque es mejor que el

Como veréis, mi enfoque intenta mostrar los

Por supuesto, después de este primer artículo

Página 32 PC PASO A PASO Nº 17

Dios mío, como haya entre los lectores algún

Al margen de si tiene sentido o no la parrafada,

Ahora vamos a plantearnos una serie de

Ahora vamos a analizar un poco en qué ha

En primer lugar, lo que más nos llama la

Igual que los cirujanos tienen su propio

Pero, a pesar de que todos estos lenguajes

PC PASO A PASO Nº 17 Página 33

Los dos doctores se han apoyado en un medio

Página 34 PC PASO A PASO Nº 17

entre los dos interlocutores. Nos da

Una vez que el intérprete ha traducido la frase

3. Las capas de TCP/IP

¡Al fin vamos a ver la relación que tiene todo

PC PASO A PASO Nº 17 Página 35

funciones para asegurarme de que el mensaje

Si después me da por programar un cliente

Página 36 PC PASO A PASO Nº 17

Este es el En el caso de las máquinas, hay que tener en

Configuración de TCP/IP en Windows. Para los impacientes, deciros que aquí es

PC PASO A PASO Nº 17 Página 37

Las funciones de esta capa son muchas, pero

¿Cuál es la responsabilidad de esta capa?

¿Cómo puede llegar hasta su destino la carta

Página 38 PC PASO A PASO Nº 17

correspondiente. En esa oficina, comprueban la

Comparación entre los elementos del correo postal y los elementos

Igual que existen las oficinas de correos, también

PC PASO A PASO Nº 17 Página 39

Pero, ¿qué ocurriría si el doctor PyC no Os remito de nuevo al número 14 de la revista,

Página 40 PC PASO A PASO Nº 17

5.- Seguiríamos así hasta que el doctor (receptor) en teoría

PC PASO A PASO Nº 17 Página 41

Página 42 PC PASO A PASO Nº 17

En el caso de TCP, existen unos sobres

3.3. La capa TCP: El tamaño de

Pero, ahora que sabemos que el protocolo

PC PASO A PASO Nº 17 Página 43

Página 44 PC PASO A PASO Nº 17

PC PASO A PASO Nº 17 Página 45

desde que comienza la transferencia del operativo diciéndole ale, ya está

El valor de esa variable usuario no lo asignó

Como es el sistema operativo el que maneja

Página 46 PC PASO A PASO Nº 17

Si repasáis mejor el artículo de la serie RAW

PC PASO A PASO Nº 17 Página 47

de transporte, si no también otros como UDP. 4.4. En el sistema operativo de

Es decir, la capa de enlace depende de la

Los tres paquetes que forman el archivo, con sus cabeceras

Una vez que los paquetes ya están listos, se

Página 48 PC PASO A PASO Nº 17

Esto significa que lo que circula por el cable

5.- Seguiríamos así hasta que el doctor (receptor) en teoría

En el caso de TCP, existen unos sobres

desde que comienza la transferencia del operativo diciéndole ale, ya está