Administración de servicios de red con Red Hat/Fedora Linux
Tabla de contenido Introducción a TCP/IP..........................................................................................................9 Introducción al protocolo TCP/IP.....................................................................................10 Familia de Protocolos TCP/IP ....................................................................................10 Protocolo IP - Direccionamiento IP ............................................................................10 Clasificación de direcciones IP....................................................................................12 Direcciones IP reservadas..........................................................................................13 Máscaras de subred....................................................................................................13 Protocolo ARP.............................................................................................................14 Protocolo ICMP...........................................................................................................14 Protocolo IGMP ..........................................................................................................15 UDP (User Datagram Protocol - Protocolo de Datagrama de Usuario)......................15 TCP (Transmission Control Protocol - Protocolo de Control de la Transmisión) ...... 16 Comparación de TCP y UDP .....................................................................................16 Configuración de dispositivos de red............................................................................. 17 Detección y configuración del hardware..........................................................................18 Scripts de red...................................................................................................................19 Ficheros de configuración de red................................................................................19 Ficheros de configuración de interfaz.........................................................................20 Interfaces Ethernet......................................................................................................20 Interfaces de acceso telefónico...................................................................................21 Otras interfaces...........................................................................................................22 Ficheros alias y clon....................................................................................................22 Scripts de control de interfaz.......................................................................................23 Asignación de parámetros de red....................................................................................24 Nombre del host .........................................................................................................25 Dirección IP, máscara de sub-red y puerta de enlace................................................25 Servidores de nombres de dominio............................................................................ 25 Agregar rutas adicionales............................................................................................26 Función de Re-envío de paquetes para IP versión 4..................................................26 Función Zeroconf.........................................................................................................26 Verificación de la configuración...................................................................................27 La herramienta ethtool.....................................................................................................27 Network File System (NFS)...............................................................................................29
Network File System (NFS).............................................................................................30 NFS y portmap............................................................................................................30 Trabajando con portmap.............................................................................................30 Archivos de configuración del servidor NFS................................................................... 32 /etc/exports..................................................................................................................33 Archivos de configuración de clientes NFS.................................................................35 /etc/fstab......................................................................................................................35 Opciones de montaje NFS comunes.......................................................................... 36 Resolución de problemas de NFS con portmap..............................................................37 Dynamic Host Configuration Protocol (DHCP)...............................................................39 Dynamic Host Configuration Protocol (DHCP)................................................................40 Motivos para usar el protocolo DHCP.........................................................................40 Configuración de un servidor DHCP...............................................................................40 Archivo de configuración.............................................................................................40 Parámetro Range (Rango)..........................................................................................42 Dirección IP estática con DHCP .................................................................................42 Base de datos de arrendamiento................................................................................42 Arranque y parada del servidor.......................................................................................43 Agente de retransmisión DHCP......................................................................................43 Interconexión con Windows - SAMBA ............................................................................45 Configuración de SAMBA................................................................................................46 Configuración de la sección [global] de servidor SAMBA ..........................................46 Configuración de la sección [shares] de servidor SAMBA .........................................49 Accediendo a recursos SAMBA......................................................................................52 Escenarios típicos............................................................................................................53 Servidor proxy Squid ........................................................................................................55 Servidor proxy Squid.......................................................................................................56 Configuración básica.......................................................................................................56 Parámetro http_port.....................................................................................................57 Parámetro cache_mem...............................................................................................57 Parámetro cache_dir...................................................................................................58 Parámetro ftp_user......................................................................................................59
3
Ing. Ivan Ferreira
Control de acceso........................................................................................................59 Reglas de Control de Acceso......................................................................................60 Parámetro cache_mgr.................................................................................................61 Parámetro cache_peer: caches padres y hermanos..................................................61 Aplicando Listas y Reglas de control de acceso.............................................................62 Control de acceso - Caso 1.........................................................................................62 Control de acceso - Caso 2.........................................................................................62 Proxy Transparente.........................................................................................................63 Proxy transparente - Regla de iptables.......................................................................64 Estableciendo el idioma por defecto................................................................................64 Iniciando el servicio al arranque del sistema...................................................................65 Depuración de errores.....................................................................................................65 Very Secure FTP Daemon (VSFTPD) .............................................................................. 66 Configuración inicial.........................................................................................................67 Control del servicio vsftpd ...............................................................................................68 Control de acceso de los usuarios..................................................................................69 Usuarios anónimos......................................................................................................69 Usuarios locales..........................................................................................................69 Berkeley Internet Name Domain (BIND).......................................................................... 73 Introducción a DNS..........................................................................................................74 Tipos de zonas de los servidores de nombres................................................................75 BIND como un servidor de nombres...............................................................................76 El archivo /etc/named.conf..........................................................................................77 Etiquetas de comentarios............................................................................................77 Declaración acl............................................................................................................77 Declaración include.....................................................................................................79 Declaración options.....................................................................................................79 Declaración zone.........................................................................................................81 Ejemplo de declaraciones de zone.............................................................................83 Otros tipos de declaraciones.......................................................................................85 Archivos de zona.........................................................................................................86 Registros de recursos de archivos de zona................................................................87
Red Hat Certified Engineer
4
Registro SOA (Start Of Authority)...............................................................................87 Registro NS (Name Server)........................................................................................88 Registro A (Address)...................................................................................................89 Registro CNAME (Cannonical Name).........................................................................89 Registro CNAME (Cannonical Name).........................................................................89 Registro PTR (PoinTeR).............................................................................................90 Ejemplo de archivo de zonas......................................................................................90 Archivos de zona de resolución de nombres inversa................................................. 91 Uso de rndc......................................................................................................................92 Configuración de /etc/named.conf para rndc..............................................................92 Configuración de /etc/rndc.conf...................................................................................93 Opciones de línea de comandos de rndc....................................................................93 Servidor Apache HTTP .....................................................................................................95 Directivas de configuración en httpd.conf....................................................................... 96 Sugerencias de configuración generales....................................................................96 Directiva ServerRoot...................................................................................................97 Directiva PidFile...........................................................................................................97 Directiva Timeout.........................................................................................................97 Directiva KeepAlive.....................................................................................................97 Directiva MaxKeepAliveRequests...............................................................................97 Directiva KeepAliveTimeout........................................................................................98 Directivas MinSpareServers y MaxSpareServers.......................................................98 Directiva StartServers..................................................................................................98 Directiva MaxClients....................................................................................................98 Directiva Listen............................................................................................................98 Directiva Include..........................................................................................................99 Directiva User..............................................................................................................99 Directiva Group............................................................................................................99 Directiva ServerAdmin.................................................................................................99 Directiva ServerName...............................................................................................100 Directiva DocumentRoot...........................................................................................100 Directiva DirectoryIndex............................................................................................100
5
Ing. Ivan Ferreira
Directiva AccessFileName........................................................................................101 Directiva HostnameLookups.....................................................................................101 Directiva ErrorLog......................................................................................................101 Directiva LogLevel.....................................................................................................101 Directiva ServerSignature.........................................................................................101 Directiva Redirect......................................................................................................102 Configuración de directorios .........................................................................................102 Directiva Alias............................................................................................................102 Directiva ScriptAlias...................................................................................................102 Directiva AddHandler.................................................................................................103 Directiva Directory.....................................................................................................103 Directiva Options.......................................................................................................104 Directiva AllowOverride.............................................................................................104 Directiva Order..........................................................................................................105 Directiva UserDir.......................................................................................................105 Arrancar y detener httpd................................................................................................106 Configuración de máquinas virtuales............................................................................107 Directiva NameVirtualHost........................................................................................107 Directiva VirtualHost..................................................................................................107 Máquinas Virtuales....................................................................................................107 Ejemplo de creación de máquinas virtuales..............................................................108 Configuración de autenticación para el acceso a directorios........................................109 Configuración del Servidor Seguro Apache HTTP........................................................109 Vista preliminar de los paquetes relacionados con la seguridad..............................110 Vista preliminar de certificados y seguridad..............................................................110 Generar una clave.....................................................................................................111 Generar una petición de certificado para enviarla a un CA......................................113 Creación de un certificado autofirmado.................................................................... 115 Probar su certificado..................................................................................................115 Forzar el uso del modo SSL......................................................................................116 Servicios de correo electrónico.....................................................................................117 Postfix............................................................................................................................118
Red Hat Certified Engineer
6
Arquitectura de Postfix..............................................................................................118 Archivos de configuración de Postfix........................................................................120 EL archivo main.cf.....................................................................................................121 Directivas adicionales................................................................................................122 Direcciones canónicas..............................................................................................122 Usuarios reubicados..................................................................................................123 Listas de correo.........................................................................................................123 Administración de colas............................................................................................124 Herramientas de gestión de colas.............................................................................125 Listar mensajes.........................................................................................................126 Borrando mensajes...................................................................................................126 Reteniendo mensajes................................................................................................126 Reencolando mensajes.............................................................................................127 Mostrando mensajes.................................................................................................127 Liberando mensajes..................................................................................................127 Mapas de transporte..................................................................................................127 Gateway de reenvío interno......................................................................................129 Reenvío de correo saliente.......................................................................................129 Enmascarando nombres de host..............................................................................130 Sendmail........................................................................................................................131 Confirmando la instalación de Sendmail...................................................................131 Configurando Sendmail.............................................................................................131 Control de RELAY.....................................................................................................132 Inicio del servicio sendmail .......................................................................................134 Administrando los aliases..........................................................................................134 Cómo usar un anfitrión inteligente............................................................................ 136 Central de correo.......................................................................................................136 Habilitando los servicios POP3 e IMAP.........................................................................137 Dovecot......................................................................................................................137 Configuración de Webmail.............................................................................................137 Secure Shell .....................................................................................................................139 Secure Shell...................................................................................................................140
7
Ing. Ivan Ferreira
El demonio SSH............................................................................................................140 Control del servicio SSH................................................................................................142 Cliente SSH para Windows...........................................................................................143 Transferencias de archivos de forma segura................................................................143 Secure copy...............................................................................................................144 Network Time Protocol....................................................................................................145 Convenciones generales...............................................................................................146 Zonas horarias...............................................................................................................147 Daylight Savings Time...............................................................................................147 Los archivos de zona horaria ...................................................................................147 El proyecto pool.ntp.org ................................................................................................149 Configuración de NTP...................................................................................................150 Solución de problemas...................................................................................................154 Diagnóstico y solución de problemas de red y servicios...............................................155
Red Hat Certified Engineer
8
1
Introducción a TCP/IP
Introducción a TCP/IP
Introducción a TCP/IP Introducción al protocolo TCP/IP Los protocolos establecen una descripción formal de los formatos que deben representar los mensajes para poder ser intercambiados por equipos de cómputo; además definen las reglas que ellos deben seguir para lograrlo.
Familia de Protocolos TCP/IP El protocolo TCP/IP está compuesto por varios protocolos que proveen distintas funciones relacionadas con la capa del modelo OSI en que se encuentran. Los protocolos que conforman el TCP/IP y su relación con el modelo OSI son: Modelo OSI
Modelo TCP/IP
Suite de protocolos TCP/IP
Aplicación
FTP – DNS – SMTP – SSH – WWW
Transporte
Transporte
TCP – UDP
Red
Internet
IP – ARP – ICMP - IGMP
Aplicación Presentación Sesión
Enlace Físico
Interface de red
Ethernet
Token Ring
Frame Relay
ATM
Protocolo IP - Direccionamiento IP Las direcciones de Internet pueden ser simbólicas o numéricas. La forma simbólica es más fácil de leer, por ejemplo: www.redhat.com. La forma numérica es un número binario sin signo de 32 bits, habitualmente expresado en forma de números decimales separados por puntos. Por ejemplo, 9.167.5.8 es una dirección de Internet válida. La forma numérica es usada por el software de IP. La función de mapeo entre los dos la realiza el DNS (Domain Name System) discutido posteriormente. Primeramente examinaremos la forma numérica, denominada dirección IP. La dirección IP Para ser capaz de identificar una máquina en Internet, a cada interfaz de red de la máquina o host se le asigna una dirección, la dirección IP, o dirección de Internet. Red Hat Certified Engineer
10
Introducción a TCP/IP
Las direcciones IP son números de 32 bits representados habitualmente en formato decimal (la representación decimal de cuatro valores binarios de 8 bits concatenados por puntos). Por ejemplo128.2.7.9 es una dirección IP. Las direcciones IP son usadas por el protocolo IP(ver Internet Protocol (IP)) para definir únicamente un host en la red. El formato binario para la dirección IP 128.2.7.9 es: Decimal
Binario
128.2.7.9
10000000.00000010.00000111.00001001
Una dirección IP se compone de dos partes, una de ellas identifica la red a la que pertenece el host (equipo) y otra identifica al equipo en sí. Las direcciones IP deben ser únicas y no deben repetirse dentro de una misma red. Los host que desean comunicarse entre sí en una red, deben tener configurados la misma dirección de red. Puede pensar en esta dirección como el código de área de un número telefónico. Para todos los números de Ciudad del Este son iguales. Cada dispositivo dentro de una red debe tener una única dirección de host. Puede considerar que esta dirección es el número específico de teléfono con quien se desea comunicar en C.E. Existen reglas que definen que parte de la dirección IP identifica a la red y que parte identifica al host. Estas reglas son conocidas como Clases de direcciones IP. Hay cinco clases de direcciones IP: 0
8
16
Redes
24
Clase A
0
Clase B
10
Clase C
110
Clase D
1110
Multicast
Clase E
1111
Resevado
31
Hosts Redes
Hosts Redes
Hosts
Solo las clases A, B y C son utilizadas para redes empresariales. Las direcciones de clase A usan 7 bits para el número de red permitiendo 126 posibles redes(veremos posteriormente que de cada par de direcciones de red y de host, dos tienen un significado especial). Los restantes 24 bits se emplean para el número de host, de modo que cada red tener hasta 16,777,214 hosts. Las direcciones de clase B usan 14 bits para el número de red, y 16 bits para el de host, lo que supone 16382 redes de hasta 65534 hosts cada una. 11
Ing. Ivan Ferreira
Introducción a TCP/IP
Las direcciones de clase C usan 21 bits para el número de red y 8 para el de host, lo que supone 2,097,150 redes de hasta 254 hosts cada una. Las direcciones de clase D se reservan para multicasting o multidifusión, usada para direccionar grupos de hosts en un área limitada. Las direcciones de clase E se reservaron para usos en el futuro.
Clasificación de direcciones IP Las direcciones IP se clasifican en: ●
Direcciones IP públicas. Son visibles en todo Internet. Un ordenador con una IP pública es accesible (visible) desde cualquier otro ordenador conectado a Internet. Para conectarse a Internet es necesario tener una dirección IP pública.
●
Direcciones IP privadas (reservadas). Son visibles únicamente por otros hosts de su propia red o de otras redes privadas interconectadas por ruteadores. Se utilizan en las empresas para los puestos de trabajo. Los ordenadores con direcciones IP privadas pueden salir a Internet por medio de un ruteador (o proxy) que tenga una IP pública. Sin embargo, desde Internet no se puede acceder a ordenadores con direcciones IP privadas.
A su vez, las direcciones IP pueden ser: ●
Direcciones IP estáticas (fijas). Un host que se conecte a la red con dirección IP estática siempre lo hará con una misma IP. Las direcciones IP públicas estáticas son las que utilizan los servidores de Internet con objeto de que estén siempre localizables por los usuarios de Internet. Estas direcciones deben ser contratarlas.
●
Direcciones IP dinámicas. Un host que se conecte a la red mediante dirección IP dinámica, cada vez lo podría hacer con una dirección IP distinta. Para ello es necesario que en la red exista un servidor DHCP (Dynamic Host Configuration Protocol).
Clase
Formato
A
r.h.h.h
B C
Red Hat Certified Engineer
Número de Redes
Número de Hosts
Rango de direcciones
Máscara por defecto
16777214
0.0.0.0127.0.0.0
255.0.0.0
128
65534
128.0.0.0191.255.0.0
255.255.0.0
16384 2097152
254
r.r.h.h r.r.r.h
192.0.0.0255.255.255.0 223.255.255.0
12
Introducción a TCP/IP
Direcciones IP reservadas Las siguientes direcciones IP pueden ser utilizadas dentro de una red privada (empresarial) sin requerir autorización de una organización de asignación de direcciones IP. ●
Clase A: 10.0.0.0
●
Clase B: 172.16.0.0 - 172.31.0.0
●
Clase C: 192.168.0.0 - 192.168.255.0
Direcciones especiales que no pueden ser utilizadas: ●
0.0.0.0 esta reservada para la puerta de enlace por defecto (default gateway ).
●
127.0.0.0 esta reservada para la tarjeta de red loopback en cada host (127.0.0.1) utilizada para comunicación dentro del mismo host y diagnóstico.
●
Todos los bits de la porción de hosts a 0: Ej. 192.168.0.0 Este es el número que identifica a la red.
●
Todos los bits de la porción de hosts a 1: Ej. 192.168.255.255 Este es el número de broadcast. El broadcast es una dirección utilizada para enviar mensajes a todos los hosts de la red.
Máscaras de subred Los Id. de red y de host en una dirección IP se distinguen mediante una máscara de subred. Cada máscara de subred es un número de 32 bits que utiliza grupos de bits consecutivos de todo unos (1) para identificar la parte de Id. de red y todo ceros (0) para identificar la parte de Id. de host en una dirección IP. Por ejemplo, la máscara de subred que se utiliza normalmente con la dirección IP 131.107.16.200 es el siguiente número binario de 32 bits: Decimal
Binario
255.255.0.0
11111111.11111111.00000000.00000000
Este número de máscara de subred está formado por 16 bits uno seguidos de 16 bits cero, lo que indica que las secciones de Id. de red e Id. de host de esta dirección IP tienen una longitud de 16 bits. Normalmente, esta máscara de subred se muestra en notación decimal con puntos como 255.255.0.0.
13
Ing. Ivan Ferreira
Introducción a TCP/IP
Normalmente, los valores predeterminados de máscara de subred (como se muestra en la tabla anterior) son aceptables para la mayor parte de las redes sin requisitos especiales en las que cada segmento de red IP corresponde a una única red física. En algunos casos, puede utilizar máscaras de subred personalizadas para implementar la creación de subredes IP. Con la creación de subredes IP, se puede subdividir la parte de Id. de host predeterminada en una dirección IP para especificar subredes, que son subdivisiones del Id. de red basado en la clase original. Al personalizar la longitud de la máscara de subred, puede reducir el número de bits que se utilizan para el Id. de host actual. Para evitar problemas de direcciones y enrutamiento, debe asegurarse de que todos los equipos TCP/IP de un segmento de la red utilizan la misma máscara de subred.
Protocolo ARP Dentro de una misma red, las máquinas se comunican enviándose tramas físicas. Las tramas Ethernet contienen campos para las direcciones físicas de origen y destino (6 bytes cada una) también conocidas como MAC address. El MAC address es una dirección que está grabada en cada tarjeta de red y es única para cada tarjeta fabricada en el mundo. Por ejemplo puede ser representado de la siguiente forma: ●
08-00-4c-85-fc-8c
●
08:00:4c:85:fc:8c
El problema que se nos plantea es cómo podemos conocer la dirección física de la máquina destino. Necesitamos obtener la dirección física de un ordenador a partir de su dirección IP. Esta es justamente la misión del protocolo ARP (Address Resolution Protocol, protocolo de resolución de direcciones).
Protocolo ICMP Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol, protocolo de mensajes de control y error) se encarga de informar al origen si se ha producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de notificar los errores, sino que también transporta Red Hat Certified Engineer
14
Introducción a TCP/IP
distintos mensajes de control. Campo de tipo
Tipo de mensaje ICMP
0
Respuesta de eco (Echo Reply)
3
Destino inaccesible (Destination Unreachable)
4
Disminución del tráfico desde el origen (Source Quench)
5
Redireccionar, cambio de ruta (Redirect)
8
Solicitud de eco (Echo)
11
Tiempo excedido para un datagrama (Time Exceeded)
12
Problema de Parámetros (Parameter Problem)
13
Solicitud de marca de tiempo (Timestamp)
14
Respuesta de marca de tiempo (Timestamp Reply)
15
Solicitud de información, obsoleto (Information Request)
16
Respuesta de información, obsoleto (Information Reply)
17
Solicitud de máscara (Addressmask)
18
Respuesta de máscara (Addressmask Reply)
Protocolo IGMP Este protocolo esta íntimamente ligado a IP. Se emplea en maquinas que emplean IP multicast . El IP multicast es una variante de IP que permite emplear datagramas con múltiples destinatarios.
UDP (User Datagram Protocol - Protocolo de Datagrama de Usuario) UDP es uno de los dos principales protocolos que residen por encima de IP. Ofrece servicio a las aplicaciones de red de usuario. Algunos ejemplos de aplicaciones de red que usan UDP son: NFS (Network File System - Sistema de Archivos de Red) y SNMP (Simple Network management Protocol - Protocolo de administración de Red Simple). El servicio es un poco más que un interface a IP. UDP es un servicio de entrega de datagramas no orientado a conexión, lo cual no garantiza la entrega. UDP no mantiene una conexión de extremo a extremo con el módulo UDP remoto; simplemente envía el datagrama a la red y acepta datagramas de entrada de la red. UDP añade dos valores a los servicios provistos por IP. Uno de ellos es la multiplexación de la información entre aplicaciones basándose en el número de puerto. El otro es una suma de comprobación (checksum) para comprobar la integridad de los datos. 15
Ing. Ivan Ferreira
Introducción a TCP/IP
TCP (Transmission Control Protocol - Protocolo de Control de la Transmisión) TCP ofrece un servicio diferente que UDP. TCP ofrece un flujo de bytes orientado a conexión, en lugar de un servicio de entrega de datagramas no orientado a conexión. TCP garantiza la entrega, mientras que UDP no lo hace. TCP es usado por las aplicaciones de red que quieren garantía de entrega y no pueden ser molestados haciendo time-outs (tiempo de espera agotado) y retransmisiones. Las dos aplicaciones de red más típicas que usan TCP son FTP (File Transfer Protocol Protocolo de Transferencia de Ficheros), SSH o TELNET. La mayor capacidad de TCP no es gratis: requiere más CPU y ancho de banda de red. Las interioridades del módulo TCP son mucho más complicadas que las de un módulo UDP.
Comparación de TCP y UDP El TCP es un protocolo de comunicación entre dos máquinas con: ●
Negociación de conexión
●
Acuse de recibo de cada paquete
●
Control de no duplicidad de paquetes
●
Inmune a la llegada desordenada de paquetes
●
Inmune a la perdida de paquetes (se solicitan otra vez)
UDP es un protocolo simple para transferir datos sin toda la sobrecarga del TCP y sin ninguna de sus virtudes. En las conexiones UDP no hay negociación, ni acuse de recibo, ni control de perdida o desorden o duplicación de paquetes, todo esto debe ser gestionado por el servicio que emplea la conexión.
Red Hat Certified Engineer
16
2
Configuración de dispositivos de red
Configuración de dispositivos de red
Configuración de dispositivos de red
Detección y configuración del hardware La detección del hardware es realizada o bien por el programa de instalación, o bien a través de kudzu, un daemon que inicia con el sistema y que se encarga de detectar y configurar los dispositivos de hardware instalados. En términos generales, no hace falta configurar parámetro alguno mientras los dispositivos de red sean compatibles y exista un controlador para la versión del kernel ejecutado. Si acaso no fuese detectado el dispositivo de red debido a la ausencia de kudzu, es posible configurar todo manualmente. La marca de la tarjeta de red es lo que menos interesa, lo que es importante es que se determine con exactitud que chipset utiliza la tarjeta de red. Esto puede determinarse examinando físicamente la tarjeta de red o bien examinando a detalle la salida en pantalla que se obtiene al ejecutar el siguiente comando: # less /proc/pci # lspci -v
Lo cual devuelve una salida similar a las siguiente (en el caso de una tarjeta 3Com 905 C) Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 120).
Debe editarse con un procesador de textos /etc/modules.conf (kernel 2.4) o /etc/modprobe.conf (kernel 2.6) y debe verificarse que el módulo de su tarjeta de red realmente este especificado correctamente. Ejemplo: alias eth0 3c59x
Si se realizó alguna edición de este fichero, deberá de ejecutarse el siguiente comando, a fin de actualizar dependencias: # /sbin/depmod -a
Si utiliza kernel 2.4.x, la lista de módulos existentes en su equipo que puede utilizar para distintos chipsets de distintas tarjetas de red se puede obtener enlistando el contenido del directorio /lib/modules/[versión de su kernel]/kernel/drivers/net/. Ejemplo: # ls /lib/modules/2.4.9-ac10/kernel/drivers/net/
Si utiliza kenel 2.6, la lista de módulos existentes en su equipo puede obtenerla del mismo modo que la versión 2.4.x, o utilizar el comando:
Red Hat Certified Engineer
18
Configuración de dispositivos de red # modprobe -t net -l
Scripts de red Usando Red Hat Linux, todas las comunicaciones de red acontecen entre interfaces, que son dispositivos de red conectados al sistema, configurados de un modo determinado y usando un protocolo, al menos, para intercambiar datos con otros sistemas. Los diferentes tipos de interfaz que existen son tan variados como los dispositivos que los soportan. Los ficheros de configuración para las diferentes interfaces de red y scripts para activarlos o desactivarlos están ubicados en el directorio /etc/sysconfig/networkscripts. Mientras que la existencia de ficheros de interfaces particulares puede diferir de sistema a sistema dependiendo del uso, los tres tipos de ficheros diferentes que existen en este directorio, ficheros de configuración de interfaz, scripts de control de interfaz y ficheros de función de red, funcionan conjuntamente para habilitar Red Hat Linux para el uso de diversos dispositivos de red disponibles. Este capítulo explorará la relación entre estos ficheros y las diferentes opciones para su uso.
Ficheros de configuración de red Antes de revisar los ficheros de configuración de interfaz estudiemos los ficheros de configuración principales que usa Red Hat Linux para configurar la red. La comprensión del papel que desemepeñan en la configuración de la red es fundamental para configurar el sistema. Los principales ficheros de configuración de la red son los siguientes:
19
El principal propósito de este fichero es resolver los nombres de hosts que no se pueden resolver en otra manera. Se puede usar solamente para resolver nombres de hosts en pequeñas redes sin servidor DNS. Sin tener en cuenta el tipo de red que el ordenador use, este fichero contiene un línea que especifica la dirección IP del dispositivo loopback (127.0.0.1) como por ejemplo localhost.localdomain.
●
/etc/hosts
●
/etc/resolv.conf
●
/etc/sysconfig/network
●
/etc/sysconfig/network-scripts/ifcfg-
Este fichero especifica las direcciones IP de los servidores DNS y el dominio de búsqueda. A menos que se haya configurado para algo diferente, los scripts de inicialización de la red llenan este fichero. Especifica la información del routing y del host para todas las interfaces de red. Para cada interfaz de Ing. Ivan Ferreira
Configuración de dispositivos de red
red del sistema Red Hat Linux existe un script de configuración de interfaz para una interfaz de red determinada.
Ficheros de configuración de interfaz Los ficheros de configuración de interfaz controlan la operación de un dispositivo de interfaz de red particular. Cuando su sistema Red Hat Linux arranca, utiliza estos ficheros para saber qué interfaces utilizar automáticamente y cómo configurarlas para que operen correctamente. Estos ficheros habitualmente se conocen como ifcfg-, donde hace referencia al nombre del dispositivo que controla el fichero de configuración.
Interfaces Ethernet Uno de los ficheros de interfaz más comunes es ifcfg-eth0, que controla el primer NIC de un sistema. En un sistema con muchos NICs, tendrá ficheros ifcfg-ethX múltiples, cada uno con un número al final del nombre del fichero. Como cada dispositivo tiene su propio fichero de configuración, llevará un gran control sobre el modo en que funciona cada interfaz. Un ejemplo ifcfg-eth0 para un sistema que usa una dirección IP fija sería de la siguiente manera: DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
Los valores que se requieren en un fichero de configuración de interfaz pueden cambiar basándose en otros valores. Por ejemplo, el fichero ifcfg-eth0 para una interfaz que use DHCP aparecerá diferente, debido al hecho de que la información IP viene proporcionada por el servidor DHCP: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
La mayoría del tiempo, deseará utilizar una utilidad GUI, como por ejemplo redhatconfig-network, system-config-network o netconfig para hacer cambios en los diversos ficheros de configuración de interfaz. También puede modificar el fichero de configuración de un determinado dispositivo de red a mano. A continuación, le mostramos los parámetros que necesita para modificar el fichero de configuración.
Red Hat Certified Engineer
20
Configuración de dispositivos de red
Dentro de cada uno de los ficheros de configuración de la interfaz, son comunes los siguientes valores: ●
BOOTPROTO=,
donde es uno de los siguientes:
No se debería utilizar ningún protocolo de tiempo de arranque.
○
none
○
bootp
○
dhcp
Se debería utilizar el protocolo BOOTP.
Se debería utilizar el protocolo DHCP.
●
BROADCAST=,
●
DEVICE=,
●
DNS{1,2}=,
●
IPADDR=,
●
NETMASK=,
●
NETWORK=,
donde es la dirección de broadcast.
donde es el nombre del dispositivo físico (a excepción de los dispositivos PPP asignados de forma dinámica donde es el nombre lógico). donde es la dirección del servidor de nombres que se tiene que colocar en /etc/resolv.conf si la directiva PEERDNS está activada. donde es la dirección IP.
donde es el valor de la máscara de red. donde
es la dirección de red. Esta opción ya no
se usa. ●
●
ONBOOT=, ○
yes
○
no
donde es uno de los siguientes:
dispositivo debería activarse en el momento de arranque.
Este dispositivo no debería activarse en el momento de arranque.
PEERDNS=,
donde es uno de las siguientes:
Modificar /etc/resolv.conf si la directiva DNS está activada. Si está usando DCHP, la opción sí es la predeterminada.
○
yes
○
no
No modificar /etc/resolv.conf
Interfaces de acceso telefónico Si se conecta a una red, como Internet, a través de la conexión de acceso telefónico PPP, necesitará un fichero de configuración para esa interfaz.
21
Ing. Ivan Ferreira
Configuración de dispositivos de red
Este fichero se crea automáticamente cuando usa las aplicaciones wvdial, ls herramienta de administración de redes o Kppp para crear una cuenta telefónica. Además, todos los cambios que se hagan en la cuentas telefónica se reflejan en estos ficheros de configuración de estos dispositivos. El Manual del principiante de Red Hat Linux contiene las instrucciones para usar estas herramientas de conexión telefónica. También puede crear y modificar este fichero a mano. La muestra de ficheros ifcfg-ppp0 sería de la siguiente manera: DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600
Otras interfaces Otro fichero de configuración de interfaz comunes que usan estas opciones es el ifcfg-lo, que controla el dispositivo loopback local del protocolo IP, ifcfg-irlan0, que establece los parámetros para el primer dispositivo infrarojo, ifcfg-plip0, que controla el primer dispositivo PLIP, y ifcfg-tr0, que se usa con el primer dispositivo Token Ring. A menudo se usa una interfaz loopback en las pruebas así como una variedad de aplicaciones que requieren una dirección IP que apunte al mismo sistema. Todos los datos que se mandan al dispositivo loopback vuelven inmediatamente a la red del host.
Ficheros alias y clon Dos tipos menos usados de ficheros de configuración de interfaz que se encuentran en /etc/sysconfig/network-scripts son los ficheros alias y clon, que incluyen un componente adicional en el nombre del fichero más allá del nombre de la interfaz. Los ficheros de configuración de la interfaz toman nombres en el formato de ifcfg:: y permiten que un alias señale una interfaz. Por ejemplo, un fichero ifcfg-eth0:0: podría estar configurado para especificar DEVICE=eth0:0 y una dirección IP estática de 10.0.0.2, que sirva como un alias de una interfaz Ethernet que ya haya sido configurada para recibir la información IP a través de DHCP en ifcfg-eth0. Llegado a ese punto, el dispositivo eth0 está ligado a una dirección IP 10.0.0.2. Red Hat Certified Engineer
22
Configuración de dispositivos de red
Un fichero de configuración de clon tiene un nombre parecido a ifcfg-. Un fichero alias es otro modo de referirse a un fichero de configuración de interfaz ya existente, mientras que un fichero clon se usa para especificar opciones adicionales al especificar una interfaz. Por ejemplo, si tiene una interfaz Ethernet DHCP estándar llamada eth0, será de la siguiente manera: DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp
Como USERCTL no está configurado para la opción sí, los usuarios no pueden activar y desactivar esta interfaz. Para que los usuarios gocen de esta habilidad, cree un clon llamado user de ifcfg-eth0 que permita que un usuario active o no la interfaz eth0. El nombre que resulta del clon sería ifcfg-eth0-user y tan sólo necesitaría una línea: USERCTL=yes
Cuando un usuario activa la interfaz eth0 mediante el comando ifup eth0-user, las opciones de configuración desde ifcfg-eth0 y ifcfg-eth0-user se usan conjuntamente. Aunque este ejemplo es muy sencillo, este método puede ser utilizado con una variedad de opciones e interfaces. Si desea configurar un alias a una interfaz sólo momentáneamente puede usar el conmando ifconfig. Por ejemplo para crear un alias en la interfaz eth0 ejecute: # ifconfig eth0:0 192.168.1.1 # ifconfig eth0:0 192.168.2.1
De esta forma podrá acceder a las redes 192.168.1.0 y 192.168.2.0. Para desactivar un alias ejecute el comando: # ifconfig eth0:0 down
Scripts de control de interfaz Los scripts de control de interfaz controlan la activación y desactivación de las conexiones de interfaz. Existen dos scripts de control de la interfaz primarios, /sbin/ifdown y /sbin/ifup que utilizan otros scripts de control variados localizados en el directorio /etc/sysconfig/network-scripts para activar y desactivar las interfaces de red. Los dos scripts de control de interfaz son ifdown y ifup y son enlaces simbólicos para los scripts en el directorio /sbin. Cuando se solicita cualquiera de estos scripts, aceptan el uso de un valor de la interfaz, como por ejemplo: # ifup eth0
23
Ing. Ivan Ferreira
Configuración de dispositivos de red
Determining IP information for eth0... done.
Tras haber verificado que se ha especificado una interfaz y que al usuario que ha ejecutado la petición se le permite activar o desactivar la interfaz, se solicita el script correcto para el tipo de dispositivo de interfaz. Los siguientes scripts de control de interfaz son los más habituales de este tipo: Configura los alias IP desde los ficheros de configuración de la interfaz cuando se asocia más de una dirección IP con una interfaz.
●
ifup-aliases
●
ifdown-ipv6
●
ifup-ipx
●
ifup-plip
●
ifup-plusb
●
ifdown-post
●
ifdown-ppp
●
ifup-routes
●
ifdown-sl y ifup-sl
y ifup-ipv6 Contiene la llamada de funciones basadas en IPv6 que utilizan las variables de entorno en varios ficheros de configuración de la interfaz y /etc/sysconfig/network. Se usa para configurar una interfaz IPX. Se usa para configurar una interfaz PLIP. Se usa para configurar una interfaz USB para conexiones de red.
e ifup-post Contiene comandos que se ejecutan después de que una interfaz particular haya sido activada o desactivada. e ifup-ppp Se usa para activar o desactivar una interfaz PPP mediante el uso de un dispositivo en particular. Añade rutas estáticas para un dispositivo en particular como si se activase su interfaz. Se usa para activar o desactivar una interfaz SLIP.
Tenga en cuenta que si elimina o modifica estos scripts puede provocar varias conexiones de interfaz que pueden funcionar de forma extraña o incluso fallar, debido a que los scripts tienden a apoyarse uno en el otro. Sin embargo, los usuarios avanzados pueden modificar los scripts relacionados con una interfaz específica para hacer que se produzcan pasos adicionales cuando esa interfaz se activa o desactiva. También puede utilizar el script init /etc/rc.d/init.d/network para activar o desactivar todas las interfaces de red configuradas para iniciar en el momento de arranque con el comando: # /sbin/service network start | stop | restart
Asignación de parámetros de red Red Hat Certified Engineer
24
Configuración de dispositivos de red
Nombre del host Debe editarse con un procesador de textos el archivo /etc/hosts, y debe verificarse que el nombre de la máquina esté asociada a su dirección IP correspondiente y no a la interfaz loopback. Ejemplo: 127.0.0.1 localhost.localdomain localhost 192.168.1.50 host.dominio.com.py host
Se debe establecer un nombre para el sistema. Este deberá ser un nombre de dominio completamente resuelto por un servidor de nombre de domino (DNS) o bien, en el caso de sistemas sin conexión a red o sistemas caseros, sea resuelto localmente en /etc/hosts. De tal modo, el nombre de host del sistema se definirá en el fichero /etc/sysconfig/network del siguiente modo: NETWORKING=yes HOSTNAME=su_maquina.su_dominio.com
El nombre de host es retornado por el comando coincidir la entrada del archivo /etc/hosts.
hostname.
El valor retornado debe
Dirección IP, máscara de sub-red y puerta de enlace Debe editarse con un procesador de textos /etc/sysconfig/network-scripts/ifcfgeth y debe verificarse que sus parámetros de red sean los correctos. Por ejemplo, para la primera interfaz de red, edite el archivo ifcfg-eth0, para la segunda ifcfg-eth1: DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.50 NETMASK=255.255.255.0 GATEWAY=192.168.1.254
Los parámetros anteriores son proporcionados por el administrador de la red local en donde se localice la máquina que está siendo configurada, o bien definidos de acuerdo a una planeación pre-definida. El administrador de la red deberá proporcionar una dirección IP disponible IPADDR y una máscara de la sub-red NETMASK.
Servidores de nombres de dominio Debe editarse con un procesador de textos /etc/resolv.conf y deben establecerse en éste los servidores de resolución de nombres de dominio (DNS) y el dominio al cual el host pertenece. Ejemplo: domain redhat.com.py nameserver 192.168.1.254
25
Ing. Ivan Ferreira
Configuración de dispositivos de red nameserver 192.168.1.1
Agregar rutas adicionales Si se requiere establecer rutas adicionales para obtener conectividad con otras redes, se pueden generar ficheros para cada interfaz que sea necesario, en donde se establecen los valores para puerta de enlace, red a la que se quiere acceder y la máscara de sub-red correspondiente. Los fichero se deben generar dentro de /etc/sysconfig/network-scripts/ como route-[interfaz] y deben llevar el siguiente formato: via
Por citar un ejemplo, imaginemos que nos encontramos dentro de la red 192.168.1.0 y se requiere establecer conectividad con las redes 192.168.2.0 y 192.168.3.0, con máscaras 255.255.255.0, a través de las puerta de enlace o ruteadores con dirección IP 192.168.1.1. La configuración de /etc/sysconfig/network-scripts/route-eth0 sería la siguiente: 192.168.2.0/24 via 192.168.1.1 192.168.3.0/24 via 192.168.1.1
Función de Re-envío de paquetes para IP versión 4 Si se tiene planeado implementar un NAT, se debe habilitar el re-envío de paquetes para IP versión 4. Esto se realiza en /etc/sysctl.conf cambiando net.ipv4.ip_forward = 0 por net.ipv4.ip_forward = 1: net.ipv4.ip_forward = 1
Función Zeroconf La función Zeroconf permite obtener una dirección IP automática privada para la ineterfaz de red cuando no puede contactar un servidor DHCP. Dicha configuración hará que cuando se ejecute route -n se muestre una ruta adicional hacia la red 169.254.0.0: 192.168.1.0
0.0.0.0
255.255.255.0
U
0
0
0 eth0
169.254.0.0
0.0.0.0
255.255.0.0
U
0
0
0 eth0
127.0.0.0
0.0.0.0
255.0.0.0
U
0
0
0 lo
0.0.0.0
192.168.1.1
0.0.0.0
UG
0
0
0 eth0
Si
se
desea
deshabilitar dicha función, solo bastará /etc/sysconfig/network el parámetro NOZEROCONF con el valor yes: Red Hat Certified Engineer
añadir
en
26
Configuración de dispositivos de red
NETWORKING=yes HOSTNAME=host.dominio NOZEROCONF=yes
Verificación de la configuración Después de hacer configurado todos los parámetros de red deseados, solo deberá de ser reiniciado el servicio de red, ejecutando lo siguiente: # /sbin/service network restart
Basta solamente comprobar si hay realmente conectividad. Puede ejecutarse el comando ping hacia cualquier dirección de la red local para tal fin. # ping 192.168.1.254
Las interfaces y la información de las mismas se puede examinar utilizando: # /sbin/ifconfig -a
Las rutas se pueden comprobar ejecutado: # /sbin/netstat -n
Para comprobar si hay resolución de nombres, se puede realizar una consulta hacia los DNS definidos para el sistema utilizando: # host host.dominio # dig host.dominio
La herramienta ethtool La herramienta ethtool es utilizada para consultar y cambiar la configuración de un dispositivo ethernet. El modulo de la tarjeta ethernet debe compatible con utilizar el comando.
mii-tool
o
ethtool
para poder
Para consultar el estado de un adaptador de red, utilice el siguiente comando: # ethtool
Por ejemplo: # ethtool eth0 Settings for eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full
27
Ing. Ivan Ferreira
Configuración de dispositivos de red 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Current message level: 0x000000ff (255) Link detected: yes
Para cambiar los valores de configuración de un adaptador ethernet, utilice el comando ethtool con las siguientes opciones: Opción
Descripción
-s
Cambia la configuración de un dispositivo.
autoneg on|off
Habilita o deshabilita la autonegociación de velocidad del adaptador.
speed 10|100|1000
Configura la velocidad en Mb/s.
duplex half|full
Selecciona el modo de duplex.
Ejemplo: # ethtool -s eth0 speed 100 duplex full autoneg off
Para que los cambios sean permanentes, edite el archivo scripts/ifcfg-ethX y agregue la siguiente línea:
/etc/sysconfig/network-
ETHTOOL_OPTS="speed 100 duplex full autoneg off"
Red Hat Certified Engineer
28
3
Network File System (NFS)
Network File System (NFS)
Network File System (NFS) NFS (Network File System) permite a las máquinas montar particiones en un sistema remoto en concreto y usarlas como si estuvieran en el sistema de archivos local. Esto permite centralizar archivos en una localización, mientras se permite su acceso continuo a los usuarios autorizados. Hay distintas versiones de NFS actualmente en uso. La versión 2 de NFS (NFSv2), que tiene varios años, es ampliamente soportada por muchos sistemas operativos. La versión 3 (NFSv3) tiene más características, incluyendo tamaño variable del manejador de archivos y una mejor información de errores. NFSv4 incluye varias mejoras sobre NFSv3 como mayor seguridad, soporte para ACL, codificación UTF8, bloqueo y montado integrado sin necesidad de protocolos auxiliares, entre otras características.
NFS y portmap Linux usa una combinación de soporte a nivel de kernel y demonios en continua ejecución para compartir archivos a través de NFS, sin embargo, el soporte NFS debe estar activo en el kernel de Linux para que funcione. NFS usa Remote Procedure Calls (RPC) para enrutar peticiones entre clientes y servidores, implicando que el servicio portmap debe estar disponible y activo en los niveles de ejecución adecuados para que la comunicación NFS funcione. NFS se apoya en las llamadas de procedimientos remotos (RPC) para funcionar. Se requiere portmap para trazar las peticiones RPC a los servicios correctos. Los procesos RPC notifican a portmap cuando comienzan, revelando el número de puerto que ellos están monitorizando y el número de programas RPC que esperan servir. El sistema cliente entonces contacta con el portmap del servidor con un número de programa RPC particular. Entonces portmap redirecciona al cliente al número del puerto apropiado para que se comunique con el servicio adecuado. Como los servicios basados en RPC confían en portmap para hacer todas las conexiones con las peticiones de clientes entrantes, portmap debe estar disponible antes que cualquiera de esos servicios comience. Si, por alguna razón, el servicio portmap inesperadamente termina, reinicie portmap y cualquier servicio que estuviera ejecutándose entonces.
Trabajando con portmap Los procesos siguientes se aseguran que una conexión particular NFS esté permitida y pueda proceder sin error: Red Hat Certified Engineer
30
Network File System (NFS)
El proceso que recibe la petición de montaje desde un cliente NFS y chequea para mirar si coincide con un sistema de archivos actualmente exportado.
●
rpc.mountd:
●
rpc.nfsd:
●
rpc.lockd:
●
rpc.statd:
●
rpc.rquotad:
El proceso que implementa los componentes del espacio del usuario del servicio NFS. Trabaja con el kernel Linux para satisfacer las demandas dinámicas de clientes NFS, tales como proporcionar procesos adicionales del servidor para que los clientes NFS lo utilicen. Un demonio innecesario en los kernels modernos. El bloqueo de archivos NFS ahora lo hace el kernel. Está incluido en el paquete nfs-utils para usuarios de versiones antiguas del kernel que no incluyen esta capacidad por defecto. implementa el protocolo RPC Network Status Monitor (NSM). Esto proporciona notificación de reinicio cuando un servidor NFS es reiniciado luego de haber sido apagado abruptamente. Un servidor RPC que proporciona información de cuotas de usuarios a usuarios remotos.
No todos estos programas son requeridos para el servicio NFS. Los únicos servicios que deben estar activos son rpc.mountd, rpc.nfsd, y portmap. Los otros demonios proporcionan funcionalidades adicionales y sólo deben usarse si el entorno de su servidor los requiere. La versión 2 de NFS usa el User Datagram Protocol (UDP) para proporcionar una conexión de red sin estado entre el cliente y el servidor. La versión 3 de NFS puede usar UDP o TCP corriendo sobre una IP. La conexión UDP sin estado minimiza el tráfico de red, al mandar el servidor NFS una cookie al cliente, después de que el cliente sea autorizado a acceder al volumen compartido. Esta cookie es un valor aleatorio guardado en la parte del servidor y es pasado junto con las peticiones RPC desde el cliente. El servidor NFS puede ser reiniciado sin afectar a los clientes y las cookies permanecen intactas. Con NFS, la autenticación sólo se produce cuando el cliente intenta montar un sistema de archivos remoto. Para limitar el acceso, el servidor NFS utiliza en primer lugar envolturas TCP (TCP wrappers). Estas envolturas leen los archivos /etc/hosts.allow y /etc/hosts.deny para determinar si a un cliente particular le debe ser explícitamente permitido o denegado su acceso al NFS. Después de que al cliente se le permite acceso a una envoltura TCP, el servidor NFS recurre a su archivo de configuración, /etc/exports, para determinar si el cliente tiene suficientes privilegios para montar alguno de los sistemas de archivos exportados. Después de permitir el acceso, cualquier operación de archivos y directorios es mandada al servidor usando llamadas de procedimiento remotas.
31
Ing. Ivan Ferreira
Network File System (NFS)
Archivos de configuración del servidor NFS Es sencillo configurar un sistema para compartir archivos y directorios usando NFS. Cada Sistema de archivos que se exporta a usuarios remotos vía NFS, así como los derechos de acceso relativos a ellos, es localizado en el archivo /etc/exports. Este archivo es leído por el comando exportfs para dar a rpc.mountd y a rpc.nfsd la información necesaria para permitir el montaje remoto de un sistema de archivos por una máquina autorizada. El comando exportfs permite a root exportar o no directorios concretos sin reiniciar los servicios NFS. Cuando se le pasan las opciones apropiadas a exportfs, el sistema de archivos a exportar es incluido en /var/lib/nfs/xtab. Como rpc.mountd se refiere al archivo xtab para decidir privilegios de acceso a un sistema de archivos, los cambios en la lista de sistemas de archivos exportados toman efecto inmediatamente. Hay varias opciones disponibles cuando usamos exportfs:
Opción
Descripción
-r
Provoca que todos los directorios listados en /etc/exports sean exportados construyendo una nueva lista de exportación en /etc/lib/nfs/xtab. Esta opción refresca la lista de exportación con cualquier cambio que hubiéramos realizado en /etc/exports.
-a
Provoca que todos los directorios sean exportados o no, dependiendo de qué otras opciones hemos pasado a exportfs.
-o opciones
Permite al usuario especificar directorios a exportar que no estén listados en /etc/exports. Estos sistemas de archivos adicionales compartidos deben ser escritos de la misma forma que son especificados en /etc/exports. Esta opción es usada para probar un sistema de archivos antes de añadirlo permanentemente a la lista de sistemas a exportar.
-i
Ignora /etc/exports; sólo las opciones dadas desde la línea de comandos son usadas para definir los sistemas de archivos exportados.
-u
Termina de exportar directorios que puedan ser montados por usuarios remotos. El comando exportfs -ua suspende los recursos compartidos NFS mientras que mantiene los demonios activos. Para volver a compartir recursos NFS, teclee exportfs -r.
-v
Operación descriptiva, donde los sistemas de archivos exportados o dejados de exportar son mostrados en gran detalle al ejecutarse el comando exportfs.
Red Hat Certified Engineer
32
Network File System (NFS)
Si no se pasan opciones al comando de archivos actualmente exportados.
exportfs,
mostrará una lista de los sistemas
Los cambios efectuados a /etc/exports pueden ser leídos al recargar el servicio NFS con el comando service nfs reload. Esto deja a los demonios NFS ejecutándose mientras reexporta el archivo /etc/exports.
/etc/exports El archivo /etc/exports controla cuáles sistemas de archivos son exportados a las máquinas remotas y especifica opciones particulares que controlen todo. Las líneas en blanco son ignoradas, se pueden comentar líneas con el símbolo # y las líneas largas pueden ser divididas con una barra invertida (\). Cada sistema de archivos exportado debe tener su propia línea. La lista de máquinas autorizadas colocada después de un sistema de archivos exportado, debe estar separada por un espacio. Las opciones para cada uno de las máquinas deben ser colocadas entre paréntesis directamente detrás del identificador de la máquina, sin ningún espacio de separación entre la máquina y el primer paréntesis. De esta sencilla manera, /etc/exports sólo necesita saber el directorio a exportar y las máquinas que pueden usarlo: /algun/directorio host1.redhat.com.py /otro/directorio/exportado 192.168.0.3
Después de reexportar /etc/exports con el comando /sbin/service nfs reload, la máquina host1.redhat.com.py será capaz de montar /algun/directorio y 192.168.0.3 podrá montar /otro/directorio/exportado. Como no hay opciones especificadas en este ejemplo, varias preferencias por defecto toman efecto:
Opción
33
Descripción
ro
Sólo lectura (read-only). Las máquinas que monten este sistema de archivos no podrán cambiarlo. Para permitirlas que puedan hacer cambios en el sistema de archivos, debe especificar la opción rw (lectura-escritura, read-write).
async
Permite al servidor escribir los datos en el disco cuando lo crea conveniente. Mientras que esto no tiene importancia en un sistema de sólo lectura, si una máquina hace cambios en un sistema de archivos de lectura-escritura y el servidor se cae o se apaga, se pueden perder datos. Especificando la opción sync, todas las escrituras en el disco deben hacerse antes de devolver el control al cliente. Esto puede que disminuya el rendimiento.
wdelay
Provoca que el servidor NFS retrase el escribir a disco si Ing. Ivan Ferreira
Network File System (NFS)
Opción
Descripción sospecha que otra petición de escritura es inminente. Esto puede mejorar el rendimiento reduciendo las veces que se debe acceder al disco por comandos de escritura separados. Use no_wdelay para desactivar esta opción, la cual sólo funciona si está usando la opción sync.
root_squash
Previene a los usuarios root conectados remotamente de tener privilegios como root asignándole el userID de 'nobody'. Esto reconvierte el poder del usuario root remoto al de usuario local más bajo, previniendo que los usuarios root remotos puedan convertirse en usuarios root en el sistema local. Alternativamente, la opción no_root_squash lo desactiva. Para reconvertir a todos los usuarios, incluyendo a root, use la opción all_squash. Para especificar los ID de usuario y grupo para usar con usuarios remotos desde una máquina particular, use las opciones anonuid y anongid, respectivamente. De esta manera, puede crear una cuenta de usuario especial para usuarios NFS remotos para compartir y especificar anonuid=,anongid=, donde es el número ID de usuario y es el número ID de grupo.
Para saltarse estas opciones predeterminadas, debe especificar una opción que tome su lugar. Por ejemplo, si no especifica la opción rw, entonces se exportará en sólo lectura. Cada opción predeterminada para cada sistema de archivos exportado, debe ser explícitamente ignorada. Adicionalmente, hay otras opciones que están disponibles que no tienen especificado un valor predeterminado. Estas incluyen desactivar el navegar por subdirectorios, permitir el acceso a puertos inseguros, y permitir bloquear archivos inseguros (necesario para algunas implementaciones antiguas de clientes NFS). Vea la página man de exports para estas opciones menos usadas. Cuando especifique los nombres de máquinas, use los métodos siguientes: ●
Una sola máquina - Cuando una máquina en particular es especificada con nombre completo de dominio, nombre de máquina o dirección IP.
●
Comodines - Cuando usamos un carácter * o ? para referirnos a un grupo de nombres completos de dominio o direcciones IP o que coincidan con una cadena particular de letras. Sin embargo, tenga cuidado cuando especifique comodines con nombres de dominio completos, pues tienden a ser más exactos de lo que usted cree. Por ejemplo, el uso de *.redhat.com.py como comodín, permitirá a ventas.redhat.com.py acceder al sistema de archivos exportado, pero no a bob.ventas.redhat.com.py. Para permitir ambas posibilidades, debería usar *.redhat.com.py *.*.redhat.com.py.
Red Hat Certified Engineer
34
Network File System (NFS)
●
Redes IP - Permite el acceso a máquinas basadas en sus direcciones IP. Es posible especificar la máscara de red en formato decimal o como tamaño de la máscara (for ejemplo 255.255.255.0 o /24).
●
Grupos de redes - Permite que un nombre de grupo de red NIS, escrita como @, sea usada. Esto pone al servidor NIS controlando el acceso de este sistema de archivos, donde los usuarios pueden ser añadidos o borrados de un grupo NIS sin que afecte a /etc/exports.
La manera en que el archivo /etc/exports está organizado es muy importante, particularmente lo que concierne a los espacios en blanco. Recuerde separar siempre los sistemas de archivos exportados de una máquina a la otra, con un espacio. Sin embargo, no debería haber otros espacios en el archivo a menos que se usen en líneas comentadas. Por ejemplo, las siguientes dos líneas significan cosas distintas: /home bob.redhat.com.py(rw,sync) /home bob.redhat.com.py (rw,sync)
La primera línea permite sólo a los usuarios de bob.redhat.com.py acceder en modo de lectura-escritura al directorio /home. La segunda línea permite a los usuarios de bob.redhat.com.py montar el directorio de solo lectura (el predeterminado), pero el resto del mundo puede instalarlo como lectura-escritura.
Archivos de configuración de clientes NFS Cualquier recurso NFS puesto a disposición por un servidor puede ser montado usando varios métodos. El recurso compartido puede ser montado manualmente, usando el comando mount. Sin embargo, esto requiere que el usuario root teclee el comando mount cada vez que el sistema reinicie.
/etc/fstab Colocando una línea adecuadamente formada en el archivo /etc/fstab tiene el mismo efecto que el montaje manual del sistema de archivos exportado. El archivo /etc/fstab es leído por el script /etc/rc.d/init.d/netfs cuando arranca el sistema y cualquier recurso NFS listado será montado. Un ejemplo de línea /etc/fstab para montar un NFS exportado será parecida a: : nfs 0 0
La opción tiene que ver con el nombre de la máquina, dirección IP o nombre de dominio totalmente cualificado del servidor que exporta el sistema de 35
Ing. Ivan Ferreira
Network File System (NFS)
archivos. La opción es la ruta al directorio exportado. La opción especifica dónde montar en el sistema de archivos local el directorio exportado. Este punto de montaje debe existir antes de que /etc/fstab sea leído o el montaje fallará. La opción
nfs
especifica el tipo de sistema de archivos que esta siendo montado.
El área especifica como el sistema de archivos es montado. Por ejemplo, si las opciones indican rw,suid, el sistema de archivos exportado será montado en modo de lectura-escritura y los ID de usuario y grupo puestos por el servidor serán usados. Aquí no se usan paréntesis.
Opciones de montaje NFS comunes Aparte de montar un sistema de archivos via NFS en una máquina remota, existe un número de diferentes opciones que pueden ser especificadas en tiempo de montaje que pueden ser más fáciles de usar. Estas opciones pueden usarse con el comando manual mount, configuraciones /etc/fstab, autofs y otros métodos de montaje. Las siguientes opciones son las más populares para montajes NFS: ●
Especifican si el programa que usa un archivo vía conexión NFS debe parar y esperar a que el servidor vuelva a estar en línea si la máquina que exporta ese sistema de archivos no está disponible (hard), o bien debe informar de un error (soft). hard o soft -
Si se especifica la opción hard, el usuario no podrá parar el proceso que está esperando la comunicación NFS a menos que especifique la opción intr. Si usa soft, puede usar la opción adicional timeo=, donde especifica el número de segundos que deben pasar antes de informar del error. Permite a las peticiones NFS ser interrumpidas si el servidor se cae o no puede ser accedido.
●
intr -
●
nolock
●
noexec
- Es requerido a veces cuando conectamos a servidores NFS antiguos. Para requerir el bloqueo, use la opción lock.
- No permite la ejecución de binarios en el sistema de archivos montado. Esto es útil si el sistema está montando un sistema de archivos no Linux a través de NFS que contiene binarios incompatibles.
Red Hat Certified Engineer
36
Network File System (NFS)
- No permite que los bits SUID o SGID tomen efecto.
●
nosuid
●
rsize=8192 y wsize=8192
●
nfsvers=2 o nfsvers=3
- Pueden acelerar la comunicación NFS tanto para leer (rsize) como para escribir (wsize), configurando un tamaño de bloque de datos mayor, en bytes, que serán transferidos de una sola vez. Tenga cuidado al cambiar estos valores; algunos kernels antiguos de Linux y tarjetas de red pueden no trabajar bien con grandes tamaños de bloques. - Especifica que versión del protocolo NFS usar. Para montar un sistema de archivos NFSv4, utilice como sistema de archivos nfsv4.
Hay muchas más opciones en la página del manual de para montar sistemas de archivos que no sean NFS.
mount,
incluyendo opciones
Resolución de problemas de NFS con portmap Como portmap proporciona la coordinación entre servicios RPC y los números de puertos usados para comunicarlos, es útil poder visualizar el estado de los servicios RPC actuales usando portmap cuando estamos resolviendo algún problema. El comando rpcinfo muestra cada servicio basado en RPC con su número de puerto, número de programa RPC, versión y tipo de protocolo (TCP o UDP). Para asegurarse que los servicios NFS basados en RPC están activos para portmap, use el comando rpcinfo -p: programa vers proto puerto 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 32768 status 100024 1 tcp 32769 status 100011 1 udp 863 rquotad 100011 2 udp 863 rquotad 100011 1 tcp 866 rquotad 100011 2 tcp 866 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 32770 nlockmgr 100021 3 udp 32770 nlockmgr 100021 4 udp 32770 nlockmgr 100021 1 tcp 32772 nlockmgr 100021 3 tcp 32772 nlockmgr 100021 4 tcp 32772 nlockmgr 100005 1 udp 32771 mountd 100005 1 tcp 894 mountd 100005 2 udp 32771 mountd 100005 2 tcp 894 mountd 100005 3 udp 32771 mountd
37
Ing. Ivan Ferreira
Network File System (NFS) 100005
3
tcp
894
mountd
La opción -p prueba el portmap de la máquina especificada, o en la máquina local por defecto si no se especifica ninguna máquina. Otras opciones están disponibles en la página manual de rpcinfo. De la salida anterior, varios servicios NFS pueden verse ejecutándose. Si uno de los servicios NFS no comienza correctamente, portmap puede ser incapaz de corresponder las peticiones RPC con sus respectivos puertos. En muchos casos, reiniciando NFS como root con el comando /sbin/service nfs restart, provocará que estos servicios funcionen correctamente con portmap y empiecen a funcionar.
Red Hat Certified Engineer
38
4
Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocol (DHCP) Dynamic Host Configuration Protocol (DHCP), es un protocolo de red para asignar automáticamente información TCP/IP a equipos cliente. Cada cliente DHCP se conecta un servidor DHCP centralizado que devuelve la configuración de red del cliente, incluida la dirección IP, el gateway y los servidores DNS.
Motivos para usar el protocolo DHCP DHCP es útil para proporcionar de un modo rápido la configuración de red del cliente. Al configurar el sistema cliente, el administrador puede seleccionar el protocolo DHCP y no especificar una dirección IP, una máscara de red, un gateway o servidor DNS. El cliente recupera esta información desde el servidor DHCP. DHCP también es útil si un administrador desea cambiar las direcciones IP de muchos sistemas. En lugar de volver a configurar todos los sistemas, puede modificar un archivo de configuración DHCP en el servidor para establecer el nuevo conjunto de direcciones IP. Si los servidores DNS de una organización cambian, los cambios también se aplicarán en el servidor DHCP, no en todos los clientes DHCP. Una vez que se reinicie la red en los clientes (o rearranquen los clientes), se aplicarán los cambios. Además, si un portátil o cualquier tipo de equipo móvil se configura para DHCP, podrá desplazarse entre distintas oficinas sin tener que volver a configurarlo, siempre y cuando cada oficina tenga un servidor DHCP que permita su conexión a la red.
Configuración de un servidor DHCP Puede configurar un servidor DHCP mediante el archivo de configuración /etc/dhcpd.conf. DHCP también usa el archivo /var/lib/dhcpd/dhcpd.leases para almacenar la base de datos de arrendamiento de clientes.
Archivo de configuración El primer paso al configurar un servidor DHCP es crear el archivo de configuración que almacena la información de red de los clientes. Se pueden declarar opciones globales para todos los clientes, o bien opciones para cada sistema cliente. El archivo de configuración puede contener tabulaciones o líneas en blanco Red Hat Certified Engineer
40
Dynamic Host Configuration Protocol (DHCP)
adicionales para facilitar el formato. Las palabras clave no distinguen entre mayúsculas y minúsculas, y las líneas que empiezan con una almohadilla o símbolo numeral (#) se consideran comentarios. DHCP puede interactuar con DNS para actualizar el archivo de zona DNS una vez entregada una dirección IP a un host. Este proceso se conoce como DNS dinámico o DDNS (Dynamic DNS). Si no utilizará DDNS, añada la siguiente línea al inicio del archivo de configuración: ddns-update-style none;
El archivo de configuración posee dos tipos de información: • Parámetros - Establece cómo se realiza una tarea, si debe llevarse a cabo una tarea o las opciones de configuración de red que se enviarán al cliente. • Declaraciones - Describen la topología de la red, describen los clientes, proporcionan direcciones para los clientes o aplican un grupo de parámetros a un grupo de declaraciones. Algunos parámetros deben empezar con la palabra clave option. Algunas opciones configuran DHCP y los parámetros definen valores no opcionales o que controlan el comportamiento del servidor DHCP. Los parámetros (incluidas las opciones) declarados antes de una sección encerrada entre llaves { } se consideran parámetros globales. Los parámetros globales se aplican a todas las secciones situadas debajo de ellos. Si cambia el archivo de configuración, los cambios no se aplicarán hasta reiniciar el demonio DHCP con el comando service dhcpd restart. Un ejemplo de configuración del archivo dhcpd.conf puede encontrarse en el directorio /usr/share/doc/dhcp-/dhcpd.conf.sample . Puede copiar este archivo como /etc/dhcpd.conf y editarlo para adecuarlo a sus necesidades. En este ejemplo, hay opciones globales para cada cliente DHCP en la subred y un rango declarado. A los clientes se les asigna una dirección IP dentro del rango. Ejemplo de declaración de Subred: subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.254; option subnet-mask 255.255.255.0; option domain-name "redhat.com.py"; option domain-name-servers 192.168.1.1; option time-offset -14400; # range 192.168.1.10 192.168.1.100; }
41
Ing. Ivan Ferreira
Dynamic Host Configuration Protocol (DHCP)
Parámetro Range (Rango) Para configurar un servidor DHCP para que responda a solicitudes de direcciones IP en una subred, modifique el ejemplo con los valores pertinentes. Declara un tiempo de lease por defecto, un tiempo de lease máximo y los valores de configuración de red para los clientes. Este ejemplo asigna una dirección IP en el rango 192.168.1.10 y 192.168.1.100 a los sistemas cliente: ddns-update-style none default-lease-time 600; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.254; option domain-name-servers 192.168.1.1, 192.168.1.2; option ntp-servers 192.168.1.1; option domain-name "redhat.com.py"; option netbios-name-servers 192.168.1.5; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.100; range 192.168.1.150 192.168.1.200; option time-offset -14400; }
Dirección IP estática con DHCP Para asignar una dirección IP a un cliente según la dirección MAC de la tarjeta de interfaz de red, use el parámetro hardware ethernet dentro de la declaración host. Como se muestra en el ejemplo, la declaración host apex especifica que la interfaz de red con una dirección MAC 00:A0:78:8E:9E:AA siempre recibe la dirección IP 192.168.1.4. Tenga en cuenta que también puede usar el parámetro opcional asignar un nombre host al cliente.
host-name
para
host apex { option host-name "apex.redhat.com.py"; hardware ethernet 00:A0:78:8E:9E:AA; fixed-address 192.168.1.4; }
Base de datos de arrendamiento En el servidor DHCP, el archivo /var/lib/dhcp/dhcpd.leases almacena la base de datos de arrendamiento del cliente DHCP. Este archivo no debe modificarse manualmente. La información sobre arrendamiento de DHCP de cada dirección IP asignada recientemente se almacena de modo automático en la base de datos de Red Hat Certified Engineer
42
Dynamic Host Configuration Protocol (DHCP)
arrendamiento. La información incluye la longitud del arrendamiento, a quién se ha asignado la dirección IP, las fechas iniciales y finales de la renta, y la dirección MAC de la tarjeta de interfaz de red utilizada para recuperar el arrendamiento.
Arranque y parada del servidor Para arrancar el servicio DHCP, use el comando /sbin/service dhcpd detener el servidor DHCP, use el comando /sbin/service dhcpd stop.
start.
Para
Si tiene más de una interfaz de red conectada al sistema, pero sólo desea que el servidor DHCP arranque en una de las interfaces, puede configurar el servidor DHCP para que sólo arranque en ese dispositivo. En /etc/sysconfig/dhcpd, agregue el nombre de la interfaz a la lista de DHCPDARGS: # Command line options here DHCPDARGS=eth0
Esto es útil si tiene una máquina firewall con dos tarjetas de red. Se puede configurar una tarjeta de red como cliente DHCP para recuperar una dirección IP en Internet y la otra tarjeta de red puede utilizarse como servidor DHCP para la red interna detrás del firewall. Su sistema será más seguro si especifica la tarjeta de red conectada a la red interna ya que los usuarios no pueden conectarse al demonio vía Internet.
Agente de retransmisión DHCP El Agente de transmisión DHCP (dhcrelay) le permite transmitir las peticiones DHCP y BOOTP desde una subred sin un servidor DHCP a uno o más servidores DHCP en otras subredes. Un agente de retransmisión es necesario cuando los ruteadores que unen las subredes no reenvían paquetes bootp. Cuando un cliente DHCP pide información, el agente de transmisión DHCP reenvía la petición a la lista de servidores DHCP especificada cuando se inicia el agente de transmisión DHCP. Cuando un servidor DHCP devuelve una respuesta, la respuesta puede ser broadcast o unicast en la red que ha enviado la petición original. La configuración del agente de retransmisión DHCP se realiza por medio de archivo /etc/sysconfig/dhcrelay:
43
●
La directiva DHCP.
●
La directiva DHCPSERVERS especifica la lista de servidores DHCP a los cuales se reenviarán las solicitudes.
INTERFACES
indica en que interfaces se escucharán solicitudes
Ing. Ivan Ferreira
Dynamic Host Configuration Protocol (DHCP)
Por ejemplo el archivo /etc/sysconfig/dhcrelay tendría el siguiente formato: INTERFACES="" DHCPSERVERS="10.42.42.2"
Luego inicie el servicio utilizando el siguiente comando: # service dhcrelay start
Red Hat Certified Engineer
44
5
Interconexión con Windows - SAMBA
Interconexión con Windows - SAMBA
Interconexión con Windows - SAMBA SAMBA es una conjunto de programas, originalmente creados por Andrew Tridgell y actualmente mantenidos por The SAMBA Team, bajo la Licencia Publica General GNU, y que implementan en sistemas basados sobre UNIX el protocolo Server Message Block (o protocolo SMB). Este es algunas veces referido también como Common Internet File System (CIFS), LanManager o protocolo NetBIOS. Sirve como reemplazo total para Windows NT, Warp, NFS o servidores Netware.
Configuración de SAMBA La configuración de SAMBA se realiza a través del archivo /etc/samba/smb.conf. En éste archivo encontrará no solo las opciones que requieren editarse, sino también un valioso instructivo que podría consultar más adelante para hacer ajustes a la configuración. Dentro de este notará que la información que le será de utilidad viene comentada con un símbolo # y los ejemplos con ; (punto y coma), siendo estos últimos los que tomaremos como referencia. El archivo consiste de varias secciones las cuales inician con el nombre de la sección encerrada en corchetes [ ] en una nueva línea. Cada sección contiene uno o mas pares de clave/valor separado por el signo igual (=). Cada sección representa un recurso compartido o un meta-servicio de SAMBA. La sección [global] es especial debido a que contiene valores que se aplican a todo el servidor SAMBA. Samba soporta una serie de meta-servicios cada uno con un propósito, por ejemplo el recurso compartido [homes] permite a SAMBA proporcionar un directorio personal para cada usuario. El meta-servicio [printers] permite compartir impresoras e indica el directorio de spool para los trabajos recibidos.
Configuración de la sección [global] de servidor SAMBA Definamos primero los parámetros necesarios, como sería el nombre NetBIOS con el que nos vería el grupo de máquinas Windows, el grupo al que pertenecemos y el rango de direcciones IP a las que se permitirá acceder hacia la máquina con GNU/Linux. Abra el fichero
/etc/samba/smb.conf
con su editor de texto favorito.
Empezaremos por establecer el grupo de trabajo o dominio editando la línea workgroup, de este modo: workgroup = REDHAT
Opcionalmente, estableceremos el nombre NetBIOS de la máquina, si no se configura uno, toma por defecto el nombre de host: Red Hat Certified Engineer
46
Interconexión con Windows - SAMBA
netbios Name = Serv1
Para permitir que las impresoras configuradas en Linux sean automáticamente compartidas a través de SAMBA, configure las siguientes opciones: load printers = yes printing = cups cups options = raw
A continuación estableceremos cierto nivel de seguridad. Primero especificando por cuales interfaces del sistema se escucharan peticiones. Cualquier interfaz omitida significará que Samba no responderá a peticiones provenientes de esa interfaz. Esto es útil cuando Samba se ejecuta en un servidor que sirve también de puerta de enlace para la red local, impidiendo se establezcan conexiones desde fuera de la red local. interfaces = 192.168.1.254/24
Continuamos especificando que rango de direcciones IP podrán acceder al servidor SAMBA, descomentando y editando la línea hosts allow. Si nuestra red consiste en la máquinas con dirección IP desde 192.168.1.1 hasta 192.168.1.254, el rango de direcciones IP será 192.168.1. y este permitirá el acceso solo a dichas máquinas. Note por favor el punto al final de cada rango. Edite ésta de manera que quede del siguiente modo: hosts allow = 192.168.1. 127.
Es necesario especificar el modelo de seguridad que utilizará SAMBA para autententicar los usuarios, el valor por defecto y mas comúnmente usado es user. Los valores pueden ser:
47
Utilice este modelo de seguridad si desea definir recursos compartidos que no requieran de una contraseña de acceso (acceso de invitado). Este modelo de seguridad es normalmente utilizado para servidores de impresión.
●
security = share -
●
security = user -
●
security = domain -
Si el nombre de usuario de sus estaciones de trabajo es el mismo que el nombre de usuario de Unix, entonces utilice este modelo de seguridad. Los usuarios deben autenticarse para acceder al recurso compartido. También es posible definir distintos permisos de acceso para cada usuario o grupo de usuarios. Este modelo requiere que los usuarios esten creados tanto en el sistema operativo como en la base de datos de usuarios del SAMBA. Cuando se utiliza este modelo de seguridad, el servidor samba tiene una una cuenta de equipo en el dominio Windows y provoca que todas las solicitudes de autenticación sean validadas por controladores de dominio. En otras palabras, esto convierte a samba en un servidor miembro. Ing. Ivan Ferreira
Interconexión con Windows - SAMBA
Si cuenta con un entorno de Directorio Activo de Windows, es posible unir a samba como un servidor miembro nativo de Directorio Activo. El servidor SAMBA puede unirse al dominio utilizando Kerberos.
●
security = ADS -
●
security
= server - Su utilización no es recomendada y se utilizaba previamente cuando samba no podía pertenecer a un dominio Windows.
A menos que tenga un controlador de dominio Windows, normalmente se utiliza: security = user
Si queremos tener que evitar el registro de Windows 9X y permitir acceso desde Windows 2000/XP, debemos asegurarnos de que las siguientes líneas no estén comentadas: encrypt passwords = yes smb passwd file = /etc/samba/smbpasswd
Si habilita estas lineas, recuerde que debe crear el usuario en el sistema operativo con el comando adduser, y luego en el samba con el comando smbpasswd -a, finalmente el nombre de inicio de sesión en Windows debe ser igual al del usuario que usted ha creado para ese equipo. El comando smbpasswd se utiliza de la siguiente forma: ●
Agregar usuario - smbpasswd
●
Deshabilitar usuario - smbpasswd
●
Habilitar usuario - smbpasswd
-e
●
Eliminar usuario - smbpasswd
-x
●
Establecer la contraseña a nulo - smbpasswd
-a -d
-n
Las máquinas Windows registran su nombre NetBIOS al iniciarse. El método exacto de este registro depende de si se ha configurado o no un servidor WINS, si se habilitó la busqueda LMHOSTS, si se habilita DNS para resolución NetBIOS, etc. En el caso que no se utilice un servidor WINS, toso los registros de nombres y las búsquedas son realizadas a través de broadcast UDP. Esto aísla la resolución de nombres a la subred local a menos que se utilice LMHOSTS para listar todos los nombres y las direcciones IP. Si se utiliza un servidor WINS, el cliente Windows utilizará UDP unicast para registrarse con el servidor WINS. Este paquete puede ser ruteado por tanto WINS permite la resolución de nombres entre redes ruteadas. Durante el proceso de inicio, una elección se lleva a cabo para crear un Local Red Hat Certified Engineer
48
Interconexión con Windows - SAMBA
Master Browser (LMB) si no existe uno. En cada red NetBIOS una máquina será electa para funcionar como el “Domain Master Browser” (DMB). El DMB contacta a cada LMB e intercambia el contenido de la lista de navegación de red, esto permite la navegación entre redes ruteadas. Cada 11 a 15 minutos una elección es mantenida para determinar quien será el “master browser”. Por la naturaleza del criterio de elección, la máquina con mayor tiempo encendida y la versión de protocolo superior entre otros criterios, ganara la elección como DMB. Los clientes que desean navegar la red hacen uso de esta lista, cualquier cambio en la resolución de nombres o fallo del LMB molestará a los usuarios debido a que temporalmente no podrán navegar la red. Por tanto, siempre es recomendada la utilización de un servidor WINS. De ser necesario, puede especificar que el servidor sea el LMB, e incluso sobreponerse a cualquier otro en la red. domain master = yes local master = yes preferred master = yes os level = 34
Utilice esta opción solo si no existe un servidor de Windows NT o 200X Server en la red. Un controlador de dominio Windows utiliza un nivel 32. Si desea que el equipo se comporte como un Windows 9x/Me , es recomendable que configure las siguientes opciones: os level = 2 domain master = no preferred master = no local master = yes
Puede habilitar convertirse en servidor WINS o bien utilizar un servidor WINS ya existente. Se puede ser un servidor WINS o un cliente WINS, pero no ambas cosas a al vez. Si se va ser el servidor WINS, debe habilitarse lo siguiente: wins support = yes
Si se va a utilizar un servidor WINS ya existente, debe descomentar la siguiente línea y especificar que dirección IP utiliza dicho servidor WINS: wins server = 192.168.1.1
Configuración de la sección [shares] de servidor SAMBA Para permitir el acceso a todas las impresoras compartidas verifique que este configurado el recurso printers y el path al cual apunta el recurso existe: [printers]
49
Ing. Ivan Ferreira
Interconexión con Windows - SAMBA comment = ALL Printers. path = /var/spool/samba printable = yes browseable = no printable = yes guest ok = no # Configure a yes si desea que la cuenta invitado imprima writable = no
Para los directorios o volúmenes que se irán a compartir, en el mismo fichero de configuración encontrará distintos ejemplos para distintas situaciones particulares. Para crear un recurso compartido: ●
El nombre del recurso compartido por el cual accederán las máquinas se encuentra entre corchetes.
●
Si lo desea, puede agregar un comentario con la opción comment.
●
Luego debe especificar la ruta al directorio compartido utilizando la opción path
●
Indique las opciones para el recurso compartido, tales como si será de acceso público, de sólo lectura, escritura para ciertos usuarios o grupos o de acceso restringido.
Ejemplos de recursos compartidos: # Este ejemplo es util para personas que desean compartir archivos [tmp] comment = Directorio de archivos temporales path = /tmp read only = no public = yes # Un directorio público donde todos acceden en modo sólo lectura excepto por los # miembros del grupo staff y el usuario fsadmin. [public] comment = Directorio publico path = /app/archivos public = yes read only = yes write list = @staff fsadmin # Un directorio compartido al cual sólo puede acceder el usuario fred. [freddir] comment = Directorio de fred path = /usr/home/fred/privado valid users = fred public = no writable = yes
Hecho todo lo anterior, solo resta iniciar el demonio correspondiente a fin de que cargue los nuevos parámetros configurados. Si iniciará SAMBA por primera vez ejecute lo siguiente: # /sbin/service smb start
Red Hat Certified Engineer
50
Interconexión con Windows - SAMBA
Si va a reiniciar el servicio, ejecute lo siguiente: # /sbin/service smb restart
Por último, asegúrese de que SAMBA iniciará automáticamente cada vez que inicie el servidor. Puede hacerlo fácilmente desde una consola ejecutando el siguiente comando: /sbin/chkconfig smb on
No olvide sincronizar las cuentas entre el servidor GNU/Linux y las estaciones con Windows. Es decir, si en una máquina con Windows ingresamos como el usuario "rhuser" con contraseña "P@ssw0rd", en el servidor GNU/Linux debe existir también dicha cuenta con ese mismo login y esa misma contraseña. Añada las cuentas el comando adduser y también con smbpasswd. # /usr/sbin/useradd # /usr/bin/smbpasswd -a
O bien, si no deseamos que las cuentas que se vayan a crear puedan acceder a servicios distintos de SAMBA, como serían Telnet, SSH, etc, es decir, que no se les permita hacer login al sistema, podemos utilizar la siguiente alternativa que solo permitirá acceso a SAMBA, pero impedirá que el usuario intente acceder al servidor y obtenga un shell: # /usr/sbin/useradd -s /bin/false # /usr/bin/smbpasswd -a
Ejemplo de un fichero de configuración de SAMBA # Parámetros globales [global] workgroup = REDHAT netbios name = Serv1 server string = Servidor de Archivos interfaces = 192.168.1.254/24 encrypt passwords = Yes log file = /var/log/samba/%m.log max log size = 0 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 domain logons = Yes domain master = True preferred master = yes dns proxy = No wins support = Yes remote announce = 192.168.1.255 hosts allow = 192.168.1. 127. load printers = yes printing = cups # Recursos compartidos [homes] comment = Home Directories valid users = %S read only = No create mask = 0664
51
Ing. Ivan Ferreira
Interconexión con Windows - SAMBA directory mask = 0775 browseable = No [printers] comment = All Printers path = /var/spool/samba guest ok = yes printable = yes browseable = no [FTP] comment = Directorio del servidor FTP path = /var/ftp/pub read only = no guest ok = yes
Accediendo a recursos SAMBA Indudablemente el método más práctico y seguro es el comando smbclient. Este permite acceder hacía cualquier servidor Samba o Windows como si fuese el comando ftp en modo texto. Para acceder al cualquier recurso de alguna máquina Windows o servidor SAMBA determine primero que volúmenes o recursos compartidos posee está. utilice el comando smbclient del siguiente modo: # smbclient -U -L //
Por ejemplo: # smbclient -U -L //
Lo cual le devolvería más menos lo siguiente: added interface added interface Anonymous login Domain=[REDHAT]
ip=192.168.1.254 bcast=192.168.1.255 nmask=255.255.255.0 ip=192.168.200.254 bcast=192.168.200.255 nmask=255.255.255.0 successful OS=[Windows]
Sharename --------publico HPDeskjet
Type ----Disk Printer
Workgroup --------REDHAT
Master ------Serv1
Comment ------Directorio Publico
La siguiente corresponde a la sintaxis básica para poder navegar los recursos compartidos por la máquina Windows o el servidor SAMBA: # smbclient //host/recurso -U usuario
Ejemplo: Red Hat Certified Engineer
52
Interconexión con Windows - SAMBA # smbclient //serv1/publico -U rhuser
Después de ejecutar lo anterior, el sistema solicitará se proporcione la contraseña del usuario rhuser en el equipo denominado Serv1. # smbclient //serv1/publico -U rhuser added interface ip=192.168.1.254 bcast=192.168.1.255 nmask=255.255.255.0 Password: Domain=[LPT] OS=[Unix] Server=[Samba 2.2.1a] smb: \>
Pueden utilizarse virtualmente los mismos comandos que en el shell del comando ftp, como serían get, mget, put, del, etc. En el ejemplo anterior hay un volumen compartido llamado publico. Si queremos montar este, debemos crear un punto de montaje. Éste puede crearse en cualquier directorio sobre el que tengamos permisos de escritura. Para montarlo, utilizamos cualqueiera de los siguientes comandos según la versión de Linux: # mount -t smbfs -o username=,password= //host/recurso /punto/de/montaje/ # mount -t cifs -o username=,password= //host/recurso /punto/de/montaje/
Escenarios típicos A continuación se presenta un escenario que requiere de una planificación adecuada y una configuración correcta del servicio SAMBA. El escenario es el siguiente; Es necesario configurar un recurso compartido que permita el acceso de equipos Windows. Los usuarios rhuser1, rhuser2 y rhuser3 del grupo admin, deben escribir en el recurso compartido, sin embargo, todos los demás usuarios deben poder acceder al recurso compartido, con permisos de solo lectura. Usted debe crear un directorio con el nombre que desee, utilizando el comando correspondiente: # mkdir -p /programas/aplicaciones
Otorgue a los miembros del grupo admin todos los permisos y a todos los usuarios del sistema los permisos de lectura y ejecución. Establezca el permiso SGID para permitir que los archivos creados en el directorio hereden el grupo propietario del directorio: # chown root.admin /programas/aplicaciones # chmod 2775 /programas/aplicaciones
53
Ing. Ivan Ferreira
Interconexión con Windows - SAMBA
Luego debe agregar los usuarios y grupos al sistema operativo: # # # #
groupadd admin useradd rhuser1 -G admin useradd rhuser2 -G admin useradd rhuser3 -G admin
Debe agregar el usuario al SAMBA y configurar su contraseña: # smbpasswd -a rhuser1 # smbpasswd -a rhuser2 # smbpasswd -a rhuser3
Luego debe editar la configuración del SAMBA con el editor vi: # vi /etc/samba/smb.conf
Allí, debe configurar las siguientes opciones para permitir el acceso de los usuarios que no existen en el SAMBA: guest account = nobody map to guest = Bad User
Configurar una entrada como la siguiente [Aplicaciones] comment = Directorio de aplicaciones path = /programas/aplicaciones guest ok = yes writable = no write list = @admin
Samba vuelve a leer su archivo de configuración cada 60 segundos para detectar cambios. Si lo desea, puede forzar la lectura del archivo de configuración sin afectar las conexiones existentes ejecutando el comando: # service smb reload
El cual envia la señal -HUP a los demonios SAMBA. Para comprobar que se haya creado el recurso compartido ejecute el siguiente comando: # smbclient -L //localhost -N
Para probar el acceso al recurso compartido ejecute el siguiente comando: # smbclient //localhost/Aplicaciones -U rhuser1
Si desea montar el recurso compartido desde un cliente Linux ejecute: # mount -t cifs /mnt/aplicaciones
Red Hat Certified Engineer
//Serv1/Aplicaciones
-o
username=rhuser1,password=
54
6
Servidor proxy Squid
Servidor proxy Squid
Servidor proxy Squid Squid es el software para servidor Proxy más popular y extendido entre los sistemas operativos basados sobre UNIX. Es muy confiable, robusto y versátil. Al ser software libre, además de estar disponible el código fuente, está libre del pago de costosas licencias por uso o con restricción a un uso con determinado número de usuarios. Entre otras cosas, Squid puede hacer Proxy y cache con los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, cache transparente, WWCP, aceleración HTTP, cache de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario. Nota: Squid no puede funcionar como proxy para servicios como SMTP, POP3, TELNET, SSH, etc. Si se requiere hacer proxy para cualquier cosa distinta a HTTP, HTTPS, FTP, GOPHER y WAIS. Se requerirá o bien implementar enmascaramiento de IP a través de un NAT (Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante.
Configuración básica Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes: •
http_port
•
cache_mem
•
ftp_user
•
cache_dir
• Al menos una Lista de Control de Acceso • Al menos una Regla de Control de Acceso •
httpd_accel_host
•
httpd_accel_port
•
httpd_accel_with_proxy
Red Hat Certified Engineer
56
Servidor proxy Squid
Parámetro http_port Squid por defecto utilizará el puerto 3128 para atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro puerto o bien que lo haga en varios puertos a la vez. En el caso de un Proxy Transparente, regularmente se utilizará el puerto 80 y se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los navegadores de Red para utilizar el servidor Proxy, bastará con utilizar como puerta de enlace al servidor. Es importante recordar que los servidores HTTP, como Apache, también utilizan dicho puerto, por lo que será necesario reconfigurar el servidor Web para utiliza otro puerto disponible, o bien desinstalar o deshabilitar el servidor Web. Hoy en día ya no es del todo práctico el utilizar un Proxy Transparente, a menos que se trate de un servicio de Café Internet u oficina pequeña, siendo que uno de los principales problemas con los que lidian los administradores es el mal uso y/o abuso del acceso a Internet por parte del personal. Es por esto que puede resultar más conveniente configurar un servidor Proxy con restricciones por contraseña, lo cual no puede hacerse con un Proxy Transparente, debido a que se requiere un diálogo de nombre de usuario y contraseña. Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer por defecto el puerto 8080 -servicio de cacheo WWW- para utilizarse al configurar que servidor proxy utilizar. Si queremos aprovechar esto en nuestro favor y ahorrarnos el tener que dar explicaciones innecesarias al usuario, podemos especificar que Squid escuche peticiones en dicho puerto también. Siendo así localice la sección de definición de http_port, y especifique: # # You may specify multiple socket addresses on multiple lines. # # Default: http_port 3128 # http_port 3128 http_port 8080
Si desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP 192.168.1.254, puede hacerse lo siguiente: # # You may specify multiple socket addresses on multiple lines. # # Default: http_port 3128 # http_port 192.168.1.254:3128 http_port 192.168.1.254:8080
Parámetro cache_mem
57
Ing. Ivan Ferreira
Servidor proxy Squid
El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente: ●
Objetos en tránsito (In transit objects) Ej. descargas activas o páginas de servidores remotos que están siendo estiradas por el servidor
●
Objetos populares (Hot objects) Los objetos que squid considera los más utilizados.
●
Objetos negativas en cache (negative-cached) Por defecto se almacenan en caché por cinco minutos y son páginas que responden con: –
302 Moved Temporarily
–
400 Bad Request
–
403 Forbidden
–
404 Not Found
–
500 Internal Server Error.
Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem especifica un límite máximo en el tamaño total de bloques asignados. Los objetos en tránsito tienen mayor prioridad. Cuando se necesita espacio adicional para algún dato que esta siendo recibido, los objetos negativas en caché y populares serán liberados. Es otras palabras los objetos negativas en caché y populares utilizarán todo el espacio no usado y necesitado por los objetos en tránsito. Por defecto se establecen 8 MB. Puede especificarse una cantidad mayor si así se considera necesario, dependiendo esto de los hábitos de los usuarios o necesidades establecidas por el administrador. Si el servidor posee suficiente memoria, podría elevar este parámetro a 32 o 48 MB: cache_mem 32 MB
Squid puede usar mucho más de lo que especifica en este parámetro, por lo tanto sea reservado.
Parámetro cache_dir Este parámetro se utiliza para establecer que tamaño se desea que tenga el cache en el disco duro para Squid. Para entender esto un poco mejor, responda a esta pregunta: ¿Cuanto desea almacenar de Internet en el disco duro? Por defecto Squid utilizará un cache de 100 MB, de modo tal que encontrará la siguiente línea: Red Hat Certified Engineer
58
Servidor proxy Squid
cache_dir ufs /var/spool/squid 100 16 256
Se puede incrementar el tamaño del cache hasta donde lo desee el administrador. Mientras más grande el cache, más objetos de almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un cache de 3 GB: cache_dir ufs /var/spool/squid 3096 16 256
Los números 16 y 256 significan que el directorio del cache contendrá 16 subdirectorios con 256 niveles cada uno. No modifique esto números, no hay necesidad de hacerlo. Es muy importante considerar que si se especifica un determinado tamaño de cache y este excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de cache especificado.
Parámetro ftp_user Al acceder a un servidor FTP de manera anónima, por defecto Squid enviará como contraseña Squid@. Si se desea que el acceso anónimo a los servidores FTP sea más informativo, o bien si se desea acceder a servidores FTP que validan la autenticidad de la dirección de correo especificada como contraseña, puede especificarse la dirección de correo electrónico que uno considere pertinente. ftp_user
[email protected]
Control de acceso Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y otras. Regularmente una lista de control de acceso se establece siguiendo la siguiente sintaxis: acl [nombre de la lista] src [lo que compone a la lista]
Si uno desea establecer una lista de control de acceso que defina sin mayor trabajo adicional a toda la red local definiendo la IP que corresponde a la red y la máscara de la sub-red. Por ejemplo, si se tienen una red donde las máquinas tienen direcciones IP 192.168.1.0 con máscara de subred 255.255.255.0, podemos utilizar lo siguiente: acl our_networks src 192.168.1.0/255.255.255.0
59
Ing. Ivan Ferreira
Servidor proxy Squid
También puede definirse una Lista de Control de Acceso invocando un fichero localizado en cualquier parte del disco duro, y en el cual se en cuenta una lista de direcciones IP. Ejemplo: acl permitidos src "/etc/squid/permitidos"
El fichero /etc/squid/permitidos contendría algo como siguiente: 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.15 192.168.1.16 192.168.1.20 192.168.1.40
Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/permitidos.
Reglas de Control de Acceso Estas definen si se permite o no el acceso a Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda: # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS #
La sintaxis básica es la siguiente: http_access [deny o allow] [lista de control de acceso]
En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos: http_access allow permitidos
También pueden definirse reglas valiéndose de la expresión !, la cual significa excepción. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2: http_access allow lista1 !lista2
Red Hat Certified Engineer
60
Servidor proxy Squid
Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.
Parámetro cache_mgr Por defecto, si algo ocurre con el Cache, como por ejemplo que muera el proceso, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente. cache_mgr
[email protected]
Parámetro cache_peer: caches padres y hermanos El parámetro cache_peer se utiliza para especificar otros proxy-cache en una jerarquía como padres o como hermanos. es decir, definir si hay un proxy adelante o en parelelo. La síntaxis básica es la siguiente: cache_peer servidor tipo http_port icp_port opciones
Ejemplo: Si su cache va a estar trabajando detrás de otro servidor cache, es decir un cache padre, y considerando que el cache padre tiene una IP 192.168.1.1, escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130 (puerto utilizado por defecto por Squid) ,especificando que no se almacenen en cache los objetos que ya están presentes en el cache del proxy padre, utilice la siguiente línea: cache_peer 192.168.1.1 parent 8080 3130 proxy-only
Cuando se trabaja en redes muy grandes donde existen varios servidores proxy haciendo cache de contenido de Internet, es una buena idea hacer trabajar todos los cache entre si. Configurar caches vecinos como sibbling (hermanos) tiene como beneficio el que se consultarán estos caches localizados en la red local antes de acceder hacia Internet y consumir ancho de banda para acceder hacia un objeto que ya podría estar presente en otro cache vecino. Ejemplo: Si su cache va a estar trabajando en paralelo junto con otros caches, es decir caches hermanos, y considerando los caches tienen IP 10.1.0.1, 10.2.0.1 y 10.3.0.1, todos escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130, especificando que no se almacenen en cache los objetos que ya están presentes en los caches hermanos, utilice las siguientes líneas: cache_peer 10.1.0.1 sibbling 8080 3130 proxy-only cache_peer 10.2.0.1 sibbling 8080 3130 proxy-only cache_peer 10.3.0.1 sibbling 8080 3130 proxy-only
Pueden hacerse combinaciones que de manera tal que se podrían tener caches 61
Ing. Ivan Ferreira
Servidor proxy Squid
padres y hermanos trabajando en conjunto en una red local. Ejemplo: cache_peer cache_peer cache_peer cache_peer
10.0.0.1 10.1.0.1 10.2.0.1 10.3.0.1
parent 8080 3130 proxy-only sibbling 8080 3130 proxy-only sibbling 8080 3130 proxy-only sibbling 8080 3130 proxy-only
Aplicando Listas y Reglas de control de acceso Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, procederemos a determinar cuales utilizar para nuestra configuración.
Control de acceso - Caso 1 Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso: acl our_networks src 192.168.1.0/255.255.255.0
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo: # Listas de Control de Acceso: definición de una red local completa # # Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl our_networks src 192.168.1.0/255.255.255.0
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo: # Reglas de control de acceso: Acceso a una Lista de Control de Acceso. # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow localhost http_access allow our_networks http_access deny all
La regla http_access allow our_networks permite el acceso a Squid a la Lista de Control de Acceso denominada our_networks, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.
Control de acceso - Caso 2
Red Hat Certified Engineer
62
Servidor proxy Squid
Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/permitidos, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo: 192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.15 192.168.1.16 192.168.1.20 192.168.1.40
Denominaremos a esta lista de control de acceso como permitidos: acl permitidos src "/etc/squid/permitidos"
Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo: # Listas de Control de Acceso: definición de una red local completa # # Recommended minimum configuration: acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl permitidos src "/etc/squid/permitidos"
Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo: # Reglas de control de acceso: Acceso a una Lista de Control de Acceso. # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # http_access allow localhost http_access allow permitidos http_access deny all
La regla http_access allow permitidos permite el acceso a Squid a la Lista de Control de Acceso denominada permitidos, la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/permitidos. esto significa que cualquier máquina no incluida en /etc/squid/permitidos no tendrá acceso a Squid.
Proxy Transparente Un proxy transparente combina un servidor proxy con NAT de manera que las conexiones son enrutadas dentro del proxy sin configuración por parte del cliente, y habitualmente sin que el propio cliente conozca de su existencia. Si la versión de squid es anterior a la 2.6, para hacer que trabaje como un proxy transparente, configure las siguientes opciones: 63
Ing. Ivan Ferreira
Servidor proxy Squid
# Debe especificarse la IP de cualquier servidor Web en la red local # o bien el valor virtual httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on
Si la versión de squid es 2.6 o superior el proxy transparente se configura simplemente estableciendo transparent en la directiva http_port: http_port 3128 transparent
Nota acerca de Internet Explorer 5.5 y versiones anteriores: Si va a utilizar Internet Explorer 5.5 y versiones anteriores con un proxy transparente, es importante recuerde que dichas versiones tiene un pésimo soporte con los proxies transparentes imposibilitando por completo la capacidad de refrescar contenido. Lo más conveniente es actualizar hacia Internet Explorer 6.x o defintivamente optar por otras alternativas como Mozilla, que consiste en una suite completa de aplicaciones para Internet, o bien Mozilla Firebird, que consiste en un navegador muy ligero y que cumple con los estándares, de las cuales encontrará versión para Windows. Si se utiliza el parámetro ie_refresh con valor on puede hacer que se verifique en los servidores de origen para nuevo contenido para todas las peticiones IMS-REFRESH provenientes de Internet Explorer 5.5 y versiones anteriores.
Proxy transparente - Regla de iptables Para que el proxy transparente funcione, debe indicar por medio de iptables que las solicitudes de conexión al puerto 80 serán redireccionadas al puerto del squid. Considerando que la red local accede a través de eth0 y que Squid escucha peticiones en puerto 8080, se utiliza la siguiente línea: /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \ -j REDIRECT --to-port 8080
Estableciendo el idioma por defecto Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado. Dichas traducciones se pueden encontrar en /usr/lib/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/lib/squid/errors/Spanish en lugar de hacerlo hacia /usr/lib/squid/errors/English. Elimine primero el enlace simbólico actual: Red Hat Certified Engineer
64
Servidor proxy Squid # rm -f /etc/squid/errors
Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español. Red Hat Linux y Fedora Core: ln -s /usr/share/squid/errors/Spanish /etc/squid/errors
Iniciando el servicio al arranque del sistema Una vez terminada la configuración, ejecute el siguiente comando para iniciar por primera vez Squid: service squid start
Si necesita reiniciar para probar cambios hechos en la configuración, ejecute lo siguiente: service squid restart
Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, ejecute lo siguiente: /sbin/chkconfig squid on
Depuración de errores Cualquier error al inicio de squid solo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los ficheros de las Listas de Control de Acceso. Puede realizar diagnóstico de problemas revisando los registros del servidor squid en el directorio /var/log/squid.
65
Ing. Ivan Ferreira
7 Very Secure FTP Daemon (VSFTPD)
Very Secure FTP Daemon (VSFTPD)
Very Secure FTP Daemon (VSFTPD) El protocolo de transferencia de archivos (File transfer protocol) ftp es el mas antiguo y confiable método de transferencia de archivos y es utilizado ampliamente en las organizaciones actualmente. El demonio Very Secure FTP Daemon (vsftpd) es uno de los servidores FTP mas popular y robusto disponible para la comunidad Linux. El servidor vsftpd tiene una prioridad desde su diseño, reforzar los requerimientos de seguridad. El servidor puede operar en una jaula chroot y ahora soporta encriptación TLS/SSL (desde la version 2). La configuración instalada inicialmente provee acceso para descarga a usuarios anónimos. Esta sección cubrirá algunos parámetros básicos de configuración del servidor y como aumentar la seguridad para permitir usuarios autorizados solamente. También se dara una mirada a como habilitar la encriptación TLS/SSL para proveer un nivel de seguridad para la transferencia de archivos. Las extensiones de seguridad FTP son discutidas en RFC2228.
Configuración inicial El archivo de configuración /etc/vsftpd/vsftpd.conf por defecto esta perfectamente adaptado para permitir acceso seguro anónimo y es un buen punto para comenzar las personalizaciones. Antes de modificar el archivo de configuración, haga una copia del archivo actual. Para desplegar un mensaje de bienvenida cada vez que un usuario se conecta, configure el parámetro banner_file y cree un mensaje de bienvenida dentro del archivo especificado. banner_file=/etc/vsftpd/vsftpd.welcome
El parámetro ftpd_banner le permite configurar rápidamente una linea de bienvenida para los usuarios que se conectan. ftpd_banner=Bienvenido al servidor FTP.
Si ambos parámetros estan habilitados, ftpd_banner.
banner_file
es desplegado antes que
Es posible personalizar el mensaje mostrado a medida que los usuarios van navegando por los directorios con el parámetro message_file. Este mensaje puede mostrar un resumen del contenido del directorio o la funcion de los archivos ubicados en él. message_file=.message
El servidor inetd/xinetd.
67
puede ejecutarse en modo independiente o a través de Para habilitar el modo independiente, configure el parámetro listen.
vsftpd
Ing. Ivan Ferreira
Very Secure FTP Daemon (VSFTPD)
listen=YES
El parámetro umask define los permisos por defecto cuando se suben archivos al servidor FTP. El parámetro anon_umask determina los permisos por defecto para archivos subidos por usuarios anónimos y local_umask determina los permisos por defecto para archivos subidos por usuarios locales. anon_umask=077 local_umask=022
La cuenta de usuario utilizada para acceso anónimo es establecido con el parámetro nopriv_user. nopriv_user=ftp
La directiva pasv_enable habilita o deshabilita el modo pasivo del servidor FTP. Por defecto el modo pasivo está habilitado. pasv_enable=NO
Los siguientes parámetros configuran el archivo de registro de transferencias donde se guardará un detalle de los archivos subidos y bajados. xferlog_enable=YES xferlog_file=/var/log/vsftpd.log
El parámetro pam_service_name especifica el nombre del módulo PAM a ser utilizado. pam_service_name=vsftpd
El parámetro anon_root es el directorio donde los archivos FTP deberán ser ubicados para acceso anónimo. El servidor vsftpd tratará de cambiarse a este directorio luego de un inicio de sesión anónimo. Debe ser un directorio vacío y no escribible por el usaurio ftp, a menos que permita que los usuarios anónimos suban los archivos. anon_root=/var/ftp
Control del servicio vsftpd Una vez configurado el servidor vsftpd, puede habilitar la ejecución del servicio durante el inicio del sistema utilizando los siguientes comandos: # chkconfig –level 345 vsftpd on # chkconfig –list
El servicio puede ser iniciado o reiniciado inmediatamente, usando los siguientes comandos: # service vsftpd start
Red Hat Certified Engineer
68
Very Secure FTP Daemon (VSFTPD) # service vsftpd restart
Control de acceso de los usuarios En el estado inicial de la configuración del servidor vsftpd, se permite acceso de descarga a los usuarios anónimos. Para aumentar la seguridad, es necesario realizar ajustes a la configuración del servidor.
Usuarios anónimos Para deshabilitar el acceso anónimo de usuarios, configure el parámetro anonymous_enable a NO, es importante destacar que no es suficiente con simplementa comentar la línea. anonymous_enable=NO
Si el servidor FTP permitirá el acceso FTP, puede evitar que los usuarios anónimos suban archivos y creen directorios por medio de las directivas anon_upload_enable y anon_mkdir_write_enable. Por seguridad, no es recomendado habilitar estas opciones. anon_upload_enable=NO anon_mkdir_write_enable=NO
Para restringir la tasa de transferencia para las subidas hechas por usuarios anónimos y locales, puede configurar la opción anon_max_rate y local_max_rate respectivamente. El valor depende del tipo de conexión que su servidor esta utilizando y es establecido en bytes por segundo. anon_max_rate=10485760 local_max_rate=0
Puede limitar la cantidad de sesiones establecidas por los usuarios en total y la cantidad de sesiones que pueden ser establecidas desde la misma dirección IP. Esto es útil para evitar los aceleradores de descargas que pueden saturar al servidor. max_clients=500 max_per_ip=4
Usuarios locales Normalmente, cualquier usuario que tenga una cuenta en el sistema local puede iniciar sesión a través de ftp y acceder a sus archivos. Como medida de seguridad, no todas las cuentas del sistema deberían ser habilitadas para realizar ftp. A cualquier cuenta de usuario listada en el archivo /etc/vsftpd/user_list se le denegará el acceso al sistema través de ftp. 69
Ing. Ivan Ferreira
Very Secure FTP Daemon (VSFTPD)
Si desea que por defecto, a todas las cuentas de usuario se deniegue el acceso ftp, excepto a los explicitamente permitidos, configure las opciones userlist_deny y userlist_enable.
Si la opción userlist_deny esta configurada a NO, entonces a los usuarios se les denegará el inicio de sesión a menos que esten listados en el archivo especificado en el parámetro userlist_file. La opción
userlist_enable
userlist_enable
especifica el archivo a ser leido cuando la opción
está activa.
userlist_enable=YES userlist_file=/etc/vsftpd/user_list userlist_deny=NO
Si desea evitar que todas las cuentas locales del sistema puedan iniciar sesión a través de FTP, configure las opciones local_enable y write_enable a NO. local_enable=YES write_enable=YES
Las cuentas locales normalmente tienen la posibilidad de navegar a través de todo el sistema de archivos, tal como si estuvieran ingresando desde una terminal, dependiendo de los permisos de los directorios. Para evitar esto, puede enjaular a los usuarios en su directorio HOME, haciendo chroot. Esto significa que el usuario vera a su directorio como como el directorio raíz y no podrá acceder al árbol principal del sistema de archivos. chroot_local_user=YES
Es posible hacer de forma selectiva el enjaulamiento de los usuarios, especificando la lista de usuarios que serán enjaulados en un archivo, usando las siguientes opciones: # chroot_local_user=YES chroot_list_enable=YES chroot_list_file=/etc/vsftpd/vsftpd.chroot_list
Si habilita las tres opciones la lista funciona de forma inversa, esto es, por defecto todos los usuarios estarán en un entorno chroot excepto los listando en chroot_list_file. Habilitando la encriptación SSL/TLS Con el lanzamiento de vsftpd version 2, se realizaron varias mejoras y actualizaciones al paquete FTP y la mas notable de ellas es la inclusión de encriptación TLS/SSL para asegurar la autenticación y transferencia de datos. TLS/SSL no debería ser habilitado si el servidor permitira acceso anónimo, el proceso de encriptación es una carga adicional a los recursos del servidor y Red Hat Certified Engineer
70
Very Secure FTP Daemon (VSFTPD)
debería ser habilitado solo si es realmente necesario. Para habilitar TLS/SSL, la versión de vsftpd debe haber sido compilada con soporte TLS/SSL. Para identificar si la versión ha sido compilada con soporte SSL, ejecute el siguiente comando: # ldd /usr/sbin/vsftpd
Si el comando despliega la biblioteca soporta TLS/SSL.
libssl
como resultado, entonces la versión
Antes de poder usar TLS/SSL, requiere de la genración de una clave privada y un certificado digital. Durante la generación de la clave, se solicitará información acerca del nombre del servidor, nombre de la organización, contacto y código de país. Ejecute los siguientes comandos para generar la clave y el certificado digital: # cd /etc/pki/tls/certs # make vsftpd.pem
El contenido del archivo debe ser verificado para asegurarse que existe la clave privada y el certificado digital. Para examinar el archivo ejecute: # cat vsftpd.pem
Para examinar el certificado digital ejecute: # openssl x509 -in vsftpd.pem –noout -text
Debera asegurar los permisos del certificado, de tal forma a que solo el usuario root tenga acceso, para ello ejecute el siguiente comando: # chmod 600 vsftpd.pem
Mueva el archivo generado al directorio /etc/vsftpd # mv vsftpd.pem /etc/vsftpd
El archivo de configuración ahora debe ser modificado para incluir el soporte de encriptación TLS/SSL. Los parámetros que deberá configurar son: # Si ssl_enable esta habilitado y vsftpd fue compilado con OpenSSL, vsftpd # soportará conexiones via SSL. Necesitará un cliente con soporte SSL también. ssl_enable=YES # El parametro allow_anon_ssl si es configurado a YES, se permitira conexiones # aseguradas con SSL a los usuarios anonimos. allow_anon_ssl=NO
71
Ing. Ivan Ferreira
Very Secure FTP Daemon (VSFTPD) # Si se activa el parametro force_local_data_ssl todas las conexiones no anonimas # seran forzadas al uso de una conexión segura SSL para la transferencia de datos. force_local_data_ssl=NO # Si se activa el parametro force_local_login_ssl todos los inicios de sesion no # anonimos seran forzados a usar SSL para el envio de la contraseña. force_local_logins_ssl=YES # Permitimos conexiones TLS V1 ssl_tlsv1=YES # Las conexiones TLS son preferidas, por tanto se deshabilitan las conexiones # SSL v2 y SSL v3. ssl_sslv2=NO ssl_sslv3=NO # Finalmente, especificamos la ruta al archivo que contiene el certificado digital rsa_cert_file=/etc/fsftpd/vsftpd.pem
Para que los cambios tengan efecto, es necesario reiniciar el servicio: # service vsftpd restart
Clientes FTP con soporte TLS/SSL El cliente FTP gFTP para linux permite conexiones TLS/SSL, sin embargo por defecto rechazará certificados auto formados. Esto puede evitarse deshabilitando la opción “Verify SSL Peer” en las opciones. Cuando realiza una conexión, asegúrese de seleccionar el protocolo FTPS. El cliente FTP SmartFTP para Windows permite conexiones TLS/SSL. El servidor FTP debe ser configurado como un “Sitio Favorito”, luego, las propiedades deben ser ajustadas para usar “FTP over SSL Explicit”.
Red Hat Certified Engineer
72
8
Berkeley Internet Name Domain (BIND)
Berkeley Internet Name Domain (BIND)
Berkeley Internet Name Domain (BIND) En la mayoría de las redes modernas, incluyendo la Internet, los usuarios localizan otras máquinas por su nombre. Esto libera a los usuarios de la pesada tarea de recordar la dirección numérica de los recursos de red. La forma más efectiva de configurar una red para permitir tales conexiones basadas en nombres es configurando un Domain Name Service (DNS) o servidor de nombres, el cual resuelve los nombres de hosts en la red a direcciones numéricas y viceversa. Este capítulo revisa el servidor de nombres incluido con Red Hat Linux, servidor DNS Berkeley Internet Name Domain (BIND), con énfasis en la estructura de sus archivos de configuración y en cómo deberían ser administrados localmente y remótamente. Si utiliza la Herramienta de configuración de Bind system-config-bind, no edite manualmente ningún archivo de configuración BIND pues todos los cambios serán sobreescritos la próxima vez que utilice la Herramienta de configuración de Bind.
Introducción a DNS Cuando hosts en una red se conectan a través de sus nombres de máquinas, también llamado nombre de dominio completamente cualificado (FQDN), DNS es usado para asociar los nombres de las máquinas a las direcciones IP para el host. El uso de nombres de un dominio completamente cualificado y DNS tiene ventajas para los administradores del sistema, éstos dan a los administradores flexibilidad a la hora de cambiar las direcciones IP para máquinas individuales sin realizar preguntas sobre el nombre en las máquinas. Por otro lado, los administradores pueden revolver cuáles máquinas manejan consultas basadas en nombre . DNS es normalmente implementado usando servidores centralizados que autorizan algunos dominios y se refieren a otros servidores DNS para otros dominios. Cuando un host cliente solicita información desde un servidor de nombres, usualmente se conecta al puerto 53. El nombre de servidor luego intenta resolver el FQDN basado en su librería de resolución, la cual puede contener información de autorización sobre el host solicitado o datos en caché de una consulta anterior. Si el nombre del servidor no tiene la respuesta en su librería de resolución, consultará otros nombres de servidores, llamados servidores de nombres de root, para determinar cuáles servidores de nombres son fidedignos para el FQDN en cuestión. Luego, con esa información, consulta los servidores de nombres autoritarios para determinar la dirección IP del host solicitado. Si se está realizando una búsqueda inversa, se usa el mismo procedimiento, excepto que la consulta es realizada con una dirección IP desconocida en vez de un nombre.
Red Hat Certified Engineer
74
Berkeley Internet Name Domain (BIND)
Zonas de servidores de nombres En Internet, el FQDN de un host se puede analizar en diversas secciones y estas secciones se analizan a su vez por orden jerárquico, como en un árbol el tronco, las ramas primarias, las ramas secundarias, etc. Por ejemplo, considere el siguiente FDNQ: update.rhn.redhat.com Cuando miramos cómo un FQDN es resuelto para encontrar la dirección IP que se relaciona a un sistema particular, lea el nombre de derecha a izquierda, con cada nivel de la jerarquía dividido por puntos (.). En nuestro ejemplo, com define el dominio de nivel superior para este FQDN. El nombre redhat es un subdominio bajo com, mientras que rhn es un subdominio bajo redhat. El nombre más hacia la izquierda, update, identifica una máquina específica. Aparte del nombre del dominio, cada sección se llama zona, la cual define un espacio de nombre particular. Un espacio de nombre, controla los nombres de los subdominios de la izquierda. Aunque en el ejemplo solamente hay dos subdominios, un FQDN tiene que contener al menos un subdominio pero puede incluir muchos más; depende de la organización del espacio de nombres elegido. Las zonas son definidas en servidores de nombres autorizados a través del uso de archivos de zona, lo cual describen el espacio de nombres de esa zona, los servidores de correo a ser utilizados por un dominio particular o sub-dominio, y más. Los archivos de zona son almancenados en servidores de nombres primarios (también llamados servidores de nombres maestro), los cuales son verdaderamente autorizados y donde los cambios se hacen a los archivos, y servidores de nombres secundarios (también llamados servidores de nombres esclavos), que reciben sus archivos de zona desde los servidores de nombres primarios. Cualquier servidor de nombres puede ser un servidor primario y secundario para zonas diferentes al mismo tiempo, y también pueden ser considerados autoritarios para múltiples zonas. Todo depende de cómo se configure el servidor de nombres.
Tipos de zonas de los servidores de nombres Existen cinco tipos de configuración de zonas en servidores de nombres de dominio:
75
●
master (maestro) - Almacena los registros de las zonas originales y de autoridad para un cierto espacio de nombres, contestando preguntas de otros servidores de nombres buscando respuestas concernientes a ese espacio de nombres.
●
slave (esclavo) - Responde a las peticiones que provienen de otros Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
servidores de nombres y que se refieren a los espacios de nombres sobre los que tiene autoridad. Sin embargo, los servidores esclavos obtienen la información de sus espacios de nombres desde los servidores maestros. Mantiene una copia de solo lectura de los registros almacenados en una zona maestra. Es utilizada para tolerancia a fallos. ●
stub - Es parecida an servidor esclavo, excepto que repliza solo los registros NS de la zona maestra en lugar de toda la zona.
●
caching only (sólo caché) - ofrece servicios de resolución de nombres a direcciones IP pero no tiene ninguna autoridad sobre ninguna zona. Las respuestas en general se introducen en un caché por un período de tiempo fijo, la cual es especificada por el registro de zona recuperado.
●
forwarder (reenvío) - Reenvía las peticiones a una lista específica de servidores de nombres para la resolución de nombres. Si ninguno de los servidores de nombres especificados puede resolver los nombres, la resolución falla.
●
Hint - El conjunto de servidores de nombres para el dominio raiz “.” (root nameservers) se especifican en una zona hint.
Un servidor de nombres puede contener uno o más de estos tipos de zonas. Por ejemplo, un servidor de nombres puede ser un maestro para algunas zonas, un esclavo para otras y sólo ofrecer el reenvío de resoluciones para otras.
BIND como un servidor de nombres BIND realiza la resolución de nombres a través del demonio /usr/sbin/named. BIND también incluye una utilidad de administración llamada /usr/sbin/rndc. BIND almacena sus archivos de configuración en los siguientes dos lugares: ●
/etc/named.conf
●
/var/named/
El archivo de configuración para el demonio named.
El directorio de trabajo estadísticas y archivos caché.
named
el cual almacena zonas,
El servicio named puede ejecutarse en un entorno enjaulado (chroot). Esto proporciona mayor seguridad debido a que el demonio no puede acceder al sistema de archivos raíz real, en lugar de ello, se genera un sistema de archivos raíz alternativo para la ejecución del servicio. Si el servicio es explotado, no podrá obtener datos del sistema de archivos real. La ejecución de
en entorno enjaulado es controlado por el archivo /etc/sysconfig/named. El archivo por defecto está configurado para ejecutarse en Red Hat Certified Engineer
named
76
Berkeley Internet Name Domain (BIND)
entorno enjaulado: ROOTDIR=/var/named/chroot
Para evitar que named se ejecute en un entorno enjaulado comente esa línea. Las próximas secciones revisan los archivos de configuración de BIND en más detalle. Si named se ejecuta en entorno enjaulado, la ruta a todos los archivos mencionados son relativas al directorio ROOTDIR.
El archivo /etc/named.conf El archivo named.conf es una colección de declaraciones usando opciones anidadas rodeadas por caracteres de llaves, { }. Los administradores deben tener mucho cuidado cuando estén modificando named.conf para evitar errores sintácticos puesto que hasta el error más pequeños puede impedir que el servicio named arranque. No modifique manualmente el archivo /etc/named.conf o cualquier archivo en el directorio /var/named/ si está usando la Herramienta de configuración de Bind. Cualquier cambio manual a esos archivos serán sobreescritos la próxima vez que se use Herramienta de configuración de Bind. Un archivo típico de siguiente: };
named.conf
está organizado de forma similar al ejemplo
{ {valor; [valor]...}; {valor; [valor]...}; {valor; [valor]...};
Etiquetas de comentarios La siguiente es una lista de las etiquetas de comentarios válidas usadas dentro de named.conf: // #
— Cuando se coloca al comienzo de una línea, esa línea es ignorada por named.
— Cuando se coloca al comienzo de una línea, esa línea es ignorada por named.
/* y */ — Cuando el texto se coloca entre estas etiquetas, se ignora el bloque de texto por named.
Declaración acl La sentencia acl (o sentencia de control de acceso) define grupos de hosts a los que se les puede permitir o negar el acceso al servidor de nombres. 77
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
Una declaración acl tiene la siguiente forma: acl { ; [ ; ...] };
En esta declaración, sustituya con el nombre de la lista de control de acceso y reemplace con una lista de direcciones IP separada por puntos y comas. La mayoría de las veces, una dirección IP individual o notación de red IP (tal como 10.0.1.0/24) es usada para identificar las direcciones IP dentro de la declaración acl. La siguiente lista de control de acceso ya están definidas como palabras claves para simplificar la configuración: Hace coincidir todas las direcciones IP.
●
any -
●
localhost -
●
localnets -
●
none -
Hace coincidir cualquier dirección IP que se use el sistema local.
Hace coincidir cualquier dirección IP en cualquier red en la que el sistema local está conectado. No concuerda ninguna dirección IP.
Cuando lo utilice con otras pautas (tales como declaraciones options), las declaraciones acl pueden ser muy útiles al asegurar el uso correcto de su servidor de nombres BIND. El ejemplo siguiente define dos listas de control de acceso y utiliza una declaración options para definir cómo son tratadas en el servidor de nombres: acl black-hats { 10.0.2.0/24; 192.168.0.0/24; }; acl red-hats { 10.0.1.0/24; }; options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; }; }
Este ejemplo contiene dos listas de control de acceso, black-hats y red-hats. Los hosts en la lista black-hats se les niega el acceso al servidor de nombres, mientras que a los hosts en la lista red-hats se les dá acceso normal.
Red Hat Certified Engineer
78
Berkeley Internet Name Domain (BIND)
Declaración include La declaración include permite incluir archivos en un named.conf. De esta forma los datos de configuración confidenciales (tales como claves) se pueden colocar en un archivo separado con permisos de restricción. Una declaración include tiene la forma siguiente: include
""
En esta declaración, archivo.
es reemplazado con una ruta absoluta a un
Declaración options La declaracion options define opciones de configuración de servidor globales y configura otras declaraciones por defecto. Puede ser usado para especificar la ubicación del directorio de trabajo named, los tipos de consulta permitidos y mucho más. La declaración options toma la forma siguiente: options { ; [; ...] };
En esta declaración, las directivas válida.
son reemplazadas con una opción
Las siguientes son opciones usadas a menudo:
79
- Especifica cuáles hosts tienen permitido consultar este servidor de nombres. Por defecto, todos los hosts tienen derecho a consultar. Una lista de control de acceso, o una colección de direcciones IP o redes se puede usar aquí para sólo permitir a hosts particulares hacer consultas al servidor de nombres.
●
allow-query
●
allow-recursion -
●
blackhole -
●
directory -
Parecida a la opción allow-query, salvo que se aplica a las peticiones recursivas. Por defecto, todos los hosts están autorizados a presentar peticiones recursivas en un servidor de nombres. Especifica cuáles hosts no tienen permitido consultar al servidor de nombres. Reemplaza el directorio de trabajo predeterminado /var/named.
named
en vez del directorio
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
●
●
Controla el comportamiento de reenvío de una directiva Se aceptan las siguientes opciones: forward -
forwarders.
Indica que los servidores de nombres especificados en la directiva forwarders sean consultados antes de que named intente resolver el nombre el mismo.
–
first
–
only -
-
Indica que named no intente la resolución de nombres él mismo en el evento de que consultas a los servidores de nombres especificados en la directiva forwarders fallen.
Especifica una lista de direcciones IP válidas para los servidores de nombres donde las peticiones se pueden reenviar para ser resueltas. forwarders
Una directiva forwarders se puede ver como: options { forwarders { 192.168.10.1; 192.168.10.2; }; };
Una servidor de solo reenvío se configura de la siguiente forma: options { forwarders { 192.168.10.1; 192.168.10.2; }; forward only; }; ●
Especifica la interfaz de red en la cual named escucha por solicitudes. Por defecto, todas las interfaces son usadas. listen-on
De esta forma, si el servidor DNS es también una gateway, BIND se puede configurar para sólo contestar solicitudes que se originan desde algunas de las redes. Una directiva listen-on
se
puede ver como:
options { listen-on { 10.0.1.1; }; };
De esta forma, solamente las peticiones que llegan desde la interfaz de red sirviendo a la red privada (10.0.1.1) serán aceptadas. ●
Controla si named notifica a los servidores esclavos cuando una zona es actualizada. Acepta las opciones siguientes: Notify -
– – –
- Notifica a los servidores esclavos. no - No notifica a los servidores esclavos. explicit - Sólo notifica a los servidores esclavos en una lista dentro de una declaración de zona. yes
Red Hat Certified Engineer
also-notify
80
Berkeley Internet Name Domain (BIND)
Especifica la ubicación del archivo del proceso ID creado por named.
●
pid-file
●
statistics-file
Permite especificar la localización alternativa de los archivos de estadísticas. Por defecto, las estadísticas de named son guardadas al archivo /var/named/named.stats.
Existen numerosas opciones disponibles, muchas de ellas dependen unas de otras para poder funcionar correctamente. Consulte el Manual de referencia para el administrador de BIND 9 y la página del manual para bind.conf para más detalles.
Declaración zone Una declaración zone define las características de una zona tal como la ubicación de su archivo de configuración y opciones específicas de la zona. Esta declaración puede ser usada para ignorar las declaraciones globales options. Una declaración zone tiene la forma siguiente: zone domain_name [ ( in | hs | hesiod | chaos ) ] { type master; file path_name; [ forward ( only | first ); ] [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] [ check-names ( warn | fail | ignore ); ] [ allow-update { address_match_list }; ] [ allow-query { address_match_list }; ] [ allow-transfer { address_match_list }; ] [ dialup yes_or_no; ] [ notify yes_or_no; ] [ also-notify { ip_addr; [ ip_addr; ... ] }; [ ixfr-base path_name; ] [ pubkey number number number string; ] }; zone domain_name [ ( in | hs | hesiod | chaos ) ] { type ( slave | stub ); [ file path_name; ] [ ixfr-base path_name; ] masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] }; [ forward ( only | first ); ] [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] [ check-names ( warn | fail | ignore ); ] [ allow-update { address_match_list }; ] [ allow-query { address_match_list }; ] [ allow-transfer { address_match_list }; ] [ transfer-source ip_addr; ] [ dialup yes_or_no; ] [ max-transfer-time-in number; ] [ notify yes_or_no; ] [ also-notify { ip_addr; [ ip_addr; ... ] }; [ pubkey number number number string; ] }; zone domain_name [ ( in | hs | hesiod | chaos ) ] { type forward; [ forward ( only | first ); ]
81
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND) [ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ] [ check-names ( warn | fail | ignore ); ] }; zone "." [ ( in | hs | hesiod | chaos ) ] { type hint; file path_name; [ check-names ( warn | fail | ignore ); ] };
En esta declaración, es el nombre de la zona, es la clase opcional de la zona, y es una lista de opciones que caracterizan la zona. El atributo para la declaración de zona es particularmente importante, pues es el valor por defecto asignado para la directiva $ORIGIN usada dentro del archivo de zona correspondiente localizado en el directorio /var/named/. El demonio named anexa el nombre de la zona a cualquier nombre de dominio que no esté completamente cualificado listado en el archivo de zona. Por ejemplo, si una declaración zone define el espacio de nombres para redhat.com.py, utilice redhat.com.py como el para que sea colocado al final de los nombres de hosts dentro del archivo de zona redhat.com.py. Las opciones más comunes para la declaración zone incluyen lo siguiente: ●
allow-query - Especifica los clientes que se autorizan para pedir información sobre una zona. Por defecto, todas las peticiones de información son autorizadas.
●
allow-transfer - Especifica los servidores esclavos que están autorizados para pedir una transferencia de información de la zona. Por defecto, todas las peticiones se autorizan.
●
allow-update - Especifica los hosts que están autorizados para actualizar dinámicamente la información en sus zonas. Por defecto, no se autoriza la actualización de la información dinámicamente. Tenga cuidado cuando autorice a los hosts para actualizar la información de su zona. No habilite esta opción si no tiene confianza en el host que vaya a usar. Es mejor que el administrador actualice manualmente los registros de zona y que vuelva a cargar el servicio named.
●
file - Especifica el nombre del archivo en el directorio de trabajo contiene los datos de configuración de zona.
●
masters - La opción masters lista las direcciones IP desde las cuales solicitar información autorizada. Solamente se usa si la zona está definida como tipo esclavo.
Red Hat Certified Engineer
named
que
82
Berkeley Internet Name Domain (BIND) ●
●
notify - Controla si named notifica a los servidores esclavos cuando una zona es actualizada. Acepta las opciones siguientes: –
yes Notifica a los servidores esclavos.
–
no No notifica a los servidores esclavos.
–
explicit Solamente notifica a los servidores esclavos especificados en una lista de also-notify dentro de la declaración de una zona.
type - Define el tipo de zona. Abajo se muestra una lista de las opciones válidas: –
forward - Dice al servidor de nombres que lleve a cabo todas las peticiones de información de la zona en cuestión hacia otros servidores de nombres. Tradicionalmente, el uso de reenviadores o forwarders ha sido una propocición al todo o nada. O usa un forwarder para resolver cualquier consulta que su servidor no puede responder por si solo, o no se usan forwarders en lo absoluto. Las zonas forward permiten configurar a su servidor de nombres para usar forwarders solamente cuando buscan ciertos nombres de dominios.
–
hint Tipo especial de zona que se usa para orientar hacia los servidores de nombres root que sirven para resolver peticiones de una zona que no se conoce. No se requiere mayor configuración que la establecida por defecto con una zona hint.
–
master Designa el servidor de nombres actual como el que tiene la autoridad para esa zona. Una zona se puede configurar como tipo master si los archivos de configuración de la zona residen en el sistema.
–
slave Designa el servidor de nombres como un servidor esclavo para esa zona. También especifica la dirección IP del servidor de nombres maestro para la zona.
–
stub Actúa como un servidor esclavo, pero solamente replica los registros NS de la zona maestra. Es utilizada principalmente para delegacion de dominios, en el dominio padre, o cuando el ancho de banda es limitado para realizar una transferencia completa de la zona.
Ejemplo de declaraciones de zone La mayoría de los cambios al archivo /etc/named.conf de un servidor de nombres maestro o esclavo envuelven agregar, modificar o borrar declaraciones zone. Mientras que estas declaraciones zone pueden contener muchas opciones, la mayoría de los servidores de nombres requieren sólo un pequeño subconjunto para 83
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
funcionar efectivamente. Las siguientes declaraciones zone son ejemplos muy básicos que ilustran la relación de servidores de nombres maestro-esclavo. A continuación se muestra un ejemplo de una declaración de zone para un servidor de nombres primario hospedando redhat.com.py (192.168.0.1): zone "redhat.com.py" IN { type master; file "redhat.com.py.zone"; allow-update { none; }; };
En la declaración, la zona es identificada como redhat.com.py, configurado a master y el servicio named se instruye para leer /var/named/chroot/var/named/redhat.com.py.zone (Si se ha habilitado enjaulado). También le dice a named que no permita a ningún otro host actualizaciones.
el tipo es el archivo el entorno que realice
Una declaración de zone de servidor esclavo para redhat.com.py se ve un poco diferente comparado con el ejemplo anterior. Para un servidor esclavo, el tipo se coloca a slave y en lugar de la línea allow-update está una directiva diciéndole a named la dirección IP del servidor maestro. Una declaración de sigue:
zone
para un servidor esclavo para redhat.com.py sería como
zone "redhat.com.py" IN { type slave; file "redhat.com.py.zone"; masters { 192.168.0.1; }; };
Esta declaración zone configura named en el servidor esclavo a que busque por el servidor maestro en la dirección IP 192.168.0.1 por información sobre la zona redhat.com.py. La información que el servidor esclavo recibe desde el servidor maestro es guardada al archivo /var/named/chroot/var/named/redhat.com.py.zone (Si se ha habilitado el entorno enjaulado). Una declaración de zone para un servidor que realiza reenvío condicional (conditional forwarding) para suc1.redhat.com.py y suc2.redhat.com.py sería como sigue: zone "suc1.redhat.com.py" IN { type forward; forwarders { 138.72.10.20; 138.72.30.28; }; }; zone "suc2. redhat.com.py" IN { type forward; forwarders { 138.72.20.20; 138.72.20.28; }; };
Red Hat Certified Engineer
84
Berkeley Internet Name Domain (BIND)
Para permitir que el servidor DNS pueda resolver dominios de la Internet, es necesario agregar una zona hint, el archivo de zona contiene la lista de root nameservers: zone "." IN { type hint; file "named.ca" ; };
Las zonas stub son utilizadas normalmente en los servidores DNS padres cuando se ha implementado delegacion de dominios. La siguiente seria una declaración de zona stub para un dominio llamado redhat.com.py que tiene un subdominio delegado llamado suc1.redhat.com.py: zone "scu1.redhat.com.py" { type stub; masters { 192.253.254.2; }; file "stub.redhat.com.py.zone"; };
Otros tipos de declaraciones La lista siguiente muestra tipos de declaraciones usadas con menos frecuencia disponibles dentro de named.conf. Configura varios requerimientos de seguridad necesarios para usar el comando rndc para administrar el servicio named.
●
controls
●
key ""
Define una clave particular por nombre. Las claves son usadas para autenticar varias acciones, tales como actualizaciones seguras o el uso del comando rndc. Se usan dos opciones con key: –
algorithm
El tipo de algoritma usado, tal como dsa o
hmac-md5. – ●
secret ""
La clave encriptada.
Permite el uso de múltiples tipos de registro, llamados channels. Usando la opción channel dentro de la declaración logging, se puede construir un tipo registro personalizado, con su propio nombre de archivo (file), tamaño límite (size), versión (version), y nivel de importancia (severity). Una vez que se haya definido el canal personalizado, se usa una opción category para clasificar el canal y comenzar a conectar cuando se reinicie named. logging
Por defecto, named registra mensajes estándar al demonio syslog, que les sitúa en /var/log/messages. Esto se debe a que varios canales estándares se encuentran incorporados a BIND junto con varios niveles de severidad, tales como uno que maneja la información de mensajes de registros 85
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
(default_syslog) y otro que maneja mensajes de depuración (default_debug). Una categoría por defecto, llamada default, usa los canales incorporados para hacer conexiones normales sin ninguna configuración especial.
Archivos de zona Los Archivos de zona contienen información sobre un espacio de nombres particular y son almacenados en el directorio de trabajo /var/named/ por defecto o /var/named/chroot/var/named si esta habilitado el entorno enjaulado. Cada archivo de zona es llamado de acuerdo a la opción file en la declaración zone, usualmente en una forma que relaciona al dominio en cuestión e identifica el archivo como conteniendo datos de zona, tal como redhat.com.py.zone. Cada archivo de zona contiene directivas y registros de recursos. Las directivas le dicen al servidor de nombres que realice tareas o aplique configuraciones especiales a la zona. Los registros de recursos define los parámetros de la zona y asignan identidades a hosts individuales. Las directivas son opcionales, pero los registros de recursos se requieren para proporcionar servicios de nombres a la zona. Todas las directivas y registros de recursos deberían ir en sus propias líneas individuales. Los comentarios se pueden colocar después de los punto y comas (;) en archivos de zona. Directivas de archivos de zona Las directivas comienzan con el símbolo de dólar ($) seguido del nombre de la directiva. Usualmente aparecen en la parte superior del archivo de zona. Lo siguiente son directivas usadas a menudo: Dice a named que incluya otro archivo de zona en el archivo de zona donde se usa la directiva. Así se pueden almacenar configuraciones de zona suplementarias aparte del archivo de zona principal.
●
$INCLUDE -
●
$ORIGIN -
Anexa el nombre del dominio a registros no cualificados, tales como aquellos con el nombre de host solamente. Por ejemplo, un archivo de zona puede contener la línea siguiente: $ORIGIN redhat.com.py
Cualquier nombre usado en los registros de recursos que no terminen en un punto (.) tendrán redhat.com.py anexado.
Red Hat Certified Engineer
86
Berkeley Internet Name Domain (BIND) ●
Ajusta el valor Time to Live (TTL) predeterminado para la zona. Este es el tiempo, en segundos, que un registro de recurso de zona es válido. Cada recurso puede contener su propio valor TTL, el cual ignora esta directiva. $TTL -
Cuando se decide aumentar este valor, permite a los servidores de nombres remotos hacer caché a la información de zona para un período más largo de tiempo, reduciendo el número de consultas para la zona y alargando la cantidad de tiempo requerido para proliferar cambios de registros de recursos.
Registros de recursos de archivos de zona El componente principal de un archivo de zona es su registro de recursos. Hay muchos tipos de registros de recursos de archivos de zona. A continuación le mostramos los tipos de registros más frecuentes;
Registro SOA (Start Of Authority) El registro SOA proclama información importante sobre la autoridad de determinados servidores sobre determinados espacios de nombres. Está situado detrás de las directivas, un registro archivo de zona.
SOA
es el primer registro en un
El ejemplo siguiente muestra la estructura básica de un registro SOA: @
IN
SOA
)
(
El símbolo @ coloca la directiva $ORIGIN (o el nombre de la zona, si la directiva $ORIGIN no está configurada) como el espacio de nombres que esta siendo definido por este registro de recursos SOA. El servidor de nombres primario que tiene autoridad para este dominio es usado por el , y el correo electrónico de la persona a contactar sobre este espacio de nombres es sustituído por el . El es incrementado cada vez que se cambia el archivo de zona para que así named sabrá que debería recargar esta zona. El parámetro le dice a cualquier servidor esclavo cuánto tiempo debe esperar antes de preguntar al servidor de nombres maestro si se han realizado cambios a la zona. El 87
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
valor es usado por el esclavo para determinar si esta usando datos de la zona desactualizados y si debería refrescarlos. El valor le dice al servidor de nombres esclavo sobre el intervalo de tiempo que tiene que esperar antes de emitir una petición de actualización de datos en caso de que el servidor de nombres maestro no le responda. Si el servidor maestro no ha respondido a una petición de actualización de datos antes que se acabe el intervalo de tiempo , el servidor esclavo para de responder como una autoridad por peticiones al espacio de nombres. La opción solicita que otro servidor de nombres guarde en caché la información de zona por al menos esta cantidad de tiempo (en segundos). Con BIND, todos los tiempos son siempre referenciados en segundos. Sin embargo, es posible usar abreviaciones cuando se especifiquen unidades de tiempo además de segundos, tales como minutos (M), horas (H), días (D) y semanas (W). El ejemplo siguiente ilustra la forma que un registro de recursos SOA puede tomar cuando es configurado con valores reales. @
IN
SOA
dns1.redhat.com.py hostmaster.redhat.com.py. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day
Registro NS (Name Server) El registro NS anuncia los nombres de servidores con autoridad para una zona particular. Este es un ejemplo de un registro NS: IN
NS
El debería ser un FQDN. Luego, dos nombres de servidores son listados como con autoridad para el dominio. No es importante si estos nombres de servidores son esclavos o si son maestros; ambos son todavía considerados con autoridad. IN IN
NS NS
Red Hat Certified Engineer
dns1.redhat.com.py. dns2.redhat.com.py.
88
Berkeley Internet Name Domain (BIND)
Registro A (Address) El registro de dirección que especifica una dirección IP que se debe asignar a un nombre, como en el ejemplo:
IN
A
Si el valor es omitido, el registro A apunta a una dirección IP por defecto para la parte superior del espacio de nombres. Este sistema es el objetivo para todas las peticiones no FQDN. Considere el siguiente ejemplo de registro A para el archivo de zona redhat.com.py: server1
IN IN
A A
10.0.1.3 10.0.1.5
Las peticiones para redhat.com.py son apuntadas a 10.0.1.3, mientras que las solicitudes para server1.redhat.com.py son dirigidas a 10.0.1.5.
Registro CNAME (Cannonical Name) El registro del nombre canónico, que enlaza un nombre con otro: también conocido como un alias. El próximo ejemplo indica a named que cualquier petición enviada a apuntará al host, . Los registros CNAME son usados normalmente para apuntar a servicios que usan un esquema de nombres común, tal como www para servidores Web.
IN
CNAME
En el ejemplo siguiente, un registro A vincula un nombre de host a una dirección IP, mientras que un registro CNAME apunta al nombre host comúnmente usado www para este. server1 www
IN IN
A CNAME
10.0.1.5 server1
Registro CNAME (Cannonical Name) El registro de Mail eXchange, el cual indica dónde debería de ir el correo enviado a un espacio de nombres particular controlado por esta zona. IN
MX
En este ejemplo, permite una clasificación numérica de los servidores de correo para un espacio de nombres, dando preferencia a algunos 89
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
sistemas de correo sobre otros. El registro de recursos MX con el valor más bajo es preferido sobre los otros. Sin embargo, múltiples servidores de correo pueden tener el mismo valor para distribuir el tráfico de forma pareja entre ellos. El puede ser un nombre de servidor o FQDN. IN IN
MX MX
10 20
mail.redhat.com.py. mail2.redhat.com.py.
En este ejemplo, el primer servidor de correo mail.redhat.com.py es preferido al servidor de correo mail2.redhat.com.py cuando se recibe correo destinado para el dominio redhat.com.py.
Registro PTR (PoinTeR) El registro PoinTeR o puntero, diseñado para apuntar a otra parte del espacio de nombres. Es utilizado en las zonas de búsqueda inversa.
Ejemplo de archivo de zonas Vistos individualmente, las directivas y registros de recursos pueden ser difíciles de comprender. Sin embargo, cuando se colocan juntos en un mismo archivo, se vuelven más fáciles de entender. El ejemplo siguiente muestra un archivo de zona muy básico. $ORIGIN redhat.com.py $TTL 86400 @ IN SOA dns1.redhat.com.py. hostmaster.redhat.com.py. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN IN
NS NS
dns1.redhat.com.py. dns2.redhat.com.py.
IN IN
MX MX
10 20
IN
A
10.0.1.5
server1 server2 dns1 dns2
IN IN IN IN
A A A A
10.0.1.5 10.0.1.7 10.0.1.2 10.0.1.3
ftp mail mail2
IN IN IN
CNAME CNAME CNAME
server1 server1 server2
Red Hat Certified Engineer
mail.redhat.com.py. mail2.redhat.com.py.
90
Berkeley Internet Name Domain (BIND) www
IN
CNAME
server2
En este ejemplo, las directivas estándar y los valores SOA son usados. Los servidores de nombres con autoridad se configuran como dns1.redhat.com.py y dns2.redhat.com.py, que tiene archivos A que los juntan a 10.0.1.2 y a 10.0.1.3, respectivamente. Los servidores de correo configurados con los registros MX apuntan a server1 y server2 a través de registros CNAME. Puesto que los nombres server1 y server2 no terminan en un punto (.), el dominio $ORIGIN es colocado después de ellos, expandiéndolos a server1.redhat.com.py y a server2.redhat.com.py. A través de registros de recursos relacionados A, se puede determinar sus direcciones IP. Los servicios FTP y Web, disponibles en los nombres estándar ftp..redhat.com.py y www..redhat.com.py, son apuntados a los servidores apropiados usando registros CNAME.
Archivos de zona de resolución de nombres inversa Un archivo de zona de resolución de nombres inversa es usado para traducir una dirección IP en un espacio de nombres particular en un FQDN. Se vé muy similar a un archivo de zona estándar, excepto que se usan registros de recursos PTR para enlazar las direcciones IP a un nombre de dominio completamente cualificado. Un registro PTR se vería similar a esto:
IN
PTR
El valor se refiere al último número en una dirección IP que debería apuntar a un sistema FQDN particular. En el ejemplo siguiente, las direcciones IP de la 10.0.1.20 a la 10.0.1.25 apuntan a los FQDNs correspondientes. $ORIGIN 1.0.10.in-addr.arpa $TTL 86400 @ IN SOA dns1.redhat.com.py. hostmaster.redhat.com.py. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day
20 21 22 23 24 25
91
IN IN
NS NS
dns1.redhat.com.py. dns2.redhat.com.py.
IN IN IN IN IN IN
PTR PTR PTR PTR PTR PTR
alice.redhat.com.py. betty.redhat.com.py. charlie.redhat.com.py. doug.redhat.com.py. ernest.redhat.com.py. fanny.redhat.com.py.
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
Este archivo de zona se colocará en funcionamiento con una declaración zone en el archivo named.conf el cual se ve similar a lo siguiente: zone "1.0.10.in-addr.arpa" IN { type master; file "redhat.com.py.rr.zone"; allow-update { none; }; };
Hay muy poca diferencia entre este ejemplo y una declaración de zone estándar, excepto por el nombre de la zona. Observe que una zona de resolución de nombres inversa requiere que los primeros tres bloques de la dirección IP estén invertidos seguido por .in-addr.arpa. Esto permite asociar con la zona a un bloque único de números IP usados en el archivo de zona de resolución de nombres inversa.
Uso de rndc BIND incluye una utilidad llamada rndc la cual permite la administración de línea de comandos del demonio named desde el host local o desde un host remoto. Para prevenir el acceso no autorizado al demonio named, BIND utiliza un método de clave secreta compartida para otorgar privilegios a hosts. Esto significa que una clave idéntica debe estar presente en los archivos de configuración /etc/named.conf y en el rndc, /etc/rndc.conf.
Configuración de /etc/named.conf para rndc Para que rndc se pueda conectar a un servicio named, debe haber una declaración controls en el archivo de configuración del servidor BIND /etc/named.conf. La declaración controls mostrada abajo en el ejemplo permite a desde un host local.
rndc
conectarse
controls { inet 127.0.0.1 allow { localhost; } keys { ; }; };
Esta declaración le dice a named que escuche en el puerto por defecto TCP 953 de la dirección loopback y que permita comandos rndc provenientes del host local, si se proporciona la clave correcta. El valor se relaciona con la declaración key, la cual esta también en el archivo /etc/named.conf. El ejemplo siguiente ilustra la declaración key. key "" { algorithm hmac-md5; secret "";
Red Hat Certified Engineer
92
Berkeley Internet Name Domain (BIND) };
En este caso, el es una clave generar claves HMAC-MD5:
HMAC-MD5.
Use el comando siguiente para
# dnssec-keygen -a hmac-md5 -b -n HOST
Una clave con al menos un largo de 256-bit es una buena idea. La clave actual debería ser colocada en el área se puede encontrar en .
Configuración de /etc/rndc.conf La declaración key es la más importante en /etc/rndc.conf. key "" { algorithm hmac-md5; secret ""; };
y deberían ser exactamente los mismos que sus configuraciones en /etc/named.conf.
Para coincidir las claves especificadas en el archivo de configuración del servidor objetivo /etc/named.conf, agregue las líneas siguientes a /etc/rndc.conf. options { default-server default-key };
localhost; "";
Este comando configura una clave global por defecto. Sin embargo, el comando rndc también puede usar claves diferentes para servidores diferentes, como en el ejemplo siguiente: server localhost { key ""; };
Opciones de línea de comandos de rndc Un comando rndc toma la forma siguiente: rndc
Cuando esté ejecutando rndc en una máquina local configurada de la forma correcta, los comandos siguientes están disponibles:
93
Ing. Ivan Ferreira
Berkeley Internet Name Domain (BIND)
Comando
Descripción
halt
Para inmediatamente el servicio named.
querylog
Registra todas las peticiones hechas a este servidor de nombres.
refresh
Refresca la base de datos del servidor de nombres.
reload
Recarga los archivos de zona pero mantiene todas las respuestas precedentes situadas en caché. Esto le permite realizar cambios en los archivos de zona sin perder todas las resoluciones de nombres almacenadas.
stats
Descarga
stop
Detiene al servidor salvando todas las actualizaciones dinámicas y los datos de las Transferencias de zona incremental (IXFR) antes de salir.
las
estadísticas /var/named/named.stats.
actuales
de
named
al
archivo
Ocasionalmente, puede ser necesario ignorar las configuraciones por defecto en el archivo /etc/rndc.conf. Estan disponibles las siguientes opciones:
Opción
Descripción
-c
Le dice a rndc que use un archivo de configuración diferente a /etc/rndc.conf.
-p
Especifica la utilización de un número de puerto diferente del predeterminado 953 para la conexión del comando rndc.
-s
Dice a rndc que envie el comando a un servidor distinto al default-server especificado en su archivo de configuración.
-y
Le permite especificar una clave distinta de la opción defaultkey en el archivo /etc/rndc.conf.
Se puede encontrar información adicional sobre estas opciones en la página del manual de rndc.
Red Hat Certified Engineer
94
9 Servidor Apache HTTP
Servidor Apache HTTP
Servidor Apache HTTP El Servidor Apache HTTP es un servidor Web de tecnología Open Source sólido y para uso comercial desarrollado por la Apache Software Foundation (http://www.apache.org). Red Hat Linux incluye el Servidor Apache HTTP versión 2 así como también una serie de módulos de servidor diseñados para mejorar la funcionalidad. El archivo de configuración predeterminado instalado en el Servidor Apache HTTP funciona en la mayor parte de los casos. Esta sección subraya cómo personalizar el archivo de configuración /etc/httpd/conf/httpd.conf de Servidor Apache HTTP para ayudar a aquellos que requieren una configuración personalizada. Si utiliza la Herramienta de configuración de HTTP system-config-httpd, no cambie el archivo de configuración del Servidor Apache HTTP manualmente pues la Herramienta de configuración de HTTP vuelve a generar este archivo cada vez que se usa.
Directivas de configuración en httpd.conf El
archivo
de
configuración del Servidor Apache HTTP El archivo httpd.conf está bien comentado y bastante autoexplicativo. Su configuración por defecto funciona para la mayoría los casos; sin embargo, quizás quiera conocer el resto de las opciones configuración más importantes. /etc/httpd/conf/httpd.conf.
es es de de
Sugerencias de configuración generales Si necesita configurar Servidor Apache HTTP sólo tiene que modificar el archivo /etc/httpd/conf/httpd.conf y después recargar o bien apagar y arrancar el proceso del comando httpd. Antes de modificar el archivo httpd.conf, primero haga una copia del archivo original. Si crea una copia de respaldo, podrá recuperar el sistema de posibles errores cometidos antes al editar el nuevo archivo de configuración. Si comete un error y su servidor de web no funciona correctamente, lo primero que debe realizar es revisar lo que lo que acaba de modificar en httpd.conf para ver si no hay errores de transcripción. Después consulte el archivo de registro de errores del servidor web, /var/log/httpd/error_log. Este puede ser difícil de interpretar, todo depende del nivel de experiencia. Si acaba de tener problemas, de todas formas, las últimas Red Hat Certified Engineer
96
Servidor Apache HTTP
entradas deberían de ayudarle a saber lo que ha pasado. Puede utilizar el comando archivo de configuración.
httpd -t
para verificar que esté correcta la sintáxis del
Directiva ServerRoot La directiva ServerRoot especifica el directorio de nivel superior que tiene el contenido web. Por defecto, ServerRoot está configurado a "/etc/httpd" para servidores seguros y no seguros.
Directiva PidFile nombra el archivo en el que el servidor graba su ID de proceso (pid). Por defecto, el PID es listado en /var/run/httpd.pid. PidFile
Directiva Timeout define, en segundos, el tiempo que el servidor esperará para recibir y enviar peticiones durante la comunicación. Específicamente, Timeout define cuánto esperará el servidor para recibir peticiones GET, cuánto esperará para recibir paquetes TCP en una petición POST o PUT y cuánto esperará entre ACKs respondiendo a otros paquetes TCP. Timeout está configurado por defecto a 300, lo cual es apropiado para la mayoría de las situaciones Timeout
Directiva KeepAlive determina si el servidor permitirá más de una petición por conexión y se puede usar para prevenir a un cliente consumir demasiados recursos del servidor. KeepAlive
Por defecto Keepalive está configurado a off. Si Keepalive está en on y el servidor se vuelve muy ocupado, este puede rápidamente generar el máximo número de procesos hijos. En esta situación, el servidor se volverá significativamente lento. Si se activa Keepalive, es una buena idea configurar el KeepAliveTimeout a un valor bajo.
Directiva MaxKeepAliveRequests Esta directiva establece el número máximo de peticiones permitidas por cada conexión persistente. El Proyecto Apache recomienda un valor alto, lo que mejoraría el rendimiento del servidor. El valor predeterminado de 97
Ing. Ivan Ferreira
Servidor Apache HTTP MaxKeepAliveRequests
es de 100 que debería bastar en la mayoría de los casos.
Directiva KeepAliveTimeout La directiva KeepAliveTimeout establece el número de segundos que el servidor esperará a la siguiente petición, tras haber dado servicio a una petición, antes de cerrar la conexión. Una vez recibida la petición, se aplica la directiva Timeout en su lugar. KeepAliveTimeout está configurado a 15 segundos por defecto.
Directivas MinSpareServers y MaxSpareServers El Servidor Apache HTTP se adapta dinámicamente a la carga percibida manteniendo un número apropiado de procesos de servidores libres basado en el tráfico. El servidor comprueba el número de servidores que esperan peticiones y elimina algunos si el número es más alto que MaxSpareServers o crea algunos si el número de servidores es menor que MinSpareServers. El valor predeterminado de MinSpareServers es 5 y el de MaxSpareServers es 20. Estos valores predeterminados son suficientes en la mayoría de los casos. El número de MinSpareServers no debería de ser elevado ya que creará una gran carga incluso cuando el tráfico fuese bajo.
Directiva StartServers establece cuántos procesos serán creados al arrancar. Ya que el servidor Web crea y elimina dinámicamente servidores según el tráfico, no se necesitará cambiar este parámetro. El servidor está configurado para arrancar ocho procesos al arrancar. StartServers
Directiva MaxClients La directiva MaxClients establece un límite al total de los procesos del servidor (o clientes conectados simultáneamente) que se pueden ejecutar a la vez. El propósito principal de esta directiva es prevenir que un Servidor Apache HTTP descontrolado vuelva inestable al sistema operativo. Para los servidores muy ocupados este valor se debería colocar a un valor alto. El valor por defecto es 150. No se recomienda que el valor del comando MaxClients supere 256.
Directiva Listen El comando
Listen
Red Hat Certified Engineer
identifica los puertos en los que el servidor Web aceptará las 98
Servidor Apache HTTP
peticiones entrantes. Por defecto, el Servidor Apache HTTP está configurado para escuchar en el puerto 80 para comunicaciones Web no seguras y (en /etc/httpd/conf.d/ssl.conf el cual define cualquier servidor seguro) en el puerto 443 para comunicaciones seguras.
Directiva Include permite que se incluyan otros archivos de configuración en el tiempo de ejecución. Include
La ruta a estos archivos de configuración pueden ser absolutas o relativas con respecto al ServerRoot.
Directiva User La directiva User establece el nombre de usuario para el proceso del servidor y determina qué archivos puede acceder el servidor. Cualquier archivo que no esté accesible a este usuario tampoco estará disponible para los clientes del Servidor Apache HTTP. Por defecto User es configurado a apache.
Directiva Group Especifica el nombre del grupo de los procesos Servidor Apache HTTP. Por defecto Group está configurado a apache.
Directiva ServerAdmin Configure la directiva ServerAdmin a la dirección de correo electrónico del administrador del servidor Web. Esta dirección de correo aparecerá en los mensajes de error en las páginas generadas por el servidor Web, de tal manera que los usuarios pueden comunicar errores enviando correo al administrador. Por defecto, ServerAdmin es configurado a root@localhost. Una forma típica de configurar ServerAdmin es situarlo en la dirección
[email protected]. Después cree un alias del webmaster para la persona responsable del servidor Web en /etc/aliases y ejecute /usr/bin/newaliases.
99
Ing. Ivan Ferreira
Servidor Apache HTTP
Directiva ServerName Use la directiva ServerName para configurar un nombre de servidor y un número de puerto (que coincida con la directiva Listen) para el servidor. El ServerName no necesita coincidir con el nombre real de la máquina. Por ejemplo, el servidor Web puede ser www.redhat.com.py pero el nombre del servidor es en realidad foo.redhat.com.py. El valor especificado en ServerName debe ser un nombre de Domain Name Service válido (DNS) que pueda ser resuelto por el sistema — no invente algo. Lo siguiente es una directiva
ServerName
de ejemplo:
ServerName www.redhat.com.py:80
Cuando especifique un ServerName, asegúrese de que el par de la dirección IP y el nombre del servidor estén incluidos en el archivo /etc/hosts.
Directiva DocumentRoot es el directorio que contiene la mayoría de los archivos HTML que se entregarán en respuesta a peticiones. El directorio predeterminado DocumentRoot para servidores seguros y no seguros es /var/www/html. Por ejemplo, el servidor puede recibir una petición para el siguiente documento: DocumentRoot
http://www.redhat.com.py/foo.html El servidor busca por el archivo siguiente en el directorio por defecto: /var/www/html/foo.html
Directiva DirectoryIndex es la página por defecto que entrega el servidor cuando hay una petición de índice de un directorio especificado con una barra (/) al final del nombre del directorio. DirectoryIndex
Por ejemplo, cuando un usuario pide la página http://example/this_directory/, recibe la página DirectoryIndex si existe, o un listado generado por el servidor. El valor por defecto para DirectoryIndex es index.html y el tipo de mapa index.html.var. El servidor intentará encontrar cualquiera de estos archivos y entregará el primero que encuentre. Si no encuentra ninguno de estos archivos y Options Indexes esta configurado para ese directorio, el servidor genera y devuelve una lista, en formato HTML, de los subdirectorios y archivos del directorio, a menos que la característica de listar directorios esté desactivada. Red Hat Certified Engineer
100
Servidor Apache HTTP
Directiva AccessFileName denomina el archivo que el servidor utilizará para información de control de acceso en cada directorio. Por defecto, el servidor utilizará .htaccess. AccessFileName
Justo tras AccessFileName, un conjunto de indicadores de Files aplican el control de acceso a cualquier archivo comenzando con un .ht. Estas directivas niegan el acceso Web a cualquier archivo .htaccess (o otros archivos que comiencen con .ht) por razones de seguridad.
Directiva HostnameLookups se puede configurar a on, off o double. Si se configura HostnameLookups a on, el servidor automáticamente resuelve las direcciones IP para cada conexión. Resolver las direcciones IP significa que el servidor hace una o más conexiones a un servidor DNS, añadiendo sobrecarga por procesamiento. Si HostnameLookups es configurado a double, el servidor realiza búsquedas inversa doble añadiendo aún más sobrecarga. HostnameLookups
Para ahorrar recursos en el servidor, defecto.
HostnameLookups
es configurado a
off
por
Si se requieren nombres de host en los archivos de registro, considere ejecutar una de los muchas herramientas de análisis de log que llevan a cabo las búsquedas de DNS de forma mucho más eficiente y por montones cuando se este rotando los archivos de log del servidor Web.
Directiva ErrorLog especifica el archivo donde se guardan los errores del servidor . Por defecto, esta directiva es configurada a /var/log/httpd/error_log. ErrorLog
Directiva LogLevel establece que tantos detalles tendrán los registros de mensajes de error. LogLevel se puede configurar (desde el que tiene menos detalles a los más detallados) a emerg, alert, crit, error, warn, notice, info o debug. El valor predeterminado de LogLevel es warn. LogLevel
Directiva ServerSignature La directiva 101
ServerSignature
añade una línea que contiene la versión del Servidor Ing. Ivan Ferreira
Servidor Apache HTTP
Apache HTTP y el ServerName para cualquier documento generado por el servidor, tales como mensajes de error devueltos a los clientes. Por defecto ServerSignature está configurada a on. También se puede configurar a off o a EMail. EMail, agrega una etiqueta HTML mailto:ServerAdmin a la línea de la firma de las respuestas autogeneradas.
Directiva Redirect Cuando se mueve una página web, se puede utilizar Redirect para crear asignaciones de la ubicación del archivo a un nuevo URL. El formato es como sigue: Redirect / http:///
Por ejemplo, si nuestro servidor es www.redhat.com.py y solicitan la página http://www.redhat.com.py/suc1, será redireccionada al servidor web de la sucursal correspondiente: Redirect
/suc1
http://www.suc1.redhat.com.py
Configuración de directorios Directiva Alias La directiva Alias permite que haya directorios fuera del DocumentRoot a los que puede acceder el servidor. Cualquier URL que termine en el alias será automáticamente traducido a la ruta del alias. Por defecto, ya existe un alias configurado para un directorio icons. El servidor web puede acceder al directorio icons pero el directorio no está en DocumentRoot. Por ejemplo, para acceder al directorio /web/forms usando http://www.redhat.com.py/webform, creamos el siguiente Alias:
el
URL
Alias /webform “/web/forms”
Directiva ScriptAlias La directiva ScriptAlias define dónde pueden encontrarse los scripts CGI (u otros scripts). Normalmente, no es una buena idea colocar los scripts CGI dentro de DocumentRoot. Si los scripts CGI se encontrasen en DocumentRoot, podrían, potencialmente, ser considerados como documentos de texto. Por esta razón, la Red Hat Certified Engineer
102
Servidor Apache HTTP
directiva ScriptAlias diseña un directorio especial fuera del directorio DocumentRoot para contener ejecutables del servidor y scripts. Este directorio es conocido como un cgi-bin y se configura por defecto a /var/www/cgi-bin/. Es posible establecer directorios para almacenar ejecutables fuera del directorio cgi-bin. Por ejemplo, para acceder al directorio /web/applications usando el URL http://www.redhat.com.py/webap, creamos el siguiente ScriptAlias: ScriptAlias /webap “/web/applications”
Directiva AddHandler La directiva AddHandler mapea extensiones de archivos a manejadores específicos. Por ejemplo, el manejador cgi-script puede mapearse con la extensión .cgi para que automáticamente trate a cualquier archivo con un nombre que termine en .cgi como un script CGI. A continuación se presenta un ejemplo de una directiva AddHandler para la extensión .cgi y .pl. AddHandler cgi-script .cgi .pl
Esta directiva habilita a CGIs fuera del cgi-bin a que funcionen en cualquier directorio en el servidor que tengan la opción ExecCGI dentro del contenedor de directorios.
Directiva Directory Las etiquetas y se usan para crear lo que se conoce como un contenedor y se usan para agrupar un grupo de directivas de configuración que sólo se aplican a ese directorio y sus subdirectorios. El contenedor Directory también se puede usar para configurar directorios adicionales cgi-bin para las aplicaciones del servidor fuera del directorio especificado en la directiva ScriptAlias. Para lograr esto, el contenedor Directory debe configurar la opción ExecCGI para ese directorio. Por ejemplo, si los scripts CGI están localizados en contenedor siguiente Directory al archivo httpd.conf:
/web/applications,
añada el
Options +ExecCGI
Para que esto funcione, los permisos para los scripts CGI y la ruta completa a los scripts, se deben colocar a 0755. 103
Ing. Ivan Ferreira
Servidor Apache HTTP
Directiva Options La directiva Options controla características del servidor que están disponibles en un directorio en particular. Por defecto, el directorio DocumentRoot, Options está configurado para incluir Indexes y FollowSymLinks. Indexes permite al servidor generar un listado de un directorio si no se especifica el DirectoryIndex (por ejemplo, index.html) es especificado. FollowSymLinks permite al servidor seguir enlaces simbólicos en ese directorio. Las opciones son: Permite la ejecución de los scripts CGI. Los scripts no se ejecutan si no elige esta opción y visualizará el script como una página de texto.
●
ExecCGI -
●
FollowSymLinks -
●
Includes -
●
IncludesNOEXEC
●
Indexes -
●
Multiviews
●
SymLinksIfOwnerMatch -
Permite que se sigan enlaces simbólicos.
Permite las inclusiones en el servidor. Esto permite la generación de contenido dinámico como fecha y hora actual, etc. Permite las inclusiones en el servidor pero anula los comandos #exec y #include en los scripts CGI. Esto es mucho más seguro. -
Muestra una lista formateada de los contenidos de un directorio si la opción DirectoryIndex (como por ejemplo index.html) existe en el directorio pedido. Soporta las visualizaciones múltiples de los contenidos habilitando el módulo mod_negotiation; esta opción no está activada por defecto. Desde HTTP 1.1, los navegadores pueden enviar información al servidor adicional y preferencias además de sus solicitudes de paginas web. Este módulo permite seleccionar el documento que mejor concuerda con las capacidades del cliente. Es útil por ejemplo para desplegar la página en el idioma que corresponde según la preferencia del navegador. -
Permite seguir un enlace simbólico solamente si el fichero o el directorio en cuestión tienen el mismo nombre que el dueño del enlace.
Directiva AllowOverride La directiva AllowOverride indica si puede o no sobreescribir Options por las declaraciones en un archivo .htaccess. Por defecto, tanto el directorio raíz como DocumentRoot están configurados para no permitir la sobreescritura .htaccess. Red Hat Certified Engineer
104
Servidor Apache HTTP
Directiva Order La directiva evaluadas.
Order
controla el orden en el cual las directivas
●
Order Deny,Allow:
●
Order Allow,Deny:
●
Order mutual-failure:
allow
y
deny
son
Las directivas Deny son evaluadas primero y luego las directivas Allow. Si a un host no se ha denegado explícitamente el acceso, se otorga el acceso al recurso. Es el orden por defecto si no se especifica lo contrario. Todas las directivas Allow son evaluadas primero y luego las directivas Deny. Si a un host no se ha otorgado explícitamente el acceso, se deniega el acceso al recurso. Solo hosts que son especificados en la directiva Allow y al mismo tiempo no aparecen en la directiva Deny se otorga el acceso. Si un host no aparece en ninguna directiva, el acceso es denegado.
Ejemplos: # Un directorio el cual permitimos acceso solo a la red local # Se evaluan las directivas Deny primero, luego las allow, por tanto se otorga # acceso a la red local Options Multiviews AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.1 redhat.com.py 192.168 # Un directorio el cual permitimos acceso solo a la red local y contiene scripts # Se evaluan las directivas Allow primero, si no se ha otorgado explicitamente # el acceso, se deniega el acceso al recurso. Options ExcecCGI AllowOverride None Order allow,deny Allow from 127.0.0.1 redhat.com.py 192.168 # Un directorio el cual permitimos acceso acceso a todos y genera un indice HTML # de su contenido Options Indexes AllowOverride None Order allow,deny Allow from all
Directiva UserDir
105
Ing. Ivan Ferreira
Servidor Apache HTTP
es el nombre del subdirectorio dentro del directorio de cada usuario dónde estarán los archivos HTML personal que serán servidos por el servidor de Web. Esta directiva esta configurada por defecto a disable. UserDir
El nombre para el subdirectorio esta configurado a public_html en la configuración por defecto. Por ejemplo, el servidor puede recibir la siguiente petición: http://redhat.com.py/~username/foo.html El servidor buscará por el archivo: /home/username/public_html/foo.html
En el ejemplo de arriba, /home/username/ es el directorio principal del usuario (observe que la ruta por defecto al directorio principal del usuario puede variar). Hay que asegurarse que los permisos de los directorios de usuario sean correctos. El valor de los permisos deben ser de 0711. Los bits de lectura (r) y ejecución (x) deben estar activados en el directorio del usuario public_html (0755 también funcionará). El valor de los permisos con que se servirán los archivos desde public_html debe ser 0644 por lo menos.
Arrancar y detener httpd El RPM de httpd instala el script /etc/rc.d/init.d/httpd, el cual se puede acceder usando el comando /sbin/service. Para iniciar el servidor, como root escriba: /sbin/service httpd start
Para detener el servidor, como root escriba: /sbin/service httpd stop
La opción HTTP.
restart
es un truco para detener y luego arrancar el Servidor Apache
Para reiniciar el servidor, como root escriba: /sbin/service httpd restart
Sin embargo, luego de modificar el archivo httpd.conf, no es necesario que explícitamente detenga e inicie el servidor. Para esto use la opción reload. Para volver a cargar el archivo de configuración, como usuario root escriba: /sbin/service httpd reload
Red Hat Certified Engineer
106
Servidor Apache HTTP
Configuración de máquinas virtuales Para crear una máquina virtual basada en nombre, lo mejor es utilizar el contenedor de la máquina virtual proporcionado en httpd.conf como un ejemplo.
Directiva NameVirtualHost La directiva NameVirtualHost asocia una dirección IP y número de puerto, si es necesario, para cualquier máquina virtual basada en nombres. El hospedaje virtual basado en nombres permite a un Servidor Apache HTTP servir a dominios diferentes sin usar múltiples direcciones IP. Para habilitar el hospedaje basado en nombres, quite los comentarios de la directiva de configuración NameVirtualHost y añada la dirección IP correcta. Luego añada más contenedores VirtualHost para cada host virtual.
Directiva VirtualHost Las etiquetas y crean un contenedor mostrando las características de un host virtual. El contenedor acepta la mayoría de las directivas de configuración.
Máquinas Virtuales La característica incorporada del Servidor Apache HTTP de máquinas virtules permite al servidor servir diferente información basado en cual dirección IP, nombre de host o puerto está siendo solicitado. El ejemplo de máquina virtual se lee como sigue: #NameVirtualHost * # # # ServerAdmin
[email protected] # DocumentRoot /www/docs/dummy-host.redhat.com.py # ServerName dummy-host.redhat.com.py # ErrorLog logs/dummy-host.redhat.com.py-error_log # CustomLog logs/dummy-host.redhat.com.py-access_log common #
Para activar máquinas virtuales basadas en nombre, quite los comentarios de la línea NameVirtualHost eliminando el símbolo de numeral o almohadilla (#). 107
Ing. Ivan Ferreira
Servidor Apache HTTP
Luego, configure un host virtual, quitando los comentarios y personalizando el contenedor . En la línea , cambie el ServerName al nombre DNS válido asignado a la máquina y configure las otras directivas si es necesario. El contenedor es altamente personalizable y acepta casi cada directiva dentro de la configuración del servidor principal. Es posible especificar la dirección IP del servidor en lugar del asterisco (*) en las directivas NameVirtualHost y . La dirección IP es requerida en versiones 1.3.12 y anteriores.
Ejemplo de creación de máquinas virtuales Para crear dos máquinas virtuales, uno llamado www.lab.redhat.com y foro.lab.redhat.com cree el archivo /etc/httpd/conf.d/virtualhosts.conf y configure como el siguiente ejemplo: NameVirtualHost * ServerAdmin
[email protected] DocumentRoot /var/www/html/www ServerName www.lab.redhat.com ErrorLog logs/www.lab.redhat.com-error_log CustomLog logs/www.lab.redhat.com-access_log common ServerAdmin
[email protected] DocumentRoot /var/www/html/foro ServerName foro.lab.redhat.com ErrorLog logs/foro.lab.redhat.com-error_log CustomLog logs/foro.lab.redhat.com-access_log common
Existen servidores que pueden ser accedidos por mas de un nombre a la vez. Esto es posible por medio de la directiva ServerAlias, que se configura en la sección . Por ejemplo, si desea puede agregar lo siguiente a la directiva para foro.lab.redhat.com: ServerAlias soporte.redhat.com
Si especifica la siguiente directiva ServerAlias: ServerAlias *.redhat.com
Todas las solicitudes para cualquier host en redhat.com sera respondida por el servidor virtual al cual se aplica la directiva. Es posible utilizar * y ? como comodines para hacer concordar los nombres. Red Hat Certified Engineer
108
Servidor Apache HTTP
Configuración de autenticación para el acceso a directorios El modulo mod_auth_dbm en el Servidor Apache le permite configurar un sistema de autenticación para el acceso al directorio. La configuración es como sigue: AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user
Observe que la directiva .htaccess.
AuthDBMUserFile
también puede ser usada en archivos
El script Perl dbmmanage, usado para manipular bases de datos de nombres de usuarios y contraseñas. Añade un usuario a la base de datos (usando la contraseña dada) # htdbm -b -TDB authdb username password
Añade un usuario a la base de datos ( le pide la contraseña) # htdbm -TDB authdb username
Eliminar el usuario de la base de datos # htdbm -x -TDB authdb username
Listar usuarios en la base de datos # htdbm -l -TDB authdb
Configuración del Servidor Seguro Apache HTTP El mdulo mod_ssl es un módulo de seguridad para el Servidor Apache HTTP. El mdulo mod_ssl usa las herramientas proporcionadas por el Proyecto OpenSSL para añadir una característica muy importante al Servidor Apache HTTP la habilidad de tener comunicaciones encriptadas. En contraste, usando HTTP normal, las comunicaciones entre el navegador y el servidor Web son enviadas en texto plano, lo cual puede ser interceptado y leído por alguna persona no autorizada. El archivo de configuración mod_ssl está ubicado en /etc/httpd/conf.d/ssl.conf. Para que este archivo sea cargado, y por ende para que mod_ssl funcione, debe tener la sentencia Include conf.d/*.conf en /etc/httpd/conf/httpd.conf. 109
Ing. Ivan Ferreira
Servidor Apache HTTP
Vista preliminar de los paquetes relacionados con la seguridad Para activar el servidor seguro, necesita, como mínimo, tener instalados los siguientes tres paquetes: El paquete httpd contiene el demonio httpd y otras utilidades relacionadas, archivos de configuración, iconos, Servidor Apache HTTP módulos, páginas de manual y otros archivos utilizados por Servidor Apache HTTP.
●
httpd
●
mod_ssl
●
openssl
El paquete mod_ssl incluye el módulo mod_ssl, que proporciona criptografía fuerte para el servidor web Servidor Apache HTTP a través de los protocolos SSL, Secure Sockets Layer y TLS, Transport Layer Security. El paquete openssl contiene el conjunto de herramientas de OpenSSL. El conjunto de herramientas de OpenSSL implementa los protocolos SSL y TLS y también incluye una librería criptográfica de propósito general.
Vista preliminar de certificados y seguridad Su servidor proporciona seguridad usando una combinación del protocolo SSL Secure Sockets Layer y (en la mayoría de los casos) un certificado digital de una Autoridad de Certificación (CA). SSL maneja las comunicaciones encriptadas y la mutua autentificación entre navegadores y su servidor seguro. El certificado digital aprobado por una CA proporciona autentificación para su servidor seguro (el CA pone su reputación detrás de la certificación de la identidad de su organización). Cuando su navegador se esté comunicando usando la encriptación SSL, verá el prefijo https:// al principio de la URL (Localizador de Recursos Uniforme - la dirección de internet) en la barra de navegación. La encriptación depende del uso de claves (imagínelas como anillos codificador/decodificador en formato de datos). En criptografía convencional o simétrica, ambas partes de la transacción tienen la misma clave, la cual usan para decodificar la transmisión del otro. En criptografía pública o asimétrica, coexisten dos claves: una pública y una privada. Una persona o una organización guarda su clave privada en secreto, y publica su clave pública. Los datos codificados con la llave pública sólo pueden ser decodificados con la clave privada; y los datos codificados con la clave privada sólo pueden ser decodificados con la llave pública. Para configurar su servidor seguro, usará criptografía pública para crear un par de claves pública y privada. En muchos casos, enviará su petición de certificado (incluyendo su clave pública), demostrando la identidad de su compañía y pago a la CA. La CA verificará la petición del certificado y su identidad, y entonces mandará Red Hat Certified Engineer
110
Servidor Apache HTTP
un certificado para su servidor seguro. Un servidor seguro usa un certificado para identificarse a sí mismo a los navegadores web. Puede generar su propio certificado (llamado certificado autofirmado) o puede conseguirlo de una Autoridad de Certificación o CA. Un certificado de una CA con buena reputación garantiza que un sitio web está asociado a una compañía u organización particular. Alternativamente, puede crear su propio certificado autofirmado. Note, sin embargo, que estos certificados autofirmados no deben ser usados en muchos entornos de producción. Dichos certificados pueden no ser aceptados automáticamente por el navegador de un usuario, el usuario será preguntado por el navegador si quiere aceptar el certificado y crear la conexión segura.
Generar una clave Tiene que ser root para generar una clave. Antes de generar la clave, debe identificar donde esta almancenada la clave, esta información la puede obtener del archivo /etc/httpd/conf.d/ssl.conf. Verifique la ruta de los archivos mencionados en las opciones: SSLCertificateFile SSLCertificateFile
Una vez determinada la ubicación de los archivos, elimine la clave y el certificado simulados que se generaron durante la instalación con los siguientes comandos: # rm /etc/httpd/conf/ssl.key/server.key # rm /etc/httpd/conf/ssl.crt/server.crt
O en versiones mas recientes: # rm /etc/pki/tls/certs/localhost.crt # rm /etc/pki/tls/private/localhost.key
A continuación, necesita crear su propia clave aleatoria. Cambie al directorio /usr/share/ssl/certs y escriba el comando siguiente: # make genkey
Su sistema mostrará un mensaje similar al siguiente: umask 77 ; \ /usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key Generating RSA private key, 1024 bit long modulus .......++++++ ................................................................++++++ e is 65537 (0x10001) Enter PEM pass phrase:
111
Ing. Ivan Ferreira
Servidor Apache HTTP
O en versiones mas recientes, cambiese al directorio /etc/pki/tls/certs: umask 77 ; \ /usr/bin/openssl genrsa -des3 1024 > /etc/pki/tls/private/localhost.key Generating RSA private key, 1024 bit long modulus .......++++++ ................................................................++++++ e is 65537 (0x10001) Enter pass phrase:
Necesita teclear una palabra de paso. Para mayor seguridad, su palabra de paso debe incluir, al menos, ocho caracteres, incluyendo números y símbolos de puntuación, y no ser una palabra que esté incluida en un diccionario. También, recuerde que su palabra de paso es sensible a las mayúsculas. Le será requerido que reingrese su contraseña, para verificar que es correcta. Una vez que la haya tecleado correctamente, será creado el archivo mostrado en la redirección de la salida del comando, que contendrá dicha clave. Observe que si no quiere teclear la palabra de paso cada vez que comience su servidor seguro, necesitará usar los dos comandos siguientes en vez de make genkey para crear su clave. La ruta que debe especificar para el archivo generado usted la obtendrá del archivo ssl.conf. Utilice el siguiente comando para crear su clave: # /usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key
O dependiendo del archivo de configuración: # /usr/bin/openssl genrsa 1024 > /etc/pki/tls/private/localhost.key
Luego, utilice el comando siguiente para asegurarse que los permisos de su clave están correctamente asignados: # chmod go-rwx /etc/httpd/conf/ssl.key/server.key
O dependiendo del archivo de configuración: # chmod go-rwx /etc/pki/tls/private/localhost.key
Después de usar los comandos anteriores para crear su clave, no necesitará utilizar una contraseña para comenzar su servidor Web seguro. Los problemas asociados con no usar la contraseña están directamente relacionados al mantenimiento de la seguridad en el sistema de la máquina. Si por ejemplo, un individuo sin escrúpulos compromete la seguridad UNIX estándar de la máquina, ésta persona podrá obtener su clave privada. La clave podría ser usada para servir páginas web que aparenten estar en su servidor web. Red Hat Certified Engineer
112
Servidor Apache HTTP
Si las labores de seguridad de UNIX son rigurosamente mantenidas en el sistema (todos los parches y actualizaciones del sistema operativo son instalados tan pronto como están disponibles, no se ejecutan servicios innecesarios o peligrosos, etc.), la contraseña del servidor seguro puede parecer innecesaria. Sin embargo, desde que su servidor Web seguro no necesita ser reiniciado muy a menudo, la seguridad extra proporcionada por la introducción de la contraseña es un pequeño esfuerzo que vale la pena en muchos casos. El archivo server.key o localhost.key deben ser propiedad del usuario root de su sistema y no debe ser accesible por nadie más. Haga una copia de seguridad de dicho archivo y guárdela en un lugar seguro. Necesitará la copia de seguridad por que si pierde el archivo server.key después de haberlo usado para crear su certificado, el susodicho certificado no funcionará más y la CA no podrá ayudarle. Su única solución será pedir (y volver a pagar por ello) un nuevo certificado.
Generar una petición de certificado para enviarla a un CA Una vez creada la clave, el siguiente paso es generar la petición de certificado que necesitaremos enviar al CA de nuestra elección. Asegúrese de estar en el directorio /usr/share/ssl/certs o /etc/pki/tls/certs, según corresponda, y teclee el siguiente comando: # make certreq
Teclee la palabra de paso que eligió cuando generó su clave. Su sistema mostrará algunas instrucciones y le requerirá una serie de respuestas. Dichas respuestas serán incorporadas a la petición del certificado. La pantalla, con respuestas de ejemplo, será similar a esta: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [GB]:PY State or Province Name (full name) [Berkshire]:Asuncion Locality Name (eg, city) [Newbury]:Asuncion Organization Name (eg, company) [My Company Ltd]:Red Hat Paraguay Organizational Unit Name (eg, section) []:Sistemas Common Name (your name or server's hostname) []:www.redhat.com.py Email Address []:
[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Las respuestas por defecto aparecerán entre corchetes [] inmediatamente después de cada petición de entrada. Por ejemplo, la primera información 113
Ing. Ivan Ferreira
Servidor Apache HTTP
requerida es el nombre del país dónde el certificado será usado, parecido a: Country Name (2 letter code) [GB]:
La entrada por defecto, entre corchetes, es relléne con el código de dos letras de su país.
GB.
Para aceptarla, pulse [Intro], o
Tendrá que introducir el resto de las entradas. Todas estas entradas son autoexplicativas, pero necesitará seguir estas directrices. No abrevie la localidad o el estado. Escríbalas enteras. Si está mandando esta información de un CSR a un CA, sea cuidadoso en proporcionar la información correcta en todos los campos, pero especialmente en el Nombre de la Organización y el Nombre común. Las CAs verifican los datos para determinar si su organización es responsable de quién proporcionó como Nombre común. Las CAs rechazarán las peticiones que incluyan información que ellos perciban como inválida. Para Nombre común, asegúrese que teclea el verdadero nombre de su servidor Web seguro (un nombre de DNS válido) y no un alias que el servidor tenga. La Dirección email debe ser la del webmaster o administrador del sistema. Evite caracteres especiales como @, #, &, !, etc. Algunas CAs rechazarán una petición de certificado que contenga un caracter especial. Así, si el nombre de su compañía contiene una "y" comercial (&), escríbalo como "y" en vez de "&". No use los atributos extra (Otra Contraseña y Nombre opcional de la compañía). Para continuar sin introducir estos campos, simplemente pulse [Intro] para aceptar los valores en blanco por defecto. El archivo /etc/httpd/conf/ssl.csr/server.csr o /etc/pki/tls/certs/localhost.csr según corresponda, es creado cuando termine de introducir su información. Este archivo es su petición de certificado, listo para enviar a su CA. Después de haber decidido una CA, siga las instrucciones que ellos proporcionen en su sitio web. Estas instrucciones le dirán como mandar su petición de certificado, cualquier otra documentación que ellos requieran, y como pagarles. Después de haber satisfecho los requisitos de la CA, ellos le mandarán un certificado para usted (normalmente por email). Guarde (o copie y pegue) el certificado que le manden como /etc/httpd/conf/ssl.crt/server.crt o /etc/pki/tls/certs/localhost.crt. Asegúrese de hacer una copia de respaldo.
Red Hat Certified Engineer
114
Servidor Apache HTTP
Creación de un certificado autofirmado Usted puede crear su propio certificado autofirmado. Por favor, tenga en cuenta que un certificado autofirmado no proporciona las garantías de seguridad que un certificado firmado por una CA sí proporciona. Una vez que tenga la clave y que se asegure de estar en el directorio /usr/share/ssl/certs o /etc/pki/tls/certs según correponda, y utilice el siguiente comando: # make testcert
Se le pedirá que introduzca su palabra de paso (a menos que haya generado una clave sin contraseña): Después de que introduzca su contraseña (o sin la petición, si ha creado una clave sin ella), se le pedirá más información. La salida del ordenador y el conjunto de peticiones será parecido al siguiente (necesitará dar la información correcta de su organización y de su máquina): You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [GB]:PY State or Province Name (full name) [Berkshire]:Asuncion Locality Name (eg, city) [Newbury]:Asuncion Organization Name (eg, company) [My Company Ltd]: Red Hat Paraguay Organizational Unit Name (eg, section) []: Sistemas Common Name (your name or server's hostname) []:www.redhat.com.py Email Address []:
[email protected]
Después que proporcione la información correcta, un certificado autofirmado será creado y colocado en /etc/httpd/conf/ssl.crt/server.crt o /etc/pki/tls/certs/localhost.crt. Necesitará reiniciar su servidor seguro, después de generar el certificado, con el comando: # /sbin/service httpd restart
Probar su certificado Para probar el certificado instalado por defecto, un certificado de una CA o un certificado autofirmado, apunte su navegador Web a la siguiente página web (reemplazando server.redhat.com.py con el nombre de su dominio): https://server.redhat.com.py 115
Ing. Ivan Ferreira
Servidor Apache HTTP
Si ha comprado un certificado de una CA bien conocida, su navegador probablemente aceptará el certificado automáticamente (sin pedirle información adicional) y creará una conexión segura. Su navegador no reconocerá automáticamente un certificado de prueba o un certificado autofirmado, porque el certificado no es firmado por una CA. Si no está usando un certificado de una CA, siga las instrucciones proporcionadas por su navegador para aceptar el certificado. Una vez que su navegador acepte el certificado, su servidor seguro mostrará una página de inicio predeterminada.
Forzar el uso del modo SSL Ahora que el servidor tiene habilitado SSL, todas las interacciones con el servidor que esten relacionadas con nombres de usuarios, contraseñas, detalles personales o financieros deben ser enviados a traves de este protocolo. Esto se hace facilmente indicando https:// en lugar de http:// en la dirección URL. Sin embargo, es posible que las personas olviden este gran detalle. Para evitar ello, el servidor tiene otro módulo llamado “mod_rewrite”, el cual permite que una solicitud de USL sea reescrita antes que el servido web responda a la petición de la página. El módulo rewrite provee una forma de forzar la utilización de SSL para cualquier solicitud entrante. Para lograr esto, es necesario crear un archivo de configuración para el módulo rewrite. Con el editor de texto vi, cree el archivo /etc/httpd/conf.d/mod-rewrite.conf # vi /etc/httpd/conf.d/mod-rewrite.conf
En este ejemplo, cualquier solicitud hecha a la carpeta “webmail” se forzará el uso de SSL, y los usuarios pueden introducir sus detalles de forma confidencial. La opción rewrite log puede ser usada para propósitos de solución de problemas. # Rewrite Rules. RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^/webmail/(.*) https://%{SERVER_NAME}/webmail/$1 [R,L] #Debug Rewrite Rules #RewriteLog /var/log/httpd/rewrite_engine_log #RewriteLogLevel 3
Red Hat Certified Engineer
116
10 Servicios de correo electrónico
Servicios de correo electrónico
Servicios de correo electrónico Postfix Postfix es un agente de transporte de correo electrónico (MTA) bastante reciente que se suma a la lista de alternativas al legendario Sendmail. En su diseño han primado factores como la seguridad, la eficiencia y la facilidad de configuración y administración, junto con la compatibilidad con Sendmail y con otros sistemas de correo. Este producto se desarrolló en el centro de investigación Thomas J. Watson Research Center, de IBM.
Arquitectura de Postfix Al contrario de Sendmail, que es un gestor de correo monolítico, en el diseño de Postfix se han disgregado los diversos tratamientos que se realizan sobre un mensaje a su paso por un Mail Transfer Agent (MTA), adjudicando cada tratamiento o grupo de tratamientos a un proceso independiente. El conjunto de todos estos procesos es Postfix. Los procesos que conforman Postfix se comunican a través de sockets que se crean, por razones de seguridad, en un directorio de acceso restringido. La información que intercambian los diversos procesos es la mínima posible, limitándose en la mayoría de los casos a la referencia de la entrada en una cola y la relación de destinatarios, o a un simple identificador de estado. La siguiente figura proporciona una visión global de los elementos que componen Postfix:
Postfix basa su funcionamiento en cuatro colas: maildrop, incoming, active y deferred (cuadrados coloreados en verde). El correo que se genera de forma local se deposita en maildrop para su posterior proceso. El proceso pickup toma los mensajes que llegan a maildrop y los pasa a Red Hat Certified Engineer
118
Servicios de correo electrónico
cleanup, que analiza las cabeceras de los mensajes y deposita éstos en la cola incoming. En la cola active se encuentran aquellos mensajes que están en fase de encaminamiento, y en deferred los mensajes que por diversas causas no se pueden encaminar o están pendientes de reintentar su encaminamiento. El proceso qmgr es el encargado de tratar los mensajes que llegan a la cola incoming, depositarlos en active y lanzar el proceso adecuado para su encaminamiento, como pueden ser local, smtp o pipe. El correo procedente de otros sistemas se atiende a través del proceso smtpd, utilizando el protocolo SMTP, pudiendo utilizar accesos a servidores de RBL o tablas internas para aplicar las políticas de acceso a cada mensaje entrante. Coloreadas de azul aparecen las tablas que, creadas por el administrador, sirven a los diferentes procesos para concretar el tratamiento que debe darse a cada mensaje. Se usan seis tablas: access, aliases, canonical, relocated, transport y virtual. Aunque no es obligatoria la existencia ni utilización de todas ellas. La tabla access permite definir una relación explícita de sistemas a los que se les deben aceptar o rechazar sus mensajes. La utiliza el proceso smptd. La tabla aliases, al igual que en Sendmail, define una serie de nombres alternativos a usuarios locales, y la consulta el proceso local. El proceso cleanup, mediante la tabla canonical establece relaciones entre nombres alternativos y nombres reales, ya sean usuarios locales o no. El proceso qmgr utiliza la tabla relocated para devolver los mensajes de usuarios que han cambiado de dirección: “User has moved to new-email”. Con la tabla transport, que es utilizada por el proceso trivial-rewrite, se define la política de encaminamiento por dominios, subdominios e incluso por dirección concreta de usuario. Para la gestión y soporte de dominios virtuales el proceso cleanup utiliza la tabla virtual. En ella se establecen las relaciones entre usuarios virtuales y reales, e incluso de dominios completos. Todas estas tablas pueden usar alguno de los siguientes tipos de formato de base de datos:
119
●
Fichero binario indexado (btree, hash, dbm, etc).
●
Fichero de texto basado en expresiones regulares ( regexp).
●
Sistema externo de base de datos (NIS, LDAP, MySQL, etc). Ing. Ivan Ferreira
Servicios de correo electrónico
Para conocer qué tipos de formato de base de datos soporta nuestra instalación, se puede usar la directiva /usr/sbin/postconf –m. Para indicar a Postfix el método de acceso a un determinado fichero se antepone al nombre del mismo el método de acceso. Así por ejemplo hash:/etc/postfix/tabla indica que /etc/postfix/tabla es un fichero en formato db. Para crear los ficheros binarios indexados, Postfix dispone de la directiva: postmap. Por ejemplo, para generar el correspondiente binario del fichero anterior se usaría la directiva postmap /etc/postfix/tabla, con lo que se crearía el fichero /etc/postfix/tabla.db.
Archivos de configuración de Postfix Como Sendmail es el MTA por defecto en Red Hat/Fedora, debe cambiar esto utilizando el comando alternatives luego de detener el servicio sendmail: # service sendmail stop # chkconfig sendmail off # alternatives –config mta There are 2 programs which provide 'mta'. Selection Command ----------------------------------------------*+ 1 /usr/sbin/sendmail.sendmail 2 /usr/sbin/sendmail.postfix Enter to keep the current selection[+], or type selection number: 2 # alternatives --display mta mta - status is manual. link currently points to /usr/sbin/sendmail.postfix
... La configuración de Postfix se realiza mediante dos ficheros principales (situados en el directorio /etc/postfix) y varias tablas opcionales que puede crear el administrador. Esos dos ficheros son: Aquí se configuran los procesos que pueden arrancarse y algunos parámetros como el número de cada uno que puede haber simultáneamente, etc. Normalmente sólo hay que tocarlo si queremos usar un sistema alternativo de entrega de correo local (si usamos Cyrus, Courier, por ejemplo), si queremos integrar un antivirus (ClamAV + AMaViS), etc.
●
master.cf
●
main.cf -
-
El fichero donde se define gran parte del funcionamiento de Postfix es main.cf.
Red Hat Certified Engineer
120
Servicios de correo electrónico
EL archivo main.cf Las directivas mínimas, para tener nuestro Postfix corriendo son las siguientes; Especifique el nombre de Internet para este host. El valor de esta variable debe ser un nombre FQDN resoluble a través de consultas DNS. El valor por defecto es utilizar el nombre de host retornado por gethostname(). myhostname =
Ej: myhostname = mail.redhat.com.py
El nombre del dominio de Internet para este sistema de correo; por defecto se utiliza el valor de la variable $myhostname sin el primer componente del valor de la misma. El valor de la variable $mydomain se utiliza por defecto en muchos otros parámetros de la configuración de Postfix. mydomain =
Ej: mydomain = redhat.com.py
Especifique el dominio de Internet con el que se originan los mensajes de correo salientes de este servidor de correo. Este es el dominio que aparece en el campo “From” de los mensajes de correo. Por defecto, se agrega $myhostname. myorigin =
Ej: myorigin = $mydomain
El parámetro inet_interfaces especifica las direcciones de las interfaces de red para las cuales este sistema recibe correo. El valor por defecto para Red Hat/Fedora es activar solamente la interface localhost. Para permitir que nuestro servidor de correo reciba mensajes de otro sistemas debe configurar para que se active en todas las interfaces. inet_interfaces =
Ej: inet_interfaces = all
Especifique los dominios de Internet que este sistema de correo atiende. mydestination =
121
Ing. Ivan Ferreira
Servicios de correo electrónico
Ej: mydestination = $myhostname localhost.localdomain localhost $mydomain
Es con este parámetro le estamos indicando a Postfix cuales dominios de Internet atiende este servidor de correo, es decir, especifica que dominios entregar localmente, en vez de enviarlo a otras maquinas. Esta configuración es suficiente para tener un sistema de correo funcional.
Directivas adicionales La opción queue_directory especifica el lugar de la cola de Postfix. Es también el directorio raíz de los demonios de Postfix (que corren en entorno chroot). queue_directory = /var/spool/postfix
Las opciones command_directory y daemon_directory contienen la ruta donde están los comandos de Postfix y los demonios, respectivamente. command_directory=/usr/sbin daemon_directory=/usr/libexec/postfix
La opción mail_owner indica el usuario que es propietario de la cola de Postfix. Especificar un usuario que no comparta un grupo con otras cuentas y que no posea otros archivos o procesos en la misma maquina. O sea, ni nobody ni daemon. Se debe usar un usuario dedicado. mail_owner = postfix
La opción default_privs indica los privilegios por defecto del agente de entrega de correo para ejecutar un comando o abrir un archivo. NO especificar un usuario con privilegios o el usuario postfix. Generalmente se usa nobody. default_privs = nobody
La opción mail_spool_directory indica el directorio donde las casillas de correo son almacenados. mail_spool_directory = /var/spool/mail
Direcciones canónicas El parámetro canonical_maps apunta a una tabla de mapeo de direcciones (en términos de profesionales de computación, canónico significa “lo usual, estándar o normal). Los mapas canónicos normalmente son utilizados para cambiar la Red Hat Certified Engineer
122
Servicios de correo electrónico
dirección de un formato interno a uno público. Incluya entradas como la siguiente en su tabla canónica: # # /etc/postfix/canonical #
[email protected] [email protected] [email protected] [email protected]
En el archivo main.cf, apunte el parámetro canonical_maps al archivo canonical: canonical_maps = hash:/etc/postfix/canonical
Asegúrese de ejecutar el comando postmap sobre el archivo postfix para que reconozca los cambios en mail.cf:
canonical
y recargue
# postmap /etc/postfix/canonical # postfix reload
Usuarios reubicados El parámetro relocated_maps apunta a una tabla de búsqueda donde puede almacenar una lista de direcciones o dominios que se han movido a otra ubicación: relocated_maps = hash:/etc/postfix/relocated
La tabla de búsqueda usa las direcciones viejas como la clave y su nueva ubicación como el valor. Cuando un mensaje es entregado a una dirección reubicada, Postfix rechaza el intento con un mensaje que indica la nueva dirección como se especifica en la tabla de búsqueda. Podría listar también un dominio para indicar que todos los recipientes en ese dominio son rechazados con el mensaje indicado. El archivo /etc/postfix/relocated contiene entradas como:
[email protected] [email protected] @it.redhat.com.py linuxmail.org
Listas de correo Las listas de correo proporcionan una forma conveniente de enviar un único mensaje de correo a múltiples destinatarios. Postfix proporciona los métodos para crear listas de correos simples a través de aliases. Los aliases pueden apuntar a una lista de correos o archivos que contienen listas de direcciones. Puede crear una lista en el archivo aliases, o cualquier otro archivo que especifica en el parámetro alias_maps. El archivo por defecto de aliases es /etc/aliases. Soponga que usted administra el dominio redhat.com.py y desea que los mensajes de carácter técnico sean enviados a
[email protected], y que los mensajes 123
Ing. Ivan Ferreira
Servicios de correo electrónico
enviados a esta dirección sean recibidos por varios miembros del personal de soporte técnico. Para lograr esto, edite el archivo /etc/aliases y agregue una línea como la siguiente: soporte:
jperez,
[email protected],
[email protected]
Luego de realizar los cambios, reconstruya la tabla de búsqueda de aliases ejecutando: # postalias /etc/aliases
Si tiene muchas direcciones en una lista, es mas conveniente crear un archivo de texto que liste todas las direcciones para la lista. El formato de una entrada alias que apunta a un archivo es como sigue: alias: :include:/ruta/al/archivo
Por ejemplo, para crear la lista
[email protected] la cual lee la lista de miembros de archivo /etc/postfix/notificaciones cree un alias como el siguiente: notificaciones:
:include:/etc/postfix/notificaciones
Cuando se envía un mensaje a
[email protected], el mensaje será entregado a todas las direcciones de correo listadas en el archivo /etc/postfix/notificaciones. Si algún mensaje no puede ser enviado a alguna de las direcciones listadas, el emisor original del mensaje recibe un error explicando el problema de entrega. Para listas largas o para aquellas en las cuales los miembros no se conocen unos a otros, es probablemente mas apropiado que los mensajes de error sean entregados al administrador de la lista. La convención es crear un alias adicional usando el formato
[email protected], es decir, owner- es antepuesto al nombre de la lista. Para el ejemplo anterior, podríamos crear el alias owner-notificaciones: owner-notificaciones:
[email protected]
Administración de colas El demonio de administración de colas, qmgr, es en muchas formas el corazón del sistema Postfix. Todos los mensajes entrantes y salientes, deben pasar a través de la cola. El administrador de colas mantiene cinco colas diferentes: incoming, active, deferred, hold y corrupt. Postfix utiliza un directorio para cada cola bajo la ruta especificada en el parámetro queue_directory. Por defecto la ruta es /var/spool/mail, el cual da una estructura de directorio como la siguiente: Red Hat Certified Engineer
124
Servicios de correo electrónico
/var/spool/mail/active /var/spool/mail/bounce /var/spool/mail/corrupt /var/spool/mail/deferred /var/spool/mail/hold
La cola incoming es donde los mensajes inicialmente entran a Postfix. El administrador de colas proporciona protección para el sistema de archivos a través del parámetro queue_minfree. Por defecto es 0. Puede asegurarse que el disco que almacena la cola no se quede sin espacio indicando un límite. De la cola incoming, el administrador de colas mueve el mensaje a la cola active e invoca al agente de entrega apropiado para manejarlo. Para la mayor parte, si no existen problemas con la entrega, el movimiento de colas es tan rápido que no verá mensajes en la cola. Si postfix está intentando entregar a un servidor SMTP lento o que no está disponible, podría ver mensajes en la cola active. Postfix espera 30 segundos antes de decidir si un sistema remoto no está disponible. Un mensaje que no pudo ser entregado es ubicado en la cola deferred. Los mensajes son diferidos solamente si encuentran un problema de entrega temporal, como un problema DNS o cuando el servidor de destino reporta un problema temporal. Los mensajes que son rechazados, o encontraron un error permanente, son retornados inmediatamente al emisor con el reporte y no se quedan en la cola. Postfix periódicamente verifica la cola para ver si existen mensajes diferidos cuya marca de tiempo indica que están listos para otro intento de entrega. Intentos fallidos de entrega subsiguientes provocan que el tiempo de espera para el reintento se duplique. Puede configurar un tiempo máximo de espera con el parámetro maximal_queue_lifetime, cuando el tiempo ha expirado, Postfix rechaza el mensaje y lo envía al emisor. El periodo por defecto es cinco días (5d). Si establece el valor a 0, el mensaje es retornado inmediatamente. La cola corrupt es simplemente usada para almacenar mensajes dañados o que no pueden ser leídos. Si un mensaje está tan dañado como para hacer algo con él, Postfix lo ubica en esta cola. Los mensajes corruptos son muy raros, pero podrían ser una indicación de un problema del sistema operativo o del hardware.
Herramientas de gestión de colas Postfix proporciona herramientas de línea de comandos para mostrar y administrar los mensajes en la cola. Los comandos principales son postsuper y postqueue, Puede realizar las siguientes tareas en las colas de mensajes:
125
●
Listar mensajes
●
Borrar mensajes
Ing. Ivan Ferreira
Servicios de correo electrónico ●
Retener mensajes
●
Reencolar mensajes
●
Mostrar mensajes
●
Liberar mensajes
Listar mensajes Puede listar todos los mensajes en la cola con el comando postqueue -p. Postfix además proporciona el comando mailq para compatibilidad con Sendmail. # postqueue -p -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------DBA3F1A9 553 Mon May 5 14:42:15
[email protected] (connect to mail.linuxmail.org [192.168.155.63]: Connection refused)
[email protected]
Borrando mensajes El comando postsuper permite eliminar mensajes de la cola. Para remover el mensaje del ejemplo anterior, ejecute el comando postsuper con la opción -d: # postsuper -d DBA3F1A9 postsuper: DBA3F1A9: removed postsuper: Deleted: 1 message
Si desea eliminar todos los mensajes de la cola ejecute el comando: # postsuper -d ALL postsuper: Deleted: 23 messages
Reteniendo mensajes La cola hold está disponible para mensajes que desea mantener en la cola de forma indefinida. Para ubicar el mensaje del ejemplo en la cola hold, use comando postsuper con la opción -h: # postsuper -h DBA3F1A9
La cola ahora contiene un signo de exclamación indicando que el mensaje está retenido: -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------DBA3F1A9 ! 553 Mon May 5 14:42:15
[email protected] (connect to mail.linuxmail.org [192.168.155.63]: Connection refused)
[email protected]
Red Hat Certified Engineer
126
Servicios de correo electrónico
Para mover el mensaje nuevamente a la cola normal para su procesamiento, ejecute el comando con la opción -H: # postsuper -H DBA3F1A9
Reencolando mensajes Si tiene mensajes que fueron diferidos por problemas de configuración que han sido corregidos, puede reencolar los mensajes para que sean entregados. El comando postsuper utiliza la opción -r para reencolar mensajes. Puede especificar el ID de un mensaje o la palabra ALL para reencolar todo: # postsuper -r ALL
Mostrando mensajes El comando postcat muestra el contenido de un archivo en la cola: # postcat -q DBA3F1A9
Liberando mensajes Liberar la cola provoca que Postfix intente entregar todos los mensajes inmediatamente. Puede liberar la cola usando el comando postqueue -f. # postqueue -f
Mapas de transporte Postfix puede ser configurado para reenviar a cualquier otro host, independientemente de como están configurados los registros MX en el servidor DNS. Conceptualmente, los mapas de transporte sobreescriben los tipos de transporte por defecto para la entrega de mensajes. El parámetro transport_maps apunta a uno o más tablas de búsqueda de transporte. La siguiente entrada configura el archivo /etc/postfix/transport como una tabla de búsqueda de transporte: transport_maps = hash:/etc/postfix/transport
La clave de una tabla de búsqueda de transporte es una dirección de correo completa o dominios y subdominios. Cuando una dirección de destino o de dominio coincide con la clave, utiliza el valor de la derecha para determinar el método de 127
Ing. Ivan Ferreira
Servicios de correo electrónico
entrega y el destino. El formato de los valores de la derecha pueden variar dependiendo del tipo de transporte, pero generalmente tiene el formato de transporte:host:puerto. Por ejemplo: # # Transport map # redhat.com.pysmtp:[192.168.0.1]:20025 #
Todos los mensajes destinados a redhat.com.py son reenviados usando el transporte smtp al host con una dirección IP 192.168.0.1. Los mensajes son entregados al puerto 20025 en lugar del puero 25 por defecto. Es requerido encerrar direcciones IP entre corchetes. # # Transport map # redhat.com.pyrelay:[gateway.redhat.com.py] #
Todos los mensajes destinados para redhat.com.py son reenviados usando el transporte relay al host gateway.redhat.com.py. Como no se indica el puerto, se utiliza el puerto por 25 por defecto. El nombre de host es encerrado entre corchetes para evitar que postfix busque registros MX, en lugar de ellos, busca el registro A y entrega a la dirección IP a la cual el nombre de host resuelve. El transporte relay fue introducido en la versión 2 de Postfix para solucionar un posible problema de rendimiento con el agendamiento de las colas. Debería direccionar los mensajes de entrada reenviados a un sistema interno usando el transporte relay, de tal forma a no competir con mensajes destinados a muchos sistemas diferentes en la Internet. # # Transport map # redhat.com.pysmtp #
Todos los mensajes destinados a redhat.com.py son reenviados usando el transporte smtp. Debido a que el host y puerto están en blanco, postfix usa el puerto 25 por defecto y determina el host buscando a través de DNS un MX para el dominio. # # Transport map #
[email protected] #
error:no se aceptan mensajes para jperez
El mensaje de transporte especial error provoca que los mensajes sean rechazados, luego del dos puntos, especifique el reporte del por qué el mensaje fue rechazado. Red Hat Certified Engineer
128
Servicios de correo electrónico
Gateway de reenvío interno Un mail gateway es un sistema de correo que acepta mensajes y reenvía a otro sistema. Mail gateways son comúnmente utilizados en conjunto con sistemas de firewall para limitar el número de servidores que necesitan acceso directo a Internet. Suponga que tiene instalado un mail gateway en la DMZ, gateway.redhat.com.py, y desea que este reenvíe los mensajes recibidos a un host en la HSZ, mail.redhat.com.py. El siguiente procedimiento demuestra como configurar gateway.redhat.com.py para reenviar los mensajes al servidor de correo interno: 1. Asegúrese que DNS ha sido configurado con los recursos MX correctos para redhat.com.py y que apuntan a gateway.redhat.com.py. 2. En el archivo de configuración main.cf, configure relay_domains: relay_domains = redhat.com.py
3. Asegúrese que el parámetro de transporte:
transport_maps
apunta a su tabla de búsqueda
transport_maps = hash:/etc/postfix/transport
4. Agregue la entrada al archivo transport para reenviar los mensajes destinados a redhat.com.py al servidor interno: # # transport maps # redhat.com.py
relay:[mail.redhat.com.py]
5. Recargue postfix para que reconozca los cambios en el archivo de configuración: # postfix reload
Reenvío de correo saliente Para permitir que el servidor mail.redhat.com.py envíe mensajes hacia la Internet sin tener una conexión directa, éste debe enviar los mensajes a gateway.redhat.com.py y éste a su vez reenviarlos hacia la Internet. Para permitir esto, asegúrese que el parámetro del servidor de correo interno. 129
mynetworks
incluye la dirección IP
Ing. Ivan Ferreira
Servicios de correo electrónico
1. En el servidor mail.redhat.com.py, configure el parámetro asegurarse que incluye todos los clientes del sistema.
mynetworks
para
2. Configure los MUA para utilizar mail.redhat.com.py como servidor de correo SMTP. 3. En el archivo mail.cf, configure el parámetro gateway.redhat.com.py:
relayhost
para apuntar a
relayhost = [gateway.redhat.com.py]
4. Recargue postfix para que reconozca los cambios en el archivo de configuración: # postfix reload
Ahora, todos los mensajes entregados a mail.redhat.com.py son reenviados a gateway.redhat.com.py.
Enmascarando nombres de host El enmascaramiento de direcciones se refiere a la idea de que puede ocultar los nombres de los host internos y hacer que todas las direcciones aparenten como si fueran originadas desde el gateway mismo. Cuando un mensaje es enviado desde estos sistemas y la dirección del emisor incluye el nombre completo del host, podría desear que la dirección aparezca con el nombre de dominio solamente. El parámetro masquerade_domains remueve el nombre de host. El parámetro toma una lista de dominios. Cualquier dirección cuyo nombre de host completamente calificado coincide con la porción de dominio, es reescrita de tal forma a que quede solamente la porción del dominio: masquerade_domains = redhat.com.py
Direcciones como
[email protected] [email protected].
son
convertidas
a
Puede listar múltiples dominios y subdominios. Postfix procesa las direcciones contra la lista de dominios en el orden que lo lista. Por ejemplo, considere una red con dos subdominios, suc1.redhat.com.py y suc2.redhat.com.py. Usted desea que las direcciones de estos dominios muestren el subdominio, pero que se oculte el nombre de host o el dominio padre de cualquier otro subdominio. Entonces configure masquerade_domains como sigue: masquerade_domains = suc1.redhat.com.py suc2.redhat.com.py redhat.com.py
Red Hat Certified Engineer
130
Servicios de correo electrónico
Con esta configuración, la dirección
[email protected] coincide con suc1.redhat.com.py y se convierte en
[email protected]. La dirección
[email protected] coincide con suc2.redhat.com.py y se convierte en
[email protected]. Finalmente,
[email protected] coincide con redhat.com.py y se convierte en
[email protected] Puede excluir ciertas cuentas del enmascaramiento. Por ejemplo, si desea que una dirección como
[email protected] se mantenga intacto, agregue la cuenta al parámetro masquerade_exceptions: masquerade_exceptions = admin, root, oracle
Sendmail La mayoría de las distribuciones de GNU/Linux incluyen de manera predeterminada Sendmail, un poderoso servidor de correo electrónico ampliamente utilizado alrededor del mundo. Este requiere de una correcta configuración para su mejor aprovechamiento y poder disponer de un nivel de seguridad aceptable. Es muy común que los administradores inexpertos no se molesten siquiera en establecer un nivel de seguridad apropiado en sus redes locales, y mucho menos en el servidor de correo, el cual ven como un servicio más. Es un error común el configurar Sendmail para que permita enviar correo como sea a cualquier costo. Usualmente este costo significa convertirse en Open Relay, y por lo tanto en un paraíso para personas que se dedican al envío masivo de correo comercial (Spam).
Confirmando la instalación de Sendmail Debe tener instalados los paquetes sendmail y sendmail-cf. Para asegurarse de esto, se puede utilizar la siguiente línea de comando: rpm -q sendmail sendmail-cf
Debe instalar sendmail-cf o no le será posible compilar los archivos necesarios para configurar Sendmail.
Configurando Sendmail Sendmail utiliza dos archivos de configuración, /etc/mail/submit.cf cuando un usuario en el equipo local envia un nuevo mensaje y /etc/mail/sendmail.cf para todas las otras funciones que incluyen al demonio mail. Los archivos de configuración *.cf son generados a partir de archivos macro *.mc que son expandidos por el procesador de macros m4.
131
Ing. Ivan Ferreira
Servicios de correo electrónico
Antes de continuar, debemos editar el fichero /etc/mail/local-host-names, en el cual deberemos de listar todos y cada uno de los aliases que tenga el servidor que estamos configurando, así como los posibles sub-dominios. Es decir, todos los dominios para los cuales estaremos recibiendo correo en un momento dado. # Incluya aquí todos los dominios para los que # recibimos correo localhost localhost.localdomain redhat.com.py mail.redhat.com.py
Procederemos entonces a modificar el archivo /etc/mail/sendmail.mc, con previo respaldo del original, a fin de preparar la configuración del servidor de correo. # cp /etc/mail/sendmail.mc /etc/mail/etc/sendmail.mc.default
Por defecto Sendmail solo permitirá enviar correo solo desde la interfaz loopback (127.0.0.1), es decir, desde el mismo servidor. Si queremos poder enviar correo desde las máquinas de la red local comente la línea o bien, si tiene varias, añada las interfaces desde las cuales se quiere que escuche peticiones sendmail y omita las que no deben, como sería una red local secundaria con restricciones. dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
Si queremos filtrar Spam de manera eficiente, la mejor manera de empezar a hacerlo es rechazando correo proveniente de dominios NO RESUELTOS, es decir dominios que no están registrados en un DNS y que por lo tanto SON inválidos. Para tal fin, a menos que se requiera lo contrario, es necesario mantener comentada la siguiente línea: dnl FEATURE(`accept_unresolvable_domains')dnl
Es necesario establecer que redhat.com.py corresponderá a la máscara que utilizaremos para todo el correo que emitamos desde nuestro servidor. Debe, por tanto, añadirse una línea justo debajo de MAILER(procmail)dnl y que va del siguiente modo: MASQUERADE_AS(redhat.com.py)dnl
Luego se procesa con el siguiente comando para generar /etc/mail/sendmail.cf # m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Control de RELAY Para permitir el uso de nuestro servidor de correo desde ciertos dominios o direcciones IP se pueden utilizar distintos métodos.
Red Hat Certified Engineer
132
Servicios de correo electrónico
El mas simple es agregar los nombres de dominio necesarios al archivo /etc/mail/relay-domains. Deben definirse los dominios para los cuales se estará permitiendo enviar correo electrónico. Esto se hace generando el fichero /etc/mail/relay-domains: # Permitir el dominio redhat.com.py redhat.com.py # Permitir a todos los host de la red 192.168.0.0 # Note que la direccion IP no indica el ultimo octeto pero si el punto. 192.168.0. # Permite a un host en particular 172.17.1.1
Para un ajuste mas preciso, el archivo /etc/mail/access es utilizado. Cada registro se compone de el nombre del dominio o dirección a la izquierda, y a la derecha la acción que debe realizarse. Las acciones pueden ser: Acepta el correo inclusive si otras reglas lo rechazarían, por ejemplo nombre de dominio no puede ser resuelto.
●
OK
●
RELAY
●
REJECT
●
DISCARD
●
TEXTO DE ERROR
Acepta el correo dirigido al dominio indicado o recibido del dominio indicado por el servidor SMTP. Rechazar el correo con un mensaje de error genérico.
Descartar el mensaje utilizando la propiedad de correo.
$#discard
del sistema
Cualquier mensaje de error que cumple con RFC 821.
Para habilitar la opción de la base de datos de acceso, se debe utilizar la siguiente declaración en su fichero sendmail.mc: FEATURE(access_db,`hash -T -o /etc/mail/access.db')dnl
Abrimos ahora el archivo /etc/mail/access y agregamos algunas líneas para definir quienes podrán hacer uso de nuestro servidor de correo para poder enviar mensajes: # Por defecto, solo se permite enviar correo desde localhost... localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY # Debemos añadir solo las direcciones IP # que ahora tenga el servidor 192.168.1.1 RELAY 148.243.59.1 RELAY # Permitimos uso del dominio local
133
Ing. Ivan Ferreira
Servicios de correo electrónico redhat.com.py
RELAY
# Agregue también las direcciones IP que integran su red local. 192.168.1 RELAY 192.168.2 RELAY # Y también podemos agregar las direcciones de correo # electrónico de aquellos a quienes consideremos # "indeseables", o que queramos bloquear. spammer.com 550 No aceptamos correo de spammers spam@algun_spamer.com REJECT info@otro_spammer.com REJECT servidor.indeseable.com REJECT
En este archivo también puede agregar las direcciones de correo electrónico que desee bloquear, como son algunas de quienes envían correo masivo no solicitado -Spam-. Al concluir, debemos también compilar este archivo para generar otro en formato de base de datos a fin de ser utilizado por Sendmail: # makemap hash /etc/mail/access.db < /etc/mail/access
Inicio del servicio sendmail Terminados los detalles de la configuración, reinicie sendmail del siguiente modo y tendrá listo un servidor de correo que podrá utilizar para enviar mensajes para toda su red local utilizando el servidor SMTP de su proveedor de servicios: /sbin/service sendmail restart
Generalmente Sendmail está incluido entre los servicios que de forma predeterminada se inician con el sistema. Si por alguna razón Sendmail no estuviese habilitado, ejecute lo siguiente a fin de habilitar sendmail en los niveles de corrida 3, 4 y 5: /sbin/chkconfig --level 345 sendmail on
Administrando los aliases Los alias de correo son una poderosa opción que permite que el correo sea dirigido a otros apartados postales que son nombres alternativos de usuarios o procesos en un servidor destinatario. Por ejemplo, es una práctica común tener retroalimentación o comentarios con respecto a un servidor de Web y que estén dirigidos a webmaster. Con frecuencia no hay un usuario llamado webmaster. en el servidor, en vez de ello, hay un alias a otro usuario del sistema. Otro uso común para los alias de correo es utilizarlos por los programas de gestión de listas de correo en los cuales un alias dirige todos los mensajes que ingresan al programa de gestión de la lista Red Hat Certified Engineer
134
Servicios de correo electrónico
para que sea interpretado. El fichero /etc/aliases es el lugar en donde los alias se almacenan. El programa sendmail consulta este fichero cuando está determinando cómo manejar un mensaje que ingresa. Si encuentra una línea en este fichero que coincide con el usuario a quien va dirigido el mensaje, lo redirige al lugar que indica dicha línea. De forma específica, hay tres cosas que los alias permiten: • Otorgan un nombre corto o bien conocido para el correo que será dirigido hacia una o más personas. • Pueden invocar a un programa con el mensaje de correo como entrada hacia dicho programa. • Pueden mandar el correo a un fichero. Todos los sistemas requieren de alias para el Postmaster y el MAILER-DAEMON para cumplir con el RFC. Se debe ser especialmente cuidadoso con la seguridad cuando se definan alias que invoquen o escriban a programas, ya que sendmail por lo general se ejecuta con los permisos de root. # # Los siguientes dos alias deben estar presentes para cumplir con el RFC. # Es importante resolverlos en 'una persona' que lea su correo con regularidad. # postmaster: root # línea indispensable MAILER-DAEMON: postmaster # línea indispensable # # # demuestra los tipos más comunes de alias # usenet: janet # alias para una persona admin: joe,janet # alias para varias personas newspak-users: :include:/usr/lib/lists/newspak # lee a los destinatarios desde un fichero changefeed: |/usr/local/lib/gup # alias que invoca a un programa complaints: /var/log/complaints # alias que escribe el correo a un fichero #
Cada vez que actualice el fichero programa:
/etc/aliases,
se debe asegurar de ejecutar el
# /usr/bin/newaliases
para reconstruir la base de datos que sendmail utiliza internamente. La orden /usr/bin/newaliases es un vínculo simbólico al ejecutable de sendmail y, cuando se invoca de esta forma, se comporta exactamente como si hubiese sido invocado así: # /usr/lib/sendmail -bi
135
Ing. Ivan Ferreira
Servicios de correo electrónico
La orden newaliases es una forma alternativa y más adecuada para hacer esto.
Cómo usar un anfitrión inteligente Algunas veces un anfitrión encuentra correo que no puede entregar directamente a un sitio remoto. Con frecuencia es conveniente tener un único sitio en una red que tenga el papel de gestionar la transmisión del correo a sitios remotos que son difíciles de alcanzar, en vez de que cada sitio local intente hacer esto por sí mismo. Una organización puede elegir instalar una red IP privada y utilizar sus propias direcciones IP no registradas. La red privada se puede conectar a Internet mediante un cortafuegos. El enviar el correo desde y hacia los diversos anfitriones dentro de la red privada hacia el mundo exterior utilizando SMTP no será posible en una configuración convencional debido a que los sitios locales no pueden establecer una conexión directa de red a los sitios que están en Internet. En cambio, la organización puede optar por que el cortafuegos tenga la función de anfitrión inteligente. El anfitrión inteligente que se ejecute en el cortafuegos será capaz de establecer conexiones directas de red con los sitios que se encuentran tanto en el interior de la red privada como en el exterior de ella. El anfitrión inteligente puede aceptar correo de ambos anfitriones, de los que están en la red privada y de los que están en Internet, el correo se guarda en un almacenamiento local y luego se gestiona la retransmisión de ese correo directamente al sitio adecuado. Los anfitriones inteligentes se utilizan en general cuando todos los otros métodos de entrega han fallado. Sendmail provee de un método simple para configurar un anfitrión inteligente utilizando la opción SMART_HOST. Las porciones relevantes de nuestra configuración que definen al anfitrión inteligente son: define(`SMART_HOST', `mail.isp.net')
No se necesita especificar que el transporte es SMTP, ya que está dicho por omisión.
Central de correo Para transferir toda la mensajería local (la que llega) pero debidamente cualificada a un host determinado se puede emplear la variable MAIL_HUB. Ejemplo: define(`MAIL_HUB', `smtp:otrohost.localdomain')dnl
Red Hat Certified Engineer
136
Servicios de correo electrónico
Habilitando los servicios POP3 e IMAP Puede habilitar los servicios ipop3 (POP3 tradicional, autenticación en texto plano), pop3s (POP3 seguro, autenticación con criptografía), imap (IMAP tradicional, autenticación en texto plano) e imaps (IMAP seguro, autenticación con criptografía). Utilice aquellos que consideré como más apropiados para su red local de acuerdo a las capacidades de los clientes de correo electrónico utilizados. Tome en cuenta que la autenticación por medio de texto plano es definitivamente un método inseguro, y siempre serán mejor usar los servicios que permitan establecer conexiones seguras.
Dovecot El paquete dovecot proporciona los servicios POP/IMAP. Edite el archivo de configuración /etc/dovecot.conf para habilitar los protocolos pop3 e imap. Para ello, modifique la siquiente línea del archivo de configuración: protocols = imap imaps pop3 pop3s
Luego, inicie el servicio sistema:
dovecot
y habilite para su ejecución durante el arranque del
# service dovecot start # chkconfig dovecot on
Configuración de Webmail SquirrelMail es una aplicación web basada en PHP que se ejecuta en el servidor Apache y permite a los usuarios acceder y leer su correo electrónico desde una ubicación remota a través de un navegador web. La aplicación solamente soporta casillas de correo Imap, no POP3, por tanto su servidor de correo debe priveer acceso Imap. El paquete dovecot e imap soportan ambos protocolos y también encriptación TLS. SquirrelMail tiene muchos plugins extra que han sido desarrollados para él. El paquete tiene dos archivos de configuración, uno que habilita la aplicación en Apache y otra que contiene las configuraciónes PHP. El archivo de configuración de SquirrelMail para Apache es: /etc/httpd/conf.d/squierrelmail.conf
El archivo de configuración contiene un alias que apunta al directorio principal de SquierrelMail y puede ser visualizado ejecutando http://nombre_servidor/webmail. El archivo de configuración del SquierrelMail es el archivo:
137
Ing. Ivan Ferreira
Servicios de correo electrónico /etc/squirrelmail/config.php
El archivo de configuración es muy fácil de entender. Lo mas importante que debe configurar el el nombre del dominio, dónde estan ubicadas las casillas de correo y el servidor utilizado para enviar los mensajes de salida. Si SquierrelMail se está ejecutando en el mismo servidor de correo, entonces puede dejar los valores en localhost: $domain $imapServerAddress $imapPort $useSendmail $smtpServerAddress $smtpPort $sendmail_path $pop_before_smtp $imap_server_type
= = = = = = = = =
'redhat.com.py'; 'localhost'; 143; true; 'localhost'; 25; '/usr/sbin/sendmail'; false; 'uw';
Una de las mayores consultas realizadas acerca de cualquier sistema webmail, es como cambiar el tamaño de los adjuntos que pueden ser enviados. Esto es en realidad una configuración PHP. Es necesario cambiar los valores en el archivo /etc/php.ini. Para ello edite el archivo /etc/php.ini y configure las siguientes opciones: upload_max_filesize = 2M post_max_size = 2M
Red Hat Certified Engineer
138
11 Secure Shell
Secure Shell
Secure Shell Uno de los aspectos mas importantes de cualquier sistema de computación en red es la posibilidad de administrarlo totalmente desde una ubicación remota como si estuviese sentado frente a la terminal. Existen aplicaciones como telnet, rcp y rlogin que permiten la administración remota de sistemas, sin embargo, estos programas son obsoletos y son un riesgo de seguridad, principalmente porque la comunicación no está encriptada. OpenSSH es un conjunto de aplicaciones que proporcionan un enlace encriptado entre la estación de trabajo del administrador y el host remoto, esto asegura que cualquier detalle de la información transferida, como la información de inicio de sesión, se mantenga confidencial.
El demonio SSH El demonio SSH actúa como el servidor que escucha y maneja las conexiones entrantes de los clientes. En su configuración por defecto, el demonio maneja todos los requerimientos para la generación y rotación de claves criptográficas, por tanto se discutira como ajustar los parámetros operacionales del servidor. El archivo de configuración para el servidor SSH es el archivo: /etc/ssh/sshd_config
SSH opera por defecto en el purto TCP 22 y escucha en todos los dispositivos de red instalados. El demonio openssh ademas soporta versiones 1 y 2 del protocolo ssh los cuales están habilitados por defecto. La version 1 del protocolo SSH es vulnerable a un fallo de seguridad donde un atacante puede introducir datos malignos en un enlace seguro, por tanto es recomendado la utilización de protocolo version 2 solamente. Port 22 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress ::
El demonio debería ser configurado para registrar todos los intentos de acceso a traves de syslog, ya sean satisfactorios o no. Estos eventos serán registrados en el archivo /var/log/secure según la configuración por defecto de syslogd. SyslogFacility AUTHPRIV LogLevel INFO
Por defecto, la cuenta de root tiene permitido el acceso por ssh al sistema. Es Red Hat Certified Engineer
140
Secure Shell
altamente recomendable que no permita el acceso root a través de ssh. PermitRootLogin no
La directiva LoginGraceTime determina la cantidad de tiempo en la que una vez conectado un usuario, debe iniciar sesión, de lo contrario es desconectado. Además, es posible configurar veces que es posible introducir la contraseña de forma incorrecta: LoginGraceTime 30s MaxAuthTries 4
Las directivas AllowUsers y AllowGroups especifican que sólo los usuarios o grupos listados pueden iniciar sesión a través de ssh. AllowUsers manager AllowGroups sshusers
La directiva DenyUsers y DenyGroups tienen efecto contrario, los usuarios y grupos listados no pueden iniciar sesión a través de ssh. DenyUsers alice bob DenyGroups sshdeny
SSH puede autenticar a través de contraseñas o claves públicas. Para permitir la autenticación con contraseñas e impedir que contraseñas en blanco sean válidas, configure las siguientes opciones: PasswordAuthentication yes PermitEmptyPasswords no
La directiva AuthorizedKeysFile identifica el nombre del archivo ubicado en el directorio HOME de los usuarios, el cual es utilizado para almacenar la clave pública cuando se conectan a un servidor. AuthorizedKeysFile
.ssh/authorized_keys
Cuando un usuario se conecta al servidor, un mensaje es mostrado antes que intente iniciar sesión en el sistema, esto puede ser utilizado para informar a los usuarios que todos los accesos son registrados y cualquier otro detalle legal. Puede ademas configurar que el mensaje del día (/etc/motd) sea mostrado una vez que ha iniciado sesión satisfactoriamente. Banner /etc/ssh/banner PrintMotd yes
El subsistema sftp (SSH File Transfer Protocol) permite copiar archivos entre la estación de trabajo y los sistemas remotos usando encriptación para mayor seguridad. Subsystem
sftp
/usr/libexec/openssh/sftp-server
Todas las opciones de configuración estan detalladas en la página del manual sshd_config, para visualizarla, ejecute man sshd_config. 141
Ing. Ivan Ferreira
Secure Shell
Control del servicio SSH Una vez configurado el servidor sshd, puede habilitar la ejecución del servicio durante el inicio del sistema utilizando los siguientes comandos: # chkconfig –level 345 sshd on # chkconfig –list
El servicio puede ser iniciado o reiniciado inmediatamente, usando los siguientes comandos: # service sshd start # service sshdd restart
Uso de SSH Para conectarse a un servidor a través de comandos:
ssh,
utilice cualquier de los siguientes
$ ssh usuario@host $ ssh host -l usuario
Si no especifica el nombre de usuario, intentará conectarse al sistema remoto con el mismo usuario que utiliza en el sistema local. La primera vez que inicia sesión en un servidor remoto, usted sera advertido que la identidad del servidor no puedo ser establecida. Si esta seguro de la identidad del host, puede aceptar el certificado presentado. Una copia es guardada en el archivo ~/.ssh/known_hosts. Usted vera un mensaje similar al siguiente: $ ssh
[email protected] The authenticity of host 'galaxy.redhat.com.py (192.168.1.1)' can't be established. RSA key fingerprint is cd:3e:99:ef:5a:e6:6e:40:a4:25:79:a1:50:31:4b:7a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'galaxy.redhat.com.py ' (RSA) to the list of known hosts.
[email protected] 's password:
Una vez autenticado, entrará al prompt del sistema remoto. A partir de ese momento puede ejecutar cualquier comando en el sistema remoto. Puede darse la situación que el par de claves del servidor es reemplazada, esto puede deberse a una reinstalación por ejemplo. Si este es el caso, la clave pública almacenada anteriormente en el archivo ~/.ssh/known_hosts causará un conflicto con la nueva clave pública. Esto provocará que el cliente rechace la conexión, suponiendo que pueda ser un fraude.
Red Hat Certified Engineer
142
Secure Shell # ssh
[email protected] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 8e:ed:e3:45:50:5e:13:33:58:0e:d5:eb:e6:fc:ef:43. Please contact your system administrator. Add correct host key in /home/alice/.ssh/known_hosts to get rid of this message. Offending key in /home/alice/.ssh/known_hosts:14 RSA host key for galaxy.redhat.com.py has changed and you have requested strict checking. Host key verification failed.
El mensaje de advertencia anterior indica que la huella digital de las claves han cambiado. Debe confirmar cualquier cambio que ha ocurrido en el sistema remoto antes de intentar corregir este error. Una vez verificada la identidad del host remoto nuevamente, deberá eliminar la clave pública guardada en el archivo ~/.ssh/known_hosts. Para ello, edite el archivo y elimine la clave pública que corresponde con el host.
Cliente SSH para Windows PuTTY es un cliente Telnet y SSH gratuito escrito y mantenido por Simon Tatham. El cliente y el código fuente pueden ser descargados de: http://www.chiark.greenend.org.uk/~sgtatham/putty
Transferencias de archivos de forma segura El demonio SSH puede ejecutar un subsistema de aplicaciones que pueden tomar venaja del entorno seguro proporcionado por los protocolos criptográficos, uno de estos subsistemas es sftp (Secure File Transfer Protocol). El servidor sftp proporciona al los usuarios la posibilidad de iniciar sesión de tal forma a que puedan transferir archivos de forma confidencial. El servidor sftp no debe ser confundido con FTPS disponible en vsftpd. Si bien ambos sistemas proporcionan la capacidad de encriptar la comunicación, existen diferencias en como pueden ser implementados. Para conectarse a un servidor sftp, utilice el siguiente comando: $ sftp usuario@host
Si no especifica el nombre del usuario, intentará conectarse con el mismo usuario que está usando en el sistema local. 143
Ing. Ivan Ferreira
Secure Shell
Una vez conectado, tiene disponible los comandos mas comunes de transferencias de archivos de FTP, utilice el comando help para obtener la lista de comandos permitidos.
Secure copy El scp s el reemplazo de rcp, y permite la copia de archivos entre el sistema local y remoto de una forma bastante parecida a si estuviera copiando archivos de un directorio a otro dentro del mismo servidor. La aplicación scp permite copia de archivos de forma no interactiva. La sintaxis del comando para copiar un archivo del equipo local al equipo remoto es: $ scp [opciones] archivo [...] [usuario]@host:[/ruta/de/destino]
Por ejemplo: Para copiar el archivo local reporte.txt al sistema galaxy.redhat.com.py en el directorio /tmp iniciando sesión con usuario bob, ejecute: $ scp /tmp/reporte.txt
[email protected]:/tmp
Para copiar todos los archivos .txt de su directorio HOME al sistema remoto, también en su directorio home, iniciando sesión con el mismo usuario utilizado de forma local, ejecute: $ scp $HOME/*.txt
galaxy.redhat.com.py:
La sintaxis del comando para copiar un archivo del equipo local al equipo remoto es: $ scp [opciones] [usuario]@host:[/ruta/al/archivo] /ruta/de/destino
Por ejemplo: Para copiar el archivo remoto /tmp/reporte.txt al directorio local /backup, iniciando sesión como usuario bob en el servidor galaxy.redhat.com.py, ejecute: $ scp
[email protected]:/tmp/reporte.txt /backup $ scp galaxy.redhat.com.py:/tmp/*.txt .
Para copiar de forma recursiva el directorio directorio /backup local, utilice la opción -r:
/reportes
del sistema remoto al
$ scp -r galaxy.redhat.com.py:/reportes/ /backup
Red Hat Certified Engineer
144
12
Network Time Protocol
Network Time Protocol
Network Time Protocol (NTP) NTP (Network Time Protocol) es un protocolo de comunicaciones que permite sincronizar el reloj de un ordenador que este conectado a la red con un servidor central de tiempo. Con ello lograremos una exactitud del orden de milisegundos en una red local. El NTP implementa un modelo jerárquico de sincronización. En la cumbre se encuentran los servidores de tiempo stratum 1, computadoras conectadas en forma directa a dispositivos conocidos como "relojes de referencia" (ó stratum 0), de altísima precisión. Estos dispositivos pueden ser relojes atómicos, receptores Global Positioning Systems (GPS) o receptores de radio. Cualquier servidor que obtenga la referencial de tiempo de un stratum 1 pasa a ser un stratum 2 y así sucesivamente. La sincronización del tiempo es vital para millones de computadoras que intercambian informaciones: personas que comparten bases de datos, que procesan transacciones de diversos tipos, tales como comercio electrónico y personal banking. Es justamente en este ambiente abierto, en el cual se comparten informaciones, que la necesidad de una referencia de tiempo común, exacta y confiable se hace imprescindible
Convenciones generales Hay varios conceptos y acrónimos utilizados cuando se configura un servidor NTP: ●
GMT (Greenwich Mean Time) - Es la hora del meridiano de Greenwich, población cercana a Londres. Se usó esa porque fué la usada por la "Britain's Royal Navy" durante el sigo XIX. El meridiano también pasa por España.
●
UTC (Universal Time Coordenated) - Básicamente lo mismo que la hora GMT, pero ya sincronizado con relojes atómicos. Es estándard y ya no hace referencia a un sitio en concreto.
●
Zulú o Z - En la segunda guerra mundial abreviaban "GMT" por "Z", y según el alfabeto internacional de comunicaciones la Z se pronuncia Zulú
●
CET (Central European Time) - Hora Central Europa, es UTC+1. Donde está España excepto las Canarias.
●
CEST (Central European Summer Time) - Hora central Europea en verano, UTC+2. Donde está España excepto las Canarias.
●
WET (Western European Time) - Hora de Europa del Oeste, donde están
Red Hat Certified Engineer
146
Network Time Protocol
las Canarias. Es la misma que UTC. ●
WEST (Western European Summer Time) - Hora de Europa del Oeste en verano, donde están las Canarias. Es UTC+1
●
DST (Daylight Summer Time) - Así se llama el periodo que estamos en ahorro de luz de verano.
●
PYT (Paraguay Time) - Horario normal de Paraguay.
●
PYST (Paraguay Summer Time) - Horario de verano de Paraguay.
Zonas horarias Las zonas horarias son divisiones geográficas del globo terráqueo de 15° cada una. Iniciando en Greenwich, creadas para ayudar a las personas a saber que hora es en otra parte del mundo. Por razones de ahorro de energía, se utiliza el horario de verano, conocido como Dailyght Savings Time (DST), que son variaciones de la zona horaria. Las zonas horarias generalmente son definidas por el gobierno de un país o un instituto astronómico y es representado por 3 o cuatro letras, por ejemplo PYT o PYST.
Daylight Savings Time Por razones de ahorro de energía, los gobiernos han creado el horario de verano o DST. Los relojes son adelantados una hora y esto hace que los dias parezcan mas largos. Lo que sucede en realidad es tan solo “un cambio en la zona horaria”. El tiempo primitivo (UTC) es y seguirá siendo el mismo.
Los archivos de zona horaria Durante la instalación del sistema operativo Linux, se selecciona la zona horaria. Esta configuración se encuentra almacenada en el archivo /etc/sysconfig/clock. El archivo /etc/localtime es el archivo de zona horaria y es una copia de alguno de los ficheros de zona que se encuentran en el directorio /usr/share/zoneinfo. Estos ficheros son binarios no pueden ser editados directamente. En el fichero de zona se especifica la fecha en la que comienza y termina el horario de verano para una zona dada. Por ejemplo, el fuente de un fichero de zona para 147
Ing. Ivan Ferreira
Network Time Protocol America/Asuncion
es como sigue:
# Paraguay # Rule NAME FROM Rule Para 2003 Rule Para 2004 # Zone NAME Zone America/Asuncion
TO TYPE only only GMTOFF RULES -4:00 Para
IN Oct Mar FORMAT PY%sT
ON AT 16 0:00 31 0:00 [UNTIL]
SAVE 1:00 0
LETTER/S S -
El bloque Rule define la fecha y la hora en la que el horario de verano se aplica, mientras que el bloque Zone hace referencia a regla (Rule) que lo gobierna. Note que el nombre de Zone el el nombre del fichero en el directorio /usr/share/zoneinfo. Para configurar la sincronización de hora a través de NTP, la configuración de la zona horaria debe ser correcta. Como es habitual que en nuestro país, el cambio de hora no se haga en la misma fecha, es necesario modificar el archivo fuente de la zona y especificar la duración del horario de verano. En este caso deberían agregarse dos reglas, para indicar cuando inicia y cuando termina el horario de verano, por ejemplo, modificando el archivo paraguay.zic anterior seria: # Paraguay # Rule NAME FROM Rule Para 2003 Rule Para 2004 Rule Para 2005 Rule Para 2006 # Zone NAME Zone America/Asuncion
TO TYPE only only only only GMTOFF RULES -4:00 Para
IN Oct Mar Oct Mar FORMAT PY%sT
ON AT 16 0:00 31 0:00 18 0:00 31 0:00 [UNTIL]
SAVE 1:00 0 1:00 0
LETTER/S S S -
Una vez modificado el archivo fuente de zona, es necesario compilarlo con el comando zic. Para ello ejecute: # zic paraguay.zic
Luego,
debera /etc/localtime: # cp
copiar
el
archivo
/usr/share/zoneinfo/America/Asuncion
a
/usr/share/zoneinfo/America/Asuncion /etc/localtime
Puede verificar que las configuraciones fueron realizadas con el comando zdump. # zdump -v America/Asuncion
Como mencionamos anteriormente, los servidores NTP siempre proporcionan la información de hora en horario UTC. Es el archivo de zona el que determina la cantidad de horas que se deben sumar o restar al horario UTC y también en que momento inicia el horario de verano. Por lo tanto, una vez llegada la fecha y la hora indicada, no es necesario realizar ninguna operación adicional. No es necesario modificar la hora manualmente.
Red Hat Certified Engineer
148
Network Time Protocol
El proyecto pool.ntp.org El proyecto se nutre de servidores horarios de todo el mundo que se unen de forma voluntaria. El sistema se basa en asignar el mismo nombre a varias máquinas en el DNS (round robin), con lo que cada vez que solicitamos una dirección, recibimos una contestación distinta. Este es un método sencillo pero muy útil para repartir la carga. Esta asignación de direcciones se basa en una jerarquización por situación geográfica, añadiendo cada servidor a la zona DNS correspondiente a su país, a su continente y a la zona mundial que los engloba a todos, bajo el dominio pool.ntp.org. Por ejemplo north-america.pool.ntp.org, south-america.pool.ntp.org, europe.pool.ntp.org, oceania.pool.ntp.org. Si consultamos al DNS la dirección IP de south-america.pool.ntp.org veremos como no obtenemos una respuesta única. # dig south-america.pool.ntp.org ; DiG 9.3.1 south-america.pool.ntp.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER
