Protokoly WHOIS a RDAP jsou základními nástroji pro přístup k informacím o objektech v registru .cz domén spravovaném sdružením CZ.NIC. Je proto důležité, aby byly tyto služby stabilní, dostupné, a dokázaly odbavit potřebný počet požadavků i v případě zvýšeného provozu. Z tohoto důvodu je nutné mít nastavený rate-limiting, který mimo jiné brání jednomu subjektu vyčerpat kapacitu systému, a to nejen v případě DoS útoku.

Původní pravidla pro rate-limiting vznikala v době, kdy byly běžné „souboje o domény“, tedy kdy se více subjektů snažilo odchytit uvolněné domény se zajímavými doménovými jmény a potenciálně vysokou hodnotou. Opakované dotazy pomocí WHOIS,  RDAP a EPP rozhraní byly součástí tohoto procesu. Přece jenom, ten kdo se první dozví o uvolnění domény může provést její registraci dříve než ostatní, takže rozhodují vteřiny. Po zprovoznění systému aukcí domén, o kterém jsme nejen zde na blogu už mnohokrát napsali (například zde), tato potřeba velmi výrazně poklesla. To nám, spolu s postupnou obměnou a posílením infrastruktury, umožnilo podívat se na pravidla limitující dotazy do registru znovu a zamyslet se nad jejich nastavením.

Rád bych vám přiblížil celý tento proces podrobně, ale to nejpodstatnější je potřeba napsat hned na začátek: Od úterý, 12.11.2024 začnou platit nová pravidla, která současný stav výrazně zjednoduší. Nově budou limity pro každou službu následující:

1 req / sec pro IPv4 adresu
1 req / sec pro /64 IPv6 subnet
100 req / sec globání limit

Tyto limity jsou ve všech případech výrazným navýšením oproti stávajícímu stavu a vycházejí z důkladné analýzy dosavadního provozu a současné konfigurace, kterou jsme provedli v předchozích měsících. Zároveň bych ale rád zdůraznil, že po této změně budeme provoz na WHOIS a RDAP nadále monitorovat, a jsme připraveni limity upravit podle provozních potřeb. Naším cílem je co nejvyšší dostupnost (nejen) těchto protokolů, ne jejich umělé zpomalování.

Současný stav

Jak jsou tedy pravidla nastavena teď? Pro oba protokoly se liší a to pouze z historických a implementačních důvodů. V případě RDAPu provádíme omezování nejen na úrovni firewallu, ale také přímo v rámci webového serveru Nginx. Limit v rámci Nginxu je 5 dotazů za minutu pro každou IPv4/IPv6 adresu, na firewallu pak zároveň filtrujeme provoz nad 30 dotazů za minutu pro každou IPv4 adresu, případně 10/min pro /64 subnetu IPv6. Určitě vidíte, že je zde mnoho nedokonalostí. Překročení limitu na úrovni Nginxu znamená odpověď s HTTP návratovou hodnotou 503, ale překročení na firewallu znamená zahození spojení a timeout. Ani v jednom případě nejde o dobrou zpětnou vazbu, ale jejich kombinace uživatele mate ještě více. WHOIS má limity pak mnohem nižší. Veškerý provoz je omezený na 8 dotazů za minutu pro IPv4 /24 subnetu, 8 dotazů za minutu pro IPv6 /64 subnetu, a zároveň 14 dotazů za vteřinu globálně. Limity jsou realizovány přesměrováním na banner s informací o překročení povoleného počtu spojení. Limity jsou vždy brané pro subnet a ne pro jednotlivé adresy. Je tedy možné, že uživatel dostane informaci o překročení počtu povolených spojení i při prvním, ručně provedeném dotazu, protože se ve stejném časovém okně dotazoval někdo jiný ze stejné sítě.

Výkon

První, co bylo potřeba zjistit, je, jaké vlastně máme možnosti. Ve spolupráci s kolegy z oddělení SQA jsme v létě provedli výkonnostní testování jak WHOISu, tak RDAPu. Získali jsme tak spoustu informací a podnětů ke zlepšení, hlavně jsme ale našli limity systémů v současném stavu. Je třeba zdůraznit, že provozovat tyto služby blízko jejich limitům není vhodné, protože jsou úzce provázané se zbytkem registru. I případné přetížení tohoto read-only rozhraní tak může mít negativní vliv na ostatní systémy, ze kterých se registr skládá. Výkonnostní testy ukázaly, že dokážeme odbavit minimálně o řád více, než je momentální špičkový provoz. To ale neznamená, že usneme na vavřínech; testy nás upozornily na místa, kterým by bylo dobré se věnovat a celý systém tak do budoucna dále posílit.

Sběr a příprava dat

Jak můžete vidět na stránkách stats.nic.cz, informace o úspěšných dotazech do RDAPu i WHOISu logujeme a dokážeme s nimi pracovat. Data o odmítnutých spojeních nebyla takto detailně zpracovávána, a tak bylo potřeba upravit konfiguraci firewallu a všechna odmítnutá spojení logovat. Pro každou kombinaci služby a verze IP protokolu jsem připravil samostatný CHAIN, který mimo samotné odmítnutí provozu zároveň logoval se specifickým prefixem. Podle prefixů pak Syslog-ng přesměroval výstup do souborů. Protože tento postup generuje velké množství dat, bylo také potřeba upravit Logrotate, aby korektně rotoval a komprimoval staré logy. Data odmítnutých spojení RDAPu z Nginxu se už logovala v rámci Nginxu, nebylo tedy potřeba konfiguraci nijak upravovat.

Ve stovkách MB dat v textových souborech rozmístěných po několika serverech se ale špatně hledá. Dalším krokem tedy bylo agregovat všechna data do databáze. Pomocí Dockeru je nasazení lokální instance PostgreSQL databáze naprosto triviální, do souboru docker-compose.yml jsem přidal pouze proměnné definující databázového uživatele a heslo (a editor, protože vim je nutností. = ) ), namapoval jsem si statické úložiště dovnitř kontejneru a pomocí docker compose up -d jsem měl k dispozici kontejner s běžící databází, jen se připojit.. Celý docker-compose.yml je k nahlédnutí níže:

services:
  db:
    image: postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: ratelimit
      POSTGRES_PASSWORD: password
      EDITOR: vim
    volumes:
      - ./pgdata:/var/lib/postgresql/data 
      - ./csv_data:/var/csv_data

Data z logů jsem pak pomocí jednoduché pipeline v AWK zpracoval do formátu CSV, který umí Postgres nativně importovat, a po chvilce byla databáze připravená. Stejným způsobem jsem pak zpracoval data o úspěšných dotazech. Výsledkem je databáze Postgres s kompletním otiskem provozu služeb WHOIS a RDAP za 7 dní. U neúspěšných dotazů logujeme pouze datum, čas, službu a IP adresu, u těch úspěšných pak také dotazovaný objekt a (v případě RDAPu) i odpověď serveru. Databáze obsahuje cca 40 000 000 záznamů a má velikost kolem 3 GB.

Analýza

Nad takovýmto datasetem je radost pracovat – není tak velký, aby bylo potřeba používat big-data postupy a nástroje, ale zároveň je dostatečný na to, aby se projevily zcela jasné trendy. Hlavním zjištěním je, že ani součet přijatých a odmítnutých dotazů se neblíží k nově navrhovaným globálním limitům. Je samozřejmě otázkou, jestli zvýšení limitů nezpůsobí v rámci indukované poptávky také zvýšení provozu, a nejen tohle budeme po nasazení monitorovat. A nyní pár zajímavých zjištění.

RDAP

 

RDAP je mladší a méně známá služba a je to znát. V porovnání s WHOISem na něj směřuje cca 16 % provozu. Zároveň je ale cca 1/4 spojení na naše RDAP servery po IPv6. Údaje o blokovaných spojeních ale překvapily – ve sledovaném týdnu jsme blokovali cca 1700 adres na úrovni webového serveru a cca 350 adres na firewallu. Úspěšné dotazy pak pocházejí z 1 400 000 adres. Další zajímavostí je, že 98 % spojení blokovaných firewallem přichází pouze ze dvou IPv4 adres. Kadence, se kterou se tyto adresy snaží připojit, způsobuje, že poměr jejich úspěšných dotazů se pohybuje kolem 1 % – občas je lepší trochu zvolnit. Pokud ale vyřadíme ze statistiky tyto dva výrazně vyčnívající údaje, ukáže se, že celkově je úspěšných více než 95 % dotazů, a to před plánovaným navýšením limitů. Dalším zajímavým zjištěním je výskyt uživatelů/IP adres, které opakují stále stejný dotaz na jednu doménu. Je možné, že RDAP používají jako jakýsi watchdog stavu domény, i když pro podobné účely poskytujeme jiné a přehlednější nástroje, jako například Doménový prohlížeč.

WHOIS

 

V případě WHOISu se čísla výrazně mění. Poměr spojení po IPv6 se snižuje na cca 1/10 celkového provozu, což více odpovídá globálním statistikám rozšíření IPv6 protokolu. I ostatní metriky mají méně extrémů a nejsou příliš překvapivé – firewall zachytil spojení od 900 000 adres, úspěšné dotazy jsou pak od 1 000 000. Deset nejblokovanějších adres se podílí na 18,5 % všech blokací, dalších 10 pak na 4 % – to je také celkem v souladu s Paretovým pravidlem. Pozitivně pak vyznívá fakt, že i nejblokovanější adresy mají průměrně cca 10% úspěšnost. I přes agresivně nastavené limity nedochází k absolutní blokaci jednotlivých uživatelů. Naopak adresa s největším počtem úspěšných dotazů má jen cca 10 % blokovaných spojení – znovu se ukazuje, že snažit se o co největší kadenci není vždy nejlepší strategie.

Oproti RDAPu nepozorujeme skoro žádné adresy dotazující dokola jednu doménu. Co mě ovšem překvapilo, je, že v logu úspěšných dotazů je 50 /24 IPv4 subnetů, které pro své dotazy používají všechny své adresy. Předpokládáme, že se jedná o snahu o data-mining; provoz generovaný těmito subnety je ale na úrovni statistické chyby a nezpůsobuje žádné zahlcení služby. I tak ale tyto pokusy budeme nadále monitorovat. Nejpodstatnější informací ale je, že zahazujeme více spojení než úspěšně odbavíme. I přesto je součet úspěšných a neúspěšných spojení na úrovni cca 35 % nově navrhovaných limitů, jejich nasazení by tedy v případě WHOIS-u mělo mít jasně pozorovatelný pozitivní vliv na dostupnost služby.

Závěrem

Najít hodnoty pro rate-limiting takové, aby vyvážily zátěž infrastruktury a dostupnost služeb, není triviální. Vždy se najde někdo, kdo je považuje za nedostatečné a komu naše blokace může narušovat způsob, jakým by chtěl tyto služby využívat. Proto jsme nastavení nových limitů nebrali na lehkou váhu a snažili se získat co nejvíce informací z reálného provozu. Nejen díky pravidelným obměnám naší infrastruktury se nyní cítíme dostatečně jistí v jejich výrazném navýšení. Věříme, že výsledek bude pro všechny naše uživatele pozitivní a že tento článek nechá nahlédnout pod pokličku toho, co je pro dobrou konfiguraci veřejně dostupných rozhraní potřeba.

Autor: Jan Hroten