AlKov Опубликовано 21 апреля, 2018 · Жалоба Собственно вопрос в сабж. Применительно к двум ситуациям: 1. целенаправленная атака 2. некорректная работа сегмента сети (шторм и т.п.) из-за неисправности оборудования, или неверных настроек. Какая из этих двух "пилюль" сработает эффективнее? Или для каждой ситуации своё "лекарство"? Разница в поведении известна - blackhole тупо "топит в сортире" всё прилетевшее, никого и никак об этом не информируя, unreachable сообщает отправителю о том, что "здесь ТАКОЙ рыбы нет". Сам склоняюсь к предпочтительному использованию blackhole для вышеуказанных ситуаций. unreachable - как мне думается - более подходит для корректной работы. Т.е. отправитель вежливо постучался в мою дверь и спросил: "а нет ли тут... ?", и ему так же вежливо ответили - "извините, нет..". А вот для пытающихся "войти без стука, открыв дверь ногой", более подойдёт blackhole (стучите-стучите, нет здесь никого, а дверь бронированная). Хотелось бы узнать мнения профессионалов по этому вопросу.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 21 апреля, 2018 · Жалоба 22 минуты назад, AlKov сказал: Или для каждой ситуации своё "лекарство"? Да. Например при защите DNS через дроп пакетов и при неправильных настройках порогов можно словить непреднамеренную атаку, потому что клиентское оборудование будет отправлять запросы, не получать ответы и отправлять их повторно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 21 апреля, 2018 · Жалоба Нет, задача не совсем такая. Мне просто необходимо "сказать", что "такой подсети у меня нет совсем" и я про неё ничего не знаю, "ищите её в другом месте". Для того, чтобы маршрутизатор не направил запрос в дефолтный роут. Т.е. команда будет либо такая - ip route add unreachable 192.168.252.0/22, либо такая - ip route add blackhole 192.168.252.0/22 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 21 апреля, 2018 · Жалоба Я бы делал блэкхол. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Merridius Опубликовано 21 апреля, 2018 · Жалоба По идее лучше blackhole, поскольку не будут отправляться лишние icmp пакеты (уведомления о том, что сеть unreachable), в случае ip route add unreachable. Я бы тоже делал через blackhole. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 21 апреля, 2018 · Жалоба Только плиз не используйте blackhole для РКНовских блокировок. Используйте другие методы, где клиенту сваливается ICMP administratively prohibited, или что-то подобное. В случае с блэкхолом браузер будет тупить три часа прежде чем отвалится по таймауту, а если придёт REJECT - сразу же попробует альтернативные варианты (которые у сайта/сервиса могут быть прописаны). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 21 апреля, 2018 · Жалоба А как в квагге, например, сделать маршрут unreachable? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 апреля, 2018 · Жалоба @myth С кваггой - никак Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 апреля, 2018 · Жалоба @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 ещё лучше) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 21 апреля, 2018 · Жалоба @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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 25 апреля, 2018 · Жалоба Я может чего то упустил, что говорит syslog и dmesg по поводу падения eth0? Как часто это происходит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 25 апреля, 2018 · Жалоба В 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 А это не оно разве будет ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 25 апреля, 2018 · Жалоба @hsvt Как я понял, вопрос в том, как повесить это на маршруты, приходящих из протоколов маршрутизации, т.е. пришёл вам маршрут по bgp и нужно сделать его unreach (типа роут-мап или как-то ещё) Тупо командой это - это так и в линукс напрямую их можно посылать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 26 апреля, 2018 · Жалоба В 25.04.2018 в 09:44, Dimka88 сказал: Я может чего то упустил, что говорит syslog и dmesg по поводу падения eth0? Как часто это происходит? Ответил тут, т.к. более ближе к теме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...