Iptables vs. pare-feu matériel

En dehors des problèmes de performances éventuels, une chose à garder à l'esprit est que si votre pare-feu n'est pas sur le même serveur que celui qu'il protège, si par hasard quelqu'un parvient à accéder au serveur web, il ne pourra toujours pas altérer le pare-feu, ce qui signifie qu'il ne pourrait pas modifier vos règles d'envoi, etc.

Un pare-feu séparé pourrait également être configuré de manière à ne pas être accessible via le réseau, ce qui, encore une fois, renforce sa protection contre toute intrusion.

Gardez à l'esprit que ceci est également valable pour un pare-feu logiciel qui est sur une machine séparée, il n'a pas besoin d'être un pare-feu matériel.

À moins qu'il y ait un relais qui claque, c'est toujours un pare-feu logiciel. Vous espérez juste que le logiciel est assez obscur pour que personne ne sache comment le pirater.

J'ai eu et ai eu beaucoup de pare-feu basés sur IPTables pour Linux, de Cisco PIX et de boîtiers grand public prêts à l'emploi. Parmi tous, les pare-feu Linux ont le moins de problèmes nécessitant un redémarrage. La plupart ont dépassé plus de 2 ans de disponibilité continue. En général, les batteries de l'UPS se déchargent avant que le système n'ait besoin d'un redémarrage.

05:35:34 401 jours, 4:08, 1 utilisateur, charge moyenne: 0.02, 0.05, 0.02 J'ai remplacé l'UPS il y a 401 jours.

Sur les 30 pare-feu Cisco PIX, 3 sont tombés en panne après 2 ans et 5 ont dû être redémarrés tous les 2 mois environ.

Le grand avantage des pare-feu "matériels" est souvent leur taille compacte et, espérons-le, l'absence de pièces mobiles.

Je voudrais utiliser un pare-feu matériel si vous essayez de protéger un segment du réseau dans son ensemble, et un pare-feu logiciel si vous essayez de protéger une application spécifique. Le matériel protège votre espace des intrus extérieurs à votre environnement global, et le logiciel protège une fonction spécifique même des autres parties de votre environnement.

Cela dit, dans ce cas, vous protégez une seule boîte, donc je choisirais simplement le logiciel. La baisse de performance ne devrait pas être trop importante jusqu'au moment où vous envisageriez d'avoir plus d'un serveur web de toute façon, auquel cas vous voudrez envisager la voie matérielle.

Et oui, comme indiqué ailleurs, les pare-feu matériels ont tendance à être globalement plus fiables. Ils sont également plus compliqués à configurer et à garder en ordre si vous devez les modifier souvent. Les points soulevés concernant l'augmentation de la sécurité en laissant le trafic suspect atteindre un appareil séparé du serveur web sont valables, mais à mon avis, l'augmentation globale de la sécurité n'est pas justifiée par le coût supplémentaire au niveau d'un seul serveur (avec quelques exceptions notables). Un pare-feu logiciel mature, configuré simplement et sur un serveur régulièrement entretenu qui ne propose aucun autre service au-delà de ceux requis pour sa fonctionnalité web, devrait être stable et sécurisé de nos jours. Ou, du moins, il le sera jusqu'à ce que vous commenciez à obtenir des exploitations de débordement de tampon passant par le trafic HTTP que le pare-feu ne capturera pas de toute façon.

Il a déjà été indiqué - mais si vous n'avez qu'UNE seule boîte de production à gérer, et que c'est la seule boîte de production que vous aurez dans cet environnement dans un avenir prévisible, et que ce n'est pas une boîte qui devra se conformer à des problèmes réglementaires (PCI, etc.) - alors filtrer simplement sur l'hôte devrait suffire.

Vous ne mentionnez pas la redondance ou quoi que ce soit d'autre, donc c'est probablement exagéré.

J'allais dire que si vous avez le budget pour, obtenez quand même une boîte séparée comme pare-feu (ce n'est pas faux...) - mais à mon avis, vous ajouterez un équipement supplémentaire susceptible de tomber en panne - donc si la charge n'est pas une préoccupation, et que vous ne mettez pas en place un système tolérant aux pannes, un serveur nu tout seul n'a pas besoin de pare-feu.

J'ai trouvé un article de recherche de l'université de Pologne qui fait une analyse entre les pare-feu matériels et logiciels.

Je vais ajouter la conclusion de cet article, et mettre en évidence les parties les plus pertinentes en gras.

Il a été observé que le débit des pare-feu dépend fortement de la taille des paquets transmis sur le réseau. Le débit le plus élevé, très proche de la capacité de la connexion directe, a été remarqué pour des paquets d'une longueur égale ou supérieure à 1 ko, pour les longueurs de paquets plus petites, le débit était considérablement moindre. Nous pouvons conclure que la taille optimale du paquet est de 1 ko, lors de l'utilisation de pare-feu réseau. Une conclusion très intéressante est le fait que la performance du pare-feu basé sur un logiciel était égale à la performance de ceux basés sur du matériel.

Les pare-feu matériels et virtuels se sont avérés être résistants aux attaques de déni de service. Comme le montre la documentation, ils disposent de mécanismes intégrés de protection contre les attaques de déni de service. Nous avons été convaincus que ces mécanismes sont efficaces. Le niveau de sécurité du pare-feu logiciel est en réalité égal au niveau de sécurité du système d'exploitation hôte.