Ataki na SDN i sposoby obrony

Wdrożenia, protokoły i oprogramowanie SDN są nowe, a historia ataków na te systemy bardzo krótka. Jednak na podstawie architektury SDN można przewidzieć, gdzie uderzą hakerzy.

Firmy przygotowujące się do wdrożenia SDN (Software Defined Network) analizują, m.in. kwestie bezpieczeństwa. Przedsiębiorstwa chcą wiedzieć, w jaki sposób produkty SDN chronią aplikacje, infrastrukturę i dane. Wprowadzenie do firmowego środowiska IT rozwiązań SDN wiąże się z wdrożeniem nowej strategii zabezpieczania transmisji danych w sieci. Aby była skuteczna, trzeba znać wektory ataków specyficzne dla systemów SDN i sposoby ochrony współdzielonej, zwirtualizowanej infrastruktury sieciowej.

Kierunki ataków na SDN

Koncepcja SDN mówi o oddzieleniu warstwy kontrolnej sieci od warstwy przesyłania danych. Jest to nowe spojrzenie na wirtualizację sieci. Większość modeli SDN składa się z trzech warstw: najniższa warstwa to urządzenia sieciowe z obsługą SDN, warstwa środkowa to kontroler SDN, a najwyższa warstwa obejmuje aplikacje i usługi, które odpowiadają za konfigurowanie i zarządzanie systemem SDN.

Zobacz również:

  • IDC CIO Summit – potencjał drzemiący w algorytmach

Chociaż większość systemów SDN jest stosunkowo nowa, a technologia ta znajduje się na wczesnym etapie rozwoju, można być pewnym, że wraz z dojrzewaniem i rosnącą liczbą wdrożeń, stanie się celem dla cyberprzestępców. Można wyróżnić kilka kierunków ataków na systemy SDN. Najczęściej poruszane kwestie bezpieczeństwa SDN dotyczą różnych warstw architektury tych systemów.

Ataki w warstwie transmisji danych

Atakujący mogą obierać za cel elementy sieci z wcześniej „zdobytych” miejsc w tej sieci. Teoretycznie haker może uzyskać nieautoryzowany fizyczny lub wirtualny dostęp do sieci lub złamać zabezpieczenia urządzenia końcowego podłączonego do systemu SDN, a następnie próbować eskalować atak, aby zdestabilizować inne elementy sieci. Może to być, np. rodzaj ataku DoS.

Jest wiele interfejsów API i protokołów, które kontroler wykorzystuje do komunikacji z elementami sieci. Ta komunikacja może się odbywać z wykorzystaniem OpenFlow (OF), Open vSwitch Database Management Protocol (OVSDB), Path Computation Element Communication Protocol (PCEP), Interface to the Routing System (I2RS), BGP-LS, OpenStack Neutron, Open Management Infrastructure (OMI), Puppet, Chef, Diameter, Radius, NETCONF, Extensible Messaging and Presence Protocol (XMPP), Locator/ID Separation Protocol (LISP), Simple Network Management Protocol (SNMP), CLI, Embedded Event Manager (EEM), Cisco onePK, Application Centric Infrastructure (ACI), Opflex, a to tylko najpopularniejsze. Każdy z tych protokołów ma wbudowane własne metody zabezpieczania komunikacji pomiędzy urządzeniami sieciowymi. Jednakże wiele z tych protokołów powstało niedawno i ich implementacje mogą zawierać wiele niedociągnięć rzutujących na bezpieczeństwo.

Atakujący może również wykorzystać te protokoły, aby do tablic przepływów urządzeń sieciowych dodać nowe wpisy. Atakujący może również próbować modyfikować nowe przepływy tak, aby zezwolić na określony typ komunikacji sieciowej, który został wcześniej wykluczony w danej sieci.

Jeśli atakujący jest w stanie zainicjować przepływ, który ominie mechanizmy sterowania ruchem przepuszczające komunikację sieciową przez firewall, zyska sporą przewagę. Jeśli atakujący jest w stanie tak pokierować ruchem, żeby ten przechodził preferowanymi przez niego łączami sieciowymi, wtedy może wykorzystać tę możliwość do przechwytywania ruchu sieciowego i przeprowadzać ataki typu Man in the Middle.

Atakując może podsłuchiwać komunikację sieciową, aby sprawdzić, jakiego rodzaju transmisja ma miejsce i jaki rodzaj ruchu jest dozwolony w danej sieci. Atakujący może również podsłuchiwać komunikację między kontrolerem a urządzeniami sieciowymi. Zdobyte w ten sposób informacje mogą być przydatne do przeprowadzenia ponownego ataku lub po prostu jako rekonesans.

Wiele systemów SDN jest wdrażanych w centrach danych, w których częściej stosuje się protokoły Data Center Interconnect (DCI), do których zaliczają się Generic Routing Encapsulation (NVGRE), Stateless Transport Tunneling (STT), Virtual Extensible LAN (VXLAN), Cisco Overlay Transport Virtualization (OTV), Layer 2 Multi-Path (L2MP), rodzina protokołów TRILL (Cisco FabricPath, Juniper QFabric, Brocade VCS Fabric), Shortest Path Bridging (SPB), itd. Te protokoły mogą nie mieć mechanizmu uwierzytelniania lub algorytmów szyfrowania, aby zabezpieczać zawartość przesyłanych pakietów. Te nowe protokoły mogą zawierać podatności powstałe na etapie ich projektowania lub w fazie implementacji. Haker może podejmować próby generowania fałszywego ruchu, który będzie próbował przechodzić przez łącza DCI lub będzie atakiem DoS na te łącza.

Ataki w warstwie kontrolera

To oczywiste, że kontroler SDN również może być celem ataku. Haker może próbować atakować kontroler SDN z kilku powodów. Jest to, m.in. sposób, inicjować nowe przepływy sieciowe poprzez wysyłanie fałszywych komunikatów do urządzeń sieciowych. Jeśli włamywacz jest w stanie z powodzeniem podszyć się pod uprawnione przepływy wychodzące z kontrolera, wtedy będzie miał możliwość inicjowania komunikacji w obrębie systemu SDN. Będzie również potencjalnie w stanie omijać zabezpieczenia i reguły bezpieczeństwa.

Przeprowadzając atak DoS na kontroler lub inny rodzaj ataku, włamywacz może próbować doprowadzić do awarii tego urządzenia. Próba wyczerpania zasobów sprzętowych dostępnych dla kontrolera może mieć na celu spowodowanie przerwy w jego pracy lub ekstremalne wydłużenie czasu odpowiedzi na przychodzące pakiety.

Często kontroler SDN pracuje pod kontrolą Linuksa. Jeśli jest to system ogólnego przeznaczenia, powszechnie znane podatności tego systemu będą zagrażać również kontrolerowi. Wyjątkowo złą, ale nierzadko spotykaną praktyką jest stosowanie domyślnych haseł w kontrolerze i nie wprowadzanie zmian w ustawieniach związanych z bezpieczeństwem. Administratorom SDN zdarza się uruchamiać system w produkcyjnym środowisku i nie modyfikować jego konfiguracji z obawy, że to może negatywnie wpłynąć na jego działanie.

Na koniec, niebezpieczną sytuacją jest również uruchomienie przez hakera własnego kontrolera, który urządzenia sieciowe mogą wziąć są uprawniony kontroler. W ten sposób włamywacz ma sposobność zmienić wpisy w tablicach połączeń różnych urządzeń sieciowych, a administratorzy sieci nie będą mieli wglądu w te przepływy z perspektywy produkcyjnego kontrolera SDN. W takim przypadku włamywacz będzie miał kompletną kontrolę nad siecią.

Ataki w warstwie SDN

Ataki na protokoły specyficzne dla SDN to kolejna płaszczyzna ataku. Jest wiele interfejsów API, wykorzystywanych przez kontroler SDN. Zaliczają się do nich, m.in. Python, Java, C, REST, XML, JSON. Jeśli atakujący potrafi wykorzystać podatności tych API, wtedy może przejąć kontrolę nad siecią SDN za pośrednictwem kontrolera. Jeśli kontroler nie ma żadnych zabezpieczeń przed atakami na interfejsy API, wtedy atakujący może mieć możliwość utworzenia własnych reguł SDN i w ten sposób przejąć kontrolę nad środowiskiem SDN.

Często administratorzy pozostawiają domyślne hasła dla REST API, które są proste do ustalenia. Jeśli podczas wdrażania systemu SDN nie zmieniono tych haseł, atakujący otrzymuje możliwość wysyłania pakietów do interfejsu zarządzania kontrolerem, co z kolei umożliwia odczytanie i modyfikację konfiguracji środowiska SDN.

Hartowanie systemu SDN

Systemy SDN wymagają nowych metod zabezpieczania warstwy kontrolnej ruchu sieciowego. W tradycyjnych sieciach IP zabezpieczenia warstwy kontrolnej są zaimplementowane jako mechanizmy protokołów routingu i obejmą takie rozwiązania, jak sumy kontrolne MD5 (EIGRP, IS-IS, OSPFv2) IPsec AH (OSPFv3) GTSM, listy kontroli dostępu, hasła (MP-BGP). Niektóre proste implementacje nie uwzględniają nawet tych podstawowych technik stosowanych w tradycyjnych sieciach IP. Jeśli podobne podejście zastosować do wdrożeń SDN, jest to wystawianie się na atak. Są jednak sposoby zabezpieczenia systemów SDN.

Zabezpieczenia w warstwie danych

Typowy system SDN wykorzystuje procesory x86 oraz szyfrowanie TLS (wcześniej SSL) do zabezpieczenia komunikacji w warstwie kontrolnej. Te sesje HTTP są podatne na szeroką gamę ataków, które mogą naruszać integralność warstwy danych. To umożliwia omijanie zabezpieczeń stosowanych w środowiskach wielozadaniowych i włamywanie do usług chmurowych. Firmy powinny stosować protokół TLS do uwierzytelniania i szyfrowania komunikacji między urządzeniami sieciowymi a kontrolerem. Używanie TLS pomaga w uwierzytelnianiu kontrolera i urządzeń sieciowych, co zapobiega podsłuchiwaniu czy podszywaniu się pod uprawnioną komunikację.

W zależności od stosowanych protokołów są różne sposoby zabezpieczenia komunikacji. Niektóre protokoły mogą działać wewnątrz sesji TLS. Inne protokoły mogą korzystać ze współdzielonych lub jednorazowych haseł, aby zapobiegać powtórnym atakom. Takie protokoły, jak SNMPv3, oferują wyższy poziom bezpieczeństwa niż SNMPv2c, a SSH jest znacznie lepszy niż Telnet. Inne zamknięte protokoły mają wbudowane własne metody uwierzytelniania urządzeń sieciowych i kontrolerów oraz szyfrowania komunikacji między nimi.

Podobnie, w zależności od protokołów Data Center Interconnect (DCI), dostępne są różne opcje uwierzytelniania urządzeń znajdujących się na końcu tunelowanej komunikacji oraz zabezpieczania komunikacji wewnątrz tunelu. Jedną z opcji jest również w tym przypadku stosowanie haseł. Jednakże niektóre protokoły DCI nie mają wbudowanych żadnych mechanizmów bezpieczeństwa.

Wśród części informatyków panuje przekonanie, że sieci lokalne charakteryzują się pewnym nieodłącznym bezpieczeństwem. Jeśli jednak firmy zaczynają rozszerzać swoje środowisko IT o sieci wirtualne, systemy SDN, usługi chmurowe czy zdalne lokalizacje, weryfikacja bezpieczeństwa fizycznego wcale nie jest taka łatwa. Zapobieganie nieuprawnionemu dostępowi jest łatwiejsze, jeśli firma jest w stanie kontrolować dostęp fizyczny, ale w sieciach wirtualnych fizyczny przebieg połączeń sieciowych staje się mniej oczywisty. A trudno jest zabezpieczyć coś, czego nie można zobaczyć.

Zabezpieczenia w warstwie kontrolnej

Kontroler jest głównym celem ataków, dlatego jego zabezpieczenia wymagają wzmocnienia. Polega to przede wszystkim na poprawieniu zabezpieczeń systemu operacyjnego, pod kontrolą którego to urządzenie działa. Zastosowanie znajdują wszystkie praktyki związane z hartowaniem serwerów linuksowych. Jednak nadal firmy powinny dokładnie monitorować kontrolery SDN pod kątem jakiejkolwiek podejrzanej aktywności.

Należy zapobiegać nieautoryzowanemu dostępowi do sieci kontrolującej system SDN. Należy stosować mechanizmy umożliwiające wdrożenie bezpiecznego i uwierzytelnionego dostępu administratorów do kontrolera. Konieczne może być zastosowanie kontroli dostępu RBAC (Role-Based Access Control). Rejestry (logi) oraz audyty mogą być pomocne w wykrywaniu nieautoryzowanych zmian wprowadzonych zarówno przez administratorów, jak i hakerów.

Zabezpieczenia w warstwie SDN

Kolejnym środkiem ochrony jest stosowanie zabezpieczeń poza ścieżką ruchu (Out-of-Band). Stosowanie takich zabezpieczeń jest łatwiejsze do zbudowania w centrach danych niż w przypadku łączy WAN. Można je stosować do zabezpieczenia protokołów używanych do zarządzania kontrolerem. Dobrą praktyką jest również stosowanie szyfrowania TLS lub SSH do zabezpieczenia komunikacji z kontrolerem. Natomiast komunikacja od aplikacji do kontrolera powinna być zabezpieczona szyfrowaniem i uwierzytelnianiem.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200