Sieć komputerowa aby działać musi być w stanie obronić się przed licznymi atakami m.in. takimi jak:
- spoofowanie adresów MAC,
- ataki na STP,
- ataki na CDP,
- ataki na DHCP,
- przepełnienie tablic adresów MAC,
- ataki typu LAN storm,
- ataki na VLAN.
W artykule tym oczywiście nie wszystkimi metodami przeprowadzania ataków się zajmiemy lecz postaram opisać te najczęściej wykorzystywane wraz z metodami ich przeciwdziałania. Tak więc w pierwszej części wpisu opis jak dany atak zorganizować i przeprowadzić zaś w drugiej części wpisu obrona przed nimi.
Artykuł ten skoncentruje się na zagrożeniach (i oczywiście sposobach ich zapobiegania) związanych z protokołem ARP, DHCP, atakiem przepełnienia tablicy adresów MAC czy atakami typu LAN storm. Zaś te bardziej wyrafinowane jak atak na sieci VLAN czy STP opiszę w osobnej osłonie.
Rozpoczynamy od opisu ataku ARP poisoning z wykorzystaniem narzędzi dostępnych w systemie Windows.
Topologia sieciowa w której przeprowadzono symulację przedstawia się następująco.
Narzędzie, które pozwoli nam na przeprowadzenie ataku to Cain&Abel. Program standardowo wykorzystywany jest do odzyskiwania haseł (bądź ich łamania) ale ma w sobie zaszyty moduł odpowiedzialny za sniffing oraz za przeprowadzanie ataku zatrucia tablicy ARP. Do działania programu niezbędne jest zainstalowanie oprogramowania WinPcap.
Po pobraniu i instalacji oprogramowania uruchamiamy narzędzie. W głównym oknie aplikacji przechodzimy do karty Sniffer (punkt 1) a następnie wybieramy ikonę interfejsu sieciowego (punkt 2).
W niektórych konfiguracjach zdarza się sytuacja w której wykorzystanie modułu sniffera uzależnione jest od wydania polecenia: netsh int ip set global taskoffload=disabled Jeśli zajdzie taka sytuacja zostaniemy powiadomieni o tym stosownym komunikatem. W razie wystąpienia opisywanego zdarzenia, należy uruchomić konsolę wiersza poleceń (z prawami administratora) i wydać wspomniane polecenie. Po wydaniu komendy ponownie uruchamiamy narzędzie Cain&Abel.
Przy pierwszym uruchomieniu sniffera pierwszą opcję jaką musimy skonfigurować to wybór użytego interfejsu. W nowo otwartym oknie Configuration Dialog na karcie Sniffer definiujemy interfejs, który będzie wykorzystywany w procesie przechwytywania pakietów oraz zatruwania tablicy ARP. Konfigurację zatwierdzamy klikając na OK.
Po zatwierdzeniu interfejsu kolejną czynnością jaką musimy wykonać jest wykonanie skanu sieci celem wykrycia aktywnych hostów. Skan przeprowadzamy wybierając ikonę plusa. Po wybraniu ikony w oknie MAC Address Scaner określamy opcje przeprowadzanego skanowania. Celem wykrycia wszystkich komputerów znajdujących się w podsieci zaznaczamy: All hosts in my subnet Jeśli chcemy zdefiniować obszar adresów IP co do których będzie przeprowadzane skanowanie wybieramy: Range a następnie określamy początkowy i końcowy adres IP.
Aby rozpocząć skan klikamy OK i rozpoczyna się proces odkrywania hostów. Lista aktywnych hostów zostanie wyświetlona w tabeli.
Po wykryciu hostów przechodzimy do zakładki APR (lewy dolny róg programu). Opcje zgromadzone na tej zakładce posłużą nam do zdefiniowania opcji ataku. Aby określić hosta co do którego będzie przeprowadzany atak należy wybrać ikonę Plusa (ikona stanie się aktywna gdy wybierzemy gałąź ARP a następnie klikniemy w obszarze górnej części tabeli). Naszym oczom powinno ukazać się nowe okno New ARP Poison Routing Okno to zostało podzielone na dwie tabele. Lewa tabela służy do wyboru adresu MAC hosta, którego ruch sieciowy chcemy przechwytywać prawa zaś odpowiedzialna jest za wybranie adresu MAC drugiego hosta, który prowadzi komunikację z celem - najczęściej jest to adres bramy (routera).
W scenariuszu założyliśmy przechwytywanie ruchu sieciowego pomiędzy hostem o adresie MAC AA-AA-AA-AA-AA-AA (ofiara) a routerem (adres MAC A0-C5-62-73-9A-50) tak więc w lewy panelu zaznaczamy adres MAC komputera ofiary zaś w prawymadres MAC routera (oczywiście możliwa jest sytuacja w której ruch sieciowy będzie przechwytywany pomiędzy dwoma hostami np. komputer-serwer). Po zdefiniowaniu hostów co do których będzie prowadzony proces przechwytywania pakietów klikamy OK.
Aby uruchomić atak wybieramy ikonę „promieniowania” - punkt 1. Status ataku pojawi się w górnej części tabeli (punkt 2) zaś informację o odbieranych pakietach znajdziemy w tabeli dolnej - punkt 3. Dodatkowo w lewej części okna przechwytywane pakiety są grupowane w zależności od typu wykrytego ruchu sieciowego (użyty protokół np. ruch związany z wykorzystaniem protokołów pocztowych).
Tablica ARP hosta została zatruta, cały ruch generowany na komputerze ofiary zostaje w pierwszej kolejności wysłany w kierunku atakującego a następnie przekazany do miejsca przeznaczenia czyli do routera.
Atak możemy obserwować analizując tablicę ARP hosta ofiary.
Gdy atak ARP poisoning nie jest uaktywniony w tablicy ARP znajdujemy prawidłowe dowiązanie bramy (routera) z jej adresem MAC.
Po uruchomieniu ataku adres MAC bramy zostaje zamieniony na adres MAC komputera przeprowadzającego atak. Atak zatrucia przeprowadzany jest z hosta o adresie MAC CC-CC-CC-CC-CC-CC tak więc w trakcie trwania ataku prawidłowy adres MAC bramy zostaje zastąpiony właśnie tym adresem.
Atak na tablicę ARP dodatkowo możemy obserwować podczas procesu przechwytywania pakietów.
Analizując pole warstwy drugiej przechwyconego pakietu o numerze 67 dochodzimy do wniosku, że wszystko jest w porządku. W pakiecie zawarte są prawidłowe informacje powiązania adresu MAC routera z jego adresem IP - punkt 1
Po przejściu do pakietu 72 można zauważyć zamianę adresu MAC routera na adres MAC komputera wykonującego atak - punkt 2.
Jednym z ciekawych narzędzi, które możemy wykorzystać w systemie Windows jest aplikacja WinArpAttacker. Narzędzie te podobnie jak opisywany powyżej program Cain&Abel umożliwia Nam przeprowadzenie ataku z wykorzystaniem protokołu ARP ale oprócz opcji ataku są również dostępne takie, które przed atakiem Nas uchronią - ale wszystko po kolei.
Aby za pomocą narzędzia przeprowadzić atak po uruchomieniu jej z prawami administratora należy w pierwszej kolejności przeprowadzić skan sieci lecz aby to zadanie wykonać warto sprawdzić czy został wybrany prawidłowy interfejs sieciowy. W przypadku posiadania jednej karty sieciowej problem Nam odpada lecz gdy system korzysta z wielu interfejsów ustawienie te należy skontrolować. Aby wybrać interfejs z menu wybieramy pozycję Options a następnie Adapter. W nowo otwartym oknie w sekcji Select a Network Device z rozwijanego menu wybieramy właściwy interfejs. Wybór oczywiście zatwierdzamy klawiszem OK.
Po ustawieniu interfejsu przechodzimy do wspomnianego skanowania sieci. Scan sieci uruchomimy wybierając z dostępnych ikon pozycję Scan. Po przeprowadzeniu operacji odkrywania hostów dostępnych w atakowanej sieci ich lista pojawi się w oknie poniżej.
Przed uruchomieniem ataku wyłączamy ochronę tablicy ARP poprzez wybranie z dostępnych ikon przycisku Stop (do tematu tego wrócimy w dalszej części wpisu poświęconej obronie przed atakiem z wykorzystaniem protokołu ARP) - punkt 1. Atak uruchomimy poprzez zaznaczenie interesującego nas hosta a następnie wybraniu ikony Attack wraz z opcją Sniff Gateway. Zaznaczenie opcji spowoduje rozpoczęcie ataku zatrucia tablicy ARP pomiędzy wybranym hostem a bramą. Aby prowadzić przechwytywanie pomiędzy dwoma wybranymi hostami z listy dostępnych hostów należy wybrać interesujące nas komputery a następnie z menu Attack wybrać opcję Sniff Hosts. Wybranie Sniff Lan spowoduje uruchomienie ataku w kontekście całej sieci LAN - co oznacza, że cały ruch sieciowy generowany przez wszystkie aktywne hosty będzie przechodził przez nasz komputer.
Atak zostaje uruchomiony a jego efekty możemy sprawdzić przeglądając tablicę ARP hosta 192.168.1.200 Jak widać poniżej (punkt 1) przed uruchomieniem ataku adres MAC bramy jest poprawnie skojarzony z jego adresem IP zaś po uruchomieniu ataku (punkt 2), adres MAC bramy wskazuje na hosta atakującego. Uruchomiony sniffer pakietów na hoście 192.168.1.210, który jest kontrolowany przez atakującego rejestruje test ping pomiędzy hostem ofiary a bramą co dowodzi, że atak zakończył się sukcesem.
Tak jak wspomniałem do programu będziemy wracać a tym czasem idziemy dalej.
O wiele więcej narzędzi do przeprowadzenia ataku opartego o protokół ARP znajdziemy w systemie Linux a gdy chcesz je mieć wszystkie z automatu wybierz dystrybucję Kali bądź Backtrack.
Topologia sieciowa użyta do opisania narzędzi pozostaje bez zmian, zmienia się system operacyjny atakującego oraz jego adres MAC z CC-CC-CC-CC-CC-CC na EE-EE-EE-EE-EE-EE. Po podłączeniu hosta pierwszą czynnością jaką powinniśmy wykonać jest wykonanie testu łączności. Test ping pomiędzy hostem atakującym (IP 192.168.1.200) jak i routerem (IP 192.168.1.1) kończy się sukcesem.
Pierwszym narzędziem (a tak właściwie trzecim) jakie wykorzystamy do przeprowadzenia ataku zatrucia tablicy ARP jest Ettercap. Jeśli go nie posiadamy to jego instalację przeprowadzimy za pomocą polecenia: apt-get install ettercap-graphical
Po instalacji narzędzie w trybie graficznym uruchamiamy poleceniem: ettercap -G (jeśli korzystamy z Linux Kali program odnajdziemy w sekcji: Sniffing @ Spoofing).
Po uruchomieniu programu w górnym menu z sekcji Sniff wybieramy opcję Unified sniffing.
W następnym kroku określamy interfejs, który zostanie użyty do przeprowadzenia ataku. W przypadku komputera posiadającego wiele kart sieciowych właściwy interfejs zidentyfikujesz wydając w konsoli polecenie: ifconfig W naszym scenariuszu został użyty
interfejs: eth0
Po wstępnej konfiguracji narzędzia przechodzimy do skanu sieci. Proces skanowania jest niezbędny gdyż jego głównym celem jest wykrycie w atakowanej sieci aktywnych hostów oraz wykonanie dopasowania adres IP - adres MAC. Aby przeprowadzić skanowanie z menu wybieramy opcję Hosts a następnie Scan for hosts.
Wybranie przedstawionych opcji spowoduje uruchomienie procesu skanowania sieci.
Skan jest przeprowadzany w ekspresowym tempie i już po chwili zostaniesz poinformowany o odnalezionej ilości działających hostów (w naszym przypadku jest ich 6).
Adresy IP oraz powiązane z nimi adresy MAC poznamy wybierając z menu opcję Hosts a następnie Hosts list. Jak można zauważyć przeglądając poniższą listę odnajdziemy na niej komputer ofiary jak i router.
Przechodzimy do ataku i definiujemy nasze cele. Ponieważ dążymy do przechwycenia ruchu sieciowego pomiędzy routerem a hostem ofiary z listy wykrytych hostów zaznaczamy adres IP 192.168.1.1 (router) i wybieramy przycisk Add to Target 1 (punkt 1) a następnie odszukujemy i zaznaczamy adres IP 192.168.1.200 (ofiara) i klikamy przycisk Add to Target 2 (punkt 2). Cele ataku zostały określone.
Aby przejrzeć bądź zmodyfikować listę celów z menu wybieramy Targets a po rozwinięciu listy klikamy na opcję Current Targets.
Aby rozpocząć atak z menu wybieramy Mitm i dalej Arp poisoning. W nowo otwartym oknie zaznaczamy opcję Sniff remote connections, zatwierdzenie ustawień przyciskiem OK rozpocznie atak.
O rozpoczęciu ataku zostaniemy poinformowani stosownymi wpisami w głównym oknie programu.
Aby mieć 100% pewność, że atak powiódł się sprawdźmy tablicę ARP ofiary. Poniżej na zrzucie przedstawione zostało użycie polecenia sprawdzającego wpisy tablicy ARP: arp -a Punkt 1 obrazuje stan tablicy przed atakiem natomiast punkt 2 stan tablicy po ataku. Jak łatwo zauważyć zmianie uległ adres MAC powiązany z adresem IP bramy. Przed uruchomieniem ataku powiązanie jest jak najbardziej prawidłowe zaś w trakcie jego trwania adres MAC bramy zostaje zamieniony na adres MAC komputera atakującego.
Atak zakończył się powodzeniem.
Aby przerwać atak z menu wybierz Mitm a następnie Stop mitm attack(s)
Ettercap oprócz trybu graficznego również oferuje Nam możliwość skorzystania z trybu pracy w konsoli (taki pseudo tryb graficzny). Przeprowadzenie ataku przy użyciu tego interfejsu przebiega w sposób analogiczny jak w środowisku graficznym. Wywołanie tego trybu odbywa się za pomocą polecenia: ettercap -C
Kolejne narzędzie jaki użyjemy do przeprowadzenia ataku zatrucia bufora ARP jest framework Metasploit a mówiąc bardziej szczegółowo wykorzystamy jeden z dostępnych modułów o nazwie arp_poisoning.
Rozpoczynamy od uruchomienia narzędzia poprzez wydanie polecenia: msfconsole (punkt 1). Wydanie komendy spowoduje uruchomienie frameworku, którego zarządzanie odbywa się za pomocą osobnego zestawu poleceń przynależnych narzędziu.
Uruchomienie modułu odpowiedzialnego za przeprowadzenie ataku ARP poisoning przeprowadzimy wydając polecenie: use/auxiliary/spoof/arp/arp_poisoning (punkt 2).
Po uruchomieniu modułu wydajemy polecenie: info aby poznać parametry jakie należy skonfigurować aby narzędzie mogło przeprowadzić skuteczny atak. Wśród obowiązkowych opcji jakie należy zdefiniować znajdują się:
1 - adres IP hosta, którego ruch chcemy przechwytywać - set dhost <adres_IP>,
2 - interfejs, który posłuży do ataku - set interface <identyfikator_interfejsu> - w przedstawianym opisie został użyty interfejs bezprzewodowy tak byś Czytelniku miał świadomość, że i tego typu interfejsy sieciowe można wykorzystać w procesie przechwytywania pakietów. Adres MAC atakującego pomimo wykorzystania innego interfejsu nie ulega zmianie.,
3 - adres IP routera - set shost <adres_IP>.
Dodatkowo aby obserwować działanie modułu został ustawiony parametr: set verbose true (punkt 4).
Wszystkie niezbędne opcje zostały skonfigurowane czas przejść do uruchomienia ataku. Atak rozpoczniemy po wydaniu polecenia: exploit Wydanie polecenia spowoduje zatrucie tablicy ARP hosta 192.168.1.200
Efekt przeprowadzanego ataku możemy zweryfikować sprawdzając tablicę ARP hosta 192.168.1.200 Jak widać poniżej adres MAC routera wskazuje na hosta o adresie MAC EE-EE-EE-EE-EE-EE co jak wiemy nie jest wartością prawidłową. Adres MAC EE-EE-EE-EE-EE-EE należy do atakującego.
W przypadku użycia opisywanych narzędzi dostępnych w systemie Linux została wykonana tylko połowa roboty gdyż możemy przechwytywać wszystkie zapytania generowane przez ofiarę lecz dane te w żaden sposób nie są przesyłane dalej. Mówiąc prościej trafiają one do atakującego i tylko do niego. Konsekwencją takiego stanu rzeczy jest to, że ofiara traci możliwość połączenia np. z Internetem. A nie do końca o to Nam chodziło. Poniżej polecenie ping wysłane przez ofiarę w kierunku witryny wp.pl i jak widać test ten kończy się niepowodzeniem.
Powodem zaistnienia takiej sytuacji jest wyłączona funkcja przekazywanie pakietów IP (IP forwarding). Tak więc naprawmy to i dajmy hostowi ofiary możliwość komunikacji.
W pierwszym etapie za pomocą polecenia: sysctl net.ipv4.ip_forward sprawdzamy bieżący stan funkcji przekazywania pakietów (punkt 1). Zwróconą wartością jest zero, które oznacza wyłączenie mechanizmu. Aby pakiety prawidłowo mogły być przekazywane pomiędzy interfejsami należy wydać komendę: sysctl net.ipv4.ip_forward=1 bądź alternatywnie polecenie: echo 1 > /proc/sys/net/ipv4/ip_forward (punkt 2). Ponowne sprawdzenie stanu przekazywania (punkt 3) zwraca wartość jeden - przekazywanie jest aktywne. Komendy te powodują tymczasowe włącznie funkcji, jeśli zależy nam na uaktywnieniu mechanizmu na stałe należy w pliku /etc/sysctl.conf dopisać linię: net.ipv4.ip_forward=1
Po wprowadzeniu zmian ofiara może prowadzić swobodną komunikację a my mamy możliwość jej rejestrowania. Tym razem test ping kończy się powodzeniem.
Efekt przeprowadzonego ataku możemy obserwować z wykorzystaniem narzędzia Wireshark. Jak można zaobserwować poniżej - pakiet ICMP trafia od ofiary (adres źródłowy MAC AA-AA-AA-AA-AA-AA) do atakującego (adres docelowy MAC EE-EE-EE-EE-EE-EE).
By następnie atakujący (adres źródłowy MAC EE-EE-EE-EE-EE-EE) przekazał go w kierunku routera (adres docelowy MAC A0-C5-62-73-9A-50).
Po ustaniu ataku wszystko wraca do normy w tablicy ARP ofiary widniej prawidłowy adres MAC routera.
W systemie Linux do przeprowadzenia ataku ARP poisoning możemy również użyć narzędzia o nazwie arpspoof. Instalację narzędzia przeprowadzimy wydając polecenie: apt-get install dsniff
Przechodzimy do ataku. Sprawdzenie tablicy ARP ofiary uwidacznia stan w którym adres MAC jest poprawnie powiązany z adresem IP routera.
Aby rozpocząć zatrucie tablicy ARP należy wydać polecenie: arpspoof -i <użyty_interfejs> -t <adres_IP_ofiary> <adres_IP_routera> (ważna jest kolejność zdefiniowanych adresów IP) po zatwierdzeniu Enterem rozpoczyna się atak.
Ponowne sprawdzenie tablicy ARP komputera ofiary ukazuje zmiany - adres MAC routera został zamieniony na adres MAC atakującego.
Aby ofiara mogła prowadzić swobodną komunikację nie zapomnij o włączeniu przekazywania pakietów IP (opis włączenia funkcji omówiony wyżej).
Nasza sieć oprócz opisanego już zagrożenia związanego z protokołem ARP może być również narażona na ataki typu LAN Storm Attacks. Choć warto tu zauważyć, że sam administrator poprzez błędną konfigurację urządzeń (np. redundancja łączy pomiędzy przełącznikami - wykorzystanie protokołu STP) czy błędną implementację protokołów korzystających z pakietów typu broadcast taki atak może wywołać sam. Należy pamiętać, że przełączniki zawsze przekazują ruch typu broadcast (wykorzystywany np. przez takie protokoły jak ARP czy DHCP) na wszystkie porty dlatego też przypadłość ta może zostać wykorzystana do przeprowadzenia ataku DoS (pojawiające się pakiety zalewają całą sieć LAN marnując tym samym dostępne pasmo co w konsekwencji prowadzi do spadku wydajności całej sieci).
Aby zasymulować atak tego typu ponownie wykorzystamy narzędzie WinArpAttacker. Program umożliwia Nam wysłanie spreparowanych pakietów ARP (pakiety typu: Request, Reply, Reverse request, Reverse reply).
Aby wysłać fałszywy pakiet po uruchomieniu narzędzia wybieramy ikonę Send. Do zalania sieci ruchem broadcast wykorzystamy pakiet typu ARP Request. Wybór rodzaju pakietu umożliwia zdefiniowanie ustawień odnoszących się do wybranego typu pakietu. Ponieważ wysyłany pakiet ma być przypisany do ruchu broadcast pole określające docelowy adres MAC zostaje wypełnione wartością FF-FF-FF-FF-FF-FF (adres rozgłoszeniowy warstwy drugiej). Ponieważ mamy wywołać burzę pakietów dodatkowo zostaje zaznaczona opcja: Continuously Po zatwierdzeniu ustawień przyciskiem Send sieć zostaje zalana pakietami ARP Request pochodzącymi od hosta 192.168.1.210
Atak ten możemy obserwować za pomocą narzędzia Wireshark na hoście 192.168.1.200 gdyż pakiety te są rozsyłane przez przełącznik na wszystkich jego portach.
Innym narzędziem, które możemy wykorzystać do wywołania burzy broadcastowej jest program Hyenae i tak jak w przypadku aplikacji WinArpAttacker tak i tu wykorzystamy pakiet ARP Request. Choć warto zaznaczyć iż narzędzie te możemy użyć do wygenerowania pakietów obejmujących szerokie spectrum ataków:
- ARP-Request flooding
- ARP-Cache poisoning
- PPPoE session initiation flooding
- Blind PPPoE session termination
- ICMP-Echo flooding
- ICMP-Smurf attack
- ICMP based TCP-Connection reset
- TCP-SYN flooding
- TCP-Land attack
- Blind TCP-Connection reset
- UDP flooding
- DNS-Query flooding
- DHCP-Discover flooding
- DHCP starvation attack
- DHCP-Release forcing
- Cisco HSRP active router hijacking
Narzędziem możemy zarządzać za pomocą interfejsu GUI jak i wiersza poleceń. Po uruchomieniu trybu graficznego by móc rozpocząć atak należy skonfigurować:
1 - określić interfejs, który zostanie wykorzystany do wysłania spreparowanych pakietów,
2 - zdefiniować typ pakietu oraz wersję protokołu IP,
3 - określić dane, które posłużą do wygenerowania pakietów - w polu Destination Pattern został umieszczony adres rozgłoszeniowy warstwy drugiej,
4 - opcjonalnie określić ilość wysyłanych pakietów oraz zdefiniować opcje związane z częstotliwością ich wysyłania.
Na dole okna aplikacji znajdziemy ekran informacyjny, w którym możemy sprawdzić status wykonywanych operacji a także znajdziemy tam wygenerowane polecenie, które możemy wykorzystać gdy z narzędzia korzystamy z wiersza linii poleceń.
Aby rozpocząć atak należy wybrać przycisk Execute.
Sieć zostaje zalana pakietami ARP Request i tak jak poprzednio atak możemy obserwować na hoście zdalnym przy wykorzystaniu narzędzia Wireshark.
Unikatową cechą programu jest możliwość wykonania opisywanych operacji za pośrednictwem hosta zdalnego. Podczas instalacji programu mamy możliwość określenia czy ma zostać zainstalowany daemon narzędzia, który może posłużyć atakującemu do wywołania ataku zdalnie z poziomu innego hosta (i wcale nie musimy ograniczać się tylko do jednej maszyny, skoordynowany atak może prowadzić wiele hostów).
Na hoście zdalny zostaje zainstalowany daemon narzędzia Hyenae. Aby usługa mogła zacząć działać w tle należy w parametrach jej wywołania określić interfejs sieciowy (parametr: -I <nr_interfejsu>) oraz maksymalną dozwoloną liczbę pakietów (parametr: -u <wartość>). Listę dostępnych interfejsów sieciowych poznasz wydając komendę: hyenaed -l
Daemon został uruchomiony i oczekuje na polecenia. Weryfikację działania możemy przeprowadzić wydając polecenie: netstat -ao, które pokaże nam aktywne usługi sieciowe wraz ze stanem portów. Jak można zauważyć poniżej narzędzie hyenaed działa i nasłuchuje na porcie TCP 666.
Dodatkowo stan procesu sprawdzimy również z wykorzystaniem polecenia: tasklist, które odpowiedzialne jest za wyświetlenie wszystkich działających procesów. Na liście tej również odnajdziemy narzędzie: hyenaed
Daemon narzędzia został zainstalowany na hoście 192.168.1.200 a atak zostanie uruchomiony z hosta o adresie IP 192.168.1.210. Po uruchomieniu narzędzia z listy Operation Mode wybieramy opcję Attack from remote Daemon. Po określeniu adresu IP hosta zdalnego, portu (opcjonalnie hasła) i zdefiniowaniu opcji ataku całość zatwierdzamy przyciskiem Execute. Atak zostaje wykonany za pośrednictwem hosta zdalnego.
Wszystkie operacje związane z działaniem narzędzia możemy dodatkowo przejrzeć w logach narzędzia. Plik logu dostępny jest w katalogu instalacyjnym aplikacji.
Co warto zaznaczyć, to to, że przedstawione programy wcale nie muszą być wykorzystane w niecnych celach ale stanowią świetne narzędzia dla administratorów do przeprowadzania symulowanych ataków (zachowanie sieci gdy prawdziwy atak nastąpi) bądź badania wydajności sieci.
Przechodzimy do ataku na protokół DHCP. Protokół ten (tak w wielkim skrócie) odpowiedzialny jest za dostarczenie konfiguracji sieciowej (adres IP, adres IP bramy, adres IP serwera DNS) nowo podłączanemu hostowi tak by mógł on prowadzić swobodną komunikację z innymi komputerami. Jeśli chcesz uzyskać więcej informacji o sposobie działania i konfiguracji tego protokołu zapraszam do zapoznania się z wpisem: Co w sieci siedzi. Protokół DHCP.
W przypadku tego protokołu do czynienia najczęściej będziemy mieli z dwoma rodzajami ataku:
- DHCP Spoofing - atak polegający na podstawieniu fałszywego serwera DHCP, którego zadaniem jest dostarczenie konfiguracji sieciowej hostom, która będzie zgodna z intencjami atakującego,
- DHCP Consumption Attack - atak polegający na zablokowaniu serwera DHCP poprzez całkowite wykorzystanie jego zasobów (serwer DHCP zostaje zablokowany gdyż wszystkie dostępne adresy IP w ramach przydzielonej puli zostają wykorzystane - serwer DHCP nie ma wolnych adresów IP, które mógłby przydzielić zgłaszającym się klientom).
Pulę dostępnych ataków możemy powiększyć o ataki typu LAN Storm w których to wykorzystywane są pakiety rozgłoszeniowe przynależne protokołowi DHCP.
W opisie obu ataków wykorzystamy topologię sieciową zaprezentowana na poniższym zrzucie. Serwer DHCP jest rolą systemu Windows 2012 natomiast atakującym jest host z zainstalowanym systemem Linux.
Rozpoczniemy od ataku DHCP Consumption Attack. Jak widać poniżej atakujący ma możliwość komunikacji z serwerem DHCP.
Atakującemu został przez serwer DHCP przyznany adres IP 10.0.0.30 (pierwszy z zadeklarowanej puli - od 10.0.0.30 do 10.0.0.254). Sprawdzenie statystyk wykorzystania zasobów serwera DHCP uwidacznia, że atakujący jest jedynym klientem, któremu została przypisana konfiguracja sieciowa tak więc serwer do rozdysponowania ma jeszcze 224 adresy IP. Celem ataku jest zablokowanie serwera DHCP poprzez doprowadzenie do stanu w którym zasoby serwera zostaną wykorzystane w 100%
Atak przeprowadzimy z wykorzystaniem narzędzia Yersinia. Narzędzie te standardowo dostępne jest w dystrybucji Linux Kali gdy korzystamy z innej dystrybucji program zainstalujemy za pomocą polecenia: apt-get install yersinia (w Linux Ubuntu instalacja oprogramowania przebiega bez żadnych problemów).
Narzędzie te w wcześniejszych moich wpisach było już wykorzystywane lecz jest tak uniwersalne iż nie raz będziemy do niego wracać.
Program możemy używać w trybie graficznym jak i interaktywnym, my wykorzystamy oba.
Aby uruchomić program w trybie interaktywnym wywołujemy go poleceniem: yersinia -I Po uruchomieniu narzędzia określamy interfejs sieciowy, który zostanie wykorzystany do przeprowadzenia ataku (interfejs można zmienić za pomocą klawisza: i - został wybrany interfejs: eth0).
Następnym krokiem jest wybór ataku a tak naprawdę protokołu, który w ataku zostanie wykorzystany - aby zdefiniować atak użyj klawisza F2 bądź g Z dostępnej listy wybieramy oczywiście DHCP (tak jak wspomniałem wyżej narzędzie yersinia jest naprawdę wszechstronne a widać to po liście dostępnych protokołów w ramach, których są przeprowadzane ataki).
Po wyborze protokołu za pomocą klawisza: x określamy rodzaj ataku. Ponieważ przeprowadzamy atak na zasoby serwera DHCP z listy wybieramy: sending DISCOVER packet
Zatwierdzenie ataku (poprzez klawisz 1) rozpocznie zalewanie serwera DHCP pakietami DHCPDlSCOVER proszącymi serwer o dostarczenie konfiguracji sieciowej (ruch ten jest typu broadcast).
Aby przerwać atak należy posłużyć się klawiszem: l po naciśnięciu, którego pojawi się lista aktualnie prowadzonych ataków. Z listy wybieramy atak i celem jego anulowania wybieramy Enter.
W trakcie trwania ataku sprawdzamy statystyki serwera DHCP. Jak można zauważyć atak powiódł się wszystkie dostępne adresy w ramach zdefiniowanej puli zostały wyczerpane.
O fakcie wyczerpania puli adresów IP poprzez okno Menedżer serwera jesteśmy informowani stosownymi komunikatami. Komunikaty te są również dostępne w dzienniku zdarzeń.
Jak wspomniałem wyżej narzędziem Yersinia a co za tym idzie prowadzonymi atakami możemy zarządzać z wykorzystaniem graficznego trybu użytkownika. Aby uruchomić aplikację w trybie graficznym wydajemy polecenie: yersinia -G Po uruchomieniu programu należy w pierwszej kolejności dokonać wyboru interfejsu sieciowego za pomocą, którego będzie przeprowadzany tak. Aby zmienić interfejs można również posłużyć się przyciskiem: Edit interfaces.
Kolejnym krokiem jest wybór protokołu, który zdefiniujemy po wybraniu odpowiedniej zakładki dostępnej po kliknięciu na przycisk: Launch attack Wybieramy zakładkę DHCP a następnie sending DISCOVER packet Aby uruchomić atak całość ustawień zatwierdzamy przyciskiem OK.
Atak DHCP Consumption Attack zostaje uruchomiony. Listę aktualnie przeprowadzanych ataków wraz z możliwością ich anulowania przeprowadzimy po wyborze przycisku: List attacks.
Tak jak poprzednio serwer DHCP zostaje zablokowany co dla klientów oznacza iż nie mogą oni uzyskać adresu IP oraz odnowić dzierżawy adresu już istniejącego. Nie ważne jaki sposób komunikacji z programem wybierzemy efekt wykonywanych operacji powinien być identyczny choć z doświadczenia wiem iż tryb interaktywny jest mniej problemowy gdyż w trybie graficznym program potrafi się zawiesić.
Do tej pory wykorzystywaliśmy serwer DHCP dostępny w ramach systemu Windows Server 2012 lecz nic nie stoi na przeszkodzie by rolę tą pełnił router. Więc zanim przejdziemy dalej prześledźmy jeszcze scenariusz w którym rolę serwera DHCP pełni router CISCO.
Serwer DHCP na routerze został uruchomiony (zostały wydane podstawowe polecenia, jeśli chcesz przeczytać więcej o sposobie konfiguracji routera, który będzie pełnić rolę serwera DHCP zapraszam do wpisu: Co w sieci siedzi. Protokół DHCP).
Statystyki serwera sprawdzimy za pomocą poleceń: show ip dhcp pool oraz show ip dhcp binding Jak widać poniżej z zdefiniowanej puli 254 adresów IP (punkt 1) dostępnych w ramach zakresu obejmujących sieć 10.0.0.0/24 został wykorzystany jeden (punkt 2).
Uruchamiamy atak wyczerpania zasobów serwera DHCP i sprawdzamy jego efekt. Wystarczyło kilka sekund by ilość przydzielonych adresów w ramach zdefiniowanej puli wzrosła do 217.
Dokładne sprawdzenie ilości przydzielonych adresów IP uwidacznia ich całą listę.
Dalsze przeprowadzenie ataku doprowadza do wyczerpania zasobów serwera DHCP a tym samym jak zostało pokazane na rysunku poniżej serwer przestaje dostarczać konfigurację sieciową zgłaszającym się klientom.
Opisany wyżej atak na serwer DHCP nie jest jedynym gdyż atakujący bardzo często wykorzystuje atak związany z podstawieniem fałszywego serwera DHCP. Jak już wiemy jak zablokować serwer DHCP nic nie stoi na przeszkodzie by uruchomić własny, którego zadaniem będzie np. dostarczanie takiej konfiguracji sieciowej w której adresy bramy będzie wskazywać na atakującego.
Prześledźmy zatem scenariusz w którym atakujący host o adresie IP 10.0.0.30 unieszkodliwia właściwy serwer DHCP a następnie uruchamia własny. Do wykonania tego zadania wykorzystamy użyte już wcześniej narzędzie Ettercap.
Po uruchomieniu narzędzia (wykorzystujemy tak jak w przypadku ataku ARP tryb Unified sniffing) z górnego menu wybieramy Mitm a następnie DHCP spoofing.
W nowo otwartym oknie określamy adresy jakie mają zostać dostarczone klientom:
- IP Pool - zakres adresów IP jakie może przydzielić serwer DHCP,
- Netmask - maska podsieci,
- DNS Server IP - adres serwera DNS (8.8.8.8 publiczny adres serwera Google),
Po zaakceptowaniu ustawień serwer DHCP zaczyna działać i oczekuje na klientów.
Do sieci podłączamy klienta (pamiętamy, że właściwy serwer DHCP nie działa), jak widać poniżej klientowi zostaje przydzielony pierwszy adres IP 10.0.0.50 z zdefiniowanej puli fałszywego serwera DHCP. Jak można łatwo zauważyć adres IP bramy wskazuje na hosta przeprowadzającego atak (10.0.0.30).
O fakcie przypisania adresu IP klientowi zostaniemy poinformowani w oknie narzędzia Ettercap.
Sprawdzenie tablicy ARP klienta dobitnie przekonuje Nas o powodzeniu ataku - adres IP 10.0.0.30 jest prawidłowo powiązany z adresem MAC atakującego.
Fałszywy serwer DHCP możemy również uruchomić wykorzystując do tego narzędzie Yersinia. Po uruchomieniu programu wybieramy ikonę Launch attack a następnie w oknie Choose attack na zakładce DHCP wybieramy opcje creating DHCP rogue server. W nowo otwartym oknie Parameters list definiujemy adresysieciowe, którymi ma dysponować fałszywy serwer DHCP. Po uzupełnieniu wszystkich pól atak uruchamiamy przyciskiem OK (okno definicji parametrów serwera nie znika). Fałszywy serwer DHCP działa i oczekuje na klientów.
W przypadku wykorzystania narzędzia Yersinia do utworzenia fałszywego serwera DHCP należy zainstalować dodatkowy pakiet: isc-dhcp-server
Podstawowa zasada działania przełącznika sprowadza się do tego, że dzięki ciągłemu uczeniu się adresów MAC podłączających się klientów (pamiętamy, że przełącznik jest urządzeniem warstwy drugiej) wie na który interfejs ma przekazać dane tak by mogły być one prawidłowo dostarczone. Oznacza to, że podczas normalnej pracy urządzenia nie dochodzi do sytuacji w której to dane są przekazywane na niewłaściwe porty. Odmienną zasadę działania oferował hub sieciowy gdyż w przypadku tego urządzenia trafiające pakiety do danego interfejsu były powielane na wszystkie inne a dany host decydował o tym czy otrzymane informacje odrzucić bądź zaakceptować. Jak łatwo się domyślić sieć zbudowana z wykorzystaniem hubów nie była rozwiązaniem zbyt wydajnym gdyż bardzo wiele danych było przesyłanych niepotrzebnie (hub przekazywał pakiety w kierunków hostów, które ich nie oczekiwały a w konsekwencji były one odrzucane). Jednak taki scenariusz dla osoby próbującej przechwycić ruch sieciowy był nader korzystny gdyż znacznie łatwiej było prowadzić sniffing. Pakiety od innych hostów do komputera przechwytującego ruch były przekazywane (ze względu na wykorzystanie huba) wystarczyło tylko zmusić kartę sieciową do ich rejestrowania. Sytuacja ta uległa pogorszeniu (z punktu widzenia atakującego) gdy zamiast hubów zaczęto wykorzystywać przełączniki. Lecz jest sytuacja w której możemy zmusić przełącznik by zachowywał się jak hub. Każdy przełącznik posiada tablicę adresów MAC, której zadaniem jest przechowywanie informacji o nauczonych adresach MAC należących do klientów. Rozmiar tej tablicy w zależności od urządzenia jest różny a co dla Nas najważniejsze jest ograniczony. Oznacza to ni mniej ni więcej, że dany switch jest w stanie nauczyć się i przechowywać określoną ilość adresów MAC. Pewnie zastanawiasz się Czytelniku - Co dzieje się w przypadku zapełnienia tablicy? Otóż w takiej sytuacji przełącznik zaczyna zachowywać się jak hub czyli otrzymane ramki zostają powielone na wszystkie interfejsy przełącznika. Dla hakera bądź osoby przeprowadzającej test penetracyjny przypadłość ta jest kolejnym wektorem ataku. Zatem spróbujmy przeprowadzić atak, którego zadaniem będzie wyczerpanie zasobów tablicy MAC przełącznika a w konsekwencji do zmuszenia switcha by działał jak hub.
Aby sprawdzić pojemność tablicy (ilość możliwych do przechowywania wpisów) wydaj polecenie: show mac-address-table count Po wydaniu komendy uzyskamy informację o ilości aktualnych wpisów w tablicy MAC (w rozbiciu na adresy poznane w sposób dynamiczny jak i te zdefiniowane statycznie przez administratora) oraz ilości dostępnego miejsca.
By poznać bardziej szczegółowe dane wydaj polecenie: show mac-address-table <rodzaj_wpisu> (w nowszych wersjach IOS: show mac address-table <rodzaj_wpisu>). Poniżej przykład wydania komendy dostarczającej nam informację o adresach MAC nauczonych dynamicznie. Oprócz samego adresu MAC zostaniemy poinformowani o interfejsie przez, który dany adres MAC jest osiągalny oraz o przynależności do sieci VLAN.
Do przeprowadzenia ataku użyjemy narzędzia: macof Aby rozpocząć atak zalewania przełącznika adresami MAC należy wydać polecenie: macof -i <interfejs> Po zatwierdzeniu komendy na domyślny adres IP 0.0.0.0 (wszyscy) zostaną wysłane ramki symulujące połączenia pomiędzy hostami.
Atak ten również możemy obserwować z wykorzystaniem narzędzia Wireshark. Jak można zauważyć poniżej program macof generuje pakiety protokołu IPv4 udające łączność pomiędzy losowo zdefiniowanymi adresami IP.
W przypadku programu macof do dyspozycji mamy dodatkowe przełączniki:
-i <interfejs> - określa użyty interfejs,
-s <adres_IP> - określa źródłowy adres IP,
-d <adres_IP> - określa docelowy adres IP,
-e <adres MAC> - określa docelowy adres sprzętowy,
-x <numer_portu> - określa źródłowy port TCP,
-y <numer_portu> - określa docelowy port TCP,
-n <liczba> - definiuje liczbę pakietów do wysłania.
Atak jest w toku. Ponowne sprawdzenie wykorzystania tablicy MAC ukazuje stan w którym to cała dostępna przestrzeń tablicy adresów MAC jest wykorzystana. Przełącznik wypełnił całą tablicę, nie może uczyć się nowy adresów MAC.
Dokładniejsze sprawdzenie wypełnienia tablicy pokaże Nam wszystkie poznane adresy MAC.
Atak zakończył się powodzeniem gdyż po przepełnieniu tablicy MAC przełącznika zaczyna się on zachowywać jak zwykły koncentrator tj. otrzymywane pakiety są rozsyłane na wszystkie interfejsy przełącznika. Poniżej przechwycony ruch sieciowy podczas trwania ataku - host 10.0.0.1 wysyła w kierunku hosta 10.0.0.20 zapytanie ping (udało się zarejestrować odpowiedzi). I na koniec jeszcze jedna mała uwaga - atak tego typu powiedzie się tylko w takiej sytuacji w której w tablicy MAC niema jeszcze wpisów odpowiadającym hostom co do których ruch monitorujemy. Jeśli wpisy istnieją nie uda nam się ruchu sieciowego przechwycić.
Aby wyczyścić tablicę adresów MAC wydaj polecenie: clear mac-address-table dynamic
Opisaliśmy podstawowe metody przeprowadzania ataku z wykorzystaniem założonych na wstępie artykułu protokołów, czas by przejść do opisu obrony przed tego typu atakami (choć do opisu przeprowadzenia jeszcze jednego ataku na chwilę wrócimy - szczegóły w dalszej części wpisu).
Opis obrony rozpoczniemy od protokołu DHCP gdyż opisana poniżej procedura zostanie powtórnie wykorzystana w innej metodzie obrony.
Zabezpieczenie serwera DHCP przed zalaniem go pakietami zawierającymi prośbę o przydzielenie adresu IP (a co za tym idzie wyczerpaniu zasobów serwera) a także ochronę sieci przed nieautoryzowanym serwerem DHCP osiągniemy konfigurując na przełączniku mechanizm DHCP snooping.
Działanie funkcji sprowadza się do określenia interfejsów zaufanych czyli takich przez które ustanowiona jest bezpośrednia łączność z serwerem DHCP oraz interfejsów niezaufanych - na portach tych nie może być prowadzona wymiana pakietów związana z funkcjonowaniem serwera DHCP (mówiąc inaczej serwer DHCP podłączony do portu przełącznika pracującego w trybie untrusted nie będzie działał). Port niezaufany w przypadku wykrycia podejrzanego ruchu sieciowego zostaje automatycznie zamknięty.
Zanim przejdziemy dalej uzupełnimy naszą topologię sieciową wykorzystywaną w atakach na serwer DHCP o niezbędne dane (numery interfejsów przełącznika do których podpięte są stacje).
Jak widać powyżej komunikacja z serwerem DHCP następuje przez interfejs f0/1. Interfejs ten będziemy konfigurowali jako zaufany. Aby na przełączniku skonfigurować mechanizm DHCP snooping należy wydać następujące polecenia:
1 - ip dhcp snooping vlan <numer_sieci_VLAN> - uruchamiamy funkcję w kontekście danej sieci VLAN. Urządzenia w scenariuszu są umiejscowione w domyślnej sieci VLAN tak więc polecenie przyjmuje postać: ip dhcp snooping vlan 1
2 - ip dhcp snooping - włączenie mechanizmu globalnie,
3 - w trybie konfiguracji interfejsu za pomocą polecenia: ip dhcp snooping trust ustawiamy zaufanie portu.
Dla reszty interfejsów sieciowych (aby nie konfigurować każdego portu z osobna wydajemy polecenie: interface range <zakres_portów>) określamy limit wystąpienia pakietów związanych z funkcjonowaniem serwera DHCP - po przekroczeniu ustalonej wartości następuje blokada interfejsu.
Działanie mechanizmu skontrolujemy wydając komendę: show ip dhcp snooping Port f0/1 jest portem zaufanym tak więc działanie mechanizmu DHCP snooping tego portu nie obejmuje, zaś na reszcie interfejsów jest przeprowadzana inspekcja związana z ruchem pakietów DHCP. W tym przypadku wartość progu została ustalona na 10 pakietów na sekundę.
Funkcja ochrony serwera DHCP została skonfigurowana nie pozostaje Nam nic innego jak sprawdzić ją w działaniu. Ponownie uruchamiamy atak zalewając serwer DHCP pakietami DHCP Discover. Chwilę po uruchomieniu ataku zostaje przekroczona graniczna wartość wystąpienia 10 pakietów na sekundę, interfejs przechodzi w stan: err-disable i zostaje wyłączony.
Status interfejsu możemy sprawdzić za pomocą dobrze znanych nam poleceń: show ip interface brief
a także: show interface <numer_interfejsu>
Do odnalezienia interfejsów w stanie err-disable możesz również użyć polecenia: show interface status err-disabled
Aby ponownie uruchomić interfejs przechodzimy do trybu konfiguracji danego portu i wyłączamy go (punkt 1) a następnie włączamy (punkt 2).
Jeśli na danym nie zaufanym porcie pojawi się obcy serwer DHCP mechanizm obrony wygeneruje odpowiednie ostrzeżenie. Podłączający się klient nie uzyska konfiguracji sieciowej.
Dzięki zastosowaniu mechanizmu DHCP snooping ochroniliśmy naszą sieć przed atakami związanymi z protokołem DHCP.
Aby zapobiec atakowi typu MAC Address Table Overflow Attack (przepełnienie tablicy MAC) możemy tak skonfigurować przełącznik by nie uczył się poznanych w sposób dynamiczny adresów MAC a co za tym idzie nie będzie budowana tablica MAC przełącznika. Standardowo jak już pewnie wiesz Czytelniku tablica ta służy switchowi do tego aby powiązać dany adres MAC z interfejsem na którym adres ten jest osiągalny.
Sprawdzenie tablicy MAC wykonujemy za pomocą polecenia: show mac address-table dynamic (już o tym wyżej pisałem i pewnie uważny Czytelnik zauważy, że w poprzednim przypadku użyłem polecenia w którym był zawarty myślnik pomiędzy słowami mac a address - Czemu teraz go nie ma? Otóż w trakcie tworzenia tego wpisu musiałem dokonać aktualizacji wersji oprogramowania przełącznika gdyż polecenia, które za chwilę przedstawię nie były dostępne w starszej wersji systemu a w nowych wersjach oprogramowania zrezygnowano z myślnika pomiędzy tymi słowami - ot i cała tajemnica). Po wydaniu polecenia zostanie wyświetlona tablica adresów MAC przełącznika jak widać poniżej znajdują się w niej tylko 3 wpisy (przyczyną wystąpienia dwóch adresów MAC na interfejsie f0/7 jest zastosowanie maszyny wirtualnej).
Wyłączenie tworzenia tablicy dla adresów poznanych dynamicznie wykonamy za pomocą komendy: no mac address-table learning vlan <numer_sieci> (poznawanie adresów MAC wyłączamy w ramach danej sieci VLAN). Dla uproszczenia opisu wszystkie urządzenia są zgrupowane w ramach domyślnej sieci VLAN 1 tak więc w efekcie polecenie przyjmuje postać: no mac address-table learning vlan 1
Po wyłączeniu możliwości zapamiętywania adresów MAC poznanych dynamicznie ponownie przechodzimy do wykonania ataku mającego na celu przepełnienie tablicy MAC przełącznika. Atak został uruchomiony.
Zweryfikujmy atak. Sprawdzenie stanu tablicy uwidacznia brak jakichkolwiek adresów MAC, które zostały uzyskane w sposób dynamiczny.
Sprawdzenie ogólnego stanu ilości przechowywanych adresów również pokazuje brak jakichkolwiek adresów MAC.
Tym razem atak MAC flooding zakończył się niepowodzeniem. Tablica adresów MAC przełącznika pozostaje pusta.
Brak adresów MAC w połączeniu z numerem portu w tablicy MAC przełącznika nie jest stanem pożądanym gdyż sytuacja ta zaburza normalne funkcjonowanie przełącznika. Dlatego po wyłączeniu automatycznego uczenia się adresów MAC sami musimy zadbać o wpisy informujące switch o powiązaniu: adres MAC urządzenia-numer interfejsu pod którym urządzenie te jest dostępne.
Aby statycznie zdefiniować tablicę MAC przełącznika należy do tego celu wykorzystać polecenie: mac address-table static <adres_MAC> vlan <numer_sieci_VLAN> interface <numer_interfejsu> Tak więc w przyjętym scenariuszu należy wydać polecenia jakie zostały pokazane na zrzucie poniżej.
Weryfikację wprowadzonych ustawień sprawdzimy za pomocą polecenia: show mac address-table static. Adresy MAC w powiązaniu z interfejsem zostały wprowadzone prawidłowo.
Jeśli interesuje Cię sprawdzenie tablicy adresów MAC w kontekście danej sieci VLAN użyj polecenia: show mac address-table static vlan <numer sieci_VLAN>
Opisane rozwiązanie mające uniknąć konsekwencji ataku przepełnienia tablicy MAC przełącznika nie jest metodą komfortową gdyż o wszystkie ustawienia musimy zadbać sami. O ile w małych sieciach, których topologia zbyt często nie ulega zmianie rozwiązanie te jest akceptowalne to w sieciach dużych o zmiennym stanie ilości urządzeń końcowych już nie. Dlatego też istnieją inne rozwiązania, które pozwolą nam zabezpieczyć naszą sieć przed tego typu atakiem a także innymi atakami wykorzystującymi słabości protokołów wykorzystywanych w warstwie 2 modelu ISO/OSI.
Podstawowym i jednym z najbardziej skutecznych sposobów zabezpieczenia sieci jest wykorzystanie mechanizmu Port Security. Przełączniki firmy CISCO zostały wyposażone w ten mechanizm, którego głównym celem jest zapewnienie komunikacji urządzeniom, które mają do tego prawo. Konfigurację tego mechanizmu w tym artykule nie opiszę gdyż jego dokładny opis zamieściłem w wpisie - Co w sieci siedzi. Warstwa 2 czyli podstawowa konfiguracja przełącznika CISCO Jeśli chcesz poznać zasady działania ochrony portu z wykorzystaniem funkcji Port Security zapraszam do lektury wpisu dostępnego pod podanym linkiem.
Zatem idziemy dalej i przechodzimy do protokołu ARP czyli jak obronić się przed atakiem polegającym na manipulacji adresami zapisanymi w tablicy ARP hosta.
Pierwsze zaproponowane rozwiązanie bazuje tak jak w przypadku określenia statycznych wpisów w tablicy MAC przełącznika na ręcznej (statycznej) definicji adresów zawartych w tablicy ARP. Po ręcznym zdefiniowaniu adresu IP w połączniu z adresem MAC unikniemy ataku zatrucia tablicy ARP gdyż system operacyjny zignoruje wszystkie odbierane komunikaty ARP, dotyczące adresów IP-MAC nie pozwalając na zastąpienie wpisów statycznych tymi uzyskanymi w sposób dynamiczny. Aby uzyskać całkowitą ochronę przed atakiem ARP spoofing należy na wszystkich urządzeniach utworzyć wpisy w tablicy ARP definiujące komunikację każdy z każdym. W praktyce z reguły stosuje się podejście w którym na komputerach tworzy się statyczne wpisy dla wszystkich serwerów oraz bram (wychodzimy z założenia, że większość hostów pomimo obecności w jednej sieci ze sobą się nie komunikuje).
Przechodzimy do ręcznej definicji wpisów tablicy ARP. Operację rozpoczniemy od hosta 10.0.0.1 W pierwszej kolejności warto wydać polecenie: netsh interface ip delete arpcache które usunie wszystkie zgromadzone do tej pory powiązania (uchroni nas to przed odmową dodania statycznego wpisu dla adresu, który już w tablicy się znajduje, czasem to nie pomaga wtedy wyłącz i włącz interfejs sieciowy). Wydanie polecenia usuwa również wszystkie zdefiniowane wcześniej wpisy statyczne.
Wpis definiujemy za pomocą komendy: arp -s <adres_IP> <adres_MAC> Na hoście oczywiście należy określić adresy hostów zdalnych. W naszym przypadku podajemy adresy przypisane hostowi 10.0.0.20 Weryfikację dodania wpisu sprawdzimy poleceniem: arp -a
Na komputerze 10.0.0.20 przeprowadzamy analogiczną czynność podając adresy hosta 10.0.0.1.
Po skonfigurowaniu statycznych tablic ARP sprawdźmy komunikację pomiędzy hostami. Test ping przeprowadzony z hosta 10.0.0.20 w kierunku komputera 10.0.0.1 zakończył się powodzeniem.
Po zdefiniowaniu wpisów statycznych sprawdźmy podatność obu systemów na atak ARP spoofing.
W przypadku systemu Windows wszystkie wpisy dodajemy osobnymi polecenia w systemie Linux możliwe jest zebranie wszystkich powiązań (para adresów IP-MAC) w osobnym pliku tekstowym i wprowadzenie wszystkich pozycji w sposób automatyczny (polecenie: arp w połączeniu z parametrem -f).
Ponownie wykorzystujemy narzędzie Ettercap gdzie po przeprowadzonym skanowaniu wraz z ustaleniem celów uruchamiamy atak zatrucia tablicy ARP.
Atak trwa. Sprawdźmy jak wygląda tablica ARP na hoście 10.0.0.20. Polecenie sprawdzenia tablicy zostało wydane dwa razy - przed uruchomieniem ataku (punkt 1) oraz podczas jego trwania (punkt 2). Wpisy w tablicy ARP hosta 10.0.0.20 nie uległy zmianie.
Sprawdzamy tablicę ARP na hoście 10.0.0.1 Tutaj również wpisy przed uruchomieniem ataku (punkt 1) są identyczne z wpisami podczas jego trwania (punkt 2).
Atak zatrucia tablicy ARP w przypadku komputerów na których zostały zdefiniowane wpisy statyczne nie powiódł się - wpisy poznane w sposób dynamiczny nie mogą zastąpić tych zdefiniowanych ręcznie przez administratora. Przechwytywanie pakietów z wykorzystaniem protokołu ARP pomiędzy hostami 10.0.0.1 a 10.0.0.20 zakończyło się niepowodzeniem co nie oznacza, że nie istnieją inne metody pozwalające Nam na przechwycenie komunikacji pomiędzy stacjami.
Miałem już pisać tylko o obronie przed atakami a nie opisywać kolejnych ale tak sobie myślę, że przedstawiony scenariusz pokaże również błędy popełniane przez administratorów, które w konsekwencji doprowadzają do tego, że atak na naszą sieć kończy się powodzeniem. W opisie przedstawionym powyżej udaremniliśmy atakującemu możliwość podsłuchania komunikacji pomiędzy hostami ale jak już wspomniałem wachlarz innych metod nadal pozostaje otwarty. Wektorem dla atakującego jest również sam przełącznik i to na nim skupimy teraz swoją uwagę.
Wykonując skanowanie sieci odkrywamy aktywne hosty (więcej o technikach i metodach skanowania dowiesz się zapoznając się z tym wpisem: Co w sieci siedzi. Skanowanie sieci - aktywne hosty), wśród gąszcza wykrytych adresów IP należy wytypować te które odpowiadają urządzeniom odpowiedzialnym za funkcjonowanie sieci (switche, routery, access pointy). I tu rodzi się pytanie - Jak tego dokonać?
Odpowiedź na to pytanie możemy uzyskać poprzez analizę aktywnych adresów MAC zdobytych podczas procesu skanowania sieci. Adres MAC jest zbudowany w ten sposób, że pierwsze 24 bity (bądź jak ktoś woli pierwsze 3 bajty) są przypisane do producenta urządzenia sieciowego - to tzw. vendor code , reszta adresu (kolejne 24 bity, bądź 3 bajty) są unikalnym identyfikatorem danego egzemplarza karty. Na przykład adres 00-01-42-AB-01-21 oznacza, że karta została wyprodukowana przez CISCO ponieważ vender code 00-01-42 jest przypisany do firmy CISCO zaś producent nadał jej numer AB-01-21.
Aby odnaleźć identyfikatory jakie zostały przypisane do producentów urządzeń sieciowych możesz posłużyć się wyszukiwarką dostępną na stronie - http://www.miniwebtool.com/mac-address-lookup/
Wpisując nazwę firmy bądź vender code uzyskamy informację o producencie.
Tak więc wracając do analizy odkrytych adresów MAC i przypisując im producenta z dość dużym prawdopodobieństwem możemy wytypować adresy, które należą do urządzeń odpowiedzialnych za zarządzanie siecią (popularne firmy to m.in. CISCO, Juniper, HP, MikroTik, TP-link, Ubiquiti Networks, ALANTEC, Jirous). Analizując adresy pierwsze swoje kroki skieruj ku adresom IP rozpoczynającym i kończącym daną podsieć gdyż to najczęściej do tych adresów IP będą przypisane urządzenia - np. adresem bramy bardzo często jest adres IP o ogólnym formacie x.x.x.1 bądź x.x.x.254
W naszym przypadku odkrywamy urządzenie o adresie 10.0.0.254 i po analizie adresu MAC dochodzimy, że jest to urządzenie CISCO (w tym przypadku zostało wykorzystane narzędzie Nmap, które samodzielnie dokonuje identyfikacji producenta urządzenia).
Wykonajmy zatem atak zatrucia bufora ARP dla adresu IP 10.0.0.254 Atak swym działaniem obejmuje całą sieć. Po wykonaniu operacji zatrucia tablicy ARP przełącznika oczekujemy na połączenie oczywiście w tle mamy uruchomiony program przechwytujący ruch sieciowy. Jeśli administrator dokonał konfiguracji przełącznika i wszystko działa to z reguły nie ma potrzeby by sprawdzać konfigurację switcha dlatego też oczekiwanie aż administrator nawiąże połączenie może zająć nam wiele czasu. Dlatego też by zmusić administratora do nawiązania połączenia możemy dodatkowo wykonać atak, którego zadaniem będzie zaburzenie działania sieci. Niedziałająca poprawnie sieć wymusi na osobach dbających o jej działanie podjęcie odpowiednich kroków celem znalezienia usterki. Szukając rozwiązania zaistniałych problemów wzrasta szansa na to, że administrator nawiąże połączenie z urządzeniem, którego ruch sieciowy monitorujemy.
Dodatkową opcją jest wykorzystanie takich narzędzi jak: Cisco Auditing Tool czy Cisco-Torch, które potrafią wykonać atak brute-force bądź atak słownikowy na urządzenie celem złamania danych logowania.
Atak ARP na switch jest uruchomiony i jak widać poniżej powiódł się on - gdyż ruch sieciowy ze stacji 10.0.0.1 z której będzie wykonywane logowanie do switcha jest przekazywany w kierunku hosta atakującego 10.0.0.30 (oczywiście podczas prowadzenia prawdziwego ataku do tych informacji jeszcze nie mamy dostępu - zadaniem zrzutu umieszczonego poniżej jest tylko pokazanie Ci Czytelniku iż atak zatrucia bufora ARP zakończył się powodzeniem).
Administrator wykonuje proces logowania i jak widać poniżej po analizie przechwyconych pakietów udaje Nam się zdobyć hasło - cisco (hasło do nawiązania połączenia oraz do przejścia do trybu enable).
Atak zatrucia tablicy ARP możemy zakończyć gdyż zdobyliśmy potrzebne nam dane.
W naszych rozważaniach wszystko przebiegło po naszej myśli gdyż zostały spełnione określone warunki, które umożliwiły Nam przeprowadzenie ataku z powodzeniem.
Pierwszym błędem jest wykorzystanie protokołu Telnet, który został użyty do nawiązania połączenia z przełącznikiem. Protokół ten nie gwarantuje Nam żadnej ochrony podczas przesyłania danych gdyż wszystkie informacje nie są w żaden sposób szyfrowane - cała komunikacja odbywa się otwartym tekstem. Osoba przeprowadzająca atak uzyska wszystkie niezbędne dane. Zatem by zwiększyć bezpieczeństwo sieci zrezygnuj z Telnetu na rzecz bezpieczniejszego protokołu jakim jest SSH (jak przeprowadzić taką konfigurację dowiesz się po przeczytaniu wpisu - Co w sieci siedzi. Warstwa 2 czyli podstawowa konfiguracja przełącznika CISCO).
Drugim błędem jest umieszczenie adresu IP przełącznika przez który uzyskujemy dostęp do urządzenia w tej samej sieci VLAN w której pracują użytkownicy sieci. Dobrą praktyką jest wydzielenie odrębnej sieci VLAN służącej do administrowania urządzeniami sieciowymi a co do której dostęp mają tylko administratorzy. Wydzielenie osobnej sieci VLAN służącej do zarządzania urządzeniami zagwarantuje Nam, że postronni użytkownicy sieci nie będą mieli dostęp do adresów IP, które urządzeniom zostały przypisane. Jak taką sieć VLAN skonfigurować dowiesz się tu: Co w sieci siedzi. Warstwa 2 - konfiguracja sieci VLAN.
Aby dodatkowo zwiększyć poziom bezpieczeństwa możesz również zdefiniować adresy IP które mają prawo łączyć się z danym urządzeniem.
W sieciach w których bezpieczeństwo jest stawiane na pierwszym miejscu stosuje się jeszcze inny wybieg polegający na stworzeniu całkiem odrębnej fizycznej sieci, która służy tylko do zarządzania oraz monitorowania urządzeń sieciowych (metoda Out of Band). Rozwiązanie te znacząco podnosi poziom bezpieczeństwa, gdyż do sieci takiej mają dostęp tylko administratorzy (normalni użytkownicy z niej nigdy nie korzystają) a dodatkowo mamy redundancję zapewniającą nam dostęp do urządzeń gdy właściwa sieć przestanie działać (dodatkowy kanał komunikacyjny).
Atakujący zdobył dostęp do przełącznika a tym samym uzyskał wgląd w ustawienia urządzenia i na pewno jest bogatszy o wiele cennych informacji dotyczących budowy naszej sieci. Dodatkowo uzyskuje on możliwość manipulowania urządzeniem.
Jedną z ciekawszych rzeczy jakie może wykorzystać atakujący jest wykorzystanie funkcji port mirroring. Działanie tego mechanizmu sprowadza się do wskazania interfejsów przełącznika, z których cały ruch sieciowy (odbierany, wysyłany bądź oba) będzie kopiowany na inny wybrany port. W przypadku CISCO mechanizm ten nazwano SPAN (ang. Switch Port Analyzer).
Spróbujmy zatem wykorzystać tę funkcję przełącznika.
Atakujący dzięki zdobytym danym uwierzytelniającym wykonuje proces logowania do urządzenia i konfiguruje kopiowanie ruchu sieciowego tak by móc przechwytywać komunikacje pomiędzy hostem o adresie IP 10.0.0.1 a 10.0.0.20
Ustawienie sesji sprowadza się do wydania dwóch poleceń:
1 - monitor session <numer_sesji> source interface <id_interfejsu> <rodzaj_ruch_sieciowego> - polecenie określa numer sesji funkcji SPAN oraz definiuje interfejs z którego ruch ma zostać skopiowany wraz z typem ruchu. W naszym przypadku kopiowany będzie ruch sieciowy przychodzący i wychodzący z interfejsu f0/1 (do portu tego podłączony jest host 10.0.0.1 - port f0/7 również jest dobrym wyborem). Użycie parametru: rx definiuje ruch otrzymywany przez przełącznik zaś parametr: tx określa ruch opuszczający dany interfejs.
2- monitor session <numer_sesji> destination interface <id_interfejsu> - polecenie definiuje do którego interfejsu ma zostać przesłany skopiowany ruch sieciowy.
Atakujący kopiowanie ruchu sieciowego ustawił na interfejs f0/3 czyli port do którego sam jest podłączony. To niestety jest błąd gdyż zatwierdzając drugie polecenie pozbawił się łączności z siecią a tym samym stracił możliwość wydawania poleceń urządzeniu.
Normalna łączność z siecią został utracona lecz na interfejs f0/3 przełącznika jest realizowany proces kopiowania otrzymywanych/wysyłanych danych z interfejsu f0/1. Uruchamiając narzędzie do przechwytywania pakietów możemy rejestrować łączność pomiędzy hostami. Na hoście 10.0.0.1 wydano polecenie ping w kierunku hosta 10.0.0.20 jak widać poniżej udało się tą komunikację przechwycić.
Konfigurację SPAN możemy zweryfikować wydając polecenie: show monitor session <numer_sesji>
Gdy atakujący ma dostęp do przełącznika może poprzez jego konfigurację zdobyć wiele cennych informacji w tym przypadku ustawienie interfejsu f0/3 jako tego na który ma być kopiowany ruch oczywiście dla przeprowadzającego atak zakończyło się powodzeniem pomimo tego, że sam fizycznie od sieci się odciął. Aby uniknąć tego typu sytuacji, ruch monitorowany należałoby kopiować na inny np. nie używany interfejs do którego jest podpięta stacja kontrolowana również prze atakującego.
Mechanizm SPAN bardzo często jest wykorzystywany przez samych administratorów do wykrywania anomalii w ruchu sieciowym. Do interfejsu takiego można podpiąć komputer, który w czasie rzeczywistym otrzymywane pakiety będzie analizował i gdy wykryje jakieś nieprawidłowości zostaniemy o nich powiadomieni - systemy IDS/IPS których zadaniem jest wykrywanie (IDS) lub wykrywanie i blokowanie ataków sieciowych (IPS).
W przypadku CISCO istnieje odmiana sesji SPAN, która może być stosowana w odniesieniu do sieci VLAN - tzw. VSPAN – Virtual SPAN.
Przykładowy zapis zamieszczony poniżej oznacza, że na porcie f0/3 pojawią się kopie ramek kierowanych do portów przełącznika, które swoje interfejsy mają przypisane do sieci VLAN o numerach od 10 do 12.
switch(config)# monitor session 1 source vlan 10-12 rx
switch(config)# monitor session 1 destination interface f0/3
Działanie funkcji SPAN dodatkowo możemy rozszerzyć na wiele przełączników, które są ze sobą połączone oraz skonfigurowane tak by przechwytywany ruch sieciowy odbywał się poprzez inne switche do komputera go rejestrującego - RSPAN (Remote SPAN).
Dokładna konfiguracja urządzeń pod kątem monitorowania i przechwytywania ruchu sieciowego i jego dalszej analizie wykracza już poza ramy tego wpisu, co nie oznacza że do tematu tego nie będę chciał w przyszłości wrócić.
Wracając jeszcze chwilkę do metody wykorzystanej przez atakującego to oczywiście możliwy jest również taki scenariusz (pod warunkiem, że atakujący ma dostęp fizycznie do sieci) w którym następuje podpięcie dodatkowego urządzenia na drodze pomiędzy hostem 10.0.0.1 a 10.0.0.20, którego zadaniem będzie kopiowanie otrzymywanego ruchu sieciowego. Do tego zadania posłużyć może nam najzwyklejszy koncentrator (pamiętamy, że w przypadku hubów sieciowych ruch jest wysyłany na wszystkie jego porty) bądź możemy skorzystać z bardziej zaawansowanego urządzenia jakim jest TAP. Zadaniem tego typu urządzeń jest przekazywanie ruchu sieciowego przy jednoczesnym kopiowaniu go. TAP zaopatrzony jest z reguły w trzy porty: port A, port B oraz port monitorujący. Porty A i B służą do połączenia urządzenia z istniejącą strukturą sieciową zaś na port monitorujący przesyłany jest cały ruch sieciowy jaki jest przekazywany pomiędzy portem A i portem B. Dużą zaletą tego typu urządzeń jest fakt iż nie wprowadzają one żadnych dodatkowych opóźnień czy spadków przepustowości łącza (jak to ma w przypadku użycia koncentratora) podczas przesyłania danych. W sprzedaży przez takie firmy jak: NetOptics, Finisar czy Gigamon są modele TAP-ów, które przeznaczone są do sieci tradycyjnych jak i światłowodowych.
Tak więc topologia sieciowa w przypadku użycia dodatkowego urządzenia, którego celem byłoby przechwytywanie pakietów mogłaby wyglądać następująco (cały czas pamiętamy, że tego typu rozwiązanie wymaga fizycznego dostępu do atakowanej sieci):
Wniosek z takiego scenariusz płynie taki - że bezpieczeństwo naszej sieci nie sprowadza się tylko do właściwej konfiguracji urządzeń sieciowych ale również obejmuje ochronę fizycznego dostępu do infrastruktury.
Wracamy do wątku głównego i omawiamy dalej jak ustrzec się przed atakiem zatrucia tablicy ARP.
Aby zapobiec zmianie tablicy ARP na przełączniku tak samo jak na hostach możemy zdefiniować statyczne adresy MAC, które zostaną powiązane z adresem IP i interfejsem przełącznika. Sprawdzenie tablicy ARP w kontekście adresów nauczonych dynamicznie i statycznie wykonamy wydając komendę: show arp dynamic bądź show arp static Jak widać poniżej w tablicy ARP przełącznika istnieją tylko dwa wpisy poznane w sposób dynamiczny i brak jest wpisów statycznych. Naszym celem jest utworzenie dla hostów 10.0.0.1 oraz 10.0.0.20 wpisów statycznych tak by ich zamiana była niemożliwa.
Rozpoczynamy od usunięcia istniejących wpisów. Usunięcie powiązania wykonamy za pomocą komendy: clear ip arp <adres_IP> Ponowne sprawdzenie tablicy uwidacznia brak jakichkolwiek wpisów dynamicznych.
Wpisy statyczne definiujemy za pomocą polecenia: arp <adres_IP> <adres_MAC> arpa <interfejs> Komendę wydajemy w trybie konfiguracji globalnej. Poniżej zostały utworzone wpisy statyczne dla obu hostów.
Poprawność dodania wpisów zweryfikujemy za pomocą znanego Nam już polecenia: show arp static Wpisy zostały dodane prawidłowo.
Dodatkowo wszystkie wpisy zapisane w tablicy możemy sprawdzić poleceniem: show ip arp zaś gdy chcemy uzyskać jeszcze bardziej szczegółowe dane możemy posłużyć się komendą: show arp <static|dynamic> detail
Ustawienie wpisów statycznych na przełączniku tak samo jak w przykładzie poprzednim w którym to tablicę ARP definiowaliśmy na hoście uchroni Nas przed atakiem zatrucia tablicy ARP switcha - wpisy określone statycznie mają pierwszeństwo przed tymi poznanymi w sposób dynamiczny.
Kontrolę nad pakietami ARP możemy sprawować jeszcze przy pomocy jednego mechanizmu jakim jest Dynamic ARP Inspection. Zadaniem funkcji jest kontrolowanie pojawiających się wpisów ARP tak by tylko uprawnione hosty mogły zostać dopuszczone do komunikacji. Działanie tego mechanizmu jest ściśle powiązane z opisywaną już funkcją DHCP snooping gdyż to na podstawie tablicy przydzielonych adresów IP powiązanych wraz z adresami MAC opiera się działanie inspekcji prowadzonej przez przełącznik. Dla poprawnego działania funkcji musi istnieć tablica tworzona dzięki włączonemu mechanizmowi DHCP snooping gdyż to na jej podstawie (badane są dwa pola tablicy tj. IPAddress oraz MACAddress) następuje weryfikacja istnienia hosta, który dane pakiety ARP generuje. Brak hosta w tablicy skutkuje zablokowaniem prowadzenia komunikacji.
Aby bardziej szczegółowo zademonstrować działanie mechanizmu przejdźmy do jego konfiguracji.
Konfigurację rozpoczynamy od włączenia funkcji DHCP snooping (punkt 1 oraz 2) a następnie za pomocą komendy: ip arp inspection vlan <id_sieci_VLAN> uaktywniamy mechanizm Dynamic ARP Inspection (punkt 3). Polecenia wydajemy w trybie konfiguracji globalnej.
Oba potrzebne mechanizmy zostały uruchomione.
Przechodzimy do konfiguracji interfejsu f0/1 gdyż to do tego portu podłączony jest serwer DHCP. W trybie konfiguracji interfejsu definiujemy ten port jako zaufany dla obu włączonych procesów:
- ip dhcp snooping trust - mechanizm DHCP snooping,
- ip arp inspection trust - mechanizm Dynamic ARP Inspection.
Reszta interfejsów przełącznika otrzymuje status portu niezaufanego - no ip arp inspection trust (punkt 1). Dodatkowo zostaje określony próg możliwych do wystąpienia w czasie jednej sekundy pakietów ARP (punkt 2). Oczywiście możemy dodatkowo określić limit pakietów DHCP, leczy by nie wprowadzać dodatkowego zamieszania z dodatkowymi komendami z tej opcji zrezygnowałem - skupiamy się na Dynamic ARP Inspection.
Aby całość przeprowadzanej konfiguracji była prawidłowa a co za tym idzie by działanie mechanizmu odbywało się prawidłowo w trybie konfiguracji globalnej należy wydać jeszcze jedno polecenie: no ip dhcp snooping information option Zadaniem tej komendy jest przekazanie do serwera DHCP prawidłowego pakietu żądania by przydzielona konfiguracja sieciowa mogła zostać dostarczona do klienta. Temat sensu wydania tej komendy niestety wykracza poza ramy tego wpisu i dokładne wytłumaczenie istoty problemu wymagałoby zbyt obszernych wyjaśnień - co nie oznacza, że do tematu nie powrócę. Jeśli Czytelniku byłbyś szczególnie zainteresowany tym zagadnieniem odsyłam do wpisu - http://blog.ine.com/2009/07/22/understanding-dhcp-option-82/
Host 10.0.0.1 nawiązuje połączenie z serwerem DHCP i zostaje mu przypisany adres IP. Po przypisaniu adresu IP hostowi w tablicy DHCP snooping fakt ten powinien zostać odnotowany. Sprawdzenia tablicy dokonamy za pomocą polecenia: show ip dhcp snooping binding
Host 10.0.0.1 uzyskał dostęp do sieci i może prawidłowo komunikować się z innymi hostami.
A co w przypadku hosta atakującego? Host o adresie IP 10.0.0.30 korzysta z konfiguracji statycznej z pominięciem serwera DHCP. Pomimo prawidłowego skonfigurowania interfejsu sieciowego hosta nie ma on możliwości nawiązania poprawnej komunikacji z innymi komputerami. Test ping w połączeniu z adresem 10.0.0.20 kończy się niepowodzeniem.
Ślady przeprowadzenia testu ping odnajdziemy również w komunikatach przełącznika. Komunikacja hosta 10.0.0.30 z siecią jest niemożliwa gdyż w tablicy mechanizmu DHCP snooping brak jest wpisu odnoszącego się do tego komputera.
Spróbujmy sytuację naprawić i na hoście 10.0.0.30 modyfikujemy konfigurację sieciową poprzez zrezygnowanie z metody opartej o wpisy statyczne. Host został skonfigurowany w ten sposób aby potrzebne ustawienia sieci uzyskać dzięki serwerowi DHCP. Hostowi zostaje przypisany adres IP 10.0.0.31
Fakt przypisania adresu IP przez serwer DHCP odnajdziemy w tablicy DHCP snooping przełącznika.
Ponownie wykonujemy test ping - tym razem komunikacja pomiędzy komputerami 10.0.0.31 a 10.0.0.20 jest możliwa.
Weryfikację działania mechanizmu Dynamic ARP Inspection wraz z statystykami dokonamy dzięki wydaniu polecenia: show ip arp inspection
Konfigurację interfejsów w kontekście działania mechanizmu poznamy wydając komendę: show ip arp inspection interfaces
Lecz co się stanie gdy host 10.0.0.31 zacznie przeprowadzać atak zatrucia bufora ARP? Aby odpowiedzieć na to pytanie należy atak tego typu zasymulować. Na hoście 10.0.0.31 zostaje uruchomione narzędzie Ettercap. Jak zapewne pamiętasz Czytelniku pierwszym etapem przy definicji parametrów ataku jest przeprowadzenie skanowania aktywnych hostów. Proces skanowania zostaje uruchomiony lecz kończy się on niepowodzeniem gdyż ilość wygenerowanych pakietów ARP przekracza ustalony limit ustawiony dla interfejsu. Interfejs f0/3 zostaje wyłączony.
Sprawdzenie statusu portu wskazuje na stan err-disabled a za wyłączenie go odpowiada mechanizm Dynamic ARP Inspection.
Aby interfejs odblokować w trybie jego konfiguracji wydajemy polecenie: shutdown a następnie no shutdown.
Sprawdźmy co stanie się w sytuacji w której proces skanowania uda Nam się przeprowadzić i host 10.0.0.31 uruchomi atak ARP spoofing. Limit pakietów powodujących wyłączenie interfejsu zostaje zwiększony do 100. Proces skanowania tym razem przebiega bez zakłóceń i atakujący uruchamia atak.
Atak zostaje przerwany z powodu błędów w dopasowaniu adresów MAC oraz IP zapisanych w tablicy DHCP snooping.
Mechanizm inspekcji ARP zadziałał prawidłowo nie dopuszczając do przeprowadzenia ataku.
Udało Nam się zapobiec atakom zatrucia tablicy ARP poprzez konfigurację przełącznika lecz metody ochrony możemy również rozszerzyć o hosty (ale to już też Czytelniku wiesz) .
Sprawdźmy zatem jakie mamy możliwości by zapobiec atakowi ARP poprzez wykorzystanie do tego celu odrębnych aplikacji.
Powracamy po raz kolejny do narzędzia WinArpAttacker, do tej pory aplikacja ta służyła nam do przeprowadzania ataków na sieć teraz odwracamy rolę i pokażę jak wykorzystać te narzędzie by sieć ochronić.
Domyślnie po uruchomieniu programu, aplikacja przejmuje kontrolę nad tablicą ARP hosta na którym została uruchomiona i na bieżąco kontroluje czy nie zaszły w niej jakieś zmiany. Jeśli takowe nastąpią użytkownik zostanie o nich powiadomiony stosownym komunikatem.
Przejdźmy zatem do zobrazowania takiej sytuacji. Narzędzie zostało uruchomione na hoście o adresie IP 10.0.0.1 (kontrolą integralności tablicy zarządzamy za pomocą dwóch ikon Detect oraz Stop). W kolejnym kroku atakujący czyli host 10.0.0.30 przeprowadza atak mający na celu zatrucie tablicy ARP tak by możliwe było przechwytywanie ruchu sieciowego pomiędzy hostami 10.0.0.1 a 10.0.0.20.
Jak już wiesz Czytelniku by atak ARP powiódł się oryginalny adres MAC skojarzony z adresem 10.0.0.20 (08-00-27-AB-D3-93) musi zostać zamieniony na adres MAC atakującego (EE-EE-EE-EE-EE-EE) tak by wszystkie ramki były przekazywane przez niego.
Uruchomienie ataku wyzwala komunikat o zmianie domyślnego adresu MAC hosta 10.0.0.20 na adres MAC EE-EE-EE-EE-EE-EE Adres ten ulega zmianie lecz po chwili uruchomiona opcja ochrony tablicy ARP adres MAC atakującego ponownie zmienia na prawidłowy.
Jak można się domyśleć dzięki narzędziu WinArpAttacker atak z wykorzystaniem zatrucia tablicy ARP nie dochodzi do skutku. Wydanie polecenia ping z hosta 10.0.0.1 w kierunku komputera 10.0.0.20 nie jest rejestrowane przez atakującego.
W systemie Linux spójność tablicy ARP możemy kontrolować za pomocą narzędzia: arpwatch Aby zainstalować niezbędne pakiety wydaj polecenie: apt-get install arpwatch Program ten po uruchomieniu kontroluje stan tablicy ARP na komputerze lokalnym i jeśli zajdzie zmiana fakt ten zostanie zarejestrowany w pliku: /var/log/syslog
Aby uruchomić narzędzie wydajemy polecenie: /etc/init.d/arpwatch start (punkt 1) a następnie za pomocą komendy: arpwatch -i <identyfikator_interfejsu_sieciowego> określamy interfejs, który ma podlegać nadzorowi (punkt 2).
W opisie przyjęto iż host o adresie IP 10.0.0.1 to ofiara (na hoście tym zostaje uruchomiony daemon arpwatch) natomiast atakujący to komputer o adresie IP 10.0.0.30 i tak jak w przypadku sytuacji z wykorzystaniem aplikacji WinArpAttacker naszym celem jest przechwycenie ruchu sieciowego pomiędzy komputerami 10.0.0.1 a 10.0.0.20
Narzędzie zostało uruchomione i działa w tle aby mieć podgląd na pojawiające się komunikaty wydaj polecenie: tail -f /var/log/syslog
Atakujący przeprowadza atak zatrucia tablicy ARP. Uruchomiona usługa arpwatch wykrywa zamianę adresu MAC i Nas o fakcie tym informuje. Niestety w tym przypadku nie mamy aktywnej ochrony jak to miało miejsce przy wykorzystaniu programu WinArpAttacker i atak kończy się sukcesem, atakujący może przechwytywać ruch sieciowy (na razie, gdyż administrator wie, że atak nastąpił i może do następnego nie dopuścić - atakujący został wykryty).
Arpwatch oprócz zamiany adresów MAC wykrywa również ataki typu LAN storm, które związane są z protokołem ARP, gdy atak nastąpi stosowne komunikaty pojawią się w pliku /var/log/syslog Poniżej przedstawiono zrzut pliku w którym zarejestrowano przebieg ataku zalewania sieci pakietami ARP Request.
W zarządzanej sieci komputerowej interfejsy sieciowe, które pracują w trybie nasłuchiwania (ang. promiscuous mode) stanowią potencjalne zagrożenie gdyż karta sieciowa pracująca w tym trybie zdolna jest do rejestrowania danych, które nie są dla niej przeznaczone. Wykrycie interfejsów sieciowych pracujących w tym trybie jest sygnałem dla administratora sieci, że dzieje się coś niepokojącego.
Aby wykryć w zarządzanej sieci interfejsy, które korzystają z tego trybu można posłużyć się m.in. narzędziem WinArpAttacker. Po uruchomieniu programu z górnego menu wybieramy pozycję Scan a następnie opcję Advanced, która to uruchomi dodatkowe okno za pomocą którego zdefiniujemy opcję skanowania.
W oknie Scan określamy zakres skanowania oraz jego tryb. Zaznaczenie opcji Antisniff scan spowoduje przeprowadzenie skanowania pod kątem wystąpienia interfejsów pracujących w trybie nasłuchiwania. Operacja skanowania polega na wysłaniu specjalnie spreparowanych pakietów i badaniu uzyskanych odpowiedzi. Szczegółowy opis klasyfikacji interfejsu, który pracuje w trybie domyślnym bądź w trybie promiscuous wykracza poza ramy tego wpisu więc procedurę przyszeregowania interfejsu do danego trybu pracy postaram opisać się w oddzielnym wpisie. Jeśli ten temat Czytelniku szczególnie Cię interesuje odsyłam do wpisów zawartych pod następującymi odnośnikami (wersja angielska) - http://www.securityfriday.com/promiscuous_detection_01.pdf bądź http://hadmernok.hu/132_27_nagyd_1.pdf
Po zatwierdzeniu skanu przyciskiem Scan następuje proces odkrywania urządzeń, których karty sieciowe pracują w trybie promiscuous. Jak widać poniżej skan naszej ćwiczebnej sieci uwidocznił dwa takie interfejsy - pierwszy z nich (10.0.0.1) to interfejs komputera przeprowadzającego skanowanie a drugi (10.0.0.30) należy do atakującego.
W systemie Linux (lecz także Windows) do skanowania możemy użyć narzędzia NMap a mówiąc bardziej szczegółowo jednego ze skryptów napisanych dla tego programu, którego celem jest wykrycie interfejsów pracujących w trybie nasłuchiwania.
Aby uruchomić proces skanowania należy wydać polecenie: nmap --script=sniffer-detect <zakres_skanowania>
Poniżej zaprezentowałem proces skanowania dwóch hostów o adresach IP 10.0.0.30 oraz 10.0.0.20 i jak można zauważyć w przypadku tego pierwszego skan ujawnił iż interfejs tego hosta jest ustawiony do pracy w trybie promiscuous.
Ataki typu LAN storm mogą zostać unieszkodliwione dzięki zastosowaniu funkcji przełącznika nazwanej storm control, której zadaniem jest monitorowanie poziomu ruchu sieciowego.
Mechanizm Storm control do pomiaru aktywności ruchu sieciowego może wykorzystywać jedną z następujących metod:
- pomiar szerokości pasma jako procent całkowitego pasma dostępnego na porcie,
- pomiar szybkości w jakiej odbierane są pakiety - szybkość tą możemy wyrazić w packets/sec lub bits/sec.
Można ustawić zarówno próg ruchu narastającego, jak i próg ruchu opadającego.
Nieważne z której metody skorzystamy, gdy zostaje osiągnięty zdefiniowany próg, port zostaje zablokowany.
Jeśli zdefiniowano tzw. próg opadający blokowanie portu następuje powyżej ustalonej wartości zaś gdy poziom ruchu sieciowego opadnie poniżej zdeklarowanej wartości port powraca do normalnego funkcjonowania.
Mechanizm ten konfigurujemy w trybie danego interfejsu poprzez ustalenie wartości progowych dla danego typu ruchu.
W przypadku wybrania metody opartej na określeniu procentu dostępnego pasma, dostępne wartości ustalamy z przedziału od 0.00% do 100.00%. Przy czym wartość 100.00% oznacza, że na dany typ ruchu nie nałożono żadnego limitu zaś wartość 0.00% oznacza, że cały ruch danego typu na porcie jest blokowany.
Przejdźmy zatem do części praktycznej i sprawdźmy mechanizm w działaniu. Ponieważ stacja atakującego jest podpięta do interfejsu f0/3 przełącznika tak więc funkcję tą włączymy właśnie na tym porcie.
1 - wydanie polecenia spowoduje ustalenie dozwolonego progu ruchu broadcast na 12,5%,
2 - ustalenie progu ruchu multicast na poziom - próg narastający 3000 pakietów w ciągu sekundy, próg opadający 2000 pakietów na sekundę (po przekroczeniu wartości 3k pps następuje blokada portu zaś gdy ruch opadnie do wartości poniżej 2k pps port zostaje włączony),
3 - ustalenie akcji związanej z przekroczeniem wartości progowych - w tym przypadku wyłączenie portu. Wydanie polecenia: storm-control action trap switch spowoduje wysłanie loga SNMP w momencie pojawienia się burzy pakietów.
Weryfikację ustawień możemy przeprowadzić wydając polecenia: show storm-control bądź show storm-control <określony_typ_ruchu_sieciowego>
Mechanizm został skonfigurowany. Przechodzimy na hosta atakującego i na nim zostaje uruchomiony atak generujący dużą ilość pakietów broadcast (atak typu DHCP consumption attacks). Chwilę po uruchomieniu ataku port zostaje wyłączony - zdefiniowany procent wykorzystania pasma dla tego typu ruchu został przekroczony.
Status interfejsu możemy sprawdzić wydając komendę: show interfaces status err-disabled Jak widzimy poniżej port jest wyłączony z powodu naruszenia zdefiniowanej polityki bezpieczeństwa związanej z mechanizmem storm-control.
Aby interfejs odblokować w trybie jego konfiguracji wydajemy polecenie: shutdown a następnie no shutdown.
Podsumowując wpis aby uniknąć opisywanych ataków zastosuj się do poniższych wskazówek:
- pamiętaj, że bezpieczeństwo sieci do również ochrona fizyczna dostępu do urządzeń oraz do komputerów,
- protokoły z których nie korzystasz - wyłącz,
- nieużywane interfejsy przełącznika - wyłącz a te do których są podpięte urządzenia końcowe ustaw do pracy w trybie access,
- skonfiguruj mechanizm Port Security,
- odseparuj dostęp zdalny do urządzeń sieciowych od sieci domyślnej, utwórz do tego celu osobny VLAN,
- realizując dostęp zdalny nie wykorzystuj protokołu Telnet, zamień go na SSH,
- celem analizowania ruch sieciowego wykorzystaj funkcję SPAN,
- pamiętaj o takich mechanizmach jak Dynamic ARP Inspection, DHCP Snooping oraz Storm control,
- rozważ wprowadzenie ochrony dostępu do sieci w oparciu o wykorzystanie protokołu 802.1X
I tu kończymy. Wyszło tego sporo. Powiem szczerze, że w planach miałem opisanie również bardziej subtelnych ataków związanych z sieciami VLAN, protokołem STP czy połączeniami typu trunk ale postanowiłem to rozbić na odrębne wpisy ze względu na dość obszerny zakres omawianego tematu. Jak mówi stare przysłowie - „Co się odwlecze, to nie uciecze” tak więc do tematu wrócimy już wkrótce (jeden wpis a już obiecałem 4 inne).
I tak już na sam koniec - złota myśl (gdzieś kiedyś to usłyszałem i strasznie mi się spodobało, bo wiele prawdy w tym) - pamiętaj, że BEZPIECZEŃSTWO JEST ZAWSZE KOSZTEM WYGODY
BIBLIOGRAFIA
http://www.thegeekstuff.com/2012/05/ettercap-tutorial
https://pentestmag.com/ettercap-tutorial-for-windows/
www.hacking-tutorial.com/hacking-tutorial/kali-linux-man-middle-attack
https://docs.oseems.com/general/operatingsystem/linux/sniff-network-traffic
http://kalilinuxtutorials.com/macof/
Komentarze
Dzięki.