SPAM szűrés: Ügyfeleink biztonságáért!

SPAM és vírusvédelem

Napjainkban a levelező rendszer legfontosabb része, hogy az "internet felhő" - biztonsági szakértők szerint ködfelhő - folyamatosan érkező SPAM áradatot megfékezze. Ezért a SPAM védelmünket több szintű védelemmel láttuk el.

A felépítés lényege az alábbi:

• A lehető legkevesebb olyan levelet utasítsunk el, amely nem SPAM, de elutasítás esetén a feladó erről értesüljön.A lehető legtöbb

• Ne terhelje a levelezőszervert.

• A postafiók tulajdonosoknak ne kelljen a SPAM működésében közreműködniük és a SPAM-eket ne kelljen letölteni és szűrővel kezelniük a klienseiken.

• SPAM szűrésre kerüljön.

A jelenlegi megoldás a SPAM-ek 99%-ban ad hathatós segítséget.

SPAM védelmünk felépítése 

   1. Fekete listás szűrés (RBL lista)
   2. Szürke lista (Greylist)
   3. Tartalom alapú szűrés
      - Vírusellenőrzés
      - SPAM levelek matematikai ellenőrzése
      - Tiltott csatolt állományok esetén visszautasítás

Fekete listás szűrés

Az RBL (Realtime Block List = Valós idejű blokklista) technika már régóta létezik az elektronikus levelezésben. Lényege, hogy bizonyos szervezetek kigyűjtik az olyan számítógépek, levelező szerverek, hálózatok IP címeit, amelyről bizonyítottan SPAM küldés történt és ezt egy lekérdezhető adatbázisban tárolják. A szerver az e-mail fogadása előtt ellenőrzi, hogy a küldő IP címe szerepel-e valamelyik RBL adatbázisban, és ha igen, hibaüzenettel visszautasítja az e-mail fogadását (erről a feladó értesül egy e-mail formájában, hogy a számítógépe vagy a hálózata szerepel egy fekete listán, ezért az e-mail kézbesítése meghiúsult). Ma már több típusú RBL adatbázis létezik (DNSBL=DNS alapú lista, SURBL = web cím fekete lista, stb.)

Az SMTP szerverünket levélküldésre használó kliensek RBL ellenőrzésen nem esnek át.

Jól működő RBL listák:

• spamhaus.org

• spamcop.net

• psbl.surriel.com

• uceprotect.net

 Szürke lista (Greylist)

A greylist technika kiváló hatékonysággal használható a SPAM-et küldők ellen. Lényege, hogy a minden egyes e-mail fogadáskor az SMTP szerver feljegyzi a levélküldő IP címét, a feladó és a címzett adatait. Ha ez az IP cím még nem szerepel az adatbázisunkban, ezzel a feladóval az adott címzettre (későbbiekben hármas) (azaz első próbálkozás), akkor az SMTP szerver egy ideiglenes hibával visszautasítja az e-mail kézbesítést. A küldő szerver ilyenkor vár néhány percig (5-10 perc), majd újra próbálja elküldeni számunkra az e-mailt. Legalábbis a szabvány szerint működő levelező szerverek ezt teszik. Második próbálkozásra már megtörténik az e-mail kézbesítés, s ezután ezt a hármast 15 napig már "jó" bejegyzésként kezeli a szerver, és minden esetben azonnal elfogadja az e-mailt.

Mi a helyzet a SPAM-küldők esetén?

Nos, a spammelők általában nem szabványos levelező szervereket használnak, hanem olyan szoftvereket, amikkel rövid idő alatt nagy számú SPAM-et tudnak kiküldeni. A szürke lista első esetben visszautasítja az ilyen kapcsolatokat, és mivel ezek nem szabványos levelező szerverekként működnek, nem próbálkoznak újra ugyanilyen adatokkal, vagy azonnal rápróbálkoznak a küldésre. Változtatják pl. a feladó e-mail címét, más IP címről próbálkoznak, de ezek mind elbuknak a szürke lista miatt.

Az SMTP szerverünket levélküldésre használó kliensek a szürke listás ellenőrzésen nem esnek át.

Sok levelező szerver több IP címmel is rendelkeznek így az első kézbesítés elhúzódhat. Ezeket broken MTA-knak hívjuk és ezekre a címekre a greylistinget kikapcsoljuk (Google, Yahoo!, AOL, Holtmail, ...).

A greylist a leghatékonyabb módszer jelenleg a SPAM védelem esetén. Egyedüli negatív hatása, hogy az "első kézfogás" esetén a levél kicsit késve érkezik meg.

 Tartalom alapú szűrés

Hatékony levelezés biztosításhoz feltétlenül szükséges az e-mailek vírusellenőrzése, SPAM szűrése.

A szerver elutasítja a vírusokat, a spameket és blokkol bizonyos mellékleteket az SMTP beszélgetés során, így a feldolgozás terhelés az email rendszerben minimális marad. A küldő egy e-mail üzenetben értesül a sikertelen e-mail kézbesítésről.

Első esetben egy GPL licensz alatt fejlesztett széles körben elterjedt antivírus programcsomag segítségével végzünk ellenőrzést a levél tartalmán. A vírusszűrés a tartalom mellett kiterjed a csatolt állományokra is, még akkor is ha ezek tömörített állományok (Zip, rar, ... a többszörös tömörítés miatt 3 mélységig csomagolja ki a tartalmat a szerver, a többit nem végzi el, de ilyen esetben a felhasználó hathatós közreműködése nélkül nem is képzelhető el vírusfertőzés).

Ettől függetlenül minden partnerünknek erősen javasoljuk az aktív vírusvédelem (mivel nem csak e-mail útján érkezhetnek vírusok) és a szoftveres vagy hardveres tűzfal használatát.

Második esetben egy úgynevezett "pontozásos" rendszerben működő levélszemét szűrő kerül futtatásra. Használata esetén a beérkező levelet különböző szempontok (trágár szavak, csupa nagybetű a tárgyban, nem azonosítható küldő, és egyéb spamra utaló jelek) alapján pontozza a levél tartalmát, fejlécét, stb.

A program hozzávetőlegesen ezer különböző tesztnek vet alá minden e-mailt. Ezek a tesztek az e-mailek tartalmát, felépítését, szabványosságát, méretét, képek, csatolmányok elhelyezkedését, a levél korábbi állomásait vizsgálják át, meghamisításra utaló jeleket keresnek. és még sok mást is vizsgálnak. Ezen tesztek mindegyike egy bizonyos pontszámot ér. A program összeadja azokat a pontszámokat, amelyek a levélre illeszkedő tesztekhez tartoznak.

Ha a levél egy előre beállított pontszámot elér, akkor SPAM-nak minősül, és nem kerül a postafiókba kézbesítésre, hanem egy globális karanténba kerül későbbi elemzés végett. A küldő egy e-mail üzenetben értesül a sikertelen e-mail kézbesítésről. A szerverünkön ez a pontszám igen magas értékre van beállítva, az előtte szereplő többszörös védelem miatt, így teljességgel kizárható, hogy ezen a pontozáson keresztül nem jut el a levél a címzetthez.

Harmadik esetben már csak pár formai feltételnek kell megfelelnie a levélnek:

•  Ne legyen vbs, pif, scr, bat, cmd, com, cpl, dll kiterjesztésű állományok csatolva

•  Ne legyen HTA* állomány csatolva

•  A levél mérete legyen kisebb, mint 20 MB