Wdrożenie Technitium DNS - własna kontrola nad reklamami i malware w całej sieci domowej
W środowisku IT bardzo popularne są projekty tworzone „po godzinach” czy wszelkie rozwiązania self-hosted (przygotowane przez innych narzędzia, które można uruchomić we własnym zakresie – przy użyciu własnej infrastruktury). Samodzielne projekty są istotne w głównej mierze na początku kariery, kiedy nie można pochwalić się jeszcze komercyjnym doświadczeniem. Nic nie zastąpi realnych wyzwań w środowisku pracy, natomiast chęć do rozwijania swoich umiejętności wyrażona właśnie w poświęcaniu czasu na własne projekty na pewno będzie pozytywnym elementem CV – aczkolwiek ważne, żeby te projekty były jakkolwiek sensowne, bo napisanie kalkulatora (w czasach, gdy dowolne AI świetnie sobie z tym poradzi) na nikim nie zrobi wrażenia.
Podobne jest z narzędziami self-hosted. Różne ich przykłady zostały zagregowane w repozytorium Awesome-Selfhosted. Bez trudu znajdziemy rozwiązania, które są powszechnie cenione i wykorzystywane produkcyjnie. Niektóre osoby mają tendencję do uruchamiania i konfigurowania wielu „losowych” narzędzi o znikomym zastosowaniu. Zdecydowanie lepiej jest zapoznać się z narzędziami, które posiadają już pewną wartość i są zwyczajnie uznane.
Prywatnie korzystam z urządzenia Raspberry Pi 4 z zainstalowanym systemem Ubuntu 24.04. Z wyjątkiem jednej prostej aplikacji wszystkie stosowane przeze mnie w sieci domowej serwisy są uruchomione jako kontenery Docker. Jest to chyba najlepsza możliwa opcja, bo łatwo zachować porządek i pewną przejrzystość konfiguracji – tym bardziej że stack technologiczny tych usług jest różny, a dzięki konteneryzacji całkowicie można uniknąć tzw. dependency hell.
Technitium DNS
Najważniejsza z tych usług to własny serwer DNS/DHCP. Większość osób posiada pewne skojarzenie i podświadomie zakłada, że jest to Pi-hole bądź AdGuard Home. Zdecydowałem się jednak na mniej znane rozwiązanie, a mianowicie Technitium DNS Server. Sprawdził się doskonale i już od prawie roku jest stosowany w mojej prywatnej sieci domowej.
Posiada wiadome funkcjonalności serwera DNS i DHCP, ale przy tym wyróżnia się nieco bardziej zaawansowaną konfiguracją i nowoczesnym panelem zarządzania – w mojej opinii jest zwyczajnie „ładniejszy” od panelu znanego z dwóch wymienionych wyżej alternatyw. Co więcej, można go uruchomić jako standardową usługę systemową (wspierane są nie tylko systemy Linux, ale także Windows), jak również w formie kontenera. Dostępny jest gotowy plik docker-compose.yml, więc samo uruchomienie nie powinno sprawiać żadnych trudności. Definicję usługi można zresztą ograniczyć do tej postaci:
services:
dns-server:
container_name: dns-server
hostname: dns-server
image: technitium/dns-server:latest
network_mode: "host"
environment:
- DNS_SERVER_DOMAIN=dns-server
volumes:
- ./config:/etc/dns
restart: unless-stopped
Ważna zmiana dotyczy volumes – zwykle lepiej stosować bind mounts zamiast volumes. W takim scenariuszu dane są zapisywane/odczytywane z lokalnie dostępnego katalogu (również pliku), a do przeprowadzenia ich ewentualnej modyfikacji nie ma potrzeby „wchodzenia” do kontenera, bo całość można wykonać z poziomu hosta (pamiętając jednak o kwestii właściciela danego zasobu).
Kontener uruchamiamy poleceniem
docker compose up -d
Ustawienie adresu serwera DNS w pliku /etc/resolv.conf
Aby w łatwy sposób ustawić ten serwer DNS do obsługi zapytań z hosta (w tym przypadku Raspberry Pi), to obecnie trzeba dezaktywować usługę systemd-resolved. Umożliwi to korzystanie z pliku /etc/resolv.conf. Kroki dla systemu Ubuntu są następujące (jako nameserver podajemy rzecz jasna adres IP hosta):
sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo unlink /etc/resolv.conf
echo "nameserver 192.168.1.10"|sudo tee /etc/resolv.conf>/dev/null
sudo chattr +i -f /etc/resolv.conf
Konfiguracja DHCP
Następnie wystarczy w przeglądarce otworzyć adres http://192.168.1.10:5380/. Podajemy hasło dla użytkownika admin, po czym można przejść do właściwej konfiguracji.
Jeśli zamierzamy wykorzystywać serwer DHCP, to polecam zacząć właśnie od tych ustawień. Przechodzimy do zakładki DHCP i dalej Scopes. Zobaczymy domyślny scope, który jak najbardziej możemy dostosować do własnych potrzeb – nie ma konieczności dodawania konfiguracji „od zera”. Wybieramy więc przycisk Edit.
Na początku usuwamy zakres adresów podany w sekcji Exclusions – nie istnieje praktyczne uzasadnienie dla tej opcji, chyba że będziemy korzystać z rezerwacji adresów na poziomie DHCP. Zwykle jednak stosuje się statyczne adresy ustawione bezpośrednio w systemie operacyjnym danego hosta.
Dalej na samej górze ustawiamy zakres adresów, który z kolei będzie wykorzystywany przez serwer DHCP – te adresy będą przydzielane hostom. W zależności od ilości urządzeń można ustawić właściwy zakres.
Jeśli host, na którym działa Technitium DNS posiada kilka adresów IP, to dodatkowo musimy odznaczyć checkbox przy opcji Use This DNS Server i poniżej w polu, które wtedy stanie się możliwe do edycji, wpisać właściwy adres. U nas jest to 192.168.1.10
Oprócz tego przydatne może okazać się aktywowanie opcji ping check – jeśli nawet omyłkowo przypisaliśmy adres z puli DHCP do wybranego hosta, to działanie ping check powinno zapobiec wystąpieniu konfliktu adresów. Należy jednak pamiętać, że połączenia „ping” mogą być odrzucane przez niektóre zapory sieciowe. Taka sytuacja występuje m.in. w systemach Windows, gdzie Windows Firewall domyślnie blokuje próby ICMP.
Zapisujemy zmiany przyciskiem Save i aktywujemy ustawienia poprzez wybór Enable.
Od teraz przypisane adresy będą widoczne po wejściu w Leases.
Najpewniej w sieci działa już usługa DHCP dostarczana jako funkcjonalność każdego routera z segmentu tych przeznaczonych do małych (domowych) sieci. O ile zakresy adresów nie są tożsame, to nie powinno być to problemem, aczkolwiek nie ma potrzeby (z wyłączeniem redundancji), aby w tym samym czasie działały oba serwery. Należy więc wyłączyć tę usługę na poziomie routera.
Wskazanie adresu IP dla serwera DNS
W związku z faktem, że do interfejsu sieciowego Raspberry Pi jest przypisanych kilka adresów IP, to dodatkowo trzeba w zakładce Settings i karcie General podać adres, na jakim ma działać usługa DNS. Jeśli do interfejsu wykorzystywanego przez nas serwera jest przypisany standardowo jeden adres, to oczywiście nie ma potrzeby wdrażania tej zmiany w konfiguracji Technitium DNS.
Blokowanie domen
Teraz przejdziemy do konfiguracji, która pewnie będzie kluczowa dla większości osób. Technitium DNS nie korzysta z żadnych wbudowanych list domen do blokowania – jest to zdecydowanie dobre podejście. Użytkownik ma możliwość wyboru dowolnych list, także tych dostępnych wyłącznie w sieci wewnętrznej. Właściwe ustawienia wprowadzamy w Settings -> Blocking. Można użyć przykładowych list widocznych w menu rozwijanym. Tutaj korzystamy z listy https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/fakenews-gambling-porn/hosts.
Zawartość list jest odświeżana automatycznie, a interwał tego procesu domyślnie wynosi 24 godziny – powinno być to całkowicie wystarczające w większości przypadków.
Blokowanie domen wyłącznie na poziomie serwera DNS nie zawsze będzie w pełni skuteczne. Problematyczne jest przede wszystkim blokowanie reklam – wtyczki do przeglądarek pod tym względem sprawdzą się lepiej (DNS operuje wyłącznie na domenach, a wtyczki mogą blokować konkretne skrypty na różnych witrynach). Dodatkowo łatwe jest obejście ewentualnych blokad. Wystarczy, że użytkownik ustawi inny adres serwera bądź skorzysta z VPN. Absolutnie jednak nie wyklucza to zasadności korzystania z własnego serwera DNS.
DNS forwarding
Technitium DNS wspiera też bardziej bezpieczne metody odpytywania DNS, czyli m.in. DNS-over-HTTPS. Dzięki temu zapytania DNS są szyfrowane, co znacząco utrudnia ich analizę, a nam gwarantuje większą prywatność. Nawet jeśli wykorzystywane przez nas systemy nie obsługują tych protokołów, to poprzez wskazanie serwera z Technitium jako serwera DNS mamy pewność, że zapytanie do publicznego serwera DNS zostanie przesłane z użyciem bezpiecznego połączenia.
Konfiguracja sprowadza się do podania adresów zewnętrznego serwera DNS i wskazania odpowiedniego protokołu w karcie Proxy & Forwardes. Można też skorzystać z gotowych list widocznych w menu. Polecane przez nas serwery DNS zostały przedstawione w tym teście.
Logowanie zapytań
Oprócz wymienionych zmian warto również zmienić domyślny czas przechowywania historii obsłużonych zapytań w karcie Logging. 365 dni to bardzo długi okres dla domowego serwera DNS. Zmiana na 14 dni wydaje się rozsądna.
Logowanie jednak nie będzie działać bez instalacji dodatkowej aplikacji. Musimy wejść w zakładkę Apps i dalej App Store. Z listy aplikacji wybieramy przycisk Install przy Query Logs (Sqlite).
DNS zones
Przydatną funkcjonalnością może okazać się obsługa stref DNS. Pozwoli to na dodanie własnej lokalnej domeny, którą będą rozpoznawać urządzenia korzystające z naszego serwera nazw. Możemy dla przykładu wystawić wybraną usługę pod nazwą domenową. Przechodzimy do zakładki Zones i po wybraniu Add Zone podajemy jej nazwę, np. dom.local. Teraz będzie można dodać konkretne rekordy – formularz dostępny jest pod przyciskiem Add Record.
Hosty powinny poprawnie rozpoznawać tak dodane domeny.
Wyświetlanie historii zapytań
Logi obsłużonych zapytań widoczne są w zakładce Logs -> Query Logs. Po kliknięciu przycisku Query zostanie załadowana bieżąca lista. Wyniki można filtrować.
Analiza logów zapytań pozwoli na lepszy wgląd w ruch sieciowy. Interesująca może być statystyka ilości domen zablokowanych na podstawie list do tych, dla których adres IP został rozwiązany. Można też zauważyć, że aplikacje zainstalowane na urządzeniach „smart” (np. telewizorach) regularnie odpytują zdalne serwery, m.in. logs.netflix.com (to zresztą najczęściej blokowana domena).
Podsumowanie
Technitium DNS stanowi przykład rozwiązania, które z całą pewnością jest warte przynajmniej krótkiego przetestowania. Łatwa konfiguracja, przy jednoczesnym zachowaniu zaawansowanych ustawień sprawia, że opisywany serwer może sprawdzić się niezależnie od skali zastosowania – nie widzę przeszkód, aby korzystać z tego serwera w mniejszych sieciach firmowych. Pod kątem użyteczności wśród szeregu innych narzędzi self-hosted będzie to dobry wybór.
wpDiscuz
