IPS i web proxy – podejście tradycyjne

W walce z zagrożeniami czyhającymi na nas podczas przeglądania zasobów Internetu jednymi z najczęściej stosowanych rozwiązań są chyba sondy IDS oraz serwery web proxy. Pierwszych obawiamy się często ze względu na fakt, iż wpięte in-line stanowią pojedyncze punkty awarii. Drugie wymagają stosowania dodatkowych mechanizmów przekierowujących ruch http/https do bramy, która następnie musi go analizować, co wpływa negatywnie na wydajność. W przypadku ruchu https konieczne jest jeszcze „rozszywanie” go za pomocą podmienianych w locie certyfikatów, co budzi kolejne wątpliwości.

A może…

A czy da się filtrować niebezpieczny ruch bez włączania w infrastrukturę sieciową dodatkowych urządzeń, przekierowywania ruchu z przeglądarek, podmiany certyfikatów i spowalniania komunikacji? Da się – przy pomocy serwera DNS. Jest to podejście dosyć mało jeszcze spopularyzowane ale posiadające wiele zalet.

Każde zapytanie generowane z przeglądarki www, ale co ważne również innych protokołów trafia najpierw do serwera DNS. Serwer DNS na podstawie nazwy domeny jest w stanie z naszą niewielką pomocą  zidentyfikować zagrożenie (korzystając z baz reputacji) i przekierować ruch zamiast do niebezpiecznego hosta docelowego, do lokalnej strony zawierającej ostrzeżenie dla użytkownika.

Super. To skąd wziąć taki serwer DNS potrafiący rozpoznać zagrożenia bazując na bazach reputacji? Można oczywiście kupić gotowy, komercyjny produkt – rozwiązanie OpenDNS firmy Cisco.  Jeżeli jednak wolimy rozwiązania, które są „open” nie tylko z nazwy możemy pokusić się o stworzenie niewielkim nakładem sił własnego systemu DNS uczącego się zagrożeń z różnych źródeł Internetu.

Do dzieła

Idąc z duchem czasu potrzebną infrastrukturę uruchomimy w środowisku chmurowym. Wykorzystamy do tego celu usługę serwerów wirtualnych polskiego dostawcy http://e24cloud.com. Umożliwi to nam zbudowanie skalowalnego i odpornego na awarię systemu składającego się z 4 serwerów nazw i dwóch load balancerów rozmieszczonych w dwóch lokalizacjach (Poznań i Warszawa). Koszt utrzymania wszystkich 6 maszyn w minimalnej konfiguracji to około 220 zł na m-c. Nie jest to wiele jak na system wysokiej dostępności (pamiętajmy, że nie zapłacimy ani złotówki za prąd, klimatyzację, umowy gwarancyjne i mnóstwo innych rzeczy, o których musielibyśmy pomyśleć utrzymując sprzęt u siebie).

                                         DNS 1
        / load balancer A (Poznań)---- /
klient /                               \ DNS 2
       \                                 DNS 3
        \ load balancer B (Warszawa)-- /
                                       \ DNS 4

Taka konfiguracja zapewnia nam odporność na awarię datacenter w dowolnej z dwóch lokalizacji, awarię load balancera oraz awarię serwera DNS.

Load balancery

Dostępne u większości dostawców usług chmurowych gotowe load balancery mają jeden mankament – nie potrafią rozdzielać ruchu na poziomie protokołu DNS. W naszym przypadku konieczne będzie więc zastosowanie dedykowanego do tego rozwiązania – usługi Relayd będącej częścią składową systemu OpenBSD. Instalacja samego systemu z obrazu dostępnego standardowo w repozytorium instalek e24cloud przebiega dosyć intuicyjnie. Należy pamiętać jedynie aby przed utworzeniem serwera w panelu e24cloud utworzyć najpierw sieć vlan dla danej lokalizacji i podpiąć do niej serwer w chwili jego uruchamiania. Dzięki temu oprócz interfejsu z publicznym adresem IP utworzony zostanie dodatkowy, o którego konfigurację zostaniemy zapytani przez instalator OpenBSD. Dla sieci vlan i podłączonego do niej interfejsu wybieramy dowolną adresację IP z klasy adresów prywatnych.

Po instalacji samego systemu pozostaje nam konfiguracja usługi Relayd w taki sposób, aby ruch przychodzący na port 53 load balancera był proporcjonalnie dystrybuowany pomiędzy dwa serwery DNS w danej lokalizacji. Efekt taki uzyskamy tworząc plik konfiguracyjny /etc/relayd.conf z poniższą zawartością:

relayd_addr="A.B.C.D"
relayd_port="53"

table <dns_servers> { 192.168.0.10, 192.168.0.11 }
dns_servers_port="53"

interval 10
timeout 200
prefork 5
log updates

dns protocol "dnsfilter" {
 tcp { nodelay, sack, socket buffer 1024, backlog 1000 }
}

relay dnsproxy {
 listen on $relayd_addr port $relayd_port
 protocol "dnsfilter"
 forward to <dns_servers> port $dns_servers_port \
 mode loadbalance check icmp
}

Znaczenie poszczególnych parametrów znajdziemy w oficjalnym manualu. Najistotniejsze dla nas to relayd_addr – adres publiczny naszego load balancera, pod którym będziemy oczekiwać na zapytania oraz <dns_servers> – lista adresów prywatnych w sieci vlan, do których będziemy te zapytania przekierowywać.
Co istotne, Relayd potrafi dzięki parametrowi „check” badać dostępność każdego z serwerów DNS i w przypadku stwierdzenia jego awarii przestaje przydzielać do niego zapytania.

Serwery DNS

Tutaj pójdzie już łatwiej. Jako serwery DNS wykorzystamy gotowe do uruchomienia obrazy systemów Linux, może być np. Ubuntu 16.10. Pamiętajmy jedynie o konieczności podpięcia serwera do stworzonego w kroku poprzednim vlanu i skonfigurowania mu adresu IP z tej samej puli.  Serwer dostanie też przydzielony adres publiczny na pierwszym interfejsie. Zostawiamy go by ułatwić sobie konfigurację ale później będzie go można usunąć.

Pozostaje nam jeszcze doinstalowanie pakietu openjdk-8-jre, który będzie nam potrzebny w kolejnym kroku.

sudo apt-get install openjdk-8-jre

Usługa DNS

Sercem całego rozwiązania będzie łatwy z instalacji i zarządzaniu, a co najważniejsze dostępny bezpłatnie pakiet NxFilter. Pobieramy go na nasz serwer ze strony producenta i instalujemy. W przypadku wybranego wcześniej systemu Ubuntu ogranicza się to do dwóch komend:

wget http://www.nxfilter.org/download/nxfilter-4.1.4-p1.deb
sudo dpkg -i nxfilter-4.1.4-p1.deb

Szczegóły oraz instrukcje instalacji dla innych systemów (w tym Windows) znajdziemy w bardzo pomocnym tutorialu.

Interfejs

Na tym etapie możemy się już zalogować do konsoli NxFilter dostępnej pod adresem publicznym pierwszego serwera dns – https://A.B.C.D/admin . Login i hasło z pewnością zgadniecie 🙂

Interfejs użytkownika jest bardzo przejrzysty i intuicyjny. Jeżeli już w tej chwili ustawimy sobie adres publiczny load balancera jako DNS na naszym komputerze to po paru minutach pracy wygenerują nam się ładne statystyki dotyczące zapytań DNS:

Jak to działa?

NxFilter realizuje dwa podstawowe zadania – klasyfikowanie nazw domenowych do jednej z domyślnych 53 kategorii (np. polityka, sport, phishing/malware, social media itd.) oraz blokowanie ruchu do nich na podstawie zdefiniowanych polityk. Jest tutaj tylko jedno małe „ale” – funkcja kategoryzacji bazuje na danych dostarczanych przez płatną usługę Jahaslist i w wersji darmowej obsłuży maksymalnie 20 użytkowników. Dla każdego kolejnego konieczna będzie licencja – koszt 50USD dla 50 użytkowników na rok.

Pamiętajmy jednak, że nam nie chodziło o cenzurowanie treści, a o zabezpieczenie się przed złośliwym oprogramowaniem. Możemy zatem zdefiniować sobie własną, nie systemową kategorię (zakładka Category -> Custom) np. o nazwie „zagrożenia” i przypisywać do niej domeny samemu, bez konieczności płacenia. Jak to robić automatycznie i skąd czerpać dane o niebezpiecznych domenach dowiemy się z punktu następnego.

Internetowe bazy reputacji

W Internecie dostępnych jest co najmniej kilkadziesiąt płatnych lub darmowych baz zawierających listy adresów IP i nazwy domen, które uznać należy za zagrożenie dla osób je odwiedzających. Poniżej wymienione zostaną te najpopularniejsze i dostępne bezpłatnie (niektóre tylko do celów niekomercyjnych):

1. Projekt blackweb
2. HpHosts by Malwarebytes
3. Malc0de Database
4. DNS-BH Malware Domain Blocklist
5. MalwareDomainList.com
6. Malware Patrol
7. OpenPhish – phishing sites

Ponadto w katalogu /nxfilter/jahaslist po zainsalowaniu pakietu NxFilter znajduje się plik baselist.txt, w którym skategoryzowane zostało ponad 1,5 mln. domen. Spośród nich ponad 56 tys. domen przydzielonych zostało domyślnej, systemowej kategorii „phishing/malware”. W prosty sposób możemy sobie wyeksportować te domeny do odrębnego pliku, aby następnie wraz z danymi z powyższych źródeł zaklasyfikować je do naszej, zdefiniowanej wcześniej kategorii „zagrożenia”:

> grep ",39" baselist.txt |tr -d ",39" > zagrozenia.txt
> wc -l zagrozenia.txt 
56343 zagrozenia.txt

Plik baselist.txt ma format listy w postaci „nazwa.domeny.com,XX” gdzie XX to numer kategorii. Interesująca nas „phishing/malware” ma numer 39. Listujemy więc wszystkie wiersze z pliku baselist.txt zawierające numer kategorii 39 i zapisujemy je do pliku zagrozenia.txt pomijając przy zapisie przecinek i numer kategorii (chcemy otrzymać czystą listę domen). W podobny sposób przy życiu narzędzi typu grep, awk, tr „obrabiamy” listy domen pobierane z innych źródeł.

Automatyzacja uczenia

Pozostaje nam jeszcze jeden krok – wrzucenie listy zebranych dla kategorii „zagrożenia” domen do bazy danych, z której korzysta NxFilter. Autorzy pakietu przygotowali do tego celu interfejs DAO. Jeżeli jednak, podobnie jak autor tego artykułu, nie jesteście zawodowymi programistami to szybciej załatwicie sprawę przy pomocy curl-a tworząc prosty skrypt, który loguje się do panelu i wrzuca dane do formularza z wykorzystaniem metody POST. Poniżej przykład, który zaoszczędzi konieczności analizowania pól formularza i formatu przesyłanych zmiennych:

#!/bin/bash

#pobieramy ID sesji z ciasteczka:
SID=`curl --silent --proto http -A Mozilla/5.0 -L -H "Content-Length: 55" \ 
-I http://127.0.0.1/admin | grep Set-Cookie | awk '{print $2}' | tr --delete ';'`;

# logujemy się 
curl --silent --proto http -X POST -A Mozilla/5.0 -L -b "$SID" -H "Content-Length: 55" \
--data "actionFlag=login&uname=admin&passwd=HASLO" http://127.0.0.1/admin;

# wrzucamy domeny z pliku do formularza
for domena in `cat zagrozenia.txt`; do
curl --silent --proto http -X POST -A Mozilla/5.0 -L -b "$SID" --data \
"actionFlag=addDomain&id=101&domainId=&description=black+lista&domain=$domena" \
http://127.0.0.1/category,custom_edit.jsp;
done;

Wrzucenie do bazy w powyższy sposób kilkudziesięciu tysięcy domen na maszynie z 1cpu i 0,5GB ramu zajęło parę godzin. Może to mało elegancki i wydajny sposób, ale programistą w kilka godzin też nikt się nie stanie. Można jeszcze próbować bawić się z bezpośrednim dostępem do bazy opartej na dosyć egzotycznym silniku H2, jednak z komentarzy na forum użytkowników NxFilter wynika, że nie warto.

Podsumowanie

Do tej pory skonfigurowaliśmy jeden serwer DNS z pracującym na nim pakietem NxFilter oraz jeden load balancer. Pozostaje nam stworzyć obrazy dysków systemowych tych maszyn, aby móc uruchomić ich kolejne instancje. W panelu e24cloud robimy to wchodząc we właściwości serwera i wybierając z zakładki „zaawansowane” opcję „tworzenie obrazu”. Utworzony w ten sposób obraz dysku możemy wykorzystać tworząc kolejny serwer. Pozostaje nam zatem utworzyć 3 kolejne serwery nazw oraz jeden load balancer pamiętając oczywiście o zmianie adresów IP i rozmieszczeniu ich pomiędzy 2 centra danych zgodnie ze schematem na początku artykułu. Sprawę bardzo ułatwia fakt, że obraz wykonany z systemu w jednym data center można wykorzystać do uruchomienia serwera również w drugim.

Na zakończenie pozostaje nam adresy publiczne load balancerów wykorzystać jako adresy serwerów DNS w naszej sieci. Można to zrobić za pomocą DHCP lub po prostu ustawić je jako DNSy nadrzędne dla naszego lokalnego serwera.

Obserwuj

Obserwuj