Jak ochronić ASA-SM przed atakiem na liczbę pakietów/sekundę

[debianek]

Witam,

drugi już raz w tym miesiącu klęknęła nam ASA-SM przy ataku z internetu.

Atak wygenerował ponad 650tyś pakietów/sekundę, liczba połączeń wzrosła do prawie 10mln i RAM został zajęty prawie w 100%, CPU też 100%.

Jedyne co pomogło to wyłączenie portu na styku z internetem.

Styk z operatorem mam 1Gb/s, zwykle wykorzystany w ok 30-40%, pps w trakcie normalnej pracy jest na poziomie 50-100tyś.

Teraz moja prośba o porade - jak ochronić ASA-SM przed atakiem na liczbę pakietów?
Z przodu ASA-SM mogę postawić 6500. Czy można zrobić QoS na 6500 ograniczające liczbę pakietów/sekundę przechodzącą przez port fizyczny albo SVI?

Operator stwierdził, że nie jest w stanie u siebie nałożyć na porcie do mnie takiego ograniczenia.

[balam]

Taki atak do ochrony to w sumie tylko z wykupiona usluga od operatora - anty DDoS - przynajmniej 2 juz oferuje.

[tomiabc]

czy to były pakiety TCP SYN?
http://www.cisco.com/c/en/us/td/docs/se ... imits.html

[debianek]

czy to były pakiety TCP SYN?
http://www.cisco.com/c/en/us/td/docs/se ... imits.html

Nie, tym razem sam ruch UDP.


Ma ustawione limity połączeń per IP na ASA-SM od strony internetu, ale bardziej chcaiłbym zapodać sobie QoS na liczbę pakietów/sekundę na 6500 i zapomnieć o problemie, bo jak zakładam, 6500 (sup720-3b) nawet by takiego wolumenu ruchu nie zauważył.

[Kyniu]

Nie, tym razem sam ruch UDP.

Ostatnio popularny się zrobił atak UDP amplification z użyciem serwerów NTP. Dla zainteresowanych podobno największy dotychczasowy DDoS "400Gbps NTP Amplification DDoS Attack" http://blog.cloudflare.com/technical-de ... dos-attack

[lbromirs]

Firewalle stanowe nie służą do ochrony przed DDoSami. To, że ich producenci o tym zapewniają, jest problemem tych producentów. Cisco tego nie robi i nie sugeruje.

Ustaw sobie CARa na SYN (i fragmenty) przed wejściem w stronę ASA, przy czym dobrze byłoby to zmieniać w zależności od sytuacji - wiele więcej jako odbiorca floodu nie zrobisz. Dostałeś ruchem UDP, więc poza oczywistymi oczywistościami (uRPF/etc) zapewne dobrze jest też na wejściu zrobić twardy rate-limit UDP na poszczególne, używane w firmie porty z wartościami oddającymi normalne wykorzystanie w frimie. W połączeniu z BGP i qos-groupami możesz tu sobie przez BGP sterować konkretną wartością policingu (BGP zapinasz wtedy na Supie 6500 oczywiście). Swoją drogą dobrze jest sam moduł też podtuningować, bo on wytrzyma dużo - odsyłam do prezentacji z Cisco Live (zaawansowany troubleshooting firewalli Cisco).

[Wolf]

czy to były pakiety TCP SYN?
http://www.cisco.com/c/en/us/td/docs/se ... imits.html

Nie, tym razem sam ruch UDP.


Ma ustawione limity połączeń per IP na ASA-SM od strony internetu, ale bardziej chcaiłbym zapodać sobie QoS na liczbę pakietów/sekundę na 6500 i zapomnieć o problemie, bo jak zakładam, 6500 (sup720-3b) nawet by takiego wolumenu ruchu nie zauważył.

To nie takie proste jak Ci się wydaje... o DoS'ach nie da się od tak zapomnieć Jaki masz timeout ustawiony na połaczenia UDP na ASA? Jak domyślne 2min to raczej tu zacząłbym szukać. Przy dosyć niwielkim rate nowych połaczeń, jesli będą one usuwane z tablicy połaczeń dopiero po 2 minutach, to zapełnienie 10mln tablicy nie jest bardzo dużym problemem.

Pozatym puszczanie UDP przez FW na styku z internetem to proszenie się o kłopoty...
To był atak na UDP/53? Ile ASA dała radę zrobić nowych połaczeń/s dla tego UDP?
Nie zdarzyło ci się że się zrestartował któryś moduł lub nastąpiło przełączenie failover? Bo ja znam jeden taki klaster 5585x z SSP60 co przy strzale potrafi się nawet zrestartować, a przełączenie klastra to norma....

[debianek]

[...] Ustaw sobie CARa na SYN (i fragmenty) przed wejściem w stronę ASA, przy czym dobrze byłoby to zmieniać w zależności od sytuacji - wiele więcej jako odbiorca floodu nie zrobisz.

Problem jest taki, że port do operatora mam w trybie TRUNK, bo oprócz VLANu do typowego INTERNETU jest tam jeszcze kilka innych usług.
Gdzie mam ustawić tego CARa? Na porcie na 6500, którym jestem podłączony do operatora?

Dostałeś ruchem UDP, więc poza oczywistymi oczywistościami (uRPF/etc) zapewne dobrze jest też na wejściu zrobić twardy rate-limit UDP na poszczególne, używane w firmie porty z wartościami oddającymi normalne wykorzystanie w frimie.

Znowu to samo pytanie: gdzie te rate-limity UDP ustawić, na ASA-SM czy na 6500?

W połączeniu z BGP i qos-groupami możesz tu sobie przez BGP sterować konkretną wartością policingu (BGP zapinasz wtedy na Supie 6500 oczywiście).

Nie mam BGP, tylko zwykły static na bramę domyślną u operatora. Mam z operatorem dwa łącza ale redundancje zapewnia mi VRRP (ISP) i HSRP (ja).

Swoją drogą dobrze jest sam moduł też podtuningować, bo on wytrzyma dużo - odsyłam do prezentacji z Cisco Live (zaawansowany troubleshooting firewalli Cisco).

Też myślałem, że dużo wytrzyma, ale jak widać i tak nie daje rady. Z kiedy ta prezentacja, z najnowszego Cisco Live czy jakaś starsza?

[...]To nie takie proste jak Ci się wydaje... o DoS'ach nie da się od tak zapomnieć Jaki masz timeout ustawiony na połaczenia UDP na ASA? Jak domyślne 2min to raczej tu zacząłbym szukać. Przy dosyć niwielkim rate nowych połaczeń, jesli będą one usuwane z tablicy połaczeń dopiero po 2 minutach, to zapełnienie 10mln tablicy nie jest bardzo dużym problemem.

No to fakt, te domyślne 2 min to bardzo dużo. Jakie jest sensowniejsze, praktycznie ustawienie?

Pozatym puszczanie UDP przez FW na styku z internetem to proszenie się o kłopoty...
To był atak na UDP/53? Ile ASA dała radę zrobić nowych połaczeń/s dla tego UDP?
Nie zdarzyło ci się że się zrestartował któryś moduł lub nastąpiło przełączenie failover? Bo ja znam jeden taki klaster 5585x z SSP60 co przy strzale potrafi się nawet zrestartować, a przełączenie klastra to norma....

Operator wyliczył mi, że dostałem około 3.5 miliona pakietów w ciągu 5 minut:
> rekordzista w przedziale 5 minutowym - 3.5 miliona pakietów:
> Proto Src IP Addr:Port Dst IP Addr:Port Tos Packets
> UDP 92.247.177.228:123 -> xx.xx.xx.xx:80 16 3.5 M 1.6 G

Co do restartu to moduły pracowały cały czas, nie zrestartowały się. Przełączanie klastra za to zaobserwowałem. ASA-SM prostu przestała przenosić ruch na wszystkich kontekstach.
Położenie portu do strony ISP rozwiązało problem, atak ustał, moduły wróciły do życia.

Co do reguł puszczania ruchu UDP na styku z ISP to nic na to nie poradzę niestety (polityka firmy/wolność akademicka itp - niepotrzebne skreślić).

[tomiabc]

czemu twój operator nie wytnie ruchu UDP do tego hosta?

[debianek]

czemu twój operator nie wytnie ruchu UDP do tego hosta?

No wycina hosty, które mnie atakują, ale to jest ręczna rzeźba i po fakcie, czyli po tym jak już mnie dośc skutecznie atak zaboli.

Aha, operatora nie moge zmienić jakby co

[lbromirs]

[...] Ustaw sobie CARa na SYN (i fragmenty) przed wejściem w stronę ASA, przy czym dobrze byłoby to zmieniać w zależności od sytuacji - wiele więcej jako odbiorca floodu nie zrobisz.

Problem jest taki, że port do operatora mam w trybie TRUNK, bo oprócz VLANu do typowego INTERNETU jest tam jeszcze kilka innych usług.
Gdzie mam ustawić tego CARa? Na porcie na 6500, którym jestem podłączony do operatora?

Tak, przez MQC na porcie trunk. Złap VLAN id, a potem ACLką zrób limit osobno na TCP SYN i osobno na UDP na porty, które w ogóle wpuszczasz do środka.

Znowu to samo pytanie: gdzie te rate-limity UDP ustawić, na ASA-SM czy na 6500?

Zawsze najpierw na tym, co zrobi to sprzętowo. Na ASA możesz też te limity zakładać, ale będą one obciążać już kompleks procesorów, a nie krzem w 6500.

Też myślałem, że dużo wytrzyma, ale jak widać i tak nie daje rady. Z kiedy ta prezentacja, z najnowszego Cisco Live czy jakaś starsza?

Jak poszukasz sesji o tytule podanym, znajdziesz. Nie mam teraz konkretnego linku pod ręką.

Pozatym puszczanie UDP przez FW na styku z internetem to proszenie się o kłopoty...
To był atak na UDP/53? Ile ASA dała radę zrobić nowych połaczeń/s dla tego UDP?
Nie zdarzyło ci się że się zrestartował któryś moduł lub nastąpiło przełączenie failover? Bo ja znam jeden taki klaster 5585x z SSP60 co przy strzale potrafi się nawet zrestartować, a przełączenie klastra to norma....

Operator wyliczył mi, że dostałem około 3.5 miliona pakietów w ciągu 5 minut:
> rekordzista w przedziale 5 minutowym - 3.5 miliona pakietów:
> Proto Src IP Addr:Port Dst IP Addr:Port Tos Packets
> UDP 92.247.177.228:123 -> xx.xx.xx.xx:80 16 3.5 M 1.6 G

Po co w ogóle wpuszczać UDP na port 80? Odfiltruj ten syf ZANIM dotrzesz do urządzenia, które musi pracowicie pamiętać stany dla tego typu połączeń.

[debianek]

Po co w ogóle wpuszczać UDP na port 80? Odfiltruj ten syf ZANIM dotrzesz do urządzenia, które musi pracowicie pamiętać stany dla tego typu połączeń.

Ciężko to wytłumaczyć (i rozumiem, że większość będzie uważała to za wprost niepawdopodobne i śmieszne) ale taka jest "polityka firmy" (instytucja edukacyjna/akademicka) - wpuszczamy wszystko, co by ruchu "akademickiego/naukowego/grantowego/badawczego" przypadkiem nie ograniczyć.

Wiem, że efekty takiego podejścia dają się teraz we znaki ale takie mam realia niestety.
Tak naprawdę to zabezpieczona jest jedynie infrastruktura typowo administracyjna (nie naukowa).

Co do filtrowania ruchu jeszcze przed ASA to chyba coś nie tak.
Rozumiem, że switch, że ASICi, że szybciej itp ale nie po to chyba mam ASA, stanowy firewall, abym miał się jeszcze "użerać" z ACLkami na switchu.
Jak mam robić ACL na switchu to do czego mi ta ASA ma służyć (VPN/NAT jest na czym innym robiony)?.



Niemniej jednak dzięki za wszelkie sugestie, pokombinuje cos z tym CAR, QoS przed ASA i się zobaczy, reguły też trochę bardziej uszczelniłem.

[lbromirs]

Co do filtrowania ruchu jeszcze przed ASA to chyba coś nie tak.
Rozumiem, że switch, że ASICi, że szybciej itp ale nie po to chyba mam ASA, stanowy firewall, abym miał się jeszcze "użerać" z ACLkami na switchu.
Jak mam robić ACL na switchu to do czego mi ta ASA ma służyć (VPN/NAT jest na czym innym robiony)?.

Zdrowy rozsądek podpowiada, że skoczyć z szóstego piętra wieżowca można, ale najprawdopodobniej tylko raz. ASA nie jest sprzedawana jako rozwiązanie DDoSów, bo nie mówisz o filtrowaniu ruchu, tylko próbie picia wody z węża strażackiego pod ogromnym ciśnieniem. Może i przeżyjesz, może i nie rozerwie Ci twarzy, ale jeśli już musisz pić z węża strażackiego, robi się to inaczej. Po prostu.

Innymi słowy i poważniej, każde narzędzie ma swoje zastosowanie. Skoro masz sprzętowo przetwarzane ACLki, ROZSĄDNIEJ jest użyć ich jako pierwszej warstwy obrony, a dopiero potem angażować urządzenia o mniejszej odporności/skalowalności.

A do obrony przed DDoSami korzysta się z NetFlow oraz współpracy z operatorami/projektu takiego jak BGP Blackholing. Można też nadal pić z węża strażackiego, wybóru zawsze dokonujesz Ty