Protocolo bootp



Descargar 145.39 Kb.
Página1/2
Fecha de conversión24.03.2017
Tamaño145.39 Kb.
  1   2
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:

    • 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.

    • 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 .



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.

    • 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 punto-a-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 host-pasarela, 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 ).

  • 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 . 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.



  1. 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".

  2. 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:. Cada uno de ellos recibirá una respuesta "250 OK" si el servidor conoce el destino, o un "550 No such user here" si no.

  3. 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 .". Nótese que se trata de la secuencia de terminación que el emisor debería usar para terminar los datos del mensaje.

  4. El cliente envía los datos línea a línea, acabando con la línea . que el servidor reconoce con "250 OK" o el mensaje de error apropiado si cualquier cosa fue mal.

  5. Ahora hay varias acciones posibles:

    • 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 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:

R: 250 OK


S: RCPT TO:

R: 250 OK

S: RCPT TO:

R: 550 No such user here

S: RCPT TO:

R: 250 OK


S: DATA

R: 354 Start mail input, end with .

S: Date: 23 Jan 89 18:05:23

S: From: Alex B. Carver

S: Subject: Important meeting

S: To:

S: To:

S: cc:

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

Datos ICMP

 

 

 





 

 

Encabezado del datagrama

Área de datos del datagrama IP

 

 



 



 

Encabezado de la trama

Á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.




Compartir con tus amigos:
  1   2


La base de datos está protegida por derechos de autor ©bazica.org 2019
enviar mensaje

    Página principal