Почему бы не заблокировать ICMP?
Я думаю, что у меня почти завершена настройка iptables в моей системе CentOS 5.3. Вот мой сценарий...
# Establish a clean slate
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F # Flush all rules
iptables -X # Delete all chains
# Disable routing. Drop packets if they reach the end of the chain.
iptables -P FORWARD DROP
# Drop all packets with a bad state
iptables -A INPUT -m state --state INVALID -j DROP
# Accept any packets that have something to do with ones we've sent on outbound
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept any packets coming or going on localhost (this can be very important)
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp -j ACCEPT
# Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow httpd
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Allow SSL
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Block all other traffic
iptables -A INPUT -j DROP
Для контекста этот компьютер является хостом веб-приложения Virtual Private Server.
В предыдущем вопросе Ли Би сказал, что я должен "заблокировать ICMP немного больше". Почему бы просто не заблокировать это вообще? Что бы произошло, если бы я сделал это (что случилось бы плохо)?
Если мне нужно не блокировать ICMP, как я могу больше заблокировать его?
10 ответов
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.
ICMP используется для ряда функций диагностики (например, ping, traceroute) и управления сетью (например, обнаружение PMTU). Беспорядочная блокировка ICMP вызывает у других людей всевозможные изжоги, и если вы точно не знаете, что делаете, вы должны оставить это в покое.
Я никогда не понимал, почему люди следят за ICMP, как сказано выше, он только вызывает головную боль у вас и у других. Вы можете определить, достаточно ли легко работает хост, и если он достаточно ограничен, чтобы его нельзя было использовать в качестве DOS, тогда я никогда не слышал убедительных причин для его блокировки. (Если кто-то может придумать причину, пожалуйста, напишите)
Вы можете просто попробовать ограничить icmp таким образом, чтобы его нельзя было использовать как DOS-атаку. но существует слишком много инструментов для устранения неполадок, таких как ping, mtr (я забываю эквивалент Windows), traceroute (tracert), которые используют icmp. отбрасывать их целиком просто глупо. Это хороший способ проверить, работает ли ваш экземпляр, даже если вы не можете использовать telnet ни на каких портах.
--limit 10/secondВот альтернативная точка зрения, в духе того, что предлагает теория безопасности. Другие плакаты правы в том, что практика безопасности часто переусердствовала, но для этого есть хорошая основа.
Теория безопасности, как правило, заключается в том, что вы включаете только то, что вам нужно. Другие вещи (которые могут быть полезны - например, пинг-ответы) могут быть использованы злоумышленником для расширения вашей системы или, возможно, в качестве вектора атаки для какой-то уязвимости, которую еще предстоит обнаружить.
Итак, глядя на типы сообщений ICMP, что вам нужно для нормальной, правильной работы вашей системы?
- эхо-ответ (пинг) - не так много
- пункт назначения недоступен - здесь много полезной информации. Отключите это, и вы заблокируете доступ к вашему серверу для некоторых клиентов.
- quench source - устарел с 1995 года и, по-видимому, удален из реализаций хоста с (не позднее) 2005 года. tools.ietf.org/html/rfc6633#section-1.
- редирект - почти наверняка нет
- реклама и приглашение маршрутизатора - не нужно, если вы статически настраиваете свои маршруты и можете использоваться для DoS. Я блокировал бы это, если вы не знаете, что вам это нужно, и если вам это нужно, возможно, закодируйте правило, чтобы принимать информацию только от возможных известных маршрутизаторов.
- Превышено значение ttl - не только для traceroute, говорит о том, что ваш трафик не проходит к месту назначения
...и так далее. Если вы действительно хотите понять это, изучите различные типы ICMP и для чего они нужны. Статья в Википедии - хорошая отправная точка.
На практике действительно ужасный - это перенаправление; если вы хотите сделать что-то быстрое и полезное, заблокируйте это и разрешите все остальное.
Я хотел бы добавить, что отслеживание соединений IPtables позволит соответствующие возвратные ICMP-пакеты для активных соединений. Поэтому, если вы используете conntrack, вы сможете блокировать большинство входящих ICMP-сообщений, пока вы принимаете СВЯЗАННЫЕ пакеты (до того, как вы заблокируете ICMP в своем наборе правил).
Это полезный диагностический инструмент для решения проблем с сетевым подключением.
Это также позволяет вам использовать соединения в других местах в Интернете, которые используют меньшие MTU, чем в вашей сети. Если вы попытаетесь отправить пакет куда-то слишком большого и не фрагментированного, устройство отбросит пакет и отправит пакет, необходимый для фрагментации ICMP, обратно отправителю. Если вы отбрасываете все пакеты ICMP, вы теряете их, и в вашей сети происходят странные вещи.
Реальный вопрос - "зачем блокировать ICMP?" Что вы получаете? Просто имейте хорошие правила фильтрации на вашей границе и перед вашими ценными активами.
ping - хороший диагностический инструмент, вы действительно захотите, чтобы он когда-нибудь был у вас. Я использую это:
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
Вы могли бы также хотеть задушить это.
В настоящее время даже ограничение ICMP-пакетов на стороне сервера может создать головную боль при DDoS-атаках. Атаки в основном осуществляются путем отправки огромных оконных ICMP-запросов на один сервер, и если сервер пытается ответить на каждый из них, угадайте, что произойдет?
Главное, что у нас есть сервер teampeak, который получает плохие пакеты каждый день, было несколько дней в двух месяцах, когда у нас было немного "свободного времени". Мы полностью отключили / заблокировали ответы ICMP, у нас нет DNS-серверов на сервере, нет NTP-серверов, нет почтовых серверов, нет FTP-серверов, только два apache и teampeak. все порты, которые не нужны для служб, отключены. Мы планируем заблокировать даже ssh и оставить открытыми только два порта. Сегодня существует 21 тыс. (!) Постоянных запретов.
Ситуация такова, что злоумышленники используют в основном ICMP-туннелирование, и несколько администраторов сервера обсудили несколько действительно интересных строк журнала, и они сказали, что у них есть ICMP-запросы к серверу, поэтому злоумышленники использовали это для туннелирования атаки и атаки на нас. Звучит странно, но это правда.
Если вам не нужна диагностика вашего сервера и если вы в состоянии полностью заблокировать запросы или отфильтровать их, например, для удаления огромных окон, сделайте это. Я также предлагаю вам полностью заблокировать: Китай, Корея, Таиланд, Турция, потому что большинство IP-адресов исходит оттуда. У меня были целые списки Inetnum этих стран, но почти каждый день приходят новые.
Я говорю то, что я делаю, если вы не согласны - не делайте этого. Просто как тот. Удачи
Как минимум, вы должны разрешить передавать icmp типы 3 (пункт назначения недоступен), 4 (источник гашения) и 11 (время превышено). Все эти типы используются для решения проблем сети и не должны фильтроваться.
iptables -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
(Тип подавления исходного кода в настоящее время устарел, но не мешало бы его открыть)
Я разрешаю трафик 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, установленного, белого списка LAN, белого списка провайдера VOIP и ACHEPT портов SSH. Я разрешаю трафик, который хочу, а затем делаю все возможное, чтобы сервер оставался невидимым для остального мира.