Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00278 005598 18999573 na godz. na dobę w sumie
Kali Linux. Testy bezpieczeństwa, testy penetracyjne i etyczne hakowanie - książka
Kali Linux. Testy bezpieczeństwa, testy penetracyjne i etyczne hakowanie - książka
Autor: Liczba stron: 328
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-5426-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> hacking >> bezpieczeństwo systemów
Porównaj ceny (książka, ebook (-35%), audiobook).

Kali Linux jest specjalistyczną dystrybucją systemu Linux, którą przeznaczono do celów związanych z bezpieczeństwem IT. Udostępnia kilkaset narzędzi do między innymi testowania zabezpieczeń, tworzenia eksploitów, dekodowania aplikacji lub po prostu śledzenia nadużyć i incydentów bezpieczeństwa. Sporo z tych narzędzi pozwala na stosowanie zaawansowanych praktyk, takich jak testy penetracyjne czy techniki inżynierii wstecznej. Szerokie możliwości Kali mogą jednak przytłaczać nawet biegłych specjalistów. Tymczasem zapewnienie bezpieczeństwa IT wymaga wiedzy i umiejętności wyboru programu najwłaściwszego do wykonania potrzebnego testu.

Ta książka jest praktycznym przewodnikiem po systemie Kali Linux, zawierającym szczegółowe informacje o jego możliwościach. Najwięcej uwagi poświęcono udostępnianym w nim narzędziom, które nie są zbyt popularne w innych dystrybucjach Linuksa. Poza podstawami budowy i działania systemu Kali Linux opisano tu metody testowania sieci, aplikacji WWW, sieci bezprzewodowych, siły haseł itp. Pokazano też różne techniki rozszerzania systemu o nowe narzędzia i tworzenia ich własnych zestawów, w pełni odpowiadających specyficznym potrzebom. Równolegle w książce omówiono zagadnienia bezpieczeństwa systemów IT, w tym ich podatności, które wskazują na potrzebę przeprowadzania odpowiednich testów.

W tej książce:

Kali Linux - dowiedz się, jak bezpieczny jest Twój system!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Learning Kali Linux: Security Testing, Penetration Testing, and Ethical Hacking Tłumaczenie: Andrzej Watrak ISBN: 978-83-283-5426-5 © 2019 Helion S.A. Authorized Polish translation of the English edition of Learning Kali Linux ISBN 9781492028697 © 2018 O’Reilly Media Inc. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Helion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Helion SA ul. Kościuszki 1c, 44-100 Gliwice tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/kalite Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Przedmowa .............................................................................................................................7 1. Podstawy systemu Kali Linux ...................................................................................13 13 14 16 19 25 34 34 36 38 41 41 Geneza systemu Linux O systemie Linux Uzyskanie i instalacja systemu Kali Linux Środowiska graficzne Wiersz poleceń Zarządzanie kontami użytkowników Zarządzanie usługami Zarządzanie pakietami Zarządzanie dziennikami Podsumowanie Przydatne materiały 2. Podstawy testowania bezpieczeństwa sieci .......................................................... 43 43 45 58 62 69 73 73 Testy bezpieczeństwa Testy bezpieczeństwa sieci Testowanie szyfrowania Przechwytywanie pakietów Ataki podsłuchowe Podsumowanie Przydatne materiały 3. Rekonesans ................................................................................................................75 75 77 88 95 Czym jest rekonesans? Biały wywiad Rekonesans systemu DNS i usługa whois Rekonesans pasywny 3 Poleć książkęKup książkę Skanowanie portów Skanowanie usług Podsumowanie Przydatne materiały 96 102 105 106 4. Wyszukiwanie podatności na ataki ........................................................................107 107 108 112 117 127 130 131 133 134 Co to jest podatność? Typy podatności Lokalne podatności Zewnętrzne podatności Podatności urządzeń sieciowych Podatności baz danych Wykrywanie nieznanych podatności Podsumowanie Przydatne materiały 5. Automatyczne eksploity .........................................................................................135 135 136 138 139 141 150 152 154 155 Czym jest eksploit? Ataki na urządzenia Cisco Ataki na inne urządzenia Baza eksploitów Metasploit Armitage Inżynieria społeczna Podsumowanie Przydatne materiały 6. Więcej o platformie Metasploit ..............................................................................157 157 163 165 170 173 175 178 179 Wyszukiwanie obiektów ataku Eksploracja testowanego obiektu Interfejs Meterpreter Rozszerzanie uprawnień Ekspansja do innych sieci Utrzymanie dostępu Podsumowanie Przydatne materiały 4  Spis treści Poleć książkęKup książkę 7. Testowanie bezpieczeństwa sieci bezprzewodowych ......................................... 181 181 184 192 198 204 209 210 210 Dziedzina łączności bezprzewodowej Ataki na sieci wi-fi i narzędzie testujące Łamanie haseł do sieci bezprzewodowych Podszywanie się Testowanie protokołu Bluetooth Testowanie protokołu Zigbee Podsumowanie Przydatne materiały 8. Testowanie aplikacji WWW .................................................................................... 211 211 215 222 234 241 245 246 247 Architektura aplikacji WWW Ataki na strony WWW Serwery proxy Automatyzacja ataków na strony WWW Wstrzykiwanie zapytań SQL Inne testy Podsumowanie Przydatne materiały 9. Łamanie haseł ......................................................................................................... 249 249 252 255 264 266 269 269 Magazyn haseł Pozyskiwanie haseł Lokalne łamanie haseł Zdalne łamanie haseł Łamanie aplikacji WWW Podsumowanie Przydatne materiały 10. Zaawansowane techniki i pojęcia ..........................................................................271 272 278 282 284 287 294 297 297 Podstawy programowania Błędy w kodzie Tworzenie modułów Nmap Rozszerzenie platformy Metasploit Deasemblacja i inżynieria odwrotna Utrzymywanie dostępu i zacieranie śladów Podsumowanie Przydatne materiały Spis treści  5 Poleć książkęKup książkę 11. Raportowanie ......................................................................................................... 299 299 301 305 309 313 314 Określenie prawdopodobieństwa i istotności zagrożenia Pisanie raportu Robienie notatek Porządkowanie danych Podsumowanie Przydatne materiały Skorowidz ...........................................................................................................................315 6  Spis treści Poleć książkęKup książkę ROZDZIAŁ 2. Podstawy testowania bezpieczeństwa sieci Testy bezpieczeństwa to szeroki temat obejmujący wiele różnych zagadnień. Niektóre z nich doty- czą bezpieczeństwa sieci, ale celem testów nie zawsze jest sprawdzanie podatności systemów na włamania. Testy mogą dotyczyć możliwości pogorszenia jakości usług sieciowych, na przykład prze- rwania działania usługi lub utraty jej dostępności. Brak usługi oznacza zagrożenie bezpieczeństwa systemu. Dlatego test obciążeniowy usługi jest ważnym elementem testu bezpieczeństwa. Aby przeprowadzić test bezpieczeństwa obejmujący nie tylko aplikacje, lecz także różne elementy sie- ciowe, trzeba znać strukturę stosu protokołów. Jedną z definicji stosu protokołów sieciowych, a do- kładniej interakcji między nimi, jest model OSI (ang. Open Systems Interconnection, łączenie systemów otwartych). W tym modelu komunikacja sieciowa jest podzielona na osobne bloki funkcjonalne, w których do tworzonych pakietów danych dodawane są różnego rodzaju informacje. Ponadto model opisuje interakcje pomiędzy systemem operacyjnym a powyższymi blokami funkcjonalnymi. Podczas wykonywania testów obciążeniowych nie tylko uzyskuje się mnóstwo informacji o faktycz- nej wydajności systemu i aplikacji, lecz także otrzymuje się nieoczekiwane wyniki. Testy mogą polegać na zamierzonym łamaniu zasad komunikacji klientów z aplikacją lub systemem. Wiele ataków prze- prowadzanych jest właśnie w ten sposób. W wyniku testów aplikacje mogą ulegać awariom, na przy- kład przerywać swoje działanie lub zgłaszać wyjątki, które potencjalnie mogą zostać wykorzystane do włamania się do aplikacji lub systemu. Testy bezpieczeństwa Wiele osób, używając terminu testy bezpieczeństwa, ma na myśli testy penetracyjne, których celem jest uzyskanie dostępu do systemu z najwyższymi możliwymi uprawnieniami. Jednak testy bezpieczeństwa obejmują nie tylko „otwieranie pudełek”. Systemy i oprogramowanie są zabezpieczane na wiele innych sposobów, których nie sprawdzają testy penetracyjne. Zanim zajmiemy się możliwościami testowania bezpieczeństwa sieci za pomocą narzędzi dostępnych w systemie Kali, musimy dokładnie określić, czym jest bezpieczeństwo i jego testy w kontekście tego systemu. Specjaliści od IT, w szczególności w instytucjach wydających certyfikaty bezpieczeństwa, często odnoszą się do tzw. triady. Niektórzy dodają do niej dodatkowe elementy, ale rdzeń bezpieczeństwa informacji zawsze pozostaje ten sam: poufność, spójność i dostępność. Jeżeli zostanie naruszona którakolwiek z tych cech, zagrożone będzie bezpieczeństwo systemu lub oprogramowania. Testy 43 Poleć książkęKup książkę bezpieczeństwa powinny uwzględniać te trzy cechy i nie ograniczać się jedynie do pozyskiwania informacji typowych dla testów penetracyjnych. Jak wiesz, triadę zazwyczaj przedstawia się jako trójkąt równoboczny. Oznacza to, że wszystkie trzy elementy są tak samo ważne. Co więcej, jeżeli któregokolwiek z tych elementów zabraknie, trójkąt przestanie istnieć. Rysunek 2.1 w sposób typowy przedstawia triadę jako trójkąt o równych bokach. Każda z podanych cech ma równie istotny wpływ na rzetelność i wiarygodność informacji. Dzisiaj, gdy dane biznesowe i osobowe są przechowywane w formie cyfrowej, bardzo ważne jest, aby były one dostępne, poufne (gdy jest taka potrzeba) oraz spójne. Rysunek 2.1. Triada poufność — spójność — dostępność Większość firm przetwarza własne poufne dane. Poufne są też dane osobowe, na przykład numery dowodów osobistych, hasła, numery PESEL, dane medyczne i różnego innego rodzaju informacje. Firmy muszą chronić swoją własność intelektualną. Mają swoje sekrety handlowe, których upublicz- nienie negatywnie wpłynęłoby na ich działalność. Ograniczona dostępność tych informacji, niezależ- nie od ich charakteru, jest określana mianem poufności. Jeżeli informacja wydostanie się poza miejsce, w którym jest bezpiecznie przechowywana, zostanie naruszona jej poufność. Poufność to podstawowy element bezpieczeństwa informacji naruszany w przypadku jej kradzieży, co się niezwykle często zdarza w różnych firmach i instytucjach; przykładem jest Target, Equifax, Sony i amerykański Office of Personnel Management (Urząd Zarządzania Kadrami). Jeżeli dane osobowe zostaną wykradzione, zostanie naruszone ich bezpieczeństwo. Przechowując jakąś informację, zazwyczaj musimy jednocześnie mieć możliwość jej odczytywania. Dane mogą zostać uszkodzone lub zmienione z różnych powodów, nie zawsze wynikających z czyjejś złej woli. Zagrożenie bezpieczeństwa nie zawsze jest związane z wrogimi intencjami. Oczywiście wspomniana wcześniej kradzież informacji stanowiła zagrożenie. Jednak niewłaściwie funkcjonująca pamięć komputera może spowodować uszkodzenie danych zapisanych na dysku. Wiem to z własnego doświadczenia. Awaria dysku lub innego nośnika również może być przyczyną uszkodzenia danych. Oczywiście w szczególnych przypadkach rozmyślnie szkodliwe operacje mogą skutkować uszkodze- niem i zakłóceniem przetwarzania danych. Niezależnie jednak od tego, co było przyczyną, efektem jest zakłócenie ich spójności. Spójność oznacza, że wszystkie informacje znajdują się w stanie, w którym powinny się znajdować. 44  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę Rozważmy jeszcze dostępność danych. Jeżeli komputer spadnie na podłogę i wypadnie wtyczka z gniazdka zasilającego, komputer przestanie być dostępny (mam na myśli komputer stacjonarny, bez baterii). Podobnie, jeżeli zatrzask w przewodzie sieciowym ulegnie uszkodzeniu i przewód wy- padnie z gniazdka w ścianie lub z karty komputera, Twój system przestanie być dostępny w sieci. Oczywiście zdarzenie to będzie miało wpływ przede wszystkim na Twoją pracę, ale może również dotyczyć innych osób, które korzystają z danych zapisanych na Twoim komputerze. Jeśli serwer ulegnie awarii, zakłócona zostanie dostępność znajdujących się na nim informacji. Jeżeli haker spowo- duje awarię usługi lub całego systemu, nawet krótkotrwałą, zakłócona zostanie dostępność danych, co może mieć poważny wpływ na funkcjonowanie firmy. Klienci nie będą wtedy mieć dostępu do usług i trzeba będzie zainwestować w ludzi i zasoby, aby usługi znów zaczęły działać i były dostępne. Tak jest w przypadku banków, które stały się obiektami zmasowanych, długotrwałych ataków DoS (ang. denial of service, blokada usługi). Ataki wprawdzie mogą się nie powieść, ale na pewno odpiera- nie ich ma negatywny wpływ na funkcjonowanie firmy. Testowanie bezpieczeństwa informacji oznacza testowanie jej opisanych wyżej cech. Forma testów nie jest istotna. Testy bezpieczeństwa sieci mogą dotyczyć podatności usługi na ataki, skuteczności szyfrowania informacji i innych czynników. Na początku do przeprowadzenia testów bezpieczeństwa sieci potrzebne są narzędzia do wykonywania testów obciążeniowych. Pożądane są też narzędzia, które mogą spowodować awarię sieci. Choć na przestrzeni lat wiele błędów w stosie protokołów sie- ciowych i systemach operacyjnych zostało usuniętych, wciąż mogą być stosowane proste urządzenia, które są bardziej podatne na ataki sieciowe. Takimi urządzeniami są na przykład drukarki, telefony IP, termostaty, lodówki, a także każdy inny sprzęt podłączany do internetu. Testy bezpieczeństwa sieci Z siecią jesteśmy związani na śmierć i życie. Mnóstwo danych osobowych jest dzisiaj gromadzonych w internecie lub jest dostępnych przez internet w tzw. chmurze. Dzisiaj oczekujemy, że wszystko będzie można znaleźć w sieci. Dlatego bardzo ważne jest, aby urządzenia, z których korzystamy, były odporne na ataki. Monitoring Zanim zaczniemy wykonywać testy, musisz poznać ważny temat monitoringu. Przede wszystkim testowanie bezpieczeństwa sieci w Twojej lub klienta firmie nie może skutkować awarią wszystkich urządzeń, chyba że wyraźnie zostaniesz o to poproszony. Niemniej jednak pomimo zachowania najwyższej ostrożności coś może pójść nie tak i usługi albo systemy zostaną zablokowane. Dlatego bardzo ważne jest powiadomienie osób opiekujących się infrastrukturą IT, aby sprawowały kontrolę na systemami i usługami. Właściciele firm nie chcą, aby zakłócana była obsługa ich klientów, dlatego życzą sobie, by podczas testów były obecne osoby, które w razie potrzeby zrestartują usługi. Niektóre firmy chcą sprawdzać skuteczność pracowników zarządzających siecią. Oczekują wtedy włamania się do jakiegoś systemu lub wywołania jego awarii bez po- wodowania długotrwałych zakłóceń ani tym bardziej trwałych uszkodzeń. W takim wypadku nie informuj o testach nikogo oprócz menedżerów, którzy zlecili Ci ich wykonanie. W większości przypadków firmy chcą mieć pewność, że ich środowisko produkcyjne działa nieprzerwanie. Testy bezpieczeństwa sieci  45 Poleć książkęKup książkę Jeżeli w przeprowadzanie testów zaangażowany jest zespół IT, musisz w jakiś sposób monitorować systemy. Możesz w tym celu śledzić wpisy w dziennikach, co jest ogólnie zalecaną metodą. Dzienniki jednak nie są niezawodnym źródłem informacji. Jeśli będziesz w stanie wywołać awarię usługi, może ona nie zdążyć zapisać w dzienniku użytecznej informacji o problemie. Nie oznacza to jednak, że mo- żesz zrezygnować ze śledzenia dzienników. Pamiętaj, że celem testów jest poprawa bezpieczeństwa firmy, w której pracujesz. Dzienniki mogą zawierać kluczowe informacje o tym, co się działo z daną usługą, zanim uległa awarii. Problem może polegać nie na tym, że jej procesy przestały działać, ale że działały niezgodnie z oczekiwaniami. W takich sytuacjach dzienniki odgrywają istotną rolę w diagno- zowaniu, co się działo z aplikacją. Czasami do kontrolowania działania procesów stosowane są programy nadzorujące (ang. watchdog). Jeżeli jakiś proces zostanie przerwany, jego identyfikator PID nie zostanie usunięty z listy i program nadzorujący uruchomi go ponownie. Ponadto program nadzorujący można wykorzystywać do spraw- dzania, czy proces ulegnie awarii. Nawet jeżeli nie trzeba będzie go ponownie uruchamiać, można kontrolować tablicę procesów i sprawdzać, czy coś niepokojącego się z nimi nie dzieje. Niekontrolowane procesy mogą zająć wszystkie zasoby systemu. Dlatego bardzo ważne jest obser- wowanie obciążenia procesora i zajętości pamięci. Można użyć do tego celu bezpłatnych narzędzi monitorujących, narzędzi komercyjnych lub w przypadku systemów Windows i macOS wbudowa- nych narzędzi diagnostycznych. Jednym z popularnych programów monitorujących jest Nagios. Zainstalowałem go w jednym ze swoich wirtualnych systemów. Rysunek 2.2 przedstawia widok jednego z okien. Bez dodatkowej konfiguracji Nagios monitoruje między innymi procesy, obciążenie proce- sora oraz stany usług SSH i HTTP. Rysunek 2.2. Monitoring zasobów systemu Jeżeli z jakiegoś powodu nie będziesz mógł współpracować z zespołem IT, a nie masz bezpośrednie- go dostępu do testowanych systemów, będziesz musiał mieć możliwość przynajmniej zdalnie kontro- lować usługę. Opisywane tu narzędzia do testowania sieci mogą przestać odbierać odpowiedzi z testo- wanych usług, co może — ale nie musi — być oznaką awarii usługi. Może to być symptomem problemu z samym narzędziem monitorującym albo skutkiem zastosowania mechanizmu blokują- cego niepożądaną aktywność w sieci. W takich sytuacjach ważne jest, aby dało się bezpośrednio sprawdzić, czy usługa przestała działać. Notowanie to podstawa Jeżeli podczas testowania usługi stwierdzisz, że przestała działać, postaraj się w miarę możliwości jak najdokładniej zanotować czas awarii. Informowanie klienta lub praco- dawcy o awarii usługi niewiele wnosi, ponieważ mogą oni nie wiedzieć, jak rozwiązać problem. Szczegółowe notatki przydadzą Ci się, gdy będziesz musiał poinformować zespół IT, co dokładnie robiłeś w chwili awarii. Dzięki temu będzie można określić przyczyny problemu i go rozwiązać. 46  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę Testy można wykonywać ręcznie za pomocą narzędzi takich jak netcat, a nawet telnet. Jeżeli uda Ci się nawiązać połączenie z wykorzystywanym przez usługę portem, będziesz miał pewność, że usługa reaguje. Taka ręczna weryfikacja (szczególnie gdy jest wykonywana za pomocą osobnego systemu, który na pewno nie jest blokowany) pozwoli wyeliminować fałszywe symptomy problemów. General- nie testy bezpieczeństwa często polegają na eliminowaniu fałszywych alarmów wynikających ze stosowania różnych narzędzi. Monitorując i weryfikując wyniki, możesz mieć pewność, że dane, które później przedstawisz pracodawcy lub klientowi, będą wiarygodne i pozwolą mu podejmować odpowiednie decyzje. Warstwy Jak stwierdził Osioł w firmie Shrek: warstwy są bardzo ważne. W rzeczywistości Shrek mówił, że ogry mają warstwy, a Osioł mówił, że mają je torty. Shrek porównywał ogra do cebuli, a Osioł uważał, że wszyscy lubią torty, bo są lepsze od cebuli. Do dzisiaj słyszę głos Osła. Oczywiście ani ogry, ani cebule nie są tutaj ważne, ale torty owszem. Mówiąc o sieciach i komunikacji pomiędzy systemami, zazwyczaj mamy na myśli warstwy. Gdy wyobrazisz sobie siedmiowarstwowy tort, łatwiej Ci będzie zrozumieć działanie sieci. Dodatkowo wyobraź sobie dwa kawałki takiego tortu. W końcu dwa kawałki są lepsze niż jeden, prawda? Rysunek 2.3 jest prostą ilustracją siedmiowarstwowego modelu OSI i komunikacji pomiędzy poszcze- gólnymi warstwami dwóch osobnych systemów. Aby rzecz wyglądała ciekawiej, możesz sobie wy- obrazić, że pomiędzy warstwami znajduje się dżem, który je ze sobą skleja. Komunikujące się ze sobą warstwy w obu systemach są dokładnie takie same. Gdy jeden kawałek tortu wysyła komunikat do drugiego, wykorzystuje do tego celu dwie odpowiadające sobie warstwy. Rysunek 2.3. Model OSI i komunikacja między systemami Kontynuujmy przykład z tortami. Na samym dole znajduje się warstwa fizyczna, którą można porów- nać do spodu tortu. Jest to miejsce, w którym system łączy się z siecią, w naszym słodkim przykładzie jest to taca, na której leży tort. Podobnie jak w przypadku tortu pomiędzy warstwą fizyczną systemu a siecią niczego nie ma. Za pomocą przewodu łączy się interfejs sieciowy systemu z gniazdkiem w ścianie. To jest wszystko, co można zrobić w warstwie fizycznej. W przypadku tortu jego spód spo- czywa bezpośrednio na tacy i niczego pomiędzy nimi nie ma. Testy bezpieczeństwa sieci  47 Poleć książkęKup książkę Następną warstwą jest krem, czyli warstwa danych. Od warstwy fizycznej oddziela ją dżem, dzięki któremu system operacyjny może obie warstwy rozróżnić. W warstwie danych stosowane są adresy MAC (ang. Media Access Control — sterowanie dostępem do medium). Pierwsze trzy bajty adresu to identyfikator producenta, tzw. OUI (ang. Organizationally Unique Identifier — unikatowy iden- tyfikator organizacji). Pozostałe trzy bajty (cały adres MAC składa się z sześciu bajtów) tworzą unikatowy identyfikator interfejsu sieciowego. Obie części razem wzięte tworzą adres MAC. Wszelka komunikacja w obrębie lokalnej sieci odbywa się w tej warstwie. Jeżeli warstwa kremu w jednym kawałku tortu chce porozmawiać z warstwą kremu w drugim kawałku (kto inny jak nie krem zrozu- mie inny krem?), musi użyć adresu MAC, ponieważ jest to jedyny adres, który rozumieją interfejsy sieciowe dwóch systemów. Adres jest przypisany do interfejsu, dlatego jest nazywany adresem fizycz- nym. Listing 2.1 przedstawia wynik użycia polecenia ifconfig. Adres MAC jest drugim ciągiem od lewej strony. Listing 2.1. Adres MAC ether 52:54:00:11:73:65 txqueuelen 1000 (Ethernet) Następną warstwą, do której trzeba się dostać poprzez dżem, jest biszkopt, czyli warstwa sieciowa. W tej warstwie stosowane są adresy IP, za pomocą których dane można wysyłać poza lokalną sieć. Adresy MAC w odróżnieniu od adresów IP nigdy nie wydostają się poza lokalną sieć. Torty danej cukierni sprzedawane w różnych punktach są dokładnie takie same, więc mogą się ze sobą komuni- kować za pomocą tej warstwy i adresów IP. Listing 2.2 przedstawia taki przykładowy adres. Składa się on z 4 bajtów, zwanych również oktetami, ponieważ każdy zbudowany jest z ośmiu bitów. W po- niższym przykładzie jest to adres IP w wersji 4 (ciąg drugi od lewej). Adres w wersji 6 składa się z 16 bajtów (128 bitów). Podobnie jak poprzednio listing przedstawia wynik użycia polecenia ifconfig. Listing 2.2. Adres IP inet 192.168.86.35 netmask 255.255.255.0 broadcast 192.168.86.255 Przechodzimy do następnej warstwy, którą jest galaretka (warstwa transportowa). Tak, to jest bardzo nietypowy tort, ale niech tak już zostanie. W tej warstwie stosowane są porty, czyli jeszcze innego rodzaju adresy. Możesz je sobie wyobrazić w następujący sposób. Gdy wejdziesz do cukierni, musisz odnaleźć odpowiednią półkę. Tak samo jest z portami. Jeżeli znajdziesz cukiernię o żądanym adresie IP, musisz w niej znaleźć odpowiednią półkę, czyli port. Port łączy działającą usługę (program) przy- pisaną do danej półki. Niektóre usługi wykorzystują tzw. dobrze znane porty, czyli przeznaczone do określonych zastosowań. Usługa (na przykład strona WWW) może wykorzystywać dowolny port, ale najczęściej jest to port dobrze znany, ponieważ wiadomo wtedy, co usługa oferuje. Warstwa piąta jest dość trudna, ponieważ zazwyczaj jest niewłaściwie opisywana. Jest to mus owocowy, bo w torcie musi być trochę owoców lub choćby ich smaku. Jest to warstwa sesji odpowiedzialna za długotrwałą komunikację i synchronizację stron. Wyobraź sobie, że Ty i ja zaczynamy w tej samej chwili jeść swoje kawałki toru (zaczynamy się komunikować). Zadaniem tej warstwy jest dopilnowanie, abyśmy jedli w tym samym tempie i skończyli w tym samym momencie. Jeżeli któryś z nas chce na chwilę przerwać jedzenie i napić się wody, to warstwa sesji wymusza, abyśmy obaj zrobili to samo w tej samej chwili. Jeżeli któryś z nas zechce napić się mleka zamiast wody, warstwa ta będzie nas synchronizować, abyśmy zaczęli i skończyli pić w tym samym czasie i tak samo wyglądali podczas jedzenia. Bo o wygląd tu głównie chodzi. 48  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę Przechodzimy do warstwy orzechów, bo czymże byłby tort bez masła orzechowego? To jest warstwa prezentacji, która dba o to, aby wszystko wyglądało tak, jak trzeba, na przykład: aby nie było łupinek orzechów i aby to, co wkładamy do ust, wyglądało jak tort. Ostatnią warstwą jest bita śmietana, czyli warstwa aplikacji, znajdująca się najbliżej konsumenta tortu (użytkownika). Warstwa ta odbiera to, co oddaje warstwa prezentacji i przekazuje użytkownikowi do skonsumowania. Ważnym elementem w tej analogii jest widelec, którym odkrawa się kawałki tortu począwszy od warstwy najwyższej, a na najniższej skończywszy. Natomiast do ust wędruje najpierw najniższa warstwa. Tak samo są wysyłane i odbierane komunikaty. Powstają one w warstwie aplikacji, po czym są przesyłane w dół stosu. Komunikat jest konsumowany w najniższej, fizycznej warstwie, a podczas przesyłania do wyższych warstw są z niego zdejmowane kolejne nagłówki. Testowanie sieci polega na pracy z różnymi warstwami tortu. Dlatego ważna jest znajomość każdej z nich. Musisz znać wymagania wszystkich warstw i umieć ocenić, czy działają one prawidłowo. Podczas testów będziesz miał do czynienia z różnymi warstwami, ale zazwyczaj każde narzędzie będzie przeznaczone dla jednej określonej warstwy. Komunikacja sieciowa polega na zjadaniu całego tortu, ale czasami trzeba skupiać się na konkretnej warstwie w oderwaniu od reszty tortu i spraw- dzać, czy ma właściwy smak. Testy obciążeniowe Niektóre programy, a nawet urządzenia, źle sobie radzą poddane dużym obciążeniom. Dzieje się tak z różnych powodów. Sprzęt o konkretnym przeznaczeniu lub urządzenia IoT (ang. Internet of Things, internet rzeczy) z wielu różnych przyczyn mogą nie być w stanie obsłużyć dużego ruchu. Na przy- kład układy elektroniczne w interfejsie sieciowym mogą nie być wystarczająco wydajne, ponieważ producent zakładał, że nigdy nie będą obsługiwać dużego ruchu. Programy mogą zwierać błędy. Nawet oprogramowanie wbudowane w sprzęt może przysparzać problemów, jeżeli będzie niewłaści- wie zaprojektowane. Dlatego ważne jest, aby testerzy bezpieczeństwa mieli pewność, że systemy, za które są odpowiedzialni, nie ulegną awarii, gdy stanie się coś złego. Test bezpieczeństwa można wprost porównać do ataku polegającego na zalaniu urządzenia pakie- tami. Jednak są również inne sposoby obciążania aplikacji. Jeden z nich polega na wysyłaniu danych, których aplikacja się nie spodziewa i „nie potrafi” obsłużyć. Są metody przeciwdziałania tego rodzaju atakom. W tej części rozdziału skupimy się na przeciążaniu systemów, a później zajmiemy się atakami zaburzającymi polegającymi na generowaniu błędnych danych. Czasami stos protokołów w prost- szych urządzeniach może nie być w stanie przetworzyć ruchu, na który nie jest przygotowany. Do ge- nerowania takich danych służy między innymi program fragroute. Program fragroute, którego autorem jest Dug Song, został napisany wiele lat temu. Zawiera zdefi- niowane reguły, według których przetwarza wszystkie pakiety wysyłane na określony adres IP. Za pomocą tego rodzaju narzędzia można dowolnie manipulować pakietami wysyłanym przez sys- tem. Jedną z głównych funkcji programu jest dzielenie wskazanych pakietów na fragmenty, które w docelowym systemie powinny być składane w całość. Jednak nie każdy system jest w stanie przetwo- rzyć naprawdę bardzo zniekształcone fragmenty, szczególnie gdy zachodzą one na siebie. W pakie- cie IP pole identyfikatora służy do wiązania ze sobą wszystkich fragmentów. Fragmenty z tym samym identyfikatorem należą do tego samego pakietu. Inne pole, tzw. przesunięcie, określa miejsce frag- mentu w całym pakiecie. Gdy pierwszy fragment zawiera na przykład bajty o numerach od 0 do 1200, Testy bezpieczeństwa sieci  49 Poleć książkęKup książkę przesunięcie w następnym pakiecie jest równe 1201, co oznacza jednocześnie, że jest to kolejny fragment. Takich fragmentów o mniej więcej podobnej wielkości może być wiele, a stos protokołów w systemie docelowym powinien być w stanie wszystkie je składać w całość niczym elementy ukła- danki. Jeżeli na przykład przesunięcie w jednym fragmencie jest równe 1150, a pakiety zawierają po 1200 bajtów, oznacza to, że kolejny fragment nakłada się na poprzedni. Stos protokołów powinien wtedy odpowiednio przetworzyć takie fragmenty, tzn. nie łączyć ich ze sobą. Niekiedy takie nakła- dające się fragmenty mogą powodować awarię systemu, który nie jest w stanie poradzić sobie z odbie- raniem sprzecznych danych. Listing 2.3 przedstawia plik konfiguracyjny umożliwiający generowanie problematycznego ruchu za pomocą programu fragroute. Listing 2.3. Konfiguracja programu fragroute ip_chaff dup 7 ip_frag 64 new drop random 33 dup random 40 order random print Pierwszy wiersz oznacza, że pomiędzy pakietami będą wysyłane ich duplikaty. Cyfra 7 jest wartością pola TTL (ang. Time to Live, czas życia) i oznacza siedem przeskoków. Z tego względu pakiety mogą być tracone podczas transmisji. Drugi wiersz powoduje dzielenie pakietów na fragmenty o wielkości 64 bajtów. Słowo new oznacza, że fragmenty będą nakładać się na siebie i częściej będą zawierały nowe dane, a rzadziej stare. Liczba 33 oznacza, że 33 pakietów będzie traconych, a liczba 40, że 40 pakietów będą stanowiły losowo wybrane duplikaty. Ponadto program fragroute będzie gene- rował pakiety w dowolnej kolejności, co oznacza, że nie będą tworzyły one poprawnych sekwencji w chwili dotarcia do miejsca przeznaczenia. Ostatni wiersz powoduje, że program będzie wyświetlał szczegółowe informacje o tym, co się dzieje z pakietami. Program uruchamia się poleceniem fragroute -f frag.rules 192.168.5.40. w tym przypadku frag.rules jest nazwą pliku z regułami, a 192.168.5.40 jest adresem urządzenia, do którego będą wysyłane wymieszane pakiety. Powyższe argumenty możesz zmienić odpowiednio do konfiguracji swojego środowiska. Użycie narzędzia takiego jak fragroute z określonym zestawem reguł nie powoduje, że urządzenie docelowe wykona jakąś pożyteczną operację. Nie to jest jednak ważne. Rzecz w tym, aby dowiedzieć się, czy urządzenie właściwie poradzi sobie z odbieranymi pakietami. Czy na przykład zwyczajnie je odrzuci? Czy system operacyjny będzie pracował poprawnie? To są ważne informacje. Zwykłe psu- cie niczego nie da. Musisz umieć udokumentować działanie systemu i wskazać, co trzeba w nim zmienić. Dokładne dokumentowanie pracy jest bardzo ważne, abyś mógł pomyślnie wykonać testy, uzyskał następne zamówienie lub działał dalej. Uwaga etyczna Systemy, nad którymi pracujesz, powinny być Twoją własnością lub musisz mieć pozwolenie na ich testowanie. Dotyczy to w szczególności sytuacji, w których możesz je uszkodzić lub spowodować ich awarię. Wszystko, o czym tu piszę, może do tego do- prowadzić. Testowanie systemów w sytuacji, kiedy nie jesteś ich właścicielem lub nie masz pozwolenia na ich testowanie, jest co najmniej nieetyczne, a czasami nielegalne. Testy, nawet te najprostsze, zawsze mogą spowodować awarię. Musisz dostać na nie pozwolenie na piśmie, zawsze! 50  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę Po przygotowaniu pliku konfiguracyjnego możesz uruchomić program fragroute na komputerze, który ma generować ruch. Jeżeli oferuje on funkcję kierowania ruchem, możesz wysyłać pakiety do różnych sieci. Dzięki temu testy będziesz mógł wykonać za pomocą jednego systemu. Listing 2.4 przedstawia polecenie, którego użyłem do przetestowania obsługi fragmentacji w lokalnej sieci, oraz wyniki, jakie uzyskałem. Testy polegały po prostu na wysyłaniu zapytań ping do systemu docelowego. Równie łatwo można przeprowadzić testy polegające na wysyłaniu zapytań WWW. Listing 2.4. Program fragroute użyty w plikiem reguł root@kali:~# fragroute -f frag.rules 192.168.86.1 fragroute: ip_chaff - ip_frag - drop - dup - order - print 192.168.86.227 192.168.86.1: icmp: type 8 code 0 192.168.86.227 192.168.86.1: icmp: type 77 code 74 192.168.86.227 192.168.86.1: icmp: type 8 code 0 192.168.86.227 192.168.86.1: icmp: type 90 code 83 192.168.86.227 192.168.86.1: icmp: type 8 code 0 192.168.86.227 192.168.86.1: icmp: type 90 code 83 192.168.86.227 192.168.86.1: icmp: type 102 code 77 192.168.86.227 192.168.86.1: icmp: type 102 code 77 192.168.86.227 192.168.86.1: icmp: type 8 code 0 Floating point exception Ciekawym wynikiem testu jest błąd operacji zmiennoprzecinkowych (Floating point exception). Wy- stąpił on w programie fragroute podczas modyfikowania ruchu. W tym konkretnym przypadku wy- daje się, że jest to błąd w programie. Niestety, po pojawieniu się tego błędu została przerwana komuni- kacja sieciowa i nie mogłem już ze swojego systemu Kali wysyłać pakietów. Cały ruch był generowany przez program fragroute. Gdy uległ on awarii, test został przerwany. W efekcie system operacyjny próbował wysyłać pakiety do nieistniejącego celu. Jest to jeszcze inny przykład wyniku testu. Każda awaria będąca skutkiem wykonania testu oznacza problem z dostępnością danych. Gdy sys- tem ulegnie awarii, nikt nie będzie w stanie do niego się dostać. Jeżeli usługa ulegnie awarii, przesta- nie być dostępna dla użytkowników. Wykonywane w ten sposób testy są atakami DoS. Dlatego ważne jest zachowanie ostrożności ze względów etycznych, o których wspomniałem wcześniej, jak również dlatego, że istnieje realne prawdopodobieństwo, że system zostanie uszkodzony i przestaną być świadczone usługi dla klientów. Więcej na ten temat będzie za chwilę. W prosty sposób testy obciążeniowe można wykonać za pomocą narzędzia hping3. Za pomocą tego wspaniałego programu można generować pakiety wprost z wiersza poleceń. Należy w tym celu określić wartości poszczególnych pól pakietu, a program utworzy je zgodnie z wymaganiami. Nie oznacza to jednak, że zawsze trzeba określać wszystkie pola. Można zdefiniować tylko te niezbędne, a program wypełni pozostałe pola nagłówka IP i nagłówka warstwy transportowej typowymi warto- ściami. Program hping3 jest w stanie generować pakiety, nie czekając na odpowiedź, ani nawet nie wprowadzając okresów oczekiwania. Generuje największy możliwy ruch i wysyła pakiety z maksy- malną szybkością. Listing 2.5 przedstawia wynik użycia tego narzędzia. Listing 2.5. Generowanie ruchu za pomocą programu hping3 root@rosebud:~# hping3 --flood -S -p 80 192.168.86.1 HPING 192.168.86.1 (eth0 192.168.86.1): S set, 40 headers + 0 data bytes hping in flood mode, no replies will be shown ^C Testy bezpieczeństwa sieci  51 Poleć książkęKup książkę --- 192.168.86.1 hping statistic --- 75425 packets transmitted, 0 packets received, 100 packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms Gdy wykonywałem powyższy test, byłem zdalnie połączony z systemem Kali. Zaraz po rozpoczęciu testu usiłowałem go przerwać, ponieważ uzyskałem wynik, który był mi potrzebny. Jednak system kontynuował wysyłanie pakietów z maksymalną szybkością i dostawał odpowiedzi. Z tego powodu nie mogłem wysłać do niego kombinacji Ctrl+C i przerwać działania programu hping3, który kon- tynuował wysyłanie mnóstwa pakietów przez sieć (na szczęście test wykonywałem w swojej lokalnej sieci, a nie w systemie należącym do kogoś innego). System operacyjny i sieć były bardzo obciążone, więc przez dłuższy czas nie uzyskiwałem żadnej reakcji. W powyższym przykładzie użyłem programu hping3 do wysyłania komunikatów SYN (synchronizacyjnych) na port numer 80. Był to tzw. potop komunikatów SYN. Nie tylko testowałem odporność stosu protokołów (systemu operacyjnego) na zalew pakietów, lecz także zdolność sprzętu i systemu do reagowania na taki ruch. Testowałem w ten sposób również warstwę transportową. System operacyjny powinien rezerwować niewielką ilość pamięci dla połączeń TCP (ang. Transport Control Protocol, protokół sterowania transmisją). Dawniej liczba slotów dla komunikatów inicjują- cych tzw. połączenia półotwarte nie była duża. Zakładano, że systemy chcące rozpocząć komunikację będą zachowywać się poprawnie i nawiązywać połączenia wykorzystywane później przez aplikacje. Po wyczerpaniu puli slotów system nie mógł nawiązywać połączeń, nawet inicjowanych przez upraw- nionych użytkowników. Obecnie większość systemów znacznie lepiej radzi sobie z potopem pakietów SYN. Nawiązują po prostu półotwarte połączenia i przerywają je, stosując różne techniki, na przykład skracając okres, przez który takie połączenie może pozostać w tym stanie. W powyższym teście były wysyłane komunikaty SYN (argument -S) na port numer 80 (-p 80). W pro- cesie tzw. potrójnego uścisku dłoni powinny być odbierane komunikaty SYN/ACK. Nie został okre- ślony protokół, ponieważ wyznaczał go komunikat SYN. Tego rodzaju komunikaty są stosowane jedynie w protokole TCP. Ponadto program hping3 został uruchomiony w trybie potopu pakietów (ar- gument --flood). Ten sam efekt można osiągnąć, używając argumentów określających czas przeplotu (okres oczekiwania przed wysłaniem następnego komunikatu). Użyty tutaj sposób jest łatwiejszy do zapamiętania i bardziej czytelny. Program hping miał kilka wersji, o czym świadczy cyfra 3 w nazwie. Jest ogólnie dostępny w wielu dystrybucjach systemu Linux. W niektórych systemach wywołuje się go, wpisując po prostu hping, a w innych trzeba dodać numer wersji, na przykład hping2 lub hping3. Testowanie niższych warstw stosu protokołów za pomocą takich narzędzi jak hping3 może być przy- czyną problemów, szczególnie w przypadku słabszych urządzeń. System Kali zawiera kilka innych narzędzi umożliwiających testowanie usług działających w wyższych warstwach stosu. Co przychodzi Ci na myśl w pierwszej chwili, gdy słyszysz słowo „internet”? Spotify? Facebook? Twitter? Insta- gram? Wszystkie te serwisy wykorzystują protokół HTTP, a użytkownik komunikuje się z odpowied- nim serwerem WWW. Nic więc dziwnego, że teraz zajmiemy się testowaniem tego rodzaju serwerów. Jest to zupełni inny temat niż testowanie aplikacji działających na serwerze WWW, czym zajmiemy się znacznie później. Na razie będziemy sprawdzać, czy serwery WWW działają. 52  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę System Kali jest wyposażony w narzędzia do testowania również innych protokołów, między innymi SIP (ang. Session Initiation Protocol, protokół inicjujący sesję) i RTP (ang. Real-time Transport Proto- col, protokół transmisji w czasie rzeczywistym), wykorzystywanych w usłudze VoIP (ang. Voice over IP, transmisja głosu za pomocą protokołu IP). Urządzenia i serwery komunikujące się za pomocą protokołu SIP wykorzystują polecenia podobne do stosowanych w protokole HTTP. Gdy urządzenie chce zainicjować połączenie, wysyła zapytanie INVITE (zaproś). Aby zapytanie dotarło do odbiorcy, musi przejść przez kilka serwerów lub urządzeń sieciowych. Ponieważ w wielu firmach usługa VoIP jest bardzo ważna, krytyczne znaczenie ma sprawdzenie, czy wszystkie urządzenia są w stanie obsłużyć dużą liczbę zapytań. Protokół SIP może korzystać z protokołu transportowego TCP lub UDP (ang. User Datagram Protocol, protokół datagramów użytkownika), jednak w starszych wersjach preferowany jest ten drugi protokół. Dlatego niektóre narzędzia, szczególnie te starsze, opierają swoje działanie na protokole UDP. Nowocześniejsze obsługują protokół TCP, jak również TLS (ang. Transport Layer Security, protokół zabezpieczający warstwę transportową) uniemożliwiający podsłuchiwanie danych. Pamiętaj, że protokół SIP opiera się na protokole HTTP, co oznacza, że wszystkie nagłówki i inne informacje przesyła w postaci zwykłego tekstu. Różni się tym od binarnego protokołu H.323, również wykorzy- stywanego w usłudze VoIP, w którym przesyłanych danych nie da się odczytać bez użycia narzędzia dekodującego. Narzędzie inviteflood wykorzystuje protokół UDP i nie można go przełączyć w tryb protokołu TCP. Jest to jednak swego rodzaju zaleta: potop pakietów można wtedy wywołać szybciej, ponieważ nie trzeba czekać na nawiązanie połączenia. Listing 2.6 przedstawia efekt użycia narzędzia inviteflood. Listing 2.6. Potop zapytań INVITE w protokole SIP root@kali:~# inviteflood eth0 kilroy dummy.com 192.168.86.238 150000 inviteflood - Version 2.0 June 09, 2006 source IPv4 addr:port = 192.168.86.35:9 dest IPv4 addr:port = 192.168.86.238:5060 targeted UA = kilroy@dummy.com Flooding destination with 150000 packets sent: 150000 Na podstawie informacji pojawiających się w terminalu można stwierdzić, co tu się dzieje. W pierw- szym wierszu wskazywany jest interfejs, którego narzędzie inviteflood będzie używać do wysyłania pakietów. Po nazwie interfejsu znajduje się nazwa drugiego urządzenia. Ponieważ protokół SIP jest wykorzystywany w usłudze VoIP, nazwą tą może być numer telefonu. W powyższym przykładzie docelowym urządzeniem jest serwer SIP o zadanej nazwie. Po niej, w zależności od konfiguracji serwera, umieszczana jest nazwa domeny lub adres IP, jeżeli domena nie jest znana. W drugim przypadku adres jest podawany dwukrotnie, ponieważ kolejnym argumentem jest adres urządzenia docelowego. Na końcu wiersza znajduje się liczba zapytań do wysłania. W tym przykładzie wysłanie 150 000 zapytań zajęło kilka sekund, co oznacza, że serwer był w stanie obsłużyć dużą ich liczbę. Zanim przejdziemy do innych tematów, zajmijmy się przez chwilę protokołem IPv6. Nie jest on wprawdzie powszechnie stosowany w internecie, na przykład nie można go użyć do otwarcia strony Google, ale jeszcze nadejdzie jego czas. Wspomniałem tu o Google, ponieważ jest to serwis, którego adres IPv6 jest udostępniany przez serwery DNS (ang. Domain Name System, system nazw domen). Testy bezpieczeństwa sieci  53 Poleć książkęKup książkę Ponadto protokół ten jest dzisiaj stosowany do przesyłania danych w wewnętrznych sieciach niektó- rych instytucji. Choć ma już ponad 20 lat, jego wdrożeniu nie towarzyszyły takie problemy jak w przypadku protokołu IPv4 — kilka dziesięcioleci zajęło usuwanie najbardziej rażących błędów wy- krytych w różnych jego implementacjach. Wszystko wskazuje na to, że pomimo wysiłku, jaki produ- cenci systemów operacyjnych Microsoft lub Linux włożyli w ich rozwijanie i testowanie, wciąż trzeba wykonywać praktyczne, wszechstronne testy różnego rodzaju urządzeń. System Kali zawiera nieźle wyposażone zestawy narzędzi do testowania protokołu IPv6. Są to dwa osobne zestawy, ponieważ protokół ten różni się od poprzednika nie tylko sposobem adresowania urządzeń. Pełna implementacja protokołu obejmuje adresację, konfigurację urządzeń, zabezpieczenia, transmisję rozgłoszeniową (ang. multicast), przesyłanie dużych datagramów, przetwarzanie ścieżek itp. Ponieważ są to funkcjonalności z różnych obszarów, do ich testowania potrzebne są osobne programy. Protokół IPv6 funkcjonuje w sieciach lokalnych inaczej niż IPv4. Do wykrywania urządzeń nie jest wykorzystywany protokół ARP (ang. Address Resolution Protocol, protokół wykrywania adresów), tylko nowy, wzbogacony protokół ICMPv6 (ang. Internet Control Message Protocol, internetowy protokół przesyłania komunikatów sterujących). Wykorzystywany jest również protokół NDP (ang. Neighbor Discovery Protocol, protokół wykrywania sąsiadów) ułatwiający dołączanie systemów do lokalnej sieci na podstawie pozyskiwanych z niej informacji. Protokół ICMPv6 został wzbogacony o komunikaty Router Solicitation (zapytanie o router), Router Advertisement (zgłoszenie routera), Neighbor Solicitation (zapytanie o sąsiada) i Neighbor Advertisement (zgłoszenie sąsiada). Dzięki tym komunikatom urządzenia odnajdują się w sieci i uzyskują o niej niezbędne informacje, takie jak adresy bramy domyślnej i serwera DNS. Za pomocą dostępnych narzędzi można testować niektóre funkcjonalności protokołu i sprawdzać, jak system będzie działał pod obciążeniem. Można również manipulować komunikatami tak, aby powo- dować niewłaściwe działanie systemu. Narzędzia na6, ns6, ra6 i rs6 umożliwiają wysyłanie dowolnie skonstruowanych opisanych wyżej komunikatów protokołu ICMPv6. Większość systemów dostarcza poprawnych informacji o sieci na podstawie swojej konfiguracji i posiadanych danych, natomiast wymienione narzędzia pozwalają wysyłać błędne komunikaty i sprawdzać, jak systemy na nie reagują. W zestawie narzędzi znajduje się również program tcp6 umożliwiający wysyłanie dowolnych pakietów TCP i przeprowadzanie ataków wykorzystujących ten protokół. Niezależnie od tego, jakich narzędzi używa się do wykonywania testów obciążeniowych, ważne jest, by jak najdokładniej notować wszystko, co się dzieje w sieci, aby wiedzieć, co było przyczyną ewentu- alnej awarii. Ważne jest również monitorowanie systemów i tworzenie dzienników. Narzędzia do ataków DoS Atak DoS nie jest tym samym co test obciążeniowy. Nie tylko cele obu operacji są różne, lecz także wykorzystywane w nich narzędzia. Testy obciążeniowe wykonuje się najczęściej za pomocą narzędzi programistycznych, które dostarczają informacji o wydajności systemów. Testy służą sprawdzaniu funkcjonowania programów lub systemów obciążonych dużą ilością komunikatów lub uszkodzonymi komunikatami. Tu pojawia się subtelna granica. Testy obciążeniowe mogą powodować awarie aplika- cji lub systemu operacyjnego. Wtedy mamy do czynienia z atakami DoS. Ponadto podczas testów może 54  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę chwilowo i gwałtownie wzrastać obciążenie procesora i wykorzystanie pamięci. To również jest warto- ściowa informacja, ponieważ oznacza, że w programie są błędy, które należy poprawić. W tej części rozdziału przyjrzymy się programom specjalnie przygotowanych do wywoływania awarii usług. Atak Slowloris Tak jak potop komunikatów SYN może wyczerpać sloty półotwartych połączeń, tak odpowiednio przeprowadzony atak może unieruchomić serwer WWW. Aplikacje nie mają do dyspozycji nieogra- niczonych zasobów. Serwery mogą nawiązywać określoną liczbę połączeń, zależną od budowy apli- kacji. Dlatego niektóre serwery są mniej podatne na ataki, a inne bardziej. Należy zaznaczyć, że prostsze urządzenia często mają ograniczone zasoby, tj. wielkość pamięci i moc procesora. Przypomnij sobie jakieś urządzenie, którym można zarządzać przez przeglądarkę, na przykład router wi-fi, mo- dem, drukarka. Każde z nich jest serwerem WWW, dzięki czemu łatwiej jest nim zarządzać. Nie jest to jednak ich główne przeznaczenie. Dane urządzenie musi przede wszystkim funkcjonować jako punkt dostępu wi-fi, modem lub drukarka. Dostępne zasoby urządzenia są przeznaczone przede wszyst- kim na te cele. Opisane urządzenia mogą być obiektami testów, ponieważ nie są przystosowane do nawiązywania dużej ilości połączeń. Oznacza to, że atak taki jak Slowloris może spowodować odcięcie urządzenia od sieci, przez co żaden użytkownik nie będzie mógł się z nim połączyć. Atak Slowloris polega na otwieraniu bardzo wielu połączeń z serwerem WWW. Różni się od zalewania serwera komunikatami SYN tym, że może być przeprowadzany powoli. Nie polega na wywoływaniu potopu komunikatów. Zamiast tego otwierane jest połączenie i przez długi czas wysyłane są niewielkie ilości danych. Serwer podtrzymuje połączenia dopóty, dopóki narzędzie wysyła do niego zapytania. Slowloris nie jest jednak jedynym rodzajem ataków na serwery WWW. W ostatnich latach zostało wykrytych kilka błędów w oprogramowaniu serwerów. Innego typu atakiem jest Apache Killer, pole- gający na wysyłaniu nakładających się serii bajtów. Serwer, usiłując złożyć serie w całość, wyczerpuje całą dostępną pamięć. Ten mankament został wykryty w oprogramowaniu Apache w wersjach 1.x i 2.x. W systemie Kali dostępny jest program slowhttptest umożliwiający przeprowadzanie czterech rodza- jów ataków wykorzystujących protokół HTTP. Pierwszy z nich to opisany wyżej Slowloris, polegają- cy na powolnym wysyłaniu nagłówków. Drugi atak to R-U-Dead-Yet, w którym powoli wysyłane są treści komunikatów. Można również przeprowadzać atak Apache Killer wymuszający przetwarzanie wadliwych komunikatów przez serwer. Te trzy ataki są przeciwieństwem opisanych wcześniej ataków zalewowych, ponieważ polegają na blokowaniu usługi poprzez wysyłanie niewielkich ilości danych. Listing 2.7 przedstawia przebieg ataku Slowloris na serwer Apache uruchomiony w lokalnym systemie Kali. Komunikaty nie były wysyłane poza system. Jak widać, po 26 sekundach atak się zakończył, ponieważ serwer nie mógł już nawiązywać następnych połączeń. Oczywiście był to bardzo prosty serwer ze skonfigurowanymi zaledwie kilkoma wątkami. Aplikacja uruchomiona na wielu serwerach przystosowanych do dużego obciążenia wytrzymałaby atak znacznie dłużej. Listing 2.7. Wynik użycia programu slowhttptest Wed Dec 5 15:03:49 2018: slowhttptest version 1.6 - https://code.google.com/p/slowhttptest/ - test type: SLOW HEADERS number of connections: 50 Testy bezpieczeństwa sieci  55 Poleć książkęKup książkę URL: http://localhost/ verb: GET Content-Length header value: 4096 follow up data max size: 68 interval between follow up data: 10 seconds connections per seconds: 50 probe connection timeout: 5 seconds test duration: 240 seconds using proxy: no proxy Wed Dec 5 15:03:49 2018: slow HTTP test status on 25th second: initializing: 0 pending: 0 connected: 30 error: 0 closed: 20 service available: YES Wed Dec 5 15:03:50 2018: Test ended on 26th second Exit status: No open connections left Będący celem tego ataku serwer Apache wykorzystywał do przetwarzania zapytań zaledwie kilka procesów pochodnych i wątków. Ich liczba została określona w konfiguracji serwera. Domyślnie są uruchamiane dwa procesy, maksymalnie 64 wątki i 150 procesów roboczych obsługujących zapyta- nia, a proces pochodny może uruchamiać najwyżej 25 wątków. W chwili wyczerpania przez program slowhttptest puli dostępnych połączeń w systemie działały 54 procesy serwera, tj. jeden główny i 53 pochodne. Aby nawiązać połączenia niezbędne do obsługi zapytań, serwer uruchomił wiele procesów pochodnych i kilka wątków w każdym z nich. Dlatego pojawiło się tak wiele procesów. Do wykonania opisanego testu została wykorzystana najnowsza wersja serwera Apache, z czego płynie następujący wniosek: pomimo upływu lat tego rodzaju ataki wciąż mogą być skuteczne. Oczywiście, jak wspo- mniałem wcześniej, wynik ataku zależy przede wszystkim od architektury testowanego systemu. Testy obciążeniowe SSL Opisany tu atak nie polega na zajęciu dostępnego pasma transmisyjnego, tylko na przeciążeniu procesora szyfrowaniem danych. Od dłuższego czasu strony serwisów zakupowych wykorzystują protokoły SSL (ang. Secure Sockets Layer, warstwa bezpiecznych gniazd) i TLS (ang. Transport Layer Security, bezpieczeństwo warstwy transportowej) do szyfrowania komunikacji z klientami i zapewnie- nia jej poufności. Dzisiaj z protokołów SSL i TLS korzysta wiele różnych serwerów. Jeżeli otworzysz stronę wyszukiwarki Google, zauważysz, że jest ona domyślnie szyfrowana, podobnie jak strony dużych firm, na przykład Microsoftu czy Apple. Przy próbie użycia niezaszyfrowanego adresu URL (ang. Uniform Resource Locator, ujednolicony format adresowania zasobów), tj. po wpisaniu prefiksu http:// zamiast https://, następuje automatyczne przełączenie na komunikację szyfrowaną. Rzecz jednak w tym, że protokoły SSL/TLS wymagają dużych mocy obliczeniowych. Nowoczesne procesory bez problemu radzą sobie z normalnym obciążeniem wywoływanym szyfrowaniem da- nych, tym bardziej że dzisiejsze algorytmy szyfrowania są zoptymalizowane pod kątem możliwości procesorów. Jednak protokoły SSL/TLS w znacznym stopniu obciążają każdy serwer. Przede wszyst- kim komunikaty wysyłane przez serwery są duże, co oznacza, że do ich szyfrowania potrzebna jest 56  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę większa moc obliczeniowa niż w przypadku małych komunikatów wysyłanych przez klientów. Po- nadto system klienta wysyła tylko kilka komunikatów co jakiś czas, a serwer musi wysyłać ich bardzo dużo do wielu klientów, jednocześnie wykorzystując liczne połączenia. Obciążenie jest powodowane głównie generowaniem kluczy niezbędnych do szyfrowania sesji. Narzędzia dostępne w systemie Kali umożliwiają testowanie starszego typu usług i serwerów wykorzy- stujących do szyfrowania danych protokół SSL. Protokół ten został zastąpiony nowocześniejszymi technikami i dzisiaj jest rzadko używany, choć wciąż jest stosowany w wielu usługach. Dlatego ważne jest ich testowanie. Ostatni opisywany w tym podrozdziale program służy do przeprowadzania ataków DoS na serwery używające powyższego protokołu. Program thc-ssl-dos wykorzystuje to, że szyfrowanie danych wymaga użycia dużych mocy obliczeniowych, szczególnie po stronie serwera. Listing 2.8 przedstawia wynik użycia programu thc-ssl-dos do ataku na serwer korzystający z proto- kołu SSL. Błędy w tym protokole są jednak znane od tak dawna, że implementujące go biblioteki często są z systemów usuwane. Choć została użyta starsza wersja serwera, widać wyraźnie, że nie było już możliwe nawiązanie pełnego połączenia SSL. Niemniej jednak gdybyś znalazł kiedyś serwer ze skonfigurowanym protokołem SSL będziesz mógł go przetestować pod kątem podatności na ataki DoS. Listing 2.8. Atak DoS przeprowadzony za pomocą programu thc-ssl-DoS root@kali:~# thc-ssl-dos -l 100 192.168.86.239 443 --accept ______________ ___ _________ \__ ___/ | \ \_ ___ \ | | / ~ \/ \ \/ | | \ Y /\ \____ |____| \___|_ / \______ / \/ \/ http://www.thc.org Twitter @hackerschoice Greetingz: the french underground Waiting for script kiddies to piss off................ The force is with those who read the source... Handshakes 0 [0.00 h/s], 1 Conn, 0 Err SSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol #0: This does not look like SSL! Niepowodzenie powyższego testu jest oznaką jednego z wyzwań towarzyszących testowaniu bezpie- czeństwa systemów: znalezienie słabego punktu może być trudne. Dlatego obecnie w atakach sto- suje się techniki inżynierii społecznej, polegające na wykorzystywaniu ludzkich słabości, łatwowier- ności i nieświadomych reakcji. Często znajdowanie technicznych wad systemów jest trudniejsze od manipulowania ludźmi. Nie oznacza to jednak, że ataki techniczne nie są przeprowadzane, tym bardziej że co jakiś czas są wykrywane i upubliczniane słabe punkty systemów. Informacje na ten temat można znaleźć na stronach Bugtraq (http://seclists.org/bugtraq) oraz Common Vulnerabilities and Exposures (http://cve.mitre.org). Testy bezpieczeństwa sieci  57 Poleć książkęKup książkę Ataki DHCP Do testowania protokołu DHCP (ang. Dynamic Host Configuration Protocol, protokół dynamicznego konfigurowania hostów) służy program DHCPig. Przeprowadza on atak polegający na zajmowaniu wszystkich zasobów serwera DHCP. Serwer ten przydziela adresy IP i udostępnia informacje konfigu- racyjne. Jego awaria w firmie stanowi poważny problem, ponieważ komputery pracowników nie mogą wtedy uzyskiwać adresów IP. Nierzadko serwer DHCP przydziela adres z długim czasem dzierżawy (czyli okresem, przez który komputer użytkownika może używać adresu bez konieczności jego odna- wiania), jednak zazwyczaj czas ten jest dość krótki. Jest to ważne w przypadku, gdy użytkownicy są mobilni i podłączają się do sieci często i na krótki czas. W takiej sytuacji długie czasy dzierżawy adre- sów powodowałyby szybkie wyczerpanie ich puli. Jeżeli jednak czasy dzierżawy są krótkie, program taki jak DHCPig może przejąć wygasający adres IP, zanim klient zdąży go odnowić. Klient wtedy zostanie bez adresu i nie będzie mógł korzystać z sieci. Korzystanie z programu DHCPig jest bardzo proste. Polega na uruchomieniu skryptu pig.py napisanego w języku Python i wskazaniu interfejsu, który ma zostać użyty do przeprowadzenia ataku. Testowanie szyfrowania Możliwość szyfrowania danych przesyłanych przez internet istnieje od ponad 20 lat. Algorytmy szyfrowania, tak jak wszystko, co dotyczy bezpieczeństwa informacji, stanowią cel ataków. Pierwsza wersja protokołu SSL, użyta w przeglądarce Netscape w 1995 r., została wycofana z użycia z powodu wykrytych w niej błędów. Druga wersja również nie przetrwała długo, ponieważ zidentyfikowano w niej następne błędy; w 1996 r. pojawiła się trzecia wersja protokołu. Ostatecznie wszystkie wersje zo- stały wycofane z powodu problemów z szyfrowaniem danych. Szyfrowanie danych przesyłanych przez sieć nie polega na zwykłym pobraniu komunikatu, zaszyfro- waniu go i przesłaniu dalej. Jest to tylko część większego procesu, w którym najbardziej wrażliwymi elementami są klucze. Zaszyfrowany komunikat ma wartość tylko wtedy, gdy można go odszyfrować, a do tego celu potrzebny jest klucz. W tym miejscu właśnie zaczynają pojawiać się problemy. Istnieją dwie główne metody szyfrowania danych. Pierwsza to szyfrowanie asymetryczne, w którym jeden klucz jest wykorzystywany do szyfrowania, a drugi do deszyfrowania. Na pewno spotkałeś się z określeniem szyfrowanie za pomocą klucza publicznego, którego idea polega na użyciu dwóch kluczy: publicznego i prywatnego. Klucz publiczny może posiadać każdy z nas; możemy mieć również dostęp do klucza innej osoby. Jednak komunikat zaszyfrowany za pomocą klucza publicznego można odszyfrować tylko za pomocą klucza prywatnego. Oba klucze są ze sobą związane matematyczną formułą wykorzystującą duże liczby. Takie podejście wydaje się racjonalne, prawda? Problem jednak polega na tym, że szyfrowanie asymetryczne jest skomplikowane obliczeniowo. W tym momencie pojawia się szyfrowanie symetryczne, w którym — jak się zapewne domyślasz — wykorzystywany jest tylko jeden klucz. Przy jego użyciu zarówno szyfruje się dane, jak i je deszyfruje. Szyfrowanie symetryczne jest mniej skomplikowane obliczeniowo, ale związane są z nim dwa pro- blemy. Pierwszy polega na tym, że im dłuższy jest klucz, tym bardziej jest podatny na ataki, dlatego że haker może zebrać dużą ilość szyfrogramów (tekstów przetworzonych za pomocą algorytmu szyfrowania) i przeanalizować je w poszukiwaniu klucza. Gdy go znajdzie, może odczytać cały ruch zaszyfrowany przy użyciu tego klucza. 58  Rozdział 2. Podstawy testowania bezpieczeństwa sieci Poleć książkęKup książkę Drugi, ważniejszy problem, brzmi: w jaki sposób dwie strony mogą wejść w posiadanie klucza? Szy- frowanie danych na sens tylko wtedy, gdy klucz mają obie strony. Jak można przekazać klucz drugiej stronie, gdy nie ma z nią bezpośredniego kontaktu? A jeżeli obie strony są blisko siebie, to czy mu- szą szyfrować przesyłane między sobą komunikaty? Jedna strona może się spotkać z drugą w umówio- nym miejscu i przekazać klucz. Jeżeli jednak w przyszłości potrzebny będzie nowy klucz, to komunika- cja nie będzie możliwa do momentu następnego spotkania. A im dłużej wykorzystywany jest jeden klucz, tym większe prawdopodobieństwo pojawienia się opisanego wcześniej pierwszego problemu. Ten problem rozwiązało dwóch matematyków. Nie byli wprawdzie pierwszymi, którzy znaleźli rozwiązanie, ale za to opublikowali je jako pierwsi. Whitfield Diffie i Martin Hellman wpadli na pomysł, aby obie strony niezależnie od siebie generowały klucze na podstawie uzgodnionej liczby. Liczbę tę mogą sobie bezpiecznie przekazać w niezaszyfrowanej postaci, ponieważ ważne jest jedynie to, co dzieje się z nią później. Obie strony umieszczają liczbę w formule matematycznej wraz z inną, znaną tylko im wartością. Jak poprzednio, formuła też może być publiczna, ponieważ ważna jest tylko owa poufna wartość. Strony wymieniają wyniki obliczeń między sobą i ponownie stosują formułę. W ten sposób wykonują te same obliczenia, wychodząc z tego samego punktu i w efekcie uzyskują te same klucze. Powyższy sposób stosuje się w praktyce dlatego, że wykorzystywane są w nim wszystkie opisane wcześniej mechanizmy. Klucz Diffiego-Hellmana jest stosowany w kryptografii do generowania symetrycznego klucza sesji. Dzięki temu obliczenia są mniej skomplikowane i serwer jest w mniej- szym stopniu obciążany szyfrowaniem i deszyfrowaniem dużych ilości danych przesyłanych pomiędzy nim a klientami. Jak wspomniałem wcześniej, protokół SSL nie jest już stosowany w kryptografii. Obecnie wykorzy- stuje się protokół TLS. Pojawiło się już kilka wersji tego protokołu, co świadczy o wyzwaniach towa- rzyszących szyfrowaniu danych. Obecnie stosowana jest wersja 1.2, a w przygotowaniu jest wersja 1.3. Kolejne wersje zawierają poprawki błędów znajdowanych podczas nieustających prób złamania tego protokołu. Do sprawdzenia, czy serwer wykorzystuje przestarzały protokół, służy między innymi narzędzie sslscan. Ten program usiłuje określić algorytm szyfrowania używany przez serwer. Jest to proste zadanie, ponieważ podczas nawiązywania połączenia serwer wysyła do klienta listę szyfrów do wy- boru. Zatem aby program sslscan uzyskał wszystkie potrzebne informacje, musi jedynie zainicjować sesję. Listing 2.9 przedstawia wynik testu algorytmu szyfrowania wykorzystywanego przez serwer Apache. Listing 2.9. Test lokalnego serwera za pomocą programu sslscan root@kali:~# sslscan 192.168.1.1 Version: 1.11.12-static OpenSSL 1.0.2-chacha (1.0.2g-dev) Connected to 192.168.1.1 Testing SSL server 192.168.1.1 on port 443 using SNI name 192.168.1.1 TLS Fallback SCSV: Server supports TLS Fallback SCSV Testowanie szyfrowania  59 Poleć książkęKup książkę TLS renegotiation: Secure session renegotiation supported TLS Compression: Compression disabled Heartbleed: TLS 1.2 not vulnerable to heartbleed TLS 1.1 not vulnerable to heartbleed TLS 1.0 not vulnerable to hea
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Kali Linux. Testy bezpieczeństwa, testy penetracyjne i etyczne hakowanie
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: