vk_logo twitter_logo facebook_logo youtube_logo telegram_logo telegram_logo

История одного BGP hijack, или необходимо ли фильтровать full-view от аплинков 1

Дата публикации: 26.04.2018
Количество просмотров: 5300
Автор:

Идея написать статью о необходимости ревизии принимаемых от аплинков BGP full-view (FV) анонсов возникла еще в конце прошлого года, после обнаруженного большого количества hidden (rejeceted by import policy) маршрутов принятых после включения очередного аплинка в Казахстане. Более детальный анализ показал "богатость" as-path отфильтрованных по prefix lendth  маршрутов, т. е. специфичных по длине маски чем /24. В тоже время были проанализированы еще с десяток FV от разных апстримов, а также маршруты, принимаемые с обменников (IX - Internet Exchange). По сути оказалось, что дела  у остальных обстоят не намного лучше увиденного в Казахстане.

Новые проекты, решение текущих задач отодвинули эту идею на второй план, и в некоторой степени она даже подзабылась. Но произошедший вчера, 24 апреля 2018 года, случай BGP hijack с инфраструктурным значимым префиксом Amazon (для фишинговой атаки на "MyEtherWalet" (MEW)) AS10297 был "угнан" префикс принадлежащий Amazon префикс 205.251.192.0/24, к которому привязаны корневые DNS сервера Amazon. В результате DNS-запросы пользователей, которые в качестве DNS-серверов использовали DNS Amazon перенаправлялись на подменный DNS-сервер злоумышленников, где myethewallet.com резолвился в IP-адрес фишингового сайта, работающего по протоколу HTTP, т. е. без SSL, или использующего поддельные сертификаты. По сообщениям пользователей Твитер атака длилась несколько часов и злоумышленникам удалось похитить значимое количество криптовалюты благодаря скомпрометированным данных пользователей.
Сначала в Твитере появилось сообщение, что это произошло с DNS Google и выглядело очень правдоподобным на фоне наблюдаемых вчера проблем со знаменитыми 8.8.8.8 и 8.8.4.4.  


 

Немного позже пользователи начали оставлять комментарии, что произошедшее случилось все-таки с DNS Amazon.

Оригинальный префикс Amazon имеет длину маски /23:


whois -h whois.radb.net 205.251.192.0/23 | grep descr
descr:      Amazon prefix

205.251.192.0/23   *[BGP/170] 2w3d 03:59:28, MED 20, localpref 100
AS path: 3257 16509 I, validation-state: unverified


Для атаки был применен так называемый more specific prefix 205.251.192.0/24, который при маршрутизации трафика всегда выигрывает перед less specific  205.251.192.0/23. Данный вид атаки по сути является очень древним, происходит с довольно часто (раз в несколько месяцев случаются довольно громкие события, по значимости аналогичны вчерашнему), и называется BGP Hijack.

Ниже на скриншоте наглядно отображен результат произошедшего с применением аналитического сервиса RIPE BGPlay: 

 

Из данного слайда видно, что префикс был проансирован AS10297 (eNET Inc., одним из американских хостинг провайдеров) в Tier1 AS6939 (Hurricane Electric), что позволило подвергнуть атаке довольно большое количество автономных систем.

Скриншот браузера при попытке открытия фишингового сайта:

К сожалению, многие пренебрегли подобными предупреждениями.

Из начала статьи можно предположить почему подобное возможно. Ниже представлен слайд презентации из выступления на одном из недавних мероприятий в городе Алма-Ата, наглядно отображающий суть BGP Hijack и не требующий комментариев.

Подобное возможно по двум причинам:

  1. Аплинки не осуществляют фильтрацию клиентских анонсов по атрибуту origin с использованием записей из баз IRR (часто причиной тому являются "раздутые" клиентские as-sets и вендорские аппаратные ограничения по количеству строк конфигурационных файлов, но в большей степени - это безразличие, нежелание что-либо внедрять, отсутствие компетенции);
  2. Со стороны клиентов нет ревизии принимаемых маршрутов FV на предмет фильтрации не принятых к распространению маршрутов, в т.ч. специфичных чем /24.


На слайдах выше показаны отфильтрованные в FV маршруты, специфичней чем /24, а также их количество.
Отсутствие подобной фильтрации в операторских сетях позволяет злоумышленникам без каких-либо проблем сделать inject префикса жертвы.

К сожалению, каких-либо жестких ограничений на анонсы спецификов не существует.

В RFC 7454 "BGP Operations and Security", в частности, отмечается, что RIPE рекомендует не анонсировать и не принимать в Интернет для IPv4 специфичней чем /24, и для IPv6 специфичней /48.

Рекомендую в качестве import policy для аплинков применить что-то подобное и вы увидите в своих таблицах тоже hidden routes :)


>show configuration policy-options policy-statement sanity-check-Upstream
term bogons-reject {
   from policy bogons;
   then reject;
}
term bogons-as-reject {
from as-path grey-as;
then reject;
}
term long-prefixes-reject {
from {
route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
}
}
​then next policy;

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/101232/istoriya-odnogo-bgp-hijack-ili-neobhodimo-li-filtrovat-full-view-ot-aplinkov.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться