Les pare-feu tels que firewalld et iptables constituent une excellente première ligne de défense contre les intrusions, mais ils ne sont pas sans faille. Ils peuvent être piratés et souffrent également de vulnérabilités occasionnelles. Mais vous devez avoir un pare-feu basé sur l'hôte en cours d'exécution. Ce n'est qu'une des choses que vous installez et configurez sur chaque système. Et vous devez configurer votre pare-feu avant d'effectuer tout travail sur votre système. En d'autres termes, verrouillez votre système dès qu'il est en ligne.
Une fois que votre nouveau système est opérationnel et que vous l'avez sécurisé avec un pare-feu, il est temps de créer cette deuxième ligne de défense avec les entrées correspondantes dans /etc/hosts.allow (hosts.allow) et /etc/hosts. refuser les fichiers (hosts.deny). Si le pare-feu est arrêté, pour une raison quelconque, les entrées hosts.allow et hosts.deny continueront à protéger votre système contre les intrusions. C'est cette couche supplémentaire qui améliore la sécurité de votre système en fournissant une sécurité intégrée pour votre pare-feu.
Créer les entrées AUTORISER
J'espère que vous avez lu mon article "Outils Sysadmin :Comment utiliser iptables". Si ce n'est pas le cas, veuillez prendre quelques minutes pour le lire avant de vous plonger dans vos fichiers hosts.allow et hosts.deny, car je vais utiliser l'article iptables comme référence pour effectuer les entrées correspondantes.
Remarque :Il convient de préciser ici que les entrées effectuées dans hosts.allow peuvent vous empêcher d'accéder à votre système, ce qui n'est pas ce que vous souhaitez. Si cela se produit, vous devrez accéder à la console système via KVM, KVM virtuel, iLO ou console de machine virtuelle.
La règle SSH de l'article mentionné ci-dessus indique iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT . Cette règle permet à tout système du réseau 192.168.1.0/24 de se connecter au système local via SSH. L'entrée correspondante dans hosts.allow est :
SSHD: 192.168.1.*
Cette entrée permet à tous les systèmes du réseau 192.168.1.0 de se connecter au système via SSH.
Remarque :vous devez ajouter une ligne vide à la fin de votre fichier hosts.allow pour qu'il fonctionne comme prévu. J'ai lutté avec ça pendant quelques jours et c'était très frustrant.
Le fichier hosts.allow est lu avant le fichier hosts.deny, donc placez toutes les entrées autorisées dans ce fichier avant de placer quoi que ce soit dans le fichier hosts.deny. Vous pouvez placer des entrées DENY dans le fichier hosts.allow mais je préfère garder les deux séparés l'un de l'autre. Je pense que cela me confondrait d'avoir les deux types d'entrées dans le fichier hosts.allow.
Une fois que vous avez apporté vos modifications aux fichiers hosts.allow et host.deny, elles sont actives. Il n'y a pas de démon à redémarrer pour les rendre actifs, ce qui est une autre raison de vous avertir de faire vos entrées avec beaucoup de soin, sauf si vous habitez près de votre centre de données, c'est-à-dire.
Créer les entrées DENY
Après avoir créé toutes vos entrées hosts.allow correspondantes iptables, il est temps de créer les entrées hosts.deny. Comme iptables, les fichiers hosts.allow et hosts.deny sont lus de haut en bas, ajoutez donc l'entrée dite DENY ALL au bas du fichier hosts.deny.
ALL: ALL
Cette entrée simple signifie de refuser tous les protocoles de tous les hôtes. Vous pouvez être plus précis si vous ne souhaitez refuser qu'un seul protocole ou réseau particulier.
SSHD: ALL #Deny SSH access from all networks but allowing other protocols.
ou
ALL: 192.168.1.* #Deny all protocols from the 192.168.1.0 network.
ou
SSHD: 192.168.1.* #Deny SSH access from the 192.168.1.0 network.
Conclusion
Comme vous pouvez le voir à partir de ces exemples et de ceux donnés dans l'article iptables, les deux partagent des similitudes de structure et de comportement. Ils sont tous les deux lus de haut en bas et les entrées ALLOW sont lues avant les entrées DENY. La seule chose à retenir lors de la création d'entrées hosts.allow/deny et d'entrées iptables est qu'elles correspondent les unes aux autres. S'ils sont en conflit, cela augmentera considérablement la complexité de vos efforts de dépannage. À des fins de test, désactivez votre pare-feu et observez le comportement de connectivité de vos fichiers hosts.allow et hosts.deny.
[ Vous voulez en savoir plus sur les réseaux et la sécurité des réseaux ? Consultez la feuille de triche sur le réseau Linux. ]