Minulý týden, v pátek odpoledne jsme se potýkali s problémy s konektivitou u VPS. Od počátku naší činnosti si zakládáme na otevřenosti a tak dovolte, abychom udělali nějaký soupis událostí a vysvětlili co se vlastně stalo.
Co se přihodilo
V pátek dne 12. 8. 2016 v době od 13:39 do 16:20 jsme měli zhoršenou dostupnost našich VPS. V průběhu této doby měly virtuální servery ztrátovost paketů cca 50 %, někdy to bylo více, jindy méně, samotné servery fungovaly zcela bez problémů.
Příčinnou byl zcela nový typ útoku na naši infrastrukturu. Dále v následujících cca 72 hodinách jsme dělali několik úprav na síti a tak jsme museli neprodleně zasáhnout do nastavení a došlo k několika dalším drobným výpadkům, zejména u virtuálních serverů používajících IPv6.
Situace se okrajově dotkla našeho webu a dostupnosti podpory. Náš web byl někdy pomalejší a chvilkami neodpovídal. Zákaznická podpora byla přetížena a nestačila odpovídat na všechny požadavky klientů a chat (jako hlavní nástroj naší komunikace) občas vypadával, protože na něj směřoval také útok. Snažili jsme se tak stručně informovat o problémech na sociálních sítích.
Zcela bez výpadků byly webhostingy. Dedikovaných serverů se problém dotkl na cca minutu, než jsme je přesměrovali na jiný router.
Situace se dotkla cca 5.900 služeb. Bohužel se jednalo o virtuální servery, kde často mohou být náročné projekty. Ostaní služby – 80.000 webhostingů (celkově 130.000 webů), 11.000 WEDOS disků a 246.000 domén fungovalo bez problémů.
Úvodní omluva
Úvodem se omlouváme za komplikace, které našim zákazníkům nastaly. Popsaná situace nás velmi mrzí. Odnesli jsme si z toho však mnoho zkušeností. Určitě nás to posunulo vpřed a určitě díky tomu můžeme nabízet lepší služby do budoucna.
Proč tak dlouho trvá vysvětlení?
Důvodem je to, že jsme určitou dobu analyzovali celou situaci, abychom dali dohromady přesně co se stalo a zároveň jsme museli udělat několik protiopatření, aby se podobná situace už neopakovala. Nemohli jsme zveřejnit některé informace bez toho, abychom měli přesně ověřenou situaci a zmapovaný průběh. Zároveň jsme nemohli zveřejnit detaily bez toho, abychom nebyli na podobnou situaci připraveni do budoucna. Dali bychom jen návod na to, aby se podobná situace opakovala.
DDoS ochrana a její vývoj u WEDOS
Před cca 2 roky jsme se začali potýkat s větší vlnou DDoS útoků. Nejprve jsme situaci řešili ručně, následně jsme testovali několik různých řešení (včetně “krabiček” za desítky milionů). Nakonec jsme se rozhodli pro řešení, které je postavené převážně na opensource. Můžeme to ovládat, víme, co to dělá a můžeme to rozšiřovat. Bohužel některé hrozby jsou poprvé. Například jako ta v pátek a my nejprve musíme náš systém “naučit ochranu”, aby příště už vše řešil sám a k tomu potřebujeme důkladně analyzovat situaci a udělat několik úprav a nastavení.
Po několika měsících vývoje a testů jsme na podzim 2014 nasadili řešení, které neustále zdokonalujeme a rozšiřujeme. V podstatě se jedná o 11 velmi silných serverů, které vyhodnocují všechny toky v síti a na základě toho aplikují různá pravidla pro filtraci nebo změny v síti.
Za 21 měsíců jsme odhalili a odfiltrovali neuvěřitelných 257.000 útoků na nás nebo naše zákazníky. Nejčastějším cílem útoků je náš web a naše routery. Některé útoky byly silné v desítkách Gbps a byly to miliony paketů za sekundu. Systém fungoval a funguje skvěle. Shodou okolností jsme před časem slavili rok bez (neplánovaných) výpadků.
V návrhu ochrany jsme vycházeli ze situací, které jsme už řešili a zároveň s formou a způsoby útoků, které jsme měli takřka na denním pořádku.
Doposud jsme 97% všech útoků řešili na IPv4, přičemž již cca 13% datového toku máme na IPv6. Jen poměrně malá část útoků byla na IPv6. Systém vždy vše zachytil, vyřešil a my jsme si v klidu mohli pracovat a nemuseli jsme nic řešit.
Do DDoS ochrany jsme investovali několik milionů, tisíce hodin práce a neustále ochranu posouváme dál a dál. V naší síti provozujeme nejvíce webhostigů a virtuálních serverů v ČR.
Útočníci neustále přicházejí s novými hrozbami a mají nové metody útoků. Dříve to bylo používání “hrubé síly”, kdy cílem bylo “ucpat” a přetížit naší infrastrukturu. Postupně jsme navyšovali kapacity linek do internetu (až na současných 70 Gbps). Naučili jsme se to všechno ještě filtrovat a tak “hrubá síla” není natolik účinná. Proto útočníci přicházejí s jinými metodami. Používají vyspělé metody útoků, kdy nejde o “hrubou sílu”, ale o inteligentní útoky. Různé pakety, které dělají problémy v síti nebo na koncových strojích. Tyto nové druhy útoků jsou hůře zachytitelné a hůře se před nimi brání. Pokud přijdou útočníci s něčím novým, tak my musíme celou situaci analyzovat a následně musíme systém připravit tak, aby se nové hrozbě dokázal bránit do budoucna. Přesně to se stalo v pátek – nová hrozba, analýza a nyní implementujeme již několik dní různá protiopatření.
Nespíme a proto IDS/IPS
Cca před rokem jsme začali chystat IDS/IPS ochranu pro naše zákazníky. Jedná se o inteligentní formu ochrany proti útokům na aplikace zákazníků. Umí například blokovat útočníky, kteří jen přetěžují weby a vyčerpávají volné procesy, snaží se prolomit zákaznická hesla nebo zneužívají různé bezpečnostní chyby v redakčních systémech. Dokážeme tak ochránit zákaznické weby před napadením, protože se používají pravidla pro filtraci pro desítky tisíc nejčastějších bezpečnostních hrozeb. Vše je online a v reálném čase. Pokud tedy například útočník chce na váš web přistupovat na stránku, která může být napadnutelná a potencionální útočník pošle požadavek, který může znamenat napadení, tak je tento požadavek blokován dříve než dojde na server.
Tento další způsob ochrany je velmi náročný technicky a je velmi složitý na přípravu, spuštění, nastavení a následný provoz. Zkoušeli jsme i hotová (placená) řešení (včetně hardwarových), ale po všech testech jsme se opět rozhodli pro použití opensource řešení s tím, že si některé části zaplatíme. V průběhu letošního jara jsme řešili velké množství úprav na naší síti a to za účelem, abychom mohli tuto ochranu nabídnout (v první fázi) pro webhostingy. Nevěřili byste kolik je to práce, ale jak je to zároveň účinné. Jen po cca týdnu po nasazení jsme snížili průměrný datový tok do naší sítě o cca 200.000 paketů za sekundu. Byl to jen zbytečný provoz, který u nás přistupoval na servery a generoval zátěž nebo byl bezpečnostním rizikem. Systém tohle vše automaticky blokoval.
Proč to zmiňujeme? Důvod je ten, že jsme měli trochu obavu zda tato ochrana (a všechny změny s tím spojené) neměla vliv na páteční situaci. Trochu jsme znejistili a bylo to první, co jsme vypnuli. Postupně systém vracíme u webhostingů do provozu.
IDS/IPS je další obrovský krok dopředu. U webhostingu jsou výsledky velmi pozitivní. Jsou to další miliony investované do ochrany našich klientů a další obrovské úsilí. Problematice se věnujeme cca rok velmi intenzivně.
Příznaky situace z minulého týdne
Jednalo se o zcela novou formu útoku. Mimořádně rafinovanou, zřejmě dlouhodobě plánovanou a profesionálně připravenou. Nešlo o nějakou náhodu nebo nějaký pokus za pár dolarů, ale o to, že útočníci měli i část výpočetního výkonu použitého pro útoky připravenou u nás (normálně na placených službách).
Útok nebyl nebezpečný silou, protože ve špičce jsme měli cca 1,5 milionu problematických paketů za sekundu přicházejících zvenku. Nebyl nebezpečný ani datovým tokem, protože naprostá většina dat byla záměrně jen ve formě tzv. TCP+SYN požadavků. To jsou malé pakety, malý objem dat, který má za cíl přetížit (vyčerpat všechny volné sloty, aby server nemohl přijímat další spojení). Ochrana proti TCP+SYN útokům není zcela jednoduchá, ale my ji máme funkční a dlouhodobě otestovanou a za normálních okolností by nikdo žádný útok nepoznal. Vygenerovat poměrně silný TCP+SYN útok lze mnoha nástroji. Snadno, levně, účinně a nepotřebujete k tomu skoro nic.
Silné útoky byly vedeny z naší sítě u virtuálních serverů a to na náš web, naše routery a na další VPS v naší síti.
Přes palubu vás mohou hodit jen ti, kteří jsou s vámi na jedné lodi
Ano, je tomu tak. Největším problémem minulý týden bylo to, že na nás útočili naši vlastní zákazníci. Cože? Ano, naši zákazníci, respektive několik zákaznických VPS útočilo na nás, na náš web a naše routery zevnitř.
Bohužel jsme v návrhu ochrany nepočítali přímo s podobnou situací. Stav byl takový, že jsme na filtraci útoků z vlastní sítě navzájem mezi sebou neměli implementovanou ochranu a zatím jsme ji jen promýšleli a připravovali její nasazení.
Útočníci byli rychlejší a objednali si u nás různá VPS, zaplatili a zaútočili na nás zevnitř. Útočili na nás (náš web a routery) a na další (ostatní zákaznická) VPS u nás. Útoky byly dosti silné (mnohonásobně silnější, než zvenku). Ve špičce to bylo cca 6 milionů problematických paketů za sekundu, které se navíc různě “množily” tím, že v síti kolovaly odpovědi od VPS a routerů na něž se útočilo.
Nevíme, zda útočili jen útočníci, kteří si koupili placené služby nebo byly zneužité i VPS běžných zákazníků (pomocí nějakých bezpečnostních chyb), ale ani to nelze vyloučit.
Co se vlastně stalo?
Proběhl plošný útok na několik stovek VPS pomocí IPv4, což byl zřejmě zastírací manévr pro silný útok na IPv6. IPv6 provoz byl mnohem silnější a agresivnější. Útoky směřovaly na stovky tisíc IP IPv6, které jsou u nás použité (respektive přidělené) na virtuálních serverech. Nejednalo se o IP adresy používané reálně jednotlivými službami, ale strojově generované IPv6.
Na náš web šlo zvenku několik desítek tisíc požadavků za sekundu. Z vnitřní sítě a ze strany našich virtuálních serverů to bylo mnohem mnohem více.
Problém spočíval v tom, že virtuální servery útočily na náš web a naše routery. Náš web dostával požadavky na spojení v řádu několika stovek tisíc za sekundu.
Routery řešily požadavky ve formě odpovědí s tím, že taková IP adresa u nás nehostuje. Vzhledem k tomu, že k nám přicházelo cca 1,5 milionu požadavků za sekundu na neexistující IP adresy (respektive existující, ale reálně nepoužívané), tak routery odpovídaly zpět a tím se datový tok zdvojnásobil. To by pořád nebylo nic zásadního.
V naší síti (u VPS) se potom odehrávaly další části útoků a to ve formě hromadného generování útoků na IPv6 z rozsahů, které byly přiděleny jednotlivým VPS. Zároveň jsme zaznamenali i útoky z IPv6, které nespadají vůbec do našeho rozsahu a provoz byl generován z námi hostovaných VPS.
Na naše hraniční routery přicházela zvenku poměrně velká část provozu, která byla z podvržených IPv6 adres, což jsme úspěšně blokovali.
Problém nastal v tom okamžiku, kdy routery a jednotlivé články DDoS ochrany, začaly aplikovat různá bezpečnostní nastavení a začaly počítat různé kontrolní součty pro IPv6 a chtěly chránit jednotlivé IP adresy na něž byl směřován útok. V tomto okamžiku se snažily spočítat obrovské množství útočících IP adres (tam se to dělá podle prefixů) a hlavně chránit námi provozované IPv6 na něž útok směřoval. Těch, na které byl aktivní útok, bylo několik stovek tisíc a celkově se systém snažil chránit prakticky celý náš rozsah… V tomto okamžiku došlo k technickým problémům. Routery a ochrana byly natolik přetížené, že přestaly reagovat odpovídajícím způsobem. Strojům v síti došla paměť a tím začaly problémy.
Výsledkem bylo to, že nakonec došlo k odpojení fyzického rozhraní a v tom okamžiku nebyla jednotlivá zařízení dosažitelná v rámci naší páteřní sítě. A tím se začaly aplikovat výchozí routovací pravidla. Tam potom pakety putovaly v naší síti sem a tam, dokud jim nevypršel TTL. Tohle cyklení se dělo v rámci páteřní sítě a byl to následek a nemělo to vliv na funkčnost a nebyla to příčina.
Jak jsme to řešili?
Nejprve jsme museli zjistit co a jak se děje. Vzhledem k problémům (přetížení) některých částí DDoS ochrany (zejména online senzorů) jsme byli trochu paralyzováni a hledali jsme příčiny, kde se dalo. Namísto toho, aby jsme měli informace online ze senzorů, tak jsme byli bez informací nebo jsme je měli s velkým zpožděním. To velmi komplikovalo situaci a velmi složitě se nám hledala příčina celé situace.
Následně jsme oddělili provoz IPv4 od IPv6 na jiný router, přesměrovali provoz dalších služeb na jiný router a tím jsme situaci stabilizovali a měli jsme čas řešit provoz na IPv6.
Na jedné straně jsme nastavili různá omezení a různé filtry. Na druhé straně jsme se snažili zjistit kdo útočí. Několik útočících VPS jsme vypnuli a další problémové jsme omezili. Krok za krokem jsme situaci stabilizovali. Mezitím jsme se snažili řešit problém s DDoS ochranou, která měla problém s nedostatkem RAM a výkonu pro tak silný plošný útok, kdy ochrana musela počítat ochranu pro stovky tisíc nebo miliony nebo miliardy IP adres na které se útočilo a na druhé straně, které utočily…
Kde byl problém u nás?
Dobrota
Od počátku přidělujeme pro VPS IPv6 prefix /112, což je 65.536 IPv6 adres pro každé VPS. Je to obrovské množství. Aktuálně tak máme přiděleno (jen pro VPS) 393,216.000 IPv6 adres. Ano, celých 393 milionů. Jen pro představu – všech IPv4 na celém světě je maximálně 4 miliardy. Takže, když to přirovnáme, tak na našich VPS je přiděleno 10% z celkového počtu všech IPv4 adres, které jsou používány ve světě (z pohledu IPv4) To je obrovské číslo. Možná jsme měli být opatrnější, ale je to takový standard ve světě plus navíc některé blacklisty často používají blokace právě na sítě /112 apod. Takže menší rozsahy by byly zase komplikovanější pro ostatní klienty.
Root VPS
Klientům jsme neomezovali co mohou. Na našich root VPS byla svoboda, kdy si klienti mohli nainstalovat co chtěli a mohli si nastavit na síťové rozhraní rozsahy, které chtěli používat a mohli si tak dělat různé vlany sítě mezi VPS. Vzhledem k tomu bylo možné na jednom VPS mít reálně použitých několik desítek tisíc různých IPv6, což je problém v situaci, když to udělá více klientů a ty potom chcete (nebo musíte) chránit.
Masivnost a zejména plošnost útoku
Nepočítali jsme s tím, že budou útoky na stovky tisíc IP adres současně. Prvky verze ochrany na to nebyly připravené a doposud jsme se s tak plošným útokem ani nesetkali. Už jsme však udělali potřebné úpravy, aby podobnou situaci nebylo možné zopakovat.
Boj proti útokům zevnitř
Jak již bylo zmíněno, tak tohle jsme promýšleli, ale ještě nepřipravili. Nyní jsme přidali do vnitřní sítě detailní monitoring provozu. Doposud jsme měli monitoring na vstupu do naší sítě, před DDoS ochranou a za DDoS ochranou. Uvnitř sítě jsme měli k dispozici netflow, které je zpožděné a není vhodné pro řešení DDoS útoků. Nyní již máme online detailní přehled a jsme tak schopni situaci lépe vyhodnotit a řešit (i zcela automaticky).
O co šlo? Trochu teorie
Pokud použijeme informaci o IPv6 z Wikipedie: “Běžně jsou uváděny příklady ukazující, jak absurdně velký je adresní prostor IPv6. Obsahuje celkem 2128 (zhruba 3,4×1038) adres, což odpovídá počtu 5×1028 adres pro každého ze 7 miliard dnes žijících lidí. Nebo také 252 adres pro každou hvězdu ve známém vesmíru (milionkrát více adres pro každou hvězdu, než umožňoval protokol IPv4 pro naši planetu). Případně srovnání s počtem atomů ve známém vesmíru (1078 až 10100).“, tak zjistíme jak obrovský počet IPv6 je připraven pro použití. Ve srovnání s cca 4 miliardami IPv4 je to naprosto diametrální rozdíl.
U WEDOS máme přidělený rozsah sítě pro IPv6 /32, což je neuvěřitelných 4 294 967 296 podsítí /64, příčemž každá z podsítí /64 má 18 446 744 073 709 551 616 IPv6. Výsledkem je tedy to, že WEDOS má přiděleno 7,922816251×10²⁸ IPv6 adres a všechny k WEDOS směřovaly a teoreticky na jakoukoliv z nich mohl vést útok. Pro takový počet IP adres není v silách žádné technologie počítat pakety proti těmto IP adresám a chránit je před DDoS útoky.
Srovnejme to s IPv4, kde máme k dispozici 10 240 IPv4 adres.
Jistě chápete, že je rozdíl na jedné straně chránit 7,922816251×10²⁸ nebo 10 240 IP adres a zároveň to chráníte proti jinému počtu útočníků, U IPv6 máte 3,4×1038 potencionálních útočníků a u IPv4 jich máte pouhé cca 4 miliardy (232 adres (cca 4×109 = 4 miliardy adres)). To jsou rozdíly. Velké rozdíly.
Když řešíte DDoS ochranu, tak musíte pro každou IP adresu nebo rozsah, který chráníte počítat počty paketů a sledovat (a počítat) o jaké pakety jde a jak jsou škodlivé. U IPv4 to snadno spočítáte (vzhledem k výše uvedeným počtům), ale u IPv6… Můžete to vždy nějak seskupovat, ale u IPv6 narážíte na obrovská čísla a když to seskupíte hodně, tak je ochrana neúčinná.
Když chcete ochranu řešit a nechcete použít jen obyčejný blackholing (zrušení IP adresy), ale chcete pakety filtrovat a doručit jen ty nezávadné, tak musíte počítat mnohem více a musíte počítat i další záležitosti. Neřešíte tedy jen cílové IP adresy, ale i zdrojové rozsahy, provoz na jednotlivých protokolech a další parametry (provoz na portech a velikosti paketů). A to jsme u jádra problému. Na počítání potřebujete výkon a paměť. Položme si otázku, zda v dnešní době existuje (ve světě) možnost jak to spočítat a docílit.
IPv6 zabíjí
Podobné situace budou asi následovat i u mnoha jiných poskytovatelů. IPv6 je moderní a my sami jsme velkým propagátorem, ale páteční situace je velkým vystřízlivěním. Velkým. Nejraději bychom IPv6 ukončili…
U IPv6 se potýkáme se situacemi, které u IPv4 nejsou a nikdy nebudou. Tohle je jen jedna z nich. Docela zásadní.
U IPv6 jsou problémy s ochranou, problémy s nastavením. Vše potřebuje mnohem větší systémové prostředky, než u IPv4.
Zavedená opatření
Síť
Upravili jsme nějaké věci v síti, rozdělili tok IPv4 přes jiné routery, než provoz IPv6. Z hlediska stability významný krok. Upravili jsme filtrovací pravidla pro IPv6. Mnohem dříve pošleme jednotlivé IPv6 na tzv. blackholing a jejich provoz bude do naší sítě zakázán a zmizí z celosvětových routovacích tabulek.
Bezpečnost
Upravili jsme jednotlivé části naší DDoS ochrany, přidali do senzorů 512 GB RAM, přidali další senzory do sítě. Nové senzory sledují provoz až za našimi routery, přímo mezi službami. Doposud jsme měli online senzory na páteřních routerech, za DDoS filtery, ale neměli jsme online sledování provozu v síti mezi jednotlivými servery u nás v síti. Netflow považujeme za pomalé a nedostatečné a proto jsme přidali další online senzory.
Zvažujeme zda nenasadíme IDS/IPS i u VPS. U webhostingů se to osvědčilo. Klesl datový tok, klesl počet incidentů v síti a klesl počet napadených webů.
Ochrana
U všech VPS bude nadále přidělován rozsah /112, což je 65.536 adres IPv6 pro každé VPS, ale reálně bude možné používat jen jednotlivé IP adresy, které bude nutné zaevidovat v zákaznické administraci a tím se tato IP adresa bude moci používat. Toto řešení máme připravené a budeme ho aktivovat v příštím týdnu. Nejprve pošleme zprávu všem klientům, kterých se to týká a následně začneme omezovat. Každý zákazník s VPS bude mít automaticky aktivní IPv6 s číslem jedna (ze svého rozsahu) a další bude muset nejprve zaevidovat v administraci. Již nyní můžete přednastavit povolené IPv6 v zákaznické administraci, ale zatím to nemá na funkčnost žádný vliv. Vše bude aktivní po víkendu.
Omezení root služeb
Již jsme udělali několik drobných opatření a tak na VPS už nejsou žádné možnosti zneužívání jiných IP adres apod., což nyní platí i pro IPv6. Již dříve nešlo některé věci dělat u IPv4. Nechceme omezovat podstatu root služeb, ale hledáme vhodné řešení, aby to nemělo negativní vliv na klienty.
Monitoring a status na sociálních sítích
Na sociální sítě budeme umět dát pravidlo o globálnějším problému. Ne jako doposud, kdy umíme exportovat jednotlivé problémy s jednotlivými servery.
Ještě jednou se omlouváme a určitě nehodláme nic zamlčet a žádné problémy netajíme. Věřte, že tohle není náš styl.
Omezení některých druhů paketů
U VPS jsme začali mírně limitovat některé druhy provozu a mimořádně nadlimitní hodnoty automaticky (v případě útoků) blokujeme. Jedná se například o ICMP pakety a tak v případě silných útoků nemusejí vždy odpovídat ICMP pakety (například pingy nemusejí vždy odpovídat). Některé protokoly mohou být omezené, ale bez vlivu na samotný virtuální server. Je to v zájmu kvality služeb, aby vždy fungoval provoz na jiných protokolech, které jsou důležité pro provoz VPS. Je pravda, že například toto omezení může způsobovat plané poplachy u různých monitoringů apod.. Za uvedené se omlouváme a věříme, že to bude jen dočasná situace.
Více detailů – omlouváme se, ale ne…
Nezlobte se, že nezveřejňujeme další detaily o celém útoku. Mohli bychom napsat pomocí jakých nástrojů byl útok proveden apod., ale nechceme dávat návod na to jak “škodit” a útočit na IPv6. To by nepomohlo nikomu. Ani nám, ani dalším poskytovatelům služeb. Děkujeme za pochopení.
Nezlobte se, že nezveřejňujeme další detaily o provedených opatřeních, ale důvody jsou podobné. Nechceme, abychom dávali informace o naší ochraně a tím mohli případným útočníkům napovědět jak škodit u nás. Děkujeme za pochopení.
Věříme, že oceníte naši otevřenost a že oceníte to, že jsme celou situaci vysvětlili a popsali velmi obsáhle a nespokojili jsme se s nějakou omlouvou nebo výmluvou. Popsali jsme co se stalo a zároveň i kde jsme měli chyby u nás a co jsme změnili nebo co musíme ještě změnit. Otevřenost a žádné tajnosti je náš styl. Celá situace nás posouvá dál a zase jsme naše služby mohli vylepšit.
IPv4 pro všechny
Vzhledem k tomu, co se stalo jsme se rozhodli, že dáme ke všem VPS IPv4 zdarma (respektive za korunu měsíčně) a to i za cenu, že je musíme draze kupovat. IPv4 nám došly. Skutečně jsme neměli žádnou volnou, a tak jsme je museli koupit a klientům zpoplatnit a nutili jsme klienty používat IPv6. Nyní se nám to vymstilo. Z tohoto pohledu dáme všem IPv4, protože tam nejsou takové nároky na filtraci a umíme to filtrovat mnohem lépe a spolehlivějším způsobem. Zároveň klientům oddělíme tok pro IPv4 a IPv6 a v případě podobných komplikací bude jedna z verzí vždy dostupná. Věříme, že podobnou situaci již řešit nebudeme.
Odpovědi na jednotlivé dotazy, které zazněly v minulých dnech
Otázka: Proč se mi tentokrát nějak nezdá výmysl s DDOS když se dívám na grafy přenosů ze včerejška. (Proč grafy neukazují DDoS)
Odpověď: Na veřejných grafech jsou vidět toky, které jsou za primární DDoS ochranou. To znamená, že tok přicházejí zvenku je většinou odfiltrován a není na grafech vidět. Problémem nebyl tolik tok zvenku jako zevnitř. Zároveň se nejednalo o velký datový tok, ale velký počet malých paketů, které spotřebovávaly volné sloty na jednotlivých VPS.
Otázka: Když jsem to testoval, tak se v určitých časech/intervalech pakety dostaly do smyčky mezi dvěma routery wedosu a pak byly zahozeny z důvodu TTL.
Odpověď: Ano, to se stalo v případě, že bylo nefunkční rozhraní na routeru a ten hledal jinou (náhradní cestu). Tam se potom aplikovaly výchozí routy a pakety mohly takhle být. Tohle se použilo v naší páteřní síti, kde to nedělalo problém. Problém jsme měli především za routerem pro VPS, který byl přetížen zevnitř.
Otázka: Proč se nedalo spojit se zákaznickou podporou?
Odpověď: Zákaznická podpora dělala v pátek odpoledne co mohla. Je čas dovolených a tak je na podpoře menší zátěž a tak tam nejsou desítky pracovníků, ale například 4 pracovníci plus technici. Bohužel, když máme pod útokem náš web nebo chat, tak je problematická dostupnost a někdy to nefunguje zcela ideálně. Telefony zvoní, ale nejde obsloužit všechny… Přicházejí desítky mailů s dotazy apod… V tom okamžiku nevíte co dříve. Z toho pohledu dáváme zprávy do administrace a na chat. Další krátké informace dáváme na sociální sítě. Veškeré úsilí věnujeme řešení problémům a řešení situace.
Otázka: Proč na některých speciálních účtech WEDOS Status na sociálních sítích nebylo ihned upozornění?
Odpověď: Automat na hromadnou situaci nebyl připraven. Po dřívějších zkušenostech jsme zavedli automaty na dílčí služby. Bereme to jako podnět na zlepšení a okamžite na tom zapracujeme.
Otázka (doplněna po zveřejnění): Jaké budou kompenzace?
Odpověď: Kompenzace řeší naše obchodní oddělení. Stačí napsat přes kontaktní formulář.
Otázka (doplněna po zveřejnění): Sloh…
Odpověď: Ano, máte pravdu. V textu jsou jak stylistické, tak gramatické chyby. Omlouváme se. Nám šlo o sdělení toho, co se stalo a vysvětlení celé situace. Mohli jsme napsat omluvu a dále to nevysvětlovat, ale to není náš styl. Mohli jsme to celé uzavřít jakýmkoliv vysvětlením, ale napsali jsme pravdu a věnovali jsme se i teoretickému vysvětlení problému, aby to pochopil každý. Za chyby v českém jazyce nebo slohové nedostatky se omlouváme. Pro nás jsou nyní aktuální technické záležitosti, které s celou situací souvisí. Těm se věnujeme. Děkujeme za pochopení.Otázka (doplněna po zveřejnění): Ta captcha je pěkně otravná. Pochopil bych ji u přihlášení do administrace, jednou ověřit, že nejsem robot, ale ne při každém přidání adresy, když jich přidávám 10, tak to po mě chce 10 ověření… Odpověď: Souhlasíme s otravností, ale je to obrana proti robotům (klientům jež použijí roboty) a kteří tam zadají stovky nebo tisíce nebo desítky tisíc IPv6 a celá akce a obrana bude k ničemu. Otázka (doplněna po zveřejnění): Omlouvám se, ale ač tento příběh zní velmi věrohodně, tak se mi nezdá jedna věc. Na Vaši síť opravdu nikdy neutočil někdo zevnitř z VPS? Odpověď: Mohli bychom si vymyslet cokoliv, ale napsali jsme pravdu. Útoky zevnitř byly, ale byly po IP4. Otázka (doplněna po zveřejnění): Proč jste neměli aplikovanou ochranu proti útokům zevnitř už preventivně? Omlouvám se, ale připadáte mi jako totální síťoví amatéři, i když ostatní Vaše inovace jsou vynikající. Odpověď: Na IPv4 jsme ochranu měli. Na IPv6 je situace mnohem komplikovanější a zkušenosti s ochranou na IPv6 jsou celosvětově menší. Počty IP adres je mnohonásobně větší a tak ochrana mnohem komplikovanější… Otázka (doplněna po zveřejnění): Můžete dát k dispozici nějaké statistiky velikosti útoků nebo je to tajné? Dle mého názoru se vám pouze zbláznilo interní routovani. Proč tedy nebyla aktivní (dle grafu) třetí trasa od ČD Telematika a druha trasa ma grafy až od tohoto “útoku”??? Odpověď: Pár čísel zaznělo v textu. Grafy neměřily, protože v době problém nefungoval sběr dat ze SNMP a routery neodpovídaly tak, aby data poskytovaly správně. Naše chyby jsme přiznali v textu. Věřte, že chyba v routování by byla to nejsnazší a určitě menší problém, než hledat co se stalo a vysvětlovat tohle a hledat řešení, jak tomu předejít v budoucnu. Ta captcha je pěkně otravná. Pochopil bych ji u přihlášení do administrace, jednou ověřit, že nejsem robot, ale ne při každém přidání adresy, když jich přidávám 10, tak to po mě chce 10 ověření…
Pokud máte další dotazy, tak se neváhejte zeptat. Určitě rádi odpovíme.
Závěrem
Ještě jednou se na závěr omlouváme všem dotčeným uživatelům VPS. Věříme, že jsme se této situace dostatečně poučili. Nyní jsme nasadili několik opatření a ještě další připravujeme s cílem, aby se nemohla podobná situace opakovat.
Aktuálně snad můžeme dodat to, že pracujeme na stavbě druhého datacentra a na přípravě nové služby, která bude v nejbližších týdnech spuštěna na veřejné testy. Nová služba bude kombinací webhostingu a VPS. Půjde o “jakési” managed VPS, kdy budete mít k dispozici parametry a výkon VPS, ale o správu VPS (určeného pro webhosting) se budeme starat my. K dispozici bude hodně novinek, které jste si žádali.
Nové datacentrum již stojí a čekáme na dodávku oken a následně již zahájíme instalace technologií ve vnitřních prostorách. Připomínáme, že půjde o jedno z nejbezpečnějších datacenter v ČR (servery v podzemí a za 30-110 cm železobetonu), které bude zároveň nejúspornějším a nejekologičtějším datacentrem (minimálně) v ČR. Servery budou chlazeny v olejové lázni a odpadní teplo bude využíváno pro ohřev městského koupaliště.
Zároveň chystáme i další novinky v naší nabídce, ale o tom až zase příště…