it-swarm-id.com

Bagaimana cara email spoof Paypal dengan mudah mengatakan itu berasal dari orang lain?

Ketika saya menerima pembayaran di Paypal, ia mengirimi saya email tentang itu (gambar di bawah). Masalahnya adalah bahwa email tersebut tampaknya berasal dari alamat email pengirim uang dan bukan dari Paypal itu sendiri, meskipun pengirim sebenarnya adalah Paypal.

Email from Paypal

Ini adalah teks yang muncul ketika saya memilih "tampilkan asli" di Gmail:

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

Jadi, Anda dapat melihat bahwa pengirim sebenarnya adalah Paypal.

Jika Paypal dapat menipu pengirim email dengan mudah, dan Gmail tidak mengenalinya, apakah ini berarti bahwa siapa pun dapat menipu alamat pengirim email dan Gmail tidak akan mengenalinya?

Saat saya mengirim email ke Gmail sendiri menggunakan telnet, email tersebut dilengkapi dengan peringatan:

Pesan ini mungkin belum dikirim oleh: [email protected]

Apakah ini masalah keamanan? Karena jika saya terbiasa dengan kenyataan bahwa email pembayaran di Paypal tampaknya berasal dari email pengirim uang dan bukan dari Paypal, maka pengirimnya dapat menipu pembayaran itu sendiri dengan mengirim pesan seperti itu dari emailnya, dan saya mungkin berpikir bahwa ini adalah pembayaran nyata.

Apakah ini sesuatu yang spesifik untuk Paypal, atau adakah yang bisa menipu Gmail seperti itu? Dan jika ada yang bisa, metode apa yang digunakan Paypal untuk menipu Gmail?

147
Sunny88

Berikut ini adalah dramatisasi bagaimana komunikasi berjalan, ketika surat diterima di mana saja.


Konteks: server e-mail, sendirian di teluk, di suatu tempat di Moskow. Server hanya duduk diam di sana, dengan ekspresi harapan.

Server:
Ah, lama adalah hari perbudakan saya,
Itu akan dihabiskan dalam kesendirian,
'Ere datang dari luar
Pembawa berita eksternal Swift.

Koneksi dibuka.

Server:
Klien yang masuk! Mungkin surat
Untuk perwalian saya akan dipercayakan
Yang bisa saya sampaikan sebagai kuda paling adil
Dan kepada penerima membawa kisah lengkap.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Selamat datang di ranah saya, pengembara jaring,
Pelajari bahwa saya adalah server email yang perkasa.
Bagaimana Anda pada hari ini akan ditangani
Haruskah kebutuhan meningkat, agar nama Anda bisa ditebak?

Klien:

HELO whitehouse.gov

Salam kepadamu, penjaga jaringan,
Ketahuilah bahwa saya dilahirkan dari gedung pucat.

Server:

250 mailserver.kremlin.ru

Alamat IP yang masuk diselesaikan melalui DNS ke "nastyhackerz.cn".

Utusan yang mulia, saya milikmu untuk diperintahkan,
Meskipun suara Anda berasal dari dataran panas
Dari tanah di luar pegunungan Asia,
Saya akan memenuhi permintaan Anda yang paling kecil.

Klien:

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 !
.

Ini pesan saya, untuk Anda kirim,
Dan dengan setia mengirimkan eter;
Pikirkan alamat, dan nama pengirim
Itu akan ditampilkan di ujung yang lain.

Server:

250 Ok

Jadi itu ditulis, jadi itu harus dilakukan.
Pesan dikirim, dan ke Rusia hilang.

Server mengirim email apa adanya, hanya menambahkan header "Diterima:" untuk menandai nama yang diberikan klien pada perintah pertama. Kemudian Perang Dunia Ketiga dimulai. The End.


Komentar: tidak ada keamanan apa pun di email. Semua nama pengirim dan penerima bersifat indikatif dan tidak ada cara yang dapat diandalkan untuk mendeteksi spoofing (jika tidak, saya akan lebih sedikit spam).

390
Tom Leek

Alamat email 'from' apa pun dapat dipalsukan, karena Anda dapat mengubah data keluar yang Anda suka. Anda tidak perlu menipu gmail. Dengan mengatakan itu, gmail dapat menemukan masalah yang jelas ketika email yang ditandai dikirim dari satu organisasi datang kepada mereka dari domain lain.

Anda juga tidak dapat memastikan email asli dari Paypal dalam contoh Anda - bahwa bit pengirim juga dapat dipalsukan!

Jika Anda ingin semacam otentikasi untuk mencegah hal ini terjadi, Anda perlu cara menandatangani atau mengenkripsi email, atau cek out-band untuk mengonfirmasi email datang dari teman Anda (seperti yang Anda sebutkan dalam komentar Anda)

Serius - jangan percaya email apa pun. Jangan klik tautan apa pun di email. Terutama dari target bernilai tinggi seperti Paypal. Sebaliknya Anda harus masuk seperti biasa dan memeriksa apakah mereka telah mengirimi Anda sesuatu.

52
Rory Alsop

Seperti yang disebutkan orang lain, siapa pun dapat memalsukan alamat email apa pun, termasuk itu Bidang "Pengirim" - tidak ada alasan teknis Paypal bahkan harus memasukkan email mereka sendiri di bidang pengirim, mereka hanya melakukannya karena mereka adalah perusahaan yang jujur. Jangan berharap spammer menjadi seperti ini.

Sebagai tambahan, bagaimanapun, saya ingin menyebutkan bahwa gmail memiliki dukungan untuk DKIM , yang memungkinkan Anda memverifikasi email Paypal yang benar-benar berasal dari Paypal.

Untuk mengaktifkannya: Klik pada roda gigi di kanan atas -> pengaturan email -> laboratorium -> Aktifkan "Ikon otentikasi untuk pengirim yang diverifikasi"

(gmail labs image)

Email Paypal yang ditandatangani sekarang akan muncul dengan ikon kunci kecil di sebelahnya:

(example image)

Ini seperti surat pos. Siapa pun dapat mengirimi Anda surat dengan kop surat yang mirip dengan cabang lokal bank Anda. Ada beberapa hal yang dapat Anda lakukan untuk menangkap peniru seperti ini - Anda dapat memastikan cap pos berasal dari kota yang tepat. Jika bank Anda selalu menggunakan surat massal alih-alih perangko individual, Anda mungkin memperhatikannya, dll. Tetapi Anda mungkin tidak pernah repot untuk memeriksa hal-hal ini, dan bahkan jika Anda melakukannya, itu tidak akan cukup untuk memverifikasi bahwa surat itu berasal dari bank Anda.

Perbedaan utama antara surat pos dan email, adalah bahwa dengan email, pemalsuan lebih praktis - dapat dirancang satu kali, dan kemudian diulang dengan biaya hampir nol.

Ini berarti bahwa semua pemalsuan dan penanggulangan berada pada skala yang lebih besar, dan (kecuali Anda seperti saya1) beberapa email palsu akan tiba di kotak masuk Anda, dan terserah Anda untuk memfilternya secara manual.

Intinya, sama seperti Anda tidak akan memanggil nomor telepon pada surat untuk "memverifikasi informasi akun Anda" (seperti SSN, dan Kartu Kredit Anda), Anda juga tidak boleh mengklik tautan dalam email, dan mengharapkan layar login atau bentuk apa pun untuk aman mengirim informasi pribadi ke bank Anda. Jika Anda melakukannya, Anda mungkin mendapati diri Anda mengirimkan kredensial Anda kepada penipu, dan tidak pernah menyadarinya.


1. Saya menghilangkan semua spam saya. Saya memiliki nama domain saya sendiri. Saya memberikan setiap kontak alamat email mereka sendiri, dan semuanya masuk ke satu kotak masuk saya. Dengan cara ini, jika Bob mendapat virus di komputernya, dan saya mulai mendapatkan beberapa spam tingkat rendah itu, maka saya dapat memberi tahu Bob untuk mengubah kata sandi emailnya dan mulai menggunakan alamat email baru untuk emailnya kepada saya. Alamat email baru tidak akan mendapatkan spam di dalamnya, dan saya bisa menghapus yang lama, karena hanya Bob yang menggunakannya.

Saya tidak harus pergi memberi tahu bank saya, dan teman-teman saya yang lain, vendor saya, rekan kerja saya, bahwa alamat email saya berubah, karena masing-masing memiliki alamat mereka sendiri. (Saya bahkan tidak perlu memperbarui StackExchange dan Gravater.) Ini bagus untuk saya (tidak ada spam), bagus untuk Bob (dia tahu dia punya "virus atau sesuatu" - kadang-kadang saya bisa bersikap langsung, tetapi orang harus berhati-hati agar tidak salah setelah itu), bagus untuk teman-teman saya yang lain (saya tidak pernah mengeluh tentang berapa banyak email yang saya dapatkan dalam 24 jam terakhir, dan menjelaskan mengapa saya tidak kembali kepada mereka)

25
Bryan Field

Saya pikir Anda semua telah mengabaikan satu detail kecil yang disebutkan dalam dramatisasi di atas, yang sebenarnya sangat mudah untuk diperiksa:

Email spoof tidak berasal dari alamat email yang secara sah milik domain dari mana mereka mengklaim berasal. Bagian dari protokol SMTP termasuk satu set header pesan lengkap bahwa selalu termasuk jalur pengembalian pesan, yang adalah alamat email yang sebenarnya mengirim pesan. Tidak hanya itu, tetapi alamat IP juga memiliki wilayah geografis definitif tempat mereka ditugaskan. Jadi, Anda dapat menangkap perbedaan ini dengan sedikit penggalian.

Ambil contoh, kata dramatisasi.

Disebutkan bahwa email tersebut berasal dari whitehouse.gov. Ini alamat IP-nya:

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

Sekarang, katakanlah nastyhackerz.cn menyelesaikan ke alamat IP di suatu tempat di blok 1.0.32.0-1.0.63.255 (untuk referensi: http://www.nirsoft.net/countryip/cn.html blok pertama dalam daftar). Alamat IP itu akan berada di tajuk pesan lengkap. Yang harus Anda lakukan adalah mengambil IP online untuk melacak geolokasi (Anda dapat menggunakan http://www.geoiptool.com/ misalnya)

IP untuk whitehouse.gov (173.223.0.110) pada saat menulis posting ini geolocates ke Boston, Massachusetts (untuk beberapa alasan sistem pencegahan spam tidak akan membiarkan saya memposting pencarian saya di geoiptool karena poin reputasi, sehingga Anda dapat pergi lakukan pencarian sendiri) yang cukup dekat dengan rumah (District of Columbia)! Anggap saja whitehouse.gov di-host di pusat data yang ada di Boston hanya untuk membuatnya lebih mudah dijelaskan.

Selama IP dan alamat email bahwa email itu sebenarnya dikirim dari tidak cocok dengan IP dan alamat email yang email klaim untuk dikirim dari, itu dapat ditentukan sebagai spoof. Anda hanya perlu melihat di header pesan penuh.


Mari kita lihat tajuk email yang saya kirim dari salah satu domain saya sendiri (dragon-architect.com) ke alamat email pribadi saya:

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!

Itu banyak data acak untuk disaring, tetapi ada dua baris yang kita lihat di sini: jalur kembali dan dari. Karena saya mengirim email ini secara sah kepada diri saya sendiri, keduanya cocok. Jalur balik tidak bisa dipalsukan. Atau jika bisa, sangat sulit untuk melakukan spoof secara efektif dan memerlukan beberapa konfigurasi daemon SMTP yang digunakan untuk mengirim email. Membandingkan jalur balik dan bidang data dari header lengkap adalah salah satu cara yang saya dan rekan kerja tempat saya bekerja dapat mengidentifikasi spoof dan menentukan apakah tiket dukungan perlu dikirimkan.

Jadi, bagaimana jika keduanya cocok, tetapi emailnya tetap palsu? Saya akan membahasnya di bagian selanjutnya ...


Sekarang, seperti yang disebutkan sebelumnya, ada cara lain untuk menentukan tipuan email. Catatan SPF adalah salah satu cara itu, tetapi tidak selalu sempurna. Ambil, misalnya, SPF dari whitehouse.gov, dan bandingkan dengan SPF domain saya sendiri:

[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"

Biasanya, catatan SPF yang baik juga mencakup alamat IP server yang mengirim surat, jadi siapa pun yang membuat catatan SPF untuk whitehouse.gov mungkin tidak mengetahui hal ini. Saya akan menganggap catatan SPF whitehouse.gov terlalu umum untuk menjadi efektif dalam menentukan asal-usul sebenarnya dari setiap pesan yang mengaku berasal dari whitehouse.gov. SPF untuk domain saya sendiri, di sisi lain, yang secara otomatis dihasilkan oleh server yang menghosting domain saya (milik webhost saya), sangat spesifik dan termasuk alamat IP server itu sendiri.

Saya akan mengakui untuk tidak akrab dengan bagaimana catatan SPF diformat dan bagaimana mereka bekerja, tetapi saya sudah cukup belajar tentang pekerjaan saya sehingga saya setidaknya bisa mengidentifikasi catatan SPF generik dan spesifik. Kira itu sesuatu yang saya mungkin harus menggali akhir pekan ketika saya bosan dan ingin beberapa bahan bacaan teknis!

Bagaimanapun, kembali ke jalur di sini. Lihatlah garis yang Diterima. Salah satunya menyatakan sebagai berikut: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Coba tebak? Itu cocok dengan alamat IP dalam catatan SPF domain saya.

Jika IP di SPF tidak cocok dengan IP server yang benar-benar mengirim email, itu indikasi lain bahwa Anda memiliki spoof di tangan Anda. Oleh karena itu, catatan SPF umum seperti "v=spf1 +mx ~all" Tidak akan memotong keamanan mustard. Saya bahkan tidak akan mempercayai email yang berasal dari domain sah yang memiliki SPF umum seperti ini.

Mungkin kita harus mengajukan petisi pada petisi.whitehouse.gov untuk meminta admin keamanan mereka mengunjungi kembali catatan SPF yang mereka buat untuk domain! (Aku nak, aku nak.)

[~ # ~] sunting [~ # ~]

Saya sebenarnya harus [~ # ~] secara besar-besaran [~ # ~] memperbaiki sendiri tentang catatan SPF! Saya membuat beberapa asumsi yang salah dan belajar beberapa hal hari ini setelah bertanya pada rekan kerja yang lebih tahu daripada saya tentang catatan SPF. Jadi, saya akan menggunakan dua SPF untuk whitehouse.gov dan dragon-architect.com dalam koreksi diri saya:

[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"

SPF untuk domain saya sendiri sebenarnya lebih lunak daripada SPF untuk whitehouse.gov (sesuatu yang saya rencanakan untuk dikoreksi malam ini setelah saya menyelesaikan pengeditan ini). Saya akan menjelaskan alasannya:

"v=spf1 +mx ~all" Pada dasarnya mengatakan bahwa email dari whitehouse.gov seharusnya berasal dari nama host yang didefinisikan dalam catatan MX untuk whitehouse.gov, dan email apa pun yang tidak berasal dari nama host itu seharusnya palsu, tetapi apakah mereka Ditandai spoof atau tidak, tergantung pada penerima email.

[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" Mengatakan bahwa email dari dragon-architect.com seharusnya berasal dari alamat IP untuk dragon-architect.com (67.18.28.78), nama host yang ditentukan dalam catatan MX untuk arsitek-naga .com, atau alamat IP dari server yang menghosting dragon-architect.com (70.84.243.130). Setiap email yang tidak berasal dari itu, yah, itu semua pada akhirnya berarti tidak ada saran apakah akan meneruskan atau menolak email.

Jadi, apa daging dan kentang dari catatan SPF? "Semua" di bagian paling akhir. Mengutip rekan kerja ini tentang "semua":

+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.

Sehingga "semua" adalah tempat Anda menentukan seberapa ketat rekaman SPF Anda. Tetapi apakah catatan SPF benar-benar digunakan untuk menentukan spoofiness email adalah sepenuhnya hingga penerima layanan email.

Jadi begitulah. Singkatnya, SPF.


Jadi ya. TL; DR: periksa header lengkap Anda untuk melihat apakah jalur pengembalian dan dari bidang cocok. Kemudian periksa ulang catatan SPF Anda jika ada untuk melihat apakah Anda mendapatkan alamat IP yang cocok.

15
Calyo Delphi

SMTP (Sederhana Protokol Transfer Surat) dinamai itu untuk alasan yang sangat bagus.

SMTP berawal pada 1982 di ARPANET lama, yang dimiliki dan dikendalikan oleh Departemen Pertahanan AS, dan dimaksudkan untuk komunikasi antara orang-orang dengan izin keamanan yang bekerja pada proyek-proyek pemerintah yang umumnya dapat dipercaya untuk tidak menyalahgunakannya. "Keamanan" dari jaringan ini dicapai dengan cukup sederhana dengan menempatkan mesin yang dapat terhubung ke dalam area yang diamankan secara fisik dari berbagai fasilitas, tepat di samping pekerjaan rahasia yang dilakukan oleh fasilitas ini. Akibatnya, sebenarnya mengamankan data yang dikirim di sepanjang jaringan umumnya tidak dipertimbangkan sampai setelah ARPANET dinonaktifkan, dengan lompatan kuantum pertama yang terjadi sekitar tahun 1993 dengan API Pemrograman Jaringan Aman (yang meletakkan dasar-dasar untuk Lapisan Soket Aman, yang sekarang dikenal secara umum. sebagai Transport Layer Security). Sementara sebagian besar protokol (termasuk SMTP/POP/IMAP) sekarang dapat menambahkan TLS untuk saluran komunikasi yang aman, semua ini menyediakan kerahasiaan, dan keaslian server; tidak memberikan keaslian pengirim atau integritas pesan, dan juga tidak memberikan penolakan.

Ada pilihan yang tersedia untuk keamanan e-mail, yang disebut PGP (Privasi Pretty Good; ini adalah lelucon Phil Zimmerman untuk sistem yang tidak bisa dipecahkan oleh komputer di planet ini jika diimplementasikan dengan benar). Ia dapat, dengan berbagai pilihan, menyediakan keempat prinsip dasar keamanan informasi; kerahasiaan, integritas, keaslian, dan non-penolakan (pengirim, yang menandatangani email menggunakan sertifikat mereka, tidak dapat mengklaim bahwa mereka tidak benar-benar mengirimkannya; tidak ada orang lain yang boleh, kecuali sertifikat dikompromikan). Ia menggunakan sistem serupa dari sertifikat kunci publik dan pertukaran kunci aman seperti yang terlihat dalam jabat tangan TLS dua arah, tetapi beberapa detail diubah untuk mencerminkan sifat tidak sinkron dari transportasi email, dan untuk mencerminkan keinginan untuk desentralisasi " web kepercayaan "menghalangi kebutuhan otoritas sertifikat yang dipercaya secara global.

Namun, sistem ini belum benar-benar lepas landas walaupun sudah berusia lebih dari 25 tahun, dan karena itu hanya diperlukan oleh lembaga pemerintah dan perusahaan besar tertentu. Hampir semua penyedia email masih akan dengan senang hati mengirimkan email palsu melalui koneksi aman ke kotak masuk Anda. Dalam banyak kasus, Anda dapat mendorong teman dan orang lain dari siapa Anda ingin menerima email untuk mengadopsi skema PGP, dan apa pun yang tidak masuk secara sah masuk ke "karantina", tetapi ini sebenarnya hanyalah level lain dari "penyaringan spam" ", dan saya tidak tahu satu penyedia email publik yang bisa Anda perintahkan untuk menolak email tanpa tanda tangan digital secara langsung; server email harus berada di bawah kendali Anda, seperti server Exchange perusahaan.

12
KeithS

tl; dr

  • Apakah Paypal memanfaatkan masalah keamanan di sini? ... Bagaimana Paypal bisa menipu email dengan begitu mudah?

Secara teknis, tidak ada yang bukan masalah keamanan, email tidak aman untuk memulai. Mereka menggunakan salah satu header SMTP berikut yang terletak di header pesan (bukan header amplop)

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

Ada perbedaan konseptual antara "remailing" dan "spoofing". Klien email harus menampilkan perbedaan ini. Klien Gmail tidak melakukan ini.

  • Paypal tidak spoofing, mereka menggunakan salah satu dari header SMTP ini: Resent-From, Resent-Pengirim, atau Pengirim

  • Sangat mudah untuk menipu domain ... bahkan dengan kontrol SPF diaktifkan

  • MUA (klien email) harus menampilkan Display From, status verifikasi SPF, DKIM, dan DMARC-nya.

  • Header Resent- * harus digunakan dengan cara yang memperjelas pesan ini "remailed".

  • Secara umum solusi terbaik adalah menggunakan DKIM + DMARC, atau SPF + DMARC dan MUA yang menampilkan hasil verifikasi.


Beberapa latar belakang

Secara umum, ada dua "dari" alamat dan dua "ke" alamat di setiap pesan SMTP. Satu dikenal sebagai Amplop RFC2821, yang lainnya adalah Pesan RFC2822. Mereka melayani tujuan yang berbeda

Amplop: (RFC2821)

  • Amplop adalah metadata yang tidak muncul di header SMTP. Hilang saat pesan masuk ke MTA berikutnya.

  • RCPT From: adalah tempat NDR akan pergi. Jika pesan datang dari Postmaster atau layanan remailer, ini biasanya <> atau [email protected]. Sangat menarik untuk melihat bahwa tenaga penjualan menggunakan ini mirip dengan constantContact sebagai kunci dalam database seperti [email protected] untuk melihat apakah pesan terpental.

  • RCPT TO: adalah siapa sebenarnya pesan yang dikirim. Ini digunakan untuk pengguna "ke" dan "bcc". Ini biasanya tidak memengaruhi "tampilan alamat" di klien email, tetapi ada beberapa kesempatan MTA akan menampilkan bidang ini (jika header RFC2822 rusak).

Pesan (RFC2822)

  • Bagian pesan dimulai ketika perintah data dikeluarkan.

  • Informasi ini termasuk header SMTP yang Anda kenal, pesan, dan lampirannya. Bayangkan semua data ini disalin dan ditempelkan dari setiap MTA ke yang berikutnya, berturut-turut sampai pesan mencapai kotak masuk.

  • Merupakan kebiasaan bagi setiap MTA untuk mengawali copy dan paste yang disebutkan di atas dengan informasi tentang MTA (IP sumber, IP tujuan, dll). Itu juga menempel rincian cek SPF.

  • Ini adalah Display From ditempatkan. Ini penting. Spoofer dapat memodifikasi ini.

  • Mail From: di dalam amplop dibuang dan biasanya ditempatkan di sini sebagai return-path: alamat untuk NDR

Jadi, bagaimana kami mencegah orang memodifikasi Tampilan Dari? Nah DMARC mendefinisikan kembali makna kedua untuk catatan SPF. Ia mengakui bahwa ada perbedaan antara Envelope From dan Display From, dan ada alasan yang sah bagi mereka untuk tidak cocok. Karena SPF pada awalnya didefinisikan hanya peduli dengan Envelope From, jika Display From berbeda, DMARC akan memerlukan pemeriksaan DNS kedua untuk melihat apakah pesan tersebut dibolehkan dari alamat IP tersebut.

Untuk memungkinkan skenario penerusan, DMARC juga memungkinkan Display From untuk ditandatangani secara kriptografi oleh DKIM, dan jika ada spammer atau phisher yang tidak sah mencoba untuk mengasumsikan identitas itu, enkripsi akan gagal.

Apa itu DKIM? DKIM adalah teknologi enkripsi ringan yang menandatangani data yang berada dalam pesan. jika Anda pernah menerima pesan dari Gmail, Yahoo, atau AOL, maka pesan Anda ditandatangani oleh DKIM. Intinya adalah bahwa tidak ada yang akan tahu Anda menggunakan enkripsi dan penandatanganan DKIM kecuali Anda melihat di header. Itu transparan.

DKIM biasanya dapat bertahan diteruskan, dan ditransfer ke MTA yang berbeda. Sesuatu yang tidak bisa dilakukan SPF. Administrator email dapat menggunakan ini untuk keuntungan kami untuk mencegah spoofing.


Masalahnya terletak pada SPF hanya memeriksa amplop RFC2821, dan bukan Tampilan Dari. Karena kebanyakan orang peduli tentang Tampilan Dari yang ditampilkan dalam pesan email, dan bukan NDR jalur balik, kami memerlukan solusi untuk melindungi dan mengamankan bagian ini.

Di sinilah DMARC masuk. DMARC memungkinkan Anda untuk menggunakan kombinasi pemeriksaan SPF yang dimodifikasi atau DKIM untuk memverifikasi Display From. DKIM memungkinkan Anda untuk secara kriptografis menandatangani Tampilan Dari RFC2822 setiap kali SPF tidak cocok dengan Layar Dari (yang sering terjadi).


Apakah spoofing Display Dari masalah keamanan?

Ya, phishing meskipun email adalah masalah keamanan penting yang dilihat banyak vendor. Yaitu Paypal, AOL, Google, Yahoo dan perusahaan lain yang menerapkan DMARC untuk memperbaiki masalah phishing ini.

Mengapa masih mungkin memalsukan tajuk "Dari:" di surel?

Beberapa administrator server belum menerapkan teknologi terbaru untuk mencegah hal semacam ini terjadi. Salah satu hal utama yang mencegah adopsi teknologi ini adalah "layanan penerusan email" seperti perangkat lunak milis, penerusan otomatis, atau remailer alumni sekolah (.forwarder). Yaitu:

  1. Baik SPF atau DKIM tidak dikonfigurasi.

  2. Kebijakan DMARC tidak diatur.

  3. Klien email tidak menampilkan hasil verifikasi Tampilan Dari dan bidang Pengirim- * atau Pengirim.

Apa yang sedang dilakukan Paypal?

Paypal menggunakan tajuk Pengirim untuk menunjukkan bahwa ia dikirim kembali. Ini adalah penggunaan yang benar dan dimaksudkan dari tajuk ini.

Apa yang salah dengan GMail?

Gmail tidak menjelaskan bahwa header Pengirim digunakan, mereka tidak memvalidasi alamat Display From dengan cara yang ramah pengguna, dan tidak membedakan antara tampilan dari dan pengirim.

5