Category: security

Hoppá

2017-03-29 / / 1 Comment

Ezt az írást érdemes alaposan átolvasni – és végiggondolni. Az internet alapműködését feszegeti a téma.

A lépések számottevő problémát jelentenek, a Symantec-csoporthoz tartozó CA-k (a Symantec, VeriSign, az Equifax, a GeoTrust, a Thawte, RapidSSL és más kisebb márkák) által kibocsátott tanúsítványok ugyanis széles körben elfogadottnak számítanak.
– link –

Azaz a Google, konkrétabban a Chrome felül fogja bírálni a fenti CA-k által kiadott tanúsítványokat, sőt, az is benne van a pakliban, hogy nem fogja elfogadni ezeket. Ugye te is észrevetted a VeriSign nevét a felsorolásban? Az sem érdektelen, hogy a Symantec válaszként beszüntette az RA programot, azaz innentől a fenti CA-k mellett nem működhetnek külsős RA szolgáltatók.

AntiSpam Update

2012-11-29 / / 6 Comments

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Aláírva

2011-11-07 / / 1 Comment

Haladni kell a korral, mese nincs. Nem lehetünk annyira kiberszerencsétlenek, hogy nincs saját tanúsítványunk. Hiszen jó dolog a nick, meg az avatar, de mennyivel vagányabb már, ha tanúsítvánnyal tudjuk igazolni, hogy mi vagyunk mi.

Oké, értem én, a tanúsítványos játék soha nem volt igazán egyszerű. Illetve, ha megpróbáltuk egyszerűvé tenni, mindjárt drága lett. Csináljunk saját CA szervert? Hát, az elég macera, ráadásul ki fog csak úgy megbízni a szerverünkben? Kérjük meg az embereket, hogy léccilécci tegyék a szerverünk tanúsítványát a Trusted CA Servers tárolójukba? Aha. Akkor már inkább vegyünk egyet valamelyik nagy CA szervezettől. Persze, ez pénzbe kerül.
A jó hír az, hogy nem mindig. Ha például magánszemély vagy, akkor a Comodo-tól(1) ingyen kapsz levelezésre használható tanúsítványt.

(1) Vagy akinek jobban tetszik, InstantSSL. Mindenesetre, ahogy maguk állítják, ők a második legnagyobbak a piacon, azaz ahhoz mindenképpen elég nagyok, hogy az általuk kiadott tanúsítványt valószínűleg mindenhol elfogadják a világon.

Meggyőztelek? Remek. Akkor nyomjál is rá bátran a megrendelő gombra.
Illetve, ne, várj egy kicsit. Milyen böngészőt használsz?

Elmesélem, hogyan jártam. Miután megrendeltem a tanúsítványt, közölték, hogy nagyon örülnek és küldenek a subject-ként megadott emailcímre egy levelet, melyben leírják a további teendőket. Ez nem volt bonyolult, rá kellett kattintani egy linkre. (Vagy elmenni egy weboldalra és beírni a levélben megadott emailcím/jelszó párost.) Oké, katt. Nagy büdös error.

“The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID).”

Mi van? A Comodo-t már megint meghekkelték? Márpedig bármelyik módszerrel próbálkoztam, mindig ezt az üzenetet kaptam. Benéztem a böngésző (Chrome) beállításai közé, hátha valahol túl szigorúra van állítva a tanúsítványok kezelése, de nem találtam semmit.
Jó, nézzük a többi böngészőt. Kimásoltam a linket. Firefox. Egy abszolút értelmezhetetlen hibaüzenetet kaptam. Opera. Lefagyott. IE9. Na, ez végre meglepően őszinte volt, azt írta, hogy szerinte nem a megfelelő böngészőt használom.

Ilyenkor marad a gugli. Nos, mondanom sem kell, az üzenetnek semmi köze a valósághoz. Szokás szerint.
John Robbins írta le a frankót, igaz, ő egy fizetős Comodo (kódaláíró) tanúsítvánnyal szívott.

A quick round with Comodo support and I find out Chrome and IE 9 are definitely not supported. They sent me a link with their instructions for downloading the certificate. The first line had me shaking my head:
1) Open http://www.instantssl.com/code-signing/ in Internet Explorer (IE) 6 or 7 with ActiveX enabled. (Windows XP preferred)

Hát, izé. Most akkor szedjem le az IE9-et, tegyem fel az IE8-at, kapjam le a tanúsítványt, majd upgradeljek vissza IE9-re? Elég rondán hangzik. Próbáltam kreatívan értelmezni az IE9 korábbi üzenetét. Mi van, ha a tanúsítványigénylő folyamat során a Comodo belerakott egy sütit a böngészőbe, mely később kellett a tanúsítvány letöltéséhez? Hiszen ez is belefér az üzenetbe.
Újabb próbálkozás. Chrome-ból visszavonattam a kért tanúsítványt, simán megtette. Majd átléptem az IE9 alá, bízva abban, hogy a John írásától eltelt egy évben csak észrevették a Comodo-nál, hogy van IE9 is. Újabb igénylés, most IE alól léptem be a gmail fiókomba – és tadam. Megkaptam a tanúsítványt, be is tette a Personal fiókba. (Nyilván kimentettem, és eltettem biztos helyre is.)

Tulajdonképpen ennyi. A többi már egyéni szociális probléma: a gmail-t ugyanis eddig senki nem értesítette, hogy egy levelet alá is lehet írni, sőt, akár titkosíthatnám is. Az hagyján, hogy a webes felületen erre semmi lehetőségem sincs, de ha aláírt levelet kapok, azzal sem tud mit kezdeni a kliens.

From Segédlet

A képen is látható, hogy a feladó publikus kulcsát tartalmazó tanúsítványt és az email lenyomatát is magában foglaló bináris cuccot a gmail egyszerűen csak egy p7s csatolásnak mutatja, anélkül, hogy értelmezné. Körbedolgozni persze lehet, a gépemen van Outlook is, abba felvettem a gmail fiókomat, aztán legfeljebb az aláírt leveleket innen küldöm. Csak éppen borzasztóan nem elegáns a dolog, mivel ekkor az elküldött levél nem ugyanabba a Sent Item folderbe kerül, márpedig én az esetek 99,99%-ában a webes felületről levelezek.

Ha esetleg kedved van még a témával kapcsolatos anyázást olvasni, tudom ajánlani Jason Perlow írását a zdnet-en. A cím önmagában is telitalálat és remekül illeszkedik hozzá az illusztráció is.

NIS

2011-09-16 / / 0 Comments

Az alábbi videón két medve beszélget a biztonságról: Yuri Diogenes és Tom Shindler. Az első 20 percben eldörmögnek arról, mi mindennel is foglalkoznak mostanában, az utolsó tíz percben viszont Yuri tart egy érdekes bemutatót arról, hogyan is tudja megvédeni a még nem naprakészre patch-elt hálózatunkat egy jól konfigurált NIS (Network Inspection Service) a TMG-n. (Feltéve persze, hogy a támadás szignatúrája már ismert és a NIS meg is kapta a frissítést.)
 

 

Miszter X és a fejléc tűzfal

2011-07-14 / / 2 Comments

Egyszer már piszkálgattam a receive konnektorokat, csakhogy ezek olyanok, hogy nem lehet sokáig piszkálatlanul hagyni őket.

De most egy kicsit más perspektívából szeretnék foglalkozni velük, sőt, nem is csak velük. Bemelegítésképpen nézzük meg ezt az ábrát.

From Segédlet

Szép ábra, sokat szoktam nézegetni. (Az eredeti, poszter méretben itt található.) De nem csak szép, hasznos is. (Tipikus háttérkép a desktopra.)
Nos, ha eleget nézegetjük, feltűnhet, hogy van egy elem, mely többször is szerepel rajta. Narancssárga téglalap és az van beleírva, hogy header firewall. Ahhoz képest, hogy mennyiszer szerepel, nem mondhatni, hogy túlzottan benne lenne a köztudatban.

Na, ezen szeretnék most javítani.

Első lépésben vizsgáljuk meg, mi is az a header, amit tűzfalazni kell. Nagy vonalakban az email (és most csak a belső részéről beszélek, a boríték jelen cikkben nem játszik) két részből áll: fejlécből és tartalomból. A fejlécen belül pedig megkülönböztetünk szabványos mezőket és nem szabványos (vagy ronda szóval élve kvázi-szabványos) mezőket. A szabványosakat RFC írja le, a nem szabványosakról nem ír semmit az RFC (azért nem szabványosak), de elterjedt, hogy az X betűvel kezdődő fejlécmezők gyakorlatilag bármiből állhatnak, bármit jelenthetnek. Azaz ezek a mezők gyártóspecifikusak: egy konkrét gyártó smtp szervere érteni fogja, mit akar üzenni neki egy másik, hasonló szerver, a többi smtp szerver meg nem foglalkozik ezekkel a mezőkkel.
A valóságban itt is lezajlott egy evolúció, néhány X-mező annyira elterjedt, hogy ma már a kitalálójától eltérő gyártók is használják.

Mire jók ezek a mezők? Rengeteg mindenre. A feladó smtp szerver belerak egy csomó információt, melyeket utána a többi smtp szerver is fel tud használni. Ide kerülhet bele, hogy a levél mikor lépett be az Exchange birodalomba, milyen autentikációs módszerrel jutott be, milyen transport rule-ok gyötörték meg a levelet, sima levél vagy journaling… és egy csomó egyéb dolog. Akár magunknak is gyárthatunk X-mezőket. (Igaz, ez a cikk még eventsink-kel dolgozik, de ügynökkel sem lehet sokkal bonyolultabb.) X-mezőbe kerül bele az például, hogy a levelet mennyire érezte szpemnek egy korábbi smtp szerver (Spam Confidence Level, SCL), illetve az is, hogy már átment egy vizsgálaton és ne vizsgálják többet.

Hoppá.

Bejelzett a vészcsengő? Egy szpemmer számára mi sem lenne egyszerűbb, mint rögtön az elején belerakni a levelekbe egy X-mezőt, miszerint ezt a levelet már ne vizsgálják, oszt jónapot.

Na, itt lép be a képbe a header firewall. Ez ugyanis azt csinálja, hogy – beállítástól függően – kipucolja akár az Exchange által használt X-mezőket, akár az egyéb fejlécmezőket a levelekből. Így bejövő levél esetében nem hiszünk el semmit a többi smtp szervernek, kimenő levél esetén nem adunk ki olyan információt, mely segíthet feltérképezni a belső rendszerünket.

Ennyit a bevezetésről, jöhet a vadulás.

Hogyan tudjuk aktivizálni a header firewallt? Hát, úgy, hogy letiltjuk. Gyárilag ugyanis általában működik. De nagyon nem mindegy, hogy kifelé megy a levél, vagy befelé jön, illetve a feladó smtp szerver milyen jogosultságokkal bír a konkrét (receive/send) konnektoron. Érzem, hogy ebből nehéz lesz érthetően kijönnöm, inkább írok egy példát. Egy konkrét receive konnektoron engedélyezem az Ms-Exch-Accept-Headers-Organization jogosultságot mondjuk az ExchangeServers jogosultsági csoportnak. Ebben az esetben, ha egy levél ezen a receive konnektoron keresztül jött be és a sessiont kezdeményező akárki tagja az ExchangeServers jogosultsági csoportnak, akkor a header firewall kussol, legalábbis az organizáció szintű X-mezőkkel kapcsolatban. (Az Exchange X-mezőknek két nagy csoportja van, az organizáció szintűek és az erdő szintűek. Az előző jogosultságnak az erdő szintű X-mezőkre vonatkozó párja az Ms-Exch-Accept-Headers-Forest jogosultság.) Ha a sessiont kezdeményező nem tagja az ExchangeServers permission groupnak, azaz tiltva van számára az a bizonyos accept-headers jogosultság, és a levél ezen a receive konnektoron keresztül jön be, akkor a header firewall már ugrik és gyapálja is ki az organizáció szintű X-mezőket. Értelemszerűen a send konnektorokkal is hasonlóan tudunk elbánni.

Szóval, jogosultság és jogosultsági csoportok. Emlékszünk?

From Segédlet

Látható, hogy gyárilag létezik néhány előre definiált jogosultsági csoport (permission group). Hogy még durvább legyen a helyzet, létezik néhány előre definiált receive konnektor tipus is.

From Segédlet

Gondolom, senkit nem lep meg, hogy mindegyikhez – tehát jogosultsági csoporthoz is és konnektortipushoz is – eleve be van állítva, hogy működjön a header firewall, vagy sem.

Na, ezt nem kis munka lesz nyomon követni.
Szerencsére annyira nagy sem.

Mind az organizáció, mind az erdő szintű X-mezőket illetően a receive konnektoroknál csak az internal tipusnál és csak az ExchangeServers jogosultsági csoportnál nem működik a header firewall, minden más esetben igen.
Send konnektor esetén némileg bonyolult a helyzet, ott gyárilag nem jogosultsági csoport van hozzárendelve a konnektorhoz, hanem security group. Nagy általánosságban elmondható, hogy ha internal tipusú konnektort gyártottunk, akkor az Exchange szervereket tartalmazó csoportoknál nem működik a header firewall, minden más esetben igen.

Jogos lehet a kérdés, hogy bele tudunk-e ebbe piszkálni? Nos, egy irányba igen. Ha nagyon megerőszakoljuk a rendszert, akkor be tudjuk állítani, hogy az Exchange szerverekre is vonatkozzon a tűzfal.

Azaz összességében elmondható, hogy az Exchange 2010 elég kegyetlenül bánik a saját X-mezőivel: se ki nem engedi, se be nem engedi azokat, de még bent is csak az ExchangeServers jogosultsági csoport élvez mentességet. És ezek közül sem mindegyik. Organizáció, illetve erdő szintű X-mező eleve csak a 2007-es verziótól felfelé létezik, azaz ha korábbi verziójú szerverről jön levél, akkor dolgozik a header firewall (mert vagy nincs benne ilyen X-mező, ha meg van, akkor biztosan sunyi módon került bele), illetve amennyiben korábbi verziójú Exchange szerverre megy a levél, akkor meg azért lép akcióba a header firewall, mert tök felesleges lenne az X-mezőket benne hagyni, a szerver úgysem értené.

Megjegyzem, a levélküldésbe nem csak konnektorokon keresztül kerülhetnek be a levelek. Tessék csak megnézni, a narancssárga téglalapok ott vannak minden kilométerkőnél.

  • Pickup könyvtár: Ide lehet manuálisan leveleket behajigálni. A header firewall működik.
  • Replay könyvtár: Ide kerülnek azok a levelek, melyek egyszer már bent voltak a queue-ban, csak éppen valamiért kikerültek onnan. Ha ez a queue Exchange2010-es volt (az X-Createdby X-mező értéke MSExchange14), akkor a header firewall békén hagyja a levelet, ha nem, akkor rávetődik.
  • Drop könyvtár: A külsős alkalmazások könyvtára, a foreign konnektorok révén ezen keresztül tudnak leveleket küldeni, fogadni. A header firewall aktív.
  • Store driver: A kapcsolat a mailbox adatbázis és az smtp motor között. A kifelé menő levelek esetében a header firewall kivágja az illetékes X-mezőket, a befelé jövő levelek esetében válogat: bizonyos X-mezők repülnek, mások maradhatnak. (Oké, pongyola voltam. Általánosságban elmondható, hogy a szpemekkel kapcsolatos X-mezők maradnak, a többiek nem. Az ugye tiszta, hogy ezeket az infókat csak a mi smtp szerverünk rakhatta bele a levélbe, mert a kintről jövő levelekből az Edge/Hub már korábban kivágta az ilyesmit, már ha léteztek egyáltalán.)
  • Delivery Status Notfication, DSN: A header firewall mindig kigyapálja az X-mezőket a DSN-be ágyazott eredeti levelekből.

Jó. A trükkös szpemekkel elbántunk. (Az SCL is X-mező, Exchange 2010-ben egész pontosan így hivják: X-MS-Exchange-Organization-SCL.) Az X-mezők kaptak egy tockost meg egy kokit, nem mennek kifelé, nem jönnek befelé. De jó-e az nekem, ha pl. egy alkalmazásszerverem az Exchange szerveren keresztül küld ki levelet, és ez az útvonal benne marad a levélben? Nevekkel együtt? Ki tudnám ezt gyapálni?
Ki.
A logika teljesen hasonló az organizáció illetve erdő szintű X-mezőkhöz. Ha egy konnektoron engedélyezve van egy identitás számára a Ms-Exch-Accept-Headers-Routing jogosultság, akkor a routing információk benne maradnak a levél fejlécében. Ha nem, akkor a header firewall kitörli azokat.
Nézzük az alapértelmezéseket. Receive konnektoron a a következő jogosultsági csoportok számára helyből engedélyezve van a jog (azaz tiltva a header firewall): Anonymous, ExchangeUsers, ExchangeServers, ExchangeLegacyServers, Partner. Valamennyi név a naptárban. (Vessünk egy pillantást a fenti ábrára: csak ezek vannak.) Hogy lehet akkor aktivizálni a header firewallt, hogy mégiscsak rúgja ki a routing információkat? Úgy, hogy Custom konnektort készítünk és nem adunk meg semmilyen jogosultsági csoportot. Vagy meglévő konnektorból töröljük ki az összeset. Vagy az Add-ADPermission paranccsal vesszük el egy-egy csoporttól a konkrét konnektoron a jogot.
A Send konnektorokok esetében nagyjából hasonló a helyzet, alapértelmezésben a routing információk maradnak, de ha akarjuk, akkor a jogosultság tiltásával a header firewall kiszedi azokat. Érdemes megemlíteni itt is az alternatív útvonalakat: a Replay, Drop könyvtárak, illetve az ügynökökön keresztül érkező levelek esetében a header firewall nem bántja a routing információkat. A Pickup könyvtár esetében mindig törlődnek a routing információk. Szintúgy a DSN-be ágyazott levelek esetében. A Store driver a kifelé menő levelek esetében töröl, a befelé jövők esetében nem. (Ez egy kicsit félrevezető lehet. A Store driver a mailbox és a hub transport szerepkör között dolgozik. Azaz ha jön egy levél a mailbox adatbázisból, melyet a kliens mondjuk MAPI-n keresztül rakott össze, annak a routing információit – ha vannak egyáltalán – nem engedjük ki. De a következő lépésben a hub transport szerver belerakja a saját routing információját és az már marad.)

A sok elmélet után jöjjön most egy konkrét példa. Van egy Oracle szerverünk, meg egy csomó alkalmazásunk. A szerveren fut egy smtp szerver is, az alkalmazások azon keresztül leveleznek, illetve a cégből kifelé egy Exchange szerveren keresztül. Hogyan tudjuk megoldani, hogy az internetre ne kerüljenek ki az Oracle szerverre vonatkozó routing információk? Úgy, hogy a szerver kap egy egyedi receive konnektort (csak az ő IP címe szerepel benne), a jogosultsági csoportok közül meg egyet sem adunk meg. Ekkor a konnektoron nem lesz Ms-Exch-Accept-Headers-Routing jogosultság, amit a header firewall úgy értelmez, hogy tiltva van – azaz törli az addigi routing információkat.
Aha. Viszont rögtön belefutunk abba, hogy ez egy open relay tipusú konnektor (igaz, csak egy IP címre), amelyhez Externally Secured autentikáció kell. Ez viszont kiköveteli az ExchangeServers jogosultsági csoportot. Megoldás: az Add-ADPermission paranccsal csak ezen a konnektoron deny-re állítjuk az ExchangeServers permission group jogosultságát az Ms-Exch-Accept-Headers-Routing elemi jognál.

Ezzel tulajdonképpen be is fejeződhetne a cikk. Beszéltünk 3 jogosultságról (Ms-Exch-Accept-Headers-Organization, Ms-Exch-Accept-Headers-Forest, Ms-Exch-Accept-Headers-Routing), arról, hogy mi történik, ha ezeket a jogosultságokat elvesszük, illetve arról, hogy mik a gyári beállítások. Úgy gondolom, hogy hasznos lehet a másik oldalról is ránézni az összerendelésekre: milyen jogosultságokkal rendelkeznek beépítetten az egyes jogosultsági csoportok?

Anonymous (Anonymous user account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
– Ms-Exch-Accept-Headers-Routing

ExchangeUsers (Authenticated user accounts)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-Accept-Headers-Routing

ExchangeServers (Hub Transport servers, Edge Transport servers, Exchange Servers (Hub Transport server only), Externally Secured servers)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50
– Ms-Exch-Accept-Headers-Organization (Kivéve az Externally Secured servers.)
– Ms-Exch-Accept-Headers-Forest (Kivéve az Externally Secured servers.)

ExchangeLegacyServers (Exchange Legacy Interop security group)
– Ms-Exch-SMTP-Submit
– Ms-Exch-SMTP-Accept-Any-Sender
– Ms-Exch-SMTP-Accept-Any-Recipient
– Ms-Exch-Accept-Authoritative-Domain-Sender
– Ms-Exch-Bypass-Anti-Spam
– Ms-Exch-SMTP-Accept-Authentication-Flag
– Ms-Exch-Bypass-Message-Size-Limit
– Ms-Exch-Accept-Headers-Routing
– Ms-Exch-Accept-Exch50

Partner (Partner Server account)
– Ms-Exch-SMTP-Submit
– Ms-Exch-Accept-Headers-Routing

És legvégül két link a témában jobban elmélyülni szándékozóknak:

MAC

2011-07-06 / / 3 Comments

Járjuk körbe.

Miért nem érdemes MAC szűrést beállítani az otthoni vagy a céges wifinken?

Ezért.

(A link Fóti Marci blogjáról származik.)

Akkor mégis miért lehet érdemes?

Céges wifinél semmiképpen sem. Ott teljesen másképpen kell megállítani a betolakodót. A MAC szűrés csak hamis biztonságérzethez vezet, nem is beszélve a kellemetlen adminisztrációról.
Otthoni wifi AP esetében viszont mondhatjuk azt, hogy – hasonlóan az ajtónkhoz, vagy a kocsi biztonsági rendszeréhez – minél több akadályt gördítünk a behatoló elé, annál valószínűbb, hogy odébbáll.
Mondhatjuk?
Attól függ, ki a behatoló. Ha csak egy arra kóválygó wifiszomjas járókelő, vagy egy háromnapos emailmegvonásban szenvedő turista, akkor tökmindegy. A WPA/WPA2 úgyis megfogja. (Mert azért megfelelő jelszavas védelemre szükség van. Gondolom, senki nem rajong az ötletért, hogy az otthoni hálózatán idegenek kóricáljanak.) Sőt, ezeket az embereket még a WEP is megfogja, hiszen ritkán túrázik az ember hacker felszereléssel. Hasonlóan jó majomfogó az SSID elrejtése is, csak ebben az esetben nem tudunk üzenni a szomszédnak, hogy takarítson a kutyája után. (Az egyéb lehetőségekről nem is beszélve.)

From Segédlet

Amennyiben célzott támadás ellen szeretnénk védekezni, akkor viszont marad a WPA2, bazi hosszú, véletlenszerű pre-shared kulcssal. (Kevéssé tartom valószínűnek, hogy otthoni hálózatban legyen egy éppen ráérő RADIUS szerver.) Emellé az SSID elrejtése szintén hasznos lehet, a MAC szűréssel viszont csak kiröhögtetjük magunkat. Illetve megnehezítjük az életünket.
Ja, miért nem jó a rövid, értelmes szó WPA2 jelszónak? Ezért.

Mint láthatod, a WPA/WPA2 is törhető, igaz, szótárral.

Akit esetleg jobban is érdekel a téma, innen el tud indulni, az oldal linkjein lesz anyag bőven.

Közepes bizalom

2009-10-30 / / 0 Comments

De jó is lenne néha.

Mit értek ez alatt?

Minden cégnek van holdudvara: partnerek, vendorok, ügyfelek. (Nyuszi barátai és üzletfelei.) Olyan szervezetekről van szó, amelyekkel sűrűn kell kommunikálnunk. Annyira nem bízunk meg bennük, hogy beengedjük őket a saját informatikai hálózatunkba – de borzasztó jó dolog lenne, ha látnánk egymás címlistáit, illetve a megbeszélések szervezéséhez szükséges free/busy adatokat.

Ehhez kellene kitalálni valami korlátozott megbízhatóságot használó modellt.

Először nézzük meg, milyen lehetőségeink vannak most.

  • Inter-Org Replication Tool, a free/busy információk szinkronizálásához: határozottan bonyolult eszköz, ráadásul teljes trustot igényel az AD-k között.
  • GalSync a címlisták szinkronizálására: ez egy MIIS/ILM szerveren alapuló címlista szinkronizáció, mely szintén nem egyszerű és borzasztó drága. Viszont nem igényel trust-ot.

Most pletykálok. Van egy multi ügyfelünk, ahol amerikai kezdeményezésre minden országban elkezdték a fenti két eszköz rendszerbeállítását, nyilván amerikai központtal. Kábé három éve. Kezdtük a Galsync-kel. Már majdnem működik. Az Inter-Org Replication Tool bevezetése pedig még a tervezésnél sem jár.

Nem valami biztató. Ehelyett született meg az ún. Federation Trust kapcsolat.

Nagyítás

Már megint a felhő. Most mondd azt, hogy a Microsoft nem veszi komolyan a cloud computing-et. 🙂

Miről is van szó? Van a felhőben valahol egy Microsoft Federation Gateway szerver. Amikor közepes megbízhatóságú kapcsolatot szeretnék, akkor fogom magam és hozzácsatlakozok ehhez a szerverhez, egy Federation Trust kapcsolattal. Ez a kapcsolat tanúsítvány alapú, maga a cert az Exchange szervert igazolja. (Ennek komoly tanúsítványnak kell lennie, a sajátot nem fogadják el.) Az üzletfeleim szintén kiépítenek ilyen Federation Trust kapcsolatokat. (Sőt, nemcsak ők, hanem számomra vadidegenek is, nyilván.) Majd ha ez kiépült, akkor organizáció szinten hozok létre ún. sharing policy-ket, melyekben megadom, hogy:
a. Kire vonatkozzon?
b. Mit engedek neki.

Gyakorlatilag ennyi. Én még azért elfilózgattam a világ furcsaságán: bizalomról van szó, bizonyos szintű bizalmas kapcsolatok kiépítéséről – és rögtön az első lépésben fogalmam sincs róla, hol van a Microsoft Federation Gateway. Ugyanis ez egy olyan paraméter, amit nem lehet megadni. Az Exchange 2010 beépítetten tudja.

Management Role Assignment Policy

2009-10-24 / / 0 Comments

Akkor azon már túl vagyunk, hogyan tudunk kisebb adminisztratív feladatokat kiszórni egyes kiválasztott embereknek. Most azt kellene megvizsgálni, hogyan tudunk tömegesen plusz jogosultságokat adni a felhasználóknak – természetesen csak a saját postafiókjaikra.

Mit is értek ez alatt? Minden postafióknak vannak tulajdonságai, azoknak pedig értékei. Mondjuk display name és ‘Kovács János’. Ebből a kupacból lehet – lehetne – mazsolázgatni, hogy miket módosíthat a felhasználó és miket csak a rendszergazda.

Van ennek értelme? Valamilyen szinten van. (Anno Jim McBee is így gondolta, hiszen már az Exchange 2003-hoz is gyártott egy hasonló funkcionalitású eszközt.) Nagy cégnél dolgozó kollégák biztosan tapasztalták már, hogy például valaki átköltözött a 306-os szobából a 308-asba, de ez a változás az életben nem lett átvezetve a címtárban. Sőt, nem ritkán még a névváltozások is csak hosszú késéssel futnak át a rendszeren. Megváltozik valakinek a mobilszáma? Van akkora rend és fegyelem(1), hogy a telefonkiadó személy értesíti az AD adminisztrátort a változásról?

(1) Megjegyzem, van, ahol van. De legalábbis a szándék. Igazán nagy cégnél nyilván ez az egész nem így működik, hanem vannak kiemelt adatbázisok (HR, HW/SW leltár) először ezekben vezetjük át a változásokat, majd onnan fognak átszivárogni a módosítások a másodlagos adatbázisokba (AD, CMDB).

Mindenesetre kisebb, kevésbé szabályozottan működő cégeknél értelmes alternatíva lehet, hogy magukra a felhasználókra bízzuk, hogy ezeket az apróbb jelentőségű változásokat maguk is adminisztrálhassák. Nyilván az emailcímüket, felhasználói nevüket nem módosíthatják – de a többi módosítás delegálása már pusztán csak bátorság és cégkultúra kérdése.

Ennyi az elv. Amitől viszont nekem égnek állt a szőr a hátamon, az az Exchange 2010 alap hozzáállása. Erősen bízom benne, hogy ez csak RC tulajdonság.
Arról van szó, hogy – a general fültől eltekintve – defaultban mindenki módosíthat minden adatot a postafiókján. A későbbiekben pedig mi szigoríthatunk majd házirendekkel a hozzáféréseken.

Nagyítás

Mint látható, egy átlagos felhasználóval (Vidor) belépve csak a felső mezők szürkék, alatta mindent szabadon szerkeszthetünk, sőt, még el is menthetjük.

Legyen akkor az a feladat, hogy vegyük el az adatmódosítási jogot Kukától.

Kezdjük megint a get-command *role* paranccsal. Nem akarom most már annyira szájbarágósan levezetni, a policy-t a következőképpen fogjuk legyártani:
new-roleassignmentpolicy ‘Alap’

A szerepet a már ismert módon keressük meg.

Nagyítás

Nem, ne lepődjünk meg a szövegen. Elsőre ugyan úgy tűnhet, hogy ez éppen hogy engedélyezné a módosítást… de higgyjél nekem, én végigcsináltam. Ez fogja _letiltani_.

A policy és a szerep összekapcsolása:
new-managementroleassignment –name ‘Alap-MyBaseOptions’ –policy ‘Alap’ –role ‘MyBaseOptions’

A policy ráhúzása egy postafiókra már rutinfeladat:
set-mailbox kuka –roleassignmentpolicy ‘Alap’

Ha az összes postafiókra akarjuk ráküldeni:
get-mailbox | set-mailbox -roleassignmentpolicy ‘Alap’

Értelemszerűen a parancs első felét pofozgatva finomíthatjuk a szűrést.

Elméletileg készen vagyunk. Nézzük is meg, mit csináltunk:
get-managementroleassignment -identity “Alap-MyBaseOptions” |fl

Nagyítás

Ami elsőre feltűnhet: a RecipientReadScope és a RecipientWriteScope tulajdonságok értéke ‘Self’-re változott – azaz a felhasználó ténylegesen csak a saját postafiókjához fér hozzá. Aztán megint érdemes megvizsgálni a Distinguished Name paramétert. Ez most szemmel láthatóan nem a domain névtérben lévő objektumra mutat, a policy a konfigurációs névtérben keletkezett. Szerencsére meg is tudjuk nézni, ha az Active Directory Site & Services konzolból bemegyünk a Services folderbe és követjük a képen látható útvonalat.

Nagyítás

Imhol. Látható, kincset találtunk. Nem csak a házirendek találhatók itt meg, hanem egyéb objektumok is: összerendelések, szerepek, szkópok. Igen, szerepek. Ha legközelebb keresnünk kell, elég, ha ide nézünk be. (Mondjuk, itt viszont csak név van, description tulajdonság nincs.)

Egy dolog van már csak hátra: teszteljünk. A kicsi adminokhoz hasonlóan a plusz postafiók jogosultságokat is az ECP-n keresztül érvényesíthetjük.

Nagyítás

Nem is kell sokat magyaráznom. Kukával belépve az égegyadta világon minden szürke.

Végül álljon itt egy újabb értetlenkedés. Ha megnézed a szerepköröket, van azért ott egy csomó érdekes My* kezdetű szerepkör: MyContactInformation, MyProfileInformation, hogy mást ne mondjak. Szorgalmasan megcsináltam mindegyikhez a házirendet, rácsorgattam a felhasználóra – de az összes eredmény csak az lett, hogy onnantól a felhasználó nem tudott belépni az ECP-be.

RC.

Nos, ezzel nagyjából ki is veséztük a jogosultságokkal kapcsolatos változásokat. Jöhetnek az adatbázisok.

Management Role Group

2009-10-22 / / 1 Comment

Jó, ez mind szép. De hogyan lehet ezeket a jogosultságokat létrehozni, beállítani, konfigurálni?
Csak és kizárólag shellből.

A feladat: hallottuk valahol, hogy meg tudjuk adni bizonyos felhasználóknak azt a jogot, hogy szavakra, kifejezésekre kereshessenek egy komplett adatbázisban. A Microsoft ezt némi eufémizmussal Mailbox Discovery-nek nevezi – de nyugodtan használhatjuk rá a spionkodás kifejezést is. Értelemszerűen nem is adjuk meg boldog-boldogtalannak ezt a jogot – de például egy jogásznak, vagy egy biztonsági főnöknek talán(1). Csak és kizárólag ezt a jogot.

(1) Ezzel azért óvatosan. Tudomásom szerint – bár nem vagyok jogász, tehát ha valakinek pontosabb infója van, javítson – Magyarországon, amennyiben a cég nem iratott alá engedélyező jellegű nyilatkozatot a felhasználókkal, akkor nem is turkálhat a postafiókjaikban.

Oké. Hogyan induljunk el?

Offline help, az ugye nincs. Csináljunk úgy, mintha semmilyen kerülő úton sem férnénk hozzá az internethez. Így legalább meglátjuk, mennyire készséges eszköz is a shell.

Tehát: annyit tudunk, hogy szerepeket akarunk kiosztani. Először is szeretnénk csinálni mondjuk egy MRG-t.
Nagy bátran gépeljük be:

get-command *role*

Nagyítás

Szerencsére nem is olyan sok. Értelemszerűen a new* kezdetű parancsok érdekelnek. Ez a new-rolegroup például határozottan szimpatikus.

get-help new-rolegroup -detailed

Nagyítás

Nem, nem csak ennyit mond. A -detailed kapcsoló ránkborítja rendesen az információkat. De ez a lényeg. Mit is kell összeraknunk, ha azt akarjuk, hogy Tudor legyen a jogosult?

new-rolegroup -name szorcs -roles ?? -member Tudor

Nem is olyan bonyolult. Igenám, de honnan lesznek meg a szerepek nevei?

Kitérő:
A korábbi get-help parancs nemcsak a szintakszist adta vissza, hanem példákat is. Például ezt.

Nagyítás

Nagyon jó példa! – csillant fel a szemem. Kiadni csak azt a jogot, hogy resetpassword. Be is gépeltem az ábrán található sort, persze felhasználóként Tudort megadva. Kövér errort kaptam. Azt mondta, hogy nincs ilyen szerepkör. Lányos zavaromban kipróbáltam mindenféle elgépelést, de semmi. Később megtaláltam a szerepeket a GUI-ban is (meg fogom mutatni) – és ott sem volt.

Nagyítás

Tekintsük ezt a még kicsit sorjás RC bájos baklövésének.

Kitérő vége.

Menjünk vissza arra a *role* képre. Van-e ott olyasmi, amelyből megtudhatjuk a szerepek neveit, funkcióit? Értelemszerűen most a get* kezdetűek érdekelnek.
Nicsak: get-managementrole.
Lőjünk bele egyet. A sörétespuskával.

get-managementrole | fl

Ez a parancs az összes létező szerepről kiírja az összes létező tulajdonságot, az összes létező értékkel egyetemben. A szöveg pár percig csak görögni fog a képernyőn.
Nem baj. Amikor megállt, nézzük meg az utolsó szerepnél, hogy milyen tulajdonságai is vannak. Van például name és van description. Bőven elég nekünk.

get-managementrole | fl name, description

Nagyítás

No, most is lesz szorgalmas görgés a képernyőn, de már jóval kevesebb. És utána kényelmesen végignézhetjük, milyen beépített szerepkörök vannak és mit is tudnak pontosan.
A fenti ábrán bejelöltem, hogy mi is kell nekünk: Mailbox Search.

Tehát a korábbi parancs valami ilyesmi lesz:

new-rolegroup -name szorcs -roles “Mailbox Search” -member Tudor

Le is fut. Meg is csinálja. Nézzük is meg.

get-rolegroup -identity szorcs | fl

Nagyítás

Hát nem szép?

Nézzük végig, fentről lefelé.

  • RoleAssignments…? Adtunk meg assignment-et? Nem. Létrejött magától. Végülis… minden adott volt, hogy létrejöhessen.
  • Egyedüli tag Tudor. Pont így szerettük volna.
  • DistinguishedName… Van neki. Méghozzá láthatjuk, hogy ez egy valami a Microsoft Security Groups OU-ban.

Nagyítás

Lám, lám, egy univerzális biztonsági csoport, benne egyedül Tudor. De ne legyenek illúzióink, a háttérben azért ez jóval több, mint egy univ.sec. csoport – láttuk, milyen extra tulajdonságai, pontosabban összerendelései vannak.

Kész. Már csak le kellene tesztelni.

Itt meg fogunk ismerkedni egy újabb nagyszerű eszközzel: Exchange Control Panel.

Legközelebb.

RBAC

2009-10-21 / / 1 Comment

Oké, túljutottunk a telepítésen. Itt az idő, hogy megvizsgáljuk, mit is kaptunk.

Nyilván neki lehet úgy is állni, hogy elkezdünk össze-vissza kattogtatni a grafikus felületen, aztán figyeljük, hogy mi történik. Csak éppen nem javasolt. Az RBAC-ról speciel a GUI-n keresztül egész konkrétan semmit sem fogunk megtudni.
Pedig az egyik leglényegesebb változás.

A rövidítés azt takarja, hogy Role-Based Access Control.

Gondoljuk el, hogy mennyire kényeztetett el eddig minket az Exchange, ha a jogosultságok finomhangolásáról volt szó?
Van ugye 4 admin jogkörünk:

  • Organization admin: Maga az Atyaúristen.
  • Server admin: Atyaúristen, csak kicsiben: képességeinek korláta egy Exchange szerver.
  • Recipient admin: Szintén az Olümposz lakója: ő a postafiókok terén mindenható.
  • View-only admin: Ő sem kispályás: mindent lát egy organizációban.

Egyébként pedig léteznek még a mezítlábas gyalogok, az úgynevezett júzerek.

Bármi ettől eltérő jogosultságot szerettünk volna kikeverni, be kellett merészkednünk a security descriptorok, access tokenek sűrű, sötét dzsungelébe. És ebben nem is az ismeretlen dzsungel volt a fő baj, hanem az, hogy a nagynehezen összefércelt jogosultságaink upgrade esetén mentek a levesbe.

Szerencsére itt van az RBAC. Illetve lesz.

Két irányban tágítja a lehetőségeket:

  1. Lehetővé teszi ún. kicsi adminok létrehozását. Rengeteg előregyártott szerepkört tartalmaz, de a lista custom szerepkörökkel is bővíthető. Ezeket a szerepeket hozzárendelhetjük univerzális csoportokhoz, a csoportokba pedig behajigálhatunk felhasználót, csoportot, recipientet.
  2. Többlet lehetőségeket biztosíthatunk az egyes felhasználóknak, természetesen csak a saját postafiókjaikra. Nem meglepő, hogy erre a célra házirendeket fogunk felhasználni.

1. Management Role Group

Nagyítás

Az ábrán láthatjuk részletesen is, milyen környezetben létezhetnek a kicsi adminok.
Létezik egy Management Role Group (MRG). Ez egy univerzális group, ide szórjuk be a konkrét szereppel megbízott felhasználót, csoportot, recipientet. A másik oldalon létezik egy vagy több szerepkör. Mint írtam, ez lehet beépített, vagy általunk gyártott. (Első körben mindenképpen az előbbi. Ahogy elnéztem, nem túl egyszerű dolog szerepet gyártani.)
A kettő között egy összerendelés, egy Management Role Assignment hoz létre kapcsolatot. Ennek az összerendelésnek még van egy scope paramétere is, miszerint az MRG a címtár egyes névterein belül – eltekintve persze a schema névtértől – mihez fér hozzá írás/olvasás jogosultságokkal.

2. Management Role Assignment Policy

Nagyítás

Itt elkövettem egy apró bakit, mert szerettem volna a két eset közötti hasonlóságot bemutatni. A valóságban természetesen nem a felhasználók esnek rá a házirendre, hanem pont fordítva.
Tehát. Létrehozunk egy Management Role Assignment Policy-t (MRAP), melyet majd valahogyan (powershell, powershell) ráküldünk bizonyos recipientekre. A jobb oldalon ugyanazok a szerepek találhatók, mint az előző ábránál. Alul pedig a Management Role Assignment kapcsolja össze a házirendet a szerepekkel. Fontos eltérés, hogy ebben az esetben nincs értelme scope-ról beszélni, hiszen a felhasználók a saját postafiókjaikhoz férnek hozzá.

Végül összefoglalva a két eset:

Nagyítás

Ennyit az elméletről. A folytatásban kinevelünk egy nem is kicsi admint, akinek megadjuk azt a jogot, hogy az egész adatbázisban kereshessen (de az külön állítható, hogy meg is tekinthesse a keresés eredményét), illetve házirendből beállítjuk, hogy bizonyos felhasználók ne tudják módosítani a postafiókjukhoz kapcsolódó ún. nem túl fontos tulajdonságokat.

Tíz körömmel kapaszkodva

2008-03-24 / / 0 Comments

Beindítottuk ezerrel a mozgatásokat. Elindultak a Public Folderek és elindultak a felhasználói postafiókok is; a cél az volt, hogy a régi szerverek adatbázisai teljesen üresek legyenek. (Eltekintve egy darab régi szervertől, mert onnan tudtuk elérni a PF adatbázist. Az Exchange 2007 SP1-gyel egyelőre még nem akartuk bonyolítani a rendszert.)

Nem is lett volna ezzel semmi baj… csakhogy az előállt káosz nem működött. Hiába lett alaposan végiggondolva, hiába sikerültek a műveletek előtti tesztek, a valóságban teljesen érthetetlenül alakultak a dolgok. Bizonyos elérések működtek, bizonyos elérések nem. Ha teszteltünk egy elérést, működött, ha használni akartuk a postafiókot, akkor nem. A free-busy mátrixon annyi lyuk volt, mintha sörétespuskával durrantottak volna bele – ráadásul a minta is illogikus volt.
Más lehetőségünk nem lévén, előre menekültünk. Közöltük mindenkivel, hogy _nem_ fogunk hibákat javítani és nem fogunk a rendszer stabilizálásával foglalkozni – ehelyett amilyen gyorsan csak lehet, lepörgetjük a mozgatásokat és kihajítjuk a régi Exchange 2000-es szervereket. (Amilyen gyorsan csak lehet… persze a Public Folderek nem arról híresek, hogy túlzottan kapkodnák a seggüket – és akkor még nem is beszéltem a postafiókmozgatások egyeztetéséről.)

De végül csak elértünk odáig, hogy üres lett a vidéki Exchange 2000 szerver. (Mondjuk, az üres enyhe túlzás: a PF instance-ok között még ott volt egy OAB folder; egy olyan, melyen már nem volt beállítva a kérdéses szerver, mint tulajdonos.) De ettől még nekimentem. Control Panel, Add/remove programs, Exchange 2000, remove. Végigmentünk a varázslón, szervízek leálltak… majd kiírta a következő borzasztóan szellemes üzenetet, minden eltávolítandó szolgáltatásra külön-külön.

Setup failed while (error 0×8000FFFF: An unexpected error occurred.)

Additional information:
An unexpected error occurred.

Ízlelgessük. Garantáltan nem fake, tényleg képes volt az alkalmazás egy ilyen hibaüzenetet a képembe tolni.
Ekkor még nem voltam igazán ideges. Amit az utóbbi években nem tanultam meg Exchange szerver likvidálásból, azt már nem is érdemes tudni. Őszintén szólva, nem is számítottam gyors sikerre.

Elkezdtem a skálázást.

1. Idézet magamtól:

A következő objektumon – CN=Configuration,DC=SUBDOMAIN,DC=DOMAIN,DC=COM\CN=Services\CN=Microsoft
Exchange\CN=EXCHANGE\CN=Global Settings\CN=Message Delivery – meg kell keresni az msExchAdminMailbox tulajdonságot. Ennek értéke mondja meg, melyik felhasználóhoz van hozzárendelve a postmaster mailbox. Ha ez megvan, akkor adsieditből megnyitjuk a felhasználó objektumát és meglessük a HomeMDB tulajdonságát. Ha ez a letörlendő szerverre mutat, akkor töröljük. Ha nincs már meg a felhasználó, akkor az msExchAdminMailbox tulajdonságnál adunk meg egy másik felhasználót.

Megkerestem. Teljesen szabályos felhasználót találtam, másik Exchange szerveren lévő postafiókkal.

2. KB279202. Itt találunk különböző módszereket arra nézve, hogyan állapíthatjuk meg, mely felhasználók ragadtak be láthatatlanul egy postafiókba. Végigzongoráztam mindegyik módszert, de nem találtam semmit.

3. Teljes gőzzel beindítottam a guglizást. Rengeteg hivatkozást találtam ugyan rá, de… ezek nagy része más – de azonos kódú – váratlan hibára utalt, a maradékban pedig valami kérdező feldobta egy listára a hibát… aztán néma csend. Senki sem tudott értelmesen válaszolni.

4. Abbahagytam az internet faggatását és használtam egy kicsit a józan eszemet. Mint az közismert (hogy mondta, Safranek?), minden adatbázisnak van egy homemdbbl tulajdonsága, mely tulajdonképpen egy backlist. Egy tömb, mely azon felhasználók DN értékeit tartalmazza, akiknek a homemdb tulajdonságának az értéke az illető adatbázisra mutat. (Azért backlist, mert a visszanyalás automatikus.) Ebből halálpontosan lehet tudni, ténylegesen kik tartoznak még az adatbázishoz. De akárhogy is néztem, mindenhol csak a system felhasználókat találtam, azokat viszont, ahogy Evan is írta, nem érdemes törölni. Nem akadályozzák meg az uninstallt.

5. Maradt volna a durva kiherélés, amelyről itt már írtam. Nem tudom, ki hogy van vele, de én irtózom az ilyesmi brutális módszerektől. Nyilván végső menedékként jó, ha vannak ilyen eljárások is… de kérdés ugye, hogy mennyire lesz megbízható a későbbiekben egy ilyen szétkurkászott szerver. És ezen még fájlszerver volt, mentőrendszer volt… meg mittudomén. Mint ahogy egy erőforráshiányos vidéki telephelyen illik.

6. Nézegettem, nézegettem azt a hibaüzenetet… aztán egyszer csak megtaláltam a gördítősávot – és előjött a hibaüzenet folytatása. Ránézésre valami debug jellegű dolognak tűnt – de nézzük már meg alaposan azt a folyamatot, ahol elhasaltunk.

Function:
CComExchSetupComponent::HrPromptForCDIfNecessary
CComExchSetupComponent::Install

HrPromptForCDIfNecessary – mintha azt mondaná, hogy cédét kér. És mivel nem kap, ezt unexpected (váratlan) hibának tartja. Nézzük csak meg, mi lenne, ha nem a Control Panelből indítanám az eltávolítást, hanem telepítőcédéről? Mi kell ehhez? Telepítő média. Exchange 2000. Péntek délután. Az ügyfélnél. Helyi rendszergazda roppant lelkes, előtúr valahonnan egyet. Igenám, de ez egy vidéki szerver, márpedig a sávszélesség finoman szólva sem acélos. Telefon a vidéki embernek. Ő is talál egy Exchange 2000 telepítőcédét valahol. Amikor elhűltem ekkora mázli láttán, blazírtan megjegyezte, hogy a cédé ott volt közvetlenül a Windows 3.11 telepítő floppyk mellett. Atyám.
A puding próbája az evés. Cédé bele a meghajtóba, telepítő elindít – hibátlanul végigmegy. A szerver megszűnt a továbbiakban Exchange szerverként létezni.

Gondoljuk végig még egyszer, mi történt? Egy program elindult, elkezdett leszedni egy alkalmazást, majd kellett volna neki néhány fájl egy cédéről. Mit csinált? Nem, nem mondta azt, hogy “b+ haver, told már be azt a cédét”, hanem ehelyett beleordította a nagyvilágba, hogy “unexpected error”, majd elszállt. Csak gratulálni tudok mindenkinek, aki részt vett eme csodálatos kód megírásában.

Azt hittem, ebben a projektben többször már nem harapok bele az asztallapba.
Tévedtem.

H@x0r

2008-02-29 / / 0 Comments

Holnap Ma lesz az utolsó nap a Netacademia Ethical Hacking tanfolyamán. Mivel ez már csak olyan fél nap lesz, nagy változások nem várhatóak – így megírhatom már most is a véleményemet.

Kezdjük azzal, hogy ennek a tanfolyamnak nagyjából annyi köze van a hackeléshez, mint a Bükkben vezetett busztúrának a hátizsákos gyalogtúrához. Ha most azt hiszed, jól megkritizáltam az egészet, akkor tévedsz: ez egy pontos, alaposan megcsiszolt hasonlat volt. Ha ugyanis körbevisznek a buszban, akkor futólag látod a Bükk részeit. És ha tetszik, akkor egy-két hét után már jöhetsz is vissza a zsákoddal – és lassan, de alaposan járhatod be a terepet.
Viszont hacker ettől a tanfolyamtól nem leszel. De még csak a vizsgától sem. Azt nem adják ilyen könnyen.
Akkor mit ad a tanfolyam? Némi szemléletet, rövid áttekintéseket – és hatalmas adag tananyagot. Lássuk a szikár számokat: a csomagban hat könyv van: 2500 oldalnyi tankönyv, 500 oldalnyi laborgyakorlat. A mellékelt cédéken olyan 3 GB hacker/cracker segédprogram, egy vizsgasegédlet, két cédényi videó és egy cédéről boot-oló linux masina található. Hatalmas anyag, az oktató meg sem próbálta teljes mennyiségben leadni. Mentünk, ahogy tudtunk, belekaptunk ebbe is, abba is. Megjegyzem, inkább network alapokról volt szó, mint konkrét hekkelésekről, dehát ugye arra épül minden. Viszont láttunk azért olyat is, a laborgyakorlatokon pl. egymás gépeit borogattuk meg.
Ami engem nagyon zavart, az a naftalinszag volt. Olyanokat hekkeltünk, hogy IIS5, IE6, SQL2000, a vizsgakérdések között is volt olyan, amelyik 2002-es(!) Windows patch-re vonatkozott. Értem én, hogy ismerkedésre jó ez is, de szívesen láttam volna, hogy mi a helyzet a mai rendszerekkel.

Mondjuk, valamennyit azért láttam.
Például Zsíros Petya előadása ütött rendesen. Nulláról indulva írt PHP-ben egy BOF exploitot, részletesen elmagyarázva, mit miért csinál. Én ugyanis eddig azt hittem, hogy a buffer overflow töréseket zöld marslakók írják – az emberek ugyanis tuti képtelenek ekkora precizitással átsurranni egy-egy kapun. Most már tudom, hogy ember is képes erre, ha van elég agya.
De megemlíthetném Agot is, aki wifi törésekről tartott egy igen érdekesnek tűnő előadást. (Azért fogalmaztam ilyen óvatosan, mert én valahol a WEP hiányosságainak boncolásakor leestem a szekérről – és az még igencsak az eleje volt. Innentől gerillamódszerekkel értettem meg részleteket az előadásból – pont annyit, hogy adott esetben a google segítségével azért boldoguljak.)

És ha már az oktatóknál járunk, ejtsünk szót a fő oktatóról is: Jan szemmel láthatóan értett az anyaghoz, jól is adott elő – de szerény véleményem szerint engedhette volna lejjebb is azt az ekevasat a mélyszántás előtt. Ahogy elnéztem, nem volt olyan inhomogén a társaság, mint általában egy tanfolyamon szokott – senki sem bánta volna, ha jobban belemegyünk néhol az anyagba. Így viszont ez az egész inkább csak vizsgára felkészítésnek tűnt.

Apropó, vizsga. Habár a tananyag rettenetesen nagy, de a vizsga ránézésre nem tűnt vészesnek. 150 kérdés, 4 óra, azt hiszem, 120 jó válasz kell. Átfutottam a próbaverziót, nagyon sok kérdés kilogikázható, ráadásul jól be is határolható, mely anyagokra kell rágyúrni a könyvből.

De szándékosan nem akarok vizsgázni belőle.
A vizsga ugyanis veszélyes – különösen, ha sikerül. Onnantól kezdve az emberen számonkérik a tudást. A vizsga speciel nem csak arra jó, hogy kompetenciát mutassunk egy-egy pályázaton. A vizsga szakértőt csinál belőlünk – olyan szakértőt, akinek kutyakötelessége naprakész tudással rendelkezni az adott területen, mert bármikor igényt tarthatnak rá. Emiatt van az, hogy én már évekkel ezelőtt megfogadtam, hogy csak abból vizsgázok, amivel hosszútávon is foglalkozni akarok. Márpedig a hekkelés nem az. Jó képben lenni, jó ismerni a technikákat – de nem jó szakértőnek lenni belőle.

Az ellopott tartományvezérlő esete

2007-09-08 / / 0 Comments

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?

Majdnem-Herkules

2007-03-30 / / 0 Comments

Igen, ő a Muszáj-Herkules testvére.

Felteszem, mindenki tudásában vannak fehér foltok. Olyan területekre gondolok, melyeket ha máskor nem is, de vizsgára megtanultunk – aztán utána el is felejtettük, mert soha nem volt rá szükségünk. Nekem ilyen terület a biztonsági sablonok molesztálása.

Adott volt a következő feladat: telepítsünk egy egyszerű failover clustert multi ügyfél magyar leányvállalatához. A vasak egyszerű pengeszerverek, oprendszer, IIS (erőforrás lesz belőle az ügyfél alkalmazásában). A gép tartományba beléptetve, lokál admin jogunk van, tartományi admin jog nincs. Jól is néznénk ki.
Mielőtt még felhajigálnánk a clustert (pontosabban beizzítanánk, hiszen a WIndows2003 Enterprise változatban helyből települ), még le kell futtatnunk egy helyi specifikus alkalmazást: ez bekeményíti az operációs rendszert, bekonfigurál egy csomó mindent, felrak ezt-azt. Céges standard, kötelező.
Jöhet végre a cluster. Gyönyörűen fel is települ, majd amikor leokézom az utolsó ablakot, jön egy kövér error. Hogy access denied.
Első alkalommal ijedtemben eltávolítottam a node-ot. (Ami persze nem igazán egyszerű dolog, hiszen grafikus felületről nem látszik semmi. A megoldás: ‘cluster node <nodename> /forcecleanup’) De az újabb, alaposabb konfigurálásnál ugyanezt kaptam. Ráadásul a kollégák szóltak, hogy a cluster tulajdonképpen működik, kívülről elérhető. Csak éppen nem menedzselhető. Zorró, a fantomklászter. Jöttek a szokásos ráolvasások éjfélkor keresztútnál (filemon, regmon, user jogosultságok, gpresult), de nem sok sikerrel. Aztán az ügyfél ötletére ráhúztuk a rendszerre a ’setup security’ biztonsági sablont – és onnantól már a cluster szolgáltatás sem indult el. Viszont amint visszaállítottuk a cluster service account user jogosultságait a setup security sablonban, egyből menedzselhetővé vált a cluster.
Azaz a hardening csinált valamit, amitől elérhetetlenné vált a cluster management GUI – amint visszatettem egy gyengébb sablont, minden ment simán.
Azt hihetnéd, hogy örültünk ennek a megoldásnak. Óriási tévedés. A leánycégnek az égegyadtavilágon semmi ráhatása sincs arra, hogy a magasságos multi anyacégnél a biztonsági részlegen milyen hardening eljárást dolgoznak ki. Sőt, még tájékoztatást sem kapnak, hogy tkp. mi is történik a folyamat során. A maximum, amit ki tudtunk csikarni, az egy mérsékelt érdeklődés volt, és egy igéret, hogy ha kiderítjük, melyik beállítás okozza a hibát, akkor az eredményt felveszik a céges knowledge base-be.

Azaz identifikálni kell, ezerrel.

És itt jön be a képbe a Security Configuration & Analysis segédprogram. A Majdnem-Herkules.

Mielőtt tovább haladnánk a megoldási folyamatban, nézzük át részeletesen, hogyan is működik ez az eszköz.

Először is, az eszköz grafikus felülete csak MMC konzolból érhető el – azaz megfuttatjuk az mmc.exe progit, majd a snap-in-ek közé felvesszük a Security Configuration & Analysis konzolt. És ha már ott járunk, kapjuk fel a Security Templates konzolt is.

Nagyítás

Ha magunktól próbálunk rájönni az eszköz működésére, akkor gondban leszünk. Ugyanis ha nem ismerjük a logikáját, magunktól soha nem fogjuk kitalálni.
Az elv az, hogy van egy működő rendszer. Ez az, amely éppen dübörög a gépen, amelyen vizsgálódunk. És van egy munkaterület, ahová boncolási célzattal betölthetünk biztonsági sablonokat. Egyszerre mindig csak egyet. Ezt a munkaterületet adatbázisnak nevezték el. Az összes műveletnek ez a két terület az alanya.

  • Össze lehet hasonlítani a munkaterületen lévő sablont a jelenlegi beállításokkal. (Analysis.)
  • Tetszőlegesen módosíthatjuk a munkaterületen lévő sablont, majd elmenthetjük.
  • A munkaterületen lévő sablont ráhúzhatjuk a működő gépre. (Configuration.)

Nézzük részletesen.

Mielőtt bármit csinálnánk, munkaasztalt – adatbázist – kell definiálnunk. Jobbklatty, open database.

Nagyítás

Itt beírjuk a létrehozandó adatbázis (.sdb) nevét. Ezzel létre is jön. De mielőtt még kiérnénk a kuruzslóból, megkérdezi, hogy vajh melyik sablont szeretnénk betölteni? Válasszuk ki valamelyiket.

Nagyítás

Amivel egész biztosan nem okozunk galibát, az az összehasonlítás. Csapjunk bele.

Nagyítás

Rögtön az elején megkérdezi, hová mentse az összehasonlítás során keletkező log fájlt. Ezt jegyezzük fel, mert később szükségünk lehet rá. (Persze ha konzolból nyomjuk, az meg fogja jeleníteni a jobb oldali ablakban.)

Nagyítás

Aztán dolgozik az analízis. (Menj analízisbe, Ofélia.)

Nagyítás

Imhol a végeredmény. Látható, hogy a security fa melyik ágán vizsgálódunk és mely tulajdonság egyezik, mely pedig nem. Az eltérést a mismatch jelzi.

Nagyítás

A konkrét ábrán például láthatjuk, hogy a User Rights ágon belül a System Time állítgatási jog beállításai eltérnek az adatbázisban és az éles rendszeren. Nézzük meg, hogy hogy is néz ez ki a grafikus felületen:

Nagyítás

Igen, láthatjuk, hogy a munkaasztalon lévő sablonban a megfelelő beállítás előtt egy ikon jelzi, hogy ott valami nem stimmel.
Egész pontosan az ikon a következőket jelezheti:

  • Piros körben fehér iksz: a beállítás eltér a valós rendszer és a vizsgált sablon között.
  • Fehér körben zöld pipa: a beállítás megegyezik a valós rendszerben és a sablonban.
  • Kérdőjel: A beállítás nem létezik az adatbázisban, ergo nem is került kiértékelésre.
  • Felkiáltójel: Pont fordítva: a beállítás nem létezik a valós rendszerben.
  • Nincs semmilyen jel: A beállítás egyik helyen sincs definiálva.

Például a korábban a szövegfájlban látott mismatch így jelenik meg a grafikus felületen.

Nagyítás

Természetesen a munkaterületre betöltött sablont nem csak boncolhatjuk, hanem műthetjük is. Bármelyik beállítást módosíthatjuk, majd az így létrejövő sablont exportáljuk valamilyen új néven.
Értelemszerűen ahhoz, hogy ez a menüpont megjelenjen, előtte be kell tölteni egy sablont a munkaterületre, majd összahasonlítani az aktuális beállításokkal. Utána lehet menteni.

Nagyítás

Új sablont nem csak létezőből kiindulva hozhatunk létre – igaz, ehhez már egy másik konzolra lesz szükségünk. A Security Templates snap-in-ben jobbkattintás, majd New Template…

Nagyítás

Látható, hogy ez egy teljesen üres sablont hoz létre. Miénk a terep, tetszőlegesen perverz kombinációk létrehozása előtt nyilik meg a lehetőség. Csak arra vigyázzunk, hogy magunkat ne zárjuk ki a módosítási engedéllyel rendelkező személyek közül. Onnantól ugyanis unalmas hétköznapunk egy kicsit pörgősebbre fog változni.

Nagyítás

Itt pedig azt láthatjuk, hogy a Security Templates konzolban létrehozott MacskaRugjaMeg sablont mentés után már a Security Configuration and Analysis konzol munkaterületére is betölthetjük, további fazonírozás céljából.

Nagyítás

Amennyiben a megfelelően módosított sablont rá akarjuk húzni, akkor az Analysis menüpont helyett a Configuration menüpontot válasszuk – ekkor a munkaterületen lévő beállítások rámásolódnak az aktuális számítógépre.

Nos, nagyjából ennyi. Egész jó kis segédprogram.
Lenne.
Ha a program tervezése során figyelembe vettek volna egy átkozottul reális igényt: azt, hogy a meglévő gép biztonsági beállításaiból sablont gyárthassunk. De nincs. Tessék ilyen szemmel végigolvasni az eszköz működését: mindenhol a munkaterületet exportálhatjuk, oda meg már létező sablont tudunk csak betölteni. Ez egy akkora öngól, hogy még ma sem tudom igazán elhinni. Programozástechnikailag semmibe nem került volna összedobni, a sablongyártásban pedig óriási segítség lett volna.

Érted már, hogy miért Majdnem-Herkules?

Térjünk vissza a megoldandó problémához. Van egy gép, induláskor a setup security sablonnal. Ezen begerjesztem a cluster szolgáltatást, felkonfigurálom a clustert. Innentől már eltértünk a sablontól, tekintve, hogy a telepítés/konfigurálás belerondít rendesen. Aztán jön a multi cég hardening folyamata, mely aztán végképp összezavarja a szálakat.
Nekem arra lenne szükségem, hogy mielőtt ráengedném a hardeninget, le tudjam menteni sablon formában az épp aktuális beállításokat, majd a bekeményítés után visszatölthessem a munkaterületre és ki tudjam analizálni közöttük a különbséget. Nyilván még ez sem lenne túl egyszerű, kicsit ‘tű a szénakazalban’ jellegű a munka… de valahogy így lehetne nekiállni.
Ehelyett… kinlódunk. Nem tudom lementeni a sablont, tehát maximum a setup security kiindulási pont és a hardening végső pont között tudok különbséget képezni – azaz a feladat jellege megmaradt, csak a szénakazal lett jóval nagyobb.
Illetve… trükközhetek. Felkonfigurálom a clustert, majd összehasonlítom a valós rendszert a setup security sablonnal. Ekkor megkapom azokat a beállításokat, melyeket a cluster telepítés érintett. Gyújtok egy gyertyát Szent Antalnál és reménykedek, hogy ez a halmaz nem lesz nagy – és tartalmazni fogja azt a beállítást, melynek átállítása okozza a galibát.
Most jöhet a hardening, majd ezt összehasonlítom a setup security sablonnal – de csak a korábban manuálisan kiszűrt beállításokkal fogok foglalkozni.

A megoldás kicsit olyan ’szarva között a tőgyét’ jellegű – de akár működhet is. Talán.
Ha nem, akkor kénytelen leszek felvenni a csempetépkedő kesztyűt.

ps.
Amikor az ember először morog, utána gondolkodik. A ‘secedit /export /mergedpolicy /db /cfg’ mintha pont ezt csinálná.

Ki őrzi az őrzőket?

2006-10-03 / / 0 Comments

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.