Hamis feladó alatt azt értem, amikor egy email feladójának a domain (a kukacot követő) része olyan szerver által kerül küldésre, amely az említett domain-nek nem hivatalos küldő szervere.

Ez a blogbejegyzés a múltkori írásomhoz hasonlóan kifejezetten szakmai jellegű.

Mi is ez pontosan?

Akkor beszélünk hamisított feladóról (szaknyelven email spoofing), amikor egy spammer vagy spambot olyan emailcímet ad meg a levél feladó részében, amely nem felel meg a valóságnak.

Többnyire ezt olyan levelezőszervereken keresztül küldik ki, amelyek valamelyik szolgáltatását feltörték (pl. webszerverek), vagy a vállalati levelezőszerverünk, amikor a spambot-tal fertőzött saját eszközünket a hálózatra kötjük.

Miért problémás a hamis feladó?

Két okból jelenthet kárt.

Az egyik, amikor mi kapjuk. Könnyen lehet, hogy a spam-védelmünk jól működik, azonban néhány esetben bizonyos feladókat és/vagy domain-eket fehérlistára teszünk, mert szeretnénk megkapni a leveleit, ám köztudottan olyan levelezést használ, amit előszeretettel hamisítanak (pl. gmail.com, outlook.com).

Ilyen esetekben könnyebben besurrannak azok a levelek, amelyek hamisított feladóval jönnek.

A másik ok is veszélyes, mivel a mi infrastruktúránkat hozza hírbe. Azaz, a mi domain-ünkkel mennek ki hamisított címmel levelek, és annak ellenére, ha ezekhez nekünk nincs is közünk, a domain-ünket könnyen feketelistára tehetik emiatt.

Hogyan védekezzünk az email spoofing ellen?

Használjunk SPF ellenőrzést a levelező kiszolgálónk határvédelménél, és lássuk el a saját domain zónánkat SPF rekorddal.

Az ellenőrzés technikailag abból áll, hogy a feladó domain zónájából lekérdezzük az SPF rekordot, és csak olyan szervertől fogadjuk el a levelet, amely az adott rekordban megtalálható.

Az SPF rekord arról is rendelkezik, hogy mi a teendő abban az esetben, ha pl. olyan IP címről jön a levél, ami nincs felsorolva a rekordban.

Természetesen a saját zónánkban is úgy kell elhelyezni a rekordban lévő szabályokat, hogy a túloldal el tudja dönteni, hogy mi a teendő.

Hogy működik az SPF rekord?

Az RFC4408 szerint ez lehet egy SPF rekord vagy egy TXT rekord, ha a névszerverünk az SPF rekordot nem támogatja - tartalmilag ugyanúgy néz ki mindkettő.
Pl.:

@    IN    TXT    "v=spf1 +mx ip4:1.1.1.0/28 -all"

Ez pl. arra utasítja a túloldali SPF ellenőrzőt, hogy azonnal fogadja el a levelet, ha az a zónánkban lévő MX rekord IP címéről jön (a + jel azt jelenti ebben az esetben, hogy az ellenőrzés véget ér).

Az 1.1.1.0/28-as tartományból érkező levelek szintén elfogadhatóak.

Az összes többi szerverről érkező levél pedig elutasításra kerülhet (a - jel miatt az ellenőrzés itt is véget ér).

Ha a -all helyett ~all-t használnánk, azzal azt közöljük a túloldallal, hogy az adott IP nem a mi hatáskörünkben van, de ő dönti el, hogy mit tesz vele - ilyenkor általában a spamassassin magas pontokat osztogat a levélre.

A rekordban használhatunk exclude, include, redirect és egyéb hivatkozásokat további rekordokra, mint ahogyan az pl. a gmail.com zóna esetén is tapasztalható - a Google és a Microsoft pont a sok hamisított feladó miatt jól behatárolt SPF rekordokkal rendelkezik, evvel is segítve minket a szűrésben -, használjuk ki.

Bővebb technikai információk itt és itt.

Mindenki használ SPF rekordokat?

Sajnos nem. Pont emiatt kell nekünk használni, ugyanis minél többen teszik ezt, annál kevesebb lesz a spammer.

Bizonyos esetekben nem is kivitelezhető az SPF használata - ott van mindjárt remek példának a freemail.

Sokan használják a címüket levelezőprogramból, ám a freemail csak POP3-at ad, SMTP-t nem, így a felhasználó kénytelen a szolgáltatójának az SMTP szerverét használni, azaz spoofolni kénytelen - még ha legálisan is.

Szívesen mondanám erre, hogy ne használjon senki freemail-t, de leginkább az lenne a jó megoldás, ha a Telekom belátná, hogy inkább készít SPF rekordot, és vagy letiltja a POP3-at, vagy ad a felhasználóknak tisztességes SMTP-t.

Zárszóként egy idevágó idézet Edmund Burke tollából:

A gonosz diadalához csak annyi kell, hogy a jók tétlenek maradjanak.