Я использую следующее простое правило iptables, которое принимает Связанный пакеты:
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Я разрешаю ICMP эхо-запросы пройти с этим другим правилом:
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
Должен ли я явно добавить что-нибудь для получения «полезных» сообщений ICMP, например destination-unreachable, time-exceeded и parameter-problem, или RELATED статья их уже примет?
http://www.linuxtopia.org/Linux_Firewall_iptables/x1571.html
Другой чрезвычайно важной частью ICMP является тот факт, что он используется, чтобы сообщить хостам, что произошло с конкретными соединениями UDP и TCP или попытками соединения. По этой простой причине ответы ICMP очень часто распознаются как СВЯЗАННЫЕ с исходными соединениями или попытками соединения. Простым примером может быть узел ICMP недоступен или сеть ICMP недоступна. Они всегда должны возвращаться к нашему хосту, если он пытается безуспешно подключиться к какому-либо другому хосту, но рассматриваемая сеть или хост могут быть недоступны, и, следовательно, последний маршрутизатор, пытающийся связаться с рассматриваемым сайтом, ответит сообщением ICMP с сообщением нам об этом. В этом случае ответ ICMP рассматривается как СВЯЗАННЫЙ пакет.
Правило RELATED по умолчанию позаботится о связанных сообщениях ICMP. Из страница руководства iptables, в разделе, посвященном Conntrack (http://linux.die.net/man/8/iptables):
СВЯЗАНО означает, что пакет начинает новое соединение, но связан с существующим соединением, таким как передача данных FTP или Ошибка ICMP.
Conntrack сообщает о следующих состояниях:
Вы можете просматривать и управлять таблицей conntrack, используя conntrack пакет.
$ sudo conntrack -L
В общем, очень плохая идея фильтровать или блокировать icmp, обычно единственный «действительный» бит icmp для фильтрации - это эхо-запрос, чтобы «появиться» в наивном сканировании.
Но если вы хотите явно разрешить его части, вам не хватает как минимум двух очень важных бит, необходимой фрагментации и Source Quench:
-A INPUT -p icmp --icmp-type fragmentation-needed -m state --state NEW -j ACCEPT
-A INPUT -p icmp --icmp-type source-quench -m state --state NEW -j ACCEPT
Позвольте мне еще раз сказать вам, что фильтрация icmp - плохая идея, которая маскирует проблемы и затрудняет их обнаружение.
Это была проблема с DF (не фрагментировать) и необходимостью фрагментации, которая необходима для автоматического обнаружения PTMU, и вызвала недоступность сайтов, потому что промежуточные межсетевые экраны / маршрутизаторы отбрасывали пакеты icmp, объявляющие конечную точку, чтобы снизить MTU.
Я добавлю свой собственный ответ, чтобы предоставить свою окончательную конфигурацию, вдохновленную другими ответами и следующими источниками:
третий ресурс который использует RELATED:
iptables -P INPUT DROP
iptables -A INPUT -p icmp --fragment -j DROP
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
ICMP - очень важный протокол соединения. «Эхо-запрос» - единственное важное полезное сообщение, которое помогает общаться. Остальные из них, включая «пункт назначения недоступен», можно безопасно заблокировать, особенно если приложение, которое вы запускаете, получает большое количество неизвестных попаданий.
Тебе лучше с чем-то вроде этого,
-A INPUT -p icmp --icmp-type echo-request -m recent --set
-A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 1 --hitcount 30 -j DROP
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
-A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP
-A INPUT -p icmp -j DROP
Это будет не только принимать «эхо-запрос», но также блокировать эхо-запросы, превышающие 30 пакетов / с. Все, что вы хотите добавить, должно быть явно принято, потому что предложение RELATED не получит их, пока соединение будет установлено путем его ввода.