jun 14 2010

Sobre mi participación junto a Oreixa en el FIMP 2010.(Foro Internet Meeting Point). #FIMP

A raíz de una distendida y enriquecedora charla que mantuve con Carlos Urioste (Blog > “Voolive“), gerente de El Comercio Digital y gran conocedor de un medio tan “desconocido a veces por los medios” (tradicionales) como es Internet, me he embarcado de lleno (hasta la piscina diría yo-;) en la tercera edición del Foro Internet Meeting Point, Fimp) que se celebrará en Gijón entre los días 1 y 3 de Julio.

En reunión estuvo también Ana Fernández Ordíz (Blog > “Con Alegría e Ilusión“), ella forma parte del equipo que se encarga de promoción y participación online en El Comercio Digital y se nota cuando la gente hace su trabajo llevando el título de su blog a la práctica “con alegría e ilusión”.

Insistieron en que tenía que estar en el FIMP de este año y a pesar de que les dije que hay gente más preparada que yo para estar en un evento de tal calibre, quise estar a la altura de la confianza que depositaron en mi y acepté encantado, consciente de la responsabilidad que supone.

No hay más que darle un vistazo al plantel de ponentes o participantes de este Fimp 2010 en las diferentes charlas o mesas redondas para darse cuenta de lo que hablo cuando digo “responsabilidad”…Podéis también ponerles cara a algunos de los organizadores y participantes (no pude estar) que vía Twitter lo presentaron.

Carlos me dio libertad total para prepararlo, imagino que buscaba también la experiencia personal de alguien que como yo, se ha tenido que ir buscando la vida para ir canalizando el tráfico que le llegaba a sus webs.

Un incremento de tráfico que tuve que lidiar primero con un Daboweb que, cuando empezamos (año 2002) ya era un foro con bastante tráfico y sobre todo, hablando de incremento de tráfico, la prueba definitiva para mi llegó a partir del 2005 con Caborian que, al mover tantas imágenes y con unas dos millones de páginas vistas al mes, además de muchas consultas a la base de datos, también es un buen “potro” que domar, además de otras webs que ya conocéis.

Por otro lado, los más asiduos al podcast o el blog, ya sabéis de mi relación tan estrecha con los temas relacionados con la seguridad. El eterno aprendiz, así me podría catalogar en un campo tan vivo como este. Al final, después de darte de leches noches y más noches con el sistema (ya lo digo en mi ficha de participante en el FIMP, no he tenido la suerte de poder estudiar nada relacionado con la informática dentro de un aula) te das cuenta de la gran relación con la seguridad que hay entre un sistema bien optimizado y uno que no lo esté.

Corría el año 2005 cuando contraté mi primer servidor dedicado en Interdominios, (a los que les doy las gracias por el apoyo continuado desde que empecé), un Pentium III con 512 mb de Ram y 40 Gb de disco duro que se portó siempre como un campeón, estaba cansado de sufrir caídas del foro dentro del alojamiento compartido en el que estaba y gracias a Raúl Naveiras, gran amigo y mejor sysadmin, programador y un largo etc, comencé a ser mi propio ISP y de paso, a verle las orejas al lobo y darme cuenta de lo poco que sabía acerca de estas temáticas.

Gracias a Raúl, también aprendí a vivir sin esos paneles gráficos como Plesk, Cpanel, DA, etc que tanto te facilitan la vida cuando no sabes pero que a su vez, tanto limitan tus conocimientos sobre el sistema (GNU/Linux en mi caso), además de tomar un protagonismo excesivo sobre el mismo. Ya les dediqué una entrada en el blog a estos sistemas y la falta de una administración adicional en la máquina.

Luego, cuando fui aprendiendo a base de prueba-error, pasé a meterle mano a servidores dedicados más potentes y a administrar otros de terceros. En estos 5 años, he ido pasando por diferentes fases hasta llegar a comprender más o menos como se mueve todo esto.

También a ser consciente de los problemas que se encuentra cualquiera que inicia un blog u otro proyecto web y empiezan a subir sus visitas, y con ello sus problemas a la hora de elegir su plan de alojamiento adecuado, o ser consciente de lo que deberían pedir cuando contraten un nuevo hosting.

No deja de ser menos cierto que el compartir experiencias en nuestros foros de Daboweb, te ayuda hacerte una idea de los problemas de los demás y cómo intentar paliarlos llegado el caso. Y relacionado con todo esto y la charla-demostración práctica del FIMP, pensé que el compañero de viaje ideal para llevarla a buen puerto era Oscar Reixa (Oreixa).

Alguien que de blogs, ahí están todos sus planetas dentro de Galaxia Blog, ( Recién renovados; Reixa, Mac, iOS, iPhone), de tráfico y de cómo buscarse la vida también sabe mucho. El mismo día en que se confirmó mi asistencia al FIMP, me tomé una cerveza con otro que de este medio podría hablar largo y tendido, desde el punto de vista del blogger, formador, usuario o sufridor de los picos de tráfico de su éxito -;). Hablo de mi amigo Juan García, “Kids” de Blogoff, quien por cierto ha escrito una recomendable entrada sobre “Por qué ir al Fimp sin conocer el Fimp“.

Juan me dio algún consejo para la charla, o más bien me contó cómo le gustaría que fuese según su percepción de las cosas o cómo le afectan las cuestiones de optimización y seguridad en el día a día de la publicación y la forma de afrontarlas. Además darme un montón de ánimos para el día 3, como muchos de vosotros -;).

También estos días, hablando con grandes amigos y gente que lleva adelante proyectos con peso y solera en Internet como pueden ser Destroyer y Danae, Forat, AJ, Rafa Espada o Diego, (juntos llevamos adelante DebianHackers) en este caso me refiero a personas que llevan adelante blogs regularmente pero que también administran sus servidores Privados/Dedicados (o co-administramos, ahí estamos ayudándonos unos a otros desde hace años-;), también voy cogiendo ideas (Liamngls, me faltas tú-;).

Pero para no perder la perspectiva, las sugerencias de otros que van “más tranquilos” en La Red como David Busto o Karbonato, nos vienen muy bien para preparar la charla. En este caso hablo de usuarios a los que no les preocupa tanto el sistema, sino el resultado final de la publicación aunque se interesan por el sistema y Karbonato por ejemplo, tiene un VPS bajo Debian.

¿El resultado?, más o menos la descripción que Oscar y yo a modo de resumen, hemos hecho para dar unas pinceladas de lo que compartiremos con el resto de compañeros que asistirán al evento. Tal y como se indica en el programa definitivo del Fimp; También está al completo con los participantes en PDF.

Título;

“Sobrevive a tu tráfico web sin morir o arruinarte en el intento”.

Descripción;

“Soñamos con aumentar el tráfico de nuestros blogs, pero ¿estamos preparados para un incremento súbito en las visitas sin perder el “sueño”? Repasaremos técnicas básicas de guerrilla para tener a punto tu WordPress, optimizar y preparar el servidor web para absorber ese tráfico.

También veremos con ejemplos y demostraciones prácticas, lo complejo que resulta a veces diferenciar entre el tráfico legítimo y el indeseado que llega hacia tu sitio web. Todo ello apoyado con escenarios reales de ataques web de diversos tipos, dando desde nuestra propia experiencia, algunas pautas para paliarlos y una visión global de lo que deberías saber antes de pasar por caja y contratar una nueva máquina”.

Quizás lo más complejo haya sido darle forma a todo o más bien resumir lo más importante. Esa fase ya está superada (más o menos-;) y ahora queda preparar cada uno nuestra parte. Dispondremos de 60 min y lo haremos en dos bloques, estamos controlando ahora mismo el tiempo para cada uno de ellos. En ambos casos, apoyaremos lo comentado con ejemplos realizados en riguroso (esperemos que no falle-;) directo.

Mi compañero de viaje en el Fimp, Oreixa, se centrará en temas relativos a lo importante que es la elección de un hosting y los puntos a tener en cuenta para contratar un nuevo plan de alojamiento, hablará de optimización desde lo más básico en WordPress (usado por la gran mayoría de asistentes a la charla, también dará pautas y herramientas para asegurarlo), hasta temas de más complejidad en el lado del servidor, válido para un VPS o dedicado, (cachés de disco, memoria, PHP, MySQL, etc), monitorización de servicios y el sistema, etc.

Por mi parte me centraré en temas que afectan a la seguridad y en lo complejo que resulta a veces diferenciar el tráfico legítimo del indeseado. También haré alguna demostración práctica de cómo se llevan a cabo ataques de fuerza bruta como los que realizan servidores o hosts troyanizados (típica Botnet) contra protocolos tan delicados como SSH, FTP, etc, ataques DoS bajo peticiones HTTP o Syn.

También se verán ejemplos de cómo un buscador puede tumbarte un servidor, ataques XSS, vulnerabilidades en PHP y otros servicios, seguridad por oscuridad con varios ejemplos y sus correspondientes test de intrusión externos, ver un firewall en acción y algún consejo para usarlos, búsqueda de Rootkits, control de puertos y servicios a la escucha, etc.

A su vez, iremos viendo alguna medida para poder paliar (en parte, ya que la seguridad “total” es una utopía y más en un servidor web). Como todo esto se va realizar usando 4 o 5 servidores reales en producción, sólo espero que no nos fallen las comunicaciones aunque intentaremos tener un plan B o C. Si os pasáis por el Fimp esos días, puede ser un buen punto de encuentro para ponernos cara delante de unas birras -;).

Edito y añado;

Muchas gracias a todos por los ánimos y por vuestras entradas que voy leyendo ;)

Oscar en Planeta Reixa

Fernando en SInLaVeniA

David en Ennegativo

Forat en Forat Dot Info

Diego en DebianHackers.

Caborian Caborians en el FIMP

Además de todos los apoyos que llegan desde Twitter, mails, etc. En “Fimp” que sois la leche ;)

Entradas relacionadas

Tags: , , , , , , , , , , , , , , , ,


mar 19 2009

Amen.es ¿Estás pensando en alojar ahí una web o contratar un servidor dedicado? Server K.O

Category: GNU/Linux,Sin archivar,Webmasterdabo @ 1:17 am

apache_server.jpgBien, para poneros en antecedentes os comentaré que hace tiempo (más de 4 años) ya expresé públicamente lo que pensaba acerca de “cierta política” de recuperación de dominios de amen.es. Por lo que en este caso, llueve sobre mojado.

Para no dispersaros mucho de vuestra multitarea, que sé como es el tema, os lo resumiré lo que más pueda pero prefiero documentar un poco los pasos para que os pongáis escena. Esto le ha sucedido a un colega con un servidor dedicado en el que yo he realizado algunas tareas de administración y optimización, el nombre no viene al caso, quizás alguno sabéis de quien hablo pero lo importante es saber con que empresa trata uno en casos como este.

Está claro que no se puede generalizar y que la gente de Amen no hará todo mal, también sé muy bien que la administración de sistemas no es una tarea fácil y que hay muchos puntos críticos o que sean susceptibles de fallar más que otros pero hablaré de lo que he visto en todo este proceso de la forma más objetiva posible.

Máquina, un servidor dedicado con tiempo ya, un Dual Xeón con mucho trote y descatalogado de la oferta actual de Amen, 150 Gb de disco duro, 2 Gb de Ram y una distribución de Fedora Linux junto a uno de esos imagino “males necesarios” que son los paneles de administración vía web, (tema del que hablé), en este caso Direct Admin.

Esto sucedió un Viernes, me llega un mail de mi colega “Dabo, el servidor ha petado, me dicen que hay muchos errores en el disco los de Amen y que me ponen el servidor en modo recuperación”, ellos lo llaman “Recovery mode” que no es otra cosa que un arranque de la maquina en cuestión vía un Live CD de Ubuntu en este caso (que supongo será una imagen vía red que tendrán preparada).

Más datos sobre el detalle del recovery mode famoso, una salida del comando uname -a (con -r da menos info);

root@wpc:~# uname -a

Linux wpc___.amenworld.com 2.6.24.2-live #1 SMP Tue Apr 22 16:13:55 UTC 2008 i686 GNU/Linux

Para saber la versión exacta del S.O, suelo usar “lsb”, concretamente lsb_release -a (hay otras formas);

root@wpc:~#  lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 8.04
Release:        8.04
Codename:       hardy

Viernes noche / Sábado, bien, a partir de ahí entro vía SSH al servidor en modo “rescate” y veo como efectivamente la salida del comando fsck (usadlo sólo sin estar montadas las unidades) reporta un montón de errores en el disco, había un sistema Raid por software con una forma de petar muy extraña pero eso es otra historia.

Previamente había estado haciendo algunas que otras comprobaciones con la ayuda de mi colega “AJ”, al final después de unos cuantos reinicios en “modo normal” desde el panel web de Amen a ver si arrancaba el sistema y viendo que no había forma de poder ya levantar todo normalmente  y que ni conectaba vía SSH, ya descarté seguir en esa máquina y la prioridad para mi fue recuperar todo el contenido de /home (donde estaban las webs) y de /var/lib/mysql, donde estaban las bases de datos en el momento de petar…

Como sabéis, el comando fsck que tiene varios parámetros para ejecutarse, una vez que hace las comprobaciones de disco, envía los archivos recuperados al directorio “Lost+Found”, había muchos material para recuperar en este caso, una vez finalizadas todas las operaciones en el disco, vía rsync hubo que colocarlos en su lugar original, para después, dejar montada una partición de disco con /home y /var con todo el contenido original con la idea de enviarlo después vía rsync al nuevo servidor…

Esta parte de la recuperación la resumo mucho porque llevó unas 5 o 6 horas recuperando, reiniciando, desmontando y montando unidades, Raids y la madre que le parió al disco duro… (se haría muy largo el post, os lo aseguro).

A todo esto ¿Qué le decía a su cliente o más bien hacía Amen? nada de nada, Viernes tarde y claro, como para ponerse con un “pancho” como este…toma soporte 24 x 7 x 365 (otra cosa como veis de la que ya escribí) y ojo, no cobran mal no, unos 50 eur la hora y no digamos lo que se gastó mi colega llamando a algún número 807…”Lo estamos mirando”.

Para colmo de la mala suerte, el cliente tenía contratado un servicio de backups para las bases de datos hacia otra máquina que falló, el problema es que no es ni mucho menos seguro que funcionen las bases de datos en un caso de “petazo” volviendo a poner las antiguas como estaban en el nuevo servidor, lo digo porque están como si fuera vía una “copia en caliente” o con el comando cp, no con un mysqldump que es lo suyo, pero se puede intentar hacer ese volcado en otro server o localmente y luego revertir el volcado y esperar a que funcione y si no chuta, a intentar reparar vía mysqlcheck o myisamchk las bases pero eso ya es otra historia…

¿Y dónde estaba Amen el Sábado y el Domingo? no sé, fuera de servicio (y de juego…)

Al final, llamaron el Lunes a las 10 am y llegaron a un acuerdo con mi colega para que le cambiaran a otro servidor más potente, un Core2 Duo y le dijeron que se ponían con la instalación del sistema…Le dieron varias opciones, todas con Plesk como panel de administración vía web y le aconsejé lógicamente que le metieran Debian GNU/Linux.

“Nos ponemos con la instalación”

Le llaman otra vez por teléfono;

“Sr cliente, hay un problema con el script de instalación, no podemos instalar Debian pero podemos ofrecerle Ubuntu o Fedora”

Me lo cuenta y yo alucino y le digo que a una mala meta Ubuntu pero que no transija fácilmente y que si tiene que esperar que lo hiciera. Después le llamaron y le dijeron que lo habían solventado…WTF !

Se tiran todo el Lunes out y el sistema sin instalar hasta el Martes, día en el que por fin quedó todo listo. Me manda el password del root, entro y zas !, la primera en la frente, el esquema de particiones brillando por su ausencia o más bien por su escasez…Todo montado en la raíz /. No les da la cabeza para meter en particiones diferentes el home, var (ya no digo /var/log y var/lib/mysql), /tmp o las webs /www pero es algo que no sólo lo hace Amen.

No os cuento nada de la configuracion por defecto del S.O, Apache o mysql…

No os enrollo más porque no acabaría dando detalles y más detalles ¿Cómo acabó la historia?, al final tuve suerte con la recuperación / restauración y más o menos todo está funcionando bajo Debian y Plesk 8 (El Plesk y estos paneles de administración vía web digo que son un “mal necesario” por la cantidad de porquería que meten en el sistema y como se medio apoderan de el, pero algo muy útil para usuarios que no sepan de sistemas) con algún tema que está dando guerra.

Viendo el resultado final, lo mínimo para lo que podía haber sido, todas las bases estan chutando y los 60 gigas de datos replicados al nuevo servidor. Quedan cosas por afinar, servicios por asegurar etc, pero de verdad, desde luego que no será porque Amen se ha molestado por su cliente...

De todos modos, en una ocasión ya opiné sobre los peligro de un servidor web dedicado mal administrado vía Plesk, Cpanel, DirectAdmin o similar sin meterte vía SSH a actualizar-monitorizar-optimizar el sistema. Lo siento por Amen, pero van dos y puede que alguno de vosotros haya pasado por lo mismo e imagino que te puede hacer de todo menos gracia.

Se me olvidaba, ese servidor para mi colega es su medio de trabajo...No se ha ido de Amen porque en Enero firmó un contrato hasta el mismo mes de 2.010. Está bien dar una segunda oportunidad a la gente, ya que como he dicho en el comienzo del post, no todo será malo pero creo que es bueno saber con lo que puedes contar llegado ese momento que por cierto, tarde o temprano, nos puede sobrevenir a todos.

Pero creo que lo peor fue en una situación como esta, no recibir una verdadera opinión – actuación profesional por parte de una empresa que se entiende y de hecho asi es, sabe de todo esto mucho más que yo.

Entradas relacionadas

Tags: , , , , , , , , , ,


sep 05 2007

Servidores web en peligro administrados solamente vía Plesk o cPanel.

attention.gif

/ Edito y añado, Fenixer, empresa de alojamiento web se ha hecho eco de este post y mirad que clarito hablan, da gusto /.

Hace unos días, en otro post contestando a Aj, comenté que iba a hablar sobre el tema. Intentaré ser lo más objetivo posible y lo que aquí os diga, tomadlo únicamente como una opinión personal, fruto del uso de estas soluciones durante un tiempo, para acabar dejándolas de lado.

Quizás alguno piensa que el título o “titular” es un poco alarmista, pero os aseguro que igual me quedo corto viendo lo que se ve por ahí.

La cuestión es simple, imaginad un sitio web que tiene unas necesidades de expansión grandes y decide contratar un servidor dedicado. Dentro de los planes de alojamiento habituales, esta es la opción más potente y cara dicho sea de paso, una máquina enterita para ti, con toda su capacidad y también, con sus problemas…

Por debajo de esta opción, está el llamado “servidor virtual” donde te aseguran (es muy fácil decirlo) un mínimo de memoria RAM o CPU de la máquina que compartes (también acceso por ssh como root, etc, etc).

En una escala inferior, (la más común) se encuentra el típico alojamiento compartido, donde puedes llegar a convivir en el mismo servidor con otros cientos de webs, pero que tampoco necesariamente tiene que funcionar mal si está bien controlado.

Hasta aquí, creo que todos entienden más o menos las diferencias, ahora pasemos a hablar del porqué de mi afirmación de “servidores en peligro”.

En este caso, tengo que pasarle la mayor parte de la responsabilidad a los proveedores de alojamiento, no voy a acusarles de publicidad engañosa pero para ser políticamente correcto (que no lo suelo ser -;), lo dejaré en un “es un cuasi-engaño“.

El cliente, leyendo frases como esta, piensa que es como el nirvana aplicado a la web;

“Podrá usted mantener su sistema actualizado y siempre a punto de un modo totalmente gráfico y sin necesidad de aprender complicados comandos de administración remota”.

Y UNA MIERDA !! con perdón xD. Si alguno se piensa que con una solución tipo Plesk, cPanel, etc, va a administrar un servidor web que dios le pille confesado -;).

Algunos casos de las “bondades” de Plesk los podéis leer (por citar un caso) en Abansys sobre Plesk pero que nadie piense que esto no es algo generalizado, ellos no dicen nada que no digan los demás, sirva como digo únicamente a modo de ejemplo, este que os pongo es de una búsqueda rápida en Google.

Plesk utiliza el estandar en seguridad adoptado por los servidores UNIX (security model). Este modelo ha sido probado en cientos de miles de servidores UNIX de todo el muno y ha demos- trado su altisimo nivel de seguridad. Al mismo tiempo, Plesk ha sido desarrollado para preservar la flexibilidad de los administadores de sistemas UNIX que necesitan un total control sobre sus servidores..

No he visto a un Plesk activar y controlar la caché de MySQL, compilar Apache con un módulo determinado, parchear un Kernel o hacer rular DenyHosts, esto va por lo de “total control“…

Aquí algo de información sobre cPanel que es parecido a Plesk en la gestión y uso de las opciones con las que cuenta.

Vamos a ver, con un software como los que he citado (que hay más), tu puedes; crear cuentas de correo, administrar cuotas de disco, crear usuarios FTP, añadir dominios, reiniciar servicios, hacer backups, instalar algo de software, etc, etc. (Ver Demos al final del post).

Por supuesto nada que no se pueda realizar desde un línea de comandos Unix GNU/Linux. La ventaja del uso de alguna de estas soluciones es que accedes a través de una interfaz web donde, a golpe de ratón y de un modo muy sencillo, controlas varios aspectos del servidor web.

¿Qué es lo que no se dice? lo que no se dice es que puedes administrar PARTES de un servidor web con cPanel o Plesk, pero es imprescindible que además lo hagas del modo “tradicional”, linea de comandos ssh y teclear comandos y más comandos.

Leer el resto de;”Servidores web en peligro administrados solamente vía Plesk o cPanel.”

Entradas relacionadas

Tags: , , , , , , , , ,