Может ли кто-нибудь помочь мне понять нижеследующее правило iptables?
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
Может ли кто-нибудь помочь мне понять нижеследующее правило iptables?
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
Радхил был слишком осторожен, удалив свой ответ, который является правильным, хотя и нуждается в интеграции.
Во-первых, буквальное значение правила: оно отбрасывает (-j DROP) все пакеты, начинающие новое соединение (-m состояние --state NEW), которые не относятся к типу SYN (! - syn) для протокола TCP (- - р tcp).
Тогда несколько комментариев. В протоколе TCP соединение инициируется путем ритуального обмена тремя пакетами: SYN (клиент-сервер) -> SYN/ACK (сервер-клиент) -> ACK (клиент-сервер). Соединение, не инициируемое пакетом SYN, такое как соединение, отброшенное вышеупомянутым правилом iptables, является неправильным способом установить соединение, которое преследует разные цели, как правильно указывает radhil.
Это правило часто и неверно считается необходимым для подавления атак с использованием синфляда в Интернете: см., Например, эту веб-страницу, где прямо указано:
Следующим шаблоном, который следует отклонить, является атака с помощью синфляда.
iptables -A INPUT -p tcp! --syn -m состояние --state NEW -j DROP
SYN-Flood-Attacks означает, что злоумышленники открывают новое соединение, но не заявляют, что они хотят (т.е. SYN, ACK, что угодно). Они просто хотят использовать ресурсы наших серверов. Мы не будем принимать такие пакеты.
Конечно, нет смысла пытаться обезвреживать атаки с помощью синфлуди, принимая (!!!!) Пакеты SYN для новых соединений. И это должны быть пакеты, а не пакеты.
Синодальные атаки создают некоторые проблемы, которые еще не полностью решены. Это привело к разработке нового модуля iptables под названием SYNPROXY, который вы можете найти здесь. Часто используется ограничение скорости, см., Например, здесь, но это влечет за собой проблему, упомянутую в предыдущей ссылке, то есть модуль conntrack, который необходим для отслеживания того, какие соединения являются новыми, а какие являются старыми и в каком состоянии, работает безупречно для ограниченного числа соединений, но потребляет непропорциональное количество времени, когда количество соединений увеличивается (например, из-за атаки SYN-flood). Это то, что подразумевается под проблемой масштабируемости .
В целом, мне не совсем ясно, что приведенное выше правило iptables служит какой-либо значимой цели.
-A INPUT
- добавить в конец цепочки "INPUT"
-p tcp
- соответствует протоколу TCP
! --syn
- сопоставлять пакеты без флага SYN TCP
-m state
- использовать модуль "state" (устарел; вместо новых наборов правил следует использовать "conntrack")
--state NEW
- сопоставлять пакеты с состоянием "NEW" (т.е. не принадлежать ни к какому установленному соединению)
-j DROP
- перейти к цели "DROP" (которая является конечной целью, которая отбрасывает пакет)
В основном TCP-пакеты либо открывают новое соединение (и всегда имеют флаг SYN), либо принадлежат существующему соединению, либо пытаются закрыть прерванное соединение (с флагом RST), либо являются мусором. Таким образом, это правило пытается отбросить пакеты в последней категории, которые не пытаются открыть новое соединение и не принадлежат существующему.
ИМХО это несколько избыточно ... Возможно, он должен защищать от различных странных типов порт-сканирования (как видно из nmap). Может быть просто паранойя тоже.