Imprimación Xinetd

Xinetd es un tutor que gestiona el acceso a su computadora desde Internet. Es un demonio que se ejecuta todo el tiempo y escucha en todos los puertos las solicitudes de conexión o servicio. Si no ejecuta un servidor, no necesitará xinetd. Sin embargo, incluso si su computadora es solo para uso doméstico, es posible que deba permitir que otros accedan a los servicios de su computadora en algún momento en el futuro. Cuando tu lo hagas, necesitará instalar xinetd para proteger su computadora de actividades maliciosas.

Sistema operativo

La utilidad xinetd fue escrita para Unix y sistemas similares a Unix. Por lo tanto, se instalará en Linux y Mac OS, pero no en Windows. El programa es de uso gratuito y se puede acceder desde GitHub.

Puede obtener el programa de este repositorio maestro y también hay una bifurcación del código. Este es un programa conocido y confiable que se ha descargado e instalado muchas veces, por lo que no debe preocuparse por los peligros de que el programa sea un falso malicioso.

Propósito de xinetd

El sistema xinet está diseñado para funcionar como un servidor. Probablemente sepa que en una conexión de internet típica, una computadora contacta a otra. La computadora que inicia el contacto se llama “cliente“Y el programa que se contacta es el”servidor.”El motivo habitual de la conexión es para que el cliente pueda obtener un servicio del servidor. Sin embargo, la computadora contactada necesita tener un programa en ejecución, esperando solicitudes. Esta es la función de xinetd.

El requisito básico para xinetd es que reciba solicitudes y las reenvíe a la aplicación correcta, que se indica mediante el número de puerto que está escrito en el encabezado de la solicitud de conexión o servicio que llega. El programa xinetd en realidad no proporciona el servicio solicitado, sino que actúa como un portero.

Alternativas: xinetd vs inetd

Los desarrolladores de xinetd no fueron las primeras personas en tener la idea de un programa que escuche en la red las solicitudes entrantes. De hecho, xinetd pretende ser una mejora en el programa original que realizó esta tarea, que se llama inetd.

El nombre “xinetd” es una abreviatura de “servicio de internet extendido daemon“. “Demonio de servicios de Internet” describe el original inetd. Con inetd obtienes la misma supervisión de solicitud de servidor que proporciona xinetd. Sin embargo, este demonio no tiene mecanismos de defensa y ahora se considera inseguro..

El viejo inetd no funcionaba solo. Transmitió solicitudes a tcpd, que verificó los archivos de permisos (hosts.allow y hosts.deny) Como su nombre indica, tcpd maneja las solicitudes de conexión TCP. Sin embargo, también examina los puertos UDP, por lo que es una implementación de interfaz de capa de transporte. También es posible que vea una mención de un contenedor TCP: este es solo otro nombre para tcpd. La inclusión de tcpd agregó alguna mejora en el control de acceso. Sin embargo, el proceso de permisos fue impulsado por dos archivos rellenados manualmente, por lo que no era una solución de seguridad muy completa..

Características de Xinetd

El modo de operación xinetd es similar al de inetd combinado con tcpd. Sin embargo, la solución xinetd tiene características de seguridad mucho mejores que la combinación inetd / tcpd. Las características del demonio incluyen:

• control de acceso para TCP y UDP
• registro de eventos que registra el éxito y el fracaso de la conexión
• control de acceso basado en segmentos de tiempo
• límite de servidor concurrente: defensa de ataque de denegación de servicio (DoS)
• límite de tamaño del archivo de registro
• asignación de servicios a diferentes interfaces, lo que permite que ciertos servicios se limiten a la red privada
• función proxy que incluye traducción de direcciones de red

Xinetd puede operar como mediador para Servicios de RPC. Sin embargo, esta función no está muy bien implementada. La falta de características de seguridad en RPC ha reducido la demanda de acceso a ese servicio, por lo que es dudoso que los desarrolladores de xinetd pasen tiempo perfeccionando su interfaz RPC.

Métodos de control de acceso.

Como inetd, xinetd le permite permitir o bloquear conexiones de acuerdo con la dirección IP del solicitante. Con inetd, también puede identificar las fuentes de conexión permitidas y bloqueadas por nombre de host o por nombre de dominio. Cada una de estas opciones requiere un procedimiento de búsqueda. En el caso de la opción de nombres de host, necesitaría tener esos nombres configurados en el sistema DNS de su propia red. Para dominios, probablemente sería mejor confiar en el sistema DNS público.

La elección de si identifica a los solicitantes por dirección IP, nombre de host o nombre de dominio depende de usted. sin embargo, seguir con la dirección IP crea conexiones más rápido porque elimina la necesidad de una fase de búsqueda.

Configuración del sistema

Para usar xinetd, primero debe instalarlo y luego actualizar el archivo de configuración. Esencialmente, el archivo de configuración es su centro de comando para xinetd. Como este programa es un demonio, una vez que lo inicias, continuará corriendo por siempre. No es una utilidad interactiva que puede ajustar en la línea de comando. Toda su comunicación con el programa ocurre a través del archivo de configuración.

El demonio continuará verificando el archivo de configuración cada vez que reciba una solicitud del mundo exterior. No carga la configuración en la memoria cuando se inicia. Eso significa puedes ajustar el rendimiento del demonio mientras se está ejecutando cambiando las instrucciones contenidas en el archivo de configuración.

El archivo de configuración para xinet es mucho más importante que los sistemas de configuración para otras utilidades. Esto se debe a que puede alterar las instrucciones para el demonio a través de la configuración sin necesidad de detener el programa xinetd y reiniciarlo.

Configurar el archivo de configuración

Busque el archivo /etc/xinetd.conf. Este es el archivo de configuración principal para el programa y actúa como una tabla de búsqueda que la aplicación lee para determinar qué conexiones permitir y qué servicios llamar.

Puede crear el archivo xinetd.conf desde un archivo existente inetd.conf archivo con el xconv.pl programa, que forma parte del paquete que puede descargar desde el repositorio de GitHub para xinetd. Ejecute el programa de conversión con el siguiente comando:

/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf

El nuevo archivo de configuración no es perfecto y necesitará más modificaciones antes de poder iniciar xinetd.

Sección de valores predeterminados del archivo de configuración

Cuando busca en su archivo xinetd.conf recién generado, debe centrarse en dos secciones de configuración clave. El primero de ellos es el valores predeterminados sección y el segundo es el servicios sección.

Como probablemente ya haya adivinado, la sección de valores predeterminados le dice a xinetd qué hacer si no encuentra instrucciones específicas para su tarea actual en la sección de servicios.

Algunas opciones clave que puede establecer en la sección predeterminada son:

• solo de
• sin acceso
• log_type
• log_on_success
• log_on_failure
• instancias
• por_source

Las siguientes secciones explican estas opciones con más detalle..

Condiciones de acceso

Solo de y sin acceso Efectivamente realice la misma tarea, que es bloquear (sin acceso) o permitir (solo_de) direcciones específicas o rangos de direcciones. Es aconsejable usar una de estas opciones para bloquear todo de forma predeterminada y luego crear una lista de servicios más abajo en el archivo de configuración. Con esta estrategia, usted se cubre si ocurre un evento que no tuvo en cuenta.

Estas dos opciones también son comandos válidos para incluir en la sección de servicios. Así que puedes comienza prohibiendo todo por defecto y luego agrega servicios. Si hay una sección de servicio relacionada con el tipo de solicitud de conexión que recibe xinetd, no verá la sección de valores predeterminados de la configuración.

Las instrucciones de only_from y no_access en una descripción de un servicio anula las declaraciones only_from y no_access en la sección de valores predeterminados.

El formato para estas dos opciones es

=

Recuerde que las direcciones se pueden expresar como direcciones IP, nombres de host o nombres de dominio. Sin embargo, es mejor atenerse a las direcciones IP. Puede usar la notación CIDR para especificar un rango. Aquí hay dos ejemplos de cómo puede usar estas opciones:

no_access = 0.0.0.0/0

Esta es probablemente la línea más común en la sección de valores predeterminados porque bloquea a todos. La sección de valores predeterminados solo está allí en el archivo de configuración para indicarle a xinetd qué hacer en caso de una solicitud de servicio que no está cubierta en la sección de servicios. Debería asumir que podrá proporcionar instrucciones específicas para cada tipo de servicio que su computadora pueda proporcionar, por lo que es razonable afirmar que todas las demás solicitudes están bloqueadas. Como diría el portero de una fiesta VIP exclusiva: “Si no está en la lista, no entrará”.

Una alternativa a esta estrategia es dejar que todos entren. Lo implementaría con:

only_from = 0.0.0.0/0

Esta política realmente no tiene sentido en la sección de valores predeterminados. Solo se hace referencia a la sección predeterminada si no ha dado instrucciones para un servicio, por lo que cuando xinetd recurre a los valores predeterminados, tiene un caso que no tiene instrucciones proporcionadas. Por lo tanto, permitir el acceso en esas circunstancias provocaría un error porque no le ha dicho a xinetd qué hacer con la solicitud. Es lógico usar esta opción catch-all only_from dentro de la descripción de un servicio, por lo que este mensaje le indicaría a xinetd que permita solicitudes de todas las fuentes posibles para usar ese servicio.

Desafortunadamente, hay una característica de las opciones only_from y no_access que crearía un conflicto si implementara una política como se describe anteriormente. Es decir, tanto no_access como only_from son globales y xinetd los revisa a ambos cada vez que tiene una tarea que realizar. Entonces, si ha configurado ambos, el demonio validará la solicitud entrante contra esa declaración no_access en la sección de valores predeterminados a pesar de que hay una configuración de servicio válida configurada.

Esta peculiaridad de no_access y only_from ser global se puede superar decidiendo una política de solo usando uno u otro en su archivo xinetd.conf. Es una práctica común quedarse con only_from e ignorar la opción no_access. Puede crear una instrucción que solo abarque todo dejando la lista de direcciones en blanco en la sección predeterminada, es decir, “only_from = “Y eso permitirá que el programa xinetd use la configuración only_from en las descripciones de los servicios. Esto ocurrirá sin generar un conflicto porque la sección de valores predeterminados only_from se sobrescribe por la configuración only_from del servicio.

Molesto, si no coloca una declaración only_from o no_access en la sección de valores predeterminados, xinetd permitirá todas las conexiones que no ha cubierto en la sección de servicios, lo que probablemente creará un error.

El formato para enumerar varias direcciones como parámetros de ambas opciones es dejar un espacio entre cada dirección (sin comas). También puede incluir rangos CIDR en la lista.

Comandos de archivo de registro

los log_type, log_on_success, y log_on_failure Todas las opciones funcionan juntas. Cada uno tiene una serie de constantes que necesita alimentar en la opción como parámetros.

Utilice el atributo log_type para dar la ruta y el nombre de un archivo de registro y use el atributo log_on_success y log_on_failure para especificar qué campos deben escribirse en el registro del archivo de registro para cada evento.

Por ejemplo, escribiría una dirección de archivo de registro con:

log_type = ARCHIVO / usr / log / internetlog

Otra opción disponible con el atributo log_type es SYSLOG, que establece el nivel de mensaje para estos eventos que informará syslogd. Los valores posibles son:

• demonio
• auth
• usuario
• local0-7

Un ejemplo sería:

log_type = SYSLOG local1

los SYLOG el atributo no es esencial y es mucho menos importante que el ARCHIVO opción. Realmente necesita darle a su xinetd el nombre de un archivo de registro para escribir; no tiene que especificar el nivel de Syslog para mensajes de eventos.

Las opciones de informes disponibles para log_on_success son:

• PID – 0 si es un servicio interno de xinetd
• HOST – dirección del cliente
• USERID: identidad del usuario remoto
• SALIDA – estado de salida del proceso
• DURACIÓN – período de duración de la sesión

Las opciones de informes para log_on_failure son:

• HOST – dirección del cliente
• USERID: identidad del usuario remoto
• INTENTO: registra un intento de acceso fallido
• REGISTRO: toda la información disponible sobre el cliente

Puede incluir varias opciones en cada línea log_on_success y log_on_failure y deben estar separadas por espacios sin ningún tipo de puntuación. Por ejemplo:

log_type = ARCHIVO / usr / log / internetlog
log_on_success = SALIDA DE DURACIÓN DEL USUARIO DEL PID DE HOST
log_on_failure = REGISTRO DE INTENTOS DE USUARIO DE ANFITRIÓN

Es una práctica común mantener las declaraciones log_type, log_in_success y log_on_failure en líneas sucesivas en el archivo.

Controles de capacidad

Dos opciones más que necesita poner en xinetd.conf limitan el número de conexiones simultáneas que su servidor debe aceptar. Este es un factor importante y es una forma simple pero poderosa de derrotar los ataques de denegación de servicio (DoS). Las dos opciones que implementan esta estrategia son instancias y por_source.

La opción de instancias en la sección de valores predeterminados especifica la cantidad de conexiones que xinetd permitirá ejecutar simultáneamente y la opción per_source especifica la cantidad de solicitudes de conexión a las que el demonio responderá desde la misma dirección de origen. Ataques distribuidos de denegación de servicio (DDoS) evitará el límite per_source, pero no la opción de instancias. Desafortunadamente, la implementación de este límite de servicio bloqueará a los usuarios genuinos durante la duración del ataque..

El formato de estas dos opciones es muy sencillo:

= número.

El valor per_source debe ser menor que el valor de las instancias.

Ejemplo de sección de valores predeterminados

Al reunir todos los detalles explicados en esta sección, su declaración predeterminada de xinetd.conf debería verse así:

valores predeterminados
{
instancias = 20
per_source = 5
log_type = ARCHIVO / usr / log / internetlog
log_on_success = SALIDA DE DURACIÓN DEL USUARIO DEL PID DE HOST
log_on_failure = REGISTRO DE INTENTOS DE USUARIO DE ANFITRIÓN
only_from =
}

Cada archivo xinetd.conf debe tener una declaración predeterminada. No es necesario que tenga ninguna declaración de servicios..

Secciones de configuración del servicio

Para cada uno de los servicios que desea que entregue su servidor, debe escribir una sección de instrucciones de servicio en xinetd.conf. Si no escribe ningún servicio en el archivo de configuración, xinetd utilizará las especificaciones establecidas en la sección de valores predeterminados. También puede sobrescribir la configuración definida en las secciones predeterminadas al restablecer esos atributos con diferentes valores en la sección escrita para definir un servicio.

Tipos de servicio

Los atributos disponibles para la sección de servicios son diferentes para cada una de las tres categorías de servicio. Estos son:

• INTERNO
• NO INCLUIDO EN LISTADO
• RPC

La categoría de servicio (INTERNO / NO INCLUIDO / RPC) se puede especificar con el atributo tipo. Sin embargo, este atributo no es obligatorio y a menudo se omite.

Definiciones de atributos de servicio

Al escribir una especificación de atributo, todos los campos están separados por espacios o retornos de carro; no utiliza ningún tipo de separador o puntuación en la definición.

El diseño de una declaración de servicio es el mismo para la sección de valores predeterminados:

Servicio
{
  valor de operador de atributo
}

El operador utilizado para las declaraciones de atributos suele ser igual (“=“). Muy pocos atributos permiten agregar valores a una lista existente con “+=“O eliminado de una lista con”-=“- en ambos casos, escribe el operador sin las comillas que se muestran aquí.

Aquí están los atributos que están disponibles para un INTERNO Tipo de servicio:

• socket_type
• banderas
• bonito
• Espere
• protocolo (si no figura en / etc / services)
• puerto (si no figura en / etc / services)
• cps
• tiempos de acceso

Los atributos disponibles para un RPC servicio son:

• socket_type
• banderas
• usuario
• servidor
• server_args
• bonito
• Espere
• protocolo
• rpc_version
• rpc_number
• cps
• tiempos de acceso

los NO INCLUIDO EN LISTADO Los tipos de servicio pueden tener cualquiera de los siguientes atributos:

• socket_type
• banderas
• usuario
• servidor
• server_args
• carga maxima
• bonito
• Espere
• protocolo (si no figura en / etc / services)
• puerto (si no figura en / etc / services)
• tiempos de acceso
• cps

Fines de atributo de servicio

Los significados de estos atributos se muestran en la tabla a continuación:

Descripción del atributo

tipo	INTERNO, RPC, SIN LISTA o INTERNO SIN LISTA
socket_type	stream (TCP), dgram (UDP), raw (acceso directo IP) o seqpacket ().
carné de identidad	crea un nombre único para este servicio
banderas	explica a continuación la tabla
usuario	especifica la prioridad del servidor
servidor	La ruta y el programa del servicio.
argumentos del servidor	argumentos para pasar con la llamada de servicio
carga maxima	cantidad de procesos concurrentes para un servicio
bonito	aumenta la prioridad para el servicio
Espere	si | no: bloquea o permite el procesamiento concurrente de nuevas solicitudes
protocolo	puede omitirse si el protocolo aparece en / etc / protocolos
Puerto	el número de puerto también debe existir en / etc / services y ser el mismo número
rpc_version	versión de RPC
rpc_number	Número de RPC
cps	límite de conexión, el segundo argumento es opcional y proporciona una cantidad de segundos para esperar cuando se alcanza el límite
tiempos de acceso	horas del día en que se puede ejecutar un servicio
enlazar	responder a conexiones a una dirección IP específica
redirigir	reenvía las solicitudes de un servicio a otra computadora

los banderas El atributo puede tener los siguientes valores:

IDONLY: solo acepta conexiones de clientes que tienen un servidor de identificación

NORETRÍA: evita la creación de un nuevo proceso en caso de fallo de conexión

NOMBRES: el primer argumento en server_args es el servidor valor. Se usa al llamar a tcpd

Además de los atributos anteriores, las opciones que están disponibles en la sección de valores predeterminados también se pueden escribir en la definición de un servicio. Estos son:

• solo de
• sin acceso
• log_type
• log_on_success
• log_on_failure
• instancias
• por_source

El uso de estos atributos nuevamente sobrescribirá cualquier valor establecido para ellos en la sección predeterminada. Sin embargo, recuerde que el solo de y sin acceso los atributos son globales, por lo que debe organizar el uso de estas opciones para evitar parámetros en conflicto.

Ejemplos de declaraciones de servicio

Aquí hay dos ejemplos de la definición de un servicio..

ntalk de servicio
{
socket_type = dgram
espera = si
usuario = nadie
servidor = /usr/sbin/in.ntalkd
tiempos de acceso = 7: 00-12: 30 13: 30-21: 00
only_from = 192.168.1.0/24
}

servicio ftp
{
socket_type = flujo
espera = no
usuario = root
servidor = /usr/sbin/in.ftpd
server_args = -l
instancias = 4
bonito = 10
}

Tenga en cuenta el uso de tiempos de acceso en el ntalk definición. Esto utiliza dos rangos de tiempos con los tiempos desde y hasta separados por un guión (“-“) sin espacios. Los dos rangos de tiempo están separados por un espacio. Las definiciones de hora utilizan el formato de reloj de 24 horas..

los solo de atributo en el ntalk la definición limita el acceso a este servicio para que solo las direcciones de la red local puedan usarlo.

los ntalk el servicio tiene un socket_type de dgram, lo que significa que es un servicio UDP. los socket_type en el ftp la definición es corriente, lo que significa que este es un servicio TCP.

Crear múltiples instancias de un servicio

La definición de servicios utiliza el nombre del servicio como su identificador de forma predeterminada. Sin embargo, es posible que desee crear varias copias de un servicio y otorgar a cada atributo diferentes. Como el nombre del servicio debe corresponder con el nombre utilizado en el / etc / services archivo, sería imposible obtener varias versiones de un servicio en ejecución. Sin embargo, el atributo id habilita esta estrategia operativa.

Un uso muy común de este escenario sería cuando desea crear diferentes servidores FTP para acceso interno y externo. Con este método, puede mantener su almacenamiento de archivos para la oficina completamente separado de los archivos descargables que pone a disposición del público en general..

En este caso de uso, definiría “Servicio ftp” dos veces. Entonces le daría a una instancia el atributo id = ftp-internal y el otro id = ftp-externo. A partir de entonces, xinetd puede distinguir entre los dos. Para que cada instancia esté disponible para diferentes audiencias, debe utilizar el solo de Atributo para limitar el acceso al servicio interno ftp a solo direcciones en la red y acceso al servicio externo ftp a todas las direcciones que no son de la red.

Vincula una dirección a un servicio

El escenario de crear diferentes servicios para usuarios internos y externos puede ser de gran ayuda con el atributo de enlace. El termino “enlazar“Se utiliza con frecuencia en la programación TCP. Por lo general, significa asociar una conexión a un puerto, creando así una identificación para la sesión. En este caso, sin embargo, “vincular” significa algo diferente. En el ejemplo del acceso interno y externo al servidor FTP, puede vincular la dirección de red de la computadora a la instancia interna de ftp y la dirección IP pública de esa computadora a la instancia externa de ftp.

En este ejemplo, podría ser posible omitir el atributo only_from en la definición del servicio. Sin embargo, es más seguro dejar esas restricciones. Entonces, la definición completa de sus servidores FTP internos y externos sería:

servicio ftp
{
id = ftp-externo
servidor = /usr/sbin/in.ftpd
server_args = -l
instancias = 4
only_from = 0.0.0.0/0
enlace = 202.19.244.130
}

servicio ftp
{
id = ftp-internal
socket_type = flujo
servidor = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24
enlace = 192.168.1.5
}

Esta estrategia requiere que su servidor FTP tenga una dirección IP estática asignada para acceso público. Además, deberá configurar su servidor DHCP para reservar la misma dirección para su servidor FTP interno. Aunque el escenario anterior funciona cuando se usa una sola computadora para acceso interno y externo, también puede asignar las direcciones de computadoras separadas para cada instancia de FTP.

Deshabilitar servicios específicos de inetd

Existen tres servicios xinetd que dan información sobre el sistema.

• servidores: informe sobre los servidores en uso
• servicios: informe sobre los servicios disponibles, sus protocolos y sus puertos
• xadmin: combina los dos comandos anteriores

Estos servicios son una debilidad de seguridad. porque pueden ser utilizados por piratas informáticos para obtener información sobre su red y servidor. Por lo tanto, es mejor deshabilitarlos. Puede hacer esto con el atributo deshabilitado, que entra en su valores predeterminados definición. Simplemente incluya la siguiente línea en la sección de valores predeterminados para eliminar estas instalaciones:

deshabilitado = servicios de servidores xadmin

Con los cambios en el archivo de configuración detallados anteriormente, ahora puede comenzar a usar xinetd.

Ejecutando xinetd

Inicia xinetd en la línea de comando. El comando también se puede ejecutar desde un archivo por lotes, por lo que puede agregarlo a los procedimientos de inicio de su computadora. El programa se puede ejecutar con las siguientes opciones:

SwitchOptionDescription

-re		Modo de depuración
-syslog	syslog_facility	Lo mismo que log_type SYSLOG en los valores predeterminados del archivo conf
-archivo de registro	archivo de registro	Lo mismo que log_type FILE en el archivo conf por defecto
-F	archivo de configuración	Especifica el archivo de configuración: el valor predeterminado es /etc/xinetd.conf
-archivo pid	pid_file	Escriba el ID del proceso en pid_file
-firme		Nunca terminar
-límite	proc_limit	Número máximo de procesos que pueden ejecutarse simultáneamente
-logprocs	límite	Número máximo de servidores que pueden ejecutarse simultáneamente
-versión		Imprima la versión xinetd
-inetd_compat		Lea /etc/inetd.conf, así como el archivo de configuración xinetd
-cc	intervalo	Realizar comprobaciones de consistencia cada intervalo de segundos

También es posible iniciar xinetd sin ninguna opción.

Use xinetd

Si tiene una computadora con Linux, es posible que ya tenga instalado xinetd. Puede verificar ejecutando xinetd -version. Si su computadora ejecuta inetd, lo más probable es que no esté ejecutando Linux. Reemplace el programa con xinetd y convierta su archivo de configuración de compatibilidad inetd a uso xinetd como se explicó anteriormente.

¿Utiliza xinetd en este momento? Deja un mensaje en el Comentarios sección a continuación para compartir sus experiencias con la comunidad.

Ver también: 15 mejores servidores de Syslog gratuitos

Imagen: Conexión a internet de red de Pixabay. Licenciado bajo CC0 Creative Commons