|
Buscar |
Intervención sobre un servidor sobrecargadoCuando un servidor se cuelga y es necesario reiniciarlo (ver guía RebootDeLaMaquina) el problema es que no sabemos donde buscar el origen del problema. El siguiente método le dará algunas pistas: El cliente nos dice: El servidor se cuelga desde hace una semana. Debo reiniciar varias veces al día. servidor : xxxxx release : 1.36 ip : 213.186.41.xx hostname : nsxxx.ovh.net Estado Al comenzar hay que echar un vistazo al tráfico MRTG y al Real Time Monitoring.  Actualización Antes de nada hay que actualizar la versión de release del servidor. Con ello evitaremos todos los problemas de seguridad conocidos. siempre a menos que un hacker haya tomado el control, pues ya sería demasiado tarde. Si tiene una release 1.xx o 2.xx de OVH puede aplicar los parches de seguridad. Consulte nuestra guía : ReleasePatchSeguridad Si dispone de una distribución Debian stable o testing, actualice y aplique todos los paquetes de security.debian. Búsqueda Ahora que el servidor está actualizado en lo que a bugs de seguridad se refiere empezamos la búsqueda de los errores: # w 12:27pm up 1:21, 2 users, load average: 2.38, 2.57, 2.36 Efectivamente el servidor tiene un uptime de 1h21. La carga es ya importante. # free total used free shared buffers cachedMem: 514544 263096 251448 0 42388 80128 -/+ buffers/cache: 140580 373964 Swap: 522104 0 522104 140MB de RAM utilizada. No utiliza el swap. Visiblemente no vamos a buscar en esa dirección. # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntelcpu family : 15 model : 1 model name : Intel(R) Celeron(R) CPU 1.80GHz stepping : 3 cpu MHz : 1800.334 cache size : 20 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 3591.37 La máquina es un celeron 1.8GHz. Está bien saberlo para tener una idea de lo que la máquina es capaz de hacer. # dmesg Linux version 2.4.19 (root@install.ovh.net) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #2 SMP mer nov 20 17:40:06 CET 2002 [...] Freeing unused kernel memory: 256k freed Adding Swap: 522104k swap-space (priority -1) EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,1), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 41e1. No hay nada fuera de lo normal en dmesg. El núcleo no está actualizado, es todo. # ps auxw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [...] markus 13410 0.0 0.1 1932 860 ? S 12:38 0:00 /bin/sh -c $HOME/bin/rrd_update.pl 6 >/dev/null 2>&1 markus 13411 0.0 0.2 2588 1316 ? S 12:38 0:00 /usr/bin/perl -w /home/markus/bin/rrd_update.pl 6 [...] La salida estándar. Vemos un rrd_update ejecutándose. Nada grave. # netstat -tanpu Conexiones Internet activas (servidores y estaciones de trabajo) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name [...] tcp 0 0 213.186.41.43:80 80.13.42.22:2569 SYN_RECV - tcp 0 0 213.186.41.43:80 81.248.123.241:3932 SYN_RECV - tcp 0 0 213.186.41.43:80 81.50.163.43:4156 SYN_RECV - tcp 0 0 213.186.41.43:80 213.36.11.55:1328 SYN_RECV - tcp 0 0 213.186.41.43:80 217.128.9.248:34257 SYN_RECV - tcp 0 0 213.186.41.43:80 81.240.118.126:3747 SYN_RECV - tcp 0 0 213.186.41.43:80 213.228.52.184:3749 SYN_RECV - tcp 0 0 213.186.41.43:80 81.240.118.126:3743 SYN_RECV - tcp 0 0 213.186.41.43:80 81.248.123.241:3931 SYN_RECV - tcp 0 0 213.186.41.43:80 81.50.163.43:4191 SYN_RECV - tcp 0 0 213.186.41.43:80 213.36.11.55:1327 SYN_RECV - [...] Hay bastantes SYN_RECV. Como la IP es diferente cada vez, podemos pensar que el servidor web tiene bastantes conexiones, y ahí hay 11 conexiones que todavía no han podido abrirse. Vamos a comprobar los parámetros de apache: # pico /usr/local/apache/conf/httpd.conf # ¿no hay parámetros que conciernen a apache? Extraño... Vamos a añadir algunos parámetros de base para comenzar bien: MinSpareServers 20MaxSpareServers 100StartServers 30MaxClients 60MaxRequestsPerChild 60y reiniciamos apache: # /root/apare /usr/local/apache/bin/apachectl stop: httpd stopped /usr/local/apache/bin/apachectl start: httpd started # w 12:46pm up 1:39, 1 user, load average: 2.54, 1.84, 2.04USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 213.244.20.43 11:52am 0.00s 0.14s 0.01s w # netstat -tanpu [...] De este modo es posible que se solucione el problema. Vamos a usar la herramienta top para comprobarlo. Usando TOP La herramienta top nos permite ver lo que sucede en tiempo real: # top 12:48pm up 1:41, 1 user, load average: 1,79, 1,81, 2,01 116 processes: 114 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 27,7% user, 14,8% system, 0,0% nice, 57,3% idle Mem: 514544K av, 286228K used, 228316K free, 0K shrd, 43616K buff Swap: 522104K av, 0K used, 522104K free 82676K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 14461 nobody 18 0 6936 6936 4132 S 12,1 1,3 0:01 httpd 14516 nobody 9 0 6308 6308 4168 S 3,5 1,2 0:00 httpd 14465 nobody 9 0 6860 6860 4156 S 2,9 1,3 0:00 httpd 14625 nobody 9 0 6924 6924 4152 S 0,7 1,3 0:01 httpd 111 root 9 0 0 0 0 SW 0,5 0,0 0:41 kjournald 14646 root 12 0 1092 1092 828 R 0,5 0,2 0:00 top 14759 root 9 0 716 716 640 S 0,3 0,1 0:00 crond 14765 markus 8 0 1316 1316 1112 S 0,3 0,2 0:00 rrd_update.pl 8 root 9 0 0 0 0 SW 0,1 0,0 0:47 kjournald 440 root 9 0 592 592 488 S 0,1 0,1 0:00 syslogd 803 root 9 -3 1284 1284 1216 S 0,1 0,2 0:00 ncftpd 6763 root 9 0 2076 2076 1708 R 0,1 0,4 0:00 sshd 14484 nobody 9 0 6932 6932 4172 S 0,1 1,3 0:00 httpd 14535 nobody 9 0 6836 6836 4164 S 0,1 1,3 0:00 httpd 14540 nobody 9 0 6508 6508 4164 S 0,1 1,2 0:00 httpd 1 root 8 0 524 524 456 S 0,0 0,1 0:09 init Vemos que hay un 57.3% de CPU libre. La RAM va bien. Algunos procesos httpd consumen bastante CPU. También kjournald nos informa de que hay bastantes accesos al disco duro. Nada grave. Dejamos que top se ejecute y vemos lo que pasa. Algunos minutos más tarde: 12:51pm up 1:44, 1 user, load average: 4,68, 2,75, 2,30 138 processes: 125 sleeping, 12 running, 1 zombie, 0 stopped CPU states: 66,5% user, 33,2% system, 0,0% nice, 0,0% idle Mem: 514544K av, 437532K used, 77012K free, 0K shrd, 44040K buff Swap: 522104K av, 0K used, 522104K free 83288K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 15172 mysql 15 0 5048 5048 1188 R 7,7 0,9 0:00 mysqld 14475 nobody 14 0 15460 15M 4152 R 7,3 3,0 0:05 httpd 15175 mysql 15 0 5048 5048 1188 R 7,3 0,9 0:00 mysqld 14623 nobody 14 0 16004 15M 4160 S 6,1 3,1 0:01 httpd 15155 mysql 11 0 5048 5048 1188 S 6,1 0,9 0:00 mysqld 14468 nobody 14 0 16988 16M 4160 S 5,7 3,3 0:02 httpd 15168 mysql 10 0 5048 5048 1188 S 5,5 0,9 0:00 mysqld 15173 mysql 15 0 5048 5048 1188 R 5,3 0,9 0:00 mysqld 14533 nobody 9 0 7064 7064 4164 S 3,9 1,3 0:01 httpd 14549 nobody 10 0 17384 16M 4144 S 3,9 3,3 0:02 httpd 14551 nobody 10 0 17492 17M 4144 S 3,9 3,3 0:00 httpd 15158 mysql 9 0 5048 5048 1188 S 3,5 0,9 0:00 mysqld 14467 nobody 9 0 18168 17M 4192 S 3,3 3,5 0:02 httpd 14481 nobody 9 0 18056 17M 4128 S 3,1 3,5 0:01 httpd 15159 mysql 9 0 5048 5048 1188 S 3,1 0,9 0:00 mysqld 14459 nobody 9 0 18028 17M 4148 S 2,7 3,5 0:02 httpd 14625 nobody 9 0 17924 17M 4152 S 2,5 3,4 0:03 httpd 15157 mysql 9 0 5048 5048 1188 S 2,3 0,9 0:00 mysqld 14469 nobody 9 0 17908 17M 4172 S 1,9 3,4 0:03 httpd 14550 nobody 9 0 17772 17M 4168 S 1,9 3,4 0:04 httpd 15153 mysql 9 0 5048 5048 1188 S 1,7 0,9 0:00 mysqld 14485 nobody 11 0 6816 6816 4168 S 1,5 1,3 0:01 httpd 15160 mysql 9 0 5048 5048 1188 S 1,5 0,9 0:00 mysqld 14463 nobody 15 0 7112 7112 4160 R 1,1 1,3 0:04 httpd 15156 mysql 9 0 5048 5048 1188 S 1,1 0,9 0:00 mysqld 15176 mysql 9 0 5048 5048 1188 S 1,1 0,9 0:00 mysqld 14646 root 12 0 1092 1092 828 R 0,7 0,2 0:01 top Ya no queda CPU, el consumo de RAM es cada vez más importante, la carga aumenta. Cada vez hay más procesos httpd y mysql que consumen todos los recursos. Dejamos que top se ejecute un poco más. 4 horas después: 4:47pm up 5:41, 2 users, load average: 47,83, 23,91, 12,70 185 processes: 138 sleeping, 47 running, 0 zombie, 0 stopped CPU states: 21,0% user, 73,4% system, 0,0% nice, 5,5% idle Mem: 514544K av, 511596K used, 2948K free, 0K shrd, 1168K buff Swap: 522104K av, 272488K used, 249616K free 25696K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 10072 nobody 15 0 14368 13M 5992 R 1,9 2,7 0:15 httpd 9500 nobody 9 0 17416 8376 7352 D 1,6 1,6 0:18 httpd 9872 nobody 10 0 17372 8796 7476 R 1,4 1,7 0:11 httpd 13684 nobody 14 0 14588 5896 2744 R 1,4 1,1 0:01 httpd 13618 nobody 11 0 14292 5416 2736 S 1,1 1,0 0:01 httpd 13363 nobody 15 0 14028 6124 2820 S 1,0 1,1 0:02 httpd 12584 nobody 13 0 14120 13M 2812 S 0,9 2,6 0:06 httpd 13461 nobody 16 0 14436 5008 2824 S 0,9 0,9 0:02 httpd 13534 mysql 14 0 14692 10M 2452 R 0,9 1,9 0:01 mysqld 10683 nobody 13 0 13148 12M 5616 S 0,8 2,4 0:08 httpd 13479 nobody 19 0 14344 5948 2820 R 0,8 1,1 0:02 httpd 13653 mysql 12 0 14692 10M 2452 S 0,8 1,9 0:00 mysqld 13690 mysql 15 0 14692 10M 2452 R 0,8 1,9 0:01 mysqld 9497 nobody 9 0 17384 8932 6876 R 0,7 1,7 0:14 httpd 10685 nobody 15 0 13324 12M 5616 R 0,7 2,4 0:12 httpd 13037 nobody 9 0 14848 14M 2792 R 0,7 2,7 0:03 httpd 13521 mysql 18 0 14692 10M 2452 R 0,7 1,9 0:00 mysqld 13539 mysql 14 0 14692 10M 2452 R 0,7 1,9 0:01 mysqld 13612 mysql 14 0 14692 10M 2452 S 0,7 1,9 0:00 mysqld 13650 nobody 14 0 15276 5888 2752 R 0,7 1,1 0:02 httpd 13652 mysql 10 0 14692 10M 2452 S 0,7 1,9 0:00 mysqld 8469 nobody 9 0 14100 13M 2728 D 0,6 2,6 0:15 httpd 8603 nobody 9 0 13004 12M 2648 R 0,6 2,4 0:23 httpd 8636 nobody 9 0 12256 11M 2644 D 0,6 2,2 0:18 httpd El servidor está prácticamente colgado. La carga es muy importante. Ya no queda CPU libre, ni RAM disponible. Intentamos recuperar el servidor antes de que se cuelgue. Algunos minutos para ejecutar el comando... # killall -9 httpd Y listo, le tenemos recuperado. Dese prisa en comprobar si queda algo interesante: # w 4:56pm up 5:50, 2 users, load average: 45.38, 44.91, 29.18# netstat -tanpu [...] Nada especial. Vemos los logs: # cd /usr/local/apache/logs/ # tail -n 100 *_log Resultado: visiblemente el servidor se cuelga porque se ejecutan programas muy pesados. Hay que utilizar server-status para recuperar los datos sobre las solicitudes hechas sobre el servidor, de la misma forma que recuperaríamos la información con top. Server Status y OTOP Un poco de lectura y configuración: ConfigurarYUtilizarServerStatus # telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is ' '. GET /ovh-status HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 09 Nov 2003 16:03:54 GMT Server: Apache/1.3.28 (Unix) mod_gzip/1.3.19.1a PHP/4.3.3 .+OpenSSL+-/0.9.6i Connection: close Content-Type: text/html < !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">< html><head>< title>Apache Status</title>< /head><body>< h1>Apache Server Status for nsXXXX.ovh.net</h1>Server Version: Apache/1.3.29 (Unix) mod_gzip/1.3.19.1a PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.6lServer Built: Dec 5 2003 09:37:56 < hr>Current Time: Thursday, 10-Jun-2004 11:35:24 CEST Restart Time: Thursday, 10-Jun-2004 10:37:04 CEST Parent Server Generation: 0 Server uptime: 6 seconds Total accesses: 52 - Total Traffic: 4 kB CPU Usage: u1.19 s.81 cu0 cs0 - 33.3% CPU load 8.67 requests/sec - 682 B/second - 78 B/request 8 requests currently being processed, 22 idle servers _KKKKKWKK [...] Ya está, ahora tenemos la posibilidad de seguir las peticiones que están en proceso de ejecución en el servidor. Vamos a instalar una pequeña utilidad de OVH: otop. El código fuente es tan simple como eficaz: se conecta a Apache para recuperar Server-Status? y filtra y ordena el resultado. # cat > otop.pl # cat > otop # chmod 755 otop.pl otop # ./otop ns30075.ovh.net — GET /ovh-status HTTP/1.0 — 127.0.0.1 — ns30075 www.tv-realite.net — GET /images/button.gif HTTP/1.1 — 81.49.201.169 — ns30075 www.tv-realite.net — GET /images/button.gif HTTP/1.1 — 82.65.220.249 — ns30075 www.tv-realite.net — GET /images/icons/profile.gif HTTP/1.1 — 193.248.177.54 — ns30075 www.tv-realite.net — GET /images/smilies/icon_wink.gif HTTP/1.1 — 62.147.34.237 — ns30075 www.tv-realite.net — GET /images/subject/icon32.gif HTTP/1.1 — 62.147.216.161 — ns30075 www.tv-realite.net — GET /modules/dbcounter/cache/cpt.php HTTP/1.1 — 62.147.216.161 — ns30075 www.tv-realite.net — GET /modules/dbcounter/cache/cpt.php HTTP/1.1 — 62.39.220.121 — ns30075 www.tv-realite.net — GET /modules/dbcounter/cache/cpt.php HTTP/1.1 — 81.50.123.85 — ns30075 www.tv-realite.net — GET /modules/forum/ HTTP/1.1 — 81.249.117.200 — ns30075 www.tv-realite.net — GET /modules/Jeux/Jeux/Action/pacmanswf/pacman.swf HTTP/1.1 — 80.238.52.86 — ns30075 www.tv-realite.net — GET /modules/magalerie/galerie/Star%20Academy%202/Jeremy/jerem3 — 80.238.52.86 — ns30075 www.tv-realite.net — GET /modules/news/images/friend1.gif HTTP/1.1 — 81.50.47.133 — ns30075 www.tv-realite.net — GET /modules/news/images/print1.gif HTTP/1.1 — 81.48.39.152 — ns30075 www.tv-realite.net — GET /smilies/fouet.gif HTTP/1.1 — 62.147.210.205 — ns30075 www.tv-realite.net — GET /smilies/nixweiss.gif HTTP/1.1 — 62.147.210.205 — ns30075 www.tv-realite.net — GET /smilies/oops.gif HTTP/1.1 — 213.36.58.1 — ns30075 www.tv-realite.net — GET /smilies/oops.gif HTTP/1.1 — 81.50.123.85 — ns30075 www.tv-realite.net — GET /smilies/tesbete.gif HTTP/1.1 — 81.248.97.134 — ns30075 www.tv-realite.net — GET /themes/FD-Bluenet/images/bag2.gif HTTP/1.1 — 193.248.177.54 — ns30075 www.tv-realite.net — GET /themes/FD-Bluenet/images/bag2.gif HTTP/1.1 — 81.48.39.152 — nsxxxx www.tv-realite.net — GET /themes/FD-Bluenet/images/bag2.gif HTTP/1.1 — 81.49.201.169 — nsxxxx www.tv-realite.net — GET /themes/FD-Bluenet/images/bag2.gif HTTP/1.1 — 82.65.220.249 — nsxxxx www.tv-realite.net — GET /themes/FD-Bluenet/images/top.gif HTTP/1.1 — 195.93.73.6 — nsxxxx También nos conectamos en una segunda consola para lanzar Otop. Vamos a hacerlo funcionar cada 2 segundos para encontrar el problema: # while true; do ./otop; sleep 2;done & Y lo dejamos funcionar durante varias horas. Cinco minutos más tarde, la máquina está ya fuera de línea: nsxxxx.ovh.net — GET /ovh-status HTTP/1.0 — 127.0.0.1 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 172.190.55.200 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 193.248.171.49 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 195.93.66.12 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 202.123.0.150 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 217.128.35.49 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 80.201.114.225 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 81.249.82.249 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 81.64.6.73 — nsxxxx www.tv-realite.net — GET / HTTP/1.1 — 81.64.6.73 — nsxxxx www.tv-realite.net — GET /images/library/starac3-2/3nolwenn-2.jpg HTTP/1.1 — 213.228.55.146 — ns30075 www.tv-realite.net — GET /images/library/starac3-2/3nolwenn-4.jpg HTTP/1.1 — 213.228.55.146 — nsxxxx www.tv-realite.net — GET /modules/forum/ HTTP/1.1 — 172.178.136.110 — nsxxxx www.tv-realite.net — GET /modules/forum/ HTTP/1.1 — 213.44.198.73 — nsxxxx www.tv-realite.net — GET /modules/forum/ HTTP/1.1 — 213.44.198.73 — nsxxxx www.tv-realite.net — GET /modules/magalerie/galerie/Star%20Academy%202/cloclo_tf1_11 — 82.65.220.249 — nsxxxx www.tv-realite.net — GET /modules/magalerie/images/rank3dbf8e9e7d88d.gif HTTP/1.1 — 82.65.220.249 — nsxxxx www.tv-realite.net — GET /modules/mylinks/ratelink.php?lid=129 HTTP/1.1 — 82.64.102.4 — nsxxxx www.tv-realite.net — GET /modules/mylinks/ratelink.php?lid=129 HTTP/1.1 — 82.64.102.4 — nsxxxx www.tv-realite.net — GET /modules/newbb_plus/index.php HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 195.93.64.6 — nsxxxx www.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 62.203.3.242 — ns30075 www.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 62.203.3.242 — nsxxxxwww.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 62.203.3.242 — nsxxxxwww.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=1 HTTP/1.1 — 62.203.3.242 — nsxxxxwww.tv-realite.net — GET /modules/newbb_plus/viewforum.php?forum=3 HTTP/1.1 — 62.203.3.242 — nsxxxxwww.tv-realite.net — GET /modules/news/article.php?item_id=2298 HTTP/1.1 — 193.248.177.54 — ns30075www.tv-realite.net — GET /modules/news/article.php?storyid=2490 HTTP/1.1 — 81.49.201.169 — ns30075www.tv-realite.net — GET /modules/news/article.php?storyid=2490 HTTP/1.1 — 81.49.201.169 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2490 HTTP/1.1 — 81.49.201.169 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2490 HTTP/1.1 — 81.49.201.169 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2497 HTTP/1.1 — 81.49.201.169 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2499 HTTP/1.1 — 213.36.11.162 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2499 HTTP/1.1 — 213.36.11.162 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2499 HTTP/1.1 — 213.36.11.162 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2499 HTTP/1.1 — 213.36.11.162 — ns30075 www.tv-realite.net — GET /modules/news/article.php?storyid=2508 HTTP/1.1 — 62.147.34.237 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=22 HTTP/1.1 — 80.14.69.42 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — ns30075 www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/news/index.php?storytopic=27 HTTP/1.1 — 62.203.3.242 — nsxxxx www.tv-realite.net — GET /modules/sections/index.php?op=viewarticle&artid=30 HTTP/1. — 217.128.35.49 — nsxxxx www.tv-realite.net — GET /modules/xoopspoll/index.php HTTP/1.1 — 195.93.72.10 — nsxxxx www.tv-realite.net — GET /modules/xoopspoll/index.php?poll_id=62 HTTP/1.1 — 193.252.57.189 — nsxxxx www.tv-realite.net — GET /modules/xoopspoll/pollresults.php?poll_id=62 HTTP/1.1 — 172.178.136.110 — nsxxxx www.tv-realite.net — GET /modules/xoopspoll/pollresults.php?poll_id=62 HTTP/1.1 — 172.188.48.244 — nsxxxx www.tv-realite.net — GET /modules/xoopspoll/pollresults.php?poll_id=62 HTTP/1.1 — 172.188.48.244 — nsxxxx www.tv-realite.net — GET /modules/xoopspoll/pollresults.php?poll_id=62 HTTP/1.1 — 62.147.34.237 — nsxxxx www.tv-realite.net — GET /modules/xtremguestbook/index.php?limite=40 HTTP/1.1 — 80.200.25.198 — ns30075 www.tv-realite.net — GET /themes/FD-Bluenet/images/top.gif HTTP/1.1 — 213.36.64.61 — ns30075 www.tv-realite.net — GET /user.php HTTP/1.1 — 193.250.7.174 — ns30075 [root@nsxxxx root]# killall -9 httpd [root@nsxxxx root]# Bueno, los scripts PHP se consultan con una violencia que bloquea el servidor. ¿Se trata de un ataque? Vamos a comprobarlo. Para ello bloqueamos (blacklist) las IPs de las peticiones: Lista negra con IP-Tables Reiniciamos Apache y el Otop, conectándonos en otra consola para hacer la operación de blacklist. Primera consola: [root@ns30075 root]# /root/apare /usr/local/apache/bin/apachectl stop: httpd (pid 15167?) not running /usr/local/apache/bin/apachectl start: httpd started [root@ns30075 root]# while true; do ./otop; sleep 2;done & Segunda consola: [root@nsxxxx root]# cat > liste.sh /usr/local/sbin/iptables -t mangle -A PREROUTING -i eth0 -s $1/32 -d 0.0.0.0/0 -j DROP [root@nsxxxx root]# chmod 755 liste.sh [root@nsxxxx root]# ./liste.sh 62.203.3.242 ./liste.sh: /usr/local/sbin/iptables: No such file or directory [root@nsxxxx root]# /sbin/iptables [root@nsxxxx root]# pico liste.sh [root@nsxxxx root]# ./liste.sh 62.203.3.242 iptables: libiptc/libip4tc.c:384: do_check: Assertion `h->info.valid_hooks (1 << 0 | 1 << 3)' failed. ./liste.sh: line 1: 18721 Aborted /sbin/iptables -t mangle -A PREROUTING -i eth0 -s $1/32 -d 0.0.0.0/0 -j DROP [root@nsxxxxx root]# Bueno, parece ser que el kernel nuevo y IPtables no funcionan bien juntos. Vamos a recompilar una versión de IPtables que funcione: [root@nsxxxxx root]# cd /temp bash: cd: /temp: No such file or directory [root@nsxxxxx root]# mkdir /temp [root@nsxxxxx root]# cd /temp [root@nsxxxxx temp]# wget http://netfilter.org/projects/iptables/files/iptables-1.2.9.tar.bz2--17:25:19-- http://netfilter.org/projects/iptables/files/iptables-1.2.9.tar.bz2=> `iptables-1.2.9.tar.bz2' Resolviendo netfilter.org... 213.95.27.115, 2001:780:0:1d:20d:93ff:fe9b:e443 Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 186,808 (182K) application/x-tar 100%[====================================>] 186,808 98.15K/s 00:31:22 (97.89 KB/s) - `iptables-1.2.9.tar.bz2' saved [186808/186808] [root@nsxxxxx temp]# tar xfj iptables-1.2.9.tar.bz2 [root@nsxxxxx temp]# cd iptables-1.2.9 [root@nsxxxxx iptables-1.2.9]# make Paramos Apache durante la compilación: [root@nsxxxx root]# killall -9 httpd [root@nsxxxx root]# En la segunda consola, todo compila perfectamente [...] [root@nsxxxx iptables-1.2.9]# rpm -e iptables [root@nsxxxx iptables-1.2.9]# make install [...] Un nuevo test para saber si funciona mejor: root@ns30075 iptables-1.2.9# cd root@ns30075 root# ./liste.sh 62.203.3.242 root@ns30075 root# /usr/local/sbin/iptables -t mangle -L PREROUTING -n Chain PREROUTING (policy ACCEPT) target prot opt source destination DROP all — 62.203.3.242 0.0.0.0/0 Y entonces, podemos comenzar la caza: Volvemos a lanzar el Apache y el Otop en una primera consola : [root@nsxxxx root]# /root/apare /usr/local/apache/bin/apachectl stop: httpd (pid 17618?) not running /usr/local/apache/bin/apachectl start: httpd started [root@nsxxxx root]# while true; do ./otop; sleep 2;done y en la segunda, estamos listos para introducir la IP y bloquearla: [root@nsxxxx root]# ./liste.sh XX.XX.XX.XX [root@nsxxxx root]# ./liste.sh XX.XX.XX.XX [root@nsxxxx root]# ./liste.sh XX.XX.XX.XX .. Treinta minutos más tarde, la máquina se bloquea con el mismo problema; incluso bloqueando las IPs. El problema no es del servidor ni de un ataque, sino símplemente de los scripts. El cliente deberá optimizar sus scripts y los accesos a la base para evitar sobrecargar la máquina, pero eso es otra historia... Todos los casos: ServidorSobrecargado |
