it-swarm-tr.com

Paypal başkalarından geldiğini söylemek için e-postaları nasıl bu kadar kolay taklit edebilir?

Paypal'da bir ödeme aldığımda, bana bu konuda bir e-posta gönderir (aşağıda resmedilmiştir). Sorun, gerçek gönderenin Paypal olmasına rağmen, e-postanın Paypal'ın değil, para gönderenin e-posta adresinden geldiği gösterilmiştir.

Email from Paypal

Gmail'de "orijinali göster" i seçtiğimde görünen metin:

From: "[email protected]" <[email protected]>  
Sender: [email protected]

Böylece gerçek gönderenin Paypal olduğunu görebilirsiniz.

Paypal e-posta göndericisini bu kadar kolay sahtekarlık yapabilirse ve Gmail bunu tanımıyorsa, bu e-posta gönderen adresini kimsenin sahtekarlığa uğratabileceği ve Gmail'in tanımayacağı anlamına mı geliyor?

Telnet kullanarak Gmail'e kendim e-posta gönderdiğimde, e-posta şu uyarıyla birlikte gelir:

Bu mesaj gönderilmemiş olabilir: [email protected]

Bu bir güvenlik sorunu mu? Çünkü Paypal'daki ödeme e-postalarının Paypal'dan değil, para gönderenin e-postasından geldiği anlaşılırsa, gönderen, e-postasından böyle bir mesaj göndererek ödemenin kendisini sahtekâr yapabilir ve bunu düşünebilirim. bu gerçek ödeme.

Bu Paypal'a özgü bir şey mi, yoksa Gmail'i böyle kandırabilecek biri var mı? Ve eğer yapabilirse, Paypal'ın Gmail'i kandırmak için kullandığı yöntem tam olarak nedir?

147
Sunny88

İşte herhangi bir yere posta alındığında iletişimin nasıl gittiğine dair bir dramatizasyon.


Bağlam: Moskova'da bir yerde tek başına bir e-posta sunucusu. Sunucu beklenti ifadesiyle sadece boşta oturuyor.

Sunucu:
Ah, uzun zaman kulluklarımın günleri,
Bu yalnız başına harcanacak,
'Ere dış halkalardan geliyor
Swift harici haber taşıyıcısı.

Bir bağlantı açıldı.

Sunucu:
Gelen bir müşteri! Bir postayı perchance
Vesayetime emanet edilir
En dürüst atı olarak iletebileceğim
Ve alıcıya masalın tamamını getirin.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Alemime hoşgeldin, ağ gezgini,
Güçlü bir posta sunucusu olduğumu öğrenin.
Bu gün nasıl ele alınacak?
Adınızın tahmin edilebilmesi için ihtiyaç doğacak mı?

Müşteri:

HELO whitehouse.gov

Sana selamlar, ağ iletişimi sorumlusu,
Solgun binadan doğduğumu biliyorum.

Sunucu:

250 mailserver.kremlin.ru

Gelen IP adresi DNS üzerinden "nastyhackerz.cn" olarak çözümlenir.

Soylu elçi, ben senin emrindeyim,
Sesiniz sıcak ovalardan gelmesine rağmen
Asya dağlarının ötesindeki topraklardan,
En zorlu talebinize uyacağım.

Müşteri:

MAIL FROM: [email protected]
RCPT TO: [email protected]
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

İşte mesajım, gönderebilmen için,
Ve eteri sadakatle iletir;
Gönderenin adreslerine ve adına dikkat edin
Bu diğer tarafta gösterilecek.

Sunucu:

250 Ok

Bu yüzden yazılmıştır, bu yüzden yapılacaktır.
Mesaj gönderildi ve Rusya'ya gitti.

Sunucu e-postayı olduğu gibi göndererek, istemcinin ilk komutunda verdiği adı işaretlemek için yalnızca bir "Alınan:" başlığı ekler. Sonra Üçüncü Dünya Savaşı başlar. Son.


Yorum: E-postada güvenlik yoktur. Tüm gönderen ve alıcı adları gösterge niteliğindedir ve kimlik sahtekarlığını tespit etmenin güvenilir bir yolu yoktur (aksi takdirde çok daha az spam olur).

390
Tom Leek

İstediğiniz giden verileri değiştirebildiğiniz için, herhangi bir 'gönderen' e-posta adresi adres sahteciliği yapabilir. Gmail'i kandırmanıza gerek yok. Bunu söyleyerek, bir kuruluştan gönderilen olarak işaretlenen bir e-posta başka bir alan adından geldiğinde gmail bariz sorunları tespit edebilir.

Ayrıca orijinal e-postanın örneğin Paypal'dan geldiğinden de emin olamazsınız - bu gönderen bit de sahte olabilir!

Bunun olmasını önlemek için bir tür kimlik doğrulaması istiyorsanız, e-postaları imzalamanın veya şifrelemenin bir yoluna veya e-postanın arkadaşınızdan geldiğini onaylamak için bant dışı bir kontrole ihtiyacınız vardır (yorumunuzda belirtildiği gibi)

Ciddi - herhangi bir e-postaya güvenme. bir e-postadaki herhangi bir bağlantıyı tıklatmayın. Özellikle Paypal gibi yüksek değerli hedeflerden. Bunun yerine normalde yaptığınız gibi giriş yapmanız ve size bir şey gönderip göndermediklerini kontrol etmeniz gerekir.

52
Rory Alsop

Diğerlerinin de belirttiği gibi, herkes sahte olabilir herhangi bir "Gönderici" alanı da dahil olmak üzere e-posta adresi - Paypal'ın kendi e-postalarını eklemesi için teknik bir neden yoktur gönderen alanında, sadece dürüst bir şirket oldukları için bunu yaparlar. Spam göndericilerin bu kadar güzel olmasını beklemeyin.

Bununla birlikte, bir yana, gmail'in DKIM desteğine sahip olduğunu belirtmek isterim, bu da Paypal'dan gerçekten bir Paypal e-postası geldiğini doğrulamanızı sağlar.

Etkinleştirmek için: Sağ üstteki dişli çark simgesini tıklayın -> posta ayarları -> laboratuvarlar -> Etkinleştir "Doğrulanmış gönderenler için kimlik doğrulama simgesi"

(gmail labs image)

Şimdi imzalı Paypal e-postaları yanlarında küçük bir anahtar simgesiyle görünecektir:

(example image)

Posta gibi. Herkes size bankanızın yerel şubesine benzeyen antetli bir mektup gönderebilir. Böyle taklitçileri yakalamak için yapabileceğiniz bazı şeyler var - posta damgasının doğru şehirden olduğundan emin olabilirsiniz. Bankanız her zaman tek tek pullar yerine toplu posta kullanıyorsa, bunun farkına varabilirsiniz. Ama muhtemelen bunları kontrol etmek için asla uğraşmazsınız ve bunu yapsanız bile, mektubun bankanızdan geldiğini doğrulamak için yeterli olmaz.

Posta ve e-posta arasındaki temel fark, e-posta ile sahteciliğin daha pratik olmasıdır - bir kez tasarlanabilir ve daha sonra neredeyse sıfır maliyetle tekrarlanabilir.

Bu, tüm sahteciliklerin ve karşı önlemlerin daha büyük bir ölçekte olduğu ve (benim gibi değilseniz1) bazı sahte postalar gelen kutunuza gelir ve manuel olarak filtrelemek size bağlıdır.

Alt satırda, tıpkı "hesap bilgilerinizi doğrulamak" (SSN'niz ve Kredi Kartınız gibi) için bir mektupta bir telefon numarasını aramamanız gibi, e-postalardaki bağlantıları tıklamamalı ve giriş ekranından veya herhangi bir formdan beklememelisiniz. Özel bilgileri güvenli bir şekilde bankanıza gönderin. Bunu yaparsanız, kimlik bilgilerinizi bir sahtekâra gönderirken bulabilir ve asla farkına varamazsınız.


1. Tüm spam'ları kaldırdım. Kendi alan adım var. Her kişiye kendi e-posta adreslerini veriyorum ve hepsi tek bir gelen kutuma geliyor. Bu şekilde, Bob bilgisayarına virüs bulaşırsa ve bu düşük düzeyli spam'lardan bazılarını almaya başlarsam, Bob'a e-posta şifresini değiştirmesini ve e-postası için yeni bir e-posta adresi kullanmaya başlamasını söyleyebilirim. Yeni e-posta adresi herhangi bir spam almaz ve eskisini silebilirim, çünkü sadece Bob onu kullanıyordu.

Bankama ve diğer arkadaşlarıma, satıcılarıma, iş arkadaşlarıma, e-posta adresimin değiştiğini söylemek zorunda değilim, çünkü her birinin kendi adresi var. (StackExchange ve Gravater'ı bile güncellemem gerekmiyor.) Bu benim için iyi (spam yok), Bob için iyi (o bir "virüs ya da bir şey" olduğunu biliyor - bazen yapabilirim doğrudan olun, ancak daha sonra yanlış olmamak için dikkatli olun), diğer arkadaşlarım için iyi (son 24 saat içinde kaç e-posta aldığımı hiç şikayet etmiyorum ve neden onlara geri dönmediğimi açıklamıyorum)

25
Bryan Field

Sanırım yukarıdaki dramatizasyonda bahsedilen küçük bir ayrıntıyı göz ardı ettiniz, bu gerçekten kontrol etmek gerçekten kolay:

Sahte e-postalar, kaynaklandığını iddia ettikleri alan adına yasal olarak ait olan bir e-posta adresinden gelmez. SMTP protokolünün bir kısmı, tam ileti üstbilgileri (her zaman iletinin dönüş yolunu içerir. aslında mesajı gönderen e-posta adresidir. Sadece bu değil, IP adresleri de atandıkları kesin bir coğrafi bölgeye sahiptir. Böylece bu tutarsızlıkları biraz kazarak yakalayabilirsiniz.

Örneğin, söz konusu dramatizasyonu ele alalım.

E-postanın whitehouse.gov'dan geldiğinden bahsediyor. İşte IP adresi:

[email protected]:~ $ Dig +short whitehouse.gov
173.223.0.110

Şimdi diyelim ki nastyhackerz.cn, 1.0.32.0-1.0.63.255 bloğunda bir yerde bir IP adresine çözüldü (referans için: http://www.nirsoft.net/countryip/cn.html listedeki ilk blok). Bu IP adresi tam ileti üstbilgilerinde olacak. Yapmanız gereken tek şey, IP'sini coğrafi konumunu izlemek için çevrimiçi yapmaktır (örneğin http://www.geoiptool.com/ )

Bu yazıyı yazarken whitehouse.gov (173.223.0.110) IP'si, Boston, Massachusetts'e coğrafi olarak yerleşir (bir nedenle, bir spam önleme sistemi, itibar puanları nedeniyle geoiptool'da aramamı yayınlamama izin vermez, böylece gidebilirsiniz aramayı kendiniz yapın) eve (Columbia Bölgesi) oldukça yakın! Diyelim ki whitehouse.gov, bunu daha kolay açıklamak için Boston'daki bir veri merkezinde barındırılıyor.

E-postanın gönderildiği IP ve e-posta adresi aslında , e-postanın iddia ettiği IP ve e-posta adresiyle eşleşmediği sürece gönderilecek, parodi olarak belirlenebilir. Sadece full ileti başlıklarına bakmanız yeterlidir.


Kendi alan adlarımdan (dragon-architect.com) kendi kişisel e-posta adresime gönderdiğim bir e-postanın başlıklarına bakalım:

Delivered-To: [email protected]
Received: by 10.180.89.68 with SMTP id bm4csp105911wib;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
X-Received: by 10.60.30.38 with SMTP id p6mr1296792oeh.2.1359478487251;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
Return-Path: <[email protected]>
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35])
    by mx.google.com with ESMTP id m7si14056914oee.29.2013.01.29.08.54.45;
    Tue, 29 Jan 2013 08:54:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) client-ip=69.93.154.35;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) [email protected]
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007)
    id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST)
Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130])
    by gateway14.websitewelcome.com (Postfix) with ESMTP id EA7191DFDB314
    for <[email protected]>; Tue, 29 Jan 2013 10:54:42 -0600 (CST)
Received: from [127.0.0.1] (port=43458 helo=dragon-architect.com)
    by bentley.websitewelcome.com with esmtpa (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1U0ESK-0001KE-DP
    for [email protected]; Tue, 29 Jan 2013 10:54:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Jan 2013 10:54:44 -0600
From: [email protected]
To: <[email protected]>
Subject: Headers Test
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/0.8.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bentley.websitewelcome.com
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dragon-architect.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (dragon-architect.com) [127.0.0.1]:43458
X-Source-Auth: [email protected]
X-Email-Count: 1
X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20=

Testing testing!

Bu, gözden geçirmek için çok fazla rastgele veri var, ancak burada baktığımız iki satır var: dönüş yolu ve. Bu e-postayı yasal olarak kendime gönderdiğim için ikisi de eşleşiyor. Dönüş yolu taklit edilemez. Ya da mümkünse, etkili bir şekilde kimlik sahtekarlığı yapmak inanılmaz derecede zordur ve posta göndermek için kullanılan SMTP arka plan programının kasıtlı olarak yapılandırılmasını gerektirir. Tam başlıklardaki dönüş yolunu ve veri alanlarını karşılaştırmak, çalıştığım iş arkadaşlarımın ve meslektaşlarımın kimlik sahtekarlığını tespit etmesinin ve bir destek biletinin gönderilmesi gerekip gerekmediğini belirlemenin bir yoludur.

Peki, ikisi de eşleşirse, ancak e-posta yine de sahte olmalıdır? Bunu bir sonraki bölümde ele alacağım ...


Şimdi, daha önce de belirtildiği gibi, bir e-postanın aldatmacalarını belirlemenin başka yolları da var. SPF kayıtları bu yollardan biridir, ancak her zaman mükemmel değildir. Örneğin, whitehouse.gov'un SPF'sini alın ve kendi alan adımın SPF'si ile karşılaştırın:

[email protected]:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
[email protected]:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Genellikle, iyi bir SPF kaydı, postayı gönderen sunucunun IP adresini de içerir, bu nedenle whitehouse.gov için SPF kaydını kim yaptıysa muhtemelen bunu bilmez. Whitehouse.gov'un SPF kaydının, whitehouse.gov kaynaklı olduğunu iddia eden iletilerin gerçek kökenlerini belirlemede etkili olamayacak kadar genel olduğunu düşünürdüm. Kendi alanım için SPF ise alan adımı barındıran sunucu tarafından otomatik olarak oluşturulan (webhost'umun izniyle), çok spesifik ve sunucunun IP adresini içeriyor.

SPF kayıtlarının nasıl biçimlendirildiğini ve nasıl çalıştığını yakından tanımadığımı itiraf edeceğim, ancak işimde en azından genel ve spesifik SPF kayıtlarını tanımlayabileceğim kadar öğrendim. Sanırım bu sıkıldığımda bir hafta sonu kazmam ve teknik okuma materyali istemem gereken bir şey!

Her neyse, buraya geri dönüyoruz. Alınan hatlara bakın. Bunlardan biri şöyle ifade eder: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Bilin bakalım ne oldu? Bu, alan adımın SPF kaydındaki IP adresiyle eşleşiyor.

SPF'deki IP, e-postayı gerçekten gönderen sunucunun IP'siyle eşleşmiyorsa, bu sizin ellerinizde parodi olduğunu gösterir. Bu nedenle, "v=spf1 +mx ~all" Gibi genel bir SPF kaydı güvenlik hardalını kesmeyecek. Böyle bir genel SPF'ye sahip bir meşru alan adından gelen e-postalara bile güvenmem.

Belki de güvenlik yöneticilerinin alan adı için yaptıkları SPF kaydını tekrar ziyaret etmelerini talep etmek için petitions.whitehouse.gov adresine bir dilekçe vermeliyiz! (Ben evlat, ben evlat.)

[~ # ~] düzenlemek [~ # ~]

Aslında [~ # ~] kitlesel [~ # ~] SPF kayıtları hakkında kendimi düzeltmek zorundayım! Bazı yanlış varsayımlar yaptım ve bugün SPF kayıtları hakkında benden daha fazla bilgi sahibi olan bir iş arkadaşına sorduktan sonra birkaç şey öğrendim. Bu yüzden, kendi düzeltmemde whitehouse.gov ve dragon-architect.com için iki SPF kullanacağım:

[email protected]:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
[email protected]:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Kendi alanım için SPF aslında whitehouse.gov için SPF'den daha yumuşaktır (bu düzenlemeyi bitirdikten sonra bu gece düzeltmeyi planladığım bir şey). Nedenini açıklayacağım:

"v=spf1 +mx ~all" Temel olarak whitehouse.gov adresinden gelen e-postaların whitehouse.gov için MX kayıtlarında tanımlanan ana bilgisayar adlarından gelmesi ve bu ana bilgisayar adlarından gelmeyen e-postaların kimlik sahtekarlığı olması gerektiğini söylüyor. adres sahteciliği veya e-postasının alıcısına kalmış.

[email protected]:~ $ Dig +short mx whitehouse.gov
110 mail6.eop.gov.
105 mail2.eop.gov.
110 mail5.eop.gov.
105 mail1.eop.gov.
105 mail4.eop.gov.
105 mail3.eop.gov.

"v=spf1 +a +mx +ip4:70.84.243.130 ?all" Dragon-architect.com adresinden gelen e-postaların ejderha mimarı için MX kayıtlarında tanımlanan ana makine adları olan dragon-architect.com IP adresinden (67.18.28.78) gelmesi gerektiğini söylüyor .com veya dragon-architect.com'u barındıran sunucunun IP adresi (70.84.243.130). Bunlardan gelmeyen e-postalar, yani, sonunda, sadece e-postaları geçme veya reddetme konusunda herhangi bir tavsiye olmadığı anlamına gelir.

Peki bir SPF kaydının et ve patatesleri nedir? En sonunda "hepsi". Bu iş arkadaşınıza "tümü" hakkında bilgi vermek için:

+all basically means ALL pass -- the record is useless, sender domain doesn't care
?all indicates neutral and is advising to not pass or reject mail
~all indicates fail, and the server is considered invalid, but does not specifically suggest an action.
-all is a hard fail, anything else is invalid, reject or flag it.

Böylece "hepsi" SPF kaydınızın ne kadar katı olduğunu tanımladığınız yerdir. Ancak bir e-postanın aldatmacalarını belirlemek için SPF kaydının aslında kullanılmış olup olmadığı tamamen alıcıya kadar e-posta hizmeti.

İşte burada. Özetle SPF.


Yani evet. TL; DR: dönüş yolunun ve alanların eşleşip eşleşmediğini görmek için tam başlıklarınızı kontrol edin. Ardından, eşleşen IP adresleri alıp almadığınızı görmek için SPF kayıtlarınızı bir kez daha kontrol edin.

15
Calyo Delphi

SMTP (Basit Posta Aktarım Protokolü) çok iyi bir nedenle adlandırılmıştır.

SMTP, 1982 yılında ABD DoD'sinin sahibi olduğu ve kontrol ettiği eski ARPANET'ten kaynaklandı ve genellikle kötüye kullanmamaya genel olarak güvenilebilecek hükümet projelerinde çalışan güvenlik izinleri olan insanlar arasındaki iletişimi amaçladı. Bu ağın "güvenliği", basitçe, bu tesislerin gerçekleştirdiği sınıflandırılmış çalışmaların yanı sıra, çeşitli tesislerin fiziksel olarak güvenli alanlarına bağlanabilecek makineleri yerleştirerek sağlandı. Sonuç olarak, aslında ağ üzerinden gönderilen verilerin güvenliğini sağlama genellikle ARPANET'in hizmetinden çıkarılıncaya kadar dikkate alınmadı, ilk kuantum sıçraması Güvenli Ağ Programlama API'sı (yaklaşık olarak şimdi bilinen Güvenli Yuva Katmanı Tabakasının temelini oluşturan 1993) ile geliyor. Taşıma Katmanı Güvenliği olarak). Çoğu protokol (SMTP/POP/IMAP dahil) artık güvenli bir iletişim kanalı için TLS ekleyebilse de, tüm bunlar gizlilik ve sunucu özgünlüğüdür; gönderenin özgünlüğünü veya ileti bütünlüğünü sağlamaz ve ayrıca reddedilmemesini de sağlamaz.

E-posta güvenliği için PGP adı verilen bir seçenek var (Pretty Good Privacy; Phil Zimmerman'ın düzgün bir şekilde uygulandığında gezegende hiçbir bilgisayarın kırılamadığı bir sistem için yanak mizahı). Çeşitli seçeneklerle, dört temel bilgi güvenliği ilkesini sağlayabilir; gizlilik, bütünlük, özgünlük ve reddedilmeme (e-postayı sertifikalarını kullanarak imzalayan gönderen, gerçekten göndermediklerini iddia edemez; sertifikadan ödün verilmedikçe başkası olamazdı). İki yönlü bir TLS anlaşmasında görüldüğü gibi benzer bir ortak anahtar sertifika sistemi ve güvenli anahtar değişimi sistemi kullanıyor, ancak bazı ayrıntılar e-posta aktarımının eşzamansız yapısını yansıtacak ve merkezi olmayan bir arzuyu yansıtacak şekilde değiştirildi " küresel güvenilen sertifika yetkililerine olan ihtiyacı ortadan kaldıran güven ağı ".

Bununla birlikte, bu sistem 25 yaşın üzerinde olmasına rağmen gerçekten başlamamıştır ve bu nedenle sadece devlet kurumları ve bazı büyük şirketler tarafından gereklidir. Neredeyse tüm e-posta sağlayıcıları gelen kutunuza güvenli bağlantılar üzerinden hileli e-postaları yine de mutlu bir şekilde teslim edecektir. Birçok durumda, arkadaşlarınızı ve e-posta almak istediğiniz diğer kişileri PGP şemasını benimsemek için teşvik edebilirsiniz ve geçerli olarak imzalanmamış herhangi bir şey "karantinaya" girer, ancak bu gerçekten sadece "spam filtrelemenin başka bir düzeyidir" "ve dijital imza açıkça olmadan e-postaları reddetmeyi söyleyebileceğiniz tek bir genel e-posta sağlayıcısı bilmiyorum; kurumsal Exchange sunucusu gibi e-posta sunucusunun sizin kontrolünüzde olması gerekir.

12
KeithS

tl, dr

  • Paypal burada bir güvenlik sorununu mu kullanıyor? ... Paypal e-postalarını nasıl bu kadar kolay bir şekilde taklit edebilir?

Teknik olarak, bu bir güvenlik sorunu değil, e-posta ile başlamak güvenli değildir. İleti başlığında bulunan aşağıdaki SMTP başlıklarından birini kullanıyorlar (zarf başlığı değil)

  1. Resent-From
  2. Resent-Sender
  3. Sender

"Kalan" ve "kimlik sahtekarlığı" arasında kavramsal bir fark vardır. E-posta istemcisi gerekir bu farkı görüntüler. Gmail istemcisi bunu yapmaz.

  • Paypal kimlik sahtekarlığı yapmazlar, şu SMTP başlıklarından birini kullanıyorlar: Yeniden Gönder, Yeniden Gönderen veya Gönderen

  • Bir etki alanını taklit etmek çok kolaydır ... SPF denetimleri etkinleştirilmiş olsa bile

  • MUA (e-posta istemcisi) Görüntüleme Kaynağı, SPF, DKIM ve DMARC doğrulama durumunu görüntülemelidir.

  • Resent- * üstbilgisi, bu iletinin "yeniden" kaldırıldığını gösterecek şekilde kullanılmalıdır.

  • Genel olarak en iyi çözüm DKIM + DMARC veya SPF + DMARC ve doğrulama sonuçlarını gösteren bir MUA kullanmaktır.


Bazı arka planlar

Genel olarak, her SMTP mesajında ​​iki "from" adresi ve iki "to" adresi vardır. Biri RFC2821 Zarfı, diğeri RFC2822 Mesajı olarak bilinir. Farklı amaçlara hizmet ediyorlar

Zarf: (RFC2821)

  • Zarf, SMTP başlığında görünmeyen meta verilerdir. Mesaj bir sonraki MTA'ya gittiğinde kaybolur.

  • RCPT From:, NDR'lerin gideceği yerdir. Bir mesaj Postmaster'dan veya bir kalan hizmetten geliyorsa bu genellikle <> Veya [email protected] Olur. Salesforce'un, iletinin geri dönüp dönmediğini görmek için [email protected] Gibi bir veritabanında anahtar olarak constantContact işlevini kullandığını görmek ilginçtir.

  • RCPT TO: Mesajın gönderildiği kişidir. "To" ve "bcc" kullanıcıları için benzer şekilde kullanılır. Bu genellikle posta istemcisinde "adreslerin görüntülenmesini" etkilemez, ancak MTA'ların bu alanı görüntüleyeceği durumlar vardır (RFC2822 üstbilgileri bozuksa).

Mesaj (RFC2822)

  • Mesaj kısmı data komutu verildiğinde başlar.

  • Bu bilgiler, tanıdığınız SMTP başlıklarını, iletiyi ve eklerini içerir. Tüm bu verilerin, mesaj gelen kutusuna ulaşana kadar art arda her MTA'dan diğerine kopyalandığını ve yapıştırıldığını düşünün.

  • Her MTA için yukarıda belirtilen kopyayı öneklemek ve MTA (kaynak IP, hedef IP, vb.) İle ilgili bilgileri yapıştırmak gelenekseldir. Ayrıca SPF çek detaylarını yapıştırır.

  • Bu Display From Yerleştirilir. Bu önemli. Kimlik sahtekarları bunu değiştirebilir.

  • Zarftaki Mail From: Atılır ve genellikle buraya NDR'ler için return-path: Adresi olarak yerleştirilir

Peki insanların Görüntüyü Kimden değiştirmesini nasıl önleyebiliriz? DMARC, SPF kaydı için ikinci bir anlamı yeniden tanımlar. Zarf Kimden ve Gösterim Kimden arasında bir fark olduğunu ve eşleşmemelerinin meşru nedenleri olduğunu kabul eder. SPF başlangıçta yalnızca Zarf Kimden ile ilgilenmek üzere tanımlandığından, Görüntüleme Kaynağı farklıysa, DMARC iletinin söz konusu IP adresinden izin verilip verilmediğini görmek için ikinci bir DNS denetimi gerektirir.

Senaryoların iletilmesine izin vermek için DMARC ayrıca Display From öğesinin DKIM tarafından şifreli olarak imzalanmasına izin verir ve yetkisiz spam gönderenlerin veya kimlik avcılarının bu kimliği kabul etmeye çalışması halinde şifreleme başarısız olur.

DKIM nedir? DKIM, mesajda bulunan verileri imzalayan hafif bir şifreleme teknolojisidir. Gmail, Yahoo veya AOL'dan bir mesaj aldıysanız, mesajlarınız DKIM imzalıdır. Asıl nokta, başlıklara bakmadığınız sürece hiç kimsenin sizi DKIM şifreleme ve imzalama kullanarak tanımayacağıdır. Şeffaf.

DKIM genellikle iletilir ve farklı MTA'lara aktarılır. SPF'nin yapamayacağı bir şey. E-posta yöneticileri kimlik sahtekarlığını önlemek için bunu avantajımıza kullanabilir.


Sorun, SPF'nin yalnızca RFC2821 zarfını kontrol etmesi ile ilgilidir, Display From değil. Çoğu insan, bir e-posta iletisinde gösterilen Display From değerini aldığından ve NDR dönüş yolunu önemsemediğinden, bu parçayı korumak ve güvenceye almak için bir çözüme ihtiyacımız var.

DMARC devreye giriyor. DMARC, Görüntüleme Kaynağı öğesini doğrulamak için değiştirilmiş bir SPF kontrolü veya DKIM'in bir kombinasyonunu kullanmanızı sağlar. DKIM, SPF Display From (sık sık meydana gelen) ile eşleşmediğinde RFC2822 Display From'ı şifreleyerek imzalamanızı sağlar.


Kimlik sahtekarlığı bir güvenlik sorunundan mı görüntüleniyor?

Evet, e-posta kimlik doğrulaması birçok satıcının baktığı önemli bir güvenlik sorunudur. Yani Paypal, AOL, Google, Yahoo ve diğer şirketler bu kimlik avı sorununu çözmek için DMARC uygulamaktadır.

E-postalarda neden "Kimden:" başlığını oluşturmak hala mümkün?

Bazı sunucu yöneticileri bu tür şeylerin olmasını önlemek için en son teknolojileri uygulamamıştır. Bu teknolojilerin benimsenmesini engelleyen en önemli şeylerden biri, posta listesi yazılımı, otomatik ileticiler veya okul mezunları (.forwarder) gibi "e-posta yönlendirme hizmetleri" dir. Yani:

  1. SPF veya DKIM yapılandırılmamış.

  2. Bir DMARC politikası oluşturulmadı.

  3. E-posta istemcisi, Görüntüleme Kaynağı ve Yeniden Gönder- * veya Gönderen alanının doğrulama sonuçlarını görüntülemiyor.

Paypal ne yapıyor?

Paypal, yeniden gönderildiğini belirtmek için Sender üstbilgisini kullanıyor. Bu, bu başlığın doğru ve amaçlanan kullanımıdır.

GMail ne yapıyor?

Gmail, Gönderen üstbilgisinin kullanıldığını netleştirmez, Görüntüleme Kaynağı adresini kullanıcı dostu bir şekilde doğrulamaz ve görüntüleme ile gönderen arasında ayrım yapmaz.

5
goodguys_activate