Ci, którzy mnie znają, wiedzą, że prywatnie moją pasją są pszczoły. Opowiadam o nich, edukuję, walczę z mitami i przekłamaniami, wspólnie z mężem od kilku lat prowadzimy Pasiekę na Roztoczu. Na blogu dzielimy się historiami i anegdotami z życia tych zapylaczy. Znajomi dostają ode mnie słodkie pułapki. Słodkie, bo mające tysiące kalorii i łamiące najtwardsze postanowienia noworoczne i dietetyczne.

W życiu zawodowym taką moją pasją są honeypoty. Wiem, jakie pułapki na przeciwników zastawiają pszczoły i chcę wiedzieć, jakie pułapki zastawiają ludzie. I jak na rynku trafia się jakaś nowa pozycja o honeypotach, to trafia do mojej kolekcji. Idę wtedy jak przysłowiowy dzik w szyszki i kupuję. Nieważne, kto jest autorem – mój przyjaciel, mój wróg, who cares?

I w piątek lub sobotę, jak tylko pokazało mi się info, że w sieci pojawiła się nowa książka o honeypotach, to od razu kupiłam. Mowa tutaj o książce Honeypoty w praktyce autorstwa Wojciecha Ciemskiego.

Ta recenzja będzie podzielona na 2 części: na merytoryczną / obiektywną, opartą na dowodach i taką subiektywną, czyli moje odczucia po przeczytaniu, i tutaj uważam, że każdy ma prawo mieć własną opinię i własne zdanie na ten temat.

STRONA OBIEKTYWNA

Wchodząc na stronę zakupową na esytools mamy dość krótki opis, ale ciekawy. Pogrubiłam te zwroty, które zwróciły moją uwagę:

Honeypoty to jedna z najbardziej praktycznych technologii cyberbezpieczeństwa — ta książka pokazuje, jak wykorzystać je do wykrywania ataków, analizy malware i budowy realnej warstwy deception w organizacji.

To techniczny przewodnik obejmujący zarówno podstawy honeypotów, jak i praktyczne wdrożenia w środowiskach Linux, Windows, IoT, SCADA oraz SOC.

Co otrzymujesz:

• Projektowanie i wdrażanie honeypotów w środowiskach IT krok po kroku

• Integracje honeypotów z Wazuh, ELK, SIEM i systemami monitoringu

• Analiza technik ataków, malware i aktywności intruzów obserwowanych przez honeypoty

• Honeytokeny, deception i mechanizmy aktywnej obrony

• Budowa oraz konfiguracja własnych środowisk honeypotowych

• Architektura, izolacja i operacyjne wykorzystanie honeypotów w praktyce

Moje oczekiwania w stosunku co do tego opisu? Techniczny przewodnik, z wdrożeniami krok po kroku, listingami, przykładami i integracjami gotowymi do użycia. A co dostałam? Tutaj trzeba się trochę rozpisać.

1. Spis treści

To pierwsze, co rzuca się w oczy. Dlaczego tematy związane z instalacją i konfiguracją honeypotów Cowrie i Dionaea znajdują się w rozdziale Honeypoty w praktyce — systemy Linux, a temat OpenCanary — konfiguracja krok po kroku w rozdziale Honey services i honeytokeny – tego dalej nie rozumiem.

2. Brak wizualizacji

400 stron książki, z czego pewnie po poprawnym sformatowaniu zostałoby koło 300, i oprócz muchy na okładce ani jednego wykresu, grafiku, infografiki, grafu, zrzutu ekranu. A listingi nie przekraczają 30 linii. Nie tego oczekiwałam po technicznym przewodniku. Autor na jednym z for na Discordzie na pytanie o brak zrzutów ekranu odpisał mi:

Screenshoty również ograniczyłem celowo. Zależało mi bardziej na trwałości treści technicznych niż na dużej liczbie obrazów z interfejsów, które często dezaktualizują się po kilku miesiącach. Postawiłem bardziej na opis architektury, integracji, procesów i praktycznych wdrożeń.

Ale to stwierdzenie nie pasuje mi do przykładów logów w książce i gryzie się z timestampami sprzed ponad roku, takimi jak 2025-02-14 czy też 2025-06-16. Czym różni się zrzut ekranu ze starą datą od przykładowego logu z taką samą datą?

3. Budowanie pierwszego honeypota (od zera) i Netcat — sieciowy „scyzoryk”

W tym rozdziale znajdziemy info o tym, czym jest netcat, kto go wymyślił, jak działa – tutaj opisano kilka podstawowych komend. IMO początkujący nie skorzysta z tego za wiele, zanim nie sprawdzi w innym źródle, jak zainstalować netcata, jakie są możliwe opcje, a jak już znajdzie odpowiednią dokumentację, to nie tylko podstawowe, ale także zaawansowane komendy tam znajdzie, z kolei osoba doświadczona podstawowe komendy zna i oczekuje konkretów a nie tłumaczenia, co robi komenda nc -l -p 8000 czy nc 192.168.1.100 22. A poświęcenie backdoor/shell i komendzie nc -l -p 4444 -e /bin/bash 8 linijek tekstu ciężko uznać za wyczerpanie tematu. W sekcji netcat nie znalazłam nic o instalacji itd.

Mamy w tym rozdziale także tworzenie podstawowego honeypota Telnet i polecenie: sudo nc -l -p 23 -v -k > /tmp/telnet_honeypot.log. Do tego polecenia jest podany przykładowy fragment logu z omówieniem. A następnie modyfikujemy to polecenie dodając tee, ale przykładu z wynikowy logiem już nie dostajemy, tylko wspomnienie np. o xinetd:

Alternatywnie wiele zewnętrznych narzędzi (np. systemd, script czy nawet użycie xinetd do uruchamiania netcata) mogłoby zadbać o logowanie z datą, ale to dodatkowa komplikacja — na razie staramy się zachować minimalizm.

To „na razie” oznacza, że w książce temat xinetd nie został już szerzej omówiony.

4. Cowrie (SSH/Telnet) — instalacja i konfiguracja krok po kroku

Przechodzimy dalej, do modułu, w którym jest podrozdział o instalacji i konfiguracji Cowrie. Aby móc ocenić kod rzetelnie, a nie tylko na oko przetestowałam go na własnym środowisku. I to, co od razu wzbudza mój sprzeciw, to użycie -y w poleceniach takich jak to z książki:

sudo apt-get install -y git python3-venv build-essential libssl-dev
libffi-dev libpython3-dev python3-minimal authbind

Ten niepozorny -y to pozwolenia na to, aby wszystkie pakiety, także zależne, zostały zainstalowane bez sprawdzenia przez nas, ile i jakie, bez wyrażenia przez nas zgody. Ja w dokumentacji takich rekomendacji nie znalazłam.

Potem mamy polecenie git clone http://github.com/cowrie/cowrie, gdzie http zgubiło s. Bo obecny adres to: https://github.com/cowrie/cowrie. Niby „drobiazg”, ale dzięki temu można dostrzec wyraźne podobieństwo między kodem w książce, a dokumentacją cowrie pod tym linkiem. W dokumentacji też jest instalacja bibliotek na początku, ale bez -y. Potem tworzenie użytkownika cowrie, przełączenie na tego użytkownika. Potem w obu źródłach jest git clone po zwykłym http: git clone http://github.com/cowrie/cowrie.

I okazuje się, że obecnie ten projekt jest o kilka MB większy, ma dużo więcej obiektów. Na dodatek ma warning o przekierowaniu na stronę z https. Po lewej jest moje środowisko, po prawej screen z dokumentacji. Prawda, że się różnią. A w książce jest ta wersja po prawej.

To podobieństw ciąg dalszy: ta sama nazwa virtualenv: cowrie-env, aktywacja zmiennych, to samo polecenie do upgrade’u pip, zmodyfikowane polecenie do instalacji zależności. I to jeszcze jest do wytłumaczenia.

Ale do tej pory, podczas procesu instalacji cowrie, było prowadzenie czytelnika za rękę, jeśli chodzi o instalację virtualenv i instalację pakietów. Ale jak przechodzimy do konfiguracji, to zaczyna się etap: radź sobie człowieku sam. W książce mamy taki tekst:

W katalogu cowrie/etc/ znajdują się dwa ważne pliki: cowrie.cfg.dist (domyślna konfiguracja) i cowrie.cfg (właściwa konfiguracja użytkownika). Na początku cowrie.cfg może nie istnieć — należy utworzyć jego kopię z pliku .dist.
Wykonujemy polecenie:
cp etc/cowrie.cfg.dist etc/cowrie.cfg
Teraz możemy edytować etc/cowrie.cfg zależnie od potrzeb. Domyślna konfiguracja Cowrie działa od razu po instalacji, więc na początku nie musimy wprowadzać żadnych zmian.”

A w dokumentacji:

The configuration for Cowrie is stored in cowrie.cfg.dist  and cowrie.cfg  (located in cowrie/etc). Both files are read on startup, where entries from cowrie.cfg  take precedence. The .dist file can be overwritten by upgrades, cowrie.cfg
 will not be touched. To run with a standard configuration, there is no need to change anything. 

Taki początkujący czytelnik dostaje instrukcję krok po kroku, jak zainstalować virtualenv, z komentarzami nawet, ale jak otworzyć plik konfiguracyjny, żeby go wyedytować – tego już nie ma. Jedyny fragment takiego pliku konfiguracyjnego to 2 linie jak te poniżej. I co ciekawe, w dokumentacji jest też akurat mowa o telnecie. Oba dokumenty opisują też konfigurację portów i Iptables. Więc równie dobrze można przeczytać dokumentację, nie trzeba płacić.

[telnet]
enabled = true

Więc traktujmy czytelnika do końca jako juniora, tym bardziej, że tytuł podrozdziału to instalacja i konfiguracja krok po kroku, a nie tylko instalacja. Tym bardziej, że ta konfiguracja wcale nie jest taka prosta, jak to opisano w książce czy wspomnianej przeze mnie dokumentacji. Jest trochę więcej kroków do wykonania, można przykład zobaczyć tutaj.

Ale trafiamy w końcu na rozdział z przykładami rzeczywistych ataków. Oczekujemy doświadczenia z pierwszej ręki, a dostajemy tekst:

W analizie przeprowadzonej przez serwis HackerTarget honeypot w Singapurze
zanotował w dobę ponad 200 unikalnych adresów atakujących. Rozkład geograficzny ujawnił najczęstsze kierunki, z których pochodziły ataki: Brazylię i Chiny.

Jest też jako przypis link do raportu. Raport od HackerTarget ciekawy, z wizualizacjami, danymi, wykresami, interaktywną mapą. A w książce: tylko morze tekstu.

5. Dionaea (honeypot typu multi-protocol) — instalacja i konfiguracja krok po kroku

Przy Dionaea też mamy polecenie sudo apt-get install -y. Zastanawiałam się, kto lub co ten przełącznik podpowiada i okazało się, że GenAI lubi to 😉

Kod w książce jest taki sam jak ten od Gemini, czy z dokumentacji. Ocean słów, od czasu do czasu jakieś polecenie, praktycznie zero listingów.

Mamy też teksty w stylu:

Przykładowe wyniki w Kibanie: Możemy uzyskać dynamiczne dashboardy. Na przykład:
o Mapa świata z punktami/nasyceniem pokazująca, z jakich krajów następuje
najwięcej ataków (logi Cowrie mają pole src_ip, które geokodujemy do pola
country).

Ja nie chcę czytać o wizualizacjach w praktycznym przewodniku, ja chcę je zobaczyć, mieć dowód na to, że to działa, że warto w to zainwestować czas. Ja nie chcę czytać, że pole src_ip mogę geokodować na country, ja chcę się dowiedzieć, jak to zrobić i jak wygląda efekt końcowy.

I mamy szumnie zapowiadaną integrację z Wzuhem, a tak naprawdę to jedna strona A4 z integracjami w stylu:

…reguła Wazuh może z tego zrobić alert. Oto przykład reguły: if
cowrie.login.success and password matches regex '^(?=.{6,}$).’ (tzn. dość długie hasło),
wtedy severity medium* — to czysto teoretycznie.

Tak samo jest z opisem instalacji OpenCanary – jest konfiguracja krok po kroku, czyli to, co można znaleźć w dokumentacji i na stronie projektu. A jak zaczyna się praktyczna konfiguracja to są tylko jakieś fragmenty, jakieś opisy, brak praktycznych wdrożeń. I tak w koło Macieju.

Przy instalacji Conpota mamy polecenie sudo apt-get update, przy Cowrie, Dionaea i Honeyd także, a przy OpenCanary jest już sudo apt update && sudo apt upgrade -y. Pracujemy w cyberbezpieczeństwie, szkolimy innych, aby trzymać standardy, bo wtedy łatwiej wykryć anomalie. Ta książka tego nie uczy.

OPINIA SUBIEKTYWNA, CZYLI MOJE WRAŻENIA

1. Dlaczego na okłace jest mucha, a nie pszczoła? Mnie tutaj taki owad nie pasuje.

2. Po otworzeniu PDFa, można zauważyć, że za zawartość książki, projekt okładki, projekt typograficzny i skład, redakcję i korektę odpowiada jedna osoba: Wojciech Ciemski. Napisałam kilka profesjonalnych artykułów, sporo dokumentacji i wiem, jak nieoceniona jest pomoc kogoś, kto zrobi korektę, poprawi błędy, sprawdzi merytorycznie zawartość naszej pracy. Moja wersja PDFa, którą otrzymałam, w temacie formatowania pozostawia wiele do życzenia. Moi studenci, którzy piszą u mnie prace dyplomowe, nie chcą mi wysyłać draftów, bo mówią, że muszą poprawić, sformatować, bo w takim stanie jak teraz nie mogą wysłać, bo wstyd, a ja zapłaciłam 57 zł.

3. Ja nie lubię, jak zamiast działającego kodu, dostaję tekst w stylu:

Oto przykład fragmentu pliku konfiguracyjnego Dionaea (pseudokod dla zilustrowania idei, nie oddaje rzeczywistej składni pliku dionaea.conf, tylko ideę).

<listen> 
    <device>any</device>        --> 
    <port>21</port>             
    <port>80</port>             
    <port>445</port>            
... 
</listen> 

23 linie pseudokodu z ideą. Powyżej tylko fragment. Taką ideę to ja mogę znaleźć w dokumentacji, nie potrzebuję za to płacić. I nie lubię płacić za 400 stron, jak spora część strony jest pusta. I skoro to techniczny przewodnik to oczekuję porządnych listingów.

4. Kupując taki przewodnik techniczny, oczekuję best practices, doświadczenia życiowego, a nie opisów, co jest w dokumentacji czy tekstów: z dokumentacji wynika.

5. Brak standardów, konwencji. Od lat uczę moich studentów, że standaryzacja to podstawa. Pozwala na wyłapywanie pomyłek, anomalii itd. A w tej książce raz jest kursywą, innym razem już nie, nie ma screenów i często nie wiadomo, o co chodzi. Patrząc na poniższy tekst nie sposób dojść, co oznacza pogrubienie, co oznacza pochylenie.

6. Po logach ciężko mi oicenić, kiedy ta książka była pisana. Czy te rady są aktualne? Po kodzie i tego, co w książce, a co po wpisaniu w konsoli dostajemy, widać, że przynajmniej parę rzeczy się zmieniło.

7. W tej książce są używane słowa, które nigdy nie zostały czytelnikowi porządnie wytłumaczone. Takim przykładem niech będzie slowo demon. Parę sekund mi zajęło, zanim skojarzyłam, że tu chodzi o angielskie słowo daemon. W książce pojawia się to słowo 20 razy. W różnych kombinacjach: „syslog-ng oraz inne demony syslog (np. rsyslog)”, „w samym demonie honeypota”. Niektóre sformułowania brzmią ciekawie, np. „zdemonizować proces (puścić w tle)” (to info pojawia się w połowie książki) lub „Po zainstalowaniu upewniamy się, że demony nie
startują automatycznie”.

8. Ja nie kupuję książki po to, aby dowiedzieć się o rzeczywistych atakach, opisanych na publicznej stronie. Takie informacje mogę sobie znaleźć w sieci za darmo albo spytać AI. Ja oczekuję zwrotów: Z mojego zawodowego doświadczenia/praktyki wynika, a nie: z dokumentacji wynika.

I teraz pytanie, kto jest idealnym odbiorcą tej książki?

Początkujący? No nie, bo on potrzebuje konkretnych listingów, a nie hipotetycznych, czy opisów, zrzutów ekranów, dokładnych poleceń, aby nie zrezygnować po pierwszym niepowodzeniu. Początkujący w danych temacie to takie script kiddies: korzystają z przykładów, które inni utworzyli i przetestowali w praktyce. Zobaczą, albo i nie (bo w książce sporo jest zwrotów: powinniśmy zobaczyć), jak się instaluje honeypota, jak się tworzy virtualenv, ale konfiguracja może już stanowić problem.

To może ekspert/bardziej doświadczony użytkownik? Też nie. Bo dokumentację to on doskonale zna. I wie, jak z niej korzystać. W książce szuka życiowego doświadczenia autora, nie z publikacji, nie z ponad 150 artykułów i książek. Ale takich z życia, z pracy. Przynajmniej ja czegoś takiego w książce tego typu szukam. A nie zastasowań teoretycznych. Jemu nie trzeba tłumaczyć, jak stworzyć zmienną środowiskową i że trzeba zrobić apt update i upgrade.

W tej książce te same informacje są wielokrotnie powtarzane, co kojarzy mi się z pisaniem rozdziałów przy pomocy GenAI, gdzie ten sam temat pojawia się jako odpowiedź na kolejny prompt. Książka jest chaotyczna: gdzieś koło 50 strony jest mowa o podstawowej konfiguracji OpenCanary, a kilka rozdziałów dalej, w okolicach 200 jest instalacja i konfiguracja krok po kroku. Jaki jest tego cel – nie mam pojęcia. Słowo OpenCanary występuje w książce 126 razy, a Cowrie – 588. W książce miało być o architekturze wdrożeń, ale jak mówić o architekturze bez schematów, diagramów. W takiej formie jak obecnie, ta książka jest dla mnie totalnie nie do zaakceptowania. To są tylko słowa, nie ma nic, co pozwoli mózgowi odpocząć, co wywoła zainteresowanie. Są rozdziały, gdzie 99,999% to tekst, a reszta to kod. Tylko opisy. Czyli czytasz, ale dopóki sam/a nie sprawdzisz, nie masz pojęcia, czy to działa, czy nie działa, czy da się to na produkcję wdrożyć. Książka pełna przypisów do darmowych w większości źródeł. Jak dla mnie 20% książki ma wartość, reszta to zwykłe lanie wody. Nie przemawia do mnie argument, że screenshoty by się dezaktualizowały za szybko. Napisałam już sporo dokumentacji w życiu, i wiem, że jak w dokumentacji muszą się pojawiać zrzuty ekranu, to się walczy dotąd, aż program zacznie działać. A to wymaga czasu, umiejętności. A tekst? Zawsze można usunąć datę, napisać, że wersja skrócona. JA też książki drugi raz bym nie kupiła. Ma potencjał, ale nie w tej formie.

I niezmiernie mnie dziwią te opinie z 5 gwiazdkami na easytools🙂 Mam nadzieję, że ktoś jeszcze się w tym temacie wypowie, może to ja mam za duże wymagania. Ale, od Wojciecha, człowieka na liście 40 under 40, mam chyba prawo wymagać, żeby poprzeczkę ustawił bardzo wysoko, czyż nie?