Jump to content
Калькуляторы

route blackhole или unreachable - что эффективнее?

Собственно вопрос в сабж.

Применительно к двум ситуациям:

1. целенаправленная атака

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

Какая из этих двух "пилюль" сработает эффективнее?

Или для каждой ситуации своё "лекарство"?

Разница в поведении известна -  blackhole тупо "топит в сортире" всё прилетевшее, никого и никак об этом не информируя,

unreachable сообщает отправителю о том, что "здесь ТАКОЙ рыбы нет".

Сам склоняюсь к предпочтительному использованию  blackhole  для вышеуказанных ситуаций.

unreachable - как мне думается - более подходит для корректной работы. Т.е. отправитель вежливо постучался в мою дверь и спросил: "а нет ли тут... ?", и ему так же вежливо ответили - "извините, нет..".

А вот для пытающихся "войти без стука, открыв дверь ногой", более подойдёт blackhole (стучите-стучите, нет здесь никого, а дверь бронированная).

Хотелось бы узнать мнения профессионалов по этому вопросу..

Share this post


Link to post
Share on other sites
22 минуты назад, AlKov сказал:

Или для каждой ситуации своё "лекарство"?

Да. Например при защите DNS через дроп пакетов и при неправильных настройках порогов можно словить непреднамеренную атаку, потому что клиентское оборудование будет отправлять запросы, не получать ответы и отправлять их повторно.

Share this post


Link to post
Share on other sites

Нет, задача не совсем такая. 

Мне просто необходимо "сказать", что "такой подсети у меня нет совсем" и я про неё ничего не знаю, "ищите её в другом месте".

Для того, чтобы маршрутизатор не направил запрос в дефолтный роут.

Т.е. команда будет либо такая - ip route add unreachable 192.168.252.0/22, либо такая -  ip route add blackhole 192.168.252.0/22

Share this post


Link to post
Share on other sites

По идее лучше blackhole, поскольку не будут отправляться лишние icmp пакеты (уведомления о том, что сеть unreachable), в случае ip route add unreachable.

Я бы тоже делал через blackhole.

Share this post


Link to post
Share on other sites

Только плиз не используйте blackhole для РКНовских блокировок.

Используйте другие методы, где клиенту сваливается ICMP administratively prohibited, или что-то подобное.

В случае с блэкхолом браузер будет тупить три часа прежде чем отвалится по таймауту, а если придёт REJECT - сразу же попробует альтернативные варианты (которые у сайта/сервиса могут быть прописаны).

Share this post


Link to post
Share on other sites

А как в квагге, например, сделать маршрут unreachable?

Share this post


Link to post
Share on other sites

@AlKov 

У blackhole и у unreachable, очевидно разные применения.

1. Если у вас bras и вы создаёте интерфейсы динамически (для простоты - ppp-интерфейсы) и если за этим брасом закреплён какой-то пул, то нужно его нулроутить на нём, с в линуксе это называется blackhole, потому что запросы поступающие извне на эти ip-адреса это всякий левак типа ботов-сканеров и не нужно им ничего отвечать (чаще всего они не отреагируют на icmp unreach)

2. Если же у вас к примеру сервер-captive-портал для wifi-абонентов, то зарубать tcp вовне(кроме 80 порта) лучше даже не с помощью icmp unreach, а tcp-reset'ами, т.к. не факт что клиент отреагирует на icmp unreach и будет тупо висеть сессия. icmp и udp и прочее L4 в случае с captive-порталом вполне нормально зарубать icmp unreach (других способов-то и нет)

3. Цензура. Ну тут на вашей совести - в идеале опять же рубить через tcp-reject'ы, то ядро умеет только icmp unreachable. Если вы хотите сделать хорошо абоненту, то как написал выше rm_, unreach это лучше чем blackhole (но tcp-reject ещё лучше)

Share this post


Link to post
Share on other sites

@s.lobanov 

В данном случае это п.1 (bras на accel-ppp, vlan-per-user/QinQ/IPoE/ip unnumbered ).

Собственно, откуда выросли ноги - переводим клиентов с PPPoE(Dual Access) на IPoE.

Во время непосредственного "переключения" на bras иногда (совершенно непредсказуемо) вылезает очень серъёзная проблема - тупо падают все QinQ интерфейсы, включая "родителя".

В логах браса и собственно accel на момент падения совершенно ничего, что могло быть пролить свет на причину проблемы.

Т.е. заходим на bras и в ifconfig видим полное отсутствие eth0 ("родитель")..

Плюс к "рабочему" bras долнительно поднят ещё один (PPPoE без авторизации), для того, чтобы хоть что-то мяукнуть клиенту об изменении типа подключения.

После перевода сегмента сети на новую конфигурацию, зашедшие в ступор клиентские железки продолжают сыпать всевозможными запросами по ранее известным им IP (не забываем про то, что "до того как" было PPPoE(Dual Access), т.е. кроме туннеля у клиента поднималось ещё и "вторичное подключение"

 

Предположил, что весь этот мусор, пролезая дальше по дефолтному маршруту браса, создаёт что-то типа "петли", ну или конфликта IP,

что в свою очередь и приводит к краху интерфейсов..

Вот собственно для этого и решил загнать "старые" подсети в никуда.

Не факт конечно, что поможет, но хоть что-то..

 

P.S. На bras "рабочие" подсети завёрнуты в unreachable, "старые" сейчас перевёл в blackhole.

Share this post


Link to post
Share on other sites

Я может чего то упустил, что говорит syslog и dmesg  по поводу падения eth0?

Как часто это происходит?

Share this post


Link to post
Share on other sites
В 21.04.2018 в 13:18, myth сказал:

А как в квагге, например, сделать маршрут unreachable?

ip route 1.1.1.1/24
  A.B.C.D    IP gateway address
  INTERFACE  IP gateway interface name
  null0      Null interface
  blackhole  Silently discard pkts when matched
  reject     Emit an ICMP unreachable when matched

 

А это не оно разве будет ?

Share this post


Link to post
Share on other sites

@hsvt 

Как я понял, вопрос в том, как повесить это на маршруты, приходящих из протоколов маршрутизации, т.е. пришёл вам маршрут по bgp и нужно сделать его unreach (типа роут-мап или как-то ещё)

 

Тупо командой это - это так и в линукс напрямую их можно посылать

Share this post


Link to post
Share on other sites
В 25.04.2018 в 09:44, Dimka88 сказал:

Я может чего то упустил, что говорит syslog и dmesg  по поводу падения eth0?

Как часто это происходит?

Ответил тут, т.к. более ближе к теме.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now