Citation en bloc Vous avez raison, je n'ai pas mis de contre. Contre : complexité accrue du réseau, point de défaillance unique, interface réseau unique par laquelle la bande passante est goulotée. De même, les erreurs administratives commises sur un pare-feu peuvent tuer tout votre réseau. Et les dieux interdisent que vous vous enfermiez à l'extérieur pendant ce temps, alors que le trajet jusqu'à la salle des serveurs dure 20 minutes.

Tout d'abord, l'ajout d'au plus un saut routé supplémentaire dans votre réseau n'est pas complexe. Deuxièmement, aucune solution de pare-feu mise en œuvre avec un point de défaillance unique n'est totalement inutile. De la même manière que vous mettez en grappe votre serveur ou vos services importants et que vous utilisez des cartes d'interface réseau liées, vous mettez en œuvre des pare-feu hautement disponibles. Ne pas le faire, ou ne pas reconnaître et savoir que vous le feriez, c'est manquer de perspicacité. Le simple fait d'affirmer qu'il n'y a qu'une seule interface ne fait pas automatiquement de quelque chose un goulot d'étranglement. Cette affirmation montre que vous n'avez aucune idée de la manière de planifier et de déployer correctement un pare-feu dimensionné pour gérer le trafic qui traverserait 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 à des erreurs qu'un seul endroit.

Quant à l'argument selon lequel vous vous tenez au courant de la sécurité Parcheando et suivez les guides de sécurité, c'est un argument bancal au mieux. Généralement, les correctifs de sécurité ne sont pas disponibles avant la découverte d'une vulnérabilité. Cela signifie que pendant tout le temps où 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 dues à de telles vulnérabilités.

Si vous pensez que vos systèmes sont aussi sûrs qu'ils peuvent l'être, c'est une bonne assurance à avoir. Cependant, je vous recommande de faire réaliser un audit de sécurité professionnel sur votre réseau. Cela pourrait vous ouvrir les yeux.

En général, la sécurité est une affaire d'oignons, comme nous l'avons déjà mentionné. Il y a des raisons pour lesquelles les pare-feu existent, et ce n'est pas seulement parce que tous les autres lemmings sont des crétins stupides.

Cette réponse vient du fait que la recherche de 'fail2ban' sur cette page ne m'a donné aucun résultat. Donc si je double d'autres contenus, soyez indulgents avec moi. Et excusez-moi, si je m'emporte un peu, je vous fais part de mon expérience car cela pourrait être utile à d'autres :)

Considérations relatives à la mise en réseau, locale ou externe

Il est plutôt spécifique à Linux et se concentre sur le pare-feu basé sur l'hôte, qui est généralement le cas d'utilisation. La mise en place d'un pare-feu externe va de pair avec une structure de réseau appropriée et d'autres considérations relatives à la sécurité sont généralement prises en compte. Si vous savez ce qui est sous-entendu ici, alors vous n'aurez probablement pas besoin de ce message. Ou vous ne le savez pas, alors lisez ce qui suit.

L'utilisation de pare-feu externes et locaux peut sembler contre-intuitive et constituer une double tâche. Mais cela donne la possibilité de modifier les règles sur le pare-feu externe, sans compromettre la sécurité de tous les autres hôtes situés derrière lui. Le besoin peut se faire sentir pour des raisons de débogage ou parce que quelqu'un s'est planté. Un autre cas d'utilisation sera abordé dans la section "pare-feu global adaptatif", pour lequel vous aurez également besoin de pare-feu globaux et locaux.

Le coût et la disponibilité et toujours la même histoire :

Le pare-feu n'est qu'un aspect d'un système correctement sécurisé. Ne pas installer un pare-feu parce qu'il "coûte" de l'argent, introduit un SPOF ou autre, c'est juste des conneries, pardonnez mon français. Installez simplement un cluster. Oh, mais que faire si la cellule de feu a une panne ? Alors installez votre cluster sur deux ou plusieurs compartiments de feu.

Mais que se passe-t-il si tout le centre de données est inaccessible, car les deux transporteurs externes sont hors service (une pelleteuse a tué votre fibre) ? Il suffit de faire en sorte que votre cluster s'étende sur plusieurs centres de données, alors.

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

Se plaindre des SPOF, mais ne pas vouloir payer plus cher ou créer des configurations un peu plus complexes est un cas évident de deux poids deux mesures 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 fait l'objet du débat du jour. 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 serveur matériel, d'un backend de stockage, de commutateurs/routeurs, ...

Vous devriez maintenant avoir compris l'idée.

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

En théorie, votre raisonnement est sain. (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 dynamique, 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é les wrappers TCP qui mettent en œuvre la même fonctionnalité pour sécuriser vos données. Pour le bien de l'argument, supposons que quelqu'un ne connaisse pas l'existence de tcpd et aime utiliser une souris ? fwbuilder pourrait vous venir à l'esprit.

Vous devriez avoir activé l'accès complet à partir de votre réseau de gestion, ce qui 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 est exécutée ailleurs et où 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'unique adresse IP donnée de l'autre serveur, c'est tout simple.

Et cela fonctionne aussi parfaitement pour UDP. Ou tout autre protocole. Les pare-feu peuvent être tellement flexibles ;)

Atténuation des portscan

De plus, avec un pare-feu, les portscans généraux peuvent être détectés et atténués car le nombre de connexions par période peut être surveillé par le noyau et sa pile réseau, et le pare-feu peut agir en conséquence.

De même, les paquets invalides ou obscurs peuvent être traités avant qu'ils n'atteignent votre application.

Limitation du trafic sortant

Le filtrage du trafic sortant est généralement un casse-tête. Mais cela peut être une nécessité, selon le contrat.

Statistiques

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

Vous pouvez voir en plein jour si les choses fonctionnent ou non. Ce qui est TRÈS utile pour dépanner les connexions et pour pouvoir dire à l'autre personne au téléphone que vous n'obtenez pas de paquets, sans avoir à recourir au bavardage. tcpdump 's. La mise en réseau est amusante, mais la plupart des gens ne savent pas ce qu'ils font et, trop souvent, il s'agit de simples erreurs de routage. Bon sang, même moi, je ne sais pas toujours ce que je fais. Bien que j'aie travaillé avec des douzaines de systèmes et d'appareils complexes, souvent avec des tunnels aussi, à ce jour.

IDS/IPS

Le pare-feu de couche 7 est généralement un remède de charlatan (IPS/IDS), s'il n'est pas suivi correctement et mis à jour régulièrement. De plus, les licences sont très chères, donc j'éviterais d'en acquérir une si vous n'avez pas vraiment besoin d'obtenir tout ce que l'argent peut vous offrir.

Masqerading

Facile, essayez simplement avec vos emballages. :D

Transfert de port local

Voir déguisement.

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'il n'y a pas de configuration VPN déployée ? Ou d'autres approches dynamiques du pare-feu ? La question y fait déjà allusion, et voici un cas d'utilisation de l'outil de gestion de l'adresse IP. Malheureusement, je ne trouve aucun pare-feu qui fasse ça. partie.

Il est indispensable d'avoir désactivé l'accès au compte root par 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 un mot de passe de connexion si les clés ssh sont perdues ou si le déploiement échoue est très pratique si quelque chose ne va vraiment pas (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 que d'avoir un mode mono-utilisateur sur Linux ou d'utiliser le mode init=/bin/bash via grub pour l'accès local vraiment très mauvais et ne peut pas utiliser un disque vivant pour une raison quelconque. Ne riez pas, il existe des produits de virtualisation qui interdisent cela. Même si la fonctionnalité existe, que se passe-t-il si une version obsolète du logiciel est exécutée sans cette 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 mis en place des choses comme le "port knocking" (pour ouvrir encore un autre port et ainsi atténuer les scans de ports, ce qui est lentement à la limite du pratique), les scans de ports finiront par détecter votre service.

En général, vous installez é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 le modifier sur toutes les machines chaque fois que vous considérez qu'il s'agit d'une information "publique", car elle l'est déjà après un scan. La question de nmap Le fait d'être légal ou non n'est pas un problème lorsque l'on dispose d'une connexion Wi-Fi piratée.

Si ce compte n'est pas nommé "root", les gens ne seront peut-être pas capables de deviner le nom du compte utilisateur de votre "backdoor". Mais ils le sauront, s'ils obtiennent un autre serveur de votre société, ou s'ils achètent simplement de l'espace web, et s'ils peuvent jeter un coup d'oeil sans racines, sans jalousie et sans contrainte à votre site web. /etc/passwd .

Pour une illustration purement théorique, ils pourraient utiliser un site web piratable pour accéder à votre serveur et voir comment les choses se passent habituellement chez vous. Vos outils de recherche de pirates ne fonctionnent peut-être pas 24 heures sur 24 et 7 jours sur 7 (ils fonctionnent généralement la nuit pour des raisons de performance de disque pour les analyses du système de fichiers ? zero-day voit la lumière du jour, il ne détectera donc pas ces événements immédiatement, et sans autres mesures de protection, vous ne saurez peut-être même jamais ce qui s'est passé. Pour revenir à la réalité, si quelqu'un a accès à des exploits de type "zero-day", il est très probable qu'il ne ciblera pas vos serveurs de toute façon, car ceux-ci sont tout simplement coûteux. Il s'agit simplement d'illustrer le fait qu'il existe toujours un moyen de pénétrer dans un système si le "besoin" s'en fait sentir.

Mais pour en revenir au sujet, il suffit de ne pas utiliser de compte supplémentaire avec mot de passe, et de ne pas s'en soucier ? Lisez la suite.

Même si les attaquants parviennent à obtenir le nom et le port de ce compte supplémentaire, un fail2ban + iptables les arrêtera net, même si vous n'avez utilisé qu'un mot de passe de huit lettres. De plus, fail2ban peut être mis en œuvre pour d'autres services également, ce qui élargit l'horizon de surveillance !

Pour vos propres services, si le besoin s'en fait sentir : En principe, tout service enregistrant les échecs dans un fichier peut obtenir le support de fail2ban en fournissant un fichier, une expression rationnelle à faire correspondre et le nombre d'échecs autorisés, et le pare-feu bannira joyeusement toutes les adresses IP qui lui seront indiquées.

Je ne dis pas qu'il faut utiliser des mots de passe à 8 chiffres ! Mais s'ils sont bannis pendant 24 heures pour cinq essais de mots de passe erronés, vous pouvez deviner combien de temps ils devront essayer s'ils n'ont pas un botnet à leur disposition, même avec une sécurité aussi médiocre. Et vous seriez étonné de savoir quels mots de passe les clients ont tendance à utiliser, pas seulement pour les services suivants ssh . Jeter un coup d'œil aux mots de passe de messagerie des gens via Plesk vous dit tout ce que vous préféreriez ne pas vouloir savoir, si jamais vous le faites, mais ce que je n'essaie pas d'insinuer ici bien sûr :)

Pare-feu global adaptatif

fail2ban est juste une application qui utilise quelque chose du type iptables -I <chain_name> 1 -s <IP> -j DROP mais vous pouvez facilement construire ce genre de choses vous-même avec un peu de magie Bash assez rapidement.

Pour aller plus loin, regroupez toutes les adresses IP fail2ban des serveurs de votre réseau sur un serveur supplémentaire, qui rassemble toutes les listes et les transmet à son tour à vos pare-feu principaux, bloquant ainsi tout le trafic déjà en périphérie de votre réseau.

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

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

Tout d'abord, en parlant de transfert de port, je pense que vous confondez le pare-feu avec le NAT. Bien que de nos jours les NATs fonctionnent très souvent comme des pare-feu de facto, ce n'est pas le but pour lequel ils ont été conçus. Le NAT est un outil de routage. Les pare-feu servent à réguler l'accès. Il est important pour la clarté de la pensée de garder ces concepts distincts.

Il est bien sûr vrai que placer un serveur derrière un boîtier NAT et configurer ensuite le NAT pour qu'il transmette tout ce qu'il veut à ce serveur n'est pas plus sûr que de placer le serveur directement sur l'Internet. Je ne pense pas que quiconque puisse contester cette affirmation.

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

Mais, est-ce que "autoriser tout le trafic" est vraiment la politique que vous voulez ? Quelqu'un a-t-il jamais eu 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 doit-il vraiment y avoir accès ?

Le pouvoir d'un pare-feu est qu'il vous permet de ne garder ouverts que les services dont vous savez qu'ils doivent l'être et de conserver un point de contrôle unique pour la mise en œuvre de cette politique.

Dans le monde physique, les gens sécurisent leurs objets de valeur en les plaçant dans des coffres-forts. Mais il n'existe pas de coffre-fort qui ne puisse être forcé. Les coffres-forts, ou conteneurs de sécurité, sont évalués en fonction du temps qu'il faut pour les forcer. L'objectif du coffre-fort est de retarder l'attaquant suffisamment longtemps pour qu'il soit détecté et que des mesures actives puissent mettre fin à l'attaque.

De même, la bonne hypothèse en matière de sécurité est que vos machines exposées seront, un jour ou l'autre, compromises. Les pare-feu et les hôtes bastionnés ne sont pas configurés pour empêcher votre serveur (avec vos précieuses données) d'être compromis, mais pour forcer un attaquant à les compromettre d'abord et vous permettre de détecter (et de dissuader) l'attaque avant que les précieuses données ne soient perdues.

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

Dans votre message initial, vous semblez sous-entendre que vous faites transiter les paquets du "monde extérieur" par votre pare-feu directement vers votre serveur. Dans ce cas, oui, votre pare-feu ne fait pas grand-chose. Un meilleur périmètre de défense est réalisé avec deux pare-feu et un hôte de 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 de bastion DMZ ; chaque paquet est examiné de manière appropriée (et éventuellement analysé) avant d'être transféré.

Les vulnérabilités sont difficiles à prévoir. Il est pratiquement impossible de prévoir de quelle manière votre infrastructure sera exploitée. Le fait de disposer d'un pare-feu "met la barre plus haut" pour un attaquant qui voudrait exploiter une vulnérabilité, et c'est là l'important, AVANT de savoir quelle est cette vulnérabilité. En outre, les ramifications du pare-feu peuvent être facilement comprises à l'avance, de sorte que vous ne risquez pas de CAUSER des problèmes avec un pare-feu qui soient plus graves que ceux 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, de sorte que tout ce qui est "inhabituel" finira par casser un robot, ou du moins par le faire passer à côté de vous au profit d'une cible plus facile.

Remarque : les pare-feu ne sont pas uniquement destinés à l'Internet. Votre service comptable n'a pas besoin d'accéder par ssh ou autre à votre serveur ldap, alors ne le lui donnez pas. Le cloisonnement des services internes peut faire une grande différence dans le travail de nettoyage au cas où quelque chose franchirait les murs du château.