Bludit je super CMS systém pro blog, zápisník nebo i velmi jednoduché webové stránky. Nepotřebuje žádný databázový systém, vše ukládá do struktury textových souborů. Oslovil mě natolik, že jsem se stal sponzorem a vydávám pro něj sám grafickou šablonu, kterou jsem během pár posledních večerů opět aktualizoval. Ke stažení (a zkritizování) je dostupná (zatím ještě) na GitHub.
Teď jen najít chvíli a aktualizovat ji tady u sebe na blogu :)
Protože jsem chtěl poznat vinárnu Wine Bar i z druhé strany, a porozumět tak více vínům, rozhodl jsem se navštívit degustaci vín, která se ve vinárně pravidelně koná. Degustace se tentokrát zaměřovala na vína oceněná českou soutěží Prague Wine Trophy, kde nabídka Wine Baru získala hned několik medailí a dokonce i titul šampióna ve dvou kategoriích. Degustace byla super akce - přestože jsem naprostý laik, necítil jsem se méněcenně. Sommeliér Petr Mikeska vysvětloval i pojmy, které jsou pro zkušené samozřejmostí. Ochutnávka každého vína byla doplněna názornou prezentací fotografií, mapou lokality, odkud pochází hrozny, i zajímavostmi ze zákulisí vinařství.
Spodní patro vinárny Wine Bar
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. Server se bude starat o výpočty důležitosti domén na internetu a o aktuálnost odkazů mezi těmito doménami.
The name of this post is inspired by the latest official post on the GitHub blog.
So Microsoft is acquiring GitHub. While certain people like GitHub CEO defunkt are beaming with enthusiasm reserved only for those, who secured themselves a hefty sum and a nice position on the lap of their new overlord, I can't help myself but feel skeptical. Don't get me wrong, I wish for nothing else but the bright future that has been promised - but is that future really possible with the track record Microsoft has had up until now?
While Microsoft and GitHub are both busy reassuring us how this partnership was struck in heaven itself, I look back at how Microsoft acquisitions have impacted me in the past. Let's just say: most times they weren't pleasant experiences...
Nokia
When Nokia annouced that they were teaming up with Intel to bring us a new mobile OS with native applications and Qt 4 as the default graphical library, I was overhelmed with joy. After my initial reservations, when I witnessed the weird squabble and sudden shift from Maemo to MeeGo, I finally gave in and bought the new flagship phone Nokia N9. The operating system and all the apps were astonishingly fast compared both to my previous semi-smart phone and to any Android device I've touched ever since. However within two weeks from my purchase it was annouced that Stephen Elop would be the new CEO of Nokia. I knew right away that the glorious era of MeeGo and native phone applications would never come. Within the next half of a year my shiny new phone became an obsolete brick with zero official support or updates and with no functional app store.
Skype
How hard can it be to screw up something that is working perfectly fine and generates a steady stream of revenue? It appears that in the hands of Microsoft nothing is impossible. A fast peer-to-peer encrypted chat and voice call application was transformed into incomprehensible mess that sports two variants which can't even properly interact together. I'm talking, of course, about the split to Skype and Skype for Business. From the rising new platform to an obsolete piece of software that works only randomly (the only version that seems to semi-successfully work is the installation on my android tablet).
While both of these events arguably occured before Satya Nadella became the new CEO of Microsoft, the direction in which Skype is evolving simply hasn't changed. Furthermore the introduction of projects such as Ubuntu on Windows and announcing SQL Server for Linux inspire only more skepticism on my side - for let's never forget the fabled triple E strategy (Embrace, Extend, Extinguish) Microsoft has used so many times in the past. To add one final drop to my bowl of mistrust, let's look at OneDrive.
OneDrive
When OneDrive was launched, it was clearly designed to pick a fight with Google Drive over their customers. In the free plan it offered thrice the size and that was quite enticing for me. Of course, when I was busy moving my files to the new cloud drive, it suddenly got shrinked back to the 5 GB limit.
What's next for GitHub
Just like with Nokia and OneDrive I've moved to GitHub shortly before the major change was announced. This time, however, I'm not waiting around to see what the damage will be. I sincerely hope this platform will stay the same unadultered cloud storage it has been so far, but I wouldn't bet on it. For all I know we can expect announcement of GitHub for Business, integration into Office 365 and login replacement with Microsoft account within few months.
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, rawChtě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, rawWe 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.
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.
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.
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:
... 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.
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?
Poslední dobou mě začal vadit CMS Nibbleblog běžící na mém blogu. Za asi největší nedostatek považuji neschopnost odebrat existující tagy. Jakmile tag jednou vytvoříte, už se ho nezbavíte a na blogu zůstane vidět, i když k němu nejsou přiřazeny žádné příspěvky. Protože jsem toho zatím až tak moc nenapsal, začal jsem hledat, jak by se dal Nibbleblog vylepšit nebo úplně nahradit. A právě při tom hledání jsem zjistil, že Nibbleblog už nikdo aktivně nevyvíjí. Jeho autor Diego Najar ho asi před rokem opustil a vydává maximálně občasné aktualizace bezpečnosti. To je informace, která by podle mě měla být jak na domovské stránce www.nibbleblog.com tak na jeho GitHubu. Kdybych to věděl, vůbec bych Nibbleblog neinstaloval!
Při hledání nového CMS jsem ale narazil. Buď musíte nasadit obří řešení jako Wordpress a Joomla, které vyžaduje vlastní SQL databázi, a nebo jsou k dispozici samé ultra jednoduché systémy generující články přímo z terminálu - hezké, ale ne vždy praktické. Nejpodobnější Nibbleblogu byl nakonec Diegův nový počin Bludit. Stejně jako Nibbleblog i Bludit běží z jediné složky a nepotřebuje žádnou databázi nebo složité nastavování - jen rozbalíte, nastavíte přihlašování a už šlape. Výhodou je také, že veškerou konfiguraci ukládá přehledně do JSON souborů.
V Bluditu chyběla čeština, tak jsem ji Diegovi hned dodal. V master větvi na GitHubu ji tak už najdete, jinak bude pravděpodobně dostupná až v následující verzi.
Z administrace Bluditu jsem nadšený, podle mě je mnohem přehlednější než byla v Nibbleblogu. Výchozí editor podporuje společně HTML i markdown syntaxi. Pluginů je dostupných více a je i větší pravděpodobnost, že nějaké přibudou. Grafické šablony jsou pro mne ale zklamání. Téměř všechny mi přijdou neuvěřitelně ošklivé a žádná úplně nesedí na původní styl blogu. Naštestí je vytvoření nové šablony velmi jednoduché, vzhled celého webu jde klidně nacpat do jediného PHP souboru. Rozhodl jsem se proto, že postupně zkonvertuji původní šablonu Echo pro Nibbleblog do Bluditu. Pracovní verze šablony je veřejně dostupná na GitHubu.
Přetrvávajícím neduhem z Nibbleblogu je timeout přihlášení během psaní článku. Uložení stránky po příliš dlouhé době tak snadno vymázne všechno, co jste zatím napsali. Asi se na to při úpravách šablony také podívám.
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:
Když si oddělíme databázi našich uživatelů a samotné úložiště schránek, jde to celé nakreslit asi takto:
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ě:
Po dlouhém výzkumu metodou pokus-omyl jsme došli k následujícímu rozvržení:
Tím jsme dosáhli následujících nákladů:
Jakých výhod jsme tímto řešením dosáhli?
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.
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:
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.
Vývoj zátěže CPU na apollo.webmedea.com od nasazení serveru.
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ář :)