شنود شبکه چیست؟ آموزش Wireshark و Packet Sniffing در هک شبکه

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

قراره اول بفهمیم Packet Sniffing دقیقاً چه کاری می‌کنه و ابزار چه محدودیت‌هایی داره. بعد می‌ریم سراغ یه جشنواره فیلم فرضی و آخرش روی کامپیوتر خودت با Python و Wireshark یه آزمایش بی‌خطر انجام می‌دیم. تفاوت HTTP و HTTPS، نحوه انتخاب رابط ضبط، فیلترها و روش گزارش‌نویسی رو هم وسط همون ماجرا یاد می‌گیری. به دستگاه هیچ‌کس وصل نمی‌شیم؛ تمام ترافیک تمرین روی 127.0.0.1 می‌مونه.

شنود شبکه چیست؟ تعریف ساده Packet Sniffing

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

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

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

سه مرز دید : چیزی که در شبکه هست، چیزی که ضبط می‌کنی و چیزی که می‌فهمی

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

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

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

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

یه جشنواره فیلم کوتاه فرضی به اسم «دالان» رو تصور کن. دستگاه پخش سالن توی شبکه مخصوص خودشه، داورها با یه شبکه دیگه امتیاز می‌دن و تماشاگرها هم به وای‌فای مهمان وصل می‌شن. حالا یکی از تماشاگرها وایرشارک رو روی لپ‌تاپش باز می‌کنه و می‌پرسه: «پس می‌تونم رأی داورها رو ببینم؟» جواب رو نه از روی اسم برنامه می‌فهمیم، نه از اینکه همه توی یه ساختمانن.

چند ارتباط جدا اینجا داریم: گوشی تماشاگر یه سایت عمومی رو باز می‌کنه، لپ‌تاپ داور از HTTPS استفاده می‌کنه و دستگاه پخش هم با سرویس داخلی خودش ارتباط داره. ممکنه اینترنت خروجی همه یکی باشه، ولی این اصلاً ثابت نمی‌کنه بسته‌های شبکه داورها به کارت شبکه مهمان می‌رسن. نوع تفکیک شبکه، فایروال، تنظیمات وای‌فای و جایی که Capture می‌گیریم، همگی روی نتیجه اثر می‌ذارن.

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

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

بسته شبکه دقیقاً چه چیزهایی داره؟

بیا قبل از اجرای ابزار یه نگاه به خود بسته بندازیم. بسته‌ای که Wireshark نشون می‌ده، بسته به محل ضبط می‌تونه اطلاعات لایه لینک، آدرس‌های IP، سرآیند TCP یا UDP و داده لایه بالاتر رو داشته باشه. شماره‌ای هم که کنار هر ردیف می‌بینی، شماره همون بسته در فایل ضبط توئه؛ نه یه شناسه جهانی که همه جا یکسان بمونه.

برای مثال، از IP می‌تونیم درباره مبدأ و مقصد در لایه شبکه سرنخ بگیریم؛ از پورت درباره انتهای اتصال، و از فیلدهای TCP درباره جزئیات انتقال. ولی هیچ‌کدوم به‌تنهایی هویت آدم پشت ارتباط یا امنیت برنامه رو اثبات نمی‌کنن. توی درس اسکن پورت و Nmap همین مسئله رو از زاویه سرویس‌ها دیدیم؛ اینجا داریم خود ترافیک رو می‌خونیم.

یه دام دیگه هم هست: هر درخواست HTTP لزوماً توی یه بسته جا نمی‌شه. TCP یه جریان داده‌ست و ممکنه اطلاعات رو در چند قطعه جابه‌جا کنه. Wireshark می‌تونه قسمت‌هایی از جریان رو بازسازی کنه، اما اگه موقع ضبط بسته‌ای از دست بره یا محتوا رمزگذاری شده باشه، چیزی که می‌بینی محدود می‌شه. پس «این متن توی یه بسته نبود» مساوی «این متن اصلاً منتقل نشد» نیست.

شنود غیرفعال و شنود فعال چه فرقی دارن؟

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

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

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

آموزش Wireshark؛ اول Capture Interface رو درست انتخاب کن

وقتی Wireshark رو از سایت رسمی نصب و باز می‌کنی، چندتا رابط می‌بینی؛ مثلاً Ethernet، Wi-Fi و Loopback. قرار نیست هر کدوم که کنار اسمش نمودار بیشتری داشت انتخاب کنی! باید ببینی ارتباطی که می‌خوای بررسی کنی از کجا رد می‌شه. چون آزمایش ما روی 127.0.0.1 انجام می‌شه، معمولاً Loopback رابط درسته. برای توضیح رسمی هم راهنمای ضبط Loopback در Wireshark رو داریم.

روی لینوکس معمولاً اسم رابط lo و روی مک lo0 هست. توی ویندوز هم برای شنود شبکه در آزمایش Loopback باید پشتیبانی Npcap نصب باشه؛ ممکنه توی فهرست رابط‌ها چیزی شبیه Adapter for loopback traffic capture ببینی. اسم دقیق بسته به نسخه فرق داره. اگه چنین رابطی نمی‌بینی، قبل از هر کاری نصب Npcap و تنظیمات خود Wireshark رو چک کن؛ کارت وای‌فای جای Loopback نیست.

برای Capture ممکنه سیستم‌عامل ازت دسترسی بیشتری بخواد، ولی مجوز سیستم‌عامل با اجازه صاحب شبکه یکی نیست. همچنین Promiscuous Mode و Monitor Mode امکاناتی وابسته به سخت‌افزار و درایورن؛ روشن کردنشون همه ترافیک اطراف رو خودکار در اختیارت نمی‌ذاره. توی این آزمایش هیچ نیازی نداریم سراغ این تنظیمات بریم.

فیلتر Capture با فیلتر Display در شنود شبکه یکی نیست

این یکی رو خوب یاد بگیر، چون واقعاً دردسر درست می‌کنه: Capture Filter و Display Filter دو چیز جدا هستن. اولی مشخص می‌کنه هنگام ضبط چه بسته‌هایی ثبت بشن و معمولاً از قواعد BPF استفاده می‌کنه؛ دومی فقط از بین بسته‌های موجود، مواردی رو برای نمایش انتخاب می‌کنه. مثلاً tcp port 8765 یه Capture Filter هست، اما tcp.port == 8765 یه Display Filter. اگه عبارت دومی رو جای اولی بنویسی، خطای نحوی می‌گیری. این تفاوت توی مستندات رسمی فیلتر ضبط هم توضیح داده شده.

برای شروع، رابط Loopback رو انتخاب کن، ضبط رو روشن کن و بعد توی نوار Display Filter بنویس tcp.port == 8765. اگه هنوز چیزی نمی‌بینی، اول درخواست رو اجرا کن و ببین ضبط همون موقع فعال بوده یا نه. یادت باشه اگه Capture Filter از اول بسته‌ای رو کنار گذاشته باشه، دیگه با عوض کردن Display Filter نمی‌تونی اون بسته رو برگردونی.

آزمایش عملی شنود شبکه : بسته‌های خودت با Python و Wireshark

حالا وقتشه شنود شبکه رو توی یه آزمایش واقعی ولی کاملاً محلی ببینیم. یه سرور کوچیک Python روی 127.0.0.1:8765 بالا میاریم و از همون لپ‌تاپ بهش درخواست HTTP می‌فرستیم. داخل درخواست فقط رشته ساختگی NABEGHEHA-LOCAL قرار می‌گیره؛ نه ایمیل واقعی، نه رمز و نه اطلاعات کسی دیگه. قراره در Wireshark مسیر بسته‌ها رو ببینی، نه اینکه ترافیک دستگاه‌های اطراف رو بگیری.

عمداً برای این تمرین آزمایشگاهی HTTP بدون TLS انتخاب شده تا متن ساده رو بتونی داخل Capture تشخیص بدی. این انتخاب برای سرویس واقعی، حساب کاربری و اطلاعات حساس مناسب نیست. بعداً هم می‌بینیم که HTTPS دقیقاً کدوم بخش از محتوا رو رمزگذاری می‌کنه. پس این کد رو به عنوان الگوی آماده Production در نظر نگیر.

گام اول : سرور فقط روی کامپیوتر خودت

توی یه پوشه خالی، فایلی به نام sniff_lab_server.py بساز و کد زیر رو داخلش بذار. این سرور فقط روی Loopback گوش می‌ده و برای یه مسیر مشخص، پاسخ ساختگی برمی‌گردونه. اگر پورت 8765 قبلاً توسط برنامه دیگه‌ای اشغال شده بود، می‌تونی یه شماره آزاد انتخاب کنی؛ فقط حتماً همون شماره رو در کلاینت و فیلترها هم تغییر بده.

from http.server import BaseHTTPRequestHandler, HTTPServer

HOST = "127.0.0.1"
PORT = 8765
MARKER = "NABEGHEHA-LOCAL"

class LabHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path != f"/demo?note={MARKER}":
            self.send_error(404)
            return

        body = f"lab-ok:{MARKER}".encode("utf-8")
        self.send_response(200)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def log_message(self, format, *args):
        pass

if __name__ == "__main__":
    print(f"Local lab: http://{HOST}:{PORT}", flush=True)
    HTTPServer((HOST, PORT), LabHandler).serve_forever()

بعد از ذخیره فایل، ترمینال رو توی همون پوشه باز کن و سرور رو اجرا کن. پنجره رو باز بذار تا منتظر درخواست بمونه. روی ویندوز اگر دستور python شناخته نشد و Python Launcher نصب بود، می‌تونی py sniff_lab_server.py رو امتحان کنی. وقتی کار تموم شد با Ctrl+C برنامه رو متوقف کن. این سرور آموزشی برای دسترسی عمومی یا ارسال اطلاعات واقعی ساخته نشده؛ قرار نیست هیچ مجوز فایروالی برای دسترسی از بیرون بهش بدی.

python sniff_lab_server.py

گام دوم : شروع ضبط محلی قبل از ارسال درخواست

قبل از اجرای کلاینت، Wireshark رو روی Loopback روشن کن و ضبط رو شروع کن. توی نوار نمایش بنویس tcp.port == 8765. اگه هنوز بسته‌ای نمی‌بینی نگران نباش؛ تا وقتی درخواست نفرستی، ممکنه ترافیکی هم برای دیدن نباشه. ترتیب کار مهمه: اول Capture، بعد اجرای درخواست.

گام سوم : ارسال درخواست ساختگی

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

from urllib.request import urlopen

URL = "http://127.0.0.1:8765/demo?note=NABEGHEHA-LOCAL"

with urlopen(URL, timeout=5) as response:
    print(f"status={response.status}")
    print(response.read().decode("utf-8"))

python sniff_lab_client.py

اگه سرور درست اجرا شده باشه، باید خروجی status=200 و متن lab-ok:NABEGHEHA-LOCAL رو ببینی. اما اینجا یه نکته آموزشی مهم داریم: موفق بودن درخواست پایتون با موفق بودن Capture یکی نیست. خروجی فقط نشون می‌ده سرور و کلاینت به هم رسیدن. برای اینکه بگی بسته‌ها ثبت شدن، باید خودت داخل Wireshark هم اون‌ها رو ببینی.

status=200
lab-ok:NABEGHEHA-LOCAL

گام چهارم : متن درخواست رو کجا ببینیم؟

برای دیدن نتیجه شنود شبکه، برگرد به Wireshark و بسته‌های مربوط به پورت 8765 رو نگاه کن. اگه رابط و زمان ضبط درست باشن، ترافیک TCP آزمایش رو می‌بینی. شاید چون پورت غیرمعمول انتخاب کردیم، برنامه همه بسته‌ها رو خودکار با نام HTTP نشون نده؛ این به معنی خرابی درخواست نیست. می‌تونی بسته حاوی داده رو باز کنی یا از Follow TCP Stream کمک بگیری تا جریان درخواست و پاسخ رو کنار هم ببینی. راهنمای رسمی Follow Stream هم همین کار رو توضیح می‌ده.

برای پیدا کردن متن ساختگی، فیلتر tcp contains "NABEGHEHA-LOCAL" هم به کارت میاد. فقط یادت باشه این فیلتر دنبال تطابق توی داده قابل بررسی بسته‌ها می‌گرده و اگه رشته بین چند قطعه پخش شده باشه یا بسته مربوط ثبت نشده باشه، ممکنه چیزی پیدا نکنی. در اون صورت برگرد به tcp.port == 8765 و جریان TCP رو بررسی کن. خالی بودن نتیجه یه فیلتر به معنی نبود ارتباط نیست.

حالا برای گزارش‌نویسی، اگر واقعاً عبارت رو توی Capture دیدی، بنویس: «در ضبط Loopback خودم، متن ساختگیِ درخواست HTTP قابل مشاهده بود.» این جمله هم قابل دفاعه، هم دقیق. اینکه ازش نتیجه بگیری «پس وایرشارک رمز همه کاربران رو نشون می‌ده» هیچ ربطی به شواهد آزمایش نداره.

اگر در شنود شبکه بسته‌ای نمی‌بینم، مشکل کجاست؟

اگه چیزی کار نکرد، اول از خود برنامه‌ها شروع کن. خروجی status=200 رو داری؟ اگر نه و Connection refused می‌بینی، شاید سرور روشن نیست یا شماره پورت رو اشتباه نوشتی. خطای Address already in use هم معمولاً یعنی یه برنامه دیگه روی اون پورت گوش می‌ده؛ نشونه هک شدن سیستم نیست. تا ارتباط محلی سالم نباشه، انتظار Capture درست هم نداشته باش.

بعد از اطمینان از کار کردن درخواست، سراغ رابط ضبط برو. ارتباط 127.0.0.1 معمولاً از Loopback عبور می‌کنه، نه Ethernet یا Wi-Fi. مخصوصاً روی ویندوز، نبود پشتیبانی Npcap می‌تونه باعث بشه نتونی این ترافیک رو ضبط کنی. ضمن اینکه Wireshark باید قبل از درخواست روشن بوده باشه؛ بسته‌های قدیمی رو از هوا برنمی‌گردونه.

آخر سر فیلتر نمایش و فیلتر ضبط رو بررسی کن. ممکنه بسته‌ها ثبت شده باشن ولی Display Filter فعلی پنهانشون کرده باشه؛ یا ممکنه از همون اول با Capture Filter اشتباه، ثبت نشده باشن. برای همین وقتی چیزی پیدا نکردی، دقیق بنویس «با این تنظیمات چیزی مشاهده نشد»؛ نه اینکه «پس هیچ بسته‌ای رد نشده».

آیا Wireshark در شنود شبکه می‌تواند رمز یا پیام‌های HTTPS را بخواند؟

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

البته HTTPS همه مشخصات ارتباط رو نامرئی نمی‌کنه. بسته به پروتکل و تنظیمات، IP، زمان‌بندی، اندازه بسته‌ها و بعضی داده‌های مربوط به اتصال ممکنه دیده بشن. وضعیت نام دامنه هم به نوع DNS، نسخه TLS و قابلیت‌هایی مثل ECH بستگی داره. پس نه شعار «همه‌چیز رو با شنود می‌بینیم» درسته، نه «با HTTPS هیچ چیزی دیده نمی‌شه».

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

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

شنود وای‌فای با شنود شبکه داخلی چه تفاوتی دارد؟

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

روی شبکه کابلی هم داستان همینه. سوییچ معمولاً ترافیک Unicast دستگاه‌های دیگه رو به هر پورت دلخواه نمی‌فرسته. مدیر شبکه ممکنه برای عیب‌یابی یه پورت مانیتورینگ مجاز یا تجهیزات مخصوص داشته باشه؛ اما وصل شدن یه لپ‌تاپ به یه پورت خالی، اون دسترسی رو خودکار ایجاد نمی‌کنه. در تحلیل بسته‌های شبکه، محل Capture از خود ابزار مهم‌تره.

احتمالاً اسم Monitor Mode رو هم شنیدی. این حالت بسته به سخت‌افزار و درایور می‌تونه امکان مشاهده برخی فریم‌های خام وای‌فای رو فراهم کنه، ولی همیشه پشتیبانی نمی‌شه و گاهی اتصال عادی کارت رو هم تغییر می‌ده. برای یادگیری مفهوم Packet Capture لازم نیست سراغ ترافیک دیگران بریم؛ آزمایش Loopback همه چیزی رو که در این مرحله نیاز داریم یاد می‌ده.

آیا ابزار شنود همان ابزار اسکن پورت است؟

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

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

مقایسه Wireshark، tcpdump و TShark در تحلیل ترافیک

وقتی دنبال ابزار شنود شبکه می‌گردی، اسم Wireshark، tcpdump و TShark زیاد میاد. لازم نیست همون روز اول هر سه‌تا رو حرفه‌ای بلد باشی. Wireshark با رابط گرافیکی برای دیدن جزئیات بسته‌ها عالیه؛ tcpdump برای ضبط و فیلتر در ترمینال به کار میاد و TShark ابزار خط فرمان مجموعه Wireshark هست. انتخاب ابزار باید از سؤال شروع بشه، نه از اینکه کدوم اسمش هکری‌تره.

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

شش فیلتر Wireshark برای شروع شنود شبکه

این شش مورد، فیلترهای نمایشی هستن؛ نه همه‌شون فیلتر ضبط. ممکنه بعضی‌ها توی آزمایش فعلی هیچ نتیجه‌ای ندن، چون ما مثلاً DNS یا TLS تولید نکردیم. یک تحلیل‌گر از فیلتر انتظار جادو نداره: فیلتر فقط بین بسته‌هایی می‌گرده که واقعاً ثبت شدن. نحوه نوشتنشون رو هم در راهنمای رسمی Display Filter می‌تونی ببینی.

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

از بسته مشکوک تا یافته امنیتی؛ عجله نکن

حالا فرض کن وسط Capture متن NABEGHEHA-LOCAL رو می‌بینی. آیا یه حفره امنیتی کشف کردی؟ نه؛ این داده رو خودت برای تمرین ساخته بودی. اما شنود شبکه بهت یاد داده چه سؤال‌هایی بپرسی: اگه داده واقعی بود حساس محسوب می‌شد؟ TLS داشت؟ از چه نقطه‌ای دیده شد؟ آیا مشاهده‌گر غیرمجاز هم می‌تونست به همون مسیر دسترسی داشته باشه؟ و کدوم بخش از خطر رو واقعاً ثابت کردیم؟

این دقت فقط برای HTTP نیست. وقتی تعداد زیادی بسته، Retransmission یا خطای اتصال می‌بینی، نمی‌تونی صرفاً با تماشای یک نمودار نتیجه بگیری حمله‌ای رخ داده. باید رفتار برنامه، لاگ‌ها، شرایط شبکه و بازه زمانی رو هم کنار Capture بذاری. خودِ TCP ممکنه به دلایل عادی شبکه دوباره داده بفرسته؛ هر ارسال مجددی نشونه خرابکاری نیست.

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

فایل PCAP در شنود شبکه هم می‌تواند یک مسئله امنیتی باشد

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

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

توی آزمایش این درس رشته‌ها ساختگی‌ان، ولی باز هم خوبه Capture رو با اسم مشخصی مثل loopback-sniffing-lab.pcapng ذخیره کنی. این کار باعث می‌شه چند وقت بعد فایل آموزشی خودت رو با ضبط یه شبکه واقعی اشتباه نگیری. برای محیط واقعی هم همیشه سیاست نگهداری و دسترسی به فایل مهمه.

برای جلوگیری از شنود شبکه چه کارهایی واقعاً مؤثرند؟

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

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

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

تفاوت Packet Sniffing، Man-in-the-Middle و هک وای‌فای

این سه اصطلاح شبیه هم به نظر میان، ولی یکی نیستن. Packet Sniffing یعنی ثبت و تحلیل بسته‌های قابل مشاهده. Man-in-the-Middle به موقعیتی اشاره داره که یک طرف در مسیر ارتباط قرار می‌گیره و بسته به سناریو می‌تونه ترافیک رو مشاهده یا دست‌کاری کنه. «هک وای‌فای» هم یه عبارت کلیه برای ضعف‌های دسترسی و امنیت ارتباط بی‌سیم. بهتره هیچ‌کدوم رو به جای دیگری استفاده نکنیم.

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

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

اشتباه‌های رایج شنود شبکه با Wireshark

اولین اشتباه اینه که درخواست رو به 127.0.0.1 می‌فرستی، ولی روی Wi-Fi ضبط می‌کنی و انتظار داری همون بسته‌ها دیده بشن. دوم اینکه فکر می‌کنی Display Filter بسته‌ها رو از فایل پاک می‌کنه. سوم هم اینه که دیدن ترافیک پورت ۴۴۳ رو مساوی خواندن متن HTTPS می‌دونی. هر سه مورد می‌تونن نتیجه تحلیل رو کاملاً عوض کنن.

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

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

تمرین‌های شنود شبکه؛ این بار فقط نگاه نکن، تحلیل کن

تمرین اول : محل Capture را عوض نکن، فرضیه‌ات را عوض کن

برای تمرین اول، سرور رو روشن کن و قبل از اجرای کلاینت پیش‌بینی کن چه ترافیکی باید روی Loopback ببینی. بعد درخواست رو اجرا کن و نتیجه رو با پیش‌بینی مقایسه کن. حالا روی کاغذ توضیح بده چرا همون بسته‌ها الزاماً روی رابط Wi-Fi دیده نمی‌شن. هدف اینه که مسیر رو بفهمی، نه اینکه با تغییر تنظیمات سراغ ترافیک بیشتری بری.

تمرین دوم : یک مشاهده و دو محدودیت بنویس

وقتی متن NABEGHEHA-LOCAL رو واقعاً دیدی، یه جمله دقیق بنویس؛ مثلاً «متن ساختگی در جریان HTTP محلی ضبط شد». بعد دو محدودیت هم کنارش بذار: ارتباط بدون TLS بود و محل ضبط فقط Loopback خود دستگاه بود. همین دو جمله نشون می‌دن نتیجه رو بیشتر از شواهدت بزرگ نکردی.

تمرین سوم : فیلترها را با هم مقایسه کن

این بار tcp.port == 8765 رو با tcp contains "NABEGHEHA-LOCAL" مقایسه کن. تعداد بسته‌هایی که هرکدوم نشون می‌دن یکیه؟ اگه نه، دو دلیل منطقی براش پیدا کن. بعد Display Filter رو پاک کن و ببین بسته‌ها دوباره توی فهرست ظاهر می‌شن. این تمرین بهت نشون می‌ده فیلتر نمایش چیزی رو از فایل پاک نمی‌کنه.

تمرین چهارم : گزارش جشنواره «دالان» را اصلاح کن

فرض کن گزارش جشنواره نوشته «چون وای‌فای مهمان و شبکه داورها توی یه ساختمونن، رأی همه داورها قابل شنوده». بدون انجام هیچ تستی توضیح بده چرا این ادعای شنود شبکه اثبات نشده. چه چیزهایی درباره مسیر ترافیک، جداسازی شبکه، نقطه Capture و HTTPS نمی‌دونیم؟ یه گزارش بهتر بنویس که همین سؤال‌های باز رو روشن کنه.

مسیر بعد از این درس برای یادگیری هک و تست نفوذ شبکه

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

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

سؤالات متداول درباره شنود شبکه و وایرشارک

منابع معتبر برای بررسی بیشتر

برای اینکه گفته‌های این درس رو خودت هم بررسی کنی، از منابع رسمی شروع کن: راهنمای کامل Wireshark، فیلترهای ضبط، فیلترهای نمایش، ضبط ترافیک Loopback و بررسی جریان TCP. جشنواره «دالان» و مدل سه مرز دید مثال‌های آموزشی ساختگی همین مقاله هستن، نه روایت یه رخداد واقعی.

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