Az ellopott tartományvezérlő esete

A szerverszobában, a szokásos hétfő reggeli névsorolvasáson azt vesszük észre, hogy eggyel kevesebb tartományvezérlő válaszolja azt, hogy ‘jelen’.
Mi ilyenkor a teendő?
Először természetesen a pánik. Egy-két perc dühödt headbanging a szerverrack-en határozottan ki tudja tisztítani az ember tudatát.
Amint elül a pánik, az ember kezdi végigondolni a lehetőségeit. Sajnos ekkor már késő. Ugyanis nagyon gyorsan kellene cselekednie, hogy csökkentse a hálózatát fenyegető veszélyt.
A legjobb, ha már azelőtt elgondolkodik a helyzetről, mielőtt elcsakliznák tőle a gépet.

Ezt tette Steve Riley a 2006 szeptemberi Technet Magazinban.
Miután végiggondolt mindent, részletesen kielemezte a lehetőségeket, ezenkívül számbavett minden rejtekutat – a következtetését egy mondatban foglalta össze: ember, építsd újra az egész AD erdőt.
Borzasztóan hangzik. (Eltekintve attól, ha a kedves olvasó nem pont AD telepítésekből él.) Ennél még a korábbi pánik is kellemesebb volt.
Ezt Riley is elismeri, ezért hívja fel a figyelmet arra, hogy tegyünk meg időben mindent a tartományvezérlőink védelmében.

Azaz:

• Láncoljuk le őket valami elvihetetlen tárgyhoz. Ha ugyanezt elektronikusan is meg tudjuk oldani az még jobb.
• A címtárat több erdőből építsük fel, majd vezessünk be szelektív autentikálást.
  Azt hiszem, ez megér némi magyarázatot. Először is, ilyesmi csak Windows2003 címtárban létezik. Másodszor – és ez nekem is újdonság volt – a Microsoft szakított az eddigi ‘használj egy erdőt és egy tartományt’ modellel. Feltételezem, nem kis mértékben a szelektív autentikáció miatt.
  Mi is ez pontosan? Addig gondolom oké, hogy ha egy cég egy címtárban több erdőt használ, akkor azokat egy forest root-on keresztül össze is kell trustolnia. Itt, a truston lehet beállítani az autentikáció típusát: ez lehet teljes vagy szelektív. A teljes azt jelenti, hogy az egyik erdőbeli felhasználó (Farkas), amikor megpróbálja elérni a másik erdőbeli erőforrást (Piroska), akkor megadja a felhasználói nevet és jelszót, majd az erőforrás jogosultsági listája alapján vagy eléri azt, vagy sem. Ezzel szemben a szelektív autentikációnál már az is egy jogosultság, hogy a Farkas egyáltalán autentikálhatja-e magát.
  Ebben az esetben ha lenyúlják az egyik erdő tartományvezérlőjét, akkor csak az illető erdőt kell újrahúzni, illetve azokat az erőforrásokat megpiszkálni a többi erdőben, amelyek egyáltalán autentikálhatóak voltak a kompromittált erdő felől.
• Telepíts read-only DC-t.
  Ez – mondjuk úgy – jótanács a jövőre nézve. Read-only DC majd a Longhorn Server családban lesz, mint ahogy ezen a blogon tanult kollégám nagyon alaposan ki is vesézte a témát.
• Végül Riley leírja, hogyan kell gyorsan, hatékonyan címtárat tervezni. Gondolom azért, hogy újratelepítéskor nem kelljen azon agyalnunk, milyen elvek mellett is építettük fel anno az egyes alrendszereket.

Nos, oké. Riley letette a voksát.

Ekkor lépett színre Joe. (Joe Richards az egyik személyes kedvencem. Mint írtam korábban, a fiú Directory MVP, néhány nagy sikerű segédprogram megalkotója és a maga kendőzetlen, nyers modorában egészen jó cikkek szerzője.)
Szóval Joe rögtön azzal kezdi, hogy ez egy nagyon jó a kérdés, de szerinte teljesen rossz a válasz. Nem is vacakol sokat, felsorolja a _rögtön_ lezongorázandó teendőket:

• Töröljük az ellopott tartományvezérlőt a címtárból. Azonnal. Gondolkodás nélkül. Erre teljesen jó az NTDSUTIL segédprogram. (Én fűzném hozzá, hogy ha volt a DC-n valamilyen FSMO, akkor azt természetesen el kell tőle rabolni.)
• Reseteljük mindenkinek az accountját, akinek lokális belépési lehetősége volt a tartományvezérlőkön. (Népszerűségi indexünk egész biztosan fel fog szökni – de erről majd később.)
• Reseteljük mindenkinek az accountját, akinek file/registry/services módosítási joga van az erdő tartományvezérlőin.
• Reseteljük mindenkinek az accountját, akinek jogosultsága volt bármilyen AD-hoz kapcsolódó alkalmazás (Exchange, SMS, MOM, stb…) menedzseléséhez.
• Ha a fenti adminok közül valamelyiknek van nem admin felhasználója, reseteljük azt is. Lehet, hogy az illető ugyanazokat a jelszavakat használta.
• Reseteljük az összes DC jelszavát. (Segítségképpen megadja, hogy a PSExex és a NetDom resetpwd lesz a mi barátunk.)
• Reseteljük a krbtgt tartományi felhasználó accountját. Méghozzá kétszer. Ekkor fognak elveszni a korábbi TGT-k. Szerencsére. (TGT: Ticket Granting Ticket; jegy, amellyel jegyet lehet igényelni a Kerberos szervertől.)
• Reseteljük mindenkinek az accountját, akinek joga volt a normális felhasználói aktivitáson túl belepiszkálni a címtárba.

És most el lehet kezdeni filozofálni. Joe véleménye szerint a fenti adminisztrátori teendőkhöz 2-5 adminisztrátor bőven elegendő. Határozottan kijelenti, hogy ennyi accounttal végigzongorázni a fenti listát, másodpercek kérdése. Ha több accountunk van, érdemes szkriptelni. Ha ez a gyorsaság nem megy kézségszinten, nos, akkor Joe szerint kutyaütők vagyunk, nem rendszergazdák. A címtár a hálózat legnagyobb értéke, akinek a dolga ezt védeni, annak nagyon ott kell lennie a szeren.

A másik filozófikus kérdés: egyeztessünk-e előtte? Joe szerint semmiképpen sem. Tegyük a dolgunkat. Itt másodpercek számítanak. És ha azok az opciók, hogy lesz néhány parázs veszekedésünk vagy egy korrupt címtárunk… akkor mindenképpen az elsőt kell választanunk. Sőt, Joe szerint már akkor elveszítettük a csatát, ha éles helyzetben egyáltalán azon filózunk, hogy értesítsük-e őket vagy sem.

A fentieken kívül két dolgot kell még megtennünk:

• Járassuk le a sárga földig az összes felhasználó jelszavát. Előtte azért szóljunk oda a helpdesknek…
• Figyelmeztessük az összes rendszer összes service account tulajdonosát, hogy egy órán belül változtassák meg az accountok jelszavát. Ha nem teszik meg, változtassuk meg mi. Jobb utólag röviden elnézést kérni, mint hetekig tartó türelmet később. Egy ideiglenesen leállt alkalmazás nem ugyanaz a nagyságrend, mint egy korrupttá vált címtár. (Nem tudom… azért a banki alkalmazásoknál nekem lennének kétségeim. Ezzel – Joe szerint – meg is buktam. Ő ugyanis a nem tervezett leállítás viszonylag rövid idejét veti össze a címtár – újrafelépítés okozta – hosszabb leállás idejével. Igenám, de az utóbbi tervezett. _Normális_ leállás után a cég addig kitalál valami metódust, mittudomén, papírnoteszt és postagalambot, meg egy adatfeldolgozási technikát, hogy hogyan lehet majd ezeket beledolgozni az újra felállt rendszerbe. Lehet, hogy ez kevesebb költséggel jár, mint egy inkonzisztens adatbázis.)

Végül természetesen a hapi szót kerít arra, hogy régen rossz, ha egy ilyen helyzetben improvizálnod kell. Hiszen rég a fiókban – és a megfelelő emberek fejében – kellene lennie a haváriatervnek.
Hogy miért is jó egy ilyen terv? Itt inkább idézem Joe-t:

A. Understand what your weaknesses are now so you can correct them.
B. Be able to block things others try to bring into your environment that will add more weaknesses later.
C. Have something you can follow when the fan and the excrement meet f2f.

Itt a vége felé térjünk vissza egy kicsit a realitás talajára. Azért ma már szinte mindenütt természetes, hogy van valamilyen szerverszoba – és ezek valamilyen formában zárhatók is. Ilyen helyekről szervert ellopni már nem olyan egyszerű.
Csakhogy… nem csak cégközpontok vannak a világon, hanem telephelyek is. Márpedig mifelénk még mindig elég drága a sávszélesség ahhoz, hogy érdemes legyen távoli helyekre is egy-egy lokális tartományvezérlőt lerakni. Általában az is igaz, hogy ezek a vidéki DC-k leginkább munkaállomás kategóriájú gépek, lelökve valamelyik sarokba – hiszen a plusz gép költségét is nehezen nézik el az informatikának, nemhogy még szerverszoba is legyen a telephelyen. Nos, ezeket már könnyű megcsapni – márpedig akármennyire vidéki is a DC, de ott van rajta a tartományi névtér írható változata, az egész erdő konfigurációs névterének írható változata és az egész erdő sémájának olvasható változata.
Ijesztő.
Erre lesz majd megoldás a Read-only DC – hiszen az azon végrehajtott Ad változtatások nem replikálódnak szét a címtárban, így hiába dugná vissza a gonosz tolvaj a preparált tartományvezérlőt, nem érne vele semmit. (Ettől függetlenül a tartomány felhasználóinak a jelszavát feltörheti, tehát a fentebb írt jelszó resetelések tartományi szinten továbbra is meg kell történjenek.)

Nos, ennyi. Elolvashattunk két véleményt. Nekem a magam részéről Joe elképzelése jobban tetszik – különösen azért, mert felhívja a figyelmet, hogy lennie kell egy alaposan kidolgozott tervnek erre az esetre is.
Tényleg, nálatok van?