iptables et pare-feu matériel

Outre les problèmes de performance (possibles), il faut garder à l'esprit que si votre pare-feu ne se trouve pas sur le même serveur que celui qu'il protège, si d'une manière ou d'une autre quelqu'un hace ont accès au serveur web, ils ne peuvent toujours pas manipuler le pare-feu, ce qui signifie qu'ils ne peuvent pas modifier vos règles de sortie, etc.

Un pare-feu séparé pourrait également être configuré pour ne pas avoir tout d'y accéder via le réseau, ce qui, là encore, renforce ses défenses contre les manipulations.

N'oubliez pas que cela s'applique également à un pare-feu logiciel qui est un boîtier séparé, il n'est pas nécessaire qu'il soit matériel.

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

J'ai eu et j'ai encore de nombreux pare-feu Linux basés sur IPTables, des Cisco PIX et des boîtiers grand public. De tous, les pare-feu Linux sont ceux qui ont le moins besoin d'être redémarrés. La plupart d'entre eux ont plus de deux ans d'autonomie. J'ai tendance à avoir les batteries à plat dans l'UPS avant que le système ait besoin d'un redémarrage.

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

Sur les 30 pare-feu Cisco PIX, 3 sont morts au bout de 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.

J'utiliserais 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 un seul boîtier, donc je choisirais le logiciel. L'impact sur les performances ne devrait pas être trop important jusqu'au moment où vous envisagerez d'avoir plus d'un serveur web, auquel cas vous voudrez vous tourner vers le matériel.

Et oui, comme indiqué ailleurs, les pare-feu matériels ont tendance à être globalement plus fiables. Ils sont également plus difficiles à configurer et à gérer si vous devez les modifier souvent. Les points soulevés concernant la sécurité accrue du trafic suspect sur un dispositif distinct du serveur web sont bien fondés, mais je pense que 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 n'a pas d'autres services en cours d'exécution que ceux requis pour sa fonctionnalité web, devrait être stable et sûr de nos jours. Ou, du moins, il le sera jusqu'à ce que vous commenciez à obtenir des exploits de dépassement de tampon sur le trafic HTTP, que le pare-feu n'attrapera pas de toute façon.

Cela a déjà été dit - mais si vous n'avez affaire qu'à UNE seule boîte de production, 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 questions réglementaires (PCI, etc.) - alors le filtrage sur l'hôte devrait suffire.

Vous ne mentionnez pas la redondance ou quelque chose comme ça, donc c'est probablement exagéré.

J'allais dire que si vous avez le budget pour cela, prenez une boîte séparée comme pare-feu de toute façon (ce n'est pas mal...) - mais IMO vous ajouteriez une pièce d'équipement supplémentaire à casser - donc si la charge n'est pas un problème, et que vous ne déployez pas une configuration tolérante aux pannes, un serveur nu tout seul ne nécessite pas de pare-feu.

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

J'ajouterai la conclusion de ce document, et je soulignerai les parties les plus pertinentes en gras.

Il a été observé que le débit de 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é d'une connexion directe, a été de pour des paquets de longueur égale ou supérieure à 1 kB, pour des paquets de longueur longueur de paquet, le débit était considérablement plus faible. Nous pouvons conclure que la taille optimale du paquet est de 1 kB, lors de l'utilisation de pare-feu de réseau. Une conclusion très intéressante conclusion est le fait que le Les performances du pare-feu logiciel sont égales à celles du pare-feu matériel. .

Les pare-feu matériels et virtuels se sont révélés résistants aux attaques par déni de service. de service. Comme le montre la documentation, ils ont des mécanismes intégrés pour la protection contre les attaques par déni de service. de protection. Nous avons acquis la conviction que ces mécanismes sont efficaces. Le site Le niveau de sécurité du pare-feu logiciel est, en fait, égal au niveau de sécurité du système d'exploitation hôte.