Kevesen tudják, de a levelezés működtetésében a különböző támadások elleni védekezés több erőforrást képes felemészteni, mint ami a felhasználók postafiókjainak kezeléséhez szükséges.
Erre egy átlagos hazai vállalatnál a megoldás: több memória, nagyobb processzor, esetleg teljesen új szerver - mert hát az igények ezt kívánják.
Nem!
Ha a rendszerünket úgy építjük fel, hogy mindent erőből próbálunk kezelni, akkor erőre lesz szükség, aminek súlyos ára van. Sokan azt hiszik, hogy csak egyszer kell érte fizetni, de nem. A magasabb teljesítménynek magasabb fogyasztás, és magasabb hőtermelés az ára, a magasabb hőtermelés magasabb hűtési kapacitást igényel, és ez így többszörösen jelentkezik a fogyasztásban, aminek hosszú távon nagyon magas lesz a költsége.
Mi a megoldás?
Semmiképp nem javaslom az erőből védekezést. Első körben meg kell érteni, hogy a levelezés nem egy online kommunikációs csatorna, hanem egy offline mód. Hiszen nem csak annak küldhetünk levelet, aki a gépnél ül, hanem annak is, aki éppen utazik, vagy alszik, és amikor elküldünk egy levelet a gondolatainkkal, az a címzettek számára nem lesz azonnal világos, csak azt követően, hogy azt el is olvasták.
Ez a hártánya egyben előny is, hiszen a levél nem csak ideiglenesen tárolódik, de nyoma is marad a rendszerekben.
Viszont tényként kell kezelni, hogy
- az elküldött levél nem azonnal érkezik meg a címzetthez
- az elküldött levelet nem olvassák azonnal
- a levél elküldési ideje van határidőkhöz kötve, nem a beérkezési idő
Ha ezeket el tudjuk fogadni, akkor egy viszonylag egyszerű - és nem utolsó sorban kis erőforrásigényű - védelmi megoldást tudok javasolni.
A megoldás egy többlépcsős folyamat, ami fokozatosan zárja ki a rendszerből azokat az elemeket, amelyektől a levelezésünket védeni akarjuk.
Első lépés: RBL-ek használata
Ha egy email közvetlen küldőjének IP címe tiltólistán szerepel, akkor dobjuk el. A tiltólistára kerülés két ok miatt lehetséges. Lehet azért, mert az IP cím, amit használ, dinamikus tartományban van. Alapszabály, hogy ilyenről nem küldünk levelet - ezért, ha valaki mégis ilyen címet küld, szabálytalanul jár el, és a szabálytalankodókat ki kell zárni a rendszerből, mert veszélyforrás.
A másik ok az lehet, ha az adott címről spam-ek kerültek ki, és emiatt egy cég levelezését blokkolták.
Ilyen esetben nem a fogadó-, hanem a feladó fél feladata, hogy hivatalos úton eljárjon a tiltás feloldása ügyében. Ez normál esetben néhány óra alatt végbe megy, ha ezalatt sürgős kézbesítendője van a feladónak, fel lehet venni a címét kivétellistára - de maximum 24 órára.
Ennyi időnek bőven elegendőnek kell lennie ahhoz, hogy a bajba került feladó informatikusai megszüntessék a hibaforrást, és eltávolíttassák a tiltólistáról a szerverüket.
Az RBL listák használata gyakorlatilag nem igényel különösebb erőforrást egy szervertől, ám extrém esetekben akár a spam-ek több, mint 95%-át is képes megfogni.
Második lépés: Greylist
A greylist egy elég egyszerű, és okos megoldás: várakozásra kényszeríteni minden új levelet - erről természetesen az emberek, akik egymással leveleznek, semmit nem vesznek észre.
Mi számít új levélnek? Amikor egy adott feladó egy adott címzettnek egy adott szerveren keresztül levelet küld, és ebben a kombinációban ilyen még nem fordult elő ezelőtt.
Ilyenkor a levelet nem vesszük át, hanem megkérjük a küldő kiszolgálót, hogy küldje később. A küldő oldal szervere elraktározza a levelet, és adott idő elteltével újraküldi - ekkor már sikerrel.
Látszólag annyi történik, hogy nem azonnal vesszük el a levelet, ami miatt 5-30 percet késhet. Hogy ez miért jó, ahhoz a levélküldés menetének pontosabb ismerete kell.
Mint ahogyan írtam, a levelet a küldő szerver elraktározza egy rövid időre. Ez senkinek sem fáj - de csak normál esetben!
A spamküldő hostok többsége kisebb, elfeledett webszerver, amelyre a gazdája kevés időt fordít, a gépet feltörik, és egy botnet hálózat részévé válik. Az erőforrásait pedig illegális célokra használják. Egy ilyen gép képes percenként több ezer levelet is kiküldeni, ám, ha ezek nagy része várakoztatásra kényszeríti, akkor 20-30 perc alatt olyan sok levelet kéne elraktároznia és/vagy újraküldenie, hogy az már meghaladná az erőforrásait. Leállna rajta a levélküldés, vagy a szerver magas terhelése maitt felhívná magára a figyelmet, és a gazdája esetleg visszavenné fölötte a hatalmat.
A spammereknek egyik eset sem kedvező. Ezért azokat a leveleket, amiket nem lehet azonnal kézbesíteni, nem őrzik meg, így nem is küldik újra.
Ismét kizártunk sok potenciális veszélyforrást egy nagyon egyszerű trükkel.
Csatolmányok ellenőrzése
Ez innentől kezdve már az erőforrásigényes védelem része, ezért is volt fontos, hogy a bejövő káros tartalom alig kevesebb, mint 100%-át kizárjuk a rendszerből.
Fájltípus vizsgálat
A csatolmányok a fájl tulajdonságai, nem pedig a neve/kiterjesztése szerint kerülnek osztályba sorolásra. Így, ha egy futtatható állományt (.exe) átnevezünk szövegfájlnak (.txt), az attól még fenn fog akadni a szűrőn.
Általánosan elfogadott, hogy az Office leggyakoribb fájljain kívül (.doc, .docx, .xls, .xlsx) minden tartalmat tiltunk, mert veszélyes. Ám a leveleket nem dobjuk el, csak karanténba helyezzük, ahonnan a levél címzettje visszanyerheti a levelet, de csak azután, hogy a helyi informatikus megvizsgálta, és meggyőződött annak a veszélytelenségéről.
Víruskeresés
Ha a fájl elfogadható, akkor még azt is ellenőriznünk kell, nincs-e benne esetleg vírus.
Ha a szűrő gyanús tartalmat észlel, akkor szintén karanténba kerül a levél - megeshet, hogy a riasztás téves, de erről szintén egy szakembernek kell meggyőződnie, és azt visszairányítani az eredeti címzettekhez.
Spamszűrés
Csak ezeket a műveleteket követően kerül sor a spamszűrésre, ami a levél egyes formai hibái, a tartalmazott szavak, kifejezések, és a korábbi tanulási eredmények függvényében plusz és mínusz pontokat ad egyes tulajdonságokra (itt van nem kis jelentőssége az SPF, DKIM, ADSP és DMARC beállításoknak), és ha az összpontszám átlép egy küszöbértéket, akkor a levél a címzett postafiókja helyett a karanténba érkezik.
Ahonnan az informatikus persze át tudja adni a címzettnek, ha az kéri.
A spamek kézbesítéséből a rendszer tanul, így néhány kézi kézbesítést követően (ha a levél nem tragikusan szabálytalan) ezek a levelek már nem fognak beesni a karanténba.
Kézbesítés
Ha a levéllel minden rendben volt, akkor az bekerül a címzett postaládájába.
Ha ennek ellenére mégis bejut valakihez egy nem kívánatos levél, az a levélszemét könyvtárba (Junk) helyezhető, így azt a rendszer onnan képes megtanulni, így a későbbiekben már nem fogja a felhasználót bosszantani.
Egy ilyen feladatra egy kb. 10 éves, az akkori színvonalnak megfelelő közepes teljesítményű asztali gép erőforrásai kb. 200-500 ember levelezésének az ellenőrzésére elegendőek, napi többszázezres bruttó levélforgalom mellett.
