Tunel DNS

Tunel pozwala nam na fizyczne połączenie się z zasobami naszej firmy za pomocą sieci internet.

Tunel DNS jest implementacją zwykłego tunelu, ale działa na warstwie 5 i w oparciu o aplikacje DNS, która zazwyczaj jest mało monitorowana w małych i średnich firmach.

Tunel DNS ma spore ograniczenia głównie jeśli chodzi o prędkości incoming/ outgoing. W naszym przypadku prędkość będzie miała 10/10 Kb/s. Jest to wystarczający transfer na otwarcie bramy dla hakerów. Z punktu widzenia atakującego nie jest zresztą rozsądne zapychanie łącza ofiary, gdyż może to bardzo szybko ujawnić atakujacego.

Rysunek 1: Tunel DNS pozwala na omijanie zabezpieczeń w sieci korporacyjnej.
Rysunek 2: przedstawia warstwę OSI dla normalnego tunelu 3 warstwy.
Rysunek 3: Przedstawia model OSI dla tunelu DNS.

Jeżeli ktoś chciałby sprawdzić czy jego sieć jest chroniona przed tego typu wyciekami proponuję zainstalować IODYNE https://github.com/yarrick/iodine jest aplikacją, która wykorzystuje wszystkie zalety wspomnianego protokołu DNS.

Na potrzeby testów stworzyłem maszynę Centos 7 w Azure i wpuściłem port 53.

Uwaga! Dla poprawnego działania aplikacji niezbędne jest instalacja z poziomu roota

Rysunek 4: Stworzenie maszyny Centos 7 w Azure adres lokalny 10.0.0.4
Rysunek 5: Odblokowanie portu 53 na maszynie w Azure

Instalujemy aplikację, a następnie modyfikujemy parametry uruchamiania serwera .

yum -y install iodine-server

cd /etc/sysconfig modyfikacja pliku iodine server

plik powinniśmy zmodyfikować według instrukcji

-f -c -P "hasło" adres_ip domena

Rysunek 7: Sprawdzenie poprawności działania serwisu.

Dodajemy rekord A i rekord Ns wskazujący na serwery mieszczące się w Azure.

Rysunek 8: Dodanie rekordów dns wskazujących na serwer w Azure .

Możemy zweryfikować poprawność konfiguracji klikając w poniższy link

https://code.kryo.se/iodine/check-it/

Rysunek 9:Weryfikacja działania serwisu IODYNE dla adresu ns1.rupiewicz.pl

Krótki filmik ukazujący połączenie tunelu z dystrybucji Kali Linux.

Skoro tak łatwo zestawić tunel, należałoby wspomnieć jak się przed tym chronić.

W urządzeniach klasy UTM powinna być włączona kontrola aplikacji. Mechanizmy te są wstanie zidentyfikować program i uniemożliwić mu komunikację.

Niestety sporo firm które mają tego typu urządzenia nie mają polityk związanych z kontrolą aplikacji. Nie zawsze wynika to z braku świadomości, że takowa jest potrzebna co raczej z wygody. Okazuje się bowiem, że kontrola aplikacji przysparza często nie lada kłopotów z działaniem innych aplikacji 🙂

Jest jeszcze możliwość aby naszę dns były obsługiwane przez cloudflare

https://www.cloudflare.com/learning/dns/dns-security/

Rysunek 9: Połączenie z tunelem w logach urządzenia brzegowego bez włączone kontroli aplikacji Fortigate.
Rysunek 10: Połączenie z tunelem w logach urządzenia brzegowego z włączoną kontrolą aplikacji Fortigate.

Wiele firm funkcjonuje bez urządzeń tego typu. Zaleca się by skorzystali ze snort https://www.snort.org/ lub wiresharka parę zrzutów da informacje czy faktycznie macie do czynienie z tunelem DNS.

Rysunek 11:Tak wyglądają standardowe zapytania w dns.

Rysunek 12:Wysyłanie danych tunelem DNS
Rysunek 13:Zestawienie połączenia tunelu DNS.

Mała uwaga! Chcąc sprawić aby tunel zadziałał na windows 10 należy zainstalować sterownik tap https://openvpn.net/community-downloads/ hasło od dawna nie działa 🙂 .

Rysunek 14: Połączenie z tunelem za pomocą konsoli CMD w systemie Windows.
Rysunek 15: Logi dns na urządzeniu UTM Fortigate.

Niniejszy artykuł ma na celu zwiększenie świadomości czytelników na temat realnego zagrożenia jakim jest wyciek danych w protokole DNS.

autor: Tomasz Rupiewicz

Żródła:

Comments are closed.