Je suis en train de réviser notre réseau, le problème auquel je reviens toujours est: essayer d'amener la couche 3 au cœur, tout en ayant un pare-feu centralisé.

Le principal problème que j'ai ici est que les commutateurs «mini-cœur» que j'ai examinés ont toujours de faibles limites ACL dans le matériel, que même à notre taille actuelle, nous pourrions rapidement atteindre. Je suis actuellement sur le point d'acheter (espérons-le) une paire d'EX4300-32F pour le noyau, mais j'ai examiné d'autres modèles et d'autres options de la gamme ICX de Juniper et Brocade. Ils semblent tous avoir les mêmes limites ACL basses.

Cela est parfaitement logique car les commutateurs principaux doivent être en mesure de maintenir le routage à vitesse filaire, donc ne voulez pas trop sacrifier le traitement ACL. Je ne peux donc pas faire tout mon pare-feu sur les commutateurs principaux eux-mêmes.

Cependant, nous faisons surtout des serveurs entièrement gérés, et avoir un pare-feu centralisé (avec état) aide beaucoup à cette gestion - car nous ne pouvons pas laisser les clients parler directement entre eux. Je voudrais que cela reste le cas si nous le pouvons, mais j'ai l'impression que la plupart des réseaux ISP ne feraient pas ce genre de chose, d'où pourquoi dans la plupart des cas, il serait simple de faire le routage dans le cœur.

Pour référence, voici la topologie que j'aimerais idéalement faire (mais je ne sais pas où installer le FW évidemment).

Solution actuelle

À l'heure actuelle, nous avons une configuration de routeur sur un bâton. Cela nous permet de faire du NAT, du pare-feu avec état et du routage VLAN tout au même endroit. Très simple.

Je pourrais continuer avec (à peu près) la même solution en étendant L2 jusqu'au «sommet» de notre réseau - les routeurs frontaliers. Mais je perds alors tous les avantages du routage à vitesse filaire que le cœur peut m'offrir.

IIRC les commutateurs principaux peuvent faire 464 Gbps de routage tandis que mes routeurs frontaliers pourront offrir peut-être 10 ou 20 Gbps si j'ai de la chance. Ce n'est pas techniquement un problème en ce moment, mais plutôt un problème de croissance. J'ai l'impression que si nous ne concevons pas l'architecture pour tirer parti de la capacité de routage principale maintenant, il sera difficile de tout refaire lorsque nous serons plus grands et que nous devons tirer parti de cette capacité. Je préfère bien faire les choses la première fois.

Solutions possibles

Couche 3 pour accéder

J'ai pensé que je pourrais peut-être étendre L3 aux commutateurs d'accès, et ainsi diviser les règles de pare-feu en segments plus petits qui correspondraient alors aux limites matérielles des ACL des commutateurs d'accès. Mais:

Pour autant que je sache, ce ne seraient pas des ACL avec état
La L3 à Access, pour moi, semble beaucoup plus rigide. Les mouvements de serveur ou les migrations de VM vers d'autres armoires seraient plus douloureux.
Si je veux gérer un pare-feu en haut de chaque rack (seulement six d'entre eux), je veux probablement une automatisation de toute façon. À ce stade, il ne s'agit donc pas d'un bond en avant pour automatiser la gestion des pare-feu au niveau de l'hôte. Évitant ainsi tout le problème.

Pare-feu pontés / transparents sur chaque liaison montante entre accès / cœur

Cela devrait impliquer plusieurs boîtes de pare-feu et augmenter considérablement le matériel requis. Et pourrait finir par coûter plus cher que d'acheter de plus gros routeurs de base, même en utilisant de vieilles boîtes Linux simples comme pare-feu.

Routeurs de base géants

Pourrait acheter un appareil plus grand qui peut faire le pare-feu dont j'ai besoin et a une capacité de routage beaucoup plus grande. Mais je n'ai vraiment pas de budget pour cela, et si j'essaie de faire faire à un appareil quelque chose pour lequel il n'est pas conçu, je devrai probablement aller à une spécification beaucoup plus élevée. que je ne le ferais autrement.

Pas de pare-feu centralisé

Puisque je saute à travers des cerceaux, cela ne vaut peut-être pas la peine. Cela a toujours été une bonne chose d'avoir, et parfois un argument de vente pour les clients qui veulent un pare-feu "matériel".

Mais il semble qu'avoir un pare-feu centralisé pour l'ensemble de votre réseau est irréalisable. Je me demande, alors, comment les plus grands FAI peuvent offrir des solutions de pare-feu matériel aux clients avec des serveurs dédiés, alors qu'ils ont des centaines voire des milliers d'hôtes?

Quelqu'un peut-il penser à un moyen de résoudre ce problème? Soit quelque chose que j'ai complètement raté, soit une variation sur l'une des idées ci-dessus?

MISE À JOUR 2014-06-16:

Sur la base de la suggestion de @ Ron, je suis tombé sur cet article qui explique assez bien le problème auquel je suis confronté et un bon moyen de résoudre le problème.

À moins qu'il n'y ait d'autres suggestions, je dirais que c'est maintenant un type de problème de recommandation de produit, donc je suppose que c'est la fin.

http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/

routing firewall design Geekman
la source

Utilisez-vous VRF-lite ou MPLS dans le réseau? De quelle marque sont les commutateurs principaux?

Daniel Dib

@DanielDib N'utilisant pas encore de VRF ou de MPLS, mais je prévois de le déployer entre ce site et un autre site. La marque n'est pas encore définitive (toujours en train de trouver la liste d'achat) ... Mais en ce moment, je regarde principalement Juniper EX4300-32F ou Brocade ICX 6610-48-PE

Geekman

J'ai voté pour la fermeture; La raison en est que la question que vous posez plonge dans des détails très spécifiques pour votre solution tels que le fabricant / modèle à choisir et les contraintes budgétaires, etc., comment cela va changer votre offre de produits pour vos clients ... Tout cela ne convient pas ici , ce sont des décisions d'affaires. Vous pouvez demander quels sont les avantages et les inconvénients de chaque topologie, mais personne ne peut vraiment vous dire ce qui vous convient le mieux.

jwbensley

Mes deux pence sur votre situation sont; Avez-vous envisagé des pare-feu qui prennent en charge des contextes tels que Cisco ASA, ou simplement des pare-feu virtuels? Disposez de certains hôtes VM sur lesquels vous pouvez activer des pare-feu pour chaque client avec deux interfaces, une que vous déposez dans le VLAN du client comme passerelle par défaut et une que vous connectez à un VLAN public face à vos routeurs de périphérie. Juste une pensée (je préfère les pare-feu virtuels).

jwbensley

J'examinerais sérieusement les pare-feu virtualisés tels que Cisco ASA 1000V ou Catbird (catbird.com). De cette façon, vous pouvez placer un pare-feu sur chaque vserver. Gardez vos listes d'accès hors de votre routeur principal.

Ron Trunk

Je choisirais l'un des deux choix:

Pare-feu virtuels individuels par locataire

Avantages:

Évolutif horizontalement
Spin-up et spin-down
Relativement insensible aux changements futurs de topologie / conception
Séparation / isolation complète du client

Les inconvénients:

Sauf si vous appliquez un modèle standard, vous avez maintenant n pare-feu individuels à gérer
Vous avez maintenant n pare-feu individuels à surveiller
Vous avez maintenant n pare-feu individuels à patcher

Grand châssis / cluster de pare-feu avec une instance de routage / contexte par locataire

Déployez un grand pare-feu central (cluster) accroché au côté de votre cœur et utilisez une instance de routage interne et externe pour acheminer le trafic vers lui (par exemple: la passerelle par défaut sur l'instance interne est le pare-feu, la passerelle par défaut sur le pare-feu est votre instance externe sur le cœur et la valeur par défaut pour l'instance externe est votre ou vos bordures.)