Obejście limitu reguł ACL sieci AWS

Maksymalnie do listy ACL sieci VPC można zastosować 40 reguł.

Mam listę ponad 50 adresów IP, które muszę jawnie zablokować dostęp w naszych systemach, za pośrednictwem dowolnego portu i dowolnego protokołu. Jest to idealny cel dla listy ACL, ale limit utrudnia mi wykonanie tego zadania.

Oczywiście mogę to zrobić w IPTables na każdym hoście, ale chcę zablokować cały ruch do wszystkich komponentów VPC (na przykład do ELB). Ponadto o wiele bardziej idealne jest zarządzanie tymi regułami w jednym miejscu, a nie na każdym hoście.

Mam nadzieję, że jest jakiś sposób, którego nie rozumiem, robiąc to na poziomie systemu / platformy. Grupy zabezpieczeń są wyraźnie dozwolone, bez akcji odmowy, więc nie zrobią tego.

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

— emmdee
źródło

Użyj oprogramowania do obsługi administracyjnej, takiego jak Ansible, do zarządzania iptables i gotowe. Oczywiście będzie działać tylko w instancjach EC2; nie LB itp.

— Kyslik

Tak, zgadzam się, że iptables jest w porządku dla EC2, ale 99% mojego ruchu przychodzącego uderza w naszą strukturę ELB. Płacilibyśmy za wiele trafień od tych znanych oszustów, z którymi mamy do czynienia. Dzięki za wkład

— emmdee

Blokowanie 50 pojedynczych adresów IP wydaje się dziwnym wymogiem.

— user253751

... i żaden z twoich oszustów nie ma dynamicznych adresów IP?

— user253751

Czasami trzyma je na dystans, a czasem nie. Jest to praktyka biznesowa, która sprawdziła się w praktyce przez większość czasu, więc nie ma powodu, aby przestać blokować adresy IP bez względu na to, jakie są Twoje opinie. Wygląda na to, że 9 głosów poparcia w ciągu 16 godzin, kiedy to pytanie jest żywe, dowodzi, że nie jest to szalona prośba. Trzymaj tę dumę z jakiegoś powodu.

— emmdee

Odpowiedzi:

Oto pomysł na lewe pole .. możesz „zerować trasę” 50 zablokowanych adresów IP, dodając „uszkodzoną” trasę do tabeli tras VPC dla każdego adresu IP.

Nie zapobiegnie to ruchowi z adresów IP uderzającemu w twoją infrastrukturę (tylko NACL i SG to zapobiegną), ale zapobiegnie ruchowi powrotnemu z każdego „powrotu do domu”.

— Funky Penguin
źródło

Przypadkowo zerowałem ruch, tworząc bramę tranzytową, konfigurując routing, a następnie usuwając bramę tranzytową. Może być jednak łatwiejszy sposób.

— Tim

Niezły pomysł. Bardzo gotowe myślenie dzięki. Zrobię eksperymenty. Może to być właściwa droga bez płacenia za WAF

— emmdee

Nie ma sposobu na zwiększenie limitu NACL, a duża liczba reguł NACL wpływa na wydajność sieci.

Przede wszystkim możesz mieć problem architektoniczny.

Czy Twoje instancje muszą znajdować się w publicznych podsieciach?
Czy skonfigurowałeś bramy NAT, aby ograniczyć ruch przychodzący?
Czy w przypadku instancji, które muszą znajdować się w podsieciach publicznych, masz minimalne reguły grupy zabezpieczeń dla ruchu przychodzącego?
Czy używasz warunków dopasowania AWS WAF IP do blokowania niechcianego ruchu do CloudFront i urządzeń równoważących obciążenie?

Jeśli osiągasz limit reguł NACL, jest to najprawdopodobniej dlatego, że nie stosujesz zalecanego przez AWS podejścia do architektury VPC i korzystania z usług takich jak WAF (i Shield for DDoS) w celu blokowania niepożądanego ruchu i jawnych ataków.

Jeśli martwisz się atakami DDoS: jak chronić dynamiczne aplikacje internetowe przed atakami DDoS za pomocą Amazon CloudFront i Amazon Route 53

— Fo.
źródło

Bramy NAT są przeznaczone dla ruchu wychodzącego, a nie przychodzącego.

— Tim

Prawidłowe @Tim, więc umieszczanie instancji w prywatnych podsieciach za bramami NAT zapewnia im łączność wychodzącą bez otwierania ich na ataki przychodzące i nie ma potrzeby blokowania adresów IP w NACL

— Fo.

WAF jest dość drogi w przypadku witryn o bardzo dużym ruchu. Z tego powodu staram się tego unikać. Fakt, że grupy zabezpieczeń nie mogą jawnie blokować i ACL sieci ma ten limit, wydaje się być poważnym chwytem gotówki.

— emmdee

Myślę, że to zależy od przypadku użycia, który nie został wyjaśniony. Jeśli powodem zablokowania tych adresów IP jest to, że atakują one serwer WWW, nadal musi istnieć publiczny dostęp do serwerów, co oznacza moduł równoważenia obciążenia lub serwer proxy. W takim przypadku podsieć prywatna nie pomogłaby.

— Tim

Mój przypadek użycia to 99% ELB przejmuje ruch przychodzący. Instancje EC2 są prywatne za ELB.

— emmdee

Nie jest to dokładnie to, o co prosiłeś, ale może dobrze wykonać zadanie.

Skonfiguruj CloudFront przed swoją infrastrukturą. Użyj warunków dopasowania IP, aby skutecznie blokować ruch. CloudFront działa zarówno z zawartością statyczną, jak i dynamiczną i może przyspieszać zawartość dynamiczną, ponieważ wykorzystuje szkielet AWS, a nie publiczny Internet. Oto, co mówią lekarze

Jeśli chcesz zezwolić na niektóre żądania sieciowe i blokować inne na podstawie adresów IP, z których pochodzą żądania, utwórz warunek dopasowania IP dla adresów IP, na które chcesz zezwolić, i inny warunek dopasowania IP dla adresów IP, które chcesz zablokować .

Korzystając z CloudFront, powinieneś blokować bezpośredni dostęp do wszelkich zasobów publicznych za pomocą grup zabezpieczeń. AWS Aktualizacja zabezpieczeń Grupy lambda zachowa swoje grupy zabezpieczeń na bieżąco, aby umożliwić ruch w CloudFront ale odrzucają innego ruchu. Jeśli przekierujesz http na https za pomocą CloudFront, możesz nieco ulepszyć skrypty, aby http nie uderzył w twoją infrastrukturę. Możesz także dodać do białej listy dowolne adresy IP, które wymagają bezpośredniego dostępu administratora.

Alternatywnie możesz użyć CDN innej firmy, takiej jak CloudFlare. CloudFlare ma skuteczną zaporę ogniową, ale dla wielu reguł chcesz 200 USD miesięcznie. To może być tańsze niż CloudFront, przepustowość AWS jest dość droga. Bezpłatny plan daje tylko 5 reguł zapory.

— Tim
źródło

Już korzystamy z chmury dla treści statycznych, ale wiele stron to dynamiczne treści internetowe.

— emmdee

CloudFront może być również używany do dynamicznej zawartości aws.amazon.com/blogs/networking-and-content-delivery/…

— Fo.

CloudFront może przyspieszać dynamiczne treści, uważam, że wykorzystuje szkielet AWS zamiast publicznego Internetu. CloudFront ma nieco tańszą przepustowość niż EC2, i myślę, że widziałem już kiedyś informację, że przepustowość CloudFront z powrotem do EC2 jest bezpłatna.

— Tim