Уцечка BGP-маршрутаў прывяла да масавага парушэння складнасці ў інтэрнэце

Кампанія Cloudflare апублікавала справаздачу аб учорашнім інцыдэнце, у выніку якога на працягу трох гадзін з 13:34 да 16:26 (MSK) назіраліся праблемы з доступам да шматлікіх рэсурсаў у глабальнай сетцы, уключаючы інфраструктуру Cloudflare, Facebook, Akamai, Apple, Linode і Amazon AWS. Праблемы ў інфраструктуры Cloudflare, якая падае CDN для 16 млн сайтаў, назіраліся з 14:02 да 16:02 (MSK). Па адзнацы Cloudflare падчас збою фіксавалася страта прыблізна 15% глабальнага трафіку.

Праблема была выклікана уцечкай маршрутаў праз BGP, падчас якой каля 20 тысяч прэфіксаў для 2400 сетак былі некарэктна перанакіраваны. Крыніцай уцечкі быў правайдэр DQE Communications, які выкарыстоўваў ПЗ BGP Optimizer для аптымізацыі маршрутызацыі. BGP Optimizer разбівае IP-прэфіксы на драбнейшыя, напрыклад, падзяляе 104.20.0.0/20 на 104.20.0.0/21 і 104.20.8.0/21, і, як следства, DQE Communications трымаў на сваім боку большая колькасць спецыфічных маршрутаў, маршруты (г.зн. замест агульных маршрутаў да Cloudflare выкарыстоўваліся больш грануляваныя маршруты да пэўных падсетак Cloudflare).

Дадзеныя кропкавыя маршруты былі анансаваныя аднаму з кліентаў (Allegheny Technologies, AS396531), які таксама меў падлучэнне праз яшчэ аднаго правайдэра. Allegheny Technologies трансляваў атрыманыя маршруты іншаму транзітным правайдэру (Verizon, AS701). З-за адсутнасці належнага фільтравання BGP-анонсаў і абмежаванні на колькасць прэфіксаў, Verizon падхапіў дадзены анонс і трансляваў атрыманыя 20 тысяч прэфіксаў для астатняга інтэрнэту. Некарэктныя прэфіксы з-за сваёй грануляванасці былі ўспрыняты як больш прыярытэтныя, бо канкрэтны маршрут мае больш высокі прыярытэт, чым агульны.

У выніку, трафік для шматлікіх буйных сетак стаў накіроўвацца праз Verizon да дробнага правайдэру DQE Communications, не здольнаму апрацаваць які нарынуў струмень, што прывяло да калапсу (эфект параўнаем з тым, як калі б частку нагружанай аўтастрады замянілі на прасёлкавую дарогу).

Для прадухілення ўзнікненне падобных інцыдэнтаў у будучыні
рэкамендавана:

• выкарыстоўваць верыфікацыю анонсаў на аснове RPKI (BGP Origin Validation, дазваляе прыём анонсаў толькі ад уладальнікаў сеткі);
• Абмежаваць максімальную колькасць прэфіксаў, якія прымаюцца для ўсіх сеансаў EBGP (настройка maximum-prefix дапамагла б адразу адкінуць перадачу 20 тысяч прэфіксаў у рамках аднаго сеанса);
• ужываць фільтраванне на аснове рэестра IRR (Internet Routing Registry, вызначае AS праз якія дапушчальная маршрутызацыя зададзеных прэфіксаў);
• Выкарыстоўваць на маршрутызатарах рэкамендуемыя ў RFC 8212 налады для блакавання па змаўчанні ('default deny');
• Спыніць неабдуманае выкарыстанне аптымізатараў BGP.

Крыніца: opennet.ru