Honeypot: efektivní a levný způsob detekce útoků v LAN

V poslední době se toho u nás ve firmě děje hodně. Za poslední 2 měsíce k nám přišli 2 bezvadní noví kolegové Petr a Jarda a třetí je na cestě. Díky vyšší pracovní kapacitě se mi uvolnily ruce a já se mohu zase více soustředit na rozvoj našich technologií.

V minulém článku „IT bezpečnost: životní cyklus“ jsem psal, že restriktivní bezpečnostní opatření dělá každý. Avšak zabezpečení nikdy nebude 100% už jen z toho důvodu, že mezi útočníkem a obráncem je nerovnováha. Útočníkovi stačí jediná chyba v systému, aby jej prolomil. Kdežto my obránci nesmíme mít v systému ani jednu chybu (to je dost nereálná představa).

Z tohoto důvodu je potřeba mít v síti i nějakou technologii (ideálně více), která detekuje, že dochází k útoku a upozorní nás. Schválně se zkuste zamyslet, byli byste schopni u vás detekovat útok? Jak? (A teď nemyslím pokusy botnetů o prolomení internet facing služeb 😊). Asi není jen tak pro nic za nic doba detekce průniku do sítě v řádu měsíců (viz. FireEeye report).

My nějaké metody a systémy pro detekování útoku máme (viz článek výše), ale technologie, o které teď píši, a kterou začneme během pár týdnů u zákazníků nasazovat, bude v poměru cena/výkon náš šampion.

Dost však omáčky kolem, pojďme na věc.

Jak vypadá ideální systém detekce útoků

Podle mne by ideální systém detekce útoků měl mít následující parametry:

• Minimum špatných detekcí – tzn. detekovat každý útok a nemít chybné detekce. Chybné detekce (kdy normální činnost je chybně označena za útok) jsou otravné a hrozí, že až se něco skutečně stane, budete to ignorovat. Jako kdyby někdo každý den volal „hoří“. Hasiči 2x přijedou, ale třetí den se už nikdo neobjeví, i kdyby opravdu hořelo.
• Co nejnižší náklady – když bude stát zabezpečovací zařízení více než to, co má chránit, není to dobře.
• Minimum času na údržbu – dobrých lidí je nedostatek, nemůžeme jejich časem plýtvat na údržbu dalšího systému.

Myslím, že právě honeypot v podobě, v jaké ho dále popisuji v článku, tyto vlastnosti má.

Jak a kdy detekovat útok

Útok nejlépe odhalíte, když k němu zrovna dochází – to bývají útočníci „nejhlučnější“ (skenují síť, zkouší hesla, exploitují a používají různé administrátorské/hackovací utility). V této fázi se lze ještě bránit (např. odstřihnout útočníka od sítě, zrušit kompromitované účty). Jakmile je však útok hotov (tzn. útočník má to, pro co přišel – data, skrytý backdoor do sítě), už se detekce provádí těžko a díky skrytému backdooru může být příští útok bleskový (do pár minut nedostupná síť/server/IS).

Obecně jde o to, abyste v síti detekovali aktivitu, kterou běžní uživatelé nikdy nedělají, ale útočníci vždy dělají. Co jsem se naučil a sám při penetračních testech vždy dělám, je fáze „průzkumu“. Když se útočník dostane do LAN (např. skrze wifi, spear phishing, zapojením sondy do sítě), ocitne se v pro něj neznámém prostředí (vaší síti) a musí se proto zorientovat. Bude se snažit vyhledat zařízení a služby, přes které by se dostal blíže (fáze „lateral movement/privilege escalation“) ke splnění svého cíle (krádeže dat, paralyzování firmy, ovlivnění firmy).

Naším cílem je odhalit útočníka během fáze průzkumu. Uděláme to tak, že do sítě zapojíme „návnadu“ (honeypot). Honeypot bude čekat, až se s ním někdo pokusí spojit. Jelikož je to zařízení, o kterém nikdo neví, že existuje, běžní uživatelé nebudou mít možnost se s ním spojit (předpokládám, že uživatelé se v pracovní době nebaví IP skeny, port skeny a přihlašováním na cizí služby).

Naopak útočník není v síti proto, aby plnil data do vašeho IS jako zaměstnanci, ale proto, aby našel zranitelnost, přes kterou se dostane v síti blíže ke splnění svého cíle. A samotné nalezení tohoto zařízení (resp. oskenování jeho portů) nebo pokus o přihlášení na nějaké služby spustí upozornění správci sítě. Proto očekávám, že řešení honeypotem bude spolehlivé a bude mít minimum špatných detekcí (útočník síť včetně portů skenuje vždy, uživatel vůbec).

Od neúspěšných plánu k současnosti

Už před pár roky jsem si říkal, že bychom do sítí našich zákazníků mohli nasazovat honeypoty. Velká část zákazníků používá virtualizaci. Myslel jsem, že bychom mohli nasazovat linuxové virtuály s nějakým open source honeypotem (seznam zajímavých honeypotů). Ušetřilo by se díky tomu za HW a SW.

Bohužel jsem tehdy nenašel vhodný software pro honeypot. To, co jsem našel, bylo vytvořeno pro použití na internetu za účelem statistik (odkud chodí útoky), nebo zachycení vzorků malware. Honeypoty byly dělané pro „hlučné prostředí“ (kde se útoky dějí co pár sekund). Já však potřeboval něco, co bylo dělané pro „sterilní/tiché“ firemní sítě, kde by se žádný útok neměl objevit. Věc jsem nakonec odložil.

Nedávno jsem narazil na přednášku „Haroon Meer / keynote – Time to play ‘D‘“ (viz video níže). Byla skvělá – ten člověk mi mluví z duše. Zkusil jsem si dohledat více jeho přednášek a narazil jsem na „Bring Back the Honeypots“ (viz video níže). Bingo, Haroon udělal přesně to, co jsem potřeboval. Honeypot pro použití ve vnitřní síti: citlivě vyladěný, který slouží jako detektor útoku. SW vydali jako open source (OpenCanary) a zároveň mají i komerční verzi Canary.tools (10.000$ za 5 zařízení).

Co honeypot OpenCanary umí

OpenCanary je open source low interaction honeypot napsaný v Pythonu. Umí „simulovat“ následující služby: FTP, HTTP, HTTP proxy, MS SQL, MySQL, RDP, SMB, SIP, SNMP, SSH, telnet, TFTP, VNC, portscan. Jakýkoliv pokus o interakci s těmito službami pak pošle e-mailem správci.

Jelikož se jedná o „low interaction“ honeypot, tak se většinou simulace služeb omezuje na přihlašovací fázi (včetně service banneru). To ale vůbec nevadí, protože už sama skutečnost, že se někdo (v e-mailovém upozornění od honeypotu dostane zdrojovou IP a zkoušené přihlašovací údaje) snaží přihlásit na nějaký FTP server, o kterém nikdo ve firmě neví, je známkou „problému“ v síti.

Jaké služby bude honeypot simulovat si navolíte sami. Ideálně to chce vyzkoušet nějakou reálnou  (aby tomu útočník věřil) a zajímavou (aby měl zájem zkusit nějakou interakci) kombinaci. Například vytvořit jeden honeypot s názvem „Server-backup“ se službami FTP, SSH a SMB a dát ho do VLAN k serverům. Pak vytvořit druhý s názvem „PC-Admin“ s VNC, RDP a MS SQL a dát ho do VLAN k PC. Myslím, že obojí bude znít pro útočníka dost zajímavě, aby si zkusil služby trochu „oťukat“ a tím se vám odhalil.

Protože se jedná o open source, můžete si chybějící služby/moduly dopsat. My například pracujeme na novém reportovacím pluginu, který bude data místo do e-mailu posílat do našeho IS (budeme mít lepší reportování a korelování logů).

Nejlepší na tom je, že OpenCanary můžete rozjet na virtuálním linuxovém serveru (pro běh stačí 256MB RAM, 1 CPU, 4GB HDD) v existující infrastruktuře. V pořizovacích nákladech vás to tak vyjde na 0 Kč. Což splňuje můj další požadavek na co nejnižší náklady. A nikdo si nemůže stěžovat na chybějící investice od vedení 😉.

Argumenty proč by to nemělo fungovat

Jak již říkal v přednášce Haroon, občas nás může přemoci nálada pro zachování „status quo“ a myšlenky, proč to nebude fungovat.

• Útočník honeypot detekuje a vyhne se mu. Ano, útočník dříve či později zjistí, že komunikuje s honeypotem. OpenCanary je stejně jen „low interaction“ honeypot. To znamená, že služby jenom napodobuje. Aby však útočník zjistil, že se jedná o honeypot, musí se s ním nejdříve spojit (např. port sken a cvičné připojení/přihlášení na nějakou službu) a o to nám jde. Naším cílem je, aby se útočník s honeypotem spojil a tím se prozradil.
• Je to pěkná technologie, ale nejdříve potřebuji nasadit AppLocker/UTM/2FA. Myslím, že nasazení honeypotu (nebo jiné detekční technologie) má před restriktivními opatřeními vyšší důležitost. Restriktivní opatření podle mě nikdy nebudou hotová. Vždy bude co nasazovat/vylepšovat a SW jsou plné ještě neobjevených chyb. Pamatujte na to, že útočníkovi stačí 1 chyba, aby se dostal do systému, zatímco vy jako admin musíte zabezpečit vše (to nejsou právě vyrovnané podmínky). O to víc potřebujete technologii, která vám dá vědět, pokud došlo k překonání restriktivních opatření.
• Honeypot bude jen další zranitelné zařízení v síti. Ano, může se stát, že zařízení někdo hackne. Avšak moc si tím nepomůže. Na zařízení není nic důvěrného, ani nemá přístup nikam, kam už by ho útočník neměl (jinak by se k honeypotu nedostal). Navíc i tak splní honeypot své poslání – předtím, než padne do útočníkových rukou, pošle zprávu o tom, že je pod útokem 😊.
• Bude se to tlouct s technologií pro skenování sítě, kterou používáme. Existuje řada řešení, od nastavení výjimky některých IP, časových pravidel, nebo úplného vypnutí modulu detekce skenování portů.

Jak to chceme nasazovat my

Chci, aby náš honeypot byla levná krabička, kterou stačí jen fyzicky zapojit do sítě a víc se o ní nestarat. A dozvědět se o ní, jen když detekuje v síti nežádoucí aktivitu (tzn. minimum času na údržbu).

Proto jsem náš honeypot postavil nad Raspberry Pi 3 Model B+ (cena i s krabičkou a SD kartou cca 1.300 Kč s DPH). Běží v něm OS Raspbian (port Debianu) s automatickými aktualizacemi, OpenCanary a agent pro náš monitorovací systém. Honeypot se umí tvářit jako zranitelný Linux i Windows server a dá o sobě vědět, jen když detekuje nežádoucí aktivitu nebo má jiné problémy (např. selže HW).

Nějaké postřehy bodově:

• Instalace: krabička se jen zapojí do sítě. Sama si načte IP z DHCP a napojí na monitorovací systém. Kdykoliv se dá přenést a zapojit do jiné sítě nebo VLANy, aniž by bylo potřeba něco přenastavovat.
• Detekce problémů: pokud se honeypot přestane hlásit (např. umře HW, nebo selže nějaká služba), monitorovací systém pošle e-mail a událost se nám zobrazí i v dashboradu monitorovacího systému.
• Detekce útoku: když honeypot detekuje pokus o útok, pošle e-mailové upozornění s logy a zároveň událost zobrazí i v dashboardu monitorovacího systému.
• Vzdálená správu: pro případ úpravy konfigurace má honeypot VPN tunel k nám do firmy (zprovoznil jsem i Teamviewer, ale VPN tunel nám umožní lepší napojení na našeho správce hesel RDM, což bude výrazně pohodlnější).

V době psaní článku mám již funkční prototyp honeypotu. Během následujících pár týdnů bych jej rád nasadil u pár našich zákazníků. Pokud se vše osvědčí, tak i u zbývajících zákazníků, kteří mají segmentovanou síť. Držte nám palce!

Závěr

Doufám, že se mi podařilo vás přesvědčit o potřebě nějaké detekční technologie. Třeba to s OpenCanary taky zkusíte. Od stejné firmy jako OpenCanary, je i služba CanaryTokens. O té se pokusím rozepsat zase někdy příště (pokud jste však viděli přednášku, kterou jsem zmiňoval, tak už vám je přínos služby jasný). Opět jako vždy budu rád za vaši zpětnou vazbu.

PS: Jestli vás OpenCanary zaujal, ale nemáte čas si s ním hrát sami, ozvěte se mi (martin.haller@patron-it.cz). Mohli bychom vám poslat náš prototyp včetně přístupu do monitorovacího systému a společně jej odladit.