Должен заметить, всё оказалось интересней.Вот уж не знаю, что там творится в нутрях iptables/conntrack, но действительно, у меня в конфигурации
host01:/web# iptables -nvL
Chain INPUT (policy ACCEPT 177M packets, 57G bytes)
pkts bytes target prot opt in out source destination
203K 61M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
16 864 AUTHS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
26 1260 AUTHS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
первоначально перестало кидать пакеты новых соединений на цепочку AUTHS, видимо пропуская её на -m state
Чтение манов выявило наличие модуля conntrack, но не выявило наличия разницы в их функциях.
http://www.linux.org.ru/forum/admin/4437887;jsessionid=4FA52...
После некотого шаманства, пакеты всё-таки стали заворачиваться на AUTHS
Chain AUTHS (2 references)
pkts bytes target prot opt in out source destination
15 744 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 60 name: auths side: source reject-with icmp-port-unreachable
7 348 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 recent: SET name: auths side: source
Правда я поменял последовательность правил - сначала проверяем, потом ставим. Иначе - выставили и следующее правило блокирует пакет, поскольку у меня нет проверки hitcount.
Данная конфигурация жестока - если в течении минуты "пользователь" не прекращал "долбиться" - сооединение не будет пропущено.
Но мы ведь не варвары, поэтому сделаем так:
Chain AUTHS (2 references)
pkts bytes target prot opt in out source destination
17 840 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 recent: UPDATE seconds: 60 name: auths side: source reject-with icmp-port-unreachable
8 396 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 recent: SET name: auths side: source
iptables -A AUTHS -m recent --name auths --rcheck --seconds 60 -j REJECT
iptables -A AUTHS -m recent --name auths --set -j ACCEPT
