Trecom - DDoS Detekcja-obrona

OBRONA PRZED
DDOS
Metody detekcji i niwelowania skutków
ataków DDoS na sieci korporacyjne
www.trecom.pl
maciej.rzehak@trecom.pl

Czym jest DDoS? (pro forma)
• Metoda ataku infrastruktury transportowej i/lub
usługowej, polegająca na wygenerowaniu ruchu o
wolumenie i/lub natężeniu przekraczającym
możliwości infrastruktury
• Zwyczajowo ataki DDoS dzieli się na trzy rodzaje:
– bot driven DDoS
– flash DDoS – najtrudniejsze do obrony ponieważ ruch
generowany przez każde źródło osobno nie wykazuje
praktycznie anomalii względem ruchu pożądanego
– aided flash DDoS – grupa atakująca wspomaga się
narzędziami – charakterystyka bardzo zbliżona do ataku
przeprowadzonego za pośrednictwem botnetu

Metody ochrony sieci operatorskich oraz klienckich przed atakami DDoS

Aided Flash DDoS

• prosty program umożliwiający zorganizowanej społeczności przeprowadzenie ataku o sile
botnetu
• Istnieje wiele podobnych narzędzi, m.in. WEBNuke
• Najczęściej wykorzystywane do przeprowadzenia spontanicznych ataków o podłożu
ideologicznym
• Ostatnio atak użytkowników 4Chan na RIAA (czerwiec 2010)


Flash DDoS
• Nazwa pochodzi od zjawiska znanego jako „Flash Mob”
• Metoda nie wymagająca żadnej wiedzy poza
umiejętnością obsługi podstawowych aplikacji
• Umożliwia przeprowadzenie ataku o podłożu ideowym,
społecznościom o odpowiedniej liczebności i będącym
w stanie się zorganizować
• Charakterystyka ruchu związanego z takim atakiem
praktycznie w ogóle nie odbiega od charakterystyki
ruchu pożądanego – bardzo trudna do wyeliminowania
• Wyrosła na kanwie zjawiska znanego jako „Digg Effect”
• Szczególnie skuteczna wobec mniejszych
przedsiębiorstw lub organizacji, nie dysponujących
wydajną i skalowalną infrastrukturą

Bot Driven DDoS

• Metoda ataku oferująca największy potencjał
• Umożliwia wygenerowanie ataku o wolumenie przekraczającym 10Gbs
• Budowa botnetu wymaga pewnej wiedzy technicznej i czasu propagacje
– wbrew pozorom wcale nie tak dużej
– na rynku są dostępne kity do budowy bota, umożliwiające przygotowanie
własnego botware’u
– niemal point&click – poradzi sobie z nimi każde scriptkitty
• Aktualnie wykorzystywana głównie w celach zarobkowych
• Popularna metoda zwalczania konkurencji na rynku wschodnim
• Atak jest formą wymuszenia okupu, lub usługą sprzedawaną konkurencji
• Wbrew pozorom kupienie usługi DDoS jest bardzo proste i relatywnie tanie
• Bardzo dobrze widać to na runku Chińskim


Obecnie DDoS to biznes

• Cena = 200$/24h


DDoS 2009/10 - trendy

• Dane zebrane przez system
monitoringu Arbor ATLAS
• Obok systemu CAIDA, największy
system monitoringu aktywności w
Internecie
• Dane zbierane w sieciach 120
największych światowych NSP/IPS



• ponad 20k ataków o natężeniu powyżej 1Gbps
• nowy powyżej 1Gbps co 26minut
• nowy rejestrowany atak co ~90sekund
• nowy atak o natężeniu powyżej 10Gbps co ~190minut


DDoS – co mamy na runku?
• Najpopularniejsze obecnie boty:
– Avzhan
– WhiteLotus
– YoYo
– BlackEnergy.v2
– IMDOS
• Analiza kodu wskazuje na 3 rodzaje ataków:
– HTTP flood
– UDP flood+SYN flood
– ICMP flood
• Istnieją różnice w technikach propagacji – inny trojanware codebase
• Z wyjątkiem BlackEnergy.v2, bardzo duże podobieństwa w przypadku
botware’u
– Podobny protokół C&C
– Powtarzające się nagłówki HTTP
– Podobne odstępstwa od RFC w przypadku niektórych pakietów


DDoS – kto jest zagrożony?
• Każde przedsiębiorstwo którego biznes jest zależny
od obecności w Internecie
– segment e-commerce
• dostępność usług wpływa bezpośrednio na core biznes,
zazwyczaj bardzo wydajna i dobrze przygotowana infrastruktura
serwerowa, load balancery, reverse proxy, front-end/backend etc.
• w polskich warunkach słaby punkt to najczęściej upstream
– przedsiębiorstwa które wykorzystują aplikacje http do
sprzedaży własnych produktów/usług przez pośredników,
nie włączanych do infrastruktury WAN
• dystrybutorzy produktów i usług masowych np. producenci
materiałów budowlanych, biura podróży etc.


DDoS – jak się bronić?
• Znajomość możliwości własnej infrastruktury
• Nadmiarowa infrastruktura – multihoming etc.
(większe możliwości zarządzania ruchem)
• Opracowane i przetestowane plany komunikacyjne z operatorami – współpraca
jest niezbędna
• BCP – działają! Potwierdzają to doświadczenia z ataków na instytucje rządowe
USA i Korei Południowej z Lipca 2009
– największy zarejestrowany w tym czasie atak miał siłę ~140mb/s i 500kpps
• Aktywne systemy detekcji i ochrony
• Szukać operatorów którzy są zainteresowani świadczeniem usług MSS
– współinwestycja jest w interesie operatora – pozwoli mu chronić własną infrastrukturę: brzeg
sieci i tym samym poszczególne PoPy – atak na jednego klienta może zablokować cały PoP
a tym samym wszystkich podłączonych klientów – straty będą zależne od poziomu
oversubscrypcji PoPa
– Umożliwia oferowanie usługi w przyszłości wszystkich klientom
– Wdrożnie można zacząć od stworzenia w sieci ISP jednego lub dwóch punktów
scrubbingowych (anycasting, LB, LSP long houl redirection)
– Docelowo można mieć scrubber w każdym PoPie i PP, broniąc się bezpośrednio na brzegu
– Szerokie wdrożenie kolektorów danych telemetryczanych SP generuje wartość dodaną w
postaci pełnej widoczności ruchu w sieci a także umożliwia łatwe uruchomienie systemów
ISP Buisness Inteligence


Przegląd rozwiązania
• Arbor PeakFlow SP + Arbor PeakFlow TMS
– rozwiązanie stworzone z myślą o operatorach
– metoda implementacji SP+TMS jest analogiczna do Cisco Anomaly
Detector/Anomaly Guard
– metoda działania jest podobna, ale znacznie się różni
– rozwiązania mogą współpracować
– elastyczna architektura pozwala w łatwy sposób przystosować
rozwiązanie do potrzeb klientów korporacyjnych
– aby chronić łącza upstreamowe, niezbędna jest współpraca z
operatorem
• PeakFlow SP monitoruje ruch i tworzy profile statystyczne dla ruchu
kierowanego do chronionych zasobów
• W przypadku wykrycia anomalii, generuje alert którego konsekwencją może
być przekierowanie ruchu do scrubbera – TMS
• PeakFlow TMS przy pomocy zestawu filtrów przesiewowych oddziela ruch
związany z atakiem od ruchu pożądanego
• Ruch pożądany zwraca w kierunku atakowanego serwera
• W trakcie czyszczenia, ruch do pozostałych zasobów przedsiębiorstwa, nie
będących bezpośrednio celem ataku, jest routowany bez zmian



Router ISP

ISP

KLIENT



1. Detekcja anomalii



2. Aktywacja
przekierowania



4. Oczyszczanie przekierowanego ruchu

3. TMS przez iBGP ogłasza /32

2. Aktywacja
przekierowania



4. Oczyszczanie przekierowanego ruchu

3. TMS przez iBGP ogłasza /32
5. Uwierzytelniony
ruch trafia do
serwera

2. Aktywacja
przekierowania




np. tunel GRE

Ruch do pozostałych
serwerów przez cały czas jest
routowany bezpośrednio


Metody detekcji ataku
• Detekcja anomalii ruchu odbywa się per-obiekt (Managed Object)
• Obiekt może zostać zdefiniowany jako zakres adresów IP,
blok CIDR, podsieć, prefiks /32 etc.
• Obiekty są identyfikowane w systemie za pomocą nadanej
im nazwy
• Dla każdego zdefiniowanego obiektu SP na podstawie
otrzymywanych meta-danych telemetrycznych tworzy
szczegółowe profile statystyczne dla ruchu powiązanego z
danym obiektem
• W przypadku klientów korporacyjnych i usługodawców są
to zazwyczaj zasoby strategiczne takie jak adresy
identyfikujące infrastrukturę www, serwery DNS, serwery
pocztowe, publicznie dostępne serwery aplikacyjne etc.
• SP tworzy profile statystyczne w odniesieniu do całego
ruchu powiązanego z danym obiektem


• Proces detekcji ataku jest dwustopniowy
• Detekcja anomalii
– Charakterystyka ruchu odbiega od normy dla danego rodzaju ruchu
– Natężenie ruchu przekracza pre-definiowane i akceptowalne poziomy
– Charakterystyka ruchu jest zgodna z charakterystyką oznaczoną jako
stanowiącą zagrożenie dla chronionych obiektów
• Klasyfikacja anomalii
– Na tym etapie SP ocenia skale zagrożenia
• Klasyfikacja opiera się na profilach statystycznych oraz konfigurowanych przez
operatora progach wysokiego ryzyka
• Umożliwia powiązanie anomalii o różnym stopniu ryzyka z różnymi rodzajami reakcji
– Trzy poziomy klasyfikacji:
• Czerwony – wysokie ryzyko utraty dostępności zasobu
• Żółty – ryzyko umiarkowane
• Zielone – ryzyko niskie
• W momencie wykrycia i sklasyfikowania anomalii, stopień ryzyka może
zostać wyłącznie podniesiony
• Dla każdego poziomy ryzyka, dla każdego chronionego obiektu, można
przypisać różne sposoby reakcji


SP rozróżnia trzy rodzaje anomalii:
• Anomalia mająca charakter nadużycia
• Anomalia względem profilu statystycznego
danego rodzaju ruchu powiązanego z danym
chronionym obiektem
• Anomalia profilu statystycznego danego
rodzaju ruchu, względem kraju pochodzenia
ruchu (GeoIP)


• Anomalia o charakterze nadużycia
– Wykrywa ataki wyłącznie per-host docelowy
– Używa statycznych progów dla poszczególnych
rodzajów ruchu w celu wykrycia nadużycia
– Progi są konfigurowane statycznie, ale mogą być
wcześniej profilowane automatycznie
– Bardzo proste w konfiguracji
– Przy dobrej znajomości udostępnianej usługi, lub
po wcześniejszym profilowaniu, praktycznie nie
generuje tzw. false-positives


– progi są konfigurowane dla następujących rodzajów
ruchu:
• ICMP (pps)
• Flaga TCP NULL (pps)
• Flaga TCP SYN (pps)
• Flaga TCP RST (pps)
• IP NULL (Protocol 0) (pps)
• Fragmentacja IP (pps)
• BOGONS (pps)
• Ruch DNS (TCP i UDP) (pps)
• Ruch UDP (pps)
• Próg sumaryczny dla danego hosta (pps+bps)
– bardzo skuteczne przy detekcji ataków typu flood



• Anomalie o charakterze nadużycia są wykrywane w oparciu o statyczne progi
• Misuse Trigger Rate – próg detekcji dla danego rodzaju ruchu, wartość
domyślna dla większości rodzajów ruchu to 500pps
• Middle Line – próg rozróżniający anomalię niskiego i wysokiego ryzyka,
ustalany automatycznie
•High severity Trigger Rate – próg detekcji anomalii wysokiego ryzyka, wartość
domyślna dla większości rodzajów ruchu to 10K



• W celu uniknięcia fałszywych alarmów w wyniku chwilowych skoków,
wykorzystywane są timery
• Misuse Latency – okres przez który poziom ruchu musi przekraczać próg
aktywujący aby został wygenerowany alarm
• Severity Duration – okres przez który poziom ruchu musi przekraczać próg
wysokiego ryzyka, zanim zostanie jako taki zakwalifikowany



• jeżeli natężenie ruchu przekracza wartość progu aktywującego przez dany
okres czasu, zostaje wygenerowany alarm
• natężenie ruchu nie przekracza progu eskalacji
• w momencie spadku poniżej progu aktywującego, alarm zostaje oznaczony jako
nie aktywny



• natężenie ruchu pozostaje powyżej progu aktywacji alarmu przez wymagany
okres czasy
• natężenie ruchu wzrasta powyżej progu aktywującego alarm średniego ryzyka
• natężenie ruchu przekracza próg aktywujący alarm wysokiego ryzyka, ale nie
na tyle długo aby klasyfikacja alarmu została zmieniona
• alarm pozostaje zakwalifikowany jako alarm średniego ryzyka



• natężenie ruchu przekracza kolejne progi aktywujące i osiąga próg aktywujący
alarm wysokiego ryzyka
• alarm pozostaje aktywny aż do momentu kiedy natężenie ruchu spadnie poniżej
progu aktywującego


• Anomalia względem profilu bazowego

– SP utrzymuje profil bazowy – tzw. baseline dla każdego
chronionego obiektu, dla poszczególnych rodzajów ruchu
powiązanego z danym obiektem
– Dla każdego routera który dostarcza meta-dane tworzony
jest osobny zestaw profili per chroniony obiekt
– SP porównuje aktualną charakterystykę ruchu z profilem
– Alarm jest generowany w sytuacji w której aktualna
charakterystyka ruchu w sposób znaczący odstaje od
profilu bazowego dla danego okresu i przekracza próg
Ignore Rate
– Skuteczna metoda detekcji ataków których
charakterystyka przypomina ruch pożądany, i których
natężenie pozostaje poniżej progów detekcji nadużyć


– Profil pps utrzymywany jest per router dostarczający meta-dane
– Profil bps utrzymywany jest per interfejs każdego routera
dostarczającego meta-dane
– Oprócz profili sumarycznych, profile per protokół L4 per router
• TCP
• UDP
• ICMP
• ESP
• AH
• GRE
• Etc.
– Profile są budowane dla okresów 30 minutowych – ta sama godzina
ten sam dzień tygodnia
– Profile są budowane na podstawie danych z ostatniego miesiąca
– Starsze dane mają większą wagę przy budowaniu profili
– Profile bazowe są budowane w oparciu o średnią statystyczną dla
danego okresu



• Ignore Rate – próg który musi zostać przekroczony przez ruch aby SP wygenerował alert
• Ignore Rate jest kalkulowany per router, per chroniony obiekt, i może być wyższy od profilu
bazowego dla danego okresu czasu
• Traffic Baseline – wartość bazowa dla maksymalnego natężenia ruchu w danym okresie, w
normalnych warunkach
• Deviation Tolerance – próg określający stopień tolerancji na odstępstwa od profilu bazowego
• Profiled Latency – minimalny okres czasu przez który natężenie ruchu musi przekraczać profil
bazowy aby został wygenerowany alarm



• natężenie ruchu przekracza próg Ignore Rate
• natężenie ruchu wykracza poza margines tolerancji wobec odstępstw od profilu
bazowego dla danego protokołu w danym okresie czasu
• natężenie ruchu przekracza próg średniego ryzyka
• zostaje wygenerowany alert średniego ryzyka
• natężenie ruchu przekracza próg wysokiego ryzyka, ale nie na tyle długo aby
został poziom ryzyka został podniesiony



• natężenie ruchu przekroczyło próg wysokiego ryzyka i utrzymywało ponad nim
powyżej 5 minut
• zostaje wygenerowany alert wysokiego ryzyka
• w momencie kiedy natężenie ruchu spada poniżej progu ignorowania anomalii lub
profilu bazowego, alert zostaje uznany za nieaktywny


• Severity Rate oraz Ignore Rate są ustawiane
ręcznie lub mogą być liczone automatycznie na
bieżąco
• Severity Rate = 95 percentyl z ostatnich 30 dni x
mnożnik (domyślnie 1.1)
– Domyślnie Severity Rate dla danego protokołu L4
jest o 10% wyższy od wartości której nie przekroczyło
95% próbek w danym okresie pomiarowym
• Ignore Rate = 40 percentyl z ostatnich 30 dni dla
danego chronionego obiektu


• Anomalie względem profilu bazowego rozkładu
pochodzenia ruchu
• Wykorzystuje utrzymywaną przez Arbor Networks bazę GeoIP, na
podstawie której identyfikuje kontynent/kraj pochodzenia pakietu IP
• Tworzy profile bazowe dla kraju pochodzenia ruchu
• Severity Rate oraz Ignore Rate jest wspólny dla wszystkich krajów
• Jest to rozszerzenie mechanizmu detekcji względem profilu bazowego
• Bardzo skuteczne w identyfikowaniu ataków typu „mimic” lub „low
volume/low rate” typu NAPHTA
– Jeżeli PeakFlow raportuje wzrost wolumenu ruchu do danego zasobu o 40%,
jednocześnie raportując np. 400% wzrost udziału ruchu z Chin, istnieje
bardzo dużo prawdopodobieństwo że wygenerowany alert dotyczy anomalii
będącej skutkiem ataku DDoS
– Dysponując profilem bazowym dla ruchu z Chin, według którego udział Chin
w zwyczajnej sytuacji jest marginalny, możemy podjąć decyzję o wycięciu
Chin bez znaczących strat dla naszego biznesu, lub biznesu naszego klienta
;-)


• PeakFlow SP w oparciu o analizę statystyczną ruchu wykrywa anomalie i
przypisuje im odpowiedni poziom ryzyka który ze sobą niosą
• PeakFlow SP nie informuje jednoznacznie czy jest to celowy atak i
jakiego rodzaju
• W oparciu i wygenerowany alert operator może podjąć odpowiednie
działania
– Może za pomocą danych statystycznych wygenerować i aktywować listy ACL
w odpowiednich punktach sieci
– Może wygenerować FlowSpec NLRI do ogłoszenia za pomocą MP-BGP
– Może przekierować ruch do danego obiektu w taki sposób, aby przechodził
przez PeakFlow TMS w celu jego analizy i oczyszczenia (lub inny scrubber)
– Jeżeli dla danego obiektu, i danego poziomu ryzyka został skonfigurowany
odpowiedni szablon mitygacyjny, przekierowanie do TMS może nastąpić
automatycznie
– Operator ma możliwość utworzenia szablonu mitygacyjnego już po wykryciu
ataku


Mechanizmy czyszczenia ruchu
Mechanizmy oczyszczania ruchu przez
urządzenie PeakFlow TMS

Tzw. „scrubbing”



Sposób obsługi filtrów:
• TMS odbiera wszystkie pakiety które zostaną do niego
przekierowane, stosując skonfigurowane filtry przesiewowe
do tych pakietów które nie zostały
przepuszczone/zablokowane przez białą/czarną listę oraz
listę wyjątków

• White/Black Lista jest dynamicznie aktualizowana przez
niektóre filtry
– w przypadku zablokowania pakietu przez dany filtr, adres źródłowy
hosta jest wpisywany na czarną listę na określony okres czasu
– po określonym czasie, adres hosta jest usuwany z czarnej listy


TMS wykorzystuje dwa rodzaje filtrów przesiewowych:

- per-packet (Per-Packet Countermeasures)
- filtry stosowane w pierwszej kolejności
- stosowane wobec każdego pakietu który trafia do TMS

- per-event (Event Driven Countermeasures)
- stosowane wyłącznie do wybranych pakietów
- podzielone na dwie grupy:
• filtry aplikacyjne
- pakiety zostają rozpoznane jako należące do strumienia danych danej aplikacji
- PDU aplikacji zostaje przekazane do odpowiednich filtrów warstwy aplikacyjnej
- jeżeli zachodzi taka potrzeba PDU jest rekonstruowane nawet z kilku pakietów

• filtry czasowe
- filtry składające się z zestawu timerów mających na celu wychwycenie konkretnych
zdarzeń, np. bezczynności sesji TCP


Kolejność stosowania filtrów typu per-packet:

1. Global Exeption List/ Mitigation Exception List [L3-4]
2. Black / White List [DROP/PERMIT/RATE LIMIT,L3-7 PCAP fingerprint]
3. Dynamic Blacklist
(utrzymywana automatycznie przez pozostałe filtry)
4. Zombie Removal
5. TCP SYN Authentication and HTTP Authentication
6. DNS Authentication
7. TCP Connection Reset (filtr reaktywny)
8. Payload Regular Expression Filtering (HTTP, DNS, SIP, CUSTOM )
9. Baseline Enforcement/GeoIP shape/drop
10. Rate Limiting
~ Application Specific


Ruch aplikacyjny poddawany jest następującym filtrom:
- HTTP
• HTTP Header Regular Expression (RegEx)
• HTTP Request Rate Limiting (per host źródłowy)
• HTTP Authentication (rozszerzenie filtra per-packet)
• HTTP Object Rate Limiting (per host źródłowy)
• Malformed HTTP Filtering

- DNS
• Malformed DNS Filtering
• DNS Regular Expressions (RegEx)
• DNS Authentication/Anti-Spoofing (rozszerzenie filtra per-packet)
• DNS Query Rate Limiting (per host źródłowy)
• DNS NXDOMAIN Rate Limiting (tylko w trybie in-line)

- SIP
• Malformed SIP Filtering
• SIP Source Rate Limiting


Filtr Zombie Removal
Filtr stosowany w celu odsiania ruchu związanego z atakami typu flood

• Ręcznie lub automatycznie konfigurowane progi pps oraz bps
– każdy adres źródłowy który przekroczy próg pps lub bps zostaje umieszczony
na czarnej liście i cały ruch generowany przez danego hosta jest blokowany
do momentu kiedy natężenie ruchu spadnie poniżej danego progu

– aktywność danego hosta jest monitorowana i mierzona osobno dla każdego
chronionego obiektu (Managed Object)

– natężenie ruchu jest mierzone w oparciu o 1min interwały
• jeżeli host przekroczył któryś z progów w okresie pomiarowym, jego adres jest
umieszczany na czarnej liście
• jeżeli w ciągu kolejnego okresu pomiarowego natężenie ruchu generowanego przez
hosta spadnie poniżej progów, jego adres jest usuwany z czarnej listy


Filtr Zombie Removal

• zalecane jest NIE blokowanie progów podczas konfiguracji szablonu, dzięki
czemu możliwa jest jego zmiana w trakcie trwania ataku


Filtr TCP SYN Authentication

• Filtr stosowany w celu odsiania bezstanowych lub wykorzystujących
fałszywe adresy IP ataków typu TCP SYN Flood
– Ataki stanowe są nadal możliwe ale wymagają znacznie większych zasobów
1. TMS przechwytuje segment SYN od hosta
2. TMS odpowiada segmentem SYN/ACK z błędnym numerem sekwencyjnym
(symuluje istniejącą pół-otwartą sesję)
3. Zgodnie z RFC793 host powinien odpowiedzieć segmentem RST z tym samym,
błędnym numerem sekwencyjnym
4. Jeżeli host odpowie RST z odpowiednim numerem sekwencyjnym, TMS
zezwala czasowo na przesłanie segmentu SYN
5. Jeżeli host wysyła kolejny segment SYN w celu nawiązania połączenia,
TMS uwierzytelnia sesje i przepuszcza segment SYN bezpośrednio do
chronionego serwera
– Pierwsza sesja nie została nawiązana, więc aplikacja nie dostaje informacji o błędzie i
ponawia próbę – uwierzytelnienie jest przezroczyste dla warstwy aplikacyjnej która nie
dostaje informacji o błędzie połączenia
– Nie ma potrzeby wyłączania konkretnych zakresów portów z uwierzytelniania segmentów
SYN


• W przypadku otrzymania trzeciego kolejnego segmentu SYN
od tego samego hosta na ten sam adres docelowy, oraz
braku segmentu RST z odpowiednim numerem
sekwencyjnym, TMS generuje SYN/ACK z unikatowym ISN

– segmenty RST „poza sekwencją” mogą zniknąć w sieci ze względu na zbyt
restrykcyjne firewalle
– w przypadku otrzymania od hosta segmentu ACK z numerem sekwencyjnym
ISN+1, TMS wysyła RST/ACK
– TMS uwierzytelnia hosta i zezwala czasowo (def.60sec) na przesłanie do
serwera kolejnego segmentu SYN



• RFC793 jest nieprecyzyjne w kwestii użycia flag RST i ACK w przypadku
odmowy połączenia na otwarty port TCP
• Interpretacja w systemach *NIX, BSD, LINUX
– RST oznacza „odmowa, usługa dostępna”
– RST/ACK oznacza „odmowa, usługa niedostępna”
– Ponów próbę w przypadku RST, nie ponawiaj w przypadku RST/ACK
• Interpretacja Microsoft Windows
– RST oznacza „odmowa, usługa niedostępna”
– RST/ACK oznacza „odmowa, usługa dostępna”
– Ponów próbę w przypadku RST/ACK, nie ponawiaj w przypadku RST
• Większość stacji klienckich działa pod kontrolą systemu MS Windows
dlatego TMS resetuje sesje uwierzytelniającą flagami RST/ACK


Filtr HTTP Authentication

• Jeżeli uwierzytelniona sesja TCP jest zestawiana na port wskazany jako port
obsługujący serwer HTTP, host zostaje poddany weryfikacji „stanowej”
obsługi HTTP
• TMS weryfikuje obecność żądania GET lub HEAD w segmencie
• Odpowiada przekierowaniem na wygenerowane URI
• Jeżeli host zestawi nową sesję z żądaniem wskazanego URI, zostaje
uwierzytelniony
• TMS odpowiada przekierowaniem na pierwotnie żądane URI
• Host może zestawiać kolejne sesje HTTP do serwera docelowego – jest
wpisywany na biała listę dla adresu serwera/portów skonfigurowanych jako
obsługujące http
• Host który nie przeszedł weryfikacji HTTP, ale przeszedł weryfikację TCP,
może nadal inicjować sesje TCP na pozostałe porty
• Dla ruchu TCP na porty powiązane z HTTP, umieszczany jest na czarnej
liście na konfigurowalny okres czasu


Filtr HTTP Authentication


Filtr DNS Authentication: Active TCP

• Klient wysyła standardowo datagram UDP z zapytaniem DNS
• TMS przechwytuje zapytanie
• TMS wysyła pustą odpowiedź (de facto zawierającą oryginalne
zapytanie) z ustawionym bitem TC w nagłówku DNS
• Ponieważ odpowiedź nie zawiera oczekiwanej przez klienta informacji,
klient respektuje flagę TC i wysyła zapytanie ponownie
– w sytuacji kiedy zostało skonfigurowane uwierzytelnianie zapytań DNS przy pomocy
flagi TC, TMS nie uwierzytelnia segmentów TCP SYN na port 53. TCP SYN na port 53
podlega tym samym ograniczeniom częstotliwości co zapytania UDP
• TMS widząc segment TCP SYN na port 53 od tego samego hosta,
przepuszcza go i pozwala zestawić sesje TCP. Następnie przy pomocy
filtra warstwy aplikacyjnej weryfikuje czy host ponowił zapytanie. Jeżeli
tak, host jest wpisywany na biała listę dla zapytań DNS
• W przypadku braku TCP SYN od danego hosta, nie uzyskuje on dostępu
do serwera DNS


Filtr Malformed Payload Detection i RegEx

• Wszystkie pakiety wysyłane na porty asocjowane z DNS, HTTP, SIP, są
dekodowane i weryfikowane pod kontem odpowiedniego payloadu
• Jeżeli pakiet nie zawiera odpowiedniego PDU, pakiet jest odrzucany
• Jeżeli faktycznie zawierają payload, struktura PDU aplikacji jest
sprawdzana pod kontem zgodności z RFC
• Jeżeli PDU aplikacji nie jest zgodne z RFC, pakiet jest odrzucany
• Jeżeli dla nagłówków danej aplikacji zostały skonfigurowane filtry
RegEx, filtry te są ewaluowane na tym samym etapie


Filtr TCP Idle Reset
• dwa timery: short timer i long timer
• Short timer jest uruchamiany w momencie pojawienia się
sesji TCP od nowego hosta
– Jeżeli przez określony czas host nie wyśle prekonfigurowanej ilości
bajtów, TMS resetuje sesje po stronie serwera i daje jeden punkt
karny
• Long Timer jest resetowany za każdym razem kiedy TMS
zobaczy segment nie-RST i nie-FIN od danego hosta
– Jeżeli segment się nie pojawi, sesja jest resetowana i host dostaje
jeden punkt karny
• Jeżeli host zbierze określoną liczbę punktów karnych, trafia
na czarną listę
• Bardzo skuteczne przeciwko atakom NAPHTo-pochodnym


Filtr TCP Idle Reset
• dwa timery: short timer i long timer
• Short timer jest uruchamiany w momencie pojawienia się
sesji TCP od nowego hosta
– Jeżeli w przez określony czas host nie wyślw prekonfigurowanej
ilości bajtów, TMS resetuje sesje po stronie serwera i daje jeden
punkt karny
• Long Timer jest resetowany za każdym razem kiedy TMS
zobaczy segment nie-RST i nie-FIN od danego hosta
– Jeżeli segment się nie pojawi, sesja jest resetowana i host dostaje
jeden punkt karny
• Jeżeli host zbierze określoną liczbę punktów karnych, trafia
na czarną listę
• Bardzo skuteczne przeciwko atakom NAPHTo-pochodnym


Filtr Baseline Enforcement
• Na podstawie danych z kolektorów, tworzone są profile
bazowe dla top 200 /24 sieci, z ostatnich 48 godzin
• Dla każdej sieci /24 nie mieszczącej się w top 200,
brany jest najniższy profil bazowy
• Jeżeli któraś sieć przekroczy 5x profil bazowy, ruch jest
dropowany lub shapowany
• To samo jest robione dla 100 protokołów
• Jeżeli jakiś protokół ma baseline mniejszy niż 10kbps,
TMS blokuje protokół jeżeli przekroczy 50kbps
• Jeżeli ma większy niż 10kbps, zawsze go przepuszcza
• To samo w odniesieniu do GeoIP
• Dodatkowo raw rate limiting per protocol



Pytania?
maciej.rzehak@trecom.pl


Trecom - DDoS Detekcja-obrona

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Trecom - DDoS Detekcja-obrona

Ähnlich wie Trecom - DDoS Detekcja-obrona (20)

Trecom - DDoS Detekcja-obrona