Názory k článku Novinky v Knot Resolver 6: ochrana před DoS útoky – přehled pro operátory

A jestlipak Knot Resolver 6 bude i v Turris OS ? Pan V.Cunat by to jiste mohl odpovedet, zda a kdy se tak stane ci nikoliv.... Dekuji

26. 7. 2024, 15:18 editováno autorem komentáře

Rozhodně bude, ale teď neumím říct kdy.

Respektive, už půl roku tady možnost nainstalovat je: https://forum.turris.cz/t/turris-os-6-5-in-rc/19513/27

Ale objevily se tam bohužel balíčkovací potíže s novými částmi pro konfiguraci a správu procesů, zatím nevyřešené. Bez těchto částí není velká motivace verzi 6 používat, možná tedy až v 6.x bude tato DoS ochrana (i když v principu cílí spíše na větší servery než Turris).

Pak máme v těch částech ještě nedořešený problém pro systémy bez libsystemd, tam tedy Turris OS taky spadá (a pro ne-Linuxy je tam ještě další problém navíc).

Také bude v Turris OS komplikace, že konfigurace není pouze psána uživateli. Ti naklikají něco v reForisu, z čehož vzniknou nějaké hodnoty v UCI. A ty vytáhne init skript a promítne je do konfigurace své služby (Knot Resolveru, v našem případě). Tady konkrétně zatím nevím o jednoduché metodě, jak zmergovat tu vygenerovanou konfiguraci s případnými modifikacemi od uživatele (protože řadě lidí reForis nestačí).

Samozřejmě Knot Resolver 5.x nadále dostává bezpečnostní opravy, atd. (tento týden například)

Proč je zvolen exponenciální pokles hodnoty čítačů v čase a ne třeba lineární? Ne že by mi to připadalo špatně, ale zajímalo by mne, jaká za tím byla úvaha.

Lineární pokles by byl nejjednodušší na výpočet (odečtení konstanty za krok) i na konfiguraci (okamžitý limit by odpadl). Exponenciální pokles je asi druhá nejjednodušší možnost (vynásobení konstantou za krok).

Mimochodem exponenciála není nějaká horká novinka pro podobné účely, čtenáři Rootu jistě znají load average. A matematicky je zajímavé, že aritmetický průměr za posledních X minut by byl mnohem dražší na paměť.

Pro vysvětlení volby u nás je asi lepší se nedívat na to co s čítači děláme v jednom kroku, ale na to jaká je definice jeho hodnoty v daný moment (pomiňme zaokrouhlovací nepřesnosti). Tedy jakoby expandovat tu řadu operací z celé historie.

S lineárním vidím potíž, že události co se děly teď mají stejnou váhu jako ty co se děly dříve, tedy až do situace kdy "spadneme na nulu" a tím se historie vymaže. S exponenciálním si jakoby pamatujeme celou historii, ale váha události hladce klesá dle jejího stáří.

A proč takovou vlastnost tady vidím jako prospěšnou? Chci zvýhodnit uživatele co generují rovnoměrnější zátěž před těmi co posílají stejné množství práce v intenzivních pulzech. Je to prostě méně náchylné na chvilková přetížení.

Opravdu máte jeden counter pro každou IPv6 adresu? Myslel jsem, že každý kdo má IPv6, má automaticky alespoň /64. To znamená, že útočník může bez vynaložení velkého úsilí požít 2^64 různých adres. Opravdu server sleduje counter pro každou adresu zvlášť?

Ano. Čítače časem klesají k nule a tedy ty co se nějakou dobu nezvedly nejsou zajímavé, lze je v klidu zapomenout. Navíc výkon serveru je omezený, tedy množství přišlých dotazů v čase, z čehož jde odhadnout kolik má smysl na tohle nakonfigurovat paměti (třeba příklad v Knot DNS dokumentaci).

Pro práci s tou hromadou čítačů jsme napsali vlastní pokročilou datovou strukturu. Máme i rozepsaný podobný text jako tento, který ji přibližuje. Ale je to mnohem detailnější záležitost, která je zajímavá spíše algoritmicky než pro uživatele.

28. 7. 2024, 09:38 editováno autorem komentáře

Nějaká super hash table? Těším se na další článek.

Ano, hašování tam hraje velkou roli.