столкнулся с такой непоняткой:
документация утверждает, что надо так:
iptables -A INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP
обычные люди про conntrack не знают и привыкли так:
iptables -A INPUT -m state --state NEW -p tcp ! SYN,RST,ACK,FIN SYN -j DROP
в общем и целом оно работает, НО! через ~ минуту бездействия подвисает и потом приходится ждать, пока дойдёт новое соединение и сессия отвиснет.
может и не отвиснуть.
я это дело залогировал и увидел ACK PSH:
SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=100 TOS=0x00 PREC=0x20 TTL=57 ID=36151 DF PROTO=TCP SPT=55967 DPT=39512 WINDOW=2480 RES=0x00 ACK PSH URGP=0

что странно ^^

пробовал так: ! SYN,RST,ACK,FIN SYN
и PSH подставлял, SYN SYN пробовал и т.д., оно всё-равно в логах про них говорит
конкретно даже вот это правило:
-A INPUT -p tcp -m state --state NEW ! --tcp-flags SYN,RST,ACK,FIN,PSH SYN -j LOG --log-level DEBUG --log-prefix="NEW packets: "
в логи выводит вышеуказанную строку про ACK PSH
флаг PSH он вообще не из NEW, по идее, он про то, что данные протолкнуть надо, поэтому его присутствие загадочно
чё он хочет то от меня?

iptables -I INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP
будет блокировать все попытки открыть входящее TCP-соединение не SYN-пакетом. Попытка установить соединение таким образом может быть либо ошибкой, либо атакой.

ssh криво открывает новые соединения или что?
но по логам там и фтп такой же косяк ловит, правда это уже не я

• почему подвисает SSH при блокировке NEW ! SYN ?,pavlinux, 00:18 , 15-Мрт-15
  • почему подвисает SSH при блокировке NEW ! SYN ?,greenwar, 00:19 , 15-Мрт-15
    • почему подвисает SSH при блокировке NEW ! SYN ?,pavlinux, 01:47 , 15-Мрт-15
• почему подвисает SSH при блокировке NEW ! SYN ?,Andrey Mitrofanov, 10:48 , 15-Мрт-15
  • почему подвисает SSH при блокировке NEW ! SYN ?,greenwar, 17:42 , 15-Мрт-15
• почему подвисает SSH при блокировке NEW ! SYN ?,Алексей, 09:38 , 16-Мрт-15

> обычные люди про conntrack не знают и привыкли так:

Обычные люди юзают контрак для отладки, потом парсят и делают правила bpf

И ваще, айпистол уже отстой nftables рулит!

> в общем и целом оно работает, НО! через ~ минуту бездействия подвисает

Лечу по фото, дорого. Весь файервол показывай.

>> обычные люди про conntrack не знают и привыкли так:
> Обычные люди юзают контрак для отладки, потом парсят и делают правила bpf
> И ваще, айпистол уже отстой nftables рулит!

как iptables может быть отстоем, а nftables - нет, когда они оба всего-лишь интерфейсы для управления netfilter, который и есть сам файрволл?

причём тут bpf какой-то левый, когда про iptables спрашивают... непонятно
хоть пассивный FTP проверял в этом bpf?

>> в общем и целом оно работает, НО! через ~ минуту бездействия подвисает
> Лечу по фото, дорого. Весь файервол показывай.

на:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

-P FORWARD DROP
-P INPUT DROP
-P OUTPUT DROP

-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j LOG --log-level DEBUG --log-prefix="NEW packets: "
-A INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

-A INPUT -j ACCEPT
-A OUTPUT -j ACCEPT

COMMIT

вот в таком виде глючит

> на:

Тут не учебный сайт.

> столкнулся с такой непоняткой:
> документация утверждает, что надо так:
> iptables -A INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j DROP
> обычные люди про conntrack не знают и привыкли так:
> iptables -A INPUT -m state --state NEW

Обычные люди и про iptables не слышали.

И да, есть многое на свете, друг Горацио, что не записано http://www.opennet.me/openforum/vsluhforumID10/5303.html в man iptables

> в общем и целом оно работает, НО! через ~ минуту бездействия подвисает
> и потом приходится ждать, пока дойдёт новое соединение и сессия отвиснет.
> ssh криво открывает новые соединения или что?
> но по логам там и фтп такой же косяк ловит, правда это

У меня
http://www.opennet.me/openforum/vsluhforumID1/93014.html#1
http://www.opennet.me/openforum/vsluhforumID10/4463.html#16
были smpt+pop3 на аналоговых модемах или через "vpn"-ы на виндовых клиентах.

> У меня
> http://www.opennet.me/openforum/vsluhforumID1/93014.html#1
> http://www.opennet.me/openforum/vsluhforumID10/4463.html#16
> были smpt+pop3 на аналоговых модемах или через "vpn"-ы на виндовых клиентах.

ну понятно, в общем крутить таймауты
спасибо

зы: кстати, так как-то проще: sysctl -a |grep -E conntrack.+?timeout

> iptables -A INPUT -m conntrack --ctstate NEW -p tcp ! --syn -j
> DROP
> обычные люди про conntrack не знают и привыкли так:
> iptables -A INPUT -m state --state NEW -p tcp ! SYN,RST,ACK,FIN SYN
> -j DROP
> в общем и целом оно работает

Это совершенно разные подходы. Первый использует таблицу conntrack ядра для определения статуса соединения. Второй использует напрямую флаги в tcp пакете. Первый вариант не будет работать, если, например, выключен conntrack. Второй вариант будет работать всегда. Выберите какой-то один подход. Либо с использованием tcp флагов, либо с использованием conntrack.

Пример для conntrack:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT