Názory k článku Novinky v Knot Resolver 6: ochrana před DoS útoky – technické řešení
-
a co běh na jiných cpu než x86?
Moc pěkný popis a algoritmus na obranu proti DoS. Dokázal bych si představit, že by podobná implementace mohla být užitečná i u dalších služeb.
Máte někde měření i z reálných podmínek? To hešování zdrojových IP adres a zreduktování ukazatelů na kolizních 16b totiž na první pohled vypadá dost úzce a na nějakých edge serverech pro kontinent to může být úzké hrdlo, ale třeba se to v praxi dobře zarovná.
Aneb řečeno, přemýšlím za kolik IP adres musím v UDP zfalšovat, abych způsobil DoS Knot resolveru.
-
Zdravím a děkuji za pochvalu.
Z optimalizací je na x86_64 explicitně omezena jen vektorizace, která navíc vyžaduje příslušná rozšíření instrukční sady (AVX, atp.). Ke kódu, který tyto instrukce využívá, máme i alternativní variantu bez vektorizace. Výsledná binárka pak podle architektury obsahuje buď jen nevektorizovanou variantu, nebo obě a za běhu se z nich vybere podle dostupnosti daných rozšíření.
Pokud by procesor nepodporoval prefetch pro dřívější načítání řádků keše, tak tu instrukci může kompilátor vynechat, příp. procesor ignorovat. A pokud by velikost řádku keše nebyla 64 B, tak jich může být potřeba načíst více. Ostatní optimalizace by vesměs měly fungovat i jinde.
Co se týče armu, tak podle krátkého hledání na webu (sám o tom moc přehled nemám) můžou mít velikost řádku keše i 32 B, což neporuší zarovnání těch 64 B skupin, takže by se to pořád mělo chovat dobře; prefetch by aspoň některé army měly taky podporovat. Tohle možná bude třeba zjistit pro konkrétní procesor.
Měření máme jen na generovaných datech, podle nichž jsme vybírali z více variant datové struktury a nastavovali výchozí velikost tabulky. Konkrétní čísla teď nemám, ale vypadalo to funkčně.
U těch 16b hešů je hlavní, že spolu můžou kolidovat jen záznamy, které vidí do stejné (15 prvkové) skupiny -- tedy pro 2 záznamy, každý uvidí 2 skupiny a aspoň jedna z nich bude sdílená. Pokud by nám na tomto místě docházelo k výraznějším kolizím, tak nejspíš máme větší problém s místem jen pro 15 prvků.
Procento záznamů, které spolu takto můžou kolidovat, lze libovolně snížit zvýšením velikosti datové struktury (počtu skupin), což je konfigurovatelný parametr. Pro výběr skupin, kam vidí konkrétní záznam, se už používá heš s počtem bitů podle velikosti tabulky.
A počet záznamů, které budeme chtít uložit do KRU, je dobře omezený tím, kolik dotazů zvládne daný server zpracovat za jednotku času -- než se exponenciálním snižováním předchozí záznamy z KRU pozvolna vytratí. Tedy pokud server zvládne N dotazů za sekundu a rate limit máme R dotazů za sekundu, tak může být současně maximálně N/R klientů přes limit, nastavením velikosti tabulky na nějaký vhodný násobek tohoto čísla by pak mělo fungovat dobře.
Distribuovaný DoS útok z mnoha adres/sítí od běžného provozu odlišit neumíme, s tím nám KRU nepomůže. Pokud ale půjde jen o falešné adresy UDP paketů, tak by pořád mohlo fungovat odpovídání na dotazy přes TCP, protože se při přetížení snažíme zpracování UDP a TCP vyvažovat.
-
děkuji za informacre.
To vidím z kódu, podle mě by ty optimalizace mohly i fungovat na armech, ale zajímalo mě, jestli jste to testovali. Dnes se má doba tak, že začínáme ve velkém nasazovat army na infrastrukturu, protože Intel je blázen a čekat 3/4 roku na dodávky je moc.
Odpověď na dotazy přes TCP se ale zapíná pouze podle zdrojové IP u UDP paketu, ne? Nebo to umí udělat při vysokém zatížení pro všechny? (Možná je popsané, nevidím). Občas vídám útoku typu plošný nálet falešných zdrojových IP u UDP.
K DDoS útokům by ale hodně pomohlo, kdyby ty KRU tabulky šlo sychronizovat s dalšími instancemi resolveru. Dokonce by bylo skvělé, kdyby bylo možné je aktualizovat z třeba z jiného dohledového systému, kdy řešení na FW je příliš invazivní.
-
Výkon se testoval pouze na x86_64. Zatím jsem neslyšel o nasazení Knot DNS nebo Knot Resolver s větší kapacitou na něčem jiném, takže z mého pohledu by zatím bylo poněkud předčasné věnovat velkou energii specificky armům.
Vynucení TCP: to ale není kvůli snížení zatížení resolveru. TCP naopak zatížení zvýší, alespoň pokud ho klienti použijí. Je to primárně kvůli reflection - tedy generování velkého UDP provozu na adresy nebo sítě které ty dotazy neposlaly (falešné zdrojové IP).
Synchronizováno je to v rámci jednoho stroje. Z mého pohledu dneska jeden stroj dokáže obsloužit obrovské množství provozu. Samozřejmě je spousta směrů kterými vylepšovat, časem se uvidí.
-
u UDP dotazů se falšovanými zdrojovými adresami by to mělo zatížení snížit, protože dotaz po TCP už nepříjde, ne?
Chápu, také s armem na tyhle služby jen experimentujeme. Chápu, že jste to netestovali.
Jeden stroj se ale může porouchat nebo občas potřebuješ udělat nějako údržbu, tak je škoda zahodit KRU a tvořit si jí zase znovu s rizikem, že se nějakou dobu budeš stabilizovat. Řešení je asi mít rovnou více aktivních instancí a případně novou čistou instanci zapojovat do provozu postupně.
-
My TC=1 odpověď zasíláme aniž bychom dotaz skutečně řešili, takže v téhle první fázi to je i levnější. A tedy záleží, jak velká část bude následně zkoušena přes TCP a třeba jestli ti klienti umí znovu-používat otevřené spojení nebo budou otevírat nové pro každý dotaz.
Podobně jak s naší cache by mělo jít ten soubor prostě zkopírovat na novou instanci, ale nemám domyšleno (myslím že drobná úprava kódu by byla potřeba) a zatím to takhle nikdo dělat nebude.
