حمله مرد میانی چیست؟ آموزش MITM، هک وای‌فای و جلوگیری از آن

فرض کن توی یک کافه به وای‌فای وصل شدی و می‌خوای وارد پنل کارت بشی. سایت هم مثل همیشه باز می‌شه؛ نه خطایی می‌بینی، نه چیزی غیرعادی. اما آیا ممکنه ارتباطت از دستگاه شخص دیگه‌ای رد بشه؟ این دقیقاً همون سؤالیه که ما رو به حمله مرد میانی یا MITM می‌رسونه. فقط یه نکته رو از همین اول روشن کنیم: وسط مسیر بودن، به معنی داشتن رمز عبور کاربر یا توانایی خوندن پیام‌های HTTPS نیست. اگه این دو رو یکی بدونیم، از همون اول تحلیل امنیتی‌مون غلط از آب درمیاد.

توی این درس قراره با هم بفهمیم حمله مرد میانی چیست، چه فرقی با شنود شبکه داره و جعل ARP یا وای‌فای تقلبی چطور ممکنه راه رو برای چنین حمله‌ای باز کنن. بعد می‌ریم سراغ خودِ دفاع: اعتبارسنجی گواهی، TLS، HSTS و اشتباه‌هایی که نباید موقع اتصال به شبکه عمومی انجام بدیم. یک تمرین Python هم داریم که بدون تماس با هیچ شبکه‌ای، پنج وضعیت متفاوت رو شبیه‌سازی می‌کنه. نمی‌خوام فقط اسم ابزار حفظ کنی؛ باید بتونی دلیل هر نتیجه رو توضیح بدی.

قبل از شروع یه مرز مشخص داریم: تمام مثال‌های این مقاله برای شناخت خطر و دفاع در شبکه خودت یا محیط دارای مجوزن. نه قرار است ترافیک دیگران رو بگیریم، نه به شبکه واقعی کسی مسیر اشتباه معرفی کنیم. اگر تازه وارد امنیت شبکه شدی، اول درس هک شبکه چیست؟ و بعد شنود شبکه با Wireshark رو بخون. اینجا فرض می‌کنیم معنی اولیه مسیر شبکه و بسته رو بلدی و می‌خوای یک قدم جلوتر بری.

حمله مرد میانی چیست؟ معنی MITM با یک مثال ساده

ببین، وقتی می‌گیم حمله مرد میانی (Man-in-the-Middle)، منظورمون موقعیتیه که یک واسطه غیرمجاز خودش رو بین دو طرف ارتباط جا می‌ده یا یکی از طرف‌ها رو درباره هویت و مسیر ارتباط گمراه می‌کنه. این دو طرف می‌تونن مرورگر و وب‌سایت، اپلیکیشن و API یا دو دستگاه شبکه باشن. توی مستندات جدیدتر، اصطلاح AiTM یا Adversary-in-the-Middle رو هم می‌بینی. اصل مسئله اینه که ارتباطی که باید مستقیم یا از مسیر مورد اعتماد انجام بشه، به مسیر یا اعتماد نامطمئنی وابسته شده.

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

پس اگر کسی گفت «با وصل شدن به وای‌فای عمومی همه حساب‌ها قابل هک هستن»، همون‌جا ازش بپرس چه شرایطی برقرار بوده. آیا واقعاً مسیر ارتباط دست مهاجم بوده؟ ارتباط HTTP بوده یا HTTPS؟ گواهی معتبر بررسی شده؟ دستگاه آلوده بوده؟ حمله مرد میانی یک روش مشخص برای سوءاستفاده از مسیر یا اعتماد ارتباطه، نه یک دکمه جادویی. همین چند سؤال کمک می‌کنه آموزش فنی رو از ادعاهای نمایشی تشخیص بدی.

سناریوی اختصاصی : کاروان تعمیر دوچرخه «چرخ‌گرد»

یه مثال بسازیم که تا آخر درس بهش برگردیم. یک گروه خیالی به اسم «چرخ‌گرد» با ون تعمیر دوچرخه در رویدادهای آخر هفته کار می‌کنن. مسئول پذیرش سفارش‌ها رو با تبلت ثبت می‌کنه، تعمیرکار با لپ‌تاپ وضعیت قطعه رو عوض می‌کنه و مشتری از گوشی خودش مرحله تعمیر رو می‌بینه. بعضی روزها اینترنت موبایل دارن و گاهی به وای‌فای محل رویداد وصل می‌شن. این داستان واقعیه نیست؛ ازش استفاده می‌کنیم تا تصمیم‌های امنیتی رو با یک موقعیت قابل تصور بررسی کنیم.

حالا فرض کن اینترنت موبایل ضعیف شده و مسئول پذیرش یک شبکه با اسم آشنا می‌بینه. بهش وصل می‌شه و صفحه سفارش‌ها هم باز می‌شه. آیا همین کافیه که بگیم همه‌چیز امنه؟ نه. شاید شبکه قانونی همون رویداده، شاید یک نقطه اتصال تقلبی با اسم مشابه باشه، شاید تنظیمات DNS اشتباه شده یا فقط اینترنت کند باشه. یک تحلیل‌گر خوب قبل از گفتن «حمله مرد میانی اتفاق افتاده»، دنبال شواهدی می‌گرده که این احتمال‌ها رو از هم جدا کنه.

در پرونده «چرخ‌گرد» سه سؤال رو جدا نگه می‌داریم: بسته‌ها از کدوم مسیر عبور می‌کنن؟، دستگاه از کجا می‌فهمه با سرور درست صحبت می‌کنه؟ و اگر واسطه‌ای ترافیک رو دید، می‌تونه محتوای اون رو بخونه یا تغییر بده؟ جواب سؤال اول به شبکه مربوطه، دومی به اعتماد و هویت سرور و سومی به رمزگذاری و کنترل‌های برنامه. وقتی این‌ها رو قاطی نکنیم، حمله MITM رو هم خیلی دقیق‌تر می‌فهمیم.

۳ قفل امنیتی در حمله مرد میانی؛ مسیر، هویت و محتوا

قفل اول : مسیر شبکه دست کیه؟

اول مسیر رو بررسی کنیم. تبلت برای رسیدن به اینترنت معمولاً ترافیکش رو به دروازه شبکه می‌فرسته. اگه کسی بتونه دستگاه رو درباره اون دروازه یا مسیر گمراه کنه، ممکنه بخشی از ارتباط از سیستمش رد بشه. جعل ARP در بعضی شبکه‌های IPv4، تنظیمات جعلی DHCP و نقطه اتصال Wi-Fi تقلبی نمونه‌هایی از راه‌های احتمالی ایجاد چنین شرایطی هستن. ولی این روش‌ها پیش‌نیاز دارن و در همه توپولوژی‌ها کار نمی‌کنن؛ صرفاً روی یک وای‌فای بودن، کنترل ترافیک بقیه رو تضمین نمی‌کنه.

قفل دوم : سروری که جواب داده واقعاً همونه؟

حالا فرض کن واسطه واقعاً وسط مسیر قرار گرفته. مرورگر هنوز یک کار مهم داره: باید مطمئن بشه گواهی TLS برای همون دامنه‌ای صادر شده که کاربر قصد باز کردنش رو داشته و زنجیره اعتماد معتبره. اگه طرف واسط گواهی ناشناس یا نامعتبر بده، مرورگر باید اتصال رو متوقف کنه یا هشدار مناسبی نشون بده. اینجا فرق «وصل شدن به یک سرور» و «مطمئن شدن از هویت سرور درست» روشن می‌شه. در حمله مرد میانی، همین مرز اعتماد خیلی تعیین‌کننده‌ست.

قفل سوم : متن سفارش قابل خواندن یا تغییر هست؟

سؤال سوم درباره خود داده‌ست. اگه ارتباط از نوع HTTP بدون TLS باشه و واسطه به مسیر دسترسی داشته باشه، بخش‌هایی از درخواست و پاسخ می‌تونن خوانا یا قابل تغییر باشن. ولی توی HTTPS درست پیکربندی‌شده، TLS برای محتوای منتقل‌شده محرمانگی و یکپارچگی فراهم می‌کنه. ممکنه مشاهده‌گر همچنان IPها، زمان‌بندی یا بخشی از فراداده رو ببینه، اما معمولاً نمی‌تونه بدون شرایط اضافه متن سفارش رو بخونه یا بی‌سر و صدا عوض کنه. پس حمله مرد میانی لزوماً به افشای محتوا منجر نمی‌شه.

حمله MITM چه فرقی با شنود شبکه و هک وای‌فای داره؟

چند تا اصطلاح رو زیاد کنار هم می‌بینی: شنود شبکه، هک وای‌فای و MITM. ولی هم‌معنی نیستن. Packet Sniffing یعنی بسته‌های قابل مشاهده در یک نقطه رو ثبت و تحلیل کنیم؛ این کار حتی روی سیستم خودت می‌تونه کاملاً قانونی و مفید باشه. حمله مرد میانی درباره دست‌کاری مسیر یا اعتماد دو طرفه. «هک وای‌فای» هم یک عبارت کلیه که از تنظیمات ضعیف شبکه تا AP تقلبی و حملات دیگه رو ممکنه شامل بشه. هر کدوم به شواهد متفاوتی نیاز دارن.

مثلاً تکنسین «چرخ‌گرد» ممکنه ترافیک لپ‌تاپ خودش رو با Wireshark بررسی کنه و فقط دنبال تأخیر یک درخواست باشه؛ این حمله نیست. یک نفر دیگه ممکنه روی وای‌فای مهمان باشه، اما ترافیک تبلت پذیرش اصلاً از مسیر قابل مشاهده اون رد نشه. در وضعیت سوم، کاربر به AP تقلبی وصل شده و مسیر اینترنتش از یک سیستم نامطمئن می‌گذره. حتی این وضعیت سوم هم به‌تنهایی ثابت نمی‌کنه رمز HTTPS لو رفته. برای همین توی بررسی هک شبکه، همیشه مسیر، هویت و محتوای ارتباط رو جدا تحلیل می‌کنیم.

جعل ARP چیست و چه ارتباطی با حمله مرد میانی داره؟

برای فهم جعل ARP، لازم نیست از همون اول ابزار هکری اجرا کنیم. توی شبکه محلی IPv4، دستگاه برای فرستادن فریم به یک مقصد در همان بخش شبکه یا به دروازه، باید MAC مربوط به IP مقصدِ همان گام رو بدونه. پروتکل ARP برای همین نگاشت به کار می‌ره و نتیجه معمولاً برای مدتی در جدول ARP نگهداری می‌شه. اگه این نگاشت اشتباه باشه، فریم می‌تونه به دستگاهی غیر از مقصد مورد انتظار برسه؛ این پایه مفهومی ARP Spoofing هست.

در یکی از سناریوهای حمله مرد میانی با جعل ARP، مهاجم سعی می‌کنه دستگاه قربانی فکر کنه IP دروازه به MAC دستگاه مهاجم تعلق داره. اگر شرایط شبکه اجازه بده و ترافیک به اون سمت بره، یک موقعیت واسط ایجاد می‌شه. اما این هنوز به معنی شکسته شدن HTTPS نیست؛ اون بحث جداگانه‌ای درباره TLS و گواهیه. ضمن اینکه این روش به شبکه محلی IPv4 وابسته‌ست و برای IPv6 سازوکار ARP نداریم. دفاع‌های سوئیچ، جداسازی کلاینت‌ها و تنظیمات شبکه هم می‌تونن جلوی بعضی مسیرها رو بگیرن.

حالا اگر توی تبلت «چرخ‌گرد» MAC دروازه از روز قبل عوض شد چی؟ نباید سریع بگیم هک شده. شاید روتر عوض شده، از تجهیزات افزونه استفاده می‌شه یا شبکه تغییر قانونی داشته. تغییر نگاشت فقط سرنخ برای بررسیه. وقتی اون رو کنار اطلاعات معتبرِ تجهیزات، زمان تغییر و پاسخ‌های ARP غیرمنتظره می‌ذاریم، تحلیل معنی پیدا می‌کنه. مستندات MITRE برای ARP Cache Poisoning هم روی همین رفتارها و شواهد قابل پایش تأکید داره.

مقایسه دو جدول ARP بدون دست‌کاری شبکه

برای اینکه فرق «تغییر» و «اثبات حمله» رو با چشم ببینی، دو جدول ARP ساختگی در کد پایین گذاشتم. یکی وضعیت مورد انتظار آزمایشگاهه و اون یکی چیزی که فرض می‌کنیم در زمان بررسی دیده شده. این برنامه هیچ بسته‌ای نمی‌فرسته، جدول ARP سیستم رو تغییر نمی‌ده و به شبکه وصل نمی‌شه. فقط دو دیکشنری Python رو مقایسه می‌کنه. پس اگر نتیجه مشکوک بود، هنوز باید به دنبال توضیح معتبر یا شواهد تکمیلی بگردیم.

# داده کاملاً ساختگی — مقایسه آفلاین و بدون اتصال شبکه
known = {
    "192.0.2.1": "02:00:00:00:00:01",
    "192.0.2.50": "02:00:00:00:00:50",
}
observed = {
    "192.0.2.1": "02:00:00:00:00:99",
    "192.0.2.50": "02:00:00:00:00:50",
}
for ip, expected_mac in known.items():
    current_mac = observed.get(ip)
    if current_mac != expected_mac:
        print(f"REVIEW {ip}: expected={expected_mac}, seen={current_mac}")
    else:
        print(f"UNCHANGED {ip}")

REVIEW 192.0.2.1: expected=02:00:00:00:00:01, seen=02:00:00:00:00:99
UNCHANGED 192.0.2.50

توی خروجی عمداً عبارت REVIEW رو می‌بینی، نه «هک شد». این انتخاب اتفاقی نیست. برنامه فقط می‌گه مقدار مشاهده‌شده با مرجع فرق داره؛ نمی‌تونه علت اون تفاوت رو تشخیص بده. آدرس‌های 192.0.2.x هم برای مستندسازی انتخاب شدن، نه هدف‌گیری یک شبکه واقعی. همین تفاوت بین مشاهده و قضاوت، موقع بررسی حمله مرد میانی از خیلی نتیجه‌های عجولانه جلوگیری می‌کنه.

وای‌فای تقلبی یا Evil Twin چطور به MITM مربوط می‌شه؟

یکی دیگه از سناریوهای شناخته‌شده، Evil Twin یا وای‌فای تقلبیه. فرض کن تیم «چرخ‌گرد» همیشه به وای‌فای رویداد با یک اسم مشخص وصل می‌شه. فردی ممکنه یک نقطه اتصال با نام مشابه بسازه تا کاربر اشتباهی همون رو انتخاب کنه. اگر اتصال برقرار بشه، اپراتور اون شبکه ممکنه مسیر بخشی از ترافیک رو در اختیار داشته باشه یا صفحه ورود فریبنده‌ای نمایش بده. MITRE این رفتار رو در دسته حملات AiTM ثبت کرده، اما موفقیتش به شرایط و رفتار کاربر وابسته‌ست.

با این حال، دیدن دو وای‌فای با اسم یکسان خودش سند حمله نیست. توی ساختمان‌های بزرگ چند Access Point قانونی ممکنه یک SSID داشته باشن. از اون طرف، اتصال به AP تقلبی هم خودبه‌خود باعث خوانده شدن محتوای HTTPS معتبر نمی‌شه. تهدید می‌تونه از فیشینگ، ارتباط بدون رمز یا فریب کاربر برای قبول گواهی نامعتبر شروع بشه. اگر می‌خوای این مورد رو دقیق‌تر ببینی، مستندات MITRE درباره Evil Twin نمونه‌ها و نشانه‌های قابل بررسی رو توضیح داده.

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

آیا در حمله مرد میانی می‌شه HTTPS رو شکست؟

اینجا برسیم به سؤال اصلی: آیا حمله مرد میانی می‌تونه HTTPS رو بشکنه؟ صرف قرار گرفتن در مسیر، نه. وقتی مرورگر گواهی سرور رو درست اعتبارسنجی می‌کنه و TLS با تنظیمات امن برقرار شده، واسطه معمولی نمی‌تونه فقط با دیدن بسته‌ها متن درخواست رو بخونه یا بی‌سروصدا دست‌کاریش کنه. ممکنه اتصال رو قطع کنه، کندش کنه یا بعضی فراداده‌ها رو ببینه، اما رمزگذاری و تأیید هویت مانع جداگانه‌ای جلوی خواندن محتوا ایجاد می‌کنن.

مرورگر فقط چک نمی‌کنه که «یک قفل روی صفحه هست»؛ نام دامنه مورد انتظار، معتبر بودن گواهی و زنجیره اعتماد رو هم می‌سنجه. اگر واسطه کاربر رو به سروری با گواهی نامعتبر هدایت کنه، اتصال باید متوقف بشه یا هشدار مناسب بده. اما یک ظرافت رو یادت باشه: سایت فیشینگ می‌تونه برای دامنه خودش گواهی معتبر داشته باشه. بنابراین HTTPS معتبر برای یک دامنه اشتباه، اصالت کسب‌وکار موردنظر تو رو تضمین نمی‌کنه. این فرق بین امنیت کانال و اعتماد به مقصد خیلی مهمه.

البته هیچ دفاعی رو مطلق معرفی نمی‌کنیم. ممکنه برنامه بررسی گواهی رو غیرفعال کرده باشه، دستگاه به یک مرجع صدور گواهی نامطمئن اعتماد کرده باشه، کاربر هشدار رو رد کرده باشه یا خود نقطه پایانی آلوده شده باشه. در شبکه‌های سازمانی هم بازرسی مجاز TLS وجود داره که بر اساس سیاست و گواهی مورد اعتماد انجام می‌شه. این‌ها شرط‌های اضافی‌اند و نباید با «هرکس وسط مسیر بود رمزها رو می‌خونه» یکی گرفته بشن. راهنمای TLS در OWASP همین نقش رمزگذاری و اعتبارسنجی رو توضیح می‌ده.

HTTP، HTTPS و هشدار گواهی در یک نگاه

HSTS چیست و چه کمکی به جلوگیری از حمله مرد میانی می‌کنه؟

یه موقعیت ظریف رو تصور کن. کاربر آدرس سایت رو برای اولین بار با HTTP باز می‌کنه و سرور می‌خواد اون رو به HTTPS منتقل کنه. اولین درخواست ممکنه قبل از رمزگذاری انجام شده باشه. HSTS به مرورگری که سیاست معتبر یک دامنه رو دریافت و ذخیره کرده می‌گه از این به بعد برای اون دامنه فقط اتصال HTTPS بسازه و بعضی هشدارهای گواهی رو قابل عبور ندونه. این سیاست می‌تونه بخشی از خطر حمله مرد میانی در شروع ارتباط ناامن رو کم کنه؛ به شرط اینکه درست پیاده‌سازی شده باشه.

اما حواست به اولین بازدید باشه. اگر مرورگر قبلاً سیاست HSTS دامنه رو از پاسخ امن نگرفته، اولین درخواست همچنان ممکنه در معرض خطر باشه؛ مگر اینکه دامنه از قبل در فهرست معتبر HSTS Preload مرورگر قرار داشته باشه. از طرف دیگه، فعال کردن includeSubDomains بدون بررسی تک‌تک زیردامنه‌ها می‌تونه سرویس‌هایی رو که هنوز HTTPS درست ندارن از کار بندازه. برای همین قبل از اعمال این هدر روی سایت واقعی باید نقشه دامنه‌ها و گواهی‌ها رو بررسی کرد، نه اینکه صرفاً یک خط تنظیمات رو کپی کرد.

# نمونه هدر دفاعی؛ فقط پس از بررسی آمادگی HTTPS همه زیردامنه‌ها
Strict-Transport-Security: max-age=31536000; includeSubDomains

نمونه هدر پایین رو فقط برای شناخت شکل دستور گذاشتم؛ این خط باید در پاسخ HTTPS سرور ارسال بشه و تا وقتی مطمئن نشدی همه زیردامنه‌های موردنظر آماده‌ان، نباید کورکورانه فعالش کنی. HSTS جلوی فیشینگ روی دامنه‌ای متفاوت یا آلودگی خود دستگاه رو نمی‌گیره؛ یکی از لایه‌های دفاعه، نه همه اون. برای جزئیات فنی، مستندات HSTS در MDN مرجع مناسبیه.

آموزش MITM با Python؛ آزمایش آفلاین و بدون دست‌کاری شبکه

حالا بیایم با یک تمرین بی‌خطر، تصمیم‌گیری درباره حمله مرد میانی رو تمرین کنیم. به‌جای اینکه واقعاً ARP رو جعل کنیم یا ارتباط کسی رو بگیریم، پنج موقعیت ساختگی تعریف می‌کنیم: واسطه در مسیر هست یا نه، ارتباط HTTP هست یا HTTPS، گواهی بررسی شده یا نه و کاربر هشدار رو رد کرده یا نه. برنامه فقط همین داده‌ها رو تحلیل می‌کنه. این شبیه‌سازی مفهومیه؛ پیاده‌سازی TLS، اسکن شبکه یا اثبات وقوع یک حمله واقعی نیست.

فایل رو با اسم mitm_decisions.py ذخیره کن و با Python 3 اجراش کن. به کتابخانه جانبی نیاز نداری و کد حتی یک سوکت هم باز نمی‌کنه. یک اصلاح مهم نسبت به مثال‌های ساده اینه که ورودی‌های ناسازگار رو رد می‌کنیم؛ مثلاً پروتکل نامعتبر، یا ادعای معتبر بودن گواهی برای ارتباط HTTP. در آموزش امنیت نباید اجازه بدیم یک داده اشتباه بی‌سروصدا به نتیجه‌ای ظاهراً معتبر تبدیل بشه.

from dataclasses import dataclass


@dataclass(frozen=True)
class Case:
    name: str
    in_path: bool
    scheme: str
    certificate_ok: bool
    user_bypasses_warning: bool = False

    def __post_init__(self):
        if not isinstance(self.name, str) or not self.name.strip():
            raise ValueError("name must be a non-empty string")
        for field in ("in_path", "certificate_ok", "user_bypasses_warning"):
            if type(getattr(self, field)) is not bool:
                raise TypeError(f"{field} must be bool")
        if self.scheme not in ("HTTP", "HTTPS"):
            raise ValueError("scheme must be HTTP or HTTPS")
        if self.scheme == "HTTP" and (self.certificate_ok or self.user_bypasses_warning):
            raise ValueError("HTTP has no TLS certificate to verify or bypass")
        if self.certificate_ok and self.user_bypasses_warning:
            raise ValueError("no warning bypass is needed for a valid certificate")


def describe(case: Case) -> str:
    # The result only describes this deliberately simplified network-path model.
    if not case.in_path:
        return "NO_INTERMEDIARY"
    if case.scheme == "HTTP":
        return "PLAINTEXT_AT_RISK"
    if case.certificate_ok:
        return "TLS_PROTECTS_CONTENT"
    if case.user_bypasses_warning:
        return "TRUST_BYPASSED_RISK"
    return "BLOCKED_BY_CERTIFICATE_CHECK"


cases = [
    Case("ordinary-https", False, "HTTPS", True),
    Case("intercepted-http", True, "HTTP", False),
    Case("intercepted-https", True, "HTTPS", True),
    Case("invalid-cert-stop", True, "HTTPS", False),
    Case("invalid-cert-ignored", True, "HTTPS", False, True),
]

for case in cases:
    print(f"{case.name}: {describe(case)}")

ordinary-https: NO_INTERMEDIARY
intercepted-http: PLAINTEXT_AT_RISK
intercepted-https: TLS_PROTECTS_CONTENT
invalid-cert-stop: BLOCKED_BY_CERTIFICATE_CHECK
invalid-cert-ignored: TRUST_BYPASSED_RISK

به مورد سوم خروجی دقت کن: intercepted-https یعنی در مدل ما واسطه توی مسیره، اما گواهی معتبره و ارتباط TLS درست فرض شده. پس خروجی TLS_PROTECTS_CONTENT میاد. این جمله به معنای مخفی شدن آدرس IP، محافظت از دستگاه آلوده یا جلوگیری از قطع ارتباط نیست. فقط می‌گه قرار گرفتن در مسیر به‌تنهایی محتوای یک ارتباط HTTPS معتبر رو آشکار نمی‌کنه. همین تفکیک باید توی گزارش‌های حمله MITM هم رعایت بشه.

برای تمرین بیشتر، مقدار certificate_ok رو در حالت چهارم از False به True تغییر بده و ببین چرا خروجی عوض می‌شه. بعد سعی کن یک مقدار مثل "FTP" برای scheme وارد کنی؛ نسخه اصلاح‌شده به‌جای حدس زدن، خطای مشخص می‌ده. در پایان هم یک سناریوی «بدافزار روی خود دستگاه» روی کاغذ بنویس و توضیح بده چرا این مدل اصلاً برای قضاوت درباره اون طراحی نشده. فهمیدن محدودیت مدل به اندازه اجرای خود کد مهمه.

جعل DNS، DHCP و ARP یک چیز نیستن

توی بحث حمله مرد میانی اسم سه پروتکل ARP، DNS و DHCP زیاد شنیده می‌شه، اما نقش‌شون فرق داره. ARP در IPv4 محلی کمک می‌کنه IP گام بعدی به MAC مربوط وصل بشه. DNS نام دامنه رو به پاسخ‌های لازم برای اتصال تبدیل می‌کنه و DHCP می‌تونه تنظیماتی مثل IP، دروازه و DNS رو به کلاینت بده. اگر یکی از این پاسخ‌ها جعل بشه، ممکنه مسیر یا مقصد ارتباط تغییر کنه؛ بااین‌حال از نظر فنی سه مسئله متفاوتن و هرکدوم شواهد مخصوص خودشون رو دارن.

برای «چرخ‌گرد»، اگر پاسخ DNS دامنه سفارش‌ها ناگهان متفاوت شد، باید تنظیمات DNS و مرجع معتبر رو بررسی کنیم. اگر MAC مربوط به دروازه عوض شد، موضوع مربوط به همون بخش محلی شبکه‌ست. اگر تبلت دروازه یا DNS غیرمنتظره گرفته، سراغ تنظیمات DHCP می‌ریم. هیچ‌کدوم از این مشاهده‌ها به‌تنهایی نمی‌گن حمله مرد میانی اتفاق افتاده. سؤال درست اینه که چه چیزی تغییر کرده، چه زمانی، تحت مدیریت چه دستگاهی و آیا تغییر با پیکربندی مجاز سازگاره یا نه.

آیا VPN جلوی حمله مرد میانی رو می‌گیره؟

خیلی‌ها می‌پرسن «اگر VPN روشن کنم دیگه حمله مرد میانی غیرممکنه؟» نه؛ این‌قدر ساده نیست. یک VPN معتبر و درست پیکربندی‌شده می‌تونه ترافیک بین دستگاه و سرور VPN رو در برابر مشاهده‌گر شبکه محلی محافظت کنه. ولی ترافیک پس از خروج از تونل هم مسیر خودش رو داره و ارائه‌دهنده VPN وارد مدل اعتماد می‌شه. برای ارتباط با وب‌سایت، هنوز باید به HTTPS معتبر، نام دامنه درست و سلامت دستگاه اهمیت بدی. VPN جای اعتبارسنجی سرور رو نمی‌گیره.

فرض کن کارمند «چرخ‌گرد» با VPN وارد یک صفحه فیشینگ بشه و خودش رمز رو وارد کنه؛ تونل VPN نمی‌تونه تشخیص بده اون صفحه واقعاً متعلق به کسب‌وکار اصلی نیست. یا اپلیکیشن گواهی TLS رو بررسی نکنه؛ باز هم تنظیم ناامن برنامه پابرجاست. حتی اگر شبکه انتقال امن باشه، بدافزار روی دستگاه می‌تونه داده رو قبل از رمزگذاری ببینه. پس برای کاهش خطر، چند لایه رو با هم لازم داریم: اتصال قابل اعتماد، HTTPS معتبر، بررسی دامنه، به‌روزرسانی و احراز هویت مناسب.

نشانه‌های حمله MITM چیه؟ چه چیزهایی مدرک قطعی نیستن؟

حالا از کجا بفهمیم ممکنه حمله مرد میانی در جریان باشه؟ هشدار غیرمنتظره گواهی، درخواست نصب گواهی ناشناس، صفحه ورود عجیب، عوض شدن دروازه یا DNS و تغییرهای غیرقابل توضیح جدول ARP می‌تونن سرنخ باشن. اما هیچ‌کدوم به‌تنهایی سند قطعی نیستن. مثلاً عوض شدن روتر یا وجود صفحه ورود قانونی یک هتل هم ممکنه نشانه مشابهی ایجاد کنه. برای نتیجه‌گیری باید چند منبع شواهد مستقل رو کنار هم بذاریم و اتفاق‌های عادی رو هم بررسی کنیم.

فرض کن مسئول پذیرش زنگ می‌زنه و می‌گه «پنل سفارش خطای Certificate می‌ده». پاسخ حرفه‌ای این نیست که فوراً اسم هکر رو وسط بکشیم. اول باید نام دامنه، متن دقیق خطا، شبکه‌ای که دستگاه بهش وصله، زمان اتفاق و تغییرات اخیر رو ثبت کنیم. بعد از مسیر پشتیبانی معتبر بررسی می‌کنیم آیا فقط یک دستگاه این وضعیت رو داره یا چند دستگاه. در تمام این مراحل هم نباید کوکی، رمز عبور یا اطلاعات مشتری‌ها رو بی‌دلیل داخل گروه یا فایل گزارش منتشر کنیم.

چک‌لیست تصمیم‌گیری برای یک هشدار مشکوک

وقتی با هشدار مشکوک روبه‌رو شدی، این ترتیب ساده رو انجام بده: عملیات حساس مثل ورود یا پرداخت رو متوقف کن، شبکه‌ای رو که بهش وصلی بررسی کن، هشدار گواهی رو دور نزن و از راه مستقل با مسئول شبکه یا سرویس تماس بگیر. اگر مشکل ادامه داشت، فقط شواهد لازم و غیرحساس رو ذخیره کن. روی یک دستگاه خاص، سلامت سیستم و مخزن گواهی‌ها هم مهمه؛ روی چند دستگاه، بررسی تجهیزات Wi-Fi، DNS، DHCP و لاگ‌های شبکه ارزش بیشتری پیدا می‌کنه. هدف پیدا کردن علت واقعیه، نه عجله برای برچسب زدن.

روش‌های جلوگیری از حمله مرد میانی برای کاربران عادی

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

یه اشتباه خیلی رایج اینه که هر صفحه‌ای علامت قفل داشت، اون رو متعلق به شرکت اصلی بدونیم. قفل HTTPS فقط درباره ارتباط با همون دامنه‌ایه که باز کردی، نه درباره خوش‌نامی یا واقعی بودن صاحب صفحه. یک مهاجم ممکنه برای دامنه مشابه و فیشینگ خودش هم گواهی معتبر بگیره. پس اسم سایت رو حرف‌به‌حرف بررسی کن، مخصوصاً زمانی که از یک پیام یا QR Code ناشناس به صفحه ورود رسیدی. نصب گواهی ریشه ناشناس برای «رفع خطای اینترنت» هم می‌تونه مدل اعتماد دستگاه رو خراب کنه.

روش‌های جلوگیری از MITM برای مدیر شبکه و توسعه‌دهنده

اگر مدیر شبکه هستی، دفاع در برابر حمله مرد میانی از شناختن توپولوژی شروع می‌شه. شبکه مهمان رو واقعاً از بخش‌های کاری جدا کن، دسترسی مدیریتی سوئیچ و روتر رو محدود کن و APهای غیرمجاز یا تغییرات غیرعادی ARP و DHCP رو پایش کن. روی تجهیزات سازگار، امکاناتی مثل DHCP Snooping و Dynamic ARP Inspection می‌تونن بخشی از خطر جعل رو کاهش بدن؛ اما روشن کردنشون بدون شناخت پورت‌های مورد اعتماد و تنظیمات شبکه ممکنه اختلال درست کنه. قبل از هر تغییری باید طراحی و اثر عملیاتی رو بررسی کنی.

برای توسعه‌دهنده، مهم‌ترین کار اینه که برنامه روی اعتبارسنجی درست TLS کوتاه نیاد. صفحات و APIهای حساس باید از HTTPS امن استفاده کنن، نام دامنه و گواهی سمت کلاینت درست بررسی بشه، کوکی‌های حساس با ویژگی‌های مناسب از جمله Secure تنظیم بشن و سیاست HSTS متناسب با زیرساخت باشه. اگر اپلیکیشن برای دور زدن یک خطا، بررسی گواهی رو خاموش کرده باشه، اون نقطه ضعف با نصب یک فایروال جدید جبران نمی‌شه. برای چک کردن جزئیات، راهنمای OWASP برای TLS و توضیحات MDN درباره MITM منابع قابل اتکایی هستن.

فرق MITM با XSS، CSRF و IDOR چیه؟

احتمالاً الان می‌پرسی حمله مرد میانی با XSS و CSRF و IDOR چه فرقی داره. جواب رو از محل شکست امنیتی پیدا کن. MITM روی مسیر یا اعتماد ارتباط اثر می‌ذاره؛ XSS به اجرای ناامن محتوای غیرقابل اعتماد در مرورگر مربوطه؛ CSRF از امکان ارسال درخواست ناخواسته با اعتبار نشست کاربر سوءاستفاده می‌کنه و IDOR به کنترل دسترسی ناکافی روی یک شیء یا رکورد مربوطه. ممکنه چند ضعف با هم دیده بشن، اما توضیح یکی جای دیگری رو نمی‌گیره.

مثلاً اگه مشتری با تغییر شماره سفارش، اطلاعات نفر دیگه‌ای رو ببینه، اول باید کنترل مجوزهای دسترسی بررسی بشه؛ این نمونه رو در درس باگ IDOR چیست؟ توضیح دادیم. اگر یک ورودی باعث اجرای اسکریپت در مرورگر بشه، بحث XSS مطرحه، نه لزوماً MITM. اگر هم کاربر روی وای‌فای تقلبی به صفحه ورود جعلی هدایت شد، باید مسیر ارتباط و فیشینگ رو جدا ارزیابی کنیم. برای تصویر کلی‌تر، مقاله هک سایت چگونه انجام می‌شود؟ کمک می‌کنه این دسته‌ها رو با هم اشتباه نگیری.

گزارش یک حمله مرد میانی چطور باید نوشته بشه؟

برای نوشتن گزارش حمله مرد میانی، اول معلوم کن چی واقعاً دیده شده. فرض کن در شبکه آزمایشگاهی مجاز، MAC دروازه تغییر کرده و هم‌زمان یک هشدار گواهی ثبت شده. تا وقتی علت و رابطه این دو مشخص نشده، گزارش «رمز همه کاربران سرقت شد» هیچ پشتوانه‌ای نداره. بنویس کدوم دارایی بررسی شده، مشاهده در چه زمان و نقطه‌ای بوده، وضعیت عادی چی بوده، چه شواهدی داریم و کدوم فرضیه‌ها هنوز اثبات نشدن. پیشنهاد اصلاح هم باید متناسب با همون شواهد باشه.

برای مدیر مجموعه لازم نیست گزارش رو پر از مخفف‌های فنی کنی. مثلاً می‌تونی بنویسی: «هنگام اتصال به شبکه عمومی، هشدار اعتبارسنجی سرور مشاهده شد؛ ورود به پنل متوقف و بررسی فنی آغاز شد. فعلاً شاهدی از افشای محتوای رمزگذاری‌شده نداریم.» در بخش فنی گزارش هم نام دامنه، نوع هشدار، مشخصات غیرحساس گواهی، زمان و جزئیات مرتبط شبکه رو ثبت کن. این شیوه هم خطر رو پنهان نمی‌کنه، هم بیشتر از شواهد ادعا نمی‌کنه.

پنج اشتباه رایج موقع یادگیری هک شبکه و MITM

پنج اشتباه رو مرتب می‌بینیم: فکر کنیم همه کاربران یک وای‌فای ترافیک همدیگه رو می‌بینن؛ جعل ARP رو معادل شکستن HTTPS بدونیم؛ هشدار گواهی رو بی‌اهمیت فرض کنیم؛ هر تغییر شبکه رو فوراً حمله مرد میانی اعلام کنیم؛ و برای یادگیری، بدون مجوز سراغ شبکه دیگران بریم. هر کدوم یک مشکل جدی دارن: یا مفهوم فنی رو بد فهمیدیم، یا درباره شواهد اغراق کردیم، یا از مرز قانونی عبور کردیم. بهتره این خطاها رو توی آزمایشگاه کوچک خودمون بشناسیم تا در پروژه واقعی تکرارشون نکنیم.

اگه می‌خوای بعدها تست نفوذ شبکه رو جدی دنبال کنی، فهمیدن TCP/IP، ARP، DNS، DHCP و TLS برات مهم‌تر از حفظ کردن اسم چند ابزار هکریه. کنار اون باید یاد بگیری چطور محدوده مجوز رو مشخص کنی، چه چیزی رو ثبت کنی و چه موقع صادقانه بگی «هنوز نمی‌دونم». درس اسکن پورت و وضعیت پورت‌های باز یکی از تمرین‌های خوب برای همین نوع تحلیل شواهده. مهارت اصلی در امنیت اینه که بتونی پشت هر نتیجه دلیل داشته باشی.

تمرین‌های آخر درس : این چهار پرونده رو خودت قضاوت کن

پرونده اول : قفل HTTPS سبزه، اما اسم دامنه فرق داره

در پرونده اول، مشتری صفحه‌ای رو می‌بینه که شبیه پنل «چرخ‌گرد» طراحی شده و HTTPS هم داره، اما دامنه‌اش با دامنه اصلی فرق می‌کنه. آیا قفل مرورگر نشون می‌ده صفحه واقعیه؟ نه. گواهی می‌تونه برای همین دامنه متفاوت معتبر باشه؛ درحالی‌که خود صفحه فیشینگ باشه. پس سؤال اول باید درباره هویت مقصد باشه، نه صرفاً رنگ قفل. این نمونه الزاماً حمله مرد میانی نیست و بیشتر به فریب کاربر و دامنه جعلی مربوط می‌شه.

پرونده دوم : MAC دروازه تغییر کرده ولی شبکه ارتقا یافته

در پرونده دوم، بعد از ارتقای تجهیزات شبکه MAC مربوط به دروازه تغییر کرده. آیا همین یعنی ARP Spoofing رخ داده؟ باز هم نه. اول تغییرات ثبت‌شده تجهیزات و اطلاعات معتبر مدیریت شبکه رو بررسی کن. اگر هم‌زمان پاسخ‌های ARP ناخواسته یا نگاشت‌های متناقض دیده بشن، دلیل خوبی برای بررسی بیشتر داریم. اما صرف تفاوت دو مقدار در دو روز مختلف، برای اثبات حمله مرد میانی کافی نیست.

پرونده سوم : مسیر مشکوکه ولی TLS معتبر مونده

در پرونده سوم، کاربر احتمال می‌ده به یک شبکه نامطمئن وصل شده، اما ارتباطش با دامنه موردنظر همچنان TLS معتبر داره. این وضعیت چه چیزی رو ثابت می‌کنه؟ فقط اینکه در شرایط فرض‌شده، کنترل امنیتی ارتباط برقرار بوده؛ نه اینکه هیچ خطر دیگه‌ای وجود نداره. واسطه هنوز ممکنه بعضی فراداده‌ها رو ببینه یا ارتباط رو قطع کنه. بدون شاهد اضافه نمی‌تونیم بگیم محتوای رمزگذاری‌شده افشا شده.

پرونده چهارم : برنامه خطای گواهی رو نادیده می‌گیره

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

سؤال‌های متداول درباره حمله مرد میانی

جمع‌بندی : وسط مسیر بودن کافی نیست

اگر بخوام این درس رو در یک نکته خلاصه کنم، اینه: در حمله مرد میانی، کنترل مسیر و توانایی خواندن محتوا دو مسئله جدا هستن. با داستان «چرخ‌گرد» دیدیم وای‌فای تقلبی، جعل ARP و تغییر تنظیمات شبکه ممکنه مسیر رو نامطمئن کنن، ولی برای قضاوت درباره اطلاعات حساس باید هویت سرور، اعتبار گواهی، TLS و وضعیت خود دستگاه رو هم بررسی کنیم. هر جا فقط یک نشانه داریم، باید همون رو گزارش کنیم؛ نه بیشتر.

این مقاله یکی از درس‌های رایگان مسیر آموزش امنیت شبکه نابغه‌ها بود. حالا می‌تونی به پیام‌های هشدار گواهی، تغییر مسیر و حرف‌هایی که درباره «هک وای‌فای در چند ثانیه» می‌شنوی با نگاه دقیق‌تری برخورد کنی. اگر دوست داری یادگیری رو با تمرین‌ها و مباحث تخصصی‌تر ادامه بدی، سرفصل‌های پکیج متخصص تست نفوذ رو ببین و با هدفت مقایسه کن. هدف این درس این بود که مفهوم رو کامل بفهمی، نه اینکه برای جواب گرفتن مجبور به خرید دوره بشی.

منابع رسمی برای مطالعه بیشتر

برای بررسی مستقل نکات فنی، سراغ این منابع برو: چارچوب MITRE درباره Adversary-in-the-Middle، جعل ARP در MITRE، Evil Twin در MITRE، توضیح حمله MITM در MDN، امنیت TLS در OWASP و راهنمای HSTS در MDN. داستان «چرخ‌گرد» و مدل سه‌قفل فقط برای آموزش ساخته شدن؛ گزارش حادثه واقعی یا استاندارد رسمی نیستن.