TEMA:

SERVICIOS DE RED

SERVICIOS DE RED

CONTENIDO

DHCP DNS TELNET SSH FTP Y TFTP WWW: HTTP Y HTTPS NFS CIFS E-MAIL: SMTP, POP, IMAP , SASL

SERVICIOS DE RED

La finalidad de una red es que los usuarios de los sistemas informticos de una organizacin puedan hacer un mejor uso de los mismos mejorando de este modo el rendimiento global de la organizacin As las organizaciones obtienen una serie de ventajas del uso de las redes en sus entornos de trabajo, como pueden ser: Mayor facilidad de comunicacin. Mejora de la competitividad. Mejora de la dinmica de grupo. Reduccin del presupuesto para proceso de datos. Reduccin de los costos de proceso por usuario. Mejoras en la administracin de los programas. Mejoras en la integridad de los datos. Mejora en los tiempos de respuesta. Flexibilidad en el proceso de datos. Mayor variedad de programas. Mayor facilidad de uso. Mejor seguridad.

Para que el trabajo de una red sea efectivo, debe prestar una serie de servicios a sus usuarios, como son: Acceso.- estos servicios de acceso a la red comprenden tanto la verificacin de la identidad del usuario para determinar cules son los recursos de la misma que puede utilizar, como servicios para permitir la conexin de usuarios de la red desde lugares remotos.

Ficheros.- el servicio de ficheros consiste en ofrecer a la red grandes capacidades de almacenamiento para descargar o eliminar los discos de las estaciones. Esto permite almacenar tanto aplicaciones como datos en el servidor, reduciendo los requerimientos de las estaciones. Los ficheros deben ser cargados en las estaciones para su uso. Impresin.- este servicio permite compartir impresoras entre mltiples usuarios, reduciendo as el gasto. En estos casos, existen equipos servidores con capacidad para almacenar los trabajos en espera de impresin. Una variedad de servicio de impresin es la disponibilidad de servidores de fax. Correo.- el correo electrnico, aplicacin de red ms utilizada que ha permitido claras mejoras en la comunicacin frente a otros sistemas. Este servicio adems de la comodidad, ha reducido los costos en la transmisin de informacin y la rapidez de entrega de la misma. Informacin.- los servidores de informacin pueden bien servir ficheros en funcin de sus contenidos como pueden ser los documentos hipertexto, como es el caso de esta presentacin. O bien, pueden servir informacin dispuesta para su proceso por las aplicaciones, como es el caso de los servidores de bases de datos. Otros.- generalmente existen en las redes ms modernas que poseen gran capacidad de transmisin, en ellas se permite transferir contenidos diferentes de los datos, como pueden ser imgenes o sonidos, lo cual permite aplicaciones como: estaciones integradas (voz y datos), telefona integrada, servidores de imgenes, videoconferencia de sobremesa, entre otros. Un servicio de red, es la creacin de una red de trabajo en un ordenador. Para la prestacin de los servicios de red se requiere que existan sistemas en la red con capacidad para actuar como servidores. Los servidores y servicios de red se basan en los sistemas operativos de red. Un sistema operativo de red es un conjunto de programas que permiten y controlan el uso de dispositivos de red por mltiples usuarios. Estos programas interceptan las peticiones de servicio de los usuarios y las dirigen a los equipos servidores adecuados. Por ello, el sistema operativo de red, le permite a sta ofrecer capacidades de multiproceso y multiusuario. Los servicios de red son configurados en redes locales corporativas para asegurar la seguridad y la operacin amigable de los recursos. Los servicios ayudan a la red local a funcionar sin problemas y eficientemente. Las redes locales corporativas usan

servicios de red como DNS para dar nombres a las direcciones IP y MAC, y DHCP para asegurar que todos en la red tienen una direccin IP vlida. Realizar tareas de administracin de red sin tener cuentas de usuario para rastrear las actividades de los usuarios (ilegal o no) o sin tener DHCP para automatizar la asignacin de direcciones IP a los nodos de la red o sin tener DNS para facilitar el acceso a direcciones IP sera una tarea muy problemtica. Activar estos pocos servicios de red automatiza tareas de administracin muy complejas y que pueden consumir mucho tiempo, y por tanto facilita las tareas de un administrador de redes. Los protocolos de capa de aplicacin de TCP/IP ms conocidos son aquellos que proporcionan intercambio de la informacin del usuario. Estos protocolos especifican la informacin de control y formato necesaria para muchas de las funciones de comunicacin de Internet ms comunes. Entre los que tratamos a lo largo de este trabajo de investigacin, tenemos los siguientes: DHCP DNS TELNET SSH FTP Y TFTP WWW: HTTP Y HTTPS NFS CIFS E-MAIL: SMTP, POP, IMAP , SASL

Software de la capa de aplicacin Dentro de la capa de Aplicacin, existen dos formas de procesos o programas de software que proporcionan acceso a la red: aplicaciones y servicios. Aplicaciones reconocidas por la red: Las aplicaciones son los programas de software que utiliza la gente para comunicarse a travs de la red. Algunas aplicaciones de usuario final son compatibles con la red, lo cual significa que implementan los protocolos de la capa de aplicacin y pueden comunicarse directamente con las capas inferiores del stack de protocolos. Los clientes de correo electrnico y los exploradores Web son ejemplos de este tipo de aplicaciones.

Servicios de la capa de Aplicacin: Otros programas pueden necesitar la ayuda de los servicios de la capa de Aplicacin para utilizar los recursos de la red, como transferencia de archivos o cola de impresin en red. Aunque son transparentes para el usuario, estos servicios son los programas que se comunican con la red y preparan los datos para la transferencia. Diferentes tipos de datos, ya sea texto, grfico o vdeo, requieren de diversos servicios de red para asegurarse de que estn bien preparados para procesar las funciones de las capas inferiores del modelo OSI. Cada servicio de red o aplicacin utiliza protocolos que definen los estndares y formatos de datos a utilizarse. Sin protocolos, la red de datos no tendra una manera comn de formatear y direccionar los datos. Los protocolos de la capa de aplicacin son utilizados tanto por los dispositivos de origen como de destino durante una sesin de comunicacin. Para que las comunicaciones sean exitosas, deben coincidir los protocolos de capa de aplicacin implementados en el host de origen y destino. Los protocolos establecen reglas consistentes para intercambiar datos entre las aplicaciones y los servicios cargados en los dispositivos participantes. Los protocolos especifican cmo se estructuran los datos dentro de los mensajes y los tipos de mensajes que se envan entre origen y destino. Los protocolos tambin definen los dilogos de mensajes, asegurando que un mensaje enviado encuentre la respuesta esperada y se invoquen los servicios correspondientes cuando se realiza la transferencia de datos.

PROTOCOLO DE CONFIGURACIN DINMICA DE HOST- DHCP

Permite a los dispositivos de una red obtener direcciones IP y dems informacin de un servidor DHCP. Este servicio automatiza la asignacin de direcciones IP, mscaras de subred, gateways y otros parmetros de redes IP. DHCP permite a un host obtener una direccin IP en forma dinmica cuando se conecta a la red. Se realiza el contacto con el servidor de DHCP y se solicita una direccin. El servidor DHCP elige una direccin de un rango configurado de direcciones denominado "pool" y se la asigna ("alquila") al host por un perodo establecido. Sin DHCP, cada direccin IP debe configurarse manualmente en cada dispositivo y, si el dispositivo se mueve a otra subred, se debe configurar otra direccin IP diferente. El DHCP le permite al administrador supervisar y distribuir de forma centralizada las direcciones IP necesarias y, automticamente, asignar y enviar una nueva IP si fuera el caso en el dispositivo es conectado en un lugar diferente de la red.

SISTEMA DE NOMBRES DE DOMINIO - DNS El DNS (Domain Name System), es una base de datos jerrquica y distribuida que almacena informacin sobre los nombres de dominio de redes como Internet. Tambin llamamos DNS al protocolo de comunicacin entre un cliente (resolver) y el servidor DNS. Utiliza direcciones IP, que se compone de 4 octetos (bytes) representados por su equivalente decimal (de 0 a 255) y separados por un punto (.). Las direcciones IP son jerrquicas, ya que cada byte ofrece una informacin ms especfica que el anterior (de izquierda a derecha), al igual que una direccin postal. Servicios proporcionados por DNS La principal tarea del DNS es traducir los nombres de host a sus correspondientes direcciones IP, es decir, es una base de datos distribuida, se ejecuta sobre UDP en servidores UNIX por el puerto 53. DNS es usado por protocolos de la capa de aplicacin (HTTP, FTP, SMTP entre otros). Cuando un usuario teclea una URL, el cliente DNS conecta con el servidor DNS y le enva la URL. ste le responde con la IP correspondiente, la cual es utilizada para establecer la conexin HTTP por TCP final. Adems, proporciona otros servicios: Alias de hosts: Un nombre de host puede ser demasiado largo de recordar (se denomina nombre cannico). Entonces existen alias que simplifican el acceso a dicho host. Si un cliente proporciona un alias, el servidor puede responder con el nombre cannico y la IP. Alias de servidores de correo: De la misma forma, si nosotros enviamos un email a destinatario@hotmail.com, probablemente Hotmail.com no sea el nombre cannico para enviar el email. Distribucin de carga: Un sitio web puede estar replicando en varios servidores (cada uno con su IP). El servidor DNS enva el conjunto IP pero rotndolas a cada peticin, lo que provoca que las peticiones hacia dicha web se repartan entre todos los hosts.

PROTOCOLO TELNET

El software de emulacin de terminal (Telnet) tiene la capacidad de acceder de forma remota a otro computador. Le permite conectarse a un host de Internet y ejecutar comandos. Se considera al cliente de Telnet como una mquina local y al servidor de Telnet, que utiliza un software especial denominado daemon, como un host remoto. El protocolo Telnet se aplica en una conexin TCP para enviar datos en formato ASCII codificados en 8 bits, entre los cuales se encuentran secuencias de verificacin Telnet. Por lo tanto, brinda un sistema de comunicacin orientado bidireccional (semidplex) codificado en 8 bits y fcil de implementar. El protocolo Telnet se basa en tres conceptos bsicos:

el paradigma Terminal virtual de red (NVT); el principio de opciones negociadas; las reglas de negociacin.

ste es un protocolo base, al que se le aplican otros protocolos del conjunto TCP/IP (FTP, SMTP, POP3, etc.). Las especificaciones Telnet no mencionan la autenticacin porque Telnet se encuentra totalmente separado de las aplicaciones que lo utilizan (el protocolo FTP define una secuencia de autenticacin sobre Telnet). Adems, el protocolo Telnet no es un protocolo de transferencia de datos seguro, ya que los datos

que transmite circulan en la red como texto sin codificar (de manera no cifrada). Cuando se utiliza el protocolo Telnet para conectar un host remoto a un equipo que funciona como servidor, a este protocolo se le asigna el puerto 23. Excepto por las opciones asociadas y las reglas de negociacin, las especificaciones del protocolo Telnet son bsicas. La transmisin de datos a travs de Telnet consiste slo en transmitir bytes en el flujo TCP (el protocolo Telnet especifica que los datos deben agruparse de manera predeterminada esto es, si ninguna opcin especifica lo contrario en un bfer antes de enviarse. Especficamente, esto significa que de manera predeterminada los datos se envan lnea por lnea). Cuando se transmite el byte 255, el byte siguiente debe interpretarse como un comando. Por lo tanto, el byte 255 se denomina IAC (Interpretar como comando). Las especificaciones bsicas del protocolo Telnet se encuentran disponibles en la RFC (peticin de comentarios) 854, mientras que las distintas opciones estn descriptas en la RFC 855 hasta la RFC 861. El principio de las opciones negociadas Las especificaciones del protocolo Telnet permiten tener en cuenta el hecho de que ciertos terminales ofrecen servicios adicionales, no definidos en las especificaciones bsicas (pero de acuerdo con las especificaciones), para poder utilizar funciones avanzadas. Estas funcionalidades se reflejan como opciones. Por lo tanto, el protocolo Telnet ofrece un sistema de negociaciones de opciones que permite el uso de funciones avanzadas en forma de opciones, en ambos lados, al iniciar solicitudes para su autorizacin desde el sistema remoto. Las opciones de Telnet afectan por separado cada direccin del canal de datos. Entonces, cada parte puede negociar las opciones, es decir, definir las opciones que:

desea usar (DO); se niega a usar (DON'T); desea que la otra parte utilice (WILL); se niega a que la otra parte utilice (WON'T).

De esta manera, cada parte puede enviar una solicitud para utilizar una opcin. La otra parte debe responder si acepta o no el uso de la opcin. Cuando la solicitud se refiere a la desactivacin de una opcin, el destinatario de la solicitud no debe rechazarla para ser completamente compatible con el modelo NVT. Existen 255 cdigos de opcin. De todas maneras, el protocolo Telnet proporciona un espacio de direccin que permite describir nuevas opciones. La RFC (peticin de comentarios) 855 explica cmo documentar una nueva opcin.

PROTOCOLO SSH Secure Shell, tambin llamado SSH, es un protocolo utilizado para login y ejecucin de procesos remotos. Resumiendo SSH nos permite: Permite a los usuarios registrarse en sistemas de host remotamente a travs de la Shell Ejecutar comandos remotamente. Copiar archivos entre distintos hosts. Ejecutar aplicaciones X11 remotamente. Realizar tneles IP cifrados. Encripta la sesin de registro, no permite que alguien pueda obtener contraseas no encriptadas Reemplaza a mtodos menos seguros como telnet, rsh y rcp

Caractersticas de SSH Tipos de proteccin: El cliente puede verificar que se est conectando a un mismo servidor Informacin de autenticacin encriptada con 128 bits Datos enviados y recibidos encriptados con 128 bits Posibilidad de enviar aplicaciones lanzadas desde el intrprete de comandos (reenvo por X11).

Existen ciertas amenazas: Intercepcin de la comunicacin entre dos sistemas: un tercero en algn lugar de la red entre entidades en comunicacin hace una copia de la

informacin que pasa entre ellas. La parte interceptora puede interceptar y conservar la informacin, o puede modificar la informacin y luego enviarla al recipiente al cual estaba destinada. Personificacin de un determinado host: un sistema interceptor finge ser el receptor a quien est destinado un mensaje. Si funciona la estrategia, el cliente no se da cuenta del engao y contina la comunicacin con el interceptor como si su mensaje hubiese llegado a su destino satisfactoriamente.

Versiones del protocolo SSH Existen dos variedades en la actualidad: SSH v.1: vulnerable a un agujero de seguridad que permite, a un intruso, insertar datos en la corriente de comunicacin. SSH v.2: carece de dicho agujero de seguridad (OpenSSH) Secuencia de eventos de una conexin SSH 1. Handshake encriptado para que el cliente pueda verificar la comunicacin con el servidor correcto 2. Encriptacin de la capa de transporte entre cliente y servidor mediante cdigo simtrico 3. Autenticacin del cliente ante el servidor 4. Interactuacin del cliente con la mquina remota sobre la conexin encriptada

PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS-FTP El protocolo de transferencia de archivos, est diseado para descargar archivos o cargarlos. FTP es una aplicacin cliente/servidor al igual que el correo electrnico y Telnet. Requiere software de servidor que se ejecuta en un host al que se puede acceder a travs del software de cliente. Una sesin FTP se establece de la misma forma que una sesin Telnet. Al igual que lo que ocurre con Telnet, la sesin FTP se mantiene hasta que el cliente la termina o hasta que se produce algn tipo de error de comunicacin. Funcin: El protocolo FTP define la manera en que los datos deben ser transferidos a travs de una red TCP/IP. El objetivo del protocolo FTP es:

Permitir que equipos remotos puedan compartir archivos Permitir la independencia entre los sistemas de archivo del equipo del cliente y del equipo del servidor Permitir una transferencia de datos eficaz

El modelo FTP El protocolo FTP est incluido dentro del modelo cliente-servidor, es decir, un equipo enva rdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor). Durante una conexin FTP, se encuentran abiertos dos canales de transmisin:

Un canal de comandos (canal de control) Un canal de datos Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la administracin de estos dos tipos de informacin: DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexin y de administrar el canal de datos. El DTP del lado del servidor se denomina SERVIDOR DE

DTP y el DTP del lado del cliente se denomina USUARIO DE DTP. PI (Intrprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser controlado mediante los comandos recibidos a travs del canal de control. Esto es diferente en el cliente y el servidor: El SERVIDOR PI es responsable de escuchar los comandos que provienen de un USUARIO PI a travs del canal de control en un puerto de datos, de establecer la conexin para el canal de control, de recibir los comandos FTP del USUARIO PI a travs de ste, de responderles y de ejecutar el SERVIDOR DE DTP. El USUARIO PI es responsable de establecer la conexin con el servidor FTP, de enviar los comandos FTP, de recibir respuestas del SERVIDOR PI y de controlar al USUARIO DE DTP, si fuera necesario. Cuando un cliente FTP se conecta con un servidor FTP, el USUARIO PI inicia la conexin con el servidor de acuerdo con el protocolo Telnet. El cliente enva comandos FTP al servidor, el servidor los interpreta, ejecuta su DTP y despus enva una respuesta estndar. Una vez que se establece la conexin, el servidor PI proporciona el puerto por el cual se enviarn los datos al Cliente DTP. El cliente DTP escucha el puerto especificado para los datos provenientes del servidor.

Es importante tener en cuenta que, debido a que los puertos de control y de datos son canales separados, es posible enviar comandos desde un equipo y recibir datos en otro. Entonces, por ejemplo, es posible transferir datos entre dos servidores FTP mediante el paso indirecto por un cliente para enviar instrucciones de control y la transferencia de informacin entre dos procesos del servidor conectados en el puerto correcto.

PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS TRIVIALES TFTP Trivial Transfer Protocol, proporciona un servicio barato y poco sofisticado de transferencia de ficheros. Al contrario que FTP, el protocolo TFTP no utiliza un servicio fiable de transmisin. No utiliza el protocolo TCP, sino que se basa en el protocolo UDP. TFTP utiliza temporizacin y retransmisin para asegurar que los datos llegan a su destino. La aplicacin en la mquina fuente transmite un fichero en bloques de tamao fijo (512 bytes) y espera por un acuse de recibo para cada bloque antes de enviar el siguiente. Por su parte, la aplicacin en la mquina destino devuelve un acuse de recibo por cada bloque que llega.

PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO HTTP Hypertext Transfer Protocol, es un sencillo protocolo cliente-servidor que articula los intercambios de informacin entre los clientes Web y los servidores HTTP. La especificacin completa del protocolo HTTP 1/1 est recogida en el RFC 2616. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribucin de informacin como el World Wide Web. Caractersticas Est soportado sobre los servicios de conexin TCP/IP: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexin de los clientes Web. Una vez que se establece la conexin, el protocolo TCP se encarga de mantener la comunicacin y garantizar un intercambio de datos libre de errores.

 HTTP se basa en: solicitud/respuesta. Un cliente establece una conexin con un servidor y enva un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operacin y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actan; cada objeto Web es conocido por su URL. Multipurpose Internet Mail Extensions (MIME) Extensiones multipropsito de correo de internet Los recursos u objetos que actan como entrada o salida de un comando HTTP estn clasificados por su descripcin MIME. De esta forma, el protocolo puede intercambiar cualquier tipo de dato, sin preocuparse de su contenido. La transferencia se realiza en modo binario, byte a byte, y la identificacin MIME permitir que el receptor trate adecuadamente los datos. Toda la comunicacin entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato original. Principales caractersticas Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado est identificado por su clasificacin MIME.

Existen bsicos

tres que

un

verbos cliente

puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar informacin al servidor y HEAD, para solicitar las caractersticas de un objeto (por ejemplo, la fecha de modificacin de un documento HTML). Cada operacin HTTP implica una conexin con el servidor, que es liberada al trmino de la misma. Es decir, en una operacin se puede recoger un nico objeto. En la actualidad se ha mejorado este procedimiento, permitiendo que una misma conexin se mantenga activa durante un cierto periodo de tiempo, de forma que sea utilizada en sucesivas transacciones. No mantiene estado. Cada peticin de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada peticin como una operacin totalmente independiente del resto. Cada objeto al que se aplican los verbos del protocolo est identificado a travs de la informacin de situacin del final de la URL.

Cmo funciona? Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los siguientes pasos: 1.- Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introducindola directamente en el campo Direccin del cliente Web. 2.- El cliente Web descodifica la URL, separando sus diferentes partes. As identifica el protocolo de acceso, la direccin DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor. 3.- Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP correspondiente. 4.- Se realiza la peticin. Para ello, se enva el comando necesario (GET, POST, HEAD,), la direccin del objeto requerido (el contenido de la URL que sigue a la direccin del servidor). 5.- El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de dato MIME de la informacin de retorno, seguido de la propia informacin.

6.-Se cierra la conexin TCP. Si no se utiliza el modo HTTP Keep Alive, este proceso se repite para cada acceso al servidor HTTP. Tipos de mensaje

Ante cada transaccin con un servidor HTTP, ste devuelve un cdigo numrico que informa sobre el resultado de la operacin, como primera lnea del mensaje de respuesta. Estos cdigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error. Los cdigos de estados 1xx: mensajes informativos. 2xx: mensajes asociados con operaciones realizadas correctamente. 3xx: mensajes de redireccin, que informan de operaciones complementarias que se deben realizar para finalizar la operacin. 4xx: errores del cliente; el requerimiento contiene algn error, o no puede ser realizado. 5xx: errores del servidor, que no ha podido llevar a cabo una solicitud.

PROTOCOLO SEGURO DE TRANSFERENCIA DE HIPERTEXTO (HTTPS)

Hypertext Transfer Protocol Secure, es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versin segura de HTTP. Es ms utilizado por entidades bancarias, tiendas en lnea, y cualquier tipo de servicio que requiera el envo de datos personales o contraseas, como pueden ser transacciones bancarias, comercio electrnico, en el que el usuario para completar una compra o alguna transaccin necesita brindar sus datos. La idea principal de https es la de crear un canal seguro sobre una red insegura. Proporcionando una proteccin contra ataques eavesdropping y man-in-the-middle, siempre que se empleen mtodos de cifrado adecuados y que el certificado del servidor sea verificado y resulte de confianza. La confianza inherente en HTTPS est basada en una Autoridad de certificacin superior que viene preinstalada en el software del navegador.

Caractersticas Tcnicas HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) ms apropiado para el trfico de informacin sensible que el protocolo HTTP. De este modo se consigue que la informacin sensible (usuario y claves de paso normalmente) no pueda ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexin, ya que lo nico que obtendr ser un flujo de datos cifrados que le resultar imposible de descifrar. El puerto estndar para este protocolo es el 443.

Diferencias con HTTP En el protocolo HTTP las URLs comienzan con http:// y en el seguro es https:// HTTP utilizan por defecto el puerto 80, las URLs de HTTPS utilizan el puerto 443 por defecto. HTTP es inseguro y est sujeto a ataques man-in-the-middle y eavesdropping que pueden permitir al atacante obtener acceso a cuentas de un sitio web e informacin confidencial.

HTTPS est diseado para resistir esos ataques y ser seguro.

PROTOCOLO DE SISTEMA DE ARCHIVOS EN RED NFS Network File System Protocol, es un protocolo de servicio de archivo, que permite a un computador exportar sus sistemas de archivos a otros clientes, para lo cual este debe tener cargado el software NFS servidor. Esta exportacin significa que ste est disponible para clientes en diversas plataformas de sistemas operativos, con la nica condicin de que ellos estn ejecutando el software NFS cliente. La figura muestra el servidor NFS exportando el directorio /users. A este directorio pueden acceder simultneamente clientes que operan en sistemas operativos diversos. El NFS permite crear archivos virtuales. Cada cliente NFC observa el sistema de archivos exportados al ambiente del sistema de archivos nativo del cliente. Por ejemplo, un cliente NFS del tipo PC DOS accede al sistema de archivos exportado mediante un controlador de red y un cliente NFS UNIX ver este sistema como si estuviera enlazado a su sistema de archivo local.

SISTEMA DE ARCHIVOS COMUNES DE INTERNET-CIFS

Common Internet File System, es un protocolo de red que se usa principalmente para compartir archivos en una LAN. El protocolo le permite al cliente manipular archivos de la misma manera que lo hara si estuviera en la computadora local. Las operaciones ms comunes son soportadas (leer, escribir, crear, borrar, renombrar, etc.), con la nica diferencia que los archivos se encuentran en una PC remota. CIFS trabaja enviando paquetes desde el cliente al servidor. Cada paquete es tpicamente un request de algn tipo (abrir un archivo, cerrarlo, etc.). El servidor recibe el paquete, verifica que el pedido sea legal y que el cliente tenga los permisos necesarios, y finalmente le devuelve al cliente un paquete con una respuesta adecuada. El cliente examina el paquete y determina si se pudo llevar a cabo la accin o no. CIFS es un protocolo de red de alto nivel, por lo que debe apoyarse en otros protocolos de transporte. El protocolo ms usado para este fin es NetBIOS over TCP (NBT), aunque tambin se pueden utilizar otros. Aunque compartir archivos es el objetivo primario de CIFS, hay otras funciones que tambin puede realizar. Generalmente, es posible determinar si hay otros servidores CIFS en la red, utilizar impresoras remotas y emplear tcnicas de autenticacin sofisticadas. CIFS se usa habitualmente con Windows, que incluye las funciones de cliente y servidor. Se podra decir que el ncleo de las funciones de red nativas de Windows est hecho basado en CIFS. CIFS en detalle CIFS es un protocolo de red que permite compartir archivos entre nodos de una red. Est basado en la arquitectura cliente-servidor, en la que el cliente enva paquetes request al servidor y ste responde con paquetes response. Cada paquete contiene un header standard y dos campos de longitud variable con informacin especfica del paquete. Cada paquete contiene adems un campo Command que indica el propsito que intenta cumplir (login, abrir un archivo, leer un archivo, cerrarlo, etc.) Propiedades del protocolo Cliente-Servidor y Request-Response: como mencionamos antes, CIFS est basado en el modelo cliente-servidor. El protocolo es capaz de tener mltiples request pendientes de forma simultnea. Esto se logra a travs del Multiplex ID (MID). Hay un MID por cada request enviado por el cliente. Cuando el servidor responde, el paquete response contiene el MID del request al que est contestando. De

esta forma, mltiples request pueden ser enviados al servidor y el cliente solamente tiene que comparar los MID de los responses con los MID de los requests enviados. Basado en comandos: cada paquete CIFS contiene un campo Command de 1 byte. En la actualidad hay ms de 100 comandos disponibles. Las respuestas al cliente siempre tienen el mismo cdigo de comando que el request. Negociacin del dialecto del protocolo: hay muchas revisiones del protocolo CIFS desde su primera aparicin en 1980. Cada versin del protocolo se conoce como dialecto y se le asigna un string nico para identificarlo. Cuando un cliente desea acceder a un archivo en un servidor remoto, el primer paquete CIFS enviado es de negociacin de protocolo. En este paquete, el cliente enva una lista de todos los dialectos que es capaz de entender. En el paquete response, el servidor le indica con qu dialecto se realizar la comunicacin o que no entiende ninguno de los dialectos enviados por el cliente. Seguridad: un share es un servidor (tpicamente una carpeta de archivos o una impresora) que est marcada como disponible para compartir para los clientes CIFS. El acceso restringido a un share se logra de dos maneras: User level security: indica que el cliente que desea acceder a un share debe proveer un nombre de usuario y una contrasea. Esto le da al administrador un control preciso sobre quin accedi a un determinado share. Este tipo de seguridad es empleado en Windows NT y 2000. Share level security: indica que el propio share requiere una contrasea para acceder, pero no es necesario un nombre de usuario. Esto implica que no se establece la identidad del usuario que accede al recurso. Por ejemplo, se establece la contrasea xxx para usar una impresora. Cualquier usuario que conozca la contrasea xxx puede imprimir, pero no se tiene control acerca de quin exactamente utiliz el recurso. Esto impide adems estableces derechos particulares para cada usuario. Este tipo de seguridad es empleada en Windows 95 y 98. Encriptacin: para cualquiera de las formas de seguridad descriptas arriba, el password es enviado encriptado al servidor. Hay dos mtodos de encriptacin que se utilizan habitualmente: el NT style y el Lan Manager style. Ambos mtodos usan autenticacin challengeresponse, en la que el servidor enva al cliente un string y espera una respuesta que pruebe que el cliente conoce el string aleatorio y el password de usuario. Command batching: muchos de los paquetes CIFS soportan piggyback de otros paquetes, lo que permite reducir la latencia de respuesta y un uso ms eficiente del ancho de banda. A esta tcnica se la conoce como ANDX batching.

Oplock: cuando un paquete CIFS pide abrir un archivo, se puede solicitar un opportunistic lock (oplock). Si es permitido por el servidor, el oplock avisa al cliente si no hay otros clientes accediendo al archivo. En este caso, el cliente puede hacer todos los cambios que desee al archivo sin tener que escribirlos en el servidor inmediatamente. Hay varios tipos de oplocks. Header de los paquetes Cada paquete request y response de CIFS usa un header como el siguiente:

Header: el comienzo de cada paquete CIFS contiene un header de 4 bytes. El primer byte es 0xFF, seguido por la representacin ASCII de las letras S, M y B. Command: contiene un cdigo de 1 byte indicando el tipo de paquete CIFS. Ejemplos de cdigos pueden ser: SMB_COM_READ_ANDX:0x2E, SMB_COM_NEGOTIATE: 0x72 SMB_COM_TREE_CONNECT:0x70,

Error class: el servidor indica si un request ha sido o no exitoso mediante el campo error class. Cuando no hay error, el campo vale cero. Valores distintos de cero indican error, los que pueden ser: ERRDOS (0x01): error del ncleo del sistema operativo ERRSRV (0x02): error generado por el administrador de archivos del servidor ERRHRD (0x03): error de hardware ERRCMD (0xFF): error en el comando enviado Error code: este campo de 16 bits indica el tipo de error que ha ocurrido. Cuando no hay errores vale cero. Cuando el valor es distinto de cero, este cdigo, en conjunto con

el Error class, puede utilizarse para obtener una descripcin completa del error, por ejemplo, Bad password o File does not exist. Como en el caso del campo Error class, este campo es modificado solamente por el servidor en respuesta a un comando enviado por el cliente. Flags: la mayora de los 8 bits en el campo Flags especifican opciones particulares. El ms importante es el bit 3, que cuando vale 0 indica que todas las rutas en este paquete son case sensitive, mientras que cuando vale 1, indica que son caseless. Flags2: especifica ms opciones. Los bits que son tiles son: Bit 0: si vale 1, indica que el servidor debe devolver nombre largos de archivos en la respuesta. Bit 6: si vale 1, indica que todas las rutas en el request son nombres largos. Bit 16: si vale 1, indica que los strings en el paquete estn en Unicode. Pad/Security signature: este campo generalmente se llena con ceros. Tree ID (TID): el TID es un nmero de 16 bits que indica a qu recurso se est refiriendo el paquete. Cuando los paquetes que se intercambian no hacen referencia a ningn recurso, este nmero no tiene significado y es ignorado. Si el cliente desea tener acceso a un recurso, enva un paquete CIFS con el campo Command con el valor SMB_TREE_CONNECT_ANDX. Se debe especificar tambin el nombre del share o de la impresora (por ejemplo, \\SERVER\DIR). El servidor verifica que el recurso exista y que el cliente tenga permisos de acceso, y luego enva un response indicando que la operacin fue exitosa. En el paquete de respuesta, el servidor establecer el TID a un nmero cualquiera, y a partir de ese momento, si el cliente desea hacer requests especficos para ese recurso, lo har con un paquete con el TID conteniendo el valor que le fue pasado en un principio. Process ID (PID): este campo de 16 bits identifica el proceso del cliente que est realizando el request. El servidor utiliza este nmero para verificar distintas cuestiones de concurrencia. User ID (UID): este campo de 16 bits indica el usuario que est haciendo el request. El cliente debe obtener el UID desde el servidor enviando un Session setup request conteniendo nombre de usuario y contrasea. Luego de verificar estos datos, el servidor responde con el UID correspondiente, que es vlido solamente para la sesin actual. El cliente usar este UID para todos los request posteriores. Si alguno de estos requests requiere permisos para acceder a un recurso, el servidor controlar que el

UID posea los permisos necesarios para realizar la operacin. Si un servidor est operando en modo Share level security, el campo UID es ignorado. Multiplex ID (MID): este campo de 16 bits permite la existencia de mltiples request pendientes de respuesta de manera simultnea. Cada vez que un cliente enva un paquete, primero chequea si hay algn request que todava no ha sido respondido y, en ese caso, le asigna al nuevo request un MID diferente al anterior. Cada vez que el servidor responde, el paquete response debe poseer un MID idntico al paquete request que lo origin. De esta forma, el cliente sabe a que request corresponde el response que est recibiendo. WordCount y Parameter Words: los paquetes CIFS usan estos dos campos para poner datos especficos de los comandos. Los headers CIFS como los de la figura no pueden contener todos los posibles datos de todos los posibles paquetes CIFS. Para remediar esta situacin, se cre el campo Parameter Words con longitud variable. El WordCount especifica cuntas palabras de 16 bits contiene el campo Parameter Words. De esta forma, cada paquete CIFS se puede ajustar al tamao necesario para transportar los datos requeridos por el comando. El WordCount es generalmente constante para cada tipo de paquete y est definido en el borrador de CIFS 1.0. Hay dos WordCounts definidos para cada comando, uno para el request del cliente y otro para el response del servidor. Ambos son necesarios ya que la cantidad de datos requeridos para hacer el request no necesariamente es la misma que para hacer el response. ByteCount y Buffer: estos dos campos son similares a los que acabamos de describir, ya que tambin contienen una cantidad variable de datos. El campo ByteCount especifica cuntos bytes contiene el campo Buffer. La principal diferencia con los anteriores es el tipo de datos que contienen, porque mientras el campo Parameter Words generalmente contiene unas pocas opciones de paquete, el campo Buffer es llenado con grandes cantidades de raw data (por ejemplo, el contenido de un archivo).

Servicios de e-mail y protocolos SMTP/POP E-mail, el servidor de red ms conocido, ha revolucionado la manera en que nos comunicamos, por su simpleza y velocidad. Inclusive para ejecutarse en una computadora o en otro dispositivo, los e-mails requieren de diversos servicios y aplicaciones. Dos ejemplos de protocolos de capa de aplicacin son Protocolo de oficina de correos (POP) y Protocolo simple de transferencia de correo (SMTP), que

aparecen en la figura. Como con HTTP, estos protocolos definen procesos clienteservidor. Cuando una persona escribe mensajes de correo electrnico, generalmente utiliza una aplicacin denominada Agente de usuario de correo (MUA) o cliente de correo electrnico. MUA permite enviar los mensajes y colocar los mensajes recibidos en el buzn del cliente; ambos procesos son diferentes. Para recibir e-mails desde un servidor de e-mail, el cliente de correo electrnico puede utilizar un POP. Al enviar un e-mail desde un cliente o un servidor, se utilizan formatos de mensajes y cadenas de comando definidas por el protocolo SMTP. En general, un cliente de correo electrnico proporciona la funcionalidad de ambos protocolos dentro de una aplicacin.

Procesos del servidor de e-mail: MTA y MDA El servidor de e-mail ejecuta dos procesos individuales: Agente de transferencia de correo (MTA, Mail Transfer Agent). Agente de entrega de correo (MDA, Mail Delivery Agent). El proceso Agente de transferencia de correo (MTA) se utiliza para enviar correos electrnicos. Como se muestra en la figura, el MTA recibe mensajes desde el MUA u otro MTA en otro servidor de e-mail. Segn el encabezado del mensaje, determina cmo debe reenviarse un mensaje para llegar a destino. Si el correo est dirigido a un usuario cuyo buzn est en el servidor local, el correo se pasa al MDA. Si el correo es para un usuario que no est en el servidor local, el MTA enruta el e-mail al MTA en el servidor correspondiente.

En la figura, vemos que el Agente de envo de correo (MDA) acepta una parte del email desde un Agente de transferencia de correo (MTA) y realiza el envo real. El MDA recibe todo el correo entrante desde el MTA y lo coloca en los buzones de los usuarios correspondientes. El MDA tambin puede resolver temas de entrega final, como anlisis de virus, correo no deseado filtrado y manejo de acuses de recibo. La mayora de las comunicaciones de e-mail utilizan las aplicaciones MUA, MTA y MDA. Sin embargo, existen otras alternativas para enviar e-mails. El cliente puede estar conectado a un sistema de e-mails corporativo, como Lotus Notes de IBM, Groupwise de Novell o Microsoft Exchange. Estos sistemas a veces tienen su propio formato interno de correo electrnico y sus clientes generalmente se comunican con el servidor de correo electrnico a travs de un protocolo propietario. El servidor enva o recibe correos electrnicos por Internet a travs de la gateway de correo de internet del producto, que realiza el reformateo que sea necesario. Si, por ejemplo, dos personas que trabajan para la misma empresa intercambian e-mails entre ellos utilizando un protocolo propietario, los mensajes pueden permanecer completamente dentro del sistema de e-mails corporativo de la empresa. Como segunda alternativa, las computadoras que no tienen un MUA pueden conectarse a un servicio de correo en un explorador Web para as recuperar y enviar mensajes. Algunas computadoras pueden ejecutar su propio MTA y administrar emails de dominio interno.

Como se mencion anteriormente, los e-mails pueden utilizar los protocolos POP y SMTP, POP y POP3 (Protocolo de oficina de correos v.3) son protocolos de envo de correo entrante y protocolos cliente/servidor tpicos. Envan e-mails desde el servidor de e-mail al cliente (MUA). El MDA escucha cuando un cliente se conecta a un servidor. Una vez establecida la conexin, el servidor puede enviar el e-mail al cliente. El protocolo simple de transferencia de correo (SMTP), por el contrario, rige la transferencia de e-mails salientes desde el cliente emisor al servidor de e-mail (MDA), como as tambin el transporte de e-mails entre servidores de e-mail (MTA). SMTP permite transportar e-mails por las redes de datos entre diferentes tipos de software de cliente y servidor, y hace posible el intercambio de e-mails en Internet. El formato de mensajes del protocolo SMTP utiliza un conjunto rgido de comandos y respuestas. Estos comandos admiten los procedimientos utilizados en el SMTP, como inicio de sesin, transaccin de correo, reenvo de correo, verificacin de nombres de buzones, expansin de listas de correo y apertura y cierre de intercambios. Algunos de los comandos especificados en el protocolo SMTP son: HELO: identifica el proceso de cliente SMTP para el proceso de servidor SMTP. EHLO: es la versin ms nueva de HELO, que incluye extensiones de servicios, y MAIL FROM: identifica al emisor. RCPT TO: identifica al receptor, y

 DATA: identifica el cuerpo del mensaje.

PROTOCOLO DE TRANFERENCIA SIMPLE DE CORREO-SMTP El protocolo de transferencia de correo simple (Simple Mail Transfer ProtocolSMTP) administra la transferencia de mensajes del sistema de correo de un computador hacia otro sistema de correo remoto. Acepta correo local y para ello se tiene a los sistemas locales. Como interacta con el sistema local de correo y no con el usuario, el SMTP est encubierto para cualquier transferencia de correo local en esa mquina. La figura ilustra la interrelacin entre SMTP y correo local.

esquema de sistema correo local

SMTP, transfiere mensajes entre servidores de correo y es mucho ms antiguo que el HTTP. Aunque tiene numerosas cualidades, tambin posee algunas restricciones que actualmente no tienen razn de ser, como la limitacin de ASCII de 7 bits para el cuerpo del mensaje (actualmente, en la era

multimedia, los datos binarios deben ser codificados a ASCII y posteriormente decodificados por el destinatario). El correo electrnico est compuesto por tres mayores componentes: agente usuario, servidor de correo, SMTP.

Agente Usuario Tambin conocido como lector de correo Escritura, edicin, lectura de mensajes de correos Mensajes de salida, entrada son almacenados en servidor

Funciones y componentes del SMTP Normalmente hay una cola de entrada y una cola de salida en la interface entre el sistema de correo local a menudo referido como sistema de correo nativo y las partes de cliente-servidor del SMTP. Sus funciones son las siguientes: El cliente opera con el inicio de la transferencia del correo hacia otro sistema. El servidor est relacionado con el correo que se recibe del exterior.

El sistema de correo local asigna a cada usuario una casilla, en la que pueda depositar o recuperar su correo. Cada casilla tiene un nombre nico que consta de dos partes: una local y una global. Parte local: Es el nombre del usuario y es nico slo dentro del sistema de correo local.

Parte global: Es la identidad del computador que debe ser nica dentro de la Internet total.

Esta parte tiene varios campos y su formato vara para los diferentes tipos de instituciones, tales como de educacin, gobierno, militares, comerciales, etc. En la transferencia del correo electrnico es necesario contemplar lo siguiente: El formato del mail: Para asegurar que ste sea interpretado de la misma manera por todos los sistemas involucrados. Este formato tiene una cabecera y un cuerpo. El protocolo SMTP: Usado para transferir el correo de una mquina a otra.

Cada lnea en la cabecera comprende una palabra clave (keyword), luego dos puntos (:) y a continuacin una cadena de texto. Algunas palabras claves son obligatorias y otras son opcionales. El encabezamiento mnimo es: TO : nombre del destinatario

FROM : nombre del remitente Otros incluyen: TO : nombre del destinatario

FROM : nombre del remitente CC : copias para SUBJECT : asunto a tratar DATE : fecha ENCRYTED : puntero de encriptacin El encabezamiento incluyendo el asunto y los nombres de los destinatarios. Estn siempre en texto simple. Aunque en algunas circunstancias las dos mquinas comunicantes pueden estar conectadas en la misma red si routers va Internet estn involucrados en la ruta, se colocan lneas adicionales de la forma siguiente: RECEIVED FROM : Identificacin del router que envi el correo. El cual puede ser aadido en la cabecera por cada router. Esto proporciona un medio de determinar la ruta tomada por el correo a travs de la Internet.

Despus que un mensaje de correo ha sido creado en su formato normalizado, el sistema de correo local determina el nombre del destinatario, si ste debe depositarse dentro de una casilla local o si debe ir a la cola de salida listo, para ser transmitido al exterior. Para enviar un correo, el cliente SMTP primero obtiene la direccin IP del computador de destino del servicio de directorio conocido como el sistema de DNS (Domain Name System) y lo usa conjuntamente con el nmero de la puerta del SMTP (port 25), para establecer la conexin TCP con el servidor SMTP del computador de destino. Una vez que la conexin ha sido establecida, el cliente inicia la transferencia del correo hacia el servidor. Comandos del SMTP La transferencia de correo consiste en el intercambio de unidades de datos de protocolo SMTP referidas como comandos. Estos comandos, codificados en cadenas de caracteres ASCII, incluyen: Un nmero de tres dgitos. Un comando textual. Ambos valores.

Estos comandos se transfieren a la conexin TCP establecida empleando las primitivas SEND/DELIVER. En la figura se presenta el intercambio de comandos.

Una vez que una conexin TCP ha sido establecida, el servidor SMTP retorna el comando 220 de regreso al cliente para indicar que est listo para recibir el correo. El cliente responde enviando un comando HELLO junto con la identidad de la mquina cliente. El servidor, al recibir este comando, responde con la identidad de la mquina servidora usada y un registro de la transaccin del correo. Luego el cliente enva el encabezado del correo al emitir el comando MAIL seguido por FROM: la lnea de la cabecera del MAIL. El servidor responde con el comando de confirmacin 250. Luego el cliente enva el comando RCPT seguido por el - TO: la lnea del encabezado del MAIL, el cual es confirmado por el comando 250. Luego de haber establecido comunicacin, es necesario enviar el contenido del mensaje, o sea iniciar la fase de transferencia. Para ello, el cliente enva el comando DATA sealando el inicio del cuerpo del correo. El servidor contesta con el comando 354 y el cliente remite entonces el contenido del mail como una secuencia de lneas. Para indicar el fin del contenido enva una lnea con un solo punto. El servidor confirma la recepcin remitiendo el comando 250. El cliente termina la fase de transferencia enviando un comando QUIT, al cual el servidor responde con el comando 221, lo cual produce la liberacin de la conexin TCP. Respecto a los mensajes, si se quiere enviar mensajes no textuales como archivos binarios, audio e imgenespuede codificarse el mensaje como un mensaje de texto mediante la utilidad UUENCODE, disponible en muchos sistemas. El receptor del mensaje decodificar el mensaje codificado con un utilitario llamado UUENCODE. Otra forma de enviar mensajes es usando el protocolo MIME (Multipurpose Internet Mail Extensions), descrito en las normas RFC 1896, 2046 y 2049. El MIME sirve para codificar distintos tipos de contenido, tales como texto simple, texto en formato enriquecido (Rich Text Format), imagen, audio, video y documentos HTML. Los contenidos de los mensajes MIME pueden tener un contenido de varias secciones (nested) y los agentes de usuario (clientes de correo) pueden elegir entre representaciones alternativas del mensaje. Hay funciones adicionales en algunas implementaciones propietarias. Por ejemplo, si el destinatario ya no tiene casilla en el servidor, ste puede usar una direccin para redireccionar el mensaje. Tambin luego que un cliente envi su correo, puede invitar al servidor para enviar correo en direccin opuesta, si hubiera correo esperando, antes de liberar la conexin de transporte. Hasta aqu se ha asumido que todas las computadoras destinatarias utilizan el protocolo SMTP. En la prctica, muchos otros protocolos de correo se usan en las redes. Para que un correo pueda interactuar con otros sistemas de correo debe usarse un servidor de correo. Un ejemplo es el gateway TCP/IP a OSI. Como su nombre

implica, ste acta como un punto de transferencia de correo entre dos sistemas de redes de correo dismiles. As, el correo recibido con SMTP de una puerta de red se enva con MOTIS, que es el protocolo de correo de ISO a la otra puerta de red. Los pasos realizados para enviar un correo de A a B seran los siguientes: 1. El mensaje se enva desde el agente de usuario de A a la cola de mensajes del servidor de correo de A. 2. El servidor ve el mensaje y establece una conexin TCP con un servidor SMTP que est ejecutndose en el servidor de correo de B. 3. Tras una sincronizacin SMTP inicial, el mensaje se enva al servidor de correo B sobre dicha conexin TCP. El mensaje se deposita en el buzn de correo de B. 4. El servidor de B enva el mensaje al agente de usuario de B cuando ste se lo solicite. No se suelen utilizar servidores intermedios, aunque la distancia entre ambos sea grande. El puerto utilizado para el SMTP es el puerto 25. SMTP utiliza conexiones persistentes; es decir, pueden enviarse varios mensajes consecutivos sobre la misma conexin TCP. Se podra enviar un correo electrnico a un servidor SMTP directamente (sin agente de usuario) a travs de Telnet.

PROTOCOLO DE OFICINA DE CORREO-POP El protocolo de oficina de correo, POP, es un protocolo cuya misin es la de entrega final del correo al destinatario. Puesto que con SMTP lo nico que se consigue es la transferencia del correo entre buzones, es necesario un protocolo como POP (o tambin IMAP) con el que podamos descargar el mensaje desde el buzn. Modelo de comunicaciones POP Como se acaba de comentar el modelo de comunicaciones POP se basa en mantener un buzn (estafeta) central en la que se almacenan los mensajes hasta que el usuario solicita la descarga de los mismos. El cliente POP se conecta con el servidor a travs del puerto TCP, 110. Para conectarse al servidor, es necesario una cuenta de identificacin en dicha mquina (lo que le permite tener un espacio reservado para sus correos). A continuacin es necesario verificar que es dueo de la cuenta a travs de una clave. Una vez conectado al sistema, el cliente POP puede dialogar con el servidor para saber, en otros, si existen

mensajes en la casilla, cuntos mensajes son o para solicitar la descarga de alguno de ellos. Para poder ofrecer estas funciones, el modelo de comunicacin POP se basa en estados: Autorizacin. Transaccin. Actualizacin. Despus de establecer la conexin, el servidor POP se encuentra en un estado de autorizacin, esperando que el cliente le enve el nombre y clave de la cuenta de usuario. Cuando se verifica que el nombre y la clave son correctos, el servidor pasa a un estado de transaccin. Antes de pasar a este estado, el servidor POP bloquea el buzn para impedir que los usuarios modifiquen o borren el correo antes de pasar al estado siguiente. En este estado de transaccin el servidor atiende las peticiones del cliente. Despus de enviar al servidor el comando QUIT, el servidor pasa al estado de actualizacin (estado siguiente). En este estado el servidor elimina los mensajes que estn con la marca de borrado y finaliza la conexin. En contraste, el protocolo IMAP permite los modos de operacin conectado y desconectado. El SMTP espera que el computador de destino es decir, el servidor de correo que va a recibir el correo est en lnea, de otra manera la conexin TCP no se podr establecer. Por esta razn no es prctico establecer una sesin SMTP con una computadora de sobremesa para recibir correo, porque las estaciones de trabajo se apagan al final del da. En diversos ambientes de red, el correo SMTP es recibido por un computador SMTP que siempre est activo, segn se muestra en la figura. Este computador provee un servicio donde las estaciones de trabajo interactan y recuperan sus mensajes usando un protocolo cliente-servidor tal como POP3, descrito en la RFC 1939. El POP3 usa el protocolo de transporte TCP y el servidor POP3 recibe los mensajes en su bien conocida puerta TCP nmero 110 (well-known port). Aunque POP3 se usa para recibir mensajes desde el servidor, el SMTP todava se usa para enviar mensajes desde la estacin de trabajo del usuario a su servidor de correo SMTP.

Comandos del POP3 Los comandos POP3 son los siguientes: Comandos requeridos

Respuestas del servidor

Comandos opcionales

El Agente de Transferencia de Mensajes (Message Transfer Agent MTA) se ejecuta en una computadora que tiene mayores recursos que la estacin de trabajo. Ofrece servicio de correo a nodos ms pequeos, tales como estaciones de trabajo. El POP proporciona acceso dinmico al servidor de correo. Aunque los comandos USER y PASS, se listan como comandos opcionales en la RFC 1939, la mayor parte de las implementaciones POP3 los soportan. La razn por la cual se consideren como opcionales reside en que pueden ser reemplazados por el mtodo de autenticacin MD5 (Message Digest version 5) usado en el comando APOP.

PROTOCOLO DE ACCESO A MENSAJES INTERNET-IMAP

Es un protocolo ms complejo y con ms funcionalidades de POP. Un servidor IMAP asigna cada mensaje a un buzn. Inicialmente se almacena en el buzn INBOX, pero puede ser movido seguidamente a un buzn creado por el usuario, leer el mensaje, borrarlo. IMAP proporciona comandos para realizar estas operaciones y tambin para buscar en los buzones remotos mensajes que cumplan con ciertos criterios. IMAP mantiene informacin de estado de los usuarios entre sesiones IMAP (ej: nombres de buzones y qu mensajes se asocian). Adems, pueden recuperarse componentes de mensajes nicamente, por ejemplo, las cabeceras o una parte de un MIME multiparte (extensiones Multipurpose Internet Mail Extensions), que puede ser til, por ejemplo, con conexiones lentas entre el agente de usuario y el servidor de correo) IMAP es un protocolo de red de acceso a mensajes electrnicos almacenados en un servidor. Mediante IMAP se puede tener acceso al correo electrnico desde cualquier equipo que tenga una conexin con el servidor que almacena los correos. IMAP tiene varias ventajas sobre POP3, que es el otro protocolo empleado para obtener los correos almacenados en un servidor. Por ejemplo, es posible especificar en IMAP carpetas del lado servidor. Por otro lado, es ms complejo que POP3. IMAP fue diseado como una moderna alternativa a POP3 por Mark Crispin en el ao 1986. Fundamentalmente, los dos protocolos les permiten a los clientes de correo, acceder a los mensajes almacenados en un servidor de correo.

Bien sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes utilizan SMTP para enviar mensajes. Los clientes de correo electrnico son comnmente denominados clientes POP3 o IMAP, pero en ambos casos se utiliza SMTP. IMAP es utilizado frecuentemente en redes grandes; por ejemplo los sistemas de correo de un campus. IMAP les permite a los usuarios acceder a los nuevos mensajes instantneamente en sus computadoras, ya que el correo est almacenado en la red. Con POP3 los usuarios tendran que descargar el correo a sus computadoras o accederlo va Web. Ambos mtodos toman ms tiempo de lo que le tomara a IMAP, y se tiene que descargar el correo nuevo o refrescar la pgina para ver los nuevos mensajes. De manera contraria a otros protocolos de Internet, IMAP4 soporta mecanismos nativos de cifrado. La transmisin de contraseas en texto plano tambin es soportada. Ventajas sobre POP3 Algunas de las caractersticas importantes que diferencian a IMAP y POP3 son: Soporte para los modos de operacin conectado y desconectado. Al utilizar POP3, los clientes se conectan al servidor de correo brevemente, solamente lo que les tome descargar los nuevos mensajes. Al emplear IMAP, los clientes permanecen conectados el tiempo que su interfaz permanezca activa y descargan los mensajes bajo demanda. Esta forma de trabajar de IMAP puede dar tiempos de respuesta ms rpidos para usuarios que tienen una gran cantidad de mensajes o mensajes grandes. Soporte para la conexin de mltiples clientes simultneos a un mismo buzn. El protocolo POP3 asume que el cliente conectado es el nico dueo de una cuenta de correo. En contraste, el protocolo IMAP4 permite accesos simultneos a mltiples clientes y proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a un buzn por otro cliente concurrentemente conectado. Soporte para acceso a las partes MIME de los mensajes y obtencin parcial de las mismas. Casi todo el correo electrnico de Internet es transmitido en formato MIME. El protocolo IMAP4 le permite a los clientes obtener separadamente cualquier parte MIME individual, as como obtener porciones de las partes individuales o los mensajes completos. Soporte para que la informacin del estado del mensaje se mantenga en el servidor.

A travs de la utilizacin de indicadores definidos en el protocolo IMAP4 los clientes pueden vigilar el estado del mensaje, por ejemplo, si el mensaje ha sido o no ledo, respondido o eliminado. Estos indicadores se almacenan en el servidor, de manera que varios clientes conectados al mismo buzn en diferente tiempo pueden detectar los cambios hechos por otros clientes. Soporte para accesos mltiples a los buzones de correo en el servidor. Los clientes de IMAP4 pueden crear, renombrar o eliminar los buzones (por lo general presentado como carpetas al usuario) en el servidor y mover mensajes entre buzones. El soporte para mltiples buzones de correo tambin le permite al servidor proporcionar acceso a directorios pblicos y compartidos. Soporte para bsquedas del lado del servidor. IMAP4 proporciona un mecanismo para que los clientes pidan al servidor que busque mensajes de acuerdo a una cierta variedad de criterios. Este mecanismo evita que los clientes descarguen todos los mensajes de su buzn de correo con el fin de agilizar las bsquedas. Soporte para un mecanismo de extensin definido. Como reflejo de la experiencia en versiones anteriores de los protocolos de Internet, IMAP4 define un mecanismo explcito mediante el cual puede ser extendido. Se han propuesto muchas extensiones de IMAP4 y son de uso comn. Un ejemplo de extensin es el IMAP IDLE, que sirve para que el servidor avise al cliente cuando ha llegado un nuevo mensaje de correo y stos se sincronicen. Sin esta extensin, para realizar la misma tarea, el cliente debera contactar peridicamente al servidor para ver si hay mensajes nuevos.

SASL SASL es un framework para autenticacin y autorizacin en protocolos de Internet. Separa los mecanismos de autenticacin de los protocolos de la aplicacin permitiendo, en teora, a cualquier protocolo de aplicacin que use SASL usar cualquier mecanismo de autenticacin soportado por SASL. A pesar de que mediante SASL slo se maneja la autenticacin (y se requieren otros mecanismos --como por ejemplo TLS-- para cifrar el contenido que se transfiere), SASL proporciona medios para un uso negociado del mecanismo elegido. Las especificaciones originales de SASL fueron editadas por John Meyers en el RFC 2222. Este fue hecho obsoleto por el RFC 4422, editado por Alexey Melnikov y Kurt Zeilenga. Un mecanismo SASL se modela como una sucesin de retos y respuestas. Los mecanismos definidos por SASL incluyen:

"EXTERNAL", aqu la autenticacin est implcita en el contexto (p.ej. para protocolos que ya usan IPsec o TLS). "ANONYMOUS", para el acceso de invitados sin autentificar. "PLAIN", un mecanismo de contrasea simple en texto plano. "OTP" para el sistema que evolucion de S/KEY y que est definido en RFC 2289. "NTLM". Se prev soportar los mecanismos GSSAPI en una familia de nomenclatura de mecanismos. Los protocolos definen su representacin de intercambios SASL con un perfil. Un protocolo tiene un nombre de servicio como "LDAP" en un registro compartido con GSSAPI y Kerberos. Entre los protocolos que ahora mismo usan SASL se incluyen IMAP, LDAP, POP3, SMTP y XMPP.