Nega l'indirizzo IP su ELB AWS

Ho, più o meno, la seguente configurazione su AWS:

Bilanciamento del carico elastico con 3 macchine o 3 diverse zone di disponibilità. Il mio gruppo di sicurezza consente 0.0.0.0/0:80 in quanto è la mia applicazione rails (nginx, unicorno).

Mi chiedevo se c'è modo di negare l'accesso alla mia app a un indirizzo IP pubblico specifico? Ho letto la documentazione di AWS, ma dato che gli SG "negano tutto" non c'è modo di negare un solo indirizzo IP specifico.

Qualche idea? iptables sulle 3 macchine dietro il bilanciamento del carico?

Grazie!

Una soluzione semplice consiste nell'utilizzare una regola in entrata ACL della rete VPC. Funziona solo se il tuo ELB è in un VPC, ma se l'hai creato negli ultimi anni dovrebbe essere in quello predefinito.

Per vietare 1.2.3.4 ad esempio, attenere alla seguente procedura:

1. Accedi ad AWS.
2. Vai a VPC.
3. Scegli Network ACLsdal menu a sinistra.
4. Scegli l'ACL associato al VPC in cui si trova ELB.
5. Scegli la Inbound Rulesscheda
6. Scegli Edite aggiungi una nuova regola con i seguenti attributi:
   • Regola #: 50 (qualsiasi numero purché sia ​​inferiore alla regola che CONSENTE da TUTTO)
   • Tipo: TUTTO il traffico
   • Protocollo: ALL
   • Port Range: TUTTI
   • Fonte: 1.2.3.4/32
   • Consenti / Nega: DENY

Ci sono molte altre informazioni sugli ACL di rete qui: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html

No, non esiste alcuna opzione per bloccare gli IP con il gruppo di sicurezza.

Il gruppo di sicurezza è essenzialmente una lista bianca, anziché una lista nera.

Tutto è negato per impostazione predefinita e puoi aprire selettivamente le porte in base alle tue necessità, ma non puoi bloccare persone / ip specifiche.

Per questo, la soluzione migliore è, come hai detto, IPtables su 3 diverse macchine.

Sono sicuro che anche i gruppi di sicurezza AWS avranno questa funzionalità, ma non per ora.

Se devi solo inserire nella lista nera alcuni IP, probabilmente potresti utilizzare nginx_http_access_module sul tuo server web.

Per questo, la soluzione migliore è, come hai detto, IPtables su 3 diverse macchine.

In realtà, questa non è una buona soluzione poiché l'ip remoto ( $remote_addrin Nginx) verrà dal bilanciamento del carico di Amazon. Vietare ciò comporterà la proibizione di tutto il traffico inoltrato.

Dovrai ispezionare i pacchetti e trovare l' X-Forwarded-Forintestazione HTTP , IPtables non è consapevole del protocollo in quel modo.

Ho optato per la seguente soluzione a 2 IP cattivi in ​​Nginx

set $client_ip $remote_addr;
if ($http_x_forwarded_for) {
  set $client_ip $http_x_forwarded_for;
}

if ($client_ip = "123.123.123.123") {
  return 403;
}

if ($client_ip = "123.123.123.234") {
  return 403;
}

Presentazione di una variabile $client_ip, solo per poterla testare localmente, dove non è http_x_forwarded_fordisponibile.

Leggermente offtopico ma pubblicando per comodità, ho anche aggiunto l'ip client ai miei registri di accesso:

log_format main "\$client_ip - \$remote_user [\$time_local] \"\$request\" \$status \$body_bytes_sent \"\$http_referer\" \"\$http_user_agent\"";
access_log /var/log/nginx.access.log main;

Non è carino, ma spero che aiuti