Lo que se ha podido constatar ha sido un tremendo aumento de tráfico desde la IP de la máquina, que además ha coincidido en el tiempocon las desconexiones. Pero también se han localizado algunos errores de actualización en VDSmanager y en varios scripts de mantenimiento de la máquina, que seguramente han sido causados por la interrupción de las actualizaciones en los momentos de sobrecarga de tráfico.

Todavía no sabemos si el origen de la sobrecarga es por un ataque externo o por mal funcionamiento del software. Por el momento estamos cargando manualmente las últimas actualizaciones de software y también se revisarán los firewalls de las IPs alojadas en esta máquina.

Se va a realizar una importante tarea de mantenimiento y revisión en esta máquina durante este fin de semana, a fin de localizar exactamente el problema y evitar que se produzcan daños en el hardware o en los datos almacenados a causa de las desconexiones.

11 de agosto de 2009:

En los tres siguientes se produjeron 4 nuevas desconexiones de la máquina, a pesar del trabajo intenso realizado para localizar el problema. Se ha confirmado que no existe ningún problema de hardware, ni de software. Las aplicaciones de medición de tráfico han localizado picos de ancho de banda superior a 10 Mbps/segundo en la máquina afectada, justo antes y durante las desconexiones. Éste es el motivo de la imposibilidad de acceder a la máquina en los momentos citados. El ancho de banda quedó consumido como consecuencia de ataques de denegación de servicio sobre una ip alojada en la máquina, que experimentó incrementos de tráfico veinte veces superiores a su ancho de banda medio.

Se ha realizado una larga tarea de configuración de firewalls y localización de los diferentes orígenes de los ataques (cada vez desde ubicaciones diferentes). En las últimas 48 horas sólo se ha producido un ataque, que fue neutralizado en 20 minutos, y en las últimas 24 horas, no se ha vuelto a detectar ninguna nueva incidencia.

Rogamos disculpen las molestias.

Desde las primeras horas de esta madrugada hemos detectado ciertos problemas de acceso a varias ips de nuestras máquinas. No se trata de un problema general, porque afecta a un volumen reducido de ips (inferior al 5%), y porque sólo sucede desde conexiones adsl de Telefónica.

El problema detectado no supone la imposibilidad de acceder al servicio, pero si está generando timeouts, pérdida de paquetes y fallos temporales de conexión en las ips afectadas.

Dimensis ha abierto una incidencia en Telefónica, pero no tenemos previsión sobre la resolución de la incidencia. Desde Telefónica nos recomiendan que los clientes afectados comuniquen igualmente el problema a Telefónica, para que ellos tengan constancia y revisen cada caso de forma personalizada.

18-05-2009 a las 13:45 horas:

Según nos informa el equipo de atención al cliente de Telefónica se ha localizado una incidencia general a nivel nacional que afecta a la resolución de varios servidores DNS de Telefónica. La previsión de resolución es “a lo largo de la tarde de hoy”.

19-05-2009 a las 06:45 horas:

Persiste el fallo de resolución en los servidores DNS de Telefónica que impide acceder a miles de ips nacionales. A pesar que hace más de 30 horas que se detectó la incidencia, desde Telefónica no dan una estimación exacta para su resolución. Ni siquiera una explicación clara sobre el problema.

El teléfono de contacto para notificar incidencias en el servicio adsl para pymes y autónomos es el 902.357.022

19-05-2009 a las 15:15 horas:

La incidencia sigue sin resolverse y la actuación por parte de telefónica está siendo, como de costumbre, detestable. Dependiendo del número de teléfono al que se llame para comunicar la incidencia, la respuesta más habitual hoy es indicarle al cliente que no existe ningún problema, cómo han tratado de convencernos hoy mismo a las 13:30 horas. Sin embargo, a las 14:45 horas hemos recibido una llamada de Telefónica para comunicarnos que siguen trabajando en la incidencia y que efectivamente existen fallos generales a nivel nacional en el servicio de resolución DNS de la red adsl de Telefónica que impide acceder correctamente a diferentes IPs, sin especificar rangos afectados, motivos de la incidencia o una previsión para su resolución.

19-05-2009 a las 16:45 horas:

Ante la pasividad de Telefónica en resolver sus propias incidencias, nos hemos visto obligados a realizar algunos cambios en ips y enrutamiento interno del tráfico, para tratar de reducir los problemas que están sufriendo una parte de nuestros clientes.

No obstante, aunque nuestra intervención reduzca el problema, la resolución definitiva de la incidencia no se alcanzará hasta que Telefónica solucione sus problemas de software.

20-05-2009 a las 09:45 horas:

Según nos reportan varios usuarios, parece que la incidencia en Telefónica ya está prácticamente resuelta.

Inicialmente se consideró que podía estar relacionado con diversos problemas detectados tras la última actualización del kernel y varias aplicaciones principales, pero la situación ha ido empeorando y los reinicios de la máquina son cada vez más frecuentes. Tras revisar detenidamente todo el software y realizar diferentes pruebas, se ha comprobado que el problema se origina en uno de los discos duros del RAID. También se han detectado algunos errores en la controladora de discos, por lo que nuestros técnicos han decidido hacer una sustitución conjunta de varios componentes del hardware.

En un primer intento se ha reemplazado el disco afectado por otro similar en stock, pero han surgido varios errores en la reconstrucción del RAID y, por precaución, se ha optado por mantener el disco viejo hasta recibir uno nuevo.

Los contenidos de esta máquina están siendo copiados diariamente a una máquina secundaria conectada a través de una segunda tarjeta ethernet, por lo que no hay riesgo de pérdida de información en el caso que el sistema de ficheros llegue a dañarse y obligue también a reemplazar el disco principal.

La previsión de entrega del nuevo disco es de 24-48 horas. Por lo que se ha programado una nueva intervención en ESP05 para hoy jueves o mañana viernes, tan pronto como se tenga disponible todos los componentes del hardware necesarios.

Viernes, 12 de diciembre:

El disco duro defectuoso ha sido reemplazado a las 12:00 horas. Tras comprobar su correcto funcionamiento, se ha procedido a “reconstruir” la estructura del RAID, de forma que desde el segundo disco que estaba almacenando correctamente los datos, se ha trasladado toda la configuración y contenidos al nuevo disco. De esta forma, no ha sido necesario hacer uso de las copias backup, y los datos del nuevo disco serán exactamente los que había en el momento de la última desconexión.

También se ha aprovechado para hacer una nueva actualización del kernel.

Esperamos que estas dos intervenciones pongan punto y final a los problemas que la máquina ha sufrido en los últimos días.

Actualización 15:00 horas

La máquina ha vuelto a fallar. El problema ya no es del disco duro, que se muestra estable y bien configurado. Los técnicos están tratando de localizar cual es el origen de los nuevos problemas, con la sospecha que se trate de un fallo de la controladora o de los puertos usb.

Al margen de intentar solventar los problemas de esta máquina, ya se ha iniciado el procedimiento para trasladar a todos los clientes a una máquina nueva. Está previsto que esto pueda realizarse a mediados o finales de la próxima semana. En primer lugar hay que realizar una configuración del sistema similar a la actual y después los clientes se irán trasladando de forma progresiva en un par de días.

Lunes, 15 de diciembre:

Desde el pasado viernes no se han producido nuevos reinicios en la máquina, por lo que la incidencia se considera definitivamente resuelta.

A las 13:03 horas se ha restablecido por completo la conexión.

[ Ni las máquinas ni los servidores han sufrido la incidencia. Han continuado funcionando con normalidad y ejecutando sus tareas internas (rotación de logs, generación de estadísticas, etc.) Los mensajes enviados hacia y desde las máquinas también se han procesado con normalidad una vez recuperada la conectividad interna.  ]

Disculpen las molestias.

12:55 horas: El servicio ha quedado totalmente restablecido, tras resolver un problema con los módulos de memoria.

13:00 horas: A pesar que el servicio ha sido restablecido durante unos minutos, poco después ha vuelto a perderse la conexión. En estos momentos estamos trabajando en el firewall y en shell local para detectar cuál es el origen de la sobrecarga del software.

13:15 horas: Hemos recuperado el acceso remoto al hardware, pero la conexión normal con la máquina está bloqueada desde el firewall hasta que se identifiquen los accesos que sobrecargan la máquina. Esperamos resolver definitivamente la incidencia antes de las 14:00 horas.

15:00 horas: No está siendo posible recuperar el servicio. Todos los esfuerzos no logran recuperar el funcionamiento y en cada paso aparecen errores nuevos. Desde el datacenter están haciendo todo lo posible para colocar una máquina nueva durante el día de hoy.

16:45 horas: Los problemas de sobrecarga y de ataque externo no han hecho más que ocultar el problema real en el sistema raid1 de la máquina.

Los técnicos han determinado que nos encontramos de nuevo ante un fallo del sistema de almacenamiento y será necesario reemplazar la máquina, los discos duros y recuperar los contenidos del disco averiado. No se prevee ninguna nueva pérdida de contenidos, pero la restauración del servicio puede alargarse unas 10 horas.

Dos de nuestros responsables se han desplazado a San Sebastián esta tarde para coordinar los trabajos.

21:00 horas: Se ha logrado recuperar el acceso al disco y corregir los problemas del RAID. En estos momentos se trabaja para recuperar las particiones del disco principal. Este proceso puede tardar en completarse entre tres y cuatro horas.

Viernes, 22 de agosto: 03:00 horas: Los técnicos van a proceder al reinicio de la máquina y chequeo de los servicios principales. Si todo es correcto los servicios podrían restablecerse en 1 hora.

Viernes, 22 de agosto: 04:30 horas: Se han resuelto algunos pequeños problemas y se está realizando una copia backup general, antes de poner de nuevo la máquina online.

Viernes, 22 de agosto: 06:00 horas: Todos los servicios han sido restablecidos.

Pese a comunicar en varias ocasiones, desde principios de agosto, el fallo de los sistemas RAID1 y de los discos duros de la máquina ESP07, propiedad de Ibercom, no se ha intervenido la máquina ni han reemplazado el hardware hasta que los discos duros han sido inservibles.
Debido al deficiente servicio recibido por parte de Ibercom, en esta última incidencia y en las dos anteriores que afectaron a esta misma máquina, se ha decidido dar de baja esta máquina y trasladar todos sus recursos a otro datacenter.

Sábado, 30 de agosto: 06:00 horas: Se ha completado el traslado de todos los contenidos a una nueva máquina en otro datacenter.

Una de nuestras máquinas principales ha tenido una grave incidencia, que ha desencadenado otras complicaciones posteriores y ha provocado un corte en el servicio superior a 48 horas para casi un centenar de clientes.

Desde Dimensis hemos trabajado intensivamente, algunos técnicos han estado toda la incidencia sin descansar, realizando horas extras, porque no debemos olvidar que la incidencia se ha producido cuando parte de los técnicos habituales están de vacaciones. La incidencia en agosto también nos ha alargado el tiempo de respuesta por parte de algunos proveedores, además de la imposibilidad de contar con otros que están cerrados hasta mediados de agosto.

Pero no hay excusas. Sólo disculpas sinceras. Hemos hecho todo lo posible para restablecer el servicio lo antes posible. Muchos clientes no tendrán esta percepción, porque más de 48 horas sin servicio no es aceptable. Pero el resultado final de la incidencia ha sido la recuperación total de contenidos y servicios para un porcentaje superior al 90% de los clientes, a pesar que el sistema de almacenamiento RAID1 afectado todavía no ha podido recuperarse.

Dimensis ha realizado un importante esfuerzo de medios materiales, humanos y económicos. A la espera del cierre definitivo de la incidencia, el gasto económico para Dimensis ya supera los 2.000 euros, y a esa cantidad habrá que sumar las compensaciones económicas a los clientes afectados y las horas extras de los técnicos, por lo que el gasto final superará los 6.000 euros.

Han sido muchas horas de trabajo intenso, de inconvenientes, de esperas, de atención telefónica a clientes enfadados, de previsiones sin poder cumplir, …

Poco a poco la situación fue remitiendo, desde que se inició la recuperación progresiva de los servicios a las 36 horas (10%), 48 horas (30%), 55 horas (60%), 60 horas (75%) … En estos momentos todavía hay un 10% de los servicios que han podido ser recuperados, pero se estima que sólo entre un 3-5% serán realmente irrecuperables.

El departamento de atención al cliente ha habilitado el correo reclamaciones@dimensis.es para gestionar todas las quejas y reclamaciones correspondientes a esta grave incidencia. Los clientes afectados tendrán derecho a una compensación sobre su cuota de alojamiento, en función del tiempo de desconexión de sus recursos. Las compensaciones podrán oscilar entre un 25% y un 50% de la última cuota de alojamiento pagada, dependiendo de si fue una cuota anual o trimestral.

Esta nueva incidencia en ESP07 (segunda en menos de 1 semana) ha puesto al descubierto el problema real que afecta a esta máquina desde hace una semana. Al parecer se trata de un problema en el sistema backup por particiones, que ha generado varias inconsistencias en el sistema de archivos del disco principal, y que ha afectado al segundo disco duro sincronizado en tiempo real con el RAID 1.

Es una incidencia muy grave, puesto que afecta al sistema de almacenamiento de archivos (hardware), pero en realidad es un fallo del software, que provoca además una sobrecarga de CPU. Por lo tanto se trata de un fallo múltiple, que afecta a varios componentes y que tiene una solución compleja que requiere mucho tiempo de trabajo (más de 6 horas).

12:00 horas:

Poco antes de las 12:00 horas hemos logrado corregir los problemas en el sistema de archivos backup y particiones. Ya se ha recuperado el acceso remoto a la máquina y se han arrancado algunos servicios. También se han verificado los contenidos de los servidores virtuales y la última copia backup completa (2 de agosto).

Estamos trabajando para reiniciar los servicios de cada servidor virtual, con los contenidos y configuraciones intactos tal y como estaban antes de la incidencia (5 de agosto).

14:15 horas:

El proceso de copia de configuraciones y revisión de particiones todavía no se ha completado. Los intentos de realizar todas las copias y reactivar los sistemas de forma automática han fallado y ponen en peligro una recuperación total del servicio. Por este motivo, se ha decidido realizar el proceso de forma manual. Aunque sea mucho más lento, es más seguro de cara a la recuperación completa y un reinicio seguro de los servicios.

No hay una previsión de finalización. De hecho, se irán completando las copias y se irán reiniciando de forma secuencial, según el orden marcado por el disco duro, por lo que es posible que los servicios empiecen a recuperarse entre las 16:00 y las 20:00 horas. Pero no podemos concretar cuando estará resuelto para cada cliente.

20:00 horas:

Tras diferentes intentos de reiniciar el servicio desde la máquina y el disco afectados, ya se ha comprobado que es imposible. Se está trabajando desde hace varias horas en copiar todos los contenidos actualizados del disco duro deteriorado y así remontar los servicios desde una nueva máquina que se está configurando con la misma versión freebsd y las mismas configuraciones. El proceso es lento y se ha estimado que serán necesarias unas 16 horas, por lo que se prevee que mañana por la mañana los servicios ya podrían estar de nuevo operativos.

22:30 horas:

Seguimos trabajando en la recuperación de configuraciones y contenidos. La velocidad de generación de los backups es bastante lenta, porque el disco está más dañado de lo que se preveía. La velocidad de lectura y copiado del disco es demasiado baja en algunos sectores y eso ralentiza mucho el proceso.

De todos modos, los técnicos que realizan el copiado preveen terminarlo alrededor de la medianoche. después se empezará a restaurar los backups en una máquina nueva o en otros servidores virtuales de los clientes (si disponen de más de uno).

Además, se espera la llegada de un técnico especializado en recuperación de discos duros para tratar de recuperar el funcionamiento del disco y hacer una copia-imagen que pueda utilizarse en la misma máquina. Eso permitiría recuperar más rápidamente todos los servicios, sin cambios ni alteraciones en los contenidos. Pero antes de trabajar sobre el disco se ha decidido copiar todo manualmente, por si algo fallase en la recuperación automática.

6 de agosto: 01:30 horas:

Ya se ha finalizado con la copia de todos los contenidos del disco duro que ha sido posible. Durante la copia se ha observado que algunos sectores defectuosos han provocado fallos de consistencia y algunas carpetas de varias particiones no se han podido copiar. No obstante, el porcentaje de contenidos salvados supera el 95% (más de 200 GBs).

6 de agosto: 04:00 horas:

Tras efectuar varias correcciones sobre el disco duro, se ha determinado que los defectos no son compatibles con la continuidad del servicio, por lo que se ha reemplazado el disco y se está procediendo a la reconstrucción del RAID. Este proceso suele tardar entre 30 segundos y 1 minuto por GB, por lo que esperamos que se complete en un plazo entre 2 y 4 horas.

6 de agosto: 07:00 horas:

El proceso de reconstrucción del RAID todavía no se ha completado. Si finaliza con éxito todos los recursos deberían quedar nuevamente accesibles a lo largo de esta mañana. Pero si la reconstrucción falla, se tendrán que trasladar todos los contenidos y configuraciones a una nueva máquina y el plazo de tiempo necesario aumentaría considerablemente.

6 de agosto: 11:00 horas:

Finalmente la reconstrucción del sistema de almacenamiento no ha sido posible. Ya se está trabajando para restaurar las copias backup en una nueva máquina que ayer se provisionó y en la que esta madrugada ya se ha instalado la versión existente en la máquina ESP07 (FreeBSD 6.3).

También se están utilizando otras máquinas de Dimensis en activo para restaurar backups de servidores virtuales privados lo antes posible. El primero de los 10 servidores afectados ya ha sido recuperado parcialmente.

Ahora los técnicos de software comprobarán la instalación y procederán a personalizar el entorno para adaptarlo a VDSmanager (aplicación que gestiona las máquinas) y después realizar el volcado de las configuraciones de cada ISPmanager (licencias para entornos de servidores virtuales).

Si no surgen complicaciones con el nuevo hardware, el proceso debería dejar lista la máquina para iniciar la restauración de los backups antes de las 15:00 horas.

6 de agosto: 15:30 horas:

Hace unos minutos se ha iniciado la restauración de los backups generales. Este proceso tardará aproximadamente 1 hora y media, por lo que calculamos que alrededor de las 18:00 horas ya comenzará la restauración de los servidores virtuales y sus dominios alojados.

No podemos decir en qué momento exacto será restaurado un dominio concreto o un servidor virtual. Pero desde las 18:00 horas se iniciarán los primeros servicios y el proceso será ininterrumpido hasta que finalicemos con todos los recursos alojados. Debido a la gran cantidad de archivos y configuraciones de usuarios, es posible que el proceso tarde en completarse entre 6 y 9 horas.

6 de agosto: 19:30 horas:

Se ha restaurado parcialmente el segundo de los servidores virtuales afectados.

7 de agosto: 06:30 horas:

A las 05:00 horas ya se había completado el 50% de las restauraciones de servidores virtuales. Pero se han localizado nuevos fallos en la estructura de archivos de algunos servidores virtuales pendientes de reactivar. Nuestros técnicos están trabajando para resolverlos. En esta ocasión la previsión de resolución es de aproximadamente 4 horas, por lo que entre las 12:00 y las 13:00 horas se prevee restablecer el servicio en los servidores virtuales de ESP07 que todavía no han sido reiniciados.

7 de agosto: 10:30 horas:

El departamento de atención al cliente está preparando un servicio especial de reclamaciones para atender a todos los afectados por la incidencia, a partir del momento en que se de por finalizada. También se habilitará un correo especial para el intercambio de comunicaciones.

El servicio telefónico está teniendo algunos problemas debido a sobrecargas en la línea. Ya se ha contactado con la empresa Vodafone para tratar de habilitar un nuevo número si los problemas no pueden ser resueltos en las próximas horas.

7 de agosto: 15:00 horas:

Ya se han logrado recuperar 7 de los 10 servidores que estaban alojados en la máquina ESP07. En estos momentos, todos los servidores de alojamiento compartido vuelven a funcionar correctamente (con un porcentaje de errores inferior al 5% después de recuperar los backups, con fecha 3 de agosto).

La incidencia general ya puede darse por finalizada, pero los técnicos siguen trabajando en los 3 restantes. A partir de este momento, se modifica el alcance de la incidencia desde el grado “general” al “parcial”, ya que afecta a un porcentaje inferior al 20% de la utilización de la máquina.

Los problemas ahora, una vez recuperados los servicios y las configuraciones, están surgiendo por algunos backups incompletos, corruptos o con problemas para restaurarlos correctamente.

Siguiendo con las previsiones, hoy quedarán definitivamente restablecidos todos los servicios en todos los servidores. Aunque mañana abriremos una nueva incidencia para tratar los problemas surgidos después de la restauración de los backups.

7 de agosto: 19:00 horas:

Ya se han restablecido todos los servidores, con la excepción de dos servidores virtuales privados. Ambos son los más afectados por el fallo del sistema de archivos y sus copias backups y archivos más recientes están demasiado dañados para utilizarse directamente.

Técnicos especializados en recuperación de datos ya están trabajando para intentar recuperar las informaciones.

8 de agosto: 10:00 horas:

Hoy se ha reiniciado el servicio de otro servidor virtual, aunque parcialmente a las espera de recuperar el contenido de sus páginas web. Todos los demás servicios funcionan correctamente.

Se continúa trabajando para recuperar los datos del último servidor virtual privado afectado por la incidencia.

El departamento de atención al cliente ha habilitado el correo reclamaciones@dimensis.es para gestionar todas las quejas y reclamaciones correspondientes a esta grave incidencia. Los clientes afectados tendrán derecho a una compensación sobre su cuota de alojamiento, en función del tiempo de desconexión de sus recursos. Las compensaciones podrán oscilar entre un 25% y un 50% de la última cuota de alojamiento pagada, dependiendo de si fue una cuota anual o trimestral.

Alrededor de las 18:15 horas se detectaron los primeros síntomas de ralentización y hacia las 18:45 horas el servicio en una de nuestras máquinas quedó completamente inaccesible de forma remota. La máquina estuvo conectada en todo momento, pero la avalancha de peticiones inundó todo el ancho de banda de la IP y la máquina. El firewall y el router quedaron también colapsados en los primeros momentos.

Durante la primera hora no se pudo hacer mucho más que intentar reiniciar la máquina y la conexión sin éxito, para después tratar de reconducir el tráfico y filtrar las conexiones. Pero la pérdida de paquetes tcp era enorme y el timeout bloqueaba cualquier intento en pocos segundos.

Fué necesario detener la máquina y revisar una a una las IPs y el firewall. Poco a poco se logró cercar el ataque hasta localizarlo hacia una de las IPs principales. También se logró bloquear los accesos desde varias decenas de IPs y rangos.

Alrededor de las 23:00 horas se reinició la máquina y se mantuvo en funcionamiento unos minutos, pero se detectaron nuevos ataques, esta vez desde dos IPs principalmente. A las 00:00 horas el ataque se empezó a intensificar y se colapsó todo el servicio de correo saliente (smtp) por el puerto 25. Los escaneos de puertos y peticiones masivas para la denegación del servicio se volvieron cada vez más abundantes.

Se tuvo que detener de nuevo la máquina y reprogramar el firewall para denegar todo el tráfico entrante. Los técnicos del datacenter tuvieron que acceder físicamente a la máquina ante la imposibilidad de conectar por software y se habilitó un acceso remoto por hardware para que los técnicos de Dimensis también pudieran revisar todo el sistema.

A las 02:00 horas se logró detener el ataque y limitarlo a una única IP. Todas las demás se reactivaron progresivamente y se fué abriendo el firewall. Antes de las 04:00 horas todas las IPs de la máquina volvieron a la normalidad, excepto la IP más afectada por el ataque, que tuvo que permanecer desactivada hasta las 09:00 horas.

Después de bloquear los ataques desde mirrows, proxies y conexiones zombies, se alcanzó el origen del ataque en dos IPs: una perteneciente a Orange (España), ubicada en Madrid, y otra perteneciente a una empresa holandesa de servicios de hosting (LeaseWeb).

Una vez bloqueadas las IPs atacantes, se restableció por completo el servicio en el servidor compartido dimensis.biz.

Hoy se ha contactado con las empresas propietarias de las IPs atacantes para solicitar que detengan el ataque y que nos remitan una explicación sobre lo sucedido y las medidas adoptadas para impedir que vuelva a repetirse. Por lo general, ya sabemos que seguramente estas IPs habrán sido utilizadas de forma fraudulenta, sin conocimiento de los propietarios, pero si no se observa una predisposición clara a la colaboración, se presentará una reclamación formal.

Lamentamos todas las molestias que este grave ataque ha podido tener para nuestros clientes. Únicamente puede haberse visto reducida la gravedad por haber coincidido la incidencia con horario no laboral, pero aún así sabemos que varios clientes se han visto perjudicados.

Para Dimensis ha supuesto más de 16 horas de trabajo, nervios y preocupación, al margen de las compensaciones que puedan llevarse a cabo con los clientes afectados. Por suerte este tipo de ataques no son nada habituales, ni en virulencia ni en duración. Pero cuando se producen suponen un grave perjuicio para todos los afectados.

Para concluir, sólo hace falta añadir que ningún cliente ha tenido que temer por la pérdida de datos, correos o el ataque directo hacia su página web. Como hemos indicado, el ataque se centró en el servicio SMTP, con el objetivo de utilizar la máquina para el envío masivo de SPAM.

El objetivo del atacante no ha sido acceder a datos personales, ni bloquear el servicio, ni desconfigurar el sistema. Se trató de un simple ataque para enviar varios miles de mensajes spam gratuitamente. El ataque no hubiera tenido mayor importancia si no fuera porque la reconfiguración que realizó el atacante afectó de forma crítica al sistema interno de procesamiento y entrega de correos en la máquina.

Ningún servidor virtual recibió el ataque directo del spammer, ni sufrío modificación alguna en la configuración, pero los 6 servidores virtuales que comparten ESP 07 se vieron afectados por un corte del servicio de envío de correos (SMTP con SendMail). El problema fue difícil de localizar, porque todos los servicios estaban activos y bien configurados. Todos los puertos respondían correctamente y el servicio DNS era correcto. Sin embargo, los servidores virtuales no permitían el RELAY de mensajes.

Tras varias horas de revisiones y pruebas, se identificó el problema real, que afectaba la máquina y no a los servidores virtuales, como se había pensado y como apuntaban los mensajes de error.

Se trata de un problema realmente raro, que ha servido para detectar el fallo de seguridad y resolverlo. Lamentablemente ha supuesto la imposibilidad de utilizar sendmail durante unas horas. Rogamos disculpen las molestias.

La incidencia se considera crítica porque afecta al hardware de la máquina y requiere el cambio de varios componentes. Un técnico se ha desplazado a la máquina y está trabajando para reiniciar el servicio lo antes posible.

Esta incidencia ha afectado al filtrado antispam y al servicio SMTP (Sendmail) en una veintena de servidores virtuales que utilizan esta pasarela. Para minimizar los problemas derivados, se ha desactivado el filtrado antispam de forma temporal en algunos servidores, o se ha redireccionado hacia otras pasarelas de correo secundarias.

Actualizado a las 23:00 horas: La máquina averiada ya ha sido reparada. La pasarela de correo principal se reiniciará en unos minutos y progresivamente se volverá a restablecer el servicio antispam en los servidores que quedó deshabilitado temporalmente.

Disculpen las molestias.