icmp, arp, bootp - Departamento de Matemáticas

PROTOCOLO BOOTP.
QUE ES BOOTP ?
BOOTP se diseño originalmente para permitir la configuración de inicio de
estaciones de trabajo sin disco en sistemas antiguos. Este protocolo era necesario, ya
que los clientes de este tipo tienen una capacidad limitada para almacenar la
información configurable, necesaria durante los respectivos procesos de inicio que se
utilizan para iniciar y participar en una red.
Las LANs hacen posible usar host sin disco como estaciones de trabajo,
"routers" concentradores de terminales, etc. Los host sin disco requieren de algún
mecanismo para el arranque remoto sobre una red. El protocolo BOOTP se utiliza para
efectuar arranques remotos en redes IP. Permite que una pila de IP mínima sin
información de configuración, típicamente almacenada en la ROM, obtenga
información suficiente para comenzar el proceso de descargar el código de arranque
necesario. BOOTP no define como se realiza esta descarga, pero habitualmente se
emplea TFTP ("Trivial File Transfer Protocol") como se describe en el RFC 906 - Carga
en Bootstrap usando TFTP.
BOOTP es predecesor del protocolo de arranque DHCP.
PASOS PARA EL PROCESO DE BOOTP.
1. El cliente determina su propia dirección hardware; esta suele estar en una
ROM del hardware.
2. El cliente BOOTP envía su dirección hardware en un datagrama UDP al
servidor. Si el cliente conoce su dirección IP y/o la dirección del servidor,
debería usarlas, pero en general los clientes BOOTP carecen de configuración IP
en absoluto. Si el cliente desconoce su dirección IP, emplea la 0.0.0.0. Si
desconoce la dirección IP del servidor, utiliza la dirección de broadcast limitado
(255.255.255.255). El número del puerto UDP es el 67.
3. El servidor recibe el datagrama y busca la dirección hardware del cliente en su
fichero de configuración, que contiene la dirección IP del cliente. El servidor
rellena los campos restantes del datagrama UDP y se lo devuelve al cliente
usando el puerto 68. Hay tres métodos posibles para hacer esto:
- Si el cliente conoce su propia dirección IP (incluida en la solicitud
BOOTP), entonces el servidor devuelve directamente el datagrama a esa
dirección. Es probable que la caché de ARP en la pila de protocolos del
servidor desconozca la dirección hardware correspondiente a esa
dirección IP. Se hará uso de ARP para determinarla del modo habitual.
- Si el cliente desconoce su propia dirección IP (0.0.0.0 la solicitud
BOOTP), entonces el servidor se ocupa de averiguarla con su propia
caché de ARP. El servidor no puede usar ARP para resolver la dirección
hardware del cliente porque el cliente no sabe su dirección IP y por lo
tanto no puede responder a una petición ARP. Hay dos soluciones
posibles:
a) Si el servidor tiene un mecanismo para actualizar directamente
su propia caché ARP sin usar ARP, lo utiliza y envía directamente
el datagrama.
b) Si el servidor no puede actualizar su propia caché, debe enviar
una respuesta en forma de broadcast.
4. Cuando reciba la respuesta, el cliente BOOTP grabará su dirección IP (permitiéndole
responder a peticiones ARP) y comenzará el proceso de arranque.
SEGUNDA FASE DEL PROCESO BOOTP.
En BOOTP, los clientes obtienen su configuración en un proceso de dos fases
que se muestra a continuación:
1. El cliente BOOTP solicita una dirección IP así como otra información
relevante. Esta información podría incluir normalmente las direcciones IP de un
gateway (puerta de enlace predeterminada) o un servidor DNS. Para obtener más
información, consulte Opciones DHCP y BOOTP estándar
2. El cliente BOOTP también solicita información adicional.
Esta información es necesaria para que el cliente localice un servidor de
Protocolo de transferencia de archivos trivial (TFTP, Trivial File Transfer
Protocol) que proporciona un archivo de imagen de inicio específico de su
plataforma. El cliente sólo necesita este archivo para completar su configuración
de inicio.
Una vez que el servidor BOOTP ha respondido con toda la información que ha
solicitado el cliente BOOTP, el cliente puede realizar la solicitud independiente a su
servidor TFTP para completar la segunda fase de su proceso de inicio.
FORMATO DEL MENSAJE BOOTP.
code
Indica una solicitud o una respuesta
1
Request
2
Reply
HWtype
El tipo de hardware, por ejemplo:
1
Ethernet
6
IEEE 802 Networks
Remitirse a STD 2 - Números asignados de Internet para un alista completa.
length
Longitud en bytes de la dirección hardware. Ethernet y las redes en anillo usan
6, por ejemplo.
hops
El cliente lo pone a 0. Cada "router" que retransmite la solicitud a otro servidor
lo incrementa, con el fin de detectar bucles. El RFC 951 sugiere que un valor de
3 indica un bucle.
Transaction ID
Número aleatorio usado para comparar la solicitud con la respuesta que genera.
Seconds
Fijado por el cliente. Es el tiempo transcurrido en segundos desde que el cliente
inició el proceso de arranque.
Flags Field
El bit más significante de este campo se usa como flag de broadcast. Todos los
demás bits deben estar a 0; están reservados para usos futuros. Normalmente, los
servidores BOOTP tratan de entregar los mensajes BOOTREPLY directamente
al cliente usando unicast. La dirección de destino en la cabecera IP se pone al
valor de la dirección IP fijada por el servidor BOOTP, y la dirección MAC a la
dirección hardware del cliente BOOTP. Si un host no puede recibir un
datagrama IP en unicast hasta saber su propia dirección IP, el bit de broadcast se
debe poner a 1 para indicar al servidor que el mensaje BOOTREPLY se debe
enviar como un broadcast en IP y MAC. De otro modo, este bit debe ponerse a
cero.
Client IP adress
Fijada por el cliente. O bien es su dirección IP real , o 0.0.0.0.
Your IP Address
Fijada por el servidor si el valor del campo anterior es 0.0.0.0
Server IP address
Fijada por el servidor.
Router IP address
Fijada por el "router" retransmisor si se usa retransmisión BOOTP.
Client hardware address
Fijada por el cliente y usada por el servidor para identificar cuál de los clientes
registrados está arrancando.
Server host name
Nombre opcional del host servidor acabado en X'00'.
Boot file name
El cliente deja este campo vacío o especifica un nombre genérico, tal como
"router", indicando el tipo de archivo de arranque a usar. El servidor devuelve el
nombre completo del fichero o bien el de un fichero de arranque adecuado para
el cliente. Su valor tiene como terminador a la secuencia X'00.
Vendor-specific area
Área específica del distribuidor (opcional). Se recomienda que el cliente llene siempre
los cuatro primeros bytes con un "magic cookie" o galleta mágica. Si el cookie
específica de un distribuidor no se usa, el cliente debería utilizar 99.130.83.99 seguido
de una marca de fin (255) y fijar los bis restantes a cero. Remitirse al RFC 1533 para
más detalles.
APLICACIÓN DE BOOTP EN UN SERVIDOR DHCP DE WINDOWS2000.
Para configurar los servidores DHCP de Windows 2000 para que proporcionen
información del archivo de inicio a los clientes BOOTP, complete los pasos siguientes:
1. Agregue una reserva de cliente para cada cliente BOOTP de un ámbito DHCP
activo.
2. Agregue entradas BOOTP para cada plataforma específica del cliente en la tabla
BOOTP del servidor DHCP.
Los clientes BOOTP utilizan la información guardada en la tabla BOOTP para
completar la segunda fase de su proceso de inicio. Esta información se devuelve a los
clientes BOOTP de la red que difunden un mensaje de solicitud BOOTP.
Si se ha agregado al menos una entrada BOOTP a la tabla BOOTP, el servidor DHCP
de Windows 2000 responderá a las solicitudes del cliente BOOTP. Si no se han
configurado entradas BOOTP, el servidor pasará por alto los mensajes de solicitud
BOOTP.
CONFIGURACIÓN DE LA TABLA BOOTP.
Cada registro de la tabla BOOTP contiene los tres campos en los que se incluye
la información devuelta al cliente BOOTP:
• Nombre del archivo de imagen de inicio. Identifica el nombre de archivo
genérico (por ejemplo, "unix") del archivo de inicio solicitado, basado en el tipo
de hardware del cliente BOOTP.
• Ruta de acceso completa del servidor a la imagen de inicio. Identifica la ruta de
acceso completa del archivo de inicio (por ejemplo, "/etc/vmunix") que devuelve
al cliente el servidor BOOTP, mediante TFTP.
• Servidor de archivos TFTP. Identifica el nombre del servidor TFTP utilizado
como origen del archivo de inicio.
Para agregar entradas a la tabla BOOTP, utilice la consola DHCP.
DETALLES ADICIONALES DE CONFIGURACIÓN DE BOOTP.
Para que los servidores DHCP de Windows 2000 suministren un archivo de
imagen de inicio y la información del servidor TFTP a los clientes BOOTP, el servidor
utiliza algunas opciones DHCP para cumplir con la información guardada en entradas
de la tabla BOOTP.
La tabla siguiente muestra estas opciones, que se utilizan para completar los
mensajes del protocolo BOOTP que se devuelven a los clientes durante su secuencia de
arranque inicial.
Código Descripción
66
Nombre de servidor TFTP
67
Nombre de archivo de inicio
Una vez que haya agregado entradas BOOTP a la tabla BOOTP de un servidor
DHCP de Windows 2000, también configurará las opciones previas que se utilizarán
para admitir a los clientes BOOTP. No necesitará configurar más las opciones DHCP en
el servidor para proporcionarlas y utilizarlas como parte de la compatibilidad con
BOOTP.
CAPA DEL MODELO OSI EN QUE SE ENCUENTRA BOOTP.
BOOTP opera en la Capa de Red del modelo OSI (Open System Interconection).
SEGURIDAD DE BOOTP.
Una petición de BOOTP nada mas puede realizarse en la misma subred en la que
se encuentra el cliente que hace la petición BOOTP. Ya que si lo hace un cliente que se
encuentra fuera de esa subred, el cliente podrá acceder a la red, aunque éste no tenga
privilegios para hacerlo.
ESTÁNDARES DE BOOTP.

El protocolo de inicio BOOTP es un estándar TCP/IP establecido para la
configuración de host que precede DHCP.

Las especificaciones de BOOTP se encuentran en: RFC 951, RFC 1497,
RFC 1542, RFC 1533 y RFC 1532.
PROTOCOLO SMTP.
El correo electrónico (E-mail) es probablemente la aplicación TCP/IP más
usada. Los protocolos de correo básicos de correo proporcionan intercambio de correo y
mensajes entre hosts TCP/IP hosts; se han añadido servicios para la transmisión de
datos que no se pueden representar con texto ASCII de 7 bits.
Hay tres protocolos estándares que se aplican a este tipo de correo. Todos son
recomendados. El término SMTP se emplea con frecuencia para referirse a la
combinación de los tres protocolos, por su estrecha interrelación, pero estrictamente
hablando, SMTP es sólo uno de los tres. Normalmente, el contexto hace evidente de
cuál de los tres se está hablando. Cuando haya ambigüedad, se emplearán los números
STD o RFC. Los tres estándares son:


Un estándar para el intercambio de correo entre dos ordenadores (STD 10/RFC
821), que especifica el protocolo usado para enviar correo entre hosts TCP/IP.
Este estándar es SMTP.
Un estándar (STD 11) para el formato de los mensajes de correo, contenido en
dos RFCs. El RFC 822 describe la sintaxis de las cabeceras y su interpretación.
El RFC 1049 describe como un conjunto de documentos de tipos diferentes del
texto ASCII plano se pueden usar en el cuerpo del correo(los mismos
documentos están en ASCII de 7 bits con información de formato embebida:
Postscript, Scribe, SGML, TEX, TROFF y DVI aparecen en el estándar).
El nombre oficial del protocolo para este estándar es MAIL.

Un estándar para el encaminamiento de correo usando el DNS, descrito en el
RFC 974. El nombre oficial del protocolo para este estándar es DNS-MX.
El STD 10/RFC 821 establece que los datos enviados por SMTP son ASCII de 7-bis,
con el bit de orden superior a cero. Esto es adecuado para mensajes en inglés, pero no
para otros lenguajes o datos que no sean texto. Hay dos estrategias para superar estas
limitaciones:

MIME ("Multipurpose Internet Mail Extensions"), definido en los RFCs 1521 y
1522, que especifica un mecanismo para codificar texto y datos binarios en
ASCII de 7 bits en el mensaje RFC 822.

SMTPSE ("SMTP Service Extensions"), que define un mecanismo para extender
las posibilidades de SMTP más allá de las limitaciones impuestas por RFC 821.
Actualmente hay tres RFCs que lo describen:
o Un estándar para que un receptor SMTP informe al emisor que
extensiones de servicio soporta (SMTPSE) soporta (RFC 1651).
El RFC 1651 modifica el 821 para permitir que un cliente
agente SMTP solicite al servidor una lista de las
extensiones de servicio que soporta el inicio de una sesión
SMTP. Si el servidor no soporta este RFC, responderá con
un error y el cliente podrá terminar la sesión o intentar
iniciar una sesión según las reglas RFC 821. Si sí lo
soporta, puede responder con una lista de las extensiones
que soporta.
o
Un protocolo para transmisión de texto de 8 bits(RFC 1652) que permite
a un servidor SMTP indicar que puede aceptar datos formados por bytes
de 8 bits. Un servidor que informa que dispone de esta extensión no debe
modificar el bit de orden superior de los bytes recibidos en un mensaje
SMTP si el cliente así se lo pide.
Las extensiones de MIME y SMTP son estrategias que se
complementan más que competir entre sí. En particular, el
RFC 1652 se titula SMTPSE para transporte MIME en
codificación "8bit", ya que MIME permite declarar
mensajes con bytes de 8 bits, en vez de 7. Tales mensajes
no se pueden transmitir con agentes SMTP que sigan
estrictamente el RFC 821, pero se pueden transmitir
cuando tanto el cliente como el servidor siguen los RFCs
1651 y 1652. Siempre que un cliente intenta enviar datos
de 8 bits a un servidor que no soporta esta extensión, el
cliente SMTP debe codificar el mensaje a 7 bits según el
estándar MIME o devolver un mensaje de error
permanente al usuario.
Esta extensión no permite el envío de datos binarios
arbitrarios porque el RFC 821 fija la longitud máxima de
las líneas aceptadas por un servidor SMTP a 1000
caracteres. Los datos que no son texto pueden tener con
facilidad secuencias de más de 1000 caracteres sin una
secuencia <CRLF>.
Nota: Las extensiones limitan específicamente el uso de
caracteres no ASCII (aquellos con valor decimal superior
a 127) al cuerpo de los mensajes - no están permitidos en
las cabeceras RFC 822.
o
Un protocolo para la declaración del tamaño del mensaje (RFC 1653)
que permite a un servidor informar al cliente del tamaño máximo de
mensaje que puede aceptar. Sin esta extensión, un cliente sólo puede ser
informado de que un mensaje ha excedido el tamaño máximo (sea fijo o
temporal, por falta de espacio en el servidor) tras transmitir todo el
mensaje. Cuando esto sucede, el servidor desecha el mensaje. Con ella,
el cliente puede declarar el tamaño estimado del mensaje y el servidor
devolverá un error si es demasiado grande.
MODELO SMTP.
COMO FUNCIONA SMTP.
SMTP está basado en la entrega punto-a-punto; un cliente SMTP contactará con
el servidor SMTP del host de destino directamente para entregar el correo. Guardará el
correo hasta que se haya copiado con éxito en el receptor. Esto difiere del principio de
retransmisión común a muchos sistemas de correo en las que el correo atraviesa un
número de host intermedios de la misma red y donde una transmisión con éxito implica
sólo que el correo ha alcanzado el host correspondiente al siguiente salto.
En varias implementaciones, existe la posibilidad de intercambiar correo entre
los sistemas de correo locales y SMTP. Estas aplicaciones se denominan pasarelas o
puentes de correo. Enviar correo a través de una pasarela puede alterar la entrega puntoa-punto, ya que SMTP sólo garantiza la entrega fiable a la pasarela, no al host de
destino, más allá de la red local. La transmisión punto SMTP en estos casos es hostpasarela, pasarela-host o pasarela-pasarela; SMTP no define lo que ocurre más allá de la
pasarela.
CONTENIDO DEL MENSAJE.
Cada mensaje tiene:


Una cabecera, o sobre, con estructura RFC 822. La cabecera termina con una
línea nula (una línea con sólo la secuencia <CRLF>).
Contents.
Todo lo que hay tras la línea nula es el cuerpo del mensaje, una
secuencia de líneas con caracteres ASCII (aquellos con valor menor del
128 decimal).
El RFC 821 define un protocolo cliente/servidor. Como siempre, el cliente
SMTP es el que inicia la sesión (el emisor) y el servidor el que responde a la solicitud
de sesión (el receptor). Sin embargo, como el cliente suele actuar como servidor para un
programa de correo del usuario, es más sencillo referirse a él como emisor SMTP, y al
servidor como receptor SMTP.
FORMATO DEL MENSAJE.
Normalmente, el usuario no tiene por qué preocuparse de la cabecera, que es
responsabilidad de SMTP.
Algunos campos habituales son:
keyword
valor
to
Receptores primarios del mensaje.
cc
Receptores Secundario("carbon-copy") del mensaje.
from
Identidad del emisor.
reply-to
El buzón al que se han de enviar las repuestas. Este campo lo añade el
emisor.
return-path
Dirección y ruta hasta el emisor. Lo añade el sistema de transporte final
que entrega el correo.
Subject
Resumen del mensaje. Suele proporcionarlo el usuario.
CLIENTE (EMISOR) Y SERVIDOR (RECEPTOR).
El RFC 821 define un protocolo cliente/servidor. Como siempre, el cliente SMTP es
el que inicia la sesión (el emisor) y el servidor el que responde a la solicitud de sesión
(el receptor). Sin embargo, como el cliente suele actuar como servidor para un programa
de correo del usuario, es más sencillo referirse a él como emisor SMTP, y al servidor
como receptor SMTP.
•
EL RFC 821 define un protocolo cliente/servidor.
•
El cliente SMTP es el emisor.
•
El servidor que responde a la solicitud de sesión es el receptor.
INTERCAMBIO DE CORREO.
El diseño de SMTP se basa en el modelo de comunicación mostrado en la figura de
abajo. Como resultado de la solicitud de correo de un usuario, el emisor SMTP
establece una conexión en los dos sentidos con el receptor SMTP. El receptor puede ser
el destinatario final o un intermediario (pasarela de correo). El emisor generará
comandos a los que replicará el receptor.
FLUJO DE DATOS DE SMTP.
Aunque los comandos y réplicas de correo están definidas rígidamente, el
intercambio se puede seguir en Flujo de Datos de SMTP. Todos los comandos, réplicas
o datos intercambiados son líneas de texto, delimitadas por un <CRLF>. Todas las
réplicas tienen un código numérico el comienzo de la línea.
1. El emisor SMTP establece una conexión TCP con el SMTP de destino y espera
a que el servidor envíe un mensaje "220 Service ready" o "421 Service not
available" cuando el destinatario es temporalmente incapaz de responder.
2. Se envía un HELO (abreviatura de "hello"), con el que el receptor se identificará
devolviendo su nombre de dominio. El SMTP emisor puede usarlo para verificar
si contactó con el SMTP de destino correcto.
Si el emisor SMTP soporta las extensiones de SMTP definidas en el RFC 1651,
puede sustituir el comando HELO por EHLO. Un receptor SMTP que no soporte
las extensiones responderá con un mensaje "500 Syntax error, command
unrecognized". El emisor SMTP debería intentarlo de nuevo con HELO, o si no
puede retransmitir el mensaje sin extensiones, enviar un mensaje QUIT.
Si un receptor SMTP soporta las extensiones de servicio, responde con un
mensaje multi-línea 250 OK que incluye una lista de las extensiones de servicio
que soporta.
3. El emisor inicia ahora una transacción enviando el comando MAIL al servidor.
Este comando contiene la ruta de vuelta al emisor que se puede emplear para
informar de errores. Nótese que una ruta puede ser más que el par
buzób@nombre de dominio del host. Además, puede contener una lista de los
hosts de encaminamiento. Si se acepta, el receptor replica con un "250 OK".
4. El segundo paso del intercambio real de correo consiste en darle al servidor
SMTP el destino del mensaje (puede haber más de un receptor). Esto se hace
enviando uno o más comandos RCPT TO:<forward-path>. Cada uno de ellos
recibirá una respuesta "250 OK" si el servidor conoce el destino, o un "550 No
such user here" si no.
5. Cuando se envían todos los comandos rcpt, el emisor envía un comando DATA
para notificar al receptor que a continuación se envían los contenidos del
mensaje. El servidor replica con "354 Start mail input, end with
<CRLF>.<CRLF>". Nótese que se trata de la secuencia de terminación que el
emisor debería usar para terminar los datos del mensaje.
6. El cliente envía los datos línea a línea, acabando con la línea <CRLF>. <CRLF>
que el servidor reconoce con "250 OK" o el mensaje de error apropiado si
cualquier cosa fue mal.
7. Ahora hay varias acciones posibles:
o
o
El emisor no tiene más mensajes que enviar; cerrará la conexión con un
comando QUIT, que será respondido con "221 Service closing
transmission channel".
El emisor no tiene más mensajes que enviar, pero está preparado para
recibir mensajes (si los hay) del otro extremo. Mandará el comando
TURN. Los dos SMTPs intercambian sus papelees y el emisor que era
o
antes receptor puede enviar ahora mensajes empezando por el paso 3 de
arriba.
El emisor tiene otro mensaje que enviar, y simplemente vuelve al paso 3
para enviar un nuevo MAIL.
Figura: Flujo de datos normal de SMTP.
DIRECCIÓN DE DESTINO DE SMTP.
En su forma general, parte-localt@nombre de dominio, puede adoptar distintos
esquemas:
usuario@host
Para un destino directo en la misma red TCP/IP.
usuario%host.remoto@host-pasarela
Para un usuario en un host remoto de destino no SMTP, vía una pasarela.
@host-a,@host-b:usuario@host-c
Para un mensaje retransmitido. Contiene explícitamente información de
encaminamiento. El mensaje será entregado primero al host a, que lo
retransmitirá al host b. El host b enviará el mensaje al host de destino real, el c.
Nótese que el mensaje se almacena en cada uno de los host intermedios, por lo
que no se necesita un mecanismo de entrega punto-a-punto.
EJEMPLO DE ENVÍO DE MENSAJES.
En el siguiente escenario, el usuario abc en el host vm1.stockholm.ibm.comando
envía una nota a los usuarios xyz, opq u rst en el host delta.aus.edu. Las líneas
precedidas por R: son las enviadas por el receptor, las que empiezan por S: las enviadas
por el emisor.
R: 220 delta.aus.edu Simple Mail Transfer Service Ready
S: HELO stockholm.ibm.comando
R: 250 delta.aus.edu
S: MAIL FROM:<[email protected]>
R: 250 OK
S: RCPT TO:<[email protected]>
R: 250 OK
S: RCPT TO:<[email protected]>
R: 550 No such user here
S: RCPT TO:<[email protected]>
R: 250 OK
S: DATA
R: 354 Start mail input, end with <CRLF>.<CRLF>
S: Date: 23 Jan 89 18:05:23
S: From: Alex B. Carver <[email protected]>
S: Subject: Important meeting
S: To: <[email protected]>
S: To: <[email protected]>
S: cc: <[email protected]>
S:
S: Blah blah blah
S: etc.....
S: .
R: 250 OK
S: QUIT
R: 221 delta.aus.edu Service closing transmission channel
Nótese que la cabecera del mensaje es parte de los datos a transmitir.
CAPA DEL MODELO OSI A LA QUE PERTENECE SMTP.
El protocolo SMTP pertenece a la Capa de Red del Modelo OSI (Open System
Interface).
APLICACIONES DE SMTP.
La aplicación principal de SMTP es el correo, de hecho para eso fue creado el
protocolo SMTP.
SEGURIDAD EN SMTP.
Las amenazas más comunes en el correo electrónico son:


Los ataques pasivos sobre los protocolos básicos del servicio de correo
electrónico.
El uso incorrecto de las estafetas de correo que degradan la calidad de
este servicio.
Las especificaciones originales del protocolo SMTP lo hacen vulnerable a los
ataques pasivos que se producen cuando una aplicación escucha el tráfico de la red y
accede al contenido de los mensajes, así como a la identificación del usuario: su nombre
y password de acceso. Estos ataques pueden actuar sobre las aplicaciones de usuario
más extendidas como: Netscape, Outlook, Eudora y las de tipo Web-Mail.
Por otro lado, el protocolo SMTP, en su versión original, no dispone de
mecanismos de autenticación del usuario que envía un mensaje. Esto permite el uso
fraudulento de servidores SMTP por parte de personas ajenas a la organización, así
como el envío de mensajes con dirección de correo falsa.
Los problemas derivados de esta situación han contribuido a una degradación
importante del servicio de correo electrónico, permitiendo la proliferación de "correo
basura" y poniendo en entredicho la imagen de las organizaciones.
Para paliar estas "deficiencias", se han generalizado mecanismos de control de
acceso a los servidores SMTP basados en la confianza respecto a clientes locales o en la
desconfianza respecto a determinadas organizaciones "fichadas" como origen de correo
basura. Si bien es cierto que estas medidas han conseguido limitar el uso fraudulento de
los servidores SMTP de las organizaciones por parte de terceros, no han conseguido
evitar el envío de mensajes falsificados desde el interior de la organización y han
dificultado la utilización del servicio a personas de la organización con necesidad de
desplazarse.
ESTÁNDARES QUE REGULAN SMTP.
•
•
•
•
•
RFC 821 – SMTP.
RFC 1123 – Requerimientos para host de Internet-Aplicación y soporte.
RFC 1651 – SMTPSE.
RFC 1652 – SMTPSE para transporte MIME con codificación 8 bit.
RFC 1653 – SMTPSE para declaración de tamaño de mensaje.
PROTOCOLO ICMP.
Protocolo de mensajes de control Internet "ICMP"
Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar
defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol,
protocolo de mensajes de control y error) se encarga de informar al origen si se ha
producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de
notificar los errores, sino que también transporta distintos mensajes de control. El
protocolo ICMP está definido en la RFC 79.
El protocolo ICMP únicamente informa de incidencias en la red pero no toma ninguna
decisión. Esto será responsabilidad de las capas superiores. Los mensajes ICMP viajan
en el campo de datos de un datagrama IP.
El Protocolo IP utiliza el protocolo de mensajes de control Internet "ICMP Internet
Control Message Protocol" para informar de los errores que pueden ocurrir durante el
enrutamiento de paquetes IP. El protoclo ICMP utiliza el soporte básico de IP como si
se tratara de un protocolo de nivel superior. Sin embargo, ICMP es realmente una parte
integral del protocol IP, y debe ser implementado por todo módulo IP.
Los mensajes ICMP son enviados en varias situaciones: por ejemplo, cuando un
datagrama no puede alcanzar su destino, cuando un enrutador no dispone de capacidad
de almacenamiento temporal para reenviar un paquete IP, y cuando el enrutador puede
dirigir al computador para enviar el tráfico por una ruta más corta. El propósito de
estos mensajes de control no es hacer a IP fiable, sino suministrar información sobre
los problemas en el entorno de comunicación.
Los mensajes ICMP se envían usando la cabecera IP básica. El primer octeto de la
parte de datos del datagrama es el campo de tipo ICMP; el valor de este campo
determina el formato del resto de los datos. Los campos etiquetados como "no usado"
están reservados para posteriores extensiones y deben ser cero al ser enviados, y los
receptores no deberán usar estos campos (excepto para incluirlos en la suma de
control).
Datagramas ICMP
El protocolo ICMP no usa número de puerto de servicio y es por eso un poco más
dificultoso coleccionar detalles. ICMP usa un número de tipos diferentes de datagramas.
Muchos de éstos son inofensivos y normales, mientras otros sólo deben observarse bajo
circunstancias especiales. A veces las personas con mucho tiempo en sus manos
intentan maliciosamente deteriorar el acceso de un usuario a la red, generando grandes
cantidades de mensajes ICMP. Esto es comúnmente denominado saturamiento ping.
Aun cuando la contabilidad IP no puede hacer nada para prevenir este problema
podemos al menos colocar reglas de contabilidad en un lugar que nos muestre si alguien
lo ha estado intentando.
ICMP no usa los puertos como lo hacen TCP y UDP. En cambio ICMP tiene mensajes
tipo ICMP. Podemos construir reglas de contabilidad para cada tipo de mensaje ICMP.
Para hacer esto, colocamos el mensaje ICMP y el número del tipo en lugar del puerto en
la orden de contabilidad ipfwadm.
Si usted especifica la dirección origen y/o destino en sus reglas, puede seguir la pista de
dónde están viniendo los ping, tales como si ellos se originan dentro o fuera de su red.
Una vez que ha determinado de dónde están viniendo los datagramas, usted puede
decidir si quiere poner reglas en un sitio para evitarlos o tomar alguna otra acción, como
avisar al dueño de la red agraviante para avisarles del problema, o quizás incluso, acción
legal si el problema es un acto malévolo.
Por ejemplo, asumiremos que nos encontramos en erdos y queremos hacer telnet al
puerto 12345 en quark, pero no hay procesos escuchando en ese puerto. Cuando el
primer paquete TCP para este puerto llegue a quark, la capa de red reconocerá esta
llegada e inmediatamente enviará un mensaje ICMP a erdos empezando con “Port
Unreachable”.
El protocolo ICMP ofrece varios mensajes diferentes, muchos de ellos tratan con
condiciones de error. De todas maneras, hay un mensaje muy interesante denominado
mensaje Redirect. Lo genera el módulo de encaminamiento cuando detecta que otro
puesto está usándolo como pasarela, aunque exista una ruta más corta. Por ejemplo,
después del arranque, la tabla de encaminamiento de sophus puede estar incompleta.
Puede que contenga las rutas a la red de Matemáticas, a la dorsal FDDI, y el
encaminamiento por defecto apuntando a la pasarela del Groucho Computing Center.
De este modo, los paquetes para quark serán enviados a gcc1 en vez de a niels, la
pasarela del departamento de Fisicas. Cuando recibe un datagrama como éste, gcc1
notará que esa es una mala elección como ruta y reenviará el paquete a niels, mientras
tanto envía un mensaje Redirect ICMP a sophus diciéndole la ruta superior.
Esta parece ser una forma muy inteligente de evitar la configuración manual de las rutas
excepto las más básicas. De cualquier forma, hay que decir que depender de esquemas
de encaminamiento dinámicos, sean RIP o mensajes Redirect ICMP, no es siempre una
buena idea. Redirect ICMP y RIP ofrecen muy poca o ninguna capacidad de verificar si
alguna información de encaminamiento es efectivamente auténtica. Esta situación
permite a malévolos inútiles perturbar el desarrollo del tráfico de la red completa, o
incluso algo peor. Consecuentemente, el código de red de GNU/Linux trata los mensaje
Network Redirect como si fuesen Host Redirects. Esto minimiza los daños de un ataque
restringiéndolos a sólo un puesto, en vez de la red completa. Por otro lado, esto significa
que se generá un poco más de tráfico en las mismas condiciones, ya que cada puesto
hace que se genere un mensaje Redirect ICMP.
Cada una de las órdenes de configuración del firewall le permite especificar tipos de
datagrama de ICMP. Al contario que los puertos de TCP y de UDP, no existe un fichero
de configuración conveniente que liste los tipos de datagramas y sus significados. Los
tipos de datagrama de ICMP se definen en el RFC-1700, el RFC de los números
asignados. Los tipos de datagrama de ICMP aparecen también listados en uno de los
ficheros de cabecera de la biblioteca estándar de C. El fichero
/usr/include/netinet/ip_icmp.h, que pertenece al paquete con la biblioteca estándar de
GNU, y que los programadores de C utilizan cuando escriben 'software' de red que
utilice el protocolo de ICMP, también define los tipos de datagrama de ICMP. La
interfaz de la orden iptables le permite especificar los tipos de ICMP por su nombre, por
lo que también se muestran los nombre nemotécnicos que utiliza.
Tabla 9-2. Tipos de datagramas de ICMP
Número de tipo Nnemónico de iptables Descripción del tipo
0
echo-reply
Respuesta a eco
3
destination-unreachable Destino inaccesible
4
Source-quench
Disminución del tráfico desde el origen
5
Redirect
Redirección
8
echo-request
Solicitud de eco
11
time-exceeded
Tiempo superado
12
parameter-problem
Problema de parámetros
13
timestamp-request
Solicitud de marca de tiempo
14
timestamp-reply
Respuesta de marca de tiempo
15
None
Solicitud de información
16
None
Respuesta de información
17
address-mask-request
Petición de máscara de dirección
18
address-mask-reply
Respuesta de máscara de dirección
Tipo
Encabezado
del datagrama
Encabezado
de la trama
Datos ICMP
Área de datos del datagrama IP
Área de datos de la trama
Final de la
trama
Debido a que el protocolo IP no es fiable puede darse el caso de que un mensaje ICMP
se pierda o se dañe. Si esto llega a ocurrir no se creará un nuevo mensaje ICMP sino que
el primero se descartará sin más.
Los mensajes ICMP comienzan con un campo de 8 bits que contiene el tipo de mensaje.
El resto de campos son distintos para cada tipo de mensaje ICMP.
nota: El formato y significado de cada mensaje ICMP está documentado en la RFC
792.
Solicitud y respuesta de eco
Los mensajes de solicitud y respuesta de eco, tipos 8 y 0 respectivamente, se utilizan
para comprobar si existe comunicación entre 2 hosts a nivel de la capa de red. Estos
mensajes comprueban que las capas física (cableado), acceso al medio (tarjetas de red) y
red (configuración IP) están correctas. Sin embargo, no dicen nada de las capas de
transporte y de aplicación las cuales podrían estar mal configuradas.
PING envía mensajes de solicitud de eco a un host remoto e informa de las
respuestas.
1. A envía un mensaje ICMP de tipo 8 (Echo) a B
2. B recibe el mensaje y devuelve un mensaje ICMP de tipo 0 (Echo Reply) a
A
3. A recibe el mensaje ICMP de B y muestra el resultado.
Si el host de destino no existiese o no estuviera correctamente configurado
recibiríamos un mensaje ICMP de tipo 11 (Time Exceeded).
Si tratamos de acceder a un host de una red distinta a la nuestra y no existe un
camino para llegar hasta él, es decir, los routers no están correctamente
configurados o estamos intentando acceder a una red aislada o inexistente,
recibiríamos un mensaje ICMP de tipo 3 (Destination Unreachable).
Utilización de PING para diagnosticar errores en una red aislada
.
Nota: El comando ping 127.0.0.1 informa de si están correctamente instalados los
protocolos TCP/IP en nuestro host. No informa de si la tarjeta de red de nuestro host
está correcta.
Utilización de PING para diagnosticar errores en una red de redes
En el caso producirse errores de comunicación en una red de redes con más de un router
(Internet es el mejor ejemplo), se suele utilizar el comando PING para ir diagnosticando
los distintos routers desde el destino hasta el origen y descubrir así si el fallo es
responsabilidad de la red de destino, de una red intermedia o de nuestra red.
Algunos hosts en Internet tienen deshabilitadas las respuestas de eco (mensajes ICMP
tipo 0) como medida de seguridad. En estos casos hay que utilizar otros mecanismos
para detectar si responde.
Mensajes ICMP de tiempo excedido
Los datagramas IP tienen un campo TTL (tiempo de vida) que impide que un mensaje
esté dando vueltas indefinidamente por la red de redes. El número contenido en este
campo disminuye en una unidad cada vez que el datagrama atraviesa un router. Cuando
el TTL de un datagrama llega a 0, éste se descarta y se envía un mensaje ICMP de tipo
11 (Time Exceeded) para informar al origen.
Tiempo de Vida (TTL, "Time To Live")
Si, de acuerdo con la información existente en las tablas de enrutamiento de la pasarela,
la red especificada en el campo de destino internet de un datagrama es inaccesible, p.
ej., si la distancia a la red es infinita, la pasarela pue de enviar un mensaje de destino
inaccesible al "host" de origen del datagrama. Además, en algunas redes, la pasarela
puede ser capaz de determinar si el "host" de destino en internet es inalcanzable. Las
pasarelas de estas redes pueden enviar al "host" de origen mensajes de destino
inaccesible cuando el "host" de destino sea inaccesible.
Si en el "host" de destino el módulo IP no puede enviar el datagrama debido a que el
módulo de protocolo o el puerto del proceso indicado no estén activos, puede enviar un
mensaje de destino inaccesible al "host" de origen.
Otro caso se presenta cuando un datagrama debe ser fragmentado para poder ser
enviado a través de una pasarela aún cuando el indicador "Don't Fragment" (No
Fragmentar) esté activado. En este caso la pasarela debe desechar el datagrama y puede
devolver un mensaje de destino inaccesible.
Mensaje de Tiempo Superado ("Time Exceeded Message")
Si la pasarela que está procesando el datagrama detecta que el campo tiempo de vida es
cero debe desechar el datagrama. La pasarela puede también notificar el suceso al "host"
de origen mediante el mensaje de tiempo de vida superado. Si un "host" que trata de
reensamblar un datagrama fragmentado no puede hacerlo en el tiempo límite debido a
fragmentos perdidos, descartará el datagrama y puede enviar un mensaje de tiempo de
reensamblaje superado.
Si el fragmento cero no está disponible no es necesario enviar ningún mensaje de
tiempo superado.
Mensaje de Problema de Parámetros ("Parameter Problem Message")
Si la pasarela o "host" que procesa el datagrama encuentra un problema con los
parámetros de cabecera, de modo que no puede completar el procesamiento del
datagrama, debe desecharlo. Una potencial fuente de este tipo de problema son los
argumentos incorrectos en una opción. La pasarela o "host" puede también notificarlo al
"host" de origen mediante el mensaje de Problema de Parámetros. Este mensaje sólo se
envía si el error provocó que el datagrama fuera desechado.
El puntero identifica el octeto de la cabecera del datagrama original donde fue detectado
el error (puede estar en medio de una opción). Por ejemplo, 1 indica que algo va mal
con el Tipo de Servicio y (si hay opciones presentes) 20 indica un error en el código de
tipo de la primera opción.
Mensaje de Disminución del Tráfico desde el Origen ("Source Quench Message")
Una pasarela puede descartar datagramas de internet si no dispone del espacio de búfer
suficiente para ponerlos en la cola de salida hacia la próxima red de la ruta a la red de
destino. Si una pasarela descarta un datagrama por este motivo, puede enviar un
mensaje de Disminución de Tráfico desde el Origen (DTO) al "host" de origen del
datagrama. Un "host" de destino puede también enviar un DTO si los datagramas llegan
demasiado rápido para ser procesados. El DTO es una petición al "host" para que
reduzca el ritmo al que envía tráfico al "host" de destino. Una pasarela puede enviar un
DTO por cada mensaje que descarta. Al recibir un DTO, el "host" de origen debe
disminuir el ritmo de generación de tráfico al destino especificado hasta que deje de
recibir DTOs de la pasarela. Después, el "host" de origen puede aumentar gradualmente
la frecuencia de mensajes al destino hasta que vuelva a recibir DTOs.
La pasarela o "host" puede enviar el DTO cuando se está acercando al límite de su
capacidad, antes que esperar a que ésta se sobrepase. Esto significa que el datagrama de
datos que provocó el DTO puede que sea enviado.
Mensaje de Redirección ("Redirect Message")
La pasarela envía un mensaje de redirección a un "host" en la siguiente situación: Una
pasarela, G1, recibe un datagrama internet de un "host" en una red a la cual la pasarela
está conectada. G1 comprueba su tabla de encaminamiento y obtiene la dirección de la
siguiente pasarela, G2, en la ruta hacia la red X, destino del datagrama en internet. Si
G2 y el "host" identificado por la dirección internet de origen del datagrama están en la
misma red, se envía un mensaje de redirección al "host". Un mensaje de redirección
recomienda al "host" que dirija el tráfico destinado a la red X directamente a la pasarela
G2, ya que se trata de un camino más corto hacia el destino. La pasarela reenvía el
datagrama original a su destino en internet.
No se envía ningún mensaje de redirección para aquellos datagramas con opciones IP de
'ruta de origen' y la dirección de la pasarela en el campo dirección de destino, incluso si
existe una ruta mejor al destino final que la que pasa por la siguiente dirección en la ruta
de origen.
Mensaje de Eco o de Respuesta de Eco ("Echo or Echo Reply Message")
Los datos recibidos en el mensaje de eco deben ser devueltos en el mensaje de respuesta
de eco.
El identificador y número de secuencia pueden ser usados por el emisor del eco como
referencia para emparejar las respuestas con las peticiones de eco. Por ejemplo, el
identificador podría usarse como un puerto en TCP o UDP para identificar una sesión, y
el número de secuencia se iría incrementando con cada nueva petición de eco enviada.
El "host" que hace eco devuelve estos mismos valores en la respuesta de eco.
Mensaje de Solicitud de Marca de Tiempo o de Respuesta de Marca de
Tiempo ("Timestamp or Timestamp Reply Message")
Los datos recibidos (una marca de tiempo) en el mensaje son devueltos en la respuesta
junto con marcas de tiempo adicionales.
La marca de tiempo es un entero de 32 bits que indica los milisegundos transcurridos
desde la medianoche UT. Un posible uso de estas marcas de tiempo se describe en Mills
[5].
La Marca de Tiempo de Origen es el instante en el cual el mensaje fue manipulado por
última vez por el emisor antes de enviarlo. La Marca de Tiempo de Recepción es el
instante en el cual el
destinatario recibe el mensaje. Por último, la Marca de Tiempo de Transmisión es el
momento en el cual el destinatario manipula el mensaje por última vez antes de
enviarlo.
Si la medida del tiempo no está disponible en milisegundos, o bien no puede ser
indicada respecto a la medianoche UT, entonces se puede insertar cualquier valor de
tiempo en la marca de tiempo, siempre y cuando el bit más significativo de la marca de
tiempo sea puesto a uno para indicar que se trata de un valor no estándar.
El Identificador y Número de Secuencia pueden ser usados por el emisor del eco como
ayuda para relacionar las respuestas con sus respectivas peticiones. Por ejemplo, el
identificador puede usarse como un puerto en TCP o UDP para identificar una sesión, y
el número de secuencia podría ser incrementado con cada petición enviada. El
destinatario devuelve estos mismos valores en respuesta.
Mensaje de Solicitud de Información o de Respuesta de Información
("Information Request or Information Reply Message").
Este mensaje puede ser enviado indicando en el campo dirección de origen de la
cabecera IP la dirección de red de origen y los campos de dirección de destino puestos a
cero.
Este mensaje puede ser enviado con la parte de red de la dirección de origen de la
cabecera IP tomando un valor cero.
El módulo IP que ha de responder debería enviar la respuesta con las direcciones
completamente especificadas. Este es un mensaje mediante el cual un "host" puede
saber el número de la red en la
que se encuentra.
El Identificador y Número de Secuencia puede ser usado por el emisor del eco como
ayuda para relacionar las respuestas con sus respectivas peticiones. Por ejemplo, el
identificador puede usarse como un puerto en TCP o UDP para identificar una sesión, y
el número de secuencia podría ser incrementado con cada petición enviada. El
destinatario devuelve estos mismos valores en la respuesta. El Código 0 puede ser
recibido desde una pasarela o un "host".
Consideraciones De la Seguridad
Cuando no ha expirado una asociación anterior de la seguridad entre los partidos, estos
mensajes SE DEBEN enviar con la autentificación. Sin embargo, el nodo NO DEBE
establecer dinámicamente una nueva asociación de la seguridad para el propósito único
de authenticar estos mensajes. La gerencia dominante automatizada es de cómputo
intensiva. Esto se podía utilizar para una negación muy seria del ataque del servicio.
Sería muy fácil hundir una blanco con SPIs falso de fuentes al azar del IP, y hace que
comience para arriba sesiones dominantes inútiles numerosas de la gerencia para
informar auténtico al remitente supuesto. En el acontecimiento de la pérdida de estado
(tal como un fallo del sistema), el nodo necesitará enviar mensajes de la falta a todos los
partidos que procuren la comunicación subsecuente. En este caso, el nodo pudo haber
perdido la técnica de gerencia dominante que fue utilizada para establecer la asociación
de la seguridad. Deje mucho mejor simplemente a pares saber que había una falta, y
déjelos solicitar a la gerencia dominante según lo necesitado (en sus descansos
escalonados). Recordarán la técnica de gerencia dominante anterior, y la recomienzan
agraciado. Esto distribuye la carga del recomenzar entre sistemas, y las ayudas permiten
que el nodo recientemente fallado maneje sus recursos de cómputo. Además, estos
mensajes informan al recipiente cuando el remitente del ICMP está bajo ataque.
Desemejante de otros mensajes de error del ICMP, los mensajes proporcionan
suficientes datos para determinarse que estos mensajes están en respuesta a mensajes
previamente enviados. Por lo tanto, es imprescindible que el recipiente acepta
authenticado y unauthenticated mensajes de la falta. El registro del recipiente DEBE
indicar cuando los mensajes del ICMP no se validan, y cuando los mensajes del ICMP
no están en respuesta a un mensaje anterior válido
Concepto del ICMP .- el paquete aislado perdió reconocido por el problema de los
protocolos de un nivel más alto de todos los paquetes que eran perdidos = > colección
específica y evitable de los detinations posibles predefinidos ICMP, IP, TCP de los
mensajes de error...
Detalles del ICMP; especialmente silbido de bala etc del WRT. obligatorio para cada
ICMP del anfitrión de TCP/IP como necesidad llana pseudo-superior de la carga útil de
limitaciones de prevenir fugitivo las cascadas enumeran (p. 175) TFTP que no funciona
(tapa del p. 179) otros ejemplos detallados (pp. 180-181)
ediciones de seguridad (comienzo) la comunicación administrativo prohibió (p.181) la
edición los listserves posibles de las respuestas, USENET vuelva a dirigir las ediciones
(pp. 184-185) concepto revisión de las comunicaciones de la rebajadora de las ediciones
silbido de bala el ejemplo del laboratorio puso cómo en ejecucio'n (p. 171)
otras utilidades traceoute utilizado para qué: el diagnóstico del problema de la red no
automatiza; mismo traceroute intensivo del recurso: subsistencia que incrementa
descubrimiento del MTU de la trayectoria del parámetro de la TTL .
una discusión más general de capas el establecimiento de una red en relación con de la
versión de los números OSI de la capa implica señales eléctricas = > significación de los
repetidores de digital contra los puentes de las señales análogas: tome las decisiones
solamente en la destinación en el nivel de Ethernet porqué: el funcionamiento publica el
concepto original de Ethernet y del token ring como analogía de la línea de partido
contra LANS cambiado (en la capa 2!) las rebajadoras, acodan 3 interruptores:
comtemplaban la destinación del nivel del IP en tomar decisiones del passthru seguridad
vía la encaminamiento terminante de la fuente ¿el punto principal es que estas ediciones
son todavía venir insisten que la trayectoria sea de una lista controlada es ésta la
dirección derecha a ir? atado con alambre contra la versión sin hilos de la comunicación
WW II: telegrafía contra la radio a ser características continuadas del servicio el viaje de
cada paquete es no confiable independiente; los nodos proporcionan el mejor esfuerzo
implican mucho que se hará en nivel del transporte
Interfaz
Este módulo ha sido diseñado especialmente para comunicarse con la capa IP. Aunque
muchos de sus servicios también están disponibles a otros niveles, deben utilizarse con
precaución. El hecho de que las capas superiores puedan utilizar el ICMP es una de las
razones por las que IP envía hacia arriba la cabecera IP original de los datagramas que
se reciben.
El ICMP ("Internet Control Message Protocol") se encarga de notificar diferentes
errores y problemas que pueden producirse durante la transmisión de paquetes TCP/IP
entre sistemas. En la práctica, los ataques basados en ICMP consisten en enviar
mensajes falsos para hacer creer al sistema del usuario o al servidor IRC que se han
detectado errores, y así provocar el corte de la comunicación que ambos mantenían.
Para que el ataque se realice con éxito es necesario enviar algún mensaje de error -como
"Bad Port", "Network Unreachable", etc.-, al puerto utilizado para la comunicación IRC
del cliente o del servidor. En el caso de los servidores suelen ser puertos fijos -como,
por ejemplo, el estándar 6667-, mientras que en los clientes suele ser un puerto
dinámico (a partir del 1024). Para evitar ataques como el anteriormente descrito, tanto
los servidores como los clientes pueden utilizar cortafuegos hardware o software que
filtren determinados paquetes ICMP.
Aplicaciones de ICMP
Hay dos aplicaciones simples y muy extendidas basadas en ICMP: el Ping y el
Traceroute. El Ping usa los mensajes ICMP Echo y Echo Reply para determinar si un
host es alcanzable. El Traceroute envía datagramas IP con bajos TTLs para que expiren
durante la ruta que les dirige al destino. Utiliza los valores de los mensajes ICMP Time
Exceeded para determinar en que parte de la red expiraron los datagramas y reconstruye
así un esquema de la ruta hasta el host de destino. Estas aplicaciones se explican más
detalladamente en Ping y Traceroute.
PROTOCOLO ARP.
ARP (Address Resolution Protocol) es el encargado de realizar las
traducciones de direcciones lógicas a direcciones físicas. Esto es, traducir las
direcciones IP utilizadas en las capas superiores a direcciones de dispositivos
dependientes del hardware subyacente. Este hardware puede estar constituido por una
red Ethernet, FDDI, un sistema AX.25, etc., cada uno de los cuales tiene sus propias
características de direccionamiento. Este nivel, por tanto, aisla a las capas superiores (en
especial a la capa IP) de los diferentes esquemas de nombramiento posibles a nivel
físico.
Cuando un nodo de la red desea enviar un paquete a otra máquina debe averiguar su
dirección física. La máquina fuente conoce sus propias direcciones IP y física (las
direcciones de sus interfaces de red), pero toda la información que dispone sobre la
máquina remota es su dirección IP. Para conocer la dirección física equivalente se envía
un mensaje ARP Broadcast (en las redes sin la opción de Broadcast se suele confiar la
tarea de resolver direcciones a un nodo conocido por los demás). Este mensaje lo
reciben todas las máquinas de la red, pero sólo contesta la máquina solicitada. Este
proceso, para el caso especial de una red Ethernet, se describe en [RFC826].
Existen situaciones, no obstante, en los que una máquina ni siquiera conoce su propia
dirección IP. Es el caso, por ejemplo, de estaciones sin disco (en particular, terminales
X-Window). En esta situación todas las estaciones son idénticas y ejecutan el mismo
software (almacenado en una ROM o EPROM). La única diferencia entre ellas es la
dirección física de su interfaz de red. Dado que para comunicarse con otros nodos
necesitan conocer su propia dirección IP, realizan un proceso RARP (Reverse Address
Resolution Protocol). Este consiste en el envío de un paquete RARP Broadcast. Este
paquete es recibido, en particular, por una máquina (un servidor) que contiene una tabla
de traducción entre direcciones físicas y direcciones IP. Dicha máquina envía a la
primera una respuesta indicando qué dirección IP le corresponde. El procedimiento se
describe en [RFC903].
Existen, todavía, dos extensiones al protocolo ARP a tener en cuenta. El primero
[RFC1293] describe un procedimiento por medio del cual un sistema dado puede
averiguar la o las direcciones del nodo situado al otro extremo de un enlace punto a
punto. Ello resulta especialmente importante, por ejemplo, en redes de circuitos
virtuales como ATM y Frame Relay. La segunda extensión [RFC1868] define un
algoritmo a través del que un nodo concreto puede anunciar su retirada de la red. Ello
es muy útil en accesos PROXY donde las direcciones asignadas a los nodos son
dinámicas. Recientemente se ha definido una extensión al protocolo RARP
[RFC1931] que permite la asignación de direcciones dinámicas a estaciones sin
disco. Interfaz
PROCESOS DE ARP.-
PROC_ARP_BC.- Este proceso se encarga de inicializar y finalizar el módulo ARP.
Los mensajes admitidos son MSG_INIT y MSG_QUIT. Los campos de información
son ignorados.
PROC_ARP_SUP.- Este proceso es el encargado de realizar la traducción entre
direcciones IP y direcciones físicas del dispositivo. Se sitúa entre la capa IP y el nivel
físico. Admite mensajes MSG_MBUF con los campos siguientes:
Campo1:
Ignorado.
Campo2: Nombre del canal físico a través del cual se envía el datagrama.
Campo3: Dirección IP destino.
En la implementación actual este proceso envía el mensaje directamente a la capa física,
sin efectuar ninguna manipulación previa.
Estos son 4 tipos de mensajes ARP que podran ser mandados pore l protocolo ARP. Son
identificados por 4 valores en el campo “operation” de un mensaje ARP. Los tipos de
mensaje son:
ARP request, ARP reply, RARP request, RARP reply
Dos máquinas en una red física, se pueden comunicar solamente si conocen sus
direcciones físicas de red. Los protocolos ARP y RARP se encarga de transformar una
dirección IP en la dirección física correcta cuando un anfitrión o un encaminador envían
un paquete a través de una red física.
Cuando dos máquinas dentro de una red física requieren compartir información nos
encontramos con el problema de que ambas máquinas cuentan con una dirección IP así
como una dirección física, pero para dicha transmisión de información solo la pueden
realizar a través de la dirección física.
Para resolver el problema anterior la máquina A debe transformar la dirección IP en una
dirección física que es la que utiliza el hardware para comunicarse con la máquina B. El
problema de transformar direcciones de alto nivel en direcciones físicas se conoce como
problema de asociación de direcciones.
TCP/IP utiliza dos técnicas para la definición de direcciones:
1. Asociación mediante transformación directa.
2. Definición mediante enlace dinámico.
Asociación mediante transformación directa
Esta técnica se utiliza en redes tipo proNet que utilizan números enteros pequeños para
sus direcciones físicas y permite que el usuario elija una dirección de hardware cuando
instala una tarjeta de interfaz en una computadora. Por lo tanto podemos asignar una
dirección IP con el campo hostid igual a 1, 2, 3, etc. y configurar la dirección física con
ese mismo nombre. Ejemplo:
Dirección
192.5.48.3
IP
3
Dirección
física
Por lo tanto la asociación mediante transformación directa se basa en crear una función
que resuelva la conversión entre direcciones IP y físicas de acuerdo al esquema de
numeración que se utilizó en la instalación de la tarjeta de interfaz.
Pero este tipo de conversión se dificulta en redes donde no se puede elegir la dirección
física como es el caso de redes orientadas a la conexión como ATM. En estos casos se
podría utilizar una tabla que almacene en memoria los pares de direcciones y la función
se encargaría de buscar la dirección física correspondiente para el envío de información.
Definición mediante enlace dinámico
Esta técnica es más utilizada en redes donde no podemos configurar la dirección física
como es el caso de redes Ethernet.
Para evitar el uso de tablas en memoria, se utiliza un protocolo de bajo nivel para
asignar direcciones en forma dinámica conocido como Protocolo de Asociación de
Direcciones (ARP).
La función de este protocolo es transmitir por difusión un paquete especial que pide al
anfitrión que posee la dirección IP deseada, que responda con su dirección física. Todos
los anfitriones reciben la solicitud, pero solo el anfitrión deseado reconoce su propia
dirección IP y envía una respuesta que contiene su dirección física.
Memoria intermedia para asociación de direcciones
La difusión es muy costosa para utilizarse cada vez que una máquina se quiere
comunicar con otra. Para reducir los costos las computadoras que utilizan ARP cuentan
con una memoria intermedia que almacena las direcciones IP y las direcciones físicas de
las computadoras con las que se han comunicado. De esta manera, no se requiere
utilizar ARP cada vez que se quiere comunicar con una computadora ya que primero
busca si existe la relación de direcciones en la memoria intermedia.
La información así obtenida se guarda luego en una tabla ARP de orígenes y destinos,
de tal forma que en los próximos envíos al mismo destinatario no será ya necesario
realizar nuevas peticiones ARP, pués su dirección MAC es conocida.
Del mismo modo las computadoras que contestan el mensaje de difusión almacenan las
direcciones de la máquina que solicito la comunicación. Estas direcciones son enviadas
dentro del paquete que envió la máquina solicitante dentro del ARP.
Encapsulación y formato del protocolo ARP
Cuando los mensaje ARP viajan de una máquina a otra, se deben transportar en tramas
físicas.
Para identificar que la trama transporta un mensaje ARP, el transmisor asigna un valor
especial al campo de tipo en el encabezado de la trama y coloca el mensaje ARP en el
campo de datos de la misma.
A diferencia de la mayor parte de los protocolos, los datos en los paquetes ARP no
tienen un encabezado con formato fijo. Por el contrario, para hacer que ARP sea útil
para varias tecnologías de red, la longitud de los campos que contienen direcciones
depende del tipo de red. Sin embargo para hacer posible la interpretación de un mensaje
ARP arbitrario, el encabezado incluye campos fijos cerca del comienzo, que especifican
la longitud de las direcciones que se encuentran en los campos siguientes.
El formato de este encabezado es el siguiente:
Tipo de hardware especifica un tipo de interfaz de hardware para el que el transmisor
busca una respuesta.
Tipo de prototipo especifica el tipo de dirección de protocolo de alto nivel que
proporcionó el transmisor.
Operación especifica una solicitud ARP(1), una respuesta ARP(2), una solicitud
RARP(3) o una respuesta RARP(4).
HLEN y PLEN permiten que ARP se utilice con redes arbitrarias ya que éstas
especifican la longitud de la dirección de hardware y la longitud de la dirección del
protocolo de alto nivel.
SENDER HA y SENDER IP proporcionan las direcciones IP y de hardware del
transmisor.
TARGET IP y TARGET HA proporcionan la dirección IP del objetivo (ARP) o la
dirección de hardware del objetivo (RARP).
Es importante resaltar que el formato de una dirección física utilizada por los
protocolos 802 es el siguiente:
1Byte - 2Byte - 3Byte - 4Byte - 5Byte - 6Byte
ARP es pués un protocolo de bajo nivel que oculta el direccionamiento de la red en las
capas inferiores, permitiendo asignar al administrador de la red direcciones IP a los host
pertenecientes a una misma red física.
Los mensajes de petición ARP (ARP request) contienen las direcciones IP y Ethernet
del host que solicita la información, junto con la dirección IP de la máquina destino. Los
mensajes de respuesta ARP (ARP reply) son creados por el ordenador propietario de la
IP buscada, que rellena el campo vacío con su dirección Ethernet y lo envía
directamente al host que cursó la solicitud.
Cuando el host origen recibe la respuesta ARP y conoce la dirección física del host
destino introduce esos datos en una tabla especial alojada en su caché, y lo mismo va
haciendo con cada una de las parejas dirección IP-dirección física que utiliza en sus
diferentes comunicaciones con otros host. Y no sólo eso; como las peticiones ARP se
realizan por multidifusión, cada vez que pasa ante él un mensaje de respuesta ARP
extráe del mismo la pareja IP-MAC y la incorpora a su tabla. De esta forma se va
construyendo la tabla dinámicamente.
En sucesivas comunicaciones entre ambos host ya no será preciso realizar una nueva
petición ARP, ya que ambos host saben las direcciones del otro.
Estas tablas se denominan tablas ARP o caché ARP, y son fundamentales para el
funcionamiento y rendimiento óptimo de una red, pués reducen el tráfico en la misma al
evitar preguntas ARP innecesarias.
tabla ARP
dirección IP
dirección física
212.5.26.1
26-5A-C5-42-FD-11
212.5.26.2
2C-2A-48-A6-36-00
212.5.26.3
5D-F1-80-02-A7-93
Las tablas ARP son necesarias para poder dirigir tramas en una red, ya que las
direcciones IP y las direcciones de las tarjetas de red son independientes, y no tienen
ninguna equivalencia entre ellas, siendo necesario entonces algún método para poder
obtener la equivalencia entre ambas.
De forma general, cuando una máquina desea comunicarse con otra a partir de su IP, lo
primero que hace es mirar en su tabla ARP si tiene la dirección física asociada a esa
dirección lógica. Si es así, envía directamente los paquetes al host destino. Si no
encuentra la entrada adecuada en la tabla, lanza una petición ARP multidifusión a todos
los host de su red, hasta encontrar respuesta, momento en el que incorpora la nueva
entrada en su tabla ARP y envía los paquetes al destino.
Si la máquina destino no existe, no habrá respuesta ARP alguna. En estos casos, el
protocolo IP de la máquina origen descartará las tramas dirigidas a esa dirección IP.
Cuando un host realiza una petición ARP y es contestado, o cuando recibe una petición
o trama, actualiza su tabla ARP con las direcciones obtenidas. Estas entradas en la tabla
tienen un tiempo de vida limitado, con objeto de no sobrecargar la tabla con datos
innecesarios, que suele ser de unos 20 minutos.
Si quieresver la tabla ARP de una máquina, tan sólo tenéis que abrir la consola del
sistema y escribir el comando "arp -a". Si no encontráis entradas, abrid el navegador y
hacer una petición HTTP a cualquier página web. Si volvéis a introducir en la consola el
camando os aparecerá la entrada ARP del router o proxy que uséis para salir a Internet.
En mi caso he obtenido la siguiente entrada:
.
Existen tecnologías de red que no usan la pila de protocolos TCP/IP, y que por lo tanto
no manejan direcciones IP como base de enrutamiento general, por lo que debe haber
algo que permita una técnica común de envío de tramas una vez llegadas a la red
destino. Y este algo son las direcciones de las tarjetas de red de los host.
Comunicar entonces dos máquinas pertenecientes a redes o subredes diferentes, si
la máquina destino no "oye" la petición ARP de la máquina origen.Esto es posible porque cuando un host realiza una petición ARP y no encuentra
respuesta, envía la trama al router que tiene configurado como "gateway por defecto",
siendo éste el encargado de transmitir la trama al exterior, hacia otros routers, enviando
las tramas con la dirección IP del host destino y con su propia dirección física, proceso
que continúa hasta que la trama llega al router perteneciente a la red en la que se
encuentra el host destino. Entonces éste hace una petición ARP, obtiene la dirección
física del host final y le envía la trama.
Cómo se entregan las tramas cuando me conecto mediante un modem y mi
proveedor de Internet.- Pués es conexiones a dial-up, como las que hacemos a través
de la línea telefónica, no es necesaria tarjeta de red alguna (en realidad pertenecemos a
una red virtual, siendo los modem una especie de tarjetas de red virtuales), por lo que
los paquetes se entregan directamente por medio de la dirección IP dinámica que nos
asigna el proveedor en cada conexión y usando para ello el protocolo PPP.
ARP Proxi.En muchas redes, para evitar el proceso de peticiones ARP sin respuesta, se usa el
protocolo denominado ARP Proxi, en el que el router de salida recoge todas las
peticiones ARP que circulan por la red y observa si la IP destino pertenece a un host de
la misma o a un host de otra red. En el primer caso deja pasar la petición, para que séa
respondida por la máquina destino, pero en el segundo caso es él el que responde
directamente a la máquina peticionaria con su propia dirección física, para
posteriormente enrutar las tramas hacia la red destino.
Seguridad y ARP.Al igual que ocurre con casi todos los protocolos de comunicaciones, y en concreto
TCP/IP, el protocolo ARP puede ser usado por un posible atacante para objetivos no
deseados.
Una de las técnicas más usadas en este sentido es la conocida como ARP Spoofing que
,como su nombre indica, consiste el el uso del protocolo para hacerse pasar por quién no
se es en realidad, es decir, para suplantar a otra persona o máquina.
Básicamente consiste en enviar a la máquina objetivo del ataque un paquete con la
dirección IP que queremos suplantar pero con la dirección física de nuestra tarjeta de
red. En este caso, la máquina objetivo guardará la entrada ARP en su tabla caché, y a
partir de ese momento todos los paquetes que envíe a la dirección IP suplantada llegarán
a la máquina del atacante, y no a su legítimo destinatario. Este ataque dura
aproximadamente unos 20 minutos (varía según el sistema operativo de la máquina
atacada), que es el tiempo que se guardan las entradas en las tablas ARP.
Cómo podemos enviar a una máquina un paquete falseado
Existen diferentes programas circulando por Internet que precisamente hacen esto,
como arp-fun, que son fácilmente asequibles a cualquiera que los busque.
Estos ataques es posible realizarlos solo en el caso de redes LAN, ya que en cuanto nos
encontremos con conexiones dial-up (modems, por ejemplo) no existen tarjetas de red a
las que redireccionar. Además, las nuevas tarjetas de red hacen una actualización de las
tablas ARP caché en intervalos muy cortos (unos cinco minutos), por lo que el ataque es
de duración muy limitada.
Existen también programas específicos para controlar estos ataques, como ARPwatch,
que observan los cambios que se producen en las entradas IP/Ethernet, enviando un
correo al administrador de la red si aprecian cambios incorrectos.
ARP Gratuito
Cada vez que un computador inicia la configuración de una interface de red que hace
uso del protocolo ARP, el protocolo ARP envía un paquete ARP con el fin de
determinar si su dirección IP o dirección física está siendo utilizada por otro
computador y así ofrecer la oportunidad a los demás computadores de actualizar su
ARP Cache.
En un paquete ARP gratuito la dirección fisica destino es igual a la dirección física
Fuente, y la dirección IP destino es igual a la dirección IP fuente. Si algún computador
de la red local detecta un paquete ARP gratuito cuya dirección IP es la misma que la
configurada de sus interface de red el mismo envía un paquete ARP indicando su
dirección IP y dirección física al computador que transmitió el ARP gratuito. De esta
manera el computador que envió el ARP gratuito genera un mensaje de advertencia
indicando que dicha dirección IP está siendo utilizada por otro computador.
Nota: El protocolo ARP está definido en la RFC 826