Protocolos y Redes. Ing. Patricio Moreno

Ing. M.Sc. Patricio Moreno C.
Integración de Sistemas ESPOCH-FIE-EIS
CAPITULO I
PROTOCOLO DE CONFIGURACION DINAMICA DE HOST
1.1 CONFIGURACION DEL ANFITRION
El protocolo 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 protocolo RARP se determina que existen tres

inconvenientes para su uso:
1. Debido a que RARP opera en un nivel bajo, su uso requiere de un 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 se necesita hacer un proceso de solicitud, para en la 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 una dirección de 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 di-
rección permanente cuando una computadora es conectada por primera vez a la
1
Ing. M.Sc. Patricio Moreno C. Integración de Sistemas ESPOCH-FIE-EIS
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 direcció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

INICIA-
R LIZAR
VE
I SCO
CPD
arrendamiento
DH
Fin de
SELEC- DHCPNACK
DHCPOFFER DHCPNACK
CIONAR
Cancelación arrendamiento
DHCPREQUEST UNIR DE DHCPREQUEST RENO-
NUEVO 87% de arrendamiento VAR
SOLICI-
DHCPACK
TAR DHCPACK
DHCPREQUEST
50% de arrendamiento
DHCPACK
ENLA-
ZAR
DHCPRELEASE
Figura 1.1 Estados de un cliente DHCP y las transiciones 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
DHCPDISCOVER y cambia al estado con el nombre SELECT(SELECCIONAR). El
cliente envía el mensaje DHCPDISCOVER en un datagrama UDP con el puerto de
destino activado para el puerto el puerto 67. Todos los servidores DHCP de la red
3
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
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
1.6 FORMATO DE LOS MENSAJES DHCP
0 8 16 24
31
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
Saltos 8 bits Indica la cantidad de servidores que reenviaron la solicitud
Identificador de Contiene un valor que el cliente utiliza para determinar si la
transacción respuesta corresponde a su solicitud. El valor de la respuesta
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
cliente 32 bits que ya le fue asignada, la ubicará en este campo.
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 32 bits servidor, caso contrario estará puesto a cero, por lo que
responderá cualquier servidor que reciba la solicitud.
Dirección IP del Contiene la dirección IP del ruteador predeterminado
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 Si el cliente conoce el nombre de dominio del servidor lo ubica

anfitrión servidor en este campo, caso contrario el espacio se desprecia y no se
llena de ceros debido a que ocupa muchos octetos
Nombre del Si una computadora no posee un sistema operativo y realiza la
archivo de solicitud de uno específico, el servidor le enviará el nombre del
arranque 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.
Opciones 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
A al anfitrión B)? ¿La respuesta difiere 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
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.
CLIENTE SERVIDOR
TELNET TELNET
El servidor
envía a una
pseudo terminal
TCP TCP
Dispositivo
de E/S IP IP
Usuario
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
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 Formato NVT

Dispositivo de cliente utilizado utilizado
de E/S
Cliente Cliente Sistema del
Usuario Conexión TCP Formato del Servidor
Red de redes 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 Valor Significado asignado

control ASCII decimal
NUL 0 No hay operación (sin efecto en la salida)
BEL 7 Sonido audible/señal visible (sin movimiento)
BS 8 Movimiento a la izquierda de un carácter
HT 9 Movimiento a la derecha al siguiente tabulador
horizontal
LF 10 Movimiento hacia abajo (vertical) a la siguiente Línea
VT 11 Movimiento hacia abajo al siguiente tabulador vertical
FF 12 Movimiento hacia arriba a la siguiente página
CR 13 Movimiento hacia la izquierda en la línea presente
Otro control • 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
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 SIGNIFICADO
IP (Interrupt Process) Interrupción del proceso (termina de correrse el programa)

AO (Abort Output) Salida abortada (se descarta cualquier salida de búfer)
AYT (Are You There) Estás ahí (prueba si el servidor responde)
EC (Erase Character) Borra carácter (borra el carácter previo)
EL (Erase Line) Borra línea (borra toda la línea actual)
SYNCH (Synchronize) Sincroniza (despeja la trayectoria de datos hasta que el punto
de datos TCP es urgente, pero interpreta comandos)
BRK (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 SIGNIFICADO

DECIMAL
IAC 255 Se interpreta al siguiente octeto como comando
(cuando el octeto IAC aparece como dato, quien envía lo
12
duplica y manda una secuencia de dos octetos IAC-IAC)

DON'T 254 Negación de petición para ejecutar una opción
especificada
DO 253 Aprobación para permitir una opción especificada
WON'T 252 Rechazo de ejecución de una opción especificada
WILL 251 Autorización de realizar una opción especificada
SB 250 Inicio de subnegociación de opción
GA 249 Señal para "continuar" (go ahead)
EL 248 Señal de "borrado de línea" (erase line)
EC 247 Señal de "borrado de carácter" (erase character)
AYT 246 Señal de "estás ahí" (are you there)
AO 245 Señal de "aborto de salida" (abort output)
IP 244 Señal de "interrupción de proceso" (interrup process)
BRK 243 Señal de "pausa" (break)
DMARK 242 La porción de corriente de datos de un SYNCH (siempre
acompañada de una notificación Urgente del TCP)
NOP 241 Sin operación
SE 240 Fin de la opción de subnegociación
EOR 239 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
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 half-
duplex 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
extremos de una conexión
Tipo de terminal 24 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)
Fin de registro 25 Termina los datos mandados con código EOR
Modo de línea 34 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
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 solu-
ció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
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 pro-

gramas 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 mientras 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
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
CLIENTE SERVIDOR
PROCESO PROCESO TRANSF.

TRANSF. DE DE DE
DE CONTROL CONTROL DATOS
DATOS
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
c:\> ftp
ftp> help
Los comandos se pueden abreviar.
! delete literal prompt send

? debug ls put status
append dir mdelete pwd trace
ascii disconnect mdir quit type
bell get mget quote user
binary glob mkdir recv verbose
bye hash mls remotehelp
cd help mput rename
close lcd open rmdir
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
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
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 FORMA DE TRANSFERIR

Archivo de texto ASCII
Hoja de cálculo Binario
Base de Datos Binario o ASCII
Archivo de procesador de palabras Binario o ASCII
Programa fuente ASCII
Mensajes de correo ASCII
Archivo de respaldo Binario
Archivo comprimido Binario
Archivo ejecutable Binario
Archivo postcript ASCII
Documento de hipertexto ASCII
Archivo de imagen (gif, jpeg, mpeg) 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
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
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
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 es-
tructura 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
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
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
pmoreno@200.110.20.42 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 pmoreno@espoch.edu.ec. 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 nombre 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
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
Servidor DNS au
Ref. a gov.au
gov.au
Ref. a space.gov.au
space.gov.au
Respuesta
Pregunta mars.space.gov.au 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
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 gobierno federal de Estados Unidos), int (ciertas organizaciones
internacionales), mil (las fuerzas armadas de Estados Unidos), net (proveedores de
red) y org (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
Genérico De País
int com org jp

edu gov mil net
ac co ec nl
sun cisco acm
berkeley ieee epn espoch vu
oce
keio nec cs
jack jill
flits 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 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 ü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 o un dominio de nivel superior, puede tener un
grupo de registros de recursos asociados a él. En un host 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
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.
Tipo Significado Valor

SOA Inicio de autoridad Parámetros para esta zona
A Dirección IP de un host Entero de 32 bits
MX Intercambio de correo Prioridad, dominio dispuesto a aceptar correo
electrónico
NS Servidor de nombres Nombre de un servidor para 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 SOA 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
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,
bill@microsoft.com, 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 paul@cs.mit.edu 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
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 person@cs.vu.nl.
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. 86400 IN SOA Star boss (9527,7200,7200,241920,86400)

cs.vu.nl. 86400 IN TXT "Divisie Wiskunde en Informática."
cs.vu.nl. 86400 IN TXT "Vrije Universiteit Amsterdam."
cs.vu.nl. 86400 IN MX 1 zephyr.cs.vu.nl.
cs.vu.nl. 86400 IN MX 2 top.cs.vu.nl.
flits.
cs.vu.nl. 86400 IN HINFO Sun Unix
flits.
cs.vu.nl. 86400 IN A 130.37.16.112
flits.
cs.vu.nl. 86400 IN A 192.31.231.165
flits.
cs.vu.nl. 86400 IN MX 1 flits.cs.vu.nl.
flits.
cs.vu.nl. 86400 IN MX 2 zephyr.cs.vu.nl.
flits.
cs.vu.nl. 86400 IN MX 3 top.cs.vu.nl.
www. cs.vu.nl. 86400 IN CNAME Star.cs.vu.ni
ftp .cs.vu.nl. 86400 IN CNAME Zephyr.cs.vu.nl
Rowboat IN A 130.37.56.201
IN MX 1 rowboat
IN MX 2 zephyr
IN HINFO Sun Unix
little -sister IN A 130.37,62.23
IN HINFO Mac MacOS
Laserjet IN A 192.31.231.216
IN HINFO "HP Laserjet IIISi" Proprietary
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
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
255
198
0 255
70
0
255
148
0
10 255
mcp.com
34
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 Significado
0 Operación del primer bit:
0 Solicitud
1 Respuesta
Tipo de solicitud :
1 Estándar (nombre de dominio a dirección IP) (bit a 0)
2 Inversa (dirección IP a nombre de dominio) (bit a 0)
3 Obsoleto (bit en 0)
4 Obsoleto (bit en 0)
5 Activado si se tiene una respuesta autorizada
6 Activado si el mensaje está truncado
7 Activado si se desea recursión
8 Activado si la recursión está disponible
9 - 11 Reservado
Tipo de respuesta (cuando el bit esta a 1)
12 Sin error
35
13 Error de formato en la solicitud

14 Falla en el servidor
15 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 solicitud 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 clase 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

section, (sección de respuestas) authority section (sección de autoridad) y de la
36
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 resource 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
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
Sevidor DNS
DNS violado
Servidor Servidor
1 Web de 1 Web de
2 Xavier 2 Silvana
Giovanna Giovanna
3 3
4 4
(a) (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
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-la-
intrusa.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 incremen-
tado 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
empeorar las cosas, ésta no es la única forma de falsificar un DNS. Hay muchas
otras formas.
Sevidor 1. Busca foobar.silvana-la-intrusa.com

DNS (para obligarlo a entrar al caché del ISP
violado 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
7
IPS de (lleva el siguiente número de secuencia del ISP,n)
5 Giovanna Rápidamente busca xavier.com
4.
(para obligar a que el ISP consulte al servidor com en el
Silvana 1 paso 5)
5. Consulta legítima para xavier.com con seq=n+1
2 6. Respuesta falsificada de Silvana: Xavier es 42.9.9.9,
3 seq = n+1
4 7. Respuesta real (rechazada, demasiado tarde)
6
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
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

KEY. 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.
SIG 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 CD-
ROM) 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
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 Tiempo de Clase Tipo Valor

dominio vida
Xavier.com 86400 IN A 36.1.2.3
Xavier.com 86400 IN KEY 36827937B73F731029CE2737D
Xavier.com 86400 IN SIG 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 au-
tenticidad 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
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 razonable. 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 TIME-
TO-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
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
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

no
:-) Estoy feliz no
=|:-) Abe Lincoln no
:+) Nariz grande
:-( Estoy =):-) Tío Sam :-)) Realmente feliz
triste/enojado
:-| Estoy apático *<:-) Santa Claus :- {) Con bigote
-) Estoy <:-( Bobo #:-) Peinado yuppy
guiñando un
ojo
:-(0) Estoy (-: Zurdo 8-) Con gafas
gritando
:-(*) Estoy :-)X Hombre con C:-) Inteligente
vomitando moño
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
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
Agente de Servidor Buzón

transferencia del
de mensaje destinatario
Puerto Puerto 25
TCP TCP
IP IP
RED TCP/IP
46
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
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 teclado.
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
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 pajaros@observador.espoch.edu.ec 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° Bandera Bytes Remitente Asunto

1 K 1030 Andrea Cambios en la tesis
2 KA 6348 Luis No todas son molestas
3 KF 4519 Silvana Moreno Solicitud de información
4 1236 Baleri Bioinformática
5 104110 Paladines Juan Material sobre las redes inalámbricas
6 1223 Frank Re: Revisará una propuesta de otorgamiento
7 3110 Guido Nuestro documento ha sido aceptado
8 1204 Dr Rueda 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
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 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 Sender: 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
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.
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
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.
MIME-Version: Identifica la versión de MIME
Content-Description: Cadena de texto que describe el contenido
Content-ld: Identificador único
Content-Transfer-Encoding: Cómo se envuelve el mensaje para su transmisión
Content-Type: Naturaleza del mensaje
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 en Content-Type: video/mpeg.
Tipo Subtipo Descripción

Texto Plano Texto sin formato
Enriquecido Texto con comandos de formato sencillos
54
Imagen Gif Imagen fija en formato GIF

Jpeg Imagen fija en formato JPEG
Audio Básico Sonido
Vídeo Mpeg Película en formato MPEG
Aplicación Octet-stream Secuencia de bytes no interpretada
Postscript Documento imprimible en PostScript
Mensaje Rfc822 Mensaje MIME RFC 822
Parcial Mensaje dividido para su transmisión
Externo El mensaje mismo debe obtenerse de la red
Multipartes Mezclado Partes independientes en el orden especificado
Alternativa Mismo mensaje en diferentes formatos
Paralelo Las partes deben verse en forma simultánea
Compendio 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 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 <bold> momento </bold>, dijo la <italic> morsa </italic>...

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 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 algo de texto, este programa puede leer, modificar o 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 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
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 pre-
MIME 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; giovanna@abcd.com
To: elena@xyz.com
MIME-Version: 1.0
Message-Id: <0704760941 .M00747@abcd.com>
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, querida <bold> Elena </bold>
--qwertyuiopasdfghjklzxcvbnm
Content-Type: message/external-body;
access-type="anon-ftp";
site="bicycle.abcd.com";
57
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
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 Formato de la orden Descripción

HELO HELO <SP> (dominio) <CRLF> Envía identificación
MAIL MAIL <SP> FROM: <camino inverso) <CRLF> Identifica al que origina el correo
RCPT RCPT <SP> T0: <camino destino) <CRLF> Identifica al destino del correo
DATA DATA<CRLF> Transfiere un texto de mensaje
RSET RSET <CRLF> Aborta la transacción del correo actual
NOOP NOOP <CRLF> No operación
QUIT QUIT <CRLF> Cierra la conexión TCP
SEND SEND <SP> FROM: (camino inverso) <CRLF> Envía correo al terminal
SOML dIVId t/ü)
SOML <SP> FROM: (camino inverso) <CRLF> Envía r©üalditerminal
correo Lüirnilícil
si es posible; de
otro modo a! buzón ^^^^
d'i:a::..."?^^^^;^;:i:::::^
SAML SAML <SP> FROM: <camino inverso) <CRLF> Envía correo al terminal y al buzón
VRFY VRFY <SP> <cadena> <CRLF> Confirma el nombre del usuario
EXPN EXPN <SP> (cadena) <CRLF> Devuelve el número de miembros de la
lista de correo
HELP HELP [<SP> <cadena>] <CRLF> Envía documentación específica del
sistema
TURN TURN <CRLF> Intercambia el rol del emisor y el
receptor
<CRLF) = retorno de carro, fin de línea
<SP> = 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
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 Descripción
Respuesta de finalización positiva
211 Estado del sistema o respuesta de ayuda del sistema.
214 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)
220 <dominio> Servicio preparado
221 <dominio> Servicio cerrando el canal de transmisión
250 Acción de correo solicitada correcta, completada
251 Usuario no local; reenviar a <camino-destino>
Respuesta intermedia positiva
354 Comenzar la entrada de correo; acabar con <CRLF>.<CRLF>
Respuesta de finalización negativa transitoria
421 <dominio> Servicio no disponible; perdido canal de transmisión. (Ésta podría ser
la respuesta a cualquier orden si el servicio conoce que debe desconectarse)
450 Acción de correo solicitada no ejecutada; buzón de correo no disponible (p. ej.
Buzón ocupado)
451 Cancelada acción solicitada; error local en el procesamiento
452 Acción solicitada no ejecutada; almacenamiento del sistema insuficiente
Respuesta de finalización negativa permanente

500 Error de sintaxis; orden no reconocida (esto puede incluir errores como línea de
orden demasiado larga)
501 Error de sintaxis en los parámetros o los argumentos
502 Orden no implementada
503 Secuencia de órdenes incorrecta
504 Parámetro de orden no implementado
550 Acción solicitada no ejecutada; buzón de correo no disponible (p. ej. buzón no
encontrado, no se accedió)
551 Usuario no local, por favor, intente <camino-destino>
552 Acción de correo solicitada cancelada; excedida la asignación de espacio de
almacenamiento
553 Acción solicitada no ejecutada; nombre del buzón de correos no permitido (p. ej.
Sintaxis de correo incorrecta)
554 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
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
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:<giovanna@abcd.com>
S: 250 emisor ok
C: RCPT T0:<elena@xyz.com>
S: 250 receptor ok
C: DATA
S: 354 envía correo; termina con una línea únicamente con "."
C: From; giovanna@abcd.com
C: To: elena@xyz.com
C: MIME-Version: 1.0
C: Message-Id: <0704760941.AA00747@abcd.com>
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
C: Feliz cumpleaños, mami <bold> Elena </bold>
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 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 COMPUTADOR

TRANSMISOR DEL USUARIO
buzón del
destinatario
Agente de usuario Servidor
de correo Servidor
Agente de cliente
POP
transferencia POP
25 110
de mensaje
Puerto Puerto
TCP
TCP TCP
IP
IP IP
RED TCP/IP
64
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
giovanna@xyz.com 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
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 POP3 IMAP

En dónde se define el protocolo RFC1939 RFC 2060
Puerto TCP utilizado 110 143
En dónde se almacena el correo PC del usuario Servidor
electrónico
En dónde se lee el correo electrónico Sin conexión En línea
Tiempo de conexión requerido Poco Mucho
Uso de recursos del servidor Mínimo Amplio
Múltiples buzones No Sí
Quién respalda los buzones Usuario ISP
Bueno para los usuarios móviles No .. Si
Control del usuario sobre la descarga Poco Mucho
Descargas parciales de mensajes No Sí
¿Es un problema el espacio en disco? No Con el tiempo podría serlo
Sencillo de implementar Sí No
Soporte amplio Sí 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
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
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
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 cert@cert.org 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
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
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 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
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
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 SERVIDOR
CLIENTE
www.espoch.edu.ec www.conesup.net
Página desplegada
en el navegador hipervínculo
Giovanna Hola
Silvana ESPOCH
Xavier
hipervínculo Maria
Giovanna
Silvana Programa Programa
Xavier
Maria servidor servidor
Programa Disco web Disco
web
navegador
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
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. El navegador determina el URL (enviando lo que se seleccionó).

2. El navegador pide al DNS la dirección IP de www.espoch.edu.ec
3. DNS responde con 201.218.5.2.
4. El navegador realiza una conexión TCP con el puerto 80 en 201.218.5.2.
5. Después envía un mensaje en el que solicita el archivo /sistemas .html.
6. El servidor www.espoch.edu.ec envía el archivo /sistemas.html.
7. Se libera la conexión TCP.
8. El navegador despliega todo el texto de /sistemas.html.
9. 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
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
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
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. Acepta una conexión TCP de un cliente (un navegador).

2. Obtiene el nombre del archivo solicitado.
3. Obtiene el archivo (del disco).
4. Regresa el archivo al cliente.
5. 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
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
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 Respuesta
entrante 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
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 Canal con

(máquina independiente) 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
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 Nodo de
aprendizaje procesamiento
3
2 3 2 Al
cliente
Front end Front end
1 4 1
Desde el Al Desde el
cliente cliente 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
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 Ejemplo

Http Hipertexto (HTML) http://www.cs.vu.nl/~ast/
Ftp FTP 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 news:AA0134223112@cs.utah.edu
Gopher Gopher . gopher://gopher.tc.umn.edu/11/Libraries
Mailto Envío de correo electrónico mailto:JohnUser@acm.org
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 Web 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
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
(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.
Cabecera de solicitud : contiene información sobre la solicitud y el cliente.
Cabecera de respuesta : 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.
Cuerpo entidad : el cuerpo del mensaje.
86
TODOS LOS MENSAJES

Campos de la cabecera general Campos de la cabecera de entidad
Cache-Control Keep-Alive Allow Derived-From
Connection MIME-Version Content-Encoding Expires
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 Accept 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-Agent
COPY extension-method Host
MENSAJES DE RESPUESTA
Códigos de estado de respuesta Campos de la
cabecera de
Continue Moved Temporarily Request Timeout Location
respuesta
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
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 fichero.
 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
 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 Cabecera-
URL 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
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 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 keep-
alive en un campo Conexión entrante, y proporciona información al solicitante 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, dela 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
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
2xx Éxito 200 = la solicitud es exitosa; 204 = no hay contenido
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
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 Recibida la parte inicial de la solicitud; el cliente puede continuar

con la solicitud.
Switching Protocol El servidor conmutará a los nuevos protocolos de aplicación
solicitados.
De éxito
93
OK La solicitud ha tenido éxito y la información de respuesta

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

no se puede determinar la localización preferida.
MovesPermariently Al recurso solicitado le ha sido asignado un URL permanente
nuevo; las referencias futuras se deben hacer a este URL.
Moved Temporarily El recurso solicitado reside temporalmente en un URL diferente.
See Other La respuesta a la solicitud se puede encontrar en un URL
diferente y se debería obtener utilizando un GET en ese
recurso.
Not Modified 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.
Use Proxy El recurso solicitado se debe acceder a través de un
representante indicado en el campo Location.
Error de Cliente
Bad Request Sintaxis incorrecta en la solicitud.
Unauthorized La solicitud requiere autorización al usuario.
Payment Required Reservado para usos futuros.
Forbidden 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
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
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
• 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
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 com-
paració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
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 distribuidas 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
Un sistema de gestión de red posee los siguientes elementos clave:
• La estación de gestió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 de 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 las 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 Incluye información sobre

system Sistema operativo del anfitrión o del ruteador
Interfaces Interfaz de red individual
Addr. trans Dirección de traducción (por ejemplo, transformación ARP)
ip Software de protocolo de Internet
icmp Software de protocolo de mensajes de control de Internet
tcp Software de protocolo de transmisión de Internet
udp Software de protocolo de datagrama de usuario
egp 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 Categoría Significado

SysUpTime sistema Tiempo desde el último arranque
IfNumber interfaz Número de interfaces de red
IfMTU interfaz MTU para una interfaz en particular
IpDefaultTTL ip Valor ip utilizado en el campo de tiempo límite
IpINReceives ip Número de datagramas recibidos
IpForwDatagrams ip Número de fallas de ruteo
IpReasmOKs ip Número de datagramas reensamblados
IpFragOKs ip Número de datagramas fragmentados
IpRoutingTable ip Tabla de rueto IP
IcmpInEchos icmp Número de solicitudes de Eco ICMP recibidas
TcpRtoMin tcp Tiempo de retransmisión mínimo TCP permitido
TcpMaxConn tcp Conexión TCP máxima permitida
TcpInSegs tcp Número de segmentos que TCP a recibido
UdpInDatagrams udp Número de datagramas UDP recibidos
EgpInMsgs egp 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
subgrupo internet mgmt con el nombre mib del espacio de nombre identificador de
objetos.
Sin
nombre
iso itu Unión

1 2 iso-itu
3
org
3
dod
6
internet
1
direc- experi-
mgmt privada
torio mental
2 4
1 3
mib
1
sistema Inter- trans. ip icmp tcp udp egp

1 faces direcc. 4 5 6 7 8
2 3
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 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 gestió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 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
Gestor/agente
SNMPv2
SNMPv2
MIB MIB
Agente Agente Agente

Agente SNMPv2 Agente SNMPv2 Agente SNMPv2
MIB 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 solicitud-
respuesta 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
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 Descripción

31
INTEGER Enteros en el rango de -2 a 231 - 1.
UInteger32 Enteros en el rango de 0 a 232 - 1.
Counter32 Un entero no negativo que se puede incrementar módulo 2 32.
Counter64 Un entero no negativo que se puede incrementar módulo 2 64.
Gauge32 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 232 - 1.
TimeTicks 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 Una dirección Internet de 32 bits.
Opaque Un campo de bits arbitrario.
BIT STRING Una enumeración de bits con nombre.
OBJECT Nombre asignado administrativamente a objetos u otros
IDENTIFIER elementos normalizados. El valor es una secuencia de hasta
128 enteros no negativos.
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
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 0 0 Variable colección

Solicitud
a) PDU Get Request, PDU GetNextRequest, PDU SetRequest, PDU SNMPv2-Trap,
PDU InformRequest
Tipo PDU Identificativo Categoría de Indice de Variable colección

Solicitud error error
b) PDU Response
Tipo PDU Identificativo No repetidor Repetición Variable colección

Solicitud máxima
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
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
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
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ólo-
lectura 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
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
Gateway
Filtro
Filtro
del
firewall Internet
LAN interna
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
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
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
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
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 CD-
ROM, 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
• 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
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
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
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
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 LAN
avanzada
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
122
123
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.
Enrutador de
Sólo tráfico filtrado de
Otro tráfico SMTP paquetes
Internet
Sólo tráfico
Telnet
Figura 8.3 Filtrado de paquetes en Telnet y SMTP
Protocolo Dirección Dirección Puerto Puerto Acción

Origen Destino Origen Destino
TCP * 123.4.5.6 >1023 23 Permitir
TCP * 123.4.5.7 >1023 25 Permitir
TCP * 123.4.5.8 >1023 25 Permitir
TCP 129.6.48.254 123.4.5.9 >1023 119 Permitir
UDP * 123.4.*.* >1023 123 Permitir
* * * * * Denegar
Figura 8.4 Conjunto de reglas de filtrado
124
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
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 entra. 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
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 los 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
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
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.
A CONFIDENCIALIDAD INTE
GR
RI IDA
ITO D
UD SEGURIDAD
IA
A
NC
DIS
PO
INFORMATICA
TE
NIB
IS
ILI
NS
DA
D
CO
CONTROL
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 SOFTWARE
DATOS ACTIVOS GENTE
DOCUMENTACION 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 redactados 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 DESCRIPCION
considerar
Incendio 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.
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)
Humo 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.
Polvo 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.
Terremotos 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.
Temperatura Las computadoras funcionan dentro de márgenes de temperaturas
que son consideradas por los fabricantes como las adecuadas para
evitar daños
Explosiones Pueden ser causadas por el mal uso de sustancias químicas
inflamables almacenadas en el edificio
Bichos Estos animales a veces se introducen en las computadoras
provocando daños en sus componentes
Rayos Estas descargas eléctricas de la naturaleza provocan altas
variaciones de voltaje que dañan los equipos incluso cuando están
protegidos
Humedad 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
considerar
Trastornos La operación del teclado constituye un movimiento repetitivo y
óseos y o continuo que puede provocar lesiones en los músculos, nervios y
musculares huesos de manos y brazos
Trastornos La pantalla constituye una fuente de luz que incide directamente
visuales sobre los ojos del operador. Esto provoca en exposiciones
prolongadas cansancio visual, irritación, lagrimeo, visión borrosa y
cefalea
Salud mental 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.
Ambiente La iluminación deficiente causa dolores de cabeza y pérdida de la
luminoso visión, además de una baja en la productividad
Ambiente El ambiente donde el ser humano trabaja debe ser el adecuado
climático 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.
considerar
Personas 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.
Vehículos Se debe realizar el control del ingreso y egreso de vehículos e
identificación de sus ocupantes.
Sistemas Mediante esta tecnología se realizan mediciones en forma
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
firmas individuo, pues contiene información de la manera en que la
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
Barreras Son codificadas por medio de pulsos con el fin de evitar intentos
infrarrojas 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
Detector Crea un campo de ondas; ante cualquier movimiento que realiza
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 DIGITOS Y SIMBOLOS

Y DE PUNTUACION +LETRAS
MINUSCULAS
Contiene
Incluye
Contiene
CONTRASEÑAS CARACTERES DE CONTROL
SIETE U OCHO Y/O ESPACIOS
BUENAS
CARACTERES Mínimo
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
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
ALGORITMOS DE ENCRIPTADO
CLAVE PRIVADA CLAVE PUBLICA
DES IDEA CAST 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 256 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
 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 (p-
1)(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
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 DESCRIPCION
Errores de usuario 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
de sistemas respecto al servicio que se esta proporcionando a los
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
Vandalismo Los intrusos que con malicia alteran o borran datos. El
robo del equipo y perdida consigo de la información
Desastres Pérdidas causadas por desastres naturales como lluvia,
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
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 EJECUTAN SOLO UNA

PREDETERMINADAS ABIERTAS GRUPO
CONTRASEÑA INSTRUCCION
Cualquiera que Tienen generalmente Son cuentas creadas Son cuentas creadas Es usada por más de
conozca el nombre de contraseñas estándar. por el administrador para los visitantes una persona permiten a
la cuenta puede Como las cuentas que que pueden ejecutar ejemplo guest , un grupo de personas
ingresar vienen con el sistema, simplemente una sola suministrarlas en el trabajar en un mismo
aplicaciones que instrucción o programa sistema es muy mala proyecto sin tener que
instalan cuentas para de aplicación ( ejemplo idea . crear una cuenta para
demostración de los finger, date) cuando un Los nombres y cada persona. Los
programas. usuario entra en ellas. contraseñas de este usuarios muchas veces
A menudo estas tipo de cuentas son prestan estas cuentas
cuentas no tienen fáciles de adivinar y más facilidad que las
contraseña representan un cuentas personales.
problema para la
seguridad.
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
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
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
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
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
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 e-
mails 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 denominado ―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
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 Sistema Página web

Operativo
Wget UNIX http://www.gnu.org/software/wget/wget.html
Teleport Pro Windows 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
 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úblico-

privada 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 Dirección de Internet

Visual Route http://www.visualroute.com
Neo Trace http://www.neotrace.com/
Figura 9.13 Identificación de la topología
4) Determinación de la actividad de un sistema
Para verificar que un sistema esta activo se realiza un barrido ping 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 Sistema Dirección de Forma de usar

Operativo Internet
Fping UNIX http://www.fping.com $ fping –f dirección de dominio
Nmap UNIX www.insecure.org/n $ nmap –sp IP/n

map
ej: n=16
Pinger Windows http://www.kilievich.c Herramienta gráfica
om
WS_Ping Windows www.ipswitch.com Herramienta gráfica, para

ProPack redes pequeñas
NetScan Windows www.nwpsw.com Herramienta gráfica, para
redes pequeñas
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 a una subred específica, se puede utilizar las
herramientas Unix:
Icmpquery(http://www.pestpatrol.com/PestInfo/i/icmpquery_c.asp) o
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, monitor de red y herramientas para descubrimiento de 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 Características

para
Windows
SuperScan http://www.foundstone.co Permite especificar las direcciones IP y
m/rdlabs/termsofuse.php? listas de puerto del sistema destino
filename=superscan.exe
WinScan http://www.prosolve.com Tiene una versión gráfica y también de
línea de comandos.
IpEye 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.
WUPS http://ntsecurity.nu Es un analizador de puertos UDP gráfico y
relativamente rápido.
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 CARACTERÍSTICAS
SONDEO
Sondeo FIN 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
Sondeo Bogus Se coloca una bandera indefinida en la cabecera TCP de un
Flag paquete SYN. Algunos Sistemas Operativos como linux
responden con esta bandera en su paquete de respuesta
Tamaño de En algunos desarrollos de pilas el tamaño de la ventana inicial
ventana inicial es único
TCP
Valor ACK 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 + 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 operativos activa el bit de no fragmentar para
148
de no fragmentar mejorar su rendimiento

Cita de mensajes Entre los sistemas operativos difieren en la cantidad de
ICMP 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
7) Enumeración de cuentas de usuario, recursos compartidos
Los atacantes lo siguiente que hacen es tratar de identificar cuentas de usuario

válidas o recursos compartidos mal protegidos. Conocido por un atacante una
cuenta, un recurso compartido o un nombre de usuario de un sistema, solo será
cuestión de tiempo para que llegue a adivinar la contraseña correspondiente o que
identifique algún punto débil asociado al protocolo de compartición de recursos. Aquí
son usadas herramientas como el superScan , Brutus, cracklib.
9.11 EJERCICIOS
1. Utilizando el criptosistema de clave pública RSA, con a=1, b=2. Si p=7 y q=11,
liste cinco valores legales para d. Si p=13, q=31 y d=7 encuentre e.
2. Busque en Internet un caso interesante que involucre la privacidad y escriba un
informe de una página sobre él.
3. Investigue sobre las seguridades físicas y lógicas implantadas en su Institución.
4. ¿Cuáles han sido los ataques que ha sufrido su Institución?
5. ¿Qué tan seguras son las Aplicaciones desarrolladas en su Institución y que
están en la Web?
6. ¿Existen fallas de seguridad en el DNS de su Institución y que se debería hacer
para corregirlos?
7. Copie el sitio Web de su Institución utilizando el Teleport Pro.
8. Identifique los equipos existente en su Institución empleando el solar winds.
150

Protocolos y Redes. Ing. Patricio Moreno

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Protocolos y Redes. Ing. Patricio Moreno

Caricato da

Copyright:

Formati disponibili

Ing. M.Sc. Patricio Moreno C.

Integración de Sistemas ESPOCH-FIE-EIS

1.1 CONFIGURACION DEL ANFITRION

El protocolo DHCP (Dynamic Host Configuration Protocol) permite a un anfitrión

Al realizar un análisis del protocolo RARP se determina que existen tres

2. Al utilizar RARP se necesita hacer un proceso de solicitud, para en la respuesta

3. Como RARP emplea una dirección de hardware de computadora para identificar

Para eludir algunas de las dificultades presentadas por RARP, se desarrollo

La asignación de direcciones de manera automática, fue solucionado por el IETF

DHCP permite tres tipos de asignación de direcciones; un administrador selecciona

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 asignación de direcciones estática, es permanentemente para cada dirección IP a

El tiempo óptimo de arrendamiento depende en particular de la red y de las

utilizar un período de arrendamiento de un día o de una semana. Para adaptarse a

1.3 PROCESO DE ADQUISICION DE DIRECCIONES

Arranque del anfitrión

Figura 1.1 Estados de un cliente DHCP y las transiciones entre estados.

Mientras permanece en el estado SELECT, el cliente reúne respuestas

1.4 TERMINACION DEL ARRENDAMIENTO

El estado BOUND es el estado normal de operación; un cliente por lo general se

Para terminar un arrendamiento de manera temprana, el cliente envía un mensaje

1.5 ESTADO DE RENOVACION DE ARRENDAMIENTO

Se ha indicado que cuando se adquiere una dirección, un cliente DHCP cambia al

Luego de enviar un mensaje DHCPREQUEST en el que solicite una extensión de su

Luego de cambiar al estado REBIND, el cliente tendrá que interrogar al servidor

1.6 FORMATO DE LOS MENSAJES DHCP

Figura 1.2 Formato del mensaje DHCP

Nombre del Si el cliente conoce el nombre de dominio del servidor lo ubica

1. Si las computadoras de su Institución utiliza la red para arrancar. ¿Qué

2.1 PROTOCOLO TELNET

Los protocolos TCP/IP incluyen un protocolo de terminal remota sencillo, llamado

Aunque TELNET no es sofisticado en comparación con algunos protocolos de

TELNET ofrece tres servicios básicos:

2. Incluye un mecanismo que permite al cliente y al servidor negociar opciones,

3. TELNET trata con ambos extremos de la conexión de manera simétrica. En

La figura 2.1, ilustra la forma en que los programas de aplicación implantan un

manera concurrente que el servidor regresa y despliega en la pantalla del usuario. El

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

Es imposible construir un servidor TELNET a menos que el sistema operativo

terminal. Finalmente, el sistema operativo remoto entrega el carácter al programa

Formato del sistema Formato NVT

Figura 2.2 Utilización del formato NVT

Para adaptar la heterogeneidad, TELNET define cómo deben mandarse las

Código de Valor Significado asignado

Figura 2.3 Tablas de los códigos de control ASCII y alguna de las

Además de la interpretación de caracteres de control. NVT define la terminación de

2.3 COMANDOS QUE CONTROLAN EL EXTREMO REMOTO

NVT de TELNET adapta las funciones de control mediante la definición de cómo se

IP (Interrupt Process) Interrupción del proceso (termina de correrse el programa)

Figura 2.4 Funciones de control que NVT de TELNET reconoce

COMANDO CODIFICACION SIGNIFICADO

duplica y manda una secuencia de dos octetos IAC-IAC)

Figura 2.5 Comandos de TELNET y codificación para cada uno

2.4 FORZAR AL SERVIDOR A LEER UNA FUNCIÓN DE CONTROL

convencional por sí sola para transportar secuencias de control entre cliente y

2.5 OPCIONES DE TELNET

En TELNET, las opciones son negociables, lo que hace posible reconfigurar su

El rango de opciones de TELNET es amplio: algunos extienden las capacidades de

NOMBRE CODIGO SIGNIFICADO

extremos de una conexión

Tipo de terminal 24 Intercambio de información sobre la elaboración y