Názory k článku Jak se staví CDN: bezpečnost, monitoring a tipy z praxe

Chtěl jsem autorovi poděkovat za velmi pěknou sérii. Pro mě byla určitě dost přínosná.

>
Dovolím si taky jedno malé off-topic zbožní přání, za které mně někteří nebudete mít rádi. Znám hodně velmi talentovaných lidí z IT oboru (bez ohledu na rodinný stav), kteří ale obrovské množství času investují do hraní her.

No, mě hraní v rozumné míře nevadí, ale co mi hlava nebere když programátor sedne k něčemu, kde zase namáhá hlavu. :-))

Jinak: moc by se mi líbil článek s aktuálními poznatky týkající se tuningu IP stacku (routing, sockety, TPROXY, atd).
Blog cloudflare celkem sleduju a je mi jasné, že lidé kolem CDN tyhle poblémy řeší celkem často.

Ten můj off-topic komentář byl opravdu nevhodný a omlouvám se za něj. Do technického článku prostě nepatřil, takže jsem požádal o jeho odstranění. Mír :-)

Ten autorův trapný off-topic mě, jako hráče, nakrklo. Myslí si snad autor, že mě baví přemýšlet v práci a pak ještě po ní ve volném čase? Člověk také potřebuje chvíli vypnout (sport, koníčky, sledování filmů, seriálů, hraní her)...

Autor si asi myslí, že to jeho řádění na kole a procházky po horách mají větší společenský přínos, po kterém u ostatních tak volá. Nebo tím jen maskuje svůj osobní světonázor, že hraní je špatné a člověk toho pro sebe víc udělá něčím jiným. Podobně to mají třeba jehovisti, kteří musí mermomocí ostatní přesvědčovat o své *absolutní* pravdě.

Do tak pěkného technického článku podobné věci nepatří, to je tak na osobní blog autora.

Dohodli jsme se s autorem na odstranění toho odstavce. Už je z článku pryč, skutečně to byl zbytečný úkrok stranou.

Kdyz jsem byl malej, vsichni furt rikali, nesed u toho pocitace! Budes mit zkazeny oci! Bez radsi ven. A dnes? Sed u toho co nejvic, rika se tomu prace, tak u nej sed, nejlepe 12h denne :-))

Clanek hodne dobry, ne kazdy je ochotny se podelit se svym resenim. Co je zarazejici je:

Pokud si robustní DDoS ochranu neplatíte, počítejte s tím, že v případě masivního útoku vám jenom ISP zavolá..

Toto je fascinujici, protoze cely clanek je defacto seznamem velkeho mnozstvi ochranych opatreni, monitoringu etc.

Do jake miry je ekonomicky rentabilni stavet vlastni ochranu? Nevyplati se v urcitem momentu investovat do reseni vetsiho providera poskytujiciho robustnejsi ochranu a usetrit na komplexnosti vlastvi konfigurace?

Ano, tam kde vám to dává ekonomicky smysl, je dobré investovat do komerčního řešení, i proto u některých PoPů využíváme např. Arbor od NETSCOUT (kdysi Arbor Networks). Někde může dávat smysl využít např. HW typu RadWare. V případě, že máte po světě desítky PoPů a chtěli byste opravdu ochránit všechny, měsíčně vás to vyjde na statisíce.

Mluvím jenom za sebe a za mé zkušenosti, ale optimální je mít rozmyšlené a implementované DoS/DDoS ochrany na všech úrovních, kde to lze. Univerzální řešení pro všechny typy a velikosti DoS/DDoS útoků totiž podle mně neexistuje. Např. zmíněný Arbor je vhodný pro mitigaci nejrozsáhlejších útoků o stovkách Gbps, ale není u něj vhodné mít prahové hodnoty na různé senzory nastavené příliš nízko, protože když se detekuje překročení a zahájí se mitigace a čištění provozu přes zahraniční "čističky", často dochází i k částečnému zahazování legitimního provozu, kdy pak s podporou trávíte spoustu času analýzou, proč a za jakých okolností k tomu docházelo. I když pak na něco přijdete a něco s poskytovatelem upravíte, reálně to otestujete až s dalším útokem. Ten může přijít v ten samý den, nebo třeba za X let.

Pro menší útoky, které jsou pod prahovými hodnotami např. zmíněného Arboru, je zase vhodné mít nějaké ochrany na vlastních routerech s ještě pořád dost vysokými limity, které ustojí routery a na úrovni serverů a webserverů zase jemnější limity pro útoky na L7, kde už můžete mít různé limity pro různé vhosty nebo dokonce jednotlivé URL masky či HTTP metody.

Považuji proto za lepší to posichrovat na více úrovních. Dobře rozumět a sledovat síťový provoz, znát peaky provozu, orientovat se dobře v dostupných možnostech HW či SW ochran, implementovat a testovat. Vždy ale potřebujete data a statistiky a to jak pro nastavení vhodných prahových hodnot, tak pro zpětnou analýzu proběhlých útoků. Začíná to globálním měřením Bps/pps, pak po jednotlivých síťových protokolech až po dostupné metriky z jednotlivých HTTP(S) požadavků.

I já sám se často vnitřně ptám, kde je ta míra si radši něco zaplatit a spoléhat že to vyřeší všechny naše problémy v dané oblasti vs. dávat něčemu vlastní čas, jít do hloubky, navyšovat interní náklady ale zároveň budovat naše hardskilly a know-how. Pokud je to součástí našeho řemesla a pomáhá nám to na denní úrovni i při vývoji a provozu jiných projektů, má to smysl.

Pro spoustu lidí a firem je osvobozující projekt vyskládat z několika komerčních řešení a když se něco pokazí, zříct se odpovědnosti, zalámat rukami s odvoláním se na cizí řešení. Úplně je chápu a nedivím se jim a často to dává i největší technický či obchodní smysl. Každý má možnost svojí volby a na své váhy při rozhodování pokládá něco jiného ;-)

Jako ochranu před DNS spoofingem bych doporučil hlavně DNSSEC (nejen zapnout pro dané domény, ale hlavně na edge serverech validovat.

nftables/iptables firewall na port mi připadá zbytečný – pokud vám na těch serverech bude na portech naslouchat něco, o čem nevíte, máte nejspíš mnohem větší problém než to, že se na to někdo z venku může připojit. Ale pokud v těch pravidlech bude jen kontrola portu, bude režie takového firewallu neměřitelná, takže asi ničemu nevadí.

K těm X-… hlavičkám bych doplnil hlavně Content-Security-Policy – ta většinu starých bezpečnostních nestandardních X-… hlaviček nahrazuje.

Dobrý den,

S chutí jsem přečetl vaší sérii článků o CDN. Po přečtení posledního dílu mám několik otázek.

Ze článků to působí tak, že stavba vlastního CDN je především věc zdrojově velmi náročná, jak časově v rámci nutných znalostí lidí (pokročilé znalosti z IT infrastruktury, administrace, networkingu, zkušenosti z praxe, aktuální vývoj trhu), tak čas samotný pro realizaci a hlavně(!) čas, který je nutné věnovat provozování 24/7/365 této služby.
Umět skloubit správně nastavení (což je prakticky minové pole, které se v čase vyvíjí), držet krok s dobou, update / security management jednotlivých komponent - to nepochybně vyžaduje čas týmu zkušených lidí. Dále je zde nutná vytvoření a udržba poměrně rozsáhlé dokumentace, vytvoření modelu zastupitelnosti a ostatních postupů nutných pro provoz. Nutnost dedikováného teamu je samozřejmostí.

V prvním článku této série jste vyčíslil jako možnou alternativu u dedikovaných CDN za 20-30 tisíc měsíčně, případně větší providery, kteři začínají na 100 tisících.

Vám se opravdu finančně vyplatí vyvinout, naprogramovat, otestovat, integrovat do produkce, spravovat a podporovat takový projekt v situaci kdy vámi popsaná alternativa stojí 25 tisíc korun měsíčně (vámi uvedená střední hodnota)? Příjde mi stěží uvěřitelné, že vše výše se dá zvládnout pod 25 tisíc měsíčně.

Jaká je přesně přidaná hodnota spravovat takový projekt ve firmě oproti zvolení služby poskytovatele, který má ne tým, ale celou společnost dedikovanou pro tento účel?

Z pohledu majitele menší it firmy, náklad 25-100 tisíc (tedy v podstatě měsíční náklad na jednoho administrátora, a jeden administrátor výše jmenované určitě nezvládne) za outsourcování CDN na profesionální firmu mi přijde jako více než dobrá nabídka.

Takto se mi to jeví jak "hobby" projekt zaměstnanců firmy, ale najímat lidi na správu takového projektu bych ani ve snu nechtěl.

Tohle je CND specialne pro weby s celosvetovou dostupnosti pro zakaznika, ktery chce byt vsude dostupny a rychle. Nejedna se uplne bezneho "as a service" poskytovatele a asi se to vyplati.

Děkuji za tento zajímavý a pochopitelný dotaz. Určitě se na to ptá více lidí. Já popíšu náš pohled, naší situaci a motivaci.

Cílem těchto článků bylo dát návod k tomu, jak si CDN sestavit a upozornit i na to, na co všechno je potřeba při její implementaci myslet. Když jsem to začínal psát, říkal jsem si, že chci pomoct 3 skupinám - ušetřím čas těm, kteří by podobné řešení začali stavět, pak že odradím a pomůžu se lépe rozhodnout těm, kteří by se do toho chtěli pouštět a přitom je pro ně lepší pronajmout komerční řešení a na závěr, že v tom najdou nějaké zajímavé myšlenky a inspirace správci webových serverů.

V našem případě toto řešení dávalo technologický i ekonomický smysl - měli jsme pro to reálnou potřebu i interní kapacity, potřebné know-how (i když jsme v něčem museli jít do ještě větší hloubky, ale to je jenom plus i kvůli vývoji a provozu jiných projektů), máme automatizační nástroje a s tím související interní procesy a z části i servery a již běžící spolupráce s některými ISP.

Kvůli provozu našich projektů stejně pečujeme o více než 100 serverů ve 3 datacentrech v ČR, takže spravovat, aktualizovat, monitorovat a zálohovat pár dalších ve světě, pro nás není téměř žádná režie navíc.

Mimochodem, tím, že jsme se rozhodli dělat PoPy svým způsobem "nestavové" (neřídí to žádný centrální a dynamický mozek), ale každý server je samostatná jednotka s pár interními procesy na pozadí, prakticky nedochází k žádným provozním problémům, které by vyžadovali něčí čas. V podstatě stačí jednou za pár týdnů věnovat 1-2 hodiny otestování a nasazení bezpečnostních aktualizací, ale s tím nám pomáhá Ansible. Každé ráno věnujeme několik minut prohlédnutí vygenerovaného reportu se stovkami grafů a občas je potřeba prověřit nějaké anomálie. Jednou za pár dní či týdnu je potřeba prověřit hlášení z monitoringu. Jednou za pár měsíců je potřeba nějaké komunikace s ISP, např. v případě problému s nějakým serverem či konektivitou, ale jinak za tím nejsou žádné šílené náklady. Samozřejmě do toho teče i nějaký další čas, ten už je ale čistě dobrovolný, kdy někdo ze svého osobního zájmu o danou oblast a problematiku analyzuje data a chce to posouvat dál a dál. Ta core funkčnost CDN by ale přežila i bez toho.

A co se týče vynaloženého času na další rozvoj CDN a jejich funkcionalit - tím, že téměř všechny naše projekty jak vyvíjíme tak provozujeme se vším všudy a je to náš denní chleba, tak potřebné sledování vývoje technologií, best-practices, postupů, nástrojů, ochran, prohlížečů... i následné implementace do projektů či serverů ... to je interní proces, který běží nepřetržitě bez ohledu na to, zda bychom vlastní CDN měli, nebo ne. Chceme a potřebujeme svému řemeslu rozumět. Máme na tom osobní zájem a je to součástí toho, co nás živí a baví. Pak už záleží na tom, na co se kdo specializuje, kde vnímá, že to jeho řemeslo začíná a končí a jak vnímá capex/opex náklady vs. hodnotu nabytých znalostí, co může být dobrá investice do budoucna.

Někdy se oplatí zariskovat, i když to na první pohled nedává smysl. Vždy je z toho nějaké poznání a ponaučení. Existují firmy a lidi, kteří dokáží provozovat stejný projekt úspěšně ve 3-4 lidech na pár serverech a jsou firmy, kde musí svůj stejný projekt při životě držet oddělení 20 lidí na stovkách serverů a pořád jsou čímsi zaměstnaní a náklady jsou extrémní. Když se dělají dobrá rozhodnutí, kvalitní research, hlídá se míra overengineeringu a definují ty správné a nepřestřelené funkčnosti, leccos se dá stejně kvalitně vyvinout a provozovat za o řád nižší náklady, než je něčí zkušenost či odhad. Učíme se a hledáme cesty celý život... ;-)

Pak prichazeji na radu mzdove naklady, mira prescasu, rychlost reseni v dobe nizkeho stavu zamestnancu v navaznosti na SLA atd...

Ten pravidelny research něco stojí, případně řešení provoznich problémů do toho. A IaaC to nezachrání.

At kalkuluji jak kalkuluji ja to při platu kvalitního člověka/specialisty v ČR nejsem schopen dát.
Možná mi uchází nějaký detail jako menší firma kde šéf sedi vedle v kanclu a rozhoduje okamžitě. Prakticky real-time scheduler:-)
Leda že by lidé měli přímý podíl na zisku firmy, byli spoluvlastníky a odměňování by probíhalo ještě jinak.
To může dávat ekonomicky smysl a perspektivu.