17.4. Archivos de configuraci�n xinetd

17.4.3.1. Opciones de registro

Las siguientes opciones de registro est�n disponibles para /etc/xinetd.conf y los archivos de configuraci�n espec�ficos al servicio en el directorio /etc/xinetd.d/.

Abajo se muestra una lista de algunas de las opciones de registro usadas m�s com�nmente:

• ATTEMPT — Indica que se intent� realizar una conexi�n pero que �sta fall� (log_on_failure).

• DURATION — Indica el tiempo que un sistema remoto usa un servicio (log_on_success).

• EXIT — Indica el estado de salida o la se�al de t�rmino del servicio (log_on_success).

• HOST — Indica la direcci�n IP de la m�quina remota (log_on_failure y log_on_success).

• PID — Indica el ID del proceso del servidor que recibe la petici�n (log_on_success).

• USERID — Registra el usuario remoto que est� usando el m�todo definido en RFC 1413 para todos los servicios de multi procesos (log_on_failure y log_on_success).

Para una lista completa de las opciones de registro, consulte la p�gina de manual de xinetd.conf.

17.4.3.2. Opciones de control de acceso

Los usuarios de servicios xinetd pueden seleccionar usar reglas de acceso a hosts wrapped TCP, proporcionar control de acceso a trav�s de los archivos de configuraci�n xinetd, o una mezcla de ambos. La informaci�n concerniente al uso de los archivos de control de acceso a hosts wrapped TCP se puede encontrar en la Secci�n 17.2.

Esta secci�n discute el uso de xinetd para controlar el acceso a servicios.

El control de acceso xinetd es diferente del m�todo usado por los wrappers TCP. Mientras que los wrappers TCP colocan toda la configuraci�n del acceso dentro de dos archivos, /etc/hosts.allow y /etc/hosts.deny, el control de acceso de xinetd se encuentra en el archivo de configuraci�n de cada servicio dentro del directorio /etc/xinetd.d.

Las opciones de acceso a host siguientes son soportadas por xinetd:

• only_from — S�lo permite que las m�quinas espec�ficas usen el servicio.

• no_access — Impide que estas m�quinas usen el servicio.

• access_times — Especifica el intervalo de tiempo en el que un determinado servicio puede ser usado. El rango de tiempo debe especificarse en formato de 24 horas, HH:MM-HH:MM.

Las opciones only_from y no_access pueden usar una lista de direcciones IP o nombres de hosts, o pueden especificar una red completa. Como los wrappers TCP, combinando el control del acceso xinetd con una configuraci�n de conexi�n apropiada puede mejorar la seguridad mediante el bloqueo de peticiones de hosts vetados mientras que graba cada intento de conexi�n.

Por ejemplo, el siguiente archivo /etc/xinetd.d/telnet puede ser usado para bloquear el acceso a Telnet desde un un grupo de red particular y restringir el rango de tiempo general que inclusive los usuarios permitidos pueden conectarse:

service telnet
{
 disable = no
 flags = REUSE
 socket_type = stream
 wait = no
 user = root
 server = /usr/sbin/in.telnetd
 log_on_failure += USERID
 no_access = 10.0.1.0/24
 log_on_success += PID HOST EXIT
 access_times = 09:45-16:15
}

En este ejemplo, cuando un sistema cliente desde la red 10.0.1.0/24, tal como 10.0.1.2, intenta accesar el servicio Telnet, recibir� un mensaje indicando lo siguiente:

Connection closed by foreign host.

Adem�s, sus intentos de conexi�n son registrados en /var/log/secure como sigue:

May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

Cuando est� usando wrappers TCP en conjunto con controles de acceso xinetd, es importante entender la relaci�n entre los dos mecanismos de control de acceso.

A continuaci�n se muestra el orden de las operaciones seguido por xinetd cuando un cliente solicita una conexi�n:

1. El demonio xinetd accesa las reglas de acceso a hosts wrappers TCP a trav�s de una llamada a la librer�a libwrap.a. Si alguna regla de rechazo coincide con el host cliente, la conexi�n se rechaza. Si una regla de aceptaci�n coincide con el host cliente, la conexi�n es pasada al xinetd.

2. El demonio xinetd verifica sus propias reglas de acceso para el servicio xinetd y el servicio solicitado. Si una regla de rechazo coincide con el host cliente la conexi�n es rechazada. De lo contrario, xinetd inicia una instancia del servicio solicitado y pasa el control de la conexi�n al mismo.

17.4.3.3. Vincular y redirigir opciones

Los ficheros de configuraci�n de servicios para el comando xinetd tambi�n soportan la vinculaci�n del servicio a una direcci�n IP y el desv�o de las peticiones entrantes para dicho servicio a otra direcci�n IP, nombre de la m�quina o puerto.

La vinculaci�n es controlada con la opci�n bind que se encuentra en el archivo de configuraci�n espec�fico del servicio, y une espec�ficamente el servicio a una direcci�n IP del sistema. Una vez configurada, la opci�n bind s�lo permite peticiones para la direcci�n IP apropiada para accesar el servicio. De esta forma se pueden vincular servicios diferentes a interfaces de red diferentes basados en la necesidad.

Esto es �til sobre todo para los sistemas con m�ltiples adaptadores de red o con m�ltiples direcciones IP. En tales sistemas, los servicios inseguros como Telnet, se pueden configurar de modo que solo escuche a la interfaz conectada a una red privada, y no a la interfaz conectada a Internet.

La opci�n redirect acepta la direcci�n IP o el nombre de la m�quina seguido del n�mero de puerto. Dice al servicio que desv�e todas las peticiones para dicho servicio a una localizaci�n y n�mero de puerto espec�ficos. Esta caracter�stica se usa para establecer otro n�mero de puerto en el mismo sistema, desviar la petici�n a otra direcci�n IP en la misma m�quina, cambiar la petici�n a otro sistema y puerto completamente diferentes o con la combinaci�n de cualquiera de estas opciones. De esta manera, un usuario que est� conectado a un determinado servicio en un sistema puede ser redirigido a otro sistema sin ninguna interrupci�n.

El demonio xinetd lleva a cabo este desv�o lanzando un proceso que mantenga la conexi�n entre la m�quina cliente que est� mandando la petici�n y la m�quina que est� dando en ese momento el servicio, transfiriendo los datos de un sistema a otro.

El mayor beneficio de estas dos opciones se obtiene cuando se usan juntas. Vinculando un servicio a una direcci�n IP determinada en un sistema y luego desviando las peticiones de dicho servicio a una segunda m�quina que solo puede ver la primera m�quina, se puede usar un sistema interno que ofrezca servicios para una red completamente diferente. Alternativamente, estas opciones se pueden usar para limitar la exposici�n de un servicio determinado a una direcci�n IP conocida, as� como desviar todas las peticiones a ese servicio a otra m�quina configurada espec�ficamente para ese objetivo.

Por ejemplo, considere un sistema que se usa como firewall con la caracter�stica siguiente para su servicio Telnet:

service telnet
{
 socket_type		= stream
 wait			= no
 server			= /usr/sbin/in.telnetd
 log_on_success		+= DURATION USERID
 log_on_failure		+= USERID
 bind = 123.123.123.123
 redirect = 10.0.1.13 23
}

Las opciones bind y redirect en este archivo aseguran que el servicio Telnet en la m�quina est� enlazado con la direcci�n IP externa (123.123.123.123), la que se encarga de Internet. Adem�s, todas las peticiones del servicio Telnet enviadas a 123.123.123.123 son redirigidas a trav�s de una segunda tarjeta de red a una direcci�n IP interna (10.0.1.13) a la que solo tienen acceso el firewall y los sistemas internos. El firewall manda luego la comunicaci�n entre los dos sistemas y el sistema que se est� conectando piensa que est� conectado a 123.123.123.123 mientras que, de hecho, est� conectado a otra m�quina.

Esta caracter�stica es �til para los usuarios con conexiones de banda ancha y con una �nica direcci�n IP fija. Cuando se usa la Traducci�n de las direcciones de la red (la Network Address Translation NAT), los sistemas detr�s de la m�quina gateway, que est�n usando direcciones IP internas, no est�n disponibles desde afuera del sistema gateway. Sin embargo, cuando determinados servicios controlados por xinetd son configurados con las opciones bind y redirect, la m�quina gateway puede funcionar como un proxy entre los sistemas externos y una m�quina interna particular configurada para proporcionar el servicio. Adem�s, las opciones de control de acceso xinetd y de conexi�n est�n tambi�n disponibles para protecci�n adicional.

17.4.3.4. Opciones de administraci�n de recursos

El demonio xinetd puede a�adir un nivel b�sico de protecci�n de un ataque Denial of Service (DoS). Abajo se encuentra una lista de las directivas que pueden ayudar en limitar la efectividad de tales ataques:

• per_source — Define el n�mero m�ximo de instancias para un servicio por direcci�n IP. Acepta s�lo enteros como argumentos y puede ser usado en xinetd.conf y los archivos de configuraci�n espec�ficos al servicio xinetd.d/.

• cps — Define el m�ximo n�mero de conexiones por segundo. Esta directiva toma dos argumentos enteros separados por un espacio en blanco. El primero es el n�mero m�ximo de conexiones permitidas por segundo. El segundo es el n�mero de segundos xinetd que debe esperar antes de reactivar el servicio. S�lo acepta enteros como argumentos y puede ser usado en ambos xinetd.conf y los archivos de configuraci�n espec�ficos al servicio en el directorio xinetd.d/.

• max_load — Indica el umbral de uso del CPU para un servicio. Acepta un argumento en forma de n�mero de punto flotante.

Hay m�s opciones de administraci�n de recursos disponibles para xinetd. Vea el cap�tulo titulado Seguridad del servidor en el Manual de seguridad de Red Hat Enterprise Linux para m�s informaci�n. Tambi�n consulte la p�gina del manual de xinetd.conf.