Laboratorium bezpieczeństwa routingu międzydomenowego

1. Laboratorium bezpieczeństwa routingumiędzydomenowego Łukasz Dobrodziej, Jakub Maćkowiak Opiekun naukowy: mgr inż. Mariusz Mycek

2. Plan prezentacji • Cel pracy i motywacja • Wady BGP stanowiące zagrożenie bezpieczeństwa • Rodzaje ataków wykorzystujących wady BGP • Wymagania na zabezpieczenie protokołu BGP • Metody zabezpieczenia protokołu BGP • Podsumowanie • Bibliografia

3. Cel pracy i motywacja • Cel: • Przedstawienie zagrożeń • Rozbudowa bazy wiedzy o problemach zabezpieczeń protokołu BGP • Przedstawienie dobrych praktyk, jak można poradzić sobie z zagrożeniami • Przedstawienie kompleksowych propozycji rozwiązań problemu bezpieczeństwa BGP • Przeprowadzenie testowego laboratorium dot. bezpieczeństwa BGP z udziałem studentów na stworzonej platformie laboratoryjnej

4. Cel pracy i motywacja • Motywacja: • Rosnące wymagania odnośnie osiągalności w sieci Internet • Słabości BGP mają wpływ na globalny routing • Wady bezpieczeństwa BGP są powszechnie znane • Spammers / Crackers • Podatność na błędy konfiguracji (humanfactor) • Stosowane metody przegrywają próbę czasu

5. Wady BGP mogące powodować zagrożenie bezpieczeństwa • Brak pewności czy uczestnicy dialogu BGP rozgłaszają prefixy, których są właścicielami • Przesyłanie wiadomości BGP (TCP/IP), jak każda transmisja w publicznej sieci, może być obiektem ataku • Ingerencja w rozgłoszenia ścieżek i ich atrybuty mająca na celu obalenie polityk routingowych ISP

6. Rozgłaszanie niewłaściwych prefixów • Router może być skonfigurowany tak by rozgłaszać jakikolwiek prefix • Jeśli choć jeden router sąsiadujący (pod względem sesji BGP) nie odrzuci nieprawidłowych rozgłoszeń, dostępność prefixu przez wrogi AS może się łatwo propagować • Rozgłaszanie nieużytych przestrzeni adresowych (Bogon IP/Dark IP/Private IP) lub przynależnych do innych AS – PrefixHijacking • ‘Longestprefixmatch’ rule • Najczęstsze przypadki to błędy ludzi!

7. Rozgłaszanie niewłaściwych ścieżek • Router może być skonfigurowany tak by wysyłać nieprawidłowe rozgłoszenia • Zmodyfikowane atrybuty • korzystniejsze / gorsze – za ich pomocą można umiejętnie skierować ruch na ścieżkę oczekiwaną przez stronę atakującą. • Fakt – pathprepending– metoda ‘pogarszania’ parametrów ścieżki jest stosowana w codzienności.

8. Announcementtampering Path: 1, 2 Path: 1, 3, 100 AS 100 manipulując atrybutem AS_PATH może: - osiągnąć równą długość AS_PATHdla ścieżki przechodzącej przez niego (usunięcie AS 3) - osiągnąć krótsze AS_PATHjeśli usunie również AS 1 (fakt – routeaggregation zastosowany na AS 100 mógłby wywołać taki właśnie efekt (brak złych intencji – znaczne zmiany w routingu))

9. Przesyłanie wiadomości BGP Kanał komunikacji może stać się celem ataków • Poufność – brak obowiązku szyfrowania pakietów BGP – pozyskiwanie danych o ISP • Integralność (‘Man inthemiddle’) – brak obowiązku autoryzacji, brak hashowania: • wstrzykiwanie nieprawidłowych danych • wpływanie na decyzję wyboru ścieżki • dążenie do DoS routera • selektywne kasowanie wiadomości • odnawianie sesji BGP jest ‘kosztowne’ • częste zmiany rozgłaszanych ścieżek powodują do kompromitacji ich źródła

10. Przesyłanie wiadomości BGP • Integralność - ciąg dalszy: • modyfikowanie wiadomości • niespójna informacja routingowa (najlepsza ścieżka wyliczana lokalnie) • wpływanie na routing, możliwość tworzenia pętli, doprowadzanie do niekorzystnego wyboru ścieżek • atak powtórzeniowy • potencjalnie opiera się stosowaniu haseł • wpływanie na routing • doprowadzanie do routeflappingpoprzez powtarzanie wycofań ścieżek Man-in-the-middle może decydować o rozpływie ruchu!

11. Przesyłanie wiadomości BGP • Denial of Service (komunikacji BGP!) • wysyłanie TCP RST • resetowanie połączenia – routery są zmuszone ustanowić od nowa sesję BGP (wiąże się to zawsze z wysłaniem wszystkich rozgłoszeń) • wysyłanie TCP SYN (flooding) • niedokończone three-way-handshake zablokują możliwość nawiązania rzeczywistej sesji BGP • dążenie do osiągnięcie utworzenia BGP Wedgie • trwałe, nieprawidłowe stany sesji BGP wymagające ręcznej ingerencji administratorów [rfc4264]

12. Rodzaje ataków przy użyciu BGP • Denial of Service • Błędy w konfiguracji routera, luki w protokole/konfiguracji, ataki na router, przeciążanie łączy • Podsłuch • Wprowadzenie nieprawidłowych informacji w celu zmiany routingu danych użytkowych • Prefixhijacking • Rozgłaszanie nieprawidłowych prefixów (spammers) • ominięcie serwerów Real-time Blackhole List • utrudnienie wykrycia pochodzenia spamu

13. Przypadki awarii • Kwiecień 1997: AS 7007 ogłasza bezpośrednią ścieżkę do każdego prefixu w Internecie • Grudzień 1999: Adresy serwerów AT&T rozgłoszone przez innego ISP • Grudzień 2004: TTnet rozgłasza ponad 100k ścieżek • Wrzesień 2005: AT&T, XO, Bell Southprzekierowane do Boliwii • Styczeń 2006: Wiele sieci przekierowanych do operatora z Nowego Jorku Źródło: BGP Security, RIPE 52 Meeting, www.ripe.net/meetings

14. Przypadki awarii • Grudzień 2004: • 09:19 AS9121 (TTnet) rozgłasza ponad 100.000 ścieżek, • 09:19 AS6762 (Telecom Italia) przyjmuje rozgłoszenie (brak ograniczenia na max prefix) • Rozgłoszenia z AS6762 zapychają do max prefix wszystkich sąsiadów • 09:20 Błędne rozgłoszenia AS9121 przykrywają rozgłoszenia prawowitych właścicieli • 09:36 Największa wartość nieprawidłowych rozgłoszeń. ‘neighbormaximum-prefix’ - niewystarczające. Źródło: The Anatomy of a Leak: AS9121, www.renesys.com

15. Podsłuch - rodzaje

16. PrefixHijacking Router z AS 1 rozgłasza prefix 150.150.0.0/16 150.150.0.0/16

17. PrefixHijacking Router z AS 5 rozgłasza konkurencyjną ścieżkę dla tego prefixu. Ścieżka jest ‘lepsza’ w kategorii długości AS_PATH dla AS 4 i jednakowa dla AS 3 150.150.0.0/16

18. PrefixHijacking Router z AS 5 rozgłasza konkurencyjną ścieżkę dla prefixu o dłuższej masce adresu. Ścieżka jest ‘lepsza’ w kategorii ‘szczegółowość’ prefixu dla AS 2 włącznie ? 150.150.0.0/16

19. Wymagania na zabezpieczenie BGP • Zachowanie dotychczasowej skalowalności • Umiar w dodatkowym obciążeniu wydajnościowym routerów • Wsteczna kompatybilność • Ograniczone zaufanie między uczestnikami • Niechęć do dystrybucji informacji przez operatorów

20. Dobre praktyki - filtrowanie • Filtrowanie prefiksów z fałszywej przestrzeni adresowej (Bogon/Dark IP/Private IP Prefixes) • Filtrowanie rozgłoszeń zawierających prywatne ASN oraz długie AS_PATH • Filtrowanie małych podsieci (wstrzykiwanie statycznego routingu) • Nakładanie limitu na liczbę prefiksów, które może rozgłosić sąsiad • Filtrowanie przez ISP rozgłoszeń klientów (pod kątem ścieżek od innego dostawcy, ścieżek do sieci nieposiadanych przez klienta) • Nadpisywanie wartości atrybutów, które nie są używane (MED=0, filtrowanie ścieżek z nieznanymi COMMUNITY)

21. Zabezpieczenie Sesji pomiędzy peer’ami BGP • filtryruchu (Access Control Lists) Sekwencyjna lista instrukcji zezwoleń (permit) lub zakazów (deny), które są stosowane w odniesieniu do adresów lub protokołów wyższych warstw • Uwierzytelnianie MD5 • Wewnątrz TCP (dodatkowy nagłówek) • Weryfikacja, że dane urządzenie wysłało pakiet • Ustalenie i ręczna konfiguracja hasła

22. Zabezpieczenie Sesji pomiędzy peer’ami BGP Rys.1 Uwierzytelnienie MD5

23. Zabezpieczenie Sesji pomiędzy peer’ami BGP • BGP overIPSec (popularna metoda) • Definiuje metody szyfrowania i uwierzytelniania nagłówków i zawartości pakietów • Ochrona integralności i zabezpieczenie przed podsłuchem oraz podszywaniem się • Użycie IKE do zarządzania kluczami • TTL security mechanizm • TCP (używane przez BGP do transportu) umożliwia użycie każdego host’a w sieci do ataku • Ograniczenie z góry wartości TTL • Tylko routery z określonego zasięgu mogą wysyłać informacje

24. Zabezpieczenie Sesji pomiędzy peer’ami BGP Rys.2 TTL security mechanizm

25. Test ReversePathForward • Zabezpieczenie przed podszywaniem się host’ów pod używany w sieci adres IP (np. do ataku DoS) • Sprawdzanie adresu źródłowego przy użyciu lokalnej informacji routingowej „czy pakiet z danym adresem źródłowym  przyszedł na interfejs, przez który wiedzie ścieżka do tej sieci źródłowej” • Problem z przypadku wielu ścieżek (dual-homed)

26. Test ReversePathForward Rys. 3 Reversepathforward

27. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP- soBGP • Pozwala na: • walidacje pochodzenia informacji routingowej • ustalanie polityk odnośnie prefiksów przez sieć źródłową • walidacje istnienia co najmniej jeden ścieżki od źródła • Wykorzystuje : • bazę danych prawidłowych systemów autonomicznych i ich kluczy • bazę prefiksów powiązanych z systemem autonomicznym (źródłowym) • skierowany graf opisujący wszystkie znane prawidłowe ścieżki

28. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP- soBGP • Definiuje PKI do uwierzytelniania i autoryzacji organizacji, zarządza trzema rodzajami certyfikatów: • Entity cert – przypisanie klucza publicznego każdemu routerowi soBGP • Policy cert – opisuje połączenie do systemu autonomicznego (lokalna topologia) i polityki odnośnie prefiksów, które rozgłasza • Auth cert – zbiór systemów autonomicznych, które mają prawo, żeby rozgłaszać dane prefiksy

29. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP- soBGP • Lokalne topologie są wykorzystywane do stworzenia bazy z topologią globalną (statyczny graf sieci – problem z odświeżaniem) • Routery soBGP używają bazy z topologią sieci do walidacji otrzymanych ścieżek • Certyfikaty przenoszone są w nowym atrybucie SECURITY • Do sprawdzania certyfikatów oraz topologii wykorzystany jest mechanizm out-of-band

30. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP – S-BGP • Wykorzystuje podpis cyfrowego i powiązane z nim certyfikaty (infrastruktura klucza publicznego) • PKI przechowuje informacje o posiadanych prefiksach przez dane AS’y (IANA) • PKI wiąże AS’y z organizacjami a organizacje z routerami w ich sieci przez wydanie certyfikatów • Wszystkie informacje przekazane w ramach wiadomości BGP (posiadane prefiksy, ASN, wektor ścieżki) są podpisywane przez urządzenie, od którego pochodzą

31. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP – S-BGP • Świadectwa – podpisane wyrażenia użyte do zapewnienia autentyczności posiadania prefiksów i rozgłaszanych ścieżek • Świadectwa adresów – Potwierdza posiadanie danych prefiksów, podpisywane i rozpowszechniane out-of-band • Świadectwo tras – przenoszone w ramach S-BGP w nowym atrybucie zmodyfikowanej wiadomości UPDATE, świadectwo jest podpisywane przez każdy AS przy przekazaniu wiadomości (zagnieżdżenie) • weryfikacja czy AS’y były przemierzane w danej kolejności • czy żadne AS’y nie zostały dodane lub usunięte z rozgłoszenia

32. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP - S-BGP Rys. 4 Rozgłaszanie ścieżki (wiadomość UPDATE) przez S-BGP

33. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP – IRV • Rozwiązanie niezależne od protokołu routingowego • Każdy AS posiada serwer IRV • Serwer weryfikuje poprawność otrzymanych informacji routingowych poprzez sekwencję zapytań do innych serwerów IRV na ścieżce • Każdy serwer IRV zarządza informacjami tylko ze swojego macierzystego ASa

34. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP – IRV Rys. 5 Zapytanie IRV sprawdzające poprawność otrzymanych informacji routingowych

35. AS-SET

36. AS-SET • Zysk dla bezpieczeństwa: Dzięki AS-SET możemy nie tracić informacji o wszystkich AS na ścieżce (bez AS-SET blacklist mają ograniczoną wykrywalność niechcianych ścieżek) • Strata na skalowalności: Gdy używamy AS-SET zmiana choć jednego prefixu należącego do zagregowanej ścieżki powoduje konieczność przesłania kolejnego UPDATE

37. Dziękujemy