Honeypot to celowo podatny system lub zasób zaprojektowany do przyciągania atakujących i przechwytywania wywiadu o ich taktykach. Dla atakujących wygląda jak prawdziwy system produkcyjny wart ataku; dla obrońców każda interakcja jest detekcją złośliwej aktywności wysokiej pewności (bo żaden legalny użytkownik nie ma powodu uzyskiwać dostępu). Honeypoty mają wiele form — fałszywe serwery, fałszywe bazy danych, fałszywe poświadczenia, fałszywe dokumenty — i służą wielu celom: wczesne ostrzeganie o atakach, zbieranie threat intelligence, odwracanie uwagi atakujących od prawdziwych celów i badanie technik adversarów.

Sześć kategorii: (1) **Low-interaction honeypots** — częściowo emulują usługi (Cowrie SSH, Dionaea malware capture); tanie, niskie ryzyko, ale atakujący mogą wykryć emulację, (2) **High-interaction honeypots** — pełen system operacyjny, atakujący może w pełni skompromitować; najgłębszy wywiad ale wyższe ryzyko i koszt operacyjny, (3) **Honeynets** — całe sieci honeypotów symulujące środowisko produkcyjne, (4) **Honeytokens** — fałszywe poświadczenia, fałszywe klucze API, fałszywe dokumenty zasiane w systemach; alertują przy dostępie, (5) **Honeyfiles** — fałszywe wrażliwe dokumenty (np. 'Q4_Finanse.xlsx') beaconujące przy otwarciu, (6) **Honey accounts** — fałszywe konta AD z wysokimi uprawnieniami; alertują przy każdej próbie logowania. Nowoczesne platformy deception (Illusive, TrapX, Acalvio, Smokescreen) automatyzują wdrożenie na skalę enterprise.

Open-source: (1) **T-Pot** — community honeypot platform od T-Systems; pakuje 20+ honeypotów w Docker, (2) **Cowrie** — SSH/Telnet honeypot, przechwytuje komendy atakującego, (3) **Dionaea** — malware capture honeypot, (4) **Honeyd** — virtual honeypot creator, (5) **Canary (Thinkst)** — commercial-grade simplicity (set-and-forget), (6) **OpenCanary** — open-source alternatywa Canary. Platformy deception enterprise: (1) **Acalvio ShadowPlex** — distributed deception przez IT/OT/cloud, (2) **Illusive Networks** (przejęte przez Proofpoint) — Active Defense + identity protection, (3) **TrapX DeceptionGrid**, (4) **Attivo Networks ThreatDefend** (przejęte przez SentinelOne) — zintegrowane z Singularity. Kryteria wyboru: skala, integracja z SIEM/SOAR, pokrycie IT/OT, jakość telemetrii.

Tak — ale nowoczesny wzorzec to **deception technology** zamiast samodzielnych honeypotów. Nowoczesne firmy wdrażają honeytokens na skalę: fałszywe poświadczenia w password managerach, decoy klucze AWS w repozytoriach kodu, lure pliki w sieciowych udostępnieniach, decoy konta AD. Każda interakcja to wysokopewna detekcja naruszenia. Dlaczego działa: atakujący wykonujący rekonesans i lateral movement nieuchronnie napotykają decoy; wskaźnik false positive jest praktycznie zero. Detekcja w punkcie *post-breach lateral movement* uzupełnia detekcję perimetru EDR/XDR. Produkty ITDR (Identity Threat Detection and Response) pakietują honeytokens z szerszą detekcją ataków tożsamości. Główni analitycy (Gartner, Forrester) rekomendują deception jako top-quartile kontrolę detekcji.

Trzy powiązane ale różne koncepcje: **Honeypots** — oryginalny termin, indywidualne fałszywe systemy do badań i przechwytywania; głównie external-facing lub DMZ. **Deception technology** — nowoczesny enterprise termin, skalowane honeypoty + honeytokens dystrybuowane w środowisku produkcyjnym do detekcji post-breach lateral movement; zintegrowane z SOC. **ITDR (Identity Threat Detection and Response)** — nowsza kategoria specjalnie dla ataków tożsamościowych; łączy honey accounts/credentials z behawioralną analityką tożsamości (Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, Silverfort, Semperis). Nowoczesne programy używają wszystkich trzech: klasyczne honeypoty dla rekonesansu zewnętrznego, deception dla wewnętrznego lateral movement, ITDR dla ataków na tożsamości.

Sześć aspektów: (1) **Obrona entrapment (rzadka w kontekście cyber)** — większość jurysdykcji nie uznaje entrapment jako obrony przed nieuprawnionym dostępem; wdrożenie honeypotów jest generalnie legalne, (2) **Prywatność** — przechwytywanie ruchu atakujących może niezamierzenie przechwytywać niewinne strony trzecie (np. ruch z Tor exit relay); banner ze zgodą zalecany, (3) **Cross-border data** — jeśli honeypot przechwytuje ruch obywateli UE, mają zastosowanie implikacje RODO, (4) **Zakazy active defence** — większość jurysdykcji zakazuje hack-back; honeypoty są *pasywne* i legalne, ale akcje ofensywne z honeypota nie, (5) **Banner / Regulamin** — wyświetlaj ostrzeżenia o autoryzowanym użytkowaniu żeby wzmocnić pozycję prawną, (6) **Zachowanie dowodów** — jeśli honeypot przechwyci actionable dowody, podążaj za chain of custody dla potencjalnego ścigania. Skonsultuj się z prawnikiem przed wdrożeniem na produkcji.

Osiem najlepszych praktyk: (1) **Izolacja sieci** — wdroż w segmentowanej sieci ze ścisłym filtrowaniem egress; honeypot nie może stać się pivotem do prawdziwej produkcji, (2) **Reguły firewall** — blokuj cały outbound z honeypota oprócz logowania do SIEM, (3) **Limity zasobów** — ogranicz CPU/pamięć/przepustowość żeby zapobiec nadużywaniu do DDoS amplification, (4) **Patchowanie** — nawet honeypoty wymagają patchowania platformy bazowej; usługa honeypot jest intencjonalnie podatna, ale host OS nie powinien być exploitowalny dla niezamierzonego dostępu, (5) **Brak prawdziwych danych** — nigdy nie wdrażaj honeypotów z prawdziwymi danymi klientów, (6) **Monitoring** — każda interakcja honeypota powinna generować alerty SIEM, (7) **Realistyczna treść** — puste honeypoty są wykrywalne; wypełnij fałszywymi-ale-wiarygodnymi danymi, (8) **Okresowe odświeżanie** — rotuj decoy żeby zapobiec rozpoznawaniu przez atakujących. Testuj dokładnie w staging przed produkcją.