Назад | Перейти на главную страницу

Почему некоторые веб-серверы не отвечают на запросы icmp?

Какова цель блокировки / сброса входящего трафика ICMP на общедоступном веб-сервере? Часто ли его блокируют?

Мне пришлось проверить, доступен ли сервер из разных мест (проверено на разных серверах, расположенных в разных штатах / странах). Я бы полагался на ping как на быстрый и надежный метод определения того, был ли сервер онлайн / доступным по сети. Не получив ответа на пару ящиков, я попытался использовать lynx для загрузки сайта, и это сработало.

В наши дни довольно часто отказываться от ICMP, поскольку это общий метод для использования в целях отказа в обслуживании. Хост с более высокой пропускной способностью или несколько хостов, повторно отправляющих эхо-запрос на один веб-сервер, могут использовать всю его пропускную способность.

Другие могут отказаться от них, чтобы уменьшить свое присутствие в Интернете, и, таким образом, они могут остаться незамеченными при массовом сканировании.

Хотя это обычное явление, я бы сказал, что он мало полезен и мало что делает для минимизации DoS и следа, ограничивая диагностический потенциал.

Помимо сомнительной защиты от DoS-атак и пониженного профиля, существует распространенная, но упускаемая из виду причина, по которой данный IP-адрес может не отвечать на эхо-запросы: он фактически не назначен интерфейсу.

Перенаправление (перенаправление портов) кортежей IP / протокола / порта на различные службы, которые вам нужны, дает вам большую плотность обслуживания в меньшей сети.

Например, предположим, что ваш интернет-провайдер направляет вам 1.2.3.4/30. У вас есть три варианта:

  • Маршрутизируйте их нормально. Оставляет вам два используемых IP-адреса, один из которых должен быть вашим шлюзом, то есть один хост.
  • NAT внешний IP-адрес на внутренний IP-адрес. У вас остается четыре хозяина.
  • При необходимости перенаправляйте трафик на внутренние службы. SMTP (TCP 25), DNS (TCP / UDP 53) и ваш корпоративный веб-сайт (TCP 80 443) могут существовать на одном внешнем адресе.

Третий способ становится все более распространенным. Большинство администраторов (включая меня) при его настройке не перенаправляют ICMP, поэтому он просто падает на брандмауэре.

Нет никакого вреда в блокировке ICMP типа 0 (эхо-ответ), но блокировка всего ICMP-трафика прерывает ответы клиенту, если какая-либо ссылка в пути возврата имеет MTU меньше, чем максимальный размер сегмента отправки TCP-соединения. Это происходит потому, что веб-сервер больше не может получать пакеты ICMP типа 3 с кодом 4 (пункт назначения недоступен; требуется фрагментация и установлен DF).

На практике это не большая проблема, потому что любой, кому нужно туннелировать трафик, также должен настроить механизм для работы с множеством веб-серверов, стеки TCP которых заблокированы неправильно настроенными брандмауэрами.

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

К тому же он не дает статистики по сайту; один хост или IP-адрес могут легко отвечать за балансирующую нагрузку ферму серверов на бэк-энде (пинг mysite.com не говорит вам, все ли серверы работают правильно за именем.)

Это может быть просто политика компании: отбрасывать ненужный трафик или разрешать перенаправление только на порт 80 и SSL-трафик на другие серверы внутри компании.

Я предполагаю, что другой вопрос будет в том, зачем разрешать внешним системам проверять связь с вашими серверами, если им действительно не нужно?