Порядок нахождения строк состояния соединения в Iptables.

[kolesov]

Всем привет!

Меня давно мучает вопрос на который не могу найти ответ (может плохо искал).

Предположим есть какой-то набор правил в цепочке INPUT:

Код: [Выделить]

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP

-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -p tcp -m multiport --dports 22,3389 -j ACCEPT

Где именно должны находиться правила определяющие состояния соединений, вверху цепочки (как в примере) или внизу?
Я так решил, что вверху т.к. правила фильтруют сверху вниз, и например соединениям с состоянием RELATED не нужно будет проходить всю цепочку.

[fisher74]

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

[kolesov]

fisher74,  Спасибо за ответ.
Было бы здорово, если бы вы привели пример.

[AnrDaemon]

Если уж пишете правило на --ctstate INVALID, его надо ставить первым. Или как минимум перед RELATED.

[kolesov]

AnrDaemon, хм а как файервол поймет, что состояние INVALID сразу, не попытавшись установить соединение?

[AnrDaemon]

При чём тут соединение?

[kolesov]

AnrDaemon, да соединение не причем. Это левый трафик, не NEW, не RELATED, не ESTABLISHED.

[AnrDaemon]

Неверно.

[kolesov]

AnrDaemon, просветите.

[AnrDaemon]

Нет никакого "трафика".
Есть ПАКЕТ. И вот этот ПАКЕТ может быть НОВЫМ СОЕДИНЕНИЕМ(NEW), ОТНОСЯЩИМСЯ К СУЩЕСТВУЮЩЕМУ СОЕДИНЕНИЮ(RELATED) и НЕВАЛИДНЫМ(INVALID) одновременно…

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

[MooSE]

По опыту скажу: RELATED,ESTABISHED надо в конец. Потому что чтобы бы понять является соединение RELATED и/или ESTABLISHED все соединения, проходящие через это правило, добавляются во внутреннюю таблицу модуля nf_conntrack. Таблица к сожалению не резиновая и на больших нагрузках её может не хватать и обработка правила будет не корректной.

Потому сначала стоит написать более простые разрешения (протоколы, порты) и уже потом, если ни одно из предыдущих правил не сработало, отправлять соединение на обработку модулем nf_conntrack.

Например если у вас слабенький процессор вроде Xeon X3 3440 крутит nginx или haproxy в качестве load balancer для web, то уже при нагрузке в 700-900 запросов в секунду можно видеть как растёт загрузка ЦПУ если такое:

Код: [Выделить]

-A INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

заменить на такое:

Код: [Выделить]

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m tcp -p tcp --dport 80 -j ACCEPT

А в dmesg начинают проскакивать ошибки вида "nf_conntrack: table full, dropping packet"

[AnrDaemon]

Если таблицы нехватает, её надо расширять.

[MooSE]

Если таблицы нехватает, её надо расширять.

Спорно. RAM не резиновая и бесконечно увеличивать таблицу conntrack не получится. Да и зачем, когда можно вообще практически полностью разгрузить эту таблицу правильным построением последовательности правил?

[bezbo]

ПАКЕТ... одновременно…

квантовая физика?

[snowin]

квантовая физика?

хуже
в той физике лишь вероятность, процент, а тут 100%
прикинь, ужас то