15.4. Archivos de configuración xinetd
Los archivos de configuración para xinetd son los siguientes:
/etc/xinetd.conf — El archivo de configuración global de xinetd.
/etc/xinetd.d/ directory — El directorio que contiene todos los archivos específicos al servicio.
15.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 varios 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 a Sección 15.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 este archivo. Consulte Sección 15.4.3.1 para más detalles sobre las opciones de registro. |
15.4.2. El directorio /etc/xinetd.d/
Los archivos en el directorio /etc/xinetd.d/ contienen los archivos de configuración para cada servicio manejado por xinetd y los nombre de los archivos que se correlacionan con el servicio. Como sucede con xinetd.conf, este archivo es de sólo lectura 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 archivo separados 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 para coincidir un servicio 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 el proceso se ejecutará.
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.
15.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.
15.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).
RECORD — Graba información sobre el sistema remoto en el caso de que no se pueda iniciar el servicio. Esta opción la usan solo determinados tipos de servicios como login y finger, puede usar esta opción (log_on_failure).
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 xinetd.conf.
15.4.3.2. Opciones de control de acceso
Los usuarios de servicios xinetd pueden seleccionar usar reglas de acceso a hosts de wrappers TCP, proporciona 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 wrappers TCP se puede encontrar en Sección 15.2. Esta sección discute el uso de xinetd para controlar el acceso a los 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. |
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 archivo de cada servicio en /etc/xinetd.d puede contener sus propias reglas de control de acceso.
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, la combinación del comando xinetd para el control del acceso 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, su intento de conexión es registrado 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. |
15.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 los ficheros de configuración, y une específicamente el servicio a una dirección IP que se encuentre en uso en el 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 puede 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 21 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 tipo de 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, tal como limitar el número de conexiones simultáneas para el servicio redirigido.
15.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 Linux para más información. También consulte la página del manual de xinetd.conf.