Por que colocar o Load-Balancer atrás do firewall?

Question

Estou pensando em adquirir um dispositivo de balanceamento de carga F5 que direcionará as conexões HTTP de entrada para um dos cinco servidores da Web na minha rede interna. Minha suposição era de que a interface externa da F5 enfrentaria a Internet e a interface interna enfrentaria a rede interna em que os servidores da web residem. No entanto, várias das ilustrações que estou vendo on-line colocam o dispositivo F5 por trás do firewall. Essa organização faria com que o tráfego extra passasse pelo firewall e também tornasse o firewall um único ponto de falha, correto?

Qual é a razão por trás dessa configuração?

    

Answer 1

Eu acho que o clássico:

Firewall <-> Load Balancer <-> Web Servers <-> ...

é em grande parte remanescente da era dos firewalls caros baseados em hardware. Eu implementei esses esquemas para que funcionem, mas torna toda a configuração mais complicada. Para eliminar pontos únicos de falha (e, por exemplo, permitir atualizações do firewall), é necessário que você faça malha de tráfego entre dois firewalls e dois balanceadores de carga (usando malhas de camada 2 ou o roteamento adequado de camada 3).

Em nuvens públicas, tende-se a implementar algo como:

Load Balancer <-> [ (firewall + web) ] <-layer 2 domain or ipsec/ssl-> [ (firewall + app/db) ]

que é francamente bom o suficiente.

1. Se você estiver usando o balanceador de carga para encerrar a conexão SSL, um firewall colocado na frente do balanceador de carga só faz a filtragem básica da camada 3, pois está vendo o tráfego criptografado.
2. Seu F5 já vem com um firewall, que é tão bom quanto as regras de filtragem que você coloca em prática.
3. O argumento de defesa em profundidade é IMHO fraco quando se trata da camada 3. Os vetores de ataque para aplicativos da Web são injeções de SQL, não acionando o firewall para obter acesso root.
4. Os núcleos de servidores Web insignificantes geralmente são bons o suficiente para lidar com filtragem de tcp e para cima.

Feliz por ver algumas discussões sobre o assunto.

    

Answer 2

Eu teria pensado que isso seria evidente: a mesma razão pela qual você coloca qualquer coisa atrás do firewall.

    

Answer 3

O raciocínio é ter o firewall para proteger os servidores da web. Nesse caso, o ponto dos balanceadores de carga é garantir que os servidores da Web não sejam um único ponto de falha e balancear a carga entre eles. Se houver apenas um firewall, ele será aceito como um único ponto de falha.

    

Answer 4

Eu não diria que há tráfego "extra" viajando por esse firewall.

Se você tiver 5.000 solicitações de entrada e enviar até 1.000 solicitações para cada servidor, não haverá mais solicitações sendo atendidas pelo firewall do que se você enviasse 5.000 solicitações para o único servidor ou se você colocasse o firewall atrás do servidor. F5 (todas as 5.000 solicitações ainda precisam passar por esse firewall em algum momento, caso contrário, elas não estão em uma rede "privada").

Mas é verdade que o firewall é um ponto único de falha, mas se você está gastando o orçamento para comprar uma única F5, então a F5 também se torna um ponto único de falha.

Se você estiver configurado para configurar um sistema totalmente redundante, precisará de duas F5s em um cluster de HA ativo / passivo e, em seguida, terá dois firewalls, também em um cluster de HA ativo / passivo.

Eles podem ser representados por um único gráfico na documentação do F5, mas isso é apenas mostrando a aparência lógica do firewall (há um dispositivo atendendo a todos os pedidos), não a configuração física (dois dispositivos, um deles em Espera de HA).

Outro motivo para colocar o seu balanceador de carga atrás do firewall é que o balanceador de carga não pode ser protegido por padrão (talvez ele tenha vulnerabilidades em suas interfaces de gerenciamento, talvez o padrão permita, quem sabe). Ao colocá-lo atrás do firewall e apenas abrir brechas para suas portas publicamente necessárias, você corre um risco muito menor de um balanceador de carga vulnerável ser exposto à Internet.

    

Answer 5

Normalmente, você quer seu balanceador de carga e servidores da Web em uma zona desmilitarizada (DMZ, De-Militarized Zone). O acesso ao DMZ das redes internas e externas deve ser controlado pelo firewall. Se o balanceador de carga estiver na frente do firewall, ele não conseguirá equilibrar essas duas cargas.

Como outros postaram, tanto o firewall quanto o balanceador de carga serão um único ponto de falha, a menos que você tenha um equipamento redundante.

    

Answer 6

Francamente, é para apaziguar os seguranças que precisam apenas de um firewall separado. O módulo bigip asm pode substituir um firewall. combine isso com políticas de firewall e ipsec nos servidores e um firewall por trás e você terá um sistema seguro.

    

Answer 7

Desconfiar, o inet, apenas toca o firewall, que só passa por tráfego específico.

Todo o resto fica atrás do firewall.

É assim que é feito. O firewall é considerado "difícil" e seguro de ser exposto a desconfiados. Todo o resto é considerado necessitado de abrigo ...

    

Answer 8

É comum visualizar implementações de segurança como um conjunto de camadas individuais de segurança, geralmente chamado de modelo de segurança em camadas.

No mais simples dos termos, cada camada de segurança que deve ser atravessada contribui com uma resistência adicional contra a penetração - cada camada aumentando a dificuldade total na qual um invasor pode obter acesso não autorizado.

Para mim, sempre pareceu bastante sensato ter habilidades de detecção, prevenção e filtragem na Internet, por várias razões - e no contexto da segurança em camadas, acho que faz todo o sentido ter um pacote inspecionando firewall como sua primeira linha de defesa - esse dispositivo tem a vantagem adicional de poder se defender contra ataques direcionados ao ADC ou outro equipamento de rede voltado para a Internet.

Como exemplo para ilustrar meu ponto; Considere como um firewall externo (de borda) está bem posicionado para verificar a conformidade do protocolo antes que o tráfego possa entrar em sua rede, ou seja, antes que possa ser passado para dispositivos potencialmente vulneráveis. O firewall também pode procurar variações e padrões no tráfego que estejam em conformidade com as especificações técnicas, mas desviem-se do uso típico ou prática comum - isso aumenta a chance de descobrir fluxos de dados ocultos, tentativas de contornar postos de controle ou até mesmo novas instalações para contrabando de solicitações.

Um design Web / SaaS típico, embora um pouco simplificado, pode ser parecido com:

1. Internet pública
2. Firewall SPI (Cisco ASA, Fortigate)
3. Load Balancer / ADC / WAF ** termo SSL / TLS. ponto ** (como Big-IP, Baracuda)
4. Firewall de próxima geração (como PaloAlto, CheckPoint)
5. Serviços de aplicativos web
6. Firewall baseado em porta (como um Cisco ASA de baixo custo ou até mesmo iptables)
7. Serviços de banco de dados e armazenamento

A redundância pode ser adicionada a cada componente individual, conforme necessário.

Pessoalmente, prefiro a redundância local para firewalls (por exemplo, 2 nós por firewall por site), mesmo se os balanceadores de carga forem implantados para alta disponibilidade global ou failover de site (requer apenas um Big IP por site).

    

Answer 9

O BIG-IP é um firewall certificado pela ICSA. Para entrada nos casos de uso do datacenter, pode fazer sentido que o BIG-IP funcione como um firewall. A plataforma BIG-IP geralmente é muito mais alta do que outros firewalls comerciais e suporta o descarregamento de SSL para inspeção de conteúdo. Como Jim B mencionou, você também pode adicionar o firewall de aplicativos da Web BIG-IP ASM para proteger aplicativos da Web.

Firewall de entrega de aplicativos de alto desempenho

link

Aaron