POLITECHNIKA WARSZAWSKA. Wydział Elektroniki i Technik Informacyjnych. Instytut Telekomunikacji PRACA DYPLOMOWA MAGISTERSKA

Transkrypt

1 POLITECHNIKA WARSZAWSKA Wydział Elektroniki i Technik Informacyjnych Instytut Telekomunikacji PRACA DYPLOMOWA MAGISTERSKA Łukasz Dobrodziej, Jakub Maćkowiak LABORATORIUM ROUTINGU MIĘDZYDOMENOWEGO BEZPIECZEŃSTWO PROTOKOŁU BGP Kierujący pracą dyplomową: mgr inż. Mariusz Mycek Opiekun naukowy: doc. dr inż. Michał Jarociński ocena pracy data i podpis Przewodniczącego Komisji Egzaminacyjnej Warszawa, czerwiec 2012

2

3 LABORATORY OF THE INTER-DOMAIN ROUTING BGP SECURITY Abstract The aim of this work is to analyse the security vulnerabilities of the Border Gateway Protocol (BGP) including detailed description of various kinds of attacks and methods of protection. A set of best practices in BGP routers configuration is proposed, enhancing network security against both misconfiguration and premeditated attacks. A practical part of this work is laboratory scenario concerning BGP security. Within the framework of previously developed Bachelor s thesis, [22], the preliminary version of laboratory infrastructure for inter-domain routing has been proposed. The infrastructure consists of the selected router emulator and an application, which main purpose is assistance in router configuration, automatic verification and evaluation of performed exercises. In order to extend flexibility of the application, the infrastructure has been reorganised (see appendix E) and new functionalities has been implemented. Due to the experience of conducting multiple laboratory exercises with students, the scenario has been significantly improved and enhanced. Using developed application and laboratory scenarios during practical experiments with students, improves the general understanding of the inter-domain routing and explaining methods of implementing traffic engineering rules to routers. In addition, the use of Simple Network Management Protocol (SNMP) and Management Information Base (MIB) is enabled in the application, which constitute a valuable extension of laboratory concerns. In general, the appliance of router emulator allow to conduct exercises with minimum effort and cost. In the introduction, the concept and structure of the Internet network is presented. In the following chapter, the purpose of usage of BGP in this network is discussed, and its main characteristics are introduced: the attributes of UPDATE messages are described in details; examples of traffic engineering in inter-domain routing are presented. Then, the issues related with security vulnerabilities of BGP, which can affect the inter-domain routing are analysed. Possible types of attacks exploiting BGP vulnerabilities are presented as well. Next, the available solutions to improve security of BGP are discussed (e.g., session security enhancement between neighbouring routers, common methods of BGP message filtering, and usage of the integrated security systems). Finally, the concepts of laboratories are presented including a description of the experiments and infrastructure required to conduct them. The integral part of this work consists of annexes with extended documentation of laboratory elements: a capabilities and operation instructions for selected router emulator; two laboratory instructions; an application manual and a report containing a list of performed changes in the new version of application. Keywords: BGP, laboratory, security

4

5 LABORATORIUM ROUTINGU MIĘDZYDOMENOWEGO BEZPIECZEŃSTWO PROTOKOŁU BGP Streszczenie Celem niniejszej pracy było przeprowadzanie analizy podatności protokołu BGP (ang. Border Gateway Protocol) na ataki, przedstawienie typów ataków oraz metod zabezpieczania się przed nimi. W szczególności autorzy chcieli zebrać i przedstawić zbiór dobrych praktyk wykorzystywanych przez administratorów systemów autonomicznych i dostawców ISP, których powszechne użycie może znacznie zwiększyć odporność sieci na awarie wywołane błędną konfiguracją lub atakiem. Praktycznym uzupełnieniem w/w zagadnień jest stworzone ćwiczenie laboratoryjne dotyczące bezpieczeństwa protokołu BGP. W ramach pracy inżynierskiej autorów (patrz [22]) powstała wstępna wersja infrastruktury laboratorium routingu międzydomenowego. Infrastruktura składa się z emulatora routerów oraz aplikacji do przeprowadzania ćwiczeń laboratoryjnych. W celu realizacji nowego ćwiczenia niezbędne było rozbudowanie oraz uelastycznienie aplikacji. Wzbogacono ją o funkcje umożliwiające realizację różnorodnych scenariuszy dotyczących routingu międzydomenowego. Dodatkowym celem niniejszej pracy było przeorganizowanie oraz zwiększenie efektywności aplikacji (patrz załącznik E). Wykorzystane w trakcie pracy inżynierskiej ćwiczenia laboratoryjne zostały uporządkowane i ujednolicone w oparciu o wielokrotnie przeprowadzone laboratoria z udziałem studentów. Aplikacja wraz ze stworzonymi ćwiczeniami może zostać wykorzystana w ramach laboratorium z przedmiotów prowadzonych w Instytucie Telekomunikacji. Ćwiczenia wykonywane z użyciem programu, umożliwiają studentom praktyczne poznanie mechanizmów związanymi z routingiem międzydomenowym, jak również z metodami implementowania tych mechanizmów w routerach. Ponadto, aplikacja zawiera funkcje, które pozwalają urozmaicić ćwiczenie i rozszerzyć jego zakres o praktyczne wykorzystanie protokołu SNMP i bazy informacji zarządzania (MIB). Zaproponowany emulator routerów pozwala na zorganizowanie laboratoriów przy minimalnym nakładzie środków i czasu. W rozdziale pierwszym opisano strukturę i organizację sieci Internet. Rozdział drugi poświęcony jest protokołowi BGP zawiera opis atrybutów wiadomości UPDATE oraz zasad ich wykorzystania w sterowaniu rozpływem ruchu międzydomenowego. Rozdział trzeci zawiera analizę wad protokołu BGP, które mogą stanowić zagrożenie bezpieczeństwa routingu międzydomenowego. Natomiast rozdział czwarty przedstawia metody ataku na routing międzydomenowy wykorzystujące opisane wcześniej luki bezpieczeństwa. W rozdziale piątym opisano dostępne rozwiązania problemu bezpieczeństwa protokołu BGP obejmują one metody zabezpieczenia sesji pomiędzy sąsiadującymi routerami, powszechne zasady filtrowania rozgłoszeń BGP oraz zintegrowane systemy zapewnienia bezpieczeństwa protokołu BGP. Rozdział szósty przedstawia koncepcję laboratorium zawiera opis przygotowanych ćwiczeń oraz infrastruktury do ich przeprowadzania. Integralną częścią niniejszej pracy jest zestaw załączników przygotowanych w czasie prac nad laboratorium i programem raport dotyczący możliwości i obsługi wybranego emulatora routerów, instrukcje do dwóch ćwiczeń laboratoryjnych oraz instrukcje obsługi aplikacji (dla użytkownika końcowego oraz administratora). Słowa kluczowe: bezpieczeństwo, BGP, laboratorium

6

7 Życiorys Łukasz Dobrodziej Urodziłem się 24 grudnia 1987 roku w Warszawie. W latach uczęszczałem do XCIV Liceum Ogólnokształcącego im. gen. Stanisława Maczka w Warszawie do klasy o profilu matematyczno - informatycznym. W roku 2006 rozpocząłem studia dzienne na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej na Makrokierunku. Wybrana przeze mnie specjalność to Teleinformatyka i Zarządzanie w Telekomunikacji. W roku 2010 ukończyłem studia inżynierskie z oceną celującą i uzyskałem tytuł inżyniera telekomunikacji.

8

9 Życiorys Jakub Maćkowiak Urodziłem się 25 czerwca 1987 roku w Koszalinie. Po ukończeniu szkoły podstawowej i gimnazjalnej, kontynuowałem naukę w I Liceum Ogólnokształcącym im. Stanisława Dubois w Koszalinie w klasie o profilu matematyczno - informatycznym. W roku 2006 rozpocząłem studia dzienne na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej na kierunku Makrokierunek. Wybrana przeze mnie specjalność to Teleinformatyka i Zarządzanie w Telekomunikacji. W roku 2010 uzyskałem tytuł inżyniera telekomunikacji.

10

11 Autorzy skadają podziękowania Panu mgr inż. Mariuszowi Myckowi za nieocenioną pomoc w trakcie pisania niniejszej pracy.

12

13 Spis treści Spis rysunków 17 Wykaz skrótów 21 Wstęp (ŁD) 23 1 Sieć Internet (JM) Rozwój Internetu Struktura sieci Internet Adresacja w sieci Internet, numeracja ASN Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego (ŁD) Wprowadzenie Sesja BGP Przebieg sesji Rodzaje sesji Atrybuty wiadomości UPDATE Atrybut Next Hop Atrybut As Path Atrybut Origin Atrybut Local Pref Atrybut Atomic Aggregate Atrybut Aggregator Atrybut Community Atrybut Multi Exit Disc Proces wyboru najlepszej ścieżki Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa (JM) Wstęp Akceptowanie nieautoryzowanych prefiksów

14 Spis treści Reguła longest prefix match Przesyłanie nieautoryzowanego prefiksu NLRI Akceptowanie nieautoryzowanych ścieżek / atrybutów ścieżek Ingerencja w kanał komunikacji wiadomości BGP Ataki na poufność komunikacji BGP Ataki na integralność komunikacji BGP Ataki DoS (ang. DoS denial of service attacks) komunikacji BGP Podsumowanie Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP (JM) Wstęp Rodzaje ataków Przejęcie prefiksu Rozgłaszanie ścieżek dla zarezerwowanych przestrzeni adresowych Rozgłaszanie ścieżek dla nieprzydzielonych przestrzeni adresowych Modyfikowanie tras ruchu użytkowego Atak powodujący niestabilność ścieżek Atak wywołujący BGP Wedgie Ryzyko deagregacji prefiksów Ryzyko rozgłoszenia bezpośredniej ścieżki do wielu adresów w sieci Internet Podsumowanie Rozwiązania problemu bezpieczeństwa protokołu BGP (ŁD) Wprowadzenie Zabezpieczenie sesji Uwierzytelnianie MD Uogólniony mechanizm bezpieczeństwa TTL Test Reverse path forward IpSec

15 5.2.5 Porównanie metod zwiększających bezpieczeństwo sesji protokołu BGP Filtrowanie rozgłoszeń protokołu BGP Zasady filtrowania rozgłoszeń BGP Rejestry routingu Zintegrowane systemy bezpieczeństwa protokołu BGP S-BGP sobgp IRV Porównanie metod Koncepcja laboratoriów (JM/ŁD) Ćwiczenia laboratoryjne (ŁD) Opis aplikacji (JM) Architektura rozwiązania Założenia projektowe Funkcjonalność aplikacji Propozycje rozwoju środowiska laboratoryjnego Podsumowanie (ŁD) 103 Literatura 105 Załączniki (JM/ŁD) 109 A Narzędzia Dynagen, Dynamips opis funkcjonalności (ŁD) B Instrukcja do ćwiczenia sterowanie ruchem (ŁD) C Instrukcja do ćwiczenia bezpieczeństwo protokołu BGP (ŁD) D Instrukcja obsługi aplikacji (JM) E Raport dotyczący przeprowadzonych zmian w aplikacji (JM/ŁD) F Środowisko laboratoryjne podręcznik administratora (JM) (ŁD) Łukasz Dobrodziej; (JM) Jakub Maćkowiak

16

17 Spis rysunków 1.1 Hierarchia systemów AS sieci Internet Liczba przydzielonych numerów ASN Sesja ebgp Sesja ibgp Podział atrybutów BGP Atrybut Next Hop Atrybut As Path As Path prepending As Path wykrywanie pętli Polecenie As Set Atrybut Local Pref Atrybut Community Atrybut Multi Exit Disc Rozgłaszanie nieprawidłowego prefiksu Modyfikacja NLRI w przekazywanej wiadomości UPDATE Fabrykacja UPDATE z nieprawidłowym NLRI Schemat ataku typu TCP Reset Schemat ataku typu SYN flooding Atak typu przejęcie prefiksu Wykorzystanie ataku prefix hijacking Powstawanie ruchu backscatter Przebieg czasowy przejęcia bogon adresów w celu wysyłki spamu BGP Dampening, wykres BGP Wedgie, routing zgodny z oczekiwaniami AS BGP Wedgie, stabilny stan routingu niezgodny z oczekiwaniami AS Uogólniony mechanizm bezpieczeństwa TTL przykład Reverse path forward przykład

18 Spis rysunków 5.3 Porównanie metod zwiększających bezpieczeństwo sesji protokołu BGP Fragment raportu CIDR z dnia Rozgłaszanie ścieżki przy wykorzystaniu mechanizmu S-BGP Graf protokołu sobgp Zapytanie IRV sprawdzające poprawność informacji routingowej Porównanie zintegrowanych systemów bezpieczeństwa protokołu BGP Uproszczona architektura środowiska laboratoryjnego B.1 Topologia sieci B.2 Tabela interfejsów B.3 Tabela bgppeertable B.4 Tabela bgp4pathattrtable C.1 Topologia sieci C.2 Tabela interfejsów C.3 Tabela bgppeertable dla routera R C.4 Tabela bgp4pathattrtable dla routera R C.5 Widok aplikacji z przeprowadzonego ćwiczenia C.6 Tabela bgp4pathattrtable dla routera R3 po zastosowaniu filtrowania D.1 Okno początkowe wprowadzanie informacji na temat Grupy Laboratoryjnej134 D.2 Widok podstawowy D.3 Widok po odświeżeniu D.4 Wykonywanie zapytań SNMP D.5 Wykonywanie Get Table po SNMP D.6 Funkcja Traceroute D.7 Okno oceniania D.8 Okno oceniania (niepowodzenie) D.9 Raport z laboratorium E.1 Diagram klas E.2 Interfejs graficzny aplikacji E.3 Plik wejściowy aplikacji w formacie XML

19 F.1 Architektura rozwiązania F.2 Instalacja adaptera loopback F.3 Zainstalowana karta sieciowa loopback F.4 Pobieranie adresu loopback F.5 Plik wejściowy aplikacji w formacie XML

20

21 Wykaz skrótów APNIC Asia Pacific Network Information Centre ARIN American Registry for Internet Numbers ARPA Advanced Research Projects Agency AS Autonomous System ASN Autonomous System Number ASN.1 Abstract Syntax Notation One BGP Border Gateway Protocol CIDR Classless Inter-Domain Routing CLI Command Line Interface DNS Domain Name System DOS Denial of Service DSUA Documenting Special Use IPv4 Address Blocks ebgp exterior BGP EGP Exterior Gateway Protocol FIB Forwarding Information Base GTSM Generalized TTL Security Mechanizm IANA Internet Assigned Numbers Authority ibgp interior BGP IGP Interior Gateway Protocol IKE Internet Key Exchange IP Internet Protocol IPSec IP Security IRV Interdomain Route Validation ISP Internet Service Provider ITU-T International Telecommunication Union - Telecommunication Standardization Sector LACNIC Latin America and Caribbean Network Information Centre MD5 Message-Digest algorithm 5 MED Multi-Exit Discriminator MIB Management Information Base MiTM Man-in-the-middle MPLS Multiprotocol Label Switching NAT Network Address Translation NLRI Network Layer Reachablity Information OS Operations System OSI Open System Interconnection OSPF Open Shortest Path First PDU Protocol Data Unit PKI Public Key Infrastructure QoS Quality of Service RBL Realtime Black List RFC Request for Comments RIB Routing Information Base RIPE Réseaux IP Européens RIR Regional Internet Registry 21

22 RPF S-BGP SLA SNMP sobgp TCP TLS TTL VPN UDP Reverse Path Forward Secure Border Gateway Protocol Service Level Agreements Simple Network Management Protocol secure origin Border Gateway Protocol Transmission Control Protocol Transport Layer Security Time To Live Virtual Private Network User Datagram Protocol 22

23 Wstęp Internet (ang. inter między, net sieć) to globalna sieć komputerowa, oparta na protokole IP (ang. Internet Protocol). Sieć ta ma charakter zdecentralizowany składa się z administrowanych niezależnie sieci (systemów autonomicznych), z których każda działa według własnych, wewnętrznie określonych zasad. Pakiety w sieci Internet kierowane są przez routery do podsieci docelowej na podstawie informacji zawartych w tabelach FIB (ang. Fowarding Information Base). Prawidłowe działanie sieci wymaga, aby zawartość tabel FIB wszystkich routerów na drodze pakietu była spójna. Za zapewnienie takiej spójności we wszystkich routerach domeny routingowej odpowiedzialny jest routing. Routing może być realizowany w płaszczyźnie zarządzania (routing statyczny) lub w płaszczyźnie sterowania (routing dynamiczny). Routing dynamiczny realizowany jest przez urządzenia komunikujące się przy wykorzystaniu protokołu routingowego. Za pomocą protokołu BGP (ang. Border Gateway Protocol) realizowany jest routing na poziomie międzydomenowym w sieci Internet. Protokół został zaprojektowany w roku 1989 kiedy bezpieczeństwo sieci Internet nie było brane pod uwagę. Najnowsza, czwarta wersja protokołu BGP-4, której specyfikacja powstała w styczniu 2006 roku, również nie definiuje wbudowanych mechanizmów zapewniających bezpieczeństwo. W konsekwencji protokół BGP jest wrażliwy na błędy konfiguracyjne administratorów oraz świadome ataki stron trzecich. Ze względu na globalny zasięg protokołu skutki awarii lub przeprowadzonego ataku mogą wpłynąć na działanie dużej części sieci. Zwiększenie bezpieczeństwa protokołu BGP stanowi obecnie duże wyzwanie i jest niezbędne w celu zapewnienia stabilności i poprawności globalnego routingu międzydomenowego. Studenci w ramach przedmiotów prowadzonych w Instytucie Telekomunikacji poznają podstawowe cechy i zastosowanie protokołu BGP. Złożoność mechanizmów i konfiguracji protokołu wymaga jednak styczności z nim w rzeczywistym środowisku sieciowym. Aby umożliwić studentom praktyczne wykorzystanie wiedzy zdobytej podczas wykładów oraz głębsze zapoznanie się z wybranymi zagadnieniami związanymi z routingiem międzydomenowym, powstał pomysł realizacji laboratoriów. W ramach pracy magisterskiej Wykorzystanie mechanizmów protokołu BGP do kształtowania rozpływu ruchu międzydomenowego (patrz [21]) prowadzonej w Instytucie 23

24 Telekomunikacji powstał zestaw trzech scenariuszy laboratoryjnych dotyczących konfigurowania protokołu BGP oraz wykorzystania go w sterowaniu rozpływem ruchu międzydomenowego. W celu realizacji laboratorium należało przygotować środowisko, które umożliwiłoby przeprowadzenie ćwiczeń. W ramach pracy inżynierskiej autorzy niniejszej pracy stworzyli wstępną wersję infrastruktury, która umożliwiła przeprowadzenie z udziałem studentów wybranego ćwiczenia testowego ( Multihoming z wykorzystaniem łączy do jednego ISP ). Infrastruktura laboratorium składa się z emulatora routerów oraz aplikacji, której podstawowym zadaniem jest ułatwienie konfigurowania oraz automatyczna weryfikacja i ocena wykonanych ćwiczeń laboratoryjnych. Podczas dalszych prac nad laboratorium planowano rozbudowę aplikacji oraz przygotowanie nowych scenariuszy. Cel pracy Celem niniejszej pracy było przeprowadzanie analizy podatności protokołu BGP na ataki, przedstawienie typów ataków oraz metod zabezpieczania się przed nimi. W szczególności autorzy chcieli zebrać i przedstawić zbiór dobrych praktyk wykorzystywanych przez administratorów systemów autonomicznych i dostawców ISP, których powszechne użycie może znacznie zwiększyć odporność sieci na awarie wywołane błędną konfiguracją lub atakiem. Praktycznym uzupełnieniem w/w zagadnień jest stworzone ćwiczenie laboratoryjne dotyczące bezpieczeństwa protokołu BGP, które umożliwi studentom zapoznanie się z wybranymi zagrożeniami routingu międzydomenowego oraz mechanizmami zabezpieczenia się przed atakami. W celu realizacji nowego ćwiczenia niezbędne było rozbudowanie oraz uelastycznienie istniejącej infrastruktury laboratorium. Dotychczasowa wersja aplikacji do przeprowadzenia ćwiczeń była dostosowana do ćwiczenia testowego. W ramach pracy wzbogacono ją o funkcje umożliwiające realizację różnorodnych scenariuszy dotyczących routingu międzydomenowego. Dodatkowym celem niniejszej pracy było przeorganizowanie oraz zwiększenie efektywności aplikacji (patrz załącznik E). Wykorzystane w trakcie pracy inżynierskiej ćwiczenia laboratoryjne zostały uporządkowane i ujednolicone w oparciu o wielokrotnie przeprowadzone laboratoria z udziałem studentów. Aplikacja wraz ze stworzonymi ćwiczeniami może zostać wykorzystana w ramach laboratorium z przedmiotów prowadzonych w Instytucie Telekomunikacji. Ćwiczenia wykonywane z użyciem programu, umożliwią studentom głębsze poznanie wybranych mechanizmów związanymi z routingiem międzydomenowym, jak również z metodami im- 24

25 plementowania tych mechanizmów w routerach. Ponadto aplikacja zawiera funkcje, które pozwalają urozmaicić ćwiczenie i rozszerzyć jego zakres o praktyczne wykorzystanie protokołu SNMP i bazy informacji zarządzania (MIB). Zaproponowany emulator routerów pozwala na zorganizowanie laboratoriów przy minimalnym nakładzie środków i czasu. Układ pracy W rozdziale pierwszym opisano strukturę i organizację sieci Internet. Rozdział drugi poświęcony jest protokołowi BGP zawiera opis atrybutów wiadomości UPDATE oraz ich zasad wykorzystania w sterowaniu rozpływem ruchu międzydomenowego. Rozdział trzeci zawiera analizę wad protokołu BGP, które mogą stanowić zagrożenie bezpieczeństwa routingu międzydomenowego natomiast rozdział czwarty przedstawia metody ataku na routing międzydomenowy wykorzystujące opisane wcześniej podatności. W rozdziale piątym opisano dostępne rozwiązania problemu bezpieczeństwa protokołu BGP obejmują one metody zabezpieczenia sesji pomiędzy sąsiadującymi routerami, najbardziej powszechne zasady filtrowania rozgłoszeń BGP oraz zintegrowane systemy zapewnienia bezpieczeństwa protokołu BGP. Rozdział szósty przedstawia koncepcję laboratorium zawiera opis przygotowanych ćwiczeń oraz infrastruktury do ich przeprowadzania. Integralną częścią niniejszej pracy jest zestaw załączników przygotowanych w czasie prac nad laboratorium i programem raport dotyczący możliwości i obsługi wybranego emulatora routerów, instrukcje do dwóch ćwiczeń laboratoryjnych oraz instrukcje obsługi aplikacji (dla użytkownika końcowego oraz administratora).

26

27 1 Sieć Internet 1.1 Rozwój Internetu Upowszechnienie się sieci Internet zrewolucjonizowało światowy system komunikacji. Możliwość niemal natychmiastowej wymiany danych między dowolnymi komputerami na świecie, łatwy dostęp do informacji, możliwość wpływania na zawarte w sieci treści sprawiają, że popularność sieci Internet jest w pełni zrozumiała. Sieć Internet jest zdecentralizowanym zbiorem niezależnych administracyjnie obszarów systemów autonomicznych AS (ang. Autonomous System). System autonomiczny to sieć lub grupa sieci z jednolitymi zasadami routingu, zarządzana przez jeden podmiot. Administratorzy systemu autonomicznego samodzielnie dbają o zapewnienie routingu wewnątrzdomenowego stosują jeden lub wiele protokołów routingu wewnątrzdomenowego klasy IGP (ang. Interior Gateway Protocol). Aby zapewnić globalną dostępność podsieci należy umożliwić wymianę informacji o trasach pomiędzy różnymi systemami AS. Wykorzystuje się do tego protokoły routingu międzydomenowego klasy EGP (ang. Exterior Gateway Protocol). Standardowo, we współczesnym Internecie wykorzystywany jest w tym celu protokół BGP (ang. Border Gateway Protocol). 1.2 Struktura sieci Internet Systemy autonomiczne tworzą w Internecie strukturę hierarchiczną (patrz rys. 1.1), w której poszczególne systemy autonomiczne należą do różnych poziomów (ang. tiers) sieci i pełnią w związku z tym różne role. Sieci na szczycie hierarchii (należące do Tier 1 ), definiuje się jako te, które mają dostęp do każdej podsieci w Internecie bez konieczności świadczenia opłat za przesyłanie pakietów. Sieci tego poziomu (ich liczba nie przekracza w chwili obecnej 15) są między sobą połączone (każda z każdą) w relacji typu peer-to-peer. Systemy autonomiczne Tier 1 stanowią szkielet Internetu. Międzynarodowe firmy utrzymujące te sieci świadczą usługi tranzytowania ruchu operatorom niższego poziomu hierarchii lub klientom biznesowym mającym duże wymagania odnośnie jakości połączenia. 27

28 1 Sieć Internet Następny poziom hierarchii (Tier 2 ) złożony jest z sieci tranzytowych będących klientami jednego lub wielu operatorów Tier 1. Utrzymują one relacje typu peer-to-peer z innymi operatorami tego samego poziomu (najczęściej pomiędzy operatorami bliskimi pod względem geograficznym, pomiędzy którymi wymieniane są znaczne ilości ruchu). Przykładem takich sieci są duże sieci operatorów krajowych. Najmniejsze wymieniane w tym podziale sieci, należą do poziomu Tier 3. Charakteryzują się one tym, że są sieciami tranzytowymi, korzystającymi z usług jednego lub więcej operatorów poziomu Tier 2. Zazwyczaj są to regionalni dostawcy Internetu. Systemy autonomiczne, które nie tranzytują ruchu (nie przesyłają ruchu pomiędzy innymi systemami AS), nazywane są stub. Cały ruch, który przekazują pochodzi od/do klientów tej sieci. W zależności od tego czy ich połączenie z siecią Internet jest świadczone odpowiednio przez jednen lub więcej ISP, wyróżniamy dwa rodzaje systemów autonomicznych typu stub: single-homed stub i multihomed stub, Rys. 1.1 Hierarchia systemów AS sieci Internet 28

29 Różnorodność możliwych relacji między systemami autonomicznymi, ilość wymienianej informacji routingowej, wymóg minimalnego czasu powrotu sieci do sprawności po wystąpieniu awarii wszystko to sprawia, że zagadnienia związane z routingiem międzydomenowym są zagadnieniami ciekawymi a ich rozwój (w tym rozwój protokołu BGP) jest podstawą istnienia sieci Internet. 1.3 Adresacja w sieci Internet, numeracja ASN Podstawą działania sieci Internet jest jednolita adresacja hostów. Obecnie, wykorzystywana jest adresacja zgodna z protokołem IP w wersji 4. Adresy IPv4 to 32 bitowe liczby, przedstawiane najczęściej w postaci czterech oktetów, zapisanych dziesiętnie i oddzielanych znakiem kropki. Liczba adresów określona w standardzie IPv4 (2 32 ), pomniejszona o adresy zarezerwowane np. dla użytku w sieciach prywatnych lub dla adresów multicast, okazała się niewystarczająca dla rozwijającej się sieci Internet. Wersja 6. protokołu IP wprowadza znacznie większą przestrzeń adresową (128 bitów), jednak nie znajduje się ona jeszcze w powszechnym użytku. Aby umożliwić efektywniejsze wykorzystanie adresów IPv4 stosuje się mechanizmy translacji adresów NAT (ang. Network Address Translation) i wprowadza bezklasowy routing międzydomenowy CIDR (ang. Classless Inter-Domain Routing). Podobne problemy z wielkością przestrzeni adresowej pojawiają się na poziomie routingu międzydomenowego. Numery systemów autonomicznych ASN (ang. Autonomous System Numbers) były początkowo 16-bitowymi liczbami. Gwałtowny wzrost zapotrzebowania na te numery (patrz Rys. 2.2) okazał się być poważniejszym zagrożeniem niż problem wyczerpujących się adresów IP. Głównym powodem jest brak możliwości przeniesienia mechanizmów stworzonych na potrzeby adresów IP na grunt numeracji systemów autonomicznych. W rezultacie takiego stanu rzeczy w roku 2007 organizacja odpowiedzialna za przydzielanie adresów IP, numerów ASN, nazw domen DNS i innych zasobów związanych z protokołami Internetowymi IANA (ang. Internet Assigned Numbers Authority), poszerzyła przestrzeń numeracji ASN do 32 bitów. Format zapisu numerów ASN składa się obecnie z dwóch 16-bitowych liczb zapisanych dziesiętnie, oddzielonych znakiem kropki (x.y), przy czym stosowane wcześniej numery 16-bitowe odzwierciedlane są przez zapis (0.y). 29

30 Rys. 1.2 Liczba przydzielonych numerów ASN

31 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego 2.1 Wprowadzenie Protokół BGP (ang. Border Gateway Protocol) jest podstawowym protokołem routingu międzydomenowego w sieci Internet. Umożliwia wymianę informacji o dostępnych podsieciach miedzy systemami autonomicznymi. Protokół BGP jest protokołem typu path-vector oznacza to, że wiadomości routingowe przenoszą listę numerów systemów autonomicznych, przez które będą przechodzić pakiety do rozgłaszanej podsieci. Przy pomocy protokołu BGP można sterować rozpływem ruchu międzydomenowego. Routery BGP wymieniają informacje o dostępnych ścieżkach. Gdy istnieje kilka ścieżek do jednej podsieci docelowej, do wyboru najlepszej z nich stosują reguły i parametry administracyjne (tzw. atrybuty). W procesie wyboru najlepszej ścieżki nie uwzględnia się stanu łączy aktualnego obciążenia, opóźnień transmisji danych oraz strat pakietów. Protokół BGP pozwala na agregację informacji o rozgłaszanych ścieżkach. Dzięki temu między sąsiednimi systemami autonomicznymi wymieniane są jedynie informacje o ścieżkach zagregowanych. Zmniejszana jest w ten sposób liczba wysyłanych rozgłoszeń. 2.2 Sesja BGP Sąsiadujące routery BGP po skonfigurowaniu przez administratora ustanawiają między sobą sesje BGP w celu wymiany wiadomości routingowych. Sesja wykorzystuje stałe, niezawodne połączenie TCP (port 179) Przebieg sesji W celu nawiązania sesji BGP routery wysyłają wiadomość OPEN. Zawarte są w niej podstawowe informacje potrzebne do określenia sąsiedztwa (numer wersji protokołu, numer ASN, identyfikator BGP routera, liczniki i parametry opcjonalne). Po ustanowieniu sesji, routery BGP przekazują sobie informacje routingowe w wiadomościach UPDATE. Pierwsza wiadomość UPDATE zawiera całą tablicę BGP, kolejne przenoszą informacje o dodawanych bądź usuwanych ścieżkach i związanych z nimi parametrach. Wiadomość 31

32 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego UPDATE składa się z dwóch opcjonalnych bloków: blok NLRI (ang. Network Layer Reachability Information), który przenosi listę dostępnych podsieci wraz a atrybutami prowadzących do nich ścieżek; blok WITHDRAW, który przenosi informacje o ścieżkach do podsieci, które należy wycofać. W celu utrzymania sesji BGP, gdy nie zachodzą wymiany informacji routingowych, routery wysyłają wiadomość KEEPALIVE. W ten sposób sygnalizują, że sesja jest wciąż aktywna. Wiadomości KEEPALIVE wysyłane są domyślnie co 60 sekund. Do zakończenia sesji BGP służy wiadomość NOTIFICATION. Wysyłana jest w celu powiadomienia o wystąpieniu błędu związanego z sesją BGP (nieznane pole wiadomości OPEN, upłynięcie określonego czasu od ostatniej wiadomości KEEPALIVE lub UPDATE). Wiadomość NOTIFICATION powoduje zerwanie sesji BGP. Po zakończeniu sesji BGP zostaje również zerwane połączenie TCP Rodzaje sesji Istnieją dwa rodzaje sesji BGP. Routery należące do dwóch różnych systemów autonomicznych nawiązują sesję zewnętrzną ebgp (ang. exterior BGP). Za ich pośrednictwem wprowadzane są rozgłoszenia o podsieciach dostępnych w innych systemach autonomicznych (patrz Rys. 2.1). Rys. 2.1 Sesja ebgp Routery BGP należące do jednego systemu autonomicznego muszą utrzymywać spójną informacje o ścieżkach do podsieci w innych systemach autonomicznych. W tym 32

33 celu routery te ustanawiają sesje wewnętrzne ibgp (ang. interior BGP) przy czym każdy router danego systemu autonomicznego powinien utrzymywać sesję ibgp z każdym innym routerem tego systemu (patrz Rys. 2.2). W przypadku dużych sieci, w celu ograniczenia liczby sesji ibgp stosuje się mechanizmy route-reflector lub confederation. Rys. 2.2 Sesja ibgp 2.3 Atrybuty wiadomości UPDATE Routery BGP przy wyborze najlepszej ścieżki wykorzystują parametry administracyjne, nazywane atrybutami. Atrybuty są związane z konkretną ścieżką i są przesyłane razem z informacją o tej ścieżce w wiadomości UPDATE. Wyróżnia się następujące typy atrybutów wiadomości UPDATE: well-known mandatory atrybuty, które muszą być rozpoznawane przez wszystkie implementacje protokołu (well-known) oraz muszą towarzyszyć każdej ogłaszanej ścieżce (mandatory); well-known discretionary atrybuty, które są rozpoznawane przez wszystkie implementacje protokołu, ale nie muszą być przesyłane razem z ogłaszaną ścieżką (discretionary); optional transitive atrybuty, które nie muszą być rozpoznawane przez implementację (optional), ale jeżeli towarzyszą ogłaszanej ścieżce są wraz z nią przekazywane do innych routerów; 33

34 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego optional non-transitive atrybuty, które nie muszą być rozpoznawane przez implementację, ani też przekazane do innych routerów (non-transitive). W tabeli na Rys. 2.3 przedstawiono atrybuty protokołu BGP podzielone na wymienione kategorie: well-known well-known optional transitive optional nontransitive mandatory discretionary Next Hop Local Pref Aggregator Multi Exit Disc As Path Atomic Aggregate Community Origin Rys. 2.3 Podział atrybutów BGP Atrybut Next Hop Atrybut Next Hop zawiera informacje o adresie IP interfejsu kolejnego routera na drodze do sieci docelowej. W zależności od pochodzenia ścieżki, atrybut ma różne znaczenie (patrz Rys. 2.4). Rys. 2.4 Atrybut Next Hop Jeżeli ścieżka została rozgłoszona w sesji ibgp i podsieć docelowa pochodzi z wnętrza systemu autonomicznego, atrybut Next Hop jest adresem routera, który tę podsieć rozgłosił (na Rys. 2.4 router A rozgłasza podsieć /24). Każdy router wewnątrz tego samego systemu autonomicznego (router B na Rys. 2.4) zmienia wartość atrybutu Next Hop na adres swojego interfejsu. 34

35 W przypadku ścieżek rozgłoszonych w sesjach ebgp, atrybut Next Hop wskazuje urządzenie, które przekazuje informacje o ścieżce do danego systemu autonomicznego. Informacja ta w stanie niezmienionym jest przekazywana do wnętrza systemu AS z wykorzystaniem protokołu ibgp, dzięki czemu wszystkie routery systemu autonomicznego otrzymują informację o tym samym routerze Next Hop. Na Rys wartością atrybutu Next Hop dla routera D jest interfejs routera C, który przekazał rozgłoszenie do systemu autonomicznego. Następnie router D przesyła rozgłoszenie do routera E, nie zmieniając wartości atrybutu Next Hop Atrybut As Path Wartością atrybutu As Path jest lista numerów ASN systemów autonomicznych, przez które będą przechodzić pakiety do danej podsieci. W przypadku agregacji ścieżek, fragment wartości atrybutu As Path może zawierać nieuporządkowany zbiór numerów ASN systemów autonomicznych, przez które przebiegają ścieżki (As Set). Gdy router brzegowy (źródłowy lub kolejne) rozgłasza podsieć do sąsiedniego systemu autonomicznego, wówczas dodaje numer własnego systemu autonomicznego na liście As Path. Rys. 2.5 Atrybut As Path Sposób tworzenia wartości atrybutu As Path ilustruje Rys System autonomiczny AS 10 rozgłasza podsieć /16 sąsiednim routerom a jego router brze- 1 Aby było możliwe wysyłanie ruchu do podsieci w innym systemie autonomicznym należy, oprócz ustalenia wartości Next Hop, zapewnić jego dostępność (np. za pomocą wewnątrzdomenowego protokołu routingu lub niestandardowego mechanizmu Cisco next-hop-self ). 35

36 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego gowy umieszcza numer ASN systemu autonomicznego w wartości atrybutu As Path. Kolejne systemy autonomiczne przekazują rozgłoszenie, również dokładając własne numery ASN. Atrybut As Path może być wykorzystywany do wyboru najlepszej ścieżki prowadzącej do danej podsieci. Dla przykładu rozgłoszenia o podsieci /16 dotrą do AS 1000 z dwóch różnych źródeł (przez AS 20 i AS 300). Ze względu na krótszą wartość atrybutu As Path, ruch do sieci /16 będzie kierowany przez AS 20. Atrybut As Path wpływa na wybór najlepszej ścieżki. Z tego względu można posłużyć się nim do kształtowania rozpływu ruchu. Jednym ze mechanizmów, który to umożliwia jest As Path prepending, który polega na sztucznym wydłużaniu drogi do podsieci poprzez wielokrotne dodanie numeru ASN do atrybutu As Path, co obniża atrakcyjność ścieżki. Rys. 2.6 As Path prepending Mechanizm As Path prepending przedstawiony jest na Rys System AS 10 umieścił własny numer ASN trzykrotnie na liście As Path w rozgłoszeniu podsieci do systemu AS 20. Pogorszył w ten sposób atrakcyjność ścieżki prowadzącej przez system AS 20 i wpłynął na rozpływ ruchu przychodzącego. Ruch z systemu AS 1000 do podsieci /16 będzie kierowany ścieżką prowadzącą przez systemy AS 200 i AS 300, ze względu na krótszą ścieżkę As Path. Atrybut As Path pozwala na wykrywanie pętli w drogach jeśli router BGP odczyta w sekwencji numer własnego systemu autonomicznego, stwierdza wystąpienie pętli 36

37 i odrzuca ogłoszenie. Rys. 2.7 As Path wykrywanie pętli Protokół BGP przewiduje możliwość agregacji prefiksów, czyli łączenia wielu prefiksów w jeden i rozgłaszanie go za pomocą jednej wiadomości UPDATE. W celu zapewnienia ochrony przed tworzeniem pętli dla ścieżek zagregowanych, router agregujący prefiksy może zastosować polecenie As Set. Spowoduje to dopisanie zbioru ASN ze wszystkich As Path ścieżek agregowanych i dołączenie ich do rozgłoszenia wyjściowego. Mimo utraty uporządkowania As Path (As Set jest zbiorem numerów ASN, nie ich wektorem), sam fakt znajomości numerów ASN pozwala algorytmowi BGP wyeliminować ścieżki, które powodowałyby pętle routingu. Kiedy administrator zarządzający routerem agregującym ścieżki jest w stanie zapewnić brak możliwości powstania pętli, może zrezygnować z przypisywania do rozgłoszeń As Set. Daje to bezpośrednią korzyść wynikającą z braku konieczności rozgłoszenia wiadomości UPDATE informującej o zmianie w ścieżce zagregowanej w przypadku zmiany As Path jakiejkolwiek ścieżki składowej. Działanie polecenia As Set jest przedstawione na rys

38 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego Rys. 2.8 Polecenie As Set Atrybut Origin Atrybut Origin informuje o sposobie pozyskania danych o ścieżce przez router wprowadzający rozgłoszenie do sieci. Może przyjmować jedną z poniższych wartości: IGP ścieżka pochodzi z protokołu routingu wewnątrzdomenowego (redystrybucja ścieżki z IGP (ang. Interior Gateway Protocols) do EGP (ang. Exterior Gateway Protocol)) EGP ścieżka pochodzi z protokołu EGP (z innego systemu autonomicznego) INCOMPLETE inne źródło informacji, np. ścieżka statyczna Atrybut Local Pref Atrybut Local Pref (ang. Local Preference) służy do określenia preferowanej ścieżki wyjściowej z danego systemu autonomicznego do podsieci w innym systemie autonomicznym. Gdy router BGP otrzyma rozgłoszenie o ścieżce do podsieci w sesji ebgp przypisuje jej wartość Local Pref. Ścieżka ta może być następnie rozgłoszona do wnętrza systemu autonomicznego (w sesji ibgp). Gdy router wewnątrz systemu autonomicznego otrzyma kilka ścieżek prowadzących do tej samej podsieci, wybierze tę z największą wartością atrybutu Local Pref. 38

39 Rys. 2.9 Atrybut Local Pref Rys. 2.9 przedstawia wykorzystanie atrybutu Local Pref. Routery brzegowe systemu autonomicznego AS 100 otrzymały rozgłoszenia o podsieci /24 z dwóch różnych źródeł przez łącze A-D oraz B-D. Router brzegowy A przypisał rozgłoszeniu, które otrzymał od sąsiedniego routera D wartość Local Pref równą 150. Router B pozostawił dla otrzymanego rozgłoszenia od routera D wartość domyślną równa 100. Informacja o podsieci /24 dotrze przez routery brzegowe do routera C. W tablicy routingu zapisze on najlepszą ścieżkę do podsieci /24 w tym wypadku będzie to ścieżka o większej wartości Local Pref. W rezultacie cały ruch z AS 100 do podsieci /24 będzie kierowany przez łącze A-D a ścieżka prowadząca przez łącze B-D będzie wykorzystywana jedynie w przypadku wystąpienia awarii na ścieżce podstawowej. Podobnie routery A i B wybiorą ścieżkę z największą wartością atrybutu Local Pref Atrybut Atomic Aggregate Router BGP może łączyć kilka adresów podsieci w celu zmniejszenia liczby rozgłoszeń przekazywanych do innego urządzenia. Działanie takie powoduje utratę informacji ponieważ rozgłoszenia wchodzące w skład ścieżki zagregowanej mają różne źródła i atrybuty. Z tego względu router agregujący ścieżki powinien dołączyć atrybut Atomic Aggregate, który wskazuje, że część informacji została usunięta Atrybut Aggregator Atrybut Aggregator wskazuje router, który dokonał agregacji adresów. Jest on wstawiany przez urządzenia agregujące ścieżki i zawiera identyfikator ASN oraz identyfikator routera 39

40 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego Router-ID (najwyższy adres IP interfejsu loopback, lub najwyższy adres IP interfejsu fizycznego) Atrybut Community Atrybut Community pozwala na znakowanie ścieżek. Jest wartością ustawianą przez administratora, na podstawie której można zmieniać wartości pozostałych atrybutów ścieżek (sterować ruchem), filtrować ruch, przypisywać reguły routingowe. Atrybut Community pozwala też określić czy rozgłoszenie można przekazać do innych systemów autonomicznych czy należy je ograniczyć do własnego systemu AS. Atrybut Community może mieć więcej niż jedną wartość. Router, który odbierze rozgłoszenie o dostępności podsieci z takim atrybutem ma możliwość jego modyfikacji lub dodania kolejnej wartości i przekazania do sąsiadów BGP. Istnieją powszechnie znane wartości atrybutu Community. Ich interpretacja jest następująca: NO ADVERTISE rozgłoszenie nie może być przekazywane do żadnego innego routera BGP NO EXPORT rozgłoszenie nie może być przekazywane do innego systemu AS (do sąsiedniego routera ebgp) INTERNET rozgłoszenie ma być przekazane do sieci Internet (oznacza brak ograniczeń dotyczących obszaru rozgłaszania). Administratorzy współpracujących systemów mogą definiować własne wartości atrybutu Community 1. Wykorzystywanie własnych wartości wymaga współpracy między administratorami sąsiednich systemów autonomicznych muszą oni ustalić jak na daną wartość zareagować Nowy format opisany w [2] oraz [3] definiuje Community jako dwie dwubajtowe liczby w formacie AA:NN. Pierwsze dwa bajty to numer ASN systemu autonomicznego a następna dwa to numer Community zdefiniowany przez administratora.

41 Rys Atrybut Community Rys przedstawia zastosowanie atrybutu Community do wysterowania ruchu przychodzącego do sieci. Administratorzy systemów 100 i 200 ustalili znaczenie wartości, przy pomocy których AS 200 oznacza rozgłoszenia. AS 100 na wartość atrybutu Community 200:150 zareaguje zmianą wartości atrybutu Local Pref na 150 dla otrzymanej ścieżki, natomiast dla wartości 200:100 ustawi wartość domyślną atrybutu Local Pref równą 100. Dzięki temu AS 200 może zdalnie wysterować ruch wchodzący z AS 100 do jego podsieci /0/24 (ruch będzie kierowany łączem A-D a ścieżka prowadząca przez łącze B-D będzie stanowiła ścieżkę zapasową) Atrybut Multi Exit Disc Atrybut Multi Exit Disc (ang. Multiple Exit Discriminatory) służy do wskazywania sąsiedniemu systemowi autonomicznemu, która droga wejściowa do danego systemu AS jest preferowana. Atrybut Multi Exit Disc jest typu non-transitive przesyłany jest między sąsiednimi systemami autonomicznymi. Atrybut Multi Exit Disc można wykorzystać do wysterowania ruchu wchodzącego do systemu autonomicznego wystarczy rozgłosić podsieć na dwóch łączach wejściowych z różnymi wartościami tego atrybutu. Ścieżka z mniejszą wartością Multi Exit Disc jest preferowana. 41

42 2 Zasady wykorzystywania protokołu BGP do sterowania rozpływem ruchu międzydomenowego Rys Atrybut Multi Exit Disc Rys ilustruje zastosowanie atrybutu Multi Exit Disc. Podsieć /24 zostaje rozgłoszona na dwóch ścieżkach z dwoma różnymi wartościami atrybutu Multi Exit Disc router brzegowy A rozgłosił podsieć z Multi Exit Disc równym 20 na łączu A-D, natomiast router brzegowy B rozgłosił tą samą podsieć na łączu B-D z Multi Exit Disc równym 50. W ten sposób została zaznaczona preferowana ścieżka wejściowa do AS 100 oraz ścieżka zapasowa. W okresie normalnej pracy sieci cały ruch przychodzący do podsieci /24 z AS 200 będzie kierowany łączem A-D, ponieważ rozgłoszenie pochodzącego z tego łącza miało mniejszą wartość atrybutu Multi Exit Disc. W przypadku awarii na tej ścieżce ruch zostanie przekierowany na ścieżkę prowadzącą przez łące B-D (ścieżka z mniejszą wartością atrybutu Multi Exit Disc). 2.4 Proces wyboru najlepszej ścieżki Router BGP dąży do wybrania tylko jednej, najlepszej ścieżki prowadzącej do wybranej podsieci. Gdy otrzyma kilka ścieżek do tej samej podsieci musi zdecydować, którą z nich umieścić w tablicy routingu. Standardowy proces decyzyjny jest sekwencją kilkunastu kroków i jest zależny od producenta routera. Poniżej przedstawiona jest procedura dla routerów Cisco: 1. Sprawdzana jest dostępność kolejnego routera na ścieżce (atrybut Next Hop). Zgodnie z domyślnym działaniem protokołu BGP, podczas wymiany informacji o ścieżkach z wykorzystaniem protokołu ibgp, routery nie modyfikują atrybutu Next Hop. Istnieje zatem możliwość odebrania informacji o ścieżce, dla której kolejny router 42

43 jest nieosiągalny. Takie ścieżki nie są wpisywane do tablic routingu, są jednak utrzymywane w bazie danych ścieżek BGP. 2. Wybierana jest ścieżka odebrana z łącza o najwyższej wartości parametru administracyjnego Weight. Jest to parametr lokalny routera, charakterystyczny jedynie dla urządzeń Cisco. Domyślna wartość współczynnika wynosi 0. Ścieżki lokalne otrzymują współczynnik o wartości Porównywana jest wartość atrybutu Local Pref. Wartość domyślna to 100. Preferowana jest ścieżka o najwyższej wartości atrybutu. 4. Wybierana jest ścieżka o najkrótszej wartości atrybutu As Path. 5. Sprawdzana jest wartość atrybutu Origin w pierwszej kolejności wybierane są ścieżki IGP, następnie EGP i na końcu INCOMPLETE. 6. Porównana jest wartość atrybutu Multi Exit Disc i wybrana ścieżka z najmniejszą wartością tego atrybutu. Parametr Multi Exit Disc jest wykorzystywany jedynie w przypadku odebrania dwóch ścieżek do tej samej podsieci z jednego sąsiedniego systemu autonomicznego (ze względu na nieprzechodniość). 7. W pierwszej kolejności wybierane są ścieżki ebgp, następnie ibgp. Takie rozwiązanie eliminuje ryzyko powstawania pętli i wyznacza ścieżkę prowadzącą bezpośrednio poza system autonomiczny. Ścieżki wewnętrzne rozsyłane przez routery danego systemu AS są rozpatrywane w kroku piątym procedury. Ten test obejmuje więc jedynie ścieżki do sieci zewnętrznej. 8. Wybierana jest ścieżka, która ma najmniejszą metrykę używanego protokołu wewnątrzdomenowego do kolejnego routera (Next Hop). 9. Jeśli ścieżki są identyczne, preferowana jest ścieżka pochodząca od routera o najwyższej wartości Router-ID 1. Jest to krok rozstrzygający. 1 Najwyższy adres IP interfejsu loopback, lub najwyższy adres IP interfejsu fizycznego

44

45 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa 3.1 Wstęp W płaszczyźnie transportowej (ang. data plane) sieci telekomunikacyjnej z komutacją pakietów działają urządzenia odpowiedzialne za przekazywanie pakietów do kolejnych węzłów na podstawie ich adresu docelowego. Urządzenia te przechowują w tabelach reguły kierowania pakietów (ang. forwarding tables lub FIB ang. Forwarding Information Base). Proces decydowania o zawartości FIB (routing) odbywa się w płaszczyźnie sterowania (ang. control plane), bądź płaszczyźnie zarządzania (ang. management plane). W praktyce, płaszczyzna sterowania jest realizowana za pomocą zbioru routerów, mających za zadanie zapewnić w danym obszarze osiągalność podsieci (ang. reachability). Wyznaczone przez nie trasy powinny prowadzić do możliwie najbardziej efektywnego kierowania ruchu. Routery stosują wybrany algorytm decydowania o trasach kierowania pakietów. Informacja, na której bazują wymieniana jest za pomocą wiadomości protokołu routingowego. Za pomocą protokołu BGP (ang. Border Gateway Protocol) realizowany jest routing na poziomie międzydomenowym w sieci Internet. Protokół został zaprojektowany w roku 1989 kiedy bezpieczeństwo sieci Internet nie było brane pod uwagę. Najnowsza, czwarta wersja protokołu BGP-4, której specyfikacja powstała w styczniu 2006 roku, również nie definiuje wbudowanych mechanizmów pozwalających zabezpieczyć sesję przed atakami modyfikującymi, usuwającymi, wytwarzającymi nieprawidłowe lub powtórzeniowe dane (zob. rozdział 5.2). W konsekwencji BGP jest wrażliwy na błędy konfiguracyjne personelu administratorów oraz świadome ataki osób trzecich. Z racji jego roli jako podstawowego protokołu, na którym opiera się działanie sieci Internet, luki w zabezpieczeniach protokołu BGP mogą stać się przyczyną destabilizacji globalnego routingu międzydomenowego. Podstawowymi wadami BGP, na których istnieniu można oprzeć atak na routing międzydomenowy są: 45

46 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa Akceptowanie nieautoryzowanych prefiksów Akceptowanie nieautoryzowanych ścieżek / atrybutów ścieżek Ingerencja w kanał komunikacji wiadomości BGP Słowo nieautoryzowane należy rozumieć jako nieuzasadnione topologią sieci, powstające wyłącznie poprzez manipulację urządzeniami uczestniczącymi w routingu BGP. W poniższych rozdziałach szczegółowo przedstawione zostaną wymienione podatności protokołu BGP. 3.2 Akceptowanie nieautoryzowanych prefiksów System autonomiczny może wprowadzić do systemu routingowego informację o dostępności podsieci. Realizowane jest to poprzez wysłanie wiadomości UPDATE informującej o tej podsieci do wszystkich partnerów BGP (BGP peer), z którymi routery mają ustanowione sesje BGP. Router BGP (BGP Speaker) powinien rozgłaszać wyłącznie te pule adresów IP, których fizyczne połączenie z siecią Internet jest zrealizowane poprzez jego system autonomiczny. Założenie to nie jest jednak w żaden sposób weryfikowane mechanizmami BGP w przypadku gdy router zaakceptuje nieprawidłowe rozgłoszenie, a algorytm protokołu BGP uzna tę ścieżkę za najlepszą, ruch zaadresowany do hostów z rozgłaszanej podsieci trafi w niewłaściwe miejsce. Jedynym, wbudowanym w architekturę BGP sposobem odrzucenia nieprawidłowego rozgłoszenia jest jawne zablokowanie podanego prefiksu pochodzącego od danego partnera BGP poprzez konfigurację list zezwoleń (ang. permit list). Istnieją czynniki, które czynią tę wadę jeszcze groźniejszą. Pierwszą z nich jest rozproszone zaufanie routingu BGP. W sytuacji, gdy choć jeden router zaakceptuje nieprawidłowe rozgłoszenie, zostanie ono przekazane do wszystkich jego sąsiadów. Utrudnia to proces tworzenia list niedozwolonych prefiksów, gdyż trzeba zabezpieczyć się przed nieprawidłowymi rozgłoszeniami przychodzącymi również od zaufanych i nie mających złych intencji sąsiadów. W rezultacie niewielka luka w zabezpieczeniach jednego AS może wywołać propagację błędnej konfiguracji na dużą skalę. Drugim problemem, który uwydatnia podatność wynikającą z możliwości rozgłaszania dowolnych prefiksów jest fakt, że sesja BGP nie jest wystarczająco dobrze chroniona. 46

47 Istnieje możliwość podszycia się pod uprawnionego uczestnika routingu BGP. Wówczas strona atakująca wykorzystuje reputację strony, pod którą się podszywa aby uwiarygodnić nieprawidłowe rozgłoszenia (zwiększyć szansę na to, że wysłane rozgłoszenie nie ulegnie odrzuceniu z powodu zablokowania go w permit list sąsiadów). Celem działania polegającego na rozgłoszeniu nieprawidłowego prefiksu może być przejęcie istniejących adresów IP (atak o nazwie prefix hijacking, zob ). Cel ten jest osiągnięty gdy podzbiór routerów BGP w sieci uzna nieprawidłowe rozgłoszenie i zgodnie z nimi zmieni reguły kierowania pakietów w bazie FIB. Sposobem na zwiększenie zasięgu tego efektu (zwiększenie liczby routerów które uznają nieprawidłowe rozgłoszenie za właściwe) jest deagregacja prefiksów. Po podziale prefiksu początkowego na wiele składowych prefiksy o dłuższej masce i rozgłoszeniu każdego z nich zasięg przejęcia będzie prawdopodobnie większy Reguła longest prefix match Reguła longest prefix match, która powoduje efekt zwiększonego zasięgu przejęcia, jest zwyczajowo implementowaną zasadą routingu IP. W przypadku istnienia równoważnych pod względem pozostałych metryk ścieżek preferuje się tę, która posiada najdłuższą maskę, jako najdokładniejszą pasującą do adresu danego pakietu. Algorytm decyzyjny BGP pozwala na wprowadzenie do FIB ścieżek, których prefiksy posiadają część wspólną (zakresy adresów IP nachodzą na siebie). Przykładowo, gdy router BGP otrzyma następujące rozgłoszenia (częścią wspólną będą adresy od do ): Network Next Hop Metric LocPrf Weight Path *> / i *> / i Symbole * i > poprzedzające informacje o obu ścieżkach oznaczają, odpowiednio, że router uznał trasy za poprawne i najlepsze. W związku z tym do tabeli FIB wprowadzone zostaną następujące reguły kierowania pakietów: /8 is variably subnetted, 2 subnets, 2 masks 47

48 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa B /8 [20/0] via , 00:00:36 B /9 [20/0] via , 00:00:412 Router po otrzymaniu pakietu z adresem docelowym zastosuje się do reguły 1 ponieważ adres pasuje wyłącznie do niej. Po otrzymaniu pakietu z adresem docelowym zastosuje się do reguły 2 ponieważ jest ona dokładniejsza w kontekście longest prefix match rule (mimo że adres jest zgodny również z prefiksem w regule 1) Przesyłanie nieautoryzowanego prefiksu NLRI Informacje o prefiksie, którego dotyczy dana wiadomość UPDATE, zawiera atrybut NLRI (ang. Network Layer Reachablity Information). Atrybut NLRI składa się z dwóch wartości: długości LENGTH prefiksu zapisanej w notacji CIDR (zob. rozdział 1.3) i prefiksu adresów PREFIX. W ramach pojedynczej wiadomości UPDATE wysyłane jest jedno lub wiele NLRI. Wiele NLRI może zostać wysłane wyłącznie w sytuacji gdy pokrywają się wszystkie wartości atrybutów ścieżki. Manipulowanie danymi przesyłanymi w NLRI pozwala osiągnąć podobny efekt jak opisywany w podrozdziale 3.2, z tą różnicą, że jest realizowane na etapie przekazywania rozgłoszenia. BGP nie gwarantuje, że router nie wprowadzi zmian w NLRI przekazywanego rozgłoszenia. Co więcej administrator routera BGP może przypisać rozgłoszenie dowolnemu AS, wysyłając sfabrykowaną wiadomość UPDATE z odpowiednio skonstruowanym AS PATH. Ten AS nie jest świadomy faktu, że w sieć została wprowadzona ścieżka do dowolnego prefiksu prowadząca do jego systemu autonomicznego. Na poniższych rysunkach zobrazowano różnicę pomiędzy rozgłaszaniem nieprawidłowego prefiksu (Rys. 3.1), modyfikacją atrybutu NLRI w przekazywanym UPDATE (Rys. 3.2) i fabrykowaniem wiadomości UPDATE dla dowolnego atrybutu NLRI (Rys. 3.3). 48

49 Rys. 3.1 Rozgłaszanie nieprawidłowego prefiksu Rys. 3.2 Modyfikacja NLRI w przekazywanej wiadomości UPDATE Rys. 3.3 Fabrykacja UPDATE z nieprawidłowym NLRI 3.3 Akceptowanie nieautoryzowanych ścieżek / atrybutów ścieżek Routery uczestniczące w sesji BGP dystrybuują między sobą informacje o poznanych ścieżkach. Podobnie jak w przypadku akceptowania nieautoryzowanych prefiksów, protokół BGP nie dostarcza mechanizmów potwierdzania wiarygodności odbieranych wiadomości UPDATE przenoszących informację o ścieżkach, jak również przypisanych im atrybutów BGP. Możliwość fabrykacji nieautoryzowanych rozgłoszeń, a także możliwość przydzielania dowolnych wartości atrybutów BGP stanowi kolejną poważną lukę w bezpieczeństwie protokołu BGP. 49

50 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa Atrybuty BGP mają szerokie zastosowanie w kształtowaniu rozpływu ruchu w sieci, stąd manipulacja nimi może prowadzić do poważnych skutków. Routing na poziomie międzydomenowym wykracza znacznie ponad zapewnianie osiągalności hostów w sieci. Operatorzy systemów autonomicznych są zobowiązani spełniać narzucone im warunki przekazywania ruchu. Często są one sformułowane w postaci umów gwarancji jakości usług (ang. Service Level Agreements SLA). W przypadku routingu międzydomenowego są to nie tylko wymagania dotyczące jakości usługi QoS (ang. Quality of Service) takich jak szybkość transmisji, opóźnienie, zmienność opóźnienia. Na te parametry BGP ma tylko pośredni wpływ wybór nieefektywnej ścieżki może pogorszyć wspomniane parametry. Wymagania biznesowe, które realizować ma BGP mogą obejmować szczegółowe wymagania co do sposobu kierowania ruchu. Wymagania dotyczące kierowania ruchu między sąsiednimi AS mogą definiować ustalone punkty wymiany ruchu, wybrane spośród wielu routerów brzegowych znajdujących się na styku systemów autonomicznych. Wymagania te mogą przewidywać bardzo zróżnicowane scenariusze zachowań dla sytuacji awaryjnych. Za pomocą mechanizmów BGP można również realizować różne warianty współpracy sieci tranzytowych i w modelu dostawca klient. Za pomocą BGP administratorzy są w stanie dostosowywać routing tak aby odwzorował pożądane ramy współpracy między organizacjami. Do implementacji tych zasad kierowania ruchu w sieci Internet służą atrybuty rozgłoszeń BGP. Rozważmy jaki negatywny wpływ na stabilność routingu międzydomenowego może mieć ingerencja w każdy z atrybutów BGP. flagi atrybutu, kod typu atrybutu, długość atrybutu Format atrybutów ścieżki w wiadomości UPDATE jest ściśle określony. Każdy typ atrybutu posiada unikalny kod (ang. attribute type code). Przykładowo, atrybut ORIGIN ma przyznany kod 1, ścieżka w rozumieniu przebytych AS (AS PATH) kod 2. Ponadto, flagi atrybutu (ang. attribute flags) określają dla każdego atrybutu czy jest on: opcjonalny (ang. optional) przechodni (ang. transitive) częściowy (ang. partial) o zwiększonej długości (ang. extended length) 50

51 Wartości te nie są właściwymi, przenoszącymi informacje składnikami wiadomości UPDATE. Dostarczają one danych, na podstawie których router jest w stanie poprawnie zinterpretować otrzymaną wiadomość protokołu BGP. Modyfikacje, które wprowadzą niespójność danych przenoszonych w wiadomości spowodują uznanie jej za niepoprawną. W takiej sytuacji BGP speaker przeprowadza procedurę zamknięcia połączenia. W rezultacie, modyfikacja omawianych atrybutów w taki sposób by były one niezgodne ze specyfikacją jest jednym ze sposobów destabilizowania sesji BGP. ORIGIN Atrybut ORIGIN informuje sąsiada BGP o pochodzeniu ścieżki. Pochodzenie ścieżki jest kryterium w piątym kroku procesu wyboru najlepszej ścieżki. Poprzez modyfikację tego atrybutu istnieje zatem możliwość wpłynięcia na wybór przepisanej do RIB routera trasy. AS PATH Rozważona zostanie kolejno ingerencja polegająca na zmianie długości atrybutu AS PATH i jego zawartości. Długość atrybutu AS PATH jest rozumiana jako liczba zawartych w nich numerów systemów autonomicznych ASN. Długość atrybutu AS PATH stanowi kryterium w czwartym kroku decydowania o wyborze najlepszej ścieżki. Zmiany tego atrybutu mają realny wpływ na wybór spośród ścieżek posiadających równe (w tym również domyślne) wartości LO- CAL PREF. Zwiększenie długości tego atrybutu jest stosowaną praktyką w normalnej pracy sieci nazywaną path prepending. Wydłużenie ścieżki może posłużyć również do tego by znacząco pogorszyć realizację połączeń w sieci poprzez wybór dłuższych i mniej efektywnych z punktu widzenia inżynierii ruchowej (ang. traffic engineering) połączeń. Problem natury technicznej stanowią ścieżki o nadzwyczaj długich AS PATH. Niektóre implementacje routerów BGP reagują w nieprawidłowy sposób na takie rozgłoszenia, czego efektem może być awaria systemu operacyjnego routera lub nieprawidłowa obsługa sesji BGP skutkująca niestabilnością wyboru ścieżki (ang. route flapping) 1. 1 Przykładowo, firma Cisco po zidentyfikowaniu problemu zbyt długich ścieżek zdecydowała się na wprowadzenie polecenia ograniczającego maksymalną długość tego atrybutu bgp maxas limit 51

52 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa Działanie przeciwne, polegające na sztucznym zmniejszaniu długości atrybutu AS PATH także pozwala wymuszać złe w skutkach decyzje routingowe. Co gorsza, wiąże się to z usunięciem podzbioru AS po których przebiega ścieżka. W rezultacie czego atrybut AS PATH jako mechanizm mający chronić algorytm decyzji protokołu BGP przed tworzeniem pętli routingowych nie jest w stanie spełniać swojej roli. Zmiana wartości numerów ASN w atrybucie AS PATH lub ich fabrykacja jest sposobem obejścia mechanizmu list zezwoleń (ang. permit list). Umożliwiają one blokowanie ścieżek przechodzących przez określony system autonomiczny AS. Poprzez usunięcie niepożądanego AS z wektora AS PATH, strona wprowadzająca złośliwe dane jest w stanie uwiarygodnić to rozgłoszenie i zwiększyć szanse na wywołanie zmiany routingu ruchu użytkowego. Odwrotne działanie polegające na wstawieniu do AS PATH niepożądanego AS może służyć zmniejszeniu prawdopodobieństwa wyboru tej ścieżki przez sąsiadów i tym samym stanowi kolejny sposób wymuszania zmian routingu, a w skrajnym przypadku może spowodować nieosiągalność hostów z przestrzeni adresowej związanej z tym NLRI. Originating Routes Wykorzystanie tego atrybutu jest równoznaczne z rozgłoszeniem podanych w nim NLRI jako adresów podsieci, do których istnieje bezpośrednia droga z danego AS (przypadek rozważany szczegółowo w rozdziale 3.2). NEXT HOP Poprzez modyfikację atrybutu NEXT HOP można doprowadzić do nieprawidłowego przekazywania pakietów (ang. forwarding) dla zmodyfikowanej ścieżki, powodując w ten sposób niedostępność hostów o adresach zgodnych z rozgłaszanym prefiksem. Innym działaniem może być przekazanie w atrybucie NEXT HOP adresu który jest osiągalny z routera, któremu wysyłamy rozgłoszenie, ale nie jest właściwym dla tego rozgłoszenia. W ten sposób istnieje możliwość skierowania ruchu do niewłaściwych miejsc w sieci. MULTI EXIT DISC Atrybut MED (MULTI EXIT DISC) jest atrybutem nieprzechodnim (ang. non transitive). Modyfikacje tego atrybutu mogą wpływać na routing wewnątrzdomenowy a także zmodyfikować drogi wchodzenia ruchu z sąsiadujących AS. z racji 52

53 niepropagowania tego atrybutu poza sąsiedni system autonomiczny, jego modyfikacja nie propaguje się globalnie. Jednak lokalne zmiany w wyborze ścieżek mają pośrednio wpływ na routing w większym obszarze sieci. LOCAL PREF Podobnie jak w przypadku atrybutu MED, atrybut LOCAL PREF jest typu non transitive. Zasięg wywołanych zmian ma wpływu wyłącznie na zmiany routingu wewnątrz domeny i wybór ścieżki dla ruchu wychodzącego z sąsiadującego systemu autonomicznego. Podobnie jak dla MED, zmiany LOCAL PREF mogą pośrednio wpływać na routing w większym obszarze sieci. ATOMIC AGGREGATE Kiedy BGP speaker agreguje wiele ścieżek, wysyła pojedyncze rozgłoszenie o ciągłym zakresie adresów obejmującym wszystkie składowe prefiksy rozgłoszeń agregowanych. Zwyczajowo wszystkie numery ASN składowych ścieżek są połączone w nieuporządkowany zbiór ASN zwany AS SET dołączany do atrybutu AS PATH. Dzięki temu spełniony jest podstawowy cel istnienia atrybutu AS PATH, którym jest zapobieganie pętli routingowych. Administrator AS agregującego ścieżki może wymusić aby router nie konstruował AS SET i nie dołączał go do zagregowanego rozgłoszenia (gdy jest pewien że ta ingerencja nie doprowadzi do powstawania pętli routingowych). Wówczas zagregowane rozgłoszenie musi zawierać atrybut ścieżki ATOMIC AGGREGATE. Routery BGP otrzymujące rozgłoszenie zawierające ATOMIC AGGREGATE nie mogą deagregować tego rozgłoszenia gdyż informacja o trasie zdeagregowanych ścieżek byłaby niepełna. Według [7], obecnie (zakładając stosowanie protokołów, routerów i hostów wspierających CIDR), nie powinna istnieć potrzeba stosowania deagregacji ścieżek. W przypadku gdy strona atakująca zmodyfikuje wartość tego atrybutu, odbiorca tego rozgłoszenia mógłby zastosować deagregację prefiksów, która doprowadziłaby do wprowadzenia ścieżek nie zawierających informacji routingowej wystarczającej do poprawnego kierowania pakietów. AGGREGATOR Atrybut AGGREGATOR służy do przekazywania numeru ASN i adresu IP routera, który przeprowadza agregację prefiksów. Wartość tego atrybutu nie jest w żaden 53

54 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa sposób uwzględniana w procesie wyboru ścieżki. Nie ma możliwości negatywnego oddziaływania na system routingowy poprzez zmianę tego atrybutu. 3.4 Ingerencja w kanał komunikacji wiadomości BGP Zalecane jest aby połączenia pomiędzy routerami BGP były realizowane jako łącze bezpośrednie (fizycznie lub logicznie poprzez wykorzystanie technik VPN (ang. Virtual Private Network)). Stosowanie się do tego zalecenia znacząco ogranicza zagrożenia związane z atakiem na kanał komunikacji wiadomości BGP. Jednakże zdarzają się sytuacje, w których routery BGP wykorzystują współdzielone łącze lub w komunikacji między nimi pośredniczą inne urządzenia sieciowe. Protokół BGP jest protokołem działającym w warstwie aplikacji modelu OSI RM (ang. Open System Interconnection Reference Model). Wymiana wiadomości BGP pomiędzy parą routerów jest realizowana poprzez warstwy niższe. Do przekazania wiadomości BGP na poziomie warstwy transportowej wykorzystywany jest protokół TCP (ang. Transmission Control Protocol). Celem jego stosowania jest zapewnienie gwarancji dostarczenia wiadomości BGP. Dzięki temu BGP nie musi implementować własnych mechanizmów wykrywania i korekcji błędów transmisji jak również nie musi retransmitować błędnie przekazanych danych. Z drugiej strony, konsekwencją tego jest narażenie się serię zagrożeń związanych z protokołem TCP a dotyczących poufności, integralności danych BGP i dostępności systemu rozumianego jako jego możliwości realizowania routingu poprzez protokół BGP Ataki na poufność komunikacji BGP Strona atakująca, poprzez zastosowanie podsłuchu, może przechwycić wiadomości BGP. Na podstawie tych wiadomości można wywnioskować jaka jest struktura sieci operatorów i jakie polityki routingowe stosują uczestniczące w wymianie strony. Przechwycenie tych wiadomości nie stanowi bezpośredniego zagrożenia dla routingu BGP. Jest jednak poważnym naruszeniem poufności wrażliwych danych biznesowych operatorów telekomunikacyjnych. Zagrożenie to dotyczy każdego typu niezabezpieczonej komunikacji wykorzystującej protokół TCP w warstwie transportowej. Komunikacja BPG w żaden sposób nie wyróżnia 54

55 się spośród nich Ataki na integralność komunikacji BGP Poprzez podsłuch, modyfikację i dostarczenie zmienionych danych strona trzecia może skonstruować atak typu man in the middle. Taki atak pozwala nieuprawnionym użytkownikom wpłynąć na routing międzydomenowy. W normalnej pracy routerów BGP, wiadomości są tworzone przez system operacyjny routera. Dba on o zachowanie spójności wysyłanych wiadomości ze stanem RIB i ze specyfikacją BGP. Modyfikacje na poziomie danych w pojedynczych pakietach, których może dopuścić się atakujący typu man in the middle, nie są kontrolowane przez system operacyjny zatem mogą powodować działanie niezgodne ze specyfikacją BGP i trudne do przewidzenia w skutkach. Ataki na integralność komunikacji BGP mogą polegać na: wysyłaniu sfałszowanych pakietów Poprzez wysyłanie odpowiednio sfabrykowanych pakietów można wycofać lub wprowadzić do systemu routingowego fałszywe ścieżki lub nieprawidłowe atrybuty ścieżek. Wprowadzenie fałszywej wiadomości BGP typu NOTIFICATION lub błędnie sformatowanych pakietów może doprowadzić do zerwania sesji BGP (zob. 3.3). Należy pamiętać, że zestawienie nowej sesji BGP jest kosztowne. Wymaga od peer ów wymiany całej informacji routingowej. Liczba wiadomości UPDATE które zostaną wysłane jest równa liczbie ścieżek znanych danemu routerowi. Strona atakująca może także wygenerować i wysłać bardzo duże ilości wiadomości BGP w celu spowodowania awarii urządzenia odbierającego te dane. wybiórczym usuwaniu pakietów Przykładowym niepożądanym działaniem jest usuwanie każdej wiadomości UPDATE przenoszącej informacje o wybranej ścieżce. W procesie decydowania o najlepszej ścieżce może wtedy zostać wybrana ścieżka gorsza pod względem wynikowego rozpływu ruchu. W skrajnym przypadku może to doprowadzić do braku 55

56 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa osiągalności hostów z danego prefiksu w zaatakowanym fragmencie sieci. Innym celem atakującego może być zmiana ścieżki w celu wymuszenia jej przechodzenia przez kontrolowane przez stronę atakującą urządzenie w celu podsłuchu ruchu użytkowego. Innym atakiem polegającym na wybiórczym usuwaniu pakietów może być eliminowanie wiadomości KEEPALIVE pomiędzy dwoma routerami BGP. Gdy wiadomości KEEPALIVE nie będą docierały do celu, sesja BGP zostaje zamknięta. modyfikacji danych w przekazywanych pakietach Poprzez modyfikowanie zawartości pakietów BGP atakujący man in the middle jest w stanie uzyskać efekty opisane szczegółowo w rozdziale 3.3. Zagrożenie modyfikacji atrybutów może powstać zatem nie tylko ze strony osób uprawnionych do uczestniczenia w routingu BGP (pracowników operatorów systemów autonomicznych) lecz także stron trzecich ingerujących w komunikację BGP na poziomie transportu TCP/IP. ataku powtórzeniowym (ang. replay attack) Gdy atakujący jako man in the middle zarejestruje dany pakiet, może wysyłać go nieograniczoną ilość razy w dowolnym momencie, dążąc np. do przywrócenia wycofanego rozgłoszenia ścieżki (wiadomość UPDATE), wycofana prawidłowej ścieżki (UPDATE wycofujący rozgłoszenie), zamknięcia sesji (wiadomość typu NOTIFI- CATION). Istotnym jest fakt, że ten atak może zakończyć się powodzeniem nawet gdy partnerzy BGP stosują zabezpieczenie hasłem. Jest ono zapamiętane wewnątrz przechwyconej wiadomości BGP, zatem jest wiarygodne dla odbiorcy tej wiadomości Ataki DoS (ang. DoS denial of service attacks) komunikacji BGP Kanał komunikacji tworzony dla potrzeb przesyłania wiadomości BGP sam może być celem ataku DoS. W tym przypadku strona atakująca stara się doprowadzić do zerwania połączenia pomiędzy BGP speakerami skutkującego zerwaniu sesji. Celem nadrzędnym może być doprowadzenie do niesprawności kierowania pakietów z ruchem użytkowym (DoS dla ruchu użytkowego). Mniej oczywistym celem jest możliwość wpływania na decyzje routingowe poprzez eliminowanie, w danej chwili wybranych jako najlepsze, ścieżek. Innym celem ataku DoS kanału komunikacji BGP jest sabotowanie wybranego BGP 56

57 speakera w celu obniżenia jego wiarygodności u innych BGP speakerów. Takie pogorszenie wiarygodności skutkuje tymczasowym zerwaniem sesji BGP, które wynika z często implementowanego mechanizmu route flap dampening (zob. rozdział 4.2.5). Kolejnym celem jaki może chcieć osiągnąć strona atakująca jest doprowadzenie do restartu sesji BGP, który w szczególnym przypadku konfiguracji BGP prowadzi do trwałego, odmiennego od początkowego stanu tablic routingowych. Taki przypadek nazywa się BGP Wedgie (szczegółowy opis w rozdziale 4.2.6). Wszystkie wymienione skutki, strona atakująca może spowodować poprzez zerwanie połączenia TCP pomiędzy parą routerów. Jest to możliwe przy zastosowaniu następujących metod ataku: Spoofing wiadomości TCP RST Sposób ataku opiera się na fabrykacji wiadomości TCP reset. Jest to wiadomość służąca do zakończenia połączenia TCP. Jej akceptacja w przypadku routera BGP powoduje zerwanie sesji. Zagrożenie tym atakiem dotyczy nie tylko protokołu BGP lecz każdej transmisji wykorzystującej w warstwie transportowej protokół TCP. Początkowo to zagrożenie było uznawane za znikome. Spoofing, czyli podrobienie wiadomości w ten sposób aby odbiorca uznał ją za wiarygodną, wymaga zgodności: źródłowego adresu IP, źródłowego portu (port strony inicjującej sesję BGP jest w pewnym stopniu wybierany losowo), numer TTL (ang. Time To Live) dla sytuacji gdy strony stosują Uogólniony mechanizm bezpieczeństwa TTL (zob. rozdział 5.2.2) i numeru sekwencji TCP. Poznanie adresu IP peerów BGP można uznać za łatwe do poznania poprzez mechanizmy traceroute. Trudność z poznaniem portu strony inicjującej ogranicza możliwość stosowania tego ataku od strony peer a nasłuchującego na standardowym porcie BGP 179 lub konieczność przejęcia dowolnego pakietu ze strumienia komunikacji BGP i pobrania z niego numeru portu. Problemy obejścia mechanizmu bezpieczeństwa TTL są szczegółowo opisane w rozdziale Elementem najtrudniejszym do sfabrykowania jest numer sekwencji TCP. Jest to numer zmieniający się wraz z wysyłaniem kolejnych wiadomości BGP. Pakiety przychodzące z nieskorelowanym numerem sekwencyjnym są uznawane za niepochodzące z danego strumienia komunikacji i są odrzucane. Jego podrobienie wymaga nasłuchiwania w czasie rzeczywi- 57

58 3 Analiza podatności BGP stanowiących zagrożenie bezpieczeństwa stym przekazywanych pakietów. Szanse na udany atak zwiększa akceptowanie przez algorytm TCP numerów sekwencyjnych należących do okna transmisji TCP. Okno transmisji określa ile kolejnych numerów sekwencyjnych router akceptuje. Zakres ten zmienia się w trakcie transmisji i jest większy dla dużych prędkości transmisji. Rys. 3.4 Schemat ataku typu TCP Reset Znaczącym utrudnieniem spoofingu TCP jest wykorzystanie mechanizmów uwierzytelnienia. Jednym z nich jest stosowanie funkcji skrótu MD5 bazującego na haśle. Pakiety TCP zawierające wiadomości BGP są wysyłane wraz ze skrótem wiadomości co gwarantuje ich integralność i uwierzytelnienie. Flooding wiadomości TCP SYN Bardzo częste próby nawiązania połączenia TCP poprzez wysłanie wiadomości TCP synchronizuj (ang. synchronize) mogą skutkować brakiem dostępności DoS routera atakowanego. W tym przypadku sesja BGP jest zrywana, gdyż atakowany router nie jest w stanie wysyłać wiadomości UPDATE lub KEEPALIVE. Nowe sesje BGP są niemożliwe do ustanowienia gdyż routery nie są w stanie zestawić pomiędzy sobą połączenia TCP. Ta podatność wynika ze sposobu nawiązywania połączenia TCP nazywanego three way handshake. Po odebraniu wiadomości SYN router odpowiada wiadomością ACK i przechodzi do stanu SYN RECEIVED. Pomijając znaczący ruch sygnalizacyjny, 58

59 który musi zostać obsłużony, właściwym problemem są nie w pełni zainicjowane połączenia TCP, które muszą być przechowywane w pamięci podręcznej routera na wypadek przyjścia potwierdzenia ACK od strony inicjującej połączenie. Przy masowym napływie zgłoszeń pamięć routera może ulec wyczerpaniu, a w tej sytuacji nie będzie on w stanie obsłużyć rzeczywistych prób nawiązania połączenia z sąsiadem BGP. Rys. 3.5 Schemat ataku typu SYN flooding (źródło: wikipedia SYN flood ) Znaczącym ułatwieniem dla strony atakującej stosującej atak SYN flooding jest brak konieczności podrobienia numeru sekwencyjnego TCP. W chwili inicjowania połączenia nie ma sposobu jego weryfikacji. Do sfabrykowania wiadomości służących do ataku SYN flooding nie potrzeba również określonego portu strony inicjującej w chwili rozpoczynania komunikacji ten wybór jest dowolny. Jedyną, lecz bardzo wątpliwą trudnością, jest zapewnienie zgodności źródłowego adresu IP ze względu na to, że router atakowany może posiadać listę dopuszczalnych adresów pochodzenia pakietów TCP i odrzucać te, które nie pochodzą z jej zakresu. Stosowanie mechanizmów uwierzytelniania np. MD5 pozwala na odrzucenie pakietów z nieuprawnionego źródła lecz jednocześnie zwiększa złożoność obliczeniową wymaganą do obsłużenia pakietu. 59

60 3.5 Podsumowanie Brak wbudowanych w BGP mechanizmów zapewniania bezpieczeństwa zmusza wiele grup osób do zwiększonego wysiłku mającego na celu utrzymanie sieci z routingiem BGP. Do tych grup należą przede wszystkim administratorzy systemów autonomicznych. Są oni zmuszeni do stosowania się do dobrych praktyk (ang. best practices), czyli działań administracyjnych zmniejszających zagrożenie poprzez odporną na błędy i ataki konfigurację routerów. Kolejną grupą osób są administratorzy urządzeń sieciowych dbający o to by sesja BGP była odpowiednio zabezpieczona. Metody te w znacznym stopniu redukują zagrożenie atakiem BGP, ograniczając możliwość jego powstania ze strony osób trzecich, nieuprawnionych do uczestnictwa w routingu BGP. Osobami zaangażowanymi w zwiększanie bezpieczeństwa są także pracownicy rozwijający oprogramowanie routerów, dzięki staraniom których implementowane są rozmaite mechanizmy ochrony routingu BGP. Rosnące zainteresowanie bezpieczeństwem BGP, które ma znaczący i bezpośredni wpływ na bezpieczeństwo sieci Internet 1, świadczy o tym, że starania mające na celu zmniejszenie podatności BGP na ataki mają obecnie wysoki priorytet. 1 Niejedynym sygnałem potwierdzającym rosnące zainteresowanie bezpieczeństwem BGP jest fakt finansowania przez Departament Bezpieczeństwa Krajowego Stanów Zjednoczonych (DHS ang. Department of Homeland Security) wielu projektów badawczych Open Source zajmujących się problemami związanymi z BGP (źródło: U.S. plots major upgrade to Internet router security Millions to be spent adding cryptography to BGP, Carolyn Duffy Marsan, Network World 2009)

61 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP 4.1 Wstęp Luki bezpieczeństwa BGP powodują podatność sieci Internet na różne rodzaje ataków. Trudność ich kategoryzacji wynika z faktu, że możliwość ich przeprowadzenia wynika najczęściej z więcej niż jednej luki bezpieczeństwa BGP. Najczęściej również zamierzony skutek ataku może być różny w zależności od jego parametrów. Typ zamierzonego skutku i podatność BGP umożliwiająca jego powstanie są wymienione przy każdym rodzaju opisywanego ataku. Możliwe do osiągnięcia skutki ataków można podzielić na: Nieosiągalność hostów (DoS hostów) ataki powodujące niedostępność hostów z zaatakowanych prefiksów Niesprawność sieci (DoS sieci) ataki powodujące pogorszenie parametrów przekazywania ruchu w sieci. W krytycznym przypadku uniemożliwiające wymianę ruchu użytkowego w zaatakowanych obszarach sieci. Niesprawność DoS sieci jest osiągana poprzez błędne kierowanie znaczących wolumenów ruchu Man in the middle (MiTM) ataki umożliwiające skierowanie ruchu poprzez określone miejsce w sieci w celu stworzenia zagrożenia atakiem man in the middle dla ruchu użytkowego Kradzież osobowości (ang. identity theft) atak polegający na podszyciu się pod innych użytkowników sieci. Przykładowo, przejęcie adresu IP, pod którym udostępniona jest strona internetowa i wyświetlenie własnej wersji strony umożliwiające przejęcie poufnych danych użytkowników Spam atak w celu umożliwienia wysyłania niechcianych treści (tzw. spam). Słowo umożliwienie jest tu rozumiane jako zwiększenie szans na dotarcie niechcianych treści do odbiorców końcowych. Jest to realizowane poprzez ominięcie serwerów RBL (ang. Realtime Black List) filtrujących w czasie rzeczywistym ruch na podstawie jego pochodzenia 61

62 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP W rozdziale 4.2 przedstawiono koncepcje ataków na ruch użytkowy, których możliwość powstania jest bezpośrednio związana z faktem wykorzystywania protokołu BGP do routingu międzydomenowego. 4.2 Rodzaje ataków Przejęcie prefiksu cel ataku: DoS hostów / Identity theft Możliwość ataku wynikająca z wady BGP polegającej na braku weryfikacji rozgłaszanych prefiksów (zob. rozdział 3.2) jest przejęcie prefiksu (ang. prefix hijacking). Routery, które nie odfiltrują błędnego rozgłoszenia i, przez które zostanie ono wybrane jako najlepsze, będą kierować ruch użytkowy w niewłaściwe miejsce w sieci. Na Rys. 4.1 widać jak system autonomiczny AS1 rozgłasza już istniejący w sieci prefiks /16. Rozważmy ścieżki do tego prefiksu, które są znane routerom w systemie AS3. Atrybut AS PATH rozgłoszenia ścieżek prowadzących do prawowitego właściciela prefiksów jest postaci [AS6, AS5, AS4] i [AS6, AS5, AS7]. Liczba ASN dla obu tych ścieżek wynosi 3. Ścieżka do przejmującego prefiks AS1, która zostanie rozgłoszona do AS3 jest postaci [AS1, AS2] (o długości 2). Zakładając, że kryterium wyboru najlepszej ścieżki będzie długość AS PATH, systemy autonomiczne AS2 i AS3 wybierają ścieżkę prowadzącą do strony atakującej AS1. 62

63 Rys. 4.1 Atak typu przejęcie prefiksu (źródło: A Survey of BGP Security, Issues and Solutions, IEEE) Ruch użytkowy trafiający do wrogiego AS przeprowadzającego przejęcie prefiksu może być odrzucany. Wówczas, dla zaatakowanego fragmentu sieci, hosty z tego prefiksu będą nieosiągalne. Efekt ten nazywany jest black hole effect (zob. Rys. 4.2, przypadek a). Zagrożenie może być większe gdy routery z AS1 skierują ruch do hostów ze swojej podsieci co pozwoli im przechwycić przesyłane dane, naruszając ich poufność (zob. Rys. 4.2, przypadek b). Możliwe jest także przejęcie ruchu, modyfikacja danych i przekazanie ich do właściwych hostów, tak aby użytkownicy nie zauważyli jakiejkolwiek ingerencji (man in the middle ruchu użytkowego zob. Rys. 4.2, przypadek c). Wreszcie, istnieje także sposób aby skierować ruch do hostów ze swojej podsieci i odpowiedzieć nadawcy wiadomości w imieniu hostów z przejętego prefiksu (podszycie, kradzież osobowości zob. Rys. 4.2, przypadek d). 63

64 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP Rys. 4.2 Wykorzystanie ataku prefix hijacking (a) black hole effect, b) podsłuch, c) man in the middle, d) kradzież osobowości) przeciwdziałanie: Filtrowanie prefiksów. Przed atakiem prefix hijacking trudno się obronić ponieważ wymagałoby to utrzymywania rejestrów przynależności prefiksów do systemów autonomicznych (rozwiązania tego typu są proponowane w koncepcjach S BGP i IRV zob.rozdziały i 5.4.3) Rozgłaszanie ścieżek dla zarezerwowanych przestrzeni adresowych cel ataku: DoS sieci Routery BGP mogą rozgłaszać przestrzenie adresowe zarezerwowane przez IANA na specjalny użytek (ang. Special use IP prefix hijacking). Są to przede wszystkim pule adresów prywatnych ( /8, /12, i /16), adresy loopback odzwierciedlające wirtualne urządzenie sieciowe wykorzystywane do komunikacji IP w obrębie jednego hosta ( /8), adresy multicast służące do komunikacji jeden do wielu docierającej do grup odbiorców ( /8). Adresy z tych przestrzeni adresowych nigdy nie powinny znaleźć się w globalnych tablicach routingowych. W obszarach sieci, w których takie rozgłoszenia zostaną zaakceptowane i trafią do tablic FIB, funkcjonalności oparte na wykorzystaniu adresów zarezerwowanych nie będą realizowane. 64

65 Organizacja IANA podjęła działania zmniejszające szkodliwość przedostania się poza sieci lokalne ruchu adresowanego na przestrzenie prywatne. Powstały w tym celu serwery DNS nazywane blackhole servers (zob. [31]), które natychmiast zwracają na adres źródłowy odpowiedź o nieistniejącym adresie. Służy to szybkiemu wyeliminowaniu niepożądanego ruchu z sieci. przeciwdziałanie: Ścieżki zawierające rozgłoszenia z prefiksami adresów specjalnego użytku powinny być filtrowane przez administratorów AS Rozgłaszanie ścieżek dla nieprzydzielonych przestrzeni adresowych cel ataku: Spam / DoS sieci i hostów (Backscatter) Rozgłoszenie w imieniu ofiary ataku adresów nieprzydzielonych przez IANA (tzw. adresy bogon) może spowodować DoS sieci. To zagrożenie jest spowodowane tzw. ruchem backscatter. Backscatter jest pobocznym efektem ataków wykorzystujących spoofing (zmianę adresu źródłowego pakietów). Ponieważ adresy te mogą być wybrane arbitralnie, często zdarza się, że atakujący wybierze adres bogon pochodzący z nieprzydzielonej przestrzeni adresowej. Zazwyczaj adresy bogon w istocie nie są rozgłaszane przez żaden AS, zatem taki ruch krąży w sieci aż zostanie odrzucony z powodu nieznanej drogi do celu, bądź w wyniku wyzerowania licznika TTL (ang. Time To Live). Rys. 4.3 Powstawanie ruchu backscatter Gdy strona atakująca rozgłosi prefiksy z adresami bogon tak aby były kierowane do AS będącego ofiarą tego ataku, stanie się on jedynym odbiorcą ruchu backscatter w sieci. 65

66 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP Powodzenie tego ataku DoS uprawdopodabnia fakt, że w sieci Internet w każdym momencie przeprowadzana jest znaczna liczba ataków spoofingowych zatem wolumen ruchu backscatter jest znaczny. Atak prawdopodobnie nie pozwoli na przeciążenie wydajnych serwerów lub routerów w sieci, jednak gdy zostanie ukierunkowany na mniej odporny cel może osiągnąć skutek w postaci DoS serwera lub routera. Innym wykorzystaniem opisywanego ataku jest możliwość skutecznego wysyłania wiadomości niepożądanych (tzw. spam). Często stosowanym zabezpieczeniem przed spamem jest wykorzystanie serwerów RBL (ang. Real time Blackhole List Server). Ich działanie polega na monitorowaniu sieci, identyfikowaniu ruchu przenoszącego spam i natychmiastowym umieszczaniu źródeł niepożądanego ruchu na czarnych listach. Wyrafinowanym sposobem uniknięcia odfiltrowania swoich wiadomości zawierających spam, jest zastosowanie przejęcia prefiksu z adresami bogon. Atakujący na krótki czas przejmuje duży zakres adresów bogon (zob. Rys. 4.4), adresy te z reguły nie znajdują się na czarnych listach serwerów RBL ponieważ są wykorzystywane do wysyłki spamu sporadycznie. Rys. 4.4 Przebieg czasowy przejęcia bogon adresów w celu wysyłki spamu (źródło: Fighting Spam, Phishing and Online Scams at the Network Level) przeciwdziałanie: Ścieżki zawierające rozgłoszenia z prefiksami adresów bogon powinny być filtrowane przez administratorów AS. 66

67 4.2.4 Modyfikowanie tras ruchu użytkowego cel ataku: DoS / MiTM Bardzo wiele metod opisywanych w rozdziałach 3.3 i 3.4 umożliwia wrogiej stronie zmianę routingu ruchu użytkowego. Zmiany takie mogą wywołać efekt DoS, gdyż atakujący może wymusić kierowanie ruchu po skrajnie nieoptymalnych ścieżkach. Kolejnym niepożądanym skutkiem, może być wymuszenie tranzytu ruchu użytkowego przez urządzenia, w których zostanie zastosowany podsłuch lub modyfikacja danych w celu uruchomienia ataku man in the middle ruchu użytkowego. przeciwdziałanie: Filtrowanie rozgłoszeń. Ochrona sesji BGP przed atakiem man in the middle komunikacji BGP Atak powodujący niestabilność ścieżek cel ataku: DoS / MiTM Istotą tego ataku jest wielokrotne doprowadzanie do DoS routera BGP, wymuszanie przerwania wybranych sesji BGP z danym routerem lub wielokrotne wprowadzanie zmian w atrybutach pojedynczej ścieżki. W wyniku konieczności odbudowy sesji BGP, wymagającej każdorazowo wymiany całej informacji routingowej, dochodzi do niestabilności ścieżek (ang. Route Flapping) objawiającej się ich wielokrotnym rozgłaszaniem i wycofywaniem. Utrzymywanie sesji z sąsiadami BGP, którzy są źródłem route flapping jest nieopłacalne. Powoduje bowiem nadmierny ruch sygnalizacyjny w sieci, a konieczność każdorazowego uruchamiania algorytmu wyboru najlepszej ścieżki niepotrzebnie zużywa moc obliczeniową routerów. Podjęto działania, polegające na implementacji w routerach BGP mechanizmu, mającego umożliwić eliminowanie rozgłoszeń od routerów wywołujących route flapping. W tym celu routery implementują mechanizm route flap dampening (zob. [25]) polegający na naliczaniu karnych punktów po każdorazowym wycofaniu i przywróceniu ścieżki, bądź zmianie jej atrybutów. Po przekroczeniu limitu punktów karnych (próg suppress limit) ścieżka jest usuwana z tablic routingowych a jej rozgłaszanie do innych routerów jest wstrzymywane. Licznik punktów karnych jest zmniejszany w czasie, w którym ścieżka pozostaje niezmienna. Gdy liczba punktów karnych spadnie poniżej progu reuse limit, 67

68 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP ścieżka jest przywracana i ponownie rozgłaszana. Przykładowy przebieg działania mechanizmu route flap dampening przedstawiony jako wykres liczby punktów karnych w czasie prezentuje Rys Rys. 4.5 BGP Dampening, wykres przedstawiający ilość punktów w czasie i stan rozgłaszania ścieżki dla poszczególnych progów. Źródło: [flapdampeningcisco]) Przy wykorzystaniu ataku man in the middle komunikacji BGP lub DoS komunikacji BGP można wymusić odrzucenie wybranych ścieżek przez mechanizm route flap dampening. Tym samym doprowadzając do zmiany kierowania ruchu użytkowego mogącego prowadzić do nieoptymalnego kierowania ruchu (w skrajnym przypadku DoS sieci) lub umożliwiającego atak man in the middle wobec ruchu użytkowego. Ciekawym sposobem posłużenia się atakiem wywołującym niestabilność ścieżek jest możliwość wykorzystania go do zwiększenia skali drugiego ataku rodzaju prefix hijacking. Gdy w danym miejscu sieci następuje próba przejęcia danego prefiksu a jednocześnie na routery pośredniczące w przekazywaniu informacji o prawidłowej ścieżce wykonywany jest omawiany atak, ścieżka prawidłowa może zostać odrzucona przez mechanizm route flap dampening, a atak prefix hijacking obejmie swoim zasięgiem znacznie większy obszar sieci (patrz [26]). przeciwdziałanie: niestosowanie restrykcyjnych parametrów konfiguracji mechanizmu route flap dampening. Ochrona sesji BGP przeciwko atakom DoS i man in the middle (zob. rozdział 5.2). 68

69 4.2.6 Atak wywołujący BGP Wedgie cel ataku: DoS / MiTM (rzadko) W celu zrozumienia idei tego ataku należy wpierw poznać zjawisko BGP Wedgie (patrz [6]). Zakłada się, że algorytm protokołu BGP dla określonych danych wejściowych zawsze zwróci ten sam wynik w postaci zbioru wybranych ścieżek do prefiksów docelowych. Okazuje się, że w pewnych szczególnych sytuacjach BGP zachowuje się niedeterministycznie i istnieje więcej niż jeden, stabilny wariant wyboru ścieżek. Sytuacje te są o tyle problematyczne, że zazwyczaj tylko jeden z wariantów stanu FIB jest pożądany przez administratorów AS. Natomiast po wyborze innego wariantu routingu, jedyną możliwością powrotu do konfiguracji pożądanej jest konieczność bezpośredniej ingerencji personelu zarządzającego routingiem BGP. Rozpatrzmy sytuację jak na Rys Poprzez atrybut COMMUNITY AS1 określa, którego z dostawców uważa za podstawowego (AS3), a którego za zapasowego (AS2). Na podstawie umów międzyoperatorskich można określić wartości COMMUNITY i wynikające z niego wartości atrybutu LOCAL PREF przypisywanych po stronie sąsiada (patrz [3]). Wówczas rozstrzygnięcie o najlepszej ścieżce odbywa się na poziomie LOCAL PREF a nie długości AS PATH, czyli mechanizm znany jako AS path prepending może zostać zastąpiony poprzez wykorzystanie COMMUNITY. Jeżeli AS2 odbierze najpierw rozgłoszenie przechodzące przez AS3, AS4, AS1 z oznaczeniem PRIMARY, zostanie ono uznane za najlepsze i tym samym AS2 nie przekaże do AS3 informacji o konkurencyjnej ścieżce bezpośredniej do AS1. Jest to routing zgodny z oczekiwaniami AS1. 69

70 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP Rys. 4.6 BGP Wedgie, routing zgodny z oczekiwaniami AS1 Rozważmy teraz co wydarzy się po zerwaniu sesji BGP pomiędzy AS3 i AS4 (zob. Rys. 4.7). Po zaobserwowanym przez AS2 wycofaniu scieżki podstawowej, router wybiera jedyną pozostałą ścieżkę zapasową wykorzystującą bezpośrednie połączenie z AS1. Rozgłasza tę ścieżkę do swojego BGP peer AS3, jednakże atrybut COMMUNITY określający ją jako zapasową zazwyczaj nie jest propagowany dalej niż do bezpośredniego sąsiedztwa BGP. W momencie gdy sesja między AS3 i AS4 zostanie przywrócona, do AS3 trafi konkurencyjne rozgłoszenie o ścieżce do klienta AS1. Jednak na podstawie widzianych przez AS3 atrybutów nie jest ona lepsza niż już istniejąca ścieżka przez AS2, AS1. Ponadto AS3 może preferować tę trasę z zupełnie innych powodów (na przykład, preferując ścieżki bezpośrednio prowadzące do swoich klientów (relacja provider customer, zamiast relacji między równoprawnymi partnerami peer peer, zgodnie z oznaczeniami na rysunkach). Zatem nowe rozgłoszenie przez AS4, AS1 nie zostanie przekazane do sąsiada AS2. Routing osiągnie stan ustalony niezgodny z oczekiwaniami AS1. 70

71 Rys. 4.7 BGP Wedgie, stabilny stan routingu niezgodny z oczekiwaniami AS1 Aby doprowadzić do ataku mającego na celu przejście routingu w ustalony, mniej efektywny stan BGP Wedgie, atakujący może posłużyć się dowolnym atakiem DoS na sesję BGP. Po zerwaniu sesji między odpowiednią parą routerów przez stronę atakującą i po jej ponownym ustanowieniu cel zostanie osiągnięty. Należy zauważyć, że aby być w stanie stworzyć atak BGP Wedgie, strona atakująca musi posiadać ogromną i szczegółową wiedzę o topologii sieci więcej niż jednego systemu autonomicznego. Ponadto musi ona umieć przewidzieć możliwość powstania BGP Wedgie i precyzyjnie wybrać parę routerów (lub dla bardziej skomplikowanych sytuacji wielu par routerów BGP) i moment zerwania sesji między nimi. Co jednak wydaje się najważniejsze, skutek tego ataku zazwyczaj nie jest tak spektakularny osiągalność hostów prawdopodobnie nie zostanie zagrożona, jedynie dobór ścieżek może być mniej efektywny od oczekiwanego. Jednakże, konieczność manualnej ingerencji personelu administracji w celu przywrócenia prawidłowego działania sieci i łatwość uruchomienia tego ataku (poprzez DoS komunikacji BGP między parą routerów) jest argumentem przemawiającym za tym by operatorzy zminimalizowali możliwość ich powstania. przeciwdziałanie: Jak wynika z mechanizmu powstawania BGP Wedgie może on ujawniać się w nominalnej pracy sieci, nie spowodowany specjalnie na to ukierunkowanym atakiem. Sama możliwość przejścia routingu w stan BGP Wedgie powinna być eliminowana przez administratorów. 71

72 4 Rodzaje ataków na ruch użytkowy wykorzystujących podatności BGP Ryzyko deagregacji prefiksów cel ataku: DoS (znaczący) Poważnym zagrożeniem dla stabilności sieci jest ryzyko deagregacji prefiksów (ang. de-aggregation risk). Jako, że większość sytuacji tego typu w historii sieci Internet, było spowodowane błędem administratorów AS a nie chęcią szkodliwego działania (świadomy atak), mówimy tutaj o ryzyku deagregacji a nie o ataku. Należy jednak mieć na uwadze możliwość wywołania tego zjawiska z premedytacją. Schemat powstawania takiego zagrożenia polega na rozgłoszeniu wielu prefiksów o dłuższej masce, w miejsce każdego znanego danemu routerówi prefiksu. Efektem tego są dwa, wzajemnie wzmacniające swój skutek, problemy. Po pierwsze, znacząco zwiększa się ilość informacji routingowej wymienianej między routerami bazując na przykładzie historycznego ataku z roku 1997, gdy AS 7007 rozgłosił zdeagregowane do długości maski /24 prefiksy, co daje 2 24 prefiksów (przy założeniu znajomości każdego prefiksu w sieci Internet). Co gorsza, rozgłoszenia te, zgodnie z regułą longest prefix match są ścieżkami częściej wybieranymi do kierowania przez nie ruchu. Poprzez to, ogromne ilości ruchu mogą trafić do obszarów sieci nieprzystosowanych do obsługi tak znacznych ilości danych. przeciwdziałanie: Stosowanie filtrowania rozgłoszeń. Stosowanie mechanizmu maximum prefix ograniczającego maksymalną liczbę przyjętych rozgłoszeń od danego sąsiada BGP Ryzyko rozgłoszenia bezpośredniej ścieżki do wielu adresów w sieci Internet cel ataku: DoS (znaczący) Gdy router w konsekwencji poważnego błędu administratorów rozgłosi istnienie bezpośredniego połączenia z dużą ilością prefiksów, obszary sieci, które nie odfiltrują tych rozgłoszeń będą kierować ruch do niewłaściwego miejsca w sieci. Jest to szczególny przypadek ataku prefix hijacking (zob. rozdział 4.2.1) odbywający się na dużą skalę. W skutkach i metodach przeciwdziałania, zagrożenie to jest podobne do ryzyka deagregacji prefiksów. Historycznym przykładem awarii spowodowanej rozgłoszeniem bezpośredniej ścieżki 1 mechanizm maximum prefix jest funkcjonalnością standardowo implementowaną w routerach BGP 72

73 do wielu adresów w sieci Internet jest incydent z 2004 roku, kiedy AS9121 rozgłosił około 100 tysięcy prefiksów pokrywających większość adresacji hostów IPv4 (zob. [6]). Sytuacja ta pogorszyła się przez fakt braku ograniczenia maximum prefix u jednego z sąsiadów BGP AS6762. W ciągu niespełna dwóch minut, nieprawidłowe rozgłoszenia stały się częściej wybierane od rozgłoszeń prawowitych właścicieli zagrożonych prefiksów. Dowiodło to niewystarczającej ochrony wynikającej ze stosowania maximum prefix i znacznego zwiększenia ryzyka w przypadku gdy część uczestników routingu BGP nie stosuje podstawowych metod zabezpieczania przed tego typu zdarzeniami. przeciwdziałanie: Stosowanie filtrowania rozgłoszeń. Stosowanie mechanizmu maximum prefix ograniczającego maksymalną liczbę przyjętych rozgłoszeń od danego sąsiada BGP. 4.3 Podsumowanie Pomimo zagrożenia atakami mogącymi powstać wyłącznie w sieci wykorzystującej protokół BGP, nie istnieje obecnie alternatywne rozwiązanie dla routingu międzydomenowego. BGP zapewnia stosunkowo stabilny i odporny na błędy routing (ang. robust) działający w skali globalnej. Mimo udokumentowanych awarii w historii sieci Internet (i przypuszczalnie wielu awarii, których fakt zaistnienia operatorzy ukrywają) można uznać, że w ogromnym środowisku jakim jest sieć Internet, przy udziale tak wielkiej ilości uczestników routingu BGP, jest to rozwiązanie zadowalające. Należy spodziewać się ewolucyjnego rozwoju BGP o elementy zwiększające jego bezpieczeństwo (zob. rozdział 5.4) niż próbę zastąpienia go jakimkolwiek nowym protokołem. Wraz z opisem każdego ataku nadmienione zostały środki zaradcze, wynikające ze zdefiniowanych w protokole metod lub wynikające ze standardowo implementowanych w routerach BGP mechanizmów. Pozwalają one w znaczącym stopniu zmniejszyć ryzyko wystąpienia awarii/ataku lub całkowicie go uniemożliwić.

74

75 5 Rozwiązania problemu bezpieczeństwa protokołu BGP 5.1 Wprowadzenie Zabezpieczenie routingu międzydomenowego stanowi wielkie wyzwanie od wielu lat. Powszechne wykorzystanie protokołu BGP w sieci Internet sprawia, że jego bezpieczeństwo jest kluczowe z punktu widzenia poprawności routingu międzydomenowego. Protokół BGP do wyboru najlepszej ścieżki wykorzystuje reguły i parametry administracyjne. Z tego względu jest podatny na błędy konfiguracyjne. Ze względu na globalny zasięg protokołu skutki awarii lub przeprowadzonego ataku mogą wpłynąć na stabilność i poprawność routingu w dużej części sieci. W celu zapewnienia bezpieczeństwa routingu międzydomenowego niezbędne jest zabezpieczenie infrastruktury fizycznej sieci oraz jej styków zarządzania. Bezpieczeństwo warstwy fizycznej można zwiększyć przez zaprojektowanie sieci, która jest odporna na awarie i wynikające z nich przeciążenia np. zapewniając ścieżki zapasowe (patrz [10]). Dostęp do routerów i zarządzanie nimi najczęściej odbywa się za pośrednictwem protokołu SNMP lub poprzez zdalne połączenie do CLI (ang. Command-line interface). Zabezpieczenie styków zarządzania jak i fizycznego dostępu do routerów jest niezbędne w celu zapewnienia bezpieczeństwa routingu międzydomenowego. Większość mechanizmów bezpieczeństwa protokołu BGP jakie są obecnie implementowane wykorzystują rozwiązania lokalne, które można wprowadzić wewnątrz pojedynczego systemu autonomicznego bez interakcji z sąsiednimi operatorami. Najczęściej implementowane rozwiązania obejmują zabezpieczenie połączenia TCP oraz filtrowanie rozgłoszeń BGP. Mechanizmy te są jednak mało efektywne w przypadku bardziej złożonych i wyrafinowanych ataków. Obecnie trwają prace nad stworzeniem zintegrowanego systemu bezpieczeństwa, którego wprowadzenie zapewniłoby kompleksowe bezpieczeństwo protokołu BGP. W pierwszej części rozdziału zostały opisane metody zabezpieczenia sesji pomiędzy sąsiadującymi routerami BGP. Obejmują one uwierzytelnianie uczestników sesji na poziomie protokołu TCP, ochronę przed atakiem z hosta podszywającego się pod sąsiadujący router BGP oraz kryptograficzne zabezpieczenie treści przesyłanych wiadomości BGP. 75

76 5 Rozwiązania problemu bezpieczeństwa protokołu BGP Następnie przedstawiono najbardziej powszechne zasady filtrowania rozgłoszeń BGP oraz mechanizm rejestrów routingowych, którego wprowadzenie przyczyniłoby się do zwiększenia efektywności filtrowania rozgłoszeń. W ostatniej części opisano przykłady zintegrowanych systemów bezpieczeństwa protokołu BGP. 5.2 Zabezpieczenie sesji Sąsiadujące routery BGP, po skonfigurowaniu przez administratora, ustanawiają między sobą sesję BGP w celu wymiany wiadomości routingowych. Sesja wykorzystuje stałe, niezawodne połączenie TCP. Zabezpieczenie komunikacji pomiędzy sąsiadującymi routerami BGP polega na zapewnieniu bezpieczeństwa połączenia TCP oraz sesji protokołu BGP. W niniejszym podrozdziale przedstawiono metody pozwalające zwiększyć bezpieczeństwo komunikacji pomiędzy sąsiadującymi routerami BGP Uwierzytelnianie MD5 Jednym ze sposobów zabezpieczenia sesji między dwoma routerami BGP jest wykorzystanie mechanizmu uwierzytelnienia MD5 (patrz [1]) działającego wewnątrz protokołu TCP. Mechanizm ten został zaprojektowany do weryfikacji czy otrzymany pakiet został wysłany przez określone urządzenie. Mechanizm uwierzytelnienia MD5 dodatkowo zabezpiecza integralność wiadomości oraz chroni przed atakiem powtórzeniowym. Ze względu na brak szyfrowania nie ukrywa treści transmitowanych wiadomości. Uwierzytelnianie MD5 bazuje na kluczu kryptograficznym współdzielonym przez sąsiadujące routery BGP (celu zwiększenia bezpieczeństwa klucz może być okresowo zmieniany). Router przed wysłaniem pakietu wykonuje szereg matematycznych obliczeń z użyciem klucza do wyliczenia liczby będącej podpisem cyfrowym pakietu. Podpis jest dołączony do wysyłanego pakietu podczas transmisji. Router, który odebrał pakiet, wykorzystuje ten sam klucz do wyliczenia podpisu. Jeżeli otrzymana wartość jest inna niż ta przesłana w pakiecie, pakiet jest odrzucany. Współdzielony klucz nie jest transmitowany przez sieć. Administratorzy zarządzający routerami BGP muszą go wprowadzić ręcznie, co stanowi duże ograniczenie mechanizmu. Użycie mechanizmu uwierzytelnienia MD5 nie jest negocjowane podczas zestawiania sesji jest to opcjonalny mechanizm, którego wykorzystanie zależy od konfiguracji routera. 76

77 Do przenoszenia podpisu cyfrowego MD5 wykorzystywany jest dodatkowy nagłówek opcji dodawany do nagłówka protokołu TCP. Składa się on z następujących pól: Kind wskazuje typ nagłówka opcji protokołu TCP w przypadku uwierzytelniania MD5 wskazuje oprogramowanie, które dołączyło do nagłówka TCP podpis cyfrowy MD5; Length długość podpisu cyfrowego MD5; Podpis MD5 liczba będąca podpisem cyfrowym pakietu wyliczona przez router nadawcy. Podpis cyfrowy MD5 jest wyliczany na podstawie współdzielonego klucza oraz parametrów sesji TCP/IP. Wykorzystywane są następujące pola pakietu: Adres źródłowy IP; Adres docelowy IP; Numer protokołu; Długość segmentu protokołu TCP; Nagłówek protokołu TCP; Dane przenoszone wewnątrz segmentu protokołu TCP. Obecnie trwają prace nad zautomatyzowaniem procesu wymiany kluczy do uwierzytelnia sąsiadujących routerów BGP za pomocą mechanizmu MD5 (patrz [11]) Uogólniony mechanizm bezpieczeństwa TTL Wiele słabości protokołu BGP wynika z wykorzystania w nim protokołu TCP. Charakter tego protokołu sprawia, że do wykonania ataku na router BGP może być wykorzystany dowolny host w sieci Internet. Pakiet może być wysłany z dowolnym adresem źródłowym np. w celu wykonania ataku na router BGP może być użyty adres IP jego sąsiedniego routera BGP (podszycie się). Uogólniony mechanizm bezpieczeństwa TTL (ang. Generalized TTL Security Mechanizm GTSM, patrz [5]) zapewnia, że jedynie pakiety wysłane 77

78 5 Rozwiązania problemu bezpieczeństwa protokołu BGP z routerów znajdujących się w określonym promieniu (w sensie liczby przeskoków) zostaną zaakceptowane przez router BGP. Atrybut TTL (ang. Time To Live) jest przenoszony wewnątrz nagłówka protokołu IP. Jego wartość jest zmniejszana o jeden po przejściu przez każdy router na ścieżce. Maksymalna wartość atrybutu jaką można ustawić podczas wysyłania pakietu do sieci jest ograniczona i wynosi 255. Uogólniony mechanizm bezpieczeństwa TTL polega na ograniczeniu od dołu wartości parametru TTL dla pakietów, które mogą zostać zaakceptowane przez router BGP. Takie zabezpieczenie jest skutecznie, ponieważ w przypadku większości sesji BGP routery znajdują się w niewielkiej odległości od siebie (przeważnie w bezpośrednim sąsiedztwie). Routery używające mechanizmu GTSM ustalają wartość atrybutu TTL na maksymalną (255). Kiedy router BGP otrzyma pakiet, sprawdza wartość atrybutu TTL pakiety z mniejszą wartością niż ustalona wartość progowa są odrzucane. Na Rys. 5.1 routery brzegowe systemów autonomicznych AS i znajdują się w bezpośrednim sąsiedztwie. Po zastosowaniu mechanizmu GTSM w routerze brzegowym systemu i ustawieniu wartości progowej parametru TTL na 254 (wartość maksymalna minus jeden skok) akceptowane będą tylko wiadomości wysłane z routerów bezpośrednio z nim sąsiadujących. Pakiety wysłane z odległego hosta (host A na Rys. 5.1) zostaną odrzucone ze względu na zbyt małą wartość atrybutu TTL. 78 Rys. 5.1 Uogólniony mechanizm bezpieczeństwa TTL przykład

79 Skuteczność mechanizmu GTSM jest ograniczona w przypadku routerów BGP, które nie znajdują się w bezpośrednim sąsiedztwie. Wartość progowa parametru TTL może być odpowiednio zmniejszona jednak mechanizm nie chroni wówczas przed atakami z hostów znajdujących się w tak określonym zasięgu. Ponadto do ominięcia mechanizmu GTSM może być wykorzystana enkapsulacja pakietu IP wewnątrz innego pakietu. Dokonanie dekapsulacji w odległości jednego skoku od docelowego routera BGP będzie skutkować dostarczeniem do niego pakietu z maksymalną wartością atrybutu TTL. Mechanizm GTSM jest prosty, mało kosztowny i skuteczny głównie przeciwko niewyrafinowanym atakom Test Reverse path forward Jednym z głównych zadań zapewnienia bezpieczeństwa sesji protokołu BGP jest przeciwdziałanie atakom polegającym na podszywaniu się pod adres IP sąsiadującego routera BGP. Na Rys. 5.2 routery brzegowe (A i B) należące do różnych systemów autonomicznych mają ustanowioną sesję BGP. Host C posiadający tymczasowy adres podszywa się pod adres routera B ( ) i wysyła w jego imieniu fałszywe wiadomości protokołu BGP do routera A. Rys. 5.2 Reverse path forward przykład 79

80 5 Rozwiązania problemu bezpieczeństwa protokołu BGP Do ochrony takim zagrożeniem może zostać użyty test RPF (ang. Reverse path forward). Polega on na sprawdzeniu adresu źródłowego na podstawie lokalnej informacji routingowej. Na Rys. 5.2 router A posiada wpis w swojej tablicy routingowej wskazujący, że adres routera B jest dostępny za pośrednictwem interfejsu Eth1. Kiedy router A otrzyma pakiet z sieci może porównać jego adres źródłowy z pulą prefiksów dostępną za pośrednictwem wybranego interfejsu. Jeżeli pakiet z danym adresem źródłowym przyszedł z interfejsu, przez który nie prowadzi ścieżka do sieci źródłowej, jest on odrzucany. Router A po otrzymaniu pakietu z interfejsu Eth2 z fałszywym adresem stwierdzi, że ścieżka do tego adresu wykorzystuje interfejs Eth1 i odrzuci pakiet. Głównym ograniczeniem mechanizmu RPF jest nieuwzględnianie ścieżek, które są prawidłowe, ale nie istnieją w lokalnej tablicy routingowej. W przypadku, gdy istnieją dwie ścieżki do danej podsieci (np. scenariusz dual-homed), tylko ścieżka główna jest wpisywana do tablicy routingowej. Rozwiązaniem tego problemu jest wykonywanie sprawdzenia na wszystkich dostępnych ścieżkach do danej podsieci. W tym celu można wykorzystać tzw. białą listę ścieżek (ang. whitelist virtual routing tables), w której umieszczane są ścieżki alternatywne IpSec Kolejnym krokiem do zapewnienia bezpieczeństwa sesji pomiędzy dwoma routerami BGP jest szyfrowanie danych przesyłanego między nimi. Najbardziej rozpowszechnionym mechanizmem szyfrowania w sieci Internet jest IPSec (ang. IP Security). Jest on często używany do tworzenia wirtualnych sieci prywatnych pomiędzy grupą hostów. Mechanizm IPSec określony jest przez zbiór protokołów zapewniających bezpieczeństwo w warstwie sieci. Protokoły te definiują metody szyfrowania i uwierzytelniania nagłówków oraz zawartości pakietów IP. Działają na zasadzie enkapsulacji, tj. oryginalny pakiet IP jest szyfrowany, otrzymuje nowy nagłówek protokołu IPsec i w takiej formie jest przesyłany przez sieć. Mechanizm IPSec wykorzystuje również protokół IKE (ang. Internet Key Exchange), który jest odpowiedzialny za dystrybucję kluczy i uwierzytelnianie stron komunikacji. Mechanizm IPSec można stosować w dwóch trybach. Tryb transportowy polega na umieszczeniu dodatkowego nagłówka IPSec pomiędzy nagłówkami protokołów IP i TCP. 80

81 Dane użytkownika oraz nagłówek TCP są szyfrowane jednak nagłówek IP pozostaje widoczny. Tryb tunelowy zapewnia wyższy poziom ochrony pakiet IP użytkownika jest szyfrowany w całości i enkapsulowany w nowym pakiecie opatrzonym specjalnym nagłówkiem IPn. Mechanizm IPSec gwarantuje bezpieczeństwo sesji BGP zapewnia uwierzytelnianie, integralność oraz poufność danych, chroni przez podsłuchem, podszywaniem się oraz atakiem powtórzeniowym. Jego wykorzystanie do zabezpieczenia danych przesyłanych w ramach protokołu BGP (patrz [12]) jest coraz bardziej powszechne ze względu na popularność protokołów IPSec w sieci Internet. Zapewnia najbardziej kompleksową ochronę sesji łącznie z częściową ochroną przez atakami DOS (ang. Denial of Service) Porównanie metod zwiększających bezpieczeństwo sesji protokołu BGP Rys. 5.3 Porównanie metod zwiększających bezpieczeństwo sesji protokołu BGP Tabela na Rys. 5.3 zawiera porównanie metod zwiększających bezpieczeństwo sesji protokołu BGP. Mechanizm IPSec zapewnia kompleksowa ochronę sesji BGP. Rozwiązanie takie jak uwierzytelnienie MD5 czy metoda GTSM są obecnie powszechnie używane w sieci Internet ze względu na łatwość implementacji i niski koszt. Chronią jednak tylko przez pojedynczymi rodzajami ataków na sesję protokołu BGP i ze względu na duże ograniczenia nie powinny być postrzegane jako długoterminowe rozwiązania problemu bezpieczeństwa sesji BGP. 5.3 Filtrowanie rozgłoszeń protokołu BGP Rozgłoszenia protokołu BGP są filtrowane w celu wykrywania i odrzucania błędnych i potencjalnie szkodliwych informacji. Nie istnieje żaden ogólny mechanizm filtrowania rozgłoszeń BGP. Administratorzy systemów autonomicznych i dostawców ISP korzystają 81

82 5 Rozwiązania problemu bezpieczeństwa protokołu BGP dobrych praktyk, których użycie może znacznie zwiększyć odporność sieci na awarie wywołane błędną konfiguracją lub atakiem. W niniejszym podrozdziale zebrane zostały najważniejsze zasady filtrowania rozgłoszeń używane przez administratorów systemów autonomicznych. Opisany został również mechanizm rejestrów routingu (ang. routing registries), którego wprowadzenie przyczyniłoby się do zwiększenia efektywności filtrowania rozgłoszeń Zasady filtrowania rozgłoszeń BGP Routery BGP powinny odrzucać rozgłoszenia zawierające nieprawidłowe prefiksy. Najczęściej są to: Prefiksy należące do grupy adresów specjalnych DSUA (ang. Documenting Special Use IPv4 Address Blocks) np. adresy interfejsów loopback. Adresy należące do fałszywej przestrzeni adresowej bogons (od ang. bogus podrabiany, fałszywy). Są to adresy i numery ASN, które nie zostały jeszcze przydzielone przez upoważnioną organizację (np. IANA) oraz adresy, które nie powinny wystąpić w danej sieci np. adresy IP należące do prywatnej przestrzeni adresowej pojawiające się w sieci Internet. Raport CIDR 1 (patrz Rys. 5.4) zawiera aktualną listę fałszywych ścieżek i systemów autonomicznych w sieci Internet. Jest on wykorzystywany przez wielu operatorów do filtrowania rozgłoszeń BGP. 1 IPv4 CIDR Report AS2.0, dostępny na stronie [29], generowany jest codziennie na podstawie rejestrów i statystyk organizacji IANA oraz RIR. 82

83 Rys. 5.4 Fragment raportu CIDR z dnia zawierający informacje o fałszywych ścieżkach i numerach ASN w sieci Internet Rozgłoszenia zawierające małe podsieci (mniejsze niż 256 adresów) są w większości przypadków odrzucane przez routery brzegowe w celu zmniejszenia globalnych tablic routingowych i uniknięcia wpływu takich rozgłoszeń na wybór ścieżki (zasada longest prefix match). Ponadto administrator systemu autonomicznego może nałożyć limit na liczbę prefiksów przekazywanych w sesji ebgp przez router z sąsiedniego systemu autonomicznego, po przekroczeniu którego sesja jest zamykana. Zastosowanie tego mechanizmu pozwala uchronić się przez sąsiadami, którzy sztucznie deagregują rozgłaszane prefiksy. Zapobiega także nadmiernemu zużyciu pamięci i wynikającym z niego błędom pracy routera. Systemy autonomiczne dostawców Internetu, którzy świadczą usługi dla swoich klientów (np. systemów autonomicznych, które nie świadczą usług tranzytowych) dysponują wiedzą o swoich klientach i mogą dzięki temu filtrować rozgłaszane przez nich ścieżki z większą dokładnością. Dostawca ISP powinien: Odrzucać ścieżki rozgłaszane przez swoich klientów, jeżeli atrybut As Path zawiera numer ASN innego dostawcy Internetu. Takie rozgłoszenia są w większości przypadków błędne, gdyż rozgłaszają ścieżki tranzytujące ruch przez sieć klienta. Odrzucać ścieżki otrzymane od klienta dla prefiksów, których klient nie posiada. Staranne filtrowanie ruchu przez dostawców Internetu przyczyniłoby się do znacznego zwiększenia bezpieczeństwa routingu międzydomenowego. Wykrycie nieprawidłowej ścieżki 83

84 5 Rozwiązania problemu bezpieczeństwa protokołu BGP jest trudniejsze jeżeli pochodzi ona z odległych systemów autonomicznych. Dodatkowo stworzenie i utrzymanie list filtrów jest utrudnione, gdy klient posiada dużą pulę prefiksów, lub gdy jest ona zmienna. Ponadto klienci dostawcy mogą świadczyć usługi swoim klientom, co jeszcze bardziej utrudnia filtrowanie ruchu. Rozgłoszenia BGP powinny być odrzucane jeżeli zawarte w nich atrybuty ścieżek posiadają błędne lub potencjalnie szkodliwe wartości. System autonomiczny powinien odrzucać rozgłoszenia, które zawierają w wartościach atrybutu As Path numery ASN należące do przestrzeni prywatnej. W celu zabezpieczenia routerów przez wyczerpaniem pamięci lub wystąpieniem błędów oprogramowania należy odrzucać rozgłoszenia zawierające wartości atrybutów As Path z kilkudziesięcioma numerami ASN 1 (patrz [30]). Takie wartości powstają zazwyczaj w skutek błędu konfiguracji lub awarii. W celu zwiększenia bezpieczeństwa system autonomiczny może nadpisać atrybuty BGP, które nie powinny być używane przez jego sąsiadów (ang. defensive programming). Jeżeli system autonomiczny nie zgodził się na wykorzystywanie atrybutu MED, jego router brzegowy może zostać skonfigurowany tak, aby przypisywał wartość 0 dla tego atrybutu dla każdej otrzymanej ścieżki. Niektórzy sąsiedzi mogą oznaczać swoje ścieżki za pomocą atrybutu Community, w celu kontrolowania jak sąsiedni system autonomiczny traktuje daną ścieżkę np. żeby poinstruować odbierający system, aby ten dopisał dodatkowe wartości do atrybutu As Path, przypisał niższą wartość atrybutu Local Pref (żeby traktować ścieżkę jako zapasową) lub żeby filtrować ścieżkę podczas przekazywania rozgłoszeń do innego systemu autonomicznego. Jeżeli sąsiedzi nie mają umowy dotyczącej oznaczania rozgłoszeń za pomocą atrybutu Community, system autonomiczny może odrzucić ścieżki, które zawierają nieoczekiwaną wartość tego atrybutu. W ten sposób zabezpiecza się przed nieuprawnionym wpływaniem przez sąsiedni system na proces wyboru ścieżki lub jej dystrybucji do kolejnych systemów autonomicznych. Reguły filtrowania rozgłoszeń BGP są najbardziej rozpowszechnioną i efektywną metodą zwiększającą bezpieczeństwo routingu międzydomenowego. Większość szkodliwych rozgłoszeń pochodzi od systemów autonomicznych podłączonych do dostawców ISP, którzy nie stosują dobrych praktyk filtrowania rozgłoszeń. 1 W przypadku routerów Cisco nie powinno akceptować się rozgłoszeń z dłuższą wartością atrybutu As Path niż 100, ponieważ mogą powodować wystąpienie błędów w starszych wersjach oprogramowania IOS. Do ograniczenia maksymalnej długości atrybutu As Path w routerach Cisco służy komenda konfiguracyjna bgp maxas-limit [length]. 84

85 Mechanizm ten nie może jednak zastąpić architektury, która zapewniałaby kompleksowe bezpieczeństwo protokołu BGP. Reguły filtrowania mogą odrzucać tylko rozgłoszenia, które są w sposób ewidentny błędne lub szkodliwe. W przypadku ścieżek pochodzących z odległych systemów autonomicznych lub złożonych hierarchii dostawców statyczne reguły filtrowania są niewystarczające. Dodatkowym ograniczeniem dokładnego filtrowania ruchu są ograniczone zasoby urządzeń Rejestry routingu Mechanizmem, który mógłby znacząco zwiększyć bezpieczeństwo routingu międzydomenowego są rejestry routingu. Obecnie nie ma możliwości sprawdzenia czy informacja routingowa otrzymana od systemu autonomicznego jest poprawna. Posiadanie współdzielonej, globalnej informacji o prawidłowym routingu znacznie ułatwiłoby wykrywanie i odrzucanie nieprawidłowych ścieżek. W założeniu rejestr routingu przechowuje informacje dotyczące prawidłowego routingu. Posiada szczegółowe dane dotyczące systemów autonomicznych tj. posiadane przez nie prefiksy, spis połączeń między systemami autonomicznymi, polityki routingowe. Informacje zawarte w rejestrach mogłyby być wykorzystywane w celu walidacji otrzymanych rozgłoszeń. Na ich podstawie operator tworzyłby precyzyjne i skuteczniejsze filtry routingowe (np. dostawca Internetu mógłby na podstawie informacji umieszczonej przez swojego klienta w rejestrze skonstruować filtr, który przepuszczałby jedynie zarejestrowane przez klienta ścieżki). Filtrowanie ruchu na podstawie rejestrów routingowych jest możliwe tylko wtedy, gdy zapewnione jest bezpieczeństwo i rzetelność informacji umieszczonych w rejestrze. Ponadto wymagane jest uwierzytelnianie (weryfikacja tożsamości) i autoryzacja (czy organizacja ma prawo do rozgłaszania danej puli prefiksów) organizacji, które rozgłaszają informacje routingowe. Problemem, który utrudnia stworzenie globalnych rejestrów routingowych jest niechęć organizacji do udostępniania informacji o wewnętrznej topologii sieci i stosowanych regułach routingowych. Rejestry tworzone przez społeczności nie są powszechnie wykorzystywane ze względu na brak zaufania i zagrożenie manipulacją. Informacje w nich przechowywane z czasem stają się nieaktualne z powodu braku motywacji do ich aktualizowania. Skutecznym rozwiązaniem byłoby wskazanie organizacji (zajmującej się przydzielaniem przestrzeni adresowej i rejestracją systemów autonomicznych) 85

86 5 Rozwiązania problemu bezpieczeństwa protokołu BGP odpowiedzialnej za stworzenie i utrzymywanie autorytatywnego rejestru. Wiele z obecnych propozycji zabezpieczenia protokołu BGP bazuje na implementacji rejestrów routingowych i infrastruktury PKI. Nad stworzeniem infrastruktury bazującej na certyfikatach służących do autoryzacji pochodzenia ścieżek pracuje organizacja AP- NIC. Podobne usługi świadczą organizacje ARIN, RIPE oraz LACNIC. Jednak stworzenie i utrzymanie kompletnego i dokładnego rejestru routingowego stanowi wciąż wyzwanie. 5.4 Zintegrowane systemy bezpieczeństwa protokołu BGP Obecnie stosowane metody zwiększające bezpieczeństwo protokołu BGP mają ograniczone możliwości. Są powszechnie używane w sieci Internet ze względu na łatwość implementacji i niski koszt jednak chronią tylko przez wybranymi zagrożeniami. Z tego względu istnieje potrzeba wprowadzenia zintegrowanego systemu bezpieczeństwa, który zapewniłby kompleksowe bezpieczeństwo protokołu BGP. System ten powinien umożliwiać potwierdzenie autentyczności pochodzenia rozgłoszenia oraz być w stanie stwierdzić jego zgodność z topologią sieci. W niniejszym podrozdziale przedstawione zostały trzy propozycje systemów bezpieczeństwa. Pierwsze dwa w różnym stopniu rozszerzają protokół BGP o mechanizmy zapewniające bezpieczeństwo. Trzeci system jest niezależny od protokołu routingu, jednak można go wykorzystać do zabezpieczenia w sposób rozproszony protokołu BGP S-BGP Mechanizm S-BGP (ang. Secure Border Gateway Protocol, patrz [15]) był pierwszym zintegrowanym rozwiązaniem problemu bezpieczeństwa przeznaczonym dla protokołu BGP. W celu weryfikacji atrybutów ścieżki przesyłanych w wiadomości BGP UPDATE wykorzystuje podpisy cyfrowe i powiązane z nimi certyfikaty. W tym celu do każdego systemu autonomicznego przypisana jest para kluczy kryptograficznych (publiczny i prywatny). Za zarządzenie kluczami odpowiada infrastruktura PKI. Informacje przesyłane w wiadomości S-BGP (prefiks, numer ASN, atrybuty w szczególności atrybut As Path) są zabezpieczane za pomocą podpisu cyfrowego wykonanego przy użyciu klucza prywatnego nadawcy. Odbiorca wiadomości może je zweryfikować wykorzystując odpowiedni klucz publiczny nadawcy. Mechanizm S-BGP wykorzystuje informacje o posiadanych przez system autono- 86

87 miczny przestrzeniach adresowych i numerach ASN w celach weryfikacji uprawnień do rozgłaszania prefiksów. Mechanizm S-BGP wykorzystuje dwa rodzaje certyfikatów: Certyfikat adresów potwierdza posiadanie przez dany system autonomiczny rozgłaszanych prefiksów. Jest podpisywany przez podmiot odpowiedzialny za alokacje adresów i rozpowszechniany poza protokołem BGP. Przy pomocy klucza publicznego tego podmiotu odbiorca wiadomości może zweryfikować czy źródłowy system autonomiczny miał prawo rozgłaszać daną pulę prefiksów. Certyfikat ścieżek przenoszony w wiadomości S-BGP w nowym atrybucie zmodyfikowanej wiadomości UPDATE. Certyfikat jest podpisywany przez każdy system autonomiczny przy przekazaniu wiadomości. Pozwala to na weryfikację czy numery systemów autonomicznych znajdują się w odpowiedniej kolejności i czy żadne numery ASN nie zostały dodane lub usunięte z atrybutu As Path. Łańcuch podpisów może być zweryfikowany przy użyciu klucza publicznego każdego systemu autonomicznego, który znajduje się na ścieżce. Rys. 5.5 Rozgłaszanie ścieżki przy wykorzystaniu mechanizmu S-BGP Na Rys. 5.5 system autonomiczny rozgłasza podsieć /24. Pobiera z rejestru RIR certyfikat adresu podpisany kluczem prywatnym rejestru. Certyfikat zawiera pule rozgłaszanych adresów oraz numer ASN, do którego należy prefiks. System przed wysłaniem wiadomości UPDATE z otrzymanym certyfikatem dodaje do wiadomości identyfikator sąsiedniego systemu autonomicznego AS 65001, jako systemu, który 87

88 5 Rozwiązania problemu bezpieczeństwa protokołu BGP może rozgłaszać ścieżkę dalej. Całość podpisuje swoim kluczem prywatnym. Tak samo postępuje system autonomiczny dodając identyfikator systemu i podpisując wiadomość UPDATE swoim kluczem prywatnym przed przekazaniem wiadomości. Mechanizm S-BGP zapewnia duży poziom bezpieczeństwa jednak jego wymagania na zasoby obliczeniowe i czas obliczeń stanowią istotną barierę w implementacji. Zarówno podpisywanie dużej ilości danych jak i weryfikacja zagnieżdżonych podpisów powoduje duże zużycie zasobów obliczeniowych. Przenoszenie certyfikatów wewnątrz wiadomości BGP zwiększa ilość przesyłanych informacji w sieci. Poza ograniczeniami związanymi z zasobami wykorzystanie mechanizmu zwiększa dwukrotnie czas konwergencji sieci w stosunku do niezabezpieczonej wersji protokołu BGP. W celu optymalizacji mechanizmu proponuje się szereg usprawnień: Tylko ścieżki wybrane jako podstawowe (ang. primary) mogą być poddawane weryfikacji. Router może przechowywać wynik obliczeń w pamięci podręcznej i wykorzystywać je do weryfikacji kolejnych wiadomości. Router powinien posiadać moduły zapewniające sprzętowe wsparcie obliczeń wykonywanych podczas podpisywania danych i weryfikacji podpisów. W przypadku przekazywania tej samej wiadomości UPDATE do kilku sąsiednich systemów autonomicznych router może stworzyć i podpisać jedną wiadomość UPDATE przeznaczoną dla wszystkich tych systemów jednocześnie (przez dodanie kilku numerów ASN do certyfikatu jako następny krok na ścieżce) sobgp Protokół sobgp (ang. Secure Origin Border Gateway Protocol, patrz [16]) stanowi rozszerzenie protokołu BGP. Został zaproponowany przez organizację IETF. Jest opisany w formie draftów, z których każdy opisuje oddzielną część specyfikacji protokołu i operacji sobgp. Protokół sobgp pozwala na weryfikację pochodzenia informacji routingowej, ustalanie polityk związanych z prefiksami przez sieć źródłową oraz sprawdzenie czy istnieje co najmniej jedna ścieżka do podsieci źródłowej. 88

89 Protokół sobgp zakłada istnienie infrastruktury PKI, która zarządza trzema rodzajami certyfikatów: EntityCert przypisuje unikalny klucz publiczny każdemu routerowi sobgp. PolicyCert opisuje połączenia do systemu autonomicznego (lokalną topologia sieci) i polityki związane z rozgłaszanymi prefiksami. Router sobgp, który otrzymał certyfikat przechowuje informacje w nim zawarte i wykorzystuje je do konstrukcji bazy danych połączeń, która odzwierciedla sieć widzianą przez router. AuthCert opisuje zbiór systemów autonomicznych, które mają prawo rozgłaszać dane prefiksy. Protokół sobgp wprowadza nowy typ wiadomości SECURITY. Wiadomości tego typu wykorzystywane są do transmisji wszystkich informacji związanych z bezpieczeństwem pomiędzy routerami sobgp. Routery sobgp wykorzystują bazę danych połączeń w sieci do walidacji otrzymanych ścieżek. Każdy system autonomiczny podpisuje i rozgłasza swoją lokalną topologię (m. in. listę sąsiednich systemów autonomicznych) za pomocą certyfikatu PolicyCer t. Te informacje są wykorzystywane do stworzenia bazy danych z połączeniami w sieci i odpowiadającego jej skierowanego grafu, którymi powinien stale dysponować każdy router sobgp. Baza danych jest wykorzystywana do weryfikacji otrzymanych ścieżek wiadomość UPDATE zawierająca ścieżkę niezgodną z utworzonym grafem jest uznawana za błędną i odrzucana. Na Rys. 5.6 przedstawiono przykładowe informacje zawarte w certyfikatach Policy- Cert oraz zbudowany na ich podstawie graf sieci. 89

90 5 Rozwiązania problemu bezpieczeństwa protokołu BGP Rys. 5.6 Graf protokołu sobgp zbudowany na podstawie informacji o lokalnych połączeniach systemów autonomicznych Graf sieci i odpowiadająca mu baza danych są statyczne informacje w nich zawarte zmienią się tylko w przypadku otrzymania nowego certyfikatu PolicyCert. Z tego względu niezbędna jest infrastruktura, która zapewni, że aktualizacja grafu sieci jest zsynchronizowana pomiędzy systemami autonomicznymi. Ponadto mechanizmy sobgp nie chronią przez podrobionymi ścieżkami, które są zgodne z topologią sieci. Protokół sobgp i związana z nim infrastruktura mogą być wprowadzone w różnych wariantach. Operator może m. in. wybrać czy ścieżki mają być weryfikowane przed wprowadzeniem do tablicy routingowej, aby zwiększyć bezpieczeństwo, lub dopiero po wpisaniu do tablicy, co pozwala na zmniejszenie czasu konwergencji. Kolejnym wyborem jest sposób weryfikacji ścieżek poprawność ścieżki może być określana na podstawie porównania jej w całości z przechowywanym grafem lub jedynie przez sprawdzenie jej początkowych kroków. Mnogość wariantów sprawia, że protokół sobgp jest elastyczny i stosunkowo łatwy do wprowadzenia jednak różne tryby pracy powodują problemy z kompatybilnością IRV Mechanizm IRV (ang. Interdomain Route Validation, patrz [17]) zakłada, że każdy system autonomiczny posiada lokalny serwer IRV, który sprawdza czy otrzymana informacja routingowa jest poprawna. Lokalny serwer IRV weryfikuje poprawność informacji poprzez 90

91 sekwencję zapytań do innych serwerów IRV znajdujących się w systemach autonomicznych obecnych na otrzymanej w rozgłoszeniu ścieżce (patrz Rys. 5.7). Mechanizm IRV ma na celu zapewnienie bezpieczeństwa protokołu BGP w sposób rozproszony. W odróżnieniu od opisanych w poprzednich podrozdziałach rozwiązań jest niezależny od protokołu routingowego. Rys. 5.7 Zapytanie IRV sprawdzające poprawność informacji routingowej Algorytm decydujący o tym kiedy i w jaki sposób ma być sprawdzana informacja zawarta w wiadomości UPDATE jest wybierany przez system autonomiczny. Serwer IRV może wykonywać zapytanie do każdego systemu autonomicznego na ścieżce lub wybrać jedynie podzbiór systemów bazując na wcześniej uzyskanych informacjach (np. systemy autonomiczne, które są znane z tego, że dostarczają zaufane informacje routingowe nie muszą być odpytywane). Wykonywanie zapytań okresowo, w przypadku podejrzanych rozgłoszeń lub tylko do podzbioru systemów autonomicznych pozwala osiągnąć lepszą wydajność. W celu zwiększenia wydajności, możliwe jest również użycie pamięci podręcznej do przechowywania wyników poprzednich zapytań i wykorzystywanie ich do weryfikacji aktualnych rozgłoszeń. Serwery IRV są podobne do rejestrów routingu jednak zarządzają informacjami pochodzącymi tylko z macierzystego systemu autonomicznego. Takie podejście pozwala na sprawowanie lepszej kontroli nad danymi i ich bieżące uaktualnianie. Do zabezpieczenia komunikacji pomiędzy serwerami IRV wykorzystywane są powszechne w sieci Internet 91

92 5 Rozwiązania problemu bezpieczeństwa protokołu BGP mechanizmy zabezpieczania warstwy sieciowej (np. IPSec) i transportowej (np. TLS) pozwalają one zapewnić autentyczność, integralność i poufność zapytań i ich wyników. Serwery IRV mogą za pomocą odpowiedzi na otrzymane zapytania sterować dostępem innych systemów autonomicznych do ich wewnętrznych poufnych informacji (polityki, struktura sieci, relacje z sąsiednimi systemami autonomicznymi). Głównym ograniczeniem mechanizmu IRV jest potrzebna zapewnienia połączenia i routingu między serwerami IRV znajdującymi się wewnątrz systemów autonomicznych. W tym celu zaleca się współpracę między systemami autonomicznymi i wykorzystanie statycznych ścieżek do serwerów IRV Porównanie metod Tabela na Rys. 5.8 przedstawia porównanie omówionych systemów bezpieczeństwa protokołu BGP. Kolumna W użyciu wskazuje czy system jest używany obecnie przez operatorów. Pole Metoda określa czy rozwiązanie bazuje na mechanizmach kryptograficznych czy usługach wykrywających anomalie. Usługi bezpieczeństwa obejmują: uwierzytelnienie topologii sprawdzenie czy ścieżki są zgodne z rzeczywistą topologią sieci uwierzytelnienie ścieżek sprawdzenie czy otrzymane ścieżki nie zostały zmienione podczas przekazywania rozgłoszenia uwierzytelnienie pochodzenia sprawdzenie czy źródłowy system autonomiczny miał prawo rozgłaszać daną pulę prefiksów Rys. 5.8 Porównanie zintegrowanych systemów bezpieczeństwa protokołu BGP Systemem zapewniającym największy poziom bezpieczeństwa protokołu BGP jest system S-BGP, jednak jego wymagania na zasoby obliczeniowe i czas obliczeń stanowią 92

93 istotna barierę w implementacji. System sobgp posiada wiele wariantów implementacji jednak nie chroni przed podrobionymi ścieżkami, które są zgodne z topologią sieci. System IVR jest niezależny od protokołu routingowego i może być wykorzystany do zapewnienia kompleksowego bezpieczeństwa protokołu BGP. Wykorzystanie przedstawionych systemów bezpieczeństwa protokołu BGP z pewnością przyczyniłoby się do poprawy bezpieczeństwa routingu międzydomenowego. Istnieje jednak wiele barier, które uniemożliwiają ich wykorzystanie przez operatorów. Największą z nich jest skala obecnej sieci Internet. Ze względu na ilość urządzeń sieciowych system bezpieczeństwa musi być wprowadzany w sposób ewolucyjny. Konieczne jest również zapewnienie współpracy nowych mechanizmów z obecną wersją protokołu BGP. Rosnąca z roku na rok liczba systemów autonomicznych i wielkość tablic routingowych sprawia, że rozwiązanie bezpieczeństwa musi być wydajne i skalowalne. Systemy bezpieczeństwa wymagają dodatkowej mocy obliczeniowej (m. in. na potrzeby kryptografii symetrycznej i asymetrycznej), co wiąże się z potrzebą ulepszenia lub wymiany obecnych urządzeń sieciowych. Ponadto niezależnie od wybranego rozwiązania system bezpieczeństwa wprowadza dodatkową złożoność do infrastruktury sieciowej i może znacząco wpłynąć na konwergencję sieci. Większość z przedstawionych systemów bazuje na rejestrach zawierających rzetelne informacje o systemach autonomicznych, posiadanych przez nie pulach prefiksów i dostępnych w sieci prawidłowych ścieżkach. Stworzenie i utrzymanie kompletnego i dokładnego rejestru routingowego stanowi wciąż wyzwanie i powinno być pierwszym krokiem w kierunku zwiększania bezpieczeństwa routingu międzydomenowego.

94

95 6 Koncepcja laboratoriów 6.1 Ćwiczenia laboratoryjne Studenci w ramach przedmiotów prowadzonych w Instytucie Telekomunikacji poznają podstawowe cechy i zastosowanie protokołu BGP. Złożoność mechanizmów i konfiguracji protokołu wymaga jednak styczności z nim w rzeczywistym środowisku sieciowym. Aby umożliwić studentom praktyczne wykorzystanie wiedzy zdobytej podczas wykładów oraz głębsze zapoznanie się z wybranymi zagadnieniami związanymi z routingiem międzydomenowym, powstał pomysł stworzenia zestawu ćwiczeń laboratoryjnych. Laboratorium składa się z zestawu czterech ćwiczeń. Trzy pierwsze ćwiczenia: Multihoming z wykorzystaniem łączy do jednego ISP, Multihoming z wykorzystaniem łączy do dwóch ISP, BGP/MPLS VPN stopniowo rozszerzają tematykę związaną z konfigurowaniem protokołu BGP. Obejmują konfigurowanie mechanizmów kształtowania rozpływu ruchu na styku sieci klienta z siecią dostawcy ISP. Ich scenariusze zostały wstępnie opracowane przez Piotra Nowaka i Piotra Zwierzchowskiego w ramach pracy magisterskiej w Instytucie Telekomunikacji (patrz [21]). Ćwiczenie czwarte Atak polegający na przejęciu puli prefiksów umożliwia studentom zapoznanie się z wybranymi zagrożeniami routingu międzydomenowego, mechanizmami zabezpieczenia się przed atakami, jak również ze środkami i metodami implementowania tych mechanizmów w routerach. Początkowo ćwiczenia miały być realizowane w laboratorium z wykorzystaniem rzeczywistych routerów. Takie rozwiązanie wprowadza pewne ograniczenia związane ze zbyt małą liczbą routerów i potrzebą ich wstępnego konfigurowania i zestawiania topologii przed każdym ćwiczeniem. Weryfikacja i ocena ćwiczeń miała odbywać się na podstawie zapisanej w pliku konfiguracji routerów oraz zawartości tablic routingu. W przypadku bardziej złożonych konfiguracji taki sposób byłby trudny do zrealizowania. W celu wyeliminowania powyższych trudności i ograniczeń zaprojektowaliśmy i zbudowaliśmy infrastrukturę do przeprowadzenia omawianych ćwiczeń laboratoryjnych. Infrastruktura składa się z emulatora routerów oraz aplikacji, której podstawowym zadaniem jest ułatwienie konfigurowania oraz automatyczna weryfikacja i ocena wykonania laboratorium. Ponadto aplikacja zawiera funkcje, które pozwalają urozmaicić ćwiczenie i rozszerzyć jego zakres o praktyczne wykorzystanie protokołu SNMP i bazy informa- 95

96 6 Koncepcja laboratoriów cji zarządzania (MIB). Zaproponowany emulator routerów (patrz załącznik A) pozwala na zorganizowanie laboratoriów przy minimalnym nakładzie środków i czasu. Stwarza również możliwości rozszerzenia zakresu ćwiczeń laboratoryjnych o scenariusze związane z rozpływem ruchu międzydomenowego na styku pomiędzy sieciami ISP, które ze względu na niewystarczającą liczbę routerów nie byłyby możliwe do realizacji na rzeczywistym sprzęcie. W ramach prac nad laboratorium sprawdzono poprawność ćwiczeń laboratoryjnych na wybranym emulatorze routerów oraz przetestowano możliwości ich przeprowadzenia z wykorzystaniem stworzonej aplikacji. Ponadto ćwiczenie pierwsze Multihoming z wykorzystaniem łączy do jednego ISP, dotyczące najbardziej podstawowego zastosowania mechanizmów protokołu BGP, zostało zaadaptowane na potrzeby naszego środowiska i wykorzystane do przeprowadzenia testowego laboratorium z udziałem studentów. Na podstawie ćwiczeń pierwszego i czwartego zostały przygotowane instrukcje do laboratorium (patrz załączniki B i C) zawierają one ograniczony, w celu zwiększenia trudności ćwiczenia, opis konfigurowania routerów a także sposoby weryfikacji konfiguracji mechanizmów z wykorzystaniem stworzonej aplikacji. Do instrukcji do laboratorium dołączona jest również instrukcja do aplikacji (patrz załącznik D), która zawiera szczegółowy opis funkcji programu potrzebnych do wykonania ćwiczeń. Wszystkie ćwiczenia zbudowane są według wspólnego schematu. W pierwszej części opisany jest cel laboratorium, założenia projektowe oraz przedstawiony jest scenariusz ćwiczenia zawierający topologie połączeń. Kolejna część dotyczy implementowania poszczególnych mechanizmów. Proces konfigurowania każdego mechanizmu jest opisany osobno. Po opisie mechanizmu, przestawiona jest lista typów komend, które należy wprowadzić do konsoli routerów oraz opis oczekiwanych rezultatów. Na końcu sekcji dotyczącej konkretnego mechanizmu przedstawiony jest proces weryfikacji działania routerów, który należy przeprowadzić przed przejściem do kolejnego etapu konfigurowania. Dwa pierwsze ćwiczenia dotyczą konfigurowania mechanizmów kształtowania rozpływu ruchu na styku sieci klienta z siecią dostawcy ISP. Styk klienta z dostawcą to typowe miejsce wykorzystania mechanizmów protokołu BGP. Konfiguracja routerów działających w tym przypadku jest łatwiejsza w systematyzacji niż konfiguracja routerów na styku dwóch sieci operatorskich. Ćwiczenie trzecie obejmuje konfigurowanie połączeń VPN w oparciu o technikę BGP/MPLS. Usługa VPN jest obecnie jedną z najważniejszych dzia- 96

97 łalności dostawców ISP i umiejętność konfigurowania tego typu połączeń może okazać się pożądaną przez pracodawcę umiejętnością. Ostatnie ćwiczenie dotyczy wybranych zagrożeń bezpieczeństwa routingu międzydomenowego oraz dostępnych mechanizmów zwiększających bezpieczeństwo protokołu BGP. Ćwiczenie pierwsze Multihoming z wykorzystaniem łączy do jednego ISP zakłada sytuację, gdy klient połączony jest z jednym dostawcą Internetu dwoma łączami. Zadaniem studentów jest wysterowanie ruchu między siecią kliencką a siecią dostawcy w taki sposób, aby łącze pierwsze było łączem podstawowym dla ruchu wychodzącego i przychodzącego, natomiast łącze drugie było łączem zapasowym i było używane tylko w przypadku awarii łącza podstawowego. Studenci najpierw konfigurują interfejsy routerów oraz sesje protokołu BGP (ibgp i ebgp). Następnie wykorzystują niestandardowy mechanizm Cisco next-hop-self, aby zapewnić dostępność adresów Next Hop. Kolejnym zadaniem jest rozgłoszenie sieci oraz wysterowanie ruchu wchodzącego i wychodzącego z sieci klienckiej przy wykorzystaniu atrybutów wiadomości UPDATE protokołu BGP. W tym celu używane są atrybuty Local Pref oraz Multi Exit Disc a ich modyfikacja odbywa się przy pomocy mechanizmu Route map. Po każdym etapie konfiguracji studenci mogą sprawić jej poprawność przy pomocy opisanej w instrukcji metody weryfikacji udostępnianej przez aplikację. Po wykonaniu laboratorium aplikacja automatycznie dokonuje sprawdzenia i oceny konfiguracji a także wyświetla raport z przeprowadzonego laboratorium. Ćwiczenie drugie Multihoming z wykorzystaniem łączy do dwóch ISP stanowi rozszerzenia ćwiczenia pierwszego. W tym przypadku klient posiada dwa łącza do dwóch różnych dostawców Internetu. Studenci muszą wysterować ruch w analogiczny sposób jak w ćwiczeniu pierwszym. Ćwiczenia ma na celu przedstawić zalety oraz trudności w konfigurowaniu wynikające z połączenia do dwóch dostawców. Ćwiczenie trzecie BGP/MPLS VPN pozwala studentom na poznanie procesu konfigurowania połączeń VPN w oparciu o protokoły BGP i MPLS. Celem ćwiczenia jest skonfigurowanie połączenia VPN pomiędzy dwoma routerami klienckimi. Ćwiczenie czwarte Atak polegający na przejęciu puli prefiksów jest związane z bezpieczeństwem protokołu BGP. Celem ćwiczenia jest skonfigurowanie routerów brzegowych systemów autonomicznych w oparciu o protokół BGP oraz zasymulowanie ataku polegającego na przejęciu puli prefiksów. Atak ten polega na wykorzystaniu rozgłoszenia 97

98 6 Koncepcja laboratoriów BGP zawierającego bardziej specyficzną maskę adresu niż rozgłoszenie pochodzące z oryginalnego systemu autonomicznego. O skuteczności ataku decyduje reguła longest prefix match, która jest standardowo implementowaną zasadą na poziomie routingu IP. Studenci najpierw konfigurują interfejsy routerów oraz sesje protokołu BGP (ebgp). Kolejnym zadaniem jest rozgłoszenie sieci przez oryginalny system autonomiczny oraz przez wrogi system dokonujący przejęcia puli prefiksów. Na koniec ćwiczenia została przedstawiona propozycja zabezpieczenia się przed atakiem przejęcia puli prefiksów. W tym celu można wykorzystać mechanizm prefix-list, który służy do filtrowania ścieżek. Studenci muszą zdefiniować listę prefiksów, które mają być odrzucane przez router a następnie zastosować ją do sąsiedniego routera BGP, który w sposób nieuprawniony te prefiksy rozgłasza. Po każdym etapie konfiguracji studenci mogą sprawić jej poprawność przy pomocy opisanej w instrukcji metody weryfikacji udostępnianej przez aplikację. 6.2 Opis aplikacji Architektura rozwiązania Na Rys. 6.1 znajduje się szkic architektury zaprojektowanego środowiska laboratoryjnego. Aplikacja, wraz z interfejsem graficznym użytkownika, stanowi jego najistotniejszy element. Kolejnym elementem środowiska jest emulator routerów Dynamips, wraz z konsolą zarządzania Dynagen. Jest to element opcjonalny co oznacza że aplikacja może również współpracować z rzeczywistymi routerami Cisco. 98

99 Rys. 6.1 Uproszczona architektura środowiska laboratoryjnego Założenia projektowe Jedyną częścią środowiska widoczną dla użytkownika, jest interfejs graficzny aplikacji. Końcowy efekt i ogólne wrażenie pozostające po wykonaniu laboratorium będzie więc ściśle powiązane z jej odbiorem. Mając to na uwadze, należało zadbać o to, by program był wydajny i wizualnie atrakcyjny. Kolejnym warunkiem powodzenia projektu związanego z dydaktyką, jest jego przejrzystość i prostota. Aplikacja powinna pozwolić studentom skoncentrować się na zagadnieniach omawianych na laboratorium, a nie na obsłudze interfejsu aplikacji. Wymogiem nadanym przez promotora pracy, stanowiącym duże ułatwienie dla prowadzącego ćwiczenie, jest możliwość automatycznej weryfikacji i oceny wykonania laboratorium. Było to najtrudniejsze zadanie projektowe. Jednocześnie, najbardziej wyróżniające opracowane przez nas środowisko. Dla celów automatycznej weryfikacji, zdecydowaliśmy się na zastosowanie protokołu SNMP. Jest to rozwiązanie, które w pełni pokrywa potrzeby, nawet bardzo skomplikowanych testów weryfikujących, a dodatkowym jego atutem jest fakt, że protokół SNMP jest szeroko omawiany na przedmiocie Zarządza- 99

100 6 Koncepcja laboratoriów nie Sieciami Telekomunikacyjnymi. Zatem poza tematyką ściśle związaną ze scenariuszem laboratoryjnym, studenci mogą zaznajomić się w praktyce z wykorzystaniem protokołu SNMP, a także poznać strukturę drzewa MIB dla konfigurowanych przez nich protokołów sieciowych Funkcjonalność aplikacji Zaimplementowana przez nas funkcjonalność pozwala na wprowadzenie imion i nazwisk studentów w grupie laboratoryjnej. Program, po zatwierdzeniu danych grupy, zapamiętuje czas uruchomienia laboratorium, co w przyszłości może służyć czasowemu ograniczeniu pracy w laboratorium lub służyć jako informacja statystyczna. Po uruchomieniu wyświetlana jest topologia fizyczna urządzeń sieciowych i połączeń między nimi. W celu przejrzystego ukazania topologii, plik konfiguracyjny określa rozmieszczenie routerów na podglądzie. Po wybraniu dowolnego elementu (routera, interfejsu, podsieci) na podglądzie graficznym, możemy w szybki sposób odczytać podstawową konfigurację urządzeń na panelach informacyjnych. Za pomocą pojedynczego przycisku, użytkownik jest w stanie uzyskać zdalny dostęp do wybranego routera przez Telnet, bez konieczności wpisywania adresu sieciowego (jest on zapisany w pliku konfiguracyjnym). Program posiada funkcjonalność przeglądarki drzewa MIB. Panel z drzewem MIB pozwala łatwo przeszukiwać obiekty, bez konieczności znajomości ich identyfikatorów OID. Ikony przy obiektach określają ich typ. Po wybraniu obiektu do jego typu dostosowywane jest zapytanie SNMP. Dla zapytania SNMP gettable, przewidziana jest odrębna forma prezentacji danych, umożliwiająca praktyczne przeglądanie dużych tablic MIB. Konsola programu poza wyświetlaniem wyników zapytań SNMP, informuje użytkownika o wszelkich nieprawidłowościach występujących w trakcie wykonywania laboratorium. Przy zagadnieniach związanych ze sterowaniem rozpływem ruchu, przydatnym narzędziem jest trasowanie ścieżki. Funkcja określana w aplikacji terminem traceroute pozwala na graficzne ukazanie drogi pakietów przez badaną sieć. Moduł weryfikacji wykonania laboratorium bazuje na wykonaniu serii zapytań SNMP, zdefiniowanej w pliku konfiguracyjnym. Pozwala ona na rzetelną ocenę pracy studentów. Po wykonaniu testów, aplikacja wyświetla proponowaną ocenę. Użytkownik może zapoznać się z popełnionymi błędami (ich opis i wartości oczekiwane poszczególnych zmiennych 100

101 są wyświetlane w panelu tekstowym). Gdy użytkownik zdecyduje się na zakończenie laboratorium, generowany jest raport zawierający dane dotyczące grupy laboratoryjnej, czas wykonywania ćwiczenia, szczegółowe informacje dotyczące poszczególnych testów i wynik końcowy. Program posiada panel pozwalający na wielokrotne wczytywanie plików wejściowych różnych scenariuszy (z formatu XML) bez konieczności ponownego uruchamiania aplikacji. Interfejs użytkownika możne być dostosowywany do przeprowadzanego ćwiczenia. Wszystkie funkcjonalności są wydzielone w postaci osobnych paneli, których wyświetlaniem można dowolnie sterować w zależności od wymagań ćwiczenia Propozycje rozwoju środowiska laboratoryjnego W trakcie pracy nad aplikacją, a także podczas przeprowadzania przykładowego laboratorium, rozważaliśmy możliwe kierunki rozwoju programu. Spośród wszystkich pomysłów, najbardziej interesującym jest stworzenie rozbudowanej platformy do tworzenia scenariuszy laboratoryjnych, możliwych do przeprowadzenia na istniejącej już części aplikacji. W ramach platformy powstałby edytor scenariuszy, pozwalający na graficzne tworzenie topologii nowego laboratorium i zapisanie jej w formie pliku konfiguracyjnego przeznaczonego dla emulatora i aplikacji. Kolejnym komponentem platformy byłby generator testów weryfikujących, działający w oparciu o informacje pobrane np. z pliku runningconfig routerów. Przeglądarka MIB wymagałaby uelastycznienia w postaci automatycznego wczytywania dowolnych modułów drzewa MIB. Pozwoliłoby to tworzyć scenariusze laboratoryjne obejmujące zagadnienia związane z dowolnymi protokołami i technikami sieciowymi. Inne udoskonalenia projektu, obejmowałyby implementację polecenia SNMP setrequest. Wówczas niektóre zmiany w konfiguracji można będzie wprowadzać bezpośrednio przez aplikację. Kolejnym rozszerzeniem byłaby implementacja obsługi powiadomień trap. Przydatną funkcją byłaby możliwość automatycznego wysłania raportu z przeprowadzonego laboratorium w postaci zaszyfrowanej, na pocztę elektroniczną osoby odpowiedzialnej za prowadzenie laboratorium.

102

103 Podsumowanie W pracy przedstawiono zasady wykorzystania protokołu BGP do sterowania rozpływem ruchu międzydomenowego. Przeprowadzono szczegółową analizę podatności protokołu BGP na ataki wraz ze wskazaniem przyczyn ich występowania. Ataki wykorzystujące luki bezpieczeństwa BGP, zostały sklasyfikowane w zależności od ich celów i sposobów przeprowadzania. Opisano metody obrony przed atakami, wynikające ze specyfikacji protokołu lub z implementowanych w routerach BGP mechanizmów ochronnych. Obecnie wykorzystywane mechanizmy zwiększające bezpieczeństwo protokołu BGP mają ograniczone możliwości i są mało efektywne w przypadku bardziej złożonych i wyrafinowanych ataków. W związku z tym, opisane zostały propozycje kompleksowego zabezpieczenia routingu międzydomenowego poprzez wprowadzenie zintegrowanego systemu bezpieczeństwa protokołu BGP opartego na rejestrach routingowych. W pracy zebrano również zbiór dobrych praktyk wykorzystywanych przez administratorów systemów autonomicznych i dostawców ISP, których powszechne i konsekwentne używanie może znacznie zwiększyć odporność sieci na awarie wywołane błędną konfiguracją lub atakiem. Praktycznym uzupełnieniem w/w zagadnień jest stworzone ćwiczenie laboratoryjne dotyczące bezpieczeństwa protokołu BGP, które umożliwi studentom zapoznanie się z wybranymi zagrożeniami routingu międzydomenowego oraz mechanizmami zabezpieczenia się przed atakami. W celu realizacji nowego ćwiczenia niezbędne było rozbudowanie oraz uelastycznienie istniejącej infrastruktury laboratorium. Jej wstępna wersja powstała w ramach pracy inżynierskiej autorów (patrz [22]). Infrastruktura składa się z emulatora routerów oraz aplikacji do przeprowadzania i automatycznej oceny wykonania ćwiczeń laboratoryjnych. Aplikacja została wzbogacona o funkcje umożliwiające realizację różnorodnych scenariuszy dotyczących routingu międzydomenowego. Ponadto przeorganizowano jej strukturę i zwiększono efektywność (patrz załącznik E). Wykorzystane w trakcie pracy inżynierskiej ćwiczenia laboratoryjne zostały uporządkowane i ujednolicone w oparciu o wielokrotnie przeprowadzone ćwiczenie testowe ( Multihoming z wykorzystaniem łączy do jednego dostawcy ISP ) z udziałem studentów przedmiotu Zarządzanie Sieciami Telekomunikacyjnymi. Aplikacja wraz ze stworzonymi ćwiczeniami może zostać wykorzystana w ramach laboratorium z przedmiotów prowadzonych w Instytucie Telekomunikacji. Ćwiczenia wy- 103

104 konywane z użyciem programu, umożliwią studentom głębsze poznanie wybranych mechanizmów związanymi z routingiem międzydomenowym, jak również z metodami implementowania tych mechanizmów w routerach. Ponadto aplikacja zawiera funkcje, które pozwalają urozmaicić ćwiczenie i rozszerzyć jego zakres o praktyczne wykorzystanie protokołu SNMP i bazy informacji zarządzania (MIB). Zaproponowany emulator routerów pozwala na zorganizowanie laboratoriów przy minimalnym nakładzie środków i czasu. Autorzy przewidują możliwość rozwoju stworzonej aplikacji. Jedną z koncepcji jest utworzenie rozbudowanej platformy służącej do projektowania ćwiczeń laboratoryjnych. Obejmowałaby ona interfejs pozwalający na graficzne tworzenie topologii połączeń między routerami oraz generator testów weryfikacyjnych działający np. w oparciu o fragmenty pobrane z pliku running-config skonfigurowanych routerów. Autorzy w czasie prac nad laboratorium rozważali utworzenie ćwiczenia, które obrazowałoby podstawowe zasady redystrybucji informacji routingowej pomiędzy protokołem BGP i wybranym protokołem wewnątrzdomenowym (np. OSPF). W tym celu należy wybrać jeden z protokołów, zaprojektować odpowiedni scenariusz oraz dostosować przeglądarkę MIB wbudowaną w aplikację do wczytywania i przeglądania modułów drzewa MIB związanych z wybranym protokołem wewnątrzdomenowym. Aplikacja może być również rozbudowana o funkcje ułatwiające studentom najczęściej wykonywane operacje na routerach tj. zmiana stanu interfejsu. W tym celu można posłużyć się metodą protokołu SNMP setrequest (obecnie zaimplementowane są jedynie metody do pobierania danych za pośrednictwem protokołu SNMP). Wówczas użytkownicy końcowi byliby w stanie wprowadzać część zmian konfiguracyjnych za pośrednictwem aplikacji, bez konieczności wykorzystania konsoli Telnet.

105 Literatura [1] Rivest R., The MD5 Message-Digest Algorithm, RFC 1321, kwiecień 1992 [2] Chandra R., Traina P., Li T., BGP Communities Attribute, RFC 1997, sierpień 1996 [3] Chen E., Bates T., An Application of the BGP Community Attribute in Multi-home Routing, RFC 1998, sierpień 1996 [4] Heffernan A., Protection of BGP Sessions via the TCP MD5 Signature Option, RFC 2385, sierpień 1998 [5] Meyer D., Gill V., Heasley J., The Generalized TTL Security Mechanism (GTSM), RFC 3682, luty 2004 [6] Griffin T., University of Cambridge, Huston G., BGP Wedgies, RFC 4264, listopad 2005 [7] Rekhter Y., Li T., Hares S., A Border Gateway Protocol 4, RFC 4271, styczeń 2006 [8] Murphy S., BGP Security Vulnerabilities Analysis, RFC 4272, styczeń 2006 [9] Haas J., Hares S., Definitions of Managed Objects for BGP-4, RFC 4273, styczeń 2006 [10] Kaeo M., Current Operational Security Practices in Internet Service Provider Environments, RFC 4778, styczeń 2007 [11] Leech M., Key Management Considerations for the TCP MD5 Signature Option, draft-ietf-idr-md5-keys, lipiec 2003 [12] Ward D., Securing BGPv4 using IPsec, draft-ward-bgp-ipsec, styczeń 2002 [13] White R., McPherson D., Srihari S., Practical BGP, Addison Wesley, sierpień 2006 [14] Butler K., Farley T. R., McDaniel P., Rexford J., A Survey of BGP Security Issues and Solutions, Proceedings of the IEEE, Vol. 98, No. 1, styczeń

106 Literatura [15] Kent S., Lynn C., Seo K., Secure Border Gateway Protocol, IEEE Journal on Selected Areas in Communications, 18(4):582592, kwiecień 2000 [16] White R., Securing BGP through secure origin BGP, Technical report, Internet Protocol Journal, Cisco Systems, wrzesień 2003 [17] Goodell G., Aiello W., Griffin T., Working around BGP: An incremental approach to improving security and accuracy of interdomain routing, Proc. of Internet Society Symposium on Network and Distributed System Security (NDSS03), 2003 [18] Iljitsch van Beijnum, BGP, O Reilly and Associates, wrzesień 2002 [19] Malhotra R., IP Routing, O Reilly and Associates, styczeń 2002 [20] Dooley K., Brown I. J., Cisco Receptury, O Reilly and Associates, 2004 [21] Zwierzchowski P., Nowak P., Wykorzystanie mechanizmów protokołu BGP do kształtowania rozpływu ruchu międzydomenowego, Politechnika Warszawska Instytut Telekomunikacji, wrzesień 2009 [22] Dobrodziej Ł., Maćkowiak J., Infrastruktura laboratorium routingu międzydomenowego, Politechnika Warszawska Instytut Telekomunikacji, wrzesień 2010 [23] Greene B. R., BGPv4 Security Risk Assessment, Cisco Press, listopad 2002 [24] Popescu A. C., Premore B. J., Underwood T., The Anatomy of a Leak: AS9121, Renesys Corporation, maj 2005 [25] ISP/IXP Workshops, BGP Flap Dampening, Cisco Systems Inc., 2000 [26] Cowie J., Daly T., Kapela A., Underwood T., Prefix Hijacking Mitigation, NANOG 46, czerwiec 2009 [27] Feamster N., Fighting Spam, Phishing and Online Scams at the Network Level, Georgia Tech [28] Mycek M., Zarządzanie sieciami telekomunikacyjnymi materiały wykładowe, Politechnika Warszawska Instytut Telekomunikacji,

107 [29] IPv4 CIDR Report AS2.0, marzec 2012 [30] the maximum BGP AS-path length, Limit the maximum BGP AS-path length, maj 2012 [31] Abuse Issues and IP Addresses, IANA, grudzień 2011 [32] BGP Dampening, Tomasz Wendlandt, listopad 2006 [33] Dokumentacja do języka C#, maj 2012 [34] Strona biblioteki SharpSNMP, marzec 2010 [35] Opis narzędzi Dynamips/Dynagen, marzec 2010 [36] /bgp.html, Poradnik Cisco dotyczący protokołu BGP, maj 2012

108

109 A Narzędzia Dynagen, Dynamips opis funkcjonalności A.1 Wstęp Dynamips jest emulatorem routerów Cisco. Pozwala na emulację systemów IOS następujących wersji routerów: 1700, 2600, 3600, 3700, i Emulator może być wykorzystany jako platforma testowa. Pozwala na poznanie cech routerów oraz przetestowanie konfiguracji, które później chcemy wykonać na prawdziwym sprzęcie. Dynamips oprócz routerów oferuje również emulacje innych prostych urządzeń sieciowych (switche, bridge). Są one wbudowane w narzędzie i nie wymagają dodatkowych obrazów z systemem operacyjnym. Dynagen jest systemem odpowiedzialnym za pobieranie danych od użytkownika, oraz prezentacje wyników (front-end) dla emulatora Dynamips. Pozwala na proste budowanie i zarządzanie wirtualnymi sieciami. Jego najważniejsze cechy to: Wykorzystuje tekstowe pliki konfiguracyjne do specyfikacji konfiguracji wirtualnych routerów; Prosty syntax do zdefiniowania połączeń pomiędzy routerami oraz innymi komponentami sieciowymi (bridge, switch Frame-relay, atm, Ethernet), które dostarcza Dynamips; Może pracować w trybie klient/serwer. Potrafi obsługiwać wiele serwerów Dynamips jednocześnie, co pozwala na budowę dużych wirtualnych sieci przy wykorzystaniu wielu komputerów. Oczywiście Dynagen i Dynamips mogą działać również na tym samym systemie; Kluczową cechą Dynagen a jest CLI (command-line interface), który pozwala na wypisywanie działających urządzeń, startowanie, zatrzymywanie ich pracy, przeładowanie oraz podłączenie się do konsoli wirtualnych routerów (przez telnet). Wszystko odbywa się w rzeczywistym czasie działania sieci. Dynagen został napisany w języku Python, dzięki czemu działa na każdym systemie operacyjnym, na którym ten język jest interpretowany (praktycznie każdy system). Ze względu na modularną budowę Dynagena i wydzielenie interfejsu do komunikacji z emulatorem Dynamips, istnieje możliwość wykorzystania jego biblioteki w inny aplikacjach 109

110 A Narzędzia Dynagen, Dynamips opis funkcjonalności języka Python, jak również rozbudowa jego funkcjonalności. Przykładem może być aplikacji GNS-3, która wykorzystuje bibliotekę narzędzia Dynagen dodatkowo zapewniając graficzny interfejs użytkownika (graficzny edytor topologii; podgląd topologii w czasie rzeczywistym; ułatwione zarządzanie routerami). Autorzy zapewniają zestawy instalacyjne do większości systemów operacyjnych. Można również instalować pojedynczo wszystkie komponenty, w których skład wchodzą: Platforma Python; Winpcap/libpcap w zależności od tego czy mamy do czynienia z Windowsem czy Linuxem. Biblioteka zapewnia połączenie interfejsów wirtualnych routerów z fizyczna kartą sieciową komputera; Dynamips oraz Dynagen. A.2 Obraz IOS Dynamips, w celu emulacji routera, wykorzystuje prawdziwy obraz Cisco IOS. W zależności od tego, jakimi obrazami dysponujemy, takie routery możemy emulować w naszej wirtualnej sieci. Klienci Cisco mają dostęp do obrazów wszystkich systemów operacyjnych za pośrednictwem serwisu internetowego. Obrazy te są skompresowane i żeby uniknąć rozpakowywania przy każdym uruchomieniu emulatora, należy samodzielnie je rozpakować. A.3 Zużycie zasobów Dynamips do prawidłowego działania potrzebuje zasobów - pamięci (RAM) oraz mocy procesora (CPU). Zużycie RAM zależy od emulowanego obrazu IOS. Przykładowa wartość dla routera w wersji 7200 to 256 MB RAM. Dynamips alokuje taką wartość dla każdej instancji routera. Dodatkowo w zależności od systemu potrzebuje 64 MB (Unix) lub 16 MB (Windows) dla każdej instancji na pokrycie kompilacji JIT (ang. Just In Time). Dynamips wykorzystuje pliki mapujące rzeczywistą pamięć systemu na wirtualną pamięć routerów. W czasie emulacji, na dysku pojawiają się chwilowe pliki ram o rozmiarze równym co do wartości pamięci RAM wirtualnych routerów. Dynamips zużywa również dużo mocy procesora, ponieważ emuluje procesy routera instrukcja po instrukcji. Początkowo emulator nie może wiedzieć, kiedy procesor wirtualnego routera jest bezczynny. Z tego względu 110

111 wszystkie instrukcje nawet te, które są oznaką bezczynności, są traktowane jako instrukcje normalnej pracy urządzenia. Dynagen zapewnia narzędzie do optymalizacji (przy pomocy wartości idle-pc) tego procesu, które uruchomione przy pierwszym wykorzystaniu IOS, drastycznie zmniejsza zużycie procesora. Przy pierwszym uruchomieniu emulatora Dynamips na dowolnym scenariuszu używamy komendy: idlepc get [nazwa routera] Po chwili otrzymamy ponumerowany zbiór wartości. Wybieramy numer wartości, przy której widnieje znak gwiazdki * (jeżeli żadna wartość nie została wyróżniona, powtarzamy pierwszą komende). Następnie zapisujemy wartość w bazie danych: idlepc save [nazwa routera] db Restartujemy emulator Dynamips, ponownie wczytujemy scenariusz i obserwujemy zużycie procesora. Jeżeli przez dłuższy czas będzie wynosić 100%, powtarzamy całą procedurę (na początku trzeba będzie usunąć zapisaną wcześniej wartość z bazy danych - poinformuje nas o tym odpowiedni komunikat przy ponownej próbuje ustawienia wartości idle-pc). A.4 Konsola routerów Przy pomocy narzędzia Dynagen można uzyskać dostęp do konsoli emulowanych routerów przy pomocy klienta telnet - należy wyspecyfikować wybranego klienta w pliku dynagen.ini. Możliwości konfiguracyjne routerów i ich funkcjonalność są praktycznie takie same jak w rzeczywistości. Należy zaznaczyć również, że możemy niezależnie połączyć się z konsolami routerów emulowanych przez Dynamips (bez pomocy narzędzia Dynagen). Należy w tym celu utworzyć połączenie telnet z adresem ip hosta, na którym działa emulator a jako port podać wartość odpowiednią dla danego routera. Dynamips wyprowadza domyślnie port konsolowy routerów na porty kolejno 2000, 2001 itd., ale można zmienić te wartości w pliku konfiguracyjnym.net za pomocą atrybuty console. 111

112 A Narzędzia Dynagen, Dynamips opis funkcjonalności A.5 Plik konfiguracyjny Plik simple1.net: # Simple lab model = 7200 ghostios = true sparsemem = true [localhost] [[7200]] image = \Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.image npe = npe-400 ram = 160 [[ROUTER R1]] s1/0 = R2 s1/0 [[router R2]] Dynagen używa pojedynczego pliku sieciowego (.net) do przechowywania konfiguracji wszystkich routerów, switchy i połączeń, które składają się na wirtualne laboratorium. Plik wykorzystuje prosty syntax podobny do plików.ini. Do tworzenia takiego pliku wystarczy zwykły edytor tekstu. Poniżej przestawione jest wyjaśnienie poszczególnych linii konfiguracji. # Simple lab Każda linia poprzedzona znakiem # to komentarz (jest ignorowana). 112 ghostios = true

113 sparsemem = true Powyższe parametry związane są z oszczędzaniem fizycznej pamięci, z której korzystają routery. Tryb ghostios jest przydatny, gdy wiele razy używamy instancji tego samego modelu routera. Wówczas IOS routera jest wczytywany do pamięci tylko raz i wszystkie routery z niego korzystają (w przeciwnym wypadku wczyta się dla każdej instancji osobno). Sparsemem pozwala rozwiązać problem ograniczenia maksymalnego przydziału pamięci dla jednego procesu w systemie operacyjnym (użyteczny przy dużej liczbie routerów). [localhost] Pierwsza sekcja specyfikuje host, na którym jest uruchomiony Dynamips. W tym przypadku jest to localhost, ponieważ chcemy uruchomić Dynamips i Dynagen na tej samej maszynie. Jeżeli Dynamips działałby na innym komputerze, sekcja ta zawierałaby nazwę hosta/adres IP. [[7200]] Kolejna sekcja definiuje model routerów jaki będziemy emulować. Podwójne nawiasy oznaczają, że sekcja ta jest zagnieżdżona - należy do opisu konfiguracji dla wyżej wymienionego hosta. Białe znaki są ignorowane. image = \Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.image npe = npe-400 ram = 160 Sekcja pod wersją routera definiuje wszystkie domyślne ustawienia, dla każdego routera z tej serii. Pozwala to na jednokrotne wyspecyfikowanie takich atrybutów jak alokowana pamięć dla każdej instancji routera, obraz IOS wykorzystany do emulacji czy rodzaj zainstalowanego silnika (npe-400). [[ROUTER R1]] s1/0 = R2 s1/0 113

114 A Narzędzia Dynagen, Dynamips opis funkcjonalności Powyższy napis definiuje instancje routera o nazwie R1. Następnie definiujemy połączenia między wybranymi interfejsami routerów. [[router R2]] Stworzenie drugiego routera o nazwie R2 (jak widzimy wielkość liter nie ma znaczenia). Interpreter sam założy, że interfejsy mają być połączone dwustronnie i nie trzeba tego powtarzać w drugim routerze. Podany plik konfiguracyjny uruchamiamy po uruchomieniu serwera Dynamips. Cała konfiguracja jest wgrywana, tworzone są poszczególne komponenty. Następnie za pomocą prostych komend narzędzia Dynagen możemy zarządzać naszą wirtualną siecią i łączyć się z konsolą poszczególnych routerów. Jedynym ograniczeniem konfiguracji routerów jakie napotkaliśmy jest brak możliwości wykonania polecenia reload w konsoli routerów. Jednak Dynagen umożliwia wykonanie tego procesu ze swojej konsoli zarządzania. Bardzo interesującą opcją oferowaną przez emulator jest możliwość połączenia interfejsu routera wirtualnego z interfejsem prawdziwego hosta (może być to interfejs loopback). Takie połączenie definiujemy w następujący sposób: F0/0 = NIO_gen_eth:\Device\NPF_{B00A38DD-F10B-43B4-99F4-B4A } Pakiety, które opuszczają interfejs routera F0/0 są wpuszczane do prawdziwej sieci przez zdefiniowane urządzenie sieciowe naszego komputera - to samo dzieje się w drugą stronę z pakietami, które przychodzą na interfejs naszej karty sieciowej. Daje to następujące możliwości: Dołączenie wirtualnych routerów do fizycznej sieci LAN (możemy pingować ich interfejsy); Łączenie się z konsolą routera przez telnet przy pomocy wyprowadzonego interfejsu; Odpytywanie routerów przy pomocy protokołu SNMP. Szczególnie ostatnia możliwość jest bardzo pomocna przy weryfikacji konfiguracji routerów przeprowadzonej w czasie laboratorium. 114

115 A.6 Konfiguracja dynamiczna Dynagen daje możliwość edycji pliku konfiguracyjnego w czasie pracy sieci (z konsoli zarządzania) bez konieczności zatrzymywania urządzeń. Umożliwia to dynamiczne dokładanie routerów czy tworzenie fizycznych połączeń między nimi i obserwowanie jak reaguje na to sieć. Można nawet (co jest niezbyt praktyczne) stworzyć całą sieć od podstaw w sposób dynamiczny (analogicznie jak w pliku konfiguracyjnym.net). A.7 Przydatne funkcje konsoli zarządzania Dynagen potrafi przechwytywać pakiety z wirtualnych interfejsów typu Ethernet bądź Serial i zapisywać je w pliku wyjściowych o formacie zgodnym z wymaganiami takich aplikacji jak Wireshark czy Tcpdump (albo każdą inną aplikacją, która potrafi czytać format libpcap capture file). Poniższy przykład przedstawia sieć trzech routerów. Routery r1 i r2 są połączone przez kabel Ethernetowy, r2 i r3 przez interfejs serialowy. model = 7200 [localhost] [[3660]] image = \Program Files\Dynamips\images\c3660-ik9o3s-mz image [[router r1]] f0/0 = r2 f0/0 [[router r2]] s1/0 = r3 s1/0 [[router r3]] 115

116 A Narzędzia Dynagen, Dynamips opis funkcjonalności Żeby zacząć przechwytywać ruch na interfejsie f0/0 routera r1 i zapisać ślady pakietów do pliku r1.cap należy użyć następującej komendy w oknie zarządzania narzędzia Dynagen: capture r1 f0/0 r1.cap Następnie możemy otworzyć ten plik w Wireshark u i w czasie rzeczywistym oglądać cały ruch przechodzący przez dany interfejs. Można jednocześnie podglądać w ten sposób ruch na różnych interfejsach różnych routerów. Taka funkcjonalność jest bardzo przydatna z dydaktycznego punktu widzenia (pozwala na weryfikacje konfiguracji i dogłębne poznanie działania protokołu). Dynagen oprócz przechwytywania pakietów umożliwia wiele innych potencjalnie przydatnych komend: import/export - Importuje/eksportuje konfiguracje routera z pliku nvram do pliku tekstowego na komputerze. Pozwala to na zapis kopii aktualnej konfiguracji (w celach backup lub weryfikacji); push/save - Podobne działanie do powyższych komend, ale pozwalają przechowywać konfiguracje bezpośrednio w pliku konfiguracyjnym topologii sieci (.net), co daje możliwość dystrybucji całego laboratorium z topologią sieci i konfiguracją poszczególnych routerów w jednym pliku o rozszerzeniu.net. Oprócz podanych funkcji wszystkie operacje i zdarzenia są zapisywanie na dysku dla każdego routera osobno. A.8 Ograniczenia Ograniczeniem omawianego narzędzia jest złożoność i rozmiar topologii sieciowej. Jeżeli nasze laboratorium będzie zbyt rozbudowane (jak na możliwości komputera), routerom zabraknie pamięci i CPU. Routery będą wówczas zagłodzone a komunikacja między nimi będzie przebiegać nieprawidłowo (znikanie wiadomości Hello itp.). Jest jednak kilka możliwości poradzenia sobie z tym problemem: 116 Użycie wydajniejszego komputera (więcej RAM/szybszy procesor);

117 Rozproszenie laboratorium na kilka hostów; Użycie innej wersji IOS, którego wymagania na pamięć są mniejsze. Dla przykładu model 3620 potrzebuje jedynie 32 MB RAM na każdą instancję i może być użyty, jeśli chcemy zasymulować prostą sieć LAN. Problemem może być również ograniczenie systemu operacyjnego co do maksymalnej ilości pamięci RAM przeznaczonej dla jednego procesu (limit dla systemu Windows wynosi 2GB, dla Linux 3 GB). Jednak są dwa sposoby radzenia sobie z tym problemem. Pierwszym jest parametr sparsemem. Drugim sposobem jest uruchomienie kilku instancji serwerów Dynamips (każdemu przyporządkowujemy inny port, który wyszczególniamy w pliku konfiguracyjnym.net) na tym samym systemie. Oczywistym ograniczeniem wirtualnych routerów jest ich wydajność, dlatego trzeba unikać zbytniego obciążania ich interfejsów. Jednak w naszych laboratoriach nie przewidujemy obsługi dużego ruchu - większą wagę przywiążemy do prawidłowej konfiguracji określonych mechanizmów BGP. A.9 Uwagi Poniżej przedstawione są uwagi dotyczące pracy z emulowanymi routerami: Aby można było wyeksportować konfiguracje routera należy najpierw zapisać ją w pamięci routerów write memory Żeby połączyć się zdalnie przez telnet z routerem przy pomocy wydzielonego interfejsu, należy ustawić hasła do dostępu telent oraz trybu uprzywilejowanego line vty 0 4 password [hasło] login enable secret [hasło] Aby aktywować agenta snmp na routerze, należy ustawić hasło community 117

118 snmp-server community [hasło] RW A.10 Podsumowanie Możliwości przedstawionych narzędzi wydają być się w zupełności wystarczające do stworzenia praktycznie każdego laboratorium dotyczącego protokołu BGP. Przedstawione funkcje Dynamips i Dynagen pozwolą na urozmaicenie ćwiczenia (np. przy pomocy przechwytywania ruchu) i stwarzają możliwości weryfikacji konfiguracji przeprowadzonych przez studentów. Literatura [1] Opis narzędzi Dynamips/Dynagen, marzec 2010

119 B Instrukcja do ćwiczenia sterowanie ruchem Temat: Multihoming z wykorzystaniem łączy do jednego dostawcy ISP B.1 Cel ćwiczenia Celem Laboratorium jest skonfigurowanie routerów brzegowych sieci klienta i operatora, w oparciu o protokół BGP, w taki sposób aby uzyskać Multihoming z wykorzystaniem łączy do jednego dostawcy ISP. Klient wykorzystuje prywatny numer AS Przestrzenią adresową wykorzystywaną przez AS jest /24. Rys. B.1 Topologia sieci 119

120 B Instrukcja do ćwiczenia sterowanie ruchem B.2 Konfiguracja Podczas Laboratorium należy skonfigurować powyższą topologię i wysterować ruch w taki sposób, aby łącze pomiędzy routerami A i C było łączem podstawowym dla ruchu wychodzącego i przychodzącego, natomiast łącze pomiędzy routerami B i D było łączem zapasowym i było używane tylko w przypadku awarii łącza podstawowego. Instrukcja nie zawiera pełnej konfiguracji (analogiczne operacje trzeba wykonać samodzielnie). B.2.1 Konfiguracja interfejsów Adresy na interfejsach powinny być skonfigurowane według poniższego schematu: Rys. B.2 Tabela interfejsów Polecenia: R1(config)\#interface S1/1 R1(config-if)\#ip address R1(config-if)\#no shutdown Stan i adres interfejsów może być sprawdzony na podstawie graficznego podglądu topologii (interfejsy po odświeżeniu topologii powinny mieć kolor zielony i odpowiedni adres IP). B.2.2 Konfiguracja sesji BGP Routery powinny mieć ustawione odpowiednie numery ASN (zgodnie z rysunkiem), które definiują przynależność do określonego AS. Dodatkowo każdy router będzie obsługiwał dwie sesje - jedną ibgp z routerem znajdującym się w tym samym AS oraz jedną ebgp z routerem znajdującym się w innym AS. Sesje należy skonfigurować obustronnie. 120 Polecenia:

121 R1(config)\#router bgp R1(config-router)\#neighbor remote-as R1(config-router)\#neighbor remote-as 100 Przynależność do danego AS można zweryfikować na podstawie graficznego podglądu topologii (routery w tym samym AS powinny mieć ten sam kolor). Sesje obsługiwane przez routery są opisane w tabeli bgppeertable dostępnej za pomocą MIB Browser. Niezerowa ilość wymienionych informacji świadczy o tym, że sesja jest zestawiona. Rys. B.3 Tabela bgppeertable B.2.3 Zapewnienie dostępności adresu Next Hop W protokole BGP wartością atrybutu Next Hop dla rozgłoszonej sieci jest adres IP routera znajdującego się w sąsiednim AS, który sieć rozgłosił. Istnieje wiele metod, które pozwalają na zapewnienie dostępności adresu Next Hop (np. wewnątrzdomenowy protokół routingu). Cisco oferuje niestandardowy mechanizm, który pozwala na zmianę adresu Next Hop przed wysłaniem rozgłoszenia do innego routera znajdującego się w tym samym AS - next-hop-self. Router brzegowy zamiast adresu routera, który rozgłosił sieć, ustawia wartość atrybutu Next Hop na swój własny adres. Dzięki temu nie ma konieczności konfigurowania wewnątrzdomenowego protokołu routingu w każdym AS. Mechanizm ten powinien być skonfigurowany tylko pomiędzy routerami w tym samym AS. Polecenia: R1(config)\#router bgp R1(config-router)\#neighbor next-hop-self 121

122 B Instrukcja do ćwiczenia sterowanie ruchem B.2.4 Rozgłoszenie sieci Przestrzenią adresową wykorzystywaną przez AS jest /24. Aby zasymulować taką sieć podłączoną do routera można skonfigurować na routerze B interfejs Loopback (interfejs logiczny, którego stan jest zawsze up). Polecenia: R2(config)\#interface loopback 0 R2(config-if)\#ip address Po odświeżeniu topologii, ikona podsieci powinna pojawić się przy routerze B. Następnie routery muszą rozgłosić podsieci, do których mają dostęp. Router B będzie rozgłaszał sieć z maską skonfigurowaną na interfejsie Loopback0. Polecenia: R2(config)\#router bgp R2(config-router)\#network mask Routery C i D będą rozgłaszały do routerów A i B znajdujących się w AS tylko trasę domyślną (trasę, która będzie używana dla całego ruchu wychodzącego z AS 65500). Polecenia: R3(config)\#router bgp 100 R3(config-router)\#neighbor default-originate W celu weryfikacji rozgłoszeń można przejrzeć tabelę bgp4pathattrtable lub iproutetable za pomocą MIB Browser. Rys. B.4 Tabela bgp4pathattrtable 122

123 B.2.5 Wysterowanie ruchu wychodzącego Żeby wysterować ruch w taki sposób, aby routery A i B korzystały tylko i wyłącznie z łącza podstawowego dla ruchu wychodzącego, możemy użyć atrybutu Local Preference. Domyślna wartość tego atrybutu dla rozgłoszeń wynosi 100. Atrybut ten jest wymieniany pomiędzy wszystkimi routerami znajdującymi się w tym samym AS. Aby łącze pomiędzy routerami A i C było łączem podstawowym należy przypisać sieci default owej otrzymanej za pomocą łącza podstawowego wyższą wartość atrybutu Local Preference. Mechanizmem, który służy do zmiany atrybutów jest Route map. Za pomocą Route map należy przypisać rozgłoszeniu o sieci otrzymanemu na łączu podstawowym wartość Local Preference 150. Polecenia: R1(config)\#route-map primary R1(config-route-map)\#match ip address 1 R1(config-route-map)\#set local-preference 150 R1(config-route-map)\#exit R1(config)\#access-list 1 permit host Route map należy przypisać na routerze A do sąsiada, który rozgłasza sieć /32 (kierunek in - dla rozgłoszenia przychodzącego). Polecenia: R1(config)\#router bgp R1(config-router)\#neighbor route-map primary in Aby router C wysłał jeszcze raz rozgłoszenie do sieci po to, żeby router A mógł przypisać mu nową wartość Local Preference 150 należy zresetować sesję BGP. Polecenia: R1\#clear ip bgp * Aby zweryfikować konfiguracje należy wykonać traceroute przed symulacją awarii łącza podstawowego i po (wyłączenie jednego z interfejsów należącego do łącza podstawowego). 123

124 Literatura B.2.6 Wysterowanie ruchu wchodzącego Ruch należy wysterować w ten sposób, aby routery C i D kierowały ruch do sieci poprzez łącze podstawowe. Jedną z metod jest rozgłoszenie sieci /24 z niższą wartością atrybutu MED na łączu podstawowym niż na łączu zapasowym. Na łączu podstawowym rozgłosimy sieć /24 z wartością atrybutu MED 20 natomiast na łączu zapasowym 50. Ponownie wykorzystamy mechanizm Route map. Polecenia: R1(config)\#route-map rozgl_wych permit 10 R1(config-route-map)\#match ip address 10 R1(config-route-map)\#set metric 20 R1(config-route-map)\#exit R1(config)\#access-list 10 permit host Route map należy przypisać do sąsiada, któremu rozgłaszamy sieć (kierunek out - dla rozgłoszeń wychodzących). Polecenia: R1(config)\#router bgp R1(config-router)\#neighbor route-map rozgl_wych out Na routerze B ustawiamy analogicznie dla rozgłoszenia tej samej podsieci (przeznaczonego dla łącza zapasowego) MED 50. Następnie musimy zresetować sesje na routerach ISP, aby mogły otrzymać ponowne rozgłoszenia z odpowiednimi wartościami metryk. Aby zweryfikować konfiguracje należy wykonać traceroute przed symulacją awarii łącza podstawowego i po (wyłączenie jednego z interfejsów). Literatura 124 [1] Piotr Zwierzchowski, Piotr Nowak, Wykorzystanie mechanizmów protokołu BGP do kształtowania rozpływu ruchu międzydomenowego - instrukcja do La-

125 boratorium 1, Politechnika Warszawska Instytut Telekomunikacji, wrzesień 2009

126

127 C Instrukcja do ćwiczenia bezpieczeństwo protokołu BGP Temat: Atak polegający na przejęciu puli prefiksów C.1 Cel ćwiczenia Celem ćwiczenia jest skonfigurowanie routerów brzegowych systemów autonomicznych w oparciu o protokół BGP oraz zasymulowanie przejęcia puli prefiksów należącej do systemu autonomicznego AS 1 przez wrogi system autonomiczny AS 5 (patrz Rys. C.1). Przedstawiony atak polega na wykorzystaniu rozgłoszenia BGP zawierającego dłuższą maskę adresu niż rozgłoszenie pochodzące z oryginalnego systemu autonomicznego. Algorytm decyzyjny protokołu BGP pozwala na wprowadzenie do bazy FIB (ang. Forwarding Information Base) ścieżek, których prefiksy posiadają część wspólną (zakresy adresów IP nachodzą na siebie). W przypadku istnienia równoważnych pod względem pozostałych metryk ścieżek preferuje się tę, która posiada najdłuższą maskę (najdokładniej pasuje do danego adresu). Decyduje o tym reguła longest prefix match, która jest standardowo implementowaną zasadą na poziomie routingu IP. Na koniec ćwiczenia zostanie przedstawiona propozycja zabezpieczenia się przed atakiem przejęcia puli prefiksów. 127

128 C Instrukcja do ćwiczenia bezpieczeństwo protokołu BGP Rys. C.1 Topologia sieci C.2 Konfiguracja Podczas realizacji ćwiczenia należy skonfigurować powyższą topologie i rozgłosić pule adresów w taki sposób, aby ruch adresowany do systemu autonomicznego AS 1 z systemu autonomicznego AS 3 został skierowany do wrogiego systemu autonomicznego AS 5. Instrukcja nie zawiera pełnej konfiguracji (analogiczne operacje należy wykonać samodzielnie). C.2.1 Konfiguracja interfejsów Adresy interfejsów powinny być skonfigurowane według tabeli z Rys. C.2. Rys. C.2 Tabela interfejsów 128

129 Polecenia: R1(config)\#interface S1/1 R1(config-if)\#ip address R1(config-if)\#no shutdown Stan i adres interfejsów może być sprawdzony na podstawie graficznego podglądu topologii (interfejsy po odświeżeniu topologii powinny mieć kolor zielony i odpowiedni adres IP). C.2.2 Konfiguracja sesji BGP Routery powinny mieć ustawione odpowiednie numery ASN (zgodnie z rysunkiem przedstawiającym topologię sieci), które definiują przynależność do określonego AS. Dodatkowo każdy router będzie obsługiwał co najmniej jedną sesje ebgp z routerem znajdującym się w innym AS. Sesję należy skonfigurować obustronnie. Polecenia: R1(config)\#router bgp 1 R1(config-router)\#neighbor remote-as 2 Przynależność do danego AS można zweryfikować na podstawie graficznego podglądu topologii (routery w tym samym AS powinny mieć ten sam kolor). Sesje obsługiwane przez routery są opisane w tabeli bgppeertable dostępnej za pomocą narzędzia MIB Browser, które jest wbudowane w aplikację. Niezerowa ilość wymienionych wiadomości świadczy o tym, że sesja jest zestawiona. Rys. C.3 Tabela bgppeertable dla routera R3 129

130 C Instrukcja do ćwiczenia bezpieczeństwo protokołu BGP C.2.3 Rozgłoszenie sieci Przestrzenią adresową rozgłaszaną przez oryginalny system autonomiczny AS 1 jest /8. Aby zasymulować taką sieć podłączoną do routera można skonfigurować na routerze R1 interfejs Loopback (interfejs logiczny, którego stan jest zawsze up). Polecenia: R1(config)\#interface loopback 0 R1(config-if)\#ip address Po odświeżeniu topologii, ikona podsieci powinna pojawić się przy routerze R1. Wrogi system autonomiczny AS 5, który chce dokonać przejęcia prefiksów wykorzystuje bardziej specyficzną przestrzeń adresową /9. Możemy ją zasymulować na routerze R5 analogiczne do powyższego przykładu. Następnie routery muszą rozgłosić swoim sąsiadom podsieci, do których mają dostęp. Router R1 będzie rozgłaszał sieć z maską natomiast router R5 rozgłasza sieć z maską Polecenia: R1(config)\#router bgp 1 R1(config-router)\#network mask W celu weryfikacji rozgłoszeń można przejrzeć tabelę bgp4pathattrtable lub iproutetable za pomocą narzędzia MIB Browser. Rys. C.4 Tabela bgp4pathattrtable dla routera R3 130

131 C.3 Weryfikacja skuteczności przeprowadzonego ataku Aby zweryfikować skuteczność przeprowadzonego ataku należy użyć narzędzia traceroute, które jest wbudowane w aplikację. Z routera R3 w systemie autonomicznym AS 3 należy sprawdzić drogę do adresu mieszczącego się zarówno w puli rozgłaszanej przez AS 1 jak i wrogi system AS 5 (np ). Ruch powinien zostać skierowany w kierunku wrogiego systemu autonomicznego, który rozgłosił bardziej specyficzną pule adresów. Rys. C.5 Widok aplikacji z przeprowadzonego ćwiczenia C.4 Zabezpieczenie się przed atakiem przejęcia puli prefiksów Do uniknięcia przejęcia puli prefiksów przez system autonomiczny można wykorzystać mechanizm prefix-list, który służy do filtrowania ścieżek. Należy zdefiniować listę prefiksów, które mają być odrzucane przez router a następnie zastosować ją do sąsiedniego routera BGP, który te prefiksy rozgłasza. 131

132 Polecenia: R4(config-router)\#neighbor prefix-list 10 in R4(config)\#ip prefix-list 10 deny /9 Aby wymusić szybsze zastosowanie zdefiniowanej reguły można zresetować sesję BGP. Polecenia: R4\#clear ip bgp * Filtr spowoduje, że router odrzuci ścieżkę do podsieci /9 otrzymaną przez sąsiedni router R5 i nie będzie jej przekazywał do sąsiednich systemów autonomicznych. W celu weryfikacji skuteczności zastosowanego filtru można przejrzeć tabelę bgp4pathattr- Table na routerze R3 powinna zawierać wyłącznie ścieżkę od uprawnionego systemu autonomicznego. Rys. C.6 Tabela bgp4pathattrtable dla routera R3 po zastosowaniu filtrowania przez router R4 Literatura [1] How to use ip prefix list, maj 2012 [2] 3/iproute/command/reference/ip2 i1g.html, IP Routing Protocols Commands, maj 2012

133 D Instrukcja obsługi aplikacji D.1 Funkcjonalność Aplikacja umożliwia przeprowadzenie ćwiczeń laboratoryjnych dotyczących protokołu BGP na routerach Cisco lub przy wykorzystaniu emulatora Dynamips. Poniżej przestawione są jej najważniejsze funkcje i możliwości. 1. Program pobiera informacje o grupie laboratoryjnej. 2. Aplikacja umożliwia graficzny podgląd topologii laboratorium. Pozwala na aktualizacje stanu poszczególnych routerów i interfejsów oraz odczytywanie podstawowych informacji o ich bieżącej konfiguracji. 3. Za pośrednictwem programu można uzyskać zdalny dostęp do wybranego routera przez telnet. 4. Aplikacja pełni role przeglądarki MIB. Użytkownik ma do dyspozycji cztery metody protokołu SNMP, aby odczytać wartość wybranego atrybutu: get Pobranie wartości atrybutu o danym numerze OID. getnext Pobranie wartości atrybutu, który znajduje się po atrybucie o danym numerze OID. getbulk Pobranie wartości N kolejnych atrybutów, które znajdują sie po atrybucie o danym numerze OID. Po wybraniu tej metody, użytkownik może zdefiniować ile wartości chce pobrać. gettable Pobranie całej tablicy wartości. Dane odczytane przy pomocy SNMP prezentowane są w konsoli. W przypadku odczytywania tablic, program wyświetla pobraną tabele w całości wraz z nazwami kolumn. 5. Aplikacja ma wbudowaną funkcjonalność traceroute. Pozwala na obserwacje ruchu wchodzącego i wychodzącego z wybranej podsieci. 6. Program posiada konsolę, na której na bieżąco pojawiają się informacje o wykonanych operacjach oraz występujących błędach. 133

134 D Instrukcja obsługi aplikacji 7. Główną funkcjonalnością aplikacji jest możliwość automatycznej weryfikacji wykonanej konfiguracji. 8. Po zakończeniu działania program generuje raport z wykonanego laboratorium. D.2 Graficzny Interfejs Użytkownika Rys. D.1 Okno początkowe wprowadzanie informacji na temat Grupy Laboratoryjnej Rys. D.2 Widok podstawowy 1. Panel wizualizacyjny ukazuje topologię sieci tworzonej na podstawie pliku konfiguracyjnego. a) Przycisk służący odświeżaniu wizualizacji. Jego użycie powoduje wyzwolenie serii zapytań SNMP, dzięki którym możemy wizualnie ocenić postęp naszych prac 134

135 i łatwiej wykrywać istniejące błędy konfiguracji. Jego użycie jest niezbędne przed korzystaniem z funkcji Traceroute. b) Ikona routera wraz z wyświetlaną poniżej nazwą i ukazanymi połączeniami fizycznymi z innymi routerami. Kolor tła jest uzależniony od przynależności do danego AS. Kliknięcie na wybrany router powoduje wyświetlenie informacji dot. tego urządzenia w panelu (5) Router Info a także wpisanie prawidłowego (4) adresu, portu i hasła SNMP i (5a) adresu i portu Telnet. c) Ikona interfejsu jej kolor jest uzależniony od stanu operacyjnego i administracyjnego interfejsu. Kolor szary nie wykonano operacji Refresh nieznany stan administracyjny/operacyjny Kolor zielony status administracyjny i operacyjny równe 1 Kolor żółty status administracyjny równy 1, operacyjny równy 0 Kolor czerwony status administracyjny i operacyjny równe 0 2. Przycisk wykonywania zapytań SNMP a) Wybór rodzaju zapytania (Get, GetNext, GetBulk, GetTable). W przypadku wyboru GetBulk dostępne staną się pola Max Repetitions i Non Repeaters. b) Pole wyboru OID, na którym zostanie wykonane zapytanie SNMP. Pole przechowuje 10 ostatnio odpytywanych OID. c) Widok drzewa MIB. Kliknięcie dowolnego elementu powoduje przypisanie jego OID do pola (2b). Ikony oznaczają jakiego typu jest dany element. Kliknięcie na elemencie będącym tablicą domyślnie ustawia rodzaj zapytania (2a) na GetTable. 3. Konsola programu służy do wyświetlania komunikatów, informacji o błędach i wyników zapytań SNMP. a) Wybór zakładki widoku konsoli/widoku tablicowego b) Przycisk do czyszczenia konsoli. 4. Panel z danymi wykorzystywanymi do zapytań SNMP (ustawiany automatycznie w momencie kliknięcia wybranego routera) 135

136 D Instrukcja obsługi aplikacji 5. Informacje o nazwie i ASN wybranego Routera (wyboru dokonujemy poprzez kliknięcie na ikonie Routera, jest on ukazywany poprzez obramowanie ikony (patrz Router R1)). a) Przycisk do uruchamiania konsoli Telnet i połączenia się z wybranym Routerem (jego adres i port Telnet jest uzupełniany automatycznie po kliknięciu ikony Routera) 6. Informacje o wybranym Interfejsie (wyboru dokonujemy poprzez kliknięcie na ikonie Interfejsu, jest on ukazywany poprzez obramowanie ikony (patrz Interfejs s1/0 Routera R1)). Informacja o przypisanym Adresie Interfejsu jest wyświetlana wyłącznie po wykonaniu odświeżenia widoku i pokazuje konfigurację, z chwili wykonania odświeżenia. 7. Panel do wprowadzenia początku i końca trasy jest to narzędzie weryfikacji konfiguracji sieci. a) Przyciski do wyświetlania i czyszczenia wyświetlonej trasy. Przycisk Traceroute jest dostępny po wykonaniu odświeżenia. 8. Przycisk otwierający okno oceniania laboratorium. Rys. D.3 Widok po odświeżeniu 136

137 1. Wyświetlenie różnych kolorów tła ikon Routerów zależnie od ich numerów ASN 2. Wyświetlenie koloru Interfejsów 3. Pojawienie się podsieci rozgłaszanych przez Routery 4. Najechanie myszką na Router/Interfejs/Podsieć powoduje wyświetlenie informacji o nim w ToolTip Text 5. Informacja w konsoli o wykonaniu odświeżenia Panelu Wizualizacyjnego wraz z datą i godziną 6. Pojawienie się informacji odczytanych przez SNMP o ASN Routera i Adresie Interfejsu 7. Dostępny przycisk Traceroute Rys. D.4 Wykonywanie zapytań SNMP 1. Rodzaj zapytania to Get 2. OID odpowiada atrybutowi bgplocalas 3. Podświetlony odpytywany atrybut drzewa MIB 4. Wynik zapytania (65500) wraz z nazwą Routera, datą i godziną, rodzajem zapytania SNMP, OID i nazwą atrybutu 137

138 D Instrukcja obsługi aplikacji Rys. D.5 Wykonywanie Get Table po SNMP 1. Rodzaj zapytania to GetTable 2. OID odpowiada tablicy ipaddrtable 3. Podświetlona odpytywana tablicą drzewa MIB 4. Wynik zapytania w widoku tablicowym Rys. D.6 Funkcja Traceroute 138

139 1. Panel Traceroute z wybranym źródłem (Router R4) i celem (Podsieć ) użycie przycisku Traceroute 2. Wyświetlenie trasy między R4 a podsiecią na podstawie wpisów w tablicy Routingowej pobranej za pomocą SNMP 3. Raportowanie Traceroute w oknie Konsoli 4. Najechanie myszą na ikonę podsieci pozwala wyświetlić jej adres. 5. Wynik zapytania w widoku tablicowym Rys. D.7 Okno oceniania 1. Okno oceniania, wyświetlane po naciśnięciu w głównym oknie Przycisku Result Window 2. Drzewo urządzeń, interfejsów i Testów sprawdzających poprawność wykonania laboratorium (TestCase). Testy mogą dotyczyć Routera lub każdego z jego interfejsów. Ikony testów i elementów sprawdzanych w drzewie oznaczają czy 1) dla testów czy test się powiódł; 2) dla elementów czy wszystkie testy podległe elementowi się powiodły. 3. Pole wyświetlające informacje o wybranym elemencie drzewa. W przypadku testów wyświetla opis co sprawdza dany test wraz z wartościami z drzewa MIB i ich spodziewanymi wartościami. 139

140 D Instrukcja obsługi aplikacji 4. Przycisk weryfikacji uruchamia serie zapytań SNMP, dzięki której stwierdzamy zgodność konfiguracji ze spodziewaną. Użycie przycisku (w przypadku braku błędów z łącznością przez SNMP) uaktualnia ikony w drzewie, oblicza wynik laboratorium (5) i odblokowuje przycisk (6) kończący Laboratorium. Uwaga: użycie przycisku Verify nie kończy laboratorium jest to metoda sprawdzenia co jeszcze pozostało do zrobienia. 5. Wynik laboratorium wyliczany ze wzoru (5 * udane TestCase y/wszystkie Test- Case y). 6. Przycisk kończący laboratorium i generujący raport do pliku.txt. Rys. D.8 Okno oceniania (niepowodzenie) Widok ukazujący jak sytuacja prezentowałaby się w naszym programie (Panelu Wizualizacyjnym i Oknie Oceniania po wyłączeniu jednego interfejsu Routera R1. 140

141 Rys. D.9 Raport z laboratorium Szczegółowy raport z wykonania Laboratorium, w którym zawarte są informacje na temat scenariusza, grupy laboratoryjnej, czasu trwania laboratorium i jego wyniku.

142

143 E Raport dotyczący przeprowadzonych zmian w aplikacji E.1 Wstęp Wszystkie poczynione zmiany w aplikacji mają na celu jej uelastycznienie. Dzięki wprowadzonym zmianom aplikacja może służyć jako fragment platformy laboratoryjnej, której ćwiczenia mogą dotyczyć stosowania dowolnych protokołów i różnorodnych zagadnień związanych z routingiem. Dzięki wprowadzonym zmianom możliwe jest tworzenie większych i bardziej skomplikowanych ćwiczeń jednocześnie zmniejszając nakład pracy przy projektowaniu nowych scenariuszy ćwiczeń laboratoryjnych. Optymalizacja wydajnościowa, stanowi nie tylko udogodnienie dla użytkowników końcowych korzystających z aplikacji. Bez niej trudno byłoby sobie wyobrazić przeprowadzenie skomplikowanych scenariuszy laboratoryjnych. Czas reakcji na akcje użytkownika w starej wersji aplikacji, przekroczyłby dopuszczalną granicę jej użyteczności. Zmiany w strukturze klas, a przede wszystkim dostarczenie przystępnych metod tworzenia paneli informacyjnych prezentujących dowolne dane, pozwalają na sprawne dostosowanie jej do wymagań dowolnego scenariusza laboratoryjnego. Rozdzielenie konfiguracji na osobne pliki przeznaczone dla emulatora i aplikacji, wraz z zastosowaniem standardowego sposobu zapisu danych w formacie xml pozwala znacząco usprawnić pracę nad nowymi scenariuszami laboratoryjnymi. Podobnie, nowo zaimplementowana funkcjonalność odczytu i zapisu scenariuszy z pliku, a także możliwość importowania scenariusza z pliku konfiguracyjnego zgodnego z wcześniejszą wersją aplikacji, usprawnia proces projektowania ćwiczeń laboratoryjnych. E.2 Optymalizacja wydajnościowa Operacjami wykazującymi znaczący czas wykonywania się są grupowe operacje SNMP: odświeżanie wizualizacji i weryfikacja konfiguracji. Do tej pory, były one realizowane poprzez sekwencyjne wykonywanie zapytań SNMP. Wprowadzenie wielowątkowego wykonywania zapytań SNMP pozwoliło osiągnąć dużo lepszą wydajność wykonywania ww. operacji. Równoległe wykonywanie zapytań SNMP znacznie skraca czas oczekiwania na odświeże- 143

144 E Raport dotyczący przeprowadzonych zmian w aplikacji nie wizualizacji i weryfikacje konfiguracji, co przekłada się na poprawie komfortu pracy z aplikacją. E.2.1 Odświeżanie wizualizacji Dla każdego routera pobierane są dane wymagane do wizualizacji (stan interfejsów, przydzielone adresy IP, numery ASN). Odświeżenie występuje w chwili użycia przycisku Refresh. Dotychczasowa złożoność obliczeniowa: Złożoność tego działania jest klasy: Θ(N P ), gdzie N liczba routerów, P liczba zapytań wymagana do pobrania podstawowej konfiguracji jednego routera Obecna złożoność obliczeniowa: Złożoność tego działania jest klasy: Θ(P ) Skrócenie czasu dla przykładowego laboratorium: Przed zmianą 5 s Po zmianie 1,5 s Uniezależnienie czasu wykonywania tego działania od liczby routerów gwarantuje skalowalność aplikacji i pozwala na przeprowadzanie przy jej użyciu bardziej skomplikowanych scenariuszy laboratoryjnych. Dodatkową korzyścią jest skrócenie czasu źawieszeniaaplikacji w przypadku, gdy istnieją problemy z komunikacją SNMP (wówczas czas wykonywania zapytania jest równy wartości parametru timeout, ustawionej dla konkretnego typu zapytania SNMP). E.2.2 Weryfikacja wykonania laboratorium Dla każdego routera wykonywane są zapytania potrzebne do przeprowadzenia testów, które mają na celu sprawdzenie poprawności konfiguracji. Weryfikacja występuje w chwili użycia przycisku Verify. Dotychczasowa złożoność obliczeniowa: 144

145 Złożoność tego działania wynosi: (x) (i) T xi, gdzie T xi złożoność i tego testu dla routera x. Obecna złożoność obliczeniowa: Złożoność tego działania wynosi: max (x,i) (T xi ), gdzie T xi złożoność i tego testu dla routera x. Skrócenie czasu dla przykładowego laboratorium: Przed zmianą 40 s Po zmianie 3 s Uniezależnienie złożoności tego działania od liczby routerów i od liczby testów na routerze daje w efekcie znaczny zysk wydajności czasowej. Obecna złożoność czasowa, zależna wyłącznie od czasu wykonania najdłuższego sprawdzenia SNMP, zapewnia, że rozwiązanie będzie bardzo wydajne dla wszystkich scenariuszy laboratoryjnych. E.3 Przebudowa struktury klas Konieczną zmianą przed wprowadzaniem zmian funkcjonalnych do aplikacji było uporządkowanie struktury klas. w poprzedniej wersji programu, znacząca większość logiki aplikacji była zawarta w klasie MainWindow. Rozbudowane panele np. prezentujący wizualizację scenariusza laboratoryjnego, panel zawierający drzewo MIB, konsola, panele informacyjne i funkcjonalne (RouterInfo, InterfaceInfo, Traceroute, SNMPInfo), były częścią klasy MainWindow. Naszym pomysłem było wyniesienie paneli do osobnych klas dziedziczących po klasie Panel. Dzięki temu zabiegowi znacząco zmniejszyła się objętość klasy głównej MainWindow, a funkcjonalności związane z działaniami w obrębie danego panelu są pogrupowane w oddzielnych klasach. Z powodu podobieństwa paneli informacyjnych/funkcjonalnych, pod względem ich przeznaczenia i reprezentacji w graficznym interfejsie użytkownika, powstał pomysł utworzenia klas FunctionalPanel i FunctionalRow. Wszystkie panele informacyjne i funkcjonalne są teraz obiektami klasy FunctionalPanel agregującymi obiekty klasy Functional- Row. Panele te są tworzone dynamicznie, mogą zawierać dowolną ilość wierszy (obiekty klasy FunctionalRow), w których umieszczane są kontrolki w postaci przycisków, pól tekstowych i pól edytowalnych. 145

146 E Raport dotyczący przeprowadzonych zmian w aplikacji Podstawową korzyścią wynikającą z istnienia klas FunctionalPanel i FunctionalRow, jest możliwość łatwego tworzenia nowych paneli, które będą musiały powstawać w celu obsługi przez program innych protokołów niż przewidziane w pierwszej wersji aplikacji. Kolejnym udogodnieniem, jest brak konieczności umieszczania kontrolek i paneli ręcznie (z poziomu GUI Designer). Obecnie panele FunctionalPanel są wdokowane w ustawione statycznie panele. Obecną struktura klas reprezentuje rysunek E.1. Na rysunku wyróżniono nowoutworzone klasy. Rys. E.1 Diagram klas Interfejs graficzny obecnej wersji aplikacji został zaprezentowany na Rys. E.2. Zaznaczono i opisano na nim wydzielone do osobnych klas panele. Na zrzucie ekranu widoczny jest również nowopowstały panel funkcjonalny ScenarioPanel służący do wczytywania i zapisywania scenariuszy laboratoryjnych bez konieczności ponownego uruchomienia/kompilacji programu. 146

147 Rys. E.2 Interfejs graficzny aplikacji E.4 Format danych wejściowych Aplikacja wczytuje z pliku następujące dane wejściowe: topologię sieci wykorzystanej w laboratorium (routery oraz łącza), informacje potrzebne do komunikacji z routerami przez telnet i SNMP, nazwy oraz współrzędne routerów wykorzystywane w wizualizacji scenariusza, definicje testów do weryfikacji przeprowadzonej konfiguracji. W poprzedniej wersji aplikacji wszystkie powyższe informacje były zapisane w jednym pliku, który był jednocześnie plikiem wejściowym definiującym scenariusz dla emulatora Dynamips (plik z rozszerzeniem.net). Informacje dodatkowe niezgodne ze składnią emulatora umieszczane były za znakami komentarza. Aby uporządkować dane wejściowe i umożliwić ich łatwiejsza edycję dokonaliśmy podziału danych na plik.net definiujący scenariusz przeznaczony wyłącznie dla emulatora Dynamips oraz plik.xml zawierający wszystkie niezbędne informacje przeznaczone dla aplikacji. Z powyższymi zmianami wiąże 147

148 E Raport dotyczący przeprowadzonych zmian w aplikacji się możliwość wczytywania scenariuszy (zarówno w formacie.xml jak i.net) w trakcie pracy aplikacji, a także możliwość eksportowania danych do formatu.xml. E.4.1 Plik wejściowy emulatora Plik z rozszerzeniem.net zawiera wyłącznie informacje interpretowane przez emulator i nie jest potrzebny do uruchomienia aplikacji. Zawiera definicje emulowanych routerów oraz połączeń. Po dokonaniu eksportu konfiguracji przechowuje również konfiguracje routerów. Poniżej przedstawiony jest przykładowy plik z zapisem scenariusza laboratorium przeznaczony dla emulatora Dynamips: model = 7200 [localhost] [[7200]] image = \Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.image npe = npe-400 ram = 160 [[ROUTER R1]] s1/0 = R2 s1/0 s1/1 = R3 s1/1 f0/0 = SW1 1 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a(...) model = 7200 [[ROUTER R2]] s1/1 = R4 s1/1 f0/0 = SW1 3 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a(...) model = 7200 [[ROUTER R3]] s1/0 = R4 s1/0 f0/0 = SW1 4 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a(...) 148

149 model = 7200 [[ROUTER R4]] f0/0 = SW1 5 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a(...) model = 7200 [[ethsw SW1]] 1 = access 1 2 = access 1 NIO_gen_eth:\Device\NPF_{9D3FA9E6-A(...) 3 = access 1 4 = access 1 5 = access 1 E.4.2 Plik wejściowy aplikacji Plik z rozszerzeniem.xml przechowuje informacje wymagane do działania aplikacji. Składnia XML pozwala na łatwą edycję danych, co jest szczególnie ważne przy definiowaniu testów wykorzystywanych do weryfikacji ćwiczenia. Podczas tworzenia nowego scenariusza można posłużyć się dowolnym edytorem plików.xml, aby uprościć dodawanie nowych testów i wypełnianie wartości atrybutów. Poniżej przedstawiono przykładowy plik wejściowy aplikacji: 149

150 E Raport dotyczący przeprowadzonych zmian w aplikacji Rys. E.3 Plik wejściowy aplikacji w formacie XML Plik rozpoczyna się podstawowymi informacjami dotyczącymi scenariusza laboratoryjnego. Podane są nazwa, wersja, autorzy, data powstania oraz opis laboratorium. Następnie opisane są routery wchodzące w skład sieci laboratoryjnej. Każdy router charakteryzowany jest przez swoją nazwę, współrzędne X i Y określające położenie routera na wizualizacji oraz informacje potrzebne do komunikacji z danym routerem z wykorzystaniem protokołów telnet i SNMP (adres IP interfejsu routera wykorzystywanego do komunikacji, port SNMP, community oraz port telnet). Każdy router zawiera dwie listy: Lista łączy. Każde łącze zdefiniowane jest przez interfejs danego routera oraz adres IP i interfejs routera do którego prowadzi łącze. Lista testów weryfikacyjnych. Test określany jest przez nazwę, obiekt, na którym jest wykonywany (router lub interfejs), typ zapytania SNMP (get lub gettable), identyfikator OID oraz opis testu. Test zawiera również listę sprawdzanych par: numer atrybutu - oczekiwana wartość (w przypadku tabel numery atrybutu są numerami kolumn). 150

151 E.4.3 Opcja zapisu/odczytu Plik wejściowy aplikacji zawiera część informacji zawartych w pliku wejściowym emulatora Dynamips (routery, nazwy routerów, łącza). Aby uprościć proces generowania pliku.xml dostępna jest opcja wczytania pliku wejściowego emulatora.net (z samym scenariuszem lub według dawnej składni z informacjami dodatkowymi w formie komentarzy) oraz zapisu wczytanych informacji do pliku.xml zgodnego z nową konwencją. Dzięki temu po zdefiniowaniu scenariusza laboratoryjnego dla emulatora Dynamips możemy w prosty sposób uzyskać szkielet pliku zawierający podstawowe informacje przeznaczone dla aplikacji. Do aplikacji dodano również panel pozwalający na wielokrotne wczytywanie plików wejściowych różnych scenariuszy (z formatu.xml lub dawnego wzbogaconego.net) bez konieczności ponownego uruchamiania aplikacji.

152

153 F Środowisko laboratoryjne podręcznik administratora F.1 Wstęp Aplikacja, wraz z interfejsem graficznym użytkownika, stanowi najistotniejszy element zaprojektowanego środowiska laboratoryjnego. Kolejnym jego elementem jest emulator routerów Dynamips, wraz z konsolą zarządzania Dynagen. Jest to element opcjonalny, co oznacza, że aplikacja może również współpracować z rzeczywistymi routerami Cisco. Scenariusze laboratorium są przechowywane jako zestaw dwóch, zgodnych plików konfiguracyjnych. Pierwszy z tych plików (.net) przechowuje konfigurację niezbędną do uruchomienia emulatora. Zawiera informację o routerach i połączeniach między nimi. Drugi plik (.xml) utrzymuje dane potrzebne aplikacji do wizualizacji scenariusza, jak również dane potrzebne do nawiązania łączności Telnet i SNMP z routerami. W tym pliku znajduje się również definicja testów, których automatyczne przeprowadzenie przez aplikację pozwala w szybki i dokładny sposób określić postęp studentów w wykonywaniu laboratorium. Na Rys. F.1 znajduje się szkic architektury zaprojektowanego środowiska laboratoryjnego. 153

154 F Środowisko laboratoryjne podręcznik administratora Rys. F.1 Architektura rozwiązania F.2 Wdrożenie środowiska Proces wdrożenia zaprojektowanego środowiska laboratoryjnego składa się z następujących kroków: Instalacja emulatora Aby zainstalować emulator Dynagen należy pobrać aktualną wersję instalatora programu ze strony [1]. Pakiet instalatora zawiera zarówno sam emulator routerów Cisco Dynagen jak i jego front-end w postaci konsoli Dynamips. Jedynym dodatkowym wymogiem jest instalacja narzędzia sieciowego WinPcap. Opis instalacji jest szczegółowo zdefiniowany na stronie internetowej emulatora. Po zainstalowaniu emulatora należy skopiować do folderu \Dynamips\images\ plik z obrazem systemu operacyjnego IOS Cisco. Klienci Cisco mają dostęp do obrazów wszystkich systemów operacyjnych za pośrednictwem serwisu internetowego. Integracja emulatora z komputerem Warunkiem koniecznym współpracy aplikacji wspomagającej przeprowadzanie laboratorium z emulatorem Dynagen jest jego zintegrowanie z interfejsem loopback 154

155 komputera. Dzięki temu połączeniu, istnieje możliwość komunikacji SNMP (wymaganej do prezentacji obecnej konfiguracji i stanu routerów na ekranie aplikacji, a także do oceny postępu konfiguracji na potrzeby wystawienia oceny za laboratorium) i komunikacji Telnet (wymaganej do połączenia z konsolą Cisco routerów i wprowadzania poleceń konfiguracyjnych przez studentów) pomiędzy aplikacją a emulowanymi routerami. Proces instalacji usługi loopback zostanie przedstawiony na przykładzie systemu operacyjnego Windows 7. Aby uruchomić usługę Microsoft Loopback należy: Wejść do ekranu Menedżer Urządzeń -> prawym przyciskiem myszy kliknąć na korzeń drzewa (nazwę komputera) -> wybrać opcję Dodaj starszy sprzęt (zob. Rys. F.2) Rys. F.2 Instalacja adaptera loopback Przycisk Dalej -> wybrać opcję wyboru sprzętu z listy -> Karty sieciowe -> Producent Microsoft -> Karta Microsoft Loopback Efektem tego powinno być pojawienie się nowo zainstalowanej karty sieciowej loopback w oknie Menedżera Urządzeń (zob. Rys. F.3) Rys. F.3 Zainstalowana karta sieciowa loopback Po zainstalowaniu interfejsu loopback należy pobrać jego adres. Możemy to wykonać uruchamiając skrypt Network device list.cmd, który jest instalowany na naszym komputerze wraz z emulatorem Dynamips (skrót do niego domyślnie pojawia się na pulpicie). 155

156 F Środowisko laboratoryjne podręcznik administratora Po uruchomieniu tego skryptu w oknie cmd pojawia się listing urządzeń sieciowych wraz z ich adresami (zob. Rys. F.4). Wyszukujemy urządzenie o opisie: Desciption: MS LoopBack Driver kopiujemy jego adres. Będzie on potrzebny przy konstruowaniu pliku definiującego scenariusz emulowanego laboratorium.net. Adres jest postaci: NIO_gen_eth:\Device\NPF_{D523BAE5-70C7-49E6-B224-C489E9A8C5BC} Rys. F.4 Pobieranie adresu loopback Instalacja aplikacji Aplikacja wspomagająca konfigurację będąca integralną częścią środowiska laboratoryjnego jest dostarczana w postaci skompilowanej. Nie wymaga instalacji jako takiej. Aplikację uruchamiamy plikiem wykonywalnym.exe. F.3 Definiowanie scenariusza Scenariusz ćwiczenia składa się z dwóch plików plik.net definiuje routery oraz łącza między nimi i jest przeznaczony wyłącznie dla emulatora Dynamips, natomiast plik.xml zawiera wszystkie niezbędne informacje przeznaczone dla aplikacji. Składnia pliku.net opisana jest w załączniku A. Plik z rozszerzeniem.xml przechowuje informacje wymagane do działania aplikacji. Format XML pozwala na łatwą edycję danych, co jest szczególnie ważne przy definiowaniu 156

157 testów wykorzystywanych do weryfikacji ćwiczenia. Podczas tworzenia nowego scenariusza można posłużyć się dowolnym edytorem plików.xml, aby uprościć proces dodawania nowych testów i wypełniania wartości atrybutów. Na rys. F.5 przedstawiono fragment przykładowego pliku wejściowego aplikacji. Rys. F.5 Plik wejściowy aplikacji w formacie XML Plik rozpoczyna się podstawowymi informacjami dotyczącymi scenariusza laboratoryjnego. Podane są nazwa, wersja, autorzy, data powstania oraz opis laboratorium. <scenario name="" version="" author="" date="" description=""> Następnie opisane są routery wchodzące w skład sieci laboratoryjnej. Każdy router charakteryzowany jest przez następujące parametry: nazwa prezentowana na ekranie wizualizacji aplikacji współrzędne X i Y określające położenie routera na ekranie wizualizacji aplikacji (wartości współrzędnych automatycznie są skalowane przez aplikację) informacje dot. komunikacji dane wymagane do połączenia się z danym routerem poprzez protokoły Telnet i SNMP. Składają się na nie: adres IP interfejsu 157