Zabezpečení sítě: Tierování a PAW
Většinu majitelů a šéfů firem (firem, o které se u nás v PATRON-IT s.r.o. staráme) znám stále osobně (ačkoli už se moje pozice mění a nevídám se s nimi tak často). O to více cítím zodpovědnost za naši práci – abychom vše dělali co nejlépe (IT musí zákazníkovi fungovat rychle, neomezovat byznys a zároveň minimalizovat bezpečnostní rizika) a efektivně (aby cena správy nebyla dražší, než co společnost vydělá). Avšak čím více toho vím o počítačové bezpečnosti, tím těžší hlavu ze všeho mívám.
Už pár měsíců se připravuji, jak zde na blogu konečně začnu psát nějaké mé postřehy a dojmy z počítačové bezpečnosti. Nějaký čas mi zabralo, než jsem si ujasnil, jak to uchopit, abych se ve článcích nezamotal. Taky jsem čekal, než projdu kurzem EC-Council ECSA (EC-Council Certified Security Analyst). Nyní si myslím, že jsem připraven se podělit o to „málo“, co vím.
Jak jsem psal v Ohlédnutí za rokem 2017 v PATRON-IT s.r.o., minulý rok jsme se hodně posunuli. Tenhle rok očekávám stejně velký posun – zejména ve věcech „bezpečnosti“. Od začátku roku jsme již stihli vyměnit systém pro správu hesel (Správa hesel 2: nasadili jsme nový systém pro správu hesel), který nám umožňuje dělat nějaké věci výrazně bezpečněji, aniž by to snižovalo efektivitu. Od konce minulého roku pak pracujeme na implementaci tierování a privilegovaných přístupových stanic (už je téměř hotovo). Vycházel jsem přitom z následujících materiálů Microsoftu: Securing Privileged Access Reference Material a Privileged Access Workstations.
Tierování
Jelikož model Microsoftu vychází z předpokladu, že vše máte v jednom „forestu“ (jedné AD doméně), musel jsem si jej přizpůsobit (máme desítky zákazníků a každý má svůj forest a své „neroutovatelné“ sítě). Výsledek jsem ztvárnil do následující ilustrace.
Pravidla jsou následující:
- Zařízení a přihlašovací údaje jsou roztříděny do tierů (vrstev). Roztřídění je prováděno dle „důležitosti“/ „důvěryhodnosti“ zařízení. Pro výsledek pak platí: kompromitace zařízení/přihlašovacích údajů z jednoho tieru znamená kompromitaci všech tierů pod ním. Z toho plyne, že čím vyšší tier (vyšší dle pozice na obrázku 😊), tím je nutné mít vyšší zabezpečení.
- Přihlašovací údaje z každého tieru mohou být zadány pouze na zařízeních v daném tieru, nebo vyšším (např. připojení skrze RDP posílá [podle nastavení] už. jm. i heslo na cílovou stanici, tzn. je to jako kdybyste tato pověření zadali na této stanici).
- Zařízení z nižšího tieru nesmí NIKDY spravovat zařízení z vyššího tieru a zařízení v rámci tieru by neměla spravovat sebe navzájem – pokud je to možné (např. z jednoho member serveru bych se neměl přihlašovat na druhý).
Na obrázku je vidět, že jsem přidal řadu tierů (s negativním číslováním), které patří našemu prostředí. Je zřejmé, že kompromitace našeho prostředí může mít za následek kompromitaci prostředí všech zákazníků (nejhorší scénář).
Prostředí zákazníků jsou od sebe izolovaná, tzn. kompromitace jednoho zákazníka nemá vliv na prostředí jiných zákazníků.
U zákazníků, kteří používají virtualizaci, oddělujeme Hyper-V hosty (spolu s managementem infrastruktury) od zbytku sítě (již jsem psal v Zálohování – jak nepřijít o data při útoku hackera (praxe)) a do ní není možné se z nižších tierů (samotné LAN zákazníka) dostat.
V pravé části obrázku jsou také šipkami naznačeny úrovně přístupů, které u nás ve firmě používáme. Každý z nás má jen taková oprávnění a přístupy, které ke své práci potřebuje.
Modré obdélníky v obrázku jsou zcenzurované 😊 Přemýšlel jsem, zdali tam informace ponechat, ale nakonec jsem je schoval. Na jejich místě je klasifikace významných aplikací a systémů, které používáme (např. centrální konzole, systém pro správu hesel) – abychom věděli, jak moc je musíme chránit, a co by se stalo, kdyby byly prolomeny.
Privilegované přístupové stanice (PAW)
Protože počítač se dá hacknout i skrze prohlížeč a u žádného programu, který z internetu stáhnete, nemáte jistotu, že je úplně bezpečný (např. kauza s CCleaner), rozhodli jsme se na všechny naše stanice, ze kterých provádíme vzdálenou správu (tzn. přistupujeme z nich k zákazníkům a heslům), zavést „přísné“ restrikce.
Samozřejmě můžete namítnout, že u open source nic takového nehrozí. Ale ruku na srdce, kdo z nás ty zdrojové kódy prochází (viz OpenSSL Heartbleed bug). Taky si můžete myslet, že jsem paranoidní, ale kompromitací našich PAW může dojít ke kompromitaci všech našich zákazníků. To nechci riskovat.
Odbočka: Začátkem roku jsem psal o hračkách od Hak5 (Hračky na hackování: Hak5 Bash Bunny a Hračky na hackování: Hak5 Packet Squirrel). Vypadá to, že již brzy budu mít na toto téma připravené školení (praktickou ukázku). Minimálně s vámi nasdílím slajdy. A když se nebudu stydět, natočím i video 😊).
V současné době máme na PAW nasazeno:
- APP whitelisting: je povoleno pouštět pouze vybrané aplikace (nejde tedy pouštět ani nic, co je z internetu, nebo přineseno na USB flash).
- Least privilege: nikdo nemá na PC administrátorský přístup (heslo zná a úpravy můžete dělat jen pár mých kolegů).
- Šifrování: na všech PC je nasazen Bitlocker (ochrana proti fyzickým útokům).
- 2FA: pro přihlášení na stanici lokálně i vzdáleně je třeba 2FA (stejně tak máme 2FA do všech dalších systémů).
- Antivirus: ESET s vlastními HIPS pravidly
- Další opatření: Windows Security Baselines, automatické uzamykání PC, zakázané NTLM.
Když je třeba otestovat nějaký program, děláme to ve virtuálních strojích (ty nemají přístup do naší LAN), které máme na svých PAW. Když se s testem skončí, vracíme pak virtuál zpět k předchozímu snapshotu (na virtuálech se pro změnu nikdy nesmí objevit nic důvěrného).
Závěr
Někteří lidé, když nás poznají, jsou překvapení, že k práci nepoužíváme notebooky. Přiznávám, že je někdy vtipné, stát vedle racku a volat kolegovi na „bázi“, ať mi něco přenastaví nebo prověří, protože se na ty zařízení v racku nedá dostat. Avšak přijde mi lepší, když pracovní stanice zůstávají v práci a slouží jen pro práci. Kolegové pak mají doma pro osobní účely své soukromé notebooky.
Nyní jsem zase zvědavý – jak se vám článek líbil? 😊 Něco překvapivého jste se dozvěděli? Říkáte si, že se v něčem mýlím? Nenechávejte si to pro sebe a dejte mi vědět, opravdu každé zpětné vazby si cením.
Zajímá vás konkrétní téma, které třeba v práci řešíte? Byli byste rádi, kdybych o tom napsal – jak to řešíme u nás? Napište mi sem nebo i do soukromé zprávy (martin.haller@patron-it.cz).
Budu rád, když společně budeme dělat IT lépe (co nejlépe)! ✌ 😊
Diskuze k článku
Karlos
03. 04. 2018 v 23:33
Díky za článek. Ten APP whitelisting řešíte přes Software Restriction Policies primo ve Windows nebo pomoci aplikace (antivir atd.)?
Odpovědět
Martin Haller
04. 04. 2018 v 22:56
Jj, řešíme to přes SRP, jak píšeš. Vím, že to asi není „the best“, ale takhle to můžeme nasadit všude (tzn. podporuje to standardizaci) a poměr cena/výkon vcelku funguje. V PowerShell v5 dokonce MS přidal i určitou „podporu“ SRP/AppLockeru (na skriptovací jazyky je SRP však stále poměrně krátký – na to zase máme HIPS v ESETu). Mám v plánu to někdy začlenit i do monitorovacího systému.
Odpovědět
Petr Tichý
05. 04. 2018 v 08:17
Díky za článek, je vidět, že bezpečnost berete vážně i do detailů. Co se mi líbí, je poslední věta „Budu rád, když společně budeme dělat IT lépe (co nejlépe)“, proto rád čtu Vaše články, kde zjištuji co děláme podobně a co můžeme dělat jinak a lépe.
Odpovědět
Martin Haller
05. 04. 2018 v 22:49
Děkuji za pochvalu. Snažíme se dělat co je v našich silách :). Sám vím, jak nám pomůže když nám dá někdo praktický tip (co se osvědčilo a co ne). Ušetří nám to vždy spoustu nervů a času – přeci jen z úst obchodníků zní každá technologie skvěle a funkčně :). Proto se i my snažíme sdílet naše zkušenosti.
Odpovědět
David Křeska
26. 07. 2018 v 08:23
Díky za článek. Je fakt, že NTB běžného uživatele, určený k práci a používaný i k soukromé činnosti doma, bez restriktivních omezení (hlavně v technologických firmách) je takovou malou časovanou bombou. 😀
Odpovědět
Martin Haller
02. 08. 2018 v 17:52
Na tož pak NB admina, který se z něj připojuje kamkoliv :).
Odpovědět
Jiří Pavlík
21. 11. 2018 v 14:24
Děkuji za velmi dobře zpracovaný článek. Narazil jsem na něj sice náhodou, ale o to více jsem mile překvapen, také se (až příliš) často setkávám spíše se správci, kteří se v přístupu ve správcovství sítě, od dob Win2003, moc neposunuli.
Abych i já trochu přispěl, tak osobně se snažím všude tlačit metodu, že jikdo (ani admini) nejsou správci svých stanic, v kombinaci s Applockerem (Path whitelisting). V korporacích se mi prozatím PAW nepodařilo prosadit v té variantě, jak to doporučuje Microsoft, ale spíše v kompromisním řešení Admin Jump Serveru v dedikované VLANě, a oddělenými účty pro CommonUsers, WKS admins, SRV admins, DomainAdmins.
A co se týče Hypervizorů, tam to většinou končí izolovanou VLANou a shielded VMs. Tady jsem taky v údivu, jak často se ochrana VMs kontejnerů podceňuje.
Odpovědět
Martin Haller
21. 11. 2018 v 14:59
Díky za komentář. S těmi správci mám stejnou zkušenost. Potkávám hodně těch, co se dlouho nikam neposunuli a věci dělají tak nějak „postaru“. Na druhou stranu, technologie jdou tak rychle dopředu, že není vůbec jednoduché držet krok.
S těmi Shielded VMs a Applockerem to máte fajn. My zákazníky s Enterprise edicí Win nemáme, tak jedeme stále na SRPu. Doufám ale, že se podaří např. ESETu zabudovat nějaký appcontrol do jejich produktu. To by nám pomohlo, protože bychom mohli povolené aplikace spravovat centrálně pro všechny zákazníky (ušetřilo by čas, zjednodušilo prostředí a umožnilo nasazovat i tam, kde nemají AD).
Jak jsme u nás nasazovali PAW, tak jsem se bál, že se kolegům nebude líbit nemít admin práva a ještě mít bloklé spouštění aplikací. Nakonec to vzali v pohodě (vysvětlil a ukázal jsem jim proč to děláme). Teď má každý na PC jeden nebo dva virtuály, které si snapshotují a jsou v pohodě. Dalším krokem je jim na pracovních PC zakázat internet …. tak uvidíme :D.
Odpovědět
Aleš Blinka
02. 05. 2020 v 16:50
Dobrý den Martine. Jak se díváte na to, že administrátor používá pro administrátorskou práci PAW + dedikovaný admin účet = řekněme pro větší zásahy na DC a jiných serverech. K serveru se připojuje přes RDP
Správu účtů v AD (reset hesla, vytvoření nového uživatele…) dělá z notebooku a účtu určenému pro běžnou práci. Tuto správu nedělá tak, že by se připojil vzdáleně k serveru, ale využívá RSAT a kontejner s běžnými uživateli je mu nadelegován = může upravovat jen uživatele. Ne celou doménu nedej Bože admin účty.
Lze to považovat za bezpečnou práci admina?
Odpovědět
Martin Haller
04. 05. 2020 v 08:45
Dobrý den, Aleši, díky za popis situace. Nad zabezpečením přemýšlíte dobře a je fajn že je zaveden PAW a dedikovaný admin účet.
Jestli je to dostatečně bezpečné, nebo ne záleží na tom jak moc cenná data chráníme, kolik na to máme prostředků (peníze, čas) a jak moc nebezpečný je „nepřítel“ :). Bezpečnost může být vždy vyšší i nižší. Nicméně co popisujete zní fajn.
Pokud byste to chtěl posunout o krok dál, tak bych správce nenechal dělat správu uživatelů z běžného účtu a stanice (usuzuji to na základě toho že používá RSAT na stanici). Jde totiž o to, že cesta hackera není vždy přímá, ale může to být přes více hopů:
* hacker získá přístup k běžnému účtu správce, skrze který spravuje uživatele
* to mu umožní získat kontrolu nad zbytkem běžných uživatelů a skupin
* díky tomu se dostane na RDP nějakého serveru
* tam získá práva admina (privilege escalation)
* počká si, až se tam připojí domain admin a ukradne jeho oprávnění
Samozřejmě nevím, jestli u Vás je takováto cesta útoku možná, nebo ne. Vše záleží na situaci i ostatních nastaveních (třeba by to šlo jiným směrem). Chci jen poukázat na to, že současní hackeři jsou stále lepší v lateral movementu. Co jsem popsal výše dokáží zrealizovat. V podstatě je na to i nástroj https://github.com/BloodHoundAD/BloodHound . Ten si vyčte veškeré informace ze sítě (AD + stanic) a pak útočníkovi ukáže jakou cestou se z běžného uživatele dostat až k domain adminovi.
Pro info o BloodHoundu doporučuji kouknout na https://www.youtube.com/watch?v=lxd2rerVsLo .
Odpovědět