TCP SYN flood

[lukaszbw]

TCP intercept na 6500 nie chodzi za dobrze, nie wszystkie rzeczy są obsługiwane sprzętowo, mogą dobić CPU ma RP. Cisco generalnie odchodzi już od tej funkcjonalności więc nie wiem nawet czy nowych softach jest.

Oprócz optymalizacji firewall sugeruje odpalić UBRL. Policy-map zapiąć od strony internetu i użyć maski SRC. W ACL pod class-map oznaczyć pakiety syn. Przyciąć w oparciu o flow do niskiej przepustowości (UBRL nie obsługuje przycinania w pps)

Generalnie będzie następujący efekt - 6500 będzie dynamicznie tworzył niezależną kolejke dla każdego klienta łączącego do serwera określonego w ACL. Czyli jak ci jeden delikwent da flood pakietami syn to wytnie go do przepustowości jaką ustawisz. Musisz oczywiście ustawić taką aby zaufanym klientom nie pogorszyć obsługi (możesz np. ustawić większy burst - Bc).

Zaleta jest taka, że wszystko masz robione sprzętowo więc mogą sobie walić w usługe. Wadą to możliwość przeciążenia tablicy netflow jak masz setki tysięcy adresów łączących się do sieci (najwazniejsze abyś dał flow mask jako interface-source). No i jak DDos masz z botnetu to i tak sporo tych SYN dojdzie. W końcu jak używasz aktualnie netflow w 6500 to pamiętaj o konfliktach z flow mask przy UBRL i NDE.

Tutaj prosty przykład:

Kod: Zaznacz cały

mls flow ip interface-source
mls qos
!
ip access-list extended ubrl
 permit tcp any host 192.168.0.100 syn
!
!
class-map match-all ubrl
  match access-group name ubrl
!
!
policy-map ubrl
  class ubrl
     police flow mask src-only 32000 64000 conform-action transmit exceed-action drop

Pozdr.

[mabes]

TCP Intercept nie jest dobrym pomysłem na 6500, ruch trafia do CPU.

Sugeruje raczej na wejściu ustawić sobie za pomocą MQC dobry QoS na wejściu dla poszczególnych klas ruchu. W szczególności np. ograniczyc ilość TCP SYNów (ACL+MQC) do 20kppsów, etc - daje się to wszystko elegancko zrobić na wejściu, a ponieważ idzie to sprzętowo, nawet nie czujesz jak bardzo próbują zrobić Ci krzywdę.

To w przypadku ataku SYN flood rzedu 1Mpps praktycznie odcinamy usluge dla nowych polaczen podczas ataku. Jezeli atakujacy generuje losowe source IP ze sporego botneta to zaden limit nie pomoze.

[PatrykW]

TCP Intercept nie jest dobrym pomysłem na 6500, ruch trafia do CPU.

Sugeruje raczej na wejściu ustawić sobie za pomocą MQC dobry QoS na wejściu dla poszczególnych klas ruchu. W szczególności np. ograniczyc ilość TCP SYNów (ACL+MQC) do 20kppsów, etc - daje się to wszystko elegancko zrobić na wejściu, a ponieważ idzie to sprzętowo, nawet nie czujesz jak bardzo próbują zrobić Ci krzywdę.

Do tego warto dorzucić inny ruch o znanych charakterystykach, np. UDP, ICMP, GRE, etc.

Dopiero do wyższych warstw warto zainwestować coś w L4-L7 z dynamicznymi progami, typu Radware, Arbor, czy nawet usługi chmurowe - w stylu CloudFlare.

Hej Lukasz,

Dzieki za hint. Czy jestes w stanie jakis przyklad podeslac konfiguracji ?

[mzb]

Oprócz optymalizacji firewall sugeruje odpalić UBRL. Policy-map zapiąć od strony internetu i użyć maski SRC. W ACL pod class-map oznaczyć pakiety syn. Przyciąć w oparciu o flow do niskiej przepustowości (UBRL nie obsługuje przycinania w pps)

Generalnie będzie następujący efekt - 6500 będzie dynamicznie tworzył niezależną kolejke dla każdego klienta łączącego do serwera określonego w ACL. Czyli jak ci jeden delikwent da flood pakietami syn to wytnie go do przepustowości jaką ustawisz. Musisz oczywiście ustawić taką aby zaufanym klientom nie pogorszyć obsługi (możesz np. ustawić większy burst - Bc).

Swoją drogą ciekawe ile wytrzyma QoS TCAM... I czy atakowany ma PFC4 =)

-- M.

[michaliwanczuk]

zawsze można wykupić usługę ant ddos w F5 - mają usługę na pokazie w F5 Forum wyglądało to fajnie, jest bardziej elastyczne niż to arbor oferowanego przez operatora jak dla mnie

[lukaszbw]

Swoją drogą ciekawe ile wytrzyma QoS TCAM... I czy atakowany ma PFC4 =)

-- M.

Prędzej łącze zapcha. Stosuje w wielu miejscach tylko jako generalne zabezpieczenie przed DoS (match IP a nie TCP syn) i prędkości >10GE nie są problemem. Nie wiem jak PFC4 ale na PFC3cxl masz do 230K połączeń z różnych adresów IP.

Jak weźmiesz source-interface (czyli jak np. ktoś robi ci scan na 65K portów i różne IP z twojej puli to masz 1 wpis flow) to naprawde musisz mieć spory ruch żeby wysycić TCAM.

Poza tym wysycenie nie powoduje problemu poza oczywiście niepełnym przycinaniem ale i tak wtedy switch weźmie ci mase ruchu "na klate".

Pozdr.

[grze]

TCP Intercept nie jest dobrym pomysłem na 6500, ruch trafia do CPU.

Sugeruje raczej na wejściu ustawić sobie za pomocą MQC dobry QoS na wejściu dla poszczególnych klas ruchu. W szczególności np. ograniczyc ilość TCP SYNów (ACL+MQC) do 20kppsów, etc - daje się to wszystko elegancko zrobić na wejściu, a ponieważ idzie to sprzętowo, nawet nie czujesz jak bardzo próbują zrobić Ci krzywdę.

Do tego warto dorzucić inny ruch o znanych charakterystykach, np. UDP, ICMP, GRE, etc.

Dopiero do wyższych warstw warto zainwestować coś w L4-L7 z dynamicznymi progami, typu Radware, Arbor, czy nawet usługi chmurowe - w stylu CloudFlare.

Myślę, że to może być dobry temat np na kolejne spotkanie ccie.pl

[PatrykW]

TCP Intercept nie jest dobrym pomysłem na 6500, ruch trafia do CPU.

Sugeruje raczej na wejściu ustawić sobie za pomocą MQC dobry QoS na wejściu dla poszczególnych klas ruchu. W szczególności np. ograniczyc ilość TCP SYNów (ACL+MQC) do 20kppsów, etc - daje się to wszystko elegancko zrobić na wejściu, a ponieważ idzie to sprzętowo, nawet nie czujesz jak bardzo próbują zrobić Ci krzywdę.

Do tego warto dorzucić inny ruch o znanych charakterystykach, np. UDP, ICMP, GRE, etc.

Dopiero do wyższych warstw warto zainwestować coś w L4-L7 z dynamicznymi progami, typu Radware, Arbor, czy nawet usługi chmurowe - w stylu CloudFlare.

Myślę, że to może być dobry temat np na kolejne spotkanie ccie.pl

Jak tylko jest mozliwosc, bardzo chcialbym zaglebic wiedze w tym temacie...

[martino76]

Witam,

Możesz sobie obejrzeć sesje z Cisco Live Berlin o DDoS BRKSEC-3009

Pozdro,