Categoryvirus/spam

Visszanyomás

Habár szerintem már nincs olyan Exchange-közeli ember, aki ne hallott volna az elbökött bevezetése miatt felettébb rossz hírnévre szert tett back-pressure folyamatról, de még mindig van hús a csonton, melyet le lehet rágni.

Ügyfél. Exchange 2007, délután fejreáll. Szaki elkezd nyomozni, megállapítja, hogy elfogyott a C:-n a hely (hiába, hol legyen az smtp queue), elkezdi átrakni a D:-re, de aztán gyorsan el kell mennie máshová, telefon nekem, hogy fejezzem be. Az ilyen hívásokban benne van minden, amiért öröm élni: ideges ügyfél, fejreállt levelezés és egy más ember által elkezdett, de aztán félbehagyott megoldási folyamat.
Szerencsére a probléma tényleg egyértelmű volt: világosan ott figyelt a logban, hogy a queue log-ra kalkulált hely elfogyott, azaz a pánikindikátor 97%-on állt, és ekkor az Exchange már lelövi a levelezést.

Emlékszem, anno mennyit anyáztuk ezért az Exchange fejlesztőket, pedig alapvetően igazuk van. Úgy döntöttek, hogy az adatbázisok – és a 2007-estől már a queue is adatbázis – konzisztens állapota fontosabb, mint a szolgáltatás megléte, azaz ha már borzasztóan kevés a hely, akkor elindítanak egy clean shutdown-t, még mielőtt az elfogyott hely miatt dirty shutdown következne be. Viszont az anyázás is jogos volt, ugyanis az első verzióban a kevés hely az 5GB-re volt belőve. Persze, hogy nem értette az egyszeri admin, hogy most mi a fasz baj van, amikor a 10 GB-s diszk fele még szabad? Cifrázta a helyzetet, hogy nem esett le, sőt, a tapasztalataim szerint még ma sem esett le sokaknak, hogy a queue is adatbázis, tehát bőven hagyni kell neki helyet. És legfőképpen nem a meglehetősen elhanyagolt C: partíción tárolni.

No, mindegy, a kollégától megtudtam, hogy elindított egy szkriptet, mely átmozgatja a queue-t a D: meghajtóra, a folyamat le is ment, de valami még nem kerek, mert továbbra sem indul a el Transport service. Ekkor tovább szürkült a tekintetem. Valahogy nem szeretem, ha az ilyen kényes lépéseket szkriptből futtatjuk, különösen akkor nem, ha maga a mozgatás nem bonyolult és ráadásul jól dokumentált is. Így kezdhettem azzal, hogy leellenőriztem a szkriptet.
Ránézésre minden rendben. Jogosultságok beállítva, ahogy kell, az edgetransport.exe.config fájlban is korrektek a queue bejegyzései. A Transport service pedig elindult, majd pár másodperc múlva megállt.
Hmm.
Eventlog. Azt írja, hogy valami process fogja a queue adatbázist, az Exchange nem fér hozzá.
Vírusirtó. Tuti. A rohadt anyját. Megnéztem és így legyen lottó ötösöm. Valós idejű fájlvédelem bekapcsolva, a kivételek között nem szerepelt az új queue könyvtára. Felvettem. Erre az antivírus program közölte, hogy ehhez újra kellene indítani a gépet.
Hívtam a helyi embert.
– Te, újra kellene indítani az Exchange szervert. Gondolom, nem probléma, mert úgysem megy a levelezés.
– Ööö, ez nem Exchange szerver, hanem SBS. Ezen megy a cég mindene.
– Oké, értem. Újraindítható?
– Nem igazán.
– Tőlem. De addig nem lesz levelezés.
– Khm. Megkérdezem az ügyfelet.

Hamarosan jött a telefon.
– Újraindítható. Akár többször is.

Gondolom, mindenkit hazazavartak, hogy mára vége a munkaidőnek. Szeretem az ilyen rugalmasságot.
Restart. Transport service? Megint áll. Nofene, nofene. Eventlog. Ugyanaz. Valami fogja az adatbázist.
Itt hirtelen elfogytak az ötleteim. Oké, ismerem a Process Explorert, de általában csak a legvégső esetben használom. Kell itt még lennie kézzelfogható magyarázatnak.
Böngésztem tovább az eventlogot és hoppá! Nem csak egy hibaszál van, hanem kettő. Az egyik ez a ‘valami fogja a queue-t’, de van egy másik is, mely nem a szolgáltatás indításakor keletkezik, hanem rendszeres időközönként. Hogy mit mond? Hát, ez elég fura. Az a baja, hogy nem tudja meghatározni a D: meghajtóra jellemző minimális allokációs egység értékét. (Vagy valami hasonló. Nem írtam fel, meg egyébként is, magyar nyelvű szerver.)
Még csak nem is hallottam hasonlóról, de elméletileg okozhatja ez is a bajt. Gugli. Nem mondanám, hogy túl sok találatot kaptam, de ugye az ideális keresés az, amikor csak egy találat van, de az pont az, ami kell. És volt is egy elgondolkodtató cikk: azt írta a hapi, hogy ahhoz, hogy az Exchange 2007 adatbázist tudjon üzemeltetni egy meghajtón, a Network Service számára FC jogot kell adni a gyökérkönyvtáron. Csak. Megnéztem. Nem volt. Hjaj. Megadtam.
Persze, hogy elböktem. Nem mentem be az Advanced gomb mögé, hanem csak nyomtam egy OK-t. Erre elkezdte hozzáadni a Network Service-t a D: meghajtó összes objektumához. Vártam 5 percet. Aztán kimentem konyhába, megvacsoráztam. Fél óra. Visszajöttem. Még nem fejezte be. Na, ja: SBS, azaz fájlszerver is. Aztán lelőttem: mivel ez addicionális jogadás, így nem lesz belőle senkinek sem baja, ha a fájlok felénél nem lesz benne a Network Service a listában. Különben is, ha elindul az Exchange, akkor rendezem a jogosultságokat.
A lényeg: a gyökér most már jó. Transport Service restart… aztán pár másodperc múlva megállt.
Ilyen nincs.
Aki rendszeresen hárít el incidenseket, tudja, milyen érzés ez. Amikor sokadjára állítasz fel valamilyen hipotézist – egyik zseniálisabb, mint a másik – aztán feltúrod az internetet, hogyan lehet a feltételezett akadályt eltakarítani, majd valahogy el is takarítod, aztán hátradőlsz… és nem, az incidens nem szűnik meg.
A végén tényleg használnom kell a Process Explorer-t.
Aztán eszembe jutott még valami. Az a nyűves antivírus szoftver. Nem lehet, hogy az nem engedi elérni a D: gyökeret? Most már nem finomkodtam, kikapcsoltam a realtime fájlvédelmet. Service restart… és… és még megy… még mindig megy… nocsak, még mindig… eventlog… semmi. Ez megjavult.
Hátradőlés. Huh.
Aztán a következő kérdés: hogyan tovább? Mondjam azt az ügyfélnek, hogy ne használjon fájlszintű vírusvédelmet? Egy fájlszerveren? Háát, izé. Akkor inkább próbáljuk meg a két rendszert összenutolni, hátha elketyegnek egymás mellett. Drasztikus kísérlet #1: visszaindítottam a realtime védelmet. A Transport service meg se rezdült. Jó jel. Drasztikus kisérlet #2: bekapcsolt realtime védelem mellett újraindítottam a Transport szolgáltatást. Elindult. Sőt. nem is állt le. Még jobb jel. Tehát elég volt meghatároznia azt az allokációs egységet egyszer, utána már nem piszkálja a gyökeret. Drasztikus kisérlet #3: szerver újraindít. Transport service ugyanúgy megy. Tehát a meghatározott értéket nem a memóriában tárolta, hanem ki is írta valahová.
Oké. Case solved.

Tanulság?

Van az Exchange adminok egyes számú posztulátuma:
“Mindig a víruskereső a hibás.”
Nos, ezt meg kell változtatni a következő formulára:
“Mindig a víruskereső a hibás, még akkor is, ha látszólag ártatlan.”

AntiSpam Update

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.

Elég furán nézek ki a fejemből

Már megint az üzlet. Nem is igazán tudom hová tenni a dolgot.

Na szóval. Van itt egy hasznos oldal. Arról szól, hogy az Exchange egyes verzióváltásaival milyen elemek tűntek el a korábbi verzióból. Külön, hangsúlyozottan hívnám fel a figyelmet az egyikre. Arról van szó, hogy ha felteszed az Exchange 2010 RTM-re az SP1-et, akkor onnantól fogva nem fog működni az Enable-AntispamUpdates parancs. Azaz nem tudod frissíteni a spamfiltered adatbázisát. A “hát akkor mi lesz velem?’ kérdésre ennyi a válasz:

Use Forefront Security for Exchange Server to obtain automatic anti-spam updates. For more information, see Microsoft Forefront Security for Exchange Server(1).

Azaz vegyél meg egy fizetős terméket.

Hangsúlyozom, ezzel az Exchange Server 2007 Edge szerepkörének a lényegét lőtték ki. Pontosabban, összekapcsolták egy másik MS termék – egy vírusirtó – megvételével. Mindezt egy Service Pack-be csomagolva.

(1) Arról nem is beszélve, hogy legalább nekik ismerniük kellene a saját termékeik nevét. Az Exchange 2010-hez adott víruskergető már Forefront Protection for Exchange Server néven fut.

Espéegy a porcelánboltban

Arról, hogy kijött az Exchange2010 SP1, szándékosan nem írtam semmit. Aki nem tudja meg tizenhét forrásból egy napon belül, az vagy traktorbelsőben él, vagy nem is érdekli a dolog. Azt is leírták sokan, sok helyen, hogy mi újdonságokat hozott a rendszerbe.

Foglalkozzunk most azzal, hogy mi mindent nyírt ki? Nem szándékosan persze, de hát így sikerült.

1.
Henrik Walther írt rögtön az elején egy cikket arról, hogy milyen meglepetésekre készüljünk fel.

2.
Aztán nem sokkal később az Exchange blogon jelent meg egy írás arról, hogy milyen problémák derültek ki nem sokkal az SP1 kibocsátása után.

3.
Végül Yuri Diogenes tett ki a blogjára egy cikket arról, hogy ne, hangsúlyozom, ne tegyél olyat, hogy a TMG E-mail Protection rendszeredben lévő Exchange 2010 Edge szerverre ráhúzod az SP1-et. Amennyiben mégis ilyet tettél volna, akkor ne, hangsúlyozom, ne nyúlj semmihez, mert csak tovább rontod a helyzetet. Várd meg a hotfixet, a fiúk a bányában ezerrel dolgoznak. (Hasonló tanáccsal szolgál a hivatalos ISA/TMG blog is.)

Angol tudósok

Oké, ez csak egy figyelemfelkeltő cím.

Valójában amerikai tudósokról lesz szó.

Kaliforniai egyetemeken megpróbálták tudományos módon (mérések, extrapolálás) meghatározni, mekkora hasznot hoznak a spam jellegű cuccok. Rászálltak a Storm botnetre, mértek, szabtak, következtettek – majd kijött egy becsült összeg.

De nem ez a lényeg. Hanem a végkövetkeztetés: a spambizniszben a legjövedelmezőbb tevékenység… az antispam termékek előállítása.
És az ember ne legyen paranoiás.

SMS8200 megint

Mióta bevezettük egyik nagy ügyfelünknél, azóta egy kicsit visszafogom magam. Nem rossz persze, de…
Már a tervezésnél beleszaladtunk egy furcsaságba. A kütyünek két hálókártyája van, de mindkettőnek ugyanabba a LAN-ba kell csatlakoznia. A két NIC között nincs smtp routolás. Magyarul, az egyik lábára jönnek kívülről a levelek és ugyanezen a lábon mennek tovább a belső smtp szerverre. A belső szerver a másik lábára küldi a kimenő leveleket és ugyanaz a láb dobja is ki az internetre azokat.
Valószínűleg teljesítmény okok rejtőzhetnek a háttérben, de akkor is furcsa. (Arról nem is beszélve, hogy könnyű úgy teljesítményt növelni, hogy így az Exchange szerverre hárul a dmz-k közötti smtp routing megvalósítása.)
De nem ez volt a legnagyobb tű a vudubabában.
Egy hét után az eszköz eldobta az agyát. Se ssh, se https, se smtp… egyedül pingre válaszolt. Helyi erő kiment, oldalba rúgta.
Az eszköz feléledt és jó egy órán keresztül működött is. Aztán megint megborult. Helyi erő blazírtan megint kiment és kihúzta a seggéből a hálózati kábelt. (Pusztán Varánusz kedvéért: az eszköz seggéből.:) Gyors rollback a korábbi rendszerre, a levelezés visszaállt.
Az alatt az egy óra alatt, amíg élt a cucc, megpróbáltuk kiolvasni belőle, mitől halt el. Nem sikerült. Pedig meglehetősen sokat próbált emberek ugrottak neki, de nem. Az eszköz alatt ugyanis egy rh linux oprendszer szaladgál – és bárhonnan próbálkoztunk hozzáférni, mindenhonnan a mail admin jail-jébe kerültünk – ahol a korlátozott lehetőségek között nem szerepelt a log elolvasása. (Csak tail volt.) A grafikus felületen viszont kizárólag az MTA logjához fértünk hozzá, az meg nem mondott semmit arról, hol csúszott ki a rendszer alól a talaj.
Mindez elég messze van attól, ami egykor lelkendezésem tárgya volt: hogy ssh és oprendszer szintű konfigurálás. Nyilván van valamilyen mód rá, hogy a Symantec mérnökei belenyúljanak root jogosultsággal, de azért ez kissé kellemetlen metódus ahhoz, hogy mondjuk kinyerjünk egy infót a syslog-ból.