از BGP Hijack تا به‌روزرسانی مخرب

در 28 آگوست 2026، مسیر جدیدی به 162.55.80.0/24 در اینترنت ظاهر شد. محدوده آدرس شامل زیرساخت های مورد استفاده Softaculous، از جمله نقاط پایانی برای نرم افزار مدیریت سرور Virtualizor است. مسیر غیرمجاز بود، اما شبکه‌هایی که آن را پذیرفتند، ترافیک آن آدرس‌ها را به سروری که توسط یک مهاجم کنترل می‌شود ارسال کردند. برخی از نصب‌های Virtualizor متعاقباً یک به‌روزرسانی مخرب دریافت کردند.

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

چگونه ترافیک منحرف شد

مسیر قانونی که آدرس‌های آسیب‌دیده را پوشش می‌دهد، Hetzner Online’s 162.55.0.0/16 بود که توسط AS24940 ایجاد شد. تقریباً در ساعت 20:57 UTC در 28 اوت، یک پیام غیرمجاز برای 162.55.80.0/24 از طریق AS62390 (NexonHost) و ترانزیت AS6204 (Zet.net) ظاهر شد. A/24 خاص تر از /16 است، بنابراین روترهایی که هر دو مسیر را یاد گرفته اند طبق پیام جدید ترافیک را برای /24 پیش می برند. انحراف در دو موج انجام شد که در 30 اوت در حدود ساعت 06:10 UTC پایان یافت. در سراسر پنجره پیوسته نبود. مسیر نیز به شدت در امواج تکان می خورد. به‌روزرسانی Softaculous و گزارش رویداد Virtualizor جدول زمانی را ارائه می‌کنند. جاده عمومی نحوه ورود مسیر غیرمجاز به AS62390 را مشخص نمی کند و ما نباید این را از موقعیت آن در جاده استنباط کنیم.

مسیر AS تبلیغ شده به AS24940 ختم می شود، مبدأ قانونی، اگرچه مسیر از طریق AS62390 می گذشت. در آن زمان، ROA برای پوشش 16/ دارای حداکثر طول 24/ بود که به AS24940 اجازه می داد پیشوندهایی به اندازه 24/ ایجاد کند. بنابراین اعتبارسنجی مبدا مسیر (ROV) این /24 غیرمجاز را به عنوان معتبر طبقه بندی می کند. ROV بررسی می کند که مبدا و طول پیشوند تبلیغ شده با ROA مطابقت داشته باشد. ثابت نمی کند که بقیه مسیر AS واقعی است یا اینکه پیام توسط شبکه منبع حل شده است. تجزیه و تحلیل حادثه APNIC این حالت شکست را توضیح می دهد، که همچنین در محدوده های مشخص شده RFC 6811 قرار دارد.

مهاجم همچنین پس از اینکه ترافیک اعتبارسنجی گواهی مسیر ربوده شده را دنبال کرد، یک گواهی فنی معتبر TLS برای دامنه های آسیب دیده به دست آورد. Let’s Encrypt از تأیید صدور چند پرسپکتیو (MPIC) استفاده می‌کند: کنترل دامنه را از چندین مکان شبکه تأیید می‌کند، بنابراین ربودن مسیر محلی باید به پاسخ‌های متناقض منجر شود. این /24 /24 / قانونی برای رقابت با آن نداشت، و به اندازه کافی گسترش یافت تا نقطه پایانی مهاجم بتواند این بررسی ها را برآورده کند. Virtualizor گزارش می دهد که تمام 368 همتا در نمونه RIPE RIS مسیر ربوده شده را در نقطه ای انجام دادند. در طول اندازه‌گیری‌های موج فعال، میانگین 266 همتای انحرافی، حدود 72 درصد از این نمونه را گزارش کرد.

بنابراین، سرویس گیرندگان HTTPS که به سرویس هدایت شده متصل می شوند، اخطار گواهی ندارند. به گفته Virtualizor، کلاینت‌های به‌روزرسانی آن بسته‌های به‌روزرسانی دانلود شده را در آن زمان به‌صورت رمزنگاری تأیید نکردند و یک بسته مخرب به تعداد کمی از نصب‌ها رسید. یک اتصال معتبر TLS برای اثبات اینکه خود نرم افزار از طرف فروشنده آمده کافی نبود.

ROA maxLength چیست؟

MaxLength ROA طولانی ترین طول پیشوندی را که AS مجاز به اعلام آن است تعیین می کند. ROA برای 162.55.0.0/16 با حداکثر طول 16 فقط 16/ را اجازه می دهد. با حداکثر طول 24، تمام 24/های داخل آن را نیز تایید می کند، به همین دلیل است که 162.55.80.0/24 جعلی به عنوان معتبر طبقه بندی شده است.

چگونه می شد از حمله جلوگیری کرد؟

هیچ کنترلی تمام امکان انحراف ترافیک را از بین نمی برد. اقدامات مختلف در نقاط مختلف زنجیره عمل می کند.

1. ROA maxLength را تنظیم کنید تا با پیشوندهایی که اعلام می کنید مطابقت داشته باشد

اگر اپراتور به طور معمول 16/ را اعلام می کند، ROA برای آن 16/ معمولاً باید 16/ را مجاز کند، نه پیشوند خاصی تا 24/. با ROA با طول دقیق، 162.55.80.0/24 جعلی RPKI نامعتبر خواهد بود، حتی اگر AS24940 را در انتهای مسیر خود حمل کند. شبکه‌هایی که مسیرهای نامعتبر را رد می‌کنند، آن را حذف می‌کنند.

اپراتورهایی که به طور قانونی از مسیرهای خاص تری استفاده می کنند، از جمله برای مهندسی ترافیک، پاسخ DDoS یا پیام های شمارنده اضطراری، به ROA های صریح برای این پیام ها و فرآیندی برای به روز رسانی آنها قبل از تغییر خط مشی BGP نیاز دارند. در این مورد، اگر 16/ فقط در طول دقیق خود مجاز باشد، 24/4 محافظ Hetzner نیز تا زمانی که ROA منطبق را دریافت نکند، در شبکه های تحمیل کننده ROV نامعتبر خواهد بود. به این ترتیب، راهنمایی حادثه باید شامل افرادی باشد که می‌توانند یک ROA اضطراری را تأیید و منتشر کنند، چگونه تأیید کنند که اعتبارسنجی‌ها آن را دریافت کرده‌اند، و چه زمانی باید مسیر امنیتی را اعلام و لغو کرد. این یک موضوع برنامه ریزی است، نه یک قاعده کلی در برابر عدم تجمیع. RFC 9319 حداقل ROA و ملاحظات عملیاتی را برای مسیرهای کاهش DDoS خاص تر مورد بحث قرار می دهد.

ROAهای سختگیرانه تر شیوع را در جایی که ROV اعمال می شد کاهش می داد. آنها نمی توانستند تضمین کنند که هر شبکه در اینترنت مسیر را رد می کند. محدود کردن توزیع همچنین این احتمال را افزایش می‌دهد که افراد احتمالی اعتبارسنجی Let’s Encrypt مخالفت کنند و مهاجم را از صدور گواهی محروم کنند. این یک مزیت محتمل است نه تضمین. APNIC گزارش می دهد که Hetzner متعاقباً ROA های /16 تحت تأثیر را به /16 کاهش داده است، اما تجزیه و تحلیل آن نشان داد که تقریباً 50 ROA دیگر Hetzner هنوز جزئیات بیشتری از آنچه در آن زمان اعلام شده بود را ارائه می دهند. این شمارش تصویری از تجزیه و تحلیل منتشر شده است و بیانیه ای از موجودی فعلی نیست.

2. پیام ها را در لبه مشتری فیلتر کنید

ارائه‌دهنده ترانزیت باید تأیید کند که هر مشتری چه چیزی مجاز به اعلام و اعمال فیلترهای مسیریابی بر اساس آن است، با استفاده از اطلاعات پیشوند و مبدا پشتیبانی‌شده. یک /24 غیرمنتظره با یک مسیر AS به ظاهر قابل قبول نباید صرفاً به این دلیل پذیرفته شود که مبدا آن تحت RPKI تأیید شده است. حداکثر محدودیت‌های پیشوند نیز می‌تواند حاوی برخی خطاها باشد، اگرچه مشخص نمی‌کند چه کسی صاحب پیشوند خاصی است.

رکورد مسیریابی عمومی مسیر را از طریق AS62390 و AS6204 نشان می دهد. به خودی خود دقیقاً تعیین نمی کند که پیام حل نشده چگونه وارد AS62390 شده است یا اینکه کدام بررسی عملیاتی شکست خورده است. درس عملی برای بالادستی اعتبارسنجی پیام های مشتری در ورود به سیستم، از جمله پیشوندهای واگذار شده یا پایین دست، و به روز نگه داشتن این مجوزها است. پیاده سازی First-AS به تنهایی این مثال را حل نمی کند: همسایه فوری می تواند ابتدا ASN خود را ارائه دهد، در حالی که منشاء قانونی جعلی را در انتهای مسیر حفظ می کند.

3. اعتبار مسیر، نه فقط شروع

ROV فقط آخرین AS را در مسیر بررسی می کند. ASPA (Autonomous System Provider Authorization) قبل از آن یک چک پرش اضافه می کند. یک رکورد ASPA منتشر شده در RPKI، شبکه هایی را که AS به عنوان ارائه دهندگان بالادستی استفاده می کند، فهرست می کند. سپس یک روتر اعتبار سنجی می تواند هر جفت AS مجاور را در یک مسیر دریافتی آزمایش کند و بپرسد که آیا AS که مسیر را ارسال کرده است مجاز به دریافت آن توسط AS زیر آن است یا خیر.

پس از این حادثه، Hetzner یک رکورد ASPA برای AS24940 منتشر کرد که تامین کنندگان مجاز آن را فهرست کرده بود و AS62390 در آن نبود. اینکه چقدر جذب می شود بستگی به محل قرار گرفتن شبکه اعتبار سنجی دارد. شبکه ای که مسیری را از یک کلاینت یا همتا می آموزد، با یک پرش غیرمجاز برای بی اعتبار کردن کل مسیر کافی رفتار می کند. AS6204 که یک /24 از مشتری AS62390 خود دریافت می کند دقیقاً همین مورد است. اگر او ASPA را تحت این ورودی تایید کرده بود و مسیرهای نامعتبر را حذف می کرد، پیام در اولین ترانزیت متوقف می شد.

شبکه‌هایی که مسیری را از یکی از ارائه‌دهندگان خود یاد می‌گیرند، آزمون ضعیف‌تری را اعمال می‌کنند زیرا مسیرهای قانونی در بالادست، گاهی از طریق یک پیوند همتا، و بالعکس حرکت می‌کنند. مگر اینکه AS62390 یا AS6204 ورودی‌های ASPA را نیز منتشر کرده باشد، این شبکه‌ها نمی‌توانند مسیری را که AS24940 با AS62390 همتا می‌شود و AS62390 مسیر پایین به AS6204 را طی می‌کند، حذف کنند. نتیجه در آنجا ناشناخته خواهد بود، نه نامعتبر. بنابراین، پوشش ASPA بستگی به این دارد که چه مقدار از مسیر احراز هویت شده است، نه فقط سوابق خود قربانی. مهاجمی که از سوابق قربانی اطلاع دارد همچنین می‌تواند یکی از ارائه‌دهندگان فهرست شده خود را در مسیر جعلی قرار دهد، و کشف این موضوع به انتشار ASPA خود توسط ارائه‌دهنده بستگی دارد.

این رکورد در زمان حمله وجود نداشت و انتشار آن مسیرهای شبکه‌هایی را که اعتبارسنجی انجام نداده‌اند فیلتر نمی‌کند. روش تأیید همچنان IETF Internet-Draft است (پیش نویس-ietf-sidrops-aspa-verification، ویرایش 28 آگوست 2026)، بنابراین اپراتورها باید قبل از تکیه بر آن، بررسی کنند که اعتبار سنجی و روترهای خودشان از چه چیزی پشتیبانی می کنند. انتشار یک ASPA دقیق برای AS خودتان هزینه کمی دارد و شروع به محافظت از شما در هر شبکه ای می کند که تأیید می کند. ردیابی APNIC زمینه بیشتری را فراهم می کند.

4. پیشوندهای خود را خارج از شبکه خود تماشا کنید

یک هشدار فقط مبدأ ممکن است این حادثه را از دست داده باشد: /24 به نظر می رسد از AS مورد انتظار نشات می گیرد. یک سیگنال مفیدتر سه مشاهدات را ترکیب می‌کند: یک پیشوند خاص‌تر که قبلاً دیده نشده بود، یک AS غیرمنتظره بلافاصله در بالادست مبدأ ظاهری، و مشاهدات در کلکتورهای مستقل BGP، حتی اگر مسیر به طور مکرر ظاهر شود و ناپدید شود. Virtualizor حدود 10600 برداشت را در طول این حادثه گزارش کرده است. هشداری که مستلزم آن است که مسیر به طور مداوم قابل مشاهده باشد، ممکن است چنین الگویی را از دست بدهد. این مشاهدات زمینه‌ای برای تحقیق هستند، نه اثبات خودکار حمله. مهندسی ترافیک قانونی همچنین می تواند طول و مسیر پیشوند را تغییر دهد.

پاسخ باید یک مالک و یک مسیر تشدید آزمایش شده داشته باشد. Hetzner شروع به اعلام همان /24 در حدود ساعت 08:50 UTC در 29 اوت کرد و انحراف تقریباً به صفر رسید. حفاظت /24 آن در حدود ساعت 14:10 UTC برداشته شد. حل نشده /24 دوباره در حدود ساعت 20:00 UTC ظاهر شد و موج دوم را باز کرد. توالی عمومی مشخص نمی کند که چرا مسیر دفاعی عقب نشینی شد یا اینکه آیا خروج از آن به خودی خود به حادثه پایان می داد. این واقعاً نیاز به حفظ یک پیام متقابل را در جایی که از نظر عملیاتی امکان پذیر است نشان می دهد تا زمانی که مسیر حل نشده مهار نشده و علت اصلی برطرف شود. نتیجه را در چندین نقطه نظارت خارجی بررسی کنید، سپس پس از بازیابی قابل مشاهده به تماشای آن ادامه دهید.

5. محدودیت و نظارت بر صدور گواهی

سوابق CAA می توانند CA ها را برای یک دامنه محدود کنند. اما یک ورودی اولیه CAA که به Let’s Encrypt اجازه می دهد این مورد را متوقف نمی کند: مهاجم یک گواهی Let’s Encrypt را به دست آورده است. در صورت لزوم، محدودیت‌های الزام‌آور حساب CAA و روش اعتبارسنجی ممکن است صدور را محدودتر کند. روشی که به کنترل DNS بستگی دارد نه نقطه پایانی وب ربوده شده، این مسیر حمله خاص را تغییر می دهد. قبل از تکیه بر این طراحی، DNS و امنیت حساب را بررسی کنید.

گزارش‌های شفافیت گواهی را برای گواهی‌های غیرمنتظره‌ای که دامنه‌های تولید و به‌روزرسانی را پوشش می‌دهند، نظارت کنید و رویه‌ای برای ابطال و واکنش رویداد در نظر بگیرید. مانیتورینگ سی تی به تشخیص رهاسازی کمک می کند. گواهی را قبل از صدور مسدود نمی کند و مشتری را از پذیرش آن باز نمی دارد.

6. بسته به روز رسانی را بدون توجه به مسیر شبکه بررسی کنید

مستقیم ترین راه برای شکستن آخرین مرحله این است که مشتری قبل از نصب، امضای فروشنده روی بسته را تأیید کند، با استفاده از یک کلید مطمئن که سرور به‌روزرسانی نمی‌تواند بی‌صدا آن را جایگزین کند. ابرداده امضا شده باید بسته را به نسخه و جمع کنترلی آن، با محافظت مناسب در برابر به‌روزرسانی‌های قدیمی یا مکرر، متصل کند. سپس یک نقطه پایانی ربوده شده و حتی یک گواهی معتبر TLS به تنهایی یک بسته ارائه شده توسط مهاجم را قابل نصب نخواهد کرد.

در 21 سپتامبر، Softaculous نسخه 6.4.1 Softaculous را با تأیید امضای RSA/SHA-256 برای بسته‌های به‌روزرسانی و پاسخ‌های امضا شده API معرفی کرد. یادداشت انتشار او کنترل کلید یا محافظت از پخش مجدد را مشخص نمی‌کند، بنابراین این موارد توصیه‌ها در اینجا باقی می‌مانند، نه ادعاها. همچنین نسخه Softaculous متوجه نمی‌شود که مشتریان به‌روزرسانی Virtualizor همان بررسی را اعمال می‌کنند: توصیه Virtualizor امضای بسته را به عنوان کاری توصیف می‌کند که باید انجام شود.

NOC واقعاً چه چیزی را می تواند ببیند؟

کانال های خارجی BGP و، در صورت وجود، BMP های روترها می توانند پیام های جدید، تغییرات مسیر AS و اثر یک مسیر اصلاحی را نشان دهند. داده‌های RPKI می‌توانند نشان دهند که مسیر معتبر، نامعتبر است یا یافت نشد. نه یک برچسب معتبر و نه یک گواهی HTTPS معمولی یک حساب پاک از مسیر کامل یا کد دانلود شده نیست.

ابزاری مانند Noction Flow Analyzer می‌تواند به پاسخگویی به مجموعه‌ای از سوالات مختلف از داده‌های ترافیک صادر شده کمک کند: به کدام مقصد رسیده‌اید، چه زمانی ترافیک به‌روز شده تغییر کرده است، و کدام شبکه‌ها یا میزبان‌ها نیاز به بررسی بیشتر دارند. ورودی های NetFlow یا IPFIX به تنهایی یک مسیر BGP AS را احراز هویت نمی کنند یا اثبات می کنند که یک به روز رسانی مخرب است. همبستگی سوابق جریان با رویدادهای مسیریابی، تغییرات DNS، سوابق گواهی و شواهد میزبان به تیم حادثه جدول زمانی قوی‌تری نسبت به هر منبع واحدی می‌دهد.

نتیجه گیری عملیاتی

این حمله از سه مرز اعتماد عبور کرد: مسیریابی مشتریان را به نقطه پایانی اشتباه تحویل داد. انحراف گسترده اعتبار گواهی چند دیدگاه را شکست داد و TLS انحراف را آشکار نکرد. و سرویس گیرنده به روز رسانی کد را بدون تأیید بسته مستقل پذیرفته است. مقادیر باریک ROA maxLength و ROV انتشار مسیر را دشوارتر می کند. فیلتر کردن لبه کلاینت می توانست زودتر آن را متوقف کند. نظارت خارجی، یک پیام متوالی متقابل، و هشدارهای گواهی می‌توانست این حادثه را کوتاه یا مهار کند. امضای نرم افزار تأیید شده می تواند از تبدیل تغییر مسیر درخواست به روز رسانی به نصب مخرب جلوگیری کند.

برای یک ISP یا میزبان NOC، سوال قابل اجرا فقط این نیست که “آیا پیشوندهای ما تحت پوشش RPKI هستند؟” به این معنا که: کدام یک از آنها را مجاز می‌دانیم، کدام همسایگان می‌توانند آن‌ها را اعلام کنند، چقدر سریع مسیری را که اشتباه به نظر می‌رسد شناسایی می‌کنیم، و اگر ترافیک منحرف شود چه اتفاقی می‌افتد؟