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 tcpd
et aime utiliser une souris? fwbuilder
pourrait 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/bash
via grub
pour 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
+ iptables
les 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
fail2ban
est juste une application qui utilise quelque chose du iptables -I <chain_name> 1 -s <IP> -j DROP
genre, 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.