Empresario a los 13 años

Scott CampbellEn un artículo aparecido en TechCrunch del Reino Unido, se cuenta la historia de Scott Campbell, un adolescente escoces de 13 años de edad que ha iniciado una StartUp llamada ScotBlog, que consiste en una red social basada en el conocido programa de blogging WordPress, con un añadido de redes sociales, en dicho website un usuario puede crear un perfil, unirse a un grupo o crear uno nuevo, enviar mensajes privados y agregar amigos a su blog. De acuerdo a Scott tienen usuarios en Glasgow, South Carolina e incluso California. El autor del post Mike Butcher, llamó a la madre del joven Susan Campbell, quien confirmó la veracidad de la historia de Scott, quien por cuenta propia envio las notas de prensa y agregó su recien formada empresa a la base de datos de empresas tecnológicas CrunchBase.

Si un adolescente de 13 años puede iniciar una empresa web 2.0, debemos admitir que las barreras para iniciar una son bien bajas. Por ejemplo la empresa que hostea el website es Servage Hosting, una empresa alemana que ofrece hosting desde $6.45 al mes por 510 GB de almacenamiento y 5010 GB de tráfico. Aunque Scott no tiene un modelo de negocio definido para su empresa, más alla del clásico modelo de anuncios y es su madre quien financia su empresa en este estado inicial, hay que admitir que este adolescente tiene una iniciativa admirable.

Aunque este no es un caso único de empresario web juvenil, ya hace más de un año comenté el casos de Ashley Qualls, quien a los 17 años dirigía una empresa web llamada WhateverLife.com, que basa su operación en distribuir templates para la red social MySpace y obtiene sus ingresos de la publicidad contextual del website. En la empresa creada por Ashley ahora trabaja toda su familia.

Si Ud. esta en el otro lado del espectro, es decir se encuentra por encima de los 60 años y cree que ya todo terminó para Ud., le recomiendo que lea un post aunque es cierto antiguo, no por ello menos inspirador "No hay edad para el éxito", donde se describen empresas web iniciadas por personas ya retiradas o que estaban a punto de retirarce y que se transformaron en una fuente de ingreso adicional para estas personas.

Así que ahora no tiene ningun pretexto para seguir su sueño y convertirce en un empresario web, ya que ni la edad, ni los recursos económicos son una barrera para nadie en la web, sólo se necesita espíritu emprendedor y muchas ganas de hacer que las ideas funcionen.

Hacking en masa a WordPress, ¿Está tu blog en peligro?

En un post aparecido en TechCrunch, escrito por Nik Cubrilovic, se comenta sobre las últimas vulnerabilidades de WordPress, y cómo la popularidad de éste software le ha valido el acedio de cientos de crackers que buscan tomar el control de los blogs que usan WordPress, para lanzar ataques sobre otros o simplemente ser usados como plataforma para lanzar camapañas de spam o phising. Es más ahora se habla de campañas de hacking en masa a blogs que tienen a WordPress como su gestor de contenidos.

Aunque en éste blog he escrito repetidas veces sobre como mejorar la seguridad en WordPress, al parecer post como "Asegurando tu blog" o "Nueva vulnerabilidad en WordPress 2.3.3", no sirvieron de mucho porque igual he detectado que muchos de los blogs que hosteo en mi servidor fueron hackeados, esa fue una de las razones por las que moví mi blog a un server virtual diferente y puse todos los websites que hosteo en otros dos servers virtuales uno con control panel y otro sin control panel.

El mayor de los problemas con los hacking exitosos es que no dejan una huella visible que le permita al dueño del blog darce cuenta del problema, ya que muchas veces las técnicas usadas esconden el código maligno encriptandolo, si desean saber las técnicas más comunes de esconder código en WordPress y una descripción básica de como se producen los ataques recomiendo la lectura del artículo "¿Tú WordPress esta hackeado?", lamentablemente sólo disponible en inglés actualmente, si tengo tiempo (lo cuál sería un milagro), es uno de los artículos que deseo traducir para incluirlos en mi lista de tutoriales y howtos.

El problema con WordPress parece que no sólo es su falta de un mecanismo de actualización automática, como se sugirió en alguno de los comentarios en el post de TechCrunch, porque es posible usar el sistema de distribución automática de parches para infectar como se describe en éste artículo de SuccessForce, donde se hace referencia y se comenta un paper (monografía) escrito por investigadores de las Universidad de Carnegie Mellon, Pittsburgh y UC Berkeley titulado "Posibilidad de generar exploits para sistemas parchados automáticamente: Técnicas e Imprementaciones".

Aunque hay técnicas que permiten proteger el servidor como las descritas por mí en el post "PHP Suhosin excelente patch de seguridad para servidores compartidos", me dí cuenta que cuando se lo aplicaba los servidores que hosteaba los websites que no son míos, éste afectaba el comportamiento de algunas páginas, razón por la cuál tuve que removerlo de dichos servidores y sólo dejarlo activo en el servidor que tiene mis blogs. Y aunque hay productos comerciales que ofrecen soluciones firewall para aplicaciones PHP como "firewallscript", su precio y su dudosa eficacia, al menos para mi, no aportan una solución real al problema de hostear WordPress en servidores compartidos.

A la fecha no hay mejor solución a los problemas de seguridad de WordPress, que tenerlo siempre actualizado a la última versión disponible, lo cuál no es práctico para muchas personas que por alguna razón u otra están atados a una versión particular de WordPress, o aquellos para los que conseguir hacer funcionar su WordPress, fue el equivalente a poner un hombre en la luna.

Finalmente, y no por último menos importante, es que los blogs hackeados no siempre son de personas completamente neófitas o que carecen de formación en TI porque algunos de los blogs que he visto hackeados son de presionales en TI, incluso en el artículo de Cubrilovic, el mismo describe como hackearon uno de sus blogs dos veces, a pesar de que lo había actualizado. Además cuando el hacking es exitoso y consiguen instalar el back door, los atacantes suelen esconder muy bien sus troyanos y se necesita mucho tiempo para detectarlos, eso lo puedo decir por experiencia, pues lo he vivido con un par de blogs de clientes que hostean en mi server.

Al final creo que esta es una razón más para no desalentarme y completar la migracrión de éste blog a Blogger, como lo propuse en un post anterior. Aunque tampoco descarto una solución híbrida de tener los post  y comentarios en Blogger, pero el renderizado de las páginas aún realizado por uno o varios servidor propios.

Optimizando WordPress

Aunque estoy contento con WordPress, me facilita tremendamente la edición de los posts y sus incontables plugins cubren todas las necesidades que podría tener, sin embargo me había dado cuenta que el renderizado de la página era lento, pues una de las características de WordPress es que todas las páginas se crean bajo demanda, ésto es bueno porque el contenido es dinámico pero por otro lado plantea una sobre carga para el servidor, anteriormente pensaba que como mi blog estaba en un servidor que compartía con otros dominios, esa podría ser la razón de la lentitud, pero desde que lo coloque en un server independiente me dí cuenta de que la lentitud no era por la carga sino por la forma como WordPress está diseñado.

Una de las alternativas para solucionar este problema es usar wp-cache, un plugin que efectúa el cacheo de las páginas para no tener que renderizarlas cada vez que el usuario las solicita; pero dado su naturaleza este plugin siempre está muy sujeto a ataques, es por ello que no me animaba a instalarlo. Pero buscando en diversas fuentes encontre otras alternativas que sumadas pueden dar sorprendentes resultados, al menos en mi caso he visto un notable aumento en la velocidad de renderizado de las páginas. Así que aquí un resumen de lo que he hecho.

Este howto que he preparado esta basado en Debian 4 (Etch), y sobre un servidor que tenga al menos 1 GB de memoria RAM, la velocidad del CPU no es tan crítica para nuestro caso como tener suficiente RAM. Con esa configuración su blog en WordPress fácilmente podría lidiar con un millon de visitas diarias.

Primero hay que instalar el módulo php5-memcache y activar el cacheo en memoria en el WordPress en sí mismo. Para instalar php5-memcache utilizamos estos comando como usuario "root":

# apt-get install php5-memcache
# /etc/init.d/apache2 force-reload

Y luego editamos el archivo wp-config.php donde agregaremos la línea:

define(ENABLE_CACHE, true);

Lo anterior habilitará el cacheo de queries por parte del WordPress con lo que la carga sobre el MySQL disminuirá, pero ahora hagamos una optimización más aumentemos la memoria del cache en el mismo MySQL y cambiemos su modo de operar para que no sólo guarde la versión compilada de las queries sino tambien la versión sin compilar, con lo cuál aceleraremos aún más el desempeño, para debemos de editar el archivo /etc/mysql/my.cnf agregando/editando las siguientes líneas:

#
# * Query Cache Configuration
#
query_cache_type        = 1
query_cache_limit       = 2M
query_cache_size        = 32M

Ahora debemos de reiniciar el mysql para que los cambios tomen efecto, para ello usaremos el siguiente comando como usuario "root":

# /etc/init.d/mysql restart

Como PHP debe de interpretarse cada vez que se desea ejecutar un script, si guardamos una copia de los script ya interpretada (bytecode), la ejecución de las instrucciones sera directa y nos ahorraremos en cada rederización de página el tiempo de interpretar todo el script, lo cuál haremos usando eAccelerator. Para instalar eAccelerator debemos de seguir las siguientes instrucciones como usuario "root":

# apt-get install build-essential php5-dev
# cd /tmp
# wget http://bart.eaccelerator.net/source/0.9.5.2/eaccelerator-0.9.5.2.tar.bz2
# tar xvfj eaccelerator-0.9.5.2.tar.bz2
# cd eaccelerator-0.9.5.2
# phpize
# ./configure
# make
# make install

Si llegamos hasta el final sin obtener ningun error en la compilación podremos continuar, caso contrario revisen éste howto que da más detalles sobre el proceso Integrating eAccelerator Into PHP5 (Debian Etch).

Ahora debemos de crear el archivo /etc/php5/conf.d/eaccelerator.ini y poner estas líneas dentro de él:

extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/var/cache/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"

Si copiaron exactamente los mismos valores debemos de crear el directorio /var/cache/eaccelerator y asignarle el usuario del apache como propietario, si uso otro valor aplicar los cambios correspondientes. Entonces procedemos como "root" con los siguientes comandos:

# mkdir -p /var/cache/eaccelerator
# chown www-data:www-data /var/cache/eaccelerator

Ahora para que los cambios tengan efecto y comenzar a utilizar eAccelerator, debemos reiniciar el Apache con éste comando:

# /etc/init.d/apache2 restart

Ahora optimizaremos un poco Apache2, para ello debemos de editar el archivo /etc/apache2/apache2.conf y cambiar/agregar éstas líneas:

<IfModule mpm_prefork_module>
    StartServers          8
    MinSpareServers       5
    MaxSpareServers      20
    ServerLimit         512
    MaxClients          512
    MaxRequestsPerChild 4000
</IfModule>

Para que los cambios tengan efecto debemos de nuevamente reiniciar nuestro Apache con el comando:

# /etc/init.d/apache2 restart

Como toque final debemos de desinstalar todo módulo de PHP que no estemos usando, revise con el comando éste comando qué módulos de PHP tiene instalado:

# dpkg -l | grep php5

Desinstale todo aquello que no éste usando. Luego de que haya terminado de desinstalar los módulos de PHP5 que no éste usando reinicie nuevamente el Apache.

Con los pasos anteriores verá como su WordPress muestra las páginas tan rápido como cualquier otro CMS.

Actualizando a WordPress 2.5

Desde ayer, ha sido la noticia más comentada en la blogosfera, el lanzamiento del WordPress 2.5, así que decidí probar el mismo en un blog (www.puntocix.com), que recien estoy comenzando a dar forma, el miercoles pasado había instalado la version 2.3.3, y apenas tenía un par de artículos en el. Así que si en el peor de los casos el upgrade no funcionaba no había mucho que perder, además aún ese blog no tiene visitantes, así que tampoco sería un problema detenerlo para poder hacer la actualización.

Bueno, el upgrade fue bastante sencillo, todos los themes y plugin fueron reconocidos inmediatamente. Pero los menus del panel de control estan reorganizados. Los que trabajan con el WordPress en español, pueden descargar el archivo del idioma español desde aquí: WordPress 2.5 en Español.

Creo que tendre que acostumbrarme a la nueva distribución de menus, pero no pienso actualizar mis otros blog hasta dentro de un mes, más o menos. Mejor espero la versión 2.5.1, de hecho todo upgrade mayor siempre introduce problemas e inestabilidades, y no deseo tomar riesgos innecesarios en mis otros blogs.

Felicitaciones al equipo de desarrollo de WordPress, por haber hecho éste gran trabajo, el procedimiento de upgrade es bastante sencillo y la compatibilidad con themes y plugins existentes es excelente, ahora ha experimentar con el WordPress 2.5 en mi nuevo blog y ya les contare si es que encuentro algún problema.

Nueva vulnerabilidad en WordPress 2.3.3

He encontrado en el blog Smackdown, un interesante reporte sobre una vulnerabilidad aún no propiamente documentada, y por supuesto aún no parchada en la última versión de WordPress 2.3.3 que permite a un atacante externo crear el directorio /wp-content/1/ el cuál contiene infinidad de enlaces spam.

Aparentemente ya existe un exploit para aprovechar dicha vulnerabilidad ya que según Google, hay actualmente más de 22,000 websites con WordPress infectados. Para verificar el estado de la infección es suficiente con que pongamos ésto en la barra de búsqueda de google:

inurl:wp-content/1/

Con lo cuál le estamos diciendo a Google que busque todos los URL en su DB que contengan el texto wp-content/1/. Incluso vale la pena recalcar que ya google ha marcado muchas de estas páginas como peligrosas.

Luego de que el atacante ha subido páginas web en dicho directorio con infinidad de links a sitios con malware, usualmente suele poner un comentario que hace referencia a dicha página.

Todas aquellas personas que tengan un blog con WordPress, les recomiendo que den un vistazo al directorio wp-content en busca de ese directorio, de tenerlo, remuevanlo y cambien los atributos al directorio wp-content para que el usuario que esta corriendo el servidor web, no tenga privilegios de escritura sobre el mismo. Claro que esto puede afectar a determinados plugins, pero es mejor proceder con cautela hasta que el problema sea resuelto.