هر بسته داده IPv4 که در بستر اینترنت جهانی مبادله می‌شود، شامل یک فیلد ۱۶ بیتی با عنوان شناسه بسته (IP ID) در هدر دودویی خود است. این فیلد در سال ۱۹۸۱ بر اساس استاندارد RFC 791 طراحی شد تا سیستم‌عامل مقصد بتواند قطعات بسته‌های قطعه‌قطعه‌شده (Fragmentation) را که اندازه آن‌ها از سقف MTU مسیر فراتر رفته است بازسازی کند. برای سال‌ها، توسعه‌دهندگان هسته سیستم‌عامل‌ها این ویژگی را با یک متغیر عددی ساده پیاده می‌کردند که با ارسال هر بسته جدید، یک واحد به مقدار آن افزوده می‌شد.

این کاربرد به‌ظاهر ساده، به یکی از ظریف‌ترین آسیب‌پذیری‌های کانال جانبی (Side-Channel) در تاریخ شبکه‌های کامپیوتری تبدیل شد. با بررسی تغییرات ترتیبی مقدار شمارنده IP ID روی یک میزبان ثالث، یک تحلیل‌گر خارجی می‌تواند پورت‌های محافظت‌شده یک سرور راه دور را بدون فرستادن حتی یک بسته با نشانی IP واقعی خود ترسیم کند، ارتباطات خصوصی بین رایانه‌ها را تشخیص دهد و حجم تبادل داده را محاسبه نماید.

استانداردهای جدید، به‌ویژه RFC 6864 و پروتکل‌های رمزنگاری لایه ۳ نظیر WireGuard، ساختار پردازش این شناسه‌ها را به کلی دگرگون کرده‌اند. مطالعه کانال جانبی IP ID اصول بنیادی امنیت انتقال، جداسازی وضعیت در هسته سیستم‌عامل و مهندسی دفاع با تونل‌های امن را روشن می‌سازد.

+-------------------------------------------------------------------------+
|                    مثلث کلاسیک حمله کانال جانبی IDLE SCAN               |
+-------------------------------------------------------------------------+
|                                                                         |
|      ۱. بررسی شناسه زامبی (SYN/ACK)    ۲. بسته جعلی SYN (مبدأ = زامبی)  |
|         IP ID زامبی = 31337               پورت مقصد 443 سرور هدف        |
|      ┌─────────────────────────┐       ┌─────────────────────────┐      |
|      │                         ▼       │                         ▼      |
|   [مهاجم]                   [میزبان زامبی]                 [سرور هدف]   |
|      ▲                         │       ▲                         │      |
|      │                         └───────┼─────────────────────────┘      |
|      ۳. بررسی دوباره (SYN/ACK)         │ پاسخ SYN/ACK هدف به زامبی      |
|         IP ID زامبی = 31339            │ ارسال RST توسط زامبی (افزایش ID)|
|         اختلاف دلتا = 2 -> پورت باز است! └────────────────────────┘     |
+-------------------------------------------------------------------------+

خاستگاه فیلد شناسه در پروتکل IPv4 (RFC 791)

بر مبنای سند فنی RFC 791، چنانچه مسیریاب‌های میانی با بسته‌ای مواجه شوند که از MTU لینک بعدی بزرگ‌تر باشد، باید آن را به چند بخش تفکیک کنند. برای آنکه دستگاه مقصد بتواند قطعات متعلق به بسته‌های گوناگون را با یکدیگر ترکیب نکند، مبدأ یک شناسه ۱۶ بیتی منحصربه‌فرد برای هر بسته مادر در نظر می‌گیرد.

سامانه مقصد جهت بازسازی بسته از اطلاعات چهارگانه زیر بهره می‌برد:

  • نشانی IP مبدأ (Source IP)
  • نشانی IP مقصد (Destination IP)
  • شناسه پروتکل (Protocol ID) (نظیر TCP، UDP یا ICMP)
  • مقدار شناسه (IP ID)

از آنجا که یک متغیر ۱۶ بیتی تنها ۶۵,۵۳۶ مقدار گوناگون را پوشش می‌دهد، سیستم‌عامل‌های نخستین از یک متغیر سرتاسری مشترک در هسته بهره می‌بردند:

// پیاده‌سازی سنتی در هسته: افزایش یکنواخت سراسری
static unsigned short global_ip_id = 0;

void build_ip_header(struct iphdr *iph) {
    iph->id = htons(++global_ip_id);
}

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

کالبدشکافی Idle Scan: پویش پنهان پورت‌ها از طریق میزبان زامبی

در سال ۱۹۹۸، سالواتوره سانفیلیپو (antirez) کشف کرد که شمارنده‌های متوالی IP ID امکان پویش مخفیانه پورت‌ها را فراهم می‌کنند. این روش که Idle Scan نام گرفت (و در Nmap با پارامتر -sI پشتیبانی می‌شود)، به مهاجم اجازه می‌دهد وضعیت پورت‌های یک هدف را بدون ارسال ترافیک با نشانی واقعی خود بررسی نماید.

این فرآیند به سه مؤلفه نیاز دارد:

  1. مهاجم (Attacker): سامانه‌ای که بسته‌ها را هدایت و نتایج را ثبت می‌کند.
  2. میزبان زامبی (Zombie Host): سیستمی متصل به اینترنت که فعالیت پردازشی و ترافیک پس‌زمینه ناچیزی دارد و شمارنده IP ID سراسری دارد.
  3. سرور هدف (Target Server): سامانه‌ای که فایروال و وضعیت گوش دادن پورت‌های آن ارزیابی می‌شود.

کل این روش بر فریب دادن سرور هدف برای پاسخ‌گویی به میزبان زامبی و سپس سنجش تغییرات فیلد IP ID در زامبی استوار است.

مراحل گام‌به‌گام پیاده‌سازی فنی اسکن Idle Scan

پویش هر پورت از طریق سه مرحله هماهنگ اجرا می‌شود:

  1. مرحله ۱ - ثبت مقدار پایه زامبی: مهاجم یک بسته SYN/ACK به میزبان زامبی ارسال می‌کند. از آنجا که زامبی پیش‌تر نشستی نداشته، یک بسته RST حاوی شناسه فعلی خود پس می‌فرستد ($IPID_1 = 1000$).
  2. مرحله ۲ - ارسال بسته دستکاری‌شده به هدف: مهاجم یک بسته خام SYN به پورت مورد نظر هدف می‌فرستد اما نشانی مبدأ آن را نشانی میزبان زامبی جعل می‌کند.
  3. مرحله ۳ - ارزیابی تغییرات شمارنده زامبی: مهاجم یک بسته SYN/ACK دیگر به زامبی می‌فرستد تا پاسخ RST دوم را دریافت کرده و مقدار جدید شناسه را بسنجد ($IPID_2$).

تحلیل تغییر وضعیت پورت: پورت‌های باز، بسته و فیلتر شده

تفاضل میان دو مقدار ثبت‌شده ($\Delta = IPID_2 - IPID_1$) نمایانگر وضعیت درونی پورت هدف است:

+-------------------------------------------------------------------------+
|                  جدول تعیین وضعیت پورت با تغییرات شمارنده               |
+-------------------------------------------------------------------------+
| وضعیت پورت هدف    | پاسخ هدف به بسته SYN جعلی         | تغییر زامبی (Δ) |
| :---              | :---                              | :---            |
| باز (OPEN)        | ارسال SYN/ACK به سوی زامبی        | Δ = 2 (پورت باز)|
|                   | زامبی بسته RST می‌فرستد (مصرف ID)                   |
| بسته (CLOSED)     | ارسال RST به سوی زامبی            | Δ = 1 (بسته)    |
|                   | زامبی بسته RST را نادیده می‌گیرد                    |
| فیلترشده (FILTER) | بسته بدون پاسخ توسط فایروال رد شد | Δ = 1 (بدون     |
|                   | زامبی هیچ پاسخی دریافت نمی‌کند     |       پاسخ)     |
+-------------------------------------------------------------------------+
  • پورت باز ($\Delta = 2$): سرور هدف تقاضای ارتباط را پذیرفته و بسته SYN/ACK را برای زامبی می‌فرستد. زامبی با دریافت بسته ناخواسته، بلافاصله RST می‌فرستد که باعث افزایش شمارنده IP ID آن می‌شود. در مرحله سوم، مقدار شناسه ۲ واحد جلوتر از مقدار ابتدایی خواهد بود.
  • پورت بسته یا فیلترشده ($\Delta = 1$): اگر پورت بسته باشد، هدف بسته RST می‌فرستد که زامبی پاسخی به آن نمی‌دهد. اگر پورت توسط فایروال فیلتر شود، هیچ داده‌ای فرستاده نمی‌شود. در هر دو حالت، زامبی ترافیک خروجی جدیدی تولید نمی‌کند و شمارنده تنها یک واحد به‌واسطه پیام سوم خود مهاجم زیاد می‌شود.

گزارش‌های ثبت وقایع فایروال هدف صرفاً نشانی زامبی را ثبت کرده و هویت واقعی سیستم پویش‌گر پنهان باقی می‌ماند.

تخمین حجم ترافیک و ردیابی میزبان‌ها در شبکه‌های مجزا

پیامدهای کانال جانبی IP ID فراتر از پویش پورت‌ها گسترش می‌یابد:

  1. ارزیابی نرخ تبادل داده سرور: با ارسال درخواست‌های متناوب به یک سرور، ناظر خارجی می‌تواند سرعت ارسال داده‌ها را ثبت کند و از این راه زمان تهیه نسخه‌های پشتیبان یا نشست‌های کاری را تخمین بزند.
  2. کشف ارتباطات درونی شبکه: اگر دو دستگاه در شبکه محلی بدون پروتکل‌های امن به تبادل داده بپردازند، جهش‌های متقارن شمارنده‌های IP ID ارتباط مستقیم آن‌ها را اثبات می‌کند.
  3. شناسایی اثر انگشت تجهیزات: در گذشته برخی سخت‌افزارهای شبکه از مقادیر اولیه معینی برای شمارنده‌ها استفاده می‌کردند که امکان ردیابی پیوسته دستگاه را بین شبکه‌های مختلف فراهم می‌ساخت.

استانداردسازی RFC 6864: حذف شناسه IP ID در دیتاگرام‌های اتمی

کارگروه مهندسی اینترنت (IETF) برای حل این نقص فنی، سند RFC 6864: Updated Specification of the IPv4 ID Field را در سال ۲۰۱۳ تصویب کرد.

این استاندارد واقعیت زیرساخت‌های مدرن را در نظر گرفت: سیستم‌های امروزی از سازوکار کشف MTU مسیر (PMTUD, RFC 1191) بهره می‌برند و پرچم عدم قطعه‌بندی (DF = 1) را روی تقریباً تمامی ترافیک‌های TCP و UDP تنظیم می‌کنند. بسته‌هایی که با DF = 1 ارسال می‌شوند و نیاز به قطعه‌بندی ندارند، دیتاگرام‌های اتمی (Atomic Datagrams) نامیده می‌شوند.

سند RFC 6864 قوانین زیر را الزام کرد:

  • صفر کردن فیلد شناسه: دستگاه‌های فرستنده مجاز و تشویق هستند که مقدار فیلد IP ID را در کلیه بسته‌های اتمی برابر با 0x0000 قرار دهند.
  • معافیت دستگاه گیرنده: سیستم‌عامل مقصد نباید برای بسته‌هایی که پرچم DF = 1 دارند، مقادیر متوالی یا یکتای IP ID را مطالبه کند.
  • منسوخ شدن شمارنده‌های سراسری: هسته سیستم‌عامل نباید از یک متغیر مشترک سراسری برای ارتباط با مقصدهای ناوابسته استفاده کند.
+-------------------------------------------------------------------------+
|                  ساختار بسته اتمی بر پایه استاندارد RFC 6864            |
+-------------------------------------------------------------------------+
|  هدر IPv4:                                                              |
|  [ Version: 4 ] [ IHL: 5 ] [ DSCP/ECN ] [ Total Length: 1500 ]          |
|  [ Identification: 0x0000 ] <--- استاندارد: تنظیم روی صفر برای اتمی     |
|  [ Flags: DF=1, MF=0 ] [ Fragment Offset: 0 ]                           |
|  [ TTL: 64 ] [ Protocol: 6 (TCP) ] [ Header Checksum ]                  |
|  [ Source IP ] [ Destination IP ]                                       |
+-------------------------------------------------------------------------+

سازوکارهای دفاعی در سیستم‌عامل‌های نوین: پیاده‌سازی در لینوکس و BSD

سیستم‌عامل‌های امروزی فیلد IP ID را از شمارنده‌های عمومی کاملاً منفک کرده‌اند.

جداول هش مجزا برای هر سوکت و تولید شبه‌تصادفی PRNG

پشته‌های شبکه به سوی ایزوله‌سازی وضعیت حرکت کرده‌اند:

  • هسته لینوکس: به‌طور پیش‌فرض مقدار iph->id = 0 را برای بسته‌های اتمی لحاظ می‌کند. برای بسته‌های نیازمند قطعه‌بندی، لینوکس با استفاده از الگوریتم هش siphash نشانی مبدأ، مقصد، پروتکل و یک کلید داخلی را ترکیب نموده و شمارنده را به‌صورت تفکیک‌شده برای هر مقصد مستقل پیش می‌برد.
  • سامانه‌های BSD و macOS: با به‌کارگیری مولدهای شبه‌تصادفی با امنیت بالا (PRNG)، برای هر نشست ارتباطی دنباله‌ای کاملاً تصادفی تولید می‌کنند که قابل پیش‌بینی نیست.
  • سیستم‌های ویندوز: از ویندوز ۱۰ و ویندوز سرور ۲۰۱۶ به بعد، سازوکار سنتی کنار گذاشته شد و شناسه‌ها به‌صورت شبه‌تصادفی مستقل ایجاد می‌شوند.

چگونگی خنثی‌سازی نشت‌های IP ID توسط تونل‌های لایه ۳ و RiceGuard

شبکه‌های امن مجازی در لایه ۳ و با رابط TUN (نظیر WireGuard) مصونیت ساختاری کاملی در برابر نشت‌های کانال جانبی ارائه می‌دهند.

زیرساخت VPNRice بر مبنای رمزنگاری پیشرفته و اصول کپسوله‌سازی شبکه توسعه یافته است. در بستر پروتکل RiceGuard، کلیه داده‌های کاربران پیش از ورود به شبکه‌های عمومی درون بسته‌های UDP معتبر قرار می‌گیرند.

+-------------------------------------------------------------------------+
|              بسته‌بندی RICEGUARD و جداسازی فیلد شناسه IP ID              |
+-------------------------------------------------------------------------+
|  پشته محلی سیستم‌عامل کلاینت:                                           |
|  [ بسته IP داخلی: ارتباط با مقصد | مقدار IP ID توسط هسته محلی ]         |
|                              │                                          |
|                              ▼                                          |
|  موتور تونل RiceGuard:                                                  |
|  [ بار رمزنگاری‌شده ChaCha20-Poly1305 (پنهان‌سازی کامل هدر داخلی) ]      |
|                              │                                          |
|                              ▼                                          |
|  ترافیک فیزیکی خروجی در شبکه:                                           |
|  [ هدر خارجی IPv4: بسته UDP | مقدار خارجی IP ID = 0x0000 (RFC 6864) ]   |
+-------------------------------------------------------------------------+

پروتکل RiceGuard خطرات کانال‌های جانبی را با سه سازوکار مهار می‌کند:

  1. رمزگذاری کامل هدرها: هدر درونی IPv4 و شناسه اصلی آن درون داده‌های رمزنگاری‌شده پنهان شده و توسط ناظران مسیر قابل خواندن نیست.
  2. پیروی بیرونی از RFC 6864: بسته‌های خروجی تونل همواره پرچم DF = 1 را فعال کرده و فیلد شناسه خارجی را روی 0x0000 ثابت نگه می‌دارند، بنابراین هیچ اختلاف محاسباتی پدید نمی‌آید.
  3. رد بسته‌های جعلی با کلید عمومی: سرورها پیش از هر واکنشی امضای کلیدهای عمومی را ارزیابی می‌کنند؛ بسته‌های جعلی در مرحله ورود بی‌صدا حذف می‌شوند و تغییری در وضعیت پشته ایجاد نمی‌کنند.

کاربرانی که تمایل به محافظت از تبادلات شبکه خود دارند می‌توانند برنامه رسمی را از صفحه دانلود VPN دریافت نمایند.

آزمایش عملی: شناسایی میزبان‌های زامبی آسیب‌پذیر با Nmap

متخصصان شبکه می‌توانند آسیب‌پذیری سرورها در برابر تکنیک Idle Scan را با استفاده از ابزار Nmap بررسی کنند:

# ارزیابی ترتیبی بودن الگوی تولید شناسه‌های بسته در سرور
nmap -p 80,443 --script ipidseq 198.51.100.25

# خروجی در صورت آسیب‌پذیر بودن:
# Host script results:
# |_ipidseq: Incremental! (مستعد استفاده به عنوان زامبی در Idle Scan)

# خروجی امن بر پایه استاندارد RFC 6864:
# Host script results:
# |_ipidseq: All zeros! (ایمن: منطبق با استاندارد RFC 6864)

اگر نتیجه برابر با Incremental باشد، آزمونگران می‌توانند عملکرد آن را در آزمایشگاه‌های مجاز بسنجند:

# آزمایش پویش پورت با بهره‌گیری از میزبان زامبی
nmap -Pn -sI 198.51.100.25:80 203.0.113.50

در صورتی که سامانه هدف از قواعد نوین پیروی کند، Nmap خطای زیر را صادر می‌کند: Cannot use zombie host: IP ID sequence is not incremental.

مقایسه معماری: شمارنده سرتاسری در برابر تولید تصادفی هش

ویژگی فنی شمارنده افزایشی سراسری جدول هش به تفکیک مقصد مقدار ثابت صفر RFC 6864 (RiceGuard)
استفاده به عنوان زامبی آسیب‌پذیر ایمن (جداسازی وضعیت) کاملاً ایمن (بدون شناسه پویا)
تخمین نرخ ترافیک برای بیگانگان میسر است برای اشخاص ثالث غیرممکن برای اشخاص ثالث غیرممکن
ردیابی سخت‌افزار بالا (به دلیل زنجیره متوالی) بسیار ناچیز صفر (فیلد ایستا)
پشتیبانی از قطعه‌بندی کامل کامل (از طریق جدول هش) کامل از طریق PMTUD
مصرف حافظه هسته ۲ بایت متغیر ساده متوسط (حافظه جدول نشست‌ها) صفر (مقدار ثابت)
بار پردازشی پردازنده حداقل (++counter) اندک (محاسبه هش سریع) حداقل (مقدار پیش‌فرض 0x0000)

گذار به IPv6: حذف بنیادین شناسه از هدر اصلی پروتکل

راهکار زیرساختی دائمی برای برطرف ساختن نشت IP ID با پیدایش IPv6 (RFC 8200) به سرانجام رسید.

از آنجا که سهم قطعه‌بندی بسته‌ها در اینترنت کنونی به کمتر از یک‌هزارم رسیده، طراحان IPv6 فیلد شناسه را به کل از هدر ثابت ۴۰ بایتی حذف کردند. در IPv6، روترهای میانی حق قطعه‌قطعه کردن بسته‌ها را ندارند؛ این فرآیند تنها در سیستم مبدأ و به‌واسطه هدر اختیاری قطعه‌بندی (Fragment Extension Header) صورت می‌گیرد:

+-------------------------------------------------------------------------+
|                  هدر استاندارد IPV6: عاری از فیلد شناسه ثابت             |
+-------------------------------------------------------------------------+
|  هدر پایه ثابت IPv6 (اندازه ۴۰ بایت):                                   |
|  [ Version: 6 ] [ Traffic Class ] [ Flow Label: 20 bits ]               |
|  [ Payload Length: 16 bits ] [ Next Header: 6 (TCP) ] [ Hop Limit: 64 ] |
|  [ Source IPv6 Address: 128 bits ]                                      |
|  [ Destination IPv6 Address: 128 bits ]                                 |
|                                                                         |
|  * هیچ فیلد شناسه‌ای در هدر اصلی وجود ندارد! *                          |
+-------------------------------------------------------------------------+

از آنجا که بسته‌های اتمی در IPv6 این هدر کمکی را ندارند، هیچ فیلدی برای مشاهده تفاضل باقی نمی‌ماند و روش پویش Idle Scan در شبکه‌های IPv6 به لحاظ ساختاری غیرممکن است.

چک‌لیست مدیران سیستم برای مقابله با کانال‌های جانبی IP ID

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

  1. اعمال استاندارد RFC 6864: به‌کارگیری هسته‌های لینوکس نسخه ۴ به بعد برای تضمین صفر بودن فیلد شناسه در بسته‌های اتمی.
  2. فعال نگه داشتن PMTUD: باز گذاشتن پیام‌های ICMP Type 3 Code 4 در فایروال‌ها برای جلوگیری از بروز اختلال در تبادل قطعات.
  3. مسدودسازی بسته‌های جعلی (BCP 38): فعال‌سازی بررسی مسیر برگشت (uRPF) روی روترهای لبه شبکه برای جلوگیری از ارسال ترافیک با نشانی‌های دستکاری‌شده.
  4. ایزوله‌سازی با تونل‌های لایه ۳: هدایت ترافیک میان سرورها از طریق تونل‌های RiceGuard جهت پنهان‌سازی اطلاعات بسته‌ها.
  5. ارتقای سامانه‌های کهنه: خارج کردن سرورها و تجهیزات جانبی قدیمی که هنوز از شمارنده‌های سراسری استفاده می‌کنند.

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