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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

22 минуты назад, AlKov сказал:

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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

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


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

@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 ещё лучше)

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


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

@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.

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


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

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

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

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


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

В 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

 

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

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


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

@hsvt 

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

 

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

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


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

В 25.04.2018 в 09:44, Dimka88 сказал:

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

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

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

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.