Hlavní navigace

Webhosting s Cloudflare: bezpečná CDN zdarma

Ondřej Caletka

Provozovat bezpečný web vyžaduje spoustu úsilí. Veřejná reverzní proxy Cloudflare dokáže spoustu věcí zásadním způsobem zjednodušit.

Poznámka: Tento článek prezentuje konkrétní komerční službu. Autor článku ani redakce nemá žádný nadstandardní vztah s provozovatelem služby. Provozovatel služby vydání článku žádným způsobem neovlivňoval.

Motivace

Provozovat web není na první pohled žádná věda. S trochou úsilí to zvládnete i na dnešní broadbandové domácí přípojce. Trochu horší to je, když chcete provozovat bezpečný web. V tu chvíli se všechno začne komplikovat o zkratky jako DNSSEC, TLS, nebo třeba HSTS. Když se stránka dostane pod útok (ať už zlomyslný, nebo takzvaný Slashdot effect), domácí přípojka se rychle zahltí a vy zůstanete bez připojení.

Služba Cloudflare představuje distribuovaný reverzní proxy server, který můžete svému web serveru předsunout. I v základní verzi, která je zdarma, zahrnuje unikátní a velmi užitečné vlastnosti:

  • plná podpora IPv4 a IPv6: Můžete mít tedy například zdrojový server na IPv6-only (což je často levnější) a přesto se k němu dostanou i klienti z IPv4-only sítí, kterých je stále většina. Máte-li domů zavedeno IPv6, můžete takový web provozovat třeba přímo na domácím serveru.
  • automatické HTTPS s důveryhodným certifikátem: Dnes, v době Let's Encrypt už tolik nepřekvapí, nicméně zde je získání certifikátu zcela bez práce. Služba také podporuje moderní protokol HTTP/2.
  • plná podpora DNSSEC: Cloudflare je první velkou sítí typu CDN, která implementovala technologii DNSSEC s využitím moderních algoritmů a technik. Navíc se aktivně zapojuje do diskuzí v rámci internetových komunit a vymýšlí způsob, jak v budoucnu DNSSEC nasadit plošně, bez nutnosti zásahu uživatele.

Všechno má samozřejmě své ale. V tomto případě jde především o to, že službě musíte bezmezně důvěřovat. Z principu činnosti může její provozovatel jakýmkoli způsobem zasahovat do webového obsahu. Také vzhledem k distribuované povaze služby může nastat situace, kdy klienti neuvidí ze všech míst světa konzistentní obsah, či neuvidí obsah vůbec, pokud dojde k výpadku.

Technickým požadavkem je pak také delegace veřejné SLD domény na servery Cloudflare. Subdoménu není možné použít. To je poněkud komplikované faktem, že Cloudflare, na rozdíl od jiných, neplní roli registrátora domény. To pro uživatele znamená, že musí sám najít vhodného registrátora a všechno správně ručně nastavit.

Registrujeme doménu

Celý proces tedy musíme začít registrací vhodné domény druhého řádu. V následujícím postupu celý proces demonstruji na reálné doméně internetovehazardnihry.cz, kterou jsem za účelem pokusů pořídil. Celý postup bohužel není zcela intuitivní a vyžaduje celkem trojnásobnou komunikaci s registrátorem.

Aby bylo možné službu Cloudflare zprovoznit, musí daná doména existovat alespoň v příslušné whois databázi. Je tedy potřeba při registraci zvolit nějaké dočasné delegování domény, například na DNS servery registrátora. Ihned poté je možné přidat doménu do Cloudflare.

Po zadání doménového jména se Cloudflare začne snažit zjistit co nejvíce informací o obsahu zónového souboru, což bude chvíli trvat. U nové domény pravděpodobně nezjistí nic a nechá vás nastavit záznamy ručně. Kromě klasického editoru DNS záznamů, obsahujícím typ záznamu, jeho držitele, příslušnou pravou stranu a dobu života, je zde také ikona oranžového nebo šedého obláčku. Je-li šedivý, jedná se o klasický DNS záznam. Oranžová barva pak znamená představení CDN sítě Cloudflare. V praxi tedy IP adresa takového záznamu nebude veřejně viditelná a bude nahrazena adresami proxy serverů služby Cloudflare.

Teprve v dalším kroku, po výběru vhodného tarifu, jsme instruováni k předelegování domény na autoritativní DNS servery Cloudflare. V mém konkrétním příkladě jde o adresy fiona.ns.cloudflare.com a rudy.ns.cloudflare.com. V případě registru domén CZ je třeba nejprve vytvořit tzv. sadu jmenných serverů (NSset). Takový objekt zdarma zaregistruje libovolný registrátor (klidně odlišný od registrátora domény jako takové). Po jeho vytvoření je třeba u registrátora domény změnit hodnotu nsset ze stávající na jméno nově zřízeného objektu. Poté je třeba vyčkat, než se změna projeví v zóně cz. V případě této domény prvního řádu se změna projeví přibližně do hodiny.

Zavádění DNSSECu

Cloudflare bohužel neumožňuje na doméně zapnout DNSSEC předtím, než je nadelegována na jeho servery. Po úspěšné delegaci a aktivaci DNSSECu v ovládacím panelu, nás služba požádá provedení bezpečné delegace, tedy umístění DS záznamu do nadřazené zóny. To je třeba opět dělat prostřednitcvím registrátora. Tentokrát je potřeba v centrálním registru založit objekt typu sada klíčů (KEYset). Na rozdíl od praxe ve většině jiných doménových registrů vyžaduje CZ.NIC nikoli DS záznam, ale celý veřejný klíč. To z toho důvodu, aby mohl být stejný keyset sdílen více doménami ( DS záznam je otiskem veřejného klíče a jména domény). I tento Cloudflare zveřejňuje, pod nadpisem Public Key. Registrátor bude potřebovat ještě další hodnoty – Flags (vždy 257 – KSK), Protocol (vždy 3 – DNSSEC) a Algorithm (v současné době 13 – ECDSAP256SHA256).

Po přiřazení keysetu a opět určitém čekání by měla doména plynule přejít do podepsaného režimu.

Bezpečné HTTPS

Protože jde o úplně novou webovou službu, není třeba dělat kompromisy ohledně bezpečnosti. Cloudflare automaticky nabízí TLS se sdíleným důvěryhodným certifikátem. Ve výchozím nastavení Flexible SSL ovšem komunikuje se zdrojovým serverem (tedy vaším vlastním webserverem) pouze prostřednictvím nešifrovaného HTTP. To rozhodně není optimální. Změnit nastavení je možné v ovládacím panelu domény na kartě Crypto.


Cloudflare

Vysvětlení jednotlivých režimů SSL

Jediné opravdu bezpečné nastavení je označené jako Full (strict). Striktní režim zde znamená, že Cloudflare bude vyžadovat validní certifikát vystavený na správné jméno zdrojového webserveru, jinak spojení odmítne. Nabízí se použití služby jako Let's Encrypt (například klientacme.sh má podporu pro DNS API Cloudflare), je zde však ještě jedno elegantní řešení.

Tím je vlastní autorita Cloudflare Origin CA. Tato autorita není veřejně důvěryhodná, důvěřují jí však proxy servery Cloudflare. Velice snadno je možné nechat si vygenerovat certifikát s dobou života 15 let a tento certifikát následně nainstalovat na zdrojový server. Pro zjednodušení života vám může Cloudflare vygenerovat rovnou pár privátního klíče a certifikátu (preferovaně s algoritmem ECDSA). V tomto případě generování privátního klíče na straně serveru nepředstavuje významný bezpečnostní problém; jak bylo uvedeno již v úvodu, službě Cloudflare je třeba bezmezně věřit, neboť má tak jako tak plnou moc nad obsahem dané domény.

Instalace certifikátu je také velmi snadná, protože na rozdíl od běžných veřejných certifikátů zde není potřeba posílat žádný další certifikát kromě koncového. Konfigurace Apache na zdrojovém serveru tak může vypadat třeba takto:

<VirtualHost 192.168.0.1:443>
DocumentRoot   /var/www/html2
ServerName     www.yourdomain.com
SSLEngine      on
SSLCertificateFile        /path/to/your_domain_name.crt
SSLCertificateKeyFile     /path/to/your_private.key
</VirtualHost> 

Vynucení HTTPS

Důležité je si uvědomit, že v bezplatné verzi Cloudflare nepodporuje HTTPS spojení ke zdrojovému serveru, pokud klient položil dotaz prostřednictvím HTTP. Je tedy nutné na zdrojovém serveru zprovoznit jak HTTPS, tak i HTTP. Chceme-li však HTTP použít v souladu s nejlepší současnou praxí pouze pro přesměrování na HTTPS, můžeme takové přesměrování nastavit už uvnitř CDN pomocí funkce Page Rules. Tím je systém i krapet bezpečnější, protože úvodní nešifrovaná komunikace se odehrává pouze mezi klientem a CDN, takže útočník mezi CDN a zdrojovým serverem ji nemůže narušit. Bezplatná verze nabízí 3 taková pravidla, takže je možné kromě vynucení HTTPS ještě třeba přesměrovávat na kanonickou variantu doménového jména (buď s, nebo naopak bez www. na začátku).

HTTP Strict Transport Security

Cloudflare také nabízí možnost zapnout HTTP Strict Transport Security. V případě zcela nové služby je možné opět nekompromisně hlavičku zapnout, nastavit nejdelší možnou životnost (12 měsíců), zahrnout všechny subdomény a zapnout volby Preload a No-sniff. Zobrazuje se zde výrazné varování, aby si každý uvědomil důsledky povolení této hlavičky.

Je-li hlavička nastavena, a máme-li správně nastavené přesměrování z HTTP na HTTPS, můžeme požádat o přidání doménového jména do vestavěného seznamu vynuceně šifrovaných doménových jmen pro internetové prohlížeče. Tím v budoucnu eliminujeme i úplně první nešifrovaný požadavek, který by odeslal čerstvě instalovaný webový prohlížeč.

Autentizace CDN vůči zdrojovému serveru

Poměrně zajímavou funkcí je Authenticated Origin Pulls. Pokud ji zapneme, budou se servery Cloudflare při spojení se zdrojovým webserverem představovat klientským certifikátem vystaveným ze speciální certifikační autority. Můžeme tedy poté nastavit webserver tak, aby vyžadoval od všech klientů předložení klientského certifikátu. Tím zcela znemožníme útočníkovi, který nějakým způsobem zjistil IP adresu zdrojového serveru, aby se na něj připojoval přímo a tím obcházel případné bezpečnostní funkce uvnitř Cloudflare.

Funkci je možné zapnout bez starostí – pokud zdrojový server o klientský certifikát nepožádá, vše funguje stejně jako dosud. Aby webserver požadoval patřičný klientský certifikát, je třeba do konfigurace webserveru (např. Apache) přidat:

SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /path/to/origin-pull-ca.pem 

Web podle současných standardů

Použitím výše zmíněných nastavení získáme webové stránky podporující DNSSEC i IPv6 a šifrované HTTPS s podporou moderního protokolu HTTP/2 a vynuceným šifrováním díky hlavičce HSTS, což je možné ověřit například známým testem od SSL Labs.

Co už návštěvník nevidí, je že podobně zabezpečené je i spojení serverů Cloudflare se zdrojovým webserverem, takže případný útočník nemá šanci do komunikace zasáhnout ani tam. Je však třeba dávat pozor na případné útoky postranními kanály. V tomto případě zejména odcizením přístupových údajů ke službě Cloudflare či k registrátorovi domény, které může vést až k únosu domény. Hodí se proto používat více faktorovou autentizaci, kde jen to je možné a domény včetně příbuzných objektů zamykat přímo na úrovni centrálního registru.

Našli jste v článku chybu?