110 votes

Pourquoi devrais-je mettre un pare-feu aux serveurs ?

VEUILLEZ NOTER : Je n'ai pas envie d'en faire une guerre de mots ! Je comprends que de nombreuses personnes ont des convictions bien ancrées sur ce sujet, en grande partie parce qu'elles ont investi beaucoup d'efforts dans leurs solutions de pare-feu, et aussi parce qu'elles ont été endoctrinées pour croire en leur nécessité.

Cependant, je cherche des réponses de personnes qui sont experts en matière de sécurité. Je pense qu'il s'agit d'une question importante, et que la réponse ne profitera pas seulement à moi-même et à l'entreprise pour laquelle je travaille. Je fais fonctionner notre réseau de serveurs depuis plusieurs années sans aucun compromis, sans aucun pare-feu. Aucune des compromissions de sécurité que nous ont aurait pu être évité avec un pare-feu.

Je suppose que je travaille ici depuis trop longtemps, car lorsque je parle de "serveurs", j'entends toujours "services offerts au public", et non "bases de données de facturation internes secrètes". En tant que tel, toute règle que nous serait dans un pare-feu devrait permettre l'accès à l'ensemble de l'Internet. De plus, nos serveurs d'accès public sont tous dans un centre de données dédié, séparé de nos bureaux.

Quelqu'un d'autre a posé une question similaire, et ma réponse a été votée en nombre négatif. Cela m'amène à penser que soit les personnes qui ont voté n'ont pas vraiment compris ma réponse, soit je ne comprends pas suffisamment la sécurité pour faire ce que je fais actuellement.

C'est mon approche de la sécurité des serveurs :

  1. Suivez les instructions de mon système d'exploitation directives de sécurité avant en connectant mon serveur à Internet.

  2. Utilisez des wrappers TCP pour limiter l'accès à SSH (et à d'autres services de gestion) à un petit nombre d'adresses IP.

  3. Surveillez l'état de ce serveur avec Munin . Et corriger les problèmes de sécurité flagrants inhérents à Munin-node dans sa configuration par défaut.

  4. Nmap mon nouveau serveur (également avant de connecter mon serveur à Internet). Si je devais mettre un pare-feu sur ce serveur, il s'agirait de l'ensemble exact de ports sur lesquels les connexions entrantes devraient être limitées.

  5. Installez le serveur dans la salle des serveurs et donnez-lui une adresse IP publique.

  6. Assurez la sécurité du système en utilisant la fonction de mise à jour de sécurité de mon système d'exploitation.

Ma philosophie (et la base de la question) est qu'une sécurité forte basée sur l'hôte supprime la nécessité d'un pare-feu. La philosophie générale en matière de sécurité indique qu'une sécurité forte basée sur l'hôte est toujours nécessaire même si vous avez un pare-feu (cf. directives de sécurité ). La raison en est qu'un pare-feu qui transmet des services publics à un serveur permet tout autant à un attaquant qu'aucun pare-feu. C'est le service lui-même qui est vulnérable, et puisque l'offre de ce service à l'ensemble de l'Internet est une condition de son fonctionnement, il n'est pas nécessaire d'en restreindre l'accès.

S'il y a son des ports disponibles sur le serveur qui n'ont pas besoin d'être accédés par l'ensemble de l'Internet, alors ce logiciel a dû être arrêté à l'étape 1, et a été vérifié à l'étape 4. Si un attaquant réussit à s'introduire dans le serveur par le biais d'un logiciel vulnérable et ouvre lui-même un port, il peut (et il le fait) tout aussi facilement déjouer n'importe quel pare-feu en établissant une connexion sortante sur un port aléatoire à la place. Le but de la sécurité n'est pas de se défendre après une attaque réussie - il a déjà été prouvé que c'était impossible - mais d'empêcher les attaquants d'entrer en premier lieu.

Il a été suggéré qu'il y a d'autres considérations de sécurité que les ports ouverts - mais pour moi, cela revient à défendre sa foi. Les vulnérabilités du système d'exploitation/de la pile TCP devraient être les mêmes, qu'il y ait ou non un pare-feu, car les ports sont transmis directement à ce système d'exploitation/cette pile TCP. De même, le fait d'installer votre pare-feu sur le serveur lui-même plutôt que sur le routeur (ou pire, aux deux endroits) semble ajouter des couches de complexité inutiles. Je comprends la philosophie "la sécurité vient en couches", mais il arrive un moment où c'est comme construire un toit en empilant un nombre X de couches de contreplaqué les unes sur les autres, puis en perçant un trou à travers toutes ces couches. Une autre couche de contreplaqué ne va pas arrêter les fuites par ce trou que vous faites exprès.

Pour être honnête, la seule façon dont je vois un pare-feu être utile pour les serveurs est s'il a des règles dynamiques empêchant toutes les connexions à tous les serveurs de la part d'attaquants connus - comme les RBL pour le spam (ce qui, par coïncidence, est à peu près ce que fait notre serveur de messagerie). Malheureusement, je ne trouve aucun pare-feu qui fasse cela. La meilleure solution suivante est un serveur IDS, mais cela suppose que l'attaquant n'attaque pas d'abord vos serveurs réels et qu'il prenne la peine de sonder l'ensemble de votre réseau. avant d'attaque. En outre, ces derniers sont connus pour produire un grand nombre de faux positifs.

54voto

Saurabh Barjatiya Points 4643

Avantages du pare-feu :

  1. Vous pouvez filtrer le trafic sortant.
  2. Les pare-feu de couche 7 (IPS) peuvent protéger contre les vulnérabilités connues des applications.
  3. Vous pouvez bloquer une certaine plage d'adresses IP et/ou un certain port de manière centralisée plutôt que d'essayer de vous assurer qu'aucun service n'écoute sur ce port sur chaque machine individuelle ou de refuser l'accès à l'aide de TCP Wrappers .
  4. Les pare-feu peuvent être utiles si vous avez affaire à des utilisateurs/administrateurs moins sensibilisés à la sécurité, car ils constituent une deuxième ligne de défense. Sans eux, il faut être absolument sûr que les hôtes sont sécurisés, ce qui exige une bonne compréhension de la sécurité de la part de tous les administrateurs.
  5. Les journaux du pare-feu fourniraient des journaux centraux et aideraient à détecter les scans verticaux. Les journaux du pare-feu peuvent aider à déterminer si un utilisateur/client essaie de se connecter au même port de tous vos serveurs de façon périodique. Pour ce faire, sans pare-feu, il faudrait combiner les journaux de divers serveurs/hébergeurs pour obtenir une vue centralisée.
  6. Les pare-feu sont également dotés de modules anti-spam / anti-virus qui renforcent la protection.
  7. Sécurité indépendante du système d'exploitation. En fonction du système d'exploitation de l'hôte, différentes techniques/méthodes sont nécessaires pour sécuriser l'hôte. Par exemple, les wrappers TCP peuvent ne pas être disponibles sur les machines Windows.

Par-dessus tout, si vous n'avez pas de pare-feu et que le système est compromis, comment le détecterez-vous ? Essayer d'exécuter une commande 'ps', 'netstat', etc. sur le système local n'est pas fiable car ces binaires peuvent être remplacés. L'exécution de la commande 'nmap' à partir d'un système distant ne garantit pas la protection car un attaquant peut s'assurer que le root-kit n'accepte les connexions qu'à partir d'une ou plusieurs adresses IP sources sélectionnées à certains moments.

Les pare-feu matériels sont utiles dans de tels scénarios car il est extrêmement difficile de modifier les systèmes d'exploitation et les fichiers du pare-feu par rapport aux systèmes d'exploitation et aux fichiers de l'hôte.

Inconvénients du pare-feu :

  1. Les gens pensent que le pare-feu se charge de la sécurité et ne mettent pas régulièrement à jour les systèmes et n'arrêtent pas les services indésirables.
  2. Ils coûtent. Il faut parfois payer une licence annuelle. Surtout si le pare-feu possède des modules anti-virus et anti-spam.
  3. Point unique de défaillance supplémentaire. Si tout le trafic passe par un pare-feu et que celui-ci tombe en panne, le réseau s'arrête. Nous pouvons avoir des pare-feu redondants, mais le point précédent sur le coût est alors encore amplifié.
  4. Le suivi avec état n'a aucune valeur sur les systèmes ouverts au public qui acceptent toutes les connexions entrantes.
  5. Les pare-feu dynamiques constituent un goulot d'étranglement important lors d'une attaque DDoS et sont souvent les premiers à tomber en panne, car ils tentent de conserver l'état et d'inspecter toutes les connexions entrantes.
  6. Les pare-feu ne peuvent pas voir à l'intérieur du trafic crypté. Puisque tout le trafic devrait être crypté de bout en bout, la plupart des pare-feu n'apportent que peu de valeur ajoutée face aux serveurs publics. Certains pare-feu de nouvelle génération peuvent recevoir des clés privées pour mettre fin à TLS et voir à l'intérieur du trafic, mais cela augmente encore la vulnérabilité du pare-feu aux attaques DDoS et rompt le modèle de sécurité de bout en bout de TLS.
  7. Les systèmes d'exploitation et les applications sont corrigés contre les vulnérabilités beaucoup plus rapidement que les pare-feu. Les vendeurs de pare-feu s'assoient souvent sur les problèmes connus pour années sans Parcheando, et Parcheando un cluster de pare-feu nécessite généralement un temps d'arrêt pour de nombreux services et connexions sortantes.
  8. Les pare-feu sont loin d'être parfaits, et beaucoup d'entre eux sont notoirement bogués. Les pare-feu ne sont que des logiciels fonctionnant sur une certaine forme de système d'exploitation, avec peut-être un ASIC ou un FPGA supplémentaire en plus d'un CPU (généralement lent). Les pare-feu ont des bogues, mais ils semblent fournir peu d'outils pour les résoudre. Par conséquent, les pare-feu ajoutent de la complexité et une source supplémentaire d'erreurs difficiles à diagnostiquer à une pile d'applications.

32voto

dannysauer Points 752

On pourrait dire que les wrappers TCP sont une mise en œuvre de pare-feu basé sur l'hôte ; vous filtrez le trafic réseau.

En ce qui concerne le point sur un attaquant qui établit des connexions sortantes sur un port arbitraire, un pare-feu fournirait également un moyen de contrôler le trafic sortant ; un pare-feu correctement configuré gère l'entrée et la sortie d'une manière qui est appropriée au risque lié au système.

En ce qui concerne le fait que les vulnérabilités TCP ne sont pas atténuées par un pare-feu, vous n'êtes pas familier avec le fonctionnement des pare-feu. Cisco dispose d'un grand nombre de règles à télécharger qui identifient les paquets construits de manière à causer des problèmes à certains systèmes d'exploitation. Si vous prenez Snort et commencez à le faire fonctionner avec le bon ensemble de règles, vous serez également alerté sur ce genre de choses. Et bien sûr, Linux iptables peut filtrer les paquets malveillants.

Fondamentalement, un pare-feu est une protection proactive. Plus on s'éloigne de la proactivité, plus on risque de se retrouver dans une situation où l'on réagit à un problème plutôt que de le prévenir. Concentrer votre protection à la frontière, comme avec un pare-feu dédié, rend les choses plus faciles à gérer car vous avez un point d'étranglement central plutôt que de dupliquer les règles partout.

Mais aucun élément ne constitue nécessairement une solution définitive. Une bonne solution de sécurité est généralement multicouche, c'est-à-dire qu'elle comporte un pare-feu à la frontière, des enveloppes TCP au niveau du périphérique et probablement aussi quelques règles sur les routeurs internes. Vous devez généralement protéger le réseau de l'Internet et protéger les noeuds les uns des autres. Cette approche multicouche n'équivaut pas à percer un trou à travers plusieurs feuilles de contreplaqué, mais plutôt à mettre en place une paire de portes pour qu'un intrus ait deux serrures à briser au lieu d'une seule ; c'est ce qu'on appelle un piège à hommes en sécurité physique, et la plupart des bâtiments en ont un pour une bonne raison :)

14voto

Sean Points 905

(Vous pouvez lire " La vie sans pare-feu ")

Maintenant : Qu'en est-il d'un système existant pour lequel aucun correctif n'est plus publié ? Qu'en est-il de l'impossibilité d'appliquer les correctifs à N machines au moment où vous devez le faire, alors que dans le même temps vous pouvez les appliquer dans moins de nœuds du réseau (pare-feu) ?

Il ne sert à rien de débattre de l'existence ou de la nécessité du pare-feu. Ce qui compte vraiment, c'est que vous devez mettre en œuvre une politique de sécurité. Pour ce faire, vous utiliserez les outils qui la mettront en œuvre et vous aideront à la gérer, à l'étendre et à la faire évoluer. Si les pare-feu sont nécessaires à cette fin, c'est parfait. S'ils ne sont pas nécessaires, ce n'est pas grave non plus. Ce qui compte vraiment, c'est d'avoir une mise en œuvre fonctionnelle et vérifiable de votre politique de sécurité.

9voto

Joshua Enfield Points 3384

La plupart de vos explications semblent réfuter la nécessité d'un pare-feu, mais je ne vois pas d'inconvénient à en avoir un, si ce n'est le peu de temps qu'il faut pour le mettre en place.

Peu de choses sont une "nécessité" au sens strict du terme. La sécurité consiste plutôt à mettre en place tous les blocages possibles. Plus le travail nécessaire pour pénétrer dans votre serveur est important, plus les chances de réussite de l'attaque sont faibles. Vous devez faire en sorte qu'il soit plus difficile de s'introduire dans vos machines qu'ailleurs. L'ajout d'un pare-feu augmente la charge de travail.

Je pense qu'une utilisation clé est la redondance dans la sécurité. Un autre avantage des pare-feu est que vous pouvez simplement abandonner les tentatives de connexion à n'importe quel port plutôt que de répondre aux demandes rejetées - cela rendra le nmapping un peu plus gênant pour un attaquant.

Le plus important pour moi, sur le plan pratique de votre question, est que vous pouvez verrouiller SSH, ICMP et d'autres services internes sur des sous-réseaux locaux, ainsi que limiter le débit des connexions entrantes afin d'atténuer les attaques DOS.

"Le but de la sécurité n'est pas de se défendre après une attaque réussie - il est déjà prouvé que c'est impossible - mais d'empêcher les attaquants d'entrer en premier lieu."

Je ne suis pas d'accord. Limiter les dommages peut être tout aussi important. (dans cet idéal, pourquoi hacher les mots de passe ? ou placer votre logiciel de base de données sur un serveur différent de celui de vos applications web). Je pense que le vieux dicton "Ne mettez pas tous vos œufs dans le même panier" est applicable ici.

8voto

Priyan R Points 687

Should I firewall my server? Bonne question. Il semblerait qu'il y ait peu d'intérêt à ajouter un pare-feu à une pile réseau qui rejette déjà les tentatives de connexion à tous les ports, à l'exception de ceux qui sont légitimement ouverts. S'il existe une vulnérabilité dans le système d'exploitation qui permet à des paquets malicieusement conçus de perturber/exploiter un hôte, est-ce qu'un firewall fonctionnant sur ce même hôte empêcher l'exploit ? Bien, peut-être ...

Et c'est probablement la raison la plus importante d'installer un pare-feu sur chaque hôte : un pare-feu pourrait empêcher l'exploitation d'une vulnérabilité de la pile réseau. Est-ce une raison suffisamment forte ? Je ne sais pas, mais je suppose qu'on pourrait dire : "Personne n'a jamais été licencié pour avoir installé un pare-feu".

Une autre raison d'utiliser un pare-feu sur un serveur est de découpler ces deux préoccupations, par ailleurs fortement corrélées :

  1. D'où, et vers quels ports, dois-je accepter des connexions ?
  2. Quels sont les services en cours d'exécution et à l'écoute des connexions ?

Sans pare-feu, l'ensemble des services en cours d'exécution (ainsi que les configurations de tcpwrappers et autres) déterminent complètement l'ensemble des ports que le serveur aura ouverts, et de qui les connexions seront acceptées. Un pare-feu basé sur l'hôte donne à l'administrateur une flexibilité supplémentaire pour installer et tester de nouveaux services de manière contrôlée avant de les rendre plus largement disponibles. Si cette flexibilité n'est pas nécessaire, il y a moins de raisons d'installer un pare-feu sur un serveur.

Pour terminer, il y a un élément qui n'est pas mentionné dans votre liste de contrôle de sécurité et que j'ajoute toujours, à savoir un système de détection des intrusions basé sur l'hôte (HIDS), tel que AIDE o samhain . Un bon HIDS rend extrêmement difficile pour un intrus d'apporter des modifications indésirables au système et de ne pas être détecté. Je pense que tous les serveurs devraient être équipés d'une sorte de HIDS.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X