Introduction
L’utilisation d’un pare-feu concerne autant la prise de décisions de politique intelligente que l’apprentissage de la syntaxe. Les pare-feu tels que iptables sont conçus pour 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 sont pertinents pour votre infrastructure.
Alors que d’autres guides se concentrent sur les commandes nécessaires pour démarrer, dans ce guide, nous discuterons des décisions que vous devrez prendre lors de la mise en place d’un pare-feu. Ces choix auront un impact sur le comportement de votre pare-feu, sur la sécurité de votre serveur et sur la manière dont il réagira à diverses situations. Nous utiliserons iptables comme exemple spécifique, mais la plupart des concepts seront largement applicables.
Choisir une politique par défaut
Lors de la construction d’un pare-feu, l’une des décisions les plus importantes à prendre est la politique par défaut. Cela détermine ce qui se passe lorsque le trafic n’est pas conforme à d’autres règles. Par défaut, un pare-feu peut soit ACCEPTER tout trafic non conforme aux règles précédentes, soit DROP ce trafic.
Politique par défaut de refus par rapport à l’acceptation par défaut
A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.
L’alternative est une politique par défaut de DROP. Cela signifie que tout trafic non conforme à une règle explicite ne sera pas autorisé. Chaque service doit être explicitement autorisé, ce qui peut sembler être une quantité significative de configuration initiale. 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. De plus, presque toutes les politiques préconfigurées suivront cette approche, ce qui signifie que vous pouvez vous appuyer sur les paramètres par défaut existants.
Politique par défaut de refus par rapport à la règle de refus finale
Le choix d’une politique par défaut de refus conduit à une autre décision subtile. Avec iptables et d’autres pare-feu similaires, la politique par défaut peut être définie en utilisant la fonctionnalité de politique intégrée du pare-feu, ou mise en œuvre en ajoutant une règle de refus générale à 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 du pare-feu sont vidées.
Si la fonction de politique intégrée du pare-feu est définie sur DROP et que les règles du pare-feu sont un jour vidées (réinitialisées), ou si certaines règles de correspondance sont supprimées, vos services seront 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.
Le revers 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 vous retrouver bloqué hors du serveur si vous n’avez pas d’accès distant local ou basé sur le web en tant qu’alternative.
L’alternative à la définition d’une politique de refus à l’aide de la fonctionnalité de politique intégrée consiste à définir la politique par défaut de votre pare-feu sur ACCEPT et à mettre en œuvre une politique de DROP 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 non correspondant.
Dans ce cas, si les règles de votre pare-feu sont vidées, vos services seront accessibles mais non protégés. Selon vos options d’accès local ou alternatif, il peut s’agir d’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, assurez-vous que la règle de capture tout reste toujours la dernière règle de votre ensemble de règles.
Abandonner vs Rejeter le trafic
Il existe plusieurs façons de prévenir un paquet de parvenir à sa destination prévue. Le choix entre celles-ci a un impact sur la manière dont le client perçoit sa tentative de connexion et sur la rapidité avec laquelle il est en mesure de déterminer que sa demande ne sera pas traitée.
La première façon dont les paquets peuvent être refusés est avec DROP. Drop peut être utilisé comme politique par défaut ou comme cible pour les règles de correspondance. Lorsqu’un paquet est abandonné, iptables le jette simplement. Il ne renvoie aucune réponse au client essayant de se connecter et ne donne aucune indication qu’il a même 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 (telles que les connexions établies par un navigateur Web), la connexion sera interrompue jusqu’à ce que la limite de temporisation soit atteinte. L’absence de réponse pour les clients UDP est encore plus ambiguë. En fait, ne pas recevoir de paquet UDP en retour 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 que devra passer un acteur malveillant pour obtenir des informations sur l’état des ports de votre serveur, mais cela pourrait également poser des problèmes avec le trafic légitime.
Une alternative à la suppression du trafic est de rejeter explicitement les paquets que vous n’autorisez pas. ICMP, ou protocole de messages de contrôle Internet, est un méta-protocole utilisé dans tout l’internet pour envoyer des messages d’état, de diagnostic et d’erreur entre les hôtes en tant que canal hors bande qui ne dépend pas des protocoles de communication conventionnels tels que TCP ou UDP. Lorsque vous utilisez la cible REJECT au lieu de la cible DROP, 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é. Un message d’état peut également être inclus pour fournir une raison.
Cela a plusieurs conséquences. En supposant que le trafic ICMP soit autorisé à atteindre le client, ce dernier 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 atteignent le bon port. Pour les utilisateurs malveillants, cela signifie qu’ils peuvent terminer leurs analyses et cartographier les ports ouverts, fermés et filtrés en moins de temps.
Il y a beaucoup de choses à prendre en compte lorsqu’il s’agit de décider de supprimer ou de rejeter le trafic. Une considération importante est que la plupart des trafics malveillants sont en fait perpétrés par des scripts automatisés. Comme ces scripts ne sont généralement pas supervisés, le fait de supprimer le trafic illégitime ne les dissuadera pas réellement et aura des effets négatifs pour les utilisateurs légitimes. Plus d’informations sur ce sujet peuvent être trouvées sur le site web de Peter Benie.
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 demandes en fonction de la politique appliquée au port de destination.
| Client Packet Type | NMap Command | Port Policy | Response | Inferred Port State |
|---|---|---|---|---|
| TCP | nmap [-sT | -sS] -Pn <server> | Accept | TCP SYN/ACK | Open |
| TCP | nmap [-sT | -sS] -Pn <server> | Drop | (none) | Filtered |
| TCP | nmap [-sT | -sS] -Pn <server> | Reject | TCP RESET | Closed |
| UDP | nmap -sU -Pn <server> | Accept | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Drop | (none) | Open or Filtered |
| UDP | nmap -sU -Pn <server> | Reject | ICMP Port Unreachable | Closed |
La première colonne indique le type de paquet envoyé par le client. La deuxième colonne contient les commandes nmap qui peuvent être utilisées pour tester chaque scénario. La troisième colonne indique la politique de port appliquée au port. La quatrième colonne est la réponse que le serveur enverra, et la cinquième colonne est ce que le client peut déduire du port en fonction de la réponse reçue.
Politiques ICMP
Tout comme pour décider de rejeter ou de laisser passer le trafic refusé, vous avez la possibilité d’accepter ou de rejeter les paquets ICMP destinés à votre serveur.
L’ICMP est un protocole utilisé pour de nombreuses choses. Comme mentionné, il est souvent renvoyé pour fournir des informations d’état sur des demandes utilisant d’autres protocoles. L’une de ses fonctions les plus populaires est d’envoyer et de répondre aux pings réseau pour vérifier la connectivité avec des hôtes distants. Il existe de nombreuses autres utilisations de l’ICMP moins connues, mais toujours utiles.
Les paquets ICMP sont organisés par « type » et ensuite par « code ». Un type spécifie le sens général du message. Par exemple, le Type 3 signifie que la destination était inaccessible. Un code est souvent utilisé pour fournir des informations supplémentaires sur un type. Par exemple, le Code 3 de Type 3 ICMP signifie que le port de destination était inaccessible, tandis que le Code 0 de Type 3 ICMP signifie que le réseau de destination n’a pas pu être atteint.
Certains types ICMP sont obsolètes, donc ils peuvent être bloqués inconditionnellement. Parmi ceux-ci, on trouve le type 4 code 0 (ICMP source quench) et le type 6 (alternate host). Les types 1, 2, 7, et les types 15 et supérieurs sont tous obsolètes, réservés à une utilisation future ou expérimentale. De nombreux modèles de pare-feu en amont traiteront cela par défaut.
Types à bloquer en fonction de la configuration réseau
Certains types ICMP sont utiles dans certaines configurations réseau, mais devraient ê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 route meilleure est directement disponible pour le client. Ainsi, si un routeur reçoit un paquet qui doit être routé vers un autre hôte sur le même réseau, il envoie un message de redirection ICMP pour indiquer au client d’envoyer les paquets à travers l’autre hôte à l’avenir.
C’est utile si vous faites confiance à votre réseau local et que vous souhaitez repérer les inefficacités dans vos tables de routage lors de la configuration initiale. Sur un réseau non fiable, 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 dangereux dans d’autres sont les paquets de publicité de routeur ICMP (type 9) et les paquets de sollicitation de routeur (type 10). Les paquets de publicité et de sollicitation de routeur sont utilisés dans le cadre de l’IRDP (protocole de découverte de routeur Internet ICMP), un système qui permet aux hôtes, lors de leur démarrage ou de leur connexion à un réseau, de découvrir dynamiquement les routeurs disponibles.
Dans la plupart des cas, il est préférable qu’un hôte ait 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 de toutes les routes découvertes, les messages de redirection sont souvent nécessaires immédiatement après la découverte. Si vous n’exécutez pas de service qui envoie des paquets de sollicitation de routeur ou modifie vos routes en fonction des paquets de publicité (comme rdisc), vous pouvez bloquer en toute sécurité ces paquets.
Types Souvent Sûrs à Autoriser
Les types ICMP qui sont généralement sûrs à autoriser sont ci-dessous, mais vous pouvez vouloir les désactiver si vous souhaitez être particulièrement prudent.
- Type 8 — Demande d’écho : Il s’agit de demandes de ping dirigées vers votre serveur. Il est généralement sûr de les autoriser (refuser ces paquets ne cache pas votre serveur, car il existe de nombreuses autres façons pour les utilisateurs de savoir si votre hôte est disponible), mais vous pouvez les bloquer ou limiter les adresses source auxquelles vous répondez si vous le souhaitez.
- Type 13 — Demande de timestamp : 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 OS, donc vous pouvez les bloquer ou limiter 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 effectuées (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 (ping).
- Type 3 — Destination inaccessible : Les paquets de destination inaccessible légitimes sont des réponses aux demandes créées par votre serveur indiquant que le paquet n’a pas pu être livré.
- Type 11 — Temps écoulé : 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 mal formé.
- Type 14 — Réponses de timestamp : Ce sont les réponses aux requêtes de timestamp générées par votre serveur.
Bloquer tout le trafic ICMP entrant est encore recommandé par certains experts en sécurité, cependant de nombreuses personnes encouragent désormais des politiques intelligentes d’acceptation ICMP. Ces deux threads Stackexchange ont plus d’informations.
Limitation de la Connexion et Limitation du Taux
Pour certains services et modèles de trafic, vous voudrez peut-être autoriser l’accès uniquement tant que le client n’abuse pas de cet accès. Deux façons de contraindre l’utilisation des ressources sont la limitation de la connexion et la limitation du taux.
Limitation de la Connexion
La limitation de la connexion peut être mise en œuvre en utilisant des extensions comme connlimit pour vérifier combien de connexions actives un client a ouvert. Cela peut être utilisé pour limiter le nombre de connexions autorisées en même temps. Si vous décidez d’imposer des limites de connexion, vous devrez prendre certaines décisions:
- Limitez-vous sur une base par adresse, par réseau, ou globale?
- Correspondez-vous et restreignez-vous le trafic pour un service spécifique ou pour le serveur dans son ensemble?
Les connexions peuvent être limitées sur une base hôte par hôte, ou une limite peut être définie pour un segment de réseau en fournissant un préfixe réseau (comme une plage d’adresses IP pour toute une organisation). 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 combiner ces options pour créer des politiques plus complexes afin de contrôler le nombre de connexions.
Limitation du débit
La limitation du débit vous permet de créer des règles qui régissent le débit ou la fréquence à laquelle le trafic sera accepté par votre serveur. Il existe plusieurs extensions de pare-feu différentes qui peuvent être utilisées pour la limitation du débit, notamment limit, hashlimit et recent. Le choix de l’extension à utiliser dépendra largement de la manière dont vous souhaitez limiter le trafic.
L’extension limit fera correspondre la règle en question jusqu’à ce que la limite soit atteinte, après quoi les paquets supplémentaires seront abandonnés. Une limite comme 5/sec permettra à 5 paquets de correspondre par seconde, après quoi la règle ne correspondra plus. C’est utile pour définir une limite globale de débit pour un service. Vous pouvez également déployer un service supplémentaire comme Fail2ban pour bloquer les tentatives de connexion répétées.
L’extension hashlimit est plus flexible, vous permettant de spécifier certaines des valeurs que iptables va hacher pour évaluer une correspondance. Par exemple, elle peut examiner l’adresse source, le port source, l’adresse de destination, le port de destination, ou une combinaison de ces quatre valeurs pour évaluer chaque entrée. Elle peut limiter par paquets ou par octets reçus. Cela permet une limitation de débit flexible par client ou par service.
L’extension recent ajoute dynamiquement les adresses IP des clients à une liste ou vérifie contre une liste existante lorsque la règle correspond. Cela vous permet de répartir votre logique de limitation sur un certain nombre de règles différentes pour des motifs complexes. Elle a la capacité de spécifier un compte de hits et une plage de temps comme les autres limiteurs, mais peut également réinitialiser la plage de temps si un trafic supplémentaire est vu, forçant un client à arrêter tout le trafic s’il est limité.
Gestion monolithique vs basée sur des chaînes
Toute la politique de pare-feu iptables et nftables est essentiellement basée sur l’extension des chaînes intégrées. Pour commencer, cela signifie généralement de changer la politique par défaut pour les chaînes existantes et d’ajouter des règles. Pour des pare-feu plus complexes, il est souvent judicieux d’étendre le cadre de gestion en créant des chaînes supplémentaires.
Si vous vous retrouvez à répéter certains critères de correspondance pour un nombre significatif de règles, il pourrait être utile de créer une règle de saut avec les critères de correspondance partagés vers une nouvelle chaîne. À l’intérieur de la nouvelle chaîne, vous pouvez ajouter cet ensemble de règles avec les critères de correspondance redondants omis.
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 de la complexité de votre ensemble de règles.
Conclusion
Vous devriez maintenant avoir une meilleure compréhension des décisions que vous devrez prendre lors de la conception des politiques de pare-feu pour vos serveurs. Généralement, l’investissement en temps associé aux pare-feu penche fortement vers la configuration initiale. Bien que cela puisse prendre du temps et de l’expérimentation pour élaborer une politique qui répond 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 correspondant à votre pare-feu pour commencer :