چگونه یک ایمیل جعلی بررسی SPF را رد کرد و در صندوق ورودی من PlatoBlockchain Data Intelligence قرار گرفت. جستجوی عمودی Ai.

چگونه یک ایمیل جعلی از بررسی SPF عبور کرد و در صندوق ورودی من فرود آمد

اگر اجازه دهید میلیاردها آدرس IP به عنوان دامنه شما ارسال شود، چارچوب خط‌مشی فرستنده نمی‌تواند از هرزنامه و فیشینگ جلوگیری کند.

بیست سال پیش، پل ویکسی یک درخواست برای نظرات منتشر کرد رد ایمیل از که به تشویق جامعه اینترنتی کمک کرد تا راه جدیدی برای مبارزه با هرزنامه ها ایجاد کند چارچوب خط مشی فرستنده (SPF). مسئله در آن زمان، مانند اکنون، این بود که پروتکل انتقال ایمیل ساده (SMTP)، که برای ارسال ایمیل در اینترنت استفاده می شود، هیچ راهی برای شناسایی دامنه های فرستنده جعلی ارائه نمی دهد.  

با این حال، هنگام استفاده از SPF، صاحبان دامنه می توانند رکوردهای سیستم نام دامنه (DNS) را منتشر کنند که آدرس های IP مجاز برای استفاده از نام دامنه خود را برای ارسال ایمیل تعریف می کند. در انتهای دریافت کننده، یک سرور ایمیل می تواند سوابق SPF را پرس و جو کند ظاهر دامنه فرستنده برای بررسی اینکه آیا آدرس IP فرستنده مجاز به ارسال ایمیل از طرف آن دامنه است. 

ایمیل SMTP و نمای کلی SPF 

خوانندگانی که با مکانیسم‌های ارسال پیام SMTP و نحوه تعامل SPF با آن‌ها آشنا هستند، ممکن است ترجیح دهند از این بخش صرف‌نظر کنند، هرچند که بسیار کوتاه است. 

تصور کنید که آلیس در example.com مایل است یک پیام ایمیل به باب بفرستد مثال.org. بدون SPF، سرورهای ایمیل آلیس و باب در یک مکالمه SMTP چیزی شبیه به زیر درگیر می شوند، که با استفاده از HELO به جای EHLO ساده شده است، اما نه به روشی که ساختارهای اصلی را به طور قابل توجهی تغییر دهد: 

به این ترتیب ارسال و دریافت ایمیل اینترنتی (SMTP) رخ داده است از ابتدای 1980s، اما حداقل با استانداردهای اینترنت امروزی یک مشکل اساسی دارد. در نمودار بالا، چاد در example.net می تواند به همین راحتی به مثال.org سرور SMTP، دقیقاً در همان مکالمه SMTP شرکت کنید و ظاهراً از آلیس یک پیام ایمیل دریافت کنید example.com تحویل باب در مثال.org. بدتر از آن، هیچ چیز نشان دهنده فریب باب نخواهد بود، به جز شاید آدرس های IP که در کنار نام میزبان در سرصفحه پیام های تشخیصی ثبت شده باشد (در اینجا نشان داده نشده است)، اما بررسی این موارد برای افراد غیر متخصص آسان نیست و بسته به برنامه مشتری ایمیل شما ، اغلب حتی دسترسی به آنها دشوار است. 

اگرچه در روزهای اولیه ارسال هرزنامه‌های ایمیل مورد سوء استفاده قرار نگرفت، با تبدیل شدن هرزنامه‌های انبوه به یک مدل کسب‌وکار جاافتاده، گرچه به شدت مورد تحقیر قرار گرفت، چنین تکنیک‌های جعل ایمیل به طور گسترده‌ای برای بهبود شانس خواندن پیام‌های هرزنامه و حتی اقدام بر اساس آن مورد استفاده قرار گرفتند. 

بازگشت به چاد فرضی در example.net ارسال آن پیام «از طرف» آلیس... این شامل دو سطح جعل هویت (یا جعل) است که در آن بسیاری از افراد اکنون احساس می‌کنند که می‌توان یا باید بررسی‌های فنی خودکار برای شناسایی و مسدود کردن چنین پیام‌های ایمیل جعلی انجام شود. اولی در سطح پاکت SMTP و دومی در سطح سرصفحه پیام است. SPF چک هایی را در سطح پاکت SMTP و پروتکل های بعدی ضد جعل و احراز هویت پیام ارائه می کند. پسوند dkim و DMARC ارائه چک در سطح سرصفحه پیام. 

آیا SPF کار می کند؟ 

به گفته یکی مطالعه منتشر شده در سال 2022، حدود 32 درصد از 1.5 میلیارد دامنه مورد بررسی دارای سوابق SPF بودند. از این تعداد، 7.7٪ دارای نحو نامعتبر بودند و 1٪ از رکورد PTR منسوخ استفاده می کردند، که آدرس های IP را به نام دامنه ها نشان می دهد. جذب SPF در واقع کند و ناقص بوده است، که ممکن است به سوال دیگری منجر شود: چند دامنه دارای رکوردهای SPF بیش از حد مجاز هستند؟  

تحقیقات اخیر یافت شده است 264 سازمان به تنهایی در استرالیا دارای آدرس های IP قابل بهره برداری در سوابق SPF خود هستند و بنابراین ممکن است ناخواسته زمینه را برای کمپین های اسپم و فیشینگ در مقیاس بزرگ فراهم کنند. در حالی که به آنچه که آن تحقیق نشان داد مربوط نیست، اخیراً براش شخصی خود را با ایمیل های بالقوه خطرناکی داشتم که از سوابق SPF پیکربندی نادرست استفاده می کردند. 

ایمیل جعلی در صندوق ورودی من 

اخیراً ایمیلی دریافت کردم که مدعی بود از طرف شرکت بیمه فرانسوی Prudence Créole، اما همه را داشت علائم اسپم و جعل: 

 چگونه یک ایمیل جعلی بررسی SPF را رد کرد و در صندوق ورودی من PlatoBlockchain Data Intelligence قرار گرفت. جستجوی عمودی Ai.

در حالی که می‌دانم جعل هدر پیام آدرس From: یک ایمیل بی‌اهمیت است، کنجکاوی من زمانی برانگیخته شد که سرصفحه‌های کامل ایمیل را بررسی کردم و متوجه شدم که دامنه موجود در پاکت SMTP MAIL FROM: آدرس reply@prudencecreole.com بررسی SPF را پاس کرده بود: 

چگونه یک ایمیل جعلی بررسی SPF را رد کرد و در صندوق ورودی من PlatoBlockchain Data Intelligence قرار گرفت. جستجوی عمودی Ai.

بنابراین من رکورد SPF دامنه را جستجو کردم prudencecreole.com: 

چگونه یک ایمیل جعلی بررسی SPF را رد کرد و در صندوق ورودی من PlatoBlockchain Data Intelligence قرار گرفت. جستجوی عمودی Ai.

این یک بلوک عظیم از آدرس های IPv4 است! 178.33.104.0/2 شامل 25 درصد از فضای آدرس IPv4 است که از 128.0.0.0 به 191.255.255.255. بیش از یک میلیارد آدرس IP، فرستنده های تایید شده برای نام دامنه Prudence Creole هستند - بهشت ​​هرزنامه ها. 

فقط برای اینکه مطمئن شوم خودم را مسخره نمی کنم، یک سرور ایمیل در خانه راه اندازی کردم، یک آدرس IP تصادفی اما واجد شرایط توسط ارائه دهنده خدمات اینترنتی به من اختصاص داد و برای خودم ایمیل جعلی فرستادم. prudencecreole.com:  چگونه یک ایمیل جعلی بررسی SPF را رد کرد و در صندوق ورودی من PlatoBlockchain Data Intelligence قرار گرفت. جستجوی عمودی Ai.

انجام شد! 

برای تکمیل همه چیز، من رکورد SPF یک دامنه را از یک ایمیل هرزنامه دیگری در صندوق ورودی خود که در حال جعل بود بررسی کردم. wildvoyger.com: 

چگونه یک ایمیل جعلی بررسی SPF را رد کرد و در صندوق ورودی من PlatoBlockchain Data Intelligence قرار گرفت. جستجوی عمودی Ai.

ببینید، 0.0.0.0/0 بلوک به کل فضای آدرس IPv4، متشکل از بیش از چهار میلیارد آدرس، اجازه می دهد تا در حالی که خود را به عنوان Wild Voyager نشان می دهد، از بررسی SPF عبور کند. 

پس از این آزمایش، من به Prudence Cr اطلاع دادمéole و Wild Voyager در مورد رکوردهای SPF پیکربندی نادرست خود. Prudence Créole رکوردهای SPF خود را قبل از انتشار این مقاله به روز کرد. 

بازتاب ها و درس های آموخته شده 

ایجاد یک رکورد SPF برای دامنه شما به هیچ وجه در برابر تلاش‌های جعل‌های هرزنامه‌نویسان به هیچ وجه منجر به مرگ نمی‌شود. با این حال، اگر به طور ایمن پیکربندی شود، استفاده از SPF می‌تواند بسیاری از تلاش‌ها مانند تلاش‌هایی را که به صندوق ورودی من وارد می‌شوند، ناکام بگذارد. شاید مهم‌ترین مانعی که در راه استفاده فوری، گسترده‌تر و کاربرد دقیق‌تر SPF وجود دارد، تحویل ایمیل است. برای انجام بازی SPF به دو نفر نیاز است زیرا هم فرستنده و هم گیرنده باید سیاست های امنیتی ایمیل خود را هماهنگ کنند تا در صورتی که ایمیل ها به دلیل قوانین بسیار سختگیرانه اعمال شده توسط هر دو طرف تحویل داده نشوند. 

با این حال، با توجه به خطرات و آسیب های احتمالی ناشی از هرزنامه ها که دامنه شما را جعل می کنند، توصیه های زیر را می توان در صورت لزوم اعمال کرد: 

  • یک رکورد SPF برای همه هویت‌های HELO/EHLO خود ایجاد کنید در صورتی که تأییدکننده‌های SPF از توصیه در RFC 7208 برای بررسی اینها 
  • بهتر است از تمام مکانیزم با "-" or "~" مقدماتی به جای "?" واجد شرایط، به عنوان دومی به طور موثر به هر کسی اجازه می دهد دامنه شما را جعل کند 
  • یک قانون "رها کردن همه چیز" را تنظیم کنید (v=spf1 -all) برای هر دامنه و زیر دامنه ای که مالک آن هستید که هرگز نباید ایمیل (مسیریابی به اینترنت) ایجاد کند یا در قسمت نام دامنه دستورات HELO/EHLO یا MAIL FROM: ظاهر شود. 
  • به عنوان یک راهنما، مطمئن شوید که رکوردهای SPF شما کوچک هستند، ترجیحاً حداکثر تا 512 بایت، تا از نادیده گرفته شدن بی‌صدا توسط برخی از تأییدکننده‌های SPF جلوگیری کنید. 
  • مطمئن شوید که فقط یک مجموعه محدود و قابل اعتماد از آدرس های IP را در سوابق SPF خود مجاز کرده اید 

استفاده گسترده از SMTP برای ارسال ایمیل، فرهنگ فناوری اطلاعات را ایجاد کرده است که به جای ایمن و حفظ حریم خصوصی، بر انتقال ایمیل ها به طور قابل اعتماد و کارآمد متمرکز شده است. تطبیق مجدد با یک فرهنگ متمرکز بر امنیت ممکن است فرآیندی کند باشد، اما باید با توجه به کسب سود واضح در برابر یکی از آسیب‌های اینترنت – هرزنامه – انجام شود. 

تمبر زمان:

بیشتر از ما امنیت زندگی می کنیم