Honeypoty

Honeypoty získaly své jméno v kontextu nástrahy nebo vějičky („medu“, chcete-li), na který se poté nalepí mouchy, jde ale také o jakousi „pavučinu“, která chytá do své sítě zlotřilé návštěvníky. V kontextu počítačové bezpečnosti se pak bavíme o nastraženém systému, který zachytává nezvané hosty a návštěvníky, kteří v daném síťovém segmentu nemají co pohledávat.

Správně nastavený a umístěný honeypot dokáže zachytit slídily automatizované i člověčí, kteří se pokoušejí skenovat síť a najít zranitelné systémy. Informace o těchto slídilech lze poté využít v rámci vyšetřování bezpečnostního incidentu.

Honeypoty rozlišujeme zejména podle „interaction level“, tedy toho, jak věrné simulace reality jsou schopny. V základu máme tři:

• Nízká úroveň interakce – Z protokolu je implementováno pouze nutné minimum pro navázání a vedení komunikace. Používá se pro jednoduché protokoly či nenáročný sběr údajů o útočnících, například u nových vzdáleně zneužitelných hrozeb, kde je pravděpodobné, že útočníci se budou pokoušet o globální průzkum.
• Střední úroveň – Pokročilejší simulace reálného systému. Užijete ji v případě, kdy potřebujete udržet iluzi reálného systému déle, ale nechcete podstupovat zbytečné riziko. Příkladem je implementace protokolu SSH v Cowrie, či protokol FTP v honeypotu Dionaea.
• Vysoká úroveň – Využití reálného (virtualizovaného) systému, kupř. pomocí proxy. Přináší to vyšší rizika, jelikož tyto honeypoty s sebou nesou celý operační systém; to je však vykoupeno možností sledovat chování na reálném systému, třeba i s právy administrátora. Dobrým příkladem je Cowrie v režimu proxy, s použitím skupiny virtuálních počítačů.

Velkou výhodou honeypotů je, že každá událost vygenerovaná honeypotem je platná a může být nějakým způsobem zpracována, ať už jako falešný poplach, nebo kupř. jako indikátor kompromitace (IoC). Informací v události může být mnoho, mezi jinými např. IP adresa, MAC adresa, datum a čas, ale také informace o klientovi, zadané příkazy, a případné škodlivé kódy. Pokud je k systému zapotřebí přihlášení, lze pak pomocí sebraného jména a hesla určit, zda nedošlo také ke kompromitaci přístupových údajů uživatele organizace.

Rizikem honeypotů, jako každé podobné služby, je, že může být napaden exploitem, proto je důležité dbát na jejich správné zabezpečení. Ideálně by honeypot neměl mít možnost přistupovat do vnitřní sítě organizace, ale naopak by měl mít široce otevřené porty pro připojení k simulovaným službám. Pro omezení rizika exploitu lze s výhodou také využít kontejnerizaci a virtualizaci – ostatně proto distribuujeme naše honeypoty jako obrazy samostatných virtuálních strojů.

Když člověk dnes řekne „honeypot“, ne vždy musí být honeypot pouze představován nějakou službou; nástrahy v síti lze provádět různě, třeba strategickým umístěním „důležitých“ dokumentů v interním úložišti. Důležitá je schopnost detekce. Nicméně zde se zkusíme omezit na základní služby typu Cowrie, nepenthes, či Dionaea. Konkrétně službám Cowrie a Dionaea se budeme věnovat podrobněji v samostatné kapitole níže; také se jedná o dost svébytné a rozsáhlé honeypoty.

Většina vytvořených honeypotů se snaží pokrýt svůj protokol nebo relativně úzkou oblast zájmu. Namátkou lze uvést ADBHoney (pro Android Debug Bridge), ElasticPot (napodobuje ElasticSearch), či které simulují součásti průmyslového řídicího systému (ICS), jako např. Conpot. Pro simulování webových aplikací pak existuje známý tandem SNARE a TANNER. Přijatelnou alternativou může být poslat crawlery, které nerespektují robots.txt, do pekla. A když nechcete nic víc, než sbírat přihlašovací údaje, pak zvolíte třeba Heralding.

Existují také honeypoty vytvořené pro konkrétní zranitelnosti, jako např. ciscoasa (CVE-2018-0101), Log4Pot (Log4Shell – CVE-2021-44228), a další. Hlavním cílem těchto honeypotů bývá sběr zdrojových IP adres a zanechaných škodlivých kódů.

Někdy, když je systém komplexní, dává smysl jej vystavit do veřejné sítě, aby bylo možné studovat chování útočníka i po průniku. Příkladem může být tento Exchange Server 2019, s nezáplatovanou zranitelností ProxyLogon. V takovém případě je ale nutno zavést ochranné prvky, jako např. blokování odchozího provozu a DNS, aby se útočník dostal dovnitř, ale už nemohl komunikovat se svojí mateřskou lodí, ani napadat jiné objekty zájmu. Pokud je takový systém provozován ve virtuálním stroji (VM), lze dále použít např. DRAKVUF pro sledování a analýzu chování VM, aniž by bylo nutné do VM cokoliv dalšího instalovat.

Honeypot Cowrie je tradičním honeypotem protokolů SSH a Telnet. Může operovat ve dvou režimech:

• režim shellu: emuluje tradiční prostředí UNIXového systému (Debian) – „medium interaction honeypot“
• režim proxy: přesměruje sezení SSH či Telnetu na jiný stroj – „high interaction honeypot“.

V obou režimech lze sledovat chování uživatele a zaznamenávat jejich příkazy a stažené soubory, nebo pokusy o vytvoření TCP tunelů (direct-tcp) prostřednictvím SSH. Sbírají se také použité přihlašovací údaje, a to včetně pokusů o přihlášení pomocí SSH klíče.

Honeypot Dionaea, následník honeypotu nepenthes, je rozšiřitelný honeypot pokrývající spoustu protokolů. Umožňuje emulaci shellcode prostřednictvím libemu a skriptování pomocí Pythonu; stejně tak umožňuje zaznamenávání událostí do spousty různých výstupních modulů.

Mezi podporované protokoly se řadí:

• přenos souborů: FTP, TFTP, SMB/CIFS, NetBIOS
• databáze a key-value úložiště: MS-SQL, MySQL, MongoDB, Memcached
• MQTT
• PPTP
• HTTP(S)
• PJL/PCL tiskový server (port 9100)
• UPnP
• specialitky jako Black Hole, EPMAP, Mirror, nfq apod.

Jednotlivé moduly mají různou kvalitu a kupř. MS-SQL implementuje historickou verzi protokolu. To ovšem často nebrání v zachycení užitečných dat či exploitů.

Pro honeypoty Hugo jsme zvolili protokoly, u kterých jsme otestovali jejich funkčnost a zároveň je rozumná šance, že poskytnou zajímavá data.