Comment choisir une politique de pare-feu efficace pour sécuriser vos serveurs

De Get Docs
Aller à :navigation, rechercher

Introduction

L'utilisation d'un pare-feu consiste autant à prendre des décisions stratégiques intelligentes qu'à apprendre la syntaxe. Les pare-feu comme iptables sont capables d'appliquer des politiques en interprétant les règles définies par l'administrateur. Cependant, en tant qu'administrateur, vous devez savoir quels types de règles ont un sens pour votre infrastructure.

Alors que d'autres guides se concentrent sur les commandes nécessaires pour être opérationnel, dans ce guide, nous discuterons de certaines des décisions que vous devrez prendre lors de la mise en œuvre d'un pare-feu. Ces choix affecteront le comportement de votre pare-feu, le degré de verrouillage de votre serveur et la manière dont il réagira aux diverses conditions susceptibles de se produire de temps à autre. Nous utiliserons iptables comme exemple pour discuter des détails, mais la plupart des décisions réelles seront pertinentes quels que soient les outils utilisés.

Décider d'une politique par défaut

Lors de la construction d'un pare-feu, l'une des décisions fondamentales que vous devez prendre est la stratégie par défaut. Cela détermine ce qui se passe lorsque le trafic ne correspond à aucune autre règle. Par défaut, un pare-feu peut soit accepter tout trafic sans correspondance avec les règles précédentes, soit refuser ce trafic.

Abandon par défaut vs acceptation par défaut

Une politique par défaut « accepter » signifie que tout trafic sans correspondance est autorisé à entrer sur le serveur. Ceci n'est généralement pas conseillé car cela signifie que, effectivement, vous maintiendrez une liste noire. Les listes noires sont difficiles à gérer car vous devez anticiper et bloquer explicitement chaque type de trafic indésirable. Cela peut entraîner des problèmes de maintenance et est généralement sujet aux erreurs, aux mauvaises configurations et aux trous imprévus dans la politique établie.

L'alternative est une politique par défaut de "drop". Cela signifie que tout trafic qui ne correspond pas à une règle explicite ne sera pas autorisé. Cela s'apparente à une ACL de liste blanche. Chaque service doit être explicitement autorisé, ce qui peut sembler une quantité importante de recherche et de travail au premier abord. Cependant, cela signifie que votre politique tend vers la sécurité et que vous savez exactement ce qui est autorisé à recevoir du trafic sur votre serveur.

Fondamentalement, le choix se résume à une tendance à la sécurité par défaut ou à des services accessibles prêts à l'emploi. Bien qu'il puisse être tentant d'implémenter un pare-feu axé sur la disponibilité du service, il est presque toujours préférable de bloquer le trafic, sauf autorisation explicite.

Politique de suppression par défaut vs règle de suppression finale

Le choix ci-dessus d'une politique de suppression par défaut conduit à une autre décision subtile. Avec iptables et d'autres pare-feu similaires, la politique par défaut peut être définie à l'aide de la fonctionnalité de politique intégrée du pare-feu, ou mise en œuvre en ajoutant une règle de suppression fourre-tout à la fin de la liste des règles.

La distinction entre ces deux méthodes réside dans ce qui se passe si les règles de pare-feu sont vidées.

Si la fonction de politique intégrée de votre pare-feu est définie sur "abandonner" et que vos règles de pare-feu sont vidées (réinitialisées), ou si certaines règles correspondantes sont supprimées, vos services deviendront instantanément inaccessibles à distance. C'est souvent une bonne idée lors de la définition d'une politique pour des services non critiques afin que votre serveur ne soit pas exposé à un trafic malveillant si les règles sont supprimées.

L'inconvénient de cette approche est que vos services seront complètement indisponibles pour vos clients jusqu'à ce que vous rétablissiez des règles permissives. Vous pourriez même potentiellement vous verrouiller hors du serveur si vous n'avez pas d'accès local ou hors bande pour contourner le problème (les serveurs DigitalOcean sont accessibles quels que soient les paramètres réseau en utilisant le bouton « Accès à la console » situé dans la section « Accès » partie de la page de votre Droplet dans le panneau de configuration). Si le vidage de votre pare-feu est intentionnel, cela peut être évité en basculant simplement la politique par défaut sur « accepter » juste avant de réinitialiser les règles.

L'alternative à la définition d'une politique de suppression à l'aide de la fonctionnalité de politique intégrée consiste à définir la politique par défaut de votre pare-feu sur « accepter », puis à implémenter une politique de « suppression » avec des règles régulières. Vous pouvez ajouter une règle de pare-feu normale à la fin de votre chaîne qui correspond et refuse tout le trafic restant sans correspondance.

Dans ce cas, si vos règles de pare-feu sont vidées, vos services seront accessibles mais non protégés. Selon vos options d'accès local ou alternatif, cela peut être un mal nécessaire pour vous assurer que vous pouvez réintégrer votre serveur si les règles sont vidées. Si vous décidez d'utiliser cette option, vous devez vous assurer que la règle fourre-tout reste toujours la règle dernière dans votre jeu de règles.

Abandonner ou rejeter le trafic

Il existe plusieurs façons de refuser le passage d'un paquet vers sa destination prévue. Le choix entre ceux-ci a un impact sur la façon dont le client perçoit sa tentative de connexion et sur la rapidité avec laquelle il est capable de déterminer que sa requête ne sera pas servie.

La première façon dont les paquets peuvent être refusés est avec "drop". Drop peut être utilisé comme stratégie par défaut ou comme cible pour les règles de correspondance. Lorsqu'un paquet est abandonné, iptables le jette simplement. Il n'envoie aucune réponse au client essayant de se connecter et ne donne aucune indication qu'il ait jamais reçu les paquets en question. Cela signifie que les clients (légitimes ou non) ne recevront aucune confirmation de la réception de leurs paquets.

Pour les tentatives de connexion TCP, la connexion se bloquera jusqu'à ce que le délai d'expiration soit atteint. Comme UDP est un protocole sans connexion, l'absence de réponse pour les clients est encore plus ambiguë. En fait, ne pas recevoir de retour de paquet dans ce cas est souvent une indication que le paquet a été accepté. Si le client UDP se soucie de la réception de ses paquets, il devra les renvoyer pour essayer de déterminer s'ils ont été acceptés, perdus en transit ou abandonnés. Cela peut augmenter le temps qu'un acteur malveillant devra passer pour obtenir des informations appropriées sur l'état des ports de votre serveur, mais cela pourrait également causer des problèmes avec le trafic légitime.

Une alternative à la suppression du trafic consiste à rejeter explicitement les paquets que vous n'autorisez pas. ICMP, ou Internet Control Message Protocol, est un méta-protocole utilisé sur Internet pour envoyer des messages d'état, de diagnostic et d'erreur entre les hôtes en tant que canal hors bande qui ne repose pas sur les protocoles de communication conventionnels tels que TCP ou UDP. Lorsque vous utilisez la cible "rejeter", le trafic est refusé et un paquet ICMP est renvoyé à l'expéditeur pour l'informer que son trafic a été reçu mais ne sera pas accepté. Le message d'état peut indiquer la raison.

Cela a un certain nombre de conséquences. En supposant que le trafic ICMP est autorisé à circuler vers le client, celui-ci sera immédiatement informé que son trafic est bloqué. Pour les clients légitimes, cela signifie qu'ils peuvent contacter l'administrateur ou vérifier leurs options de connexion pour s'assurer qu'ils accèdent au bon port. Pour les utilisateurs malveillants, cela signifie qu'ils peuvent terminer leurs analyses et cartographier les ports ouverts, fermés et filtrés dans un délai plus court.

Il y a beaucoup à considérer lors de la décision de supprimer ou de rejeter le trafic. Une considération importante est que la plupart du trafic malveillant sera en fait perpétré par des scripts automatisés. Étant donné que les scripts ne sont généralement pas sensibles au facteur temps, l'abandon du trafic illégitime n'aura pas l'effet dissuasif souhaité alors qu'il aura des effets négatifs pour les utilisateurs légitimes. Plus d'informations à ce sujet peuvent être trouvées ici.

Tableau de réponse Drop vs Reject

Le tableau ci-dessous montre comment un serveur protégé par un pare-feu réagira à différentes requêtes en fonction de la politique appliquée au port de destination.

Type de paquet client Commande NMap Politique portuaire Réponse État du port présumé
TCP -sS] -Pn Accepter TCP SYN/ACK Ouvrir
TCP -sS] -Pn Laissez tomber (rien) Filtré
TCP -sS] -Pn Rejeter RÉINITIALISATION TCP Fermé
UDP nmap -sU -Pn Accepter (rien) Ouvert ou filtré
UDP nmap -sU -Pn Laissez tomber (rien) Ouvert ou filtré
UDP nmap -sU -Pn Rejeter Port ICMP inaccessible Fermé

La première colonne indique le type de paquet envoyé par le client. Dans la deuxième colonne, nous avons inclus les commandes nmap qui peuvent être utilisées pour tester chaque scénario. La troisième colonne indique la stratégie de port appliquée au port. La quatrième colonne est la réponse que le serveur renverra et la cinquième colonne est ce que le client peut déduire sur le port en fonction de la réponse qu'il a reçue.

Politiques ICMP

Semblable à la question de savoir s'il faut abandonner ou rejeter le trafic refusé, les avis divergent sur l'acceptation ou non des paquets ICMP destinés à votre serveur.

ICMP est un protocole utilisé pour beaucoup de choses. Il est souvent renvoyé, comme nous l'avons vu plus haut, pour donner des informations sur l'état des requêtes utilisant d'autres protocoles. Peut-être sa fonction la plus reconnue pour envoyer et répondre aux pings réseau pour vérifier la connectivité aux hôtes distants. Il existe cependant de nombreuses autres utilisations d'ICMP qui ne sont pas aussi bien connues, mais qui sont toujours utiles.

Les paquets ICMP sont organisés par "type" puis par "code". Un type spécifie la signification générale du message. Par exemple, Type 3 signifie que la destination était inaccessible. Un code est souvent utilisé pour donner des informations supplémentaires sur un type. Par exemple, ICMP Type 3 Code 3 signifie que le port de destination était indisponible, tandis que ICMP Type 3 Code 0 signifie que le réseau de destination n'a pas pu être atteint.

Types qui peuvent toujours être bloqués

Certains types ICMP sont obsolètes, ils devraient donc probablement être bloqués sans condition. Parmi ceux-ci figurent l'extinction source ICMP (type 4 code 0) et l'hôte alternatif (type 6). Les types 1, 2, 7 et les types 15 et supérieurs sont tous obsolètes, réservés à une utilisation future ou expérimentaux.

Types à bloquer en fonction de la configuration du réseau

Certains types ICMP sont utiles dans certaines configurations réseau, mais doivent être bloqués dans d'autres.

Par exemple, les messages de redirection ICMP (type 5) peuvent être utiles pour mettre en lumière une mauvaise conception du réseau. Une redirection ICMP est envoyée lorsqu'une meilleure route est directement disponible pour le client. Ainsi, si un routeur reçoit un paquet qui devra être acheminé vers un autre hôte sur le même réseau, il envoie un message de redirection ICMP pour dire au client d'envoyer les paquets via l'autre hôte à l'avenir.

Ceci est utile si vous faites confiance à votre réseau local et souhaitez repérer les inefficacités dans vos tables de routage lors de la configuration initiale (réparer vos routes est une meilleure solution à long terme). Cependant, sur un réseau non approuvé, un utilisateur malveillant pourrait potentiellement envoyer des redirections ICMP pour manipuler les tables de routage sur les hôtes.

D'autres types ICMP qui sont utiles dans certains réseaux et potentiellement nuisibles dans d'autres sont les paquets d'annonce de routeur ICMP (type 9) et de sollicitation de routeur (type 10). Les paquets d'annonce et de sollicitation de routeur sont utilisés dans le cadre d'IRDP (ICMP Internet Router Discovery Protocol), un système qui permet aux hôtes, lors du démarrage ou de la connexion à un réseau, de découvrir dynamiquement les routeurs disponibles.

Dans la plupart des cas, il est préférable pour un hôte d'avoir des routes statiques configurées pour les passerelles qu'il utilisera. Ces paquets doivent être acceptés dans les mêmes situations que les paquets de redirection ICMP. En fait, étant donné que l'hôte ne connaîtra pas la route préférée pour le trafic des routes découvertes, les messages de redirection sont souvent nécessaires directement après la découverte. Si vous n'exécutez pas un service qui envoie des paquets de sollicitation de routeur ou modifie vos itinéraires en fonction des paquets de publicité (comme rdisc), vous pouvez bloquer ces paquets en toute sécurité.

Types qu'il est souvent sûr d'autoriser

Les types ICMP qui sont généralement autorisés en toute sécurité sont indiqués ci-dessous, mais vous pouvez les désactiver si vous voulez être très prudent.

  • Type 8 — Requête d'écho : il s'agit de requêtes ping adressées à votre serveur. Il est généralement prudent de les autoriser (le refus de ces paquets ne cache pas votre serveur. Il existe de nombreuses autres façons pour les utilisateurs de savoir si votre hôte est actif), mais vous pouvez les bloquer ou limiter les adresses sources auxquelles vous répondez si vous le souhaitez.
  • Type 13 — Requête d'horodatage : ces paquets peuvent être utilisés par les clients pour collecter des informations sur la latence. Ils peuvent être utilisés dans certaines techniques d'empreinte digitale du système d'exploitation, alors bloquez-les si vous le souhaitez ou limitez la plage d'adresses auxquelles vous répondez.

Les types ci-dessous peuvent généralement être autorisés sans règles explicites en configurant votre pare-feu pour autoriser les réponses aux demandes qu'il a faites (en utilisant le module conntrack pour autoriser le trafic ESTABLISHED et RELATED) .

  • Type 0 — Réponses d'écho : Ce sont des réponses aux demandes d'écho (pings).
  • Type 3 — Destination inaccessible : les paquets légitimes de destination inaccessible sont des réponses aux requêtes créées par votre serveur indiquant que le paquet n'a pas pu être livré.
  • Type 11 — Temps dépassé : Il s'agit d'une erreur de diagnostic renvoyée si un paquet généré par votre serveur est mort avant d'atteindre la destination en raison du dépassement de sa valeur TTL.
  • Type 12 — Problème de paramètre : cela signifie qu'un paquet sortant de votre serveur était malformé.
  • Type 14 — Réponses d'horodatage : il s'agit des réponses aux requêtes d'horodatage générées par votre serveur.

Le blocage de tout le trafic ICMP entrant est toujours recommandé par certains experts en sécurité, mais de nombreuses personnes encouragent désormais les politiques d'acceptation ICMP intelligentes. Les liens ici et ici contiennent plus d'informations.

Limitation de connexion et limitation de débit

Pour certains services et modèles de trafic, vous pouvez autoriser l'accès à condition que le client n'abuse pas de cet accès. Deux façons de limiter l'utilisation des ressources sont la limitation de connexion et la limitation de débit.

Limitation de connexion

La limitation des connexions peut être implémentée à l'aide d'extensions telles que connlimit pour vérifier le nombre de connexions actives ouvertes par un client. Cela peut être utilisé pour limiter le nombre de connexions autorisées en même temps. Si vous décidez d'imposer une limitation de connexion, vous aurez des décisions à prendre quant à son application. La répartition générale des décisions est la suivante :

  • Limitation par adresse, par réseau ou globale ?
  • Faites correspondre et restreignez le trafic pour un service spécifique ou pour le serveur dans son ensemble ?

Les connexions peuvent être limitées hôte par hôte, ou une limite peut être définie pour un segment de réseau en fournissant un préfixe de réseau. Vous pouvez également définir un nombre maximal global de connexions pour un service ou l'ensemble de la machine. Gardez à l'esprit qu'il est possible de les mélanger et de les assortir pour créer des politiques plus complexes afin de contrôler vos numéros de connexion.

Limitation de débit

La limitation de débit vous permet de construire des règles qui régissent le débit ou la fréquence à laquelle le trafic sera accepté par votre serveur. Il existe un certain nombre d'extensions différentes qui peuvent être utilisées pour la limitation de débit, notamment limit, hashlimit et recent. Le choix de l'extension que vous utiliserez dépendra en grande partie de la voie dont vous souhaitez limiter le trafic.

L'extension limit entraînera la correspondance de la règle en question jusqu'à ce que la limite soit atteinte, après quoi d'autres paquets seront supprimés. Si vous définissez une limite comme "5/sec", la règle autorisera 5 paquets à correspondre par seconde, après quoi la règle ne correspondra plus. C'est utile pour définir une limite de débit globale pour un service.

L'extension hashlimit est plus flexible, vous permettant de spécifier certaines des valeurs que iptables hachera pour évaluer une correspondance. Par exemple, il peut examiner l'adresse source, le port source, l'adresse de destination, le port de destination ou une combinaison arbitraire de ces quatre valeurs pour hacher chaque entrée. Il peut limiter par paquets ou octets reçus. Fondamentalement, cela fournit une limitation de débit flexible par client ou par service.

L'extension recent ajoute dynamiquement des adresses IP client à une liste ou vérifie par rapport à une liste existante lorsque la règle correspond. Cela vous permet de répartir votre logique de limitation entre un certain nombre de règles différentes pour des modèles complexes. Il a la capacité de spécifier un nombre de visites et une plage de temps comme les autres limiteurs, mais peut également réinitialiser la plage de temps si du trafic supplémentaire est détecté, forçant ainsi un client à arrêter tout le trafic s'il est limité.

Le choix de l'extension de limitation de débit à utiliser dépend des politiques exactes que vous souhaitez appliquer.

Gestion monolithique vs gestion en chaîne

Toutes les politiques de pare-feu iptables reposent sur l'extension des chaînes intégrées. Pour les pare-feu simples, cela prend souvent la forme de la modification de la politique par défaut des chaînes et de l'ajout de règles. Pour les pare-feu plus complexes, il est souvent judicieux d'étendre le cadre de gestion en créant des chaînes supplémentaires.

Les chaînes créées par l'utilisateur sont intrinsèquement liées à leur chaîne d'appel. Les chaînes créées par l'utilisateur n'ont pas de politique par défaut, donc si un paquet passe par une chaîne créée par l'utilisateur, il retournera à la chaîne d'appel et continuera l'évaluation. Dans cet esprit, les chaînes créées par l'utilisateur sont principalement utiles à des fins d'organisation, pour rendre les conditions de correspondance des règles plus sèches et pour améliorer la lisibilité en divisant les conditions de correspondance.

Si vous vous retrouvez à répéter certains critères de correspondance pour un nombre important de règles, il peut être intéressant de créer à la place une règle de saut avec les critères de correspondance partagés vers une nouvelle chaîne. Dans la nouvelle chaîne, vous pouvez ajouter cet ensemble de règles avec les critères de correspondance partagés supprimés.

Au-delà de la simple organisation, cela peut avoir des effets secondaires bénéfiques. Par exemple, l'utilisation intelligente de chaînes pour des ensembles de règles très similaires signifie que l'ajout de règles au bon endroit peut être plus facile et moins sujet aux erreurs. Il peut également être plus facile d'afficher et de comprendre les parties de la politique qui vous intéressent en limitant par chaîne.

La décision de regrouper toutes vos règles dans l'une des chaînes intégrées ou de créer et d'utiliser des chaînes supplémentaires dépendra en grande partie de la complexité et de la facilité de gestion de votre ensemble de règles.

Conclusion

À présent, vous devriez avoir une assez bonne idée de certaines des décisions que vous devrez prendre lors de la conception des politiques de pare-feu pour vos serveurs. Habituellement, l'investissement en temps impliqué dans les pare-feu dépend fortement de la configuration initiale, ce qui rend la gestion assez simple. Bien que cela puisse prendre du temps, de la réflexion et de l'expérimentation pour trouver une politique qui réponde le mieux à vos besoins, cela vous donnera plus de contrôle sur la sécurité de votre serveur.

Si vous souhaitez en savoir plus sur les pare-feu et iptables en particulier, consultez les articles suivants :

Les guides suivants peuvent vous aider à mettre en œuvre vos politiques. Choisissez le guide qui correspond à votre pare-feu pour commencer :