Xinetd, o el Daemon de Servicios de Internet Extendidos, es un llamado super-servidor. Puede configurarlo para escuchar en el lugar de muchos servicios e iniciar el servicio que debe manejar una solicitud entrante solo cuando realmente llega al sistema, ahorrando así recursos. Si bien esto puede no parecer un gran problema en un sistema donde el tráfico es relativamente permanente, este servicio frente a otro enfoque tiene algunas ventajas interesantes, como registro o control de acceso.
En este artículo instalaremos xinetd en un RHEL 8 / CentOS 8 y pondremos el sshd demonio bajo su cuidado. Después de verificar la configuración, ajustaremos un poco la configuración para ver el control de acceso en acción.
En este tutorial aprenderás:
- Cómo instalar xinetd
- Cómo configurar sshd en RHEL 8/CentOS 8 como un servicio xinetd
- Cómo permitir el acceso solo desde una red específica al servicio sshd de xinetd
- Cómo auditar el tráfico de las entradas de registro de xinetd
Permitir el acceso desde un determinado segmento de red a sshd.
Requisitos de software y convenciones utilizadas
Requisitos de software y convenciones de la línea de comandos de Linux | Categoría | Requisitos, convenciones o versión de software utilizada |
|---|
| Sistema | RHEL 8 / CentOS 8 |
| Software | xinetd 2.3.15-23, OpenSSH 7.8p1 |
| Otro | Acceso privilegiado a su sistema Linux como root o a través de sudo comando. |
| Convenciones | # – requiere que los comandos de Linux dados se ejecuten con privilegios de root, ya sea directamente como usuario root o mediante el uso de sudo comando
$ – requiere que los comandos de Linux dados se ejecuten como un usuario normal sin privilegios |
Cómo instalar el servicio xinetd en Red Hat 8 instrucciones paso a paso
Xinetd se puede encontrar en los repositorios base después de configurar los repositorios oficiales de gestión de suscripciones. El sshd El servidor está instalado en cualquier Red Hat (y prácticamente en cualquier distribución de Linux) de forma predeterminada.
ADVERTENCIA
Tenga en cuenta que sshd se apagará durante esta configuración. NO intente completar esta guía en un sistema al que solo puede acceder con ssh, de lo contrario, perderá la conexión con el sistema en el momento en que apague sshd para iniciar el servidor xinetd. - Primero necesitamos instalar el
xinetd demonio. Usaremos dnf :# dnf install xinetd
- Si por alguna razón su sistema no contiene la instalación de OpenSSH, puede instalar paquetes como en este caso el
openssh paquete de la misma manera que arriba:# dnf install openssh
- Xinetd viene con un archivo de configuración predeterminado
/etc/xinetd.conf , así como algunos buenos ejemplos en el /etc/xinetd.d/ directorio, todo deshabilitado por defecto. Con un editor de texto como vi o nano , vamos a crear un nuevo archivo de texto /etc/xinetd.d/ssh con el siguiente contenido (tenga en cuenta que la nueva línea después del nombre del servicio es obligatoria):service ssh
{
disable = no
socket_type = stream
protocol = tcp
port = 22
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i
}
- Si
sshd el servidor se está ejecutando en el sistema, debemos detenerlo; de lo contrario, xinetd no se puede vincular al puerto TCP 22. Este es el paso en el que se desconectará si ha iniciado sesión a través de ssh.# systemctl stop sshd
Si planeamos usar sshd sobre xinetd a largo plazo, también podemos deshabilitar el systemd servicio para él, para evitar que se inicie en el momento del arranque:
systemctl disable sshd
- Ahora podemos iniciar
xinetd :# systemctl start xinetd
Y, opcionalmente, habilite el inicio en el momento del arranque:
# systemctl enable xinetd
- Después de que se inicia xinetd, podemos iniciar sesión a través de ssh, ya que nuestra configuración básica no contiene ninguna restricción adicional. Para probar el servicio, solicitamos iniciar sesión en
localhost :# ssh localhost
root@localhost's password:
Last login: Sun Mar 31 17:30:07 2019 from 192.168.1.7
#
- Agreguemos otra línea a
/etc/xinetd.d/ssh , justo antes de la pulsera de cierre:[...]
server = /usr/sbin/sshd
server_args = -i
only_from = 192.168.0.0
}
Con esta configuración, restringimos el acceso solo desde el segmento de red 192.168.*.*. Necesitamos reiniciar xinetd para que este cambio de configuración surta efecto:
# systemctl restart xinetd
- Nuestra máquina de laboratorio tiene más de una interfaz. Para probar la restricción anterior, intentaremos conectarnos a una interfaz que no esté permitida por la configuración de xinetd y una que sí esté permitida:
# hostname -i
fe80::6301:609f:4a45:1591%enp0s3 fe80::6f06:dfde:b513:1a0e%enp0s8 10.0.2.15 192.168.1.14 192.168.122.1
Intentaremos abrir la conexión desde el propio sistema, por lo que nuestra dirección IP de origen será la misma que la del destino al que intentamos conectarnos. Por lo tanto, cuando intentamos conectarnos a 10.0.2.15 , no podemos conectarnos:
# ssh 10.0.2.15
ssh_exchange_identification: read: Connection reset by peer
Mientras que la dirección 192.168.1.14 está dentro del rango de direcciones permitido. Obtendremos la solicitud de contraseña y podremos iniciar sesión:
# ssh 192.168.1.14
[email protected]'s password:
- Como no hemos cambiado la configuración de registro predeterminada, nuestros intentos de inicio de sesión (o, en otras palabras, nuestros intentos de acceder al servicio xinetd) se registrarán en
/var/log/messages . Las entradas de registro se pueden encontrar con un simple grep :cat /var/log/messages | grep xinetd
Mar 31 18:30:13 rhel8lab xinetd[4044]: START: ssh pid=4048 from=::ffff:10.0.2.15
Mar 31 18:30:13 rhel8lab xinetd[4048]: FAIL: ssh address from=::ffff:10.0.2.15
Mar 31 18:30:13 rhel8lab xinetd[4044]: EXIT: ssh status=0 pid=4048 duration=0(sec)
Mar 31 18:30:18 rhel8lab xinetd[4044]: START: ssh pid=4050 from=::ffff:192.168.1.14
Estos mensajes facilitan saber cómo se accedió a nuestros servicios. Si bien hay muchas otras opciones (incluida la limitación de conexiones concurrentes o la configuración de tiempos de espera después de conexiones fallidas para evitar ataques de DOS), esta sencilla configuración muestra el poder de este súper servidor que puede facilitar la vida del administrador de sistemas, especialmente abarrotado, orientado a Internet. sistemas.