Question Pourquoi devrais-je pare-feu serveurs?


NOTEZ S'IL VOUS PLAÎT: Je ne suis pas intéressé à en faire une guerre de flammes! Je crois comprendre que de nombreuses personnes ont des idées bien arrêtées sur ce sujet, notamment parce qu’elles ont déployé beaucoup d’efforts dans leurs solutions de pare-feu et parce qu’elles ont été endoctrinées à croire en leur nécessité.

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

Je suppose que je travaille ici depuis trop longtemps, car lorsque je parle de "serveurs", je parle toujours de "services offerts au public" et non de "bases de données de facturation internes secrètes". En tant que telles, toutes les règles que nous aurait avoir dans tous les pare-feu devrait permettre l'accès à l'ensemble de l'Internet. De plus, nos serveurs d'accès public se trouvent tous dans un centre de données dédié séparé de notre bureau.

Quelqu'un d'autre posé une question similaire, et ma réponse a été voté en nombres négatifs. Cela me porte à penser que les votants n'ont pas vraiment compris ma réponse ou que je ne comprends pas suffisamment la sécurité pour faire ce que je fais actuellement.

Voici mon approche de la sécurité du serveur:

  1. Suivez mon système d'exploitation consignes de sécurité  avant connecter 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. Surveiller l'état de ce serveur avec Munin. Et corrigez les énormes problèmes de sécurité 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 pare-feu sur ce serveur, ce devrait être le jeu exact de ports auquel les connexions entrantes devraient être limitées.

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

  6. Protégez le système en utilisant la fonctionnalité de mise à jour de sécurité de mon système d'exploitation.

Ma philosophie (et le fondement de la question) est qu'une sécurité forte basée sur l'hôte supprime la nécessité d'un pare-feu. Selon la philosophie de sécurité globale, une sécurité forte basée sur l'hôte est toujours nécessaire, même si vous avez un pare-feu (voir consignes de sécurité). La raison en est qu'un pare-feu qui transfère des services publics à un serveur permet à un attaquant autant que de ne pas avoir de pare-feu du tout. C’est le service lui-même qui est vulnérable et, comme il est indispensable d’offrir ce service à tout l’Internet, il n’est pas question de restreindre l’accès à ce dernier.

S'il y a sont Les ports disponibles sur le serveur qui n’ont pas besoin d’être accessibles par Internet au complet, puis ce logiciel a dû être arrêté à l’étape 1 et a été vérifié à l’étape 4. Si un attaquant réussit à pénétrer sur le serveur via un logiciel vulnérable et à ouvrir une port eux-mêmes, l'attaquant peut (et fait) tout aussi facilement neutraliser tout pare-feu en établissant une connexion sortante sur un port aléatoire. Le but de la sécurité n'est pas de se défendre après une attaque réussie - cela s'est déjà avéré impossible - mais de garder les attaquants à distance.

Il a été suggéré qu'il y avait d'autres considérations de sécurité en plus des ports ouverts - mais pour moi, cela ressemble à de la défense de sa foi. Toutes les vulnérabilités du système d'exploitation / pile TCP doivent être également vulnérables, qu'il existe ou non un pare-feu - en raison du fait que les ports sont transférés directement à cette pile du système d'exploitation / TCP. De même, faire fonctionner votre pare-feu sur le serveur lui-même plutôt que sur le routeur (ou pire, aux deux endroits) semble ajouter des niveaux de complexité inutiles. Je comprends que la philosophie "la sécurité se fait en couches", mais il arrive un moment où c'est comme construire un toit en empilant X couches de contreplaqué les unes sur les autres, puis en forant un trou à travers chacune d'elles. Une autre couche de contreplaqué ne va pas empêcher les fuites à travers ce trou que vous faites exprès.

Pour être honnête, la seule façon dont un pare-feu peut être utilisé par un pare-feu est d'utiliser des règles dynamiques interdisant toutes les connexions à tous les serveurs d'attaques connus - comme les RBL pour le spam (ce qui, comme par hasard, correspond à peu près à ce que notre serveur de messagerie fait). . Malheureusement, je ne trouve aucun pare-feu qui fasse cela. La meilleure chose à faire est un serveur IDS, mais cela suppose que l’attaquant n’attaque pas en premier vos vrais serveurs et que les attaquants se donnent la peine de sonder tout votre réseau. avant attaquer. En outre, ils sont connus pour produire un grand nombre de faux positifs.


101
2017-11-12 21:11


origine


Et ainsi TOUT le trafic qui passe entre vos serveurs est crypté? - GregD
Aimer. Les règles de pare-feu locales sont presque toujours réservées au vaudou. - unixtippse
Avez-vous des ordinateurs de bureau / employés dans votre réseau? que fais-tu avec eux? - Brandon
Cette question aurait été bien adaptée pour security.stackexchange.com - Olivier Lalonde
@ RouteNpingme: Il semble que je n'ai pas inclus cette friandise dans mon message d'origine. Tous nos serveurs doivent être ouverts au public et résident dans un centre de données dédié. Si votre bureau est votre centre de données, je suppose qu’il serait nécessaire d’installer un pare-feu entre votre réseau de serveur et votre réseau de bureau. Dans ce cas, je parle du réseau de serveurs. Pourquoi un pare-feu est-il accessible à tous? - Ernie


Réponses:


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 applicatives connues.
  3. Vous pouvez bloquer une certaine plage d'adresses IP et / ou un port de manière centralisée plutôt que d'essayer de vous assurer qu'aucun service n'est à l'écoute de ce port sur chaque ordinateur ou de refuser l'accès à l'aide de TCP Wrappers.
  4. Les pare-feu peuvent vous aider si vous devez traiter avec des utilisateurs / administrateurs moins sensibles à la sécurité, car ils fourniraient 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 nécessite une bonne compréhension de la sécurité de la part de tous les administrateurs.
  5. Les journaux de pare-feu fourniraient des journaux centraux et aideraient à détecter les analyses verticales. Les journaux de pare-feu peuvent vous aider à déterminer si un utilisateur / client tente de se connecter périodiquement au même port de tous vos serveurs. Pour ce faire sans pare-feu, il faudrait combiner les journaux de différents serveurs / hôtes pour obtenir une vue centralisée.
  6. Les pare-feu sont également fournis avec des modules anti-spam / anti-virus qui renforcent également la protection.
  7. Sécurité indépendante du système d'exploitation. Selon le système d'exploitation 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 ordinateurs Windows.

Surtout si vous n’avez pas de pare-feu et que le système est compromis, comment le détecteriez-vous? Essayer d'exécuter une commande 'ps', 'netstat', etc. sur un système local ne peut pas être approuvé, car ces fichiers binaires peuvent être remplacés. La protection de 'nmap' depuis un système distant n'est pas garantie, puisqu'un attaquant peut s'assurer que le root-kit n'accepte les connexions qu'à partir de la ou des adresses IP source sélectionnées à des moments choisis.

Les pare-feu matériels aident dans de tels scénarios car il est extrêmement difficile de modifier le système d'exploitation / les fichiers du pare-feu par rapport à un système d'exploitation / des fichiers hôte.

Inconvénients du pare-feu:

  1. Les gens pensent que le pare-feu assurera la sécurité, ne mettra pas à jour régulièrement les systèmes et ne bloquera pas les services indésirables.
  2. Ils coutent. Parfois, les droits de licence annuels doivent être payés. Surtout si le pare-feu comporte des modules anti-virus et anti-spam.
  3. Point unique supplémentaire d'échec. Si tout le trafic passe à travers 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 les coûts est encore amplifié.
  4. Le suivi avec état n’a aucune valeur pour les systèmes ouverts au public acceptant toutes les connexions entrantes.
  5. Les pare-feu avec état constituent un goulet d'étranglement lors d'une attaque DDoS et sont souvent la première chose à échouer, car ils tentent de conserver l'état et d'inspecter toutes les connexions entrantes.
  6. Les pare-feu ne peuvent pas voir le trafic crypté à l'intérieur. Depuis tout le trafic devrait cryptés de bout en bout, la plupart des pare-feu n’ajoutent que peu de valeur face aux serveurs publics. Des clés privées peuvent être attribuées à certains pare-feu de nouvelle génération pour mettre fin à TLS et voir à l'intérieur du trafic. Toutefois, 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 fournisseurs de pare-feu sont souvent assis sur des problèmes connus années sans appliquer de correctifs et appliquer des correctifs à un cluster de pare-feu nécessite généralement des temps d'arrêt pour de nombreux services et connexions sortantes.
  8. Les pare-feu sont loin d'être parfaits, et beaucoup sont notoirement buggés. Les pare-feu ne sont que des logiciels fonctionnant sur un système d'exploitation quelconque, éventuellement avec un ASIC ou un FPGA supplémentaire en plus d'un processeur (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 une complexité et une source supplémentaire d'erreurs difficiles à diagnostiquer à une pile d'applications.

52
2017-11-13 02:36



Above all this if you do not have firewall and system is compromised then how would you detect it? La détection d'intrusion n'est pas le travail du pare-feu. Ce travail est mieux géré par le système HIDS (système de détection d'intrusion sur hôte), indépendant du pare-feu. - Steven Monday
Les serveurs Syslog éliminent le besoin de l'élément 5. Dans le meilleur des cas, il est préférable d'envoyer les journaux de votre pare-feu à un serveur Syslog, au cas où un attaquant parviendrait à compromettre le pare-feu et à supprimer ses journaux. Ensuite, l’attaquant doit compromettre deux systèmes simplement pour supprimer les journaux, et il se peut qu’ils ne soient pas préparés à cela (en particulier avec les attaques automatisées). De même, si tous vos systèmes ont une journalisation centralisée, vous obtenez des informations plus détaillées sur l'attaque que les journaux de pare-feu ne peuvent fournir. - Ernie
Mon point était que depuis que HIDS réside sur l'hôte, nous ne pouvons faire confiance à sa sortie. Par exemple, même si nous utilisons un «tripwire» cryptographiquement sécurisé comme IDS basé sur l'hôte, l'attaquant peut toujours remplacer tous les fichiers binaires de tripwire (twadmin, tripwire, twprint, etc.) par des versions compromises qui ne signaleront jamais l'intrusion. Même si nous essayons de copier des bibliothèques / binaires d'un autre système, il peut exister un processus en cours d'exécution qui surveille ces binaires compromis et les remplace à nouveau par une version endommagée au cas où ils seraient remplacés ou mis à jour. Le pare-feu étant indépendant de l'hôte, il est possible de faire confiance à de tels scénarios. - Saurabh Barjatiya
Cette réponse a été acceptée par rapport à la plus populaire car elle fournit un ensemble plus complet et plus complet de raisons d'utiliser un pare-feu. Et non, d'ailleurs. - Ernie
Les pare-feu d'inspection de paquets avec état ne font PAS partie des serveurs. Ils constituent une énorme responsabilité dans les attaques DDoS et sont généralement la première chose à échouer en cas d'attaque. - rmalayter


TCP Wrappers pourrait être appelé une implémentation de pare-feu basée sur l’hôte; vous filtrez le trafic réseau.

En ce qui concerne l'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 les entrées et sorties de manière 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 familiarisé avec le fonctionnement des pare-feu. Cisco a toute une série de règles à télécharger qui identifient les paquets construits de manière à causer des problèmes particuliers au système d'exploitation. Si vous saisissez Snort et commencez à l'exécuter avec le bon jeu de règles, vous serez également alerté sur ce type de problème. Et bien sûr, Linux iptables peut filtrer les paquets malveillants.

Fondamentalement, un pare-feu est une protection proactive. Plus vous vous éloignez de votre anticipation, plus vous êtes susceptible de vous retrouver dans une situation où vous réagissez à un problème plutôt que de le prévenir. Concentrer votre protection à la frontière, comme avec un pare-feu dédié, facilite la gestion, car vous avez un point d’étouffement central plutôt que de dupliquer les règles partout.

Mais rien n'est nécessairement une solution finale. Une bonne solution de sécurité est généralement multicouche, avec un pare-feu à la frontière, des wrappers TCP sur le périphérique et probablement aussi des règles sur les routeurs internes. Vous devez généralement protéger le réseau contre Internet et protéger les nœuds les uns des autres. Cette approche multicouche ne ressemble pas à percer un trou dans plusieurs feuilles de contreplaqué, mais plutôt à une paire de portes afin qu'un intrus ait deux serrures à casser au lieu d’une seule; c'est ce qu'on appelle un piège à sécurité physique, et la plupart des bâtiments en ont un pour une raison. :)


33
2017-11-12 22:04



De plus, s’ils se faufilent à l’intérieur du bâtiment et ouvrent la porte intérieure de leur ami à l’extérieur, ils doivent également déverrouiller et ouvrir la porte extérieure. (c.-à-d. sans pare-feu externe, une personne qui pénètre dans votre serveur peut l'ouvrir, alors qu'un pare-feu externe bloquerait toujours les ports ouverts de l'extérieur) - Ricket
@Ricket: Peut-être qu'ils pourraient, mais les attaquants modernes ne s'embarrassent pas de ce genre de choses. Votre site devrait présenter un intérêt particulier pour qu'un attaquant fasse autre chose que d'ajouter votre serveur à une ferme zombie. - Ernie
@Ernie - non, il suffit d'exister pour rechercher automatiquement de l'espace libre pour Warez, des bases de données clients, des informations financières, des mots de passe et pour être ajouté à un réseau de bot (ce qui peut être déjà assez grave). Certains administrateurs seront ravis de votre adresse IP. si on dirait que vous hébergez des zombies. - Rory Alsop
TCP Wrappers could be arguably called a host-based firewall implementation +1 pour une bonne réponse. - sjas


(Vous voudrez peut-être lire "La vie sans pare-feu")

Maintenant: qu'en est-il d'un système hérité pour lequel aucun correctif n'est publié? Qu'en est-il de ne pas pouvoir appliquer les correctifs aux machines N au moment voulu, tout en les appliquant dans moins de nœuds du réseau (pare-feu)?

Il ne sert à rien de débattre de l'existence ou des besoins du pare-feu. Ce qui compte vraiment, c'est de mettre en œuvre une politique de sécurité. Pour ce faire, vous utiliserez tous les outils permettant de le mettre en œuvre et vous aiderez à le gérer, le développer et le faire évoluer. Si des pare-feu sont nécessaires pour le faire, c'est bien. S'ils ne sont pas nécessaires, c'est bien aussi. Ce qui compte vraiment, c’est la mise en œuvre efficace et vérifiable de votre politique de sécurité.


15
2017-11-12 21:31



Il h. Je fais fonctionner notre réseau de serveurs depuis 8 ans sans pare-feu. J'aurais pu écrit "La vie sans pare-feu", mais il a fait un travail bien meilleur et gère un réseau beaucoup plus grand que moi, de toute façon. - Ernie
@ Ernie - Je suppose que vous auriez pu avoir de la chance. Comment savez-vous que vous n'avez pas été compromis? Les résultats d'enquêtes médico-légales sur plusieurs de mes clients ont révélé des compromis, parfois remontant à des mois, alors que les assaillants ont trouvé des informations personnelles et financières, des informations sur les clients, des propriétés intellectuelles, des plans commerciaux, etc. Comme Sean l'a dit - faites procéder à un audit de sécurité approprié. - Rory Alsop
En fait, mis à part le fait que notre réseau de serveurs est physiquement séparé de notre réseau de bureau (et qu’il est donc impossible de récupérer des données réellement sensibles, même avec un accès root sur chaque serveur), j’ai pu découvrir chaque compromis 'ai jamais eu depuis que j'ai commencé ici. Je pourrais continuer à parler du spectacle d'horreur qui existait quand j'ai commencé, mais je n'ai pas assez d'espace. :) Autant dire que la plupart des attaques ne sont pas subtiles, et que les plus subtiles sont également découvrables. Oh oui, et la séparation des privilèges de l'utilisateur est votre ami. - Ernie


La plupart de vos explications semblent réfuter le besoin d'un pare-feu, mais je ne vois pas d'inconvénient à en avoir un, à part le peu de temps disponible pour le configurer.

Peu de choses sont une "nécessité" au sens strict du terme. La sécurité consiste davantage à mettre en place tous les blocages possibles. Plus de travail est nécessaire pour pénétrer votre serveur, ce qui réduit les chances de réussir une attaque. Vous voulez faire plus de travail pour pénétrer dans vos machines qu’ailleurs. L'ajout d'un pare-feu fait plus de travail.

Je pense qu'une utilisation clé est la redondance en matière de sécurité. Un autre avantage des pare-feu est que vous pouvez simplement abandonner les tentatives de connexion à un port plutôt que de répondre aux demandes rejetées - cela rendra la cartographie un peu plus gênante pour un attaquant.

Le point le plus important pour moi sur la note 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 nombre de connexions entrantes afin d’atténuer les attaques par le DOS.

"Le but de la sécurité n'est pas de se défendre après une attaque réussie - cela s'est déjà avéré impossible - c'est de garder les attaquants à distance en premier lieu."

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


9
2017-11-12 21:30



Eh bien, vous avez raison, je n'y ai mis aucun contre. Inconvénients: complexité accrue du réseau, point de défaillance unique, interface réseau unique via laquelle la bande passante est goulot d’étranglement. De même, les erreurs administratives commises sur un pare-feu peuvent tuer tout votre réseau. Et les dieux vous interdisent de vous enfermer dans l'intervalle, alors que vous êtes à 20 minutes de la salle des serveurs. - Ernie
Cela peut être purement rhétorique, mais lorsque vous dites: "La sécurité, c’est plus la mise en place de tous les blocages que vous pouvez", je préférerais entendre: "La sécurité, c’est plus le blocage de tout par défaut, et l’ouverture prudente du strict minimum pour fonctionner". - MatthieuP
+1 Un plan de sécurité complet couvre la prévention, la détection et la réaction. - Jim OHalloran


Should I firewall my server? Bonne question. Il semblerait qu’il n’y ait aucun intérêt à gifler un pare-feu sur une pile réseau qui rejette déjà les tentatives de connexion vers tous les ports, à l’exception de la poignée de ports légalement ouverts. S'il existe une vulnérabilité dans le système d'exploitation qui permet à des paquets conçus de manière malveillante de perturber / exploiter un hôte, un pare-feu en cours d'exécution sur ce même hôte empêcher l'exploit? Bien, peut être ...

Et c’est probablement la raison la plus forte d’exécuter un pare-feu sur chaque hôte: un pare-feu pourrait empêcher une vulnérabilité de pile réseau d'être exploitée. Est-ce une raison assez forte? Je ne sais pas, mais je suppose qu'on pourrait dire: "Personne n'a jamais été congédié pour avoir installé un pare-feu."

Une autre raison pour exécuter un pare-feu sur un serveur est de découpler ces deux problèmes par ailleurs fortement corrélés:

  1. Est-ce que j'accepte les connexions depuis et vers quels ports?
  2. Quels services sont 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 pour tcpwrappers et autres) détermine complètement l'ensemble des ports que le serveur aura ouverts et à partir duquel les connexions seront acceptées. Un pare-feu basé sur l'hôte offre à 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 une telle flexibilité n'est pas requise, l'installation d'un pare-feu sur un serveur est alors moins nécessaire.

Sur une note finale, j’ajoute toujours un élément non mentionné dans votre liste de contrôle de sécurité: il s’agit d’un système de détection des intrusions basé sur l’hôte (HIDS), tel que AIDE ou samhain. Un bon HIDS rend extrêmement difficile pour un intrus d'apporter des modifications indésirables au système et de rester non détecté. Je crois que tous les serveurs devraient exécuter une sorte de HIDS.


8
2017-11-12 23:10



+1 pour la mention des systèmes HIDS. - Sam Halicke
Les HIDS sont excellents - Si vous avez l’intention de l’installer et de l’oublier. Et ne jamais ajouter ou supprimer des comptes. Sinon, la grande majorité des journaux HIDS constitueront de longues listes de ce que vous avez fait aujourd'hui et seront rapidement ignorés. - Ernie
Pas de douleur, pas de gain, comme on dit. Sur les serveurs soumis à de nombreuses modifications, il est possible de filtrer le bruit attendu, ce qui vous permet de vous concentrer sur les imprévus. - Steven Monday


Un pare-feu est un outil. Cela ne sécurise pas les choses en soi, mais peut apporter une contribution en tant que couche dans un réseau sécurisé. Cela ne signifie pas que vous en avez besoin, et je m'inquiète certainement pour les personnes qui disent aveuglément «Je dois obtenir un pare-feu» sans comprendre pourquoi elles pensent ainsi et qui ne comprennent pas les forces et les faiblesses des pare-feu.

Il y a beaucoup d'outils dont nous pouvons dire que nous n'avons pas besoin ... Est-il possible de faire fonctionner un ordinateur Windows sans Antivirus? Oui, c’est ... mais c’est une belle couche d’assurance d’en avoir une.

Je dirais la même chose à propos des pare-feu - peu importe ce que vous pouvez dire à leur sujet, ils constituent un bon niveau d'assurance. Ils ne se substituent pas aux correctifs, au verrouillage des machines, à la désactivation de services que vous n'utilisez pas, à la journalisation, etc., mais ils peuvent constituer un complément utile.

Je suggérerais également que l'équation change légèrement selon que vous parlez de placer un pare-feu devant un groupe de serveurs soigneusement entretenus, comme vous semblez l'être, ou d'un réseau local typique avec une combinaison de postes de travail et de serveurs. , certains d’entre eux peuvent avoir des tâches plutôt poilues malgré les efforts et les souhaits de l’équipe informatique.

Une autre chose à considérer est l’avantage de créer une cible manifestement durcie. Sécurité visible, que ce soit des lumières vives, des serrures lourdes et une alarme évidente dans un bâtiment; ou un pare-feu évident sur la plage d'adresses IP d'une entreprise peut dissuader l'intrus occasionnel: il recherche une proie plus facile. Cela ne dissuadera pas l'intrus déterminé qui sait que vous avez les informations qu'il veut et est déterminé à l'obtenir, mais il est toujours utile de dissuader les intrus occasionnels - en particulier si vous savez que tout intrus dont les sondes persistent après la dissuasion doit être pris très au sérieux .


6
2017-11-12 22:25



Ainsi, la raison pour laquelle j'ai dit "serveurs" au lieu de "réseau de bureau"? :) Dans notre cas en particulier, le centre de données et le bureau sont deux entités physiquement distinctes. - Ernie
Je comprends Ernie, mais c’est un point qui mérite d’être souligné ... alors je l’ai fait. - Rob Moir


Toutes les bonnes questions. MAIS - Je suis très surpris que PERFORMANCE n’ait pas été portée à la table.

Pour les frontaux Web très utilisés (en termes de processeur), le pare-feu local dégrade réellement les performances, tout simplement. Essayez un test de charge et voyez. J'ai vu cela des tonnes de fois. La désactivation du pare-feu a augmenté les performances (nombre de requêtes par seconde) de 70% ou plus.

Ce compromis doit être considéré.


5
2017-11-13 22:28



Cela dépend beaucoup des règles de pare-feu en place. Les règles de pare-feu sont exécutées de manière séquentielle sur chaque paquet, vous ne voulez donc pas avoir des centaines de règles à examiner. L'hiver dernier, lorsque nous avons géré un site comportant une publicité sur le superbowl, les règles de pare-feu ne posaient pas de problème, par exemple. Mais je conviens que vous devez comprendre l'impact des règles de pare-feu sur les performances. - Sean Reifschneider


Un pare-feu est une protection supplémentaire. Il protège contre les attaques de pile réseau (c’est-à-dire que votre système d’exploitation serveur est vulnérable aux paquets spécialement conçus qui n’atteignent jamais le niveau de ports), à une intrusion réussie qui se connecte à "phone home" (ou envoie du spam, ), ou une intrusion réussie ouvrant un port de serveur ou, moins détectable, guettant une séquence de cognement de port avant d’ouvrir un port. Certes, les deux derniers ont pour objet de limiter les dommages d’une intrusion plutôt que de les prévenir, mais cela ne signifie pas que c’est inutile. Rappelez-vous que la sécurité n’est pas une proposition du tout ou rien; on adopte une approche en couches, ceinture et bretelles, pour atteindre un niveau de sécurité suffisant pour vos besoins.


4
2017-11-13 12:37



+1 Absolument, la défense en profondeur est la clé. - Jim OHalloran
Je ne vois pas comment je pourrais espérer bloquer le trafic sortant, en particulier lorsque nos clients s’attendent à ce que beaucoup de nos serveurs envoient des messages à des hôtes aléatoires sur Internet (comme dans le cas du spam). "Téléphoner à la maison" consiste simplement à se connecter à un autre hôte aléatoire sur le réseau - et je doute que le fait de bloquer toutes les connexions sortantes, à l'exception de quelques-uns, aidera à quoi que ce soit - c'est-à-dire si vous voulez le faire n'importe quoi sur Internet. Et bloquer quelques ports, c'est un peu comme installer un poste de péage au milieu du désert. - Ernie