El fichero /etc/inetd.conf

Este fichero es el utilizado por el demonio inetd, conocido como el superservidor de red. El demonio inetd es el encargado de ofrecer la mayoría de servicios de nuestro equipo hacia el resto de máquinas, y por tanto debemos cuidar mucho su correcta configuración. Posteriormente hablaremos de cómo restringir servicios, tanto ofrecidos por este demonio como servidos independientemente.

Cada línea (excepto las que comienzar por `#', que son tratadas como comentarios) del archivo /etc/inetd.conf le indica a inetd cómo se ha de comportar cuando recibe una petición en cierto puerto; en cada una de ellas existen al menos seis campos (en algunos clones de Unix pueden ser más, como se explica en [SH95]), cuyo significado es el siguiente:

• Servicio
  Este campo indica el nombre del servicio asociado a la línea correspondiente de
  /etc/inetd.conf; el nombre ha de existir en /etc/services para ser considerado correcto, o en /etc/rpc si se trata de servicios basados en el RPC (Remote Procedure Call) de Sun Microsystems. En este último caso se ha de acompañar el nombre del servicio con el número de versión RPC, separando ambos con el carácter `/'.
• Socket
  Aquí se indica el tipo de socket asociado a la conexión. Aunque dependiendo del clon de Unix utilizado existen una serie de identificadores válidos, lo normal es que asociado al protocolo TCP se utilicen sockets de tipo stream, mientras que si el protocolo es UDP el tipo del socket sea dgram (datagrama).
• Protocolo
  El protocolo debe ser un protocolo definido en /etc/protocols, generalmente TCP o UDP. Si se trata de servicios RPC, de nuevo hay que indicarlo utilizando rpc antes del nombre del protocolo, separado de él por el carácter `/' al igual que sucedía con el nombre; por ejemplo, en este caso podríamos tener protocolos como rpc/tcp o rpc/udp.
• Concurrencia
  El campo de concurrencia sólamente es aplicable a sockets de tipo datagrama (dgram); el resto de tipos han de contener una entrada nowait en este campo. Si el servidor que ha de atender la petición es multihilo (es decir, puede anteder varias peticiones simultáneamente), hemos de indicarle al sistema de red que libere el socket asociado a una conexión de forma que inetd pueda seguir aceptando peticiones en dicho socket; en este caso utilizaremos la opción nowait. Si por el contrario se trata de un servidor unihilo (acepta peticiones de forma secuencial, hasta que no finaliza con una no puede escuchar la siguiente) especificaremos wait.
  
  Especificar correctamente el modelo de concurrencia a seguir en un determinado servicio es importante para nuestra seguridad, especialmente para prevenir ataques de negación de servicio (DoS). Si especificamos wait, inetd no podrá atender una petición hasta que no finalice el servicio de la actual, por lo que si este servicio es muy costoso la segunda petición no será servida en un tiempo razonable (o incluso nunca, si inetd se queda bloqueado por cualquier motivo). Si por el contrario especificamos nowait, el número de conexiones simultáneas quizás llegue a ser lo suficientemente grande como para degradar las prestaciones del sistema, lo que por supuesto no es conveniente para nosotros. Para evitar ataques de este estilo, la mayoría de sistemas Unix actuales permiten especificar (junto a wait o nowait, separado de él por un punto) el número máximo de peticiones a un servicio durante un intervalo de tiempo (generalmente un minuto), de forma que si este número se sobrepasa inetd asume que alguien está intentando una negación de servicio contra él, por lo que deja de ofrecer ese servicio durante cierto tiempo (algunos clones de Unix incluso paran inetd, es conveniente consultar la documentación en cada caso). Como evidentemente esto también es una negación de servicio, algo muy común entre administradores es aprovechar las facilidades de planificación de Unix para enviar cada poco tiempo la señal SIGHUP al demonio inetd, de forma que este relea su fichero de configuración y vuelva a funcionar normalmente. Por ejemplo, para conseguir esto podemos añadir a nuestro fichero crontab una línea como la siguiente:

  00,10,20,30,40,50 * * * *           pkill -HUP inetd
  

  Con esto conseguimos que inetd se reconfigure cada diez minutos (el equivalente a pkill en ciertos Unices es killall, pero es recomendable consultar el manual para asegurarse de lo que esta orden provoca).
• Usuario
  En este campo se ha de indicar el nombre de usuario bajo cuya identidad se ha de ejecutar el programa que atiende cada servicio; esto es así para poder lanzar servidores sin que posean los privilegios del root, con lo que un posible error en su funcionamiento no tenga consecuencias excesivamente graves. Para el grupo, se asume el grupo primario del usuario especificado, aunque se puede indicar un grupo diferente indicándolo junto al nombre, separado de éste por un punto.
• Programa
  Por último, en cada línea de /etc/inetd.conf hemos de indicar la ruta del programa encargado de servir cada petición que inetd recibe en un puerto determinado, junto a los argumentos de dicho programa. El servidor inetd es capaz de ofrecer pequeños servicios basado en TCP por sí mismo, sin necesidad de invocar a otros programas; ejemplos de este tipo de servicios son time, echo o chargen. En este caso, el valor de este campo ha de ser internal.

De esta forma, si en /etc/inetd.conf tenemos una línea como

telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd

entonces inetd sabe que cuando reciba una petición al puerto telnet ha de abrir un socket tipo stream (el habitual para el protocolo TCP) y ejecutar fork() y exec() del programa
/usr/sbin/in.telnetd, bajo la identidad de root.