Como no quise ser menos que Neri, tengo que contarles que mi blog también fue hackeado  ;), qué fue lo que pasó y qué aprendí de esta experiencia. A continuación, mi pequeña historia.

Poco menos de 2 semanas atrás, Milagros me aviso que mi cuenta Twitter había sido tomada por un hacker. Por lo cual, comencé a tomar medidas sobre el asunto, pero ya era tarde.

Cometí   muchos errores y descuidos que permitieron que el hackeo de mi blog Oberdata fuera algo relativamente sencillo para el delincuente.

¿Pero cómo el atacante logró acceder al password de mis cuentas? Errores cometidos:

• SQL Server público: En esos días estaba cambiando de servidor y para poder realizar este traspaso, necesite publicar el SQL Server. El hacker efectúo un ataque de fuerza bruta para obtener mi contraseña de usuario “SA” y lo logró, luego de más de 160.000 intentos en 3 días.
• Password de SA y usuarios del sistema: Un error gravísimo que cometí es dejar el mismo password de SA para un usuario del sistema con permisos root.
• ¿Me toco un hacker bueno? Eso no lo sé, ya que perdí algo de dinero en mi cuenta de Paypal. Lo que si estoy seguro es que el hacker pudo haber realizado más daño del que hizo. Igualmente pude averiguar quién fue.
• ¿Y el firewall? El firewall funcionaba, pero al publicar los servicios de FTP, SQL Server y Remote Desktop deje vulnerable mi server.
• Exploits en BlogEngine: El hacker intentó acceder a archivos del servidor por medio de exploits en blogengine. Estos ataques fueron realizados desde la ip 24.10.202.254.
• ¿Como borró  el hacker mi blog?: Por FTP, simplemente entró y borro las carpetas de mi server.
• ¿Accedió el hacker por terminal server? Si, pudo acceder por terminal server a mi server y todo quedo en la auditoria que el atacante no pudo borrar, ya que pude cambiar mis contraseñas. Estas son algunas de las ips utilizadas para acceder: 59.44.141.237, 24.10.202.254, 121.14.213.91.

Para que esto no suceda nunca más. ¿Qué cuidados debo o debemos tener?

• Passwords seguros: Utiliza passwords seguros, de por lo menos 10 o más caracteres. En la actualidad existen programas que pueden desencriptar passwords SHA1 y MD5 por fuerza bruta. Pero si tu password tiene muchos caracteres, letras mayúsculas y minúsculas combinados con números, el trabajo para al hacker será casi imposible.
  El día del ataque, Fabio Maulo me recomendó un programa muy interesante para administrar passwords llamado keepass. El mismo puede generarte passwords seguros.
• VPN: Utiliza una VPN para publicar los servicios que necesites y consideres que puedan ser vulnerables como FTP, SQL Server y Remote Desktop.
• Logs: Los logs son muy importantes para estos casos. Si tienes servicios publicados en internet y no tienes logs de los mismos, no podrás auditar. Es fundamental tener acceso a los logs y que los mismos sean los más detallados posible.
• DROP por Default: Es la regla por defecto que tienes que poner en tu firewall. Primero no permitas absolutamente ningún tipo de tráfico y luego vas agregando reglas para los distintos servicios y puertos que necesites que estén abiertos.
• Usuario SA: Si necesitas que tu SQL Server este público, es altamente recomendable que deshabilites el usuario SA.
• Redes Sociales: Exponerte en redes sociales puede ser bueno para conseguir amigos, pero también puedes crear enemigos.
• Niveles de passwords: No tengas 1 o 2 passwords nada más, trata de crear varios passwords y ponle niveles. Nunca utilices los passwords de las redes sociales para los usuarios de sistemas.

Esta fue mi experiencia. Espero que mis errores y dolores de cabeza les permitan tomar más recaudos y aprender de mi ejemplo.