Gu�a de Administraci�n de Redes con Linux | ||
---|---|---|
Anterior | Cap�tulo 12. Caracter�sticas Importantesde Redes | Siguiente |
Los programas que proporcionan servicios de aplicaci�n a trav�s de la red se llaman demonios[1]. Un demonio es un programa que abre un puerto, com�nmente un puerto de alg�n servicio bien conocido, y espera conexiones entrantes en �l. Si ocurre una, el demonio crea un proceso hijo que acepta la conexi�n, mientras que el proceso padre contin�a escuchando m�s peticiones. Este mecanismo funciona bien, pero tiene unas pocas desventajas; al menos una instancia de cada posible servicio que se quiera proporcionar, debe estar activa en memoria a todas horas. Adem�s, la rutina software que hacen la escucha y la gesti�n del puerto tiene que ser replicada en cada uno de los demonios de red.
Para superar estas ineficiencias, muchas instalaciones Unix ejecutan un demonio de red especial, el cual debe ser considerado como un “super servidor.” Este demonio crea sockets en nombre de cada uno de los servicios y escucha en todos ellos simult�neamente. Cuando una conexi�n entrante es recibida en cualquiera de esos sockets, el super servidor acepta la conexi�n y replica el servicio especificado para ese puerto, pasando el socket a gestionarse a trav�s del proceso hijo. El servidor entonces, vuelve a la escucha.
startup El super servidor m�s com�n se llama inetd, el Demonio de Internet[2]. Se inicia en tiempo de arranque del sistema y toma la lista de servicios que ha de gestionar de un fichero de inicializaci�n llamado /etc/inetd.conf. Adem�s de estos servidores, hay un n�mero de servicios triviales realizados por inetd llamados servicios internos. Se incluyen chargen, el cu�l simplemente genera una cadena de caracteres, y daytime, el cu�l devuelve la idea del sistema de la hora del d�a.
Una entrada en este fichero consiste en una sola l�nea compuesta de los siguientes campos:
servicio tipo protocolo espera usuario servidor l�nea_de_�rdenes |
Cada uno de los campos se describe en la siguiente lista:
Da el nombre del servicio. El nombre del servicio tiene que ser traducido a un n�mero de puerto busc�ndolo en el fichero /etc/services. Este fichero se describir� m�s tarde en este cap�tulo, en la secci�n “ Secci�n 12.3.”
Especifica la clase de socket, o un socket de flujo “stream” (para protocolos orientados a la conexi�n) o un socket de datagrama “dgram” (para protocolos orientados a datagramas). Los servicios basados en TCP deber�an entonces utilizar siempre sockets de flujo, stream, mientras que servicios basados en UDP deber�an utilizar sockets de datagramas, dgram.
Nombra el protocolo de transporte usado por el servicio. Debe ser un nombre v�lido de protocolo que se encuentre en el fichero protocols, expuesto m�s adelante.
Esta opci�n se aplica s�lo a sockets dgram. Puede ser wait[3] o nowait[4]. Si se especifica wait, inetd ejecuta s�lo un servidor para el puerto especificado. El otro modo, contin�a escuchando inmediatamente en el puerto despu�s de ejecutar el servicio.
Esto es usado para servidores “de hilo �nico”[5] que leen todos los datagramas entrantes hasta que no llegan m�s, y despu�s terminan. Muchos servidores RPC son de este tipo y tienen que ser especificados como wait. El tipo opuesto, “multi-hilo”, [6] permite la ejecuci�n concurrente de un n�mero ilimitado de instancias. Estos servidores deben especificarse como nowait.
Los sockets de flujo, “stream”, deben usar siempre nowait.
Esto es el identificador de registro del usuario[7] que ser� propietario del procesos mientras se est� ejecutando. �ste ser� muchas veces el usuario root, pero algunos servicios pueden usar cuentas distintas. Es una buena idea aplicar el principio del m�nimo privilegio aqu�, lo que significa que usted no debe ejecutar �rdenes bajo cuentas privilegiadas si el programa no requiere esto para su correcto funcionamiento. Por ejemplo, el servidor de noticias NNTP ejecutado como news, mientras sirve noticias puede ser un riesgo de seguridad (como tftp o finger) que son muchas veces ejecutados como nobody.
Proporciona el camino completo del programa servidor a ser ejecutado. Los servicios internos se marcan con la palabra clave internal.
Esta es la l�nea de �rdenes que se va a pasar al servidor. Comienza con el nombre del servidor a ejecutar y puede incluir cualquier argumento que se le necesiten pasar. Si est� usando encapsulaci�n TCP [8], especificar� el camino completo al servidor aqu�. Si no, entonces especificar� el nombre del servidor como quiera que aparezca en un listado de procesos. Hablaremos acerca de encapsulaci�n TCP brevemente.
Este campo est� vac�o para los servicios internos.
Un ejemplo del fichero inetd.conf se expone en Ejemplo 12-1. El servicio finger est� comentado as� que no est� disponible. Esto se hace a menudo por razones de seguridad, porque puede ser usado por atacantes para obtener nombres y otros detalles de los usuarios de su sistema.
Ejemplo 12-1. Un ejemplo del fichero /etc/inetd.conf
# # inetd services ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless #login stream tcp nowait root /usr/sbin/rlogind in.rlogind #shell stream tcp nowait root /usr/sbin/rshd in.rshd #exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # inetd internal services # daytime stream tcp nowait root internal daytime dgram udp nowait root internal time stream tcp nowait root internal time dgram udp nowait root internal echo stream tcp nowait root internal echo dgram udp nowait root internal discard stream tcp nowait root internal discard dgram udp nowait root internal chargen stream tcp nowait root internal chargen dgram udp nowait root internal |
[1] | daemons |
[2] | Internet Daemon en ingl�s, N. del T. |
[3] | espera |
[4] | no espera |
[5] | single-threaded |
[6] | multi-threaded |
[7] | login ID |
[8] | TCP wrapper |