Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux 4: Manual de referencia - Archivos de configuraci�n xinetd

17.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/ — El directorio que contiene todos los archivos espec�ficos al servicio.

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.

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:

  • 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.

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire