Перейти к содержимому
Калькуляторы
Source IP spoofing prevention  

39 пользователей проголосовало

  1. 1. предпринимаете ли вы действия для предотвращения Source IP spoofing вашими абонентами?



Source IP spoofing prevention

Потомушто URPF проверяет не наличие анонсов этих сетей, а их наличие в RIB. То есть если анонс от клиента пришел, но эта сеть лучше видна за другим оператором

Ну те при получении анонса и наличии лучшего BGP маршрута в RIB не добавляется два маршрута "через другого оператора с нормальным (высоким)" приоритетом + "через прямой интефейс с низким", а добавляется только первый. А почему? Маршрут-то через интерфейс есть. Зачем его полностью игнорировать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ох. Давно пройденный этап. Ситуация с отсутствием подобного фильтра например прекрасно использовалась при пире на IX с магистралом (да и вообще со многими).

Настраивалась маршрутизация забугорного трафика в пир, несмотря на то, что анонсов забугра от пира не было. И исходняк радостно улетал туда (и даже нормально доезжал до получателя).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Потомушто URPF проверяет не наличие анонсов этих сетей, а их наличие в RIB. То есть если анонс от клиента пришел, но эта сеть лучше видна за другим оператором

Ну те при получении анонса и наличии лучшего BGP маршрута в RIB не добавляется два маршрута "через другого оператора с нормальным (высоким)" приоритетом + "через прямой интефейс с низким", а добавляется только первый. А почему? Маршрут-то через интерфейс есть. Зачем его полностью игнорировать?

Мне кажется или мы ходим по кругу? :)

Машрут хранится в bgp rib, хранить не используемые маршруты в рутинг тэйбл слишком накладно. Почитайте про cef и tcam. В архитектуре специально отсекли несколько срезов для того что бы форвардить аппаратно, а вы опять тянете к процессорной обработка. Маршут пришел на рутер, он сравнивается с такими же роутами от этого же протокола. Затем бест сравнивается с такими же от других протоклов и только за тем попадает в риб. По аналогии можно весь хард запихнуть в оперативку - быстрее же будет работать - просто летать :)

 

Ох. Давно пройденный этап. Ситуация с отсутствием подобного фильтра например прекрасно использовалась при пире на IX с магистралом (да и вообще со многими).

Настраивалась маршрутизация забугорного трафика в пир, несмотря на то, что анонсов забугра от пира не было. И исходняк радостно улетал туда (и даже нормально доезжал до получателя).

 

Ага, а кто-то приходил и инетерсовался, а не сольют ли нам дармовой траф:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мне кажется или мы ходим по кругу? :)

Кажется, только до сих пор не было объяснения, почему так.

 

Машрут хранится в bgp rib, хранить не используемые маршруты в рутинг тэйбл слишком накладно.

Не всех же, а только тех нетранзитных операторов, что прямо к железке прицеплены. Не так уж и много их будет. Но зато поимеем защиту от src IP spoof-а

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В чём проблема на своём бордере поставить deny в ACL для всех source, которые не Ваши?

Только в том, что это должны сделать все...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мне кажется или мы ходим по кругу? :)

Кажется, только до сих пор не было объяснения, почему так.

 

Машрут хранится в bgp rib, хранить не используемые маршруты в рутинг тэйбл слишком накладно.

Не всех же, а только тех нетранзитных операторов, что прямо к железке прицеплены. Не так уж и много их будет. Но зато поимеем защиту от src IP spoof-а

 

Дык не транзитный оператор с bgp это как? Смотрим анонс, если в анонсе не больше одной as? А если препенд? А еще есть bgp inderect next-hop. Это усложнит urpf. Его фишка в простоте, а делать один или несколько lookup для поиска возможных косяков в routing table конечно можно, но это направлено в противоположную сторону от мыслей вендоров. Собственно дело за малым выпустить RFC

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати тут обсуждают вопрос производительности... имхо, если это так критично по производительности, lookups можно было бы делать самплингом, и кидать в логи или блочить порт, если в семпле появились левые IP. Когда клиент получит по заднице за спуфинг, быстро нарисует правильные фильтры. И производительность не пострадает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати тут обсуждают вопрос производительности... имхо, если это так критично по производительности, lookups можно было бы делать самплингом, и кидать в логи или блочить порт, если в семпле появились левые IP. Когда клиент получит по заднице за спуфинг, быстро нарисует правильные фильтры. И производительность не пострадает.

 

Это плохо с prefix-limit работает, а уж со спуфингом до первого воя клиента не дальше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Smoke - можно не блочить, а кидать репорты на мыло. И пусть или фиксит или вносит в список своих сетей, в разумные сроки. Не внесет скажем за неделю - блокировка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Smoke - можно не блочить, а кидать репорты на мыло. И пусть или фиксит или вносит в список своих сетей, в разумные сроки. Не внесет скажем за неделю - блокировка.

 

И транзитникам тоже тогда придется, вообще идея то правильная инет станет реально чище, но внедрять тему надо сверху вниз, иначе никак. Дмитрия Буркова надо спросить были ли у ICANN попытки борьбы со спуфом через выпуск полиси или еще как. Подписывать пакеты не предлагать :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подписывать пакеты не предлагать :)

А ведь, наверное, можно. Что-то там такое в IPv6 + IPSec было... (Кстати, обязаны ли уметь шифровать IPv6 устройства? Я в свое время не понял.)

Изменено пользователем Sergey Gilfanov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, обязаны ли иметь шифровать IPv6 устройства?

 

Если даже де-юре(выпустят какой-нибудь стандарт, а не жалкий RFC) это обяжут, то реальный мир устроен немножко по-другому и ломать совместимость в таких масштабах никто не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Smoke - можно не блочить, а кидать репорты на мыло. И пусть или фиксит или вносит в список своих сетей, в разумные сроки. Не внесет скажем за неделю - блокировка.

 

И транзитникам тоже тогда придется, вообще идея то правильная инет станет реально чище, но внедрять тему надо сверху вниз, иначе никак. Дмитрия Буркова надо спросить были ли у ICANN попытки борьбы со спуфом через выпуск полиси или еще как. Подписывать пакеты не предлагать :)

1. ICANN здесь совсем нипричем - и этому можно только радоваться

2. RIRs тоже - не дело Реестров определять routing

3. Меня N лет коллеги из-за речки и друзья спрашивают - почему мы у себя в России не введем обязательную реализацию BCP38 и BCP84

(в условиях нашего регулирования это сделать можно быстрее - чем в США)?

Вот это бы и пообсуждали - там не все так просто - сами знаете - и чем то придется пожертвовать

 

В разных документах уже появляются ссылки на эти BCP - вопрос только во времени и как лучше это сделать

 

Прошу очевидное не повторять

 

Подписывать пакеты не предлагать :)

А ведь, наверное, можно. Что-то там такое в IPv6 + IPSec было... (Кстати, обязаны ли уметь шифровать IPv6 устройства? Я в свое время не понял.)

Был я у китайцев ( CERNET )они c SAVA давно экспериментируют - только большой радости в глазах не видно было - как и заявлений об успехах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну не правда же. Просто при маршрутизации надо не только на dst смотреть, но и на src. Если src пришел с какого-то интерфейса, куда для этого src маршрута нет - пакет дропается. Это, кажется, называется Reverse path filtering.

Reverse path filtering - ой, я думаю за это могут побить на транзите... Дело в том, что маршруты ходят в обе стороны по разным путям. И по тому пути, который избрала та сторона, она может вообще свой анонс заблокировать (условный анонс может быть).

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В чём проблема на своём бордере поставить deny в ACL для всех source, которые не Ваши?

Только в том, что это должны сделать все...

Такое возможно.

Но только на стыках "оператор - клиент" или "хостинг - сервер".

Максимум на стыке "оператор - оператор, имеющий только клиентов (ну или совсем чуть чуть BGP многоногих клиентов)".

 

Это не сработает на стыке двух магистралов, у которых полно BGP многоногих клиентов - операторов, каждый из которых непременно решает задачу балансировки своих аплинков.

 

Как уже говорили - проблема в американских дата-центрах. А их тут на месте не зафильтруешь даже если они поставят российский IP, потому как есть петли трафика и даже российский IP источника позволителен магистралу...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2. RIRs тоже - не дело Реестров определять routing

 

Тогда нафига эти реестры нужны? Тупо выделять адреса и всё? RIPE же вполне успешно справляется с поддержанием БД route-object'ов и AS-SET'ов. Если заставить всех операторов заполнять эти данные в RIR, то можно было бы нормально строить фильтры, по крайней мере в сторону пиров с небольшим кол-вом анонсируемых префиксов(грубо говоря, в сторону клиентов и маленьких IX).

 

Кстати, на крупнейших IX, RS фильтруют префиксы(bgp updates) от участников, подключенных к RS-серверу?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2. RIRs тоже - не дело Реестров определять routing

 

Тогда нафига эти реестры нужны? Тупо выделять адреса и всё? RIPE же вполне успешно справляется с поддержанием БД route-object'ов и AS-SET'ов. Если заставить всех операторов заполнять эти данные в RIR, то можно было бы нормально строить фильтры, по крайней мере в сторону пиров с небольшим кол-вом анонсируемых префиксов(грубо говоря, в сторону клиентов и маленьких IX).

 

Кстати, на крупнейших IX, RS фильтруют префиксы(bgp updates) от участников, подключенных к RS-серверу?

 

Тут дело в валидности информации. RIPE никак не проверяет информацию в as-set Да и route-object есть варианты сделать для сетей которые тебе не принадлежат.. Забор он и есть забор. И это именно потому, что они не лезут в полиси раутинг лиров.

С другой стороны операторы сами самоорганизоватся для разработки такой политики тоже не смогут. Собственно этот статус-кво мы и наблюдаем

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все правильно привели, если у клиента BGP то strict mode - зло. И не важно одно у него включение в вас или 2. Strict URPF и BGP вместе использовать нельзя.

Это наша историческая данность. Так как у нас клиенты не считают зазорным балансировать трафик спецификами или префиксами, но при этом не раскладывать аналогично PBR-ом трафик в обратную сторону...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все правильно привели, если у клиента BGP то strict mode - зло. И не важно одно у него включение в вас или 2. Strict URPF и BGP вместе использовать нельзя.

Это наша историческая данность. Так как у нас клиенты не считают зазорным балансировать трафик спецификами или префиксами, но при этом не раскладывать аналогично PBR-ом трафик в обратную сторону...

 

А где считают по другому? Примеры полиси или хотя бы рекомендации кто-нить видел?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В чём проблема на своём бордере поставить deny в ACL для всех source, которые не Ваши?

Только в том, что это должны сделать все...

Такое возможно.

Но только на стыках "оператор - клиент" или "хостинг - сервер".

Именно там оно и должно стоять.

Или Вы считаете, что магистрал своих клиентов не-операторов включает прямо в магистраль, без бордера?

Также можно поставить и на стыке оператор доступа (ластмильщик, хостер) - магистрал, лучше со стороны оператора доступа, чем со стороны магистрала. А на стыках магистрал-магистрал это не нужно, нет в магистрали ни клиентских компов ни серверов, только маршрутизаторы, которые не спуфят по-определению.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут дело в валидности информации. RIPE никак не проверяет информацию в as-set Да и route-object есть варианты сделать для сетей которые тебе не принадлежат.. Забор он и есть забор. И это именно потому, что они не лезут в полиси раутинг лиров.

С другой стороны операторы сами самоорганизоватся для разработки такой политики тоже не смогут. Собственно этот статус-кво мы и наблюдаем

Как только Ваш магистрал объявит, что у него робот строит по ночам фильтр анонсов по базе RIPE, то Вы наперегонки побежите актуализировать надписи на этом "заборе".

 

Поэтому собственно говоря база RIPE хотя и содержит уже устаревшие сведения (часть мертвых линков там числятся живыми) но в целом верна и позволяет строить фильтры. Заслуга в этом нескольких крупных российских магистралов.

 

Так сказать именно самоорганизовалось все.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут дело в валидности информации. RIPE никак не проверяет информацию в as-set Да и route-object есть варианты сделать для сетей которые тебе не принадлежат.. Забор он и есть забор. И это именно потому, что они не лезут в полиси раутинг лиров.

С другой стороны операторы сами самоорганизоватся для разработки такой политики тоже не смогут. Собственно этот статус-кво мы и наблюдаем

Как только Ваш магистрал объявит, что у него робот строит по ночам фильтр анонсов по базе RIPE, то Вы наперегонки побежите актуализировать надписи на этом "заборе".

 

Поэтому собственно говоря база RIPE хотя и содержит уже устаревшие сведения (часть мертвых линков там числятся живыми) но в целом верна и позволяет строить фильтры. Заслуга в этом нескольких крупных российских магистралов.

 

Так сказать именно самоорганизовалось все.

Ну вы сами ответили уже в своем посте о том что информация там устаревшая, что не мешает фильтрам работать, но отнимает лишние ресурсы у магистрала. И на большом масштабе простынии вылязят ой-ёй-ёй. Это еще далеко не все префиксы подтягивают. А так да - за заслугу спасибо - польщен :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Потомушто URPF проверяет не наличие анонсов этих сетей, а их наличие в RIB. То есть если анонс от клиента пришел, но эта сеть лучше видна за другим оператором то исходняк магистрал отправит в другого оператора. И все бы ничего но при включенном URPF магистрал еще дропнет входящий трафик и клиент останется без связи. То есть BGP сам по себе предпологает работу в ассиметричном режиме, а URPF эту логику ломает. Ну и заметьте засунуть анонс в routing table или нет решает роутер магистрала, на который клиент имеет косвенное влияние ибо рулит Local Pref.

FYI: в Juniper уже ну очень давно имеется опция 'unicast-reverse-path feasible-paths', при включении которой strict URPF не дропает входняк, если он прилетел не оттуда, куда смотрит best path. Важно лишь, чтобы анонс не-best маршрута таки существовал (отдавался клиентом), пусть хоть с безмерным хвостом препендов. Что, увы, отнюдь не всегда имеет место

 

А начиная с версии 12.2, в JunOS появился механизм валидации origin-AS маршрутов. Сомневаюсь, что его кто-то уже использует, но таки тенденция. От route leaks оно вряд ли спасёт, но пресечь хайджеки теоретически может imho

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Оно и в циске также - 2 режима URPF.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Оно и в циске также - 2 режима URPF.

strict & loose? Loose от спуфинга практически не спасает

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас