Iran „idzie offline”: dlaczego blackout internetu może potrwać dłużej i co mówią dane NetBlocks, Cloudflare i Kentik

Wprowadzenie do problemu / definicja luki

W Iranie trwa niemal całkowite odcięcie kraju od globalnego internetu (internet shutdown / blackout). To nie „awaria” w klasycznym sensie, tylko działanie administracyjne realizowane na poziomie operatorów i routingu: wycofywanie prefiksów z BGP, ograniczanie tras międzynarodowych, selektywne wygaszanie sieci mobilnych i stacjonarnych oraz próby przejścia na model dostępu tylko do wybranych, zatwierdzonych usług („whitelist”).

W skrócie

• Blackout zaczął się 8 stycznia i – według monitoringu – utrzymuje się na poziomie „prawie zera” ruchu międzynarodowego.
• Monitorzy wskazują, iż władze przygotowują model dostępu do ograniczonej listy dozwolonych serwisów, co sugeruje dłuższe utrzymanie restrykcji.
• NetBlocks raportuje, iż łączność niesatelitarna utrzymuje się w okolicach ~1% typowych poziomów.
• Część użytkowników próbuje obchodzić blackout przez Starlink, ale relacje mówią o „łatanej” dostępności i możliwym zagłuszaniu terminali.

Kontekst / historia / powiązania

Iran ma historię ograniczania łączności w okresach napięć społecznych. Cloudflare przypomina m.in. rozległy shutdown z listopada 2019 (w odpowiedzi na protesty) oraz zakłócenia z 2022 roku.
Obecna fala odcięć jest powiązana z protestami, a obserwatorzy zwracają uwagę na szybkie wdrożenie „kill switcha” w porównaniu do wcześniejszych epizodów.

Analiza techniczna / szczegóły „blackoutu”

1) Oś czasu: od IPv6 do pełnego „odcięcia”

Dane Cloudflare i Kentik wskazują na spójny scenariusz eskalacji:

• 11:49–11:50 UTC (8 stycznia): gwałtowne wycofanie ogłaszanej przestrzeni IPv6 (spadek rzędu ~98,5%), co jest klasycznym sygnałem celowego ograniczania osiągalności sieci.
• 16:30–17:00 UTC: szybki spadek wolumenu ruchu (ok. -90%) napędzany „gaśnięciem” największych operatorów/AS-ów (m.in. MCCI, IranCell, TCI).
• ok. 18:45 UTC: ruch z Iranu spada „efektywnie do zera”, co oznacza praktyczne odłączenie od globalnego internetu.

2) „Okienka” łączności i testy mechanizmów kontroli

Cloudflare zauważa krótkie, niestabilne powroty śladowej łączności 9 stycznia (m.in. chwilową dostępność publicznego resolvera DNS 1.1.1.1 oraz epizody w niektórych sieciach uczelni), po czym ruch znów zanika. Taki wzorzec często wskazuje na testowanie reguł filtracji/whitelistingu albo czasowe „wycieki” tras.

3) Sygnały „whitelistingu” i filtracji warstwowej

Ciekawym wskaźnikiem w danych Cloudflare jest spadek udziału HTTP/3/QUIC w ruchu „ludzkim” jeszcze przed pełnym blackoutem – co może pasować do scenariusza zaostrzenia filtracji i warstwowego ograniczania dostępu (np. blokady na poziomie protokołów/portów, SNI, DPI) przed finalnym odcięciem.
The Record podaje wprost, iż monitorzy spodziewają się wdrożenia dostępu opartego o listę dozwolonych serwisów (whitelist), co zwykle bywa „fazą przejściową” między pełnym blackoutem a kontrolowanym, szczątkowym internetem.

4) Łączność satelitarna jako „zmienna” (Starlink) i próby jej tłumienia

Reuters opisuje przypadki działania Starlink w części lokalizacji (zwłaszcza przy granicach), ale z ograniczeniami; eksperci dopuszczają scenariusz zagłuszania terminali (jamming), co w praktyce daje efekt „działa, ale słabo i niestabilnie”.

Praktyczne konsekwencje / ryzyko

• Utrata widoczności i telemetrii: firmy i organizacje utrzymujące systemy w Iranie tracą zdalny monitoring, EDR/siemowe „serce” i kanały administracyjne – rośnie ryzyko „cichej” degradacji bezpieczeństwa (brak aktualizacji, brak alertów, brak zdalnych reakcji).
• Rozpad procesów operacyjnych: płatności, logistyka, łańcuch dostaw, helpdesk, zdalne wsparcie – wszystko może przejść w tryb offline, z dużą liczbą błędów i nadużyć.
• Ryzyko eskalacji represji cyfrowych: jeżeli wejdzie model whitelistingu, można oczekiwać większej presji na „legalne” platformy (monitoring, identyfikacja użytkowników), a równolegle polowania na obejścia (VPN, satelity).
• Starlink nie jest panaceum: koszt, dostępność sprzętu, ryzyko zakłócania i prawne konsekwencje sprawiają, iż jest to kanał „dla nielicznych”, a nie masowe rozwiązanie.

Rekomendacje operacyjne / co zrobić teraz

Jeśli masz użytkowników, kontrahentów, infrastrukturę lub SOC-owe zależności od łączności z Iranem:

1. Włącz plan ciągłości działania na wypadek blackoutu
   Z góry zakładaj brak internetu, brak SMS i ograniczenia połączeń – tak jak sugerują obserwacje monitorów.
2. Zorganizuj kanały out-of-band (OOB)
   • telefony satelitarne / alternatywne łącza (tam, gdzie legalne i realne),
   • „store-and-forward” (np. okresowe synchronizacje danych, paczki aktualizacji),
   • lokalne procedury manualne (paper ops) dla krytycznych procesów.
3. Zabezpiecz pracę offline i opóźnioną synchronizację
   • lokalne logowanie zdarzeń i kolejkowanie telemetryki,
   • buforowanie polityk, kluczy i certyfikatów,
   • przygotowane nośniki aktualizacji (w kontrolowanym łańcuchu dostaw).
4. Monitoring sytuacyjny na bazie publicznych danych
   Ustal wewnętrzny „watch” na: Cloudflare Radar (ruch/routing), komunikaty monitorów (NetBlocks) i analizy operatorów/telemetrii (Kentik).
5. Scenariusz powrotu z „whitelistingu”
   Jeśli łączność wróci tylko dla wybranych usług, rozważ: minimalne „okno” na aktualizacje bezpieczeństwa, priorytetyzację krytycznych endpointów oraz kontrolę integralności (bo częściowa łączność sprzyja MITM i degradacji mechanizmów ochronnych).

Różnice / porównania z innymi przypadkami

• Szybkość wdrożenia: NetBlocks (cytowany przez The Record) wskazuje, iż obecny shutdown został wdrożony szybciej niż w 2019 roku, co sugeruje dojrzalsze procedury i lepiej „przećwiczoną” ścieżkę odcięcia.
• „Odcięcie routingowe” jako najważniejszy mechanizm: obserwowane wycofanie IPv6/BGP i spadek ruchu do zera pokazują, iż to nie tylko blokady aplikacyjne, ale twarde sterowanie osiągalnością sieci.
• Nowy element: satelity konsumenckie: Starlink daje część łączności „ponad” infrastrukturą naziemną, ale jednocześnie pojawia się presja na zagłuszanie i ściganie użytkowników.

Podsumowanie / najważniejsze wnioski

Blackout w Iranie to klasyczny przykład państwowego „kill switcha” wdrożonego na poziomie operatorów i routingu, z sygnałami przygotowań do modelu whitelistingu. Dane Cloudflare i Kentik pokazują spójny przebieg: najpierw twarde zmiany w IPv6/BGP, potem szybkie wygaszanie ruchu największych sieci aż do praktycznego „zera”. NetBlocks i Reuters potwierdzają, iż niesatelitarna łączność utrzymuje się na szczątkowym poziomie, a Starlink działa jedynie punktowo i może być zakłócany.

Źródła / bibliografia

• The Record (Recorded Future News) – „Internet monitoring experts say Iran blackout likely to continue” (The Record from Recorded Future)
• Cloudflare Blog / Cloudflare Radar – „What we know about Iran’s Internet shutdown” (The Cloudflare Blog)
• Kentik – „Iran Goes Dark as Government Cuts Itself Off from Internet” (Kentik)
• NetBlocks – aktualizacja o utrzymaniu łączności ok. ~1% i trwającym blackoutcie (NetBlocks)
• Reuters – „Iranians tap Musk’s Starlink to skirt internet blackout, sources say” (Reuters)