📬 ISN 204: Exodus IPv4 z Ukrainy, Fałszywe Certyfikaty 1.1.1.1 i Automatyzacja z Ansible!

Nieautoryzowane certyfikaty dla 1.1.1.1

Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1

Unauthorized TLS certificates were issued for 1.1.1.1 by a Certification Authority without permission from Cloudflare. These rogue certificates have now been revoked. Read our blog to see how this could affect you.

The Cloudflare BlogJoe Abley

W okresie od lutego 2024 do sierpnia 2025 roku Fina CA wydało szereg certyfikatów dla adresu IP 1.1.1.1 bez wiedzy i zgody Cloudflare. Incydent został ujawniony dzięki systemowi Certificate Transparency, podkreślając jednocześnie krytyczne znaczenie monitorowania certyfikatów w infrastrukturze sieciowej.

Cloudflare zostało powiadomione o problemie przez:

• Program ujawniania luk w zabezpieczeniach
• Listę mailingową certificate transparency
• Zgłoszenia na platformach takich jak Hacker News

Wszystkie nieautoryzowane certyfikaty dla 1.1.1.1 miały następujące charakterystyki:

• Ważność dokładnie jeden rok
• Zawierały inne nazwy domen, z których większość nie była zarejestrowana
• Wskazywały na fikcyjną organizację "TEST D.D."

Lista nazw domen znalezionych w nieautoryzowanych certyfikatach:

fina.hr
ssltest5
test.fina.hr
test.hr
test1.hr
test11.hr
test12.hr
test5.hr
test6
test6.hr
testssl.fina.hr
testssl.finatest.hr
testssl.hr
testssl1.finatest.hr
testssl2.finatest.hr

Aby wykorzystać te nieautoryzowane certyfikaty do podszywania się pod usługę 1.1.1.1, atakujący musiałby spełnić wszystkie następujące warunki:

1. Posiadanie certyfikatu i klucza prywatnego - Certyfikat został wydany, więc należy założyć istnienie odpowiadającego mu klucza prywatnego
2. Zaufanie klientów do Fina CA - Centrum certyfikacji jest domyślnie uwzględnione w magazynie certyfikatów głównych Microsoft i EU Trust Service provider
3. Przechwycenie ruchu - Ruch między klientem a 1.1.1.1 musiałby zostać przechwycony

Cloudflare zidentyfikowało trzy główne niedociągnięcia w swoim systemie monitorowania:

1. Monitoring certyfikatów IP - System nie alarmował o certyfikatach dla adresów IP
2. Filtrowanie alertów - Niewystarczające filtrowanie przy dużej liczbie nazw i wydań
3. Konfiguracja alertów - Nie wszystkie domeny miały włączone alerty

Planowane ulepszenia

Alerty - Poprawa alertów i eskalacji dla wydawania certyfikatów dla brakujących domen należących do Cloudflare

Transparentność - Wprowadzenie wymagania transparency dla klientów DNS, szczególnie tych korzystających z TLS

Bug Bounty - Rewizja procesu raportów w programie ujawniania luk

Monitoring - Rozwój dedykowanego interfejsu użytkownika do eksploracji danych CT w Cloudflare Radar

Eksodus IPv4 z ogarniętej wojną Ukrainy

Exodus of IPv4 from War-torn Ukraine

In this post, we discuss how the ongoing war in Ukraine has led to a significant decline in the amount of IPv4 address space announced by Ukrainian Autonomous Systems (ASes), and why those addresses are often now being announced by western ISPs and major public clouds.

KentikDoug Madory

Wojna w Ukrainie od 2022 roku odbiła się szerokim echem na sieciach. W ciągu trzech lat zanotowano niemal 18,5% spadek ogłoszonej przez ukraińskie AS-y przestrzeni adresowej IPv4.

Dlaczego to ważne? Adresy IPv4 to cenny zasób, używany przez operatorów do świadczenia usług. Gdy przestają być ogłaszane przez ukraińskie ASN, często przejmuje je Zachód, chmury publiczne lub brokerzy IPv4.

Nie każda firma podążyła ścieżką sprzedaży lub leasingu. Oto lista operatorów, którzy utrzymali swoje bloki praktycznie bez zmian od początku wojny:

• Kyivstar (AS15895): 2964 x /24
• Triolan (AS13188): 1605 x /24
• Lifecell (AS34058): 1508 x /24
• Vodafone (AS21497): 1361 x /24
• Datagroup (AS3326), Tenet (AS6876) i inni: po kilkaset /24

Ich strategia polegała na utrzymaniu lokalnej usługi, na przekór przeciwnościom.

Ukrtelecom znacząco zredukował swoją obecność w routingu globalnym. Wartości:

• AS6849: z 4728 x /24 do 1377 x /24 (spadek 71%)
• AS6877: praktycznie zniknął z tablicy routingu

Co się stało z tymi adresami? Większość trafiła do brokerów IPv4. Kluczowe sieci, które teraz ogłaszają te zasoby to m.in.:

• AS174 (COGENT): 91.124.96.0/22
• AS16509 (AWS): 91.124.133.0/24
• AS7018 (AT&T): 91.124.2.0/24

Te bloki są teraz rozproszone globalnie i wykorzystywane przez firmy hostingowe, operatorów chmurowych, proxy oraz inne podmioty.

Według informacji od Ukrtelecomu, leasing adresów IPv4 stał się sposobem na przetrwanie – leasing 1500 bloków /24 to miesięczny dochód rzędu 150 000 USD. Pozwala to utrzymać usługi i rozwijać infrastrukturę światłowodową.

Przykłady innych operatorów pokazują podobny trend:

• LVS (AS43310): rozdrobnienie adresów na kilkanaście światowych ASN, głównie AT&T.
• TVCOM (AS34092, AS57033): zniknięcie z routingu, przekazanie bloków 37 różnym ASN, w tym Microsoft (AS8075), AWS (AS16509), Deutsche Telekom (AS3320).
• Brokerzy IPv4 odgrywają kluczową rolę pośrednika i dystrybutora tych zasobów.

Regiony zajęte przez Rosję dokumentują wręcz „russifikację sieci”. Przykłady:

• Online Technologies LTD (AS45025, Donieck): Baza RIPE zmieniła atrybut ‘country’ z UA na RU. Adresy rozdysponowane do operatorów w Doniecku oraz globalnych telko.
• Byte-SD (AS42430, Ługańsk): Całkowite zniknięcie z routingu; bloki przejęły podmioty takie jak Paltel (Palestyna), AT&T, Sprint.
• Trinity (AS43554, Mariupol): Bloki przejął operator Sweet (UA), wcześniej wykorzystane m.in. przez AT&T do proxy rezydencyjnych.
• Interphone (AS24881, Mariupol): Bloki trafiły do lokalnych operatorów w tzw. Donieckiej Republice Ludowej, potem powróciły, ale z rosyjskim tranzytem.
• SkyNet (AS47598, Chersoń): Po zajęciu miasta przez Rosję, cała infrastruktura przekierowana przez Miranda Media (Krym), a potem po wycofaniu Rosji przekazanie adresów do nowych właścicieli, dziś wykorzystywane pod proxy.

Rosnąca liczba ukraińskich IPv4 wykorzystywana jest jako tzw. residential proxies. Pozwala to omijać zabezpieczenia geo-lokalizacyjne i zwiększa ryzyko nadużyć: spamu, fraudów, automatyzacji, web scrapingu.

Brokerzy IP, tacy jak IPXO i firmy hostingowe, stają się kluczowymi rozdzielaczami tych zasobów, nie zawsze dbając o reputację adresów.

Automatyzacja Palo Alto

GitHub - cdot65/paloaltonetworks-automation-examples: Consolidated repository for Palo Alto Networks automation examples using Python, Go, TypeScript, Bash, Terraform, Ansible.

Consolidated repository for Palo Alto Networks automation examples using Python, Go, TypeScript, Bash, Terraform, Ansible. - cdot65/paloaltonetworks-automation-examples

GitHubcdot65

Repozytorium zawiera przykłady automatyzacji dla produktów Palo Alto Networks, zrealizowane w różnych językach i narzędziach (Python, Go, TypeScript, Bash, Terraform, Ansible i inne). Możesz go wykorzystać jako punkt odniesienia przy wdrażaniu automatycznych zadań administracyjnych i integracji — np. rotacji haseł PAN-OS, konfiguracji BGP, zarządzania obiektami sieciowymi w Terraform czy przykładów użycia gNMI.

Dashboard do zarządzania SSL

GitHub - sieteunoseis/netSSL

Contribute to sieteunoseis/netSSL development by creating an account on GitHub.

GitHubsieteunoseis

NetSSL to webowy dashboard do zarządzania certyfikatami SSL w infrastrukturach klasowego przedsiębiorstwa. Umożliwia centralne operacje na certyfikatach dla różnych systemów — od ogólnych aplikacji po platformy Cisco VOS (CUCM, CUC, CER) oraz Cisco ISE — korzystając z ich interfejsów API lub SSH. Narzędzie automatyzuje generowanie CSR, pobieranie certyfikatów (w tym Let's Encrypt przez ACME), ich instalację oraz ponowne uruchamianie usług (SSH dla VOS, API dla ISE).

Jak Zbudować Sieć Spine-Leaf za Pomocą Ansible