Casi siempre todo funciona bien, el servidor es robusto y responde sin muchas preocupaciones pero el problema llega cuando uno de estos robots se vuelve loco. Seguramente esta locura es producida por algún cambio en alguna variable que fuerza el número de escaneados diarios que realiza el bot, de esa forma el humano “snifante” prueba con diversos valores subiendo a veces sin saberlo la cantidad de peticiones por minuto de forma exponencial, el no ve las repercusiones en el servidor de origen, probablemente se dice, que bien ahora así tengo el contenido nuevo tan pronto como se publica, si soy el primero posiciono mejor, lo voy a dejar así. Y sin saberlo está haciendo un ataque DDOS o de denegación de servicio.

En este caso concreto es tal el consumo que en hora punta de tráfico las peticiones se enletecen hasta más allá de los 3 segundos por página peticionada.

Lo primero es detectar que algo paso, esto por suerte te lo dicen los clientes del servicio web en cuestión con emails técnicos del tipo:

“La web va lenta”, “La web va como el c…”

Recibido el tercer email de este tipo y tras comprobar que no es un problema de la conexión del cliente hacia la red, que también reportan, toca averiguar que está pasando.

1. Vemos el estado de saturación de la máquina. En Windows con el Administrador de Tareas.

2. Lo primero es ver que tal estamos de RAM, que consumo tenemos.

3. Luego vemos el espacio en disco que nos queda

4. El consumo de CPU

5. Ahora vamos a ver con ese mismo administrador de tareas que “programas” son los que más consumen

Si es MYSQL y la RAM va cargada tocará ampliar RAM, al igual de que si es disco.

Si es APACHE y la CPU va saturada, pues tocará ver cuantas peticiones y de quien son recibe el servidor web.

Para conocer cuantas peticiones recibe nuestro server hay muchas cosas y programas, pero en este caso no hay ningún sistema estadístico instalado, bueno si, Google Analytics, el cual pinta y colorea los datos que da gusto, pero a nivel técnico no nos sirve pues estamos buscando excesos y errores y me da a mi que Analytics los obvia, a saber porque con la todopoderosa y sus manías, que ya me cansan.

Aunque no tengamos nada instalado en server siempre nos podemos bajar los archivos de log del Apache para analizarlos en casita, con nuestra maquinita.

Ten en cuenta que estos archivos pueden ser gigantes, depende de como esté configurado el server, los hay con rotaciones y sin, pero puedes encontrartes con archivos de 2Gb. en servidores de alto tráfico, lidia con ellos si puedes. Lo mejor es rotarlos manualmente en el momento de máximo tráfico o ataque.

Para ello, detén el servicio de Apache, renombra los access.log y error.log y vuelve a iniciarlo, dejarás a tu cliente sin servicio un minuto escaso. Aguanta un ratito con el ataque, un par de horas a lo sumo, y vuelve a hacer lo mismo, de esa forma tendrás una muestra sanguínea del ataque o del momento de saturación del server y trabajarás única y exclusivamente con esos datos, localizando más rápidamente si existen direcciones IPs que un consumo excesivo de datos.

De Windows a Ubuntu y tiro porque me toca

Una vez muevas ese log a una carpeta accesible por FTP o HTTP faltará bajártela para analizarla en tu flamante workstation Ubuntu, que mola más que un OS X… al menos más que un Snow Leopard, pues falta ver si este próximo lunes día 6 de Junio lo que nos maravilla OS X Lion de la mano de Steve Jobs, palabra de AppleFun arrepentido venido a Ubuntu.

Analizando los archivos .log de Apache

Para analizarlo en nuestro Ubuntu vamos a usar Webzilla, para instalártela:

sudo apt-get install webalizer

Luego la configuramos con un:

sudo gedit /etc/webalizer/webalizer.conf

Aquí en principio sólo falta tocar el lugar, ruta y archivo donde está el access.log

LogFile                   /var/www/logs-para-analizar/access.log
OutputDir              /var/www/webalizer
Incremental           yes

Grabamos y ejecutamos el Webalizer con un complejísimo, es broma:

sudo webalizer

Unos segunditos y tachán, apunta tu navegador a:

http://localhost/webalizer

Selecciona el mes actual, y en la siguiente pantalla la opción “Clientes” aquí verás las IPs que han visitado más la página durante el ataque o la bajada de rendimiento del server, busca las más abultadas que vamos a revisarlas.

Ahora nos faltará saber el Quién es quién de cada IP

¿Quién es quién?

Para eso podemos usar varias opciones, entre ella una via web:

http://whois.domaintools.com/67.195.112.52

Donde 67.195.112.52 es la IP sobre la que quieres conocer información y la otra es usar las herramientas de red del sistema que incorpora Ubuntu.

Con ellas puedes realizar un WHOIS, un LOOKUP , etc.

Si entras en “Explorar los puertos”, cosa que tarda un rato podrás también detectar si detrás hay un servidor web, un servidor FTP, o un emule abierto. Datos que te permitirán determinar con algo más de certeza si se trata de una empresa o un usuario.

También puedes rastrear la ruta para más o menos ver de donde es el país de origen, si este por ejemplo es de Ukrania o de la conchinchina probablemente se trate de un buscador en el que no te importe perder posicionamiento.

Cuidadín cuidadín con los GoogleBots y familia

Pues eso, asegúrate que de todas esas IPs no te apuntes ninguna que sea de un buscador conocido en el que te quieras posicionar, pues si la anotas y luego la baneamos perderás el posicionamiento en ese buscador pues tu Apache no le dejará entrar.

Ya tenemos las IPs localizadas y correctamente anotadas, ahora vamos a banearlas

Baneando IPs en Apache bajo Windows

Bueno esto a decir verdad es más o menos igual en Windows que en Linux que un radiocassette donde sea capaz de correr Apache.

Busca el fichero de configuración de Apache httpd.conf

En la sección Directory

Introduce al final, justo antes del cierre de la directiva </Directory> y una en cada línea la siguiente instrucción:

deny from TU-NO-PASAS

por ejemplo si quisiéramos banear a Yahoo, NO lo hagas!

deny from 67.195.112.52

Graba el fichero y reinicia Apache, en Windows desde “Accesorios -> Herramientas del Sistema -> Servicios -> Apache” botón de la derecha reiniciar.

Listas negras de IPs malignas

También de paso y por el mismo precio que nos ponemos a banear, una práctica aceptable sería el banear sistemáticamente aquellas IPs que se han detectado en el mundo recientemente como IPs malignas.

Yo he sacado una lista desde:

http://isc.sans.org/ipsascii.html

y desde:

http://isc.sans.org/sources.html

Baneando que es gerundio.

Páginas relacionadas con este artículo:

1. Test de carga web
2. Personalizar un virtual host de Apache bajo Plesk
3. Bloquear muchos intentos fallidos de acceso a servidor

Protegiendo Apache, FTP y los servidores de correo con Fail2Ban

Funciona de una forma muy sencilla, Fail2Ban lee los archivos de log de accesos por password o los errores del fichero de errores de apache error_log vetando a través del Firewall aquellas IPs que fallan muchas veces

Para instalarlo, desde Ubuntu o Debian:

sudo apt-get install fail2ban

Páginas relacionadas con este artículo:

1. Baneando direcciones IPs en Apache bajo Windows
2. Test de carga web
3. Optimizar servidor MySQL

Esto se hace editando el facilísimo, ejem, .htaccess de Apache, con sus directivas, que ninguna está buena ni te pone, al revés son la repera, difíciles por ser casi todas iguales, así que traes leer en ellas en diferentes blogs y comprobar que no me ha servido ninguna para este, mi caso, he decidido hacer un “brevepost” para que aquí quede si alguien debe en el futuro lidiar con ello:

Redirect 301 “/Longboard-completo/”  http://www.tulongboard.es/longboards-bambu-series/
Redirect 301 “/Mochilas-Skate/”  http://www.tulongboard.es/mochilas-longboard/
Redirect 301 “/Longboard/”  http://www.tulongboard.es/longboards-baratos/

Es decir:

Redirect 301 “página en servidor A sin las http://www.dominioA.com, es decir solo el QUERY_STRING” http://www.dominioB.es/pagina-html-destino

Así de fácil!

Páginas relacionadas con este artículo:

1. Ocultar los datos de registro de un dominio
2. Extensiones de dominio disponibles en el mundo
3. Personalizar un virtual host de Apache bajo Plesk

No se si es porque no me leo la documentación de nada de cabo a rabo, de ser así probablemente estaría leyendo aún los manuales de la PalmPilot I, o siendo sinceros los del ZX Spectrum pero el modulito mod_pagespeed que lanzó Google me ha dado por saco durante horas, deteniendo mi producción “pa na”.

Os explico a continuación, me lo instalé hace unos días en mi máquina con Ubuntu donde desarrollo aplicaciones web como siempre para trastear con ello y ganar algo de velocidad en descarga, pues bien en esta máquina es donde mismamente estoy mejorando el sistema de emailing que incorpora mi aplicación de facturación electrónica invOOice.com.

Con este modulo instalado, que debe ir de narices para máquinas en producción, Apache2 te crea un directorio donde cachea ficheros estáticos, por ejemplo los ficheros .js con javascript, luego al hacer cambios y grabarlos, Apache2 no se entera durante un cierto tiempo y el problema es que cambias y no ves los resultados producidos por el cambio, todo esto durante horas hasta que al final con un alert(‘hola hola’) que no aparecía por ningún lado me di cuenta de que esto leía de algún sitio que no era el suyo, nada, ves el código fuente, te fijas y tachán:

forms.ajax.js.pagespeed.ce.QB8x0iVrtt.js

Grrrr… ahora ármate de valor baja a la línea de comandos y desinstala el módulo pagespeed, eh? bueno, pues para eso os copio aquí la solución, a grandes trazos borrar los módulos a saco paco del directorio de módulos de apache:

cd /etc/apache2/mods-enabled/

rm pagespeed.conf

rm pagespeed.load

y reniciamos Apache con un!

/etc/init.d/apache2 restart

Te quedará una carpeta en apache2 con los cachés, yo no la he borrado, en cuanto pueda volveré a experimentar con pagespeed pues se notaba bastante, pero por el momento vamos a lo que vamos.

Páginas relacionadas con este artículo:

1. Habilitar cURL en Ubuntu
2. Habilitar cURL en Ubuntu
3. Instalar Apache 2 PHP 5 MYSQL 5 y Webmin 1.5

Tras actualizar el Ubuntu de mi portátil desde la versión 10.04 LTS a la 10.10 he podido comprobar que de momento casi todo funciona, no obstante ha dejado de funcionar el mod_rewrite de Apache.

Este módulo nos sirve para que el sistema interprete URLs bonitas, es decir en lugar de un:

index.php?prodid=1234&fam=9, podría quedar: /fregaplatos/phillips-madeira.

Lo primero es asegurarnos que el módulo está activado y habilitado, para ello utiliza:

sudo a2enmod rewrite

Lo siguiente y algo más complejo es modificar nuestro archivo de host que encontrarás en /etc/apache2/sites-enabled/000-default

sudo nano /etc/apache2/sites-enabled/000-default

En este archivo hay que cambiar el parámetro de AllowOverride None a AllowOverride All

Grabamos y forzamos el reinicio de Apache con:

sudo /etc/init.d/apache2 force-reload

Páginas relacionadas con este artículo:

1. Habilitar permalinks en Apache 2
2. Habilitar cURL en Ubuntu
3. Condiciones en mod_rewrite para la redirección

Muchas de estas aplicaciones ya las conocía, pero de todas, me quedo con http://loadimpact.com/

Sencillamente porque su versión gratuita te permite simular hasta 40 usuarios navegando simultáneamente en tu página web, cifra más que suficiente para poder medir cualquier hosting y predecir si se va a caer.

Para los programadores web tiene otra utilidad, la de la optimización, sí ya sabes que arañar unos bytes a tu código siempre le sienta bien, pero bueno, ¿tan poco se nota? Dedicar 4 horas depurando para unos pocos bytes es rentable. Si te lo pagan sí. Por ejemplo en aplicaciones críticas con muchos usuarios concurrentes quizá el primer paso es optimizar y no proceder a cambiar de hosting o de servidor con elcoste que implica.

Esta prueba de rendimiento en masa tiene otras aplicaciones, no sólo podrás saber si el hosting que tienes o el de tus clientes es bueno sino que también si eres de sistemas te permitirá comprobar la eficacia en cuanto a rendimiento de los cambios de configuración que realices en la configuración de un servidor. Incluso ir un paso más allá, podrás medir diferentes servidores web, Apache bajo Windows, Apache bajo Linux, Nginx, Cherooke…

Bueno pues nada, a optimizar nenes y nenas de la web!: http://loadimpact.com/

Páginas relacionadas con este artículo:

1. Comprobar la velocidad de carga de una web
2. Nginx y phpMyAdmin
3. Baneando direcciones IPs en Apache bajo Windows

http://www.hongkiat.com/blog/website-speed-and-performance-check-tools/

Páginas relacionadas con este artículo:

1. Optimizar la velocidad de descarga de una web
2. Comprobar velocidad servidor
3. Test de carga web

Ahora bien, Plesk tiene como todos los sistemas bonitos y muy domesticados algunas limitaciones que sólo podrás superar gracias a la línea de comandos del sistema, es decir, pasando completamente de la interficie de Plesk, es aquí donde se nos ha planteado el siguiente problema:

Necesitamos que varios dominios apunten al mismo directorio físico del disco duro pero conservando su host, es decir no valen redirecciones de dominio, esto es para nuestro sistema de gestión de tiendas online ecOOmmerce.com que soporta un sistema multitienda es decir, mismo catálogo de productos diferentes tiendas.

Que dos webs apunten a un mismo dominio bajo la versión actual de Plesk no es posible así que deberás de contar con un acceso SSH a tu servidor y un poco de confianza en el manejo de la shell.

La modificación no se puede hacer directamente sobre el archivo que genera plesk dentro de la carpeta vhosts, hablamos de un archivo denominado httpd.include, pues si lo tocas Plesk lo reescribirá con sus propios valores perdiendo cualquier cambio. El concepto es generar otro archivo de modificación que se leerá a posteriori y decirle a plesk que existe ese archivo para finalmente reiniciar el servicio web, es decir el Apache.

En nuestro proyecto, la web real donde se contienen los archivos es mazingerzeta.com y la web satélite que debe apuntar a la misma carpeta es superpc.es

A continuación, los 3 pasos y diversos comandos que necesitarás para modificar el Virtual host.

1. Añadir un archivo vhost.conf en el directorio “conf” del dominio satélite con la siguiente configuración:

ServerName www.superpc.es
DocumentRoot /var/www/vhosts/mazingerzeta.com/httpdocs
#CustomLog /var/www/vhosts/superpc.es/statistics/logs/access_log plesklog
DirectoryIndex index.php
#ErrorLog /var/www/vhosts/superpc.es/statistics/logs/error_log

SSLEngine off


AllowOverride All
Allow from All

php_admin_flag engine on
php_admin_flag safe_mode off
php_admin_value open_basedir none

Options -Includes -ExecCGI

2. Reprogramar Plesk para que lea ese archivo

Este es el comando genérico, depende del directorio de instalación del Plesk y del nombre del dominio:

/plesk_installation_directory/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=dominio.com

En nuestro caso:

/usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=superpc.es

3. Reiniciar Apache

/etc/init.d/httpd restart

Ya está!

Páginas relacionadas con este artículo:

1. Baneando direcciones IPs en Apache bajo Windows
2. Habilitar permalinks en Apache 2
3. Instalar Apache 2 PHP 5 MYSQL 5 y Webmin 1.5

En el panorama actual existen diversas soluciones libres para establecer un buen servidor web, desde el aclamado Cheroke, un web server creado por el español Álvaro López Ortega y que prometo probar en un futuro, al famoso Lighttpd, otro cuyo nombre se las tra, y el nginx, donde me gustaría ver a Paco León, genio y artista, pronunciar semejante nombre como cuando lo intentó con Shreek y cuyo testigo queda en YouTube.

Hemos escogido Nginx pues las comparativas que hemos leído sobre él destroza a cualquier otros servidor web en cuanto al escaso consumo de recursos que precisa, estableciendo un ratio de 1:10 contra por ejemplo Apache, es un servidor ligero, muy ligero y cuya configuración no es en exceso difícil para alguien que se maneje un poco con la línea de comando de Linux, ahora bien, el problema ha llegado al intentar configurar phpMyAdmin bajo él, de todos, todos, los tutoriales que hemos visitado, ninguno ha funcionando, hasta que al final hemos copiado el directorio de la carpeta /usr/share/phpmyadmin a dentro del propio directorio del webserver /var/www una solución temporal, pero que nos va a servir para comprobar el rendimiento del conjunto nginx+php+mysql+phpmyadmin como futuro para nuestros servidores de producción donde correr nuestras aplicaciones web.

Como apunte os diremos que algunas de las mayores webs del mundo, aquellas que tienen un tráfico brutal, funcionan bajo nginx, por ejemplo YouTube, y hace poco también migró de Apache a nginx la española “meneame”.

Ahora, repite conmigo: enllins, einnllinss, enellinks, enjinks y quédate con la que quieras pero quédate.

Páginas relacionadas con este artículo:

1. Alternativa a phpMyAdmin con Ajax
2. Test de carga web
3. Error con LOAD DATA LOCAL INFILE en MySql

La imagen que acompaña este post-nota no tiene mucho que ver con el contenido pues es muy surfera aunque pensándolo bien algo sí, ¿o no?, ¿tú que opinas?

La utilidad básica de cURL es esa leer información de diferentes protocolos, escribo este artículo porque la necesito para una classe bajo PHP que permite  integrar el motor de traducción de idiomas de Google en una de mis aplicaciones web.

Mi configuración actual es Apache2 + PHP5 en un entorno Ubuntu 9.10 Karmic 64 Bits donde si realizo un phpinfo(); no me figura módulo alguno para usar las librerías de php para cURL necesarias para algunas classes php que toman datos de APIs externas.

Además de un módulo para PHP es un comando ejecutable desde línea de comando por ejemplo:

curl www.google.com

Te mostrará en la terminal el código HTML que hay tras esa dirección.

Instalar las librerías cURL para PHP

Os comento el proceso de habilitar cURL en mi versión de Ubuntu.

Lo primero es darte una vuelta por el archivo de configuración de PHP el famoso php.ini , para ello ejecuta en un terminal:

sudo nano /etc/php5/apache2/php.ini

Obviamente si no dispones del editor nano instalado o te es más cómodo el más visual gedit sustituye nano por gedit, eso sí nano es una excelente opción que merece la pena aprender a utilizar pues la podrás utilizar en servidores donde no tengas entorno gráfico, hay seguidores incondicionales de VI pero yo no lo soy en absoluto y prefiero nano.

También ten en cuenta que ese comando puede variar dependiendo de donde se encuentre el php.ini en tu máquina o si la versión de PHP o del Apache difieren.

Una vez dentro busca la cadena “curl” en Nano se hace presionando CTRL + W, si no la encuentras es que cURL no está instalado en tu sistema o en tu servidor, así que toca instalarlo, sal del editor, CTRL + Q y vamos de nuevo a la línea de comando para instalar cURL en Ubuntu:

sudo apt-get install php5-curl

Ahora se bajará los paquetes necesarios y comenzará el proceso de instalación. Una vez finalizado tan sólo te quedará reiniciar el servicio Apache2 con:

sudo /etc/init.d/apache2 restart

¡A programar!

Páginas relacionadas con este artículo:

1. Habilitar permalinks en Apache 2
2. Activar el mod_rewrite en Ubuntu 10.10
3. Instalar Apache 2 PHP 5 MYSQL 5 y Webmin 1.5