Historias reales: El día que mi empresa atacó a otra por internet sin saberlo

Valencia noticias |INCIBE  «Galletas Don Gutierre», empresa líder en la industria galletera, mantenía todos los sistemas de la compañía en un CPD en su sede. Este CPD daba soporte a las redes de las distintas sucursales y fábricas de la compañía. El mantenimiento es llevado a cabo por un equipo técnico a cuyo frente se encontraba José.

Entre los servicios que se alojaban en el CPD central se encontraban:

  • los diferentes servidores de su web
  • los servidores de bases de datos (de ventas y clientes)
  • los servidores de correo electrónico, para los correos electrónicos de los empleados
  • el servidor de resolución de nombres interno (DNS) que es el que permite que al escribir la dirección de la intranet y otros servicios de la empresa accedan a ellos.
  • el servidor de cuentas de usuario (LDAP) con el que se validan los usuarios de la empresa cuando acceden a sus puestos.

Una mañana, José recibió en su despacho la visita de Luis, uno de sus técnicos, porque habían recibido un correo electrónico de una empresa de fabricación de motores (Motores Fernández).

01
image-208031

El correo les decía que estaban recibiendo grandes cantidades de «tráfico de red» procedente de los servidores de su empresa. Les estaban haciendo una denegación de servicio.

En concreto, continuaba el email, se trata de DNS (de resolución de nombres de internet). José se puso a pensar e hizo un esquema de lo que estaba pasando y analizando alguno de los servidores:

02
image-208032

Al instante descolgó su teléfono:

  • Luis, el problema está en la configuración del servidor DNS. Lo tenemos abierto a Internet. Es un servicio interno no debería permitir accesos desde el exterior. Investiga cómo cambiar eso.
  • ¿Como? Pero si lo tenemos en la red de los servidores.
  • Ya, pero lo tenemos configurado para que dé servicio a todo el mundo y un ciberdelincuente lo está aprovechando para enviar tráfico basura a esta gente de Motores Fernández
  • ¿Y eso para qué? Pues no sé, porque les caerán mal. Vete tú a saber…

Sin embargo uno de los mayores problemas que descubrieron era que tenían los servidores directamente conectados a internet, sin ningún cortafuegos que les pudiera servir de defensa.

José y su equipo se pusieron manos a la obra y en apenas 2 días tuvieron los equipos bien configurados y protegidos. En ese momento y de vuelta en su despacho José decidió responder a la empresa de motores Fernández que les había informado del problema para darles las gracias.

¿Qué fue realmente lo que pasó?

Aunque hay servicios que se crean con el objetivo de que estén en todo momento abiertos al público en general (por ejemplo los servidores web, ya que siempre queremos que puedan visitar nuestra página) o los servidores de correo (queremos poder recibir todos los correos que nos mandan), hay otros servicios que sólo deberían estar disponibles para los empleados de la empresa. Por ejemplo los servicios de DNS (de resolución de nombres de dominio a direcciones IP). Estos servicios son transparentes para el usuario final.

En este caso, aparentemente GalletasDonGutierre se dejó el servidor de nombres (DNS) abierto y cualquier equipo desde el exterior podía hacer consultas de nombres al servidor de galletasDonGutierre.

Pero, ¿qué tiene esto que ver con la denegación de servicio?

Una denegación de servicio es un tipo de ataque contra las empresas, también conocido con el nombre DoS. De forma muy general: imaginemos que en la barra de un bar hay dos camareros que pueden atender a aproximadamente 5 clientes a la vez, si de repente entrasen en el bar 1.500 personas, no pueden atenderles a todos y se quedarían «colapsados» ante tal número de personas.

Bien, teniendo el ejemplo anterior en mente y desde un plano más «tecnológico» el problema en este caso es que el atacante se hizo pasar por Motores Fernández y comenzó a hacer consultas al servidor de nombres (DNS) de Galletas Don Gutierre, que se encontraba mal configurado y atendía cualquier tipo de petición.

La petición enviada por el atacante era algo como “Hola, soy la empresa Motores Fernández y me gustaría saber cómo poder ver la página de Google y ya de paso, qué servicios ofrece”. Es decir, se estaba haciendo pasar por Motores Fernandez. La consulta era muy cortita pero la respuesta era mucho más larga (entre 30 y 50 veces más larga).

… ¿Y esto para qué? Seguro que los ordenadores de Motores Fernández saben cómo ver Google… Cierto. Y de hecho el cortafuegos de Motores Fernández, como no espera el mensaje del servidor DNS, lo descartará y sin problemas…. Si se trata de una única respuesta. Pero imaginemos que el atacante realiza millones de consultas haciéndose pasar por Motores Fernandez. Entonces el servidor de GalletasDonGutierre devolverá millones de mensajes de respuesta (y muy largos) y provocarán que los servidores de la Motores Fernandez no puedan dar abasto y se provocará una Denegación de Servicio similar a la que explicábamos antes. Así, el cortafuegos de Motores Fernández no podrá dar servicio a sus usuarios (no dejando ni a los usuarios navegar, ni a los clientes acceder a su web) por estar ocupado descartando respuestas que no había solicitado.

Este tipo de ataques se suelen realizar aprovechándose no de uno sino de varios servidores DNS abiertos mal configurados, de manera que el tráfico que reciba la empresa atacada sea aún mayor.

¿Qué hacer si nos sucede esto?

Es un problema de mala configuración que un ciberdelincuente está aprovechando para atacar a un tercero. Si es posible, se debe desactivar el servicio vulnerable que está realizando el ataque. Si no fuera posible, se debe configurar el sistema y los servicios adecuadamente. En cualquiera de los dos casos siempre debemos de revisar la configuración de nuestro cortafuegos (o implantarlo en el caso de que no exista) para no dar acceso desde el exterior a servicios que sean solamente internos.

Es importante también almacenar todos los logs (ficheros de registro) de los servidores que han estado mal configurados. De esta manera, en caso de recibir algún tipo de denuncia, al menos podremos alegar que nuestros servidores estaban respondiendo legítimamente a las consultas realizadas por el demandante. Por esta razón es importante que dentro de la política de backup se almacenen los ficheros de log de todos los servidores en las copias de seguridad.

¿Qué hacer para que no nos ocurra esto?

Para evitar que este tipo de incidentes ocurran, las recomendaciones que generalmente se ofrecen son:

  • Realizar una auditoría de seguridad para la detección de malas configuraciones y vulnerabilidades que pudieran permitir este tipo de ataques.
  • Configurar el servicio de servidor de nombres (DNS) con opciones de seguridad:
  • permitir su acceso solo desde algunas redes
  • cambiar parámetros para evitar este tipo de ataques
  • Configurar un cortafuegos para evitar exponer a internet puertos / servicios innecesarios. Crear reglas de cortafuegos que filtren el acceso al servicio vulnerable.
  • Introducir los servicios que deban estar abiertos al público en la red llamada DMZ y los servicios internos en la red interna. Una DMZ es una red segura y aislada que se ubica entre la red interna de una organización e Internet. El objetivo es proteger a la red interna de accesos desde el exterior.

Valencia noticias Noticias de Valencia, Castellón y Alicante Periódico, prensa digital valenciano, Noticies en Valencià, noticias nacionales e internacionales.

Leave a Reply

Your email address will not be published.