چرا جعل ایمیل کار می کند و چگونه می توان در برابر آن محافظت کرد

گاهی اوقات مشاهده کردن ایمیل های فیشینگ فقط با بررسی زمینه "از" آسان است. با این حال ، همیشه اینطور نیست ساخت نامه الکترونیکی جعلی قابل تشخیص از یک نامه واقعی ممکن است. اگر یک مهاجم می داند چگونه چنین کاری را انجام دهد ، سازمان هدفمند واقعاً دچار مشکل می شود. اکثر مردم قبل از کلیک کردن روی پیوند یا پرونده مخربی که در نامه الکترونیکی به ظاهر از طرف رئیس یا مشتری ارشدشان گرفته شده اند ، فکر دیگری نخواهند کرد – و سرزنش کردن آنها دشوار است ، به خصوص اگر راهی برای گفتن ایمیل وجود نداشته باشد. -mail جعل شد.

اما چرا در وهله اول می توان نامه الکترونیکی کاملی را جعل کرد؟ صحبت های اندرو کنستانتینف در مورد تأیید هویت نامه الکترونیکی برای آزمایش کنندگان نفوذ ، در سی و ششمین کنگره ارتباطات آشوب ، به این سؤال پاسخ می دهد و بینشی در مورد اثربخشی محافظت درمورد جعل ایمیل ارسال می کند.

مسئله 1: نامه الکترونیکی باید جریان یابد [19659004] پست الکترونیکی روشی اساسی برای ارتباط با دنیای مدرن است و هر سازمانی در عملیات روزانه خود به ایمیل بسیار متکی است. اگرچه وقتی همه چیز به آرامش می رسد ، در مورد فناوری خیلی فکر نمی کنیم ، اگر همه نامه های الکترونیکی ناگهانی از بین بروند ، می توانید مطمئن باشید همه متوجه خواهند شد. بنابراین ، قابلیت اطمینان به طور کلی اولویت اصلی هر مدیر سرور پست الکترونیکی است. نامه الکترونیکی صرفنظر از آنچه باید ارسال شود و به آنها تحویل داده شود.

منظور اینجاست که سرور پست الکترونیکی هر سازمان باید تا حد ممکن با همه جای دنیا سازگار باشد. مسئله در اینجا نهفته است: استانداردهای نامه الکترونیکی خیلی قدیمی نیستند.

مسئله 2: پروتکل نامه الکترونیکی و بدون تأیید اعتبار

پروتکل اصلی که هم برای مشتری به سرور و هم از سرور به سرور استفاده می شود. ارتباطات پستی SMTP است. این پروتکل برای اولین بار در سال 1982 معرفی شد و آخرین بار در سال 2008 – بیش از یک دهه پیش – به روز شد. و مانند بسیاری از معیارهای باستانی دیگر ، SMTP یک کابوس امنیتی است.

ابتدا اجازه دهید نگاهی به پیام الکترونیکی معمولی شما بیندازیم:

• پاکت SMTP. این قسمت برای ارتباطات سرور به سرور استفاده می شود و هرگز در مشتری های نامه الکترونیکی نشان داده نمی شود. آدرس ایمیل فرستنده و گیرنده را مشخص می کند.
• مشتری های پست الکترونیکی این قسمت را نشان می دهند. این قسمت هایی است که می توانید زمینه های آشنایی "از" ، "به" ، "تاریخ" و "موضوع" را که برای هر نامه الکترونیکی مشاهده می کنید ، پیدا کنید.
• بدن پیام. متن پست الکترونیکی و سایر مطالب.

پیام الکترونیکی چیست. منبع تصویر

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

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

به یک هکر حرفه ای نیاز نیست تا اتاق زیادی را برای مشکلات خود در اینجا ببیند.

پروتکل -mail به هیچ وجه امکان اطمینان از ارسال نامه الکترونیکی از فرستنده نشان داده شده را فراهم نمی کند

مشکل 3: جعلی بودن ، جعلی بودن – باید آنها را تماشا کنید

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

از یک طرف ، شما مطمئناً می خواهید مطمئن باشید که هر نامه الکترونیکی که دریافت می کنید در واقع از آدرس مشخص شده ارسال شده است. از طرف دیگر ، شما احتمالاً می خواهید از ارسال نامه الکترونیکی دیگران که به نظر می رسد از آدرس شما هستند ، جلوگیری کنید. متأسفانه استاندارد نمی تواند به هیچکدام از اینها کمک کند.

جای تعجب نیست که پروتکل SMTP آنقدر مورد سوء استفاده قرار گرفت که مردم برای رفع نقص های ذکر شده در ابتدا اقدام به ابداع فن آوری های جدید کردند.

رفع تلاش 1: چارچوب سیاست ارسال کننده ( SPF)

ایده موجود در چارچوب خط مشی فرستنده بسیار ساده است: سرور دریافت کننده می تواند بررسی کند که آیا آدرس سرور ارسال کننده پست الکترونیکی با آدرس سرور ایمیل واقعی مرتبط است یا خیر. دامنه.

متأسفانه ، این آسان تر از آنچه گفته شده است انجام می شود. استاندارد SMTP هيچ ابزاری براي انجام چك چك ندارد ، بنابراين هر روش احراز هويت بايد در بالاي موارد موجود اضافه شود. رسیدن به چنین فناوری به مرحله تبدیل شدن به "استاندارد پیشنهادی" یک دهه طول کشید. امروزه تنها حدود 55٪ از 1 میلیون سرور برتر از SPF استفاده می كنند و بیشتر آنها از سیاستهای كاملاً آرام استفاده می كنند.

SPF در اینجا با مشکلات دیگری نیز روبرو است ، مانند معماری کثیفی که نادرست ترسیم آن را آسان می کند ، روش های خاصی برای دور زدن آن. با استفاده از سایر سرورهای میزبان در همان آدرس و غیره. اما نقص مهلک SPF این است که فقط آدرس مندرج در پاکت SMTP را چک می کند و زمینه "از" در هدر را نادیده می گیرد – همان چیزی که کاربر در واقع می بیند.

نتیجه:

• SPF به بررسی اینکه آیا نامه الکترونیکی از سرور اصلی وارد شده است کمک می کند.
• آدرس قابل مشاهده برای کاربران هنوز هم می تواند جعلی باشد.

رفع تلاش 2: نامه شناسایی شده DomainKeys (DKIM)

DomainKeys شناسایی شده ایمیل با مشکل متفاوت می شود. : DKIM به طور رمزنگاری هدر پیام و بخشی از بدنه پیام را با استفاده از یک کلید خصوصی امضا می کند ، که امضای آن را می توان با استفاده از یک کلید عمومی که در سیستم نام دامنه منتشر شده است تأیید کرد.

با این وجود شایان ذکر است که DKIM نیست. قرار است کل پیام را رمزگذاری کند. در عوض ، یک ضمیمه امضا شده رمزنگاری به آن اضافه می کند. این یک مشکل است. قسمت رمزنگاری اصلاح آن دشوار است ، اما حذف امضا به طور کامل و تهیه پیام جعلی آسان است – و نتایج غیر قابل کشف است.

DKIM اجرای آن دشوار است زیرا شامل صدور و مدیریت کلیدهای رمزنگاری است. همچنین ، DKIM با پیکربندی اشتباه می تواند یک مهاجم را قادر سازد تا ضمن امتحان کردن کاملاً سرصفحه و بدن ، امضای اصلی DKIM را در یک پیام حفظ کند.

اجرای آن دشوار است زیرا شامل مدیریت کلید رمزنگاری است.

جعل آهنگ ها می توانند ضمن جعل نامه ای به نام شما ، نامه را به سادگی حذف کنند.

برخی از تنظیمات غلط خاص منجر به نتیجه می شوند. پیام های جعلی حاوی امضاهای اصلی DKIM.

رفع تلاش 3: تأیید اعتبار ، گزارش دهی و سازگاری پیام پیام دامنه مبتنی بر دامنه [DMARC]

علیرغم نام بسیار طولانی ، پروتکل تأیید پیام ، دامنه مبتنی بر دامنه در واقع ساده تر است. درک از SPF یا DKIM. این واقعاً پسوندی از این دو است که بیشترین چشم پوشی آنها را برطرف می کند.

اول ، DMARC به سرپرست دامنه کمک می کند تا مشخص کند که مکانیسم محافظت – SPF ، DKIM یا هر دو – سرور از کدام سرور استفاده می کند ، که در واقع مکانیسم DKIM را برطرف می کند. دوم ، SPF را نیز برطرف می کند ، در ضمن چک کردن آدرس مشخص شده در قسمت "از" عنوان (که در واقع برای کاربر قابل مشاهده است) ، در بالای بررسی آدرس فرستنده در پاکت SMTP ، ارائه می شود. [19659002نکتهمنفیایناستکهپروتکلDMARCنسبتاًجدیداست،هنوزیکاستانداردمناسبنیست(RFC7489آنرانهبهعنواناستانداردیاحتیاستانداردپیشنهادی،بلکهفقطبهعنوان"اطلاعاتی"تعریفمیکند)وبههماناندازهایکهبایداستفادهنمیشودطبقاینمطالعهاز20،000دامنه،فقط20٪DMARCراتاسال2019بهتصویبرساندهبودندوتنها84٪سیاستهایسختگیرانهداشتند

متأسفانه ، تصویب DMARC هنوز گسترده نیست ، و در بسیاری از موارد با "هیچ" استفاده می شود. خط مشی. منبع تصویر

نتیجه:

• مهمترین شماره های SPF و DKIM را برطرف می کند.
• هنوز به طور گسترده اتخاذ نشده است ، و بنابراین به همان اندازه ممکن نیست که بتواند محافظت کند.

چگونه محافظت شود خود را از جعل پست الکترونیکی

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

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

در اینجا آورده شده است. توصیه هایی برای محافظت از پست الکترونیکی: