4. Protocolos de soporte y de usuario

Indicadores de Logros

4.1. Lectura: Protocolos de soporte y de usuario

4.1.1. Configuración de servicios básicos

Cómo se presentó en la lectura de la sección Redes, protocolos e Internet cada servicio que su sistema ofrezca requiere un proceso daemon que esté pendiente de atender conexiones. Para disminuir el número de procesos que deberían estar activos esperando conexiones por cada servicio, el programa inetd que se inicia durante el arranque de su sistema (con /etc/init.d/inetd, ver Inicialización del sistema) espera conexiones en diversos puertos y cuando recibe una inicia el daemon apropiado.

inetd se configura en el archivo /etc/inetd.conf que puede referenciar servicios por nombres si estos están listados en /etc/services o en /etc/rpc y protocolos listados en /etc/protocols. Debian inlcuye versiones de estos archivos listas para servir telnet, talk, finger, hora local y correo (smtp).

Cada línea del archivo /etc/inetd.conf puede ser un comentario (si comienza con el caracter "#") o puede ser análoga a:

smtp            stream  tcp     nowait  mail    /usr/sbin/exim exim -bs 

que indica que el servicio smtp, se maneja con conexiones[210] tipo stream del protocolo tcp, sin espera. Cada vez que haya una conexión para este servicio se iniciará el programa /usr/sbin/exim con argumentos[211] exim -bs desde la cuenta mail. Otras posibilidades para cada parte son:

servicio

El servicio es uno de los especificados en /etc/services o puede ser una dirección precedida por un puerto, o uno de los servicios RPC especificados en /etc/rpc.

Tipo de conexión

stream, dgram para datagramas, raw para conexiones puras, rdm para reliable delivered messages o seqpacket para paquetes secuenciados.

Protocolo

Debe ser uno de los disponibles en el archivo /etc/protocols, por ejemplo tcp o udp.

Espera

Puede ser wait o nowait, indica si inetd debe esperar a que el proceso termine para recibir nuevas conexiones en el mismo puerto o no. Esto depende del tipo de servicio, la mayoría no requiere espera (porque emplean varios hilos [212] que emplean otro puerto por cada conexión), aunque son excepciones talkd, biff y tftp. Después de wait o nowait puede venir separado por un punto el máximo número de conexiones que inetd debe aceptar para el servicio en 1 minuto (por defecto 256).

Usuario

Usuario a nombre del cual se iniciará el proceso.

[Warning]Aviso

Por seguridad, es recomendable ejecutar daemons desde cuentas diferentes a root

Puede especificarse un grupo primario poniendolo a continuación del nombre separado por el caracter "."

Programa

Ruta del programa que atenderá la conexión. Si se trata de un servicio interno se usa internal. Los servicios internos son echo que responde con los mensajes que recibe (útil para medir y probar como se especifica en el RFC 862); discard que descarta todo dato que recibe (también útil para probar y medir como se describe en el RFC 863); chargen definido en el RFC 864 responde generando caracteres hasta que la conexión sea cerrada; daytime que de acuerdo al RFC 867 informa fecha y hora en formato entendible para humanos time hora actual en formato para máquinas de acuerdo al RFC 868.

El archivo /etc/inetd.conf, en una LAN como la especificada en nuestra plataforma de referencia (sin conexión a Internet) incluye:

telnet          stream  tcp     nowait  telnetd.telnetd /usr/sbin/tcpd  /usr/sbin/in.telnetd
talk            dgram   udp     wait    nobody.tty /usr/sbin/tcpd  /usr/sbin/in.talkd
finger          stream  tcp     nowait  nobody  /usr/sbin/tcpd /usr/sbin/in.fingerd
smtp            stream  tcp     nowait  mail    /usr/sbin/exim exim -bs
	 

Después de modificar este archivo puede reiniciar inetd, tal como haría con otros servicios que se inician al arranque del sistema (ver Inicialización del sistema):

/etc/init.d/inetd restart	  

o envíando la señal SIGHUP al proceso. (ver Señales).

Note que la ejecución de telnet, finger y talk se hace con el programa tcpd. Este programa puede manejar conexiones de diversos servicios, registrar las conexiones en la bitácora y agregar un mínimo de seguridad incluyendo listas de control configurables en los archivos hosts.allow y hosts.deny. En estos archivos se configuran con patrones los servicios, computadores y/o usuarios pueden iniciar conexiones, y los que no. Cuando recibe una solicitud de conexión tcpd primero lee los patrones de /etc/hosts.allow si ninguno concuerda con la conexión intenta con los de /etc/hosts.deny y si ninguno concuerda permite la conexión. Para permitir acceso a estos servicios sólo a computadores en la red privada /etc/hosts.deny podría ser:

ALL: ALL
     

y /etc/hosts.allow:

ALL: 192.168.0.0/255.255.0.0
     

4.1.2. Servicio DNS

DNS permite asociar nombres a direcciones IP, esto es importante para facilitarnos la identificación de computadores en una red.

Como se describe en el RFC 1034, DNS puede verse desde 3 puntos de vista:

Usuario

Un usuario emplea nombres de dominios DNS al solicitar conexiones con máquinas cuyos nombres describen posiciones en un árbol de nombres. Por ejemplo structio.sourceforge.net.

Resolvedor de nombres

Los programas emplean un resolvedor de nombres. Este resolvedor recibe nombres con la estructura antes descrita, busca en un depósito [213] de nombres, de requerirlo trata de conectarse con uno o más servidores de nombres que puedan responder la consulta, envia la consulta y analiza la respuesta.

Servidor de nombres

Un servidor de nombres, es un programa que además de atender solicitudes de resolvedores, mantiene tablas donde asocia nombres con direcciones IP de algunas zonas del árbol de nombres. También mantiene direcciones de otros servidores de nombres que puede emplear para actualizar las tablas de las zonas que mantiene y para obtener información de otras zonas.

4.1.2.1. DNS a nivel de usuario

Los nombres son independientes de las IPs, estos conforman un árbol dividido en zonas manejadas por diversos servidores de nombres distribuidos en todo el mundo y conectados a Internet [214], la raíz de este árbol se denota con el carácter '.'. Un nombre se compone de partes separadas por el caracter '.', cada parte se compone de letras mayúsculas o minúsculas sin distinción (preferiblemente menos de 12), eventualmente números y eventualmente guiones. Las partes del nombre indican la ruta entre el nodo y la raíz, de forma análoga a la ruta de un archivo del sistema de archivos, sólo que un nombre DNS completo comienza por la parte que corresponde a la hoja y termina en la parte que corresponde a un hijo de la raíz. Por ejemplo en la dirección structio.sourceforge.net la parte net es un nodo descendiente de la raíz del árbol de nombres. A la parte descendiente de la raiz se le llama dominio de nivel superior (TLD - Top Level Domain) y puede ser dos letras que identifiquen uno de los 244 paises registrados de acuerdo a ISO 3166 (por ejemplo .co en el caso de Colombia) o por ejemplo una de las siguientes:

.aero

Industria de transporte aéreo

.biz

Miscelánea

.com

Comercial

.coop

Cooperativas

.edu

Educativo

.gov

Gubernamental de EUA

.info

Información

.int

Organizaciones internacionales

.mil

Militar de EUA

.museum

Museos

.name

Individuos

.net

Redes

.org

Organizaciones

4.1.2.2. DNS a nivel de resolvedor

El resolvedor de nombre es un conjunto de funciones, que los diferentes programas emplean cuando requieren determinar la IP asociado con un nombre (resolución de nombres) o el nombre asociado con una IP (resolución inversa).

Puede emplear el resolvedor de nombres desde la línea de comandos, por ejemplo con el programa dig (incluido en el paquete dnsutils). Algunos de sus usos se ejemplifican a continuación:

dig structio.sourceforge.net

Consulta todos los registros disponibles para el nombre structio.sourceforge.net usando el servidor configurado en /etc/resolv.conf

dig @ns1.valinux.com structio.sourceforge.net

La misma consulta anterior pero en el servidor de nombres ns1.valinux.com (usa el resolvedor local para determinar la IP de ese servidor)

dig structio.sourceforge.net txt

Busca sólo registros tipo T_TXT, es decir con texto arbitrario. Otras posibilidades son a (T_A) dirección; any (T_ANY) todo tipo de información; mx (T_MX) intercambiadores de correo; ns (T_NS) servidores de nombres; soa (T_SOA) zona de autoridad; hinfo (T_HINFO) información de la máquina; axfr (T_AXFR) zona de transferencia.

dig -x 192.25.206.10

Para especificar resolución inversa. También podría emplearse dig 10.206.25.192.in-addr.arpa

En Internet puede consultarse información sobre el registro de un dominio (incluyendo datos de quien lo registro) empleando whois, o información sobre el nombre de máquina y dominio del computador que usa con hostname (ver Comandos y programas útiles al hacer scripts).

El resolvedor de nombres incluido en Debian puede resolver nombres empleando el archivo /etc/hosts, servidores de nombres o NIS. Se configura en los archivos /etc/resolv.conf, /etc/host.conf y si se usa NIS también en /etc/nsswitch.conf. El primero ( /etc/resolv.conf) contiene direcciones de servidores de nombres y configuración para buscar en ellos. Por ejemplo en nuestra plataforma de referencia si el servidor tiene IP 192.168.1.1 y en este se configura un servidor de nombres, en todos los computadores de la red el archivo /etc/resolv.conf debe incluir:

search micolegio.edu.co
nameserver 192.168.1.1 

Si conectará su sistema a Internet podría incluir más servidores de nombres especificando cada uno con líneas iniciadas con la palabra nameserver (podría especificarlos a continuación de su propio servidor para que la información de su servidor tenga prelación dentro de la LAN). La línea search indica dominios con los cuales completar direcciones (por ejemplo purpura será completado como purpura.micolegio.edu.co). El archivo /etc/host.conf de todos los computadores puede ser:

order hosts,bind
multi on
	

que indica en la primera línea el orden para resolver nombres, en este caso como hosts está primero, resolverá nombres primero revisando el archivo /etc/hosts y en segundo lugar empleará los servidores de nombres configurados en /etc/resolv.conf (también podría especificarse nis en caso de que se resolvieran dominios usando NIS). La línea multi on indica que el resolvedor debe retornar todas las direcciones IP que pueda encontrar para un nombre en el archivo /etc/hosts y no sólo la primera (útil en una red multihomed con varios IPs para una misma máquina). Cómo en nuestra plataforma de referencia empleamos DNS para resolver nombres de dominios, el archivo de configuración de NIS (/etc/nsswitch.conf) debe incluir la línea (ver Servicio NIS):

hosts: files dns 

que de forma análoga a las líneas en /etc/hosts.conf indica buscar primero en /etc/hosts y después usar los servidores de nombres DNS.

Los resultados de las consultas que un resolvedor de nombres hace a un servidor de nombres, son registros de recursos (RR del inglés Resource Records). Este mismo tipo de registros se usa para configurar un servidor de nombres. Un ejemplo es:

servidor.micolegio.edu.co.   IN  A  192.168.1.1
                            A  128.9.0.32
micolegio.edu.co.	            MX  10 servidor.micolegio.edu.co
	 

que describe información de nombres Internet (indicado por la sigla IN de la primera línea y asumida por defecto en las demas). Las dos primeras líneas son tipo dirección (el tipo A --de Address-- lo indica), mientras que la tercera identifica un intercambiador de correo para el dominio micolegio.edu.co (tipo MX --de Mail Exchange). Los dos primeros registros presentan información sobre servidor.micolegio.edu.co, la ausencia de otro nombre al comienzo de la segunda línea indica que es una segunda dirección para servidor.micolegio.edu.co. Los registros tipo dirección permiten asociar una IP con un nombre, así en el ejemplo anterior el nombre servidor.micolegio.edu.co se referirá a dos direcciones IP. Los registros tipo MX identifican computadores que pueden resolver direcciones de correo para un dominio, cada uno con un valor de preferencia (empleando para determinar que servidor se emplea primero si hay varios intercambiadores de correo para un mismo dominio). Note que los nombres de dominios completos terminan con un punto, esto es un requerimiento propio de la configuración como se explica más adelante.

Otros tipos pueden ser: CNAME que identifica el nombre principal de un alias, HINFO que identifica CPU y sistema operativo de un computador, NS que marca un servidor de nombres autoritario para un dominio (autoritario quiere decir que su respuesta es la que se considera más acertada en caso de que otros servidores den otras respuestas); PTR para referenciar otra parte del espacio de nombres de dominio; SOA (start of authority) para marcar el comienzo de una zona de autoridad.

Además de asociar nombres a IPs, pueden asociarse IPs a nombres para permitir hacer resolución inversa (dada la IP encontrar el nombre). Para lograrlo se emplean registrros PTR, usando como nombre de máquina la IP tras invertir el orden de los 4 bytes que la conforman y seguida de IN-ADDR.ARPA. Por ejemplo:

	1.2.168.192.IN-ADDR.ARPA.       IN      PTR     servidor.micolegio.edu.co
      
4.1.2.3. DNS a nivel de servidor de nombres

Las consultas formuladas por los resolvedores de nombres que no pueden ser resueltas por el depósito local del resolvedor ni con otros mecanismos (e.g. /etc/hosts), pueden ser contestadas por uno de los servidores siguiendo el algoritmo descrito en el RFC 1034:

  1. El resolvedor contacta a uno de los servidores configurados.

  2. El servidor busca la zona que sea ancestro más cercano de la información buscada.

  3. Si la información buscada está entre las zonas manejadas o referenciadas por el servidor, busca entre ellas hasta encontrar la información o hasta encontrar un registro que referencie otro servidor de nombres autoritario o en último caso reporta que el dominio no fue encontrado.

  4. Si la información no está en las zonas manejadas por el servidor (o está en una subzona), busca en un deposito local.

  5. Si no hay información en el deposito local y está en modo recursivo, empleando su resolvedor de nombres consulta al servidor encontrado en el paso 3 y retorna la respuesta además de almacenarla en el deposito. En modo iterativo sólo responde el nombre del servidor encontrado en el paso 3.

  6. Una vez el resolvedor consigue la información, la almacena temporalmente en un depósito local.

Para distribuir la información en los servidores de nombres, el árbol de nombres se divide en zonas, cada una de las cuales puede ser atendida con registros autoritarios por un servidor primario. Para respaldar la información de servidores primarios, hay servidores secundarios que copian periódicamente la información y también proveen información autoritaria de la zona.

Para hacer consultas a servidores de nombres o para recibir respuestas, se emplean los puertos UDP 53 y TCP 53 (como puertos de entrada y de salida, aunque para la comunicación con algunos programas cliente pueden requerirse puertos no privilegiados (TCP 1024 y UDP 1024).

Entre los servidores DNS disponibles en Internet están djbdns y bind. Aunque djbdns es más seguro, bind (paquete bind, documentación en paquete bind-doc) es más popular y será el servidor que describimos en esta sección. La instalación por defecto de este paquete dejará una configuración sencilla que consta de:

/etc/bind/named.conf

Archivo de configuración principal que define zonas y opciones del servidor.

/etc/bind/db.local y /etc/bind/db.127

Que definen la zona localhost (interfaz loopback) y su zona inversa (i.e direcciones 127.*.*.*)

/etc/bind/db.root

Que referencia los servidores de la raíz del árbol de nombres.

/etc/bind/db.0 y /etc/bind/db.255

Que incluyen registros para hacer resolución inversa de direcciones de la forma 0.*.*.* (también localhost) y 255.*.*.* (broadcast).

Las zonas instaladas por defecto son recomendadas en el RFC 1912, y deben estar configuradas en todo servidor de nombres.

Para configurar una zona para su red local, es preferible que emplee un nombre de dominio que no esté registrado en Internet (aún si no planea conectarse a Internet a corto plazo). Cree un archivo para su zona, digamos /etc/bind/db.micolegio.edu.co y otro para resolución inversa en su red, digamos /etc/bind/db.192.168.1 (que resolverá direcciones de la forma 192.168.1.*).

En el archivo de configuración principal (/etc/bind/named.conf), debe agregar entradas para la zona. Debe tener líneas como las siguientes, aunque quitando o agregando comentarios de ser necesario (son comentarios los textos iniciadas con // hasta final de línea o porciones encerradas entre /* y */ o líneas iniciadas con el caracter #).

options {
  directory "/var/cache/bind";
  forwarders {
	//Remplazar por dirección del servidor DNS del proveedor si lo hay
	// o comentar esta sección.  Esta dirección será usada en caso
	// de que este servidor no tenga un registro en una zona manejada
	// por él o en el deposito.
    1.2.3.4;
    };
    // Quitar comentarios si se hacen conexiones esporadicas a Internet
    // con un modem para actualizar zonas
    // dialup yes
}
logging {
  category lame-servers { null; };
  category cname { null; };
  };
  // Las siguientes líneas se comentan si la red no se conecta a
  // Internet
zone "." {
  type hint;
  file "/etc/bind/db.root";
};
zone "localhost" {
  type master;
  file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
  type master;
  file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
  type master;
  file "/etc/bind/db.127";
};
zone "255.in-addr.arpa" {
  type master;
  file "/etc/bind/db.255";
};
zone "micolegio.edu.co" {
  type master;
  file "/etc/bind/db.micolegio.edu.co";
};
zone "1.168.192.in-addr.arpa" {
  type master;
  file "/etc/bind/db.1.168.192";
}; 
	

Note que se configuran las nuevas zonas como tipo master porque el servidor podrá dar respuestas autoritarias sobre estas.

Los archivos con registros de recursos de cada zona, pueden tener comentarios en líneas que comienzan con ';'. El archivo /etc/bind/db.local que define una zona para la interfaz loopback ---que siempre tiene dirección 127.0.0.1 y nombre localhost--- sería:

@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresco
			  86400		; Reintento
			2419200		; Expiración
			 604800 )	; TTL Mínimo

@	IN	NS	localhost.
@	IN	A	127.0.0.1

Note que se define una zona sobre la que este servidor tiene autoridad usando un registro SOA; cómo el registro ocupa más de una línea se emplean paréntesis para delimitarlo. El signo '@' es una abreviación del nombre de dominio base, es decir el que proviene del archivo /etc/bind/named.conf (en este caso localhost).

El registro SOA tienen el nombre completo de la máquina que mantiene la información (terminada en punto), seguida de la dirección electrónica del administrador del servicio, pero remplazando el caracter '@' por '.' y terminando con '.' [215] Los registros tipo SOA incluyen: un número serial que los servidores secundarios usan para determinar cuando la información de la zona del primario a cambiado, el número de refresco indica cada cuantos segundos un servidor secundario revisará el primario para determinar si el número serial ha aumentado, un número de reintentos que un servidor secundario debería efectuar en caso de ausencia de respuesta. Expiración es el tiempo máximo en segundos que un servidor secundario debe esperar antes de declarar la información que tenga de una zona como válida en ausencia de respuesta del servidor primario. Mínimo TTL indica el tiempo mínimo que los registros pueden estar en el deposito de otros servidores de nombres. Es el dato más importante. Si no se planean hacer cambios puede dejarse en un valor grande (3 días), si se planea un cambio es mejor disminuir este valor con suficiente anticipación y volverlo a un valor grande después del cambio. Note que para este ejemplo como se trata de localhost, estos valores pueden ser arbitrarios (en este caso muy grandes).

La información de la zona raíz corresponde a las direcciones de los 13 servidores de la raíz, puede obtenerse con:

dig @a.root-servers.net. . ns

En el momento de este escrito es:

.			518400	IN	NS	K.ROOT-SERVERS.NET.
.			518400	IN	NS	L.ROOT-SERVERS.NET.
.			518400	IN	NS	M.ROOT-SERVERS.NET.
.			518400	IN	NS	I.ROOT-SERVERS.NET.
.			518400	IN	NS	E.ROOT-SERVERS.NET.
.			518400	IN	NS	D.ROOT-SERVERS.NET.
.			518400	IN	NS	A.ROOT-SERVERS.NET.
.			518400	IN	NS	H.ROOT-SERVERS.NET.
.			518400	IN	NS	C.ROOT-SERVERS.NET.
.			518400	IN	NS	G.ROOT-SERVERS.NET.
.			518400	IN	NS	F.ROOT-SERVERS.NET.
.			518400	IN	NS	B.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.	3600000	IN	A	193.0.14.129
L.ROOT-SERVERS.NET.	3600000	IN	A	198.32.64.12
M.ROOT-SERVERS.NET.	3600000	IN	A	202.12.27.33
I.ROOT-SERVERS.NET.	3600000	IN	A	192.36.148.17
E.ROOT-SERVERS.NET.	3600000	IN	A	192.203.230.10
D.ROOT-SERVERS.NET.	3600000	IN	A	128.8.10.90
A.ROOT-SERVERS.NET.	3600000	IN	A	198.41.0.4
H.ROOT-SERVERS.NET.	3600000	IN	A	128.63.2.53
C.ROOT-SERVERS.NET.	3600000	IN	A	192.33.4.12
G.ROOT-SERVERS.NET.	3600000	IN	A	192.112.36.4
F.ROOT-SERVERS.NET.	3600000	IN	A	192.5.5.241
B.ROOT-SERVERS.NET.	3600000	IN	A	128.9.0.107
J.ROOT-SERVERS.NET.	3600000	IN	A	192.58.128.30
	

Si en la zona micolegio.edu.co el servidor de nombres tiene IP 192.168.1.1 con nombre servidor y algunos clientes con otras direcciones de la forma 192.168.1.*, el archivo /etc/bind/db.micolegio.edu.co sería:

@       IN      SOA     servidor.micolegio.edu.co. root.localhost. (
                            1		; Serial
                          10800		; Refresco cada 3 horas
                           3600		; Reintento cada hora
                        2419200		; Expiracion después de un mes
                         259200 )	; TTL 3 dias

@             NS        servidor
servidor.micolegio.edu.co         	A	192.168.1.1
www                     A	192.168.1.1
mail                    A	192.168.1.1
bachillerato1           A	192.168.1.2
bachillerato2           A	192.168.1.3
bachillerato3           A	192.168.1.4
bachillerato4           A	192.168.1.5
secretaria              A	192.168.1.100
profesores              A	192.168.1.200
      

Note que además de indicar que el archivo tiene información autoritaria sobre la zona con un registro SOA (que tiene parámetros más apropiados para un servidor de nombres primario); este ejemplo tiene: un registro tipo NS que presenta a servidor como servidor de nombres. Los demás registros tipo A asocian nombres a direcciones en la red. Note que todos los nombres de máquinas excepto el del registro SOA como no terminan en punto serán completados con el nombre de la zona (micolegio.edu.co declarada en /etc/bind/named.conf y referenciable como la variable $ORIGIN).

En cuanto a las zonas inversas, /etc/bind/db.0 es

@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
@	IN	NS	localhost.
	

La zona inversa para localhost (/etc/bind/db.127):

@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
@	IN	NS	localhost.
1.0.0	IN	PTR	localhost.
	

para la zona de broadcast /etc/bind/db.255:

@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
@	IN	NS	localhost.
	

y para la zona de su red (/etc/bind/db.1.168.192):

@	IN	SOA	servidor.micolegio.edu.co. root.localhost. (
			      1		; Serial
			  10800		; Refresco cada 3 horas
			   3600		; Reintento cada hora
			2419200		; Expiracion después de un mes
			 259200 )	; TTL 3 dias
@	IN	NS	servidor.micolegio.edu.co.
1	IN	PTR	servidor.micolegio.edu.co
1	IN	PTR	www.micolegio.edu.co.
1	IN	PTR	mail.micolegio.edu.co.
2	IN	PTR	bachillerato1.micolegio.edu.co.
3	IN	PTR	bachillerato2.micolegio.edu.co.
4	IN	PTR	bachillerato3.micolegio.edu.co.
5	IN	PTR	bachillerato4.micolegio.edu.co.
100	IN	PTR	secretaria.micolegio.edu.co.
200	IN	PTR	profesores.micolegio.edu.co.
	

Después de hacer sus cambios puede reiniciar bind (lo cual limpiará el depósito y leerá de nuevo los archivos de configuración) con: /etc/init.d/bind restart (ver Inicialización del sistema).

Al editar zonas tenga en cuenta estas recomendaciones (de los RFC 1912 y 1034):

  • Todo registro de recursos tipo A, debería tener el correspondiente registro tipo PTR para resolución inversa.

  • No emplee en registros CNAME el mismo nombre con otros propósitos, ni emplee nombres de registros MX.

  • No referencie alias definidos con CNAME en registros tipo SOA, MX ni CNAME.

  • Si mantiene un servidor primario, cada vez que haga modificaciones a información de la zona que maneja, recuerde aumentar el número serial del registro SOA para que el o los servidores secundarios realicen la actualización.

4.1.3. Servicio NFS

Como se describe en el RFC 1813, el protocolo NFS [216] permite acceder de forma transparente sistemas de archivos compartidos que están en máquinas remotas. Hay muchas posibilidades para usar este servicio, nuestra plataforma de referencia lo aprovecha para distribuir información de usuarios (directorio /home del servidor), las colas de correo (/var/mail) y los programas y documentos disponibles en el servidor (directorio /usr). Así mismo permite aprovechar el espacio de sobra de cada cliente (directorio /aux).

Al igual que otros servicios, NFS cuenta con un cliente y un servidor. El servidor NFS permite exportar directorios del computador en el que corre a computadores donde se ejecute el cliente, mientras estos últimos tengan permiso para importar tales directorios. Los directorios que se exportan, así como las restricciones sobre los clientes que pueden importarlos se especifican en el archivo /etc/exports. Por ejemplo el siguiente es el archivo /etc/exports del servidor de nuestra plataforma de referencia:

/usr  *.micolegio.edu.co(ro,no_root_squash)
/home  *.micolegio.edu.co(rw,no_root_squash)
/var/mail  *.micolegio.edu.co(rw,no_root_squash)

Este archivo especifica que pueden exportarse con permiso de lectura y escritura los directorios /home, /var/mail. Puede exportar con permiso de sólo lectura (ro) el directorio /usr. Todos estos directorios pueden ser importados por máquinas con nombres de la forma x.micolegio.edu.co. La opción no_root_squash indica que los archivos de usuario y grupo root exportados del servidor sean tratados como si fueran del usuario y grupo root en los clientes.

En nuestra plataforma de referencia tanto cliente NFS como servidor NFS deben instalarse en todos los computadores (porque los computadores clientes exportarán el espacio que resta de su partición aux al servidor). El archivo /etc/exports de cada cliente debe ser algo como:

/aux *.micolegio.edu.co(rw,no_root_squash)

Para instalar el servidor y el cliente NFS en Debian 2.2 basta que instale los paquetes nfs-common y nfs-server, siguiendo el procedimiento usual (ver Administración de programas). Como NFS depende de RPC, asegúrese también de dar acceso a las máquinas de su dominio con portmap y que esté operando. Dado que portmap es manejado con tcpd (ver Configuración de servicios básicos) este acceso se da o restringe modificando los archivos /etc/hosts.allow y /etc/hosts.deny. Por ejemplo el archivo /etc/hosts.allow debe tener una línea como:

portmap: .micolegio.edu.co

Puede comprobar que portmap está corriendo buscándolo entre los procesos (i.e ps ax | grep "[p]ortmap") o revisando los programas que están registrados para usar RPC con pmap_dump.

Una vez esté corriendo el servidor y el cliente NFS en todas las máquinas, puede montar (ver Montaje y desmontaje de sistemas de archivos) los directorios exportados por el servidor en cada cliente, por ejemplo con algo como:

mount -t nfs servidor.micolegio.edu.co:/usr /opt

para montar el directorio /usr del servidor como el directorio /opt de cada cliente. Mejor aún, puede editar el archivo /etc/fstab para que cada vez que cada máquina inicie monte automáticamente ese directorio. Por ejemplo podría agregar la siguiente línea al archivo /etc/fstab de un cliente [217]:

servidor.micolegio.edu.co:/usr /opt nfs ro 0 0

En el servidor puede agregar al archivo /etc/fstab, líneas de la forma "clienten:/aux /mnt/auxn nfs rw 0 0" para montar en /mnt/auxn el directorio /aux de cada cada cliente. Para comprobar los directorios que ha montado con NIS puede emplear mount.

Mientras no configure el servicio NIS (ver Servicio NIS), recomendamos no montar /home ni /var/mail del servidor en los clientes.

4.1.4. Servicio NIS

NIS [218] es un servicio para centralizar nombres de usuarios, claves, e información de grupos en el servidor facilitando la administración de usuarios. Si además de NIS se usa NFS para montar el directorio /home del servidor en cada cliente, puede centralizarse también la información de todos los usuarios en el servidor.

NIS de forma análoga a DNS opera sobre un grupo de computadores (dominio) y mantiene bases de datos (mapas) centralizadas en un servidor maestro, que pueden ser consultadas por los clientes. Para disminuir carga podrían ponerse servidores esclavos que repliquen la información del servidor maestro.

Para usar NIS debe escoger un nombre de dominio NIS (puede ser diferente al dominio DNS) y usarlo en los computadores clientes y en el servidor.

Puede comenzar instalando el paquete nis tanto en clientes como servidor, al instalarlo podrá dar el dominio NIS (o puede editarlo en /etc/defaultdomain). En todos los computadores debe modificar el archivo /etc/nsswitch para cambiar el orden de búsqueda de usuarios, grupos y shadow. También debe agregar algunas líneas al final de los archivos /etc/passwd, /etc/group y /etc/shadow, tarea que puede hacer con los siguientes comandos:

echo "+::::::" >> /etc/passwd
echo "+:::" >> /etc/group
echo "+::::::::" >> /etc/shadow

Que agregan líneas con un "+" y tantos ":" como separadores hay en los respectivos archivos. En el servidor los usuarios y grupos que estén después de estas marcas no serán compartidos por NIS.

En el servidor debe configurar NIS de la siguiente forma:

  1. Edite /etc/init.d/nis, asegurándose de dejar NISSERVER=master.

  2. Reinicie el servicio NIS con /etc/init.d/nis restart

  3. Edite el archivo /var/yp/Makefile y cambie la regla all: para que incluya también shadow.

  4. Ejecute /usr/lib/yp/ypinit -m.

Una vez NIS esté funcionando en clientes y servidor, puede agregar, eliminar o modificar usuarios y grupos con los comandos usuales (ver Administración de usuarios) y después de cada modificación, para que el cambio sea notado por NIS, debe pasar al directorio /var/yp/ y ejecutar make.

Para centralizar la información de todos los usuarios en el servidor puede usar NFS una vez NIS funcione bien. Para lograrlo se debe hacer la administración de usuario siempre en el servidor (por ejemplo agregar nuevos usuarios sólo desde el servidor) para que los directorios queden allí; por otra parte debe montar el directorio /home del servidor en todos los clientes. Para centralizar la cola de correo en el servidor debe montar el directorio /var/mail del servidor en los clientes. De esta forma el archivo /etc/fstab de cada cliente debe incluir:

servidor.micolegio.edu.co:/home /home nfs rw 0 0
servidor.micolegio.edu.co:/var/mail /var/mail nfs rw 0 0

y el archivo /etc/exports del servidor debe tener las líneas apropiadas para exportar /home y /var/mail. Ver Servicio NFS.

4.1.5. Servicio ssh

El protocolo ssh cuenta con dos versiones, un borrador de la segunda de estas está en proceso de desarrollo. OpenSSH es la implementación de cliente y servidor para estos protocolos, la versión disponible para Debian permite usar tanto ssh 1 como ssh 2.

Tal como se describe en uno de los borradores de la especificación temporal "SSH Protocol Architecture" (http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt) ssh es un protocolo para iniciar sesiones en máquinas remotas que ofrece autenticación, confidencialidad e integridad. Consta de tres componentes:

  1. Protocolo de transporte. Que normalmente opera sobre TCP/IP dando autenticidad, confidencialidad e integridad.

  2. Protocolo de autenticación de usuario. Que autentica al usuario ante el servidor.

  3. Protocolo de conexión. Que multiplexa un canal encriptado en diversos canales lógicos.

Este protocolo requiere que los servidores tengan "llaves", las cuales son usadas por los clientes cada vez que se conectan a un servidor para verificar que no fue suplantado. Una llave es un número codificado y encriptado en un archivo. Para la encripción de llaves, OpenSSH ofrece los algoritmos RSA y DSA (de los cuales para la versión 2 recomendamos DSA).

Para instalar un servidor OpenSSH, que le permita conectarse a su sistema de forma segura, instale el paquete ssh preferiblemente tomando la versión más reciente del sitio de seguridad de Debian: http://security.debian.org o compile las fuentes más recientes que puede obtener en http://www.openssh.org. Cuando instale se generaran un par de "llaves" para su computador, una pública y una privada. Una vez instalado podrá afinar la configuración del servidor en el archivo /etc/ssh/sshd.conf que puede incluir líneas como las siguientes:

PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
RhostsAuthentication no
hostsRSAAuthentication no
HostbasedAuthentication no
X11Forwarding yes 

La última línea permitirá a los clientes que se conecten ejecutar aplicaciones de X-Window y transmitir la información gráfica sobre la conexión segura (ver Sección 3.1.1).

Un usuario también puede crear un par de llaves que le faciliten su autenticación al emplear ssh o scp. Estos programas por defecto piden clave al usuario que se conecte a un servidor ssh. Si un usuario genera sus llaves pública y privada, puede saltarse esta autenticación pues se hará de forma automática con las llaves. Para lograrlo su llave pública debe estar en el computador al cual se conecta (en ~/.ssh/authorized_keys) y su llave privada en el computador desde el cual se conecta (normalmente en ~/.ssh/id_dsa).

La generación de llaves puede hacerse con:

ssh-keygen -t dsa

que por defecto dejará su llave pública en ~/.ssh/id_dsa.pub y su llave privada en ~/.ssh/id_dsa (que además quedará protegida por una palabra clave que usted especifica). Como el nombre lo índica la llave privada no debe compartirla, por el contrario la llave pública puede transmitirla y puede ser vista por cualquiera.

En el computador en el que desee conectarse, agregue en el archivo ~/.ssh/authorized_keys (o ~/.ssh/authorized_keys2 si usa DSA y una versión de OpenSSH anterior a la 3.1), su llave pública. Por ejemplo el usuario mario desde purpura.micolegio.edu.co puede configurar la entrada con autenticación automática a la cuenta juan en amarillo.micolegio.edu.co con:

purpura> scp ~/.ssh/id_dsa.pub amarillo.micolegio.edu.co:/home/juan/id_dsa_mario.pub
purpura> ssh -l juan amarillo.micolegio.edu.co
...
amarillo> cat id_dsa_mario.pub >> ~/.ssh/authorized_keys
   

Cuando mario se intente conectar desde purpura, a la cuenta juan en amarillo ya no tendrá que dar la clave de juan en ese computador sino la palabra clave con la que protegio su llave privada. Incluso esta palabra clave puede darse una sóla vez, aún cuando se realicen diversas conexiones con:

purpura> ssh-agent bash
purpura> ssh-add mario

Tras lo cual mario tecleará una vez la palabra clave de su llave privada, y después en esa sesión de bash todo ingreso que haga a la cuenta juan en amarillo, no solicitará clave alguna.

4.1.6. Servicio CVS

En esta sección se presenta configuración de un servidor CVS y creación de repositorios (el uso de un repositorio y un servidor ya configurado puede verse en Sección 1.1.5).

Un servidor CVS puede emplearse sin conexión a una red, o bien en red con alguno de los protocolos rsh, ssh (ver Servicio ssh) o pserver. Los dos primeros requieren que el usuario que se conecta tenga cuenta (o una llave pública ssh entre las llaves autorizadas de una cuenta), mientras que pserver puede manejar su propio archivo de usuarios y claves. En todos los casos requiere instalar CVS y configurar un depósito. Si usa ssh debe instalar también el servidor sshd (ver Servicio ssh), si usa pserver debe agregar a su archivo /etc/inetd.conf (ver Configuración de servicios básicos) la línea:

cvspserver      stream  tcp     nowait.400      root    /usr/sbin/tcpd
/usr/bin/cvs -b /usr/bin --allow-root=/var/cvs pserver

(cambiando /var/cvs por el directorio donde está el depósito) y debe configurar los repositorios que desee poder acceder con pserver en /etc/cvs-pserver.conf.

Para instalar CVS instale el paquete cvs (ver Paquetes en Debian), que le permitirá activar o no el protocolo pserver y de requerirse hará los cambios apropiados en /etc/inetd.conf. El programa de instalación también podrá inicializar un repositorio por usted (puede ser /var/cvs, directorio que usted debe crear antes o durante la instalación de cvs).

Una vez CVS (y eventualmente ssh) esté instalado, todo usuario de la misma máquina puede crear uno o más depósitos. Tales depósitos podrán ser accedidos por otros usuarios del mismo sistema o de otro con ssh o con rsh o con el protocolo pserver (ver Uso de CVS)

Un usuario juan emplearía una secuencia de comandos como la siguiente para crear un repositorio en /home/juan/cvs:

cd ~
mkdir cvs
cd cvs
export CVS_RSH=""
export CVSROOT=/home/juan/cvs
cvs init

Juan mismo o algún otro usuario del sistema que tenga permiso de escritura en ese directorio podrá leer (update) y escribir (commit) en el nuevo repositorio. Para eso basta que emplee:

export CVS_RSH=""
export CVSROOT=/home/juan/cvs

También puede usarlo vía ssh (por ejemplo desde otro computador de la misma red) con CVS_RSH="ssh". O si durante la instalación o reconfiguración de cvs el administrador activa el protocolo pserver puede emplearse CVSROOT=:pserver:juan@purpura.micolegio.edu.co:/home/juan/cvs, siendo juan un usuario de la máquina donde está el repositorio con permisos para leer (o escribir) o un usuario para ese repositorio agregado en el archivo /home/juan/cvs/CVSROOT/passwd[219]

Todo usuario con permiso de escritura en ese depósito podrá ingresar un módulo nuevo. Por ejemplo un usuario con permiso de escritura y las variables CVS_RSH y CVSROOT con los valores recién presentados, puede ingresar todo el contenido del directorio ~/quimica` como módulo laquimica:

cd ~/quimica
cvs import laquimica start vendor

Tras lo cual el mismo usuario que importó el módulo, o cualquier otro con permiso de lectura, puede sacar una copia local con:

cvs co laquimica

y hacer otras operaciones usuales de CVS (ver Uso de CVS).

4.1.6.1. Caso: Correo por cada actualización

Aprovechando la capacidad de CVS de ejecutar un script cuando actualiza la bitácora y el script syncmail, es posible configurar CVS para que por cada actualización (commit) envíe un correo a una dirección electrónica. Para esto haga checkout del directorio CVSROOT de su repositorio :

cvs co CVSROOT
      

En ese directorio copie el archivo syncmail que podrá descargar de: http://cvs-syncmail.sourceforge.net y después ejecute:

chmod +x syncmail
cvs add syncmail 

Después agregue al archivo checkoutlist la línea:

syncmail	

actualice:

cvs commit -m "Ahora usa syncmail" 

y finalmente edite y actualice el archivo loginfo, agregando líneas como la siguiente:

^mimodulo $CVSROOT/CVSROOT/syncmail %{sVv} pablo@micolegio.edu.co 

que indican que toda actualización al módulo mimodulo, debe generar un correo indicando el cambio a pablo@micolegio.edu.co. La primera parte de la línea (^mimodulo) es una expresión regular que se aplicará al módulo o puede ser DEFAULT para indicar cualquier módulo.

4.1.7. Servicio de correo

El servicio de correo empleado en Internet y en una red TCP/IP se basa en el protocolo SMTP (Simple Mail Transfer Protocol) descrito especialmente en los RFCs 821 y 1123, funcionando sobre TCP/IP. En una situación típica en la que un usuario juan@primaria2.micolegio.edu.co envía un mensaje al usuario pablo@bachillerato3.micolegio.edu.co sin computadores intermediarios, se requiere:

  • Que haya conexión física y a nivel de TCP/IP entre ambos computadores.

  • Que ambos computadores tengan un programa que permita enviar y recibir correo usando el protocolo SMTP, como por ejemplo exim, sendmail o postfix (a tal programa se le llama MTA - Mail Transport Agent).

  • Que ambos usuarios tengan un programa con el que puedan leer y redactar correos, como por ejemplo mail, mutt, elm, balsa, pine, evolution (a ese programa se le llamará MUA - Mail User Agent[220]).

Si tanto Juan como Pablo emplean como MUA mail, y ambos computadores tiene como MTA exim, el proceso sería:

  1. Juan emplea mail en su computador primaria2 para redactar el mensaje cuyo destinatario es pablo.

  2. En primaria2, el programa mail ejecuta exim para enviar el mensaje. exim deja el mensaje en una cola de mensajes por enviar. Esa cola de mensajes es actualizada por exim a medida que envía o intenta enviar mensajes (si un mensaje no puede ser enviado exim puede reintentar el envio cierto número de veces, haciendo pausas entre un intento y otro).

    Enviar un mensaje significa crear una conexión TCP con el MTA destino o con otro MTA que actúe de intermediario, típicamente en el puerto TCP 25, y transmitir el mensaje siguiendo las reglas del protocolo SMTP [221]. Para establecer el computador con el cual conectarse exim revisa con el resolvedor DNS, registros MX asociados con el dominio de la dirección, si los hay intenta enviar a cada uno en orden de prioridad --los registros MX con menor número tienen mayor prioridad (ver Servicio DNS).

  3. En bachillerato3 debe estar corriendo un proceso que acepte la conexión en el puerto 25. Puede ser exim mismo o puede ser inetd que una vez realizada la conexión ejecuta a exim (ver Configuración de servicios básicos). Después exim recibirá el mensaje siguiendo el protocolo SMTP.

  4. exim agrega el mensaje que recibe en el archivo tipo texto /var/mail/pablo.

  5. Cuando Pablo lo desee, podrá emplear mail para leer los correos que se hayan acumulado en /var/mail/pablo ---a medida que los lea saldrán de ese archivo para quedar en ~/mbox.

Este es el esquema básico, aunque hay muchas otras situaciones en las que se emplean otras posibilidades de SMTP, protocolos auxiliares y programas[222]. Como parte de nuestra plataforma de referencia, sugerimos este esquema:

  • Emplear un MUA que pueda leer directamente los correos que están en /var/mail o /var/spool/mail y configurarlo para esto, (en Debian el primero es el preferido, y /var/spool/mail es un enlace a /var/mail) y que emplee un MTA para enviar correos (ejemplos de MUAs con estás características son: mail, mutt, elm, balsa, evolution).

  • Emplear exim como MTA en todos los clientes. Una ventaja de exim sobre otros MTA (como sendmail) es la facilidad con la que se configura en el archivo /etc/exim/exim.conf o aún más sencillo en Debian para muchas situaciones con el script eximconfig. Los computadores clientes se configuran como MTA satélites con el servidor como compuerta de correo (o smart host) ---es decir se configura en los clientes sin capacidad de recibir correos sino sólo de enviar todo correo a un computador (al servidor). El MTA del servidor funciona como un MTA completo que pueda recibir y enviar correo usando SMTP.

  • Emplear NFS para compartir el directorio /var/mail del servidor en todos los clientes. De forma que exista un único sitio físico donde estén todos los correos, pero que desde todos los computadores cada usuario pueda acceder a su archivo de correos.

Para configurar este esquema se requiere:

  1. Instalar en todos los computadores los MUAs que habrá disponibles (mínimo mail disponible en el paquete mailx).

  2. Instalar en todos los computadores el MTA exim (paquete exim). En los clientes configurarlo como sistema satélite. Como nombre de sistema emplee el dominio de su institución, como computador del cual leerán los correos y como smart host use el servidor. Para hacer un cambio en la configuración después de instalar puede emplear eximconfig, o con más práctica /etc/exim.conf. Algunas líneas que ese archivo debe tener en el caso de clientes, para enviar siempre por el servidor son:

    qualify_domain = micolegio.edu.co
    local_domains = micolegio.edu.co:localhost
    
    smart:
      driver = smartuser
      new_address = ${local_part}@servidor.micolegio.edu.co
    end
    
    smarthost:
      driver = domainlist
      transport = remote_smtp
      route_list = "* servidor.micolegio.edu.co bydns_a"   
    end
    	  

    También puede incluir reglas para reescribir direcciones de forma que parezcan provenir de servidor.micolegio.edu.co:

    ^(?i)(root|postmaster|mailer-daemon)@micolegio.edu.co ${1}@in.limbo Ffr
    *@micolegio.edu.co ${1}@servidor.micolegio.edu.co Ffr
    ^(?i)(root|postmaster|mailer-daemon)@localhost ${1}@in.limbo Ffr
    *@localhost ${1}@servidor.micolegio.edu.co Ffr
    *@in.limbo root@servidor.micolegio.edu.co Ffr
    
    	  

    y esta para agregar direcciones que deben cambiarse para ciertos usuarios en el archivo /etc/email-adresses [223]:

    *@micolegio.edu.co    ${lookup{$1}lsearch{/etc/email-addresses}\
                                                    {$value}fail} bcfrF
    	  

  3. El servidor puede configurarlo como si fuera sitio de Internet usando eximconfig y agregando registros MX al servidor DNS. Configure como nombre del sistema el dominio de su institución, excluya de los controles de relaying su red interna (e.g 192.168.1.0/24). De editar manualmente /etc/exim/exim.conf, entre las líneas que eximconfig incluye están las siguientes que configuran procmail (ver mutt y procmail):

    procmail:
       driver = localuser
       transport = procmail_pipe
       require_files =
       ${local_part}:+${home}:+${home}/.procmailrc:+/usr/bin/procmail
       no_verify
    	  

    Con las siguientes permite redireccionamiento con el archivo .forward. Tenga en cuenta cambiar la configuración por defecto que deja eximconfig para esto (porque permite que .forward pueda ser escrito por el grupo):

    userforward:
       driver = forwardfile
       file_transport = address_file
       pipe_transport = address_pipe
       reply_transport = address_reply
       no_verify
       check_ancestor
       file = .forward
       filter
    	  

    Las siguientes indican emplear el sistema de correo local para usuarios locales, hacer consultas DNS antes de iniciar conexiones SMTP y emplear direcciones IP explícitas.

     localuser:
       driver = localuser
       transport = local_delivery
    
     lookuphost:
       driver = lookuphost
       transport = remote_smtp
    
     literal:
        driver = ipliteral
              

    La configuración de DNS debería tener en cuenta emplear servidor.micolegio.edu.co como intercambiador de correo para el dominio micolegio.edu.co y también como intercambiador de correo para cada cliente (es decir que todo correo que vaya a uno de los clientes se redirija al servidor). Retomando el ejemplo de la zona de DNS (ver Servicio DNS), el archivo /etc/bind/db.micolegio.edu.co tendría dos nuevas líneas (con registros tipo MX):

    @	IN	SOA	servidor.micolegio.edu.co. root.localhost. (
    			      1		; Serial
    			  10800		; Refresco cada 3 horas
    			   3600		; Reintento cada hora
    			2419200		; Expiracion después de un mes
    			 259200 )	; TTL 3 dias
    
    @		NS	servidor
    servidor.micolegio.edu.co			A	192.168.1.1
    www			A	192.168.1.1
    mail			A	192.168.1.1
    micolegio.edu.co.		MX	5 mail
    *.micolegio.edu.co.		MX	5 mail
    bachillerato1		A	192.168.1.2
    bachillerato2		A	192.168.1.3
    bachillerato3		A	192.168.1.4
    bachillerato4		A	192.168.1.5
    secretaria		A	192.168.1.100
    profesores		A	192.168.1.200
    	

Una vez haga cambios a la configuración de exim podrá realizar algunas pruebas para verificar la forma de enrutamiento:

exim -bV
exim -v -bt root@localhost
exim -v -bt root@servidor.micolegio.edu.co
exim -v -bt root@purpura.micolegio.edu.co
      

4.1.8. Servicio FTP

El protocolo FTP (que se describe en los RFC 1123 y en el RFC 959) permite transmitir archivos de un computador a otro de forma robusta y eficiente. Este protocolo requiere una conexión por la que se transmiten comandos y respuestas a comandos (normalmente por el puerto 21) y otra por la que se transmiten datos (el puerto es escogido por el cliente o el servidor). Pueden realizarse conexiones en modo activo o pasivo, en el primero el cliente establece la dirección y el puerto para el canal de datos, en el segundo es el servidor el que los establece. Al conectarse desde una red con direcciones privadas a un servidor FTP fuera de la red privada es necesario usar modo pasivo.[224]

Sugerimos emplear FTP para establecer un servidor FTP anónimo, pero no para brindar transmisión de archivos a usuarios del sistema (que pueden hacerlo con scp de ssh).

[Warning]Aviso

Las claves transmitidas en sesiones de FTP viajan por la red sin encripción alguna.

Como servidor FTP sugerimos proftp (paquete proftpd). La configuración por defecto queda en /etc/proftpd.conf que permite a todos los usuarios emplear ftp, permite ftp anónimo empleando los archivos del directorio /var/ftp. El directorio empleado puede tener una estructura arbitraria. proftpd deja errores y mensajes de error en /var/log/syslog.

Para limitar el servicio a ftp anónimo (los usuarios pueden emplear scp para realizar copias), puede agregar en la sección general del archivo de configuración limitación de acceso para todos los usuarios (con LimitLOGIN) y en la sección de ftp anónimo permitir acceso para todos los usuarios. El archivo /etc/proftpd.conf sería algo como:


ServerName			"servidor"
ServerType			standalone
DeferWelcome			off

ShowSymlinks			on
MultilineRFC2228		on
DefaultServer			on
ShowSymlinks			on
AllowOverwrite			on

TimeoutNoTransfer		600
TimeoutStalled			600
TimeoutIdle			1200

DisplayLogin                    welcome.msg
DisplayFirstChdir               .message
LsDefaultOptions                "-l"

Port				21

Umask				022  022

MaxInstances			30

User				nobody
Group				nogroup

<Limit LOGIN>
    DenyAll
</Limit>

<Directory /*>
  AllowOverwrite		on
</Directory>

<Anonymous ~ftp>
  User				ftp
  Group				nogroup
  UserAlias			anonymous ftp

  RequireValidShell		off

  MaxClients			10

  DisplayLogin			welcome.msg
  DisplayFirstChdir		.message
  
  <Limit LOGIN>
    AllowAll
  </Limit>

  <Directory *>
    <Limit WRITE>
      DenyAll
    </Limit>
  </Directory>

</Anonymous>

       

4.1.9. Servicio Web

El servicio web se basa en el protocolo HTTP (Hypertext Transfer Protocol), cuya versión 1.1 está definida en el RFC 2616. Este protocolo permite:

  • Transmitir hipertextos escritos en HTML con diversas codificaciones e idiomas, gráficas y otros tipos de información a partir de URLs solicitados por el navegador. Cada tipo de información solicitada por un cliente es transmitida por el servidor con una identificación MIME (Multipurpose Internet Mail Extensions) que permite al navegador desplegarlo apropiadamente (por ejemplo cargando otro programa o un plugin de ser necesario)[225]. La identificación MIME es de la forma tipo/subtipo, las identificaciones registradas pueden consultarse en: http://www.iana.org/assignments/media-types/index.html

  • Sirve como protocolo genérico para transmisión de otros tipos de protocolos (e.g FTP, SMTP, Gopher, NNTP).

  • Permite emplear intermediarios (proxys, compuertas y túneles), cada uno de los cuales puede tener un deposito. Normalmente HTTP emplea por defecto el puerto TCP 80 (si el servidor/proxy está en otro puerto, puede especificarse en un URL como http://servidor.micolegio.edu.co:8080/index.html).

  • Ejecutar CGIs (Common Gateway Interface) que respondan dinámicamente a información transmitida desde el cliente. Por ejemplo el siguiente URL incluye las variables nombre y apellido que son pasadas al CGI param.cgi con valores Camilo y Paez: http://structio.sourceforge.net/cgi-bin/param.cgi?nombre=Camilo&apellido=Paez Los CGIs son programas o scripts que reciben por entrada estándar y/o variables de ambiente, consultas hechas por un cliente y responden escribiendo en sálida estándar la respuesta que dará el servidor.

Como servidor web sugerimos Apache (paquete apache), que es el servidor más popular en Internet (puede consultar estadísticas en Netcraft) y para hacer más eficiente la conexión sugerimos emplear squid como proxy con depósito.

Apache se configura en el archivo /etc/apache/httpd.conf. La configuración por defecto supone que las páginas por servir están en /var/www y en los directorios public_html de cada usuario. Los errores y mensajes quedan en /var/log/apache/error.log y pueden dejarse CGIs en el directorio /usr/lib/cgi-bin (que es alias de /cgi-bin). Entre sus características están:

  • Excelente implementación de HTTP 1.1 y CGI 1.1.

  • Configuración sencilla (en /etc/apache/httpd.conf) y posibilidad de emplear archivos de confioguración por cada usuario ~/public_html/.htaccess.

  • Cuenta con módulos para soportar SSI (Server Side Includes) y PHP.

  • Soporta SSL (Secure Socket Layer) para trasmisión encriptada y autenticación básica para tener zonas restringidas con claves.

  • Soporta dominios virtuales (Virtual Host), para atender con un sólo servidor diversos dominios. Además de la configuración DNS que esto requiere (puede ser con registros CNAME), basta agregar una sección por cada dominio virtual, por ejemplo:

    	      <VirtualHost *>
    		ServerName estudiantes.micolegio.edu.co
    		DocumentRoot /var/www/estudiantes
    	</VirtualHost>
    	

En cuanto a proxy, puede instalar squid (paquete squid). Este programa permite definir listas de acceso y emplearlas para dar servicio sólo a las direcciones con permiso. La configuración por defecto del paquete deja listo squid para servir sólo al computador donde se instala, para servir otros computadores de su red debe (1) agregar un ACL que especifique todos los computadores de su red y (2) indicar que el ACL definido puede emplear el proxy de HTTP, se hace con líneas como éstas en las secciones apropiadas del archivo de configuración /etc/squid.conf:

	acl red src 192.168.0.0/255.255.0.0

y

	http_access allow red

Tras hacer cambios en la configuración puede reiniciarlo con

/etc/init.d/squid restart
      

Puede comprobar que funciona o diagnosticar errores revisando las bitácoras del directorio /var/log/squid. Desde los clientes podrá configurar el navegador para que emplee este proxy que por defecto atiende el puerto 3128. Por ejemplo con w3m y lynx basta establecer el URL del proxy en la variable de ambiente http_proxy:

	export http_proxy=http://servidor.micolegio.edu.co:3128
      

En el caso de mozilla, se configura en Advanced/Proxies después de elegir Edit/Preferences en el menú principal.

4.1.10. Impresora en red

El programa lpd es un servidor del protocolo LPD, mientras que lpr es un cliente. En esta sección se dan detalles mínimos para configurar una impresora en red, la configuración de una impresora local a un computador y la configuración básica de /etc/printcap puede consultarse en la sección Sección 4.1.5 y el uso de la impresora una vez configurada en Sección 1.1.1.

La impresora de la red debe conectarse a un computador y configurarse como local en ese computador. En el resto de computadores debe configurarse como impresora remota. Por ejemplo si el comptuador al que está conectado la impresora es rojo.micolegio.edu.co y allí se configura una impresora con nombre psprn, en los demás computadores en el archivo /etc/printcap debe haber líneas como:

psprn|rp|remote line printer:\
  :lp=:rm=rojo.micolegio.edu.co:rp=psprn:sd=/var/spool/lpd/psprn: \
  :lf=/var/log/lp-errs: 

El servidor lpd que debe ser iniciado durante el arranque de rojo, recibe conexiones sólo de las máquinas especificadas en /etc/hosts.equiv o /etc/hosts.lpd y podrá entonces imprimir trabajos iniciados por usuarios en tales máquinas (agregue a uno de esos archivos los computadores clientes que podrán imprimir). Para restringir acceso a una impresora de otra forma, en /etc/printcap puede emplearse rs en lugar de rm para indicar que tal impreso sólo imprimirá trabajos de usuarios que tengan una cuenta en el mismo computador.

4.2. Lecturas recomendadas: Protocolos de soporte y de usuario

  • Net-HOWTO. 5.8. Configuring your network servers and services. http://linuxdoc.org/HOWTO/Net-HOWTO/x619.html

  • El tema seguridad no es tratado en profundidad (es indispensable estudiarlo si se planea conectar a Internet). NET-3-HOWTO Sección 5.10. Network Security and access control.

Configuración de servicios básicos

  • Para conocer más sobre la configuración de inetd y tcpd, puede consultar las páginas man de inetd, tcpd y hosts_access.

  • Puede consultar sobre el protocolo Telnet en los RFC 854, 855 y 1123.

  • Sobre el protocolo de finger en el RFC 1288.

NFS

  • La versión 3 de este protocolo está descrita en el RFC 1813.

  • Páginas del manual de exports (man exports), de NFS y de portmap.

  • De Olaf Kirch y Terry Dawson: Linux Network Administrators Guide. The Network File System. http://www.linuxdoc.org/LDP/nag2/x-087-2-nfs.html

DNS

NIS

CVS

CVS

Correo

Web

4.3. Ejercicios: Protocolos de soporte y de usuario

4.3.1. Servicios
4.3.4.3.1.1.

Active el servicio interno daytime de inetd, después revise la respuesta que este da a una conexión empleando telnet. Describa los pasos que siguió.

4.3.2. DNS
4.3.4.3.2.1.

Desde el intérprete de comandos ¿Cómo puede determinar la IP de structio.sourceforge.net, los nombres DNS asociados a la IP 204.152.184.85 y la dirección de correo del contacto técnico de sourceforge.net? ¿Cuáles son esos datos?

4.3.3. NFS
4.3.4.3.3.1.

En su máquina cree los directorios /aux y /mnt/tmp, ponga en el primero algún archivo. Después monte vía NFS el directorio /aux y móntelo en el directorio /mnt/tmp. Después de que funcione, desmóntelo.

4.3.4.3.3.2.

Monte el directorio /usr del servidor principal como /opt en otro computador de la red. ¿Qué debe hacer para que en ese computador se emplee la ruta /opt/bin para buscar archivos y /opt/lib para buscar bibliotecas compartidas?

4.3.4. Correo
4.3.4.3.4.1.

Configure exim en un computador cliente para no recibir correos y enviar empleando el MTA del servidor. Compruebe que funciona enviando desde el cliente un correo a una cuenta en el servidor.

4.3.4.3.4.2.

Después de configurar NIS, empleando NFS comparta el directorio /var/mail del servidor en un cliente con la configuración del ejercicio anterior. Tras esto compruebe que cada usuario puede revisar su correo con el programa mail desde cualquier computador.

4.3.4.3.4.3.

En caso de emplear un cliente de correo diferente a mail configúrelo de forma que lea correo de la cola /var/mail (o /var/spool/mail) y que transmita usando exim.

4.3.5. Web
4.3.4.3.5.1.

Instale el servidor Apache en el servidor, compruebe que funciona desde un browser en otro computador.

4.3.4.3.5.2.

Configure Apache para que puedan accederse los directorios de los usuarios con el URL http://servidor/~login.



[210] conexión del inglés sockets

[211] El primer argumento corresponde al nombre del comando, es útil al emplear tcpd

[212] Hilos del inglés threads.

[213] Depósito es la traducción que empleamos para cache

[214] Hay 13 servidores principales que manejan la raíz de este árbol.

[215] Estos archivos de registros son preprocesados, y a todo nombre que no termine con el caracter '.' se le agrega la zona (definida en /etc/bind/named.conf) para convertirlo en un nombre completo (FQDN - Fully qualified domain name).

[216] NFS es sigla de Network File System que en castellano es sistema de archivos en red. Anque en el momento de este escrito hay versión 4, en Debian está implementada la 3.

[217] Después de montar /usr del servidor como /opt de cada cliente, podrá ejecutar algunos programas que están en el servidor, desde el directorio /opt (aún para más comodidad puede agregar las rutas /opt/bin a la variable de entorno PATH).

[218] NIS es sigla de Network Information System que en castellano es sistema de información de la red

[219] El archivo de claves para CVS tiene 2 o 3 campos, el primero es el nombre con el que se conectará el usuario, el segundo la clave encriptada con DES (ver Administración de usuarios) y el tercer opcional es el nombre del usuario local a nombre del cual modificará el repositorio. Este archivo puede administrarse con htpasswd, para crear el archivo con un primer usuario: htpasswd -c juan y posteriormente para agregar otros usuarios htpasswd agustin

[220] De acuerdo al RFC 1123 los nombre MUA y MTA son propios del protocolo X.400.

[221] De acuerdo al protocolo SMTP, exim de primaria2 se conectaría por el puerto 25 a exim en bachillerato3 y enviaría el mensaje MAIL FROM: juan@primaria2.micolegio.edu.co, después enviaría RCPT TO: pablo@bachillerato3.micolegio.edu.co, después DATA y a continuación el cuerpo del correo comenzando con el encabezado de acuerdo al RFC 822, con un cuerpo de mensaje que emplee 7 bits y terminando con una línea que sólo tenga un punto. Por ejemplo

From: juan@primaria2.micolegio.edu.co
To: pablo@bachillerato3.micolegio.edu.co
Subject: Saludo

Un cortisimo saludo.
.  

Si lo desea puede experimentar con este protocolo, empleando telnet y el MTA de su computador: telnet localhost 25. Claro resulta más transparente empleando directamente exim (que tiene como alias el script sendmail):

 sendmail -bm
pablo@bachillerato3.micolegio.edu.co -f
juan@primaria2.micolegio.edu.co 

(para emplear -f con exim debe ser usuario autorizado).

[222] Otro caso típico que evita tener MTA en el computador del usuario, requiere otro computador que almacene los correos y el protocolo POP3 (RFC 1939).

[223] Cada línea de /etc/email-adresses será análoga a la siguiente, que indica reescribir la dirección del usuario juan como juan2@micolegio.edu.co:

juan:        juan2@micolegio.edu.co
	    

[224] Puede observarse con telnet el comportamiento de este protocolo por ejemplo:

telnet ftp.ibiblio.org 21
user anonymous
pass email@
pwd
pasv
retr index.html
	 

Como resultado del comando pasv el servidor FTP envía dirección y puerto al que debe conectarse el cliente para recibir la información. Si la respuesta es por ejemplo:

227 Entering Passive Mode (152,2,210,81,230,214)
	 

el cliente debe abrir otra conexión para recibir los datos con la máquina con IP 152.2.210.81 (ftp.ibiblio.org) puerto 230*256+214 (59094). Al hacer:

telnet 152.2.210.81 59094
	 

la conexión abierta recibirá el contenido del archivo README. Este ejemplo emplea FTP en modo pasivo, podría también indicarse modo activo empleando port en lugar de pasv. El comando port indica al servidor que inice una conexión con cierta dirección y puerto para realizar la transmisión, por ejemplo si en el cliente con dirección 1.2.3.4 se espera una conexión en el puerto 8000:

port 1,2,3,4,31,64
       

(note que 31*256+64 es 8000).

[225] Puede verse en funcionamiento este protocolo empleando telnet, por ejemplo:

	    telnet structio.sourceforge.net 80
	    GET http://structio.sourceforge.net/index.html