همگام‌سازی دقیق زمان یکی از ارکان بنیادی برای کارکرد سیستم‌های توزیع‌شده، پروتکل‌های احراز هویت و اعتبارسنجی‌های رمزنگاری به شمار می‌رود. پروتکل زمان شبکه (Network Time Protocol یا NTP) طبق استاندارد RFC 5905 از سال ۱۹۸۵ ساعت‌های رایانه‌ها را در سراسر اینترنت هماهنگ ساخته است. این پروتکل بر بستر پورت ۱۲۳ پروتکل UDP کار می‌کند و با تبادل بسته‌های سبک، دقتی کمتر از میلی‌ثانیه نسبت به ساعت هماهنگ جهانی (UTC) فراهم می‌آورد.

با این وجود، از آنجا که نسخه سنتی NTP فاقد احراز هویت در سطح لایه انتقال است و بر بستر بدون اتصال UDP اجرا می‌شود، آسیب‌پذیری‌های امنیتی چشمگیری دارد. مهاجمان سایبری با سوءاستفاده از دستورهای مدیریتی قدیمی، حملات گسترده منع سرویس توزیع‌شده از نوع بازتابی (DrDoS) را سازماندهی می‌کنند. علاوه بر این، تبادل بدون رمزنگاری بسته‌های زمانی به مهاجمان اجازه می‌دهد ساعت سیستم قربانی را دستکاری کرده و به فروپاشی اعتبارسنجی گواهی‌های TLS، بلیت‌های احراز هویت کربروس و کدهای یکبارمصرف TOTP دامن بزنند.

بررسی امنیت NTP نیازمند تحلیل ضریب تقویت حجم ترافیک با دستور monlist، پیامدهای مخرب انحراف ساعت و ساختار استاندارد امنیت زمان شبکه (NTS بر پایه RFC 8915) است.

سازوکار دستور Monlist و تقویت ۵۵۶ برابری ترافیک

حملات تقویت NTP بر پایه الگوی بازتاب ترافیک توزیع‌شده عمل می‌کنند. مهاجم از دو ویژگی پروتکل بهره می‌گیرد: امکان جعل نشانی IP مبدا در پروتکل UDP و یک فرمان تشخیصی نامتقارن به نام monlist.

مهاجم (جعل نشانی IP عمومی قربانی)
       |
       |  (درخواست تک‌بسته‌ای ۲۳۴ بایتی: Mode 7 "monlist")
       v
+-------------------------------+
| سرور باز NTP دارای آسیب‌پذیری |  (سرویس ntpd فهرست کلاینت‌ها را استخراج می‌کند)
+-------------------------------+
       |
       |  (تا ۱۰۰ بسته پاسخی UDP: حدود ۴۸٬۰۰۰ بایت)
       v
مقصد هدف (میزبان قربانی / پهنای باند مسدودشده)

۱. تحلیل فنی دستور Monlist

در نسخه‌های قدیمی نرم‌افزار مرجع ntpd (پیش از نسخه 4.2.7p26)، پروتکل از پرس‌وجوهای مدیریتی Mode 7 پشتیبانی می‌کرد. در این میان، دستور monlist به سرور فرمان می‌داد حافظه موقت خود شامل نشانی‌های IP آخرین ۶۰۰ کلاینتی را که با سرور ارتباط گرفته بودند، بازگرداند:

۱. مهاجم یک بسته سبک UDP با اندازه ۲۳۴ بایت به پورت ۱۲۳ سرور عمومی NTP ارسال می‌کند. ۲. نشانی IP فرستنده در سرآیند بسته دستکاری شده و با نشانی IP قربانی جایگزین می‌گردد. ۳. از آنجا که داده‌های ۶۰۰ کلاینت در یک بسته منفرد جا نمی‌گیرد، سرور ناچار به قطعه‌بندی پاسخ می‌شود. ۴. سرور تا ۱۰۰ بسته متوالی UDP ارسال می‌کند که هر یک حدود ۴۸۰ بایت اطلاعات دارند. ۵. مجموع ترافیک بازتابی ارسالی به سوی قربانی بین ۴۸٬۰۰۰ تا ۵۲٬۰۰۰ بایت خواهد بود.

$$\text{ضریب تقویت} = \frac{\text{حجم پاسخ (بایت)}}{\text{اندازه درخواست (بایت)}} = \frac{48000}{234} \approx ۲۰۵.۱ \text{ تا } ۵۵۶\text{ برابر}$$

هنگامی که صدها سرور NTP به طور همزمان هدف این درخواست‌ها قرار گیرند، مهاجم با پهنای باند خانگی ۱۰ مگابیت می‌تواند سیل ترافیکی به حجم ۲ تا ۵ گیگابیت بر ثانیه را به سمت هدف سرازیر سازد.

بردار حمله بازتابی اندازه معمول درخواست حجم داده پاسخی ضریب تقویت ترافیک
سامانه DNS (با EDNS0 و ANY) ۴۵ تا ۶۵ بایت ۳٬۰۰۰ تا ۴٬۲۰۰ بایت حدود ۷۰ برابر
پروتکل SSDP ۱۰۰ بایت ۳٬۰۰۰ بایت حدود ۳۰ برابر
حمله NTP Monlist (کد CVE-2013-5211) ۲۳۴ بایت ۴۸٬۰۰۰ تا ۵۲٬۰۰۰ بایت ۲۰۵ تا ۵۵۶ برابر
پایگاه داده Memcached ۱۵ بایت ۷۵۰٬۰۰۰ بایت حدود ۵۰٬۰۰۰ برابر

حملات انحراف زمان: فروپاشی لایه‌های رمزنگاری

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

تغییر زمان سیستم به اندازه چند ساعت، چند روز یا چند سال، لایه‌های امنیتی سیستم‌عامل را بی‌اثر می‌کند:

۱. از کار افتادن اعتبارسنجی گواهی‌های TLS / X.509

مرورگرها و سیستم‌عامل‌ها برای تایید اعتبار گواهی‌های وب، بررسی می‌کنند که آیا زمان فعلی سیستم دقیقا میان دو بازه زمانی notBefore و notAfter قرار دارد یا خیر:

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

۲. اختلال در سیستم‌های احراز هویت Kerberos

در شبکه‌های سازمانی مبتنی بر اکتیو دایرکتوری و کربروس (RFC 4120)، اختلاف ساعت میان رایانه‌ها و کنترلر دامنه نباید از ۵ دقیقه (۳۰۰ ثانیه) تجاوز کند. در صورت انحراف زمان فراتر از این آستانه، فرایند صدور بلیت‌های دسترسی با شکست مواجه شده و ورود کاربران ناممکن می‌شود.

۳. بی‌اعتبار شدن رمزهای یکبارمصرف مبتنی بر زمان (TOTP)

کدهای احراز هویت دومرحله‌ای (MFA) طبق استاندارد RFC 6238 بر پایه بازه‌های ۳۰ ثانیه‌ای از زمان سیستم ساخته می‌شوند:

$$T = \left\lfloor \frac{\text{زمان UTC فعلی} - T_0}{T_X} \right\rfloor$$

با تغییر ساعت سیستم، کدهای تولیدشده توسط سرورها رد می‌شوند و کاربر از حساب‌های کاربری خود محروم خواهد شد.

استاندارد امنیت زمان شبکه (NTS، پروتکل RFC 8915)

برای حل این چالش‌های بنیادین، کارگروه IETF در سپتامبر ۲۰۲۰ استاندارد امنیت زمان شبکه (RFC 8915) را تصویب نمود. NTS اعتبارسنجی رمزنگاری‌شده را بدون کاستن از دقت بالای NTP پیاده‌سازی می‌کند.

این استاندارد فرایند امن‌سازی را به دو مرحله تفکیک می‌نماید:

+------------------+                              +------------------+
|    کلاینت NTS    |                              |     سرور NTS     |
+------------------+                              +------------------+
         |                                                 |
         |  ۱. دست‌تکانی TLS 1.3 روی پورت TCP 4460         |
         |<----------------------------------------------->|
         |  ۲. دریافت کلیدهای AEAD و کوکی‌های              |
         |     رمزنگاری‌شده بدون حالت                      |
         |                                                 |
         |  ۳. پرس‌وجوی امن NTP روی پورت UDP 123           |
         |     [بسته NTP + فیلدهای افزونه + کوکی]          |
         |------------------------------------------------>|
         |  ۴. رمزگشایی کوکی، تایید صحت MAC و              |
         |     ارسال پاسخ معتبر همراه با کوکی جدید         |
         |<------------------------------------------------|

۱. فاز نخست: توافق کلیدهای NTS (NTS-KE)

کلاینت ابتدا یک اتصال امن استاندارد TLS 1.3 با پورت TCP 4460 سرور برقرار می‌کند:

  • سرور گواهی X.509 معتبر خود را ارائه می‌دهد.
  • الگوریتم رمزنگاری احرازشده (معمولا AEAD_AES_SIV_CMAC_256) انتخاب می‌شود.
  • سرور ۸ کوکی رمزنگاری‌شده بدون حالت که حامل پارامترهای کلید متقارن هستند به کلاینت تحویل می‌دهد.
  • اتصال TLS بی‌درنگ بسته می‌شود تا منابع پردازشی سرور آزاد گردد.

۲. فاز دوم: تبادل بسته‌های زمانی ایمن

در مراجعات دوره‌ای زمان روی پورت UDP 123:

  • کلاینت فیلدهای افزونه NTS (طبق RFC 7822) را همراه با یک کوکی و کد احراز اصالت پیام (MAC) پیوست می‌نماید.
  • سرور با کلید اصلی خود کوکی را رمزگشایی کرده، کلید AEAD را بازیافته و درستی MAC را تایید می‌کند.
  • پاسخ زمان دقیق همراه با کوکی جدیدی برای درخواست بعدی ارسال می‌شود.
  • مهاجم توانایی جعل یا تقویت ترافیک را نخواهد داشت، زیرا تبادل داده کاملا متقارن و رمزنگاری‌شده است.

امن‌سازی سرویس‌های زمان در لینوکس: Chrony و NTPd

مدیران سامانه‌ها بهتر است سرویس قدیمی ntpd را کنار گذاشته و به نرم‌افزار نوین Chrony با پشتیبانی پیش‌فرض از NTS مهاجرت نمایند.

۱. راه‌اندازی Chrony با تایید هویت NTS

نصب Chrony و تعیین سرورهای معتبر در فایل /etc/chrony/chrony.conf:

# معرفی سرورهای معتبر زمان دارای استاندارد NTS
server time.cloudflare.com iburst nts
server time.nist.gov iburst nts

# ذخیره وضعیت انحراف زمانی
driftfile /var/lib/chrony/chrony.drift

# تنظیم جهشی ساعت در صورت انحراف بیش از ۱ ثانیه در زمان بوت
makestep 1.0 3

# حداکثر سرعت مجاز برای اصلاح تدریجی زمان
maxslewrate 500

# بستن پورت کنترل از راه دور
cmdport 0

راه‌اندازی مجدد و بررسی عملکرد:

sudo systemctl restart chrony
chronyc sources -v
chronyc authdata

۲. بستن نفوذپذیری Monlist در سرویس قدیمی NTPd

در صورت الزام به حفظ ntpd، دسترسی به پرس‌وجوهای مدیریتی را در /etc/ntp.conf مسدود سازید:

# سیاست پیش‌فرض: منع هرگونه درخواست مدیریتی
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# دسترسی کامل فقط برای درگاه داخلی لوپ‌بک
restrict 127.0.0.1
restrict -6 ::1

# غیرفعال‌سازی بخش مانیتورینگ برای مهار آسیب‌پذیری monlist
disable monitor

اعمال تغییرات در سیستم:

sudo systemctl restart ntp
ntpq -c rv

حفاظت ساختاری از همگام‌سازی زمان با WireGuard و معماری VPNRice

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

کپسوله‌سازی بسته‌های NTP در تونل رمزنگاری WireGuard

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

+---------------------------------------------------------------+
|                        رایانه کاربر                           |
|                                                               |
|  پردازش کلاینت NTP (پورت UDP 123)                             |
|         |                                                     |
|         v                                                     |
|  رابط مجازی WireGuard (wg0)                                   |
|  AllowedIPs = 0.0.0.0/0, ::/0 (هدایت تمامی ترافیک)            |
|         |                                                     |
|         v  (رمزنگاری سرتاسری با ChaCha20-Poly1305)            |
|  رابط فیزیکی شبکه (eth0) ---> درگاه امن VPN                   |
+---------------------------------------------------------------+

با اجرای تونل WireGuard: ۱. تمامی بسته‌های ارسالی UDP 123 توسط رابط مجازی (wg0) دریافت می‌شوند. ۲. داده‌های زمانی با الگوریتم ChaCha20-Poly1305 رمزنگاری شده و سپس به شبکه فیزیکی هدایت می‌گردند. ۳. ناظران محلی یا نقاط دسترسی جعلی امکان بازرسی ترافیک یا دستکاری مقادیر زمان را نخواهند داشت.

تدابیر حفاظتی زمان در شبکه VPNRice

شبکه جهانی درگاه‌های VPNRice از اصول حفاظتی پیشرفته بهره می‌برد:

۱. سرورهای همگام با ساعت‌های اتمی سخت‌افزاری: درگاه‌های VPNRice با پروتکل PTP و سامانه‌های ماهواره‌ای GNSS Stratum 1 تنظیم می‌شوند. ۲. پالایش ترافیک ورودی و حذف آسیب‌پذیری‌ها: در تمامی لبه‌های ارتباطی، فیلترینگ BCP 38 اجرا شده و دستورهای ناامن رد می‌شوند. ۳. بازپخش امن در شبکه داخلی: کاربران با پروتکل RiceGuard زمان را از سرورهای اختصاصی داخلی دریافت می‌کنند و از گزند ردیابی انحراف ساعت مصون می‌مانند.

ترکیب استاندارد NTS (طبق RFC 8915) و تونل‌های رمزشده WireGuard مانع از حملات بازتابی و انحراف زمان شده و امنیت سیستم‌ها را تضمین می‌نماید.