Cloudflare публикува подробности за 25-минутен BGP route leak, настъпил на 22 януари, който е засегнал IPv6 трафика в глобален мащаб. Инцидентът е довел до измерима конгестия, загуба на пакети и приблизително 12 Gbps дропнат трафик, като ефектът не се е ограничил само до клиенти на Cloudflare, а е засегнал и външни мрежи в интернет.

Какво представлява BGP и защо подобни инциденти са критични

Border Gateway Protocol (BGP) е основният механизъм за маршрутизация между автономни системи (AS) в интернет. Чрез него различните мрежи обменят информация за наличните маршрути и насочват трафика към крайните дестинации през множество междинни оператори.

При грешка в BGP конфигурацията, маршрутите могат да бъдат рекламирани към мрежи, които не би трябвало да ги получават, което води до:

• неочаквано пренасочване на трафик;

• задръствания и нестабилни пътища;

• пълно отхвърляне на трафик при наличие на филтри.

Какво се е случило при Cloudflare

Според официалното съобщение на Cloudflare, инцидентът е причинен от непреднамерена грешка в routing policy на рутер в Маями.

„По време на инцидента на 22 януари предизвикахме route leak, при който маршрути, получени от някои наши peers, бяха преразпределени в Маями към други peers и доставчици“, посочват от Cloudflare.

По дефинициите на RFC 7908, това представлява комбинация от Type 3 и Type 4 route leak.

Какво е Type 4 route leak

Type 4 route leak възниква, когато автономна система наруши т.нар. valley-free routing правила, като рекламира маршрути, научени от peer или доставчик, към друг peer или доставчик.

Резултатът е, че:

• трафикът се насочва през мрежа, която не е проектирана да го пренася;

• възникват конгестия и загуби на пакети;

• при строги firewall политики трафикът може да бъде напълно отхвърлен.

Valley-free правилата описват допустимия начин на разпространение на маршрути според бизнес отношенията между операторите. Нарушаването им води до привличане на трафик към неподходящи или нестабилни пътища, какъвто е бил и този случай.

Техническа първопричина

Cloudflare обяснява, че проблемът произтича от промяна в policy, целяща да предотврати рекламирането на Bogotá IPv6 префикси от локацията в Маями.

Премахването на специфични prefix листи обаче прави export policy-то прекалено разрешително. Това позволява вътрешно правило да съвпадне с всички iBGP IPv6 маршрути, които след това са експортирани към външни BGP съседи.

В резултат:

• всички IPv6 префикси, разпространявани вътрешно в Cloudflare backbone-а;

• са били рекламирани към всички BGP съседи в Маями;

• което е довело до масово пренасочване и дропване на трафик.

Реакция и овладяване на инцидента

Cloudflare засича проблема малко след възникването му. Инженерите:

• ръчно връщат конфигурацията;

• временно спират автоматизацията;

• ограничават въздействието до около 25 минути.

По-късно проблемният код е напълно премахнат, а автоматизацията е възстановена след допълнителни проверки.

Сходство с предишни инциденти и рискове за сигурността

Компанията отбелязва, че случаят е много сходен с инцидент от юли 2020 г. Макар подобни route leak събития да се разглеждат основно като проблеми с надеждността, те имат и сериозен аспект на сигурността.

При по-злонамерени сценарии подобни грешки могат да се използват за BGP hijacking, при който неоторизирани страни:

• прихващат;

• анализират;

• или манипулират трафик.

Мерки за предотвратяване на бъдещи инциденти

Cloudflare е обявила редица стъпки за намаляване на риска от подобни събития:

• по-строги export safeguards, базирани на BGP community-та;

• CI/CD проверки за грешки в routing policy;

• подобрено ранно откриване на аномалии;

• валидиране по RFC 9234;

• активно насърчаване на RPKI ASPA като стандарт за междудомейн сигурност.

Инцидентът с BGP route leak при Cloudflare показва колко чувствителна остава глобалната интернет маршрутизация дори при големи и добре автоматизирани оператори. Една неправилна policy промяна е достатъчна да причини значителни смущения, измерими в гигабити загубен трафик. Случаят подчертава нуждата от по-строги контроли, автоматизирана валидация и масово въвеждане на RPKI механизми, за да се намали рискът от бъдещи инциденти с потенциални последици и за сигурността.