Lavorare attorno a un limite di regole ACL della rete AWS

Al massimo, un ACL di rete VPC può avere 40 regole applicate.

Ho un elenco di oltre 50 indirizzi IP di cui ho bisogno per bloccare esplicitamente l'accesso nei nostri sistemi, su qualsiasi porta e qualsiasi protocollo. Questo è uno scopo ideale per un ACL, ma il limite mi sta impedendo di completare questo compito.

Naturalmente, posso farlo in IPTables su ciascun host, ma voglio bloccare tutto il traffico verso tutti i componenti nel VPC (ad esempio a ELB). Inoltre è molto più ideale gestire queste regole in un posto piuttosto che su ogni singolo host.

Spero che ci sia un modo in cui non capisco farlo a livello di sistema / piattaforma. I gruppi di sicurezza sono esplicitamente autorizzati, senza alcuna azione di rifiuto, quindi non faranno il trucco.

amazon-web-services access-control-list amazon-vpc

— emmdee
fonte

Utilizzare il software di provisioning come Ansible per la gestione di iptables e il gioco è fatto. Ovviamente funzionerà solo in istanze EC2; non LB ecc.

— Kyslik,

Sì, sono d'accordo che fare iptables vada bene per EC2, ma il 99% del mio traffico in entrata colpisce la nostra struttura ELB. Pagheremmo molti successi di questi noti truffatori con cui abbiamo a che fare. Grazie per l'input

— emmdee,

Il blocco di 50 IP individuali sembra un requisito strano.

— user253751

@immibis Odd per te forse. Riceviamo molti truffatori che cercano di fregare i nostri clienti legittimi. Blocciamo i loro account ma anche vietiamo completamente l'IP per ovvi truffatori russi / nigeriani / cinesi. Il nostro prodotto ha molte interazioni con l'utente, chat / ecc. - assolutamente non dispari per una piattaforma del genere.

— emmdee,

... e nessuno dei tuoi truffatori ha IP dinamici?

— user253751

Risposte:

Ecco un'idea per il campo a sinistra. È possibile "annullare il routing" dei 50 IP bloccati, aggiungendo un route "interrotto" alla tabella di route VPC per ciascun IP.

Ciò non impedirebbe al traffico proveniente dagli IP di colpire la tua infrastruttura (solo i NACL e gli SG lo impediranno), ma impedirà che il traffico di ritorno lo faccia tornare "a casa".

— Pinguino Funky
fonte

Una volta ho accidentalmente annullato il traffico di routing creando un gateway di transito, impostando il routing, quindi eliminando il gateway di transito. Potrebbe esserci un modo più semplice però.

— Tim

Non è una cattiva idea. Molto fuori dagli schemi pensando grazie. Farò un po 'di sperimentazione. Potrebbe essere la strada giusta da percorrere senza pagare per WAF

— emmdee,

Non è possibile aumentare il limite di NACL e un numero elevato di regole NACL influisce sulle prestazioni della rete.

Potresti avere soprattutto un problema di architettura.

Le tue istanze devono trovarsi in sottoreti pubbliche?
Hai impostato gateway NAT per limitare il traffico in entrata?
Per quelle istanze che devono trovarsi nelle sottoreti pubbliche hai regole minime per i gruppi di sicurezza in entrata?
Stai utilizzando le condizioni di corrispondenza IP AWS WAF per bloccare il traffico indesiderato verso CloudFront e i tuoi sistemi di bilanciamento del carico?

Se stai raggiungendo il limite della regola NACL è molto probabile perché non stai adottando l'approccio raccomandato da AWS all'architettura VPC e all'uso di servizi come WAF (e Shield for DDoS) per bloccare il traffico indesiderato e gli attacchi palesi.

Se il problema riguarda gli attacchi DDoS: come proteggere le applicazioni Web dinamiche dagli attacchi DDoS utilizzando Amazon CloudFront e Amazon Route 53

— Fo.
fonte

I gateway NAT sono destinati al traffico in uscita anziché in entrata.

— Tim

Corretto @Tim, quindi posizionare le tue istanze in sottoreti private dietro i gateway NAT offre loro una connettività in uscita senza aprirle agli attacchi in entrata e non è necessario bloccare gli IP nei NACL

— Fo.

WAF è piuttosto costoso per i siti Web a traffico molto elevato. Cercando di evitarlo per quel motivo. Il fatto che i gruppi di sicurezza non possano esplicitamente bloccare e l'ACL Web ha questo limite sembra proprio un grosso problema.

— emmdee,

Immagino che dipenda dal caso d'uso, che non è stato spiegato. Se il motivo per bloccare questi IP è che stanno attaccando un server web, deve comunque esserci un accesso pubblico ai server, il che significa un bilanciamento del carico o un proxy. Una sottorete privata non sarebbe d'aiuto in quel caso.

— Tim

Il mio caso d'uso è ELB del 99% che prende il traffico in entrata. Le istanze EC2 sono private dietro ELB.

— emmdee,

Questo non è esattamente quello che hai chiesto, ma può fare abbastanza bene il lavoro.

Imposta CloudFront di fronte alla tua infrastruttura. Utilizzare le condizioni di corrispondenza IP per bloccare efficacemente il traffico. CloudFront funziona con contenuti sia statici che dinamici e può accelerare i contenuti dinamici in quanto utilizza la struttura portante AWS anziché Internet pubblica. Ecco cosa dicono i documenti

Se si desidera consentire alcune richieste Web e bloccarne altre in base agli indirizzi IP da cui provengono le richieste, creare una condizione di corrispondenza IP per gli indirizzi IP che si desidera consentire e un'altra condizione di corrispondenza IP per gli indirizzi IP che si desidera bloccare .

Quando si utilizza CloudFront è necessario bloccare l'accesso diretto a qualsiasi risorsa pubblica utilizzando i gruppi di sicurezza. I gruppi di sicurezza di AWS Update Lambda manterranno aggiornati i tuoi gruppi di sicurezza per consentire il traffico CloudFront ma rifiutare altro traffico. Se reindirizzi http su https utilizzando CloudFront puoi modificare un po 'gli script per evitare che HTTP colpisca la tua infrastruttura. Puoi anche inserire nella whitelist tutti gli IP che richiedono l'accesso diretto all'amministratore.

In alternativa, è possibile utilizzare un CDN di terze parti come CloudFlare. CloudFlare ha un firewall efficace, ma per il numero di regole che desideri è di $ 200 al mese. Potrebbe essere più economico di CloudFront, la larghezza di banda di AWS è piuttosto costosa. Il piano gratuito ti dà solo 5 regole del firewall.

— Tim
fonte

Usiamo già il cloud front per i contenuti statici ma molti siti sono contenuti Web dinamici.

— emmdee,

CloudFront può essere utilizzato anche per contenuti dinamici aws.amazon.com/blogs/networking-and-content-delivery/…

— Fo.

CloudFront può accelerare i contenuti dinamici, credo che utilizzi la struttura portante di AWS anziché Internet pubblica. CloudFront ha una larghezza di banda leggermente più economica di EC2, e penso di aver visto un annuncio qualche tempo fa che la larghezza di banda CloudFront di nuovo su EC2 è gratuita.

— Tim