Si crees que la formación es cara,
prueba con la ignorancia . . .

Blog de Jaume Ramonet

Hola...

Entre mis actividades hay una que realizo con sumo placer: Hacer de administrador del sistema (alias "SysAdmin") de un servidor dedicado en el que hay alojados unos 30 sites, la mayoría de ellos funcionando, evidentemente, con el CMS DRUPAL. Solo una de las instalaciones he dejado (ERROR !!!) que fuera el propio cliente quien se preocupara de actualizar las versiones de seguridad de DRUPAL. Y ya podéis imaginar lo que ha sucedido...

Como much@s ya sabréis, hacia mediados de octubre se descubrió una vulnerabilidad muy grave que afecta a todas las versiones de DRUPAL 7 anteriores a la 7.31 (incluida). La versión 7.32 solucionaba el problema.

Ni corto ni perezoso, actualicé los sitios bajo mi responsabilidad en menos que canta un gallo ;-) ... pero el sitio del que yo no me preocupaba, pues eso...

El viernes 12 de diciembre a media tarde recibo un e-mail de mi querido proveedor del servidor comunicándome que, por motivos de envío masivo de SPAM desde mi servidor, cerraban el puerto 25 para que no pudiese continuar ensuciando la red :-( (desde mi panel de control yo podía volver a abrir el puerto, pero muy educadamente me pedían que antes solucionara el problema).

Con un site comprometido, la cosa podía ser desde muy grave (servidor comprometido) o solo un problema del sitio concreto... así que empecé a investigar. Pronto descubrí que mi amado servidor estaba de primera, solo que había un montón de procesos lanzados por el servidor de correo Postfix. ¿Quien lanzaba esos procesos?.

Al consultar los usuarios del sitio DRUPAL, encontré los dos "sospechosos" habituales que aparecen cuando un sitio DRUPAL ha sido asaltado aprovechando la vulnerabilidad mencionada -ver imagen- (fácilmente reconocibles por su antigüedad como usuarios del sitio: + de 44 años) y otro usuario "vivienne_newman_125" mucho menos evidente. Suerte que el sitio comprometido solo debería tener 2 usuarios legales. También se habían creado un nuevo rol para asignar permisos...

Arreglar todo esto es fácil. Eliminar los usuarios y sus contenidos, cambiar las palabras de paso de los usuarios legales, revisar el contenido y desactivar el filtro PHP si procede, por descontado. Actualizar a la versión + reciente del núcleo DRUPAL y de los módulos y ... ya está. Como yo uso el absolutamente fabuloso DRUSH ... coser y cantar...

Pero... la cola de emails continuaba creciendo !!! (ver iamgen). El "culpable" era un script PHP llamado

start.php

de solo 64,9 Kb, escondido en uno de los subdirectorios del módulo

fontyourface

.

¿Como lo encontré?... Bien, este artículo me dio la pista...

Se trata de crear y activar un log que nos informe de los scripts PHP que lancen correos: en la tercera imagen se aprecia la actividad del "maligno" ...

Total, una mañanita de un frío sábado de diciembre dedicada a deshacer entuertos. Y, si, finalmente he abierto de nuevo el puerto 25 de mi servidor ;-)

Saludos

Addendum:

SI los permisos de ficheros y directorios hubieran estado correctamente configurados... el maligno no hubiera podido entrar !!!

Propiedad y permisos recomendados para ficheros los ficheros de una instalación DRUPAL en explotación:

  • Usuario propietario de los ficheros y directorios: un usuario del sistema (p.e. "jaime").
  • Grupo propietario de los ficheros y directorios: usuario propietario del proceso del servidor web (p.e. "www-data")
  • Permisos para TODOS los ficheros: "0440"
  • Permisos para los directorios en general: "2550"
  • Permisos para los directorios bajo "files": "2770"

Marzo 2015 - Addendum 2 (tras la pregunta de Oscar):

La verdad es que no solo había un script en el site "infectado"... creo que tuve que borrar no menos de 6 o 7. La mejor forma de localizarlos es mediante el módulo hacked ya mencionado.

Este módulo descubre todos los ficheros añadidos o distintos a los del repositorio del núcleo, los módulos y los temas de DRUPAL, aunque el problema (algún script maligno) también puede estar en las librerías. Por ello lo mejor es verificar que correo sale de nuestra instalación, mandado por algún script PHP. Para ello, como dice el artículo mencionado, hay que activar (quitar el comentario) a dos líneas del fichero "php.ini" de vuestra instalación. Las dos líneas son:

mail.add_x_header = On
mail.log = /var/log/phpmail.log

Tras haber editado el fichero "php.ini" hay que arrancar de nuevo Apache !!!
Y a partir de ese momento, si consultáis el log "/var/log/phpmail.log" podréis ver quien manda e-mails desde PHP... (siempre y cuando tengáis una versión igual o superior a la 5.3).

Espero que ahora haya quedado más claro...

Saludos

Este domingo (19 oct 2014) se ha publicado en el suplemento de Negocios del periódico El País una entrevista con Henry Mitzberg absolutamente IMPRESCINDIBLE de leer para tod@s los que estéis interesados en la gestión...
"Esta es la formación que llevó a George W. Bush a tomar decisiones sobre Irak. Para él, Irak fue un case study"

Os dejo a continuación otra entrevista un poco + antigua (08/08/2008) aparecida en la sección La Contra de La Vanguardia:
"Si a usted le fichan como directivo de una fábrica en Estados Unidos, lo más fácil para usted es despedir a cuantos pueda e ir vendiendo el stock hasta que se acabe."

¿A qué conclusiones llegas tras leer estos artículos? ;-)

A finales de octubre (2014 !!!) imparto un seminario sobre las 7 herramientas básicas para la resolución de problemas en el Colegio de Ingenieros Industriales de Catalunya (EIC). + info en el [ enlace ]

Saludos.

Restos de una cuantas botellitas de muy buen vino Domain RAMONET. Consultad el precio del Gran Cru Montrachet !!! ;-(

Curiosidades del destino, mi mismo apellido, pero no somos familia... Una lástima ;-)

Ficha de mi curso sobre KAIZEN - 5 "S" impartido en los Ingenieros Industriales de Catalunya (en Catalán)

Páginas

Suscribirse a RSS - Blog de Jaume Ramonet