Month: October 2006

Anima

Huh, de meg tudnám símogatni laposvassal azt a szoftvertervezőt, aki kitalálta, hogy az ISA2004 admin MMC jobb oldali ablaka animálva bújjon elő, meg el. Ekkora marhaságot…
Most képzeljük el: ott ül az admin egy 128K-s vonal rosszabbik végén – rajta kívül még húszan használják a drótot – és szeretne ISA szervert adminisztrálni. Ahhoz, hogy mindent lásson, be kell zárnia a panelt. Ahhoz, pl. hogy a policy elemeket megvizsgálhassa, ki kell nyitnia. Egy kinyitás kb. másfél perc. Pusztán csak azért, mert a művelet animálva történik, azaz vagy tízszer megjeleníti az a gyökérkefe a panel egyes részeit.
Hihetetlen. Egyébként sem szeretem a túlcsícsázást, de amikor az ráadásul a használhatóság rovására megy, az végképp ki tudja nálam verni a biztosítékot.

Hol a rekord?

Szerverüzemeltető kollégám furcsa jelenséggel fordult hozzám: képtelen kitörölni egy reverz DNS bejegyzést. Kitörli, de az visszamászik. Nézzek már rá.

Első blikkre nem villanyozott fel túlzottan az eset. Lehet mögötte replikációs probléma, lehet valami DHCP félrekonfigurálás – még az se kizárt, hogy a kliensen bolondult meg valami.

Leteszteltem. Kitöröltem a kérdéses rekordot, majd egyből nyomtam egy F5-öt. A rekord visszajött. Egyből. Ejha. Az összes prekoncepció ment a kukába: ilyen gyorsan egyik sem hozza vissza a törölt rekordot. Átmentem egy másik tartományvezérlőre, azon is nyomtam egy törlést, F5 – a rekord megint ott volt. (Ha esetleg az eddigiekből nem lenne egyértelmű, a zóna AD integrált volt.)

Rögtön felcsillant a szemem – ez nem egy szokványos feladat.
Okoskodjunk.
Mivel a zóna AD integrált, így tulajdonképpen arról van szó, hogy valamiért sikertelen lesz egy törlési művelet a címtárból. Legalábbis ha GUI-n keresztül próbálom végrehajtatni. De pontosan mit is akarok törölni?

Itt jött egy hosszú sóhaj. A magam részéről még erősen emlékszem arra az időkre, amikor a zónafájlok könnyen átlátható szöveges fájlok voltak, olvasásuk, szerkesztésük teljesen egyszerű volt. Most viszont törhettem a fejem, hol is vannak egyáltalán az adatok.

Tényleg, hol? Tudjuk, hogy elméletileg a zóna és a tartomány még csak köszönő viszonyban sincsennek egymással. Úgy értem, egy DNS szerverre tetszőleges számú AD integrált zónát is felvehetek, miközben a konkrét tartományhoz tartozó zóna csak egy a sok közül és nem is feltétlenül kell jelen lennie minden DNS szerveren. Ergo a zóna adatai akár a konfigurációs, akár a tartományi névtérben is lehetnek. (A sémában azért csak nem.;)
Lehetne ugyan guglizni, de jelen esetben érdemesebb inkább becsavarogni a névtereket. ADSIEdit a jóbarátunk, nézzük meg először a konfigurációs névteret, úgyis az a kisebb. Itt bizony nincs. Marad a tartományi – és ott is van: system/microsoftdns/ folder alatt jámborul vigyorognak ránk a zónák.

Így néz ki egy AD integrált reverz DNS zóna

Kitérő:
Attól függően, hogy W2k vagy W2k3 címtárunk van, nagyon eltérő képet kapunk a fenti folderben. W2k címtár esetén mind a reverz, mind a forward zónák ott figyelnek a Domain névtér megfelelő folderében. Ezzel szemben W2k3 címtár esetén a forward dns zónák önálló névteret kaptak a Domain névtér alatt, méghozzá rögtön kettőt: DomainDNS, illetve ForestDNS névvel. A reverz zónák maradtak a régi helyen.
Most szerencsénk van, mert éppen a reverz zónát akarjuk piszkálni. De mi van akkor, ha valamelyik forward zónát szeretnénk direktben kibelezni? Az ADSIEdit csak a klasszikus névtereket adja fel kapcsolódásra és itt nem látszanak az alá rejtett névterek. Igaz, van egy olyan opciója, ahol tetszőleges DN-t is megadhatok kapcsolódásként. Már csak azt kellene megtudni, mi is a DomainDNS partíció DN neve… de ezt meg a konfigurációs névtérből tudjuk kinyerni, itt ugyanis van egy Partition bejegyzés, ahonnan kiolvashatók az egyes partícók adatai. (Az ldp érdekes módon nem vacakol ennyit, egyből mutatja a Domain névtér alatt a DNS névtereket is.)
Huh.

A képen már a sikeres kapcsolódást láthatjuk.

Innentől már miénk a terep. Szépen megkeressük a minket érintő objektumot és… hoppá. Melyik a módosítandó tulajdonság? Ilyenkor segít az ldp. Ugye tudjuk (tudjuk, mert már írtam róla), az ldp mutatja meg egy objektum összes értékkel bíró tulajdonságát. Innentől már nem nagy ügy kispekulálni, hogy minket bizony a dnsrecord tulajdonság érdekel.

A kisebbik baj, hogy a tulajdonság értéke hexadecimális kódolású karakterlánc. A közepes baj az, hogy nem csak a ptr rekordhoz tartozó karakterlánc van ebben a tulajdonságban, hanem egyéb adatok is. A legnagyobb baj viszont az, hogy ha visszamegyünk az ADSIEdit-hez és lekérjük ezt a tulajdonságot, akkor csak az első néhány bájtot látjuk. A legeslegnagyobb baj pedig az, hogy nincs a felületen modify gomb – így csak törölni vagy hozzáadni tudunk, de természetesen egy ilyen bonyolult formátumú tulajdonságnál semmi esélyünk sincs, hogy majd begépeljük a frankót. Az ldp-vel nagyjából ugyanez a helyzet, bár ott is tudnánk módosítani a tulajdonság értékét, de nincs olyan lehetőség, hogy a jelenlegi érték jelenjen meg egy textboxban, én meg majd editálom és utána visszaírom.

Kitérő:
A konkrét esetben tényleg így jártam, tekintve, hogy az még W2k címtár volt. Kíváncsiságból megnéztem a tesztelésre használt W2k3 címtárban és voilá, ott már volt modify gomb az ADSIEditben. Persze itt sem egyértelmű elsőre, hogy mit kell módosítani, de az ldp segítségével megfejthető, lásd alábbi ábrák.

Ilyenkor gördül végig egy könnycsepp a rendszergazda arcán és elérzékenyülve gondol vissza a Quick Editorral karbantartott zónákra.

Az mindenesetre már látszott a konkrét feladatnál, hogy finom műtétre nincs lehetőségem. (Az eredeti feladat tkp. az lett volna, hogy módosítsuk a ptr rekord értékét.) Ha szikével nem megy, vegyük elő a baltát: töröljük a francba az egész objektumot. Végülis, bármennyire bonyolultan néz is ki, csak egy ptr rekordról van szó.
És ez már meghatotta. Amint a törlés ténye szétreplikálódott, az a bizonyos ptr rekord végképp megszűnt létezni – kicsiny lelke jelenleg a semmi szélén üldögél és József Attilát olvasgat.

Gondoljuk végig, mi is történt. Törölni akartunk egy ptr rekordot. A kezelői felületről nem ment. Bele akartunk nyúlni az adatbázisba – és itt kezdett el izgalmas lenni a játék: rendszerezni kellett a tudásunkat, hogy ebben a nem is túl egyszerű környezetben kisilabizáljuk, hol is lehet a minket érintő adat. És amikor meglett, kiderült, hogy gyakorlatilag nem editálható, tehát csak és kizárólag a del billentyűvel avatkozhatunk be hatásosan. (Ez a billentyű egyébként a legtöbbször tényleg nagyon hatásos.)
De végül sikerült. És lassan már a címtár felépítését is kezdjük érteni.

Ki őrzi az őrzőket?

Jim McBee dobott fel egy érdekes témát a blogjában. Azt mondja, haknikörútjain rendszeresen visszatérő kérdés, hogyan is lehet védekezni egy rendszergazda ellen… hogyan tudják elérni, hogy egy rendszergazda sehogyan se legyen képes elolvasni az alkalmazottak leveleit.

Hát, Árpád, ez bizony fogós probléma. Feltételezem a tisztelt olvasó hozzám hasonlóan technikai szemléletű (aka kockafejű), így rögtön el is kezd meditálni, milyen eszközökkel lehetne korlátozni egy feltételezett rosszindulatú rendszergazdát.
Pedig nem ez a helyes út. A leghatékonyabb eszköz ugyanis a munkakönyv, illetve kapcsolt területei. Egy rendszergazda igenis legyen úgy megfizetve, hogy ne könnyen csábuljon el. Mindemellett legyen annyira sarokba is szorítva, hogy meg se nagyon forduljon a fejében, hogy titkok között turkáljon. De leginkább a HR próbálja meg kiszűrni, hogy a rendszergazda a megfelelő pszichikai alkattal bírjon.
Ez ugyanis egy bizalmi állás. Igaz, nem egy döntésekben erős pozícióról van szó, de tény, hogy a rendszergazdának – szükségszerűen – mindenhez van kulcsa.
Nagyon sok cég elköveti azt a hibát, hogy spórolás címszóval a titkárnő Marika unokatesóját, Lajcsikát alkalmazza ócsóért, mert azt a pár gépet ő is el tudja kezelgetni. Technikailag valószínűleg igen – de elképzelhető, hogy a felelős, érett gondolkodásban Lajosunk jelentős deficittel bír.

No, ennyi körbejárás után nézzük meg, milyen technikai eszközeink vannak a kockázat csökkentésére:

  • Lehetőleg alkalmazzunk kevés rendszergazdát.
    Ezt ugye nem nagyon kell magyaráznom. Minél kevesebben bírnak korlátlan joggal, annál kisebb az esélye, hogy valamelyik személy bekattan a Fásy mulatón és eladja a cég email címlistáját rosszindulatú szpemmereknek.
  • Lehetőleg alkalmazzunk sok rendszergazdát.
    Lehet, hogy most kicsit következetlennek tartasz, pedig nem vagyok az. Rendszergazda és rendszergazda között óriási különbségek lehetnek, mondjuk hatóerő tekintetében. Lehetnek rövid hatótávolságú rendszergazdák és lehetnek interkontinentális rendszergazdák. A lényeg: a feladat delegálás. Ha meg tudod oldani, hogy minden jól körülírható feladatnak – rendszernek – önálló gazdája legyen, aki csak és kizárólag egy konkrét területhez fér hozzá Atyaúristensz joggal, akkor jelentősen csökkentetted a – felettébb kockázatos – omnipotens emberek számát.
  • Auditálj.
    Természetesen beállíthatsz mindenféle korlátozásokat arra nézve, hogy akármilyen rendszergazda se tudjon belenézni a felhasználók postafiókjaiba. És természetesen ugyanez az akármilyen rendszergazda minden további nélkül el tudja távolítani ezeket a korlátozásokat. Csak abban bízhatsz, ha arra mész rá, hogy legalább mindennek maradjon nyoma. (Természetesen az auditálást is ki lehet kapcsolni – de remélhetőleg olyan szintű adminból, aki ezt megteheti, nem alkalmaztok túl sokat.)
  • Ne legyenek funkcióhoz rendelt rendszergazdáid, mely technikai accountok mögött több személy is rejtőzhet. Ilyen esetben az audit kábé annyit ér mint hajszárító hurrikán ellen.
  • A kényes felhasználóknál használhatsz DRM-et illetve PKI-n alapuló titkosítást (S-MIME). Természetesen itt is figyelned kell, hogy keymaster-ből ne legyen túl sok.

Nos, ennyi. Felhívom a figyelmedet, hogy ha alaposan átnézed a fenti pontokat, akkor fel kell tűnjön, hogy minden megoldás alapja a feladatkör/jogosultság delegálás. Amíg ezt nem rendezed, addig nem lesz értelme semmilyen technikai csodaeszközt csatasorba állítani.
A józan észnél nem sok hatékonyabb fegyver létezik.