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

Transcripción

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

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

Transcripción

Documentos relacionados