غول اینترنتی Cloudflare گزارش می‌دهد که سرویس DNS resolver ۱٫۱٫۱٫۱ این شرکت، اخیراً برای برخی از مشتریانش به دلیل ترکیبی از هک پروتکل (BGP) و نشت مسیر، غیر قابل دسترسی یا دچار افت کیفیت شده است.
این حادثه هفته گذشته رخ داد و ۳۰۰ شبکه در ۷۰ کشور را تحت تأثیر قرار داد. با وجود این ارقام، شرکت می‌گوید که تأثیر آن بسیار کم بود و در برخی کشورها کاربران حتی متوجه آن نشدند.
جزییات حادثه :
Cloudflare اعلام کرده که در ساعت ۱۸:۵۱ به وقت جهانی در تاریخ ۲۷ ژوئن، شرکت الکترونت (AS267613) شروع به اعلام آدرس IP 1.1.1.1/32 به ارائه‌دهندگان سرویس‌های بالادستی خود کرده است.
این اعلام نادرست توسط شبکه‌های مختلف، از جمله یک ارائه‌دهنده Tier 1 ، پذیرفته شد که این شبکه آن را به عنوان مسیر Remote Triggered Blackhole (RTBH) در نظر گرفت.
این hijack به این دلیل رخ داد که پروتکل BGP به سمت مسیر خاصی می رود. مسیر AS267613 در مورد ۱٫۱٫۱٫۱/۳۲ خاص تر از Cloudflare 1.1.1.0/24 بود و شبکه ها را به سمت ترافیک مخرب هدایت می کرد.
ترافیکی که برای DNS resolver 1.1.1.1 از Cloudflare لحاظ شده بود، به صورت blackhole قرار داشت، و در نتیجه، خدمات برای برخی کاربران غیرقابل دسترسی قرار گرفت.
یک دقیقه بعد، در ساعت ۱۸:۵۲ به وقت جهانی ، شرکت Nova Rede de Telecomunicações Ltda (AS262504) به طور اشتباه آدرس ۱٫۱٫۱٫۱/۲۴ را به سمت upstream شرکت AS1031 فرستاد، که باعث شد که این اعلام به صورت گسترده‌تری منتشر شود و تأثیراتی بر روی مسیریابی جهانی داشته باشد.
این نشت تغییراتی در مسیریابی BGP عادی ایجاد کرد، باعث شد که ترافیکی که به سمت ۱٫۱٫۱٫۱ مقصد داشته است، به طور نادرست مسیردهی شود و مشکلات اضافی در دسترسی و تاخیر ایجاد کند.
Cloudflare مشکلات را در حدود ساعت ۲۰:۰۰ به وقت جهانی شناسایی کرد و تقریباً دو ساعت بعد، مشکل حل شد.
اصلاح مشکلات
اقدام اولیه Cloudflare برای پاسخ به وقوع این حادثه، درگیر شدن با شبکه‌های درگیر در حادثه بوده است
استفاده از RPKI به شرکت این امکان را می‌دهد که مسیرهای نادرست را به طور خودکار رد کند، بنابراین این اعلان‌های نادرست تأثیری بر مسیریابی داخلی شبکه‌ها نداشته‌اند.
Cloudflare در گزارش پس از وقوع حادثه خود، راه‌حل‌های بلندمدت زیر را ارائه کرده است:
- سیستم‌های تشخیص نشت مسیر را با استفاده از منابع داده بیشتر و یکپارچه‌سازی نقاط داده‌ی زمان واقعی، بهبود دهید.
- از RPKI برای اعتبار سنجی مبدا و مسیر استفاده کنید.
- از MANRS استفاده کنید تا آدرس های طولانی با prefix نامعتبر را رد کند که این روش در پیاده سازی مکانیزم های فیلترینگ قوی است.
- پتانسیل اجرای RFC9234 و Discard Origin Authorization (DOA) را بررسی کنید.
