Компания 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 разделя 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 000 префикса в рамките на една сесия);
- Прилагане на филтриране на базата на IRR (Internet Routing Registry, който определя AS, през които е допустима маршрутизацията на зададените префикси);
- Използвайте на маршрутизаторите препоръчаните настройки в RFC 8212 за блокиране по подразбиране (‘default deny’);
- Прекратете необмисленото използване на оптимизатори BGP.
Източник: opennet.ru
