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

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS 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