Для контекста, моя машина является хостом веб-приложений Virtual Private Server.
Следует ли мне «немного заблокировать ICMP»? Или почему бы просто не заблокировать его полностью? Что произойдет, если я так поступлю (что плохого случится)?
Ответ 1
ICMP — это намного, намного больше чем «traceroute» и «ping». Он используется для обратной связи при работе DNS-сервера (порт недоступен), что в современном DNS-сервере может помочь быстрее выбрать другую машину для запроса.
ICMP также используется для обнаружения MTU пути. Скорее всего, ваша ОС устанавливает «DF» (don't fragment) на TCP-пакеты, которые она посылает. Она ожидает получить в ответ пакет ICMP «требуется фрагментация», если что-то на пути не может обработать пакет такого размера. Если вы заблокируете все ICMP, вашей машине придется использовать другие механизмы отката, которые в основном используют тайм-аут для обнаружения «черной дыры» PMTU и никогда не будут оптимизированы правильно.
Кроме того, вы должны спросить себя, почему вы хотите блокировать ICMP. Что конкретно вы пытаетесь предотвратить? Совершенно очевидно, что вы не понимаете, для чего используется ICMP, что встречается довольно часто. Я был бы крайне осторожен, блокируя то, что вы не до конца понимаете.
Чтобы еще больше усложнить изучение этого вопроса, многие обычные книги по брандмауэрам говорят: «Блокируйте ICMP». Очевидно, что их авторы никогда не читали RFC и не сталкивались с решением проблем, связанных с такими советами. Это плохой совет — блокировать весь ICMP.
Ограничение скорости также может навредить. Если ваша машина занята, или даже если это не так, вы можете получить большое количество ICMP-трафика. Мой веб-сервер, вероятно, получает около 10-100 ICMP-пакетов в минуту, большинство из которых — это обнаружение PMTU. Даже если кто-то решит атаковать мой сервер с помощью ICMP пакетов какого-то типа, это не так уж и важно. Если ваша машина принимает хотя бы одно TCP-соединение (ssh, http, mail и т. д.), есть шанс, что это более серьезный вектор атаки, чем неправильно принятый ICMP.
Ответ 2
Вот альтернативная точка зрения в духе того, что предлагает теория безопасности. Практика безопасности часто бывает чрезмерно усердной, но многое из этого имеет под собой хорошую основу.
Теория безопасности в целом гласит, что вы включаете только то, что вам нужно. Другие вещи (которые могут быть полезны, например, ответы ping) могут быть использованы злоумышленником для изучения вашей системы или, возможно, в качестве вектора атаки для какой-то еще не обнаруженной уязвимости.
Итак, рассмотрим типы сообщений ICMP, что вам НЕОБХОДИМО для нормальной, правильной работы вашей системы?
эхо-ответ (ping);
destination unreachable — здесь много полезной информации. Отключите его, и вы нарушите доступ к вашему серверу для некоторых клиентов;
source quench — устарел с 1995 года и, очевидно, удален из реализаций хостов с (самое позднее) 2005 года. tools.ietf.org/html/rfc6633#section-1;
перенаправление — почти наверняка не работает;
реклама и запрос маршрутизатора — не нужно, если вы статически конфигурируете свои маршруты, и может быть использован для DoS. Я бы заблокировал его, если вы не знаете, что он вам нужен, а если он вам нужен, возможно, введите правило для приема информации только от возможных известных маршрутизаторов;
ttl exceeded — не только для traceroute, говорит о том, что ваш трафик не доходит до места назначения.
...и так далее. Если вы действительно хотите разобраться в этом, изучите различные типы ICMP и их назначение. На практике действительно некорректным является перенаправление; если вы хотите просто сделать что-то быстрое и полезное, заблокируйте его и разрешите остальные.
Я бы еще добавил, что отслеживание соединений IPtables разрешает соответствующие возвращаемые ICMP-пакеты для активных соединений. Так что, если вы используете conntrack, вы должны быть в состоянии блокировать большинство входящих ICMP, пока вы принимаете пакеты RELATED (до того, как вы заблокируете ICMP в вашем наборе правил).
Ответ 3
В настоящее время даже ограничение ICMP-пакетов на стороне сервера может создать головную боль при DDoS-атаках. Атаки в основном делаются путем отправки огромного количества сетевых ICMP-запросов на один сервер, и если сервер пытается ответить на каждый из них, происходит отказ в обслуживании.
В моей организации есть сервер teamspeak, который получает «плохие» пакеты каждый день. Мы полностью отключили/заблокировали ICMP-ответы, у нас нет DNS-серверов на сервере, нет NTP-серверов, нет почтовых серверов, нет FTP-серверов, только два apache и teamspeak. Все порты, которые не нужны для служб, отключены. Мы планируем заблокировать даже ssh и оставить открытыми только два порта. На сегодняшний день существует 21k (!) перманентных банов.
Ситуация такова, что злоумышленники используют в основном ICMP-туннели, и несколько действительно интересных строк журнала были обсуждены с администраторами сервера. Они сказали, что у них включены серверные ICMP-запросы, поэтому злоумышленники используют их для туннелирования атак через них и атакуют нас.
Если вам не нужна диагностика вашего сервера и если вы можете полностью заблокировать запросы или отфильтровать их, то сделайте это.
Ответ 4
Я разрешаю ICMP-трафик из локальной интрасети, блокирую его из интернета. Таким образом, мой сервер практически невидим в интернете (он отвечает только на нестандартный порт SSH).
iptables -I INPUT 7 -d 208.180.X.X -p icmp --icmp-type 8 -j DROP
iptables -I INPUT 8 -d 208.180.X.X -p icmp --icmp-type 0 -j DROP
iptables -I INPUT 9 -d 208.180.X.X -p icmp --icmp-type 11 -j DROP
Это вставляет его после стандартных loopback, established, LAN whitelist, VOIP provider whitelist и SSH port ACCEPTs. Я разрешаю нужный мне трафик, а затем делаю все возможное, чтобы сервер оставался невидимым для остального мира.
Linux
