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 ============================================================================
