VEUILLEZ NOTER: 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 des experts en sé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 avons eus n’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 tel, toutes les règles que nous aurions dans tous les pare-feu devraient 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 a posé une question similaire et ma réponse a été votée 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 les consignes de sécurité de mon système d'exploitation avant de 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. Surveillez 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 l'ensemble des ports exacts 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 disposez d'un pare-feu (voir les 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 existe des ports disponibles sur le serveur auxquels il n'est pas nécessaire d'accéder via Internet, il est nécessaire d'arrêter ce logiciel à l'étape 1 et de le vérifier à l'étape 4. Si un attaquant réussissait à pénétrer sur le serveur avec un logiciel vulnérable et ouvrir un port eux-mêmes, l'attaquant peut (et fait) tout aussi facilement contourner un 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 en premier lieu.

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 / de la pile TCP doivent être également vulnérables, qu'il existe ou non un pare-feu - du fait que les ports sont transférés directement à cette pile du système d'exploitation / TCP. De même, exécuter 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 la philosophie "la sécurité se compose de couches", mais à un moment donné, c’est comme construire un toit en empilant un nombre X de couches de contreplaqué superposées, puis en forant un trou. Une autre couche de contreplaqué ne va pas empêcher les fuites à travers ce trou

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 fait notre serveur de messagerie). . 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 d’ attaquer. En outre, ils sont connus pour produire un grand nombre de faux positifs.

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 port de manière centralisée plutôt que d'essayer de vous assurer qu'aucun service n'écoute 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 sensibilisés à 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é par 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.

Avant tout, 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 les systèmes d'exploitation / fichiers de pare-feu par rapport aux systèmes d'exploitation / fichiers hôtes.

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. Étant donné que tout le trafic doit être chiffré de bout en bout, la plupart des pare-feu n’ajoutent que peu de valeur devant les 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 sensibilité du pare-feu aux attaques DDoS et casse 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 restent souvent assis sur des problèmes connus pendant des années sans appliquer de correctifs. Corriger 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.

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 au lieu 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, où vous avez un pare-feu à la frontière, des wrappers TCP sur le périphérique et probablement quelques règles sur les routeurs internes. Vous devez généralement protéger le réseau d’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 à hommes en sécurité physique, et la plupart des bâtiments en ont un pour une raison. :)

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

Maintenant: qu'en est-il d'un système existant 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é.

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 sur 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 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. (sous 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.

Should I firewall my server?Bonne question. Il semblerait qu'il ne sert à rien de gifler un pare-feu au-dessus d'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 / d'exploiter un hôte, un pare-feu exécuté sur ce même hôte empêcherait-il l'exploit? Eh bien, peut - être ...

Et c'est probablement la raison la plus forte pour exécuter un pare-feu sur chaque hôte: Un pare - feu peut empêcher l'exploitation d'une vulnérabilité de pile réseau. 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é: 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.

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 quelque peu 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. 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 décourager l'intrus occasionnel: il va rechercher 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 particulièrement au sérieux. .

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é.

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 autre chose du genre). ), 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.

Je ne suis en aucun cas un expert en sécurité, mais il semble que vous ayez un pare-feu. Il semble que vous ayez intégré certaines des fonctionnalités essentielles d’un pare-feu à vos règles et procédures. Non, vous n'avez pas besoin de pare-feu si vous voulez faire vous-même le travail de pare-feu. Pour ma part, je préférerais faire de mon mieux pour assurer la sécurité, mais placer un pare-feu au-dessus de mon épaule, mais lorsque vous pouvez faire tout ce que le pare-feu fait, il commence à perdre de sa pertinence.

Un pare-feu n'est certainement pas nécessaire pour les petites installations. Si vous avez un ou deux serveurs, les pare-feu logiciels sont maintenables. Cela dit, nous ne fonctionnons pas sans pare-feu dédiés, et je maintiens cette philosophie pour plusieurs raisons:

Séparation des rôles

Les serveurs sont destinés aux applications. Les pare-feu sont destinés à l'inspection, au filtrage et aux stratégies de paquets. Un serveur Web devrait se soucier de servir des pages Web, et c'est tout. Mettre les deux rôles dans un seul appareil revient à demander à votre comptable d’être également votre gardien de sécurité.

Le logiciel est une cible mouvante

Le logiciel sur l'hôte change constamment. Les applications peuvent créer leurs propres exceptions de pare-feu. Le système d'exploitation est mis à jour et corrigé. Les serveurs constituent une zone "admin" à fort trafic et vos stratégies de pare-feu / de sécurité sont souvent beaucoup plus importantes pour la sécurité que les configurations de vos applications. Dans un environnement Windows, supposons que quelqu'un commette une erreur au niveau de la stratégie de groupe et désactive le pare-feu Windows sur les ordinateurs de bureau, sans savoir qu'il sera appliqué aux serveurs. Vous êtes grand ouvert en quelques clics.

En ce qui concerne les mises à jour, les mises à jour du micrologiciel du pare-feu sont généralement publiées une ou deux fois par an, tandis que les mises à jour du système d'exploitation et des services constituent un flux constant.

Services / politiques / règles réutilisables, facilité de gestion

Si je configure un service / politique appelé "serveur Web" une fois (par exemple, TCP 80 et TCP 443), et que je l'applique au "groupe de serveurs Web" au niveau du pare-feu, cela est beaucoup plus efficace (quelques modifications de configuration) et exponentiellement moins sujet aux erreurs humaines que la configuration de services de pare-feu sur 10 boîtiers et l’ouverture de 2 ports x 10 fois. Lorsque cette politique doit changer, c'est 1 changement contre 10.

Je peux toujours gérer un pare-feu pendant une attaque ou après une compromission

Supposons que mon serveur d'applications avec pare-feu + basé sur l'hôte soit attaqué et que le processeur ne soit plus sur la carte. Pour même commencer à comprendre ce qui se passe, je suis à la merci de mon chargement, qui est inférieur à celui de l'attaquant.

Expérience réelle - une fois, j'ai gâché une règle de pare-feu (laissé des ports sur ANY au lieu d'un serveur spécifique et le serveur avait un service vulnérable), et l'attaquant avait en fait une session de bureau à distance en direct. À chaque fois que je commençais à obtenir une session, l'attaquant allait tuer / déconnecter ma session. Si ce n’était pas pour pouvoir arrêter cette attaque à partir d’un pare-feu indépendant, cela aurait pu être bien pire.

Surveillance indépendante

La connexion à des unités de pare-feu dédiées est généralement bien supérieure aux pare-feu logiciels basés sur l’hôte. Certaines sont suffisamment bonnes pour que vous n'ayez même pas besoin d'un logiciel de surveillance externe SNMP / NetFlow pour obtenir une image précise.

Conservation IPv4

Il n’ya aucune raison d’avoir deux adresses IP, l’une pour le Web et l’autre pour le courrier. Conservez les services sur des boîtes séparées et dirigez les ports de manière appropriée via le périphérique conçu à cet effet.

Blockquote Eh bien, vous avez raison, je n'y ai mis aucun inconvénient. 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.

Premièrement, ajouter au plus un saut supplémentaire routé sur votre réseau n’est pas complexe. Deuxièmement, aucune solution de pare-feu mise en œuvre avec un seul point de défaillance n’est totalement inutile. Tout comme vous mettez en cluster votre serveur ou vos services importants et utilisez des NIC liés, vous mettez en place des pare-feu hautement disponibles. Ne pas le faire, ou ne pas reconnaître et savoir que vous le feriez, est très myope. Le simple fait de déclarer qu’il existe une seule interface ne crée pas automatiquement un goulot d’étranglement. Cette assertion montre que vous ne savez pas comment planifier et déployer correctement un pare-feu conçu pour gérer le trafic qui transiterait sur votre réseau. Vous avez raison de dire qu'une erreur de stratégie peut nuire à l'ensemble de votre réseau, mais je dirais que le maintien de stratégies individuelles sur tous vos serveurs est beaucoup plus sujet aux erreurs qu'un seul endroit.

Pour ce qui est de l’argument selon lequel vous suivez les correctifs de sécurité et suivez les guides de sécurité; c'est un argument fragile au mieux. En règle générale, les correctifs de sécurité ne sont disponibles qu'après la découverte d'une vulnérabilité. Cela signifie que pendant tout le temps que vous utilisez des serveurs adressables publiquement, ils sont vulnérables jusqu'à ce qu'ils soient corrigés. Comme d'autres l'ont souligné, les systèmes IPS peuvent aider à prévenir les compromissions de ces vulnérabilités.

Si vous pensez que vos systèmes sont aussi sûrs que possible, c'est une bonne confiance. Cependant, je vous recommanderais de réaliser un audit de sécurité professionnel sur votre réseau. Cela peut simplement vous ouvrir les yeux.

En général, la sécurité est une chose d'oignon, comme déjà mentionné. Il y a des raisons aux pare-feu, et ce ne sont pas tous les autres lemmings qui sont des idiots stupides.

Cette réponse vient, car la recherche de 'fail2ban' sur cette page ne m'a donné aucun résultat. Donc, si je double un autre contenu, supporte-moi. Et excusez-moi, si je peste un peu, je fournis une expérience simple car cela pourrait être utile pour les autres. :)

Considérations de mise en réseau, locales ou externes

Ceci est plutôt spécifique à Linux et se concentre sur le pare-feu basé sur l'hôte, ce qui est généralement le cas d'utilisation. Le pare-feu externe va de pair avec une structure de réseau appropriée et d'autres considérations de sécurité entrent généralement dans celle-ci. Soit vous savez ce qui est impliqué ici, alors vous n'aurez probablement pas besoin de cet affichage. Ou vous ne le faites pas, alors lisez simplement.

L'exécution locale et externe de pare-feu peut sembler contre-intuitive et constituer un double travail. Mais cela donne aussi la possibilité de tourner les règles sur les règles externes, sans compromettre la sécurité de tous les autres hôtes. Le besoin pourrait découler soit du débogage, soit du fait que quelqu'un vient de faire la poire. Un autre cas d'utilisation apparaîtra dans la section «pare-feu global adaptatif», pour laquelle vous aurez également besoin de pare-feu globaux et locaux.

Coût et disponibilité et la même histoire tout le temps:

Le pare-feu n'est qu'un aspect d'un système sécurisé adéquat. N'installez pas de pare-feu car cela «coûte» de l'argent, introduit un SPOF ou autre chose qui n'est que connerie, excusez-moi mon français ici. Il suffit de configurer un cluster. Oh, mais que se passe-t-il si la cellule d'incendie est en panne? Configurez ensuite votre cluster sur deux ou plusieurs compartiments coupe-feu.

Mais que se passe-t-il si l'ensemble du centre de données est inaccessible, car les deux transporteurs externes sont hors service (l'excavatrice a tué votre fibre)? Il suffit alors de créer votre cluster couvrant plusieurs centres de données.

C'est cher? Les clusters sont trop complexes? Eh bien, la paranoïa doit être payée.

Se plaindre au sujet des SPOF, mais ne pas vouloir payer plus d'argent ou créer des configurations un peu plus complexes est un cas évident de double norme ou de simple portefeuille, de la part de la société ou du client.

Ce schéma s’applique à TOUTES ces discussions, quel que soit le service choisi. Peu importe s’il s’agit d’une passerelle VPN, d’un Cisco ASA utilisé uniquement pour le pare-feu, d’une base de données MySQL ou PostgreSQL, d’un système de système virtuel ou matériel serveur, d’un backend de stockage, de commutateurs / routeurs,…

Vous devriez maintenant avoir l'idée.

Pourquoi s'embêter avec le pare-feu?

En théorie, votre raisonnement est sain. (Seuls les services en cours peuvent être exploités.)

Mais ce n'est que la moitié de la vérité. Le pare-feu, en particulier le pare-feu dynamique, peut faire beaucoup plus pour vous. Les pare-feu sans état ne sont importants que si vous rencontrez des problèmes de performances similaires à ceux déjà mentionnés.

Contrôle d'accès simple, central et discret

Vous avez mentionné les wrappers TCP qui implémentent fondamentalement les mêmes fonctionnalités pour sécuriser vos fichiers. Par souci d'argumentation, supposons que quelqu'un ne sache pas tcpdet aime utiliser une souris? fwbuilderpourrait venir à l'esprit.

Vous devriez avoir activé l'activation de l'accès complet à votre réseau de gestion. C'est l'un des premiers cas d'utilisation de votre pare-feu basé sur l'hôte.

Qu'en est-il d'une configuration multi-serveur, où la base de données s'exécute ailleurs et où vous ne pouvez pas mettre les deux / toutes les machines dans un sous-réseau partagé (privé) pour une raison quelconque? Utilisez le pare-feu pour autoriser l'accès MySQL sur le port 3306 uniquement pour l'adresse IP donnée de l'autre serveur, c'est simple.

Et cela fonctionne également parfaitement pour UDP. Ou quelque protocole que ce soit. Les pare-feu peuvent être si flexibles. ;)

Atténuation de Portscan

En outre, avec le pare-feu, les scans de port généraux peuvent être détectés et atténués car le nombre de connexions par période peut être surveillé via le noyau et sa pile de mise en réseau, et le pare-feu peut agir en conséquence.

Des paquets non valides ou obscurs peuvent également être traités avant qu’ils n’atteignent votre application.

Limitation du trafic sortant

Filtrer le trafic sortant est généralement pénible. Mais cela peut être un must, selon le contrat.

Statistiques

Une autre chose qu'un pare-feu peut vous donner, ce sont les statistiques. (Pensez watch -n1 -d iptables -vnxL INPUTà avoir ajouté quelques règles pour les adresses IP spéciales juste en haut pour voir si les paquets passent.)

Vous pouvez voir en plein jour si les choses fonctionnent ou non. Ce qui est TRÈS utile lorsque vous dépannez des connexions et que vous pouvez dire à votre correspondant au téléphone que vous ne recevez pas de paquets, sans avoir à recourir à la conversation tcpdump. Le réseautage est amusant, la plupart des gens savent maintenant ce qu’ils font, et souvent c’est trop simplement de simples erreurs de routage. Bon sang, même si je ne sais pas toujours ce que je fais. Bien que j’ai travaillé avec des dizaines de systèmes et d’applications complexes, souvent avec la construction de tunnels également.

IDS / IPS

Le pare-feu Layer7 est généralement de l'huile de serpent (IPS / IDS), s'il n'est pas utilisé correctement et mis à jour régulièrement. De plus, les licences sont sacrément chères, alors je vous en procurerais une si vous n'avez pas vraiment besoin de tout ce que l'argent peut vous acheter.

Masquer

Facile, essayez ceci avec vos emballages. :RÉ

Transfert de port local

Voir masquerading.

Sécurisation des canaux d'accès par mot de passe avec des adresses IP dynamiques

Qu'en est-il si les clients ont des adresses IP dynamiques et qu'aucune configuration VPN n'est déployée? Ou d'autres approches dynamiques au pare-feu? Ceci est déjà fait allusion dans la question, et voici un cas d'utilisation pour le Malheureusement, je ne trouve aucun pare-feu qui le fasse. partie.

Après avoir désactivé l'accès au compte root via un mot de passe, c'est indispensable. Même si l'accès est limité à certaines adresses IP.

En outre, il est très utile de toujours disposer d'un autre compte blanko avec un identifiant par mot de passe en cas de perte des clés ssh ou d'échec du déploiement, en cas de problème grave (un utilisateur dispose d'un accès administratif à la machine et «des événements se sont produits»?). C’est la même idée pour l’accès au réseau que le fait d’avoir un mode mono-utilisateur sous Linux ou d’utiliser init=/bin/bashvia grubpour un accès local vraiment très mauvais et qu’on ne peut pas utiliser un disque en direct pour une raison quelconque. Ne riez pas, il existe des produits de virtualisation interdisant cela. Même si la fonctionnalité existe, que se passe-t-il si une version logicielle obsolète est exécutée sans la fonctionnalité?

Quoi qu’il en soit, même si vous exécutez votre démon ssh sur un port ésotérique et non sur 22, si vous n’avez pas implémenté des fonctionnalités telles que la détection de port (pour ouvrir même un autre port et atténuer ainsi les scans de ports, devenant trop impraticable), les analyses de ports détecteront votre service éventuellement.

Généralement, vous configurez également tous les serveurs avec la même configuration, avec les mêmes ports et services, pour des raisons d'efficacité. Vous ne pouvez pas configurer ssh sur un port différent sur chaque machine. De plus, vous ne pouvez pas le changer sur toutes les machines à chaque fois que vous considérez qu'il s'agit d'informations «publiques», car elles le sont déjà après une analyse. La question d' nmapêtre légal ou non n'est pas un problème lorsque vous disposez d'une connexion Wi-Fi piratée.

Si ce compte n'est pas nommé 'root', il est possible que les utilisateurs ne puissent pas deviner le nom du compte d'utilisateur de votre 'porte dérobée'. Mais ils sauront s'ils obtiennent un autre serveur de votre société ou s'ils achètent simplement un espace Web et qu'ils jetteront un coup d'oeil sans chroot /etc/passwd.

Pour des illustrations purement théoriques maintenant, ils pourraient utiliser un site Web piraté pour accéder à votre serveur et voir comment les choses se passent habituellement chez vous. Vos outils de recherche hack pourraient ne pas fonctionner 24/7 ( en général , ils font la nuit pour des raisons de performance de disque pour les scans du système de fichiers?) Et vos scanners de virus ne sont pas mis à jour le deuxième un nouveau zéro jour voit la lumière du jour, de sorte qu'il ne détectez pas ces événements à la fois, et sans autres mesures de protection, vous pourriez même ne jamais savoir ce qui s’est passé. Pour revenir à la réalité, si quelqu'un a accès à des exploits du jour zéro, il est fort probable qu'il ne ciblera pas vos serveurs de toute façon, car ceux-ci sont tout simplement coûteux. Ceci est juste pour illustrer qu'il y a toujours un moyen d'entrer dans un système si le «besoin» se présente.

Mais encore une fois sur le sujet, n'utilisez pas de compte avec un mot de passe supplémentaire, et ne vous dérangez pas? S'il vous plaît lisez la suite.

Même si des attaquants cherchent à obtenir le nom et le port de ce compte supplémentaire, une combinaison fail2ban+ iptablesles arrêtera, même si vous avez uniquement utilisé un mot de passe de huit lettres. De plus, fail2ban peut être mis en œuvre pour d'autres services, élargissant ainsi l'horizon de surveillance!

Pour vos propres services, si le besoin s’en fait sentir: en principe, chaque échec de journalisation de service dans un fichier peut obtenir une prise en charge de fail2ban en fournissant un fichier, les expressions rationnelles à associer et le nombre d’échecs autorisés, et le pare-feu interdira simplement toutes les adresses IP est dit à.

Je ne dis pas d'utiliser des mots de passe à 8 chiffres! Mais s'ils sont bannis pendant 24 heures pour cinq tentatives de mot de passe erronées, vous pouvez deviner combien de temps ils devront essayer s'ils ne disposent pas d'un botnet, même avec une sécurité aussi médiocre. Et vous seriez surpris de voir quels mots de passe les clients ont tendance à utiliser, pas seulement pour ssh. En examinant les mots de passe des utilisateurs via Plesk, vous constaterez tout ce que vous préférez ne pas savoir, mais ce que je n'essaie pas de laisser entendre ici. :)

Pare-feu global adaptatif

fail2banest juste une application qui utilise quelque chose du iptables -I <chain_name> 1 -s <IP> -j DROPgenre, mais vous pouvez facilement construire de telles choses vous-même avec de la magie Bash assez rapidement.

Pour développer davantage quelque chose comme ceci, regroupez toutes les adresses IP fail2ban des serveurs de votre réseau sur un serveur supplémentaire, qui gère toutes les listes et les transmet à votre tour à votre pare-feu principal, bloquant ainsi tout le trafic déjà sur le bord de votre réseau.

Une telle fonctionnalité ne peut pas être vendue (bien sûr que si, mais ce sera juste un système fragile et nul), mais doit être intégrée à votre infrastructure.

En cours de route, vous pouvez également utiliser des adresses IP de listes noires ou des listes d'autres sources, qu'elles soient agrégées par vous-même ou externes.

Dans le monde physique, les gens sécurisent les objets de valeur en les mettant dans des coffres-forts. Mais il n'y a pas de coffre-fort dans lequel on ne puisse pas pénétrer. Les coffres-forts, ou conteneurs de sécurité, sont évalués en fonction du temps nécessaire pour forcer l'entrée. Le coffre-fort a pour but de retarder l'attaquant suffisamment longtemps pour qu'il soit détecté et que des mesures actives arrêtent ensuite l'attaque.

De même, l'hypothèse de sécurité appropriée est que vos machines exposées seront éventuellement compromises. Les pare-feux et les bastions ne sont pas configurés pour empêcher votre serveur (avec vos précieuses données) de compromettre, mais pour forcer un attaquant à les compromettre d'abord et vous permettre de détecter (et dissuader) l'attaque avant que les objets de valeur ne soient perdus.

Notez que ni les pare-feu ni les coffres de banque ne protègent contre les menaces internes. C'est l'une des raisons pour lesquelles les comptables des banques prennent deux semaines de congé consécutives et que les serveurs appliquent toutes les mesures de sécurité internes, même s'ils sont protégés par des hôtes bastions.

Vous semblez impliquer dans le message d'origine que vous transférez des paquets "hors du monde" via votre pare-feu directement vers votre serveur. Dans ce cas, oui, votre pare-feu ne fait pas beaucoup. Une meilleure défense de périmètre est réalisée avec deux pare-feu et un hôte bastion, en l'absence de connexion logique directe de l'extérieur vers l'intérieur - chaque connexion se termine dans l'hôte bastion DMZ; chaque paquet est examiné de manière appropriée (et éventuellement analysé) avant son expédition.

Les vulnérabilités sont difficiles à prévoir. Il est pratiquement impossible de prédire de quelle manière votre infrastructure sera exploitée. Avoir un pare-feu "soulève la barre" pour un attaquant qui souhaite exploiter une vulnérabilité, et c'est la partie importante, AVANT de connaître la nature de cette vulnérabilité. De plus, les ramifications du pare-feu peuvent être facilement comprises à l'avance, il est donc peu probable que vous causiez des problèmes avec un pare-feu plus graves que les problèmes que vous êtes susceptible d'éviter.

C'est pourquoi "personne n'a jamais été viré pour avoir installé un pare-feu". Leur mise en œuvre présente un risque très faible et une probabilité ÉLEVÉE d'empêcher ou d'atténuer un exploit. En outre, la plupart des vulnérabilités les plus malveillantes finissent par être exploitées par l’automatisation. Ainsi, tout ce qui est "inhabituel" finira par casser un bot, ou du moins l’obtenir pour vous éviter en faveur d’une cible plus facile.

Note de côté; les pare-feu ne sont pas destinés uniquement à Internet. Votre département de comptabilité. n’a pas besoin de ssh / que ce soit sur votre serveur LDAP, alors ne le leur donnez pas. Compartimenter les services internes peut faire une grande différence dans le travail de nettoyage dans le cas où quelque chose brise les murs du château.

Je dois dire à Ernie que, bien que vous sembliez faire beaucoup pour durcir vos serveurs et limiter les attaques et les vulnérabilités, je ne suis pas d'accord avec votre position concernant les pare-feu.

Je traite la sécurité un peu comme un oignon car, idéalement, vous avez des couches que vous devez traverser avant d’arriver au cœur. Personnellement, j’estime qu'il est extrêmement erroné de ne pas installer de pare-feu matériel sur votre périmètre réseau.

J'admets que j'arrive à cela par l'angle "à quoi je suis habitué", mais je sais que chaque mois, je reçois une belle liste de correctifs de ce mois de Microsoft, dont beaucoup sont exploités à l'état sauvage. . J'imagine qu'il en va de même pour pratiquement tous les systèmes d'exploitation et applications auxquels vous vous intéressez.

Maintenant, je ne suggère pas que les pare-feu suppriment cela, et que les pare-feu ne soient pas immunisés contre les bogues / vulnérabilités, de toute évidence, un pare-feu "matériel" est simplement un logiciel exécuté sur une pile matérielle.

Cela dit, je dors beaucoup plus en sécurité, sachant que si j'ai un serveur qui n'a besoin que du port 443 pour être accessible à partir du Web, mon périmètre Juniper garantit que seul le port 443 est accessible à partir du Web. Non seulement cela, mais mon Palo Alto veille à ce que le trafic entrant soit déchiffré, inspecté, enregistré et analysé pour IPS / IDS - cela ne supprime pas la nécessité de garder le ou les serveurs sécurisés et à jour, mais pourquoi ne PAS trouveriez-vous un avantage étant donné qu'il peut atténuer les exploits du jour zéro et la bonne vieille erreur humaine?

Tout d’abord, dans votre exposé sur la redirection de port, je pense que vous associez pare-feu et NAT. Bien que de nos jours les NAT fonctionnent très souvent comme des coupe-feu de facto, ce n’est pas le but pour lequel elles ont été conçues. La NAT est un outil de routage. Les pare-feu servent à réglementer l'accès. Il est important pour la clarté de la pensée de garder ces concepts distincts.

Il est bien sûr que le fait de placer un serveur derrière une boîte NAT, puis de configurer le NAT pour qu'il transfère quoi que ce soit sur ce serveur, n'est pas plus sûr que de placer le serveur directement sur Internet. Je ne pense pas que quiconque se disputerait avec cela.

De même, un pare-feu configuré pour autoriser tout le trafic n’est pas du tout un pare-feu.

Mais, est-ce que "autoriser tout le trafic" est vraiment la politique que vous voulez? Est-ce que quelqu'un a déjà besoin de ssh sur l'un de vos serveurs à partir d'une adresse IP russe? Pendant que vous bricolez avec la configuration d'un nouveau démon de réseau expérimental, le monde entier a-t-il vraiment besoin d'y accéder?

La puissance d’un pare-feu réside dans le fait qu’il vous permet de garder ouverts uniquement les services dont vous savez qu’ils doivent être ouverts et de maintenir un point de contrôle unique pour la mise en œuvre de cette stratégie.

Les pare-feu d'inspection de paquets avec état ne font PAS partie des serveurs publics. Vous acceptez toutes les connexions, le suivi d'état est donc plutôt inutile. Les pare-feu traditionnels sont une lourde responsabilité pour les attaques par DDoS et sont généralement la première chose à échouer sous une attaque par DDoS, avant même que la bande passante des liens ou les ressources du serveur ne soient totalement consommés.

Les filtres de paquets sans état sur les routeurs ont du sens devant les serveurs publics, mais uniquement s'ils peuvent gérer le débit de tout le trafic entrant et sortant (tel qu'une liste de contrôle d'accès matérielle dans un routeur).

Google, Facebook et même Microsoft ne mettent pas les "pare-feu" traditionnels devant les serveurs publics. Tous ceux qui ont exécuté des services Web publics à "plus d’un serveur" devraient le savoir.

Les autres fonctions présentes dans les pare-feu traditionnels, tels que les ASA de Cisco ou autres, sont mieux mises en œuvre sur les hôtes eux-mêmes, où elles peuvent être étendues efficacement. La journalisation, les IDS, etc. sont de toute façon des fonctionnalités logicielles dans les pare-feu. Elles deviennent donc un énorme goulot d'étranglement et une cible DDoS si elles sont placées devant des serveurs accessibles au public.

Pourquoi tous vos serveurs ont-ils besoin d'une adresse publique?

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

Sur environ 14 serveurs que je lance régulièrement, seulement 2 ont des interfaces accessibles au public.

Ajoutée à ajouter : sur d’autres réseaux que j’ai eu à gérer, nous avons pu activer / désactiver les services à volonté, alors que nous n’avions pas accès à la gestion du pare-feu. Je ne peux même pas commencer à vous dire combien de fois, par inadvertance bien sûr, un service inutile (SMTP) s’est allumé et s’est arrêté, et la seule chose qui nous a empêché de devenir un cliché de spam et de devenir une liste noire, était un pare-feu.

En outre, le trafic en transit entre les serveurs est-il entièrement chiffré?

Vous pouvez certainement conduire une voiture 100 mph sans ceinture de sécurité, sans airbags et pneus chauves, mais pourquoi voudriez-vous ??

Les pare-feu peuvent empêcher les utilisateurs du système d'ouvrir des services accessibles au réseau que les administrateurs ne connaissent pas ou d'effectuer un transfert de port vers d'autres ordinateurs. En utilisant le module hashlimit, les pare-feu peuvent également limiter le nombre d'abus sur la base de l'adresse IP distante.

Un pare-feu est un autre filet de sécurité qui garantit le respect de vos politiques. Bien sûr, ne lancez pas de services auxquels vous ne vous attendez pas.

Je recommande vivement que les mises à jour logicielles soient appliquées rapidement, par exemple, mais je recommande également des pare-feu sur toutes les machines. C'est comme quand je conduisais: Bien sûr, j'essaie d'éviter les obstacles et les autres voitures, mais je porte aussi une ceinture de sécurité et des airbags au cas où l'inattendu se produirait.

Vous ne réalisez peut-être pas à quel point vous tirez parti des pare-feu simplement parce que tout le monde les utilise. À une époque où littéralement tout le monde, à la maison, les utilisateurs de DSL ont des pare-feu en place, le sniffing de port a été pratiquement abandonné en tant que vecteur d’attaque possible. Un pirate informatique honnête ne va pas perdre son temps à vérifier de telles choses.