W dzisiejszych czasach w większości przypadków kiedy chcemy skorzystać z zasobów internetu wystarczy podłączyć nasz komputer do gniazdka sieciowego lub podpiąć się do sieci bezprzewodowej. Nie ma tu znaczenia czy chcemy sprawdzić pocztę, posłuchać muzyki ze spotify czy obejrzeć film na Netflixie.
Cała konfiguracja naszego NIC’a (Network Interface Card) czyli karty sieciowej dzieje się poza naszą wiedzą. Zawdzięczamy to takiej usłudze jak DHCP Dynamic Host Configuration Protocol.
DHCP – DYNAMIC HOST CONFIGURATION PROTOCOL
Obecnym standardem sieciowym jest protokół IP który wymaga, aby każdy host posiadał unikalny w skali internetu adres IP oraz maskę podsieci ( oczywiście upraszczając i nie biorąc pod uwagę NAT). Kiedy mamy już te dwa elementy potrzebujemy jeszcze adresu urządzenia, najczęściej routera lub switcha L3 który będzie robił za naszą bramę domyślną. Dla użytkownika końcowego ważne również by było, aby miał adres jakiegoś serwera DNS który pozwoli na zamianę nazw domen na adresy IP.
W najprostszej wersji potrzebujemy otrzymać następujące informacje od naszego serwera DHCP:
- Unikalny adres IP
- Maskę podsieci
- Adres bramy domyślnej
- Adres serwera DNS
DORA, DORA, DORA
Kiedy musimy skonfigurować jedną kartą sieciową lub tylko kilka interfejsów niestanowi to problemu i możemy zrobić to ręcznie. Logujemy się do urządzenia i wpisujemy wszystkie komendy po kolei. I jak zawsze ma tu znaczenie efekt skali oraz wygody, jakie dane rozwiązanie oferuje, a ręczna konfiguracja w dużej skali nie jest ani wygodna, ani szybka. Nie wspominając o konieczności pilnowania, wykorzystania puli adresów w podsieciach.
Jeśli nie z manualnej konfiguracji, to skąd nasz NIC ma wiedzieć jakiego adresu IP, maski podsieci oraz adresu bramy domyślnej ma używać?
Z pomocą przychodzi nam zestaw wiadomości, jakie wymieniają między sobą klient oraz serwer DHCP. Branżowo nazywa się te komunikaty DORA, co bierze się z pierwszych liter nazw tych wiadomości:
- Discovery – wysyłane przez klienta
- Offer – wysyłane przez serwer DHCP
- Request – wysyłane przez klienta
- Acknowledgement – wysyłane przez serwer DHCP
Na poniższym obrazku możesz, zobaczyć jak to wygląda w sposób graficzny.
Prześledźmy ten proces jeszcze raz od początku. Kiedy interfejs sieciowy włącza się do sieci, w pierwszej kolejności sprawdza, czy posiada skonfigurowane odpowiednie parametry do pracy.
- Klient wysyła wiadomość DHCP Discovery jako broadcast, czyli do wszystkich dostępnych odbiorców danym segmencie sieci, aby odnaleźć serwer DHCP.
- Serwer DHCP odpowiada, wysyłając DHCP Offer wraz z ofertą adresu IP jako wiadomość typu unicast, tylko do nadawcy.
- Następnie klient odpowiada, wysyłając DHCP Request ponownie wiadomością typu broadcast, że akceptuje adres i będzie pod nim osiągalny.
- Serwer DHCP wysyła DHCP Acknowledgement jako potwierdzenie przydzielenia adresu oraz dzierżawy dla klienta jako wiadomość typu unicast.
Dzierżawa i odnowa adresu IP
O co chodzi z tą dzierżawą? Otóż każdy serwer DHCP ma z góry określoną pulę adresów, które może wykorzystać. Na przykład mając podsieć składającą się z 14 użytecznych adresów, chcielibyśmy zarezerwować pierwsze 3 adresy dla naszego routera, serwera plików i drukarki. W takim wypadku serwer DHCP może rozdać adresy od 4 do 14.
Teraz wyobraź sobie, że jesteś w biurze, które zatrudnia 20 osób, ale pracują oni na 2 zmiany. Każdy z pracowników ma swojego laptopa, z którego korzysta w pracy. I teraz w momencie gdy Karol przychodzi rano do pracy, dostaje adres 192.168.0.4, to serwer DHCP zapisuje w swoim rejestrze, że ten adres należy do Karola na przykład na 1 godzinę.
Karol spędził w pracy 8 godzin, posługując się otrzymanym adresem, ale na koniec pracy wyłączył laptopa i zabrał go do domu.
Standardowo serwer DHCP stara się potwierdzić ważność dzierżawy w połowie okresu jej trwania. Jeśli nie otrzyma potwierdzenia, że chcemy taki adres nadal używać, dany adres wróci do puli dostępnych adresów.
Z tego faktu może skorzystać na przykład Adam, który przychodzi do pracy wieczorem i również otrzymuje adres 192.168.0.4. Tak długo jak dzierżawa będzie odnawiana, ten adres będzie należał do Adama, nawet jeśli Karol przyjdzie do pracy, zanim Adam skończy swoją zmianę.
Pozostałe pakiety DHCP
Oprócz pakietów wykorzystywanych w procesie DORA klient oraz serwer DHCP mogą wymieniać dodatkowe pakiety:
- DHCPNAK -Pakiet wysyłany przez serwer do klienta, z informacją, że jego adres IP jest nieprawidłowy lub wygasła dzierżawa
- DHCPDECLINE – Pakiet wysyłany przez klienta do serwera z informacją, że adres jest w użyciu.
- DHCPRELEASE -Pakiet wysyłany przez klienta do serwera z informacją, że adres zostaje zwolniony.
- DHCPINFORM – Pakiet wysyłany przez klienta do serwera z prośbą o przesłanie wyłącznie informacji o konfiguracji sieci, klient ma już zewnętrznie przypisany adres IP.
Parametry przekazywane przez DHCP
Jak już wcześniej wspomnieliśmy, serwer DHCP może dostarczyć nam adres IP, maskę podsieci, adres bramy domyślnej oraz adres serwera DNS. Jednak zdefiniowany w RFC 1533 standard pozwala na przekazanie o wiele większej ilości danych.
Do pozostałych opcji, które możemy, otrzymać z takiego serwera należy między innymi:
- adres serwera TFTP
- maksymalny rozmiar MTU
- adres serwera SMTP
- adres serwera NTP
- Statyczne trasy routingu
Specyficzne opcje DHCP są również wykorzystywane przez Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP.
IP Helper
Do tej pory omówiliśmy przypadek kiedy nasz klient DHCP oraz serwer DHCP są w tej samej sieci lokalnej. Zwykle taka sytuacja ma miejsce w domu lub w małym biurze gdzie router brzegowy świadczy również usługę DHCP.
Duże organizacje oraz ISP preferują posiadanie serwera lub nawet serwerów DHCP w jednym scentralizowanym punkcie zamiast setek, lub tysięcy rozproszonych po wszystkich lokalizacjach. Znacząco to uprasza zarządzanie posiadanymi pulami adresów oraz pozwala wykorzystywać je w sposób efektywny.
Stajemy więc przed problemem, jak nasz pakiet typu broadcast przekazać do serwera poprzez internet i gdzie w ogóle taki pakiet wysłać. Z pomocą przychodzi DHCP relay, który Cisco nazywa IP helper.
IP helper definiujemy na interfejsie skierowanym w stronę danej sieci lokalnej lub pod interfejsem SVI. Jest to adres serwera DHCP. Dodatkowo IP helper służy jako przekaźnik (relay), przekształcając pakiety typu broadcast wysłane przez klienta w pakiety unicast do serwera docelowego.
Router(config-if)#ip address 192.168.0.1 255.255.255.0 Router(config-if)#ip helper-address 192.168.1.2
Ataki na usługę DHCP
Usługa DHCP jak każda inna może zostać wykorzystana zarówno do ułatwienia nam życia jak również do złych celów.
- Starvation (wysycenie) – Atak polega na wysyceniu puli adresów, poprzez wysyłanie podrobionych adresów MAC z jednego hosta do serwera DHCP. W takim wypadku nasz serwer odpowiada adresem IP dla każdej wiadomości z żądaniem (DHCP Discovery).
Formą obrony przed takimi atakami jest DHCP snooping binding. Przechowuje w pamięci switcha informację, że na konkretnym interfejsie klient otrzymał już adres IP (właściwie to zapisuje parę MAC-IP oraz czas dzierżawy). W takim wypadku żaden nowy pakiet DHCP discovery nie zostanie przekazy dalej do końca czasu dzierżawy.
- Podstawiony serwer DHCP – Atak polega na ustawieniu w sieci drugiego serwera DHCP, który będzie odpowiadał na żądania od klientów, wysyłając podstawione dane. W takim wypadku klient DHCP może otrzymać adres bramy domyślnej lub adres serwera DNS kontrolowanego przez osobę nieupoważnioną.
Do obrony przed takimi atakami służy pojęcie zaufanych interfejsów (skąd mogą przyjść odpowiedzi od serwera DHCP) oraz niezaufanych (skąd odpowiedzi nie powinny przyjść, ale takie interfejsy nadal mogą wysyłać pakiety od strony klienta). Interfejsem zaufanym będzie napewno port, gdzie jest podpięty serwer DHCP oraz trunki, z których oczekujemy nadejścia pakietów DHCP. Do niezaufanych z zasady należą wszystkie pozostałe, na których nie spodziewamy się odpowiedzi serwera.
Konfiguracja DHCP na routerze Cisco
Konfiguracja DHCP na routerze Cisco jest stosunkowo prosta. W pierwszej kolejności musimy utworzyć i nazwać pulę, z której nasz serwer DHCP korzystał. Następnie musimy przypisać konkretną sieć do naszej puli. W kolejnym kroku definiujemy adres bramy domyślnej oraz opcjonalnie adres serwera DNS.
Router(config)#ip dhcp pool BIURO Router(dhcp-config)#network 192.168.0.0 255.255.255.0 Router(dhcp-config)#default-router 192.168.0.1
Warto by również przeznaczyć część adresów z danej puli do adresacji statycznej. Robimy to za pomocą polecenia wykluczającego dany zakres z adresów rozdawanych przez DHCP.
Router(config)#ip dhcp excluded-address 192.168.0.1 192.168.0.10
O czym warto pamiętać, że nasz serwer będzie rozdawał adresy IP z puli zgodnej z adresem interfejsu, na którym otrzymał pakiet DHCP Discovery lub zgodnej z adresem źródłowym jeśli wykorzystany był IP Helper.
Weryfikacja usługi DHCP na routerze Cisco
Do weryfikacji czy nasza usługa DHCP, którą skonfigurowaliśmy, posłużą nam następujące komendy:
show ip dhcp binding – Wyświetla listę wszystkich wykorzystanych adresów IP i ich przypisania do klientów.
Router#show ip dhcp binding IP address Client-ID/ Lease expiration Type Hardware address 192.168.0.2 0003.E477.CDE8 -- Automatic
show ip dhcp pool <nazwa_puli> – Wyświetla listę skonfigurowanych podsieci plus statystyki ich wykorzystania.
Router#show ip dhcp pool OFFICE Pool OFFICE : Utilization mark (high/low) : 100 / 0 Subnet size (first/next) : 0 / 0 Total addresses : 254 Leased addresses : 1 Excluded addresses : 0 Pending event : none 1 subnet is currently in the pool Current index IP address range Leased/Excluded/Total 192.168.0.1 192.168.0.1 - 192.168.0.254 1 / 0 / 254
APIPA – Automatic Private Ip Addresseing
Każdy interfejs sieciowy do komunikacji w warstwie 3 potrzebuje adresu IP. Co jednak w sytuacji gdy nie został on skonfigurowany oraz nie mamy dostępu do serwera DHCP? W takim wypadku wkracza APIPA, czyli Automatic Private IP Addressing i przydziela adres IPv4 z puli 169.254.0.1 – 169.254.255.254, z domyślną maską 255.255.0.0. Ten zakres adresów jest zarezerwowany przez IANA do celów automatycznej adresacji sieci lokalnych (LAN). W teorii adres przydzielony przez APIPA powinien zostać zastąpiony adresem otrzymanym z serwera DHCP kiedy pojawi się on ponownie w sieci.
0 komentarzy