Recherche de site Web

Sécurisation de Linux avec des wrappers TCP : un mode d’emploi rapide


L’amélioration de la sécurité d’un système Linux avec des wrappers TCP implique essentiellement l’édition de deux fichiers. Le premier est le fichier hosts.allow, qui permet aux administrateurs de spécifier quels hôtes ou réseaux peuvent accéder au système. L’autre fichier est hosts.deny, qui indique explicitement tous les hôtes ou réseaux qui seront empêchés d’accéder au système. Les fichiers nous permettent également de spécifier quels services doivent être accessibles ou protégés.

Il s’agit d’une approche rudimentaire et simpliste de la sécurisation du système sur le réseau, mais elle n’en est pas moins efficace pour empêcher les hôtes ou les réseaux explicites d’accéder au système, tout en autorisant ceux qui sont sur liste blanche. Dans certains scénarios, il peut s’agir d’un moyen rapide et facile de mettre en œuvre une sécurité réseau de base. Il ajoute également une couche de redondance au-delà du pare-feu du système. Cependant, il convient également d’envisager des techniques plus avancées et modernes, dont nous parlerons ci-dessous.

Dans ce tutoriel, vous allez voir comment sécuriser un système Linux avec des wrappers TCP. Nous allons montrer des exemples de configurations qui peuvent être mises en œuvre afin d’autoriser ou d’empêcher des hôtes ou des réseaux entiers d’accéder à votre système ou à des services spécifiques. De plus, nous passerons en revue les considérations importantes pour les administrateurs Linux qui souhaitent utiliser des wrappers TCP dans le cadre de la ligne de défense de leur sécurité système.

Dans ce tutoriel, vous allez apprendre :

  • Limitations et considérations relatives à l’utilisation des wrappers TCP
  • Comment configurer les règles d’autorisation et de refus pour les wrappers TCP

Les wrappers TCP sont-ils toujours une mesure de sécurité pertinente ?

Avant de configurer les wrappers TCP, tous les utilisateurs doivent être conscients de ses limitations.

AVERTISSEMENT
L’utilisation de wrappers TCP pour le renforcement du système a été largement supprimée par les administrateurs Linux en faveur de l’utilisation du pare-feu par défaut : iptables/nftables, ou l’un des frontaux populaires comme ufw ou firewalld.

Assistance sur les distributions contemporaines

Tout d’abord, certaines distributions Linux modernes ne prennent même plus en charge les wrappers TCP. Donc, avant de vous plonger dans l’utilisation des wrappers TCP, vous devez considérer les systèmes avec lesquels vous travaillez et vérifier le support natif. Consulter la documentation officielle de votre distribution Linux est un bon point de départ. Sinon, la vérification de l’existence des fichiers hosts.allow et hosts.deny sur votre système vous aidera à confirmer si cette configuration est prise en charge ou non.

Voici le résultat sur notre système de test Arch Linux, où l’utilisation de wrappers TCP n’est plus prise en charge :


ls -l /etc/hosts.allow
ls: cannot access '/etc/hosts.allow': No such file or directory

Et voici le résultat sur notre système de test Ubuntu, où l’utilisation des wrappers TCP est toujours supportée :


ls -l /etc/hosts.allow
-rw-r--r-- 1 root root 411 Feb 22  2023 /etc/hosts.allow

Alternatives au pare-feu

La mise en œuvre de wrappers TCP était une pratique de sécurité ordinaire il y a 20 ans, et même courante avant cela. De nos jours, la plupart des administrateurs Linux choisiront d’utiliser le pare-feu iptables intégré ou l’un de ses frontaux plus simples mentionnés précédemment.

Netfilter (le système sur lequel s’appuient iptables et nftables) a été intégré au noyau Linux depuis 2001, et son introduction et son adoption généralisée ont par la suite rendu les anciennes méthodes de renforcement du réseau comme les wrappers TCP non pertinentes pour de nombreux utilisateurs.

Les raisons pour lesquelles vous pouvez toujours vouloir utiliser des wrappers TCP sont les suivantes :

  • Une deuxième ligne de défense qui réitère les règles actuelles du pare-feu : si le pare-feu est désactivé ou mal configuré, l’idée est que les wrappers TCP bloquent ou autorisent toujours activement les connexions que vous devez configurer
  • Si vous souhaitez simplement mettre en œuvre des règles réseau simples (par exemple, sur un système de test) et que vous ne voulez pas jouer avec le pare-feu
  • Si vous avez besoin de contrôler l’accès réseau aux applications, les wrappers TCP peuvent bloquer ou autoriser les connexions à des services spécifiques (pensez à vsftpd ou sshd) plutôt qu’aux protocoles réseau
  • Les règles de pare-feu et la syntaxe requise pour les programmer peuvent s’avérer assez complexes, surtout par rapport à la simplicité et à la simplicité des wrappers TCP

Raisons pour lesquelles vous devriez utiliser un pare-feu en plus des wrappers TCP, ou pourquoi de nombreux administrateurs système opteront simplement pour un pare-feu au lieu d’utiliser des wrappers TCP :

  • Le pare-feu permet une inspection dynamique des paquets, ce qui permet aux administrateurs d’élaborer des règles complexes et granulaires pour contrôler le flux de paquets en fonction de diverses conditions
  • Les wrappers TCP ne sont pas pris en charge sur tous les systèmes Linux
  • Un pare-feu prend en charge la journalisation et l’analyse du trafic en temps réel, ce qui vous permet de voir exactement ce qui est refusé ou autorisé par votre système
  • Le pare-feu système peut autoriser ou refuser le trafic en fonction du protocole (tel que FTP ou SSH), contrairement aux wrappers TCP qui ne peuvent autoriser ou refuser que le trafic provenant d’hôtes, de réseaux ou de services spécifiques
  • Le pare-feu prend en charge les chaînes afin de créer des règles pour l’entrée (trafic entrant), la sortie (trafic sortant) et le transfert (trafic entrant qui est redirigé vers un autre endroit)

Il y a aussi une pléthore d’autres raisons, mais celles-ci sont parmi les plus convaincantes. Comme vous pouvez le constater, les raisons d’utiliser un pare-feu l’emportent sur les raisons d’utiliser des wrappers TCP.

Cela n’a pas pour but de vous décourager d’utiliser des wrappers TCP. Cette explication n’a pour but que de vous donner les informations nécessaires pour comprendre les implications de l’utilisation d’enveloppes TCP à la place d’une solution plus largement acceptée et moderne.

Configuration des wrappers TCP

Voyons maintenant comment nous pouvons configurer certaines règles à l’aide d’enveloppes TCP. Pour appliquer une configuration, vous devez ouvrir les fichiers /etc/hosts.allow et/ou /etc/hosts.deden, selon que vous essayez d’autoriser ou de refuser le trafic, respectivement. Cela doit être fait avec les permissions root, et peut être avec n’importe quel éditeur de texte (nano, vim, etc.) de votre choix.

Règles de refus

Tout d’abord, voyons quelques règles de refus que nous pouvons configurer dans les wrappers TCP :

  1. Une pratique courante consiste à configurer une seule règle à l’intérieur du fichier hosts.deny, qui consiste simplement à refuser le trafic entrant de tous les hôtes vers tous les services :

    
    ALL: ALL
    

    Cette règle en elle-même ne nous servirait pas à grand-chose puisqu’elle signifierait qu’aucun de nos services n’est accessible sur le réseau. Mais, l’idée derrière cette règle est que nous pouvons procéder à l’ajout de tous les hôtes auxquels nous voulons accorder l’accès à l’intérieur du fichier hosts.allow. Une telle configuration ne fonctionnera que si nous disposons d’une liste connue de noms d’hôtes, de réseaux ou d’adresses IP auxquels nous souhaitons accorder l’accès. Si nous ne pouvons pas prédire les adresses réseau des systèmes qui ont besoin d’accès, cette règle ne sera pas réalisable.

  2. La règle suivante refuserait TOUT le trafic vers SSH – plus précisément sshd, le démon du serveur SSH :

    
    sshd: ALL
    

    Gardez à l’esprit qu’après avoir configuré cette règle, nous pouvons toujours aller dans le fichier hosts.allow et spécifier les hôtes qui doivent avoir accès à SSH.

  3. Voyons comment nous pouvons refuser l’accès à un hôte spécifique. Dans cet exemple, nous refusons l’accès à l’hôte 192.168.1.100 :

    
    ALL: 192.168.1.100
    

    Ou refuser à un service spécifique :

    
    sshd: 192.168.1.100
    
  4. Voici comment nous pouvons refuser le trafic vers un réseau entier. Dans cet exemple, nous allons refuser le trafic vers le réseau 192.168.1.0/24 pour le service sshd :

    
    sshd: 192.168.1.0/255.255.255.0
    
  5. Nous pouvons également utiliser la syntaxe ALL EXCEPT pour refuser le trafic de tous les hôtes et réseaux à l’exception de ceux que nous spécifions. Voici un exemple où nous autorisons deux réseaux différents (192.168.1.0/24 et linuxconfig.org) mais refusons le trafic provenant de partout ailleurs :

    
    ALL: 192.168.1.0/255.255.255.0, .linuxconfig.org
    

Autoriser les règles

La syntaxe des règles d’autorisation sera la même que celle des règles de refus. En règle générale, mais pas toujours, les règles de refus sont configurées pour bloquer la plupart du trafic entrant, les règles d’autorisation étant ensuite configurées en tant qu’exceptions.

  1. Plutôt que de bloquer toutes les connexions dans hosts.deny et d’utiliser hosts.allow pour configurer les exceptions, nous pouvons également utiliser la configuration opposée en autorisant tout le trafic dans hosts.allow et en refusant ensuite des hôtes spécifiques dans hosts.deny. Voici comment autoriser tout le trafic vers un certain service tel que sshd :

    
    sshd: ALL
    
  2. Nous pouvons utiliser la syntaxe ALL EXCEPT pour autoriser tout le monde, à l’exception des hôtes ou des réseaux que nous voulons explicitement refuser :

    
    sshd: ALL .linuxconfig.org EXCEPT prod.linuxconfig.org
    

Pour obtenir la configuration idéale, vous devrez configurer les deux fichiers pour construire votre liste d’autorisation et de refus. Pour des configurations simples, cela s’avère facile à faire. Une fois que vous avez besoin d’une configuration plus avancée, il est probablement plus difficile de conserver les règles dans deux fichiers distincts que d’utiliser le pare-feu système intégré.

Réflexions finales

Dans ce tutoriel, nous avons vu comment sécuriser un système Linux à l’aide de wrappers TCP. Cela impliquait de modifier les fichiers hosts.allow et hosts.deny afin qu’ils fonctionnent conjointement pour autoriser et refuser une liste d’hôtes et de réseaux que nous spécifions. Nous avons également abordé les limitations et les considérations que tout administrateur Linux devrait prendre en compte lorsqu’il travaille avec des wrappers TCP. Lorsqu’il s’agit d’autoriser ou de refuser le trafic sur la couche d’application (couche 7 en mode OSI), les wrappers TCP sont une méthode simple et rapide, en supposant que votre distribution Linux les prenne en charge.

Articles connexes: