ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Ruslan Kazansky                      2:5035/7       19 Oct 2002  22:39:41
 To : All
 Subject : iptables -m state & New !SYN
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: usenet@news.kursknet.ru
 .RFC-NNTP-Posting-Date: 19 Oct 2002 18:38:13 GMT
 .RFC-X-Priority: 3
 .RFC-X-MSMail-Priority: Normal
 .RFC-X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
 From: "Ruslan Kazansky" <arsl@kursknet.ru>
 
 Hi!
 
 Использую ядро 2.4.18, iptables v1.2.6a.
 
 1)
 
 Имеются следующие правила iptables:
 
 ====begin============
 iptables -t filter -A bad_pkt -p TCP -m state --state ! NEW -j ACCEPT
 
 iptables -t filter -A bad_pkt -p TCP -m state --state NEW --tcp-flags
 SYN,ACK,FIN,RST SYN -j ACCEPT
 
 iptables -t filter -A bad_pkt -p TCP -j LOG --log-prefix "New !SYN: "
 
 ====end============
 
 В логи пишутся пакеты, которые conntrack считает "NEW", но у них установлена
 одна из следующих "неправильных" для state new комбинаций флагов:
 
 --tcp-flags SYN,ACK,FIN,RST ACK,FIN
 
 --tcp-flags SYN,ACK,FIN,RST ACK
 
 --tcp-flags SYN,ACK,FIN,RST ACK,RST
 
 Причем, по номерам портов видно, что это нормальные соединения, а не
 портскан и т.п.
 
 Также замечено, что статус "netstat -neoA inet" отличается от "cat
 /proc/net/ip_conntrack".
 
 Т.е. состояние ip_conntrack не отражает реального состояния TCP-соединений!
 
 Является ли такое явление нормальным? Или это баг ядра?
 
 2)
 
 В /proc/net/ip_conntrack присутствуют долго висящие (до 5 дней) записи,
 видимо соответствующие:
 
 (linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c):
 
       52     5 DAYS,     /*      TCP_CONNTRACK_ESTABLISHED,      */
 
 Hа dejanews нашел, что рекомендуют TCP_CONNTRACK_ESTABLISHED уменьшить до 2
 часов, причем такая рекомендация давалась еще год назад.
 
 Однако в исходники ядра (2.4.19, patch-2.4.20-pre11) мантейнеры эту
 коррекцию не вносят, причина... ?
 
 Есть ли способ какой-то еще бороться с возможной DOS-атакой на ip_conntrack,
 которая, IMHO, может привести к
 
   ip_conntrack: maximum limit of XXX entries exceeded ?
 
 netstat -neoA inet не показывает "висячих" соединений, они видны только в
 /proc/net/ip_conntrack...
 
 3)
 
 Почему время таймаутов для ip_conntrack отлично от стандартных TCPшных ? Или
 это только для протоколов типа UDP & ICMP ?
 
 -----------
 Rsl
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: kursknet.ru (2:5035/7@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор