17.4. Archivos de configuración xinetd

Los archivos de configuración para xinetd son los siguientes:

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:

NotaNota
 

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:

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.

NotaNota
 

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:

  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.

ImportanteImportante
 

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.