Arquitetura do AWS WebServer (ELB + iptables)

2

Atualmente, estou trabalhando na arquitetura do site de alta disponibilidade de alto tráfego.

Estamos usando o AWS.

Atualmente, temos:

Rota 53 - > ELB - > Várias instâncias do EC2 - > RDS Multi AZ.

Cada instância do EC2 executa o Varnish + Nginx & PHP FCI. Sessões e outros dados compartilhados são armazenados via ElastiCache.

Planejamos executar o Varnish e o Nginx em cada instância do EC2, pois isso nos permite reduzir os pontos de falha e simplesmente executar instâncias extras se a carga aumentar.

No entanto, temos que adicionar iptables (fail2ban) a isso. Obviamente, obtemos o IP do ELB em vez do IP do cliente real ...

Pensamos nas seguintes soluções:

1) Adicione uma instância do EC2 entre o Route 53 e o ELB, executando iptables / firewalls (e talvez verniz?) e encaminhando tudo para o ELB.

2) Substitua o ELB por um EC2 personalizado executando HAProxy + iptables.

3) Use mod_security e construa algumas coisas personalizadas para IPs de lista negra dinamicamente

4) Continue com a arquitetura atual e remova iptables da nossa lista de tarefas.

Qual seria uma boa abordagem?

Obrigado

    
por Benjamin Leclerc 05.02.2014 / 11:20

1 resposta

4

x-forwarded-for header

Of course, we get the IP of the ELB instead of the real client ip...

Você vai querer usar o cabeçalho x-forwarded-for, que lhe dará o ip do cliente.

link

The X-Forwarded-For request header helps you identify the IP address of a client when you use HTTP/HTTPS load balancer.

Veja algumas outras coisas que você pode estar interessado ...

Grupos de segurança & ACLs de rede

A AWS fornece dois ótimos recursos de segurança que operam na mesma área que o iptables:

  • Grupos de segurança
  • ACLs de rede

Grupos de segurança (pense na substituição do iptables) permitem que você permita / negue o tráfego com base no ip e na porta. Existem outras características em torno do fornecimento de outro recurso da AWS no lugar de um endereço IP.

As ACLs de rede oferecem mais controle sobre sua rede. Você pode permitir / negar o tráfego com base em ip e porta dentro e entre sub-redes dentro de sua VPC.

Segurança da AWS

  • Se você estiver usando o VPC, poderá colocar itens como EC2s em sub-redes particulares.
  • Os ELBs que precisam ser voltados para o público podem ter apenas os itens essenciais expostos (443, 80).
  • Você pode bloquear serviços como o SSH para uma lista de permissões de IPs.
  • Se você tiver um aplicativo com uma interface da web para administração, poderá bloqueá-lo no nível do servidor da web para se proteger contra qualquer vulnerabilidade no nível do software.

Adicionando sua própria segurança ao EC2s

Se você quiser adicionar medidas de segurança adicionais aos seus EC2s (como o fail2ban) e estiver usando vários EC2s atrás de um balanceador de carga, será necessário projetar seus EC2s para que eles não tenham dados exclusivos. neles (não adianta adicionar uma regra o EC2 # 1 se não estiver no EC2 # 2).

Existem técnicas para manter os EC2s em sincronia uns com os outros, como armazenar dados no S3, extrair o gerenciamento de configurações de um mestre ou extrair conteúdo do mesmo repositório. Usando imagens douradas junto com scripts de bootstrap (que extraem dados do S3).

Respostas às suas perguntas

1) Add an EC2 instance between Route 53 and ELB, running iptables/firewalls (and maybe varnish ?) and forwarding everything to ELB.

Adicionar uma instância do EC2 na frente do seu ELB diminuirá sua capacidade de escalar. Você também cria um ponto único de falha, então você provavelmente não quer fazer isso.

2) Replace ELB by a custom EC2 running HAProxy + iptables.

Você pode fazer isso, mas isso acontece com o custo de gerenciar você mesmo. Você se torna responsável pelo software, segurança, atualizações, disponibilidade, etc. Você quer evitar isso, se possível (ou seja, faça isso apenas se não puder resolver o problema usando um ELB).

3) Use mod_security and build some custom stuff to dynamically blacklist IPs

Esta é uma opção, mas você pode querer gerenciar a segurança no nível do SO / Rede, não (apenas) no nível do aplicativo / software.

4) Stick with the current architecture and remove iptables from our todo-list.

Claro que é uma opção, mas é aceitável para o negócio / projeto?

    
por 05.02.2014 / 13:09