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.
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?