W nocy 17 lipca użytkownicy na całym świecie odnotowali, że popularne serwisy, takie jak Discord, Orange, Roblox, Steam, Santander, nie działają.

Hmmm https://t.co/vI9xvp3pyR jest… 'down' podobnie jak Discord i parę innych serwisów.

— Sekurak (@Sekurak) July 17, 2020

Wiadomo, że awaria tak wielu serwisów jednocześnie musi mieć wspólną przyczynę. Działanie Internetu to bardzo skomplikowane zagadnienie, ale dostęp do domen wymaga przede wszystkim wykorzystania protokołu DNS (Domain Name System). W przypadku braku skonfigurowanego DNS na urządzeniach klienckich (routery, czy w bezpośrednio w systemie operacyjnym) w celu połączenia się z domeną (np. sekurak.pl) konieczne byłoby wpisywanie za każdym razem jej adresu IP (przykładowo dla sekurak.pl to 51.77.40.125). Teoretycznie to też nie zawsze zadziała, bo wiele serwisów jest hostowanych na VPS-ach, więc jeden adres jest współdzielony przez innych klientów. Cloudflare jest popularnym dostawcą usługi DNS. Oferuje szeroki zakres możliwości (analiza ruchu, bezpłatny certyfikat SSL, firewall, cache czy ochronę przed atakami DDoS) co sprawia że, Cloudflare wybierają często ogromne serwisy.

Problemy nie trwały długo, bo 27 minut (według oficjalnej informacji). Przyczyna była dość trywialna, więc co się wydarzyło?

As there was backbone congestion in Atlanta, the team had decided to remove some of Atlanta’s backbone traffic. But instead of removing the Atlanta routes from the backbone, a one line change started leaking all BGP routes into the backbone.

Całość opisu na blogu CF wydaje się być całkiem sensowna, ponieważ dokładnie tłumaczy zachowanie routerów. Administratorzy ustawili local preference (drugi atrybut BGP, określający ścieżkę wyjściową dla systemu autonomicznego) na 200, gdzie domyślna wartość to 100. Routery podczas wyboru ścieżki wyjściowej zawsze biorą pod uwagę wyższą wartość, dlatego cały ruch, zamiast trafić do lokalnych węzłów, trafiał do Atlanty. Skutkowało to zwiększonym obciążeniem procesora:

Podsumowanie:

Sam protokół BGP jest dość problematyczny i domyślnie mało bezpieczny, ponieważ charakteryzuje się zasadą: „każdy ufa każdemu”. Brak dostępu do niektórych usług jest mało znaczący w porównaniu do przechwytywania ruchu. Nieszyfrowany protokół HTTP wciąż jest używany na wielu stronach, więc przechwycenie takiej komunikacji pozwoli odczytać przesyłane dane bez większych problemów. Podobnie jest z innymi nieszyfrowanymi protokołami, takimi jak telnet (zapewnia dostęp do terminalu zdalnego systemu, prekursor szyfrowanego SSH) czy FTP (służy do przesyłania plików na serwer). Rozwiązaniem jest zastosowanie RPKI, który wdraża się po stronie ISP. Na stronie isbgpsafeyet.com możliwe jest sprawdzenie, czy nasz dostawca internetu już to zrobił, znajduje się tam również także porównanie ISP pierwszego poziomu (przydziela zakresy adresów IP do wykorzystania dla “mniejszych”, lokalnych operatorów).

— Michał Giza