Linux

Стоит ли блокировать ICMP?

Я думаю, что настройка iptables почти завершена в моей системе CentOS 5.3. Вот мой сценарий ...

iptables -P INPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -P OUTPUT ACCEPT

iptables -F # Flush all rules

iptables -X # Delete all chains

# Отключает маршрутизацию. Отбрасывает пакеты, если они достигли конца цепочки.

iptables -P FORWARD DROP

# Отбросить все пакеты с плохим состоянием

iptables -A INPUT -m state --state INVALID -j DROP

# Принимать любые пакеты, которые имеют отношение к тем, которые мы отправили на исходящем направлении.

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Принимать любые пакеты, приходящие или уходящие на localhost (это может быть очень важно)

iptables -A INPUT -i lo -j ACCEPT

# Принимать ICMP

iptables -A INPUT -p icmp -j ACCEPT

# Разрешить ssh

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Разрешить httpd

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# Разрешить SSL

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Блокировать весь остальной трафик 

iptables -A INPUT -j DROP

 

Для контекста, этот компьютер является хостом веб-приложения Virtual Private Server.

Как мне поступить с ICMP?

 

Ответ 1

ICMP это намного больше, чем «traceroute» и «ping». Он используется для обратной связи при запуске DNS-сервера (порт недоступен), который на современном DNS-сервере может фактически помочь выбрать другую машину для более быстрого запроса.

ICMP также, как упоминалось выше, используется для определения MTU пути. Скорее всего, ваша ОС устанавливает «DF» (не фрагментировать) для TCP-пакетов, которые она отправляет. Ожидается, что ICMP вернет пакет «требуется фрагментация», если что-то на пути не сможет обработать этот размер пакета. Если вы заблокируете весь ICMP, ваша машина должна будет использовать другие резервные механизмы, которые в основном используют тайм-аут для обнаружения «черной дыры» PMTU и никогда не будут правильно оптимизироваться.

Кроме того, вы должны спросить себя, почему вы хотите заблокировать ICMP. Что конкретно вы пытаетесь здесь предотвратить? Совершенно очевидно, что вы не понимаете, для чего используется ICMP, что бывает довольно часто. Я был бы крайне осторожен, блокируя то, чего не совсем понимаю.

Чтобы усложнить изучение этого вопроса, во многих распространенных книгах по брандмауэрам написано «блокировать ICMP» очевидно, что их авторы никогда не читали RFC и им не приходилось решать проблемы, связанные с такими советами. Блокировать все ICMP плохой совет.

Также ограничение скорости тоже может навредить. Если ваша машина занята или даже если это не так, вы можете получить хороший объем ICMP-трафика. Мой веб-сервер, вероятно, получает около 10-100 пакетов ICMP в минуту, большинство из которых обнаружение PMTU. Даже если кто-то решит атаковать мой сервер с помощью ICMP-пакетов какого-либо типа, на самом деле, это не так уж и важно. Если ваша машина принимает хотя бы одно TCP-соединение (ssh, http, mail и т. д.), скорее всего, это более серьезный вектор атаки, чем атака на неправильно настроенный ICMP.

 

Ответ 2

ICMP используется для ряда функций диагностики (например, ping, traceroute) и управления сетью (например, обнаружение PMTU). Неизбирательная блокировка ICMP вызывает множество трудноуловимых проблем, и если вы точно не знаете, что делаете, вам следует избегать этого.

 

Ответ 3

Вы можете просто попытаться ограничить icmp таким образом, чтобы его нельзя было использовать для dDOS-атаки. но существует слишком много инструментов для устранения неполадок, таких как ping, traceroute (tracert), которые используют icmp. Бросать их полностью глупо. Это хороший способ проверить, работает ли ваш экземпляр, даже если вы не можете использовать telnet ни на одном из портов.

--limit 10/second

 

К вашим правилам icmp, вероятно, является приличным пределом, учитывая, насколько компьютер действительно может это обработать.



Ответ 4

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

Теория безопасности обычно заключается в том, что вы включаете только ТО, ЧТО ВАМ НУЖНО. Другие вещи (которые могут быть полезны например, ответы ping) могут быть использованы злоумышленником для обзора вашей системы или, возможно, в качестве вектора атаки для какой-либо уязвимости, которую еще предстоит обнаружить.

Итак, глядя на типы сообщений ICMP, что вам НУЖНО для нормальной и правильной работы вашей системы?

  • эхо-ответ (пинг)

  • destination unreacheable здесь много полезной информации. Отключите это, и вы нарушите доступ к вашему серверу для некоторых клиентов.

  • Source quench устарело с 1995 года и, по-видимому, удалено из реализаций хоста с (самое позднее) 2005 года. tools.ietf.org/html/rfc6633#section-1.

  • redirectional почти наверняка не нужно.

  • Объявление и запрос маршрутизатора нет необходимости, если вы статически настраиваете свои маршруты, и может использоваться для DDoS. Я бы заблокировал его, если вы не знаете, что он вам нужен, и, если он вам нужен, возможно, закодируйте правило, чтобы принимать информацию только от возможных известных маршрутизаторов.

  • ttl exceeded не только для traceroute, сообщает вам, что ваш трафик не доходит до пункта назначения.

…и так далее. Если вы действительно хотите понять это, узнайте о различных типах ICMP и о том, для чего они нужны. Статья в Википедии является хорошей отправной точкой.

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

Я бы добавил, что отслеживание соединений IPtables позволит возвращать соответствующие пакеты ICMP для активных соединений. Поэтому, если вы используете conntrack, вы сможете заблокировать большую часть входящих ICMP, пока вы принимаете СВЯЗАННЫЕ пакеты (до того, как вы заблокируете ICMP в своем наборе правил).

 

Ответ 5

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

Главное, что у нас есть командный сервер, который получает плохие пакеты каждый день. Что мы сделали, так это полностью отключили/заблокировали ответы ICMP, у нас нет DNS-серверов на сервере, нет NTP-серверов, нет почтовых серверов, нет FTP-серверов, только два apache и teamspeak. Все порты, которые не нужны для служб, отключены. Мы планируем заблокировать даже ssh и оставить открытыми только два порта. Ситуация такова, что злоумышленники используют в основном туннелирование ICMP, и несколько действительно интересных строк журнала было обсуждено с администраторами сервера, и они показали, что у них есть запросы ICMP сервера, поэтому злоумышленники использовали это, чтобы туннелировать атаку через них и атаковать нас. Звучит странно, но это правда.

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

Схожие статьи

Команды Linux. Шпаргалка
Linux

Команды Linux. Шпаргалка

Linux

Как принудительно закрыть сокет в TIME_WAIT

Мониторинг процессов Linux: топовые инструменты и какие сложности могут быть
Linux

Мониторинг процессов Linux: топовые инструменты и какие сложности могут быть

Linux

Правильная настройка отправки почты через Cron