Source: https://www.scribd.com/document/52220395/PROYECTO-SERVIDOR-DE-CORREO-LINUX-CENTOS
Timestamp: 2017-01-24 22:02:11+00:00

Document:
BrowseInterestsBiography & MemoirBusiness & LeadershipFiction & LiteraturePolitics & EconomyHealth & WellnessSociety & CultureHappiness & Self-HelpMystery, Thriller & CrimeHistoryYoung AdultBrowse byBooksAudiobooksArticlesSheet MusicBrowse allUploadSign inJoinPLATAFORMA DE CORREO SEGURA PROYECTO FORMATIVO – ADMINISTRACIÓN DE SOFTWARESARA MARIA FERNÁNDEZ VALENZUELA ERIKA STEPHANY FRANCO ORTEGA JOHANA CANO HERNÁNDEZ GRUPO: LARED - 38110
INTRODUCCIÓN 1. OBJETIVOS 1.1 Objetivo General 1.2 Objetivo Específico 2. DIAGRAMA DEL SISTEMA 3. CONFIGURACIÓN INICIAL 4. INSTALACION Y CONFIGURACION SERVICIO DE CORREO POSTFIX (MTA) 4.1 Pruebas locales con el servidor de Correo Postfix 4.2 Instalación y configuración Cliente (MUA) Mozilla Thunderbird 5. INSTALACION Y CONFIGURACION LDAP (SISTEMA DE DIRECTORIO) USUARIOS VIRTUALES 5.1 Instalación y configuración LdapSoft (Administración grafica del LDAP) 5.2 Agregar esquema en el LDAP 5.3 Integración Postfix – LDAP 6. INSTALACIÓN DOVECOT Y SISTEMA DE ALMACENAMIENTO MAILDIR 7. INSTALACIÓN DEL SERVIDOR DE SOLUCIÓN DE NOMBRES DE DOMINIO DNS 8. INSTALACION ESTANDAR DE AUTENTICACIÓN Y AUTORIZACIÓN SASL 8.1 Configuración del cliente SASL 9. INSTALACION Y CONFIGURACIÓN DE LA TÉCNICA DE CIFRADO TLS 9.1 Configuración del cliente TLS 10. INSTALACIÓN Y CONFIGURACIÓN DEL SERVICIO WEBMAIL (APACHE) 11. INSTALACIÓN Y CONFIGURACIÓN DE LA TÉCNICA DE CIFRADO SSL 12. MARCO TEÓRICO 13. DIFICULTADES PRESENTADAS DURANTE EL PROCESO 14. CONCLUSIONES BIBLIOGRAFIA
La implementación y configuración de un Servicio de Correo Seguro dentro de la infraestructura de red de una determinada empresa requiere de una serie de parámetros y protocolos de servicios que constituyan y fomenten el desarrollo y funcionamiento en su totalidad; de modo que logre así emplear de forma diligente todos los recursos de los cuales dispone destinados al uso de cada uno de los usuarios que la requieran. La configuración y administración de este tipo de servidor cumple un papel muy importante en aquellas organizaciones que están integradas y comprenden varias sedes de trabajo para la comunicación entre los diferentes usuarios por medio del envío y recepción de correos de forma segura y confidencial de los destinatarios. Además de esto, la aplicación del servicio contiene características de disponibilidad e integridad con el fin de mantener la información almacenada disponible en todo momento y garantizar que ésta no será modificada por terceros. En el Siguiente informe se explicará de forma clara y precisa los procedimientos realizados durante la configuración del Servidor de Correo utilizando un Sistema de Directorio (LDAP) para mantener el registro de todos los usuarios que harán uso de dicho servicio por medio de una cuenta de correo utilizando un dominio determinado. De igual manera se define y explica con precisión la utilización de métodos para hacer redundancia de datos con el propósito de evitar pérdidas y mantener una copia de todo lo relacionado con el servidor. Se realizó con la mayor creatividad e interés posible para que el lector lo disfrute completamente.
1.1 Objetivo General Desarrollar competencias en las áreas técnicas de correo electrónico, monitoreo de servicios de red y redundancia de datos; además de fortalecer en los aprendices un sentido de responsabilidad y ética en la metodología de trabajo. 1.2 Objetivos Específicos  Utilizar tecnologías para la protección de datos que permitan realizar el almacenamiento de la información por medio de mecanismos redundantes, así como la implementación de un sistema automatizado de Backup para prevenir una caída inesperada del Servidor de Correo en funcionamiento.  Practicar y conocer el proceso de funcionamiento de almacenamiento, envío y recepción de correos electrónicos entre el cliente y el servidor con el fin de mejorar el proceso de aprendizaje y tener un conocimiento más completo para el desarrollo de competencias a nivel laboral.
2. DIAGRAMA DEL SISTEMA
3. CONFIGURACION INICIAL Como primer paso debemos actualizar completamente nuestro sistema con el comando yum update para que cuando descargos los paquetes necesarios para cada uno de los servicios, podamos obtener los que necesitemos para que no hallan fallas.
4. INSTALACION Y CONFIGURACION SERVICIO DE CORREO POSTFIX (MTA) Para la instalación y configuración del servidor de correo POSTFIX, utilizaremos una maquina virtual con un Sistema Operativo CentOS que es una distribución de Linux. Y teniendo la maquina nos dirigimos a la terminal de la misma y nos logeamos como súper usuario (root) para tener todos los privilegios y así poder configurar todos los requerimientos necesarios, ya estando como este usuario con el comando dhclient pedimos una dirección IP verificando a la vez que nuestra maquina se encuentre en RED INTERNA.
Con el comando yum search postfix, vamos a buscar el paquete necesario para instalar el MTA o servidor de correo en la maquina.
Debemos tener en cuenta que para esta distribución de Linux ya viene previamente instalado un servidor de correo (MTA) llamado SENDMAIL, y con el comando netstat –antp verificamos en número de puerto al cual está asociado el servicio, el nombre del servicio, entre otra información; en este caso por el puerto 25 (Servidor de correo “postfix”) está corriendo el sendmail. Es muy importante tener en cuenta que no pueden correr dos MTA a la vez ya que existirá un conflicto porque el servidor de correo no sabrá cual es el principal que debería funcionar.
Para verificar que efectivamente el sendmail esta corriendo, podemos ejecutar el comando ps – e, el cual nos muestra el nombre del proceso que esta activado y el numero que lo identifica. En la siguiente imagen podemos observar el sendmail con su respectivo identificador.
Con el comando alternatives –display mta, obtenemos información acerca del estado del servidor MTA (quien esta encargado del MTA), y cuál de los dos existentes esta como predeterminado o principal.
Con el comando alternatives –config mta, configuraremos el postfix como servidor principal. Estando allí nos muestran los dos servicios disponibles, para este caso editamos el número 2 que el que corresponde al postfix y damos Enter.
Nuevamente editamos el comando netstat –antp para verificar que en el puerto 25 esté corriendo el servidor postfix y podemos observar que efectivamente está corriendo el servicio con el nombre master que es el nombre con el cual se está identificando el postfix.
Con el comando ps –e grep master, podemos verificar esta información más exactamente.
El archivo de configuración principal del postfix se encuentra en /etc/postfix/main.cf, al cual ingresaremos con un editor de texto que en este caso en nano para editar las líneas que necesitamos configurar en el servidor para el debido funcionamiento.
En la siguiente línea especificamos el nombre que tiene la maquina del servidor del correo con el respectivo dominio (lared.lab), este parámetro es utilizado por defecto y es necesario para identificar tanto el host como el dominio.
La próxima línea especifica el nombre del dominio principal con el cual trabajara el servidor de correo postfix (lared.lab) para el funcionamiento en general.
La siguiente línea significa que el origen o destino de los correos va a hacer el dominio del postfix (lared.lab).
En la próxima opción nos dice que el servidor va a escuchar por todas las interfaces de red (inet_interfaces = all), para tener conexión a todos los equipos ya sean clientes finales u otros servidores MTA.
El próximo parámetro nos permite editar la direccion de red dentro de la cual va a estar incluido el servidor de correo, tambien podemos especificar la direccion de loopback para cualquier conexión o prueba local.
Ya terminada esta configuración, procedemos a guardar la configuración realizada para que los cambios tomen efecto (Ctrl + o (Guardar) Ctrl + x (Salir)).
Recordemos que en el anterior archivo de configuración especificamos que el nombre de host era mail, como siguiente paso cambiaremos el nombre de la maquina en la ruta que aparece subrayada en la próxima imagen. Con el comando hostname podemos verificar el nombre que tiene el equipo actualmente.
Estando dentro del archive de configuración nos dirigimos a la línea que dice HOSTNAME y cambiemos el nombre que allí aparece por defecto (localhost) por el que elegimos colocarle a nuestra maquina, en este caso “mail”.
Como siguiente paso con el comando hostname verificamos que efectivamente el nombre de la maquina a cambiado, y como podemos observar en la imagen efectivamente cambio a mail.
4.1 Pruebas locales con el servidor de Correo Postfix Las siguientes pruebas de correo las realizaremos con usuarios del sistema, estando en la terminal ejecutamos los comandos que aparecen a continuación para enviar un correo al usuario Johana, con el comando tail var/log/maillog verificamos que el correo se ha removido de la cola (spool) y en la ruta cat /var/spool/mail/johana mbox podemos observar el contenido del correo recibido.
En la siguiente imagen podemos observar los usuarios que se encuentran actualmente en el sistema, con el comando useradd se agregan usuarios y con la opción –p les podemos dar un password.
Ahora realizaremos otra prueba local con el usuario Sara ejecutando el mismo comando para enviar el respectivo correo, y verificamos en la cola de los correos si efectivamente fue removido.
Nos dirigimos nuevamente a la ruta en la cual podemos visualizar los correos de cada uno de los usuarios, recordemos que en este punto los correos se están entregando en modo Mailbox (mbox) para todos los usuarios, y como podemos ver en la imagen el correo de entrego correctamente.
Podemos visualizar que el correo nos dice a quien va dirigido (To), el asunto (Subject), el identificador del mensaje (Messaje - Id), la fecha en la cual fue enviado el correo (Date), el origen del mensaje (From) y el mensaje como tal.
Para verificar que efectivamente el correo ha llegado, nos dirigimos al explorador e iniciamos sesión en Erika, y como podemos observar en las siguientes dos imágenes el correo llego exitosamente a otro dominio.
4.2 Instalación y configuración Cliente (MUA) Mozilla Thunderbird Como primer paso debemos descargar este software ingresando al navegador web y editamos Thunderbird para ingresar a la página oficial, damos clic en la primera opción.
Inmediatamente nos aparece la página de la cual podremos descargar el software de forma segura, damos clic Descarga gratuita.
Nos aparece una ventana en la cual elegimos la opción para guardar o ejecutar de una vez el software, en este caso daremos clic en Guardar y esperamos a que finalice la descarga del archivo.
Al terminar la descarga, nos aparece una ventana y damos clic en Ejecutar para que iniciemos la instalación de la aplicación.
Esperamos a que todos los archivos necesarios sean extraídos.
Nos aparece un asistente para la instalación mostrando un mensaje de bienvenida y una recomendación, para continuar damos clic en Siguiente.
En el próximo asistente debemos seleccionar el tipo de instalación (Estándar o Personalizada), en este caso elegiremos la instalación estándar con las opciones más comunes que tiene Thunderbird y dejamos la opción para dejar la aplicación como correo por defecto, damos Siguiente.
En el siguiente asistente nos dan un resumen y la ruta en la cual se instalara el software, para continuar damos clic en Instalar.
Esperamos a que el proceso de instalación termine
Al terminar la instalación dejamos la opción para ejecutar Thunderbird y damos clic en Finalizar.
Para que el cliente se pueda conectar con el servidor y le podamos dar la función de recibir y almacenar los correos de cada uno de los usuarios que se encuentran incluidos en el servicio de correo; para ello debemos configurar la máquina con un direccionamiento IP que se encuentre en el mismo rango del servidor, ingresamos a Inicio – Panel de control – Conexione de red.
Estando allí, nos aparece el Adaptador de red y damos clic derecho – Propiedades.
Nos aparece una ventana en la cual seleccionaremos Protocolo de Internet (TCP/IP) y damos clic en Aceptar.
Al momento nos aparece otra ventana en la cual debemos configurar la dirección IP con la respectiva máscara y el Gateway predeterminado.
Ahora vamos a verificar que nuestra maquina tenga la dirección IP correctamente.
Cuando nos aparezca el símbolo del sistema, verificamos que efectivamente la maquina tiene la dirección IP asignada anteriormente con el comando ipconfig, y como podemos observar la dirección se encuentra bien configurada.
Otro parámetro que debemos tener en cuenta para la conexión entre las dos maquinas es que se encuentren dentro de la misma red, para este caso vamos a poner las maquinas en Red Interna ingresando a los adaptadores de red de Virtual Box para la respectiva maquina virtual.
Para que a nuestro cliente le puedan llegar los correos del servidor, debemos configurar una regla en el Firewall, la cual permita la conexión y comunicación entre las dos maquinas, para ello ingresamos a Inicio – Panel de control – Control de seguridad.
Estando en la configuración del Firewall damos clic en Comprobar configuración para hacer la respectiva regla.
Nos aparece una ventana en la cual podemos visualizar si el Firewall esta activado o desactivado, como siguiente paso damos clic en la opción que se encuentra en la parte superior Opciones avanzadas.
Estando allí damos clic en Configuración de ICMP, que es el paquete que necesitamos que ingrese en esta máquina cliente.
En la siguiente ventana podemos configurar las reglas necesarias en el Firewall, en este caso únicamente seleccionaremos la regla de permitir la solicitud de eco entrante (PING), también nos explican un poco acerca de este protocolo y damos Aceptar.
Para comprobar que esta regla está en funcionamiento, nuevamente ingresamos al símbolo del sistema en Inicio – Accesorios – Símbolo del sistema, estando allí ejecutamos el comando ping con la dirección IP respectiva la servido y cómo podemos ver efectivamente están comunicados.
Habiendo hecho lo anterior, ahora pasamos a probar el Thunderbird, damos clic en el acceso directo que quedó en el escritorio o en Inicio - Todos los programas, estando en la aplicación inmediatamente debemos configurar una cuenta principal con un usuario que se encuentre agregado en el servidor; debemos ingresar el nombre del usuario, el correo electrónico, la contraseña y damos Continuar. Debemos ejecutar este mismo procedimiento para agregar todas las cuentas existentes.
Aquí, la aplicación debe comprobar la cuenta del usuario con el servidor y como todavía no tenemos un servidor con un nombre especificado debemos configurarlo manualmente, damos clic en Configuración manual…
Nos aparece una ventana, elegimos la cuenta que estamos configurando y damos clic en Configuración del servidor, allí editaremos la dirección IP de nuestro servidor de correo electrónico y verificamos que el puerto del protocolo POP3 se encuentre especificado.
En la configuración del protocolo SMTP, debemos establecer el dominio predeterminado, para este caso será lared.lab.
Previamente hemos configurado la autenticación para el protocolo IMAP y POP3, es por ello que cuando ingresamos a la aplicación y deseamos ver nuestros correos debemos ingresar la respectiva contraseña a cada una de las cuentas para visualizar los correos que han sido enviados.
Y como podemos observar la cuanta del administrador ha recibido los correos que le han enviado.
Damos doble clic en el correo recibido y podemos leerlo en una ventana que aparece a continuación.
Estando todas las cuentas agradas, vamos a enviar un correo de un usuario a otro, para ello debemos configurar la dirección del servidor SMTP para cada uno de los usuarios, ingresamos nuevamente a la configuración de la cuenta principal y la editamos colocando una descripción, la dirección IP del servidor y verificar que el puerto este correctamente (25). Este procedimiento lo debemos realizar para cada una de las cuentas de usuario que se encuentren en la aplicación.
Como siguiente paso vamos a enviar un correo de prueba de una cuenta de usuario a otra con un destinatario especificado, un asunto y el mensaje, para ello damos clic en Redactar en la interfaz principal de Thunderbird.
Ahora nos dirigimos a la respectiva cuneta a la cual se le ha enviado el correo y damos clic en Recibir y vemos que efectivamente ha recibido un correo del Administrador.
Damos doble clic en el correo y por consiguiente lo podremos visualizar en una ventana con todos los detalles.
También podemos hacer pruebas enviando un correo a otro dominio diferente que no sea el que estamos imprentando (lared.lab), para eso desde cualquier cuenta de usuario enviaremos un correo a erifra@misena.edu.co con un asunto y un mensaje especifico, después damos clic en Enviar.
Ahora ingresamos al pagina de misena.edu.co y editamos le usuario y la contraseña del usuario perteneciente a este dominio y damos clic en Acceder.
Efectivamente el correo ha llegado en la carpeta de Spam, ya que para el envió de correos desde otra parte que no sea estando en la red local del SENA, algunos dominios no están permitidos; pero con esto hemos probado que el servidor de correo está funcionando correctamente.
Aquí podemos visualizar el correo y le podemos dar clic en Mostar detalles para que nos muestre todos los datos importantes.
5. INSTALACION Y CONFIGURACION LDAP (SISTEMA DE DIRECTORIO) USUARIOS VIRTUALES Para la instalación y configuración de este servicio, debemos buscar en los repositorios el paquete del mismo con el comando yum search openldap. Después de esta búsqueda, ya encontrado el paquete procedemos a instalarlo como se muestra en la siguiente imagen.
Antes de ingresar a este archivo, vamos a generar el password para el admin del LDAP con el comando slapasswd + password, el cual me permitirá generar una salida inteligible para un password escrito en texto plano y este mismo se especificara en el archivo de configuración del servidor como mecanismo de autenticación.
Ya terminado esto ingresamos al archivo de configuración con un editor de texto, en este caso vim y empezamos a editar el suffix que es el DN padre y el rootdn que es el DN Admin LDAP como se muestra en las siguientes imágenes.
En la siguiente línea vamos a poner el password del Admin LDAP encriptado que generamos anteriormente, damos ESC y editamos: x para salir del editor y guardar
Para solucionar este problema haremos la copia respectiva de esta base de datos ingresando a la ruta /etc/openldap/DB_CONFIG.example al directorio /var/lib/ldap y renombramos la base con el nombre DB_CONFIG. Después reiniciamos nuevamente el servicio ldap y vemos que este error ya no aparece porque ye esta leyendo la base de datos del servicio.
Con el comando netstat –antp podemos verificar que el puerto correspondiente al LDAP (389) esta corriendo, esto lo podemos visualizar en la siguiente imagen.
Ahora vamos a crear la base principal del LDAP para poder administrarla desde un entorno grafico, para ello vamos a crear un archivo con una extensión .ldif con unos parámetros específicos en la siguiente ruta /tmp/ y con un editor de texto anexaremos la sintaxis correspondiente.
Lo siguiente es la base de la arquitectura con la cual vamos a trabajar para los usuarios que están anexos al servidor de correo, en la cual especificamos el dominio, la clase de objeto (dc, o = Organización, entre otros) y otras sentencias, terminado esto damos ESC y editamos :x.
Ahora, como siguiente paso añadimos este archivo al servidor de LDAP, para ello debemos estar en la ruta donde se encuentra el archivo, debemos especificar el nombre del mismo, el dominio, la opción –x es porque aun no estamos implementando seguridad y la opción –W es para que nos pida el password configurado en los pasos anteriores, en la siguiente imagen se muestra el comando con el cual debemos subir este complemento.
5.1 Instalación y configuración LdapSoft (Administración grafica del LDAP) Existen múltiples software de administración para el servicio del LDAP, pero en este caso vamos a implementa uno llamado LdapSoft. Para ello ingresamos a un explorador y buscamos la página oficial de este administrador, nos dirigimos al professional Edition y damos clic en DOWNLOAD de Linux de 32 bits.
Ahora vamos a ejecutar el instalador del paquete estando parados en la misma ruta, con la opción ./ + nombre del archivo, e inmediatamente nos aparece un asistente de instalación.
Este próximo asistente nos muestra la carpeta de destino en la cual se guardaran todos los archivos del LDAP Admin Tool Professional y después damos Siguiente para continuar.
Cuando termina el proceso, nos aparece el último asistente y damos clic en Finalizar.
Terminada la instalación, nos dirigimos al menú de tareas Aplicación – Ldap Admin Tool – Ldap Admin Tool, al instante nos aparece la siguiente ventana y damos clic en New conecction. Tambien aparecen otras herramientas que podemos utilizar implementar.
Inmediatamente nos aparece un asistente en el cual debemos editar el nombre de la conexión, el nombre o la dirección IP del servidor, el puerto y la versión del LDAP, verificamos los datos y si todo está correctamente configurado nos aparece Successfull y damos Siguiente.
Ahora especificaremos como será la autenticación del usuario que tiene privilegios sobre el LDAP, en este caso es simple y editamos el Bind DN con el password respectivo al Ldap; validamos las credenciales y damos Next.
5.2 Agregar esquema en el LDAP Este esquema lo necesitamos porque trae atributos como mail, mailenable, entre otros. Este esquema se encuentra dentro de paquete mmc-agent-2.3.2 en la siguiente ruta: contrib > ldap > mail.schema. Después de saber cuál es el esquema debemos de añadirlo al LDAP, hacemos una copia del esquema mail.schema al directorio donde el ldap aloja todos sus esquemas.
5.3 Integración Postfix - LDAP Debemos crear un usuario llamado vpostfix, el cual es el encargado de guardar los mensajes de los usuarios virtuales. Verificamos su UID y GID visualizando con el comando “cat” el archivo /etc/passwd.
Debemos ingresar al archivo de configuración de postfix main.cf y agregar las siguientes líneas. Cada una de las sentencias especifica lo siguiente:      Virtual_mailbox_domains = Le notifica a postfix que lared.lab, es el llamado buzón de correo del dominio virtual, Virtual_mailbox_base = Especifica un prefijo para todas las rutas de acceso de buzón virtual. Evita que el correo sea entregado a todo el sistema de archivos. Virtual_mailbox_maps = Es el índice por la dirección de correo virtual, nombra la tabla de búsqueda de los buzones. Virtual_uid_maps = Virtual_gid_maps = Parámetros que indican que todos los buzones son propiedad de un uid y un gid fijo. Virtual_minimun_uid = Límite inferior en el buzón Maildir del propietario UID.
El archivo virtual_ldap.conf está compuesto por las siguientes líneas:       Start_tls = Implementación de TLS. Search_base = Base donde se van a hacer las consultas al LDAP de los usuarios. Query_filter = Atibutos a los cuales pertenecen los usuarios; clase de objeto. Result_attribute = Atributo de almacenamiento para los correos. Result_format = Forma en que se van a almacenar los correos a través del método Maildir. Bind = Utilización de DNS.
Finalizado el procedimiento presionamos la tecla “ESC, Shift + : +” x para salir y guardar el archivo de configuración con los cambios efectuados. REINICIAMOS EL SERVICIO POSTFIX PARA QUE LOS CAMBIOS SEAN EFECTUADOS (/etc/init.d/postfix restart)
6. INSTALACIÓN DOVECOT Y SISTEMA DE ALMACENAMIENTO MAILDIR Para la instalación y configuración del Servidor Dovecot el cual será el encargado de manejar los protocolos POP3 e IMAP para la entrega de los correos electrónicos a sus respectivos destinatarios se realiza el siguiente procedimiento: Buscamos el nombre del paquete “dovecot” dentro de los repositorios que estamos utilizando el cual se encuentra especificado como dovecot.i386 y lo instalamos dando esta misma sentencia. A continuación damos “y” para aceptar la instalación de dicho paquete.
Si el paquete es instalado completamente con todas sus dependencias necesarias para ser ejecutado, al final de la instalación nos aparecerá el mensaje “Complete!” con la lista de los diferentes paquetes instalados.
Luego de realizar el anterior procedimiento, nos dirigimos a verificar los archivos de configuración de los cuales podremos hacer uso para su modificación; aquí podremos ver e archivo principal “dovecot.conf”:
Ingresamos al archivo de configuración principal del Dovecot “dovecot.conf”para realizar las respectivas modificaciones que permitan habilitar los protocolos POP3 e IMAP, así como integrar dicho servicio con el MTA (Postfix) y el LDAP. Para ello utilizamos un editor de texto como nano, vim, entre otros.
Ya estando en el archivo de configuración empezamos por descomentar la línea “protocols” la cual indica el tipo de protocolos que se van a utilizar para el recibo de correos por parte del destinatario; para este caso solo utilizaremos POP3 e IMAP. NOTA: Para insertar texto con el editor vim utilizamos la tecla “i”.
A continuación definimos para cada uno de los protocolos el puerto respectivo por el que va a estar trabajando especificando que para todas las direcciones “*” va a escuchar por el puerto 143 (IMAP) y 110 (POP3); además el protocolo IMAP utilizará la autenticación por SSL a través de su respectivo socket lo que se explicará más adelante.
La siguiente línea “syslog_facility” la descomentamos y especificamos que en la ruta donde son registrados los logs del servicio mail también serán especificados los del dovecot (/var/log/maillog).
La línea mail_location indica la dirección donde están alojados los buzones de los usuarios a partir del sistema de almacenamiento Maildir; éstos serán guardados en el directorio /home/vpostfix/%u (usuario)/Maildir.
La sentencia auth_default específica el método de autenticación que utilizaran los usuarios para recuperar los correos del buzón alojando varios parámetros como lo son:  Mecanisms: Método de autenticación que se va a utilizar, en este caso será plana (plain).  Passdb pam: Indica que los usuarios que tomará el dovecot serán los del sistema; como los usuarios que estamos utilizando son virtuales a través del LDAP comentamos esta línea.  Passdb ldap: Especifica la ruta donde se encuentra el archivo que se integra con el LDAP para conocer cuales con los usuarios y sus respectivas contraseñas; en este caso consultaría por el password de los usuarios.  Userdb passwd: Esta línea se utiliza para definir que el dovecot utilizará los usuarios del sistema ubicados en el archivo passwd, para este caso comentamos no utilizaremos dicho parámetro ya que el servicio de correo usará usuarios virtuales.  Userdb ldap: Especifica cuál es el archivo que contestara por los usuarios virtuales a través del Servicio de Directorio LDAP.  User: Identifica el usuario principal que tendrá acceso a la base de datos de los usuarios con sus respectivos passwords, éste será el ROOT (Súper usuario).
Especificados los anteriores parámetros, presionamos la tecla “ESC, Shift + : +” x para salir y guardar el archivo de configuración con los cambios efectuados.
A continuación procedemos a crear en el directorio /etc el archivo de configuración que integrará al DOVECOT con el LDAP denominado “dovecot-ldap.conf”. En la siguiente ruta de los documentos de dovecot podremos encontrar un ejemplo de éste archivo el cual lo copiaremos a dicho directorio de forma recursiva especificando su respectivo nombre.
Ahora procedemos a ingresar a dicho archivo de configuración por medio de un editor de texto como nano, vim, entre otros.
Ya estado dentro de éste configuramos las líneas que son específicas para integrar ambos servicios. Los parámetros a establecer son las siguientes:
 Host = Identifica la dirección IP del servidor LDAP, como éste se encuentra alojado localmente la dirección específica es la de loopback (127.0.0.1) o también puede utilizarse la dirección estática (192.168.1.2).  Sasl_bind = Especifica si el servicio va a trabajar con SASL. Para este caso no utilizaremos autenticación para el envío de correos.  Tls = Indica si se va a trabajar con el protocolo de Seguridad de la Capa de Transporte (TLS).  Auth_bind = Utilización de autenticación básica.  Auth_bind-userdn = Ruta en el LDAP donde se encuentran los usuarios que se van a autenticar (cn=%u, ou=Usuarios, dc=lared, dc=lab).  Ldap_version = Versión del LDAP con la cual se está trabajando, en este caso versión 3.  Base = Raíz que abarca todos los parámetros (dominio).  User_filter = Requerimientos que deben tener los usuarios para que puedan ser válidos, en este caso el usuario debe pertenecer a una clase de objeto llamada mailAccount y debe tener un UID definido.  Pass_attrs = Parámetro que especifica que la contraseña está definida por el atributo userPassword y que el usuario debe ser reconocido por el UID (Identificador del Usuario)  Pass_filter = Filtro de búsqueda para el password de cada uno de los usuarios en el LDAP.  User_global_uid = Identifica el usuario local (dueño de los usuarios virtuales) que tiene los permisos para ejecutar tareas de búsqueda para cada filtro.  User_global_gid = Grupo local que posee los permisos globales para realizar los filtros de búsqueda en el LDAP y establecerlos en el dovecot.
Realizado el anterior procedimiento configurando las respectivas líneas, ahora presionamos “ESC + Shift + : + x” para guardar y salir e inmediatamente reiniciamos el servicio de dovecot lo cual definirá si no hubieron errores en la configuración. Para ello utilizamos el comando /etc/init.d/dovecot restart y vemos que efectivamente el servicio subió correctamente.
Como siguiente paso nos dirigimos a configurar el método de almacenamiento (Maildir) en el archivo de configuración del MTA POSTFIX. Abrimos este con el editor de texto vim el archivo principal main.cf.
Procedemos a descomentar la línea home_mailbox = Maildir/ para indicarle al servidor que el almacenamiento se dará por medio del método Maildir. Damos “ESC + Shift + : + x” para guardar y salir.
Continuamos reiniciando el servicio de postfix para actualizar los cambios y nos dirigimos a verificar los puertos que tenemos escuchando en nuestra máquina.
Utilizamos el comando netstat el cual muestra un listado de las conexiones activas del ordenador, tanto entrantes como salientes a partir de las opciones: -a (Muestra todos los sockets (por defecto únicamente los que están en modo conectado)), n (Se muestran los puertos con su identificación en forma numérica), t (Conexiones TCP), p (Muestra PID o nombre del programa por cada socket). Efectivamente se encuentran habilitados los puertos 110 (POP3) y 143 (IMAP) en el dovecot.
Para probar el correcto funcionamiento del servicio de dovecot utilizando los puertos ya establecidos anteriormente para la entrega de correos electrónicos al destinatario enviaremos un correo aplicando la siguiente sentencia “mail –s “Prueba usuarios virtuales” (Asunto) administradorlared.lab (Destinatario)” y escribimos el mensaje, con “. + ENTER” finalizamos el mensaje. Luego verificamos los logs para asegurarnos de que el mensaje fue enviado y removido al buzón de correo Maildir.
Como siguiente paso nos dirigimos al buzón del usuario Administrador almacenado a través de Maildir ubicado en /home/vpostfix/administrador/Maildir/new; con el comando cat podremos visualizar el mensaje. El directorio cur almacena una copia de los mensajes recibidos y el tmp copia de los correos leídos temporalmente.
Ahora como último paso procedemos a verificar con el comando “postmap” la forma como el SERVIDOR POSTFIX está almacenando los correos a través del método MAILDIR ya configurado. La sentencia de dicho comando especifica una consulta (q) para un determinado usuario (sara@lared.lab) y el archivo de filtro que integra al Postfix con el LDAP para el uso de los usuarios virtuales (ldap:/etc/postfix/virtual_ldap.conf).
7. INSTALACIÓN DEL SERVIDOR DE RESOLUCIÓN DE NOMBRES DE DOMINIO DNS Los requisitos principales para instalar y configurar el Servidor DNS (Servidor de Resolución de Nombres de Dominio) nos dirigimos al menú principal de nuestra máquina CentOS – Sistema – Administración – Red. Para configurar el sysmem-config-network debemos especificar la contraseña como super usuario y dar clic en Aceptar para validarla contra el sistema. Luego de esto se abrirá una ventana la cual nos mostrará las tarjetas de red que tenemos disponibles y las cuales podemos modificar (Para nuestro caso tenemos dos tarjetas de red de las cuales una se encuentra en NAT para la descarga de paquetes y otra en RED INTERNA para la conexión con el cliente MUA); en este caso seleccionamos la pestaña DNS donde configuraremos el Nombre del host que va a tener dicho servicio (en este caso el servidor será alojado localmente; es decir será el host mail) y la dirección IP del servidor DNS primario (192.168.1.2) para la resolución de nombres. Cerramos la ventana y damos “Sí” para guardar los cambios.
Ahora nos dirigimos a la Terminal y desde allí vamos al archivo de configuración de la tarjeta de red utilizando el editor de texto vim /etc/sysconfig/network-scripts/ifcfg-eth0.
Estando allí configuramos y establecemos la dirección IP estática que identificará al servidor MTA – DNS, la máscara de subred y la puerta de enlace predeterminada. Damos “ESC + Shift + : + x” para guardar y salir.
Procedemos a reiniciar el servicio de network para que se activen las tarjetas de red con las configuraciones establecidas y con el comando ifconfig verificamos que estas estén especificadas correctamente en el sistema (eth0: RED INTERNA; eth1: NAT; lo: LOOPBACK).
Para iniciar la instalación del Servidor DNS instalamos los siguientes paquetes que se encuentran en los repositorios que estamos utilizando para la máquina. Con el comando yum install y los paquetes especificados los añadimos a los servicios a utilizar en nuestra máquina, damos “y” para aceptar la instalación.
Finalizada la instalación nos aparecerá un mensaje indicando que ésta se ha completado satisfactoriamente junto con los paquetes y servicios especificados.
Realizado el procedimiento anterior adecuadamente, nos dirigimos al directorio principal (/var/named/chroot) del servicio named (DNS). Dentro de éste se destacan dos directorios (var: Posee los archivos de configuración para especificar las zonas; etc: Contiene los achivos de configuración para la creación de cada una de las zonas y la habilitación del puerto correspondiente a dicho servicio “53”). Ingresamos al directorio /var del cual realizaremos una copia del archivo localdomain.zone a localdomain.zone.directa (zona directa) así como de named.local a named.local.inversa (zona inversa). Ambas copias las realizamos de forma recursiva. Damos ls para listar los archivos del directorio y verificar que cada archivo fue duplicado correctamente.
A continuación utilizando el editor de texto vim ingresamos al archivo que usaremos para nuestra zona directa “localdomain.zone.directa”.
Ya estando dentro del archivo procedemos a modificar la zona de acuerdo a las características que ésta va a tener en nuestro servidor DNS. Añadimos el registro SOA (Autoridad) que en este caso será mail.lared.lab. y root.lared.lab.; se especifica el registro NS (mail.lared.lab.), el registro MX con un número de prioridad que será 10 (Nivel principal) y el nombre de dominio FQDN mail.lared.lab., un registro tipo A para la resolución directa (Nombre de Dominio a IP) relacionado con el nombre del host (mail) y un segundo registro A en caso de que nuestro servidor MTA se encuentre alojado en otra máquina (remotamente) la resolución primero encuentre la dirección del servidor DNS. Damos “ESC + Shift + : + x” para guardar y salir.
Ahora pasamos a modificar el archivo de configuración para la zona inversa “named.local.inversa”.
En dicho archivo añadiremos igualmente el registro SOA correspondiente al servidor y el NS. Para especificar la resolución inversa (IP a Nombre de Dominio) ingresamos un registro tipo PTR definido por la porción de host de la dirección IP de la máquina (2) y el nombre FQDN de la misma (mail.lared.lab.). A continuación damos “ESC + Shift + : + x” para guardar y salir.
Ya configuradas las zonas nos dirigimos al directorio /var/named/chroot/etc, damos ls para listar los archivos alojados en dicho directorio y luego pasamos a especificar (crear) las zonas de acuerdo a su tipo de resolución (directa – inversa). Antes de configurar el archivo correspondiente hacemos una copia de seguridad del mismo (named.rfc1912.zones a zones) de forma recursiva. Damos ls para verificar que la copia fue exitosa.
Procedemos a abrir el archivo de configuración con un editor de texto, en este caso vim.
En dicho archivo registraremos las zonas que vamos a utilizar y que se encontrarán enlazadas con los archivos que contienen los registros de resolución. Definimos la zona directa por medio del dominio y la zona inversa por la porción de red de la dirección IP del servidor; indicamos que el servidor será maestro (principal), el nombre del archivo que contiene cada zona (localdomain.zone.directa – named.local.inversa) y especificaremos que dichas zonas no tendrán actualizaciones dinámicas. A continuación damos “ESC + Shift + : + x” para guardar y salir.
Dentro del mismo directorio identificamos el archivo named.caching-nameserver.conf en el cual realizaremos configuraciones generales para dicho servicio como lo son el puerto por el cual va a escuchar, las direcciones IP y la ruta del archivo del cual leerá las zonas para hacer las respectivas resoluciones. Utilizamos el editor de texto vim.
Especificamos las direcciones IP por las cuales va a escuchar el servicio (127.0.0.1 – 192.168.1.2) y el puerto “53”; además indicamos que todas las preguntas de resolución que se hagan estarán activas localmente y para todos (any) los equipos que se encuentren conectados a éste servidor y requieran de dicho servicio DNS. Podemos identificar la ruta del archivo que tomara el DNS para la resolución de zonas (include /etc/named.rfc1912.zones) el cual fue configurado anteriormente.
Como siguiente paso nos dirigimos a configurar el archivo /etc/resolv.conf el cual indicara la búsqueda del servidor al cual va a realizar Resoluciones de Nombres de Dominio y la IP del mismo. Podemos utilizar el editor de texto vim, nano entre otros para ingresar y modificar éste archivo.
De acuerdo a lo que se muestra en la siguiente imagen, indicamos el nombre de dominio de búsqueda (lared.lab) y el nombre del servidor definido por la dirección IP del mismo (192.168.1.2). Damos “ESC + Shift + : + x” para guardar y salir.
Es de gran importancia verificar que el usuario propietario y grupo propietario de los archivos que definen las zonas y los registros de resolución deben ser propiedad del usuario y el grupo named para que sean ejecutados como éste. Con el comando chown named:named cambiaremos estos privilegios a la zona directa e inversa. Damos ls para listar los archivos y comprobar que el cambio se dio correctamente.
Procedemos a reiniciar el servicio named con el comando /etc/init.d/named restart y si ésta se a efectuado correctamente verificamos los puertos que están escuchando en el servidor. Como podemos observar el puerto 53 está habilitado a partir del servicio named.
A continuación verificamos que el SERVIDOR DNS (NAMED) se encuentre funcionando correctamente. Para ello utilizamos el comando nslookup para hacer las respectivas resoluciones; indicamos el servidor que estamos utilizando para realizar dicha tarea (server 192.168.1.2) y resolvemos con el nombre de dominio (mail.lared.lab), la dirección IP (192.168.1.2) y el nombre del host (mail). Vemos que efectivamente el servidor nos está respondiendo a dichas peticiones.
8. INSTALACION ESTANDAR DE AUTENTICACIÓN Y AUTORIZACIÓN SASL Para la instalación y configuración del estándar de autenticación y autorización (SASL) que permitirá validar a los usuarios contra la base de datos (LDAP) y verificar a su vez que éste se encuentre en la unidad organizativa de la misma con un atributo de autenticación. En primer instancia verificamos el tipo de servicio (Integrado por los portocolos POP3 e IMAP) que soporta dicha técnica a partir del comando postconf –a (Para listar todos los servicios). Como podemos ver en la imagen éste mecanismos de autenticación es soportado por CYRUS y DOVECOT que en nuestro caso es el servicio que estamos utilizando.
Ingresamos al archivo de configuración principal del servicio DOVECOT ubicado en el directorio /etc/. Con un editor de texto en este caso “vim” abrimos el archivo dovecot.conf.
Ya estando dentro de éste archivo de configuración buscamos las líneas que aparecen en la imagen:  Auth default: Específica el método de autenticación que utilizaran los usuarios para recuperar los correos del buzón alojando varios parámetros como lo son:  Mecanisms: Método de autenticación que se va a utilizar, en este caso será plana pero requerirá de un login (password) para ser validada (plain login).  Socket listen: Parámetro que define cual es el canal de comunicación que se va a emplear para la autenticación. En este caso la autenticación se hará del lado del cliente a la hora de enviar un correo, entonces se debe habilitar la sentencia Client.  Path: Define la ruta donde se encuentra el SOCKET UNIX - DOMAIN (canal de comunicación). Este se especifica como un archivo que enlazará la comunicación entre dos puertos (25 y 110 – 143).  Mode: Código que permite que sólo el Servidor Postfix y Dovecot lean el archivo de enlace (socket de comunicación).  User: Usuario que tendrá los permisos específicos para tener acceso a dicho enlace (postfix)  Group: Grupo que tendrá autoridad en cuanto al acceso al socket de comunicación (postfix). NOTA: Verificamos y descomentamos las llaves correctamente para que siempre tengan un inicio y final abarcando el contenido habilitado. Terminada la configuración damos “ESC + Shift + : + x” para guardar y salir.
Realizado el anterior procedimiento, procedemos a reiniciar el servicio de dovecot para activar los cambios realizados en el archivo de configuración.
Ahora nos dirigimos a configurar la técnica SASL en el Servidor Postfix. Ingresamos al archivo de configuración principal “main.cf” a través de un editor de texto.
Como se observa en la siguiente imagen, debemos añadir unas líneas (parámetros) que permitirán la configuración SASL en el Servidor Postfix. Agregamos un encabezado (### SASL###) para diferenciar esta configuración y luego las siguientes sentencias:  Smtpd_sasl_type = dovecot (Usuario que posee permiso sobre el POP3 y el IMAP).  Smtpd_sasl_path = /var/run/dovecot/auth-client (Ruta del archivo intermediario (SOCKET) entre el Postfix y el Dovecot).  Smtpd_sasl_auth_enable = yes (Habilita la autenticación con SASL).  Smtpd_sasl_security_options = noanonymous (La autenticación no acepta usuarios anónimos)  Smtpd_recipient_restrictions = Permit_sasl_authenticated, reject (Indica que los usuario deben pedir autenticación con SASL. Únicamente los clientes con una misma IP (rango) podrán enviarse correos entre sí rechazando los usuarios remotos)). Finalizada ésta configuración damos “ESC + Shift + : + x” para guardar y salir.
Como siguiente paso, por medio de una CONEXIÓN TELNET a la máquina local (192.168.1.2) a través del puerto 25 (Servidor SMTP) probaremos la validez de la autenticación que se va a implementar para los usuarios. Nos conectamos a la máquina y por medio del mensaje “EHLO mail.lared.lab” esperamos una respuesta del servicio; ésta nos despliega una serie de opciones con las cuales podremos interactuar con el servidor. En este caso utilizaremos el mensaje AUTH PLAIN LOGIN para verificar la correcta conexión al utilizar la autenticación plana requiriendo un login (código).
Abrimos una nueva solapa (ventana en la terminal) y ejecutamos el comando “perl” con el fin de codificar a través del mecanismo Base64 el usuario y la contraseña que queremos validar, en este caso “johana”. Damos ENTER para dar el resultado codificado y lo copiamos. Luego nuevamente nos dirigimos a la ventana donde estamos ejecutando la conexión telnet y pegamos el código después de la sentencia AUTH PLAIN y efectivamente la autenticación es satisfactoria. Damos “quit” para salir de la conexión.
8.1 Configuración del cliente SASL
Para probar el correcto funcionamiento de la técnica SASL en un cliente MUA, en primer lugar verificamos los puertos que se encuentran habilitados en la máquina. Como vemos en la imagen tanto el puerto 993 y 995 del Servicio de Dovecot se encuentran escuchando. Estos puertos hacen referencia al socket seguro para IMAP y POP3.
Nos dirigimos a la máquina Windows XP donde se encuentra instalado el Cliente MUA por medio de la aplicación Thunderbird y como el usuario “johana” Redactaremos un nuevo mensaje.
Para el siguiente correo utilizaremos como destinatario (remitente) al usuario “administrador”, añadimos un asunto “Prueba SASL” y escribimos un mensaje, en este caso “Prueba autenticación SASL”. Damos clic en el botón Enviar ubicado en la parte superior – izquierda de la ventana.
Inmediatamente realizada esta acción, el servicio de envío de correo (SMTP – Postfix) requerirá de una contraseña para validar al usuario que va a enviar el mensaje con el fin de dar autorización y validar sus atributos contra el repositorio de información LDAP. Digitamos la contraseña para el usuario “administrador” y damos clic en Aceptar.
Efectivamente la contraseña e identificación del usuario fue válida. Seleccionamos el buzón del usuario administrador y damos clic en el botón Recibir. Como podemos ver en la parte inferior – derecha vemos que el correo fue recibido correctamente.
Procedemos a ingresar a la “Bandeja de entrada” de dicho usuario y vemos que el correo se encuentra registrado en ésta; damos doble clic en el mensaje para leerlo.
Aquí podemos ver que los datos remitente, destinatario, asunto y mensaje son correctos. Efectivamente la técnica SASL de autenticación para el envió de correos se está ejecutando correctamente.
9. INSTALACION Y CONFIGURACIÓN DE LA TÉCNICA DE CIFRADO TLS Para la implementación del protocolo de capa de conexión segura se requiere de la instalación del paquete OpenSSL el cual permitirá el cifrado del canal de comunicación a través de un certificado digital que establezca las sesiones de forma segura. Por medio del comando “yum search openssl” hacemos una búsqueda de dicho paquete para luego instalarlo. El paquete correspondiente a la aplicación es “openssl.i386”. Damos “y” para aceptar la instalación de dicha herramienta y verificamos al final que ésta se haya ejecutado correctamente con cada uno de los paquetes relacionados a la misma.
Realizado el anterior procedimiento, utilizamos el comando rpm para visualizar cada uno de los archivos de configuración de dicha aplicación, los cuales serán la base fundamental para la configuración del protocolo TLS. Entre los archivos que podemos destacar se encuentran:
Procedemos a dirigirnos a la primera ruta especificada por la herramienta rpm “/etc/pki”, listamos los archivos alojados en éste directorio y vemos que por defecto se encuentra creada una Autoridad Certificadora. Como se requiere de una nueva CA eliminaremos éste fichero (rm –rf (removerforzar eliminación)) que contiene una configuración diferente a la que vamos a establecer y nuevamente listamos los archivos para comprobar la correcta eliminación del directorio.
Como siguiente paso nos dirigimos al directorio /etc/pki/tls/misc en el cual se encuentran los scripts de ejecución para la creación de la Autoridad Certificadora. Por medio de un editor de texto como “vim” procedemos a ingresar a dicho archivo para realizar algunas configuraciones antes de ejecutarlo para crear la nueva CA.
Ya estando dentro del script nos dirigimos a añadir a la línea “$CA” la sentencia “-extensions v3_ca” ya que es un parámetro que dicho archivo ejecutable no trae por defecto para certificar que la Autoridad Certificadora que se va a crear va a registrarse como VERDADER “true” (de confianza). Finalizada ésta configuración damos “ESC + Shift + : + x” para guardar y salir.
Como siguiente paso, volvemos al directorio tls/ utilizando el comando cd .. (Ir dos directorios atrás) y listamos los archivos que éste contiene. Dicho fichero contiene el archivo principal de configuración para OpenSSL (openssl.cnf); ingresamos a éste por medio de un editor de texto. En este archivo de configuración indicaremos a la aplicación OpenSSL que el directorio donde estarán alojados los archivos pertenecientes a la Autoridad Certificadora será en /etc/pki/CA la cual a su vez se encuentra asociada con las rutas $dir indicando la ruta especifica del certificado de la CA y la llave privada. Damos “ESC + Shift + : + x” para guardar y salir.
Efectuados las anteriores configuraciones procedemos a ejecutar el script para la creación de la nueva CA utilizando el comando “. /CA –newca” (Nueva Autoridad Certificadora). El script es llamado a ser ejecutado a partir del “./” estando ubicados en la ruta respectiva donde se encuentra el script (/etc/pki/tls/misc/). Luego de la ejecución de éste damos ENTER para crear la nueva CA y dicha instalación nos indicará que la llave privada fue creada correctamente en el directorio /etc/pki/CA/prívate/cakey.pem, después nos aparecerá una serie de preguntas para especificar los datos correspondientes para la nueva CA. La primera pregunta que dicha configuración nos indica es especificar el password para la clave privada (cakey.pem):  Enter PEM pass phrase: “password” y luego verificamos el password.  Enter pass phrase for: “password”; verificación de la contraseña. A partir de esto el script nos indicará añadir una serie de datos que identificarán nuestra Autoridad Certificadora como lo son: Código del país, Nombre de la providencia, Nombre de la ciudad, Nombre de la Organización, Nombre de la Unidad Organizativa, Nombre completo del servidor donde se encontrará implementada y Dirección de Email como contacto (usuario virtual). En las preguntas “A challenge password” y “An optional company name” damos ENTER ya que no vamos a cambiar de contraseña para los archivos .PEM y no utilizaremos un nombre de compañía opcional.
Inmediatamente se tomaran las configuraciones realizadas en el archivo de configuración “openssl.cnf” y se creará la petición del certificado para la Autoridad Certificadora con la llave pública (este certificado será compartido para todos los clientes). Dicho script nos mostrará los detalles ya guardados y especificados para la CA indicando que éste es TRUE (VERDADERA).
Por medio del comando “cd ../..” nos devolvemos hacia atrás dos directorios. Estando en el fichero pki/ listamos los archivos que se encuentran en éste y cómo podemos ver se ha creado la nueva CA, ingresamos a éste directorio y con “ls” vemos los archivos que se crearon junto con la Autoridad Certificadora. Entre estos archivos podemos identificar el certificado de la CA el cual podemos abrir y visualizar con el comando “cat”. De acuerdo a lo que se muestra en la siguiente imagen, éste certificado contiene los datos específicos de la CA lo que indica que éste fue generado por ésta Autoridad, la llave pública, validación de la CA que lo generó y hash de todo el certificado (Firma).
Procedemos a visualizar la petición de certificado que la CA misma se genero. Este se muestra como un hash que contiene todos los datos e información (llave pública) necesaria para la generación del cacert.pem.
Para ver el contenido de la llave privada (Propiedad de la Autoridad Certificadora), estando en el directorio CA/ nos desplazamos a el fichero prívate/, listamos los archivos y allí se encuentra dicha clave. Visualizamos el hash de la llave utilizando el comando cat + el archivo.
Ya que el servicio de TLS se va a implementar para un Servidor de Correo, éste debe realizar una petición de certificado a la Autoridad Certificadora ya existente utilizando la herramienta OpenSSL. Para ello nos ubicamos en el root dando el comando “cd” y aplicamos el comando con las siguientes opciones:       Req: Genera una petición de certificado New: Indica que estamos realizando una petición nueva. Nodes: Indicamos que la nueva clave generada (privada) no sea cifrada. Keyout: Lee la clave privada del fichero dado como argumento (ruta) Out: La petición de certificado se almacenará en el fichero dado. Days: Especifica el número de días que el certificado creado será válido.
De acuerdo a lo anterior, la llave privada será almacenada en el directorio /etc/postfix con el nombre postfix-key.pem; la petición (postfix-req.pem) se alojará en el directorio desde el cual ejecutamos el comando (root) y los días de validez para dicho certificado serán equivalentes a un año (365 días). Ingresamos los datos que nos indican los campos y damos ENTER en las preguntas opcionales:
Estando ubicados en la ruta desde la cual se generó la petición, listamos los archivos que se encuentran en éste directorio y efectivamente allí se encuentra alojada la petición (postfix-req.pem) ya generada. Visualizamos el hash de dicha petición con el comando “cat”.
Ahora como siguiente paso procedemos a generar la firma del certificado a partir de la petición ya realizada utilizando igualmente la herramienta OpenSSL y las siguientes opciones específicas:  Ca: Firma una CSR (petición de certificado).  Out: El certificado firmado se almacenará en el fichero dado.  Infiles: Especifica el CSR (petición de certificado) que vamos a firmar (postfix-req.pem). Dicho certificado será guardado en el directorio /etc/postfix con el nombre postfix-cert.pem y para su generación será necesaria la validación de la contraseña para el acceso a la clave privada de la CA (cakey.pem) para firmar el certificado del cliente. La ejecución del comando nos muestra los detalles del Certificado con cada uno de los datos e información específica del mismo. Damos “y” para asignar el certificado al Servicio de correo por 365 días y “y” para validarlo a partir de la petición realizada.
Nos dirigimos a comprobar la creación de los archivos (certificado y llave privada) en el Servidor Postfix (/etc/postfix). Listamos los archivos existentes en éste fichero. Como podemos ver allí se encuentran ambos archivos, procedemos a visualizar el hash respectivo para la llave privada y el certificado ya firmado por la CA el cual contiene la llave pública y los datos específicos para éste.
Es importante especificar que en este certificado aparece la CA por la cual fue generado dicho certificado “FALSE” ya que éste certificado no es real, no se está pagando por su generación y servicio. |
Como siguiente paso debemos hacer una copia del certificado de la CA (cacert.pem) al directorio /etc/postfix con el fin de que la CA comparta su certificado con el cliente y este pueda ser distribuido y utilizado para las aplicaciones que van a ser certificadas y validadas a partir de la llave pública. Esta copia la realizamos de forma recursiva (-R).
Nuevamente nos dirigimos al directorio /etc/postfix y listamos los archivos para verificar la copia correcta de dicho certificado. Ahora procedemos a modificar los permisos del certificado del Servidor y de la CA (644) para que el usuario propietario (root) sea el único que pueda leerlos y escribir en ellos (modificar). Tanto el grupo propietario y los otros solo podrán leerlos. Para la llave privada del Servidor daremos los permisos 400 para que solo el usuario propietario (root) pueda leerla. Listamos los archivos para comprobar el cambio de los permisos especificados.
Debemos configurar el Servidor Postfix para que acepte la utilización de TLS. Para ello debemos ingresar al archivo de configuración principal “main.cf”.
Estando dentro del archivo de configuración debemos añadir las siguientes líneas. A partir de la sentencia (### TLS ###) diferenciaremos la sintaxis específica para la aplicación del protocolo TLS y con (### CA ###) las rutas definidas para el certificado del Servidor y la llave privada del mismo. Se deben añadir las siguientes líneas:  Smtp_tls_CAfile = /etc/postfix/cacert.pem (Ruta donde se encuentra el certificado de la CA con la clave pública).  Smtpd_tls_security_level = may (Todos los niveles de seguridad).  Smtpd_use_tls = yes (Utilizar técnica de cifrado TLS).  Smtpd_tls_session_cache_timeout = 3600s (Límite de tiempo en las sesiones TLS).  Smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_scache (Alojamiento de la base de datos donde se encuentran registradas las sesiones TLS).  Smtpd_auth_only = yes (Requerir autenticación para el uso de TLS).  Smtpd_enforce_tls = yes (Aplicar TLS a el Servicio de SMTP).  Smtpd_tls_cert_file = /etc/postfix/postfix-cert.pem (Ruta donde se encuentra el certificado del Servidor).
 Smtpd_tls_key_file = /etc/postfix/postfix-key-pem (Ubicación de la llave privada del Servidor). Terminada la configuración anterior damos “ESC + Shift + : + x” para guardar y salir. Reiniciamos el servicio de Postfix para que los cambios se apliquen correctamente.
Procedemos a realizar las pruebas de la funcionalidad de la técnica TLS utilizando la herramienta OpenSSL. Es de gran importancia especificar que el cifrado del canal de comunicación únicamente se configuró para la autenticación; es por ello que utiliza el método STARTTLS. Aplicamos la conexión a través de las siguientes opciones:  S_client: Prueba desde el cliente TLS.  Connect: Conectar a la dirección local 192.168.1.2 por el puerto 25.  Starttls: Cifrado del canal de comunicación únicamente para el envío de correos (SMTP). Como vemos en la siguiente imagen el resultado fue exitoso ya que nos muestra que se está utilizando un certificado digital para el cifrado del canal de comunicación (Certificado del cliente, es decir, del Servidor SMTP); además de mostrar el código de la sesión iniciada, el cifrado de la llave con la cual fue abierta y el tiempo de conexión. A través de dicha conexión podemos iniciar la comunicación hacia el servidor con el mensaje EHLO mail.lared.lab; si hay conectividad éste responderá a dicha solicitud con una serie de opciones a utilizar, podemos probar nuevamente la autenticación de los usuarios.
Utilizamos la codificación realizada anteriormente en la prueba para la autenticación con SASL o podemos codificar los datos a partir de un nuevo usuario. Copiamos el código y con la sentencia AUTH PLAIN LOGIN añadimos éste en la comunicación OPENSSL y efectivamente ésta es exitosa. Damos el comando “quit” para finalizar la comunicación.
9.1 Configuración del cliente TLS Para la correcta configuración y efectividad del TLS, debemos compartir al cliente Windows XP (MUA) el certificado de la Autoridad Certificadora que contiene la clave pública (cacert.pem) para importarlo en la Aplicación Thunderbird y así ésta pueda trabajar con un canal cifrado al momento del envío de correos. Para efectuar esto, desde el servidor utilizaremos el correo educativo http://correo.misena.edu.co para enviarnos un correo que tenga como adjunto dicho certificado.
Ahora nos dirigimos a la máquina cliente Windows XP e ingresamos a la Aplicación MUA. Seleccionamos el usuario “administrador” y damos clic derecho – Configuración.
Dentro de la Configuración de la cuenta – Configuración del servidor de salida (SMTP) damos clic en Editar … y modificaremos el nombre del servidor de la conexión (mail.lared.lab) ya que esta es una de las comprobaciones que hace el TLS; comprobar el nombre del servidor al cual se va a conectar. También debemos cambiar el método de seguridad de la conexión que para este caso sería STARTTLS. Este procedimiento lo debemos realizar con cada uno de los usuarios. Damos clic en Aceptar.
Ahora estando como el usuario “administrador” redactaremos un nuevo mensaje para el usuario erika@lared.lab con el asunto “Primera prueba TLS” y un cuerpo de mensaje “TLS!”. Damos clic en el botón Enviar e inmediatamente nos aparece una ventana para “Añadir excepciones de seguridad” que está requiriendo obtener un certificado de mail.lared.lab a través del puerto 25; define que el estado del certificado no es válido y que no se confía en dicha identidad. Damos clic en Obtener certificado y deseleccionamos la opción “Guardar esta excepción de manera permanente” con el fin de que no sea ignorada la utilización de un certificado validado correctamente. Presionamos el botón “Confirmar excepciones de seguridad”.
Efectivamente nos aparece la ventana de autenticación para el envío de correo, ingresamos la contraseña para el usuario erika y damos clic en Aceptar.
Estando sobre el Buzón del usuario erika damos clic en el botón Recibir y cómo podemos ver el mensaje se ha recibido correctamente.
Como siguiente paso nos dirigimos desde nuestra máquina Windows XP al correo.misena.edu.co desde el cual abriremos el correo enviado anteriormente con el certificado de la CA (cacert.pem) para descargarlo en el cliente.
Damos clic en Descargar y luego en el botón Guardar. Buscamos la ruta donde queremos que dicho certificado sea almacenado, en éste caso lo guardaremos en el Escritorio.
Ahora nos dirigimos nuevamente a la Aplicación Thunderbird y en el menú de opciones seleccionamos Herramientas – Opciones.
Inmediatamente se abrirá una ventana para la administración y configuración de las opciones de la Aplicación como tal. Damos clic en la pestaña “Avanzado” y luego en “Certificados”. Estas opciones nos permitirán ver y administrar los certificados que ésta corriendo dicho proceso. Damos clic en el botón “Ver certificados”.
Al ingresar al Administrador de certificados, damos clic en la pestaña Servidores en el cual veremos registrado el certificado que validamos al enviar el correo “Primera prueba TLS”. Este certificado desconocido debemos eliminarlo para que la aplicación no lo tome como válido.
Damos clic en Aceptar para eliminar ésta excepción de certificado.
Ya eliminado el certificado temporal para mail.lared.lab, desplegamos la pestaña Autoridades en la cual se alojan los certificados válidos firmados por una Autoridad Certificadora de confianza. Damos clic en el botón Importar… para añadir el nuevo certificado.
Buscamos en la respectiva ruta “Escritorio” el certificado descargado anteriormente (cacert.pem), lo seleccionamos y le damos Abrir.
Ahora buscamos en los certificados de Autoridades el certificado correspondiente a la CA LARED (mail.lared.lab), lo seleccionamos y damos clic en el botón “Ver…” para identificar características fundamentales del certificado como lo son: Emitido por, Emitido para, El nombre común (CN), la organización, la unidad organizativa, la fecha de vigencia y las huellas digitales. Para ver con más detalle cada uno de éstos campos damos clic en la pestaña Detalles. Aquí podremos visualizar especificaciones como la clave pública compartida por la CA.
Ahora procedemos a enviar nuevamente un correo desde el usuario “administrador”, en este caso para el usuario “sara@lared.lab”, con un asunto “Segunda prueba TLS” y el cuerpo del mensaje será “TLS!!”. Damos clic en Enviar.
Inmediatamente nos aparece esta ventana indicándonos que la Aplicación va a utilizar el nuevo certificado importado dentro de sus Autoridades. Para indicar que la Autoridad Certificadora es de confianza (mail.lared.lab) seleccionaremos las opciones por las cuales haremos uso de la misma, como lo son: Identificación de un sitio web, identificación de usuarios de correo e identificación de desarrolladores de software. Antes de aceptar confiar en ésta CA debemos verificar o examinar el certificado de ésta (Proceso realizado anteriormente). Damos clic en Aceptar.
La aplicación nos pide autenticarnos para el envío de correos utilizando la contraseña del “administrador”. Damos clic en Aceptar para validar la autenticación.
Como podemos ver efectivamente la aplicación ha validado el nuevo certificado, verificando el nombre del servidor al cual va dirigido, la fecha de vigencia del mismo y la firma de confianza realizada por una Autoridad Certificadora verdadera. Señalamos el usuario “sara” y damos clic en recibir y como muestra la siguiente imagen el correo se ha recibido correctamente.
Nos dirigimos a la bandeja de entrada del usuario sara y damos clic en el nuevo mensaje recibido para visualizarlo.
NOTA: Es un requisito importante añadir como Servidor DNS preferido para el cliente la dirección del servidor de correo (DNS) con el fin de que la validación del nombre mail.lared.lab sea satisfactorio en su resolución a través de TLS.
10. INSTALACIÓN Y CONFIGURACIÓN DEL SERVICIO WEBMAIL (APACHE)
Para la instalación y correcta configuración de la aplicación Web WEBMAIL aplicada bajo un servidor apache, debemos descargar de la página oficial el paquete del software que deseamos ejecutar en este caso se instalará “ROUND CUBE”. Ingresamos a un navegar web e ingresamos a la página oficial de dicha aplicación. Ya estando allí damos clic en DOWNLOAD versión Stable 0.5.1.
Inmediatamente nos aparece una ventana donde daremos Aceptar para guardar y paquete y luego daremos la ruta donde queremos que éste ya descargado se almacene. Para este caso lo guardaremos en el directorio principal del usuario del sistema LARED.
Esperamos a que la descarga finalice completamente y sea correcta para iniciar la instalación de dicho paquete.
Ya finalizada la descarga procedemos a instalar por medio del comando “yum install” el servicio httpd (Apache, Servidor Web) el cual es fundamental para montar dicha aplicación Web (WEBMAIL). El paquete httpd contiene el demonio “httpd” y otras utilidades relacionadas, archivos de configuración, iconos, Servidor Apache HTTP, módulos, manual de configuración y otros archivos utilizados por Servidor Apache HTTP y que son fundamentales para su total funcionamiento. El paquete httpd-devel contiene el Servidor Apache HTTP, incluye archivos, cabeceras de archivos y la utilidad APXS (Utilidad de apache para instalar módulos y extensiones).
Damos “y” para confirmar la instalación de dichos paquetes. Al finalizar la instalación el proceso nos informará que la instalación fue exitosa listando cada una de las aplicaciones instaladas.
Luego de realizar el anterior procedimiento, verificamos los puertos que se encuentran escuchando con el comando netstat y cómo podemos ver el puerto respectivo al servicio httpd no se encuentra en función. Con el comando rpm hacemos una búsqueda de los archivos de configuración de dicho servicio para probar que se encuentra correctamente instalado. Las opciones “q” y “l” se utilizan para hacer una búsqueda y listar el resultado de la misma.
Ahora continuamos reiniciando el servicio para que éste se inicie correctamente y luego nuevamente comprobamos el estado de los puertos y efectivamente el puerto 80 se encuentra escuchando por todas las direcciones.
Como siguiente paso, nos dirigimos a /home/lared, el cual fue el directorio donde guardamos el paquete compreso “.tar.gz” para la instalación del WEBMAIL ROUNDCUBEMAIL. Procedemos a descomprimirlo (extraer todos los archivos) utilizando el empaquetador “tar –zxvf” (z = Descomprimir archivos de forma automática, x = Extraer el contenido de un archivo, v = Imprimir resultados detallados (nombres de archivo lista a medida que se procesan), f = Nombre del archivo a descomprimir) y el nombre correspondiente al archivo. Damos ENTER para proceder a su ejecución.
Realizado éste proceso nuevamente listamos los archivos del directorio /home/lared, y vemos que se ha desempaquetado correctamente el archivo compreso; con el comando “mv” cambiamos el nombre del nuevo archivo como vemos en la siguiente imagen y verificamos que éste haya sido renombrado.
A continuación debemos realizar una copia de dicho archivo (roudcubemail) al directorio correspondiente a las aplicaciones WEB “/var/www/html” realizándolo de forma recursiva (-R). Procedemos a dirigirnos a ésta ruta y listamos los archivos alojados en ésta; cómo podemos ver la copia fue realizada correctamente.
Como siguiente paso, estando en el directorio /var/www/html accedemos al directorio roundcubemail y allí listamos los archivos que éste contiene para comenzar con su configuración e instalación. Entre los archivos que podemos resaltar se encuentra “INSTALL” el cual contiene una explicación completa del proceso de instalación; procedemos a abrirlo con el editor de texto “vim”.
Las instrucciones que se muestran a continuación contienen un listado de los requisitos necesarios para la instalación de la Aplicación Web Roundcube Webmail en un servidor de éste tipo. Entre los requerimientos más importantes se encuentran tener instalado un servidor Apache en la máquina, PHP Versión 5.2.1 o mayor a ésta, Una base de datos como MySQL con una versión 4.0.0 o mayor y un servidor SMTP configurado para el servicio de mail.
Gracias a lo especificado anteriormente, nos dirigimos a instalar los servicios de mysql (Base de datos), mysql- server (Servidor) y mysql-devel (Bibliotecas y ficheros de cabecera que se necesitan para compilar otros clientes MySQL, como los módulos Perl.). Damos “y” para aceptar la instalación de dichos paquetes y verificamos al terminar el proceso que éste se haya completado correctamente.
Antes de descargar e instalar el lenguaje de programación PHP debemos buscar en Internet los repositorios correspondiente para la actualización de su versión ya que los repositorios que estamos utilizando en nuestra máquina contiene la versión anterior a la 5.2.1 la cual no es válida para la instalación de acuerdo a los requerimientos. Nos dirigimos a un Navegador de Internet y en el buscador de Google buscamos los “repositorios utterramblings” los cuales contienen dicha actualización y accedemos al tercer link que desprende la búsqueda (http://www.cibermanuales.com/sistemas-operativos/linux/como-actualizar-version-servicorphp-en-centos) y seguimos paso a paso las especificaciones dadas en la página.
En primer lugar se debe instalar la clave pública para el acceso a los repositorios importándolos al sistema con la herramienta de administración de paquetes “rpm”.
Luego con el editor de texto nano se debe crear el archivo que va a alojar las rutas asociadas al repositorio y lo llamaremos utterramblings.repo (extensión de repositorios). En este fichero copiaremos el código señalado en el siguiente paso.
Procedemos a seguir los pasos expuestos anteriormente dirigiendonos a la ruta /etc/yum.repos.d/ (Ruta en la cual se encuentran alojados los repositorios que estamos utilizando); listamos los archivos y cómo podemos ver únicamente se encuentran los repositorios para CentOS. Estado allí, importamos la clave pública para los nuevos repositorios utilizando el comando especificado en la página guía así como la sintaxis correcta para la creación del nuevo repositorio.
Ya estando dentro del archivo pegamos el código respectivo el cual indica el nombre del repositorio, la base en internet de la cual se van a descargar los paquetes (repositorio), estado habilitado y ruta donde se encuentra la llave o clave pública para la utilización de los mismos. Damos “Ctrl + o” para guardar los cambios, “Ctrl + x” para salir.
Verificamos la creación de los repositorios listando nuevamente los archivos que se encuentran el /etc/yum.repos.d y efectivamente se encuentra el nuevo fichero creado “utterramblings.repo”.
Como siguiente paso actualizaremos los repositorios utilizando el comando yum update para que tome en uso el nuevo fichero “utterramblings.repo”. Damos “y” para aceptar dicha actualización. Finalizada la actualización el proceso especificará que éste fue completado correctamente.
Ya actualizada la lista de repositorios a utilizar, ahora instalaremos el lenguaje de programación PHP con una serie de dependencias y paquetes relacionados con el mismo para su correcto funcionamiento. Entre estos paquetes se incluye “php-mysql” el cual permitirá integrar la base de datos junto con éste lenguaje para su correcta ejecución. Damos “y” para aceptar la instalación.
Comprobamos a través del mensaje Complete! que la instalación fue correcta además de la lista que se muestra relacionada a los paquetes y dependencias de los mismos ya instalados y listos para ser utilizados.
Pasamos a verificar los archivos de configuración principales del paquete PHP así como la versión del lenguaje PHP ya instalado la cual efectivamente es mayor a la 5.2.1 (5.2.16). Este parámetro lo podemos visualizar con el comando “php –version”.
Nuevamente nos dirigimos al documento guía de instalación y seguimos cada uno de los pasos expuestos para la INSTALLATION. En primer lugar debemos desempaquetar el folder que descargamos (Paso ya realizado anteriormente). Ahora es necesario darle permisos a algunos de los directorios pertenecientes a éste paquete y crear una base de datos respectiva para Roundcube.
Nos dirigimos al directorio /var/www/html/roundcubemail y estando allí identificamos los directorios logs/ y temp/ a los cuales les daremos los permisos 775 de forma recursiva para que el usuario y grupo propietario (APACHE) tengan control total sobre ellos pero los “otros” solo puedan leerlo y ejecutarlo, no pueden escribir (modificarlos).
Estando dentro del mismo directorio, cambiamos el usuario y grupo propietario a todos los archivos por APACHE, listamos el contenido del directorio y le damos “–l” para ver las características de usuario y grupo. Como podemos ver cada uno de los ficheros y archivos de dicho directorio pertenecen al usuario APACHE y al grupo APACHE. Como siguiente paso colocaremos únicamente el fichero installer/ con el usuario y grupo propietario ROOT para que este sea únicamente ejecutado por el súper usuario del sistema; esto lo realizamos de forma recursiva (-R).
De acuerdo a los parámetros especificados en el documento guía INSTALL, procedemos a crear la base de datos para dicha aplicación (Roundcube).
Ingresamos al servicio de MySQL a través del comando mysql –u (usuario) root –p (password); para este caso no tenemos configura una contraseña para acceder a la base de datos, damos ENTER como contraseña ya que el acceso es anónimo. Inmediatamente ingresamos al PROMPT de mysql desde el cual ejecutaremos los comandos especificados en la guía para crear la base de datos “roundcubemail” y crear un usuario para dicha base de datos con todos los privilegios sobre ésta y con una identificación de password para su acceso. Luego de este procedimiento con el comando “show databases;” consultamos las bases de datos existentes para verificar que “rondcubemail” se haya creado correctamente. Damos “quit” para salir del PROMPT mysql.
Es de gran importancia recordar que después de realizar algún cambio en alguno de los servicios es necesario reiniciar el mismo para que se tomen los cambios efectuados y el sistema compruebe fallas o errores de configuración. Reiniciamos el servicio de MYSQLD como se muestra en la siguiente imagen.
Como siguiente paso nos dirigimos nuevamente a los archivos de configuración para el roundcubemail. Ingresamos al directorio config/ (Fichero de configuración principal) y listamos los archivos allí existentes. Es necesario renombrar los archivos db.inc.php.dist y main.inc.php.dist a una extensión .php para que la aplicación tome los parámetros y configuraciones realizadas en éstos a partir del lenguaje PHP. Utilizamos el comando “mv” para cambiar dichos nombres. Damos “ls” para listar los archivos y verificar los nombres ya renombrados.
Después de realizar dicho proceso, por medio del editor de texto “nano” ingresamos al archivo db.inc.php ya renombrado.
Ya estando dentro de éste, procedemos a modificar la línea que se muestra en la imagen con el fin de especificar que la base de datos mysql llamada “roundcubemail” posee un password “administracion” con un dominio local “localhost” y un usuario propietario de dicha base de datos (roundcubemail). Este parámetro se configura para que al momento de instalar la aplicación ésta detecte la base de datos y pueda acceder a la misma a partir del password especificado. Damos Ctrl + o para guardar y Ctrl + x para salir.
Continuamos reiniciando el servicio de httpd para que los cambios sean aplicados correctamente.
Ya realizados los anteriores cambios y procesos, abrimos un Navegador de Internet en el cual añadiremos la URL: http://localhost/roundcubemail/roundcubemail/installer para iniciar el proceso de instalación de la Aplicación Web como tal. Esta nos muestra un mensaje informándonos que el fichero installer se encuentra deshabilitado (false) en el archivo de configuración principal main.inc.php.
Para habilitar el installer de la Aplicación y poder ejecutarlo, nos dirigimos al directorio /var/www/html/roundcubemail/config y desde allí ingresamos con el editor de texto “nano” al archivo main.inc.php para realizar las respectivas configuraciones.
Ya estando en el archivo correspondiente buscamos la línea que especifica el fichero installer para ser habilitado, cambiamos el comentario “false” por “true” y damos Ctrl + o para guardar y Ctrl + x para salir.
Reiniciamos nuevamente el servicio utilizando el comando /etc/init.d/httpd restart o service httpd restart.
Nos dirigimos al Navegador (URL: http://localhost/roundcubemail/roundcubemail/installer), y efectivamente el archivo installer para Roundcube Webmail se ha habilitado correctamente. En esta imagen podemos observar que la Aplicación ha aceptado la versión de PHP instalada, así como las extensiones referentes a ésta y la base de datos en MySQL. Los comentarios NOT AVAILABLE son parámetros que no se encuentran disponibles pero que de igual forma no son requisitos fundamentales para la instalación de la Aplicación.
De igual forma se hace un chequeo de una serie o conjunto de parámetros como la conexión correcta a un servidor SMTP para hacer uso del Webmail a través de éste. Además de verificar algunos archivos de configuración para el lenguaje de programación PHP. Damos clic en Next para continuar con el chequeo de las diferentes especificaciones.
El paso de configuración número dos (Create config) no es necesario realizarlo gracias a la configuración realizada en el archivo db.inc.php indicando la base de datos, su usuario y contraseña respectiva. Por ello el instalador por defecto se salta este paso. El ítem número tres define un test de configuración; chequea los archivos y ficheros respectivos para ésta aplicación como el main.inc.php y db.inc.php; temp/ y logs/ y por ende la configuración correcta de la DB (Base de Datos). El test de configuración para SMTP es opcional puesto que es efectivo probar con el test para IMAP.
Se debe realizar un test de configuración para probar la conectividad del Protocolo IMAP para la recepción de correos electrónicos. Para ello a través del puerto 143 indicamos el servidor local (127.0.0.1) donde se encuentra el servidor DOVECOT, un usuario virtual (administrador) y su respectiva contraseña. Damos clic en “Check login” para probar que el usuario es válido.
Como podemos ver, efectivamente el chequeo fue satisfactorio y existe conexión con el protocolo IMAP a través de la dirección 127.0.0.1. En la parte inferior aparece un letrero en rojo informando que es necesario remover el fichero “installer” de la configuración para tener acceso a la Aplicación.
Para que la instalación termine correctamente, nos dirigimos nuevamente al archivo de configuración main.inc.php ingresando a través de un editor de texto como “vim”.
Procedemos a deshabilitar el fichero installer en la línea respectiva a dicha especificación. Modificamos el comentario “true” por “false” como se muestra en la siguiente imagen. Damos “ESC + Shift + : + x” para guardar y salir.
Reiniciamos el servicio para que los cambios sean efectuados correctamente (/etc/init.d/httpd restart).
Ingresamos nuevamente al Navegador de Internet y accedemos a la URL respectiva y cómo podemos ver ya el fichero de instalación “installer” se encuentra deshabilitado y no puede ser ejecutado.
Para que el acceso a dicha Aplicación se dé correctamente debemos borrar de la ruta el fichero installer (URL: http://localhost/roundcubemail/). Como podemos Roundcube Webmail carga correctamente y se encuentra habilitado para iniciar sesión con los respectivos usuarios registrados en el servicio SMTP y DOVECOT. Ingresamos con el nombre del usuario administrador, su respectiva contraseña y el servidor local (Dirección IP: 192.168.1.2). Clic en Entrar.
Al ingresar podemos verificar que todos los correos que ha recibido (Entrada) dicho usuario se encuentran registrados y habilitados para ser leídos por el cliente final. Damos clic en “Nuevo mensaje” para hacer prueba enviando un correo a otro de los usuarios virtuales.
Añadimos como usuario destinatario a “erika@lared.lab” y como asunto “Prueba WEBMAIL”. Agregamos un mensaje, en este caso “Hola Prueba!”. Damos clic en el ícono Enviar.
Verificamos en la carpeta “Enviados” que el correo se haya enviado correctamente al respectivo remitente y procedemos a cerrar la sesión del usuario administrador.
Ahora procedemos a ingresar al WEBMAIL como el usuario erika; digitamos la contraseña y el servidor (SMTP – DOVECOT). Damos clic en Entrar.
Observamos la BANDEJA DE ENTRADA para dicho usuario y efectivamente allí se encuentran los correos que éste ya había recibido anteriormente y el nuevo mensaje “Prueba WEBMAIL”. Damos doble clic sobre éste para leerlo.
Como podemos ver en la imagen cada uno de los datos de dicho mensaje corresponden a los especificados al enviar el correo desde el usuario administrador (Asunto, Remitente, Destinatario, Fecha y Mensaje). Con esto podemos concluir que la Aplicación Roundcube WEBMAIL (MUA) para el browser fue instalado y configurado correctamente por lo que su ejecución es exitosa.
11. INSTALACIÓN Y CONFIGURACIÓN DE LA TÉCNICA DE CIFRADO SSL
Para la implementación de la técnica de cifrado SSL en todo el canal de comunicación (DOVECOT – Entrega de correos) procedemos en primer lugar a reiniciar el servicio de Dovecot con el fin de verificar su correcto funcionamiento. Luego nos dirigimos a la ruta preestablecida donde se alojan las Autoridades Certificadoras; entre ellas se encuentra el fichero “dovecot” al cual ingresaremos y listaremos todos sus archivos.
Entre estos archivos podemos identificar el documento principal de configuración OpenSSL denominado “Dovecot-openssl.cnf”. Nos dirigimos a abrir dicho archivo utilizando el editor de texto “vim”.
Ya estando dentro del archivo de configuración respectivo procedemos a añadir en los campos de información los datos referentes para la petición de un nuevo certificado como lo son el código del país, la providencia, la ciudad, la organización, la unidad organizativa, el nombre del servidor, el email de contacto y el tipo de certificado que se va a generar. Damos “ESC + Shift + : + x” para guardar y salir.
Ahora nos dirigimos al directorio /usr/share/doc/dovecot-1.0.7 y listamos los archivos, allí ingresamos al fichero examples/ y verificamos los archivos alojados en éste. Debemos identificar el archivo mkcert.sh el cual es un archivo ejecutable que se utiliza para la creación de la llave privada para el servicio de Dovecot. Con el comando sh ejecutamos dicho archivo y efectivamente creamos la clave la cual se encuentra alojada en /etc/pki/dovecot/prívate/dovecot.pem.
Ahora, estando dentro del directorio /etc/pki/dovecot/, ingresamos al fichero certs/ y listamos los archivos allí alojados. Como podemos ver en la imagen, allí se encuentra el certificado para el servicio de Dovecot; podemos visualizar el Hash que lo compone a través del comando “cat”.
Estando dentro del directorio certs/ procedemos a modificar el nombre del certificado “dovecot.pem” por “dovecot-cert.pem” con el fin de identificarlo como un certificado. Listamos nuevamente los archivos para verificar que el archivo haya sido renombrado correctamente.
Con el comando “cd ..” nos devolvemos un fichero hacia atrás. Ahora nos encontramos en el directorio /etc/pki/dovecot, desde allí ingresamos al directorio prívate/ y con el visor archivos “cat” visualizamos la llave privada ya creada “dovecot.pem”. Al igual que el certificado, pasamos a renombrar dicho archivo de “dovecot.pem” a “dovecot-key.pem” utilizando el comando “mv”.
Listamos los archivos para verificar que el archivo haya sido renombrado correctamente.
Como siguiente paso procedemos a realizar una serie de configuraciones en el archivo principal del Servicio de Dovecot “dovecot.conf” utilizando el editor de texto “vim”.
Ya estando dentro del archivo de configuración, añadimos a la línea “protocols” los protocolos seguros para cada imap (imaps) y pop3 (pop3s).
Descomentamos la línea “ssl_disable” e indicamos que NO esté deshabilitada ésta técnica de cifrado.
A continuación procedemos a descomentar las líneas señaladas, éstas indican la ruta específica para el certificado (dovecot-cert.pem) y la llave privada (dovecot-key.pem).
Ahora como siguiente paso copiamos cada una de estas rutas en las sentencias de los protocolos POP3 e IMAP con el fin de que cada uno de éstos conozca la ubicación del certificado y la llave privada y puedan tener acceso a los mismos al momento de recibir un correo a través del canal cifrado.
Pasamos a habilitar la línea disable_plaintext_auth y confirmamos “yes” desactivar la autenticación en texto plano (anónima).
En la línea ssl_key_password, indicamos que para el acceso a la llave privada al utilizar el mecanismo SASL se debe validar la contraseña.
El parámetro ssl_parameters_regenerate indica la no regeneración (0) de los parámetros del archivo para SSL.
La línea ssl_cipher_list es la directiva que indica que todos los usuarios que utilicen SSL para recibir los correos implementarán SSL versión 2.
Descomentamos la línea verbose_ssl y habilitamos su utilización para registrar los mensajes de información con SSL (errores). Finalizado el procedimiento presionamos la tecla “ESC, Shift + : +” x para salir y guardar el archivo de configuración con los cambios efectuados.
Procedemos a reiniciar el servicio de Dovecot para que los cambios realizados en dicho archivo de configuración sean aplicados correctamente. Como siguiente paso probaremos el correcto funcionamiento de la comunicación cifrada por SSL para el Servicio de Dovecot; utilizamos el comando openssl s_client (para especificar que nos vamos a conectar al servidor como clientes) – connect mail.lared.lab (nombre del servidor al cual nos vamos a conectar):pop3s (protocolo a utilizar para la conexión). Como podemos ver en la imagen el servidor nos contesta mostrándonos que se está haciendo uso de un certificado para dicho protocolo, la identificación de la sesión iniciada, el hash del certificado, y datos específicos del certificado creado. A partir de esto podemos decir que la conexión cifrada ha sido satisfactoria para el Servicio de Dovecot.
1. SERVIDOR DE CORREO: Un servidor de correo es una aplicación informática ubicada en una Página Web en Internet cuya función es similar al correo postal a diferencia que en este caso los correos (mensajes) que circulan lo hacen a través de redes de transmisión de datos , por este medio solo se pueden enviar adjuntos de ficheros de cualquier extensión y no paquetes al viajar la información en formato electrónico. MTA (Agente de Transferencia de Correo - Mail Transport Agent): Los servidores de correo realizan diferentes funciones según sea el uso que se planifique para el mismo, es uno de los programas que ejecutan los servidores de correo, y tiene como fin transferir un conjunto de datos de una computadora a otra. Dicho servidor tiene varias formas de comunicarse con otros servidores de correo:  Recibe los mensajes desde otro MTA. Actúa como "servidor" de otros clientes.  Envía los mensajes hacia otro MTA. Actúa como un "cliente" de otros servidores.  Actúa como intermediario entre un Mail Submision Agent (Agente de Registro de Correo) y otro MTA. 2. INTERCAMBIO DE CORREO ELECTRONICO: Un servidor de correo realiza una serie de procesos que tienen la finalidad de transportar información entre los distintos usuarios. Usualmente el envío de un correo electrónico tiene como fin que un usuario (remitente) cree un correo electrónico y lo envié a otro (destinatario). 3. SERVIDORES DE CORREO VIA WEB: Este tipo de servidores de correo, son aquellos que pueden ser accesibles vía WEB usando el protocolo HTTP. En el mismo servido se integran programas para acceder a los correos por medio de un navegador Web. Algunos de estos son: www.hotmail.com, www.yahoo.com, www.gmail.com, entre otros. 4. MTA (Mail Transport Agent - Agente de Transporte de Correo): Es uno de los programas que ejecutan los servidores de correo, y tiene como fin transferir un conjunto de datos de una computadora a otra, estos transportan el mensaje hasta llegar a su destino y utilizan el protocolo SMTP. 5. MUA (Mail User Agent - Agente de Usuario de Correo): Es una aplicación usada para leer y enviar e-mails, puede ser vía Web (OWA - Outlook Web Access) o localmente desde el ordenador (Outlook, Thunderbird, entre otros).
 ARBOL: Es la agrupación de organizaciones que contienen varios dominios.  BOSQUE: Es la organización y agrupación de varios árboles completamente independientes entre sí. 20. DNS (Domain Name System): Servicio de resolución de nombres de domino. Este servicio nos ofrece la oportunidad de resolver nombres por IP o de IP por nombres de equipo. El DNS es una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio.  ZONA INVERSA: Con la IP podemos encontrar el nombre de dominio. (Maneja el registro PTR)  ZONA DIRECTA: Con el nombre de dominio podemos encontrar la IP. (Maneja el registro A) 21. CERTIFICADO DE SEGURIDAD: Son archivo de textos que junto al protocolo SSL permite establecer una conexión confiable, este a su vez también incluye a quien pertenece el certificado. 22. SSL (Secure Sockets Layer, Protocolo de capa de conexión segura): SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad). SSL implica una serie de fases básicas: Negociar entre las partes el algoritmo que se usará en la comunicación Intercambio de claves públicas y autenticación basada en certificados digitales Cifrado del tráfico basado en cifrado simétrico El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser comprimido, cifrado y empaquetado con un código de autenticación del mensaje (MAC). Cada registro tiene un campo decontent_type que especifica el protocolo de nivel superior que se está usando  MAC (código de autenticación del mensaje): Es una porción de información utilizada para autenticar un mensaje.     23. TLS (Transport Layer Security): Es un protocolo criptográfico que proporciona comunicación de seguridad en la red. TLS y SSL cifrar los segmentos de conexiones de red por encima de la capa de transporte , utilizando criptografía simétrica de la vida privada y una clave de mensaje código de autenticación para la fiabilidad del mensaje. Varias versiones de los protocolos están en uso generalizado en aplicaciones como navegación web , correo
electrónico , fax por Internet , mensajería instantánea y voz sobre IP (VoIP). El protocolo TLS permite / servidor de aplicaciones de cliente para comunicarse a través de una red de una forma diseñada para prevenir escuchas ilegales y la manipulación 24. HTTP (Hypertext Transfer Protocol, protocolo de transferencia de hipertexto): Es el protocolo usado en cada transacción de la World Wide Web (es un sistema de distribución de información basado en hipertexto o hipermedias enlazados y accesibles a través de Internet.) 25. HTTPS (Hypertext Transfer Protocol Secure, Protocolo seguro de transferencia de hipertexto): Es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP. Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar HTTP. Es aquí cuando nuestro navegador nos advertirá sobre la carga de elementos no seguros (HTTP), estando conectados a un entorno seguro (HTTPS).  Los protocolos HTTPS son utilizados por navegadores Explorer, Mozilla Firefox, Opera y Google Chrome, entre otros. como: Safari, Internet
 El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no pueda ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar.  El puerto estándar para este protocolo es el 443. 26. FIRMAS DIGITALES: Una firma digital es una variedad de caracteres que acompaña a un archivo, de manera que autentifica al autor y que los datos se encuentren en perfecto estado. Sirve para demostrar la autenticidad de un mensaje digital o de un documento electrónico. Una firma digital da al destinatario seguridad en que el mensaje fue creado por el remitente, y que no fue alterado durante la transmisión. Las firmas digitales se utilizan comúnmente para la distribución de software, transacciones financieras y en otras áreas donde es importante detectar la falsificación y la manipulación. Consiste en un método criptográfico que asocia la identidad de una persona o de un equipo informático al mensaje o documento. En función del tipo de firma, puede, además, asegurar la integridad del documento o mensaje.
27. WEBMAIL: Es un cliente de correo electrónico, que provee una interfaz web por la que acceder al correo electrónico. Otras formas de acceder al correo electrónico pueden ser:  Conectándose con un cliente de correo local a un servidor de correo remoto utilizando un protocolo ad hoc de transporte de correo, como IMAP o POP, descargar los correos y almacenarlos localmente.  Utilizando un cliente de correo por consola. 28. CERTIFICADO DIGITAL: Un certificado digital (también conocido como certificado de clave pública o certificado de identidad) es un documento digital mediante el cual un tercero confiable (una autoridad de certificación) garantiza la vinculación entre la identidad de un sujeto o entidad (por ejemplo: nombre, dirección y otros aspectos de identificación) y una clave pública. Este tipo de certificados se emplea para comprobar que una clave pública pertenece a un individuo o entidad. Las existencia de firmas en los certificados aseguran por parte del firmante del certificado (una autoridad de certificación, por ejemplo) que la información de identidad y la clave pública perteneciente al usuario o entidad referida en el certificado digital están vinculadas. Existen variados formatos para certificados digitales, los más comúnmente empleados se rigen por el estándar UIT-T X.509. El certificado contiene usualmente lo siguiente: El nombre de la entidad certificada, Número de serie, Fecha de expiración del certificado, Una copia de la clave pública del titular del certificado (esta clave es utilizada para la verificación de su firma digital)
29. MBOX: Es un término genérico para una familia de formatos de fichero que se usan para almacenar conjuntos de correos electrónicos. Todos los mensajes en un buzón Mailbox están concatenados en un único fichero. El principio de cada mensaje está marcado por una línea que empieza por las cinco letras "From" (Desde), y una línea en blanco marca el final. Durante un tiempo el formato MBOX fue popular debido a que las herramientas de procesado de archivos de texto se podían usar muy fácilmente sobre el archivo de texto usado para almacenar los mensajes.  Al contrario de los protocolos de Internet usados para el intercambio de correo, el formato usado para almacenamiento del correo se dejó completamente en manos del desarrollador del cliente de correo electrónico. 30. AUTORIDAD CERTIFICADORA (Certification Authority): Es una entidad de confianza, responsable de emitir y revocar los certificados o certificados, utilizados en la firma electrónica, para lo cual se emplea la criptografía de clave pública. Jurídicamente es un caso particular de Prestador de Servicios de Certificación.
 Verifica la identidad del solicitante de un certificado antes de su expedición o, en caso de certificados expedidos con la condición de revocados, elimina la revocación de los certificados al comprobar dicha identidad. Los certificados son documentos que recogen ciertos datos de su titular y su clave pública y están firmados por la Autoridad de Certificación utilizando su clave privada. La Autoridad de Certificación es un tipo particular de Prestador de Servicios de Certificación que legitima ante los terceros que confían en sus certificados la relación entre la identidad de un usuario y su clave pública.  Un certificado revocado es un certificado que no es válido aunque se emplee dentro de su período de vigencia. Un certificado revocado tiene la condición de suspendido si su vigencia puede restablecerse en determinadas condiciones.  La Autoridad de Certificación es un tipo particular de Prestador de Servicios de Certificación que legitima ante los terceros que confían en sus certificados la relación entre la identidad de un usuario y su clave pública. La confianza de los usuarios en la CA es importante para el funcionamiento del servicio y justifica la filosofía de su empleo, pero no existe un procedimiento normalizado para demostrar que una CA merece dicha confianza. 31. LDAP (Lightweight Directory Access Protocol): Es un protocolo de aplicación para la lectura y edición de directorios a través de una IP. Un cliente inicia una sesión LDAP mediante la conexión a un servidor LDAP, llamado Directorio Agente del sistema (DSA), de forma predeterminada en TCP puerto 389. El cliente envía una solicitud de operación para el servidor y el servidor envía las respuestas a cambio. Con algunas excepciones, el cliente no tiene que esperar una respuesta antes de enviar la siguiente solicitud, y el servidor puede enviar las respuestas en cualquier orden. El cliente puede solicitar las siguientes operaciones:  TLS Inicio - utilizar el LDAPv3 Transport Layer Security (TLS) de extensión para una conexión segura.  Enlazar - autenticarse y especificar la versión del protocolo LDAP.  De la búsqueda - búsqueda y / o recuperar las entradas de la guía.  Comparar - prueba de si una entrada con nombre contiene un valor determinado atributo.  Añadir una nueva entrada.  Eliminar una entrada.  Modificar una entrada.  Modificar nombre completo (DN) - mover o cambiar el nombre de una entrada.  Abandonar - abortar una solicitud anterior.  Operación extendida - operación genérica utilizada para definir otras operaciones.  Separar - cerrar la conexión (no a la inversa de Enlace).
33. CATÁLOGO GLOBAL: Un catálogo global es un controlador de dominio que almacena una copia de todos los objetos de Active Directory en un bosque. El catálogo global almacena una copia completa de los objetos del directorio para su dominio host y una copia parcial de todos los objetos para todos los otros dominios del bosque, como se muestra en la siguiente imagen:
34. ANTISPYWARE (Programa Espía): Es un programa, que funciona dentro de la categoría malware, que se instala furtivamente en un ordenador para recopilar información sobre las actividades realizadas en éste. La función más común que tienen estos programas es la de recopilar información sobre el usuario y distribuirlo a empresas publicitarias u otras organizaciones interesadas, pero también se han empleado en organismos oficiales para recopilar información contra sospechosos de delitos, como en el caso de la piratería de software. Además pueden servir para enviar a los usuarios a sitios de internet que tienen la imagen corporativa de otros, con el objetivo de obtener información importante. 35. LLAVE PÚBLICA: Es el método criptográfico que usa un par de claves para el envío de mensajes. Las dos claves pertenecen a la misma persona a la que se ha enviado el mensaje. Una clave es pública y se puede entregar a cualquier persona, la otra clave es privada y el propietario debe guardarla de modo que nadie tenga acceso a ella. Además, los métodos criptográficos garantizan que esa pareja de claves sólo se puede generar una vez, de modo que se puede asumir que no es posible que dos personas hayan obtenido casualmente la misma pareja de claves. Si el remitente usa la clave pública del destinatario para cifrar el mensaje, una vez cifrado, sólo la clave privada del destinatario podrá descifrar este mensaje, ya que es el único que la conoce. Por tanto se logra la confidencialidad del envío del mensaje, nadie salvo el destinatario puede descifrarlo. Si el propietario del par de claves usa su clave privada para cifrar el mensaje, cualquiera puede descifrarlo utilizando su clave pública. En este caso se consigue por tanto la identificación y autentificación del remitente, ya que se sabe que sólo pudo haber sido él quien empleó su clave privada (salvo que alguien se la hubiese podido robar). Esta idea es el fundamento de la firma electrónica.
36. LLAVE PRIVADA: La llave privada es almacenada sólo en su computadora a través de su navegador Web. Dependiendo del Navegador Web que use y su configuración de seguridad, usted podría tener una contraseña asociada con su llave privada. Esto es protección adicional para usted, de tal forma que si alguien consigue su llave privada o usa su computadora, no puede usar la llave privada (o su Certificado Digital) La llave pública es utilizada por otras personas enviarle correo electrónico cifrado. También es usado para la autenticación de cliente asegurando que su Certificado Digital no es adulterado cuando usted lo envía de su computadora a un sitio Web.
37. CA RAÍZ (Certification Authority): Autoridad de certificación, certificadora o certificante, es una entidad de confianza, responsable de emitir y revocar los certificados digitales o certificados, utilizados en la firma electrónica, para lo cual se emplea la criptografía de clave pública. Jurídicamente es un caso particular de Prestador de Servicios de Certificación
38. USUARIO: Los usuarios deben poder acceder a recursos por todo el dominio usando un único acceso o log in a la red. Los administradores deben poder centralizar la gestión de usuarios y recursos. El directorio activo es un servicio de directorio. El término servicio de directorio se refiere a dos cosas – un directorio donde la información sobre usuarios y recursos está almacenada, y un servicio o servicios te dejan acceder y manipular estos recursos. El directorio activo es una manera de manejar todos los elementos de una red, incluidos ordenadores, grupos, usuarios, dominios, políticas de seguridad, y cualquier tipo de objetos definidos para el usuario. Además de esto, provee de funciones adicionales más allá de estas herramientas y servicios. 39. REGISTROS DNS:  A = Address – (Dirección) Este registro se usa para traducir nombres de hosts a direcciones IPv4.  AAAA = Address – (Dirección) Este registro se usa para traducir nombres de hosts a direcciones IPv6.  CNAME = Canonical Name – (Nombre Canónico) Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio. Es usado cuando se están corriendo múltiples servicios (como FTP y web server) en un servidor con una sola dirección IP. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com. y www.ejemplo.com.). Esto también es usado cuando corres múltiples servidores http, con diferentes nombres, sobre el mismo host.  NS = Name Server – (Servidor de Nombres) Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres.  MX (registro) = Mail Exchange – (Registro de Intercambio de Correo) Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio.  PTR = Pointer – (Indicador) También conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio.  SOA = Start of authority – (Autoridad de la zona) Proporciona información sobre la zona.  HINFO = Host INFOrmation – (Información del sistema informático) Descripción del host, permite que la gente conozca el tipo de máquina y sistema operativo al que corresponde un dominio.  TXT = TeXT - (Información textual) Permite a los dominios identificarse de modos arbitrarios.  LOC = LOCalización - Permite indicar las coordenadas del dominio.
 WKS - Generalización del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV.  SRV = SeRVicios - Permite indicar los servicios que ofrece el dominio.  SPF = Sender Policy Framework - Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts están autorizados a enviar correo desde el dominio dado. El servidor que recibe consulta el SPF para comparar la IP desde la cual le llega, con los datos de este registro.
40. CONTENEDOR: Se vincula a un contenedor del directorio activo (un sitio, un dominio o una unidad organizativa. El Controlador de Dominio informa al equipo cuáles son las GPOs que debe aplicar de acuerdo a dónde esté la cuenta de usuario. En nuestro caso: GPO1, GPO2, GPO3, GPO4 y GPO8. De estas GPOs se aplicará la parte Configuración de Usuario, se ejecutarán los scripts de inicio de sesión y finalmente se mostrará el escritorio del usuario. Luego que el Controlador de Dominio hace esta autenticación le pasa a la máquina la lista de GPOs que debe aplicar de acuerdo a la Unidad Organizativa donde ésta se encuentra.
41. UNIDAD ORGANIZATIVA (Organizational Unit, OU): Una Unidad Organizativa es un objeto del Directorio Activo que puede contener a otros objetos del directorio. Es decir, es un contenedor de otros objetos, de forma análoga a una carpeta o directorio en un sistema de archivos tradicional. En concreto, dentro de una unidad de este tipo pueden crearse cuentas de usuario, de grupo, de equipo, de recurso compartido, de impresora compartida, etc., además de otras unidades organizativas. 42. ADMINISTRADOR: Administra el sistema de replicación de archivos por el cual se replica la información de los controladores de dominio entre ellos. Desde Windows server 2008 se ha comenzado a usar esta tecnología. Sólo funciona cuando estás utilizando el nivel de funcionalidad Windows 2008 en todo el dominio. Los administradores del Directorio Activo deben ser considerados para administradores de servicios. Administración de Directorio Activo, Servidores, Computadoras de Escritorio y Portátiles Bajo Plataforma Windows. 43. ALMACEN DE BUZÓN: En ocasiones los buzones de los usuarios van creciendo de tamaño de tal forma que el almacén de buzones de Exchange puede llegar a agotar el espacio en disco, y a colapsar el S.O, siendo necesario entonces cambiarlo a otro volumen con espacio libre suficiente. En este caso, los usuarios de la organización fueron creciendo, y a pesar de tener muy limitados los tamaños de los buzones, obligando a los usuarios a archivar a menudo para aliviar el peso de su buzón, las BBDD de Exchange llenaron por completo el disco, hasta tal punto que el propio Exchange dejó de funcionar y el almacén de buzones desmontado. 44. NSLOOKUP: Es un programa, utilizado para saber si el DNS está resolviendo correctamente los nombres y las IP. Se utiliza con el comando nslookup, que funciona tanto en Windows como en UNIX para obtener la dirección IP conociendo el nombre, y viceversa. Permite consultar un servidor de nombres y obtener información relacionada con el dominio o el host y así diagnosticar los eventuales problemas de configuración que pudieran haber surgido en el DNS.
Utilizado sin ningún argumento, el comando nslookup muestra el nombre y la dirección IP del servidor de nombres primario y una invitación de comando para realizar consultas. Basta con introducir el nombre de un dominio en la invitación de comando para detallar las características. De la misma manera, es posible solicitar información sobre un host indicando su nombre seguido del comando nslookup. 45. NETSTAT (network statistics): Es una herramienta de línea de comandos que muestra un listado de las conexiones activas de un ordenador, tanto entrantes como salientes. Existen versiones de este comando en varios sistemas Como UNIX, GNU/Linux, Mac OS X, Windows y BeOS. La información que resulta del uso del comando incluye el protocolo en uso, las direcciones IP tanto locales como remotas, los puertos locales y remotos utilizados y el estado de la conexión. Existen, además de la versión para línea de comandos, herramientas con interfaz gráfica (GUI) en casi todos los sistemas operativos desarrollados por terceros. 46. IPCONFIG /ALL: Comando que muestra toda la información de configuración 47. PING: Comando que comprueba el estado de la conexión del host local con uno o varios equipos remotos por medio de el envío de paquetes ICMP de solicitud y de respuesta. Mediante esta utilidad puede diagnosticarse el estado, velocidad y calidad de una red determinada. Muchas veces se utiliza para medir la latencia o tiempo que tardan en comunicarse dos puntos remotos, y por ello, se utiliza el término PING para referirse al log o latencia de la conexión en los juegos en red. 48. FQDN (Fully Qualified Domain Name): Es un nombre que incluye el nombre de la computadora y el nombre de dominio asociado a ese equipo. Por ejemplo, dada la computadora llamada «serv1» y el nombre de dominio «bar.com», el FQDN será «serv1.bar.com», a su vez un FQDN asociado a serv1 podría ser «post.serv1.bar.com». La longitud máxima permitida para un FQDN es 255 caracteres (bytes), con una restricción adicional a 63 bytes por etiqueta dentro de un nombre de dominio. Las etiquetas FQDN se restringen a un juego de caracteres limitado: letras A-Z de ASCII, los dígitos, y el carácter «-», y no distinguen mayúsculas de minúsculas. 49. SERVIDOR: Equipo donde se van a encontrar todos los recursos a compartir, con esto me refiero tanto carpetas, como impresoras, grabadoras, lectores, entre otros. A parte del servidor encontramos diferentes equipos llamados clientes o estaciones de trabajo, que solo tendrán permisos sobre los recursos locales o del servidor, importante no de las otras estaciones de trabajo. Dependiendo del tipo de sistema operativo instalado en el servidor encontramos:  Servidor dedicado: Utilizado únicamente para gestionar los recursos de la red.  Servidor no dedicado: Que además de llevar la gestión de la red también puede funcionar como estación de trabajo. 50. NOMBRE DE EQUIPO: Es un nombre único y relativamente informal que se le da a un dispositivo conectado a una red informática. Puede ser un ordenador, un servidor de ficheros,
un dispositivo de almacenamiento por red, una máquina de fax, impresora, entre otros. En Internet, generalmente se trabaja con equipos funcionando como servidores (hosts), en estos casos el equivalente para "nombre de equipo" en inglés seria "hostname". Estos servidores siempre tienen una dirección IP asignada. 51. RED INTERNA: Una red de computadoras, también llamada red de ordenadores o red informática, es un conjunto de equipos informáticos conectados entre sí por medio de dispositivos físicos que envían y reciben impulsos eléctricos, ondas electromagnéticas o cualquier otro medio para el transporte de datos para compartir información y recursos. Este término también engloba aquellos medios técnicos que permiten compartir la información. 52. NAT (Network Address Translation - Traducción de Dirección de Red): Es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se asignan mutuamente direcciones incompatibles. Consiste en convertir en tiempo real las direcciones utilizadas en los paquetes transportados. También es necesario editar los paquetes para permitir la operación de protocolos que incluyen información de direcciones dentro de la conversación del protocolo. Su uso más común es permitir utilizar direcciones privadas para acceder a Internet. Existen rangos de direcciones privadas que pueden usarse libremente y en la cantidad que se quiera dentro de una red privada. Si el número de direcciones privadas es muy grande puede usarse solo una parte de direcciones públicas para salir a Internet desde la red privada. De esta manera simultáneamente sólo pueden salir a Internet con una dirección IP tantos equipos como direcciones públicas se hayan contratado. Esto es necesario debido al progresivo agotamiento de las direcciones IPv4. Se espera que con el advenimiento de IPv6 no sea necesario continuar con esta práctica. 53. FILTROS ISAPI: Un filtro ISAPI es un archivo DLL que se ejecuta en un servidor HTTP habilitado para ISAPI con objeto de filtrar los datos que viajan hacia o desde el servidor. El filtro registra notificaciones sobre eventos, como el inicio de sesión o la asignación de direcciones URL. Cuando se producen los eventos seleccionados, se llama al filtro y es posible supervisar y cambiar los datos (en su recorrido entre el servidor y el cliente, y al contrario). Los filtros ISAPI pueden utilizarse para proporcionar un registro mejorado de las solicitudes HTTP (por ejemplo, para controlar quién inicia sesión en el servidor), cifrado y compresión de archivos personalizados o métodos de autenticación adicionales. 54. HASH: Se refiere a una función o método para generar claves o llaves que representen de manera casi unívoca a un documento, registro, archivo, etc., resumir o identificar un dato a través de la probabilidad, utilizando una función hash o algoritmo hash. Un hash es el resultado de dicha función o algoritmo. Una función de hash es una función para resumir o identificar probabilísticamente un gran conjunto de información, dando como resultado un conjunto imagen finito generalmente menor (un subconjunto de los números naturales por ejemplo). Varían en los conjuntos de partida y de llegada y en cómo afectan a la salida similitudes o patrones de la entrada. Una propiedad fundamental del hashing es que si dos resultados de una misma función son diferentes, entonces las dos entradas que generaron dichos resultados también lo son.
55. CODIFICACIÓN BASE64: Es un sistema de numeración posicional que usa 64 como base. Es la mayor potencia de dos que puede ser representada usando únicamente los caracteres imprimibles de ASCII. La primera aplicación conocida de la codificación Base 64 para transmisiones electrónicas de datos fue el protocolo Privacy-enhanced Electronic Mail (PEM), define un esquema de caracteres imprimibles que usa Base 64 para transformar una secuenca arbitraria de octetos en un formato que puede ser expresado en líneas cortas de caracteres de 7 bits, tales como las necesarias en protocolos de transmisión como SMTP. 56. FIREWALL (CortaFuegos): Es una parte de un sistema o una red que está diseñada para bloquear el acceso no autorizado, permitiendo al mismo tiempo comunicaciones autorizadas. Se trata de un dispositivo o conjunto de dispositivos configurados para permitir, limitar, cifrar, descifrar, el tráfico entre los diferentes ámbitos sobre la base de un conjunto de normas y otros criterios. Los cortafuegos pueden ser implementados en hardware o software, o una combinación de ambos. 57. TCP/80: El puerto TCP 80 puede utilizar un protocolo definido para comunicarse dependiendo de la aplicación. Un protocolo es un conjunto de normas de carácter oficial que explique cómo los datos se comunican a través de una red. Piense en ello como la lengua hablada entre los equipos para ayudarles a comunicarse de manera más eficiente. Protocolo HTTP, por ejemplo, define el formato para la comunicación entre los navegadores de Internet y sitios web. Otro ejemplo es el protocolo IMAP, que define la comunicación entre servidores de correo electrónico IMAP y clientes o, por último, el protocolo SSL, que establece el formato a utilizar para las comunicaciones cifradas. 58. UDP/2409: Hace posible la transmisión de un mensaje de datagramas de un ordenador a una aplicación que se ejecuta en otro equipo. Al igual que TCP (Transmission Control Protocol), UDP se utiliza con IP (Protocolo de Internet) pero a diferencia de TCP en el puerto 2409, puerto UDP 2409 está sin conexión y no garantiza una comunicación fiable, sino que depende de la aplicación que recibió el mensaje en el puerto 2409 a la proceso de los errores y verificar la entrega correcta. Debido a que el protocolo del puerto UDP 2409 fue marcado como un virus (color rojo), no significa que un virus es a través del puerto 2409, pero que un troyano o virus ha usado este puerto en el pasado para comunicarse. 59. LDIF: es un formato que se utiliza para la importación y exportación de datos independientemente del servidor LDAP que se esté utilizando. 60. VIRTUAL LDAP: Es un conjunto de scripts de Perl que le permite aumentar los datos existentes en el servidor LDAP (que no desea modificar) usando ldap-rewrite.pl (con soporte para reescribir de solicitud de enlace, las solicitudes de búsqueda y las respuestas). 61. MAILDROP: Es el filtro de correo / agente de la entrega de correo que se utiliza por el servidor de correo Courier. No es necesario descargar buzón de aquí si ya tiene el servidor de correo de Correo instalado. Se trata de una construcción independiente del buzón electrónico de filtro que se puede utilizar con otros servidores de correo.
62. THUNDERBIRD: Es un cliente de correo electrónico de la Fundación Mozilla. Su objetivo es desarrollar un Mozilla más liviano y rápido mediante la extracción y rediseño del gestor de correo del Mozilla oficial. Es multiplataforma, utiliza el lenguaje de interfaz XUL y es software libre. 63. ROUNDCUBE: Es un cliente de correo que nos permite visualizar los mensajes de nuestras cuentas de email a través de una página web. Pudiendo acceder desde cualquier navegador con acceso a internet. Desde el podremos realizar todas las operaciones necesarias para gestionar nuestros correos e incluso usarlo como agenda de contactos y calendario. 64. POSTFIX: Es un servidor de correo de software libre / código abierto, un programa informático para el enrutamiento y envío de correo electrónico, creado con la intención de que sea una alternativa más rápida, fácil de administrar y segura al ampliamente utilizado Sendmail. 65. SENDMAIL (Agente de transporte de correo, MTA - Mail Transport Agent): consiste en "encaminar" los mensajes correos de forma que estos lleguen a su destino. Se afirma que es el más popular MTA, compatible con sistemas Unix y el responsable de la mayoría de envío del correo de internet, aunque se le critica su alto número de alertas de seguridad (la mayoría de ellas parcheadas a las pocas horas), además de no ser sencillo de configurar. 66. CENTOS (Community Enterprise Operating System): Es un clon a nivel binario de la distribución de Linux Red Hat Enterprise Linux RHEL, compilado por voluntarios a partir del código fuente liberado por Red Hat. 67. DOVECOT: Es un código abierto IMAP y POP3 servidor de correo electrónico para Linux /-como los sistemas UNIX, escrito con la seguridad Dovecot es una excelente opción tanto para instalaciones pequeñas y grandes. 68. OPENLDAP: Se trata de una implementación libre del protocolo que soporta múltiples esquemas por lo que puede utilizarse para conectarse a cualquier otro LDAP.
OpenLDAP tiene cuatro componentes principales     Slapd - demonio LDAP autónomo Slurpd - demonio de replicación de actualizaciones LDAP autónomo Rutinas de biblioteca de soporte del protocolo LDAP Utilidades, herramientas y clientes
13. DIFICULTADES PRESENTADAS DURANTE EL PROCESO
 En el momento de verificar la correcta funcionalidad del Servidor de Correo por medio del envío de mensajes y recepción de los mismos se nos presentaron problemas al comprobar la entrega de éste ya que dichos correos electrónicos se estaban almacenando con el nombre del e-mail completo para dicho usuario, lo cual no se relacionaba con el nombre en específico del usuario como tal. Dicho problema radicaba en que en el atributo maildrop especificado para cada usuario en el LDAP se había registrado con el correo electrónico, más no con su CN específico. Para la solución de éste inconveniente recurrimos a la asesoría del instructor y a la investigación de diferentes medios de consulta, logrando verificar que en los filtros configurados en el Dovecot para el almacenamiento del correo podíamos añadir la función “%u@lared.lab” para que la entrega de correos funcionara correctamente partiendo del usuario definido por el correo electrónico : /usuario@lared.lab/Maildir. Al final decidimos modificar el campo del atributo MAILDROP en el Servicio de Directorio Ligero LDAP y modificar nuevamente los filtros en el Dovecot con el fin de que el correo se almacenara de la siguiente forma: /usuario/Maildir.
 La implementación de una Plataforma de Correo Segura, implica utilizar una serie de aplicaciones, parámetros, protocolos y servicios que ejecuten la utilización de los diferentes agentes que interactúan entre sí en dicha interconexión con el fin de dar una solución estratégica de mensajería electrónica para una empresa u organización que requiera de su utilización y funcionamiento interno, integro, confidencial, seguro y que ésta a su vez se encuentre a disposición de los usuarios cuando éstos requieran de su uso y ejecución.  Es indispensable tener en cuenta que una Plataforma de Correo debe estar configurada para emitir, recibir y reenviar correos utilizando una serie de protocolos de seguridad como lo son TLS y SSL; los cuales deben ser aplicados y configurados en toda la infraestructura de red para ejecutar la transferencia de mensajes cifrados que sólo se encuentren disponibles para los destinatarios correspondientes y que dicho mensaje se mantenga íntegro durante su proceso de envío y recepción.  Para implementar una Aplicación tipo cliente (MUA) que utilice elun canal de comunicación cifrado para el envío de correos es necesario solicitar un certificado a una Autoridad Certificadora (AC) que garantice y firme dicha plantilla que lo conforma con el fin de que éste sea emitido nuevamente al cliente o usuario que lo requiere para su aplicación de acuerdo al servicio que se encuentra prestando. El Certificado Digital contiene una serie de parámetros que lo identifican como lo son el nombre de la Autoridad Certificadora por el que fue emitido, el usuario por quien fue solicitado a quien va dirigido para su utilización, la fecha de vigencia para el certificado y la firma representada en un código Hash que será la llave que permitirá la ejecución de dicho documento.  El objetivo principal de la utilización de esta validación es garantizar que una aplicación determinada va a realizar la transferencia de datos de forma cifrada entre el emisor y el destinatario brindando a los usuarios del servicio seguridad para su información basada en INTEGRIDAD, CONFIDENCIALIDAD, DISPONIBILIDAD y AUTENTICACIÓN.
 http://cursos.redsena.net  http://es.wikipedia.org/wiki/RoundCube  http://es.wikipedia.org/wiki/Mozilla_Thunderbird  http://es.wikipedia.org/wiki/MySQL  http://en.wikipedia.org/wiki/Kerberos_(protocol)  http://en.wikipedia.org/wiki/Authentication  http://es.wikipedia.org/wiki/Transport_Layer_Security  http://es.wikipedia.org/wiki/SASL  http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer  http://es.wikipedia.org/wiki/Transport_Layer_Security  http://es.wikipedia.org/wiki/OpenLDAP  http://taquiones.net/sysadmin/maildrop_notes.html#index1h1  http://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica  http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/x-087-2-resolv.named.html  http://es.wikipedia.org/wiki/Domain_Name_System  http://es.wikipedia.org/wiki/Dominio_de_internet  http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-openldap-samba-cups python/htmls/openldap-que-es-slapd.html  http://es.wikipedia.org/wiki/OpenSSL  http://es.wikipedia.org/wiki/Servidor_de_correo_electr%C3%B3nico  http://www.akeebabackup.com/software/admin-tools.html
 http://translate.google.com.co/translate?hl=es&sl=en&u=http://www.ohloh.net/p/virtualldap&ei=OyaJTerqJqS10QHHhc39DQ&sa=X&oi=translate&ct=result&resnum=2&ved=0CCM Q7gEwAQ&prev=/search%3Fq%3Dvirtual%2Bldap%26hl%3Des%26biw%3D1440%26bih% 3D809%26prmd%3Divns  http://translate.google.com.co/translate?hl=es&sl=en&u=http://myvd.sourceforge.net/&ei=Oy aJTerqJqS10QHHhc39DQ&sa=X&oi=translate&ct=result&resnum=1&ved=0CBsQ7gEwAA& prev=/search%3Fq%3Dvirtual%2Bldap%26hl%3Des%26biw%3D1440%26bih%3D809%26pr md%3Divns
More From This UserSOLUCIONES_PERIMETRALES_SEGURIDAD PERIMETRAL CON FIREWALLS EN ZENTYAL_38110SOLUCIONES_ PERIMETRALES_SOLUCIÓN DE ACELERACIÓN Y FILTRADO WEB (PROXY) EN ZENTYAL_38110SOLUCIONES_ PERIMETRALES_SOLUCIÓN DE CONECTIVIDAD REMOTA (SITE TO SITE)_38110Soluciones Perimetrales Seguridad Perimetral Con Firewalls Taller 38110VULNERABILIDAD MAJORDOMO2 - DIRECTORY TRAVERSAL (SMTP/HTTP)VULNERABILIDAD EN SERVIDOR APACHE - COYOTE 1.1 (TOMCAT 5.5)VULNERABILIDAD EN SERVIDOR APACHE 2.2.8 APLICACIÓN TIKIWIKITOPOLOGÍA_DE_RED_GESTIÓN Y MONITOREO (WINDOWS SERVER 2008)TOPOLOGÍA_LÓGICA_DE_RED_GESTIÓN Y MONITOREO (LINUX - FEDORA)PROYECTO_SERVIDOR_DE_CORREO_LINUX_-_CENTOSTOPOLOGÍA_LÓGICA_DE_LA_RED_(PLATAFORMA_DE_CORREO_SEGURA_CENTOS)_LARED38110Proyecto Plataforma de Correo Segura Lared38110 TOPOLOGÍA_LÓGICA_DE_LA_RED_(PLATAFORMA_DE_CORREO_SEGURA)_LARED38110RESUMEN_CAPITULO6_PANDUIT_INTRODUCCIÓN A LOS ESTÁNDARES DEL CABLEADO_ERIKA STEPHANY FRANCOSENA_PRESENTACION_INGLES_CAPITULO6_PANDUIT_LARED38110GLOSARIO_CAPITULO7 - PANDUIT_LARED38110GLOSARIO_CAPITULO6 - PANDUIT_LARED38110RESUMEN_CAPITULO 7_PANDUIT_ CABLEADO ESTRUCTURADO_ERIKA STEPHANY FRANCOPRESENTACION_MEDIOS Y SEÑALES_ACTIVIDAD1_LARED38110_SENA._SENA_PRESENTACIÓN_INGLÉS_CAPÍTULO7_PANDUIT_LARED38110_SENA_PRESENTACIÓN_CAPÍTULO7_PANDUIT_LARED38110SENA_PRESENTACIÓN_CAPÍTULO6_PANDUIT_LARED38110_MANUAL_APLICACIÓN_WEB_PRESTASHOP_WINDOWS_SERVER_2008_LARED38110PRESENTACIÓN_APACHE_EN_LINUX_LARED38110
Sign up to vote on this titleUsefulNot usefulPROYECTO_SERVIDOR_DE_CORREO_LINUX_-_CENTOS by lared38110EmbedDownloadInterests: Topics, Art & DesignRead on Scribd mobile: iPhone, iPad and Android.Copyright: Attribution Non-Commercial (BY-NC)Download as PDF, TXT or read online from ScribdFlag for inappropriate contentMore informationShow less
RelatedProyecto_servidor de Correo_linux - Centosby gotita55Servidor de Correo Centos-linuxby camilo_skate598servidor correo centos 6by Christian Amaya GómezManual de Configuración de un servidor FTP en Linuxby Roger Armando Contreras CorralesSimilar to PROYECTO_SERVIDOR_DE_CORREO_LINUX_-_CENTOSProyecto_servidor de Correo_linux - CentosServidor de Correo Centos-linuxservidor correo centos 6Manual de Configuración de un servidor FTP en LinuxInstalacion de Un Servidor de Correo en Windows Server 2008PROYECTO_SERVIDOR_DE_CORREO_LINUX_-_CENTOS

References: RESOLUCIÓN 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución