Re: lug-bg: Странен проблем с апаче
- Subject: Re: lug-bg: Странен проблем с апаче
- From: George Danchev <danchev@xxxxxxxxx>
- Date: Mon, 27 Dec 2004 20:07:31 +0200
On Monday 27 December 2004 15:00, Hristo Chernev wrote:
> Понеже нищо повече не ми ражда главата, ще се допитам до вас за проблема,
> който не ме остави да спя.
>
> Двупроцесорна машинка с Xeon-и, много памет - 5ГБ, scsi u160 диск. На нея -
> 2.4 кернел smp bigmem(redhat9), 1.3.31 апач с 4.3.9 php, qmail , bind
> 9.2.1.16 (rh). Има и малък firewall с iptables 1.2.7а.2.(rh)
>
> Както си работеше безпроблемно 2 месеца така тая нощ се появи 3 пъти
> проблема, като двата пъти изчезна след около половин час и работи нормално
> 2 часа, но третия си остана в такова - ни живо, ни умряло състояние:
>
> http услугата на апаче не отговаря или много бавно отговаря, apaчe
> процесите sa na max и са всички във 'W' състояние - Sending Reply, в лога
W май беше статус paging (man ps), може би поради това, че още не е уточнен
статуса на кънекшъна, но пък всички процеси да са в това състояние май вече
става подозрително.
> на системата нищо, на екрана нищо,в ерор лога на апача има много от тези и
> все от различни IP-ta:
> client stopped connection before rvputs completed
> client stopped connection before rwrite completed
Това наистина прилича на tcp syn attack, само, че тук си съкратил малко от
тези съобщения "client stopped connection" и има още неща освен rvputs,
rwrite....
Наблюдавай за връзки в наполовина-отворено (half-open) състояние с:
netstat -n -p TCP | grep SYN_RECV
даже може да го зациклиш да блъска във някой файл...
Разгледай малко 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
обаче това е интересно да се види по време на атаката.
Евентуални действия:
1) вдигаш tcp syncookies на 1 както беше казано, ако не помага, то не боли.
2) tcp_max_syn_backlog задава колко на брой tcp връзки в наполовина отворено
състояние се допускат в backlog queue.
sysctl -w net.ipv4.tcp_max_syn_backlog=1024
3) tcp_syn_retries имаше ли в 2.4 ? ако има дай му 5-10.
и въобще разгледай стойностите на променливите /proc/sys/net/ipv4/tcp* за нещо
интересно.
2 и 3 по-скоро ги провери и ги остави както, ако пак има грижа, може да ги
понамалиш малко...
инспектирането на syslog и messages за странни неща около часовете когато се е
наблюдавало това явление е силно препоръчително.
--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
============================================================================
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
============================================================================
|