امنیت زمان شبکه در عمل: راهنمای دفاعی NTS برای NTP و chrony

چرا ساعت دقیق، دارایی امنیتی است؟

زمان شبکه برای ثبت رویداد، اعتبار گواهی، هم‌بستگی لاگ‌ها و سامانه‌های توزیع‌شده مهم است. اگر پاسخ NTP در مسیر تغییر کند، ترتیب رویدادها و تصمیم‌های وابسته به زمان آسیب می‌بیند؛ اما تأخیر، نامتقارن‌بودن مسیر و رانش نوسان‌ساز محلی همچنان خطای اندازه‌گیری می‌سازند. هدف NTS در RFC 8915 اصالت پیام است، نه حذف فیزیک مسیر.

RFC 8915 در سپتامبر ۲۰۲۰ منتشر شده و NTS را فقط برای حالت client-server در NTPv4 مشخص می‌کند، نه symmetric peer، broadcast یا control. احراز و تمامیت بسته با کیفیت تخمین زمان یکی نیست: پاسخ معتبر ممکن است به‌علت تأخیر زیاد، اندازه‌گیری بدی باشد.

معماری دو مرحله‌ای: NTS-KE و NTP امن

NTS دو زیرپروتکل نسبتاً مستقل دارد. در مرحله نخست، NTS Key Establishment یا NTS-KE روی TCP پورت 4460 اجرا می‌شود. کلاینت با سرور TLS دست‌دادن انجام می‌دهد، شناسه ALPN برابر ntske/1 را پیشنهاد می‌کند و سرور آن را می‌پذیرد. RFC تصریح می‌کند که TLS کمتر از نسخه 1.3 نباید مذاکره شود، استفاده از ALPN برای قابلیت همکاری الزامی است و اعتبار هویت سرویس باید با قواعد گواهی X.509 و تطبیق نام سرویس بررسی شود. پس از دست‌دادن، کلاینت یک درخواست و سرور یک پاسخ را در کانال محافظت‌شده می‌فرستند؛ پیام‌ها با رکورد End of Message تمام می‌شوند و کانال با close_notify بسته می‌شود.

در همان پاسخ، پروتکل بعدی، الگوریتم AEAD، یک یا چند کوکی و در صورت نیاز نشانی یا پورت سرور NTP اعلام می‌شود. اگر پورت NTP در مذاکره اعلام نشود، مقدار پیش‌فرض UDP پورت 123 است. اگر نشانی سرور NTP اعلام نشود، کلاینت باید به سروری در همان نشانی IP سرور NTS-KE متصل شود. این جداسازی برای سازمان مهم است: نقطه TLS می‌تواند در لبه شبکه باشد، در حالی که سرویس NTP در شبکه داخلی قرار گیرد؛ اما در این حالت سرورها باید کوکی‌ها و اسرار لازم را طبق سازوکار پیاده‌سازی خود هماهنگ کنند.

پس از TLS، کلیدها با TLS exporter و HKDF استخراج می‌شوند و برچسب دقیق EXPORTER-network-time-security را دارند. برای NTPv4 کلید C2S و S2C جداست. سرور NTS باید AEAD_AES_SIV_CMAC_256 با شناسه 15 را پشتیبانی کند؛ اگر کلاینت آن را عرضه و NTPv4 پذیرفته شود، پاسخ الگوریتمی نمی‌تواند خالی باشد.

کوکی، حالت بی‌حالت و AEAD

کوکی NTS گذرنامه‌ای رمزنگاری‌شده برای بازیابی وضعیت است، نه توکنی که کلاینت بتواند محتوای آن را بخواند. سرور با کوکی می‌تواند الگوریتم مذاکره‌شده و کلیدهای C2S و S2C را به دست آورد، بدون آن‌که برای هر کلاینت رکورد نشست جداگانه نگه دارد. قالب پیشنهادی RFC غیرالزامی است: سرور کلید اصلی AEAD و شناسه آن را نگه می‌دارد، متن شامل الگوریتم و دو کلید جهت‌دار را رمز می‌کند و کوکی از سه‌تایی شناسه، nonce و خروجی رمز تشکیل می‌شود. بنابراین این قالب را نباید با تنها قالب مجاز اشتباه گرفت؛ خود RFC، قالب کوکی را implementation-defined می‌داند.

چرخش کلید باید میان NTS-KE، NTP و کلاسترها هماهنگ باشد. RFC تولید دوره‌ای کلید تازه و نگه‌داری محدود کلید قدیمی برای گذار را پیشنهاد می‌کند. در chrony 4.7، ntsrotate برای کلید کوکی است، مقدار پیش‌فرض مستندشده یک هفته است و دو کلید قبلی نگه داشته می‌شود؛ ntsrotate 0 مدیریت بیرونی را لازم می‌کند. این عدد الزام RFC نیست.

AEAD تغییر را تشخیص می‌دهد و بخش منتخب را محرمانه می‌کند. سرآیند معمول ۴۸ اکتتی NTP رمز نمی‌شود؛ داده همراه از ابتدای سرآیند تا آخرین فیلد پیش از Authenticator است و nonce و ciphertext تا مرز چهار اکتت هم‌تراز می‌شوند. chrony 4.7 شناسه‌های 15، AES-SIV-CMAC-256، و 30، AES-128-GCM-SIV، را با ترتیب پیش‌فرض 30 15 مستند کرده است؛ پشتیبانی شناسه 15 الزام RFC برای سرور است.

ضدبازپخش، حریم خصوصی و اندازه پاسخ

درخواست NTS کلاینت دقیقاً یک Unique Identifier تصادفی و دست‌کم ۳۲ اکتتی دارد. سرور همان مقدار را در پاسخ برمی‌گرداند. کلاینت باید شناسه را با یک درخواست بازِ خود تطبیق دهد و پاسخ فاقد اعتبار NTS را دور بیندازد؛ بنابراین یک پاسخ قدیمی یا پاسخ جعلی خارج از مسیر نباید مبنای تنظیم ساعت شود. کوکی ارسالی کلاینت احراز می‌شود اما رمز نمی‌شود تا سرور بتواند با آن کلیدها را بازیابی کند؛ کوکی‌هایی که سرور در پاسخ می‌دهد باید درون بخش رمزنگاری‌شده باشند تا قابلیت پیوندزدن رفت‌وآمدها کاهش یابد.

کلاینت بهتر است کوکی مصرف‌نشده را دوباره استفاده نکند؛ اگر کوکی نماند، NTS-KE دوباره اجرا می‌شود، هرچند RFC برای دسترس‌پذیری اجازه تعادل میان unlinkability و استفاده مجدد را می‌دهد. placeholderها باید هم‌اندازه کوکی باشند تا پاسخ بزرگ‌تر از درخواست نشود و سرویس تقویت‌کننده DDoS نگردد؛ هم‌ترازی چهار اکتتی ممکن است اختلاف ناچیزی ایجاد کند.

NTS حذف یا تأخیر بسته را حل نمی‌کند و KoD جعلی می‌تواند بار NTS-KE را بالا ببرد. کد NTSN برای NTS NAK است، اما هر خطا به‌تنهایی نشانه اصالت کامل نیست. افشای کلید اصلی کوکی امکان جعل سرور و تولید کوکی می‌دهد؛ باید کلید آلوده حذف و چرخانده شود. حمله تأخیر با AEAD آشکار نمی‌شود و به چند منبع و پایش offset نیاز دارد.

راه‌اندازی chrony در کلاینت

در chrony، گزینه nts روی همان خط server یا pool احراز NTS را فعال می‌کند. نامی که در این خط می‌آید، سرور NTS-KE یا مجموعه آن است؛ سرور NTP معمولاً همان میزبان است، مگر پاسخ KE مقصد دیگری بدهد. اگر اتصال با IP انجام شود، IP باید در SAN گواهی سرور وجود داشته باشد. نمونه پایه زیر عمداً از نام دامنه استفاده می‌کند تا اعتبارسنجی نام سرویس روشن بماند:

server time.example.org iburst nts
ntsdumpdir /var/lib/chrony
ntsaeads 30 15
ntstrustedcerts /etc/pki/nts/ca.example.org.crt
makestep 0.1 3
driftfile /var/lib/chrony/drift
log measurements statistics tracking
logdir /var/log/chrony
logchange 0.1

iburst در شروع ۴ تا ۸ درخواست می‌فرستد و جایگزین کاهش دائمی poll نیست. ntsdumpdir کوکی‌ها را ذخیره می‌کند تا restart الزاماً به NTS-KE تازه نیاز نداشته باشد؛ پیش‌فرض ذخیره‌سازی خاموش است. ntsrefresh بیشینه فاصله دست‌دادن را تعیین می‌کند؛ پیش‌فرض مستندشده چهار هفته است و باید از poll همه منابع NTS طولانی‌تر باشد.

برای CA سازمانی یا خودامضا، ntstrustedcerts و در صورت نیاز certset را تنظیم کنید؛ مجموعه صفر CAهای سیستم را دارد مگر nosystemcert فعال باشد. ساعت غلط می‌تواند گواهی معتبر را منقضی یا هنوز معتبرنشده نشان دهد؛ بررسی زمان را دائمی خاموش نکنید و اصلاح اولیه را کنترل‌شده انجام دهید.

راه‌اندازی سرور و تفکیک نقش‌ها

برای تبدیل chronyd به NTS-KE/NTP server، ntsservercert فایل گواهی PEM و زنجیره میانی مورد نیاز مشتریان را معرفی می‌کند و ntsserverkey کلید خصوصی متناظر را می‌دهد. تعداد کلیدها و گواهی‌ها و ترتیبشان باید یکسان باشد و کلید برای کاربران دیگر قابل خواندن نباشد. ntsport پورت TCP سرویس KE را تعیین می‌کند و پیش‌فرض آن 4460 است؛ این پورت فقط وقتی باز می‌شود که گواهی و کلید مشخص شده باشند. port پورت NTP را تعیین می‌کند و پیش‌فرض آن UDP 123 است. برای جداسازی KE از NTP، ntsntpserver نام یا نشانی NTP را در پاسخ معرفی می‌کند، اما هر دو نقش باید کلیدهای کوکی را هماهنگ کنند.

یک نمونه سرور داخلی می‌تواند چنین باشد:

server upstream.example.org iburst nts
ntsservercert /etc/pki/chrony/nts-server.crt
ntsserverkey /etc/pki/chrony/nts-server.key
ntsdumpdir /var/lib/chrony
ntsrotate 604800
ntsaeads 30 15
port 123
ntsport 4460
allow 10.20.0.0/16
ratelimit interval 1 burst 16
ntsratelimit interval 3 burst 1
log measurements statistics tracking
logdir /var/log/chrony

در این سناریو، allow دسترسی سروری را به شبکه مجاز محدود می‌کند. ratelimit پاسخ NTP و ntsratelimit درخواست KE را محدود می‌کنند؛ فاصله پیش‌فرض KE یک اتصال در ۶۴ ثانیه است. ntsprocesses و maxntsconnections برای ظرفیت‌سنجی‌اند، نه جایگزین فایروال و اعتبارسنجی گواهی.

رانش ساعت و روش ارزیابی

driftfile نرخ gain یا loss ساعت را بر حسب قسمت در میلیون و برآورد خطای آن ذخیره می‌کند؛ chronyd بعد از راه‌اندازی می‌تواند از این تخمین برای شروع بهتر استفاده کند. مثلاً مقدار 100 ppm در مستندات به معنای کسب ۱۰۰ میکروثانیه در هر ثانیه پیشروی ساعت نسبت به زمان واقعی توضیح داده شده است. makestep 0.1 3 در مثال رسمی می‌گوید اصلاح بزرگ‌تر از ۰٫۱ ثانیه فقط در سه به‌روزرسانی نخست با جهش انجام شود؛ بعد از آن، اصلاح تدریجی از پرش ناگهانی که ترتیب رویدادها را برهم می‌زند، مناسب‌تر است.

برای ارزیابی، زنجیره اعتماد را جدا از دقت بسنجید: نام و SAN گواهی، CA، TLS 1.3 یا بالاتر، ALPN ntske/1 و دسترسی TCP 4460 و UDP 123. سپس offset، root distance، jitter، دسترسی و وضعیت انتخاب منبع را زیر بار شبکه مقایسه کنید. chrony می‌تواند rawmeasurements، statistics و tracking را در لاگ ثبت کند. logchange هنگام اصلاح بزرگ ساعت پیام syslog می‌دهد؛ پیش‌فرض آستانه یک ثانیه و نمونه رسمی ۰٫۱ ثانیه است.

در آزمون تکرارپذیر، کلاینت را با دو منبع NTS و دو وضعیت بار اجرا کنید و روند drift را نگه دارید. تمدید گواهی مورد اعتماد را جدا آزمایش کنید؛ chrony برای آن restart لازم نمی‌داند، اما گواهی ntsservercert هنگام بارگذاری یک‌باره خوانده می‌شود و برای نسخه تازه restart سرور لازم است. موفقیت فقط synchronized نیست: شکست احراز، NTS NAK، تأخیر، حذف بسته و clock step هم باید دیده شود.

سناریوی سازمانی و محدودیت‌های عملی

فرض کنید مرکز داده یک NTP داخلی در شبکه مدیریت و یک نقطه NTS-KE در لبه دارد. کلاینت با نام مندرج در گواهی به TCP 4460 وصل می‌شود، مقصد NTP را از پاسخ KE می‌گیرد و سپس روی UDP 123 همگام می‌شود. کوکی‌ها در کلاینت و کلیدهای رمزکننده کوکی در گره‌های NTS نگه‌داری می‌شوند؛ ntsdumpdir و مجوز محدود فایل‌ها از طوفان دست‌دادن پس از restart می‌کاهند. پیش از تعادل بار، چرخش کلید و اشتراک آن میان گره‌ها باید آزموده شود.

NTS جعل و تغییر را بهتر از NTP ساده مهار می‌کند، اما منبع زمان نادرست، تأخیر عمدی، قطع مسیر یا رانش سخت‌افزار را درمان نمی‌کند. گواهی معتبر نیز بدون بررسی نام، کافی نیست. افزودن منبع بدون احراز می‌تواند سطح حمله را بالا ببرد؛ require و trust در chrony برای سیاست انتخاب وجود دارند، اما اثرشان بر دقت و تاب‌آوری باید مستند شود. NTS را برای mode 3 و 4 به کار ببرید و پوشش آن را به modeهای دیگر تعمیم ندهید.

مرزبندی عملیاتی و تصمیم‌گیری سنجش‌پذیر

در طراحی دفاعی، هر هشدار باید فرضی آزمودنی داشته باشد: خطای زنجیره‌گواهی به TLS، NTSN به کوکی، root distance به مسیر و drift به نوسان‌ساز یا اصلاح محلی مربوط است. بنابراین موفقیت رمزنگاری را با دقت زمانی یکی نگیرید. هر تغییر الگوریتم، پورت، poll، اعتماد یا چرخش‌کلید باید مالک، پنجره اجرا، معیاربازگشت و نتیجه‌آزمون داشته باشد تا خطای پیکربندی از رخدادمسیر جدا شود.

برگه فشرده ارزیابی:

مرحله۱|TCP/4460|TLS>=1.3|ALPN=ntske/1|X.509|SAN|CA|close_notify|End_of_Message|یک_درخواست_یک_پاسخ
مرحله۲|NTP/UDP/123|mode=3/4|Unique_ID>=32_octets|Cookie|C2S|S2C|AEAD|Authenticator|NTSN
کلاینت|server_nts|ntsdumpdir|ntsaeads=30,15|ntsrefresh=2419200s|driftfile|makestep=0.1/3|log=measurements,statistics,tracking
سرور|ntsservercert|ntsserverkey|ntsdumpdir|ntsrotate=604800s|ntsprocesses|maxntsconnections|allow|ratelimit|ntsratelimit
ارزیابی|گواهی|کوکی|کلید|دسترسی|offset|root_distance|jitter|drift|حذف|تأخیر|restart|بازیابی|ممیزی
مرزاعتماد|هویت_X.509|تمامیت_AEAD|محرمانگی_فیلد|ضدبازپخش_شناسه|بی‌حالت‌بودن_سرور|unlinkability_کوکی|non-amplification_پاسخ|محدودیت_تاخیر|محدودیت_رانش
چرخه‌عمر|NTS-KE|TLS_exporter|HKDF|کلید_C2S|کلید_S2C|کوکی_تازه|چرخش_کلید|کلید_قدیمی|NTS_NAK|retry_rate_limit|گواهی_منقضی
کیفیت‌زمان|round_trip_delay|asymmetry|root_dispersion|root_delay|polling_interval|frequency_error|slew|step|measurement_history|rawmeasurements|statistics|tracking|logchange|measurement_acceptance|source_selection|certificate_time_bootstrap|auditable_change_record|rollback_criteria|postchange_verification

چک‌لیست پیش از بهره‌برداری

• [ ] TCP 4460 و UDP 123 در فایروال ثبت و آزموده شده‌اند.
• [ ] TLS 1.3، ALPN ntske/1، SAN، نام سرویس و زنجیره CA بررسی شده‌اند.
• [ ] ntstrustedcerts، مجوز کلید خصوصی و گواهی‌های دو سوی ارتباط کنترل شده‌اند.
• [ ] همه منابع لازم با nts تعریف و منبع ناشناس حذف شده است.
• [ ] ntsaeads با کتابخانه و مشتریان سازگار است و شناسه 15 حفظ شده است.
• [ ] کوکی، کلید، چرخش، کلیدهای قبلی و بازیابی restart آزمایش شده‌اند.
• [ ] allow، فایروال، ratelimit و ntsratelimit با ظرفیت هماهنگ‌اند.
• [ ] لاگ‌های اندازه‌گیری، tracking، NTS NAK، drift و تغییر ساعت پایش می‌شوند.
• [ ] قطع KE، انقضای گواهی، کوکی نامعتبر، تأخیر و اختلاف منابع تمرین شده‌اند.
• [ ] منشأ عددها ثبت و از CVSS یا نسخه ساختگی پرهیز شده است.

جمع‌بندی این است که NTS با انتقال احراز اولیه به TLS و انتقال اعتبارسنجی سبک به AEAD، NTP را برای مدل client-server قابل دفاع‌تر می‌کند. ارزش آن زمانی کامل می‌شود که کوکی و کلید به‌درستی چرخانده شوند، مقصدها و گواهی‌ها پایش شوند، اندازه پاسخ و نرخ اتصال کنترل شود و drift و تأخیر در کنار وضعیت رمزنگاری اندازه‌گیری شوند. chrony ابزارهای پیکربندی لازم را در اختیار می‌گذارد، اما تصمیم نهایی درباره دقت، افزونگی و واکنش به شکست همچنان بخشی از طراحی عملیاتی سازمان است. مالک، زمان اجرا، معیار بازگشت و نتیجه آزمون هر تغییر ثبت شود.