ROM
написал 14 февраля 2005 года в 16:39 (712 просмотра)
Ведет себя
как мужчина; открыл 33 темы в форуме, оставил 63 комментария на сайте.
Русский: =)
Корректно ли будет в ответ ping’а посылать «Destination host unreachable"?
iptables:
IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j REJECT --reject-with icmp-host-unreachable
Последние комментарии
- OlegL, 17 декабря в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
если не волнует работоспособность сети — да хоть DROP
PS: отрезать самому себе диагностические средства — это изврат
т.е. так делать нельзя?
Так делать можно, но не нужно.
Почему ?
Мой любимый ответ на такой вопрос: потому!
Ну, приведу пример (а уж дальше сам додумыавй, придумывай, рассуждай, делай выводы). Представь ситуацию: Среднестатистическая корпоративная сеть, в которой ты администратор. Вот сделал ты на маршрутизаторе запрет на входящие echo запросы со всех IP (правилов исходном посте: '-s 0/0\′ --icmp-type 8 -j REJECT --reject-with icmp-host-unreachable). А в середине рабочего дня у тебя взял и «пропал» интернет. Пингуешь яндекс — молчит.. Ага, значит что-то с провайдеровским маршрутизатором (тут я для простоты упущу возможность неработоспособности яндекса ;)). Пингуешь его — молчит…. Ага, раз молчит, то либо он висит, либо твой маршрутизатор. Первое, что делают нормальные люди — пингуют свой маршрутизатор. А если эхо запросы запрещены на нём, то фиг угадаешь — висит он или нет. Вобщем, просто напросто, эхо запросы помогают в некоторых ситуациях определить, какой из удлов вышел из строя.
П.С. а объясните мне нужду запрета эхо запросов, а?
Чаще всего мне так девушки отвечают. ладно, это к слову.
А я отвечаю : ибо нефиг. :-)
Иногда это нужно сделать, потому что могут найтись товарищи, любящие поиграть с сырыми сокетами или libnet, собирая icmp-пакеты с интересными опциями, от коорых твоему роутеру сплохеет.
Можно запрещать эхо-запросы к твоему внешнему интерфейсу, но оставлять возможность пинговать всех и вся.
А админ, у которого не хватает ума сделать telnet www.yandex.ru {80,8080,etc}, скорее всего, виндузятник. ;-)
вообще — что и как делать — дело каждого.
только всего-то надо, что вдумчиво и целенаправленно подходить к делу.
с одной стороны, опасность создания всяких разных «кривых» пакетов существует не только для icmp, но и для любого другого протокола.
как правило, на внешние icmp-echo-request закрывается для обеспечения минимального уровня защиты от сканирования, и, как следствие, от более высокого входящего трафика.
однако, в настоящее время выгоды это никакой не несёт — сканят уже даже не пингуя предварительно. сразу и «влоб», что говорится.
ну и потом, закрываться от всех тоже не имеет смысла — к примеру, у провайдера может быть настроено нечто типа fping, которое пингует клиентские узлы и поднимает тревогу по пропаданию пингов. отсутствие этого — лишняя для них головная боль.
а support в раздражённом состоянии несколько не всегда мил, добр и пушист. точнее далеко не мил, добр и пушист.
Интеоесно, что за вопросы ты им задаёшь, раз получаешь такие ответы ;) Если такие же непутёвые, типа «почему?», то понятно ;))
О, как! Виндузятник =). Типа, они все ламеры и не знают, что такое телнет… Ну да ладно.
Там где-то я написал, что упускаю возможность неработоспособности яндекса. Т.е. если яндекс пашет, а telnet на его 80-ый порт не проходит, то либо у твоего прова, либо у тебя не работает маршрутизатор (это я всё про описанную мной ситуацию…). telnet на марщрутизатор прова не обязан проходить, следовательно, телнетом ты не проверишь его работоспособность и будешь опять гадать — в тебе косяк или же в твоём провайдере. Знаю, ты сейчас начёншь опять придумывать всякие изощрённые способы проверки, но ping самый простой. Не надо его рубить со всех IP.
и бестолковый, кстати. в большинстве случаев.
потому, как не даёт ответа на вопрос «А в каком месте у нас тут непотребность возникла?»
мне в этом случае $ mtr some.host.dom очень приглянулся. ;)
А теперь вопрос: будет ли работать mtr, если зпретить icmp echo? ;)
П.С. в контексте моего предыдущего ответа 'ping' следует воспринимать не как утилиту, а как icmp echo request.
несколько зависит от того, как же именно оно запрещено. ;)
если только на -A INPUT, то через такой шлюз пройдёт нормально.
а вот если на -A FORWARD… тут да, тут «ой».
а, между прочим, много ли народу сможет сразу настроить шлюз на обеспечение работоспособности стандартного traceroute?
и сколько смогут толково составить вопрос гуглю? :D
Я про INPUT. Просто, если проверять таким образом работоспособность своего маршрутизатора, то mtr не поможет при запрещённых входящих icmp echo.
А там разве что-то выдающееся надо настраивать? ;))
;)
ну, своё проверять, вообще-то, проще с консоли….. :)))
а то ж.
довольно неочевидно, если не совсем понимаешь, как это хозяйство работает.
Ну, во-первых, эта консоль не всегда имеется (если проверяет работоспособность, скажем не админ, как я написал выше, а кто-то из рядовых пользователей). А во-вторых, кто даст гарантии, что запретивший echo request со всех IP не запретил ещё что-нибудь? ;))
что-то ты несколько не того… заговариваешься и во флейм скатываешься ;)
простой пользователь, по условию треда, не фигурирует.
и iptables настраивать ему никто не давал.
т.е. по условию задачи — действующее лицо — админ.
да. я понимаю, что расширить условия — это всегда интересно ;)
а простой пользователь и спрашивать «А чего это у нас icmp пакеты не проходят?» не должен.
у него своё — ну там, сайт не работает, второй день как. а надо с него информацию шефу распечатать. что там случилось? остальное вроде как работает…
Ладно, ладно… Если флейм идёт, значит его кто-то поддерживает ;)
Вобщем, моя основная мысль: не надо рубить входящие icmp echo request’ы со всех IP.