Protocolos y redes. Ing. Patricio Moreno

Ing. M.Sc. Patricio Moreno C.

Integración de Sistemas

ESPOCH-FIE-EIS ESPOCH-FIE-EI S

CAPITULO I PROTOCOLO DE CONFIGURACION DINAMICA DE HOST 1.1 CONFIGURACION DEL ANFITRION El protocolo DHCP DHCP (Dynamic Host Configuration Protocol) permite a un anfitrión determinar su dirección IP sin utilizar RARP. La comunicación entre el cliente y el servidor se hace mediante el protocolo UDP, lo notable esta en que el UDP depende del protocolo IP para transferir mensajes, y parecería imposible que una computadora pueda utilizar el UDP para localizar su dirección IP. Al realizar un análisis del inconvenientes para su uso:

protocolo RARP se determina que existen tres

1. Debido a que RARP opera opera en un nivel bajo, su su uso requiere de un acceso acceso directo hacia el hardware de red. Así pues, puede resultar difícil o imposible para un programador de aplicaciones construir un servidor. 2. Al utilizar RARP RARP se necesita necesita hacer un proceso proceso de solicitud, solicitud, para en la respuesta respuesta solo recibir la dirección IP de 4 octetos. Esto es molesto especialmente en las redes Ethernet que imponen un tamaño de paquete mínimo, debido a que información adicional (dirección de un router, la máscara de red en uso y la dirección de un servidor de nombres) puede enviarse en la respuesta sin costo adicional. 3. Como RARP emplea emplea una dirección dirección de hardware hardware de computadora para identificar una máquina, no puede utilizarse en redes con una asignación dinámica de direcciones de hardware. Para eludir algunas de las dificultades presentadas por RARP, se desarrollo primeramente el BOOTP (BOOTstrap Protocol) y más recientemente el DHCP que es el sucesor del BOOTP, al compararlos son bastante similares. La asignación de direcciones de manera automática, fue solucionado por el IETF mediante el diseño del DHCP que permite que una computadora adquiera toda la información que necesita en un solo mensaje. Por ejemplo, además de una dirección IP, un mensaje DHCP puede tener una máscara de subred. Además permite que una computadora posea una dirección IP en forma rápida y dinámica. Para utilizar el mecanismo de asignación de direcciones dinámico DHCP, el administrador debe configurar un servidor DHCP con un conjunto de direcciones IP específicas para ser utilizadas en el proceso. Cada vez que una computadora nueva se conecta a la red, la computadora contacta al servidor y solicita una dirección. El servidor selecciona una de las direcciones especificadas por el administrador y la asigna a la computadora. DHCP permite tres tipos de asignación de direcciones; un administrador selecciona cómo responderá el DHCP a cada red o a cada anfitrión. El DHCP permite la configuración manual, mediante la cual un administrador puede configurar una dirección específica para una computadora específica. La configuración automática, por medio de la cual el administrador permite a un servidor DHCP asignar una dirección permanente cuando una computadora es conectada por primera vez a la 1




red. Por último, el DHCP admite una configuración dinámica completa, con la cual el servidor "presta" una dirección a una computadora por tiempo limitado. DHCP utiliza la identidad del cliente para decidir cómo proceder. Cuando un cliente contacta un servidor DHCP, envía un identificador, por lo general, la dirección de hardware del cliente. El servidor utiliza el identificador del cliente y la red a la que el cliente se ha conectado para determinar cómo asignar el cliente y la dirección IP. Así, el administrador tiene un control completo sobre la forma en que se asignan las direcciones. Un servidor puede configurarse para asignar direcciones a computadoras específicas de manera estática, mientras permite a otras computadoras obtener dinámicamente direcciones de manera permanente o temporal.

1.2 ASIGNACIÓN DINAMICA DE DIRECCIONES IP La asignación dinámica de direcciones es el más significativo aspecto del DHCP, en la cual el servidor no necesita conocer la identidad de un cliente a priori. En particular, un servidor DHCP puede ser configurado para permitir que una computadora arbitraria obtenga una dirección IP y comience la comunicación. Así, el DHCP permite diseñar sistemas que se autoconfiguren. Luego de que una computadora ha sido conectada a la red, la computadora se vale del DHCP para obtener una dirección IP y entonces configura su software TCP/IP a fin de utilizar la dirección. Por supuesto, la autoconfiguración está sujeta a restricciones administrativas, es el administrador el que decide qué servidor DHCP puede realizar la autoconfiguración. Para hacer posible la autoconfiguración, un servidor DHCP comienza con un conjunto de direcciones IP que el administrador de red asigna al servidor para su manejo. El administrador especifica las reglas bajo las que opera el servidor. Un cliente DHCP negocia el uso de una dirección intercambiando mensajes con un servidor. En el intercambio, el servidor proporciona una dirección para el cliente y el cliente verifica que la dirección sea aceptable. Una vez que el cliente ha aceptado una dirección, puede comenzar a utilizar la dirección para comunicarse. 1 La asignación de direcciones estática, es permanentemente para cada di rección IP a un anfitrión específico, mientras la asignación de direcciones dinámica es temporal. Se dice que un servidor DHCP arrienda una dirección a un cliente por un período de tiempo finito. El servidor es el encargado de especificar el período de arrendamiento cuando asigna la dirección. Durante el período de arrendamiento, el servidor no arrendará la misma dirección a ningún otro cliente. Al final del período de arrendamiento, sin embargo, el cliente debe renovar el arrendamiento o dejar de usar la dirección. El tiempo óptimo de arrendamiento depende en particular de la red y de las necesidades de un anfitrión. Por ejemplo, para garantizar que las direcciones puedan reciclarse con rapidez, las computadoras en una red utilizadas por estudiantes en un laboratorio universitario deben tener un corto período de arrendamiento (por ejemplo, una hora). En contraste, la red de una compañía podría 1

Comer Douglas redes globales de información con internet y TCP/IP, pág 375

2




utilizar un período de arrendamiento de un día o de una semana. Para adaptarse a todos los posibles ambientes, el DHCP no especifica un período de arrendamiento fijo y constante. De hecho, el protocolo permite que un cliente solicite un período de arrendamiento específico y permite a un servidor informar al cliente que el período de arrendamiento está garantizado. Así, un administrador puede decidir durante cuánto tiempo podrá asignar cada servidor una dirección a un cliente. En el caso extremo, el DHCP reserva un valor infinito para permitir un arrendamiento por un período de tiempo indeterminadamente largo.

1.3 PROCESO DE ADQUISICION DE DIRECCIONES Cuando se utiliza el DHCP para obtener una dirección IP, el cliente se encuentra en 1 de 6 estados. La figura 1.1 muestra los estados de transición sus eventos y mensajes que ocasionan que un cliente cambie de estado.

Arranque del anfitrión E R O V C I S P D C D H

SELECCIONAR CIONAR

DHCPOFFER

DHCPREQUEST

SOLICITAR

INICIALIZAR o t n e e i d m a n d i DHCPNACK F n e r r a

UNIR DE NUEVO

DHCPACK

DHCPACK

ENLAZAR

DHCPNACK

o t n DHCPREQUEST RENO e i m 87% de arrendamiento VAR a d n e r r a n ó DHCPACK i c l DHCPREQUEST a e c n a 50% de arrendamiento C

DHCPRELEASE

Figura 1.1 Estados de un cliente DHCP y las transiciones entre entre estados. Cuando un cliente arranca por primera vez lo hace con una dirección IP 0.0.0.0, entra en el estado INITIALIZE (INICIALIZAR). Para comenzar a adquirir una dirección IP, el cliente primero contacta a todos los servidores DHCP en la red local. Para hacerlo, el cliente difunde (utiliza la dirección IP 255.255.255.255) un mensaje cambia al estado con el nombre SELECT(SELECCIONAR). El DHCPDISCOVER y cambia cliente envía el mensaje DHCPDISCOVER en en un datagrama UDP con el puerto de destino activado para el puerto el puerto 67. Todos los servidores DHCP de la red 3



ESPOCH-FIE-EIS

local reciben el mensaje y los servidores que hayan sido programados para responder a un cliente enviarán un mensaje DHCPOFFER emitido por broadcast al puerto 68 de UDP, cliente DHCP . Así, un cliente puede recibir ceros o más respuestas. Mientras permanece en el estado SELECT, el cliente reúne respuestas DHCPOFFER desde los servidores DHCP. Cada oferta contiene información de configuración para el cliente junto con una dirección IP que el servidor ofrece para arrendar al cliente. El cliente debe seleccionar una de las respuestas (por ejemplo, la primera en llegar) y negociar con el servidor un arrendamiento. Para ello, el cliente envía al servidor un mensaje DHCPREQUEST y entra al estado REQUEST(SOLICITAR). A fin de enviar un acuse de recibo de la recepción de la solicitud y comenzar el arrendamiento, el servidor responde con el envío de un DHCPACK. El arribo y el acuse de recibo hacen que el cliente cambie al estado BOUND (ENLAZAR), en el cual el cliente procede a utilizar la dirección.

1.4 TERMINACION DEL ARRENDAMIENTO El estado BOUND es el estado normal de operación; un cliente por lo general se mantiene en un estado BOUND mientras utiliza la dirección IP que ha adquirido. Si un cliente tiene almacenamiento secundario (por ejemplo, un disco local), puede almacenar la dirección IP que le fue asignada y solicitar la misma dirección cuando arranque de nuevo. En algunos casos, sin embargo, un cliente en el estado BOUND puede descubrir que no necesita por más tiempo una dirección IP. Por ejemplo, supongamos que un usuario conecta una computadora portátil a una red, utiliza el DHCP para adquirir una dirección IP y, luego, se vale del TCP/IP para leer correo electrónico. El usuario puede no saber por cuánto tiempo leerá su correspondencia, o bien, la computadora portátil podría permitir al servidor seleccionar el período arrendado. En cualquier caso, el DHCP especifica un periodo de arrendamiento mínimo de 1 hora. Si después de obtener una dirección IP, el usuario descubre que no tiene mensajes de correo electrónico para leer podría optar por desconectar la computadora portátil y cambiar hacia otra localidad. Cuando no es necesario un arrendamiento por más tiempo, el DHCP permite que el cliente termine sin esperar a que su tiempo expire. Tal terminación es muy útil en los casos en los que ni el cliente ni el servidor pueden determinar una terminación de arrendamiento apropiada, al mismo tiempo que se garantiza el arrendamiento pues le es posible a un servidor seleccionar un periodo de arrendamiento razonablemente largo. Una finalización temprana es importante en especial si el número de direcciones IP que un servidor tiene disponible es mucho más pequeño que el número de computadoras que están conectadas a la red. Si cada cliente termina su arrendamiento en cuanto la dirección IP deja de ser necesaria, el servidor será capaz de asignar la dirección a otro cliente. Para terminar un arrendamiento de manera temprana, el cliente envía un mensaje DHCPRELEASE al servidor. Liberar una dirección es una acción final que previene que el cliente continúe utilizando la dirección. Así, luego de transmitir el mensaje de liberación, el cliente no debe enviar ningún otro datagrama que utilice la dirección. En términos del diagrama de transición de estados de la figura 1.1, un anfitrión que envía una DHCPRELEASE deja el estado BOUND y debe comenzar de nuevo en el estado INITIALIZE antes de utilizar IP. 4



ESPOCH-FIE-EIS

1.5 ESTADO DE RENOVACION DE ARRENDAMIENTO Se ha indicado que cuando se adquiere una dirección, un cliente DHCP cambia al estado BOUND. Al entrar al estado BOUND, el cliente instala tres temporizadores que controlan: la renovación de arrendamiento, la reasignación y la expiración. Un servidor DHCP puede especificar valores explícitos para los temporizadores cuando asigna una dirección al cliente; si el servidor no especifica valores para el temporizador, el cliente empleará valores por omisión. El valor por omisión para el primer temporizador es la mitad del tiempo que tarda el arrendamiento. Cuando el primer temporizador expira, el cliente debe lograr la renovación de su arrendamiento. Para solicitar una renovación, el cliente envía un mensaje DHCPREQUEST hacia el servidor desde el que fue obtenido el arrendamiento. El cliente entonces cambia al estado RENEW (RENOVAR) en espera de una respuesta. DHCPREQUEST contiene la dirección IP del cliente que está utilizando actualmente e interroga al servidor para extender el arrendamiento en esa dirección. Como en la negociación inicial de arrendamiento, un cliente puede solicitar un período para la extensión, pero el servidor controla, en última instancia, la renovación. Un servidor puede responder a la solicitud de renovación de un cliente de una de dos formas: puede instruir al cliente para que deje de usar la dirección o aprobar que la continúe utilizando. Si se aprueba esto último, el servidor envía un DHCPACK, el cual hace que el cliente regrese al estado BOUND y continúe utilizando la dirección. El DHCPACK puede también contener valores nuevos para los temporizadores del cliente. Si un servidor desaprueba que se continúe utilizando la dirección, el servidor enviará una DHCPNACK (acuse de recibo negativo), el cual hace que el cliente deje de utilizar la dirección inmediatamente y regrese al estado INITIALIZE.

Luego de enviar un mensaje DHCPREQUEST en el que solicite una extensión de su arrendamiento, el cliente se mantiene en el estado RENEW en espera de una respuesta. Si no se obtiene ninguna respuesta, el servidor que garantiza el arrendamiento se considera inactivo o inaccesible. Para manejar la situación, el DHCP libera un segundo temporizador, el cual fue instalado cuando el cliente entró al estado BOUND. El segundo temporizador expira luego de que se cumple el 87.5% del periodo de arrendamiento y hace que el cliente pase del estado RENEW al estado REBIND (UNIR DE NUEVO). Cuando se realiza la transición, el cliente asume que el anterior servidor DHCP no está disponible y comienza a difundir un mensaje DHCPREQUEST hacia cualquier servidor en la red local. Cualquier servidor configurado para proporcionar servicio a un cliente puede responder de manera positiva (por ejemplo, para extender el arrendamiento) o negativamente (esto es, para no permitir que se siga usando la dirección IP). Si recibe una respuesta positiva, el cliente vuelve al estado BOUND y reinicializa los dos temporizadores. Si recibe una respuesta negativa, debe cambiar al estado INITIALIZE, dejar de usar inmediatamente la dirección IP y adquirir una nueva dirección IP antes de continuar utilizando el IP. Luego de cambiar al estado REBIND, el cliente tendrá que interrogar al servidor original y a todos los servidores en la red local para una extensión del arrendamiento. En dado caso de que el cliente no reciba una respuesta de ningún servidor antes de que expire su tercer temporizador, el arrendamiento expirará. El cliente debe dejar de utilizar la dirección IP, regresar al estado INITIALIZE y comenzar la adquisición de una nueva dirección. 5



ESPOCH-FIE-EIS

1.6 FORMATO DE LOS MENSAJES DHCP 0 31

8

16

24

OP

Tipo Hardware Longitud Hardware Saltos Identificador de transacción Segundos Banderas Dirección IP del cliente Su dirección IP Dirección IP del servidor Dirección IP del ruteador Dirección de hardware del cliente (16 octetos de longitud máximo) Nombre de anfitrión servidor (64 octetos) Nombre de archivo de arranque (128 octetos) Opciones (variable)

Figura 1.2 Formato del mensaje DHCP Campo

Significado OP Especifica si el mensaje es una solicitud con el valor 1 o una 8 bits respuesta con el valor 2 Tipo de Hardware Indica el tipo de hardware de red, en el caso de Ethernet vale 8 bits 1 Longitud Hardware Longitud de la dirección de Hardware, para Ethernet tiene un 8 bits valor de 6 Indica la cantidad de servidores que reenviaron la solicitud Saltos 8 bits Contiene un valor que el cliente utiliza para determinar si la Identificador de respuesta corresponde a su solicitud. El valor de la respuesta transacción 32 bits es igual al de la solicitud. Segundos Especifica el tiempo transcurrido desde que se inicio el 16 bits arranque de la computadora Banderas Solo el primer bit de este campo tienen asignado un 16 bits significado. El cliente activa este bit (valor 1) para solicitar que el servidor responda por medio de difusión (255.255.255.255) y no utilice unidifusión mediante la dirección de hardware del cliente, debido a que puede suceder que la dirección IP no concuerde con la dirección de la computadora, y el software IP puede descartar el datagrama. Dirección IP del Si la computadora (cliente) conoce su dirección IP debido a que ya le fue asignada, la ubicará en este campo. cliente 32 bits Su dirección IP Es el campo en el cual el servidor entrega a la IP solicitada al 32 bits cliente. Dirección IP del Es llenado por el cliente si este conoce la dirección IP del servidor, caso contrario estará puesto a cero, por lo que servidor 32 bits responderá cualquier servidor que reciba la solicitud. Contiene la dirección IP del ruteador predeterminado Dirección IP del ruteador 32 bits Dirección de Contiene la dirección de hardware de la interfaz del cliente, en Hardware del el caso de ethernet es una dirección de 6 octetos. cliente 6


Nombre del anfitrión servidor Nombre del archivo de arranque

Opciones


ESPOCH-FIE-EIS

Si el cliente conoce el nombre de dominio del servidor lo ubica en este campo, caso contrario el espacio se desprecia y no se llena de ceros debido a que ocupa muchos octetos Si una computadora no posee un sistema operativo y realiza la solicitud de uno específico, el servidor le enviará el nombre del archivo en el cual se encuentra el sistema operativo, y la máquina cliente en la que esta almacenado. El cliente mediante un protocolo de transferencia de archivo puede obtener una copia. Cuando no se requiere este campo se procede igual que en el caso del campo anterior. Para codificar información como la duración de arrendamiento, los tipos de mensajes DHCP DEL 1 al 7 ( DHCPDISCOVER, DHCPOFFER DHCPREQUEST, DHCPDECLINE, DHCPPACK, DHCPNACK, DHCPRELEASE) , máscara de subred, hora del día etc.

1.7 EJERCICIOS 1. Si las computadoras de su Institución utiliza la red para arrancar. ¿Qué protocolos son utilizados empleados?. 2. Elabore una lista de la información que puede configurarse al arrancar una computadora. 3. Existen algunas aplicaciones de red que difieren la configuración hasta que se necesita el servicio. Ejemplo de esto es cuando queremos imprimir, pues la computadora espera hasta que el usuario intente imprimir un documento antes de empezar a buscar impresoras disponibles . ¿Cuál considera que es la ventaja principal de la configuración diferida y cuál su desventaja?. 4. Antes de que una computadora pueda emplear una red para arrancar, debe tener algún código de protocolo almacenado localmente. Elabore una lista de los protocolos que deben estar disponibles antes de que la computadora pueda servirse de BOOTP para arrancar. 5. Compare un protocolo de asignación de direcciones que use ligaduras y otro que se valga de un servidor como por ejemplo DHCP. ¿Qué protocolo funciona mejor en una WAN? . ¿Qué protocolo funciona mejor en una LAN con mucho tráfico? 6. Leer el estándar para encontrar como pueden acordar un cliente DHCP y un servidor la duración de arrendamiento sin tener relojes sincronizados. 7. Considere un anfitrión que tiene un disco y utiliza DHCP para obtener una dirección IP. Si el anfitrión almacena su dirección en un disco junto con la fecha en que expira el arrendamiento y luego se reinicializa dentro del periodo de arrendamiento, ¿puede utilizar la dirección? ¿Por qué si o por qué no? 8. El DHCP establece un arrendamiento de dirección mínimo de una hora. ¿Puede usted imaginar una situación en la que el arrendamiento mínimo del DHCP provoque inconvenientes? Explíquelo. 9. Lea el RFC para encontrar cómo especifica el DHCP la renovación y la reasignación de temporizadores. ¿Un servidor debe establecer siempre uno sin el otro? ¿Por qué sí o por qué no? 10. El diagrama de transición de estado no muestra la retransmisión. Lea el estándar para encontrar cómo muchas veces debe retransmitir un cliente una solicitud. 11. ¿Puede el DHCP garantizar que un cliente no es "engañado" (es decir, puede el DHCP garantizar que no está enviando información de configuración del anfitrión 7



ESPOCH-FIE-EIS

A al anfitrión B)? ¿La respuesta dif iere para BOOTP? Explique por qué si o por

qué no. 12. El DHCP especifica que un anfitrión debe prepararse para manejar por lo menos 312 octetos de opciones. ¿Cómo se obtiene el número 312? 13. ¿Puede una computadora que utiliza al DHCP obtener una dirección IP operando un servidor? Si así es, ¿cómo accede un cliente al servidor?

CAPITULO II TELNET 2.1 PROTOCOLO TELNET Los protocolos TCP/IP incluyen un protocolo de terminal remota sencillo, llamado TELNET que permite al usuario de una localidad establecer una conexión TCP con un servidor. TELNET transfiere después las pulsaciones directamente desde el teclado del usuario a la computadora remota como si hubiesen sido hechos en un teclado unido a la máquina remota. TELNET también transporta la salida de la máquina remota de regreso a la pantalla del usuario. El servicio se llama transparent (transparente) porque da la impresión de que el teclado y el monitor del usuario están conectados de manera directa a la máquina remota. Aunque TELNET no es sofisticado en comparación con algunos protocolos de terminal remota, se utiliza ampliamente. El software de cliente TELNET suele permitir que el usuario especifique una máquina remota ya sea dando su nombre de dominio o su dirección IP. TELNET ofrece tres servicios básicos: 1. Define una terminal virtual de red (network virtual terminal) que proporciona una interfaz estándar para los sistemas remotos. Los programas clientes no tienen que comprender los detalles de todos los sistemas remotos, se construyen para utilizarse con la interfaz estándar. 2. Incluye un mecanismo que permite al cliente y al servidor negociar opciones, asimismo proporciona un conjunto de opciones estándar (por ejemplo, una de las opciones controla si los datos que se transfieren a través de la conexión se valen del conjunto de caracteres ASCII estándar de siete bits o de un conjunto de caracteres de ocho bits). 3. TELNET trata con ambos extremos de la conexión de manera simétrica. En particular, TELNET no fuerza la entrada del cliente para que ésta provenga de un teclado, ni al cliente para que muestre su salida en una pantalla. De ésta manera, TELNET permite que cualquier programa se convierta en cliente. Además, cualquier extremo puede negociar las opciones. La figura 2.1, ilustra la forma en que los programas de aplicación implantan un cliente y servidor de TELNET. Como se muestra en la figura, cuando un usuario invoca a TELNET, un programa de aplicación en la máquina del usuario se convierte en el cliente. El cliente establece una conexión TCP con el servidor por medio de la cual se comunicarán. Una vez establecida la conexión, el cliente acepta los pulsos de teclado del usuario y los manda al servidor, al tiempo que acepta caracteres de 8



ESPOCH-FIE-EIS

manera concurrente que el servidor regresa y despliega en la pantalla del usuario. El servidor debe aceptar una conexión TCP del cliente y después transmitir los datos entre la conexión TCP y el sistema operativo local.

Dispositivo de E/S Usuario

CLIENTE TELNET

SERVIDOR TELNET

TCP

TCP

IP

IP

El servidor envía a una pseudo terminal

Red de redes TCP/IP

Figura 2.1 Trayectoria de datos en un sesión TELNET En la práctica, el servidor es más complejo de lo que muestra la figura pues debe manejar diversas conexiones concurrentes. Normalmente, un proceso de servidor maestro espera nuevas conexiones y crea un nuevo esclavo para manejar cada conexión. De esta forma, el servidor de TELNET, que se muestra en la figura 2.1, representa al esclavo que maneja una conexión en particular. La figura no muestra al servidor maestro que está atento a nuevas peticiones, ni se muestra a los esclavos que se encuentran manejando otras conexiones. Se utiliza el término pseudo terminal para describir el punto de entrada del sistema operativo que permite que un programa, que se está corriendo como el servidor TELNET, transfiera caracteres al sistema operativo como si vinieran de un teclado. Es imposible construir un servidor TELNET a menos que el sistema operativo proporcione dicha característica. Si el sistema soporta la abstracción de una pseudo terminal, el servidor TELNET podrá implantarse con programas de aplicación. Cada servidor esclavo conecta una corriente TCP de un cliente a una pseudo terminal en particular. El arreglo del servidor TELNET para que sea un programa de nivel de aplicación tiene sus ventajas y sus desventajas. La ventaja más obvia es que hace la modificación y el control del servidor más fácil que si el código estuviera enclavado en el sistema operativo. La desventaja evidente es su ineficiencia. Cada pulso de teclado viaja del teclado del usuario a través del sistema operativo hacia el programa cliente, del programa cliente regresa a través del sistema operativo y a través de la red de redes hacia la máquina servidor. Después de llegar a su máquina destino, los datos deben viajar a través del sistema operativo del servidor al. programa de aplicación del servidor, y del programa de aplicación del servidor de regreso al sistema operativo del servidor, en un punto de entrada de pseudo 9



ESPOCH-FIE-EIS

terminal. Finalmente, el sistema operativo remoto entrega el carácter al programa de aplicación que el usuario está corriendo. Mientras tanto, la salida (incluyendo el eco de carácter remoto si es que la opción se ha seleccionado) viaja de regreso del servidor al cliente transfiriéndose por la misma trayectoria. 2

2.2 HETEROGENEIDAD Para hacer que TELNET interopere entre tantos sistemas como sea posible, debe adaptar los detalles de las computadoras heterogéneas y los sistemas operativos. Por ejemplo, algunos sistemas requieren de líneas de texto que se terminen mediante el carácter de control de retorno de carro (CR) de ASCII. Para otros es necesario el carácter de alimentación de línea (LF) de ASCII. Incluso, algunos necesitan la secuencia de los dos caracteres CR-LF. Aunado a lo anterior, los sistemas más interactivos permiten que el usuario pulse una tecla para que interrumpe un programa que se está corriendo. Sin embargo, el pulso de teclado empleado para interrumpir un programa varía de sistema a sistema (por ejemplo, algunos sistemas emplean Control-C, mientras otros se valen de ESCAPE.

Formato del sistema Dispositivo de cliente utilizado Cliente de E/S Usuario

Formato NVT utilizado

Cliente

Conexión TCP Red de redes

Sistema del Formato del Servidor sistema servidor utilizado

Figura 2.2 Utilización del formato NVT Para adaptar la heterogeneidad, TELNET define cómo deben mandarse las secuencias de datos y comandos a través de Internet. La definición se conoce como network virtual terminal (terminal virtual de red o NVT). Como muestra la figura 2.2, el software cliente traduce las pulsaciones de teclado y las secuencias de comandos que vienen de la terminal del usuario a formato NVT y las envía al servidor. El software del servidor traduce los datos y comandos que acaban de llegar de formato NVT al formato que el sistema remoto requiera. Para devolver los datos, el servidor remoto traduce del formato de una máquina remota a NVT y el cliente local traduce del formato NVT al formato de la máquina local. La definición del formato NVT es bastante clara. Toda comunicación comprende un conjunto de octetos de 8 bits. Al arrancar, NVT utiliza la representación estándar de 7 bits de USASCII para los datos y reserva los octetos con el conjunto de bits de alto orden para las secuencias de comandos. El conjunto de caracteres USASCII incluye 95 caracteres que tienen gráficas "imprimibles" (por ejemplo, letras, dígitos y signos de puntuación) así como 33 códigos de "control". A todos los caracteres imprimibles se les asigna el mismo significado que el conjunto de caracteres estándar de USASCII. El estándar NVT define las interpretaciones para los caracteres de control como se muestra en la figura 2.3. 2


10


Código de control ASCII


Valor decimal

NUL BEL BS HT

0 7 8 9

LF VT FF CR

10 11 12 13

Otro control

•

ESPOCH-FIE-EIS

Significado asignado No hay operación (sin efecto en la salida) Sonido audible/señal visible (sin movimiento) Movimiento a la izquierda de un carácter Movimiento a la derecha al siguiente tabulador horizontal Movimiento hacia abajo (vertical) a la siguiente Línea Movimiento hacia abajo al siguiente tabulador vertical Movimiento hacia arriba a la siguiente página Movimiento hacia la izquierda en la línea presente Sin operación (sin efecto en la salida)

Figura 2.3 Tablas de los códigos de control ASCII y alguna de las Interpretaciones NVT para TELNET de los caracteres de control USASCII Además de la interpretación de caracteres de control. NVT define la terminación de línea estándar como una secuencia de dos caracteres: CR-LF. Cuando un usuario pulsa la tecla que corresponde a fin de línea en la terminal local (por ejemplo, ENTER o RETORNO), el cliente TELNET debe transformarla en CR-LF para su transmisión. El servidor TELNET traduce a CR-LF en la secuencia de caracteres apropiada de fin de línea para la máquina remota. 11



ESPOCH-FIE-EIS

2.3 COMANDOS QUE CONTROLAN EL EXTREMO REMOTO NVT de TELNET adapta las funciones de control mediante la definición de cómo se transmiten de cliente a servidor. Conceptualmente, pensamos en NVT como entrada de aceptación de un teclado que puede generar más de 128 caracteres. Suponemos que el teclado del usuario tiene teclas virtuales (imaginarias) que corresponden a las funciones que normalmente se utilizan para el procesamiento de control. Por ejemplo, NVT define una tecla de "interrupción" conceptual que pide la terminación de un programa. En la figura 2.4, se listan las funciones de control que NVT permite. SEÑAL IP AO AYT EC EL SYNCH BRK

SIGNIFICADO (Interrupt Process) Interrupción del proceso (termina de correrse el programa) (Abort Output) Salida abortada (se descarta cualquier salida de búfer) (Are You There) Estás ahí (prueba si el servidor responde) (Erase Character) Borra carácter (borra el carácter previo) (Erase Line) Borra línea (borra toda la línea actual) (Synchronize) Sincroniza (despeja la trayectoria de datos hasta que el punto de datos TCP es urgente, pero interpreta comandos) (Break) Pausa (tecla de pausa o señal de atención)

Figura 2.4 Funciones de control que NVT de TELNET reconoce La mayor parte de los teclados no posee teclas extra para los comandos. De hecho, los sistemas operativos individuales o los interpretadores de comandos tienen una gran variedad de maneras para generarlos. La técnica más común es construir un carácter ASCII individual para una función de control, de modo que, cuando el usuario pulsa esa tecla, el sistema operativo lleve a cabo las acciones apropiadas en lugar de aceptar al carácter como entrada. Los diseñadores de NVT eligieron mantener a los comandos separados del conjunto de caracteres ASCII normales por dos razones. En primer lugar , definir las funciones de control de manera separada significa que TELNET tiene una mayor flexibilidad. Puede transferir todas las secuencias de caracteres posibles en ASCII entre el cliente y el servidor así como también todas las funciones de control posibles. En segundo lugar , mediante la separación de señales de los datos normales, NVT permite que el cliente especifique las señales de manera no ambigua, nunca hay confusión acerca de si un carácter de entrada se deberá tratar como dato o como función de control. Para transferir las funciones de control a través de la conexión TCP, TELNET las codifica mediante la secuencia de escape. Una secuencia de escape se vale de un octeto reservado para indicar que sigue a continuación un octeto de código de control. En TELNET, el octeto reservado que inicia una secuencia de escape se conoce como el octeto interpret as command (interpretar como comando o IAC). En la figura 2.5, se listan los comandos posibles y las codificaciones decimales utilizados para cada uno.

COMANDO CODIFICACION DECIMAL IAC

255

SIGNIFICADO Se interpreta al siguiente octeto como comando (cuando el octeto IAC aparece como dato, quien envía lo

12


DON'T

254

DO WON'T WILL SB GA EL EC AYT AO IP BRK DMARK

253 252 251 250 249 248 247 246 245 244 243 242

NOP SE EOR

241 240 239


ESPOCH-FIE-EIS

duplica y manda una secuencia de dos octetos IAC-IAC) Negación de petición para ejecutar una opción especificada Aprobación para permitir una opción especificada Rechazo de ejecución de una opción especificada Autorización de realizar una opción especificada Inicio de subnegociación de opción Señal para "continuar" (go ahead) Señal de "borrado de línea" (erase line) Señal de "borrado de carácter" (erase character) Señal de "estás ahí" (are you there) Señal de "aborto de salida" (abort output) Señal de "interrupción de proceso" (interrup process) Señal de "pausa" (break) La porción de corriente de datos de un SYNCH (siempre acompañada de una notificación Urgente del TCP) Sin operación Fin de la opción de subnegociación Fin del registro

Figura 2.5 Comandos de TELNET y codificación para cada uno Como se muestra en la tabla, las señales generadas por las teclas conceptuales en cada teclado NVT tienen un comando correspondiente. Por ejemplo, para pedir que el servidor interrumpa el programa que se está ejecutando, el cliente debe mandar la secuencia de dos octetos IAC IP (255 seguido de 244). Los comandos adicionales permiten que el cliente y el servidor negocien qué opciones utilizarán y la comunicación sincronizada.

2.4 FORZAR AL SERVIDOR A LEER UNA FUNCIÓN DE CONTROL Enviar funciones de control junto con datos normales no siempre es suficiente para garantizar los resultados deseados. A fin de ver la razón, consideremos la situación en la que un usuario podría enviar la función de control de interrupción de proceso al servidor. Normalmente, dicho control sólo se necesita cuando el programa que se ejecuta en una máquina remota se está conduciendo mal y el usuario quiere que el servidor deje de correr el programa. Por ejemplo, el programa podría estar ejecutando un ciclo sin fin sin leer la entrada o generando una salida. Por desgracia, si la aplicación en la localidad del servidor se detiene a leer la entrada, los buffers del sistema operativo en ocasiones se llenarán y el servidor será incapaz de escribir más datos en la pseudo terminal. Cuando esto sucede, el servidor debe dejar de leer datos de la conexión TCP que hacen que los bufers se llenen. En ocasiones, el TPC de la máquina servidor comenzará a anunciar un tamaño de ventana cero, previniendo que los datos fluyan a través de la conexión. Si el usuario genera una función de interrupción de control, cuando los bufers están llenos, la función de control no llegará al servidor. Es decir que el cliente puede formar la secuencia de comandos IAC IP y escribirla en la conexión TCP, pero como el TCP ha dejado de enviar a la máquina del servidor, el servidor no leerá la secuencia de control. El punto es que: TELNET no puede confiarse al flujo de datos 13



ESPOCH-FIE-EIS

convencional por sí sola para transportar secuencias de control entre cliente y servidor, pues una aplicación que se conduce mal necesita estar controlada ya que se podría bloquear de manera inadvertida el flujo de datos.

Para resolver el problema, TELNET utiliza una señal fuera de banda. El TCP implemento la señalización fuera de banda con el mecanismo de dato urgente. Dondequiera que se coloque una función de control en la corriente de datos, TELNET también mandará un comando SYNCH. TELNET después anexará un octeto reservado, llamado marca de datos y hará que el TCP emita una señal hacia el servidor enviando un segmento con el conjunto de bits de URGEN DATA (DATOS URGENTES). Los segmentos que llevan los datos urgentes evitan el control de flujo y llegan de inmediato al servidor. En respuesta a una señal urgente, el servidor lee y descarta todos los datos hasta que encuentra la marca de datos. El servidor regresa a su procesamiento normal cuando encuentra la marca de datos.

2.5 OPCIONES DE TELNET En TELNET, las opciones son negociables, lo que hace posible reconfigurar su conexión para el cliente y el servidor. Por ejemplo, dijimos que la corriente de datos solía transmitirse en datos de 7 bits y utilizaba octetos con el conjunto del octavo bit para transmitir la información de control como el comando de interrupción de proceso. Sin embargo, TELNET también ofrece una opción que permite que el cliente y el servidor transmitan datos de 8 bits (cuando se transmiten datos de 8 bits, el octeto reservado IAC debe aún duplicarse si aparece en los datos). El cliente y el servidor deben negociar, y ambos tienden a llegar al acuerdo de transmitir datos de 8 bits antes de que tales transmisiones sean posibles. El rango de opciones de TELNET es amplio: algunos extienden las capacidades de manera significativa mientras que otros tratan con los detalles menores. Por ejemplo, el protocolo original fue diseñado para un ambiente half-duplex en el que era necesario indicar al otro extremo que "continuara" antes de que se pudieran mandar más datos. Una de las opciones controla si TELNET opera en modo halfduplex o füll-duplex. Otra de las opciones permite que el servidor, en una máquina remota, determine el tipo de terminal del usuario. El tipo de terminal es importante para el software que genera las secuencias de posicionamiento del cursor (es decir, un editor de pantalla completa que se ejecuta en una máquina remota). En la figura 2.6, se listan algunas de las opciones de TELNET que se implantan con mayor frecuencia.

NOMBRE CODIGO SIGNIFICADO Transmisión binaria 0 Se cambia la transmisión a modo binario de 8 bits Eco 1 Se permite que uno de los lados haga eco para los datos que recibe Supresión de GA 3 Se suprime (ya no se manda) la señal de continuar después de los datos Estado 5 Petición del estado de la opción TELNET de una localidad remota Marca de tiempo 6 Petición de que se inserte una marca de tiempo en la corriente de retorno para sincronizar dos 14



ESPOCH-FIE-EIS

extremos de una conexión Tipo de terminal

24

Fin de registro Modo de línea

25 34

Intercambio de información sobre la elaboración y modelo de una terminal que se está usando (permite que los programas se ajusten a la salida como las secuencias de posicionamiento del cursor para la terminal del usuario) Termina los datos mandados con código EOR Utiliza la edición local y envía líneas completas en lugar de caracteres individuales

Figura 2.6 Opciones de TELNET usadas con mayor frecuencia. 2.6 NEGOCIACIÓN DE OPCIONES DE TELNET En razón de que en algunas ocasiones tiene sentido para el servidor iniciar una opción en particular, el protocolo está diseñado para permitir o dejar de hacer una petición. De este modo, se dice que el protocolo es simétrico con respecto al procesamiento de opciones. El extremo de recepción puede responder a una petición con una aceptación positiva o un rechazo. En la terminología de TELNET, la petición es WILL x, que significa estarías de acuerdo en dejarme usar la opción X; y la respuesta podría ser DO x o DON'T x, que significa estoy de acuerdo en dejarte utilizar la opción X o no estoy de acuerdo en dejarte utilizar la opción X. La simetría surge porque DO X pide que la parte receptora comience a usar la opción X, y WILL X o WON'T X significa comenzaré a usar la opción X no comenzaré a usar la opción X.

A veces se requiere que ambos extremos corran una implantación de NVT no agrandada (es decir, una sin ninguna de las opciones activadas). Si una de las localidades trata de negociar una opción que la otra no comprende, la localidad que recibe la petición puede sencillamente declinarla. De este modo, es posible interoperar versiones más nuevas y sofisticadas de clientes y servidores TELNET (es decir, software que comprenda más opciones) con versiones más antiguas y menos sofisticadas. Si el cliente y el servidor comprenden las nuevas opciones, pueden ser capaces de mejorar la interacción. Si no es así, se revertirán a un estilo menos eficiente pero trabajable.

2.7 CONSIDERACIONES DE SEGURIDAD EN TELNET Existen unos cuantos requisitos de seguridad orientados a conexión que debe tener en mente cuando inicie una sesión Telnet: • Confidencialidad • Integridad • Autenticación entidad-igual • Control de acceso basado en identidad

15



ESPOCH-FIE-EIS

Todos estos requisitos asumen implícitamente que hay seguridad básica implementada en un protocolo de aplicación punto a punto en uso, orientado al flujo y al nivel de conexión. Pero usted no puede dar por hecho que la conexión es segura, así como no siempre encontrará mecanismos de seguridad implementados dentro de protocolos de aplicación. Si es necesario, usted deberá tratar de implementar mecanismos de seguridad en los niveles inferiores, tales como los niveles de transporte o de red. El Transport Layer Security Protocol (TLSP, Protocolo de Seguridad al Nivel de Transporte), el cual se volvió una norma de Internet en julio de 1992, es una solución posible para la falta de seguridad de las conexiones Telnet. TLSP se ejecutará bajo el nivel de transporte y proporcionará servicios de seguridad para las conexiones Telnet por conexión, al proveer cifrado criptográfico de extremo a extremo directamente sobre el nivel de red. Una de las ventajas de basarse en este mecanismo de seguridad en los niveles más bajos es que puede evitarse duplicar los esfuerzos de seguridad. Pero, de nuevo, no estoy seguro de cuántos desarrolladores o profesionales de la implementación desearían introducir software nuevo en núcleos de sistemas operativos. Por tanto, sería mucho mejor ofrecer seguridad para las conexiones Telnet en el nivel de aplicación que en el nivel de transporte o de red. A pesar de los productos a nivel de capa de aplicación que utilice dirigidos a la seguridad u otros mecanismos de seguridad que se tenga implementados, existen medidas de seguridad potenciales que debe tomarse en consideración:

a) Estrategias de vencimiento de plazos de tiempo3 

Duración de las sesiones Telnet. Usted puede configurar la duración de las

sesiones Telnet de sus usuarios. La extensión del tiempo podría basarse en el tipo de usuario o el usuario individual. Por ejemplo, las cuentas de invitados que utilizan Telnet en una empresa podrían tener un tiempo de sesión más corto (5 a 10 minutos) que el personal de soporte técnico, los administradores con una jerarquía importante o cualquier otro usuario calificado/certificado. 

Vencimiento de sesión Una sesión Telnet puede configurarse para finalizar si no

se lleva a cabo ninguna actividad después de un periodo específico. 

Protectores de pantalla seguros. Puede utilizar un protector de pantalla activado

por tiempo para dispararse cuando no exista actividad en una sesión después de cierto periodo. En este caso, a diferencia del vencimiento de sesión, la sesión Telnet permanecerá activa en la red, pero protegida. Podría advertirse a los usuarios antes de que se agote el tiempo.

b) Estrategias de protección de datos 

Directorios de intercambio de información. Usted debería implementar directorios

temporales para toda la empresa cuando se guarden registros sin verificar. Además, deberá asegurarse de que ningún usuario sin autorización modifique 3

Goncalves Marcus. Manual de firewalls. Pág. 66

16



ESPOCH-FIE-EIS

estos datos después de que la entrada se haya verificado por una firma electrónica. 

Protección de información delicada. Asegúrese de proteger la información

delicada permitiendo el acceso a la misma sólo a los usuarios validados y recordándoles que toda la información es confidencial.

c) Lista de control sobre la seguridad de las sesiones Telnet 





Haga respetar el uso de contraseñas de al menos ocho caracteres y fuerce a los usuarios a que las cambien cada seis meses. Restrinja las sesiones Telnet y el acceso mediante contraseñas y ubicación de terminales. Si las sesiones Telnet inician desde el hogar o desde cualquier otra ubicación remota mediante marcado telefónico, debería requerir una segunda contraseña o un procedimiento de llamada de verificación de origen.



Las contraseñas deberían encriptarse.



¡No permita que las contraseñas se compartan!









Registre en bitácora todos los accesos por contraseña y las direcciones de red y genere informes de uso con el nombre del usuario, la dirección de red y la fecha (rastro de la auditoría del acceso). Desarrolle perfiles de usuario y supervise las desviaciones del perfil. Los usuarios de Telnet deberían firmar un acuerdo confidencial. Realice simulacros de pruebas de seguridad periódicamente con algunos programas de evaluación de la seguridad disponibles. Implemente un firewall.

2.8 EJERCICIOS 1. Utilice un cliente telnet para conectar un teclado y monitor al puerto de protocolo TCP para eco o cambio y observe lo que sucede. 2. Lea el estándar telnet referente al funcionamiento de la operación SYNCH. 3. TELNET emplea el mecanismo de dato urgente del TCP para forzar al sistema operativo remoto a que responda a las funciones de control rápidamente. Lea el estándar para averiguar qué comandos del servidor remoto trabajan m ientras se explora el flujo de entrada. 4. ¿Cómo puede la opción de negociación simétrica DO/DON'T- WIL/ WON'T producir un ciclo sin fin de respuestas si la otra parte siempre reconoce una petición? 5. El archivo de texto para RFC 854 (la especificación del protocolo TELNET) contiene exactamente 854 líneas. ¿Piensa que hay una coincidencia cósmica en esto?

17



ESPOCH-FIE-EIS

CAPITULO III FTP 3.1 PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS FTP El protocolo FTP (File Transfer Protocol) es utilizado para la transferencia de archivos, sean estos binarios (código ejecutable de un programa o una imagen) o de texto (caracteres ASCII). Iniciada una sesión se puede traer archivos desde el servidor remoto o enviar archivos a éste. FTP proporciona facilidades para las funciones de transferencia, como son: 





Acceso Interactivo. A pesar de que FTP está diseñado para ser usado por programas, la mayoría de las implementaciones proporcionan al usuario un interfaz con servidores remotos para importar o exportar archivos. Especificaciones de Formato. FTP permite al cliente especificar el tipo y el formato de los datos. Por ejemplo, puede especificar que los datos sean ASCII o binarios. Control de Autenticación. FTP exige al cliente que se identifique mediante su nombre de usuario y su contraseña. El servidor puede negarle el acceso en caso de que ese usuario no esté autorizado. 4

Existen localizaciones públicas que admiten que cualquier usuario inicie sesiones FTP denominadas anónimas, en las cuales se proporciona como nombre de usuario la palabra anonymous y como contraseña la dirección electrónica de usuario o la palabra guest, para iniciar la sesión. Al igual que otros servidores, la mayoría de las implementaciones de FTP permiten el acceso concurrente de varios clientes. Los clientes emplean TCP para conectarse al servidor. En general en este tipo de servidores, el proceso maestro del servidor genera un esclavo para atender a cada uno de los clientes. En FTP, el proceso maestro acepta y lleva a cabo las peticiones de conexión del cliente, pero emplea otro proceso para manejar la transferencia de datos. Este modelo puede observarse en la figura 3.1. Como muestra la figura, el proceso cliente se conecta al servidor mediante una conexión TCP, mientras que la transferencia de datos emplea sus propias conexiones TCP. En general, el proceso de control y la conexión de control permanecen activas mientras el usuario mantenga su sesión FTP abierta. Sin embargo, FTP establece una nueva conexión para cada archivo que se vaya a transmitir. La conexión para transferencia de datos y los procesos de transferencia de datos se crean dinámicamente según se van necesitando, mientras que la conexión de control permanece activa mientras perdure la sesión FTP. Una vez que la conexión de control desaparece, la sesión finaliza y los procesos de ambos extremos finalizan la transferencia de datos.

4


18



ESPOCH-FIE-EIS

CLIENTE

SERVIDOR

PROCESO DE CONTROL

TRANSF. DE DATOS

TRANSF. DE DATOS

PROCESO DE CONTROL

21

20

TCP

TCP

IP

IP

RED TCP/IP

Figura 3.1 Esquema de funcionamiento FTP 3.2 ASIGNACIÓN DE NUMERO DE PUERTO TCP Cuando un cliente se conecta al servidor, el cliente emplea un puerto aleatorio, pero el servidor se conecta en el puerto 21. Cuando el proceso de control crea una nueva conexión TCP para la transferencia de datos, no puede emplear los mismos números de puertos empleados en la conexión de control. El cliente obtiene un puerto no usado de su máquina y lo emplea para el proceso de transferencia de datos. El proceso de transferencia de datos en la máquina servidora se lleva a cabo mediante el puerto 20 (puerto reservado a la transferencia de datos). Para enviar datos a través de la conexión de control FTP utiliza el protocolo NVT de TELNET . A diferencia de TELNET, el FTP no permite la negociación de opciones, emplea sólo la definición básica de NVT. De esta manera, la administración de una conexión de control FTP es mucho más sencilla que la administración de una conexión estándar de TELNET. Sin importar las limitaciones, usar la definición de TELNET, en lugar de inventar una, ayuda a simplificar considerablemente al FTP.

3.3 VISION DE FTP Los usuarios ven a FTP como un sistema interactivo. Una vez que se ha invocado, el cliente ejecuta una serie de submandatos de forma repetitiva: leer una línea de entrada, analizar la línea para extraer un comando y sus argumentos, así como ejecutar el comando con los argumentos especificados. El programa local de cliente FTP comienza y despliega un indicador para el usuario. Después del indicador, el usuario puede desplegar comandos como help, de la forma siguiente 19



ESPOCH-FIE-EIS

c:\> ftp ftp> help Los comandos se pueden abreviar. ! ? append ascii bell binary bye cd close

delete debug dir disconnect get glob hash help lcd

literal ls mdelete mdir mget mkdir mls mput open

prompt put pwd quit quote recv remotehelp rename rmdir

send status trace type user verbose

Para tener información sobre un comando , el usuario debe teclear (help comando) por ejemplo: ftp> help ls ls mostrar el contenido del directorio remoto Para ejecutar un comando, el usuario debe teclear el nombre del comando y en algunos casos una instrucción específica. Adjunta al comando ftp> bell Modo Bell activo

PARÁMETROS DE TRANSFERENCIA (no usuales) PORT (Puerto de datos) Especificación del ordenador-puerto, para el puerto que será usado en la conexión de datos. Hay valores por defecto, y bajo circunstancias normales, esta orden y su respuesta no son necesarias. Si se usa esta orden, el argumento es la unión de una dirección IP (32 bits) y un puerto TCP (16 bits). PASV (Pasivo) Solicita al servidor que escuche en un puerto de datos distinto del puerto por defecto, y espere a recibir una conexión en lugar de iniciar una al recibir una orden de transferencia. La respuesta a este comando incluye la dirección IP y el puerto donde este servidor está esperando a recibir la conexión. TYPE (tipo de representación) Especifica un tipo de representación: A - ASCII E - EBCDIC I - Imagen L - tamaño de byte STRU (Estructura de fichero) Un único carácter Telnet especificando una estructura de fichero de las descritas en la sección Representación de Datos y Almacenamiento: F -Fichero (sin estructurar en registros) R - Estructurado en registros P -Estructurado en páginas. La estructura por defecto es Fichero. MODE (Modo de transferencia) Un único carácter Telnet especificando un modo de transferencia: S - Flujo B - Bloque C - Comprimido 20



ESPOCH-FIE-EIS

COMANDOS DE SERVICIO RETR (Recuperar) Hace que el server-FTP transfiera una copia del fichero especificado en el nombre de ruta STOR (Almacenar) Hace que el servidor lea los datos transferidos por la conexión de datos y los guarde en un fichero en el servidor. Si el fichero especificado en el nombre de ruta existe en el servidor, su contenido se debe reemplazar con los datos recibidos. Se crea un fichero nuevo en el servidor si el indicado no existía ya. STOU (Almacenamiento único) Igual que STOR sólo que el fichero resultante se crea en el directorio actual con un nombre único para ese directorio APPE (Añadir) Si el fichero especificado en el nombre de ruta existe, los datos se añaden a ese fichero; si no, se crea un fichero nuevo en el servidor ALLO (Solicitar espacio) Reserva suficiente espacio de almacenamiento en el servidor para recibir el nuevo fichero. A continuación de esta orden se deberá indicar una orden STOR o APPE REST (Recomenzar) El argumento representa un marcador del servidor a partir del cual debe recomenzar la transferencia. La orden no realiza la transferencia del fichero, pero hace que el puntero de lectura o escritura del fichero se sitúe a continuación del punto indicado. A continuación de esta orden se debe enviar la orden de servicio FTP apropiada que hará que continúe la transferencia del fichero RNFR (Renombrar de) Indica el fichero que queremos cambiar de nombre en el servidor RNTO (Renombrar a) Especifica el nuevo nombre para el fichero indicado mediante el comando RNFR. Las dos órdenes seguidas hacen que el fichero cambie de nombre ABOR (abortar) Pide al servidor que interrumpa la orden de servicio FTP previa y cualquier transferencia de datos asociada. Hay dos posibles casos para el servidor al recibir esta orden: (1) la orden de servicio FTP está ya terminada, o (2) aún está en ejecución. En el primer caso, el servidor cierra la conexión de datos (si está abierta) y devuelve una respuesta 226 indicando que la orden de interrumpir se ha procesado correctamente. En el segundo caso, el servidor interrumpe el servicio FTP en proceso y cierra la conexión de datos, devolviendo una respuesta 426 para indicar que la solicitud de servicio terminó anormalmente. Luego, el servidor envía una respuesta 226 para indicar que la orden de interrumpir se ha procesado correctamente. DELE (Borrar) Borra en el servidor el fichero indicado en el nombre de ruta RMD (Borrar directorio) Borra en el servidor el directorio indicado MKD Borra el directorio del servidor especificado PWD Muestra el directorio de trabajo del servidor 21



ESPOCH-FIE-EIS

LIST Envía una listado de los ficheros a través del proceso de transferencia de datos pasivo. Si el nombre de ruta u otra agrupación de ficheros, el servidor debe transferir una lista de los ficheros en el directorio indicado. Si el nombre de ruta especifica un fichero, el servidor debería enviar información sobre el fichero. Si no se indica argumento alguno, implica que se quiere listar el directorio de trabajo actual o directorio por defecto NLST (Listar nombres) Envía listado de directorio desde el servidor. El nombre de ruta indica un directorio u otra agrupación de ficheros específica del sistema; si no hay argumento, se asume el directorio actual SITE (Parámetros del sistema) Proporciona servicios específicos propios del sistema del servidor que son fundamentales para transferir ficheros pero no lo suficientemente universales como para ser incluidos como órdenes en el protocolo SYST Devuelve el tipo de sistema operativo del servidor STAT El servidor devolverá información general del estado del proceso servidor FTP HELP El servidor envía información sobre la implementación del FTP NOOP (No operación) No hace nada más que provocar que el servidor envíe una respuesta OK A continuación (figura 3.2) se señalan modos de transferencia de archivos comunes

ARCHIVO Archivo de texto Hoja de cálculo Base de Datos Archivo de procesador de palabras Programa fuente Mensajes de correo Archivo de respaldo Archivo comprimido Archivo ejecutable Archivo postcript Documento de hipertexto Archivo de imagen (gif, jpeg, mpeg)

FORMA DE TRANSFERIR ASCII Binario Binario o ASCII Binario o ASCII ASCII ASCII Binario Binario Binario ASCII ASCII Binario

Figura 3.2 Formas de transferencia de archivos 3.4 SEGURIDAD EN LA TRANSFERENCIA DE ARCHIVOS La transferencia de archivos es uno de los servicios de Internet más utilizados. Con la web, este servicio se vuelve más fácil de utilizar y, por tanto, más difícil de 22



ESPOCH-FIE-EIS

controlar y asegurar. Así que, por razones de seguridad, las compañías conectadas a Internet a menudo bloquean el acceso a FTP y Telnet . Los firewalls y los servidores proxy pueden proteger su sitio al controlar el acceso a sitios FTP autenticados. La seguridad es uno de los oponentes más importantes de los servicios de FTP. Muchas compañías bloquean FTP, porque temen a los ataques de los hackers, o incluso a un intruso que intervenga las líneas de comunicación del sitio. El uso de FTP privado sobre Internet tiene algunas implicaciones de seguridad, el nombre de usuario y la contraseña se transmiten completamente visibles, de tal manera que cualquiera en la ruta entre su cliente y servidor pueden husmear su nombre de usuario y contraseña. Luego pueden usar su nombre y contraseña para obtener acceso no autorizado al servidor. Los datos que usted transfiere tampoco están encriptados y pueden ser vistos. Estos dos problemas pueden superarse al utilizar una versión de la Secure Socket Layer (SSL, Capa de Socket Seguro) del servidor FTP y el programa cliente. Cuando se utiliza SSL, todo el tráfico de red se encripta y el cliente y el servidor pueden utilizar autenticación sólida. Sin embargo, éste es un inconveniente; el protocolo SSL requiere un tercero independiente, por ejemplo una Certification Authority (CA, Autoridad de Certificación). Esta CA debe ser confiable para ambas partes y se utiliza en el establecimiento de la identidad verdadera del cliente y del servidor. En el caso de un navegador web, esta CA es una de las autoridades de "verdad", como VeriSign (para mayor información acerca de VeriSign, revise su sitio en (http: / /www. verisign.com). Sin embargo, para una conexión FTP dedicada entre un cliente y un servidor, esta CA puede ser cualquier organización que goce de la confianza entre las partes. Para solucionar este problema, hay varios productos proxy disponibles para incorporar un servidor FTP anónimo asegurado, el cual proporciona acceso de sólo lectura a una jerarquía de archivos limitada y protegida. Estos productos ofrecen un mecanismo de interfaz que habilita un directorio de entrada para escritura con el fin de permitir el envío de archivos a un firewall. Después se tiene acceso a las áreas de datos sólo desde la red interna. Si usted cuenta con un programa servidor de FTP no comprometa la seguridad general de los datos al compartir directorios entre este programa y el programa servidor de la web. Sin embargo, ningún usuario remoto deberá subir archivos que después puedan ser leídos o ejecutados por el servidor web. De otra forma, un hacker podría colocar un script CGI en el sitio FTP y después utilizar su navegador para solicitar el nuevo archivo cargado desde el servidor web, lo cual haría que el script se ejecutara y se omitiría la seguridad. Por lo tanto, limite todas las colocaciones de archivos del servicio FTP a un directorio que no pueda ser leído por los usuarios. Intente desarrollar una lista de control de configuración con base en el entorno, que tiene; no esté copiando recomendaciones de libros o de la web. En lugar de ello, úselas como una plantilla para personalizarlas según las necesidades y características del sistema de su compañía. A continuación se dan algunas 23



ESPOCH-FIE-EIS

sugerencias de configuración a considerar (añádalas a la lista dependiendo de sus necesidades):

Revise si su servidor FTP está corriendo correctamente Debe revisar en forma periódica si su servicio de servidor FTP se ejecuta de manera adecuada. Si usted está utilizando un servidor Windows 2000, puede intentar usar FTP en el sistema local al teclear la dirección IP de ciclo interno (loopback) desde la línea de comandos: ftp 127.0.0.1 

No debe existir diferencia entre la interacción con un servidor local así como con otros clientes Windows 2000 y la mayoría de los clientes Linux. Esto también puede utilizarse para determinar si los directorios, permisos, etc., en el servicio de servidor FTP están configurados apropiadamente.

Revise si la configuración de su servidor FTP es correcta Si encuentra problemas después de la prueba anterior, siguiendo las recomendaciones del CIAC, debería considerar los siguientes lineamientos cuando configure su servidor FTP: 

1) Asegúrese de que los archivos y directorios en el área de FTP no pertenecen al ftp del usuario, el cual es el ID de usuario de los usuarios anónimos. El riesgo es que cualquier cosa que le pertenezca puede ser modificada, reemplazada o eliminada por un usuario remoto en Internet. 2) Asegúrese de no colocar ninguna contraseña encriptada desde el archivo de contraseñas del sistema etc/passwd en el área de FTP anónimo ~ftp/etc/passwd. Un hacker puede obtener estas contraseñas encriptadas y también intentar desencriptarlas. Trate de no establecer los directorios o archivos para escritura para los usuarios anónimos. Aun cuando a algunos usuarios remotos les pueda parecer más fácil tener un directorio de entrada disponible para arrastrar archivos, los hackers pueden utilizar estas áreas para almacenar archivos de contrabando, lo cual puede incluir materiales con derechos de autor y otras cosas. 

Revise si la configuración de su FTP anónimo es segura

FTP anónimo puede ser un servicio valioso en su sitio, pero usted debe configurarlo correctamente y tomarse el tiempo para administrarlo. De lo contrario, estará abriendo puertas, invitando a entrar a intrusos, hackers y crackers. Como se alerta anteriormente, no todas las recomendaciones que se está listando aquí se aplicarán necesariamente a usted puesto que su entorno o plataforma de sistema podrían diferir. Así que, por favor, recuerde lo siguiente: a) Asegúrese de tener la última versión del daemon/servidor FTP. b) Cuando instale directorio FTP, asegúrese de que el directorio raíz de FTP anónimo, ~ftp, y sus subdirectorios no pertenecen a la cuenta FTP o incluso al mismo grupo. De lo contrario, como se remarcó previamente, éstos pueden ser

24



ESPOCH-FIE-EIS

puertas traseras para agresores, especialmente si el directorio no está protegido contra escritura. c) Su directorio raíz FTP y sus subdirectorios deben pertenecer a una raíz y sólo la raíz debe tener permisos para escribir en ella. De esta forma usted mantendrá su servicio FTP seguro. El siguiente ejemplo muestra una estructura de directorio de FTP anónimo: drwxr-xr-x 7 root system 512 Mar 1 15:17 ./ drwxr-xr-x 25 root system 512 Jan 4 11:30 ../ drwxr-xr-x 2 root system 512 Dec 20 15:43 bin/ drwxr-xr-x 2 root system 512 Mar 12 16:23 etc/ drwxr-xr-x 10 root system 512 Jun 5 10:54 pub/ Observe que los archivos y las bibliotecas, incluyendo aquellos utilizados por el daemon FTP y aquellos en ~ftp/bin y ~ftp/etc, deben tener las mismas protecciones que estos directorios: no pertenecer a FTP o estar en el mismo grupo y protegidos contra escritura. d) Nunca coloque archivos de sistema en el directorio ~ftp/etc. Permitirá un acceso abierto para que los agresores obtengan una copia de estos archivos. Tenga en mente que estos archivos son opcionales y no se usan para control de acceso. En lugar de ello, utilice una versión de prueba tanto de los archivos ~ftp/etc/passwd como de ~ftp/etc/group, que pertenecen a la raíz. De esta manera, el comando dir usará estas versiones de prueba para mostrar al propietario y los nombres de grupo de los archivos y directorios. e) Asegúrese de que el archivo ~/ftp/etc/passwd no contiene ningún nombre de cuenta que ya se encuentre en el archivo /etc/passwd del sistema. Incluya en estos archivos sólo la información necesaria para la jerarquía de FTP o los datos requeridos para mostrar al propietario y a los nombres de grupo. f) Si usted tiene un firewall instalado en funcionamiento, es posible para los hackers obtener acceso a su servidor FTP a través de la web, omitiendo el firewall. Ésta es una de las razones por las cuales algunos sitios preferirían tener el servidor web fuera del firewall. Por consiguiente, asegúrese de que el campo de contraseña ha quedado en blanco. El siguiente ejemplo muestra el uso de asteriscos (*) para limpiar el campo de contraseñas. El ejemplo se tomó de un archivo passwd en el área de FTP anónimo en cert.org: ssphwg:*:3144:20:Site Specific Policy Handbook Working Group:: cops:*:3271:20:COPS Distribution:: cert:*:9920:20:CERT: : tools:*:9921:20:CERT Tools:: ftp:*:9922:90:Anonymous FTP:: nist:*:9923:90:NIST Files:: 25



ESPOCH-FIE-EIS

Es importante comprender que existe un riesgo al permitir conexiones de FTP anónimo para escribir en su servidor. Por lo tanto, usted debe evaluar los riesgos involucrados antes de abrir la puerta. Además de los riesgos analizados con anterioridad (el almacenaje temporal para archivos de contrabando, etc.), un agresor podría generar una carga maliciosa de archivos interminables hasta el punto de provocar problemas de negación del servicio en su servidor.

3.5 EJERCICIOS 1. ¿Qué sucede en el FTP si la conexión TCP que se emplea para la transferencia de datos se interrumpe pero la conexión de control no? 2. ¿Cuál es la ventaja principal de utilizar conexiones separadas del TCP para el control y la transferencia de datos? (Pista: piense en condiciones anormales). 3. Experimente con el FTP para ver qué tan rápido puede transferir un archivo entre dos sistemas razonablemente grandes a través de una red de área local. Trate de experimentar cuando la red esté ocupada y cuando se encuentre "ociosa". Explique el resultado. 4. ¿Pruebe el FTP desde una máquina a usted mismo y después de una máquina a otra máquina en la misma red de área local. ¿Le sorprendió la proporción de datos transferidos? 5. ¿Tarda más tiempo o menos una transferencia binaria que una transferencia de texto? Para determinarlo, efectúe con FTP una transferencia de un archivo de texto 20 veces con modo textual y luego hágalo las mismas veces con modo binario. ¿Es diferente el tiempo de transferencia?. ¿Cuál es la razón del mayor tamaño de transferencia?. Compruebe la respuesta del con un analizador de red que capture el tráfico FTP durante una transferencia. 6. Experimente con FTP la transferencia de un archivo con datos arbitrarios (no textuales). Transfiera el archivo en modo binario y luego en modo textual. Compare el resultado con el archivo original. ¿Cómo cambia la transferencia textual el archivo?. 7. Experimente con el FTP de una LAN que transfiere un archivo grande. Compare el rendimiento logrado por el FTP con el ancho de banda ofrecido por la LAN. ¿Qué porcentaje del ancho de banda es de datos de usuario?. 8. En el ejercicio anterior, suponga que cada datagrama ocupa un cuadro de hardware completo y que la cabecera TCP es de 20 octetos y la cabecera IP también. Calcule el porcentaje del ancho de banda de hardware con cabeceras de protocolo.

26



ESPOCH-FIE-EIS

CAPITULO IV DNS 4.1 SISTEMA DE NOMBRES DE DOMINIO Teóricamente los programas pueden hacer referencia a hosts, buzones de correo y otros recursos mediante sus direcciones de red (por ejemplo, IP), a las personas se les dificulta recordar estas direcciones. Además, enviar correo electrónico a [email protected] significa que si el ISP u organización de pmoreno mueve el servidor de correo electrónico a una máquina diferente, la cual tiene una dirección IP diferente, la dirección de correo electrónico de pmoreno tiene que cambiar. Debido a esto, se introdujeron los nombres ASCII, con el fin de separar los nombres de máquina de las direcciones de máquina. De esta manera, la dirección de pmoreno podría ser algo como [email protected]. Sin embargo, la red misma sólo comprende direcciones numéricas, por lo que se requieren algunos mecanismos para convertir las cadenas ASCII a direcciones de red. En los tiempos de ARPANET, existía un archivo ( hosts.txt), en el que se listaban todos los hosts y sus direcciones IP. Cada noche, todos los hosts obtenían este archivo del sitio en el que se mantenía. En una red conformada por unas cuantas máquinas grandes de tiempo compartido, este método funcionaba razonablemente bien. Sin embargo, cuando miles de estaciones de trabajo se conectaron a la red, todos se dieron cuenta de que este método no podría funcionar eternamente. Por una parte, el tamaño del archivo crecería de manera considerable. Un problema aún más importante era que ocurrirían conflictos constantes con los nombres de los hosts a menos de que dichos nombres se administraran centralmente. Para resolver estos problemas, se inventó el DNS (Sistema de Nombres de Dominio). La esencia del DNS es la invención de un esquema de nombres jerárquico basado en dominios y un sistema de base de datos distribuido para implementar este esquema de nombres. El DNS se usa principalmente para relacionar los nombres de host y destinos de correo electrónico con las direcciones IP, pero también puede usarse con otros fines. El DNS se define en los RFCs 1034 y 1035. La forma en que se utiliza el DNS es la siguiente; para relacionar un nom bre con una dirección IP, un programa de aplicación llama a un procedimiento de biblioteca llamado resolvedor (figura 4.1), y le pasa el nombre como parámetro. El resolvedor envía un paquete UDP a un servidor DNS local, que después busca el nombre y devuelve la dirección IP al resolvedor, que entonces lo devuelve al solicitante. Una vez que tiene la dirección IP, el programa puede establecer una conexión TCP con el destino, o enviarle paquetes UDP. Generalmente los resolvedores que son conocidos como clientes puros trabajan en forma recursiva y los servidores DNS los hacen en forma iterativa. Teóricamente un solo servidor de nombres podría contener toda la base de datos DNS y responder a todas las consultas dirigidas a ella. En la práctica, este servidor estaría tan sobrecargado que sería inservible. Más aún, si llegara a caerse, la Internet completa se vendría abajo. 27



ESPOCH-FIE-EIS

Para evitar los problemas asociados a tener una sola fuente de información, el espacio de nombres DNS se divide en zonas no traslapantes. Por lo general, una zona tendrá un servidor de nombres primario, que obtiene su información de un archivo en su disco, y uno o más servidores de nombres secundarios, que obtienen su información del primario. Para mejorar la confiabilidad, algunos servidores de cierta zona pueden situarse fuera de la zona. El lugar donde se colocan los límites de las zonas dentro de una zona es responsabilidad del administrador de esa zona. Esta decisión se toma en gran medida con base en la cantidad de servidores de nombres deseados y su ubicación. “.“

Referencia a au au

Servidor DNS

Ref. a gov.au gov.au Ref. a space.gov.au space.gov.au Respuesta mars.space.gov.au

Pregunta

128.66.45.12

Respuesta Resolvedor

Figura 4.1 Utilización del DNS para relacionar un nombre con una dirección IP

4.2 ESPACIO DE NOMBRES DEL DNS Administrar un grupo grande y continuamente cambiante de nombres es un problema nada sencillo. En el sistema postal, la administración de nombres se hace requiriendo letras para especificar (implícita o explícitamente) el país, estado o provincia, ciudad y calle, y dirección del destinatario. El DNS funciona de la misma manera. Conceptualmente, Internet se divide en 200 dominios de nivel superior, cada uno de los cuales abarca muchos hosts. Cada dominio se divide en subdominios, los cuales, a su vez, también se dividen, y así sucesivamente. Todos estos dominios pueden representarse mediante un árbol, como se muestra en la figura 4.2. Las hojas del árbol representan los dominios que no tienen subdominios (pero que, por supuesto,

28



ESPOCH-FIE-EIS ESPOCH -FIE-EIS

contienen máquinas). Un dominio de hoja puede contener un solo host, o puede representar a una compañía y contener miles de hosts. Los dominios de nivel superior se dividen en dos categorías: genéricos y de país. Los dominios genéricos originales son com (comercial), edu (instituciones educativas), gov (el (el gobierno federal de Estados Unidos), int (ciertas (ciertas organizaciones internacionales), mil (las (las fuerzas armadas de Estados Unidos), net (proveedores (proveedores de red) y org (organizaciones (organizaciones no lucrativas). Los dominios de país incluyen una entrada para cada país, como se define en la ISO 3166 (ar Argentina, ca Canada, co Colombia, ec Ecuador, jp Japón, mx México, uk Gran Bretaña, etc). En noviembre de 2000, ICANN aprobó cuatro nuevos dominios de nivel superior y de propósito general: biz (negocios), info (información), name (nombres de personas) y pro (profesiones, como doctores y abogados). Además, se introdujeron otros tres nombres de dominio especializados de nivel superior a solicitud de ciertas industrias. Éstos son: aero (industria aeroespacial), coop (cooperativas) y museum (museos). En el futuro se agregarán otros dominios de nivel superior. 5

De País

Genérico

int

com sun

edu cisco

gov

org

mil acm

berkeley jack

jp

net ac

co ec

ieee

jill

epn espoch keio

nl oce

nec flits

vu cs fluit

Figura 4.2 Parte del espacio de nombres de dominio de Internet Obtener un dominio de segundo nivel, como nombre-de-compañía.com, es fácil; simplemente se necesita ir con el registrador del dominio de nivel superior correspondiente (com, en este caso) para ver si el nombre deseado está disponible y si no es la marca registrada de alguien más. Si no existe problemas, el solicitante paga una pequeña cuota anual y obtiene el nombre. Cada uno de los dominios se nombra por la ruta hacia arriba desde él a la raíz (sin nombre). Los componentes se separan con puntos. Por lo tanto, el departamento de ingeniería de Sun Microsystems podría utilizar eng.sun.com., en lugar de un nombre tipo UNIX como /com/sun/eng. Observe que esta asignación jerárquica significa que eng.sun.com. no entra en conflicto con un uso potencial de eng por ejemplo, eng.mit.edu., que podría usarse en el departamento de inglés de M.I.T. Los nombres de dominio pueden ser absolutos o relativos. Un nombre de dominio absoluto termina con un punto (por ejemplo, eng.sun.com.), y uno relativo no. Los nombres relativos tienen que interpretarse en algún contexto para determinar de 5

Tanembaum Andrew. Redes de computadoras. Pág. 581

29




manera única su significado verdadero. En ambos casos, un dominio nombrado hace referencia a un nodo específico del árbol y a todos los nodos por debajo de él. Los nombres de dominio no hacen distinción entre mayúsculas y minúsculas, por lo que edu, Edu y EDU significan significan lo mismo. Los nombres de componentes pueden ser de hasta 63 caracteres de longitud, y los de ruta completa de hasta 255 caracteres. En principio, los dominios pueden introducirse en el árbol de dos maneras diferentes. Por ejemplo, cs.yale.edu también podría estar listado bajo el dominio de país us como cs.yale.ct.us. Sin embargo, en la práctica, casi todas las organizaciones de Estados Unidos están bajo un dominio genérico, y casi todas las de fuera de Estados Unidos están bajo el dominio de su país. No hay ninguna regla que impida registrarse bajo dos dominios de nivel superior, pero pocas organizaciones lo hacen, excepto las multinacionales (por ejemplo, sony.com y sony.nl). Cada dominio controla cómo se asignan los dominios que están debajo de él. Por ejemplo, Japón tiene los dominios ac.jp y co.jp que son espejos de edu y com. Los Países Bajos no hacen esta distinción y ponen a todas las organizaciones directamente bajo ni. Por lo tanto, los siguientes tres son departamentos universitarios de informática; 1. cs.yale.edu (Universidad de Yaie, en Estados Unidos) 2. cs.vu.nl (Vrije (Vrije üniversiteit, en los Países Bajos) 3. cs.keio.ac.j.p (Universidad Keio, en Japón) Para crear un nuevo dominio, se requiere el permiso del dominio en el que se incluirá. Por ejemplo, si se inicia un grupo VLSI en Yale y quiere que se le conozca como vlsi.cs.yale.edu, requiere permiso de quien administra cs.yale.edu. De la misma manera, si se crea una universidad nueva, digamos la Universidad del Norte de Tulcán, debe solicitar al administrador del dominio edu que le asigne unt.edu. De esta manera se evitan los conflictos de nombres y cada dominio puede llevar el registro de todos sus subdominios. Una vez que se ha creado y registrado un nuevo dominio puede crear subdominios, como cs.unt.edu, sin obtener el permiso de nadie más arriba en el árbol. Los nombres reflejan los límites organizacionales, no las redes físicas. Por ejemplo, si los departamentos de informática e ingeniería eléctrica se ubican en el mismo edificio y comparten la misma LAN, de todas maneras pueden tener dominios diferentes.

4.3 REGISTROS DE RECURSOS Cada dominio, sea un host individual individual o un dominio de nivel superior, puede tener un grupo de registros de recursos asociados a él. En un host individual, individual, el registro de recursos más común es simplemente su dirección IP, pero también existen muchos otros tipos de registros de recursos. Cuando un resolvedor da un nombre de dominio al DNS, lo que recibe son los registros de recursos asociados a ese nombre. Por lo tanto, la función real del DNS es relacionar los dominios de nombres con los registros de recursos.

30




Un registro de recursos tiene cinco tuplas. Aunque éstas se codifican en binario por cuestión de eficiencia, en la mayoría de las presentaciones, los registros de recursos r ecursos se dan como texto ASCII, una línea por registro de recursos. El formato que usaremos es el siguiente:

Nombre_dominio Tiempo_de_vida Clase Tipo Valor El Nombre_dominio indica el dominio al que pertenece este registro. Por lo general, existen muchos registros por dominio y cada copia de la base de datos contiene información de muchos dominios. Por lo tanto, este campo es la clave primaria de búsqueda usada para atender las consultas. El orden de los registros de la base de datos no es significativo. El campo de Tiempo_de_vida es una indicación de la estabilidad del registro. La información altamente estable recibe un valor grande, como 86,400 (la cantidad de segundos en un día). La información altamente volátil recibe un valor pequeño, como 60 (1 minuto). El tercer campo de cada registro de recursos es Class . Para la información de Internet, siempre es IN. Para información que no es de Internet, se pueden utilizar otros códigos, pero en la práctica, éstos raramente se ven. El campo Tipo indica el tipo de registro de que se trata. En la figura 4.3 se listan los tipos más importantes.

Ti o SOA A MX

Si nific icaado Valor lor Inicio de autoridad Parámetros para esta zona Dirección IP de un host Entero de 32 bits Intercambio de correo Prioridad, dominio dispuesto a aceptar correo electrónico NS Servidor de nombres Nombre de un servidor ara este dominio CNAME Nombre canónico Nombre de dominio PTR Apuntador Alias de una dirección IP HINFO Descripción del host CPU y SO en ASCII TXT

Texto

Texto ASCII no interpretado

Figura 4.3 Principales tipos de registro de recursos DNS Un registro S OA proporciona el nombre de la fuente primaria de información sobre la zona del servidor de nombres, la dirección de correo electrónico de su administrador, un número de serie único y varias banderas y temporizadores. El tipo de registro más importante es el registro A (dirección) que contiene una dirección IP de 32 bits de algún host. Cada host de Internet debe tener cuando menos una dirección IP, para que otras máquinas puedan comunicarse con él. Algunos hosts tienen dos o más conexiones de red, en cuyo caso tendrán un registro de recursos tipo A por cada conexión de red (y, por lo tanto, por cada dirección IP).

31



ESPOCH-FIE-EIS

DNS se puede configurar para iterar a través de éstos, regresando el primer registro en la primera solicitud, el segundo registro en la segunda solicitud, y así sucesivamente. El siguiente tipo de registro más importante es MX , que especifica el nombre del dominio que está preparado para aceptar correo electrónico del dominio especificado. Se utiliza porque no todas las máquinas están preparadas para aceptar correo electrónico. Si alguien desea enviar correo electrónico a, por ejemplo, [email protected], el host emisor necesita encontrar un servidor de correo en microsoft.com que esté dispuesto a aceptar correo electrónico. El registro MX puede proporcionar esta información. Los registros NS especifican servidores de nombres. Por ejemplo, cada base de datos DNS normalmente tiene un registro NS por cada dominio de nivel superior, de modo que el correo electrónico pueda enviarse a partes alejadas del árbol de nombres. Los registros CNAME permiten la creación de alias. Por ejemplo, una persona familiarizada con los nombres de Internet en general que quiere enviar un mensaje a alguien cuyo nombre de inicio de sesión es paúl y que está en el departamento de informática del M.I.T., podría suponer que [email protected] funcionará. De hecho, esta dirección no funcionará, puesto que el dominio del departamento de informática del M.I.T. es lcs.mit.edu. Sin embargo, como servicio para la gente que no sabe esto, el M.I.T. podría crear una entrada CNAME para encaminar a la gente y a los programas en la dirección correcta. La entrada podría ser como la siguiente: cs.mit.edu 86400 IN CNAME lcs.mit.edu Al igual que CNAME, PTR apunta a otro nombre. Sin embargo, a diferencia de CNAME, que en realidad es sólo una definición de macro, PTR es un tipo de datos DNS normal, cuya interpretación depende del contexto en el que se encontró. En la práctica, PTR casi siempre se usa para asociar un nombre a una dirección IP a fin de permitir búsquedas de la dirección IP y devolver el nombre de la máquina correspondiente. Éstas se llaman búsquedas invertidas. Los registros HINFO permiten que la gente conozca el tipo de máquina y sistema operativo al que corresponde, un dominio. Por último, los registros TXT permiten a los dominios identificarse de modos arbitrarios. Ambos tipos de registro son para el provecho de los usuarios. Ninguno es obligatorio, por lo que los programas no pueden contar con que los recibirán (y probablemente no puedan manejarlos si los obtienen). Por último, llegamos al campo Valor . Este campo puede ser un número, un nombre de dominio o una cadena ASCII. La semántica depende del tipo de registro. En la tabla 4.1 se presenta una descripción corta de los campos de Valor para cada uno de los tipos principales de registro. Como ejemplo del tipo de información que podría encontrarse en la base de datos DNS de un dominio, vea la figura 4.4. En ésta se ilustra una parte de una base de

32



ESPOCH-FIE-EIS

datos (semihipotética) correspondiente al dominio cs.vu.nl. La base de datos contiene siete tipos de registros de recursos. La primera línea que esta comentada de la figura 4.4 da un poco de información básica sobre el dominio. Las siguientes dos líneas dan información textual sobre la localización del dominio. Luego están dos entradas que dan el primer y segundo lugar a donde se intentará entregar correo electrónico dirigido a [email protected]. Primero se intentará en la zephyr (una máquina específica). Si falla, a continuación se intentará en la top. ;Datos

autorizados correspondientes a cs.vu.nl

cs.vu.nl. cs.vu.nl. cs.vu.nl. cs.vu.nl. cs.vu.nl.

86400 86400 86400 86400 86400

IN IN IN IN IN

SOA TXT TXT MX MX

Star boss (9527,7200,7200,241920,86400) "Divisie Wiskunde en Informática." "Vrije Universiteit Amsterdam." 1 zephyr.cs.vu.nl. 2 top.cs.vu.nl.

flits. flits. flits. flits. flits. flits.

86400 86400 86400 86400 86400 86400 86400 86400

IN IN IN IN IN IN IN IN

HINFO A A MX MX MX CNAME CNAME

Sun Unix 130.37.16.112 192.31.231.165 1 flits.cs.vu.nl. 2 zephyr.cs.vu.nl. 3 top.cs.vu.nl. Star.cs.vu.ni Zephyr.cs.vu.nl

IN

A

130.37.56.201

IN IN IN

MX MX HINFO

1 rowboat 2 zephyr Sun Unix

IN

A

130.37,62.23

IN

HINFO

Mac MacOS

IN

A

192.31.231.216

IN

HINFO

"HP Laserjet IIISi" Proprietary

cs.vu.nl. cs.vu.nl. cs.vu.nl. cs.vu.nl. cs.vu.nl. cs.vu.nl. www. cs.vu.nl. ftp .cs.vu.nl. Rowboat

little -sister

Laserjet

Figura 4.4 Base de datos para cs.vu.nl. Después de la línea en blanco, que se agregó para hacer más clara la lectura, siguen líneas que indican que la flits es una estación de trabajo Sun que ejecuta UNIX, y dan sus dos direcciones IP. Después se indican tres posibilidades para manejar el correo electrónico enviado a flits.cs.vu.nl. La primera opción naturalmente es la flits misma, pero si está inactiva, Ia zephyr y la top son la segunda y tercera opciones, respectivamente. Luego viene un alias, www.cs.vu.nl, para que esta dirección pueda usarse sin designar una máquina específica. La creación de este alias permite a cs.vu.nl cambiar su servidor Web sin invalidar la dirección que la gente usa para llegar a él. Un argumento similar es válido para ftp.cs.vu.nl. Las siguientes cuatro líneas contienen una entrada típica de una estación de trabajo, en este caso, rowboat.cs.vu.nl. La información proporcionada contiene la dirección IP, los destinos de correo primarios y secundarios, así como información sobre la 33



ESPOCH-FIE-EIS

máquina. Luego viene una entrada para un sistema no UNIX incapaz de recibir correo por sí mismo, seguida de una entrada para una impresora láser que está conectada a Internet. Lo que no se muestra (y no está en este archivo) son las direcciones IP a usar para buscar los dominios de nivel superior. Éstas son necesarias para buscar hosts distantes pero, dado que no son parte del dominio cs.vu.nl, no están en este archivo. Tales direcciones son suministradas por los servidores raíz, cuyas direcciones IP están presentes en un archivo de configuración del sistema y se cargan en el caché del DNS cuando se arranca el servidor DNS. Hay aproximadamente una docena de servidores raíz esparcidos en todo el mundo, y cada uno conoce las direcciones IP de todos los servidores de dominio de nivel superior. Por lo tanto, si una máquina conoce la dirección IP de por lo menos un servidor raíz, puede buscar cualquier nombre DNS.

4.4 MAPEO INVERSO De lo que se ha visto DNS convierte los nombres de dominio en direcciones IP. Sin embargo en ciertos casos, es necesario realizar la conversión contraria; dada una dirección IP puede ser necesario determinar el nombre de dominio asociado. Internet cuenta con un dominio especial que permite realizar conversiones inversas, este dominio es in-addr.arpa. La forma de proceder para solucionar el problema es la siguiente como se explica mediante un ejemplo. La dirección IP 198.70.148.10 corresponde a mcp.com. Esto se puede resolver por que el dominio in-addr.arpa puede contener 256 dominios que corresponden al primer octeto de la dirección IP. Cada uno de ellos puede contener a su vez otros 256 subdominios correspondientes al segundo octeto. A su vez existen dos subniveles más de 256 subdominios correspondientes a los octetos tercero y cuarto de la dirección IP. El valor del registro correspondiente al cuarto octeto es el nombre del dominio que corresponde a la dirección IP. .

“ “

arpa in-addr 0 198

0

255

255

70

0 148 0 10

255

255

mcp.com

34



ESPOCH-FIE-EIS

Figura 4.5 Localización del nombre de dominio correspondiente a una dirección IP En la figura 4.5 se muestra el proceso para la dirección IP 198.70.148.10 donde para proceder a la búsqueda se reordena la representación decimal como una cadena con la forma siguiente: 10.148.70.198.in-addr.arpa.

4.5 FORMATO DE LOS MENSAJES DNS 0

16

31

Identificación Parámetro Número de solicitudes Número de respuestas Número de autoridad Número de adicional Sección de solicitudes Sección de respuestas Sección de autoridad Sección de información adicional

Figura 4.6 Formato de mensaje de servidor de nombre de dominio Cada mensaje comienza con un encabezado fijo que contiene los siguientes campos:

IDENTIFICACION: El cliente lo utiliza para confrontar las solicitudes con las respuestas. PARAMETRO: Especifica la operación solicitada y el código de respuesta, a continuación se proporciona la interpretación de los bits del campo. BIT 0

1 2 3 4 5 6 7 8 9 - 11 12

Significado Operación del primer bit: 0 Solicitud 1 Respuesta Tipo de solicitud : Estándar (nombre de dominio a dirección IP) (bit a 0) Inversa (dirección IP a nombre de dominio) (bit a 0) Obsoleto (bit en 0) Obsoleto (bit en 0) Activado si se tiene una respuesta autorizada Activado si el mensaje está truncado Activado si se desea recursión Activado si la recursión está disponible Reservado Tipo de respuesta (cuando el bit esta a 1) Sin error 35


13 14 15


ESPOCH-FIE-EIS

Error de formato en la solicitud Falla en el servidor El nombre no existe

NUMERO DE SOLICITUDES: proporciona el conteo de entradas que aparecen en la "sección de solicitudes " del mensaje. NUMERO DE RESPUESTAS: proporciona el conteo de entradas que aparecen en la "sección de respuestas " del mensaje. NUMERO DE AUTORIDAD: proporciona el conteo de entradas que aparecen en la "sección de autoridad " del mensaje. NUMERO DE ADICIONAL: proporciona el conteo de entradas que aparecen en la "sección de información adicional " del mensaje. SECCIÓN DE SOLICITUDES (question section): contiene las solicitudes para las que se desea una respuesta. El cliente llena sólo la sección de solicitud; el servidor devuelve la solicitud y la respuesta en su réplica. Cada solicitud consiste en un query domain name (solicitud de nombre de dominio} seguido por los campos query type (tipo de solicitud) y query class, (clase de solicitud) como se muestra en la figura 4.7. Solicitud de nombre de dominio Tipo de solicitud

Clase de solicitud

Figura 4.7 Formato de entrada de información en la sección de solicitud Aun cuando el campo s olic itud de nombre de dominio tiene una longitud variable, pero debido a la representación interna de los nombres de dominio hace posible, para el receptor, conocer la longitud exacta. El campo tipo de solicitud codifica el tipo de solicitud (por ejemplo, si la solicitud se refiere a un nombre de máquina o a una dirección de correo). El campo clas e de solicitud permite que los nombres de dominio se utilicen para objetos arbitrarios debido a que los nombres oficiales de Internet son sólo de una clase. Debe notarse que, aun cuando el diagrama en la figura 4.5 sigue la convención de mostrar los formatos en múltiplos de 32 bits, el campo query domain name puede contener un número arbitrario de objetos. No se utilizan rellenos. Además, los mensajes hacia o desde un servidor de nombres de dominio pueden contener un número impar de octetos. En un mensaje de servidor de nombres de dominio, cada uno de los campos answer s ection , (sección de respuestas) authority section (sección de autoridad) y de la

36



ESPOCH-FIE-EIS

additional information section (sección de información adicional) consiste en un conjunto de registros de recursos que describen los nombres de dominio y las transformaciones. Cada registro de recurso describe un nombre. La figura 4.8 muestra el formato.

Recursos de nombre de dominio Tipo Clase Tiempo límite de duración Longitud de datos de recurso Datos de recurso ..............

Figura 4.8 Formato de un registro de recurso devuelto por el servidor DNS El campo resource domain name (recurso de nombre de dominio) contiene el nombre de dominio al que este registro de recursos se refiere. El campo type (tipo) especifica el tipo de datos incluidos en el registro de recurso. El campo class (clase) especifica la clase de datos. El campo time to live (tiempo límite de duración) contiene un entero que especifica el número de segundos que la información en este registro de recursos se mantendrá en memoria inmediata. Ésta es utilizada por clientes que han solicitado la asignación de un nombre y desean capturar el resultado. Los dos últimos campos contienen el resultado de la asignación, con el campo resource data length (longitud de datos de recursos) especifica el conteo de octetos en el campo res ource data (datos de recurso).

4.6 ASIGNACIÓN DE NOMBRES DE FORMA SEGURA Supongamos que Giovanna desea visitar el sitio Web de Xavier, digita el URL de Xavier en su navegador y segundos más tarde, aparece una página Web. Pero, ¿es la de Xavier?. Tal vez Silvana podría estar haciendo sus viejos trucos nuevamente. Por ejemplo, tal vez esté interceptando y examinando todos los paquetes salientes de Giovanna. Cuando captura una solicitud GET de HTTP dirigida al sitio Web de Xavier, puede ir ella misma a dicho sitio para obtener la página, modificarla como lo desea y regresar la página falsa a Giovanna, la cual no sería extraña para Giovanna. Peor aún, Silvana podría recortar los precios de la tienda electrónica de Xavier para hacer que los precios de los productos parezcan muy atractivos, con lo que engañaría a Giovanna para que enviara su número de tarjeta de crédito a "Xavier" para comprar algo de mercancía. Una desventaja de este clásico ataque de hombre en medio es que Silvana tiene que estar en una posición para interceptar el tráfico saliente de Giovanna y falsificar su tráfico entrante. En la práctica, tiene que intervenir la línea telefónica de Giovanna o la de Xavier, puesto que intervenir la red dorsal de fibra es mucho más difícil. Aunque intervenir la línea es ciertamente posible, también significa mucho trabajo, y

37



ESPOCH-FIE-EIS

aunque Silvana es inteligente, también es floja. Además, hay formas más fáciles de engañar a Giovanna.

4.6.1 FALSIFICACIÓN DE DNS Pensemos que Silvana es capaz de violar el sistema DNS, tal vez sólo el caché DNS del ISP de Giovanna, y reemplazar la dirección IP de Xavier (digamos, 36.1.2.3) con la suya propia (digamos, 42.9.9.9). Eso lleva al siguiente ataque. En la figura 4.9(a) se ilustra la forma en que se supone debe trabajar. Aquí (1) Giovanna pide al DNS la dirección IP de Xavier, (2) la obtiene 36.1.2.3, (3) le pide a Xavier su página de inicio GET indice.html, y (4) también obtiene la página de inicio de Xavier. Después de que Silvana ha modificado el registro DNS de Xavier para contener su propia dirección IP en lugar de la de Xavier, obtenemos la situación de la figura 4.9(b). Aquí, cuando Giovanna busca la dirección IP de Xavier, obtiene la de Silvana 42.9.9.9, por lo que todo su tráfico dirigido a Xavier va a parar a las manos de Silvana. Ahora, ella puede iniciar un ataque de hombre en medio sin tener que intervenir ninguna línea telefónica. En su lugar, tiene que irrumpir en un servidor DNS y cambiar un registro, lo cual es más fácil. Sevidor DNS violado

Sevidor DNS 1

Servidor Web de Xavier

2

Giovanna

3

1

2

Giovanna

4

(a)

Servidor Web de Silvana 3 4

(b)

Figura 4.9 (a) Situación normal (b) Ataque basado en la violación del DNS ¿Cómo engaña Silvana al DNS? Parece bastante fácil. Brevemente Silvana puede engañar al servidor DNS en el ISP de Giovanna para que envíe una consulta a fin de encontrar la dirección de Xavier. Desgraciadamente, puesto que el DNS utiliza ÜDP, el servidor DNS no puede verificar quién proporcionó la respuesta. Silvana puede explotar esta propiedad falsificando la respuesta esperada e introduciendo una dirección IP falsa en el caché del servidor DNS. Por simplicidad, supondremos que el ISP de Giovanna inicialmente no tiene una entrada para el sitio Web de Xavier, Xavier.com. Si la tiene, Silvana puede esperar hasta que expire y probar otra vez (o utilizar otros trucos).

38



ESPOCH-FIE-EIS

Silvana inicia el ataque enviando una solicitud de respuesta al ISP de Giovanna preguntando por la dirección IP de Xavier.com. Puesto que no hay entrada para este nombre DNS, el servidor de caché pide al servidor de nivel superior el dominio com para obtener uno. Sin embargo, Silvana evade al servidor com y regresa una respuesta falsa diciendo: "Xavier.com es 42.9.9.9"; sin embargo, esta dirección IP es la de ella. Si la respuesta falsa de Silvana llega primero al ISP de Giovanna, se almacenará en caché y la respuesta real se rechazará como respuesta no solicitada de una consulta que ya no está pendiente. Engañar a un servidor DNS para que instale una dirección IP falsa se conoce como falsificación de DNS. Un caché que contiene una dirección IP intencionalmente falsa como ésta se conoce como caché envenenado. Por lo general, las cosas no son tan sencillas. Primero, el ISP de Giovanna verifica si la respuesta lleva la dirección de origen IP correcta del servidor de nivel superior. Pero debido a que Silvana puede colocar lo que quiera en ese campo IP, puede vencer esa prueba con facilidad puesto que las direcciones IP de los servidores de nivel superior tienen que ser públicas. Segundo, para permitir que los servidores DNS digan cuál respuesta corresponde a cual solicitud, todas las solicitudes llevan un número de secuencia. Para falsificar el ISP de Giovanna, Silvana tiene que conocer su número de secuencia actual. La forma más fácil para que Silvana conozca el número de secuencia actual es que ella misma registre un dominio, digamos, Silvana-la-intrusa.com. Supongamos que su dirección IP también es 42.9.9.9. Silvana también crea un servidor DNS para su nuevo dominio, dns.Silvana-la-intrusa.com. El servidor DNS utiliza la dirección IP 42.9.9.9 de Silvana, puesto que ésta sólo tiene una computadora. Ahora Silvana tiene que informarle al ISP de Giovanna sobre su servidor DNS. Esto es fácil. Todo lo que tiene que hacer es pedir foobar.Silvana-la-intrusa.com al IPS de Giovanna, la que causará que dicho ISP pregunte al servidor com de nivel superior quién proporciona el nuevo dominio de Silvana. Una vez que tiene seguro el dns. Silvana-la-intrusa.com en el caché del ISP de Giovanna, el ataque real puede comenzar. Silvana ahora solicita www.Silvana-laintrusa.com al ISP de Giovanna. Como es natural, el ISP envía al servidor DNS de Silvana una consulta en la que se lo pide. Dicha consulta lleva el número de secuencia que Silvana está buscando. Rápidamente, Silvana pide al ISP de Giovanna que busque a Xavier. Silvana responde de inmediato su propia pregunta enviando al ISP una respuesta falsificada, supuestamente del servidor com de nivel superior que dice: "Xavier.com es 42.9.9.9". Esta respuesta falsificada lleva un número de secuencia, un número más que el que acaba de recibir. Mientras esté allí, puede enviar una segunda falsificación con un número de secuencia incrementado en dos, y tal vez una docena más con números de secuencia crecientes. Uno de ellos está obligado a coincidir. El resto simplemente se elimina. Cuando llega la respuesta falsificada de Giovanna, se almacena en caché; cuando la respuesta real viene más tarde, se rechaza puesto que ninguna consulta está pendiente. Cuando Giovanna busca a.Xavier.com, se le indica que utilice 42.9.9.9, la dirección de Silvana. Ésta ha realizado un ataque hombre en medio desde la comodidad de su casa. En la figura 4.10 se ilustran los diversos pasos para este ataque. Para

39



ESPOCH-FIE-EIS

empeorar las cosas, ésta no es la única forma de falsificar un DNS. Hay muchas otras formas.

Sevidor DNS violado 7 5

Silvana

1 2 3 4 6

1. Busca foobar.silvana-la-intrusa.com (para obligarlo a entrar al caché del ISP 2. Busca www.silvana-la-intrusa.com (para obtener el siguiente número de secuencia del ISP) Caché del 3. Solicita www.silvana-la intrusa.com IPS de (lleva el siguiente número de secuencia del ISP,n) Giovanna 4. Rápidamente busca xavier.com (para obligar a que el ISP consulte al servidor com en el paso 5) 5. Consulta legítima para xavier.com con seq=n+1 6. Respuesta falsificada de Silvana: Xavier es 42.9.9.9, seq = n+1 7. Respuesta real (rechazada, demasiado tarde)

Figura 4.10 Forma en que Silvana falsifica el ISP de Giovanna

4.6.2 DNS SEGURO Este ataque específico puede frustrarse al hacer que los servidores DNS utilicen IDs aleatorios en cualquiera de las consultas en lugar de sólo contar, pero parece que cada vez que se tapa un hoyo, otro se destapa. El problema real es que el DNS se diseñó en la época en la que Internet era una herramienta de investigación para algunos cientos de universidades y ni Giovanna, ni Xavier, ni mucho menos Silvana fueron invitados a la fiesta. En ese entonces la seguridad no era un problema; hacer que Internet funcionara era el problema. Con los años, el entorno ha cambiado radicalmente, por lo que en 1994 el IETF estableció un grupo funcional para hacer que DNS fuera seguro. Este proyecto se conoce como DNSsec (seguridad DNS); su salida se presenta en el RFC 2535. Desgraciadamente, DNSsec aún no se ha distribuido por completo, por lo que numerosos servidores DNS aún son vulnerables a ataques de falsificación. DNSsec es en concepto muy sencillo. Se basa en la criptografía de clave pública. Cada zona DNS (en el sentido de la figura 4.2) tiene un par de claves pública/privada. Toda la información enviada por un servidor DNS se firma con la clave privada de la zona originaria, por lo que el receptor puede verificar su autenticidad. DNSsec ofrece tres servicios fundamentales: 1. Prueba dónde se originaron los datos. 40



ESPOCH-FIE-EIS

2. Distribución; de la clave publica. 3. Autenticación de transacciones y solicitudes. El servicio principal es el que se lista primero, el cual verifica que los datos que se están regresando ha sido probado por el dueño de la zona. El segundo es útil para almacenar y recuperar de manera segura claves públicas. El tercero es necesario para proteger contra ataques de repetición y falsificación. Observe que la confidencialidad no es un servicio ofrecido puesto que toda la información en el DNS se considera como pública. Puesto que la planificación en etapas del DNSsec lleva algunos años, es esencial la capacidad que tienen los servidores consientes de la seguridad para interactuar con los servidores que no están conscientes de ella, lo cual implica que el protocolo no puede cambiarse. Veamos ahora algunos de los detalles. Los registros DNS están agrupados en conjuntos llamados RRSets (Conjuntos de Registro de Recursos), en los que todos los registros tienen el mismo nombre, clase y tipo en un conjunto. Un RRSet puede contener múltiples registros A; por ejemplo, si un nombre DNS se resuelve en una dirección IP primaria y una secundaria. Los RRSets se extienden con varios nuevos tipos de registro (que se analizan a continuación). A cada RRSet se le aplica un hash de manera criptográfica (por ejemplo, utilizando MD5 o SHA-1). La clave privada de la zona firma (por ejemplo, utilizando RSA) el hash. La unidad de transmisión a clientes es el RRSet firmado. Al momento de la recepción de un RRSet firmado, el cliente puede verificar si fue firmado por la clave privada de la zona originaria. Si la firma concuerda, se aceptan los datos. Puesto que cada RRSet contiene su propia firma, los RRSets pueden cambiarse en cualquier lugar, incluso en servidores no confiables, sin poner en peligro la seguridad. DNSsec introduce varios tipos nuevos de registros. El primero de éstos es el registro K E Y . Estos registros mantienen la clave pública de una zona, usuario, host u otro personaje principal, el algoritmo criptográfico utilizado para firmar, el protocolo utilizado para transmisión y otros bits. La clave pública se almacena tal como está. Los certificados X.509 no se utilizan debido a su volumen. El campo de algoritmo contiene un 1 para las firmas MD5/RSA (la opción preferida) y otros valores para otras combinaciones. El campo de protocolo puede indicar el uso de IPsec y otros protocolos de seguridad, si es que hay. S IG es el segundo nuevo tipo de registro. Contiene el hash firmado de acuerdo con el algoritmo especificado en el registro KEY. La firma se aplica a todos los registros del RRSet, incluyendo a cualquiera de los registros KEY presentes, pero excluyéndose a sí mismo. También contiene la fecha en la que la firma comienza su periodo de validación y cuando ésta expira, así como el nombre de quien firma y algunos otros elementos.

El diseño de DNSsec tiene la característica de que es posible mantener sin conexión una clave privada de una zona. Una o dos veces al día, el contenido de una base de datos de una zona puede transportarse de manera manual (por ejemplo, en CDROM) a una máquina desconectada en la que se localiza una clave privada. Todos los RRSets pueden firmarse ahí y los registros SIG producidos de esa manera 41



ESPOCH-FIE-EIS

pueden transportarse al servidor primario de la zona en CD-ROM. De esta manera, la clave privada puede almacenarse en un CD-ROM guardado en forma segura excepto cuando se inserta en la máquina desconectada para firmar los nuevos RRSets del día. Después de que se termina el proceso de firma, todas las copias de la clave se eliminan de la memoria y el disco y el CD-ROM son guardados. Este procedimiento reduce la seguridad electrónica a seguridad física, algo que las personas saben cómo tratar. Este método de prefirmar los RRSets aumenta la velocidad de manera considerable el proceso de responder consultas puesto que no es necesario realizar criptografía sobre la marcha. La desventaja consiste en que se necesita una gran cantidad de espacio en disco para almacenar todas las claves y firmas en las bases de datos DNS. Algunos registros incrementarán diez veces el tamaño debido a la firma. Cuando un proceso de cliente obtenga un RRSet firmado, debe aplicar la clave pública de la zona originaria para desencriptar el hash, calcular el hash mismo y comparar los dos valores. Si concuerdan, los datos se consideran válidos. Sin embargo, este procedimiento asume la manera de cómo obtiene el cliente la clave pública de la zona. Una forma es adquirirla de un servidor confiable, utilizando una conexión segura (por ejemplo, utilizando IPsec). Sin embargo, en la práctica, se espera que los clientes serán preconfigurados con las claves públicas de todos los dominios de nivel superior. Si Giovanna ahora desea visitar el sitio Web de Xavier, puede pedir al DNS el RRSet de Xavier.com, que contendrá su dirección IP y un registro KEY que contiene la clave pública de Xavier. Este RRSet será firmado por el dominio com de nivel superior, por lo que Giovanna puede verificar fácilmente su validez. Un ejemplo de lo que podría contener este RRSet se muestra en la figura 4.11.

Nombre de dominio Xavier.com Xavier.com Xavier.com

Tiempo de Clase vida 86400 IN 86400 IN 86400 IN

Tipo A KEY SIG

Valor 36.1.2.3 36827937B73F731029CE2737D 869475038B848F5272E53930C

Figura 4.11 Un Rrset para Xavier.com. El registro KEY es la clave pública de Xavier. EL registro SIG es el hash firmado del servidor com de nivel superior de los registros A y KEY para verificar la autenticidad. Una vez que Giovanna tiene una copia verificada de la clave pública de Xavier, puede pedir al servidor DNS de Xavier la dirección IP de www.Xavier.com. La clave privada de Xavier firmará este RRSet, a fin de que Giovanna pueda verificar la firma del RRSet que Xavier regresa. Si Silvana hace algo para inyectar un RRSet falso en cualquiera de los caches, Giovanna puede detectar fácilmente su falta de autenticidad porque el registro SIG contenido será incorrecto. Sin embargo, DNSsec también proporciona un mecanismo criptográfico para enlazar una respuesta a una consulta específica, a fin de evitar el tipo de falsificación utilizado por Silvana en la figura 4.10. Esta medida (opcional) de antifalsificación 42



ESPOCH-FIE-EIS

agrega a la respuesta un hash del mensaje de consulta firmado con la clave privada del receptor. Puesto que Silvana no conoce la clave privada del servidor com de nivel superior, no puede falsificar una respuesta a una consulta que el ISP de Giovanna haya enviado a dicho servidor. Ciertamente Silvana puede conseguir que su respuesta regrese primero, pero será rechazada debido a la firma inválida sobre la consulta con hash. DNSsec también soporta algunos otros tipos de registros. Por ejemplo, el registro CERT puede utilizarse para almacenar certificados (por ejemplo, X.509). Este registro ha sido proporcionado porque algunas personas desean cambiar un DNS en una PKI. Si esto realmente sucede, está por verse.

4.7 EJERCICIOS 1. DNS utiliza UDP en lugar de TCP. Si se pierde un paquete DNS, no hay recuperación automática. ¿Esto causa un problema, y si es así, .cómo se resuelve? 2. Además de ser propensos a perderse, los paquetes UDP tienen una longitud máxima, potencialmente tan baja como 576 bytes. ¿Qué pasa cuando un nombre DNS que se va a buscar excede esta longitud? ¿Se puede enviar en dos paquetes? 3. ¿Una máquina con un solo nombre DNS puede tener múltiples direcciones IP? ¿Cómo puede ocurrir esto? 4. ¿Una computadora puede tener dos nombres DNS que pertenecen a dominios de nivel superior diferentes? De ser así, dé un ejemplo ra zonable. De lo contrario, explique por qué no. 5. ¿cuál es la razón para que cada servidor de nombres deba conocer la dirección IP de su padre, en lugar del nombre de dominio del mismo? 6. Lea el estándar y encuentre cómo utiliza el sistema de nombres de dominio registros SOA. 7. El sistema de nombres de dominio de Internet puede adaptarse también a los nombres de buzones. Averigüe cómo. 8. El estándar sugiere que, cuando un programa necesita encontrar el nombre de dominio asociado con una dirección IP, primero debe enviar una solicitud inversa al servidor local y, después, utilizar el dominio in-addr. arpa sólo si éste falla. ¿Por qué? 9. ¿Cómo podría adaptar las abreviaturas a un esquema de nombres de dominio? Como ejemplo, muestre dos localidades que estén registradas bajo . edu y bajo un servidor de nivel superior. Explique cómo trata cada localidad cada tipo de abreviatura. 10. Lea los RFC sobre el sistema de nombres de dominio. ¿Cuáles son los valores máximo y mínimo que un servidor DNS puede almacenar en el campo TIMETO-LIVE de un registro de recurso? 11. ¿Debería el sistema de nombres de dominio permitir solicitudes que cumplan con sus requisitos básicos parcialmente (es decir, que utilicen comodines como parte del nombre)? ¿Por qué sí o por qué no? 12. La Institución educativa decidió colocar la siguiente entrada de registro de recurso de tipo A en su servidor de nombre de dominio: 43



ESPOCH-FIE-EIS

13. localhost.espoch.edu.ec 127.0.0.1 14. Explique qué podría suceder si una localidad remota tratara de ejecutar una función ping hacia una máquina con un nombre de dominio localhost.espoch.edu.ec 15. Trace la jerarquía de dominios de su Institución y muestre su división en servidores. Use un monitor de red para observar el tráfico en la Internet cuando un host solicita un nombre de dominio. ¿Cuántos datagramas viajan entre los servidores remotos? Repita cinco veces el experimento del ejercicio anterior. ¿Qué observa? 16. ¿Funciona el dominio in-addr.arpa con las computadoras de su sitio? 17. Mediante un programa como nslookup pruebe las direcciones IP de las computadoras de su organización con varios tipos DNS. Pruebe nombres como www.

18. El programa nslookup permite al usuario especificar la consulta al hacer una solicitud DNS. Intente varias consultas con los nombres de las computadoras de su sitio para ver si su organización tiene un nombre de dominio que resuelva hacia una dirección IP diferente cuando cambia el tipo de consulta.

44



ESPOCH-FIE-EIS

CAPITULO V CORREO ELECTRONICO 5.1 ASPECTOS DEL CORREO ELCTRONICO El correo electrónico, o e-mail, ha existido por más de dos décadas. Antes de 1990, se utilizaba principalmente en ambientes académicos. En la década de 1990, se dio a conocer al público y creció en forma exponencial al punto que el número de mensajes de correo electrónico enviados por día ahora es mayor que el número de cartas por correo normal. El correo electrónico está lleno de abreviaturas, símbolos ASCII llamados caritas o símbolos de emociones en sus mensajes de correo electrónico. Algunos de los más interesantes se listan en la Figura 5.1; para ver con mayor claridad, gire el texto 90 grados en dirección de las manecillas del reloj.

Emotico Significado Emotico Significado Emotico Significado :-) Estoy feliz =|:-) Abe Lincoln :+) Nariz grande :-(

Estoy =):-) triste/enojado

Tío Sam

:-|

Estoy apático *<:-)

Santa Claus :- {)

Con bigote

-)

Estoy <:-( guiñando un ojo Estoy (-: gritando

Bobo

#:-)

Peinado yuppy

Zurdo

8-)

Con gafas

:-(0) :-(*)

Estoy vomitando

:-)X

:-))

Hombre con C:-) moño

Realmente feliz

Inteligente

Figura 5.1 Algunos emoticonos Los primeros sistemas de correo electrónico consistían en protocolos de transferencia de archivos, con la convención de que la primera línea de cada mensaje (es decir, archivo) contenía la dirección del destinatario. A medida que pasó el tiempo, las limitaciones de este enfoque se hicieron obvias. Algunas de las quejas eran:6 1. El envío de un mensaje a un grupo de personas era laborioso. Los administradores con frecuencia necesitaban esta facilidad para enviar memorandos a todos sus subordinados.

6

Tanembaum Andrew. Redes de computadoras. Pág. 589

45



ESPOCH-FIE-EIS

2. Los mensajes no tenían estructura interna, lo que dificultaba el proceso por computadora. Por ejemplo, si un mensaje reenviado se incluía en el cuerpo de otro mensaje, era difícil extraer la parte reenviada del mensaje recibido. 3. El originador (remitente) nunca sabía si el mensaje había llegado o no. 4. Si alguien planeaba ausentarse por un viaje de negocios durante varias semanas y quería que todo el correo entrante fuera manejado por su secretaria, esto no era fácil de arreglar. 5. La interfaz de usuario estaba mal integrada al sistema de transmisión, pues requería que el usuario primero editara un archivo, luego saliera del editor e invocara el programa de transferencia de archivos. 6. No era posible crear y enviar mensajes que contuvieran una mezcla de texto, dibujos, facsímiles y voz. A medida que se incrementó la experiencia, se propusieron sistemas de correo electrónico más elaborados. En 1982, se publicaron las propuestas de correo electrónico de ARPANET como el RFC 821 (protocolo de transmisión) y el RFC 822 (formato de mensaje). Las revisiones menores, los RFCs 2821 y 2822, se han vuelto estándares de Internet, pero todas las personas aún se refieren al correo electrónico de Internet como el RFC 822.

5.2 ARQUITECTURA Y SERVICIOS El correo electrónico consiste en dos subsistemas: los agentes de usuario, que permiten a la gente leer y enviar correo electrónico, y los agentes de transferencia de mensajes (figura 5.2), que mueven los mensajes del origen al destino. Los agentes de usuario son programas locales que proporcionan un método basado en comandos, en menús o en una interfaz gráfica para interactuar con el sistema de correo electrónico. Los agentes de transferencia de mensajes son por lo común demonios (daemons) del sistema que operan en segundo plano y mueven correo electrónico a través del sistema. CLIENTE

SERVIDOR

Agente de usuario

Puerto

Agente de transferencia de mensaje

Servidor del destinatario

Buzón Puerto 25

TCP

TCP

IP

IP

RED TCP/IP

46



ESPOCH-FIE-EIS

Figura 5.2 Partes del software de correo electrónico Por lo general, los sistemas de correo electrónico desempeñan cinco funciones básicas, como se describe a continuación. La redacción se refiere al proceso de crear mensajes y respuestas. Aunque es posible utilizar cualquier editor de texto para el cuerpo del mensaje, el sistema mismo puede proporcionar asistencia con el direccionamiento y los numerosos campos de encabezado que forman parte de cada mensaje. Por ejemplo, al contestar un mensaje, el sistema de correo electrónico puede extraer la dirección del remitente e insertarla en forma automática en el lugar adecuado de la respuesta. La transferencia se refiere a mover mensajes del remitente al destinatario. En gran medida, esto requiere establecer una conexión con el destino o alguna máquina intermedia, enviar el mensaje y liberar la conexión. El sistema de correo electrónico debe hacer esto en forma automática, sin molestar al usuario. La generación del informe tiene que ver con indicar al remitente lo que ocurrió con el mensaje: ¿se entregó, se rechazó o se perdió?. Existen muchas aplicaciones en las que la confirmación de la entrega es importante y puede incluso tener una aplicación legal. La visualización de los mensajes de entrada es necesaria para que la gente pueda leer su correo electrónico. A veces se requiere cierta conversión o debe invocarse un visor especial, por ejemplo, si el mensaje es un archivo PostScript o voz digitalizada. Algunas veces también se intentan conversiones y formateo sencillos. La disposición es el paso final y tiene que ver con lo que el destinatario hace con el mensaje una vez que lo recibe. Las posibilidades incluyen tirarlo antes de leerlo, desecharlo después de leerlo, guardarlo, etcétera. También debe ser posible recuperar y releer mensajes guardados, reenviarlos o procesarlos de otras maneras. Además de estos servicios básicos, la mayoría de los sistemas de correo electrónico, especialmente los corporativos internos, proporcionan una gran variedad de características avanzadas. Brevemente mencionaremos algunas de éstas. Cuando la gente se muda, o cuando está lejos durante cierto tiempo, podría querer el reenvío de su correo electrónico, por lo que el sistema debe ser capaz de hacer esto de manera automática. La mayoría de los sistemas permite a los usuarios crear buzones de correo para almacenar el correo entrante. Se requieren comandos para crear y destruir buzones de correo, inspeccionar el contenido de los buzones, insertar y borrar mensajes de los buzones, etcétera. Los gerentes corporativos con frecuencia necesitan enviar un mensaje a cada uno de sus subordinados, clientes o proveedores. Esto da pie al concepto de lista de correo, que es una lista de direcciones de correo electrónico. Cuando se envía un mensaje a la lista de correo, se entregan copias idénticas a todos los de la lista.

47



ESPOCH-FIE-EIS

Otras características avanzadas son copias ocultas, correo electrónico de alta prioridad, correo electrónico secreto (es decir, encriptado), destinatarios alternos si el primario no está disponible y la capacidad de que las secretarias manejen el correo electrónico de su jefe. En la actualidad, el correo electrónico se usa ampliamente en la industria para la comunicación intracompañía. Permite que los empleados remotos cooperen en proyectos complejos, incluso si están en otros husos horarios. Al eliminar la mayoría de las señales asociadas al rango, edad y género, los debates realizados por correo electrónico tienden a enfocarse principalmente en las ideas, no en el status corporativo. Una idea clave de todos los sistemas modernos de correo electrónico es la distinción entre el sobre y su contenido. El sobre encapsula el mensaje; contiene toda la información necesaria para transportar el mensaje, como dirección de destino, prioridad y nivel de seguridad, la cual es diferente del mensaje mismo. Los agentes de transporte del mensaje usan el sobre para enrular, al igual que la oficina postal. El mensaje dentro del sobre, contiene dos partes: el encabezado y el cuerpo del mensaje. El encabezado contiene información de control para los agentes de usuario. El cuerpo es por completo para el destinatario humano.

5.3 AGENTE DE USUARIO Un agente de usuario normalmente es un programa (a veces llamado lector de correo) que acepta una variedad de comandos para redactar, recibir y contestar los mensajes, así como para manipular los buzones de correo. Algunos agentes de usuario tienen una interfaz elegante operada por menús o por iconos que requiere un ratón, mientras que otros esperan comandos de un carácter desde el teclado. Funcionalmente, ambos son iguales. Algunos sistemas son manejados por menús o por iconos, pero también tienen métodos abreviados de t eclado.

Envío de correo electrónico Para enviar un mensaje de correo electrónico, el usuario debe proporcionar el mensaje, la dirección de destino y, posiblemente, algunos otros parámetros. El mensaje puede producirse con un editor de texto independiente, un programa de procesamiento de texto o, posiblemente, un editor de texto incorporado en el agente de usuario. La dirección de destino debe estar en un formato que el agente de usuario pueda manejar. Muchos agentes de usuario esperan direcciones DNS de la

48



ESPOCH-FIE-EIS

forma usuario@dirección-dns.

Figura 5.3 Manejo de listas de correo La mayoría de los sistemas de correo electrónico manejan listas de correo, por lo que un usuario puede enviar el mismo mensaje a un grupo de personas con un solo comando. Si la lista de correo se mantiene localmente, el agente usuario puede sencillamente enviar un mensaje por separado a cada destinatario. Sin embargo, si la lista se mantiene de manera remota, los mensajes se multiplicarán ahí. Por ejemplo, si un grupo de observadores de pájaros tiene una lista de correo llamada pájaros instalada en observador .espoch.edu.ec, entonces cualquier mensaje enviado a [email protected] se enrulará a la Politécnica de Chimborazo y se multiplicará ahí para producir mensajes individuales para todos los miembros de la lista de correo, sin importar el lugar del mundo en el que estén. Los usuarios de esta lista de correo no pueden saber que es una lista de correo. El software expansor (figura 5.3) cuando llega un mensaje de correo electrónico, procederá a examinar la dirección de destino, si aparece en la base de datos, reenvía copias a todas las direcciones de la lista.

Lectura del correo electrónico Por lo común, cuando se inicia un agente de usuario, buscará en el buzón del usuario el correo electrónico recibido, antes de presentar otra cosa en la pantalla. Después puede anunciar la cantidad de mensajes en el buzón o presentar un resumen de una línea de cada uno y esperar un comando. Como ejemplo del funcionamiento de un agente de usuario, veamos una situación típica de correo. Después de iniciar el agente de usuario, el usuario solicita un resumen de su correo electrónico. A continuación aparece una pantalla como la de la figura 5.4. Cada línea hace referencia a un mensaje. En este ejemplo, el buzón contiene ocho mensajes. N° 1 2 3 4 5 6 7 8

Bandera K KA KF

Bytes 1030 6348 4519 1236 104110 1223 3110 1204

Remitente Andrea Luis Silvana Moreno Baleri Paladines Juan Frank Guido Dr Rueda

Asunto Cambios en la tesis No todas son molestas Solicitud de información Bioinformática Material sobre las redes inalámbricas Re: Revisará una propuesta de otorgamiento Nuestro documento ha sido aceptado Re: Visita de mis estudiantes

Figura 5.4 Ejemplo de contenido de un buzón Cada línea de la pantalla contiene varios campos extraídos del sobre o del encabezado del mensaje correspondiente. En un sistema sencillo de correo electrónico, la selección de campos a presentar está incorporada en el programa. En uno más refinado, el usuario puede especificar los campos a presentar proporcionando un perfil de usuario, un archivo que describe el formato de presentación. En el ejemplo, el primer campo es el número de mensaje. El segundo 49



ESPOCH-FIE-EIS

campo, Banderas, puede contener una K, lo que significa que el mensaje no es nuevo, sino que ha sido leído previamente y guardado en el buzón; una A, lo que quiere decir que el mensaje ya ha sido contestado; y/o una F, lo que indica que ese mensaje ha sido reenviado a alguien más. También son posibles otras banderas. El tercer campo indica la longitud del mensaje y el cuarto indica quién envió el mensaje. Puesto que este campo simplemente se extrae del mensaje, puede contener nombres de pila, nombre completos, iniciales, claves de acceso o cualquier otra cosa que el remitente decida poner ahí. Por último, el campo de Asunto da un resumen breve del tema del mensaje. La gente que no incluye un campo de Asunto con frecuencia descubre que las respuestas a su correo electrónico tienden ano recibir la prioridad más alta. Una vez que se han visualizado los encabezados, el usuario puede realizar cualquiera de diversas acciones, como desplegar o eliminar el mensaje. Los sistemas más antiguos se basaban en texto y típicamente utilizaban comandos de un carácter para realizar estas tareas, como T (teclear mensaje), A (responder a mensaje), D (borrar mensaje) y F (reenviar mensaje). Un argumento especificaba el mensaje en cuestión. Los sistemas más recientes utilizan interfaces gráficas. Por lo general, el usuario selecciona un mensaje con el ratón y después hace clic en un icono para escribir, responder a él, eliminarlo o reenviarlo. El correo electrónico ha recorrido un largo camino desde los días cuando era simplemente transferencia de archivos. Los agentes de usuario refinados hacen posible manejar un gran volumen de correo electrónico. Para las personas que reciben y envían miles de mensajes de correo electrónico al año, tales herramientas son invaluables.

5.4 FORMATOS DE MENSAJE Existen dos formatos de correo electrónico que se utilizan en la actualidad el ASCII básico usando el RFC 822 y las extensiones multimedia del RFC 822.

5.4.1 RFC 822 Los mensajes consisten en un sobre primitivo (descrito en el RFC 821), algunos campos de encabezado, una línea en blanco y el cuerpo del mensaje. Cada campo de encabezado consiste (lógicamente) en una sola línea de texto ASCII que contiene el nombre del campo, dos puntos (:)y. para la mayoría de los campos, un valor. El RFC 822 es un estándar viejo y no distingue claramente los campos del sobre de los de encabezado. Aunque se revisó en el RFC 2822, no fue posible restaurarlo por completo debido a su uso amplio. En el uso normal, el agente de usuario construye un mensaje y lo pasa al agente de transferencia de mensajes, quien después usa algunos campos del encabezado para construir el sobre, una mezcla un tanto anticuada de mensaje y sobre. En la figura 5.5 se listan los principales campos de encabezado relacionados con el transporte del mensaje.

50


Encabezado


ESPOCH-FIE-EIS

Significado

To:

Direcciones de correo electrónico de los destinatarios primarios

Cc:

Direcciones de correo electrónico de los destinatarios secundarios

Bcc:

Direcciones de correo electrónico para las copias ocultas

From:

Persona o personas que crearon el mensaje

Sender:

Dirección de correo electrónico del remitente

Received:

Línea agregada por cada agente de transferencia en la ruta

Return-Path: Puede usarse para identificar una ruta de regreso al remitente

Figura 5.5. Campos de encabezado RFC 822 El campo To: indica la dirección DNS del destinatario primario. Está permitido tenga varios destinatarios. El campo Cc: indica la dirección de los destinatarios secundarios; En términos de entrega, no hay diferencia entre los destinatarios primarios y los secundarios. Es una diferencia por entero psicológica que puede ser importante para los participantes, pero que no lo es para el sistema de correo. El término Cc: (copia al carbón) es un poco anticuado, puesto que las computadoras no usan papel carbón, pero está muy establecido. El campo Bcc: (copia oculta) es como el campo Cc:, excepto que esta línea se borra de todas las copias enviadas a los destinatarios primarios y secundarios. Esta característica permite a la gente mandar copias a terceros sin que los destinatarios primarios y secundarios lo sepan. From: y S ender: indican quién escribió y envió el mensaje, respectivamente; pueden ser diferentes. Por ejemplo, un ejecutivo de negocios puede escribir un mensaje, pero su secretaria podría ser la que lo transmita. En este caso, el ejecutivo estaría listado en el campo From: y la secretaria en el campo Sender:. El campo From: es necesario, pero el campo Sender: puede omitirse si es igual al campo From:. Estos campos son necesarios en caso de que el mensaje no pueda entregarse y deba devolverse al remitente.

Se agrega una línea que contiene Received: por cada agente de transferencia de mensajes en el camino. La línea contiene la identidad del agente, la fecha y hora de recepción del mensaje, y otra información que puede servir para encontrar fallas en el sistema de enrutamiento. El campo Return-Path: es agregado por el agente de transferencia de mensajes final y estaba destinado para indicar la manera de regresar al remitente. En teoría, esta información puede tomarse de todos los encabezados Received: (con excepción del nombre del buzón del remitente), pero pocas veces se llena de esta manera y por lo general contiene sólo la dirección del remitente.

51



ESPOCH-FIE-EIS

Además de los campos de la figura 5.5, los mensajes RFC 822 también pueden contener una variedad de campos de encabezado usados por los agentes de usuario o los destinatarios. En la figura 5.6 se listan los más comunes. La mayoría de ellos autoexplicativos, por lo que no los veremos en detalle. Encabezado

Significado

Date:

Fecha y hora de envío del mensaje

RepIy-To:

Dirección de corre electrónico a la que deben enviarse las contestaciones

Message-ld:

Número único para referencia posterior a este mensaje

In-RepIy-To:

Identificador del mensaje al que éste responde

References:

Otros identificadores de mensaje pertinentes

Keywords:

Claves seleccionadas por el usuario

Subject:

Resumen corto del mensaje para desplegar en una línea

Figura 5.6 Algunos campos usados en el encabezado de mensaje RFC 822. El campo RepIy-To: a veces se usa cuando ni la persona que redactó el mensaje ni la que lo envió quieren ver la respuesta. Por ejemplo, un gerente de marketing escribe un mensaje de correo electrónico para informar a los clientes sobre un producto nuevo. El mensaje lo envía una secretaria, pero el campo RepIy-To: indica el jefe del departamento de ventas, quien puede contestar preguntas y surtir pedidos. Este campo también es útil cuando el emisor tiene dos cuentas de correo electrónico y desea que la respuesta llegue a su otra cuenta. El documento RFC 822 indica explícitamente que los usuarios pueden inventar encabezados nuevos para uso privado, siempre y cuando comiencen con la cadena X-. Se garantiza que no habrá encabezados futuros que usen nombres que comiencen con X-, a fin de evitar conflictos entre los encabezados oficiales y los privados. A veces algunos estudiantes universitarios, pasándose listos incluyen campos como X-Fruta-del-Día: o X-Enfermedad-de-la-Semana:, que son legales, aunque no muy ilustrativos. Tras los encabezados viene el cuerpo del mensaje. Los usuarios pueden poner aquí lo que deseen. Algunos terminan sus mensajes con firmas complicadas, incluidas caricaturas sencillas en ASCII, citas de autoridades mayores y menores, pronunciamientos políticos y renuncias de responsabilidades de todo tipo.

5.4.2 MIME—Extensiones Multipropósito de Correo Internet En los primeros días de ARPANET, el correo electrónico consistía exclusivamente en mensajes de texto escritos en inglés y expresados en ASCII. En tal entorno, el RFC 822 hacia todo el trabajo: especificaba los encabezados, pero dejaba el contenido en manos del usuario. Hoy día en la red mundial de Internet, este método ya no es adecuado. Los problemas incluyen envío y recepción de: 52



ESPOCH-FIE-EIS

1. Mensajes en idiomas con acentos (por ejemplo, español, francés y alemán). 2. Mensajes en alfabetos no latinos (por ejemplo, hebreo y ruso). 3. Mensajes en idiomas sin alfabetos (por ejemplo, chino y japonés). 4. Mensajes que no contienen texto (por ejemplo, audio y vídeo). Se propuso una solución en el RFC 1341 y se actualizó en los RFCs 2045-2049. Esta solución, llamada MIME (Extensiones Multipropósito de Correo Internet), se usa ampliamente. La idea básica de MIME es continuar usando el formato RFC 822, pero agregar una estructura al cuerpo del mensaje y definir reglas de codificación para los mensajes no ASCII. Al no desviarse del 822, los mensajes MIME pueden enviarse usando los programas y protocolos de correo electrónico existentes. Todo lo que tiene que cambiarse son los programas emisores y receptores, lo que pueden hacer los usuarios mismos. MIME define cinco nuevos encabezados de mensaje, como se muestra en la figura 5.7. El primero de éstos simplemente indica al agente de usuario receptor del mensaje que está tratando con un mensaje MIME, así como la versión del MIME que usa. Se considera que cualquier mensaje que no contenga un encabezado MIME-Versión: es un mensaje de texto normal en inglés, y se procesa como tal.

Encabezado Significado MIME-Version: Identifica la versión de MIME Content-Descri tion: Cadena de texto ue describe el contenido Content-ld: Identificador único Content-Transfer-Encodin : Cómo se envuelve el mensa e ara su transmisión Content-T e: Naturaleza del mensa e Figura 5.7 Encabezados RFC 822 agregados por MIME. El encabezado Content-Description: es una cadena ASCII que dice lo que está en el mensaje. Este encabezado es necesario para que el destinatario sepa si vale la pena descodificar y leer el mensaje. Si la cadena dice: "Foto de Avril Lavigne" y la persona que recibe el mensaje no es un gran fanático de ella, el mensaje probablemente será descartado en lugar de descodificado para dar una foto a color de alta definición. El encabezado Content-ld: identifica el contenido; usa el mismo formato que el encabezado estándar Message-Id: Content-Transfer-Encoding: indica la manera en que está envuelto el cuerpo para su transmisión a través de una red donde se podría tener problemas con la mayoría de los caracteres distintos de las letras, números y signos de puntuación. Se proporcionan cinco esquemas (más un escape hacia nuevos esquemas). El

53




esquema más sencillo es simplemente texto ASCII. Los caracteres ASCII usan 7 bits y pueden transportarse directamente mediante el protocolo de correo electrónico siempre y cuando ninguna línea exceda 1000 caracteres. El siguiente esquema más sencillo es lo mismo, pero utiliza caracteres de 8 bits, es decir, todos los valores de O a 255. Este esquema de codificación viola el protocolo (original) del correo electrónico de Internet, pero es usado por algunas partes de Internet que implementan ciertas extensiones al protocolo original. Mientras que la declaración de la codificación no la hace legal, hacerla explícita puede cuando menos explicar las cosas cuando algo sucede mal. Los mensajes que usan codificación de 8 bits deben aún adherirse a la longitud máxima de línea estándar. Peor aún son los mensajes que usan codificación binaria. Éstos son archivos binarios arbitrarios que no sólo utilizan los 8 bits, sino que ni siquiera respetan el límite de 1000 caracteres por línea. Los programas ejecutables caen en esta categoría. No se da ninguna garantía de que los mensajes en binario llegarán correctamente, pero mucha gente los envía de todos modos. La manera correcta de codificar mensajes binarios es usar codificación base64, a veces llamada armadura ASCII. En este esquema se dividen grupos de 24 bits en unidades de 6 bits, y cada unidad se envía como un carácter ASCII legal. La codificación es "A" para 0, "B" para 1, etcétera, seguidas por las 26 letras minúsculas, los 10 dígitos y, por último, + y / para el 62 y 63, respectivamente. Las secuencias == e = se usan para indicar que el último grupo contenía sólo 8 o 16 bits respectivamente. Los retornos de carro y avances de línea se ignoran, por lo que puede introducirse a voluntad para mantener la línea lo suficientemente corta. Puede enviarse un texto binario arbitrario usando este esquema. En el caso de mensajes que son casi completamente ASCII, pero con algunos caracteres no ASCII, la codificación base 64 es algo ineficiente. En su lugar se usa una codificación conocida como codificación entrecomillada imprimible. Simplemente es ASCII de 7 bits, con todos los caracteres por encima de 127 codificados como un signo de igual seguido del valor del carácter en dos dígitos hexadecimales. En resumen, los datos binarios deben enviarse codificados en base 64 o en forma entrecomillada imprimible. Cuando hay razones válidas para no usar uno de estos esquemas, es posible especificar una codificación definida por el usuario en el encabezado Content-Transfer-Encoding:. El último encabezado mostrado en la figura 5.8 en realidad es el más interesante. Especifica la naturaleza del cuerpo del mensaje. En el RFC 2045 hay siete tipos definidos, cada uno de los cuales tiene uno o más subtipos. El tipo y el subtipo se separan mediante una diagonal, como como en Content-Type: video/mpeg. video/mpeg.

Ti o Texto

Subti o Plano Enriquecido

Descri ción Texto sin formato Texto con comandos de formato sencillos

54


Imagen

Gif J e Audio Básico Vídeo Mpeg Aplicación Octet-stream Post Postsc scri ri t Mensaje Rfc822 Parcial Externo Multipartes Multipartes Mezclado Mezclado Alternativa Paralelo Compendio



Imagen fija en formato GIF Ima en fi a en formato JPEG Sonido Película en formato MPEG Secuencia de b tes no inter retada Docu Docume ment nto o im rimi rimibl ble e en Post PostSc Scri ri t Mensa e MIME RFC 822 Mensa e dividido ara su transmisión El mensa e mismo debe obtenerse de la red Partes inde endientes endientes en el orden orden es ecificado ecificado Mismo mensa e en diferentes formatos Las partes deben verse en forma simultánea Cada parte es un mensaje RFC 822 completo

Figura 5.8. Tipos y subtipos MIME definidos en el RFC 2045 El subtipo debe indicarse de manera explícita en el encabezado; no se proporcionan valores predeterminados. La lista inicial de tipos y subtipos especificada en el RFC 2045 se da en la figura 5.8. Se han agregado muchos otros desde entonces, y se agregan entradas nuevas todo el tiempo, a medida que surge la necesidad. Veamos brevemente la lista de tipos. El tipo text es para texto normal. La combinación text/plain es para mensajes ordinarios que pueden visualizarse como se reciben, sin codificación ni ningún procesamiento posterior. Esta opción permite el transporte de mensajes ordinarios en MIME con sólo unos pocos encabezados extra. El subtipo text/enriched permite permite la inclusión de un lenguaje de marcado sencillo en el texto. Este lenguaje proporciona una manera independiente del sistema para indicar negritas, cursivas, tamaños en puntos menores y mayores, sangrías, justificaciones, sub y superíndices, y formatos sencillos de página. El lenguaje de marcado se basa en SGML, el lenguaje estándar genérico de etiquetas que también se utiliza como la base del HTML de World Wide Web. Por ejemplo, el mensaje Ha llegado el momento , dijo la morsa ... se presentaría como

Ha llegado el momento, dijo la morsa... Es responsabilidad del sistema receptor seleccionar la presentación adecuada. Si hay negritas y cursivas disponibles, pueden usarse; de otra manera, pueden usarse colores, parpadeos, vídeo inverso, etcétera, como énfasis. Los diferentes sistemas pueden hacer selecciones distintas, lo cual hacen en realidad.

55




Cuando Web se volvió popular, se agregó un nuevo subtipo texto/html (en (en el RFC 2854) para permitir que las páginas Web se enviaran en el correo electrónico del RFC 822. En el RFC 3023 se define un subtipo para el lenguaje de marcado extensible, texto/xml. El siguiente tipo MIME es imagen, que se usa para transmitir imágenes fijas. Hoy día se usan muchos formatos para almacenar y transmitir imágenes, tanto con compresión como sin ella. Dos de éstos, GIF y JPEG, están integrados en la mayoría de los navegadores, pero también existen muchos otros, los cuales se han agregado a la lista original. Los tipos audio y vídeo son para sonido e imágenes en movimiento, respectivamente. Obsérvese que vídeo incluye sólo la información visual, no la pista de sonido. Si se debe transmitir una película con sonido, tal vez sea necesario transmitir las partes de vídeo y de audio por separado, dependiendo del sistema de codificación usado. El primer formato de vídeo definido fue realizado por el grupo denominado MPEG (Grupo de Expertos en Imágenes en Movimiento), pero desde entonces se han agregado otros. Además de audio/basic , se agregó un nuevo tipo de audio, audio/mpeg , en el RFC 3003 para permitir que las personas pudieran enviar archivos de audio MP3. El tipo aplicación es un tipo general para los formatos que requieren procesamiento externo no cubierto por ninguno de los otros tipos. Un octet-stream simplemente es una secuencia de bytes no interpretados. Al recibir una de tales cadenas, un agente de usuario probablemente debería presentarla en pantalla sugiriendo al usuario que lo copie en un archivo y solicitándole un nombre de archivo. El procesamiento posterior es responsabilidad del usuario. Otro subtipo definido es postscript, que se refiere al lenguaje PostScript producido por Adobe Systems y ampliamente usado para describir páginas impresas. Muchas impresoras tienen intérpretes PostScript integrados. Aunque un agente de usuario simplemente puede llamar a un intérprete PostScript externo para visualizar los archivos PostScript entrantes, hacerlo no esta exento de riesgos. PostScript es un lenguaje de programación completo. Con el tiempo necesario, una persona lo bastante masoquista podría escribir un compilador de C o un sistema de administración de base de datos en PostScript. El despliegue de un mensaje PostScript entrante puede hacerse ejecutando el programa PostScript contenido en él. Además de desplegar desplegar algo de texto, texto, este programa puede puede leer, modificar o borrar borrar los archivos del usuario, así como tener otros efectos secundarios desagradables. El tipo mensaje permite que un mensaje esté encapsulado por completo dentro de otro. Este esquema es útil para reenviar, por ejemplo, correo electrónico. Cuando se encapsula un mensaje RFC 822 completo en un mensaje exterior, debe usarse el subtipo rfc822. El subtipo parcial parc ial hace posible dividir un mensaje encapsulado en pedazos y enviarlos por separado (por ejemplo, si el mensaje encapsulado es demasiado grande). Los parámetros hacen posible reensamblar en forma correcta todas las partes en el destino en el orden correcto.

56



ESPOCH-FIE-EIS

Por último, el subtipo externo puede usarse para mensajes muy grandes (por ejemplo, películas en vídeo). En lugar de incluir el archivo MPEG en el mensaje, se da una dirección FTP y el agente de usuario del receptor puede obtenerlo a través de la red al momento que se requiera. Esta característica es especialmente útil cuando se envía una película a una lista de correo, y sólo se espera que unos cuantos la vean. El último tipo es multíparte, que permite que un mensaje, contenga más de una parte, con el comienzo y el fin de cada parte claramente delimitados. El subtipo mezclado permite que cada parte sea diferente, sin ninguna estructura adicional impuesta. Muchos programas de correo electrónico permiten que el usuario agregue uno o más archivos adjuntos a un mensaje de texto. Estos archivos adjuntos se envían mediante el tipo multíparte. A diferencia del tipo multiparte, el subtipo alternativa permite que el mismo mensaje se incluya varias veces, pero expresado en dos o más medios diferentes. Por ejemplo, un mensaje puede enviarse como ASCII común, como texto enriquecido (enriched) y como PostScript. Un agente de usuario adecuadamente diseñado que reciba uno de tales mensajes lo presentará en PostScript de ser posible. La segunda posibilidad sería como texto enriquecido. Si ninguna de las dos fuera posible, se presentaría el texto ASCII normal. Las partes deben ordenarse de la más sencilla a la más compleja para ayudar a que los receptores con agentes de usuario pre-MIME puedan encontrarle algún sentido al mensaje (por ejemplo, incluso un usuario preMIME puede leer texto ASCII común). El subtipo alternativa también puede servir para varios lenguajes. En la figura 5.9 se muestra un ejemplo multimedia. Aquí se transmite una felicitación de cumpleaños como texto y como canción. Si el receptor tiene capacidad de audio, el agente de usuario traerá el archivo de sonido, birthday.snd, y lo ejecutará. Si no, se presenta la letra en la pantalla en absoluto silencio. Las partes están delimitadas por dos guiones seguidos de una cadena (generada por software) especificada en el parámetro boundary From; [email protected] To: [email protected] MIME-Version: 1.0 Message-Id: <0704760941 [email protected] > Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm Subject: La Tierra da vuelta al Sol un número entero de veces Éste es el preámbulo. El agente de usuario lo ignora. Tenga un bonito día. --qwertyuiopasdfghj klzxcvbnm Content-Type: text/enriched Feliz cumpleaños a ti Feliz cumpleaños a ti Feliz cumpleaños, querida Elena Feliz cumpleaños a ti --qwertyuiopasdfghjklzxcvbnm Content-Type: message/external-body; access-type="anon-ftp"; site="bicycle.abcd.com"; 57



ESPOCH-FIE-EIS

directory="pub" ; name="birthday.snd" content-type: audio/basic content-transfer-encoding: base64 --qwertyuiopasdfghjklzxcvbnm-Figura 5.9 Mensaje multiparte que contiene alternativas de texto enriquecido y audio.

Observe que el encabezado Content-Type aparece en tres lugares en este ejemplo. En el nivel superior, el encabezado indica que el mensaje tiene varias partes. En cada parte, el encabezado indica el tipo y el subtipo de la parte. Por último, en el texto de la segunda parte, el encabezado es necesario para indicarle al agente de usuario la clase de archivo externo que debe conseguir. Para indicar esta pequeña diferencia de uso, hemos usado letras en minúscula, aunque los encabezados no hacen distinciones entre mayúsculas y minúsculas. De la misma manera, se requiere el encabezado content-transfer-encoding para cualquier cuerpo externo que no esté codificado como ASCII de 7bits. Regresando a los subtipos para mensajes multiparte, existen dos posibilidades más. El subtipo paralelo se usa cuando todas las partes deben "verse" de manera simultánea. Por ejemplo, las películas con frecuencia tienen un canal de audio y uno de vídeo. Las películas son más efectivas si estos dos canales se producen en paralelo, en lugar de consecutivamente. Por último, el subtipo compendio se usa cuando se empacan muchos mensajes juntos en un mensaje compuesto. Por ejemplo, algunos grupos de discusión de Internet recolectan mensajes de los subscriptores y luego los envían como un solo mensaje multiparte/compendio.

5.5 TRANSFERENCIA DE MENSAJES El sistema de transferencia de mensajes se ocupa de transmitir del remitente al destinatario La manera más sencilla de hacer esto es establecer una conexión de transporte de la máquina de origen a la de destino y sencillamente transferir el mensaje.

SMTP—Protocolo Simple de Transporte de Correo En Internet, el correo electrónico se entrega al hacer que la máquina de origen establezca una conexión TCP con el puerto 25 de la máquina de destino. Escuchando en este puerto está un demonio de correo electrónico que habla con el SMTP (Protocolo Simple de Transporte de Correo). Este demonio acepta conexiones de entrada y copia mensajes de ellas a los buzones adecuados (ver figura 5.2). Si no puede entregarse un mensaje, se devuelve al remitente un informe de error que contiene la primera parte del mensaje que no pudo entregarse. SMTP es un protocolo ASCII sencillo. Después de establecer la conexión TCP con el puerto 25, la máquina emisora, operando como cliente, espera que la máquina 58



ESPOCH-FIE-EIS

receptora, operando como servidor, hable primero. El servidor comienza enviando una línea de texto que proporciona su identidad e indica si está preparado o no para recibir correo. Si no lo está, el cliente libera la conexión y lo intenta después. Si el servidor está dispuesto a aceptar correo electrónico, el cliente anuncia de quién proviene el mensaje, y a quién está dirigido. Si existe el destinatario en el destino, el servidor da al cliente permiso para enviar el mensaje. A continuación el cliente envía el mensaje y el servidor confirma su recepción. Por lo general, no se requieren sumas de verificación porque TCP proporciona un flujo de bytes confiable. Si hay más correo electrónico, se envía ahora. Una vez que el correo electrónico ha sido intercambiado en ambas direcciones, se libera la conexión. Nombre HELO MAIL RCPT DATA RSET NOOP QUIT SEND SOML

Formato de la orden

Descripción

HELO (dominio) MAIL FROM: RCPT T0: DATA RSET NOOP QUIT SEND FROM: (camino inverso) SOML FROM: (camino inverso)

Envía identificación Identifica al que origina el correo Identifica al destino del correo Transfiere un texto de mensaje Aborta la transacción del correo actual No operación Cierra la conexión TCP Envía correo al terminal Envía correo al terminal si es posible; de otro modo a! buzón SAML SAML FROM: Envía correo al terminal y al buzón VRFY VRFY Confirma el nombre del usuario EXPN EXPN (cadena) Devuelve el número de miembros de la lista de correo HELP HELP [ ] Envía documentación específica del sistema TURN TURN Intercambia el rol del emisor y el receptor = espacio Los paréntesis cuadrados indican elementos opcionales. Las órdenes sombreados son opcionales en una implementación que verifiqué SMTP.

Figura 5.10 Ordenes SMTP El funcionamiento de SMTP se realiza por medio de una serie de órdenes y respuestas intercambiadas entre el emisor y receptor SMTP. La iniciativa la lleva el SMTP emisor, que establece la conexión TCP. Una vez que se ha establecido la conexión, el emisor SMTP envía órdenes a través de la conexión al receptor. Cada orden genera exactamente una respuesta del receptor SMTP. La figura 5.10 muestra las órdenes SMTP. Cada orden consta de una única línea de texto, comenzando con un código de orden de 4 letras seguido en algunos casos por un campo de argumentos. La mayoría de las respuestas son una única línea, 59



ESPOCH-FIE-EIS

aunque es posible respuestas de líneas múltiples. La figura indica aquellas órdenes que todos los receptores deben ser capaces de reconocer. Las respuestas SMTP se muestran en la figura 5.11. Cada respuesta comienza con un código de tres dígitos y puede ir seguido por información adicional. El primer bit indica la categoría de la respuesta: Código 211 214 220 221 250 251 354 421 450 451 452 500 501 502 503 504 550 551 552 553 554

Descripción Respuesta de finalización positiva Estado del sistema o respuesta de ayuda del sistema. Mensaje de ayuda (información de cómo utilizar el receptor o el significado de una orden particular no estándar; esta respuesta es sólo útil al usuario humano) Servicio preparado Servicio cerrando el canal de transmisión Acción de correo solicitada correcta, completada Usuario no local; reenviar a Respuesta intermedia positiva Comenzar la entrada de correo; acabar con . Respuesta de finalización negativa transitoria Servicio no disponible; perdido canal de transmisión. (Ésta podría ser la respuesta a cualquier orden si el servicio conoce que debe desconectarse) Acción de correo solicitada no ejecutada; buzón de correo no disponible (p. ej. Buzón ocupado) Cancelada acción solicitada; error local en el procesamiento Acción solicitada no ejecutada; almacenamiento del sistema insuficiente Respuesta de finalización negativa permanente Error de sintaxis; orden no reconocida (esto puede incluir errores como línea de orden demasiado larga) Error de sintaxis en los parámetros o los argumentos Orden no implementada Secuencia de órdenes incorrecta Parámetro de orden no implementado Acción solicitada no ejecutada; buzón de correo no disponible (p. ej. buzón no encontrado, no se accedió) Usuario no local, por favor, intente Acción de correo solicitada cancelada; excedida la asignación de espacio de almacenamiento Acción solicitada no ejecutada; nombre del buzón de correos no permitido (p. ej. Sintaxis de correo incorrecta) Transacción fallida

Figura 5.11 Respuestas SMTP • Respuesta de finalización afirmativa: la acción solicitada se ha completado

satisfactoriamente. Se puede iniciar; una nueva solicitud. • Respuesta intermedia positiva: la orden ha sido aceptada pero la acción solicitada está suspendida, pendiente de recibir más información. El emisor SMTP

60



ESPOCH-FIE-EIS

debería enviar otra orden especificando está información. Esta respuesta se utiliza en grupos de secuencias de órdenes. • Respuesta de finalización negativa transitoria: la orden no se aceptó y la acción solicitada no se realizó. Sin embargo, la condición de error es temporal y se puede solicitar la acción de nuevo. • Respuesta de finalización negativa permanente: la orden no se aceptó y la acción solicitada no se realizó. La operación básica de SMTP ocurre en tres fases: establecimiento de la conexión, intercambio de uno o más pares orden-respuesta, y cierre de la conexión. A continuación se examinan cada una de las fases.

Establecimiento de la conexión Un emisor SMTP intentará establecer una conexión TCP con un computador destino cuando tiene uno o más mensajes de correo para entregar a ese computador. La secuencia es bastante sencilla: 1. El emisor abre una conexión TCP con el receptor. 2. Una vez que se ha establecido la conexión, el receptor se identifica a sí mismo con «220 Service Ready». 3. El emisor se identifica a sí mismo con la orden HELO. 4. El. receptor acepta la identificación del emisor con «250 OK». Si el servicio de correo no está disponible en el destino, el computador destino devuelve una respuesta «421 Service Not Available» en el paso 2 y finaliza el proceso.

Transferencia de correo Una vez que se ha establecido la conexión, el emisor SMTP puede enviar uno o más mensajes al receptor SMTP. Hay tres fases lógicas en la transferencia de un mensaje: 1. Una orden MAIL identifica al que originó el mensaje. 2. Una o más órdenes RCPT identifican los destinos de este mensaje. 3. Una orden DATA transfiere el texto del mensaje. La orden MAIL da el camino inverso que puede utilizarse para informar de errores: Si él receptor está preparado para aceptar mensajes, devuelve una respuesta «250 OK». De otra forma devuelve una respuesta indicando un fallo al ejecutar la orden (códigos 451, 452, 552) o un error en la orden (códigos 421,500, 501). 7 La orden RCPT identifica un destino individual de los datos del correo; se pueden especificar destinos múltiples mediante el uso múltiple de esta orden. Se devuelve

7

Stallings William. Comunicaciones y redes de computadores.Pág. 665.

61



ESPOCH-FIE-EIS

una respuesta separada por cada orden RCPT, con una de las siguientes posibilidades: 1. El receptor acepta el destino con una respuesta «250»; esto indica que ese buzón de correo destino está en el sistema receptor. 2. El destino requiere qué se reenvíe y el receptor lo reenviará (251). 3. El destino requiere que se reenvíe pero el receptor no lo reenviará; el emisor debe reenviar a la dirección de reenvío (551). 4. No existe ese buzón de correo para ese destino en este computador (550). 5. El destino se rechaza debido a algún fallo de ejecución (códigos 450, 451, 452, 552) o a un error en la orden (códigos 421, 500, 501, 503). La ventaja de utilizar fases separadas de RCPT es que el emisor no enviará el mensaje hasta que esté seguro que él receptor está preparado para recibir el mensaje para al menos un destino evitando, por tanto, el tiempo suplementario de enviar un mensaje entero para aprender que el destino es desconocido. Una vez que el receptor SMTP está de acuerdo en recibir el mensaje de correo para al menos un destino, el emisor SMTP utiliza la orden DATA para iniciar la transferencia del mensaje. Si el receptor SMTP sigue preparado para recibir el mensaje devuelve un mensaje «354»; de otro modo el receptor devuelve una respuesta indicando un fallo al ejecutar la orden (códigos 451, 554) o un error en la orden (códigos 421, 500, 501, 503). Si se devuelve la respuesta «354», el emisor SMTP procede a enviar el mensaje sobre la conexión TCP como una secuencia de líneas ASCII. El fin del mensaje se indica por una línea que contiene solamente un punto. El receptor SMTP responde con una respuesta «250 OK» si se acepta el mensaje o con el código de error apropiado (451, 452, 552, 554). A continuación se muestra el proceso S: 220 servicio SMTP xyz.com listo C: HELO abcd.com S: 250 xyz.com dice hola a abcd.com C: MAIL FROM: S: 250 emisor ok C: RCPT T0: S: 250 receptor ok C: DATA S: 354 envía correo; termina con una línea únicamente con "." C: From; [email protected] C: To: [email protected] C: MIME-Version: 1.0 C: Message-Id: <[email protected]> C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghj klzxcvbnm C: Subject: La Tierra da vuelta al Sol un número entero de veces C: C: Este es el preámbulo.. El agente de usuario lo ignora. Tenga un bonito día. C: C:--qwertyuiopasdfghjklzxcvbnm C: Content-Type: text/enriched C: C: Feliz cumpleaños a ti 62



ESPOCH-FIE-EIS

C: Feliz cumpleaños a ti C: Feliz cumpleaños, mami Elena C: Feliz cumpleaños a ti C: C: --qwertyuiopasdfghjklzxcvbnm C: Content-Type: message/external-body; C: access-type="anon-ftp"; C: site="bicycle.abcd.com"; C: directory="pub"; C: C: name="birthday.snd" C: C: content-type: audio/basic C: content-transfer-encoding: base64 C: --qwertyuiopasdfghjklzxcvbnm C: . S: 250 mensaje aceptado C: QUIT S: 221 xyz.com cerrado conexión Figura 5.12 Transferencia de un mensaje

Se muestra en la figura 5.12 un diálogo de ejemplo para el envío del mensaje de la figura 5.9, incluyendo los códigos numéricos usados por SMTP. Las líneas enviadas por el cliente se marcan con C:; aquellas enviadas por el servidor se marcan con S:. Pueden ser útiles algunos comentarios sobre el ejemplo. El primer comando del cliente es ciertamente HELO. De las dos abreviaturas de cuatro caracteres de HELLO, ésta tiene numerosas ventajas sobre su competidora. La razón por la que los comandos tienen que ser de cuatro caracteres se ha perdido en las brumas del tiempo. El mensaje se envía a un solo destinatario, por lo que se usa un solo comando RCPT. Se permiten tales comandos para enviar un solo mensaje a destinatarios múltiples; se confirma la recepción de cada uno o se rechaza de manera individual. Incluso si se rechazan algunos destinatarios (porque no existen en el destino), el mensaje puede enviarse a los demás. Por último, aunque la sintaxis de los comandos de cuatro caracteres del cliente se especifica con rigidez, la sintaxis de las respuestas es menos rígida. Sólo cuenta el código numérico. Cada implementación puede poner la cadena que desee después del código.

Cierre de la conexión El emisor SMTP cierra la conexión en dos pasos. Primero, el emisor envía una orden QUIT y espera una respuesta. El segundo paso es iniciar una operación de cierre TCP para la conexión TCP. El receptor inicia su cierre TCP después de enviar su respuesta en la orden QUIT.

63


5.6


ESPOCH-FIE-EIS

ENTREGA FINAL

Hasta ahora se ha supuesto que todos los usuarios trabajan en máquinas capaces de enviar y recibir correo electrónico. Como vimos, el correo electrónico se entrega al hacer que el emisor establezca una conexión TCP con el receptor y después que envíe el correo electrónico a través de ella. Este modelo funcionó bien por décadas cuando todos los hosts ARPANET (y más tarde Internet) se pusieron, de hecho, en línea todo el tiempo para aceptar conexiones TCP. Sin embargo, con el advenimiento de personas que acceden a Internet llamando a su ISP por medio de un módem, ese modelo dejó de usarse. El problema es el siguiente: ¿qué sucede cuando Elena desea enviar correo electrónico a Giovanna y esta última no está en línea en ese momento? Elena no puede establecer una conexión TCP con Giovanna y, por lo tanto, no puede ejecutar el protocolo SMTP. Una solución es que un agente de transferencia de mensajes en una máquina ISP acepte correo electrónico para sus clientes y lo almacene en sus buzones en una máquina ISP. Puesto que este agente puede estar en línea todo el tiempo, el correo electrónico puede enviarse las 24 horas del día.

5.6.1 POP3 Desgraciadamente, esta solución genera otro problema: ¿cómo obtiene el usuario el correo electrónico del agente de transferencia de mensajes del ISP? La solución a este problema es crear otro protocolo que permita que los agentes de transferencia de usuarios (en PCs cliente) contacten al agente de transferencia de mensajes (en la máquina del ISP) y que el correo electrónico se copie desde el ISP al usuario. Tal protocolo es POP3 (Protocolo de Oficina de Correos Versión 3), que se describe en el RFC 1939. En la figura 5.13 se ilustra la situación en la que el emisor está (actualmente) en línea pero el receptor no. COMPUTADOR CON BUZON

TRANSMISOR

buzón del destinatario

Agente de usuario

Puerto TCP

COMPUTADOR DEL USUARIO

Servidor de correo Agente de transferencia 25 de mensaje

Servidor POP 110 TCP IP

IP

cliente POP Puerto TCP IP

RED TCP/IP

64



ESPOCH-FIE-EIS

Figura 5.13 Trayectoria del correo electrónico al emplear POP POP3 inicia cuando el usuario arranca el lector de correo. Éste llama al ISP (a menos que ya haya una conexión) y establece una conexión TCP con el agente de transferencia de mensajes en el puerto 110. Una vez que se ha establecido la conexión, el protocolo POP3 pasa por tres estados en secuencia: 1. Autorización. 2. Transacciones. 3. Actualización. El estado de autorización tiene que ver con el inicio de sesión por parte del usuario, el cliente envía su nombre de usuario y después su contraseña. El estado de transacción se relaciona con el hecho de que el usuario colecte los mensajes de correo electrónico y los marque para eliminación desde el buzón. El estado de actualización se encarga de que los mensajes de correo electrónico se eliminen realmente. Si bien es cierto que el protocolo POP3 soporta la capacidad de descargar un mensaje específico o un conjunto de mensajes y dejarlos en el servidor, la mayoría de los programas de correo electrónico simplemente descarga todo y vacía el buzón. Este comportamiento significa que en la práctica, la única copia está en el disco duro del usuario. Si se cae, es posible que se pierda de manera permanente todo el correo electrónico. Resumamos brevemente la forma en que funciona el correo electrónico para los clientes ISP. Elena utiliza un programa de correo electrónico (es decir, un agente de usuario) para crear un mensaje para Giovanna y hace clic en un icono para enviarlo. El programa de correo electrónico entrega el mensaje al agente de transferencia de mensajes del host de Elena. Dicho agente ve que el mensaje está dirigido a [email protected] por lo que utiliza DNS para buscar el registro MX de xyz.com (donde xyz.com es el ISP de Giovanna). Esta consulta regresa el nombre del DNS del servidor de correo de xyz.com. El agente de transferencia de mensajes ahora busca la dirección IP de esta máquina utilizando nuevamente DNS, por ejemplo, gethostbyname. Después establece una conexión TCP con el servidor SMTP en el puerto 25 de esta máquina. A continuación utiliza una secuencia de comandos SMTP análoga a la de la figura 5.12 para transferir el mensaje al buzón de Giovanna y termina la conexión TCP. A su debido tiempo, Giovanna arranca su PC, se conecta a su ISP e inicia su programa de correo electrónico. Éste establece una conexión TCP con el servidor POP3 en el puerto 110 de la máquina servidora de correo del ISP. Por lo general, el nombre del DNS o la dirección IP de esta máquina se configura cuando se instala el programa de correo electrónico o "cuando se realiza la suscripción al ISP. Una vez que se ha establecido la conexión TCP, el programa de correo electrónico de Giovanna se ejecuta en el protocolo POP3 para obtener el contenido del buzón a su disco duro. Una vez que se ha transferido todo el correo electrónico, se libera la conexión TCP. De hecho, la conexión con el ISP también puede terminarse ahora, puesto que todo el correo electrónico se encuentra en el disco duro de la máquina de Giovanna. Por supuesto, para enviar una respuesta, será necesaria otra vez la

65



ESPOCH-FIE-EIS

conexión con el ISP, por lo que generalmente dicha conexión no se termina después de obtener el correo electrónico.

5.6.2 IMAP Para un usuario que tiene una cuenta de correo electrónico con un ISP que siempre accede desde una PC, POP3 es adecuado y se utiliza ampliamente debido a su sencillez y robustez. Sin embargo, es un axioma de la industria de la computación el hecho de que siempre que algo funciona bien, alguien comienza a pedir más características (y a obtener más errores). Eso también sucedió con el correo electrónico. Por ejemplo, muchas personas tienen una sola cuenta de correo electrónico en el trabajo o en la universidad y desean accederla desde el trabajo, desde la PC de su casa, desde su computadora portátil cuando están en viaje de negocios y desde algún cibercafé cuando se encuentran de vacaciones. Aunque POP3 permite esto, debido a que descarga todos los mensajes almacenados en cada contacto, el resultado es que los mensajes de correo electrónico del usuario quedan esparcidos rápidamente en múltiples máquinas, más o menos de manera aleatoria, y algunos de ellos ni siquiera en la máquina del usuario. Esta desventaja dio lugar a un protocolo de entrega final alternativo, IMAP (Protocolo de Acceso a Mensajes de Internet ), que se define en el RFC 2060. A diferencia de POP3, que asume básicamente que el usuario vaciará el buzón de cada contacto y trabajará sin conexión después de eso, IMAP supone que todo el correo electrónico permanecerá en el servidor de manera indefinida en múltiples buzones de correo. IMAP proporciona mecanismos de gran alcance para leer mensajes o incluso partes de un mensaje, una característica útil cuando se utiliza un módem lento para leer parte del texto de un mensaje dividido en varios fragmentos y que tiene archivos adjuntos grandes de audio y vídeo. Debido a que la suposición más razonable es que los mensajes no se transferirán a la computadora del usuario para un almacenamiento permanente, IMAP proporciona mecanismos para crear, destruir y manipular múltiples buzones en el servidor. De esta forma, un usuario puede mantener un buzón para cada uno de sus contactos y colocar ahí mensajes de la bandeja de entrada después de que se han leído. IMAP tiene muchas características, como la capacidad de dirigir correo no por número de llegada, como se hace en la figura 5.4, sino utilizando atributos (por ejemplo, dame el primer mensaje de Juan). A diferencia de POP3, IMAP también puede aceptar correo saliente para enviarlo al destino, así como entregar correo electrónico entrante. El estilo general del protocolo IMAP es similar al de POP3, excepto que hay docenas de comandos. El servidor IMAP escucha en el puerto 143. En la figura 5.14 se muestra una comparación de POP3 e IMAP. Sin embargo, se debe mencionar que no todos los ISPs ni todos los programas de correo electrónico soportan ambos protocolos. Por lo tanto, cuando se elige un programa de correo electrónico, es importante averiguar qué protocolos soporta y asegurarse de que el ISP soporte por lo menos uno de ellos.

66



Característica En dónde se define el protocolo Puerto TCP utilizado En dónde se almacena el correo En dónde se lee el correo electrónico Tiempo de conexión requerido Uso de recursos del servidor Múltiples buzones Quién respalda los buzones Bueno para los usuarios móviles Control del usuario sobre la descarga Descargas parciales de mensajes ¿Es un problema el espacio en disco? Sencillo de implementar Soporte amplio

POP3 RFC1939 110 PC del usuario Sin conexión Poco Mínimo No Usuario No .. Poco No No Sí Sí

ESPOCH-FIE-EIS

IMAP RFC 2060 143 Servidor En línea Mucho Amplio Sí ISP Si Mucho Sí Con el tiempo podría serlo No En crecimiento

Figura 5.14. Comparación entré POP3 e IMAP 5.6.3 CARACTERÍSTICAS DE LA ENTREGA DE CORREO ELECTRÓNICO Una característica especialmente valiosa para muchos usuarios de correo electrónico es la capacidad de establecer filtros. Éstas son reglas que se verifican cuando llega el correo electrónico o cuando se inicia el agente de usuario. Cada regla especifica una condición y una acción. Por ejemplo, una regla podría decir que cualquier mensaje del jefe va al buzón número 1, cualquier mensaje de un grupo seleccionado de amigos va al buzón número 2, y cualquier mensaje que contenga en la línea Asunto ciertas palabras objetables se descarta sin ningún comentario. Algunos ISPs proporcionan un filtro que clasifica de manera automática el correo electrónico como importante o como publicidad no deseada (correo basura) y almacena cada mensaje en el buzón correspondiente. Por lo general, tales filtros funcionan verificando primero si el origen es un spammer (persona que envía correo basura) conocido. A continuación, por lo general examinan la línea de asunto. Si cientos de usuarios han recibido un mensaje con la misma línea de asunto, probablemente sea correo basura. También se utilizan otras técnicas para la detección de correo basura. Otra característica de entrega que por lo general se proporciona es la capacidad de reenviar (de manera temporal) correo electrónico entrante a una dirección diferente, la cual puede ser una computadora manejada por un servicio de localización comercial, el cual a continuación localiza al usuario por radio o satélite y le indica que tiene un mensaje en su localizador. Otra característica común de la entrega final es la capacidad de instalar un demonio de vacaciones. Éste es un programa que examina cada mensaje entrante y envía al emisor una respuesta grabada como Hola. Estoy de vacaciones. Regresaré el 24 de agosto. Tenga un buen fin de semana.

67



ESPOCH-FIE-EIS

Tales respuestas también pueden especificar cómo manejar asuntos urgentes, las personas a quienes se puede acudir en caso de problemas específicos, etcétera. La mayoría de los demonios de vacaciones lleva un registro de a quién le ha enviado respuestas grabadas y se abstiene de enviar a la misma persona una segunda respuesta. Los buenos demonios también verifican si los mensajes entrantes se enviaron a una lista de correo, y de ser así, no envían una respuesta grabada. (Las personas que envían mensajes a listas de correo grandes durante el verano probablemente no desean obtener cientos de respuestas que detallen los planes de vacaciones de todos los demás.

5.6.4 CORREO DE WEB Algunos sitios Web, como Hotmail y Yahoo, proporcionan servicio de correo electrónico a cualquiera que lo desee. Funcionan como se menciona a continuación. Tienen agentes de transferencia de mensajes normales que escuchan el puerto 25 para conexiones SMTP entrantes. Para contactar, digamos, Hotmail, usted tiene que adquirir su registro MX de DNS. La parte interesante es la forma en que se entrega el correo electrónico. Básicamente, cuando el usuario va a la página Web de correo electrónico, se despliega un formulario en el que se pide al usuario que introduzca un nombre de usuario y una contraseña. Cuando el usuario hace clic en Registrarse, el nombre de usuario y la contraseña se envían al servidor, quien los valida. Si el inicio de sesión es exitoso, el servidor encuentra el buzón del usuario y construye una lista similar a la de la figura 5.4, sólo que formateada como página Web en HTML. Esta página Web se envía al navegador para su despliegue. En muchos de los elementos de la página se puede hacer clic, por lo que los mensajes se pueden leer, eliminar, etcétera.

5.7

AMENAZAS DE SEGURIDAD EN EL CORREO ELECTRÓNICO

El correo electrónico es una herramienta maravillosa en Internet, pero conlleva amenazas a su privacidad y seguridad. Entre las amenazas, tenemos las bombas y el correo no autorizado (spam.), así como los riesgo de descargar ciertos documentos adjuntos. Uno de los puntos débiles principales de los mensajes de correo electrónico es que no siempre puede ser rastreado su origen. Otra amenaza de correo electrónico también incluye a personas que examinan los mensajes de otros en busca de información valiosa, por ejemplo una tarjeta de crédito, el número del seguro social o información de autenticación de sistemas. Cuando un mensaje de correo electrónico viaja a través de Internet, puede quedar expuesto a programas pequeños que automáticamente examinan el mensaje enviado a una computadora, buscan información específica, del mismo modo que usted lo hace en su programa de correo electrónico cuando desea localizar un mensaje en particular almacenado en una de sus carpetas. Una buena medida preventiva para este tipo de ataque es mediante el encriptado de mensaje que dificulta la actividad de los hackers. Además, existen muchas herramientas de encriptado, como Pretty Good Prívacy (PGP) y firmas digitales. 68



ESPOCH-FIE-EIS

Las bombas de correo electrónico es una forma de acecho, un tipo anónimo de acoso al cual no se puede responder. Las bombas de correo electrónico son ilegales y difíciles de rastrear debido a las formas anónimas en que puede enviarse el correo electrónico, por lo general consiste en el envío de grandes cantidades de mensajes de correo electrónico, desde cientos hasta miles de mensajes, hacia una sola dirección, lo cual comúnmente genera una negación del servicio (DoS) en el servidor de correo. Pero no hay que confundir las bombas de correo electrónico con el correo no autorizado (spam). Las bombas de correo electrónico se caracterizan por que personas abusivas envían repetidamente varias copias del mismo mensaje de correo a una dirección particular, en cambio, el correo no autorizado es una variante de las bombas, se refiere al envío del mismo mensaje de correo a cientos de usuarios (o a listas que contienen muchos usuarios). El correo electrónico puede empeorar si los destinatarios lo responden provocando que todas las direcciones originales reciban la respuesta. Este tipo de correo también puede ocurrir de una manera inocente, cuando alguien envía un mensaje a una lista de correo sin darse cuenta de que la lista se dispara a miles de usuarios, o como resultado de un mensaje de respuesta configurado incorrectamente. Si se altera la identidad de la cuenta que envió el mensaje, entonces las bombas de correo electrónico o el correo electrónico no autorizado se combinan con la suplantación, lo cual hace casi imposible rastrear al autor y el origen del mensaje. La gran cantidad de mensajes de correo electrónico que llega a un servidor como resultado de las bombas de correo electrónico y correos no autorizados puede generar una negación del servicio en el servidor (el servidor niega una solicitud o tarea por no poder cumplirla, hasta el extremo de congelarse), mediante la pérdida de la conectividad en red, colapsos del sistema o incluso la falla de un servicio (donde el servidor pierde la capacidad de ejecutar el servicio) por las siguientes razones: • Conexiones de red sobrecargadas • Recursos del sistema al límite • Disco lleno como resultado de múltiples mensajes recibidos y registros de

bitácoras de syslog

5.7.1 PREVENCIÓN DE LOS ATAQUES DE CORREO ELECTRÓNICO Es muy importante que detecte las bombas de correo electrónico o el correo no autorizado lo más pronto posible. Una de las señales que presentará su sistema cuando esté bajo ataque es la lentitud. Si el correo electrónico es lento o no se envía o recibe, podría ser que su servidor de correo esté tratando de procesar una gran cantidad de mensajes, o ya ha sufrido una negación del servicio. Si se experimenta una condición semejante en el servidor, haga lo siguiente: 

Identifique el origen del correo electrónico revisando los encabezados y reconfigurando inmediatamente su firewall (o enrutador) para bloquear los paquetes que llegan desde esa dirección. Tenga cuidado antes de asumir que el 69



ESPOCH-FIE-EIS

autor del ataque es la persona que muestra el encabezado del mensaje, debido a que muchas veces el nombre que aparece ahí es un alias, en un intento por ocultar su verdadera identidad. 



Si su servicio de correo electrónico lo recibe a través de un Internet Service Provider (ISP, Proveedor de servicios de Internet), infórmele sobre el incidente de la bomba o el correo no autorizado, de tal manera que pueda volver a reconfigurar su enrutador o firewall para impedir que los mensajes lleguen, desde la dirección de origen. Entre en contacto con el Computer Emergency Response Team (CERT, Equipo de Respuesta ante Emergencias de Cómputo) en [email protected] e infórmele sobre el ataque, para que él pueda rastrear los incidentes. El compromiso del centro de coordinación del CERT es trabajar con la comunidad de Internet para facilitar su respuesta a los eventos de cómputo que involucran los hosts de Internet, dar pasos proactivos hacia una mayor concienciación por parte de la comunidad respecto a los problemas de la seguridad de cómputo y conducir una investigación dirigida a mejorar la seguridad de los sistemas existentes.

No hay manera de bloquear las bombas de correo electrónico ni el correo chatarra en su totalidad. Sin embargo, hay unas cuantas cosas que puede hacer para protegerse a sí mismo y disminuir la probabilidad de un ataque de bombas o correo chatarra. Primero, debe mantener su software de correo electrónico actualizado en todo momento. Segundo , asegúrese de mantener las actualizaciones, correcciones y arreglos de errores que publica su desarrollador de correo electrónico. Lo tercero es un poco más técnico. Usted podría desarrollar una herramienta que haría revisiones y le alertaría de mensajes de entrada que se originan del mismo usuario o del mismo sitio en un breve periodo. Luego podría bloquear estas conexiones a nivel de enrutador. Probablemente usted no podrá identificar al autor de estos mensajes, pero al menos puede dejar de recibirlos al bloquearlos antes de que lleguen a su buzón de correo. Una alternativa a considerar es que si usted tiene uno o dos servidores de correo, asegúrese de configurar su firewall para permitir sólo conexiones SMTP que vengan desde Internet hacia su servidor de correo electrónico. Desde ahí, usted deberá bloquear el puerto SMTP y negar el permiso a las conexiones que llegan directamente a las computadoras del usuario. La manera de hacer esto variará de un software de firewall a otro. Si usted está utilizando un enrutador como firewall, deberá insertar una línea en su archivo de con figuración negando las conexiones al puerto SMTP. Al bloquear el acceso a su puerto SMTP, se impedirá la inyección de mensajes de correo no autorizados a través de él. Debe tenerse cuidado con los archivos adjuntos en los mensajes de correo electrónico. La mayoría de los paquetes de correo, tienen una configuración en la cual usted puede especificar si desea que los archivos adjuntos vayan como archivos separados o se encapsulen. El riesgo con estos archivos adjuntos es que 70



ESPOCH-FIE-EIS

pueden contener varias amenazas, desde virus y macros maliciosas hasta pequeños caballos de Troya. Los virus pueden ser insertados en. los archivos adjuntos de un mensaje de correo electrónico, como parte del encabezado o incluso como parte del cuerpo del mensaje. Algunos de los virus actuales y códigos de bombas lógicas de mayor éxito y más peligrosos están basados en documentos, y como probablemente sabrá, la mayoría de los archivos adjuntos a los mensajes de correo electrónico también son documentos. Por consiguiente, se vuelven una de las maneras más fáciles de hacer llegar un virus a su computadora o compañía. Con el fin de protegerle contra una amenaza semejante, debe ser muy cuidadoso cuando abra un archivo adjunto, ya que son los portadores del peligro. Asegúrese de conocer su origen y de que puede confiar en que el archivo adjunto está limpio y libre de errores. Si no puede, debe utilizar un detector de virus de correo electrónico, para examinar los mensajes que recibe. Debe darse especial atención a los archivos adjuntos comprimidos con zip o codificados, ya que muchas veces los paquetes antivirus los omiten o no los soportan. Estos archivos adjuntos podrían contener virus o bombas de macros. Existen virus que pueden obtener acceso a una computadora a través de los archivos adjuntos que usted descarga o abre desde su correo, los cuales aparentemente podrían dañar su computadora. Aun cuando los medios afirman que los virus pueden dañar el hardware de su computadora, nunca he visto uno que sea capaz de hacerlo. Sin embargo, existen virus que pueden hacer que su disco duro se comporte como si tuviera errores. Los paquetes antivirus de correo electrónico pueden examinar los mensajes de correo electrónico conforme llegan desde el sistema de correo host. Al hacer uso de un proceso recursivo de desensamblado, estas aplicaciones pueden abrir completamente sus mensajes y cualquier archivo adjunto de tal forma que las herramientas antivirus puedan examinar en busca de virus incrustados en los datos. De la misma forma para los virus de macros, asegúrese de descargar la última versión de los antivirus de macros de Word/Excel. Si la seguridad de su conexión SMTP y los mensajes corporativos que viajan a través de ella son realmente importantes, es recomendable que considere utilizar el Riordan's Internet Privacy Enhanced Mail (RIPEM, Correo de Privacidad Mejorada de Internet de Riordan), el cual es una implementación práctica del Privacy Enhanced Mail (PEM, Correo de Privacidad Mejorada). PEM es una norma para permitir la transferencia de correo electrónico encriptado que ha sido generado a través de un periodo largo, mediante un grupo de trabajo de especialistas. Observe que RIPEM en realidad no es una implementación completa de PEM. RIPEM especifica los certificados para llaves de autenticación, y no los maneja aún. La adición de autenticación de llaves está planeada para un futuro próximo, así como para la versión de Macintosh, la cual es diferente de la versión de PC, debido a que los sistemas operativos son distintos. RIPEM proporciona a su

71



ESPOCH-FIE-EIS

correo SMTP las facilidades de seguridad provistas por PEM (RFCs 1421 al 1424), las cuales son: 8 







Protección contra revelación, la cual es opcional y protege el contenido de los mensajes de una revelación no autorizada. Autenticidad del creador, que permite la verificación de la firma digital y de la fiabilidad de un mensaje. Medidas de integridad de los mensajes, que aseguran que el mensaje no se modificó durante la transmisión. Sin capacidad de rechazo de origen, lo cual permite verificar la identidad del remitente original del mensaje.

Pretty Good Privacy (PGP) de Phil Zimmermann es otro producto que puede utilizar para encriptar sus mensajes de SMTP.

Protocolo de Oficina Postal (POP) Tenga en mente que cuando usted se ocupa de la configuración POP, en última instancia está tratando con información privada que entra y sale a través de la sesión POP. Se está lidiando con problemas como confidencialidad, integridad y responsabilidad. Así que es recomendable no permitir que los usuarios transfieran correo por Internet a través de POP debido a que puede revelar las contraseñas, y los mensajes están completamente desprotegidos. Si deben transferir correo, entonces implemente filtrado de paquetes. Es posible que también pueda implementar algún proxy pero requerirá alguna codificación.

Extensiones para Correo Internet de Múltiples Propósitos (MIME) Lamentablemente, MIME no es seguro. Por tanto, RSA desarrolló S/MIME (RFCs 2632 al 2643) , el cual es una especificación para MIME seguro al ofrecer autenticación (utilizando firmas digitales) y privacidad (empleando encriptación). S/MIME, PGP y PEM son similares porque especifican métodos para asegurar su correo electrónico. Sin embargo, PGP puede considerarse tanto una especificación como una aplicación, debido a que se basa en los usuarios para intercambiar llaves y para establecer la confianza mutua. S/MIME, por otra parte, utiliza jerarquías en las cuales los roles del usuario y del certificador se formalizan, lo cual vuelve a S/MIME más seguro y más escalable que las implementaciones de PGP. Si fuéramos a comparar PEM con S/MIME, necesitaríamos tomar en consideración que PEM es un estándar para asegurar el correo electrónico, que especifica un formato de mensaje y una estructura de jerarquías. El formato de mensaje PEM está basado en mensajes de texto de 7 bits mientras que S/MIME está diseñado para trabajar con adjuntos binarios MIME así como con texto. Los lineamientos para jerarquías también son más flexibles en S/MIME. Esto debería permitir una instalación fácil para grupos de trabajo pequeños que no necesitan ser parte de una jerarquía que abarque todo y una ruta fácil para mover grupos de trabajo a la jerarquía que se adapta mejor a sus necesidades. 8

Goncalves Marcus. Manual de Firewalls. Pág. 307.

72


5.8


ESPOCH-FIE-EIS

EJERCICIOS

1. ¿Tiene ventajas un identificador de buzón numérico sobre un identificador mnemónico? Explique. 2. Algunos fabricantes de programas de correo electrónico añaden una línea a la cabecera de los mensajes de correo con su nombre o el del producto con el que se creó. ¿Tiene tal información algún uso más allá de fines publicitarios? 3. ¿Cuánto tiempo querría que se guardara un mensaje transmitido si el sistema de correo no puede establecer la comunicación con la computadora destino? ¿Por qué? 4. Si se envía un mensaje a una lista de correo, ¿se garantiza que todos los destinatarios de la lista reciban copias? Explique. 5. Algunos programas de lista de correo reescriben las líneas From: de la cabecera de los mensajes enviados a la lista para que parezca que el mensaje fue transmitido desde la lista, en lugar de por una persona. La ventaja es que, si el destinatario responde, todos reciben copias de la respuesta. ¿Cuál es el peligro de reescribir las cabeceras? Sugerencia: imagine que una de las direcciones de la lista tiene un error tipográfico. 6. Algunas instalaciones ejecutan un programa llamado mailer para que los usuarios puedan crear seudónimos de sus direcciones de correo electrónico. El usuario recibirá el correo enviado a cualquiera de los seudónimos. ¿Cuál es la ventaja y la desventaja principal de tales seudónimos? 7. Lea el estándar MIME . ¿Qué servidores pueden especificarse en una referencia externa MIME?. 8. Lea el estándar SMTP. Luego, use TELNET para conectarse a un puerto SMTP en una máquina remota y solicite al servidor SMTP remoto que expanda un alias de correo. 9. Averiguar con qué frecuencia su sistema de correo local trata de realizar entregas y durante cuánto tiempo realiza los intentos. 10. Los sistemas de correo electrónico necesitan directorios a fin de que se puedan buscar las direcciones de correo electrónico de las personas. Para construir tales directorios y para que la búsqueda sea posible, los nombres deben dividirse en componentes estándar (por ejemplo, nombre, apellido). Mencione algunos problemas que deben resolverse a fin de que un estándar mundial sea aceptable. 11. La dirección de correo electrónico de una persona es su nombre de inicio de sesión + @ + el nombre .Sífís'de un dominio DNS con un registro MX. Los nombres de inicio de sesión pueden ser nombres de pila. apellidos, iniciales y todos los tipos de nombres. Suponga que una compañía grande decidió que se estaba perdiendo mucho correo debido a que las personas no sabían el nombre de inicio de sesión del receptor. ¿Hay alguna forma de que dicha compañía

73



ESPOCH-FIE-EIS

arregle este problema sin cambiar el DNS? De ser así, dé una propuesta y explique cómo funciona. De lo contrario, explique por qué no es posible. 12. Nombre cinco tipos MIME que no se listan en este texto. Puede verificar su navegador o Internet para obtener información. 13. Suponga que desea enviar un archivo MP3 a un amigo, pero el ISP de éste limita a 1 MB la cantidad de correo entrante y el archivo MP3 es de 4 MB. ¿Hay alguna forma para manejar esta situación utilizando el RFC 822 y MIME? 14. Suponga que alguien establece un demonio de vacaciones y que después envía un mensaje justo antes de terminar su sesión. Desgraciadamente, el receptor ha estado de vacaciones una semana y también tiene un demonio de vacaciones en su lugar. ¿Qué sucede a continuación? Las respuestas grabadas se enviarán y regresarán hasta que alguien regrese? 15. En cualquier estándar, como el RFC 822, se necesita una gramática precisa de lo que está permitido de manera que diferentes implementaciones puedan interactuar. Incluso los elementos simples se tienen que definir con cuidado. Los encabezados SMTP permiten espacios en blanco entre los tokens. Dé dos definiciones de alternativas razonables de espacios en blanco entre los tokens. 16. ¿El demonio de vacaciones es parte del agente de usuario o del agente de transferencia de mensajes? Por supuesto, se establece con el agente de usuario, pero ¿éste envía realmente las respuestas? Explique. 17. POP3 permite que los usuarios obtengan y bajen correo electrónico de un buzón remoto. ¿Esto significa que el formato interno de los buzones debe estandarizarse para que cualquier programa POP3 en el cliente pueda leer el buzón en cualquier servidor de correo? Explique su respuesta. 18. Desde el punto de vista de un ISP, POP3 e IMAP tienen diferencias importantes. Por lo general, los usuarios de POP3 vacían sus buzones todos los días. Los usuarios de IMAP mantienen su correo electrónico en el servidor de manera indefinida. Imagine que se le pide a usted que aconseje a un ISP sobre cuáles protocolos debe soportar. ¿Qué aspectos tomaría en cuenta? 19. ¿Webmail utiliza POP3, IMAP o ninguno? Si utiliza alguno de éstos, ¿por qué se eligió? Si no se utiliza ninguno, ¿cuál está más cerca de ser usado?

74



ESPOCH-FIE-EIS

CAPITULO VI WORLD WIDE WEB 6.1 INTRODUCCION La WWW es un armazón arquitectónico para acceder a documentos vinculados distribuidos en miles de máquinas de todo el Internet; su enorme popularidad se deriva del hecho de que tiene una interfaz gráfica atractiva que es fácil de usar y proporciona una enorme cantidad de información sobre casi cualquier tema. Los comienzos de la Web fue en 1989 en el CERN (Centro Europeo de Investigación Nuclear); surge por la necesidad de lograr que sus grupos de investigadores dispersos internacionalmente colaboren usando un conjunto siempre cambiante de informes, planos, dibujos, fotos y otros documentos. La idea inicial de una red de documentos vinculados fue del físico del CERN Tim Berners-Lee en marzo de 1989 y Marc Andreessen de la Universidad de Illinois desarrollo el primer navegador gráfico conocido como Mosaic que fue dado a conocer en 1993, desde entonces se han creado algunos navegadores como Netscape Navigator, Microsoft Internet Explorer, etc. Desde el punto de vista de los usuarios la Web consiste en un enorme conjunto de documentos a nivel mundial, denominados páginas Web. Cada página puede contener vínculos a otras páginas relacionadas en cualquier parte del mundo; esta idea conocida como hipertexto fue inventada por Vannevar Bush en 1945, mucho antes de que se inventara Internet. SERVIDOR www.espoch.edu.ec

CLIENTE Página desplegada en el navegador

Giovanna Silvana Xavier Maria

hipervínculo Programa navegador

SERVIDOR www.conesup.net

hipervínculo Giovanna Silvana Xavier Maria

Disco

Hola ESPOCH

Programa servidor web

Disco

Programa servidor web

INTERNET

Figura 6.1 Componentes del modelo Web En la figura 6.1 se muestra el modelo básico de la forma en que funciona la Web. Aquí el navegador despliega una página Web en la máquina cliente. Cuando el 75



ESPOCH-FIE-EIS

usuario hace clic en una línea de texto que esta vinculada a una página del servidor www.espoch.edu.ec, el navegador sigue el hipervínculo enviándole un mensaje al servidor www.espoch.edu.ec en el mismo que solicita la página. Cuando esta llega se despliega. Si contiene un hipervínculo a la página del servidor www.conesup.net en el que se hace clic, el navegador a continuación envía un mensaje a dicha máquina solicitando esa página, y así deforma indefinida.

6.2 EL CLIENTE En esencia, un navegador es un programa que puede desplegar una página Web y atrapar los clics que se hacen en los elementos de la página desplegada. Cuando se selecciona un elemento, el navegador sigue el hipervínculo y obtiene la página seleccionada. Por lo tanto, el hipervínculo incrustado necesita una manera de nombrar cualquier página que se encuentre en la Web. Las páginas se nombran utilizando URLs (Localizadores Uniformes de Recursos). Un URL típico es http://www.espoch.edu.ec/sistemas.html El URL tiene tres partes: el nombre del protocolo (http), el nombre DNS de la máquina donde se localiza la página (www.espoch.edu.ec) y (por lo general) el nombre del archivo que contiene la página ( sitemas.html ). Cuando un usuario hace clic en un hipervínculo, el navegador lleva a cabo una serie de pasos para obtener la página a la que se está apuntado. 1. 2. 3. 4. 5. 6. 7. 8. 9.

El navegador determina el URL (enviando lo que se seleccionó). El navegador pide al DNS la dirección IP de www.espoch.edu.ec DNS responde con 201.218.5.2. El navegador realiza una conexión TCP con el puerto 80 en 201.218.5.2. Después envía un mensaje en el que solicita el archivo /sistemas .html. El servidor www.espoch.edu.ec envía el archivo /sistemas. html. Se libera la conexión TCP. El navegador despliega todo el texto de /sistemas.html. El navegador obtiene y despliega todas las imágenes del archivo.

Muchos navegadores despliegan en una línea de estado, que se encuentra en la parte inferior de la pantalla, qué paso están ejecutando actualmente. De esta manera, cuando el desempeño es pobre, el usuario puede ver si se debe a que el DNS o el servidor no están respondiendo, o simplemente hay congestionamiento en la red durante la transmisión de la página. Para poder desplegar la nueva página (o cualquiera), el navegador tiene que entender su formato. Para permitir que todos los navegadores entiendan todas las páginas Web, éstas se escriben en un lenguaje estandarizado llamado HTML , el cual las describe. Aunque un navegador es básicamente un intérprete HTML, la mayoría de los navegadores tiene varios botones y características para facilitar la navegación en la Web. La mayoría tiene un botón para regresar a la página anterior, uno para ir a la siguiente (el cual sólo funciona una vez que el usuario ha regresado de esa página) y uno para ir directamente a la página de inicio del usuario. La mayoría de los 76



ESPOCH-FIE-EIS

navegadores tiene un botón o elemento para establecer un marcador y otro para desplegar la lista de marcadores, lo que hace posible volver a visitar cualquiera de ellos con sólo algunos clics del ratón. Las páginas también pueden guardarse en disco o imprimirse. Por lo general, hay varias opciones disponibles para controlar el diseño de la pantalla y establecer varias preferencias de usuario. Además de tener texto ordinario (que no está subrayado) e hipertexto (texto subrayado), las paginas Web también pueden tener iconos, dibujos de líneas, mapas y fotografías. Cada uno de éstos puede (opcionalmente) vincularse a otra página. Hacer clic en alguno de estos elementos causa que el navegador obtenga la página vinculada y la despliegue en pantalla, al igual que al hacer clic en el texto. En el caso de imágenes como fotos y mapas, la página que se obtenga a continuación depende de en cuál parte de la imagen se hizo clic. No todas las páginas contienen HTML. Una página puede consistir en un documento con formato PDF, un icono con formato GIF, una fotografía con formato JPEG, una canción con formato MP3, un vídeo con formato MPEG, o cualquiera de los cientos de los otros tipos de archivos. Puesto que las páginas HTML estándar pueden vincular cualquiera de éstos, el navegador tiene un problema cuando encuentra una página que no puede interpretar. En lugar de agrandarse cada vez más los navegadores incorporándoles intérpretes para una colección creciente de tipos de archivos, la mayoría de los navegadores ha elegido una solución más general. Cuando un servidor regresa una página, también regresa alguna información adicional acerca de ella. Dicha información incluye el tipo MIME de la página (figura 5.8). Las páginas del tipo text/html se despliegan de manera directa, como las páginas de algunos otros tipos integrados. Si el tipo MIME no es de los integrados, el navegador consulta su tabla de tipos MIME que le indique cómo desplegar la página. Esta tabla asocia un tipo MIME con un visor.

6.2.1 ARQUITECTURA DEL VISUALIZADOR El visualizador maneja la mayoría de detalles de acceso y presentación del documento, en consecuencia tiene varios componentes grandes de software que interectúan para dar la impresión de un servicio uniforme. En la figura 6.2 se presenta la organización conceptual de un visualizador, el cual consta de un grupo de clientes (HTML, FTP, Telnet etc.), un grupo de interpretes, y un controlador que los administra que es la parte central del visualizador. Interpreta tanto los clics del ratón como la entrada del teclado y llama a otros componentes para llevar a cabo las operaciones indicadas por el usuario. Cada visualizador debe tener un intérprete HTML para presentar los documentos. Son opcionales otros intérpretes. La entrada de un intérprete HTML consta de un documento que se adapta a la sintaxis HTML; la salida consiste en una versión formateada del documento en la pantalla del usuario. El intérprete se encarga de los detalles de la presentación y traduce las especificaciones HTML en comandos adecuados al hardware de presentación del usuario. Por ejemplo, si encuentra una referencia de cabecera en el documento, el intérprete cambia el tamaño de la fuente

77



ESPOCH-FIE-EIS

de la cabecera. De igual manera, si encuentra una referencia de salto de línea, inicia una nueva línea de salida. 9 Una de las funciones más importantes de un intérprete HTML se relaciona con los elementos seleccionables. El intérprete debe almacenar la relación entre las posiciones de la pantalla y los elementos anclados del documento HTML. Cuando el usuario selecciona un elemento con el ratón, el visualizador toma la posición de cursor actual y la información de posición almacenada para determinar el elemento seleccionado por el usuario.

Figura 6.2 Componentes principales de un visualizador Web Además de un cliente HTTP y un intérprete HTML, el visualizador puede tener componentes que le permiten desempeñar otras tareas. Por ejemplo, muchos visualizadores incluyen un cliente FTP con el que se puede acceder al servicio dé transferencia de archivos. Algunos visualizadores también tienen un cliente de correo electrónico para transmitir y recibir mensajes. ¿Cómo puede el usuario acceder a un servicio como el FTP desde un visualizador? La respuesta es que el usuario no llama a tales servicios explícitamente ni interactúa con un software cliente convencional. En cambio, el visualizador llama automáticamente al servicio y con él lleva a cabo una tarea. Si el visualizador está bien diseñado, oculta al usuario los detalles, de modo que tal vez no se dé cuenta de que se ha llamado un servicio opcional. Por ejemplo, puede asociarse una transferencia de archivos con un elemento seleccionable de la pantalla. Cuando el

9

Comer Douglas. Redes de computadoras, internet e interredes. Pág. 373.

78



ESPOCH-FIE-EIS

usuario selecciona el elemento, el visualizador emplea su cliente FTP para traer una copia del archivo. ¿Cómo puede especificarse la transferencia de archivos en una página de Web? Recuerde que el primer campo de un URL indica un protocolo. El controlador usa el campo para determinar el cliente a llamar. Por ejemplo, si el URL indica http, el controlador llama al cliente HTTP. De la misma manera, el URL: ftp://ftp.espoch.edu.ec/sistemas/linux.c indica que el visualizador debe usar FTP anónimo para traer el archivo sistemas /linux.c de la computadora ftp.espoch.edu.ec.

6.3 EL SERVIDOR Cuando el usuario digita un URL o hace clic en una línea de hipertexto, el navegador lo analiza e interpreta la parte entre http:// y la siguiente diagonal como un nombre DNS a buscar. Una vez que él navegador tiene la dirección IP del servidor, establece una conexión TCP con el puerto 80 de ese servidor. A continuación envía un comando que contiene el resto del URL, que es el nombre del archivo que se encuentra en ese servidor. Éste regresa el archivo para que el navegador lo despliegue. Al servidor Web, lo que se le proporciona es el nombre del archivo a buscar y regresar. Los pasos que da el servidor en su ciclo principal son: 1. 2. 3. 4. 5.

Acepta una conexión TCP de un cliente (un navegador). Obtiene el nombre del archivo solicitado. Obtiene el archivo (del disco). Regresa el archivo al cliente. Libera la conexión TCP.

Los servidores Web modernos hacen más que sólo aceptar y regresar nombres de archivos. De hecho, el procesamiento real de cada solicitud puede ser muy complicado. Por esta razón, en muchos servidores cada módulo de procesamiento realiza una serie de pasos. El front end pasa cada solicitud entrante al primer módulo disponible, que después la transporta mediante algunos de los siguientes pasos, dependiendo de los que sean necesarios para esa solicitud en particular. 1. Resuelve el nombre de la página Web solicitada. 2. Autentica al cliente. 3. Realiza control de acceso en el cliente. 4. Realiza control de acceso en la página Web. 5. Verifica el caché. 6. Obtiene del disco la página solicitada. 7. Determina el tipo MIME que se incluirá en la respuesta. 8. Se encarga de diversos detalles. 9. Regresa la respuesta al cliente. 10. Realiza una entrada en el registro del servidor.

79



ESPOCH-FIE-EIS

El paso 1 es necesario porque la solicitud entrante tal vez no contenga el nombre real del archivo como una cadena literal. Por ejemplo, considere el URL http://www.cs.vu.nl, que tiene un nombre de archivo vacío. Tiene que expandirse a algún nombre de archivo predeterminado. Además, los navegadores modernos pueden especificar el lenguaje predeterminado del usuario (por ejemplo, italiano o inglés), lo cual posibilita que el servidor seleccione una página Web en ese lenguaje, si está disponible. En general, la expansión de nombres no es tan trivial como podría parecer a primera vista, debido a una variedad de convenciones acerca de la asignación de nombres de archivos. El paso 2 consiste en verificar la identidad del cliente. Este paso es necesario para las páginas que no están disponibles para el público en general. El paso 3 verifica si hay restricciones con respecto a si la solicitud se puede satisfacer a partir de la identidad y ubicación del cliente. El paso 4 verifica si hay restricciones de acceso asociadas con la página misma. Si cierto archivo (por ejemplo, .htaccess) se encuentra en el directorio donde se localiza la página deseada, ésta puede prohibir que dominios particulares accedan al archivo; por ejemplo, tal vez sólo permita que usuarios que están dentro de la compañía accedan al archivo. Los pasos 5 y 6 consisten en obtener la página. El paso 6 necesita poder manejar múltiples lecturas de disco al mismo tiempo. El paso 7 consiste en determinar el tipo MIME a partir de la extensión del archivo, de las primeras palabras del archivo, de un archivo de configuración y, posiblemente, de otros recursos. El paso 8 tiene que ver con una variedad de tareas, como la construcción de un perfil de usuario o la recolección de ciertas estadísticas. . El paso 9 tiene que ver con el lugar al que se envía el resultado. El paso 10 crea una entrada en el registro del sistema para propósitos administrativos. Tales registros pueden examinarse en busca de información valiosa acerca del comportamiento de los usuarios, como el orden en que acceden las páginas. El problema de diseño de obtener el archivo del disco y regresarlo al cliente es que cada solicitud requiere un acceso al disco para obtener el archivo. El resultado es que el servidor Web no puede atender más solicitudes por segundo que accesos al disco. Un disco SCSI de alta calidad tiene un tiempo de acceso promedio de aproximadamente 5 mseg, lo que limita al servidor a lo mucho 200 solicitudes/seg, o menos si se tienen que leer con frecuencia archivos grandes. Para un sitio Web grande, esta cifra es muy baja. Una mejora obvia (utilizada por todos los servidores Web) es mantener un caché en la memoria de los n archivos más recientemente utilizados. Antes de ir al disco para obtener un archivo, el servidor verifica el caché. Si el archivo está ahí, se puede 80



ESPOCH-FIE-EIS

proporcionar directamente desde memoria, con lo que se elimina el acceso al disco. Aunque el almacenamiento en caché efectivo requiere una gran cantidad de memoria principal y tiempo de procesamiento extra para verificar el caché y manejar su contenido, el ahorro de tiempo justifica la sobrecarga y costo implícitos. El siguiente paso para construir un servidor más rápido es hacerlo de múltiples subprocesos. En un diseño, el servidor consiste en un módulo de front end que acepta todas las solicitudes entrantes y k módulos de procesamiento, como se muestra en la figura 6.3. Los k + 1 subprocesos pertenecen al mismo proceso por lo que todos los módulos de procesamiento tienen acceso al caché dentro del espacio de direcciones del proceso. Cuando llega una solicitud, el front end la acepta y construye un registro corto que la describe. Después entrega el registro a uno de los módulos de procesamiento. En otro diseño posible, se elimina el front end y cada módulo de procesamiento trata de .adquirir sus propias solicitudes, pero se necesita un protocolo de bloqueo para evitar conflictos. 10

Caché

Modulo de procesamiento (subprocesos)

Front end

Solicitud entrante

Respuesta saliente

Figura 6.3 Servidor Web con múltiples subprocesos El módulo de procesamiento primero verifica el caché para ver si el archivo solicitado está ahí. De ser así, actualiza el registro para incluir un apuntador al archivo del registro. Si no está ahí, el módulo de procesamiento inicia una operación de disco para leerlo en el caché (posiblemente descartando algunos otros archivos en caché para hacerle espacio). Cuando el archivo llega del disco, se coloca en el caché y también se regresa al cliente. La ventaja de este esquema es que mientras que uno o más módulos de procesamiento están bloqueados esperando a que termine una operación del disco (y, por lo tanto, no consumen tiempo de CPU), otros módulos pueden estar trabajando activamente en otras solicitudes. Por supuesto, para obtener cualquier mejora real sobre el modelo de un solo subproceso, es necesario tener múltiples 10

Tanenbaum Andrew. Redes de computadoras. Pág. 619

81



ESPOCH-FIE-EIS

discos, a fin de que más de un disco pueda estar ocupado al mismo tiempo. Con k módulos de procesamiento y k discos, la velocidad real de transporte puede ser k veces mayor que con el servidor de un solo subproceso y un disco. En teoría, un servidor de un solo subproceso y k discos también puede ganar un factor de k, pero el código y la administración son mucho más complicados puesto que las llamadas de sistema READ de bloqueo normal no se pueden utilizar para acceder al disco. Con un servidor de múltiples subprocesos se pueden utilizar puesto que READ sólo bloquea el subproceso que hizo la llamada, no todo el proceso. Si llegan demasiadas solicitudes cada segundo, la CPU no será capaz de manejar la carga de procesamiento, sin importar cuántos discos se utilicen en paralelo. La solución es agregar más nodos (computadoras), posiblemente con discos replicados para evitar que los discos se vuelvan el siguiente cuello de botella. Esto lleva al modelo de granja de servidores de la figura 6.4. Un front end aún acepta solicitudes entrantes pero las distribuye en múltiples CPUs en lugar de en múltiples subprocesos para reducir la carga en cada computadora. Las máquinas individuales podrían contar con múltiples subprocesos y canales como en el esquema anterior. Un problema con las granjas de servidores es que no hay caché compartido debido a que cada nodo de procesamiento tiene su propia memoria —a menos que se utilice un multiprocesador de memoria compartida costoso. Una forma de medir esta pérdida de rendimiento es hacer que un front end registre el lugar a donde envía cada respuesta y que envíe las solicitudes subsecuentes de la misma página al mismo nodo. Hacer esto ocasiona que cada nodo sea un especialista en ciertas páginas a fin de que el espacio en caché no se desperdicie al tener cada archivo en cada caché.

Enrutador

Nodo de procesamiento (máquina independiente)

Canal con subprocesos

LAN Front end

Figura 6.4 Granja de servidores Otro problema con las granjas de servidores es que la conexión TCP del cliente termine en el front end, por lo que la respuesta puede pasar a través del front end. Esta situación se ilustra en la figura 6.5(a), donde la solicitud (1) y la respuesta (4) pasan a través del front end. Para solucionar este problema, algunas veces se utiliza un truco llamado transferencia TCP (TCP handoff). Con ésta, el punto final de la 82



ESPOCH-FIE-EIS

conexión TCP se pasa al nodo de procesamiento a fin de que pueda contestar directamente al cliente, que se muestra como (3) en la figura 6.5(b), Esta transferencia se realiza de tal forma que es transparente para el cliente. Nodo de aprendizaje 2

Nodo de procesamiento

3 Front end

1 Desde el cliente

4 Al cliente

3 2

Al cliente

Front end 1 Desde el cliente

Figura 6.5 a) Secuencia normal de mensajes solicitud-respuesta b) Secuencia cuando se utiliza la transferencia TCP 6.4 URLs LOCALIZADORES UNIFORMES DE RECURSOS Cuando se creó Web, de inmediato fue evidente que para que una página Web apuntara a otra se requerían mecanismos para nombrar y localizar las páginas; debían contestarse tres preguntas antes de poder presentar visualmente una página: 1. ¿Cómo se llama la página? 2. ¿Dónde está la página? 3. ¿Cómo se puede acceder a la página? La solución escogida identifica las páginas de una manera que resuelve los tres problemas a la vez. A cada página se le asigna un URL (Localizador Uniforme de Recursos) que sirve efectivamente como nombre mundial de la página. Los URLs tienen tres partes: el protocolo (también llamado esquema), el nombre DNS de la máquina en donde se encuentra la página y un nombre local que indica de manera única la página específica (por lo general, sólo un nombre de archivo de la máquina en que reside). http://www.espoch.edu.ec/academico/horarios.html Muchos sitios cuentan con ciertos atajos para los nombres de archivos. En muchos sitios, un nombre de archivo nulo tiende a ser de manera predeterminada la página de inicio de la organización. Por lo general, cuando el archivo nombrado es un directorio, esto implica un archivo nombrado índex.html. Por último, ~user/ podría

83



ESPOCH-FIE-EIS

tener una correspondencia con el directorio WWW de user y con el archivo index.html de ese directorio. Ahora debe quedar clara la manera en que funciona el hipertexto. Para que pueda hacerse clic en una parte del texto, el redactor de la página debe proporcionar dos elementos de información: el texto en el que se puede hacer clic y el URL de la página a la que se debe ir si; se hace clic en dicho texto. Al seleccionarse el texto, el navegador busca el nombre del host usando DNS. Armado ahora con la dirección IP del host, el navegador establece una conexión TCP con el host, y envía por esa conexión el nombre de archivo usando el protocolo especificado. Lotería. La página regresa. Este esquema de URL es abierto en el sentido de que es directo hacer que los navegadores utilicen múltiples protocolos para obtener diferentes tipos de recursos. De hecho, se han definido los URLs de varios otros protocolos comunes. En la figura 6.6 se listan formas ligeramente simplificadas de los más comunes.

Nombre Usado para Http Hipertexto (HTML) Ftp FTP

Ejemplo http://www.cs.vu.nl/~ast/ ftp://ftp.cs.vu.nl/pub/minix/README

File

Archivo local

file:///usr/suzanne/prog.c

News

Grupo de noticias

news:comp.os.mimx

News Artículo Gopher Gopher .

news:[email protected] gopher://gopher.tc.umn.edu/11/Libraries

Mailto

Envío de correo electrónico

mailto:[email protected]

Telnet

Inicio de sesión remota

telnet://www.w3.org:80

Figura 6.6 Algunos URLs comunes Los URLs se han diseñado no sólo para permitir que los usuarios naveguen por la Web, sino para que también utilicen FTP, noticias, Gopher, correo electrónico y telnet; de este modo los programas especializados de interfaz de usuario para esos otros servicios son innecesarios pues casi todos los accesos a Internet se integran en un solo programa, el navegador Web. Si no fuera por el hecho de que este esquema fue diseñado por un investigador de física, podría pensarse fácilmente que lo creó el departamento de publicidad de una compañía de software. A pesar de todas estas agradables propiedades, el uso creciente de W eb ha sacado a la luz una debilidad inherente del esquema URL. Un URL apunta a un host específico. En el caso de páginas a las que se hace referencia constante, sería deseable tener varias copias muy distantes, para reducir el tráfico de la red. El problema es que los URLs no proporcionan ninguna manera de referirse a una

84



ESPOCH-FIE-EIS

página sin decir de manera simultánea dónde está. No hay manera de decir: "quiero la página xyz y no me importa de dónde la traigas". Para resolver este problema y hacer posible la duplicación de páginas, la IETF está trabajando en un sistema de URNs (Nombres Universales de Recursos). Un URN puede considerarse como un URL generalizado. Este tema aún es objetivo de investigación, aunque en el RFC 2141 se da una sintaxis propuesta.

6.5 HTTP PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO El protocolo de transferencia utilizado en World Wide Web es HTTP (Protocolo de Transferencia de Hipertexto), especifica cuáles mensajes pueden enviar los clientes a los servidores y qué respuestas obtienen. Cada interacción consiste en una solicitud ASCII, seguida por una respuesta tipo MIME del RFC 822. Todos los clientes y servidores deben obedecer este protocolo. Se define en el RFC 2616.

6.5.1 PROCEDIMIENTOS DE CONEXIONES La forma común en que un navegador contacta a un servidor es estableciendo una conexión TCP con el puerto 80 de la máquina del servidor, aunque este procedimiento no se requiere formalmente. El valor de utilizar TCP es que ni los navegadores ni los servidores tienen que preocuparse por los mensajes largos, perdidos o duplicados, ni por las confirmaciones de recepción. En la implementación de TCP se manejan todos estos aspectos. En HTTP 1.0, una vez que se establecía la conexión, se enviaba una solicitud y se obtenía una respuesta. Después se liberaba dicha conexión. Este método era adecuado en un mundo en el que una página Web típica consistía por completo de texto HTML. Sin embargo, años más tarde la página Web promedio contenía una gran cantidad de iconos, imágenes, entre otras cosas, por lo que establecer una conexión TCP para transportar un solo icono era un método muy costoso. Debido a lo anterior se diseñó HTTP 1.1, que soporta conexiones persistentes. Con ellas, es posible establecer una conexión TCP, enviar una solicitud y obtener una respuesta, y después enviar solicitudes adicionales y obtener respuestas adicionales. Al repartir la configuración y terminación de sesiones de TCP en múltiples solicitudes, la sobrecarga resultante de TCP es mucho menor por solicitud. También es posible enviar solicitudes en canalización, es decir, enviar la solicitud 2 antes de que la respuesta a la solicitud 1 haya llegado.

6.5.2 METODOS Aunque HTTP se diseñó para utilizarlo en Web, se ha hecho intencionalmente más general que lo necesario con miras a las aplicaciones orientadas a objetos futuras. Por esta razón, se soportan otras operaciones, llamadas métodos, diferentes a las de solicitar una página Web. Esta generalidad es lo que permite que SOAP 85



ESPOCH-FIE-EIS

(protocolo simple de acceso a objetos) exista y mediante este lenguaje se puedan realizar RPCs (llamadas a procedimientos remotos) entre aplicaciones en forma independiente del lenguaje y de la aplicación; el cliente construye la solicitud como un mensaje XML y lo envía al servidor, utilizando el protocolo HTTP. El servidor envía una respuesta como un mensaje XML formateado, de esta forma plataformas heterogéneas pueden comunicarse. La mejor forma para describir la funcionalidad de HTTP es describir los elementos individuales del mensaje, que consta de solicitudes de los clientes a los servidores y respuestas de los servidores a los clientes. La estructura general de los mensajes se muestra en al figura 6.7. Línea de petición o Línea de respuesta Cabecera General Cabecera de petición o Cabecera de respuesta Cabecera de entidad

Cuerpo de entidad

Figura 6.7 Estructura general de los mensajes HTPP A continuación se describen los campos: Lí nea de solicitud : identifica el tipo de mensaje y el recurso solicitado. Lí nea de respuesta : proporciona información de estado sobre la respuesta Cabecera general : contiene campos que se aplican a los mensajes de solicitud y de respuesta, pero no se aplican a la entidad que está siendo transferida. C abecera de s olicitud : contiene información sobre la solicitud y el cliente. C abecera de res puesta : contiene información sobre la respuesta. Cabecera de entidad : contiene información sobre el recurso identificado por la solicitud e información sobre el cuerpo de la entidad. C uerpo entidad : el cuerpo del mensaje.

86



ESPOCH-FIE-EIS

TODOS LOS MENSAJES Campos de la cabecera general Campos de la cabecera de entidad Cache-Control Kee -Alive Allow Derived-From Connection MIME-Version Content-Encodin Ex ires Date Pragma Content-Language Last-Modified Forwarded Upgrade Content-Length Link Content-MD5 Title Content-Range Transfer-Encoding Content-Type URI-Header Content-Version

extension-header

MENSAJES DE PETICIÓN Métodos de solicitud Campos de la cabecera de petición OPTIONS MOVE Acce t If-Modified-Since GET DELETE Accept-Charset Proxy-Authorization HEAD LINK Accept-Encoding Range POST UNLINK Accept-Language Referer PUT TRACE Authorization Unless PATCH WRAPPED From User-A ent COPY extension-method Host MENSAJES DE RESPUESTA Códigos de estado de respuesta Campos de la cabecera de Continue Moved Temporarily Request Timeout Location Switching Protocols See Other Conflict Proxy-Authehticate OK Not Modified Gone Public Created Use Proxy Lengh Required Retry-After Accepted Bad Request Unless True Server Non-Authoritative Unauthorized Internal Server Error WWW-Authenticate Information Payment Required Not Implemented No Content Forbidden Bad Gateway Reset Content Not Found Service Unavailable Partial Content Method Not Allowed Gateway Timeout Multiple Choices None Acceptable Extension coce Moved Permanently Proxy Authentication Required

Figura 6.8 Elementos HTTP 6.5.2.1

MENSAJES DE PETICIÓN

Un mensaje de petición completo consta de una línea de estado seguida por una o más cabeceras generales de entidad seguidas por un cuerpo de entidad opcional.

MÉTODOS DE PETICIÓN

87



ESPOCH-FIE-EIS

En los métodos cada solicitud consiste en una o más líneas de texto ASCII, y la primera palabra de la primera línea es el nombre del método solicitado. Los nombres son sensibles a mayúsculas y minúsculas, por lo que GET es un método válido y get no lo es. Un mensaje de petición completo siempre comienza con una Línea-Petición, que tiene el siguiente formato: Línea-Petición = Método SP URL-Petición SP Version-HTTP CRLF El parámetro Método contiene la orden de petición real, llamada método en HTTP. El URL-Petición es el URL del recurso solicitado y Versión-HTTP es el número de versión de HTTP utilizado por el emisor. Se definen los siguientes métodos de petición en HTTP/1.1: 11

OPTIONS (opciones): una petición de información sobre las opciones disponibles para la cadena petición/respuesta identificada por este URL.



GET (obtener): una petición utiliza para recuperar la información identificada en el URL y devuelta en el cuerpo de entidad. Un GET es opcional si el campo de cabecera If-Modifíed-Since está incluido, y es parcial si el campo de cabecera Range está incluido. La mayoría de solicitudes a los servidores son GET.



HEAD (cabeza): esta petición es idéntica a GET, excepto que la respuesta del servidor no debe incluir un cuerpo de entidad; todos los campos de cabecera en la respuesta son los mismos como si el cuerpo de la entidad estuviera presente. Esto permite a un cliente obtener información sobre un recurso sin transferir el cuerpo de la entidad. Es utilizado para solicitar información sobre un objeto (fichero) : tamaño, tipo, fecha de modificación etc. También lo utilizan los gestores de caché de páginas o los servidores proxy, para conocer cuando es necesario actualizar la copia que se mantiene de un f ichero.



POST (correo): una petición para aceptar la entidad incorporada cómo una nueva subordinada al URL identificado. La entidad enviada está subordinada a ese URL de la misma forma que un fichero está subordinado al directorio que lo contiene, un articulo nuevo está subordinado a un grupo de noticias al que se envía o un registro está subordinado a una base de datos. Sirve para enviar información al servidor, por ejemplo los datos contenidos en un formulario. El servidor pasará esta información a un proceso encargado de su tratamiento (generalmente una aplicación CGI).



PUT (poner): es la petición que envía el cliente al servidor para que sea aceptada la entidad incorporada y almacenada bajo el URL proporcionado. Éste puede ser un nuevo recurso con un nuevo URL o una reposición del contenido de un recurso existente. Es similar a post, pero en este caso, la información enviada al servidor debe ser almacenada en la URL que acompaña al comando. Así se puede actualizar el contenido de un documento.



11

Stallings William. Comunicaciones y redes de computadoras. Pág. 682

88





















ESPOCH-FIE-EIS

PATCH (parche): similar a PUT, excepto que la entidad contiene una lista de diferencias con respecto al contenido del recurso original identificado en el URL. COPY (copiar): solicita que una copia del recurso identificado por el URL en Línea-Petición se copie a la(s) localización(es) dada(s) en el campo CabeceraURL en la Cabecera-Entidad de este mensaje. MOVE (mover): solicita que el recurso identificado por el URL en Línea-Petición se transfiera a la(s) localización(es) dada(s) en el campo Cabecera-URL en la Cabecera-Entidad de este mensaje. Es equivalente a COPY seguido de DELETE. DELETE (suprimir): solicita que el servidor origen suprima el recurso (documento) identificado por el URL en la Línea-Solicitud. No siempre tendrá éxito , puesto que aunque el servidor HTTP remoto este dispuesto a eliminar la página , el archivo subyacente puede tener un modo que prohiba al servidor HTTP modificarla o eliminarla. LINK (enlace): establece una o más relaciones de enlace entre recursos (documentos) identificados en Línea-Solicitud. Los enlaces se definen en el campo Link de la Cabecera-Entidad. UNLINK (enlace roto): elimina una o más relaciones de enlace entre recursos identificados en Línea-Solicitud. Los enlaces se definen en el campo Link de la Cabecera-Entidad. TRACE (trazar): solicita que el servidor devuelva todo lo que reciba como cuerpo de entidad de la respuesta. Esto se puede utilizar con objetivos de comprobación y diagnóstico. Es útil cuando las solicitudes no están procesando de manera correcta y el cliente desea saber cual solicitud ha obtenido realmente el servidor. WRAPPED (envolver): permite a un cliente enviar una o más solicitudes encapsuladas. Las solicitudes pueden estar encriptadas o haber sufrido otro tipo de procesamiento. El servidor debe quitar la envoltura y procesar de acuerdo a esto. Extension-method (método-de-extensión): permite definir métodos adicionales sin cambiar el protocolo, pero no se puede suponer que estos métodos se vayan a reconocer por el destino.

CAMPOS DE LA CABECERA DE PETICIÓN Los campos de la cabecera de petición actúan como modificadores de petición, proporcionando información adicional y parámetros relacionados con la petición. En HTTP/1.1 están definidos los siguientes campos: 

Accept (aceptado): es una lista de tipos MIME aceptados por el cliente. Se pueden utilizar * para indicar rangos de tipos de datos; tipo /* indica todos los

89



ESPOCH-FIE-EIS

subtipos de un determinado medio, mientras que */* representa a cualquier tipo de datos disponible. 























Accept-Charset (conjunto de caracteres aceptado): una lista de conjuntos de caracteres aceptables para la respuesta. Accept-Encoding (codificación aceptada): lista de los esquemas de codificación de contenido aceptable para el cuerpo de la entidad. La codificación del contenido se utiliza principalmente para permitir que un documento se comprima o se encripte. Normalmente el recurso se almacena con esta codificación y solamente se decodifica antes de su uso real. Accept-Languaje (lenguaje aceptado): restringe el conjunto de lenguajes naturales que se prefiere para la respuesta. Authorization (autorización): contiene un valor de campo, conocido como credencial, utilizado por un cliente para autentificarse el mismo ante el servidor. Es necesario para páginas que están protegidas. From (de): la dirección de correo electrónico en Internet del usuario del cliente Web que realiza el acceso. Host (computador): especifica el computador Internet (servidor) del recurso solicitado. Este encabezado se toma del URL y es obligatorio. Se utiliza porque algunas direcciones IP pueden proporcionar múltiples nombres DNS y el servidor necesita una forma de indicar a cuál host entregarle la solicitud. If-Modified-Since (si ha sido modificado desde): utilizado con el método GET. Ésta cabecera incluye un parámetro de fecha/hora; el recurso se va a transferir solamente si ha sido modificado desde la fecha/hora especificada. Esta característica permite actualizaciones eficientes de la cache. Un mecanismo que implemente la cache puede emitir periódicamente mensajes GET a un servidor origen y solamente recibirá pequeños mensajes de respuesta a menos que sea necesario una actualización. Es equivalente a realizar un HEAD seguido de un GET normal. Proxy Authorization (autorización de representante): permite que un cliente se autorice el mismo a un representante que requiere autentificación. Range (rango): para estudios futuros. La intención es que, en un mensaje GET, un cliente pueda solicitar solamente una parte del recurso identificado. Referer (remite): contiene el URL de un recurso del que se obtuvo el URL solicitado. Esto permite a un servidor generar una lista de enlaces hacia atrás. Unless (no útil): similar en funcionamiento al campo If-Modified-Since, con dos diferencias: (1) no se restringe al método GET, y (2) la comparación se realiza en el valor del campo Entity-Header en lugar del valor fecha/hora. User-Agent (agente de usuario): contiene información sobre el agente usuario que origina la solicitud como el navegador que esta utilizando, sistema operativo, etc. Esto se utiliza con objetivos estadísticos, para hacer un seguimiento de las violaciones de protocolo y para el reconocimiento automático de agentes usuarios con objeto de confeccionar respuestas que evitan limitaciones de agentes usuarios particulares. 90


6.5.2.2


ESPOCH-FIE-EIS

CAMPOS DE LA CABECERA GENERAL

Los campos de la cabecera general se pueden utilizar en los mensajes de solicitud y de respuesta. Estos campos se aplican en ambos tipos de mensajes y contienen información que no se aplica directamente a la entidad que se está transfiriendo. Los campos son: 















Cache-ControI (Control de Cache): especifica directivas que se deben cumplir por cualquier mecanismo de implementación de cache a lo largo de la cadena solicitud/respuesta. El propósito es prevenir a una cache de interferencias adversas con esta solicitud o respuesta particular. Connection (Conexión): contiene una lista de palabras clave y nombres de campos de cabecera que solamente se aplican a esta conexión TCP entre el que envía y el destino más cercano que no sea un túnel. Date (Fecha): día y hora en la que se originó el mensaje. Las fechas deben incluir la zona horaria en el que reside el sistema que genera la operación. Por ejemplo: Sunday, 12-Dec-2006 12:21:22 GMT+01. No existe un formato único en las fechas; incluso es posible encontrar casos en los que no se dispone de la zona horaria correspondiente, con los problemas de sincronización que esto produce. Los formatos de la fecha a emplear están recogidos en los RFC 1036 y 1123. Forwarded (Reenvío): utilizado por las pasarelas y representantes para indicar pasos intermedios a lo largo de la cadena de solicitud o respuesta. Cada pasarela o representante que trata un mensaje puede incorporar un campo Reenvío que da su URL. Keep-Alive (Mantener vivo): puede estar presente si existe la palabra clave keepalive en un campo Conexión entrante, y proporciona información al sol icitante de la duración de la conexión persistente. Este campo puede indicar un tiempo máximo durante el que el emisor mantendrá abierta la conexión esperando la siguiente solicitud, o el máximo número de solicitudes adicionales que se le permitirán a la actual conexión persistente. Versión MIME: indica que el mensaje sigue las instrucciones, de la versión indicada de MIME. Pragma: contiene directivas específicas de la implementación que se pueden aplicar a cualquier destino a lo largo de la cadena de solicitud/respuesta. Por ejmeplo, un cliete puede enviar un Pragma: no cache para informar que desea una copia nueva del recurso especificado. Upgrade (Actualización): se utiliza en una solicitud para especificar los protocolos adicionales que admite el cliente y cuál de ellos le gustaría utilizar; se utiliza en 91



ESPOCH-FIE-EIS

respuestas para indicar que protocolo será utilizado. Fue creado para facilitar la transición a una versión futura (posiblemente incompatible) del protocolo HTTP.

6.5.2.3

MENSAJES DE RESPUESTA

Un mensaje de respuesta completo consta de una línea de estado seguida por una o más cabeceras generales de entidad de respuesta, seguida por un cuerpo de entidad opcional.

CÓDIGOS DE ESTADO Cada solicitud obtiene una respuesta que consiste en una línea de estado, y posiblemente de información adicional (por ejemplo, toda o parte de una página Web). La línea de estado contiene un código de estado de tres dígitos que indica si la solicitud fue atendida, y si no, por qué. El primer dígito se utiliza para dividir las respuestas en cinco grupos mayores, como se muestra en la figura 6.9. En la práctica, los códigos 1xx no se utilizan con frecuencia. Los códigos 2xx significan que la solicitud se manejó de manera exitosa y que se regresa el contenido (si hay alguno). Los códigos 3xx indican al cliente que busque en otro lado, ya sea utilizando un URL diferente o en su propio caché. Los códigos 4xx significan que la solicitud falló debido a un error del cliente, por ejemplo una solicitud inválida o una página no existente. Por último, los errores 5xx significan que el servidor tiene un problema, debido a un error en su código o a una sobrecarga temporal.

Código

Significado

Ejemplos

1xx

Información

100 = el servidor está de acuerdo en manejar la solicitud del cliente 200 = la solicitud es exitosa; 204 = no hay contenido

2xx

Éxito

3xx

Redirección

301 = página movida; 304 = la página en caché aún es válida

4xx

Error del cliente

403 = página prohibida; 404 = página no encontrada

5xx

Error del servidor 500 = error interno del servidor; 503 = trata más tarde

Figura 6.9 Los grupos de respuesta del código de estado. Un mensaje .de respuesta completo siempre comienza, con una Línea-de-Estado, que tiene el siguiente formato: Línea-de-estado = Versión-HTTP SP Código-Estado SP Frase-de-Razón CRLF

92



ESPOCH-FIE-EIS

El valor de Versión-HTTP es el número de versión del HTTP utilizado por el que envía. El Código-Estado es un entero de 3 dígitos que indica la respuesta a una solicitud recibida y la Frase-de-Razón proporciona una explicación corta textual del código de estado. Existe una gran cantidad de códigos de estado definidos en HTTP/1.1; éstos se muestran en la figura 6.10 junto con una breve explicación. Los códigos se organizan en las siguientes categorías: 



De información: la solicitud .se ha recibido y el procesamiento continúa. No se acompaña un cuerpo de entidad en la respuesta. De éxito: la solicitud se recibió con éxito, se entendió y aceptó. La información devuelta en el mensaje de respuesta depende del método de solicitud, como sigue: GET: el contenido del cuerpo de entidad corresponde al recurso solicitado. HEAD: no se devuelve cuerpo de entidad. POST: la entidad describe o contiene el resultado de la acción. TRACE: la entidad contiene el mensaje de solicitud. Otros métodos: la entidad describe el resultado de la acción.







De redirección: se requieren acciones adicionales para completar la solicitud. De error del cliente: la solicitud contiene un error de sintaxis o la solicitud no se puede llevar a cabo. De error del servidor: el servidor falló al llevar a cabo una solicitud aparentemente válida.

De información Continue Switching Protocol

Recibida la parte inicial de la solicitud; el cliente puede continuar con la solicitud. El servidor conmutará a los nuevos protocolos de aplicación solicitados.

De éxito

93


OK Create Accepted Non-Authoritative Information No Content Reset Content Partial Content


ESPOCH-FIE-EIS

La solicitud ha tenido éxito y la información de respuesta apropiada se incluye. La solicitud se ha completado y se ha creado un recurso nuevo; se incluye el URL(s). La solicitud se ha aceptado pero el procesamiento no ha terminado. La solicitud podría o no ser finalizada finalmente. Los contenidos devueltos de la cabecera de entidad no son el conjunto definitivo disponible en el servidor origen, pero están recogidos en una copia local o en una tercera parte. El servidor ha completado la solicitud pero no se tiene información que devolver. La solicitud ha tenido éxito y el usuario agente debería inicializar la vista de documento que causó la solicitud a ser generada. El servidor ha completado la solicitud GET parcial y la información correspondiente se incluye.

Redirección Multiple Choices MovesPermariently Moved Temporarily See Other Not Modified Use Proxy

El recurso solicitado está disponible en varias localizaciones y no se puede determinar la localización preferida. Al recurso solicitado le ha sido asignado un URL permanente nuevo; las referencias futuras se deben hacer a este URL. El recurso solicitado reside temporalmente en un URL diferente. La respuesta a la solicitud se puede encontrar en un URL diferente y se debería obtener utilizando un GET en ese recurso. El cliente ha realizado un GET condicional, el acceso está permitido, y el documento no se ha modificado desde la fecha/tiempo especificada en la solicitud. El recurso solicitado se debe acceder a través de un representante indicado en el campo Location. Error de Cliente

Bad Request Unauthorized Payment Required Forbidden

Sintaxis incorrecta en la solicitud. La solicitud requiere autorización al usuario. Reservado para usos futuros. El servidor rechaza completar la solicitud; utilizado cuando el servidor no desea revelar porque se rechazó la solicitud. Not Found URL solicitado no encontrado. Method Not Allowed Método (orden) no permitido para el recurso solicitado. Proxy Authentication El cliente se debe autentificar con el representante. Required Conflict La solicitud no se puede completar debido a un conflicto con él estado actual del recurso. Gone El recurso solicitado no está ya disponible en el servidor y no se conoce la dirección de reenvío. Length Required El servidor rechaza aceptar solicitudes sin una longitud de contenido definida. Unless True La condición dada en el campo Unless era verdadera cuando se comprobó en el servidor.

94



ESPOCH-FIE-EIS

Error de Servidor Internal Server Error El servidor encontró una condición no esperada que le impide completar la solicitud. No Implemented El servidor no soporta la funcionalidad requerida para completar la solicitud. Bad Gateway El servidor, mientras actuaba como pasarela o representante, recibió una respuesta inválida del servidor en la dirección del flujo al que accede para completar la solicitud. Server Unavailable El servidor es incapaz de gestionar la solicitud debido a una sobrecarga temporal o a mantenimiento del servidor. Gateway Timeout El servidor, mientras actuaba como pasarela o representante, no recibió una respuesta a tiempo del servidor en la dirección del flujo al que accede para completar la solicitud. Figura 6.10 : Códigos de estado HTTP CAMPOS DE CABECERA DE RESPUESTA Los campos de cabecera de respuesta proporcionan información adicional relacionada con la respuesta y que no se puede situar en la Línea-de-Estado. En HTTP/1.1 se definen los siguientes campos: • Locatíon (localización): define la localización exacta del recurso, identificado por

el URL-Request. Este se puede utilizar si la página se movió o para permitir que múltiples URLs hagan referencia a la misma página (posiblemente en servidores diferentes). También se utilizan para compañías que tienen una página Web principal en el dominio com, pero que dirigen a los clientes a una página nacional o regional con base en su dirección IP o idioma preferido. • Proxy-Authenticate (autentifícación del representante): incluido con una

respuesta que tiene un código de estado de la solicitud de autentificación del representante. Este campo contiene un «reto» que indica el esquema de autentificación y los parámetros requeridos. • Public (público): indica los métodos no normalizados que admite .este servidor. • Retry-After (intentar después): incluido en una respuesta que tiene un código de

estado de Ser-vice Unavailable (servicio no disponible) e indica cuánto tiempo se espera que el servicio esté no disponible. • Server (servidor): identifica el producto software utilizado por el servidor origen

para tratar la solicitud. • WWW-Authenticate (autentificación WWW): incluida en una respuesta que tiene

el código de estado Unauthorized (no autorizado). Este campo contiene un «reto» que indica el esquema de autentificación y los ^parámetros requeridos.

6.5.2.4

ENTIDADES 95



ESPOCH-FIE-EIS

Una entidad consta de una cabecera de entidad y un cuerpo de entidad en un mensaje de solicitud o de respuesta. Una entidad puede representar un recurso de datos o puede constituir otra información proporcionada con una solicitud o una respuesta.

CAMPOS DE LA CABECERA DE ENTIDAD Los campos de la cabecera de entidad proporcionan información opcional sobre el cuerpo de la entidad o, si el cuerpo no está presente, sobre el recurso identificado por la solicitud. En HTTP/1.1 se definen los siguientes campos: • AIIow (permitir): indica -los métodos admitidos por el recurso identificado en el

URL-Request. Este campo se debe incluir con una respuesta que tiene un código de estado Method-Not-Allowed y se puede incluir en otras respuestas. • Content-Encoding (codificación del contenido): indica qué codificación del

contenido se ha aplicado al recurso. La única codificación actualmente definida es la compresión zip.

• Content-Language (lenguaje del contenido): identifica el lenguaje(s) natural de la

audiencia destino de la entidad indicada. • Content-Iength (longitud del contenido): el tamaño del cuerpo de la entidad en

octetos. • Content-MDS (contenido MD5): para estudios futuros. MD5 se refiere a la función de código de mezcla (hash) MD5. • Content-Range (rango del contenido): para estudios futuros. La intención es que

indicará una parte del recurso identificado que se incluye en esta respuesta.

• Content-Type (tipo de contenido): indica el tipo de medio del cuerpo de la entidad. • Contení -Versión (versión del contenido): una marca dé versión asociada con una

entidad en desarrollo.

• Derived-From (derivada de): indica la marca de versión de un recurso del que se

derivó esta entidad antes de que se hicieran las modificaciones por el emisor. Este campo y el campo Content-Versión se pueden utilizar para tratar múltiples actualizaciones por un grupo de usuarios. • Expires (expirar): fecha/hora después de la cual la entidad se debería considerar

obsoleta.

• Last-Modifíed (ultima modificación): fecha/hora de la última modificación del

recurso (página) que supone el emisor. Este encabezado juega un papel importante en el almacenamiento en caché de la página.

96



ESPOCH-FIE-EIS

• Link (enlace): define enlaces a otros recursos. • Title (título): un título textual de la entidad. •Transfer -Encoding

(codificación de transferencia): indica qué tipo de transformación se ha aplicado al cuerpo del mensaje para realizar una transferencia segura entre el emisor y el destino. La única codificación definida en el estándar es chunked. Esta opción define un procedimiento para romper un cuerpo de entidad en fragmentos etiquetados que se transmiten por separado.

• URL-header (cabecera de URL): informa al destino de otros URL por los que se

puede identificar el recurso.

• Extension-header (ampliación de cabecera): permite definir campos adicionales

sin cambiar el protocolo, pero se supone que estos campos se van a reconocer por el destino.

6.6 EJERCICIOS 1. Cuando se envían las páginas Web, se les anteponen encabezados MIME. ¿Por qué? 2. ¿Cuándo son necesarios los visores externos? ¿Cómo sabe un navegador cuál utilizar? 3. Un servidor Web de múltiples subprocesos está organizado como se muestra en la figura 6.3. Tarda 500 useg en aceptar una solicitud y verificar el caché. La mitad del tiempo es para encontrar el archivo en el caché y para regresarlo de inmediato. En la otra mitad del tiempo, el módulo tiene que bloquearse por 9 mseg mientras su solicitud de disco se coloca en la cola y se procesa. ¿Cuántos módulos debe tener el servidor para mantener ocupada todo el tiempo a la CPU (suponiendo que el disco no es un cuello de botella)? 4. El URL http estándar da por hecho que el servidor Web está escuchando en el puerto 80. Sin embargo, es posible que un servidor Web escuche en otro puerto. Diseñe una sintaxis razonable para que un URL acceda a un archivo en un puerto no estándar. 5. Aunque no se mencionó en el texto, una forma alternativa de un URL es utilizar una dirección IP en lugar de su nombre DNS. Un ejemplo del uso de una dirección IP es http://192.31.231.66/index.html. ¿Cómo sabe el navegador si el nombre que sigue al esquema es un nombre DNS o una dirección IP? 6. El Banco Sloth desea que sus clientes flojos puedan utilizar con facilidad su banca en línea, por lo que después de que un cliente firma y se autentica mediante una contraseña, el banco regresa una cookie que contiene un número de ID del cliente. De esta forma, el cliente no tiene que identificarse a si mismo o escribir una contraseña en visitas futuras a la banca en línea. ¿Qué opina de esta idea? ¿Funcionará? ¿Es una buena idea?

97



ESPOCH-FIE-EIS

7. Es posible utilizar el encabezado If-Modified-Since para verificar si una página almacenada en caché aún es válida. Las solicitudes pueden realizarse para obtener páginas que contengan imágenes, sonido, vídeo, HTML, etcétera. ¿Cree que la efectividad de esta técnica es mejor o peor para imágenes JPEG en comparación con HTML? Piense con.cuidado sobre lo que significa "efectividad" y explique su respuesta. 8. Suponga que el vínculo de un documento de Web a otro tiene un error tipográfico que invalida la referencia a la computadora. ¿Qué informa un visualizador si un usuario intenta acceder al vínculo? 9. En la pregunta anterior, ¿qué informa un visualizador si un error hace que el vínculo se refiera a una computadora válida que no está ejecutando un visualizador de Web? 10. ¿Cuál es la ventaja principal de permitir que el HTML seleccione detalles de presentación .como el tamaño de los elementos de la pantalla? ¿La desventaja principal? 11. Un visualizador mantiene un grupo de marcadores, cada uno de los cuales corresponde a una página de Web; en cualquier momento, el usuario puede solicitar que el visualizador guarde un marcador para la página presentada. Para regresar después a la página, el usuario abre el menú de marcadores y selecciona la página. ¿Qué aparece en el menú para identificar la página? 12. ¿Qué intérpretes puede tener un visualizador además de HTML y FTP? 13. Use un analizador de red para supervisar el tráfico mientras un visualizador trae una página de información textual. ¿Cuántas conexiones TCP se forman? 14. En la pregunta anterior, calcule el porcentaje de paquetes con datos. 15. ¿Qué tan grande es la caché empleada por el visualizador de su máquina? Para determinarlo, lleve a cabo un experimento: visite tres páginas de Web, desconecte su computadora de la red e intente regresar a una de las páginas visitadas. ¿Puede guardar en caché una docena de páginas?

98



ESPOCH-FIE-EIS

CAPITULO VII SNMP 7.1 INTRODUCCION Las redes y los Sistemas de procesamiento distribuido son de importancia critica y creciente en los negocios, gobierno y otras instituciones. Dentro de las instituciones, la tendencia es hacia redes más grandes, más complejas y dando soporte a más aplicaciones y a más usuarios. A medida que estas redes crecen en escala, existen dos hechos que se hacen evidentes: • La red y sus recursos asociados y las aplicaciones dist ribuidas llegan a ser

indispensables para la organización. • Puede suceder que se inutilice la red o una parte de ella o degradar las

prestaciones a un nivel inaceptable. Una red grande no se puede instalar y gestionar sólo con el esfuerzo humano. La complejidad de un sistema tal impone el uso de herramientas automáticas de gestión de red. La urgencia de la necesidad de esas herramientas se incrementa, y también está en auge la dificultad de suministrar dichas herramientas, si la red incluye equipos de múltiples distribuidores. En respuesta, se han desarrollado normalizaciones para tratar la gestión de red, y que cubren los servicios, los protocolos y la base de información de gestión.

7.2 SISTEMAS DE GESTIÓN DE RED Un sistema de gestión de red es una colección de herramientas para monitorizar y controlar la red y que está integrado por los siguientes recursos: •

Una interfaz de operador sencilla con un conjunto de órdenes potentes, pero

agradables para el usuario, para llevar a cabo la mayoría o todas las tareas de gestión de red. •

Una cantidad mínima de equipo separado del sistema de gestión. Esto es, la

mayor parte del hardware y el software requeridos para la gestión de red están incorporados en el equipo del usuario. Un sistema de gestión de red consta de hardware extra y software adicional implementados entre los componentes de red existentes. El software se utiliza para efectuar las tareas de gestión de red que residen en los computadores y en los procesadores de comunicaciones (por ejemplo, procesadores frontales y controladores de grupos de terminales). Un sistema de gestión de red está diseñado para ver la red entera como una arquitectura unificada, con direcciones y etiquetas asignadas a cada punto y los atributos específicos de cada elemento y enlace del sistema conocidos. Los elementos activos de la red proporcionan una realimentación regular de información de estado al centro de control de red.

99



ESPOCH-FIE-EIS

Un sistema de gestión de red posee los siguientes elementos clave: • La estación de gest ión o gestor. • El agente. • La base de información de gestión. • El protocolo de gestión de red.

La estación de gestión es normalmente un dispositivo autónomo pero puede ser implementado en un sistema compartido. En cualquier caso, la estación de gestión sirve como interfaz entre el gestor de red humano, y el sistema de gestión de red. La estación de gestión, tendrá, como mínimo: • Un conjunto de aplicaciones de gestión para el análisis de los datos,

recuperación de fallos, etc. • Una interfaz a través d e la cual el gestor de red puede monitorizar y controlar la red. • La capacidad de trasladar los requisitos del gestor de red a la monitorización y

control real de los elementos en la red.

• Una base de datos de información de gestión de red extraída de la s bases de

datos de todas las entidades gestionadas en la red.

El otro elemento activo en un sistema de gestión de red es el agente. Las plataformas claves, como los computadores, puentes, dispositivos de encaminamiento y concentradores se pueden equipar con software de agente para que puedan ser gestionados desde la estación de gestión. El agente responde a las solicitudes de información desde una estación de gestión, responde a las solicitudes de acción desde la estación de gestión y puede, de una forma asíncrona, proporcionar a la estación de gestión información importante y no solicitada. El medio por el cual se pueden gestionar los recursos de una red es representando estos recursos como objetos. Cada objeto es, esencialmente, una variable de datos que representa un aspecto del agente de gestión. La colección de objetos se conoce como base de información de gestión (MIB, Manage-ment Information Base). La MIB funciona como una colección de puntos de acceso al agente por parte de la estación de gestión. Estos objetos están normalizados a través de los sistemas de una clase particular (por ejemplo, todos los switches contienen los mismos objetos de gestión). La estación de gestión lleva a cabo la función de monitorización mediante el acceso a los valores de los objetos MIB. Una estación de gestión puede causar que una acción tenga efecto en un agente o puede cambiar la configuración de un agente mediante la modificación de los valores de variables específicas. La MIB para TCP/IP divide la información de la administración en 8 categorías, como se muestra en la figura 7.1 La selección de la categoría es importante pues los identificadores utilizados para especificar características incluyen un código para la categoría. Mediante este mecanismo todos los dispositivos utilizan el mismo mecanismo para comunicarse.

100


Categoría MIB system Interfaces Addr. trans ip icmp tcp udp egp


ESPOCH-FIE-EIS

Incluye información sobre Sistema operativo del anfitrión o del ruteador Interfaz de red individual Dirección de traducción (por ejemplo, transformación ARP) Software de protocolo de Internet Software de protocolo de mensajes de control de Internet Software de protocolo de transmisión de Internet Software de protocolo de datagrama de usuario Software de protocolo de compuerta esterior.

Figura 7.1 Categorías de información en la MIB Además del estándar MIB existe un conjunto de variables MIB, las cuales dependen de la versión de la MIB. Lo interesante de que este definido solo las categorías MIB es que permite una gran diversidad de variables. La figura 7.2 lista ejemplos de variables MIB junto con sus categorías.

Variable MIB SysUpTime IfNumber IfMTU IpDefaultTTL IpINReceives IpForwDatagrams IpReasmOKs IpFragOKs IpRoutingTable IcmpInEchos TcpRtoMin TcpMaxConn TcpInSegs UdpInDatagrams EgpInMsgs

Categoría sistema interfaz interfaz ip ip ip ip ip ip icmp tcp tcp tcp udp egp

Significado Tiempo desde el último arranque Número de interfaces de red MTU para una interfaz en particular Valor ip utilizado en el campo de tiempo límite Número de datagramas recibidos Número de fallas de ruteo Número de datagramas reensamblados Número de datagramas fragmentados Tabla de rueto IP Número de solicitudes de Eco ICMP recibidas Tiempo de retransmisión mínimo TCP permitido Conexión TCP máxima permitida Número de segmentos que TCP a recibido Número de datagramas UDP recibidos Número de mensajes EGP recibidos

Figura 7.2 Ejemplos de variables MIB Los nombres utilizados por las variables MIB son tomados del espacio de nombres identificador de objetos administrado por ISO y por ITU; estos están estructurados para hacerlos únicos globalmente y son jerárquicos. La figura 7.3 ilustra las partes pertinentes de la jerarquía de identifiación de objetos y muestra el nodo utilizado por los protocolos de administración de red TCP/IP así como parte de los sub-árboles bajo el nodo mib. El nombre de un objeto en la jerarquía es la secuencia de etiquetas numéricas de los nodos a lo largo de la trayectoria desde la raíz hacia el objeto. La secuencia está escrita con puntos que separan a los componentes individuales. Por ejemplo el nombre 1.3.6.1.1 denota al nodo con el nombre directorio. El MIB ha sido asignado a un nodo bajo el

101



ESPOCH-FIE-EIS

subgrupo internet mgmt con el nombre mib del espacio de nombre identificador de objetos. Sin nombre Unión iso-itu 3

itu 2

iso 1 org 3

dod 6

internet 1

directorio 1

mgmt 2

experimental 3

privada 4

mib 1

sistema 1

Interfaces 2

trans. direcc. 3

ip 4

icmp 5

tcp 6

udp 7

egp 8

Figura 7.3 Jerarquía del espacio de nombres identificador de objetos La figura 7.3 muestra que la categoría con la etiqueta ip ha sido asignada al valor numérico 4. Asi el nombre de todas las variables MIB correspondientes al IP tienen un identificador que comienza con el prefijo 1. 3. 6. 1. 2. 1. 4. Si se quisiera escribir la etiqueta textual en lugar de la representación numérica , el nombre sería: iso.org.dod.internet.mgmt.mib.ip La variable MIB llamada ipInReceives ha sido asignada al identificador numérico 3 bajo el nodo ip en el espacio de nombres así su nombre y representación numérica será: 102



iso.org.dod.internet.mgmt.mib.ip

ESPOCH-FIE-EIS

1. 3. 6. 1. 2. 1. 4. 3

Para especificar el campo de máscara de red en el elemento de la tabla de direcciones IP correspondiente a la dirección 128.10.2.3 se utiliza el nombre iso.org.dod.internet.mgmt.mib.ip.ipAddrTable.ipAdrrEntry.ipAdEntNetMask.128.10.2.3 1. 3. 6. 1. 2. 1. 4. 20. 1. 3. 128. 10. 2. 3

La estación de gestión y el agente están enlazados por el protocolo de g es tión de red . El protocolo utilizado para la gestión en redes TCP/IP es el protocolo sencillo de gestión de red (SNMP). Para las redes basadas en OSI, se está desarrollando el protocolo de información de gestión común (CMIP, Common Management Information Protocol). Una versión mejorada de SNMP, conocida como SNMPv2, está proyectada para ambos tipos de redes, basadas en OSI y basadas en TCP/IP. Cada uno de estos protocolos incluye las siguientes capacidades clave: • Get: permite a la estación de gestión obtener del agente los valores de objetos. • Get-Next: recorre las tablas de la MIB • Set: permite a la estación de gestión establecer valores de objetos del agente. Manipula objetos MIB, por lo que puede ocasionalmente variar la configuración del dispositivo. • Notify: permite a un agente notificar a una estación de gestión la producción de eventos significativos. • Trap: Informa de una alarma En un esquema tradicional de gestión de red centralizado, un computador en la configuración tiene el papel de estación de gestión; puede haber posiblemente una o dos estaciones de gestión con una misión de respaldo. El resto de los dispositivos en la red contiene software de agente y una MIB para permitir la monitorización y control por parte de la estación de gestión. Conforme las redes crecen en tamaño y en carga de tráfico, un sistema centralizado como el indicado no es práctico. Hay demasiada carga situada en la estación de gestión, y hay también mucho tráfico, con informes desde cada agente atravesando la red entera hasta llegar al «cuartel general». En tales circunstancias, una técnica descentralizada y distribuida funciona de mejor forma (por ejemplo, Figura 7.4). En un esquema descentralizado de gestión de red, puede haber múltiples estaciones de gestión del nivel más alto, que se podrían denominar servidores de gestión. Cada uno de estos servidores podría gestionar directamente una parte del conjunto total de agentes. Sin embargo, para muchos de estos agentes, el servidor de gestión delega la responsabilidad a un gestor intermedio. El gestor intermedio juega el papel de un gestor para monitorizar y controlar los agentes bajo su responsabilidad. También juega el papel de agente para proporcionar información y aceptar control desde un servidor de gestión de un nivel más alto. Este tipo de arquitectura dispersa la carga de procesamiento y reduce al tráfico total de la red.

103




Figura 7.4 Configuración de gestión de una red distribuida

7.3 PROTOCOLO SIMPLE DE GESTIÓN DE RED VERSIÓN 2 (SNMPv2) La especificación SNMP se publicó en agosto de 1988 y rápidamente se convirtió en el estándar de gestión de red dominante. Una serie de suministradores ofrecen estaciones de trabajo de gestión de red basadas en SNMP y la mayoría de los vendedores de puentes, dispositivos de encaminamiento(switch, router), estaciones de trabajo y PC ofrecen paquetes de agente SNMP que permiten que sus productos sean gestionados por una estación de gestión SNMP. Como el nombre sugiere, SNMP es una herramienta sencilla para la gestión de red. Define una base de información de gestión (MIB) limitada y fácil de implementar de variables escalares y tablas de dos dimensiones, y define un protocolo para permitir a un gestor obtener y establecer variables MIB y para permitir a un agente emitir notificaciones no solicitadas, llamadas intercepciones (traps). Esta simplicidad es la potencia de SNMP. Se implementa de una forma fácil y consume un tiempo modesto del procesador y de recursos de red. También, la estructura del protocolo y de la MIB es suficientemente directa de forma que no es difícil alcanzar la interacción entre estaciones de gestión y software de agente de varios vendedores. 12 Con una utilización tan amplia, las deficiencias de SNMP han llegado a ser notorias; éstas incluyen deficiencias funcionales y la falta de una herramienta de seguridad. 12

Stallings William. Comunicaciones y redes de computadores. Pág. 655

104




Como resultado en 1993 se publicó una versión mejorada, conocida como SNMPv2, y en 1996 se publicó una versión revisada (RFC 1901 a 1908). SNMPv2 ganó rápidamente apoyos y una serie de distribuidores anunciaron productos unos meses después de la publicación del estándar.

7.3.1 ELEMENTOS DE SNMPv2 SNMPv2 no proporciona gestión de red; en lugar de eso proporciona un marco de trabajo en el que se pueden construir aplicaciones de gestión de red. Estas aplicaciones, como la gestión de fallos, monitorización del rendimiento, contabilizado de tiempo, etc. están fuera del ámbito del estándar. Lo que proporciona SNMPv2 es la infraestructura de la gestión de red. La Figura 7.5 es un ejemplo de una configuración que muestra esta infraestructura. La esencia de SNMPv2 es un protocolo que se utiliza util iza para intercambiar información de gestión. Servidor de Gestión Aplicaciones de gestión

Gestor SNMPv2 MIB

Gestor de elemento

Gestor de elemento

Gestor/agente SNMPv2

Gestor/agente SNMPv2 MIB

Agente Agente SNMPv2 MIB

MIB



Figura 7.5 Configuración gestionada por SNMPv2 Cada estación en un sistema de gestión de red mantiene una base de datos local de información relevante de gestión de red, conocida como base de información de gestión (MIB). El estándar SNMPv2 define la estructura de esta información y los tipos de datos permitidos; esta definición se conoce como estructura de información de gestión (SMI, Structure of Management Information). Podemos pensar que esto constituye el lenguaje para definir la información de gestión. El estándar también 105




proporciona varias MIB que son generalmente útiles para la gestión de red. Además los vendedores y los grupos de usuarios pueden definir nuevas MIB. Al menos un sistema de la configuración debe ser responsable de la gestión de red. Es aquí donde se debe instalar cualquier aplicación de gestión de red. Debería de haber más de una de estas estaciones de gestión, para proporcionar redundancia o simplemente dividir las obligaciones en una red grande. La mayoría del resto de los sistemas actúan con un papel de agente. Un agente recoge información localmente y la almacena para accesos posteriores de un gestor. La información incluye datos sobre el mismo sistema y también pueden incluir información del tráfico de la red o redes a las que está conectado el agente. SNMPv2 dará apoyo a una estrategia de gestión de red altamente centralizada o distribuida. En este último caso, algunos sistemas operan con el papel de gestor y el de agente. En su papel de agente, un sistema aceptará órdenes de un sistema de gestión superior. Algunas de estas órdenes están relacionadas con la MIB local en el agente. Otras órdenes requieren que el agente actúe como delegado para dispositivos remotos. En éste caso, el agente delegado asume el papel de gestor para acceder a información en un agente remoto, y después asume el papel de agente para pasar esa información a un gestor superior. Todos estos intercambios se realizan utilizando el protocolo SNMPv2, que es un protocolo sencillo del tipo petición/respuesta. Normalmente, se implementa encima del protocolo de datagrama de usuario (UDP), que es parte del conjunto de protocolos TCP/IP. Ya que los intercambios SNMPv2 son del tipo de pares solicitudrespuesta discretos, no se requiere una conexión segura.

7.3.2 ESTRUCTURA DE LA INFORMACIÓN DE GESTIÓN La estructura de la información de gestión (SMI) define el marco de trabajo general dentro del que se puede definir y construir la MIB. La SMI identifica los tipos de datos que se pueden utilizar en la MIB y cómo se pueden representar y nombrar los recursos dentro de la MIB. La filosofía que subyace en la SMI es animar la simplicidad y la amplitud dentro de una MIB. Así, la MIB puede almacenar solamente tipos de datos sencillos: escalares y matrices de dos dimensiones de escalares, llamadas tablas. La SMI no permite la creación o la recuperación de estructuras de datos complejas. Esta filosofía es la contraria a la utilizada en los sistemas de gestión de OSI, que proporciona estructuras de datos y modos de recuperación complejos para permitir una funcionalidad mayor. SMI evita los tipos y estructuras de datos complejos para simplificar la tarea de la implementación y mejorar la interoperabilidad. Las MIB inevitablemente contendrán tipos de datos creados por el vendedor y, a menos que se impongan fuertes restricciones en la definición de tales tipos de datos, la interoperabilidad se verá afectada. Existen realmente tres elementos claves en la especificación de la SMI. En el nivel más bajo, la SMI especifica los tipos de datos que se pueden almacenar. Después, la SMI especifica la técnica formal para definir los objetos y tablas de objetos. 106



ESPOCH-FIE-EIS

Finalmente, SMI proporciona un esquema para asociar un identificador único con cada objeto real en un sistema, para que los datos de un agente se puedan referenciar por un gestor. La figura 7.6 muestra los tipos de datos que están permitidos por SMI. Éste es un conjunto bastante restringido de tipos. Por ejemplo, los números reales no se permiten. Sin embargo, es lo bastante rico como para permitir la mayoría de los requisitos de la gestión de red.

Tipo de dato INTEGER UInteger32 Counter32 Counter64 Gauge32 TimeTicks

Descripción Enteros en el rango de -231 a 231 - 1. Enteros en el rango de 0 a 232 - 1. Un entero no negativo que se puede incrementar módulo 2 32. Un entero no negativo que se puede incrementar módulo 2 64. Un entero no negativo que se puede incrementar o decrementar, pero que no excederá un valor máximo. El valor máximo no puede ser mayor que 2 32 - 1. Un entero no negativo que representa el tiempo, módulo 2 32, en centésimas de segundo.

OCTET STRING

Cadena de octetos para datos arbitrarios binarios o textuales; puede estar limitado a 255 caracteres.

IpAddress Opaque BIT STRING

Una dirección Internet de 32 bits. Un campo de bits arbitrario. Una enumeración de bits con nombre.

OBJECT IDENTIFIER

Nombre asignado administrativamente a objetos u otros elementos normalizados. El valor es una secuencia de hasta 128 enteros no ne ativos.

Figura 7.6 Tipos de datos permitidos en SNMPv2 7.3.3 FUNCIONAMIENTO DEL PROTOCOLO El protocolo SNMPv2 proporciona un mecanismo básico y directo para intercambiar información de gestión entre un gestor y un agente. La unidad básica de intercambio es el mensaje, que consta de un envoltorio de mensaje exterior y una unidad de datos de protocolo interior (PDU). La cabecera de mensaje exterior está relacionada con la seguridad.

107



ESPOCH-FIE-EIS

Se pueden transmitir siete tipos de PDU en un mensaje SNMP. El formato general de éstos se muestra informalmente en la Figura 7.7. Existen varios campos que son comunes a varias PDU. Tipo PDU

Identificativo Solicitud

0

0

Variable colección

a) PDU Get Request, PDU GetNextRequest, PDU SetRequest, PDU SNMPv2-Trap, PDU InformRequest Tipo PDU


Categoría de error

Indice de error

Variable colección

b) PDU Response Tipo PDU


No repetidor

Repetición máxima

Variable colección

c) PDU GetBulkRequest Nombre

valor

Nombre 2

Valor 2

........

Nombre n

Valor n

d) Variable colección

Figura 7.7 Formato de PDU de SNMPv2 El campo identificativo de solicitud es un entero asignado de forma que las solicitudes que se produzcan se identifiquen de forma única. Esto permite que un gestor relacione las respuestas de entrada con las solicitudes de salida. También permite que un agente trate el problema de dos o más PDU duplicadas generadas por un servicio de transporte no seguro. El campo de variable colección contiene una lista que recolecta los identificadores de objetos; dependiendo en el PDU , la lista puede incluir un valor de cada objeto. El PDU GetRequest, emitido por un gestor, incluye una lista de uno o más nombres de objetos para los que se solicita un valor. Si la operación de obtener valores tiene éxito, el agente que responde enviará un PDU Response. La lista de la variable colección contendrá el identificador y el valor de todos los objetos obtenidos. Para cualquier variable que no es relevante desde el punto de vista de la MIB, se devuelve el identificador y un código de error en la lista de la variable colección. Así, SNMPv2 permite respuestas parciales a un GetRequest, lo que da lugar a una mejora significativa con respecto a SNMP. En SNMP, si una o más variables en GetRequest no se permiten, el agente devuelve un mensaje de error con un estado de noSuchName. Para poder tratar estos errores, el gestor SNMP no debe devolver valores a la aplicación solicitante o debe incluir un algoritmo que responda ante un error eliminando las variables perdidas, reenviando la solicitud, y enviando un resultado parcial a la aplicación. La PDU GetNextRequest también es emitida por un gestor e incluye una lista de uno o más objetos. En este caso, para cada objeto cuyo nombre se encuentra en el 108



ESPOCH-FIE-EIS

campo de la variable colección se devuelve un valor para ese objeto que es el siguiente en orden lexicográfico, lo que es equivalente a decir siguiente en la MIB en términos de su posición en la estructura de árbol de identificadores de objetos. Como con la PDU GetRequest, el agente devuelve valores para tantas variables como le sea posible. Una de las ventajas de la PDU GetNextRequest es que permite a un gestor descubrir la estructura de una MIB dinámicamente. Esto es útil si el gestor no conoce a priori el conjunto de objetos asociados a un agente o que están en una MIB particular. Una de las principales mejoras proporcionadas por SNMPv2 es la PDU GetBulkResquest. El objetivo de esta PDU es minimizar el número de intercambios de protocolo requeridos para obtener gran cantidad de información de gestión. La PDU GetBulkRequest permite a un gestor SNMPv2 solicitar que la respuesta sea tan grande como sea posible dada la restricción del tamaño del mensaje. La PDU SetRequest se emite por un gestor para solicitar que el valor de uno o más objetos se modifique. La entidad SNMPv2 que la recibe responde con una PDU Response que contiene el mismo identificador de solicitud. La operación de SetRequest es atómica: o se actualizan todas las variables o ninguna. Si la entidad que responde es capaz de establecer los valores de todas las variables indicadas en la lista entrante de la variable colección, entonces la PDU Response incluye el campo de la variable colección con un valor proporcionado para cada variable. Si al menos uno de los valores de variable no se puede proporcionar, entonces no se devuelven valores ni se actualizan éstas. En este último caso, el código de estado de error indica la razón del fallo y el campo de índice de error indica la variable en la lista de variables colección que causó el fallo. La PDU dé SNMPv2 Trap se genera y transmite por un agente SNMPv2 actuando en su papel de agente cuando ocurre un evento inusual. Se utiliza para proporcionar a la estación de gestión una notificación asíncrona de algún evento significativo. La lista de la variable colección se utiliza para contener la información asociada con el mensaje Trap. A diferencia de GetRequest, GetNestRequest, GetBulkRequest, SetRequest e InformRequest, la PDU SNMPv2 Trap no provoca una respuesta de la entidad que lo recibe; es un mensaje no confirmado. La PDU InformRequest se envía por una entidad SNMPv2 actuando como gestor, en representación de una aplicación, a otra entidad SNMPv2 en su papel de gestor, para proporcionar información de gestión a una aplicación utilizando la última entidad. Como con la PDU SNMPv2 Trap, la lista de la variable colección se utiliza para llevar la información asociada. El gestor que recibe una InformRequest las confirma con una PDU Response. Tanto para Trap como para InformRequest, se pueden definir varias condiciones que indican cuándo se genera la notificación; también se especifica la información que se va a enviar.

7.4 PROTOCOLO SENCILLO DE GESTIÓN DE RED VERSIÓN 3 (SNMPv3)

109



ESPOCH-FIE-EIS

Un buen número de las deficiencias funcionales de SNMP se solucionaron en SNMPv2. Para corregir las deficiencias en seguridad de SNMPv1/SNMPv2, se publicó SNMPv3 como un conjunto de Estándares Propuestos en enero de 1998 (actualmente RFC 2570 a 2575). Este conjunto de documentos no proporciona una capacidad SNMP completa si no que define una arquitectura general de SNMP y un conjunto de capacidades en seguridad. Estas están pensadas para que se utilicen con el SNMPv2 actual. Son proporcionados tres servicios por SNMPv3 que son: autentificación, privacidad y control de acceso . Los dos primeros forman parte del modelo de Seguridad Basada en Usuarios (USM, User-Based Security) y el último se define en el Modelo de Control de Acceso Basado en Consideraciones (VACM, View-Based Access Control Model). Los servicios de seguridad están gobernados por la identidad del usuario que solicita el servicio; esta identidad se expresa como un director, que puede ser un individuo o una aplicación o un grupo de individuos o aplicaciones. El mecanismo de autentificación en USM asegura que el mensaje recibido lo transmitió el director cuya identidad aparece como fuente en la cabecera del mensaje. Este mecanismo también asegura que el mensaje no se ha alterado en la transmisión y que no se ha retardado o retransmitido artificialmente. El director que envía proporciona la autentificación mediante la inclusión de un código de autentificación del mensaje con el mensaje SNMP que envía. Este código es una función del contenido del mensaje y las identidades del emisor y el receptor. La clave secreta se debe establecer fuera de USM como una función de configuración. Esto es, el gestor de configuración o el gestor de red es responsable de la distribución de la claves secretas que se guardan en las bases de datos de los diferentes gestores y agentes SNMP. Esto se puede hacer de forma manual o utilizando alguna forma de transferencia de datos segura fuera de USM. Cuando el director receptor obtiene un mensaje, utiliza la misma clave secreta para calcular el código de autentificación de mensaje una vez más. Si la versión del código del receptor coincide con el valor añadido al mensaje, entonces el receptor sabe que el mensaje sólo lo puede haber originado el gestor autorizado y que el mensaje no se alteró en el camino. La clave secreta compartida por el emisor y el receptor debe estar preconfigurada. El código de autentificación actual se conoce como HMAC, que es un mecanismo de autentificación estándar de Internet . El servicio de privacidad de USM habilita a los gestores y a los agentes a encriptar mensajes. De nuevo, el gestor director y el agente director deben compartir una clave secreta. En este caso, si los dos están configurados para utilizar la facilidad de privacidad, todo el tráfico entre ellos es encriptado utilizando el estándar de encriptado de datos (DES). El director que envía encripta el mensaje utilizando el algoritmo DES y su clave secreta y envía el mensaje al director receptor que lo desencripta utilizando el algoritmo DES y la misma clave secreta. El servicio de control de acceso hace posible configurar los agentes para que proporcionen diferentes niveles de acceso a la base de información de gestión (MIB) del agente a diferentes gestores. Un director agente puede restringir el acceso a su MIB a un director gestor de dos formas. Primero, puede restringir el acceso a cierta porción de su MIB. Por ejemplo, 110



ESPOCH-FIE-EIS

un agente podría restringir a la mayoría de los gestores ver las estadísticas relacionadas con el rendimiento y permitir solamente a un único director gestor designado para ello a ver y actualizar los parámetros de configuración. Segundo, el agente puede limitar las operaciones que un gestor podría utilizar en esa porción de la MIB. Por ejemplo, un director gestor particular podría limitar el acceso de sólolectura a una porción de la MIB de un agente. El criterio de control de acceso que utilice un agente para cada gestor se debe preconfigurar y esencialmente consiste en una tabla que detalla los privilegios de acceso de los diferentes gestores autorizados.

7.5 EJERCICIOS 1. Capture un paquete SNMP con un analizador de red y decodifique los campos. 2. Lea el estándar para que sepa cómo ASN.1 codifica los dos primeros valores de un identificador de objeto en un solo octeto. ¿Por qué lo hace así? 3. Suponga que los diseñadores de MIB necesitan definir una variable que corresponda a un arreglo de dos dimensiones. ¿Cómo puede la notación de ASN. 1 adaptar las referencias para esta variable? 4. ¿Cuáles son las ventajas y las desventajas de definir globalmente nombres ASN.1 únicos para las variables MIB? 5. Lea la especificación de MIB para encontrar la definición de la variable ipRoutingTable que corresponde a una tabla de ruteo IP. 6. Si algún dispositivo de su Institución ejecuta un agente SNMP, emplee una estación de administración SNMP para supervisar el dispositivo.

111



ESPOCH-FIE-EIS

CAPITULO VIII FIREWALLS 8.1 INTRODUCCION La idea básica de un firewall es que se debe permitir a los usuarios desde una red protegida, por ejemplo una red corporativa, tener acceso a una red pública, como Internet, y al mismo tiempo poner los servicios y productos de la compañía a disposición de esta red pública. El problema se suscita cuando la compañía se conecta a Internet sin que se hayan implementado medidas de seguridad apropiadas, pues queda expuesto a los ataques de otros servidores en Internet. No sólo la red corporativa se vuelve vulnerable al acceso no autorizado, sino que también lo hacen todos los servidores en la misma. Por consiguiente, cuando se empieza a planear cómo proteger la red de las muchas amenazas que puede traer Internet, hay que comenzar pensando en los firewalls. Sin embargo, incluso antes de pensar en ello, debe definirse cómo y cuáles servicios de información que darán disponibles a Internet. Antes que nada, se debe ratificar que el servidor sea seguro. Tendrá que bloquearse el acceso de entrada no autorizado, los accesos de transferencias de archivos y la ejecución de comandos remotos y quizá también negar servicios como Rlogin, Telnet, FTP, SMTP, NFS y otros servicios RPC. Una vez que se empieza a usar o se tenga acceso a estos servicios, entonces será cuando se necesite construir un firewall. La figura 8.1 presenta una idea básica de un firewall y su propósito.

Firewall

LAN interna

o r t l i F

Gateway del firewall

o r t l i F

Internet

Figura 8.1 Función básica de un firewall Pero, ¿qué es un firewall, de cualquier modo? Básicamente, un firewall separa una red protegida de una red sin protección, Internet. Somete a revisión y filtra todas las conexiones que llegan desde Internet a la red protegida (corporativa), y viceversa, a través de un solo control de seguridad concentrado. Un firewall previene que no pueda alcanzarse Internet desde una red interna, o viceversa, a menos que pase a través de este control . 112



ESPOCH-FIE-EIS

Pero incluso antes de definir qué tipo de firewall se adapta mejor a determinadas necesidades, deberá analizarse la topología de la red para determinar si los varios componentes de la red, como los concentradores, conmutadores, enrutadores y el cableado son apropiados para un modelo específico de firewall. Para comprender mejor un firewall y su propósito, debe tenerse una idea más detallada de qué es un firewall y su barrera de protección. Debe examinarse la red corporativa con base en los niveles del modelo de la Intemational Standards Organization (ISO, Organización Internacional de Estándares). En él encontrará que los repetidores y concentradores actúan en el primer nivel, los conmutadores y los puentes en el segundo nivel, y los enrutadores en el tercero. Un firewall pasa a través de todos estos niveles puesto que actúa en los niveles sexto y séptimo, que son los niveles responsables por los controles de establecimiento de sesiones y aplicaciones. De esta manera, con un firewall podemos controlar el flujo de información a través del establecimiento de sesiones o incluso al determinar cuáles operaciones se permitirán o no lo harán. Un firewall ayuda a administrar una variedad de aspectos desde el gateway a la web al mantener fuera a las personas no deseadas.

8.2 PROPOSITO DE UN FIREWALL Muchas compañías toman la seguridad de sus activos de red, en especial los activos de comunicación de datos e interconectividad, muy a la ligera. Con frecuencia, no existen políticas ni se lleva ningún tipo de registro, y la seguridad de los sistemas se trata con muy poca información al respecto. En este punto es donde los firewalls entran en acción, pero debe darse cuenta de que un firewall por sí solo no asegurará su red. Sólo es parte de un área más amplia en la protección de su sitio web y la conectividad en red en general. Para asegurar la red corporativa, debe definirse la idea de un perímetro de red. Se necesita determinar qué cosas debe proteger, desarrollar una política de seguridad establecer mecanismos para hacer cumplir la política y los métodos que usted va a emplear. Por supuesto, existen mecanismos además del firewall que se puede añadir para incrementar en gran medida el nivel de seguridad. Estos mecanismos deben venir después de que se haya desarrollado la política de seguridad, no antes. Ésta es la idea principal que se debe retener: definir un mecanismo de seguridad que protegerá el sitio corporativo, en específico los firewalls, y proporcionará los prerrequisitos para implementarlo. Las políticas y los

113



ESPOCH-FIE-EIS

procedimientos son un prerrequisito indispensable. Los métodos que va a emplear y los resultados de su análisis son otros. Muchas compañías y centros de información deben estar guiados por políticas de seguridad de cómputo, particularmente aquellas organizaciones en el sector público que es probable sean un blanco de ataque y otras agencias gubernamentales. Se establece que los procedimientos deben observarse. Curiosamente, esto rara vez sucede con el sector privado, en especial cuando se trata de conectarse a Internet. Es sorprendente de que muchas compañías privadas a menudo rechazan el desarrollo de una política de seguridad, y por lo tanto sus mecanismos de seguridad son débiles si no es que defectuosos. Claro que las políticas de seguridad varían de una organización a otra, pero un aspecto que prescindirá de estas políticas será la plataforma para la cual se están desarrollando. Un firewall puede implementarse en UNIX, Linux, Windows 2000, Windows 2003, NT o una plataforma patentada. Debe estudiar muy de cerca la plataforma que elegirá, ya que ésta definirá definitivamente todos los proyectos futuros, el nivel de seguridad y en consecuencia, la política de seguridad que se está desarrollando. Por esta razón una política de seguridad debe darse primero para garantizar el éxito de los mecanismos que serán implementados. Como administrador web o de LAN, debe saberse que la parte más difícil de conectar una empresa a Internet no es justificar la inversión o el esfuerzo, sino convencer a la administración de que es seguro hacerlo, especialmente en las compañías grandes. Un firewall no sólo añade seguridad real, sino que también juega un papel importante como un manto de seguridad para la administración.

8.3 PAPEL DE PROTECCION QUE JUEGA UN FIREWALL Un firewall mejora en gran medida la seguridad de red y reduce los riesgos para los servidores en la red al filtrar inherentemente servicios inseguros. Como resultado, el entorno de red está expuesto a menores riesgos debido a que sólo los protocolos seleccionados son capaces de pasar a través de un firewall. Por ejemplo, un firewall puede prohibir a ciertos servicios vulnerables como NFS que entren o salgan de una red protegida. Esto brinda el beneficio de impedir que los servicios sean explotados por agresores ajenos, pero al mismo tiempo permite el uso de estos servicios con un riesgo de explotación sumamente reducido. Los servicios como NIS y NFS que son particularmente útiles en una red de área local pueden disfrutarse y utilizarse de esta manera para reducir la carga de administración del servidor. Los firewalls además pueden proporcionar protección de ataques dirigidos al enrutador, tales como el enrutamiento de origen e intentos de dirigir las rutas de enrutamiento hacia sitios comprometidos a través de envíos ICMP. Podría rechazar 114



ESPOCH-FIE-EIS

todos los paquetes enrutados desde el origen y envíos ICMP, y luego informar a los administradores de los incidentes. No obstante, el problema con los firewalls es que limitan el acceso a, y desde Internet. En algunas configuraciones puede decidirse a utilizar un servidor proxy, para filtrar el acceso de entrada y salida que la política ha determinado que es seguro. Un firewall puede ofrecer control de acceso a los sistemas de un sitio. Por ejemplo, algunos servidores pueden ponerse al alcance de redes externas, mientras que otros pueden cerrarse de una manera efectiva al acceso no deseado. Dependiendo del nivel de riesgo que se desea tomar en la red corporativa, se debe esperar acceso del exterior hacia los servidores de red internos, excepto para casos especiales como los servidores de correo o los servicios RAS. Asimismo, se debe esperar que los usuarios descarguen virus a través del correo electrónico y los diseminen en toda la red protegida. Otra amenaza son los applets (principalmente los de Java, JavaScript y ActiveX), los cuales pueden iniciar procesos remotos en una estación de trabajo que podrían afectar a un servidor o incluso desactivar un firewall. Esto nos lleva a uno de los principales propósitos en los que una política de acceso es particularmente experta para hacer cumplir: nunca proporcione acceso a servidores o servicios que no requieran acceso; los hackers podrían explotarlos debido a que el acceso no es necesario o no se requiere.

8.4 PAPEL DE SEGURIDAD QUE JUEGA UN FIREWALL En realidad un firewall puede resultar menos costoso para una organización en que todo (o la mayoría) el software modificado y el software de seguridad adicional puede localizarse en el sistema de firewall que si se distribuye en cada servidor o máquina. En particular, los sistemas de contraseñas desechables y otro software de autenticación agregado puede localizarse en el firewall en lugar de en cada sistema al cual se necesite tener acceso desde Internet. 13 Tampoco se debe rechazar la seguridad interna. Frecuentemente, se da mucho énfasis al firewall, pero si un hacker irrumpe en su sistema, a menos que se tenga algunas políticas de seguridad interna en funcionamiento, su red quedará expuesta. Por esta razón muchas veces podría ser buena idea poner el servidor a disposición de Internet fuera del firewall. Es muy probable que los servicios queden expuestos a amenazas de Internet, pero se podría tener fácilmente una réplica del servidor 13

Goncalves Marcus. Manual de Firewalls. Pág. 262.

115



ESPOCH-FIE-EIS

dentro del firewall y que estuviera disponible para una recuperación rápida. También podría mantenerse toda la configuración del sistema del servidor externo en un CDROM, volviéndolo seguro contra modificaciones. Otras soluciones para la seguridad de la red corporativa podrían involucrar modificaciones en cada sistema de servidor. Aunque vale la pena considerar muchas técnicas por sus ventajas y probablemente son más apropiadas que los firewalls en ciertas situaciones, los firewalls tienden a ser más simples de implementar debido a que sólo el firewall necesita ejecutar software especializado, a menos que se tenga un firewall de filtrado de paquetes o se requiera que los usuarios inicien una sesión Telnet a él. En este caso, se necesitará ya sea un enrutador o una máquina dedicada que filtre los paquetes. La privacidad debe ser una gran preocupación para toda red corporativa, debido a que lo que normalmente se consideraría información inocua en realidad podría contener pistas útiles para un hacker. Al usar un firewall, su sitio puede bloquear el acceso de servicios como Finger y el Servicio de Nombres de Dominio Otra ventaja de usar un firewall en el sito es que al pasar a través de un firewall todo el acceso hacia y desde Internet, se puede llevar una bitácora de los accesos y, proporcionar estadísticas valiosas sobre el uso de la red. A pesar de estas ventajas, se debería estar consciente de que también existen varias desventajas: cosas contra las cuales no pueden protegerle los firewalls, como restricciones de acceso, amenazas de las puertas traseras (módems o servidores RAS que omiten el acceso por el firewall) y vulnerabilidad a hackers internos, por nombrar unas cuantas.

8.5 COMPONENTES DE LOS FIREWALLS Los componentes básicos en la construcción de un firewall incluyen: • Política • Autenticación avanzada • Filtrado de paquetes • Gateways de aplicación

a) Política de seguridad de la red La decisión de instalar un firewall puede estar directamente influenciada por dos niveles de política de red: • Instalación

116



ESPOCH-FIE-EIS

• Uso del sistema

La política de acceso a red que define los servicios que se permitirán o negarán de manera explícita desde la red restringida es la política de más alto nivel. También define cómo se utilizarán estos servicios. La política de más bajo nivel define como el firewall restringirá en realidad el acceso y determinará los servicios especificados en la política de nivel superior. Sin embargo, la política no debe volverse un documento aislado olvidado en el cajón de su escritorio; debe serle útil. Es imprescindible que la política de seguridad de red se vuelva parte de la política de seguridad de la compañía. Echemos un vistazo a los distintos tipos de políticas de seguridad.

Política de flexibilidad Si usted va a desarrollar una política que cubra el acceso a Internet, la administración web y los servicios electrónicos en general, deberá ser flexible. Su política deberá ser flexible debido a lo siguiente: • Internet por sí misma cambia cada día a una velocidad que nadie puede seguir.

Conforme Internet cambia, los servicios ofrecidos a través de la misma también cambian. Por eso, una compañía necesita cambiar también, así que se debe estar preparado para editar y adaptar la política en consecuencia sin comprometer la seguridad y la consistencia. Recuerde: una política de seguridad casi nunca cambia pero los procedimientos siempre deben revisarse. • Los riesgos que la compañía enfrenta en Internet no son estáticos tampoco.

Cambian cada momento, en constante crecimiento. De acuerdo con eso debe ser capaz de anticipar estos riesgos y ajustar los procesos de seguridad.

Política de acceso a los servicios Cuando se escriba una política de acceso a los servicios, debe concentrarse en los problemas de los usuarios de la compañía, así como en las políticas de marcado interno, las conexiones SLIP y las conexiones PPP. La política debería ser una extensión de la política organizacional con respecto a la protección de los recursos de los Sistemas de información (SI) en la compañía. La política de acceso a los servicios debe ser completamente realista. Asegúrese de tener un borrador antes de implementar un firewall. La política debe proporcionar un balance entre proteger la red y dar acceso a los usuarios a los recursos de la red.

Política de diseño de firewall Una política de diseño de firewall es específica para el firewall. Define las reglas de implementación de las políticas de acceso a los servicios. No se puede diseñar esta 117



ESPOCH-FIE-EIS

política sin entender las capacidades y limitaciones del firewall, así como las amenazas y los puntos vulnerables asociados con TCP/IP. Los firewalls usualmente realizan una de las siguientes acciones: • Permiten cualquier servicio a menos que se niegue expresamente • Niegan cualquier servicio a menos que se permita expresamente

Un firewall que implementa la primera política permite a todos los servicios pasar a su sitio en forma predeterminada, excepto aquellos servicios que la política de acceso a los servicios haya determinado que se les niegue el permiso. De la misma manera, si se decide implementar la segunda política, el firewall negará todos Ios servicios en forma predeterminada, pero luego permitirá aquellos que se hayan establecido como permitidos. Tener una política que permita el acceso a cualquier servicio no es aconsejable puesto que expone el sitio a más amenazas. Obsérvese la estrecha relación entre la política de acceso a los servicios de nivel superior y la de nivel inferior. Esta relación es necesaria debido a que la política de acceso a los servicios depende de las capacidades y limitaciones de los sistemas de firewall que se está instalando, así como los problemas de seguridad inherentes que traen los servicios web. Por ejemplo, podría ser necesario restringir algunos de los servicios que se definió en la política de acceso a los servicios. Los problemas de seguridad que pueden presentarse es posible que no se controlen de una manera eficiente por la política de nivel inferior. Si la compañía se basa en estos servicios, lo cual generalmente hacen los sitios web, es probable que se tenga que aceptar mayores riesgos al permitir estos servicios. Esta relación entre ambas políticas de acceso a los servicios permiten su interacción al definir tanto las políticas de nivel superior como las de nivel inferior de una manera eficiente y consistente. La política de acceso a los servicios es el componente más importante al instalar un firewall. Los otros tres componentes son necesarios para implementar y hacer cumplir política. Recuerde: La eficiencia del firewall al proteger el sitio dependerá del tipo de implementación de firewall que se utilice, así como del uso de los procedimientos apropiados y de la política de acceso a los servicios.

Política de información Como administrador de Internet, o incluso como administrador LAN o web, si se intenta proporcionar acceso público a la información, debe desarrollar una política 118



ESPOCH-FIE-EIS

para determinar el acceso al servidor (probablemente un servidor web) e incluirla en su diseño de firewall. El servidor creará por sí solo problemas de seguridad que ya existían, pero esto no debería comprometer la seguridad de otros sitios protegidos que tienen acceso al servidor. Se debe tener la capacidad de distinguir entre un usuario externo que tiene acceso al servidor en busca de información y un usuario que utilizará la característica de correo electrónico, si se está incorporando un usuario, por ejemplo, para comunicarse con usuarios que están del otro lado del firewall. Debería tratarse estos dos tipos de tráfico en forma diferente y mantener el servidor aislado de otros sitios en el sistema.

Política de marcado al interior y exterior Los sistemas de acceso remoto añaden características útiles a los usuarios autenticados cuando no están en el sitio o no pueden tener acceso a ciertos servicios o información a través del sitio web de la compañía. Sin embargo, los usuarios deben estar conscientes de la amenaza del acceso no autorizado que una capacidad de marcado al interior puede generar. También se debe ser capaz de demostrar los puntos vulnerables que creará esta característica si los usuarios no son cuidadosos cuando entran a la red interna a través de un módem. La capacidad de marcado al exterior de un usuario podría volverse una amenaza de marcado al interior por un intruso. Por lo tanto, debería considerarse ambas capacidades de marcado en la política al diseñar el firewall. Deberá forzarse a los usuarios que llaman de fuera a pasar a través de la autenticación avanzada del firewall. Esto deberá enfatizarse en la política, así como la prohibición de módems sin autorización conectados a cualquier host o cliente que no esté aprobado por la Management of Information Systems (MIS, Administración de Sistemas de Información) o no pase a través del firewall. El objetivo es desarrollar una política lo suficientemente sólida como para limitar el número de módems no autorizados en toda la compañía. Al combinar tal política con un grupo de módems eficiente, se estará en capacidad de reducir el peligro de los ataques de hackers en la compañía utilizando módems, así como limitando la vulnerabilidad. Otro factor que deberá considerarse involucra a los servidores web. Peor que tener una línea de módem que permita capacidades de marcado al interior y hacia el exterior es el uso de IP de línea serial o del protocolo punto a punto a través del servidor web o de cualquier otro medio de acceso a la red de la compañía. Por mucho, es una puerta trasera más peligrosa de lo que cualquier módem pudiera ser, a menos, por supuesto, que usted pase a través del firewall 119



ESPOCH-FIE-EIS

b) Autenticación avanzada A pesar de todo el tiempo y esfuerzo invertido en escribir políticas e implementar firewalls, muchos incidentes resultan del uso de contraseñas débiles o permanentes. Las contraseñas en Internet pueden ser forzadas de muchas formas. El mejor mecanismo de contraseñas tampoco valdrá la pena si se tiene usuarios que piensan que su nombre de acceso deletreado al revés o una serie de equis son contraseñas buenas. El problema con las contraseñas es que para crearlas una vez que un algoritmo se especifica, se vuelve una simple cuestión de analizar el algoritmo con el propósito de encontrar cada contraseña en el sistema. A menos que el algoritmo sea muy sutil, un cracker puede probar todas las combinaciones posibles del generador de contraseñas para cada usuario en la red. Además, un cracker puede analizar la salida del programa de contraseñas y determinar el algoritmo que se está utilizando. Entonces el sólo necesitará aplicar el algoritmo a otros usuarios de tal manera que las contraseñas puedan determinarse. Asimismo, existen programas disponibles gratuitamente en Internet para forzar las contraseñas de los usuarios. Por otra parte, se debe estar consciente de que algunos servicios TCP o UDP sólo autentican en el nivel de direcciones del servidor y no para usuarios específicos. Una de las primeras cosas que probablemente se les debe decir a los usuarios de Internet es que elijan contraseñas difíciles de adivinar y que no compartan sus contraseñas con nadie. No obstante, la mayoría de los usuarios no seguirán este consejo, y aun si lo hicieran, los hackers pueden monitorear las contraseñas que se transmiten. Una de las alternativas más eficaces para pelear contra el hacker es adoptar medidas de autenticación avanzadas. Las tarjetas inteligentes, como las tarjetas de identificación, tipo tarjeta de crédito y otras tarjetas con códigos magnéticos, y los mecanismos basados en software son alternativas para hacer frente a los puntos débiles de las contraseñas tradicionales. Si se adopta uno de estos dispositivos de autenticación avanzada, los hackers no serán capaces de volver a utilizar una contraseña que haya sido observada durante una conexión. Si se considera todos los problemas inherentes a las contraseñas en Internet, un firewall que no incluye el mismo tipo de sistema de autenticación avanzada no tiene mucho sentido. Algunos de los dispositivos de autenticación avanzada más populares en uso actualmente, son los sistemas de contraseña desechable. Una tarjeta inteligente, por ejemplo, genera una respuesta como un autenticador en lugar de una 120



ESPOCH-FIE-EIS

contraseña tradicional. Trabaja junto con software o hardware. Incluso si es observada, puede utilizarse sólo una vez. El sistema de autenticación avanzada del firewall debe localizarse en el firewall debido a que centraliza y controla el acceso al sitio. Se puede instalar en otro servidor, pero si lo carga en un firewall es más práctico y manejable centralizar las medidas. La figura 8.2 muestra lo que sucede cuando la autenticación avanzada está presente. Todas las conexiones y solicitudes de sesión como Telnet o FTP que se originan en Internet y van a los sistemas de un sitio deben pasar la autenticación avanzada antes de que se les otorgue el permiso. Las contraseñas todavía podrían requerirse, pero antes de permitir el acceso, estas contraseñas se protegerían incluso si se observan. Tráfico FTP autenticado Internet

Sistema de firewall con Tráfico FTP autentificación autenticado avanzada

LAN

Figura 8.2 Uso de autenticación avanzada en un firewall c) Filtrado de paquetes Comúnmente, el filtrado de paquetes IP se realiza utilizando un enrutador configurado para filtrar paquetes conforme éstos pasan por las interfaces del enrutador. Estos enrutadores pueden filtrar paquetes IP con base en los siguientes campos: • Dirección IP origen • Dirección IP destino • Puerto TCP/UDP origen • Puerto TCP/UDP destino

Aunque no todos los enrutadores de filtrado de paquetes pueden filtrar el puerto TCP/UDP origen, la mayoría de ellos ya cuenta con esta capacidad. Algunos enrutadores examinan en cuál de las interfaces de red del enrutador llegó un paquete, y esto se usa como criterio extra.

121



ESPOCH-FIE-EIS

122



ESPOCH-FIE-EIS

123



ESPOCH-FIE-EIS

Para bloquear las conexiones desde o hacia servidores web o redes específicos, el filtrado puede aplicarse de muchas formas, incluyendo el bloqueo de conexiones a determinados puertos. Por ejemplo, se podría decidir bloquear conexiones desde direcciones o sitios que considere poco confiables, o podría decidirse bloquear las conexiones a su sitio desde todas las direcciones externas; todo esto puede lograrse mediante el filtrado. Se puede añadir mucha flexibilidad simplemente al agregar filtrado de puertos TCP o UDP al filtrado de direcciones IP. Los servidores como el daemon Telnet por lo general residen en puertos específicos. Si se habilita el firewall para bloquear conexiones TCP o UDP hacia o desde puertos específicos, podrá implementarse políticas para dirigirse a ciertos tipos de conexiones hechas para determinados servidores, pero no para otros. Se podría, por ejemplo, bloquear todas las conexiones que llegan a los servidores web excepto aquellos conectados a un firewall. En esos sistemas, se podría desear permitir sólo ciertos servicios, como SMTP para un sistema y Telnet o conexiones FTP para otro sistema. El filtrado en los puertos TCP o UDP puede ayudarle a implementar una política a través de un enrutador de filtrado de paquetes o incluso mediante un servidor con la capacidad de filtrado de paquetes. La figura 8.3 muestra los enrutadores de filtrado de paquetes en tales servicios.

Otro tráfico

Sólo tráfico SMTP

Enrutador de filtrado de paquetes

Sólo tráfico Telnet

Internet

Figura 8.3 Filtrado de paquetes en Telnet y SMTP Protocolo TCP TCP TCP TCP UDP *

Dirección Origen * * * 129.6.48.254 * *

Dirección Destino 123.4.5.6 123.4.5.7 123.4.5.8 123.4.5.9 123.4.*.* *

Puerto Origen >1023 >1023 >1023 >1023 >1023 *

Puerto Destino 23 25 25 119 123 *

Acción Permitir Permitir Permitir Permitir Permitir Denegar

Figura 8.4 Conjunto de reglas de filtrado

124



ESPOCH-FIE-EIS

Puede instalar un conjunto de reglas para que le ayuden a dar una idea general de los permisos. La figura 8.4 presenta como ejemplo un conjunto de reglas muy básicas de filtrado de paquetes. La primera regla permite a los paquetes TCP desde cualquier dirección origen y puerto mayor que 1023 en Internet, introducir la dirección destino de 123.4.5.6 y el puerto 23 en él sitio. El puerto 23 es el puerto asociado con el servidor Telnet y todos los clientes Telnet deben tener puertos origen sin privilegios de 1024 o mayores. La segunda y tercera reglas trabajan de una manera muy similar, excepto que los paquetes hacia las direcciones destino 123.4.5.7 y 123.4.5.8 ,y el puerto 25 para SMTP, están permitidos. La cuarta regla permite paquetes hacia el servidor NNTP del sitio, pero sólo desde direcciones origen 129.6.48.254 hacia direcciones destino 123.4.5.9 y el puerto 119 (129.6.48.254 es el único servidor NNTP desde el cual debe recibir noticias el sitio; por lo tanto, el acceso al sitio para NNTP está restringido a ese sistema únicamente). La quinta regla permite tráfico NNTP, el cual usa UDP en lugar de TCP, desde cualquier dirección origen hacia cualquier dirección destino en el sitio. Finalmente, la sexta regla niega a todos los otros paquetes. Si esta regla no estuviera presente, el enrutador podría no rechazar todos los paquetes subsecuentes. Aunque el filtrado de paquetes puede bloquear de una manera efectiva las conexiones desde o hacia hosts específicos, lo cual incrementa el nivel de seguridad considerablemente, los enrutadores de filtrado de paquetes tienen varios puntos débiles. Sus reglas son complejas de especificar y difíciles de probar, debido a que usted debe ya sea hacer una evaluación exhaustiva a mano o encontrar una instalación donde pueda probar la exactitud de sus reglas. La capacidad de registro en bitácora no se encuentra en todos los enrutadores. Si el enrutador no cuenta con esta capacidad, usted no sabrá si pasan paquetes peligrosos hasta que sea demasiado tarde. Además, con el fin de permitir ciertos tipos de acceso (que normalmente estarían bloqueados), podría verse en la necesidad de crear una excepción a las reglas que se impuso. Las excepciones algunas veces pueden hacer las reglas de filtrado muy difíciles o incluso inmanejables. ¿Cómo? Por ejemplo, si se especifica una regla para bloquear todas las conexiones que llegan al puerto 23 (el servidor Telnet).

125



ESPOCH-FIE-EIS

Suponiendo que hizo excepciones tales como aceptar las conexiones Telnet directamente, se requiere agregar una regla para cada sistema, ¿correcto? Bueno, en ocasiones este tipo de adición puede complicar todo el esquema de filtrado. No lo olvide: hacer pruebas a conjuntos de reglas complejos para verificar su exactitud podría ser tan difícil que usted nunca sería capaz de establecerlas bien. Otro inconveniente que se debe esperar es que algunos enrutadores de filtrado de paquetes no filtrarán en el puerto TCP/UDP origen. El conjunto de reglas de filtrado puede volverse muy complejo debido a ello y se puede terminar con fallas en todo el esquema de filtrado. Los servicios de Remote Procedure Call (RPC, Llamada de Procedimiento Remoto) son también muy difíciles de filtrar. Los servidores asociados vigilan los puertos que se asignan en forma aleatoria al inicio del sistema. El servicio portmapper relaciona las llamadas iniciales a los servicios RPC con los números de servicio asignados. Sin embargo, no hay un equivalente para un enrutador de filtrado de paquetes. Se vuelve imposible bloquear estos servicios completamente, debido a que no se puede indicar al enrutador en qué puertos residen los servicios (a menos que usted bloquee todos los paquetes UDP) debido a que los servicios RPC utilizan en su mayoría UDP. Pero si se bloquea todos los paquetes UDP, probablemente se bloqueará servicios que se requieren (Por ejemplo, DNS). Bloquear o no bloquear las RPC, he ahí el dilema. Es muy importante comprender los problemas que pueden presentarse y cómo abordarlos.

d) Gateways de aplicación Los dispositivos de filtración de paquetes, casi siempre se mejoran mediante gateways de aplicación (llamadas barreras de protección), que operan en las capas superiores del modelo OSI y tienen información completa sobre las funciones de la aplicación en la cual basan sus decisiones. Por ejemplo es posible configurar una puerta de enlace de correo para examinar cada mensaje que sale o e ntra. Para cada uno la puerta de enlace decide si transmitir o descartar el mensaje con base en los campos de encabezado, el tamaño del mensaje o en incluso en el contenido. Existen varios métodos para construir una barrera de protección .Las organizaciones con talento en la programación y recursos financieros prefieren usar un método de envoltura propia , el cual implica construir soluciones personalizadas para proteger la red de la organización. Otras organizaciones prefieren usar los productos comerciales existentes, así como personalizarlos y configurarlos para cumplir la política de seguridad de red de esas organizaciones. En general una barrera de protección se coloca entre la red interna confiable y la red externa no confiable, actuando como un punto ahogador que monitorea y rechaza el 126



ESPOCH-FIE-EIS

tráfico en la red a nivel de aplicación (figura 8.5). Las barreras también pueden operar en las capas de transporte y de red, aquí revisan los encabezados IP y TCP de los paquetes de entrada y de salida, además de rechazar o pasar los paquetes con base en las reglas programadas del filtro de paquetes. Barrera de protección

Aplicación Presentación Sesión Transporte Red Enlace de datos Física

Intranet

Internet

Figura 8.5 Operación de una barrera de protección 8.6 EJERCICIOS 1. Diseñe una política de firewall para su institución. ¿Qué tipos de paquetes permitirá que pasen? ¿por qué? 2. Lea la descripción de un filtrado de paquetes, de un ruteador disponible comercialmente. ¿Qué características ofrecen? 3. Dé dos razones por las que un grupo de personas que administra las políticas de seguridad de una organización deben separarse de las personas que administran los sistemas de red y las computadoras de una institución. 4. Algunas instituciones utilizan muros de seguridad para aislar grupos de usuarios internamente. Proporcione ejemplos de la forma en que l os muros de seguridad pueden mejorar el desempeño de la red interna y de cómo pueden degradar el desempeño de la red. 5. De una razón por la cual se configuraría un firewall para inspeccionar el tráfico entrante. De una razón por la cual se configuraría para inspeccionar el tráfico saliente. ¿Cree que las inspecciones sean exitosas?

127



ESPOCH-FIE-EIS

CAPITULO IX SEGURIDAD EN REDES 9.1 SEGURIDAD INFORMATICA Los conceptos iniciales de seguridad se evidencian en los inicios de la escritura con los Sumerios (3000 AC) o el Hammurabi (2000 AC). La Biblia, los relatos de Homero, Ciserón, son libros en los que aparecen rasgos referentes a la seguridad en la guerra y el gobierno. La arqueología nos muestra pruebas de seguridad en la antigüedad al observar los descubrimientos hechos en la pirámides egipcias, el templo de Karnak en el valle del Nilo. Los incas utilizaban los quipus para llevar el correo de forma segura de un lugar a otro, transportado por los chasquis y el quipus a su llegada era interpretado por los quipucamayos. Al definir el objetivo de la seguridad se habla de salvaguardar las propiedades y personas contra el robo, las inundaciones, el fuego, poder contrarrestar los disturbios sociales que puedan poner en peligro el progreso de un país, en definitiva buscar la paz y tranquilidad de la gente. En la actualidad la seguridad está en manos del poder legislativo quienes promulgan las leyes en la que deciden la valoración de los delitos y el correspondiente castigo. Si se dirige hacia el ámbito técnico la seguridad está a cargo de los administradores de las redes y de los usuarios de las computadoras . La llegada de las redes informáticas incrementó los riesgos de robo, de modificaciones no autorizadas y daños flagrantes a los datos. La computadora personal cambió todo lo existente en los grandes sistemas y minicomputadoras las que podían abrirse o cerrarse completamente y eran por tanto muy seguras. Una computadora hoy en día conectada a una red es una vía potencial de conflictos. Como va el desarrollo en la actualidad en el campo de la informática y de las comunicaciones cada día más computadoras estarán formando parte de la red, sea esta privada o pública como en el caso del Internet. Al tener acceso a Internet desde una red privada o el acceso de personas mediante una extranet se está añadiendo una gran cantidad de puertas a través de las cuales pueden entrar datos espurios y salir datos confidenciales. Todo el mundo tiene en la actualidad un profundo respeto con los riesgos asociados con Internet, que algunos denominan el paraíso de los hackers, pero las redes internas son vulnerables también por quienes trabajan con ellas de forma autorizada, el 70% de todos los ataques provienen de sus propios usuarios. La seguridad de un red interna se relaciona con la verificación de los usuarios, de la restricción del acceso a datos siempre que sea necesario y el cifrado de comunicaciones confidenciales para impedir su interceptación.

128



ESPOCH-FIE-EIS

9.1.1 CLASES DE SEGURIDAD INFORMATICA La información siendo intangible puede clasificarse en pública la cual esta al alcance de todas las personas y privada aquella que debe ser visualizada por quien la generó o un grupo de personas que trabaja con ella. La seguridad informática involucra datos, hardware y usuarios; en ella se deben tener en cuenta ciertos parámetros, como los indicados en la figura 9.1.

I A R O T I D U A

DA D I N CO N F I D E NC IA L I T E

SEGURIDAD INFORMATICA

D I S P O N I B I L I D A D

CONTROL

G R I D AD

I A C N E T S I S N O C

PARAMETROS CARACTERISTICAS Confidencialidad Proteger la información para que nadie pueda leerla o copiarla, sin la respectiva autorización de su dueño Integridad Proteger la información para evitar se borre o altere sin el permiso del propietario de la misma. Disponibilidad Proteger los servicios para que no se degraden o dejen de estar disponibles sin la respectiva autorización Consistencia Asegurar que el hardware y software se comporte como lo espera el usuario autorizado. Control Reglamentar la forma de acceder al sistema Auditoría Determinar qué se hizo, quién lo hizo y que fue afectado Figura 9.1 Parámetros de seguridad informática 9.2 POLITICAS DE SEGURIDAD Mediante las políticas se define que se considera valioso y se especifica las medidas a tomar para proteger esos activos (figura 9.2), deben ser generales y no variar mucho a lo largo del tiempo. Las políticas pueden escribirse de algunas maneras : 

 

Políticas sencillas y generales que en unas cuantas páginas cubran gran cantidad de posibilidades. Políticas para diversos activos Políticas pequeñas y sencillas, complementadas por estándares y recomendaciones sobre el comportamiento.

129



HARDWARE

DATOS

ESPOCH-FIE-EIS

SOFTWARE

ACTIVOS

DOCUMENTACION

GENTE

ACCESORIOS

Figura 9.2 Activos a proteger Las políticas juegan tres papeles principales: 1) Aclarar que se está protegiendo y por qué 2) Establecer la responsabilidad de la protección 3) Poner las bases para resolver e interpretar conflictos posteriores Los estándares codifican las prácticas exitosas de seguridad en una organización, son r edactados generalmente en términos de ―es obligatorio‖, implican una métrica que permite determinar si se han cumplido. Son un apoyo para las políticas y cambian lentamente en el tiempo. Las recomendaciones son redactadas en términos de ―debería‖ , busca interpretar los estándares en el contexto de un cierto entorno sea éste de programas o físico. Estas se pueden violar si resulta necesario pues solo constituyen guías para el comportamiento. Las recomendaciones suelen ser muy específicas y se basan en arquitecturas dadas, incluso relacionadas con una computadora determinada, estas cambian con más frecuencia que los estándares para tomar en cuenta los cambios de condiciones de trabajo.

9.3 SEGURIDAD FISICA La seguridad física en muchas de las corporaciones (entidades privadas), entidades públicas y universidades es olvidada, dando importancia casi siempre a la parte lógica de los equipos informáticos. A continuación se hace referencia a las seguridades físicas a ser consideradas en las redes.

9.3.1 DESASTRES Las computadoras y dispositivos activos requieren que las conexiones físicas y el entorno tengan un balance para evitar fallas de manera inesperada y nada deseables por lo que es necesario tener presente las consideraciones de la figura 9.3.

130


Aspectos a considerar Incendio

Agua Humo Polvo Terremotos

Temperatura Explosiones Bichos Rayos Humedad


ESPOCH-FIE-EIS

DESCRIPCION Las computadoras no resisten el fuego, así éste no las alcance, porque el excesivo calor se encargará de derretir el disco duro y las soldaduras, o el agua utilizada para sofocarlo las destruirá. En la actualidad se esta utilizando el bióxido de carbono comúnmente, pero en lugares donde existen computadoras que pueden salir ilesas cuando son expuestas el agua se sugiere rociadores de agua. El peligro principal con el agua es que provoca cortocircuitos, generalmente ésta proviene en los centros de cómputo; de la lluvia, inundaciones, bebidas (refrescos, café, etc) El humo actúa como abrasivo y se adhiere a las cabezas de los discos magnéticos , discos ópticos, unidades de cinta, causan fallas en los teclados. El polvo es abrasivo y destruye lentamente las cabezas de los discos magnéticos , las unidades ópticas y las unidades de cinta, puede provocar cortocircuito en los elementos activos. En los últimos años en el Ecuador no se han dado fuertes movimientos sísmicos, por lo cual las construcciones no respetan severas normas de seguridad respecto a la resistencia contra terremotos, sin embargo se debe estar preparado para ellos ya que nos encontramos en zona de alto riesgo. Las computadoras funcionan dentro de márgenes de temperaturas que son consideradas por los fabricantes como las adecuadas para evitar daños Pueden ser causadas por el mal uso de sustancias químicas inflamables almacenadas en el edificio Estos animales a veces se introducen en las computadoras provocando daños en sus componentes Estas descargas eléctricas de la naturaleza provocan altas variaciones de voltaje que dañan los equipos incluso cuando están protegidos Las computadoras requieren de pequeñas cantidades de humedad para su buen funcionamiento, pues evita el almacenamiento de cargas estáticas; pero si ésta se encuentra en demasía puede provocar condensaciones en los circuitos de las computadoras causando cortocircuito.

Figura 9.3 Entorno que puede afectar a las computadoras 9.3.2 ERGOMETRIA La interacción del ser humano con la computadora ha hecho que se le de importancia a las condiciones de trabajo, tomando en cuenta aspectos como la anatomía, filosofía y psicología del operador; buscando evitar problemas tales como el agotamiento, sobrecargas y envejecimiento prematuro. La figura 9.4 presenta aspectos ergonómicos a considerar.

131


Aspectos a considerar Trastornos óseos y o musculares Trastornos visuales Salud mental

Ambiente luminoso Ambiente climático


ESPOCH-FIE-EIS

DESCRIPCION La operación del teclado constituye un movimiento repetitivo y continuo que puede provocar lesiones en los músculos, nervios y huesos de manos y brazos La pantalla constituye una fuente de luz que incide directamente sobre los ojos del operador. Esto provoca en exposiciones prolongadas cansancio visual, irritación, lagrimeo, visión borrosa y cefalea La forma monótona de trabajar con las computadoras sobre todo en tarea de ingreso de datos provoca en las personas sensaciones de hastío y estrés informático que pueden llevar en el aspecto fisiológico al incremento de la presión arterial, al aumento de la frecuencia cardíaca; en el aspecto psicológico a la tensión, irritabilidad, agresividad; y de forma general a sensaciones de insatisfacción ante la vida, pérdida de la autoestima. La iluminación deficiente causa dolores de cabeza y pérdida de la visión, además de una baja en la productividad El ambiente donde el ser humano trabaja debe ser el adecuado evitando el exceso de calor o las bajas temperaturas.

Figura 9.4 Aspectos Ergonómicos 9.3.3 CONTROL DE ACCESO Los sistemas de control de acceso (figura 9.5) de los lugares permiten mantener protegidos los sistemas importantes.

Aspectos a considerar Personas

DESCRIPCION

El servicio de vigilancia está encargado de controlar el acceso de personas a los edificios, comúnmente mediante la colocación de guardias en lugares estratégicos. Se debe realizar el control del ingreso y egreso de vehículos e Vehículos identificación de sus ocupantes. Mediante esta tecnología se realizan mediciones en forma Sistemas biométricos electrónica que permiten comparar características únicas de cada persona (manos, ojos y voz) Termograma Basado en la emisión de calor corporal mediante el cual se trazan mapas de valores sobre la forma de cada persona Verificación Usando emisiones acústicas se toma datos del proceso dinámico automática de de firmar o escribir que constituye un patrón único en cada individuo, pues contiene información de la manera en que la firmas escritura es ejecutada Animales Los perros son utilizados para cuidar grandes extensiones de terreno por poseer órganos mucho más sensibles que cualquier dispositivo. 132



ESPOCH-FIE-EIS

Barreras infrarrojas

Son codificadas por medio de pulsos con el fin de evitar intentos de sabotaje; al ser el haz interrumpido se activa el sistema de alarma no puede ser afectado por la luz ambiental, calefacción, vibraciones. Microondas Son ondas de radio de frecuencia muy elevada, permitiéndo que se opere con señales de bajo nivel para que no sean afectadas por otras emisiones de radio, no son afectadas por turbulencias de aire o sonidos muy fuertes Crea un campo de ondas; ante cualquier movimiento que realiza Detector ultrasónico un cuerpo dentro del espacio protegido, genera una perturbación que acciona la alarma Circuito Se emplean cámaras colocadas estratégicamente, que permiten cerrado de controlar todo lo que sucede en el área en la que puede captar televisión imágenes la cámara

Figura 9.5 Control de acceso 9.4 CONTRASEÑAS Cada usuario que emplee una computadora deben tener una cuenta, la cual se identifique mediante el nombre de usuario y una contraseña, siendo esta última el sistema de autenticación más simple y el primer nivel de defensa que poseen los sistemas operativos contra los extraños. Las contraseñas son importantes en computadoras que se comparten entre varios usuarios o en computadoras que están conectadas a redes en las que varias computadoras tienen una relación de confianza entre ellas. Muchas de las computadoras personales no utilizan contraseñas facilitando su uso tanto al usuario primario como a cualquiera que esté cerca, y la seguridad de estas esta basado tan solo en medios físicos.

MAYUSCULAS Y MINUSCULAS

DIGITOS Y SIMBOLOS DE PUNTUACION +LETRAS Contiene

Contiene

SIETE U OCHO CARACTERES

Mínimo

CONTRASEÑAS BUENAS

e y u l c n I

CARACTERES DE CONTROL Y/O ESPACIOS

Fáciles recordar NO SEA NECESARIO ESCRIBIR EN PAPELES

Figura 9.6 Contraseñas buenas Cuando las computadoras están conectadas a un módem y se puede acceder desde casi cualquier parte del mundo en donde exista teléfonos, o cuando estas se conectan a una red que utiliza gente fuera del círculo inmediato al dueño entonces las contraseñas son muy necesarias. 133



ESPOCH-FIE-EIS

Los intrusos con una computadora casera y un buen programa para probar contraseñas pueden probar miles en menos de un día. Se dice que una mala contraseña es aquella que se puede adivinar, entre estas están el nombre del usuario, nombres de familiares, nombres escritos al revés o seguidos de un solo dígito, contraseñas cortas, números telefónicos, personajes de películas, nombres de científicos, etc. Las mejores contraseñas deben ser aquellas que no se pueden adivinar y que poseen las características indicadas en la figura 9.6.

9.5 CRIPTOGRAFIA La criptografía constituye la ciencia y el arte de escribir en clave, permitiendo de esta manera mantener la información en secreto. En las computadoras y las comunicaciones actuales se utiliza una forma de criptografía denominada cifrado que es un proceso por el cual un mensaje se transforma en otro mensaje utilizando una función matemática y una contraseña de cifrado especial, llamada clave. El cifrado desempeña un papel muy importante; pues protege la información almacenada en la computadora contra accesos no autorizados, o cuando ésta es transmitida de un sistema de cómputo a otro evitando alteraciones accidentales o intencionales. Las limitaciones del cifrado constituyen el no poder prevenir que un agresor borre intencionalmente todos los datos, que una persona modifique el programa de cifrado mismo, o construya un decodificador, por lo que el cifrado constituye solo una parte de la estrategia de seguridad. Todos los sistemas de cifrado tienen ciertos elementos en común como se indica en la figura 9.7.

ELEMENTOS SIGNIFICADO Algoritmo de cifrado Mediante fundamentos matemáticos desempeña la función de cifrar y decifrar sus datos Claves de cifrado Son utilizadas por el algoritmo de cifrado para determinar como cifrar o decifrar datos. El programa de cifrado usa su clave para transformar el texto cifrado en texto claro. Longitud de clave La clave tiene una longitud predeterminada , el usar claves largas hace más difícil adivinar usando la fuerza bruta. Texto en claro Información que se va ha cifrar Texto cifrado Información producto de cifrar Figura 9.7 Elementos de cifrado 9.5.1 TIPOS PRINCIPALES DE ALGORITMOS DE ENCRIPTADO En la actualidad están en uso dos tipos de algoritmos (figura 9.8) de clave privada y clave pública

134



ESPOCH-FIE-EIS

ALGORITMOS DE ENCRIPTADO

CLAVE PRIVADA

DES

IDEA

CAST

CLAVE PUBLICA

Skipjack

RSA

DSS

MD

Figura 9.8 Algoritmos de encriptado a) Clave privada Utiliza la misma clave para cifrar y descifrar el mensaje. Se le conoce también como criptografía simétrica, los algoritmos más conocidas son los siguientes:

Data Encryption Standard (DES)



Es uno de los más comúnmente empleados, desarrollado por IBM, es un algoritmo muy conocido , con una gran base de implementaciones en aplicaciones comerciales y gubernamentales. Es la norma gubernamental de encriptado de los EE. UU desde 1976, pero solo para material no ultra secreto. Kerberos utiliza el algoritmo DES para encriptar mensajes y para crear las llaves privadas que se emplean en las distintas transacciones. La llave puede ser cualquier número de 64 bits, pero debido a la forma que trabaja el algoritmo, su extensión efectiva es 56 bits. 14 Para romperlo se necesitaría 2.000 años si se prueba 1'000.000 de llaves cada segundo por medio de una búsqueda exhaustiva del espacio de llave, pues el algoritmo proporciona 2 56 llaves posibles. En 1997 el algoritmo fue abierto por DES Challenge .

International Encryption Algorithm (IDEA)



Es uno de los algoritmos más seguros y mejor estructurados, utiliza una operación de retroalimentación de encriptado que refuerza el algoritmo; de esta forma el texto de encriptado se emplea como entrada del algoritmo de encriptado. IDEA es ideal para FTP, donde se transmite gran cantidad de datos, pero funciona deficientemente con Telnet. Este algoritmo utiliza un tamaño de bloque de 64 bits, lo suficientemente sólido contra el criptoanálisis, no tiene problema cuando encripta grandes cantidades de datos.

14

Garfinkel Simson. Seguridad práctica en Unix e Internet. Pág. 516.

135





ESPOCH-FIE-EIS

Cast Utiliza un tamaño de bloque de 64 bits y una llave de 64 bits. El algoritmo emplea seis S-boxes con una entrada de 8 bits y una salida de 32 bits.



Skipjack Es un algoritmo sobre el cual se desconoce mucho porque esta clasificado como un secreto por el gobierno de Estados Unidos. Se conoce que utiliza una llave de 80 bits y tiene 32 vueltas de procedimiento por cada operación de encriptado o descencriptado. Es muy seguro pues si se emplea 100.000 computadoras RISC y cada computadora tuviera la capacidad de manejar cerca de 100.000 encriptados por segundo necesitaría 4 millones de años para abrir el código.

b) Clave pública En este modelo de criptosistemas se utiliza dos llaves que se usan juntas. Una de las llaves siempre permanece en secreto mientras que la otra es pública; puede utilizarse cada llave tanto para encriptado como descencriptado. Este sistema ayuda a resolver problemas de distribución de llaves a los usuarios, se utiliza para certificados, firmas digitales y texto simple.



Rivest Shamir Adleman (RSA) Fue desarrollado en 1977, se ha convertido en una especie de norma , pues es el más utilizado. Para trabajar RSA toma 2 números primos , p y q y encuentra su producto n=pq. Elige un número e, menor que n y relativamente primo a (p1)(q-1), y determina su inverso, d, mod(p-1)(q-1), lo que significa que ed=1mod(p-1)(q-1); e y d son los llamados exponentes público y privado, respectivamente. La llave pública es el par (n,e); la llave privada es d. Los factores p y q deben guardarse en secreto o destruirse. La seguridad de RSA dependerá del tamaño de la llave empleada.



Digital Signature Standard

(DSS)

Es una norma gubernamental estadounidense para firmas digitales, le permite claves entre 512 y 1024 bits. Tiene algunos problemas, la fuga de datos secretos es una de ellos, si utiliza 2 veces el mismo número aleatorio cuando genera la firma, se revelará la llave secreta.



Message Digest (MD) Los algoritmos de sintetización de mensajes se crearon para tomar cualquier mensaje como entrada y producir como salida una síntesis del mensaje. Existen 3 versiones disponibles que son: MD2, MD4 y MD5. 136



ESPOCH-FIE-EIS

MD5 es la versión más reciente, se puede utilizar para trasladar una cadena de bytes de longitud arbitraria en un valor de 128 bits. MD5 procesa el texto de entrada en bloques de 512 bits, divididos en 16 bloques secundarios de 32 bits. La salida es un conjunto de cuatro bloques de 32 bits, que están conectados en un solo valor de dispersión de 128 bits.

9.6 RESPALDOS Para la protección de los datos lo más importante es realizar respaldos y verificarlos, pues ante un desastre se puede comparar el sistema actual con el sistema respaldado y se puede restaurar el sistema a un estado estable, esto se puede hacer aun cuando se haya perdido el equipo físicamente. Los respaldos son importantes por razones como las que se indican en la figura 9.9.

RAZONES Errores de usuario

DESCRIPCION Los usuarios novatos casi siempre borran o sobre escriben archivos, destruyen directorios completos al cometer un error tecleando un carácter especial Errores del personal Los encargados del sistema pueden cometer errores, con respecto al servicio que se esta proporcionando a los de sistemas usuarios. Fallas de software Los programas de aplicación pueden venir con defectos ocultos que destruyen de pronto los datos Fallas de hardware Las famosas caídas del sistema que frecuentemente destruyen datos Los intrusos que con malicia alteran o borran datos. El Vandalismo robo del equipo y perdida consigo de la información Pérdidas causadas por desastres naturales como lluvia, Desastres terremotos, incendios. Fugas de agua Figura 9.9 Razones para realizar respaldos Existen tres tipos básicos de respaldos: 





Respaldo día – cero Se realiza una copia del sistema original. Respaldo completo Se hace una copia de cada archivo de la computadora en el dispositivo de respaldo. Respaldo incremental Se efectúa una copia en el dispositivo de respaldo solo de aquellos elementos en el sistema de archivo que se hayan modificado.

137



ESPOCH-FIE-EIS

9.7 CUENTAS A PROTEGER Cada cuenta en la computadora es una puerta hacia el exterior, que puede ser usada por usuarios autorizados y no autorizados. En la figura 9.10 se observan los tipos de cuentas. CUENTAS

SIN CONTRASEÑA

Cualquiera que conozca el nombre de la cuenta puede ingresar

PREDETERMINADAS

EJECUTAN SOLO UNA INSTRUCCION

Tienen generalmente contraseñas estándar. Como las cuentas que vienen con el sistema, aplicaciones que instalan cuentas para demostración de los programas.

Son cuentas creadas por el administrador que pueden ejecutar simplemente una sola instrucción o programa de aplicación ( ejemplo finger, date) cuando un usuario entra en ellas. A menudo estas cuentas no tienen contraseña

ABIERTAS

Son cuentas creadas para los visitantes ejemplo guest , suministrarlas en el sistema es muy mala idea . Los nombres y contraseñas de este tipo de cuentas son fáciles de adivinar y representan un problema para la seguridad.

GRUPO

Es usada por más de una persona permiten a un grupo de personas trabajar en un mismo proyecto sin tener que crear una cuenta para cada persona. Los usuarios muchas veces prestan estas cuentas más facilidad que las cuentas personales.

Figura 9.10 Clases de cuentas 9.7.1 FORMAS DE DETECTAR CAMBIOS EN ARCHIVOS Existen tres formas de detectar cambios en los archivos:

a) Usar copias para comparar datos a vigilar : Se mantiene una copia de datos no alterados y se realiza una comparación byte a byte cuando se necesita; al existir un cambio se podrá detectar él mismo. Al descubrirse un cambio no autorizado se podrá realizar la restauración del sistema a la normalidad. Este método es considerado demasiado costoso, pues se requiere espacio sustancial de disco para almacenar las copias.

b) Listas de control y metadatos: Es un método más eficiente mediante el cual se guarda un resumen de cada archivo y directorio, al ser necesario hacer una comparación las características serán regeneradas y comparadas con la información almacenada. Esto permite detectar cambios en los metadatos tales como en los propietarios de los archivos o los modos de protección. Este método tiene un problema debido a que pueden los archivos ser modificados de tal forma que la información que se vigila no muestre el cambio. 138



ESPOCH-FIE-EIS

c) Listas de control y firmas: Consiste en crear una firma digital para los contenidos de los archivos para determinar si se efectúo un cambio. El sistema de firmas digitales de uso más común es la combinación de mensajes MD5 y el mecanismo de cifrado con clave pública RSA.

9.8 VIGILAR EL COMPORTAMIENTO DEL SISTEMA La vigilancia de los mecanismos de protección permitirán ver que estos realmente funcionen. Las bitácoras son la forma de poder detectar problemas (causas de errores), o localizar ataques (fuente de intromisión) y avalizar el daño causado, pues revelan problemas en el equipo, con la configuración de la red y con la seguridad Los programas de noticias de Usenet, los servidores gopher, las aplicaciones de bases de datos, la World Wide Web, y muchas otras aplicaciones generan bitácoras en las cuales se van registrando el uso e indican potenciales problemas. El proceso de auditar puede ayudar a decidir sobre necesidades de la red y resolver ciertos problemas que puede sufrir el entorno. Durante la auditoría de la red comúnmente se decide que equipos de red se desea auditar y la información que sobre los mismos se desea obtener. Lo mejor es auditar sucesos relacionados con información privilegiada y seguridad. Los archivos de registro de seguridad nos permiten conocer sobre sucesos tales como: 



  

  

Intentos de inicio de sesión completados con éxito y/o fallidos; cambios, creaciones o eliminaciones de cuentas de usuario o de grupo. Registro de cuando una cuenta cambia de nombre, se desactiva, se activa o se vuelve a establecer su contraseña. Inicios o cierres de sesión de usuario. Acceso a un archivo carpeta o impresora por parte de un usuario. Cambios realizados en las opciones de seguridad de un usuario, derechos de usuario y planes de auditoría. Acción desarrollada por un usuario en el sistema local. Acción realizada por un programa. Sucesos que afectan a la seguridad del sistema operativo o la seguridad en general.

9.9 AMENAZAS LOGICAS Los errores de programación son la causa más común del comportamiento inesperado de un programa, pero si en cambio la fuente de instrucciones que hacen que el programa se comporte de forma anormal es debido a un individuo malicioso, entonces se está hablando de amenazas lógicas. Existen programas maliciosos que son usados para ataques lógicos como los que se muestra en la figura 9.11. 139



ESPOCH-FIE-EIS

PROGRAMAS DEFINICIONES Herramientas Diseñadas para que los administradores las utilicen en seguridad de seguridad para encontrar problemas en sus sitios, además pueden ser utilizadas por alguien que busque fallas a explotar. También existen programas y juegos de herramientas que su única función es atacar a las computadoras Puertas Es código escrito dentro de aplicaciones o sistemas operativos que traseras permiten a los programadores el acceso a programas sin que sea necesario que paseen a través de autenticación de acceso, por lo tanto permiten el acceso no autorizado al sistema. Bombas Son características ocultas en programas que permanecen en ese lógicas estado hasta que se disparan, ejecutando una función que no es propia del programa en la cual están contenidas. Una vez que se dispara puede destruir o alterar datos, interrumpir el funcionamiento de la computadora o dañar el sistema. Caballos de Son similares a los programas que un usuario le gustaría usar troya (juegos, editores, hojas de cálculo, páginas Web, correo codificado en MIME), pero mientras el programa parece estar realizando lo que se le ordena , esta haciendo algo más sin el conocimiento del usuario. Gusanos Son programas que se propagan de computadora en computadora en una red, sin necesariamente hacer modificaciones en otros programas de la máquina en la que se encuentran, a no ser que contengan otro código que si lo haga (virus) Bacterias Son programas que no dañan ningún archivo, lo que hacen es copias de si mismos con el fin de saturar los recursos de un sistema (capacidad de procesador, la memoria, espacio en disco), reproduciéndose de forma exponencial. Virus Es código que se inserta en otro código ejecutable, para que en el momento que se ejecute el programa que requiere el usuario, el programa virus también se ejecute. Los virus se encuentran de forma general en computadoras personales. Figura 9.11 Programas usados en las amenazas lógicas Estos ataques se realizan por las razones siguientes: La mayoría de las puertas traseras, bombas lógicas, caballos de troya y bacterias aparecen en el sistema porque se escribieron allí, por lo que la más grande amenaza al sistema es su propio grupo de usuarios que entienden el sistema, conocen sus debilidades y saben sobre los sistemas de control y auditoría existentes. Los usuarios también pueden ser agentes involuntarios de transmisión de virus, gusanos y otros tipos de amenazas, al instalar programas obtenidos de fuentes de dominio público, por ejemplo mediante un proceso simple se bajan de la WWW.

140



ESPOCH-FIE-EIS

Si una máquina es conectada a una red o a otro medio de comunicación computadora a computadora , los programas como gusanos que pueden contener bombas lógicas o virus tendrán una forma de ingresar. La mayoría de los sistemas se configura confiando en los usuarios , las máquinas y los servicios en el ambiente local.

9.9.1 TIPOS DE ATAQUES Los ataques se llevan a cabo sobre cualquier tipo de red, sistema operativo, usando diferentes protocolos. Existe una gran cantidad y variabilidad de los mismos, y estos se llevan a cabo remotamente.

a) Ingeniería Social Se basa en convencer a las personas de que realicen acciones que normalmente no lo hacen para que revele lo necesario con la finalidad de superar las barreras de seguridad, es muy utilizada para averiguar nombres de usuarios y passwords. b) Trashing Los usuarios anotan su login y password en papelitos que luego cuando se lo graban en la mente proceden a votar en la basura. c) Shoulder Surfing Explota el error de los usuarios de dejar su login y password anotados cerca de la computadora o ver al usuario por encima del hombro en el momento en que teclea su nombre y password. d) Decoy Son programas que se diseñan con la misma interfaz que el original que conoce el usuario, en el cual se imita la solicitud del login y el usuario desprevenido lo hace; el programa guardará esta información y dará paso a las actividades normales del sistema. Otra técnica semejante es mediante un programa que permite guardar todas las teclas presionadas en una sesión. e) TCP Connect Scanning Es el scanneo de puertos TCP; si el puerto está habilitado devolverá una respuesta de éxito. Para usar esta técnica no se necesita de privilegios especiales. f) TCP SYN Scanning En esta técnica se envía un paquete SYN como si se deseara abrir una conexión y se espera por la respuesta ACK; e inmediatamente recibida esta se envía un RST para terminar la conexión y se registra el puerto como abierto g) TCP FIN Scanning – Stealth Port Scannig Debido a que en la actualidad los Firewalls y Routers monitorean la red en busca de paquetes SYN a puertos restringidos, el TCP SYN Scanning no es lo 141



ESPOCH-FIE-EIS

suficientemente clandestino para ser utilizado por los atacantes. El tipo de scanneo TCP FIN se basa en la idea de que los puertos cerrados tienden a responder a los paquetes FIN con el RST correspondiente; mientras que los puertos abiertos suelen ignorarlo.

h) Eavesdropping – Packet Sniffing Este ataque se realiza utilizando programas sniffers, los cuales monitorean los paquetes que circulan por la red; pueden ser ubicados en una estación de trabajo conectada a la red, en un router o gateway de Internet; para lo cual el usuario que lo realiza debe tener acceso legítimo a estos dispositivos. Se emplea comúnmente para robar password de un recurso compartido o de acceso a una cuenta que viajen sin encriptar; capturar números de tarjetas de crédito y direcciones de e-mails; para lo cual se analizan las tramas de un segmento de red. i) Snooping Downloading A diferencia del anterior además de interceptar el tráfico de red, el atacante ingresa los documentos, mensajes de correo electrónico y otra información guardada, para a continuación, en la mayoría de los casos realizar copias de estos a su propia computadora, para luego proceder a un análisis exhaustivo. j) Spoofing – Looping El objetivo de esta técnica es actuar en nombre de otros usuarios; para lo cual el intruso utiliza un sistema para obtener información y utilizar en otro sistema, y luego utiliza esta información para ingresar en otro y así sucesivamente, lo que hace casi imposible la ubicación del atacante. El envío de falsos e-mail es otra forma de Spoofing, en el cual el atacante envía un e-mail a nombre de otra persona. k) IP Spoofing El atacante genera paquetes de Internet con una dirección de red falsa en el campo fuente, que es aceptado por el destinatario del paquete. Si la víctima descubre el ataque verá a otra máquina como su atacante y no al verdadero origen. l) Web Spoofing Se crea un sitio Web completo similar al que la víctima desea ingresar; permitiéndole monitorear al atacante todas las acciones de la víctima. m) IP Splicing-Hijacking El atacante consigue interceptar una sesión ya establecida; esperando primeramente que el usuario legítimo se identifique ante el sistema y tras ello le suplanta como usuario autorizado. Para este ataque son utilizados los Sniffer que permiten ver todo el proceso Handshake; desarrollado éste el atacante calcula el número de secuencia siguiente, luego del cual él envía el paquete. El servidor no notará el cambio de origen

142



ESPOCH-FIE-EIS

n) Jamming Se utiliza para desactivar o saturar los recursos del sistema, para lo cual el atacante utiliza falsas direcciones IP, el servidor al responder al mensaje y no recibir respuesta acumula buffers con información de las conexiones abiertas, no dejando lugar a las conexiones legítimas. Otra forma es enviando miles de emails sin sentido a todos los usuarios posibles en forma continua, saturando los sistemas destino. o) SYN Flood El proceso handshake se lleva a cabo en tres pasos, si el paso final no llega a establecerse, la conexión permanece en un estado den ominado ―semiabierto‖, Si se crean muchas peticiones incompletas de conexión el servidor estará inactivo mucho tiempo esperando respuesta ocasionando lentitud en los demás servicios . p) Connection Flood Los ISP tienen un límite máximo en el número de conexiones simultaneas, una vez alcanzado el mismo no se admitirán conexiones nuevas; mientras van caducando las conexiones el atacante intenta nuevas conexiones para mantener fuera de servicio al servidor q) Land Attack Este ataque es común a las plataformas Windows en el cual se envía a un puerto abierto de un servidor un paquete que contiene la dirección y puerto fuente igual a la del destino; luego de una cierta cantidad de este tipo de mensajes provoca la caída del sistema. r) Uso de diccionarios Son archivos con millones de palabras, las cuales pueden ser posibles password de los usuarios, esta forma de obtener información del usuario legítimo se conoce como fuerza bruta. s) Broadcast Storm Se basa en la recolección de una serie de direcciones broadcast, para a continuación enviar una petición ICMP (ping) a cada una de ellas en serie, varias veces, falsificando la dirección IP de origen. La petición maliciosa hecha, será repetida en broadcast por cientos o miles de host enviando una respuesta de eco a la víctima cuya dirección IP figuraba en el paquete ICMP como que realizaba el ping. t) Out of Band, Supernuke El ataque OOB consiste en configurar el bit URG del TCP como válido, lo que provoca que a estos paquetes trate de darles prioridad el sistema operativo de la máquina atacada. El Nuke es una ataque que se realiza contra los equipos con windows, que escuchan por el puerto NetBios (137-139) mediante el envío de paquetes UDP manipulados

143



ESPOCH-FIE-EIS

u) E-mail bombing, spamming El bombing consiste en enviar gran cantidad de veces el mismo mensaje a una misma dirección, saturando así el buzón del destinatario. El spamming es enviar e-mails a miles de usuarios hayan estos solicitado el mensaje o no.

v) Ataques con Java Applets Los applets son código ejecutable y por lo cual susceptibles de ser manipulados por intrusos, existe gente especializada en descubrir fallas de seguridad en las implementaciones de Java. w) Ataques con JavaScript y Vbscript Son programas que son interpretados por el navegador por lo cual los atacantes los utilizan para explotar vulnerabilidades específicas de navegadores y servidores de correo. x) Ataques con ActiveX ActiveX aparentemente soluciona los problemas de seguridad mediante certificados y firmas digitales, pero esta característica se ha convertido en su mayor punto débil, debido a que la mayoría de los usuarios aceptan el certificado sin siquiera leer, pudiendo ser esta la fuente de un ataque con un control dañino. 9.10 PROCESO DE ATAQUE A LAS REDES INFORMATICAS Quienes atacan las redes lo hacen mediante procedimientos estructurados que les permite ir conociendo a su víctima, utilizando herramientas gratuitas o comerciales. El proceso es el siguiente:

1) Búsqueda de Información Lo primero que hará un atacante, es examinar la página Web de la víctima, buscando información que le pueda ser útil, para lo cual puede emplear herramientas de copiado de sitios web enteros:

Herramienta Wget Teleport Pro

Sistema Operativo UNIX Windows

Página web http://www.gnu.org/software/wget/wget.html http://www.tenmax.com/teleport/home.htm

Figura 9.12 Herramientas de copiado de sitios Web También para buscar páginas Web empleando la herramienta FerretPRO (http://www.ferretsoft.com) que le permite utilizar varios buscadores simultáneamente, o emplear un buscador múltiple como dogpile (http://www.dogpile.com), o realizar búsquedas avanzadas en su buscador favorito. Además de esta fuente utiliza otras como pueden ser: 144


   

 


ESPOCH-FIE-EIS

Notas de prensa Números de teléfono Nombres de contactos y direcciones de correo electrónico Directivas de seguridad o privacidad que indiquen los tipos de mecanismos de seguridad instalados en la red Enlaces a otros servidores web relacionados con la Institución Revisión del código fuente HTML buscando comentarios que le sean beneficiosos.

Después procede a revisar los nombres de dominio y redes asociadas con la Institución, para lo cual se realiza una investigación en base de datos existentes en el Internet relacionadas a la Institución.

2) Fallas en la configuración del DNS Identificado el nombre de dominio procederá a consultar el servidor DNS, para comprobar si está configurado de forma insegura para poder obtener información muy importante sobre la Institución víctima. Una de las fallas más serias que un administrador puede cometer es la de permitir que se realice una transferencia de zona de DNS a usuarios de Internet no autorizados. El problema surge cuando una Institución no utiliza un mecanismo de DNS públicoprivada para separar su información de DNS, entre la información externa que es pública de la interna que es información DNS privada; pues en este caso el atacante puede ver los nombres de Hosts internos y las direcciones IP. Para transferir la zona desde una máquina con sistemas operativos Unix, NT o W2000 Server o W2003 Server, puede utilizar el cliente nslookup. Existen herramientas que se pueden utilizar para transferencia de zona como axfr (http://cr.yp.to/djbdns/axfr-get.html ), que transfiere de forma recursiva información de zona y crea una base de datos comprimida de la zona y de los archivos huésped para cada uno de los dominios consultados. Tambien se utiliza Sam Spade.

3) Identificación de la topología Para identificar la topología de una red y sus posibles rutas de acceso potenciales se utiliza el programa traceroute para el caso de Unix o tracert para Windows. Estas herramientas le permiten ver la ruta que sigue un paquete IP desde un host al siguiente. Para explorar sistemas que estén situados detrás de un dispositivo de control de acceso ( se da cuenta de esto porque al realizar un traceroute normal en la indicación de los saltos empiezan a salir tres asteriscos * * *) se envían paquetes con el puerto UDP 53 fijo. $ traceroute – s –p53 Ipmáquina atacada

145




Existen herramientas que tienen un sistema gráfico para identificar la topología que realizan el mismo trabajo que traceroute o tracert.

Herramienta Visual Route Neo Trace

Dirección de Internet http://www.visualroute.com http://www.neotrace.com// http://www.neotrace.com

Figura 9.13 Identificación de la topología 4) Determinación de la actividad de de un sistema Para verificar que un sistema esta activo se realiza un barrido ping automatizado automatizado en un rango de direcciones IP y bloques de red, previo al ataque real. La técnica más simple es enviar paquetes ICMP Echo (tipo 8) para obtener paquetes ICMP Repley (tipo 0). Para realizar barridos ping se emplea herramientas como las indicadas a continuación que envían gran cantidad de solicitudes (direcciones IP).

Herramientas Fping

Sistema Operativo UNIX

Dirección de Forma de usar Internet http://www.fping.com $ fping –f dirección de dominio

Nmap

UNIX

www.insecure.org/n map

$ nmap –sp IP/n

Pinger

Windows

ej: n=16 http://www.kilievich.c Herramienta gráfica om

WS_Ping ProPack NetScan

Windows

www.ipswitch.com

Windows

www.nwpsw.com

Herramienta gráfica, redes pequeñas Herramienta gráfica, redes pequeñas

para para

Figura 9.14 Herramientas para determinar la actividad del sistema Para solicitar la hora del sistema (timestamp) o la máscara de red (address mask request), con la finalidad de determinar todas las subredes que se están utilizando y poder de esta forma dirigir un ataque ataque a una subred específica, específica, se puede utilizar las herramientas Unix: http://www.pestpatrol.com/PestInfo/i/icmpquery_c.asp)) o Icmpquery (http://www.pestpatrol.com/PestInfo/i/icmpquery_c.asp http://packages.qa.debian.org/i/icmpush.html)) icmpush (http://packages.qa.debian.org/i/icmpush.html Existe también la herramienta Solar Winds

que trae consigo herramientas de

administración de red, red, monitor de red y herramientas herramientas para descubrimiento descubrimiento de redes. redes. El sitio donde se encuentra la herramienta es www.solarwinds.net

146




5) Exploración de los puertos Cuando el tráfico ICMP se encuentra bloqueado, se realiza una exploración de puertos de cada una de las direcciones IP que se desee para determinar que hosts están activos en función de los puertos que están abiertos o a la espera. Al determinar los servicios que se están ejecutando o están en estado listening mediante la exploración de los puertos UDP y TCP, se puede establecer el tipo de sistema operativo y aplicaciones que se están utilizando. Existen muchas herramientas para la exploración de los puertos como las que se indica en la figura 9.15 y figura 9.16.

Herramienta Dirección para Características para Unix obtener Udp_scan http://wwdsilx.wwdsi.c Desarrollado inicialmente por SATAN es om/saint/ uno de los exploradores UDP más fiables de los que existe actualmente. Las búsquedas se realizan por debajo del puerto 1024, y determinados puertos de alto riesgo por encima de 1024. $udp_scan IP 1-1024 Nmap http://www.insecure.or Es una herramienta que ofrece muchas g/nmap características como las siguientes: Para hacer escaneo de los puertos TCP, se utiliza la opción –sS (nmap –sS IP) Para los puertos UDP (nmap –sU IP Con la opción avanzada TCP ping scan (nmap –sp –PT80 IP/n) el número de puerto (80) puede ser cualquiera. Esta opción envía paquetes TCP ACK a la red objetivo y espera un RST que indicará que el host está activo, se utiliza este tipo de paquetes por tiene gran probabilidad de pasar a través del firewall. Hping http://www.kyuzz.org/ Es mejor que nmap, al permitir controlar antirez opciones específicas del paquete TCP, se puede traspasar ciertos dispositivos de control de acceso ( hping IP –S –p 80 –f ). Una de estas opciones es la fragmentación de paquetes ante la cual los dispositivos de control de acceso no sofisticados no pueden manejar correctamente permitiendo que estos paquetes los atraviesen. Figura 9.15 Herramientas para la exploración de puertos en Unix

147




Herramienta Dirección para obtener para Windows SuperScan http://www.foundstone.co m/rdlabs/termsofuse.php? filename=superscan.exe WinScan http://www.prosolve.com

Características

IpEye

http://ntsecurity.nu

WUPS

http://ntsecurity.nu

Realiza exploración de puertos y exploraciones SYN, FIN, Xmas desde la línea de comandos de Windows, solo se puede ejecutar en Windows 200 y solo puede analizar un host de forma simultánea. Es un analizador de puertos UDP gráfico gráf ico y relativamente rápido.

Permite especificar las direcciones IP y listas de puerto del sistema destino Tiene una versión gráfica y también de línea de comandos.

Figura 9.16 Herramientas para la exploración de puertos en Windows 6) Detección del sistema operativo Para los atacantes detectar el Sistema Operativo es importante por que existen vulnerabilidades que son específicas de cada uno de ellos. Esto se debe a que cada fabricante cuando escribe sus pilas TCP/IP las interpreta a su manera de lo que viene escrito en el normativo del RFC correspondiente y con estas diferencias es que se detecta el sistema operativo que se esta utilizando. Los sondeos que se envían y que permiten distinguir un sistema operativo se indican en la figura 9.17.

TIPO DE SONDEO Sondeo FIN

Sondeo Bogus Flag Tamaño de ventana inicial TCP Valor ACK

CARAC CARACTER TER STICAS STICAS Se envía un paquete fin a un puerto abierto. Según el RFC 793 la forma correcta es no responder a este paquete , sin embargo existen sistemas operativos que responden con FIN/ACK, como los de Windows Se coloca una bandera indefinida en la cabecera TCP de un paquete SYN. Algunos Sistemas Operativos como linux responden con esta bandera en su paquete de respuesta En algunos desarrollos de pilas el tamaño de la ventana inicial es único

Cuando responden con el ACK algunos sistemas operativos lo hacen con el mismo número de secuencia recibido y otros lo hacen con el número de secuencia secuencia + 1. Muestreo del Se busca un patrón en la secuencia inicial elegida por la número de implementación TCP cuando responde a una petición de secuencia inicial conexión Supervisión del bit Algunos sistemas sistemas operativos operativos activa el bit de no fragmentar para 148



ESPOCH-FIE-EIS

de no fragmentar Cita de mensajes ICMP

mejorar su rendimiento Entre los sistemas operativos difieren en la cantidad de información que entregan cuando envían mensajes de error ICMP. Integridad de los Algunos desarrollos de pilas TCP/IP pueden alterar las mensajes de error cabeceras IP cuando devuelven mensajes de error ICMP. ICMP Tipo de servicio En los mensajes ICMP de puerto inaccesible, la mayoria de los desarrollos de pilas utilizan un 0, pero existen otras posibilidades Gestión de Cada pila maneja de forma diferente los fragmentos que se fragmentación superponga. Algunas pilas cuando recomponen los fragmentos escriben los datos nuevos sobre los viejos, y viceversa. Analizando como se recompone los paquetes de sondeo, se puede realizar suposiciones sobre cual es el sistema operativo objetivo Opciones TCP Estas opciones son definidas en el RFC 793 y de forma mas reciente en el RFC 1323; donde se pueden encontrar las opciones mas avanzadas, que suelen a su vez estar en los desarrollos de pila más modernos. Enviando un paquete para el que se han definido una serie de acciones, es posible realizar algunas hipotesis sobre cual es el sistema operativo objetivo

Figura 9.17 Sondeos utilizados para identificar un sistema operativo Para la detección del S.O se utiliza herramientas que poseen funciones de rastreo de pilas que emplean las técnicas antes mencionadas, que nos permite averiguar rápidamente y con una alta probabilidad cual es el sistema operativo instalado en el host. Nmap (http://www.insecure.org/nmap) es una de las herramientas más empleadas por la cantidad de opciones que posee. La opcion –o de seguimiento de pilas permite averiguar el sistema operativo objetivo. $ nmap –o Ipmáquina atacada # nmap –p80 –o Ipmáquina atacada

si no existen puertos abiertos

Otra forma que utilizan los atacantes para determinar el sistema operativo es la observación pasiva del tráfico que circula por la red (http://project.honeynet.org) que se basa en el tiempo de vida (TTL), tamaño de ventana, bit de no fragmentación, que es comparado con una base de datos que contiene los atributos indicados para diferentes sistemas operativos. Existe una herramienta denominada siphon(http://siphon.datanerds.net/) para realizar esta actividad. # siphon –v –i x10 –o fingerprint.out Se puede emplear también Cheops (http://www.marko.net/cheops/) que es una herramienta de exploración de red pero gráfica.

149

Protocolos y redes. Ing. Patricio Moreno

Recommend Documents