Пробовали тест маршрутизации по примеру с “http://wiki.mikrotik.com/wiki/Routing_Questions”, но не работает. Помогите, пожалуйста, как правильно это сделать? Спасибо большое за ответ! С уважением.
Думаю, это не обязательно, так как объявление сети добавляется уже после того, как фильтр установлен. Чуть проще сделать это, выборочно перераспределяя статические маршруты в BGP, чтобы не пришлось добавлять сеть и обновлять цепочки фильтров:
/routing bgp instance set default out-filter=BGP-out-global redistribute-static=yes
С этим настроенным, вам достаточно просто создавать или удалять статические маршруты — и они автоматически будут отправлены соседям, чьи выходные фильтры это позволяют.
Оба варианта заставят локальный маршрутизатор сбрасывать трафик на эти адреса (blackhole), а наличие сообщества 200:666 позволит им перераспределяться в BGP через первое правило в цепочке BGP-out-global. Учтите, что в этом примере фильтр не ограничивает длину префикса — по сути, вы доверяете себе и вводите только разумные маршруты в blackhole-сообщество. Если хотите подстраховаться, добавьте в правило для blackhole-сообщества ограничение prefix-length=29-32.
Я бы не советовал перераспределять какие-либо маршруты. Создавайте статические "черные дыры" с помощью bgp-communities и добавляйте каждую сеть в раздел /routing bgp network с параметром synchronize=yes.
Хотя я согласен с вами, что маршруты всегда нужно правильно объявлять, по моим наблюдениям, маршрут в «чёрную дыру» отлично подходит под категорию «вещей, которые логично перераспределять». Я много раз писал на форуме Mikrotik, что все маршруты нужно объявлять корректно — ведь у перераспределённых маршрутов есть тонкие нюансы, которые потом могут дать о себе знать, когда вы станете глубже разбираться в маршрутизации. Однако, учитывая, что маршрут в чёрную дыру для защиты от DDoS — это: а) временная мера, б) длинный префикс (который имеет приоритет вне зависимости от других метрик или методов управления трафиком), в) мера, применяемая в экстренной ситуации, то есть должна быть максимально быстрой и простой в исполнении, г) не распространяется на весь глобальный BGP — мне кажется, что неполное объявление происхождения вовсе не так уж критично, ведь каждый провайдер, получивший этот префикс, просто внесёт его в чёрную дыру и не будет распространять дальше среди других пиров. К тому же, эта экстренная мера должна работать как можно меньше по времени, так что вы не ссыпаете мусор в глобальную таблицу маршрутизации. Конечно, если кто-то хочет использовать redistribute-static=yes, нужно быть аккуратным и следить, чтобы глобальный фильтр пропускал в BGP только ту информацию, которая нужна. Если же он пропускает все маршруты подряд, без разбора — это, безусловно, плохо.
Привет, ZeroByte, я использую это для фильтра: chain=to_MYISP prefix=xxx.xx.xx.0/22 prefix-length=32 invert-match=no action=accept set-bgp-prepend-path=“” set-bgp-communities=1111:111. Также нашёл этот скрипт в интернете и пытаюсь его подправить, чтобы отправлять заблокированные DDoS-ом IP в blackhole:
Это правило означает, что любой префикс /32 из вашего IP-блока будет получать сообщество 9121:666 (при этом все ранее установленные сообщества очищаются) при отправке к MYISP. Судя по названию цепочки, полагаю, что оно применяется к конфигурации пиринга, а не к самому BGP-инстансу. Также предполагаю, что в этой цепочке есть другие правила, которые вы не показали… потому что если это единственное правило, ваш роутер на самом деле будет отправлять всю таблицу BGP к MYISP, и вы полагаетесь на входной фильтр провайдера, чтобы он не дал вам рекламировать что-то неправильное.
Что касается скрипта, по первому впечатлению, он должен работать. Главное — то, что он использует synchronize=no в определениях BGP-сетей, так что вам не нужно добавлять статические blackhole-маршруты для /32.
Возможно, скрипт, который вы используете, был написан до появления функции, которая мне очень нравится: on-error={}. Для добавления blackhole-префиксов, вместо того чтобы писать всю логику проверки в скрипте, можно использовать одну команду:
Этот синтаксис добавит все из списка Blackholes и просто ничего не сделает при ошибке (например, если элемент уже в списке). Обратите внимание, что внутри блока do={} команды :foreach вложена команда :do. :do позволяет использовать on-error{} так, чтобы скрипт не останавливался при ошибке выполнения :do.
Код для удаления всё ещё должен сравнивать все элементы.
С помощью другого скрипта, который я отправлял тебе ранее, пытаюсь сделать что-то вроде — либо переделать под себя — чтобы автоматически добавлять атакуемые IP в сеть BGP с маской /32. Думаю, так можно будет лучше справляться с DDoS-атаками.
Также, если не сложно, проверь мои настройки BGP, может там что-то не так.
Это значит, что вы отправляете своему провайдеру объявление о маршруте по умолчанию — то есть сообщаете, что ИМЕННО ВЫ являетесь маршрутом в интернет. Гарантирую, они это блокируют, но вам определённо стоит это отключить. (сделайте это, когда сможете пережить кратковременный сбой BGP, потому что изменение настроек пира приводит к сбросу сессии BGP на Mikrotik). Вопрос — сессия BGP используется ТОЛЬКО для объявления black hole маршрутов или вы также планируете анонсировать свой собственный блок /22? Текущая настройка фильтра не позволяет вам анонсировать основной префикс или его подмножества, кроме /32 для black hole.
Привет, zerobyte! Что именно ты хочешь отключить? Не понимаю, disable routing filter? Или disable default-originate=if-installed? У нас настроена BGP-сессия для интернета между upstream-провайдером и нашей системой. Провайдер дал мне blackhole community, чтобы отправлять атакуемый IP в их «черную дыру». Блок /22 взят из RIPE и назначен на мой AS-номер. Извини, у меня не так много опыта, и я стараюсь объяснить, спасибо за помощь еще раз.
Отключите default-originate=if-installed (измените на «never»). Ваше правило фильтра to_MYISP фактически разрешает отправку всего. Вам также нужно добавить ещё два правила в конец этой цепочки в таком порядке: chain=to_MYISP prefix=xxx.xx.xx.0/22 prefix-length=22-24 action=accept chain=to_MYISP action=discard
Повторяйте первое из этих двух правил столько раз, сколько у вас публичных префиксов. (Это правило позволяет отправлять подблоки /24 или /23 из основного /22, но если у вас есть другие диапазоны, помимо этого /22, их тоже нужно добавить перед правилом discard.)
Я тут подумал, стоит внимательно отнестись к твоей конфигурации — твое правило фильтра позволит любой маршруту /32, который ты создашь, быть подхваченным и разрекламированным как маршрут в черную дыру у твоего провайдера. Возможно, стоит добавить какие-то дополнительные критерии, например, scope=90 или bgp-communities=1111:111, чтобы если вдруг тебе понадобится создать реальный маршрут /32 из твоего публичного блока, который ведет куда-то корректно, он не попал по ошибке в черную дыру.
Если используешь scope=90, то чтобы создать черную дыру, делай это так: /ip route add dst=b.b.b.b/32 scope=90 type=blackhole
Или для соответствия communities: /ip route add dst=b.b.b.b/32 bgp-communities=1111:111 type=blackhole
В этом случае не придется назначать bgp action = set communities на фильтре черной дыры, потому что это будет задано на самом маршруте.
Дело в том, что твоя инстанция перераспределяет статические маршруты, а текущие фильтры просто ищут любые маршруты /32 из твоего публичного блока и объявляют их провайдеру с сообществом черной дыры. Тебе нужно убедиться, что фильтр на черную дыру не навешивает это сообщество на любой /32, который увидит.
Привет, Zero Byte! Я понимаю, что ты не поддерживаешь routing filter и предпочитаешь использовать scope 90 или bgp-communities. Поэтому я удалил фильтры из маршрутизации и у BGP-пира. На следующую DDoS-атаку я планирую использовать команду /ip route add dst=b.b.b.b/32 bgp-communities=1111:111 type=blackhole. Я правильно двигаюсь? Я провёл тест: когда использую фильтр и трассирую до адреса xxx.xxx.xxx.x, трафик останавливается до того, как доходит до моего апстрим-провайдера. А если включаю blackhole, трафик останавливается уже после апстрим-провайдера.