Seguridad para tu VPS

Hola, ¿qué tal? ¿Cómo estás? Espero que todo vaya muy bien. Te saluda Alex Ávalos y te doy la bienvenida a Panel de Control,

el podcast para quienes quieren tener el control de su propio servidor y disfrutar de las ventajas del hosting VPS.

En junio del 2014, Code Spaces, una empresa británica, ofrecía un servicio para que programadores y equipos de desarrollo pudieran guardar y gestionar el código fuente de sus proyectos.

Era algo así como un Dronebox, pero especializado para código de programación. Algo así como lo que ahora nosotros conocemos como GitHub, pero en ese entonces era ¡wow!

Era algo nuevo nunca antes visto.

Empresas y desarrolladores guardaban ahí sus proyectos en Code Spaces.

Su código, su trabajo, tenían clientes, tenían reputación.

De hecho, hasta su eslogan, hombre, era muy potente.

"Rock Solid, Secure and Affordable"

So sorry, vos sabes que my English is not very good looking. Es decir, hosting sólido, seguro y asequible. Pero en menos de 12 horas, todo se fue al traste y tanto así que la empresa simplemente dejó de existir.

¿Y qué pasó? Un cibercriminal logró acceder al panel de control, al dashboard, a la cuenta de Amazon AWS, donde tenían todos sus servidores.

Esto empezó con un ataque de denegación de servicios, un DDoS, que duró 12 horas.

Y luego dejó un mensaje.

"Contáctame o lo borro todo."

Estaba pidiendo un rescate, los atacó con un ransomware.

Code Spaces, hombre intentó negociar, pero mientras trataban de recuperar el acceso,

cambiaron contraseñas, también intentaron echar fuera al atacante.

Pero el atacante, astuto, había creado puertas traseras, estas backdoors,

accesos ocultos para volver a entrar y retomar el control.

Y cuando se dio cuenta que CodeSpaces estaba intentando sacarlo, se dio cuenta que no iban, o sea, que no estaba entre sus planes pagar el rescate, así que les borró todo. Todos los snapshots, todos los backups, todas las máquinas virtuales, todo.

En el comunicado oficial, Code Spaces dijeron que no vamos a poder operar más allá de este punto.

El costo de resolver este problema y de reembolsar a nuestros clientes nos ponen en una posición irreversible, tanto financiera como de credibilidad.

La empresa cerró permanentemente. Por supuesto, no se iban a poder recuperar y nunca intentaron recuperarse.

A todo esto, yo no sé vos, pero a mí me queda la duda, ¿cómo entraron? ¿El cibercriminal cómo logró?

Al día de hoy, pues, está documentado muchas cosas, pero nunca se supo con certeza,

aunque lo más probable puede ser credencia de débiles en el panel de AWS,

falta de autenticación, de segundo factor de autenticación,

y por supuesto, ninguna alerta ante accesos inusuales o accesos extraños.

Y por supuesto, al final del día, el gran meme se hizo realidad en este caso.

Tenían los backups en el mismo lugar que los servidores.

Gran error.

Ahora, CodeSpaces era una empresa de tecnología.

Estamos hablando que era gente que sabía de servidores de código.

Y aún así, no implementaron la seguridad básica.

Con esto, yo no estoy tratando de asustarte. Bueno, un poquito quizás sí. Estoy tratando de que entendas que la seguridad no es una opción, no es opcional. No es algo que vamos a hacer después. Vamos a ver si nos queda chance. No. Es lo primero que dejas hecho.

Al momento de crearte tu servidor VPS, al momento de instalar tu WordPress, al momento de subir tu web, esto es lo que haces antes de cualquier cosa.

Por eso, vamos a ver en este episodio las 5 capas, ah no, no, las 4 capas básicas para proteger tu servidor VPS, digamos del 95% de los ataques.

Antes de entrar en faena, tenemos que tener claro que la seguridad no es una cima, no es una meta, no es un punto al que se llega.

La seguridad deberíamos de siempre entenderla como capas, capas para proteger nuestros sistemas y mantener a salvo nuestros datos.

Por supuesto, en este episodio no vamos a ver seguridad intermedia ni avanzada.

Vamos a comenzar con lo más básico, con el ABCD, ¿no?

Por eso son cuatro.

Con lo fundamental, con lo esencial, con lo básico de lo básico.

Es decir que esto sí o sí lo tenés que tener.

Vamos a ver, capa 1, no usar root directamente.

Root o el usuario administrador por defecto, Ubuntu, Debian, etc.

El usuario root es Dios en el servidor.

Puede hacer cualquier cosa.

Puede hacerlo todo.

Puede crear todo, pero también puede borrarlo todo, instalar lo que sea,

y no necesita confirmaciones y nadie le pone ninguna restricción.

¿Cuál es el problema?

Si alguien entra como root, tiene poder total.

Y si vos mismo trabajas como root, puede ser en algún momento de de velo, prisa o cansancio,

podés cometer un error al escribir y podés estropearlo todo.

¿Cuál sería la solución?

La solución sería crear tu propio usuario y darle permiso de administrador.

Y cuando necesites hacer alguna gestión con el usuario root,

Forzarte a usar el comando sudo para recordarte que estás realizando procesos administrativos.

También es recomendable, siempre con este usuario, usar siempre tu usuario administrador y desactivar el uso directo del usuario root o el usuario Ubuntu o el usuario administrador por defecto.

Así si alguien detecta, alguien intenta entrar como root, simplemente no va a poder.

Se va a quedar fuera.

Capa 2. El Firewall.

Un Firewall puede sonar muy complejo, pero en realidad su funcionamiento es bastante simple.

El Firewall ya tiene los puertos abiertos o cerrados.

Por lo tanto, decide que puede entrar y que no. Y ya está. Así de simple. Por defecto, tu VPS nuevo tiene todos los puertos abiertos. Así como un terreno baldío o una casa sin paredes. Todo abierto. Así.

¿Qué necesitas? Cerrar los puertos, bueno, te diría todos, ¿no? Podemos decirlo así, cerra todo y abrí únicamente lo que vas a usar. Por supuesto, el puerto para el SSH, el puerto para HTTP, el puerto para HTTP, ese si tienes tu sitio web en el servidor.

Y nada más. Y ya de ahí todo lo demás. Cerrado. Ubuntu ya viene con el UFW, que significa Firewall sin complicaciones. Y hace honor a su nombre porque es simple, efectivo y realmente funciona.

Pero además también, dependiendo del panel de control que vas a usar, tenés que ver en la documentación qué puertos usa para su funcionamiento y también abrirlos.

Porque si lo cerrás todo, incluidos los puertos de tu panel de control, no vas a poder usarlo y vas a tener problemas en el funcionamiento.

Capa número 3.

Fail to Ban.

Fail2ban.

Fail2ban es un programa que monitorea los intentos de acceso. Es decir, que si alguien intenta entrar y falla 1, 2, 3, Fail2ban bloquea esa IP. Y la bloquea por un tiempo. Puede ser una hora o por el tiempo que vos has establecido en la configuración.

Funciona esto automáticamente.

Vos lo instalas, lo pones a punto,

configuras lo básico

y ya se encarga Fail2ban de todo, solo.

Por supuesto, te lo recomiendo

porque yo lo tengo en todos mis servidores.

Y una de las cosas que a mí me hizo

tener más conciencia de esto

es ver los logs

y ver todas las IPs bloqueadas

Y ahí es cuando te das cuenta del problema real y de la pobre lucha que hace todos los días a toda hora tu pobre servidor.

El guerrero de mil batallas, el verdadero guerrero, Minions, invadan Perú.

Capa 4, contraseñas fuertes.

Aunque sería mejor el uso de las llaves o claves SSH. Pero de esto vamos a hablar más adelante. Esto parece obvio, ¿no? Pero fíjate que no lo es tanto. 1, 2, 3, 4, 5, 6 sigue siendo una de las contraseñas más usadas.

También, incluso los nombres de perros ya están en los diccionarios de los cibercriminales. Nombres de perros, nombres de gatos, fechas de nacimiento, familiares, nombres kawaii, todo ya están en los diccionarios.

Yo te recomiendo, si la llave es SSH, pero si vas a usar usuario o contraseña, una contraseña fuerte, robusta, segura. Mínimo 21 caracteres, letras mayúsculas, minúsculas, números, símbolos.

Y esto, por supuesto, va a ser algo que no vas a poder recordar fácilmente.

Y de hecho, en el mejor de los casos, no deberías ni siquiera de saber cuál es.

Porque para eso es recomendable usar un gestor de contraseñas.

Pero para esto hay una mejor forma de hacerlo.

Y son las SSH keys, las claves SSH, que son como una llave digital mucho más segura que las contraseñas.

Y una vez que las configurás, ni tenés que escribir nada.

Es automágicamente la conexión.

Pero de esto vamos a hablar más adelante.

Después de implementar estas cuatro capas, ¿qué cambia?

Pues ya lo hice y quedé bien contento y muy motivado y con el chute de energía.

Y wow.

Pero y ahora qué pasó?

Qué cambió?

Vamos a ver.

Han cambiado varias cosas.

Lo primero, los ataques automatizados básicos ya no te van a afectar.

Van a intentar entrar como root y no van a poder.

Van a probar contraseñas comunes y fail to ban lo va a bloquear.

Y por supuesto, el Firewall ha cerrado todo menos lo que realmente está en uso.

Segundo, vos vas a trabajar mucho más tranquilo.

¿Por qué? Porque sabes que tu servidor tiene su protección básica, que no es presa de los ataques.

Eso sí, esto no significa que es invulnerable, pero tampoco es un campo abierto

Y tampoco tiene un rótulo de, hey, vengan, hackeenme.

Tercero, si algo raro pasa, ya tenés logs y alertas.

Puedes ver quién intentó entrar, cuántas veces y desde dónde.

¿Esto es suficiente?

¿Puede vivir así mi servidor por siempre para siempre?

No. No, my friend.

So sorry, my friend, pero no.

Esto es la seguridad básica.

A medida que tu servidor crece, que tus requerimientos crecen y por supuesto que tu expertise crece, vas a ir agregando más capas.

Actualizaciones automatizadas, backup programado, monitoreo activo, segundo factor de autenticación, las llaves SSH y mucho más.

Pero con estas cuatro capas ya estás en otro nivel, comparado con todos aquellos que no han escuchado este episodio y dejan todo por defecto.

Pero aún cumpliendo con nuestras tareas e implementando estas capas, también podemos cometer errores.

Y por eso es muy buena idea dar un repaso a los errores comunes, que son cinco, porque ya estamos llegando al final del episodio.

Vamos a ver.

Error número uno.

Pensar.

Después lo voy a hacer.

Bueno, voy a instalar el WordPress, voy a subir la web y ya después voy a ver si configuro la seguridad.

Y ya después voy a ver si pongo a punto esto de la seguridad.

Te digo yo, ese después nunca llega.

Error número dos.

Copiar comandos de internet o preguntarle a la IA sin entender qué estás haciendo.

Algunas veces copias algo mal o algunas veces no estás copiando el comando correcto con los parámetros correctos para tu sistema o para la versión de tu sistema.

Esto en el mejor de los casos, por así decirlo, podría dejarte fuera del servidor, que ya no tengas el acceso.

Algunas veces, lamentablemente, podrías sobreescribir configuraciones y en el peor de los casos podrías abrir innecesariamente tu servidor porque la IA alucinó y te dijo que esta configuración era mejor que aquella.

Con esto no te quiero decir que tenemos que volver a la biblioteca con los libros de texto. No. Puedes copiar comandos, por supuesto. Puedes preguntarle a la IA, por supuesto. Pero siempre verifica, siempre comproba y siempre hace snapshot previos antes de cualquier modificación. No hagas todo así por las prisas y creyéndole 100% a la IA.

Error número tres. Configurar la seguridad, pero nunca revisar. La seguridad, ya lo hemos dicho, no es algo que se hace una vez y queda hecho. Es algo que vos mantenés constantemente. Revisa logs, los logs, actualiza el sistema, monitoriza los recursos, revisa los accesos. Haced tus tareas.

Error número cuatro. Pensar que como mi servidor es pequeñito, mi proyecto es muy humilde, nadie se va a meter si nadie lo ve. Si mira si Google Analytics dice que solo tres personas han entrado esta semana. Incluso hasta pensar el quién va a querer hackear mi web.

Mira, ya lo hemos hablado. Los bots no discriminan. Atacan lo que encuentran. No importa si sos Google o sos el blog de Pepito Grillo 89. No le importa. Si vos lo pones público en internet, va a ser hackeado. Así de simple y sencillo.

Y con esto llegamos al error número 5. No tener plan B. No tener backups. No tener snapshots. No tener un plan de recuperación ante desastres.

Porque si un día algo sale mal, hombre, hay una gran diferencia entre poder restaurar el backup a perderlo todo.

Si estás escuchando esto y pensás, ¡hombre, Alex, qué faena! Te entiendo, te entiendo. Pero si lo ves, claro, te tomas un café, una tila, un té de manzanilla y luego lo volvés a escuchar, lo volvés a ver, lo ves con calma, vas a ver que tampoco es tan complicado como suena.

Yo, ¿qué te recomiendo? Mira, en tu agenda reserva una tarde, una o dos horas. Implementa las cuatro capas básicas. Prova, verifica que todo funciona. Por supuesto, crea un snapshot previo, ¿no? Por cualquier cosa.

Y después ya puedes instalar lo que necesites con la tranquilidad que tu servidor tiene esta protección básica.

Te gustaría ver la seguridad en las siguientes capas, en los siguientes niveles, porque esto es la básica.

Te gustaría ver, por ejemplo, el intermedio, el avanzado, para saber reservar tiempo y saber, digamos, cuál es el siguiente nivel.

No lo vamos a ver en este episodio porque ya estamos llegando al final, pero te voy a compartir en las notas del episodio el hilo del foro y el enlace al directo que tienen el mismo nombre, Seguridad Básica para VPS.

En ese directo y en ese hilo del foro de akoma.tech te comparto la seguridad como un todo.

La seguridad básica para tu VPS, pero como un todo.

Nivel básico, intermedio y avanzado.

Y ahí te voy desglosando lo que tienes que ver primero y tienes que ir resolviendo.

¿Cuál es la idea de esto?

La idea de esto es tener un punto de partida y que vos hagas tu propio checklist para que vayas completando y creando tu propia documentación, tu propio paso a paso.

Y bueno, vamos ya cerrando esta terminal. Vamos cerrando sesión.

Te recuerdo las cuatro capas básicas de seguridad que vimos en este episodio.

No usar el usuario root, firewall correctamente configurado, fail to ban activo y contraseñas fuertes y robustas.

Todo esto no es opcional.

Son los primeros pasos recomendables y yo te recomiendo sí o sí dedicar un poco de tiempo y hacerlo.

En el próximo episodio vamos a hablar sobre las llaves SSH, vamos a ver cómo funcionan y por qué son mejores y recomendables que las contraseñas.

Si tienes alguna duda sobre este tema de la seguridad básica o quieres compartirme tu experiencia, bien sabes que no te voy a dar la IP, pero sí la URL, paneldecontrol.org barra contacto.

¿Qué te parece si nos conectamos en el próximo episodio?

espero que sí que todo vaya muy bien ¡Salú!