Obcy – drugi serwer DHCP w sieci

Po świątecznej hibernacji (wreszcie można było się porządnie wyspać) tempo nieco wolniejsze. Większość użytkowników na urlopach korzysta z dobrodziejstw „długich weekendów” (jeszcze z hibernacji się nie wybudzili), więc współczynnik awarii i zgłoszeń na zaskakująco niskim poziomie. Można wreszcie zająć się wszystkimi odkładanymi na lepsze czasy zadaniami. Wtem sączący się z głośników cichy gitarowy riff zagłusza dzwoniący intercom telefon. „Nie mogę się zalogować”, no cóż, zdarza się. Tym razem restart nie rozwiązuje problemu, a komputer nie jest widoczny w sieci, ponadto pojawiło się kilka innych zgłoszeń. Niestety trzeba wdziać kombinezon w postaci geek’owej aury i ruszyć na spotkanie pierwszego stopnia z Użytkownikiem i jego maszyną. Na miejscu okazuje się, że komputer jest poprawnie podpięty do sieci, ale … domyślna brama i serwer DHCP na pewno z naszej sieci nie pochodzą. Jest niemal pewne, że w trzewiach naszej infrastruktury zalągł się Obcy. Musimy działać szybko aby nie doszło do eskalacji problemu. (… bo potem tylko wyssanie w próżnię pozostaje)

 

Diagnozowanie

Działanie serwer DHCP opiera się na rozgłaszaniu pakietów. Jeżeli podłączany do sieci komputer skonfigurowany jest do automatycznego pobierania adresów to pierwsze co robi to wysyła broadcast z zapytaniem „kto jest serwerem DHCP?”, serwer odpowiada podając swoje dane, rozpoczyna się komunikacja, a komputer dostaje adres z odpowiedniej sieci oraz inne dane w zależności konfiguracji. Jeżeli w tej samej sieci znajduje się drugi serwer DHCP to akceptowany przez hosty jest ten, którego odpowiedź dotrze szybciej.
Mamy kilka metod aby potwierdzić postawioną w powyższej historii diagnozę:
bezpośrednio – odnajdujemy IP potencjalnego serwera DHCP. Na komputerach możemy to najszybciej sprawdzić używając komendy ipconfig /all podany jest tam adres IP serwera. Próbujemy podłączyć się do tego adresu poprzez http bądź https, jeżeli to nie pomoże to telnet lub SSH. Nieautoryzowany serwer DHCP może pochodzić z jakiegoś domowego router’ka, którego podłączył użyszkodnik. Jeżeli wyświetli nam się okienko logowania któregoś ze znanych producentów takiego sprzętu to diagnozę mamy za sobą.
węszenie – poprzednia metoda może niestety nie być skuteczna, szczególnie w przypadku świadomego uruchomienia serwera DHCP – atak Man in the middle. Najbardziej miarodajne i jednoznaczne jest odsłuchanie krążących po sieci pakietów DHCP. Użyć można jakiegokolwiek sniffera np. Wireshark’a. Jeżeli zauważymy pakiety DHCP pochodzące z innego serwera niż posiadamy to pochodzą one z pewnością od intruza.
programowo – można użyć dostępnych w sieci programów wykrywających nieautoryzowane serwery. Najmniejszy jaki znalazłem to RogueChecker pochodzący z bloga Microsoftowego zespołu DHCP. Tu już nie trzeba dużo tłumaczyć: odpalamy, skanujemy, dostajemy listę serwerów DHCP dla sieci. Proste i skuteczne. Warto wgrać go sobie na pendrive’a do zadań specjalnych (posiadacie takiego. prawda?)

 

Unicestwianie

Włączamy tryb search&destroy podnoszący adrenalinę u każdego szanującego się geeka ;). Najważniejsze co musimy zrobić na początku to odnaleźć adres MAC intruza. Jak zwykle mamy kilka opcji, które będą wynikały głównie z wybranej wcześniej metody diagnozy. Jeżeli przeprowadzaliśmy ją bezpośrednio z komputera to skorzystać można z wpisów w tablicy ARP, wcześniej pingując nieproszony serwer – arp -a. Jeżeli używaliśmy dodatkowego softu to MAC powinien być wyświetlony obok znalezionych serwerów. Jeżeli węszyliśmy – MAC dostępny będzie w polu „source” przechwyconych pakietów. Kolejnym krokiem jest namierzenie intruza, a możemy tego dokonać po prostu za pomocą komend IOS lub, jeżeli takowy posiadamy, za pomocą aplikacji monitorujących sieć (IPAM). Wtedy wystarczy zablokować port aby odciąć od sieci DHCP’a. Później fizycznie lokalizujemy Obcego, wrzucamy to wrzącego metalu, spalamy lub zamrażamy ciekłym tlenem i roztrzaskujemy.

 

Profilaktyka

Mądry administrator (po szkodzie) powinien od razu zabrać się za uszczelnienie infrastruktury, którą zarządza. Jeżeli sieć podzieloną mamy na vlany (oddzielne domeny rozgłoszeniowe) to nieproszony serwer DHCP ma mniejszą siłę rażenia. Najważniejsze maszyny, inne serwery i urządzenia powinny mieć ustawiony statyczny adres IP. Mądrzejsze systemy IPAM posiadają funkcje wykrywanie obcych urządzeń więc warto się w takowy zaopatrzyć. Jednak najbardziej skutecznym rozwiązaniem, będzie zablokowanie problemu już w drugiej warstwie (model OSI). Wykorzystamy do tego technikę DHCP Snooping, jest bardzo prosta i polega na odrzucaniu wszelkich pakietów DHCP, które nie pochodzą z zaufanego interfejsu. Używając na switchu komendy

Switch(config)# ip dhcp snooping

blokujemy wszystkie pakiety DHCP, które są w jego obrębie wysyłane. Blokowane będą również te z autentycznego serwera DHCP, aby temu zapobiec dodajemy linię konfiguracji do interfejsu z którego docierać będą pakiety DHCP (na switchach warstwy „Access” będą to zazwyczaj trunki)

Switch(config-if)# ip dhcp snooping trust

Jeżeli mamy specyficzne potrzeby możemy sprecycować zakres vlanów podlegającego snoopingowi

Switch(config)# ip dhcp snooping vlan [zakres]

DHCP snooping ma dużą moc, więc dobrze przemyślcie wdrożenie tego rozwiązania w swojej sieci, czasem można popsuć więcej niż niejeden intruz. Po akcji jednak możecie wrócić w sielankowym nastroju do swojej „nudnej” pracy w przekonaniu, że sieć pilnuje się sama (… do czasu kolejnej awarii nie-do-przewidzenia ;))

Przeczytaj także...

1 Response

  1. Arek napisał(a):

    Warto jeszcze dodać ochronę portów przed nieznanymi urządzeniami. Np. na switchach Cisco można zrobić tak, by port automatycznie się wyłączał. Przydatny jest jeszcze system monitoringu. Np. Zabbix, o którym piszę na swoim blogu. W przypadku wystąpienia problemu to system monitoringu powinien nas powiadomić zanim zrobi to „użyszkodnik”. 🙂

Dodaj komentarz