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 • Wprowadzenie – protokół BGP • Wady BGP stanowiące zagrożenie bezpieczeństwa • Rodzaje ataków wykorzystujących wady BGP • Metody zabezpieczenia protokołu BGP • Koncepcja laboratorium • Podsumowanie

3. Cel pracy i motywacja • Cel: • Rozszerzenie wiedzy dot. protokołu BGP o zagadnienia związane z jego bezpieczeństwem • Charakterystyka zagrożeń • Zebranie i przedstawienie dobrych praktyk, sposobów na ochronę przed zagrożeniami • Przeprowadzenie laboratorium dotyczącego 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)

5. Protokół BGP • Podstawowy protokół klasy EGP (ExteriorGatewayProtocol) • Wymiana informacji o dostępnych podsieciach między systemami autonomicznymi • Protokół typu path-vector • Oparty na regułach i parametrach administracyjnych

6. 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 • Ingerencja w rozgłoszenia ścieżek i ich atrybuty mająca na celu obalenie polityk routingowych ISP • Przesyłanie wiadomości BGP (TCP/IP), jak każda transmisja w publicznej sieci, może być obiektem ataku

7. 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

8. 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ą.

9. 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

10. 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ść – brak obowiązku autoryzacji, brak hashowania: • wstrzykiwanie nieprawidłowych danych • selektywne kasowanie wiadomości • modyfikowanie wiadomości • atak powtórzeniowy • Denial of Service (komunikacji BGP!) • wysyłanie TCP RST • wysyłanie TCP SYN (flooding)

11. 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

12. 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

13. 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

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

15. Awarie – 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

16. Awarie - 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

17. 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

18. 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

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

20. 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

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

22. 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)

23. Test ReversePathForward Rys. Reversepathforward

24. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP- soBGP • Pozwala na: • walidacje pochodzenia informacji routingowej • 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

25. 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 (PKI)

26. Zintegrowane rozwiązania problemu bezpieczeństwa protokołu BGP- soBGP Rys. Prosty graf zbudowany z lokalnych informacji o topologii

27. 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 (uwierzytelnienie samych urządzeń) • Wszystkie informacje przekazane w ramach wiadomości BGP (posiadane prefiksy, ASN, wektor ścieżki) są podpisywane przez urządzenie, od którego pochodzą

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

29. 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

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

31. Infrastruktura laboratorium

32. Widok podstawowy

33. Okno weryfikacji

34. Raport

35. Scenariusz laboratorium Rys. PrefixHijacking

36. Podsumowanie • Kontynuacja pracy inżynierskiej • Rozszerzenie wiedzy dot. protokołu BGP o zagadnienia związane z jego bezpieczeństwem • Przeprowadzenie laboratorium dotyczącego bezpieczeństwa BGP z udziałem studentów na stworzonej platformie laboratoryjnej • Wykorzystanie aplikacji do przeprowadzania i automatycznej oceny wykonania laboratorium

37. Dziękujemy