CDN
| Po angielsku | content delivery network (CDN) |
|---|---|
| Którą formą pisać | bez tłumaczenia Skrót, nazwa własna albo nazwa standardu — nie tłumaczymy w ogóle. |
| Inne formy | sieć dostarczania treści · sieć dystrybucji treści |
| Kategoria | Sieć i infrastruktura obronna |
CDN (content delivery network, sieć dostarczania treści) to grupa serwerów rozmieszczonych w wielu lokalizacjach, które przechowują kopie danych, tak aby żądanie obsłużył serwer najbliższy użytkownikowi [1]. Pierwotnym celem jest szybkość i odporność na duży ruch [1]. W bezpieczeństwie CDN pełni drugą rolę: stoi przed serwerem źródłowym, przyjmuje ruch zamiast niego i może go filtrować, w tym ruch ataków DDoS. Zarazem jest kolejnym pośrednikiem, którego konfiguracja i awarie wpływają na dostępność strony.
Jak działa
Użytkownik nie łączy się bezpośrednio z serwerem strony, tylko z węzłem brzegowym CDN. Węzeł sprawdza, czy ma zapisaną odpowiedź na takie żądanie. Jeśli ma, oddaje ją od razu. Jeśli nie, pobiera ją z serwera źródłowego (origin), zapisuje i przekazuje dalej. Przebieg pokazuje schemat poniżej.
Zasady przechowywania odpowiedzi opisuje specyfikacja HTTP. RFC 9111 nazywa CDN-y i inne takie pośredniki pamięcią współdzieloną (shared cache): przechowuje ona odpowiedzi do ponownego użycia przez więcej niż jednego użytkownika [2]. Pamięć prywatna należy do jednego użytkownika i zwykle działa w przeglądarce [2]. Serwer steruje zachowaniem pośrednika nagłówkiem Cache-Control.
| Dyrektywa | Znaczenie dla CDN |
|---|---|
public, max-age | odpowiedź wolno przechować na wskazany czas [2] |
private | pamięć współdzielona nie może jej zapisać [2] |
no-store | żadna pamięć nie może zapisać żądania ani odpowiedzi [2] |
Z punktu widzenia sieci CDN działa jak reverse proxy: to jego adresy widzi odwiedzający, a serwer źródłowy widzi adresy CDN [5].
W WordPressie
Dokumentacja WordPressa zaleca CDN do wydajności. Przeniesienie obrazów, JavaScriptu, CSS i plików motywu na CDN ma być szybsze i zdejmować obciążenie z serwera WordPressa [3]. Dokumentacja dodaje, że CDN może powielać pliki statyczne w różnych regionach geograficznych, a nowsze usługi oferują też buforowanie całych stron (Full Page Caching, Edge Caching) [3]. Najlepiej działa w parze z wtyczkami buforującymi [3].
Z tym wiążą się trzy sprawy bezpieczeństwa.
Adres IP odwiedzającego. Za CDN serwer w logach widzi adres pośrednika. Cloudflare podaje prawdziwy adres w nagłówku CF-Connecting-IP, a jako alternatywę wymienia X-Forwarded-For [5]. Ma to znaczenie dla limitu prób logowania, wtyczek bezpieczeństwa i blokad adresów. Jeśli wtyczka widzi tylko adres CDN, zablokuje wszystkich naraz albo nikogo. Jeśli bezwarunkowo ufa nagłówkowi, atakujący łączący się z pominięciem CDN może go sfałszować. Nagłówek jest wiarygodny tylko wtedy, gdy połączenie przyszło z adresu CDN.
Strony dla zalogowanych. Buforowanie całych stron nie może obejmować panelu /wp-admin/, koszyka ani stron z danymi konta. Taka odpowiedź powinna mieć Cache-Control: private albo no-store [2]; inaczej pamięć współdzielona może oddać cudzą stronę innemu odwiedzającemu.
Ukrycie serwera źródłowego. Ochrona przez CDN działa tylko wtedy, gdy ruch nie może go obejść. Zob. niżej.
Znaczenie dla bezpieczeństwa
Cloudflare zaleca kierowanie rekordów DNS przez swoją sieć, aby ukryć adresy IP serwera źródłowego i objąć go ochroną przed DDoS [4]. Ostrzega przy tym, że historyczne rekordy DNS zawierają adresy sprzed przejścia na CDN [4]. Serwer, którego adres wyciekł, można zaatakować bezpośrednio. Dlatego zaleca się też dopuszczanie na serwerze tylko adresów CDN, choć producent ocenia tę metodę jako średnio pewną, bo podatną na podszywanie się pod adres [4]. Mocniejsza jest weryfikacja kryptograficzna, że żądanie pochodzi z sieci CDN (Authenticated Origin Pulls), wymagająca pełnego szyfrowania TLS między CDN a serwerem [4].
Wiele usług CDN oferuje też WAF i rate limiting na brzegu sieci. Filtrowanie przed serwerem odciąża hosting przy zalewie żądań HTTP i odcina część złośliwych botów. Nie zastępuje to jednak aktualizacji: ruch, który przejdzie przez filtr, trafia do tego samego kodu WordPressa.
Zagrożenia i skutki
Zatrucie pamięci podręcznej. Web cache poisoning to technika, w której atakujący wykorzystuje zachowanie serwera i pamięci podręcznej tak, że szkodliwa odpowiedź trafia do innych użytkowników [6]. Pamięć rozpoznaje równoważne żądania po kluczu (cache key), zwykle wierszu żądania i nagłówku Host; pozostałe elementy są pomijane [6]. Jeśli aplikacja buduje odpowiedź z nagłówka spoza klucza, zatruta kopia trafia do każdego, czyje żądanie pasuje do klucza, dopóki pozostaje w pamięci [6]. Pokrewny błąd opisuje hasło host header injection.
Wspólny punkt awarii. Jeden dostawca obsługuje tysiące serwisów, więc jego awaria wyłącza je wszystkie naraz. Zob. przykład poniżej.
Zaufanie do dostawcy. Ruch strony przechodzi przez infrastrukturę zewnętrznej firmy, więc CDN jest elementem łańcucha dostaw, który warto uwzględnić przy ocenie ryzyka.
Historia i przykłady
8 czerwca 2021 roku o 9:47 UTC sieć CDN Fastly zaczęła zwracać błędy w 85% swojej infrastruktury [7]. Przyczyną był błąd oprogramowania, uruchomiony przez poprawną zmianę konfiguracji wprowadzoną przez jednego z klientów [7]. Fastly wykrył problem w ciągu minuty, 95% sieci przywrócił w ciągu 49 minut, a pełne usunięcie skutków nastąpiło o 12:35 UTC [7]. Sekurak odnotował, że niedostępne były wtedy m.in. Reddit, PayPal, Spotify, Twitch i Stack Overflow [8]. Zdarzenie pokazało, że CDN poprawia odporność pojedynczej strony, ale sam staje się elementem, którego dostępność trzeba brać pod uwagę.
Przypisy
8- [1] CDN — MDN Web Docs Glossary · MDN Web Docs
- [2] RFC 9111: HTTP Caching · IETF
- [3] Optimization — Advanced Administration Handbook · WordPress.org
- [4] Protect your origin server · Cloudflare
- [5] Restoring original visitor IPs · Cloudflare
- [6] Web cache poisoning · PortSwigger Web Security Academy
- [7] Summary of June 8 outage · Fastly
- [8] Niedostępne serwisy: Reddit, Paypal, Spotify, Twitch czy Stackoverflow – awaria CDN Fastly · sekurak.pl
Hasła w tym artykule
12Linkują tutaj
33- NIS2
- WAF
- DDoS
- limit prób logowania
- wirtualne patchowanie (virtual patching)
- TLS
- atak odmowy usługi
- mixed content
- HSTS (HTTP Strict Transport Security)
- host header injection
- nagłówki bezpieczeństwa HTTP
- zabezpieczenia w .htaccess
- złośliwe boty
- HTTP request smuggling
- subdomain takeover
- web cache poisoning
- HTTP flood
- rate limiting
- algorytm generowania domen
- reverse proxy
- DPI (deep packet inspection)
- kryptografia postkwantowa
- amplifikacja
- biała lista adresów IP
- forward secrecy
- geoblokowanie
- serwer proxy
- SYN flood
- zarządzanie ryzykiem dostawców (TPRM)
- DNSSEC
- haktywista
- bezpieczeństwo IoT (internetu rzeczy)
- infrastruktura krytyczna