El post de Securi provee todos los detalles técnicos de la vulnerabilidad. Pero la conclusión que debemos extraer es como siempre, no confiar en la entrada de datos por parte de un usuario y si es que debemos aceptar un texto. Siempre debemos usar una función que limpie la entrada de texto antes de escribir a la base de datos.

Las siguientes transmisiones estarán basadas en el mismo tema de Cloud Computing, que me parece un tema bastante interesante por el momento y que no ha recibido suficiente covertura en el idioma español. La mayoría de las transmisiones en vivo pretenden ser hands-on (es decir eminentemente prácticas) con sólo el mínimo de teoría necesaria antes de comenzar con la parte práctica. Espero sus comentarios para poder mejorar poco a poco esta iniciativa.

UPDATE: Aquí el video de la conferencia, disculpen la demora en publicarlo:

Espero que pronto estos problemas se resuelvan, por lo pronto a esperar a que estas incompatibilidades sean resueltas y si tienes tu blog en un servidor virtual y usas nginx no actualices hasta que este problema sea resuelto por los desarrolladores de WordPress. Aquellos que se aventuraron a la actualización sin seguir los pasos previos de hacer un back-up de los archivos y la DB, pues la pasaran muy mal ya que es inevitable para volver a poner operativo tu blog hacer un roll back completo a la version 3.2.1.

Bueno, comencemos por el principio, según Technorati el 60% de los bloggers que han respondido a su encuesta afirman hacerlo por diversión, como un hobby, y reportan no recibir ningún ingreso por ello. El tiempo promedio que le dedican a sus blogs es de 3 horas a la semana y su principal "retribución" de dicha actividad es una "satisfacción personal". De este grupo de usuarios la mayoría (60%) responden a los comentarios de sus visitantes.

Los bloggers profesionales, aquellos que tienen está actividad como un trabajo de medio tiempo o tiempo completo, representan el 18%. Un detalle interesante aquí es que este grupo no considera al bloguear como su fuente principal de ingresos, incluso aquellos que están a tiempo completo.

Los blogueros corporativos, aquellos que como parte de su trabajo regular están a cargo de poner contenido en el blog de la compañía, representan un 8% de los que respondieron la encuesta. Para estos bloggers la medida del éxito es el número de visitantes únicos que logran atraer el website de la compañía para la cual trabajan.

Los blogueros empresarios, son aquellos emprendedores que usan los blogs como una manera de conseguir nuevos negocios o comentar ideas, esta clase representó el 13% de los que respondieron la encuesta.

De estas cuatro categorías, hobistas, profesionales, corporativos y empresarios, casi un 60% son hombres, aunque la mayoría está entre los 25 y 44 años de edad, un tercio de los autores de blogs está sobre los 44 años. La mitad de todos ellos vive en Estados Unidos y publica en inglés, toda latinoamérica apenas supera a África y el oriente medio.

Un detalle interesante es que la gran mayoría de los bloggers son casados y la mitad de todos tienen hijos. Este detalle me parece interesante, porque demuestra que al final los que se han quedado en la blogosfera han sido aquellos capaces de llevar a cabo tareas que requieren un compromiso de largo tiempo y cuya recompensa no es inmediata.

Un dato interesante es que para ser blogger se debe tener una relativa estabilidad económica, la gran mayoría de los bloggers trabaja, ya sea para una empresa, son dueños de su propia empresa. Los bloggers que tienen sólo un trabajo a tiempo parcial, los bloggers que trabajan desde casa, los desempleados, los jubilados y los estudiantes son una monoría.

Un cuadro que justifica el título del pesente post es el siguiente, en el podremos ver como la gran mayoría de los bloggers está haciendolo por dos años o más y que los que tienen menos tiempo son una minoría:

Lo que nos indica de que la blogosfera no está creciendo, por el contrario está reduciendose. Una de las razones más evidentes son las redes sociales, como Facebook o Twitter, que no requiren el compromiso de escribir sobre un tema, ni tampoco seleccionar contenido o resumirlo. Aunque no lo dice el reporte en ningún lado, yo creo que una de las razones por las cuales la blogosferá se está achicando cada año se debe al hecho de que el tráfico está en las redes sociales y es alli donde aquellos interesados en hacer dinero rápido están en estos momentos.

En el caso peruano, la blogosfera nunca fue un fenómeno de masas, pero ahora podríamos decir que existe un fenómeno de extinsión masiva. Los medios de comunicación tradicionales han añadido bloggers a sus fuentes de contenido, supongo yo a comisión con la publicidad obtenida, lo cual demuestra que en su mayoría, estos bloggers peruanos no eran auténticos ciudadanos de a pie expresando sus ideas, sino periodistas o profesionales de los medios desempleados queriendo hacerse notar para ser contratados por un medio tradicional.

Para el próximo año veremos una blogósfera más reducida en términos absolutos, con más bloggers profesionales o corporativos (porcentualmente hablando), debido a que la actual crisis económica hará que muchos de los hobistas abandonen sus blogs. ¿Es malo que esto pase?, desde el punto de vista del contenido es bueno porque aquellos que se queden realmente estarán más enfocados en expresar sus ideas produciendo contenido de calidad y no contenido que busque atraer visitantes para hacer dinero con la publicidad (como fue la blogosfera del 2005-2008).

Haciendo una reflexión personal sobre cuanto tiempo tengo este blos, acabo de descubrir que en su actual formato ya tiene más de 4 años (el primer post data de marzo del 2007), pero desde que comenzara con blogger en http://volkan68.blogspot.com/ ya llevo 6 años. Una gran recesión de por medio y aún tengo la suerte de seguir trabajando en una empresa que paga un sueldo justo, que me permite entre otras cosas además de proveer lo necesario para mi familia, el poder dedicar un tiempo a poder expresar mis ideas de manera independiente a través de este medio.

Deseo finalizar el presente post agradeciendo a mis lectores (trolls incluídos), por continuar leales al presente blog por tanto tiempo, lo cual me motiva a seguir produciendo contenido y mejorando la estética/performance del presente blog.

Primero, fue el cambio de LAMP a LEMP que ya comenté en un post anterior. Pero eso solamente mejora la escalabilidad del website, es decir podemos aceptar un gran número de visitas sin requerir más recursos y sin que la experiencia de usuario se vea degradada. La optimización del cacheo con W3 Total Cache es otro paso importante, aunque parezca ilógico los mejores resultados se obtienen cacheando los objetos del site y usando minify al extremo pero NO, ojo NO haciendo cacheo de las queries del MySQL. Al parecer si usamos MyISAM no es buena idea hacer el cacheo de las queries, aunque la razón exacta aún no termino de entenderla, pero luego de medir la performance con y sin cacheo de DB, es mejor no habilitar dicha opción en W3 Total Cache.

Haciendo todas las optimizaciones anteriores pude reducir el tiempo de carga de la página de 6 segundos a 2.4 segundos, lo cual puede parecer una gran mejora (2.5 veces más rápido), pero por alguna razón no me sentía satisfecho, así que comencé a ver por qué la página de inicio demoraba en cargar más de un segundo. Una de las razones era varios plugins que usaba muy poco, es decir los instalé para probarlos y luego nunca más los use. Así que comencé a remover todos aquellos plugin que no eran usados diariamente. Luego de la dieta de plugins, descubrí que mi página cargaba 50 objetos (javascripts, css, imágnes, etc.). Como sabran cada objeto debe ser descargado desde el servidor y debido a que por seguridad hay una restricción a cuantas conexiones se permiten desde un host, este conjunto de 50 objetos se descargaba en varias etapas. En mi caso particular tenía 10 botones "Like" que llamaban igual número de javascripts desde la red de distribución de contenido de Facebook, una mejora obvia fue eliminarlos ya que en cada post individual aparecen.

Bien, con 40 objetos y un tiempo de carga de 1600 ms aún estaba lejos de mi meta. ¿Qué más podía optimizar?, es aquí donde entra en juego el CSS Image Sprite, una técnica que consiste en poner todas las imágenes que se van a utilizar en una sóla imagen png o gif, para luego cortarla usando CSS. Es decir todas esa imágenes de pequeñitas de pocos bytes son consolidadas en una sóla imagen de algunos cuantos KB, pero que tiene la ventaja de reducir el número de objetos que serán descargados desde el servidor y por lo tanto reduce el tiempo de carga total de la página. Es así que con la ayuda del website csssprite.com, cree una sóla imgen con todas las pequeñas imágenes que forman parte de mi theme, esto puso a dieta aún más a mi WordPress que ahora sólo tiene 23 objetos. Finalmente tras esa última optimización el tiempo de carga de la página de incio de este blog es de 980ms en promedio.

Ahora, probado desde NYC la página de inicio de este blog carga 2 veces más rápido que Yahoo, según whichloadfaster.com. Lo cual considero satisfactorio por el momento, aunque estoy muy lejos de los 176ms de Google. La siguiente optimización va a requerir meter mano a algunos plugins y ver si es posible reducir aún más el número de objetos que son transferidos entre el servidor y el navegador. Para aquellos que quieran auditar sus websites hay una herramienta muy útil en Pingdom.com que te permite identificar los cuellos de botella de tu website. Espero pronto tener tiempo para escribir un breve tutorial sobre como usar los CSS Sprite para acelerar la carga de un website.

Durante mucho tiempo la escalabilidad del blog era un problema que me tenía preocupado, siempre temía que por alguna razón un post llegara a ser popular y miles de visitantes saturen el server y lo traingan al piso. Algo que no ha pasado, pero que muchos calificarían como un problema que les gustaría tener. Por ello durante estos últimos años ensayé varias posibles soluciones, evalué moverlo a Blogger (pero era muy limitado, igual en los picos Blogger te limitaba el tráfico), probé con la optimización del Apache, del MySQL, instalé el eAccelerator para compilar-cachear los scripts de PHP, hice pruebas de varios plugins de cacheo para WordPress y finalmente me quedé con W3 Total Cache y lógicamente cada mejora implicaba hacer benchmarking del site con las herramientas que describí en el post "Midiendo la performance de un website". Sin embargo nada de eso parecía resolver el problema de que si más visitantes llegaban era necesario disponer de más RAM y más CPU. Es decir la escalabilidad se conseguía sólo a través de poner más hardware (en el caso de los VPS hacer un pago extra para poder acceder a más recursos). Pero desde el 2009 el nombre Nginx ya era comentado entre la cofradía de sysadmin y muchos ISP lo usaban para hostear websites, pero tenía un pequeño incoveniente, sólo soportaba PHP a través de FastCGI y usar PHP de esta manera requería de spawn-fcgi y lamentablemente existía un problema de confiabilidad (se caía muy frecuentemente).

El problema de spawn-fcgi era tan serio que Andrei Nigmatulin creo PHP-FPM como un parche al código de PHP para permitirle operar de manera confiable sin tener que depender de spawn-fcgi. Lo cual era una solución pero requería parchar el código de PHP, esto era desde mi punto de vista poco confiable porque no tenía la certeza de que el proyecto podría tener larga vida, especialmente luego de que su creador declarara públicamente que no podía darle soporte por más tiempo. Pero desde noviembre del año pasado el código de PHP-FPM pasó a formar parte del core de PHP, con lo cual ya se podía usar de manera confiable en producción porque la continuidad estaba garantizada por la propia continuidad de PHP.

Finalmente animado por todos los buenos comentarios de Nginx y de PHP-FPM, decidí probarlos. Debo decir que no me ha decepcionado, el uso de CPU y RAM fue casi plano independientemente de la carga que se le ponga al server, pero el sólo hecho de reemplazar LAMP con LEMP no mejora la velocidad con la que se muestran las páginas de WordPress. Después de todo tenía mi LAMP optimizado para mi WordPress y lo estaba comparado contra un LEMP de paquete. Así que era necesario nivelar el piso a través de la optimización de LEMP.

La primera y obvia mejora era usar un compilador-cache para PHP, había usado eAccelerator en LAMP y me ha funcionado bien, pero en todas las páginas que encontré todas mencionaban a APC (las dos razones más citadas son que es parte de los repositorios PEAR y que Facebook lo usa), así que decidí seguir a la mayoría e instale APC. La compilación y cacheo de los scripts definitivamente mejoró la velocidad de rederizado de las páginas pero aún se podía optmizar un poco más. Así que instalé memcache (para reducir el número de queries a MySQL) y habilité el soporte de memcache en WordPress, lo cuál le dio un boost adicional a la carga de las páginas.

Pero moviendome de tutorial en tutorial encontré a Varnish, un proxy inverso que hace cacheo de contenido estático, es decir guarda en disco/memoria las páginas generadas dinámicamente por WordPress para no tener que volver a ejecutar un script si la página ya está cacheada y eso fue la cereza sobre el pastel, no solamente las páginas cargaban más rápido sino que el uso de CPU y memoria se fueron al piso. Como resultado reduje la RAM del VPS de 1GB a 512MB con el ahorro que se deriva de ello, pero me he dado cuenta de que incluso con 256MB el VPS va bien. Pero de momento no tomaré riesgos y veré que tal va durante el próximo mes con 512MB, si veo que no hay picos y todo opera normalmente bajaré la memoria a 256MB.

Si deseran hacer lo mismo les recomiendo este howto de CryptkCoding que sintetiza varios otros que he visto en la red y funciona para Ubuntu, aunque con pequeños cambios tambien es útil para Debian. Si es que me doy un tiempo preparé uno en español específicamente para Debian y lo publicaré en la sección de Tutoriales y Howtos.

Como prueba de los increíblemente lineal de la mezcla LEMP + APC + memcache + Varnish, aquí les dejo una gráfica de Load Impact de un stress test a este blog y como el tiempo de carga es independiente del número de clientes conectados concurrentemente:

Aquí el resultado de una prueba con Apache Benchmarking (ab) desde otro server en el mismo switch (10,000 solicitudes con 100 clientes concurrentes), el benchmarking arroja la sorprendente velocidad de casi 3000 solicitudes por segundo:

Lo que siempre me ha preocupado de mi blog y todo lo que escribo en el es que pasaría si por alguna razón de fuerza mayor (enfermedad, muerte o despido) no puedo seguir manteniendolo en mi propio servidor o conservando el nombre de dominio. Entonces se me ha ocurrido comenzar a tener otros lugares que sirvan como fuente alterna en caso de que mi blog principal esté caído, o no pueda ser mantenido. Logicamente esto tiene consecuencias, la primera es que a Google no le gusta el contenido duplicado porque estropea sus índices de búsqueda y tiende a penalizar dichos websites, pero por otro lado ya desde hace buen tiempo la principal fuente de tráfico de mi blog no es Google sino las redes sociales y supongo que con el tiempo esto se convertirá en regla, por lo que en cierto modo tener una presencia en todas las posibles redes sociales ayudará en cierto modo.

Por lo pronto ya he comenzado ha hacer una primera migración a todos estos websites:

http://volkan68.wordpress.com/

http://volkan68.posterous.com/

Pero la idea es ir agregando otros servicios de blogging como tumblr y blogger, aunque aún tengo problemas para poder exportar desde wordpress a dichos servicios, pero espero en el transcurso de los próximos días poder hacerlo. Además no sólo es importante mover lo que ya he escrito, más de mil post a la fecha, sino mantener todo sincronizado para que el contenido siempre esté actualizado en todos los websites, esto último aún no he podido conseguirlo, pero le dedicaré un tiempo para que publicando una sóla vez aquí automáticamente el contendio sea repetido en toda mi red de blogs a través de Internet.

Otro pequeño cambio en el servidor virtual que utilizo ha sido incrementar la RAM de 512MB a 1 GB, espero que esto permita que siga respondiendo de igual modo en caso de que el tráfico al site continúe su tendencia al alza. Pero no puedo negar que estoy muy interesado en cambiar de DB, como todos sabran WordPress actualmente sólo soporta MySQL, aunque hay la posibilidad de usar otros motores de base de datos, pero haciendo un cambio profundo en el CMS que incluye instalar un PDO plugin. La idea que tengo sería usar WordPress con MongoDB como motor de base de datos, al parecer no es algo tan sencillo pero quien sabe con tiempo se pueda hacer.

¿Por qué usar MongoDB?, la primera razón es porque esta base de datos NoSQL está emergiendo como uno de los estándares de facto, la segunda es la noticia que leí ayer en Business Insiders de que Sequoia Capital invertirá 6.5 millones de dólares en 10gen la compañía que está detras del desarrollo de MongoDB. Finalmente, la tercera y última razón es que MongoDB puede ser instalado en un sólo server y luego escalar al tamaño que se desee, con lo que en principio comenzar a utilizar MongoDB debería de ser tan simple como usar cualquier otra instalación de motores de base de datos como MySQL o PostgreSQL, algo que he comprobado cuando instalé a modo de prueba Diaspora.

Como dice el título "cambiemos algo para que todo siga igual".

He probado el plugin y puedo recomendalo funciona muy bien, por ejemplo aquí he incluído un tweet mío para que vean el resultado de usarlo:

[blackbirdpie id=29661531628]

¿Cómo funciona?, muy sencillo sólo es necesario indicar entre brackets que deseamos usar blackbirdpie y señalar el id del tweet que deseamos publicar. Para el ejemplo anterior deberiamos tipear esto:

Al principio creí que era debido a la última migración/actualización que hice de mi server. Si mi memoria no me falla este es el septimo server que hospeda mi blog. Luego de recibir el reporte de @cnieto de que el formulario tenía problemas, hice lo que siempre hago asegurarme de que el exim4 este seteado para hacer relays a dominios externos. Luego de ello pense que el problema se había solucionado, sin embargo para mi sorpresa en un test que hice luego de haber reconfigurado el exim, me di cuenta de que aún no funcionaba.

Luego de leer los logs, encontré este misterioso mensaje:

"ALERT – configured request variable name length limit exceeded – dropped variable"

Con detalles de la IP desde donde me estaba conectando y un increíblemente largo nombre de variable de 204 caracteres de largo. Seamos honestos a que mente retorcida se le puede ocurrir darle 204 caracteres de longitud al nombre de una variable. Al parecer el plugin que estoy usando lo hace, razón por lo cual tuve que editar el archivo "/etc/php5/conf.d/suhosin.ini" y cambiar los valores por defecto de estas dos variables:

;suhosin.post.max_name_length = 64
;suhosin.request.max_varname_length = 64

Por los siguientes:

suhosin.post.max_name_length = 254
suhosin.request.max_varname_length = 254

Luego de reiniciar el Apache, el formulario de "Contactame" ya estaba nuevamente operando como lo hacía en el anterior server. Creo que en Lenny el módulo Suhosin se ha vuelto más paranoico o sencillamente tampoco estaba funcionando en el anterior server que era Lenny también pero estaba en RackspaceCloud, si los chicos del "Fanatical Support", que terminaron desiluncionandome, razón por la cual  volví a hostear nuevamente el servidor virtual de mi blog en el server físico que tengo colocado en el data center de la compañía donde trabajo. Como sea el problema no estaba en el seteo del sistema que estaba racionalmente configurado, sino en las malas prácticas de programación que al parecer algunos desarrolladores de pequeños proyectos Open Source suelen tener. Es por eso que la gran mayoría de proyectos Open Source nunca crecen.

Bueno ya pude desahogar mi enojo, para eso también sirve el blog. Desde ahora ya esta activa nuevamente la página de "Contactame".

Y me vino a la memoria un artículo aparecido en Newsweek a principios de este año, escrito por Lyons titulado "Es tiempo de colgar las pijamas", cuyo subtítulo sintetizaba su experiencia tras haber sido blogger a tiempo completo por dos años, "He aprendido de la forma más difícil que mientras los blogs pueden servir para muchas cosas maravillosas, hacer mucho dinero no es una de ellas". Por experiencia propia como blogger ocacional desde el 2005 y más disciplinadamente desde el 2007, doy fé que lo que no te dará un blog será dinero. Es más en junio del año pasado, en el post titulado "Interesante, pero aburrido" hice una declaración tal vez egoísta con mis lectores pero no por eso falsa, "yo no blogueo por popularidad o dinero, yo blogueo porque quiero, es mi hobby".

Ciertamente aquellos que son bloggers por dinero están abandonando la blogosfera, según Technorati en su informe sobre la blogosfera del 2008, sólo el 5.56% de los blogs que contabiliza se actualizan con una frecuencia menor a los 4 meses. Pero si esas estadísticas son desalentadoras, también lo son las de Twitter que comenté en este mismo blog bajo el título "El espejismo de la web 2.0". Lo cierto es que la mayoría de personas lo que buscan es una forma fácil de hacer dinero, es por eso que funcionan las estáfas tipo pirámide, sino echen una mirada a este "Kit de hacer dinero en Twitter" de TwitterProfitHouse.com, que ofrece ingresos de hasta más de $850 diarios. Lo cuál no deja de ser interesante, ya que los creadores de Twitter hasta ahora no saben como hacer dinero con él.

La misma fiebre del oro ocurrió con la blogosfera a finales del 2006 y principios del 2007, todos corrian a crear sus blogs tratando de llegar a ser ricos o bloguear en el intento (Get rich or blog trying). La gran mayoría simplemente abandonaron sus blogs, los periodístas o comunicadores profesionales que tuvieron cierta aceptación del público, tuvieron que volver a los medios tradicionales para poder recibir un ingreso que les permita vivir, y es que tratar de vivir de los anuncios no es fácil como fue probado por el equipo de NewJerseyNewsroom.com. Y es que según las estadísticas que se manejan, los pocos "blogs" que generan buenos ingresos están formados por equipos de periodistas profesionales, es decir son en realidad periódicos o revistas que publican en la web en lugar de en papel.

Algo que he descubierto experimentando con blogs es que aquellos que tocan temas de humanidades suelen tener mucho más tráfico y desarrollan una audiencia mucho más leal y participativa. Lo cuál no debe de sorprender a nadie, sencillamente las personas odian la ciencia y las matemáticas, algo por lo cual estoy agradecido, de no ser así tendría demasiada competencia al momento de buscar trabajo. Así que si quiere bloguear y que lo lean, hagalo sobre temas relacionados a humanidades y si quiere hacer un blog "informático", en realidad toque temas meramente informativos y generales, si toca algún tema en profundidad no lo leeran.

Por otra lado, una forma de hacer dinero con una web es ciertamente tener tráfico y poner publicidad en ella, eso no es un misterio. Pero hacerlo generando contenido suele ser tedioso, costoso y de pocas recompensas. La mejor forma es hacer dinero es con el trabajo de otros, como lo hemos venido haciendo los seres humanos por milenios, un ejemplo de esto es Google. Google no genera contenido propio, ordena el contenido generado por otros. Blogger, MySpace, Facebook, Twitter, etc., ninguno de esos sites genera contenido por sí mismo, son servicios que millones usan y generan contenido queriendo hacer dinero en el intento.

Siguiendo el ejemplo de los que tienen éxito inicié un proyecto llamado flv2amv.com, que es una herramienta web que convierte videos de YouTube al formato AMV, muy utilizado en los clones de iPod chinos llamados ChiPod. Los resultados han sido más que sorprendentes, sin producir contenido propio, este website que no es más que un mashup del API de YouTube con algunos scripts de shell que corren la herramienta de conversión de formatos en el servidor, tiene unas métricas web envidiables. En primer lugar promedia 100 visitas únicas diarias, tras estar en la web hace sólo 5 meses, con una media de 8 impresiones por visitante, un tiempo promedio en el site de 15 minutos y una lealtad del 50% (es decir de cada 2 visitantes, uno vuelve al menos una vez más al mes) y un porcentaje de rebote de menos del 20%, todo esto según Google Analytics. Por otro lado este blog al cual le dedico varias horas a la semana para producir contenido, apenas exhibe un pobre 1.4 páginas vistas por visitante y el tiempo promedio en el site es apenas superior a un minuto.

Debo admitir sin embargo que tal vez una de las razones por las cuales este blog no es popular, se debe en parte a que no soy una persona muy popular, no se como serlo y tampoco aspiro a serlo. Tal vez una persona más social pueda hacer que su blog sea muy visitado y con ello obtener ingresos por el contenido que produce, esto no creo que ocurra con este blog, eso no significa que lo cerraré, por el contrario planeo conservarlo mientras tenga vida. Pero ya se que debo invertir más de mi tiempo en hacer "herramientas" y no "contenido". Como dice el viejo refran "zapatero a tus zapatos".

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.

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.

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);

# 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"

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

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.

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:

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.