ADMINISTRACIÓN DE REDES

LIC. JOSÉ LUIS ORTEGÓN DELGADO

INFORME DE INVESTIGACIÓN
UNIDAD 2: SERVICIOS DE RED

Ángel Alberto García Guerrero

ISMA-7
 UNIDAD 2 SERVICIOS DE RED

DHCP
El servicio DHCP (Dynamic Host Configuration Protocol) es el protocolo de configuración
dinámica de host, un estándar TCP/IP diseñado para simplificar la administración de la
configuración IP de los equipos de nuestra red. El estándar DHCP permite el uso de
servidores DHCP para administrar la asignación dinámica a los clientes DHCP de la red, de
direcciones IP y de otros detalles de configuración relacionados con el direccionamiento IP,
tales como la puerta de enlace o los servidores DNS, por ejemplo, siempre que los clientes
estén configurados para utilizar un servidor DHCP, en lugar de estar configurados
manualmente con una dirección IP estática.
Cada equipo de una red TCP/IP debe tener un nombre y una dirección IP únicos. La
dirección IP, junto con su máscara de subred relacionada, identifica al equipo host y a la
subred a la que está conectado, de modo que al mover un equipo a una subred diferente, se
debe cambiar la dirección IP asignada a dicho equipo; DHCP permite asignar
dinámicamente una dirección IP a un cliente, a partir de una base de datos de direcciones IP
de servidor DHCP de la red local, reduciendo la complejidad y cantidad de trabajo que debe
realizar el administrador para reconfigurar los equipos.
DHCP es el protocolo de servicio TCP/IP que alquila o asigna dinámicamente direcciones
IP durante un tiempo, conocido como duración del alquiler, a las estaciones de trabajo,
distribuyendo además otros parámetros de configuración entre clientes de red autorizados,
tales como la puerta de enlace o el servidor DNS. El servicio DHCP proporciona una
configuración de red TCP/IP segura, confiable y sencilla, evitando conflictos de direcciones
y ayudando a conservar el uso de las direcciones IP de clientes en la red, para lo cual utiliza
un modelo cliente-servidor en el que el servidor DHCP mantiene una administración
centralizada de las direcciones IP utilizadas en la red.
Las estaciones de trabajo solicitan al servidor DHCP su dirección IP y demás
configuraciones para este protocolo, el cual les va asignando direcciones del rango que
sirve, de entre aquellas que le quedan libres; si deseamos que a determinados equipos el
servidor les sirva siempre la misma dirección IP, podemos llegar a forzar la asignación de
la dirección IP deseada a equipos concretos a través de la dirección MAC de su tarjeta de
red. Además, también pueden excluirse del rango de direcciones IP que va a servir nuestro
servidor, aquellas que deseamos que estén asociadas de forma estática a determinados
equipos o periféricos de red.
¿Cómo funciona el DHCP?
El servidor DHCP es el que distribuye las direcciones IP. Este equipo será la base para
todas las solicitudes DHCP por lo cual debe tener una dirección IP estática.
Cuando un equipo cliente se inicia no tiene información sobre su configuración de red y
desea obtenerla. Para esto, la técnica que se usa es la transmisión: para encontrar y
comunicarse con un servidor DHCP, el equipo enviará un paquete de broadcast
(255.255.255.255 con información adicional como el tipo de solicitud, los puertos de
conexión, etc.) a través de la red local. Cuando el servidor DHCP recibe el paquete de
transmisión, contestará con otro paquete de transmisión que contiene toda la información
solicitada por el cliente.
Existen varios tipos de paquetes DHCP que pueden emitirse tanto desde el cliente hacia el
servidor o servidores, como desde los servidores hacia un cliente:

 DHCPDISCOVER: Paquete broadcast para ubicar servidores DHCP disponibles.

 DHCPOFFER: Paquete broadcast de respuesta del servidor a un paquete.
 DHCPDISCOVER: informando que hay presencia de un servidor DHCP
disponible.
 DHCPREQUEST: Paquete unicast de solicitudes varias del cliente al servidor
DHCP disponible.
 DHCPACK: Paquete de respuesta del servidor que contiene los parámetros
solicitados por el cliente.
 DHCPNAK: Paquete de respuesta del servidor para indicarle al cliente que su
concesión ha vencido o en caso de que el cliente anuncie configuración de red
errónea.
 DHCPDECLINE: Paquete del cliente informando al servidor que la dirección ya
está en uso.
 DHCPRELEASE: Paquete del cliente liberando su dirección IP.
 DHCPINFORM: Paquete del cliente solicitando parámetros locales, ya tiene su
dirección IP.
Cuando el equipo cliente es configurado para obtener su dirección IP mediante DHCP, este
envía un primer paquete tipo DHCPDISCOVER en busca de un servidor disponible en la
red siendo este paquete un Broadcast.
El servidor responde con un paquete DHCPOFFER, informando al cliente que si le puede
brindar el servicio DHCP.

El cliente envía paquete DHCPREQUEST tipo unicast para validar su dirección IP,
confirmando que usara el servicio que el Servidor le ha ofrecido.

El servidor responde con un DHCPACK con la dirección IP para confirmar la asignación y

el cliente queda con la configuración IP dinámica.

Si por error algún equipo de la red estuviera configurado con un direccionamiento IP

estático del rango gestionado por nuestro servidor DHCP, podría ocurrir que cuando
nuestro servidor DHCP alquilase una dirección IP a la estación de trabajo solicitante, dicha
dirección IP fuera la que estuviera siendo utilizada por el equipo con direccionamiento
estático, provocándose un conflicto de direccionamiento IP; en ese caso el cliente DHCP
solicitará otra dirección IP y la probará, hasta que obtenga una dirección IP que no esté
asignada actualmente a ningún otro equipo de la red; por cada conflicto de direcciones IP,
el cliente volverá a intentar configurarse automáticamente hasta con 10 direcciones IP.

DNS
El Sistema de Nombres de Dominio o DNS es un sistema de nomenclatura jerárquico que
se ocupa de la administración del espacio de nombres de dominio (Domain Name Space).
Su labor primordial consiste en resolver las peticiones de asignación de nombres. Esta
función se podría explicar mediante una comparación con un servicio telefónico de
información que dispone de datos de contacto actuales y los facilita cuando alguien los
solicita. Para ello, el sistema de nombres de dominio recurre a una red global de servidores
DNS, que subdividen el espacio de nombres en zonas administradas de forma
independiente las unas de las otras. Esto permite la gestión descentralizada de la
información de los dominios.
Cada vez que un usuario registra un dominio, se crea una entrada WHOIS en el registro
correspondiente y esta queda almacenada en el DNS como un “resource record”. La base de
datos de un servidor DNS se convierte, así, en la compilación de todos los registros de la
zona del espacio de nombres de dominio que gestiona.
La creación del sistema de nombres de dominio en 1983 sustituyó al procedimiento anterior
de resolución, muy propenso a errores y basado en un archivo local de hosts. Este archivo
hosts.txt puede encontrarse aún hoy en sistemas basados en UNIX en el directorio etc/ y, en
computadores Windows, en %SystemRoot%\system32\drivers\etc.
El archivo hosts.txt requería el mantenimiento manual y una actualización regular, un
esfuerzo que, a medida que Internet iba creciendo de forma exponencial, ya no era posible
realizar. Hoy, este archivo se usa exclusivamente para la clasificación de direcciones IP en
redes locales. También permite bloquear servidores web desviando automáticamente su
dirección hacia el alojamiento local (local host).
Peticiones al DNS
Cuando se introduce la dirección de una página web (URL) en el campo de búsqueda del
navegador, este realiza una petición al llamado resolver, un componente especial del
sistema operativo cuya función consiste en almacenar en caché direcciones IP ya solicitadas
anteriormente, y proporcionarlas cuando la aplicación cliente (navegador, programa de
correo) la solicita. Si la dirección IP solicitada no se encuentra en el caché del resolver, este
redirige la petición al servidor DNS que corresponda, que, en general, se trata del servidor
DNS del proveedor de Internet. Aquí se coteja la petición con la base de datos del DNS y,
si está disponible, se envía la dirección IP correspondiente como respuesta (“forward
lookup”). Esta permite al navegador del usuario dirigirse al servidor web deseado en
Internet. Otra vía alternativa consiste en el camino inverso, es decir, en traducir la dirección
IP en la dirección de dominio (“reverse lookup”).
Si un servidor DNS no puede responder a una petición con la información de que dispone
en su base de datos, puede solicitar la información a otro servidor o reenviar la petición al
servidor DNS que corresponda. Esta resolución se puede realizar de dos formas:
 Resolución recursiva: es la que se produce cuando el servidor DNS no puede
responder por sí mismo a una petición y toma la información de otro servidor. El
resolver transfiere la petición completa a su servidor DNS, que proporciona a su vez
la respuesta al resolver con el nombre de dominio, si se ha resuelto.

 Resolución iterativa: cuando el servidor DNS no puede resolver la petición, envía

como respuesta la dirección del siguiente servidor DNS de la jerarquía. El resolver
tiene que enviar él mismo una nueva petición y repetir la maniobra hasta que se
resuelve el nombre de dominio.
La administración centralizada de la información de los dominios en el DNS se caracteriza
por un índice elevado de fiabilidad y flexibilidad. Si la dirección IP de un servidor cambia,
el usuario no suele percibir nada, ya que la dirección IP actual para el dominio
correspondiente se guarda en la base de datos.

¿Qué es un servidor DNS?

Un servidor DNS, también conocido como servidor de nombres, consiste en un software
para servidores que recurre a la base de datos de un DNS para responder a las peticiones
que guardan relación con el espacio de nombres de dominio. Como, por regla general, se
alojan en hosts dedicados, también se denominan así a los ordenadores que albergan estos
programas. Suele hacerse una diferenciación entre servidores DNS primarios y secundarios:
 Servidor primario, principal o maestro: se denomina a un servidor DNS primario
o maestro cuando guarda la información sobre una zona determinada del espacio de
nombres de dominio en su propia base de datos. El sistema de nombres de dominio
está construido de tal forma que cada zona disponga de, al menos, un servidor de
nombres primario. Un sistema de este tipo suele ser implementado como clúster de
servidores donde se almacenan los datos de zona idénticos en un sistema maestro y
en varios esclavos, aumentando, gracias a esta redundancia, la seguridad ante caídas
y la disponibilidad de un servidor maestro. De aquí procede la denominación de
servidores primarios y secundarios que se ha usado.

 Servidor secundario o esclavo: cuando la información de un servidor de nombres

no procede de los archivos de zona propios, sino que son de segunda o de tercera
mano, este servidor se convierte en secundario o esclavo para esta información. Esta
situación se produce cuando un servidor no puede resolver una petición con su
propia base de datos y ha de recurrir a la información disponible en otro servidor de
nombres (resolución recursiva). Estos datos del DNS se guardan de forma temporal
en un almacenamiento local (caching) y se proporcionan en caso de peticiones
 futuras. Como es posible que las entradas en el propio archivo de zona hayan
cambiado en el ínterin, la información proporcionada por servidores secundarios no
se considera segura.
Notificación de errores del DNS
A veces se recibe la notificación de error “El servidor DNS no responde” cuando hay
problemas de conexión. Esto sucede cuando la conexión con Internet no funciona y no es
posible acceder a una página web. En este artículo te ayudamos a determinar las posibles
causas de este molesto problema y proponemos posibles formas de solucionarlos.
Como se cambian las DNS
Como registrador de dominios que somos proporcionamos un panel de control que permite
realizar estos cambios de forma online. En nuestro caso, es importante tener claro, que, para
cambiar las DNS de un dominio individual, es necesario acudir a la sección “Dominios” y
configurar las DNS del dominio individualmente, bien escribiendo las nuevas que
queremos asignar o bien eligiendo entre las que tenemos grabadas en nuestra Área de
Clientes.
Hay que tener cuidado con la gestión de DNS, pues como ya hemos explicado, de ellas
depende que funcione nuestro dominio, o lo que es lo mismo, nuestra web, nuestro correo o
nuestras aplicaciones y bases de datos.
SSH
SSH es el acrónimo de Secure Shell, y es un protocolo que se utiliza en el manejo de
servidores de forma remota, permitiendo a un usuario realizar toda clase de tareas sobre el
mismo.
En las conexiones realizadas por medio de SSH, toda la información viaja de forma
encriptada, lo cual lo convierte en uno de los medios más seguros a la hora de trabajar en
un servidor.
Sus orígenes se remontan al año 1995, cuando su primera versión (lo que hoy llamamos
SSH-1) fue desarrollada por Tatu Ylönen en la Universidad de Helsinki, Finlandia. El
objetivo inicial de SSH era convertirse en un reemplazo seguro y efectivo de otros
protocolos que estaban de moda en la época, pero que no eran realmente seguros, como por
ejemplo Telnet.
SSH o Secure Shell, es un protocolo de administración remota que le permite a los usuarios
controlar y modificar sus servidores remotos a través de Internet. El servicio se creó como
un reemplazo seguro para el Telnet sin cifrar y utiliza técnicas criptográficas para
garantizar que todas las comunicaciones hacia y desde el servidor remoto sucedan de
manera encriptada. Proporciona un mecanismo para autenticar un usuario remoto, transferir
entradas desde el cliente al host y retransmitir la salida de vuelta al cliente.
¿Cómo funciona?
Establecer una conexión SSH es sencillo, la única herramienta que vamos a necesitar para
hacerlo es una del tipo terminal o consola, como por ejemplo la clásica consola de Linux y
Mac, o un programa como PuTTY en el caso de Windows.
La conexión SSH usa tres ítems: un usuario, un puerto y un servidor. Con solo esos tres
elementos podemos establecer una conexión segura entre dos servidores.
Esta seguridad se logra mediante el uso de llaves y técnicas de cifrado. Cada server tiene su
propia llave de cifrado, y al establecer una conexión por primera vez con un server
tendremos que añadir el servidor en cuestión a una lista de servidores a los cuales es seguro
conectarnos.
Las diferentes técnicas de cifrado
La ventaja significativa ofrecida por SSH sobre sus predecesores es el uso del cifrado para
asegurar la transferencia segura de información entre el host y el cliente. Host se refiere al
servidor remoto al que estás intentando acceder, mientras que el cliente es el equipo que
estás utilizando para acceder al host. Hay tres tecnologías de cifrado diferentes utilizadas
por SSH:
1. Cifrado simétrico
2. Cifrado asimétrico
3. Hashing

 Cifrado Simétrico
El cifrado simétrico es una forma de cifrado en la que se utiliza una clave secreta tanto para
el cifrado como para el descifrado de un mensaje, tanto por el cliente como por el host.
Efectivamente, cualquiera que tenga la clave puede descifrar el mensaje que se transfiere.
El cifrado simétrico a menudo se llama clave compartida (shared key) o cifrado secreto
compartido. Normalmente sólo hay una clave que se utiliza, o a veces un par de claves
donde una clave se puede calcular fácilmente con la otra clave.
Las claves simétricas se utilizan para cifrar toda la comunicación durante una sesión SSH.
Tanto el cliente como el servidor derivan la clave secreta utilizando un método acordado, y
la clave resultante nunca se revela a terceros. El proceso de creación de una clave simétrica
se lleva a cabo mediante un algoritmo de intercambio de claves.
Lo que hace que este algoritmo sea particularmente seguro es el hecho de que la clave
nunca se transmite entre el cliente y el host. En lugar de eso, los dos equipos comparten
datos públicos y luego los manipulan para calcular de forma independiente la clave secreta.
Incluso si otra máquina captura los datos públicamente compartidos, no será capaz de
calcular la clave porque el algoritmo de intercambio de clave no se conoce.
Debe tenerse en cuenta, sin embargo, que el token secreto es específico para cada sesión
SSH, y se genera antes de la autenticación del cliente. Una vez generada la clave, todos los
paquetes que se mueven entre las dos máquinas deben ser cifrados por la clave privada.
Esto incluye la contraseña escrita en la consola por el usuario, por lo que las credenciales
siempre están protegidas de los fisgones de paquetes de red.
Existen varios códigos cifrados simétricos, incluyendo, pero no limitado a, AES (Advanced
Encryption Standard), CAST128, Blowfish, etc. Antes de establecer una conexión segura,
el cliente y un host deciden qué cifrado usar, publicando una lista de cifrados soportados
por orden de preferencia. El cifrado preferido de entre los soportados por los clientes que
está presente en la lista del host se utiliza como el cifrado bidireccional.
Por ejemplo, si dos máquinas Ubuntu 14.04 LTS se comunican entre sí a través de SSH,
utilizarán aes128-ctr como su cifrado predeterminado.
 Cifrado Asimétrico
A diferencia del cifrado simétrico, el cifrado asimétrico utiliza dos claves separadas para el
cifrado y el descifrado. Estas dos claves se conocen como la clave pública (public key) y la
clave privada (private key). Juntas, estas claves forman el par de claves pública-privada
(public-private key pair).
La clave pública, como sugiere el nombre, se distribuye abiertamente y se comparte con
todas las partes. Si bien está estrechamente vinculado con la clave privada en términos de
funcionalidad, la clave privada no se puede calcular matemáticamente desde la clave
pública. La relación entre las dos claves es altamente compleja: un mensaje cifrado por la
clave pública de una máquina, sólo puede ser descifrado por la misma clave privada de la
máquina. Esta relación unidireccional significa que la clave pública no puede descifrar sus
propios mensajes ni descifrar nada cifrado por la clave privada.
La clave privada debe permanecer privada, es decir, para que la conexión sea asegura,
ningún tercero debe conocerla. La fuerza de toda la conexión reside en el hecho de que la
clave privada nunca se revela, ya que es el único componente capaz de descifrar mensajes
que fueron cifrados usando su propia clave pública. Por lo tanto, cualquier parte con la
capacidad de descifrar mensajes firmados públicamente debe poseer la clave privada
correspondiente.
A diferencia de la percepción general, el cifrado asimétrico no se utiliza para cifrar toda la
sesión SSH. En lugar de eso, sólo se utiliza durante el algoritmo de intercambio de claves
de cifrado simétrico. Antes de iniciar una conexión segura, ambas partes generan pares de
claves públicas-privadas temporales y comparten sus respectivas claves privadas para
producir la clave secreta compartida.
Una vez que se ha establecido una comunicación simétrica segura, el servidor utiliza la
clave pública de los clientes para generar y desafiar y transmitirla al cliente para su
autenticación. Si el cliente puede descifrar correctamente el mensaje, significa que contiene
la clave privada necesaria para la conexión. Y entonces comienza la sesión SSH.
 Hashing
El hashing unidireccional es otra forma de criptografía utilizada en Secure Shell
Connections. Las funciones de hash unidireccionales difieren de las dos formas anteriores
de encriptación en el sentido de que nunca están destinadas a ser descifradas. Generan un
valor único de una longitud fija para cada entrada que no muestra una tendencia clara que
pueda explotarse. Esto los hace prácticamente imposibles de revertir.

Ventajas y desventajas del Servidor SSH

A continuación, les mostramos una tabla comparativa y esquema sobre cuáles son las
principales ventajas y desventajas del servidor SSH.

Características Ventajas Desventajas

 Seguridad  Muy buena  No muy buena
 Funciones  Muchas y variadas
 Velocidad  Totalmente gratuito  No posee interfaz
 Costo  Fácil de usar gráfica
 Facilidad de uso
 Interfaz

FTP Y TFTP
 FTP
FTP (siglas en inglés de File Transfer Protocol, ‘Protocolo de Transferencia de Archivos’),
es un protocolo de red para la transferencia de archivos entre sistemas interconectados o
enlazados a Internet, basado en la arquitectura cliente-servidor. Desde un equipo cliente se
puede conectar a un servidor para descargar archivos desde él o para enviarle archivos,
independientemente del sistema operativo utilizado en cada equipo.
El funcionamiento es relativamente sencillo. Una persona desde su computador invoca un
programa cliente FTP para conectar con otro computador/servidor, que a su vez tiene
instalado el programa servidor FTP. Una vez establecida la conexión y debidamente
autenticado el usuario con su contraseña, se pueden empezar a intercambiar archivos de
todo tipo.
Los beneficios de contar con un servicio FTP son bastantes, entre otros se encuentran la
facilidad para la transferencia de altos volúmenes de información, velocidad y estabilidad
de los enlaces, seguridad en la transferencia de información, bajos costos de
implementación y flexibilidad en configuración de cuotas, usuarios y permisos de acceso.
Para contar con la posibilidad de manejar servicios FTP se requieren básicamente dos
elementos principales, un servidor FTP y un cliente FTP.
Servidor FTP
Un servidor FTP es un programa especial que se ejecuta en un equipo servidor
normalmente conectado a Internet. Su función es permitir el intercambio de datos entre
diferentes servidores/computadores.
Por lo general, los programas servidores FTP no suelen encontrarse en los computadores
personales, por lo que un usuario normalmente utilizará el FTP para conectarse
remotamente a uno y así intercambiar información con él.
Las aplicaciones más comunes de los servidores FTP suelen ser el hosting, en el que los
clientes utilizan el servicio para subir sus páginas web y sus archivos correspondientes; o
como servidor de backup de los archivos importantes que pueda tener una empresa. Para
ello, existen protocolos de comunicación FTP para que los datos se transmitan cifrados,
como el SFTP (Secure File Transfer Protocol).
Cliente FTP
Cuando un navegador no está equipado con la función FTP, o si se quiere cargar archivos
en un servidor remoto, se necesitará utilizar un programa cliente FTP. Un cliente FTP es un
programa que se instala en el computador del usuario, y que emplea el protocolo FTP para
conectarse a un servidor FTP y transferir archivos, ya sea para descargarlos o para subirlos.
Para utilizar un cliente FTP, se necesita conocer el nombre del archivo, el computador en
que reside (servidor, en el caso de descarga de archivos), el computador al que se quiere
transferir el archivo (en caso de querer subirlo nosotros al servidor), y la carpeta en la que
se encuentra.
Algunos clientes de FTP básicos en modo consola vienen integrados en los sistemas
operativos, incluyendo Microsoft Windows, GNU/Linux y Unix. Sin embargo, hay
disponibles clientes con opciones añadidas e interfaz gráfica. Aunque muchos navegadores
tienen ya integrado FTP, es más confiable a la hora de conectarse con servidores FTP
utilizar un programa cliente.

¿Qué es FTP?
El acrónimo de FTP es protocolo de transferencia de ficheros (File Transfer Protocol) y es
un software cliente/servidor que permite a usuarios transferir ficheros entre ordenadores en
una red TCP/IP.
FTP tiene sus orígenes en 1971, y aunque ha evolucionado con el paso de los años, es uno
de los protocolos más antiguos que todavía están en uso. Hoy en día se usa principalmente
en redes corporativas y la red más grande que existe, Internet.
Aunque no estés familiarizado o no conoces FTP, las opciones de que lo hayas usado
alguna vez son bastante grandes. Muchos de los enlaces de descarga que usas en Internet,
son URLs que apuntan a un ordenador que está actuando como un servidor FTP: tu
navegador automáticamente hace la conexión y descarga correspondiente.
Puertos múltiples, modos múltiples
A diferencia de la mayoría de los protocolos utilizados en Internet, FTP requiere de
múltiples puertos de red para funcionar correctamente. Cuando una aplicación cliente FTP
inicia una conexión a un servidor FTP, abre el puerto 21 en el servidor conocido como el
puerto de comandos. Se utiliza este puerto para arrojar todos los comandos al servidor.
Cualquier petición de datos desde el servidor se devuelve al cliente a través del puerto de
datos. El número de puerto para las conexiones de datos y la forma en la que las conexiones
son inicializadas varía dependiendo de si el cliente solicita los datos en modo activo o en
modo pasivo.
A continuación, se describen estos modos:
 Modo activo
El modo activo es el método original utilizado por el protocolo FTP para la transferencia de
datos a la aplicación cliente. Cuando el cliente FTP inicia una transferencia de datos, el
servidor abre una conexión desde el puerto 20 en el servidor para la dirección IP y un
puerto aleatorio sin privilegios (mayor que 1024) especificado por el cliente. Este arreglo
implica que la máquina cliente debe poder aceptar conexiones en cualquier puerto superior
al 1024. Con el crecimiento de las redes inseguras, tales como Internet, es muy común el
uso de cortafuegos para proteger las máquinas cliente. Debido a que estos cortafuegos en el
lado del cliente normalmente rechazan las conexiones entrantes desde servidores FTP en
modo activo, se creó el modo pasivo.
 Modo pasivo
La aplicación FTP cliente es la que inicia el modo pasivo, de la misma forma que el modo
activo. El cliente FTP indica que desea acceder a los datos en modo pasivo y el servidor
proporciona la dirección IP y el puerto aleatorio, sin privilegios (mayor que 1024) en el
servidor. Luego, el cliente se conecta al puerto en el servidor y descarga la información
requerida.
Mientras que el modo pasivo resuelve el problema de la interferencia del cortafuego en el
lado del cliente con las conexiones de datos, también puede complicar la administración de
los cortafuegos del lado del servidor. Una de las formas de limitar el número de puertos
abiertos en el servidor y de simplificar la tarea de crear reglas para el cortafuego del lado
del servidor, es limitando el rango de puertos sin privilegios ofrecidos para las conexiones
pasivas.
 TFTP
El protocolo Trivial File Transfer Protocol, en su forma abreviada TFTP, es un protocolo
cliente-servidor muy simple que regula la transferencia de archivos en redes informáticas.
Se definió originalmente en junio de 1981 en el RFC 783, si bien en la actualidad está
vigente el estándar RFC 1350, publicado en 1992. Por defecto, el protocolo TFTP se basa
en el protocolo mínimo de nivel de transporte UDP (User Datagram Protocol), que ofrece la
posibilidad de transmitir datos sin necesidad de una conexión fija entre los miembros de la
comunicación. No obstante, también es posible implementar el protocolo TFPT basándose
en otros protocolos diferentes.
Se trata de un protocolo de transferencia de archivos que funciona mediante paquetes de
datos. Forma parte de la familia de protocolos TCP/IP y fue específicamente diseñado para
que su implementación fuese lo más sencilla y ligera posible. Por esta razón, su
funcionalidad consiste principalmente en la lectura o escritura de un archivo o un correo
electrónico de un servidor. Sin embargo, con el protocolo TFTP no es posible listar
directorios o establecer permisos usando chmod. TFTP utiliza el puerto 69. Posteriormente,
la comunicación se produce a través de números de puerto asignados individualmente
(entre el 1024 y el 65535), que el servidor del protocolo TFTP envía al cliente solicitante a
través de identificadores TID (Transfer Identifiers).
¿Cómo funciona el protocolo TFTP?
La transferencia de archivos a través de TFTP se basa siempre en una solicitud de acceso
del cliente, bien de lectura bien de escritura. Esta solicitud funciona al mismo tiempo como
petición de conexión que se concede automáticamente en el momento en el que el servidor
acepta el acceso. A continuación, el cliente o el servidor envía el archivo que corresponda
en bloques de tamaño fijo. En las primeras versiones del protocolo, se utilizaba un valor
fijo de 512 bytes pero, a partir del RFC 2348, el servidor y el cliente tienen la posibilidad
de negociar en cada caso el tamaño del bloque.
La transferencia se realiza bloque a bloque. El servidor no envía un nuevo bloque hasta que
reciba el paquete de confirmación del bloque anterior. El paquete de datos final se
identifica por ser más pequeño del tamaño establecido. Si un paquete se pierde se generará
un timeout, tras el que se efectuará la retransmisión del último paquete. De esta manera, el
emisor del paquete perdido sabrá que tiene que retransmitir dicho paquete. Cualquier error
que ocurra al transferir archivos mediante TFTP dan lugar a paquetes de error que en la
mayoría de los casos causan la finalización de la transferencia. Las posibles causas de error
son:
 No es posible aceptar una solicitud de transferencia, por ejemplo, porque el archivo
no se ha podido encontrar, el usuario no existe o se ha producido una violación de
permisos (archivo protegido, etc.).
  Los clientes o servidores reciben un paquete que no se puede explicar por un retraso
o duplicación en la red. Es el caso, por ejemplo, de paquetes con formato incorrecto.
 Se pierde el acceso a un recurso necesario, por ejemplo, si no hay espacio en el
disco duro.
Pros y contras del protocolo TFTP
Una de las principales ventajas del protocolo TFTP es su simplicidad, pues está diseñado
para permitir la escritura y la lectura de archivos sin tener que establecer una conexión
entre el cliente y el servidor. Por ello, el protocolo TFTP no solo es fácil de implementar,
sino que también es el precursor de la transferencia rápida de archivos. Los identificadores
TID y los números de bloque de datos únicos hacen que el archivo llegue en su totalidad al
destinatario.
Sin embargo, la falta de cifrado y de un mecanismo de control de autenticación y acceso
hacen que el envío de archivos confidenciales a través del protocolo TFTP suponga riesgos
altos. En su lugar, pueden utilizarse otras alternativas más seguras como FTP, un protocolo
más complejo. Además, muchos servidores TFTP no permiten eliminar y renombrar
archivos
HTTP Y HTTPS
 HTTP
El http (del inglés HyperText Transfer Protocol o Protocolo de Transferencia de Hiper
Textos) es el protocolo de transmisión de información de la World Wide Web, es decir, el
código que se establece para que el computador solicitante y el que contiene la información
solicitada puedan “hablar” un mismo idioma a la hora de transmitir información por la red.
Con el http se establecen criterios de sintaxis y semántica informática (forma y significado)
para el establecimiento de la comunicación entre los diferentes elementos que constituyen
la arquitectura web: servidores, clientes, proxies. Fue creado en 1999 por el World Wide
Web Consortium en colaboración con la Internet Engineering Task Force.
Se trata de un protocolo “sin estado”, vale decir, que no lleva registro de visitas anteriores
sino que siempre empieza de nuevo. La información relativa a visitas previas se almacena
en estos sistemas en las llamadas “cookies”, almacenadas en el sistema cliente.
El http ha pasado por numerosas versiones hasta alcanzar la actual a principios del siglo
XXI, llamada HTTP/2. Sus primeros intentos se produjeron en 1991 y arrojaron versiones
parciales en 1996, 1999, 2000 y, finalmente, la vigente en 2015.
¿Para qué sirve el protocolo http?
El http, como se ha dicho, es un lenguaje que media entre las peticiones del cliente y las
respuestas del servidor en la Internet, para permitir una comunicación fluida y en un mismo
“lenguaje”. Este protocolo establece las pautas a seguir, los métodos de petición (llamados
“verbos”) y cuenta con cierta flexibilidad para incorporar nuevas peticiones y
funcionalidades, en especial a medida que se avanza en sus versiones.
Considerando que la Internet es poco más que una compleja red de intercambio de
información entre computadores a distancia, este tipo de herramientas digitales son clave en
establecer las bases para ordenar y facilitar la transmisión de la información.

¿Cómo funciona el protocolo http?

El funcionamiento del http se basa en un esquema de petición-respuesta entre el servidor
web y el “agente usuario” (del inglés user agent) o cliente que realiza la solicitud de
transmisión de datos. Un cliente puede ser un explorador determinado, cuando intentamos
abrir una página web, o los rastreadores web (webcrawlers o arañas web) que las
inspeccionan.
A ellos el servidor brinda una respuesta estructurada de modo puntual y dotada de una serie
de metadatos, que establecen las pautas para el inicio, desarrollo y cierre de la transmisión
de la información. Estos son los “métodos de petición”, es decir, los comandos que
disparan la ejecución de recursos determinados, cuyos archivos residen en el servidor.
Por ejemplo: Al abrir una página web específica, el intercambio informativo entre nuestro
explorador web y el servidor donde reside la información establecerá de qué manera debe
transmitirse la información, en qué lugar están las imágenes y en qué orden se me
mostrarán, etc. Este intercambio de comandos de solicitud y códigos de respuesta da como
resultado la representación en mi computador de la misma información contenida
originalmente en el servidor, que puede estar a miles de kilómetros de distancia.
Códigos numéricos de respuesta HTTP
El servidor web responde a cada solicitud con un código de respuesta que puede ser:
 1xx: Respuestas informativas, indicando que la petición se recibió y se está
procesando. El más común es el 100.

 2xx: Respuestas correctas, donde indica que la solicitud se procesó correctamente.

El típico es el 200 (OK).

 3xx: Respuestas de redirección, indica que el cliente deberá realizar más acciones
para finalizar esta solicitud.
  4xx: Errores causados por el cliente, donde indica que ha ocurrido un error cuando
se estaba procesando la solicitud probablemente porque el cliente hizo algo mal.
Generalmente porque la dirección URL es incorrecta, que es el error más típico, el
404. También el 403 - Forbidden (prohibido) es usual.

 5xx: Errores causados por el servidor, con esto indica que ha ocurrido un error al
procesar la solicitud por un fallo en en el servidor. La más usual es 500 - Internal
Server Error.
HTTPS
HTTPS es una versión segura del Protocolo de Transferencia de Hipertexto (HTTP). La ‘S’
quiere decir ‘Seguro’.
La diferencia básica entre ambos es la forma en la que viajan los datos. Si los datos son
transferidos mediante HTTP, estos viajan en claro y son accesibles para cualquiera que
intercepte la comunicación. En cambio, el protocolo HTTPS usa una conexión segura
mediante un cifrado SSL y por tanto los datos viajan de un modo seguro de un lugar a otro.
Es un método para garantizar una comunicación segura entre el navegador de un usuario y
un servidor web. A menudo se reconoce por una barra de direcciones verde o un candado
en la ventana del navegador, que indica que la conexión es segura.
¿Por qué necesitas HTTPS?
Tradicionalmente, HTTPS se usaba por vendedores eCommerce o por cualquiera que
aceptara un pago online, con el fin de asegurar que los detalles del pago, de carácter más
sensible, se enviaban de forma segura, evitando que fueran robados por hackers.
Sin embargo, mejorar la seguridad online se ha convertido en algo cada vez más importante
en los últimos años y Google se ha puesto a la cabeza de ello. Tanto que ha anunciado que
HTTPS es un valor que influye en su algoritmo de ranking, lo cual ha acelerado el cambio
general a HTTPS.
Por tanto, HTTPS es algo muy recomendado para cualquier negocio que quiera ofrecer una
experiencia segura a sus visitantes y desee alcanzar un ranking alto en Google, así como
facilitar operaciones seguras a través de su sitio web.
¿Cómo funciona HTTPS?
HTTPS se basa en uno de los dos tipos de Protocolos de Encriptación: Secure Sockets
Layer (SSL) o Transport Layer Security (TLS). Muchos sitios web usan un certificado SSL
para encriptar la comunicación.
Tanto TLS como SSL usan una Infraestructura Asimétrica de Clave Pública, en la que una
clave ‘pública’ y una clave ‘privada’ se emplean para encriptar los datos.
La clave privada se almacena en el servidor web mientras que la clave pública es, como
indica su nombre, de dominio público y se usa para decodificar los datos encriptados
enviados desde el servidor web y viceversa.
Cuando un navegador inicia una sesión HTTPS con el servidor web, el servidor envía la
clave pública al navegador y se lleva a cabo un ‘SSL Handshake’ (saludo) entre el
navegador y el servidor. Una vez que la conexión segura se ha iniciado y aceptado, el
navegador reconoce el link y lo muestra como seguro, ya sea mediante una barra verde o un
candado, dependiendo del tipo de certificado SSL que se use.
¿Cuáles son los beneficios de HTTPS?
 Mayor confianza: HTTPS reafirma a los potenciales clientes que tu negocio es
responsable y seguro.
 Mayor transparencia: los clientes potenciales pueden ver que eres un negocio real
y que eres propietario del nombre de dominio.
 Mejores tasas de conversión: los clientes son mucho más proclives a completar
una compra si ven que el sitio web es seguro.
 Más tráfico: HTTPS se ha establecido como un factor de ranking para Google, así
que usar HTTPS te puede proporcionar un mejor ranking que a los sitios menos
seguros de la competencia.

NFS
El protocolo NFS (del inglés Network File System) fue diseñado para permitir sistemas de
archivo distribuido en entornos de red local. Esto significa que cualquier equipo, ya sea un
ordenador de usuario o un servidor, es capaz de acceder a la información almacenada como
si se tratara de almacenamiento de un disco duro local. La primera versión fue presentada
por Sun Microsystems en 1984 y fue pensada para que fuera independiente del sistema
operativo utilizado por cada equipo y del tipo de red local que hubiera. Hay que recordar
que en esa época la tecnología TCP/IP competía con otros tipos de redes y aún no estaba
claro cuál sería la red predominante.
El desarrollo de este protocolo parte de algunas premisas importantes, fruto del estado de la
tecnología del momento, que hoy en día nos pueden parecer algo encorsetadas, si bien el
protocolo NFS sigue siendo ampliamente utilizado en entornos empresariales por las
facilidades que aporta a los sistemas distribuidos. Veamos dos de estas premisas básicas:
 El protocolo diferencia dos participantes en la comunicación: un servidor, que es el
equipo que tiene almacenada físicamente la información; y los clientes, que son
aquellos equipos que desean acceder o modificar la información. En esta estructura
siempre habrá un único servidor y tantos clientes como sean necesarios.
  Todas las operaciones son síncronas. Debido a las capacidades de la época el
protocolo NFS fue diseñado para que cualquier operación que se ordena desde un
cliente (acceso, escritura o borrado de archivos, etc.) se realiza en el servidor y éste
no devuelve la información al cliente hasta que se haya terminado. Así se puede
garantizar la integridad de los datos almacenados ya que se evita que se ejecuten
instrucciones incompatibles al mismo tiempo.

Funcionamiento
Hay tres versiones de NFS actualmente en uso. La versión 2 de NFS (NFSv2), es la más
antigua y está ampliamente soportada por muchos sistemas operativos. La versión 3 de NFS
(NFSv3) tiene más características, incluyendo manejo de archivos de tamaño variable y
mejores facilidades de informes de errores, pero no es completamente compatible con los
clientes NFSv2. NFS versión 4 (NFSv4) incluye seguridad Kerberos, trabaja con
cortafuegos, permite ACLs y utiliza operaciones con descripción del estado. Red Hat
Enterprise Linux soporta clientes tanto NFSv2, NFSv3 como NFSv4, y cuando monta un
sistema de archivos a través de NFS, Red Hat Enterprise Linux usa NFSv4 por defecto.
Todas las versiones de NFS pueden utilizar el Protocolo de control de transmisiones (TCP)
ejecutándose sobre una red IP. En el caso de NFSv4, éste lo requiere. NFSv2 y NFSv3
pueden utilizar el Protocolo de datagrama de usuarios (UDP) sobre una red IP para
proporcionar conexiones de red sin supervisión (stateless) entre el cliente y el servidor.
Cuando se utiliza NFSv2 o NFSv3 con UDP, bajo condiciones normales la conexión UDP
desatendida minimiza el tráfico de la red, ya que el servidor NFS envia un cookie al cliente
después que este tiene acceso al volumen compartido. Esta cookie es un valor aleatorio
guardado en el lado del servidor y es pasado junto con las peticiones RPC desde el cliente.
El servidor NFS puede ser reiniciado sin afectar a los clientes y las cookies permanecen
intactas. Sin embargo, debido a que UDP es sin supervisión, si el servidor se cae de forma
inesperada, los clientes UDP continúan saturando la red con peticiones para el servidor. Por
esta razón, TCP es el protocolo preferido cuando se conecte a un servidor NFS.
Cuando se autentifique utilizando NFSv4, se crea una conexión atenta y, de forma opcional,
está disponible la autenticación de usuarios y grupos con Kerberos. NFSv4 no tiene
interacción con portmapper, rpc.mountd, rpc.lockd y rpc.statd, pues estos han sido
incorporados en el kernel. NFSv4 escucha en el puerto TCP 2049.
La única vez que NFS lleva a cabo la autentificación es cuando el cliente intenta montar un
recurso compartido NFS. Para limitar el acceso al servicio NFS, se utilizan envolturas TCP
(TCP wrappers). Los TCP wrappers leen los archivos /etc/hosts.allow y /etc/hosts.deny para
determinar si a un cliente particular o red tiene acceso o no al servicio NFS. Para más
información sobre cómo configurar los controles de acceso con envolturas TCP (TCP
wrappers), consulte el Capítulo 17.
Después de que al cliente se le permite acceso gracias a un TCP wrapper, el servidor NFS
recurre a su archivo de configuración, /etc/exports, para determinar si el cliente tiene
suficientes privilegios para acceder a los sistemas de archivos exportados. Una vez
otorgado el acceso, todas las operaciones de archivos y de directorios están disponibles para
el usuario.

Servicios requeridos
Red Hat Enterprise Linux utiliza una combinación de soporte a nivel del kernel y procesos
demonio para proporcionar los archivos compartidos con NFS. NFSv2 y NFSv3 confía en
las Llamadas de procedimientos remotos ((RPC)) para enrutar peticiones entre clientes y
servidores. Los servicios RPC bajo Linux son controlados por el servicio portmap. Para
compartir o montar sistemas de archivos NFS, los servicios siguientes funcionan juntos,
dependiendo de cuál versión de NFS se tenga implementada:
 nfs: Inicia los procesos RPC apropiados para servir peticiones para los sistemas de
archivos compartidos NFS.
 nfslock: Un servicio opcional que inicia los procesos RPC adecuados para permitir
que clientes NFS bloqueen archivos en el servidor.
 Portmap: El servicio RPC para Linux; responde a las peticiones para servicios
RPC y configura las conexiones al servicio RPC solicitado. No se utiliza con
NFSv4.
Los siguientes procesos RPC facilitan los servicios NFS:
 rpc.mountd: Este proceso recibe las peticiones de montaje desde clientes NFS y
verifica que el sistema de archivos solicitado esté actualmente exportado. Este
proceso es iniciado automáticamente por el servicio nfs y no requiere de la
configuración del usuario. No se utiliza con NFSv4.

 rpc.nfsd: Este proceso es el servidor NFS. Trabaja con el kernel Linux para
satisfacer las demandas dinámicas de clientes NFS, tales como proporcionar hilos
del servidor cada vez que se conecta un cliente NFS. Este proceso corresponde al
servicio nfs.

 rpc.lockd: Un proceso opcional que permite a los clientes NFS bloquear archivos
en el servidor. Esto corresponde al servicio nfslock. No se utiliza con NFSv4.

 rpc.statd: Este proceso implementa el protocolo RPC Network Status Monitor

(NSM) el cual notifica a los clientes NFS cuando un servidor NFS es reiniciado
luego de haber sido apagado abruptamente. Este proceso es iniciado
 automáticamente por el servicio nfslock y no requiere configuración por parte del
usuario. No se utiliza con NFSv4.
 rpc.rquotad: Proporciona información de cuotas de usuario para los usuarios
remotos. Este proceso se inicia automáticamente por el servicio nfs y no requiere
configuración por parte del usuario.

 rpc.idmapd: Este proceso proporciona al cliente y servidor NFSv4 llamadas

ascendentes (upcalls) que hacen corresponder los nombres NFSv4 (los cuales son
cadenas en la forma usuario@dominio) y los UIDs y GIDs locales. Para que idmapd
funcione con NFSv4, el /etc/idmapd.conf debe estar configurado. Se requiere este
servicio para su uso con NFSv4.

 rpc.svcgssd: Este proceso proporciona al servidor los mecanismos de transporte

para el proceso de autenticación (Kerberos versión 5) con NFSv4. Se requiere este
servicio para su uso con NFSv4.

 rpc.gssd: Este proceso proporciona al cliente los mecanismos de transporte para el

proceso de autenticación (Kerberos versión 5). Se requiere este servicio para su uso
con NFSv4.

LDAP
LDAP (“Lightweight Directory Access Protocol'', «Protocolo Ligero de Acceso a
Directorios») es un protocolo de tipo cliente-servidor para acceder a un servicio de
directorio. Se usó inicialmente como un front-end o interfaz final para X.500, pero también
puede usarse con servidores de directorio únicos y con otros tipos de servidores de
directorio.
LDAP (Protocolo compacto de acceso a directorios) es un protocolo estándar que permite
administrar directorios, esto es, acceder a bases de información de usuarios de una red
mediante protocolos TCP/IP.
Las bases de información generalmente están relacionadas con los usuarios, pero, algunas
veces, se utilizan con otros propósitos, como el de administrar el hardware de una
compañía.
El objetivo del protocolo LDAP, desarrollado en 1993 en la Universidad de Michigan, fue
reemplazar al protocolo DAP (utilizado para acceder a los servicios de directorio X.500 por
OSI) integrándolo al TCP/IP. Desde 1995, DAP se convirtió en LDAP independiente, con
lo cual se dejó de utilizar sólo para acceder a los directorios tipo X500. LDAP es una
versión más simple del protocolo DAP, de allí deriva su nombre Protocolo compacto de
acceso a directorios.
¿Qué es un servicio de directorio?
Un directorio es como una base de datos, pero en general contiene información más
descriptiva y más basada en atributos. La información contenida en un directorio
normalmente es lee mucho más de lo que se escribe. Como consecuencia los directorios no
implementan normalmente los complicados esquemas para transacciones o esquemas de
reducción (rollback) que las bases de datos utilizan para llevar a cabo actualizaciones
complejas de grandes volúmenes de datos. Por contra, las actualizaciones en un directorio
son usualmente cambios sencillos de «todo o nada», si es que se permiten en algo.
Los directorios están afinados para proporcionar una repuesta rápida a operaciones de
búsqueda o consulta. Pueden tener la capacidad de replicar información de forma amplia,
con el fin de aumentar la disponibilidad y la fiabilidad, y a la vez reducir el tiempo de
respuesta. Cuando se duplica (o se replica) la información del directorio, pueden aceptarse
inconsistencias temporales entre la información que hay en las réplicas, siempre que
finalmente exista una sincronización.
Existen muchas maneras distintas de proporcionar un servicio de directorio. Los diferentes
métodos permiten almacenar en el directorio diferentes tipos de información, establecer
requisitos diferentes para hacer referencias a la información, consultarla y actualizarla, la
forma en que protege al directorio de accesos no autorizados, etc. Algunos servicios de
directorio son locales, proporcionando servicios a un contexto restringido (por ejemplo, el
servicio de finger en una única máquina). Otros servicios son globales, proporcionando
servicio en un contexto mucho más amplio.

¿Cómo funciona LDAP?

El servicio de directorio LDAP se basa en un modelo cliente-servidor. Uno o más
servidores LDAP contienen los datos que conforman el árbol del directorio LDAP o base
de datos troncal. El cliente ldap se conecta con el servidor LDAP y le hace una consulta. El
servidor contesta con la respuesta correspondiente, o bien con una indicación de dónde
puede el cliente hallar más información (normalmente otro servidor LDAP). No importa
con qué servidor LDAP se conecte el cliente: siempre observará la misma vista del
directorio; el nombre que se le presenta a un servidor LDAP hace referencia a la misma
entrada a la que haría referencia en otro servidor LDAP. Es ésta una característica
importante de un servicio de directorios universal como LDAP.
Backends, objetos y atributos en LDAP
Slapd se suministra con tres diferentes bases de datos de backend (dorsal, o base de datos
de segundo plano) entre las que elegir. Se trata de LDBM, una base de datos de gran
rendimiento basada en disco: SHELL, una interfaz de base de datos para órdenes arbitrarias
de UNIX o guiones (scripts) del intérprete de órdenes (shell); y PASSWD, una sencilla
base de datos de contraseñas.
La base de datos LDBM funciona asignando un identificador compacto de cuatro bytes,
único para cada entrada de la base de datos. La base de datos utiliza este identificador para
hacer referencia a entradas en los índices. La base de datos está compuesta de un fichero
índice principal, llamado id2entry, que mapea el identificador único de una entrada en la
representación en texto de esa misma entrada. También se da mantenimiento a otros
ficheros índice.
Para importar y exportar información de directorio entre servidores de directorios basados
en LDAP, o para describir una serie de cambios que han de aplicarse al directorio, se usa en
general del fichero de formato conocido como LDIF (siglas de "LDAP interchange format",
«formato de intercambio de LDAP»). Un fichero LDIF almacena información en jerarquías
de entradas orientadas a objeto. El paquete de software LDAP que va a utilizar incluye una
utilidad para convertir ficheros LDIF a formato LDBM.
Un fichero LDIF corriente tiene este aspecto:
dn: o=Insflug, c=ES
o: Insflug
objectclass: organization
dn: cn=Luiz Malere, o=Insflug, c=ES
cn: Luiz Malere
sn: Malere
mail: [email protected]
objectclass: person

Como puede comprobar, cada entrada está identificada unívocamente por un nombre
distintivo (DN, "distinguished name"). El DN (nombre distintivo) está compuesto por el
nombre de la entrada en cuestión, más la ruta de nombres que permiten rastrear la entrada
hacia atrás hasta la parte superior de la jerarquía del directorio.
En LDAP, una clase de objetos define la colección de atributos que pueden usarse para
definir una entrada. El estándar LDAP proporciona estos tipos básicos para las clases de
objetos:
 Grupos en el directorio, entre ellos listas no ordenadas de objetos individuales o de
grupos de objetos.
 Emplazamientos, como por ejemplo el nombre del país y su descripción.
 Organizaciones que están en el directorio.
 Personas que están en el directorio.
Una entrada determinada puede pertenecer a más de una clase de objetos. Por ejemplo, la
entrada para personas se define mediante la clase de objetos person, pero también puede
definirse mediante atributos en las clases de objetos inetOrgPerson, groupOfNames y
organization. La estructura de clases de objetos del servidor determina la lista total de
atributos requeridos y permitidos para una entrada concreta.
Los datos del directorio se representan mediante pares de atributo y su valor. Cualquier
pieza de información específica se asocia con un atributo descriptivo.

SMTP, POP, IMAP Y SASL

SMTP
El SMTP (Simple Mail Transfer Protocol, o protocolo simple de transferencia de correo) es
un protocolo básico que permite que los emails viajen a través de Internet.
Es decir, es un protocolo de mensajería empleado para mandar un email de un servidor de
origen a un servidor de destino. Este procedimiento, indispensable en el proceso de envío
de emails, es completado por el servidor SMTP.
¿Qué es el servidor SMTP?
El servidor SMTP es un ordenador encargado de llevar a cabo el servicio SMTP, haciendo
las veces de “cartero electrónico” y permitiendo el transporte de ese correo electrónico por
Internet. La retransmisión SMTP funciona de un modo muy sencillo: si el servidor SMTP
confirma las identidades del remitente y del destinatario, entonces el envío se realiza.
Digamos que es como la oficina de correos de la web: recoge el email del remitente y lo
entrega en la oficina de correos local del destinatario, que es otro servidor SMTP. Nació en
1982 y sigue siendo el estándar de Internet más utilizado a día de hoy.
El SMTP es un protocolo de red que se emplea para enviar y recibir correos electrónicos
(emails). Cabe destacar que un protocolo de red es un conjunto de normativas y reglas que
posibilitan la circulación de información en una red informática. En este caso, el SMTP
forma parte de los llamados protocolos de Internet.
La operación del SMTP se produce en el contexto de los servicios de correo electrónico.
Debido a ciertas restricciones técnicas para recibir los correos, es habitual que el SMTP se
emplee sólo para el envío de mensajes y que para la recepción se apele a otros protocolos
de Internet, como IMAP (Internet Message Access Protocol) o POP (Post Office Protocol).
En el caso del SMTP, su función es permitir que un cliente se comunique con un servidor,
posibilitando que el cliente envíe un correo a uno o más receptores. El SMTP trabaja con
líneas de texto para brindar las instrucciones necesarias.
Existen tres comandos que componen el SMTP: MAIL, que establece la dirección de
remitente para los mensajes de despedida; RCPT, que establece el destinatario del mensaje
(en caso de ser varios, se emite una vez para cada uno); DATA, comando que envía el
contenido del mensaje.
Cuando una persona envía un correo electrónico a través de este protocolo, lo que ocurre es
que el cliente de correo (como Outlook Express o Mozilla Thunderbird) presenta el
mensaje en cuestión a un servidor de correo a través del SMTP. El servidor envía el
mensaje al Mail Transfer Agent (MTA), que apela al Domain Name System (DNS) para
buscar el registro MX. Cuando éste acepta el correo, lo deriva a su vez a un Mail Delivery
Agent (MDA), que puede volver a recurrir al SMTP para entregarlo al servidor de correo.
Mediante el IMAP, finalmente, el usuario receptor puede recuperar el mensaje en su cliente
de correo electrónico.
Comandos SMTP
La conversación se produce mediante comandos de texto muy simples. Los más comunes
son los siguientes:
 HELO: para abrir una sesión con el servidor.
 EHLO: para abrir una sesión, en el caso de que el servidor soporte extensiones
definidas en el RFC 1651.
 MAIL FROM: para indicar quien envía el mensaje.
 RCPT TO: para indicar el destinatario del mensaje.
 DATA: para indicar el comienzo del mensaje, este finalizará cuando haya una línea
únicamente con un punto.
 QUIT: para cerrar la sesión.
 RSET: Aborta la transacción en curso y borra todos los registros.
 SEND: Inicia una transacción en la cual el mensaje se entrega a una terminal.
 VRFY: Solicita al servidor la verificación de todo un argumento.
 EXPN: Solicita al servidor la confirmación del argumento.
 HELP: Permite solicitar información sobre un comando.
POP
POP (Post Office Protocol) es un protocolo estándar de internet de la capa aplicación en el
modelo OSI. El protocolo POP es utilizado por programas de e-mail locales para recibir e-
mails desde un servidor remoto a través de una conexión TCP/IP.
POP e IMAP (Internet Message Access Protocol) son los dos protocolos más empleados
para la recepción de e-mails.
La versión 3 del protocolo POP, llamada POP3, es el estándar actual y el más extendido. Es
el más empleado por los servicios de webmail como Gmail y Yahoo! Mail.
El POP proporciona acceso a través de una red de Protocolo de Internet (IP) para una
aplicación cliente de usuario a un buzón de correo (maildrop) mantenido en un servidor de
correo. El protocolo soporta operaciones de descarga y borrado de mensajes. Los clientes
POP3 se conectan, recuperan todos los mensajes, los almacenan en la computadora del
cliente y finalmente los eliminan del servido. Este diseño de POP y sus procedimientos fue
impulsado por la necesidad de que los usuarios sólo tuvieran conexiones temporales a
Internet, como el acceso por marcación, lo que les permite recuperar el correo electrónico
cuando están conectados y, posteriormente, ver y manipular los mensajes recuperados
cuando están fuera de línea.
Funcionamiento del protocolo POP
POP permite conectarse al servidor que almacena los e-mails, recibir todos los mensajes a
la computadora del cliente de e-mail y luego eliminar dichos e-mails del servidor, para
luego desconectarse. En ocasiones el cliente de e-mail permite conservar los e-mails en el
servidor.
Otros protocolos, como el IMAP, permiten tareas más complejas que el POP, pero la
mayoría de los proveedores de e-mail soportan solo POP.
El servidor POP3 (que contiene los e-mails) escucha el puerto 110 esperando conexiones.
Se encripta la comunicación (usando el comando STLS o POP3s), que conectan al servidor
usando TLS o SSL a través del puerto 995.
Los clientes POP3 también tienen la opción de dejar el correo en el servidor después de la
descarga. Por el contrario, el Protocolo de Acceso a Mensajes de Internet (IMAP) fue
diseñado para dejar normalmente todos los mensajes en el servidor para permitir la gestión
con múltiples aplicaciones cliente, y para soportar tanto los modos de operación conectados
(en línea) como desconectados (fuera de línea).
Un servidor POP3 escucha en el conocido puerto 110 para las peticiones de servicio. La
comunicación cifrada para POP3 se solicita tras el inicio del protocolo, utilizando el
comando STLS, si es compatible, o bien mediante POP3S, que se conecta al servidor
mediante Transport Layer Security (TLS) o Secure Sockets Layer (SSL) en el conocido
número de puerto TCP 995.
Los mensajes disponibles para el cliente se determinan cuando una sesión POP3 abre el
envío de correo, y se identifican por el número de mensaje local de esa sesión u,
opcionalmente, por un identificador único asignado al mensaje por el servidor POP. Este
identificador único es permanente y único para el envío de correo y permite a un cliente
acceder al mismo mensaje en diferentes sesiones POP. El correo se recupera y se marca
para ser borrado por el número de mensaje. Cuando el cliente sale de la sesión, el correo
marcado para su eliminación se elimina del envío de correo.

IMAP
IMAP es la abreviatura de "Internet Message Access Protocol". IMAP te ofrece la
posibilidad de administrar tus E-Mails directamente en el servidor de E-Mail, es decir, si
eliges el protocolo IMAP para establecer tu cuenta de correo en tu programa de E-Mail, los
correos que recibas no se descargarán en tu ordenador, sino que simplemente recibirás una
lista de tus mensajes y sus correspondientes asuntos. Generalmente sólo aparecerán los
encabezamientos de los E-Mails (esta opción también podrá modificarse en los respectivos
programas de E-Mail).
Además, puedes crear tu propia carpeta en el servidor de E-Mail y desplazar ahí tus
mensajes.
Ventajas al utilizar IMAP:
 Poder acceder a los E-Mails desde cualquier ordenador.
 Poder compartir un buzón de correo con otros usuarios.
 IMAP te permite crear carpetas y subcarpetas en el servidor de forma rápida y
sencilla. Las carpetas creadas con los programas de E-Mail se encontrarán en
realidad en el servidor.
 Se pueden llevar a cabo tareas como "buscar" o "clasificar" con ordenadores que no
tengan mucha potencia, ya que la acción tiene lugar en el servidor y no en el PC
local.
 Además, el servidor IMAP soporta extensiones IDLE, es decir, los nuevos E-Mails
recibidos se mostrarán como no leídos en la bandeja de entrada y tú. recibirás un
aviso. No será por tanto necesario hacer clic en "recibir" ni establecer un Polling-
Interval. Esta función está generalmente activada en los programas de E-Mail más
comunes (por ejemplo, Outlook, Outlook Express, Thunderbird, Netscape, etc.).
IMAP está diseñado para permitir la manipulación de buzones remotos como si fueran
locales. Dependiendo de la implementación del cliente IMAP y de la arquitectura de correo
deseada por el administrador del sistema, el usuario puede guardar los mensajes
directamente en el equipo del cliente, o guardarlos en el servidor, o se le puede dar la
opción de hacerlo.

SASL
Siglas en inglés para Simple Authentication and Security Layer (capa de seguridad y
autenticación simple).
SASL es un framework para autenticación y autorización en protocolos de Internet. Separa
los mecanismos de autenticación de los protocolos de la aplicación permitiendo, en teoría, a
cualquier protocolo de aplicación que use SASL usar cualquier mecanismo de autenticación
soportado por SASL. A pesar de que mediante SASL sólo se maneja la autenticación y se
requieren otros mecanismos, como por ejemplo TLS para cifrar el contenido que se
transfiere, SASL proporciona medios para un uso negociado del mecanismo elegido. Las
especificaciones originales de SASL fueron editadas por John Meyers en el RFC 2222. Este
fue hecho obsoleto por el RFC 4422, editado por Alexey Melnikov y Kurt Zeilenga.
Un mecanismo SASL se modela como una sucesión de retos y respuestas. Los mecanismos
definidos por SASL [1] incluyen:
  "EXTERNAL", aquí la autenticación está implícita en el contexto, por ejemplo, para
protocolos que ya usan IPsec o TLS.
 "ANONYMOUS", para el acceso de invitados sin autentificar.
 "PLAIN", un mecanismo de contraseña simple en texto plano.
 "OTP" para el sistema que evolucionó de S/KEY y que está definido en RFC 2289.
 "NTLM". Se prevé soportar los mecanismos GSSAPI en una familia de
nomenclatura de mecanismos.
Los protocolos definen su representación de intercambios SASL con un perfil. Un
protocolo tiene un nombre de servicio como "LDAP" en un registro compartido con
GSSAPI y Kerberos.
Entre los protocolos que ahora mismo usan SASL se incluyen IMAP, LDAP, POP3, SMTP
y XMPP.
2.9 PROXY
Un servidor proxy es un equipo dedicado o un sistema de software que se ejecuta en un
equipo de cómputo que actúa como intermediario entre un dispositivo de punto final, como
una computadora, y otro servidor del cual un usuario o cliente solicita un servicio. El
servidor proxy puede existir en la misma máquina que un servidor de firewall o puede estar
en un servidor independiente, que reenvía las solicitudes a través del firewall.
Una ventaja de un servidor proxy es que su caché puede servir a todos los usuarios. Si uno
o más sitios de internet se solicitan con frecuencia, es probable que estos estén en el caché
del proxy, lo que mejorará el tiempo de respuesta del usuario. Un proxy también puede
registrar sus interacciones, lo que puede ser útil para la solución de problemas.
A continuación, se muestra un ejemplo sencillo de cómo funcionan los servidores
proxy:
Cuando un servidor proxy recibe una solicitud de un recurso de internet (como una página
Web), busca en su caché local de páginas anteriores. Si encuentra la página, la devuelve al
usuario sin necesidad de reenviar la solicitud a internet. Si la página no está en la memoria
caché, el servidor proxy, que actúa como un cliente en nombre del usuario, utiliza una de
sus propias direcciones IP para solicitar la página desde el servidor en internet. Cuando se
devuelve la página, el servidor proxy la relaciona con la solicitud original y la envía al
usuario.
Los servidores proxy se utilizan para fines legales e ilegales. En la empresa, un servidor
proxy se utiliza para facilitar la seguridad, control administrativo o servicios de caché, entre
otros propósitos. En un contexto de computación personal, los servidores proxy se utilizan
para permitir la privacidad del usuario y el surf anónimo. Los servidores proxy también se
pueden utilizar para el propósito opuesto: supervisar el tráfico y minar la privacidad del
usuario.
Para el usuario, el servidor proxy es invisible; todas las solicitudes de internet y las
respuestas devueltas parecen estar directamente con el servidor de internet dirigido. (El
proxy no es realmente invisible, su dirección IP tiene que ser especificada como una opción
de configuración para el navegador u otro programa de protocolo.)
Los usuarios pueden acceder a proxies web en línea o configurar navegadores web para
usar constantemente un servidor proxy. Los parámetros del navegador incluyen opciones
manuales y detectadas automáticamente para proxies HTTP, SSL, FTP y SOCKS. Los
servidores proxy pueden servir a muchos usuarios o sólo uno por servidor. Estas opciones
se llaman proxies compartidos y dedicados, respectivamente. Hay una serie de razones para
los proxies y por lo tanto una serie de tipos de servidores proxy, a menudo en categorías
superpuestas.
Servidores proxy directos e inversos
Los proxies directos (forward proxy servers) envían las solicitudes de un cliente a un
servidor web. Los usuarios acceden a proxies directos navegando directamente a una
dirección de proxy web o estableciendo sus configuraciones de internet. Los proxies
directos permiten eludir los firewalls y aumentar la privacidad y la seguridad de un usuario,
pero a veces pueden usarse para descargar materiales ilegales, como los materiales
protegidos por derechos de autor o pornografía infantil.
Los proxies inversos (reverse proxies) manejan de forma transparente todas las solicitudes
de recursos en los servidores de destino sin requerir ninguna acción por parte del
solicitante.
Se utilizan proxies inversos:
 Para habilitar el acceso indirecto cuando un sitio web no permite conexiones
directas como medida de seguridad.
 Para permitir el equilibrio de carga entre los separadores.
 Para transmitir contenido interno a los usuarios de internet.
 Para deshabilitar el acceso a un sitio, por ejemplo cuando un ISP o un gobierno
desea bloquear un sitio web.
Los sitios pueden bloquearse por razones más o menos legítimas. Pueden utilizarse proxies
inversos para impedir el acceso a contenido inmoral, ilegal o protegido por derechos de
autor. A veces estas razones son justificables, pero a veces la justificación es dudosa. Los
proxies inversos a veces impiden el acceso a sitios de noticias donde los usuarios pueden
ver la información filtrada. También pueden impedir que los usuarios accedan a sitios
donde puedan revelar información sobre acciones del gobierno o de la industria. El bloqueo
del acceso a dichos sitios web puede violar los derechos de libertad de expresión.
Más tipos de proxies
Los proxies transparentes se encuentran típicamente cerca de la salida de una red
corporativa. Estos proxies centralizan el tráfico de red. En las redes corporativas, un
servidor proxy está asociado con –o forma parte de un servidor Gateway que separa la red
de las redes externas (normalmente internet) y un firewall que protege la red de la intrusión
externa y permite que los datos sean escaneados para propósitos de seguridad antes de la
entrega a un cliente en la red. Estos proxies ayudan a monitorear y administrar el tráfico de
red, ya que los ordenadores de una red corporativa suelen ser dispositivos seguros que no
necesitan anonimato para tareas típicamente mundanas.
Los proxies anónimos ocultan la dirección IP del cliente, permitiéndoles acceder a los
materiales que están bloqueados por firewalls o evitar las prohibiciones de direcciones IP.
Pueden ser utilizados para mayor privacidad y/o protección contra ataques.
Los proxies altamente anónimos ocultan incluso el hecho de que están siendo utilizados
por los clientes y presentan una dirección IP pública no proxy. Así que no sólo ocultan la
dirección IP del cliente que los usa, sino que también permiten el acceso a sitios que
pueden bloquear servidores proxy. Ejemplos de proxies altamente anónimos incluyen I2P y
TOR.
Los proxies Socks 4 y 5 proporcionan servicio de proxy para datos UDP y operaciones de
búsqueda de DNS, además del tráfico web. Algunos servidores proxy ofrecen ambos
protocolos Socks.
Los proxys de DNS envían solicitudes de servicio de nombres de dominio (DNS) desde
LANs a servidores DNS de internet durante el almacenamiento en caché para una velocidad
mejorada.
Proxy hacking
En la piratería de proxy, un atacante intenta robar los accesos de una página web auténtica
en el índice de un motor de búsqueda y las páginas de resultados de búsqueda. El hacker
proxy tendría un sitio fraudulento o emularía el original o lo que sea que les gustaría
mostrar a los clientes que solicitan la página.
Así es como funciona: El atacante crea una copia de la página web de destino en un
servidor proxy y utiliza métodos como relleno de palabras clave y vinculación a la página
copiada de sitios externos para elevar artificialmente su ranking de motores de búsqueda.
La página auténtica tendrá un rango más bajo y puede verse como contenido duplicado, en
cuyo caso un motor de búsqueda puede eliminarlo de su índice.
Esta forma de hacking también se puede utilizar para entregar páginas con intenciones
maliciosas. El hackeo de proxy puede dirigir a los usuarios al sitio bancario falso, por
ejemplo, para robar información de la cuenta que luego se puede vender o utilizar para
robar fondos de la cuenta. El atacante también puede usar el hack para dirigir a los usuarios
a un sitio infectado con malware para comprometer sus máquinas para una variedad de
propósitos nefastos.
Algunos medios han sido desarrollados para comprometer las habilidades de proxy.
Aplicaciones Flash y Java especialmente diseñadas, Javascript, Active X y algunos otros
complementos de navegador pueden usarse para revelar la identidad de un usuario proxy,
por lo que los proxies no deben usarse en sitios no confiables o en cualquier lugar en el que
el anonimato sea importante.
Los propietarios de sitios web que sospechan que han sido víctimas de un hack proxy
pueden poner a prueba la teoría mediante la búsqueda de una frase que sería casi única en la
identificación del sitio. Su sitio debe ser prominente en la página de resultados del Search
Engine (SERP). Si aparece un segundo sitio con el mismo contenido, puede ser una página
proxy.
Seguridad del servidor proxy
Los servidores proxy en muchas formas mejoran la seguridad, pero como muchas cosas en
la computación pueden ser vulnerables por sí mismos. Para evitar los ataques DoS y la
intrusión en la red, los administradores deben mantener el software actualizado, utilizar
equilibrio de cargas, aplicar autorización y autenticación seguras y bloquear tráfico no
deseado, proxies maliciosos y abiertos.