Skorzystaj z Black Friday!
Tylko teraz z kodem bf100 otrzymasz 100 zł rabatu na roczny plan INNASIEĆ PREMIUM.
Nie przegap okazji, by zyskać więcej za mniej!
Jak duplikaty w bazie danych położyły globalną sieć?

18 listopada 2025 roku Cloudflare doświadczyło najpoważniejszej awarii od 2019 roku. Przez ponad 3 godziny większość ruchu przestała przepływać przez ich sieć. Źródło problemu? Pozornie niewinna zmiana uprawnień w bazie danych ClickHouse.
O 11:05 UTC zespół Cloudflare wdrożył zmianę w zarządzaniu uprawnieniami ClickHouse, mającą poprawić bezpieczeństwo zapytań rozproszonych. Zapytanie SQL pobierające metadane kolumn dla systemu Bot Management nie filtrowało po nazwie bazy danych:
SELECT name, type FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;
Po zmianie uprawnień zapytanie zaczęło zwracać duplikaty - kolumny zarówno z bazy default, jak i r0. Plik konfiguracyjny "features" urósł dwukrotnie, przekraczając hardcoded limit 200 cech w systemie prealokacji pamięci. Efekt: panic w kodzie Rust i błędy 5xx dla całego ruchu.
Plik generował się co 5 minut. W zależności od tego, który node ClickHouse obsługiwał zapytanie (z nowymi uprawnieniami czy bez), system albo działał, albo padał. Ta fluktuacja między stanem poprawnym a błędnym przekonała zespół, że być może to atak DDoS typu Aisuru. Dodatkowo, strona statusowa Cloudflare (hostowana poza ich infrastrukturą) akurat w tym samym momencie przestała działać z niezależnych powodów - potęgując podejrzenie o skoordynowany cyberattack.
Kluczowe wnioski dla architektów
Prealokacja pamięci to miecz obosieczny. Cloudflare używał limitu 200, przy rzeczywistym użyciu ~60 dla optymalizacji. Brak graceful degradation zamienił mechanizm wydajnościowy w single point of failure.
Zapytania bez pełnych kwalifikatorów są tykającą bombą. W systemach rozproszonych każde zapytanie powinno jawnie definiować scope - w tym przypadku brak WHERE database = 'default' stworzył ukrytą zależność.
Testowanie założeń o danych wejściowych. Cloudflare traktował wewnętrznie generowane pliki konfiguracyjne jak zaufane. Po incydencie planują walidować je jak user input - zasada, którą warto przyjąć od razu.
Cloudflare wdraża globalne kill switches dla modułów, eliminuje możliwość przeciążenia systemu przez core dumps i przepisuje obsługę błędów we wszystkich modułach proxy.
Dla nas lekcja jest jasna: w architekturze rozproszonej każda "niewinna" zmiana w warstwie danych może mieć kaskadowe skutki w warstwie aplikacyjnej. Defensive programming nie jest paranoją - to konieczność.
Jak zepsuć PMTUD w GRE na Palo Alto

"Niektóre strony działają, inne nie" – to scenariusz, który każdy sieciowiec woli uniknąć. Problem pojawił się w środowisku z Zscalerem przez tunel GRE z Palo Alto Networks. Diagnoza? Klasyka: jeśli to nie DNS, to MTU.
W Zone Protection Profile na Palo Alto była włączona opcja "Suppress ICMP Frag Needed". Ta funkcja robi dokładnie to, co sugeruje nazwa – blokuje komunikaty ICMP "fragmentation needed". Problem w tym, że zabija sesje z ustawionym bitem "Don't Fragment", które przekraczają niższe MTU tunelu GRE.
Dlaczego troubleshooting był trudny?
Żaden log w GUI Palo nie pomaga:
- Traffic log pokazuje dozwolone połączenia
- Threat log nie widzi zagrożeń
- Trzeba sięgnąć po
show counter global,show zone-protectionlub packet capture z Wiresharkiem
Wireshark pokazał całą historię: pakiet SYN z niskim MSS (1376), serwer odpowiada większym payloadem, Palo powinien zwrócić ICMP unreachable z MTU 1400/1376 – ale tego nie robi przez blokadę.
Quick fix: Wyłącz "Suppress ICMP Frag Needed" w Zone Protection Profile.
Alternatywa: Dostosuj TCP MSS na interfejsie Palo. Dla GRE potrzeba adjustment 64 zamiast domyślnych 40 (GRE header: 24 bajty). Uwaga: to rozwiązuje tylko problemy TCP, nie sam problem z MTU.
Oferty na Black Friday
Repozytorium zawiera zbiór promocji związanych z Black Friday i Cyber Monday 2024, skupiający się na ofertach z zakresu sieci komputerowych i automatyzacji. Znajdziesz tu rabaty na szkolenia, książki, narzędzia do zdalnego pulpitu i wirtualizacji oraz subskrypcje platform edukacyjnych.
Automatyzacja obrazów Dockera dla CML
Projekt automatyzuje budowanie kontenerów Docker dla Cisco Modeling Labs (CML) 2.9+. Repozytorium zawiera szablony i skrypty do tworzenia obrazów kontenerów, definicji węzłów i pakietów Debiana, które można używać lokalnie lub w CI (GitHub Actions). Budowanie odbywa się przez Makefile, który wykrywa katalogi z Dockerfile i generuje wymagane pliki w strukturze zgodnej z CML.
Infrahub + Arista AVD
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj

