MonthJanuary 2011

Hulljon a férgese

Biztosan sok emberben felmerült már, hogy milyen jó móka lenne rendszergazdaként a szerver konzolból látszólag véletlenül beletörölni a felhasználók postafiókjaiba. Az Exchange 2007-ben, illetve az Exchange 2010 RTM-ben erre a célre az export-mailbox parancs szolgált. Mind exportálni, mind törölni lehetett vele.
Az Exchange 2010 SP1-ben a fenti két funkció kettévált. Exportálásra a New-MailboxExportRequest parancsot kell használnunk.

Minket viszont sokkal jobban érdekel, hogyan tudunk törölni. Nos, bár fura, de logikus: a search-mailbox paranccsal. Tessék megnézni a kapcsolókat. Egyrészt megadjuk a keresési feltételeket, majd jöhet az akció definiálása. Az első lépésnél izgalmas lehet a -searchdumpster kapcsoló, a másodiknál pedig a -deletecontent. Ha mindkettőt alkalmazzuk, akkor a levelet az se menti meg, ha a felhasználó előrelátóan már korábban törölte. (De csak a kukáig.) Az összes paramétert nem fogom felsorolni, a fenti linken részletesen is megtalálható a magyarázatuk.

Habár a Pokoli Operátor sem rossz játék, de azért a parancsnak léteznek értelmes felhasználási területei is. Tudom, hogy nehéz, de képzeljük el, hogy a titkárnő szétküldött hivatalszinten egy államfői levelet, mely tele volt helyesírási hibával. Nyilván ez így blamálja az elnököt, akit nem fog érdekelni, hogyan, de tüntessük el a levelet a rendszerből. Természetesen tágabb értelemben el tudunk vele tüntetni bármilyen, meghatározható paraméterű (pl subject) szpemet, vírust és bármit, ha éppen nincs erre a célra dedikált külső alkalmazásunk.

Apu, hod med be

Jó téma, napokig lehetne cikkezni róla. Konkrétan arról van szó, hogyan nyúl bele a tűzfal a legegyszerűbb adatáramlásokba is. Melyekről persze kiderül, hogy nem is olyan egyszerűek.

Az első sztorink egy világméretű hálózaton történt. Két Exchange organizáció között kellett Free/Busy szinkront összelőni. A túloldal Amerikában volt, jó nagy időeltolódással. A kommunikáció enélkül is igen nehézkesen ment, ilyen környezetben nem egyszerű összehozni egy élő kapcsolatot, hogy mind a két oldalon ott üljön a megfelelő mérnök és szinkronban taperolják a billentyűzetet.

Előtte határozottan felhívtam a tűzfalas kollégák figyelmét, hogy a két host között any-any kapcsolatot kérek az oldalunkon. Belső hálózatról van szó, épp elég lesz az F/B szinkronnal játszanunk, első körben nem szeretnénk, ha a tűzfal bekavarna. (Utána lehet majd szigorítani.) Megigérték, beállították.

Eljött az idő. Próbálkoztunk. Nem működött. Kiderült, hogy a túloldali tűzfalon mindösszesen néhány portot engedélyeztek, csak éppen ezt a portlistát elfelejtették közölni. Mi viszont az Exchange megfelelő szolgáltatását nem korlátoztuk konkrét portokra. Némi gondot jelentett, hogy az általuk engedélyezett portokat nálunk már más Exchange szolgáltatások használták. Hasraütve kiválasztottunk néhányat a környékről (6xxx), a túloldalon engedélyezték a tűzfalon, nálunk ugye nem kellett.
Továbbra sem működött a szinkronizáció. Izzadtunk még egy sort, majd kölcsönös és sűrű sorry-k mellett befejeztük a közös munkát. Majd legközelebb.

Másnap a biztonság kedvéért rákérdeztem a helyi biztonsági erőknél, hogy tényleg any-any lett-e beállítva? Mellékeltem a konkrét portszámot is. Erre kaptam egy olyan választ, hogy jojózott a szemem. Ugyanis a véletlenszerű porttal pont beletaláltam egy általam még csak soha nem is hallott protokoll tartományába, melyet a konkrét tűzfalon nem engednek át direktben, hanem proxyznak. Innentől jókedvű anyázásba fordult a levelezés, én próbáltam elmagyarázni, hogy az any-any azt jelenti, hogy a két host között minden kommunikáció transzparens, ők viszont ragaszkodtak ahhoz, hogy az any-any az egy beállítás a szabályon, de nem érinti a különböző protokollproxykat.

A vége az lett, hogy kerestünk egy olyan portot, amelyiken biztosan nincs semmi trükközés, a következő partira az amik módosították a náluk lévő tűzfal szabályát, be is indult a kommunikáció.

A második sztori nem sokkal ezután esett meg egy kollégámmal és kisértetiesen hasonlított az előzőre.

Ügyfélnél két telephely, két AD site. Mindkettőn vannak Exchange Hub Transport szerverek. A jelenség: nem mennek át a levelek. Ott állnak a várakozási sorban, és azt mondják, hogy a túloldali szerver nem képes az Exchange szerver autentikációra. (Lásd a korábbi cikk.) A tűzfalas kolléga szerint a hostok között a kért portok engedélyezve vannak.
Ami alapvetően igaz is volt, de amikor megpróbáltak telnetelni, elég érdekes válaszokat kaptak. Lényeg a lényeg, a tűzfalas úriember csak azt felejtette el közölni, hogy a készüléken be van kapcsolva a MailGuard, amelyik meglehetősen szigorú ellenőrzést gyakorol az smtp forgalom felett: egyedül a HELO, MAIL, RCPT, DATA, RSET, NOOP és QUIT parancsokat támogatja, minden más tiltott. Igen, már az ESMTP és az AUTH is.
Nyilván a kikapcsolás után beindult minden.