Fałszowanie DNSu

10 stycznia, 2013 (16:01) | windows | By: konrad

Tym razem będzie opis przypadku konretnego Klienta, ale sama konfiguracja może się przydać do wielu ciekawych rzeczy.

Wyobraźmy sobie firmę z prostą instalacją Active Directory składającą się z kontrolera domeny, serwera plików, serwera SQL oraz serwera web (IIS). Wszystko to szczelnie „zamknięte” w sieci lokalnej z adresacją 192.168.1.0/24. Kontakt ze światem to dowolne łącze z jednym publicznym adresem IP i router typu „SOHO”, który potrafi zrobić NAT (co stanowi podstawową metodę dostępu do Internetu dla maszyn w sieci lokalnej) i… niewiele więcej. Za obsługę poczty, firmowej strony WWW i DNSów dla domeny odpowiadają serwery gdzieś w świecie.

W pewnym momencie na serwerze IIS został zainstalowany serwis, do którego dostęp mają mieć użytkownicy mobilni (czyli tacy, którzy mają laptopa i są czasami w siedzibie firmy, a czasami trochę dalej). I ci użytkownicy mają na swoich stacjach zainstalowany program, który łączy się ze wspomnianym serwisem. Niby nic prostszego, bo wystarczy wystawić port tcp/443 na zewnątrz za pomocą prostego przekierowania i wszystko śmiga aż miło. Ale nasi bohaterowie nie bardzo chcą zmieniać konfiguracji swojego programu za każdym razem, kiedy wychodzą z firmy, albo do niej wracają. A router jest na tyle „prosty”, że nie radzi sobie zbyt dobrze z połączeniami inicjowanymi z sieci lokalnej na zewnętrzny adres IP, który jest „zawinięty” do serwera w tejże sieci lokalnej (robi się podwójny NAT, który przerasta urządzenie sieciowe). Pojawia się więc drobny problem…

Na szczęście nasz magiczny program można skonfigurować tak, aby korzystał z nazwy domenowej, a nie adresu IP. Tylko jak w łatwy i elegancki sposób zrobić tak, żeby – w zależności od fizycznej lokalizacji laptopa – ta sama nazwa domenowa (nazwijmy ją app.firma.pl) była rozwiązywana na różne adresy IP? Zacznijmy od rzeczy prostych i oczywistych. Na pewno na serwerach DNS odpowiadających za domenę firma.pl musimy zdefiniować rekord A (albo AAAA dla IPv6) określający, że app.firma.pl znajduje się pod publicznym adresem IP przypisanym do Klienta. Drugą rzeczą jest (wspomniane już przeze mnie) przekierowanie portu tcp/443 serwera z IISem (niech będzie to 192.168.1.100) na routerze tak, aby był osiągalny z zewnątrz. Pozostaje jeszcze skonfigurować aplikacje na laptopach tak, żeby korzystał z nazwy domenowej, a nie adresu IP. Dzięki powyższym modyfikacjom wszyscy użytkownicy znajdujący się poza murami firmy powinni mieć dostęp do swoich danych. Ale co dalej?

Można na serwerach DNS domeny AD dodać strefę firma.pl, a w niej rekord „app.firma.pl. A 192.168.1.100„. Owszem, będzie działać, ale stracimy możliwość rozwiązywania innych nazw z domeny firma.pl (z wewnątrz sieci nie zadziała np. www.firma.pl), bo AD stanie się autorytatywne dla zdefiniowanej właśnie strefy. Niby można zdublować wszystkie wpisy z DNSów „publicznych”, jednak nie jest to dobry pomysł, bo trzeba będzie pilnować spójności tych dwóch systemów, co jeszcze szczególnie trudne w przypadku, gdzie zewnętrznymi zarządza ktoś inny. Poza tym jest to nieeleganckie :-)

Rozwiązanie okazuje się wyjątkowo proste. Okazuje się, że na serwerach DNS Active Directory można utworzyć nową strefę app.firma.pl, a w niej zdefiniować jeden rekord typu A z pustą nazwą (wtedy będzie się odnosił do nazwy strefy). Taka konfiguracja skutkuje kilkoma rzeczami. Po pierwsze – udało się spełnić założenie, bo adres app.firma.pl rozwiązywany jest na zewnątrz dzięki „publicznym” DNSow, a w siedzibie firmy dzięki DNSom skojarzonym z Active Directory. Po drugie – nie muszę pamiętać o synchronizacji strefy na dwóch, niezależnych systemach. A po trzecie – rozwiązanie jest proste, eleganckie i przejrzyste, więc nie trzeba tworzyć rozbudowanej dokumentacji i trenować pamięci, żeby się w tym później połapać.

Trackback URL: https://konrad.bechler.pl/2013/01/falszowanie-dnsu/trackback/

«

»

Comments

Comment from rozie
Time 11 stycznia 2013 at 20:03

Wydaje mi się, że lepszym rozwiązaniem będzie ustawienie na routerze adresu serwera DNS, który będzie realizowany przez maszynkę w sieci lokalnej (zakładam DHCP w sieci i pobieranie informacji o serwerach DNS za jego pośrednictwem). Na tej maszynce stawiamy cache’ujące proxy DNS, np. dnsmasq (więcej o dnsmasq w tym wpisie http://rozie.blox.pl/2011/01/Dnsmasq-DHCP-i-DNS-dla-malych-i-srednich-sieci-i.html ) i dalej już z górki – opcja address w dnsmasq pozwoli na resolvowanie zapytań z sieci lokalnej na adres lokalny. Z zewnątrz działa bez zmian. Oczywiście stawianie proxy DNS tylko w tym celu to overkill, ale lokalne proxy DNS w firmie ma więcej zalet, z przyspieszeniem ładowania stron na czele.

Comment from konrad
Time 11 stycznia 2013 at 23:16

No nie, to byłby zdecydowany overkill, bo sieć jest homogeniczna, a dnsmasq for windows nie widziałem. Poza tym domena windowsowa wymaga, aby końcówki korzystały z serwerów skojarzonych z AD, inaczej dzieją się nieciekawe rzeczy. Oczywiście to też da się zmienić, tylko… po co?

Comment from rozie
Time 12 stycznia 2013 at 09:51

Huh, homogeniczna sieć? Istnieją takie jeszcze? :-) Wydawało mi się, że teraz to zawsze się trafia ktoś z Linuksem/Androidem/mac OS…

Comment from konrad
Time 12 stycznia 2013 at 13:55

Ano istnieją i mają się całkiem nieźle. Ale żeby być dokładnym, w tym wypadku homogeniczna ze względu na część serwerową. Jest w firmie kilka urządzeń z logiem nagryzionego jabłka, ale istalowanie serwer DNS na stacji roboczej prezesa nie wydaje mi się szczególnie dobym pomysłem :-)

Write a comment





*