Wykrywanie Honeypotów – Metody, Narzędzia, Obrona - Security Bez Tabu

Wykrywanie Honeypotów – Metody, Narzędzia, Obrona

Honeypoty też mają odciski palców

Honeypoty (komputerowe wabiki) są potężnym narzędziem obrony – przyciągają atakujących niczym cyber-pułapki, dając wgląd w ich techniki. Nic dziwnego, że agresorzy starają się je wykrywać i omijać. W tym artykule przyjrzymy się technikom honeypot detection, czyli metodom rozpoznawania czy dany system to prawdziwy cel, czy sprytnie zastawiona pułapka. Omówimy fingerprinting aktywny i pasywny, zdradliwe sygnały (banery, błędy protokołów, cechy stosu TCP/IP, certyfikaty TLS), narzędzia wykorzystywane zarówno przez red team (atakujących) jak i blue team (obrońców) oraz metody obrony honeypotów przed dekonspiracją. Przygotujcie się na techniczne szczegóły, przykłady z narzędzi w stylu curl/nmap oraz konkretne porady gotowe do wdrożenia w labie i produkcji.

Fingerprinting honeypotów

Pierwszym krokiem w wykrywaniu honeypotów jest tzw. fingerprinting – czyli pobranie charakterystycznych „odcisków palca” systemu, które pozwolą go zidentyfikować. Badacze wyróżniają tutaj dwie kategorie: fingerprinting aktywny oraz pasywny, zależnie od tego, czy atakujący aktywnie sondzuje podejrzany system, czy też analizuje dane pasywnie, bez bezpośredniego angażowania celu. Każde podejście ma swoje plusy i minusy, a zaawansowani napastnicy często łączą oba, aby zwiększyć szanse na wykrycie honeypota nie zdradzając przy tym swoich zamiarów.

Fingerprinting aktywny

Fingerprinting aktywny polega na wysyłaniu specjalnie spreparowanych zapytań/prob do celu i obserwacji odpowiedzi. Innymi słowy, atakujący sam generuje ruch sieciowy, by wywołać reakcje mogące zdradzić prawdziwą naturę systemu. Może to przybrać formę skanowania portów i usług, wysyłania niestandardowych pakietów TCP/IP czy nietypowych poleceń protokołów. Narzędzia takie jak Nmap, Xprobe2 czy SinFP3 wykorzystują zestawy sond, by aktywnie zbierać informacje o systemie – np. o jego systemie operacyjnym czy usługach. Active fingerprinting bywa skuteczny, bo umożliwia zebranie szczegółowych danych (banery usług, odpowiedzi na edge-case’y protokołu itp.). Jednakże ma wadę: generowany ruch może zostać wykryty przez honeypot lub systemy IDS, alarmując obrońcę. Mimo to, dla atakującego próbującego rozpoznać pułapkę, aktywne sondowanie jest często warte ryzyka – może ujawnić niekonsekwencje i sztuczność w zachowaniu usług, które normalnie trudno wychwycić.

Przykład aktywnego fingerprintingu: skan FIN – atakujący wysyła pakiet TCP z ustawioną flagą FIN bez wcześniejszego ustanowienia sesji. Normalne systemy zgodne z RFC powinny zignorować taki pakiet dla portu nasłuchującego, ale pewne implementacje (a zwłaszcza niepełne symulacje usług w honeypotach) mogą odpowiedzieć resetem. Taka nieprawidłowa odpowiedź może być czerwoną flagą świadczącą o pułapce. Inny przykład to wysłanie nietypowego ciągu poleceń SMTP lub SSH: prawdziwy serwer może zachować się inaczej niż uproszczona emulacja w honeypocie. W skrócie – aktywny fingerprinting to sztuka zadawania podchwytliwych pytań i analizy, czy odpowiedzi „trzeszczą” fałszem.

Fingerprinting pasywny

Fingerprinting pasywny to podejście bardziej skryte – polega na wykorzystaniu już dostępnych danych o systemie, bez bezpośredniego pobudzania go niestandardowymi bodźcami. Atakujący podsłuchuje ruch lub korzysta z informacji zebranych przez skanery internetowe (np. Shodan, Censys) i stara się z tego wywnioskować prawdę o systemie. Techniki pasywne nie generują własnych pakietów (lub ograniczają je do minimum), przez co są trudniejsze do wykrycia przez ofiarę. Z tego powodu uznaje się, że dojrzały przeciwnik woli najpierw fingerprinting pasywny – dzięki niemu może sprawdzić, z kim ma do czynienia, nie zdradzając swoich intencji.

Klasycznym przykładem fingerprintingu pasywnego jest analiza cech pakietów TCP/IP, które system sam wysyła w normalnej komunikacji. Narzędzia typu p0f nasłuchują ruchu i na podstawie np. TTL początkowego, rozmiaru okna TCP, opóźnień, kolejności opcji itp. próbują określić, jaki system operacyjny generuje dany ruch. Jeśli honeypot udaje Windows, ale pakiety mają „podpis” charakterystyczny dla Linuxa – pasywny fingerprinting to wychwyci. Innym pasywnym wektorem jest sprawdzenie informacji z baz danych skanerów: Shodan posiada usługę Honeyscore, która na podstawie własnych obserwacji przypisuje adresowi IP prawdopodobieństwo bycia honeypotem. Atakujący może zapytać API Shodana o score podejrzanego hosta zanim zaatakuje – nie musząc w ogóle dotykać celu własnymi pakietami. Pasywnie można też analizować certyfikaty TLS, rekordy DNS, metadane – jednym słowem wszystko, co system już ujawnił światu. Choć fingerprinting pasywny jest bezpieczniejszy dla napastnika, to bywa mniej kompletny – stąd często stanowi wstęp, uzupełniany potem aktywnymi testami dla potwierdzenia hipotez.

Wektory i sygnały wykrywania honeypotów

Skoro wiemy już, że atakujący chcą fingerprintować honeypoty, przyjrzyjmy się jakich konkretnie sygnałów szukają. Poniżej omawiamy główne wektory i wskaźniki, które mogą zdradzić, że system jest pułapką. Od oczywistych rzeczy jak dziwne banery usług, po subtelne niuanse stosu TCP/IP czy certyfikatów TLS – diabeł tkwi w szczegółach. Dla każdego punktu podajemy przykłady, jakie nietypowe zachowania może wychwycić doświadczony intruz.

Banery i sygnatury usług

Baner powitalny usługi (np. komunikat serwera SMTP przy połączeniu, ciąg identyfikacyjny serwera FTP/SSH itp.) to często pierwsza rzecz, którą widzi skaner atakującego. Honeypoty, zwłaszcza te niskiej i średniej interakcji, zazwyczaj korzystają z zestawu stałych, zdefiniowanych banerów dla emulowanych usług. Często są one zahardkodowane w kodzie honeypota i mogą nie pasować do rzeczywistych bannerów używanych przez dany soft w prawdziwym systemie. Przykładowo, honeypot udający FTP może zawsze odpowiadać identycznym przywitaniem “220 Welcome” niezależnie od komendy, podczas gdy prawdziwe serwery FTP miewają różne komunikaty. Innym przykładem jest usługodawanie nazwy serwera: honeypot może podawać generyczną nazwę hosta, która nie zgadza się z nazwą domenową czy konwencją nazewniczą sieci – to potrafi zwrócić uwagę. Co sprytniejsi atakujący mają listy sygnatur banerów typowych honeypotów i automatycznie porównują je z otrzymanymi danymi. W literaturze badawczej skompilowano nawet holistyczne listy banerów honeypotów – zebrano znane ciągi znaków wystawiane przez popularne pułapki, by łatwo je identyfikować.

Z praktyki red-teamowej: jeśli skanując sieć Nmapem widzimy host nasłuchujący jednocześnie na nietypowym zestawie portów (np. 21/FTP, 80/HTTP, 445/SMB i 3306/MySQL wszystkie otwarte na jednej maszynie) i każdy z nich zgłasza się “podejrzanie książkowym” banerem – warto zapalić lampkę ostrzegawczą. Realny serwer rzadko udostępnia tak wiele różnych usług naraz, a nawet jeśli, to zwykle w banerach znajdziemy drobne różnice: tu wersja z dystrybucji, tam nazwa hosta w SMTP odpowiadająca domenie itp. Honeypot może nie zadbać o te szczegóły. Podsumowując: jednolity, „sterylny” charakter banerów i niedopasowanie ich do kontekstu systemu (np. wersja SSH na pozór nowa, ale reszta systemu wskazuje na archaiczny OS) jest mocnym sygnałem, że coś jest nie tak.

Nietypowe błędy protokołów

Kolejnym źródłem wskazówek są błędy i zachowanie w warstwie protokołów. Honeypoty często nie implementują pełnej logiki danego protokołu – ich celem jest logować aktywność, a niekoniecznie perfekcyjnie naśladować każdy aspekt usługi. To prowadzi do odchyleń w negocjacji protokołowej. Atakujący, który celowo wprowadzi nietypowe sytuacje, może zaobserwować, że honeypot reaguje inaczej niż prawdziwa usługa.

Jakie odchylenia mogą wystąpić? Badania wykazały m.in. następujące anomalie przy handshake’ach i błędach: honeypoty potrafią akceptować malformowane pakiety, które prawdziwy serwer by odrzucił; oferują ograniczone opcje negocjacji (np. obsługują tylko podzbiór komend protokołu, brak pełnej palety rozszerzeń SMTP/FTP itp.); albo w razie problemu rozłączają sesję z dziwnym, niestandardowym komunikatem błędu. Przykład pierwszy: atakujący celowo wysyła do serwera HTTP nieprawidłowo sformatowany nagłówek żądania. Prawdziwy serwer Apache czy Nginx zapewne odpowie kodem 400 Bad Request z własnym standardowym opisem. Honeypot Glastopf lub inny web honeypot może tymczasem zwrócić inne kodowanie błędu, albo – co gorsza – w ogóle nie zrozumieć sytuacji i np. rozłączyć połączenie bez żadnego komunikatu. Przykład drugi: w protokole SSH podczas wymiany kluczy pewne implementacje serwerów mogą różnie reagować na niezgodności – prawdziwy OpenSSH wypisze stosowny błąd, a honeypotowy serwer Cowrie może np. przerwać sesję w milczeniu. Każda taka niezgodność jest dla atakującego sygnałem: „prawdziwy serwer by tak nie zrobił”.

Co więcej, honeypoty mają zazwyczaj ograniczony zestaw komend – atakujący po zalogowaniu do fałszywej konsoli (np. Telnet/SSH honeypot) może testować dostępność pewnych poleceń systemowych. Jeśli próba użycia ifconfig czy uname -a skutkuje dziwnie okrojonym outputem lub błędem, a inne podstawowe komendy działają, to poważne podejrzenie, że środowisko jest symulowane. Podobnie nietypowe reakcje na sekwencje SMTP (np. brak odpowiedzi na komendę VRFY albo zawsze taki sam timestamp w nagłówkach) mogą wskazać na emulację usługi, nie prawdziwy serwer pocztowy.

Krótko mówiąc: chaotyczne lub niezgodne ze specyfikacją błędy i „zachowanie nie z tej ziemi” w komunikacji protokołowej często obnażają honeypot. Dla obrońców jest to trudny orzech do zgryzienia – odtworzyć wszelkie subtelności protokołów – ale o metodach zaradczych powiemy w dalszej części.

Charakterystyka stosu TCP/IP

Każdy system operacyjny ma swój unikalny „akcent” w sposobie, w jaki prowadzi komunikację sieciową. Mówimy tu o parametrach stosu TCP/IP: początkowe wartości TTL, wielkość okna, kolejność i zawartość opcji TCP (MSS, WSCALE, timestamps), ID pakietów IP, sposób generacji numerów sekwencyjnych itd. Zaawansowane narzędzia OS fingerprinting (np. wspomniane p0f, Nmap -O, SinFP3) wykorzystują te detale, by zidentyfikować system – i to samo czyni atakujący, by zweryfikować honeypot. Problem w tym, że honeypoty niskiej interakcji często działają na jednym systemie (np. Linux) udając inny (np. Windows), a ich stos TCP/IP zdradza prawdziwą tożsamość.

Jeśli honeypot nie podjął środków maskujących, to atakujący wykonując nawet proste pasywne testy może zauważyć rozbieżności. Przykładowo: host przedstawia się jako Windows Server 2016 (baner SMB czy RDP to sugeruje), ale pakiety SYN+ACK z tego hosta mają TTL=64 i window size=5840 – wartości typowe dla Linuxa (Windows zazwyczaj TTL=128, inne rozmiary okien). Taka niekonsekwencja to strzał w kolano dla honeypota. Inny przykład: kolejność opcji TCP. Systemy z rodziny Linux często układają opcje TCP w pakiecie w określonej kolejności (np. MSS, Window Scale, SACK, Timestamps), a Windows w nieco innej kolejności. Jeśli honeypot nie zmieni domyślnego zachowania stosu, te różnice wyjdą w analizie p0f. Literatura wskazuje, że parametry jak domyślny TTL, długość i kolejność opcji TCP, a nawet wartości pól ID czy czasów retransmisji stanowią unikalny identyfikator stosu danej rodziny OS. Atakujący dysponując bazą takich sygnatur (a Nmap czy SinFP mają obszerne bazy) błyskawicznie sprawdzi, czy „Windows” na porcie 445 to faktycznie Windows czy np. Dionaea na Linuksie.

W kontekście honeypotów, ciekawą sztuczką jest też sprawdzanie spójności stosu TCP/IP między usługami. Jeżeli host udaje mix systemów (np. na porcie 80 podszywa się pod Apache/Linux, a na 3389 pod Windows Server), to i tak wszystkie pakiety wychodzą z jednej maszyny – więc ich niskopoziomowe cechy będą identyczne. Atakujący może to zauważyć: pakiety z portu 80 i 3389 mają ten sam TTL i order opcji – co jest mało prawdopodobne, gdyby to były dwa różne serwery (IIS na Windows vs Apache na Linuxie). Taki „fingerprint drift” między usługami jasno wskazuje, że to jedna platforma symuluje różne systemy.

Podsumowując: charakterystyka stosu TCP/IP jest jak odcisk palca systemu. Honeypot, który nie ukryje swojego odcisku, łatwo wpadnie w ręce narzędzi OS fingerprinting. Sztuką obrońców jest albo maskować te cechy, albo iść w high-interaction (rzeczywisty system) – do tego wrócimy w sekcji obrony.

Certyfikaty TLS i metadane

Współczesne usługi często używają szyfrowania TLS – a to kolejna okazja do fingerprintingu. Certyfikaty X.509 wystawiane przez honeypoty bywają generowane automatycznie lub wręcz dostarczone „fabrycznie” z honeypotem, przez co mogą mieć powtarzalne cechy. Przykładem jest honeypot Dionaea: badacze wykryli, że we wszystkich domyślnych instancjach Dionaea, certyfikat używany do nasłuchu SSL ma ten sam issuer (wystawcę) i te same pola podmiotu. To oznacza, że skanując Internet pod kątem tego konkretnego ciągu znaków w certyfikacie (np. nazwie organizacji), można wprost wypunktować wszystkie serwery Dionaea udające SSL – co zresztą zrobiono. Shodan i inni potrafią tagować hosty na tej podstawie. Dla atakującego to banalny test: pobrać certyfikat z podejrzanego serwera (np. komendą openssl s_client) i porównać do znanych sygnatur honeypotów.

Metadane TLS to nie tylko certyfikat, ale i parametry negocjacji. Prawdziwe serwery mają często unikalne preferencje co do zestawów szyfrów, wersji protokołu, opcjonalnych rozszerzeń TLS. Honeypot może korzystać z innej biblioteki TLS niż oryginalny system – co widać w tzw. TLS fingerprint (tj. charakterystyce listy cipher suites, TLSExtensions itp.). Świeży przykład: honeypoty RDP (protokołu Windowsowego) implementowane w Pythonie/Go nie korzystają z natywnej biblioteki SChannel Windows, tylko np. OpenSSL – w efekcie proponują zestaw szyfrów typowy dla OpenSSL, niepokrywający się z tym, co oferowałby prawdziwy Windows RDP. Skany pokazały, że wiele rzekomych serwerów RDP z Windows 10 tak naprawdę zdradza się handshake’em TLS – „mówią” nie tym dialektem co powinny.

Inny przykład metadanych: domeny i nazwy hostów. Produkcyjne systemy często mają sensowne nazwy (np. mail.firma.pl w certyfikacie, rekordy DNS), a honeypoty – nie zawsze. Jeśli certyfikat przedstawia nazwę hosta zupełnie niepowiązaną z żadną domeną, albo co gorsza CN=honeypot (bywały i takie wpadki), to oczywiście mamy sprawę jasną. Również Fully Qualified Domain Name (FQDN) użyte w konfiguracji honeypota może być wyśledzone – np. honeypot rejestrujący w DNS nazwę z nietypową domeną techniczną, której normalnie urządzenie ICS by nie miało. W badaniach sugeruje się nawet sprawdzanie, czy urządzenie ICS (np. przemysłowy sterownik) ma domenę w publicznym DNS – bo jeśli tak, to raczej jest to honeypot, w prawdziwych środowiskach ICS urządzenia nie mają publicznych FQDN.

Podsumowując: warstwa TLS i metadanych to bogate źródło sygnałów. Powtarzalne certyfikaty, nienaturalne parametry TLS (fingerprint TLS niezgodny z deklarowanym systemem), czy dziwne informacje o hoście – wszystko to może wywołać alarm u atakującego. Obrona wymaga tu uwagi: unikać domyślnych certów, dopasować konfigurację TLS do udawanego systemu, a nawet generować losowe, unikatowe parametry per instancja honeypota, by nie było globalnej sygnatury. O tym więcej za chwilę.

Narzędzia do wykrywania honeypotów

Skuteczne wykrycie honeypota wymaga wiedzy, ale też sprytu i automatyzacji. Dlatego powstały liczne narzędzia wspierające fingerprinting – niektóre to ogólne skanery i sniffery, inne wręcz dedykowane honeypot detection. Przyjrzyjmy się kilku z nich, które powinny znaleźć się w arsenale zarówno ofensywnych, jak i defensywnych specjalistów bezpieczeństwa:

SinFP3

SinFP3 to zaawansowane narzędzie OS fingerprinting nastawione na skuteczność nawet w trudnych warunkach. Zostało zaprojektowane w odpowiedzi na ograniczenia Nmap – tak, by zidentyfikować system operacyjny nawet gdy mamy do dyspozycji tylko jeden otwarty port i minimalną komunikację. SinFP (obecnie wersja 3) wykorzystuje zaledwie trzy specjalne pakiety TCP do wysondowania celu. Pierwsze dwie sondy to zwykłe żądania SYN (różniące się jednak ustawieniami opcji TCP), trzecia sonda to nietypowy pakiet SYN+ACK oczekujący wymuszenia odpowiedzi RST. Otrzymawszy trzy odpowiedzi od celu, SinFP buduje z nich sygnaturę i porównuje z bazą znanych fingerprintów OS. Podejście to sprawia, że SinFP3 radzi sobie tam, gdzie Nmap może polec – np. gdy firewall przepuszcza tylko jeden port. W przeciwieństwie do Nmap, SinFP nie potrzebuje bombardować celu 16 różnymi pakietami; działa niczym strzelec wyborowy, a nie strzelba śrutowa.

Dla wykrywania honeypotów SinFP3 jest użyteczne, bo pozwala szybko zweryfikować OS maszyny. Jeśli nasz cel deklaruje się jako Windows, a SinFP na podstawie 3 pakiecików melduje 95% pewności na Linux 3.x – cóż, wiemy z czym mamy do czynienia. Warto dodać, że SinFP3 został pomyślany jako “noiseless” skaner – trzy pakiety to mało, trudniej je wyłapać w IDS. A jednak potrafią przynieść dużo informacji: analizuje się parametry IP i TCP odpowiedzi (TTL, okno, flagi, kolejność opcji – o czym była mowa przy TCP/IP stack) i na tej podstawie profiluje OS. SinFP3 jest dostępny jako samodzielne narzędzie oraz jako plugin np. do Nessusa. Dla obrońcy honeypota to przeciwnik, którego warto znać – w dalszej części opowiemy, jak można próbować go oszukać (patrz: manipulacja TTL/okien).

Xprobe2

Xprobe2 to alternatywne narzędzie aktywnego fingerprintingu OS, które obrało inną filozofię niż Nmap. Jego twórcy (Ofir Arkin i in.) skupili się na ICMP jako głównym nośniku informacji o systemie. Xprobe2 powstał jako wynik badań “ICMP Usage in Scanning” i korzysta z pakietów ICMP oraz kilku kontrolowanych pakietów TCP/UDP, by zidentyfikować system. Cechą charakterystyczną Xprobe2 jest logika rozmyta (fuzzy matching): zamiast ścisłego dopasowania do sygnatury, oblicza on podobieństwa i z pewnym prawdopodobieństwem wskazuje najbardziej pasujący system. Takie podejście jest odporniejsze na drobne odchylenia spowodowane np. firewallami czy nietypową konfiguracją.

Xprobe2 uchodzi za “cichszego” skanera niż Nmap – generuje niewiele pakietów i stara się używać jedynie „legalnych” kombinacji (poza ewentualnymi przekłamanymi sumami kontrolnymi). Dzięki temu jest trudniejszy do wykrycia przez IDS/IPS i świetnie nadaje się do fingerprintingu w warunkach, gdy cele są silnie filtrowane. Co więcej, Xprobe2 bywa skuteczniejszy tam, gdzie Nmap się gubi – np. przy braku otwartych portów na celu. W takich sytuacjach Nmap może nie zebrać danych do fingerprintingu, a Xprobe2 dzięki ICMP echo i analizie odpowiedzi IP może wskazać system. Jedynym minusem jest to, że Xprobe2 nie był od dawna intensywnie rozwijany (ostatnia większa aktualizacja około 2005 r.). Niemniej, wciąż doskonale spełnia swoją rolę w rękach red-teamu. Z punktu widzenia honeypota – trzeba pamiętać, że pasywne podejście obronne (typu „udaję, że nic nie widzę”) tu nic nie da, bo Xprobe2 naszpikowany jest sprytem i czeka na najmniejszy fałszywy krok stosu IP.

p0f

p0f to kultowe narzędzie pasywnego fingerprintingu stworzone przez Michała Zalewskiego. Nie wysyła ono żadnych pakietów – zamiast tego podsłuchuje ruch i rozpoznaje systemy operacyjne na podstawie tego, jakie pakiety inicjujące połączenia do nas docierają. p0f analizuje głównie pierwsze pakiety TCP (SYN) od zdalnych hostów: patrzy na rozmiary segmentów, flagi, opcje TCP, TTL itd., porównując z obszerną bazą sygnatur. Oryginalnie służyło administratorom do identyfikacji kto się z nimi łączy (np. czy atakujący to Windows XP czy Linux), ale oczywiście nic nie stoi na przeszkodzie, by atakujący użył p0f w odwrotną stronę – do analizy pakietów od naszego serwera honeypot.

Jeśli atakujący ma możliwość zobaczyć pakiety np. z naszą odpowiedzią SYN+ACK (co może osiągnąć np. inicjując połączenie i obserwując je wiresharkiem u siebie), to p0f powie mu „system X odpowiada”. W typowym scenariuszu: atakujący łączy się do naszej usługi (np. telnet honeypot), dostaje SYN+ACK od serwera. On nie musi nawet kończyć handshake, wystarczy ten jeden pakiet – p0f wskaże, że to np. Linux 5.x, a nie deklarowany Cisco IOS 😉. p0f jest diabelnie skuteczny i bardzo trudny do wykrycia, bo nie zostawia żadnych śladów – nie generuje ruchu. Honeypot nie „widzi”, że jest fingerprintowany, bo wszystko dzieje się po stronie atakującego. To dlatego manipulacja parametrami stosu TCP/IP (TTL, okno etc.) jest kluczowa dla obrony: p0f wychwyci najmniejsze niezgodności. W sekcji obronnej wspomnimy, że są sposoby by go oszukać (badacze z CERN pokazali, że zmiana TTL i window potrafi zmylić p0f), ale trzeba o tym świadomie pamiętać.

Podsumowując, p0f to cichy zabójca honeypotów: zero podejrzanego ruchu, a może ujawnić całą prawdę. Każdy budujący honeypot musi założyć, że prędzej czy później ktoś jakimś p0f-em spojrzy na jego pakiety.

Nmap

Nmap to klasyka, której nie trzeba przedstawiać. To wszechstronny skaner, który w kontekście honeypotów służy dwojako: po pierwsze jako narzędzie wykrywające otwarte porty i usługi, po drugie – dzięki swoim zaawansowanym skryptom – może rozpoznać znane honeypoty. Standardowy OS fingerprinting w Nmap (opcja -O) wykorzystuje kilkanaście różnych prob (TCP, UDP, ICMP) i analizuje dziesiątki pól odpowiedzi, generując sygnaturę systemu. Zwykle Nmap radzi sobie dobrze z odróżnieniem przynajmniej rodziny OS, o ile nie stoi mu na drodze coś nietypowego (np. kilka warstw NAT/IPS mogą zamieszać). Ale Nmap to nie tylko OS – to także skrypty NSE. Istnieją NSE scripts dedykowane wykrywaniu konkretnych honeypotów. Przykładowo, dla starego trojana NetBus istniał honeypot o nazwie NetBuster, i Nmap ma skrypt netbus-version rozpoznający, czy usługa to prawdziwy NetBus czy NetBuster-honeypot właśnie (na podstawie niuansów protokołu). Podobnie społeczność dostarczała skrypty np. do wykrywania Kippo/Cowrie (honeypot SSH) – np. wysyłające specyficzne sekwencje by sprawdzić, czy to realny SSH czy imitacja z ograniczonym zestawem komend.

Nmap może więc wprost powiedzieć „uważaj, to Kippo honeypot” jeśli mamy odpowiedni skrypt. Ale nawet bez tego, uważny operator Nmapa zanalizuje wyniki skanowania pod kątem niespójności: wspomniane zestawy portów, banery, wersje usług vs. OS, latencje. Czasami samo pole „Device type” w wyniku OS fingerprintingu Nmap potrafi wskazać „Generic IDS device” zamiast np. „general purpose”, co bywa tropem (bo honeypot to de facto sensor). W codziennej pracy red teamu, Nmap jest często pierwszym narzędziem, które da sygnał „coś tu pachnie jak honeypot” – i wtedy do gry wchodzi cięższa artyleria jak p0f, SinFP etc. Dla blue teamu warto wiedzieć, że honey-potowe wpadki są dobrze znane społeczności i szybko trafiają jako sygnatury do Nmap/NSE – stąd ważne, by honeypot po wdrożeniu przeskanować samemu Nmapem i zobaczyć, co on tam „wywęszy”.

Nessus

Nessus to popularny skaner podatności, używany głównie przez blue team (audytorów, pentesterów). Choć jego głównym celem jest znajdowanie dziur, przy okazji wykonuje on pewne fingerprinting systemu w ramach skanowania. Warto o nim wspomnieć, bo bywa używany przez atakujących do profilowania systemów (choć rzadziej, bo jest dość hałaśliwy). Nessus posiada pluginy do rozpoznawania OS – m.in. wykorzystuje SinFP oraz własne metody (ICMP, SMB, SNMP itp.) i podaje w raporcie listę pasujących systemów z Confidence Level. Może np. wyświetlić: „Remote host is running Linux Kernel 2.4, Confidence 70% (method: SinFP)”. Z punktu widzenia honeypotów ciekawsze jest jednak jak Nessus wykrywa podatności: niemal całkowicie polega on na bannerach i wersjach usług. Jeśli w banerze Apache widnieje „Apache 2.4.1”, a baza Nessusa mówi że wersje ≤2.4.2 są podatne na XSS, to Nessus zgłosi podatność. Jeżeli honeypot celowo zmieni baner na „Apache 2.4.99”, Nessus nic nie znajdzie – da się go oszukać bardzo łatwo tym sposobem. Dla atakującego ta informacja też jest cenna: jeżeli skanując potencjalny honeypot Nessusem okaże się, że host wygląda w 100% „fully patched, zero vulnerabilities”, a jednocześnie ma mnóstwo usług – może to być podejrzane. Realne systemy rzadko są idealnie w łatane i jeszcze oferują tyle punktów wejścia.

Z drugiej strony, sprytny honeypot może celowo wystawiać parę fałszywych podatności (np. stary numer wersji w banerze), by wydać się bardziej przekonujący. Tak czy inaczej, Nessus uczy nas, że honeypot który jest zbyt czysty i spójny wersjami, może wyglądać nierealistycznie. Blue team powinien to przemyśleć – wprowadzanie lekko dziurawych komponentów (kontrolowanych!) może podnieść wiarygodność wabika.

Z perspektywy ataku – Nessus jest raczej bronią obosieczną (skanując cudzy system robi się dużo hałasu), ale bywa używany by szybko zebrać profil. Nie znamy dedykowanych „honeypot detection” modułów w Nessusie, ale niektóre policy checki (np. sprawdzanie obecności domyślnych kont, default passów) mogą mimowolnie wykryć honeypot, jeśli twórca zostawił defaultowe dane (jak konto root:!HoneyPot). Warto więc i Nessusa wymienić: jeśli on coś powie „hmm to dziwne”, na pewno warto się przyjrzeć.

Shodan Honeyscore

Na koniec nie sposób pominąć usług OSINT-owych. Shodan Honeyscore to mechanizm stworzony przez Shodan (wyszukiwarkę urządzeń w Internecie) specjalnie do oceniania, czy dany host to honeypot. Użytkownik z kluczem API może zapytać Shodan o wynik – dostaje score od 0.0 do 1.0, gdzie 1.0 oznacza „to na pewno honeypot”. Shodan niestety nie ujawnia dokładnie jak liczy ten wynik (to ich przewaga konkurencyjna), ale wiadomo, że korzysta z szeregu heurystyk: m.in. sprawdza, czy serwis wygląda na zbyt pusty (np. porty otwarte, ale brak normalnej aktywności), czy konfiguracja usług nie jest zbieżna z known honeypot default, czy host nie reaguje jak znane implementacje honeypotów. Ponadto Shodan integruje już tagi honeypot w wynikach – można wyszukiwać urządzenia z tagiem honeypot.

Dla atakującego Honeyscore to szybka podpowiedź – np. wynik 0.8 oznacza „lepiej odpuść, bo prawdopodobnie to pułapka”. Dla obrońcy to z kolei punkt kontrolny: warto samemu sprawdzić honeypot w Honeyscore. Jeżeli nasz dopieszczany Dionaea dostaje 0.9, to znak, że gdzieś jest oczywisty mankament. Usunięcie go powinno obniżyć score. Oczywiście Honeyscore nie jest nieomylny ani ciągły (to raczej API testowe Shodana), ale i tak wbiło się do toolsetu społeczności. Ba, powstały nawet moduły do Metasploita wykorzystujące Honeyscore do automatycznego filtrowania celów. Atakujący zintegrowany z OSINT przed zaatakowaniem firmy może przesiać jej adresy IP i usunąć z listy ataku te, które wyglądają na honeypoty. To kolejny powód, by honeypot bronić tak, aby nie był oczywistym honeypotem (bo wówczas może nie zostać zaatakowany, a przecież chcemy złapać przeciwnika).

Reasumując: Shodan Honeyscore to narzędzie, które demaskuje słabe honeypoty hurtowo. Warto o nim pamiętać, zarówno planując atak (uważaj na high-score hosty), jak i stawiając obronę (dopilnuj, by Twój honeypot nie miał zbyt wysokiego score).

Co zdradza popularne honeypoty?

Przejdźmy od teorii do konkretnych przykładów. Omówimy pokrótce typowe cechy zdradzające sześć popularnych honeypotów. Każdy z nich – mimo że starannie zaprojektowany – ma swoje znane “tell-tale signs”, które doświadczony przeciwnik może wychwycić. Ta wiedza przyda się zarówno atakującym (wiedzą, na co uważać), jak i obrońcom (wiedzą, co poprawić/ukryć w swoich instancjach).

Dionaea

Dionaea to low-interaction honeypot służący głównie do kolekcjonowania malware. Emuluje całą gamę usług (SMB, FTP, HTTP, MySQL, TFTP, SIP i inne) w podatnych wersjach, licząc że robaki same się do niego skopiują. Co może zdradzić Dionaeę?

Po pierwsze, nienaturalna kombinacja otwartych portów. Dionaea domyślnie nasłuchuje na wielu portach jednocześnie (SMB/445, FTP/21, HTTP/80, MySQL/3306 itd.). Taki “wszechstronny” serwer nieczęsto występuje w przyrodzie. Atakujący skanując hosta i widząc, że jest on jednocześnie serwerem Windows SMB, Linuxowym FTP i jeszcze bazą danych, może nabrać podejrzeń. Oczywiście, da się to zamaskować (np. odpalać Dionaeę tylko z wybranymi serwisami w danym deployment), ale default często kusi by mieć wszystko na raz – a to ryzykowne.

Druga sprawa – banery i zachowanie usług. Dionaea stara się emulować podatne usługi, ale często w dość uproszczony sposób. Jego SMB może np. zawsze zgłaszać ten sam Domain Name, niezależnie od tego u kogo stoi. FTP serwer może mieć bardzo ograniczone komendy (np. nie obsługuje LIST poza root, albo pokazuje identyczny listing na każde polecenie). Takie powtarzalne zachowanie, jeśli atakujący je rozpozna, pozwala na identyfikację honeypota.

Najbardziej znanym “signature” Dionaei jest jej certyfikat TLS. Dionaea wykorzystuje bibliotekę OpenSSL do obsługi TLS dla swoich usług (np. FTPS, HTTPS) i posługuje się domyślnie wygenerowanym certyfikatem. We wszystkich instancjach Dionaea (o ile admin sam nie podmieni certyfikatu) pojawia się certyfikat o tych samych polach issuer/subject. Badacze to namierzyli i dzięki temu jednym skanem TLS w Internecie wykryli tysiące honeypotów Dionaea. Jeśli atakujący trafi na host, gdzie np. port 443 jest otwarty i ten certyfikat wygląda podejrzanie (np. issuer “Dionaea Certificate” – tu już twórcy popełnili gafę jeśli takie coś wpisali), to sprawa jasna. W nowszych wersjach raczej takich oczywistych stringów nie ma, ale i tak powtarzalność certów jest fatalna. W obronie koniecznie generuj unikalny cert dla każdej instancji Dionaea albo – lepiej – użyj prawdziwego certyfikatu (choćby self-signed, ale z własnymi danymi).

Trzecia sprawa – telemetria i HPFeeds. Dionaea często jest wdrażana z systemem raportowania HPFeeds (honeypot feeds). Jeśli atakujący miałby wgląd np. w ruch wychodzący i zobaczy, że host komunikuje się z jakimś znanym kolektorem HPFeeds – bingo, to pułapka (choć to dość mało prawdopodobny wektor, bo atakujący musiałby sniffować nasz ruch).

Podsumowując, Dionaea zdradza: za dużo usług na raz, powtarzalne sygnatury (certyfikat TLS), ograniczone emulacje protokołów. Warto dodać, że projekt nie jest już tak żywo rozwijany – co oznacza, że znane fingerprinty nie są usuwane zbyt szybko. Trzeba to zrobić samemu (patrz sekcja obrona).

Cowrie

Cowrie to bardzo popularny honeypot udający shell dostępowy (SSH/Telnet). Wywodzi się z projektu Kippo. Działa tak: atakujący loguje się (Cowrie pozwala użyć z góry określonych loginów/haseł, np. root:1234), po czym dostaje fałszywy system plików i powłokę do interakcji – oczywiście wszystko co wpisze jest logowane. Cowrie to honeypot średniej interakcji: daje atakującemu namiastkę prawdziwego systemu, ale nie jest to pełna maszyna.

Co może pójść nie tak? Otóż stale to samo środowisko może zostać rozpracowane przez atakujących. Z czasem zauważono, że boty i ludzie rozpoznają Cowrie/Kippo po pewnych stałych elementach. Najbardziej znany case dotyczył domyślnego użytkownika „richard” obecnego w przykładzie pliku passwd w Cowrie. W starszych wersjach honeypota w symulowanym /home istniał użytkownik richard (zostawiony przez twórców jako ciekawostka). Okazało się, że botnety zaczęły automatycznie sprawdzać obecność tego katalogu, by wykryć honeypot! Wystarczyło, że skrypt po zalogowaniu wykonuje ls /home i patrzy, czy widzi „richard” – jeśli tak, to „GOTCHA” i bot przerywał działania. W repo Cowrie zgłoszono ten problem i zalecono usunięcie owego wpisu lub jego losową zmianę, ale fakt pozostaje: statyczny wskaźnik zdradził setki honeypotów.

Kolejna sprawa to ograniczony zestaw komend i dziwne odpowiedzi. Cowrie nie symuluje całego Linuxa, tylko prosty filesystem i kilka poleceń. Atakujący może to rozkminić: np. komenda uname -a zawsze zwraca tę samą przyhardkodowaną wartość (podczas gdy w prawdziwym systemie data kompilacji kernela, nazwa hosta itp. różnią się między maszynami). ifconfig może być niekompletne albo w ogóle niedostępne. Nie ma procesów (polecenie ps może pokazać tylko samego siebie, co nienaturalne). Lista użytkowników jest uboga. Te nienaturalne ograniczenia sprawiają, że wprawny intruz po paru komendach już „czuje plastik” zamiast prawdziwego systemu. Co gorsza, niektórzy atakujący specjalnie uruchamiają pewne sekwencje (widziano malware, które np. tworzy plik i usuwa go, sprawdza uptime, wykonuje nietypowe ruchy myszką po RDP itp.) by zobaczyć, czy system faktycznie reaguje jak realny. Cowrie tu dość łatwo obnażyć, bo np. nie ma pełnego kernela – więc nie obsłuży prawdziwych binarek CPU (każde wget czy gcc jest udawane). Gdy malware spróbuje się uruchomić, po prostu nie zadziała – i może to wykryć.

Inny sygnał to powtarzalny fingerprint SSH. Cowrie domyślnie przedstawia się jako jakiś tam „SSH-2.0-OpenSSH_7.4” itp., ale klucz hosta RSA będzie zawsze ten sam (jeśli admin go nie zmieni). Atakujący skanując masowo może zauważyć, że wiele IP ma identyczny klucz SSH hosta – co jest statystycznie praktycznie niemożliwe, chyba że to sklonowane honeypoty. Pojawiły się nawet listy takich kluczy w darknecie.

Cowrie może też zdradzić opóźnienie – często działa w Pythonie na Twisted, więc interakcja bywa nieco wolniejsza i mniej płynna niż prawdziwy bash. Atakujący czując lag przy prostych ls może podejrzewać, że to logowanie, proxying itp.

Podsumowanie: Cowrie zdradzają stałe elementy (katalogi, userzy), ubogi zestaw komend, powtarzalne odpowiedzi i klucze. Dobrą praktyką jest mocno zmodyfikować domyślną konfigurację: pozmieniać domyślne nazwy, dodać losowości (np. generować dynamicznie pliki, daty modyfikacji różne), a nawet co jakiś czas „przetasować” filesystem. Bo stary, niewariujący honeypot szybko staje się rozpracowany przez boty (i nie złapiemy nic nowego).

Glastopf

Glastopf to low-interaction honeypot webowy – udaje serwer WWW z masą podatności (RFI/LFI, SQLi, uploady itd.). Jego koncepcja to nie symulować całego frameworka, tylko reagować na próby exploitów webowych: np. jak ktoś próbuje ataku SQL injection, Glastopf generuje stronę, która wygląda jakby faktycznie baza danych wywaliła błąd SQL (żeby zadowolić atakującego). Podejście sprytne, ale Glastopf ma pewną bolączkę: statyczne szablony stron. W standardowej konfiguracji serwuje zawsze bardzo podobne treści – np. prosty index, kilka podstron z zestawu. Gdy atakujący trafi na kilka instancji Glastopfa, zauważy powtarzalność schematu. Co gorsza, długo nic nie zmieniało się w wyglądzie tych stron. W efekcie, jak stwierdzono w pewnej pracy badawczej, „Glastopf może być łatwo rozpoznany przez atakujących z uwagi na prostotę i statyczność szablonów stron”.

Innymi słowy: inteligentny atakujący (np. botnet prowadzony przez kogoś sprytnego) może przed wykonaniem ataku wejść na takiego hosta przeglądarką/HTTP i obejrzeć stronę. Jeśli widzi tę samą ubogą stronę z generatorem „vuln” co już widział gdzie indziej – odpuszcza atak, bo to honeypot. Ponadto, Glastopf domyślnie nie hostuje prawdziwych zasobów (obrazków, skryptów) – strony są dość puste. Dla człowieka to sygnał „hmm, strona niby wygląda legit, ale jakby wydmuszka”. Prawdziwe strony web mają mnóstwo plików, cssów, ciasteczek – honeypot może być minimalistyczny.

Kolejna rzecz: mechanizm odpowiedzi na ataki. Glastopf generuje odpowiedzi takie, jakich atakujący oczekuje. Ale jeśli ktoś spróbuje normalnego przeglądania strony, to może dostrzec, że są tam np. linki do znanych podatnych skryptów (w ramach wabika), które wszędzie prowadzą do czegoś prostego. Albo że serwer odgrywa błąd za każdym razem z tym samym timestampem – bo szablon błędu SQL jest stały. Dla bystrego oka – sygnał.

Wreszcie, podobieństwo między instancjami: Glastopf rozprowadzany był z zestawem tych samych domyślnych stron (chyba jakiejś aplikacji w PHP stylizowanej). Jeśli wielu ludzi tego nie zmieniło, to Google mogło zaindeksować powtarzalne fragmenty. Wystarczy, że atakujący znajdzie w Google unikalny fragment tekstu z takiej strony – i wyskoczy mu list wszystkich hostów z Glastopfem.

Reasumując: Glastopf zdradza statyczna, powtarzalna natura stron, brak dynamiki. Badacze proponowali poprawę tego poprzez generowanie dynamicznych, zmiennych stron (coś jak losowy content) żeby utrudnić fingerprinting. To zresztą część filozofii Moving Target Defense – do czego wrócimy.

Na marginesie: nowsze projekty, jak Telerabbit czy Dionaea HTTP moduł, częściowo zastąpiły Glastopf. Jednak zasada ta sama: if (page.template == static) then fingerprint++. Obrońcy powinni zadbać, by ich web honeypot nie był klonem tysięcy innych.

Conpot

Conpot to honeypot udający systemy przemysłowe (ICS/SCADA) – np. sterowniki PLC, panele HMI itp. W związku z tym, że prawdziwe systemy ICS rzadko siedzą otwarte w Internecie, Conpot często jest łatwy do wykrycia kontekstowo. Jak wspomnieliśmy przy TLS, jeśli atakujący znajdzie w Shodanie np. port 102 (Siemens S7) otwarty na serwerze w chmurze AWS – prawie pewne, że to honeypot. Realne sterowniki PLC nie działają na Amazon EC2 😉. I faktycznie, atakujący wykorzystują tę heurystykę: „PLC w chmurze = 99% honeypot”. Badacze zalecają wręcz nie wystawiać Conpota z adresów oczywiście chmurowych, bo to się rzuca w oczy.

Drugą sprawą są identyfikatory urządzeń i dane przemysłowe. Conpot ma zestaw gotowych profili symulujących np. stację elektryczną czy system HVAC. Te profile mają nazwy urządzeń, rejestry, wartości – jeśli ktoś odpali wiele Conpotów bez zmian, wszystkie mają np. ten sam Device Name albo te same wartości rejestrów na starcie. To znów powtarzalny fingerprint. Napastnik, który raz rozgryzie taki profil, może go wykryć gdziekolwiek indziej, jeśli nie zmodyfikowano ustawień. Np. Conpot ma domyślny template udający Siemens S7-200 PLC o określonym Model ID. Jeśli kilkanaście IP na świecie zgłasza identyczny Model ID i konfigurację, to możliwe że to klony Conpota – prawdziwe urządzenia miałyby różne wersje firmware, serie, itp.

Kolejny trop – reakcja na protokół. Conpot obsługuje m.in. Modbus, BACnet. Są narzędzia do fingerprintingu takich protokołów (np. Modbus palcuje wersję sterownika). Conpot, będąc emulacją, może nie implementować wszystkiego: np. odpowie na podstawowe zapytania, ale już bardziej zaawansowane funkcje (których w template nie przewidziano) zignoruje albo zwróci błąd. Prawdziwy sterownik mógłby np. odpowiedzieć Exception Code X, a Conpot w ogóle się rozłączy. Jeśli atakujący jest obeznany z protokołem, takie nietypowe zachowanie go naprowadzi.

Wreszcie, dane dodatkowe: ICS-y często mają panele webowe, SNMP, inne oznaki integracji. Conpot raczej tego nie replikuje (chyba że celowo skonfigurujemy). Sam fakt, że system wygląda jak tylko PLC i nic więcej może być podejrzany – w realu ten PLC miałby pewnie jakieś towarzyszące urządzenia, kamery, cokolwiek w okolicy.

Podsumowanie: Conpot (i honeypoty ICS ogólnie) są wykrywane głównie po niespójności z typowym środowiskiem ICS. Wystawiony w Internecie samotny sterownik z defaultowymi parametrami to “red flag”. Ciekawostka: powstały honeypoty ICS które walczą z tym – np. projekt Gazpot generował losowe parametry baku paliwa, by każdy instance był inny. To dobry kierunek, bo czyni fingerprinting trudniejszym.

RDPY

RDPY to open-source honeypot implementujący protokoł RDP (Remote Desktop) w Pythonie. Skoro udaje RDP, to z reguły ma symulować Windowsowy serwer Terminal Services. Niestety, RDPY ma dwie słabości, które wypunktowali badacze:

Po pierwsze, nie używa oryginalnego stosu TLS Windows (SChannel), tylko OpenSSL (przez Twisted). W praktyce oznacza to, że TLS handshake RDP jest inny niż normalnie w Windows. Jak już wspomniano, wykryto wiele hostów, które niby mówiły „tu Windows, zapraszam po RDP”, ale ich zachowanie TLS wskazywało na OpenSSL – i rzeczywiście okazały się RDPY honeypotami. Więc atakujący może to wykryć w ten sposób (wystarczy spojrzeć na listę Cipher Suites w Wiresharku – Windows ma specyficzne preferencje, np. mocno promuje szyfry z RC4 lub AES, a OpenSSL inny zestaw). Trudno to honeypotowi zmienić, bo to dość nisko poziomowa różnica.

Druga rzecz – RDPY daje atakującemu pełen ekran logowania Windows (statyczny), ale… no właśnie, jest to zawsze ten sam obraz (chyba Windows 8/10, jak zanotowano) i nic więcej się nie da zrobić. Atakujący może zauważyć, że: (a) może się logować dowolnymi danymi i zawsze wygląda to tak samo (brak realnej weryfikacji poza przyjęciem hasła do loga), (b) np. po zalogowaniu (jeśli w ogóle następuje jakaś namiastka sesji) nic nie można zrobić. RDPY pewnie kończy połączenie gdy zebrał hasło. Według badań, RDPY po uwierzytelnieniu po prostu pokazuje nagrany wcześniej fragment sesji (replay), np. pulpit który się nie zmienia, co bywa dziwne.

Trzeci trop – zachowanie przy rozłączaniu. Okazuje się, że normalny Windows RDP jak zamykamy sesję może wysyłać RST, a RDPY np. grzecznie FIN (albo odwrotnie). Jeśli atakujący to przeanalizuje, zobaczy różnicę.

Czwarty – certyfikat TLS. Wielu operatorów RDPY pewnie nie zmienia domyślnego certyfikatu, więc może być powtarzalny (podobnie jak z Dionaea czy Heralding). Certyfikaty RDP normalnych serwerów bywają różne (np. samopodpisane z nazwą hosta). Jak kilka honeypotów ma identyczny CN, to znowu słabo.

Generalnie RDPY honeypot jest fingerprintowalny i badanie z 2022 roku wykryło przeszło 1123 instancje RDPY w Internecie właśnie metodą fingerprintingu aktywnego. Co ciekawe, zaobserwowano też, że atakujący (bruteforcerzy RDP) unikają tych instancji – czyli fingerprinting RDPY jest już w arsenale botnetów (widząc pulpit/honeypot – porzucają próbę bardzo szybko).

Heralding

Heralding to inny honeypot obsługujący protokoły uwierzytelnienia (RDP, VNC, FTP, SSH, etc.) – celem jest zebrać loginy/hasła. Skupmy się na RDP, bo tu jest on porównywany z RDPY.

Heralding różni się tym, że w ogóle nie stara się dać atakującemu sesji graficznej – kończy połączenie zaraz po zebraniu hasła. To już sygnał: “brak faktycznej sesji RDP”. Normalnie po poprawnym zalogowaniu dostaniemy pulpit. W Heraldingu tego nie uświadczysz – atakujący zobaczy, że po wprowadzeniu hasła nagle połączenie się urywa. To jak „drzwi do nikąd”. Dla sprytnego atakującego, który testowo wpisał hasło: czerwony alarm (w raporcie badaczy potwierdzono, że Heralding nie pozwala dojść do etapu wyświetlenia pulpitu, zawsze zrywa wcześniej). Boty pewnie nie analizują tego świadomie, ale ludzie – mogą.

Kolejna sprawa: certyfikaty TLS Heraldinga. Wykryto, że wiele instancji Heralding używa takiego samego self-signed certa (pola issuer/subject te same). To znowu sygnał do masowego fingerprintingu (podobnie jak z Dionaea). Ktoś odpalając rdp-checker na porcie 3389 i sprawdzając certy może odfiltrować honeypoty.

Trzecia – ograniczony protokół. Heralding pewnie wspiera tylko część opcji protokołu RDP (tyle by zebrać hasło). Jak atakujący spróbuje nietypowych funkcji (np. redirekcja urządzeń, szyfrowanie na poziomie NV2) to może dostać odpowiedź wskazującą brak obsługi – co może budzić podejrzenia, choć akurat tu Windows też bywa różny (nie wszystkie opcje zawsze dostępne).

Czwarta – identyczne zachowanie instancji. Skoro Heralding jest nastawiony tylko na loginy, prawdopodobnie wszystkie instancje reagują niemal identycznie: np. zawsze pozwalają na dowolny login i hasło (bo chcą zebrać). Prawdziwe serwery RDP zwykle po kilku nieudanych próbach blokują IP lub konto. Heralding może pozwalać brute-force praktycznie bez limitu, by loginy zbierać. Dla atakującego, który celowo spróbuje 100 haseł do Administratora i nie zostanie rozłączony – to podejrzane, bo normalnie taka wyrozumiałość nie jest standardem (chyba że ktoś fatalnie zabezpieczył serwer).

Podsumowując: Heralding demaskuje brak pełnej sesji i powtarzalny TLS. W cytowanym badaniu znaleziono ~84 honeypoty Heralding, co pokazuje że nie są tak powszechne jak RDPY, ale jednak istnieją. I – co ważne – wszystkie miały te wspólne cechy (zerwanie sesji, identyczne TLS etc.), co czyni ich wykrycie dość łatwym automatem.

Na tym kończymy przegląd – widać pewien wzór: honeypoty zdradza powtarzalność i brak pełnej imitacji. Mając tę wiedzę, przechodzimy do perspektywy defensywnej: jak budować honeypot, by powyższych wpadek uniknąć.

Metody obrony honeypotów przed wykryciem

Skoro atakujący dysponują tyloma metodami identyfikacji honeypotów, obrońcy nie są bez szans – istnieją taktyki utrudniające fingerprinting. Poniżej omówimy najważniejsze metody obrony honeypota przed wykryciem, w podziale na kilka kategorii:

Manipulacja TTL i parametrami sieciowymi

Najniższy poziom, od którego warto zacząć, to “oszukanie” pasywnych fingerprintów. Chodzi o to, by honeypot swoim zachowaniem sieciowym odpowiadał temu, za co się podaje. Jeśli udaje Windows – niech jego pakiety wyglądają jak Windows. Można to osiągnąć, manipulując takimi polami jak TTL, okno, flagi, kolejność opcji TCP itp. Przykładowo, jeżeli nasz honeypot stoi na Linuxie (domyślny TTL=64, window=5840), a ma udawać Windows (TTL=128, inne okna), to powinniśmy zmienić te wartości w wychodzących pakietach. Można to zrobić przy pomocy iptables/netfilter na Linuxie lub odpowiednich driverów na Windows. W literaturze opisano wręcz implementację w kernelu Linux, która podmienia w locie TTL i rozmiar okna w odpowiedziach honeypota, żeby zmylić narzędzia pokroju p0f. Efekt – p0f widzi np. TTL=128 i większe okno, więc fingerprint skłania się ku Windows, nawet jeśli host to Linux.

To samo dotyczy innych szczegółów: kolejność opcji TCP (np. kolejność MSS/WS/TS), ich długości, itp. Możemy przechwycić pakiet SYN+ACK i przebudować opcje tak, by pasowały do sygnatury OS, który emulujemy. To trudniejsze, ale istnieją bazy (np. SinFP signature database), z których można wyciągnąć potrzebne parametry dla danego systemu i zaprogramować kernel, by tak właśnie odpowiadał. Tego typu modulacja to już zaawansowana sztuczka – wymaga np. pisania modułu jądra albo użycia specjalistycznych narzędzi (swego czasu istniał projekt IP Personality do zmiany fingerprintu stosu).

Prostsza praktyka to przynajmniej zmiana domyślnych sysctl: np. wartości net.ipv4.ip_default_ttl na 128 (dla Windows), ustawienie tcp_timestamps tak, by odzwierciedlały boot time zgodny z uptime udawanego systemu, itp. Również banner na poziomie IP (czyli np. opcja DF – don’t fragment – różnie ustawiana w różnych OS) można dostosować.

Krótko mówiąc: nie pozwól, by Twój honeypot miał “linuxowy akcent” jeśli udaje Windows i vice versa. Podstawą jest gruntowna wiedza, jak wyglądają pakiety z docelowego systemu, albo użycie narzędzia które Ci to powie (np. postawić prawdziwą maszynę z danym OS i skanować ją Nmapem z opcją -O, sprawdzając czy fingerprint Nmapa się zgadza – jeśli tak, to nasz honeypotowy stos sieciowy jest przekonujący).

Warto wspomnieć, że manipulacja parametrami sieciowymi przydaje się też do zmylenia prostszych skanerów portów. Nmap i inne mają mechanizmy wykrywania “tarpitów” czy systemów bezpieczeństwa na podstawie właśnie nietypowych reakcji (np. super długi czas odpowiedzi, czy określone wzorce RST). Odpowiednio modulując te elementy, można sprawić by honeypot nie wyróżniał się na tle normalnych hostów w sieci.

Dynamiczne banery i kamuflaż usług

Stałe, powtarzalne banery to wróg numer jeden – dlatego obrońca powinien zadbać o kamuflaż na poziomie aplikacji. Co to znaczy? Przede wszystkim: unikaj domyślnych banerów honeypota. Jeśli Twój honeypot Cowrie zawsze reklamuje się jako “SSH-2.0-OpenSSH_6.0p1 Debian”, zmień to – np. wpisz inną realistyczną wersję (ale upewnij się, że pasuje do udawanego systemu). Jeśli Dionaea FTP wita “220 Honey FTP ready”, zmień to choćby na “220 ProFTPD 1.3.5a Server”. W skrócie: podmień statyczne sygnatury na unikalne, pasujące do story Twojej pułapki.

Kolejna sprawa to dynamika odpowiedzi. Wspomnieliśmy, że atakujący lubią wykrywać honeypot po niezmienności pewnych danych (np. date zawsze da tę samą datę). Remedium jest wprowadzenie losowości i kontekstowości. Przykład: w honeypotach typu Cowrie warto zaimplementować, by komenda date zwracała aktualny czas systemowy honeypot (synchronizowany), a nie stały string. Podobnie uname -a – niech wstawia dzisiejszą datę kompilacji jądra (można wygenerować pseudo-losowy, ale zbliżony do obecnego dnia, by wyglądało legit). Nawet drobiazgi, jak zmienny uptime systemu, mogą zmylić fingerprinting. Badacze sugerują, że dynamiczne odpowiedzi choć częściowo oszukają automaty, które oczekują stałych wartości. Oczywiście nie wszystko da się zrobić dynamicznie (zwłaszcza w low-interaction honeypot), ale co się da – warto.

Trzeba też usunąć oczywiste artefakty: taki nieszczęsny użytkownik richard w Cowrie – nic nie stało na przeszkodzie, by zmienić tę nazwę choćby na losowo wygenerowaną dla każdej instancji (albo po prostu usunąć). Domyślne pliki, nazwy folderów, komentarze w generowanych stronach HTML (“<!– Glastopf Honeypot –>”) – to wszystko musi zniknąć lub stać się unikalne.

Kolejny poziom kamuflażu to dodanie realizmu: jeżeli Twój honeypot webowy udaje serwer firmowy, to warto wgrać mu prawdziwie wyglądającą stronę (np. skopiowaną z jakiegoś szablonu) zamiast zostawiać szkielet. Jeśli udaje serwer FTP, niech ma w katalogach parę unikatowych plików pasujących do tematyki (a nie zawsze te same przykładowe pliki). Z punktu widzenia atakującego, różnorodność między instancjami honeypotów i ich osadzenie w realnym kontekście czyni fingerprinting dużo trudniejszym. Bo atakujący nie będzie już mógł polegać na globalnej sygnaturze (“katalog richard = honeypot”) – co najwyżej będzie musiał każdy przypadek analizować osobno. A to zwiększa szanse, że jednak wejdzie w interakcję i da się złapać.

Można tu przywołać analogię do poligrafii: jeśli dwie książki są identycznie wydane, to łatwo poznać, że z tej samej drukarni – ale jak każda jest innym fontem i formatem, trudniej poznać, że to ta sama treść. Podobnie honeypoty: unikaj klonów, twórz indywidualności.

Na koniec – warto rozważyć emulację banerów prawdziwych aplikacji. Istnieją narzędzia (np. Honeyd dawniej) pozwalające podszywać się pod różne protokoły wzorując na fingerprintach. Można też manualnie – np. masz honeypot ICS Conpot udający PLC: zadbaj, by jego baner Modbus czy HTTP API wyglądał identycznie jak w oryginalnym urządzeniu (patrząc w dokumentację). Dotyczy to też “welcome message” po zalogowaniu do Telnet/SSH – może warto wyświetlić dynamicznie wygenerowany motd z nazwą hosta, uptime etc., zamiast statycznego napisu. To detale, ale atakujący zauważy, że „witam na serwerze FR-PLC-01, uptime 5 days” brzmi bardziej prawdziwie niż „welcome honey” albo nic.

Podsumowanie: kluczem jest wyeliminowanie sygnatur i wprowadzenie zmienności. Honeypot musi żyć, oddychać jak normalny system – choć trochę. Każdy przejaw “życia” (logi systemowe, zmieniający się czas, rotujące ID procesów) czyni go mniej podejrzanym.

Zmiana fingerprintu systemu operacyjnego

Ten punkt pokrywa się częściowo z manipulacją TTL, ale idzie dalej – dotyczy głębszego udawania innego OS. Jeśli nasz honeypot stoi na Linuxie, a chcemy by wyglądał na Windows, to nie tylko pakiety TCP/IP muszą się zgadzać. Również np. stos TLS/crypto powinien imitować tamten system (jak wspomniany SChannel vs OpenSSL problem). To trudne, ale w pewnym stopniu można to osiągnąć. Przykładowo, istnieją projekty które zmieniają kolejność oferowanych szyfrów TLS w OpenSSL by udawać inny system (tak, by JA3 fingerprint pasował do celu). Podobnie, można przechwytywać negocjację SSH i podszyć się pod inną implementację.

W praktyce, obrońca honeypota ma tu dwa wyjścia: wykorzystać system docelowy (np. postawić honeypot faktycznie na Windows, jeśli ma udawać Windows) – to drastyczne, ale rozwiązuje problem fingerprintu OS w 100%. Albo użyć specjalnych nakładek zmieniających fingerprint. W 2015 opisano kernel patch, który interceptuje pakiety i modyfikuje je według zadanego podpisu OS – udało się w ten sposób oszukać zarówno SinFP, jak i p0f. Niestety, nie jest to out-of-the-box rozwiązanie, trzeba mieć skille niskopoziomowe.

Czasem jednak drobne rzeczy wiele dają: np. honeypot na Linuxie, który udaje Cisco router, powinien odpowiadać na pingi TTL=255 (Cisco tak robi). Wystarczy echo 255 > /proc/sys/net/ipv4/ip_default_ttl – i już p0f nie powie “Linux” tylko może się nabierze. Albo: Windows ma w TCP opcjach inny układ NOP-ów (padding) – można by tak przerobić swoje pakiety.

Nie można też zapomnieć o warstwie aplikacyjnej: fingerprint OS można zdobyć też po bannerach aplikacji – np. serwer SSH dropbear vs OpenSSH, SNMP z konkretnym sysDescr. Dlatego zmieniając fingerprint OS, zmieńmy też fingerprint usług: udawajmy nawet drobne rzeczy, np. w SNMP Conpot niech sysDescr string będzie identyczny jak w prawdziwym PLC (z nazwą systemu, wersją OS). To drobiazg, ale spójność buduje przekonanie.

Dodajmy jeszcze, że Nessus i skanery vulnerability potrafią czasem podać OS na podstawie paru testów SMB/SSH – honeypot powinien przejść takie testy pozytywnie. Można to osiągnąć np. integrując pewne realne komponenty – o czym za chwilę w High-Interaction.

Generalnie, zmiana fingerprintu OS to trudny temat – wymaga albo mocno kombinować w konfiguracji, albo iść w kierunku budowania honeypota na bazie prawdziwego systemu (co rodzi inne ryzyka). Niemniej, warto mieć świadomość, że narzędzia typu Nmap/SinFP nas sprawdzą, i dobrze zawczasu zobaczyć jak widzą nasz honeypot. Testuj swój honeypot: odpal p0f, Nmap, Xprobe2 przeciwko niemu i zobacz co wykrywają. Jeżeli nie zgadza się z deklarowanym OS – popracuj nad tym.

Moving Target Defense (obrona ruchomego celu)

Najbardziej zaawansowaną koncepcją obrony jest “Moving Target Defense” (MTD), czyli sprawienie, by honeypot był ruchomym celem. Idea w świecie honeypotów jest taka: skoro atakujący potrzebuje czasu by fingerprintować i rozpoznać pułapkę, to jeśli będziemy zmieniać parametry honeypota szybciej niż on zdąży nas namierzyć, znacznie utrudnimy mu zadanie. W praktyce MTD dla honeypota może oznaczać różne rzeczy:

  • Rotacja adresów IP: Honeypot może zmieniać swój adres (lub porty) co jakiś czas, albo skrywać się za jakimś mechanizmem, który daje mu zmienne IP. Wtedy atakujący nie ma stałego punktu odniesienia – nawet jak wpisze nasze IP na czarną listę honeypotów, jutro będziemy już pod innym.
  • Migracja usług między hostami: Mając klaster honeypotów, można przerzucać rolę między nimi. Dziś ataki obsługuje instancja A (o pewnych cechach), jutro instancja B (nieco inny fingerprint). Atakujący, który wczoraj zebrał trochę fingerprintu, dziś dostanie inne sygnały – być może uzna to za inny system, i nie skojarzy, że to ten sam honeypot.
  • Zmienne środowisko wewnątrz: To o czym mówiliśmy – dynamiczne banery, zmiany w filesystem – to też część MTD, tylko na mikro skalę. Chodzi o to, by pułapka nie była statyczna. Badacze sugerują właśnie dodanie do honeypotów mechanizmów dynamicznych jako przyszłość obrony.
  • Reset po wykryciu: Można programować honeypot tak, by wykrywał fingerprinting i reagował – np. zmieniał swoją personę. Jeśli honeypot zauważy (po sygnaturach ruchu), że ktoś go intensywnie skanuje / testuje, może automatycznie przełączyć się w inny tryb (np. zmienić banery na bardziej zbieżne albo wręcz przełączyć IP na inny). To utrudni atakującemu zebranie pewnych potwierdzeń. Oczywiście to skomplikowane do wdrożenia – wymaga “self-awareness” honeypota, której obecne raczej nie mają – ale w akademii się to proponuje.
  • Polimorficzne honeypoty: myśleć o honeypocie jak o polimorficznym wirusie – nigdy nie taki sam. Każda instancja wygenerowana automatycznie ze slight różnicami. To już robota dla developerów honeypotów – by budowali platformy z losowością (nie jest to trudne, a jednak rzadko robione dotąd).

MTD wiąże się z pewnymi kosztami (zarządzanie IP, orchestracja), ale zwiększa niepewność po stronie atakującego. A o to nam chodzi: by attacker nie miał łatwo powtarzalnego procesu „scanuj – porównaj do sygnatur – pomiń honeypot”. Jeśli każdy nasz honeypot będzie inny i do tego zmienny w czasie, to jedyne bezpieczne dla atakującego będzie… w sumie nic nie atakować, bo ciągle ryzyko.

Przykład wdrożenia MTD: honeypot webowy co godzinę zmienia lekko układ strony (przesuwa elementy, zmienia kolejność komentarzy HTML), co dzień podmienia parę losowych obrazków (spośród jakiejś puli) i co tydzień zmienia domenę (przez przekierowanie ruchu na nową). Dla człowieka może to nieznaczne, ale automaty wykrywające statyczny content pogubią się. Inny przykład: honeypot SSH co restart generuje nową parę kluczy hosta – więc fingerprint klucza nie jest już stałym identyfikatorem w skali internetu.

Badacze w 2023 stwierdzili jasno: “przyszłość honeypotów musi iść w stronę Moving Target Defense”, bo inaczej honeypoty będą coraz łatwiej wykrywane i omijane. W pełni się z tym zgadzamy – ruchomy cel trudniej trafić, a w naszym wypadku – trudniej jednoznacznie stwierdzić „honeypot!”.

Oczywiście MTD nie jest panaceum – bardzo wyrafinowany atakujący, jeśli zechce, może i tak rozpracować dynamiczny honeypot (np. obserwując dłużej, ucząc się wzorców zmian). Ale to podnosi poprzeczkę i czyni atak mniej opłacalnym.

Na koniec tej sekcji warto wspomnieć jeszcze o high-interaction honeypots jako pewnej formie obrony. Wysokointeraktywne honeypoty to w istocie prawdziwe systemy z minimalnymi modyfikacjami – więc mają minimalne różnice od normalnych maszyn. Atakujący może je trudniej odróżnić (bo np. to naprawdę Windows Server, tylko kontrolowany przez nas). Oczywiście kosztem jest ryzyko i trudność w obsłudze. Ale niektórzy stosują hybrydy: np. low-interaction honeypot stoi frontem, a w razie czego przełącza atakującego do sandboxa z prawdziwym systemem (żeby nie spłoszyć go gdy zacznie coś podejrzewać). Albo dokłada się prawdziwe usługi do emulacji (np. prawdziwy demon SSH w kontenerze, a reszta systemu symulowana). Takie mieszane podejście może zbić z tropu fingerprinting, bo np. OS będzie prawdziwy, a logi i tak mamy z honeypota – to już zaawansowane konstrukcje, ale warte rozważenia przy ochronie przed topowym przeciwnikiem.

Czas teraz zebrać najważniejsze porady w zwięzłą listę.

Checklista defensywna: obrona honeypota przed wykryciem

Poniżej przedstawiamy checklistę dla budującego honeypot, która pomaga zminimalizować ryzyko wykrycia pułapki:

  • Dopasuj sieciowy fingerprint OS – Ustaw TTL, rozmiary okien, kolejność opcji TCP tak, by odpowiadały udawanemu systemowi (np. Linux udający Windows: TTL=128, etc.). Przetestuj swój honeypot narzędziami p0f, nmap -O, SinFP – czy wykrywają zamierzony OS?
  • Spersonalizuj banery usług – Zmień wszystkie domyślne banery honeypota na unikalne, pasujące do Twojej historii. Usuń jakiekolwiek wzmianki typu „Honey” w komunikatach. Dodaj realistyczne detale (nazwa hosta, wersje oprogramowania zgodne z OS).
  • Usuń domyślne artefakty – Przeszukaj konfiguracje pod kątem domyślnych użytkowników, plików, katalogów (/home/richard, default creds, przykładowe strony) – usuń je lub zmień nazwy na inne dla każdej instancji. Każdy honeypot powinien mieć niepowtarzalny zestaw takich elementów.
  • Wprowadź dynamiczne elementy – Zaimplementuj zmienność w odpowiedziach: np. aktualna data/czas w powłoce (date), zmieniające się banner IDs (np. losowy element w server header HTTP), dynamiczny motd przy SSH. Unikaj statycznych, niezmiennych ciągów w generowanych treściach.
  • Utrzymuj i aktualizuj – Regularnie aktualizuj używane biblioteki protokołów i łatki honeypota. Jeśli badania publikują nowy fingerprint honeypota – zaimplementuj obejście. Honeypot nie może tkwić w starej wersji przez lata – wtedy staje się łatwym celem do rozpoznania.
  • Certyfikaty TLS i klucze – Wygeneruj własne certyfikaty TLS dla usług (unikalne dla instancji). Upewnij się, że pola issuer/subject nie są jednakowe między instancjami. Dobrą praktyką jest wygenerować cert imitujący realny (np. nazwa organizacji pasująca do firmy). Podobnie, dla SSH – generuj unikalny klucz hosta przy każdym wdrożeniu (żadnych powtarzalnych fingerprintów SSH!).
  • Symuluj pełne protokoły (o ile możliwe) – Jeśli honeypot obsługuje np. RDP/SMB, rozważ wsparcie jak najwięcej typowych funkcji protokołu. Przynajmniej zadbaj o poprawne kody błędów na nieobsługiwane funkcje (tak jak zrobiłby prawdziwy serwer, zamiast rozłączać nieelegancko).
  • Dodaj „szum” wokół honeypota – Prawdziwe systemy generują ruch i logi: Twój honeypot też powinien. Możesz np. okresowo generować w nim jakieś logi systemowe, udawać ruch wychodzący (np. update’y). Chodzi o to, by w razie gdy atakujący uzyska częściowy dostęp, zobaczył coś w logach, a nie tabula rasa (co bywa podejrzane).
  • Monitoruj pod kątem fingerprintingu – Sam honeypot może wykrywać, że jest sondowany (np. nietypowe pakiety FIN, ciągi typu /home/richard w komendach). Wykrywaj takie zdarzenia i reaguj: możesz np. automatycznie zmienić zachowanie honeypota, gdy zorientujesz się, że ktoś próbuje Cię zdekonspirować (np. przełączyć go w high-interaction mode albo po prostu logować agresora, by w przyszłości ulepszyć maskowanie).
  • Rozważ high-interaction lub hybrydę – Najlepszy sposób na niektóre fingerprinty to po prostu być tym, za co się podajemy. Np. honeypot SSH można postawić na prawdziwym Linuksie z ograniczeniami (kontener, SELinux). Jeśli coś jest krytyczne dla realizmu (np. pełna interakcja systemu), a nasz low-interaction sobie nie radzi – może dołóżmy prawdziwy komponent. High-interaction honeypot wymaga zabezpieczeń, ale zapewnia najwyższy realizm, którego żadne emulacje nie przebiją.
  • Stosuj zasadę ograniczonego zaufania – Zakładaj, że Twój honeypot prędzej czy później i tak zostanie rozpracowany. Planuj architekturę tak, by nawet wykryty honeypot nadal dostarczał wartości (np. jako tripwire – sam fakt, że atakujący go ominął, to cenna informacja). Miej przygotowane kolejne warstwy (np. honeynet: za pierwszym honeypotem kolejny, innego typu), by atakujący wpadał z deszczu pod rynnę 😉.

To oczywiście nie wyczerpuje tematu, ale spełnienie powyższych punktów zdecydowanie utrudni życie komuś, kto chce Twój honeypot zidentyfikować. Tak zabezpieczona przynęta stanie się wiarygodnym źródłem danych, bo atakujący będą ją traktować jak prawdziwy system wystarczająco długo, byś zdążył ich obserwować.

Plan działania dla inżyniera bezpieczeństwa

Honeypoty to ciągła gra w kotka i myszkę między atakującymi a obrońcami. Jako praktycy bezpieczeństwa – niezależnie czy działacie po czerwonej czy niebieskiej stronie – powinniście wynieść z tego artykułu konkretną motywację do działania:

Red Team: Włączcie techniki honeypot detection do swoich rekonesansów. Następnym razem, gdy będziecie pentestować infrastrukturę, zastanówcie się: czy ten łatwy cel to na pewno serwer produkcyjny, czy może przynęta? Przetestujcie opisane metody fingerprintingu w kontrolowanym środowisku – odpalcie własnego Dionaeę czy Cowrie i spróbujcie go wykryć niczym prawdziwi napastnicy. Zdobyte w ten sposób doświadczenie pozwoli Wam bezpiecznie omijać cudze honeypoty podczas operacji Red Team (albo… świadomie w nie wchodzić, by zmylić blue team, ale to już inna historia). Pamiętajcie jednak o etyce: jeśli odkryjecie honeypot klienta, zasygnalizujcie to w raporcie z rekomendacją ulepszeń zamiast wykorzystywać przeciw obrońcom. Naszym celem jest ulepszać bezpieczeństwo, nie tylko wygrywać.

Blue Team: Przyjrzyjcie się swoim honeypotom krytycznym okiem. Uruchomcie nmap -O, p0f, sprawdźcie Shodan Honeyscore dla swoich adresów. Czy wyniki sugerują “honeypot”? Jeśli tak – działajcie zgodnie z checklistą powyżej. Zachęcamy, byście świadomie utrudnili zadanie potencjalnym intruzom: zaimplementujcie choć drobne mechanizmy MTD (np. regularna zmiana kluczy SSH, rotacja banerów). Zorganizujcie wewnętrzny Red-Blue exercise: niech jeden zespół postawi honeypot, a drugi spróbuje go wykryć – potem zamiana. Takie ćwiczenia szybko pokażą, gdzie są słabe punkty Waszych przynęt. Nie bójcie się też sięgać po high-interaction honeypots, tam gdzie potrzebny jest najwyższy realizm – przy odpowiedniej izolacji zyskujecie cenne narzędzie, które trudno będzie zdemaskować.

Na koniec, dzielcie się wiedzą: społeczność honeypotów rozwija się dzięki raportom z frontu. Jeśli odkryliście nowy sposób na fingerprinting lub nową metodę kamuflażu – opublikujcie to (oczywiście odpowiednio po czasie, by dać obrońcom przewagę). W ten sposób podnosimy poprzeczkę dla przeciwników po obu stronach.

Honeypoty pozostają wartościowym elementem arsenału obronnego – ale tylko wtedy, gdy są wiarygodne. Od Was zależy, czy przyszły intruz potraktuje Wasz serwer jak łatwy kąsek, czy ominie go szerokim łukiem podejrzewając podstęp. Uzbrójcie się w opisane techniki, eksperymentujcie i udoskonalajcie swoje wabiki. Gra toczy się dalej – atakujący doskonalą honeypot detection, więc my doskonalmy honeypot deception. Powodzenia w terenie, niech Wasze przynęty będą zawsze o krok przed wrogiem!

Podsumowanie

Fingerprinting honeypotów to nie „sztuczka”, tylko standardowy etap rekonesansu – napastnicy łączą metody aktywne i pasywne, polują na niespójności (banery, błędy protokołów, cechy stosu TCP/IP, TLS/JA3), a do tego automatyzują decyzje narzędziami typu Nmap/p0f/SinFP/Xprobe2 oraz OSINT-em (Shodan Honeyscore). Po stronie obrony liczy się spójność i dynamika: dopasowanie fingerprintu OS (TTL/okna/opcje TCP), unikalne certyfikaty/klucze, realistyczne i zmienne banery, usunięcie domyślnych artefaktów, bogatsza emulacja protokołów oraz podejście Moving Target Defense, które wprowadza kontrolowany chaos. Dobrze skonfigurowany honeypot nie świeci „laboratoryjną sterylnością” – ma kontekst (usługi, treści, logi), żyje (czas, uptime, rotacja), i potrafi zareagować na próbę fingerprintingu.

Zanim wystawisz przynętę, sam zaatakuj ją nmapem (-sV -O), p0f i SinFP – jeśli wyniki nie pasują do roli, popraw konfigurację; jeśli Shodan daje wysoki Honeyscore, maskuj sygnały. Traktuj kamuflaż jak cykl CI/CD: test → pomiar → korekta → powtórka. Dobrze ukryty honeypot wydłuża czas „grania” z przeciwnikiem, zwiększa jakość telemetryki i realnie podnosi koszt ataku. Finalnie – nie zakładaj, że dziś dobry kamuflaż wystarczy jutro: iteruj, bo ofensywa też uczy się szybko.

Bibliografia