Ide bagus? Menolak email masuk dengan akhiran domain kami sendiri? (karena mereka pasti palsu)

33

Saya punya pertanyaan tentang Exchange Server kami: Apakah menurut Anda adalah ide yang baik untuk menolak email eksternal masuk yang memiliki domain sendiri di akhir?

Suka dari eMail eksternal [email protected]?

Karena jika itu berasal dari pengirim nyata di perusahaan kami, email tidak akan pernah datang dari luar?

Jika ya, apa cara terbaik untuk melakukan ini?

security email-server exchange-2013 Steffen Maier
sumber
3
Apakah Anda memiliki solusi penyaringan spam apa pun saat ini?
ewwhite
14
Anda harus memeriksa ulang bahwa Anda tidak memiliki vendor aplikasi web yang mencoba mengirim dari domain Anda sendiri. Seperti jika Anda memiliki sistem penggajian yang mungkin mengirim e-mail ke staf Anda dari "[email protected]". Juga periksa apakah pemasaran atau SDM mungkin menggunakan layanan surat massal eksternal dan mereka ingin staf mendapatkan pesan-pesan itu. Biasanya pesan-pesan itu memiliki pengirim atau setidaknya menjawab-ke alamat seseorang dalam pemasaran atau SDM. Dalam situasi itu, Anda biasanya dapat menempatkan server email layanan pada daftar izin dan masih memblokir masuk domain Anda sendiri (itulah yang kami lakukan).
Todd Wilcox
6
@NeilMcGuigan Apa masalahnya? Surat masih harus berasal dari server surat internal? Itu tidak akan datang dari luar jaringan hanya karena dia tidak hadir secara fisik.
Matt
@Matt gotya, brainfart
Neil McGuigan
1
Jika Anda memiliki pemberitahuan email otomatis yang datang dari salah satu server Anda, misalnya, pemberitahuan pekerjaan cron gagal, atau upaya pelanggaran dari IDS, atau monitor penggunaan sumber daya, dan mereka dikonfigurasi sehingga alamat Dari mereka adalah dengan nama domain Anda. Anda harus berhati-hati untuk merutekan email tersebut melalui server surat internal Anda, atau memasukkan daftar putih ke server tersebut sebagai pengirim yang diizinkan.
Lie Ryan

Jawaban:

53

Ya, jika Anda tahu bahwa email untuk domain Anda seharusnya hanya berasal dari server Anda sendiri, maka Anda harus memblokir email apa pun untuk domain yang berasal dari server yang berbeda. Bahkan jika klien email pengirim ada di host lain, mereka harus masuk ke server Anda (atau server email apa pun yang Anda gunakan) untuk mengirim email.

Mengambil langkah lebih jauh, Anda dapat mengkonfigurasi server Anda untuk memeriksa catatan SPF. Ini adalah jumlah host yang mencegah aktivitas email semacam itu. Catatan SPF adalah catatan DNS, catatan TXT, yang memberikan aturan tentang server mana yang diizinkan mengirim email untuk domain Anda. Cara mengaktifkan pemeriksaan catatan SPF akan tergantung pada layanan email Anda, dan akan berada di luar jangkauan apa yang akan dibahas di sini. Untungnya, sebagian besar lingkungan dan perangkat lunak hosting akan memiliki dokumentasi untuk bekerja dengan catatan SPF. Anda mungkin ingin mempelajari lebih lanjut tentang SPF secara umum. Inilah artikel Wikipedia: https://en.wikipedia.org/wiki/Sender_Policy_Framework

DKing
sumber
3
@Kurtovic server email yang dikonfigurasi dengan baik harus memantulkan email yang ditolaknya, sehingga pengirim akan diberi tahu.
Calimo
8
@Calimo Tidak ketika menolak email karena dianggap spam. Melakukan hal itu hanya akan memungkinkan spammer untuk terus mencoba sampai dia mengetahui apa yang diperbolehkan dan tidak dibolehkan oleh algoritma Anda.
Jon Bentley
27
@Calimo - tidak. accept-and-bounce adalah hal terburuk yang dapat dilakukan, Anda berkontribusi untuk menyebarkan kembali spam dan AKAN masuk daftar hitam dengan sangat cepat. tolak saja surat yang tidak diinginkan - berurusan dengan itu adalah masalah tuan rumah pengirim . Jika Anda tidak dapat melakukannya, terima, periksa, dan buang jika ada spam atau malware. jangan pernah menerima dan bangkit.
cas
2
@cas: Ada alternatif ketiga: tolak pada waktu penerimaan SMTP. Ini meninggalkan beban menghasilkan respons kesalahan pada server SMTP pengirim, jika ingin melakukannya, dan dengan demikian memungkinkan banyak pengirim yang sah untuk melihat apakah email mereka ditolak sambil menjamin bahwa Anda tidak akan pernah menghasilkan spam sendiri.
R ..
2
@R .. saya pikir Anda akan menemukan bahwa itu bukan alternatif ketiga, ini adalah parafrase dari apa yang saya katakan "tolak saja surat yang tidak diinginkan - berurusan dengan itu adalah masalah tuan rumah pengirim."
cas
31

Sudah ada standar untuk melakukan ini. Itu disebut DMARC . Anda menerapkannya dengan penandatanganan DKIM (yang merupakan ide bagus untuk menerapkannya).

Ikhtisar tingkat tinggi adalah Anda menandatangani setiap email yang meninggalkan domain Anda dengan header DKIM (yang merupakan praktik yang baik). Kemudian Anda mengkonfigurasi DMARC untuk menolak setiap email yang mengenai server email Anda, dari domain yang Anda miliki, yang tidak ditandatangani dengan header DKIM yang valid.

Ini berarti Anda masih dapat memiliki layanan eksternal mengirim email ke domain Anda (seperti perangkat lunak helpdesk yang di-host, dll), tetapi dapat memblokir upaya phishing tombak.

Hal hebat lainnya tentang DMARC adalah Anda mendapatkan laporan kegagalan yang dikirim, sehingga Anda dapat mengelola penanganan pengecualian sesuai kebutuhan.

Sisi buruknya adalah Anda perlu memastikan bahwa Anda telah menyelesaikan semuanya dengan seksama sebelumnya atau Anda mungkin mulai menjatuhkan email yang sah.

Mark Henderson
sumber
3
Sangat disarankan untuk menerapkan SPF dan DKIM sebelum menguji DMARC.
Todd Wilcox
Bagaimana DMARC dapat bekerja dengan email berasal dari server yang berbeda dari milik Anda, seperti dengan layanan eksternal, karena itu tidak akan ditandatangani oleh server Anda?
jpaugh
1
@ jpa, Anda menambahkan kunci publik server lain ke catatan DMARC Anda di DNS Anda. Mereka akan dapat memberi Anda catatan untuk ditambahkan.
Mark Henderson
Saya memberi +1 jawaban ini karena secara teknis benar - untuk itulah DMARC diperuntukkan, dan untuk apa DMARC - tetapi DMARC adalah ide yang sangat buruk jika Anda ingin bekerja sama dengan hal-hal seperti milis, karena melanggar RFC dan umumnya berperilaku buruk.
MadHatter mendukung Monica
11

Blok semacam itu kemungkinan akan mengurangi spam dan kemungkinan membuat rekayasa sosial lebih sulit tetapi mungkin juga memblokir email yang sah. Contohnya termasuk layanan penerusan surat, milis, pengguna dengan klien surat yang tidak terkonfigurasi, aplikasi web yang mengirim surat langsung dari hosting tanpa melibatkan server surat utama Anda dan sebagainya.

Dkim dapat mengurangi ini sampai batas tertentu dengan menyediakan cara untuk mengidentifikasi pesan yang dikirim dari jaringan Anda, di-loop melalui milis atau forwarder dan kemudian diterima di email Anda tetapi itu bukan obat yang sempurna, beberapa milis akan memecah tanda tangan dkim dan Anda masih memiliki masalah melacak semua titik asal surat yang sah dan memastikan mereka pergi melalui penandatangan dkim.

Tapak dengan hati-hati, terutama jika menerapkan ini pada domain yang ada.

Peter Green
sumber
3

Mungkin, tetapi ada beberapa kasus yang perlu Anda pertimbangkan sebelum Anda melakukan perubahan seperti itu.

1) Apakah ada orang di perusahaan Anda yang menggunakan layanan eksternal apa pun (misalnya Survey Monkey, Constant Contact, dll.) Untuk mengirimkan email yang tampaknya "dari" domain Anda? Bahkan jika mereka tidak melakukannya hari ini, mungkinkah mereka melakukannya di masa depan?

2) Apakah ada alamat luar yang meneruskan ke pengguna Anda? Misalnya, anggap akun gmail "[email protected]" meneruskan ke "[email protected]", dan pengguna Anda "[email protected]" mengirim ke "[email protected]". Dalam hal ini, pesan akan datang dari "luar", tetapi dengan "@ mycompany.com" Dari: alamat.

3) Apakah ada pengguna Anda yang berlangganan daftar distribusi eksternal yang mempertahankan alamat "Dari:" asli pada pesan ke daftar? Misalnya, jika Bob berlangganan "[email protected]" dan mengirim pesan, ia akan menerima pesan masuk yang terlihat seperti: Dari: [email protected] Ke: [email protected]. com Pengirim:

Jika server Anda secara naif melihat header "Dari:" (bukan "Pengirim:"), ia mungkin menolak pesan ini karena Anda menerimanya dari luar.

Karena semua hal di atas, memiliki kebijakan selimut "... dari pengirim nyata di perusahaan kami, email tidak akan pernah datang dari luar" tidak selalu layak.

David Gelhar
sumber
2

Anda dapat melakukan ini di PowerShell dengan memperbarui izin Receive Connector Anda untuk mengecualikan pengguna Anonim dari mengirim sebagai pengirim domain otoritatif:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Namun masalah muncul ketika Anda memiliki server aplikasi jarak jauh yang perlu mengirim email status kepada Anda, karena ini umumnya menggunakan nama domain Anda di alamat Dari mereka. Dimungkinkan untuk membuat Konektor Penerimaan tambahan untuk alamat IP spesifik mereka sehingga Anda tidak mengecualikannya secara tidak sengaja.

Neil
sumber
1

GMail memiliki pengaturan di mana ia memungkinkan Anda untuk mengirim email dengan domain non-GMail asalkan alamat email yang pertama diverifikasi. Keputusan Anda akan memblokir email-email itu.

Apakah Anda memiliki pengguna yang mungkin menggunakan fitur GMail ini dan apakah masuk akal untuk melayani mereka sangat tergantung pada perilaku di perusahaan Anda.

Kristen
sumber
-1

SPF tidak akan menyembuhkan ini karena amplop tersebut dapat memiliki pass SPF yang tepat (yaitu spammer menggunakan server yang dikompromikan) sementara mereka akan memalsukan email di dalam amplop. Yang Anda butuhkan adalah blok pada pesan email domain Anda sendiri yang memiliki server email asal pada amplop yang tidak dapat Anda terima.

Jim
sumber
"Yang Anda butuhkan adalah blok pada pesan email domain Anda sendiri yang memiliki server email asal di amplop yang tidak dapat Anda terima" - itulah yang Anda lakukan dengan SPF, buat daftar server email asli yang berasal dari domain Anda.
Diambil