Vaciar cache de mod_pagespeed de google

Una forma rápida de tunear nuestro servidor y ganar algo de velocidad en nuestros sites es usar mod_pagespeed de google que proporciona un sistema de compresión básico de css y js, así como una optimización de gestión en las imágenes, realmente sí se nota y no es complicado de instalar.

Una vez instalado, el problema puede venir al actualizar contenido, ¿ por qué ? por que nuestras hojas de estilos, código javascript o imágenes pueden estar cacheadas y volvernos locos pensando que no hemos hecho los cambios adecuados. Cuando esto sucede verifica que el servidor está actualizado manualmente y vacía la cachés.
¿ como se vacía la caché de mod_pagespeed ? Tenemos que generar una marca así de sencilla :

[code]
touch /var/cache/mod_pagespeed/cache.flush
[/code]

apache2 mod_ssl poodle atack fix

El año pasado me alegré un poco de no trabajar como adminstrador de sistemas, el continuo escándolo de fallos gordos de seguridad, me hubiera subido la tensión aún más 😀

Uno de los fallos de seguridad fué el llamado ‘POODLE‘ destapado por gente Google, del que llevaban conociendo us existencia bastante tiempo; en resumen permite leer en claro una transmisión de datos que usa ssl con unas ciertas características.

Configurando certificados de Comodo en servidores apache2 de Debian, me he llevado el chasco de que son vulnerables por defecto a POODLE, así que he aquí un copy&paste para solucionarlo en un pis pas.

La solución se basaa en desactivar SSLv3 y listo, todo funciona igual pero nos evitamos ser vulnerables
/etc/apache2/mods-available/ssl.conf
[shell]
SSLProtocol all -SSLv3 -SSLv2
[/shell]

Lo mejor es que esta herramienta de Comodo nos permite chequear y validar si somos vulnerables además de otros tantos chequeos de seguridad:

[raw]
https://sslanalyzer.comodoca.com/?url=www.senin.org
[/raw]

redirige tu dominio a www

Cuando tienes un site un poquito más grande, se suele jugar con los nombres de hosts y puede ser que la ip donde esté tu domino.ltd no tenga el mismo contenido que www.domino.tld para redirigir todo el tráfico a www se puede hacer de una manera muy muy simple usando mod_rewrite en .htaccess

[shell]
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
[/shell]

De esta manera generamos una redirección 301 a www.domino.tld independientemente del nombre de dominio que sea

redirigir HTTP a HTTPS

Receta rápida para redirigir todo el tráfico HTTP a HTTPS usando mod_rewrite de Apache

<ifModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</ifModule>

Fallo grave de seguridad en Plesk mod_php

Nos llega información acerda de una fallo de seguridad en Plesk:

«SECURITY ADVISORY:
Parallels Plesk Panel 9.x, 10.x, 11.x – Privilege Escalation Vulnerability

Parallels Customer,

Please read this message in its entirety and take the recommended actions.

Situation

Parallels Plesk Panel privilege escalation vulnerabilities have been
discovered and are described in VU#310500 and CVE-2013-0132,
CVE-2013-0133 (CVSS score 4.4 –
http://www.kb.cert.org/vuls/id/310500).

Impact

This impacts Parallels Plesk Panel for Linux versions 9.x, 10.x, 11.x.

You are at risk if you have Apache web server running mod_php,
mod_perl, mod_python, etc.

You are NOT at risk if you have Apache web server running Fast CGI
(PHP, perl, python, etc.) or CGI (PHP, perl, python, etc.).

Solution

Parallels has issued security updates for Parallels Plesk Panel
versions 9.x-11.x. The security updates for Parallels Plesk Panel 11.x
and Parallels Plesk Panel 10.4.4 will automatically appear inside your
Parallels Plesk Panel control panel – please apply them as soon as
possible.

The security hotfix for Parallels Plesk 9.x is available for download
here: http://kb.parallels.com/115942.

Workaround

Parallels understands that it’s not always practical for immediate
upgrades, so we have provided a solution to fix this vulnerability.
For the immediate solution, customers should read this knowledge base
article for instructions: http://kb.parallels.com/115942.»

Recordamos que para instalar los microupdates de plesk se pueden ejecutar estos comandos :

/usr/local/psa/admin/sbin/autoinstaller --select-release-current --install-component base
/usr/local/psa/admin/sbin/autoinstaller --select-release-current --upgrade-installed-components

cómo instalar eAccelerator para acelerar tu servidor apache

Últimamente tratamos con bastantes tiendas en prestashop y una de las formas de mejorar el rendimiento de las tiendas es usando eaccelerator.
Es muy fácil de instalar si no tenemos el paquete en nuestra distribución, el único inconveniente es que tienes que recompilar cada vez que instales una versión nueva de php.

# instalamos dependencias
apt-get install php5-dev automake autoconf libtool m4

# descargamos y descomprimimos 
wget https://github.com/eaccelerator/eaccelerator/tarball/master -O eaccelerator.tar.gz
tar zxvf eaccelerator.tar.gz

export PHP_PREFIX="/usr"

$PHP_PREFIX/bin/phpize

./configure 
--enable-shared 
--with-php-config=$PHP_PREFIX/bin/php-config

# compilamos
make
# instalamos
make install 

mkdir /tmp/eaccelerator
chmod 0777 /tmp/eaccelerator

En este punto ya tenemos la instalación ahora solo hace falta configurar el módulo, para configurarlo en debian tenemos que editar el fichero

/etc/php5/conf.d/eaccelerator.ini

y agreagmos este contenido

extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

Reiniciamos apache y echamos un vistazo al log de errores para verificar que no falla el módulo.
Podemos encontrarnos con un error como este :

"eAccelerator: Unable to change cache directory /var/cache/eaccelerator permissions"

Es debido a que no hay permisos para crear la estructura de directorios de la caché.
Desde la documentación de eaccelerator, nos instan a configurar la ruta de la caché en /tmp
según vemos en este enlace
https://github.com/eaccelerator/eaccelerator/wiki/InstallFromSource#wiki-Step_4_Creating_cache_directory

redigir hostnames en apache con mod_rewrite

Hay casos ( por ejemplo en Prestashop 1.3 ) que es necesario que la navegación se redirija de hostingaldescubierto.com a www.hostingaldescubierto.com

Una forma fácil de solucionar esto sería agregar al .htaccess las siguientes lineas:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST}   !^www.hostingaldescubierto.com [NC]
RewriteRule ^(.*)$         http://www.hostingaldescubierto.com/$1 [L,R=301]

RewriteCond %{HTTPS} on
RewriteCond %{HTTP_HOST}   !^www.hostingaldescubierto.com [NC]
RewriteRule ^(.*)$         https://www.hostingaldescubierto.com/$1 [L,R=301]

Es importante destacar que %{HTTPS_HOST} NO EXISTE para eso usamos %{HTTPS} que nos indica si se usa el protocolo seguro o no y HTTP_HOST nos indica el nombre de host, ya sea bajo ssl o no.

Bloqueando los ataques más básicos

En las tareas rutinarias de revisión de los logs, podemos encontrar intentos de acceso por fuerza bruta en el servicio de correo, ssh, ftp, y logs en apache de los scanners más comunes buscando por rutas concretas de foros phpbb, mysqladmin, etc…

Una solución muy cómoda y rápida para bloquear los ataques más básicos es fail2ban que revisa los logs en busca de expresiones regulares que definimos para bloquear IPs.

En nuestro caso vamos a bloquear las ips que están generando errores 404 en apache, es decir están itentando consultar páginas que no existen.

Como es habitual tenemos un script de copiar y pegar para instalar fail2ban y agregar nuestra regla :

apt-get --yes install fail2ban

cat > /etc/fail2ban/filter.d/apache-404.conf << EOF
##
## http://www.hostingaldescubierto.com
## stop web scanners
##
## Bassed on : http://blog.barbarycodes.com/2010/10/06/automated-banning-of-script-kiddies-with-fail2ban/
##
##
[Definition]
failregex = (?P<host>[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}) .+ 404 [0-9]+ "
ignoreregex =
EOF

cat >> /etc/fail2ban/jail.conf << EOF
[apache-404]
enabled = true
port = http,https
filter = apache-404
logpath = /var/log/apache2/access.log
bantime = 3600
findtime = 60
maxretry = 5
EOF

/etc/init.d/fail2ban restart

Esperamos que os sirva y que os quite algunos dolores de cabeza 😀

SVN : Error detected while processing /usr/share/vim/vimrc

Otra de subversion :

[shell]
svn: Can’t open file ‘/var/lib/svn/hostingaldescubierto.com/db/txn-current-lock’: Permission denied
[/shell]

Esto es por que no hay permisos para modificar los ficheros, seguramente el propietario es root , pero estamos usando autenticación por apache, así le tenemos que dar permisos a www-data para que pueda commitear .

[shell]
chown -R www-data.www-data /var/lib/svn/hostingaldescubierto.com/
[/shell]

[Plesk] Parallels Plesk Panel 10: Cambiar el puerto apache

Tan sólo llevamos unos minutos revisando documentación y nos encontramos con esta nueva característica: cambiar el puerto de apache:

http://download1.parallels.com/Plesk/PP10/10.0.1/Doc/en-US/online/plesk-apache-configuration-guide/index.htm

La primera impresión al leer la documentación es que Plesk 10 aún está en beta, pero ha sido liberada, y será madurada en las siguiente releases. Hay una característica medianamente aceptable y es que ahora hay unas plantillas para lo servicios que se pueden modificar y desde estas plantillas se generan las configuraciones para los servicios ( lease websrvmng –reconfigure-all ). Esta característica está bien, pero al llegar al apartado de cambiar apache de puerto, podemos leer esto:

To change the number of Apache HTTP port:

Find all occurrences of the string $VAR->server->webserver->httpPort and replace them with the required port number enclosed in quotation marks, for example: "3456">.

To change the number of Apache HTTPS port:

Find all occurrences of the string $VAR->server->webserver->httpsPort and replace them with the required port number enclosed in quotation marks, for example: "4567".

En resumen que hay que reemplazar todas la variables donde se indica el puerto «$VAR->server->webserver->httpPort» por el puerto en el que queremos que escuche Apache. Sería mucho más fácil definir un fichero con constantes y modificarlo directamente en el fichero. Parece un claro indicador de que aún faltan cosas por pulir.