Introducción al protocolo TCP/IP

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: (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)

PORT SCANNING
Escaneando Ordenadores
Remotos: Tipos de Scaneos
Para utilizar programas/herramientas de escaneo como el NMAP necesitamos conocer

la forma en que se establecen las conexiones y adentrarnos en su funcionamiento. Este
artículo te ilustrará sobre el tema.
1- Avanzando en el análisis de Ahora imagina que se publica una vulnerabilidad

sistemas para algún demonio (proceso/programa) de
algún sistema operativo como IRIX, FreeBSD
Ya hemos comentado la importancia que tiene o determinada versión de Linux. Nuestro usuario
el análisis previo de un sistema de cara a coge su lista y busca coincidencias, ¡acaba de
saltarnos su seguridad, hoy en día existen encontrar un centenar de máquinas vulnerables
numerosas técnicas de escaneo de puertos y en las que obtener privilegios de administrador!
la mayoría ya han sido implementadas; Un ¿A que no te haría gracia estar en la lista de
ejemplo claro es NMap del que ya se habló en nuestro amigo?
la revista.
Por ese motivo resulta interesante conocer
mejor el funcionamiento de diferentes técnicas
! Muy importante de "port scanning" y de como usar la información
obtenida para explotar las debilidades de un
MUY IMPORTANTE: Para cuando leas este artículo, en sistema así como la forma de protegernos de
la Web de PC PASO A PASO (www.hackxcrack.com) estos ataques en la medida en que esto sea
podrás descargarte el artículo Técnicas del Port Scannig posible ;-)
y uso del NMAP, que fue publicado en el número 9 de
PC PASO A PASO. 2- Algunas nociones fundamentales
Ambos artículos se complementan y nuestra intención es Es interesante conocer algunas cosas acerca
que puedas comprender este texto aunque no comprases del protocolo TCP de cara a comprender varias
en su momento el número 9 de PC PASO A PASO. cosas que leerás a continuación y por ello
volveremos a mencionar algunos de los
conceptos de artículos anteriores.
Quizás seas de los que piensa que un 'simple
escaneo de puertos' no es la mejor forma para El protocolo de control de transmisión (TCP) es
entrar en un sistema... aunque sea orientado a conexión y esto implica que se
simplemente uno de los pasos previos genera un circuito (virtual) entre dos host's
evidentemente te equivocas, imaginemos por cuya comunicación se considera fiable, TCP
ejemplo que un usuario aburrido se dedica a asegura unas condiciones
jugar con el 'Intesné' escaneando la red y tiene óptimas para el circuito establecido y utiliza lo
una lista con 250.000 host's con interesante que se denomina "acuse de recibo" para
información acerca de su sistema operativo, garantizar que los datos lleguen correctamente
puertos abiertos, etc. a su destino. Cuando queremos establecer una

PORT SCANING - Tipos de escaneo - PORT SCANING - Tipos de escaneo - PORT SCANING
conexión ambas partes deberán estar de acuerdo en participar 3. El número de secuencia ack (o acknowledge number) es
o dicha conexión no se podrá realizar. lo que permite validar los segmentos que van llegando a un
host, con este fin se coloca en el campo el número de
SEGMENTO TCP secuencia del segmento incrementado en 1, dicho byte
espera ser recibido en el siguiente envío. **
La cabecera de un segmento tcp (20 bytes normalmente)
es la siguiente: ** Los puntos 2 y 3 es, para que nos entendamos, la
forma que tiene el protocolo TCP de no perder ningún
paquete. Si estamos enviando a un compañero un
archivo Word de un par de megas, este se corta en
pequeños trocitos y el receptor debe recibirlos todos,
no puede perderse un solo paquete. Vale, ya se que
explicarlo así es muy poco técnico, pero quiero que
se entienda.
4. La longitud de la cabecera en múltiplos de 32 bits. **
** Hemos dicho que el archivo Word es cortado en

paquetitos ¿verdad? Bueno, pues cada paquetito
es como una carta. La CABECERA de un paquete TCP
es como el sobre de una carta, es donde figuran los
datos del remitente (el que envía la carta) y del
destinatario (el que debe recibir la carta). Dentro del
Explicaré muy brevemente los campos ;) ** sobre ¿qué encontramos?, pues lo importante, el
contenido, los DATOS, lo que quieren comunicarnos,
** Seguramente no comprenderás muchos de los que nos ha tocado la lotería y cosas de ese tipo ;p
conceptos que a continuación se detallarán, no te Pues bien, un paquete TCP es exactamente igual que
preocupes demasiado, la idea es que empiecen a una carta, tenemos una CABECERA (el sobre) y
sonarte un montón de nombres raros y tener una unos DATOS (en este caso un cachito del archivo
visión global del asunto. Para comprender a la WORD que estamos enviando).
perfección una conexión TCP/IP necesitarías
programar sockets en lenguaje C, algo que no 5. Ahora lo que nos interesa especialmente, el campo
tardaremos mucho en publicar por el momento no 'flags' (banderas):
te agobies e intenta simplemente tener una visión
general. Para practicar todo lo que a partir de ahora Tenemos varios flags para disfrute personal y son
se explicará puedes emplear el NMAP. URG|ACK|PSH|RST|SYN|FIN ahora te explico algo más acerca
de ellos, como verás no tienen ningún misterio :)
1. Puerto origen y destino, bastante explícito :P
URG, indica que el segmento transporta datos urgentes.
2. Número de secuencia, al intentar establecer una conexión
los host's que intervienen en el proceso eligen un número ACK, indica que el número de secuencia ack de la cabecera
aleatorio para empezar a contabilizar bytes que viajarán en es válido.
los segmentos de datos de la conexión. Los sucesivos
segmentos que se envíen llevarán como número de secuencia PSH, fuerza el envío inmediato de los datos recibidos al nivel
el número aleatorio elegido al principio más el de aplicación, que serían las aplicaciones finales a nivel de
número de bytes enviados hasta ese momento. usuario.

RST, indica que la comunicación debe reiniciarse. la cabecera IP y TCP así como las posibles opciones TCP si
las hay. El host A genera una llamada a connect () para el
SYN, durante la conexión indica el proceso de sincronización. propósito.
FIN, indica que el host desea finalizar la conexión. 2) Ahora el host B enviará la validación para el segmento
anterior y activará el flag ACK y en el número de secuencia
6. El tamaño de la ventana es el número de bytes que ack colocará el número de secuencia del segmento recibido
esperan ser recibidos sin necesidad de ser validados por + 1, como el proceso de sincronización no ha terminado el
parte de un host y puede variar durante la conexión activa. flag SYN sigue levantado.
7. La integridad de los datos y la cabecera tcp se 3) El host A sabe que el host B ha validado la petición al
pueden verificar mediante el checksum o suma de verificación. recibir el segmento pero ahora el host B está esperando a
que se valide su segmento. El host A envía un segmento
8. El puntero urgente (que se utiliza junto al flag URG) colocando el valor oportuno en el número de secuencia ack
indica el número de secuencia del último byte que se considera y activando el flag ACK, el flag SYN no viaja levantado esta
parte de los datos fuera de banda (urgentes). vez. En este punto la conexión se ha completado con éxito.
9.Opciones TCP como el tamaño máximo de segmento, el ¿COMO SE FINALIZA UNA CONEXIÓN ORDENADA TCP?
window scale y otras que de momento no vamos a ver aquí.
10,11. Un campo reservado y de datos respectivamente.
¿COMO SE ESTABLECE UNA CONEXIÓN ORDENADA TCP?
El proceso se denomina three-way handshake (o saludo en

tres fases)
Ahora te explico que significa eso, no te impacientes, ya

sabes que aquí siempre lo explicamos todo para que no se
nos escape ningún detalle :)
1) El host A genera una llamada a close() para finalizar

la conexión y se envía un segmento con el flag FIN levantado.
Es posible que no comprendas el esquema pero tranquilidad
que ahora te lo explico paso a paso ;-) seguro que lo 2) El host B valida cualquier información previa enviando
entenderás mejor: un segmento con el flag ACK levantado.
El proceso para recibir una petición de conexión implica estar 3) Para que el host A pueda cerrar la conexión el host
preparado para llevar a cabo una serie de llamadas a funciones B debe enviar un segmento con el flag FIN activado.
como lo son bind (), listen () o connect () de las que 4) Se valida el segmento anterior y la conexión se cierra con
hablaremos en el texto de forma genérica. éxito.
1) Cuando el host A desea establecer una conexión ** Todo esto ocurre de forma transparente al usuario
mediante un circuito TCP envía un segmento al host B, el cada vez que establecemos una conexión con un pc
segmento llevará el flag SYN levantado indicando el proceso remoto (por ejemplo cuando hacemos un simple PING
de sincronización y no suele llevar ningún tipo de datos salvo o nos conectamos a una Web con el navegador). De

hecho suceden muchas más cosas, pero nos en lugar de eso la abortaremos mediante un paquete con
conformamos con que captes el concepto general de RST, ¿y eso por qué? Te preguntarás, la respuesta es muy
que establecer una conexión es un proceso de 3 pasos sencilla, si ya sabemos que hay alguien al otro lado (tras
y cerrarla es un proceso de cuatro pasos y que los recibir SYN|ACK) para que seguir intentando conectar ¿? así
flags (BANDERAS) tienen mucho que decir en este evitamos establecer la conexión completa y es poco probable
proceso :) que nuestro escaneo quede registrado que es de lo que se
trata ;) este escaneo probablemente pasará desapercibido
3- Las técnicas de port scanning pero recuerda, eso sí, que se necesitan privilegios de
administrador para usar esta técnica y que el sistema pueda
Existen muchas técnicas para descubrir qué puertos tiene montar ese tipo de paquetes, a este tipo de escaneo se le
abiertos un host y determinar que servicios están corriendo conoce también como escaneo medio abierto.
e incluso bajo que privilegios, pero lo más importante es
hacerlo de forma sigilosa sin que la actividad quede registrada - TCP FIN, aunque el escaneo TCP SYN no suele dejar
en los logs de nuestra víctima y evitar que los sistemas de rastro en los logs del sistema y su detección puede ser algo
detección de intrusos (IDS) nos apunten como origen del complicada hay algunos entornos sensibles al escaneo SYN
escaneo. Te aseguro que a muchos usuarios no les hará como aquellos en los que hay filtros de paquetes o firewalls
gracia que les toques los... puertos :P y por otro lado existen utilidades que registrarán los intentos
de conexión SYN. Para estos casos puede resultar de interés
Vamos a ver detalladamente varias de las técnicas de escaneo echar mano al escaneo sigiloso FIN (o stealth scan), se
ya conocidas, algunas son una maravilla :) y otras no tanto fundamenta en el hecho de que los puertos abiertos ignoran
pero en cualquier caso debes conocerlas para poder adaptar los paquetes recibidos con el flag FIN (vacío) y los cerrados
mejor el escaneo a tus necesidades jeje. Ya empezaste a responderán con RST. Como se dijo en su momento al
leer acerca de ellas cuando tratamos en la revista el NMap presentar Nmap los sistemas de Micro$oft entre otros no
pero ahora veremos con más detalle esas y otras técnicas son susceptibles a este tipo de ataques pues no siguen las
como el Idle Scan :) pautas establecidas, quien lo diría xD ¿verdad?
- TCP CONNECT (), mediante esta técnica no - ACK scan, para esos ambientes hostiles con la
necesitarás ningún tipo de privilegio especial como sucederá presencia de cortafuegos puede interesar nmapear las
con otros tipos de escaneo como TCP SYN, y además es una reglas de filtrado. Mediante esta técnica podemos enviar un
técnica muy rápida puesto que podemos efectuar varias paquete con el flag ACK con los números de secuencia y ack
conexiones en paralelo. Su funcionamiento (la mayoría ya de forma incorrecta o aleatoria de manera que recibamos
lo habéis deducido) es el siguiente: intentamos establecer un paquete de control (ICMP unreachable, inalcanzable)
una conexión con un puerto determinado si el puerto está o no se reciba respuesta, en tal caso el puerto se encuentra
abierto la llamada a connect () tiene éxito y se nos retornará filtrado y en caso contrario la conexión será reiniciada y las
el valor oportuno en caso contrario la llamada fallará. El conexiones al puerto no estarían filtradas. Como habrás
problema reside en que los intentos de conexión se registrarán deducido, no puedes usar este tipo de escaneo para averiguar
automáticamente en el sistema y en principio no nos interesa los puertos abiertos. Si deseas además encontrar los puertos
en absoluto dejar huellas de ningún tipo. abiertos y además clasifica los puertos según se encuentren
filtrados o no, existe otra técnica conocida como Window
- TCP SYN (), hace un momento te acabo de explicar Scan que además aprovecha anomalías el tamaño de la
como se establece una conexión completa, mandamos un ventana TCP por parte de varios sistemas operativos para
paquete con el flag SYN tal y como se haría normalmente determinar si el puerto está abierto.
al intentar establecer una conexión y ahora la máquina
remota nos responde amablemente con SYN|ACK hasta aquí - UDP scan (User Datagram Protocol scan), antes de
va todo perfecto pero ahora nosotros para llevar la contraria nada aclarar que se trata de un escaneo mediante un
NO vamos a responder con ACK para establecer la conexión, protocolo no orientado a conexión de manera que no existe

un circuito virtual entre hosts ni tampoco garantía de entrega enviamos un paquete falso como si fuésemos el host ZOMBIE
alguna de los paquetes enviados. Se utiliza cuando queremos de manera que la respuesta del host VICTIMA irá para el
averiguar que puertos udp (un puerto puede ser tcp y udp host tal y como muestra el ejemplo, supondremos que el
al mismo tiempo pues difieren en el tipo de protocolo pese IPid del zombie es ahora 100 e ignoraremos a que puerto
a tener el mismo número identificador) están abiertos, si se dirige junto con otros datos irrelevantes para hacer el
tras mandar el paquete se recibe un mensaje de control ejemplo un poco más inteligible:
informando del error el puerto está cerrado y en caso
contrario, no recibir nada, se encuentra abierto. Esta técnica Lo primero es obtener el IPid del zombie escogido (100),
es muy poco precisa ya que si por ejemplo se filtran las
conexiones udp aparecerán como abiertos puertos que están
bloqueados. Además el número de conexiones udp suele
estar limitado por los sistemas de manera que el escaneo
puede ser bastante lento, y he dicho que suele limitarse
porque existe cierto sistema operativo cuyo nombre no
recuerdo ;) que no atiende a las especificaciones establecidas Tras la primera consulta procedemos,
por los RFCs de manera que el escaneo irá mucho más
rápido en los sistemas de la compañía Micro$oft. Por el
mismo motivo el escaneo denominado Null Scan o escaneo
nulo que se basa en no levantar ninguna bandera tampoco
funcionará al usarlo contra una máquina Window$ :(
- Xmas Scan: muy similar al escaneo nulo esta técnica Chequeamos el IPid para ver si el puerto se encuentra
envía un paquete con todas las banderas levantadas. Si el abierto,
puerto está abierto debe ignorar el paquete.
- Idle scan, esta es para mí una de las técnicas más

interesantes y que realmente interesa poder usar siempre
que se pueda ya que es altamente sigilosa y no dejamos ni
rastro de nuestra IP :-) esto es así debido básicamente a ¿Qué ha pasado arriba?
que no será el origen del escaneo... o mejor dicho no para
la máquina víctima de nuestro Idle scan jeje. Con lo leído Pues lo que ha ocurrido es que ahora el IPid del zombie se
hasta ahora y para tu total comprensión del Idle Scan lo ha incrementado en 1 tras rebotar al zombie nuestra petición
único nuevo que deberías saber es que los paquetes que se de conexión. Ahora tu que eres una persona muy atenta
envían llevan un identificador de fragmento que se suele observas de nuevo el IPid de nuestro amigo el zombie xD
incrementar cada vez que se envía uno. Esta técnica de y observas que efectivamente vale 100 + 2 = 102 y eso
escaneo utiliza hosts intermedios o los llamados zombies significa que el puerto está abierto :-) pero como no siempre
para escanear un objetivo, ahora te explico la forma de tendremos esa suerte ahora veremos que ocurre si el puerto
hacerlo: está cerrado, tomaremos los mismos datos previos pero con
esa diferencia respecto al estado del puerto:
Elegir un host zombie para determinar su identificación IP
(IPid), ahora enviamos un paquete para probar un puerto
en nuestra víctima desde el host zombie (ya deberías saber
que podemos falsear la dirección IP tal y como se comentó
en el artículo del NMap, pero nos interesa obtener los
resultados ahora). El resultado puede ser que el puerto este
abierto o cerrado (--no me digas) en el primer caso NOSOTROS

linux $ ftp ftp.netscape.com

Connected to ftp.gftp.netscape.com.
220-15
220 ftpnscp.newaol.com FTP server (SunOS 5.8) ready.
Name (ftp.netscape.com:linux): anonymous
¿Y ahora que ha ocurrido? 500 'AUTH SSL': command not understood.
SSL not available
Pues muy sencillo :-), al rebotar al zombie la petición de conexión 331 Guest login ok, send your complete e-mail address as password.
la víctima (a la que también se le puede llamar host remoto :P) Password:
nos dice ¿SYN@#~?¿eso qué es? Como le suena raro y 230-The response `' is not valid.
curiosamente el puerto está cerrado nos reinicia la conexión 230-Next time please use your e-mail address as password.
mediante RST. Ahora miramos de nuevo el IPid de nuestro zombie 230 Guest login ok, access restrictions apply.
y nos damos cuenta de que solo ha incrementado en una unidad Remote system type is UNIX.
desde la última vez por lo que el puerto estaba cerrado. Si te fijas Using binary mode to transfer files.
la IP que recibe la víctima es siempre la de la máquina zombie ;- ftp> syst
), muy bien pues ahora imagina que nuestra víctima tiene habilitado 215 UNIX Type: L8 Version: SUNOS
un cortafuegos que tiene permiso para dejar pasar los paquetes ftp>
cuya IP coincida con la de nuestro zombie (sucede por ejemplo en
las relaciones de confianza), ¡acabas de saltarte el cortafuegos por linux $ telnet 131.215.48.89 21
la cara!. Espero que hayas comprendido bien el funcionamiento de Trying 131.215.48.89...
esta potente técnica de escaneo que como ves es muy efectiva. ...
El principal problema es encontrar hosts que tengan números IPid 220 secant FTP server (Version wu-2.6.1(2) Thu Nov 29 15:02:58
predecibles como serían las dedicadas a impresión puesto que PST 2001) ready.
tienen poca actividad o tráfico para llevar a buen término esta ftp> syst
técnica. 215 UNIX Type: L8
Hasta aquí hemos visto con detalle los tipos de escaneo más linux $ telnet 216.127.72.117
importantes y más utilizados. Te recuerdo que explicamos en un ...
artículo anterior la herramienta que aplica estas y otras técnicas Red Hat Linux release 7.2 (Enigma)
de port scanning que fue NMap, permíteme que te sugiera dicha Kernel 2.4.9-34 on an i686
utilidad si no te apetece programar tu propio escáner de puertos login: ^D
ahora que ya sabes como funciona el asunto :)
ANALIZANDO LA PILA TCP/IP
4- UN PASO MÁS: DETECCIÓN REMOTA DE SOs
A este método se le suele llamar Stack FingerPrinting y permite
Ni que decir tiene la importancia que tiene saber a que sistema
obtener conclusiones analizando la pila de protocolos
operativo nos enfrentamos ya que resulta fundamental de cara al
TCP/IP.
análisis y la penetración de un sistema así como la explotación
remota debido a fallas conocidas (e incluso desconocidas :P) en
Algunas formas de discriminar según el sistema operativo conocidas
alguno de los servicios, etc. Existen varias formas y utilidades que
se basan en:
nos permitirán obtener una huella digital (o fingerprint) de nuestra
víctima que nos sirva para discriminar un sistema operativo del
- Flag de fragmentación, en casos concretos se establece
resto, ahora veremos algunas.
por parte de ciertos SOs el flag DF (deshabilitar la fragmentación)
de la cabecera IP.
PRIMER CONTACTO
- Números de secuencia, se intentan encontrar patrones
Si ya has realizado conexiones directamente desde la consola ya
en los números iniciales escogidos al responder a una solicitud de
sea para mirar el correo, usar el FTP y/o cualquier otra cosa que
conexión como por ejemplo incrementar un valor X cada cierto
se pueda hacer mediante telnet te habrás fijado de que en muchos
tiempo o elegir valores totalmente aleatorios, devolver el mismo
casos se nos está dando una valiosa información de forma totalmente
número enviado, etc.
gratuita por parte del demonio que corre en ese puerto referente
a ellos mismos y en muchos casos la plataforma sobre la que corren
- Limitación ICMP, el sistema operativo Linux siguiendo las
:) pero no siempre lo tendremos tan fácil por lo que ahora veremos
normas y recomendaciones establecidas limita el número de
otras técnicas bastante más sofisticadas jeje.

mensajes del tipo ICMP unreachable (inalcanzable) a un máximo 5- PortSentry

de 20 por segundo pero no todos los sistemas operativos siguen
las reglas establecidas tal y como he comentado Mediante esta interesante utilidad que te puedes descargar de su
antes ;) sitio web oficial en http://www.psionic.com (pero suele venir el
paquete correspondiente en muchas de las distribuciones de Linux)
- Flag no determinado, enviamos SYN y uno de los 6 bits capaz de detectar y responder en tiempo real a un escaneo de
reservados para ver si se mantienen estos bits levantados en la puertos contra una máquina ¡incluso puede detectar escaneos
respuesta ya que algunos sistemas cerraran la conexión tras ocultos! aunque no en todos los casos evidentemente ;-), PortSentry
considerar el error, y como sobre gustos no hay nada escrito... :P se pone a la escucha en los puertos no utilizados que se indican
en /etc/portsentry.conf (por lo general) y guarda las direcciones
- Tipo de servicio, se puede comprobar uno de los campos IP origen del escaneo guardándolas a continuación en /etc/host.deny
del mensaje de control de errores ICMP de tipo unreachable para entonces se puede dejar en un host inválido como 999.999.999.999
ver si su valor es 0 u otro ya que lo normal es que su valor sea 0 mediante TCPWrappers o utilidades similares. Evidentemente
pese haber sistemas, como es el caso de Linux, en que se devuelve necesitarás algo más para proteger tu sistema como un cortafuegos
un 192 decimal (0xC0). y una política de seguridad adecuada... :P
- Opciones TCP, se pueden observar los valores devueltos, La línea de comandos básica para PortSentry teniendo en cuenta
su orden o si son soportadas o no ciertas opciones como lo son que estamos bajo Linux como super usuario es:
el window scale, o el MSS (tamaño máximo de segmento).
root # portsentry stcp, detectar escaneos ocultos TCP.
- Fragmentos solapados, dependiendo de la implementación
del sistema para el tratamiento de los fragmentos solapados, el root # portsentry atcp, como el anterior pero en modo avanzado.
nuevo fragmento sobrescribe o es sobrescrito por el fragmento
anterior, hay que utilizar todos los fragmentos para reconstruir el root # portsentry tcp, detección básica TCP con atadura al puerto
paquete original completo. (con binding o ligado al puerto).
Estos son algunos de los métodos que existen y que se suelen root # portsentry udp, detección básica UDP con atadura al puerto.
utilizar para determinar con MUCHA precisión que SO corre en
nuestra víctima pero no son los únicos y posiblemente aparecerán root # portsentry sudp, puede detectar escaneos UDP ocultos.
algunos otros más por lo que no es el objetivo de este artículo
profundizar en todos ellos ahora, quizás más adelante en próximos root # portsentry audp, como -sudp pero en modo avanzado.
artículos ;-)
Puede que hablemos de esta y otras utilidades relacionadas en un
Por supuesto existen potentes utilidades como QUESO (Qué Sistema futuro pero por ahora esto es más que suficiente :) para empezar.
Operativo) que puedes obtener de http://www.apostols.org con
el objetivo de detectar el SO de un host remotamente. QUESO 6- Medidas de seguridad básicas
utiliza varios paquetes con ACK=0 y un número de secuencia
aleatorio de la siguiente forma: Como has podido observar existen numerosas formas de escanear
una red y obtener información sensible acerca de la misma por
1 SYN lo que se recomienda instalar sistemas IDS que registren cualquier
2 SYN|ACK actividad sospechosa así como un buen cortafuegos (con una
6 PSH buena política restrictiva) y disponer de un buen syslog. Además
3 FIN lo ideal sería guardar todos nuestros logs en un servidor remoto
4 SYN|FIN junto con sumas de verificación u otros sistemas que nos aseguren
5 FIN|ACK que no se han modificado nuestros registros. Existen muchas
7 SYN|otros flags no estandarizados. aplicaciones para proteger nuestro sistema del exterior pero ninguna
medida es suficiente como para proteger al 100% nuestro sistema,
QUESO es un programa bien diseñado mediante un fichero aparte eso es lo único que es realmente seguro si tu computadora está
que contiene las respuestas que se esperan según el tipo de conectada a la red de redes :P y lo seguiremos demostrando en
paquete enviado y que se utilizada para contrastar los resultados los siguientes artículos ;-)
obtenidos para afirmar con bastante seguridad que SO corre en
nuestro objetivo, en fin una maravilla que ya deberías
tener :)

TeCNICAS DE PORT SCANNING
Y USO DEL NMAP.
1- ¿Qué es el escaneo de puertos

y para qué sirve? necesitamos una referencia y este artículo cumplirá esa
función.
El escaneo de puertos es una técnica usada
por hackers y administradores (sin ánimo
de hacer distinciones) para auditar máquinas Algunos tipos de escaneo explicados de forma
y redes con el fin de saber que puertos están breve, y que luego verás mejor con la práctica,
abiertos o cerrados, los servicios que son son:
ofrecidos, chequear la existencia de un
firewall así como verificaciones sobre el -TCP connect: esta es una técnica rápida y
funcionamiento del mismo y algunas otras simple, pero tiene el inconveniente de que
cosas. Ni que decir tiene que ésta es una de canta un poquito xD y se detecta fácilmente.
las técnicas más utilizadas a la hora de penetrar Además por lo general si utilizas esta técnica
en un sistema y realizar un análisis preliminar tus conexiones serán logueadas y/o filtradas.
del sistema... sin duda una de las mejores y
más efectivas para llevar a cabo nuestras Se basa en intentar establecer una conexión
"oscuras intenciones". con el puerto del host remoto mediante la
llamada a connect () si se establece
De eso te hablaré aquí, de las diversas técnicas dicha conexión, evidentemente, el puerto está
de escaneo, de cómo escanear una máquina abierto.
o red y de cómo aprovechar los resultados
obtenidos para atacar o proteger nuestro -TCP SYN: se trata de un escaneo en el que
sistema, todo con un propósito puramente no se establece una conexión completa,
educativo ;-) enviamos SYN y en función de la respuesta
obtenida por el host contestamos con RST (en
caso de estar abierto) para resetear la conexión,
2- Algunos tipos de escaneo
es decir, abortar.
conocidos. Puede darse el caso de que al enviar un paquete
TCP con el bit SYN no se reciba respuesta lo
Antes de seguir con la explicación deberías
que significa que el host está desconectado o
tener algunas nociones básicas acerca del
se filtra la conexión a ese puerto.
protocolo TCP y algunas otras cosas que ya
A este tipo de escaneo se le conoce como
se han explicado en la revista.
escaneo "medio abierto" o "SYN stealth".
! Si no estas... -Stealth Scan (TCP FIN): se trata de enviar

FIN y esperar la respuesta del host víctima de
Si no estás iniciado en el tema, lo que leerás a continuación nuestro escaneo FIN stealth ("sigiloso"), si
quizás te amedrente un poco. Vamos a ver, este artículo ignora los paquetes enviados entonces el puerto
servirá de plataforma para explicar en profundidad muchos está abierto. Los sistemas de la compañía
temas en próximos números, todo aquello que ahora no Micro$oft (entre otros) no son susceptibles
entiendas será explicado, como hacemos siempre, pero a este tipo de escaneo aunque parezca mentira
:P .

PORT SCANING - NMAP - PORT SCANING - NMAP - PORT SCANING - NMAP
-Reverse Ident (TCP): realizamos un -Null Scan: se trata de otro método de escaneo
escaneo normal TCP pero miramos si el puerto stealth, en el que enviamos un curioso paquete
113 está abierto con el objetivo de saber quién sin banderas levantadas.
es dueño de los servicios que corren en otros
puertos de la máquina. -Xmas Scan: lo realizamos enviando paquetes
TCP anormalmente configurados y todos los
-Ping Scan: ...bastante explícito xD en todo flags (banderas) SYN, ACK, PSH, RST, URG
caso se debe usar cuando tu intención sea y FIN levantados.
saber que máquina(s) están despiertas, es
posible bloquear los pings, pero luego (con la -Idle scan: se trata de una técnica de escaneo
practica) veremos como saltarse esta stealth muy potente y eficaz, con la que no
"protección" en caso de encontrarnos con el tenemos necesidad de enviar ni un solo paquete
inconveniente. con nuestra IP si no que se utilizan host's
zombis, sería interesante comentar esta técnica
-Bounce Attack (vía ftp): se trata de detalladamente en su propio espacio por lo que
aprovechar la conexión proxy ftp para escanear no profundizaremos ahora.
a través de un servidor FTP. Esto es así porque
podemos utilizar el comando PORT indicando Finalmente,
una dirección IP y un puerto, en este caso el
objetivo de nuestro escaneo y solicitamos una -RCP Scan: se trata de enviar el comando
transmisión de datos, si el puerto en cuestión NULL (SunRPC) a los puertos tcp o udp
está cerrado se generará un error 425 ("Can´t que están abiertos y ver si son puertos RPC
get data conection" o algo muy similar). Es para saber qué programa y su versión está
una buena idea deshabilitar la opción ftp corriendo.
proxy para evitar que terceros utilicen nuestro
servidor para escanear y/o atacar otras redes. Estos son los tipos de escaneo fundamentales
aunque no son los únicos.
-UDP Scan: este escaneo mostrará los puertos
abiertos que utilizan el protocolo UDP (con 3- Nuestros enemigos: "IDS".
sus inconvenientes), es bastante lento aunque
irá mejor si escaneas una máquina que utilice Antes de proceder a ver de qué manera
la plataforma Window$ gracias a la política podemos aplicar los diferentes ataques
de M$ de hacer las cosas "iguales pero existentes que acabamos de repasar brevemente
diferentes" y "viva el monopolio". me gustaría dejar clara una cosa a la hora de
escanear puertos a diestro y siniestro: DEBES
-ACK Scan: muchas veces nos encontramos SER CUIDADOSO Y NO DAR LA NOTA (--
con un bonito firewall que impide el "correcto ¡no j*d*s!) ten en cuenta que aparte de haber
flujo de los paquetes" xDD desde nuestra buenos administradores (pocos pero hay :P)
máquina al host víctima, por eso y otros monitoreando el tráfico y la actividad de sistema,
motivos nos interesa saber qué tipo de los cortafuegos y los logs del sistema... existen
configuración tiene el cortafuegos, es decir si los llamados: IDS (Intrusion Detection System,
el tráfico ha sido filtrado o no. que no traduciré porque seguro que ya sabéis
lo que significa xD) mediante estos sistemas
-Window Scan: muy parecido al anterior, es posible detectar un escaneo, activar las
pero nos dice también que puertos están alarmas y llevar a cabo las acciones oportunas,
abiertos. es decir, que si un "UIA" (Usuario del Intesné

Aburrido) se dedica a escanear ciento y pico ¿De dónde me bajo el NMap?

máquinas de una red de arriba a abajo en plan
"destroyer" tiene todos los números de meterse
Como acabo de decir se trata de una
en un buen lío ...aunque os pego aquí un texto
herramienta LIBRE y eso significa que dispones
sacado de la web de los Men In Green ;-)
del código fuente y el programa compilado; lo
<< Es de destacar que conductas tan frecuentes tienes para diversas plataformas. Aunque NMap
en esta Sociedad de la Información, como son el está pensado para su uso en la consola (línea
Spam o el simple Escaneo de puertos, difícilmente de comando) dispone de un agradable GUI
encuentran cabida entre los delitos tipificados en (Interfaz Gráfica de Usuario) que hace más
nuestro Código Penal, por lo que no son fácil todavía su manejo, si piensas utilizar NMap
perseguibles por vía penal. >> bajo la plataforma Window$ te recomiendo
que sea un Window$ NT/2K aunque existe
Ejemplos de aplicaciones "IDS" son: Cyber para 95/98/ME, por supuesto las versiones
Cop, CISCO NetRanger, TripWire, Snort para Window$ no son tan rápidas ni estables
y L.I.D.S siendo estos tres últimos como cabría esperar debido a que todavía se
encuentran en constante desarrollo.
gratuitos :)
Te puedes bajar la versión NMap 1.3.1 para
! IDS ¿Qué? ... Window$ aquí:
ttp://download.insecure.org/nmap/dist/nmapwin
IDS ¿Qué? ¿?¿? Si nunca has oído hablar de esto, ya sabes, _1.3.1.exe
www.google.com e investiga un poco por tu cuenta.
INSTALACIÓN DEL NMAP:
Si has optado por descargarte NMAP junto con

4- Visión práctica: usando el NMap. su GUI ("NMapWin") simplemente sigue
estos pasos:
NMap es una herramienta LIBRE para la
auditoria de redes, disponible en varias
plataformas aunque fue desarrollada 1-Bájate NMapwin_1.3.1.exe (instalador para
inicialmente para entornos Unix, y para mí Window$) mencionado justo arriba.
una de las mejores utilidades que existen
actualmente para el propósito, mediante esta 2-Ejecuta el instalador y sigue las instrucciones
potente herramienta podemos por ejemplo: indicadas.
3-Una vez finalizado esto te vas al directorio

-Determinar que host's están disponibles en
que diste al programa y encontrarás nuevos
una red.
ejecutables, debes instalar WinPCap.
-Determinar los puertos abiertos que tiene el
sistema y que servicios ofrecen. 4-Una vez reiniciado Window$ (por una vez
-Determinar que sistema operativo corre en el que sea decisión tuya ¿no? xD) ya dispones de
host objetivo. Nmap para la línea de comandos y su interfaz
-Determinar la configuración y uso de gráfica plenamente funcionales :)
cortafuegos.
-Arreglar una tarde aburrida escaneando el Ahora explicaremos cómo utilizar el NMap
ordenador de nuestra vecina ;) mediante su GUI para escanear los puertos de

un sistema mediante las diversas técnicas que También se permite el uso del asterisco, por
he comentado. ejemplo: 198.154.3.* e incluso el escaneo de
puertos dentro de un rango específico.
! Si has leido ...
Si has leído los números anteriores de esta

publicación ya sabes lo que es una IP y el formato
que tiene, por lo tanto solo te puntualizo que cuando
sustituyes una parte de la IP por un asterisco, lo
que haces es escanear un rango de IPs.
Si tomamos como ejemplo 198.154.3.*, lo que

hacemos es escanear desde la IP 198.154.3.0 a la
IP 198.154.3.255
Justo abajo tenemos una serie de

pestañitas para indicar el tipo de escaneo
a realizar así como las opciones
adicionales que queremos aplicar. Los
resultados obtenidos tras el escaneo
aparecerán en el cuadro de salida
Para empezar lo mejor será ver todas esas (Output), además si te fijas en la barra de abajo
opciones que puedes utilizar jeje seguro que aparecen los argumentos que deberíamos
estás inquieto pensando en darle al botoncito pasarle al NMap mediante la línea de comandos.
de "scan" pero no te impacientes.
En primer lugar tenemos un cuadro de

texto donde indicaremos el host que
queremos escanear, podemos usar la IP
o el nombre del host indicando además:
/32 para escanear únicamente el servidor

especificado. Veamos esas opciones que es importante
/16 para escanear una dirección de clase 'B'. conocer, por ejemplo ya hemos comentado que
/24 para escanear una dirección de clase 'C'. es posible que nuestra víctima (por llamarla de
alguna manera :P) esté on-line pero no deja
que "pinguées" su servidor.
! Si no entiendes ...
Si te fijas en la pestañita "SCAN" verás que
.Si no entiendes eso de Clase A, B, C, no te preocupes,
puedes seleccionar las modalidades de escaneo
en los próximos números y tomando de referencia este
que te he explicado hace un momento, y que
texto explicaremos las MUCHAS cosas que seguro no
no volveremos a comentar ahora, pero lo que
comprendes ahora mismo de este artículo poco a poco
si que es interesante explicar son las opciones
y paso a paso :)
de tu derecha ("Scan Options").

Como se puedes ver si quieres indicar un rango así: -PT80 (puerto 80 por no ser normalmente
de puertos a escanear (con -P) debes marcar filtrado) si el objetivo no permite pings puedes
la opción Port Range, por ejemplo así: 10- estas dos últimas opciones... aunque es una
2048. sugerencia xD.
Otra opción curiosa que me gusta bastante -Realizar un "ping" TCP usando SYN (-PS).
(aunque yo no la uso :P) es Decoy, sirve para -Realizar un ping mediante ICMP.
escanear usando uno o más señuelos para que Por defecto NMap realiza un ping ICMP + ACK
el servidor objetivo vea que le atacan desde en paralelo, es decir, -PI y -PT.
varias IP's que debes indicar separadas por
comas, si no indicas "ME" en una de las Si ahora te vas a "OPTIONS" podrás ver unas
posiciones se te asignará una de oficio, digo, opciones muy interesantes, por ejemplo:
aleatoria xD imagínate que locura para un
administrador ;) Fragmentation (-f) con esta opción se usan
paquetes fragmentados que dificultan la
Más cosas, en Device (-e) especificamos la detección del escaneo, en un futuro os
interfaz desde la que enviar y recibir los hablaremos de ataques de ataques de
paquetes, aunque normalmente NMap detecta fragmentación y relacionados ampliamente.
esto de forma automática :) así que salvo casos
puntuales no debes preocuparte por eso. OS detection: pues eso, si quieres determinar
Otra de las opciones de especial interés es que tipo de SO utiliza el objetivo marca esta
indicar una IP en Source Address (-S) de casilla, recomendado.
manera que aparentemente el ataque se realiza
desde esa IP, aunque evidentemente el escaneo Get Ident Info: usa la técnica del escaneo
no te servirá de nada :( especifica la interfaz inverso (TCP reverse ident scanning) siempre
en este caso (-e) y ten en cuenta que falsear que sea posible, úsalo al realizar un escaneo
la dirección de origen por otra ajena puede tipo -sT (connect), útil cuando quieras saber si
hacer que "esa IP" se meta en problemas, por un servicio corre con privilegios de administrador.
favor, utiliza esta función con responsabilidad.
Fast Scan (-F): escanea los puertos especificados
Otra opción es Bounce Attack (-b) necesita de /etc/services (nmap-services en nuestro
que le pases usuario:password@servidor:puerto caso xD).
y ya sabes lo que hace ;) pero recuerda que
va muy lento. Random Host's: objetivos aleatorios (-iR) y
También podemos especificar el Source Port bueno, realmente no nos interesa.
(puerto de origen) con -g o marcando su casilla
en la interfaz gráfica con el fin de establecer Con don´t resolve (-n) y resolve all (-R)
ese puerto como fuente de nuestro escaneo. indicamos si queremos resolución DNS, es decir,
Esto tiene sentido especialmente si un firewall resolución de nombres de host por su IP.
hace excepciones en función del puerto de
origen para filtrar o no los paquetes. Mediant Resume (--resume fichero) podemos
retomar un escaneo detenido usando un fichero
En la pestañita "DISCOVER" encontrarás de salida.
nuevas posibilidades:
Verbose y very verbose: nos da información
-No realizar un ping previo. (-P0) más amplia de lo que sucede (-v) puedes usarlo
-Realizar un "ping" TCP usando ACK tal que dos veces (very verbose) para mostrar todavía

más información. número máximo de escaneos que se permitirán

ejecutar en paralelo, no debes utilizar un valor
muy alto para no agotar los recursos de tu
máquina ;-)
Scan Delay: tiempo mínimo de espera entre

las diferentes pruebas en milisegundos, lo
puedes usar para evitar (¿?) que algunos IDS
detecten el escaneo.
Pasemos a la siguiente pestañita como ves hay

MUCHAS opciones xD para "curiosear" redes;
Si ahora pasas a la pestañita "timing" en Files encontrarás Input File y Output File (-
encontrarás opciones referentes al tiempo que, iL y -oN respectivamente):
por lo general, no es necesario que modifiques
aunque si por ejemplo te encuentras en una Input File: escanear los objetivos de un fichero
red con tráfico excesivo u otros casos en los dado con objetivos separados por retornos de
que sea necesario reajustar estos valores debes carro (intro), espacios y tabulaciones.
hacerlo aquí, veamos lo que podemos hacer:
Output File: guarda los resultados obtenidos
Throttle: sirve para configurar el tiempo de en un fichero especificado, podemos especificar
envío y respuesta de paquetes de forma general, el formato del salida pero lo suyo es dejarlo
siendo Paranoid el más lento e Insane el más normal (-oN) puedes marcar Append para añadir
rápido. (-T Paranoid|Sneaky|Polite|Normal...). la nueva información al final del fichero.
Otras alternativas disponibles (¡no debes usarlas A continuación se puede ver la pestaña "Service"
si modificas algo usando Throttle!) que simplemente se usa para configurar el
servicio pero para lo que estamos tratando
Host Timeout: indica el tiempo máximo en ahora no es importante así que pasemos a
milisegundos que se dedica al escaneo de un otras opciones que aunque tampoco son
único sistema, por defecto no tiene impuesto especialmente necesarias veremos algunas,
un límite tal y como se puede ver. son las de la pestañita "Win32" y se usan para
lo siguiente:
Max RTT: tiempo máximo de espera en
milisegundos que NMap esperará a recibir No Pcap (--win_nopcap): deshabilita el soporte
respuesta del sistema escaneado. Wincap.
Min RTT (ms): para evitar casos de demora en No Raw Sockets (--win_norawsock): deshabilita
la comunicación NMap nos asegura un tiempo el soporte para raw sockets (algún día
mínimo de espera. hablaremos de los sockets y los sockets en
crudo puesto que proporcionan ventajas
Initial RTT (ms): al especificar la opción -P0 interesantes aunque por ahora puede ser
para probar un cortafuegos podemos especificar demasiado avanzado).
un tiempo de espera en las pruebas iniciales.
List Interfaces (--win_list_interfaces): lista todas
Parallelism: (--max_parallelism num) indica el las interfaces de red.

C:\>nmap --win_list_interfaces y obtendremos como respuesta algo parecido

Available interfaces: a esto:
Name Raw send Raw recieve IP Starting nmap V. 3.00 ( www.insecure.org/nmap )

loopback0 SOCK_RAW SOCK_RAW 127.0.0.1 Host (***.***.**.*) appears to be up ... good.
eth0 SOCK_RAW winpcap 0.0.0.0 Initiating SYN Stealth Scan against (***.***.**.*)
ppp0 SOCK_RAW SOCK_RAW The SYN Stealth Scan took 0 seconds to scan 1
211.98.199.104 ports.
Interesting ports on (***.***.**.*):
Force Raw Socket(--Win_forcerawsock): probar Port State Service
los raw sockets incluso en un sistema que no 1080/tcp filtered socks
sea Window$ 2000. [...]
Aunque lo mismo interesa buscar algunos

servidores con NT:
nmap -sS -O -p 80 objetivo/24.
Más ejemplos,
nmap -sS -PI -v ***

Hemos visto lo podemos hacer y supongo que Starting nmap V. 3.00 ( www.insecure.org/nmap )
te das cuenta de la potente herramienta que Host (***.***.***.***) appears to be down,
tienes en tus manos ¿verdad? jeje pues espera skipping it.
a usarla ;). Note: Host seems down. If it is really up, but
blocking our ping probes, try -P0
4.1- Algunos ejemplos de uso.
...mmm parece ser que con un escaneo (usando
Ahora veremos algunos ejemplos de escaneo ping) normalillo no basta :P
utilizando el NMap, yo como soy un maniático
usaré la línea de comandos, cada uno que use nmap -sS -PT -v ***
lo que más le guste :) Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host (***.***.***.***) appears to be up ... good.
Antes de ponernos a "curiosear" permíteme Initiating SYN Stealth Scan against
recomendarte no escanear desde tu propio PC (***.***.***.***)
=:) búscate el cyber cutre de turno o asegúrate Adding open port 80/tcp
de ocultar bien tu IP, etc. Adding open port 53/tcp
Realizamos un primer chequeo: Adding open port 22/tcp
Adding open port 443/tcp
Hoy es un día aburrido y no hay nada mejor Adding open port 25/tcp
que hacer que buscar WinGates (servicio The SYN Stealth Scan took 31 seconds to scan
ofrecido normalmente en el puerto 1080), 1601 ports.
abrimos una ventana de comandos y Interesting ports on (***.***.***.***):
escribimos: (sustituye objetivo por la IP (The 1584 ports scanned but not shown below are
de la víctima) in state: closed)
Port State Service
nmap -sP -vv -p 1080 objetivo 22/tcp open ssh

25/tcp open smtp Remote operating system guess: Linux 2.2.12 -

53/tcp open domain 2.2.19
79/tcp filtered finger
[...]
80/tcp open http
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn nmap -sS -O -vv NOMBRE/IP_víctima/24
143/tcp filtered imap2
389/tcp filtered ldap
443/tcp open https Con este escaneo barremos una red de clase
901/tcp filtered samba-swat
C mediante un escaneo oculto (stealth SYN) y
3306/tcp filtered mysql
con la intención de averiguar el SO, además
5432/tcp filtered postgres
6346/tcp filtered gnutella hemos especificado el modo very verbose para
6699/tcp filtered napster obtener más detalles acerca de lo que está
10000/tcp filtered snet-sensor-mgmt ocurriendo.
vaya... pues si que estaba despierto mira tu

que cosas :P y resulta que tiene algunos puertos
Estos son algunos ejemplos simples de escaneo,
filtrados, ok. En cambio tiene otros como el 25
ahora ya estás listo para salir "ahí fuera" a
(servidor SMTP), el 53 (name-domain server)
y 22/ssh (secure shell) abiertos. explorar de forma efectiva y segura (?) ya
iremos viendo como explotar algunos agujeros
Vamos a investigar eso un poco ;-) por simple de seguridad más a fondo en la revista para
curiosidad: los cuales es buena idea realizar un análisis
previo del sistema del que queremos
C:\>telnet ***.*** 25
comprometer la seguridad, no te pierdas los
próximos artículos ;).
220 correo.***.*** ESMTP
MAIL FROM yo mismamente!
250 ok
#en fin, no ha hecho falta el saludo xD. Seguimos.
[...]
y si nos conectamos al puerto 22 sacamos esto ! Para tus primeras...

SSH-2.0-OpenSSH_2.5.2p2 xD.
Para tus primeras pruebas, te recomendamos utilizar como
M o l a r í a s a b e r e l s i s t e m a o p e ra i vo : víctima para tus escaneos el servidor de Hack x Crack que
nmap -sS -PT -PI -O -T 3 (usamos -O para está en la IP 80.36.230.235, que para eso está ;)
detectar el SO)
Starting nmap V. 3.00 ( www.insecure.org/nmap

)
[...]

Introducción al protocolo TCP/IP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducción al protocolo TCP/IP

Cargado por

Copyright:

Formatos disponibles

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

Este es precisamente el motivo por el que

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á

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