Pourquoi devrais-je pare-feu des serveurs?
VEUILLEZ NOTER: Je ne suis pas intéressé à en faire une guerre de flammes! Je comprends que beaucoup de gens ont des croyances bien ancrées sur ce sujet, en grande partie parce qu'ils ont mis beaucoup d'efforts dans leurs solutions de pare-feu, et aussi parce qu'ils ont été endoctrinés à croire en leur nécessité.
Cependant, je cherche des réponses de personnes qui sont des experts en sécurité. Je crois que c'est une question importante, et la réponse bénéficiera plus que moi-même et l'entreprise pour laquelle je travaille. J'exécute notre réseau de serveurs depuis plusieurs années sans compromis, sans aucun pare-feu. Aucun des compromis de sécurité que nous avons n'aurait pu être évité avec un pare-feu.
Je suppose que je travaille ici depuis trop longtemps, car quand je dis "serveurs", je veux toujours dire "services offerts au public", pas "bases de données de facturation internes secrètes". En tant que tel, toutes les règles que nous le ferions ont dans tous les pare-feu devraient autoriser 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é distinct 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 m'amène à croire que soit les personnes qui ont voté contre n'ont pas vraiment compris ma réponse, soit je ne comprends pas assez la sécurité pour faire ce que je fais actuellement.
Voici mon approche de la sécurité des serveurs:
Suivez mon système d'exploitation consignes de sécurité avant connectez mon serveur à Internet.
Utilisez TCP wrappers pour restreindre l'accès à SSH (et à d'autres services de gestion) à un petit nombre d'adresses IP.
Surveillez l'état de ce serveur avec Munin . Et corrigez les problèmes de sécurité flagrants inhérents au nœud Munin dans sa configuration par défaut.
Nmap mon nouveau serveur (également avant de connecter mon serveur à Internet). Si je devais pare-feu ce serveur, ce devrait être l'ensemble exact de ports que les connexions entrantes devraient être limitées.
Installez le serveur dans la salle des serveurs et donnez-lui une adresse IP publique.
Gardez le système sécurisé 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 forte sécurité basée sur l'hôte supprime la nécessité d'un pare-feu. La philosophie de sécurité globale dit qu'une forte sécurité basée sur l'hôte est toujours requise même si vous avez un pare-feu (voir directives de sécurité ). La raison en est qu'un pare-feu qui transfère des services publics à un serveur permet à un attaquant tout autant qu’aucun pare-feu. C'est le service lui-même qui est vulnérable, et comme l'offre de ce service à l'ensemble de l'Internet est une condition de son fonctionnement, restreindre l'accès à celui-ci n'est pas la question.
S'il y a sont ports disponibles sur le serveur qui n'ont pas besoin d'être accessibles par tout Internet, alors ce logiciel devait être arrêté à l'étape 1, et a été vérifié à l'étape 4. Si un l'attaquant réussit à pénétrer le serveur via un logiciel vulnérable et à ouvrir lui-même un port, l'attaquant peut (et fait) tout aussi facilement vaincre n'importe quel pare-feu en établissant une connexion sortante sur un port aléatoire à la place. Le point de 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 à l'écart en premier lieu.
Il a été suggéré qu'il y a d'autres considérations de sécurité en plus des ports ouverts - mais pour moi, cela ressemble à défendre sa foi. Toutes les vulnérabilités du système d'exploitation/de la pile TCP devraient être tout aussi vulnérables, qu'il existe ou non un pare-feu - en raison du fait que les ports sont transmis directement à ce système d'exploitation/pile TCP. De même, l'exécution de votre pare-feu sur le serveur lui-même au lieu de l'avoir sur le routeur (ou pire, dans les 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 X nombre de couches de contreplaqué les unes sur les autres, puis en forant un trou à travers chacune d'entre elles. Une autre couche de contreplaqué ne va pas arrêter les fuites à travers ce trou que vous faites exprès.
Pour être honnête, la seule façon dont je vois un pare-feu pour les serveurs est s'il a des règles dynamiques empêchant toutes les connexions à tous les serveurs 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 le fasse. La prochaine meilleure chose est un serveur IDS, mais cela suppose que l'attaquant n'attaque pas vos vrais serveurs en premier, et que les attaquants prennent la peine de sonder l'ensemble de votre réseau avant attaquant. En outre, ceux-ci sont connus pour produire un grand nombre de faux positifs.
Avantages du pare-feu:
- Vous pouvez filtrer le trafic sortant.
- Les pare-feu de couche 7 (IPS) peuvent protéger contre les vulnérabilités connues des applications.
- Vous pouvez bloquer une certaine plage d'adresses IP et/ou certains ports de manière centralisée plutôt que de vous assurer qu'il n'y a pas de service d'écoute sur ce port sur chaque machine individuelle ou de refuser l'accès à l'aide de TCP Wrappers .
- Les pare-feu peuvent vous aider si vous devez traiter avec des utilisateurs/administrateurs moins conscients de 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 tous les administrateurs.
- Les journaux du pare-feu fourniraient des journaux centraux et aideraient à détecter les analyses verticales. Les journaux de pare-feu peuvent aider à déterminer si un utilisateur/client essaie 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.
- Les pare-feu sont également livrés avec des modules anti-spam/anti-virus qui renforcent également la protection.
- Sécurité indépendante du système d'exploitation. Basé sur le système d'exploitation hôte, différentes techniques/méthodes sont nécessaires pour sécuriser l'hôte. Par exemple, TCP Wrappers peut ne pas être disponible sur les machines 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 le système local ne peut pas faire confiance car ces binaires peuvent être remplacés. 'nmap' d'un système distant n'est pas garanti car un attaquant peut s'assurer que root-kit accepte les connexions uniquement à partir des adresses IP source sélectionnées à des moments sélectionnés.
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 du pare-feu par rapport aux systèmes d'exploitation/fichiers hôtes.
Inconvénients du pare-feu:
- Les gens pensent que le pare-feu veillera à la sécurité et ne mettra pas à jour les systèmes régulièrement et n'arrêtera pas les services indésirables.
- Ils coutent. Parfois, des frais de licence annuels doivent être payés. Surtout si le pare-feu dispose de modules antivirus et anti-spam.
- Point de défaillance unique supplémentaire. Si tout le trafic passe par un pare-feu et que le pare-feu tombe en panne, le réseau s'arrêtera. Nous pouvons avoir des pare-feu redondants, mais le point précédent sur le coût est encore amplifié.
- Le suivi avec état ne fournit aucune valeur sur les systèmes accessibles au public qui acceptent toutes les connexions entrantes.
- Les pare-feu avec état sont un goulot d'étranglement massif lors d'une attaque DDoS et sont souvent la première chose à échouer, car ils tentent de maintenir l'état et d'inspecter toutes les connexions entrantes.
- 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 ajoutent peu de valeur devant les serveurs publics. Certains pare-feu de nouvelle génération peuvent recevoir des clés privées pour terminer TLS et voir l'intérieur du trafic, mais cela augmente encore plus la vulnérabilité du pare-feu aux DDoS et brise le modèle de sécurité de bout en bout de TLS.
- Les systèmes d'exploitation et les applications sont corrigés des vulnérabilités beaucoup plus rapidement que les pare-feu. Les fournisseurs de pare-feu sont souvent confrontés à des problèmes connus pendant ans sans appliquer de correctifs, et l'application de correctifs à un cluster de pare-feu nécessite généralement des temps d'arrêt pour de nombreux services et connexions sortantes.
- Les pare-feu sont loin d'être parfaits, et beaucoup sont notoirement buggés. Les pare-feu ne sont que des logiciels exécutés sur une certaine forme de système d'exploitation, peut-être avec un ASIC ou 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 Par conséquent, les pare-feu ajoutent de la 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.
Pour le point sur un attaquant établissant 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 les sorties d'une manière appropriée au risque lié au système.
En ce qui concerne la façon dont une vulnérabilité TCP n'est pas atténuée par un pare-feu, vous n'êtes pas familier avec le fonctionnement des pare-feu. Cisco a tout un tas de règles disponibles pour le téléchargement qui identifient les paquets construits dans d'une manière qui pourrait causer des problèmes particuliers aux systèmes d'exploitation. Si vous saisissez Snort et commencez à l'exécuter avec le bon ensemble de règles, vous serez également alerté sur ce genre de chose. Et bien sûr, les iptables Linux peuvent filtrer les paquets malveillants.
Fondamentalement, un pare-feu est une protection proactive. Plus vous vous éloignez de la proactivité, plus vous risquez 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é, 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 aucune chose n'est nécessairement une solution définitive. Une bonne solution de sécurité est généralement multicouche, où vous avez un pare-feu à la frontière, TCP wrappers sur le périphérique, et probablement aussi quelques 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 n'est pas comme percer un trou à travers plusieurs feuilles de contreplaqué, c'est plus comme mettre en place une paire de portes afin qu'un intrus ait deux verrous à briser au lieu de simplement un; cela s'appelle un piège à homme 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-fe ")
Maintenant: qu'en est-il d'un système hérité pour lequel aucun correctif n'est plus publié? Et si vous ne pouviez pas appliquer les correctifs aux N-machines au moment où vous en avez besoin, alors que vous pouvez en même temps les appliquer sur moins de nœuds du réseau (pare-feu)?
Il est inutile de débattre de l'existence ou du besoin 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 le mettront en œuvre et vous aiderez à le gérer, à l'étendre 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 d'avoir une mise en œuvre fonctionnelle 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 pour en installer un.
Peu de choses sont une "nécessité" au sens strict du mot. La sécurité consiste davantage à mettre en place tous les blocus que vous pouvez. Plus de travail est nécessaire pour pénétrer dans votre serveur, moins de chances de réussir l'attaque. Vous voulez faire en sorte qu'il soit plus efficace de pénétrer dans vos machines qu'ailleurs. L'ajout d'un pare-feu rend plus de travail.
Je pense qu'une utilisation clé est la redondance de 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 la cartographie nm un peu plus gênante pour un attaquant.
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 les connexions entrantes pour aider à atténuer les attaques DOS.
"Le point de 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 à l'écart 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 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 à tous, sauf à la poignée de ports qui sont légitimement 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 fonctionnant sur ce même hôte empêcherait-il l'exploit? Eh bien, peut-être ...
Et c'est probablement la raison la plus importante pour exécuter un pare-feu sur chaque hôte: un pare-feu pourrait empêcher une vulnérabilité de la pile réseau d'être exploitée. Est-ce une raison suffisante? Je ne sais pas, mais je suppose que l'on pourrait dire: "Personne n'a jamais été renvoyé pour avoir installé un pare-feu."
Une autre raison pour exécuter un pare-feu sur un serveur est de dissocier ces deux problèmes sinon fortement corrélés:
- D'où et vers quels ports, est-ce que j'accepte les connexions?
- Quels services fonctionnent et écoutent les 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 desquels 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, il y a moins de raisons d'installer un pare-feu sur un serveur.
Sur une note finale, il y a un élément non mentionné dans votre liste de contrôle de sécurité que j'ajoute toujours, et c'est un système de détection d'intrusion basé sur l'hôte (HIDS), tel que AIDE ou samhain . Un bon HIDS, il est extrêmement difficile pour un intrus d'apporter des modifications indésirables au système et de ne pas être détecté. Je crois que tous les serveurs devraient exécuter une sorte de HIDS.
Un pare-feu est un outil. Il ne sécurise pas les choses en soi, mais il 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 gens qui disent aveuglément "Je dois avoir un pare-feu" sans comprendre pourquoi ils pensent de cette façon 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 d'exécuter un ordinateur Windows sans antivirus? Oui, c'est ... mais c'est une belle assurance pour en avoir un.
Je dirais la même chose des pare-feu - quoi que vous puissiez dire d'autre à leur sujet, ils sont un bon niveau d'assurance. Ils ne remplacent pas les correctifs, le verrouillage des machines, la désactivation des services que vous n'utilisez pas, la journalisation, etc ... mais ils peuvent être un complément utile.
Je suggérerais également que l'équation change quelque peu selon que vous parliez ou non de placer un pare-feu devant un groupe de serveurs soigneusement entretenus, comme vous semblez l'être, ou un LAN typique avec un mélange de postes de travail et de serveurs , dont certains pourraient exécuter des trucs assez poilus malgré les meilleurs efforts et souhaits de l'équipe informatique.
Une autre chose à considérer est l'avantage de créer une cible manifestement durcie. Une sécurité visible, qu'il s'agisse de lumières vives, de serrures lourdes et d'une alarme évidente sur un bâtiment; ou un pare-feu évident sur la gamme d'adresses IP d'une entreprise peut dissuader l'intrus occasionnel - ils iront à la recherche de proies plus faciles. Cela ne dissuadera pas l'intrus déterminé qui sait que vous avez des informations qu'il veut et est déterminé à les obtenir, mais dissuader les intrus occasionnels vaut toujours la peine - surtout si vous savez que tout intrus dont les sondes persistent après la dissuasion doit être pris particulièrement au sérieux .
Toutes les grandes questions. MAIS - je suis très surpris que la PERFORMANCE ne soit pas mise sur la table.
Pour les frontaux Web très utilisés (CPU), le pare-feu local dégrade vraiment les performances, point final. Essayez un test de charge et voyez. J'ai vu ça des tonnes de fois. La désactivation du pare-feu a augmenté les performances (demande par seconde) de 70% ou plus.
Ce compromis doit être pris en considération.
Un pare-feu est une protection supplémentaire. Il protège contre trois scénarios particuliers: les attaques de pile de réseau (c.-à-d. Que votre système d'exploitation de serveur est vulnérable à des paquets spécialement conçus qui n'atteignent jamais le niveau des ports), une intrusion réussie établissant une connexion au "téléphone maison" (ou envoyant du spam, ou autre) ), ou une intrusion réussie ouvrant un port de serveur ou, moins détectable, surveillez une séquence de détournement de port avant d'ouvrir un port. Certes, les deux derniers ont à voir avec l'atténuation des dommages d'une intrusion plutôt que de la prévenir, mais cela ne signifie pas qu'elle est inutile. N'oubliez pas que la sécurité n'est pas une proposition tout ou rien; on adopte une approche en couches, ceinture et bretelles, pour atteindre un niveau de sécurité suffisant à vos besoins.
Un pare-feu n'est certainement pas nécessaire pour les petites configurations. 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 il y a plusieurs raisons pour lesquelles je maintiens cette philosophie:
Séparation des rôles
Les serveurs sont destinés aux applications. Les pare-feu sont destinés à l'inspection, au filtrage et aux politiques des 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, c'est comme demander à votre comptable d'être également votre gardien de sécurité.
Le logiciel est une cible mobile
Le logiciel sur l'hôte est en constante évolution. Les applications peuvent créer leurs propres exceptions de pare-feu. Le système d'exploitation est mis à jour et corrigé. Les serveurs sont une zone "d'administration" à fort trafic, et vos politiques de pare-feu/politiques de sécurité sont souvent bien plus importantes pour la sécurité que vos configurations d'application. Dans un environnement Windows, supposons que quelqu'un commette une erreur à un niveau de stratégie de groupe et désactive le pare-feu Windows sur les ordinateurs de bureau, et ne se rend pas compte qu'il va être appliqué aux serveurs. Vous êtes grand ouvert en quelques clics.
En ce qui concerne les mises à jour, les mises à jour du firmware du pare-feu sortent généralement une ou deux fois par an, tandis que les mises à jour du système d'exploitation et des services sont un flux constant.
Services/politiques/règles réutilisables, gérabilité
Si j'installe une fois un service/politique appelé "Web Server" (disons TCP 80 et TCP 443), et l'applique au "groupe de serveurs Web "au niveau du pare-feu, c'est beaucoup plus efficace (quelques changements de configuration) et exponentiellement moins sujet aux erreurs humaines que de configurer des services de pare-feu sur 10 boîtiers et d'ouvrir 2 ports x 10 fois. Lorsque cette stratégie doit changer, c'est 1 changement contre 10.
je peux toujours gérer un pare-feu lors d'une attaque, ou après un compromis
Supposons que mon pare-feu basé sur l'hôte + serveur d'applications soit attaqué et que le processeur soit hors du graphique. Pour même commencer à comprendre ce qui se passe, je suis à la merci de ma charge inférieure à celle de l'attaquant pour même y entrer et le regarder.
Une expérience réelle - j'ai une fois foiré une règle de pare-feu (laissé les ports à N'IMPORTE QUEL au lieu d'un spécifique, et le serveur avait un service vulnérable), et l'attaquant avait en fait une session Remote Desktop en direct dans la boîte. Chaque fois que je commençais à avoir une session, l'attaquant tuait/déconnectait ma session. Si ce n'était pas pour avoir pu arrêter cette attaque à partir d'un pare-feu indépendant, cela aurait pu être bien pire.
Surveillance indépendante
La journalisation dans 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. Certains sont assez bons pour que vous n'ayez même pas besoin d'un logiciel de surveillance SNMP/NetFlow externe pour obtenir une image précise.
Conservation IPv4
Il n'y a aucune raison d'avoir deux adresses IP si l'une est pour le Web et l'autre pour le courrier. Conservez les services sur des boîtes distinctes et acheminez les ports de manière appropriée via l'appareil conçu pour cela.
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 utilisé certaines des fonctionnalités de base d'un pare-feu et que vous les ayez intégrées à vos politiques et procédures. Non, vous n'avez pas besoin d'un pare-feu si vous voulez faire le même travail qu'un pare-feu vous-même. Quant à moi, je préfère faire de mon mieux pour maintenir la sécurité, mais avoir un pare-feu regardant par-dessus mon épaule, mais à un moment donné, lorsque vous pouvez faire tout ce que le pare-feu fait, cela commence à devenir hors de propos.
En général, la sécurité est une chose oignon, comme déjà mentionné. Il y a des raisons pour lesquelles les pare-feu existent, et ce ne sont pas seulement tous les autres lemmings qui sont des imbéciles stupides.
Cette réponse vient, car la recherche de 'fail2ban' sur cette page ne m'a donné aucun résultat. Donc, si je double d'autres contenus, supportez-moi. Et excusez-moi, si je me lamente un peu, je fournis une expérience simple car cela pourrait être utile pour les autres. :)
Considérations de mise en réseau, locale vs externe
C'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é vont généralement dans ce sens. Soit vous savez ce qui est impliqué ici, alors vous n'aurez probablement pas besoin de cette publication. Ou vous ne le faites pas, alors lisez la suite.
L'exécution de pare-feu en externe et en local peut sembler contre-intuitive et double. Mais cela donne également la possibilité de tourner les règles sur l'externe, sans compromettre la sécurité de tous les autres hôtes se trouvant derrière. Le besoin peut provenir de raisons de débogage ou du fait que quelqu'un vient de foirer. Un autre cas d'utilisation apparaîtra dans la section "pare-feu global adaptatif", pour lequel vous aurez également besoin de pare-feu mondiaux et locaux.
Coût et disponibilité et toujours la même histoire:
Le pare-feu n'est qu'un aspect d'un système sécurisé approprié. Ne pas installer de pare-feu car cela "coûte" de l'argent, introduit un SPOF ou quoi que ce soit juste des conneries, pardonnez mon français ici. Configurez simplement un cluster. Oh, mais que faire si la cellule d'incendie est en panne? Configurez ensuite votre cluster sur 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 (une pelle a tué votre fibre)? Créez simplement votre cluster sur plusieurs centres de données.
C'est cher? Les clusters sont trop complexes? Eh bien, la paranoïa doit être payée.
Se contenter de se plaindre des SPOF, mais ne pas vouloir payer plus d'argent ou créer des configurations un peu plus complexes est un cas clair de double standard ou simplement un petit portefeuille du côté de l'entreprise ou du client.
Ce schéma s'applique à TOUTES ces discussions, quel que soit le service qui soit d'actualité. Qu'il s'agisse 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 virtuel ou d'un 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 solide. (Seuls les services en cours d'exécution peuvent être exploités.)
Mais ce n'est que la moitié de la vérité. Le pare-feu, en particulier le pare-feu avec état, peut faire beaucoup plus pour vous. Les pare-feu sans état ne sont importants que si vous rencontrez des problèmes de performances comme ceux déjà mentionnés.
Contrôle d'accès simple, central et discret
Vous avez mentionné TCP wrappers qui implémentent essentiellement la même fonctionnalité pour sécuriser votre. Pour l’argument, supposons que quelqu'un ne connaît pas tcpd et aime utiliser une souris? fwbuilder pourrait vous venir à l'esprit.
Avoir un accès complet à partir de votre réseau de gestion est quelque chose que vous auriez dû activer, ce qui est l'un des premiers cas d'utilisation de votre pare-feu basé sur l'hôte.
Que diriez-vous d'une configuration multi-serveurs, où la base de données s'exécute ailleurs et vous ne pouvez pas placer 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 unique de l'autre serveur, c'est simple.
Et cela fonctionne également parfaitement pour UDP. Ou quel que soit le protocole. Les pare-feu peuvent être extrêmement flexibles. ;)
Atténuation de Portscan
De plus, avec le pare-feu, les analyses de port générales peuvent être détectées et atténuées car la quantité de connexions par intervalle de temps peut être surveillée via le noyau et sa pile de mise en réseau, et le pare-feu peut agir en conséquence.
Les paquets non valides ou obscurs peuvent également être traités avant qu'ils n'atteignent votre application.
Limitation du trafic sortant
Le filtrage du trafic sortant est généralement une douleur dans le cul. Mais cela peut être un must, selon le contrat.
Statistiques
Une autre chose qu'un pare-feu peut vous apporter, ce sont les statistiques. (Pense watch -n1 -d iptables -vnxL INPUT avec l'ajout de règles pour les adresses IP spéciales tout en haut pour voir si les paquets arrivent.)
Vous pouvez voir en plein jour si les choses fonctionnent ou non. Ce qui est TRÈS utile pour dépanner les connexions et pouvoir dire à l'autre personne au téléphone que vous n'obtenez pas de paquets, sans avoir à recourir à des messages tcpdump bavards. Le réseautage est amusant, la plupart des gens savent maintenant ce qu'ils font et, souvent, ce ne sont que de simples erreurs de routage. Enfer, même je ne sais pas toujours ce que je fais. Bien que j'ai travaillé avec des dizaines de systèmes et d'appareils complexes, souvent avec des tunnels, maintenant.
IDS/IPS
Le pare-feu de couche 7 est généralement de l'huile de serpent (IPS/IDS), s'il n'est pas correctement suivi et mis à jour régulièrement. De plus, les licences sont sacrément chères, donc j'épargnerais d'en obtenir une si vous n'avez pas vraiment besoin d'obtenir tout ce que l'argent peut vous acheter.
Masqerading
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 du pare-feu? Ceci est déjà indiqué dans la question, et voici un cas d'utilisation pour Malheureusement, je ne trouve aucun pare-feu qui le fasse. part .
Il est indispensable d'avoir désactivé l'accès au compte root via un mot de passe. Même si l'accès est limité à certaines adresses IP.
De plus, avoir un autre compte blanko prêt avec une connexion par mot de passe si les clés ssh sont perdues ou le déploiement échoue est très pratique si quelque chose se passe vraiment mal (un utilisateur a un accès administratif à la machine et `` des choses se sont passées ''?). C'est la même idée pour l'accès au réseau car il a le mode mono-utilisateur sur Linux ou utilise init=/bin/bash via grub pour l'accès local vraiment très mauvais et ne peut pas utiliser un disque en direct pour une raison quelconque. Ne riez pas, il existe des produits de virtualisation qui l'interdisent. Même si la fonctionnalité existe, que se passe-t-il si une version de logiciel 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 choses comme le détournement de port (pour ouvrir même un autre port et atténuer ainsi les analyses de port, à la limite d'être trop peu pratiques), les analyses de port détecteront votre service éventuellement.
Habituellement, 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. Vous ne pouvez pas non plus la modifier sur toutes les machines chaque fois que vous la considérez comme une information "publique", car elle se trouve déjà après une analyse. La question de nmap étant légale 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", les gens ne pourront peut-être 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 entreprise, ou s'ils achètent simplement un espace Web, et qu'ils auront un regard non bridé/non emprisonné/non confiné sur /etc/passwd.
À titre d'illustration purement théorique, ils pourraient utiliser un site Web piratable pour accéder à votre serveur et voir comment les choses se déroulent généralement chez vous. Vos outils de recherche de piratage peuvent ne pas fonctionner 24h/24 et 7j/7 (ils le font généralement la nuit pour des raisons de performances du disque pour les analyses du système de fichiers?) Et vos antivirus ne sont pas mis à jour la seconde une nouvelle zero-day voit la lumière de la journée, il ne détectera donc pas ces événements à la fois, et sans d'autres mesures de protection, vous ne saurez peut-être même pas ce qui s'est passé. Pour revenir à la réalité, si quelqu'un a accès à des exploits zero-day, il est très probable qu'il ne ciblera pas vos serveurs de toute façon car ceux-ci sont juste chers. C'est juste pour illustrer qu'il y a toujours un moyen d'entrer dans un système si le "besoin" se fait sentir.
Mais encore une fois, n'utilisez pas de compte avec mot de passe supplémentaire et ne vous embêtez pas? Veuillez lire.
Même si les attaquants obtiennent le nom et le port de ce compte supplémentaire, un fail2ban + iptables combinaison les arrêtera court, même si vous avez utilisé uniquement un mot de passe de huit lettres. De plus, fail2ban peut également être implémenté pour d'autres services, élargissant ainsi l'horizon de surveillance!
Pour vos propres services, si le besoin se fait sentir: en gros, chaque échec de la journalisation des services dans un fichier peut obtenir une prise en charge de fail2ban en fournissant un fichier, quelle expression régulière doit correspondre et combien d'échecs sont autorisés, et le pare-feu interdira volontiers chaque adresse IP qu'il est dit de.
Je ne dis pas d'utiliser des mots de passe à 8 chiffres! Mais s'ils sont interdits pendant 24 heures pour cinq tentatives de mot de passe incorrectes, vous pouvez deviner combien de temps ils devront essayer s'ils n'ont pas de botnet à leur disposition, même avec une sécurité aussi minable. Et vous seriez étonné des mots de passe que les clients ont tendance à utiliser, pas seulement pour ssh. Jetez un œil aux mots de passe des gens via Plesk vous dit tout ce que vous préférez ne pas savoir, si jamais vous le faites, mais ce que je n'essaie pas d'impliquer ici bien sûr. :)
Pare-feu global adaptatif
fail2ban n'est qu'une application qui utilise quelque chose comme iptables -I <chain_name> 1 -s <IP> -j DROP, mais vous pouvez facilement créer de telles choses vous-même avec de la magie Bash assez rapidement.
Pour développer davantage quelque chose comme ça, agrégez toutes les adresses IP fail2ban des serveurs de votre réseau sur un serveur supplémentaire, qui conserve toutes les listes et les transmet à son tour à vos pare-feu principaux bloquant tout le trafic déjà sur la périphérie de votre réseau.
Une telle fonctionnalité ne peut pas être vendue (bien sûr, mais ce sera juste un système fragile et nul), mais doit être imbriquée dans votre infrastructure.
Pendant que vous y êtes, vous pouvez également utiliser des adresses IP de liste noire ou des listes provenant d'autres sources, qu'elles soient agrégées par vous-même ou par des sources externes.
Blockquote Eh bien, vous avez raison, je n'ai mis aucun inconvénient là-dedans. Inconvénients: complexité du réseau accrue, point de défaillance unique, interface réseau unique à travers laquelle la bande passante est goulot d'étranglement. De même, les erreurs administratives commises sur un pare-feu peuvent tuer l'intégralité de votre réseau. Et les dieux interdisent que vous vous enfermiez hors de lui en attendant quand c'est un voyage de 20 minutes à la salle des serveurs.
Tout d'abord, l'ajout d'au plus un tronçon routé supplémentaire via votre réseau n'est pas complexe. Deuxièmement, aucune solution de pare-feu implémentée avec un seul point de défaillance n'est complètement inutile. Tout comme vous mettez en cluster votre serveur ou vos services importants et utilisez des cartes réseau liées, vous implémentez 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 dire qu'il existe une seule interface ne fait pas automatiquement quelque chose un goulot d'étranglement. Cette affirmation montre que vous ne savez pas comment planifier et déployer correctement un pare-feu dimensionné pour gérer le trafic qui circulerait sur votre réseau. Vous avez raison de dire qu'une erreur de politique peut nuire à l'ensemble de votre réseau, mais je dirais que le maintien de politiques individuelles sur tous vos serveurs est beaucoup plus sujet aux erreurs qu'un seul endroit.
Quant à 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 exécutez des serveurs publiquement adressables, 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 compromis de ces vulnérabilités.
Si vous pensez que vos systèmes sont aussi sûrs que possible, c'est une bonne confiance à avoir. Cependant, je vous recommande de faire réaliser un audit de sécurité professionnel sur votre réseau. Cela pourrait simplement vous ouvrir les yeux.
Dans le monde physique, les gens sécurisent leurs objets de valeur en les mettant dans des coffres-forts. Mais il n'y a pas de coffre-fort qui ne puisse être pénétré. Les coffres-forts, ou conteneurs de sécurité, sont évalués en fonction du temps qu'il faut pour forcer l'entrée. Le but du coffre-fort est de retarder l'attaquant suffisamment longtemps pour qu'il soit détecté et des mesures actives puis de stopper l'attaque.
De même, l'hypothèse de sécurité appropriée est que vos machines exposées seront éventuellement compromises. Les pare-feu et les hôtes 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 de dissuader) l'attaque avant la perte des objets de valeur.
Notez que ni les pare-feu ni les coffres-forts bancaires ne protègent contre les menaces internes. C'est l'une des raisons pour lesquelles les comptables bancaires doivent prendre deux semaines de congé consécutives et pour que les serveurs bénéficient de toutes les précautions de sécurité internes, même s'ils sont protégés par des hôtes bastions.
Vous semblez impliquer dans la publication d'origine que vous transférez des paquets du "monde extérieur" via votre pare-feu directement vers votre serveur. Dans ce cas, oui, votre pare-feu ne fait pas grand-chose. Une meilleure défense du périmètre est effectuée avec deux pare-feu et un hôte bastion, où il n'y a pas 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 la transmission.
Tout d'abord, en parlant de la redirection de port, je pense que vous confondez le pare-feu avec le NAT. Bien que de nos jours, les NAT fonctionnent très souvent comme des pare-feu de facto, ce n'est pas le but pour lequel ils ont été conçus. NAT est un outil de routage. Les pare-feu servent à réguler l'accès. Il est important, par souci de clarté, de garder ces concepts distincts.
Il est bien sûr vrai que placer un serveur derrière une boîte NAT puis configurer le NAT pour transmettre quoi que ce soit à ce serveur, n'est pas plus sûr que de mettre serveur directement sur Internet. Je pense que personne ne contesterait cela.
De même, un pare-feu configuré pour autoriser tout le trafic n'est pas du tout un pare-feu.
Mais, "autoriser tout le trafic" est-il vraiment la politique que vous souhaitez? Quelqu'un a-t-il jamais besoin de se connecter à l'un de vos serveurs à partir d'une adresse IP russe? Pendant que vous bricolez la configuration d'un nouveau démon réseau expérimental, le monde entier a-t-il vraiment besoin d'y accéder?
La puissance d'un pare-feu est 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 avec inspection des paquets avec état n'appartiennent PAS devant les serveurs publics. Vous acceptez toutes les connexions, donc le suivi de l'état est assez inutile. Les pare-feu traditionnels sont un énorme handicap dans les attaques DDoS et sont généralement la première chose qui échoue sous une attaque DDoS, avant même que la bande passante du lien ou les ressources du serveur ne soient totalement consommées.
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 ligne de tout le trafic d'entrée et de sortie (comme une ACL matérielle dans un routeur).
Google, Facebook et même Microsoft ne mettent pas de "pare-feu" traditionnels devant les serveurs publics. Quiconque a géré des services Web publics à l'échelle de "plusieurs serveurs" doit le savoir.
D'autres fonctions présentes dans les pare-feu traditionnels tels que Cisco ASA ou tout ce qui est mieux implémenté sur les hôtes eux-mêmes, où elles peuvent être mises à l'échelle efficacement. La journalisation, les IDS, etc. sont de toute façon toutes les fonctionnalités logicielles des pare-feu, ils deviennent donc un énorme goulot d'étranglement et une cible DDoS s'ils sont placés devant des serveurs accessibles au public.
Les vulnérabilités sont difficiles à prévoir. Il est pratiquement impossible de prédire de quelle manière votre infrastructure va être exploitée. Avoir un pare-feu "élève la barre" pour un attaquant qui souhaite exploiter une vulnérabilité, et c'est la partie importante, AVANT de savoir ce qu'est cette vulnérabilité. De plus, les ramifications du pare-feu peuvent être facilement comprises à l'avance, il est donc peu probable que cela cause 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é licencié pour avoir installé un pare-feu". Leur mise en œuvre présente un risque très faible et a une forte probabilité d'empêcher ou d'atténuer un exploit. De plus, la plupart des vulnérabilités vraiment désagréables finissent par être exploitées par l'automatisation, donc tout ce qui est "inhabituel" finira par casser un bot, ou du moins le faire vous sauter en faveur d'une cible plus facile.
Note latérale; les pare-feu ne sont pas réservés à Internet uniquement. Votre service de comptabilité. n'a pas besoin de ssh/que ce soit pour votre serveur LDAP, alors ne le leur donnez pas. La compartimentation des services internes peut faire une grande différence dans le travail de nettoyage dans le cas où quelque chose briserait les murs du château.
Je dois dire Ernie que même si vous semblez faire beaucoup pour durcir vos serveurs et atténuer les attaques et les vulnérabilités, je ne suis pas d'accord avec votre position sur les pare-feu.
Je traite la sécurité un peu comme un oignon dans la mesure où, idéalement, vous avez des couches que vous devez traverser avant d'arriver au cœur, et personnellement, je pense qu'il est vraiment malavisé de ne pas avoir une sorte de pare-feu matériel sur le périmètre de votre réseau.
J'admets que j'y arrive sous l'angle "à quoi je suis habitué", mais je sais que chaque mois, je reçois une jolie petite liste des correctifs de ce mois de Microsoft, dont beaucoup sont exploités à l'état sauvage . J'imagine que la même chose se produit pour à peu près n'importe quel système d'exploitation et ensemble d'applications auxquels vous pensez.
Maintenant, je ne suggère pas que les pare-feu suppriment cela, et les pare-feu ne sont pas à l'abri des bogues/vulnérabilités, de toute évidence, un pare-feu "matériel" n'est qu'un logiciel fonctionnant 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 garantit que le trafic entrant est déchiffré, inspecté, enregistré et analysé pour IPS/IDS - pas qu'il supprime la nécessité de maintenir le ou les serveurs sécurisés et à jour, mais pourquoi ne trouveriez-vous PAS un avantage étant donné qu'il peut atténuer les exploits du jour zéro et les bonnes vieilles erreurs humaines?
Pourquoi tous vos serveurs ont-ils besoin d'une adresse publique?
Installez le serveur dans la salle des serveurs et donnez-lui une adresse IP publique.
Sur 14 serveurs environ que j'exécute régulièrement, seulement 2 ont des interfaces accessibles au public.
Modifié pour ajouter: Dans d'autres réseaux que j'ai eu la main dans la gestion, nous avons pu désactiver/activer les services à volonté, alors que nous n'avions pas accès pour gérer le pare-feu . Je ne peux même pas commencer à vous dire combien de fois, par inadvertance, bien sûr, un service inutile (SMTP) a été activé et laissé en marche et la seule chose qui nous a évité de devenir un vidage de spam et d'être mis sur liste noire dans le processus, était un pare-feu.
De plus, tout le trafic qui passe entre les serveurs est-il entièrement crypté?
Vous pouvez certainement conduire une voiture à 100 mph sans ceinture de sécurité, sans airbags et pneus chauves, mais pourquoi le feriez-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 une redirection de port vers d'autres machines. En utilisant le module hashlimit, les pare-feu peuvent également limiter les taux d'abus en fonction 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, n'exécutez pas les services auxquels vous ne vous attendez pas.
Je recommande définitivement que les mises à jour logicielles soient appliquées en temps opportun, par exemple, mais je recommande également les pare-feu sur toutes les machines. C'est comme lorsque je conduis: bien sûr, j'essaie d'éviter les obstacles et les autres voitures, mais je porte également 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 bénéficiez des pare-feu simplement parce que tout le monde else les utilise. À une époque où littéralement tout le monde, jusque chez eux, les utilisateurs DSL ont des pare-feu en place, le reniflage de port a été presque abandonné comme vecteur d'attaque réalisable. Un pirate décent ne va pas perdre son temps à vérifier de telles choses.