Re: lug-bg: Странен проблем с апаче
- Subject: Re: lug-bg: Странен проблем с апаче
- From: Hristo Chernev <chercho@xxxxxxx>
- Date: Tue, 28 Dec 2004 16:05:05 +0200
Благодаря на всички които отговориха, внасям малко яснота и допълнителни данни
и ви очаквам пак :)
>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
============================================================================
|