Comment installer et configurer un exemple de service avec xinetd sur RHEL 8 / CentOS 8 Linux

Xinetd, ou Extended Internet Services Daemon, est un soi-disant super-serveur. Vous pouvez le configurer pour écouter à la place de nombreux services et démarrer le service qui ne doit traiter une demande entrante que lorsqu'elle arrive réellement au système, ce qui permet d'économiser des ressources. Bien que cela puisse ne pas sembler être un gros problème sur un système où le trafic est relativement permanent, ce service en face d'une autre approche présente des avantages intéressants, comme la journalisation ou le contrôle d'accès.

Dans cet article nous allons installer xinetd sur un RHEL 8 / CentOS 8, et nous allons mettre le sshd démon sous sa garde. Après avoir vérifié la configuration, nous allons peaufiner un peu la configuration pour voir le contrôle d'accès en action.

Dans ce didacticiel, vous apprendrez :

Comment installer xinetd
Comment configurer sshd sur RHEL 8/CentOS 8 en tant que service xinetd
Comment autoriser l'accès uniquement à partir d'un réseau spécifique au service sshd à partir de xinetd
Comment auditer le trafic à partir des entrées de journal xinetd

Autoriser l'accès d'un certain segment de réseau à sshd.

Configuration logicielle requise et conventions utilisées

Configuration logicielle requise et conventions de ligne de commande Linux
Catégorie	Exigences, conventions ou version du logiciel utilisée
Système	RHEL 8/CentOS 8
Logiciel	xinetd 2.3.15-23, OpenSSH 7.8p1
Autre	Accès privilégié à votre système Linux en tant que root ou via le `sudo` commande.
Conventions	# - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant `sudo` commande $ – nécessite que les commandes linux données soient exécutées en tant qu'utilisateur normal non privilégié

Comment installer le service xinetd dans Red Hat 8 instructions étape par étape

Xinetd peuvent être trouvés dans les référentiels de base après avoir configuré les référentiels officiels de gestion des abonnements. Le sshd serveur est installé par défaut sur n'importe quelle Red Hat (et à peu près n'importe quelle distribution Linux).

AVERTISSEMENT
Gardez à l'esprit que sshd sera désactivé pendant cette configuration. N'essayez PAS de terminer ce guide sur un système auquel vous ne pouvez accéder qu'avec ssh, sinon vous perdrez votre connexion au système à la minute où vous désactiverez sshd pour démarrer le serveur xinetd.

Premièrement, nous devons installer le xinetd démon. Nous utiliserons dnf :
```
# dnf install xinetd
```
Si pour une raison quelconque votre système ne contient pas l'installation d'OpenSSH, vous pouvez installer des packages comme dans ce cas le openssh package de la même manière que ci-dessus :
```
# dnf install openssh
```
Xinetd est livré avec un fichier de configuration par défaut /etc/xinetd.conf , ainsi que quelques exemples intéressants dans le /etc/xinetd.d/ répertoire, tous désactivés par défaut. Avec un éditeur de texte comme vi ou nano , créons un nouveau fichier texte /etc/xinetd.d/ssh avec le contenu suivant (notez que la nouvelle ligne après le nom du service est obligatoire) :
```
service ssh 
{
 disable     = no
 socket_type = stream
 protocol    = tcp
 port        = 22
 wait        = no
 user        = root
 server      = /usr/sbin/sshd
 server_args = -i
} 
```
Si le sshd serveur est en cours d'exécution sur le système, nous devons l'arrêter, sinon xinetd ne peut pas se lier au port TCP 22. C'est l'étape où vous serez déconnecté si vous êtes connecté via ssh.
```
# systemctl stop sshd
```
Si nous prévoyons d'utiliser sshd sur xinetd à long terme, nous pouvons également désactiver le systemd service pour lui, pour l'empêcher de démarrer au démarrage :
```
systemctl désactiver sshd
```
Nous pouvons maintenant démarrer xinetd :
```
# systemctl start xinetd
```
Et éventuellement activer le démarrage au démarrage :
```
# systemctl enable xinetd
```
Après le démarrage de xinetd, nous pouvons nous connecter via ssh, car notre configuration de base ne contient aucune restriction supplémentaire. Pour tester le service, nous vous demandons de vous connecter sur localhost :
```
# ssh localhostroot@localhost's password :Dernière connexion :dimanche 31 mars 17:30:07 2019 à partir de 192.168.1.7#
```

Ajoutons une autre ligne à /etc/xinetd.d/ssh , juste avant le bracelet de clôture :

[...] server =/usr/sbin/sshd server_args =-i only_from =192.168.0.0 }

Avec ce paramètre, nous restreignons l'accès uniquement à partir du segment de réseau 192.168.*.*. Nous devons redémarrer xinetd pour que ce changement de configuration prenne effet :

# systemctl redémarre xinetd

Notre machine de laboratoire a plus d'une interface. Pour tester la restriction ci-dessus, nous allons essayer de nous connecter pour nous connecter à une interface qui n'est pas autorisée par la configuration de xinetd, et une qui est effectivement autorisée :
```
# hostname -ife80::6301:609f:4a45:1591% enp0s3 fe80::6f06:dfde:b513:1a0e%enp0s8 10.0.2.15 192.168.1.14 192.168.122.1
```
Nous essaierons d'ouvrir la connexion à partir du système lui-même, de sorte que notre adresse IP source sera la même que la destination à laquelle nous essayons de nous connecter. Par conséquent, lorsque nous essayons de nous connecter à 10.0.2.15 , nous ne sommes pas autorisés à nous connecter :
```
# ssh 10.0.2.15ssh_exchange_identification :lecture :réinitialisation de la connexion par l'homologue
```
Alors que l'adresse 192.168.1.14 se trouve dans la plage d'adresses autorisée. Nous recevrons l'invite de mot de passe et nous pourrons nous connecter :
```
# ssh [email protected]'s password :
```
Comme nous n'avons pas modifié la configuration de journalisation par défaut, nos tentatives de connexion (ou en d'autres termes, nos tentatives d'accès au service xinetd) seront enregistrées dans /var/log/messages . Les entrées de journal peuvent être trouvées avec un simple grep :
```
cat /var/log/messages | grep xinetdMars 31 18:30:13 rhel8lab xinetd[4044] :DÉBUT :ssh pid=4048 de=::ffff:10.0.2.15Mars 31 18:30:13 rhel8lab xinetd[4048] :ÉCHEC :adresse ssh de= : :ffff:10.0.2.1531 mars 18:30:13 rhel8lab xinetd[4044] : SORTIE :statut ssh=0 pid=4048 durée=0(sec)31 mars 18:30:18 rhel8lab xinetd[4044] :DÉBUT :ssh pid =4050 de=::ffff:192.168.1.14
```
Ces messages permettent de savoir facilement comment nos services ont accédé. Bien qu'il existe de nombreuses autres options (y compris la limitation des connexions simultanées ou la définition de délais d'attente après l'échec des connexions pour empêcher les attaques DOS), cette configuration simple montre, espérons-le, la puissance de ce super-serveur qui peut faciliter la vie de l'administrateur système - en particulier surpeuplé, face à Internet. systèmes.