12.1. The inetd Super Server

Los programas que proporcionan servicios a través de la red se llaman daemons. Un daemon es un programa que abre un puerto, cumunmente un puerto conocido, y espera conexiones entrantes en él. Si ocurre una, el daemon crea un proceso hijo que acepta la conexión, mientras que el proceso padre continúa escuchando para futuras peticiones. Este mecanismo trabaja bien, pero tiene algunas desventajas; al menos una instancia de cada posible servicio de los que usted quiere proveer, tiene que estar activa en memoria al mismo tiempo. Además, la rutina software que escucha y maneja el puerto tiene que ser replicada en cada uno de los network daemon.

Para superar esta ineficiencia, muchas instalaciones Unix ejecutan un network daemon especial, el cual debe ser considerado como “super server.” este daemon crea sockets en favor a un número de servicios y listens todos ellos simultáneamente. Cuando una conexión entrante es recibida en cualquiera de esos sockets, el super server acepta la conexión y produce el server especificado para ese puerto, pasando el socket a través del proceso hijo el cual lo maneja. El server entonces, vuelve a escuchar.

startup El super server más común se llama inetd, the Internet Daemon. Se inicia en el arranque del sistema y coge la lista de servicios que ha de manejar del fichero de inicialización llamado /etc/inetd.conf. Además de estos servicios, existe un número de servicios triviales ejecutados por inetd autollamados internal services. Incluyen chargen, el cual simplemente genera cadenas de caracteres, y el daytime, el cual devuelve the system's idea of the time of day.

Las entradas en este fichero consisten en líneas sencillas compuestas de los siguientes campos:
    service type protocol wait user server cmdline

Cada uno de los campos estan descritos en la siguiente lista:

service

Proporciona el nombre del servicio. El nombre del servicio será traducido a un número de puerto para bloquearlo en el fichero /etc/services . Este fichero se describirá en este capítulo, en la sección Sección 12.3.”

type

Especifica el tipo de socket, un stream (para protocolos orientados a la conexión) o dgram (para protocolos datagrama). los servicios TCP deben utilizar siempre stream, mientras que servicios UDP utilizan dgram.

protocol

Proporciona el nombre del protocolo de transporte usado por el servicio. Debe ser un nombre válido de protocolo del fichero protocols, expuesto más adelante.

wait

Esta opción se aplica sólo a sockets dgram. Puede ser wait o nowait. Si se especifica wait, inetd ejecuta sólo un servicio para el puerto especificado cada vez. De otro modo, continua inmediatamente escuchando en el puerto despues de ejecutar el servicio.

Esto es usado para servicios “single-threaded” que leen todos los datagramas entrantes hasta que no llegan más, y después terminan. Muchos servicios RPC son de este tipo y tiene que ser especificados como wait. EL tipo de servicio opuesto, “multi-threaded” permiten un número ilimitado de instancias para ejecutarlas concurrentemente. Estos servicios deben especificarse como nowait.

sockets del tipo stream deben usar siempre nowait.

user

Esto es el login ID del usuario que será propietario de los procesos que ejecute. Este será muchas veces el usuario root , pero algunos servicios pueden usar otras cuentas. Es una buena idea aplicar el principio del mínimo privilegio aqui, lo que significa que usted no debe ejecutar comandos bajo cuentas privilegiadas si estos no lo necesitan para su correcto funcionamiento. Por ejemplo, el servicio de noticias NNTP ejecutado como news, mientras que servicios que conllevan riesgo de seguridad (como el tftp o finger) son muchas veces ejecutados como nobody.

server

Proporciona el camino completo del servicio a ejecutar. Internal services se marcan con la palabra internal.

cmdline

Este es el comando pasado al servicio. Se ejecuta con el nombre de servicio a ejecutar y puede incluir los argumentos que se le deban pasar. Si usted esta usando the TCP wrapper, especificará el camino completo del servicio aqui. De otro modo, especificará el nombre de servicio que quiera que aparezca en la lista de procesos. Hablaremos brevemente acerca de the TCP wrapper.

Este campo esta vacío para los servicios internos.

Un ejemplo del fichero inetd.conf se expone en Ejemplo 12-1. El servicio finger no esta disponible. Se debe a razones de seguridad, porque puede ser usado por atacantes para obtener nombres de usuario y otros detalles de su sistema.

Ejemplo 12-1. Un ejemplo del fcihero /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

The tftp daemon se explica fuera tambien. tftp implementa el Trivial File Transfer Protocol (TFTP), el cual permite transferir cualquier fichero desde nuestro sistema sin verificación de password. Esto es especialmente perjudicial para el fichero /etc/passwd,y más aun si usted no usa shadow passwords.

TFTP se usa para clientes sin discos y Xterminals para descargar su código desde servidores de arranque. Si usted necesita ejecutar tftpd por esta razón, asegurese de limitar su alcance a aquellos directorios desde los cuales los clientes puedan recuperar ficheros; deberá añadir esos nombres de directorio en la línea de comando tftpd. Esto se muestra en la segunda tftp linea del ejemplo.