نگاهی دقیق‌تر به یک ناهنجاری BGP در ونزوئلا 🔎

داده‌های Cloudflare Radar نشان دادند که در تاریخ ۲ ژانویه یک اتفاق مسیررسانی (route leak) در شبکه‌های ونزوئلا رخ داده است. با بررسی بیشتر متوجه شدیم که از اوایل دسامبر تاکنون یازده رویداد مشابه وجود دارد که در همه آن‌ها AS8048 به‌عنوان leaker شناسایی شده است.

الگوی تکرارشوندهٔ این نشت‌ها نشان می‌دهد که شبکهٔ CANTV (AS8048)، یکی از ISPهای بزرگ ونزوئلا، احتمالاً سیاست‌های export/import مرزی (routing export/import policies) را به درستی تنظیم نکرده است. به عبارت دیگر، آنچه در داده‌ها می‌بینیم ممکن است ناشی از رویه‌های فنی ضعیف در ISP باشد و لزوماً دلیلی بر رفتار مخرب نیست 🙂.

در ادامه کوتاه دربارهٔ Border Gateway Protocol (BGP) و مفهوم route leak توضیح می‌دهم و سپس به جزئیات نشت مشاهده‌شده و سناریوهای محتمل می‌پردازم.

پس‌زمینه: BGP route leaks

اول به‌طور مختصر مرور کنیم منظور از route leak چیست. یک route leak شبیه این است که در بزرگراه خروجی اشتباهی را بگیریم؛ ممکن است به مقصد برسیم اما با یک مسیر طولانی‌تر و تاخیر بیشتر. RFC7908 این پدیده را به‌صورت «انتشار اعلان‌های مسیریابی خارج از دامنهٔ موردنظر» تعریف کرده و دامنهٔ موردنظر معمولاً بر اساس روابط تجاری بین Autonomous Systems (ASها) مشخص می‌شود.

روابط بین شبکه‌ها در BGP معمولاً یکی از این دو نوع است: customer-provider یا peer-peer. در رابطهٔ customer-provider، provider باید تمام مسیرها را به customer اعلام کند اما customer فقط باید مسیرهای خود و مشتریانش را به provider اعلام کند. در رابطهٔ peer-peer هم هر طرف فقط مسیرهای خودش و مسیرهای مشتریانش را به peer دیگر اعلام می‌کند.

این قوانین کمک می‌کنند که ترافیک روی مسیرهای‌ متعارف حرکت کند: از customer به provider و نهایتاً از طریق peeringها به شبکه‌های دیگر، بدون اینکه «دره» (valley) نامتعارفی شکل بگیرد. یک route leak زمانی رخ می‌دهد که یک AS مسیرهایی را از provider یا peer بگیرد و آن‌ها را به provider یا peer دیگر منتقل کند — یعنی نقض قانون valley-free. یک نمونهٔ ساده، Type 1 یا hairpin leak است که در آن یک مشتری مسیرهای یکی از providers خود را به provider دیگرش بازتوزیع می‌کند؛ این کار باعث می‌شود شبکهٔ کوچک‌تر (customer) تحت بار ترافیک غیرمنتظره قرار بگیرد و تاثیرگذاری بالایی داشته باشد.

نشت مسیر توسط AS8048 (CANTV)

در مورد مورد ونزوئلا: بررسی‌ها نشان می‌دهد AS8048 (CANTV) مسیرهایی را از یکی از providers خود، AS6762 (Sparkle)، گرفته و به AS52320 (V.tal GlobeNet) بازارسال کرده است — این رفتار قطعاً یک route leak است ⚠️.

پیشینهٔ مسیرها نشان می‌دهد prefixهای متأثر همه از AS21980 (Dayco Telecom) می‌آیند و مجموعه‌ای از آدرس‌ها در محدودهٔ 200.74.224.0/20 هستند. نکتهٔ کلیدی این است که AS8048 تأمین‌کنندهٔ (provider) AS21980 است؛ یعنی رابطهٔ customer-provider بین AS8048 و AS21980 برقرار است و این موضوع در داده‌های Cloudflare Radar و ابزارهایی مثل bgp.tools و BGPKIT (monocle) نیز قابل مشاهده است.

برای دیدن خروجی ابزاری که وضعیت رابطهٔ دو AS را نشان می‌دهد، نمونه‌ای از خروجی monocle را می‌توان این‌جا آورد:

➜  ~ monocle as2rel 8048 21980
Explanation:
- connected: % of 1813 peers that see this AS relationship
- peer: % where the relationship is peer-to-peer
- as1_upstream: % where ASN1 is the upstream (provider)
- as2_upstream: % where ASN2 is the upstream (provider)
Data source: https://data.bgpkit.com/as2rel/as2rel-latest.json.bz2

╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮
│ asn1 │ asn2  │ connected │ peer │ as1_upstream │ as2_upstream │
├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤
│ 8048 │ 21980 │ 9.9%      │ 0.6% │ 9.4%         │ 0.0%         │
╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯

اگرچه تنها ~9.9% از route collectorها این دو ASN را مستقیمِ مجاور نشان می‌دهند، اما در مسیرهای دیده‌شده تقریباً همیشه AS8048 به‌عنوان upstream برای AS21980 شناخته می‌شود؛ بنابراین می‌توان با اطمینان نسبتاً بالا رابطهٔ provider-customer را تأیید کرد.

نکتهٔ دیگری که جالب است، prepending شدید AS8048 روی بسیاری از مسیرهای لوک‌شده بود. Prepending یعنی تکرار ASN خود در outbound advertisement برای کم‌مصرف جلوه‌دادن آن مسیر و سوق دادن ترافیک به مسیر دیگر. نمونهٔ مسیرهای دیده‌شده به‌صورت تقریبی به شکل زیر بودند: “52320,8048,8048,8048,8048,8048,8048,8048,8048,8048,23520,1299,269832,21980”. مسیر غیر-prepended معادلش می‌شود: “52320,8048,23520,1299,269832,21980”.

اگر هدف AS8048 این بود که به‌عنوان man-in-the-middle (MITM) برای ترافیک عمل کند، کار منطقی این نبود که با Prepending مسیر را کمتر جذاب کند؛ ضمن اینکه AS8048 خودش providerِ downstream است، پس چرا باید برای MITM کردن prefixها را نشت دهد؟ این تصویر با سناریوی سوءاستفاده هماهنگ نیست.

رویدادهای نشت در چند اعلان جداگانه و با فواصل حدود یک‌ساعته در بازهٔ 15:30 تا 17:45 UTC در ۲ ژانویه ظاهر شدند که نشان می‌دهد ممکن است مشکل شبکه‌ای یا یک خطای پالیسی/همگرایی (convergence) باعث بروز این نشت‌ها شده باشد. همچنین قابل ذکر است که این رویدادها بیش از دوازده ساعت قبل از هر حملهٔ نظامیِ اعلام‌شده رخ داده‌اند؛ با توجه به فراوانی نشت‌ها در شبکه‌های آمریکای جنوبی و الگوی پیشین، هیچ دلیل روشنی برای ارتباط زمانی این نشت با رخدادهای سیاسی وجود ندارد.

در دو ماه گذشته سابقهٔ مشابهی از AS8048 وجود دارد؛ از اوایل دسامبر یازده رویداد نشت که AS8048 در آنها leaker بوده ثبت شده است. این نشان می‌دهد رفتار اخیر تکرار همین الگوهای اشتباهِ پالیسی است و نه یک ناپدیدی فنی بی‌سابقه.

شرحِ سناریوی معقول‌تر: به‌احتمال زیاد AS8048 پالیسی‌های export خود را نسبت به یکی از providersش (AS52320) خیلی باز تنظیم کرده است. به‌عنوان مثال اگر میل فیلترِ خروجی آن‌ها فقط بر مبنای prefix list تولیدشده از IRR بوده و از community tagهای BGP مشتری (customer BGP community) استفاده نکرده باشند، ممکن است مسیرهایی که فقط باید بین customer و provider مستقیم رد و بدل شوند، به‌صورت غیرمستقیم و در غیاب مسیر مستقیمِ AS21980 به AS6762 نشت پیدا کرده باشند.

استانداردهایی مثل RFC9234 و ویژگی‌هایی مانند Only-to-Customer (OTC) می‌توانند تا حد زیادی از این خطاها جلوگیری کنند، چون BGP را بیشتر به نقش‌های customer-provider و peer-peer گره می‌زنند—البته در صورتی که همهٔ فروشنده‌ها (routing vendors) از آن پشتیبانی کنند. در آینده می‌توانم جزئیات فنی‌تر RFC9234 را در یک پست جداگانه توضیح بدهم.

تفاوت بین origin validation و path validation

در گزارش اولیه به این نکته اشاره شده بود که Sparkle (AS6762) RPKI Route Origin Validation (ROV) را پیاده‌سازی نکرده است و به‌همین‌خاطر در سایت‌هایی مثل isbgpsafeyet.com به‌عنوان «unsafe» نشان داده شده. این درست است، اما باید توجه کنیم که origin validation جلوی همهٔ انواع ناهنجاری‌های BGP را نمی‌گیرد.

در عمل دو دستهٔ متفاوت از ناهنجاری‌های BGP وجود دارد: route misoriginations (معمولاً BGP hijacks که ریشهٔ اشتباه یک prefix است) و path-based anomalies (مشکلات مربوط به مسیر/انتشار مسیر). RPKI/ROV برای دستهٔ اول طراحی شده تا مطمئن شویم که origin یک prefix واقعاً مالک آن است. در مورد نشت ونزوئلا، origin صحیح (AS21980) بود و مشکل در مسیر انتشار (path) رخ داده است، پس ROV به تنهایی این حالت را متوقف نمی‌کرد.

جمع‌بندی و پیام برای SRE/DevOps 👩‍💻👨‍💻

برای تیم‌های شبکه و SRE نکات عملی این است که: اولاً رصد مداوم مسیرها و alerting بر اساس الگوهای غیرمعمول می‌تواند سریعاً نشت‌ها را نشان دهد؛ ثانیاً از community-based tagging و کنترل دقیق export policy استفاده کنید تا فقط مسیرهایی که باید به peers/providers اعلام شوند، منتشر شوند. استفاده از استانداردهایی مثل RFC9234 و OTC و بهبود پوشش RPKI هم ابزارهای مکمل خوبی هستند، اما هرکدام برای دستهٔ مشخصی از مشکلات طراحی شده‌اند.

در نهایت، وقتی با چنین رویدادهایی روبه‌رو می‌شوید، قبل از نتیجه‌گیری دربارهٔ انگیزهٔ سیاسی یا جاسوسی، همیشه الگوهای تاریخی، جزئیات path (مثل prepending) و ساختار روابط AS را بررسی کنید — خیلی وقت‌ها علت، خطای پالیسی یا مشکل عملیاتی ساده است 😊.