Esta historia sucedió a finales de 2014, mientras probaba la estabilidad y configuración de algunos programas en un servidor antes de llevarlos al servidor de producción. Como era un servidor de pruebas, y los datos que manejaba no eran privados, decidí no hacer nada para su seguridad. Es decir, usé contraseñas muy sencillas, firewall desactivado y todo con la configuración por defecto.
Tabla de contenidos
Pruebas antes de utilizar en producción
En general, esto es lo recomendable. Es decir, aunque tengamos un servidor de test para probar los últimos cambios en nuestras plataformas y un servidor de producción en el que nada puede fallar ya; en ocasiones cuando necesitamos un software nuevo y podemos meter la pata está bien hacer pruebas en otro servidor externo, sin relación con los anteriores, para ver cómo va. Y cuando esté todo claro, lo trasladamos a test y luego a producción.
La teoría está muy bien, y aprovechando que los servidores VPS están muy baratos, un día de alquiler de un servidor pequeño puede salir por menos de 20 céntimos, por lo que puede ser una manera interesante para realizar las pruebas. Aunque siempre surge aquella prueba que no vas a tardar mucho y te lanzas a probar…
¿Qué necesito?
Yo necesité 4 servidores Ubuntu Server, muy pequeños, ya que mi experimento tenía que ver con el intercambio de información entre servidores (utilizar varias máquinas virtuales en mi ordenador tal vez hubiera sido muy costoso para mí). Y a lo mejor 2 o 3 horas de tiempo online.
Seguridad
Y, ¿como contraseñas? pues 111111, 222222, 333333, 444444 dependiendo del servidor. ¿Claves RSA? Pues no, porque tenía que generar claves en todos los servidores y copiar las claves públicas, y da pereza. ¿Firewall? Desactivado completamente, como era un tema de comunicación entre servidores y no conocía bien el software, no sabía qué puertos necesitaba para realizar la comunicación, es lo que pasa cuando vas a saco.
El problema
Después de 2h de trabajo, me voy a comer, y, como he hecho mucha configuración al vuelo, y al reiniciar las máquinas dicha configuración se perderá, lo dejo todo encendido, total, 1 hora más por máquina, no son 3 céntimos, pues pa’lante.
Después de comer, veo que hay una máquina que no responde. Mi primera sospecha es el software que estoy probando que ha dejado frito el server, pues nada, reinicio y sigo probándola, pero la máquina no funciona como antes, tarda un poco más en responder y me pongo a revisar toda la configuración. Descubro que hay un par de archivos ocultos en la home de mi usuario que no reconozco.
De repente veo mi e-mail y encuentro tres mensajes de mi proveedor de VPS diciendo que las IPs de 3 de mis máquinas están denunciadas por phising, ¡ toma ya ! Ahora me dedico yo a sacar contraseñas de usuarios de un banco italiano por la cara. En ese momento, otras dos de mis máquinas se desconectan. ¡ Impresionante ! E impresionante era mi estado de nervios en ese momento, cuando pensaba que en cualquier momento la Guardia Civil entraría por mi puerta…
Resulta que un atacante, vio mis servidores, escaneó puertos, se dio cuenta de que el puerto SSH estaba abierto, probó usuarios (el usuario admin, por ejemplo) y se puso a probar contraseñas, las mías eran de diccionario, vamos. Seguidamente, y con acceso, ejecutó un pequeño script que instalaba un servidor web muy pequeño y la web en cuestión y ya tenía un demonio de phising activado y funcionando. Luego, redirigiría las DNS de algún subdominio parecido al del banco que queremos atacar y fuera. El servidor no es suyo, por lo que si contactan con la dirección de abusos correspondiente a la IP saldrá mi proveedor, y mi proveedor me echará la bronca a mí porque la IP la tengo contratada yo.
La dirección de abusos la podemos obtener haciendo whois a la IP que queremos analizar. Además de la información sobre el proveedor, el país, el rango, etc. Nos saldrá una dirección de e-mail con la que debemos contactar si creemos que desde esa IP se está haciendo un uso indebido.
Esta herramienta, whois también podemos utilizarla en dominios, y el mensaje lo recibe el registrador. Por otro lado, si estás en España, y crees que existe un delito es conveniente que, al menos, informes a la unidad de delitos informáticos de la Guardia Civil.
Al final se portaron muy bien, mi proveedor se tomó muy en serio la queja, tras un par de mensajes, cerraron todo acceso externo al servidor (quitando el puerto de SSH) para que me diera tiempo a salvar la información importante. Bueno, y al ser la primera vez sólo me dieron un toque de atención, sabían que yo no era el malo de la película, sólo la víctima, aunque según las condiciones de servicio, se pueden tomar la libertad de echarte si ven que te pasa mucho. Yo, por si las moscas, copié los ficheros que me interesaban de cada servidor y los desactivé.
Moraleja
Aunque tarde un poco más, intentaré proteger un poco más la instalación SSH, tal vez no hacer algo demasiado extremo, pero al menos, configurar pares de claves pública y privada para los servidores, aunque tarde un poco más y dé pereza, está claro que nada más tener conectada una máquina a Internet, puede ser víctima de ataques.
Foto: Wesley Wilson
Pingback: ¿ Por qué debemos trabajar en la seguridad hasta de un servidor de pruebas ? | PlanetaLibre /
There are several reasons why it is crucial to prioritize security even on a test server. Firstly, a test server may contain sensitive information or databases that could be exploited if not adequately protected. Secondly, any vulnerabilities discovered on a test server can enable hackers to gain valuable insights into the system’s weaknesses, risking the integrity and security of the overall network.
There are several important reasons why we should prioritize security even on a test server. Firstly, test servers often contain sensitive data or prototypes that, if compromised, could lead to serious consequences such as intellectual property theft or regulatory non-compliance. Secondly, by maintaining robust security measures on test servers, we can identify and fix vulnerabilities before they are present in the production environment, thus reducing the risk of potential attacks.
The article provides valuable insights into the potential risks associated with neglecting security measures in a testing environment and emphasizes the need for a comprehensive approach to safeguarding data and systems. The author highlights various reasons why organizations should pay attention to the security of their testing servers, including the potential for data breaches, unauthorized access, and the demonstration effect that flaws in the testing environment can have on clients and users.
The author highlights the potential risks and vulnerabilities that can arise from neglecting security measures in the development, testing, and deployment of a server. The consequences of overlooking security can range from exposing sensitive data to unauthorized access, to compromising the integrity of the entire system.
The comment you referred to, left by an anonymous user, brings up an interesting point about the potential risks and vulnerabilities that can arise from neglecting security measures on testing servers. The user emphasizes the need to treat all servers, regardless of their purpose, with the same level of care and attention when it comes to security.
The author emphasizes the need for organizations to prioritize security not only on production servers but also on testing environments, as they can still be vulnerable to attacks. The blog post highlights the potential risks that come with neglecting security measures on testing servers, including unauthorized access and potential data breaches. It underscores the significance of implementing robust security protocols, such as regularly updating software, restricting access privileges, and conducting thorough security assessments, to mitigate the risk of compromising sensitive data during the development and testing phases.
The article explores the potential risks associated with neglecting security in testing environments and highlights why it is crucial to prioritize security throughout the entire software development lifecycle.
The main argument presented is that neglecting security measures during this phase can expose organizations to serious risks and potentially compromise sensitive data. The author suggests that implementing proper security protocols and testing them rigorously can significantly mitigate these risks and protect both the organization and its clients or users.
The author of the article emphasizes the importance of working on security even for a test server, as it plays a crucial role in protecting sensitive data and preventing potential vulnerabilities. They assert that neglecting the security aspects of a test server can lead to severe consequences such as unauthorized access, data leakage, and even compromising the entire network infrastructure.
The author emphasizes that neglecting security on a testing server can have severe consequences, as it can provide an entry point for attackers to exploit vulnerabilities and gain unauthorized access to sensitive data. The article highlights the fact that many organizations tend to overlook the security of their testing servers, considering them less critical than production servers.