Garnce miodu (ang. honeypot) to technika wykorzystywana w bezpieczeństwie komputerowym stosunkowo od niedawna, jednak sama koncepcja użycia przynęty, o jaką się opiera, ma wiekowe tradycje. W niniejszym artykule przedstawione zostały ogólne założenia i zasady działania systemów honeypot oraz instalacja, konfiguracja i działanie honeyd i dionaea.
Źródło: hakin9.org
Autor: Marcin Teodorczyk

W informatyce, honeypoty to systemy tworzone jedynie w celu zbierania informacji o atakach na nie przeprowadzanych. Systemy te nie pełnią żadnej innej funkcji.
Pierwsze pomysły stworzenia czegoś na kształt dzisiejszych honeypotów pojawiły się już na początku lat dziewięćdziesiątych. Nie sposób nie wspomnieć w tym miejscu o książce Clifforda Stolla Kukułcze jajo, opisującej zmagania administratora sieci uczelnianej jednego z uniwersytetów w USA z intruzem, jak się potem okazało z Europy.
Pierwszy krok w praktyce upowszechniający honeypoty wykonany został w 1997 roku, kiedy to Fred Cohen udostępnił Deception Toolkit (uznawany za pierwszy publicznie dostępny honeypot). Był to przeznaczony dla systemów *NIX zestaw skryptów napisanych w języku perl, symulujących znane usługi sieciowe wraz z wybranymi lukami dla zachęty dla atakujących. W miarę upływu czasu powstawało coraz więcej projektów, od prostych aplikacji po rozbudowane systemy czy nawet całe sieci komputerowe.
Przykładami współczesnych honeypotów są Specter, Kfsensorczy PatriotBox (o zamkniętym kodzie źródłowym) oraz Honeyd (Rysunek 1), Nepenthes, Dionaea (Rysunek 2) czy LaBrea (o otwartym kodzie źródłowym). W budowie honeypotów coraz częściej wykorzystuje się też oprogramowanie do wirtualizacji, takie jak Vmware, Virtualbox, Xen czy UML (ang. User Mode Linux) w połączeniu z oprogramowaniem monitorującym system takim jak Sebek i filtrującym ruch sieciowy jak iptables czy snort inline. W połączeniu z honeypotami bardzo często używane są mechanizmy typu chrootw systemach Linux i jail w systemach *BSD. Istnieją też implementacje honeypotów dedykowane sieciom bezprzewodowym, takie jak fake ap czy honeyspot.

Rodzaje honeypotów

Przytoczona w pierwszym akapicie definicja systemu honeypot wydaje się być bardzo szeroka i rzeczywiście pod pojęciem tym mogą kryć się bardzo różne systemy. Dlatego też, w tym miejscu, przedstawię krótką klasyfikację rozwiązań, która ułatwi odnalezienie się w gąszczu implementacji dostępnych na rynku.
Zwykle honeypoty klasyfikuje się ze względu na stopień interakcji, czyli na to, na ile pozwalają one atakującemu.
W skrajnym przypadku z jednej strony, honeypot może być całym systemem komputerowym (łącznie ze sprzętem). System taki nie różni się od typowego niczym oprócz tego, że wszelkie działania użytkowników są skrupulatnie rejestrowane w sposób dla nich niewidoczny oraz że nie służy on do niczego innego, jak tylko do kuszenia atakujących. Honeypoty tego typu, wiernie oddające rzeczywisty system i pozwalające atakującemu praktycznie na wszystko, nazywane są honeypotami o wysokim stopniu interakcji. Typowym rozwiązaniem jest tutaj uruchomienie rzeczywistego systemu lub systemu opartego o oprogramowanie do wirtualizacji (Xen, Vmware, Virtualbox, UML), wzbogaconego o podsystem monitorowania akcji użytkowników w sposób dla nich możliwie niezauważalny (np. Sebek) czy też gotowe rozwiązania komercyjne jak Symantec Decoy Server (przeznaczony dla systemów Solaris), które de facto pozwalają na to samo przy znacznie mniejszym nakładzie pracy. Podejście takie pozwala zebrać bardzo dużo informacji na temat ataków, jednak nie jest pozbawione wad. Pierwsza jaka się nasuwa na myśl to koszt. Trzeba przecież uruchomić cały system, tylko po to, żeby służył za przynętę. Kolejną wadą jest niebezpieczeństwo, że zostanie on wykorzystany w niecnych celach przez atakującego – po przejęciu maszyny dysponuje on wszystkimi jej zasobami i może użyć jej do kolejnych ataków. W skrajnym przypadku z drugiej strony, honeypot może być prostą aplikacją lub skryptem, nasłuchującym na wyznaczonym porcie i symulującym działanie jakiejś usługi. Honeypoty tego typu, symulujące usługi sieciowe, czasem symulujące działanie systemu operacyjnego (w bardzo ograniczonym zakresie), nazywane są honeypotami o niskim stopniu interakcji. Kluczowym słowem jest tutaj symulujące. Przykładowo, kilkulinijkowy skrypt mógłby odpowiadać na zapytania kierowane na port 25, zgodnie z protokołem SMTP (ang. Simple Mail Transfer Protocol), typowo działającym na tym właśnie porcie. Oczywiście jednocześnie zapisywane byłoby możliwie najwięcej danych na temat połączeń, tj. czas, adres źródłowy, przesyłane dane itp. Jako przykłady bardziej rozbudowanych rozwiązań
tego typu podać można Specter, Kfsensor, PatriotBox, Honeyd, Nepenthes, Dionaea. Zaletami takiego podejścia są niskie koszty, łatwość wykonania i małe ryzyko (skrypt/proces powinien działać z ograniczonymi uprawnieniami i ograniczać się tylko do parsowania otrzymanych danych i odpowiadania na znane ciągi znaków). Wadą jest stosunkowo niewielka ilość informacji na temat ataku, jaką można zebrać (w porównaniu do systemów o wysokim stopniu interakcji).
Istnieje jeszcze podział honeypotów ze względu na ich przeznaczenie. Wyróżnić tutaj można dwa podejścia. Z jednej strony honeypot może pełnić funkcję ostrzegawczą, odpowiednio wcześnie alarmując administratora o próbach ataków oraz dostarczać minimalnej ilości informacji na ich temat. Z drugiej strony, honeypot może być przeznaczony do zbierania jak największej ilości informacji, które potem wykorzystać można do badań. W tym momencie widoczna już powinna być analogia do podziału na honeypoty o wysokim stopniu interakcji i o niskim stopniu interakcji.
Do honeypotów zaliczane są także, trudne do sklasyfikowania wg powyższej terminologii, tzw. tarpit(ang. tar- smoła, ang. pit- dół), zwane także sticky honeypots. Są to systemy mające za zadanie spowolnić ataki sieciowe. Ich działanie opiera się o odpowiadanie na próby nawiązania połączeń w taki sposób, aby znacznie przedłużyć ten proces. Najprostszym rozwiązaniem tego typu jest użycie iptables. Jako przykład dedykowanych systemów przeznaczonych do tego typu zastosowań wymienić można netfilter, LaBrea, Honeyd.
Wartym wspomnienia na koniec rozszerzeniem idei honeypota jest honeynet. Za honeynet uznaje się dwa lub więcej honeypotów w tej samej sieci. Pierwszy, niekomercyjny, międzynarodowy projekt honeynet zapoczątkowany został w 1999 roku przez Lance’a Spitznera. Honeynet ten dostarcza dziś dla społeczności wiele honeypotów głównie o wysokim stopniu interakcji.

Honeypoty w praktyce

Honeypoty coraz częściej używane są w praktyce ze względu na zalety, których próżno można szukać pośród innych technik. Dobrze skonfigurowany honeypot zbiera niewielką (w porównaniu z tradycyjnymi systemami IDS) ilość bardzo wartościowych informacji. Oprócz tego, w odróżnieniu od innych systemów (IDS, antywirusów itp.) bardzo dobrze może spełniać swoją rolę także w przypadku nowych ataków czy nieopisanych jeszcze malware.
W dalszej części artykułu przedstawione zostaną honeypoty honeyd i dionaea, uruchomione pod kontrolą systemu operacyjnego Arch Linux.

Honeyd

Honeyd to przeznaczony dla systemów *NIX deamon, który tworzy wirtualne hosty we wskazanej podsieci. Na każdym hoście emulowane może być działanie systemu operacyjnego (dla skanów typu fingerprint) oraz usługi. Emulację usług dostarczają skrypty, które mogą być pisane w dowolnym języku – honeyd ogranicza się do ich uruchamiania po nawiązaniu połączenia na określony port zgodnie ze swoją konfiguracją. Oznacza to, że honeyd jest w stanie podjąć interakcję jedynie ze znanymi, opisanymi atakami. Oprócz tego, umożliwia on określenie domyślnego zachowania dla wskazanych portów przy próbie połączenia z nimi (np. block czy reset), a także działanie na zasadzie tarpit, czyli ustanawiania połączeń w sposób znacznie opóźniający hosta, który je nawiązuje. Wirtualne hosty mogą także odpowiadać na zapytania ping i traceroute. Wg informacji na stronie projektu, pojedyncza instalacja w praktyce jest w stanie obsłużyć do 65536 wirtualnych hostów w sieci komputerowej.
Honeyd dostępny jest wraz z kodem źródłowym na licencji GNU GPL i rozwijany jest przez Nielsa Provosa. Aktualna wersja stabilna (z 27 maja 2007 roku) nosi numerek 1.5c.

Rysunek 1. Strona domowa projektu honeyd

Instalacja honeyd

Najnowsza stabilna wersja honeyd dla dystrybucji Arch Linux dostępna jest w AUR (ang. Archlinux User Repository, http:/ /aur.archlinux.org/) i posiada następujące zależności: libdnet libevent libpcap pcre zlib libdnsres. Wszystkie oprócz ostatniej dostępne są w standardowych
repozytoriach i mogą być zainstalowane w następujący sposób:
pacman -Sy libdnet libevent libpcap pcre zlib
Ostatnią (libdnsres) najprościej zainstalować z użyciem AUR. Aby to zrobić należy pobrać tarball:
wget 'http://aur.archlinux.org/ packages/libdnsres/ libdnsres.tar.gz'
Rozpakować archiwum:
tar -xzf libdnsres.tar.gz cd libdnsres
Zbudować paczkę:
makepkg
I zainstalować pakiet:
pacman -U libdnsres-0.1a-1-i686.pkg.tar.gz cd .. && rm -Rf libdnsres*
Mając spełnione wymagania, można przystąpić do instalacji honeyd, także z wykorzystaniem AUR. Analogicznie do libdnsres, na początku pobieramy tarball:
wget 'http://aur.archlinux.org/packages/honeyd/ honeyd.tar.gz'
Następnie rozpakowujemy archiwum:
tar -xzf honeyd.tar.gz cd honeyd
Budujemy paczkę:
makepkg
I instalujemy pakiet:
pacman -U honeyd-1.5c-3-i686.pkg.tar.gz cd .. && rm -Rf honeyd*
W praktyce, aby móc korzystać z możliwości honeyd, oprócz odpowiedniej konfiguracji (o której później), potrzebujemy w jakiś sposób skierować ruch z nieużywanych (przez rzeczywiste hosty) adresów IP na host, na którym funkcjonował będzie nasz honeypot. Można to zrobić na dwa sposoby: przekazywać ruch na poziomie rutera lub zastosować technikę arp cache poisoning z poziomu hosta, na którym uruchomiony jest honeyd. W niniejszym artykule użyjemy drugiego rozwiązania.

ARP cache poisoning

Na stronie domowej honeyd dostępny jest do pobrania kod źródłowy programu arpd. Program ten, po wskazaniu podsieci, odpowiada na zapytania ARP (ang. Address Resolution Protocol) z adresem MAC (ang. Media Access Control) hosta, na którym jest uruchomiony. Ponadto, możliwe jest ustalenie opóźnienia po jakim odpowiedzi są generowane. Funkcjonalność ta jest idealna do zastosowania w połączeniu z naszym honeypotem. Mianowicie, za każdym razem, gdy ktoś próbuje się połączyć z adresem IP, wysyłane jest zapytanie ARP. W normalnej sytuacji odpowiada na nie host mający poszukiwane IP. Uruchomienie naszego arpd spowoduje, że jeśli żaden host nie odpowie na zapytanie ARP w ciągu, dajmy na to 1 sekundy, odpowie na nie nasz deamon, podając naszego hosta jako właściciela IP. Od tej pory wszystkie pakiety wysyłane z docelowym adresem IP równym wspomnianemu, trafiać będą do naszego hosta. W praktyce oznacza to tyle, że wszystkie zapytania kierowane do nieprzydzielonych rzeczywistym hostom IP będą przekierowywane na nasz host, na którym działa arpd i honeyd.
Arpd nie jest dostępny ani w standardowych repozytoriach, ani w AUR Arch Linuksa. Dlatego też, zbudujemy go ze źródeł i zainstalujemy w drzewie /opt/arpd.
Aby zainstalować arpd należy pobrać i rozpakować kod źródłowy ze strony honeyd:
wget http://www.citi.umich.edu/u/ provos/honeyd/ arpd-0.2.tar.gz
tar -xzf arpd
cd arpd
Następnie uruchomić skrypt configure:
./configure  -prefix=/opt/arpd
Jeśli w systemie brak libdneti libevent, skrypt powinien zakończyć się niepowodzeniem. Zainstalujmy więc te zależności. Libdnet pobrać można z sourceforge:
wget http://prdownloads.sourceforge.net/libdnet/libdnet-1.11.tar.gz?download tar -xzf libdnet-1.11.tar.gz cd libdnet-1.11
Konfiguracja i instalacja nie powinna sprawić żadnych problemów:
./configure  -prefix=/opt/libdnet
make
make install
Libevent pobrać można ze strony http: //monkey.org/~provos/:
wget 'http://monkey.org/~provos/libevent-1.4.10-stable.tar.gz'
Standardowo należy go rozpakować i uruchomić configure:
tar -xzf libevent-1.4.10-stable.tar.gz cd libevent-1.4.10-stable . /configure  -prefix=/opt/libevent
A następnie:
make
make install
Teraz wracamy do katalogu z arpd i ponownie uruchamiamy configure z następującymi parametrami:
./configure —prefix=/opt/arpd — with-libdnet=/opt/libdnet -with-libevent=/opt/libevent
A następnie:
make && make install
Jeśli kompilacja przeprowadzana jest wersją GCC nowszą niż 3.4, otrzymamy
komunikaty błędów przedstawione na Listingu 1. Rozwiązanie problemu zostało wyjaśnione na forum honeyd: http:// honeyd.org/phpBB2/viewtopic.php?t=471 Można zaaplikować łatkę na nim udostępnioną, lub ręcznie zamienić wszystkie linie w pliku arpd.c zawierające __FUNCTION__ analogicznie do poniższych:
syslog(LOG_DEBUG, __FUNCTION__ ": who-
has %s tell %s",
na
syslog(LOG_DEBUG, "%s: who-has %s tell %s",___FUNCTION___,
A następnie ponownie wywołać:
make && make install
Tym razem procesy powinny zakończyć się pomyślnie i arpd powinien być dostępny w lokalizacji /opt/arpd/sbin/ arpd.

Konfiguracja honeyd

Plik konfiguracyjny honeyd podawać będziemy jako parametr z linii poleceń, więc jego położenie w systemie plików jest nieznaczące. Pierwszą, najprostszą wersję pliku honeyd.config przedstawia Listing 2.
Tworzy on wzorzec default, będący hostem z systemem operacyjnym Microsoft Windows XP Professional. Host ten nie udostępnia żadnych usług i resetuje wszelkie próby połączeń TCP. Będzie on jednak odpowiadał na zapytania ping. Wzorzec default zawsze musi być zdefiniowany w pliku konfiguracyjnym i jest on przypisywany domyślnie do wszystkich adresów IP podsieci. Wypróbujmy teraz naszego bardzo prymitywnego honeypota:
honeyd -d -f ./honeyd.config -i vboxnet0 192.168.56.0/24
Powyższe polecenie uruchamia honeyd dla interfejsu vboxnet0 i podsieci 192.168.56.0/24, wczytuje plik konfiguracyjny honeyd.config znajdujący się w katalogu bieżącym i nie pozwala przejść honeypotowi w tryb pracy daemona (dzięki czemu na bieżąco będą widoczne próby połączeń).
Po uruchomieniu honeyd należy jeszcze uruchomić arpd aby skierować ruch z nieużywanych IP na nasz honeypot. Można to zrobić następującym poleceniem:
/opt/arpd/sbin/arpd -d -i vboxnet0 192.168.56.0/24
Spowoduje ono uruchomienie arpd bez przechodzenia w tryb daeamona, dzięki czemu będziemy w stanie śledzić przesyłane pakiety ARP.
Na potrzeby niniejszego artykułu uruchomiono drugi system we wskazanej podsieci. Istnieją w niej zatem teraz dwa rzeczywiste systemy: 192.168.56.1 i 192.168.56.3, przy czym honeyd i arpd działają na systemie 192.168.56.1. Reszta adresów IP w podsieci jest wolna.
Wypróbujmy zatem działanie naszego systemu. Z maszyny 192.168.56.3 wywołajmy polecenie:
ping  192.168.56.8
Jak wiadomo, w naszej podsieci nie ma takiego hosta. Jednak po opóźnieniu ok. 2000 ms dostajemy odpowiedź na nasze zapytanie. Jak to możliwe? Arpd przechwyciło zapytanie ARP wysyłane podczas wywołania polecenia ping, po upływie domyślnego wartości czasu oczekiwania odpowiedziało na nie, podając adres MAC hosta z uruchomionym honeyd. Następnie honeyd, zgodnie ze swoją konfiguracją odpowiedział na zapytanie ping. Zauważyć w tym momencie można zmieniające się opóźnienia odpowiedzi przedstawione na Listingu 3. (arpd wprowadza opóźnienie przy pierwszym pakiecie). Listing 4. przedstawia działanie arpd, Listing 5. przedstawia działanie honeyd.

Rysunek 2. Strona domowa dionaea

Usługi w honeyd

Spróbujmy teraz rozbudować nasz honeypot o kilka usług sieciowych. Na stronie honeyd: http://www.honeyd.org/ contrib.php znaleźć można przykładowe skrypty. W niniejszym artykule wykorzystamy dwa z nich: smtp.sh i ftp.sh. Po pobraniu skryptów do wybranego katalogu należy zmodyfikować plik konfiguracyjny honeyd.config. Tym razem ustawimy domyślne zachowanie dla połączeń TCP na block i utworzymy serwer dostępny pod adresem IP 192.168.56.8, na którym emulowane będą usługi SMTP i FTP. Plik konfiguracyjny realizujący taki honeypot przedstawia Listing 6. Należy zwrócić szczególną uwagę na poprawność ścieżek do skryptów emulujących usługi oraz poprawność praw dostępu do nich (m.in. prawa do wykonywania). Jako system operacyjny podany jest Astaro Linux. Wykaz obsługiwanych systemów operacyjnych znaleźć można w pliku /usr/share/honeyd/nmap.assoc. Ponownie uruchamiamy arpd i honeyd (w dwóch oknach):
/opt/arpd/sbin/arpd -d -i vboxnet0 192.168.56.0/24
honeyd -d -f ./honeyd.config -i vboxnet0 192.168.56.0/24
Uruchamiamy też naszą maszynę wirtualną. Tym razem, na ping odpowiadać powinny tylko 3 hosty: 192.168.56.1 (gospodarz), 192.168.56.3 (maszyna wirtualna) i 192.168.56.8 (serwer emulowany przez honeyd). Spróbujmy połączyć się z naszymi usługami z hosta 192.168.56.3:
telnet  192.168.56.8  21
Po wykonaniu powyższego polecenia połączenie zostanie nawiązane i powinien zostać wyświetlony komunikat: 220 red.localdomain FTP server (Version wu-2.6.0(5) Mon Dec 14 22:08:39 CET 2009) ready. Wpisanie dowolnego polecenia (oprócz quit) spowoduje wyświetlenie 530 Please login with USER and PASS. Więcej szczegółów na temat emulacji znaleźć można w kodzie źródłowym ftp.sh. Podobny eksperyment można wykonać z usługą SMTP:
telnet  192.168.56.8  25
Miejsce, gdzie logowane są dane na temat połączeń wskazywane jest w samych skryptach emulujących usługi i domyślnie jest to zwykle plik w katalogu /tmp.
Polecam zapoznanie się ze stroną domową projektu honeyd i przetestowanie innych skryptów, a także eksperymentowanie z własnymi rozwiązaniami.

Zaawansowane możliwości honeyd

Honeyd posiada możliwości znacznie wykraczające poza zakres niniejszego artykułu. Zachęcam do samodzielnego
ich wypróbowania. Jedną z nich jest wsparcie dla tworzenia topologii rutowania (ang. routing topology). Dzięki tej funkcjonalności można dowolnie kształtować topologię naszej wirtualnej sieci honeypotów. Kolejną jest podsystem wirtualizacji, który umożliwia uruchomienie rzeczywistych aplikacji (np. /usr/sbin/httpd) na wirtualnych hostach pod kontrolą honeyd. Znacznie zwiększa to poziom interakcji dostępny dla atakującego (usługi są rzeczywiste a nie emulowane). Honeyd wspiera także tworzenie dynamicznych wzorców - zachowanie sieci może się zmieniać zależnie od adresu źródłowego, systemu operacyjnego i czasu połączenia. Ostatnią możliwością są wewnętrzne usługi pisane w języku python, sterowane zdarzeniami (ang. event-driven).

Dionaea

Dionaea to honeypot o niskim stopniu interakcji, napisany w C i pythonie, dostępny wraz z kodem źródłowym na licencji GNU GPL w wersji 2, będący
następcą nie rozwijanego już nepenthes. Dionaea umożliwia emulowanie usług przy pomocy pythona, wykorzystuje libemu do wykrywania shellcodes (ang. shell - powłoka, code - kod) i wspiera protokoły ipv4, ipv6 oraz TLS (ang. Transport Layer Security). Dzięki zastosowaniu sqlite3 pozwala też na wygodne przeglądanie logowanych danych (z użyciem zapytań SQL). W czasie działania, dionaea udostępnia powłokę python.

Instalacja

Dionaea posiada szereg zależności, które muszą być spełnione zanim przystąpimy do budowy samego honeypota. Jako, że oprogramowanie to jest ciągle w pierwszej, gwałtownej fazie rozwoju, wśród wymagań znajdują się najnowsze wersje, nierzadko nietypowych bibliotek. Trudno zapewnić je z użyciem managera pakietów większości dystrybucji. Dlatego też, w niniejszym artykule opisana została instalacja honeypota wraz z niektórymi zależnościami w drzewie /opt/dionaea. Oprócz tego, aby przejść przez proces budowania oprogramowania potrzebne są systemy kontroli wersji SVN (ang. SubVersioN) i Git oraz kompilator GCC (ang. GNU Compiller Collection) i narzędzia GNU Autotools (m.in. autoconf, automake, make).
Na początek zainstalujmy więc potrzebne narzędzia:
pacman -Sy subversion git gcc make
automake autoconf libtool
Następnie zależności, które znaleźć można w repozytoriach Arch Linuksa:
pacman -Sy curl openssl readline glib2 libev gc python
Pozostałe zależności zainstalujemy w drzewie /opt/dionaea, budując je z kodów źródłowych. Będą to kolejno liblcfg, libemu, libnl, udns i cython.
Liblcfg (lightweight configuration file library) jest napisaną w C99 biblioteką dostarczającą wsparcie dla prostych plików konfiguracyjnych, które mogą zawierać przypisania, listy i mapowania (słowniki). Kod źródłowy liblcfg pobrać można z publicznego repozytorium SVN w następujący sposób:
svn co https://svn.carnivore.it/ liblcfg/code/trunk liblcfg cd liblcfg
A następnie zainstalować, wywołując polecenia:
autoreconf -vi
. /configure  —prefix=/opt/dionaea
make install && cd ..
Libemu to biblioteka napisana w C, udostępniająca podstawową emulację
procesorów x86 i detekcję kodów maszynowych (shellcodes) z użyciem heurystyk (GetPC). Podobnie jak liblcfg, kod źródłowy libemu pobrać można z publicznego repozytorium SVN:
svn co https://svn.carnivore.it/libemu/trunk libemu cd libemu
Następnie można przystąpić do konfiguracji i instalacji:
autoreconf -vi
. /configure  —prefix=/opt/dionaea
make install && cd ..
Libnl (Netlink Library) udostępnia interfejs do komunikacji z wykorzystaniem netlink. Kod źródłowy libnl pobrać można z publicznego repozytorium Git w następujący sposób:
git clone git://git.kernel.org/pub/ scm/libs/netlink/ libnl.git
cd libnl
Aby zbudować i zainstalować bibliotekę należy wywołać następujące polecenia:
autoreconf -vi
export  LDFLAGS=-Wl,-rpath,/opt/ dionaea/lib
. /configure  —prefix=/opt/dionaea make && make install && cd  ..
Udns (DNS Resolver Library) umożliwia tworzenie synchronicznych i asynchronicznych zapytań DNS (ang. Domain Name Server). Kod źródłowy udns pobrać można w następujący sposób:
wget http://www.corpit.ru/mj t/udns/udns_0.0.9.tar.gz tar xfz udns_0.0.9.tar.gz cd udns-0.0.9/
Następnie należy skonfigurować i zbudować bibliotekę, wykorzystując polecenia:
./configure make shared
Wreszcie aby zainstalować bibliotekę, należy skopiować pliki nagłówkowe do naszego katalogu include:
cp udns.h /opt/dionaea/include/
oraz pliki biblioteki do katalogu lib:
cp *.so* /opt/dionaea/lib/
Na koniec konieczne jest stworzenie dowiązania symbolicznego:
cd /opt/dionaea/lib
ln -s libudns.so.0 libudns.so
cd ..
Cython jest ostatnią zależnością jaką musimy zainstalować. Jest to język programowania, który ułatwia pisanie modułów dla cpython, składnią do złudzenia przypominając pythona, jednak umożliwiając wywoływanie funkcji C i deklarowanie zmiennych o typach znanych z C. Cython dla dystrybucji Arch Linux dostępny jest w AUR. Można go pobrać w następujący sposób:
wget   'http://aur.archlinux.org/packages/cython/cython.tar.gz tar -xzf cython.tar.gz cd cython
Następnie, aby zbudować i zainstalować paczkę trzeba wykonać:
makepkg
pacman -U cython-0.12-1-i686.pkg.tar.gz
Nadszedł w końcu czas na to, co najbardziej nas interesuje. Kod źródłowy Dionaea dostępny jest poprzez repozytorium SVN. Można go pobrać wywołując polecenie:
svn co https://svn.carnivore.it/dionaea/trunk dionaea cd dionaea
Następnie należy przekonfigurować system budowania:
autoreconf -vi
Kolejnym krokiem jest wywołanie ./ conflgure. Ze względu na to, że wcześniej zainstalowaliśmy zależności w drzewie /opt/dionaea, konieczne będzie podanie szeregu parametrów. Pełne wywołanie przedstawia Listing 7.
Po pomyślnym zakończeniu skryptu ./configure powinniśmy otrzymać podsumowanie konfiguracji dionaea. Na koniec pozostaje nam zbudować i zainstalować honeypot:
make && make install && cd ..

Rysunek 3. Dionaea po uruchomieniu skanowania portów nmap

Konfiguracja dionaea

Plik konfiguracyjny dionaea.conf znajduje się w katalogu /opt/ dionaea/etc/dionaea. W jego treści można wyróżnić bloki. W pierwszym bloku podaje się plik, do którego mają być logowane zdarzenia. My pozostawimy tutaj wartość domyślną (log/dionaea.log). Jak już wcześniej wspomniano, dionaea korzysta z libemu, biblioteki dostarczającej emulacji x86. W kolejnym bloku pliku konfiguracyjnego można ustawić parametry emulowanego procesora. Te wartości także pozostawimy domyślne. Następnie podawane są katalogi, w których zapisywane mają być przechwycone binaria (var/dionaea/ binaries) i bistreams (var/dionaea/ bistreams).
W kolejnym bloku podawane są adresy URL (ang. Unified Resource Locator) tzw. analizatorów sandbox. Są to serwisy WWW, pozwalające przesłać binaria, które poddawane są potem analizie. Następnie wyniki udostępniane
przez WWW/e-mail. Domyślnie podane są dwa serwisy Norman Sandbox i CWSandbox oraz adres e-mail nepenthesdev@gmail.com, na który wysyłane mają być raporty z analizy. Należy go oczywiście zmienić na własny adres e-mail i pamiętać, że niektóre serwisy wymagają rejestracji on-line.
W następnym bloku podać można adresy IP kart sieciowych, na których dionaea ma nasłuchiwać. Domyślnie dionaea nasłuchuje na wszystkich adresach wszystkich kart sieciowych i takie też ustawienie pozostawimy do naszych testów.
Kolejny blok (modules) to ustawienia związane z modułami: curl, emu, pcap i python. W module python znaleźć można m.in. blok logsql, w którym podawany jest plik sqlite do logowania danych na temat ataków. Dane te można potem przeglądać z użyciem zapytań sqlite3 (co zostanie zademonstrowane w dalszej części artykułu).

Dionaea w akcji

Jeśli do tej pory wszystko zostało wykonane poprawnie, powinniśmy być już w stanie uruchomić naszą instalację dionaea. Na początek, jako użytkownik root wykonajmy polecenie:
/opt/dionaea/bin/dionaea -l all,-debug -L  '*'
Zgodnie z konfiguracją, powinno ono uruchomić nasz honeypot nasłuchujący na wszystkich obsługiwanych portach i wszystkich interfejsach. Dla sprawdzenia działania, wykonajmy skanowanie wybranych portów programem nmap:
nmap -p 22,23,25,80,443  192.168.1.109 -reason
Powyższe polecenie spowoduje przeskanowanie portów 22, 23, 25, 80 i 443 dla adresu IP 192.168.1.109 i powinno dać wynik przedstawiony na Listingu 8. Jednocześnie, nasz honeypot powinien odnotować próby połączeń na wyżej wymienione porty i wyświetlić odpowiednie komunikaty (widoczne na Rysunku 3).
W przeciwieństwie do honeyd, dionaea de facto nie emuluje usług/ aplikacji, a działa na zasadzie emulacji sprzętu/luk. Dzięki temu jest w stanie zebrać zarówno znany jak i nowy, nieznany malware.

Baza danych dionaea

Dionaea zapisuje szereg danych w bazie sqlite3. Domyślnie plik bazy to /opt/dionaea/var/dionaea/logsql.sqlite. Przykładowy skrypt w pythonie wyświetlający wszystkie zarejestrowane połączenia przedstawia Listing 9.
Oprócz tabeli connections, zawierającej dane dotyczące połączeń dostępne jest m.in. tabela downloads. Oczywiście nic nie stoi na przeszkodzie realizowania bardziej zaawansowanych zapytań. Przykładowo, aby wyświetlić atakujące hosty w kolejności od najbardziej aktywnego (najwięcej ataków), wraz z liczbą ataków, posłużyć można się zapytaniem:
SELECT COUNT(remote_host), remote_host FROM connections WHERE connection_type
= 'accept' GROUP BY remote_host ORDER BY
COUNT(remote_host) DESC;

Zaawansowane możliwości dionaea

Dionaea może współpracować z P0f. P0f jest wolnodostępnym programem realizującym pasywny fingerprinting. Pozwala on na zdobycie dodatkowych informacji na temat atakujących, takich jak rodzaj i wersja systemu operacyjnego.
Inną, bardzo użyteczną funkcjonalnością dionaea jest konsola python, dostępna w czasie rzeczywistym, po uruchomieniu honeypota. Można przy jej użyciu wykonywać np. wspomniane wcześniej zapytania do bazy sqlite3.

Honeypoty a ryzyko

Często zdarza się, że podczas instalacji i konfiguracji honeypota, zapominamy (lub bagatelizujemy) ryzyko z tym związane. W niniejszym artykule,
dla uproszczenia celowo pominięto zagadnienia dotyczące minimalizacji tego ryzyka. Nie zwalnia to jednak czytelnika z jego świadomości. Przykładowo, dla przedstawionych honeypotów (honeyd i dionaea) uzasadnione wydaje się maksymalne odizolowanie ich od systemu, na którym działają i zminimalizowanie uprawnień z jakimi są uruchamiane. Oprócz standardowego dobrania użytkownika, z którego prawami uruchamiany jest honeypot, można tutaj użyć mechanizmów takich jak chroot czy jail oraz grsecurity czy SELinux. Dodatkowo, na wypadek kompromitacji honeypota, dobrze jest zapewnić jego izolację od pozostałej części sieci komputerowej. Wystarczyć tutaj powinna zapora sieciowa, blokująca ruch inicjowany z honeypota (który przecież w założeniu służy jedynie jako serwer).

Podsumowanie

Po skonfigurowaniu i zabezpieczeniu honeypota polecam udostępnienie go w sieci publicznej. Szybkość z jaką rośnie liczba ataków potrafi być zaskakująca i pouczająca. Podobnie jak zbierane informacje.
Honeypoty to bez wątpienia technologia przyszłości. Obecnie rozwiązania o dobrze ugruntowanej pozycji (takie jak honeyd), dobrze sprawdzające się w obliczu znanych ataków i luk, powoli zaczynają ustępować miejsca nowatorskim rozwiązaniom (takim jak dionaea) bazującym m.in. na heurystykach.
Honeypoty w różnych formach bez wątpienia mają i będą miały zastosowanie w systemach zabezpieczeń, wspaniale uzupełniając możliwości systemów IDS, firewalli i anty wirusów.

W Sieci

• • http://www.honeyd.org/ – Honeyd,
• • http://dionaea.carnivore.it/ – Dionaea,
• • http://carnivore.it/ – Carnivore,
• • http://www.honeynet.org/ – Honeynet,
• • http://archlinux.org/ – Arch Linux.

Akronimy

Address Resolution Protocol – ARP,
Archlinux User Repository – AUR,
Domain Name Server – DNS,
File Transfer Protocol – FTP,
GNU Compiler Collection – GCC,
GNU's Not Unix – GNU,
General Public License – GPL,
Intrusion Detection System – IDS,
Internet Protocol – IP,
Media Access Control – MAC,
Simple Mail Transfer Protocol – SMTP,
Structured Query Language – SQL,
SubVersioN – SVN,
Transport Layer Security – TLS,
User Mode Linux – UML,
Uniform Resource Locator – URL.


Listing 1. Komunikaty błędów podczas kompilacji arpd
[mpt@red]arpd> make
make all-am
make[1]: Entering directory `/home/mpt/workdir/arpd'
gcc -DHAVE_CONFIG_H -I. -I/opt/libdnet/include -I/opt/libevent/include -I/usr/
include/pcap -I/opt/libdnet/include -c arpd.c
arpd.c: In function ‘arpd_send’:
arpd.c:268: error: expected ‘)’ before string constant
arpd.c: In function ‘arpd_lookup’:
arpd.c:285: error: expected ‘)’ before string constant
arpd.c:294: error: expected ‘)’ before string constant
arpd.c:297: error: expected ‘)’ before string constant
arpd.c: In function ‘arpd_recv_cb’:
arpd.c:426: error: expected ‘)’ before string constant
make[1]: *** [arpd.o] Error 1
make[1]: Leaving directory `/home/mpt/workdir/arpd'
make: *** [all] Error 2

Listing 6. Zawartość zmodyfikowanego pliku honeyd.config
create default
set default default tcp action block
set default default udp action block
set default default icmp action block
create server
set server personality "Astaro Security Linux 4 (Kernel 2.4.19)"
add server tcp port 21 "./ftp.sh"
add server tcp port 25 "./smtp.sh"
set server default tcp action reset
bind 192.168.56.8 server
Listing 7. Parametry wywołania ./configure dla dionaea
./confi gure --with-lcfg-include=/opt/dionaea/include --with-lcfg-lib=/opt/dionaea/lib/liblcfg --with-python=/opt/dionaea/bin/
python3.1 --with-emu-include=/opt/dionaea/include/ --with-emu-lib=/opt/dionaea/lib/libemu/ --with-nlinclude=/
opt/dionaea/include/ --with-nl-lib=/opt/dionaea/lib/ --with-emu-include=/opt/dionaea/include/
--with-emu-lib=/opt/dionaea/lib/libemu/ --with-udns-include=/opt/dionaea/include/ --with-udns-lib=/opt/
dionaea/lib/
Listing 8. Wynik skanowania dionaea z użyciem nmap
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-10 23:06 CET
Interesting ports on red (192.168.1.109):
PORT STATE SERVICE REASON
22/tcp closed ssh conn-refused
23/tcp closed telnet conn-refused
25/tcp closed smtp conn-refused
80/tcp open http syn-ack
443/tcp open https syn-ack
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
Listing 9. Skrypt wyświetlający wszystkie połączenia zarejestrowane przez dionaea
#!/opt/dionaea/bin/python3
import sqlite3
import sys
def main():
conn = sqlite3.connect('/opt/dionaea/var/dionaea/logsql.sqlite')
c = conn.cursor()
sql = 'SELECT * FROM connections'
c.execute(sql)
for row in c:
print(row)
sys.exit()
if __name__ == "__main__":
main()