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

[pers123]

В связи с тем, что за последние полгода по интернету прокатилась волна DDOSа в рамках, которой активно использовались всяческие

методы UDP floodа активно использующего source IP spoofing (включая DNS amplification), провожу опрос среди операторов о мерах

с их стороны, которые могут предупредить развитие подобных атак.

Просьба отвечающих "нет" - прокомментировать почему...

Изменено 3 июля, 2013 пользователем pers123

[bitbucket]

Плохо то, что всякие папуасии-америкосии в своих датацентрах с хостингом на source IP spoofing забили.

[pers123]

Плохо то, что всякие папуасии-америкосии в своих датацентрах с хостингом на source IP spoofing забили.

Интересно, а отечественные лидеры шпд в лице ростелека, Эр-телекома, корбины, и прочих имеют ли такую практику?

[Sergey Gilfanov]

Вопрос несколько более глобального плана. А на стыках с нетранзитными операторами IP пакеты с 'не их' src кто-нибудь фильтрует?

[srg555]

Плохо то, что всякие папуасии-америкосии в своих датацентрах с хостингом на source IP spoofing забили.

Интересно, а отечественные лидеры шпд в лице ростелека, Эр-телекома, корбины, и прочих имеют ли такую практику?

 

Проверил через домашнее подключение Ростелекома (pppoe, bras huawei, судя по мак-адресу). Спуфинг режется.

 

Методика проверки:

modprobe dummy

ifconfig dummy0 1.1.1.1 netmask 255.255.255.255

iptables -t nat -I POSTROUTING -s 1.1.1.1 -j RETURN

ping -I 1.1.1.1 IP_ДРУГОГО_ХОСТА

 

На другом_хосте смотрел прилетают ли пакет с 1.1.1.1

 

Думаю, что большинство брендированных BRAS решений режут IP спуф по умолчанию(и даже не факт что это можно отключить)

[m0xf]

Интересно, а отечественные лидеры шпд в лице ростелека, Эр-телекома, корбины, и прочих имеют ли такую практику?

Эр-телеком года два назад не резал, сейчас не знаю.

[Tosha]

Это дело совести провайдера.

Вопрос несколько более глобального плана. А на стыках с нетранзитными операторами IP пакеты с 'не их' src кто-нибудь фильтрует?

Это очень тяжелая задача на транзитном уровне. TCAM не напасешься...

[Sergey Gilfanov]

Вопрос несколько более глобального плана. А на стыках с нетранзитными операторами IP пакеты с 'не их' src кто-нибудь фильтрует?

Это очень тяжелая задача на транзитном уровне. TCAM не напасешься...

Ну не правда же. Просто при маршрутизации надо не только на dst смотреть, но и на src. Если src пришел с какого-то интерфейса, куда для этого src маршрута нет - пакет дропается. Это, кажется, называется Reverse path filtering. Еще раз напоминаю, что речь идет только о стыках с нетранзитными операторами. А 'легитимное' использование несимметричного роутинга пусть делают выставлением метрик и весов. Ибо нефиг. Если IP xxx.xxx.xxx.xxx не может быть смаршрутизирован в интерфейс Eth0/12 - то и приходить он оттуда не должен.

Изменено 5 июля, 2013 пользователем Sergey Gilfanov

[bitbucket]

Если IP xxx.xxx.xxx.xxx не может быть смаршрутизирован в интерфейс Eth0/12 - то и приходить он оттуда не должен.

На основании каких таблиц это должно проверятся ? Только kernel или еще в quagga/bgp/ospf смотреть ? Если первое - то не будет работать в случае не симметричных путей, если второе - то привет производительности.

[Sergey Gilfanov]

На основании каких таблиц это должно проверятся ? Только kernel или еще в quagga/bgp/ospf смотреть ? Если первое - то не будет работать в случае не симметричных путей, если второе - то привет производительности.

Только kernel. И (разумный) пример с ассиметрией можно? Такой, чтобы интерфейс аплинка пакеты от сети принимает, но маршрута на эту сеть (пусть и с метрикой ниже плинтуса) не имеет. Причем широко применяемый пример, те который оправдывает отключение Reverse path filtering по умолчанию.

[bitbucket]

Только kernel. И (разумный) пример с ассиметрией можно? Такой, чтобы интерфейс аплинка пакеты от сети принимает, но маршрута на эту сеть (пусть и с метрикой ниже плинтуса) не имеет. Причем широко применяемый пример, те который оправдывает отключение Reverse path filtering по умолчанию.

2 канала до клиента для резервирования с одинаковыми настройками bgp. В kernel будет только одна запись маршрута до клиента - через какой-то канал, но запись будет одна. У клиента default/что-там-еще может вполне легко идти в канал, через который клиент трафик не получает. Вариант 2 - та же схема, но трафик сбалансирован между каналами путем раскидывания сеток в разные каналы. А весь обратный трафик идет через один из каналов (так как его меньше и раскидывать его не надо).

[Sergey Gilfanov]

2 канала до клиента для резервирования с одинаковыми настройками bgp. В kernel будет только одна запись маршрута до клиента - через какой-то канал, но запись будет одна.

Это, возможно, нестандартно, но почему одна-то? А не две с одинаковой метрикой?

 

У клиента default/что-там-еще может вполне легко идти в канал, через который клиент трафик не получает.

Отсылать с каких-то своих сетей трафик в default, но не объявлять в сторону этого default эти свои сети - это как-то странно. И как-раз должно резаться как попытка source IP spoofing.

 

Вариант 2 - та же схема, но трафик сбалансирован между каналами путем раскидывания сеток в разные каналы. А весь обратный трафик идет через один из каналов (так как его меньше и раскидывать его не надо).

А вот нефиг. 'Сеть в интерфейс не объявляется' == 'этой сети за интефейсом нет'. Соответственно, потрудись сделать так, чтобы трафик с необъявляемых сетей в такой интерфейс не уходил.

[nuclearcat]

Отсылать с каких-то своих сетей трафик в default, но не объявлять в сторону этого default эти свои сети - это как-то странно. И как-раз должно резаться как попытка source IP spoofing.

Есть такие операторы которые режут все приоритеты и т.п., так, что проще в их сторону анонсы направлять только когда это жизненно необходимо.

[zi_rus]

 

Отсылать с каких-то своих сетей трафик в default, но не объявлять в сторону этого default эти свои сети - это как-то странно. И как-раз должно резаться как попытка source IP spoofing.

 

А вот нефиг. 'Сеть в интерфейс не объявляется' == 'этой сети за интефейсом нет'. Соответственно, потрудись сделать так, чтобы трафик с необъявляемых сетей в такой интерфейс не уходил.

он мог объявить но с некоторым препендом таким что трафик до него должен отправляться через другой канал или backup community или любая другая причина когда маршруты объявлены на стыке, но оказались хуже чем пройти через другой канал

[Sergey Gilfanov]

он мог объявить но с некоторым препендом таким что трафик до него должен отправляться через другой канал или backup community или любая другая причина когда маршруты объявлены на стыке, но оказались хуже чем пройти через другой канал

А это не должно приводить к ситуации 'два маршрута с разным приоритетом'? Один - тот, который 'через другой канал'. Другой - непосредственно через

интерфейс, но с приоритетом пониже.

[zi_rus]

должно, но только на уровне бгп

на уровне RIB, а потом и TCAM будет один маршрут через другой канал

[Sergey Gilfanov]

должно, но только на уровне бгп

на уровне RIB, а потом и TCAM будет один маршрут через другой канал

Эээ... А почему? Железо не умеет? И что происходит, когда я вручную два статических маршрута на сеть через разные интерфейсы и с одинаковой метрикой в конфиг вставлю?

[Smoke]

должно, но только на уровне бгп

на уровне RIB, а потом и TCAM будет один маршрут через другой канал

Эээ... А почему? Железо не умеет? И что происходит, когда я вручную два статических маршрута на сеть через разные интерфейсы и с одинаковой метрикой в конфиг вставлю?

 

Обалансится, в FIB будет 2 next-hop. Заканчивайте изобретать велосипед. На стаб подключение вешается strict URPF, на остальные loose или не вешается вовсе.

[zi_rus]

должно, но только на уровне бгп

на уровне RIB, а потом и TCAM будет один маршрут через другой канал

Эээ... А почему? Железо не умеет? И что происходит, когда я вручную два статических маршрута на сеть через разные интерфейсы и с одинаковой метрикой в конфиг вставлю?

есть одинаковая метрика а есть разная

[Sergey Gilfanov]

Обалансится, в FIB будет 2 next-hop. Заканчивайте изобретать велосипед. На стаб подключение вешается strict URPF, на остальные loose или не вешается вовсе.

Ага, значит соответствующая строчка в настройке все-таки есть. Тогда переформурирую вопрос: "А магистралы этой настройкой пользуются?"

[Smoke]

Обалансится, в FIB будет 2 next-hop. Заканчивайте изобретать велосипед. На стаб подключение вешается strict URPF, на остальные loose или не вешается вовсе.

Ага, значит соответствующая строчка в настройке все-таки есть. Тогда переформурирую вопрос: "А магистралы этой настройкой пользуются?"

 

Статической балансировкой? Пользуются канеш. Например, если у клиента 2*e1 и он MLPPP не умеет. Или вы про URPF? Тут тоже ответ да - loose помогает от трафика из bogon сетей, ну и стрикт на стабы.

[Sergey Gilfanov]

Я про URPF. Тут мне выше привели (как распространенный) пример, когда оно будет все ломать. Вот я по этому примеру и удивлялся.

[Smoke]

Я про URPF. Тут мне выше привели (как распространенный) пример, когда оно будет все ломать. Вот я по этому примеру и удивлялся.

 

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

[Sergey Gilfanov]

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

Ага. Пример был

он мог объявить но с некоторым препендом таким что трафик до него должен отправляться через другой канал или backup community или любая другая причина когда маршруты объявлены на стыке, но оказались хуже чем пройти через другой канал

Последовал мой вопрос:

А это не должно приводить к ситуации 'два маршрута с разным приоритетом'? Один - тот, который 'через другой канал'. Другой - непосредственно через

интерфейс, но с приоритетом пониже.

То, что URPF и BGP несовместимы, говорит о том, что для нужд проверок URPF какого-то маршрута не будет. А почему так?

[Smoke]

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

Ага. Пример был

он мог объявить но с некоторым препендом таким что трафик до него должен отправляться через другой канал или backup community или любая другая причина когда маршруты объявлены на стыке, но оказались хуже чем пройти через другой канал

Последовал мой вопрос:

А это не должно приводить к ситуации 'два маршрута с разным приоритетом'? Один - тот, который 'через другой канал'. Другой - непосредственно через

интерфейс, но с приоритетом пониже.

То, что URPF и BGP несовместимы, говорит о том, что для нужд проверок URPF какого-то маршрута не будет. А почему так?

 

 

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