Tentando ajustar o firewall centralizado na topologia de rede


11

Estou no processo de re-transportar nossa rede, o problema para o qual continuo voltando é: tentando trazer a camada 3 para o núcleo, enquanto ainda tenho um firewall centralizado.

O principal problema que tenho aqui é que os comutadores "mini core" que tenho observado sempre têm limites baixos de ACL no hardware, que mesmo em nosso tamanho atual poderíamos atingir rapidamente. No momento, estou prestes a (espero) comprar um par de EX4300-32Fs para o núcleo, mas observei outros modelos e outras opções da linha ICX da Juniper e Brocade. Todos eles parecem ter os mesmos limites baixos de ACL.

Isso faz todo o sentido, pois os comutadores principais precisam ser capazes de manter o roteamento da velocidade do fio, portanto, não querem sacrificar muito pelo processamento da ACL. Portanto, não posso fazer todo o meu firewall nos principais switches.

No entanto, a maioria dos servidores é totalmente gerenciado, e ter um firewall centralizado (com estado) ajuda muito nesse gerenciamento - pois não podemos ter clientes conversando diretamente entre si. Gostaria de mantê-lo assim, se pudermos, mas sinto que a maioria das redes de ISPs não faria esse tipo de coisa; portanto, na maioria dos casos, seria mais fácil fazer o roteamento no núcleo.

Para referência, aqui está a topologia que eu idealmente gostaria de fazer (mas não tenho certeza de onde encaixar o FW, obviamente).

rede

Solução atual

No momento, temos uma configuração de roteador no stick. Isso nos permite executar NAT, firewall stateful e roteamento de VLAN em um único local. Muito simples.

Eu poderia continuar com (aproximadamente) a mesma solução estendendo o L2 até o "topo" da nossa rede - os roteadores de borda. Mas, então, perco todos os benefícios do roteamento de velocidade do fio que o núcleo pode me oferecer.

No IIRC, os comutadores principais podem fazer 464 Gbps de roteamento, enquanto meus roteadores de borda poderão oferecer talvez 10 ou 20 Gbps, se tiver sorte. Tecnicamente, isso não é um problema agora, mas mais uma questão de crescimento. Sinto que, se não projetarmos a arquitetura para aproveitar agora a capacidade de roteamento principal, será doloroso refazer tudo quando formos maiores e precisarmos aproveitar essa capacidade. Prefiro acertar da primeira vez.

Soluções possíveis

Camada 3 para acessar

Pensei que talvez pudesse estender L3 aos comutadores de acesso e, assim, dividir as regras do firewall em segmentos menores que se ajustariam aos limites de hardware das ACLs dos comutadores de acesso. Mas:

  • Até onde eu sei, essas não seriam ACLs com estado
  • L3 para Access, para mim, parece muito mais inflexível. Movimentos do servidor ou migrações de VM para outros gabinetes seriam mais dolorosos.
  • Se eu estiver gerenciando um firewall na parte superior de cada rack (apenas seis), provavelmente quero a automação de qualquer maneira. Portanto, nesse ponto, não é um grande salto automatizar o gerenciamento de firewalls no nível do host. Evitando assim todo o problema.

Firewalls em ponte / transparentes em cada ligação entre acesso / núcleo

Isso teria que envolver várias caixas de firewall e aumentar significativamente o hardware necessário. E pode acabar custando mais caro do que comprar roteadores principais maiores, mesmo usando caixas Linux simples como firewalls.

Roteadores de núcleo gigante

Poderia comprar um dispositivo maior que possa executar o firewall necessário e que tenha uma capacidade de roteamento muito maior. Mas realmente não tenho orçamento para isso, e se estou tentando fazer um dispositivo fazer algo para o qual não foi projetado, provavelmente terei que ir a uma especificação muito mais alta. do que eu faria de outra maneira.

Nenhum firewall centralizado

Desde que eu estou pulando através de aros, talvez isso não valha o esforço. Sempre foi uma coisa agradável de se ter e, às vezes, um ponto de venda para clientes que desejam um firewall de "hardware".

Mas parece que ter um firewall centralizado para toda a sua rede é inviável. Pergunto-me, então, como os ISPs maiores podem oferecer soluções de firewall de hardware para clientes com servidores dedicados, quando eles têm centenas ou mesmo milhares de hosts?

Alguém pode pensar em uma maneira de resolver esse problema? Ou algo que eu perdi completamente, ou uma variação de uma das idéias acima?

ATUALIZAÇÃO 16-06-2014:

Com base na sugestão de @ Ron, me deparei com este artigo, que explica muito bem o problema que estou enfrentando e uma boa maneira de resolver o problema.

A menos que haja outras sugestões, eu diria que agora esse é um tipo de problema de recomendação de produto, portanto, suponho que esse seja o fim.

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


Você está usando VRF-lite ou MPLS na rede? Qual marca são os switches principais?
precisa

@DanielDib Ainda não estou usando VRFs ou MPLS, mas planejo implantá-lo entre este site e outro site. Marca não é definitivo ainda (ainda descobrir lista de compra) ... Mas agora olhando principalmente à Juniper EX4300-32F ou Brocade ICX 6610-48-PE
Geekman

1
Eu votei para fechar; O motivo é que a pergunta que você faz se aprofunda em detalhes muito específicos para sua solução, como qual fabricante / modelo escolher e restrições orçamentárias etc., como isso mudará sua oferta de produtos para seus clientes ... Tudo o que não é adequado aqui , essas são decisões de negócios. Você pode perguntar quais são os prós e os contras de cada topologia, mas ninguém pode realmente lhe dizer o que é melhor para você.
jwbensley

1
Meus dois pence na sua situação é; Você já pensou em firewalls que suportam contextos como Cisco ASAs ou apenas em ter firewalls virtuais? Tenha alguns hosts de VM nos quais você pode ativar firewalls para cada cliente com duas interfaces, uma que você insere na VLAN do cliente como gateway padrão e uma que você insere em uma VLAN voltada para o público em direção aos seus roteadores de borda. Apenas um pensamento (eu prefiro firewalls virtuais).
jwbensley

2
Eu consideraria seriamente firewalls virtualizados, como Cisco ASA 1000V ou Catbird (catbird.com). Dessa forma, você pode colocar um firewall em todos os vserver. Mantenha suas listas de acesso fora do seu roteador principal.
Ron Trunk

Respostas:


5

Eu escolheria uma das duas opções:

Firewalls virtuais individuais por inquilino

Prós:

  • Escalonável horizontalmente
  • Spin-up e spin-down
  • Relativamente imune a futuras alterações de topologia / design
  • Separação / isolamento completo do cliente

Contras:

  • A menos que você imponha um modelo padrão, agora você possui n firewalls individuais para gerenciar
  • Agora você possui n firewalls individuais para monitorar
  • Agora você tem n firewalls individuais para corrigir

Chassi / cluster de firewall grande com uma instância de roteamento / contexto por inquilino

Implante um firewall central (cluster) grande pendurado na lateral do seu núcleo e use uma instância de roteamento interna e externa para rotear o tráfego de volta para ele (por exemplo: gateway padrão em Instância interna é o firewall, gateway padrão em o firewall é sua instância externa no núcleo e o padrão para a instância externa é sua (s) borda (s).)

Prós:

  • Caixa única para gerenciar e configurar
  • Caixa única para monitorar
  • Caixa única para remendar
  • Separação do cliente

Contras:

  • O custo do primeiro dia será maior
  • Sem redução
  • Dependendo da configuração, o tráfego entre clientes pode começar a rotear pelos roteadores de borda

0

Quais switches principais você está executando? As políticas geralmente são feitas na camada de distribuição; se você optar por um design Core desmoronado, o núcleo poderá atender aos seus requisitos. Além disso, você está gostando de uma inspeção completa ou apenas de acls. Se você tem alguma conformidade que precisa seguir, acls pode não ser suficiente.

Pessoalmente, eu usaria um firewall, talvez procure um que possa ser agrupado em cluster para que você possa agrupar cada um e manter a base de regras gerenciada centralmente, como um firewall sourcefire.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.