پیام های NTP (پروتکل زمان شبکه) گاهی اوقات با سرعت محدود می شوند یا به طور کامل توسط اپراتورهای اینترنت مسدود می شوند . این " فیلتر کردن NTP " که چندان شناخته نشده است ، چندین سال پیش در پاسخ به حملات DDoS (انکار سرویس توزیع شده) اجرا شد. فیلتر کردن NTP ممکن است پیام های NTP را بر اساس میزان یا اندازه پیام کاهش دهد. بیایید در آن جستجو کنیم:
من چندین سال است که بر عملکرد سرورهای NTP عمومی نظارت داشته ام. درخواست های زمانی ارسال شده توسط سرویس گیرنده های NTP به چندین دلیل رایج بی پاسخ هستند. سرور ممکن است خراب باشد یا بار بیش از حد داشته باشد. ممکن است درخواست یا پاسخ به دلیل ازدحام شبکه از بین برود. سرور NTP ممکن است ترافیک را کنترل کند ، به خصوص برای مشتریانی که درخواست مکرر دارند. ممکن است سرور به گونه ای پیکربندی شده باشد که فقط درخواستها را براساس محدوده آدرس IP (مثلاً geoblocking) بپذیرد. برخی از ISP ها ، م institutionsسسات آموزشی یا شرکت های بزرگ ، ترافیک NTP را ممنوع یا محدود می کنند. اتصال اینترنت مشتری یا سرور ممکن است بسته های IP بیش از حد در پرواز را ذخیره کند ، که منجر به ایجاد حالت بافر می شود. مدیر یک سرور NTP ممکن است بسیاری از این عوامل را کنترل کند یا حداقل از آنها آگاهی داشته باشد. اپراتور می تواند سرور و شبکه محلی را بررسی کند. آنها می توانند از ISP خود بپرسند که آیا خط مشی "بدون سرور" وجود دارد یا خیر. به هر حال موارد دیگری در این داستان وجود دارد.
Some History of NTP
اینترنت می تواند مکانی غیر دوستانه باشد ، خصوصاً برای برخی از انواع ترافیک. کاربران NTP باید از یک آسیب شبکه عمدی آگاه باشند که اغلب "فیلتر کردن NTP" نامیده می شود و امروزه رخ می دهد. این کاهش عمدی ترافیک NTP توسط اپراتورهای اینترنتی است. ابتدا برخی از تاریخ. هنگامی که NTP برای اولین بار در دهه 1980 توسعه یافت ، نویسنده اصلی آن ، دیوید میلز ، بسیاری از قابلیت های تشخیصی محلی / از راه دور را به پیاده سازی های اولیه اضافه کرد. به عنوان مثال ، یک مشتری NTP می تواند از سرور بالادست NTP اطلاعات دقیق در مورد منابع زمانی سرور را بخواهد. پیام های تشخیصی (پیام 6) و پیام های خصوصی (حالت 7). [The more common NTP client requests are denoted as mode 3, server responses are mode 4.] برخی از تلاش های استاندارد سازی برای پیام های کنترل NTP انجام شد ، اما پیام های خصوصی NTP اینگونه نبود. یک گروه سو abuse استفاده از شبکه حملات انکار سرویس (DDoS) توزیع شده است. مهاجمان از بسیاری از منابع (از این رو "توزیع شده") ترافیک ناخواسته را به سمت مقصد IP ارسال می کنند که به طور بالقوه باعث پهنای باند شبکه دسترسی می شود ، یا سایر حافظه رایانه و سایر منابع را تخلیه می کند. از قابلیت های تشخیصی NTP ، به ویژه گزینه monlist ، اغلب از سال 2013/2014 به عنوان بردار حمله استفاده می شد. مون لیست دو ویژگی داشت که مورد حمله مهاجمان قرار می گرفت. درخواست لیست شامل تنها یک پیام UDP تأیید نشده است. از این رو ، جعل آدرس منبع به راحتی انجام می شد و منبع واقعی DDoS را مخفی می کرد. بدتر از این ، پاسخ لیست به طور معمول بسیار بیشتر از درخواست بود ، این یک حمله تقویت است. این نمودار از Cloudflare نحوه کار حمله monlist را نشان می دهد.
اقدامات متقابل حمله Monlist به توزیع های اصلی نرم افزار NTP اضافه شدند تا سرورهایی که توزیع های به روز شده خود را اجرا می کنند ، در برابر حمله جعلی لیست قرار نگیرند. این زمان برد و هنوز ناقص است. در سال 2020 ، شش سال پس از حملات گسترده ، هزاران سرور NTP با دسترسی عمومی هنوز در معرض حمله monlist قرار دارند.
NTP Filtering
سازمان های مسئول حمل و نقل و امنیت اینترنتی در ISP / IXP حملات افزایش یافته لیست را شناسایی کردند در حدود سال 2014 و راه حل هایی را ایجاد کرد که محدودیت هایی را در ترافیک NTP ایجاد می کند. این را اغلب فیلتر کردن NTP می نامند. دو راه حل عمده بسته به سازمان و تجهیزات موجود توسعه یافته است. یک راه حل ساده ترافیک NTP را بر اساس اندازه پیام محدود می کند. درخواستها و پاسخهای عادی NTP دارای طول 48 بایت هستند در حالی که پاسخهای لیست به طور معمول 440 بایت بودند. یک فیلتر NTP مبتنی بر اندازه که توسط ISP / IXP پیاده سازی شده است می تواند پیام های لیست را مسدود کند در حالی که درخواست ها و پاسخ های عادی را مجاز می داند. این فیلترها هنوز سر جای خود هستند. در ماه مه و ژوئن سال 2020 من چندین هزار سرور را با پیام های NTP با طول متغیر از یک سرویس گیرنده IPv4 متصل به یک سرویس فیبر AT&T در حومه شیکاگو اسکن کردم. نمودار زیر تعداد سرورهای پاسخ دهنده را نشان می دهد. یک قطع سخت در اندازه پیام NTP = 428 بایت قابل مشاهده است و به AT&T مربوط می شود:
برای اسکن مشابه در همان مکان با استفاده از سرویس گیرنده IPv4 متصل به سرویس اینترنت Comcast ، شکل زیر را ببینید. به جای قطع سخت ، یک سوراخ برای اندازه NTP بین 212 تا 460 بایت وجود دارد. این سوراخ بیش از یک سوم سرورهای هدف را تحت تأثیر قرار می دهد. هرچند که سوراخ کمتری در نمودار ISP = AT & T در بالا نیز دیده می شود: انسداد مبتنی بر اندازه نیز در اروپا دیده می شود ، اگرچه شیوع آن کمتر است.
مسدود کردن NTP بر اساس اندازه چندین سال پیش در لیست NANOG و جاهای دیگر مورد بحث قرار گرفت. سالها بعد این بلوکهای مبتنی بر اندازه هنوز در جای خود قرار دارند اما بر ترافیک نرم افزار سرور سرویس گیرنده NTP تأثیری ندارند. با این حال ، آخرین پروتکل امن انتقال زمان NTP ، Network Time Security (NTS) ، بسته های NTP را با بارهای تأیید اعتبار بزرگ مبادله می کند. آزمون های قابلیت همکاری NTS در مورد بلوک های مبتنی بر اندازه NTP بد عمل کرده است. راه حل ها در جامعه NTS مورد بحث است.
در حالی که فیلتر NTP مبتنی بر اندازه بر بر ترافیکی تأثیر می گذارد که دارای معیارهای اندازه خاصی باشد ، فیلترهای حد مجاز NTP باعث برخی ] ترافیک NTP کاهش می یابد. به عنوان مثال. یکی از مشتریان نظارت بر NTP در منطقه شیکاگو من بطور منظم از سرورهای NTP NIST واقع در Gaithersburg ، مریلند سال می کند. شکل زیر نشان می دهد که میزان موفقیت در اواخر اکتبر 2019 از 100٪ به 20-40٪ کاهش یافته است. [Scheduled maintenance at Gaithersburg caused the low values on October 26, 27.]
چه اتفاقی افتاد؟ میزان موفقیت مشاهده شده از سایر سرویس گیرندگان نظارت بر NTP همچنان بالا است. شاید ازدحام شدید اینترنت در جایی بین شیکاگو و گیترزبرگ وجود داشته باشد. من این احتمال را بررسی کردم. سرورهای NIST NTP همچنین از یک پروتکل قدیمی تر برای انتقال زمان پشتیبانی می کنند: TIME. Time از پورت 37 UDP استفاده می کند در حالی که NTP از پورت 123 UDP استفاده می کند. مقایسه میزان موفقیت NTP و TIME چشمگیر است: NTP عملکرد ضعیفی داشت همانطور که در بالا نشان داده شد TIME نزدیک به 100٪ بود از این رو ترافیک NTP عمدا کاهش می یافت. ترجیحاً کنار گذاشتن ترافیک NTP مخفی نیست ، به این ارائه مراجعه کنید. علی رغم پرسش های فراوان ، من نتوانسته ام جزئیاتی مانند دقیقاً نحوه فیلتر کردن NTP ، نمایه ترافیک فعلی NTP را که مخرب تلقی می شود یا اینکه می توان از روش های جایگزینی برای محدود کردن استفاده از NTP در حملات DDoS استفاده کرد ، تعیین کنم. من توانستم CenturyLink و چندین ISP / IXP دیگر را به عنوان اپراتورهای شبکه ای که نرخ NTP را محدود می کنند شناسایی کنم.
محدود کردن نرخ باعث ایجاد مشکل در استخر NTP می شود. استخر NTP از سیستم های مانیتورینگ برای بررسی دقیق زمان سرورهای NTP استخر و تأیید اتصال شبکه خوب سرورها استفاده می کند. یک فیلتر محدود کننده نرخ NTP می تواند باعث اتصال ضعیف به برخی از سرورها شود و باعث شود این سرورها به طور موقت از استخر NTP حذف شوند.
اگرچه در اینجا جزئیات را بیان نمی کنم ، فیلتر کردن IPv6 NTP در حال حاضر غیرمعمول است.
چه اتفاقی می افتد بعدی ؟ پس از بحث و گفتگو با تعدادی از اپراتورهای اینترنت ، من شواهد کمی در مورد ضرورت فیلتر کردن NTP دیده ام. اپراتورهای اینترنتی انگیزه کمی برای تغییر در فیلتر کردن NTP موجود دارند. در بیشتر موارد ، مشتریان آنها شکایتی ندارند. پیش نویس اخیر IETF پیشنهاد می کند با اختصاص یک پورت اضافی برای NTP علاوه بر پورت فعلی UDP 123 ، از فیلتر کردن NTP جلوگیری کنید.
ضمیمه: کشف محل کار فیلترهای NTP .
مکان از فیلترهای NTP مبتنی بر اندازه گاهی اوقات می توان تعیین کرد. در اینجا من از mtr یکی از مشتری های آزمایش NTP خود استفاده می کنم (ISP = AT & T). (می توان از Traceroute نیز استفاده کرد.) محموله 100 بیتی از طریق پورت UDP 123. ارسال می شود.
$ mtr -s 100 –udp -P 123 204.9.54.119
Traceroute [v0.93]
میزبان
1. dsldevice
2. aa-bb-cc-dd.lightspeed.cicril.sbcglobal.net (AT&T)
3. 71.151.XX.YY (AT&T)
4. cr83.cgcil.ip.att.net
5. cgcil403igs.ip.att.net
6. 192.205.37.22
7. 50.248.118.166
8. ae4-2324.ls-transit.en180br.ord2.your.org
9. (منتظر پاسخ)
اکنون ما همین دستور را با بار 500 بایت اجرا می کنیم.
$ mtr -s 500 –udp -P 123 204.9.54.119
Traceroute من [v0.93]
میزبان
1. dsldevice
2. aa-bb-cc-dd.lightspeed.cicril.sbcglobal.net (AT&T)
3. (در انتظار پاسخ)
فیلتر اندازه NTP بین aa-bb-cc-dd.lightspeed.cicril.sbcglobal.net و 71.151.XX.YY ، هر دو روتر AT&T واقع شده است.
کشف محدودیت نرخ انجام شده دشوارتر است اگر فیلتر NTP درخواست های NTP را محدود کند ، mtr / traceroute ممکن است در کجا نشان دهد. اگر در عوض میزان NTP میزان محدود شده باشد ، این ابزارها کمک نمی کنند.
عکس Daphné Be Frenchie در Unsplash.

