Změna schéma WebMedea databáze

led 27 2019

WebMedea již eviduje přes miliardu odkazů mezi weby. Tato data v naší Cassandra databázi zabírají již přes 110 GB. Společně s rostoucím množstvím dat jsme narazili na neustále se zvyšující vytížení RAM, CPU a diskové IO našich serverů právě od Cassandry. Její požadavky se zdá, že nejde ukojit. To nás přivedlo k zamyšlení se nad naším současným datovým modelem. Zhodnotili jsme, že nám nezbývá nic jiného než upravit způsob, jakým WebMedea ukládá odkazy mezi weby.

Cassandra, stejně jako relační databáze, umožňuje ukládat jako primární klíč tabulky skupinu více sloupců. Takový primární klíč se u Cassandry nazývá kompozitní (Composite key) a rozlišuje se na dvě důležité části - oddílový (Partition key) a třídící klíč (Clustering key). Oddílový klíč říká Cassandře do jakých celků (oddílů) ukládat bloky dat - tyto oddíly jsou vytvářeny na základě hodnoty sloupců, které jsou součástí klíče a cílem je vyhnout se příliš malým (stovky záznamů) nebo naopak příliš velkým oddílům (stovky MB dat). Třídící klíč, jak můj pokus o překlad napovídá, pak slouží ke třídění dat v rámci jednoho oddílu.

Při ukládání odkazů ve WebMedea jsme preventivně rozdělili cílové domény odkazů na jednotlivé úrovně oddělené tečkou a v oddílovém klíči je vedeme jako samostatné sloupce. Ukazuje se nám ale, že to nestačí. Největší české weby jako Heuréka.cz a Nova.cz jsou schopny vytvářet v naší databázi oddíly do velikosti až několika GB. Jejich "mikrostránky" jako produktroku.cz pak nejsou daleko pozadu.

Abychom předešli tomuto problému upravujeme náš oddílový klíč aby obsahoval také údaje o datumu nalezení odkazu. Tato změna má navíc benefit v tom, že urychlí zobrazování nejnovějších odkazů na výstupu z WebMedea. Jak ale provést takový zásah do 110 GB dat, která jsou neustále upravována, rozšiřována a čtena našimi klienty?

Pro tento úkol jsme přidali do WebMedea servery artemis.webmedea.com a athena.webmedea.com, které sídlí v datacentru Wedos.cz. Tyto servery na svých instancích Cassandry replikují pouze nově vytvořené databázové schéma a s ním i novou strukturu uložení odkazů. Původní formát odkazů je postupně překládán na nový persistentní službou. Tím se zvedá zátěž na naše servery v ostrém provozu jen minimálně, protože nemusí zapisovat novou strukturu dat. Paralelně k tomu upravujeme naši těžbu odkazů tak, aby ukládala do obou formátů naráz. Posledním krokem pak bude přepnutí schématu v klientských aplikacích a změna replikačního faktoru nového schématu, aby se nový formát dat rozšířil do celé sítě WebMedea.

Nový core server ve WebMedea

čen 06 2018

Protože naše databáze se neustále rozšiřuje, a my k ní navíc přidáváme další funkce, museli jsme ve WebMedea Services rozšířit i náš hardware o další hlavní server - ares.webmedea.com. S naším bohem války se ale, na rozdíl od toho antického, nikde nepotkáte. Jeho úkolem je totiž válčit s naší databází. Ares se bude starat o výpočty důležitosti domén na internetu a o aktuálnost odkazů mezi těmito doménami.

Ochrana nebo buzerace? Vyhodnocování DNS sinkhole od CSIRT

led 04 2018

Do WebMedea nám už mnohokrát přišlo varování, že naše servery provádí něco podivného. V podobných případech se většinou ukáže, že si jen někdo špatně nastavil wildcard v robots.txt na doméně, a my pak vlezli někam, kde nás nechtěl. Jindy má oznamovatel příliš důvěřivě nastavený mail server, když mu pak přijde spam s falešnou doménou (naší) v odesílateli, jde nadávat nám místo spammerovi. Někdy zase uděláme chybu my a zkoušíme se na web podívat příliš rychle z více míst - to jsme pak obviněni z DDOS útoku.

20.12.2017 jsme ale ve WebMedea dostali varování od jednoho z našich poskytovatelů, že se nám ze serverů šíří malware. Zpráva byla navíc doplněna následující přílohou::

Vážení kolegové,

jménem Národního bezpečnostního týmu CSIRT.CZ Vám, v rámci projektu PRedikce a Ochrana před Kybernetickými Incidenty (PROKI, ID: VI20152020026) realizovaném v rámci Programu bezpečnostního výzkumu ČR na léta 2015 – 2020, zasíláme souhrnný report o IP adresách z Vaší sítě, které byly vyhodnoceny jako potenciálně škodlivé.

V příloze naleznete seznam aktivit z Vašich IP rozsahů, které byly za uplynulých 7 dní zaznamenány z různých bezpečnostních informačních zdrojů - https://csirt.cz/page/3587/zdroje-dat/ ve formátu: time_detected, ip, class, type, time_delivered, country_code, asn, description, malware, feed_name, feed_url, raw

Chtěli bychom Vás tímto požádat o prošetření nálezů a vykonání případné nápravy u provozovatelů daných strojů. Doplňující informace o projektu PROKI naleznete na adrese: https://csirt.cz/page/3586/proki/ - https://csirt.cz/page/3586/proki/ .


Dear colleagues,

On behalf of the CSIRT.CZ National Security Team, we are sending you a comprehensive report on the IP addresses from your network, as part of the Preparedness and Protection against Cyber Incidents (PROKI, ID: VI20152020026) implemented within the Security Research Program of the Czech Republic for the years 2015-2020. evaluated as potentially harmful.

In the appendix you will find a list of activities from your IP ranges that have been recorded over the last 7 days from various security information sources - https://csirt.cz/page/3587/zdroje-dat/ in the format: time_detected, ip, class, type, time_delivered, country_code, asn, description, malware, feed_name, feed_url, raw

We would like to ask you to investigate the findings and make any corrections to the operators of the machines. Additional information on the PROKI project can be found at: https://csirt.cz/page/3586/proki/ - https://csirt.cz/page/3586/proki/.

To se nám ještě nestalo. Šlo o mnohem závažnější nařčení než obvykle, a proto jsme inkriminované servery rovnou odstavili. Díky uvedenému času a popisu údajného útoku jsme se měli čeho chytit. Mohli jsme tak určit, k čemu vůbec došlo.

A co se vlastně stalo?

WebMedea procházela české diskuzní servery a narazila na vlákna, kde si lidé stěžují na své počítače zaheslované pomocí ransomware. Odkazy na domény s popisem, jak odevzdat výkupné, se tak automaticky uložily do našeho systému. WebMedea se následně pokusila prozkoumat, co je na doménách za weby. Mezi publikací diskuze a příchodem WebMedea ale uplynula dlouhá doba, a tak již byly domény odhaleny a zabaveny evropskými úřady. Protože tyto domény byly používány i k distribuci přikazů pro botnety, byla na ně nasazena DNS sinkhole. Jakákoliv návštěva na jednu z těchto domén je tak automaticky odchycena a informace o návštěvníkovi jsou uloženy na seznam IP adres, které by stále ještě mohly být pod kontrolou některého z odhalených botnetů nebo šiřitelů malware.

Kde tedy vznikl problém

Databázi těchto potenciálně škodlivých adres spravuje německý tým CERT Bund. Právě tuto databázi poměrně svérázně uchopil český CSIRT, který ji jednoduše začal těžit a podle IP adres rozesílat oznámení na jednotlivé poskytovatele připojení. ISP samozřejmě obsah takových oznámení vůbec nezkoumají a rovnou konají - buď předáním varování nebo omezením služeb. Postihlo nás oboje.

Nešťastnost přístupu CSIRT

Dostat se na seznam potenciálních škůdců je úplně jednoduché - stačí když se váš počítač pokusí kontaktovat kompromitující doménu. Toho jde docílit mnoha jednoduchými způsoby:

  • Kliknete na přímý odkaz
  • Otevřete web, který vás na doménu přesměruje
  • Na internetovém fóru si někdo si vloží odkaz na neexistující obrázek na této doméně do podpisu nebo avatara
  • Otevřete email bez zapnutého blokování externích obrázků a obrázek z domény je tam schován ...

... a tak podobně. Sinkhole navíc evidentně neukládá (nebo neposkytuje) celé packety k další analýze, prostě vás přidají na seznam a je hotovo. Z toho pohledu mi příde nešťastné strašit lidi rovnou na základě jediné události, o které CSIRT navíc prakticky nic neví, protože se nedostane k obsahu packetů. Je naprosto jasné, že ISP se v tom vrtat nebudou a výhrůžky jen přesměrují na zákazníka tak, jak se mi potvrdilo ve dvou případech.

Postih pro WebMedea a řešení

V případě poskytovatele našich serverů vše naštěstí skočilo varováním a naší reakcí. V případě mého domácího připojení to ale bylo mnohem nepříjemnější. Poskytovatel mi rychlost připojení automaticky snížil na 10%, a to po celé svátky až do současnosti, kdy mi to konečně oznámil přes email.

Protože stále existuje risk, že narazíme na další kompromitované domény, přidáváme do WebMedea blacklist - seznam zakázaných domén, který budeme automatizovaně plnit. Do podobné patálie jako my se ale může dostat provozovatel libovolné webové služby, stačí když se dotazuje na jiné internetové domény na základě vstupu od uživatele. Máte své služby proti podobnému problému zabezpečeny?

Emaily na vlastní doméně - díl 2: naše řešení

lis 21 2017

Po zjištění z minulého dílu jsme se v Triton IT rozhodli nasadit vlastní mail server. Z běžně používaných řešení je ale pouze Microsoft Exchange Server dostupný jako kompetní balík všeho, co je potřeba. MS Exchange Server samozřejmě představuje nemalou investici a funguje jen na zařízeních s operačním systémem Windows Server. Vzhledem k našim požadavkům na nízkou cenu nezbývá, než ho přeskočit a podívat se na celé téma podrobněji.

Pro úspěšný běh vlastního mail serveru na internetu je potřeba jen následující tři kusy software:

  • MTA: Mail Transfer Agent vyměňuje emaily po internetu. Funguje jako server i klient nad protokolem SMTP. Příkladem MTA jsou programy sendmail, postfix a exim4. V podstatě má jen dva úkoly:
    • jako klient se připojí k jinému MTA a doručí mu email.
    • jako server čeká, až mu někdo (např. jiný MTA) doručí email. Pak se rozhodne, jestli ho někam uloží, nebo ho jde poslat dál.
  • MDA: Mail Delivery Agent umožňuje uživatelům stahovat emaily ze serveru. Konkrétně povoluje klientským programům (MUA) se připojit prostřednictvím protokolů IMAP nebo POP3 ke schránkám uživatelů. Teoreticky také může schránky a uživatele spravovat, to je něco, co ale umí i někteří MTA a obecně není jasně dáno, kdo to má mít starost.
  • MUA: Mail User Agent je program, s kterým pracuje uživatel. MUA má zpravidla hezké grafické rozhraní s přehledem emailů ve schránce, ukládá si kontakty, umožňuje snadno přikládat přílohy, atd. Mezi MUA patří MS Outlook, Thunderbird, ale i GMail.com a Seznam.cz.

Když si oddělíme databázi našich uživatelů a samotné úložiště schránek, jde to celé nakreslit asi takto:

Náčrt propojení programů a služeb v mail serveru

Při návrhu se největším úskalím ukázalo být vyzvedávání emailů pomocí MUA z MDA. Přestože komunikace přes protokoly POP3 a IMAP je naprosto přímočará a jasně definovaná, některé MUA se rozhodly zavést si vlastní dodatečná pravidla k formátu uživatelských jmen a šifrování. Konkrétně:

  • MS Outlook nefunguje, dokuď nemá uživatelská jména pro komunikaci s MDA jen v alfanumerickém tvaru, tj. bez symbolu @ (nelze použít email jako přihlašovací jméno).
  • GMail protestuje, pokud TLS komunikace není realizována pomocí certifikátu od některé z mezinárodních certifikačních autorit. Certifikát od Let's encrypt v době našeho testování (2016) bohužel nebyl podporován.

Finální řešení

Po dlouhém výzkumu metodou pokus-omyl jsme došli k následujícímu rozvržení:

  • MTA = postfix
  • MDA = dovecot
  • MUA = co má kdo rád, za mě jednoznačně GMail
  • Schránka = složka na serveru, kompletně v režii postfix a dovecot
  • Databáze emailových účtů = MySQL databáze

Tím jsme dosáhli následujících nákladů:

  • 110 Kč / měsíc ... Virtuální server, na kterém už stejně provozujeme weby
  • 259 Kč / rok ... Certum Commercial SSL certifikát
  • 130 Kč / rok / doména ... Náklady na CZ doménu placené registrátorovi

Jakých výhod jsme tímto řešením dosáhli?

  • Libovolný počet domén, schránek, aliasů bez poplatků navíc.
  • Možnost napojit oblíbenou schránku na webu nebo program úplně podle vlastní preference zaměstnance.
  • Při používání GMailu dále:
    • Snadné spojení více firemních i soukromých schránek do jediného účtu
    • Automatické ukládání kontaktů a jejich sdílení do Android zařízení
  • Téměř bezúdržbový běh
  • Při použítí POP3 k vyzvedávání schránky - téměř nulové nároky místo při zálohování, zodpovědnost za uložené emaily lze přesunout na jinou (i placenou) službu.

V příštím díle se podíváme na běžné problémy, se kterými se setkáte po nasazení vlastního mail serveru. A že jich není málo.

Cassandra repair implicitně nespouští compact

zář 25 2017

Naše cesta k nasazení Cassandry byla poměrně rychlá: šli jsme rovnou do produkce a problémy se učili řešit až za běhu. Za rok, co ji provozujeme, jsme potkali už téměř všechny běžné scénáře:

  • přeplnění tombstone
  • oživení tombstone kvuli nespuštění repair do konce gc_grace_period
  • nekontrolovatelné spínání stop-the-world garbage collection
  • neopravitelné rozpojení tabulky mezi datacentry
  • smazání části databáze špatně napsanou čistící funkcí a následná obnova ze snapshotu ...

Poslední dobou jsem ale zaznamenal plynulý nárůst zátěže na serverech s Cassandrou. Nárůst, který jsem si nedovedl vysvětlit.

Nejdříve jsem jej chtěl přisuzovat zvyšujícímu se objemu přenosu. Přece jen každý měsíc přidáváme nové stroje na těžbu a zpracování dat, logicky by se měla zvednout i zátěž na databázi. Svědomitě jsem proto pravidelně pouštěl repair, hlídal četnost GC a dodržoval postupy, které jsme našli v literatuře. A právě tady byl problém.

Bohužel jsme šáhli po stejných zdrojích jako Maki Watanabe. Důvod nárustu se ukázal být úplně prostý - nodetool repair implicitně nespouští tzv. major compaction. Právě nodetool compact jsem přestal manuálně spouštět ve chvíli, kdy jsem se naučil používat nodetool repair.

Repair není tak efektivní v odstraňování tombstone a my často zapisujeme, mažeme a provádíme změny struktury naší databáze. To také vedlo k vyšší zátěži.

Zátěž na apollo.webmedea.com před kompakcí.

Vývoj zátěže CPU na apollo.webmedea.com od nasazení serveru.

Zátěž na apollo.webmedea.com po vynucené kompakci.

Zátěž CPU po vynucené kompakci.

Všechno špatné je ale k něčemu dobré, máme poučení, že nemáme číst zastaralou literaturu. Známe teď také další problémový scénář :)