Este post puede considerarse como un acto de promoción dado que soy parte “interesada” o directamente implicada por mi participación en los casos que comento. Ante las (lógicas) posibles dudas, vamos a apelar a aquello de “pásate por ejemplo” por daboweb.com que en breve cumple 10 años y sólo verás un lugar más de ayuda informática, totalmente desinteresado, sin publicidad y hecho por amigos, no colaboradores, amigos, reitero, por y para la comunidad, aprovecho la ocasión para mandar un saludo a mis compañeros de Caborian.

Además, son más cinco años junto a vosotros por aquí en DaboBlog como para que os venga a contar películas en formato TS Screener (recuerda, descarga, pero con calidad).

¿Por qué esta entrada? Y tan tarde…

Bueno, era algo que tenía pendiente, a pesar de que intento conservar cierta actividad en las webs que promuevo o participo, colaborar con el podcast de mi amigo Dani, con el que he grabado unos audios sobre seguridad Wifi y seguridad en dispositivos móviles “para todos los públicos” (por cierto, sobre DaboBlog Podcast, pronto sacaremos un nuevo episodio, o eso espero;), como os decía, es frustrante por ejemplo, abrir Twitter y no poder leeros como me gustaría, no devolver todo el feedback que llega, dejar de publicar aquí con mayor regularidad o en Daboweb, DebianHackers, etc, pero uno da hasta donde da y tiene sus limitaciones. Acabo de ver que mi último post es del día 18 de Enero, día del famoso “Blockout“.

Situación actual.

Actualmente me encuentro inmerso entre una marea de cursos que estoy impartiendo (dentro de las actividades que llevo a cabo desde davidhernandez.es) y otra marea, pero en este caso, con APACHEctl.com junto a mis compañeros. Hablo de mareas de bytes, servidores web, auditorías de seguridad, terminales, intervenciones de urgencia, etc y todos los problemas a los que se puede enfrentar un autónomo en una época como esta, además de un proyecto en común que va gestándose con paso firme y a ritmo suave con Emma Fernández, buscando una diversificación en base a ciertos servicios que demandan algunos clientes.

Servidores y aplicaciones web, usuarios, condicionantes…

Y de mi actividad principal quería hablaros, servidores, seguridad, clientes, SysAdmins y algún ISP que en lugar de “Internet Service Provider“, bien podría ser un acrónimo de “Internet Sopla Pollas“. Sí, de varios hechos que he podido comprobar con mis propios ojos, algunos adelantados en medio de sensaciones entre el cabreo o la falta de comprensión por mi parte y…ciertamente hacen falta más de 140 caracteres para expresarlo. Eso sí, 140 caracteres son pocos, pero aunque tampoco quiero abusar de vuestro limitado tiempo en medio de una multitarea cada vez más acuciante, reconoceréis que a casi un post por mes, tengo que exprimir un poco el teclado ;)

Partamos de la base de que no siempre se puede actualizar como te gustaría o querría el cliente, existen ciertas dependencias entre algunas aplicaciones web, versiones del S.O, entornos de producción que no se pueden parar (de todo esto hablamos Sergio Hernando y yo en el “Especial Seguridad“) y situaciones en las que hay limitaciones tanto técnicas, comerciales o administrativas que impiden un estado ideal de algunos sistemas web en producción. Me tranquiliza en lo personal, saber que en ninguno de estos casos se den esas circunstancias.

Por otro lado, si alguien que trabaje en seguridad o sistemas no entiende que bajo ciertas condiciones, su infraestructura puede ser comprometida, debería pensar en cambiar de trabajo porque cuando viene un cliente buscando que le vendas una utopía, o veo en algún sitio web eso de “garantizamos al 100 % tu seguridad” me quedo alucinado o pienso ¡Qué envidia, si yo pudiera…!

A dos días de terminar de impartir un curso sobre SGSI, LOPD, LSSICE y todas las implicaciones y embrollos legales que se pueden dar cuando manejas datos de terceros, (aprovecho para saludar a esos 14 alumnos con los que tanto aprendo;), cada vez me doy cuenta de que en la solidez de la gestión de la seguridad entran en escena tantos protagonistas (ISP, Webmaster, sofware instalado, usuarios, SysAdmin, etc) que controlar todas esas variables al 100 % es prácticamente imposible, os recomiendo (sobre el factor humano) esta entrada “Por qué falla la seguridad” de los colegas de Security By Default.

¿Por qué? las acciones realizadas por personas a nivel individual influyen en tu trabajo y puedes preveer una actuación en concreto, pero no cambiar ciertas condiciones o costumbres del ser humano. De ahí que sea tan importante un “plan B” y sobre todo hacer que el “plan A” se vaya al carajo para ver cuánto tiempo tardas en poner en marcha ese “plan B” y dar por hecho que puedes encontrarte con el peor de los escenarios posibles.

Si lo ves o planificas de ese modo, no estarás poniéndote vendas en los ojos que acabarán seguramente provocándote una “ceguera operativa” cuando el escenario ideal se convierta en la peor de tus pesadillas, o la de tu cliente, si cuando contacta contigo y está siendo víctima de una fuga de información o ataque a sus sistemas, las cosas no van como debieran. Aún así, sé consciente siempre de tus limitaciones o carencias, e intenta aprender y aprovechar tus puntos fuertes, pero sin dejar de trabajar la parte que menos controlas o te gusta, para conseguir un mayor equilibrio. Créeme, hay gente “ahí fuera” que sabe mucho más de los que están (o estamos) a veces en un plano “mediático” (eventos, reseñas, referencias) en el que se vende mucho humo y prevalecen los conceptos en lugar de las realidades.

De servidores web bajo Debian Etch que jamás se han actualizado.

Con este (sub) título no debería extenderme mucho. Hablamos de una empresa que me contrató para impartir unas clases sobre administración de servidores web bajo GNU/Linux. Dicho cliente (de Asturias) tenía contratado un servidor dedicado con un proveedor local, no daré nombres ya que aún mantiene una relación contractual y no seré yo quien promueva más malas artes por su parte, pero tampoco seré quien recomiende sus servicios, quizás hasta me lean, seguro que se ven “retratados” por lo de MaxClients 40  TimeOut = 300. Sólo diré que son una empresa Asturiana de Hosting (a buen entendedor…).

En el curso, a modo de ejercicio, fuimos creando paso a paso un servidor GLAMP y llegado el momento, se migraron algunos dominios a su máquina, en ese momento es cuando accedí al servidor dedicado contratado con esa empresa. Ya cuando hice un barrido rápido con Nmap lo vi claro pero…cuando haces un uname -a , cat /etc/debian_version o miras el source.list, puedes quedarte K.O.

El que el cliente tuviese una distribución de Debian de hace 5 años que ya no tiene actualizaciones desde finales de 2010 (ojo con Debian Lenny que desde hace unos días ya no recibirá actualizaciones de seguridad !!) puede considerarse bastante fuerte con unas 20 webs en producción. Pero…¿Cómo se queda uno si ve que la salida de tail /var/log/aptitude es = 0? WTF. Si, hay que joderse y “joder” al prójimo, jamás se había actualizado, no daba crédito y tras varias comprobaciones pude ver que era así de crudo y duro. En un primer momento pensé que había un problema con los logs, fue tan fácil como ir tecleando apache2ctl -V, mysql -v, etc, para ver que eran las versiones originales según venían en Debian 4.

Ahora bien, el listillo jamás había metido un update pero ojo, sí que había tenido tiempo para poner en el apache2.conf la directiva “maxclients” en 40. Todo ello con un “bonito” TimeOut de 300 seg, sí amigos, ¿el motivo? piensa mal y acertarás, claro, para ahorrar ancho de banda en su CPD…Limita a 40 conexiones o IPs diferentes en cada máquina y de ese modo, paga menos a su proveedor. Pero hay que ser malo o tener “mala fe” (vi el history y controlar, controlan) para dejar en 300 seg el TimeOut cuando sabes que si hay 40 IPs diferentes conectadas, hasta que se cierre una conexión de Apache que quede inactiva y dé paso a la 41, pasarán la friolera de 300 segundos, luego el cliente, ya se dio cuenta del motivo por el cual a veces le llamaban con eso de “es que me dicen que no se puede entrar a mi web”.

De servers con CentOS, un Cpanel sin actualizar y 3 joomlas crackeados.

Uno de los primeros síntomas por los cuales el cliente se da cuenta de que tiene un problema en su servidor, es en el momento que empiezan a venir e-mails rebotados o marcados como spam y entras en alguna (o varias) de las “blacklists” (o listas negras) habidas y por haber. Esa actividad inusual de envíos de correos desde el localhost, sin estar asociados a ningún dominio, ya es algo que debería mosquearte y luego llega “ese momento” (de la revelación).

El panorama no podía ser peor, una máquina con una versión de CentOS sin actualizar al igual que la versión de Cpanel desde la que se administraba, medidas de protección cuasi-nulas tanto a niveles más bajos del sistema, como protección de ataques de fuerza bruta, picos de tráfico indeseado, escaneos de puertos un tanto “intrusivos”, configuraciones del servidor bajo mi punto de vista inadecuadas para la gran cantidad de webs que alojaba, etc. El cliente pagando por una administración delegada que efectivamente no se estaba realizando, no en este caso a su proveedor de hosting, sino a un tercero. Dicho cliente había sufrido un ataque a varios de los Joomlas instalados (sí, mirad por ahí en las carpetas de imágenes a ver si veis algún .php que no debería estar ahí…), tenía todo un entorno de acceso remoto por una puerta trasera vía web para enviar spam de forma masiva, acceder a las bases de datos, subir ficheros, etc.

Ahh, también un servidor de IRC en la raiz “/”, desde esa máquina se habían realizado ataques de pishing haciendo de pasarela, algo que pudimos comprobar mientras hacíamos el análisis, reportando por mi parte a INTECO CERT la situación de un segundo servidor comprometido (que por cierto, actuaron muy rápido avisando al ISP o dueño del dominio ya que se palió casi al instante). ¿Vaya panorama eh?. Siendo sinceros, el administrador de ese sistema no hizo su trabajo, pero si te dedicas a desarrollar o implementar algún CMS como WordPress o Joomla, lo mínimo que deberías hacer es estar al tanto de las posibles actualizaciones de seguridad que van publicándose, nadie está a salvo de un “0 day”, pero de eso a dejar pasar varias ramas o versiones hay un paso…

De una “gran” empresa de hosting y “rayos por las nubes”.

Este tema fue quizás más extraño, se trataba de un sistema “On Cloud” de estos muy modernos en los que a golpe de click, vas clonando, arrancando máquinas bajo demanda y pensando que todo se soluciona así, a base de “clicks” y monitores o paneles web muy pomposos pero que no se enteran de lo que pasa por su interfaz de red (o sistema de ficheros NFS lento como el sólo…) no hablo de Amazon por cierto.

Por resumirlo, el cliente sufrió un ataque en 3 máquinas virtualizadas sin tener en marcha ninguna web visible, es decir, había unas direcciones IP con un servidor de aplicaciones, otro para MySQL y otro para Apache en pre-producción. Entraron “hasta la cocina” y se enteraron 7 días después. ¿Los motivos o vectores de entrada? bueno, por cuestiones “técnico-económicas” el cliente no quiso realizar una auditoría forense y si mal no recuerdo, pidió un clonado de los discos virtualizados por si en un futuro, viese pertinente hacerla.

Esta “aparentemente” y aparente gran empresa de hosting, una vez acabados los trabajos a realizar por nuestra parte (que en APACHEctl no estoy yo sólo;), después de estar tirando en plan bestia con varios servidores (yo) para probar todas las medidas implementadas (ataques de fuerza bruta, escaneos de puertos de esos que hacen algo de “ruido”, denegación de servicio intentando “floodear” algún puerto o servicio inundándolo de peticiones SYN – TCP,  el cliente pidió los resultados de ese día, y cuando comparó el resultado del sistema de control de logs que le instalamos con lo que pidió a su ISP, era como para darte la risa (por decir algo), “se ha detectado cierto tráfico ICMP“, os aseguro que monté una buena, y ojo, todas las soluciones instaladas por nosotros se basan en Software Libre o herramientas Open Source y su “ultra-mega firewall” por hardware, (imagina el típico “SonicWall de 9.000 €) desde el que se realizaba un NAT hacia las máquinas virtuales, no se enteró de nada…Acabo recordando que el cliente (empresa desarrolladora) se enteró 7 días después, teniendo que dar muchas e incómodas explicaciones al cliente final.

De otro “gran” ISP que cobra por administrar, no lo hace y entorpece.

Y además de no hacerlo, actualizar los sistemas del cliente, cuando ese o esos clientes (dos en una semana) piden acceso SSH, todo son problemas, no vamos a ir al tema legal y la denostada (por mi desde sus inicios) LSSI que dice que “el ISP no es responsable de los contenidos que aloja el cliente siempre que no sea el creador de sus contenidos, pero tiene que actuar con rapidez caso de que queden expuestos datos de terceros o la propia infraestructura web“, vamos a eso de “estoy siendo víctima de un ataque, no doy con ello y como vosotros no sois capaces de pararlo y dar con el vector de entrada, por favor, ceded el paso ya que cada minuto es vital para mi negocio.

Es lo que pasa con ciertas ventas o mejor dicho “fusiones” que queda mejor, es como lo de la Coca Cola de los 80, queda el nombre y algo del gusto de antaño, pero la esencia…se perdió entre tanta “alianza estratégica“. Aquí hablamos de máquinas comprometidas intentando redirigir el tráfico hacia sitios maliciosos (que afortunadamente se paró a tiempo) y clientes que se sientes totalmente impotentes frente a una situación muy dura en la que como he dicho, cada minuto, segundo, cuenta…

Podría seguir comentando algún tema localizado en una auditoría de seguridad que realizamos a unos 30 equipos, redes, servidores, etc, en una empresa hace unos días, pero quizás aún el cliente no ha leído el informe recién enviado y es mejor que lo vea con detalle desde la tranquilidad y no en pinceladas que pueda dejar aquí escritas. Tampoco voy a poner nombres, en muchos de estos casos, se están o bien finiquitando relaciones contractuales o arreglándolas, lo siento pero si me preguntas por algún sitio en el que confiar, pasa al siguiente párrafo…

¿Y ahora qué?

Podrás preguntarte…¿todo el mundo lo hace mal? no, ¿las cosas están feas ahí fuera? sí. No deja de ser toda una paradoja que cuando alguien dice que “mi hosting es genial, etc, etc” lo hacen porque simplemente ven que su web está activa y llegado el caso (no en todos los casos que comento), el servicio de atención al cliente es bueno, contestan en tiempo y forma, etc pero…cuando tienes problemas es el momento de darte cuenta de a quien le estás dando las llaves que abren (o pueden cerrar) las puertas de tu negocio.

No sé si habría que decir a la gente eso de “mira, piensa que un servidor web es como tu ordenador de casa, tiene que estar actualizado, pero también los programas que usas a diario, del mismo modo que tienes un antivirus, bla, bla, bla“. Pero mejor quédate con eso de, actualiza primero todos los CMS que tengas instalados en tu servidor (foros, blogs, etc), realiza o contrata una auditoría de seguridad al menos una vez al año, asegúrate de que efectivamente tu SysAdmin o ISP estén actualizando/administrando esa máquina, haz lo mismo que con los médicos, pide siempre una segunda opinión, (pásate por el “Especial SysAdmin“ con Ricardo Galli) créeme, si estás leyendo esto te confesaré que soy el primero que dudo de mi propio trabajo y entre los miembros de APACHEctl y allegados, no paramos de auditarnos y ponernos a prueba, además de tirarnos de las orejas si nos pillamos en un renuncio. Y ojo, por fiarte, no te fíes ni de nosotros al 100 % si llegas a contratarnos. Sí, somos humanos y como todos, podemos cometer errores por mucho que lo intentemos evitar.

Un abrazo y “tengan cuidado ahí fuera” -;).

Pdta; Según WordPress, son 2.714 palabras, lo sé, ni tanto ni tan poco ¿o era al revés? ;D.

Compartir

Hoy vamos hablar de una herramienta interesante que ya mencioné  hace más de un año en el pasado FIMP. Se trata de “Whatweb”, (acceso a la web del proyecto y su lugar en GitHub). Se trata básicamente de una herramienta capaz de identificar las versiones instaladas de la gran mayoría de CMS (gestores de contenidos) actuales, plugins y una gran variedad de aplicaciones web. También proporciona datos tan relevantes como versiones de Apache, SSL o PHP a través de la información extraída de las “cabeceras” o “banners” que lee cuando realiza una petición al website en cuestión.

"Features" (Según se lee en la web del proyecto):
	* Over 1000 plugins
	* Control the trade off between speed/stealth and reliability
	* Plugins include example URLs
	* Performance tuning. Control how many websites to scan concurrently.
	* Multiple log formats: Brief (greppable)
          XML, JSON, MagicTree, RubyObject, MongoDB, SQL.
	* Proxy support including TOR
	* Custom HTTP headers
	* Basic HTTP authentication
	* Control over webpage redirection
	* Nmap-style IP ranges
	* Fuzzy matching
	* Result certainty awareness
	* Custom plugins defined on the command line

Por lo general, simplemente dentro del directorio desde donde hayamos descargado Whatweb, ejecutamos;

Buscando información con Whatweb y “Server Spy”.

dabo@debian:~/whatweb$ ./whatweb *****web_muy_conocida.com

http://******.com [302]  HTTPServer[Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g], RedirectLocation[/es/], X-Powered-By[PHP/5.2.6-1+lenny13],

Como podéis ver, ese servidor, revela mucha información. Pero no hace falta usar nuestro apreciado Nmap ni otras técnicas más complejas a la hora de recopilar información. Si ponemos como ejemplo Spotify, hubiese bastado con una extensión para Iceweasel / Firefox tan simple como puede ser “Server Spy“.

Si hablamos de la detección de versiones en un gestor de contenidos tan utilizado como WordPress, sobre el que hace unos días escribí una entrada con medidas para mejorar su seguridad, junto a una recopilación de  20 plugins recomendados, vamos al siguiente párrafo…

Como ejemplos bajo WordPress, podríamos ver muchos sites tan visitados (supongo, que no es mi caso;) como la web del “incombustible” Sylvester Stallone (la foto de portada no tiene desperdicio), u otros tan visitados como Mashable funcionan con este CMS . (Aclarar que en muchas ocasiones, simplemente viendo el código fuente, además de la versión de WordPress, también se suelen revelar muchos otros datos de interés).

dabo@debian:~/whatweb$ ./whatweb http://****web_muy_conocida.com/

http://******.com/ [200] X-Powered-By[PleskLin], WordPressSpamFree[2.1.1.1], HTML5, HTTPServer[Apache], WordPress[3.2.1], JQuery, UncommonHeaders[x-pingback], MetaGenerator[WordPress 3.2.1],

Ahí, incluso vemos algún plugin como WordPressSpamFree y su versión, además de la propia de WordPress. Pero en este caso, el servidor está mejor configurado si hablamos de “seguridad por oscuridad” ya que no revela la misma información que el que aloja la web de Spotify, la diferencia es la presencia por ejemplo de Plesk junto a WP.

Con un “simple” curl -i

Pero también, desde la línea de comandos, con una simple petición realizada con “curl“, ya sería suficiente para conseguir mucha información

dabo@debian:~$ curl -i spotify.com

HTTP/1.1 302 Found
Date: Mon, 24 Oct 2011 18:22:33 GMT
Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g
Location: http://www.spotify.com/
Vary: Accept-Encoding
Content-Length: 312
Content-Type: text/html; charset=iso-8859-1

El mismo ejemplo realizado con este blog (también bajo Debian y Apache, no vamos a descubrir/ocultar ahora la pólvora;) con esa petición vía curl, devolvería una mínima información.

dabo@debian:~/$ curl -i daboblog.com

HTTP/1.1 301 Moved Permanently
Date: Mon, 24 Oct 2011 18:25:04 GMT
Server: Apache
X-Pingback: http://www.daboblog.com/xmlrpc.php
Location: http://www.daboblog.com/
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html; charset=UTF-8

Simplemente pone “Apache” y no se proporciona otra información. ¿Cuál es la diferencia?. Básicamente, la forma de evitar este exceso de información y por resumirlo en dos acciones a realizar (que hay mucho más, lógicamente), se trata de modificar lo siguiente.

Cambiando la configuración de Apache.

En la configuración de Apache (en Apache 2 y Debian estaría por defecto en /etc/apache2/apache2.conf)

Cambiamos los siguientes valores; “ServerTokens” por defecto está en “Full”, lo cambiamos a “Prod”. Otra directiva, “ServerSignature” por defecto está en “On”, lo cambiamos a “Off”.

Luego con un /etc/init.d/apache2 reload para que vuelva a “leer” la configuración de Apache sería suficiente ¿o no?.

Realmente no, ya que, a través de otra directiva por defecto que viene en la configuración de PHP, se revela también información acerca de estas cuestiones tal y como se puede comprobar aún con esa directiva cambiada en Apache con otro curl -i.

Cambiando la configuración de PHP.

Para ello, editamos el fichero de configuración de PHP, php.ini (En Debian o Ubuntu sería por lo general en /etc/php/apache2/php.ini). En otras distros al igual que con Apache (o httpd.conf) podéis buscar con un find / -iname php.

El valor “expose_php” por defecto está en “On”, hay que ponerlo en “Off” (no olvidéis hacer un “reload” a Apache para que cargue esta nueva conf de PHP). Esta directiva, además de revelar que está ejecutándose PHP, algo que no es un riesgo para la seguridad realmente, también proporciona información sobre la versión de Apache y en ocasiones del S.O, por lo que tampoco como se ha podido ver, no harían falta herramientas como xprobe o la función “fingerprint” de Nmap para saber que distro o versión de GNU/Linux corre en el servidor.

Como podéis ver, eso de “la seguridad por oscuridad” de oscuro tiene poco, yo diría que “clarifica” las cosas, aunque esto de la seguridad web es un concepto mucho más amplio, donde la “seguridad total” es un mito hablando de estos entornos. Estamos hablando de técnicas simples y nada intrusivas, pero que pueden hacer que nos llevemos algún susto si nos pilla con el pie cambiado alguna actualización, o sale el típico “0 day” (que nos puede pasar a todos). Nos vemos en el capítulo 2 de “/* Sec Tools */”.

Compartir

Ya he hablado antes en DaboBlog de seguridad y WordPress. No hace mucho, publiqué en mi cuenta de Twitter un enlace con el título “Hardening WordPress” (la guía oficial de WordPress para fortificar instalaciones de WordPress). El amigo Jordi Prats de “System Admin”, escribió un artículo “Configuración segura de Apache para WordPress“, con el fin de evitar el listado de plugins frente a una auditoría realizada con nuestro querido Nmap (vía el script http-wp-plugins para nmap)

En el caso de Jordi, fue a raíz de un post muy interesante de Chema Alonso (de “El lado del mal”) en el que realizaba un ataque de este tipo, con algún tip más (por ejemplo el típico error del listado de directorios en Apache y entrar “hasta la cocina”).

Pero tenía pendiente esta entrada sobre este tema y está dedicada especialmente a Dani de “El Arca de la alianza” ya que en alguna ocasión me lo había comentado, y era algo en “pendiente” desde que grabé con él un podcast sobre “Iniciación a la seguridad informática”.(y a ver si retomas la publicación bandido;).

Sobre todo esto se ha escrito por supuesto mucho y muy bien en otros blogs, pero destaco y recomiendo leer los enlaces a las entradas de WordPress.org, Jordi , Chema, Security By Default y Oreixa (con esos seis enlaces ya tenéis una buena hoja de ruta para empezar) ya que me parece que todo puede ser complementario. También citaré alguno útil en el caso de que tengáis el registro de usuarios activado en vuestro blog.

Además de cuestiones como proteger la cuenta de admin (o cambiar el nombre), tener passwords potentes (y cambiarlos), habilitar incluso el acceso por SSL al área de administración (Oscar Reixa habló de ello y publicó una entrada de la parte que tocó de WordPress junto a mi en el FIMP 2010) o una configuración de PHP para que en el caso de que haya algún fallo en la ejecución de una función o un plugin (display errors “off”) para que no revele el “path” o ruta de la instalación de WordPress (un tema publicado no hace mucho en Security By Default, recomendable su lectura). Sobre cuestiones de seguridad, servidores web y Apache (que está todo relacionado), quizás os sirva también de ayuda el resumen de mi participación en el FIMP de Gijón (2010).

# 21 Plugins para dotar a WordPress de más seguridad.

#Actualizado, gracias por vuestras sugerencias ;)

 Vamos a pensar que no todo el mundo tiene acceso vía SSH para controlar su servidor, puede estar en un hosting compartido y creo que sobra decir que si no tenéis vuestra instalación, temas en algún caso y plugins actualizados, de poco servirán muchas de las medidas de prevención comentadas.

Akismet; Todo un clásico, poco hay que hablar de él, salvo que conviene mirar de vez en cuando los comentarios o “trackbacks” ya que no es muy difícil ver “falsos positivos” y más cuando alguien en un comentario alguien mete más de 3 enlaces como se puede configurar en “Ajustes-Comentarios”). Web del plugin

Comment Timeout; Como complemento a Akismet es perfecto. Permite cerrar los comentarios en entradas antiguas, tanto a nivel global, como en cada entrada individualmente. También funciona con los “pingbacks” o “trackbacks”. Web del plugin.

WordPress Backup (BTE); Realizar una copia de seguridad de vuestro tema actual, uploads, imágenes, el tema actual, etc en un directorio (formato .zip) también hay una opción para enviarlo todo por e-mail. Web del plugin.

WordPress Database Backup; Como complemento al anterior, realizar backups de vuestra base de datos (incrementales) y además, tiene la opción de poder enviarlos por e-mail. Web del plugin.

Automatic WordPress Backup; Según nos sugiere e informa en los comentarios Rastreador “Este plugin realiza backups periódicos de tu instalación de WordPress contra un servidor S3 de amazon”. Web del plugin.

WP-DBManager; al igual que si desde vía SSH ejecutáis comandos MySQL como mysqlcheck -o (optimize) – c (check) -r (repair), este plugin hará lo mismo, ayudando a que vuestra base de datos esté siempre a punto. Web del plugin.

Stop Spammer Registrations Plugin; Aquí ya entramos en el tema de los blogs con registro de usuarios habilitado, previene y puede dejar en “cola” de aprobación, a los usuarios con correos o IPs que puedan estar marcados como “spammers” por StopForumSpam.com, Project Honeypot, DNSBL o BotScout. Web del plugin.

Además del comentado “Stop Spammer Registrations”, que ayuda con el Spam y usuarios potencialmente peligrosos puede estar bien usarlo junto a;

Cimy User Extra Fields; Posibilita la opción de reforzar el área de registro del blog, con campos personalizables, sistemas de verificación del registro, puedes ver en una lista de los usuarios pendientes de activar su cuenta, etc (ejemplo en Daboblog con otro parecido, Register Plus Redux). Web del plugin.

Wp Contact Form 7 + Really Simple CAPTCHA; Una buena opción de formulario de contacto junto a la función de Captcha del “Really Simple” para evitar Spam en el envío de correos. Web de WP Contact Form 7 | Web de Really Simple Captcha.

WP Hide Dashboard; También útil para blogs con registro de usuarios, remueve los campos innecesarios del perfil de usuario para que no pueda acceder a otras áreas administrativas. Web del plugin.

Login LockDown; Plugin para prevenir ataques de fuerza bruta contra el usuario / password. Por citar un ejemplo, puedes definir que con 3 intentos fallidos de “login”, se realice un bloqueo contra la IP durante 600 seg. Luego verás una lista de las IPs bloqueadas (pudiendo sacar alguna de esa “lista negra”. Web del plugin.

AskApache Password Protect; Un gran plugin que no estaba añadido, permite autenticación “HTTP Basic” o una más segura “HTTP Digest Authentication”. Te puede ayudar a bloquear Spam y conservar recursos de CPU, memoria, base de datos, etc. Puedes elegir un usuario y password para proteger además del login, directorios como wp-admin, wp-includes, wp-content, plugins, etc. Web del plugin.

Exploit Scanner; Puede ser útil en el caso de que vuestra instalación haya sido comprometida, para buscar en la base de datos, o ficheros, rastros de y huellas de un ataque (también busca en el CSS, HTML, etc). Ojo a los 128 mb de memoria. Web del plugin.

Secure WordPress; Múltiples funciones como pueden ser; remover la versión de WordPress, crear un archivo “index.php” en /themes o /plugins para evitar el listado de directorios, proteger vuestro WordPress contra peticiones de URL maliciosas, evitar que tanto WP a nivel de Core o sus plugins no se actualice salvo por administradores, remover de wp_head opciones como “Windows Live Writer” o “”Really Simple Discovery”" o remover informaciones de error en el login. Web del plugin.

Block Bad Queries (BBQ); Ayuda como el anterior a proteger WordPress de peticiones de webs o IPs maliciosas, realiza un chequeo de cadenas excesivamente largas (por ej mayores de 255 caracteres) , también controla peticiones URI / “Base 64″, etc. Web del plugin

WP-Sentinel; Además de un sistema de bloqueo de IP, alertas al usuario en caso de ataque, etc, protege la instalación de algunos ataques tan comunes como; “Cross Site Scriptings, HTML Injections, Remote File Inclusions, Local File Inclusions, SQL Injections, Cross Site Request Forgery, Login bruteforcing, Flooding“. Web del plugin.

WP Security Scan; Realiza un chequeo de tu WordPress buscando posibles vulnerabilidades y sugiere acciones correctivas en campos como; passwords, permisos de ficheros, seguridad de tu base de datos, oculta la versión de WP, protección para la zona de administración y remueve la etiqueta ” WP Generator META” del “core” de WP. Web del plugin.

AntiVirus for WordPress; Su función es realizar búsquedas diarias con reportes vía mail de en vuestro WP por si hay algún script o llamada maliciosa, protege de ciertos exploits e inyecciones de spam. Otra protección contra el malware en vuestro blog. Web del plugin.

Mutex; (tal y como publican en Security By Default) “Es un plugin para WordPress que incorpora PhpIds y además, lo integra perfectamente en WordPress permitiendo su administración desde el panel de gestión”. Web del plugin.

Además de todo esto, os recomiendo dar un vistazo a esta entrada del mes pasado en DaboBlog sobre “Web Site Defender“, un servicio muy interesante para controlar instalaciones de WordPress. Y recordad borrar el readme.html que da la versión !

Espero que os sea de utilidad, partiendo de la base que siempre se podrán encontrar brechas de seguridad en un sistema remoto y, que ese concepto de la “seguridad total” es sólo eso, un concepto, estas acciones os ayudarán a estar “un poco más tranquilos”, saludos ;).

Compartir

#Disclaimer; Esta entrada debe ser considerada como un post o reflexión seguramente paranoide y bajo ese aviso (cuidando la salud mental de quienes tenéis a bien seguirme;) debe ser leída.

#Actualización, me han llamado hoy 27 de Septiembre desde Google (Irlanda) para aclararme el caso, concretamente la persona que añadió nuestras cuentas (Cristian) dándome una explicación. Lo pongo en los comentarios del post.

El título quizás es algo “novelesco”, también buscando quitarle trascendencia a algo que puede ser (como seguramente es) fruto de la casualidad, o para dejar la pregunta final a vuestro criterio. Para responder a esa pregunta; ¿Casualidad, causalidad o inseguridad? os pondré en antecedentes.

Mi colega Salva, mejor “Xsas” para los habituales del blog, y yo (a quien le comenté que quizás escribiría algo sobre el tema entre risas y sensación de “uhmm” -;), nos cruzamos un par de correos hablando de cómo hacer un backup de la cuenta de un cliente con su correo y otros datos funcionando bajo Google Apps (servicio proporcionado por Google).

Aclaro que no hubo conversación previa vía Twitter del tema, sólo por correos electrónicos, en ambos casos cuentas de Gmail / Google Apps lo que viene a ser lo mismo. El detalle de que ni en público ni en privado, comentamos nada en Twitter, tiene su peso para la sensación de “conspi-paranoia” que sufrimos en ese momento ;D.

Bien, hasta ahí todo normal, nuestra “extrañeza” llego cuando pasada más o menos una hora del último envío de correo, nos llegó un aviso casi a la vez, de que la cuenta oficial de Google Apps España nos estaba siguiendo en Twitter…Si os fijáis en la lista de a quien siguen, tal y como se ve en la captura de pantalla, efectivamente están las dos seguidas, primero la mía y luego, la cuenta de Quadux que es de Salva.

Cuando recibimos el aviso de Twitter, casi a la vez, vía mail nos cruzamos un “hostia” ¡Qué casualidad ! y ciertamente aquí puede haber opiniones para todos los gustos, ahí quedan 3 de las muchas opciones posibles.

Como dato adicional, he de decir que hace cerca de un mes escribí en Twitter algo así como “no uses como cuenta de admin tu cuenta personal en Google Apps” (para que, en el caso de un acceso no autorizado, puedas recuperar tu cuenta “normal”, aconsejaba hacer otra con un nombre “enrevesado” y administrar Google Apps desde esa). Puse como “hashtag“ (#) GoogleApps.

¿Casualidad?

Una mera casualidad, el súper algoritmo “Panda” de Google o los responsables de la cuenta de Google Apps España van buscando temas sobre administración de sistemas, la gestión de cuentas de Google, “hastags” o menciones que contengan “GoogleApps”, etc y encuentran lo que escribí en Twitter sobre Google Apps, “ven” la relación entre la cuenta de Salva y la mía y nos siguen a ambos. Sería lo normal pero ¡ qué casualidad ! que sea después de los mails. Aunque de eso van las casualidades ¿no?

¿Causalidad?

Causa-efecto. En los dos mails que nos enviamos, Salva y yo estábamos usando cuentas de Gmail / Google Apps, como dentro de los mensajes se hacía mención a Google Apps, su súper algoritmo (modo <conspi-paranoide> ON ;) rastrea las palabras, el mensaje viaja por Matrix y llega a “su sitio” en Google, acto seguido, (en una hora) nos sigue su cuenta de Google Apps España en Twitter. Sería algo muy factible en lo técnico a la par que más que censurable en cuanto a la privacidad.

¿Inseguridad?

 Este último punto vendría a colación si la respuesta fuese “causalidad“. Muchas veces, comentamos la gran cantidad de datos que maneja Google sobre todos nosotros (y muchas otras empresas) así como de los usos que hacen de datos “cruzados” las compañías. Bien para ofrecernos algún servicio determinado, saber nuestras preferencias de navegación, lugares visitados, etc (aquí se podría hablar de las cookies). Aunque no es menos cierto, que el administrador de tu correo, también puede leerlo sin llamarse Google…

Os comento que esta entrada ha estado como “borrador” durante unos días, esperando a que pasase un poco el tiempo para intentar quitarle trascendencia, sólo con el título escrito y con todos los papeles de no pasar de “borrador”. Pero también que, aún con las risas que nos echamos Salva y yo respecto a lo sucedido, uno se queda con “la mosca detrás de la oreja” como se suele decir. Si me preguntáis sobre mi respuesta, diría que claramente se trata de una casualidad, pero en este negocio de “los unos y ceros“, hay artistas (del código-;) que pueden convertir las “casualidades” en inquietantes “realidades” (y viceversa).

Compartir

A lo largo de estos años, he podido comprobar que el cansancio, las preocupaciones externas y esa mitificada (pero ciertamente real) falta de sueño que suele acompañar a desarrolladores, administradores de sistemas o alguien que lleva adelante un proyecto web, son factores que afectan a nuestro rendimiento y se multiplican exponencialmente en situaciones “críticas”. No digamos si a eso le sumas que puedas estar enfermo o tomando alguna medicación que merme tus facultades.

No voy a hacer un pseudo estudio barato de psicología, pero la experiencia me dice que hay veces en las que por mucho que queramos avanzar, nuestra mente está perezosa y por mucha cafeína que te metas en vena, salvo algún “pico” de lucidez, es mejor hacer un “suspend to RAM“ al equipo y a tu cabeza, para pasado un tiempo, volver a ello con más fuerza y seguridad.

En mi caso, dentro los trabajos que realizo administrando servidores web, bien sea en tareas de mantenimiento o actualizaciones del sistema, como en cuestiones de seguridad que a diario debo afrontar dentro de APACHEctl (Implementación de un IDS, Firewall, auditorías, tests de intrusión, análisis de logs, etc) me encuentro a veces con esas situaciones un tanto “críticas” que comentaba en las que hay terceros que pueden verse afectados por un fallo y nadie está libre de ello. Lo importante es intentar evitarlo a toda costa y si nos sobreviene, tener un buen “plan B” para aplicarlo con rapidez.

Hay algo muy bueno cuando estás trabajando con una línea de comandos, la falta de una capa gráfica que puede abstraerte de tu verdadero fin ayuda a concentrarse, también que si fallas, lo puedes ver al momento. No he visto a muchos terminales equivocándose. Tampoco soy la persona más indicada para dar consejos a nadie, pero quizás encuentras algo aplicable a tu forma de trabajar en estas líneas.

# Algún consejo…

- Hazle caso a la “DGT”, cada dos o tres horas para, date una vuelta aunque sea por casa o la oficina, ten una botella de agua a mano y carga algo menos el café. No hace mucho leí esta entrada en MV sobre cómo hacer ejercicio frente al ordenador, si te pasas muchas horas frente a él, no te vendrá nada mal.

- Intenta ajustar el brillo de la pantalla al mínimo posible dentro de un umbral aceptable para tu vista, luego, si ves que va haciendo falta ya lo irás subiendo. Tus pupilas te lo agradecerán, también si evitas (aquí cada uno tiene sus manías) los colores muy “chillones” en tu consola, mejor que mejor.

- Si puedes hacer ese trabajo que se atasca por la mañana mejor, a no ser que sea imprescindible y tengas que trabajar de noche por no alterar el funcionamiento habitual de los proyectos de tus clientes (webs en producción, correo electrónico, etc).

- En el caso de que te toque una “noche de fiesta” pero no en la barra de un bareto ;D, procura dormir algo por la tarde, yo no soy de los que se echan una siesta habitualmente, pero con media o una hora de descanso, a veces “ganas” tres por la noche…(ojo que también te va a servir para las de “birra y barra”;).

- Procura evitar todo aquello que haga que pierdas la concentración, desactiva las notificaciones o ventanas emergentes del Twitter o Facebook de turno, cierra o ponte “off-line” en tu programa de mensajería instantánea y ojo a la TV o música que estás escuchando. Lo de la música, aquí también todos tenemos nuestras manías, pero está demostrado que el tipo de música que escuchas, influye tanto en tu estado de ánimo, como a veces, en la toma de decisiones a corto plazo

- Si hablamos de una consola GNU/Linux (aunque también se puede aplicar a Mac OS X o Windows), cuando estés haciendo tareas delicadas, procura no usar comandos del tipo “rm” o “mv” sin que el sistema te pida confirmación, dale un vistazo en tu /home o la de tu usuario en el servidor a ficheros como “.bashrc” o “.bash_profile” y quita el comentario a las líneas donde está definido o en su defecto añádelo.

- Pierdes menos tiempo en hacer una copia de seguridad de los ficheros a modificar que en resolver un entuerto que te puedes encontrar a la mínima. Eso sí, acuérdate después de borrarlos y que no queden expuestos en directorios públicos.

- Con las bases de datos otro tanto igual con alguna recomendación aparte, en algún caso es posible que yendo a /var/lib/mysql y haciendo un “hot copy” o “copia en caliente” de la base de datos (por ejemplo con un cp -prfv) cuando lo quieras restaurar te funcione, en otros casos no, por eso es mucho más seguro usar comandos de MySQL como puede ser un; mysqldump –opt -Q -u usuario -p > base_datos.sql.

- Aunque a veces pueda parecerte un coñazo, procura comentar de la mejor forma posible tanto los cambios en el código que escribes, como en los ficheros de configuración del sistema (una copia de /etc también puede ayudarte en caso de que cometas algún error).

- La comodidad a veces se paga, antes de aplicar en tu sistema o servidor una información que ves en Internet, comprueba que no vaya a ver ningún conflicto con el tuyo, los “copy & paste” y los servers no suelen ser buenos compañeros de viaje, está bien coger referencias pero es mejor que “pierdas” (que lo ganas) algo de tiempo en documentarte que en aplicar a la ligera una configuración.

- Hablando de comodidad o probar de una forma más segura, la virtualización puede ser tu mejor amiga antes de poner algún cambio en producción. Hay que superar ese “es que me da pereza” a configurar un entorno LAMP (GNU/Linux, Apache, MySQL y PHP) de forma local, importar tanto webs como bases de datos, aplicar los cambios y ponerlos en producción, pero créeme, es lo más seguro.

- Ese cansancio o problemas de concentración que puedes sufrir en ciertos momentos, hace que seas menos receptivo o te cueste más comunicarte. Si trabajas con varios departamentos (desarrollo, sistemas, marketing, etc) y tu trabajo depende de ellos o el suyo de ti, procura hacer un esfuerzo y coordina los pasos a seguir de la mejor forma posible, busca apoyo en alguien que esté “más fresco” o puntos de vista alternativos, puedes llegar a sorprenderte (favorablemente).

- Para acabar, y esto es algo que suelo repetir cuando estoy dando algún curso sobre seguridad, sistemas web, WordPress, etc. No intentes ir más allá si verdaderamente no puedes. Eso de ponerte metas y objetivos muy altos está bien a modo de ejercicio de auto-superación, pero no olvides que los objetivos se marcan para cumplirlos. A todos nos abruma el exceso de información existente y los campos que no abarcamos, es preferible, al más puro estilo del “15M”, establecer un “consenso de mínimos” contigo, que entrar en un círculo vicioso donde estéis tú y ese conocimiento que anhelas. Todo acaba llegando y ese ansia, a veces aumenta tu estrés y por ende, el agotamiento físico y mental.

Cierto es que muchas veces tienes que entrar a un sistema y actuar como si fueses un “bombero” a apagar fuegos sin saber de dónde vienen las llamas, eso es inevitable  y hay que contar con ello, pero el mejor consejo es que si estás cansado, no lo hagas, espera, descansa y lo harás mejor, “seguro” -;).

Compartir

Hace unos días, me llegó a través del formulario de contacto de davidhernandez.es (donde aglutino los servicios que ofrezco a nivel profesional) una consulta para asegurar una instalación de un WordPress que contaba con una pasarela de pago segura, registro de usuarios y una tienda virtual integrada en él.

Tipos de alertas y avisos;

Entre otras modificaciones y revisiones que hice, di de alta una cuenta para el cliente en WebsiteDefender y los resultados fueron cuasi-inmediatos en el primer “scan” realizado y que vi en la bandeja de entrada de mi correo electrónico.

Como ejemplo, reproduzco con datos (algunos simulados) de mi blog cuestiones que vi en el del cliente. WebsiteDefender. además de comprobar el estado de tus DNS, tiempo de expiración del dominio, si tu web o IP está incluida en alguna “blacklist” (lista negra) o catalogada como “spammer” (tal y como os comenté hace un tiempo aquí), también revisa si Google considera que eres “portador” de algún tipo de Malware tal y como se puede ver en esta captura de pantalla;

También compara si ha habido cambios en algún directorio, si tienes actualizaciones pendientes de algún plugin o si alguno es vulnerable, como sucedio con este caso que reproduzco/simulo en mi blog con el plugin “Register Plus“, plugin del que ni se sabe nada en la web de sus creadores ni en la sección de plugins de WordPress…Pero si lo tienes como era su caso instalado, ahí está “clavada” la versión 3.5.1 (y por los tiempos estará según veo…).

Aviso que puedes ver en tu tablero de WebsiteDefender;

The WordPress plugin register-plus from your WordPress installation in / is known to be affected by a security vulnerability.

Vulnerability details
Title	WordPress Register Plus Plugin ‘wp-login.php’ Multiple Cross-Site Scripting Vulnerabilities
Version	3.5.1
Description	Register Plus plugin for WordPress is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input. An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks. Register Plus plugin 3.5.1 is vulnerable; other versions may also be affected.

Solution

Update the WordPress plugin to the latest version or contact the vendor for more information about a fix.

Compartir

También está siendo llamado “zen mode” en alusión a este post sobre WP 3.2, (ENG) que llevó la firma de Matt Mullenweg creador de WordPress, allí hacía una especial mención a la escritura sin distracciones en modo “fullscreen” (así se se llama el botón para activarlo).

Es muy sencillo hacerlo y sinceramente, es una de las características que más me está gustando de WordPress 3.2 aunque las distracciones no creo que vengan tanto de la pantalla, sino más bien de Twitter, los RSS y Facebook o Google + (para quienes uséis esas dos redes sociales, no es mi caso ya que no me veo también actualizando perfiles allí, entonces, entre mis trabajos de consultoría, los que llevo a cabo en APACHEctl , el podcast que saldrá por cierto en breve el episodio 29, más la participación en los blogs y comunidades que ves en el sidebar (mis otras webs) apaga y vámonos ;D.

Cómo activar el modo “pantalla completa” en WordPress 3.2

# 1º; Cambias la pestaña dentro del editor gráfico (si lo tienes activado en tu perfil) de modo Visual a HTML.

# 2º Haces click en el botón que ves debajo donde pone “fullscreen” (pantalla completa en Inglés) y el cambio se hará efectivo.

Acto seguido, verás una limpia y bonita pantalla blanca con el título y el texto que estás escribiendo, si acercas el ratón a la zona superior, saldrán los controles para añadir una imagen, insertar un enlace, cambiar la alineación, edición de texto, etc, o salir del modo “pantalla completa” tal y como puedes ver en la captura inferior.

Pincha para ampliar

Por cierto, en la entrada que le dediqué en Daboweb al lanzamiento de esta versión junto a sus novedades y con el poco tiempo que lo había probado, ya dije que notaba una mayor ligereza y rapidez en la carga (se nota más en el panel de admin),

Unas cuantas actualizaciones y post después me reafirmo, se nota el trabajo con el código, gracias y enhorabuena a toda la comunidad que está detrás del desarrollo de WordPress. Ahora a seguir escribiendo, compartiendo y “mucho zen” para todos -;).

Compartir

Este es un post que hacía mucho tiempo tenía ganas de publicar y por falta de tiempo no había podido hacerlo, ayer estuve instalando y actualizando las galerías de un cliente y fui recopilando los pasos a seguir o los problemas que me encontré con el update.

Realmente, hay mucha documentación en la web del proyecto y un foro de ayuda en castellano, pero si seguís estos pasos no tenéis que tener problemas a la hora de pasar a la rama estable 1.5x.

El proceso de actualización viene a ser “el de siempre”, esto es;

Hacéis una copia de seguridad de la base de datos ya que escribe más cambios de los habituales que cuando se hacía la actualización de la rama 1.4x. También de toda la galería.

Dejáis la carpeta “albums” tal y como está (ahí están las fotos subidas, miniaturas, etc). Es decir, cuando subáis los nuevos ficheros no la sustituyáis ojo !.

Dentro de /include está el fichero “config.inc.php“, ahí están los datos de conexión del CMS a la base de datos (como wp-config en WordPress por ej). No lo sustituyáis.

Una vez subidos los nuevos ficheros, si accedéis a vuestra galería os podéis encontrar un con un “bonito/puñetero”; “fatal error”,bien eso se solventa ejecutando vuestrodominio/update.php

(Ahí se escribirán todos los cambios en la base de datos necesarios para que funcione perfectamente la nueva rama de Coppermine). Después borrad install.php y update.php.

Ahora, otras consideraciones y problemas que podéis tener.

Es importante que desde el menú “config” (vuestrodominio/admin.php) vayáis a la opción “Check versions” (http://www.vuestrodominio/versioncheck.php) y ahí comparar las versiones instaladas y ver si falta algo.

Es más que posible que ese “Check versions” os informe que dentro de “albums” falten algunos ficheros (directorio “edit” por ejemplo), subid vía FTP buscando dentro de la nueva versión descargada (por ej 1.5.12) dentro de “albums” el directorio “edit” al directorio “albums” que tenéis subido y que recuerdo, no hay que sustituir en la actualización.

Una vez hecho todo esto, es más que posible que cuando queráis ver una imagen al pinchar en una miniatura, os pida un password para hacerlo. Esto es por la configuración de “grupos” y los permisos para los “visitantes”.

Tenéis que ir a http://www.vuestrositio/groupmgr.php (o hacer click en groups o grupos según el idioma) y ahí en “Guest” (invitados) poner los siguientes permisos para ver las imágenes en “Access level” o “nivel de acceso”;

 

Los temas anteriores (de la rama 1.4x) en principio deberían funcionar (os saldrán mal maquetadas o colocadas las opciones cuando estéis logeados como “admin” a la galería pero los visitantes lo verán bien). De todos modos, en Coppermine dan los consejos y pistas necesarias para que sean compatibles con la rama 1.5x.

Espero que os sea de utilidad y que os ahorre algún dolor de cabeza. No obstante como en cualquier tutorial de este tipo, siempre aconsejo ir a la documentación oficial (ES). Saludos ;).

Compartir

Your WordPress.com account, daboblog is not authorized to view the stats of this blog.

Pues bien, esto no es un tema puntual, se solventa con el plugin “Jetpack” para WordPress que al estilo de las “autorizaciones” en Twitter, (entre otras muchas funcionalidades) hace de “pasarela” entre tu blog alojado fuera de wordpress.com y su sistema de estadísticas.

Una vez lo hayáis instalado, sólo tenéis que darle a “autorizar”. Que disfruten con sus estadísticas amigos -;).

Compartir

Es muy recomendable leer esta entrada de Ricardo sobre cómo migró Menéame hacia Amazon que es un poco la base de dónde viene todo esto.

En esta ocasión, tal y como digo con toda la sinceridad en el audio, se juntan el profesor (Ricardo) y mi “maestro” (Raúl Naveiras). Dos personas muy cercanas a mi y que por diferentes motivos me han marcado mucho en lo personal y profesional e imagino que (además de otros factores) por Raúl, que fue quien me empezó a enseñar algo de sistemas hace años, apachectl.com entre otros proyectos es una realidad…

El blog de Ricardo (@gallir) ; http://gallir.wordpress.com, el blog de Raúl (@rnaveiras) ;  http://raulnaveiras.es. Muchas gracias a ambos por la participación -;).

Especial SysAdmin y Servidores Web, en “Kernel Panic” con Ricardo Galli  y Raúl Naveiras.

Como muchos os daréis cuenta, yo aquí sí que actúo de “mediador”, entre lo que se dice y vosotros, la audiencia. Creo que se entiende todo bastante bien y hemos hecho todos un esfuerzo para que así sea. Si una vez escuchado este audio te surgen dudas, estaremos todos muy al tanto de vuestros comentarios.

Debajo del audio, enlaces a todo lo comentado en el podcast;

DaboBlog Podcast “Especial Amazon EC2 en Kernel Panic”

Ficha completa en ivoox.com del episodio Especial.

Descargar fichero de audio (daboblog-podcast-especial-amazon-ec2-agallir-y_md_575611_1.mp3)

Baja >el audio. (46 MB) Escuchar o descargar. (Navegadores, lectores de feeds o móviles sin Flash)

Suscríbete al canal En: GPodder | iTunes | iGoogle | tu lector de RSS

¿No ves el reproductor integrado vía tu lector de RSS?, entra con tu navegador

Nos volvemos a escuchar en la siguiente entrega del podcast (El 1 de Diciembre de 2010).

En el especial Amazon (duración; 1,47 h)

Amazon EC2

Después de una breve presentación, Ricardo y Raúl nos introducen poco a poco hasta llegar a aspectos más profundos en los servicios “on cloud” (lo que viene siendo “en la nube”) que ofrece Amazon, particularmente centrándonos dentro del podcast en Amazon EC2. (Amazon Elastic Compute Cloud) [...es un servicio web que proporciona capacidad informática con tamaño modificable en la nube. Se ha diseñado con el fin de que la informática web resulte más sencilla a los desarrolladores...]

Más info; Tipos de instancias | Precios de EC2 | FAQs de EC2 | Opciones de compra de instancias EC2 | Instancias reservadas | Detectar instancias | Instancias de Windows.

Amazon S3 y “Cloud Front”

Hablando de su historia, hay que decir que primero empezaron con un sistema de almacenamiento de alta disponibilidad, Amazon S3, con cifrado y bajo coste además de ser contratado “bajo demanda” como es  (Amazon S3), el cual se integra perfectamente con el servicio “Cloud Front“, este servicio está destinado a distribuir según las zonas geográficas los contenidos para mantener una baja  latencia de red, independientemente desde donde te conectes, por ej vídeos o emisiones en streaming.

Más info; FAQs Amazon S3 | Cálculo de precios S3 | Precios de Cloud Front | FAQs de Cloud Front.

> Amazon EBS

A su vez, damos un repaso a servicios como el “EBS” (Elastic Block Store) [...Amazon Elastic Block Store (EBS) proporciona volúmenes de almacenamiento a nivel de bloque diseñados para utilizarlos con las instancias (lo entenderemos mejor como un servidor) de Amazon EC2 ...], hablamos en el audio de las diferentes regiones y zonas, además de  cómo afectan a la latencia de red, y a cuestiones también de índole legal (LODP). Esto,al igual que prácticamente todos los servicios de Amazon, se contratan bajo demanda, pensemos en el “EBS” como discos o volúmenes. Características.

> Amazon RDS

Comentamos la funcionalidad Amazon RDS (Amazon Relational Database Service), destinado a una gestión externa de tu motor de bases de datos (normalmente MySQL aunque ahora han añadido otros motores como puede ser Oracle según comenta Ricardo). Sobre este  servicio en Amazon podemos leer [...Es un servicio web que facilita las tareas de configuración, utilización y escalado de una base de datos relacional en la nube. Proporciona capacidad rentable y de tamaño modificable y, al mismo tiempo, gestiona las tediosas tareas de administración de la base de datos...]

Pensemos hablando del RDS, en el  concepto “Failover” (ENG), esta opción nos da la posibilidad de que en el caso de que nuestra base de datos falle, en tiempo real se levanta automáticamente otra con el último backup a la espera, en definitiva, un sistema de alta disponibilidad, aunque bajo mi punto de vista, con MySQL, “pegándote” un poco con la conf, se puede hacer mucho…

Más info; Características del RDS | Precios | FAQs. |

> Amazon Elastic Load Balancing

Como no podía ser de otro modo, hacemos mención a una funcionalidad que os quitará muchos dolores de cabeza a SysAdmins sin tiempo para invertirlo preparando balanceadores de carga “al uso” y con resultados muy profesionales. Hablamos del “Load Balancer” Aquí es donde entra en escena Elastic Load Balancing [... Distribuye automáticamente el tráfico entrante de las aplicaciones entre varias instancias de Amazon EC2. Le permite conseguir aún más tolerancia a fallos en sus aplicaciones, al proporcionar la capacidad de equilibrio de carga necesaria como respuesta al tráfico entrante de aplicaciones. Elastic Load Balancing detecta instancias en mal estado dentro de un conjunto y redirige automáticamente el tráfico hacia las instancias que se encuentran en buen estado, hasta que se restauran las instancias en mal estado. Los clientes pueden habilitar Elastic Load Balancing en una única zona de disponibilidad o en varias zonas, para obtener un rendimiento de la aplicación más uniforme ...]

> Amazon CloudWatch

> Amazon Auto Scaling

Disponer al igual que un balanceador de carga profesional junto a un sistema de escalado automático en función de la carga, tráfico o peticiones web, es otra de las opciones que podemos encontrar en Amazon. [...Auto Scaling le permite escalar automáticamente la capacidad de Amazon EC2, para aumentarla o reducirla, de acuerdo con las condiciones que defina. Con Auto Scaling, (Sistema de escalado automático) puede asegurarse de que el número de instancias de Amazon EC2 que esté utilizando aumente sin interrupciones durante los picos de demanda, a fin de mantener el rendimiento, y se reduzca automáticamente durante los períodos de calma en la demanda para minimizar los costes. Auto Scaling resulta especialmente adecuado para aquellas aplicaciones que muestran variaciones de uso según la hora, el día o la semana. Auto Scaling está habilitado por Amazon CloudWatch y está a su disposición sin ningún pago aparte de las tarifas de Amazon CloudWatch...]

> Amazon Route 53 (Beta)

> Amazon (SES)

Otro de los servicios comentados (no muy conocido por nosotros la verdad) fue Amazon Simple Email Service (Amazon SES) , según comentan en Amazon; [...Un servicio de envío de correo electrónico masivo y transaccional económico y muy ampliable dirigido a empresas y desarrolladores. Amazon SES elimina la complejidad y los gastos de construcción de·una solución de correo electrónico, o de licencias, instalación y uso de un servicio de correo electrónico de otro proveedor. El servicio se integra con otros servicios de AWS, lo que facilita el envío de aplicaciones alojadas en servicios como Amazon EC2. Con Amazon SES no existe ningún compromiso a largo plazo, ni gasto mínimo ni negociación; las empresas pueden utilizar un plan de precios gratuito y después disfrutar de tarifas económicas en función de la cantidad de correos enviados, además de las tarifas por transferencia de datos...] Esquema de precios | FAQs sobre Amazon SES |

> Nota final

Os recomiendo una vez  más como en el anterior Sysadmin, descargar en PDF estas transparencias –> “Estrategias y bases de datos web“ cortesía de Ricardo , incluyendo además del escalado (vertical y horizontal), otras cuestiones sobre el tema a muy a tener en cuenta (Teorema CAP y ACID vs BASE, etc). También comentaros que he querido hacer un resumen de lo comentado pero que estaremos encantados de responder vuestros comentarios sobre lo hablado.

Muchas gracias de nuevo a Ricardo y Raúl pero también a toda esa gente que estáis detrás de esta comunidad que se ha ido formando junto al podcast -;)

/* Tenéis también todos los episodios del podcast desde el primero en esta nueva sección del blog. */

Compartir