xinetd

El demonio xinetd es un sper servicio de envolturas TCP que controla acceso a

un subconjunto de servicios de red populares, entre ellos FTP, IMAP y Telnet.
Tambin orece opciones de coni!uraci"n para control de acceso, re!istro
mejorado, vinculaci"n, redirecci"n y control de utili#aci"n de recursos.
Cuando un cliente intenta conectarse a un servicio de red controlado por xinetd,
el s$per servicio recibe la solicitud y revisa si %ay re!las de control de acceso de
envolturas TCP.
Al autori#ar el acceso, xinetd veriicar& si la cone'i"n est& permitida bajo sus
propias re!las de acceso para ese servicio. Tambin veriicar& si el servicio puede
tener m&s recursos asi!nados y si no inrin!e nin!una de las re!las deinidas.
(i todas estas condiciones se cumplen )es decir, si se permite el acceso al servicio*
si el servicio no %a alcan#ado el l+mite de recursos y si el servicio no inrin!e
nin!una re!la deinida,, xinetdiniciar& una instancia del servicio solicitado y
pasar& control de la cone'i"n. Cuando la cone'i"n se estable#ca, xinetd no %ar&
m&s parte de la comunicaci"n entre el cliente y el servidor.

El directorio /etc/xinetd.d/
El directorio /etc/xinetd.d/ contiene los arc%ivos de coni!uraci"n para cada servicio
administrado por xinetd y los nombres de los arc%ivos se relacionan con el servicio.
Como con xinetd.conf, este directorio se lee $nicamente cuando se inicia el
servicio xinetd. Para que los cambios se eect$en, el administrador debe reiniciar el
servicio xinetd.
El ormato de arc%ivos en el directorio /etc/xinetd.d/ usa las mismas convenciones
que /etc/xinetd.conf. -a ra#"n principal por la cual la coni!uraci"n para cada
servicio se almacena en un servicio independiente es la de acilitar la personali#aci"n y
para que otros servicios se aecten menos.
Para entender c"mo se estructuran estos arc%ivos, considere el
arc%ivo /etc/xinetd.d/krb5-telnet.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}
Estas l+neas controlan varios aspectos de control del servicio telnet.
o service / Especiica el nombre del servicio, por lo !eneral uno de los que aparece
en la lista del arc%ivo /etc/services.
o flags / Establece el n$mero de atributos para la cone'i"n. REUSE le pide
a xinetdque reutilice el soc0et para una cone'i"n de Telnet.
Nota
El indicador REUSE est& depreciado. A%ora, todos los servicios impl+citamente usan el
indicador REUSE .
o socket_type / Establece el tipo de cone'i"n de red para stream.
o wait / Especiica si el servicio es de un solo %ilo )yes, o de varios %ilos )no,.
o user / Especiica el I1 de usuario bajo el cual se ejecuta el proceso.
o server / Especiica el binario ejecutable que se va a lan#ar.
o log_on_failure / Especiica los par&metros para log_on_failure adem&s de
los que ya est&n deinidos en xinetd.conf.
o disable / Especiica si el servicio est& in%abilitado )yes, o %abilitado )no,.


Archivos de configuracin xinetd
-os arc%ivos de coni!uraci"n para xinetd son los si!uientes.
o /etc/xinetd.conf / El arc%ivo de coni!uraci"n !lobal xinetd.
o /etc/xinetd.d/ / El directorio que contiene todos los arc%ivos espec+icos del
servicio.
2.3.4.1. El archivo /etc/xinetd.conf
El arc%ivo /etc/xinetd.conf contiene los par&metros de coni!uraci"n !enerales que
aectan a cada servicio bajo el control de xinetd. (e lee cuando el
servicio xinetd inicia, para que los cambios de coni!uraci"n pueden eectuarse,
necesitar& reiniciar el servicio xinetd. A continuaci"n, se presenta un ejemplo del
arc%ivo /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 controlas los si!uientes aspectos de xinetd.
o instances / Especiica el n$mero m&'imo de solicitudes simult&neas
que xinetdpuede procesar.
o log_type / Coni!ura xinetd para usar el recurso de re!istro authpriv, el cual
re!istra las entradas al arc%ivo /var/log/secure. Al a2adir una directiva tal
como FILE /var/log/xinetdlog se crear+a un arc%ivo de re!istro personali#ado
llamado xinetdlog en el directorio /var/log/.
o log_on_success / Coni!ura a xinetd para que re!istre los intentos de cone'i"n
correctos. -a direcci"n IP de %ost remoto predeterminada y el I1 del proceso del
servidor que procesa la solicitud ser&n re!istrados.
o log_on_failure / Coni!ura a xinetd par re!istrar los intentos de cone'iones
allidas o que %an sido dene!adas.
o cps / Coni!ura a xinetd para que no permita m&s de 34 cone'iones por se!undo
para nin!$n servicio. (i se sobrepasa este l+mite, el servicio ser& retirado por 56
se!undos.
o includedir /etc/xinetd.d/ / Incluye las opciones declaradas en los arc%ivos
de coni!uraci"n del servicio locali#ados en el directorio /etc/xinetd.d/. Consulte
la(ecci"n 3.5.7.3, 8El directorio 9etc9'inetd.d9: para obtener mayor inormaci"n.
Nota
Tanto los par&metros de log_on_success como de log_on_failure en el
directorio /etc/xinetd.conf suelen ser modiicados en los arc%ivos de
coni!uraci"n espec+ica del servicio. Por lo tanto, puede aparecer m&s inormaci"n en
el arc%ivo de re!istro de un determinado arc%ivo que en el
arc%ivo /etc/xinetd.conf puede indicar.
Cmo alterar los archivos de configuracin xinetd
E'iste un ran!o de directivas disponible para los servicios prote!idos por xinetd. Esta
secci"n resalta al!unas de las opciones m&s comunes.
3.5.7.5.;. <pciones de re!istro
-as opciones de re!istro a continuaci"n est&n disponibles tanto
para /etc/xinetd.conf como para los arc%ivos de coni!uraci"n de servicios
espec+icos dentro del directorio /etc/xinetd.d/.
A continuaci"n, una lista de al!unas de las opciones de re!istro m&s utili#adas.
o ATTEMPT / =e!istra el %ec%o de que se %i#o un intento allido )log_on_failure,.
o DURATION / =e!istra el tiempo de servicio utili#ado por un sistema remoto
)log_on_success,.
o EXIT / =e!istra el estatus de salida o se2al de terminaci"n del servicio
)log_on_success,.
o HOST / =e!istra la direcci"n IP de %ost )log_on_failure y log_on_success,.
o PID / =e!istra el I1 de proceso del servidor que recibe la solicitud
)log_on_success,.
o USERID / =e!istra al usuario remoto que utili#a el mtodo deinido en =FC ;7;5 para
todos los servicios de lujo de multi%ilos )log_on_failure ylog_on_success,.

<pciones de control de acceso
-os usuarios de servicios xinetd pueden ele!ir el uso de las re!las de acceso de %osts de
envolturas TCP, proporcionar control de acceso a travs de arc%ivos de coni!uraci"n
de xinetdo una combinaci"n de los dos. Consulte la (ecci"n 3.5.3, 8Arc%ivos de
coni!uraci"n de envolturas TCP : para obtener mayor inormaci"n sobre arc%ivos de
control de acceso de %osts de envolturas TCPor more inormation about TCP >rappers
%osts access control iles.
Esta secci"n aborda el uso de xinetd para controlar el acceso a servicios.
Nota
A dierencia de las envolturas TCP, los cambios al control de acceso se eect$an si el
administrador de xinetd reinicia el servicio xinetd.
Tambin, a dierencia de las envolturas TCP, el control de acceso a travs
de xinetdsolamente aecta los servicios controlados por xinetd.
El control de acceso de %osts xinetd diiere del mtodo utili#ado por envolturas TCP.
Cuando las envolturas TCP sit$an toda la coni!uraci"n de acceso en dos
arc%ivos, /etc/hosts.allowy /etc/hosts.deny, el control de acceso
de xinetd se encuentra en cada arc%ivo de coni!uraci"n en el
directorio /etc/xinetd.d/.
-as opciones de acceso de %osts a continuaci"n est&n soportadas por xinetd.
o only_from / ?nicamente acepta %osts especiicados para usar el servicio.
o no_access / @loquea a los %osts listados para usar el servicio.
o access_times / Especiica el ran!o de tiempo que un servicio determinado puede
utili#arse. El ran!o debe establecerse en un ormato de 37 %oras, AA.MMBAA.MM.
-as opciones only_from y no_access pueden utili#ar una lista de todas las
direcciones IP o nombres de %osts, o pueden especiicar una red completa. I!ual que las
envolturas TCP, al combinar el control de acceso xinetd con la coni!uraci"n de re!istro
mejorada se puede aumentar la se!uridad al bloquear solicitudes de los %osts rec%a#ados
mientras se re!istra detalladamente cada intento de cone'i"n.
Por ejemplo, el si!uiente arc%ivo /etc/xinetd.d/telnet se utili#a para bloquear
el acceso Telnet desde un !rupo de red determinado y restrin!ir todo el intervalo de
tiempo que incluso los usuarios autori#ados pueden in!resar.
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
no_access = 172.16.45.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
}
En este ejemplo, cuando el sistema de cliente de una red 172.16.45.0/24 tal
como 172.16.45.2, intenta acceder al servicio Telnet, recibe el si!uiente mensaje.
Conexin cerrada por un host externo
Adem&s sus intentos de in!reso se re!istran en /var/log/messages, as+.
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address
from=172.16.45.107
Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285
from=172.16.45.107
Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0
pid=5285 duration=0(sec)
Al usar las envolturas TCP junto con los controles de acceso de xinetd, es importante
entender la relaci"n entre los dos mecanismos de control de acceso.
-a si!uiente es la secuencia de eventos se!uidos por xinetd cuando el cliente solicita
una cone'i"n.
;. El demonio xinetd accede a las re!las de acceso de las envolturas TCP mediante una
llamada de biblioteca libwrap.a. (i una re!la de ne!aci"n coincide con el cliente, la
cone'i"n se descartar&. (i una re!la de permiso coincide con el cliente, la cone'i"n
pasar& a xinetd.
3. El demonio xinetd veriica sus propias re!las de acceso tanto para el
servicio xinetdcomo para el servicio solicitado. (i una re!la de ne!aci"n coincide con
el cliente, la cone'i"n se descartar&. 1e lo contrario, xinetd iniciar& una instancia del
servicio solicitado y pasar& control de la cone'i"n de ese servicio.
Importante
(e debe tener cuidado al usar los controles de acceso de las envolturas TCP junto con los
controles de acceso xinetd. (i no se coni!uran correctamente pueden ocasionar
eectos indeseables.

<pciones de vinculaci"n y redirecci"n
-os arc%ivos de coni!uraci"n de servicios para xinetd soportan la vinculaci"n del
servicio a una direcci"n IP y las solicitudes de entrada de redirecci"n para ese servicio a
otra direcci"n IP, nombre de %ost o puerto.
-a vinculaci"n se controla con la opci"n bind en los arc%ivos de coni!uraci"n espec+icos
del servicio y enla#a al servicio a una direcci"n IP en el sistema. Cuando se coni!ura, la
opci"n bind $nicamente permite solicitudes para acceder al servicio a la direcci"n IP
correcta. Puede usar este mtodo para vincular dierentes servicios a diversas interaces
de red con base en los requisitos.
Esto es bastante $til en los sistemas con m$ltiples adaptadores de red o con m$ltiples
direcciones IP. En dic%os sistemas, los servicios que no son se!uros )como por ejemplo,
Telnet,, se pueden coni!urar para escuc%ar $nicamente a la intera# que est& conectada
a una red privada y no a la intera# conectada a la Internet.
-a opci"n redirect acepta una direcci"n IP o nombre de %ost se!uido de un n$mero de
puerto. Esta opci"n coni!ura el servicio para rediri!ir las solicitudes para este servicio a
un %ost especiicado o n$mero de puerto. Esta uncionalidad puede utili#arse para se2alar
las dierentes direcciones IP en la misma m&quina, cambiar la solicitud a un sistema y
n$mero de puerto totalmente dierentes o al!una combinaci"n de estas opciones. Cn
usuario que se conecte a un servicio en un sistema puede por lo tanto ser rediri!ido a otro
sistema sin interrupci"n.
El demonio xinetd puede reali#ar esta redirecci"n al !enerar un proceso que
permane#ca vivo para la duraci"n de la cone'i"n entre el cliente que solicita la m&quina
y el %ost que proporciona el servicio, al transerir los datos entre los dos sistemas.
-as ventajas de las opciones de bind y redirect son evidentes cuando se utili#an
juntas. Al vincular un servicio a una direcci"n IP particular en un sistema y lue!o rediri!ir
las solicitudes para este servicio a una se!unda m&quina que $nicamente la primera
m&quina puede ver, se puede utili#ar un sistema interno para proporcionar servicios a una
red totalmente dierente. Tambin estas opciones sirven para limitar la e'posici"n de un
determinado servicio en un equipo de %ost m$ltiple a una direcci"n IP conocida, como
tambin para rediri!ir las solicitudes para ese servicio a otra m&quina especialmente
coni!urada con ese prop"sito.
Por ejemplo, considere un sistema que se utilice como cortaue!os con esta
coni!uraci"n para el servicio de Telnet.
service telnet
{
socket_type = stream
wait = no
server = /usr/kerberos/sbin/telnetd
log_on_success += DURATION USERID
log_on_failure += USERID
bind = 123.123.123.123
redirect = 10.0.1.13 23
}
-as opciones bind y redirect en este arc%ivo !aranti#an que el servicio de Telnet en
la m&quina est asociado a una direcci"n IP e'terna )123.123.123.123,, la que se
encar!a de la Internet. Adem&s, las solicitudes al servicio de Telnet enviadas
a 123.123.123.123 se rediri!en a travs de un se!undo adaptador de red a una
direcci"n IP interna )10.0.1.13, que $nicamente el cortaue!os puede acceder. -ue!o,
el cortaue!os env+a la comunicaci"n entre los dos sistemas y el sistema que se conecta
piensa que est& conectado a 123.123.123.123cuando en realidad est& conectado a
una m&quina dierente.
Esta uncionalidad es bastante $til para usuarios con cone'iones de banda anc%a y una
sola direcci"n IP ija. Cuando se utili#a la Traducci"n de direcciones de red )DAT,, los
sistemas detr&s de la m&quina de puerta de enlace, que solamente utili#an las direcciones
IP internas, no est&n disponibles desde uera del sistema de puerta de enlace. (in
embar!o, cuando al!unos sistemas est&n controlados por las opciones bind y redirect,
la m&quina de puerta de enlace puede actuar como un pro'y entre los sistemas e'ternos
y la m&quina interna coni!urada para proporcionar el servicio. Adem&s, las diversas
opciones de re!istro y control de acceso xinetdest&n disponibles como protecci"n
adicional.