17.4.1. El archivo /etc/xinetd.conf
El archivo /etc/xinetd.conf contiene par�metros de configuraci�n generales los cuales afectan cada servicio bajo el control de xinetd. Se lee una vez cuando el servicio xinetd es iniciado, por esto, para que los cambios de la configuraci�n tomen efecto, el administrador debe reiniciar el servicio xinetd. Abajo se muestra un ejemplo del archivo /etc/xinetd.conf:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d |
Estas l�neas controlan los siguientes aspectos de xinetd:
instances — Configura el m�ximo n�mero de peticiones que xinetd puede manejar simult�neamente.
log_type — Configura xinetd para usar la facilidad de registro authpriv, el cual escribe las entradas de registro al archivo /var/log/secure. Al agregar una directiva tal como FILE /var/log/xinetdlog aqu�, crear� un archivo de registro personalizado llamado xinetdlog en el directorio /var/log/.
log_on_success — Configura xinetd a registrar si la conexi�n es exitosa. Por defecto, la direcci�n IP del host remoto y el ID del proceso del servidor procesando la petici�n son grabados.
log_on_failure — Configura xinetd para registrar si hay una falla de conexi�n o si la conexi�n no es permitida.
cps — Configura xinetd para no permitir m�s de 25 conexiones por segundo a cualquier servicio dado. Si se alcanza este l�mite, el servicio es retirado por 30 segundos.
includedir /etc/xinetd.d/ — Incluye las opciones declaradas en los archivos de configuraci�n espec�ficos del servicio localizados en el directorio /etc/xinetd.d/. Consulte la Secci�n 17.4.2 para m�s informaci�n sobre este directorio.
 | Nota |
|---|
| | A menudo, las configuraciones log_on_success y log_on_failure en /etc/xinetd.conf son modificadas a�n m�s en los archivos de registro espec�ficos al servicio. Por esta raz�n, puede que aparezca m�s informaci�n en el registro de un servicio dado que lo que puede indicar el archivo/etc/xinetd.conf. Consulte la Secci�n 17.4.3.1 para m�s informaci�n. |
17.4.2. El directorio /etc/xinetd.d/
El directorio /etc/xinetd.d/ contiene los archivos de configuraci�n para cada servicio manejado por xinetd y los nombres de los archivos que se correlacionan con el servicio. Como sucede con xinetd.conf, este archivo s�lo es le�do cuando el servicio xinetd es arrancado. Para que los cambios tengan efecto, el administrador debe reiniciar el servicio xinetd.
El formato de los archivos en el directorio /etc/xinetd.d/ usan las mismas convenciones que /etc/xinetd.conf. La raz�n principal por la que la configuraci�n para cada servicio es almacenada en un archivo separado es hacer m�s f�cil la personalizaci�n y que sea menos probable afectar otros servicios.
Para tener una idea de c�mo estos archivos est�n estructurados, considere el archivo /etc/xinetd.d/telnet:
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = yes
} |
Estas l�neas controlan varios aspectos del servicio telnet:
service — Define el nombre del servicio, usualmente uno listado en el archivo /etc/services.
flags — Configura cualquier n�mero de atributos para la conexi�n. REUSE instruye xinetd a reutilizar el socket para una conexi�n Telnet.
socket_type — Configura el socket de red a escribir a stream.
wait — Define si el servicio es de un s�lo hilo (yes) o de m�ltiples hilos (no).
user — Define bajo qu� ID de usuario se ejecutar� el proceso.
server — Define el binario ejecutable a lanzar.
log_on_failure — Define los par�metros de registro para log_on_failure adem�s de aquellos ya definidos en xinetd.conf.
disable — Define si el servicio est� activo o no.
17.4.3. Modificar archivos de configuraci�n xinetd
Existe una gran cantidad de directivas disponibles para los servicios xinetd protegidos. Esta secci�n resalta algunos de las opciones usadas m�s com�nmente.
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.
| Nota |
|---|
| | A diferencia de los wrappers TCP, los cambios al control de acceso s�lo tengan efecto si el administrador de xinetd reinicia el servicio xinetd. A diferencia de los wrappers TCP, el control de acceso a trav�s de xinetd s�lo afecta a los servicios controlados por xinetd mismo. |
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:
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.
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.
 | Importante |
|---|
| | Se debe tener especial cuidado cuando se use el control de acceso wrappers TCP en conjunto con los controles xinetd. Un error en la configuraci�n puede generar resultados no deseados. |
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.
