Rogue DHCP Server – czyli problem z nieautoryzowanym serwerem DHCP

Początki

W sieciach ISP opartych o technologie ethernetowe możemy klientów podłączać na kilka różnych sposobów i w różny sposób ich autoryzować. Wracając pamięcią do dawnych czasów kiedy sieci lokalne opierały się jeszcze na koncentratory/huby i kable koncentryczne a sam Internet nie był jeszcze tak bardzo popularny – adresowanie komputerów w sieci odbywało się często ręcznie w oparciu o jakiś prefiks z puli tzw. prywatnych (10.0.0.0/8. 192.168.0.0/16 172.16.0.0/12) i dodaniu mu odpowiedniej końcówki z pamięci. Jeśli sieć była niewielka – powiedzmy była to sieć dla paru sąsiadów to przypisanie adresów „z palca” nie stanowiło wielkiego problemu.

W przypadku kiedy użytkowników przybywa ogarnięcie „ręcznego” wklepywania odpowiedniej konfiguracji bywa kłopotliwe – bo o pomyłkę nie trudno a źle wpisany adres IP (pomylony adres IP z adresem bramki) może skutecznie wysadzić naszą sieć w powietrze (mówimy tu o siedzi płaskiej – w której nie ma segmentów oddzielonych routerami). Aby nie męczyć się z ręcznym klepaniem ustawień wymyślono coś takiego co nazywa się DHCP.

Czym jest DHCP i z czym to się je?

DHCP (Dynamic Host Configuration Protocol) jest jednym z kilku rozwiązań (poza m.in. RARP i BOOTP) pozwalających na automatyczną konfigurację protokołu IPv4 bez potrzeby ręcznego pamiętania ustawień IP dla dowolnego urządzenia obsługującego oczywiście ten protokół. Z uwagi, że DHCP nie jest żadną nowością i zasadniczo znakomita większość dostępnych urządzeń jaki i systemów operacyjnych obsługuje ten protokół – użycie tego rozwiązania jest niemal oczywiste.

Protokół DHCP opiera się o tradycyjną architekturę klient-serwer. Serwer DHCP zajmuje się przechowywaniem całej konfiguracji oraz rejestruje tzw. „dzierżawy” adresów IP oraz konfigurację poszczególnych urządzeń w sieci, które zgłaszają się do niego z poszczególnymi zapytaniami. Klient DHCP więc wysyła do sieci (za pomocą broadcastu) zapytanie o możliwość przydzielenia adresu IP i jeśli w sieci znajduje się odpowiedni serwer DHCP otrzymuje on ofertę „dzierżawy” danego adresu IP lub też odmowę jeśli np. serwer nie posiada w swojej konfiguracji danego urządzenia. Oczywiście cała procedura jest troszkę bardziej skomplikowana (szczegóły polecam wyczytać na Wikipedii).

DHCP prócz konfiguracji samego protokołu IPv4 potrafi również przekazywać dodatkowe informacje konfiguracyjne m.in. adresy serwerów DNS/WINS, alternatywne bramy domyślne, nazwy domeny, konfigurację uruchomienia systemu poprzez sieć (zastępuje BOOTP) itd.

Konfiguracja serwera DHCP sprowadza się w zasadzie do określenia przestrzeni adresowej IP (tzw. DHCP Pool) jaką serwer DHCP ma rozdysponować dla klientów oraz na jak długo adres IP ma być przypisany dla ewentualnego klienta (lease time – czas dzierżawy). W znakomitej większości routerów domowych serwer DHCP jest domyślnie włączony – więc wpinając kabelek lub łącząc się z nim bezprzewodowo – otrzymamy wolny adres IP (który zwykle jest przydzielany dynamicznie i także losowo). Oczywiście losowe przypisywanie adresu IP jest nie zawsze pożądaną cechą – dlatego zwykle serwery DHCP pozwalają na ustawienie tzw. statycznej dzierżawy w oparciu o adres MAC urządzenia. Pozwala to na stałe przypisanie adresu IP dla określonego urządzenia bez jego ręcznej konfiguracji – jest to więc najprostszy sposób na wprowadzenie ładu i porządku w naszej sieci. Dzięki DHCP użytkownik nie musi więc pamiętać o ręcznej konfiguracji IP – wystarczy, że my posiadamy odpowiednie wpisy w naszym serwerze.

O korzyściach jakie daje nam takie rozwiązanie nie trzeba nawet wspominać – w razie jakiejkolwiek zmiany (np. serwera DNS) nie musimy każdorazowo biegać po użytkownikach naszej sieci i zmieniać jakichkolwiek ustawień. Poza tym w prosty sposób możemy autoryzować naszych użytkowników – jeśli ktoś dopnie się do sieci – a nie będzie dopisany wcześniej do systemu – jego komputer oczywiście nie pobierze ustawień a tym samym nie skorzysta z zasobów np. Internetu (pomijam, że złamanie tego zabezpieczenia nawet dla dziecka z podstawówki to żaden problem).

No więc jaki jest problem z DHCP ?

Nasza sieć rozrasta się a tym samym ilość użytkowników się zwiększa. A z ludźmi jak to z ludźmi – nie każdy jest tak bardzo obyty lub tym bardziej zna podstawy działania tego do czego jest podłączony. Dodatkowo dochodzi naturalna skłonność do „kombinowania” a już nie daj boże do poprawiania tego co zrobił administrator sieci lub instalator.  Jeśli nasza sieć opiera się więc w większości na zwykłej skrętce (pomijam PON czy sieci WIFI) to prędzej czy później zdarzy się nam, że któryś z użytkowników wepnie kabelek nie tam gdzie trzeba  – szczególnie kiedy w dobie routerów z WIFI każdy chce mieć Internet w każdym domowym urządzeniu. O ile pojedynczemu użytkownikowi Internet może nie działać – to zamienienie interfejsu LAN z WANem może spowodować nie lada problem dla większej grupy użytkowników – szczególnie, że popularne „domowe routerki” również serwer DHCP posiadają.

Dwa serwery DHCP w jednym segmencie to za dużo

Jeśli klientów dopinamy do sieci za pomocą prostych (niezarządzalnych) przełączników to zasadniczo nie mamy możliwości większej obrony w przypadku takiego nieumyślnego lub umyślnego działania użytkownika. W przypadku znakomitej większości zarządzalnych przełączników istnieje co najmniej kilka sposobów na „obronę”. Podstawową ochroną naszej sieci jest przypisanie adresu MAC do konkretnego portu. Jeśli użytkownik zamieni WAN z LANem a  najczęściej LAN ma inny adres MAC – switch nie pozwoli na transmisję danych lub po prostu wyłączy port. Istnieje również możliwość skorzystania z bardziej wyrafinowanego zabezpieczenia jakim jest dhcp-snooping – który pozwala na wskazanie na którym porcie w przełączniku osiągalny jest serwer DHCP. W przypadku kiedy serwer DHCP pojawi się na innym porcie niż zdefiniowany – ruch z takiego serwera lub portu zostanie zablokowany. Co więc możemy zrobić jeśli nie posiadamy zarządzalnego przełącznika?

Problem staje się bardziej poważny zważywszy, że wpięty „odwrotnie” router może rozłożyć nam sieć lub przynajmniej segment do najbliższego routera. (Warto zaznaczyć, że DHCP działa w domenie broadcastowej, więc nie przechodzi przez routery – no chyba, że ktoś wstawi DHCP Relay’a). Co więc poradzić w takim wypadku? Rozwiązania są zasadniczo dwa :

  • Uruchomić w sieci dostęp poprzez protokół PPPoE
  • Wyciąć niechciany ruch na mostach lub switchach wyżej

O ile pierwsza metoda jest dość ciekawa – bo zasadniczo zabezpiecza nas przed podobnymi sytuacjami – o tyle wdrożenie PPPoE w sieci z dużą ilością klientów może rodzić wiele problemów przy czym najważniejszy jest nakład czasowy oraz jeśli to będzie wymagane również koszta materialne (trzeba uruchomić koncentrator PPPoE).

Metoda druga jest zwykle dostępna wszędzie tam, gdzie znajdziemy urządzenia które potrafią filtrować nam ruch IPv4 – czyli wszelkiego rodzaju mosty bezprzewodowe (Mikrotik, Ubiquiti) oraz switche agregacyjne – czyli te zarządzalne ;D

Jak i co filtrować?

Usługa DHCP ma to do siebie, że serwer DHCP rozgłasza swoje oferty odnośnie dzierżawy adresu IP na porcie UDP o numerze 67. Komunikacja od strony klientów odbywa się na porcie o numer wyższym czyli 68. Blokując więc ruch UDP na porcie 67 od strony gdzie znajdują się urządzenia klientów możemy skutecznie zablokować rozgłoszenia zdublowanego serwera DHCP a tym samym ograniczyć „psucie sieci”.

Wystarczy użyć odpowiedniej regułki w ebtables dla Linuxa :

ebtables -p IPv4 -i eth0 –ip-proto udp –ip-sport 67 -j DROP

Należy pamiętać, że gdzie -i eth0 należy wpisać odpowiedni interfejs pod którym znajdują się klienci. W przypadku kiedy się pomylimy zablokujemy właściwy serwer DHCP.

W przypadku Mikrotik’a stosowną regułkę wprowadzamy w Bridge / Filter :

/interface bridge filter
add action=drop chain=forward comment=”” disabled=no in-interface=ether1 \
ip-protocol=udp mac-protocol=ip src-address=0.0.0.0/0 src-port=67

 

Dla sprzętu UBNT sytuacja jest niemal identyczna. W zakładce Networks musimy tylko zaznaczyć „dziubek” Firewall i wprowadzić regułę DROP na interfejs eth0 i wpisać dla źródła port 67 UDP.

Który klient nabruździł i co z nim zrobić dalej ?

Jeśli „odwrócony router” zdążył już nam trochę namieszać to naprawienie sytuacji u pozostałych użytkowników sprowadza się zwykle do zrestartowania urządzenia końcowego. Dlatego warto posiadać dostęp do końcówek klienckich – dzięki czemu możemy zrobić to zdalnie.

Namierzenie delikwenta który podpiął nam odwrotnie router sprowadza się zwykle do przeanalizowania pakietów w których znajduje się oferta dzierżawy adres IP. Adres MAC źródła wskaże nam urządzenie które „rozsyła” trefne informacje. Jak już wspomniałem adres MAC dla interfejsu LAN i WAN różni się –  jest to zwykle ostatnia cyfra w adresie MAC. Stąd mając listę adresów MAC które są w naszej sieci – łatwo odnaleźć podobny adres – no chyba, że klient „sklonował” sobie adres MAC WANu to wtedy może być to nie lada problem. Jeśli znamy już adres MAC oraz znamy adresy i konfigurację jaką przypisał nam nieautoryzowany serwer DHCP możemy spróbować zablokować jego działanie.

O ile mamy dostęp do danego segmentu sieci możemy wysycić go bzdurnymi dzierżawami za pomocą odpowiedniego narzędzia lub… zalogować się do „nieszczęsnego” routera i zdalne wyłączyć serwera DHCP – pod warunkiem, że znamy do tego routera hasło i uda nam się uzyskać do niego dostęp – co w przypadku „odwrócenia” routera wymaga przypisania na stałe adresu MAC z adresem IP za pomocą komendy:

arp -s adres_ip adres_mac

Czym się posługiwać ?

W przypadku takich sytuacji idealnie sprawdza się potężne i popularne narzędzie o nazwie Wireshark który dostępne jest zarówno pod Linuxa i Windows. Zresztą jest to kompletny sniffujący kombajn pozwalający na analizę niemalże każdego elementu stosu sieciowego. Drugą wartą polecenie aplikacją jest THCRUT – niewielki programik dostępny pod Linuxa i FreeBSD potrafiący „zalewać” serwer DHCP zapytaniami.

Podsumowując

Morał z tej historii taki – kupujcie zarządzalne switche z możliwością filtracji na warstwie 3 i z autoryzacją MAC na poszczególnych portach. Najlepiej wyposażone dodatkowo w dhcp-snooping. Wtedy odwrotne wpinanie routera nie jest nam straszne. W przeciwnym wypadku musimy albo wdrażać PPPoE lub … trochę się pomęczyć.

Dodaj komentarz