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.