Administración de servicios de red con Red Hat/Fedora...

Administración de servicios de red con Red Hat/Fedora Linux

Tabla de contenido

Introducción a TCP/IP..........................................................................................................9Introducció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.............................................................................17Detecció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)...............................................................39Dynamic 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 ............................................................................45Configuració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 ........................................................................................................55Servidor 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) ..............................................................................66Configuració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)..........................................................................73Introducció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 .....................................................................................................95Directivas 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


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.....................................................................................117Postfix............................................................................................................................118


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 .....................................................................................................................139Secure Shell...................................................................................................................140


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....................................................................................................145Convenciones 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...................................................................................................154Diagnóstico y solución de problemas de red y servicios...............................................155


1

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ónPresentación

SesiónAplicación FTP – DNS – SMTP – SSH – WWW

Transporte Transporte TCP – UDPRed Internet IP – ARP – ICMP - IGMP

EnlaceFí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.



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 24 31Clase A 0 Redes HostsClase B 10 Redes HostsClase C 110 Redes HostsClase D 1110 MulticastClase E 1111 Resevado

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.



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 Número de Redes

Número de Hosts

Rango de direcciones

Máscara por defecto

A r.h.h.h128 16777214

0.0.0.0-127.0.0.0

255.0.0.0

B r.r.h.h16384 65534

128.0.0.0-191.255.0.0

255.255.0.0

C r.r.r.h2097152 254

192.0.0.0-223.255.255.0

255.255.255.0



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.



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



distintos mensajes de control.

Campo de tipo Tipo de mensaje ICMP0 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.



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.


2

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:



# 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/network-scripts. 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:

● /etc/hosts 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/resolv.conf 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.

● /etc/sysconfig/network Especifica la información del routing y del host para todas las interfaces de red.

● /etc/sysconfig/network-scripts/ifcfg-<interface-name> Para cada interfaz de



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-<device>, donde <device> 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=eth0BOOTPROTO=noneONBOOT=yesNETWORK=10.0.1.0NETMASK=255.255.255.0IPADDR=10.0.1.27USERCTL=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=eth0BOOTPROTO=dhcpONBOOT=yes

La mayoría del tiempo, deseará utilizar una utilidad GUI, como por ejemplo redhat-config-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.



Dentro de cada uno de los ficheros de configuración de la interfaz, son comunes los siguientes valores:

● BOOTPROTO=<protocol>, donde <protocol> es uno de los siguientes:

○ none No se debería utilizar ningún protocolo de tiempo de arranque.

○ bootp Se debería utilizar el protocolo BOOTP.

○ dhcp Se debería utilizar el protocolo DHCP.

● BROADCAST=<address>, donde <address> es la dirección de broadcast.

● DEVICE=<name>, donde <name> 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).

● DNS{1,2}=<address>, donde <address> es la dirección del servidor de nombres que se tiene que colocar en /etc/resolv.conf si la directiva PEERDNS está activada.

● IPADDR=<address>, donde <address> es la dirección IP.

● NETMASK=<mask>, donde <mask> es el valor de la máscara de red.

● NETWORK=<address>, donde <address> es la dirección de red. Esta opción ya no se usa.

● ONBOOT=<answer>, donde <answer> es uno de los siguientes:

○ yes dispositivo debería activarse en el momento de arranque.

○ no Este dispositivo no debería activarse en el momento de arranque.

● PEERDNS=<answer>, donde <answer> es uno de las siguientes:

○ yes Modificar /etc/resolv.conf si la directiva DNS está activada. Si está usando DCHP, la opción sí es la predeterminada.

○ 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.



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=ppp0NAME=testWVDIALSECT=testMODEMPORT=/dev/modemLINESPEED=115200PAPNAME=testUSERCTL=trueONBOOT=noPERSIST=noDEFROUTE=yesPEERDNS=yesDEMAND=noIDLETIMEOUT=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-<if-name>:<alias-value>: 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.



Un fichero de configuración de clon tiene un nombre parecido a ifcfg-<if-name>-<clone-name>. 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=eth0ONBOOT=yesBOOTPROTO=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



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:

● ifup-aliases 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.

● ifdown-ipv6 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.

● ifup-ipx Se usa para configurar una interfaz IPX.

● ifup-plip Se usa para configurar una interfaz PLIP.

● ifup-plusb Se usa para configurar una interfaz USB para conexiones de red.

● ifdown-post e ifup-post Contiene comandos que se ejecutan después de que una interfaz particular haya sido activada o desactivada.

● ifdown-ppp e ifup-ppp Se usa para activar o desactivar una interfaz PPP mediante el uso de un dispositivo en particular.

● ifup-routes Añade rutas estáticas para un dispositivo en particular como si se activase su interfaz.

● ifdown-sl y ifup-sl 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



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 localhost192.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=yesHOSTNAME=su_maquina.su_dominio.com

El nombre de host es retornado por el comando hostname. El valor retornado debe coincidir la entrada del archivo /etc/hosts.

Dirección IP, máscara de sub-red y puerta de enlace

Debe editarse con un procesador de textos /etc/sysconfig/network-scripts/ifcfg-eth<numero> 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=eth0ONBOOT=yesBOOTPROTO=staticIPADDR=192.168.1.50NETMASK=255.255.255.0GATEWAY=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.pynameserver 192.168.1.254



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:

<destino> via <nombre>

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.1192.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á añadir en /etc/sysconfig/network el parámetro NOZEROCONF con el valor yes:



NETWORKING=yesHOSTNAME=host.dominioNOZEROCONF=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 mii-tool o ethtool para poder utilizar el comando.

Para consultar el estado de un adaptador de red, utilice el siguiente comando:

# ethtool <nombre de interface>

Por ejemplo:

# ethtool eth0Settings for eth0:Supported ports: [ MII ]Supported link modes: 10baseT/Half 10baseT/Full



100baseT/Half 100baseT/Full1000baseT/Half 1000baseT/FullSupports auto-negotiation: YesAdvertised link modes: 10baseT/Half 10baseT/Full100baseT/Half 100baseT/Full1000baseT/Half 1000baseT/FullAdvertised auto-negotiation: YesSpeed: 1000Mb/sDuplex: FullPort: Twisted PairPHYAD: 1Transceiver: internalAuto-negotiation: onSupports Wake-on: gWake-on: dCurrent 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 /etc/sysconfig/network-scripts/ifcfg-ethX y agregue la siguiente línea:

ETHTOOL_OPTS="speed 100 duplex full autoneg off"


3

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 UTF-8, 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:



● rpc.mountd: 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.nfsd: 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.

● rpc.lockd: 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.

● rpc.statd: 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.

● rpc.rquotad: 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.



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:


-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.



Si no se pasan opciones al comando exportfs, mostrará una lista de los sistemas de archivos actualmente exportados.

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:


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




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=<valor>,anongid=<valor>, donde <uid-valor> es el número ID de usuario y <gid-valor> 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.



● 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 @<nombre-grupo>, 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:

<servidor>:</recurso/exportado> </punto_montaje_local> nfs <opciones> 0 0

La opción <servidor> 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



archivos.

La opción </recurso/exportado> es la ruta al directorio exportado.

La opción </punto_montaje_local> 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 <opciones> 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:

● hard o soft - 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).

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=<value>, donde <value> especifica el número de segundos que deben pasar antes de informar del error.

● intr - Permite a las peticiones NFS ser interrumpidas si el servidor se cae o no puede ser accedido.

● nolock - Es requerido a veces cuando conectamos a servidores NFS antiguos. Para requerir el bloqueo, use la opción lock.

● noexec - 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.



● nosuid - No permite que los bits SUID o SGID tomen efecto.

● rsize=8192 y wsize=8192 - 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.

● nfsvers=2 o nfsvers=3 - 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 mount, incluyendo opciones para montar sistemas de archivos que no sean NFS.

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



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.


4

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



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-<número-versión>/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;}



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 host-name para asignar un nombre host al cliente.

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



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 start. Para detener el servidor DHCP, use el comando /sbin/service dhcpd stop.

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 hereDHCPDARGS=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:

● La directiva INTERFACES indica en que interfaces se escucharán solicitudes DHCP.

● La directiva DHCPSERVERS especifica la lista de servidores DHCP a los cuales se reenviarán las solicitudes.



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


5

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 SAMBALa 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:



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 = yesprinting = cupscups 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:

● security = share - 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 = user - 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.

● security = domain - 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.



● security = ADS - 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 = 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 -a <usuario>

● Deshabilitar usuario - smbpasswd -d <usuario>

● Habilitar usuario - smbpasswd -e <usuario>

● Eliminar usuario - smbpasswd -x <usuario>

● Establecer la contraseña a nulo - smbpasswd -n <usuario>

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



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 = yeslocal master = yespreferred 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 = nolocal 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]



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



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 <usuario># /usr/bin/smbpasswd -a <usuario> 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 <usuario># /usr/bin/smbpasswd -a <usuario> 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



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 <usuario> -L //<host>

Por ejemplo:

# smbclient -U <usuario> -L //<host>

Lo cual le devolvería más menos lo siguiente: added interface ip=192.168.1.254 bcast=192.168.1.255 nmask=255.255.255.0 added interface ip=192.168.200.254 bcast=192.168.200.255 nmask=255.255.255.0 Anonymous login successful Domain=[REDHAT] OS=[Windows] Sharename Type Comment --------- ----- ------- publico Disk Directorio Publico HPDeskjet Printer Workgroup Master --------- ------- REDHAT Serv1 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:



# 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=<usuario>,password=<contraseña> //host/recurso /punto/de/montaje/

# mount -t cifs -o username=<usuario>,password=<contraseña> //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



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 //Serv1/Aplicaciones -o username=rhuser1,password=<contraseña> /mnt/aplicaciones


6

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



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 3128http_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:3128http_port 192.168.1.254:8080

Parámetro cache_mem



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:



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



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.1192.168.1.2192.168.1.3192.168.1.15192.168.1.16192.168.1.20192.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



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-onlycache_peer 10.2.0.1 sibbling 8080 3130 proxy-onlycache_peer 10.3.0.1 sibbling 8080 3130 proxy-only

Pueden hacerse combinaciones que de manera tal que se podrían tener caches



padres y hermanos trabajando en conjunto en una red local. Ejemplo:

cache_peer 10.0.0.1 parent 8080 3130 proxy-onlycache_peer 10.1.0.1 sibbling 8080 3130 proxy-onlycache_peer 10.2.0.1 sibbling 8080 3130 proxy-onlycache_peer 10.3.0.1 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.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl 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 localhosthttp_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



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.1192.168.1.2192.168.1.3192.168.1.15192.168.1.16192.168.1.20192.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.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl 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 localhosthttp_access allow permitidoshttp_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:



# Debe especificarse la IP de cualquier servidor Web en la red local# o bien el valor virtualhttpd_accel_host virtualhttpd_accel_port 80httpd_accel_with_proxy onhttpd_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:



# 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.


7

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, banner_file es desplegado antes que ftpd_banner.

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 vsftpd puede ejecutarse en modo independiente o a través de inetd/xinetd. Para habilitar el modo independiente, configure el parámetro listen.



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=077local_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=YESxferlog_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



# 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=NOanon_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=10485760local_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=500max_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.



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 especifica el archivo a ser leido cuando la opción userlist_enable está activa.

userlist_enable=YESuserlist_file=/etc/vsftpd/user_listuserlist_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=YESwrite_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=YESchroot_list_enable=YESchroot_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



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 libssl como resultado, entonces la versión soporta TLS/SSL.

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



# 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=NOssl_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”.


8

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.



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:

● 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



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 El archivo de configuración para el demonio named.

● /var/named/ El directorio de trabajo named el cual almacena zonas, estadísticas y archivos caché.

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 named en entorno enjaulado es controlado por el archivo /etc/sysconfig/named. El archivo por defecto está configurado para ejecutarse en



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 named.conf está organizado de forma similar al ejemplo siguiente:

<declaracion> { <opcion-1> {valor; [valor]...}; <opcion-1> {valor; [valor]...}; <opcion-1> {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.



Una declaración acl tiene la siguiente forma:

acl <nombre-acl> { <elemento-de-concordancia>; [ <elemento-de-concordancia>; ...]};

En esta declaración, sustituya <nombre-acl> con el nombre de la lista de control de acceso y reemplace <elemento-de-concordancia> 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:

● any - Hace coincidir todas las direcciones IP.

● localhost - Hace coincidir cualquier dirección IP que se use el sistema local.

● localnets - Hace coincidir cualquier dirección IP en cualquier red en la que el sistema local está conectado.

● none - 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.



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 "<nombre-archivo>"

En esta declaración, <nombre-archivo> es reemplazado con una ruta absoluta a un archivo.

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 { <opcion>;

[<opcion>; ...]};

En esta declaración, las directivas <opcion> son reemplazadas con una opción válida.

Las siguientes son opciones usadas a menudo:

● allow-query - 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-recursion - 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.

● blackhole - Especifica cuáles hosts no tienen permitido consultar al servidor de nombres.

● directory - Reemplaza el directorio de trabajo named en vez del directorio predeterminado /var/named.



● forward - Controla el comportamiento de reenvío de una directiva forwarders. Se aceptan las siguientes opciones:

– first - Indica que los servidores de nombres especificados en la directiva forwarders sean consultados antes de que named intente resolver el nombre el mismo.

– 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.

● forwarders Especifica una lista de direcciones IP válidas para los servidores de nombres donde las peticiones se pueden reenviar para ser resueltas.

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;};

● listen-on Especifica la interfaz de red en la cual named escucha por solicitudes. Por defecto, todas las interfaces son usadas.

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.

● 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 - Sólo notifica a los servidores esclavos en una lista also-notify

dentro de una declaración de zona.



● pid-file Especifica la ubicación del archivo del proceso ID creado por named.

● 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 ); ]



[ 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, <zone-name> es el nombre de la zona, <zone-class> es la clase opcional de la zona, y <zone-options> es una lista de opciones que caracterizan la zona.

El atributo <zone-name> 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 <zone-name> 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 named que 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.



● 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



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, el tipo es configurado a master y el servicio named se instruye para leer el archivo /var/named/chroot/var/named/redhat.com.py.zone (Si se ha habilitado el entorno enjaulado). También le dice a named que no permita a ningún otro host que realice actualizaciones.

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 zone para un servidor esclavo para redhat.com.py sería como sigue:

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; };

};



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.

● controls Configura varios requerimientos de seguridad necesarios para usar el comando rndc para administrar el servicio named.

● key "<key-name>" 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 <algorithm-name> El tipo de algoritma usado, tal como dsa o hmac-md5.

– secret "<key-value>" La clave encriptada.

● logging 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.

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



(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:

● $INCLUDE - 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.

● $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.



● $TTL - 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.

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 SOA es el primer registro en un archivo de zona.

El ejemplo siguiente muestra la estructura básica de un registro SOA:

@ IN SOA <primary-name-server> <hostmaster-email> ( <serial-number> <time-to-refresh> <time-to-retry> <time-to-expire> <minimum-TTL> )

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 <primary-name-server>, y el correo electrónico de la persona a contactar sobre este espacio de nombres es sustituído por el <hostmaster-email>.

El <serial-number> 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 <time-to-refresh> 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



valor <serial-number> es usado por el esclavo para determinar si esta usando datos de la zona desactualizados y si debería refrescarlos.

El valor <time-to-retry> 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 <time-to-expire>, el servidor esclavo para de responder como una autoridad por peticiones al espacio de nombres.

La opción <minimum-TTL> 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 <nameserver-name> El <nameserver-name> 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 NS dns1.redhat.com.py. IN NS dns2.redhat.com.py.



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:

<host> IN A <IP-address>

Si el valor <host> 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:

IN A 10.0.1.3server1 IN A 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 <alias-name> apuntará al host, <real-name>. Los registros CNAME son usados normalmente para apuntar a servicios que usan un esquema de nombres común, tal como www para servidores Web.

<alias-name> IN CNAME <real-name> 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 IN A 10.0.1.5www IN CNAME 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 <preference-value> <email-server-name> En este ejemplo, <preference-value> permite una clasificación numérica de los servidores de correo para un espacio de nombres, dando preferencia a algunos



sistemas de correo sobre otros. El registro de recursos MX con el valor más bajo <preference-value> 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 <email-server-name> puede ser un nombre de servidor o FQDN.

IN MX 10 mail.redhat.com.py. IN MX 20 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 MX 10 mail.redhat.com.py. IN MX 20 mail2.redhat.com.py.

IN A 10.0.1.5

server1 IN A 10.0.1.5server2 IN A 10.0.1.7dns1 IN A 10.0.1.2dns2 IN A 10.0.1.3

ftp IN CNAME server1mail IN CNAME server1mail2 IN CNAME server2



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:

<ultimo-digito-ip> IN PTR <FQDN-of-system> El valor <ultimo-digito-ip> 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 IN PTR alice.redhat.com.py.21 IN PTR betty.redhat.com.py.22 IN PTR charlie.redhat.com.py.23 IN PTR doug.redhat.com.py.24 IN PTR ernest.redhat.com.py.25 IN PTR fanny.redhat.com.py.



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 rndc conectarse desde un host local.

controls { inet 127.0.0.1 allow { localhost; } keys { <key-name>; };}; 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 <key-name> 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 "<key-name>" { algorithm hmac-md5; secret "<key-value>";



};

En este caso, el <key-value> es una clave HMAC-MD5. Use el comando siguiente para generar claves HMAC-MD5:

# dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name> Una clave con al menos un largo de 256-bit es una buena idea. La clave actual debería ser colocada en el área <key-value> se puede encontrar en <key-file-name>.

Configuración de /etc/rndc.conf

La declaración key es la más importante en /etc/rndc.conf.

key "<key-name>" { algorithm hmac-md5; secret "<key-value>";}; <key-name> y <key-value> 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 localhost; default-key "<key-name>";}; 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 "<key-name>";};

Opciones de línea de comandos de rndc

Un comando rndc toma la forma siguiente:

rndc <options> <command> <command-options> Cuando esté ejecutando rndc en una máquina local configurada de la forma correcta, los comandos siguientes están disponibles:



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 las estadísticas actuales de named al archivo /var/named/named.stats.

stop Detiene al servidor salvando todas las actualizaciones dinámicas y los datos de las Transferencias de zona incremental (IXFR) antes de salir.

Ocasionalmente, puede ser necesario ignorar las configuraciones por defecto en el archivo /etc/rndc.conf. Estan disponibles las siguientes opciones:


-c <archivo> Le dice a rndc que use un archivo de configuración diferente a /etc/rndc.conf.

-p <puerto> Especifica la utilización de un número de puerto diferente del predeterminado 953 para la conexión del comando rndc.

-s <servidor> Dice a rndc que envie el comando a un servidor distinto al default-server especificado en su archivo de configuración.

-y <clave> Le permite especificar una clave distinta de la opción default-key en el archivo /etc/rndc.conf.

Se puede encontrar información adicional sobre estas opciones en la página del manual de rndc.


9

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 es /etc/httpd/conf/httpd.conf. El archivo httpd.conf está bien comentado y es bastante autoexplicativo. Su configuración por defecto funciona para la mayoría de los casos; sin embargo, quizás quiera conocer el resto de las opciones de configuración más importantes.

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



entradas deberían de ayudarle a saber lo que ha pasado.

Puede utilizar el comando httpd -t para verificar que esté correcta la sintáxis del archivo de configuración.

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

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.

Directiva Timeout

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

Directiva KeepAlive

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.

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



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

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.

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 identifica los puertos en los que el servidor Web aceptará las



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

Include permite que se incluyan otros archivos de configuración en el tiempo de ejecución.

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.



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

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:

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

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.

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.



Directiva AccessFileName

AccessFileName denomina el archivo que el servidor utilizará para información de control de acceso en cada directorio. Por defecto, el servidor utilizará .htaccess.

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

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.

Para ahorrar recursos en el servidor, HostnameLookups es configurado a off por defecto.

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

ErrorLog especifica el archivo donde se guardan los errores del servidor . Por defecto, esta directiva es configurada a /var/log/httpd/error_log.

Directiva LogLevel

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.

Directiva ServerSignature

La directiva ServerSignature añade una línea que contiene la versión del Servidor



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 /<old-path> http://<current-domain>/<current-path> 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 el URL http://www.redhat.com.py/webform, creamos el siguiente Alias:

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



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 <Directory /path/to/directory> y </Directory> 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 /web/applications, añada el contenedor siguiente Directory al archivo httpd.conf:

<Directory /web/applications> Options +ExecCGI</Directory> Para que esto funcione, los permisos para los scripts CGI y la ruta completa a los scripts, se deben colocar a 0755.



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:

● ExecCGI - 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.

● FollowSymLinks - Permite que se sigan enlaces simbólicos.

● Includes - Permite las inclusiones en el servidor. Esto permite la generación de contenido dinámico como fecha y hora actual, etc.

● IncludesNOEXEC - Permite las inclusiones en el servidor pero anula los comandos #exec y #include en los scripts CGI. Esto es mucho más seguro.

● Indexes - 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.

● Multiviews - 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.

● SymLinksIfOwnerMatch - 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.



Directiva Order

La directiva Order controla el orden en el cual las directivas allow y deny son evaluadas.

● Order Deny,Allow: 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.

● Order Allow,Deny: 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.

● Order mutual-failure: 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 <Directory "/web/forms"> Options Multiviews

AllowOverride NoneOrder deny,allowDeny from allAllow from 127.0.0.1 redhat.com.py 192.168

</Directory>

# 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.<Directory "/web/applications"> Options ExcecCGI

AllowOverride NoneOrder allow,denyAllow from 127.0.0.1 redhat.com.py 192.168

</Directory>

# Un directorio el cual permitimos acceso acceso a todos y genera un indice HTML# de su contenido<Directory "/web/downloads"> Options Indexes

AllowOverride NoneOrder allow,denyAllow from all

</Directory>

Directiva UserDir



UserDir 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.

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 restart es un truco para detener y luego arrancar el Servidor Apache HTTP.

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



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 <VirtualHost> y </VirtualHost> crean un contenedor mostrando las características de un host virtual. El contenedor <VirtualHost> 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 *##<VirtualHost *># 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#</VirtualHost>

Para activar máquinas virtuales basadas en nombre, quite los comentarios de la línea NameVirtualHost eliminando el símbolo de numeral o almohadilla (#).



Luego, configure un host virtual, quitando los comentarios y personalizando el contenedor <VirtualHost>.

En la línea <VirtualHost>, cambie el ServerName al nombre DNS válido asignado a la máquina y configure las otras directivas si es necesario.

El contenedor <VirtualHost> 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 <VirtualHost>. 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 *

<VirtualHost *> 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</VirtualHost>

<VirtualHost *> 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</VirtualHost>

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 <VirtualHost>. Por ejemplo, si desea puede agregar lo siguiente a la directiva <VirtualHost> 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.



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:

<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user</Location>

Observe que la directiva AuthDBMUserFile también puede ser usada en archivos .htaccess.

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.



Vista preliminar de los paquetes relacionados con la seguridad

Para activar el servidor seguro, necesita, como mínimo, tener instalados los siguientes tres paquetes:

● httpd 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.

● mod_ssl 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.

● openssl 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á



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.keyGenerating RSA private key, 1024 bit long modulus.......++++++................................................................++++++e is 65537 (0x10001)Enter PEM pass phrase:



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.keyGenerating 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.



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 incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or aDN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [GB]:PYState or Province Name (full name) [Berkshire]:AsuncionLocality Name (eg, city) [Newbury]:AsuncionOrganization Name (eg, company) [My Company Ltd]:Red Hat ParaguayOrganizational Unit Name (eg, section) []:SistemasCommon Name (your name or server's hostname) []:www.redhat.com.pyEmail Address []:[email protected] enter the following 'extra' attributesto be sent with your certificate requestA 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



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 GB. Para aceptarla, pulse [Intro], o relléne con el código de dos letras de su país.

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.



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 incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or aDN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [GB]:PYState or Province Name (full name) [Berkshire]:AsuncionLocality Name (eg, city) [Newbury]:AsuncionOrganization Name (eg, company) [My Company Ltd]: Red Hat ParaguayOrganizational Unit Name (eg, section) []: SistemasCommon Name (your name or server's hostname) []:www.redhat.com.pyEmail 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



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 OnRewriteCond %{HTTPS} !=onRewriteRule ^/webmail/(.*) https://%{SERVER_NAME}/webmail/$1 [R,L]

#Debug Rewrite Rules#RewriteLog /var/log/httpd/rewrite_engine_log#RewriteLogLevel 3


10

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



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 usuariosque 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 basede datos:

● 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).



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 mtamta - 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:

● master.cf - 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.

● main.cf - El fichero donde se define gran parte del funcionamiento de Postfix es main.cf.



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 = <Nombre de Internet de este host>

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 = <Dominio de Internet de este sistema de correo>

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 = <Dominio de Internet>

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 = <Interfaces de red habilitadas para recibir correo>

Ej:

inet_interfaces = all

Especifique los dominios de Internet que este sistema de correo atiende.

mydestination = <Dominio de Internet>



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/sbindaemon_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



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 canonical y recargue postfix para que reconozca los cambios en mail.cf:

# 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



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 owner-<alias>@dominio.com, 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:



/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:

● Listar mensajes

● Borrar mensajes



● 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 DBA3F1A9postsuper: DBA3F1A9: removedpostsuper: Deleted: 1 message

Si desea eliminar todos los mensajes de la cola ejecute el comando:

# postsuper -d ALLpostsuper: 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]



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



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.



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 transport_maps apunta a su tabla de búsqueda de transporte:

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 mynetworks incluye la dirección IP del servidor de correo interno.



1. En el servidor mail.redhat.com.py, configure el parámetro mynetworks para asegurarse que incluye todos los clientes del sistema.

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 relayhost para apuntar a gateway.redhat.com.py:

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] son convertidas a [email protected].

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



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.



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 correolocalhostlocalhost.localdomainredhat.com.pymail.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.



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.pyredhat.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 particular172.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:

● OK Acepta el correo inclusive si otras reglas lo rechazarían, por ejemplo nombre de dominio no puede ser resuelto.

● RELAY Acepta el correo dirigido al dominio indicado o recibido del dominio indicado por el servidor SMTP.

● REJECT Rechazar el correo con un mensaje de error genérico.

● DISCARD Descartar el mensaje utilizando la propiedad $#discard del sistema de correo.

● TEXTO DE ERROR 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<TMPF> -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 RELAYlocalhost RELAY127.0.0.1 RELAY

# Debemos añadir solo las direcciones IP# que ahora tenga el servidor192.168.1.1 RELAY148.243.59.1 RELAY

# Permitimos uso del dominio local



redhat.com.py RELAY

# Agregue también las direcciones IP que integran su red local.192.168.1 RELAY192.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 spammersspam@algun_spamer.com REJECTinfo@otro_spammer.com REJECTservidor.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



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 indispensableMAILER-DAEMON: postmaster # línea indispensable### demuestra los tipos más comunes de alias#usenet: janet # alias para una personaadmin: joe,janet # alias para varias personasnewspak-users: :include:/usr/lib/lists/newspak # lee a los destinatarios desde un ficherochangefeed: |/usr/local/lib/gup # alias que invoca a un programacomplaints: /var/log/complaints # alias que escribe el correo a un fichero#

Cada vez que actualice el fichero /etc/aliases, se debe asegurar de ejecutar el programa:

# /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



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



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 dovecot y habilite para su ejecución durante el arranque del sistema:

# 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:



/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 = 'redhat.com.py';$imapServerAddress = 'localhost';$imapPort = 143;$useSendmail = true;$smtpServerAddress = 'localhost';$smtpPort = 25;$sendmail_path = '/usr/sbin/sendmail';$pop_before_smtp = false;$imap_server_type = '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 = 2Mpost_max_size = 2M


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 22Protocol 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 AUTHPRIVLogLevel INFO

Por defecto, la cuenta de root tiene permitido el acceso por ssh al sistema. Es


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 30sMaxAuthTries 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 managerAllowGroups 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 bobDenyGroups 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 yesPermitEmptyPasswords 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/bannerPrintMotd 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.


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 ssh, utilice cualquier de los siguientes comandos:

$ 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)? yesWarning: Permanently added 'galaxy.redhat.com.py ' (RSA) to the list of known [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.


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 is8e: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:14RSA 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.


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 /reportes del sistema remoto al directorio /backup local, utilice la opción -r:

$ scp -r galaxy.redhat.com.py:/reportes/ /backup


12

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



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



America/Asuncion es como sigue:

# Paraguay# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/SRule Para 2003 only - Oct 16 0:00 1:00 SRule Para 2004 only - Mar 31 0:00 0 -# Zone NAME GMTOFF RULES FORMAT [UNTIL]Zone America/Asuncion -4:00 Para PY%sT

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 TO TYPE IN ON AT SAVE LETTER/SRule Para 2003 only - Oct 16 0:00 1:00 SRule Para 2004 only - Mar 31 0:00 0 -Rule Para 2005 only - Oct 18 0:00 1:00 SRule Para 2006 only - Mar 31 0:00 0 -# Zone NAME GMTOFF RULES FORMAT [UNTIL]Zone America/Asuncion -4:00 Para PY%sT

Una vez modificado el archivo fuente de zona, es necesario compilarlo con el comando zic. Para ello ejecute:

# zic paraguay.zic

Luego, debera copiar el archivo /usr/share/zoneinfo/America/Asuncion a /etc/localtime:

# cp /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.



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<<- opcode: QUERY, status: NOERROR, id: 31674 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;south-america.pool.ntp.org. IN A ;; ANSWER SECTION: ;; ANSWER SECTION: south-america.pool.ntp.org. 1420 IN A 200.141.215.162 south-america.pool.ntp.org. 1420 IN A 200.141.215.164 south-america.pool.ntp.org. 1420 IN A 200.144.121.33 south-america.pool.ntp.org. 1420 IN A 200.218.160.160 south-america.pool.ntp.org. 1420 IN A 200.89.74.17

De forma periódica, se comprueba el estado y fiabilidad de los servidores implicados (recordemos que se trata de voluntarios sin ninguna garantía de operatividad). Para ello, las zonas DNS se actualizan aproximadamente cada hora a partir de los datos de servidores que velan por el correcto funcionamiento de todos los servidores monitoreando su estado mediante las herramientas que NTP proporciona. De esta forma, aquellos servidores que quedan desconectados o, sencillamente, no ofrecen una hora razonablemente buena, son eliminados temporalmente.

El sistema se basa en la asignación de una puntuación entre dos extremos: si un servidor está funcionando bien, se le suman puntos, si no, se le restan. Cuando alguno de ellos tiene una puntuación por debajo del umbral establecido, se retira del DNS y se sigue vigilando para una futura reincorporación.



El método hace que las puntuaciones bajen muy deprisa en caso de mal funcionamiento, pero tarden un poco más en subir, asegurando así que no existen servidores malos en el sistema.

Configuración de NTP

La configuración de NTP se realiza a través del archivo /etc/ntp.conf.

En el archivo de configuración, existe una regla por defecto que aplica cierta seguridad a la configuración NTP.

restrict default nomodify notrap noquery

Esta regla permite la sincronización con los servidores NTP, pero no permite que los servidores NTP consulten o modifiquen el servicio en nuestro sistema.

En la sección OUR TIMESERVERS debemos configurar los servidores NTP.

# --- OUR TIMESERVERS ----- server south-america.pool.ntp.org server south-america.pool.ntp.org server south-america.pool.ntp.org

Lo más interesante del fichero de configuración son las lineas que nos indican qué servidores vamos a usar para sincronizarnos. Como se puede notar, todas ellas son iguales, aprovechando la resolución DNS que hemos explicado más arriba. De esta forma, obtenemos tres servidores distintos con los que actuar.

Si desea utilizar otros servidores NTP puede consultar la lista de servidores NTP publicos en http://www.eecis.udel.edu/~mills/ntp/servers.html.

driftfile /var/lib/ntp/drift

La opción driftfile especifica qué fichero se utiliza para almacenar el desplazamiento de la frecuencia de reloj de la máquina. El servicio “ntpd” utiliza este valor para automáticamente compensar el desvío que experimenta de forma natural el reloj de la máquina, permitiendo mantener una precisión acotada incluso cuando se pierde la comunicación con el resto de referencias externas.

Inicio del servicio NTP

Antes de iniciar el demonio ntpd, ejecute el comando ntpdate para sincronizar el reloj con el servidor de horario. NTP no sincronizará su reloj con un servidor de horario si la hora local esta significativamente desfasada a la del servidor NTP.

# ntpdate -u south-america.pool.ntp.org

Como una alternativa, puede agregar los servidor NTP al archivo /etc/ntp/step-



tickers. De esta forma usted no necesita sincronizar manualmente el reloj, ntp consultará estos servidores si la hora esta muy desfasada con respecto a la hora NTP durante el inicio del servicio.

Configure el servicio para iniciar automáticamente al siguiente reinicio:

# chkconfig ntpd on

Inicie el servicio inmediatamente ejecutando el comando:

# service ntpd start

Es posible utilizar la herramienta system-config-date para administrar NTP.

Verificación de NTP

El comando ntpq es util para consultar servidores NTP remotos y verificar la configuración y operación del servicio.

Utilice el comando ntpq siempre que necesite:

● Verificar que ntpd puede formar asociaciones con otros hosts NTP

● La sincronización esta funcionado correctamente

Luego que ha iniciado el servidor ntpd ejecute el comando ntpq con la opción -p:

# ntpq -p

El resultado del comando sera algo similar al siguiente:

# ntpq -pn

remote refid st t when poll reach delay offset jitter==============================================================================-80.34.215.206 213.144.140.154 3 u 143 256 377 126.321 24.212 0.798+130.206.130.95 129.132.2.21 2 u 74 256 377 68.792 -8.019 2.836*217.127.249.18 193.79.237.14 2 u 88 256 377 110.388 -6.299 1.346 80.38.245.22 130.206.3.166 2 u 74 256 377 942.683 -397.04 399.034+193.45.254.143 212.94.162.1 3 u 80 256 375 87.577 -2.074 100.146

Cada columna mostrada se describe como sigue:

● remote: La columna remote lista los hosts especificados en el archivo de configuracion local. Los hosts pueden estar precedidos con los siguientes caracteres especiales:

* Indica que es la fuente actual de sincronización.

# Indica que el host ha sido seleccionado para sincronización, pero la distancia desde el host al servidor ha excedido el maximo valor.



o Indica que el host es seleccionado para sincronización y la señal PPS esta en uso.

+ Indica que el host ha sido includo en el conjunto de selección final.

x Indica que el host es designado como “false ticker” por el algoritmo de sincronización

. Indica que el host es seleccionado del final de la lista de candidatos.

- Indica que el host ha sido descartado por el algoritmo de clustering.

Vacío o en blanco Indica que el host ha sido descartado debido a un alto stratum o fallo las verificaciónes de sanidad.

● refid: La columna indicador de referencia indica la actual fuente de sincronización para el host remoto. WWVB indica que el host utiliza un radio reloj.

● st: La columna stratum indica que nivel de stratum para el host remoto.

● t: La columna tipo denota los tipos disponibles que incluyen:

l = local (como un relog GPS)

u = unicast

m = multicast

b = broadcast

- = netaddr (normalmente 0)

● when: La columna when indica la cantidad de segundos desde que la respuesta del host remoto fue recibida.

● poll: El periodo de poll indica el intervalo de consulta al host remoto.

● reach: La columna reach indica que tan exitosos son los intentos de alcanzar un servidor. El valor 001 indica que la prueba mas reciente fue contestada, mientras 357 indica que una respuesta no fue contestada. El valor 377 indica que todas las pruebas recientes fueron contestadas.

● delay: La columna delay indica el tiempo (en milisegundos) que toma en retornar el paquete de respuesta a una consulta.

● offset: La columna offset indica la diferencia de tiempo (en milisegundos)



entre el reloj del servidor y el reloj des cliente. Cuando este numero excede 128, el mensaje de “synchronization lost” aparece en el archivo de registro.

● disp: La columna dispersión indica la diferencia en la medida del offset entre dos muestras. Este es un estimativo de error. La dispersión es un valor para medir la calidad del servicio de red.

Aquí vemos cómo tomamos como referencia el tercero de los servidores (*), siendo el segundo y el quinto (+) alternativas a tener en cuenta que entran en el cálculo de la hora, descartando momentáneamente los demás.

Con ntptrace conoceremos cuál es el origen de nuestra hora:

# ntptrace -n127.0.0.1: stratum 3, offset 0.000038, synch distance 0.18706217.127.249.18: stratum 2, offset -0.006845, synch distance 0.09442193.79.237.14: stratum 1, offset -0.006269, synch distance 0.00000, refid 'GPS'

Nuestra máquina (127.0.0.1) toma la hora de 217.127.249.18, que está sincronizado con 193.79.237.14, que tiene por referencia un receptor GPS. En este caso, nuestro ordenador se ha convertido en un servidor NTP de stratum 3.

Si dejamos que ntpd funcione durante más tiempo haciendo su trabajo mejoraremos mucho la precisión.


13

Solución de problemas



Diagnóstico y solución de problemas de red y servicios

Existen diversas clases de problemas con los que se puede encontrar al trabajar con configuración de dispositivos y servicios de red. Estas son algunas recomendaciones a tener en cuenta para diagnosticar problemas de red:

Problema Acción a tomar

El comando ifconfig no despliega otro adaptador de red más que el adaptador loopback.

Verifique que el servicio network está habilitado para ese nivel de ejecución.Verifique la configuración NETWORKING en /etc/sysconfig/network

Verifique que los módulos han sido cargados para su adaptador de red, revise el archivo /etc/modules.conf

No es posible conectarse a la red. No responde ningún host al comando ping.

Compruebe que el adaptador está recibiendo paquetes con el comando ifconfig. Si no, puede ser un problema con el cable de red, el switch o el adaptador de red.Verifique la configuración de la dirección IP y la máscara de sub red.Detenga los servicios de firewall y pruebe nuevamente.Verifique la configuración de los archivos host, ifcfg-ethX, resolv.conf.

No es posible alcanzar un host remoto Verifique la configuración de las rutas con el comando netstat -r.Compruebe la configuración de los firewalls que se encuentran en el camino al host.

Un servicio de red no inicia. Muchos servicios proveen archivos de registros propios, verifique estos archivos generalmente ubicados en el directorio /var/log.Busque referencias al error el archivo /var/log/messages, /var/log/secure, etc.



Problema Acción a tomar

El servicio de red inicia pero no es posible acceder a él.

Compruebe la configuración del firewall.Compruebe que el servicio está escuchando en todas las interfaces de red.Revise la configuración del tcpwrapper.

La transferencia de archivos es muy lenta en algún sentido de la conexión, la conexión es intermitente o existen muchos errores en los paquetes en las estadísticas de netstat.

Verifique que la velocidad de la tarjeta de red concuerda con la velocidad configurada en el puerto del swtich.


Administración de servicios de red con Red Hat/Fedora...

Documents

Transcript of Administración de servicios de red con Red Hat/Fedora...