چند ربودن مسیر (route hijack) اخیر که Spamhaus گزارش کرده بود توجه ما رو جلب کرد 😊. در بسیاری از این حملات، بازیگر مخرب از ASNs بلااستفاده سوء‌استفاده کرده و با ساختن AS_PATH‌های جعلی، ترافیک رو به مسیرهای غیرمنتظره هدایت کرده است. با جعل AS_PATH، مهاجم سعی می‌کند ترافیک را به جایی بفرستد که نباید برود و هم‌زمان هویت خودش را پنهان کند. در برخی موارد مهاجم آن‌قدر اطلاعات مسیر را پاک می‌کند که وانمود کند خودِ او منشاء (origin) یک prefix در BGP است. از این مسیرهای ربوده‌شده می‌توان برای رهگیری ترافیک یا مقاصد دیگر سوء‌نیت‌دار استفاده کرد. راه‌حل ساده‌ای برای این موارد وجود دارد: بررسی پایه‌ای که اطمینان دهد BGP peer همیشه شبکهٔ همتای خود را به‌عنوان “First AS” در مسیر ارسالی قرار می‌دهد. برای فهمیدن اینکه این محافظت‌ها چقدر پیاده‌سازی شده‌اند، چند شبکهٔ بزرگ را استرس‌تست کردیم و پیاده‌سازی BGP آن‌ها را بررسی نمودیم — در ادامه یافته‌ها را می‌بینید.

بررسی ربودن مسیرها با مسیرهای جعل‌شده 🔍

نشانه‌هایی که نشان می‌دهد AS_PATH جعل شده، وقتی واضح می‌شود که روابط غیرمحتملِ ASها در مسیر را با دقت نگاه کنیم. به‌عنوان مثال یکی از ربودن‌هایی که Spamhaus گزارش کرد مربوط به یک prefix متعلق به Orange S.A. (اپراتور فرانسوی) بود. با استفاده از ابزار monocle می‌توانیم پیام BGP UPDATE مرتبط با آن ربودن را پیدا کنیم:

➜  ~ monocle search --start-ts 2026-04-13T00:20:00Z --end-ts 2026-04-13T00:23:59Z --prefix 90.98.0.0/15 --collector rrc26 --json
{
  "aggr_asn": null,
  "aggr_ip": null,
  "as_path": "48237 1299 199524 270118 17072 41128",
  "atomic": false,
  "collector": "rrc26",
  "communities": null,
  "local_pref": 0,
  "med": 0,
  "next_hop": "185.1.8.3",
  "origin": "IGP",
  "peer_asn": 48237,
  "peer_ip": "185.1.8.3",
  "prefix": "90.98.0.0/15",
  "timestamp": 1776039612.0,
  "type": "ANNOUNCE"
}

ما می‌دانیم AS1299 (Arelion) یک Tier 1 است؛ بنابراین هر AS در سمت راستِ AS_PATH معمولاً رابطهٔ customer→provider را نشان می‌دهد. طبق ترتیب بالا، این پیام می‌گوید AS17072 برای AS41128 ترانزیت فراهم کرده، AS270118 برای AS17072 و AS199524 برای AS270118. اگر کمی شبکه‌ها را بررسی کنیم متوجه می‌شویم: AS41128 یک ASN بلااستفاده متعلق به Orange France است، AS17072 یک ISP عمدتاً مکزیکی است، AS270118 یک hosting provider در مکزیک است و AS199524 همان Gcore با حضور peering جهانی است. ترتیب ASها در پیام نشان می‌دهد که یک ASN بلااستفادهٔ Orange دارد از ISPهای مکزیکی ترانزیت می‌خرد و سپس این مسیر به Gcore و Tier 1 می‌رسد — چیزی که از نظر منطقی غیرمعمول به‌نظر می‌رسد.

در یک مورد دیگر، ربودنی برای prefixهای 47.1.0.0/16 و 47.2.0.0/16 با origin AS36429 شامل ASN اصلی Cloudflare یعنی 13335 در AS_PATH هم بود: “199524 270118 17072 13335 36429”. این BGP UPDATEها در MRT Explorer از Cloudflare Radar نیز مشاهده پذیرند.

ما قاطعانه تأیید می‌کنیم که ما (Cloudflare, AS13335) هیچ adjacency‌ای با AS36429 که اکنون بلااستفاده و متعلق به Charter است نداریم. یعنی این یک مسیر جعل‌شده بوده که مهاجم ASN کلودفلر را به‌عنوان یکی از upstreamهای جعلی در تبلیغاتش وارد کرده و این تبلیغات به سمت Gcore (AS199524) منتشر شده‌اند. همچنین تمام مسیرهای ربوده‌شده به شبکه‌ای در پشت peeringهای Gcore در Chicago ختم می‌شدند و در واقع ترافیک هرگز از ISPهای مکزیکی یا شبکهٔ Cloudflare عبور نکرده بود. بنابراین با منطق معقول می‌توانیم نتیجه بگیریم که مسیرها تا جایی جعل شده‌اند که به چپ‌ترین AS مشترک می‌رسند — در این مثال AS199524 — چون بخش باقی‌ماندهٔ مسیر نامحتمل به‌نظر می‌رسد.

به نظر می‌رسد استراتژی مهاجم شامل مراحل مشخصی بوده است:

1. آغاز اعلان‌های BGP برای prefixهای «parked» یا ثبت‌شده ولی غیرفعال 📌

2. جعل کامل AS_PATH بدون گذاشتن ASN محلیِ خود مهاجم (یعنی از مسیر حذف کردن ASN خودش) 🎭

3. تبلیغ این مسیرها به Gcore، AS199524 🚚

در این ربودن‌ها به نظر می‌رسد Gcore (AS199524) بررسی و اعمال قاعدهٔ First AS را نادیده گرفته است. (بعداً بررسی می‌کنیم چرا ممکن است گاهی این بررسی‌ها نادیده گرفته شوند.) در نتیجه مسیر جعلی پذیرفته شده و prefixهای ربوده‌شده به upstreamها و peers منتشر شده‌اند. اگرچه ASPA می‌تواند در باطل کردن برخی از مسیرهای جعل‌شده کمک کند، مهاجم ممکن است با وارد کردن یک origin AS معتبر که RPKI-ROV آن را تأیید می‌کند یا یک upstream ASPA معتبر، از ASPA عبور کند. برای جلوگیری از همین نوع خاص ربودن‌ها باید به مکانیزمی دیگر که در BGP وجود دارد تکیه کنیم: First AS checking و enforcement.

اهمیت First AS checking

هدایت ترافیک در اینترنت شبیه ارسال یک بسته است: هر بار که بسته دست یک курیر می‌افتد یک ثبت (log) از آن نگه داشته می‌شود. در BGP، این همان AS_PATH است که هر شبکه‌ای را که مسیر از آن عبور می‌کند ثبت می‌کند.

AS_PATH در BGP برای انتخاب مسیر استفاده می‌شود. الگوریتم انتخاب مسیر ترکیبی از فاکتورها را در نظر می‌گیرد تا «بهترین» لیست hops را مشخص کند. AS_PATH همچنین برای جلوگیری از loop کاربرد دارد، چون شبکه‌ها می‌توانند تصمیم بگیرند مسیرهایی را که قبلاً از شبکه‌شان عبور کرده‌اند قبول نکنند. جدا از ثبت شبکه‌هایی که یک BGP UPDATE از آن‌ها عبور می‌کند، اپراتورها می‌توانند AS_PATH را برای اعمال سیاست‌های مسیریابی، مثل دور زدن یا عبور عمدی از یک AS خاص، بررسی کنند — مثلاً برای جلوگیری از اثرات غیرمنتظرهٔ anomalies در BGP.

BGP بر پایهٔ اعتماد ساخته شده و AS_PATH به‌راحتی قابل دستکاری است — چه برای دلایل به‌ظاهر مشروع مانند AS prepending برای جابجایی ترافیک، و چه برای دلایل مخرب مانند کوتاه‌کردن مسیر برای جذب مصنوعی ترافیک یا انجام حملات origin.

بیایید ببینیم این دو نوع دستکاری مخرب چگونه اجرا می‌شوند.

مثال 1: حملات جعل-origin

در این سناریوها معمولاً چیزهایی شبیه موارد زیر رخ می‌دهد:

• AS64506 مسیرهایش را با یک RPKI ROA امضا می‌کند تا جلوی hijack شدن origin را بگیرد (RPKI-ROV). ✅

• AS64506 یک شیٔ ASPA ایجاد کرده و فقط AS64503 را به‌عنوان provider معتبر مشخص می‌کند. 🔐

• AS64505 AS_PATH را دستکاری می‌کند تا ASN خودش را حذف کند و وانمود کند منشاء مسیر AS64506 است. 🎭

• AS64502 (یک peer یا provider در زنجیره) بررسی First AS را اعمال نمی‌کند. ⚠️

نتیجه: مسیر به‌صورت RPKI-ROV valid ظاهر می‌شود و چون کوتاه به‌نظر می‌رسد، ترافیک را به‌طور مؤثر ربوده می‌کند. AS64506 همهٔ کارهای لازم (ROA و ASPA) را انجام داده، اما مهاجم در نقش AS64505 با حذف ASN خودش از AS_PATH توانسته وانمود کند که خودش AS64506 است؛ بنابراین حتی اگر AS64501 (مشتری) و AS64502 (provider) ASPA validation اجرا کنند، مسیر نامعتبر تشخیص داده نمی‌شود. راه‌حل ساده و مؤثر برای جلوگیری از این نوع hijack، اعمال enforcement روی First AS در AS_PATH است. اگر AS64502 قاعدهٔ First AS را اجرا می‌کرد، مسیر از AS64505 به‌درستی کنسل می‌شد.

مثال 2: کوتاه‌کردن AS_PATH برای جذب ترافیک

در سناریوی دیگری:

• AS64506 دو transit provider دارد: AS64503 و AS64505.

• AS64505 پذیرش هزینهٔ پهنای‌باند را بر اساس نسبت ترافیک مشتری‌ها محاسبه می‌کند.

• AS64505 خودش را از مسیر حذف می‌کند (strip) و peer آن، AS64504، بررسی First AS را اعمال نمی‌کند.

نتیجه: الگوریتم انتخاب مسیر BGP از AS64501 مسیر از طریق AS64504 را به‌عنوان بهترین مسیر برمی‌گزیند. AS64506 به هر دو provider پول می‌دهد، ولی چون AS64505 مسیر کوتاه‌تری از منابع دورتر ارائه می‌دهد، تمام ترافیک از طریق AS64505 عبور می‌کند و AS64503 که انتظار دریافت سهم خودش را دارد، درآمدی نمی‌برد. این نوع سوء‌استفاده هم با اعمال rule سادهٔ First AS matching در همسایگی‌های BGP حل می‌شود.

چطور باید First AS را اعمال کرد؟

وقتی اپراتور یک neighbor BGP را پیکربندی می‌کند، remote AS شبکه‌ای که به آن متصل می‌شود را مشخص می‌کند. اگر First AS در AS_PATH با این مقدار تطابق نداشته باشد، مسیر دستکاری شده است. پروسهٔ اعمال First AS در Section 6.3 از RFC 4271 به‌وضوح توضیح داده شده است:

“If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost (with respect to the position of octets in the protocol message) AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH.”

RFC 7606 بعداً روش‌های مربوط به error-handling توسط vendors را بازبینی کرده و پیشنهاد می‌دهد که مسیرهای حاوی AS_PATHهای malformed باید با روش treat-as-withdraw حذف شوند. این امکان را می‌دهد تا روترها prefixهای خاصی را به‌خاطر attributes نامعتبر حذف کنند بدون اینکه کل جلسهٔ BGP قطع شود. طرح فعلی ASPA هم اهمیت enforcement روی First AS را به‌صراحت یادآور می‌شود، چون ASPA نمی‌تواند مسیرهایی را که به‌خاطر اعلان‌های malformed اطلاعات AS_PATH کافی ندارند، پوشش دهد. بنابراین اجرای First AS برای امنیت مسیریابی اینترنت ضروری است.

اندازه‌گیری با نقض عمدی قانون First AS

به‌جای تکیه صرف روی موارد نظری و حوادث عمومی گذشته دربارهٔ نقض قانون First AS، ما خواستیم خودمان بسنجیم این نقض‌ها تا چه حد روی اینترنت پذیرفته می‌شوند. برای این کار به‌صورت کنترل‌شده اعلان‌های BGP را به همسایگان ارسال کردیم که در آن‌ها عمداً قانون First AS نقض شده بود. کارهایی که انجام دادیم عبارت بودند از:

• اختصاص دو prefix (یکی IPv4 و یکی IPv6) برای اعلان به Tier 1 EBGP neighbors

• عمداً تبلیغات مربوط به prefixهای تست را طوری prepended/دستکاری کردیم که First AS در AS_PATH با remote AS واقعی همخوانی نداشته باشد، تا ببینیم کدام Tier 1ها این مسیرهای malformed را قبول یا رد می‌کنند و مسیرها تا کجا انتشار می‌یابند.

در ادامه گزارش، نتایج این آزمایش‌ها و مشاهدات دربارهٔ نحوهٔ پذیرش یا رد AS_PATHهای ناقص/جعلی توسط شبکه‌های بزرگ را بررسی می‌کنیم و توصیه‌هایی عملی برای اپراتورهای DevOps / SRE ارائه می‌دهیم تا بتوانند هم‌پوشانی‌هایی مثل First AS enforcement را در شبکه‌های خود تقویت کنند. 🔧🌐