Неожиданное срабатывание iptables connlimit

Я использовал эти правила брандмауэра:

-I FORWARD -p tcp --syn -m connlimit --connlimit-above 50 -j REJECT
-I FORWARD -p tcp --syn -m connlimit --connlimit-above 50 -j LOG --log-prefix "CONNLIMIT: " --log-level debug

это кажется достаточно простым: запретить кому-либо открывать более 50 подключений и вызывать отказ в обслуживании. Я успешно протестировал его против slowloris. Я увеличил лимит до 50 специально, чтобы предотвратить проблемы с ложными срабатываниями (Apache может быть очень требовательным к соединению). Однако сегодня утром я получаю электронное письмо от монитора Nagios, и в моих журналах отображается несколько строк «CONNLIMIT» с исходный IP - это моя система мониторинга.

Понятия не имею, почему это происходит. в лучшем случае мой сервер мониторинга должен выполнять 5-10 проверок и, возможно, устанавливать соединение ping или SSH. Я был бы шокирован, если бы у меня было открыто более 25 подключений, но 2 выходных подряд мне удалось активировать connlimit 50 и грубо разбудить себя.

Что-то не так с правилами моего брандмауэра? (может быть, добавить «новый» флаг?) Nagios не закрывает свои соединения должным образом? Я даже не уверен, как продолжить отладку этой проблемы, не регистрируя каждый пакет на проводе и терпеливо ожидая, когда мой сотовый телефон отключится в какой-то ужасный час.

[изменить: просто для удовольствия, вот логи сервера]

Oct  9 11:33:22 adapt kernel: [1888526.442640] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=2076 DF PROTO=TCP SPT=46536 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  9 11:34:22 adapt kernel: [1888586.443869] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=43048 DF PROTO=TCP SPT=57931 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  9 11:35:42 adapt kernel: [1888667.011376] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=19161 DF PROTO=TCP SPT=63669 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Oct  9 11:35:48 adapt kernel: [1888673.093663] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=48302 DF PROTO=TCP SPT=63673 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Oct  9 11:35:53 adapt kernel: [1888678.361267] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=11711 DF PROTO=TCP SPT=63677 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Oct  9 11:36:04 adapt kernel: [1888688.517868] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=6316 DF PROTO=TCP SPT=44206 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  9 11:36:21 adapt kernel: [1888705.382273] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=29613 DF PROTO=TCP SPT=63697 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Oct  9 11:36:49 adapt kernel: [1888733.467511] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=52433 DF PROTO=TCP SPT=40930 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Oct  9 11:37:04 adapt kernel: [1888748.574700] CONNLIMIT: IN=eth0 OUT=eth1 SRC=[MONITOR] DST=[HOST] LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=26329 DF PROTO=TCP SPT=44223 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0

мы видим, что он проверяет несколько портов и выдает проверку примерно раз в минуту.

Ты наверное хочешь recent не connlimit.

Вот пример с одного из моих хостов, который ограничивает SSH-соединения:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
iptables -A SSH_Brute_Force -m recent --set --name SSH --rsource
iptables -A SSH_Brute_Force -m recent ! --update --seconds 120 --hitcount 5 --name SSH --rsource -j RETURN
iptables -A SSH_Brute_Force -m recent --update --name SSH --rsource
iptables -A SSH_Brute_Force -p tcp -j DROP

Или:

Для входа в цепочку уже выбраны только SSH-пакеты
Назначьте подключения к недавней очереди "SSH"
Установите 120-секундный тайм-аут и максимум пять новых подключений за это время, верните сеансы цепочки вызовов, которые не должны быть ограничены (цепочка вызовов затем разрешает хорошие хосты)
Обновите список подключений
Отбросить пакет

Когда срабатывает правило, видите ли вы открытые соединения с хоста монитора в netstat?

А как насчет / proc / net / ip_conntrack на маршрутизаторе?

ISTR, который connlimit фактически ограничивает все соединения, которые попадают в это правило, и это очень общее правило. Увеличивается ли число до 50 из-за других подключений, проходящих через маршрутизатор?

Как насчет добавления правила отладки, чтобы определить, что на самом деле происходит:

-I FORWARD -p tcp --syn -s [MONITOR] -j LOG --log-prefix "MONITOR CONNECT: " --log-level debug