LE 202 Linux Enterprise Servicios de Red

LE-202 - Linux Enterprise / Servicios de red
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...........................................................................................................15
Protocolo IGMP ..........................................................................................................15
UDP (User Datagram Protocol - Protocolo de Datagrama de Usuario)......................16
TCP (Transmission Control Protocol - Protocolo de Control de la Transmisión) ...... 16
Comparación de TCP y UDP .....................................................................................16
IPv6..................................................................................................................................17
Direcciones IPv6..........................................................................................................17
Ambitos........................................................................................................................18
Direcciones Unicast.....................................................................................................18
Link-local Unicast....................................................................................................19
Site-local Unicast.....................................................................................................19
Global Scope Unicast..............................................................................................20
Obtener el prefijo IPv6.................................................................................................20
Direcciones multicast...................................................................................................20
Direcciones Anycast....................................................................................................21
Configuración de dispositivos de red............................................................................. 22
Detección y configuración del hardware..........................................................................23
Scripts de red...................................................................................................................24
Ficheros de configuración de red................................................................................24
Ficheros de configuración de interfaz.........................................................................25
Interfaces Ethernet......................................................................................................25
Interfaces de acceso telefónico...................................................................................26
Otras interfaces...........................................................................................................27
Ficheros alias..............................................................................................................27
Scripts de control de interfaz.......................................................................................28
Asignación de parámetros de red....................................................................................29
Nombre del host .........................................................................................................29
Dirección IP, máscara de sub-red y puerta de enlace................................................29
Servidores de nombres de dominio............................................................................ 30
Agregar rutas adicionales............................................................................................30
Función de Re-envío de paquetes para IP versión 4..................................................30
Función Zeroconf.........................................................................................................31
Verificación de la configuración...................................................................................31
La herramienta ethtool.....................................................................................................32
Network File System (NFS)...............................................................................................34
Network File System (NFS).............................................................................................35
NFS y portmap............................................................................................................35
Trabajando con portmap.............................................................................................35
Archivos de configuración del servidor NFS................................................................... 37
El archivo /etc/exports.................................................................................................38
Archivos de configuración de clientes NFS.................................................................40
El archivo /etc/fstab.....................................................................................................40
Opciones de montaje NFS comunes.......................................................................... 41
Resolución de problemas de NFS con portmap..............................................................42
Dynamic Host Configuration Protocol (DHCP)...............................................................44
Dynamic Host Configuration Protocol (DHCP)................................................................45
Motivos para usar el protocolo DHCP.........................................................................45
Configuración de un servidor DHCP...............................................................................45
Archivo de configuración.............................................................................................45
Parámetro Range (Rango)..........................................................................................47
Dirección IP estática con DHCP .................................................................................47
Base de datos de arrendamiento................................................................................47
Arranque y parada del servidor.......................................................................................48
Agente de retransmisión DHCP......................................................................................48
Interconexión con Windows - SAMBA ............................................................................50
Configuración de SAMBA................................................................................................51
Configuración de la sección [global] de servidor SAMBA ..........................................51
3 Ing. Ivan Ferreira

Configuración de la sección [shares] de servidor SAMBA .........................................54
Accediendo a recursos SAMBA......................................................................................57
Escenarios típicos............................................................................................................58
Servidor proxy/cache Squid ............................................................................................60
Servidor proxy/cache Squid.............................................................................................61
Configuración básica.......................................................................................................61
Parámetro http_port.....................................................................................................62
Parámetro cache_mem...............................................................................................63
Parámetro cache_dir...................................................................................................63
Parámetro ftp_user......................................................................................................64
Control de acceso........................................................................................................64
Reglas de Control de Acceso......................................................................................65
Parámetro cache_mgr.................................................................................................66
Parámetro cache_peer: caches padres y hermanos..................................................66
Aplicando Listas y Reglas de control de acceso.............................................................67
Control de acceso - Caso 1.........................................................................................67
Control de acceso - Caso 2.........................................................................................68
Proxy Transparente.........................................................................................................69
Proxy transparente - Regla de iptables.......................................................................69
Estableciendo el idioma por defecto................................................................................70
Iniciando el servicio al arranque del sistema...................................................................70
Depuración de errores.....................................................................................................70
Very Secure FTP Daemon (VSFTPD) .............................................................................. 72
Configuración inicial.........................................................................................................73
Control del servicio vsftpd ...............................................................................................74
Control de acceso de los usuarios..................................................................................75
Usuarios anónimos......................................................................................................75
Usuarios locales..........................................................................................................75
Berkeley Internet Name Domain (BIND).......................................................................... 79
Introducción a DNS..........................................................................................................80
Zonas de servidores de nombres....................................................................................81
Tipos de zonas de los servidores de nombres................................................................82
Red Hat Certified Engineer 4

Consultas iterativas y recursivas.....................................................................................82
BIND como un servidor de nombres...............................................................................83
El archivo /etc/named.conf..........................................................................................84
Etiquetas de comentarios........................................................................................84
Declaración acl........................................................................................................85
Declaración include.................................................................................................86
Declaración options.................................................................................................86
Declaración zone.....................................................................................................88
Otros tipos de declaraciones...................................................................................91
Ejemplo de declaraciones de zone.............................................................................92
Configuración del archivo /etc/named.conf.................................................................93
Archivos de zona.........................................................................................................95
Directivas de archivos de zona...............................................................................96
Registros de recursos de archivos de zona................................................................96
Registro SOA (Start Of Authority)...........................................................................97
Registro NS (Name Server)....................................................................................98
Registro A (Address)...............................................................................................98
Registro CNAME (Cannonical Name).....................................................................99
Registro MX (Mail eXchange).................................................................................99
Registro PTR (PoinTeR).......................................................................................100
Ejemplo de archivo de zonas....................................................................................100
Archivos de zona de resolución de nombres inversa............................................... 102
Uso de rndc....................................................................................................................103
Opciones de línea de comandos de rndc..................................................................103
Servidor Apache HTTP ...................................................................................................105
Directivas de configuración en httpd.conf..................................................................... 106
Sugerencias de configuración generales..................................................................106
Directiva ServerRoot.................................................................................................107
Directiva PidFile.........................................................................................................107
Directiva Timeout.......................................................................................................107
Directiva KeepAlive...................................................................................................107
Directiva MaxKeepAliveRequests.............................................................................107

Directiva KeepAliveTimeout......................................................................................108
Directivas MinSpareServers y MaxSpareServers.....................................................108
Directiva StartServers................................................................................................108
Directiva MaxClients..................................................................................................108
Directiva Listen..........................................................................................................108
Directiva Include........................................................................................................109
Directiva User............................................................................................................109
Directiva Group..........................................................................................................109
Directiva ServerAdmin...............................................................................................109
Directiva ServerName...............................................................................................110
Directiva DocumentRoot...........................................................................................110
Directiva DirectoryIndex............................................................................................110
Directiva AccessFileName........................................................................................111
Directiva HostnameLookups.....................................................................................111
Directiva ErrorLog......................................................................................................111
Directiva LogLevel.....................................................................................................111
Directiva ServerSignature.........................................................................................111
Directiva Redirect......................................................................................................112
Configuración de directorios .........................................................................................112
Directiva Alias............................................................................................................112
Directiva ScriptAlias...................................................................................................112
Directiva AddHandler.................................................................................................113
Directiva Directory.....................................................................................................113
Directiva Options.......................................................................................................114
Directiva AllowOverride.............................................................................................114
Directiva Order..........................................................................................................115
Directiva UserDir.......................................................................................................115
Arrancar y detener httpd................................................................................................116
Configuración de máquinas virtuales............................................................................117
Directiva NameVirtualHost........................................................................................117
Directiva VirtualHost..................................................................................................117
Máquinas Virtuales....................................................................................................117

Ejemplo de creación de máquinas virtuales..............................................................118
Configuración de autenticación para el acceso a directorios........................................119
Configuración del Servidor Seguro Apache HTTP........................................................119
Vista preliminar de los paquetes relacionados con la seguridad..............................120
Vista preliminar de certificados y seguridad..............................................................120
Generar una clave.....................................................................................................121
Generar una petición de certificado para enviarla a un CA......................................123
Creación de un certificado autofirmado.................................................................... 125
Probar su certificado..................................................................................................125
Forzar el uso del modo SSL......................................................................................126
Servicios de correo electrónico.....................................................................................127
Conceptos generales.....................................................................................................128
Postfix............................................................................................................................129
Arquitectura de Postfix..............................................................................................129
Archivos de configuración de Postfix........................................................................131
EL archivo main.cf.....................................................................................................132
Directivas adicionales................................................................................................133
Direcciones canónicas..............................................................................................134
Usuarios reubicados..................................................................................................134
Listas de correo.........................................................................................................135
Administración de colas............................................................................................136
Herramientas de gestión de colas.............................................................................137
Listar mensajes.........................................................................................................137
Borrando mensajes...................................................................................................137
Reteniendo mensajes................................................................................................138
Reencolando mensajes.............................................................................................138
Mostrando mensajes.................................................................................................138
Liberando mensajes..................................................................................................138
Mapas de transporte..................................................................................................139
Gateway de reenvío interno......................................................................................140
Reenvío de correo saliente.......................................................................................141
Enmascarando nombres de host..............................................................................141

Sendmail........................................................................................................................142
Confirmando la instalación de Sendmail...................................................................142
Configurando Sendmail.............................................................................................143
Control de RELAY.....................................................................................................144
Inicio del servicio sendmail .......................................................................................145
Administrando los aliases..........................................................................................146
Cómo usar un anfitrión inteligente............................................................................ 147
Central de correo.......................................................................................................148
Habilitando los servicios POP3 e IMAP.........................................................................148
Dovecot......................................................................................................................148
Configuración de Webmail.............................................................................................148
Secure Shell .....................................................................................................................150
Secure Shell...................................................................................................................151
El demonio SSH............................................................................................................151
Control del servicio SSH................................................................................................153
Cliente SSH para Windows...........................................................................................154
Transferencias de archivos de forma segura................................................................154
Secure copy...............................................................................................................155
Network Time Protocol....................................................................................................156
Convenciones generales...............................................................................................157
Zonas horarias...............................................................................................................158
Daylight Savings Time...............................................................................................158
Los archivos de zona horaria ...................................................................................158
El proyecto pool.ntp.org ................................................................................................160
Configuración de NTP...................................................................................................161
Solución de problemas...................................................................................................165
Diagnóstico y solución de problemas de red y servicios...............................................166

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
Presentación Aplicación FTP – DNS – SMTP – SSH – WWW
Sesión
Transporte Transporte TCP – UDP
Red Internet IP – ARP – ICMP - IGMP
Enlace Token Frame
Interfaz de red Ethernet ATM
Físico Ring Relay
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.linux.com. La forma numérica es un número
binario sin signo de 32 bits, habitualmente expresado en forma de números
decimales separados por puntos. Por ejemplo, 9.167.5.8 es una dirección de
Internet válida.
La forma numérica es usada por el software de IP. La función de mapeo entre los
dos la realiza el DNS (Domain Name System) discutido posteriormente.
Primeramente examinaremos la forma numérica, denominada dirección IP. La

dirección IP Para ser capaz de identificar una máquina en Internet, a cada interfaz
de red de la máquina o host se le asigna una dirección, la dirección IP, o dirección
de Internet.

Las direcciones IP son números de 32 bits representados habitualmente en formato

decimal (la representación decimal de cuatro valores binarios de 8 bits
concatenados por puntos). Por ejemplo128.2.7.9 es una dirección IP. Las
direcciones IP son usadas por el protocolo IP(ver Internet Protocol (IP)) para definir
únicamente un host en la red.
El formato binario para la dirección IP 128.2.7.9 es:
Decimal Binario
128.2.7.9 10000000.00000010.00000111.00001001
Una dirección IP se compone de dos partes, una de ellas identifica la red a la que
pertenece el host (equipo) y otra identifica al equipo en sí.
Las direcciones IP deben ser únicas y no deben repetirse dentro de una misma red.
Los host que desean comunicarse entre sí en una red, deben tener configurados la
misma dirección de red. Puede pensar en esta dirección como el código de área de
un número telefónico. Para todos los números de Ciudad del Este son iguales.
Cada dispositivo dentro de una red debe tener una única dirección de host. Puede
considerar que esta dirección es el número específico de teléfono con quien se
desea comunicar en C.E. Existen reglas que definen que parte de la dirección IP
identifica a la red y que parte identifica al host. Estas reglas son conocidas como
Clases de direcciones IP.
Hay cinco clases de direcciones IP:

0 8 16 24 31
Clase A 0 Redes Hosts
Clase B 10 Redes Hosts
Clase C 110 Redes Hosts
Clase D 1110 Multicast
Clase E 1111 Resevado
Solo las clases A, B y C son utilizadas para redes empresariales.
Las direcciones de clase A usan 7 bits para el número de red permitiendo 126
posibles redes(veremos posteriormente que de cada par de direcciones de red y de
host, dos tienen un significado especial). Los restantes 24 bits se emplean para el
número de host, de modo que cada red tener hasta 16,777,214 hosts.
Las direcciones de clase B usan 14 bits para el número de red, y 16 bits para el de
host, lo que supone 16382 redes de hasta 65534 hosts cada una.

Las direcciones de clase C usan 21 bits para el número de red y 8 para el de host,
lo que supone 2,097,150 redes de hasta 254 hosts cada una.
Las direcciones de clase D se reservan para multicasting o multidifusión, usada

para direccionar grupos de hosts en un área limitada.
Las direcciones de clase E se reservaron para usos en el futuro.
Clasificación de direcciones IP
Las direcciones IP se clasifican en:
● Direcciones IP públicas. Son visibles en todo Internet. Un ordenador con

una IP pública es accesible (visible) desde cualquier otro ordenador
conectado a Internet. Para conectarse a Internet es necesario tener una
dirección IP pública.
● Direcciones IP privadas (reservadas). Son visibles únicamente por otros

hosts de su propia red o de otras redes privadas interconectadas por
ruteadores. Se utilizan en las empresas para los puestos de trabajo. Los
ordenadores con direcciones IP privadas pueden salir a Internet por medio
de un ruteador (o proxy) que tenga una IP pública. Sin embargo, desde
Internet no se puede acceder a ordenadores con direcciones IP privadas.
A su vez, las direcciones IP pueden ser:
● Direcciones IP estáticas (fijas). Un host que se conecte a la red con

dirección IP estática siempre lo hará con una misma IP. Las direcciones IP
públicas estáticas son las que utilizan los servidores de Internet con objeto
de que estén siempre localizables por los usuarios de Internet. Estas
direcciones deben ser contratarlas.
● Direcciones IP dinámicas. Un host que se conecte a la red mediante

dirección IP dinámica, cada vez lo podría hacer con una dirección IP distinta.
Para ello es necesario que en la red exista un servidor DHCP (Dynamic Host
Configuration Protocol).
Clase Formato Número de Número de Rango de Máscara por
Redes Hosts direcciones defecto
A r.h.h.h 0.0.0.0- 255.0.0.0
128 16777214 127.0.0.0
B r.r.h.h 128.0.0.0- 255.255.0.0
16384 65534 191.255.0.0
C r.r.r.h 192.0.0.0- 255.255.255.0
2097152 254 223.255.255.0

Direcciones IP reservadas
Las siguientes direcciones IP pueden ser utilizadas dentro de una red privada
(empresarial) sin requerir autorización de una organización de asignación de
direcciones IP.
● Clase A: 10.0.0.0
● Clase B: 172.16.0.0 - 172.31.0.0
● Clase C: 192.168.0.0 - 192.168.255.0
Direcciones especiales que no pueden ser utilizadas:
● 0.0.0.0 esta reservada para la puerta de enlace por defecto (default

gateway ).
● 127.0.0.0 esta reservada para la tarjeta de red loopback en cada host

(127.0.0.1) utilizada para comunicación dentro del mismo host y diagnóstico.
● Todos los bits de la porción de hosts a 0: Ej. 192.168.0.0 Este es el

número que identifica a la red.
● Todos los bits de la porción de hosts a 1: Ej. 192.168.255.255 Este es el

número de broadcast. El broadcast es una dirección utilizada para enviar
mensajes a todos los hosts de la red.
Máscaras de subred
Los Id. de red y de host en una dirección IP se distinguen mediante una máscara
de subred. Cada máscara de subred es un número de 32 bits que utiliza grupos de
bits consecutivos de todo unos (1) para identificar la parte de Id. de red y todo
ceros (0) para identificar la parte de Id. de host en una dirección IP.
Por ejemplo, la máscara de subred que se utiliza normalmente con la dirección IP

131.107.16.200 es el siguiente número binario de 32 bits:
Decimal Binario
255.255.0.0 11111111.11111111.00000000.00000000
Este número de máscara de subred está formado por 16 bits uno seguidos de 16
bits cero, lo que indica que las secciones de Id. de red e Id. de host de esta
dirección IP tienen una longitud de 16 bits. Normalmente, esta máscara de subred
se muestra en notación decimal con puntos como 255.255.0.0.

Normalmente, los valores predeterminados de máscara de subred (como se

muestra en la tabla anterior) son aceptables para la mayor parte de las redes sin
requisitos especiales en las que cada segmento de red IP corresponde a una única
red física.
En algunos casos, puede utilizar máscaras de subred personalizadas para

implementar la creación de subredes IP. Con la creación de subredes IP, se puede
subdividir la parte de Id. de host predeterminada en una dirección IP para
especificar subredes, que son subdivisiones del Id. de red basado en la clase
original.
Al personalizar la longitud de la máscara de subred, puede reducir el número de

bits que se utilizan para el Id. de host actual.
Para evitar problemas de direcciones y enrutamiento, debe asegurarse de que

todos los equipos TCP/IP de un segmento de la red utilizan la misma máscara de
subred.
Protocolo ARP
Dentro de una misma red, las máquinas se comunican enviándose tramas físicas.
Las tramas Ethernet contienen campos para las direcciones físicas de origen y
destino (6 bytes cada una) también conocidas como MAC address.
El MAC address es una dirección que está grabada en cada tarjeta de red y es
única para cada tarjeta fabricada en el mundo. Por ejemplo puede ser representado
de la siguiente forma:
● 08-00-4c-85-fc-8c
● 08:00:4c:85:fc:8c
El problema que se nos plantea es cómo podemos conocer la dirección física de la

máquina destino. Necesitamos obtener la dirección física de un ordenador a partir
de su dirección IP. Esta es justamente la misión del protocolo ARP (Address
Resolution Protocol, protocolo de resolución de direcciones).
Para visualizar la tabla arp de su equipo local, puede utilizar el comando arp:
# arp -an
? (10.129.4.233) at 00:16:3E:43:23:7F [ether] on eth0
? (10.129.5.11) at 00:0B:5D:E0:0D:14 [ether] on eth0
? (10.129.4.156) at 02:0B:CD:F4:E4:7C [ether] on eth0
? (172.20.0.19) at 00:1B:78:56:E1:6D [ether] on eth0
? (10.129.4.1) at 00:15:C7:F2:ED:80 [ether] on eth0

Protocolo ICMP
Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar

defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol,
protocolo de mensajes de control y error) se encarga de informar al origen si se ha
producido algún error durante la entrega de su mensaje.
Pero no sólo se encarga de notificar los errores, sino que también transporta
distintos mensajes de control.
Campo de tipo Tipo de mensaje 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)
El comando ping utiliza el protocolo ICMP para el diagnóstico de red, por ejemplo,
ejecutando el siguiente comando:
# ping -c 3 localhost
PING mercurio.linux.com.py (127.0.0.1) 56(84) bytes of data.
64 bytes from mercurio.linux.com.py (127.0.0.1): icmp_seq=1 ttl=64 time=4.02 ms
--- mercurio.linux.com.py ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.193/1.506/4.020/1.778 ms
Es posible notar claramente la secuencia de paquetes ICMP utilizados para

verificar la comunicación de red.
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 una interfaz a IP. UDP es un servicio de entrega de
datagramas no orientado a conexión, lo cual no garantiza la entrega. UDP no
mantiene una conexión de extremo a extremo con el módulo UDP remoto;
simplemente envía el datagrama a la red y acepta datagramas de entrada de la
red. UDP añade dos valores a los servicios provistos por IP. Uno de ellos es la
multiplexación de la información entre aplicaciones basándose en el número de
puerto. El otro es una suma de comprobación (checksum) para comprobar la
integridad de los datos.
TCP (Transmission Control Protocol - Protocolo de Control de la

Transmisión)
TCP ofrece un servicio diferente que UDP. TCP ofrece un flujo de bytes orientado a
conexión, en lugar de un servicio de entrega de datagramas no orientado a
conexión.
TCP garantiza la entrega, mientras que UDP no lo hace. TCP es usado por las
aplicaciones de red que quieren garantía de entrega y no pueden ser molestados
haciendo time-outs (tiempo de espera agotado) y retransmisiones. Las dos
aplicaciones de red más típicas que usan TCP son FTP (File Transfer Protocol -
Protocolo de Transferencia de Ficheros), SSH o TELNET. La mayor capacidad de
TCP no es gratis: requiere más CPU y ancho de banda de red. Las interioridades
del módulo TCP son mucho más complicadas que las de un módulo UDP.
Comparación de TCP y UDP
El TCP es un protocolo de comunicación entre dos máquinas con:
● Negociación de conexión
● Acuse de recibo de cada paquete
● Control de no duplicidad de paquetes

● Inmune a la llegada desordenada de paquetes
● Inmune a la perdida de paquetes (se solicitan otra vez)
UDP es un protocolo simple para transferir datos sin toda la sobrecarga del TCP y
sin ninguna de sus virtudes. En las conexiones UDP no hay negociación, ni acuse
de recibo, ni control de perdida o desorden o duplicación de paquetes, todo esto
debe ser gestionado por el servicio que emplea la conexión.
IPv6
El protocolo sucesor de IPv4 IPv6 el cual está definido en los estándar RFC 2460 y
relacionados.
Los problemas fundamentales que requerían un rediseño del protocolo incluyen:
● Mayor espacio de direcciones IP.
● Eliminar la necesidad de utilizar NAT.
● Simplificar la reorganización de redes y renumeración de direcciones.
● Proporcionar mecanismos de Calidad de servicio (QoS).
● Eliminar el broadcast.
● Seguridad con IPsec para autenticación y encriptación integrada.
● IPv6 Móvil.
Direcciones IPv6
Las direcciones IPv6 están compuestas de 128 bits, cuatro veces mas que las
direcciones IPv4, esto permite 2^128 direcciones posibles.
Las direcciones IPv6 están escritas en hexadecimal, en pares separados por dos
puntos. Los dígitos hexadecimales son conocidos como “nibbles”.
Un ejemplo de dirección IPv6 es el siguiente:
fe80:0000:0000:0000:032c:ffc1:def1:21e4
Para abreviar, dentro de cada bloque, los ceros a la izquierda pueden ser omitidos,
el resultado sería:

fe80:0:0:0:32c:ffc1:def1:21e4
Los bloques consecutivos de ceros pueden ser representados con un doble dos
puntos (::), por tanto la dirección anterior se representaría:
fe80::32c:ffc1:def1:21e4
Por ejemplo, la dirección IPv6 para la interfaz loopback es:
0000:0000:0000:0000:0000:0000:0000:0001
La cual puede representarse como:
::1
Los prefijos de red son representados utilizando una barra seguido por el número
de bits relevantes tal como en IPv4. Por ejemplo:
fe80::/64
Ambitos
IPv4 definía rangos de direcciones para ser utilizadas en redes privadas, tales
como la 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16 en nodos que no requerían
conectividad global. Estas direcciones posteriormente utilizarían NAT para
proporcionar una conectividad limitada. Mientras IPv6 elimina la necesidad de NAT,
preserva y extiende la idea original de los ámbitos de direcciones presentados en
RFC 1918.
Tres ámbitos son los más importantes:
● Global scope: Las direcciones que son ruteadas a través de la Internet6

entera.
● Site-local scope: Las direcciones de ámbito site-local son ruteadas

únicamente dentro de un “sitio”. Son equivalentes a las direcciones IPv4 de
uso privado.
● Link-local scope: Este ámbito no es ruteado, de tal forma que únicamente

puede ser utilizado dentro de una sola red física. Generalmente utilizado
para propósitos internos de IPv6.
Direcciones Unicast
Las direcciones unicast son aquellas asignadas a las interfaces de red. Por

ejemplo, la dirección IP de la interfaz loopback, ::1, es una dirección IP unicast

especial.
IPv6 permite de manera nativa la configuración de múltiples direcciones IP por

interfaz, similar a los “aliases” de IPv4, con la diferencia que no requiere interfaces
“virtuales” para su asignación.
Las direcciones IPv6 consisten de una “porción de red” llamada prefijo de subred
(subnet prefix) y una “porción de host” llamada identificador de interfaz
(interface identifier/interface ID). A diferencia de IPv4, el tamaño del prefijo de
subred es siempre 64 bits. Por tanto, todas las direcciones IPv6 unicast excepto la
interfaz loopback sería como sigue:
Prefijo de subred (64 bits) Identificador de interfaz (64 bits)
fe80:0000:0000:0000: 032c:ffc1:def1:21e4
Esto hace que el concepto de tamaños variables de prefijos de subred quede

obsoleto.
Link-local Unicast
Las direccioens link-local son utilizadas para una variedad de propósitos internos
de IPv6. Tan pronto como una interfaz IPv6 es habilitada, automáticamente
adquirirá una dirección link-local iniciando con un prefijo fe80::/64. Los nodos
utilizan la dirección link-local cuando se comunican en la misma subred, conocida
como link. Por ejemplo, una red son ruteador, utiliza direcciones link-local para
comunicar a los host entre sí en el link. Son equivalentes a las direcciones
APIPA/Zeroconf.
Site-local Unicast
Las direcciones site-local son equivalentes a las direcciones privadas IPv4. Las
direcciones site-local no son alcanzables de otros sitios y los ruteadores no deben
reenviar tráfico site-local fuera del sitio. Estas direcciones pueden ser utilizadas en
adición a las direcciones globales. Las direcciones site-local no son configuradas
automáticamente a diferencia de las link-local.
Las direcciones site-local actualmente son conocidas como Unique Local Unicast.
Estas direcciones requieren que sean aleatoriamente generadas para evitar la
posibilidad de que dos sitios que requieran conectividad posterior, tengan el mismo
rango de direcciones.
El prefijo para las direcciones unique local unicast el cual no se encuentra

administrado de manera centralizada es fd00::/8. Cualquiera puede tomar un prefijo
aleatorio /48 para propósitos locales de este pool. Sin embargo, no es una buena

idea realizar esto, de ser posible, deben utilizarse direcciones de ámbito global.
Global Scope Unicast
Los paquetes enviados a direcciones de este tipo pueden ser ruteados a través de
toda la Internet6.
Las direcciones globales son asignadas a los sitios como prefijos /48. El prefijo
asignado es llamado global routing prefix. El prefijo actual para direcciones
globales es 2000::/3. El sitio de la organización puede utilizar estos 16 bits dentro
del sitio para crear 65536 subredes.
Dentro de un sitio, a cada subred se asigna un subnet ID de 16 bits. En conjunto

con el routing prefix forman el subnet prefix o prefijo de subred.
Prefijo de subred (64 bits) Identificador de interfaz (64 bits)

Global Routing Prefix (48 Subnet ID Interface ID
bits) (16 bits)
2001:0DB8:F282: 2A3C: 032c:ffc1:def1:21e4
Algunos prefijos dentro de este ámbito fueron asignados para propósitos

especiales, por ejemplo, el prefijo 2001:db8::/32 ha sido asignado para propósitos
de documentación como ejemplos en los libros.
Obtener el prefijo IPv6
Las direcciones IPv6 son virtualmente ilimitadas y debería obtener su propio prefijo
global /48 de un ISP.
Si no puede conseguir uno, utilice direcciones unique local unicast como se define
en RFC 4193 que no serán ruteadas a Internet. Esto es apropiado so no deseamos
conectarnos a Internet6, sin embargo, no es una buena idea a largo plazo, ya que
no permitirá conexión a Internet6. Asegúrese de utilizar una herramienta que le
ayude a generar el prefijo para la dirección unique local unicast, como la disponible
en este sitio:
http://forschung.goebel-consult.de/ipv6/createLULA
Direcciones multicast
Multicast ha madurado lo suficiente en IPv6 de tal forma a que reemplaza por

completo al “broadcast”, es decir, IPv6 no utiliza en absoluto broadcast.

Las direccioens IPv6 multicast inician con el prefijo ff00::/8. Multicast soporta mas
ámbitos que unicast. Dos de estos ámbitos son particularmente útiles, el grupo all
nodes link-local multicast (ff02::1) y el grupo all routers link-local multicast (ff02::2).
Usando estas direcciones, es posible hacer ping a todos los nodos o ruteadores
dentro de una subred, respectivamente.
Direcciones Anycast
Las direcciones anycast son un intermedio entre unicast y multicast. Utilizan

direcciones del rango de direcciones unicast y los paquetes anycast son enviados
siempre a una sola interfaz, como en unicast. Pero pueden existir multiples
interfaces escuchando a esa dirección, como multicast. Con IPv4, un efecto similar
se ha logrado usando la misma dirección IP en diferentes servidores DNS raíz
ubicados alrededor del mundo. Usando protocolos de ruteo dinámico, las peticiones
son direccionadas automáticamente al servidor DNS más cercano usando esa
dirección IP.

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 demonio 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 listando el
contenido del directorio /lib/modules/[versión de su kernel]/kernel/drivers/net/.
Ejemplo:
# ls /lib/modules/$(uname -r)/kernel/drivers/net/
Si utiliza kenel 2.6, la lista de módulos existentes en su equipo puede obtenerla del
mismo modo que la versión 2.4.x, o utilizar el comando:
# modprobe -t net -l

Scripts de red
Usando CentOS Linux, todas las comunicaciones de red se realizan entre

interfaces, que son dispositivos de red conectados al sistema, configurados de un
modo determinado y usando un protocolo, al menos, para intercambiar datos con
otros sistemas. Los diferentes tipos de interfaz que existen son tan variados como
los dispositivos que los soportan.
Los ficheros de configuración para las diferentes interfaces de red y scripts para
activarlos o desactivarlos están ubicados en el directorio /etc/sysconfig/network-
scripts. Mientras que la existencia de ficheros de interfaces particulares puede
diferir de sistema a sistema dependiendo del uso, los tres tipos de ficheros
diferentes que existen en este directorio, ficheros de configuración de interfaz,
scripts de control de interfaz y ficheros de función de red, funcionan conjuntamente
para habilitar CentOS 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 CentOS Linux para configurar la red. La
comprensión del papel que desemepeñan en la configuración de la red es
fundamental para configurar el sistema.
Los principales ficheros de configuración de la red son los siguientes:
● /etc/hosts El principal propósito de este fichero es resolver los nombres de

hosts que no se pueden resolver en otra manera. Se puede usar solamente
para resolver nombres de hosts en pequeñas redes sin servidor DNS. Sin
tener en cuenta el tipo de red que el ordenador use, este fichero contiene un
línea que especifica la dirección IP del dispositivo loopback (127.0.0.1) como
por ejemplo localhost.localdomain.
● /etc/resolv.conf Este fichero especifica las direcciones IP de los servidores

DNS y el dominio de búsqueda. A menos que se haya configurado para algo
diferente, los scripts de inicialización de la red llenan este fichero.
● /etc/sysconfig/network Especifica la información del routing y del host para

todas las interfaces de red.
● Para cada interfaz de

/etc/sysconfig/network-scripts/ifcfg-<interface-name>
red del sistema CentOS 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 CentOS 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 mas de un adaptador de red, 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
Si desea utilizar una utilidad GUI, puede ejecutar los comandos system-config-
network o system-config-network-tui 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, se describen los parámetros que necesita para
modificar el fichero de configuración.
Dentro de cada uno de los ficheros de configuración de la interfaz, son comunes los

siguientes valores:
● BOOTPROTO=<protocol>, donde <protocol> es uno de los siguientes:
○ none No se debería utilizar ningún protocolo de tiempo de arranque.
○ bootp Se debería utilizar el protocolo BOOTP.
○ dhcp Se debería utilizar el protocolo DHCP.
● BROADCAST=<address>, donde <address> es la dirección de broadcast.
● DEVICE=<name>, donde <name> es el nombre del dispositivo físico (a excepción

de los dispositivos PPP asignados de forma dinámica donde es el nombre
lógico).
● IPADDR=<address>, donde <address> es la dirección IP.
● NETMASK=<mask>, donde <mask> es el valor de la máscara de red.
● NETWORK=<address>, donde <address> es la dirección de red. Esta opción ya no

se usa.
● ONBOOT=<answer>, donde <answer> es uno de los siguientes:
○ yes dispositivo debería activarse en el momento de arranque.
○ no Este dispositivo no debería activarse en el momento de arranque.
● PEERDNS=<answer>, donde <answer> es uno de las siguientes:
○ yesModificar /etc/resolv.conf si la directiva DNS está activada. Si está

usando DCHP, la opción sí es la predeterminada.
○ no No modificar /etc/resolv.conf
Interfaces de acceso telefónico
Si se conecta a una red, como Internet, a través de la conexión de acceso

telefónico PPP, necesitará un fichero de configuración para esa interfaz.
Este fichero se crea automáticamente cuando usa las aplicaciones wvdial, la

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
CentOS 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
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.
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:1 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
# ifconfig eth0:1 down
Scripts de control de interfaz
Los scripts de control de interfaz controlan la activación y desactivación de las

mismas. Existen dos scripts de control de la interfaz primarios, /sbin/ifdown y
/sbin/ifup que utilizan otros scripts de control variados localizados en el directorio
/etc/sysconfig/network-scripts para activar y desactivar las interfaces de red.
Los dos scripts de control de interfaz son ifdown y ifup y son enlaces simbólicos
para los scripts en el directorio /sbin. Cuando se solicita cualquiera de estos
scripts, aceptan el uso de un valor de la interfaz, como por ejemplo:
# ifup eth0
Determining IP information for eth0... done.
Tras haber verificado que se ha especificado una interfaz y que al usuario que ha
ejecutado la petición se le permite activar o desactivar la interfaz, se solicita el
script correcto para el tipo de dispositivo de interfaz. Los siguientes scripts de
control de interfaz son los más habituales de este tipo:
● ifup-aliases Configura los alias IP desde los ficheros de configuración de la

interfaz cuando se asocia más de una dirección IP con una interfaz.
● ifdown-ipv6 y ifup-ipv6 Contiene la llamada de funciones basadas en IPv6

que utilizan las variables de entorno en varios ficheros de configuración de la
interfaz y /etc/sysconfig/network.
● ifup-ipx Se usa para configurar una interfaz IPX.
● ifup-plip Se usa para configurar una interfaz PLIP.
● ifup-plusb Se usa para configurar una interfaz USB para conexiones de red.
● ifdown-post e ifup-post Contiene comandos que se ejecutan después de que

una interfaz particular haya sido activada o desactivada.
● ifdown-ppp e ifup-ppp Se usa para activar o desactivar una interfaz PPP

mediante el uso de un dispositivo en particular.
● ifup-routes Añade rutas estáticas para un dispositivo en particular como si

se activase su interfaz.

● ifdown-sl y ifup-sl Se usa para activar o desactivar una interfaz SLIP.
Tenga en cuenta que si elimina o modifica estos scripts puede provocar varias
conexiones de interfaz que pueden funcionar de forma extraña o incluso fallar,
debido a que los scripts tienden a apoyarse uno en el otro. Sin embargo, los
usuarios avanzados pueden modificar los scripts relacionados con una interfaz
específica para hacer que se produzcan pasos adicionales cuando esa interfaz se
activa o desactiva.
También puede utilizar el script init /etc/rc.d/init.d/network para activar o

desactivar todas las interfaces de red configuradas para iniciar en el momento de
arranque con el comando:
# /sbin/service network start | stop | restart
Asignación de parámetros de red
Nombre del host
Debe editarse con un procesador de textos el archivo /etc/hosts, y debe verificarse

que el nombre de la máquina esté asociada a su dirección IP correspondiente y no
a la interfaz loopback. Ejemplo:
127.0.0.1 localhost.localdomain localhost
192.168.1.1 serv1.linux.com.py serv1
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=serv1.linux.com.py
El nombre de host es retornado por el comando hostname. El valor retornado debe

coincidir la entrada del archivo /etc/hosts.
Dirección IP, máscara de sub-red y puerta de enlace
Debe editarse con un procesador de textos /etc/sysconfig/network-scripts/ifcfg-

eth<numero> y debe verificarse que sus parámetros de red sean los correctos. Por
ejemplo, para la primera interfaz de red, edite el archivo ifcfg-eth0, para la
segunda ifcfg-eth1:

DEVICE=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 linux.com.py
nameserver 192.168.1.254
nameserver 192.168.1.1
Agregar rutas adicionales
Si se requiere establecer rutas adicionales para obtener conectividad con otras

redes, se pueden generar ficheros para cada interfaz que sea necesario, en donde
se establecen los valores para puerta de enlace, red a la que se quiere acceder y la
máscara de sub-red correspondiente. Los fichero se deben generar dentro de
/etc/sysconfig/network-scripts/ como route-[interfaz] y deben llevar el siguiente
formato:
<destino> via <nombre>
Por citar un ejemplo, imaginemos que nos encontramos dentro de la red

192.168.1.0 y se requiere establecer conectividad con las redes 192.168.2.0 y
192.168.3.0, con máscaras 255.255.255.0, a través de las puerta de enlace o
ruteadores con dirección IP 192.168.1.1. La configuración de
/etc/sysconfig/network-scripts/route-eth0 sería la siguiente:
192.168.2.0/24 via 192.168.1.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

interfaz de red cuando no puede contactar un servidor DHCP. Dicha configuración
hará que cuando se ejecute netstat -nr se muestre una ruta adicional hacia la red
169.254.0.0:
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Si se desea deshabilitar dicha función, solo bastará añadir en

/etc/sysconfig/network el parámetro NOZEROCONF con el valor yes:
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=serv1.linux.com.py
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 -nr
Para comprobar si hay resolución de nombres, se puede realizar una consulta

hacia los DNS definidos para el sistema utilizando:

# host host.dominio.com
# dig host.dominio.com
La herramienta ethtool
La herramienta ethtool es utilizada para consultar y cambiar la configuración de un

dispositivo ethernet.
El modulo de la tarjeta ethernet debe compatible con mii-tool o ethtool para poder
utilizar el comando.
Para consultar el estado de un adaptador de red, utilice el siguiente comando:

# ethtool <nombre de interface>
Por ejemplo:
# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
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 /etc/sysconfig/network-

scripts/ifcfg-ethX y agregue la siguiente línea:
ETHTOOL_OPTS="speed 100 duplex full autoneg off"

3
Network File System (NFS)

NFS (Network File System) permite a las máquinas montar particiones en un

sistema remoto en concreto y usarlas como si estuvieran en el sistema de archivos
local. Esto permite centralizar archivos en una localización, mientras se permite su
acceso continuo a los usuarios autorizados.
Hay distintas versiones de NFS actualmente en uso. La versión 2 de NFS (NFSv2),

que tiene varios años, es ampliamente soportada por muchos sistemas operativos.
La versión 3 (NFSv3) tiene más características, incluyendo tamaño variable del
manejador de archivos y una mejor información de errores. NFSv4 incluye varias
mejoras sobre NFSv3 como mayor seguridad, soporte para ACL, codificación UTF-
8, bloqueo y montado integrado sin necesidad de protocolos auxiliares, entre otras
características.
NFS y portmap
Linux usa una combinación de soporte a nivel de kernel y demonios en continua

ejecución para compartir archivos a través de NFS, sin embargo, el soporte NFS
debe estar activo en el kernel de Linux para que funcione. NFS usa Remote
Procedure Calls (RPC) para enrutar peticiones entre clientes y servidores,
implicando que el servicio portmap debe estar disponible y activo en los niveles de
ejecución adecuados para que la comunicación NFS funcione.
NFS se apoya en las llamadas de procedimientos remotos (RPC) para funcionar.

Se requiere portmap para trazar las peticiones RPC a los servicios correctos. Los
procesos RPC notifican a portmap cuando comienzan, revelando el número de
puerto que ellos están monitorizando y el número de programas RPC que esperan
servir. El sistema cliente entonces contacta con el portmap del servidor con un
número de programa RPC particular. Entonces portmap redirecciona al cliente al
número del puerto apropiado para que se comunique con el servicio adecuado.
Como los servicios basados en RPC confían en portmap para hacer todas las
conexiones con las peticiones de clientes entrantes, portmap debe estar disponible
antes que cualquiera de esos servicios comience. Si, por alguna razón, el servicio
portmap inesperadamente termina, reinicie portmap y cualquier servicio que estuviera
ejecutándose entonces.
Trabajando con portmap
Los procesos siguientes se aseguran que una conexión particular NFS esté
permitida y pueda proceder sin error:

● rpc.mountd:El proceso que recibe la petición de montaje desde un cliente

NFS y chequea para mirar si coincide con un sistema de archivos
actualmente exportado.
● rpc.nfsd: El proceso que implementa los componentes del espacio del

usuario del servicio NFS. Trabaja con el kernel Linux para satisfacer las
demandas dinámicas de clientes NFS, tales como proporcionar procesos
adicionales del servidor para que los clientes NFS lo utilicen.
● rpc.lockd:Un demonio innecesario en los kernels modernos. El bloqueo de

archivos NFS ahora lo hace el kernel. Está incluido en el paquete nfs-utils
para usuarios de versiones antiguas del kernel que no incluyen esta
capacidad por defecto.
● rpc.statd:implementa el protocolo RPC Network Status Monitor (NSM). Esto

proporciona notificación de reinicio cuando un servidor NFS es reiniciado
luego de haber sido apagado abruptamente.
● rpc.rquotad: Un servidor RPC que proporciona información de cuotas de

usuarios a usuarios remotos.
No todos estos programas son requeridos para el servicio NFS. Los únicos
servicios que deben estar activos son rpc.mountd, rpc.nfsd, y portmap. Los otros
demonios proporcionan funcionalidades adicionales y sólo deben usarse si el
entorno de su servidor los requiere.
La versión 2 de NFS usa el User Datagram Protocol (UDP) para proporcionar una
conexión de red sin estado entre el cliente y el servidor. La versión 3 de NFS puede
usar UDP o TCP corriendo sobre una IP. La conexión UDP sin estado minimiza el
tráfico de red, al mandar el servidor NFS una cookie al cliente, después de que el
cliente sea autorizado a acceder al volumen compartido. Esta cookie es un valor
aleatorio guardado en la parte del servidor y es pasado junto con las peticiones
RPC desde el cliente. El servidor NFS puede ser reiniciado sin afectar a los clientes
y las cookies permanecen intactas.
Con NFS, la autenticación sólo se produce cuando el cliente intenta montar un

sistema de archivos remoto. Para limitar el acceso, el servidor NFS utiliza en primer
lugar envolturas TCP (TCP wrappers). Estas envolturas leen los archivos
/etc/hosts.allow y /etc/hosts.deny para determinar si a un cliente particular le debe
ser explícitamente permitido o denegado su acceso al NFS.
Después de que al cliente se le permite acceso a una envoltura TCP, el servidor

NFS recurre a su archivo de configuración, /etc/exports, para determinar si el
cliente tiene suficientes privilegios para montar alguno de los sistemas de archivos
exportados. Después de permitir el acceso, cualquier operación de archivos y
directorios es mandada al servidor usando llamadas de procedimiento remotas.

Archivos de configuración del servidor NFS
Es sencillo configurar un sistema para compartir archivos y directorios usando NFS.

Cada Sistema de archivos que se exporta a usuarios remotos vía NFS, así como
los derechos de acceso relativos a ellos, es localizado en el archivo /etc/exports.
Este archivo es leído por el comando exportfs para dar a rpc.mountd y a rpc.nfsd la
información necesaria para permitir el montaje remoto de un sistema de archivos
por una máquina autorizada.
El comando exportfs permite a root exportar o no directorios concretos sin reiniciar

los servicios NFS. Cuando se le pasan las opciones apropiadas a exportfs, el
sistema de archivos a exportar es incluido en /var/lib/nfs/xtab. Como rpc.mountd
se refiere al archivo xtab para decidir privilegios de acceso a un sistema de
archivos, los cambios en la lista de sistemas de archivos exportados toman efecto
inmediatamente.
Hay varias opciones disponibles cuando usamos exportfs:
-r Provoca que todos los directorios listados en /etc/exports sean
exportados construyendo una nueva lista de exportación en
/etc/lib/nfs/xtab. Esta opción refresca la lista de exportación con
cualquier cambio que hubiéramos realizado en /etc/exports.
-a Provoca que todos los directorios sean exportados o no,
dependiendo de qué otras opciones hemos pasado a exportfs.
-o opciones Permite al usuario especificar directorios a exportar que no estén
listados en /etc/exports. Estos sistemas de archivos adicionales
compartidos deben ser escritos de la misma forma que son
especificados en /etc/exports. Esta opción es usada para probar un
sistema de archivos antes de añadirlo permanentemente a la lista
de sistemas a exportar.
-i Ignora /etc/exports; sólo las opciones dadas desde la línea de
comandos son usadas para definir los sistemas de archivos
exportados.
-u Termina de exportar directorios que puedan ser montados por
usuarios remotos. El comando exportfs -ua suspende los recursos
compartidos NFS mientras que mantiene los demonios activos.
Para volver a compartir recursos NFS, teclee exportfs -r.
-v Operación descriptiva, donde los sistemas de archivos exportados o
dejados de exportar son mostrados en gran detalle al ejecutarse el
comando exportfs.

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

de archivos actualmente exportados.
Los cambios efectuados a /etc/exports pueden ser leídos al recargar el servicio

NFS con el comando service nfs reload. Esto deja a los demonios NFS
ejecutándose mientras reexporta el archivo /etc/exports.
El archivo /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.linux.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.linux.com.py será capaz de montar /algun/directorio y 192.168.0.3
podrá montar /otro/directorio/exportado. Como no hay opciones especificadas en
este ejemplo, varias preferencias por defecto toman efecto:
ro Sólo lectura (read-only). Las máquinas que monten este sistema
de archivos no podrán cambiarlo. Para permitirlas que puedan
hacer cambios en el sistema de archivos, debe especificar la
opción rw (lectura-escritura, read-write).
async Permite al servidor escribir los datos en el disco cuando lo crea
conveniente. Mientras que esto no tiene importancia en un
sistema de sólo lectura, si una máquina hace cambios en un
sistema de archivos de lectura-escritura y el servidor se cae o se
apaga, se pueden perder datos. Especificando la opción sync,
todas las escrituras en el disco deben hacerse antes de devolver
el control al cliente. Esto puede que disminuya el rendimiento.
wdelay Provoca que el servidor NFS retrase el escribir a disco si

sospecha que otra petición de escritura es inminente. Esto puede

mejorar el rendimiento reduciendo las veces que se debe acceder
al disco por comandos de escritura separados. Use no_wdelay para
desactivar esta opción, la cual sólo funciona si está usando la
opción sync.
root_squash Previene a los usuarios root conectados remotamente de tener
privilegios como root asignándole el userID de 'nobody'. Esto
reconvierte el poder del usuario root remoto al de usuario local
más bajo, previniendo que los usuarios root remotos puedan
convertirse en usuarios root en el sistema local. Alternativamente,
la opción no_root_squash lo desactiva. Para reconvertir a todos los
usuarios, incluyendo a root, use la opción all_squash. Para
especificar los ID de usuario y grupo para usar con usuarios
remotos desde una máquina particular, use las opciones anonuid y
anongid, respectivamente. De esta manera, puede crear una
cuenta de usuario especial para usuarios NFS remotos para
compartir y especificar anonuid=<valor>,anongid=<valor>, donde
<uid-valor> es el número ID de usuario y <gid-valor> es el número
ID de grupo.
Para saltarse estas opciones predeterminadas, debe especificar una opción que
tome su lugar. Por ejemplo, si no especifica la opción rw, entonces se exportará en
sólo lectura. Cada opción predeterminada para cada sistema de archivos
exportado, debe ser explícitamente ignorada. Adicionalmente, hay otras opciones
que están disponibles que no tienen especificado un valor predeterminado. Estas
incluyen desactivar el navegar por subdirectorios, permitir el acceso a puertos
inseguros, y permitir bloquear archivos inseguros (necesario para algunas
implementaciones antiguas de clientes NFS). Vea la página man de exports para
estas opciones menos usadas.
Cuando especifique los nombres de máquinas, use los métodos siguientes:
● Una sola máquina - Cuando una máquina en particular es especificada con

nombre completo de dominio, nombre de máquina o dirección IP.
● Comodines - Cuando usamos un carácter * o ? para referirnos a un grupo

de nombres completos de dominio o direcciones IP o que coincidan con una
cadena particular de letras.
Sin embargo, tenga cuidado cuando especifique comodines con nombres de

dominio completos, pues tienden a ser más exactos de lo que usted cree.
Por ejemplo, el uso de *.linux.com.py como comodín, permitirá a
ventas.linux.com.py acceder al sistema de archivos exportado, pero no a
bob.ventas.linux.com.py. Para permitir ambas posibilidades, debería usar
*.linux.com.py *.*.linux.com.py.

● Redes IP - Permite el acceso a máquinas basadas en sus direcciones IP. Es

posible especificar la máscara de red en formato decimal o como tamaño de
la máscara (for ejemplo 255.255.255.0 o /24).
● Grupos de redes - Permite que un nombre de grupo de red NIS, escrita

como @<nombre-grupo>, sea usada. Esto pone al servidor NIS controlando el
acceso de este sistema de archivos, donde los usuarios pueden ser
añadidos o borrados de un grupo NIS sin que afecte a /etc/exports.
La manera en que el archivo /etc/exports está organizado es muy importante,

particularmente lo que concierne a los espacios en blanco. Recuerde separar
siempre los sistemas de archivos exportados de una máquina a la otra, con un
espacio. Sin embargo, no debería haber otros espacios en el archivo a menos que
se usen en líneas comentadas.
Por ejemplo, las siguientes dos líneas significan cosas distintas:

/home bob.linux.com.py(rw,sync)
/home bob.linux.com.py (rw,sync)
La primera línea permite sólo a los usuarios de bob.linux.com.py acceder en modo

de lectura-escritura al directorio /home. La segunda línea permite a los usuarios de
bob.linux.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.
El archivo /etc/fstab
Colocando una línea adecuadamente formada en el archivo /etc/fstab tiene el

mismo efecto que el montaje manual del sistema de archivos exportado. El archivo
/etc/fstab es leído por el script /etc/rc.d/init.d/netfs cuando arranca el sistema y
cualquier recurso NFS listado será montado.
Un ejemplo de línea /etc/fstab para montar un NFS exportado será parecida a:
<servidor>:</recurso/exportado> </punto_montaje_local> nfs <opciones> 0 0
La opción <servidor> tiene que ver con el nombre de la máquina, dirección IP o

nombre de dominio totalmente cualificado del servidor que exporta el sistema de

archivos.
La opción </recurso/exportado> es la ruta al directorio exportado.
La opción </punto_montaje_local> especifica dónde montar en el sistema de

archivos local el directorio exportado. Este punto de montaje debe existir antes de
que /etc/fstab sea leído o el montaje fallará.
La opción nfs especifica el tipo de sistema de archivos que esta siendo montado.
El área <opciones> especifica como el sistema de archivos es montado. Por

ejemplo, si las opciones indican rw,suid, el sistema de archivos exportado será
montado en modo de lectura-escritura y los ID de usuario y grupo puestos por el
servidor serán usados. Aquí no se usan paréntesis.
Opciones de montaje NFS comunes
Aparte de montar un sistema de archivos via NFS en una máquina remota, existe
un número de diferentes opciones que pueden ser especificadas en tiempo de
montaje que pueden ser más fáciles de usar. Estas opciones pueden usarse con el
comando manual mount, configuraciones /etc/fstab, autofs y otros métodos de
montaje.
Las siguientes opciones son las más populares para montajes NFS:
● hard o soft - Especifican si el programa que usa un archivo vía conexión

NFS debe parar y esperar a que el servidor vuelva a estar en línea si la
máquina que exporta ese sistema de archivos no está disponible (hard), o
bien debe informar de un error (soft).
Si se especifica la opción hard, el usuario no podrá parar el proceso que está

esperando la comunicación NFS a menos que especifique la opción intr.
Si usa soft, puede usar la opción adicional timeo=<value>, donde <value>

especifica el número de segundos que deben pasar antes de informar del
error.
● intr -Permite a las peticiones NFS ser interrumpidas si el servidor se cae o

no puede ser accedido.
● nolock - Es requerido a veces cuando conectamos a servidores NFS

antiguos. Para requerir el bloqueo, use la opción lock.
● noexec - No permite la ejecución de binarios en el sistema de archivos

montado. Esto es útil si el sistema está montando un sistema de archivos no
Linux a través de NFS que contiene binarios incompatibles.

● nosuid - No permite que los bits SUID o SGID tomen efecto.
● rsize=8192 y wsize=8192 - Pueden acelerar la comunicación NFS tanto para

leer (rsize) como para escribir (wsize), configurando un tamaño de bloque de
datos mayor, en bytes, que serán transferidos de una sola vez. Tenga
cuidado al cambiar estos valores; algunos kernels antiguos de Linux y
tarjetas de red pueden no trabajar bien con grandes tamaños de bloques.
● - Especifica que versión del protocolo NFS usar. Para

nfsvers=2 o nfsvers=3
montar un sistema de archivos NFSv4, utilice como sistema de archivos
nfsv4.
Hay muchas más opciones en la página del manual de mount, incluyendo opciones
para montar sistemas de archivos que no sean NFS.
Resolución de problemas de NFS con portmap
Como portmap proporciona la coordinación entre servicios RPC y los números de

puertos usados para comunicarlos, es útil poder visualizar el estado de los servicios
RPC actuales usando portmap cuando estamos resolviendo algún problema. El
comando rpcinfo muestra cada servicio basado en RPC con su número de puerto,
número de programa RPC, versión y tipo de protocolo (TCP o UDP).
Para asegurarse que los servicios NFS basados en RPC están activos para
portmap, use el comando rpcinfo -p:
programa vers proto puerto

100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32769 status
100011 1 udp 863 rquotad
100011 2 udp 863 rquotad
100011 1 tcp 866 rquotad
100011 2 tcp 866 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 udp 32770 nlockmgr
100021 1 tcp 32772 nlockmgr
100005 1 udp 32771 mountd
100005 1 tcp 894 mountd
100005 2 udp 32771 mountd
100005 2 tcp 894 mountd
100005 3 udp 32771 mountd
100005 3 tcp 894 mountd

La opción -p prueba el portmap de la máquina especificada, o en la máquina local

por defecto si no se especifica ninguna máquina. Otras opciones están disponibles
en la página manual de rpcinfo.
De la salida anterior, varios servicios NFS pueden verse ejecutándose. Si uno de

los servicios NFS no comienza correctamente, portmap puede ser incapaz de
corresponder las peticiones RPC con sus respectivos puertos. En muchos casos,
reiniciando NFS como root con el comando /sbin/service nfs restart, provocará
que estos servicios funcionen correctamente con portmap y empiecen a funcionar.

4
Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP), es un protocolo de red para asignar

automáticamente información TCP/IP a equipos cliente. Cada cliente DHCP se
conecta un servidor DHCP centralizado que devuelve la configuración de red del
cliente, incluida la dirección IP, el gateway y los servidores DNS.
Motivos para usar el protocolo DHCP
DHCP es útil para proporcionar de un modo rápido la configuración de red del

cliente. Al configurar el sistema cliente, el administrador puede seleccionar el
protocolo DHCP y no especificar una dirección IP, una máscara de red, un gateway
o servidor DNS. El cliente recupera esta información desde el servidor DHCP.
DHCP también es útil si un administrador desea cambiar las direcciones IP de
muchos sistemas. En lugar de volver a configurar todos los sistemas, puede
modificar un archivo de configuración DHCP en el servidor para establecer el nuevo
conjunto de direcciones IP. Si los servidores DNS de una organización cambian, los
cambios también se aplicarán en el servidor DHCP, no en todos los clientes DHCP.
Una vez que se reinicie la red en los clientes (o reinicien los clientes), se aplicarán
los cambios.
Además, si un portátil o cualquier tipo de equipo móvil se configura para DHCP,

podrá desplazarse entre distintas oficinas sin tener que volver a configurarlo,
siempre y cuando cada oficina tenga un servidor DHCP que permita su conexión a
la red.
Configuración de un servidor DHCP
Puede configurar un servidor DHCP mediante el archivo de configuración

/etc/dhcpd.conf.
DHCP también usa el archivo /var/lib/dhcpd/dhcpd.leases para almacenar la base

de datos de arrendamiento de clientes.
Archivo de configuración
El primer paso al configurar un servidor DHCP es crear el archivo de configuración

que almacena la información de red de los clientes. Se pueden declarar opciones
globales para todos los clientes, o bien opciones para cada sistema cliente.
El archivo de configuración puede contener tabulaciones o líneas en blanco

adicionales para facilitar el formato. Las palabras clave no distinguen entre

mayúsculas y minúsculas, y las líneas que empiezan con una almohadilla o
símbolo numeral (#) se consideran comentarios.
DHCP puede interactuar con DNS para actualizar el archivo de zona DNS una vez
entregada una dirección IP a un host. Este proceso se conoce como DNS dinámico
o DDNS (Dynamic DNS).
Si no utilizará DDNS, añada la siguiente línea al inicio del archivo de configuración:

ddns-update-style none;
El archivo de configuración posee dos tipos de información:
• Parámetros - Establece cómo se realiza una tarea, si debe llevarse a cabo una
tarea o las opciones de configuración de red que se enviarán al cliente.
• Declaraciones - Describen la topología de la red, describen los clientes,

proporcionan direcciones para los clientes o aplican un grupo de parámetros a
un grupo de declaraciones.
Algunos parámetros deben empezar con la palabra clave option. Algunas opciones
configuran DHCP y los parámetros definen valores no opcionales o que controlan el
comportamiento del servidor DHCP.
Los parámetros (incluidas las opciones) declarados antes de una sección

encerrada entre llaves { } se consideran parámetros globales. Los parámetros
globales se aplican a todas las secciones situadas debajo de ellos.
Si cambia el archivo de configuración, los cambios no se aplicarán hasta reiniciar el

demonio DHCP con el comando service dhcpd restart.
Un ejemplo de configuración del archivo dhcpd.conf puede encontrarse en el

directorio /usr/share/doc/dhcp-<número-versión>/dhcpd.conf.sample . Puede copiar
este archivo como /etc/dhcpd.conf y editarlo para adecuarlo a sus necesidades.
En este ejemplo, hay opciones globales para cada cliente DHCP en la subred y un
rango declarado. A los clientes se les asigna una dirección IP dentro del rango.
Ejemplo de declaración de Subred:

subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option subnet-mask 255.255.255.0;
option domain-name "linux.com.py";
option domain-name-servers 192.168.1.1;
option time-offset -14400; #
range 192.168.1.10 192.168.1.100;
}

Parámetro Range (Rango)
Para configurar un servidor DHCP para que responda a solicitudes de direcciones

IP en una subred, modifique el ejemplo con los valores pertinentes. Declara un
tiempo de lease por defecto, un tiempo de lease máximo y los valores de
configuración de red para los clientes. Este ejemplo asigna una dirección IP en el
rango 192.168.1.10 y 192.168.1.100 a los sistemas cliente:
ddns-update-style none
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option ntp-servers 192.168.1.1;
option domain-name "linux.com.py";
option netbios-name-servers 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
option time-offset -14400;
}
Dirección IP estática con DHCP
Para asignar una dirección IP a un cliente según la dirección MAC de la tarjeta de

interfaz de red, use el parámetro hardware ethernet dentro de la declaración host.
Como se muestra en el ejemplo, la declaración host apex especifica que la interfaz
de red con una dirección MAC 00:A0:78:8E:9E:AA siempre recibe la dirección IP
192.168.1.4.
Tenga en cuenta que también puede usar el parámetro opcional host-name para
asignar un nombre host al cliente.
host apex {
option host-name "apex.linux.com.py";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.4;
}
Base de datos de arrendamiento
En el servidor DHCP, el archivo /var/lib/dhcp/dhcpd.leases almacena la base de

datos de arrendamiento del cliente DHCP. Este archivo no debe modificarse
manualmente. La información sobre arrendamiento de DHCP de cada dirección IP
asignada recientemente se almacena de modo automático en la base de datos de

arrendamiento. La información incluye la longitud del arrendamiento, a quién se ha

asignado la dirección IP, las fechas iniciales y finales de la renta, y la dirección
MAC de la tarjeta de interfaz de red utilizada para recuperar el arrendamiento.
Arranque y parada del servidor
Para arrancar el servicio DHCP, use el comando /sbin/service dhcpd start. Para
detener el servidor DHCP, use el comando /sbin/service dhcpd stop.
Si tiene más de una interfaz de red conectada al sistema, pero sólo desea que el
servidor DHCP arranque en una de las interfaces, puede configurar el servidor
DHCP para que sólo arranque en ese dispositivo. En /etc/sysconfig/dhcpd, agregue
el nombre de la interfaz a la lista de DHCPDARGS:
# Command line options 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:
● La directiva INTERFACES indica en que interfaces se escucharán solicitudes

DHCP.
● La directiva DHCPSERVERS especifica la lista de servidores DHCP a los cuales

se reenviarán las solicitudes.

Por ejemplo el archivo /etc/sysconfig/dhcrelay tendría el siguiente formato:
INTERFACES=""
DHCPSERVERS="10.42.42.2"
Luego inicie el servicio utilizando el siguiente comando:

# service dhcrelay start

5
Interconexión con Windows - SAMBA

SAMBA es una conjunto de programas, originalmente creados por Andrew Tridgell

y actualmente mantenidos por The SAMBA Team, bajo la Licencia Publica General
GNU, y que implementan en sistemas basados sobre UNIX el protocolo Server
Message Block (o protocolo SMB). Este es algunas veces referido también como
Common Internet File System (CIFS), LanManager o protocolo NetBIOS. Sirve
como reemplazo total para Windows NT, Warp, NFS o servidores Netware.
Configuración de 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 = LINUX
Opcionalmente, estableceremos el nombre NetBIOS de la máquina, si no se

configura uno, toma por defecto el nombre de host:

netbios Name = Serv1
Para permitir que las impresoras configuradas en Linux sean automáticamente

compartidas a través de SAMBA, configure las siguientes opciones:
load printers = 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

autenticar los usuarios, el valor por defecto y mas comúnmente usado es user. Los
valores pueden ser:
● security = share -Utilice este modelo de seguridad si desea definir recursos

compartidos que no requieran de una contraseña de acceso (acceso de
invitado). Este modelo de seguridad es normalmente utilizado para
servidores de impresión.
● security = user -Si el nombre de usuario de sus estaciones de trabajo es el

mismo que el nombre de usuario de Unix, entonces utilice este modelo de
seguridad. Los usuarios deben autenticarse para acceder al recurso
compartido. También es posible definir distintos permisos de acceso para
cada usuario o grupo de usuarios. Este modelo requiere que los usuarios
esten creados tanto en el sistema operativo como en la base de datos de
usuarios del SAMBA.
● security = domain - Cuando se utiliza este modelo de seguridad, el servidor

samba tiene una una cuenta de equipo en el dominio Windows y provoca
que todas las solicitudes de autenticación sean validadas por controladores
de dominio. En otras palabras, esto convierte a samba en un servidor
miembro.

● security = ADS - Si cuenta con un entorno de Directorio Activo de Windows,

es posible unir a samba como un servidor miembro nativo de Directorio
Activo. El servidor SAMBA puede unirse al dominio utilizando Kerberos.
● security = server - Su utilización no es recomendada y se utilizaba

previamente cuando samba no podía pertenecer a un dominio Windows.
A menos que tenga un controlador de dominio Windows, para poder controlar el

acceso a los recursos compartidos por usuario deberá configurar:
security = user
passdb backend = tdbsam
Recuerde que al utilizar la seguridad por usuario, debe crear cada usuario que
desea autenticar en el sistema operativo con el comando adduser, y luego en el
samba con el comando pdbedit -a.Además, nalmente el nombre de inicio de sesión
en Windows debe ser igual al del usuario que usted ha creado para ese equipo.
El comando pdbedit se utiliza de la siguiente forma:
● Agregar usuario - pdbedit -a <usuario>
● Deshabilitar usuario - pdbedit -r -c "[D]" <usuario>
● Habilitar usuario - pdbedit -r -c "[]" <usuario>
● Eliminar usuario - pdbedit -x <usuario>
● Establecer la contraseña a nulo - pdbedit -r -c "[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 búsqueda LMHOSTS, si se habilita DNS para resolución NetBIOS,
etc.
En el caso que no se utilice un servidor WINS, toso los registros de nombres y las
búsquedas son realizadas a través de broadcast UDP. Esto aísla la resolución de
nombres a la subred local a menos que se utilice LMHOSTS para listar todos los
nombres y las direcciones IP. Si se utiliza un servidor WINS, el cliente Windows
utilizará UDP unicast para registrarse con el servidor WINS. Este paquete puede
ser ruteado por tanto WINS permite la resolución de nombres entre redes ruteadas.
Durante el proceso de inicio, una elección se lleva a cabo para crear un Local
Master Browser (LMB) si no existe uno. En cada red NetBIOS una máquina será
electa para funcionar como el “Domain Master Browser” (DMB). El DMB contacta a
cada LMB e intercambia el contenido de la lista de navegación de red, esto permite
la navegación entre redes ruteadas. Cada 11 a 15 minutos una elección es
mantenida para determinar quien será el “master browser”. Por la naturaleza del

criterio de elección, la máquina con mayor tiempo encendida y la versión de

protocolo superior entre otros criterios, ganara la elección como DMB.
Los clientes que desean navegar la red hacen uso de esta lista, cualquier cambio
en la resolución de nombres o fallo del LMB molestará a los usuarios debido a que
temporalmente no podrán navegar la red.
Por tanto, siempre es recomendada la utilización de un servidor WINS.
De ser necesario, puede especificar que el servidor sea el LMB, e incluso

sobreponerse a cualquier otro en la red.
domain master = 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]
comment = ALL Printers.
path = /var/spool/samba
printable = yes
browseable = no
printable = yes
guest ok = no # Configure a yes si desea que la cuenta invitado imprima

writable = no
Para los directorios o volúmenes que se irán a compartir, en el mismo fichero de

configuración encontrará distintos ejemplos para distintas situaciones particulares.
Para crear un recurso compartido:
● El nombre del recurso compartido por el cual accederán las máquinas se

encuentra entre corchetes.
● Si lo desea, puede agregar un comentario con la opción comment.
● Luego debe especificar la ruta al directorio compartido utilizando la opción

path
● Indique las opciones para el recurso compartido, tales como si será de

acceso público, de sólo lectura, escritura para ciertos usuarios o grupos o de
acceso restringido.
Ejemplos de recursos compartidos:

# Este ejemplo es util para personas que desean compartir archivos
[tmp]
comment = Directorio de archivos temporales
path = /tmp
read only = no
public = yes
# Un directorio público donde todos acceden en modo sólo lectura excepto por los
# miembros del grupo staff y el usuario fsadmin.
[public]
comment = Directorio publico
path = /app/archivos
public = yes
read only = yes
write list = @staff fsadmin
# Un directorio compartido al cual sólo puede acceder el usuario fred.

[freddir]
comment = Directorio de fred
path = /usr/home/fred/privado
valid users = fred
public = no
writable = yes
Hecho todo lo anterior, solo resta iniciar el demonio correspondiente a fin de que
cargue los nuevos parámetros configurados. Si iniciará SAMBA por primera vez
ejecute lo siguiente:
# /sbin/service smb start
Si va a reiniciar el servicio, ejecute lo siguiente:

# /sbin/service smb restart

Por último, asegúrese de que SAMBA iniciará automáticamente cada vez que inicie
el servidor. Puede hacerlo fácilmente desde una consola ejecutando el siguiente
comando:
/sbin/chkconfig smb on
No olvide sincronizar las cuentas entre el servidor GNU/Linux y las estaciones con
Windows. Es decir, si en una máquina con Windows ingresamos como el usuario
"jperez" 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 pdbedit.
# /usr/sbin/useradd <usuario>
# /usr/bin/pdbedit -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/pdbedit -a <usuario>
Ejemplo de un fichero de configuración de SAMBA

# Parámetros globales
[global]
workgroup = LINUX
netbios name = Serv1
server string = Servidor de Archivos
interfaces = 192.168.1.254/24
encrypt passwords = Yes
log file = /var/log/samba/%m.log
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
domain logons = Yes
domain master = True
preferred master = yes
dns proxy = No
wins support = Yes
remote announce = 192.168.1.255
hosts allow = 192.168.1. 127.
load printers = yes
printing = cups
# Recursos compartidos
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
browseable = No
[printers]

comment = All Printers

path = /var/spool/samba
guest ok = yes
printable = yes
browseable = no
[FTP]
comment = Directorio del servidor FTP
path = /var/ftp/pub
read only = no
guest ok = yes
Accediendo a recursos SAMBA
Indudablemente el método más práctico y seguro es el comando smbclient. Este

permite acceder hacía cualquier servidor Samba o Windows como si fuese el
comando ftp en modo texto.
Para acceder al cualquier recurso de alguna máquina Windows o servidor SAMBA

determine primero que volúmenes o recursos compartidos posee está. utilice el
comando smbclient del siguiente modo:
# smbclient -U <usuario> -L //<host>

# smbclient -L //<host> -N
Por ejemplo:
# smbclient -L //localhost -N
Lo cual le devolvería más menos lo siguiente:

added interface ip=192.168.1.254 bcast=192.168.1.255 nmask=255.255.255.0
Anonymous login successful
Domain=[LINUX] OS=[Windows]
Sharename Type Comment

--------- ----- -------
publico Disk Directorio Publico
HPDeskjet Printer
Workgroup Master
--------- -------
LINUX Serv1
La siguiente corresponde a la sintaxis básica para poder navegar los recursos

compartidos por la máquina Windows o el servidor SAMBA:
# smbclient //host/recurso -U usuario
Ejemplo:
# smbclient //serv1/publico -U jperez

Después de ejecutar lo anterior, el sistema solicitará se proporcione la contraseña

del usuario jperez en el equipo denominado Serv1.
# smbclient //serv1/publico -U jperez
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 jperez, plopez y hgomez del grupo admin, deben escribir en
el recurso compartido, sin embargo, todos los demás usuarios deben poder
acceder al recurso compartido, con permisos de solo lectura.
Usted debe crear un directorio con el nombre que desee, utilizando el comando
correspondiente:
# mkdir -p /programas/aplicaciones
Otorgue a los miembros del grupo admin todos los permisos y a todos los usuarios
del sistema los permisos de lectura y ejecución. Establezca el permiso SGID para
permitir que los archivos creados en el directorio hereden el grupo propietario del
directorio:
# chown root.admin /programas/aplicaciones
# chmod 2775 /programas/aplicaciones
Luego debe agregar los usuarios y grupos al sistema operativo:

# groupadd admin
# useradd jperez -G admin
# useradd plopez -G admin
# useradd hgomez -G admin
Debe agregar el usuario al SAMBA y configurar su contraseña:

# pdbedit -a jperez
# pdbedit -a plopez
# pdbedit -a hgomez
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
public = yes
writable = no
write list = @admin
directory mask = 2775
create mask = 664
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 envía 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 jperez
Si desea montar el recurso compartido desde un cliente Linux ejecute:

# mount -t cifs //Serv1/Aplicaciones \
-o username=jperez,password=<contraseña> /mnt/aplicaciones

6
Servidor proxy/cache Squid

Un servidor proxy es un servidor que responde a las peticiones de clientes

reenviando estas peticiones a otros servidores. Un cliente se conecta al servidor
proxy, solicitando algún servicio, como una página web. El servidor proxy
proporciona el recurso solicitado conectándose al servidor indicado y solicitando la
petición en nombre del cliente.
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.
Además de funcionar como proxy, también actúa como cache, almacenando

determinados objetos de Internet en el disco local. Los clientes pueden utilizar el
cache de Squid reduciendo el tiempo de acceso y el consumo de ancho de banda.
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 como mínimo deberá configurar los siguientes:
• El parametro http_port
• El parametro cache_mem
• El parametro ftp_user
• El parametro cache_dir

• Al menos una Lista de Control de Acceso
• Al menos una Regla de Control de Acceso
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
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.
Como regla general, Squid utiliza aproximadamente 10 MB de RAM por GB del

total de todos los cache_dir especificados, más el valor de cache_mem y unos 10-20
MB adicionales. Es recomendado que tenga al menos el doble de esta cantidad de
memoria en el servidor Squid.
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. Puede especificar múltiples cache_dir para distribuir el

cache entre diferentes particiones de disco. Para entender esto un poco mejor,
responda a esta pregunta: ¿Cuanto desea almacenar de Internet en el disco duro?
Por defecto Squid utilizará un cache de 100 MB, de modo tal que encontrará la
siguiente línea:
cache_dir ufs /var/spool/squid 100 16 256
Se puede incrementar el tamaño del cache hasta donde lo desee el administrador.

Mientras más grande el cache, más objetos de almacenarán en éste y por lo tanto
se utilizará menos el ancho de banda. La siguiente línea establece un cache de 3
GB:
cache_dir ufs /var/spool/squid 3096 16 256
Los números 16 y 256 significan que el directorio del cache contendrá 16

subdirectorios con 256 niveles cada uno. No modifique esto números, no hay
necesidad de hacerlo.
Es muy importante considerar que si se especifica un determinado tamaño de

cache y este excede al espacio real disponible en el disco duro, Squid se bloqueará
inevitablemente. Sea cauteloso con el tamaño de cache especificado. Si desea
utilizar todo un sistema de archivos para cache, reste 20 % del total.
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 proxy@linux.com.py
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.
Regularmente una lista de control de acceso se establece siguiendo la siguiente

sintaxis:
acl <nombre de la lista> <tipo de lista> <componentes de lista>
El tipo de lista determina los componentes de ella, por ejemplo, es posible indicar
que la lista esta compuesta de direcciones IP utilizando el tipo de lista src/dst,

dominios de Internet utilizando el tipo de lista srcdom_regex/dstdom_regex o rangos de

tiempo si la lista es de tipo time.
Si uno desea establecer una lista de control de acceso que defina sin mayor trabajo
adicional a toda la red local definiendo la IP que corresponde a la red y la máscara
de la sub-red. Por ejemplo, si se tienen una red donde las máquinas tienen
direcciones IP 192.168.1.0 con máscara de subred 255.255.255.0, podemos utilizar
lo siguiente:
acl our_networks src 192.168.1.0/255.255.255.0
También puede definirse una Lista de Control de Acceso invocando un fichero

localizado en cualquier parte del disco duro, y en el cual se en cuenta una lista de
direcciones IP. Ejemplo:
acl permitidos src "/etc/squid/permitidos"
El fichero /etc/squid/permitidos contendría algo como siguiente:
192.168.1.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.
Para definir una lista que permita el control de acceso por hora del día, puede
definir una lista de control de acceso como sigue:
acl mediodia time SMTWHFA 12:00-14:00
El nombre de la lista de control de acceso es mediodia, el tipo es time, se aplica de

lunes a domingo (SMTWHFA) de 12 a 14 horas (12:00-14:00).
Reglas de Control de Acceso
Estas definen si se permite o no el acceso a Squid. Se aplican a las Listas de

Control de Acceso. Deben colocarse en la sección de reglas de control de acceso
definidas por el administrador, es decir, a partir de donde se localiza la siguiente
leyenda:
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
La sintaxis básica es la siguiente:

http_access [deny o allow] [lista de control de acceso]
En el siguiente ejemplo consideramos una regla que establece acceso permitido a

Squid a la Lista de Control de Acceso denominada permitidos:
http_access allow permitidos
También pueden definirse reglas valiéndose de la expresión !, la cual significa

excepción. Pueden definirse, por ejemplo, dos listas de control de acceso, una
denominada lista1 y otra denominada lista2, en la misma regla de control de
acceso, en donde se asigna una expresión a una de estas. La siguiente establece
que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que
comprenda lista2:
http_access allow lista1 !lista2
Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un
rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al
que se debe denegar el acceso.
Para permitir el acceso a Internet en el horario indicado por la lista “mediodia” a los
equipos de la red local, deberá establecer como regla:
http_access allow mediodia our_networks
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 soporte@linux.com.py
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
padres y hermanos trabajando en conjunto en una red local. Ejemplo:
cache_peer 10.0.0.1 parent 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
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:
# 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 Firefox, 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 3128, se utiliza la siguiente línea:
/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
-j REDIRECT --to-port 3128
Estableciendo el idioma por defecto
Squid incluye traducción a distintos idiomas de las distintas páginas de error e

informativas que son desplegadas en un momento dado. Dichas traducciones se
pueden encontrar en /usr/lib/squid/errors/. Para poder hacer uso de las páginas
de error traducidas al español, es necesario cambiar un enlace simbólico localizado
en /etc/squid/errors para que apunte hacia /usr/lib/squid/errors/Spanish en lugar
de hacerlo hacia /usr/lib/squid/errors/English.
Elimine primero el enlace simbólico actual:

# rm -f /etc/squid/errors
Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros
correspondientes a los errores traducidos al español.
ln -s /usr/share/squid/errors/Spanish /etc/squid/errors
Iniciando el servicio al arranque del sistema
Una vez terminada la configuración, ejecute el siguiente comando para iniciar por
primera vez Squid:
service squid start
Si necesita reiniciar para probar cambios hechos en la configuración, ejecute lo

siguiente:
service squid restart
Si desea que Squid inicie de manera automática la próxima vez que inicie el
sistema, ejecute lo siguiente:
/sbin/chkconfig squid on
Depuración de errores

Cualquier error al inicio de squid solo significa que hubo errores de sintaxis, errores
de dedo o bien se están citando incorrectamente las rutas hacia los ficheros de las
Listas de Control de Acceso.
Puede realizar diagnóstico de problemas revisando los registros del servidor squid
en el directorio /var/log/squid.

7
Very Secure FTP Daemon (VSFTPD)


El protocolo de transferencia de archivos (File transfer protocol) ftp es el mas
antiguo y confiable método de transferencia de archivos y es utilizado ampliamente
en las organizaciones actualmente. El demonio Very Secure FTP Daemon (vsftpd)
es uno de los servidores FTP mas popular y robusto disponible para la comunidad
Linux. El servidor vsftpd tiene una prioridad desde su diseño, reforzar los
requerimientos de seguridad. El servidor puede operar en una jaula chroot y ahora
soporta encriptación TLS/SSL (desde la version 2).
La configuración instalada inicialmente provee acceso para descarga a usuarios

anónimos. Esta sección cubrirá algunos parámetros básicos de configuración del
servidor y como aumentar la seguridad para permitir usuarios autorizados
solamente. También se dara una mirada a como habilitar la encriptación TLS/SSL
para proveer un nivel de seguridad para la transferencia de archivos. Las
extensiones de seguridad FTP son discutidas en RFC2228.
Configuración inicial
El archivo de configuración /etc/vsftpd/vsftpd.conf por defecto esta perfectamente

adaptado para permitir acceso seguro anónimo y es un buen punto para comenzar
las personalizaciones. Antes de modificar el archivo de configuración, haga una
copia del archivo actual.
Para desplegar un mensaje de bienvenida cada vez que un usuario se conecta,

configure el parámetro banner_file y cree un mensaje de bienvenida dentro del
archivo especificado.
banner_file=/etc/vsftpd/vsftpd.welcome
El parámetro ftpd_banner le permite configurar rápidamente una linea de bienvenida

para los usuarios que se conectan.
ftpd_banner=Bienvenido al servidor FTP.
Si ambos parámetros están habilitados, banner_file es desplegado antes que

ftpd_banner.
Es posible personalizar el mensaje mostrado a medida que los usuarios van

navegando por los directorios con el parámetro message_file. Este mensaje puede
mostrar un resumen del contenido del directorio o la función de los archivos
ubicados en él.
message_file=.message
El servidor vsftpd puede ejecutarse en modo independiente o a través de

inetd/xinetd. Para habilitar el modo independiente, configure el parámetro listen.

listen=YES
El parámetro umask define los permisos por defecto cuando se suben archivos al
servidor FTP. El parámetro anon_umask determina los permisos por defecto para
archivos subidos por usuarios anónimos y local_umask determina los permisos por
defecto para archivos subidos por usuarios locales.
anon_umask=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 vsftpd on
# chkconfig –list
El servicio puede ser iniciado o reiniciado inmediatamente, usando los siguientes

comandos:
# service vsftpd start

# service vsftpd restart
Control de acceso de los usuarios
En el estado inicial de la configuración del servidor vsftpd, se permite acceso de

descarga a los usuarios anónimos. Para aumentar la seguridad, es necesario
realizar ajustes a la configuración del servidor.
Usuarios anónimos
Para deshabilitar el acceso anónimo de usuarios, configure el parámetro

anonymous_enable a NO, es importante destacar que no es suficiente con simplemente
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.

Si desea que por defecto, a todas las cuentas de usuario se deniegue el acceso ftp,
excepto a los explícitamente 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 estén listados en el archivo especificado
en el parámetro userlist_file.
La opción userlist_enable especifica el archivo a ser leído cuando la opción

userlist_enable 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 permitirá acceso anónimo, el

proceso de encriptación es una carga adicional a los recursos del servidor y

debería ser habilitado solo si es realmente necesario.
Para habilitar TLS/SSL, la versión de vsftpd debe haber sido compilada con soporte
TLS/SSL. Para identificar si la versión ha sido compilada con soporte SSL, ejecute
el siguiente comando:
# ldd /usr/sbin/vsftpd
Si el comando despliega la biblioteca libssl como resultado, entonces la versión

soporta TLS/SSL.
Antes de poder usar TLS/SSL, requiere de la generación de una clave privada y un

certificado digital. Durante la generación de la clave, se solicitará información
acerca del nombre del servidor, nombre de la organización, contacto y código de
país.
Ejecute los siguientes comandos para generar la clave y el certificado digital:

# cd /etc/pki/tls/certs
# make vsftpd.pem
El contenido del archivo debe ser verificado para asegurarse que existe la clave
privada y el certificado digital.
Para examinar el archivo ejecute:

# cat vsftpd.pem
Para examinar el certificado digital ejecute:

# openssl x509 -in vsftpd.pem –noout -text
Debera asegurar los permisos del certificado, de tal forma a que solo el usuario root
tenga acceso, para ello ejecute el siguiente comando:
# chmod 600 vsftpd.pem
Mueva el archivo generado al directorio /etc/vsftpd
# mv vsftpd.pem /etc/vsftpd
El archivo de configuración ahora debe ser modificado para incluir el soporte de

encriptación TLS/SSL. Los parámetros que deberá configurar son:
# Si ssl_enable esta habilitado y vsftpd fue compilado con OpenSSL, vsftpd
# soportará conexiones via SSL. Necesitará un cliente con soporte SSL también.
ssl_enable=YES
# El parametro allow_anon_ssl si es configurado a YES, se permitira conexiones

# aseguradas con SSL a los usuarios anonimos.
allow_anon_ssl=NO

# Si se activa el parametro force_local_data_ssl todas las conexiones no anonimas

# seran forzadas al uso de una conexión segura SSL para la transferencia de datos.
force_local_data_ssl=NO
# Si se activa el parametro force_local_login_ssl todos los inicios de sesion no

# anonimos seran forzados a usar SSL para el envio de la contraseña.
force_local_logins_ssl=YES
# Permitimos conexiones TLS V1
ssl_tlsv1=YES
# Las conexiones TLS son preferidas, por tanto se deshabilitan las conexiones
# SSL v2 y SSL v3.
ssl_sslv2=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”.

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 CentOS Linux, servidor
DNS Berkeley Internet Name Domain (BIND), con énfasis en la estructura de sus
archivos de configuración y en cómo deberían ser administrados localmente y
remótamente.
Si utiliza la Herramienta de configuración de Bind system-config-bind, no edite

manualmente ningún archivo de configuración BIND pues todos los cambios serán
sobreescritos la próxima vez que utilice la Herramienta de configuración de Bind.
Introducción a DNS
Cuando hosts en una red se conectan a través de sus nombres de máquinas,

también llamado nombre de dominio completamente cualificado (FQDN), DNS es
usado para asociar los nombres de las máquinas a las direcciones IP para el host.
El uso de nombres de un dominio completamente cualificado y DNS tiene ventajas

para los administradores del sistema, éstos dan a los administradores flexibilidad a
la hora de cambiar las direcciones IP para máquinas individuales sin realizar
preguntas sobre el nombre en las máquinas. Por otro lado, los administradores
pueden revolver cuáles máquinas manejan consultas basadas en nombre .
DNS es normalmente implementado usando servidores centralizados que autorizan

algunos dominios y se refieren a otros servidores DNS para otros dominios.
Cuando un host cliente solicita información desde un servidor de nombres,

usualmente se conecta al puerto 53. El nombre de servidor luego intenta resolver el
FQDN basado en su librería de resolución, la cual puede contener información de
autorización sobre el host solicitado o datos en caché de una consulta anterior. Si
el nombre del servidor no tiene la respuesta en su librería de resolución, consultará
otros nombres de servidores, llamados servidores de nombres de root, para
determinar cuáles servidores de nombres son fidedignos para el FQDN en
cuestión. Luego, con esa información, consulta los servidores de nombres
autoritarios para determinar la dirección IP del host solicitado. Si se está realizando
una búsqueda inversa, se usa el mismo procedimiento, excepto que la consulta es
realizada con una dirección IP desconocida en vez de un nombre.

Zonas de servidores de nombres
En Internet, el FQDN de un host se puede analizar en diversas secciones y estas

secciones se analizan a su vez por orden jerárquico, como en un árbol el tronco,
las ramas primarias, las ramas secundarias, etc. Por ejemplo, considere el
siguiente FDNQ:
update.linux.com.py
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, py define el
dominio de nivel superior para este FQDN. El nombre com es un subdominio bajo
com, mientras que linux es un subdominio bajo com. 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 almacenados en servidores de nombres primarios
(también llamados servidores de nombres maestro), los cuales son
verdaderamente autorizados y donde los cambios se hacen a los archivos, y
servidores de nombres secundarios (también llamados servidores de nombres
esclavos), que reciben sus archivos de zona desde los servidores de nombres
primarios. Cualquier servidor de nombres puede ser un servidor primario y
secundario para zonas diferentes al mismo tiempo, y también pueden ser
considerados autoritarios para múltiples zonas. Todo depende de cómo se
configure el servidor de nombres.

Tipos de zonas de los servidores de nombres
Existen cinco tipos de configuración de zonas en servidores de nombres de

dominio:
● master (maestro) - Almacena los registros de las zonas originales y de

autoridad para un cierto espacio de nombres, contestando preguntas de
otros servidores de nombres buscando respuestas concernientes a ese
espacio de nombres.
● slave (esclavo) - Responde a las peticiones que provienen de otros

servidores de nombres y que se refieren a los espacios de nombres sobre
los que tiene autoridad. Sin embargo, los servidores esclavos obtienen la
información de sus espacios de nombres desde los servidores maestros.
Mantiene una copia de solo lectura de los registros almacenados en una
zona maestra. Es utilizada para tolerancia a fallos.
● stub - Es parecida al servidor esclavo, excepto que replica 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.
Consultas iterativas y recursivas
Cuando un cliente DNS necesita buscar un nombre que se utiliza en un programa,

por ejemplo, www.linux.com.py, consulta los servidores DNS para resolver el
nombre.
Una consulta puede ser iterativa o recursiva.
● Una consulta recursiva es aquella realizada a un servidor DNS en la que un

cliente solicita al servidor DNS que proporcione una respuesta completa a la

consulta.
● Una consulta iterativa es aquella efectuada a un servidor DNS en la que el

cliente DNS solicita la mejor respuesta que el servidor DNS puede
proporcionar sin buscar ayuda adicional de otros servidores DNS. El
resultado de una consulta iterativa normalmente es una referencia a otro
servidor DNS de nivel inferior en el árbol DNS.
BIND como un servidor de nombres
BIND realiza la resolución de nombres a través del demonio /usr/sbin/named. BIND

también incluye una utilidad de administración llamada /usr/sbin/rndc.
BIND almacena sus archivos de configuración en los siguientes dos lugares:
● /etc/named.conf - El archivo de configuración para el demonio named.
● /var/named/ o /var/named/chroot/var/named - El directorio de trabajo named el

cual almacena zonas, estadísticas y archivos caché.
El servicio named puede ejecutarse en un entorno enjaulado (chroot). Esto

proporciona mayor seguridad debido a que el demonio no puede acceder al
sistema de archivos raíz real, en lugar de ello, se genera un sistema de archivos
raíz alternativo para la ejecución del servicio. Si el servicio es explotado, no podrá
obtener datos del sistema de archivos real.
La ejecución de named en entorno enjaulado es controlado por el archivo

/etc/sysconfig/named. El archivo por defecto está configurado para ejecutarse en

entorno enjaulado:
ROOTDIR=/var/named/chroot
Para evitar que named se ejecute en un entorno enjaulado comente esa línea.
Las próximas secciones revisan los archivos de configuración de BIND en más

detalle. Si named se ejecuta en entorno enjaulado, la ruta a todos los archivos
mencionados son relativas al directorio ROOTDIR.
El archivo /etc/named.conf
El archivo named.conf es una colección de declaraciones usando opciones anidadas

rodeadas por caracteres de llaves, { }. Los administradores deben tener mucho
cuidado cuando estén modificando named.conf para evitar errores sintácticos puesto
que hasta el error más pequeños puede impedir que el servicio named arranque.
No modifique manualmente el archivo /etc/named.conf o cualquier archivo en el

directorio /var/named/ si está usando la Herramienta de configuración de Bind
system-config-bind. Cualquier cambio manual a esos archivos serán sobreescritos
la próxima vez que se use Herramienta de configuración de Bind.
Un archivo típico de named.conf está organizado de forma similar al ejemplo

siguiente:
<declaracion> {
<opcion-1> {valor; [valor]...};
};
Etiquetas de comentarios
La siguiente es una lista de las etiquetas de comentarios válidas usadas dentro de

named.conf:
● // — Cuando se coloca al comienzo de una línea, esa línea es ignorada por

named.
● # — Cuando se coloca al comienzo de una línea, esa línea es ignorada por

named.
● /* y */ — Cuando el texto se coloca entre estas etiquetas, se ignora el

bloque de texto por named.

Declaración acl
La sentencia acl (o sentencia de control de acceso) define grupos de hosts a los

que se les puede permitir o negar el acceso al servidor de nombres.
Una declaración acl tiene la siguiente forma:
acl <nombre-acl> {
<elemento-de-concordancia>;
[ <elemento-de-concordancia>; ...]
};
En esta declaración, sustituya <nombre-acl> con el nombre de la lista de control de

acceso y reemplace <elemento-de-concordancia> con una lista de direcciones IP
separada por puntos y comas. La mayoría de las veces, una dirección IP individual
o notación de red IP (tal como 10.0.1.0/24) es usada para identificar las direcciones
IP dentro de la declaración acl.
La siguiente lista de control de acceso ya están definidas como palabras claves

para simplificar la configuración:
● any - Hace coincidir todas las direcciones IP.
● localhost - Hace coincidir cualquier dirección IP que se use el sistema local.
● localnets - Hace coincidir cualquier dirección IP en cualquier red en la que

el sistema local está conectado.
● none - No concuerda ninguna dirección IP.
Cuando lo utilice con otras pautas (tales como declaraciones options), las
declaraciones acl pueden ser muy útiles al asegurar el uso correcto de su servidor
de nombres BIND.
El ejemplo siguiente define dos listas de control de acceso y utiliza una declaración
options para definir cómo son tratadas en el servidor de nombres:
acl black-hats {
10.0.2.0/24;
192.168.0.0/24;
};
acl red-hats {
10.0.1.0/24;
};
options {
blackhole { black-hats; };
allow-query { red-hats; };
allow-recursion { red-hats; };
}

Este ejemplo contiene dos listas de control de acceso, black-hats y red-hats. Los
hosts en la lista black-hats se les niega el acceso al servidor de nombres, mientras
que a los hosts en la lista red-hats se les da acceso normal.
Declaración include
La declaración include permite incluir archivos en un named.conf. De esta forma los

datos de configuración confidenciales (tales como claves) se pueden colocar en un
archivo separado con permisos de restricción.
Una declaración include tiene la forma siguiente:
include "<nombre-archivo>"
En esta declaración, <nombre-archivo> es reemplazado con una ruta absoluta a un

archivo. Por ejemplo:
include “/etc/named.root.hints”
Con esta declaración estamos indicando que se debe incluir el archivo de

named.root.hints como parte del archivo de configuración named.conf.
Declaración options
La declaracion options define opciones de configuración de servidor globales y

configura otras declaraciones por defecto. Puede ser usado para especificar la
ubicación del directorio de trabajo named, los tipos de consulta permitidos y mucho
más.
La declaración options toma la forma siguiente:
options {
<opcion>;
[<opcion>; ...]
};
En esta declaración, las directivas <opcion> son reemplazadas con una opción
válida.
Las siguientes son opciones usadas a menudo:
● allow-query - Especifica cuáles hosts tienen permitido consultar este

servidor de nombres. Por defecto, todos los hosts tienen derecho a
consultar. Una lista de control de acceso, o una colección de direcciones IP
o redes se puede usar aquí para sólo permitir a hosts particulares hacer
consultas al servidor de nombres.

● allow-recursion - Parecida a la opción allow-query, salvo que se aplica a las

peticiones recursivas. Por defecto, todos los hosts están autorizados a
presentar peticiones recursivas en un servidor de nombres.
● Especifica cuáles hosts no tienen permitido consultar al servidor

blackhole -
de nombres.
● directory -Reemplaza el directorio de trabajo named en vez del directorio

predeterminado /var/named.
● forward -Controla el comportamiento de reenvío de una directiva forwarders.

Se aceptan las siguientes opciones:
– first - Indica que los servidores de nombres especificados en la

directiva forwarders sean consultados antes de que named intente resolver
el nombre el mismo.
– only - Indica que named no intente la resolución de nombres él mismo en

el evento de que consultas a los servidores de nombres especificados en
la directiva forwarders fallen.
● forwarders - Especifica una lista de direcciones IP válidas para los

servidores de nombres donde las peticiones se pueden reenviar para ser
resueltas.
Una directiva forwarders se puede ver como:

options {
forwarders { 192.168.10.1; 192.168.10.2; };
};
Una servidor de solo reenvío se configura de la siguiente forma:

options {
forwarders { 192.168.10.1; 192.168.10.2; };
forward only;
};
● listen-on -Especifica la interfaz de red en la cual named escucha por

solicitudes. Por defecto, todas las interfaces son usadas.
De esta forma, si el servidor DNS es también una gateway, BIND se puede

configurar para sólo contestar solicitudes que se originan desde algunas de
las redes.
Una directiva listen-on se puede ver como:
options {
listen-on { 10.0.1.1; };
};

De esta forma, solamente las peticiones que llegan desde la interfaz de red
sirviendo a la red privada (10.0.1.1) serán aceptadas.
● Notify - Controla si named notifica a los servidores esclavos cuando una

zona es actualizada. Acepta las opciones siguientes:
– yes - Notifica a los servidores esclavos.

– no - No notifica a los servidores esclavos.
– explicit - Sólo notifica a los servidores esclavos en una lista also-notify
dentro de una declaración de zona.
● pid-file Especifica la ubicación del archivo del proceso ID creado por named.
● statistics-file Permite especificar la localización alternativa de los archivos

de estadísticas. Por defecto, las estadísticas de named son guardadas al
archivo /var/named/named.stats.
Existen numerosas opciones disponibles, muchas de ellas dependen unas de otras

para poder funcionar correctamente. Consulte el Manual de referencia para el
administrador de BIND 9 y la página del manual para bind.conf para más detalles.
Declaración zone
Una declaración zone define las características de una zona tal como la ubicación
de su archivo de configuración y opciones específicas de la zona. Esta declaración
puede ser usada para ignorar las declaraciones globales options.
Una declaración zone tiene la forma siguiente:
zone domain_name [ ( in | hs | hesiod | chaos ) ] {

type master;
file path_name;
[ forward ( only | first ); ]
[ forwarders { [ ip_addr ; [ ip_addr ; ... ] ] }; ]
[ check-names ( warn | fail | ignore ); ]
[ allow-update { address_match_list }; ]
[ allow-query { address_match_list }; ]
[ allow-transfer { address_match_list }; ]
[ dialup yes_or_no; ]
[ notify yes_or_no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] };
[ ixfr-base path_name; ]
[ pubkey number number number string; ]
};

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

linux.com.py, utilice linux.com.py como el <zone-name> para que sea colocado al final
de los nombres de hosts dentro del archivo de zona linux.com.py.
Las opciones más comunes para la declaración zone incluyen lo siguiente:
● allow-query -Especifica los clientes que se autorizan para pedir información

sobre una zona. Por defecto, todas las peticiones de información son
autorizadas.
● allow-transfer - Especifica los servidores esclavos que están autorizados

para pedir una transferencia de información de la zona. Por defecto, todas
las peticiones se autorizan.
● allow-update - Especifica los hosts que están autorizados para actualizar

dinámicamente la información en sus zonas. Por defecto, no se autoriza la
actualización de la información dinámicamente.
Tenga cuidado cuando autorice a los hosts para actualizar la información de

su zona. No habilite esta opción si no tiene confianza en el host que vaya a

usar. Es mejor que el administrador actualice manualmente los registros de

zona y que vuelva a cargar el servicio named.
● file - Especifica el nombre del archivo en el directorio de trabajo named que

contiene los datos de configuración de zona.
● masters - La opción masters lista las direcciones IP desde las cuales solicitar
información autorizada. Solamente se usa si la zona está definida como tipo
esclavo.
● notify - Controla si named notifica a los servidores esclavos cuando una zona
es actualizada. Acepta las opciones siguientes:
– yes - Notifica a los servidores esclavos.
– No - No notifica a los servidores esclavos.
– Explicit - Solamente notifica a los servidores esclavos especificados en

una lista de also-notify dentro de la declaración de una zona.
● type - Define el tipo de zona. Abajo se muestra una lista de las opciones
válidas:
– forward - Dice al servidor de nombres que lleve a cabo todas las

peticiones de información de la zona en cuestión hacia otros
servidores de nombres. Tradicionalmente, el uso de reenviadores o
forwarders ha sido una propocición al todo o nada. O usa un forwarder
para resolver cualquier consulta que su servidor no puede responder
por si solo, o no se usan forwarders en lo absoluto. Las zonas forward
permiten configurar a su servidor de nombres para usar forwarders
solamente cuando buscan ciertos nombres de dominios.
– hint Tipo especial de zona que se usa para orientar hacia los
-
servidores de nombres root que sirven para resolver peticiones de una
zona que no se conoce. No se requiere mayor configuración que la
establecida por defecto con una zona hint.
– master - Designa el servidor de nombres actual como el que tiene la

autoridad para esa zona. Una zona se puede configurar como tipo master
si los archivos de configuración de la zona residen en el sistema.
– slave -Designa el servidor de nombres como un servidor esclavo para

esa zona. También especifica la dirección IP del servidor de nombres
maestro para la zona.
– stub Actúa como un servidor esclavo, pero solamente replica los

-
registros NS de la zona maestra. Es utilizada principalmente para
delegacion de dominios, en el dominio padre, o cuando el ancho de

banda es limitado para realizar una transferencia completa de la zona.
Otros tipos de declaraciones
La lista siguiente muestra tipos de declaraciones usadas con menos frecuencia

disponibles dentro de named.conf.
● Controls - Configura varios requerimientos de seguridad necesarios para

usar el comando rndc para administrar el servicio named.
● key "<nombre-clave>" - 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 "<valor-clave>" - La clave encriptada.
● Logging - Permite el uso de múltiples tipos de registro, llamados channels.

Usando la opción channel dentro de la declaración logging, se puede
construir un tipo registro personalizado, con su propio nombre de archivo
(file), tamaño límite (size), versión (version), y nivel de importancia
(severity). Una vez que se haya definido el canal personalizado, se usa una
opción category para clasificar el canal y comenzar a conectar cuando se
reinicie named.
Por defecto, named registra mensajes estándar al demonio syslog, que les
sitúa en /var/log/messages. Esto se debe a que varios canales estándares se
encuentran incorporados a BIND junto con varios niveles de severidad, tales
como uno que maneja la información de mensajes de registros
(default_syslog) y otro que maneja mensajes de depuración (default_debug).
Una categoría por defecto, llamada default, usa los canales incorporados
para hacer conexiones normales sin ninguna configuración especial.
● view "<nombre-vista>" — Crea vistas especiales dependiendo de en qué red

esté el host que contacta el servidor de nombres. Esto permite a
determinados hosts recibir una respuesta que se refiere a una zona
particular mientras que otros hosts reciben información completamente
diferente. Alternativamente, algunas zonas puede que sólo estén disponibles
para ciertos hosts de confianza mientras que otros hosts menos autorizados,
sólo pueden hacer peticiones a otras zonas.
Se pueden usar múltiples visualizaciones, siempre y cuando sus nombres

sean únicos. La opción match-clients especifica las direcciones IP que
aplican a una vista particular. Cualquier declaración de options puede
también ser usada dentro de una vista, ignorando las opciones globales ya

configuradas por named. La mayoría de las sentencias view contienen

múltiples declaraciones zone que aplican a la lista match-clients. El orden en
que las sentencias view son listadas es importante, pues la primera
sentencia view que coincida con una dirección IP de cliente particular es
usada.
Ejemplo de declaraciones de zone
La mayoría de los cambios al archivo /etc/named.conf de un servidor de nombres

maestro o esclavo envuelven agregar, modificar o borrar declaraciones zone.
Mientras que estas declaraciones zone pueden contener muchas opciones, la
mayoría de los servidores de nombres requieren sólo un pequeño subconjunto para
funcionar efectivamente. Las siguientes declaraciones zone son ejemplos muy
básicos que ilustran la relación de servidores de nombres maestro-esclavo.
A continuación se muestra un ejemplo de una declaración de zone para un servidor

de nombres primario hospedando linux.com.py (192.168.0.1):
zone "linux.com.py" IN {
type master;
file "linux.com.py.db";
allow-update { none; };
};
En la declaración, la zona es identificada como linux.com.py, el tipo es configurado

a master y el servicio named se instruye para leer el archivo
/var/named/chroot/var/named/linux.com.py.db (Si se ha habilitado el entorno
enjaulado). También le dice a named que no permita a ningún otro host que realice
actualizaciones.
Una declaración de zone de servidor esclavo para linux.com.py se ve un poco

diferente comparado con el ejemplo anterior. Para un servidor esclavo, el tipo se
coloca a slave y en lugar de la línea allow-update está una directiva diciéndole a
named la dirección IP del servidor maestro.
Una declaración de zone para un servidor esclavo para linux.com.py sería como
sigue:
zone "linux.com.py" IN {
type slave;
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
linux.com.py. La información que el servidor esclavo recibe desde el servidor
maestro es guardada al archivo /var/named/chroot/var/named/linux.com.py.db (Si se
ha habilitado el entorno enjaulado).

Una declaración de zone para un servidor que realiza reenvío condicional

(conditional forwarding) para suc1.linux.com.py y suc2.linux.com.py sería como
sigue:
zone "suc1.linux.com.py" IN {
type forward;
forwarders { 138.72.10.20; 138.72.30.28; };
};
zone "suc2. linux.com.py" IN {

type forward;
forwarders { 138.72.20.20; 138.72.20.28; };
};
Para permitir que el servidor DNS pueda resolver dominios de la Internet, es

necesario agregar una zona hint, el archivo de zona contiene la lista de root
nameservers:
zone "." IN {
type hint;
file "named.root" ;
};
Las zonas hint son normalmente incluidas en el archivo /etc/named.conf a través de

la siguiente declaración:
include "/etc/named.root.hints"
Las zonas stub son utilizadas normalmente en los servidores DNS padres cuando
se ha implementado delegación de dominios. La siguiente seria una declaración de
zona stub para un dominio llamado linux.com.py que tiene un subdominio delegado
llamado suc1.linux.com.py:
zone "suc1.linux.com.py" {
type stub;
masters { 192.253.254.2; };
file "stub.linux.com.py.db";
};
Configuración del archivo /etc/named.conf
El paquete bind incluye archivos de ejemplo que puede utilizar como base para la
configuración de un servidor de nombres y se encuentran en el directorio
/usr/share/doc/bind-*/sample/. Copie todos los archivos de configuración de
ejemplo al directorio /etc:
# cp /usr/share/doc/bind-*/sample/etc/* /var/named/chroot/etc
# chown -R root:named /var/named/chroot/etc
Edite el archivo /etc/named.conf y modifíquelo acorde al tipo de servidor que desea

configurar. El siguiente es un ejemplo de un archivo named.conf para un servidor
maestro de la zona linux.com.py:

//
// Sample named.conf BIND DNS server 'named' configuration file
// for the CentOS BIND distribution.
//
// See the BIND Administrator's Reference Manual (ARM) for details, in:
// file:///usr/share/doc/bind-*/arm/Bv9ARM.html
// Also see the BIND Configuration GUI : /usr/bin/system-config-bind and
// its manual.
//
options
{
/* make named use port 53 for the source of all queries, to allow
* firewalls to block all ports except 53:
*/
query-source port 53;
query-source-v6 port 53;
// Put files that named is allowed to write in the data/ directory:

directory "/var/named"; // the default
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";
// Configure forwarders
forwarders { 192.168.10.1; 192.168.10.2; };
};
logging
{
/* If you want to enable debugging, eg. using the 'rndc trace' command,
* named will try to write the 'named.run' file in the $directory
* (/var/named).
* By default, SELinux policy does not allow named to modify the /var/named
* directory, so put the default debug log file in data/ :
*/
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view "internal"
{
/* This view will contain zones you want to serve only to "internal" clients
* that connect via your directly attached LAN interfaces - "localnets" .
*/
match-clients { localnets; localhost; };
match-destinations { localnets; localhost; };
recursion yes;
// all views must contain the root hints zone:
include "/etc/named.root.hints";
// include "named.rfc1912.zones";
// you should not serve your rfc1912 names to non-localhost clients.
// These are your "authoritative" internal zones, and would probably

// also be included in the "localhost_resolver" view above :
zone "linux.net.py" {
type master;
file "linux.net.py.db";
};
};
view "external"

{
/* This view will contain zones you want to serve only to "external" clients
* that have addresses that are not on your directly attached LAN interface
* subnets:
*/
match-clients { !localnets; !localhost; };
match-destinations { !localnets; !localhost; };
recursion no;
// you'd probably want to deny recursion to external clients, so you don't
// end up providing free DNS service to all takers
// all views must contain the root hints zone:

include "/etc/named.root.hints";
// These are your "authoritative" external zones, and would probably

// contain entries for just your web and mail servers:
zone "linux.com.py" {
type master;
};
};
En el ejemplo anterior, se han definido dos vistas, una para los recursos de la red
Interna y otra para los recursos publicados hacia Internet. Cada vista tiene su
propia base de datos de zona y restringe el acceso a los hosts listados en las
declaraciones match-clients y match-destinations.
Para la vista internal, match-clients y match-destinations están configurados a

localhost y localnets, lo cual restringe su acceso a el equipo local y los equipos
conectados a alguna de las redes del servidor.
Para la vista external, match-clients y match-destinations están configurados de tal

forma a no coincidir con localhost o localnets, por tanto, esto sería cualquier host
que no pertenezca a la red privada, lo cual concordaría con cualquier consulta que
provenga desde Internet. Se debe notar que para los hosts que provienen de
Internet, la recursión está deshabilitada.
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 linux.com.py.db.
Cada archivo de zona contiene directivas y registros de recursos. Las directivas le

dicen al servidor de nombres que realice tareas o aplique configuraciones
especiales a la zona. Los registros de recursos define los parámetros de la zona y
asignan identidades a hosts individuales. Las directivas son opcionales, pero los
registros de recursos se requieren para proporcionar servicios de nombres a la

zona.
Todas las directivas y registros de recursos deberían ir en sus propias líneas

individuales.
Los comentarios se pueden colocar después de los punto y comas (;) en archivos
de zona.
Directivas de archivos de zona
Las directivas comienzan con el símbolo de dólar ($) seguido del nombre de la
directiva. Usualmente aparecen en la parte superior del archivo de zona.
Lo siguiente son directivas usadas a menudo:
● $INCLUDE -Dice a named que incluya otro archivo de zona en el archivo de

zona donde se usa la directiva. Así se pueden almacenar configuraciones de
zona suplementarias aparte del archivo de zona principal.
● $ORIGIN -Anexa el nombre del dominio a registros no cualificados, tales

como aquellos con el nombre de host solamente.
Por ejemplo, un archivo de zona puede contener la línea siguiente:

$ORIGIN linux.com.py.
Cualquier nombre usado en los registros de recursos que no terminen en un

punto (.) tendrán linux.com.py anexado.
● $TTL - Ajusta el valor Time to Live (TTL) predeterminado para la zona. Este
es el tiempo, en segundos, que un registro de recurso de zona es válido.
Cada recurso puede contener su propio valor TTL, el cual ignora esta
directiva.
Cuando se decide aumentar este valor, permite a los servidores de nombres

remotos hacer caché a la información de zona para un período más largo de
tiempo, reduciendo el número de consultas para la zona y alargando la
cantidad de tiempo requerido para proliferar cambios de registros de
recursos.
Registros de recursos de archivos de zona
El componente principal de un archivo de zona es su registro de recursos.
Hay muchos tipos de registros de recursos de archivos de zona. A continuación le

mostramos los tipos de registros más frecuentes;
Registro SOA (Start Of Authority)
El registro SOA proclama información importante sobre la autoridad de

determinados servidores sobre determinados espacios de nombres.
Está situado detrás de las directivas, un registro SOA es el primer registro en un

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

@ IN SOA <primary-name-server> <hostmaster-email> (
<serial-number>
<time-to-refresh>
<time-to-retry>
<time-to-expire>
<minimum-TTL> )
El símbolo @ coloca la directiva $ORIGIN (o el nombre de la zona, si la directiva

$ORIGIN no está configurada) como el espacio de nombres que esta siendo definido
por este registro de recursos SOA. El servidor de nombres primario que tiene
autoridad para este dominio es usado por el <primary-name-server>, y el correo
electrónico de la persona a contactar sobre este espacio de nombres es sustituído
por el <hostmaster-email>.
El <serial-number> es incrementado cada vez que se cambia el archivo de zona

para que así named sabrá que debería recargar esta zona. El parámetro <time-to-
refresh> le dice a cualquier servidor esclavo cuánto tiempo debe esperar antes de
preguntar al servidor de nombres maestro si se han realizado cambios a la zona. El
valor <serial-number> es usado por el esclavo para determinar si esta usando datos
de la zona desactualizados y si debería refrescarlos.
El valor <time-to-retry> le dice al servidor de nombres esclavo sobre el intervalo de

tiempo que tiene que esperar antes de emitir una petición de actualización de datos
en caso de que el servidor de nombres maestro no le responda. Si el servidor
maestro no ha respondido a una petición de actualización de datos antes que se
acabe el intervalo de tiempo <time-to-expire>, el servidor esclavo para de
responder como una autoridad por peticiones al espacio de nombres.
La opción <minimum-TTL> solicita que otro servidor de nombres guarde en caché la

información de zona por al menos esta cantidad de tiempo (en segundos).
Con BIND, todos los tiempos son siempre referenciados en segundos. Sin
embargo, es posible usar abreviaciones cuando se especifiquen unidades de
tiempo además de segundos, tales como minutos (M), horas (H), días (D) y semanas
(W).

El ejemplo siguiente ilustra la forma que un registro de recursos SOA puede tomar
cuando es configurado con valores reales.
@ IN SOA dns1.linux.com.py. soporte.linux.com.py. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
Registro NS (Name Server)
El registro NS anuncia los nombres de servidores con autoridad para una zona
particular.
Este es un ejemplo de un registro NS:

IN NS <nameserver-name>
El <nameserver-name> debería ser un FQDN.
Luego, dos nombres de servidores son listados como con autoridad para el
dominio. No es importante si estos nombres de servidores son esclavos o si son
maestros; ambos son todavía considerados con autoridad.
IN NS dns1.linux.com.py.
Registro A (Address)
El registro de dirección que especifica una dirección IP que se debe asignar a un

nombre, como en el ejemplo:
<host> IN A <IP-address>
Si el valor <host> es omitido, el registro A apunta a una dirección IP por defecto para
la parte superior del espacio de nombres. Este sistema es el objetivo para todas las
peticiones no FQDN.
Considere el siguiente ejemplo de registro A para el archivo de zona linux.com.py:
IN A 10.0.1.3
host1 IN A 10.0.1.5
Las peticiones para linux.com.py son apuntadas a 10.0.1.3, mientras que las
solicitudes para host1.linux.com.py son dirigidas a 10.0.1.5.

Las direcciones IPv6 son representadas en DNS por recursos AAAA, también
llamados registros quad-A para las zonas de búsqueda directa. El siguiente es un
ejemplo de un recuros IPv6:
host01 IN AAAA 3ffe:400:10:100:201:2ff:feb5:3806
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.
host1 IN A 10.0.1.5
www IN CNAME host1
Registro MX (Mail eXchange)
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>
En este ejemplo, <preference-value> permite una clasificación numérica de los

servidores de correo para un espacio de nombres, dando preferencia a algunos
sistemas de correo sobre otros. El registro de recursos MX con el valor más bajo
<preference-value> es preferido sobre los otros. Sin embargo, múltiples servidores
de correo pueden tener el mismo valor para distribuir el tráfico de forma pareja
entre ellos.
El <email-server-name> puede ser un nombre de servidor o FQDN.
IN MX 10 mail.linux.com.py.
IN MX 20 mail2.linux.com.py.
En este ejemplo, el primer servidor de correo mail.linux.com.py es preferido al

servidor de correo mail2.linux.com.py cuando se recibe correo destinado para el

dominio linux.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.
Puede utilizar como modelo el archivo localdomain.zone existente en el directorio

/usr/share/doc/bind-*/sample/var/named y modificarlo para configurar los archivos de
zona para cada vista. Para ello, copie el archivo al directorio
/var/named/chroot/var/named:
# cp /usr/share/doc/bind-*/sample/var/named/localdomain.zone \
/var/named/chroot/var/named/linux.net.py.db
# cp /usr/share/doc/bind-*/sample/var/named/localdomain.zone \
/var/named/chroot/var/named/linux.com.py.db
# cp /usr/share/doc/bind-*/sample/var/named/named.root \
/var/named/chroot/var/named/
# chown -R root:named /var/named/chroot/var
Modifique los archivos para reflejar la información correspondiente con cada zona.
El siguiente es un ejemplo para la zona linux.com.py:
$ORIGIN linux.com.py.
$TTL 86400
42 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN MX 10 mail.linux.com.py.
IN MX 20 mail2.linux.com.py.
IN A 10.0.1.5
server1 IN A 10.0.1.5
dns1 IN A 10.0.1.2
dns2 IN A 10.0.1.3
ftp IN CNAME server1

mail IN CNAME server1

mail2 IN CNAME server2
www IN CNAME server2
En este ejemplo, las directivas estándar y los valores SOA son usados. Los
servidores de nombres con autoridad se configuran como dns1.linux.com.py y
dns2.linux.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.linux.com.py y a server2.linux.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..linux.com.py y

www..linux.com.py, son apuntados a los servidores apropiados usando registros
CNAME.
De la misma forma, puede configurar los recursos para la zona linux.net.py.
El siguiente es un ejemplo para la zona linux.com.py:

$ORIGIN linux.net.py.
$TTL 86400
@ IN SOA dns1.linux.net.py. soporte.linux.net.py. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS dns1.linux.net.py.
IN NS dns2.linux.net.py.
IN MX 10 mail.linux.net.py.
IN MX 20 mail2.linux.net.py.
IN A 10.0.1.5
dns1 IN A 10.0.1.2
dns2 IN A 10.0.1.3
ftp IN CNAME server1

mail IN CNAME server1
mail2 IN CNAME server2
www IN CNAME server2
pc01 IN A 192.168.1.10
pc02 IN A 192.168.1.11
pc03 IN A 192.168.1.12
imp01 IN A 192.168.1.13
En esta zona se listan recursos de la red privada, tales como estaciones de trabajo
e impresoras.

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
42 ; serial
3H ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
5 IN PTR server1.linux.com.py.
7 IN PTR server2.linux.com.py.
2 IN PTR dns1.linux.com.py.
3 IN PTR dns2.linux.com.py.
Este archivo de zona se colocará en funcionamiento con una declaración zone en el

archivo named.conf el cual se ve similar a lo siguiente:
zone "1.0.10.in-addr.arpa" IN {
type master;
file "1.0.10.in-addr.arpa.db";
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 la utilidad rndc, que permite administrar localmente o a distancia, el

demonio named gracias a las declaraciones de las líneas de comandos. Para evitar
que los usuarios no autorizados a controlar BIND en su sistema, se utiliza el
método de claves secretas compartidas para dar privilegios a determinados hosts.
El comando rndc tiene la siguiente sintaxis:
rndc <options> <command> <command-options>
Cuando ejecuta el comando rndc, las opciones más comunes son:

● halt — Para inmediatamente el servicio named.
● reload — Dice al servidor de nombres que recargue los ficheros de zona paro
que conserve todas las respuestas precedentes situadas en caché. Esto le
permite realizar cambios en los ficheros de zona y de ponerlos en práctica en
los servidores maestros y esclavos sin perder las resoluciones de nombres
almacenadas.
Si los cambios no afectan a una zona determinada, puede decir al comando
named que recargue esa zona. Escriba el nombre de la zona después del
comando reload.
● status — Muestra el estado del servidor.
● stop— Para el servidor salvando todas las actualizaciones dinámicas y los
datos IXFR antes de parar el servidor completamente.
Para poder utilizar rndc simplemente ejecute:
# rndc-confgen -a
# service named restart
El comando rndc-confgen creará el archivo /var/named/chroot/etc/rndc.key el cual

contiene la clave para la administración de este servidor.
Opciones de línea de comandos de rndc
Un comando rndc toma la forma siguiente:
rndc <options> <command> <command-options>
Cuando esté ejecutando rndc en una máquina local configurada de la forma

correcta, los comandos siguientes están disponibles:
Comando Descripción
halt Para inmediatamente el servicio named.
querylog Registra todas las peticiones hechas a este servidor de nombres.

Comando Descripción
refresh Refresca la base de datos del servidor de nombres.
reload Recarga los archivos de zona pero mantiene todas las respuestas
precedentes situadas en caché. Esto le permite realizar cambios
en los archivos de zona sin perder todas las resoluciones de
nombres almacenadas.
stats Descarga las estadísticas actuales de named al archivo
/var/named/named.stats.
stop Detiene al servidor salvando todas las actualizaciones dinámicas y
los datos de las Transferencias de zona incremental (IXFR) antes
de salir.
Ocasionalmente, puede ser necesario ignorar las configuraciones por defecto en el

archivo /etc/rndc.conf. Están disponibles las siguientes opciones:
-c <archivo> Le dice a rndc que use un archivo de configuración diferente
a /etc/rndc.conf.
-p <puerto> Especifica la utilización de un número de puerto diferente del
predeterminado 953 para la conexión del comando rndc.
-s <servidor> Dice a rndc que envie el comando a un servidor distinto al
default-server especificado en su archivo de configuración.
-y <clave> Le permite especificar una clave distinta de la opción default-
key en el archivo /etc/rndc.conf.
Se puede encontrar información adicional sobre estas opciones en la página del

manual de rndc.

9
Servidor Apache HTTP

El Servidor Apache HTTP es un servidor Web de tecnología Open Source sólido y

para uso comercial desarrollado por la Apache Software Foundation
(http://www.apache.org). CentOS Linux incluye el Servidor Apache HTTP versión 2
así como también una serie de módulos de servidor diseñados para mejorar la
funcionalidad.
El archivo de configuración predeterminado instalado en el Servidor Apache HTTP

funciona en la mayor parte de los casos. Esta sección subraya cómo personalizar
el archivo de configuración /etc/httpd/conf/httpd.conf de Servidor Apache HTTP
para ayudar a aquellos que requieren una configuración personalizada.
Si utiliza la Herramienta de configuración de HTTP system-config-httpd, no cambie

el archivo de configuración del Servidor Apache HTTP manualmente pues la
Herramienta de configuración de HTTP vuelve a generar este archivo cada vez que
se usa.
Directivas de configuración en httpd.conf
El archivo de
configuración del Servidor Apache HTTP es
/etc/httpd/conf/httpd.conf. El archivo httpd.conf está bien comentado y es
bastante autoexplicativo. Su configuración por defecto funciona para la mayoría de
los casos; sin embargo, quizás quiera conocer el resto de las opciones de
configuración más importantes.
Sugerencias de configuración generales
Si necesita configurar Servidor Apache HTTP sólo tiene que modificar el archivo
/etc/httpd/conf/httpd.conf y después recargar o bien apagar y arrancar el proceso
del comando httpd.
Antes de modificar el archivo httpd.conf, primero haga una copia del archivo
original. Si crea una copia de respaldo, podrá recuperar el sistema de posibles
errores cometidos antes al editar el nuevo archivo de configuración.
Si comete un error y su servidor de web no funciona correctamente, lo primero que

debe realizar es revisar lo que lo que acaba de modificar en httpd.conf para ver si
no hay errores de transcripción.
Después consulte el archivo de registro de errores del servidor web,

/var/log/httpd/error_log. Este puede ser difícil de interpretar, todo depende del
nivel de experiencia. Si acaba de tener problemas, de todas formas, las últimas

entradas deberían de ayudarle a saber lo que ha pasado.
Puede utilizar el comando httpd -t para verificar que esté correcta la sintaxis del
archivo de configuración.
Directiva ServerRoot
La directiva ServerRoot especifica el directorio de nivel superior que tiene el

contenido web. Por defecto, ServerRoot está configurado a "/etc/httpd" para
servidores seguros y no seguros.
Directiva PidFile
La 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.
Directiva Timeout
La 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
Directiva KeepAlive
La 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.
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 elrendimiento del servidor. El valor predeterminado de

MaxKeepAliveRequests es de 100 que debería bastar en la mayoría de los casos.
Directiva KeepAliveTimeout
La directiva KeepAliveTimeout establece el número de segundos que el servidor

esperará a la siguiente petición, tras haber dado servicio a una petición, antes de
cerrar la conexión. Una vez recibida la petición, se aplica la directiva Timeout en su
lugar. KeepAliveTimeout está configurado a 15 segundos por defecto.
Directivas MinSpareServers y MaxSpareServers
El Servidor Apache HTTP se adapta dinámicamente a la carga percibida

manteniendo un número apropiado de procesos de servidores libres basado en el
tráfico. El servidor comprueba el número de servidores que esperan peticiones y
elimina algunos si el número es más alto que MaxSpareServers o crea algunos si el
número de servidores es menor que MinSpareServers.
El valor predeterminado de MinSpareServers es 5 y el de MaxSpareServers es 20.

Estos valores predeterminados son suficientes en la mayoría de los casos. El
número de MinSpareServers no debería de ser elevado ya que creará una gran carga
incluso cuando el tráfico fuese bajo.
Directiva StartServers
StartServers establece cuántos procesos serán creados al arrancar. Ya que el

servidor Web crea y elimina dinámicamente servidores según el tráfico, no se
necesitará cambiar este parámetro. El servidor está configurado para arrancar ocho
procesos al arrancar.
Directiva MaxClients
La directiva MaxClients establece un límite al total de los procesos del servidor (o

clientes conectados simultáneamente) que se pueden ejecutar a la vez. El
propósito principal de esta directiva es prevenir que un Servidor Apache HTTP
descontrolado vuelva inestable al sistema operativo. Para los servidores muy
ocupados este valor se debería colocar a un valor alto. El valor por defecto es 150.
No se recomienda que el valor del comando MaxClients supere 256.
Directiva Listen

El comando Listen identifica los puertos en los que el servidor Web aceptará las
peticiones entrantes. Por defecto, el Servidor Apache HTTP está configurado para
escuchar en el puerto 80 para comunicaciones Web no seguras y (en
/etc/httpd/conf.d/ssl.conf el cual define cualquier servidor seguro) en el puerto
443 para comunicaciones seguras.
Directiva Include
Include permite que se incluyan otros archivos de configuración en el tiempo de

ejecución.
La ruta a estos archivos de configuración pueden ser absolutas o relativas con

respecto al ServerRoot.
Directiva User
La directiva User establece el nombre de usuario para el proceso del servidor y

determina qué archivos puede acceder el servidor. Cualquier archivo que no esté
accesible a este usuario tampoco estará disponible para los clientes del Servidor
Apache HTTP.
Por defecto User es configurado a apache.
Directiva Group
Especifica el nombre del grupo de los procesos Servidor Apache HTTP.
Por defecto Group está configurado a apache.
Directiva ServerAdmin
Configure la directiva ServerAdmin a la dirección de correo electrónico del

administrador del servidor Web. Esta dirección de correo aparecerá en los
mensajes de error en las páginas generadas por el servidor Web, de tal manera
que los usuarios pueden comunicar errores enviando correo al administrador.
Por defecto, ServerAdmin es configurado a root@localhost.
Una forma típica de configurar ServerAdmin es situarlo en la dirección

webmaster@ejemplo.com. Después cree un alias del webmaster para la persona
responsable del servidor Web en /etc/aliases y ejecute /usr/bin/newaliases.

Directiva ServerName
Use la directiva ServerName para configurar un nombre de servidor y un número de

puerto (que coincida con la directiva Listen) para el servidor. El ServerName no
necesita coincidir con el nombre real de la máquina. Por ejemplo, el servidor Web
puede ser www.linux.com.py pero el nombre del servidor es en realidad
foo.linux.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.linux.com.py:80
Cuando especifique un ServerName, asegúrese de que el par de la dirección IP y el

nombre del servidor estén incluidos en el archivo /etc/hosts.
Directiva DocumentRoot
DocumentRoot es el directorio que contiene la mayoría de los archivos HTML que se

entregarán en respuesta a peticiones. El directorio predeterminado DocumentRoot
para servidores seguros y no seguros es /var/www/html. Por ejemplo, el servidor
puede recibir una petición para el siguiente documento:
http://www.linux.com.py/index.html
El servidor busca por el archivo siguiente en el directorio por defecto:

/var/www/html/index.html
Directiva DirectoryIndex
DirectoryIndex es la página por defecto que entrega el servidor cuando hay una
petición de índice de un directorio especificado con una barra (/) al final del nombre
del directorio.
Por ejemplo, cuando un usuario pide la página http://example/this_directory/, recibe

la página DirectoryIndex si existe, o un listado generado por el servidor. El valor por
defecto para DirectoryIndex es index.html y el tipo de mapa index.html.var. El
servidor intentará encontrar cualquiera de estos archivos y entregará el primero que
encuentre. Si no encuentra ninguno de estos archivos y Options Indexes esta
configurado para ese directorio, el servidor genera y devuelve una lista, en formato
HTML, de los subdirectorios y archivos del directorio, a menos que la característica
de listar directorios esté desactivada.

Directiva AccessFileName
AccessFileName denomina el archivo que el servidor utilizará para información de

control de acceso en cada directorio. Por defecto, el servidor utilizará .htaccess.
Justo tras AccessFileName, un conjunto de indicadores de Files aplican el control de

acceso a cualquier archivo comenzando con un .ht. Estas directivas niegan el
acceso Web a cualquier archivo .htaccess (o otros archivos que comiencen con .ht)
por razones de seguridad.
Directiva HostnameLookups
HostnameLookups se puede configurar a on, off o double. Si se configura

HostnameLookups a on, el servidor automáticamente resuelve las direcciones IP para
cada conexión. Resolver las direcciones IP significa que el servidor hace una o más
conexiones a un servidor DNS, añadiendo sobrecarga por procesamiento. Si
HostnameLookups es configurado a double, el servidor realiza búsquedas inversa doble
añadiendo aún más sobrecarga.
Para ahorrar recursos en el servidor, HostnameLookups es configurado a off por

defecto.
Si se requieren nombres de host en los archivos de registro, considere ejecutar una

de los muchas herramientas de análisis de log que llevan a cabo las búsquedas de
DNS de forma mucho más eficiente y por montones cuando se este rotando los
archivos de log del servidor Web.
Directiva ErrorLog
ErrorLog especifica el archivo donde se guardan los errores del servidor . Por
defecto, esta directiva es configurada a /var/log/httpd/error_log.
Directiva LogLevel
LogLevel establece que tantos detalles tendrán los registros de mensajes de error.
LogLevel se puede configurar (desde el que tiene menos detalles a los más
detallados) a emerg, alert, crit, error, warn, notice, info o debug. El valor
predeterminado de LogLevel es warn.
Directiva ServerSignature
La directiva ServerSignature añade una línea que contiene la versión del Servidor

Apache HTTP y el ServerName para cualquier documento generado por el servidor,

tales como mensajes de error devueltos a los clientes. Por defecto ServerSignature
está configurada a on.
También se puede configurar a off o a EMail. EMail, agrega una etiqueta HTML
mailto:ServerAdmin a la línea de la firma de las respuestas autogeneradas.
Directiva Redirect
Cuando se mueve una página web, se puede utilizar Redirect para crear
asignaciones de la ubicación del archivo a un nuevo URL. El formato es como
sigue:
Redirect /<old-path> http://<current-domain>/<current-path>
Por ejemplo, si nuestro servidor es www.linux.com.py y solicitan la página

http://www.linux.com.py/suc1, será redireccionada al servidor web de la sucursal
correspondiente:
Redirect /suc1 http://www.suc1.linux.com.py
Configuración de directorios
Directiva Alias
La directiva Alias permite que haya directorios fuera del DocumentRoot a los que
puede acceder el servidor. Cualquier URL que termine en el alias será
automáticamente traducido a la ruta del alias. Por defecto, ya existe un alias
configurado para un directorio icons. El servidor web puede acceder al directorio
icons pero el directorio no está en DocumentRoot.
Por ejemplo, para acceder al directorio /web/forms usando el URL

http://www.linux.com.py/webform, creamos el siguiente Alias:
Alias /webform "/web/forms"
Directiva ScriptAlias
La directiva ScriptAlias define dónde pueden encontrarse los scripts CGI (u otros
scripts). Normalmente, no es una buena idea colocar los scripts CGI dentro de
DocumentRoot. Si los scripts CGI se encontrasen en DocumentRoot, podrían,
potencialmente, ser considerados como documentos de texto. Por esta razón, la

directiva ScriptAlias diseña un directorio especial fuera del directorio DocumentRoot

para contener ejecutables del servidor y scripts. Este directorio es conocido como
un cgi-bin y se configura por defecto a /var/www/cgi-bin/.
Es posible establecer directorios para almacenar ejecutables fuera del directorio

cgi-bin.
Por ejemplo, para acceder al directorio /web/applications usando el URL

http://www.linux.com.py/webap, creamos el siguiente ScriptAlias:
ScriptAlias /webap "/web/applications"
Directiva AddHandler
La directiva AddHandler mapea extensiones de archivos a manejadores específicos.

Por ejemplo, el manejador cgi-script puede mapearse con la extensión .cgi para
que automáticamente trate a cualquier archivo con un nombre que termine en .cgi
como un script CGI. A continuación se presenta un ejemplo de una directiva
AddHandler para la extensión .cgi y .pl.
AddHandler cgi-script .cgi .pl
Esta directiva habilita a CGIs fuera del cgi-bin a que funcionen en cualquier
directorio en el servidor que tengan la opción ExecCGI dentro del contenedor de
directorios.
Directiva Directory
Las etiquetas <Directory /path/to/directory> y </Directory> se usan para crear lo

que se conoce como un contenedor y se usan para agrupar un grupo de directivas
de configuración que sólo se aplican a ese directorio y sus subdirectorios.
El contenedor Directory también se puede usar para configurar directorios

adicionales cgi-bin para las aplicaciones del servidor fuera del directorio
especificado en la directiva ScriptAlias. Para lograr esto, el contenedor Directory
debe configurar la opción ExecCGI para ese directorio.
Por ejemplo, si los scripts CGI están localizados en /web/applications, añada el

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

Directiva Options
La directiva Options controla características del servidor que están disponibles en

un directorio en particular.
Por defecto, el directorio DocumentRoot, Options está configurado para incluir Indexes
y FollowSymLinks. Indexes permite al servidor generar un listado de un directorio si no
se especifica el DirectoryIndex (por ejemplo, index.html) es especificado.
FollowSymLinks permite al servidor seguir enlaces simbólicos en ese directorio.
Las opciones son:
● ExecCGI - Permite la ejecución de los scripts CGI. Los scripts no se ejecutan

si no elige esta opción y visualizará el script como una página de texto.
● FollowSymLinks - Permite que se sigan enlaces simbólicos.
● Includes -Permite las inclusiones en el servidor. Esto permite la generación

de contenido dinámico como fecha y hora actual, etc.
● IncludesNOEXEC Permite las inclusiones en el servidor pero anula los

-
comandos #exec y #include en los scripts CGI. Esto es mucho más seguro.
● Indexes - Muestra una lista formateada de los contenidos de un directorio si

la opción DirectoryIndex (como por ejemplo index.html) existe en el
directorio pedido.
● Multiviews -Soporta las visualizaciones múltiples de los contenidos

habilitando el módulo mod_negotiation; esta opción no está activada por
defecto. Desde HTTP 1.1, los navegadores pueden enviar información al
servidor adicional y preferencias además de sus solicitudes de paginas web.
Este módulo permite seleccionar el documento que mejor concuerda con las
capacidades del cliente. Es útil por ejemplo para desplegar la página en el
idioma que corresponde según la preferencia del navegador.
● SymLinksIfOwnerMatch - Permite seguir un enlace simbólico solamente si el

fichero o el directorio en cuestión tienen el mismo nombre que el dueño del
enlace.
Directiva AllowOverride
La directiva AllowOverride indica si puede o no sobreescribir Options por las

declaraciones en un archivo .htaccess. Por defecto, tanto el directorio raíz como
DocumentRoot están configurados para no permitir la sobreescritura .htaccess.

Directiva Order
La directiva Order controla el orden en el cual las directivas allow y deny son
evaluadas.
● Order Deny,Allow: Las directivas Deny son evaluadas primero y luego las
directivas Allow. Si a un host no se ha denegado explícitamente el acceso,
se otorga el acceso al recurso. Es el orden por defecto si no se especifica lo
contrario.
● Order Allow,Deny: Todas las directivas Allow son evaluadas primero y luego
las directivas Deny. Si a un host no se ha otorgado explícitamente el acceso,
se deniega el acceso al recurso.
● Order mutual-failure:Solo hosts que son especificados en la directiva Allow y

al mismo tiempo no aparecen en la directiva Deny se otorga el acceso. Si un
host no aparece en ninguna directiva, el acceso es denegado.
Ejemplos:
# Un directorio el cual permitimos acceso solo a la red local
# Se evaluan las directivas Deny primero, luego las allow, por tanto se otorga
# acceso a la red local
<Directory "/web/forms">
Options Multiviews
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.1 linux.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 linux.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

UserDir es el nombre del subdirectorio dentro del directorio de cada usuario dónde
estarán los archivos HTML personal que serán servidos por el servidor de Web.
Esta directiva esta configurada por defecto a disable.
El nombre para el subdirectorio esta configurado a public_html en la configuración

por defecto. Por ejemplo, el servidor puede recibir la siguiente petición:
http://linux.com.py/~username/foo.html
El servidor buscará por el archivo:

/home/username/public_html/foo.html
En el ejemplo de arriba, /home/username/ es el directorio principal del usuario

(observe que la ruta por defecto al directorio principal del usuario puede variar).
Hay que asegurarse que los permisos de los directorios de usuario sean correctos.
El valor de los permisos deben ser de 0711. Los bits de lectura (r) y ejecución (x)
deben estar activados en el directorio del usuario public_html (0755 también
funcionará). El valor de los permisos con que se servirán los archivos desde
public_html debe ser 0644 por lo menos.
Arrancar y detener httpd
El RPM de httpd instala el script /etc/rc.d/init.d/httpd, el cual se puede acceder

usando el comando /sbin/service.
Para iniciar el servidor, como root escriba:

/sbin/service httpd start
Para detener el servidor, como root escriba:

/sbin/service httpd stop
La opción restart es un truco para detener y luego arrancar el Servidor Apache

HTTP.
Para reiniciar el servidor, como root escriba:

/sbin/service httpd restart
Sin embargo, luego de modificar el archivo httpd.conf, no es necesario que

explícitamente detenga e inicie el servidor. Para esto use la opción reload.
Para volver a cargar el archivo de configuración, como usuario root escriba:

/sbin/service httpd reload

Configuración de máquinas virtuales
Para crear una máquina virtual basada en nombre, lo mejor es utilizar el

contenedor de la máquina virtual proporcionado en httpd.conf como un ejemplo.
Directiva NameVirtualHost
La directiva NameVirtualHost asocia una dirección IP y número de puerto, si es

necesario, para cualquier máquina virtual basada en nombres. El hospedaje virtual
basado en nombres permite a un Servidor Apache HTTP servir a dominios
diferentes sin usar múltiples direcciones IP.
Para habilitar el hospedaje basado en nombres, quite los comentarios de la

directiva de configuración NameVirtualHost y añada la dirección IP correcta. Luego
añada más contenedores VirtualHost para cada host virtual.
Directiva VirtualHost
Las etiquetas <VirtualHost> y </VirtualHost> crean un contenedor mostrando las

características de un host virtual. El contenedor <VirtualHost> acepta la mayoría de
las directivas de configuración.
Máquinas Virtuales
La característica incorporada del Servidor Apache HTTP de máquinas virtules

permite al servidor servir diferente información basado en cual dirección IP, nombre
de host o puerto está siendo solicitado.
El ejemplo de máquina virtual se lee como sigue:

#NameVirtualHost *
#
#<VirtualHost *>
# ServerAdmin webmaster@dummy-host.linux.com.py
# DocumentRoot /www/docs/dummy-host.linux.com.py
# ServerName dummy-host.linux.com.py
# ErrorLog logs/dummy-host.linux.com.py-error_log
# CustomLog logs/dummy-host.linux.com.py-access_log common
#</VirtualHost>
Para activar máquinas virtuales basadas en nombre, quite los comentarios de la

línea NameVirtualHost eliminando el símbolo de numeral o almohadilla (#).

Luego, configure un host virtual, quitando los comentarios y personalizando el

contenedor <VirtualHost>.
En la línea <VirtualHost>, cambie el ServerName al nombre DNS válido asignado a la

máquina y configure las otras directivas si es necesario.
El contenedor <VirtualHost> es altamente personalizable y acepta casi cada

directiva dentro de la configuración del servidor principal.
Es posible especificar la dirección IP del servidor en lugar del asterisco (*) en las
directivas NameVirtualHost y <VirtualHost>. La dirección IP es requerida en versiones
1.3.12 y anteriores.
Ejemplo de creación de máquinas virtuales
Para crear dos máquinas virtuales, uno llamado www.lab.linux.com y

foro.lab.linux.com cree el archivo /etc/httpd/conf.d/virtualhosts.conf y configure
como el siguiente ejemplo:
NameVirtualHost *
<VirtualHost *>
ServerAdmin webmaster@lab.linux.com
DocumentRoot /var/www/html/www
ServerName www.lab.linux.com
ErrorLog logs/www.lab.linux.com-error_log
CustomLog logs/www.lab.linux.com-access_log common
</VirtualHost>
<VirtualHost *>
ServerAdmin webmaster@lab.linux.com
DocumentRoot /var/www/html/foro
ServerName foro.lab.linux.com
ErrorLog logs/foro.lab.linux.com-error_log
CustomLog logs/foro.lab.linux.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.linux.com:
ServerAlias soporte.linux.com
Si especifica la siguiente directiva ServerAlias:
ServerAlias *.linux.com
Todas las solicitudes para cualquier host en linux.com sera respondida por el
servidor virtual al cual se aplica la directiva. Es posible utilizar * y ? como
comodines para hacer concordar los nombres.

Configuración de autenticación para el acceso a directorios
El modulo mod_auth_dbm en el Servidor Apache le permite configurar un sistema de

autenticación para el acceso al directorio. La configuración es como sigue:
<Location /private/>
AuthType Basic
AuthName "My Private Files"
AuthDBMUserFile /var/www/authdb
AuthDBMType DB
require valid-user
</Location>
Observe que la directiva AuthDBMUserFile también puede ser usada en archivos

.htaccess.
El script Perl dbmmanage, usado para manipular bases de datos de nombres de

usuarios y contraseñas.
Añade un usuario a la base de datos (usando la contraseña dada)

# htdbm -b -TDB authdb username password
Añade un usuario a la base de datos ( le pide la contraseña)

# htdbm -TDB authdb username
Eliminar el usuario de la base de datos

# htdbm -x -TDB authdb username
Listar usuarios en la base de datos

# htdbm -l -TDB authdb
Configuración del Servidor Seguro Apache HTTP
El mdulo mod_ssl es un módulo de seguridad para el Servidor Apache HTTP. El

mdulo mod_ssl usa las herramientas proporcionadas por el Proyecto OpenSSL para
añadir una característica muy importante al Servidor Apache HTTP la habilidad de
tener comunicaciones encriptadas. En contraste, usando HTTP normal, las
comunicaciones entre el navegador y el servidor Web son enviadas en texto plano,
lo cual puede ser interceptado y leído por alguna persona no autorizada.
El archivo de configuración mod_ssl está ubicado en /etc/httpd/conf.d/ssl.conf.

Para que este archivo sea cargado, y por ende para que mod_ssl funcione, debe
tener la sentencia Include conf.d/*.conf en /etc/httpd/conf/httpd.conf.

Vista preliminar de los paquetes relacionados con la seguridad
Para activar el servidor seguro, necesita, como mínimo, tener instalados los
siguientes tres paquetes:
● httpd El paquete httpd contiene el demonio httpd y otras utilidades

relacionadas, archivos de configuración, iconos, Servidor Apache HTTP
módulos, páginas de manual y otros archivos utilizados por Servidor Apache
HTTP.
● mod_ssl El paquete mod_ssl incluye el módulo mod_ssl, que proporciona

criptografía fuerte para el servidor web Servidor Apache HTTP a través de
los protocolos SSL, Secure Sockets Layer y TLS, Transport Layer Security.
● openssl El paquete openssl contiene el conjunto de herramientas de

OpenSSL. El conjunto de herramientas de OpenSSL implementa los
protocolos SSL y TLS y también incluye una librería criptográfica de
propósito general.
Vista preliminar de certificados y seguridad
Su servidor proporciona seguridad usando una combinación del protocolo SSL

Secure Sockets Layer y (en la mayoría de los casos) un certificado digital de una
Autoridad de Certificación (CA). SSL maneja las comunicaciones encriptadas y la
mutua autentificación entre navegadores y su servidor seguro. El certificado digital
aprobado por una CA proporciona autentificación para su servidor seguro (el CA
pone su reputación detrás de la certificación de la identidad de su organización).
Cuando su navegador se esté comunicando usando la encriptación SSL, verá el
prefijo https:// al principio de la URL (Localizador de Recursos Uniforme - la
dirección de internet) en la barra de navegación.
La encriptación depende del uso de claves (imagínelas como anillos

codificador/decodificador en formato de datos). En criptografía convencional o
simétrica, ambas partes de la transacción tienen la misma clave, la cual usan para
decodificar la transmisión del otro. En criptografía pública o asimétrica, coexisten
dos claves: una pública y una privada. Una persona o una organización guarda su
clave privada en secreto, y publica su clave pública. Los datos codificados con la
llave pública sólo pueden ser decodificados con la clave privada; y los datos
codificados con la clave privada sólo pueden ser decodificados con la llave pública.
Para configurar su servidor seguro, usará criptografía pública para crear un par de
claves pública y privada. En muchos casos, enviará su petición de certificado
(incluyendo su clave pública), demostrando la identidad de su compañía y pago a la
CA. La CA verificará la petición del certificado y su identidad, y entonces mandará

un certificado para su servidor seguro.
Un servidor seguro usa un certificado para identificarse a sí mismo a los

navegadores web. Puede generar su propio certificado (llamado certificado
autofirmado) o puede conseguirlo de una Autoridad de Certificación o CA. Un
certificado de una CA con buena reputación garantiza que un sitio web está
asociado a una compañía u organización particular.
Alternativamente, puede crear su propio certificado autofirmado. Note, sin embargo,

que estos certificados autofirmados no deben ser usados en muchos entornos de
producción. Dichos certificados pueden no ser aceptados automáticamente por el
navegador de un usuario, el usuario será preguntado por el navegador si quiere
aceptar el certificado y crear la conexión segura.
Generar una clave
Tiene que ser root para generar una clave.
Antes de generar la clave, debe identificar donde esta almancenada la clave, esta
información la puede obtener del archivo /etc/httpd/conf.d/ssl.conf. Verifique la
ruta de los archivos mencionados en las opciones:
SSLCertificateFile
SSLCertificateFile
Una vez determinada la ubicación de los archivos, elimine la clave y el certificado

simulados que se generaron durante la instalación con los siguientes comandos:
# rm /etc/httpd/conf/ssl.key/server.key
# rm /etc/httpd/conf/ssl.crt/server.crt
O en versiones mas recientes:

# rm /etc/pki/tls/certs/localhost.crt
# rm /etc/pki/tls/private/localhost.key
A continuación, necesita crear su propia clave aleatoria. Cambie al directorio

/usr/share/ssl/certs y escriba el comando siguiente:
# make genkey
Su sistema mostrará un mensaje similar al siguiente:

umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key
Generating RSA private key, 1024 bit long modulus
.......++++++
................................................................++++++
e is 65537 (0x10001)
Enter PEM pass phrase:

O en versiones mas recientes, cambiese al directorio /etc/pki/tls/certs:
umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > /etc/pki/tls/private/localhost.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.

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]:CentOS Paraguay
Organizational Unit Name (eg, section) []:Sistemas
Common Name (your name or server's hostname) []:www.linux.com.py
Email Address []:soporte@linux.com.py
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

requerida es el nombre del país dónde el certificado será usado, parecido a:

Country Name (2 letter code) [GB]:
La entrada por defecto, entre corchetes, es GB. Para aceptarla, pulse [Intro], o
relléne con el código de dos letras de su país.
Tendrá que introducir el resto de las entradas. Todas estas entradas son
autoexplicativas, pero necesitará seguir estas directrices.
No abrevie la localidad o el estado. Escríbalas enteras.
Si está mandando esta información de un CSR a un CA, sea cuidadoso en

proporcionar la información correcta en todos los campos, pero especialmente en el
Nombre de la Organización y el Nombre común. Las CAs verifican los datos para
determinar si su organización es responsable de quién proporcionó como Nombre
común. Las CAs rechazarán las peticiones que incluyan información que ellos
perciban como inválida.
Para Nombre común, asegúrese que teclea el verdadero nombre de su

servidor Web seguro (un nombre de DNS válido) y no un alias que el servidor
tenga.
La Dirección email debe ser la del webmaster o administrador del sistema.
Evite caracteres especiales como @, #, &, !, etc. Algunas CAs rechazarán una
petición de certificado que contenga un caracter especial. Así, si el nombre de su
compañía contiene una "y" comercial (&), escríbalo como "y" en vez de "&".
No use los atributos extra (Otra Contraseña y Nombre opcional de la

compañía). Para continuar sin introducir estos campos, simplemente pulse [Intro]
para aceptar los valores en blanco por defecto.
El archivo /etc/httpd/conf/ssl.csr/server.csr o /etc/pki/tls/certs/localhost.csr

según corresponda, es creado cuando termine de introducir su información. Este
archivo es su petición de certificado, listo para enviar a su CA.
Después de haber decidido una CA, siga las instrucciones que ellos proporcionen
en su sitio web. Estas instrucciones le dirán como mandar su petición de
certificado, cualquier otra documentación que ellos requieran, y como pagarles.
Después de haber satisfecho los requisitos de la CA, ellos le mandarán un

certificado para usted (normalmente por email). Guarde (o copie y pegue) el
certificado que le manden como /etc/httpd/conf/ssl.crt/server.crt o
/etc/pki/tls/certs/localhost.crt.
Asegúrese de hacer una copia de respaldo.

Creación de un certificado autofirmado
Usted puede crear su propio certificado autofirmado. Por favor, tenga en cuenta
que un certificado autofirmado no proporciona las garantías de seguridad que un
certificado firmado por una CA sí proporciona.
Una vez que tenga la clave y que se asegure de estar en el directorio

/usr/share/ssl/certs o /etc/pki/tls/certs según correponda, y utilice el siguiente
comando:
# make testcert
Se le pedirá que introduzca su palabra de paso (a menos que haya generado una
clave sin contraseña):
Después de que introduzca su contraseña (o sin la petición, si ha creado una clave

sin ella), se le pedirá más información. La salida del ordenador y el conjunto de
peticiones será parecido al siguiente (necesitará dar la información correcta de su
organización y de su máquina):
You are about to be asked to enter information that will be 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]: CentOS Paraguay
Organizational Unit Name (eg, section) []: Sistemas
Common Name (your name or server's hostname) []:www.linux.com.py
Email Address []:soporte@linux.com.py
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.linux.com.py con el nombre de su dominio):
https://server.linux.com.py

Si ha comprado un certificado de una CA bien conocida, su navegador

probablemente aceptará el certificado automáticamente (sin pedirle información
adicional) y creará una conexión segura. Su navegador no reconocerá
automáticamente un certificado de prueba o un certificado autofirmado, porque el
certificado no es firmado por una CA. Si no está usando un certificado de una CA,
siga las instrucciones proporcionadas por su navegador para aceptar el certificado.
Una vez que su navegador acepte el certificado, su servidor seguro mostrará una
página de inicio predeterminada.
Forzar el uso del modo SSL
Ahora que el servidor tiene habilitado SSL, todas las interacciones con el servidor
que esten relacionadas con nombres de usuarios, contraseñas, detalles personales
o financieros deben ser enviados a traves de este protocolo. Esto se hace
facilmente indicando https:// en lugar de http:// en la dirección URL. Sin embargo,
es posible que las personas olviden este gran detalle.
Para evitar ello, el servidor tiene otro módulo llamado “mod_rewrite”, el cual permite
que una solicitud de USL sea reescrita antes que el servido web responda a la
petición de la página. El módulo rewrite provee una forma de forzar la utilización de
SSL para cualquier solicitud entrante.
Para lograr esto, es necesario crear un archivo de configuración para el módulo

rewrite. Con el editor de texto vi, cree el archivo /etc/httpd/conf.d/mod-rewrite.conf
# vi /etc/httpd/conf.d/mod-rewrite.conf
En este ejemplo, cualquier solicitud hecha a la carpeta “webmail” se forzará el uso

de SSL, y los usuarios pueden introducir sus detalles de forma confidencial. La
opción rewrite log puede ser usada para propósitos de solución de problemas.
# Rewrite Rules.
RewriteEngine 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

10
Servicios de correo electrónico


Conceptos generales
El correo en Internet es gestionado por programas que se agrupan en dos
categorías: MTA (Mail Transfer Agent) y MUA (Mail User Agent). Los MTA se
encargan de transportar el mensaje de máquina en máquina hasta que llega a su
destino, mientras que los MUA se encargan de interactuar con el usuario para
enviar o recibir el correo.
Evolution, Mozilla thunderbird, pine son MUA que son usados habitualmente. Entre
la lista de MTAs se encuentran Postfix, Sendmail, Qmail, Exim.
En Internet, los MTA se comunican entre sí usando el protocolo SMTP, y por lo

tanto se los llama servidores SMTP.
El MTA del destinatario entrega el correo electrónico al (MDA, Mail Delivery Agent),
el cual almacena el correo electrónico mientras espera que el usuario lo acepte. El
MDA mas popular es procmail. Existen dos protocolos principales utilizados para
recuperar un correo electrónico de un MDA:
● POP3 (Post Office Protocol - Protocolo de Oficina de Correo), el más antiguo

de los dos, que se usa para recuperar el correo electrónico y, en algunos
casos, dejar una copia en el servidor.
● IMAP (Internet Message Access Protocol - Protocolo de Acceso a Mensajes

de Internet), el cual se usa para coordinar el estado de los correos
electrónicos (leído, eliminado, movido) a través de múltiples clientes de
correo electrónico. Con IMAP, se guarda una copia de cada mensaje en el
servidor.
El proceso de envío de correo electrónico es como sigue:
1. El cliente de correo (MUA) entrega un mensaje destinado a

jperez@linux.com.py al MTA local via SMTP.
2. El servidor MTA local consulta al servidor DNS, cual es la dirección IP del

registro MX para el dominio linux.com.py.
3. El servidor DNS responde con la dirección IP del registro MX para el dominio

linux.com.py.
4. El MTA local contacta con el MTA de linux.com.py y entrega el mensaje vía

SMTP. El MTA de linux.com.py entrega el mensaje al MDA a la espera de
ser retirado.
5. El MUA obtiene el mensaje utilizando POP3/POP3s/IMAP/IMAPs.
Postfix
Postfix es un agente de transporte de correo electrónico (MTA) bastante reciente

que se suma a la lista de alternativas al legendario Sendmail. En su diseño han
primado factores como la seguridad, la eficiencia y la facilidad de configuración y
administración, junto con la compatibilidad con Sendmail y con otros sistemas de
correo. Este producto se desarrolló en el centro de investigación Thomas J.
Watson Research Center, de IBM.
Arquitectura de Postfix
Al contrario de Sendmail, que es un gestor de correo monolítico, en el diseño de

Postfix se han disgregado los diversos tratamientos que se realizan sobre un
mensaje a su paso por un Mail Transfer Agent (MTA), adjudicando cada
tratamiento o grupo de tratamientos a un proceso independiente. El conjunto de
todos estos procesos es Postfix.
Los procesos que conforman Postfix se comunican a través de sockets que se

crean, por razones de seguridad, en un directorio de acceso restringido. La
información que intercambian los diversos procesos es la mínima posible,
limitándose en la mayoría de los casos a la referencia de la entrada en una cola y
la relación de destinatarios, o a un simple identificador de estado.
La siguiente figura proporciona una visión global de los elementos que componen
Postfix:

Postfix basa su funcionamiento en cuatro colas: maildrop, incoming, active y

deferred (cuadrados coloreados en verde).
El correo que se genera de forma local se deposita en maildrop para su posterior

proceso. El proceso pickup toma los mensajes que llegan a maildrop y los pasa a
cleanup, que analiza las cabeceras de los mensajes y deposita éstos en la cola
incoming.
En la cola active se encuentran aquellos mensajes que están en fase de

encaminamiento, y en deferred los mensajes que por diversas causas no se
pueden encaminar o están pendientes de reintentar su encaminamiento.
El proceso qmgr es el encargado de tratar los mensajes que llegan a la cola

incoming, depositarlos en active y lanzar el proceso adecuado para su
encaminamiento, como pueden ser local, smtp o pipe.
El correo procedente de otros sistemas se atiende a través del proceso smtpd,

utilizando el protocolo SMTP, pudiendo utilizar accesos a servidores de RBL o
tablas internas para aplicar las políticas de acceso a cada mensaje entrante.
Coloreadas de azul aparecen las tablas que, creadas por el administrador, sirven a
los diferentes procesos para concretar el tratamiento que debe darse a cada
mensaje. Se usan seis tablas: access, aliases, canonical, relocated, transport y
virtual. Aunque no es obligatoria la existencia ni utilización de todas ellas.
La tabla access permite definir una relación explícita de sistemas a los que se les
deben aceptar o rechazar sus mensajes. La utiliza el proceso smptd.
La tabla aliases, al igual que en Sendmail, define una serie de nombres alternativos
a usuarios locales, y la consulta el proceso local.
El proceso cleanup, mediante la tabla canonical establece relaciones entre

nombres alternativos y nombres reales, ya sean usuarios locales o no.
El proceso qmgr utiliza la tabla relocated para devolver los mensajes de 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:
● Fichero binario indexado (btree, hash, dbm, etc).
● Fichero de texto basado en expresiones regulares ( regexp).
● Sistema externo de base de datos (NIS, LDAP, MySQL, etc).
Para conocer qué tipos de formato de base de datos soporta nuestra instalación, se
puede usar la directiva /usr/sbin/postconf –m.
Para indicar a Postfix el método de acceso a un determinado fichero se antepone al

nombre del mismo el método de acceso. Así por ejemplo hash:/etc/postfix/tabla
indica que /etc/postfix/tabla es un fichero en formato db.
Para crear los ficheros binarios indexados, Postfix dispone de la directiva: postmap.
Por ejemplo, para generar el correspondiente binario del fichero anterior se usaría
la directiva postmap /etc/postfix/tabla, con lo que se crearía el fichero
/etc/postfix/tabla.db.
Archivos de configuración de Postfix
Como Sendmail es el MTA por defecto en CentOS, 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:
● master.cf - Aquí se configuran los procesos que pueden arrancarse y

algunos parámetros como el número de cada uno que puede haber
simultáneamente, etc. Normalmente sólo hay que tocarlo si queremos usar
un sistema alternativo de entrega de correo local (si usamos Cyrus, Courier,
por ejemplo), si queremos integrar un antivirus (ClamAV + AMaViS), etc.
● main.cf - El fichero donde se define gran parte del funcionamiento de Postfix

es main.cf.
EL archivo main.cf
Las directivas mínimas, para tener nuestro Postfix corriendo son las siguientes;
Especifique el nombre de Internet para este host. El valor de esta variable debe ser
un nombre FQDN resoluble a través de consultas DNS. El valor por defecto es
utilizar el nombre de host retornado por gethostname().
myhostname = <Nombre de Internet de este host>
Ej:
myhostname = mail.linux.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 = linux.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 CentOS es
activar solamente la interfaz localhost. Para permitir que nuestro servidor de correo
reciba mensajes de otro sistemas debe configurar para que se active en todas las
interfaces.
inet_interfaces = <Interfaces de red habilitadas para recibir correo>
Ej:
inet_interfaces = all
Especifique los dominios de Internet que este sistema de correo atiende.

mydestination = <Dominio de Internet>
Ej:
mydestination = $myhostname localhost.localdomain localhost $mydomain
Es con este parámetro le estamos indicando a Postfix cuales dominios de Internet

atiende este servidor de correo, es decir, especifica que dominios entregar
localmente, en vez de enviarlo a otras maquinas.
Esta configuración es suficiente para tener un sistema de correo funcional.
Directivas adicionales
La opción queue_directory especifica el lugar de la cola de Postfix. Es también el

directorio raíz de los demonios de Postfix (que corren en entorno chroot).
queue_directory = /var/spool/postfix
Las opciones command_directory y daemon_directory contienen la ruta donde están los

comandos de Postfix y los demonios, respectivamente.
command_directory=/usr/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
dirección de un formato interno a uno público. Incluya entradas como la siguiente
en su tabla canónica:
#
# /etc/postfix/canonical
#
jperez@linux.com.py juan.perez@linux.com.py
plopez@linux.com.py pedro.lopez@linux.com.py
En el archivo main.cf, apunte el parámetro canonical_maps al archivo canonical:
canonical_maps = hash:/etc/postfix/canonical
Asegúrese de ejecutar el comando postmap sobre el archivo canonical y recargue

postfix para que reconozca los cambios en mail.cf:
# postmap /etc/postfix/canonical
# postfix reload
Usuarios reubicados
El parámetro relocated_maps apunta a una tabla de búsqueda donde puede

almacenar una lista de direcciones o dominios que se han movido a otra ubicación:
relocated_maps = hash:/etc/postfix/relocated
La tabla de búsqueda usa las direcciones viejas como la clave y su nueva

ubicación como el valor. Cuando un mensaje es entregado a una dirección
reubicada, Postfix rechaza el intento con un mensaje que indica la nueva dirección
como se especifica en la tabla de búsqueda. Podría listar también un dominio para
indicar que todos los recipientes en ese dominio son rechazados con el mensaje
indicado. El archivo /etc/postfix/relocated contiene entradas como:

jperez@linux.com.py jperez@linuxmail.org
@it.linux.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 linux.com.py y desea que los mensajes
de carácter técnico sean enviados a soporte@linux.com.py, y que los mensajes
enviados a esta dirección sean recibidos por varios miembros del personal de
soporte técnico. Para lograr esto, edite el archivo /etc/aliases y agregue una línea
como la siguiente:
soporte: jperez, plopez@linux.com.py, hgomez@linuxmail.org
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 notificaciones@linux.com.py 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 notificacioens@linux.com.py, 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: postmaster@linux.com.py
Administración de colas
El demonio de administración de colas, qmgr, es en muchas formas el corazón del

sistema Postfix. Todos los mensajes entrantes y salientes, deben pasar a través de
la cola.
El administrador de colas mantiene cinco colas diferentes: incoming, active,

deferred, hold y corrupt. Postfix utiliza un directorio para cada cola bajo la ruta
especificada en el parámetro queue_directory. Por defecto la ruta es
/var/spool/mail, el cual da una estructura de directorio como la siguiente:
/var/spool/mail/active
/var/spool/mail/bounce
/var/spool/mail/corrupt
/var/spool/mail/deferred
/var/spool/mail/hold
La cola incoming es donde los mensajes inicialmente entran a Postfix. El

administrador de colas proporciona protección para el sistema de archivos a través
del parámetro queue_minfree. Por defecto es 0. Puede asegurarse que el disco que
almacena la cola no se quede sin espacio indicando un límite.
De la cola incoming, el administrador de colas mueve el mensaje a la cola active e

invoca al agente de entrega apropiado para manejarlo. Para la mayor parte, si no
existen problemas con la entrega, el movimiento de colas es tan rápido que no verá
mensajes en la cola. Si postfix está intentando entregar a un servidor SMTP lento o
que no está disponible, podría ver mensajes en la cola active. Postfix espera 30
segundos antes de decidir si un sistema remoto no está disponible.
Un mensaje que no pudo ser entregado es ubicado en la cola deferred. Los

mensajes son diferidos solamente si encuentran un problema de entrega temporal,
como un problema DNS o cuando el servidor de destino reporta un problema
temporal. Los mensajes que son rechazados, o encontraron un error permanente,
son retornados inmediatamente al emisor con el reporte y no se quedan en la cola.
Postfix periódicamente verifica la cola para ver si existen mensajes diferidos cuya
marca de tiempo indica que están listos para otro intento de entrega. Intentos
fallidos de entrega subsiguientes provocan que el tiempo de espera para el
reintento se duplique. Puede configurar un tiempo máximo de espera con el
parámetro maximal_queue_lifetime, cuando el tiempo ha expirado, Postfix rechaza el
mensaje y lo envía al emisor. El periodo por defecto es cinco días (5d). Si establece
el valor a 0, el mensaje es retornado inmediatamente.

La cola corrupt es simplemente usada para almacenar mensajes dañados o que no

pueden ser leídos. Si un mensaje está tan dañado como para hacer algo con él,
Postfix lo ubica en esta cola. Los mensajes corruptos son muy raros, pero podrían
ser una indicación de un problema del sistema operativo o del hardware.
Herramientas de gestión de colas
Postfix proporciona herramientas de línea de comandos para mostrar y administrar

los mensajes en la cola. Los comandos principales son postsuper y postqueue,
Puede realizar las siguientes tareas en las colas de mensajes:
● Listar mensajes
● Borrar mensajes
● Retener mensajes
● Reencolar mensajes
● Mostrar mensajes
● Liberar mensajes
Listar mensajes
Puede listar todos los mensajes en la cola con el comando postqueue -p. Postfix
además proporciona el comando mailq para compatibilidad con Sendmail.
# postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
DBA3F1A9 553 Mon May 5 14:42:15 jperez@linux.com.py
(connect to mail.linuxmail.org [192.168.155.63]: Connection refused)
hgomez@linuxmail.org
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 jperez@linux.com.py
(connect to mail.linuxmail.org [192.168.155.63]: Connection refused)
hgomez@linuxmail.org
Para mover el mensaje nuevamente a la cola normal para su procesamiento,

ejecute el comando con la opción -H:
# postsuper -H DBA3F1A9
Reencolando mensajes
Si tiene mensajes que fueron diferidos por problemas de configuración que han
sido corregidos, puede reencolar los mensajes para que sean entregados. El
comando postsuper utiliza la opción -r para reencolar mensajes. Puede especificar
el ID de un mensaje o la palabra ALL para reencolar todo:
# postsuper -r ALL
Mostrando mensajes
El comando postcat muestra el contenido de un archivo en la cola:
# postcat -q DBA3F1A9
Liberando mensajes
Liberar la cola provoca que Postfix intente entregar todos los mensajes
inmediatamente. Puede liberar la cola usando el comando postqueue -f.
# postqueue -f

Mapas de transporte
Postfix puede ser configurado para reenviar a cualquier otro host,

independientemente de como están configurados los registros MX en el servidor
DNS. Conceptualmente, los mapas de transporte sobreescriben los tipos de
transporte por defecto para la entrega de mensajes.
El parámetro transport_maps apunta a uno o más tablas de búsqueda de transporte.

La siguiente entrada configura el archivo /etc/postfix/transport como una tabla de
búsqueda de transporte:
transport_maps = hash:/etc/postfix/transport
La clave de una tabla de búsqueda de transporte es una dirección de correo

completa o dominios y subdominios. Cuando una dirección de destino o de dominio
coincide con la clave, utiliza el valor de la derecha para determinar el método de
entrega y el destino. El formato de los valores de la derecha pueden variar
dependiendo del tipo de transporte, pero generalmente tiene el formato de
transporte:host:puerto. Por ejemplo:
#
# Transport map
#
linux.com.py smtp:[192.168.0.1]:20025
#
Todos los mensajes destinados a linux.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
#
linux.com.py relay:[gateway.linux.com.py]
#
Todos los mensajes destinados para linux.com.py son reenviados usando el

transporte relay al host gateway.linux.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
#
linux.com.py smtp
#
Todos los mensajes destinados a linux.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
#
jperez@linux.com.py error:no se aceptan mensajes para jperez
#
El mensaje de transporte especial error provoca que los mensajes sean

rechazados, luego del dos puntos, especifique el reporte del por qué el mensaje fue
rechazado.
Gateway de reenvío interno
Un mail gateway es un sistema de correo que acepta mensajes y reenvía a otro

sistema. Mail gateways son comúnmente utilizados en conjunto con sistemas de
firewall para limitar el número de servidores que necesitan acceso directo a
Internet.
Suponga que tiene instalado un mail gateway en la DMZ, gateway.linux.com.py, y

desea que este reenvíe los mensajes recibidos a un host en la HSZ,
mail.linux.com.py. El siguiente procedimiento demuestra como configurar
gateway.linux.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
linux.com.py y que apuntan a gateway.linux.com.py.
2. En el archivo de configuración main.cf, configure relay_domains:
relay_domains = linux.com.py
3. Asegúrese que el parámetro transport_maps apunta a su tabla de búsqueda

de transporte:
transport_maps = hash:/etc/postfix/transport
4. Agregue la entrada al archivo transport para reenviar los mensajes

destinados a linux.com.py al servidor interno:
#
# transport maps
#

linux.com.py relay:[mail.linux.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.linux.com.py envíe mensajes hacia la Internet sin
tener una conexión directa, éste debe enviar los mensajes a gateway.linux.com.py
y éste a su vez reenviarlos hacia la Internet.
Para permitir esto, asegúrese que el parámetro mynetworks incluye la dirección IP

del servidor de correo interno.
1. En el servidor mail.linux.com.py, configure el parámetro mynetworks para

asegurarse que incluye todos los clientes del sistema.
2. Configure los MUA para utilizar mail.linux.com.py como servidor de correo

SMTP.
3. En el archivo mail.cf, configure el parámetro relayhost para apuntar a

gateway.linux.com.py:
relayhost = [gateway.linux.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.linux.com.py son reenviados a

gateway.linux.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 = linux.com.py
Direcciones como jperez@servidor1.linux.com.py son convertidas a

jperez@linux.com.py.
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.linux.com.py y suc2.linux.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.linux.com.py suc2.linux.com.py linux.com.py
Con esta configuración, la dirección jperez@serv1.suc1.linux.com.py coincide con

suc1.linux.com.py y se convierte en jperez@suc1.linux.com.py. La dirección
plopez@serv2.suc2.linux.com.py coincide con suc2.linux.com.py y se convierte en
plopez@suc2.linux.com.py. Finalmente, hperez@serv3.linux.com.py coincide con
linux.com.py y se convierte en hperez@linux.com.py
Puede excluir ciertas cuentas del enmascaramiento. Por ejemplo, si desea que una
dirección como root@serv1.linux.com.py se mantenga intacto, agregue la cuenta al
parámetro masquerade_exceptions:
masquerade_exceptions = admin, root, oracle
Sendmail
La mayoría de las distribuciones de GNU/Linux incluyen de manera predeterminada

Sendmail, un poderoso servidor de correo electrónico ampliamente utilizado
alrededor del mundo. Este requiere de una correcta configuración para su mejor
aprovechamiento y poder disponer de un nivel de seguridad aceptable.
Es muy común que los administradores inexpertos no se molesten siquiera en

establecer un nivel de seguridad apropiado en sus redes locales, y mucho menos
en el servidor de correo, el cual ven como un servicio más. Es un error común el
configurar Sendmail para que permita enviar correo como sea a cualquier costo.
Usualmente este costo significa convertirse en Open Relay, y por lo tanto en un
paraíso para personas que se dedican al envío masivo de correo comercial (Spam).
Confirmando la instalación de Sendmail
Debe tener instalados los paquetes sendmail y sendmail-cf. Para asegurarse de

esto, se puede utilizar la siguiente línea de comando:

rpm -q sendmail sendmail-cf
Debe instalar sendmail-cf o no le será posible compilar los archivos necesarios

para configurar Sendmail.
Configurando Sendmail
Sendmail utiliza dos archivos de configuración, /etc/mail/submit.cf cuando un

usuario en el equipo local envia un nuevo mensaje y /etc/mail/sendmail.cf para
todas las otras funciones que incluyen al demonio mail. Los archivos de
configuración *.cf son generados a partir de archivos macro *.mc que son
expandidos por el procesador de macros m4.
Antes de continuar, debemos editar el fichero /etc/mail/local-host-names, en el cual

deberemos de listar todos y cada uno de los aliases que tenga el servidor que
estamos configurando, así como los posibles sub-dominios. Es decir, todos los
dominios para los cuales estaremos recibiendo correo en un momento dado.
# Incluya aquí todos los dominios para los que
# recibimos correo
localhost
localhost.localdomain
linux.com.py
mail.linux.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 linux.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(linux.com.py)dnl
Luego se procesa con el siguiente comando para generar /etc/mail/sendmail.cf
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Control de RELAY
Para permitir el uso de nuestro servidor de correo desde ciertos dominios o

direcciones IP se pueden utilizar distintos métodos.
El mas simple es agregar los nombres de dominio necesarios al archivo

/etc/mail/relay-domains.
Deben definirse los dominios para los cuales se estará permitiendo enviar correo
electrónico. Esto se hace generando el fichero /etc/mail/relay-domains:
# Permitir el dominio linux.com.py

linux.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:
● OK Acepta el correo inclusive si otras reglas lo rechazarían, por ejemplo

nombre de dominio no puede ser resuelto.
● RELAY Acepta el correo dirigido al dominio indicado o recibido del dominio

indicado por el servidor SMTP.
● REJECT Rechazar el correo con un mensaje de error genérico.
● DISCARD Descartar el mensaje utilizando la propiedad $#discard del sistema

de correo.
● TEXTO DE ERROR Cualquier mensaje de error que cumple con RFC 821.
Para habilitar la opción de la base de datos de acceso, se debe utilizar la siguiente

declaración en su fichero sendmail.mc:
FEATURE(access_db,`hash -T<TMPF> -o /etc/mail/access.db')dnl
Abrimos ahora el archivo /etc/mail/access y agregamos algunas líneas para definir

quienes podrán hacer uso de nuestro servidor de correo para poder enviar
mensajes:
# Por defecto, solo se permite enviar correo desde localhost...
localhost.localdomain 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

linux.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
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 /etc/aliases, se debe asegurar de ejecutar el

programa:
# /usr/bin/newaliases
para reconstruir la base de datos que sendmail utiliza internamente. La orden

/usr/bin/newaliases es un vínculo simbólico al ejecutable de sendmail y, cuando se
invoca de esta forma, se comporta exactamente como si hubiese sido invocado así:
# /usr/lib/sendmail -bi
La orden newaliases es una forma alternativa y más adecuada para hacer esto.
Cómo usar un anfitrión inteligente
Algunas veces un anfitrión encuentra correo que no puede entregar directamente a

un sitio remoto. Con frecuencia es conveniente tener un único sitio en una red que
tenga el papel de gestionar la transmisión del correo a sitios remotos que son
difíciles de alcanzar, en vez de que cada sitio local intente hacer esto por sí mismo.
Una organización puede elegir instalar una red IP privada y utilizar sus propias
direcciones IP no registradas. La red privada se puede conectar a Internet
mediante un cortafuegos. El enviar el correo desde y hacia los diversos anfitriones
dentro de la red privada hacia el mundo exterior utilizando SMTP no será posible
en una configuración convencional debido a que los sitios locales no pueden
establecer una conexión directa de red a los sitios que están en Internet. En
cambio, la organización puede optar por que el cortafuegos tenga la función de
anfitrión inteligente. El anfitrión inteligente que se ejecute en el cortafuegos será
capaz de establecer conexiones directas de red con los sitios que se encuentran
tanto en el interior de la red privada como en el exterior de ella. El anfitrión
inteligente puede aceptar correo de ambos anfitriones, de los que están en la red
privada y de los que están en Internet, el correo se guarda en un almacenamiento
local y luego se gestiona la retransmisión de ese correo directamente al sitio
adecuado.
Los anfitriones inteligentes se utilizan en general cuando todos los otros métodos
de entrega han fallado.
Sendmail provee de un método simple para configurar un anfitrión inteligente

utilizando la opción SMART_HOST. Las porciones relevantes de nuestra configuración
que definen al anfitrión inteligente son:

define(`SMART_HOST', `mail.isp.net')
No se necesita especificar que el transporte es SMTP, ya que está dicho por

omisión.
Central de correo
Para transferir toda la mensajería local (la que llega) pero debidamente cualificada
a un host determinado se puede emplear la variable MAIL_HUB. Ejemplo:
define(`MAIL_HUB', `smtp:otrohost.localdomain')dnl
Habilitando los servicios POP3 e IMAP
Puede habilitar los servicios ipop3 (POP3 tradicional, autenticación en texto plano),
pop3s (POP3 seguro, autenticación con criptografía), imap (IMAP tradicional,
autenticación en texto plano) e imaps (IMAP seguro, autenticación con criptografía).
Utilice aquellos que consideré como más apropiados para su red local de acuerdo a
las capacidades de los clientes de correo electrónico utilizados. Tome en cuenta
que la autenticación por medio de texto plano es definitivamente un método
inseguro, y siempre serán mejor usar los servicios que permitan establecer
conexiones seguras.
Dovecot
El paquete dovecot proporciona los servicios POP/IMAP. Edite el archivo de

configuración /etc/dovecot.conf para habilitar los protocolos pop3 e imap. Para ello,
modifique la siquiente línea del archivo de configuración:
protocols = imap imaps pop3 pop3s
Luego, inicie el servicio dovecot y habilite para su ejecución durante el arranque del
sistema:
# service dovecot start
# chkconfig dovecot on
Configuración de Webmail
SquirrelMail es una aplicación web basada en PHP que se ejecuta en el servidor

Apache y permite a los usuarios acceder y leer su correo electrónico desde una
ubicación remota a través de un navegador web. La aplicación solamente soporta

casillas de correo Imap, no POP3, por tanto su servidor de correo debe priveer
acceso Imap. El paquete dovecot e imap soportan ambos protocolos y también
encriptación TLS. SquirrelMail tiene muchos plugins extra que han sido
desarrollados para él.
El paquete tiene dos archivos de configuración, uno que habilita la aplicación en

Apache y otra que contiene las configuraciónes PHP. El archivo de configuración
de SquirrelMail para Apache es:
/etc/httpd/conf.d/squierrelmail.conf
El archivo de configuración contiene un alias que apunta al directorio principal de

SquierrelMail y puede ser visualizado ejecutando http://nombre_servidor/webmail.
El archivo de configuración del SquierrelMail es el archivo:

/etc/squirrelmail/config.php
El archivo de configuración es muy fácil de entender. Lo mas importante que debe

configurar el el nombre del dominio, dónde estan ubicadas las casillas de correo y
el servidor utilizado para enviar los mensajes de salida. Si SquierrelMail se está
ejecutando en el mismo servidor de correo, entonces puede dejar los valores en
localhost:
$domain = 'linux.com.py';
$imapServerAddress = 'localhost';
$imapPort = 143;
$useSendmail = true;
$smtpServerAddress = 'localhost';
$smtpPort = 25;
$sendmail_path = '/usr/sbin/sendmail';
$pop_before_smtp = false;
$imap_server_type = 'uw';
Una de las mayores consultas realizadas acerca de cualquier sistema webmail, es

como cambiar el tamaño de los adjuntos que pueden ser enviados. Esto es en
realidad una configuración PHP. Es necesario cambiar los valores en el archivo
/etc/php.ini. Para ello edite el archivo /etc/php.ini y configure las siguientes
opciones:
upload_max_filesize = 2M
post_max_size = 2M

11
Secure Shell
Secure Shell
Secure Shell
Uno de los aspectos mas importantes de cualquier sistema de computación en red

es la posibilidad de administrarlo totalmente desde una ubicación remota como si
estuviese sentado frente a la terminal. Existen aplicaciones como telnet, rcp y
rlogin que permiten la administración remota de sistemas, sin embargo, estos
programas son obsoletos y son un riesgo de seguridad, principalmente porque la
comunicación no está encriptada.
OpenSSH es un conjunto de aplicaciones que proporcionan un enlace encriptado

entre la estación de trabajo del administrador y el host remoto, esto asegura que
cualquier detalle de la información transferida, como la información de inicio de
sesión, se mantenga confidencial.
El demonio SSH
El demonio SSH actúa como el servidor que escucha y maneja las conexiones
entrantes de los clientes. En su configuración por defecto, el demonio maneja todos
los requerimientos para la generación y rotación de claves criptográficas, por tanto
se discutira como ajustar los parámetros operacionales del servidor.
El archivo de configuración para el servidor SSH es el archivo:

/etc/ssh/sshd_config
SSH opera por defecto en el purto TCP 22 y escucha en todos los dispositivos de
red instalados. El demonio openssh ademas soporta versiones 1 y 2 del protocolo
ssh los cuales están habilitados por defecto.
La version 1 del protocolo SSH es vulnerable a un fallo de seguridad donde un

atacante puede introducir datos malignos en un enlace seguro, por tanto es
recomendado la utilización de protocolo version 2 solamente.
Port 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

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.

Secure Shell
Control del servicio SSH
Una vez configurado el servidor sshd, puede habilitar la ejecución del servicio
durante el inicio del sistema utilizando los siguientes comandos:
# chkconfig –level 345 sshd on
# chkconfig –list
El servicio puede ser iniciado o reiniciado inmediatamente, usando los siguientes

comandos:
# service sshd start
# service sshdd restart
Uso de SSH
Para conectarse a un servidor a través de ssh, utilice cualquier de los siguientes

comandos:
$ ssh usuario@host
$ ssh host -l usuario
Si no especifica el nombre de usuario, intentará conectarse al sistema remoto con

el mismo usuario que utiliza en el sistema local.
La primera vez que inicia sesión en un servidor remoto, usted sera advertido que la
identidad del servidor no puedo ser establecida. Si esta seguro de la identidad del
host, puede aceptar el certificado presentado. Una copia es guardada en el archivo
~/.ssh/known_hosts. Usted vera un mensaje similar al siguiente:
$ ssh alice@galaxy.linux.com.py
The authenticity of host 'galaxy.linux.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.linux.com.py ' (RSA) to the list of known
hosts.
alice@galaxy.linux.com.py 's password:
Una vez autenticado, entrará al prompt del sistema remoto. A partir de ese
momento puede ejecutar cualquier comando en el sistema remoto.
Puede darse la situación que el par de claves del servidor es reemplazada, esto
puede deberse a una reinstalación por ejemplo. Si este es el caso, la clave pública
almacenada anteriormente en el archivo ~/.ssh/known_hosts causará un conflicto
con la nueva clave pública. Esto provocará que el cliente rechace la conexión,
suponiendo que pueda ser un fraude.

Secure Shell
# ssh alice@galaxy.linux.com.py
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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.linux.com.py has changed and you have requested strict
checking.
Host key verification failed.
El mensaje de advertencia anterior indica que la huella digital de las claves han
cambiado. Debe confirmar cualquier cambio que ha ocurrido en el sistema remoto
antes de intentar corregir este error.
Una vez verificada la identidad del host remoto nuevamente, deberá eliminar la
clave pública guardada en el archivo ~/.ssh/known_hosts. Para ello, edite el archivo y
elimine la clave pública que corresponde con el host.
Cliente SSH para Windows
PuTTY es un cliente Telnet y SSH gratuito escrito y mantenido por Simon Tatham.
El cliente y el código fuente pueden ser descargados de:
http://www.chiark.greenend.org.uk/~sgtatham/putty
Transferencias de archivos de forma segura
El demonio SSH puede ejecutar un subsistema de aplicaciones que pueden tomar

venaja del entorno seguro proporcionado por los protocolos criptográficos, uno de
estos subsistemas es sftp (Secure File Transfer Protocol). El servidor sftp
proporciona al los usuarios la posibilidad de iniciar sesión de tal forma a que
puedan transferir archivos de forma confidencial.
El servidor sftp no debe ser confundido con FTPS disponible en vsftpd. Si bien
ambos sistemas proporcionan la capacidad de encriptar la comunicación, existen
diferencias en como pueden ser implementados.
Para conectarse a un servidor sftp, utilice el siguiente comando:
$ sftp usuario@host
Si no especifica el nombre del usuario, intentará conectarse con el mismo usuario

que está usando en el sistema local.

Secure Shell
Una vez conectado, tiene disponible los comandos mas comunes de transferencias
de archivos de FTP, utilice el comando help para obtener la lista de comandos
permitidos.
Secure copy
El scp s el reemplazo de rcp, y permite la copia de archivos entre el sistema local y

remoto de una forma bastante parecida a si estuviera copiando archivos de un
directorio a otro dentro del mismo servidor. La aplicación scp permite copia de
archivos de forma no interactiva.
La sintaxis del comando para copiar un archivo del equipo local al equipo remoto
es:
$ scp [opciones] archivo [...] [usuario]@host:[/ruta/de/destino]
Por ejemplo:
Para copiar el archivo local reporte.txt al sistema galaxy.linux.com.py en el

directorio /tmp iniciando sesión con usuario bob, ejecute:
$ scp /tmp/reporte.txt bob@galaxy.linux.com.py:/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.linux.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.linux.com.py, ejecute:
$ scp bob@galaxy.linux.com.py:/tmp/reporte.txt /backup
$ scp galaxy.linux.com.py:/tmp/*.txt .
Para copiar de forma recursiva el directorio /reportes del sistema remoto al

directorio /backup local, utilice la opción -r:
$ scp -r galaxy.linux.com.py:/reportes/ /backup

12
Network Time Protocol

Network Time Protocol (NTP)
NTP (Network Time Protocol) es un protocolo de comunicaciones que permite

sincronizar el reloj de un ordenador que este conectado a la red con un servidor
central de tiempo. Con ello lograremos una exactitud del orden de milisegundos en
una red local.
El NTP implementa un modelo jerárquico de sincronización. En la cumbre se

encuentran los servidores de tiempo stratum 1, computadoras conectadas en forma
directa a dispositivos conocidos como "relojes de referencia" (ó stratum 0), de
altísima precisión. Estos dispositivos pueden ser relojes atómicos, receptores
Global Positioning Systems (GPS) o receptores de radio. Cualquier servidor que
obtenga la referencial de tiempo de un stratum 1 pasa a ser un stratum 2 y así
sucesivamente.
La sincronización del tiempo es vital para millones de computadoras que

intercambian informaciones: personas que comparten bases de datos, que
procesan transacciones de diversos tipos, tales como comercio electrónico y
personal banking. Es justamente en este ambiente abierto, en el cual se comparten
informaciones, que la necesidad de una referencia de tiempo común, exacta y
confiable se hace imprescindible
Convenciones generales
Hay varios conceptos y acrónimos utilizados cuando se configura un servidor NTP:
● GMT (Greenwich Mean Time) - Es la hora del meridiano de Greenwich,

población cercana a Londres. Se usó esa porque fué la usada por la
"Britain's Royal Navy" durante el sigo XIX. El meridiano también pasa por
España.
● UTC (Universal Time Coordenated) - Básicamente lo mismo que la hora

GMT, pero ya sincronizado con relojes atómicos. Es estándard y ya no hace
referencia a un sitio en concreto.
● Zulú o Z - En la segunda guerra mundial abreviaban "GMT" por "Z", y según

el alfabeto internacional de comunicaciones la Z se pronuncia Zulú
● CET (Central European Time) - Hora Central Europa, es UTC+1. Donde

está España excepto las Canarias.
● CEST (Central European Summer Time) - Hora central Europea en

verano, UTC+2. Donde está España excepto las Canarias.
● WET (Western European Time) - Hora de Europa del Oeste, donde están

las Canarias. Es la misma que UTC.
● WEST (Western European Summer Time) - Hora de Europa del Oeste en

verano, donde están las Canarias. Es UTC+1
● DST (Daylight Summer Time) - Así se llama el periodo que estamos en

ahorro de luz de verano.
● PYT (Paraguay Time) - Horario normal de Paraguay.
● PYST (Paraguay Summer Time) - Horario de verano de Paraguay.
Zonas horarias
Las zonas horarias son divisiones geográficas del globo terráqueo de 15° cada
una. Iniciando en Greenwich, creadas para ayudar a las personas a saber que hora
es en otra parte del mundo.
Por razones de ahorro de energía, se utiliza el horario de verano, conocido como

Dailyght Savings Time (DST), que son variaciones de la zona horaria.
Las zonas horarias generalmente son definidas por el gobierno de un país o un

instituto astronómico y es representado por 3 o cuatro letras, por ejemplo PYT o
PYST.
Daylight Savings Time
Por razones de ahorro de energía, los gobiernos han creado el horario de verano o
DST. Los relojes son adelantados una hora y esto hace que los dias parezcan mas
largos. Lo que sucede en realidad es tan solo “un cambio en la zona horaria”. El
tiempo primitivo (UTC) es y seguirá siendo el mismo.
Los archivos de zona horaria
Durante la instalación del sistema operativo Linux, se selecciona la zona horaria.

Esta configuración se encuentra almacenada en el archivo /etc/sysconfig/clock.
El archivo /etc/localtime es el archivo de zona horaria y es una copia de alguno de

los ficheros de zona que se encuentran en el directorio /usr/share/zoneinfo. Estos
ficheros son binarios no pueden ser editados directamente.
En el fichero de zona se especifica la fecha en la que comienza y termina el horario

de verano para una zona dada. Por ejemplo, el fuente de un fichero de zona para
America/Asuncion es como sigue:

# Paraguay
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Para 2003 only - Oct 16 0:00 1:00 S
Rule Para 2004 only - Mar 31 0:00 0 -
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Asuncion -4:00 Para PY%sT
El bloque Rule define la fecha y la hora en la que el horario de verano se aplica,

mientras que el bloque Zone hace referencia a regla (Rule) que lo gobierna. Note
que el nombre de Zone el el nombre del fichero en el directorio /usr/share/zoneinfo.
Para configurar la sincronización de hora a través de NTP, la configuración de la

zona horaria debe ser correcta.
Como es habitual que en nuestro país, el cambio de hora no se haga en la misma

fecha, es necesario modificar el archivo fuente de la zona y especificar la duración
del horario de verano. En este caso deberían agregarse dos reglas, para indicar
cuando inicia y cuando termina el horario de verano, por ejemplo, modificando el
archivo paraguay.zic anterior seria:
# Paraguay
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Asuncion -4:00 Para PY%sT
Una vez modificado el archivo fuente de zona, es necesario compilarlo con el

comando zic. Para ello ejecute:
# zic paraguay.zic
Luego, debera copiar el archivo /usr/share/zoneinfo/America/Asuncion a

/etc/localtime:
# cp /usr/share/zoneinfo/America/Asuncion /etc/localtime
Puede verificar que las configuraciones fueron realizadas con el comando zdump.
# zdump -v America/Asuncion
Como mencionamos anteriormente, los servidores NTP siempre proporcionan la

información de hora en horario UTC. Es el archivo de zona el que determina la
cantidad de horas que se deben sumar o restar al horario UTC y también en que
momento inicia el horario de verano. Por lo tanto, una vez llegada la fecha y la hora
indicada, no es necesario realizar ninguna operación adicional. No es necesario
modificar la hora manualmente.

El proyecto pool.ntp.org
El proyecto se nutre de servidores horarios de todo el mundo que se unen de forma

voluntaria. El sistema se basa en asignar el mismo nombre a varias máquinas en el
DNS (round robin), con lo que cada vez que solicitamos una dirección, recibimos
una contestación distinta. Este es un método sencillo pero muy útil para repartir la
carga.
Esta asignación de direcciones se basa en una jerarquización por situación

geográfica, añadiendo cada servidor a la zona DNS correspondiente a su país, a su
continente y a la zona mundial que los engloba a todos, bajo el dominio
pool.ntp.org. Por ejemplo north-america.pool.ntp.org, south-america.pool.ntp.org,
europe.pool.ntp.org, oceania.pool.ntp.org.
Si consultamos al DNS la dirección IP de south-america.pool.ntp.org veremos como

no obtenemos una respuesta única.
# dig south-america.pool.ntp.org
; <<>> DiG 9.3.1 <<>> south-america.pool.ntp.org

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31674
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 5, ADDITIONAL: 5
;; QUESTION SECTION:
;south-america.pool.ntp.org. IN A
;; ANSWER SECTION:
;; ANSWER SECTION:
south-america.pool.ntp.org. 1420 IN A 200.141.215.162
De forma periódica, se comprueba el estado y fiabilidad de los servidores

implicados (recordemos que se trata de voluntarios sin ninguna garantía de
operatividad). Para ello, las zonas DNS se actualizan aproximadamente cada hora
a partir de los datos de servidores que velan por el correcto funcionamiento de
todos los servidores monitoreando su estado mediante las herramientas que NTP
proporciona. De esta forma, aquellos servidores que quedan desconectados o,
sencillamente, no ofrecen una hora razonablemente buena, son eliminados
temporalmente.
El sistema se basa en la asignación de una puntuación entre dos extremos: si un

servidor está funcionando bien, se le suman puntos, si no, se le restan. Cuando
alguno de ellos tiene una puntuación por debajo del umbral establecido, se retira
del DNS y se sigue vigilando para una futura reincorporación.

El método hace que las puntuaciones bajen muy deprisa en caso de mal
funcionamiento, pero tarden un poco más en subir, asegurando así que no existen
servidores malos en el sistema.
Configuración de NTP
La configuración de NTP se realiza a través del archivo /etc/ntp.conf.
En el archivo de configuración, existe una regla por defecto que aplica cierta
seguridad a la configuración NTP.
restrict default nomodify notrap noquery
Esta regla permite la sincronización con los servidores NTP, pero no permite que
los servidores NTP consulten o modifiquen el servicio en nuestro sistema.
En la sección OUR TIMESERVERS debemos configurar los servidores NTP.
# --- OUR TIMESERVERS -----

server south-america.pool.ntp.org
Lo más interesante del fichero de configuración son las lineas que nos indican qué
servidores vamos a usar para sincronizarnos. Como se puede notar, todas ellas
son iguales, aprovechando la resolución DNS que hemos explicado más arriba. De
esta forma, obtenemos tres servidores distintos con los que actuar.
Si desea utilizar otros servidores NTP puede consultar la lista de servidores NTP
publicos en http://www.eecis.udel.edu/~mills/ntp/servers.html.
driftfile /var/lib/ntp/drift
La opción driftfile especifica qué fichero se utiliza para almacenar el

desplazamiento de la frecuencia de reloj de la máquina. El servicio “ntpd” utiliza
este valor para automáticamente compensar el desvío que experimenta de forma
natural el reloj de la máquina, permitiendo mantener una precisión acotada incluso
cuando se pierde la comunicación con el resto de referencias externas.
Inicio del servicio NTP
Antes de iniciar el demonio ntpd, ejecute el comando ntpdate para sincronizar el

reloj con el servidor de horario. NTP no sincronizará su reloj con un servidor de
horario si la hora local esta significativamente desfasada a la del servidor NTP.
# ntpdate -u south-america.pool.ntp.org
Como una alternativa, puede agregar los servidor NTP al archivo /etc/ntp/step-

tickers. De esta forma usted no necesita sincronizar manualmente el reloj, ntp

consultará estos servidores si la hora esta muy desfasada con respecto a la hora
NTP durante el inicio del servicio.
Configure el servicio para iniciar automáticamente al siguiente reinicio:

# chkconfig ntpd on
Inicie el servicio inmediatamente ejecutando el comando:

# service ntpd start
Es posible utilizar la herramienta system-config-date para administrar NTP.
Verificación de NTP
El comando ntpq es util para consultar servidores NTP remotos y verificar la

configuración y operación del servicio.
Utilice el comando ntpq siempre que necesite:
● Verificar que ntpd puede formar asociaciones con otros hosts NTP
● La sincronización esta funcionado correctamente
Luego que ha iniciado el servidor ntpd ejecute el comando ntpq con la opción -p:
# ntpq -p
El resultado del comando sera algo similar al siguiente:

# ntpq -pn
remote refid st t when poll reach delay offset jitter

==============================================================================
-80.34.215.206 213.144.140.154 3 u 143 256 377 126.321 24.212 0.798
+130.206.130.95 129.132.2.21 2 u 74 256 377 68.792 -8.019 2.836
*217.127.249.18 193.79.237.14 2 u 88 256 377 110.388 -6.299 1.346
80.38.245.22 130.206.3.166 2 u 74 256 377 942.683 -397.04 399.034
+193.45.254.143 212.94.162.1 3 u 80 256 375 87.577 -2.074 100.146
Cada columna mostrada se describe como sigue:
● remote: La columna remote lista los hosts especificados en el archivo de

configuracion local. Los hosts pueden estar precedidos con los siguientes
caracteres especiales:
* Indica que es la fuente actual de sincronización.
# Indica que el host ha sido seleccionado para sincronización, pero la

distancia desde el host al servidor ha excedido el maximo valor.

oIndica que el host es seleccionado para sincronización y la señal PPS esta

en uso.
+ Indica que el host ha sido includo en el conjunto de selección final.
x Indica que el host es designado como “false ticker” por el algoritmo de

sincronización
. Indica que el host es seleccionado del final de la lista de candidatos.
- Indica que el host ha sido descartado por el algoritmo de clustering.
Vacío o en blanco Indica que el host ha sido descartado debido a un alto

stratum o fallo las verificaciónes de sanidad.
● refid: La columna indicador de referencia indica la actual fuente de

sincronización para el host remoto. WWVB indica que el host utiliza un radio
reloj.
● st: La columna stratum indica que nivel de stratum para el host remoto.
● t: La columna tipo denota los tipos disponibles que incluyen:
l = local (como un relog GPS)
u = unicast
m = multicast
b = broadcast
- = netaddr (normalmente 0)
● when: La columna when indica la cantidad de segundos desde que la

respuesta del host remoto fue recibida.
● poll: El periodo de poll indica el intervalo de consulta al host remoto.
● reach:La columna reach indica que tan exitosos son los intentos de alcanzar
un servidor. El valor 001 indica que la prueba mas reciente fue contestada,
mientras 357 indica que una respuesta no fue contestada. El valor 377 indica
que todas las pruebas recientes fueron contestadas.
● delay: La columna delay indica el tiempo (en milisegundos) que toma en

retornar el paquete de respuesta a una consulta.
● offset: La columna offset indica la diferencia de tiempo (en milisegundos)

entre el reloj del servidor y el reloj des cliente. Cuando este numero excede
128, el mensaje de “synchronization lost” aparece en el archivo de registro.
● disp:La columna dispersión indica la diferencia en la medida del offset entre

dos muestras. Este es un estimativo de error. La dispersión es un valor para
medir la calidad del servicio de red.
Aquí vemos cómo tomamos como referencia el tercero de los servidores (*), siendo
el segundo y el quinto (+) alternativas a tener en cuenta que entran en el cálculo de
la hora, descartando momentáneamente los demás.
Con ntptrace conoceremos cuál es el origen de nuestra hora:
# ntptrace -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.

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 Compruebe que el adaptador está

responde ningún host al comando ping. recibiendo paquetes con el comando
ifconfig. Si no, puede ser un problema
con el cable de red, el switch o el
adaptador de red.
Verifique la configuración de la dirección
IP y la máscara de sub red.
Detenga los servicios de firewall y
pruebe nuevamente.
Verifique la configuración de los
archivos host, ifcfg-ethX, resolv.conf.
No es posible alcanzar un host remoto Verifique la configuración de las rutas

con el comando netstat -r.
Compruebe la configuración de los
firewalls que se encuentran en el
camino al host.
Un servicio de red no inicia. Muchos servicios proveen archivos de

registros propios, verifique estos
archivos generalmente ubicados en el
directorio /var/log.
Busque referencias al error el archivo
/var/log/messages, /var/log/secure, etc.

Problema Acción a tomar
El servicio de red inicia pero no es Compruebe la configuración del firewall.

posible acceder a él. 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.

LE 202 Linux Enterprise Servicios de Red

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

LE 202 Linux Enterprise Servicios de Red

Cargado por

Copyright:

Formatos disponibles

LE-202 - Linux Enterprise / Servicios de red

3 Ing. Ivan Ferreira

Red Hat Certified Engineer 4

5 Ing. Ivan Ferreira

Red Hat Certified Engineer 6

7 Ing. Ivan Ferreira

Red Hat Certified Engineer 8

Introducción al protocolo TCP/IP

Familia de Protocolos TCP/IP

Las direcciones de Internet pueden ser simbólicas o numéricas. La forma simbólica

Primeramente examinaremos la forma numérica, denominada dirección IP. La

Red Hat Certified Engineer 10

Las direcciones IP son números de 32 bits representados habitualmente en formato

El formato binario para la dirección IP 128.2.7.9 es:

Hay cinco clases de direcciones IP:

Solo las clases A, B y C son utilizadas para redes empresariales.

11 Ing. Ivan Ferreira

Las direcciones de clase D se reservan para multicasting o multidifusión, usada

Las direcciones de clase E se reservaron para usos en el futuro.

Las direcciones IP se clasifican en:

● Direcciones IP públicas. Son visibles en todo Internet. Un ordenador con

● Direcciones IP privadas (reservadas). Son visibles únicamente por otros

A su vez, las direcciones IP pueden ser:

● Direcciones IP estáticas (fijas). Un host que se conecte a la red con

● Direcciones IP dinámicas. Un host que se conecte a la red mediante

Red Hat Certified Engineer 12

● 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

● 127.0.0.0 esta reservada para la tarjeta de red loopback en cada host

● Todos los bits de la porción de hosts a 0: Ej. 192.168.0.0 Este es el

● Todos los bits de la porción de hosts a 1: Ej. 192.168.255.255 Este es el

Por ejemplo, la máscara de subred que se utiliza normalmente con la dirección IP

13 Ing. Ivan Ferreira

Normalmente, los valores predeterminados de máscara de subred (como se

En algunos casos, puede utilizar máscaras de subred personalizadas para

Al personalizar la longitud de la máscara de subred, puede reducir el número de

Para evitar problemas de direcciones y enrutamiento, debe asegurarse de que

El problema que se nos plantea es cómo podemos conocer la dirección física de la

Red Hat Certified Engineer 14

Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar

Campo de tipo Tipo de mensaje ICMP

--- mercurio.linux.com.py ping statistics ---

Es posible notar claramente la secuencia de paquetes ICMP utilizados para

15 Ing. Ivan Ferreira

IP multicast . El IP multicast es una variante de IP que permite emplear datagramas

UDP (User Datagram Protocol - Protocolo de Datagrama de Usuario)

TCP (Transmission Control Protocol - Protocolo de Control de la

Comparación de TCP y UDP

El TCP es un protocolo de comunicación entre dos máquinas con:

● Acuse de recibo de cada paquete

● Control de no duplicidad de paquetes

Red Hat Certified Engineer 16

● Inmune a la llegada desordenada de paquetes

● Inmune a la perdida de paquetes (se solicitan otra vez)

Los problemas fundamentales que requerían un rediseño del protocolo incluyen:

● Mayor espacio de direcciones IP.

● Eliminar la necesidad de utilizar NAT.

● Simplificar la reorganización de redes y renumeración de direcciones.

● Proporcionar mecanismos de Calidad de servicio (QoS).

● Seguridad con IPsec para autenticación y encriptación integrada.

Un ejemplo de dirección IPv6 es el siguiente:

17 Ing. Ivan Ferreira