Как стать автором
Обновить

Комментарии 26

А у вас роутеры умеют flow spec, поэтому рекомендую использовать ExaBGP или GoBGP для выката правил в полу-автоматическом либо автоматическом режиме :)
В данном контексте — я не уверен, что IX и flow spec — это слова которые можно говорить в одном предложении. В России даже не все магистральные провайдеры его поддерживают.
Не, я про ваш роутер. iBGP, а не eBGP. Удобно подавать команды не по CLI, а по универсальному сигнальному протоколу.
Теперь понял. Такую схему не тестировали, но предположу, что это действительно удобно.
flowspec, afaik, не умеет ставить фильтры по src-mac
Так что flowspec это l3+
Да, flow spec не умеет mac. Для рулежа ФСД можно netconf :)
Кстати, Алексей, а есть ли цифры, как много трафика сваливается в каждый из IX?
Об этом напишу отдельную статью.
а это коммерческая тайна =)
Почему? Я спокойно могу пошарить соотношения трафика, который у меня выливается относительно MSK-IX, SPB-IX, Data-IX. Но я — генератор трафика. У ШПД будет сильно иная картина.
Трафик генерируем мы и скрывать его особого смысла не вижу.
Это же можно просто отдать в sflow, а на уровне sflowtools анализировать и пакеты с мак-адресами.
Ну и я не вижу ничего tcp syn flood специфичного.
Да, у меня было мыслью для FastNetMon сделать такую фичу, но у нас не так много IX с основной точке присутствия и обычно трафик льется по L3 уже с апстримов.
у нас IX'ов очень много, но полностью выносить кого-то мак-фильтром на своей стороне неправильно — у него же продолжает быть связность с роут-серверами, и он видит твои префиксы через них. Т.е. ты полностью теряешь связность с кем-то.
Неправильно, безусловно. Правильное решение — дернуть blackhole на данном IX для данного конкретного клиента, чтобы он прекратил лить трафик. Но если он не принимает блэкхол коммунити — ему этот анонс будет пофигу и он продолжить лить говно, увы.
Если канал позволяет это может быть наименьшим из зол:

term 00:03:fe:0a:ac:00 {
    from {
        source-mac-address {
            00:03:fe:0a:ac:00/48;
        }
        ip-destination-address {
            # адрес атакуемого сервера
        }
        destination-port {
            # атакуемый порт
        }
        ip-protocol {
            tcp;
        }
        tcp-flags {
            syn;
        }
    }
    then {
        discard;
    }
}

В этом случае даже с этого источника другие сервисы будут работать. Но я еще раз повторюсь — это не идеальное решение, а только один из вариантов.
Про дропы по мак-адресам по-моему совершенно правильно критикуют.
У меня ничего проще не получалось в такой ситуации, чем включить loose rpf на аплинках, и с анализатора netflow/ipfix анонсировать на бордер source-адреса флуда в комьюнити с локальным блэкхолом.
syn flood идет с подменой адреса источника, не очень понял про "source-адреса флуда в комьюнити с локальным блэкхолом". DST IP можно отправить в blackhole, только не все IX принимают blackhole и в любом случае это приведет к большей недоступности чем данная блокировка.
По опыту полученных ddos'ов — довольно редко идёт подмена адреса источника.
Почти у всех провайдеров включен urpf. Много трафика генерят заражённые хосты из датацентров, а там urpf включен ещё чаще чем у провайдеров обычных домашних пользователей.

Блэкхол может быть локальным для бордера, без перераздачи полученного анонса аплинкам.
Просто для того чтобы работал loose rpf.
Получаем анонсы с определённым комьюнити — помещаем в fib с next-hop discard, и нужен junos >=12.1 чтобы была возможность включить rpf-loose-mode-discard.
По опыту полученных ddos'ов — довольно редко идёт подмена адреса источника.

— у меня совершенно другой опыт. И крайне редко идет без подмены src ip. Может кто собирал статистику?

На межоператорских стыках uRPF не включен — там асинхронная маршрутизация и полная связанность, то есть не факт, что пакет придя по одному каналу туда же и уйдет.
uRPF loose mode подразумевает — неважно откуда пришел пакет, если есть дорога обратно то он легитивен. У меня на роутере прилетает от пяти провайдеров full view, есть несколько маршрутов по умолчанию и т.д. то есть полная связанность. В данном случае uRPF мне не как не поможет.
urpf loose подразумевает что если у отправителя next-hop discard (или null 0 на циске), то такой пакет роутер дропнет. Количество фулвью и дефолтные маршруты здесь не влияют.

urpf loose смотрит — "маршрут до отправителя есть через любой интерфейс, и роут не указывает на null0=всё, пакет форвардим"
предположим, Ваша точка зрения правильная — маршрут до любого src есть и, фактически, это означает, что остается только правило "роут не указывает на null0 (если у отправителя next-hop discard (или null 0 на циске))". Что фактически превращается в кучу правил по маршрутизации src/dst. Даже если предположить, что нет подмены src и атака идет с большого ботнета, очень сильно разросшаяся таблица маршрутизации или фильтрации не принесен ничего хорошего.

Это не моя точка зрения, это доки вендоров и работающие решения на их основе, в том числе и мои :)

juniper:
«The only check in loose mode is whether the packet has a source address with a corresponding prefix in the routing table; loose mode does not check whether the interface expects to receive a packet with a specific source address prefix.»

cisco:
«When administrators use Unicast RPF in loose mode, the source address must appear in the routing table. Administrators can change this behavior using the allow-default option, which allows the use of the default route in the source verification process. Additionally, a packet that contains a source address for which the return route points to the Null 0 interface will be dropped.»

Про остальное:
а) любые пиры у меня (без разницы — eBGP/iBGP) всегда заводятся с maximum-prefix, ничего ужасного до сих пор не разрасталось. При суммарной ёмкости каналов около 10гб ограничения на 200 префиксов на пир, анонсирующий айпишники для локального блэкхола, всегда хватало

б) Это уже наблюдение просто из практики — если количество атакующих хостов вылезает за указанную величину, то приходится объявлять атакуемый айпишник в блэкхол аплинкам, так как перестаёт хватать каналов.
То есть это уже тот предел, когда блокирование в своей зоне ответственности не помогает.

в) Кучи правил по маршрутизации нет, при ограничении 2млн (вроде бы) на допустим mx80 +200 префиксов не делают никакой погоды.
fullview порядка 580к префиксов, ну вот могут у нас появиться в таблице маршрутизации ещё 200 маршрутов /32, это некритично и на производительность не влияет.
Я не понимаю смысла RPF в данной ситуации, когда маршруты ко всем IP есть в таблице маршрутизации. Это тоже самое, что просто фильтр по src. Отлично — есть такая технология, только зачем ее применять данном контексте и как она поможет в данной ситуации? Заблокировать 200 IP адресов из ботнета в 1-10к машин, а потом послать IP в blackhole ?

Если трафик идет с подменой SRC на 1-10 серверов, Вы не сможете послать в blackhole все IP адреса серверов (все перестанет работать) локально, не локально разницы нет. Так же как и заблокировать рандомные адреса.

1) 200 хостов это мало
2) как раз, что бы не посылать в blackhole ip на котором располагается не один клиенты — мы увеличиваем емкость каналов (на текущий момент в 10 раз больше названного Вами значения) и делаем все возможное, что бы не посылать IP в blackhole. blackhole для нас не выход.

В любом случае статья не о том как заблокировать 200 IP или послать атакуемый IP в blackhole.
По моему опыту подделать отправителя ддосерам удавалось редко, и это были такие объёмы, из-за которых приходилось отправлять получателя ддоса в блэкхол аплинкам. Основное преимущество, которое я вижу — нет необходимости блокировать bgp-peer на точке обмена трафиком. То есть это работает более избирательно.

Фильтр по src требует операций commit на изменение, что влечёт изменение глобальной конфигурации с операциями записи. В случае rpf имеется дешёвый аналог flowspec, не ограниченный способностью фильтрации asic платформы, и работающий с пропускными способностями коммутационного чипсета роутера.

200 хостов достаточно для меня, в моих условиях. Не вижу никакой проблемы блокировать 10k хостов при желании, но у меня на обычном хостинге хватало блокировать 200 генераторов, остальное нейтрализовалось на уровне получателя.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий