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

[AlKov]

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

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

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

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

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

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

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

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

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

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

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

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

[alibek]

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

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

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

[AlKov]

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

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

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

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

[alibek]

Я бы делал блэкхол.

[Merridius]

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

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

[rm_]

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

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

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

[myth]

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

[s.lobanov]

@myth 

С кваггой - никак

[s.lobanov]

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

[AlKov]

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

[Dimka88]

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

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

[hsvt]

В 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

 

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

[s.lobanov]

@hsvt 

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

 

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

[AlKov]

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

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

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

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