MonthFebruary 2007

Megint tesztlabor

Az elektronikus levelezés van annyira kritikus, a rosszindulatú levélforgalom pedig van annyira ijesztő, hogy általában el szoktam nézni a Symantec ‘tesztlabor’ nevezetű előadásaira, figyelemmel kísérve, éppen hogyan állják a sarat a harcban.
Így történt ma is.
Azt kell mondjam, a legutóbbi alkalom óta nem sok minden változott. (A helyszín, az igen.:) Az előadás nem volt rossz, de azonkívül, hogy a közbenső rétegben kijött egy új appliance család – mely egy icipicit minden területen okosabb, mint az elődje – más változást nem tapasztaltam. Aki esetleg nem volt ott, annak leírnám, mi is ez a köztes réteg:

  • A Symantec az ún. traffic shaping védelmet teszi ki a legkülső rétegbe. Ennek az a lényege, hogy az eszköz (No. 8100 appliance) valamilyen módon megállapítja egy forgalomról, hogy az spam, majd a feladó IP címére egy korlátozó házirendet tesz. Ez a korlátozás egészen brutális is lehet: lehet napi egy elfogadott levél, de lehet kitiltás is. Nagy előnye a technikának, hogy jelentősen csökkenti azt az adatmennyiséget, melyen a következő rétegbeli eszközöknek a meglehetősen számításigényes elemzéseiket el kell végezniük.
  • A köztes rétegben smtp szintű elemzések zajlanak. Itt kerül bevetésre mindazon lelemény, melyet az emberek a kellemetlen email tartalmak ellen kitaláltak – és itt ütközik meg mindez azokkal a leleményekkel, melyeket embertársaink azon célból zúdítanak ránk, hogy dagadtra keressék magukat. Ebben a rétegben a Symantec-nek szintén vannak appliance megoldásai (az SMS 8200 sorozatot itt váltja a 8300-as sorozat) – és vannak szoftveres termékei is (Brightmail).
  • Végül van a – szerveroldali – legbelső réteg, a konkrét levelezőszerver. Ez gyakorlatilag belső terület, itt már a cégen belüli levelezés kerül szűrésre, illetve itt valósul meg a postafiók adatbázisok vizsgálata is.

A továbbiakban inkább csak benyomások:

  • Az előadás azzal kezdődött, hogy Szabi elmondta, miért olyan népszerű a szpemmelés. Olyan meggyőzően ecsetelte, hogy mennyire egyszerű beindítani egy szpemmelésre alapuló vállalkozást, mennyire egyszerű üzemeltetni – és az emberi ostobaságból kifolyólag mennyire biztos a haszon… a végén majdnem kedvet kaptam én is spamware céget alapítani.
  • Pofátlanul megelőztek! Amennyit mostanában alszom, biztos voltam benne, hogy én fogok először elbóbiskolni. Ehhez képest már kezdés után öt perccel érces férfihorkolás fojtotta a szót az előadóba. Hmm, ez is egy probléma – jegyezte meg higgadtan Szabolcs.
  • Erre nem is gondoltam: nemcsak vásárlásra ingerlés, illetve megtévesztés lehet a szpemmelők célja, hanem idetartozik a kattintások generálása is. Link a levélbe – itt oldódik meg az összes gondod – a link mögött meg egy olyan oldal van, amelyik odalátogatók után kér pénzt a reklámozóktól. Ügyes. Mondom én, hogy egyre inkább kedvem van ehhez a szakmához.
  • Egy érdekes szempont. Épp nemrégiben írtam egy gyilkosan ironikus levelet a szolgáltatómnak, miszerint kicsit sokallom a nem nekem szánt leveleket a postafiókomban, a kéretlen levelekről nem is beszélve. Levelemnek azonnal meg is lett a hatása, két napig nem kaptam semmilyen emailt sem. Végül beállt az egyensúly, a napi 60-80 spam helyett max 10-et kapok mostanában. Számomra ez teljesen természetes folyamat volt. Az előadó viszont az ISP-k szempontjából közelítette meg a problémát. Hogy vannak olyan szolgáltatók, akik szándékosan nem szűrnek semmit. Hiszen hogy jönnének ők ahhoz, hogy előfizetőik levelét töröljék? Hogy jönnének ők ahhoz, hogy megmondják, az ügyfél mely levelei minősülnek szpemnek? Lehet, hogy a kedves ügyfélnek kicsi a pénisze, Viagra nélkül állandóan lecsúszik a nadrágja, élete leghőbb vágya pedig egy hamis Rolex?
    Nehéz ügy, mert nem vagyunk egyformák, mi ügyfelek.

Exchange esettanulmány

Van egy ügyfelünk és van nála egy régóta elhúzódó probléma.
Az Exchange organizácójuk nem túl bonyolult, a lentebbi módon néz ki.

Nagyítás

Azaz két administrative/routing group, jelezve, hogy ez valamikor két cég volt, külön IT szervezettel. Mindkét RG-nek saját Internet kijárata van. Mindkét smarthoston X-re végződő operációs rendszer fut. Ami még fontos a történet szempontjából, hogy ‘A’ cég rendszergazdája valamivel paranoiásabb, mint ‘B’ cégé… azaz a smarthoston nem engedi át azokat a kifelé menő leveleket, melyeknek feladója @a.ceg.hu. ‘B’ rendszergazda ellenben mindenkit kienged.
Az elvárt működés az lenne, hogy mindenki a saját kijáratát használja. Ezzel szemben, amennyiben felvesszük ‘A’ cég SMTP konnektorába a * névteret, minden levél – tehát a ‘B’-ben feladottak is – ‘A’ kijáratán mennek ki. Ahol a smarthost el is meszeli a nem oda valókat. Emiatt most gyakorlatilag ‘A’ konnektor le van zárva, mindenki ‘B’-n keresztül levelez.
A cégnél az email meglehetősen kritikus, tehát idő sem nagyon van kísérletezni, meg hibázni sem nagyon lehet.

Kollégám egy évvel ezelőtt kapott egy éjszakát, reggelig sportolt a rendszeren, de nem jutott előbbre. Amint hozzányúlt, felvette a * névteret, megindultak vissza ‘A’ smarthostjáról az NDR-ek, lett is egyből sírás-rívás, árvák könnyeinek potyogása.
Én múlt héten kezdtem el foglalkozni az esettel, péntek délután volt lehetőségem megpiszkálni a rendszert.
Első körben – még hétközben – felvettem mindkét konnektorra egy senki más által nem használt névteret, ahol nekem van egy eldugott postafiókom. (Nem írkálom ki egyenként, de minden smtp névtérhez 1-es súly tartozik.) Ez délután volt, szépen hagytam, hagy terjedjen el az infó a Link State Táblában (LST). Másnap reggel teszteltem, mindkét szerverről küldtem egy levelet magamnak, gyönyörűen a megfelelő kijáraton ment ki mindegyik. Nem lesz itt semmi probléma – nyugodtam meg – akár munkaidőben is át lehetne állítani.
Azért csak megvártam a péntek délutánt. Beírtam a * névteret ‘A’ konnektorába, újraindítottam a Routing Engine Service-t (RES) és az SMTP szolgáltatást, megvártam, amíg az LST frissül, mindenhonnan küldtem egy tesztlevelet – és csak az ‘A’-ból feladott érkezett meg. Jeges rémület szorította össze a szívemet, gondolatban elnézést kértem a kollégámtól, hogy ennyire amatőrnek néztem – és megpróbáltam összekapni magam, hogy megbírkózzak az ismeretlennel. Első körben gyorsan visszaállítottam a kiindulási állapotot, nehogy elvesszenek a levelek. Mondhatnád, hogy mit vacakolok, az smtp konnektoron be lehet állítani, hogy milyen csoportok küldhetnek levelet rajta keresztül, egyszerűen fel kell venni, hogy ‘A’ konnektoron ‘B’ userek ne küldhessenek – és már kész is, lehet menni a pénztárhoz felmarkolni a zsét. Ugyanerre vezetne, ha mindkét konnektoron csak a saját RG-jére érvényesen definiálnám a névtereket. El is raktároztam ezeket a megoldásokat, végső esetben jók lesznek – de itt elsősorban a ‘miért’-et kell megtalálnom és tisztességes megoldást összerakni. A workaround-dal mindig az a baj, hogy nem ismerjük, mi váltja ki, nem tudjuk, milyen más rendellenéséget okozhat. Nehéz így felelősen rendszert üzemeltetni.

Szóval jöhetett a kísérletezgetés. Első körben lecsekkoltam minden elemet. (Az organizáció messze nem ilyen egyszerű, mint amit rajzoltam. Az csak a lényegi vázlat.) Aztán elkezdtem rugdosni a rendszert. (Igen, így identifikálunk: belerúgunk a rendszerbe és lessük, mekkorát sikít.) Nos, láttam olyan csodákat, hogy szemem-szám elállt. A legdurvább az volt, hogy felvettem jó magasra (10) az RG konnektoron a súlyokat, RES újraindít, tesztlevél. És igen, megjött mindkét feladótól! Boldogan csaptam a levegőbe, majd a biztonság kedvéért megnéztem mindkét levél fejlécét. Elég sokáig néztem, egyre üvegesebb szemekkel… majd szóltam Janinak, hogy jöjjön ide, mert ilyesmit még ő sem látott. A ‘B’ szerveren lévő postafiókból a levél az 1-es súlyú út helyett átment a 10-es súlyú RGC-n, majd az ottani 1-es súlyú SMTP konnektor helyett visszament B szerverre – újabb 10-es súly -, végül most már kiment a ‘B’ SMTP konnektoron; azaz mindösszesen összeszedett 21 egységnyi súlyt, az 1 egység helyett. A sportember.

Ha azt mondom, hogy tanácstalan voltam, akkor meglehetősen enyhén fejeztem ki magam. Először is elmentem darts-ot dobálni pár percig. Ránézésre nyugodtnak látszódtam, a figyelmes szemlélőnek legfeljebb az tűnhetett fel, hogy a tábla mellé dobott nyilak is beleálltak a falba. Pedig műanyag hegyűek.

Végül érdekes módját választottam a monitorozásnak. Beírtam újból a * névteret ‘A’ konnektorába, újraindítottam a szolgáltatásokat, mindeközben egy perces auto frissítésre állítottam a Winroute-ot – és fel-alá szkrolloztam a képernyőn, hátha elkapok valahol valami érdekeset. És úgy döntöttem, hogy nem leszek gyáva nyúl, teszek rá, hogy NDR-ek jönnek vissza.
Nos, igen, végül csak elkaptam valamit.
A következő sorozatot láttam:

  • Körülbelül két perc telt el, amíg ‘A’ SMTP konnektora state up állapotba jutott.
  • Körülbelül öt perc telt el, mire az LST frissült.
  • Majdnem tíz percbe telt, mire ‘B’ SMTP konnektora state up állapotba került.

Itt van minden. A magyarázat is, és a megoldás is.
Látható, hogy van egy olyan kritikus öt perc, amikor az organizáció már észleli, hogy két konnektoron is rajta van a * névtér, de a ‘B’ konnektor még nem él. Tehát ebben az öt percben az ‘A’ felé küldi a leveleket. Egyéni balszerencse, hogy mind a kollégám, mind én ebben az öt percben teszteltünk, majd a sikertelen teszt után pánikszerűen álltunk vissza az eredeti állapotra.
Nézzük meg az egyes eseteket:

  • Amikor a teszt névteret vettem fel, nem siettem. Délután beírtam, elmentem haza, reggelig volt ideje elterjedni a változásnak. Azaz nem indítottam újra a szolgáltatásokat, nem került egyik konnektor sem state down állapotba. Persze, hogy ment minden rendben.
  • Na, azzal a súlyemelővel még a hiba gyökerének ismeretében sem igen tudok mit kezdeni. Valószínűleg pont úgy küldtem meg a tesztlevelet, hogy ‘B’ kijárata még éppen nem élt, ezért átment ‘A’-ra, aztán ott valahogy észrevette, hogy időközben életre kelt a ‘B’ SMTP konnektor – és visszament afelé. Elég perverz – és nem is igazán értem, mert nem logikus.

Gyors teszt, immáron jócskán kivárva – és minden levél a saját kijáratán ment ki.
A feladat megoldva.

Aki velem együtt dőlt hátra a székében, elégedetten csettintve, hogy ez egy korrekt lezárása volt az esetnek – igen nagyot tévedett. Ez a megoldás ugyanis – dacára annak, hogy működik – életveszélyes.
Gondolkodjunk el a következő eseteken:

  • ‘B’ rendszergazda újraindítja az Exchange szerverét.
  • Vagy elég csak a Routing Engine Service-t újraindítania.
  • Ledől a ‘B’ smarthost. Oké, tudom, hogy Unix, de a kalapács ellen azok sem rendelkeznek erős védelemmel.

Mindegyik esetben hosszabb-rövidebb ideig az organizáció azt fogja látni, hogy csak ‘A’ konnektor él – és mivel nem tud róla, hogy azon az úton leselkedik Szkülla és Karübdisz – így arra küldi az összes levelet. Azaz nem az történik, hogy ‘B’ konnektor felállásáig a levelek egy kényelmes queue-ban várakoznának – nem, ehelyett egy gusztustalan NDR-rel pattannak vissza.
Szépen végiggondolva a szituációt, visszaállítottam az eredeti állapotot, leírtam, mit tapasztaltam – majd az egészet bedobtam az ‘It needs business decision’ dossziéba.
Amíg ‘A’ rendszergazda nem enged ki minden levelet, addig jobb, ha az a konnektor nem is működik.