Hej,
Jestem przekonany ze byla sesja poswiecona jak ISP powinno sie bronic przed DDoS/DoS.
Jezeli macie jakis link do PLNOGa / EURONOGa poprosze o URL.
Z gory dzieki.
W poszukiwaniu DPI/DDoS dla ISP - PLNOG?
- PatrykW
- wannabe
- Posty: 1742
- Rejestracja: 31 paź 2008, 16:05
- Lokalizacja: UI.PL / Ubiquiti Polska.pl
- Kontakt:
W poszukiwaniu DPI/DDoS dla ISP - PLNOG?
.ılı..ılı.
http://www.linkedin.com/in/pwojtachnio
Potrzebujesz projektu na studia z zakresu Cisco Packet Tracer & GNS ? Just give me call
Integrujemy i wspieramy IT
https://www.ui.pl | https://facebook.com/UIPolska
Jedyne rozwiązania Ubiquiti Networks w Polsce!
https://ubiquitipolska.pl | https://www.facebook.com/groups/Ubiquiti.Polska
http://www.linkedin.com/in/pwojtachnio
Potrzebujesz projektu na studia z zakresu Cisco Packet Tracer & GNS ? Just give me call
Integrujemy i wspieramy IT
https://www.ui.pl | https://facebook.com/UIPolska
Jedyne rozwiązania Ubiquiti Networks w Polsce!
https://ubiquitipolska.pl | https://www.facebook.com/groups/Ubiquiti.Polska
Nie ma jedneo zlotego srodka, czyt magicznego pudelka ktore zapewnia ci ochrone przed kazdym atakiem DDoS. Dlatego ze masz rozne typy atakow.
1) Mozesz robic BGP Blackholing
2) Mozesz wstawic pudelko ktore obroni ci ataki skierowane do wew sieci
3) Mozesz skorzystac z firmy 3 i przekierowac przez GRE ruch podejrzany o DDoS do odfiltrowania w ich sieci
Najgorsze ataki to te ktore wysycaja ci lacze ;] wtedy po prostu najlepiej miec wieksza przepustowosc niz atak
1) Mozesz robic BGP Blackholing
2) Mozesz wstawic pudelko ktore obroni ci ataki skierowane do wew sieci
3) Mozesz skorzystac z firmy 3 i przekierowac przez GRE ruch podejrzany o DDoS do odfiltrowania w ich sieci
Najgorsze ataki to te ktore wysycaja ci lacze ;] wtedy po prostu najlepiej miec wieksza przepustowosc niz atak
Re: W poszukiwaniu DPI/DDoS dla ISP - PLNOG?
Nie robi się DPI dla DDoSów.Wojtachinho pisze:Hej,
Jestem przekonany ze byla sesja poswiecona jak ISP powinno sie bronic przed DDoS/DoS.
Jezeli macie jakis link do PLNOGa / EURONOGa poprosze o URL.
Z gory dzieki.
Czy naprawdę tak trudno zajrzeć na stronę PLNOG albo YouTube?
- peper
- CCIE / Site Admin
- Posty: 5005
- Rejestracja: 13 sie 2004, 12:19
- Lokalizacja: Warsaw, PL
- Kontakt:
To nie łącze jest wąskim gardłem, szczególnie w DC gdzie zazwyczaj masz kontrakty typu burstable od ISP, a wydajność pudełka brzegowego mierzoną przepływnością czy pps.horac pisze:Najgorsze ataki to te ktore wysycaja ci lacze ;] wtedy po prostu najlepiej miec wieksza przepustowosc niz atak
Szkoła DevNet: https://szkoladevnet.pl
Facebook: https://www.facebook.com/Piotr.Wojciechowski.CCIE
LinkedIn: https://www.linkedin.com/in/peper
Twitter: https://www.twitter.com/PiotrW_CCIE
"Zapomniałem że od kilku lat wszyscy giną jakby nigdy ich nie miało być
w stu tysiącach jednakowych miast giną jak psy"
Facebook: https://www.facebook.com/Piotr.Wojciechowski.CCIE
LinkedIn: https://www.linkedin.com/in/peper
Twitter: https://www.twitter.com/PiotrW_CCIE
"Zapomniałem że od kilku lat wszyscy giną jakby nigdy ich nie miało być
w stu tysiącach jednakowych miast giną jak psy"
A ja napiszę że i jedno i drugie, w sensie:
1) najpierw padnie wszystko co "stanowe" na brzegu sieci
2) a potem przy odpowiednim wolumenie zapchają się łącza.
I dokładnie w tej kolejności. nawet przy posiadaniu wielu łączy np. 10G rozlicznych na 95-percentylu, można szybko policzyć jaki UDP czy TCP flood może zabić naszego firewall'a (po sprawdzeniu w speckach ile może zrobić max ilość nowych conn/s i ilość concurrent conn), i czy trzeba do tego 10G pasma...
Więc dobrą ochronę AntyDDoS w przypadku z którym miałem do czynienia dał miks ochrony "on site" i zewnętrznego dostawcy. Urządzenie zainstalowane na brzegu DC ma za zadanie ochronić przed pierwszym strzałem wszystko co głębiej w sieci, a jeśli atak który do niego dotrze przekroczy jego możliwości to powinno pozostać w stanie "stabilnym", w sensie np. nie zrestartować się i przeczekać aż ruch spadnie. FW które miałem na brzegu najczęściej albo wpadały w przepinanie się w ramach HA z jednego na drugie lub kończyło się restartem pudełek.
I to urządzenie on-site (w mniejszych instalacjach zainstalowane in-line, w ISP pewnie obok z przekierowaniem ruchu via np. BGP - z tym że że urządzenie inline napewno zareaguje szybciej) ma nam pozwolić przetrwać przez pierwsze kilka minut zanim zewnętrzny usługodawca zacznie aktywnie filtrować DDoS. A i tak najczęściej zewnętrzny usługodawca robi to nie w 100% więc wtedy urządzenie in-site może zająć się swoją robotą na tym co przepuścił dostawca. A czasem może to robić lepiej bo np. widzi ruch symetryczny, usługodawca nie koniecznie.
No i często pod przykrywką większego ataku prowadzone są kolejne pod spodem więc szczególnie wtedy warto zadbać o to by krytyczne zasoby sieci były chronione przez DPI - ale już na końcu tego "leja" którym odfiltrowujemy ruch.
Z darmowych rozwiązań skrypty (np. ja korzystałem z NFSen+NFDump + skrypt DDD który znalazłem gdzieś w necie, jakieś info np. tu DDD. Jak nie znajdziecie w necie to poszukam u siebie - może gdzieś mam to w archiwum. Oczywiście to co "wypluje" DDD trzeba jeszcze wstrzelić np. do URPF'a na brzeg sieci.
Z tanich rozwiązań, wanguard - sprawdzony w boju.
Z drogich rozwiązań - (a co mi tam ;P ) szukaj tu AntyDDoS lub radware, arbor itp.
ps. Kiedyś w PL była mowa o próbie skrzyknięcia się w kilka firm i powołania "ciała" które będzie chronić uczestników inicjatywy. Nic z tego nie wyszło, ale jak widać da się to zrobić (strona w NL, google translate pomaga : NBIP
1) najpierw padnie wszystko co "stanowe" na brzegu sieci
2) a potem przy odpowiednim wolumenie zapchają się łącza.
I dokładnie w tej kolejności. nawet przy posiadaniu wielu łączy np. 10G rozlicznych na 95-percentylu, można szybko policzyć jaki UDP czy TCP flood może zabić naszego firewall'a (po sprawdzeniu w speckach ile może zrobić max ilość nowych conn/s i ilość concurrent conn), i czy trzeba do tego 10G pasma...
Więc dobrą ochronę AntyDDoS w przypadku z którym miałem do czynienia dał miks ochrony "on site" i zewnętrznego dostawcy. Urządzenie zainstalowane na brzegu DC ma za zadanie ochronić przed pierwszym strzałem wszystko co głębiej w sieci, a jeśli atak który do niego dotrze przekroczy jego możliwości to powinno pozostać w stanie "stabilnym", w sensie np. nie zrestartować się i przeczekać aż ruch spadnie. FW które miałem na brzegu najczęściej albo wpadały w przepinanie się w ramach HA z jednego na drugie lub kończyło się restartem pudełek.
I to urządzenie on-site (w mniejszych instalacjach zainstalowane in-line, w ISP pewnie obok z przekierowaniem ruchu via np. BGP - z tym że że urządzenie inline napewno zareaguje szybciej) ma nam pozwolić przetrwać przez pierwsze kilka minut zanim zewnętrzny usługodawca zacznie aktywnie filtrować DDoS. A i tak najczęściej zewnętrzny usługodawca robi to nie w 100% więc wtedy urządzenie in-site może zająć się swoją robotą na tym co przepuścił dostawca. A czasem może to robić lepiej bo np. widzi ruch symetryczny, usługodawca nie koniecznie.
No i często pod przykrywką większego ataku prowadzone są kolejne pod spodem więc szczególnie wtedy warto zadbać o to by krytyczne zasoby sieci były chronione przez DPI - ale już na końcu tego "leja" którym odfiltrowujemy ruch.
Z darmowych rozwiązań skrypty (np. ja korzystałem z NFSen+NFDump + skrypt DDD który znalazłem gdzieś w necie, jakieś info np. tu DDD. Jak nie znajdziecie w necie to poszukam u siebie - może gdzieś mam to w archiwum. Oczywiście to co "wypluje" DDD trzeba jeszcze wstrzelić np. do URPF'a na brzeg sieci.
Z tanich rozwiązań, wanguard - sprawdzony w boju.
Z drogich rozwiązań - (a co mi tam ;P ) szukaj tu AntyDDoS lub radware, arbor itp.
ps. Kiedyś w PL była mowa o próbie skrzyknięcia się w kilka firm i powołania "ciała" które będzie chronić uczestników inicjatywy. Nic z tego nie wyszło, ale jak widać da się to zrobić (strona w NL, google translate pomaga : NBIP