Благодаря на всички които отговориха, внасям малко яснота и допълнителни данни и ви очаквам пак :)
>W май беше статус paging (man ps), може би поради това, че още не е уточнен >статуса на кънекшъна, но пък всички процеси да са в това състояние май вече >става подозрително. Мой пропуск, че не съм уточнил че става въпрос за /server-status на апачето,а не за ps, т.е "W" състояние си е "Sending Reply" според него. >Това наистина прилича на tcp syn attack, само, че тук си съкратил малко от >тези съобщения "client stopped connection" и има още неща освен rvputs, >rwrite.... Прегледах пак логовете, има и Send timed out, ето примерен отрязък: [Mon Dec 27 07:47:37 2004] [info] [client x.y.z.133] (104)Connection reset by peer: client stopped connection before rwrite completed [Mon Dec 27 07:47:38 2004] [info] [client x.y.z.60] (104)Connection reset by peer: client stopped connection before rwrite completed [Mon Dec 27 07:47:41 2004] [info] [client x.y.z.179] send timed out [Mon Dec 27 07:47:41 2004] [info] [client x.y.z.179] client stopped connection before rvputs completed [Mon Dec 27 07:47:46 2004] [info] [client x.y.z..137] send timed out [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.137] client stopped connection before rvputs completed [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.60] send timed out [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.60] client stopped connection before rvputs completed [Mon Dec 27 07:47:46 2004] [info] [client x.y.z.225] (104)Connection reset by peer: client stopped connection before rwrite completed [Mon Dec 27 07:47:49 2004] [info] [client x.y.z.109] send timed out >Наблюдавай за връзки в наполовина-отворено (half-open) състояние с: >netstat -n -p TCP | grep SYN_RECV >даже може да го зациклиш да блъска във някой файл... На мен това ми беше една от първите идеи, точно това и направих, огледах резултантното файлче, SYN_RECV бяха около 200 , но трябва да се има в предвид че: при нормална работа има около 100 такива ( т.е. сървъра си е натоварен); syncoocies защитата ми е активна; нямаше много повтарящи се ip-та. >Разгледай малко tcp flags с: >tcpdump -i $IFACE 'tcp[tcpflags] & (tcp-syn ) != 0 ' -vvv >или >tcpdump -i $IFACE 'tcp[tcpflags] & (tcp-fin | tcp-syn | tcp-rst | tcp-push | >tcp-ack | tcp-urg) != 0 ' -vvv Това не съм го правил но трябва да се има в предвид че филтрирам някои шитс и меря количеството на филтрираните: #PROTECTION /sbin/iptables -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j b_block #disallow packets frequently used by port-scanners # All of the bits are cleared /sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j b_block # SYN and FIN are both set /sbin/iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j b_block # SYN and RST are both set /sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j b_block # FIN and RST are both set /sbin/iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j b_block # FIN is the only bit set, without the expected accompanying ACK /sbin/iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j b_block # PSH is the only bit set, without the expected accompanying ACK /sbin/iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j b_block # URG is the only bit set, without the expected accompanying ACK /sbin/iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j b_block /sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST,ACK SYN -j flood_prot /sbin/iptables -A INPUT -i eth0 -p icmp --icmp-type timestamp-request -j b_block ..и по време на кризисните периоди нямаше голямо увеличение на блокираните пакети b_block, нито съм имал логнати активации на флууд протекшъна. >2) tcp_max_syn_backlog задава колко на брой tcp връзки в наполовина отворено >състояние се допускат в backlog queue. >sysctl -w net.ipv4.tcp_max_syn_backlog=1024 Да евентуално мога да го намаля до 400 сега е 1024 3) tcp_syn_retries имаше ли в 2.4 ? ако има дай му 5-10. и въобще разгледай стойностите на променливите /proc/sys/net/ipv4/tcp* за нещо интересно. cat /proc/sys/net/ipv4/tcp_retries1 3 cat /proc/sys/net/ipv4/tcp_retries2 15 Смъкнал съм и някои други таймаутс и ретрайс.Увеличил съм и паметта за TCP/IP стека. Ето и топа от времето на проблема: 08:06:20 up 50 days, 13:25, 2 users, load average: 370.48, 363.99, 356.72 637 processes: 635 sleeping, 1 running, 1 zombie, 0 stopped CPU0 states: 3.1% user 2.2% system 0.0% nice 0.0% iowait 94.0% idle CPU1 states: 2.3% user 1.0% system 0.0% nice 0.0% iowait 96.0% idle CPU2 states: 4.2% user 0.4% system 0.0% nice 0.0% iowait 94.3% idle CPU3 states: 1.1% user 3.1% system 0.0% nice 0.0% iowait 95.1% idle Mem: 5030532k av, 4648888k used, 381644k free, 0k shrd, 1052k buff 1415204k actv, 1174416k in_d, 44920k in_c Swap: 530136k av, 0k used, 530136k free 2749728k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 11 root 15 0 0 0 0 SW 13.0 0.0 16:24 0 kswapd 29197 root 15 0 2104 2104 1608 S 12.4 0.0 7:01 2 httpd 30688 root 16 0 1632 1632 792 R 1.1 0.0 0:01 0 top 6 root 15 0 0 0 0 SW 0.1 0.0 1:32 1 keventd 2820 named 25 0 10192 9.9M 2112 S 0.1 0.2 46:47 2 named Странно ми е че след стоп и старт на апаче проблема не се оправи, а след рестарт се оправи .. --- Христо Чернев ----------------------------- Всичко е по-бързо и сигурно с БТК ADSL! http://www.telecom.bg/adsl/ ============================================================================ A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html ============================================================================