PROTOCOLOS DE RED

Operatividad Protocolo FTP

Este protocolo comienza abriendo una nica conexin llamada sesin "FTP control" (sesin de control ftp). En cuanto enviamos comandos a travs de esta sesin, se abren otros puertos para transportar el resto de datos relacionados con esos comandos. Estas conexiones se pueden crear de dos maneras: activamente o pasivamente. Cuando una conexin se genera activamente, el cliente FTP enva al servidor un puerto y una direccin IP a los que conectarse. Tras sto el cliente FTP abre el puerto indicado y el servidor conecta con l desde su propio puerto 20 (conocido como "FTP-Data"), enviando datos a travs de l. El problema radica en que el cortafuegos no tiene conocimiento de esas conexiones extras, ya que son negociadas a travs del bloque de datos que transporta el paquete (lo que se conoce como "payload" o carga de informacin; recordemos que a grosso modo un paquete IP tiene una cabecera con informacin sobre la conexin y un bloque de datos que es lo que desea el host que lo recibe). Debido a sto el cortafuegos no ser capaz de saber que debera dejar conectarse al servidor con el cliente a travs de estos puertos concretos. La solucin al problema pasa por aadir un asistente especial al mdulo del seguimiento de conexiones, que escanear los datos de la conexin de control para detectar sintaxis e informacin especficas: cuando encuentre la informacin adecuada, la aadir en una nueva entrada etiquetada como relacionada (RELATED) y gracias a esta nueva entrada el servidor ya ser capaz de efectuar un seguimiento de la conexin..

El ftp pasivo ("Passive FTP") funciona completamente a la inversa: el cliente FTP le indica al servidor que quiere determinados datos, a lo que el servidor responde con una direccin IP y un puerto a los que conectarse. Tras recibir estos datos, el cliente se

conectar a ese puerto desde su propio puerto 20 (el puerto FTP-data) y coger los datos en cuestin. Si tienes un servidor FTP tras tu cortafuegos, necesitars de este mdulo adems de los mdulos estndar de iptables para permitir que los clientes desde Internet puedan conectar correctamente con tu servidor FTP. De igual forma necesitars el mdulo si eres extremadamente restrictivo con tus usuarios y slo quieres dejar que utilicen servidores HTTP y FTP de Internet, bloqueando cualquier otro puerto.

Operatividad del

protocolo HTTP

El propsito del protocolo HTTP es permitir la transferencia de archivos (principalmente, en formato HTML). Entre un navegador (el cliente) y un servidor web (denominado, entre otros, http en equipos UNIX) localizado mediante una cadena de caracteres denominada direccin URL. Comunicacin entre el navegador y el servidor La comunicacin entre el navegador y el servidor se lleva a cabo en dos etapas:

El navegador realiza una solicitud HTTP El servidor procesa la solicitud y despus enva una respuesta HTTP

En realidad, la comunicacin se realiza en ms etapas si se considera el procesamiento de la solicitud en el servidor. Una solicitud HTTP es un conjunto de lneas que el navegador enva al servidor. Por ejemplo:

Una lnea de solicitud: es una lnea que especifica el tipo de documento solicitado, el mtodo que se aplicar y la versin del protocolo utilizada. La lnea est formada por tres elementos que deben estar separados por un espacio: o el mtodo o la direccin URL o la versin del protocolo utilizada por el cliente (por lo general, HTTP/1.0) Los campos del encabezado de solicitud: es un conjunto de lneas opcionales que permiten aportar informacin adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas lneas est formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.

El cuerpo de la solicitud: es un conjunto de lneas opcionales que deben estar separadas de las lneas precedentes por una lnea en blanco y, por ejemplo, permiten que se enven datos por un comando POST durante la transmisin de datos al servidor utilizando un formulario.

Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de lnea): MTODO VERSIN URL<crlf> ENCABEZADO: Valor<crlf> . . . ENCABEZADO: Valor<crlf> Lnea en blanco <crlf> CUERPO DE LA SOLICITUD Un ejemplo de una solicitud HTTP: GET http://es.kioskea.net HTTP/1.0 Accept: Text/html If-Modified-Since : Saturday, 15January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)

Comandos
Comando GET HEAD POST PUT DELETE Descripcin Solicita el recurso ubicado en la URL especificada Solicita el encabezado del recurso ubicado en la URL especificada Enva datos al programa ubicado en la URL especificada Enva datos a la URL especificada Borra el recurso ubicado en la URL especificada

Encabezados
Nombre del encabezado Accept Descripcin

Tipo de contenido aceptado por el navegador (por ejemplo, texto/html). Accept-Charset Juego de caracteres que el navegador espera Accept-Encoding Codificacin de datos que el navegador acepta Idioma que el navegador espera (de forma predeterminada, Accept-Language ingls) Authorization Identificacin del navegador en el servidor Content-Encoding Tipo de codificacin para el cuerpo de la solicitud Content-Language Tipo de idioma en el cuerpo de la solicitud Content-Length Extensin del cuerpo de la solicitud

Content-Type Date Forwarded From From Link Orig-URL Referer User-Agent

Tipo de contenido del cuerpo de la solicitud (por ejemplo, texto/html). Fecha en que comienza la transferencia de datos Utilizado por equipos intermediarios entre el navegador y el servidor Permite especificar la direccin de correo electrnico del cliente Permite especificar que debe enviarse el documento si ha sido modificado desde una fecha en particular Vnculo entre dos direcciones URL Direccin URL donde se origin la solicitud Direccin URL desde la cual se realiz la solicitud Cadena con informacin sobre el cliente, por ejemplo, el nombre y la versin del navegador y el sistema operativo

Una respuesta HTTP es un conjunto de lneas que el servidor enva al navegador. Est constituida por:

Una lnea de estado: es una lnea que especifica la versin del protocolo utilizada y el estado de la solicitud en proceso mediante un texto explicativo y un cdigo. La lnea est compuesta por tres elementos que deben estar separados por un espacio: La lnea est formada por tres elementos que deben estar separados por un espacio: o la versin del protocolo utilizada o el cdigo de estado o el significado del cdigo Los campos del encabezado de respuesta: es un conjunto de lneas opcionales que permiten aportar informacin adicional sobre la respuesta y/o el servidor. Cada una de estas lneas est compuesta por un nombre que califica el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado Cada una de estas lneas est formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado. El cuerpo de la respuesta: contiene el documento solicitado.

Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de lnea): VERSIN-HTTP CDIGO EXPLICACIN <crlf> ENCABEZADO: Valor<crlf> . . . ENCABEZADO: Valor<crlf> Lnea en blanco <crlf> CUERPO DE LA RESPUESTA A continuacin se encuentra un ejemplo de una respuesta HTTP:

HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT

Encabezados de respuesta
Nombre del encabezado Content-Encoding Content-Language Content-Length Content-Type Date Expires Forwarded Location Server Descripcin Tipo de codificacin para el cuerpo de la respuesta Tipo de idioma en el cuerpo de la respuesta Extensin del cuerpo de la respuesta Tipo de contenido del cuerpo de la respuesta (por ejemplo, texto/html). Fecha en que comienza la transferencia de datos Fecha lmite de uso de los datos Utilizado por equipos intermediarios entre el navegador y el servidor Redireccionamiento a una nueva direccin URL asociada con el documento Caractersticas del servidor que envi la respuesta

Los cdigos de respuesta Son los cdigos que se ven cuando el navegador no puede mostrar la pgina solicitada. El cdigo de respuesta est formado por tres dgitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error. Cdigo 10x 20x 200 201 202 203 204 Mensaje Mensaje de informacin xito OK CREATED ACCEPTED PARTIAL INFORMATION NO RESPONSE Descripcin Estos cdigos no se utilizan en la versin 1.0 del protocolo Estos cdigos indican la correcta ejecucin de la transaccin La solicitud se llev a cabo de manera correcta Sigue a un comando POST e indica el xito, la parte restante del cuerpo indica la direccin URL donde se ubicar el documento creado recientemente. La solicitud ha sido aceptada, pero el procedimiento que sigue no se ha llevado a cabo Cuando se recibe este cdigo en respuesta a un comando de GET indica que la respuesta no est completa. El servidor ha recibido la solicitud, pero no hay

205 206 30x 301 302

303

304

40x 400

401

402 403 404 50x 500 501

informacin de respuesta El servidor le indica al navegador que borre el RESET CONTENT contenido en los campos de un formulario Es una respuesta a una solicitud que consiste en el PARTIAL encabezado range. El servidor debe indicar el CONTENT encabezado content-Range Estos cdigos indican que el recurso ya no se Redireccin encuentra en la ubicacin especificada Los datos solicitados han sido transferidos a una MOVED nueva direccin Los datos solicitados se encuentran en una nueva FOUND direccin URL, pero, no obstante, pueden haber sido trasladados Significa que el cliente debe intentarlo con una nueva METHOD direccin; es preferible que intente con otro mtodo en vez de GET Si el cliente llev a cabo un comando GET condicional (con la solicitud relativa a si el NOT MODIFIED documento ha sido modificado desde la ltima vez) y el documento no ha sido modificado, este cdigo se enva como respuesta. Error debido al Estos cdigos indican que la solicitud es incorrecta cliente La sintaxis de la solicitud se encuentra formulada de BAD REQUEST manera errnea o es imposible de responder Los parmetros del mensaje aportan las especificaciones de formularios de autorizacin que se UNAUTHORIZED admiten. El cliente debe reformular la solicitud con los datos de autorizacin correctos PAYMENT El cliente debe reformular la solicitud con los datos de REQUIRED pago correctos FORBIDDEN El acceso al recurso simplemente se deniega Un clsico. El servidor no hall nada en la direccin NOT FOUND especificada. Se ha abandonado sin dejar una direccin para redireccionar... :) Error debido al Estos cdigos indican que existe un error interno servidor en el servidor El servidor encontr una condicin inesperada que le INTERNAL ERROR impide seguir con la solicitud (una de esas cosas que les suceden a los servidores...) NOT El servidor no admite el servicio solicitado (no puede IMPLEMENTED saberlo todo...)

502

BAD GATEWAY

503

SERVICE UNAVAILABLE

504

GATEWAY TIMEOUT

El servidor que acta como una puerta de enlace o proxy ha recibido una respuesta no vlida del servidor al que intenta acceder El servidor no puede responder en ese momento debido a que se encuentra congestionado (todas las lneas de comunicacin se encuentran congestionadas, intntelo de nuevo ms adelante) La respuesta del servidor ha llevado demasiado tiempo en relacin al tiempo de espera que la puerta de enlace poda admitir (excedi el tiempo asignado...)

Operatividad Protocolo de SNMP

SNMP surge para resolver los problemas de administracin de redes TCP/IP, debido a que el crecimiento apresurado y desmesurado de este tipo de redes ha hecho que la administracin y gestin de las mismas se convierta en una labor intensa. Con el objeto de solucionar este tipo de problemas, a finales de los aos 80, La Internet Architecture Board (IAB), encargada de establecer las polticas de Internet, decide definir un marco de administracin de red y fijar un conjunto de protocolos estndar que permitan agilizar estos procesos. Por las razones antes expuestas, un grupo de trabajo de Internet crea el Protocolo Bsico de Administracin de Red (SNMP- Simple Network Management Protocol), el cual permitira cubrir las necesidades inmediatas de TCP/IP. La arquitectura de este protocolo se dise tomando en cuenta el modelo OSI. SNMP est formado por cuatro componentes bsicos: 1. Base de datos lgica: SNMP sigue el modelo de una base de datos lgica, en la misma se almacena informacin referente a la configuracin, estado, error y rendimiento. 2. Agentes: El agente es un software, que permite el acceso a la informacin. Dicho agente responde a peticiones, realiza actualizaciones e informa los problemas. 3. Administradores: La estacin de administracin, contiene un software de administrador, el cual se encarga de enviar y recibir los mensajes SNMP. 4. Base de informacin de administracin: La base de informacin de administracin, denominada MIB, constituye la descripcin lgica de todos los datos de administracin de la red. La MIB contiene informacin de estado y del sistema, estadsticas de rendimiento y parmetros de configuracin.

En lo que se refiere a la arquitectura de SNMP se dice que es de tipo modular, y que est basada en las siguientes especificaciones: 1. 2. 3. 4. Utiliza un lenguaje de definicin de datos Definicin de administracin de informacin (MIB) Definicin protocolar Seguridad y Administracin.

Al pasar del tiempo, SNMP ha evolucionado a travs de sus diferentes versiones (SNMPv1, SNMPv2 y SNMPv3) y las definiciones de cada una de stas, en cuanto a sus componentes arquitectnicos lo ha hecho ms rico y claramente definido, sin embargo el principio de la arquitectura ha permanecido consistente.

ESTRUCTURA DE LA INFORMACION DE DIRECCION. La informacin de direccin es una coleccin de objetos manejados por un administrador. La Base de informacin de administracin (MIB) es la descripcin lgica de todos los datos de administracin de la red. Existen muchos documentos RFC que describen las variables de MIB, cada documento describe un mdulo, que es un sub-conjunto de variables relacionadas. El marco de definicin de variables de administracin de red debe incluir: a. Una Estructura Administrativa. b. Se usa para describir y llevar un seguimiento del reparto del trabajo y la delegacin de la autoridad. c. Una Estructura de Informacin. Debido a que la informacin no es esttica, esta debe estar estructurada de forma tal que sea fcil extender y revisar antiguas tecnologas y a su vez aadir nuevas tecnologas. a. Una Estructura de Nombres. Se basa en el uso de un mtodo consistente en la definicin de nombres de las diferentes variables a ser utilizadas. Una estructura de rbol cumple con los tres requisitos antes mencionados y recibe el nombre de Estructura de Informacin de Administracin (SMI). El SMI est dividido en tres partes: a. Definiciones de modulo. Utilizadas para describir los mdulos de informacin. Se usa para llevar consistentemente la semntica de un mdulo de informacin. b. Definiciones de Objeto. Se utilizan para describir los objetos manejados y para llevar consistentemente la semntica de un objeto.

c. Definiciones de Notificacin. Se usan al describir transmisiones de informacin de direccin y para llevar consistentemente la sintaxis de una notificacin. 2. OPERACIN DE PROTOCOLOS. El protocolo de direccin mantiene el intercambio de mensajes que lleva la informacin de direccin entre los agentes y la direccin de estaciones. La forma de estos mensajes es en forma de paquete, el cual encapsula una Unidad de Datos Protocolar (PDU). Las especificaciones de los servicios protocolares de SNMPv3, estn incorporados en RFC 1905 [1], tambin se define el funcionamiento del protocolo con respecto al recibimiento y envo de PDUs. TRANSPORTE. Pueden usarse mensajes de SNMP con una gran variedad de colecciones protocolares, dentro de las cuales se pueden nombrar IPX y UDP. Aunque se definen varas categoras se seleccion UDP como el transporte preferido, ya que es simple y se puede implementar con poco cdigo. Adems de esto es la opcin ms fiable en caso de que el dispositivo est daado o sobrecargado. ARQUITECTURA, SEGURIDAD Y ADMINISTRACION. La arquitectura de SNMPv3, se basa principalmente en el mejoramiento de la seguridad y de la administracin, por este hecho est enfocado en los siguientes puntos: a. Los Instrumentos y Aplicaciones. b. Las entidades (Proveedores de servicio como los instrumentos en agentes y gerentes). c. Las Identidades (usuarios de Servicio) d. La informacin de direccin, incluyendo apoyo para mltiple contextos lgicos. 5. MENSAJES QUE PROCESA Y DESPACHA (MPD) Los administradores y los agentes se comunican entre s envindose mensajes de SNMP. Algunos de estos mensajes son los siguientes: a. b. c. d. e. f. Get-Request. Solicita uno o ms valores de una MIB del sistema administrado. Get-Next-Request. Permite al administrador obtener los valores secuencialmente. Set- Request. Permite al administrador actualizar las variables. Response. Devuelve el resultado de una operacin de Get, get-Next o Set. Trap. Permite a un agente avisar de eventos importantes. Get-Bulk. Solicita a un agente que devuelva tanta informacin de la solicitada como pueda g. Inform. Confirmacin de excepciones.

En RFC 2572 se describe el proceso de los mensajes y despacho de los mismos [4]. APLICACIONES DE SNMP. SNMP posee cinco tipos de aplicaciones, las cuales pueden asociarse con cada uno de sus instrumentos. Dichas aplicaciones son las siguientes: a. b. c. d. e. f. Generadores de Orden Generador de Respuestas Creadores de la Notificacin Receptores de la notificacin Proxy Forwarders (Expedidores).

COEXISTENCIA Y TRANSICION DE SNMPv3. SNMPv3 permite la transicin y coexistencia de los diferentes documentos MIB generados en la versin 1 (SNMPv1) y la versin 2 (SNMPv2). Por otra parte, tambin permite la coexistencia de las entidades que soportan las diferentes versiones de SNMP en una red multi-lenguaje y adems el procesamiento de operaciones protocolares en los mltiples lenguajes implementados. En el modelo de procesamiento de mensajes de SNMPv1 y el Modelo de Seguridad de esta misma versin, existen mecanismos para adaptar estas versiones y las de SNMPv2 al Modelo de Control de Acceso de Vista (VACM- View Based Access Control Model) El VACM puede simultneamente asociarse con un solo instrumento de implementacin, el cual puede procesar mltiples mensajes y mltiples modelos de seguridad. SERVICIOS DE SEGURIDAD DE SNMPv3 1. TIPOS DE SERVICIOS DE SEGURIDAD. Los servicios de seguridad que ofrece el modelo de SNMPv3 son los siguientes: a. Integridad de la Data. b. Su objetivo es prevenir la alteracin y/o destruccin de los datos por entes no autorizados. c. Autenticacin del origen de los datos. d. Permite comprobar el origen de los datos exigiendo la identidad del usuario. Corrobora que los datos estarn en el lugar donde se origin la peticin. e. Confidencialidad de los datos. f. Permite garantizar que los datos no sern accesados por usuarios no autorizados, entidades o procesos desconocidos. g. Mdulo de Tiempo (Timeliness) y proteccin de repeticin limitada.

Permite proteger un mensaje de un determinado retraso e impide la repeticin del mismo. 2. ORGANIZACIN DEL MDULO DE SEGURIDAD. Los protocolos de seguridad estn divididos en tres mdulos diferentes y cada uno tiene sus responsabilidades especficas: a. Mdulo de Autenticacin. b. Est encargado de la Integridad y de la Autenticacin del origen de los datos. Cuando se efecta el proceso de autenticacin el mensaje completo es chequeado para garantizar su integridad en el modulo de autenticacin. c. Mdulo de Tiempo (Timeliness). d. Ofrece proteccin contra el retraso o repeticin del mensaje. El chequeo de tiempo solo se realiza si se ha concluido el proceso de autenticacin. e. Mdulo de Reserva. Ofrece proteccin contra el descubrimiento de los datos, garantizando la confidencialidad de los mismos. En este caso se necesita tambin que el mensaje sea autenticado.

Operatividad protocolo POP3

El protocolo POP (Protocolo de oficina de correos), como su nombre lo indica, permite recoger el correo electrnico en un servidor remoto (servidor POP). Es necesario para las personas que no estn permanentemente conectadas a Internet, ya que as pueden consultar sus correos electrnicos recibidos sin que ellos estn conectados. Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan los puertos 109 y 110 respectivamente, y que funcionan utilizando comandos de texto radicalmente diferentes. Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con comandos de texto enviados al servidor POP. Cada uno de estos comandos enviados por el cliente (validados por la cadena CR/LF) est compuesto por una palabra clave, posiblemente acompaada por uno o varios argumentos, y est seguido por una respuesta del servidor POP compuesta por un nmero y un mensaje descriptivo.

Comandos POP2 Comando Descripcin HELLO Identificacin que utiliza la direccin IP del equipo remitente

FOLDER READ

Nombre de la bandeja de entrada que se va a consultar Nmero del mensaje que se va a leer

RETRIEVE Nmero del mensaje que se va a recoger SAVE DELETE QUIT Nmero del mensaje que se va a guardar Nmero del mensaje que se va a eliminar Salida del servidor POP2

A continuacin se brinda un resumen de los principales comandos POP3:

Comandos POP3 Comando Descripcin

Este comando permite la autenticacin. Debe estar USER seguido del nombre de usuario, es decir, una cadena de identification caracteres que identifique al usuario en el servidor. El comando USER debe preceder al comando PASS. PASS password STAT RETR DELE LIST [msg] NOOP El comando PASS permite especificar la contrasea del usuario cuyo nombre ha sido especificado por un comando USER previo. Informacin acerca de los mensajes del servidor Nmero del mensaje que se va a recoger Nmero del mensaje que se va a eliminar Nmero del mensaje que se va a mostrar Permite mantener la conexin abierta en caso de inactividad

TOP Comando que muestra n lneas del mensaje, cuyo nmero <messageID> se da en el argumento. En el caso de una respuesta

<n>

positiva del servidor, ste enviar de vuelta los encabezados del mensaje, despus una lnea en blanco y finalmente las primeras n lneas del mensaje. Solicitud al servidor para que enve una lnea que contenga informacin sobre el mensaje que eventualmente se dar en el argumento. Esta lnea contiene una cadena de caracteres denominada unique identifier listing (lista de identificadores nicos) que permite identificar de manera nica el mensaje en el servidor, independientemente de la sesin. El argumento opcional es un nmero relacionado con un mensaje existente en el servidor POP, es decir, un mensaje que no se ha borrado. El comando QUIT solicita la salida del servidor POP3. Lleva a la eliminacin de todos los mensajes marcados como eliminados y enva el estado de esta accin.

UIDL [msg]

QUIT

Operatividad Protocolo Telnet

El protocolo Telnet es un protocolo de Internet estndar que permite conectar terminales y aplicaciones en Internet. El protocolo proporciona reglas bsicas que permiten vincular a un cliente (sistema compuesto de una pantalla y un teclado) con un intrprete de comandos (del lado del servidor). 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 especfica 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). Los comandos se describen ms adelante en este documento. Modos de operacin Para utilizar telnet, es muy importante tener en cuenta que el cliente telnet dispone de dos formas de operacin: modo Comando y modo de uso normal. El modo comando permite utilizar una serie de rdenes que afectan al modo de operacin, incluyendo conectar y desconectar. Entre estos comandos estn: CLOSE Cierra la conexin Telnet con el ordenador remoto y vuelve al modo comando (si se inici en modo comando) o cierra la aplicacin saliendo de Telnet. QUIT Cierra la sesin Telnet. Si se est conectado a un equipo remoto, este comando cierra la conexin y a continuacin cierra la aplicacin Telnet. SET ECHO Si no podemos ver lo que estamos tecleando, o por el contrario, lo vemos doble, este comando arregla la situacin. OPEN Este comando establece una conexin con un ordenador remoto. En modo normal nuestro equipo se comporta como si fuese un teclado (modificado y remoto) del ordenador al que estamos conectados. Cada pulsacin de tecla es enviada al equipo remoto, y lo que vemos en la pantalla es realmente el eco que, en respuesta a esa seal, nos enva el equipo remoto. Cuando se est en modo normal y se desea pasar a modo comando (por ejemplo para terminar la sesin mediante QUIT), hay que enviar el carcter de escape. Esto se consigue generalmente pulsando simultneamente la tecla Ctrl y el carcter [ (Ctrl + [), lo que interrumpe momentneamente la sesin Telnet y nos coloca en modo comando. A su vez, si estamos en modo comando y pulsamos la tecla CR o Enter, salimos de l y volvemos a modo normal. Telnet slo sirve para acceder en modo terminal, es decir, sin grficos, pero fue una herramienta muy til para arreglar fallos a distancia, sin necesidad de estar fsicamente en

el mismo sitio que la mquina que los tena. Tambin se usaba para consultar datos a distancia, como datos personales en mquinas accesibles por Red, informacin bibliogrfica, etc. Aparte de estos usos, en general telnet se ha utilizado (y an hoy se puede utilizar en su variante SSH) para abrir una Sesin con una mquina UNIX, de modo que mltiples usuarios con cuenta en la mquina, se conectan, abren sesin y pueden trabajar utilizando esa mquina. Es una forma muy usual de trabajar con sistemas UNIX.

Operatividad Protocolo SSH

SSH permite a los usuarios registrarse en sistemas de host remotamente. A diferencia de rlogin o telnet. SSH encripta la sesin de registro imposibilitando que alguien pueda obtener una contrasea de texto. SSH est diseado para reemplazar los mtodos comunes para registrarse remotamente en otro sistema a travs de la shell de comando. El programa scp reemplaza otros programas diseados para copiar ficheros entre hosts como por ejemplo ftp o rcp. Ya que estas aplicaciones antiguas no encriptan contraseas entre el cliente y el servidor, las evita siempre que sea posible. El uso de mtodos seguros para registrarse remotamente a otros sistemas har disminuir los riesgos de seguridad para ambos sistemas y el sistema remoto. SSH (o Secure SHell) es un protocolo para crear conexiones seguras entre dos sistemas. Usando SSH, la mquina del cliente inicia una conexin con una mquina del servidor. SSH proporciona los siguientes tipos de proteccin: Despus de la conexin inicial, el cliente puede verificar que se est conectando al mismo servidor durante sesiones ulteriores. El cliente puede transmitir su informacin de autenticacin al servidor, como el nombre de usuario y la contrasea, en formato cifrado. Todos los datos enviados y recibidos durante la conexin se transfieren por medio de encriptacin fuerte, lo cual los hacen extremamente difcil de descifrar y leer. El cliente tiene la posibilidad de usar X11 [1] aplicaciones lanzadas desde el intrprete de comandos de la shell. Esta tcnica proporciona una interfaz grfica segura (llamada reenvo por X11), proporciona un medio seguro para usar aplicaciones grficas sobre una red.

Ya que el protocolo SSH encripta todo lo que enva y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede converrirse en un conducto para convertir en seguros los protocolos inseguros mediante el uso de una tcnica llamada reenvo por puerto, como por ejemplo POP, incrementando la seguridad del sistema en general y de la seguridad de los datos. Porqu usar SSH? Entre las amenazas al trfico de red estn incluidos el husmeo de paquete y la falsificacin de DNS e IP y la promulgacin de informacin de ruteo falso. En trminos generales, estas amenazas se pueden catalogar del siguiente modo: Intercepcin de la comunicacin entre dos sistemas bajo esta hiptesis, existe un tercero en algn lugar de la red entre entidades en comunicacin que 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 con esta estrategia, un sistema interceptor finge ser el recipiente 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. Ambas tcnicas causan que se intercepte informacin, posiblemente con propsitos hostiles. El resultado puede ser catastrfico, ya sea que ese propsito se alcance por medio de escuchar todos los paquetes en un LAN o por un servidor DNS sometido a un hack que apunta hacia un host duplicado intencionalmente. Si se utiliza SSH para inicios de sesin de shell remota y para copiar ficheros, estas amenazas a la seguridad se pueden disminuir notablemente. La firma digital de un servidor proporciona la verificacin para su identidad. No es posible utilizar la comunicacin entera entre los sistemas si ha sido interceptada, porque cada uno de los paquetes est cifrado. No servirn de nada los intentos de falsificar la identidad de cualquiera de los dos lados de la comunicacin ya que cada paquete est cifrado por medio de una clave conocida slo por el sistema local y el remoto. Secuencia de eventos de una conexin SSH Una cierta serie de eventos ayuda a proteger la integridad de una comunicacin SSH entre dos hosts. Primero, se crea una capa de transporte segura para que el cliente sepa que est efectivamente comunicando con el servidor correcto. Luego se cifra la comunicacin entre el cliente y el servidor por medio de un cdigo simtrico.

Despus, con la conexin segura al servidor en su lugar, el cliente se autentica ante el servidor sin preocuparse de que la informacin de autenticacin pudiese exponerse a peligro. Por ltimo, con el cliente autenticado ante el servidor, se pueden usar varios servicios diferentes con seguridad a travs de la conexin, como una sesin shell interactiva, aplicaciones X11 y tneles TCP/IP. Capas de seguridad SSH El protocolo SSH permite que cualquier programa de cliente y servidor construido segn los planes detallados del protocolo comuniquen con seguridad y se usen de manera intercambiable. Actualmente existen dos variedades diferentes de SSH. La versin 1 de SSH contiene varios algoritmos de encriptacin patentados (sin embargo varios de estas patentes han caducado) y un agujero de seguridad que potencialmente permitira que datos se inserten en el flujo de datos. Se recomienda el uso de servidores y clientes compatibles con la versin 2 de SSH, si es posible. Las versiones de protocolo SSH 1 y 2 aaden capas de seguridad, cada una aade su propio tipo de proteccin. Capa de transporte El papel principal de la capa de transporte es el de facilitar una comunicacin segura entre dos hosts a la hora de y despus de la autenticacin. Normalmente ejecutado a travs de TCP/IP, la capa de transporte logra hacer esto ocupndose de la encriptacin y descifrado de datos, verificando que el servidor sea la mquina correcta para la autenticacin, y proporcionando proteccin a la integridad de los paquetes de datos al momento de ser enviados y recibidos. Adems, la capa de transporte tambin puede proveer la compresin de los datos, acelerando as la transmisin de la informacin. Al contactar un cliente a un servidor por medio del protocolo SSH, se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Durante el intercambio se producen los siguientes pasos: Intercambio de claves El algoritmo de la clave pblica que hay que usar El algoritmo de la encriptacin simtrica que hay que usar El algoritmo de la autenticacin de mensajes que hay que usar El algoritmo de hash que hay que usar

El servidor se identifica ante el cliente con una clave de host durante el intercambio de claves. Obviamente si este cliente nunca haba comunicado antes con este determinado servidor, la clave del servidor le resultar desconocida al cliente. OpenSSH evita este problema permitiendo que el cliente acepte la clave de host del servidor la primera vez que se lleva a cabo una conexin SSH. Luego la clave de host del servidor se puede verificar con la versin guardada en el cliente en las siguientes conexiones, proporcionando la confianza que el cliente est realmente comunicando con el servidor deseado. Autenticacin Cuando la capa de transporte haya construido un tnel seguro para transmitir informacin entre los dos sistemas, el servidor le dir al cliente de los diferentes mtodos de autenticacin soportados, como el uso de firmas privadas codificadas con claves o la insercin de una contrasea. El cliente entonces intentar autenticarse ante el servidor mediante el uso de cualquiera de los mtodos soportados. Ya que los servidores se pueden configurar para que concedan varios tipos de autenticacin, este mtodo proporciona a cada parte un control ptimo. Luego el servidor podr decidir qu mtodos de encriptacin soportar basado en su pauta de seguridad, y el cliente puede elegir el orden en que intentar utilizar los mtodos de autenticacin entre las opciones a disposicin. Gracias a la naturaleza segura de la capa de transporte de SSH, hasta mtodos de autenticacin que parecen inseguros, como la autenticacin basada en el host, son en realidad seguros. La mayora de los usuarios que requieren de una shell segura se autenticarn por medio de una contrasea. Ya que la contrasea est encriptada en el proceso de envo, se puede enviar fcilmente a travs de la red. Conexin Despus de una autenticacin exitosa sobre una capa de transporte SSH, se abren canales mltiples por medio de la multiplexin[1] la conexin individual entre dos sistemas. Cada canal se ocupa de la comunicacin para sesiones entre terminales diferentes, el reenvo de informacin por X11 o cualquier servicio aparte que intente usar la conexin SSH. Ya sea los clientes como los servidores pueden crear un canal nuevo, con cada canal asignado un nmero diferente en cada orilla. Cuando una parte intenta abrir un canal nuevo, el nmero para el canal de esa parte se enva junto con la peticin. Esta informacin se almacena por la otra parte y se usa para dirigir un determinado tipo de comunicacin de servicio a ese canal. Esto se lleva a cabo para que diferentes tipos de sesiones no se afecten los unos por los otros y que los canales puedan cerrarse sin interrumpir la conexin SSH principal entre los dos sistemas.

Los canales tambin soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envan a travs del canal sino hasta que el host haya recibido un mensaje avisando que el canal puede recibirlos. Los canales son especialmente tiles con el reenvo por X11 y el reenvo por puerto TCP/IP con SSH. Se pueden configurar canales aparte en modo diferente, tal vez para usar un tamao de paquete mximo diferente o para transferir un determinado tipo de datos. Esto permite que SSH sea flexible en su modo de encargarse de los diferentes tipos de conexiones remotas, como el acceso telefnico en redes pblicas o enlaces LAN de alta velocidad, sin tener que cambiar la infraestructura bsica del protocolo. Requisitos de SSH para conexiones remotas Para que SSH sea realmente eficaz para proteger sus conexiones de red, deber dejar de usar protocolos de conexin inseguros, como por ejemplo telnet y rsh. De otra manera, la contrasea de un usuario podra ser protegida un da si se usa ssh y luego ser capturada al da siguiente cuando inicia una sesin por medio de telnet.

Operatividad Voz sobre IP

Voz sobre Protocolo, tambin llamado Voz IP, VozIP, VoIP (por sus siglas en ingls), es un grupo de recursos que hacen posible que la seal de voz viaje a travs de Internet empleando un protocolo IP (Protocolo de Internet). Esto significa que se enva la seal de voz en forma digital, en paquetes, en lugar de enviarla en forma digital o analgica, a travs de circuitos utilizables slo para telefona como una compaa telefnica convencional o PSTN (sigla de Public Switched Telephone Network, Red Telefnica Pblica Conmutada). Los Protocolos que se usan para enviar las seales de voz sobre la red IP se conocen como protocolos de Voz sobre IP o protocolos IP. Estos pueden verse como aplicaciones comerciales de la "Red experimental de Protocolo de Voz" (1973), inventada por ARPANET.

El trfico de Voz sobre IP puede circular por cualquier red IP, incluyendo aquellas conectadas a Internet, como por ejemplo las redes de rea local (LAN). Es muy importante diferenciar entre Voz sobre IP (VoIP) y Telefona sobre IP. VoIP es el conjunto de normas, dispositivos, protocolos, en definitiva la tecnologa que permite comunicar voz sobre el protocolo IP. Telefona sobre IP es el servicio telefnico disponible al pblico, por tanto con numeracin E.164, realizado con tecnologa de VoIP. Arquitectura de red

El propio Estndar define tres elementos fundamentales en su estructura: Terminales: Son los sustitutos de los actuales telfonos. Se pueden implementar tanto en software como en hardware. Gatekeepers: Son el centro de toda la organizacin VoIP, y seran el sustituto para las actuales centrales. Normalmente implementadas en software, en caso de existir, todas las comunicaciones pasaran por l. Gateways: Se trata del enlace con la red telefnica tradicional, actuando de forma transparente para el usuario. Con estos tres elementos, la estructura de la red VoIP podra ser la conexin de dos delegaciones de una misma empresa. La ventaja es inmediata: todas las comunicaciones entre las delegaciones son completamente gratuitas. Este mismo esquema se podra aplicar para proveedores, con el consiguiente ahorro que esto conlleva. Protocolos de VoIP: Es el lenguaje que utilizarn los distintos dispositivos VoIP para su conexin. Esta parte es importante ya que de ella depender la eficacia y la complejidad de la comunicacin. Por orden de antigedad (de ms antiguo a ms nuevo): H.323 - Protocolo definido por la ITU-T SIP - Protocolo definido por la IETF Megaco (Tambin conocido como H.248) y MGCP - Protocolos de control Skinny Client Control Protocol - Protocolo propiedad de Cisco MiNet - Protocolo propiedad de Mitel CorNet-IP - Protocolo propiedad de Siemens IAX - Protocolo original para la comunicacin entre PBXs Asterisk (Es un estndar para los dems sistemas de comunicaciones de datos, actualmente est en su versin 2 - IAX2) Skype - Protocolo propietario peer-to-peer utilizado en la aplicacin Skype IAX2 - Protocolo para la comunicacin entre PBXs Asterisk en reemplazo de IAX Jingle - Protocolo abierto utilizado en tecnologa Jabber MGCP- Protocolo propietario de Cisco

weSIP [1] - Protocolo licencia gratuita de VozTelecom [2] Cdec La voz ha de codificarse para poder ser transmitida por la red IP. Para ello se hace uso de Cdecs que garanticen la codificacin y compresin del audio o del video para su posterior decodificacin y descompresin antes de poder generar un sonido o imagen utilizable. Segn el Cdec utilizado en la transmisin, se utilizar ms o menos ancho de banda. La cantidad de ancho de banda suele ser directamente proporcional a la calidad de los datos transmitidos.

Entre los codecs utilizados en VoIP encontramos los G.711, G.723.1 y el G.729 (especificados por la ITU-T) Estos Cdec tienen este tamao en su sealizacin: G.711: bit-rate de 56 o 64 Kbps. G.722: bit-rate de 48, 56 o 64 Kbps. G.723: bit-rate de 5,3 o 6,4 Kbps. G.728: bit-rate de 16 Kbps. G.729: bit-rate de 8 o 13 Kbps. Esto no quiere decir que es el ancho de banda utilizado, por ejemplo el Codec G729 utiliza 31.5 Kbps de ancho de banda en su transmisin.

UNIVERSIDAD NUEVA ESPARTA CEDE CENTRO ESCUELA DE COMPUTACION COMPLEMENTARIA I (TCP/IP)

OPERATIVIDAD DE PROTOCOLOS

Alumno: Mijares Miguel ngel