📬 ISN 193: Cyfrowe Bliźniaki, Atak DDoS i Testy SNMP: Jak Zabezpieczyć Sieć?

Nowy rekord ataku DDoS

W połowie maja 2025 roku Cloudflare zablokował największy atak DDoS w historii, osiągający 7,3 terabity na sekundę (Tbps).

Atak dostarczył 37,4 terabajty danych w zaledwie 45 sekund. To równowartość przesłania ponad 9 350 filmów HD lub strumieniowania 7 480 godzin wideo wysokiej rozdzielczości w mniej niż minutę.

Cel ataku stanowił dostawca hostingu korzystający z usługi Magic Transit Cloudflare. Atakujący bombardowali średnio 21 925 portów docelowych jednego adresu IP, z maksymalnym natężeniem 34 517 portów na sekundę.

Analiza ruchu wykazała, że 99,996% ataku stanowił flooding UDP. Pozostałe 0,004% (1,3 GB) składało się z:

Ataków refleksyjnych QOTD
Ataków refleksyjnych Echo
Ataków refleksyjnych NTP
Powodzi UDP Mirai
Powodzi Portmap
Ataków amplifikacyjnych RIPv1

Atak pochodził z ponad 122 145 unikalnych adresów IP, obejmujących:

5 433 systemy autonomiczne (AS)
161 krajów
Średnio 26 855 unikalnych adresów IP na sekundę

Największy udział w ataku miały:

Brazylia i Wietnam - łącznie około 50% ruchu
Telefonica Brazil (AS27699) - 10,5% całkowitego ruchu
Viettel Group (AS7552) - 9,8%
China Unicom (AS4837) - 3,9%

Zaatakowany adres IP był anonsowany z sieci Cloudflare przy użyciu globalnego anycast. Ruch ataku został automatycznie rozproszony do 477 centrów danych w 293 lokalizacjach na całym świecie, wykorzystując rozproszoną naturę ataku przeciwko niemu samemu.

Proces odpierania takiego ataku składa się z 5 kroków:

Wykrywanie: System analizuje próbki pakietów w poszukiwaniu wzorców
Liczenie: Algorytmy strumieniowe identyfikują najbardziej aktywne odciski palców
Aktywacja: Po przekroczeniu progów kompilowana jest reguła eBPF
Mitygacja: Pakiety pasujące do wzorca są automatycznie odrzucane
Dezaktywacja: Reguła automatycznie wygasa po zakończeniu ataku

Automatyczna konfiguracja sieci w Docker Compose

Docker Compose automatycznie tworzy izolowane sieci bridge dla każdego projektu. Każdy kontener otrzymuje własny adres IP oraz wpisy DNS, umożliwiając komunikację między usługami bez konieczności znajomości konkretnych adresów IP.

Przyjrzyjmy się prostemu przykładowi demonstrującemu mechanizmy sieciowe:

# compose.yaml
name: "example"

services:
  a:
    image: "hashicorp/http-echo"
    command: ["-text=Hello from A!"]
    stop_grace_period: "1s"

  b:
    image: "hashicorp/http-echo" 
    command: ["-listen=:5679", "-text=Hello from B!"]
    stop_grace_period: "1s"

  http-client:
    image: "curlimages/curl"
    command: ["sleep", "infinity"]
    stop_grace_period: "1s"

Po uruchomieniu projektu komendą docker compose up, automatycznie tworzona jest sieć example_default.

Testowanie łączności między kontenerami

$ docker compose exec http-client curl a:5678
Hello from A!

$ docker compose exec http-client curl b:5679
Hello from B!

Inspekcja sieci Docker

$ docker network inspect example_default

Kluczowe parametry sieci:

Driver: bridge (domyślny dla Docker Compose)
Subnet: 172.27.0.0/16 (może się różnić w zależności od liczby istniejących sieci)
Gateway: 172.27.0.1
Zakres adresów: Automatycznie przydzielane z puli subnet

Docker Compose tworzy dla każdego serwisu następujące wpisy DNS:

Nazwa serwisu (np. a, b, http-client)
Pełną nazwę kontenera (np. example-a-1)
ID kontenera (np. 324f50a7a70a)

Inspekcja właściwości sieciowych kontenera

$ docker container inspect example-http-client-1

Fragment wyniku pokazujący konfigurację DNS:

"Networks": {
    "example_default": {
        "Aliases": [
            "example-http-client-1",
            "http-client"
        ],
        "DNSNames": [
            "example-http-client-1", 
            "http-client",
            "24c028f7e49d"
        ],
        "IPAddress": "172.27.0.4",
        "Gateway": "172.27.0.1"
    }
}

Oczywiście, jeśli potrzebujesz, jest możliwość dodawania własnych aliasów DNS:

services:
  a:
    image: "hashicorp/http-echo"
    command: ["-text=Hello from A!"]
    networks:
      default:
        aliases:
          - "apple"

Po tej modyfikacji serwis będzie dostępny również pod nazwą apple:5678.

Adres bramy (Gateway IP) 172.27.0.1 pełni kluczową rolę w komunikacji:

Wszystkie kontenery w sieci używają tego samego adresu bramy
Umożliwia komunikację z hostem Docker
Dostępny dla ping z każdego kontenera w sieci

Przy publikowaniu portów na host:

services:
  a:
    image: "hashicorp/http-echo"
    ports: ["5678:5678"]

Możliwa staje się komunikacja przez adres bramy:

$ docker compose exec http-client curl 172.27.0.1:5678
Hello from A!

Ruch kierowany na adres bramy z opublikowanym portem jest przekierowywany przez hosta Docker z powrotem do odpowiedniego kontenera.

Najlepsze praktyki bezpieczeństwa

Unikaj publikowania portów jeśli komunikacja odbywa się tylko między kontenerami
Używaj niestandardowych sieci dla złożonych topologii
Monitoruj przydzielone zakresy IP aby uniknąć konfliktów

Problem z tworzeniem cyfrowych bliźniaków

Artykuł omawia wyzwania i ograniczenia związane z tworzeniem cyfrowych bliźniaków sieci (Network Digital Twins). Ivan Pepelnjak zwraca uwagę na bariery techniczne, problemy z emulacją warstwy danych i zachowaniem protokołów sterujących często odbiega od rzeczywistości, co utrudnia testowanie automatyzacji sieci.

Testowanie SNMP

Go SNMP Tool Kit to narzędzie napisane w Go do testowania SNMP. Aplikacja oferuje zaawansowane funkcje wykrywania urządzeń, operacje SNMP (GET, WALK itp.) oraz precyzyjne rozpoznawanie producentów takich jak Cisco, Dell i Arista.

Mikrosegmentacja warstwy drugiej

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

Masz już konto? Zaloguj się